Bug 63534

Summary: [5 Regression] Bootstrap failure on x86_64/i686-linux
Product: gcc Reporter: Jakub Jelinek <jakub>
Component: targetAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: areg.melikadamyan, astrange+gcc, evstupac, fxcoudert, garyfunck, howarth.at.gcc.testresults, iains, ian, izamyatin, jeffreyalaw, kyukhin, law, mrs, nenad, PHHargrove, ro, vmakarov
Priority: P3 Keywords: ice-on-valid-code, wrong-code
Version: 5.0   
Target Milestone: 5.0   
See Also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87479
Host: Target: x86_64-*-*, i?86-*-*
Build: Known to work:
Known to fail: Last reconfirmed: 2014-10-14 00:00:00
Bug Depends on:    
Bug Blocks: 63773    
Attachments: Compressed tar of the files produced with -fdump-rtl-all
patch to fix darwin bootstrap
patch disabling just nonlocal_goto_receiver split
asm and .i
RTL dumps
Fix SET_GOT delete
patch includes 3 patches fixing darwin bootstrap
patch disabling nonlocal goto receiver and fixing setjmp receiver

Description Jakub Jelinek 2014-10-14 12:31:00 UTC
r216154 broke bootstrap on x86_64-linux and i686-linux for me, pretty much everything in libgo ICEs, including as simple testcases as:
void foo (void) {}
with -m32 -fsplit-stack -fpic (with or without -O?).
Seems the pro_and_epilogue pass adds insn like:
(insn 14 13 15 3 (set (reg:SI 3 bx)
        (reg:SI 83)) g2.i:3 90 {*movsi_internal}
     (nil))
before a call to __morestack added during the prologue expansion, which of course isn't right, this is after reload and using a pseudo is not allowed.

Also, looking at a simple testcase like:
void foo (void) { bar (); bar (); }
I see wrong-code for -m32 -O2 -fpic -p:
there is
call    *mcount@GOT(%ebx)
before set_got is invoked, so if e.g. the routine is called from executable,
where %ebx can contain pretty much anything, it will crash, or if it is called
from a different shared library, it will access unrelated pointer in that other shared library's got rather than current library's got.

And lastly, I'm seeing on the same testcase significant code quality regression
with just -m32 -O2 -fpic:
        .cfi_startproc
-       pushl   %ebx
+       pushl   %esi
        .cfi_def_cfa_offset 8
-       .cfi_offset 3, -8
-       call    __x86.get_pc_thunk.bx
-       addl    $_GLOBAL_OFFSET_TABLE_, %ebx
-       subl    $8, %esp
+       .cfi_offset 6, -8
+       pushl   %ebx
+       .cfi_def_cfa_offset 12
+       .cfi_offset 3, -12
+       call    __x86.get_pc_thunk.si
+       addl    $_GLOBAL_OFFSET_TABLE_, %esi
+       subl    $4, %esp
        .cfi_def_cfa_offset 16
+       movl    %esi, %ebx
        call    bar@PLT
        call    bar@PLT
-       addl    $8, %esp
-       .cfi_def_cfa_offset 8
+       addl    $4, %esp
+       .cfi_def_cfa_offset 12
        popl    %ebx
        .cfi_restore 3
+       .cfi_def_cfa_offset 8
+       popl    %esi
+       .cfi_restore 6
        .cfi_def_cfa_offset 4
        ret
       .cfi_endproc

Here, the register allocator makes a bad decision (load the got into %esi rather than %ebx, both are call saved registers, but we need it in %ebx), and nothing after LRA fixes it up (postreload, etc.).

Can the problematic commit be reverted and all these issues analyzed and fixed before it is reapplied?
Comment 1 Richard Biener 2014-10-14 12:46:18 UTC
It sounds like it would work fine for leaf functions though (really leafs,
accounting for things like __morestack or _mcount calls).

Confirmed btw.
Comment 2 Stupachenko Evgeny 2014-10-14 13:20:28 UTC
Before the changes there were potential bug as morestack call was emitted with dependency on ebx (which was not set):

(call_insn 28 27 29 3 (call (mem:QI (symbol_ref:SI ("__morestack")) [0  S1 A8])
        (const_int 4 [0x4])) ../../../../gcc/libgo/runtime/go-assert.c:15 -1
     (nil) 
    (expr_list (use (reg:SI 3 bx))
        (nil))) 

Treating morestack as SYMBOL_FLAG_LOCAL resolves the issue.

The following patch should fix go bootstrap:
(bootstaped with --enable-languages=c,c++,fortran,lto,go)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a3ca2ed..6235c4f 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -11999,7 +11999,10 @@ ix86_expand_split_stack_prologue (void)
                    REG_BR_PROB_BASE - REG_BR_PROB_BASE / 100);
 
   if (split_stack_fn == NULL_RTX)
