[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #50 from Denis Excoffier g...@denis-excoffier.org --- gcc-4.9.1-RC-20140710 bootstraps perfectly. Thank you.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #48 from Fanael fanael4 at gmail dot com --- Is revision 209946 an attempt to fix this?
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #49 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Fanael from comment #48) Is revision 209946 an attempt to fix this? Yes. It is supposed to fix the cygwin-32 build with --disable-sjlj-exceptions
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||fanael4 at gmail dot com --- Comment #47 from Kai Tietz ktietz at gcc dot gnu.org --- *** Bug 61003 has been marked as a duplicate of this bug. ***
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #46 from Mikael Pettersson mikpelinux at gmail dot com --- Using a binutils with the proposed patch for binutils' PR 16858 I can now bootstrap gcc-4.8.2 with --disable-sjlj-exceptions on Cygwin.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #42 from Kai Tietz ktietz at gcc dot gnu.org --- Second variant of the patch looks ok to me, if bootstrap works for 32-bit and 64-bit cygwin. Post patch to ML for gcc trunk, and if no further issues are present we can merge patch to 4.9.1
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #43 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Kai Tietz from comment #42) Second variant of the patch looks ok to me, if bootstrap works for 32-bit and 64-bit cygwin. Post patch to ML for gcc trunk, and if no further issues are present we can merge patch to 4.9.1 Boot-Strap works for 32 bit. Could you please try 64 bit for me, as I don't have access to that configuration?
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #44 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Kai Tietz from comment #42) Second variant of the patch looks ok to me, if bootstrap works for 32-bit and 64-bit cygwin. Post patch to ML for gcc trunk, and if no further issues are present we can merge patch to 4.9.1 I have no access to a 64bit cygwin, but if the patch works there, shouldn't it be possible to make it available to 4.9.0, instead of 4.9.1? After all, the bootstrap (with --disable-sjlj-exceptions) fails and this cannot be worse with the patch. Also there is no impact on other (non-cygwin) configurations.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #45 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Denis Excoffier from comment #44) shouldn't it be possible to make it available to 4.9.0, instead of 4.9.1? No because 4.9.0 is out.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #30 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
It looks like a bug in the assembler!
with objdump -d -r crtbegin.o we have wrong code:
f3: 83 ec 04sub$0x4,%esp
f6: 85 c0 test %eax,%eax
f8: ba f0 ff ff ff mov$0xfff0,%edx
f9: dir32 ___deregister_frame_info
fd: 74 16 je 115 ___gcc_deregister_frame+0x35
but the cygming-crtbegin.s looks correct:
LVL17:
.loc 1 158 0
testl %eax, %eax
.loc 1 162 0
movl$___deregister_frame_info, %edx
.loc 1 158 0
je L27
whenever there is a weak definition the reference is actually minus
the offset of the previous weak definition. Everything is OK if that was
at offset zero.
test case:
$ cat test.c
#include stdio.h
extern void test() __attribute__((weak));
int main()
{
printf(hello\n);
test();
return 0;
}
__attribute__((weak))
void test()
{
printf(weak\n);
}
$ cat test1.c
#include stdio.h
void test()
{
printf(strong\n);
}
$ gcc -o test test.c test1.c
$ ./test
hello
Segmentation fault (core dumped)
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #31 from Kai Tietz ktietz at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #30)
It looks like a bug in the assembler!
with objdump -d -r crtbegin.o we have wrong code:
f3: 83 ec 04sub$0x4,%esp
f6: 85 c0 test %eax,%eax
f8: ba f0 ff ff ff mov$0xfff0,%edx
f9: dir32 ___deregister_frame_info
fd: 74 16 je 115 ___gcc_deregister_frame+0x35
but the cygming-crtbegin.s looks correct:
LVL17:
.loc 1 158 0
testl %eax, %eax
.loc 1 162 0
movl$___deregister_frame_info, %edx
.loc 1 158 0
je L27
whenever there is a weak definition the reference is actually minus
the offset of the previous weak definition. Everything is OK if that was
at offset zero.
test case:
$ cat test.c
#include stdio.h
extern void test() __attribute__((weak));
int main()
{
printf(hello\n);
test();
return 0;
}
__attribute__((weak))
void test()
{
printf(weak\n);
}
$ cat test1.c
#include stdio.h
void test()
{
printf(strong\n);
}
$ gcc -o test test.c test1.c
$ ./test
hello
Segmentation fault (core dumped)
Interesting finding. So second issue cooks down to be an binutils bug about
weak. I remember the cause of the change to gcc's crtbegin, and it is pretty
important one (at least for x64). As the implicit zero-relocation doesn't work
on x64 as instructions have +/-2^31 offset in max.
So I would suggest to report this issue on binutils. gcc's bz isn't the right
place to discuss that issue further.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #32 from Bernd Edlinger bernd.edlinger at hotmail dot de --- OK, opened a binutils-bug at: https://sourceware.org/bugzilla/show_bug.cgi?id=16858
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #33 from Denis Excoffier g...@denis-excoffier.org --- Created attachment 32651 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32651action=edit bootstrap works at least under i686
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #34 from Denis Excoffier g...@denis-excoffier.org --- The patch under attachment 32651 seems to make bootstrapping behave better, at least for i686.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #35 from Bernd Edlinger bernd.edlinger at hotmail dot de --- would not using --disable-sjlj-excaptions cause any problems, maybe a unwanted ABI-Change?
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #36 from Denis Excoffier g...@denis-excoffier.org ---
(In reply to Bernd Edlinger from comment #35)
would not using --disable-sjlj-excaptions cause any problems,
maybe a unwanted ABI-Change?
I don't know really. Cygwin people usually build gcc using
--disable-sjlj-exceptions and the /usr/bin/cyggcc_s-1.dll is never very far.
Without --disable-sjlj-exceptions, you get a ${prefix}/bin/cyggcc_s-sjlj-1.dll,
and i believe that cyggcc_s-1.dll and cyggcc_s-sjlj-1.dll are not supposed to
live together very well.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #37 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Denis Excoffier from comment #36)
(In reply to Bernd Edlinger from comment #35)
would not using --disable-sjlj-excaptions cause any problems,
maybe a unwanted ABI-Change?
I don't know really. Cygwin people usually build gcc using
--disable-sjlj-exceptions and the /usr/bin/cyggcc_s-1.dll is never very far.
Without --disable-sjlj-exceptions, you get a
${prefix}/bin/cyggcc_s-sjlj-1.dll, and i believe that cyggcc_s-1.dll and
cyggcc_s-sjlj-1.dll are not supposed to live together very well.
That sounds in deed like a problem.
Regarding your patch:
I believe the reason for the gas-bug is that more than one weak default
definitions in one .o file and calling them from ths same compilation unit
caused the bug.
Maybe it would work, if you move all (maybe but one) default definitions from
cygming-crtbegin.c to cygming-crtend.c, leaving just the forward declarations.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #38 from Denis Excoffier g...@denis-excoffier.org ---
(In reply to Bernd Edlinger from comment #37)
Regarding your patch:
I've tested it and it works (as far as i can tell): the bootstrap has gone
until the end (installation in ${prefix}). objdump -d crtbegin.o contains ba 00
00 00 00 instead of ba f0 ff ff ff, and the .weak... objects at the beginning
of crtbegin.o are gone. More than that, i've built (with this GCC 4.9) several
usual distributions (for the moment: sed, patch, diffutils, bzip2, make, gawk,
xz, many others to come of course).
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #39 from Kai Tietz ktietz at gcc dot gnu.org --- Well, the patch might work-a-round issue. Nevertheless it just paperbags the real issue existing in binutils. Additionally the patch would break x64 version of cygwin. At least that was the reason why we introduced it.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #40 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 32652 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32652action=edit another possible workaround This is what I am bootstrapping right now. Looks good so far, it just reached stage3.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #41 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Kai Tietz from comment #39) Well, the patch might work-a-round issue. Nevertheless it just paperbags the real issue existing in binutils. Additionally the patch would break x64 version of cygwin. At least that was the reason why we introduced it. Kai, this issue is also present in binutils-2.22, and probably very old. So it really deserves a work-around on our side. As far as I understood from your messages on gcc-patches, the PE-Format is not able to handle weak externals without any definition. But it is not a requirement, that the weak definition is in the same file, where it is used. So this patch just moves the weak definitions to another file. The only file I could think of is cygming-crtend.c, because crtbegin.o and crtend.o are always used in pairs. What do you think, will this work for x64 too? Bernd.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #29 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Hmm, that is really strange. the crash happens in __gcc_deregister_frame. just break at this function and step. The first call is GetModuleHandle (LIBGCC_SONAME) which returns NULL, so the weak default __deregister_frame_info is used. BUT the address is wrong by 0x10. 00401170 ___gcc_deregister_frame: 401170: 55 push %ebp 401171: 89 e5 mov%esp,%ebp 401173: 83 ec 18sub$0x18,%esp 401176: c7 04 24 20 71 47 00movl $0x477120,(%esp) 40117d: ff 15 50 b4 4c 00 call *0x4cb450 401183: 83 ec 04sub$0x4,%esp 401186: 85 c0 test %eax,%eax 401188: ba 10 25 47 00 mov$0x472510,%edx 40118d: 74 16 je 4011a5 ___gcc_deregister_frame+0x35 40118f: c7 44 24 04 67 71 47movl $0x477167,0x4(%esp) 401196: 00 401197: 89 04 24mov%eax,(%esp) 40119a: ff 15 54 b4 4c 00 call *0x4cb454 4011a0: 83 ec 08sub$0x8,%esp 4011a3: 89 c2 mov%eax,%edx 4011a5: 85 d2 test %edx,%edx 4011a7: 74 09 je 4011b2 ___gcc_deregister_frame+0x42 4011a9: c7 04 24 38 b0 4b 00movl $0x4bb038,(%esp) 4011b0: ff d2 call *%edx = this call goes to 0x472510 instead of 0x472520. 4724ff: e8 fc 01 00 00 call 472700 _free 472504: 8b 44 24 1c mov0x1c(%esp),%eax 472508: 83 c4 28add$0x28,%esp 47250b: 5b pop%ebx 47250c: c3 ret 47250d: 89 d0 mov%edx,%eax 47250f: ba e4 ac 4c 00 mov$0x4cace4,%edx 472514: eb a6 jmp4724bc ___deregister_frame_info_bases+0x6c 472516: 8d 76 00lea0x0(%esi),%esi 472519: 8d bc 27 00 00 00 00lea0x0(%edi,%eiz,1),%edi 00472520 ___deregister_frame_info: 472520: e9 2b ff ff ff jmp472450 ___deregister_frame_info_bases 472525: 8d 74 26 00 lea0x0(%esi,%eiz,1),%esi 472529: 8d bc 27 00 00 00 00lea0x0(%edi,%eiz,1),%edi
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #26 from Denis Excoffier g...@denis-excoffier.org --- After more investigation, it seems that the culprit can be --disable-sjlj-exceptions. Since the beginning (last Sunday), each time i use it on the command line, the build fails and each time i don't use it, the build succeeds. Please would you mind trying again a cygwin build, but with --disable-sjlj-exceptions this time. Especially for those where the build succeeded. For Mikael (see comment #2), it is more than probable that he used --disable-sjlj-exceptions instead of my gmp kludges known by nobody except by me.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #27 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Denis Excoffier from comment #26) After more investigation, it seems that the culprit can be --disable-sjlj-exceptions. Since the beginning (last Sunday), each time i use it on the command line, the build fails and each time i don't use it, the build succeeds. Please would you mind trying again a cygwin build, but with --disable-sjlj-exceptions this time. Especially for those where the build succeeded. For Mikael (see comment #2), it is more than probable that he used --disable-sjlj-exceptions instead of my gmp kludges known by nobody except by me. Yes, adding --disable-sjlj-exceptions makes the build fail: mkdir -p -- i686-pc-cygwin/libgcc Checking multilib configuration for libgcc... Configuring stage 2 in i686-pc-cygwin/libgcc configure: creating cache ./config.cache checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... gawk xgcc: error: unrecognized command line option '-isystem' xgcc: error: unrecognized command line option '-isystem' xgcc: error: unrecognized command line option '-mtune=generic' xgcc: error: unrecognized command line option '-march=pentiumpro' checking for i686-pc-cygwin-ar... ar checking for i686-pc-cygwin-lipo... lipo checking for i686-pc-cygwin-nm... /home/ED/gnu/gcc-build/./gcc/nm checking for i686-pc-cygwin-ranlib... ranlib checking for i686-pc-cygwin-strip... strip checking whether ln -s works... yes checking for i686-pc-cygwin-gcc... /home/ED/gnu/gcc-build/./gcc/xgcc -B/home/ED/gnu/gcc-build/./gcc/ -B/home/ed/gnu/install/i686-pc-cygwin/bin/ -B/home/ed/gnu/install/i686-pc-cygwin/lib/ -isystem /home/ed/gnu/install/i686-pc-cygwin/include -isystem /home/ed/gnu/install/i686-pc-cygwin/sys-include checking for C compiler default output file name... configure: error: in `/home/ED/gnu/gcc-build/i686-pc-cygwin/libgcc': configure: error: C compiler cannot create executables See `config.log' for more details. Makefile:17788: recipe for target 'configure-stage2-target-libgcc' failed make[2]: *** [configure-stage2-target-libgcc] Error 77 make[2]: Leaving directory '/home/ED/gnu/gcc-build' Makefile:20606: recipe for target 'stage2-bubble' failed make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory '/home/ED/gnu/gcc-build' Makefile:897: recipe for target 'all' failed make: *** [all] Error 2
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 Denis Excoffier g...@denis-excoffier.org changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #24 from Denis Excoffier g...@denis-excoffier.org --- Well, i suppose it can be RESOLVED_INVALID. Last night i built successfully with 1.7.28-2. I was using some non-standard configuration for gmp and as soon as this kludge was removed, gcc built perfectly (once...). I have to confirm this with a few other builds, latest cygwin version etc. I'll keep you informed. Hence, my fault. However, i am curious to know how Mikael (see comment #2) was able to obtain the exact very same symptoms (to be honest: nearly). Please could you provide details?
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #25 from Kai Tietz ktietz at gcc dot gnu.org --- So I close this bug. Don't hesitate to answer Denis' question.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #13 from Denis Excoffier g...@denis-excoffier.org --- Created attachment 32600 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32600action=edit gdb session stepping until the end
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #14 from Denis Excoffier g...@denis-excoffier.org --- I'm now using plain cygwin-1.7.29-2, the cygwin1.dbg now matches with cygwin1.dll. I've alto tried to recompile without -O2. I'm not so familiar with gdb, i've produced a session where i break at __call_exitprocs (in cygwin1.dll), that shows that the destructors are not called more than once. But i now obtain 2 SEGV. Hope this helps. See attachment 32600.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #15 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to Denis Excoffier from comment #14) I'm now using plain cygwin-1.7.29-2, the cygwin1.dbg now matches with cygwin1.dll. I've alto tried to recompile without -O2. I'm not so familiar with gdb, i've produced a session where i break at __call_exitprocs (in cygwin1.dll), that shows that the destructors are not called more than once. But i now obtain 2 SEGV. Hope this helps. See attachment 32600 [details]. Thanks, the second SIGSEGV is the Second Chance exception. Nothing to wonder here. There seems to be no handler catching the SIGSEGV's first chance exception.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||cgf at gcc dot gnu.org, ||dave.korn.cygwin at gmail dot com --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org --- Hum. This looks like a cygwin issue to me? Do earlier cygwin versions work ok? I only see x86_64-cygwin testresults posted semi-regularly from Tim Prince but no i686-cygwin ones (which is the platform listed in secondary targets). Adding the rest of cygwin maintainers to CC.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #17 from Kai Tietz ktietz at gcc dot gnu.org --- Just as side-note, I tried to reproduce your reported issue and did a personal build of cygwin's gcc. It worked fine in stage2. I couldn't reproduce the reported ICE on stage2. Which brings me to the question if you are using additional patches/fixes, etc
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #18 from Kai Tietz ktietz at gcc dot gnu.org --- Another side-note. You should specify option '--disable-multilib'. this is pretty essential as cygwin doesn't support it right now.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #19 from Denis Excoffier g...@denis-excoffier.org --- Created attachment 32602 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32602action=edit discover __DTOR_LIST__
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #20 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Kai Tietz from comment #12) In general it would be of interest to learn what destructors (by whom) are present in the list called by do_global_dtors (__DTOR_LIST__) I've rebuilt everything, under plain cygwin-1.7.29-2, with BOOT_CFLAGS=-g instead of -g -O2. I carefully didn't rebuilt anything after the failure in i686-pc-cygwin/libgcc like before and cc1 seems to work, BUT xgcc still does not work (with the same symptoms). xgcc --version (or -dumpspecs) shows something on stdout, but when piped into wc, there is no output... Strange. The __DTOR_LIST__ contains a single item: deregister_frame_dtor (see attachment 32602). Also the specs file is not built (is built empty, see in attachment the -dumpspecs parameter), this is probably the cause of the xgcc: error: unrecognized command line option 'X' (with X=--version, or -mtune=generic, or -march=pentiumpro) when the -B/tmp/lcl/tmp/gcc/obj/gcc/ option is used.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #21 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Kai Tietz from comment #17) Just as side-note, I tried to reproduce your reported issue and did a personal build of cygwin's gcc. It worked fine in stage2. I couldn't reproduce the reported ICE on stage2. Which brings me to the question if you are using additional patches/fixes, etc Did you use 32bits? Did you use a recent cygwin version? There has been some movement recently (2014-03-28) in dtors.cc, although i believe that only 64bits is impacted.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #22 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to Denis Excoffier from comment #21) (In reply to Kai Tietz from comment #17) Just as side-note, I tried to reproduce your reported issue and did a personal build of cygwin's gcc. It worked fine in stage2. I couldn't reproduce the reported ICE on stage2. Which brings me to the question if you are using additional patches/fixes, etc Did you use 32bits? Did you use a recent cygwin version? There has been some movement recently (2014-03-28) in dtors.cc, although i believe that only 64bits is impacted. I built recent gcc 4.9 on my pre-installed cygwin 32-bit (as you did too, as logs have shown). Only difference I made was to disable multilib. And this you should do too. Additionally I built x64 version on my cygwin64 environment too. So from my point of view it isn't a gcc issue. As both targets are bootstrapping without issue for me. So, it might be an issue with recent cygwin, I can test that too. I will continue on that tomorrow as it takes me pretty long to built it native. Nevetheless I doubt that I will find different results for gcc. And if it is really dependent on cygwin-dll version, then it seems to me indeed like a cygwin-bug
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #23 from Bernd Edlinger bernd.edlinger at hotmail dot de --- FYI: I have 32-bit cygwin 1.7.28-2/XP SP2 here, and the following configuration builds successfully: ../gcc-4.9.0-RC-20140411/configure --prefix=/full-path-to-install --enable-languages=c,c++ gmp etc. in-tree with: contrib/download_prerequisites
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Priority|P3 |P1 Status|UNCONFIRMED |WAITING Last reconfirmed||2014-04-14 Target Milestone|--- |4.9.0 Summary|ICE on bootstrapping on |[4.9 Regression] ICE on |cygwin |bootstrapping on cygwin Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Can you provide a full backtrace? This looks like a library we link to calling abort () (gcc itself doesn't do that without printing some pretty message).
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Btw, the usual suspicious one is gmp which in older versions used to abort () on impossible CPU kinds in its CPU detection code (at least trips on qemu default configs for example)
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #5 from Denis Excoffier g...@denis-excoffier.org --- Created attachment 32591 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32591action=edit top level config.log
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #6 from Denis Excoffier g...@denis-excoffier.org --- Created attachment 32592 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32592action=edit i686-pc-cygwin/libgcc/config.log
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #7 from Denis Excoffier g...@denis-excoffier.org --- Here are the config.log found at top level and the config.log at i686-pc-cygwin/libgcc level (see attachments). What do you need more specifically? I have to say that i use gmp-6.0.0a, mpfr-3.1.2 (without patches), and mpc-1.0.2, all of them untarred in the source tree. All of them work well for building GCC 4.8.2.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- I guess for start, it would be nice to see backtrace from the debugger about where the segfault and/or abort happened.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #9 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Jakub Jelinek from comment #8) I guess for start, it would be nice to see backtrace from the debugger about where the segfault and/or abort happened. See attachment 3.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #10 from Denis Excoffier g...@denis-excoffier.org --- Created attachment 32595 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32595action=edit gdb session catching signal SIGABRT
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to Denis Excoffier from comment #10) Created attachment 32595 [details] gdb session catching signal SIGABRT Thanks for the debug-log. Could you please attach the backtrace starting from the fancy_abort call? (That what you see after up 7). The issue here is that deregister is called without any register object (ob). Therefore is got NULL.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #12 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to Denis Excoffier from comment #10) Created attachment 32595 [details] gdb session catching signal SIGABRT Some comments here: - it might be helpful to install proper debug-information (cygwin1.dbg doesn't match cygwin1.dll) - to ease debugging it might be helpful to translate gcc without optimizations - As side-note: is there by any chance -std=c++11 active on built? The issue seems to be a global-destructor. The issue might be that a) A library doesn't register .eh_frame. Nevertheless tries to destruct it b) There is tried to destruct it more then once. (Maybe try to set a break-point on that function to find if it get called more then once) c) Issue might be to have mixed static/shared version. This could lead to register/deregister-issues too. In general it would be of interest to learn what destructors (by whom) are present in the list called by do_global_dtors (__DTOR_LIST__)
