8030 libmvect: uninitialized variable

Review Request #428 — Created April 4, 2017 and submitted

tsoome
illumos-gate
8030
2f9f63b...
general
I suspect this is actually mis-detected.


  • 0
  • 0
  • 2
  • 0
  • 2
Description From Last Updated
andy_js
  1. I suspect you're right and it is a false positive. I would be more inclined to suppress the warning.

    1. I do understand the temptation, but our goal should be suppressions removed, not added.

    2. We shouldn't be blindly initializing everything gcc thinks is uninitialized as well. I'd really love to understand why it does think so.

    3. it is not done just "blindly" - if you look on it, why x2 and not y2? also same will go for x1 and y1. I actually do suspect the gcc 6.3 bug there, and thats really about making "mental note" - unfortunately I have no information if anyone is actually working on gcc to get the root cause identified and fixed. I have no time to do that myself and this is exactly the reason why I'm posting those reviews - maybe someone will finally step up. At least, at this time we actually do have the compiler packaged, so we can do something.

    4. I would still go for supressing the warning along with a comment in the appropriate makefile pointing the finger at GCC.

  2. 
      
marcel
  1. Ship It!
  2. usr/src/lib/libmvec/common/__vhypotf.c (Diff revision 1)
     
     
    Maybe it would be better to move this initialization right before the actual initialization at line 140, so the fun is even more obvious.
  3. 
      
rm
  1. 
      
  2. usr/src/lib/libmvec/common/__vhypotf.c (Diff revision 1)
     
     
    If we're fixing braces, should this be pulled up a line?
  3. usr/src/lib/libmvec/common/__vhypotf.c (Diff revision 1)
     
     
    Is there a chance that this assignment is what's screwing up gcc's analysis?
    1. I definitely also suspect it, but there is still the question why it only does happen with x2, and not for y2, or x1/y1 pair. Probably the mechanics is more complicated of course; in some other cases it also seems the if statement can have some influence; and/or perhaps something about how they are trying to predict the execution paths. I think this issue is something not to hurry about anyhow - there are more obvious ones and hopefully at some point we can have enough analysis about gcc 6 there to understand the root cause better.

    2. Quite surely. And I took different kind of approach for workaround - instead of pointer games, using union.

  4. 
      
tsoome
marcel
  1. Ship It!
  2. 
      
tsoome
rm
  1. Ship It!
  2. 
      
marcel
  1. Ship It!
  2. 
      
tsoome
Review request changed

Status: Closed (submitted)

Loading...