Bug 19171 - <sys/reent.h> causes segfault ICE in GCC 4
Summary: <sys/reent.h> causes segfault ICE in GCC 4
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.0.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code, wrong-code
Depends on:
Blocks:
 
Reported: 2004-12-27 21:30 UTC by Lucas
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: i686-pc-cygwin
Target: i686-pc-cygwin
Build: i686-pc-cygwin
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Preprocessed source of the header file in question (1.46 KB, text/plain)
2004-12-27 21:31 UTC, Lucas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lucas 2004-12-27 21:30:16 UTC
Files that include <sys/reent.h> on i686-pc-cygwin can cause GCC 4 (10-26-04) to
bomb out due to a segfault in the compiler itself. I don't have a backtrace (I
don't know how to get one if the ICE occurs during the bootstrap process itself,
which it does).
Comment 1 Lucas 2004-12-27 21:32:00 UTC
Created attachment 7832 [details]
Preprocessed source of the header file in question

This is a preprocessed copy of a file that did nothing else but include
<sys/reent.h>.
Comment 2 Andrew Pinski 2004-12-27 22:07:56 UTC
10-26-04 is very old, I cannot reproduce it with a cross compiler with today's compiler, can you try a 
new snapshot.
Comment 3 Lucas 2004-12-28 01:18:49 UTC
This bug still exists with GCC 4 as of 10-27-04, and I miscategorized this bug.
 It occurs during bootstrap in builds hosted on i686-pc-cygwin.
Comment 4 Andrew Pinski 2004-12-28 01:20:13 UTC
Do you mean 12-27-04 or 10-27-04?
Comment 5 Lucas 2004-12-28 01:23:11 UTC
(In reply to comment #4)
> Do you mean 12-27-04 or 10-27-04?
Sorry, I meant 12-27-04.  The 10 was a typo.

Comment 6 Andrew Pinski 2004-12-28 01:28:16 UTC
Ok, then I will close this as invalid to ...
Comment 7 Andrew Pinski 2004-12-28 01:28:32 UTC
Mark as unconfirmed.
Comment 8 Lucas 2004-12-28 01:31:22 UTC
(In reply to comment #7)
> Mark as unconfirmed.

Ok, does anyone else have Cygwin?
Comment 9 Lucas 2004-12-28 01:59:30 UTC
I finally figured out how to get a backtrace from the stage2 compiler, so here
it is (this is from running the posted testcase thru cc1):

--backtrace starts--
Starting program: /home/Lucas/b-gcc/gcc/cc1.exe /home/Lucas/test.i

Program received signal SIGSEGV, Segmentation fault.
0x00583da6 in emit_insn (x=0x101d19a0) at ../../gcc/gcc/emit-rtl.c:4375
4375      rtx last = last_insn;
(gdb) bt
#0  0x00583da6 in emit_insn (x=0x101d19a0) at ../../gcc/gcc/emit-rtl.c:4375
#1  0x00646f9c in ix86_handle_cdecl_attribute (node=0x22e614,
    name=0x101d7a48, args=0x0, flags=0, no_add_attrs=0x22e61b "")
    at ../../gcc/gcc/config/i386/i386.c:1716
#2  0x0040965f in decl_attributes (node=0x22e6f0, attributes=0x101da870,
    flags=0) at ../../gcc/gcc/attribs.c:253
#3  0x00405d9e in yyparse () at c-parse.y:1723
#4  0x004087c2 in c_parse_file () at c-parse.y:2922
#5  0x0047bf62 in c_common_parse_file (set_yydebug=0)
    at ../../gcc/gcc/c-opts.c:1092
#6  0x0049ec9b in compile_file () at ../../gcc/gcc/toplev.c:992
#7  0x004a079e in do_compile () at ../../gcc/gcc/toplev.c:2085
#8  0x004a0801 in toplev_main (argc=2, argv=0x10100f08)
    at ../../gcc/gcc/toplev.c:2117
#9  0x004972e0 in main (argc=2, argv=0x10100f08) at ../../gcc/gcc/main.c:35
--backtrace ends--
Comment 10 Andrew Pinski 2004-12-28 05:02:20 UTC
(In reply to comment #9)
> I finally figured out how to get a backtrace from the stage2 compiler, so here
> it is (this is from running the posted testcase thru cc1):

This backtrace does not makes sense as ix86_handle_cdecl_attribute does not call emit_insn,
are you sure you don't have an extra patch which is applied wrong?
Comment 11 Lucas 2004-12-28 14:27:51 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > I finally figured out how to get a backtrace from the stage2 compiler, so here
> > it is (this is from running the posted testcase thru cc1):
> 
> This backtrace does not makes sense as ix86_handle_cdecl_attribute does not
call emit_insn,
> are you sure you don't have an extra patch which is applied wrong?

OK, I updated my CVS to 10-28-04 and I still get this error (same place, too:
the  libgcc2 build is what's failing).  I'll try doing a fresh co.
Comment 12 Lucas 2004-12-30 01:25:06 UTC
Fresh co as of 10-28-04 works.  It was a patching glitch. =P Thanks!