[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

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

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

--- Comment #12 from Paul Thomas  ---
(In reply to kargls from comment #11)
> (In reply to Paul Thomas from comment #9)
> > Created attachment 61467 [details]
> > Test vehicle for my f2018 import patch
> > 
> > Hi Steve,
> > 
> > Note the sections marked WRINKLE. ifx considers an associate block to be
> > executable code such that the import statement cannot appear there. With my
> > patch, symbols in the associate target expression are not accepted, unless
> > imported into the host scope.
> > 
> 
> I just check F2023, and ifx is correct.  An import statement
> is not allowed in an associate construct.  As an associate construct
> does not have a declaration section.
> 
> R1102 associate‑construct is
>   associate‑stmt
> 
>   end‑associate‑stmt
> 
> as opposed to
> 
> R1107 block‑construct is
>   block‑stmt
>  [block‑specification‑part]
>  
>   end‑block‑stmt
> 
> R1109 block‑specification‑part is
> [ use‑stmt ] ...
> [ import‑stmt ] ...
> [ declaration‑construct ]

Thanks for doing the legwork on that. I'll roll it in.

Paul

[Bug target/120360] Horrible code generation for trivial decrement with test

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2025-05-20
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
int f1(type *b)
{
  type a = *b;
  *b = a - 24;
  if (*b == 1)
return g();
  return 0;
}

is similarly "bad".  This is about us not realizing it's worth canonicalizing
compares to ==/!= 0, aka reduce them to the various CCmode tests.

For 'f' it could work to pattern-match SSA == CST in FRE and see whether
there's SSA - CST available and then re-write as == 0.  Of course folding
would immediately undo that unless restricted by single-use (but after CSE
it should have multiple uses).

I don't think this is a target thing.  I'm not sure it's easily possible
to handle this on the RTL side (in CSE, again), it might be detrimental
before combine.

[Bug target/120326] problems with attribute __ms_struct__

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

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

--- Comment #3 from uecker at gcc dot gnu.org ---
Those should not get the same TYPE_CANONICAL. tagged_types_tu_compatible_p
should be changed to detect this case which is due to different packing of bit
fields. It works correctly for this:

struct {
  unsigned char a;
  unsigned char b;
  unsigned long c;
} a;
struct {
  unsigned char a;
  unsigned char b;
  unsigned long c;
} __attribute__((packed)) b;

[Bug tree-optimization/120341] [15/16 Regregression] wrong code at -O1 and above with "-fallow-store-data-races" on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Version|unknown |16.0

--- Comment #3 from Richard Biener  ---
Mine.  Same error in store motion then.

[Bug target/120351] [15 regression] Assemble failure on armv7-a with -mfpu=neon (ldrex r1, [s14], invalid use of NEON registers) since r15-1579-g792f97b44ffc5e

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||16.0

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||rguenth at gcc dot gnu.org

[Bug tree-optimization/120357] [16 Regression] RISC-V: ICE in vect pass "error: definition in block 9 does not dominate use in block 3"

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Keywords||needs-bisection
   Target Milestone|--- |16.0

[Bug target/119847] [13/14/15 Regression] RISC-V:GCC fail to optimize repeated patterns in volatile operations

[fanghuaqi at vip dot qq.com via Gcc-bugs]

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

--- Comment #3 from Huaqi  ---
This issue still existed in gcc truck(16) version, will it be optimized, or is
there any patch?

[Bug target/120344] code size increase with gcc 13 due to repeated loading of higher address in assembly for riscv

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug target/119847] [13/14/15/16 Regression] RISC-V:GCC fail to optimize repeated patterns in volatile operations

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[13/14/15 Regression]   |[13/14/15/16 Regression]
   |RISC-V:GCC fail to optimize |RISC-V:GCC fail to optimize
   |repeated patterns in|repeated patterns in
   |volatile operations |volatile operations

--- Comment #4 from Andrew Pinski  ---
(In reply to Huaqi from comment #3)
> This issue still existed in gcc truck(16) version, will it be optimized, or
> is there any patch?

The summary was missing 16 because this was created the same day GCC 15 was
branched off and I missed 16 at that point.

[Bug c++/120346] New: internal compiler error: tree check: expected target_expr, have error_mark in convert_like_internal, at cp/call.cc:9037 since 14.1

[mario.rodriguezb1 at um dot es via Gcc-bugs]

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

Bug ID: 120346
   Summary: internal compiler error: tree check: expected
target_expr, have error_mark in convert_like_internal,
at cp/call.cc:9037 since 14.1
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mario.rodriguezb1 at um dot es
  Target Milestone: ---

ICE in:

```
#include 
#include 
int main() {
std::unordered_set set1{{1, 2, 3, 4, 5}};
}
```

```
:5:51: internal compiler error: tree check: expected target_expr, have
error_mark in convert_like_internal, at cp/call.cc:9037
0x2945025 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2962d96 internal_error(char const*, ...)
???:0
0x9e1042 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
???:0
0xaf9923 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xafac7d build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0xc079ca build_aggr_init(tree_node*, tree_node*, int, int)
???:0
0xbd268e cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int,
cp_decomp*)
???:0
0xcfccb3 c_parse_file()
???:0
0xe618e9 c_common_parse_file()
???:0
```

To quickly reproduce:

https://godbolt.org/z/edWbj8GT7

[Bug c++/120345] New: array subscript is partly outside array bounds

[orgads at gmail dot com via Gcc-bugs]

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

Bug ID: 120345
   Summary: array subscript is partly outside array bounds
   Product: gcc
   Version: 12.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: orgads at gmail dot com
  Target Milestone: ---

This is the most minimal repro I could create:

struct List {
void *f1 = nullptr;
void *f2 = nullptr;
};

class Base {
public:
virtual ~Base() {}
virtual void foo() = 0;
};

class Derived1 : public Base {
char buf[10];

public:
Derived1() {}
~Derived1() override {}
void foo() override;
};

class Derived2 : public Base {
public:
Derived2();
~Derived2();
void foo() override;
};

void test()
{
Base *update = new Derived2();
List list;
delete update;
}

When compiling with -fcheck-new -Wall -O2, the following error is shown:

In destructor 'virtual Derived1::~Derived1()',
inlined from 'virtual Derived1::~Derived1()' at :17:24,
inlined from 'void test()' at :32:9:
:17:31: warning: array subscript 'Derived1::__as_base [0]' is partly
outside array bounds of 'unsigned char [8]' [-Warray-bounds=]
   17 | ~Derived1() override {}
  |   ^
: In function 'void test()':
:30:37: note: object of size 8 allocated by 'operator new'
   30 | Base *update = new Derived2();
  |

This looks similar to bug 106247 and some others.

Godbolt link: https://godbolt.org/z/Pa8xh5T5n

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #8 from Paul Thomas  ---
Created attachment 61466
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61466&action=edit
The patch that I had been working on

Hi Steve,

As I wrote elsewhere, I should have checked if anybody else is working on
import. Apologies for treading on your toes.

The testcase that I have been using follows.

Some important differences between our patches:

1) I have assumed  and . Does this need an interpretation request?

2) I retained the original functioning of 'has_import_set' until such time as
f2018 import functions to my satisfaction. Your approach is better.

3) resolve.cc(check_import_status) is (possibly?) the wrong approach compared
with your checking of host association in symbol.cc.

4) I think that my error messages are more helpful, if considerably less
concise.

A merging of the best features from both might be in order.

Paul

[Bug target/120347] New: invalid arm32/thumb assembly output

[arnd at linaro dot org via Gcc-bugs]

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

Bug ID: 120347
   Summary: invalid arm32/thumb assembly output
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

During build testing on the Linux kernel, I came across a new failure with
gcc-15.1 producing a single invalid instruction, in exactly one file/function:

/tmp/ccGz2dNz.s: Assembler messages:
/tmp/ccGz2dNz.s:681: Error: registers may not be the same -- `str r1,[r1],#4'
make[8]: *** [scripts/Makefile.build:195: drivers/gpu/drm/radeon/radeon_test.o]
Error 1

I managed to produce a reduced test case with the same output:

void *end;
void **start;
void main(void)
{
  for (; end; start++) {
if (*start)
  return;
*start = start;
  }
}
$ arm-linux-gcc-15.1 -O2 -march=armv7-a -mthumb test.c -c
/tmp/ccjHgo9c.s:43: Error: registers may not be the same -- `str r3,[r3],#4'

See https://godbolt.org/z/4v41cnsbY for reference. The test case also
reproduces on current 'trunk' but not on gcc-14.2 or earlier.

[Bug c++/120337] internal compiler error: error reporting routines re-entered. tuple library since version 14.1

[mario.rodriguezb1 at um dot es via Gcc-bugs]

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

--- Comment #1 from MARIO RODRIGUEZ BEJAR  ---
I have found with a program that gives a similar ICE, if you use c++23 instead
of c++20 it gives "g++: internal compiler error: Segmentation fault signal
terminated program cc1plus":


```
#include 
#include 
#include 
using namespace std;
class Test {
public:
  void test() {
  }
};
int main() {
  auto y = std::bind(&Test::test, std::make_unique());
  std::thread t(y);
}
```


https://godbolt.org/z/o9bGeqMG6

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

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

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

--- Comment #9 from Paul Thomas  ---
Created attachment 61467
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61467&action=edit
Test vehicle for my f2018 import patch

Hi Steve,

Note the sections marked WRINKLE. ifx considers an associate block to be
executable code such that the import statement cannot appear there. With my
patch, symbols in the associate target expression are not accepted, unless
imported into the host scope.

Cheers

Paul

[Bug target/120347] [15/16 regression] invalid arm32/thumb assembly output

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

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

Sam James  changed:

   What|Removed |Added

Summary|invalid arm32/thumb |[15/16 regression] invalid
   |assembly output |arm32/thumb assembly output
   Keywords||assemble-failure,
   ||wrong-code
   Target Milestone|--- |15.2

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[hainque at adacore dot com via Gcc-bugs]

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

--- Comment #43 from hainque at adacore dot com  ---
Good morning Nicolas,

Thanks for your recent updates.

We had a successful complete native Linux build end of last week with v16 +
a local patch similar to what v17 brings.

We are currently looking into a few test failures reported by our first
testsuite runs.
Some look innocuous, some a bit less so. Investigating if those diffs are
legit.

With Kind Regards,

Olivier


