[Bug c/69960] "initializer element is not constant"

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

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

--- Comment #25 from Daniel Lundin  ---
(In reply to jos...@codesourcery.com from comment #24)
> On Thu, 23 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:
> 

Regardless of how one chose to read that part of the standard, fact remains
that this part of the standard has not changed since C89 but still gcc behaves
wildly different depending on version. This makes it impossible to port
strictly conforming programs between different gcc versions, because then
you'll either get a diagnostic that you (arguably) shouldn't be getting, or you
will not get a diagnostic where you (arguably) should be expecting one. 

This makes gcc a hazard in my case. My choices are to forbid newer versions or
to port to a different compiler. In case -pedantic would still result in a
diagnostic past version 8 then that would make gcc behave consistently across
versions and that would solve the problem. As was already mentioned previously
in this thread, before this change was implemented with that remark ignored.

Additionally there is bug #2 where (uint32_t)&function_pointer does not give a
diagnostic in case the pointer is 32 bit, which is non-conforming behavior for
constant expressions. I should perhaps open a separate bug report about that
since I'm not sure if it's related to this one.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #23 from Iain Sandoe  ---
(In reply to ibuclaw from comment #21)
> There is something about the Darwin ABI I'm just not getting from looking at
> the front-end alone though:
> 
> C++ Darwin 32-bit calling a method that returns an 8 byte struct:
> ```
> __Z4testP3Bar:
> subl$24, %esp
> movl28(%esp), %eax
> movl(%eax), %edx
> pushl   %eax// <--
> call*(%edx)
> ```

Darwin does not need an "sret" parameter since it will return the struct in
registers.
So it only passes "this".

> C++ Linux 32-bit calling a method that returns an 8 byte struct:
> ```
> _Z4testP3Bar:
> subl$44, %esp
> movl%gs:20, %edx
> movl%edx, 28(%esp)
> xorl%edx, %edx
> movl48(%esp), %eax
> leal8(%esp), %ecx
> subl$8, %esp
> movl(%eax), %edx
> pushl   %eax// <--
> pushl   %ecx// <--
> call*(%edx)
> ```

The Linux (SysV ABI arch-specific addition) says that structures are returned
via an sret param - for all size of struct.


So the ABIs differ in this (as noted on IRC, the Darwin 32b ABIs are not the
same as Linux).

[Bug target/108902] Conversions std::float16_t<->float with FP16C are not vectorized

[g.peterhoff--- via Gcc-bugs]

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

--- Comment #5 from g.peterh...@t-online.de ---
add test case (https://godbolt.org/z/q65cWKhWx)

void inc_builtin(array_t& arr)noexcept
{
auto load_cvt = [](const std::float16_t*const ptr) noexcept
{
return __builtin_convertvector(*((const __m128h*const)ptr), __m256);
};

auto save_cvt = [](std::float16_t* ptr, const __m256 arg)noexcept
{
*((__m128h*)ptr) = __builtin_convertvector(arg, __m128h);
};

for (std::size_t i=0; i

[Bug debug/108917] ICE when specifying optimization level and debuging for C++ contracts code

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-02-24

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
[[gnu::noipa]]
int f (int i) {
  return i + 100;
}

int g (int j) [[pre: f (j) < j ]] {
  return j;
}

```
It is the inlining of the contract into g which is causing the ICE.

[Bug testsuite/108730] gcc.target/powerpc/bfp/scalar-test-neg-8.c fails on power 9 BE

[linkw at gcc dot gnu.org via Gcc-bugs]

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

Kewen Lin  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||linkw at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
   Last reconfirmed||2023-02-24
  Component|target  |testsuite
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Kewen Lin  ---
The bif builtin_vsx_scalar_test_neg_qp is guarded with ieee128-hw, which
requires -m64, so the test case needs lp64 effective target.

  if (TARGET_FLOAT128_HW && !TARGET_64BIT)
{
  if ((rs6000_isa_flags_explicit & OPTION_MASK_FLOAT128_HW) != 0)
error ("%qs requires %qs", "%<-mfloat128-hardware%>", "-m64");

  rs6000_isa_flags &= ~OPTION_MASK_FLOAT128_HW;
}

[Bug target/108902] Conversions std::float16_t<->float with FP16C are not vectorized

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #3)
> Yes,  in sse.md the corresponding expanders are only defined under
> TARGET_AVX512FP16.

Even w/ -mavx512fp16, it's still not vectorized since it relied on
vec_unpacks_hi/lo_v*hf for loop vectorizer. BB vectorizer seems ok.

[Bug libstdc++/108918] New: PR107701 breaks windows targets

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 108918
   Summary: PR107701 breaks windows targets
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

https://github.com/gcc-mirror/gcc/commit/ec59848074ba8c4310cbadb603822bfaeff03a32

#include

int main()
{
std::cout<<"Hello World\n";
}

This is a simple program. As long as std::cout is used, the program crashes on
windows with DYNAMIC LINKING libstdc++. I believe it is due to the patch of GCC
here.

Although LLVM lld does not break, I do not know why gnu ld breaks. It looks
like it cannot handle the init_priority attribute properly on windows targets.


https://sourceware.org/bugzilla/show_bug.cgi?id=29973

[Bug c++/108917] New: ICE when specifying optimization level for C++ contracts code

[saifi.khan at nishan dot io via Gcc-bugs]

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

Bug ID: 108917
   Summary: ICE when specifying optimization level for C++
contracts code
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: saifi.khan at nishan dot io
  Target Milestone: ---

Environment
 - Linux  6.1.0-3-amd64 x86_64 GNU/Linux
 - Debian GLIBC 2.36-8) 2.36
 - gcc version 13.0.1 20230215 (experimental) (GCC)

was working through p2680r1 example with the code as follows.

---
auto f (int i) -> int {
  return i + 100;
}

int g (int j) [[pre: f (j) < j ]] {
  int r { j - f (j)};
  return 2 * r;
}

auto test () -> void {
  g (5);
}

---

::  g++ -std=c++23 -fcontracts contract_01.cc 
::  ./a.out 
contract violation in function g at contract_01.cc:8: f (j) < j
terminate called without an active exception
Aborted
::  

But this doesn't work !

::  g++ -std=c++23 -O3 -g2 -fcontracts contract_01.cc 
during RTL pass: final
contract_01.cc: In function ‘int g(int)’:
contract_01.cc:13:1: internal compiler error: in gen_inlined_subroutine_die, at
dwarf2out.cc:25002
   13 | }
  | ^
0x7d40a5 gen_inlined_subroutine_die
/opt/gcc/src/gcc/dwarf2out.cc:25002
0x7d40a5 gen_block_die
/opt/gcc/src/gcc/dwarf2out.cc:26487
0xe3b3ca decls_for_scope
/opt/gcc/src/gcc/dwarf2out.cc:26612
0xe18c93 gen_subprogram_die
/opt/gcc/src/gcc/dwarf2out.cc:24086
0xe1d82f gen_decl_die
/opt/gcc/src/gcc/dwarf2out.cc:27020
0xe1e60a dwarf2out_decl
/opt/gcc/src/gcc/dwarf2out.cc:27598
0xe1ea62 dwarf2out_function_decl
/opt/gcc/src/gcc/dwarf2out.cc:27613
0xea23e7 rest_of_handle_final
/opt/gcc/src/gcc/final.cc:4274
0xea23e7 execute
/opt/gcc/src/gcc/final.cc:4318
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.

[Bug tree-optimization/108916] Miss vectorization for masked gather w/o restrict qualifier.

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||49774, 53947
   Keywords||alias, missed-optimization

--- Comment #2 from Andrew Pinski  ---
I thought there was another bug about restrict and only one of the arguments
marked but I can't find it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49774
[Bug 49774] [meta-bug] restrict qualification aliasing issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/108916] Miss vectorization for masked gather w/o restrict qualifier.

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 Target||x86_64-*-* i?86-*-*

--- Comment #1 from Hongtao.liu  ---
https://godbolt.org/z/xxMjGhh5e

[Bug tree-optimization/108916] New: Miss vectorization for masked gather w/o restrict qualifier.

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 108916
   Summary: Miss vectorization for masked gather w/o restrict
qualifier.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

void
foo1 (double* __restrict a, long long* b, double* c, long long* d)
{
for (long long i = 0; i != 1; i++)
  {
if (b[i])
  a[i] = 0;
else
  a[i] = c[d[i]];
  }
}


void
foo2 (double* __restrict a, long long* b, double* __restrict c, long long* d)
{
for (long long i = 0; i != 1; i++)
  {
if (b[i])
  a[i] = 0;
else
  a[i] = c[d[i]];
  }
}

w/ -Ofast -march=skylake-avx512, foo1 can't be vectorized, but foo2 can, the
only difference between foo1 and foo2 is restrict qualifier for double* c.
But there's already a restrict qualifier for double* __restrict a in both
cases,   why double* __restrict c matters.

[Bug tree-optimization/108915] invalid pointer access preserved in optimized code

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #5 from Andrew Pinski  ---
(In reply to AK from comment #4)
> Adding `__attribute__((used))` also fixed it. Does it reflect the same
> behavior as using `asm` as you suggested?

NO.

[Bug target/108902] Conversions std::float16_t<->float with FP16C are not vectorized

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #3 from Hongtao.liu  ---
Yes,  in sse.md the corresponding expanders are only defined under
TARGET_AVX512FP16.

7275(define_expand "extend2"
 7276  [(set (match_operand:VF48H_AVX512VL 0 "register_operand")
 7277(float_extend:VF48H_AVX512VL
 7278  (match_operand: 1 "nonimmediate_operand")))]
 7279  "TARGET_AVX512FP16")


 7369(define_expand "trunc2"
 7370  [(set (match_operand: 0 "register_operand")
 7371(float_truncate:
 7372  (match_operand:VF48H_AVX512VL 1 "nonimmediate_operand")))]
 7373  "TARGET_AVX512FP16")

[Bug tree-optimization/108915] invalid pointer access preserved in optimized code

[hiraditya at msn dot com via Gcc-bugs]

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

AK  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #4 from AK  ---
Adding `__attribute__((used))` also fixed it. Does it reflect the same behavior
as using `asm` as you suggested?

[Bug tree-optimization/108915] invalid pointer access preserved in optimized code

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> The way to fix uboot code is to change the ll_entry_start/ll_entry_end to:

That is because you cannot take the difference between two distinct objects and
have a well defined answer. Nor can increment one from one distinct object into
another.

[Bug tree-optimization/108915] invalid pointer access preserved in optimized code

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
ll_start/ll_end needs a similar change.

[Bug tree-optimization/108915] invalid pointer access preserved in optimized code

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
static char start_bar[0]
says this is an array of size 0.

The reduced testcase does not match up with the code in uboot though.

Anyways GCC is correct for the reduced testcase, so is clang since it is
undefined as you are accessing outside of the bounds of the array.

The way to fix uboot code is to change the ll_entry_start/ll_entry_end to:


#define ll_entry_start(_type, _list)\
({  \
static char start[0] __aligned(CONFIG_LINKER_LIST_ALIGN)\
__attribute__((unused)) \
__section("__u_boot_list_2_"#_list"_1");\
_type * tmp = (_type *)&start;  \
asm("":"+r"(tmp));  \
tmp;\
})


#define ll_entry_end(_type, _list)  \
({  \
static char end[0] __aligned(4) __attribute__((unused)) \
__section("__u_boot_list_2_"#_list"_3");   
\
_type * tmp = (_type *)&end;\
asm("":"+r"(tmp));  \
tmp;\
})

[Bug c/108915] New: invalid pointer access preserved in optimized code

[hiraditya at msn dot com via Gcc-bugs]

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

Bug ID: 108915
   Summary: invalid pointer access preserved in optimized code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

Testcase has been reduced from u-boot's linker-list macro:
https://github.com/u-boot/u-boot/blob/master/include/linker_lists.h#L127


#include

char* bar() {
static char start_bar[0] __attribute__((aligned(16)))
   __attribute__((unused))
   __attribute__((section("__u_boot_list_2_1")));
char *p = (char *)start_bar;
for (int i = p[0]; i < p[9]; i++)
printf("asdfasd");
return 0;
}



$ gcc -O3 -fno-unroll-loops -S -o -

.LC0:
.string "asdfasd"
bar:
pushrbx
movsx   eax, BYTE PTR start_bar.1[rip+9]
movsx   ebx, BYTE PTR start_bar.1[rip]
cmp ebx, eax
jge .L2
.L3:
mov edi, OFFSET FLAT:.LC0
xor eax, eax
add ebx, 1
callprintf
movsx   eax, BYTE PTR start_bar.1[rip+9]
cmp eax, ebx
jg  .L3
.L2:
xor eax, eax
pop rbx
ret

-
$ clang -O3 -fno-unroll-loops -S -o -

bar:# @bar
xor eax, eax
ret

[Bug c/108914] during RTL pass: internal compiler error

[andreas.kanzler at outlook dot com via Gcc-bugs]

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

--- Comment #1 from Andreas Kanzler  ---
Created attachment 54524
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54524&action=edit
preprocessed file

[Bug c/108914] New: during RTL pass: internal compiler error

[andreas.kanzler at outlook dot com via Gcc-bugs]

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

Bug ID: 108914
   Summary: during RTL pass: internal compiler error
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andreas.kanzler at outlook dot com
  Target Milestone: ---

I noticed this bug in my current project. It occurs from GCC 10.3 or 10.4. The
project compiles with GCC 9.4 and 10.2 without problems, all versions above
seem to be affected.
I tested 9.4, 10.2, 10.4, 11.3 and 12.1 in Linux (Ubuntu 22.04 LTS and 20.04
LTS, Native and under Windows 11/WSL) and under Cygwin64, here only GCC 10.2
and 11.3.

Error Message from Cygwin, the error occurs during linking:
during RTL pass: ira
/cygdrive/e/RC-Dev/inav/src/main/fc/fc_core.c: In function ‘getAxisRcCommand’:
/cygdrive/e/RC-Dev/inav/src/main/fc/fc_core.c:170:1: internal compiler error:
Segmentation fault
  170 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: /usr/bin/gcc returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-cygw

Output from cmake, here from cygwin, but its similar in Linux/WSL
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
Target: x86_64-pc-cygwin
Configured with: /mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-11.3.0/configure
--srcdir=/mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-11.3.0 --prefix=/usr
--exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--with-gcc-major-version-only --enable-shared --enable-shared-libgcc
--enable-static --enable-version-specific-runtime-libs --enable-bootstrap
--enable-__cxa_atexit --with-dwarf2 --with-tune=generic
--enable-languages=c,c++,fortran,lto,objc,obj-c++,jit --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --enable-libquadmath
--enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers
--with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib
--enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible
--enable-libstdcxx-filesystem-ts
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (GCC)

COLLECT_GCC_OPTIONS='-D' 'FC_VERSION_MAJOR=6' '-D' 'FC_VERSION_MINOR=0' '-D'
'FC_VERSION_PATCH_LEVEL=0' '-D' 'HSE_VALUE=800' '-D' 'SITL' '-D'
'SITL_BUILD' '-D' '__FORKNAME__=inav' '-D' '__REVISION__="1af0e611"' '-D'
'__TARGET__="SITL"' '-I' '/cygdrive/e/RC-Dev/inav/src/main/target/SITL' '-I'
'/cygdrive/e/RC-Dev/inav/release/src/main/target/SITL/SITL' '-I'
'/cygdrive/e/RC-Dev/inav/lib' '-I' '/cygdrive/e/RC-Dev/inav/src/main' '-I'
'/cygdrive/e/RC-Dev/inav/lib/main/MAVLink' '-ggdb3' '-Os' '-D' 'NDEBUG' '-flto'
'-fno-fat-lto-objects' '-Wformat=0' '-Wno-return-local-addr'
'-fsingle-precision-constant' '-funsigned-char' '-v' '-save-temps' '-Wall'
'-Wextra' '-Wdouble-promotion' '-Wstrict-prototypes' '-Werror=switch'
'-std=gnu99' '-MD' '-MT'
'src/main/target/SITL/CMakeFiles/SITL.elf.dir/__/__/telemetry/telemetry.c.o'
'-MF' 'CMakeFiles/SITL.elf.dir/__/__/telemetry/telemetry.c.o.d' '-o'
'CMakeFiles/SITL.elf.dir/__/__/telemetry/telemetry.c.o' '-c' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'CMakeFiles/SITL.elf.dir/__/__/telemetry/'
 /usr/lib/gcc/x86_64-pc-cygwin/11/cc1.exe -E -quiet -v -I
/cygdrive/e/RC-Dev/inav/src/main/target/SITL -I
/cygdrive/e/RC-Dev/inav/release/src/main/target/SITL/SITL -I
/cygdrive/e/RC-Dev/inav/lib -I /cygdrive/e/RC-Dev/inav/src/main -I
/cygdrive/e/RC-Dev/inav/lib/main/MAVLink -MD
CMakeFiles/SITL.elf.dir/__/__/telemetry/telemetry.c.d -MF
CMakeFiles/SITL.elf.dir/__/__/telemetry/telemetry.c.o.d -MT
src/main/target/SITL/CMakeFiles/SITL.elf.dir/__/__/telemetry/telemetry.c.o -dD
-idirafter /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../lib/../include/w32api
-idirafter
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api
-D FC_VERSION_MAJOR=6 -D FC_VERSION_MINOR=0 -D FC_VERSION_PATCH_LEVEL=0 -D
HSE_VALUE=800 -D SITL -D SITL_BUILD -D __FORKNAME__=inav -D
__REVISION__="1af0e611" -D __TARGET__="SITL" -D NDEBUG
/cygdrive/e/RC-Dev/inav/src/main/telemetry/telemetry.c -mtune=generic
-march=x86-64 -std=gnu99 -Wformat=0 -Wno-return-local-addr -Wall -Wextra
-Wdouble-promotion -Wstrict-prototypes -Werror=switch -flto
-fno-fat-lto-objects -fsingle-precision-constant -funsigned-char -ggdb3
-fworking-directory -Os -fpch-preprocess -o
CMakeFiles/SITL.elf.dir/__/__/telemetry/telemetry.c.i
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-cygwin/11/incl

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #22 from ibuclaw at gcc dot gnu.org ---
(In reply to ibuclaw from comment #21)
> There is something about the Darwin ABI I'm just not getting from looking at
> the front-end alone though:
Taken from a test Iain had sent me, and I've subsequently modified.
```
struct Visibility
{
enum Kind
{
undefined, none, private_,
package_, protected_,
public_, export_
};
Kind kind;
void *pkg;
};

class Bar
{
public:
int x;
virtual Visibility vis ();
};

Visibility Bar::vis () { return Visibility (); }

class Foo  : public Bar
{
public:
Visibility v;
int y;
Visibility vis () override final;
};

Visibility Foo::vis () { return v; }

int test (Bar *foo)
{
Visibility vis;
vis = foo->vis ();
return vis.kind;
}
```

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #21 from ibuclaw at gcc dot gnu.org ---
There is something about the Darwin ABI I'm just not getting from looking at
the front-end alone though:

C++ Darwin 32-bit calling a method that returns an 8 byte struct:
```
__Z4testP3Bar:
subl$24, %esp
movl28(%esp), %eax
movl(%eax), %edx
pushl   %eax// <--
call*(%edx)
```

C++ Linux 32-bit calling a method that returns an 8 byte struct:
```
_Z4testP3Bar:
subl$44, %esp
movl%gs:20, %edx
movl%edx, 28(%esp)
xorl%edx, %edx
movl48(%esp), %eax
leal8(%esp), %ecx
subl$8, %esp
movl(%eax), %edx
pushl   %eax// <--
pushl   %ecx// <--
call*(%edx)
```

[Bug testsuite/108898] [13 Regression] Test introduced by r13-6278-g3da77f217c8b2089ecba3eb201e727c3fcdcd19d failed on i386

[haochen.jiang at intel dot com via Gcc-bugs]

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

--- Comment #2 from Haochen Jiang  ---
(In reply to Andrew Stubbs from comment #1)
> I tested it on i686-pc-linux-gnu before I posted the patch, and it was
> working then. Can you be more specific what configuration you were testing,
> please?

For fail
FAIL: gcc.dg/vect/vect-simd-clone-18e.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-18e.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-18f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-18f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-18f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2

We can reproduce by:

$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18f.c
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18f.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18f.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18e.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18e.c
--target_board='unix{-m32\ -march=cascadelake}'"

[Bug testsuite/108899] [13 Regression] ERROR: can't rename to "saved-unsupported": command already exists on i386

[haochen.jiang at intel dot com via Gcc-bugs]

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

--- Comment #9 from Haochen Jiang  ---
(In reply to Jakub Jelinek from comment #8)
> Should be fixed now.

Sorry for the late reply.

Yes, it fixed for me now. Thx a lot!

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #20 from ibuclaw at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #19)
> (In reply to Andrew Pinski from comment #18)
> > > I think the visibility type is POD (assuming D has that concept)
> 
> At least the front-end does.
> See dmd/dstruct.d:443
> 
> if isPOD return false, TREE_ADDRESSABLE is set on the struct.
> I have not gone through the code otherwise.
See d/decl.cc:950

It's not TREE_ADDRESSABLE, but on 32-bit the struct is considered to be
'aggregate_value_p', which in turn sets up return by hidden reference.

This effects how the return is handled later (around toir.cc:1044), which
splits up the init and return expression.  Returning this way I guess is fine
for extern(D) functions, however we should not be so eager to do rvo/sret for
other extern language functions.

Having a quick look at C++ front-end, they require both `aggregate_value_p` and
for a named variable to be in the return expression.

```
  if (current_function_return_value)
{
  tree r = current_function_return_value;
  tree outer;

  if (r != error_mark_node
  /* This is only worth doing for fns that return in memory--and
 simpler, since we don't have to worry about promoted modes.  */
  && aggregate_value_p (TREE_TYPE (TREE_TYPE (fndecl)), fndecl)
```

So for the current gate in D:
```
if (TREE_ADDRESSABLE (TREE_TYPE (resdecl))
|| aggregate_value_p (TREE_TYPE (resdecl), fndecl))
```

I think tightening that to (its late, and my parentheses may be wrong).
```
if (TREE_ADDRESSABLE (TREE_TYPE (resdecl))
|| ((d->resolvedLinkage () == LINK::d
 || (d->resolvedLinkage () == LINK::cpp && d->nrvo_var))
&& aggregate_value_p (TREE_TYPE (resdecl), fndecl)))
```
Which is:
1. TREE_ADDRESSABLE
2. extern(D) and aggregate_value_p
3. extern(C++) and have NVRO variable and aggregate_value_p

I guess for extern(C) functions we should just forget even attempting to do any
(N)RVO/SRET returns and let tree-nrv.cc decide whether to optimize or not.

[Bug target/108881] "__builtin_ia32_cvtne2ps2bf16_v16hi" compiled only with option -mavx512bf16 report ICE.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 54520 [details]
> gcc13-pr108881.patch
> 
> Untested fix.

Yes, patch LGTM.

[Bug other/108907] ira-color.cc:3028:1: error: definition in block 5 follows the use

[danglin at gcc dot gnu.org via Gcc-bugs]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #2 from John David Anglin  ---
Resolved by PR 10 fix.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #19 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #18)
> > I think the visibility type is POD (assuming D has that concept)

At least the front-end does.
See dmd/dstruct.d:443

if isPOD return false, TREE_ADDRESSABLE is set on the struct.
I have not gone through the code otherwise.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from Andrew Pinski  ---
(In reply to Iain Sandoe from comment #17)
> (In reply to Andrew Pinski from comment #15)
> > (In reply to Iain Sandoe from comment #14)
> > > So it would seem that we might want to find a reproducer that we can look 
> > > at
> > > the various tree dumps and see if/where an sret is introduced?
> > > 
> > > (if that's not the cause, then we'll have to find a new hypothesis)
> > 
> > POD vs non-POD (I think TYPE_ADDRESSABLE causes the difference but I am not
> > 100% sure ...)
> 
> I think the visibility type is POD (assuming D has that concept)

Something is TREE_ADDRESSABLE on the D Visibility  type ...

This is the mismatch that is happening.

[Bug c++/107938] [11/12/13 Regression] ICE directly returning `this` of `extern` variable in template since r11-557

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Marek Polacek  ---
Patch posted:

[Bug debug/108905] Debugging information refers to the wrong file with function defined in toplevel inline-asm

[lveyde at redhat dot com via Gcc-bugs]

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

--- Comment #2 from Lev Veyde  ---
So the incorrect filename and line comes from not setting it properly in inline
assembly the macro resolves to?

So it's basically an issue in the Linux kernel source code?

I tried to add .line to the inline assembly code and it didn't really had any
effect on the compiled kernel, as far as debugging info for the symbol is
concerned. However I'm not 100% certain that I did it correctly.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from Iain Sandoe  ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Iain Sandoe from comment #14)
> > So it would seem that we might want to find a reproducer that we can look at
> > the various tree dumps and see if/where an sret is introduced?
> > 
> > (if that's not the cause, then we'll have to find a new hypothesis)
> 
> POD vs non-POD (I think TYPE_ADDRESSABLE causes the difference but I am not
> 100% sure ...)

I think the visibility type is POD (assuming D has that concept)

struct Visibility
{
   enum Kind
   {
   undefined,
   none,   // no access
   private_,
   package_,
   protected_,
   public_,
   export_
   };
   Kind kind;
   void *pkg;
};

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #14)
> (In reply to ibuclaw from comment #13)

> If the caller is passing two regs it seems to me likely that (for some
> reason it thinks that the value is returned via an sret pointer).
> 
> The callee then get s the set pointer in the register it is expecting *this
> to be in... and boom .. we are broken at some point,
> 
> So it would seem that we might want to find a reproducer that we can look at
> the various tree dumps and see if/where an sret is introduced?
> 
> (if that's not the cause, then we'll have to find a new hypothesis)

oops I misread the D callee asm .. it looks like the D callee is expecting an
sret.

So ISTM that somehow D is not getting the right answer to "does this ABI pass
by sret for this size of struct"?

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #15 from Andrew Pinski  ---
(In reply to Iain Sandoe from comment #14)
> So it would seem that we might want to find a reproducer that we can look at
> the various tree dumps and see if/where an sret is introduced?
> 
> (if that's not the cause, then we'll have to find a new hypothesis)

POD vs non-POD (I think TYPE_ADDRESSABLE causes the difference but I am not
100% sure ...)

[Bug target/108874] [10/11/12/13 Regression] Missing bswap detection

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-02-23
 Target|arm |arm, aarch64
   Keywords|needs-bisection |
 Status|UNCONFIRMED |NEW

--- Comment #5 from Andrew Pinski  ---
How it worked before because of the following combine, removing 1 instruction
and then doing the 4->1 matching:

Trying 7 -> 10:

(set (reg:SI 80 [ D.3188 ])
(ior:SI (lshiftrt:SI (reg:SI 81 [ D.3187 ])
(const_int 8 [0x8]))
(reg:SI 84 [ D.3187 ])))



So we could match add a pattern/split that matching this combine:
Trying 6, 7 -> 10:
6: r99:SI=r97:SI 0>>0x8
7: r100:SI=r99:SI&0xff00ff
  REG_DEAD r99:SI
   10: r98:SI=r100:SI|r102:SI
  REG_DEAD r102:SI
  REG_DEAD r100:SI
Failed to match this instruction:
(set (reg:SI 98)
(ior:SI (and:SI (lshiftrt:SI (reg/v:SI 97 [ x ])
(const_int 8 [0x8]))
(const_int 16711935 [0xff00ff]))
(reg:SI 102)))

into two, pushing the and before the shift right.

Note this would require modifying both the arm and aarch64 backends but it
seems doable.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from Iain Sandoe  ---
(In reply to ibuclaw from comment #13)
> Confirmed, D is doing NRVO return whereas C++ isn't.

I am not sure that the NVRO is the issue (it is correct ABI for an 8 byte
struct to be returned in EAX:EDX).  The value can be "created" in the return
slot (i.e. doing the NVRO) without altering that.

--

If the caller is passing two regs it seems to me likely that (for some reason
it thinks that the value is returned via an sret pointer).

The callee then get s the set pointer in the register it is expecting *this to
be in... and boom .. we are broken at some point,

So it would seem that we might want to find a reproducer that we can look at
the various tree dumps and see if/where an sret is introduced?

(if that's not the cause, then we'll have to find a new hypothesis)

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from ibuclaw at gcc dot gnu.org ---
Confirmed, D is doing NRVO return whereas C++ isn't.

gdc-11 codegen of the `visible` method:

---
struct Visibility visible (struct AggregateDeclaration * const this)
{
  return  = this->visibility;
}
---

vs. gdc-mainline
---
struct Visibility visible (struct AggregateDeclaration * const this)
{
   = this->visibility;
  return ;
}
---

[Bug c++/108913] GCC 12.1.0 h8300 ICE building libstdc++

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Fixed on the trunk already.

*** This bug has been marked as a duplicate of bug 101697 ***

[Bug target/101697] [11/12 regression] ICE compiling uClibc-ng for h8300-linux

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mike at mnmoran dot org

--- Comment #11 from Andrew Pinski  ---
*** Bug 108913 has been marked as a duplicate of this bug. ***

[Bug c++/108913] New: GCC 12.1.0 h8300 ICE building libstdc++

[mike at mnmoran dot org via Gcc-bugs]

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

Bug ID: 108913
   Summary: GCC 12.1.0 h8300 ICE building libstdc++
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mike at mnmoran dot org
  Target Milestone: ---

Created attachment 54523
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54523&action=edit
Output of -freport-bug

ICE when building libstdc++ for h8300 cross-compiler.
I'm in the process of updating my cross-compilers for the first time in many
years. Many of the cross-compilers (e.g., m68k-none-elf, mips-none-elf,
powerpc-none-eabi )build without issues.

See the attachment for the -freport-bug output.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from ibuclaw at gcc dot gnu.org ---
Looks like a bad mismatch between C++ and D.

When C++ calls the method, it pushes one register.  When D calls it, pushes
two.

Looks like the method itself returns the result in 2 registers as well - or
maybe uses return slot optimization.
---
// C++ Caller code
#include "tree.h"
#include "dmd/dsymbol.h"
#include "dmd/aggregate.h"
void
set_visibility_for_decl (tree node, Dsymbol *sym)
{
  Visibility visibility = sym->visible ();

// C++ Caller asm
pushl   %ebx
subl$20, %esp
.loc 1 2561 1
movl32(%esp), %eax
movl28(%esp), %ebx
.loc 1 2562 40
movl(%eax), %edx
pushl   %eax
call*104(%edx)

// D Caller code
import dmd.dsymbol;
import dmd.aggregate;
import dmd.gluelayer;
extern(C++)
void
set_visibility_for_decl (tree_node* node, Dsymbol sym)
{
  Visibility visibility = sym.visible();
}
// D Caller asm
subl$28, %esp
.loc 1 5 1
movl36(%esp), %eax
.loc 1 8 27
leal8(%esp), %ecx
subl$8, %esp
movl(%eax), %edx
pushl   %eax
pushl   %ecx
call*104(%edx)

// D Callee code
override final Visibility visible() pure nothrow @nogc @safe
{
  return visibility;
}
// D Callee asm
movl8(%esp), %edx
movl4(%esp), %eax
.loc 1 789 9
movl208(%edx), %ecx
movl212(%edx), %edx
movl%ecx, (%eax)
movl%edx, 4(%eax)
.loc 1 790 5
ret $4

[Bug tree-optimization/108912] A -Wstringop-overflow false positive in aarch64-linux-gnu-gcc 12.2.0

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Wan-Teh Chang from comment #4)
> Andrew: Thank you very much for the quick reply.
> 
> I am also curious about the 15 number. Do you know why the compiler seems to
> think cfg->stage_num_col and cfg->stage_num_row can be equal to 15? I.e.,
> why do the warnings go away if I increase the array size to 15?

It is just an over-vectorization/unrolling of the loop. I am not 100% sure but
I think it is the epilogue of the vectorized loop which is max of 15. That is
the vector version of the loop can be 16 char at a time but the epilogue will
be max 15 of size.

[Bug tree-optimization/108912] A -Wstringop-overflow false positive in aarch64-linux-gnu-gcc 12.2.0

[wtc at google dot com via Gcc-bugs]

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

--- Comment #4 from Wan-Teh Chang  ---
Andrew: Thank you very much for the quick reply.

I am also curious about the 15 number. Do you know why the compiler seems to
think cfg->stage_num_col and cfg->stage_num_row can be equal to 15? I.e., why
do the warnings go away if I increase the array size to 15?

[Bug tree-optimization/108912] A -Wstringop-overflow false positive in aarch64-linux-gnu-gcc 12.2.0

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Wan-Teh Chang from comment #1)
> Also, I don't get these warnings if I compile with /usr/bin/cc on my Debian
> x86_64 GNU/Linux system, which has the following verison:

That is because the autovectorizer is doing it slightly different for x86_64 vs
aarch64.

[Bug tree-optimization/108912] A -Wstringop-overflow false positive in aarch64-linux-gnu-gcc 12.2.0

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
So the vectorizer is over vectorizing this code slightly.
The easiest fix is at add:

if (stage_num_col > 12) __builtin_unreachable();

and

if (stage_num_row > 12) __builtin_unreachable();

I thought there was another bug related to this warning/vectorizer over
vectorizing but I can't find it right now.

[Bug tree-optimization/108912] A -Wstringop-overflow false positive in aarch64-linux-gnu-gcc 12.2.0

[wtc at google dot com via Gcc-bugs]

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

--- Comment #1 from Wan-Teh Chang  ---
If I increase the size of the `stage_range_col` and `stage_range_row` arrays in
the `TXFM_2D_FLIP_CFG` struct from 12 to 13, 14, 15, the warning messages
change and eventually disappear when the array size becomes 15. This seems to
imply the compiler somehow thinks cfg->stage_num_col and cfg->stage_num_row can
be equal to 15, but I can't figure out how the compiler arrives at the 15
number.

Also, I don't get these warnings if I compile with /usr/bin/cc on my Debian
x86_64 GNU/Linux system, which has the following verison:

$ /usr/bin/cc --version
cc (Debian 12.2.0-10) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug translation/108890] Translation mistakes 2023

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:7423f5b56ad436f51ac1b9defb954e2bdc5b06ab

commit r13-6307-g7423f5b56ad436f51ac1b9defb954e2bdc5b06ab
Author: Jakub Jelinek 
Date:   Thu Feb 23 23:26:43 2023 +0100

xtensa: Fix up fatal_error message strings in xtensa-dynconfig.c [PR108890]

The translation PR complains that these 4 messages from xtensa-dynconfig.c
are marked in po/gcc.pot as c-format (which doesn't allow %qs) while they
should be gcc-internal-format.

The problem is in the manual translation of the strings with _(),
that should be both unnecessary because fatal_error invokes _() on its
argument already, but also incorrect for the above reason, for
gcc-internal-format strings one should use G_("...") instead if really
needed.

The following patch drops those _("..."), tested by regenerating po/gcc.pot
to see they are now gcc-internal-format, but not really tested on xtensa
target.

2023-02-23  Jakub Jelinek  

PR translation/108890
* config/xtensa/xtensa-dynconfig.c (xtensa_load_config): Drop _()s
around fatal_error format strings.

[Bug c/108912] New: A -Wstringop-overflow false positive in aarch64-linux-gnu-gcc 12.2.0

[wtc at google dot com via Gcc-bugs]

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

Bug ID: 108912
   Summary: A -Wstringop-overflow false positive in
aarch64-linux-gnu-gcc 12.2.0
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wtc at google dot com
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54522&action=edit
Reduced test case

Steps to reproduce:

1. Save the attachment in a file named av1_fwd_txfm2d.c.

2. On a Debian x86_64 GNU/Linux system, install the gcc-aarch64-linux-gnu
package:

$ sudo apt install gcc-aarch64-linux-gnu

3. Check the compiler version:

$ /usr/bin/aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (Debian 12.2.0-3) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

4. Compile the av1_fwd_txfm2d.c file with the following command line:

$ /usr/bin/aarch64-linux-gnu-gcc -march=armv8-a -O3 -DNDEBUG -std=c99 -Wall
-Wdisabled-optimization -Wextra -Wfloat-conversion -Wformat=2
-Wimplicit-function-declaration -Wlogical-op -Wpointer-arith -Wsign-compare
-Wtype-limits -Wuninitialized -Wunused -Wvla -Wstack-usage=10 -Wshadow
-Wundef -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -fPIC -o av1_fwd_txfm2d.o -c av1_fwd_txfm2d.c

The compiler emits the following warnings:

In function ‘set_fwd_txfm_non_scale_range’,
inlined from ‘av1_get_fwd_txfm_cfg’ at av1_fwd_txfm2d.c:86:3:
av1_fwd_txfm2d.c:64:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   64 |   cfg->stage_range_col[i] = (range_mult2_col[i] + 1) >> 1;
  |   ^~~
av1_fwd_txfm2d.c: In function ‘av1_get_fwd_txfm_cfg’:
av1_fwd_txfm2d.c:23:10: note: at offset 12 into destination object
‘stage_range_col’ of size 12
   23 |   int8_t stage_range_col[12];
  |  ^~~
In function ‘set_fwd_txfm_non_scale_range’,
inlined from ‘av1_get_fwd_txfm_cfg’ at av1_fwd_txfm2d.c:86:3:
av1_fwd_txfm2d.c:64:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   64 |   cfg->stage_range_col[i] = (range_mult2_col[i] + 1) >> 1;
  |   ^~~
av1_fwd_txfm2d.c: In function ‘av1_get_fwd_txfm_cfg’:
av1_fwd_txfm2d.c:23:10: note: at offset 13 into destination object
‘stage_range_col’ of size 12
   23 |   int8_t stage_range_col[12];
  |  ^~~
In function ‘set_fwd_txfm_non_scale_range’,
inlined from ‘av1_get_fwd_txfm_cfg’ at av1_fwd_txfm2d.c:86:3:
av1_fwd_txfm2d.c:72:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   72 |   cfg->stage_range_row[i] =
  |   ^
   73 |   (range_mult2_col[cfg->stage_num_col - 1] + range_mult2_row[i]
+ 1) >>
  |  
~
   74 |   1;
  |   ~
av1_fwd_txfm2d.c: In function ‘av1_get_fwd_txfm_cfg’:
av1_fwd_txfm2d.c:24:10: note: at offset 12 into destination object
‘stage_range_row’ of size 12
   24 |   int8_t stage_range_row[12];
  |  ^~~
In function ‘set_fwd_txfm_non_scale_range’,
inlined from ‘av1_get_fwd_txfm_cfg’ at av1_fwd_txfm2d.c:86:3:
av1_fwd_txfm2d.c:72:31: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   72 |   cfg->stage_range_row[i] =
  |   ^
   73 |   (range_mult2_col[cfg->stage_num_col - 1] + range_mult2_row[i]
+ 1) >>
  |  
~
   74 |   1;
  |   ~
av1_fwd_txfm2d.c: In function ‘av1_get_fwd_txfm_cfg’:
av1_fwd_txfm2d.c:24:10: note: at offset 13 into destination object
‘stage_range_row’ of size 12
   24 |   int8_t stage_range_row[12];
  |  ^~~

[Bug libgcc/108891] libatomic: AArch64 SEQ_CST 16-byte load missing barrier

[wilco at gcc dot gnu.org via Gcc-bugs]

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

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-02-23
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |wilco at gcc dot gnu.org

[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package

[kurt at garloff dot de via Gcc-bugs]

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

--- Comment #17 from Kurt Garloff  ---
jIt fixes it. Fix committed to git (on bad old sf.net).
Will release new dd_rescue tomorrow ...

Thanks, Martin, Jakub, Andrew for analyzing this!

[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jakub Jelinek  ---
There is another bug, in darktable actually such overaligned pointer isn't
passed, but it is cvise reduced into:
$ cat color_picker.c
void
bar (void)
{
  float *__attribute__((aligned(64))) x;
}
$ cat color_vocabulary.c
int a, b, c;

void
foo (void)
{
  c = __builtin_cosf (2.0f * 3.14159265358979324f * a);
  b = __builtin_sinf (2.0f * 3.14159265358979324f * a);
}
$ ./xgcc -B ./ -c -flto=auto -ffat-lto-objects -g -O3 -ffast-math
-fno-finite-math-only -fPIC -fexpensive-optimizations color_picker.c
$ ./xgcc -B ./ -c -flto=auto -ffat-lto-objects -g -O3 -ffast-math
-fno-finite-math-only -fPIC -fexpensive-optimizations color_vocabulary.c
$ ./xgcc -B ./  -flto=auto -ffat-lto-objects -o color_picker -r color_picker.o
color_vocabulary.o
during RTL pass: expand
color_vocabulary.c: In function ‘foo’:
color_vocabulary.c:4:1: internal compiler error: in aarch64_layout_arg, at
config/aarch64/aarch64.cc:7688
4 | foo (void)
  | ^
0x118d493 aarch64_layout_arg
../../gcc/config/aarch64/aarch64.cc:7688
0x118dd7a aarch64_function_arg
../../gcc/config/aarch64/aarch64.cc:7868
0x92080b initialize_argument_information
../../gcc/calls.cc:1499
0x925273 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.cc:2973
0x90a2da expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/builtins.cc:8452
0xa5ecfe expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.cc:11872
0x8f638d expand_builtin_cexpi
../../gcc/builtins.cc:2685
0x9077ee expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/builtins.cc:7476
0xa5ecfe expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.cc:11872
0xa694b5 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.cc:6333
0xa6bbf0 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.cc:6051
0x93866a expand_call_stmt
../../gcc/cfgexpand.cc:2829
0x93866a expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3880
0x93866a expand_gimple_stmt
../../gcc/cfgexpand.cc:4044
0x93e0c6 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6096
0x93fa67 execute
../../gcc/cfgexpand.cc:6831
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.
lto-wrapper: fatal error: ./xgcc returned 1 exit status
compilation terminated.
/usr/bin/aarch64-linux-gnu-ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

Now, I believe the reason why this #c0 bug triggers even when the aligned (64)
pointer appears in completely unrelated function
is that while without LTO, TYPE_POINTER_TO/TYPE_NEXT_PTR_TO is only registered
for types actually created with build_pointer_type_for_mode,
so pretty much for type with basic alignment, no extra attributes, no
cv-qualification/TYPE_ADDR_SPACE etc. (note, I'm talking
about the POINTER_TYPE, not what it points to), during LTO streaming in that is
all of sudden not the case.
LTO streaming itself doesn't do anything about those, but then
lto_fixup_prevailing_type can add there some other POINTER_TYPE
which as in the testcase has TYPE_USER_ALIGN, or could have any other weird
stuff.  I think we should add to TYPE_POINTER_TO
chain only if it is really a pointer type without any of those extras and only
if such a type doesn't appear in the chain already.

[Bug c++/108911] New: 0xe+100 gives talks about an impossible literal operator in error message

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 108911
   Summary: 0xe+100 gives talks about an impossible literal
operator in error message
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
  int a = 0xe+100;
```
The C++ front-end gives:
:1:11: error: unable to find numeric literal operator 'operator""+100'
1 |   int a = 0xe+100;
  |   ^~~

But there is no way to have a numeric literal operator named that ..
Note erroring out is correct, I am just saying the diagnostic should be
improved.

[Bug preprocessor/24976] [10/11/12/13 Regression] simple hexadecimal number and plus/minus and no space

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #27 from Andrew Pinski  ---
Something like this should improve the diagnostic, note the patch needs to be
improved for wrapping:
diff --git a/libcpp/expr.cc b/libcpp/expr.cc
index 6e5bf68eae9..f70be382dd4 100644
--- a/libcpp/expr.cc
+++ b/libcpp/expr.cc
@@ -728,7 +728,7 @@ cpp_classify_number (cpp_reader *pfile, const cpp_token
*token,
  else
{
  cpp_error_with_line (pfile, CPP_DL_ERROR, virtual_location, 0,
-  "invalid suffix \"%.*s\" on floating
constant",
+  "invalid suffix \"%.*s\" on floating
constant (maybe missing a space)",
   (int) (limit - str), str);
  return CPP_N_INVALID;
}
@@ -753,7 +753,7 @@ cpp_classify_number (cpp_reader *pfile, const cpp_token
*token,
   if ((result & CPP_N_DFLOAT) && radix != 10)
 {
   cpp_error_with_line (pfile, CPP_DL_ERROR, virtual_location, 0,
-  "invalid suffix \"%.*s\" with hexadecimal
floating constant",
+  "invalid suffix \"%.*s\" with hexadecimal
floating constant (maybe missing a space)",
   (int) (limit - str), str);
   return CPP_N_INVALID;
 }
@@ -789,7 +789,7 @@ cpp_classify_number (cpp_reader *pfile, const cpp_token
*token,
  else
{
  cpp_error_with_line (pfile, CPP_DL_ERROR, virtual_location, 0,
-  "invalid suffix \"%.*s\" on integer
constant",
+  "invalid suffix \"%.*s\" on integer constant
(maybe missing a space)",
   (int) (limit - str), str);
  return CPP_N_INVALID;
}

[Bug ada/108909] Build process does not honor discovered path to "gnatmake" and "gnatlink"

[emr-gnu at hev dot psu.edu via Gcc-bugs]

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

--- Comment #1 from Eric Reischer  ---
One more:

--- gcc-12.2.0/gcc/ada/gcc-interface/Makefile.in2022-08-19
04:09:52.352659553 -0400
+++ gcc-12.2.0-fixed/gcc/ada/gcc-interface/Makefile.in  2023-02-23
16:27:59.604161728 -0500
@@ -616,7 +616,7 @@
-$(MKDIR) ./bldtools/oscons
$(RM) $(addprefix ./bldtools/oscons/,$(notdir $^))
$(CP) $^ ./bldtools/oscons
-   (cd ./bldtools/oscons ; gnatmake -q xoscons)
+   (cd ./bldtools/oscons ; $(GNATMAKE) -q xoscons)

 $(RTSDIR)/s-oscons.ads: ../stamp-gnatlib1-$(RTSDIR) s-oscons-tmplt.c gsocket.h
./bldtools/oscons/xoscons
$(RM) $(RTSDIR)/s-oscons-tmplt.i $(RTSDIR)/s-oscons-tmplt.s

[Bug tree-optimization/108908] [13 regression] r13-6278-g3da77f217c8b20 causes ICE

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Dup.

*** This bug has been marked as a duplicate of bug 10 ***

[Bug tree-optimization/108888] [13 Regression] error: definition in block 26 follows the use

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #5 from Andrew Pinski  ---
*** Bug 108908 has been marked as a duplicate of this bug. ***

[Bug target/108145] [13 regression] ICE in from_reg_br_prob_base, at profile-count.h:259

[vmakarov at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Vladimir Makarov  ---
FYI, I think my patch did not cause this problem.

I've just check fresh trunk (w/o my patch and the compilation still fails).

So the PR probably should be still open.

[Bug tree-optimization/108908] [13 regression] r13-6278-g3da77f217c8b20 causes ICE

[seurer at gcc dot gnu.org via Gcc-bugs]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from seurer at gcc dot gnu.org ---
Sorry, I was working off r13-6292 from early this morning.

[Bug target/108892] [13 Regression] unable to generate reloads for at -Og on riscv64 since r13-4907

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-23
Summary|[13 Regression] ICE: in |[13 Regression] unable to
   |curr_insn_transform, at |generate reloads for at -Og
   |lra-constraints.cc:4168 |on riscv64 since r13-4907
   |(unable to generate reloads |
   |for: {*mvconst_internal})   |
   |at -Og on riscv64   |
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
r13-4907-g2e886eef7f2b5a broke this.

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

[qinzhao at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #10)

> I'd keep its current behavior, perhaps except for -fsanitize=bounds-strict
> -fstrict-flex-arrays{,=3} so that -fsanitize=bounds
> -fstrict-flex-arrays{,=3} wouldn't be more strict than the former.
Agreed.

[Bug target/108892] [13 Regression] ICE: in curr_insn_transform, at lra-constraints.cc:4168 (unable to generate reloads for: {*mvconst_internal}) at -Og on riscv64

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |blocker

--- Comment #1 from Andrew Pinski  ---
The backend is really broken:
(define_insn_and_split "*mvconst_internal"
  [(set (match_operand:GPR 0 "register_operand" "=r")
(match_operand:GPR 1 "splittable_const_int_operand" "i"))]
  "!(p2m1_shift_operand (operands[1], mode)
 || high_mask_shift_operand (operands[1], mode))"
  "#"
  "&& 1"
  [(const_int 0)]
{
  riscv_move_integer (operands[0], operands[0], INTVAL (operands[1]),
  mode, TRUE);
  DONE;
})


There are multiple insn patterns which match and guess what it is just broken.

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to qinzhao from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > Well, -fsanitize=bounds-strict certainly shouldn't imply
> > -fstrict-flex-arrays=2,
> > it should just treat [1] and [4] (but I think it does even [0] right now) as
> > regular arrays for the purposes of the sanitization.
> 
> with a small example I just tested, with -fsanitize=bounds-strict, I can
> see, it treats:
>[], [0] as flexible array members;
> but
>[1], [4] as regular arrays
> 
> This is the same level as -fstrict-flex-arrays=2. 
> should we just keep its default behavior like this, or let it more strictly
> as -fstrict-flex-arrays=3?

I'd keep its current behavior, perhaps except for -fsanitize=bounds-strict
-fstrict-flex-arrays{,=3} so that -fsanitize=bounds -fstrict-flex-arrays{,=3}
wouldn't be more strict than the former.

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

[qinzhao at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> Well, -fsanitize=bounds-strict certainly shouldn't imply
> -fstrict-flex-arrays=2,
> it should just treat [1] and [4] (but I think it does even [0] right now) as
> regular arrays for the purposes of the sanitization.

with a small example I just tested, with -fsanitize=bounds-strict, I can see,
it treats:
   [], [0] as flexible array members;
but
   [1], [4] as regular arrays

This is the same level as -fstrict-flex-arrays=2. 
should we just keep its default behavior like this, or let it more strictly as
-fstrict-flex-arrays=3?

[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jakub Jelinek  ---
As I've tried to explain in the past, C/C++ considers float * and float
*__attribute__((aligned (64))) types to be compatible, similarly to int and int
__attribute__((aligned (64))), so in calling convention one should ignore
alignment on scalar types of passed arguments at least, because they can be
pretty much random.

Though
extern void foo (long, long, long);
void baz (void *);

void
bar (void *p)
{
  long __attribute__((aligned (64))) q = 1;
  asm volatile ("" : "+r" (q));
  foo (0.0L, q, q);
}
doesn't ICE.

[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package

[kurt at garloff dot de via Gcc-bugs]

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

kurt at garloff dot de changed:

   What|Removed |Added

 CC||kurt at garloff dot de

--- Comment #16 from kurt at garloff dot de ---
Using u32 instead of long to access the arrays in XORN should work as well, no?
Should result in better performance than doing it byte by byte...

[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|13.0|12.3
Summary|[13 Regression] Further ICE |[12/13 Regression] Further
   |in aarch64_layout_arg   |ICE in aarch64_layout_arg

--- Comment #2 from Andrew Pinski  ---
> ICEs on aarch64-linux with -O2 likely since r13-5124

Which has been backported to the GCC 12 branch too.

[Bug target/108910] [13 Regression] Further ICE in aarch64_layout_arg

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
What I don't understand is how the alignment of the function argument 64 bytes
aligned being taken into account here ...
The alignment of the argument type is still 4 byte aligned even because of the
declaration of foo.

[Bug target/108910] [13 Regression] Further ICE in aarch64_layout_arg

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Ever confirmed|0   |1
   Last reconfirmed||2023-02-23
 CC||clyon at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1

[Bug target/108910] New: [13 Regression] Further ICE in aarch64_layout_arg

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 108910
   Summary: [13 Regression] Further ICE in aarch64_layout_arg
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

extern void foo (float, float *, float *);

void
bar (void *p)
{
  float *__attribute__((aligned (64))) q = __builtin_assume_aligned (p, 64);
  foo (0.0f, q, q);
}

ICEs on aarch64-linux with -O2 likely since r13-5124 with:
during RTL pass: expand
woohoo.c: In function ‘bar’:
woohoo.c:7:3: internal compiler error: in aarch64_layout_arg, at
config/aarch64/aarch64.cc:7688
7 |   foo (0.0f, q, q);
  |   ^~~~
0x12c4993 aarch64_layout_arg
../../gcc/config/aarch64/aarch64.cc:7688
0x12c527a aarch64_function_arg
../../gcc/config/aarch64/aarch64.cc:7868
0xa44efb initialize_argument_information
../../gcc/calls.cc:1499

I know trying to overalign a pointer type (rather than what it points to) is
very dumb,
but some real-world code (most likely just by mistake (but many)) does that:
https://github.com/darktable-org/darktable/blob/master/src/common/bspline.h#L178

[Bug preprocessor/48839] #error should terminate compilation - similar to missing #include

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from Andrew Pinski  ---
Note C23 has the following under "4. Conformance":
The implementation shall not successfully translate a preprocessing translation
unit containing a
#error preprocessing directive unless it is part of a group skipped by
conditional inclusion.

GCC does error out when preprocessing seperately from compiling but when doing
a combined, GCC does "successfully" translate the preprocessing translation but
does not finish compiling though. But maybe that is still valid.

[Bug preprocessor/48839] #error should terminate compilation - similar to missing #include

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

--- Comment #12 from Andrew Pinski  ---
Paolo has not been around for the last 3 years so unassigning this bug report
from him so someone else can take it if they want. The patch against libcpp is
simple but the testsuite needs to updated or improved.
It also might make sense to have this as an option instead; though
-Wfatal-errors might be enough for that ... (maybe just an improved
documentation for #error in the cpp manual is needed for this change in the
end).

[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #26 from Iain Sandoe  ---
(In reply to Gaius Mulley from comment #25)
> Created attachment 54516 [details]
> Proposed fix version 6
> 
> Version 6 (more coroutine tests) and RTint.mod with more descriptive
> variable names.

This does not solve the timeout issues on Darwin (mentioned here because we
were wondering if the issue was related to init ordering).

-

Here's a patch that seems to prevent the hangs (but at the expense of a lot of
diagnostic output - it seems modula-2 is somehow calling the OS select with
some bad input) .. I cannot reproduce this calling it from C.

>From 92cc7b7c19735ea32e0800b369a2e49f85047e27 Mon Sep 17 00:00:00 2001
From: Iain Sandoe 
Date: Thu, 23 Feb 2023 09:54:01 +
Subject: [PATCH] modula-2 : Some TLC for  select fail case diagnostics

---
 gcc/m2/gm2-libs/RTint.mod | 52 ++-
 1 file changed, 35 insertions(+), 17 deletions(-)

diff --git a/gcc/m2/gm2-libs/RTint.mod b/gcc/m2/gm2-libs/RTint.mod
index d8ca8dd5694..796430a55df 100644
--- a/gcc/m2/gm2-libs/RTint.mod
+++ b/gcc/m2/gm2-libs/RTint.mod
@@ -669,6 +669,7 @@ PROCEDURE Listen (untilInterrupt: BOOLEAN;
 VAR
found: BOOLEAN ;
r: INTEGER ;
+   zero,
after,
b4,
t: Timeval ;
@@ -742,6 +743,7 @@ BEGIN
   ELSE
  GetTime (t, s, m) ;
  Assert (m

[Bug ada/108909] New: Build process does not honor discovered path to "gnatmake" and "gnatlink"

[emr-gnu at hev dot psu.edu via Gcc-bugs]

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

Bug ID: 108909
   Summary: Build process does not honor discovered path to
"gnatmake" and "gnatlink"
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emr-gnu at hev dot psu.edu
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54521
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54521&action=edit
Patch to resolve gnatmake build issue

When attempting to build GCC 12.2 from released source:

$ GNATBIND=gnatbind-12.1 GNATMAKE=gnatmake-12.1 ../gcc-12.2.0/configure
--enable-languages=c,c++,ada,fortran --program-suffix=-12.2 {...blah blah...}
{...}
checking for x86_64-linux-gnu-gnatbind... gnatbind-12.1
checking for x86_64-linux-gnu-gnatmake... gnatmake-12.1
checking whether compiler driver understands Ada... yes
{...much later...}
mkdir -p ada/gen_il
cd ada/gen_il; gnatmake -q -g -gnata -gnat2012 -gnatw.g -gnatyg -gnatU
-I/build/gcc-12.2.0/gcc/ada gen_il-main
/bin/sh: gnatmake: command not found
make: *** [ada/stamp-gen_il] Error 127

This seems similar to PR 30541, in that if your system-level packages don't
have the GNAT tools installed, but you have specified an alternate compiler
path to Ada tools in the environment, the build scripts ignore the
configure-guessed (or environment-specified) options, and just blindly call
"gnatmake".  Thus, the build fails.

The fix is to change lines 21, 42, and 49 of gcc/ada/Make-generated.in to use
"$(GNATMAKE)" instead of "gnatmake".

[Bug libstdc++/108030] `std::experimental::simd` not inlined

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Matthias Kretz
:

https://gcc.gnu.org/g:a1f70114f9bae5a1dbcec4b556c16716601fccf1

commit r11-10543-ga1f70114f9bae5a1dbcec4b556c16716601fccf1
Author: Matthias Kretz 
Date:   Sat Jan 14 23:32:38 2023 +0100

libstdc++: Simplify three helper functions into one

Broadcast is a very common function. This should reduce compile-time
effort.

Signed-off-by: Matthias Kretz 

libstdc++-v3/ChangeLog:

PR libstdc++/108030
* include/experimental/bits/simd.h (__vector_broadcast):
Implement via __vector_broadcast_impl instead of
__call_with_n_evaluations + 2 lambdas.
(__vector_broadcast_impl): New.

(cherry picked from commit 2e29e2fbeb8936e5c85cefaf547cba42e17e137b)

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to qinzhao from comment #7)
> 1. let -fstrict-flex-arrays=N to control the behavior of -fsanitize=bounds;

I'm ok with that.

> 2. -fsanitize=bounds-strict actually is an alias of -fsanitize=bounds
> -fstrict-flex-arrays=2,  i.e, it treats [], [0] as flexible array members,
> but treat [1], [4], as regular arrays.

Well, -fsanitize=bounds-strict certainly shouldn't imply
-fstrict-flex-arrays=2,
it should just treat [1] and [4] (but I think it does even [0] right now) as
regular arrays for the purposes of the sanitization.

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

[qinzhao at gcc dot gnu.org via Gcc-bugs]

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> As for whether -fstrict-flex-arrays= should or shouldn't affect
> -fsanitize=bounds, making it gradually equivalent to
> -fsanitize=bounds-strict, that is a question, perhaps if
> -fstrict-flex-arrays= is considered as changing the exactly applicable
> language standard, with that option it might change what is and is not
> undefined behavior.
> Siddhesh/Qing, what do you think?
from the doc:
"
-fsanitize=bounds
This option enables instrumentation of array bounds. Various out of bounds
accesses are detected. Flexible array members, flexible array member-like
arrays, and initializers of variables with static storage are not instrumented.

-fsanitize=bounds-strict
This option enables strict instrumentation of array bounds. Most out of bounds
accesses are detected, including flexible array members and flexible array
member-like arrays. Initializers of variables with static storage are not
instrumented.
"

the situation is very similar to the previous:

-Warray-bounds
-Warray-bounds=2

Per our previous discussion on  -Warray-bounds and -Warray-bounds=2 and
-fstrict-flex-arrays=N, I think it's very reasonable to handle the
-fsanitize=bounds and -fsanitize=bounds-strict + -fstrict-flex-arrays=N
similarly, i.e:

1. let -fstrict-flex-arrays=N to control the behavior of -fsanitize=bounds;
2. -fsanitize=bounds-strict actually is an alias of -fsanitize=bounds
-fstrict-flex-arrays=2,  i.e, it treats [], [0] as flexible array members, but
treat [1], [4], as regular arrays.

[Bug tree-optimization/108908] [13 regression] r13-6278-g3da77f217c8b20 causes ICE

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
Was this not fixed by r13-6296-g31cc5821223a096ef61743bff520f4a0dbba5872 (aka
PR 10 )?

[Bug tree-optimization/108908] New: [13 regression] r13-6278-g3da77f217c8b20 causes ICE

[seurer at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 108908
   Summary: [13 regression] r13-6278-g3da77f217c8b20 causes ICE
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:3da77f217c8b2089ecba3eb201e727c3fcdcd19d, r13-6278-g3da77f217c8b20

This causes an ICE when compiling one of the SPEC 2017 test cases.

/home/seurer/gcc/git/install/gcc-test/bin/gfortran -c -o
module_ra_rrtm.fppized.o -I. -I./netcdf/include -I./inc -m64 -O3 -mcpu=power9
-ffast-math -funroll-loops -fpeel-loops -fvect-cost-model -mpopcntd
-mrecip=rsqrt -Wno-deprecated-declarations -fconvert=big-endian -std=legacy
-fno-finite-math-only module_ra_rrtm.fppized.f90
f951: Warning: '-mrecip' requires '-ffinite-math' or '-ffast-math'
module_ra_rrtm.fppized.f90:6853:35:
 6791 |   CALL wrf_dm_bcast_bytes ( rrtm_unit , 4 )
  |2
..
 6853 |  CALL wrf_dm_bcast_bytes ( abscoefL1 , size ( abscoefL1 ) * 4 )
  |   1
Warning: Type mismatch between actual argument at (1) and actual argument at
(2) (REAL(4)/INTEGER(4)).
module_ra_rrtm.fppized.f90:6051:24:
 6051 |   SUBROUTINE
TAUGB16(kts,ktep1,COLH2O,COLCH4,FAC00,FAC01,FAC10,FAC11,&
  |^
Error: definition in block 5 follows the use
for SSA_NAME: _764 in statement:
_735 = .MASK_CALL (__builtin_fmodf, _731, 1.0e+0, _764);
during GIMPLE pass: ifcvt
module_ra_rrtm.fppized.f90:6051:24: internal compiler error: verify_ssa failed
0x110cc0c3 verify_ssa(bool, bool)
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa.cc:1211
0x10c12093 execute_function_todo
/home/seurer/gcc/git/gcc-test/gcc/passes.cc:2098
0x10c12f8b do_per_function
/home/seurer/gcc/git/gcc-test/gcc/passes.cc:1694
0x10c1319b execute_todo
/home/seurer/gcc/git/gcc-test/gcc/passes.cc:2145
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.


commit 3da77f217c8b2089ecba3eb201e727c3fcdcd19d (HEAD)
Author: Andrew Stubbs 
Date:   Thu Jul 28 16:07:22 2022 +0100

vect: inbranch SIMD clones

[Bug other/108907] ira-color.cc:3028:1: error: definition in block 5 follows the use

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=10

--- Comment #1 from Andrew Pinski  ---
I suspect this was just fixed today. See PR 10 .

[Bug other/108907] New: ira-color.cc:3028:1: error: definition in block 5 follows the use

[danglin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 108907
   Summary: ira-color.cc:3028:1: error: definition in block 5
follows the use
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-linux*
Target: hppa*-*-linux*
 Build: hppa*-*-linux*

/home/dave/gnu/gcc/objdir/./prev-gcc/xg++
-B/home/dave/gnu/gcc/objdir/./prev-gcc
/ -B/home/dave/opt/gnu/gcc/gcc-13/hppa-linux-gnu/bin/ -nostdinc++
-B/home/dave/g
nu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/ob
jdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/home/dave/gnu/gcc/objd
ir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu 
-I/home/dave/gnu/gcc
/objdir/prev-hppa-linux-gnu/libstdc++-v3/include 
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-fno-PIE -c   -g -O2 -fchecking=1 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include  -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libcody  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc/gcc/../libbacktrace   -o ira-lives.o -MT ira-lives.o -MMD -MP -MF
./.deps/ira-lives.TPo ../../gcc/gcc/ira-lives.cc
../../gcc/gcc/ira-color.cc: In function 'void
setup_allocno_priorities(ira_allocno**, int)':
../../gcc/gcc/ira-color.cc:3028:1: error: definition in block 5 follows the use
 3028 | setup_allocno_priorities (ira_allocno_t *consideration_allocnos, int n)
  | ^~~~
for SSA_NAME: _119 in statement:
_55 = .MASK_CALL (__builtin_clzll, _4, _119);
../../gcc/gcc/ira-color.cc:3028: confused by earlier errors, bailing out
make[3]: *** [Makefile:1152: ira-color.o] Error 1
make[3]: *** Waiting for unfinished jobs

[Bug c/69960] "initializer element is not constant"

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #24 from joseph at codesourcery dot com  ---
On Thu, 23 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:

> In this code 
> 
> static const int y = 1;
> static int x = y;
> 
> y is not an integer constant expression, nor is it an integer constant in the
> meaning that ISO 9899 defines it.

Correct, but irrelevant, since nothing in that code example is required by 
the standard to be an integer constant expression.

> Therefore an initializer was given which is
> not a constant expression.

No, it's an "other form of constant expression" accepted by GCC.

> "an implementation may accept other forms of constant expressions" does not
> mean that an implementation can throw out any constraints it pleases out the
> window.

Correct.  The Constraints on constant expressions say "Constant 
expressions shall not contain assignment, increment, decrement, 
function-call, or comma operators, except when they are contained within a 
subexpression that is not evaluated." and "Each constant expression shall 
evaluate to a constant that is in the range of representable values for 
its type.".  The initializer is entirely consistent with those 
Constraints, so it is within the bounds of what an implementation may 
accept as an "other form of constant expression".  Whereas it wouldn't be 
valid for an implementation to accept f() as a constant expression 
(contains a function call), for example.

Note also that only violations of Syntax and Constraints require 
diagnostics (and thus -pedantic doesn't claim to ensure diagnostics for 
code that's not strictly conforming for some other reason than violating 
Syntax or Constraints).

[Bug libgomp/108895] [13.0.1 (exp)] Fortran + gfx90a !$acc update device produces a segfault.

[hberre3 at gatech dot edu via Gcc-bugs]

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

--- Comment #2 from Henry Le Berre  ---
Thank you Thomas for your swift reply! I would also like to thank you for
fixing the previous bug I had reported, it is sincerely appreciated. I will
take a look at the devel/omp/gcc-12 branch to see how much I can get working. 

I agree that testing with GCC 8 isn't ideal but it is the only version with
nvptx offloading that I had on hand.. I will build GCC for nvtpx as well. Are
there any upcoming merges from development branches planned into master?

[Bug preprocessor/107818] Overflow of linemap breaks its chronological order

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
include/line-map.h:const location_t LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES =
0x5000;
include/line-map.h:const location_t LINE_MAP_MAX_LOCATION_WITH_COLS =
0x6000;
include/line-map.h:const location_t LINE_MAP_MAX_LOCATION = 0x7000;

[Bug fortran/108621] [12/13 regression]: bind(c) pointer array spurious maybe-uninitialized warning

[burnus at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Tobias Burnus  ---
The warning itself is bogus (false positive in the middle end).
I get:

Warning: ‘f.dim[idx.1_32].lbound’ may be used uninitialized
[-Wmaybe-uninitialized]


If I now look at the 021t.ssa dump, I see:

  f.data = 0B;
...
  _1 = f.data;
  cfi.0.base_addr = _1;
...
  _2 = cfi.0.base_addr;
  if (_2 != 0B)
goto ; [INV]
  else
goto ; [INV]
...
   :
  _3 = f.dim[idx.1_32].lbound;
...
   :
  fun (&cfi.0);

The basic block  is the only place where idx.1_32 gets used - but as
f.data == NULL, we directly jump to . Seemingly, the range/value
propagation from f.data to cfi.0.base_addr did not work. — Thus and probably
unsurprisingly, the warning is gone once optimization has been turned on (-Og,
-Os or -O1 are sufficient).

→ This is now tracked in the new PR middle-end/108906

* * *

Still, we can do better in the FE by producing less code when we know that the
dummy argument is 'intent(out)'. That's what the lightly tested patch below
does.

(Note: It fixes the testcase of comment 0, but when changing the intent, e.g., 
to 'intent(inout)' the bogus warning will re-appear.)

TODO: I think something similar needs to be done for allocatable +
'intent(out)', except that we still need to handle the DEALLOCATE in the
caller.


--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -5675,3 +5675,3 @@ gfc_conv_gfc_desc_to_cfi_desc (gfc_se *parmse, gfc_expr
*e, gfc_symbol *fsym)

-  if (e->rank == 0)
+  if (e->rank == 0 && (!fsym->attr.pointer || fsym->attr.intent !=
INTENT_OUT))
 {
@@ -5680,3 +5680,3 @@ gfc_conv_gfc_desc_to_cfi_desc (gfc_se *parmse, gfc_expr
*e, gfc_symbol *fsym)
 }
-  else
+  else if (!fsym->attr.pointer || fsym->attr.intent != INTENT_OUT)
 {
@@ -5697,2 +5697,5 @@ gfc_conv_gfc_desc_to_cfi_desc (gfc_se *parmse, gfc_expr
*e, gfc_symbol *fsym)

+  if (fsym->attr.pointer && fsym->attr.intent == INTENT_OUT)
+goto done;
+
   /* When allocatable + intent out, free the cfi descriptor.  */

[Bug middle-end/108906] New: Bogus may be used uninitialized warning

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 108906
   Summary: Bogus may be used uninitialized warning
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Split-off from  on PR fortran/108621

This shows up with code generated by gfortran internally. The warning is bogus
and (rightly!) disappears when compiled with -Og, -Os, -O1 or higher:


Warning: ‘f.dim[idx.1_32].lbound’ may be used uninitialized
[-Wmaybe-uninitialized]


If I now look at the 021t.ssa dump, I see:

  f.data = 0B;
...
  _1 = f.data;
  cfi.0.base_addr = _1;
...
  _2 = cfi.0.base_addr;
  if (_2 != 0B)
goto ; [INV]
  else
goto ; [INV]
...
   :
  _3 = f.dim[idx.1_32].lbound;
...
   :
  fun (&cfi.0);


I get the same result when I use '_2 = f.data' instead, i.e. neither value
propagation works.

The basic block  is the only place where idx.1_32 gets used - but as
f.data == NULL, we directly jump to . Seemingly, the range/value
propagation from 'f.data = 0' to '_2 = ' does not work.

* * * 

Testcase – compile with "gfortran -Wall"; a variant is 'subroutine'
instead of 'program' but this does not have any effect, either.


program demo
use, intrinsic :: iso_c_binding, only : c_int
implicit none

interface
subroutine fun(f_p) bind(c)
import c_int
integer(c_int), pointer, intent(inout) :: f_p(:)
end subroutine
end interface

integer(c_int), pointer :: f(:)

nullify(f)
call fun(f)

end

[Bug target/108881] "__builtin_ia32_cvtne2ps2bf16_v16hi" compiled only with option -mavx512bf16 report ICE.

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2023-02-23

--- Comment #3 from Jakub Jelinek  ---
Created attachment 54520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54520&action=edit
gcc13-pr108881.patch

Untested fix.

[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Arthur O'Dwyer  ---
(In reply to Jonathan Wakely from comment #10)
> std::move(x,y,z) and std::copy(z,y,z) use the same underlying
> implementation, so it does have the same issue, but will be fixed by the
> same change.

Right; also std::rotate, std::set_union, etc., I'd expect would all be fixed by
the same change to std::copy.

You might want to peek at std::swap_ranges, though. Microsoft's STL has trouble
there; I don't *think* libstdc++ does, but you might as well check me.

[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #7)
> I suspect std::move has the same issue too. The ability to use memmove with
> trivial copyable subobjects ...

std::move(x,y,z) and std::copy(z,y,z) use the same underlying implementation,
so it does have the same issue, but will be fixed by the same change.

[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Giuseppe D'Angelo from comment #5)
> https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/
> stl_algobase.h#L417-L437
> 
> Is the extent of the fix just to add another branch to the if (_Num) check
> here?

Yes, I think that's the simplest place to fix it.

And we can even get rid of the static assertion, because the Num==1 branch will
require assignability now.

--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -737,16 +737,11 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
static _Tp*
__copy_move_b(const _Tp* __first, const _Tp* __last, _Tp* __result)
{
-#if __cplusplus >= 201103L
- using __assignable = __conditional_t<_IsMove,
-  is_move_assignable<_Tp>,
-  is_copy_assignable<_Tp>>;
- // trivial types can have deleted assignment
- static_assert( __assignable::value, "type must be assignable" );
-#endif
  const ptrdiff_t _Num = __last - __first;
- if (_Num)
+ if (__builtin_expect(_Num > 1, true))
__builtin_memmove(__result - _Num, __first, sizeof(_Tp) * _Num);
+ else if (_Num == 1)
+   *__result = *__first;
  return __result - _Num;
}
 };

[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-02-23
 Ever confirmed|0   |1

--- Comment #8 from Jonathan Wakely  ---
I don't think we need the ABI keyword here, the library can just avoid the
optimization for distance == 1. That has no ABI impact.

[Bug target/108881] "__builtin_ia32_cvtne2ps2bf16_v16hi" compiled only with option -mavx512bf16 report ICE.

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
With -mavx512bf16
typedef float __m256 __attribute__((__vector_size__(32)));
typedef __bf16 __v16bf16 __attribute__((__vector_size__(32)));
__v16bf16 res2;
__m256 x3, x4;
void foo (void) { res2 = __builtin_ia32_cvtne2ps2bf16_v16bf (x3, x4); }
still ICEs on the trunk.

[Bug c++/108848] [10/11/12/13 Regression] template keyword incorreclty required to access template class static member of non-dependent expression using member syntax in dependent context

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

[Bug target/108902] Conversions std::float16_t<->float with FP16C are not vectorized

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
-std=c++23 -march=x86-64-v3 -O3 -mno-vzeroupper

[Bug ipa/108871] attribute nonnull does not spot nullptr O2 and above when function inlined

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Andrew Pinski from comment #3)
> > *** Bug 108893 has been marked as a duplicate of this bug. ***
> 
> N.B. this one is about __attribute__((access(read_only, 1))) not nonnull.
> The docs already seem to imply that it requires a non-null pointer:
> 
>   The read_only access mode specifies that the pointer to which it applies
> is used to
>   read the referenced object but not write to it. Unless the argument
> specifying the
>   size of the access denoted by size-index is zero, the referenced object
> must be
>   initialized.
> 
> If a non-zero size implies an initialized object, then it also implies a
> non-null pointer (since a null pointer doesn't point to an initialized
> object).
> 
> I don't know if we want this PR to be specific to the nonnull attribute, or
> if it makes sense to use it for access(read_only) too.

On the other side, looking at glibc sources, access attributes there are used
on many functions together with nonnull attributes for the same arguments and
in many cases in places where there are not nonnull attributes.  So, making
access attribute imply non-null might not be desirable in real-world unless it
is already implied.
So it might be just that it is badly documented.

[Bug libstdc++/108030] `std::experimental::simd` not inlined

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Matthias Kretz
:

https://gcc.gnu.org/g:8e171d840584a564993201101cd1f2e920e7aecb

commit r12-9200-g8e171d840584a564993201101cd1f2e920e7aecb
Author: Matthias Kretz 
Date:   Sat Jan 14 23:32:38 2023 +0100

libstdc++: Simplify three helper functions into one

Broadcast is a very common function. This should reduce compile-time
effort.

Signed-off-by: Matthias Kretz 

libstdc++-v3/ChangeLog:

PR libstdc++/108030
* include/experimental/bits/simd.h (__vector_broadcast):
Implement via __vector_broadcast_impl instead of
__call_with_n_evaluations + 2 lambdas.
(__vector_broadcast_impl): New.

(cherry picked from commit 2e29e2fbeb8936e5c85cefaf547cba42e17e137b)

[Bug testsuite/108899] [13 Regression] ERROR: can't rename to "saved-unsupported": command already exists on i386

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jakub Jelinek  ---
Should be fixed now.

[Bug ipa/108871] attribute nonnull does not spot nullptr O2 and above when function inlined

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #3)
> *** Bug 108893 has been marked as a duplicate of this bug. ***

N.B. this one is about __attribute__((access(read_only, 1))) not nonnull. The
docs already seem to imply that it requires a non-null pointer:

  The read_only access mode specifies that the pointer to which it applies is
used to
  read the referenced object but not write to it. Unless the argument
specifying the
  size of the access denoted by size-index is zero, the referenced object must
be
  initialized.

If a non-zero size implies an initialized object, then it also implies a
non-null pointer (since a null pointer doesn't point to an initialized object).

I don't know if we want this PR to be specific to the nonnull attribute, or if
it makes sense to use it for access(read_only) too.

[Bug testsuite/108899] [13 Regression] ERROR: can't rename to "saved-unsupported": command already exists on i386

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:5592679df783547049efc6d73727c5ff809ec302

commit r13-6306-g5592679df783547049efc6d73727c5ff809ec302
Author: Jakub Jelinek 
Date:   Thu Feb 23 17:17:05 2023 +0100

testsuite: Fix up modules.exp [PR108899]

On Wed, Feb 22, 2023 at 02:33:42PM -0300, Alexandre Oliva via Gcc-patches
wrote:
> When a multi-source module is found to be unsupported, we fail
> module_cmi_p and subsequent sources.  Override proc unsupported to
> mark the result in module_do, and test it to skip module_cmp_p and
> subsequent related tests.
>
> for  gcc/testsuite/ChangeLog
>
>   * g++.dg/modules/modules.exp: Override unsupported to update
>   module_do, and test it after dg-test.

This patch breaks testing with more than one set of options in
target board, like
make check-g++ RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} modules.exp'
yields:
...
 === g++ Summary for unix/-m32 ===

 # of expected passes7217
 # of unexpected failures1
 # of expected failures  18
 # of unsupported tests  2
 Running target unix/-m64
...
 ERROR: tcl error sourcing
/home/jakub/src/gcc/gcc/testsuite/g++.dg/modules/modules.exp.
 ERROR: tcl error code TCL OPERATION RENAME TARGET_EXISTS
 ERROR: can't rename to "saved-unsupported": command already exists
 while executing
 "rename unsupported saved-unsupported"
 (file "/home/jakub/src/gcc/gcc/testsuite/g++.dg/modules/modules.exp"
line 322)
 invoked from within
 "source /home/jakub/src/gcc/gcc/testsuite/g++.dg/modules/modules.exp"
 ("uplevel" body line 1)
 invoked from within
 "uplevel #0 source
/home/jakub/src/gcc/gcc/testsuite/g++.dg/modules/modules.exp"
 invoked from within
 "catch "uplevel #0 source $test_file_name" msg"

In other spots where we in *.exp files rename some routine, we guard that
and the following patch does that for modules.exp too.

Tested with running
make check-g++ RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} modules.exp'
again which now works properly again.

2023-02-23  Jakub Jelinek  

PR testsuite/108899
* g++.dg/modules/modules.exp: Only override unsupported if it
exists and saved-unsupported doesn't.

[Bug middle-end/108854] [10/11/12/13 Regression] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281 since r10-4511-g6cf67b62c8cda035dccac

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #12 from Jakub Jelinek  ---
Created attachment 54519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54519&action=edit
gcc13-pr108854.patch

Full untested patch.

[Bug target/97276] A whole if-block is ignored by avr-gcc 9.3.0

[gjl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Georg-Johann Lay  ---
... also tried v9.2 via

https://godbolt.org/z/9r3vMj1e3

and just like with v8.5, the respective block is around asm line 350.