[Bug target/63534] New: [5 Regression] Bootstrap failure on x86_64/i686-linux

[Bug target/63534] New: [5 Regression] Bootstrap failure on x86_64/i686-linux

[jakub at gcc dot gnu.org]

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

            Bug ID: 63534
           Summary: [5 Regression] Bootstrap failure on x86_64/i686-linux
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code, wrong-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: ian at gcc dot gnu.org, kyukhin at gcc dot gnu.org, law at gcc dot gnu.org,
                    vmakarov at gcc dot gnu.org

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?

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*, i?86-*-*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-10-14
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It sounds like it would work fine for leaf functions though (really leafs,
accounting for things like __morestack or _mcount calls).

Confirmed btw.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

Stupachenko Evgeny <evstupac at gmail dot com> changed:

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

--- Comment #2 from Stupachenko Evgeny <evstupac at gmail dot com> ---
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;

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #4 from Stupachenko Evgeny <evstupac at gmail dot com> ---
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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[iverbin at gcc dot gnu.org]

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

--- Comment #6 from iverbin at gcc dot gnu.org ---
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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #7 from Jeffrey A. Law <law at redhat dot com> ---
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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
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)

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #10 from Stupachenko Evgeny <evstupac at gmail dot com> ---
(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".

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[vmakarov at gcc dot gnu.org]

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

--- Comment #11 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(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".

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #12 from Stupachenko Evgeny <evstupac at gmail dot com> ---
(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?

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Created attachment 33728
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33728&action=edit
Compressed tar of the files produced with -fdump-rtl-all

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #15 from Stupachenko Evgeny <evstupac at gmail dot com> ---
Created attachment 33733
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33733&action=edit
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).

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> 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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[iains at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3674 bytes --]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iains at gcc dot gnu.org

--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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.
>From gcc-bugs-return-464263-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 16 15:11:04 2014
Return-Path: <gcc-bugs-return-464263-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22382 invoked by alias); 16 Oct 2014 15:11:03 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 22326 invoked by uid 48); 16 Oct 2014 15:11:00 -0000
From: "evstupac at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
Date: Thu, 16 Oct 2014 15:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: evstupac at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-63534-4-k5A9UrZCDQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63534-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63534-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01284.txt.bz2
Content-length: 532

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc534

--- Comment #18 from Stupachenko Evgeny <evstupac at gmail dot com> ---
Created attachment 33736
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3736&actioníit
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?

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[dominiq at lps dot ens.fr]

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

--- Comment #19 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> 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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[iains at gcc dot gnu.org]

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

--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> ---
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

====

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[izamyatin at gmail dot com]

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

--- Comment #21 from Igor Zamyatin <izamyatin at gmail dot com> ---
(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?

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[iains at gcc dot gnu.org]

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

--- Comment #23 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 33741
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33741&action=edit
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 ..

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #24 from Stupachenko Evgeny <evstupac at gmail dot com> ---
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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[iains at gcc dot gnu.org]

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

--- Comment #25 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 33746
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33746&action=edit
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).

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[iains at gcc dot gnu.org]

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

--- Comment #26 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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?
>From gcc-bugs-return-464354-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 17 13:03:04 2014
Return-Path: <gcc-bugs-return-464354-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14823 invoked by alias); 17 Oct 2014 13:03:04 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 14696 invoked by uid 48); 17 Oct 2014 13:02:59 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/61773] [5 Regression] ICE in tree-ssa-strlen.c:417
Date: Fri, 17 Oct 2014 13:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-61773-4-mhrttgM7Oo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61773-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61773-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01375.txt.bz2
Content-length: 2139

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-10-17
                 CC|                            |trippels at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #5 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Also happens during PGO/LTO bootstrap:

