[Bug testsuite/106680] Test gcc.target/powerpc/bswap64-4.c fails on 32-bit BE

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #14 from Sebastian Huber  ---
Thanks for your help, it seems that this patch fixes the issue for RTEMS:

diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h
index 57a2325991b..b36e64fec77 100644
--- a/gcc/config/rs6000/rtems.h
+++ b/gcc/config/rs6000/rtems.h
@@ -36,6 +36,10 @@
 #endif
 #endif

+/* RTEMS configured for the 32-bit multilibs doesn't support saving and
+   restoring 64-bit regs.  */
+#define OS_MISSING_POWERPC64 !TARGET_64BIT
+
 /* Copy and paste from linux64.h and freebsd64.h */
 #undef TARGET_AIX
 #defineTARGET_AIX TARGET_64BIT

[Bug testsuite/106680] Test gcc.target/powerpc/bswap64-4.c fails on 32-bit BE

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #13 from Sebastian Huber  ---
(In reply to Kewen Lin from comment #12)
> (In reply to Sebastian Huber from comment #10)
> > (In reply to Kewen Lin from comment #9)
> > > Note that now we only disable implicit powerpc64 for -m32 when the
> > > OS_MISSING_POWERPC64 is set.
> > > 
> > >   /* Don't expect powerpc64 enabled on those OSes with 
> > > OS_MISSING_POWERPC64,
> > >  since they do not save and restore the high half of the GPRs 
> > > correctly
> > >  in all cases.  If the user explicitly specifies it, we won't 
> > > interfere
> > >  with the user's specification.  */
> > > #ifdef OS_MISSING_POWERPC64
> > >   if (OS_MISSING_POWERPC64
> > >   && TARGET_32BIT
> > >   && TARGET_POWERPC64
> > >   && !(rs6000_isa_flags_explicit & OPTION_MASK_POWERPC64))
> > > rs6000_isa_flags &= ~OPTION_MASK_POWERPC64;
> > > #endif
> > > 
> > > But rtems.h doesn't define OS_MISSING_POWERPC64
> > 
> > RTEMS supports the 64-bit PowerPC for the 64-bit multilibs.
> > 
> 
> 64-bit kernel should support 64-bit PowerPC, but does 32-bit kernel support
> saving and restoring 64-bit regs?

For the 32-bit multilibs, we don't save/restore the full 64-bit registers.

> 
> The current rtems.h is saying yes, if it's no, we should fix the rtems.h and
> you won't need the explicit -mno-powerpc64 then.
> 
> 
> btw, take the comments in freebsd64.h for example.
> 
> /* FreeBSD doesn't support saving and restoring 64-bit regs with a 32-bit
>kernel. This is supported when running on a 64-bit kernel with
>COMPAT_FREEBSD32, but tell GCC it isn't so that our 32-bit binaries
>are compatible. */
> #define OS_MISSING_POWERPC64 !TARGET_64BIT

Thanks for the hint, I will try out this setting.

[Bug testsuite/106680] Test gcc.target/powerpc/bswap64-4.c fails on 32-bit BE

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #10 from Sebastian Huber  ---
(In reply to Kewen Lin from comment #9)
> Note that now we only disable implicit powerpc64 for -m32 when the
> OS_MISSING_POWERPC64 is set.
> 
>   /* Don't expect powerpc64 enabled on those OSes with OS_MISSING_POWERPC64,
>  since they do not save and restore the high half of the GPRs correctly
>  in all cases.  If the user explicitly specifies it, we won't interfere
>  with the user's specification.  */
> #ifdef OS_MISSING_POWERPC64
>   if (OS_MISSING_POWERPC64
>   && TARGET_32BIT
>   && TARGET_POWERPC64
>   && !(rs6000_isa_flags_explicit & OPTION_MASK_POWERPC64))
> rs6000_isa_flags &= ~OPTION_MASK_POWERPC64;
> #endif
> 
> But rtems.h doesn't define OS_MISSING_POWERPC64

RTEMS supports the 64-bit PowerPC for the 64-bit multilibs.

> 
> gcc/config/rs6000/linux.h:#define OS_MISSING_POWERPC64 1
> gcc/config/rs6000/freebsd64.h:#define OS_MISSING_POWERPC64 !TARGET_64BIT
> gcc/config/rs6000/aix.h:#define OS_MISSING_POWERPC64 1
> gcc/config/rs6000/linux64.h:#define OS_MISSING_POWERPC64 !TARGET_64BIT
> 
> meanwhile cpu "e6500" has MASK_POWERPC64 set by default (it's 64bit core).
> 
> That's why you still have powerpc64 flag set when you specify -m32 on rtems.

For some applications, you don't need the 64-bit support on the e6500 machines.
So, we have 32-bit and 64-bit multilibs. This is just a performance
optimization for some applications.

[Bug testsuite/106680] Test gcc.target/powerpc/bswap64-4.c fails on 32-bit BE

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #8 from Sebastian Huber  ---
Yes, it seems that -mcpu=e6500 -mno-powerpc64 yields the right code for the
attached test case (with or without the -m32).

I am now a bit confused what the purpose of the -m32 and -m64 options is.

[Bug testsuite/106680] Test gcc.target/powerpc/bswap64-4.c fails on 32-bit BE

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #6 from Sebastian Huber  ---
It seems that the change

commit acc727cf02a1446dc00f8772f3f479fa3a508f8e
Author: Kewen Lin 
Date:   Tue Dec 27 04:13:07 2022 -0600

rs6000: Rework option -mpowerpc64 handling [PR106680]

causes a regression for -mcpu=e6500 -m32, for example:

gcc -fpreprocessed -O2 -S -mcpu=e6500 -m32 -S imfs_add_node.c.67.s
imfs_add_node.c.67.i

diff -u imfs_add_node.c.67.s.good.e2acff49fb2962b921bf8b73984b89878b61492c
imfs_add_node.c.67.s.bad.acc727cf02a1446dc00f8772f3f479fa3a508f8e
--- imfs_add_node.c.67.s.good.e2acff49fb2962b921bf8b73984b89878b61492c 
2024-01-20 12:15:15.143182571 +0100
+++ imfs_add_node.c.67.s.bad.acc727cf02a1446dc00f8772f3f479fa3a508f8e  
2024-01-20 12:11:46.804204927 +0100
@@ -52,8 +52,8 @@
bne- 0,.L4
 .L2:
mr 4,29
-   addi 3,1,8
li 5,24
+   addi 3,1,8
bl rtems_filesystem_eval_path_start
lis 9,IMFS_node_clone@ha
lwz 10,20(3)
@@ -63,12 +63,12 @@
cmpw 0,10,9
beq- 0,.L24
li 4,134
-   addi 3,1,8
+   li 3,0
bl rtems_filesystem_eval_path_error
 .L9:
li 31,-1
 .L10:
-   addi 3,1,8
+   li 3,0
bl rtems_filesystem_eval_path_cleanup
 .L1:
lwz 0,116(1)
@@ -93,7 +93,7 @@
lwz 9,12(31)
li 8,96
lhz 10,16(31)
-   addi 3,1,8
+   li 3,0
stw 8,24(1)
stw 9,8(1)
stw 10,12(1)
@@ -105,7 +105,7 @@
cmpwi 0,9,0
beq- 0,.L9
li 4,22
-   addi 3,1,8
+   li 3,0
bl rtems_filesystem_eval_path_error
b .L9
.p2align 4,,15
@@ -129,12 +129,9 @@
stw 9,0(10)
stw 10,4(9)
bl _Timecounter_Getbintime
-   lwz 10,64(1)
-   lwz 11,68(1)
-   stw 10,40(30)
-   stw 11,44(30)
-   stw 10,48(30)
-   stw 11,52(30)
+   ld 9,64(1)
+   std 9,40(30)
+   std 9,48(30)
b .L10
.cfi_endproc
 .LFE351:

For the call to rtems_filesystem_eval_path_cleanup() the register 3 should
point to a structure on the stack. Correct is:

-   addi 3,1,8

Wrong is:

+   li 3,0

It seems that for the -mcpu=e6500 the -m32 option has not the right effect and
some 64-bit instructions are generated, for example ld and std plus the wrong
function parameters.

[Bug testsuite/106680] Test gcc.target/powerpc/bswap64-4.c fails on 32-bit BE

[sebastian.huber--- via Gcc-bugs]

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

Sebastian Huber  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #5 from Sebastian Huber  ---
Created attachment 57174
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57174&action=edit
Proprocessed test file.

[Bug target/112777] [14 Regression] profiled bootstrap fails on powerpc-linux-gnu, undefined references to __atomic_fetch_add_8

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #3 from Sebastian Huber  ---
I think the issue is in c-cppbuiltin.cc:

  builtin_define_with_int_value ("__LIBGCC_HAVE_LIBATOMIC",
 targetm.have_libatomic);

Which is used in libgcov.h like this:

/* Detect whether target can support atomic update of profilers.  */
#if (__SIZEOF_LONG_LONG__ == 4 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4) \
|| (__SIZEOF_LONG_LONG__ == 8 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8) \
|| defined (__LIBGCC_HAVE_LIBATOMIC)
#define GCOV_SUPPORTS_ATOMIC 1
#else
#define GCOV_SUPPORTS_ATOMIC 0
#endif

Should I keep the defined (__LIBGCC_HAVE_LIBATOMIC) and change c-cppbuiltin.cc
to:

if (targetm.have_libatomic)
  builtin_define ("__LIBGCC_HAVE_LIBATOMIC");

Or, should I change libgcov.h to use:

#if (__SIZEOF_LONG_LONG__ == 4 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4) \
|| (__SIZEOF_LONG_LONG__ == 8 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8) \
|| __LIBGCC_HAVE_LIBATOMIC

[Bug libgcc/110775] [12/13/14 Regression] abort define causing issues in tsystem.h

[sebastian.huber--- via Gcc-bugs]

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

Sebastian Huber  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #2 from Sebastian Huber  ---
In tsystem.h we have:

#ifdef inhibit_libc

...

#ifndef abort
#define abort() __builtin_trap ()
#endif

Does it make sense to define inhibit_libc and then later use  and
?

[Bug target/109566] [12/13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #15 from Sebastian Huber  ---
Thanks for digging into this. With the change I am able to build the
powerpc-rtems target.

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #7 from Sebastian Huber  ---
(In reply to Jakub Jelinek from comment #6)
> How have you configured gcc?  I certainly can't reproduce this with
> --enable-targets=powerpc64-linux,powerpc-linux --with-cpu-32=power7
> --with-cpu-64=power7 --with-long-double-128 --enable-checking=release
> --target=powerpc64-linux-gnu --enable-languages=c,c++,fortran,lto
> nor
> --target powerpc-linux --enable-languages=c,c++
> configured gccs.

I notices this issue with the powerpc-rtems6 target while building Newlib. Can
you compile the test case with your compiler?

I was able to reproduce the error with the powerpc-elf target:

powerpc-elf-gcc -O2  -mcpu=power10 -c test.c
/home/EB/sebastian_h/tmp/bug-gcc-pr109566/test.c: In function '__ieee754_fmod':
/home/EB/sebastian_h/tmp/bug-gcc-pr109566/test.c:32:1: error: unrecognizable
insn:
   32 | }
  | ^
(insn 49 8 50 2 (parallel [
(set (reg:CC 100 0)
(compare:CC (and:DI (ashift:DI (reg:DI 9 9 [123])
(const_int 33 [0x21]))
(const_int -9007199254740992 [0xffe0]))
(const_int 0 [0])))
(clobber (reg:DI 9 9 [127]))
]) "/home/EB/sebastian_h/tmp/bug-gcc-pr109566/test.c":21:4 -1
 (nil))
during RTL pass: split2
/home/EB/sebastian_h/tmp/bug-gcc-pr109566/test.c:32:1: internal compiler error:
in extract_insn, at recog.cc:2791
0x40730a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/EB/sebastian_h/src/gcc/gcc/rtl-error.cc:108
0x407329 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/EB/sebastian_h/src/gcc/gcc/rtl-error.cc:116
0x957257 extract_insn(rtx_insn*)
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:2791
0x9572b1 extract_insn_cached(rtx_insn*)
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:2680
0x6a99ab cleanup_subreg_operands(rtx_insn*)
/home/EB/sebastian_h/src/gcc/gcc/final.cc:3054
0x95561c split_insn
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:3420
0x95a392 split_all_insns()
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:3488
0x95a4a8 execute
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:4412
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/109566] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #4 from Sebastian Huber  ---
(In reply to Sebastian Huber from comment #3)
> I get this error also for -mcpu=power3, ..., -mcpu=power10.

I get the ICE only in 32-bit mode, the 64-bit mode works:

powerpc-rtems6-gcc -O2 -mcpu=power10 -m64 -S test.c -dA -da -dp -o - 
.file   "test.c"
.machine power10
.abiversion 2
.section".text"
.align 2
.p2align 4,,15
.globl __ieee754_fmod
.type   __ieee754_fmod, @function
__ieee754_fmod:
.LFB0:
.cfi_startproc
.localentry __ieee754_fmod,1
 # BLOCK 2, count:118111600 (estimated locally) seq:0
 # PRED: ENTRY [always]  count:118111600 (estimated locally) (FALLTHRU)
mfvsrd 9,1   # 7[c=4 l=4]  *movdi_internal64/25
srdi 9,9,32  # 8[c=4 l=4]  lshrdi3
rldicr. 9,9,33,10# 49   [c=4 l=4]  *rotldi3_mask_dot/0
 # SUCC: 4 [50.0% (guessed)]  count:59055800 (estimated locally) (CAN_FALLTHRU)
3 [50.0% (guessed)]  count:59055800 (estimated locally) (FALLTHRU,CAN_FALLTHRU)
beq 0,.L2# 50   [c=4 l=4]  *cbranch
 # BLOCK 3, count:118111600 (estimated locally) seq:1
 # PRED: 2 [50.0% (guessed)]  count:59055800 (estimated locally)
(FALLTHRU,CAN_FALLTHRU)
xxlxor 1,1,1 # 22   [c=4 l=4]  *movdf_hardfloat64/8
 # SUCC: EXIT [always]  count:118111600 (estimated locally)
blr  # 53   [c=4 l=4]  simple_return
 # BLOCK 4, count:0 (estimated locally) seq:2
 # PRED: 2 [50.0% (guessed)]  count:59055800 (estimated locally) (CAN_FALLTHRU)
4 [always]  count:0 (estimated locally) (DFS_BACK,CAN_FALLTHRU)
.L2:
 # SUCC: 4 [always]  count:0 (estimated locally) (DFS_BACK,CAN_FALLTHRU)
b .L2# 59   [c=4 l=4]  jump
.long 0
.byte 0,0,0,0,0,0,0,0
.cfi_endproc
.LFE0:
.size   __ieee754_fmod,.-__ieee754_fmod
.ident  "GCC: (GNU) 13.0.1 20230424 (prerelease) [releases/gcc-13
f743863e09a]"
.gnu_attribute 4, 9
.section.note.GNU-stack,"",@progbits

[Bug target/109566] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

[sebastian.huber--- via Gcc-bugs]

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

Sebastian Huber  changed:

   What|Removed |Added

Summary|powerpc: unrecognizable |powerpc: unrecognizable
   |insn for -mcpu=e6500|insn for -mcpu=e6500,
   ||-mcpu=power3, ...,
   ||-mcpu=power10

--- Comment #3 from Sebastian Huber  ---
I get this error also for -mcpu=power3, ..., -mcpu=power10.

[Bug target/109566] powerpc: unrecognizable insn for -mcpu=e6500

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #2 from Sebastian Huber  ---
Sorry for the confusion, the actual bad commit was the follow up commit (NOT
d75be7e4343f049176546aa9517d570e5eb67954):

commit 6cc3394507a2303a18891d34222c53f679256c37
Author: Andrew MacLeod 
Date:   Wed Oct 5 10:42:07 2022 -0400

propagate partial equivs in the cache.

Adjust on-entry cache propagation to look for and propagate both full
and partial equivalences.

gcc/
PR tree-optimization/102540
PR tree-optimization/102872
* gimple-range-cache.cc (ranger_cache::fill_block_cache):
Handle partial equivs.
(ranger_cache::range_from_dom): Cleanup dump output.

gcc/testsuite/
* gcc.dg/pr102540.c: New.
* gcc.dg/pr102872.c: New.

[Bug target/109566] powerpc: unrecognizable insn for -mcpu=e6500

[sebastian.huber--- via Gcc-bugs]

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

Sebastian Huber  changed:

   What|Removed |Added

  Known to work||12.1.0, 12.2.0

--- Comment #1 from Sebastian Huber  ---
I did a git bisect using. It ended up in this commit:

commit d75be7e4343f049176546aa9517d570e5eb67954
Author: Andrew MacLeod 
Date:   Thu Oct 6 15:01:24 2022 -0400

Add partial equivalence recognition to cast and bitwise and.

This provides the hooks that will register partial equivalencies for
casts and bitwise AND operations with the appropriate bit pattern.

* range-op.cc (operator_cast::lhs_op1_relation): New.
(operator_bitwise_and::lhs_op1_relation): New.

 gcc/range-op.cc | 65 +
 1 file changed, 65 insertions(+)

[Bug target/109566] New: powerpc: unrecognizable insn for -mcpu=e6500

[sebastian.huber--- via Gcc-bugs]

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

Bug ID: 109566
   Summary: powerpc: unrecognizable insn for -mcpu=e6500
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Consider the following test case:

typedef int __int32_t;
typedef unsigned int __uint32_t;
typedef union
{
  double value;
  struct
  {
__uint32_t msw;
__uint32_t lsw;
  } parts;
} ieee_double_shape_type;
 double __ieee754_fmod(double x, double y)
{
 __int32_t n,hx,hy,hz,ix,iy,sx,i;
 __uint32_t lx,ly,lz;
 do { ieee_double_shape_type ew_u; ew_u.value = (x); (hx) = ew_u.parts.msw;
(lx) = ew_u.parts.lsw; } while (0);
 sx = hx&0x8000;
 hx ^=sx;
 if(hx<=hy) {
 }
 if(hx<0x0010) {
 if(hx==0) {
  for (ix = -1043, i=lx; i>0; i<<=1) ix -=1;
 }
 } else ix = (hx>>20)-1023;
 if(ix >= -1022)
 hx = 0x0010|(0x000f&hx);
 while(hx<0x0010) {
 if(n<=20) {
 }
 }
}

This yields:

powerpc-rtems6-gcc -O2  -mcpu=e6500  -c test.c
test.c: In function '__ieee754_fmod':
test.c:32:1: error: unrecognizable insn:
   32 | }
  | ^
(insn 52 8 53 2 (parallel [
(set (reg:CC 100 0)
(compare:CC (and:DI (ashift:DI (reg:DI 9 9 [123])
(const_int 33 [0x21]))
(const_int -9007199254740992 [0xffe0]))
(const_int 0 [0])))
(clobber (reg:DI 9 9 [129]))
]) "test.c":21:4 -1
 (nil))
during RTL pass: split2
test.c:32:1: internal compiler error: in extract_insn, at recog.cc:2791
0x40730a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/EB/sebastian_h/src/gcc/gcc/rtl-error.cc:108
0x407329 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/EB/sebastian_h/src/gcc/gcc/rtl-error.cc:116
0x957477 extract_insn(rtx_insn*)
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:2791
0x9574d1 extract_insn_cached(rtx_insn*)
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:2680
0x6a9a0b cleanup_subreg_operands(rtx_insn*)
/home/EB/sebastian_h/src/gcc/gcc/final.cc:3054
0x95583c split_insn
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:3420
0x95a5b2 split_all_insns()
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:3488
0x95a6c8 execute
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:4412
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug gcov-profile/108658] [GCOV] Function entry is not recorded in a function containing an infinite loop from another thread depending on the optimization level

[sebastian.huber--- via Gcc-bugs]

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

Sebastian Huber  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #4 from Sebastian Huber  ---
What is interesting is that -g changes the behaviour. I guess there is an error
in the mapping of the profiling counter to the associated source code lines.

gcc-12 -O2 --coverage -c main.c -g
rm -f *.gc??
gcc-12 -pthread -fprofile-update=atomic -O2 --coverage -c idle.c -g
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:66.67% of 3
Creating 'idle.c.gcov'

Lines executed:66.67% of 3
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
#:1:void *idle(void *ignored)
-:2:{
213413784:3:  while (1) {
-:4:/* Do nothing */
213413784:5:  }
-:6:
-:7:  return 0;
-:8:}
rm -f *.gc??
gcc-12 -pthread -fprofile-update=atomic -Og --coverage -c idle.c -g
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:66.67% of 3
Creating 'idle.c.gcov'

Lines executed:66.67% of 3
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
#:1:void *idle(void *ignored)
-:2:{
214569562:3:  while (1) {
-:4:/* Do nothing */
214569562:5:  }
-:6:
-:7:  return 0;
-:8:}
rm -f *.gc??
gcc-12 -pthread -fprofile-update=atomic -O0 --coverage -c idle.c -g
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:100.00% of 2
Creating 'idle.c.gcov'

Lines executed:100.00% of 2
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
214896204:1:void *idle(void *ignored)
-:2:{
214896204:3:  while (1) {
-:4:/* Do nothing */
-:5:  }
-:6:
-:7:  return 0;
-:8:}

[Bug gcov-profile/108658] [GCOV] Function entry is not recorded in a function containing an infinite loop from another thread depending on the optimization level

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #3 from Sebastian Huber  ---
Thanks for the hint, however, adding -pthread or -fprofile-update=atomic
doesn't change anything.

[Bug gcov-profile/108658] New: [GCOV] Function entry is not recorded in a function containing an infinite loop depending on the optimization level

[sebastian.huber--- via Gcc-bugs]

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

Bug ID: 108658
   Summary: [GCOV] Function entry is not recorded in a function
containing an infinite loop depending on the
optimization level
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Consider the following test code:

idle.c

void *idle(void *ignored)
{
  while (1) {
/* Do nothing */
  }

  return 0;
}

main.c

#include 

void *idle(void *ignored);

int main(void)
{
  pthread_t th;
  pthread_create(&th, NULL, idle, NULL);
  sleep(1);
  return 0;
}

This sequence of commands shows that the idle() function entry is not recorded
for -O2 and -Og:

gcc-12 -O2 --coverage -c main.c
rm -f *.gc??
gcc-12 -O2 --coverage -c idle.c
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:0.00% of 1
Creating 'idle.c.gcov'

Lines executed:0.00% of 1
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
#:1:void *idle(void *ignored)
-:2:{
-:3:  while (1) {
-:4:/* Do nothing */
-:5:  }
-:6:
-:7:  return 0;
-:8:}
rm -f *.gc??
gcc-12 -Og --coverage -c idle.c
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:50.00% of 2
Creating 'idle.c.gcov'

Lines executed:50.00% of 2
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
#:1:void *idle(void *ignored)
-:2:{
472195650:3:  while (1) {
-:4:/* Do nothing */
-:5:  }
-:6:
-:7:  return 0;
-:8:}
rm -f *.gc??
gcc-12 -O0 --coverage -c idle.c
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:100.00% of 2
Creating 'idle.c.gcov'

Lines executed:100.00% of 2
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
472440920:1:void *idle(void *ignored)
-:2:{
472440920:3:  while (1) {
-:4:/* Do nothing */
-:5:  }
-:6:
-:7:  return 0;
-:8:}

For -O0 the line count is also wrong from my point of view. Line 1 should have
a count of 1.

[Bug target/108031] New: riscv: Access of members of a global structure is not optimized in atomic operations

[sebastian.huber--- via Gcc-bugs]

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

Bug ID: 108031
   Summary: riscv: Access of members of a global structure is not
optimized in atomic operations
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Consider the following test code:

struct s {
  int a;
  int b;
};

struct s s;

int f(void)
{
  return __atomic_fetch_add(&s.a, 1, 0) + __atomic_fetch_add(&s.b, 1, 0);
}

Using gcc -O2 -S -o - test.c yields:

f:
lui a5,%hi(s)
li  a4,1
addia5,a5,%lo(s)
amoadd.w a0,a4,0(a5)
lui a5,%hi(s+4) <-- this should be: addi a5, a5, 4
addia5,a5,%lo(s+4) <-- this should be removed
amoadd.w a3,a4,0(a5)
add a0,a0,a3
ret

This seems to be a backend issue since on arm we have for example (gcc
-march=armv7-a -O2 -S -o - test.c):
f:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
movwr3, #:lower16:.LANCHOR0
movtr3, #:upper16:.LANCHOR0
.L2:
ldrex   r0, [r3]
add r2, r0, #1
strex   r1, r2, [r3]
cmp r1, #0
bne .L2
add r3, r3, #4
.L3:
ldrex   r2, [r3]
add r1, r2, #1
strex   ip, r1, [r3]
cmp ip, #0
bne .L3
add r0, r0, r2
bx  lr

clang produces (clang -O2 -S -o - test.c --target=riscv32):

f:
lui a0, %hi(s)
addia0, a0, %lo(s)
li  a1, 1
amoadd.wa2, a1, (a0)
addia0, a0, 4
amoadd.wa0, a1, (a0)
add a0, a0, a2
ret

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

[sebastian.huber--- via Gcc-bugs]

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

Sebastian Huber  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #19 from Sebastian Huber  ---
I just have a side note. Enabling the thread-local storage may be an option for
targets with limited memory resources. Newlib has the configuration option
--enable-newlib-reent-thread-local to use thread-local objects instead of one
big struct _reent.

[Bug target/106282] New: m68k: Problem with thread-local storage and -mcpu=5206

[sebastian.huber--- via Gcc-bugs]

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

Bug ID: 106282
   Summary: m68k: Problem with thread-local storage and -mcpu=5206
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

The following test code (derived from Newlib l64a.c):

_Thread_local char _tls_l64a_buf[8];

static const char R64_ARRAY[] =
"./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";

char *
_l64a_r (long value)
{
  char *ptr;
  char *result;
  int i, index;
  unsigned long tmp = (unsigned long)value & 0x;

  result = _tls_l64a_buf;
  ptr = result;

  for (i = 0; i < 6; ++i)
{
  if (tmp == 0)
{
  *ptr = '\0';
  break;
}

  index = tmp & (64 - 1);
  *ptr++ = R64_ARRAY[index];
  tmp >>= 6;
}

  return result;
}

compiled with

m68k-rtems6-gcc -mcpu=5206 -O2 -c test.c

fails with

/tmp/ccO3QdNm.s: Assembler messages:
/tmp/ccO3QdNm.s:24: Error: syntax error -- statement `lea
(_tls_l64a_buf@TLSLE+6,%a0),%a0' ignored

[Bug libstdc++/105880] eh_globals_init destructor not setting _M_init to false

[sebastian.huber--- via Gcc-bugs]

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

Sebastian Huber  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #1 from Sebastian Huber  ---
Just for reference, the destructor code is (eh_globals.cc):

struct __eh_globals_init
{
  __gthread_key_t   _M_key;
  bool  _M_init;

[...]

  ~__eh_globals_init()
  {
if (_M_init)
  __gthread_key_delete(_M_key);
_M_init = false; <-- This store is optimized away
  }
};

[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken

[sebastian.huber--- via Gcc-bugs]

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

Sebastian Huber  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #4 from Sebastian Huber  ---
Maybe you can reproduce it with Binutils 2.38. There was a recent change in
Binutils which could prevent the error:

commit cebc89b9328eab994f6b0314c263f94e7949a553
Author: Alan Modra 
Date:   Mon Feb 21 10:58:57 2022 +1030

binutils 2.38 vs. ppc32 linux kernel

Commit b25f942e18d6 made .machine more strict.  Weaken it again.

* config/tc-ppc.c (ppc_machine): Treat an early .machine specially,
keeping sticky options to work around gcc bugs.

diff --git a/gas/config/tc-ppc.c b/gas/config/tc-ppc.c
index 054f9c72161..89bc7d3f9b9 100644
--- a/gas/config/tc-ppc.c
+++ b/gas/config/tc-ppc.c
@@ -5965,7 +5965,30 @@ ppc_machine (int ignore ATTRIBUTE_UNUSED)
 options do not count as a new machine, instead they add
 to currently selected opcodes.  */
  ppc_cpu_t machine_sticky = 0;
- new_cpu = ppc_parse_cpu (ppc_cpu, &machine_sticky, cpu_string);
+ /* Unfortunately, some versions of gcc emit a .machine
+directive very near the start of the compiler's assembly
+output file.  This is bad because it overrides user -Wa
+cpu selection.  Worse, there are versions of gcc that
+emit the *wrong* cpu, not even respecting the -mcpu given
+to gcc.  See gcc pr101393.  And to compound the problem,
+as of 20220222 gcc doesn't pass the correct cpu option to
+gas on the command line.  See gcc pr59828.  Hack around
+this by keeping sticky options for an early .machine.  */
+ asection *sec;
+ for (sec = stdoutput->sections; sec != NULL; sec = sec->next)
+   {
+ segment_info_type *info = seg_info (sec);
+ /* Are the frags for this section perturbed from their
+initial state?  Even .align will count here.  */
+ if (info != NULL
+ && (info->frchainP->frch_root != info->frchainP->frch_last
+ || info->frchainP->frch_root->fr_type != rs_fill
+ || info->frchainP->frch_root->fr_fix != 0))
+   break;
+   }
+ new_cpu = ppc_parse_cpu (ppc_cpu,
+  sec == NULL ? &sticky : &machine_sticky,
+  cpu_string);
  if (new_cpu != 0)
ppc_cpu = new_cpu;
  else

[Bug target/104121] [12 Regression] v850: Infinite loop in find_reload_regno_insns() since r12-5852-g50e8b0c9bca6cdc57804f860ec5311b641753fbb

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #8 from Sebastian Huber  ---
I can't reproduce the issue with the reduced test case, however, compiling the
preprocessed file still results in an infinite loop.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #18 from Sebastian Huber  ---
clang 11 produces this code for the attached test case:

clang -O2 -S -o - pr50883.c -target arm 
clang-11.0: warning: unknown platform, assuming -mfloat-abi=soft
clang-11.0: warning: unknown platform, assuming -mfloat-abi=soft
.text
.syntax unified
.eabi_attribute 67, "2.09"  @ Tag_conformance
.cpuarm7tdmi
.eabi_attribute 6, 2@ Tag_CPU_arch
.eabi_attribute 8, 1@ Tag_ARM_ISA_use
.eabi_attribute 9, 1@ Tag_THUMB_ISA_use
.eabi_attribute 34, 0   @ Tag_CPU_unaligned_access
.eabi_attribute 17, 1   @ Tag_ABI_PCS_GOT_use
.eabi_attribute 20, 1   @ Tag_ABI_FP_denormal
.eabi_attribute 21, 0   @ Tag_ABI_FP_exceptions
.eabi_attribute 23, 3   @ Tag_ABI_FP_number_model
.eabi_attribute 24, 1   @ Tag_ABI_align_needed
.eabi_attribute 25, 1   @ Tag_ABI_align_preserved
.eabi_attribute 38, 1   @ Tag_ABI_FP_16bit_format
.eabi_attribute 18, 4   @ Tag_ABI_PCS_wchar_t
.eabi_attribute 26, 2   @ Tag_ABI_enum_size
.eabi_attribute 14, 0   @ Tag_ABI_PCS_R9_use
.file   "pr50883.c"
.globl  f   @ -- Begin function f
.p2align2
.type   f,%function
.code   32  @ @f
f:
.fnstart
@ %bb.0:
mov r0, r1
bx  lr
.Lfunc_end0:
.size   f, .Lfunc_end0-f
.cantunwind
.fnend
@ -- End function
.globl  g   @ -- Begin function g
.p2align2
.type   g,%function
.code   32  @ @g
g:
.fnstart
@ %bb.0:
mov r0, r1
bx  lr
.Lfunc_end1:
.size   g, .Lfunc_end1-g
.cantunwind
.fnend
@ -- End function
.globl  h   @ -- Begin function h
.p2align2
.type   h,%function
.code   32  @ @h
h:
.fnstart
@ %bb.0:
ldr r1, .LCPI2_0
ldm r1, {r0, r1}
b   j
.p2align2
@ %bb.1:
.LCPI2_0:
.long   ss
.Lfunc_end2:
.size   h, .Lfunc_end2-h
.cantunwind
.fnend
@ -- End function
.globl  i   @ -- Begin function i
.p2align2
.type   i,%function
.code   32  @ @i
i:
.fnstart
@ %bb.0:
ldr r1, .LCPI3_0
ldm r1, {r0, r1}
b   k
.p2align2
@ %bb.1:
.LCPI3_0:
.long   tt
.Lfunc_end3:
.size   i, .Lfunc_end3-i
.cantunwind
.fnend
@ -- End function
.ident  "clang version 11.0.1"
.section".note.GNU-stack","",%progbits
.addrsig

[Bug target/104090] [10/11/12 Regression] powerpc: asm machine directive wrong for FSL processors

[sebastian.huber--- via Gcc-bugs]

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

Sebastian Huber  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Sebastian Huber  ---
Fixed on all relevant branches.

[Bug target/104121] [12 Regression] v850: Infinite loop in find_reload_regno_insns()

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #2 from Sebastian Huber  ---
Created attachment 52235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52235&action=edit
Pre-processed source file

[Bug target/104121] New: [12 Regression] v850: Infinite loop in find_reload_regno_insns()

[sebastian.huber--- via Gcc-bugs]

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

Bug ID: 104121
   Summary: [12 Regression] v850: Infinite loop in
find_reload_regno_insns()
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Building the current master branch for the v850-rtems target results in an
infinite loop in find_reload_regno_insns() while building libgcc:

/tmp/sh/b-gcc-v850-rtems6/v850-rtems6/v850e2v3/libgcc >
/tmp/sh/b-gcc-v850-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-v850-rtems6/./gcc/
-nostdinc -B/tmp/sh/b-gcc-v850-rtems6/v850-rtems6/newlib/ -isystem
/tmp/sh/b-gcc-v850-rtems6/v850-rtems6/newlib/targ-include -isystem
/home/EB/sebastian_h/src/gcc/newlib/libc/include
-B/tmp/sh/i-v850-rtems6/v850-rtems6/bin/
-B/tmp/sh/i-v850-rtems6/v850-rtems6/lib/ -isystem
/tmp/sh/i-v850-rtems6/v850-rtems6/include -isystem
/tmp/sh/i-v850-rtems6/v850-rtems6/sys-include-g -O2 -mv850e2v3 -O2
-I/home/EB/sebastian_h/src/gcc/libgcc/../newlib/libc/sys/rtems/include -g -O2
-DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include -mno-app-regs -msmall-sld -Wa,-mwarn-signed-overflow
-Wa,-mwarn-unsigned-overflow  -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc  -I. -I. -I../../.././gcc
-I/home/EB/sebastian_h/src/gcc/libgcc -I/home/EB/sebastian_h/src/gcc/libgcc/.
-I/home/EB/sebastian_h/src/gcc/libgcc/../gcc
-I/home/EB/sebastian_h/src/gcc/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS 
-o _muldc3.o -MT _muldc3.o -MD -MP -MF _muldc3.dep -DL_muldc3 -c
/home/EB/sebastian_h/src/gcc/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS -wrapper gdb,--args
GNU gdb (GDB; openSUSE Leap 15.2) 11.1
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /tmp/sh/b-gcc-v850-rtems6/./gcc/cc1...
(gdb) r
Starting program: /tmp/sh/b-gcc-v850-rtems6/gcc/cc1 -quiet -nostdinc -I
/home/EB/sebastian_h/src/gcc/libgcc/../newlib/libc/sys/rtems/include -I . -I .
-I ../../.././gcc -I /home/EB/sebastian_h/src/gcc/libgcc -I
/home/EB/sebastian_h/src/gcc/libgcc/. -I
/home/EB/sebastian_h/src/gcc/libgcc/../gcc -I
/home/EB/sebastian_h/src/gcc/libgcc/../include -imultilib v850e2v3 -iprefix
/tmp/sh/b-gcc-v850-rtems6/gcc/../lib64/gcc/v850-rtems6/12.0.1/ -isystem
/tmp/sh/b-gcc-v850-rtems6/./gcc/include -isystem
/tmp/sh/b-gcc-v850-rtems6/./gcc/include-fixed -MD _muldc3.d -MF _muldc3.dep -MP
-MT _muldc3.o -D__v850e2v3__ -D IN_GCC -D CROSS_DIRECTORY_STRUCTURE -D
IN_LIBGCC2 -D inhibit_libc -D HAVE_CC_TLS -D USE_EMUTLS -D L_muldc3 -D
HIDE_EXPORTS -isystem /tmp/sh/b-gcc-v850-rtems6/v850-rtems6/newlib/targ-include
-isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include -isystem
/tmp/sh/i-v850-rtems6/v850-rtems6/include -isystem
/tmp/sh/i-v850-rtems6/v850-rtems6/sys-include -isystem ./include
/home/EB/sebastian_h/src/gcc/libgcc/libgcc2.c -quiet -dumpbase _muldc3.c
-dumpbase-ext .c -mv850e2v3 -mno-app-regs -msmall-sld -g -g -g -O2 -O2 -O2
-Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -fbuilding-libgcc
-fno-stack-protector -fvisibility=hidden -o /tmp/ccXJQ7zz.s
Missing separate debuginfos, use: zypper install
glibc-debuginfo-2.26-lp152.26.12.1.x86_64
^C
Program received signal SIGINT, Interrupt.
0x00982526 in find_reload_regno_insns (finish=:
, start=: , regno=410) at
/home/EB/sebastian_h/src/gcc/gcc/lra-assigns.cc:1740
1740  if (next_insn != NULL && second_insn == NULL)
(gdb) n
1727   n != 1 && (prev_insn != NULL || next_insn != NULL); )
(gdb) 
1729  if (prev_insn != NULL && first_insn == NULL)
(gdb) 
1740  if (next_insn != NULL && second_insn == NULL)
(gdb) 
1727   n != 1 && (prev_insn != NULL || next_insn != NULL); )
(gdb) 
1729  if (prev_insn != NULL && first_insn == NULL)
(gdb) 
1740  if (next_insn != NULL && second_insn == NULL)
(gdb) 
1727   n != 1 && (prev_insn != NULL || next_insn != NULL); )
(gdb) 
1729  if (prev_insn != NULL && first_insn == NULL)
(gdb) 
1740

[Bug target/104090] [10/11/12 Regression] powerpc: asm machine directive wrong for FSL processors

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #1 from Sebastian Huber  ---
I work on a patch, see:

https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588641.html

[Bug target/104090] New: [10/11/12 Regression] powerpc: asm machine directive wrong for FSL processors

[sebastian.huber--- via Gcc-bugs]

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

Bug ID: 104090
   Summary: [10/11/12 Regression] powerpc: asm machine directive
wrong for FSL processors
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

The latest GCC 10/11/12 branches do not build the powerpc-rtems target due to a
build error in the -mcpu=8540 multilib:

/tmp/sh/b-gcc-powerpc-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-powerpc-rtems6/./gcc/
-nostdinc -B/tmp/sh/b-gcc-powerpc-rtems6/powerpc-rtems6/m8540/nof/newlib/
-isystem
/tmp/sh/b-gcc-powerpc-rtems6/powerpc-rtems6/m8540/nof/newlib/targ-include
-isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include
-B/tmp/sh/i-powerpc-rtems6/powerpc-rtems6/bin/
-B/tmp/sh/i-powerpc-rtems6/powerpc-rtems6/lib/ -isystem
/tmp/sh/i-powerpc-rtems6/powerpc-rtems6/include -isystem
/tmp/sh/i-powerpc-rtems6/powerpc-rtems6/sys-include  -mcpu=8540 -msoft-float -g
-O2 -O2 -I/home/EB/sebastian_h/src/gcc/libgcc/../newlib/libc/sys/rtems/include
-g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc  -I. -I. -I../../../.././gcc
-I/home/EB/sebastian_h/src/gcc/libgcc -I/home/EB/sebastian_h/src/gcc/libgcc/.
-I/home/EB/sebastian_h/src/gcc/libgcc/../gcc
-I/home/EB/sebastian_h/src/gcc/libgcc/../include  -DHAVE_CC_TLS  -o _negvdi2.o
-MT _negvdi2.o -MD -MP -MF _negvdi2.dep -DL_negvdi2 -c
/home/EB/sebastian_h/src/gcc/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
/tmp/ccZJ18fW.s: Assembler messages:
/tmp/ccZJ18fW.s:24: Error: unrecognized opcode: `isel'
make: *** [Makefile:501: _negvdi2.o] Error 1

The assembler is called like this:

/tmp/sh/b-gcc-powerpc-rtems6/./gcc/as -I
/home/EB/sebastian_h/src/gcc/libgcc/../newlib/libc/sys/rtems/include -I . -I .
-I ../../../.././gcc -I /home/EB/sebastian_h/src/gcc/libgcc -I
/home/EB/sebastian_h/src/gcc/libgcc/. -I
/home/EB/sebastian_h/src/gcc/libgcc/../gcc -I
/home/EB/sebastian_h/src/gcc/libgcc/../include -a32 -me500 -mbig -o _negvdi2.o
_negvdi2.s

Using -me500 seems to be all right, however, the file contains a machine
directive:

.file"libgcc2.c"
.machine ppc
.section".text"

If I remove the ".machine ppc" by hand, the file can be assembled with the
above command line.

The affect of the patch for PR100108 is:

diff -u _negvdi2.s.before _negvdi2.s.after
--- _negvdi2.s.before   2022-01-11 09:07:43.313828636 +0100
+++ _negvdi2.s.after2022-01-11 08:54:08.424946502 +0100
@@ -1,5 +1,5 @@
.file   "libgcc2.c"
-   .machine power9
+   .machine ppc
.section".text"
 .Ltext0:
.align 2

[Bug target/103150] New: Structure return is not optimized on 32-bit targets

[sebastian.huber--- via Gcc-bugs]

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

Bug ID: 103150
   Summary: Structure return is not optimized on 32-bit targets
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Consider the following test case:

struct timespec {
  long long tv_sec;
  long tv_nsec;
};

void  a(struct timespec *);
void  b(struct timespec *);

static inline struct timespec c(void)
{
  struct timespec t;

  a(&t);

  return t;
}

void f(void)
{
  struct timespec ts = c();
  b(&ts);
}

For the 64-bit targets (I checked x86_64, aarch64, riscv, powerpc) this is
optimized to:

aarch64-rtems6-gcc -O2 -S -o - getptr.c 
.arch armv8-a
.file   "getptr.c"
.text
.align  2
.p2align 4,,11
.global f
.type   f, %function
f:
stp x29, x30, [sp, -32]!
mov x29, sp
add x0, sp, 16
bl  a
add x0, sp, 16
bl  b
ldp x29, x30, [sp], 32
ret
.size   f, .-f
.ident  "GCC: (GNU) 10.3.1 20210409 (RTEMS 6, RSB
889cf95db0122bd1a6b21598569620c40ff2069d, Newlib eb03ac1)"

The pointer used to get the data from a() is directly passed to the consumer
b().

However, for 32-bit targets this test case seems to be not optimized and the
data is copied on the stack frame. For example:

arm-rtems6-gcc -O2 -S -o - getptr.c 
.cpu arm7tdmi
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.file   "getptr.c"
.text
.align  2
.global f
.arch armv4t
.syntax unified
.arm
.fpu softvfp
.type   f, %function
f:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 32
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, lr}
sub sp, sp, #32
add r4, sp, #16
mov r0, r4
bl  a
mov ip, sp
ldm r4, {r0, r1, r2, r3}
stm ip, {r0, r1, r2, r3}
mov r0, ip
bl  b
add sp, sp, #32
@ sp needed
pop {r4, lr}
bx  lr
.size   f, .-f
.ident  "GCC: (GNU) 10.3.1 20210409 (RTEMS 6, RSB
889cf95db0122bd1a6b21598569620c40ff2069d, Newlib eb03ac1)"