-    split_stack_fn = gen_rtx_SYMBOL_REF (Pmode, "__morestack");
+    {
+      split_stack_fn = gen_rtx_SYMBOL_REF (Pmode, "__morestack");
+      SYMBOL_REF_FLAGS (split_stack_fn) |= SYMBOL_FLAG_LOCAL;
+    }
   fn = split_stack_fn;
 
   /* Get more stack space.  We pass in the desired stack space and the
@@ -12044,9 +12047,11 @@ ix86_expand_split_stack_prologue (void)
          gcc_assert ((args_size & 0xffffffff) == args_size);
 
          if (split_stack_fn_large == NULL_RTX)
-           split_stack_fn_large =
-             gen_rtx_SYMBOL_REF (Pmode, "__morestack_large_model");
-
+           {
+             split_stack_fn_large =
+               gen_rtx_SYMBOL_REF (Pmode, "__morestack_large_model");
+             SYMBOL_REF_FLAGS (split_stack_fn_large) |= SYMBOL_FLAG_LOCAL;
+           }
          if (ix86_cmodel == CM_LARGE_PIC)
            {
              rtx_code_label *label;
Comment 3 Jakub Jelinek 2014-10-14 13:49:59 UTC
For -fsplit-stack you are right, __morestack seems to have hidden visibility, so even if gcc emits call __morestack@plt, the linker should transform that into
a direct call __morestack which doesn't need %ebx set up.

Profiling -fpic code would still remain broken though.
Comment 4 Stupachenko Evgeny 2014-10-14 14:20:04 UTC
Profiling implementation has hard coded "%ebx" use.
There are at least 2 quick solutions to resolve this:

1. Disable the changes for PIC profiling

Lead to different behavior with and without profiling of code with EBX asm insertions. However could be applied as temporary solution as there are no EBX asm insertions right now.

2.
print:
  push %ebx
  call    __x86.get_pc_thunk.bx
  addl    $_GLOBAL_OFFSET_TABLE_, %ebx
  
and pop %ebx at the end

Here:
  else if (flag_pic)
    {
#ifndef NO_PROFILE_COUNTERS
      fprintf (file, "\tleal\t%sP%d@GOTOFF(%%ebx),%%" PROFILE_COUNT_REGISTER "\n",
               LPREFIX, labelno);
#endif
      fprintf (file, "1:\tcall\t*%s@GOT(%%ebx)\n", mcount_name);
    }

Lower profiling performance in PIC mode.

I vote for the second solution and can prepare patch for this.
Comment 5 Jakub Jelinek 2014-10-14 14:56:07 UTC
Double set_got doesn't make sense, if you want to keep the current model, I'd emit a set_got insn forced into %ebx before the mcount call in the prologue and see if early after the prologue isn't a set_got insn, if there is, see if %ebx isn't clobbered in between the second set_got and end of prologue (or the reg in that second set_got), and if it isn't, just replace the second set_got with a move from %ebx to the reg used there (or, if %ebx is clobbered and the second reg isn't, move in the prologue into that register).  Keep the double set_got only in uncommon case where you don't find it or both regs are clobbered early.
Comment 6 iverbin 2014-10-14 16:27:29 UTC
Author: iverbin
Date: Tue Oct 14 16:26:57 2014
New Revision: 216208

URL: https://gcc.gnu.org/viewcvs?rev=216208&root=gcc&view=rev
Log:
	PR target/63534
gcc/
	* config/i386/i386.c (ix86_expand_split_stack_prologue): Make
	__morestack local.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
Comment 7 Jeffrey A. Law 2014-10-14 17:18:20 UTC
I'd strongly recommend against option #1 to deal with PIC vs profiling.  We don't want to have two distinct implementations for PIC support in 32 bit mode.

I've got no strong opinions on Jakub's proposal, or emitting a second set_got after the profiling bits.
Comment 8 Jakub Jelinek 2014-10-15 07:31:23 UTC
For -pg, at least for 32-bit -fpic, one way to handle this would be
for !targetm.profile_before_prologue () && crtl->profile in ix86_init_pic_reg
instead of emitting set_got into the pic_offset_table_rtx emit set_got into %ebx
hard reg and then copy %ebx to the pic_offset_table_rtx (to strongly hint RA that it better should allocate the pic register at the start of the function
to %ebx).  And then, when emitting prologue, see if the function doesn't start
with set_got insn (after optional notes) loading into %ebx, and if it does,
move the set_got insn right before the NOTE_INSN_PROLOGUE_END (on which final.c
emits the _mcount call).  That way, there will be just a single set_got, not two.  If you don't find it for some reason (e.g. function that doesn't use PIC register otherwise, or something unexpected happened), make sure you treat %ebx
as clobbered in the prologue and emit the set_got into %ebx directly right before NOTE_INSN_PROLOGUE_END.  For -m64 -fpic -mcmodel=large -pg this will be harder, as init_pic_reg emits multiple instructions.
Comment 9 Dominique d'Humieres 2014-10-15 08:22:31 UTC
r216154 broke bootstrap on x86_64-apple-darwin13 too while building libstdc++-v3:

libtool: compile:  /opt/gcc/p_build/./gcc/xgcc -shared-libgcc -B/opt/gcc/p_build/./gcc -nostdinc++ -L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/src -L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/src/.libs -L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/libsupc++/.libs -B/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/bin/ -B/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/lib/ -isystem /opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/include -isystem /opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/sys-include -m32 -I/opt/gcc/p_work/libstdc++-v3/../libgcc -I/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/include/x86_64-apple-darwin13.4.0 -I/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/include -I/opt/gcc/p_work/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -frandom-seed=atexit_thread.lo -g -O2 -m32 -std=gnu++11 -c ../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc  -fno-common -DPIC -D_GLIBCXX_SHARED -o atexit_thread.o
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc: In function 'void {anonymous}::key_init()':
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc:111:3: internal compiler error: in cselib_invalidate_regno, at cselib.c:2146
   }
   ^

../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc:111:3: internal compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1plus)
Comment 10 Stupachenko Evgeny 2014-10-15 16:07:19 UTC
(In reply to Jakub Jelinek from comment #8)
> For -pg, at least for 32-bit -fpic, one way to handle this would be
> for !targetm.profile_before_prologue () && crtl->profile in ix86_init_pic_reg
> instead of emitting set_got into the pic_offset_table_rtx emit set_got into
> %ebx
> hard reg and then copy %ebx to the pic_offset_table_rtx (to strongly hint RA
> that it better should allocate the pic register at the start of the function
> to %ebx).  And then, when emitting prologue, see if the function doesn't
> start
> with set_got insn (after optional notes) loading into %ebx, and if it does,
> move the set_got insn right before the NOTE_INSN_PROLOGUE_END (on which
> final.c
> emits the _mcount call).  That way, there will be just a single set_got, not
> two.  If you don't find it for some reason (e.g. function that doesn't use
> PIC register otherwise, or something unexpected happened), make sure you
> treat %ebx
> as clobbered in the prologue and emit the set_got into %ebx directly right
> before NOTE_INSN_PROLOGUE_END.  For -m64 -fpic -mcmodel=large -pg this will
> be harder, as init_pic_reg emits multiple instructions.

Sounds reasonable. I also don't like 2 set_got one-by-one. However, we should ask Vladimir on how we can force RA allocate pseudo GOT on %ebx. I expect there should be an easier way to do this. And we should refer %ebx for pseudo GOT register in all 32bit cases.
Right now we can "emit second set_got" and file a bug on potential performance improvement in RA.

I've measured spec2000 o2 -fporfile-generate execution on train data on Corei7.
Even with additional set_got there is:
CINT +0,2
CFP  +1,4
compared to a compiler before "enabling ebx".
Comment 11 Vladimir Makarov 2014-10-15 16:18:18 UTC
(In reply to Stupachenko Evgeny from comment #10)
> 
> Sounds reasonable. I also don't like 2 set_got one-by-one. However, we
> should ask Vladimir on how we can force RA allocate pseudo GOT on %ebx. I
> expect there should be an easier way to do this. And we should refer %ebx
> for pseudo GOT register in all 32bit cases.
> Right now we can "emit second set_got" and file a bug on potential
> performance improvement in RA.
> 

The modification to IRA to get ebx for GOT pseudo could be not difficult.  However it will not work.  When I worked on modification RA for this project, I saw that RA gets info that ebx is clobbered by calls.  I already wrote about this to Ilya.  So this problem should be solved first.  When the problem is solved, GOT pseudo will get the best hard reg (most probably ebx) and we will not need to do modification to RA to assign specifically ebx to GOT pseudo.


> I've measured spec2000 o2 -fporfile-generate execution on train data on
> Corei7.
> Even with additional set_got there is:
> CINT +0,2
> CFP  +1,4
> compared to a compiler before "enabling ebx".
Comment 12 Stupachenko Evgeny 2014-10-15 16:30:24 UTC
(In reply to Dominique d'Humieres from comment #9)
> r216154 broke bootstrap on x86_64-apple-darwin13 too while building
> libstdc++-v3:
> 
> libtool: compile:  /opt/gcc/p_build/./gcc/xgcc -shared-libgcc
> -B/opt/gcc/p_build/./gcc -nostdinc++
> -L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/src
> -L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/src/.libs
> -L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/libsupc++/.
> libs -B/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/bin/
> -B/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/lib/ -isystem
> /opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/include -isystem
> /opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/sys-include -m32
> -I/opt/gcc/p_work/libstdc++-v3/../libgcc
> -I/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/include/
> x86_64-apple-darwin13.4.0
> -I/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/include
> -I/opt/gcc/p_work/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
> -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
> -fdiagnostics-show-location=once -fvisibility-inlines-hidden
> -ffunction-sections -fdata-sections -frandom-seed=atexit_thread.lo -g -O2
> -m32 -std=gnu++11 -c
> ../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc  -fno-common
> -DPIC -D_GLIBCXX_SHARED -o atexit_thread.o
> ../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc: In function
> 'void {anonymous}::key_init()':
> ../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc:111:3:
> internal compiler error: in cselib_invalidate_regno, at cselib.c:2146
>    }
>    ^
> 
> ../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc:111:3:
> internal compiler error: Abort trap: 6
> xgcc: internal compiler error: Abort trap: 6 (program cc1plus)

We are trying to reproduce the issue. Can you please send me/attach rtl dumps on the fail?
Comment 13 Dominique d'Humieres 2014-10-15 18:13:53 UTC
Created attachment 33728 [details]
Compressed tar of the files produced with -fdump-rtl-all
Comment 14 Igor Zamyatin 2014-10-15 19:58:00 UTC
Thanks!

That's define_insn_and_split "nonlocal_goto_receiver" where the issue comes from.
Seems now we need to handle this split somewhat similar to the second approach in solving of the profiling issue
Comment 15 Stupachenko Evgeny 2014-10-16 11:32:38 UTC
Created attachment 33733 [details]
patch to fix darwin bootstrap

With pseudo GOT register we don't need to set GOT register after any jump, and therefore don't need "nonlocal_goto_receiver" and "builtin_setjmp_receiver" for i386.

Please try attached patch (just removing "nonlocal_goto_receiver" and "builtin_setjmp_receiver" from i386.md).
Comment 16 Dominique d'Humieres 2014-10-16 12:33:23 UTC
> Created attachment 33733 [details]
> patch to fix darwin bootstrap
>
> With pseudo GOT register we don't need to set GOT register after any jump,
> and therefore don't need "nonlocal_goto_receiver" and "builtin_setjmp_receiver"
> for i386.
>
> Please try attached patch (just removing "nonlocal_goto_receiver" and 
> "builtin_setjmp_receiver" from i386.md).

With the patch bootstrap fails with

libtool: link:  /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/src/.libs -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/libsupc++/.libs -B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.4.0/bin/ -B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.4.0/lib/ -isystem /opt/gcc/gcc4.10w/x86_64-apple-darwin13.4.0/include -isystem /opt/gcc/gcc4.10w/x86_64-apple-darwin13.4.0/sys-include    -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libstdc++.6.dylib  .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o   -Wl,-force_load,../libsupc++/.libs/libsupc++convenience.a -Wl,-force_load,../src/c++98/.libs/libc++98convenience.a -Wl,-force_load,../src/c++11/.libs/libc++11convenience.a  -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/libsupc++/.libs -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/src/.libs -lm  -Wl,-single_module -Wl,-exported_symbols_list -Wl,libstdc++-symbols.explist   -install_name  /opt/gcc/gcc4.10w/lib/libstdc++.6.dylib -compatibility_version 7 -current_version 7.21 -Wl,-single_module
ld: warning: cannot export hidden symbol __cxxabiv1::__pbase_type_info::__pointer_catch(__cxxabiv1::__pbase_type_info const*, void**, unsigned int) const from ../libsupc++/.libs/libsupc++convenience.a(pbase_type_info.o)
ld: warning: cannot export hidden symbol std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf() from ../src/c++98/.libs/libc++98convenience.a(complex_io.o)
ld: warning: cannot export hidden symbol std::basic_stringbuf<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_stringbuf() from ../src/c++98/.libs/libc++98convenience.a(complex_io.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_narrow(char, char) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_narrow(char const*, char const*, char, char*) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char const*, char const*, char*) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o)
ld: warning: cannot export hidden symbol construction vtable for std::basic_istream<char, std::char_traits<char> >-in-std::istrstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o)
ld: warning: cannot export hidden symbol construction vtable for std::basic_ostream<char, std::char_traits<char> >-in-std::ostrstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o)
ld: warning: cannot export hidden symbol construction vtable for std::basic_istream<char, std::char_traits<char> >-in-std::strstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o)
ld: warning: cannot export hidden symbol construction vtable for std::basic_iostream<char, std::char_traits<char> >-in-std::strstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_narrow(char, char) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_narrow(char const*, char const*, char, char*) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char const*, char const*, char*) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char) const from ../src/c++98/.libs/libc++98convenience.a(locale-inst.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_narrow(char, char) const from ../src/c++98/.libs/libc++98convenience.a(locale-inst.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char const*, char const*, char*) const from ../src/c++98/.libs/libc++98convenience.a(locale-inst.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char) const from ../src/c++98/.libs/libc++98convenience.a(misc-inst.o)
ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::~stdio_sync_filebuf() from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o)
ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::~stdio_sync_filebuf() from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o)
ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<wchar_t, std::char_traits<wchar_t> >::~stdio_sync_filebuf() from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o)
ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<wchar_t, std::char_traits<wchar_t> >::~stdio_sync_filebuf() from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o)
ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<wchar_t, std::char_traits<wchar_t> >::xsgetn(wchar_t*, long) from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o)
ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<wchar_t, std::char_traits<wchar_t> >::xsputn(wchar_t const*, long) from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o)
ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::xsputn(char const*, long) from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o)
ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::xsgetn(char*, long) from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char) const from ../src/c++11/.libs/libc++11convenience.a(ios-inst.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_narrow(char, char) const from ../src/c++11/.libs/libc++11convenience.a(ios-inst.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char) const from ../src/c++11/.libs/libc++11convenience.a(istream-inst.o)
ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char) const from ../src/c++11/.libs/libc++11convenience.a(ostream-inst.o)
ld: warning: cannot export hidden symbol std::basic_stringbuf<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_stringbuf() from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o)
ld: warning: cannot export hidden symbol std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf() from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o)
ld: warning: cannot export hidden symbol std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf() from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o)
ld: warning: cannot export hidden symbol std::basic_stringbuf<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_stringbuf() from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o)
ld: warning: cannot export hidden symbol construction vtable for std::basic_istream<char, std::char_traits<char> >-in-std::basic_istringstream<char, std::char_traits<char>, std::allocator<char> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o)
ld: warning: cannot export hidden symbol construction vtable for std::basic_ostream<char, std::char_traits<char> >-in-std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o)
ld: warning: cannot export hidden symbol construction vtable for std::basic_ostream<char, std::char_traits<char> >-in-std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o)
ld: warning: cannot export hidden symbol construction vtable for std::basic_istream<char, std::char_traits<char> >-in-std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o)
ld: warning: cannot export hidden symbol construction vtable for std::basic_iostream<char, std::char_traits<char> >-in-std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o)
ld: warning: cannot export hidden symbol construction vtable for std::basic_istream<wchar_t, std::char_traits<wchar_t> >-in-std::basic_istringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o)
ld: warning: cannot export hidden symbol construction vtable for std::basic_ostream<wchar_t, std::char_traits<wchar_t> >-in-std::basic_ostringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o)
ld: warning: cannot export hidden symbol construction vtable for std::basic_ostream<wchar_t, std::char_traits<wchar_t> >-in-std::basic_stringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o)
ld: warning: cannot export hidden symbol construction vtable for std::basic_istream<wchar_t, std::char_traits<wchar_t> >-in-std::basic_stringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o)
ld: warning: cannot export hidden symbol construction vtable for std::basic_iostream<wchar_t, std::char_traits<wchar_t> >-in-std::basic_stringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o)
ld: illegal text reloc in 'std::strstream::strstream()' to 'construction vtable for std::basic_ostream<char, std::char_traits<char> >-in-std::strstream' for architecture x86_64
collect2: error: ld returned 1 exit status
Comment 17 Iain Sandoe 2014-10-16 14:40:29 UTC
(In reply to Dominique d'Humieres from comment #16)
> > Created attachment 33733 [details]
> > patch to fix darwin bootstrap
> >
> > With pseudo GOT register we don't need to set GOT register after any jump,
> > and therefore don't need "nonlocal_goto_receiver" and "builtin_setjmp_receiver"
> > for i386.
> >
> > Please try attached patch (just removing "nonlocal_goto_receiver" and 
> > "builtin_setjmp_receiver" from i386.md).
> 
> With the patch bootstrap fails with

> ld: illegal text reloc in 'std::strstream::strstream()' to 'construction
> vtable for std::basic_ostream<char, std::char_traits<char>
> >-in-std::strstream' for architecture x86_64
> collect2: error: ld returned 1 exit status

It's possible that this ^ is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888
(investigating)… once we get past this .. 

I suppose someone should try a bootstrap on i686-darwin .. will try to fit that in later.
Comment 18 Stupachenko Evgeny 2014-10-16 15:10:58 UTC
Created attachment 33736 [details]
patch disabling just nonlocal_goto_receiver split

Am I correct that this is 64 bits library link failed?
If so it is really strange, because the patch removes patterns under "!TARGET_64BIT".

Can you please try more conservative patch disabling just nonlocal_goto_receiver split bootstrapping it from scratch?
Comment 19 Dominique d'Humieres 2014-10-16 15:33:04 UTC
> Can you please try more conservative patch disabling just
> nonlocal_goto_receiver split bootstrapping it from scratch?

It still get the same error/warnings as in comment 16 with the conservative patch.
Comment 20 Iain Sandoe 2014-10-16 19:06:55 UTC
so I rewound to r216156 and made the change to i386.md (removed the receiver and nonlocal label stuff).

So, that succeeds in getting to stage #3 and then fails building [m32] target libs which is much more likley to be fallout from these changes. (Transcript below)

====

Note that there is some PIC register handling in common code for darwin (config/darwin.c) - is it possible that a required change has been missed?

====

<meanwhile, I'll try and track down what appears to be a second bootstrap crasher in the same window>

=====

libtool: compile:  /GCC/ml/gcc-trunk-appleas/./gcc/xgcc -B/GCC/ml/gcc-trunk-appleas/./gcc/ -B/compilers/gcc-trunk/x86_64-apple-darwin12/bin/ -B/compilers/gcc-trunk/x86_64-apple-darwin12/lib/ -isystem /compilers/gcc-trunk/x86_64-apple-darwin12/include -isystem /compilers/gcc-trunk/x86_64-apple-darwin12/sys-include -DHAVE_CONFIG_H -I. -I/GCC/gcc-trunk/libquadmath -I /GCC/gcc-trunk/libquadmath/../include -g -O2 -m32 -MT math/frexpq.lo -MD -MP -MF math/.deps/frexpq.Tpo -c /GCC/gcc-trunk/libquadmath/math/frexpq.c  -fno-common -DPIC -o math/.libs/frexpq.o
/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:68:non-relocatable subtraction expression, "LC0" minus "L1$pb"
/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:68:symbol: "L1$pb" can't be undefined in a subtraction expression
/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:unknown:Undefined local symbol L1$pb
make[6]: *** [math/frexpq.lo] Error 1
make[5]: *** [all] Error 2

====
Comment 21 Igor Zamyatin 2014-10-16 20:59:26 UTC
(In reply to Iain Sandoe from comment #20)
> 
> libtool: compile:  /GCC/ml/gcc-trunk-appleas/./gcc/xgcc
> -B/GCC/ml/gcc-trunk-appleas/./gcc/
> -B/compilers/gcc-trunk/x86_64-apple-darwin12/bin/
> -B/compilers/gcc-trunk/x86_64-apple-darwin12/lib/ -isystem
> /compilers/gcc-trunk/x86_64-apple-darwin12/include -isystem
> /compilers/gcc-trunk/x86_64-apple-darwin12/sys-include -DHAVE_CONFIG_H -I.
> -I/GCC/gcc-trunk/libquadmath -I /GCC/gcc-trunk/libquadmath/../include -g -O2
> -m32 -MT math/frexpq.lo -MD -MP -MF math/.deps/frexpq.Tpo -c
> /GCC/gcc-trunk/libquadmath/math/frexpq.c  -fno-common -DPIC -o
> math/.libs/frexpq.o
> /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:68:non-
> relocatable subtraction expression, "LC0" minus "L1$pb"
> /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:68:symbol:
> "L1$pb" can't be undefined in a subtraction expression
> /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:unknown:
> Undefined local symbol L1$pb
> make[6]: *** [math/frexpq.lo] Error 1
> make[5]: *** [all] Error 2
> 
> ====

Can we look at the rtl dumps and probably asm file?
Comment 22 Iain Sandoe 2014-10-16 22:20:06 UTC
(In reply to Iain Sandoe from comment #17)
> (In reply to Dominique d'Humieres from comment #16)
> > > Created attachment 33733 [details]
> > > patch to fix darwin bootstrap
> > >
> > > With pseudo GOT register we don't need to set GOT register after any jump,
> > > and therefore don't need "nonlocal_goto_receiver" and "builtin_setjmp_receiver"
> > > for i386.
> > >
> > > Please try attached patch (just removing "nonlocal_goto_receiver" and 
> > > "builtin_setjmp_receiver" from i386.md).
> > 
> > With the patch bootstrap fails with
> 
> > ld: illegal text reloc in 'std::strstream::strstream()' to 'construction
> > vtable for std::basic_ostream<char, std::char_traits<char>
> > >-in-std::strstream' for architecture x86_64
> > collect2: error: ld returned 1 exit status

This fail above ^ is caused by r216305 (which seems to be being investigated elsewhere)
Comment 23 Iain Sandoe 2014-10-16 23:54:28 UTC
Created attachment 33741 [details]
asm and .i

I built 216304+removing the two sections in i386.md.

A stage 1 compiler built with -O0 -g is suffient to show the issue - so it's possible to debug without needing a Darwin box.

Attached the .i and .s files for the first file to fail from doing

make all-target-libquadmath at stage #1.

As you will see there is no picbase being output for the function (there should be a call to a thunk and a label L1$pb0).

Will sort out the tree dumps tomorrow ..
Comment 24 Stupachenko Evgeny 2014-10-17 12:08:23 UTC
We are able to reproduce the bug.
SET_GOT removed as the only use of GOT register was hidden by:
(insn 37 34 38 6 (set (mem:TF (pre_dec:SI (reg/f:SI 7 sp)) [0  S16 A8]) 
        (const_double:TF 2.0769187434139310514121985316880384e+34 [0x0.8p+115])) frexpq.c:1316 121 {*pushtf} 
     (expr_list:REG_ARGS_SIZE (const_int 16 [0x10]) 
        (nil))) 

The solution is not to delete SET_GOT till reload.
Comment 25 Iain Sandoe 2014-10-17 12:55:16 UTC
Created attachment 33746 [details]
RTL dumps

This is trunk rev 216304 + change to i386.md.
-O2 -m32.

For O0/1 the output is created OK.
For O2 the picbase is being optimised away.

(this was with a stage#1 compiler built -O0 -g3 using a GCC-4.9 bootstrap).
Comment 26 Iain Sandoe 2014-10-17 12:57:30 UTC
(In reply to Stupachenko Evgeny from comment #24)
> We are able to reproduce the bug.
> SET_GOT removed as the only use of GOT register was hidden by:
> (insn 37 34 38 6 (set (mem:TF (pre_dec:SI (reg/f:SI 7 sp)) [0  S16 A8]) 
>         (const_double:TF 2.0769187434139310514121985316880384e+34
> [0x0.8p+115])) frexpq.c:1316 121 {*pushtf} 
>      (expr_list:REG_ARGS_SIZE (const_int 16 [0x10]) 
>         (nil))) 
> 
> The solution is not to delete SET_GOT till reload.

cool! 
sorry I didn't see that before making my post…
.. are you working up a patch?
Comment 27 Stupachenko Evgeny 2014-10-17 13:48:27 UTC
Created attachment 33748 [details]
Fix SET_GOT delete

The patch fix the problem.
Can you please run darwin bootstrap with it and previous (receivers patterns delete)?
x86 is in progress.
Comment 28 Dominique d'Humieres 2014-10-17 15:06:07 UTC
With the patches in comments 15 and 27 applied on top of r216304, bootstrap stil fails with

libtool: compile:  /opt/gcc/p_build/./gcc/xgcc -B/opt/gcc/p_build/./gcc/ -B/opt/gcc/gcc4.10p-216304p1/x86_64-apple-darwin14.0.0/bin/ -B/opt/gcc/gcc4.10p-216304p1/x86_64-apple-darwin14.0.0/lib/ -isystem /opt/gcc/gcc4.10p-216304p1/x86_64-apple-darwin14.0.0/include -isystem /opt/gcc/gcc4.10p-216304p1/x86_64-apple-darwin14.0.0/sys-include -DHAVE_CONFIG_H -I. -I../../../../p_work/libquadmath -I ../../../../p_work/libquadmath/../include -g -O2 -m32 -MT math/remainderq.lo -MD -MP -MF math/.deps/remainderq.Tpo -c ../../../../p_work/libquadmath/math/remainderq.c  -fno-common -DPIC -o math/.libs/remainderq.o
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//cclKy0QW.s:388:non-relocatable subtraction expression, "LC1" minus "L1$pb"
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//cclKy0QW.s:388:symbol: "L1$pb" can't be undefined in a subtraction expression
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//cclKy0QW.s:unknown:Undefined local symbol L1$pb
Comment 29 Jeffrey A. Law 2014-10-17 16:56:19 UTC
I thought we had already dealt with the "hidden" GOT usages that show up during reload...  Is it IRA that's removing the SET_GOT?
Comment 30 Iain Sandoe 2014-10-17 17:05:52 UTC
FWIW, I built a stage #1 with fortran, objc and ada enabled.

libgcc, libstdc++v3, libgomp, libobjc and libada build.

libgfortran & libquadmath fail (errors as per Dominique's post).
Comment 31 Stupachenko Evgeny 2014-10-20 10:07:41 UTC
(In reply to Jeffrey A. Law from comment #29)
> I thought we had already dealt with the "hidden" GOT usages that show up
> during reload...  Is it IRA that's removing the SET_GOT?

That is not EQUIV related case. SET_GOT is removed by CSE called at IRA.
Here we have insn that don't use GOT register implicitly:

(insn 37 34 38 6 (set (mem:TF (pre_dec:SI (reg/f:SI 7 sp)) [0  S16 A8]) 
        (const_double:TF 2.0769187434139310514121985316880384e+34 [0x0.8p+115])) frexpq.c:1316 121 {*pushtf} 
     (expr_list:REG_ARGS_SIZE (const_int 16 [0x10]) 
        (nil)))

It appears that there are no other insns using GOT or calls.
Therefore CSE absolutely correct in removing SET_GOT.
Comment 32 Stupachenko Evgeny 2014-10-20 10:17:18 UTC
(In reply to Iain Sandoe from comment #30)
> FWIW, I built a stage #1 with fortran, objc and ada enabled.
> 
> libgcc, libstdc++v3, libgomp, libobjc and libada build.
> 
> libgfortran & libquadmath fail (errors as per Dominique's post).

We got MAC and are setting up GCC build there to be able to reproduce all issues and publish patch fixing whole bootstrap.
Comment 33 Stupachenko Evgeny 2014-10-21 16:12:21 UTC
Created attachment 33769 [details]
patch includes 3 patches fixing darwin bootstrap

It looks like data constant LC0 generated from pushtf not treated as GOT dependent or treated as unchanged (assuming it depends on unchanged ebx) at darwin reload pass.

RELOAD PASS:

(insn/f 106 8 2 2 (parallel [ 
            (set (reg:SI 0 ax [98]) 
                (unspec:SI [ 
                        (const_int 0 [0]) 
                    ] UNSPEC_SET_GOT)) 
            (clobber (reg:CC 17 flags)) 
        ]) 679 {set_got} 
     (expr_list:REG_EQUIV (unspec:SI [ 
                (const_int 0 [0]) 
            ] UNSPEC_SET_GOT) 
        (expr_list:REG_CFA_FLUSH_QUEUE (nil) 
            (nil)))) 

.....
For some reason on darwin AX is set here without spilling previous value.
On Linux AX is spilled and filled in appropriate place.

After that while reading LC0 on darwin we use incorrect GOT register.

(insn 115 41 116 6 (set (reg:SI 0 ax [128]) 
        (plus:SI (reg:SI 0 ax [98]) 
            (const:SI (unspec:SI [
                        (symbol_ref/u:SI ("*LC0") [flags 0x2])
                    ] UNSPEC_MACHOPIC_OFFSET)))) frexpq.c:1319 213 {*leasi}
     (expr_list:REG_EQUAL (symbol_ref/u:SI ("*LC0") [flags 0x2])
        (nil))) 
...

Do you have any ideas where darwin can treat the LC0 symbol so?

Please try attached patch (includes all fixes) moving pushtf split earlier. The bootstrap (c,c++,fortran,lto) on MAC passed (patch applied on top of 216304).
Comment 34 Dominique d'Humieres 2014-10-21 17:09:23 UTC
Bootstrap completed with the patch in comment 33 applied on top of r216304 and configured with: 

../p_work/configure --prefix=/opt/gcc/gcc4.10p-216304p1 --enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp --with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto --enable-plugin --with-arch=core2 --with-cpu=core2

Thanks for the patch.
Comment 35 Iain Sandoe 2014-10-22 20:22:54 UTC
(In reply to Stupachenko Evgeny from comment #33)
> Created attachment 33769 [details]
> patch includes 3 patches fixing darwin bootstrap

> Do you have any ideas where darwin can treat the LC0 symbol so?

This deserves a proper answer - but I don't have enough context to give one.
- can you point me at something specific to build or attach the .i and .s file relevant?

Mike - any comments?

> Please try attached patch (includes all fixes) moving pushtf split earlier.
> The bootstrap (c,c++,fortran,lto) on MAC passed (patch applied on top of
> 216304).

this worked for me - although we're still hosed by multiple other issues from later commits.
Comment 36 Stupachenko Evgeny 2014-10-22 20:36:18 UTC
(In reply to Iain Sandoe from comment #35)
> (In reply to Stupachenko Evgeny from comment #33)
> > Created attachment 33769 [details]
> > patch includes 3 patches fixing darwin bootstrap
> 
> > Do you have any ideas where darwin can treat the LC0 symbol so?
> 
> This deserves a proper answer - but I don't have enough context to give one.
> - can you point me at something specific to build or attach the .i and .s
> file relevant?

I've created PR63618 and PR63620 with small reproducers.
PR63620 is darwin only issue (note that patch from PR63618 should be applied).

> 
> Mike - any comments?
> 
> > Please try attached patch (includes all fixes) moving pushtf split earlier.
> > The bootstrap (c,c++,fortran,lto) on MAC passed (patch applied on top of
> > 216304).
> 
> this worked for me - although we're still hosed by multiple other issues
> from later commits.
Comment 37 iverbin 2014-10-23 16:52:43 UTC
Author: iverbin
Date: Thu Oct 23 16:52:11 2014
New Revision: 216596

URL: https://gcc.gnu.org/viewcvs?rev=216596&root=gcc&view=rev
Log:
	PR target/63534
	PR target/63618
gcc/
	* cse.c (delete_trivially_dead_insns): Consider PIC register is used
	while it is pseudo.
	* dse.c (deletable_insn_p): Likewise.
gcc/testsuite/
	* gcc.target/i386/pr63618.c: New test.

Added:
    trunk/gcc/testsuite/gcc.target/i386/pr63618.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cse.c
    trunk/gcc/dce.c
    trunk/gcc/testsuite/ChangeLog
Comment 38 Rainer Orth 2014-10-24 14:15:31 UTC
What's currently required to get Darwin/x86 to bootstrap again?  I'm totally lost
in this maze of PRs and patches.

I've just tried r216667 plus the patch from PR 63620 on x86_64-apple-darwin14.0.0 and still run into

ld: illegal text reloc in 'std::strstream::strstream()' to 'construction vtable for std::basic_ostream<char, std::char_traits<char> >-in-std::strstream' for architecture x86_64

when linking stage1 libstdc++.

  Rainer
Comment 39 Stupachenko Evgeny 2014-10-24 14:32:16 UTC
(In reply to Rainer Orth from comment #38)
> What's currently required to get Darwin/x86 to bootstrap again?  I'm totally
> lost
> in this maze of PRs and patches.
> 
> I've just tried r216667 plus the patch from PR 63620 on
> x86_64-apple-darwin14.0.0 and still run into
> 
> ld: illegal text reloc in 'std::strstream::strstream()' to 'construction
> vtable for std::basic_ostream<char, std::char_traits<char>
> >-in-std::strstream' for architecture x86_64
> 
> when linking stage1 libstdc++.
> 
>   Rainer

You should apply patch from comment 15 as well.
It is still under review:
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02482.html
Comment 40 ro@CeBiTec.Uni-Bielefeld.DE 2014-10-24 15:17:14 UTC
> --- Comment #39 from Stupachenko Evgeny <evstupac at gmail dot com> ---
> (In reply to Rainer Orth from comment #38)
[...]
> You should apply patch from comment 15 as well.
> It is still under review:
> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02482.html

Even with this, the illegal text reloc error remains.  May be a Mac OS X
10.10 thing, though?

	Rainer
Comment 41 Stupachenko Evgeny 2014-10-24 15:26:19 UTC
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #40)
> > --- Comment #39 from Stupachenko Evgeny <evstupac at gmail dot com> ---
> > (In reply to Rainer Orth from comment #38)
> [...]
> > You should apply patch from comment 15 as well.
> > It is still under review:
> > https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02482.html
> 
> Even with this, the illegal text reloc error remains.  May be a Mac OS X
> 10.10 thing, though?
> 
> 	Rainer

That should be not "EBX enablig" issue as pointed in comments 17 and 35.
I'm testing bootstrap like in comment 34 and it passed.
Comment 42 ro@CeBiTec.Uni-Bielefeld.DE 2014-10-24 15:53:12 UTC
> --- Comment #41 from Stupachenko Evgeny <evstupac at gmail dot com> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #40)
[...]
> That should be not "EBX enablig" issue as pointed in comments 17 and 35.
> I'm testing bootstrap like in comment 34 and it passed.

Adding --with-arch=core2 --with-cpu=core2 didn't make any difference.

	Rainer
Comment 43 Stupachenko Evgeny 2014-10-24 16:20:42 UTC
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #42)
> > --- Comment #41 from Stupachenko Evgeny <evstupac at gmail dot com> ---
> > (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #40)
> [...]
> > That should be not "EBX enablig" issue as pointed in comments 17 and 35.
> > I'm testing bootstrap like in comment 34 and it passed.
> 
> Adding --with-arch=core2 --with-cpu=core2 didn't make any difference.
> 
> 	Rainer

The core thing in comment 34 is "patch in comment 33 applied on top of r216304".

Most likely after r216304 someone broke darwin bootstrap again.
So to test my changes I use revision r216304 with patch from commnet 33.
Comment 44 Iain Sandoe 2014-10-24 16:28:14 UTC
(In reply to Stupachenko Evgeny from comment #43)
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #42)
> > > --- Comment #41 from Stupachenko Evgeny <evstupac at gmail dot com> ---
> > > (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #40)
> > [...]
> > > That should be not "EBX enablig" issue as pointed in comments 17 and 35.
> > > I'm testing bootstrap like in comment 34 and it passed.
> > 
> > Adding --with-arch=core2 --with-cpu=core2 didn't make any difference.
> > 
> > 	Rainer
> 
> The core thing in comment 34 is "patch in comment 33 applied on top of
> r216304".
> 
> Most likely after r216304 someone broke darwin bootstrap again.
> So to test my changes I use revision r216304 with patch from commnet 33.

there were at one point this week 4 concurrent bootstrap breaks on dariwn.

this PR.
the ipa-icf series
requiring non-weak aliases
and the iconv dep on libcpp.

I don't know how many of those have been fixed so far - but I suspect that not all have.  Unfortunately, not able to be more explict right now.
Comment 45 ro@CeBiTec.Uni-Bielefeld.DE 2014-10-24 16:31:06 UTC
> --- Comment #44 from Iain Sandoe <iains at gcc dot gnu.org> ---
> (In reply to Stupachenko Evgeny from comment #43)
[...]
> there were at one point this week 4 concurrent bootstrap breaks on dariwn.
>
> this PR.
> the ipa-icf series
> requiring non-weak aliases
> and the iconv dep on libcpp.
>
> I don't know how many of those have been fixed so far - but I suspect that not
> all have.  Unfortunately, not able to be more explict right now.

Thanks for the update.  As I said, I'd completely lost track of what's
going on here.

I'm now testing the rev before Evgeny's patch to check if that
bootstraps on 10.10.  If not, we may have yet another issue here.

	Rainer
Comment 46 Jeffrey A. Law 2014-10-24 16:34:16 UTC
Glad I'm not the only one struggling to track everything that's breaking on Darwin!
Comment 47 ro@CeBiTec.Uni-Bielefeld.DE 2014-10-24 16:50:12 UTC
> --- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
[...]
> I'm now testing the rev before Evgeny's patch to check if that
> bootstraps on 10.10.  If not, we may have yet another issue here.

I'm now in stage2 at rev 216153, so there's no 10.10 issue here.

	Rainer
Comment 48 Dominique d'Humieres 2014-10-27 09:58:45 UTC
> --- Comment #44 from Iain Sandoe <iains at gcc dot gnu.org> ---
> (In reply to Stupachenko Evgeny from comment #43)
[...]
> there were at one point this week 4 concurrent bootstrap breaks on dariwn.
>
> this PR.
> the ipa-icf series
> requiring non-weak aliases      <-- this is pr63622
> and the iconv dep on libcpp.    <-- AFAICT this should be fixed now

In addition r216154 breaks a lot of asan tests with -m32: see

https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02834.html
Comment 49 Igor Zamyatin 2014-10-27 20:46:19 UTC
Testing a patch to fix asan failures
Comment 50 Igor Zamyatin 2014-10-28 14:10:46 UTC
> In addition r216154 breaks a lot of asan tests with -m32: see
> 
> https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02834.html

Could you please try following patch?

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 5580ea8..508db5d 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -1715,6 +1715,9 @@ expand_used_vars (void)
-
   init_vars_expansion ();
-
+  if (targetm.use_pseudo_pic_reg ())
+    pic_offset_table_rtx = gen_reg_rtx (Pmode);
+
   hash_map<tree, tree> ssa_name_decls;
   for (i = 0; i < SA.map->num_partitions; i++)
     {
diff --git a/gcc/function.c b/gcc/function.c
index ee229ad..dab691d 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -3464,11 +3464,6 @@ assign_parms (tree fndecl)
-
   fnargs.release ();
-
-  /* Initialize pic_offset_table_rtx with a pseudo register
-     if required.  */
-  if (targetm.use_pseudo_pic_reg ())
-    pic_offset_table_rtx = gen_reg_rtx (Pmode);
-
   /* Output all parameter conversion instructions (possibly including calls)
      now that all parameters have been copied out of hard registers.  */
   emit_insn (all.first_conversion_insn);