markus@x4 gcc % /var/tmp/gcc_build_dir/./stage1-gcc/xg++
-B/var/tmp/gcc_build_dir/./stage1-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/
-nostdinc++
-B/var/tmp/gcc_build_dir/stage1-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/var/tmp/gcc_build_dir/stage1-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/var/tmp/gcc_build_dir/stage1-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/var/tmp/gcc_build_dir/stage1-x86_64-pc-linux-gnu/libstdc++-v3/include
-I/var/tmp/gcc/libstdc++-v3/libsupc++
-L/var/tmp/gcc_build_dir/stage1-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/var/tmp/gcc_build_dir/stage1-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-march=native -O3 -pipe -flto=jobserver -frandom-seed=1 -fprofile-use -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
-DHAVE_CONFIG_H -DGENERATOR_FILE
-Wl,-O1,--hash-style=gnu,--as-needed,--gc-sections,--icf=safe,--icf-iterations=3
-o build/gengtype build/gengtype.o build/errors.o build/gengtype-lex.o
build/gengtype-parse.o build/gengtype-state.o build/version.o
.././libiberty/libiberty.a
../../gcc/gcc/gengtype.c: In function ‘output_mangled_typename’:
../../gcc/gcc/gengtype.c:2625:1: internal compiler error: in get_string_length,
at tree-ssa-strlen.c:417
 output_mangled_typename (outf_p of, const_type_p t)
 ^
Please submit a full bug report,
>From gcc-bugs-return-464355-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 17 13:11:13 2014
Return-Path: <gcc-bugs-return-464355-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20175 invoked by alias); 17 Oct 2014 13:11:12 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20112 invoked by uid 48); 17 Oct 2014 13:11:08 -0000
From: "mliska at suse dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/63572] [5 Regression] ICF breaks user debugging experience
Date: Fri, 17 Oct 2014 13:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mliska at suse dot cz
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63572-4-2LPmTdSgLL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63572-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63572-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01376.txt.bz2
Content-length: 2388

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

--- Comment #6 from Martin Liška <mliska at suse dot cz> ---
There's how gold's ICF works for test attached by Jakub:

gcc --version:
gcc version 5.0.0 20141016 (experimental) (GCC) 

ld --version:
GNU gold (GNU Binutils 2.24.51.20141010) 1.11

$ gcc icf-gdb.c -c -g --function-sections
$ gcc icf-gdb.o -o a.out -Wl,--icf=all,--print-icf-sections
...
ld: ICF folding section '.text.f2' in file 'icf-gdb.o' into '.text.f1' in file
'icf-gdb.o'
...

dwarfdump a.ou shows:
< 1><0x00000059>    DW_TAG_subprogram
                      DW_AT_name                  f1
                      DW_AT_decl_file             0x00000001
/home/marxin/Programming/testcases/icf-gdb.c
                      DW_AT_decl_line             0x00000005
                      DW_AT_prototyped            yes(1)
                      DW_AT_type                  <0x00000052>
                      DW_AT_low_pc                0x00400546
                      DW_AT_high_pc               <offset-from-lowpc>115
                      DW_AT_frame_base            len 0x0001: 9c:
DW_OP_call_frame_cfa
                      DW_AT_GNU_all_call_sites    yes(1)
                      DW_AT_sibling               <0x000000e2>


and:
< 1><0x000000e8>    DW_TAG_subprogram
                      DW_AT_name                  f2
                      DW_AT_decl_file             0x00000001
/home/marxin/Programming/testcases/icf-gdb.c
                      DW_AT_decl_line             0x00000015
                      DW_AT_prototyped            yes(1)
                      DW_AT_type                  <0x00000052>
                      DW_AT_low_pc                0x00400546
                      DW_AT_high_pc               <offset-from-lowpc>115
                      DW_AT_frame_base            len 0x0001: 9c:
DW_OP_call_frame_cfa
                      DW_AT_GNU_all_call_sites    yes(1)
                      DW_AT_sibling               <0x00000171>

If I tried to put breakpoint in GDB to f2, breakpoint is triggered 4 times with
back-trace from all functions f3-f6.
Example:
#0  f1 (x=0x7fffffffda10) at icf-gdb.c:24
#1  0x00000000004005d1 in f3 (x=0x7fffffffda10) at icf-gdb.c:33
#2  0x0000000000400657 in main () at icf-gdb.c:44


Maybe I miss something, but gold also does not support correct DWARF merging.
I will create issue for gold.

