This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/11746] New: __attribute__((__noreturn__)) causing compiler SEGV
- From: "eljay at adobe dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 31 Jul 2003 14:15:57 -0000
- Subject: [Bug c++/11746] New: __attribute__((__noreturn__)) causing compiler SEGV
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11746
Summary: __attribute__((__noreturn__)) causing compiler SEGV
Product: gcc
Version: 3.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eljay at adobe dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
--- foo.cpp ---
extern int okay();
extern void good(int i = (okay(),0));
extern void boom() __attribute__((__noreturn__));
extern void crash(int i = (1?(void)0:boom(),0)); // <-- crash
extern void crash_this_too(int i = (boom(),0)); // <-- alternative crash
--- end-of-file ---
I would not expect a crash to occur at that line.
I realize that the above looks somewhat unusual, but it serves as a mechanism to
do Eiffel-like constraints. The above minimal code is distilled from the
real-world example, and doesn't demonstrate the utility value of the original
situation. The original situation spans many lines of code, and involves
__assert_fail from cassert / assert.h in particular.
No crash with GCC 2.95 or RH-GCC 2.96.
> gcc -v
Reading specs from
/user/unicore/i80386linux/compiler/gcc3.2/linux2.4/lib/gcc-lib/i686-pc-linux-gnu/3.2/specs
Configured with: ../configure
--prefix=/user/unicore/i80386linux/compiler/gcc3.2/linux2.4
--enable-languages=c,c++ --enable-threads
Thread model: posix
gcc version 3.2
> uname -a
Linux angelo 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown
Same crash on...
NT 5.1 / Cygwin GCC 3.2 prerelease-3
Sun 2.8 GCC 3.2
I have not confirmed that the crash still occurs with GCC 3.2.3 or GCC 3.3.1 or
GCC 3.4.