https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #50 from Denis Excoffier ---
gcc-4.9.1-RC-20140710 bootstraps perfectly. Thank you.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #49 from Bernd Edlinger ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #48 from Fanael ---
Is revision 209946 an attempt to fix this?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
Kai Tietz changed:
What|Removed |Added
CC||fanael4 at gmail dot com
--- Comment #47 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #46 from Mikael Pettersson ---
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #45 from Denis Excoffier ---
(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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #44 from Denis Excoffier ---
(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 prese
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #43 from Bernd Edlinger ---
(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 presen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #42 from Kai Tietz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #41 from Bernd Edlinger ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #40 from Bernd Edlinger ---
Created attachment 32652
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32652&action=edit
another possible workaround
This is what I am bootstrapping right now.
Looks good so far, it just reached stage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #39 from Kai Tietz ---
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 introd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #38 from Denis Excoffier ---
(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 crtbeg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #37 from Bernd Edlinger ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #36 from Denis Excoffier ---
(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
--disa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #35 from Bernd Edlinger ---
would not using --disable-sjlj-excaptions cause any problems,
maybe a unwanted ABI-Change?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #34 from Denis Excoffier ---
The patch under attachment 32651 seems to make bootstrapping behave better, at
least for i686.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #33 from Denis Excoffier ---
Created attachment 32651
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32651&action=edit
bootstrap works at least under i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #32 from Bernd Edlinger ---
OK,
opened a binutils-bug at: https://sourceware.org/bugzilla/show_bug.cgi?id=16858
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #31 from Kai Tietz ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #30 from Bernd Edlinger ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #29 from Bernd Edlinger ---
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 __de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #27 from Bernd Edlinger ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #26 from Denis Excoffier ---
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,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
Kai Tietz changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
Denis Excoffier changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #22 from Kai Tietz ---
(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 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #21 from Denis Excoffier ---
(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 repo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #20 from Denis Excoffier ---
(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 everyth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #19 from Denis Excoffier ---
Created attachment 32602
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32602&action=edit
discover __DTOR_LIST__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #18 from Kai Tietz ---
Another side-note. You should specify option '--disable-multilib'. this is
pretty essential as cygwin doesn't support it right now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #17 from Kai Tietz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
Richard Biener changed:
What|Removed |Added
CC||cgf at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #15 from Kai Tietz ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #14 from Denis Excoffier ---
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_exi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #13 from Denis Excoffier ---
Created attachment 32600
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32600&action=edit
gdb session stepping until the end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #12 from Kai Tietz ---
(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.db
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #11 from Kai Tietz ---
(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_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #10 from Denis Excoffier ---
Created attachment 32595
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32595&action=edit
gdb session catching signal SIGABRT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #9 from Denis Excoffier ---
(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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #7 from Denis Excoffier ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #6 from Denis Excoffier ---
Created attachment 32592
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32592&action=edit
i686-pc-cygwin/libgcc/config.log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #5 from Denis Excoffier ---
Created attachment 32591
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32591&action=edit
top level config.log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #4 from Richard Biener ---
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)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
Richard Biener changed:
What|Removed |Added
Keywords||build
Priority|P3
47 matches
Mail list logo