Martin
>From gcc-bugs-return-464356-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 17 13:18:43 2014
Return-Path: <gcc-bugs-return-464356-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29276 invoked by alias); 17 Oct 2014 13:18:43 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 29223 invoked by uid 48); 17 Oct 2014 13:18:39 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/63572] [5 Regression] ICF breaks user debugging experience
Date: Fri, 17 Oct 2014 13:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63572-4-VbYjTdUiVD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63572-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63572-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01377.txt.bz2
Content-length: 3510

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #6)
> There's how gold's ICF works for test attached by Jakub:
> 
> gcc --version:
> gcc version 5.0.0 20141016 (experimental) (GCC) 
> 
> ld --version:
> GNU gold (GNU Binutils 2.24.51.20141010) 1.11
> 
> $ gcc icf-gdb.c -c -g --function-sections
> $ gcc icf-gdb.o -o a.out -Wl,--icf=all,--print-icf-sections
> ...
> ld: ICF folding section '.text.f2' in file 'icf-gdb.o' into '.text.f1' in
> file 'icf-gdb.o'
> ...
> 
> dwarfdump a.ou shows:
> < 1><0x00000059>    DW_TAG_subprogram
>                       DW_AT_name                  f1
>                       DW_AT_decl_file             0x00000001
> /home/marxin/Programming/testcases/icf-gdb.c
>                       DW_AT_decl_line             0x00000005
>                       DW_AT_prototyped            yes(1)
>                       DW_AT_type                  <0x00000052>
>                       DW_AT_low_pc                0x00400546
>                       DW_AT_high_pc               <offset-from-lowpc>115
>                       DW_AT_frame_base            len 0x0001: 9c:
> DW_OP_call_frame_cfa
>                       DW_AT_GNU_all_call_sites    yes(1)
>                       DW_AT_sibling               <0x000000e2>
> 
> 
> and:
> < 1><0x000000e8>    DW_TAG_subprogram
>                       DW_AT_name                  f2
>                       DW_AT_decl_file             0x00000001
> /home/marxin/Programming/testcases/icf-gdb.c
>                       DW_AT_decl_line             0x00000015
>                       DW_AT_prototyped            yes(1)
>                       DW_AT_type                  <0x00000052>
>                       DW_AT_low_pc                0x00400546
>                       DW_AT_high_pc               <offset-from-lowpc>115
>                       DW_AT_frame_base            len 0x0001: 9c:
> DW_OP_call_frame_cfa
>                       DW_AT_GNU_all_call_sites    yes(1)
>                       DW_AT_sibling               <0x00000171>
> 
> If I tried to put breakpoint in GDB to f2, breakpoint is triggered 4 times
> with back-trace from all functions f3-f6.
> Example:
> #0  f1 (x=0x7fffffffda10) at icf-gdb.c:24
> #1  0x00000000004005d1 in f3 (x=0x7fffffffda10) at icf-gdb.c:33
> #2  0x0000000000400657 in main () at icf-gdb.c:44
> 
> 
> Maybe I miss something, but gold also does not support correct DWARF merging.
> I will create issue for gold.

Well, the debug info you get after ld ICF merging is better than what GCC
creates for ICF merging right now, though still not ideal, but as gold likely
doesn't want to rewrite debug info (which is costly operation), it can't do
much more than that, while GCC can.

As you can see above, at least you do have two separate DW_TAG_subprogram for
f1/f2, vars/lexical blocks/parameters/inline functions in them in a good shape.
Supposedly the DW_TAG_GNU_call_site info is present and correct too, so the
debugger has the option to find out in which function it is, but that doesn't
necessarily mean gdb has such support present.

What is broken with ld ICF merging is supposedly .debug_line, for both
functions you are pointed to the same portion of .debug_line, and that portion
contains two sets of line instructions for the same spots, not sure if it can
be considered valid or how would gdb be able to find out which function is
which in there.
>From gcc-bugs-return-464357-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 17 13:21:43 2014
Return-Path: <gcc-bugs-return-464357-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32129 invoked by alias); 17 Oct 2014 13:21:43 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 32032 invoked by uid 48); 17 Oct 2014 13:21:34 -0000
From: "mliska at suse dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/63572] [5 Regression] ICF breaks user debugging experience
Date: Fri, 17 Oct 2014 13:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mliska at suse dot cz
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-63572-4-yh5Ip2Fvut@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63572-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63572-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01378.txt.bz2
Content-length: 239

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

