What assembler are you using?

GNU assembler version 2.37 (powerpc64-portbld-freebsd13.1) using BFD version (GNU Binutils) 2.37

Current git bisect visualize --oneline:
93557e6dc39 (refs/bisect/bad) Update gcc de.po
77eccbf39ed rs6000: Improve .machine
0e5d9ae8e41 Update .po files
591d2130348 c++: Standard mangling abbreviations & modules
14dfbb53594 (HEAD) Fix 'libgomp.oacc-c-c++-common/kernels-decompose-1.c' expected diagnostics
458ad38ce2b analyzer: reduce svalue depth limit from 13 to 12 [PR103521]
c3402486afa mkruntimeinc: skip _FILE

14dfbb53594 is still building but it looks like it will succeed. This would mean that 77eccbf39ed is the culprit.

@segher
Could you look into it?

Have you tried with something with

commit 80fcc4b6afee72443bef551064826b3b4b6785e6
Author: Segher Boessenkool <segher@kernel.crashing.org>
Date:   Fri Mar 11 21:15:18 2022 +0000

    rs6000: Do not use rs6000_cpu for .machine ppc and ppc64 (PR104829)
    
    Fixes: 77eccbf39ed5


?  And, what .machine do you get now?

The command line output I pasted in the OP is actually from 12-20220320 (but 12-20220306 fails the same way). So I guess that fix did nothing for powerpc64-freebsd.

Regarding .machine, I will check it tomorrow.

OK, it's .machine "7450", which seems correct.

Created attachment 52670 [details]
proposed patch

Does this help?  The 7450 (which is what freebsd64 defaults to) indeed does
not support these instructions, and it isn't clear to me why we generate them
at all anyway, but this patch makes us more conservative here still.

Testing.

FYI, on 12-20220227, .machine power4 is used.

Now libgcc fails to configure.
From config.log:
configure:3789: checking for suffix of object files
configure:3811: /wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/xgcc -B/wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd13.1/bin/ -B/usr/local/powerpc64-portbld-freebsd13.1/lib/ -isystem
 /usr/local/powerpc64-portbld-freebsd13.1/include -isystem /usr/local/powerpc64-portbld-freebsd13.1/sys-include -fno-checking  -m32 -fPIC -mstrict-align -msecure-plt -c -g -O2 -pipe  -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-
