gcc 4.4.1/linux 64bit: code crashes with -O3, works with -O2

gcc 4.4.1/linux 64bit: code crashes with -O3, works with -O2

[Christoph Rupp]

Hi,

i'd like to submit a bug report. I read the instructions on
http://gcc.gnu.org/bugs, but i do not really know where the crash
happens and what causes the crash to happen. I therefore just wrote
the instructions below - they're simple. If you still need more
specific stuff, please send me a private message and help me a little
bit...

I have a library which uses automake/autoconf; it does not have
dependencies. If i build the non-debug version, files are compiled
with -O3. Then the library causes a segfault. If i compile with -O2,
everything works. Actually it's enough if i compile 2 files with -O2,
all others with -O3, and everything's fine.

If i run the program under valgrind, it runs without failure. gdb
shows that a pointer is bogus.

My system is a 64bit Ubuntu 9.04 linux, but i also saw it on other
64bit distributions (but it works fine on 32bit).
uname -a says:
Linux wintermute 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 17:01:44
UTC 2009 x86_64 GNU/Linux

My gcc is
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.4.1-4ubuntu8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --enable-multiarch --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
--program-suffix=-4.4 --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-objc-gc --disable-werror
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8)

I did some tests with the following versions (again, only x86_64. x86
works fine):
4.1.3 20080704 (prerelease) (Debian 4.1.2-27) - works
4.3.4 (Debian 4.3.4-6) - works
4.4.1 on Gentoo - fails
4.4.3 20100108 (prerelease) (Ubuntu 4.4.2-9ubuntu3) - fails

To reproduce, these steps are necessary:

wget http://crupp.de/dl/hamsterdb-1.1.1.tar.gz
tar -zxvf hamsterdb-1.1.1.tar.gz
cd hamsterdb-1.1.1
./configure --enable-internal
make
make test # this will segfault after a few tests

Now change the CFLAGS to -O2 in src/Makefile, and rebuild the two
files which depend on freelist.c
cd src
vi Makefile # -O3 -> -O2
touch freelist.c
make # will build two files - freelist.c and freelist_v2.c
cd ../unittests
make
./test # this will run

Best regards
Christoph

Re: gcc 4.4.1/linux 64bit: code crashes with -O3, works with -O2

[Jonathan Wakely]

2010/1/14 Christoph Rupp:
>
> To reproduce, these steps are necessary:
>
> wget http://crupp.de/dl/hamsterdb-1.1.1.tar.gz
> tar -zxvf hamsterdb-1.1.1.tar.gz
> cd hamsterdb-1.1.1
> ./configure --enable-internal
> make

There are lots of these warnings, which you ignore at your peril:

freelist.c:3326: warning: dereferencing type-punned pointer will break
strict-aliasing rules

ham_info.c:80: warning: dereferencing type-punned pointer will break
strict-aliasing rules

env.cpp:1804: warning: dereferencing type-punned pointer will break
strict-aliasing rules

You should probably either fix those warnings, avoid compiling at high
optimisation levels, or use -fno-strict-aliasing (which allows the
tests to run successfully.)

Re: gcc 4.4.1/linux 64bit: code crashes with -O3, works with -O2

[Dâniel Fraga]

On Thu, 14 Jan 2010 22:44:11 +0100
Christoph Rupp <chris@crupp.de> wrote:

> To reproduce, these steps are necessary:
> 
> wget http://crupp.de/dl/hamsterdb-1.1.1.tar.gz
> tar -zxvf hamsterdb-1.1.1.tar.gz
> cd hamsterdb-1.1.1
> ./configure --enable-internal
> make
> make test # this will segfault after a few tests

	At least here, it didn't segfault:

total: 0 errors, 636 tests

	***

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.4.2/configure --disable-multilib
Thread model: posix
gcc version 4.4.2 (GCC) 

Linux tux.abusar.org.br 2.6.32 #1 SMP PREEMPT Mon Dec 7 02:18:33 BRST
2009 x86_64 GNU/Linux

	***

	Have you tried with gcc 4.4.2?

-- 
Linux 2.6.32: Man-Eating Seals of Antiquity

Re: gcc 4.4.1/linux 64bit: code crashes with -O3, works with -O2

[Christoph Rupp]

Hi Jonathan & list,

this is a follow-up on an email from mid-january - i had crashes when
compiling my library with -O3. I fixed all warnings "dereferencing
type-punned pointer will break
> strict-aliasing rules" and got it running.

