This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/39891] Bogus location given for warning, no warning at real location: dereferencing pointer ‘<anonymous>’ does break strict-aliasing rules



------- Comment #3 from rguenth at gcc dot gnu dot org  2009-04-25 11:13 -------
The location is also "correct" in the sense that we try to warn with the
location
of the _dereference_.  And that is indeed in APSInt& APSInt::operator=(const
APSInt&):

 (void) (((struct APSInt *) this)->D.1723 = *(const struct APInt &) &((const
struct APSInt *) RHS)->D.1723)

the pointer initialization point is that of the call - we dereference a
type-pun of the this pointer in Val.getInt().

I have some improvements though - trying to get rid of '<anonymous>' most
of the time.  The improved version would look like

t.ii: In function 'bool foo()':
t.ii:8: warning: dereferencing type-punned pointer '& Val.APValue::Data' does
break strict-aliasing rules
t.ii:26: note: initialized from here

I don't know if that is more useful though - the &Val.APValue::Data expression
does not appear literally in the program either.

Note that getInt is completely inlined and there is no location involving
that function available anymore :/  The difficulties of C++ and late
diagnostics ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39891


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]