aliasing   conftest.c >&5
{standard input}: Assembler messages:
{standard input}:2: Error: junk at end of line, first unrecognized character is `,'

Created attachment 52675 [details]
proposed patch v2

Bah.  Try this one :-)

Unfortunately, this fails with the original issue:
/wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/xgcc -B/wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd13.1/bin/ -B/usr/local/powerpc64-portbld-freebsd13.1/lib/ -isystem /usr/local/powerpc64-portbld-freebsd13.1/include -isystem /usr/local/powerpc64-portbld-freebsd13.1/sys-include   -fno-checking -g -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -m32 -fPIC -mstrict-align -msecure-plt -O2  -g -O2 -pipe  -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing  -DIN_GCC -fPIC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -pthread -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  -fPIC -pthread -mno-minimal-toc -I. -I. -I../../.././gcc -I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20220320/libgcc -I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20220320/libgcc/. -I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20220320/libgcc/../gcc -I/wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20220320/libgcc/../include  -DHAVE_CC_TLS   -o _mulsc3.o -MT _mulsc3.o -MD -MP -MF _mulsc3.dep -DL_mulsc3 -c /wrkdirs/usr/ports/lang/gcc12-devel/work/gcc-12-20220320/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
{standard input}: Assembler messages:
{standard input}:140: Error: invalid mfcr mask
{standard input}:147: Error: unrecognized opcode: `fcfid'
{standard input}:166: Error: invalid mfcr mask
{standard input}:175: Error: unrecognized opcode: `fcfid'
{standard input}:326: Error: invalid mfcr mask
{standard input}:337: Error: unrecognized opcode: `fcfid'
{standard input}:356: Error: invalid mfcr mask
{standard input}:365: Error: unrecognized opcode: `fcfid'

What I still cannot figure out is how you get TARGET_MFCRF with your
configuration and command line, so, ISA 2.01 .  This is -m32 so *should*
default to -mcpu=7450.  But apparently it uses the PROCESSOR_DEFAULT64 for
-m32 as well?  How can that ever work?

Is it possible there's an underlying bug in GCC and it only works on Linux because the default for Linux for 32-bits is POWER7?

(In reply to Piotr Kubaj from comment #13)
> Is it possible there's an underlying bug in GCC and it only works on Linux
> because the default for Linux for 32-bits is POWER7?

Well the default for -m32 should not be POWER7 (unless you configured with --with-cpu=power7 or --with-cpu-32=power7)!  Segher and I talked offline on how to fix this and it's not a one-line fix. :-(  I believe he is working on it though.

GCC 12.1 is being released, retargeting bugs to GCC 12.2.

GCC 12.2 is being released, retargeting bugs to GCC 12.3.

This also affects GCC 10.4 and the snapshots of GCC 11.

We have (since ten years or sp already)

/* ISA 2.01 allowed FCFID to be done in 32-bit, previously it was 64-bit only.
   Enable 32-bit fcfid's on any of the switches for newer ISA machines.  */
#define TARGET_FCFID    (TARGET_POWERPC64                               \
                         || TARGET_PPC_GPOPT    /* 970/power4 */        \
                         || TARGET_POPCNTB      /* ISA 2.02 */          \
                         || TARGET_CMPB         /* ISA 2.05 */          \
                         || TARGET_POPCNTD)     /* ISA 2.06 */

I don't see how this can ever be enabled for 7450.

But!  We do not support 2.00 at all since quite a while (-mcpu=power4
does not mean 2.00, it means 2.02, i.e. POWER4+ actually), so this macro could
be a lot simpler.

Could you please show the generated .s file?  (Compile with -S instead of -c).

Created attachment 54172 [details]
generated assembly

Attached.

(In reply to Segher Boessenkool from comment #18)
> But!  We do not support 2.00 at all since quite a while (-mcpu=power4
> does not mean 2.00, it means 2.02, i.e. POWER4+ actually), so this macro
> could
> be a lot simpler.

It means 2.01, sorry.  Nasty typo :-(

So, although we get  .machine "7450"  in the generated assembler code, the
compiler uses the default -mcpu=power4 otherwise.  Some logic there is
broken.

I'm not sure whether it will help, but the issue only affects building 32-bit multilib libraries on powerpc64. That is, building a full 32-bit gcc for powerpc works just fine.

(In reply to Piotr Kubaj from comment #21)
> I'm not sure whether it will help, but the issue only affects building
> 32-bit multilib libraries on powerpc64. That is, building a full 32-bit gcc
> for powerpc works just fine.

I can reproduce it with a simple testcase always.  It needs a powerpc64-freebsd
compiler, built with all default options.  With -m32 it still uses the 64-bit
processor, so equivalent to -mcpu=power4.  If you manually use -mcpu=7450 all
works fine.

(In reply to Segher Boessenkool from comment #22)
> (In reply to Piotr Kubaj from comment #21)
> > I'm not sure whether it will help, but the issue only affects building
> > 32-bit multilib libraries on powerpc64. That is, building a full 32-bit gcc
> > for powerpc works just fine.
> 
> I can reproduce it with a simple testcase always.  It needs a
> powerpc64-freebsd
> compiler, built with all default options.  With -m32 it still uses the 64-bit
> processor, so equivalent to -mcpu=power4.  If you manually use -mcpu=7450 all
> works fine.

Wouldn't it be possible to just set -mcpu=7450 in the Makefile for multilib?

GCC 12.3 is being released, retargeting bugs to GCC 12.4.

GCC 12.4 is being released, retargeting bugs to GCC 12.5.