Comment 51 Dominique d'Humieres 2014-10-29 22:06:50 UTC
> > In addition r216154 breaks a lot of asan tests with -m32: see
> > 
> > https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02834.html
>
> Could you please try following patch?
>
> diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
> ...

The failures are gone with the patch. Thanks.
Comment 52 Jeffrey A. Law 2014-10-30 03:03:53 UTC
Igor, can you post the patch from c#50 for official review?  Thanks!
Comment 53 Ilya Enkovich 2014-10-31 13:30:40 UTC
Author: ienkovich
Date: Fri Oct 31 13:30:06 2014
New Revision: 216975

URL: https://gcc.gnu.org/viewcvs?rev=216975&root=gcc&view=rev
Log:
gcc/

	PR target/63534
	* config/i386/i386.c (ix86_init_pic_reg): Emit SET_GOT to
	REAL_PIC_OFFSET_TABLE_REGNUM for mcount profiling.
	(ix86_save_reg): Save REAL_PIC_OFFSET_TABLE_REGNUM when profiling
	using mcount in 32bit PIC mode.
	(ix86_elim_entry_set_got): New.
	(ix86_expand_prologue): For the mcount profiling emit new SET_GOT
	in PROLOGUE, delete initial if possible.

gcc/testsuite/

	PR target/63534
	* gcc.target/i386/mcount_pic.c: New.