--- Comment #8 from Martin Liška <mliska at suse dot cz> ---
Created attachment 33747
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33747&action=edit
Gold ICF dwarfdump
>From gcc-bugs-return-464358-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 17 13:30:37 2014
Return-Path: <gcc-bugs-return-464358-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7515 invoked by alias); 17 Oct 2014 13:30:37 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7453 invoked by uid 48); 17 Oct 2014 13:30:31 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support
Date: Fri, 17 Oct 2014 13:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-53513-4-MhuECP0ho5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53513-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53513-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01379.txt.bz2
Content-length: 1756

https://gcc.gnu.org/bugzilla/show_bug.cgi?idS513

--- Comment #36 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #35)
> Created attachment 33745 [details]
> Use SImode for FPSCR, add __builtin_sh_get_fpscr, __builtin_sh_set_fpscr
>
> So I ended up removing the usage of PSImode for FPSCR and using SImode
> instead.  I've tested this patch on r216173, together with the already
> applied attachment 33727 [details] patch, with -m4 -ml and -m4 -mb.  There
> is one new failure:
>
> FAIL: gcc.c-torture/execute/20021120-1.c   -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects  (internal compiler error)
>
> error: insn does not satisfy its constraints:
> (insn 1491 1489 1176 5 (set (reg:SI 12 r12)
>         (plus:SI (reg:SI 13 r13)
>             (const_int 24 [0x18]))) 20021120-1.c:39 76 {*addsi3_compact}
>      (nil))
>
>
> Summary:
>
> insn 1173 stores the fpscr to r12
>
> the mode switch (xor op) is done on r12
>
> insn 1489 writes r12 (new fpscr value) on the stack
>
> insn 1491 tries to recalculate the stack address and put it into r12, to
> satisfy the memory constraints of fpu_switch (which now accepts post-inc
> load and simple register address).
>
> insn 1776 tries to load it from the stack
>
>
> Reload generates a wrong insn addsi3 insn.  Something similar was happening
> in PR 55212, too.

Disallowing memory operands (except pre-dec store, post-inc load for push,pop)
in the fpu_switch pattern fixes that failure.  Although it might result in less
optimal code in some cases where user code wants to store the current fpscr in
memory.  On the other hand, the generated memory address code in such cases is
not very good anyway.  Thus it's probably better to drop that for now.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #27 from Stupachenko Evgeny <evstupac at gmail dot com> ---
Created attachment 33748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33748&action=edit
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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[dominiq at lps dot ens.fr]

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

--- Comment #28 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[law at redhat dot com]

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

--- Comment #29 from Jeffrey A. Law <law at redhat dot com> ---
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?

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[iains at gcc dot gnu.org]

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

