Hi, On Thu, 27 Feb 2014, Ruediger Meier wrote:
On Thursday 27 February 2014, Cristian Morales Vega wrote:
On 27 February 2014 16:36, Andreas Schwab
wrote: Ruediger Meier
writes: [ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined
This is probably the effect of inlining not properly maintaining sequence points.
So the warning is "correct", but the code generation is wrong?
As far as I understood, it's just a false positive warning. Seems to be fixed since gcc > 4.3. The was never a problem with the compiled binaries.
The link to the thread which I posted a few emails above indicates that there was a bug report about the issue. Unfortunately they didn't posted the bug number.
The link you posted doesn't indicate a gcc bug, Diego was confused, it used macros, not function calls and amounted basically to *c++ = *c; and _that_ does correctly cause a warning (there really is no sequence point between lhs and rhs of assignments). Your case is different, there you had hextou(++bp, &bp); And now comes the guesses: probably hextou (a static function, not macro) uses the value of *arg2 (i.e. bp), as well as the incremented value. With a little inlining and depending on how hextou's code looks like, that can very well result in effectively the same code as the invalid one above. But as there's a sequence point right before calling the function, there actually is no problem, also not after inlining. So your case does show a gcc bug (in not properly maintaining sequence point rules over inlining, as Andreas said), the link you posted does not. Now, of course, nothing of that helps you in your problem, but perhaps is entertaining :) Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org