(at least i thought so - now i experience crashes again so maybe i
just messed up my makefile and falsely thought that everything would
work)...

I fixed all warnings regarding dereferencing type-punned pointers and
I compile with -O3 AND -fno-strict-aliasing.

and i still get the same crash as earlier. it does not crash with -O2.

From what i understand the -fno-strict-aliasing should solve the
problem, but it doesn't.

The function which crashes basically is searching a bitmap for a
pattern. When the search starts, it uses two pointers to the same
memory location (u64 ptr for searching in 8byte-steps, char* ptr for
searching byte-wise). If i understand the aliasing correctly then this
might cause the problems. I just don't know how to rewrite the
function - I want to use those two pointers for performance reasons. I
don't even know if the problem is in this function or if it's
somewhere else and the crash is just a side-effect of a completely
different problem.

To reproduce:
wget http://crupp.de/hamsterdb-1.1.3.tar.gz
tar -zxvf hamsterdb-1.1.3.tar.gz
cd hamsterdb-1.1.3
./configure
make
cd unittests
./test # <-- will segfault with a bad pointer

Here's my gcc version:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.4.1-4ubuntu9'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --enable-multiarch --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
--program-suffix=-4.4 --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-objc-gc --disable-werror
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)

Thanks for any help,
Christoph


2010/1/14 Jonathan Wakely <jwakely.gcc@gmail.com>:
> 2010/1/14 Christoph Rupp:
>>
>> To reproduce, these steps are necessary:
>>
>> wget http://crupp.de/dl/hamsterdb-1.1.1.tar.gz
>> tar -zxvf hamsterdb-1.1.1.tar.gz
>> cd hamsterdb-1.1.1
>> ./configure --enable-internal
>> make
>
> There are lots of these warnings, which you ignore at your peril:
>
> freelist.c:3326: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
>
> ham_info.c:80: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
>
> env.cpp:1804: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
>
> You should probably either fix those warnings, avoid compiling at high
> optimisation levels, or use -fno-strict-aliasing (which allows the
> tests to run successfully.)
>

Re: gcc 4.4.1/linux 64bit: code crashes with -O3, works with -O2

[Richard Guenther]

On Sat, Feb 20, 2010 at 1:38 PM, Christoph Rupp <chris@crupp.de> wrote:
> Hi Jonathan & list,
>
> this is a follow-up on an email from mid-january - i had crashes when
> compiling my library with -O3. I fixed all warnings "dereferencing
> type-punned pointer will break
>> strict-aliasing rules" and got it running.
>
> (at least i thought so - now i experience crashes again so maybe i
> just messed up my makefile and falsely thought that everything would
> work)...
>
> I fixed all warnings regarding dereferencing type-punned pointers and
> I compile with -O3 AND -fno-strict-aliasing.
>
> and i still get the same crash as earlier. it does not crash with -O2.
>
> From what i understand the -fno-strict-aliasing should solve the
> problem, but it doesn't.
>
> The function which crashes basically is searching a bitmap for a
> pattern. When the search starts, it uses two pointers to the same
> memory location (u64 ptr for searching in 8byte-steps, char* ptr for
> searching byte-wise). If i understand the aliasing correctly then this
> might cause the problems. I just don't know how to rewrite the
> function - I want to use those two pointers for performance reasons. I
> don't even know if the problem is in this function or if it's
> somewhere else and the crash is just a side-effect of a completely
> different problem.

With -fno-strict-aliasing this is perfectly valid so the problem must be
elsewhere.  It might be alignment related if you do not make sure
that the u64 accesses are properly aligned.  Try -O3 -fno-tree-vectorize
or analyze the crash.

Richard.

