--- Comment #9 from sezeroz at gmail dot com 2009-07-31 09:59 ---
Interesting that the problem occurs only with the inlined version: if the test
object is linked with a non-inline version in a separate *.a file, the test
behaves correctly.. BTW, neither 4.4 nor 4.5 complains even with
-
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-07-31 09:48 ---
With 4.4 you are probably simply lucky ;) This is an aliasing violation
because
C even considers
struct A { int i; };
struct B { int i; };
to be different. If the indirection isn't needed why provide two structs
--- Comment #7 from sezeroz at gmail dot com 2009-07-31 06:30 ---
Besides my question in comment #6, I wonder why is this actually considered an
aliasing violation? The only difference between struct stat and struct
_stat64i32 is the time fields: _stat64i32 has __time64_t and stat has t
--- Comment #6 from sezeroz at gmail dot com 2009-07-30 19:30 ---
(In reply to comment #5)
> Yep:
>
> extern __inline__ int __attribute__((__cdecl__)) stat(const char
> *_Filename,struct stat *_Stat) {
> return _stat64i32(_Filename,(struct _stat64i32 *)_Stat);
> }
>
> that isn't goin
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-30 14:34 ---
Yep:
extern __inline__ int __attribute__((__cdecl__)) stat(const char
*_Filename,struct stat *_Stat) {
return _stat64i32(_Filename,(struct _stat64i32 *)_Stat);
}
that isn't going to fly.
struct stat {
_dev
--- Comment #4 from ppluzhnikov at google dot com 2009-07-30 14:03 ---
Created an attachment (id=18272)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18272&action=view)
pre-processed t.c
Some answers:
The -fno-strict-aliasing does help:
/usr/local/mingw-w64/bin/x86_64-w64-mingw3
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-30 10:24 ---
It indeed smells like a alias violation. Preprocessed source would help here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
--- Comment #2 from sezeroz at gmail dot com 2009-07-30 09:58 ---
Hmm, with gcc-4.4.2 (branch rev. 150249), I always get "mode = 81ff" reported
on the console with both -O0 and -O2 compiled exes from t.c test. This is with
mingw-w64 headers and crt revision 1101, the exes cross-compiled
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-07-30 08:38 ---
Hmm, possibly this is a bug in our inline functions of mingw-w64. Does the
switch -fno-strict-aliasing solves this issue, too?
We have here struct casts, which maybe are reasoning here strict aliasing
issues.
Kai
-
