Errors building libgcc for powerpc64le-linux-gnu

Errors building libgcc for powerpc64le-linux-gnu

[Ian Lance Taylor via gcc]

I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
cross-compiling from x86_64-pc-linux-gnu.  I'm at SVN revision 279830.
I'm seeing the following.  Is anybody else seeing this crash?  Thanks.

Ian

/tmp/go-build-release/gccgo-objdir/ppc/./gcc/xgcc
-B/tmp/go-build-release/gccgo-objdir/ppc/./gcc/
-B/tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/bin/
-B/tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/lib/
-isystem /tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/include
-isystem /tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/sys-include
--sysroot=/google/src/files/285475989/depot/google3/third_party/grte/v5_ppc/release/usr/grte/v5
  -g -O2 -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag
-Wold-style-definition  -isystem ./include   -fPIC -mlong-double-128
-mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -mlong-double-128 -mno-minimal-toc -I.
-I. -I../.././gcc -I/tmp/go-build-release/gccgo-srcdir/libgcc
-I/tmp/go-build-release/gccgo-srcdir/libgcc/.
-I/tmp/go-build-release/gccgo-srcdir/libgcc/../gcc
-I/tmp/go-build-release/gccgo-srcdir/libgcc/../include
-I/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/dpd
-I/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber
-DHAVE_CC_TLS  -o decNumber.o -MT decNumber.o -MD -MP -MF
decNumber.dep -c
/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c
/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c:
In function 'decToString':
/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c:3760:3:
error: unrecognizable insn:
 3760 |   } /* decToString */
      |   ^
(insn/f 1592 1591 1593 145 (set (reg:CC 104 4)
        (unspec:CC [
                (reg:SI 12 12)
                (const_int 8 [0x8])
            ] UNSPEC_MOVESI_TO_CR))
"/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c":3760:3
-1
     (expr_list:REG_DEAD (reg:SI 12 12)
        (expr_list:REG_CFA_RESTORE (reg:SI 104 4)
            (nil))))
during RTL pass: cprop_hardreg
/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c:3760:3:
internal compiler error: in extract_insn, at recog.c:2294
0xb95832 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
/tmp/go-build-release/gccgo-srcdir/gcc/rtl-error.c:108
0xb9585b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/tmp/go-build-release/gccgo-srcdir/gcc/rtl-error.c:116
0xb63ec2 extract_insn(rtx_insn*)
/tmp/go-build-release/gccgo-srcdir/gcc/recog.c:2294
0xb67995 extract_constrain_insn(rtx_insn*)
/tmp/go-build-release/gccgo-srcdir/gcc/recog.c:2193
0xb6a552 copyprop_hardreg_forward_1(basic_block_def*, value_data*)
/tmp/go-build-release/gccgo-srcdir/gcc/regcprop.c:802
0xb6e207 (anonymous namespace)::pass_cprop_hardreg::execute(function*)
/tmp/go-build-release/gccgo-srcdir/gcc/regcprop.c:1367
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://go.ext.google.com/go/> for instructions.
make: *** [Makefile:645: decNumber.o] Error 1

Re: Errors building libgcc for powerpc64le-linux-gnu

[Ian Lance Taylor via gcc]