Added:
    trunk/gcc/testsuite/gcc.target/i386/mcount_pic.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog
Comment 54 Jack Howarth 2014-11-06 22:16:16 UTC
What is the status of this PR? I am finding that current gcc trunk requires https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 in order to avoid the use of alias  on darwin resulting in undefined symbols in libstdc++. However then the error shifts to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c19 which is identical to that reported in Comment 9 here. If I use the patch from https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736&action=diff in this PR, the bootstrap failure shifts to...

/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/xg++ -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc5.0/x86_64-apple-darwin14.0.0/bin/ -nostdinc++ -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs  -I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/include/x86_64-apple-darwin14.0.0  -I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/include  -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/libstdc++-v3/libsupc++ -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs -c   -g -O2  -gtoggle -DIN_GCC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc-5.0-20141106/gcc -I../../gcc-5.0-20141106/gcc/. -I../../gcc-5.0-20141106/gcc/../include -I../../gcc-5.0-20141106/gcc/../libcpp/include -I/sw/include -I/sw/include  -I../../gcc-5.0-20141106/gcc/../libdecnumber -I../../gcc-5.0-20141106/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-5.0-20141106/gcc/../libbacktrace -DCLOOG_INT_GMP -I/sw/include -DCLOOG_INT_GMP -I/sw/include -I/sw/include -o tree-inline.o -MT tree-inline.o -MMD -MP -MF ./.deps/tree-inline.TPo ../../gcc-5.0-20141106/gcc/tree-inline.c
../../gcc-5.0-20141106/gcc/tree-inline.c: In function ‘int estimate_num_insns_seq(gimple_seq, eni_weights*)’:
../../gcc-5.0-20141106/gcc/tree-inline.c:5820:1: error: invalid argument to gimple call
 }
 ^