riscv-rtems6-gcc -O2 -S -o - getptr.c 
.file   "getptr.c"
.option nopic
.text
.align  1
.globl  f
.type   f, @function
f:
addisp,sp,-48
addia0,sp,16
sw  ra,44(sp)
calla
lw  a5,16(sp)
mv  a0,sp
sw  a5,0(sp)
lw  a5,20(sp)
sw  a5,4(sp)
lw  a5,24(sp)
sw  a5,8(sp)
lw  a5,28(sp)
sw  a5,12(sp)
callb
lw  ra,44(sp)
addisp,sp,48
jr  ra
.size   f, .-f
.ident  "GCC: (GNU) 10.3.1 20210409 (RTEMS 6, RSB
889cf95db0122bd1a6b21598569620c40ff2069d, Newlib eb03ac1)"

[Bug c/100357] unexpected behaviour of attribute noinit

[sebastian.huber--- via Gcc-bugs]

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

Sebastian Huber  changed:

   What|Removed |Added

Summary|attribute noinit with   |unexpected behaviour of
   |-fdata-sections unexpected  |attribute noinit
   |behaviour   |

--- Comment #1 from Sebastian Huber  ---
Consider the following test code:

__attribute__(( __noinit__ )) int a;

__attribute__(( __noinit__ )) int b;