On Sat, Dec 14, 2019 at 10:51 AM Ian Lance Taylor <iant@google.com> wrote:
>
> I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
> cross-compiling from x86_64-pc-linux-gnu.  I'm at SVN revision 279830.
> I'm seeing the following.  Is anybody else seeing this crash?  Thanks.
>
> Ian
>
> /tmp/go-build-release/gccgo-objdir/ppc/./gcc/xgcc
> -B/tmp/go-build-release/gccgo-objdir/ppc/./gcc/
> -B/tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/bin/
> -B/tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/lib/
> -isystem /tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/include
> -isystem /tmp/go-build-release/gccgo-installdir/ppc/powerpc64le-linux-gnu/sys-include
> --sysroot=/google/src/files/285475989/depot/google3/third_party/grte/v5_ppc/release/usr/grte/v5
>   -g -O2 -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
> -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
> -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag
> -Wold-style-definition  -isystem ./include   -fPIC -mlong-double-128
> -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc
> -fno-stack-protector   -fPIC -mlong-double-128 -mno-minimal-toc -I.
> -I. -I../.././gcc -I/tmp/go-build-release/gccgo-srcdir/libgcc
> -I/tmp/go-build-release/gccgo-srcdir/libgcc/.
> -I/tmp/go-build-release/gccgo-srcdir/libgcc/../gcc
> -I/tmp/go-build-release/gccgo-srcdir/libgcc/../include
> -I/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/dpd
> -I/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber
> -DHAVE_CC_TLS  -o decNumber.o -MT decNumber.o -MD -MP -MF
> decNumber.dep -c
> /tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c
> /tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c:
> In function 'decToString':
> /tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c:3760:3:
> error: unrecognizable insn:
>  3760 |   } /* decToString */
>       |   ^
> (insn/f 1592 1591 1593 145 (set (reg:CC 104 4)
>         (unspec:CC [
>                 (reg:SI 12 12)
>                 (const_int 8 [0x8])
>             ] UNSPEC_MOVESI_TO_CR))
> "/tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c":3760:3
> -1
>      (expr_list:REG_DEAD (reg:SI 12 12)
>         (expr_list:REG_CFA_RESTORE (reg:SI 104 4)
>             (nil))))
> during RTL pass: cprop_hardreg
> /tmp/go-build-release/gccgo-srcdir/libgcc/../libdecnumber/decNumber.c:3760:3:
> internal compiler error: in extract_insn, at recog.c:2294
> 0xb95832 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
> /tmp/go-build-release/gccgo-srcdir/gcc/rtl-error.c:108
> 0xb9585b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
> /tmp/go-build-release/gccgo-srcdir/gcc/rtl-error.c:116
> 0xb63ec2 extract_insn(rtx_insn*)
> /tmp/go-build-release/gccgo-srcdir/gcc/recog.c:2294
> 0xb67995 extract_constrain_insn(rtx_insn*)
> /tmp/go-build-release/gccgo-srcdir/gcc/recog.c:2193
> 0xb6a552 copyprop_hardreg_forward_1(basic_block_def*, value_data*)
> /tmp/go-build-release/gccgo-srcdir/gcc/regcprop.c:802
> 0xb6e207 (anonymous namespace)::pass_cprop_hardreg::execute(function*)
> /tmp/go-build-release/gccgo-srcdir/gcc/regcprop.c:1367
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <http://go.ext.google.com/go/> for instructions.
> make: *** [Makefile:645: decNumber.o] Error 1


Sorry, I think I see the problem.  I forgot to mention that for
complicated reasons I am building this cross-compiler starting with
clang.  In rs6000.md we see

(define_expand "movsi_to_cr_one"
  [(set (match_operand:CC 0 "cc_reg_operand")
        (unspec:CC [(match_operand:SI 1 "gpc_reg_operand")
    (match_dup 2)] UNSPEC_MOVESI_TO_CR))]
  ""
  "operands[2] = GEN_INT (1 << (75 - REGNO (operands[0])));")

This code has been around for quite a while, and when it was written
the maximum value of a register matching cc_reg_operand was in fact
75.  But now it is 107.  I'm testing changing this 75, and the
corresponding one a few lines down, to MAX_CR_REGNO.

A PowerPC maintainer may want to take this from here.

Ian

Re: Errors building libgcc for powerpc64le-linux-gnu

[Segher Boessenkool]

On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
> cross-compiling from x86_64-pc-linux-gnu.  I'm at SVN revision 279830.
> I'm seeing the following.  Is anybody else seeing this crash?  Thanks.

No, and that makes me wonder what is going on.  The error is simple enough
of course, as you note in a later message; but why do we not see it on
every other build?


Segher

Re: Errors building libgcc for powerpc64le-linux-gnu

[Ian Lance Taylor via gcc]

On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> > I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
> > cross-compiling from x86_64-pc-linux-gnu.  I'm at SVN revision 279830.
> > I'm seeing the following.  Is anybody else seeing this crash?  Thanks.
>
> No, and that makes me wonder what is going on.  The error is simple enough
> of course, as you note in a later message; but why do we not see it on
> every other build?

I think it's because clang treats a left shift by a negative number as
undefined behavior but GCC does not.  So GCC is consistently producing
some number, and clang is producing different numbers.

I should note that I don't really understand what purpose that
constant is serving anyhow.

Ian

Re: Errors building libgcc for powerpc64le-linux-gnu

[Segher Boessenkool]