> To reproduce:
> wget http://crupp.de/hamsterdb-1.1.3.tar.gz
> tar -zxvf hamsterdb-1.1.3.tar.gz
> cd hamsterdb-1.1.3
> ./configure
> make
> cd unittests
> ./test # <-- will segfault with a bad pointer
>
> Here's my gcc version:
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 4.4.1-4ubuntu9'
> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> --enable-shared --enable-multiarch --enable-linker-build-id
> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-objc-gc --disable-werror
> --with-arch-32=i486 --with-tune=generic --enable-checking=release
> --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
>
> Thanks for any help,
> Christoph
>
>
> 2010/1/14 Jonathan Wakely <jwakely.gcc@gmail.com>:
>> 2010/1/14 Christoph Rupp:
>>>
>>> To reproduce, these steps are necessary:
>>>
>>> wget http://crupp.de/dl/hamsterdb-1.1.1.tar.gz
>>> tar -zxvf hamsterdb-1.1.1.tar.gz
>>> cd hamsterdb-1.1.1
>>> ./configure --enable-internal
>>> make
>>
>> There are lots of these warnings, which you ignore at your peril:
>>
>> freelist.c:3326: warning: dereferencing type-punned pointer will break
>> strict-aliasing rules
>>
>> ham_info.c:80: warning: dereferencing type-punned pointer will break
>> strict-aliasing rules
>>
>> env.cpp:1804: warning: dereferencing type-punned pointer will break
>> strict-aliasing rules
>>
>> You should probably either fix those warnings, avoid compiling at high
>> optimisation levels, or use -fno-strict-aliasing (which allows the
>> tests to run successfully.)
>>
>

Re: gcc 4.4.1/linux 64bit: code crashes with -O3, works with -O2

[Christoph Rupp]

2010/2/20 Richard Guenther <richard.guenther@gmail.com>:
> On Sat, Feb 20, 2010 at 1:38 PM, Christoph Rupp <chris@crupp.de> wrote:
[...]
>> I fixed all warnings regarding dereferencing type-punned pointers and
>> I compile with -O3 AND -fno-strict-aliasing.
>>
>> and i still get the same crash as earlier. it does not crash with -O2.
>>
>> From what i understand the -fno-strict-aliasing should solve the
>> problem, but it doesn't.
>>
>> The function which crashes basically is searching a bitmap for a
>> pattern. When the search starts, it uses two pointers to the same
>> memory location (u64 ptr for searching in 8byte-steps, char* ptr for
>> searching byte-wise). If i understand the aliasing correctly then this
>> might cause the problems. I just don't know how to rewrite the
>> function - I want to use those two pointers for performance reasons. I
>> don't even know if the problem is in this function or if it's
>> somewhere else and the crash is just a side-effect of a completely
>> different problem.
>
> With -fno-strict-aliasing this is perfectly valid so the problem must be
> elsewhere.  It might be alignment related if you do not make sure
> that the u64 accesses are properly aligned.  Try -O3 -fno-tree-vectorize
> or analyze the crash.

If i enable -fno-tree-vectorize for one file (that's the file which
produces the crash) everything works.

For me this workaround is fine, although this file is performance
relevant and i'd like to have every optimization that's available.

I don't really understand how alignment issues could cause this crash.
i'm only building for x86_64 and i was not aware of any alignment
requirements (i'd love to test on a SPARC, but sadly i don't have
access to one...)

BTW - if i execute this in valgrind then it doesn't crash or give warnings.

For me this looks cheesy - there are no gcc warnings, -O2 works, -O3
crashes. MSVC works and older gcc versions also work fine. In this
case it's hard for me not to blame gcc for the crash.

Anyway - thanks for your help!
Christoph

>
> Richard.
>
>> To reproduce:
>> wget http://crupp.de/hamsterdb-1.1.3.tar.gz
>> tar -zxvf hamsterdb-1.1.3.tar.gz
>> cd hamsterdb-1.1.3
>> ./configure
>> make
>> cd unittests
>> ./test # <-- will segfault with a bad pointer
>>
>> Here's my gcc version:
>> Using built-in specs.
>> Target: x86_64-linux-gnu
>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
>> 4.4.1-4ubuntu9'
>> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
>> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
>> --enable-shared --enable-multiarch --enable-linker-build-id
>> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
>> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
>> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu
>> --enable-libstdcxx-debug --enable-objc-gc --disable-werror
>> --with-arch-32=i486 --with-tune=generic --enable-checking=release
>> --build=x86_64-linux-gnu --host=x86_64-linux-gnu
>> --target=x86_64-linux-gnu
>> Thread model: posix
>> gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
>>
>> Thanks for any help,
>> Christoph
>>
>>
>> 2010/1/14 Jonathan Wakely <jwakely.gcc@gmail.com>:
>>> 2010/1/14 Christoph Rupp:
>>>>
>>>> To reproduce, these steps are necessary:
>>>>
>>>> wget http://crupp.de/dl/hamsterdb-1.1.1.tar.gz
>>>> tar -zxvf hamsterdb-1.1.1.tar.gz
>>>> cd hamsterdb-1.1.1
>>>> ./configure --enable-internal
>>>> make
>>>
>>> There are lots of these warnings, which you ignore at your peril:
>>>
>>> freelist.c:3326: warning: dereferencing type-punned pointer will break
>>> strict-aliasing rules
>>>
>>> ham_info.c:80: warning: dereferencing type-punned pointer will break
>>> strict-aliasing rules
>>>
>>> env.cpp:1804: warning: dereferencing type-punned pointer will break
>>> strict-aliasing rules
>>>
>>> You should probably either fix those warnings, avoid compiling at high
>>> optimisation levels, or use -fno-strict-aliasing (which allows the
>>> tests to run successfully.)
>>>
>>
>

