[Bug c/43637] New: [4.4/4.5 regression] miscompilation in strict-aliasing optimization

[Bug c/43637] New: [4.4/4.5 regression] miscompilation in strict-aliasing optimization

[jengelh at medozas dot de]

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

[Bug c/43637] [4.4/4.5 regression] miscompilation in strict-aliasing optimization

[jengelh at medozas dot de]

------- 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

[Bug c/43637] [4.4/4.5 regression] miscompilation in strict-aliasing optimization

[rguenth at gcc dot gnu dot org]

------- 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

[Bug c/43637] [4.4/4.5 regression] miscompilation in strict-aliasing optimization

[jengelh at medozas dot de]

------- 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