On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote:
> On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> > > I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
> > > cross-compiling from x86_64-pc-linux-gnu.  I'm at SVN revision 279830.
> > > I'm seeing the following.  Is anybody else seeing this crash?  Thanks.
> >
> > No, and that makes me wonder what is going on.  The error is simple enough
> > of course, as you note in a later message; but why do we not see it on
> > every other build?
> 
> I think it's because clang treats a left shift by a negative number as
> undefined behavior but GCC does not.  So GCC is consistently producing
> some number, and clang is producing different numbers.

Hrm.  Why did that not show up with ubsan then though?  (Or maybe it did,
and I just never heard).

> I should note that I don't really understand what purpose that
> constant is serving anyhow.

-  "operands[2] = GEN_INT (1 << (75 - REGNO (operands[0])));")
+  "operands[2] = GEN_INT (1 << (7 - (REGNO (operands[0]) - CR0_REGNO)));")

The constant is the bitmask of which CR fields to save/restore (always
one here, but the insn allows any combination).

Committing that patch later today.  Thanks for the report!


Segher

Re: Errors building libgcc for powerpc64le-linux-gnu

[Segher Boessenkool]

On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote:
> On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> > > I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
> > > cross-compiling from x86_64-pc-linux-gnu.  I'm at SVN revision 279830.
> > > I'm seeing the following.  Is anybody else seeing this crash?  Thanks.
> >
> > No, and that makes me wonder what is going on.  The error is simple enough
> > of course, as you note in a later message; but why do we not see it on
> > every other build?
> 
> I think it's because clang treats a left shift by a negative number as
> undefined behavior but GCC does not.  So GCC is consistently producing
> some number, and clang is producing different numbers.
> 
> I should note that I don't really understand what purpose that
> constant is serving anyhow.

It's the (old, changed months ago!) register number for CR7.  This code
creates the bitfield that says which CR fields to save or restore.

Anyway, should be fixed now.  If you can confirm, please do :-)


Segher

Re: Errors building libgcc for powerpc64le-linux-gnu

[Ian Lance Taylor via gcc]

On Wed, Dec 18, 2019 at 7:58 AM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote:
> > On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> > >
> > > On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> > > > I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
> > > > cross-compiling from x86_64-pc-linux-gnu.  I'm at SVN revision 279830.
> > > > I'm seeing the following.  Is anybody else seeing this crash?  Thanks.
> > >
> > > No, and that makes me wonder what is going on.  The error is simple enough
> > > of course, as you note in a later message; but why do we not see it on
> > > every other build?
> >
> > I think it's because clang treats a left shift by a negative number as
> > undefined behavior but GCC does not.  So GCC is consistently producing
> > some number, and clang is producing different numbers.
> >
> > I should note that I don't really understand what purpose that
> > constant is serving anyhow.
>
> It's the (old, changed months ago!) register number for CR7.  This code
> creates the bitfield that says which CR fields to save or restore.

That much I got, but the bitfield doesn't seem to actually be used for
anything.  It seems to be created and matched but not used.  Unless I
missed something.  The constant doesn't seem to add anything we don't
already know from the register number.

> Anyway, should be fixed now.  If you can confirm, please do :-)

Confirmed.  Thanks.

Ian

Re: Errors building libgcc for powerpc64le-linux-gnu

[Segher Boessenkool]

On Thu, Dec 19, 2019 at 04:08:39PM -0800, Ian Lance Taylor wrote:
> On Wed, Dec 18, 2019 at 7:58 AM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote:
> > > On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
> > > <segher@kernel.crashing.org> wrote:
> > > >
> > > > On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> > > I should note that I don't really understand what purpose that
> > > constant is serving anyhow.
> >
> > It's the (old, changed months ago!) register number for CR7.  This code
> > creates the bitfield that says which CR fields to save or restore.
> 
> That much I got, but the bitfield doesn't seem to actually be used for
> anything.  It seems to be created and matched but not used.  Unless I
> missed something.  The constant doesn't seem to add anything we don't
> already know from the register number.

Ah okay, in that sense.  In *movsi_to_cr any combination of bits can be
set.  We still could derive the mask from the rtl vector every time it
is used, of course.

We use the mtocrf insn most of the time these days.  ("o" means "one",
exactly one of the eight bits is set, it works on just one cr field).
If we had a different unspec for that (which is probably a good idea
anyway, thanks for that :-) ) we could easily do as you suggest.

> > Anyway, should be fixed now.  If you can confirm, please do :-)
> 
> Confirmed.  Thanks.

Cheers!


Segher