[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||mrs at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #40 from mrs at gcc dot gnu.org  ---
Fixed.

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[mrs at gcc dot gnu.org]

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

--- Comment #39 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Thu Feb  8 18:48:37 2018
New Revision: 257501

URL: https://gcc.gnu.org/viewcvs?rev=257501=gcc=rev
Log:
2018-02-08  Iain Sandoe  

PR target/84113
* config/rs6000/altivec.md (*restore_world): Remove LR use.
* config/rs6000/predicates.md (restore_world_operation): Adjust op
count, remove one USE.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/altivec.md
branches/gcc-7-branch/gcc/config/rs6000/predicates.md

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[mrs at gcc dot gnu.org]

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

--- Comment #38 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Thu Feb  8 18:39:43 2018
New Revision: 257500

URL: https://gcc.gnu.org/viewcvs?rev=257500=gcc=rev
Log:
Mark previous change with:
PR target/84113

Modified:
trunk/gcc/ChangeLog

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[dougmencken at gmail dot com]

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

--- Comment #37 from Douglas Mencken  ---
(In reply to Segher Boessenkool from comment #36)
> I'll take care of it.

Fine. I published my build here https://ftp.osuosl.org/pub/manulix/other/GCC/

And they’re on “rs6000” too (;

manulix@ftp-osl ~]$ uname -a
Linux ftp-osl 3.10.0-327.22.2.el7.ppc64le #1 SMP Thu Jun 9 10:20:28 EDT 2016
ppc64le ppc64le ppc64le GNU/Linux

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-05
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #36 from Segher Boessenkool  ---
I'll take care of it.

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[dougmencken at gmail dot com]

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

--- Comment #35 from Douglas Mencken  ---
(In reply to Douglas Mencken from comment #34)
> And this https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00181.html

By merging that patch this issue is okay to close as resolved

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[dougmencken at gmail dot com]

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

--- Comment #34 from Douglas Mencken  ---
And this https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00181.html

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[dougmencken at gmail dot com]

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

--- Comment #33 from Douglas Mencken  ---
(In reply to Segher Boessenkool from comment #32)
> Yes, run "make -k check" (add -jN to taste if you have multiple CPUs).
> And then run contrib/test_summary.  See if that is as expected (compare
> it to previous powerpc-darwin results on gcc-testresults@; you can also
> send your testresults there).

I did it https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg00374.html

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[segher at gcc dot gnu.org]

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

--- Comment #32 from Segher Boessenkool  ---
Yes, run "make -k check" (add -jN to taste if you have multiple CPUs).
And then run contrib/test_summary.  See if that is as expected (compare
it to previous powerpc-darwin results on gcc-testresults@; you can also
send your testresults there).

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[dougmencken at gmail dot com]

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

--- Comment #31 from Douglas Mencken  ---
(In reply to Segher Boessenkool from comment #29)
> The patch has never been sent to gcc-patches.  It also still never was
> properly tested.  Can you do that?

Or you’re bout sending it to “gcc-patches” by myself?

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[dougmencken at gmail dot com]

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

--- Comment #30 from Douglas Mencken  ---
(In reply to Segher Boessenkool from comment #29)
> The patch has never been sent to gcc-patches.  It also still never was
> properly tested.  Can you do that?

Like doing ‘make check’ after it completes 3rd stage? Sure

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[segher at gcc dot gnu.org]

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

--- Comment #29 from Segher Boessenkool  ---
The patch has never been sent to gcc-patches.  It also still never was
properly tested.  Can you do that?

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[dougmencken at gmail dot com]

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

--- Comment #28 from Douglas Mencken  ---
(In reply to Segher Boessenkool from comment #27)
> Yes.

Wow, it compiles

So I suggest to push patch
https://gcc.gnu.org/ml/gcc-testresults/2017-01/txtnZhWiDkC4z.txt after checking
on other rs6000 systems to the trunk. And to mark this bug as dupe of #80865
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865

One important question ’s yet: Why this patch has been ignored despite it’s
been made just in time?

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[segher at gcc dot gnu.org]

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

--- Comment #27 from Segher Boessenkool  ---
Yes.

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[dougmencken at gmail dot com]

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

--- Comment #26 from Douglas Mencken  ---
(In reply to Segher Boessenkool from comment #25)
> Please test https://gcc.gnu.org/ml/gcc-testresults/2017-01/txtnZhWiDkC4z.txt

Okay, and as I got it, it is supposed to apply upon fresh GCC with that “Don't
emit a use of LR in returns and sibcalls” patch, yeah?

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[segher at gcc dot gnu.org]

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

--- Comment #25 from Segher Boessenkool  ---
Please test https://gcc.gnu.org/ml/gcc-testresults/2017-01/txtnZhWiDkC4z.txt .

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[dougmencken at gmail dot com]

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

--- Comment #24 from Douglas Mencken  ---
(In reply to Segher Boessenkool from comment #23)
> GCC 7 was released more than nine months ago, and yet no one has noticed
> that it does not build at all on powerpc-darwin.  We cannot do magic.

Well, yo can~

“ David and Iain, can you please test on AIX and Darwin? Or is this okay for
trunk without testing?  ;-) ” © Segher Boessenkool
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02040.html
“ This is okay. ” © David Edelsohn
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02051.html [ ..to push without
testing ]

And it’s more than year and five months since that... Nobody noticed, nor Iain,
nor me myself. Until now

So. What to do next? Would it be left ”as is” with yet-gained knowledge what to
revert for these rare species still building GCC on such too extinct platform?
Or there would be some compromise between “Don't emit a use of LR in returns
and sibcalls” and buildability on rs6000:darwin from your side?

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[segher at gcc dot gnu.org]

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

--- Comment #23 from Segher Boessenkool  ---
(In reply to Douglas Mencken from comment #22)
> as for https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02040.html
> I think that optimizing epilogues is a good idea, but not of a cost of
> unbuildability,
> even when it’s unbuildability on “quartiary” ( read as “we don’t care” )
> platform

GCC 7 was released more than nine months ago, and yet no one has noticed
that it does not build at all on powerpc-darwin.  We cannot do magic.

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: unrecognizable insn: internal compiler error on Darwin

[dougmencken at gmail dot com]

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

--- Comment #22 from Douglas Mencken  ---
So yet I have fully workin’

$ /Developer/GCC/7.3patched/PowerPC/32bit/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/Developer/GCC/7.3patched/PowerPC/32bit/bin/gcc
COLLECT_LTO_WRAPPER=/Developer/GCC/7.3patched/PowerPC/32bit/libexec/gcc/powerpc-unknown-darwin/7.3.0/lto-wrapper
Target: powerpc-unknown-darwin
Configured with: ../gcc-git/configure --build=powerpc-unknown-darwin
--host=powerpc-unknown-darwin --target=powerpc-unknown-darwin
--prefix=/Developer/GCC/7.3patched/PowerPC/32bit
--enable-languages=c,c++,objc,obj-c++ --enable-shared --enable-static
--enable-checking=release --enable-threads=posix --with-__thread
--without-system-zlib --disable-nls --disable-werror
Thread model: posix
gcc version 7.3.0 (GCC)

as for https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02040.html
I think that optimizing epilogues is a good idea, but not of a cost of
unbuildability,
even when it’s unbuildability on “quartiary” ( read as “we don’t care” )
platform