Re: gcc 4.4.1/linux 64bit: code crashes with -O3, works with -O2

[Janis Johnson]

On Mon, 2010-02-22 at 21:17 +0100, Christoph Rupp wrote:
> 2010/2/20 Richard Guenther <richard.guenther@gmail.com>:
> > On Sat, Feb 20, 2010 at 1:38 PM, Christoph Rupp <chris@crupp.de> wrote:
> [...]
> >> I fixed all warnings regarding dereferencing type-punned pointers and
> >> I compile with -O3 AND -fno-strict-aliasing.
> >>
> >> and i still get the same crash as earlier. it does not crash with -O2.
> >>
> >> From what i understand the -fno-strict-aliasing should solve the
> >> problem, but it doesn't.
> >>
> >> The function which crashes basically is searching a bitmap for a
> >> pattern. When the search starts, it uses two pointers to the same
> >> memory location (u64 ptr for searching in 8byte-steps, char* ptr for
> >> searching byte-wise). If i understand the aliasing correctly then this
> >> might cause the problems. I just don't know how to rewrite the
> >> function - I want to use those two pointers for performance reasons. I
> >> don't even know if the problem is in this function or if it's
> >> somewhere else and the crash is just a side-effect of a completely
> >> different problem.
> >
> > With -fno-strict-aliasing this is perfectly valid so the problem must be
> > elsewhere.  It might be alignment related if you do not make sure
> > that the u64 accesses are properly aligned.  Try -O3 -fno-tree-vectorize
> > or analyze the crash.
> 
> If i enable -fno-tree-vectorize for one file (that's the file which
> produces the crash) everything works.
> 
> For me this workaround is fine, although this file is performance
> relevant and i'd like to have every optimization that's available.
> 
> I don't really understand how alignment issues could cause this crash.
> i'm only building for x86_64 and i was not aware of any alignment
> requirements (i'd love to test on a SPARC, but sadly i don't have
> access to one...)
> 
> BTW - if i execute this in valgrind then it doesn't crash or give warnings.
> 
> For me this looks cheesy - there are no gcc warnings, -O2 works, -O3
> crashes. MSVC works and older gcc versions also work fine. In this
> case it's hard for me not to blame gcc for the crash.
> 
> Anyway - thanks for your help!
> Christoph

Vector instructions usually require aligned data.  Perhaps the
vectorizer assumes that a pointer to 64-bit data will only be used
to access data that is 64-bit aligned.

If you can reproduce the problem with a small, self-contained test then
please file a bug report.  It might be possible to issue a warning or
to detect that the loop should not be vectorized.  If not, maybe the
compiler should disable vectorization for -fno-strict-aliasing.

Janis

