public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/43637] New: [4.4/4.5 regression] miscompilation in strict-aliasing optimization
@ 2010-04-03 15:13 jengelh at medozas dot de
2010-04-03 15:14 ` [Bug c/43637] " jengelh at medozas dot de
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: jengelh at medozas dot de @ 2010-04-03 15:13 UTC (permalink / raw)
To: gcc-bugs
I have here a testcase where -fstrict-aliasing seems to miscompiles the code.
$ gcc-4.4 tc.c -o tc && ./tc
$ gcc-4.4 tc.c -o tc -O1 && ./tc
$ gcc-4.4 tc.c -o tc -O1 -fstrict-aliasing && ./tc
Segmentation fault
$ gcc-4.4 tc.c -o tc -O1 -fstrict-aliasing -DOK && ./tc
0xaf8bea20
This also happens with the gcc-4.5 snapshot.
> gcc-4.4 -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.4
--enable-linux-futex --without-system-libunwind --with-arch-32=i586
--with-tune=generic --build=i586-suse-linux
Thread model: posix
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)
> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-suse-linux/4.5/lto-wrapper
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.5
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.5
--enable-linux-futex --without-system-libunwind --enable-gold
--with-plugin-ld=/usr/bin/gold --with-arch-32=i586 --with-tune=generic
--build=i586-suse-linux
Thread model: posix
gcc version 4.5.0 20100331 (experimental) [trunk revision 157870] (SUSE Linux)
--
Summary: [4.4/4.5 regression] miscompilation in strict-aliasing
optimization
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jengelh at medozas dot de
GCC build triplet: i586-suse-linux-gnu
GCC host triplet: i586-suse-linux-gnu
GCC target triplet: i586-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43637
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c/43637] [4.4/4.5 regression] miscompilation in strict-aliasing optimization
2010-04-03 15:13 [Bug c/43637] New: [4.4/4.5 regression] miscompilation in strict-aliasing optimization jengelh at medozas dot de
@ 2010-04-03 15:14 ` jengelh at medozas dot de
2010-04-03 15:39 ` rguenth at gcc dot gnu dot org
2010-05-26 21:44 ` jengelh at medozas dot de
2 siblings, 0 replies; 4+ messages in thread
From: jengelh at medozas dot de @ 2010-04-03 15:14 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from jengelh at medozas dot de 2010-04-03 15:13 -------
Created an attachment (id=20302)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20302&action=view)
testcase
Hopefully short enough to be a testcase. Left unprocessed to not prematurely
clutter it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43637
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c/43637] [4.4/4.5 regression] miscompilation in strict-aliasing optimization
2010-04-03 15:13 [Bug c/43637] New: [4.4/4.5 regression] miscompilation in strict-aliasing optimization jengelh at medozas dot de
2010-04-03 15:14 ` [Bug c/43637] " jengelh at medozas dot de
@ 2010-04-03 15:39 ` rguenth at gcc dot gnu dot org
2010-05-26 21:44 ` jengelh at medozas dot de
2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-04-03 15:39 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-03 15:39 -------
You are accessing {lh,clh}.{next,prev} through a pointer to type
struct item.
Testcase can be fixed with givin clh and lh type struct item.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43637
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c/43637] [4.4/4.5 regression] miscompilation in strict-aliasing optimization
2010-04-03 15:13 [Bug c/43637] New: [4.4/4.5 regression] miscompilation in strict-aliasing optimization jengelh at medozas dot de
2010-04-03 15:14 ` [Bug c/43637] " jengelh at medozas dot de
2010-04-03 15:39 ` rguenth at gcc dot gnu dot org
@ 2010-05-26 21:44 ` jengelh at medozas dot de
2 siblings, 0 replies; 4+ messages in thread
From: jengelh at medozas dot de @ 2010-05-26 21:44 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from jengelh at medozas dot de 2010-05-26 21:44 -------
>You are accessing {lh,clh}.{next,prev} through a pointer to type struct item.
Thank you for your time.
I do have a few questions. I wonder where exactly I am doing that access. In
the first part of the for clause,
(pos) = list_entry((head)->next, typeof(*(pos)), member);
head->next is valid, so only pos is punned. The second part is
&(pos)->member != (void *)(head);
This I can imagine blowing up; as pos will point to a non-existing memory block
once the end of the list is reached. I thus replace that by the reverse of
containerof to avoid dereferencing pos (/or accessing member/next through a
pointer of the wrong type), IOW
#define s_member(var, type, member) \
((type *)((char *)var + offsetof(typeof(*var), member)))
s_member(pos, struct list_head, member) != (void *)(head)
On an empty list, the condition is not met, so the for loop stops and the third
part of the for() is not evaluated. On a non-empty list, pos points to a valid
memory region as long as it loops, so that the pos->member.next in 3rd part,
(pos) = list_entry((pos)->member.next, typeof(*(pos)), member))
should be valid. Please correct me if I am wrong.
Though I also have to employ s_member in the third case
(pos) = list_entry(s_member((pos), struct list_head, member)->next,
typeof(*(pos)), member))
to get rid of any visible artifacts (such as segfaults), but I suspect the
underlying problem isn't eliminated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43637
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-05-26 21:44 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-03 15:13 [Bug c/43637] New: [4.4/4.5 regression] miscompilation in strict-aliasing optimization jengelh at medozas dot de
2010-04-03 15:14 ` [Bug c/43637] " jengelh at medozas dot de
2010-04-03 15:39 ` rguenth at gcc dot gnu dot org
2010-05-26 21:44 ` jengelh at medozas dot de
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).