On Sun, 18 May 2025 at 23:37, nicolas at debian dot org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
>
> --- Comment #42 from Nicolas Boulenguez  ---
> Created attachment 61464
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61464&action=edit
> v17 
> GNAT.Sockets.Thin_Common wrappers
>
> As suggested in
> https://inbox.sourceware.org/gcc-patches/aBZh8egJTzj_BHFS@pegase/
> this version restores the visible types in GNAT.Sockets.Thin_Common, as
> renamings of System.C_Time types, instead of removing them.
>
> User code importing any module under Ada or GNAT should now build
> unchanged,
> although with new warnings (Obsolescent, identifier case).
>
> If necessary, similar wrappers could also be added under System, except in
> System.Parameters because this would create a circular dependency.
>
> This version tries to mimic better the formatting of existing commit
> headers.
>
> The tarball contains a diff with v16.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug target/120347] [15/16 regression] invalid arm32/thumb assembly output

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

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

Richard Earnshaw  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=20972
 CC|richard.earnshaw at arm dot com|rearnsha at gcc dot 
gnu.org

--- Comment #1 from Richard Earnshaw  ---
This is somewhat of a heisenbug.  The instruction is unpredictable because the
increment may take place before the value to be stored is read.

Unfortunately, there's currently no way in the machine description (that I'm
aware of) to describe this restriction - I don't think you can early-clobber a
mem.

[Bug ipa/120307] [16 regression] ICE in combine_with_ipa_count_within, at profile-count.cc:410 during aarch64 -O3 profiledbootstrap since r16-101-g132d01d96ea9d6

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

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

--- Comment #3 from Alex Coplan  ---
Created attachment 61468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61468&action=edit
reduced testcase

Attached is a reduced testcase with optabs.ii down to 458 lines and optabs.gcda
reduced to 15,249 bytes (down from 50k bytes).  The reduced C++ testcase should
also work with the unmodified profile data from the original reproducer, if
that's preferable.

[Bug testsuite/120167] [16 Regression] FAIL: libgomp.graphite/force-parallel-1.c by r16-372-g064cac730f88dc

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  ---
While the fail is new to new (in GCC 16), I want to point out that there is
also PR83043.

Thus, while something clearly has changed in GCC 16 (16 regression), something
is preexisting.

[Bug libstdc++/120293] std::format("{}", std::chrono::local_days()) should not include time-of-day

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:1ed7585bf60ba9940ca5dc6d2c72dba86eea7b4d

commit r16-731-g1ed7585bf60ba9940ca5dc6d2c72dba86eea7b4d
Author: Jonathan Wakely 
Date:   Thu May 15 19:32:01 2025 +0100

libstdc++: Fix std::format of chrono::local_days with {} [PR120293]

Formatting of chrono::local_days with an empty chrono-specs should be
equivalent to inserting it into an ostream, which should use the
overload for inserting chrono::sys_days into an ostream. The
implementation of empty chrono-specs in _M_format_to_ostream takes some
short cuts, and that wasn't being done correctly for chrono::local_days.

libstdc++-v3/ChangeLog:

PR libstdc++/120293
* include/bits/chrono_io.h (_M_format_to_ostream): Add special
case for local_time convertible to local_days.
* testsuite/std/time/clock/local/io.cc: Check formatting of
chrono::local_days.

Reviewed-by: Tomasz KamiÅski 

[Bug gcov-profile/120348] New: Bogus line coverage triggered by passing pointers via extern "C" functions

[wentaoz5 at illinois dot edu via Gcc-bugs]

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

Bug ID: 120348
   Summary: Bogus line coverage triggered by passing pointers via
extern "C" functions
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wentaoz5 at illinois dot edu
  Target Milestone: ---

Hit the issue when measuring
https://sources.debian.org/src/lzma/9.22-2.2/CPP/7zip/Compress/LzmaDecoder.cpp/#L101
where RINOK is defined as:

#define RINOK(x)  \
  {   \
int __result__ = (x); \
if (__result__ != 0)  \
  return __result__;  \
  }