stmts
# .MEM_3 = VDEF <.MEM_1(D)>
retval.1677_4 = count_insns_seq (stmts, weights_2(D)); [tail call]
../../gcc-5.0-20141106/gcc/tree-inline.c:5820:1: internal compiler error: verify_gimple failed

in stage2.
Comment 55 Stupachenko Evgeny 2014-11-06 22:41:48 UTC
Created attachment 33915 [details]
patch disabling nonlocal goto receiver and fixing setjmp receiver

(In reply to howarth from comment #54)
> What is the status of this PR? I am finding that current gcc trunk requires
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 in order to avoid the
> use of alias  on darwin resulting in undefined symbols in libstdc++. However
> then the error shifts to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c19 which is identical to
> that reported in Comment 9 here. If I use the patch from
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736&action=diff in this PR,
> the bootstrap failure shifts to...
> 
Please try attached patch instead of "https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736&action=diff"
Comment 56 Stupachenko Evgeny 2014-11-07 00:00:19 UTC
If this does not help, then described issue is not related to this bug,
as darwin bootstrap passed with the patch applied on r216304 (along with
already committed to trunk patches from PR63618 and PR63620).

The patch is discussed here:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00445.html
Comment 57 Jack Howarth 2014-11-07 01:18:10 UTC
(In reply to Stupachenko Evgeny from comment #55)
> Created attachment 33915 [details]
> patch disabling nonlocal goto receiver and fixing setjmp receiver
> 
> (In reply to howarth from comment #54)
> > What is the status of this PR? I am finding that current gcc trunk requires
> > https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 in order to avoid the
> > use of alias  on darwin resulting in undefined symbols in libstdc++. However
> > then the error shifts to
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c19 which is identical to
> > that reported in Comment 9 here. If I use the patch from
> > https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736&action=diff in this PR,
> > the bootstrap failure shifts to...
> > 
> Please try attached patch instead of
> "https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736&action=diff"

Using gcc trunk at r217202 with the patches from...

https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00541.html
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00555.html
https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63580#c4

and your revised patch for disabling nonlocal goto receiver and fixing setjmp receiver from Comment 55 applied allows x86_64-apple-darwin14 to completely bootstrap when configured as...

../gcc-5.0-20141106/configure --prefix=/sw --prefix=/sw/lib/gcc5.0 --mandir=/sw/share/man --infodir=/sw/lib/gcc5.0/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-5.0

Hopefully these patches can get pushed into gcc trunk to allow routine regression testing on darwin again.
Comment 58 Martin Liška 2014-11-07 09:52:36 UTC
Hello Jack.

I would like to thank you for the effort you invested in testing. I'm going to push all IPA ICF related patches to mainline as soon as possible.

Interesting think would be to have a machine with darwin platform in compile farm. But I know it must be a different machine than your MacPro :)

Thanks,
Martin
Comment 59 Jack Howarth 2014-11-07 11:45:52 UTC
(In reply to Martin Liška from comment #58)
> Hello Jack.
> 
> I would like to thank you for the effort you invested in testing. I'm going
> to push all IPA ICF related patches to mainline as soon as possible.
> 
> Interesting think would be to have a machine with darwin platform in compile
> farm. But I know it must be a different machine than your MacPro :)
> 
> Thanks,
> Martin

Martin,
    Using "make -k check-gfortran RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'" on the build from Comment 57 as a quick regression scan shows...

Test Run By howarth on Fri Nov  7 02:25:01 2014
Native configuration is x86_64-apple-darwin14.0.0

		=== gfortran tests ===

Schedule of variations:
    unix/-m32
    unix/-m64

Running target unix/-m32
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/coarray/caf.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/debug/debug.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/assumed_rank_10.f90   -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/assumed_rank_10.f90   -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/assumed_rank_8.f90   -O2  execution test
FAIL: gfortran.dg/assumed_rank_8.f90   -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/assumed_rank_8.f90   -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/assumed_rank_8.f90   -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/assumed_rank_8.f90   -O3 -g  execution test
FAIL: gfortran.dg/assumed_rank_8.f90   -Os  execution test
FAIL: gfortran.dg/assumed_rank_9.f90   -O2  execution test
FAIL: gfortran.dg/assumed_rank_9.f90   -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/assumed_rank_9.f90   -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/assumed_rank_9.f90   -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/assumed_rank_9.f90   -O3 -g  execution test
FAIL: gfortran.dg/assumed_rank_9.f90   -Os  execution test
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/gomp/gomp.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/graphite/graphite.exp ...
FAIL: gfortran.dg/graphite/pr42393.f90   -O  (internal compiler error)
FAIL: gfortran.dg/graphite/pr42393.f90   -O  (test for excess errors)
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/guality/guality.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/ieee/ieee.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/lto/lto.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/vect/vect.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp ...

		=== gfortran Summary for unix/-m32 ===

# of expected passes		46508
# of unexpected failures	16
# of expected failures		52
# of unsupported tests		214
Running target unix/-m64
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/coarray/caf.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/debug/debug.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/assumed_rank_8.f90   -O2  execution test
FAIL: gfortran.dg/assumed_rank_8.f90   -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/assumed_rank_8.f90   -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/assumed_rank_8.f90   -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/assumed_rank_8.f90   -O3 -g  execution test
FAIL: gfortran.dg/assumed_rank_8.f90   -Os  execution test
FAIL: gfortran.dg/assumed_rank_9.f90   -O2  execution test
FAIL: gfortran.dg/assumed_rank_9.f90   -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/assumed_rank_9.f90   -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/assumed_rank_9.f90   -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/assumed_rank_9.f90   -O3 -g  execution test
FAIL: gfortran.dg/assumed_rank_9.f90   -Os  execution test
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/gomp/gomp.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/graphite/graphite.exp ...
FAIL: gfortran.dg/graphite/pr42393.f90   -O  (internal compiler error)
FAIL: gfortran.dg/graphite/pr42393.f90   -O  (test for excess errors)
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/guality/guality.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/ieee/ieee.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/lto/lto.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/vect/vect.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp ...
Running /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp ...

		=== gfortran Summary for unix/-m64 ===

# of expected passes		46797
# of unexpected failures	14
# of expected failures		52
# of unsupported tests		76

		=== gfortran Summary ===

# of expected passes		93305
# of unexpected failures	30
# of expected failures		104
# of unsupported tests		290
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../gfortran  version 5.0.0 20141106 (experimental) (GCC) 

I suspect these regressions may be fixed by adding in the proposed patch from...

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c50

which I am currently testing.
Comment 60 Dominique d'Humieres 2014-11-07 12:03:07 UTC
> Martin,
>    Using "make -k check-gfortran RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
> on the build from Comment 57 as a quick regression scan shows...

See pr63622 comment 7.
Comment 61 Jack Howarth 2014-11-07 13:52:40 UTC
(In reply to Dominique d'Humieres from comment #60)
> > Martin,
> >    Using "make -k check-gfortran RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
> > on the build from Comment 57 as a quick regression scan shows...
> 
> See pr63622 comment 7.

Oddly adding in the patch from Comment 50 here doesn't eliminate the fortran regressions. Is there a second section to that change?
Comment 62 Jack Howarth 2014-11-07 14:15:50 UTC
(In reply to howarth from comment #61)
> (In reply to Dominique d'Humieres from comment #60)
> > > Martin,
> > >    Using "make -k check-gfortran RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
> > > on the build from Comment 57 as a quick regression scan shows...
> > 
> > See pr63622 comment 7.
> 
> Oddly adding in the patch from Comment 50 here doesn't eliminate the fortran
> regressions. Is there a second section to that change?

Reading through pr63622 a second time, it appears that these fortran regressions were never triaged. I think we should proceed with the bootstrap fixes and consider the test suite regression fixes in a second set of patches unless these are impacting other targets.
Comment 63 Dominique d'Humieres 2014-11-07 14:49:27 UTC
> Reading through pr63622 a second time, it appears that these fortran
> regressions were never triaged. I think we should proceed with the
> bootstrap fixes and consider the test suite regression fixes in a
> second set of patches unless these are impacting other targets.

Please stop mixing the problems introduced by r216154 and r216305. While I agree that the first step is to fix bootstrap, there is no hope to fix the issues introduced by r216305 with patches for r216154: the fortran issues as well as the gcc/g++/ada ones are fall out of the former and should be reported in pr63622.
Comment 64 Jack Howarth 2014-11-07 15:20:16 UTC
(In reply to Dominique d'Humieres from comment #63)
> Please stop mixing the problems introduced by r216154 and r216305. While I
> agree that the first step is to fix bootstrap, there is no hope to fix the
> issues introduced by r216305 with patches for r216154: the fortran issues as
> well as the gcc/g++/ada ones are fall out of the former and should be
> reported in pr63622.

Then which should just put the test suite regressions aside for the moment and simply focus on fixing the bootstrap. We need though to either discuss all of the bootstrap patches in a single PR, cc the same information into all associated PRs or create a single meta PR for bootstrapping darwin. Otherwise, it become far to difficult to collate all of the required patches from the individual PRs.
Comment 65 Kirill Yukhin 2014-11-07 20:43:08 UTC
Author: kyukhin
Date: Fri Nov  7 20:42:36 2014
New Revision: 217237

URL: https://gcc.gnu.org/viewcvs?rev=217237&root=gcc&view=rev
Log:
PR target/63534

gcc/
        * config/i386/i386.md (builtin_setjmp_receiver): Use
        pic_offset_table_rtx for PIC register.
        (nonlocal_goto_receiver): Delete.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.md
Comment 66 Francois-Xavier Coudert 2014-11-11 10:13:09 UTC
(In reply to Jeffrey A. Law from comment #52)
> Igor, can you post the patch from c#50 for official review?  Thanks!

ping?
Comment 67 Igor Zamyatin 2014-11-11 12:15:27 UTC
Posted a patch here - http://gcc.gnu.org/ml/gcc-patches/2014-10/msg03318.html

Now discussion stop here - http://gcc.gnu.org/ml/gcc-patches/2014-11/msg00320.html
Comment 68 Francois-Xavier Coudert 2014-11-11 12:21:17 UTC
(In reply to Igor Zamyatin from comment #67)
> Posted a patch here - http://gcc.gnu.org/ml/gcc-patches/2014-10/msg03318.html
> Now discussion stop here -
> http://gcc.gnu.org/ml/gcc-patches/2014-11/msg00320.html

Isn't Jeff's email an approval to commit? As I read it, he said it's OK, but asked if you were sure why you wanted to do this. It seems you are sure.

Jeff, could you confirm?
Comment 69 Dominique d'Humieres 2014-11-11 12:39:49 UTC
On top of pr63815, r216154 is also responsible of

FAIL: gcc.target/i386/avx512f-kandnw-1.c scan-assembler-times kandnw[ \\\\t]+[^\\n]*%k[1-7] 1
FAIL: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-not pop
FAIL: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-not push
FAIL: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-times addl\\t%[re]?dx, %[re]?ax 1
FAIL: gcc.target/i386/fuse-caller-save-xmm.c scan-assembler-times addpd\\t%xmm1, %xmm0 1
FAIL: gcc.target/i386/fuse-caller-save-xmm.c scan-assembler-times movapd\\t%xmm0, %xmm1 1
FAIL: gcc.target/i386/fuse-caller-save.c scan-assembler-not pop
FAIL: gcc.target/i386/fuse-caller-save.c scan-assembler-not push
FAIL: gcc.target/i386/fuse-caller-save.c scan-assembler-times addl\\t%[re]?dx, %[re]?ax 1

with -m32 (may be related to pr63527).
Comment 70 Francois-Xavier Coudert 2014-11-20 11:22:23 UTC
(In reply to Dominique d'Humieres from comment #69)

Apart from comment #69 (which I am not sure is related to the issue), the rest of the PR seems now fixed by the various commits here, as well as the fix for PR63845.

I am thus closing here. Other issues should be reported separately, because this has become such a monster thread.
Comment 71 Francois-Xavier Coudert 2014-11-20 11:22:49 UTC
Actually closing.
Comment 72 hjl@gcc.gnu.org 2014-11-25 21:08:15 UTC
Author: hjl
Date: Tue Nov 25 21:07:43 2014
New Revision: 218062

URL: https://gcc.gnu.org/viewcvs?rev=218062&root=gcc&view=rev
Log:
Add a testcase for PR target/63534

	PR target/63534
	* gcc.target/i386/pr63534.c: New test.

Added:
    trunk/gcc/testsuite/gcc.target/i386/pr63534.c
Modified:
    trunk/gcc/testsuite/ChangeLog