--- Comment #30 from Iain Sandoe <iains at gcc dot gnu.org> ---
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).

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #31 from Stupachenko Evgeny <evstupac at gmail dot com> ---
(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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #32 from Stupachenko Evgeny <evstupac at gmail dot com> ---
(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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #33 from Stupachenko Evgeny <evstupac at gmail dot com> ---
Created attachment 33769
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33769&action=edit
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).

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrs at gcc dot gnu.org

--- Comment #35 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #36 from Stupachenko Evgeny <evstupac at gmail dot com> ---
(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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[iverbin at gcc dot gnu.org]

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

--- Comment #37 from iverbin at gcc dot gnu.org ---
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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at gcc dot gnu.org

--- Comment #38 from Rainer Orth <ro at gcc dot gnu.org> ---
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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #39 from Stupachenko Evgeny <evstupac at gmail dot com> ---
(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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- 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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #41 from Stupachenko Evgeny <evstupac at gmail dot com> ---
(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.
>From gcc-bugs-return-464936-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 15:46:55 2014
Return-Path: <gcc-bugs-return-464936-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22712 invoked by alias); 24 Oct 2014 15:46:55 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 22656 invoked by uid 48); 24 Oct 2014 15:46:51 -0000
From: "pthaugen at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63595] [5.0 Regression] Segmentation faults inside kernel
Date: Fri, 24 Oct 2014 15:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pthaugen at gcc dot gnu.org
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63595-4-xovbviqpXQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63595-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63595-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01957.txt.bz2
Content-length: 1011

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

--- Comment #7 from Pat Haugen <pthaugen at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #6)
> 
> There's patch I've been testing:
> 
> diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
> index d1238a4..7456fec 100644
> --- a/gcc/ipa-icf.c
> +++ b/gcc/ipa-icf.c
> @@ -869,6 +869,12 @@ sem_function::compare_phi_node (basic_block bb1, 
> basic_block bb2)
>         phi1 = gsi_stmt (si1);
>         phi2 = gsi_stmt (si2);
> 
> +      tree phi_result1 = gimple_phi_result (phi1);
> +      tree phi_result2 = gimple_phi_result (phi2);
> +
> +      if (!m_checker->compare_operand (phi_result1, phi_result2))
> +	return return_false_with_msg ("PHI results are different");
> +
>         size1 = gimple_phi_num_args (phi1);
>         size2 = gimple_phi_num_args (phi2);

I noticed you committed this as r216662 so gave it a try. 254.gap passes now
but 447.dealII still segfaults and has the same code as described in Comment 4.
>From gcc-bugs-return-464937-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 15:53:19 2014
Return-Path: <gcc-bugs-return-464937-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28179 invoked by alias); 24 Oct 2014 15:53:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28106 invoked by uid 55); 24 Oct 2014 15:53:16 -0000
From: "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
Date: Fri, 24 Oct 2014 15:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ro at CeBiTec dot Uni-Bielefeld.DE
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63534-4-cvgOd7RMoX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63534-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63534-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01958.txt.bz2
Content-length: 507

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc534

--- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- 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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[law at redhat dot com]

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

--- Comment #46 from Jeffrey A. Law <law at redhat dot com> ---
Glad I'm not the only one struggling to track everything that's breaking on
Darwin!

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #47 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- 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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[dominiq at lps dot ens.fr]

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

--- Comment #48 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> --- 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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[izamyatin at gmail dot com]

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

--- Comment #50 from Igor Zamyatin <izamyatin at gmail dot com> ---
> 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);

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[dominiq at lps dot ens.fr]

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

--- Comment #51 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> > 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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[law at redhat dot com]

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

--- Comment #52 from Jeffrey A. Law <law at redhat dot com> ---
Igor, can you post the patch from c#50 for official review?  Thanks!

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[ienkovich at gcc dot gnu.org]

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

--- Comment #53 from ienkovich at gcc dot gnu.org ---
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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[howarth at bromo dot med.uc.edu]

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

howarth at bromo dot med.uc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth at bromo dot med.uc.edu

--- Comment #54 from howarth at bromo dot med.uc.edu ---
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.
>From gcc-bugs-return-465917-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Nov 06 22:21:43 2014
Return-Path: <gcc-bugs-return-465917-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8292 invoked by alias); 6 Nov 2014 22:21:43 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8249 invoked by uid 48); 6 Nov 2014 22:21:39 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305
Date: Thu, 06 Nov 2014 22:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: blocker
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63622-4-rSglg0xlib@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63622-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63622-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00389.txt.bz2
Content-length: 345

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc622

--- Comment #25 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> The error seen in Comment 19 appears to be identical to that reported in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?idc534#c9.

This is fixed by the patch at
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc580#c4.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #55 from Stupachenko Evgeny <evstupac at gmail dot com> ---
Created attachment 33915
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33915&action=edit
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"

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #56 from Stupachenko Evgeny <evstupac at gmail dot com> ---
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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[howarth at bromo dot med.uc.edu]

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

--- Comment #57 from howarth at bromo dot med.uc.edu ---
(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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #58 from Martin Liška <marxin at gcc dot gnu.org> ---
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
>From gcc-bugs-return-465947-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 07 09:55:46 2014
Return-Path: <gcc-bugs-return-465947-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16186 invoked by alias); 7 Nov 2014 09:55:45 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15889 invoked by uid 48); 7 Nov 2014 09:55:41 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939
Date: Fri, 07 Nov 2014 09:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_gcchost
Message-ID: <bug-63764-4-wHqtnAHQIv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63764-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63764-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00419.txt.bz2
Content-length: 1552

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Host|                            |x86_64-pc-linux-gnu