On a target with a small data area (e.g. powerpc) this yields:

 powerpc-rtems6-gcc -O2 -S -o - test.c
.file   "test.c"
.machine ppc
.section".text"
.globl B
.globl a
.section.sbss,"aw",@nobits
.align 2
.type   B, @object
.size   B, 4
B:
.zero   4
.type   a, @object
.size   a, 4
a:
.zero   4
.ident  "GCC: (GNU) 10.2.1 20210113 (RTEMS 6, RSB
3d30ecae960152dd5a0e1be55de97dd46486ac53, Newlib 415fdd4)"
.section.note.GNU-stack,"",@progbits

On arm you get the expected result:
arm-rtems6-gcc -O2 -S -o - test.c
.cpu arm7tdmi
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.file   "test.c"
.text
.global B
.global a
.section.noinit,"aw"
.align  2
.type   B, %object
.size   B, 4
B:
.space  4
.type   a, %object
.size   a, 4
a:
.space  4
.ident  "GCC: (GNU) 10.2.1 20210113 (RTEMS 6, RSB
3d30ecae960152dd5a0e1be55de97dd46486ac53, Newlib 415fdd4)"

However, with -fdata-sections you get:

arm-rtems6-gcc -O2 -S -o - test.c -fdata-sections
.cpu arm7tdmi
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.file   "test.c"
.text
.global B
.global a
.section.bss.B,"aw",%nobits
.align  2
.type   B, %object
.size   B, 4
B:
.space  4
.section.bss.a,"aw",%nobits
.align  2
.type   a, %object
.size   a, 4
a:
.space  4
.ident  "GCC: (GNU) 10.2.1 20210113 (RTEMS 6, RSB
3d30ecae960152dd5a0e1be55de97dd46486ac53, Newlib 415fdd4)"