> >
> > Richard.
> >
> >> To reproduce:
> >> wget http://crupp.de/hamsterdb-1.1.3.tar.gz
> >> tar -zxvf hamsterdb-1.1.3.tar.gz
> >> cd hamsterdb-1.1.3
> >> ./configure
> >> make
> >> cd unittests
> >> ./test # <-- will segfault with a bad pointer
> >>
> >> Here's my gcc version:
> >> Using built-in specs.
> >> Target: x86_64-linux-gnu
> >> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> >> 4.4.1-4ubuntu9'
> >> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
> >> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> >> --enable-shared --enable-multiarch --enable-linker-build-id
> >> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
> >> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
> >> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu
> >> --enable-libstdcxx-debug --enable-objc-gc --disable-werror
> >> --with-arch-32=i486 --with-tune=generic --enable-checking=release
> >> --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> >> --target=x86_64-linux-gnu
> >> Thread model: posix
> >> gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
> >>
> >> Thanks for any help,
> >> Christoph
> >>
> >>
> >> 2010/1/14 Jonathan Wakely <jwakely.gcc@gmail.com>:
> >>> 2010/1/14 Christoph Rupp:
> >>>>
> >>>> To reproduce, these steps are necessary:
> >>>>
> >>>> wget http://crupp.de/dl/hamsterdb-1.1.1.tar.gz
> >>>> tar -zxvf hamsterdb-1.1.1.tar.gz
> >>>> cd hamsterdb-1.1.1
> >>>> ./configure --enable-internal
> >>>> make
> >>>
> >>> There are lots of these warnings, which you ignore at your peril:
> >>>
> >>> freelist.c:3326: warning: dereferencing type-punned pointer will break
> >>> strict-aliasing rules
> >>>
> >>> ham_info.c:80: warning: dereferencing type-punned pointer will break
> >>> strict-aliasing rules
> >>>
> >>> env.cpp:1804: warning: dereferencing type-punned pointer will break
> >>> strict-aliasing rules
> >>>
> >>> You should probably either fix those warnings, avoid compiling at high
> >>> optimisation levels, or use -fno-strict-aliasing (which allows the
> >>> tests to run successfully.)
> >>>
> >>
> >

Re: gcc 4.4.1/linux 64bit: code crashes with -O3, works with -O2

[Andrew Pinski]

On Mon, Feb 22, 2010 at 1:06 PM, Janis Johnson <janis187@us.ibm.com> wrote:
> If you can reproduce the problem with a small, self-contained test then
> please file a bug report.  It might be possible to issue a warning or
> to detect that the loop should not be vectorized.  If not, maybe the
> compiler should disable vectorization for -fno-strict-aliasing.

It is not an aliasing issue but an alignment issue.  Anyways this is
most likely the same as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43009 .

Thanks,
Andrew Pinski

Re: gcc 4.4.1/linux 64bit: code crashes with -O3, works with -O2

[Janis Johnson]

On Mon, 2010-02-22 at 13:11 -0800, Andrew Pinski wrote:
> On Mon, Feb 22, 2010 at 1:06 PM, Janis Johnson <janis187@us.ibm.com> wrote:
> > If you can reproduce the problem with a small, self-contained test then
> > please file a bug report.  It might be possible to issue a warning or
> > to detect that the loop should not be vectorized.  If not, maybe the
> > compiler should disable vectorization for -fno-strict-aliasing.
> 
> It is not an aliasing issue but an alignment issue.  Anyways this is
> most likely the same as
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43009 .

Yes, that's the problem I had in mind but I was thinking about an
explicit cast to a pointer to more-aligned data in the function that has
the vector loop.  There's no way to warn about the undefined behavior
when the cast is in a different source file.

It's interesting that two reports of failure due to this same undefined
behavior come so close together.

Janis

Re: gcc 4.4.1/linux 64bit: code crashes with -O3, works with -O2

[Kai Henningsen]

On 22.02.2010 22:41, Janis Johnson wrote:
> On Mon, 2010-02-22 at 13:11 -0800, Andrew Pinski wrote:
>> On Mon, Feb 22, 2010 at 1:06 PM, Janis Johnson<janis187@us.ibm.com>  wrote:
>>> If you can reproduce the problem with a small, self-contained test then
>>> please file a bug report.  It might be possible to issue a warning or
>>> to detect that the loop should not be vectorized.  If not, maybe the
>>> compiler should disable vectorization for -fno-strict-aliasing.
>>
>> It is not an aliasing issue but an alignment issue.  Anyways this is
>> most likely the same as
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43009 .
>
> Yes, that's the problem I had in mind but I was thinking about an
> explicit cast to a pointer to more-aligned data in the function that has
> the vector loop.  There's no way to warn about the undefined behavior
> when the cast is in a different source file.
>
> It's interesting that two reports of failure due to this same undefined
> behavior come so close together.

I wonder if it might be feasible to have a flag which inserts code to 
check for alignment assumptions and complain if they're not met, to 
check for things like this.

(And then possibly to insert similar code for other assumptions gcc 
makes that are fairly easy to check at runtime.)

Not alternate code paths, just something like an assert that the code 
behaves like gcc feels justified in assuming it should, and the 
programmer didn't do anything stupid - as long as it's fairly simple to 
check, such as the actual alignment of a pointer or perhaps the actual 
limit of a loop or some such; and as long as the assumption actually 
influences code generation decisions.