--- Comment #3 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Markus Trippelsdorf from comment #1)
> > Also happens when building the Linux kernel:
> That is a different issue and already recorded as bug 63569 (I reduced it
> further based on thinking why it would produce wrong code too).

Ok. Thanks.

This is the original issue further reduced:

trippels@gcc2-power8 ~ % cat test2.ii
void
fn1 ()
{             __attribute__ altivec (vector__))) int saijplus16;
  ((__attribute__ ((altivec (vector__))) int) saijplus16)[0] = 0;
}

trippels@gcc2-power8 ~ % gcc -mvsx -O2 -c test2.ii
test2.ii: In function ‘void fn1()’:
test2.ii:5:1: internal compiler error: in verify_ssa, at tree-ssa.c:939
 }
 ^
0x10bdf767 verify_ssa(bool, bool)
        ../../gcc/gcc/tree-ssa.c:939
0x108a458b execute_function_todo
        ../../gcc/gcc/passes.c:1875
0x108a54ab do_per_function
        ../../gcc/gcc/passes.c:1602
0x108a5667 execute_todo
        ../../gcc/gcc/passes.c:1925
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
>From gcc-bugs-return-465946-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 07 09:55:38 2014
Return-Path: <gcc-bugs-return-465946-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15535 invoked by alias); 7 Nov 2014 09:55:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15463 invoked by uid 48); 7 Nov 2014 09:55:35 -0000
From: "ro at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libobjc/63765] [5.0 Regression] libobjc testsuite failures on AIX caused by setting _XOPEN_SOURCE
Date: Fri, 07 Nov 2014 09:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libobjc
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: ro at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ro at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to
Message-ID: <bug-63765-4-JMPq1evziF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63765-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63765-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00418.txt.bz2
Content-length: 720

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc765

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ro at gcc dot gnu.org

--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> ---
I'll prepare and test a patch along that line over the weekend.

David, just out of interest: could you check what happens if you remove the
definition of _XOPEN_SOURCE in thr.c completely?  In my experience, defining
feature test macros more often than not causes more trouble than it solves
anything.

Thanks, and sorry for the breakage.

  Rainer

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[howarth at bromo dot med.uc.edu]

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

--- Comment #59 from howarth at bromo dot med.uc.edu ---
(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.
>From gcc-bugs-return-465958-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 07 12:03:20 2014
Return-Path: <gcc-bugs-return-465958-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16511 invoked by alias); 7 Nov 2014 12:03:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16420 invoked by uid 48); 7 Nov 2014 12:03:12 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
Date: Fri, 07 Nov 2014 12:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63534-4-WTasRkWx1O@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63534-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63534-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00430.txt.bz2
Content-length: 311

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc534

--- Comment #60 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> 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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[howarth at bromo dot med.uc.edu]

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

--- Comment #61 from howarth at bromo dot med.uc.edu ---
(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?

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[howarth at bromo dot med.uc.edu]

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

--- Comment #62 from howarth at bromo dot med.uc.edu ---
(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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[dominiq at lps dot ens.fr]

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

--- Comment #63 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> 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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[howarth at bromo dot med.uc.edu]

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

--- Comment #64 from howarth at bromo dot med.uc.edu ---
(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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[kyukhin at gcc dot gnu.org]

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

--- Comment #65 from Kirill Yukhin <kyukhin at gcc dot gnu.org> ---
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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu.org

--- Comment #66 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #52)
> Igor, can you post the patch from c#50 for official review?  Thanks!

ping?

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[izamyatin at gmail dot com]

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

--- Comment #67 from Igor Zamyatin <izamyatin at gmail dot com> ---
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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[fxcoudert at gcc dot gnu.org]

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

--- Comment #68 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(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?

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[dominiq at lps dot ens.fr]

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

--- Comment #69 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
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).

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #71 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Actually closing.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[fxcoudert at gcc dot gnu.org]

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

--- Comment #70 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(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.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[hjl at gcc dot gnu.org]

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

--- Comment #72 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> ---
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