[Bug c/100357] New: attribute noinit with -fdata-sections unexpected behaviour

[sebastian.huber--- via Gcc-bugs]

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

Bug ID: 100357
   Summary: attribute noinit with -fdata-sections unexpected
behaviour
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Consider the following test code:

[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #8 from Sebastian Huber  ---
(In reply to Eric Botcazou from comment #7)
> > I still think that the profiling counter increment in the
> > __builtin_unreachable() path is a bug.
> 
> How so?  I only see a missed optimization, but with -fprofile-arcs
> -ftest-coverage you're splitting hairs IMO.

The __builtin_unreachable() explicitly mentions the use case with a function
which doesn't return in the documentation:

https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

I would expect from the compiler that it generates then similar code. Having a
profiling counter increment in one case and not in the other is not really a
nice behaviour.

[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #6 from Sebastian Huber  ---
(In reply to Eric Botcazou from comment #5)
> static void
> sparc_asm_function_epilogue (FILE *file)
> {
>   /* If the last two instructions of a function are "call foo; dslot;"
>  the return address might point to the first instruction in the next
>  function and we have to output a dummy nop for the sake of sane
>  backtraces in such cases.  This is pointless for sibling calls since
>  the return address is explicitly adjusted.  */

This nop behaviour could be a bit inconsistent across architectures. For
example, arm and powerpc don't generate a nop here.

I still think that the profiling counter increment in the
__builtin_unreachable() path is a bug.

[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #4 from Sebastian Huber  ---
(In reply to Andrew Pinski from comment #3)
> Is the nop due to alignment?

With -g and -coverage I get this code:

sparc-rtems7-gcc -O2 -o - -S unreachable.c -fverbose-asm -g -coverage
.file   "unreachable.c"
! GNU C17 (GCC) version 11.0.0 20210205 (RTEMS 7, RSB
61dcadee0825867ebe51f9f367430ef75b8fe9c0, Newlib d4a756f) (sparc-rtems7)
!   compiled by GNU C version 11.0.0 20201130 (experimental) [revision
b46314c78061a5156bac44a317c87d32b00d4295], GMP version 6.1.0, MPFR version
3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

! GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
! options passed: -mcpu=v7 -g -O2 -fprofile-arcs -ftest-coverage
.section".text"
.LLtext0:
.cfi_sections   .debug_frame
.align 4
.global g
.type   g, #function
.proc   020
g:
.LLFB0:
.file 1 "unreachable.c"
.loc 1 5 1 view -0
.cfi_startproc
save%sp, -96, %sp   !
.cfi_window_save
.cfi_register 15, 31
.cfi_def_cfa_register 30
sethi   %hi(__gcov0.g), %g1 !, tmp112
ldd [%g1+%lo(__gcov0.g)], %i4   ! __gcov0.g[0], __gcov0.g[0]
addcc   %i5, 1, %g3 ! __gcov0.g[0],, tmp115
addx%i4, 0, %g2 ! __gcov0.g[0],,
.loc 1 6 9 view .LLVU1
callr, 0!,
.LLVL0:
 std%g2, [%g1+%lo(__gcov0.g)]   ! tmp115, __gcov0.g[0]
nop

In the the no-return function case, this nop has no line debug information and
there is no profiling counter increment.

.cfi_endproc
.LLFE0:
.size   g, .-g
.align 4
.global f
.type   f, #function
.proc   020
f:
.LLFB1:
.loc 1 11 1 view -0
.cfi_startproc
save%sp, -96, %sp   !
.cfi_window_save
.cfi_register 15, 31
.cfi_def_cfa_register 30
sethi   %hi(__gcov0.f), %g1 !, tmp114
ldd [%g1+%lo(__gcov0.f)], %i2   ! __gcov0.f[0], __gcov0.f[0]
addcc   %i3, 1, %g3 ! __gcov0.f[0],, tmp117
addx%i2, 0, %g2 ! __gcov0.f[0],,
or  %g1, %lo(__gcov0.f), %i5! tmp114,, tmp113
.loc 1 12 9 view .LLVU3
callu, 0!,
.LLVL1:
 std%g2, [%g1+%lo(__gcov0.f)]   ! tmp117, __gcov0.f[0]
ldd [%i5+8], %i2! __gcov0.f[1], __gcov0.f[1]
addcc   %i3, 1, %g3 ! __gcov0.f[1],, tmp123
addx%i2, 0, %g2 ! __gcov0.f[1],,
std %g2, [%i5+8]! tmp123, __gcov0.f[1]
.loc 1 13 9 view .LLVU4
.cfi_endproc
.LLFE1:
.size   f, .-f

In the __builtin_unreachable() case we don't have a nop, but a profiling
counter increment is there.

clang 9 generates this code:

clang -O2 -o - -S unreachable.c -fverbose-asm -g -coverage --target=sparc
.text
.file   "unreachable.c"
.globl  g   ! -- Begin function g
.p2align2
.type   g,@function
g:  ! @g
.Lfunc_begin0:
.file   1 "/home/EB/sebastian_h/src/rtems/unreachable.c"
.loc1 5 0   ! unreachable.c:5:0
.cfi_startproc
! %bb.0:
save %sp, -96, %sp
.cfi_def_cfa_register %fp
.cfi_window_save
.cfi_register 15, 31
.Ltmp0:
.loc1 6 9 prologue_end  ! unreachable.c:6:9
sethi %hi(__llvm_gcov_ctr), %i0
ldd [%i0+%lo(__llvm_gcov_ctr)], %i2
addcc %i3, 1, %i5
addxcc %i2, 0, %i4
call r
std %i4, [%i0+%lo(__llvm_gcov_ctr)]
.Ltmp1:
.Lfunc_end0:
.size   g, .Lfunc_end0-g
.cfi_endproc
! -- End function
.globl  f   ! -- Begin function f
.p2align2
.type   f,@function
f:  ! @f
.Lfunc_begin1:
.loc1 11 0  ! unreachable.c:11:0
.cfi_startproc
! %bb.0:
save %sp, -96, %sp
.cfi_def_cfa_register %fp
.cfi_window_save
.cfi_register 15, 31
.Ltmp2:
.loc1 12 9 prologue_end ! unreachable.c:12:9
sethi %hi(__llvm_gcov_ctr.1), %i0
ldd [%i0+%lo(__llvm_gcov_ctr.1)], %i2
addcc %i3, 1, %i5
addxcc %i2, 0, %i4
call u
std %i4, [%i0+%lo(__llvm_gcov_ctr.1)]
.Ltmp3:
.Lfunc_end1:
.size   f, .Lfunc_end1-f
.cfi_endproc
! -- End function

There are no nops and no unreachable profiling counter increments.

[Bug c/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #2 from Sebastian Huber  ---
(In reply to Jakub Jelinek from comment #1)
> This is done intentionally, so that one gets e.g. usable backtraces from
> abort.

Ok, the stack frame could be a feature.

The extra nop on SPARC hurts a bit in my case since I have to show that my
program has no unreachable code and here I get an unreachable nop:

f:
save%sp, -96, %sp
callu, 0
 nop
nop <--- unreachable

[Bug c/99151] New: Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()

[sebastian.huber--- via Gcc-bugs]

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

Bug ID: 99151
   Summary: Missed optimization: Superfluous stack frame and code
with noreturn or __builtin_unreachable()
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

The following test code:

_Noreturn void r(void);
void u(void);

void g(void)
{
r();
}


void f(void)
{
u();
__builtin_unreachable();
}

Produces code the following code on a sample set of architectures. There should
be no stack frame set up. There should be no instructions after the no-return
function calls (for example sparc).

sparc-rtems6-gcc -O2 -o - -S unreachable.c 
.file   "unreachable.c"
.section".text"
.align 4
.global g
.type   g, #function
.proc   020
g:
save%sp, -96, %sp
callr, 0
 nop
nop
.size   g, .-g
.align 4
.global f
.type   f, #function
.proc   020
f:
save%sp, -96, %sp
callu, 0
 nop
nop
.size   f, .-f
.ident  "GCC: (GNU) 10.2.1 20210205 (RTEMS 6, RSB
61dcadee0825867ebe51f9f367430ef75b8fe9c0, Newlib d4a756f)"

arm-rtems6-gcc -O2 -o - -S unreachable.c 
.cpu arm7tdmi
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.file   "unreachable.c"
.text
.align  2
.global g
.arch armv4t
.syntax unified
.arm
.fpu softvfp
.type   g, %function
g:
@ Function supports interworking.
@ Volatile: function does not return.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, lr}
bl  r
.size   g, .-g
.align  2
.global f
.syntax unified
.arm
.fpu softvfp
.type   f, %function
f:
@ Function supports interworking.
@ Volatile: function does not return.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, lr}
bl  u
.size   f, .-f
.ident  "GCC: (GNU) 10.2.1 20210205 (RTEMS 6, RSB
61dcadee0825867ebe51f9f367430ef75b8fe9c0, Newlib d4a756f)"
powerpc-rtems6-gcc -O2 -o - -S unreachable.c 
.file   "unreachable.c"
.machine ppc
.section".text"
.align 2
.globl g
.type   g, @function
g:
.LFB0:
.cfi_startproc
stwu 1,-16(1)
.cfi_def_cfa_offset 16
mflr 0
stw 0,20(1)
.cfi_offset 65, 4
bl r
.cfi_endproc
.LFE0:
.size   g,.-g
.align 2
.globl f
.type   f, @function
f:
.LFB1:
.cfi_startproc
stwu 1,-16(1)
.cfi_def_cfa_offset 16
mflr 0
stw 0,20(1)
.cfi_offset 65, 4
bl u
.cfi_endproc
.LFE1:
.size   f,.-f
.ident  "GCC: (GNU) 10.2.1 20210205 (RTEMS 6, RSB
61dcadee0825867ebe51f9f367430ef75b8fe9c0, Newlib d4a756f)"
.section.note.GNU-stack,"",@progbits

[Bug target/98878] Incorrect multilib list for riscv*-rtems

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #1 from Sebastian Huber  ---
It may have something to do with TARGET_RISCV_DEFAULT_ABI == ilp32d. The
gcc/tm.h in the build tree contains this:

gcc/tm.h:#ifndef TARGET_RISCV_DEFAULT_ARCH
gcc/tm.h:# define TARGET_RISCV_DEFAULT_ARCH rv32gc
gcc/tm.h:#ifndef TARGET_RISCV_DEFAULT_ABI
gcc/tm.h:# define TARGET_RISCV_DEFAULT_ABI ilp32d

The rv32imafd/ilp32d multilib is the only multilib (except ".") which has also
this ABI. This could be checked by adding a rv32imfd/ilp32d multilib for
example.

[Bug ada/98595] [RISC-V, Ada] a-nallfl.ads:48:13: warning: profile of "Sin" doesn't match the builtin it binds

[sebastian.huber--- via Gcc-bugs]

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

Sebastian Huber  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Sebastian Huber  ---
Fixed by commit above.

[Bug ada/98595] New: [RISC-V, Ada] a-nallfl.ads:48:13: warning: profile of "Sin" doesn't match the builtin it binds

[sebastian.huber--- via Gcc-bugs]

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

Bug ID: 98595
   Summary: [RISC-V, Ada] a-nallfl.ads:48:13: warning: profile of
"Sin" doesn't match the builtin it binds
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

I am currently unable to build an riscv-rtems6 cross compiler with Ada support
using GCC 11. It works with GCC 10. I am not sure what the error is, the build
stops with:

/tmp/sh/src/rsb/rtems/build/riscv-rtems7-gcc-b87ec92-newlib-a485393-x86_64-linux-gnu-1/build/./gcc/xgcc
-B/tmp/sh/src/rsb/rtems/build/riscv-rtems7-gcc-b87ec92-newlib-a485393-x86_64-linux-gnu-1
/build/./gcc/ -nostdinc
-B/tmp/sh/src/rsb/rtems/build/riscv-rtems7-gcc-b87ec92-newlib-a485393-x86_64-linux-gnu-1/build/riscv-rtems7/newlib/
-isystem
/tmp/sh/src/rsb/rtems/build/riscv-rtems7-gcc-b87ec92-newlib-a485393-x86_64-linux-gnu-1/build/riscv-rtems7/newlib/targ-include
-isystem
/tmp/sh/src/rsb/rtems/build/riscv-rtems7-gcc-b87ec92-newlib-a485393-x86_64-linux-gnu-1/gnu-mirror-gcc-b87ec92/newlib/libc/include
-B/opt/rtems/7/riscv-rtems7/bin/ -B/opt/rtems/7/riscv-rtems7/lib/ -isystem
/opt/rtems/7/riscv-rtems7/include -isystem
/opt/rtems/7/riscv-rtems7/sys-include-c -g -O2   -W -Wall -gnatpg -nostdinc
  a-nallfl.ads -o a-nallfl.o
a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:48:13: warning: profile of "Sin" doesn't match the builtin it
binds
a-nallfl.ads:51:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:51:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:51:13: warning: profile of "Cos" doesn't match the builtin it
binds
a-nallfl.ads:54:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:54:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:54:13: warning: profile of "Tan" doesn't match the builtin it
binds
a-nallfl.ads:57:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:57:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:57:13: warning: profile of "Exp" doesn't match the builtin it
binds
a-nallfl.ads:60:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:60:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:60:13: warning: profile of "Sqrt" doesn't match the builtin it
binds
a-nallfl.ads:63:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:63:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:63:13: warning: profile of "Log" doesn't match the builtin it
binds
a-nallfl.ads:66:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:66:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:66:13: warning: profile of "Acos" doesn't match the builtin it
binds
a-nallfl.ads:69:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:69:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:69:13: warning: profile of "Asin" doesn't match the builtin it
binds
a-nallfl.ads:72:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:72:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:72:13: warning: profile of "Atan" doesn't match the builtin it
binds
a-nallfl.ads:75:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:75:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:75:13: warning: profile of "Sinh" doesn't match the builtin it
binds
a-nallfl.ads:78:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:78:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:78:13: warning: profile of "Cosh" doesn't match the builtin it
binds
a-nallfl.ads:81:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:81:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:81:13: warning: profile of "Tanh" doesn't match the builtin it
binds
a-nallfl.ads:84:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:84:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:84:13: warning: profile of "Pow" doesn't match the builtin it
binds
make[5]: *** [../gcc-interface/Makefile:302: a-nallfl.o] Error 1

[Bug target/98135] New: arm: Inconsistent automatic selection of FPU variant from -mcpu= and -march= options

[sebastian.huber--- via Gcc-bugs]

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

Bug ID: 98135
   Summary: arm: Inconsistent automatic selection of FPU variant
from -mcpu= and -march= options
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Since GCC 8, the FPU variant is derived from -mcpu= and -march= options. This
works well for the code generation by the compiler, but it doesn't work well
for the assembler if -mfpu=auto is not specified on the command line. For
example:

arm-rtems6-gcc -save-temps -c test.c -mthumb -march=armv8-r+crc+simd
-mfloat-abi=hard -wrapper echo
/tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/cc1 -E -quiet -D__USES_INITFINI__
test.c -mthumb -mfloat-abi=hard -march=armv8-r+crc+simd -fpch-preprocess -o
test.i
/tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/cc1 -fpreprocessed test.i -quiet
-dumpbase test.c -mthumb -mfloat-abi=hard -march=armv8-r+crc+simd -auxbase test
-o test.s
/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/as
-march=armv8-r+crc -mfloat-abi=hard -meabi=5 -o test.o test.s

The assembler is called without the "+simd".

It is discarded by arm_rewrite_selected_arch() probably because

(gdb) p *entry
$16 = {name = 0x4c1acc "simd", remove = false, alias = false, isa_bits =
{isa_bit_fp_d32, isa_bit_fp_dbl, isa_bit_fp16conv, isa_bit_fpv5, isa_bit_vfpv2,
isa_bit_vfpv3, isa_bit_vfpv4, isa_bit_neon, isa_nobit }}

and

#define ISA_ALL_FPU_INTERNAL \
  isa_bit_fp16conv, \
  isa_bit_crypto, \
  isa_bit_vfpv2, \
  isa_bit_vfpv3, \
  isa_bit_vfpv4, \
  isa_bit_fpv5, \
  isa_bit_neon, \
  isa_bit_fp_dbl, \
  isa_bit_fp_d32

So

(gdb) p/x fpu_bits
$17 = {m_bitmap = 0x778e60}
(gdb) p/x opt_bits
$18 = {m_bitmap = 0x778e20}

if (!bitmap_subset_p (opt_bits, fpu_bits))
optlist.push_back (entry->name);

doesn't push back entry->name.

The assembler doesn't complain about a -march=armv8-r+crc+simd and it makes the
assembler error go away. Probably older assembler versions doesn't support it.

What fixes the problem is adding the "-mfpu=auto" option. For example:

arm-rtems6-gcc -save-temps -c test.c -mthumb -march=armv8-a+crc+simd
-mfloat-abi=hard -mfpu=auto -wrapper echo
/tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/cc1 -E -quiet -D__USES_INITFINI__
test.c -mthumb -mfloat-abi=hard -mfpu=auto -march=armv8-a+crc+simd
-fpch-preprocess -o test.i
/tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/cc1 -fpreprocessed test.i -quiet
-dumpbase test.c -mthumb -mfloat-abi=hard -mfpu=auto -march=armv8-a+crc+simd
-auxbase test -o test.s
/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/as
-mfpu=neon-fp-armv8 -march=armv8-a+crc -mfloat-abi=hard -meabi=5 -o test.o
test.s

This is not really nice since the -mfpu=auto option seems to have no effect on
the code generation (compiler):

arm-rtems6-gcc -save-temps -E -P -v -dD test.c -mthumb -march=armv8-a+crc+simd
-mfloat-abi=hard -mfpu=auto > auto.txt 2>&1

arm-rtems6-gcc -save-temps -E -P -v -dD test.c -mthumb -march=armv8-a+crc+simd
-mfloat-abi=hard  > noauto.txt 2>&1

diff -u auto.txt noauto.txt
--- auto.txt2020-12-03 15:18:46.466141382 +0100
+++ noauto.txt  2020-12-03 15:18:52.282185710 +0100
@@ -5,8 +5,8 @@
 Thread model: rtems
 Supported LTO compression algorithms: zlib
 gcc version 10.2.1 20201203 [releases/gcc-10 revision
75a5af680a1:72d226ca97d:3444cb38a4d8df2c198ae5b4bdc747ff0c42a940] (GCC)
-COLLECT_GCC_OPTIONS='-save-temps' '-E' '-P' '-v' '-dD' '-mthumb'
'-mfloat-abi=hard' '-mfpu=auto' '-march=armv8-a+crc+simd'
- /tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/cc1 -E -quiet -v -P
-D__USES_INITFINI__ test.c -mthumb -mfloat-abi=hard -mfpu=auto
-march=armv8-a+crc+simd -fpch-preprocess -dD
+COLLECT_GCC_OPTIONS='-save-temps' '-E' '-P' '-v' '-dD' '-mthumb'
'-mfloat-abi=hard' '-march=armv8-a+crc+simd'
+ /tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/cc1 -E -quiet -v -P
-D__USES_INITFINI__ test.c -mthumb -mfloat-abi=hard -march=armv8-a+crc+simd
-fpch-preprocess -dD
 ignoring nonexistent directory
"/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/sys-include"
 #include "..." search starts here:
 #include <...> search starts here:
@@ -466,4 +466,4 @@
 #define __USES_INITFINI__ 1

COMPILER_PATH=/tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/:/tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/:/tmp/sh/rtems/6/lib/gcc/arm-rtems6/:/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/10.2.1/:/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/:/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/

LIBRARY_PATH=/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/10.2.1/:/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/lib/
-COLLECT_GCC_OPTIONS='-save-temps' '-E' '-P' '-v' '-dD' '-mthumb'
'-mfloat-abi=hard' '-mfpu=auto' '-march=armv8-a+crc+simd'
+COLLECT_GCC_OPTIONS='-save-temps' '-E' '-P' '-v' '-dD'