http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41103
Paolo Carlini changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41103
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41103
Paolo Carlini changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org |
Known to fail|
--- Comment #5 from tim at klingt dot org 2009-08-18 14:36 ---
compiling with -fno-strict-aliasing doesn't do any difference.
the error is actually related to some code, that does a pointer/tag
compression, packing a pointer and an integer to a 64bit pointer [1] in order
to deal with th
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-18 14:24 ---
Does it work with -fno-strict-aliasing? I suppose this is one case where boost
plays tricks with placement new on decls (non-anonymous storage)?
--
rguenth at gcc dot gnu dot org changed:
What|Re
--- Comment #3 from tim at klingt dot org 2009-08-18 11:50 ---
i forgot to mention, i am building with bjam, passing the following options:
COLLECT_GCC_OPTIONS='-ftemplate-depth-128' '-O3' '-finline-functions'
'-Wno-inline' '-Wall' '-pthread' '-fPIC' '-g' '-v' '-save-temps'
'-DBOOST_ALL
--- Comment #2 from tim at klingt dot org 2009-08-18 11:37 ---
Created an attachment (id=18396)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18396&action=view)
preprocessed source, 4.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41103
--- Comment #1 from tim at klingt dot org 2009-08-18 11:35 ---
Created an attachment (id=18395)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18395&action=view)
preprocessed source, 4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41103
