[Bug bootstrap/60830] New: ICE on bootstrapping on cygwin

[Bug bootstrap/60830] New: ICE on bootstrapping on cygwin

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

            Bug ID: 60830
           Summary: ICE on bootstrapping on cygwin
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc@Denis-Excoffier.org

Installed gcc-4.9.0-RC-20140411 on darwin (Mavericks) with no problem. But:

On Cygwin 1.7.29-2 (+ latests patches), platform=i686-pc-cygwin (Windows XP
SP3, 32 bits), bootstrap stops with:

xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
configure: error: in `/tmp/lcl/tmp/gcc/obj/i686-pc-cygwin/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage2-target-libgcc] Error 1
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2


Indeed, inside /tmp/lcl/tmp/obj/gcc:
% echo "int main() { return 0; }" > foo.c
% cc1 -quiet -o foo.c foo.c
foo.c:1:1: internal compiler error: Aborted
 int main() { return 0; }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
%

The foo.o seems ok. After some investigation, it seems that cc1 receives an
unexpected SIGABRT signal, after the end of main(), and strace confirms the
kill:
% strace -o /tmp/1 cc1 -quiet -o foo.o foo.c
(same messages as above)
% cat /tmp/1
...
 344 4823227 [main] cc1 3768 close: 0 = close(3)
2019 4825246 [main] cc1 3768 set_signal_mask: setmask 0, newmask FFFEFEDK,
mask_bits 0
  23 4825269 [main] cc1 3768 kill0: kill (3768, 6)
  22 4825291 [main] cc1 3768 sig_send: sendsig 0x784, pid 3768, signal 6,
its_me 1
...
%


On the other hand, if foo.c is erroneous, all seems ok:
% echo "it main() { return 0; }" > foo.c
foo.c:1:1: error: unknown type name 'it'
 it main() { return 0; }
 ^
foo.c:1: confused by earlier errors, bailing out
%

I don't know what to do next.

[Bug bootstrap/60830] ICE on bootstrapping on cygwin

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

Denis Excoffier <gcc@Denis-Excoffier.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |i686-pc-cygwin
               Host|                            |i686-pc-cygwin
              Build|                            |i686-pc-cygwin

--- Comment #1 from Denis Excoffier <gcc@Denis-Excoffier.org> ---
Typos:
- 1st cc1 command should read "cc1 -quiet -o foo.o foo.c" instead of "cc1
-quiet -o foo.c foo.c"
- the newmask in strace output is FFFEFEDF and not FFFEFEDK
- the cc1 command is missing when foo.c is erroneous:
cc1 -quiet -o foo.o foo.c

Also, tke kill (xxxx, 6) is also present when foo.c is erroneous.

[Bug bootstrap/60830] ICE on bootstrapping on cygwin

[mikpelinux at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #2 from Mikael Pettersson <mikpelinux at gmail dot com> ---
I'm getting a different error bootstrapping the 4.9.0 RC on Cygwin:

checking for C compiler default output file name... 
configure: error: in `/home/mikpe/objdir/i686-pc-cygwin/libgcc':
configure: error: C compiler cannot create executables
See `config.log' for more details.
Makefile:14037: recipe for target 'configure-stage2-target-libgcc' failed
make[2]: *** [configure-stage2-target-libgcc] Error 77
make[2]: Leaving directory '/home/mikpe/objdir'
Makefile:16771: recipe for target 'stage2-bubble' failed
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory '/home/mikpe/objdir'
Makefile:16974: recipe for target 'bootstrap' failed
make: *** [bootstrap] Error 2

Inspecting i686-pc-cygwin/libgcc/config.log shows a number of failed attempts
to run gcc/xgcc:

xgcc: error: unrecognized command line option '-isystem'
xgcc: error: unrecognized command line option '-v'

which eventually causes configure to give up.

This is with cygwin-1.7.28 (32-bit), Windows 7 (64-bit), Core-i7.

[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin

[rguenth at gcc dot gnu.org]

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

[rguenth at gcc dot gnu.org]

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

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #5 from Denis Excoffier <gcc@Denis-Excoffier.org> ---
Created attachment 32591
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32591&action=edit
top level config.log

[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #6 from Denis Excoffier <gcc@Denis-Excoffier.org> ---
Created attachment 32592
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32592&action=edit
i686-pc-cygwin/libgcc/config.log

[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #7 from Denis Excoffier <gcc@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

[jakub at gcc dot gnu.org]

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

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #9 from Denis Excoffier <gcc@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

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #10 from Denis Excoffier <gcc@Denis-Excoffier.org> ---
Created attachment 32595
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32595&action=edit
gdb session catching signal SIGABRT

[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin

[ktietz at gcc dot gnu.org]

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

[ktietz at gcc dot gnu.org]

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__)

[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #13 from Denis Excoffier <gcc@Denis-Excoffier.org> ---
Created attachment 32600
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32600&action=edit
gdb session stepping until the end

[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #14 from Denis Excoffier <gcc@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

[ktietz at gcc dot gnu.org]

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

[rguenth at gcc dot gnu.org]

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

[ktietz at gcc dot gnu.org]

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

[ktietz at gcc dot gnu.org]

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

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #19 from Denis Excoffier <gcc@Denis-Excoffier.org> ---
Created attachment 32602
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32602&action=edit
discover __DTOR_LIST__

[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #20 from Denis Excoffier <gcc@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

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #21 from Denis Excoffier <gcc@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

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

Denis Excoffier <gcc@Denis-Excoffier.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpelinux at gmail dot com

--- Comment #24 from Denis Excoffier <gcc@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

[ktietz at gcc dot gnu.org]

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

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #26 from Denis Excoffier <gcc@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

[bernd.edlinger at hotmail dot de]

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

[bernd.edlinger at hotmail dot de]

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 18                sub    $0x18,%esp
  401176:       c7 04 24 20 71 47 00    movl   $0x477120,(%esp)
  40117d:       ff 15 50 b4 4c 00       call   *0x4cb450
  401183:       83 ec 04                sub    $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 47    movl   $0x477167,0x4(%esp)
  401196:       00
  401197:       89 04 24                mov    %eax,(%esp)
  40119a:       ff 15 54 b4 4c 00       call   *0x4cb454
  4011a0:       83 ec 08                sub    $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 00    movl   $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             mov    0x1c(%esp),%eax
  472508:       83 c4 28                add    $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                   jmp    4724bc
<___deregister_frame_info_bases+0x6c>
  472516:       8d 76 00                lea    0x0(%esi),%esi
  472519:       8d bc 27 00 00 00 00    lea    0x0(%edi,%eiz,1),%edi

00472520 <___deregister_frame_info>:
  472520:       e9 2b ff ff ff          jmp    472450
<___deregister_frame_info_bases>
  472525:       8d 74 26 00             lea    0x0(%esi,%eiz,1),%esi
  472529:       8d bc 27 00 00 00 00    lea    0x0(%edi,%eiz,1),%edi

[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin

[bernd.edlinger at hotmail dot de]

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 04                sub    $0x4,%esp
  f6:   85 c0                   test   %eax,%eax
  f8:   ba f0 ff ff ff          mov    $0xfffffff0,%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

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #33 from Denis Excoffier <gcc@Denis-Excoffier.org> ---
Created attachment 32651
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32651&action=edit
bootstrap works at least under i686

[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #34 from Denis Excoffier <gcc@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

[bernd.edlinger at hotmail dot de]

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

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #36 from Denis Excoffier <gcc@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

[bernd.edlinger at hotmail dot de]

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

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #38 from Denis Excoffier <gcc@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

[ktietz at gcc dot gnu.org]

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

[bernd.edlinger at hotmail dot de]

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=32652&action=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

[bernd.edlinger at hotmail dot de]

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

[ktietz at gcc dot gnu.org]

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

[bernd.edlinger at hotmail dot de]

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

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #44 from Denis Excoffier <gcc@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

[gcc@Denis-Excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #45 from Denis Excoffier <gcc@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

[mikpelinux at gmail dot com]

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

[ktietz at gcc dot gnu.org]

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

[fanael4 at gmail dot com]

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

[bernd.edlinger at hotmail dot de]

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

[gcc@Denis-Excoffier.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #50 from Denis Excoffier <gcc@Denis-Excoffier.org> ---
gcc-4.9.1-RC-20140710 bootstraps perfectly. Thank you.