The direct output from gcov is:

 -:  96: for (;;)
 -:  97: {
 6:  98:   if (_inPos == _inSize)
 -:  99:   {
 6: 100: _inPos = _inSize = 0;
9*: 101: RINOK(inStream->Read(_inBuf, _inBufSizeAllocated, &_inSize));
 -: 102:   }

A reduced reproducing step is given as follow:

$ gcc --version
gcc (GCC) 16.0.0 20250511 (experimental)
Copyright (C) 2025 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.

$ cat > src1.cc << 'EOF'
int g;

extern "C" {
int foo(int *x);
}

int never;

void bar() {
int j = 0;
while (1)
{
g++;
if (never) {
g++;
return;
}

int l; // has to be local and in this scope
foo(&l);

j++;
if (j == 11)
return;
}
}

int main() {
for (int i = 0; i < 7; i++)
bar();
return 0;
}
EOF

$ cat > src2.c << 'EOF'
int foo(int *x) {
return 0;
}
EOF

$ rm -f *.gcov *.gcda *.gcno
$ g++ -c --coverage src1.cc
$ gcc -c --coverage src2.c
$ g++ --coverage  src1.o src2.o -o prog
$ ./prog
$ gcov src1
$ cat src1.cc.gcov
-:0:Source:src1.cc
-:0:Graph:src1.gcno
-:0:Data:src1.gcda
-:0:Runs:1
-:1:int g;
-:2:
-:3:extern "C" {
-:4:int foo(int *x);
-:5:}
-:6:
-:7:int never;
-:8:
7:9:void bar() {
7:   10:int j = 0;
-:   11:while (1)
-:   12:{
   77:   13:g++;
   77:   14:if (never) {
#:   15:g++;
   7*:   16:return;
-:   17:}
-:   18:
-:   19:int l; // has to be local and in this scope
   77:   20:foo(&l);
-:   21:
   77:   22:j++;
   77:   23:if (j == 11)
7:   24:return;
   70:   25:}
-:   26:}
-:   27:
1:   28:int main() {
8:   29:for (int i = 0; i < 7; i++)
7:   30:bar();
1:   31:return 0;
-:   32:}

where line coverage for line 16 is reported to be a nonzero value.

Tweaking the code format can produce what's closer to the original symptom
I experienced in lzma (although the first format seems more concerning):

-:   12:{
   77:   13:g++;
  84*:   14:if (never) { g++; return; }
-:   15:

[Bug c++/120349] New: [16 regression] std::println link fail with std module

[c at cyano dot cn via Gcc-bugs]

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

Bug ID: 120349
   Summary: [16 regression] std::println link fail with std module
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: c at cyano dot cn
  Target Milestone: ---

`test.cc`:
```
import std;

int main() {
  std::println("Hello, {0}!", "world");
  return 0;
}
```

Compiled with:
```
g++ -std=c++23 -fmodules -O2 -fmodule-only -fsearch-include-path -c bits/std.cc
g++ -std=c++23 -fmodules -O2 test.cc
```

Error message:
```
/usr/bin/ld: /tmp/ccml92so.o: in function `std::format_error::~format_error()':
test.cc:(.text._ZNSt12format_errorD2Ev[_ZNSt12format_errorD5Ev]+0x3): undefined
reference to `vtable for std::format_error'
/usr/bin/ld: /tmp/ccml92so.o: in function `std::__throw_format_error(char
const*)':
test.cc:(.text.unlikely._ZSt20__throw_format_errorPKc[_ZSt20__throw_format_errorPKc]+0x21):
undefined reference to `vtable for std::format_error'
/usr/bin/ld: /tmp/ccml92so.o: in function `std::format_error::~format_error()':
test.cc:(.text._ZNSt12format_errorD0Ev[_ZNSt12format_errorD5Ev]+0x7): undefined
reference to `vtable for std::format_error'
/usr/bin/ld: /tmp/ccml92so.o: in function `main.cold':
test.cc:(.text.unlikely+0x2f): undefined reference to `vtable for
std::__format::_Seq_sink, std::allocator > >'
/usr/bin/ld: test.cc:(.text.unlikely+0x85): undefined reference to `vtable for
std::__format::_Seq_sink, std::allocator > >'
/usr/bin/ld: /tmp/ccml92so.o: in function `.LC25':
test.cc:(.rodata.cst8+0x0): undefined reference to `vtable for
std::__format::_Seq_sink, std::allocator > >'
/usr/bin/ld: /tmp/ccml92so.o: in function `.LC26':
test.cc:(.rodata.cst8+0x8): undefined reference to `vtable for
std::__format::_Formatting_scanner, char>'
collect2: error: ld returned 1 exit status
```

Bisection points to
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c875748cdc468ec604c904e19a688998aa4d7a1f.

`gcc -v`:
```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/cyano/gcc-git/bin/../libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix= --enable-languages=c,c++
--enable-static --disable-shared --disable-bootstrap --disable-multilib
CFLAGS=-O2 CXXFLAGS=-O2 LDFLAGS=-s
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250516 (experimental) (GCC) 
```

[Bug c++/120351] New: ldrex r1, [s14], invalid use of NEON registers

[jhofstee at victronenergy dot com via Gcc-bugs]

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

Bug ID: 120351
   Summary: ldrex r1, [s14], invalid use of NEON registers
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jhofstee at victronenergy dot com
  Target Milestone: ---

When compiling gcc for ARM with --with-arch=armv7-a gcc can emit invalid
instructions like ldrex r1, [s14]

godbolt can't reproduce this, since it depends on mentioned configure flag.

Below script builds gcc 15.1.0 with the issue:
https://github.com/jhofstee/qatomic-failure/blob/master/build-gcc-cross/make-gcc-cross.sh

This will then trigger the issue:
/opt/cross/bin/arm-oe-linux-gnueabi-c++ -O2 reduced.cpp -c -ffunction-sections
-O2 -save-temps -fverbose-asm -std=c++17 -O2 -Wall -Wextra  -mfpu=neon
-mfloat-abi=hard -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64
reduced.s: Assembler messages:
reduced.s:47: Error: ARM register expected -- `ldrex r1,[s14]'
reduced.s:49: Error: ARM register expected -- `strex r2,r1,[s14]'

[Bug c++/120350] New: [modules] address taken but ‘TREE_ADDRESSABLE’ bit not set for imported inline ref of typeid

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

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

Bug ID: 120350
   Summary: [modules] address taken but ‘TREE_ADDRESSABLE’ bit not
set for imported inline ref of typeid
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nshead at gcc dot gnu.org
Blocks: 103524
  Target Milestone: ---

Consider:

  // a.cpp
  module;
  #include 
  export module M;
  struct S {};
  export inline auto& x = typeid(S);

  // b.cpp
  import M;
  int main() { x == x; }

$ g++ -fmodules -S a.cpp b.cpp

b.cpp: In function ‘int main()’:
b.cpp:2:5: error: address taken but ‘TREE_ADDRESSABLE’ bit not set
2 | int main() {
  | ^~~~
x.0_1 = &_ZTIW1M1S;
b.cpp:2:5: error: address taken but ‘TREE_ADDRESSABLE’ bit not set
x.1_2 = &_ZTIW1M1S;
b.cpp:2:5: internal compiler error: ‘verify_gimple’ failed
0x3d7f97f internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x1df90b7 verify_gimple_in_seq(gimple*, bool)
../../gcc/gcc/tree-cfg.cc:5350
0x190cf3a gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.cc:20916
0x190d479 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.cc:21042
0x1618b64 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.cc:689
0x161b055 analyze_functions
../../gcc/gcc/cgraphunit.cc:1265
0x161e6e1 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.cc:2574
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.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug target/120351] ldrex r1, [s14], invalid use of NEON registers

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

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

--- Comment #2 from Sam James  ---
```
# diff -u <(g++-14 /tmp/a.cxx -O2 -S -mfpu=neon -o -) <(g++-15 /tmp/a.cxx -O2
-S -mfpu=neon -o -)
--- /dev/fd/63  2025-05-19 10:57:07.663372453 -
+++ /dev/fd/62  2025-05-19 10:57:07.666705782 -
@@ -31,10 +31,9 @@
.pad #32
sub sp, sp, #32
ldr r3, .L7+4
-   add r4, sp, #20
+   add r0, sp, #20
 .LPIC0:
add r2, pc, r2
-   mov r0, r4
ldr r3, [r2, r3]
ldr r3, [r3]
str r3, [sp, #28]
@@ -43,16 +42,15 @@
mov r0, sp
bl  _ZN1BC1Ev(PLT)
vldrd7, [sp]
-   vmovr3, s14 @ int
vstrd7, [sp, #8]
 .L3:
-   ldrex   r1, [r3]
+   ldrex   r1, [s14]
add r1, r1, #1
-   strex   r2, r1, [r3]
+   strex   r2, r1, [s14]
cmp r2, #0
bne .L3
add r1, sp, #8
-   mov r0, r4
+   add r0, sp, #20
bl  _ZN1B9insertOneES_(PLT)
ldr r2, .L7+8
ldr r3, .L7+4
```

[Bug target/120351] ldrex r1, [s14], invalid use of NEON registers

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

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

Sam James  changed:

   What|Removed |Added

  Component|c++ |target
   Keywords||assemble-failure,
   ||wrong-code

--- Comment #1 from Sam James  ---
Please always include relevant files as attachments. See
https://gcc.gnu.org/bugs/#need.

Anyway, I can reproduce it:
```
$ g++-14 /tmp/a.cxx -O2 -c -mfpu=neon
$ g++-15 /tmp/a.cxx -O2 -c -mfpu=neon
/tmp/ccTgsrnS.s: Assembler messages:
/tmp/ccTgsrnS.s:47: Error: ARM register expected -- `ldrex r1,[s14]'
/tmp/ccTgsrnS.s:49: Error: ARM register expected -- `strex r2,r1,[s14]'
```

```
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/15/lto-wrapper
Target: armv7a-unknown-linux-gnueabihf
Configured with:
/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./configure
--host=armv7a-unknown-linux-gnueabihf --build=armv7a-unknown-linux-gnueabihf
--prefix=/usr --bindir=/usr/armv7a-unknown-linux-gnueabihf/gcc-bin/15
--includedir=/usr/lib/gcc/armv7a-unknown-linux-gnueabihf/15/include
--datadir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabihf/15
--mandir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabihf/15/man
--infodir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabihf/15/info
--with-gxx-include-dir=/usr/lib/gcc/armv7a-unknown-linux-gnueabihf/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/armv7a-unknown-linux-gnueabihf/15/python
--enable-libphobos --enable-objc-gc
--enable-languages=c,c++,d,objc,obj-c++,fortran,ada,rust --enable-obsolete
--enable-secureplt --disable-werror --with-system-zlib --enable-nls
--without-included-gettext --disable-libunwind-exceptions
--enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 15.1. p, commit
931f2ec7eafda39ea33684e191c9e2e8b4239fdc' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --with-float=hard --with-arch=armv7-a
--with-float=hard --with-fpu=vfpv3-d16 --enable-libgomp --disable-libssp
--enable-libada --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --with-isl
--disable-isl-version-check --enable-default-pie --enable-host-pie
--enable-host-bind-now --enable-default-ssp --disable-fixincludes
--with-gxx-libcxx-include-dir=/usr/include/c++/v1
--with-build-config=bootstrap-O3
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.1.1 20250518 848e7b119cc4558aec8f473dced811ae8b54829f (Gentoo
15.1. p, commit 931f2ec7eafda39ea33684e191c9e2e8b4239fdc)
```

[Bug target/120351] [15/16 regression] Assemble failure on armv7-a with -mfpu=neon (ldrex r1, [s14], invalid use of NEON registers)

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

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

--- Comment #4 from Sam James  ---
For completeness, my pastes are with:

$ as --version
GNU assembler (Gentoo  p1) 2.44.50.20250518

[Bug target/120351] ldrex r1, [s14], invalid use of NEON registers

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---
Created attachment 61469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61469&action=edit
a.cxx

[Bug target/120351] [15/16 regression] Assemble failure on armv7-a with -mfpu=neon (ldrex r1, [s14], invalid use of NEON registers)

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.2
Summary|ldrex r1, [s14], invalid|[15/16 regression] Assemble
   |use of NEON registers   |failure on armv7-a with
   ||-mfpu=neon (ldrex r1,
   ||[s14], invalid use of NEON
   ||registers)

[Bug tree-optimization/118924] [12 regression] Wrong code at -O2 and above leading to uninitialized accesses on aarch64-linux-gnu since r10-917-g3b47da42de621c

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

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||12.4.1
 Status|ASSIGNED|RESOLVED

--- Comment #29 from Sam James  ---
Fixed.

[Bug ipa/110282] [12/13/14/15 regression] Segmentation fault with specific optimizations since r10-3311-gff6686d2e5f797

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-05-19
 Status|UNCONFIRMED |NEW

--- Comment #19 from Sam James  ---
Tentatively confirmed then.

[Bug middle-end/120352] New: scalar epiloque not needed for early break when exit block is invariant

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

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

Bug ID: 120352
   Summary: scalar epiloque not needed for early break when exit
block is invariant
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
Blocks: 53947, 115130
  Target Milestone: ---

The following sequence

#define N 4
int a[N] = {0,0,0,1};
int b[N] = {0,0,0,1};

__attribute__((noipa, noinline))
int foo ()
{
  for (int i = 0; i < N; i++)
{
  if (a[i] > b[i])
return 1;
}
  return 0;
}

on AArch64 compiles to:

ldr q31, [x2, #:lo12:.LANCHOR0]
ldr q30, [x1, 16]
cmgtv30.4s, v31.4s, v30.4s
umaxp   v30.4s, v30.4s, v30.4s
fmovx3, d30
cbnzx3, .L8
ret
.L8:
ldr w0, [x2, #:lo12:.LANCHOR0]
ldr w3, [x1, 16]
cmp w3, w0
blt .L6
ldr w0, [x1, 4]
ldr w2, [x1, 20]
cmp w2, w0
blt .L6
ldr w0, [x1, 8]
ldr w2, [x1, 24]
cmp w2, w0
blt .L6
ldr w0, [x1, 28]
ldr w2, [x1, 12]
cmp w2, w0
csetw0, gt
ret
.L6:
mov w0, 1
ret

However since the body of the break contains only loop invariant instructions
and the remainder of the loop is empty we don't need the scalar epiloque as the
IV value is irrelevant.

This sequence is somewhat common as it's a `contains` check


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115130
[Bug 115130] [meta-bug] early break vectorization

[Bug c++/120349] [16 regression] std::println link fail with std module since r16-688-gc875748cdc468e

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |16.0
Summary|[16 regression] |[16 regression]
   |std::println link fail with |std::println link fail with
   |std module  |std module since
   ||r16-688-gc875748cdc468e
 Blocks||103524
   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
   Last reconfirmed||2025-05-19
   Keywords||link-failure
 CC||nshead at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Nathaniel Shead  ---
Confirmed.  Minimal reproducer:

  // a.cpp
  module;
  struct S {
virtual ~S() {}
  };
  struct D : S {};
  export module M;
  export using ::D;

  // b.cpp
  import M;
  int main() { D d; }

$ g++-16 -fmodules a.cpp b.cpp
/usr/bin/ld: /tmp/ccym3Ujw.o: in function `S::~S()':
b.cpp:(.text._ZN1SD2Ev[_ZN1SD5Ev]+0x9): undefined reference to `vtable for S'
collect2: error: ld returned 1 exit status

It looks like I was overzealous in cleaning up some of the special-casing for
vtable linkage.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug c/120353] New: Flex array struct referenced in the middle via type alias of forward declaration is not reported by -Wflex-array-member-not-at-end option

[alansnape3058 at gmail dot com via Gcc-bugs]

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

Bug ID: 120353
   Summary: Flex array struct referenced in the middle via type
alias of forward declaration is not reported by
-Wflex-array-member-not-at-end option
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alansnape3058 at gmail dot com
  Target Milestone: ---

Details and comparison with Clang in https://godbolt.org/z/P1aYbY1j3

For a struct containing a flexible array member, if one of its type aliases is
defined with its forward declaration, referencing this alias to define a member
in the middle of another struct will not be reported by option
-Wflex-array-member-not-at-end.

```
typedef struct X XX;

struct X {
int length;
int a[];
};

struct Q {
XX x;
int plug;
};
```

In this example, a type alias `XX` is defined for `struct X` via its forward
declaration. Then, `struct X` is defined as a flexible array struct. Finally,
the type alias `XX` is referenced in `struct Q` to define a member in the
middle. This leads to a flexible array member in the middle problem. However,
this problem is not reported by the latest version of GCC.

Even if there are other re-definitions of `XX` below `struct X`, when there is
a definition above the struct, this problem will not be reported.

```
typedef struct X XX; // First definition above struct X

struct X {
int length;
int a[];
};

typedef struct X XX; // Redefinition below struct X

struct Q {
XX x; // Also not reported
int plug;
};
```

[Bug c/120354] Flexible array union in the middle is not reported by -Wflex-array-member-not-at-end option when flexible array member is not the last one

[alansnape3058 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Ella Ma  ---
Details and comparison with Clang in https://godbolt.org/z/h8qYhK6rY

[Bug c/120354] New: Flexible array union in the middle is not reported by -Wflex-array-member-not-at-end option when flexible array member is not the last one

[alansnape3058 at gmail dot com via Gcc-bugs]

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

Bug ID: 120354
   Summary: Flexible array union in the middle is not reported by
-Wflex-array-member-not-at-end option when flexible
array member is not the last one
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alansnape3058 at gmail dot com
  Target Milestone: ---

Details and comparison with Clang in

The unions containing a flexible array member that is not the last one are not
considered flexible array unions.

```
union X {
int x[];
int y;
};

struct T {
union X x;
int plug;
};
```

In this example, the flexible array member in `union X` is not the last
element. However, it is still a flexible array union. When using this union to
define a member in the middle of another struct, the usage is not reported.

This is also true when referencing a flexible array struct in the union.

```
struct Q {
int len;
int data[];
};

union Y {
struct Q q;
int y;
};

struct S {
union Y y;
int plug;
};
```

[Bug cobol/119790] FE (parser): CONSTANT AS figurative-constant broken

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

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

James K. Lowden  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2025-05-19
   Assignee|unassigned at gcc dot gnu.org  |jklowden at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from James K. Lowden  ---
fixed on parser 3adf4337a3b, update to gcc/master pending.

[Bug libstdc++/120029] Dangling iterator usage in std::filesystem::path::operator+=(const std::filesystem::path &p) when this == p

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Jonathan Wakely
:

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

commit r15-9709-gbeb0ffd36eedf0542d7f408e87efee4bee3150f8
Author: Jonathan Wakely 
Date:   Wed Apr 30 17:31:01 2025 +0100

libstdc++: Fix dangling pointer in fs::path::operator+=(*this) [PR120029]

When concatenating a path we reallocate the left operand's storage to
make room for the new components being added. When the two operands are
the same object, or the right operand is one of the components of the
left operand, the reallocation invalidates the pointers that refer
into the right operand's storage.

The solution in this commit is to detect these aliasing cases and just
do the concatenation in terms of the contained string, as that code
already handles the case where the string aliases the path. The standard
specifies the concatenation in terms of the native() string, so all this
change does is disable the optimized implementation of concatenation for
path objects which attempts to avoid re-parsing the path from the
concatenated string.

The potential loss of performance for this case isn't likely to be an
issue, because concatenating a path with itself (or one of its existing
components) probably isn't a common use case.

The Filesystem TS implementation doesn't have the optimized form of
concatenation and always does it in terms of the native string and
reparsing the whole thing, so doesn't have this bug. A test is added to
confirm that anyway (that test has some slightly different results due
to different behaviour for trailing slashes and implicit "." filenames
in the TS spec).

libstdc++-v3/ChangeLog:

PR libstdc++/120029
* src/c++17/fs_path.cc (path::operator+=(const path&)): Handle
parameters that alias the path or one of its components.
* testsuite/27_io/filesystem/path/concat/120029.cc: New test.
* testsuite/experimental/filesystem/path/concat/120029.cc: New
test.

(cherry picked from commit a067cbcdcc5f599a2b7d607e89674533d23c652d)

[Bug libstdc++/120293] std::format("{}", std::chrono::local_days()) should not include time-of-day

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:4bc5697341f1eda3b20c16dcf173948b2d1bd5c8

commit r15-9710-g4bc5697341f1eda3b20c16dcf173948b2d1bd5c8
Author: Jonathan Wakely 
Date:   Thu May 15 19:32:01 2025 +0100

libstdc++: Fix std::format of chrono::local_days with {} [PR120293]

Formatting of chrono::local_days with an empty chrono-specs should be
equivalent to inserting it into an ostream, which should use the
overload for inserting chrono::sys_days into an ostream. The
implementation of empty chrono-specs in _M_format_to_ostream takes some
short cuts, and that wasn't being done correctly for chrono::local_days.

libstdc++-v3/ChangeLog:

PR libstdc++/120293
* include/bits/chrono_io.h (_M_format_to_ostream): Add special
case for local_time convertible to local_days.
* testsuite/std/time/clock/local/io.cc: Check formatting of
chrono::local_days.

Reviewed-by: Tomasz KamiÅski 
(cherry picked from commit 1ed7585bf60ba9940ca5dc6d2c72dba86eea7b4d)

[Bug target/120347] [15/16 regression] invalid arm32/thumb assembly output

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #2 from Sam James  ---
-fno-late-combine-instructions works, just like in PR120351

[Bug libstdc++/120293] std::format("{}", std::chrono::local_days()) should not include time-of-day

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.5

[Bug libstdc++/120190] Definition of the primary template of std::format_kind seems IFNDR

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:53680c1aa92d9f78e8255fbf696c0ed36f160650

commit r15-9708-g53680c1aa92d9f78e8255fbf696c0ed36f160650
Author: Jonathan Wakely 
Date:   Thu May 15 11:01:05 2025 +0100

libstdc++: Fix std::format_kind primary template for Clang [PR120190]

Although Clang trunk has been adjusted to handle our std::format_kind
definition (because they need to be able to compile the GCC 15.1.0
release), it's probably better to not rely on something that they might
start diagnosing again in future.

Define the primary template in terms of an immediately invoked function
expression, so that we can put a static_assert(false) in the body.

libstdc++-v3/ChangeLog:

PR libstdc++/120190
* include/std/format (format_kind): Adjust primary template to
not depend on itself.
* testsuite/std/format/ranges/format_kind_neg.cc: Adjust
expected errors. Check more invalid specializations.

Reviewed-by: Tomasz KamiÅski 
Reviewed-by: Daniel Krügler 
(cherry picked from commit c65725eccbabf3b9b5965f27fff2d3b9f6c75930)

[Bug target/120351] [15/16 regression] Assemble failure on armv7-a with -mfpu=neon (ldrex r1, [s14], invalid use of NEON registers) since r15-1579-g792f97b44ffc5e

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

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

Sam James  changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu.org
   Last reconfirmed||2025-05-19
Summary|[15/16 regression] Assemble |[15/16 regression] Assemble
   |failure on armv7-a with |failure on armv7-a with
   |-mfpu=neon (ldrex r1,   |-mfpu=neon (ldrex r1,
   |[s14], invalid use of NEON  |[s14], invalid use of NEON
   |registers)  |registers) since
   ||r15-1579-g792f97b44ffc5e
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #5 from Sam James  ---
-fno-late-combine-instructions is a workaround

[Bug libstdc++/118031] [C++23] ranges::starts_with and ranges::ends_with

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2025-05-19
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |16.0

--- Comment #1 from Patrick Palka  ---
Patch posted for review:
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684041.html

[Bug cobol/119772] FE: COBOL2025/2026 (original GnuCOBOL extension) LENGTH OF usage-specification missing

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

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

James K. Lowden  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jklowden at gcc dot 
gnu.org
   Last reconfirmed||2025-05-19
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from James K. Lowden  ---
fixed in parser 89d6cd8d13a, update to gcc/master pending

[Bug libstdc++/120190] Definition of the primary template of std::format_kind seems IFNDR

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jonathan Wakely  ---
Fixed for 15.2

[Bug target/120347] [15/16 regression] invalid arm32/thumb assembly output

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||sjames at gcc dot gnu.org
   Last reconfirmed||2025-05-19

[Bug target/120347] [15/16 regression] invalid arm32/thumb assembly output

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

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

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Sandiford  ---
Mine then.

[Bug target/120347] [15/16 regression] invalid arm32/thumb assembly output

[arnd at linaro dot org via Gcc-bugs]

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

--- Comment #4 from Arnd Bergmann  ---
I have reduced another build failure (in some configurations but many files)
and found that also to be caused by -flate-combine-instructions

https://godbolt.org/z/7o1KE4jd3
void c(short *d) { asm("strh %1, %0" : : "Qo"(*(d + 1000)), "r"(0)); }

arm-linux-gnueabihf-gcc -O2 -march=armv7-a -marm test.c
/tmp/ccw7KGmj.s:77: Error: bad immediate value for 8-bit offset (2000)

I've added -fno-late-combine-instructions to the kernel cflags on my test box
now, which seems to address all of these. Let me know if I should open a
separate report for that.

[Bug target/120351] [15/16 regression] Assemble failure on armv7-a with -mfpu=neon (ldrex r1, [s14], invalid use of NEON registers) since r15-1579-g792f97b44ffc5e

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

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Earnshaw  ---
mine.

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #10 from kargls at comcast dot net ---
(In reply to Paul Thomas from comment #8)
> Created attachment 61466 [details]
>
> As I wrote elsewhere, I should have checked if anybody else is working on
> import. Apologies for treading on your toes.

No need to apologies.  As the audit trail indicates I got
stuck and then ran into have too little time to actually
work out how to handle import-list.

> 
> The testcase that I have been using follows.
> 
> Some important differences between our patches:
> 
> 1) I have assumed  and  import, only :: import_list>. Does this need an interpretation request?

My reading agrees with your interpretation above.  From F2003, 
made all host symbols available within an interface body.  
seems to be just a more verbose way of spelling .

Until you mentioned it, I unconsciously assumed 
was the same as .  It seems that J3 is
simply extending the .  Note, the use of only
a single colon.  The older former from F2003 must still be accepted
for backwards compatibility.

> 
> 2) I retained the original functioning of 'has_import_set' until such time
> as f2018 import functions to my satisfaction. Your approach is better.
> 
> 3) resolve.cc(check_import_status) is (possibly?) the wrong approach
> compared with your checking of host association in symbol.cc.

This is where I got stuck.   is easy as host association
is simply blocked in symbol.cc.  I was unable to come up with a way to 
implement .  My idea as to construct a linked
list of symbol names within the current namespace, but that's as far as
I got.

> 
> 4) I think that my error messages are more helpful, if considerably less
> concise.
> 
> A merging of the best features from both might be in order.
> 

Feel free to take or ignore anything from my WIP patch.  One 
that you may want to carry over is the big comment above
gfc_match_import with the EBNF of the various standards.  Once
you have something that you're happy with, feel free to ping
me for a review.

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #11 from kargls at comcast dot net ---
(In reply to Paul Thomas from comment #9)
> Created attachment 61467 [details]
> Test vehicle for my f2018 import patch
> 
> Hi Steve,
> 
> Note the sections marked WRINKLE. ifx considers an associate block to be
> executable code such that the import statement cannot appear there. With my
> patch, symbols in the associate target expression are not accepted, unless
> imported into the host scope.
> 

I just check F2023, and ifx is correct.  An import statement
is not allowed in an associate construct.  As an associate construct
does not have a declaration section.

R1102 associate‑construct is
  associate‑stmt

  end‑associate‑stmt

as opposed to

R1107 block‑construct is
  block‑stmt
 [block‑specification‑part]
 
  end‑block‑stmt

R1109 block‑specification‑part is
[ use‑stmt ] ...
[ import‑stmt ] ...
[ declaration‑construct ]

[Bug middle-end/118694] OpenMP: target/metadirective/teams directive nesting gives error

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

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

--- Comment #4 from sandra at gcc dot gnu.org ---
The nesting error is diagnosed in omp-low.cc.  By this time the gimplifier has
already replaced the metadirective with a conditional.  Since it's a static
selector, it'll be resolved to a constant during the ompdevlow pass, allowing
the conditional to be optimized away.

This can only happen when the metadirective selector is static and involves a
"device" selector in a configuration where it *might* match.  Dynamic selectors
are not allowed, and the other case for static selectors that requires late
resolution (a "construct" selector that can't be scored) doesn't apply here
because of the enclosing #omp target directive.

I thought briefly about refactoring the code in the gimplifier to duplicate the
enclosing #omp target into the arms of the conditional, but that would screw up
the resolution of the "device" selector and I don't think it's always
statically resolvable by examining the clauses on the #omp target.

I need to do some more investigation to discover if it will generate correct
code if the bogus error is disabled.  In that case the diagnostic could be
moved to the gimplifier, or the gimplifier could emit some sort of new marker
to enclose the metadirective expansion, without otherwise changing the
expansion.  Otherwise I have no ideas as yet.  :-(

[Bug fortran/120355] New: Type mismatch for passed external function, if external function appears in the same source file

[jsberg at bnl dot gov via Gcc-bugs]

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

Bug ID: 120355
   Summary: Type mismatch for passed external function, if
external function appears in the same source file
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsberg at bnl dot gov
  Target Milestone: ---

Created attachment 61470
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61470&action=edit
Fortran source demonstrating the bug

Compile the attached source with

gfortran bug-250519a.f90 -o bug-250519a

Compiler output is 

bug-250519a.f90:12:9:

   12 |   call t(s,i,j)
  | 1
..
   29 | function s(x) result(y)
Error: Type mismatch at (1) passing global function ‘s’ declared at (2)
(UNKNOWN/INTEGER(4))

If I put the external function at the end in a separate source file, the code
compiles without error.

OS is Arch, but I built gcc from 15.1.0 source to verify that the bug appears
in the released version:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jsberg/opt/gcc-15.1.0/libexec/gcc/x86_64-pc-linux-gnu/15.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-15.1.0/configure --prefix=/home/jsberg/opt/gcc-15.1.0
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.1.0 (GCC)

[Bug target/120356] New: [16 Regression] RISC-V: Miscompile at -O[23]

[ewlu at rivosinc dot com via Gcc-bugs]

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

Bug ID: 120356
   Summary: [16 Regression] RISC-V: Miscompile at -O[23]
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

Testcase:
unsigned char a = 5;
signed char b[8][18][18][18];
long long c[18];
long long aj;
char e = 9;
short g = 60;
unsigned q = 143;
char s = 119;
int u = 2;
void d(char e, short g, unsigned q, char s, int u) {
  for (short i = 0; i < g; i += 65413)
for (signed j = 0; j < 5; j++)
  for (short k = 0; k < 18; k++)
if (e) {
  for (unsigned l = 0; l < 18; l++) {
b[4][j][k][l] = 0;
if (g ? u : e)
  a *= 0 > e ? 0 : q;
  }
  for (char l = 0; l < 8; l++)
for (int m = 0; m < 18; m++)
  c[m] = 0;
}
}
int main() {
  d(e, g, q, s, u);
  aj ^= a;
  for (int am = 0; am < 8; ++am)
aj ^= c[am];
  __builtin_printf("%llu\n", aj);
}


Commands:
# -O3
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gcv_zvl256b -flto -O3 -mrvv-vector-bits=zvl red.c -o 
> user-config.out -fsigned-char -fno-strict-aliasing -fwrapv
> QEMU_CPU=rv64,vlen=256,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
>  timeout --verbose -k 0.1 4 
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/qemu-riscv64 user-config.out 
> 1
5

# -O2
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gcv_zvl256b -flto -O2 -mrvv-vector-bits=zvl red.c -o 
> user-config.out -fsigned-char -fno-strict-aliasing -fwrapv
> QEMU_CPU=rv64,vlen=256,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
>  timeout --verbose -k 0.1 4 
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/qemu-riscv64 user-config.out 
> 1
5

# -O1
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gcv_zvl256b -flto -O1 -mrvv-vector-bits=zvl red.c -o 
> user-config.out -fsigned-char -fno-strict-aliasing -fwrapv
> QEMU_CPU=rv64,vlen=256,rvv_ta_all_1s=true,rvv_ma_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
>  timeout --verbose -k 0.1 4 
> /scratch/ewlu/daily-upstream-build/build-gcv/bin/qemu-riscv64 user-config.out 
> 1
69

bisected to r15-6881-g7b815107f40 as the first bad commit

Found via fuzzer.

[Bug target/120326] problems with attribute __ms_struct__

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

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

Joseph S. Myers  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||uecker at gcc dot gnu.org

--- Comment #2 from Joseph S. Myers  ---
These two structs have no tags; it should be fine to have both of them in the
same translation unit, structs without tags need have no relation to one
another. Rejection should only be if they were given the same tag.

[Bug target/120356] [15/16 Regression] RISC-V: Miscompile at -O[23] since r15-6881-g7b815107f40

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|[16 Regression] RISC-V: |[15/16 Regression] RISC-V:
   |Miscompile at -O[23]|Miscompile at -O[23] since
   ||r15-6881-g7b815107f40
   Target Milestone|--- |15.2

[Bug target/120351] [15/16 regression] Assemble failure on armv7-a with -mfpu=neon (ldrex r1, [s14], invalid use of NEON registers) since r15-1579-g792f97b44ffc5e

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Richard Earnshaw :

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

commit r16-733-ge5bb7a328eb71daa02d15b48d3a6c6b8cd24abc5
Author: Richard Earnshaw 
Date:   Mon May 19 16:19:39 2025 +0100

arm: fully validate mem_noofs_operand [PR120351]

It's not enough to just check that a memory operand is of the form
mem(reg); after RA we also need to validate the register being used.
The safest way to do this is to call memory_operand.

PR target/120351

gcc/ChangeLog:

* config/arm/predicates.md (mem_noofs_operand): Also check the op
is a valid memory_operand.

gcc/testsuite/ChangeLog:

* gcc.target/arm/pr120351.c: New test.

[Bug target/120351] [15 regression] Assemble failure on armv7-a with -mfpu=neon (ldrex r1, [s14], invalid use of NEON registers) since r15-1579-g792f97b44ffc5e

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

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

Richard Earnshaw  changed:

   What|Removed |Added

Summary|[15/16 regression] Assemble |[15 regression] Assemble
   |failure on armv7-a with |failure on armv7-a with
   |-mfpu=neon (ldrex r1,   |-mfpu=neon (ldrex r1,
   |[s14], invalid use of NEON  |[s14], invalid use of NEON
   |registers) since|registers) since
   |r15-1579-g792f97b44ffc5e|r15-1579-g792f97b44ffc5e

--- Comment #8 from Richard Earnshaw  ---
Fixed on trunk so far.

[Bug target/120347] [15/16 regression] invalid arm32/thumb assembly output

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

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

--- Comment #5 from Richard Earnshaw  ---
(In reply to Arnd Bergmann from comment #4)
> I have reduced another build failure (in some configurations but many files)
> and found that also to be caused by -flate-combine-instructions
> 
> https://godbolt.org/z/7o1KE4jd3
> void c(short *d) { asm("strh %1, %0" : : "Qo"(*(d + 1000)), "r"(0)); }
> 
> arm-linux-gnueabihf-gcc -O2 -march=armv7-a -marm test.c
> /tmp/ccw7KGmj.s:77: Error: bad immediate value for 8-bit offset (2000)
> 
> I've added -fno-late-combine-instructions to the kernel cflags on my test
> box now, which seems to address all of these. Let me know if I should open a
> separate report for that.

The compiler has no idea what the valid range of supported offsets are in an
asm statement.  IIRC It just assumes the basic addressing modes (ldr/str).

But why aren't you using "m" here?  That does the right thing.

[Bug target/120347] [15/16 regression] invalid arm32/thumb assembly output

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Arnd Bergmann from comment #4)
> I have reduced another build failure (in some configurations but many files)
> and found that also to be caused by -flate-combine-instructions
> 
> https://godbolt.org/z/7o1KE4jd3
> void c(short *d) { asm("strh %1, %0" : : "Qo"(*(d + 1000)), "r"(0)); }
> 
> arm-linux-gnueabihf-gcc -O2 -march=armv7-a -marm test.c
> /tmp/ccw7KGmj.s:77: Error: bad immediate value for 8-bit offset (2000)
> 
> I've added -fno-late-combine-instructions to the kernel cflags on my test
> box now, which seems to address all of these. Let me know if I should open a
> separate report for that.

That is a different issue overall and I think it is invalid inline-asm:
(define_memory_constraint "Q"
 "@internal
  An address that is a single base register."
 (and (match_code "mem")
  (match_test "REG_P (XEXP (op, 0))")))

'o' definition:
A memory operand is allowed, but only if the address is offsettable. This means
that adding a small integer (actually, the width in bytes of the operand, as
determined by its machine mode) may be added to the address and the result is
also a valid memory address.

[Bug tree-optimization/120345] array subscript is partly outside array bounds

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL|https://godbolt.org/z/Pa8xh |
   |5T5n|

--- Comment #1 from Andrew Pinski  ---
https://godbolt.org/z/Pa8xh5T5n

[Bug fortran/120099] [16 regression] gfortran.dg/specifics_1.f90 FAILs since r16-372-g064cac730f88dc

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

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

--- Comment #22 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r16-734-gbf98b735ae01c652f641b824a7c4e1d575b5b6d8
Author: Harald Anlauf 
Date:   Sun May 18 22:42:26 2025 +0200

Fortran: fix FAIL of gfortran.dg/specifics_1.f90 after r16-372 [PR120099]

After commit r16-372, testcase gfortran.dg/specifics_1.f90 started to
FAIL at -O2 and higher, as DCE lead to elimination of evaluations of
Fortran specific intrinsics returning complex results and with -ff2c.
As the Fortran runtime library is compiled with -fno-f2c, the frontend
generates calls to wrapper subroutines _gfortran_f2c_specific_* that
return their result by reference via their first argument when this is
needed.  This is e.g. the case when specific names of the intrinsics are
used for passing as actual argument to procedures.  These wrappers are
not pure in the GCC IR sense, even if the Fortran intrinsics are.
Therefore gfc_return_by_reference must return true for these.

PR fortran/120099

gcc/fortran/ChangeLog:

* trans-types.cc (gfc_return_by_reference): Intrinsic functions
returning complex numbers may return their result by reference
with -ff2c.

[Bug target/120357] New: [16 Regression] RISC-V: ICE in vect pass "error: definition in block 9 does not dominate use in block 3"

[ewlu at rivosinc dot com via Gcc-bugs]

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

Bug ID: 120357
   Summary: [16 Regression] RISC-V: ICE in vect pass "error:
definition in block 9 does not dominate use in block
3"
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

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

Testcase:
char a;
void b(int d, int o, unsigned long long t[][22], int u[]) {
  for (int v = 0; v < d + 1488232569; v += o + 952017568)
for (_Bool w = 0; w < (u[v] < 0) + 1; w = 1)
  a *= 0 != t[w][v];
}
int d = 5780825713192689565;
int o = 3342949729;
unsigned long long t[2][22];
int u[2];
int main() {
  b(d, o, t, u);
}

Commands:
$
/scratch/ewlu/daily-upstream-build/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
-I/scratch/ewlu/ci/compiler-fuzz-ci/csmith-build/include -fsigned-char
-fno-strict-aliasing -fwrapv -march=rv64gcv_zvl256b -fwhole-program -O3 red.c
-o rv64gcv.out -w -freport-bug
red.c: In function 'main':
red.c:11:5: error: definition in block 9 does not dominate use in block 3
   11 | int main() {
  | ^~~~
for SSA_NAME: mask__36.15_83 in statement:
_102 = VEC_COND_EXPR ;
during GIMPLE pass: vect
red.c:11:5: internal compiler error: verify_ssa failed
0x31772b6 internal_error(char const*, ...)
../../../gcc/gcc/diagnostic-global-context.cc:517
0x17075bf verify_ssa(bool, bool)
../../../gcc/gcc/tree-ssa.cc:1203
0x1339155 execute_function_todo
../../../gcc/gcc/passes.cc:2108
0x13395ee execute_todo
../../../gcc/gcc/passes.cc:2155
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccVIenpc.out file, please attach this to
your bugreport.

Godbolt: https://godbolt.org/z/YdKh9ed87

Original fuzzer command used -flto but -fwhole-program also causes the ICE

Found via fuzzer.

[Bug ipa/120345] array subscript is partly outside array bounds

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |ipa
   Keywords||missed-optimization

--- Comment #2 from Andrew Pinski  ---
So what is happening is devirtualization decided that `Base *update` might be
Derived1 and added a check there. And then the warning happens because of
inlining.

I have not looked into why include -fcheck-new causes that.

[Bug target/120347] [15/16 regression] invalid arm32/thumb assembly output

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

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

--- Comment #7 from Richard Earnshaw  ---
The address in offsettable_address is always validated as a 'byte' sized
address (it's generic code).  So it's not generally useful to use this on Arm
for validating anything that's more restricted than ldrb/strb.

[Bug fortran/120355] [15/16 Regression] Type mismatch for passed external function, if external function appears in the same source file

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|Type mismatch for passed|[15/16 Regression] Type
   |external function, if   |mismatch for passed
   |external function appears   |external function, if
   |in the same source file |external function appears
   ||in the same source file
 Ever confirmed|0   |1
   Last reconfirmed||2025-05-19
   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |15.2

[Bug fortran/120355] [15/16 Regression] Type mismatch for passed external function, if external function appears in the same source file

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/120355] [15/16 Regression] Type mismatch for passed external function, if external function appears in the same source file

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

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Workaround: don't use the result clause in the external function, e.g.

integer function s(x)
  implicit none
  integer, intent(in) :: x
  s = 1 - x
end function s

[Bug target/120308] 'TYPE_EMPTY_P' vs. code offloading

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

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

--- Comment #4 from GCC Commits  ---
The trunk branch has been updated by Thomas Schwinge :

https://gcc.gnu.org/g:9063810c86beee6274d745b91d8fb43a81c9683e

commit r16-738-g9063810c86beee6274d745b91d8fb43a81c9683e
Author: Thomas Schwinge 
Date:   Thu May 15 18:11:16 2025 +0200

'TYPE_EMPTY_P' vs. code offloading [PR120308]

We've got 'gcc/stor-layout.cc:finalize_type_size':

/* Handle empty records as per the x86-64 psABI.  */
TYPE_EMPTY_P (type) = targetm.calls.empty_record_p (type);

(Indeed x86_64 is still the only target to define 'TARGET_EMPTY_RECORD_P',
calling 'gcc/tree.cc-default_is_empty_record'.)

And so it happens that for an empty struct used in code offloaded from
x86_64
host (but not powerpc64le host, for example), we get to see 'TYPE_EMPTY_P'
in
offloading compilation (where the offload targets (currently?) don't use it
themselves, and therefore aren't prepared to handle it).

For nvptx offloading compilation, this causes wrong code generation:
'ptxas [...] error : Call has wrong number of parameters', as nvptx code
generation for function definition doesn't pay attention to this flag (say,
in
'gcc/config/nvptx/nvptx.cc:pass_in_memory', or whereever else would be
appropriate to handle that), but the generic code
'gcc/calls.cc:expand_call'
via 'gcc/function.cc:aggregate_value_p' does pay attention to it, and we
thus
get mismatching function definition vs. function call.

This issue apparently isn't a problem for GCN offloading, but I don't know
if
that's by design or by accident.

Richard Biener:
> It looks like TYPE_EMPTY_P is only used during RTL expansion for ABI
> purposes, so computing it during layout_type is premature as shown here.
>
> I would suggest to simply re-compute it at offload stream-in time.

(For avoidance of doubt, the additions to
'gcc.target/nvptx/abi-struct-arg.c',
'gcc.target/nvptx/abi-struct-ret.c' are not dependent on the offload
streaming
code changes, but are just to mirror the changes to
'libgomp.oacc-c-c++-common/abi-struct-1.c'.)

PR lto/120308
gcc/
* lto-streamer-out.cc (hash_tree): Don't handle 'TYPE_EMPTY_P' for
'lto_stream_offload_p'.
* tree-streamer-in.cc (unpack_ts_type_common_value_fields):
Likewise.
* tree-streamer-out.cc (pack_ts_type_common_value_fields):
Likewise.
libgomp/
* testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c: Add empty
structure testing.
gcc/testsuite/
* gcc.target/nvptx/abi-struct-arg.c: Add empty structure testing.
* gcc.target/nvptx/abi-struct-ret.c: Likewise.

[Bug tree-optimization/22237] [4.0/4.1 Regression] struct copy inlining generates overlapping memcpy

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

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

--- Comment #9 from Andrew Pinski  ---
Just an FYI, LLVM uses memmove here instead of 2 memcpy.  

If we care about how memcpy we do, we can extend
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684017.html to do the
memmove for:
```
+  /* For 2 memory refences and using a temporary to do the copy,
+ don't remove the temporary as the 2 memory references might overlap.
+ Note t does not need to be decl as it could be field.
+ See PR 22237 for full details.
+ E.g.
+ t = *a;
+ *b = t;
+ Cannot be convert into
+ t = *a;
+ *b = *a;
+  */
+  if (!DECL_P (dest) && !DECL_P (src2))
+return false;

```

I am putting this into the bug report to remind me later on if we care enough.
this will have to be for the late forwprop but we should be able to handle the
conversion easily.

[Bug cobol/119770] FLOAT-DECIMAL support + "cannot MOVE '_stack1'"

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

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

James K. Lowden  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-19
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jklowden at gcc dot 
gnu.org

--- Comment #1 from James K. Lowden  ---
Fixed locally in parser df331ef465b, update to gcc/master pending. 

All messages (I hope!) now use a hyphen in the name, as in COBOL, not an
underscore, as in Bison.  And function temporaries now carry the function name,
for messages.

[Bug target/120333] [16 Regression] RISC-V: Wrong code with bitmanip extension

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from Jeffrey A. Law  ---
I think the pattern in that change is just bogus.  I forgot to account for the
fact that the left shift value isn't the bit position we care about.  The
position we care about is 63/31 - shift value (rv64/rv32).

Once we take into the account the need for that adjustment, the new code is no
better than the old code.  Thankfully that variant is the least important of
the single bit extraction variants.

[Bug middle-end/50481] builtin to reverse the bit order

[aleks at physik dot tu-berlin.de via Gcc-bugs]

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

Alexander Kleinsorge  changed:

   What|Removed |Added

 CC||aleks at physik dot 
tu-berlin.de

--- Comment #13 from Alexander Kleinsorge  ---
for single bytes (uint8), there could be a faster way (x86 + x64).
there are only logical ops and shifts, nothing else.

static inline uint8 byte_rev(uint8 v) {
const uint64 BREV64 = ~0x084c2a6e195d3b7fLLu; // verify this number (LUT
like)
uint8 a = (BREV64) >> ((v % 16u) * 4u); // from low
uint8 b = (BREV64) >> ((v / 16u) * 4u); // from high
return (a * 16u) | (b % 16u);
}

[Bug tree-optimization/14295] [tree-ssa] copy propagation for aggregates

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

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

--- Comment #15 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684017.html

[Bug target/120347] [15/16 regression] invalid arm32/thumb assembly output

[arnd at linaro dot org via Gcc-bugs]

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

--- Comment #8 from Arnd Bergmann  ---
My mistake, I accidentally reintroduced the kernel bug from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54983 while debugging another
issue, so the code in comment #4 does not actually appear in the Linux kernel.

[Bug tree-optimization/120358] New: [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

Bug ID: 120358
   Summary: [15/16 regression] qtbase-6.9.0 miscompiled since
r15-580-gf3e5f4c58591f5
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: needs-reduction, wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 61472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61472&action=edit
tst_qstringtokenizer.cpp.ii.xz

Originally reported downstream in Gentoo at https://bugs.gentoo.org/956308.
qtbase-6.9.0's testsuite fails in tst_QStringTokenizer when built w/ `-O2
-march=x86-64-v4` or `-O3 -march=znver2` (I've gone with the latter, but the
former issue seems to be the same).

With -O2 -march=znver2:
```
/var/tmp/portage/dev-qt/qtbase-6.9.0-r1/work/qtbase-everywhere-src-6.9.0_build/tests/auto/corelib/text/qstringtokenizer
$ QTEST_FATAL_FAIL=1 valgrind -q ./tst_qstringtokenizer -nocrashhandler -v1 -v2
[...]
PASS   : tst_QStringTokenizer::emptyResult_U16(Empty/Empty (SkipEmptyParts))
INFO   : tst_QStringTokenizer::cleanupTestCase() entering
PASS   : tst_QStringTokenizer::cleanupTestCase()
Totals: 24 passed, 0 failed, 0 skipped, 0 blacklisted, 190ms
* Finished testing of tst_QStringTokenizer *
```

With -O3 -march=znver2:
```
/var/tmp/portage/dev-qt/qtbase-6.9.0-r1/work/qtbase-everywhere-src-6.9.0_build/tests/auto/corelib/text/qstringtokenizer
$ QTEST_FATAL_FAIL=1 valgrind -q ./tst_qstringtokenizer -nocrashhandler -v1 -v2
* Start testing of tst_QStringTokenizer *  
   
  Config: Using QtTest library 6.9.0, Qt 6.9.0
(x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 15.1.1
20250517), gentoo 2.17
INFO   : tst_QStringTokenizer::initTestCase() entering
PASS   : tst_QStringTokenizer::initTestCase()
INFO   : tst_QStringTokenizer::constExpr() entering
PASS   : tst_QStringTokenizer::constExpr()
INFO   : tst_QStringTokenizer::basics() entering
[...]
INFO   : tst_QStringTokenizer::basics(SkipEmptyParts/CaseSensitive)
QCOMPARE(toQStringList(qTokenize(u",a,b,c,d,e,", u',', cs, sb)), expected) 
18:17:37 [14/9235]
   Loc:
[/var/tmp/portage/dev-qt/qtbase-6.9.0-r1/work/qtbase-everywhere-src-6.9.0/tests/auto/corelib/text/qstringtokenizer/tst_qstringtokenizer.cpp(102)]
INFO   : tst_QStringTokenizer::basics(SkipEmptyParts/CaseSensitive)
QCOMPARE(toQStringList(tok), expected)
   Loc:
[/var/tmp/portage/dev-qt/qtbase-6.9.0-r1/work/qtbase-everywhere-src-6.9.0/tests/auto/corelib/text/qstringtokenizer/tst_qstringtokenizer.cpp(108)]
INFO   : tst_QStringTokenizer::basics(SkipEmptyParts/CaseSensitive)
QCOMPARE(toQStringList(tok), expected)
   Loc:
[/var/tmp/portage/dev-qt/qtbase-6.9.0-r1/work/qtbase-everywhere-src-6.9.0/tests/auto/corelib/text/qstringtokenizer/tst_qstringtokenizer.cpp(115)]
==717527== Conditional jump or move depends on uninitialised value(s)
==717527==at 0x4B087A0: qustrlen_sse2 (qstring.cpp:410)
==717527==by 0x4B087A0: QtPrivate::qustrlen(char16_t const*)
(qstring.cpp:661)
==717527==by 0x4B24D37: QString::QString(QChar const*, long long)
(qstring.cpp:2494)
==717527==by 0x400450E: QString (qstring.h:213)
==717527==by 0x400450E: toString (qstring.h:1207)
==717527==by 0x400450E: toQString (tst_qstringtokenizer.cpp:51)
==717527==by 0x400450E: toQStringList >
(tst_qstringtokenizer.cpp:59)
==717527==by 0x400450E: (anonymous
namespace)::tst_QStringTokenizer::basics() const [clone .isra.0]
(tst_qstringtokenizer.cpp:120)
==717527==by 0x4C4153E: QMetaMethodInvoker::invokeImpl(QMetaMethod, void*,
Qt::ConnectionType, long long, void const* const*, char const* const*,
QtPrivate::QMetaTypeInterface const* const*) (qmetaobject.cpp:2801)
==717527==by 0x4C41EA9: QMetaMethod::invokeImpl(QMetaMethod, void*,
Qt::ConnectionType, long long, void const* const*, char const* const*,
QtPrivate::QMetaTypeInterface const* const*) (qmetaobject.cpp:2640)
==717527==by 0x48B1C45: invoke (qmetaobject.h:150)
==717527==by 0x48B1C45: invoke<> (qmetaobject.h:162)
==717527==by 0x48B1C45: invokeTestMethodIfValid (qtestcase.cpp:434)
==717527==by 0x48B1C45: QTest::TestMethods::invokeTestOnData(int) const
(qtestcase.cpp:1050)
==717527==by 0x48B2BB5: operator() (qtestcase.cpp:1368)
==717527==by 0x48B2BB5: runWithWatchdog&) const:: >
(qtestcase.cpp:1251)
==717527==by 0x48B2BB5: QTest::TestMethods::invokeTest(int, QLatin1String,
std::optional&) const (qtestcase.cpp:1367)
==717527==by 0x48B3BDB: QTest::TestMethods::invokeTests(QObject*) const
(qtestcase.cpp:1710)
==717527==by 0x48C175E: QTest::qRun() (qtestcase.cpp:1951)
==717527==by 0x48C1ABD: QTest::qExec(QObjec

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

--- Comment #1 from Sam James  ---
Created attachment 61473
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61473&action=edit
build.sh

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.2
   Keywords||alias

[Bug cobol/119695] Incorrect diagnostic format specifiers in COBOL FE

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

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

James K. Lowden  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2025-05-19
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jklowden at gcc dot 
gnu.org

--- Comment #2 from James K. Lowden  ---
> The ones mentioning 'z' are gettext fault, %zd/%zu is supported in 
> gcc-internal-format.

gettext "15.3.1 C Format Strings" references POSIX, 

http://www.opengroup.org/onlinepubs/007904975/functions/fprintf.html

which defines z and l as length modifiers.  Are we sure z is not allowed? 
There are 55 examples of %zu in the COBOL FE, each one legitimate, typically
the result sizeof or strlen() or size().  

If they have to be removed, , it can be done.  But then please tell me
which documentation I should rely on, and specifically if l is OK.  

The numeric specifiers will be removed.  The only ones remaining were not
discovered during testing during conversion to the diagnostics framework.

[Bug cobol/119695] Incorrect diagnostic format specifiers in COBOL FE

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

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to James K. Lowden from comment #2)
> > The ones mentioning 'z' are gettext fault, %zd/%zu is supported in 
> > gcc-internal-format.
> 
> gettext "15.3.1 C Format Strings" references POSIX, 
> 
> http://www.opengroup.org/onlinepubs/007904975/functions/fprintf.html
> 
> which defines z and l as length modifiers.  Are we sure z is not allowed? 

Not all targets have POSIX compatible C library.
z is actually also ISO C99 and later modifier, but e.g. HPUX doesn't implement
that.

I've changed all the z modifier uses in the FE in *printf family functions to
HOST_SIZE_T_PRINT_UNSIGNED etc. macros and (fmt_size_t) casts, but perhaps some
new ones slipped in since then.
Note, z modifier in gcc-internal-format functions (error etc.) are fine, there
we do control the implementation and know it is always present (and using
macros is undesirable because it kills translations).

[Bug ipa/110282] [12/13/14/15 regression] Segmentation fault with specific optimizations since r10-3311-gff6686d2e5f797

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

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

--- Comment #20 from Martin Jambor  ---
(In reply to mcccs from comment #17)
>
[...]
> 
> The problem is that the parameter pointer is not set to the argument so
> dereferencing it causes a segfault. Dumping all the passes, this problem is
> first present in the output of the pass "x.c.100t.fixup_cfg3.c" as compiled
> with the modified GCC with -O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-dse
> -fno-tree-dse
> 

This looks pretty much like a bug that...

(In reply to mcccs from comment #15)
> There's indeed a miscompilation and I've confirmed it's still present in the
> current trunk. With -fno-dce -fno-ipa-cp -fno-tree-dce the issue was visible
> until r12-248 which made the issue latent. So I added -fno-tree-dse and then
> it was made latent by r12-1848. So I added:

...the commit r12-1848 aimed to fix.  What makes you think it is
"latent?"

>
[...]
> 
> Download the minimized testcase from
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282#c14
> 
> -O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-dse -fno-tree-dse
> 
> sed -i -e 's/mark_dead_statements (m_oparms\[i\]/(void)3;\/\//g'
> ./gcc/gcc/ipa-param-manipulation.cc
> 

This looks like undoing a fix for the problem you described in
comment#17, I'm afraid.

[Bug tree-optimization/120296] Missed VRP with __builtin_popcount() when bitshift with __builtin_{ctzg, clzg}

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com
   Last reconfirmed||2025-05-19
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Roger Sayle  ---
A step to implementing this would be to add folding optimizations to match.pd:

__builtin_popcount(x<<__builtin_clz(x)) => __builtin_popcount(x)
__builtin_popcount(x>>__builtin_ctz(x)) => __builtin_popcount(x)
when the right shift is unsigned or x is known to be non-negative

I don't think it's necessary to also check that x can't be zero (which
introduces undefined behavior (UB) in the c[tl]z, and from there UB in the
shift) as the result has strictly less UB than the input.

[Bug cobol/119636] compile error: gcobol1 does not find file descriptions in case of obsolete FD phrases

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

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

James K. Lowden  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jklowden at gcc dot 
gnu.org
   Last reconfirmed||2025-05-19
 Status|UNCONFIRMED |SUSPENDED
 Ever confirmed|0   |1

--- Comment #3 from James K. Lowden  ---
GCC COBOL makes no claim to support features that were obsolete 40 years ago,
when CCVS/85 was codified.  Whether or not it should do so is a value
judgement.  Without real code to test against, any effort to add that support
would be provisional at best.  

The user with working code in need of CCVS/85 features labelled OBSOLETE is
invited to file an issue here.  We would welcome the challenge.

[Bug cobol/119637] link error for LINAGE-COUNTER

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

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

--- Comment #2 from James K. Lowden  ---
The parser will emit a "sorry, unimplemented" LINAGE message for the time
being.

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-05-19
 Status|UNCONFIRMED |WAITING

--- Comment #2 from Andrew Pinski  ---
(In reply to Sam James from comment #0)
> Created attachment 61472 [details]
> tst_qstringtokenizer.cpp.ii.xz


Is there a way to regenerate this preprocessed source with a more recent GCC
15?
AVX512ER support has been removed so we get errors.

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

Sam James  changed:

   What|Removed |Added

  Attachment #61472|0   |1
is obsolete||

--- Comment #3 from Sam James  ---
Created attachment 61474
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61474&action=edit
tst_qstringtokenizer.cpp.ii.xz

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Sam James from comment #3)
> Created attachment 61474 [details]
> tst_qstringtokenizer.cpp.ii.xz

Just a quick note -march=znver2 is needed to compile this preprocessed source.
Even though -march=x86-64-v4 is mentioned in comment #0 :).

[Bug target/120333] [16 Regression] RISC-V: Wrong code with bitmanip extension

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:38fa6c0455ec14f2f42310a817b90765ad894aa4

commit r16-740-g38fa6c0455ec14f2f42310a817b90765ad894aa4
Author: Jeff Law 
Date:   Mon May 19 16:55:15 2025 -0600

[committed][RISC-V][PR target/120333] Remove bogus bext pattern

I goof'd when doing analysis of missed bext cases.  For the shift into the
sign
bit, then shift into the low bit case (thankfully the least common), I got
it
in my brain that the field is at the left shift count.   It's actually at
word_size - 1 - left shift count.

One the subtraction is included, it's no longer profitable to turn those
cases
into bext.  Best case scenario would be sub+bext, but we can just as easily
use
sll+srl which fuses in some designs into a single op.

So this patch removes those two patterns, adjusts the existing testcase and
adds the new execution test.

Given it's a partial reversion and has passed in my tester, I'm going to go
ahead and push it to the trunk rather than waiting for upstream CI.

PR target/120333
gcc/
* config/riscv/bitmanip.md: Remove bext formed from left+right
shift patterns.

gcc/testsuite/

* gcc.target/riscv/pr114512.c: Update expected output.
* gcc.target/riscv/pr120333.c: New test.

[Bug target/120333] [16 Regression] RISC-V: Wrong code with bitmanip extension

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug tree-optimization/120359] New: -Wtype-limits misses a warning when comparing enums

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

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

Bug ID: 120359
   Summary: -Wtype-limits misses a warning when comparing enums
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: diagnostic, testsuite-fail, xfail
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: dnovillo at gcc dot gnu.org, gcc-bugs at gcc dot gnu.org,
manu at gcc dot gnu.org, pinskia at gcc dot gnu.org
Depends on: 33738
Blocks: 89129, 33702
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #33738 +++
This testcase (g++.dg/warn/pr33738.C) was xfailed at r7-3163-g973625a04b3d93
and then the code which did the warning was removed at r13-4277-gca0be1bbedd637
.

The original bug report follows:
This was found on GCC 4.2.1.  In this test case, VRP quietly folds a comparison
between an enum type and a constant value that the enum type can never take.
With -Wtype-limits, this should give the warning:

comparison always false due to limited range of data type

extern void link_error (void);

enum Alpha {
 ZERO = 0, ONE, TWO, THREE
};

Alpha a2;

int m1 = -1;
int GetM1() {
 return m1;
}

int main() {
 a2 = static_cast(GetM1());
 if (a2 == -1) {   <-- VRP should warn when folding this.
link_error ();
 }
 return 0;
}

This is not warned by the front end because we promote -1 to the same type as
a2.  But during VRP, we *do* fold the predicate, so warning when -Wtype-limits
is given in this case would be a good QOI feature.

I have a patch in the works to make VRP warn when it linearizes this predicate.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33702
[Bug 33702] [meta-bug] GCC 4.4 pending patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33738
[Bug 33738] -Wtype-limits misses a warning when comparing enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89129
[Bug 89129] [meta-bug] bogus/missing -Wtype-limits warnings

[Bug tree-optimization/120359] -Wtype-limits misses a warning when comparing enums

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
I should note I noticed this while "improving" match to handle:
`(convert)a == CST` where the convert is used more than once.

Note r7-3163-g973625a04b3d93 has:
* g++.dg/warn/pr33738.C: XFAIL as optimization now happens in ccp.

This is not true, the optimization happened in EVRP but EVRP did not warn.

Note my change just exposed the failure started in GCC 6 even:
```
extern void link_error (void);

enum Alpha {
 ZERO = 0, ONE, TWO, THREE
};

int m1 = -1;
int GetM1() {
 return m1;
}

int main() {
 Alpha a3 = static_cast(GetM1());
 if (-1 == a3) {// { dg-warning "always false due" "" { xfail *-*-* } }
*/
link_error ();
 }
 return 0;
}
```

fails started in GCC 6.

[Bug target/120297] [15/16 Regression] RISC-V: Miscompile at -O3

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-19
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Jeffrey A. Law  ---
I'm not seeing this fail, even when I go back to r15-6657-g405c99c1721 and test
that.  It might be helpful if you could pass along your executables, or even
better, the assembly code you're getting, particularly for the failing case.

[Bug tree-optimization/120359] -Wtype-limits misses a warning when comparing enums

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on|33738   |
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=33738
 Blocks|33702   |

--- Comment #2 from Andrew Pinski  ---
`-O2 -Wtype-limits -fstrict-enums -fno-short-enums -fdisable-tree-evrp` stopped
working in GCC 10. though.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33702
[Bug 33702] [meta-bug] GCC 4.4 pending patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33738
[Bug 33738] -Wtype-limits misses a warning when comparing enums

[Bug target/103771] [12/13/14 Regression] Missed vectorization under -mavx512f -mavx512vl after r12-5489

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

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

--- Comment #46 from GCC Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:1e579e2eb5bf69419222a10afc854565b6bc0d78

commit r16-750-g1e579e2eb5bf69419222a10afc854565b6bc0d78
Author: liuhongt 
Date:   Sun May 11 23:21:30 2025 -0700

Extend vect_recog_cond_expr_convert_pattern to handle REAL_CST

REAL_CST is handled if it can be represented in different floating
point types without loss of precision or under fast math.

gcc/ChangeLog:

PR tree-optimization/103771
* match.pd (cond_expr_convert_p): Extend the match to handle
REAL_CST.
* tree-vect-patterns.cc
(vect_recog_cond_expr_convert_pattern): Handle REAL_CST.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr103771-5.c: New test.
* gcc.target/i386/pr103771-6.c: New test.

[Bug c++/120013] SIGSEGV ICE with modules related to instantiation of templates across partition units

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

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

commit r16-752-gb0de7297f2b5670386472229ab795a577c288ecf
Author: Nathaniel Shead 
Date:   Sat May 17 23:51:07 2025 +1000

c++/modules: Fix ICE on merge of instantiation with partial spec [PR120013]

When we import a pending instantiation that matches an existing partial
specialisation, we don't find the slot in the entity map because for
partial specialisations we register the TEMPLATE_DECL but for normal
implicit instantiations we instead register the inner TYPE_DECL.

Because the DECL_MODULE_ENTITY_P flag is set we correctly realise that
it is in the entity map, but ICE when attempting to use that slot in
partition handling.

This patch fixes the issue by detecting this case and instead looking
for the slot for the TEMPLATE_DECL.  It doesn't matter that we never add
a slot for the inner decl because we're about to discard it anyway.

PR c++/120013

gcc/cp/ChangeLog:

* module.cc (trees_in::install_entity): Handle re-registering
the inner TYPE_DECL of a partial specialisation.

gcc/testsuite/ChangeLog:

* g++.dg/modules/partial-8.h: New test.
* g++.dg/modules/partial-8_a.C: New test.
* g++.dg/modules/partial-8_b.C: New test.
* g++.dg/modules/partial-8_c.C: New test.
* g++.dg/modules/partial-8_d.C: New test.

Signed-off-by: Nathaniel Shead 
Reviewed-by: Jason Merrill 

[Bug c++/120350] [modules] address taken but ‘TREE_ADDRESSABLE’ bit not set for imported inline ref of typeid

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:9a6e5a437f0416627ee516f6ef5929cb30c5e498

commit r16-751-g9a6e5a437f0416627ee516f6ef5929cb30c5e498
Author: Nathaniel Shead 
Date:   Mon May 19 23:17:16 2025 +1000

c++/modules: Always mark tinfo vars as TREE_ADDRESSABLE [PR120350]

We need to mark type info decls as addressable if we take them by
reference; this is done by walking the declaration during parsing and
marking the decl as needed.

However, with modules we don't stream tinfo decls directly; rather we
stream just their name and type and reconstruct them in the importer
directly.  This means that any addressable flags are not propagated, and
we error because TREE_ADDRESSABLE is not set despite taking its address.

But tinfo decls should always have TREE_ADDRESSABLE set, as any attempt
to use the tinfo decl will go through build_address anyway.  So this
patch fixes the issue by eagerly marking the constructed decl as
TREE_ADDRESSABLE so that modules gets this flag correctly set as well.

PR c++/120350

gcc/cp/ChangeLog:

* rtti.cc (get_tinfo_decl_direct): Mark TREE_ADDRESSABLE.

gcc/testsuite/ChangeLog:

* g++.dg/modules/tinfo-3_a.H: New test.
* g++.dg/modules/tinfo-3_b.C: New test.

Signed-off-by: Nathaniel Shead 
Reviewed-by: Jason Merrill