[Bug libstdc++/120388] constraint on expected's comparison operator causes infinite recursion, overload resolution fails

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120388

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
.

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

[Bug libstdc++/120387] constraint on expected's comparison operator causes infinite recursion, overload resolution fails

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
This is PR119714 which is already fixed. You didn't show the output of 'gcc -v'
as requested, but I suspect you're using a snapshot before that fix.

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

[Bug libstdc++/119714] [15/16 Regression] Failure when using == operator on a class derived from std::expected

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119714

Jonathan Wakely  changed:

   What|Removed |Added

 CC||justend29 at gmail dot com

--- Comment #11 from Jonathan Wakely  ---
*** Bug 120387 has been marked as a duplicate of this bug. ***

[Bug c++/120243] [15/16 Regression] Exception rethrown from coroutine promise type unhandled_exception not caught under -O1

2025-05-21 Thread iains at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243

--- Comment #7 from Iain Sandoe  ---
update:

It seems not simply the inlining of the actor into the ramp
but also when the result of that is then inlined into main()

If I apply DECL_DISREGARD_INLINE_LIMITS() to the actor - so that it is inlined
into the ramp at O1 - but then mark the ramp as __attribute__((__noinline__))
then the code works as expected (including at O2, O3) .. so two levels of
inlining are involved..

[Bug target/120368] [16 Regression] wrong code with -O -fno-forward-propagate

2025-05-21 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120368

Jeffrey A. Law  changed:

   What|Removed |Added

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

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

[Bug target/120368] [16 Regression] wrong code with -O -fno-forward-propagate

2025-05-21 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120368

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

https://gcc.gnu.org/g:8459c546197dc9178d250994db021b36405f1bd6

commit r16-807-g8459c546197dc9178d250994db021b36405f1bd6
Author: Jeff Law 
Date:   Wed May 21 14:15:23 2025 -0600

[RISC-V][PR target/120368] Fix 32bit shift on rv64

So a followup to last week's bugfix.  In last week's change we we stopped
using
define_insn_and_split to rewrite instructions.  That change was done to
avoid
dropping a masking instruction out of the RTL.

As a result the pattern(s) were changed into simple define_insns, which is
good.  One of them uses the GPR iterator since it's supposed to work for
both
32bit and 64bit shifts on rv64.

But we failed to emit the right opcode for a 32bit shift on rv64.
Thankfully
the fix is trivial.  If the mode is anything but word_mode, then we must be
doing a 32-bit shift on rv64, ie the various "w" shift instructions.

It's run through my tester.  Just waiting on the upstream CI system to spin
it.

PR target/120368
gcc/
* config/riscv/riscv.md (shift with masked shift count): Fix
opcode when generating an SImode shift on rv64.

gcc/testsuite/
* gcc.target/riscv/pr120368.c: New test.

[Bug modula2/120389] Assigning a CHAR to an INTEGER crashes the compiler

2025-05-21 Thread gaius at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120389

Gaius Mulley  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2025-05-22

--- Comment #1 from Gaius Mulley  ---
Confirmed, thanks for the report.

[Bug libstdc++/120390] Request to improve error with private destructor

2025-05-21 Thread nightstrike at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390

--- Comment #6 from nightstrike  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to nightstrike from comment #3)
> > I know it isn't a bug,
> 
> You're missing the point. It *is* a bug if the diagnostic is bad. My point
> is that it's not a *compiler* bug, it's a library bug.
> 
> The compiler is doing exactly what the library code tells it to do.

Ah, thank you for the clarification.  I didn't understand that distinction, as
you surmised.

[Bug target/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size

2025-05-21 Thread pan2.li at intel dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362

--- Comment #17 from Li Pan  ---
FYI, the spec2017 619 ref size, with --thread > 1 can also trigger this issue,
but with another load.

10cf4:   0287f107vl1re64.v   v2,(a5)

thread = 1 is OK, as above code appears at omp related part, aka
00010cac :.

[Bug libstdc++/120387] New: constraint on expected's comparison operator causes infinite recursion, overload resolution fails

2025-05-21 Thread justend29 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387

Bug ID: 120387
   Summary: constraint on expected's comparison operator causes
infinite recursion, overload resolution fails
   Product: gcc
   Version: 15.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: justend29 at gmail dot com
  Target Milestone: ---

Created attachment 61488
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61488&action=edit
minimum reproducible example

ISSUE
=

The requires clause introduced in GCC15 on std::expected::operator==
prevents any type from being compared if it has std::expected as a template
argument, as evaluation of the constraint depends on itself.

The specific function causing the error is here
(https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/expected;h=5dc1dfbe5b8a954826d2779a9cbc51c953b5e5f0;hb=1b306039ac49f8ad91ca71d3de3150a3c9fa792a#l1172),
where its definition is as such:

1172   template
1173 requires (!__expected::__is_expected<_Up>)
1174   && requires (const _Tp& __t, const _Up& __u) {
1175 { __t == __u } -> convertible_to;
1176   }
1177 friend constexpr bool
1178 operator==(const expected& __x, const _Up& __v)
1179 noexcept(noexcept(bool(*__x == __v)))
1180 { return __x.has_value() && bool(*__x == __v); }


Minimum Reproducible Example


Included below is a minimum reproducible example. You'll notice that
std::expected is never compared. Merely, the compiler's evaluation of the
constraint on operator== during overload resolution causes the infinite
recursion.

// mre.cpp
#include 
#include 

template 
class A {
   public:
friend bool operator==(const A&, const A&) {
return true;  // not using T == T;
}

T t;
};

int main() {
static_assert(std::equality_comparable>>);
};

This issue is seen on GCC 15+, but not on GCC14, as the requires clause did not
yet exist. Compiler output with GCC 15.1.1 compiling mre.cpp with g++ mre.cpp
is shown below:

In file included from mre.cpp:2:
/usr/include/c++/15.1.1/expected: In substitution of ‘template 
requires !(__is_expected<_Up>) && requires(const _Tp& __t, const _Up& __u)
{{__t == __u} -> decltype(auto) [requires std::convertible_to<,
bool>];} constexpr bool std::operator==(const expected&, const _Up&)
[with _Up = A >]’:
/usr/include/c++/15.1.1/expected:1175:12:   required by substitution of
‘template  requires !(__is_expected<_Up>) && requires(const _Tp&
__t, const _Up& __u) {{__t == __u} -> decltype(auto) [requires
std::convertible_to<, bool>];} constexpr bool
std::operator==(const expected&, const _Up&) [with _Up =
A >]’
 1175 | { __t == __u } -> convertible_to;
  |   ^~
/usr/include/c++/15.1.1/concepts:306:10:   required from here
  306 |   { __t == __u } -> __boolean_testable;
  | ^~
/usr/include/c++/15.1.1/expected:1178:2:   required by the constraints of
‘template template  requires
!(__is_expected<_Up>) && requires(const _Tp& __t, const _Up& __u) {{__t == __u}
-> decltype(auto) [requires std::convertible_to<, bool>];}
constexpr bool std::operator==(const expected<_Tp, _Er>&, const _Up&)’
/usr/include/c++/15.1.1/expected:1174:7:   in requirements with ‘const _Tp&
__t’, ‘const _Up& __u’ [with _Tp = int; _Up = A >]
/usr/include/c++/15.1.1/expected:1174:14: error: satisfaction of atomic
constraint ‘requires(const _Tp& __t, const _Up& __u) {{__t == __u} ->
decltype(auto) [requires std::convertible_to<, bool>];} [with _Tp
= _Tp; _Up = _Up]’ depends on itself
 1174 |   && requires (const _Tp& __t, const _Up& __u) {
  |  ^~~
 1175 | { __t == __u } -> convertible_to;
  | ~~~
 1176 |   }
  |   ~   


Problem Evaluation
==

I believe these evaluation steps form the issue:
1. Overload resolution occurs for operator== between two
A> 
   types
2. std::expected is instantiated, along with its operator== shown
above.
3. Since std::expected is a template argument to A, namespace std is 
   involved in ADL with std::expected. The instantiated operator==
from 
   (2.) is then considered.
4. Although no std::expected is being compared, since constraints must be 
   evaluated before overload resolution, the compiler evaluates the 
   constraint on line 1175 above when considering the expected's operator==. 
   Within the constraint, lookup is again performed for operator== between 
   _Tp and _Up. For this MRE, _Tp is int (from std::expected) and _Up
is 
   A>.
5. When looking up operator== for the evaluation of the constraint, 
   std::expected is again a template argument, again bringing in 
   namespace s

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

2025-05-21 Thread sandra at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118694

--- Comment #7 from sandra at gcc dot gnu.org ---
Hmmm, that is helpful.  Which pass is it that depends on the strict nesting of
"omp teams" within "omp target" for code generation?  Is that also in omp-low
(where the nesting error is diagnosed) or some later pass?

[Bug libstdc++/120387] constraint on expected's comparison operator causes infinite recursion, overload resolution fails

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387

--- Comment #1 from Jonathan Wakely  ---
*** Bug 120388 has been marked as a duplicate of this bug. ***

[Bug cobol/119256] Capture source ranges for tokens in gcobol

2025-05-21 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119256

--- Comment #4 from David Malcolm  ---
James, I see you closed this as WONTFIX; was that just for the trailing "."
issue mentioned in comment #2, or for the whole idea?  I thought you were keen
on having ranges rather than points.

[Bug c++/120392] New: GCC Segmentation Fault Cross Compiling C++ Source

2025-05-21 Thread admin--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392

Bug ID: 120392
   Summary: GCC Segmentation Fault Cross Compiling C++ Source
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ad...@u-group13.org
  Target Milestone: ---

GCC (ARM C++ cross compiler, to be specific) segfaults when attempting to
compile the libcamera library (addon for Circle) using its standard
instructions with make. Compilation completes normally with v11.4.0 on my
laptop.

libcamera is cloned from commit 0b04195, make v4.4.1 was used, and the cross
compiler's version is v9.3.0

Error output is:

during GIMPLE pass: fnsplit
camerabuffer.cpp: In function 'CCameraBuffer::TPixel
CCameraBuffer::GetPixel(unsigned int, unsigned int)':
camerabuffer.cpp:265:1: internal compiler error: Segmentation fault
  265 | }
  | ^
unrecognized DWARF version in .debug_info at 6
unrecognized DWARF version in .debug_info at 6
unrecognized DWARF version in .debug_info at 6

Command triggering issue (as invoked by make):

arm-none-eabi-g++ -fno-exceptions -fno-rtti -nostdinc++ -DAARCH=32
-mcpu=arm1176jzf-s -marm -mfpu=vfp -mfloat-abi=hard -Wall -fsigned-char -g
-DUSE_USB_FIQ -D__circle__=49 -DRASPPI=1 -DSTDLIB_SUPPORT=1
-D__VCCOREVER__=0x0400 -U__unix__ -U__linux__  -I ../include -I
../circle/include -I ../circle/addon -I ../circle/app/lib -I
../circle/addon/vc4 -I ../circle/addon/vc4/interface/khronos/include  -O2
-ffreestanding -std=c++14 -Wno-aligned-new -c -o camerabuffer.o
camerabuffer.cpp

gcc -v output:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-unknown-linux-gnu/14.2.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /builddir/gcc-14.2.1+20250405/configure
--build=x86_64-unknown-linux-gnu --enable-gnu-unique-object
--enable-vtable-verify --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --libexecdir=/usr/lib64 --libdir=/usr/lib64
--enable-threads=posix --enable-__cxa_atexit --disable-multilib
--with-system-zlib --enable-shared --enable-lto --enable-plugins
--enable-linker-build-id --disable-werror --disable-nls --enable-default-pie
--enable-default-ssp --enable-checking=release --disable-libstdcxx-pch
--with-isl --with-linker-hash-style=gnu --disable-sjlj-exceptions
--disable-target-libiberty --disable-libssp
--enable-languages=c,c++,objc,obj-c++,fortran,lto,go,ada
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.1 20250405 (GCC)

Operating system: Void Linux x64, kernel v6.12.29_1
CPU: AMD Ryzen 7 3700X

[Bug c++/120392] GCC Segmentation Fault Cross Compiling C++ Source

2025-05-21 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392

--- Comment #1 from Sam James  ---
(In reply to admin from comment #0)
> Command triggering issue (as invoked by make):
> [...]

Please run this with -save-temps appened, then upload camerabuffer.ii (or
.cpp.ii). This is the preprocessed source mentioned at
https://gcc.gnu.org/bugs/#need.

[Bug c++/120392] GCC Segmentation Fault Cross Compiling C++ Source

2025-05-21 Thread admin--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392

--- Comment #2 from ad...@u-group13.org ---
Created attachment 61490
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61490&action=edit
Preprocessed source for component

Forgot to attach

[Bug c++/120392] GCC Segmentation Fault Cross Compiling C++ Source

2025-05-21 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392

--- Comment #3 from Sam James  ---
Wait, you're reporting this for GCC 9.3.0? Anything under 12 is EOL.

[Bug tree-optimization/120392] GCC Segmentation Fault Cross Compiling C++ Source

2025-05-21 Thread admin--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392

--- Comment #4 from ad...@u-group13.org ---
(In reply to Sam James from comment #3)
> Wait, you're reporting this for GCC 9.3.0? Anything under 12 is EOL.

Ah, apologies for the confusion. For some reason, Void's repos have an
up-to-date version of main GCC, but this particular cross-compiler is old. I
apparently got mixed up when checking package versions.

[Bug target/114064] [meta-bug] Use SVE instructions more for Advanced. SIMD

2025-05-21 Thread pzheng at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114064
Bug 114064 depends on bug 113328, which changed state.

Bug 113328 Summary: Some fixed length vector constants can be generated using 
SVE index instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113328

   What|Removed |Added

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

[Bug target/113328] Some fixed length vector constants can be generated using SVE index instruction

2025-05-21 Thread pzheng at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113328

Pengxuan Zheng  changed:

   What|Removed |Added

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

--- Comment #5 from Pengxuan Zheng  ---
Fixed.

[Bug tree-optimization/120392] GCC Segmentation Fault Cross Compiling C++ Source

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392

--- Comment #5 from Andrew Pinski  ---
I can reproduce it with:
xgcc (GCC) 15.0.1 20250319 (experimental) [trunk 37680168360]

[Bug c++/120392] GCC Segmentation Fault Cross Compiling C++ Source

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392

--- Comment #6 from Andrew Pinski  ---
Can reproduced on the trunk with x86_64-linux-gnu and -m32 -Os.

[Bug rtl-optimization/120374] ext-dce fails to realize a shift pair makes bits dead

2025-05-21 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120374

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2025-05-22

[Bug c++/120392] GCC Segmentation Fault Cross Compiling C++ Source

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392

--- Comment #7 from Andrew Pinski  ---
Created attachment 61491
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61491&action=edit
Reduced

ICEs at -O2+.

[Bug target/100837] nds32le-linux: error: array subscript 2 is above array bounds of 'rtx_def* [2]'

2025-05-21 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100837

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to work||16.0
   Last reconfirmed||2025-05-22

[Bug modula2/120389] New: Assigning a CHAR to an INTEGER crashes the compiler

2025-05-21 Thread belka at caraus dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120389

Bug ID: 120389
   Summary: Assigning a CHAR to an INTEGER crashes the compiler
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: belka at caraus dot de
  Target Milestone: ---

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

Here is the source code:

```
MODULE M;

VAR X: ARRAY[1..5] OF INTEGER;

BEGIN
  X[1] := 'c';
END M.
```

So it just declares an array of integers and assigns a character to an element.
Compiling this results in an ICE. Details are in the attachment.

[Bug tree-optimization/119835] GCN, nvptx offloading: ICE 'during GIMPLE pass: nrv' in "return value optimizations for functions which return aggregate types"

2025-05-21 Thread tschwinge at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119835

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed|2025-05-20 00:00:00 |2025-5-21
   Keywords||ABI
Summary|GCN, nvptx offloading:  |GCN, nvptx offloading: ICE
   |'libgomp.c++/pr106445-1.C'  |'during GIMPLE pass: nrv'
   |with '-fno-inline': ICE |in "return value
   |'during GIMPLE pass: nrv'   |optimizations for functions
   ||which return aggregate
   ||types"

--- Comment #2 from Thomas Schwinge  ---
So, per my current understanding, this is another host vs. offload target
ABI-related issue...

For example, also for C (not C++!) code:

typedef struct {int a;} sint;

static sint rsint(void)
{
  sint t;
  t.a = sizeof t;
  return t;
}

..., on the x86_64 host, 'gcc/gimplify.cc:gimplify_return_expr', we get:

 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x778b9150
fields 
SI
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c:10:21
size  unit-size 
align:32 warn_if_not_align:0 offset_align 128
decl_not_flexarray: 1
offset 
bit-offset  context
>
chain >
ignored SI
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c:45:13
size  unit-size 
align:32 warn_if_not_align:0 context >

..., and 'aggregate_value_p (result_decl, TREE_TYPE (current_function_decl))'
then does 'return false;' (at end of function).  In particular:

2132  if (targetm.calls.return_in_memory (type, fntype))

... does not 'return true;'.

Therefore, 'gimplify_return_expr' then does:

1934  result = create_tmp_reg (TREE_TYPE (result_decl));
[...]

..., and does not do the "If aggregate_value_p is true, then we can return the
bare RESULT_DECL." thing where it would set: 'result = result_decl;'.

(Similarly, presumably but not verified, for ppc64le host.)

However then in nvptx offloading compilation, we get:

 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x777b07e0
fields 
SI
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c:10:21
size  unit-size 
align:32 warn_if_not_align:0 offset_align 128
decl_not_flexarray: 1
offset 
bit-offset  context
>>
ignored BLK
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c:45:13
size  unit-size 
align:32 warn_if_not_align:0 context >

..., and with that 'aggregate_value_p' runs into:

2132  if (targetm.calls.return_in_memory (type, fntype))
(gdb)
2133return true;

... because:

pass_in_memory (mode=E_BLKmode, type=type@entry=0x777b0a80,
for_return=for_return@entry=true) at
../../source-gcc/gcc/config/nvptx/nvptx.cc:658
658 {
(gdb) n
659   if (type)
(gdb) 
661   if (AGGREGATE_TYPE_P (type))
(gdb) 
662 return true;

This is probably not surprising given 'BLK'?

(Similarly, presumably but not verified, for GCN offload target.)

This 'return true;' from 'aggregate_value_p' then enables the
'gcc/tree-nrv.cc:pass_nrv::execute' processing, which then fails in:

  tree result = DECL_RESULT (current_function_decl);
[...]
  if (greturn *return_stmt = dyn_cast  (stmt))
{
  /* In a function with an aggregate return value, the
 gimplifier has changed all non-empty RETURN_EXPRs to
 return the RESULT_DECL.  */
  ret_val = gimple_return_retval (return_stmt);
  if (ret_val)
gcc_assert (ret_val == result);
}

..., as the host code has not been set up conforming to that.

Any good suggestion about how to address this mismatch?

I don't understand enough of the GIMPLE/'DECL_RESULT' semantics to tell if we
could just disable this 'assert' here, and the pass would still be doing
correct transformations, or if that'd then potentially result in wrong code?

Per a quick instrumented run on powerpc64le-unknown-linux-gnu, for
'check-gcc-{c,c++,fortran}' and 'check-target' (for host, not offloading), this
pass is doing any code transformations only for exactly 24 (only!?) test cases,
so one option might be to just disable it for offloading compilation... 
(Yuck!)

But then, there's the more general problem of 'aggregate_value_p' potentially
returning different things for host vs. offload target -- somewhat similar to
what we had seen in PR120308 "'TYPE_EMPTY_P' vs. code offloading"...

Help?

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

2025-05-21 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357

Jeffrey A. Law  changed:

   What|Removed |Added

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

[Bug libstdc++/120387] constraint on expected's comparison operator causes infinite recursion, overload resolution fails

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387

--- Comment #3 from Jonathan Wakely  ---
(In reply to Justen Di Ruscio from comment #0)
> The specific function causing the error is here
> (https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/
> expected;h=5dc1dfbe5b8a954826d2779a9cbc51c953b5e5f0;
> hb=1b306039ac49f8ad91ca71d3de3150a3c9fa792a#l1172), where its definition is
> as such:

If you look at the current code instead of an older version, you'll see it's
different:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/expected;hb=releases/gcc-15#l1172

[Bug c++/120391] New: Enhancement: deduplicate constexpr char[] arrays with identical or overlapping contents

2025-05-21 Thread nickooo314 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120391

Bug ID: 120391
   Summary: Enhancement: deduplicate constexpr char[] arrays with
identical or overlapping contents
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickooo314 at gmail dot com
  Target Milestone: ---

In optimized builds, GCC currently does not deduplicate "constexpr char[]"
arrays that have identical or overlapping contents, even when using flags like
-Os or -fmerge-all-constants. This results in unnecessary duplication in
.rodata, especially for embedded or size-constrained targets.

Example (no deduplication):

$ cat merge_test.cpp 
#include 

constexpr char c1[] = {'H','e','l','l','o',' ','w','o','r','l','d','!','\0'};
constexpr char c2[] = {'w','o','r','l','d','!','\0'};

int main() {
puts(c1);
puts(c2);
}
$ /test/bin/g++ -Os -fmerge-all-constants -o merge_test merge_test.cpp
$ objdump -s -j .rodata merge_test

merge_test: file format elf64-x86-64

Contents of section .rodata:
 402000 01000200  776f726c 64210a00  world!..
 402010 48656c6c 6f20776f 726c6421 0a00  Hello world!..

Even though c2 is a suffix of c1, GCC emits both arrays independently in
.rodata, as opposed to string literals which get optimized (in fact even
without "-fmerge-all-constants"):

constexpr auto c1 = "Hello world!";
constexpr auto c2 = "world!";

$ objdump -s -j .rodata merge_test

merge_test: file format elf64-x86-64

Contents of section .rodata:
 402000 01000200 48656c6c 6f20776f 726c6421  Hello world!
 402010 00 

Is there any reason GCC doesn't perform this optimization even with
"-fmerge-all-constants" for constexpr char arrays?

[Bug libstdc++/120390] Request to improve error with private destructor

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390

Jonathan Wakely  changed:

   What|Removed |Added

  Component|c++ |libstdc++

--- Comment #5 from Jonathan Wakely  ---
(In reply to nightstrike from comment #3)
> I know it isn't a bug,

You're missing the point. It *is* a bug if the diagnostic is bad. My point is
that it's not a *compiler* bug, it's a library bug.

The compiler is doing exactly what the library code tells it to do.

[Bug c++/120391] Enhancement: deduplicate constexpr char[] arrays with identical or overlapping contents

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120391

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
```
.section.rodata.str1.1,"aMS",@progbits,1
.type   _ZL2c2, @object
.size   _ZL2c2, 7
_ZL2c2:
.string "world!"
.section.rodata.str1.8,"aMS",@progbits,1
.align 8
.type   _ZL2c1, @object
.size   _ZL2c1, 13
_ZL2c1:
.string "Hello world!"

```

With -fmerge-all-constants, the variables are emitted into the mergable
sections. So there is nothing for GCC to do here. 

The problem for x86_64 ABI, since c1 is larger than 8, it has an alignment for
8. Note the `.8` in the section name there.

So on aarch64 we get:
```
.section.rodata.str1.1,"aMS",@progbits,1
.type   _ZL2c2, %object
.size   _ZL2c2, 7
_ZL2c2:
.string "world!"
.type   _ZL2c1, %object
.size   _ZL2c1, 13
_ZL2c1:
.string "Hello world!"
```

Which then the linker can/will merge.

So this comes down to ABI requirements of x86_64.

[Bug libstdc++/120367] [15/16 Regression] C++23 ranges::transform | ranges::to exception catching (segfault)

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120367

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Mine then (I think we're deallocating an invalid pointer).

[Bug cobol/119232] gcobol -fdump-lang-all produces no dumps

2025-05-21 Thread jklowden at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119232

James K. Lowden  changed:

   What|Removed |Added

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

--- Comment #3 from James K. Lowden  ---
Isn't GENERIC itself the AST?  "The purpose of GENERIC is simply to provide a
language-independent way of representing an entire function in trees."  What
more abstraction is needed?  

Perhaps my point of view explains my opinion that GENERIC should have a
canonical, compilable textual representation.  IMO a mature, well-designed
language to represent compilable trees already exists: Lisp.  If GENERIC could
be dumped as Lisp, it could be examined in detail, and the output of different
front-ends (or different versions of the same front-end) could be compared.  

For us, GENERIC dumps were a requirement to get the COBOL FE up and running. 
No existing dump options were useful.  We wrote our own GENERIC dumper (twice!)
only to see it rejected. 

An ambition of mine, when we add OO to GCC COBOL, is to make COBOL objects
binary compatible with C++ objects (within semantic constraints).  A
fine-grained understanding of C++ GENERIC will doubtless be part of that
endeavor.  

I'm not sure what to do with this PR.  I don't understand what the goal of
-fdump-lang-all would be for COBOL, or what it would show, or how it would
improve on what we have already found useful.

[Bug libstdc++/120367] [15/16 Regression] C++23 ranges::transform | ranges::to exception catching (segfault)

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120367

--- Comment #4 from Jonathan Wakely  ---
Here's the fix:

--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -1969,7 +1969,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
_M_range_initialize_n(_Iterator __first, _Sentinel __last,
  size_type __n)
{
- pointer __start = this->_M_impl._M_start =
+ pointer __start = this->_M_impl._M_start = this->_M_impl._M_finish =
this->_M_allocate(_S_check_init_len(__n, _M_get_Tp_allocator()));
  this->_M_impl._M_end_of_storage = __start + __n;
  this->_M_impl._M_finish


Because vector(from_range_t, R&&) uses constructor delegation, it means that
the ~vector destructor will be run if an exception happens during the
delegating constructor.

When ~vector runs it destroys all the objects in the range [_M_start,_M_finish)
but we never set _M_finish, so it just destroys garbage.

The fix is to set _M_finish == _M_start so that ~vector has nothing to do.

[Bug cobol/119221] RFE: fix-it hints for cobol syntax errors

2025-05-21 Thread jklowden at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119221

James K. Lowden  changed:

   What|Removed |Added

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

--- Comment #1 from James K. Lowden  ---
Current output is better, but no hints yet.

tbug.cbl:1:10: error: syntax error, unexpected NAME, expecting IDENTIFICATION
DIVISION or PROGRAM-ID
1 |  PORGRAM-ID. TBUG.
  |  ^

I marked this as "suspended" because the important part IMO ("expecting") is
done, and errors/warnings are due for another overhaul RSN.  As experience
accumulates with GCC COBOL, we can review the diagnostics again for user
friendliness.

[Bug c++/120377] ICE with fmtlib and modules

2025-05-21 Thread cjangus at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120377

--- Comment #2 from Cameron Angus  ---
(In reply to Nathaniel Shead from comment #1)
> Having preprocessed sources makes it a lot easier for me, and I understand
> that there's some concerns about making sure that bugzilla remains as a
> source of truth for the issue even if say godbolt goes down or any of the
> other links rot.  But if you can't do that I'd still prefer having a bug
> over nothing at all :)

Understood, yeah that makes sense. Sometimes those extra couple of steps just
end up being the difference between me posting a bug or it sitting around for a
couple of weeks, that's all. 

> Your attached sources don't reproduce for me on my current build of trunk;
> on GCC15 I get an "error reporting routines re-entered", so it looks like
> something we've possibly already fixed for GCC16.

Hmm, interesting. I'm on the latest build I have access to, but it is a little
over a week old now. I expect a new one will come through soon and I'll test
again. I'm fairly sure I went through at least two distinct issues in the
process of reducing though, so I may just need to tweak things again. The
original ICE I was getting was a segmentation fault, and it changed to the
"error reporting routines re-entered" issue somewhere mid-reduction.

[Bug cobol/119324] cppcheck meets /cobol/

2025-05-21 Thread rdubner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324

--- Comment #6 from Robert Dubner  ---
I compiled and installed cppcheck 2.17, which was a bit of an intelligence
test.  The error messages were very chatty, but didn't actually tell me what I
needed to know.  It took a while, but the internet came through.

So I have a working installation of cppcheck 2.17

Here is simple attempt:

bob@doobie:~/repos/gcc-cobol/gcc/cobol$ cppcheck genapi.cc
Checking genapi.cc ...
genutil.h:104:1: error: There is an unknown macro here somewhere. Configuration
is required. If FIXED_WIDE_INT is a macro then please configure it.
[unknownMacro]
FIXED_WIDE_INT(128) get_power_of_ten(int n);
^
Checking genapi.cc: INCORPORATE_ANALYZER...
Checking genapi.cc: LINE_TICK...
Checking genapi.cc: YDFLTYPE;YDFLTYPE_IS_DECLARED...
Checking genapi.cc: YYLTYPE;YYLTYPE_IS_DECLARED...
Checking genapi.cc: _CBLDIAG_H...
Checking genapi.cc: _SYMBOLS_H_...
Checking genapi.cc: condition_lists...
Checking genapi.cc: yy_flex_debug...

Since there are a bunch of .h file in gcc/, I tried this:

bob@doobie:~/repos/gcc-cobol/gcc/cobol$ cppcheck genapi.cc --force -I..
Checking genapi.cc ...
../hwint.h:62:5: error: #error "Unable to find a suitable type for
HOST_WIDE_INT" [preprocessorErrorDirective]
   #error "Unable to find a suitable type for HOST_WIDE_INT"
^

I don't know what I am doing differently, or why I am seeing errors that you're
not.

[Bug lto/58203] memset/memcpy are discarded with -flto

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58203

Andrew Pinski  changed:

   What|Removed |Added

 CC||jas...@chili-chips.com

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

[Bug lto/58203] memset/memcpy are discarded with -flto

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58203

--- Comment #10 from Andrew Pinski  ---
The basic problem is the gimple IR has no reference to either memset or memcpy
in the case of zeroing  aggregates or copying them. So the linker does think
memset/memcpy is needed. And then when gcc expands the zeroing or copying, a
reference happens but it is already too late to bring back in them.

Marking memset/memcpy as used should bring in the reference to them if
memcpy/memset is only in lto ir.

[Bug bootstrap/120394] c++tools: configure doesn't honer --disable-default-pie

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120394

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
c++tools/configure.ac has:

# Check whether --enable-default-pie was given.
AC_ARG_ENABLE(default-pie,
[AS_HELP_STRING([--enable-default-pie],
  [enable Position Independent Executable as default])],
[PICFLAG=-fPIE], [PICFLAG=])

So yes --disable-default-pie will be handled incorrectly here.


AC_ARG_ENABLE(host-pie,
[AS_HELP_STRING([--enable-host-pie],
[build host code as PIE])],
[PICFLAG=-fPIE; LD_PICFLAG=-pie], [])
AC_SUBST(PICFLAG)

is also wrong.

So is:
AC_ARG_ENABLE(host-bind-now,
[AS_HELP_STRING([--enable-host-bind-now],
   [link host code as BIND_NOW])],
[LD_PICFLAG="$LD_PICFLAG -Wl,-z,now"], [])

[Bug c++/120393] New: Link-time optimization vs. Os/O2; baremetal memcpy elimination

2025-05-21 Thread jasmin--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120393

Bug ID: 120393
   Summary: Link-time optimization vs. Os/O2; baremetal memcpy
elimination
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jas...@chili-chips.com
  Target Milestone: ---

Use of `-flto' option generates an error for initialized char string variables.
Here is an example:

   char test[] = "Hello world!\r\n";

   for (i = 0; i < 14; i++) { 
  uart_send_char(csr, test[i]);
   }

  /usr/lib/gcc/riscv64-unknown-elf/13.2.0/../../../riscv64-unknown-elf/bin/ld:
/tmp/ccerPl2Y.ltrans0.ltrans.o: in function `main':
:(.text.startup+0x314): undefined reference to `memcpy'

The error comes from premature optimization, where linker concludes that the
`memcpy' function is not used in the source code, and eliminates it. The
workaround is to accompany the `memcpy' declaration with __attribute__((used)),
such as:

__attribute__((used)) void *memcpy(void *dest, const void *src, size_t
len);

Hence the questions:

 Q1) why does `-flto' option make the compile flow optimize out `memcpy'
function, which was actually inserted by the flow, to copy the initialized
strings?

Q2) can other functions outside of `main.cpp', including calls from boot CRT
Assembly code, be similarly eliminated by `-flto'?

This issue is uncovered in Wireguard-FPGA project, where tracked under:
   https://github.com/chili-chips-ba/wireguard-fpga/issues/17

It seems related to:
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119424

[Bug c++/120393] Link-time optimization vs. Os/O2; baremetal memcpy elimination

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120393

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug other/120394] New: c++tools: configure doesn't honer --disable-default-pie

2025-05-21 Thread deminhan at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120394

Bug ID: 120394
   Summary: c++tools: configure doesn't  honer
--disable-default-pie
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: deminhan at gcc dot gnu.org
  Target Milestone: ---

when pass --disable-default-pie, the enable_default_pie var would be "no".
The if condition met, and PICFLAG was set wrongly.

We should use "yes" or "no" for condition.

Similar issues for host-pie and host-bind-now.

# Check whether --enable-default-pie was given.
# Check whether --enable-default-pie was given.
if test "${enable_default_pie+set}" = set; then :
  enableval=$enable_default_pie; PICFLAG=-fPIE
else
  PICFLAG=
fi


# Enable --enable-host-pie
# Check whether --enable-host-pie was given.
if test "${enable_host_pie+set}" = set; then :
  enableval=$enable_host_pie; PICFLAG=-fPIE; LD_PICFLAG=-pie
fi



# Enable --enable-host-bind-now
# Check whether --enable-host-bind-now was given.
if test "${enable_host_bind_now+set}" = set; then :
  enableval=$enable_host_bind_now; LD_PICFLAG="$LD_PICFLAG -Wl,-z,now"
fi

[Bug libstdc++/120388] New: constraint on expected's comparison operator causes infinite recursion, overload resolution fails

2025-05-21 Thread justend29 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120388

Bug ID: 120388
   Summary: constraint on expected's comparison operator causes
infinite recursion, overload resolution fails
   Product: gcc
   Version: 15.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: justend29 at gmail dot com
  Target Milestone: ---

ISSUE
=

The requires clause introduced in GCC15 on std::expected::operator==
prevents any type from being compared if it has std::expected as a template
argument, as evaluation of the constraint depends on itself.

The specific function causing the error is here
(https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/expected;h=5dc1dfbe5b8a954826d2779a9cbc51c953b5e5f0;hb=1b306039ac49f8ad91ca71d3de3150a3c9fa792a#l1172),
where its definition is as such:

1172   template
1173 requires (!__expected::__is_expected<_Up>)
1174   && requires (const _Tp& __t, const _Up& __u) {
1175 { __t == __u } -> convertible_to;
1176   }
1177 friend constexpr bool
1178 operator==(const expected& __x, const _Up& __v)
1179 noexcept(noexcept(bool(*__x == __v)))
1180 { return __x.has_value() && bool(*__x == __v); }


Minimum Reproducible Example


Included below is a minimum reproducible example. You'll notice that
std::expected is never compared. Merely, the compiler's evaluation of the
constraint on operator== during overload resolution causes the infinite
recursion.

// mre.cpp
#include 
#include 

template 
class A {
   public:
friend bool operator==(const A&, const A&) {
return true;  // not using T == T;
}

T t;
};

int main() {
static_assert(std::equality_comparable>>);
};

This issue is seen on GCC 15+, but not on GCC14, as the requires clause did not
yet exist. Compiler output with GCC 15.1.1 compiling mre.cpp with g++ mre.cpp
is shown below:

In file included from mre.cpp:2:
/usr/include/c++/15.1.1/expected: In substitution of ‘template 
requires !(__is_expected<_Up>) && requires(const _Tp& __t, const _Up& __u)
{{__t == __u} -> decltype(auto) [requires std::convertible_to<,
bool>];} constexpr bool std::operator==(const expected&, const _Up&)
[with _Up = A >]’:
/usr/include/c++/15.1.1/expected:1175:12:   required by substitution of
‘template  requires !(__is_expected<_Up>) && requires(const _Tp&
__t, const _Up& __u) {{__t == __u} -> decltype(auto) [requires
std::convertible_to<, bool>];} constexpr bool
std::operator==(const expected&, const _Up&) [with _Up =
A >]’
 1175 | { __t == __u } -> convertible_to;
  |   ^~
/usr/include/c++/15.1.1/concepts:306:10:   required from here
  306 |   { __t == __u } -> __boolean_testable;
  | ^~
/usr/include/c++/15.1.1/expected:1178:2:   required by the constraints of
‘template template  requires
!(__is_expected<_Up>) && requires(const _Tp& __t, const _Up& __u) {{__t == __u}
-> decltype(auto) [requires std::convertible_to<, bool>];}
constexpr bool std::operator==(const expected<_Tp, _Er>&, const _Up&)’
/usr/include/c++/15.1.1/expected:1174:7:   in requirements with ‘const _Tp&
__t’, ‘const _Up& __u’ [with _Tp = int; _Up = A >]
/usr/include/c++/15.1.1/expected:1174:14: error: satisfaction of atomic
constraint ‘requires(const _Tp& __t, const _Up& __u) {{__t == __u} ->
decltype(auto) [requires std::convertible_to<, bool>];} [with _Tp
= _Tp; _Up = _Up]’ depends on itself
 1174 |   && requires (const _Tp& __t, const _Up& __u) {
  |  ^~~
 1175 | { __t == __u } -> convertible_to;
  | ~~~
 1176 |   }
  |   ~   


Problem Evaluation
==

I believe these evaluation steps form the issue:
1. Overload resolution occurs for operator== between two
A> 
   types
2. std::expected is instantiated, along with its operator== shown
above.
3. Since std::expected is a template argument to A, namespace std is 
   involved in ADL with std::expected. The instantiated operator==
from 
   (2.) is then considered.
4. Although no std::expected is being compared, since constraints must be 
   evaluated before overload resolution, the compiler evaluates the 
   constraint on line 1175 above when considering the expected's operator==. 
   Within the constraint, lookup is again performed for operator== between 
   _Tp and _Up. For this MRE, _Tp is int (from std::expected) and _Up
is 
   A>.
5. When looking up operator== for the evaluation of the constraint, 
   std::expected is again a template argument, again bringing in 
   namespace std into scope, and recursing to step (3.)


Solution


The std::expected's operator== above is similar to this overloa

[Bug c++/120390] Request to improve error with private destructor

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-05-21
 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=117294

--- Comment #2 from Jonathan Wakely  ---
The error is telling you that the assertion "type is destructible" failed. Like
when you get static_assert(some_cond) or assert(some_cond) and it says that
some_cond failed.

But I usually try to phrase the static assert messages as "X must be Y" to
avoid this ambiguity. I'll change that one.

I don't think this is a compiler bug. The code failed to compile because of a
static_assert, and that's exactly what the compiler tells you. Maybe something
like Bug 117294 could help, if that was extended to static_assert as well as
concept satisfaction failures.

[Bug c++/120390] Request to improve error with private destructor

2025-05-21 Thread nightstrike at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390

--- Comment #3 from nightstrike  ---
I know it isn't a bug, it's bad code that the compiler is correctly erroring
out on.  My point is that the original error message was spot on perfect in
highlighting the issue being that the destructor was private.  The new error
message leaves that important detail out.

[Bug c++/120390] Request to improve error with private destructor

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390

--- Comment #4 from Jonathan Wakely  ---
There's also the source context which should be pretty clear what the assertion
was testing when it failed:

  188 |   static_assert(is_destructible<_Value_type>::value,


But I think the best solution is to move the static_assert so it is only
checked for types with a trivial destructor, because it isn't needed otherwise:

--- a/libstdc++-v3/include/bits/stl_construct.h
+++ b/libstdc++-v3/include/bits/stl_construct.h
@@ -204,9 +204,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef typename iterator_traits<_ForwardIterator>::value_type
_Value_type;
 #if __cplusplus >= 201103L
-  // A deleted destructor is trivial, this ensures we reject such types:
-  static_assert(is_destructible<_Value_type>::value,
-   "value type must be destructible");
   if constexpr (!__has_trivial_destructor(_Value_type))
for (; __first != __last; ++__first)
  std::_Destroy(std::__addressof(*__first));
@@ -215,6 +212,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
for (; __first != __last; ++__first)
  std::destroy_at(std::__addressof(*__first));
 #endif
+  else
+   // A deleted destructor is trivial, this ensures we reject such types:
+   static_assert(is_destructible<_Value_type>::value,
+ "value type must be destructible");
 #else
   std::_Destroy_aux<__has_trivial_destructor(_Value_type)>::
__destroy(__first, __last);


This restores the original error: 'MovieData::~MovieData()' is private within
this context

[Bug target/120090] [16 Regression] gcc.target/i386/avx512bw-pr103750-2.c since r16-160

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120090

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
Fixed.

[Bug target/120090] [16 Regression] gcc.target/i386/avx512bw-pr103750-2.c since r16-160

2025-05-21 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120090

--- Comment #10 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r16-809-gf725d6765373f7884a2ea23bc11409b15545958b
Author: Andrew Pinski 
Date:   Mon May 5 09:46:14 2025 -0700

combine: gen_lowpart_no_emit vs CLOBBER [PR120090]

The problem here is simplify-rtx.cc expects gen_lowpart_no_emit
to return NULL on failure but combine's hook was returning CLOBBER.
After r16-160-ge6f89d78c1a7528e93458278,
gcc.target/i386/avx512bw-pr103750-2.c
started to fail at -m32 due to this as new simplify code would return
a RTL with a clobber in it rather than returning NULL.
To fix this gen_lowpart_no_emit should return NULL when there was an
failure
instead of a clobber. This only changes the gen_lowpart_no_emit hook and
not the
generic gen_lowpart hook as parts of combine just pass gen_lowpart result
directly
without checking the return value.

Bootstrapped and tested on x86_64-linux-gnu.

PR rtl-optimization/120090
gcc/ChangeLog:

* combine.cc (gen_lowpart_for_combine_no_emit): New function.
(RTL_HOOKS_GEN_LOWPART_NO_EMIT): Set to
gen_lowpart_for_combine_no_emit.

Signed-off-by: Andrew Pinski 

[Bug c++/120390] Request to improve error with private destructor

2025-05-21 Thread nightstrike at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390

--- Comment #1 from nightstrike  ---
(In reply to nightstrike from comment #0)
> either 1) I was missing private:,

"missing public:", obviously

[Bug c++/120390] New: Request to improve error with private destructor

2025-05-21 Thread nightstrike at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390

Bug ID: 120390
   Summary: Request to improve error with private destructor
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

I recently encountered this exact problem:

https://web.archive.org/web/20250521203035/https://stackoverflow.com/questions/67962227/static-assert-failed-because-value-type-is-destructible-for-stdvector

(which I conveniently saved to archive.org for whoever reads this in 20 years.)


Since that post is effectively the same as my own issue, I'm reposting that
(shortened) code instead of my own:

```
#include 

class MovieData {
MovieData(){}
~MovieData(){}
};

int main() {   
std::vector movies; // Line 16
return 0;
}
```

On old gcc 4.8.2, we get a loud but ultimately useful error output:

/usr/include/c++/4.8.2/bits/stl_construct.h: In instantiation of ‘void
std::_Destroy(_Tp*) [with _Tp = MovieData]’:
/usr/include/c++/4.8.2/bits/stl_construct.h:103:46:   required from ‘static
void std::_Destroy_aux< >::__destroy(_ForwardIterator,
_ForwardIterator) [with _ForwardIterator = MovieData*; bool  =
false]’
/usr/include/c++/4.8.2/bits/stl_construct.h:127:27:   required from ‘void
std::_Destroy(_ForwardIterator, _ForwardIterator) [with _ForwardIterator =
MovieData*]’
/usr/include/c++/4.8.2/bits/stl_construct.h:151:31:   required from ‘void
std::_Destroy(_ForwardIterator, _ForwardIterator, std::allocator<_T2>&) [with
_ForwardIterator = MovieData*; _Tp = MovieData]’
/usr/include/c++/4.8.2/bits/stl_vector.h:416:30:   required from
‘std::vector<_Tp, _Alloc>::~vector() [with _Tp = MovieData; _Alloc =
std::allocator]’
a.cc:9:29:   required from here
a.cc:5:10: error: ‘MovieData::~MovieData()’ is private
  ~MovieData(){}
  ^
In file included from /usr/include/c++/4.8.2/vector:62:0,
 from a.cc:1:
/usr/include/c++/4.8.2/bits/stl_construct.h:93:7: error: within this context
 { __pointer->~_Tp(); }
   ^


Specifically, "error: ‘MovieData::~MovieData()’ is private".  This is great! 
However, on 14.1, we get the more verbose and less helpful output:


In file included from /tmp/gcc-14.1-rh7/include/c++/14.1.0/vector:64,
 from a.cc:1:
/tmp/gcc-14.1-rh7/include/c++/14.1.0/bits/stl_construct.h: In instantiation of
'void std::_Destroy(_ForwardIterator, _ForwardIterator) [with _ForwardIterator
= MovieData*]':
/tmp/gcc-14.1-rh7/include/c++/14.1.0/bits/alloc_traits.h:944:20:   required
from 'void std::_Destroy(_ForwardIterator, _ForwardIterator, allocator<_T2>&)
[with _ForwardIterator = MovieData*; _Tp = MovieData]'
  944 |   std::_Destroy(__first, __last);
  |   ~^
/tmp/gcc-14.1-rh7/include/c++/14.1.0/bits/stl_vector.h:735:15:   required from
'std::vector<_Tp, _Alloc>::~vector() [with _Tp = MovieData; _Alloc =
std::allocator]'
  735 | std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish,
  | ~^
  736 |   _M_get_Tp_allocator());
  |   ~~
a.cc:9:29:   required from here
9 | std::vector movies; // Line 16
  |^~
/tmp/gcc-14.1-rh7/include/c++/14.1.0/bits/stl_construct.h:188:51: error: static
assertion failed: value type is destructible
  188 |   static_assert(is_destructible<_Value_type>::value,
  |   ^
/tmp/gcc-14.1-rh7/include/c++/14.1.0/bits/stl_construct.h:188:51: note:
'std::integral_constant::value' evaluates to false



There are a few things that made this difficult to track down.  Obviously, the
original message describing the core problem is gone -- that the destructor is
private.  Instead, it's replaced with "value type is destructible", which is
confusing.  At first glance, when I looked at the code, I thought "Of course
it's destructible, there's the destructor!"  And when I removed the destructor,
it compiled perfectly.  This was puzzling, and the error output sent me in
ambiguous circles.  Now, obviously, I should have recognized that either 1) I
was missing private:, or 2) I was using class, not struct, but I'm a flawed
human that makes mistakes.  It'd be awesome if the compiler could help me make
fewer of them :)

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

2025-05-21 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||acoplan at gcc dot gnu.org
Summary|[16 Regression] RISC-V: ICE |[15 16 Regression] RISC-V:
   |in vect pass "error:|ICE in vect pass "error:
   |definition in block 9 does  |definition in block 9 does
   |not dominate use in block   |not dominate use in block
   |3"  |3"

--- Comment #1 from Jeffrey A. Law  ---
Bisect lands on:

commit 68326d5d1a593dc0bf098c03aac25916168bc5a9 (HEAD)
Author: Alex Coplan 
Date:   Mon Mar 11 13:09:10 2024 +

vect: Force alignment peeling to vectorize more early break loops
[PR118211]

This allows us to vectorize more loops with early exits by forcing
peeling for alignment to make sure that we're guaranteed to be able to
safely read an entire vector iteration without crossing a page boundary.

To make this work for VLA architectures we have to allow compile-time
non-constant target alignments.  We also have to override the result of
the target's preferred_vector_alignment hook if it isn't a power-of-two
multiple of the TYPE_SIZE of the chosen vector type.
[ ... ]

[Bug c++/120318] Module deduced return type error.

2025-05-21 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120318

--- Comment #3 from Patrick Palka  ---
Probably not very useful but here's a mechanically reduced testcase (fixed by
r16-504):

$ cat std.ii
module;
   
16:56 [38/1494]
namespace std { 
template  auto declval() -> decltype(0);
template  void forward() {}   
template
concept convertible_to = requires { declval; }; 
template  
concept move_constructible = convertible_to<_Tp, _Tp>;   
namespace ranges {  
inline namespace _Cpo {}
} // namespace ranges   
namespace __detail {
template  using __iter_concept = _Iter;
}   
template
concept input_iterator = requires { typename __detail::__iter_concept<_Iter>;
};
namespace ranges {  
namespace _Cpo {
int end;
}   
template  
concept range = requires { end; };  
template  
concept input_range = input_iterator<_Tp>;  
template  
concept viewable_range = range<_Tp>;
} // namespace ranges   
struct vector {};   
namespace ranges {  
template   
concept __adaptor_invocable = requires { declval<_Adaptor>; };
template  struct _Partial;
template  
concept __is_range_adaptor_closure = requires(_Tp __t) { __t; };
template
  requires __is_range_adaptor_closure<_Self> && 
   __adaptor_invocable<_Self, _Range>   
constexpr auto operator|(_Range &&, _Self &&) {}
template  struct _RangeAdaptorClosure {
  template 
requires __is_range_adaptor_closure<_Self> &&
 __adaptor_invocable<_Self, _Range>
  friend constexpr auto operator|(_Range &&, _Self &&);
};  
struct _RangeAdaptor {  
  template  auto operator()(_Args...) {
return _Partial{0, forward<_Args>...};
  } 
};  
template 
struct _Partial<_Adaptor, _Arg> : _RangeAdaptorClosure<_Arg> {
  template  _Partial(int, _Tp) {}
};  
namespace views {   
_RangeAdaptorClosure all;
template  using all_t = decltype(all);
} // namespace views
template  class transform_view;
template 
transform_view() -> transform_view, _Fp>;
namespace views {   
namespace __detail {
template 
concept __can_transform_view = requires { transform_view(declval); };
} // namespace __detail 
struct _Transform : _RangeAdaptor {
  template 
requires __detail::__can_transform_view<_Range, _Fp>
  auto operator0(); 
} inline transform; 
} // namespace views
} // namespace ranges   
} // namespace std  
export module std;  
export namespace std {  
namespace ranges {  
namespace views {   
using views::transform; 
}   
} // namespace ranges   
using std::vector;  
} // namespace std  

$ cat 120318.C
import std; 
using std::vector;  
using std::ranges::views::transform;
int main(int argl,char**argv)
{   
vector v;   
v | transform([](int x){return x * x % 24;});
return 0;   
}

[Bug libstdc++/120387] constraint on expected's comparison operator causes infinite recursion, overload resolution fails

2025-05-21 Thread justend29 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387

--- Comment #4 from Justen Di Ruscio  ---
Pardon me for not seeing that this has been resolved. I'll also ensure to
expressly include the output of 'gcc -v', as opposed to mentioning the version,
even if the cause is provided. This is my first report.

[Bug libstdc++/120387] constraint on expected's comparison operator causes infinite recursion, overload resolution fails

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387

--- Comment #5 from Jonathan Wakely  ---
The instructions at https://gcc.gnu.org/bugs/ are very explicit about including
that information.

15.1.1 is not a release, it's any snapshot between the date of the 15.1.0
release and now, so is not enough to tell us what you're using. That's why we
ask for the 'gcc -v' output.

[Bug tree-optimization/120392] [12/13/14/15/16 REgression] ICE with VLA typedef and function splitting/eiline

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #10)
> 
> Note this is a GCC extension even.


For C++.

[Bug c++/120392] [12/13/14/15/16 REgression] ICE with VLA typedef and function splitting

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-22
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code

--- Comment #8 from Andrew Pinski  ---
.

[Bug tree-optimization/120392] [12/13/14/15/16 REgression] ICE with VLA typedef and function splitting

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #61491|0   |1
is obsolete||

--- Comment #9 from Andrew Pinski  ---
Created attachment 61492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61492&action=edit
Reduced slightly some more

This one also fails with the C front-end but in einline rather than fnsplit.
But both are the same issue.

[Bug tree-optimization/120392] [12/13/14/15/16 REgression] ICE with VLA typedef and function splitting

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |tree-optimization
 Blocks|16994   |
   Target Milestone|--- |12.5


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994
[Bug 16994] [meta-bug] VLA and C++

[Bug tree-optimization/120392] [12/13/14/15/16 REgression] ICE with VLA typedef and function splitting/eiline

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392

--- Comment #10 from Andrew Pinski  ---
The original code:
```
 typedef u16 TImage[][m_nBytesPerLine / sizeof (u16)];
```

Note this is a GCC extension even.

[Bug bootstrap/103459] Make configury regenerate cleanly with `autoreconf -Wall`

2025-05-21 Thread pietro at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103459

pietro  changed:

   What|Removed |Added

 CC||pietro at gcc dot gnu.org

--- Comment #4 from pietro  ---
Patch to fix some warnings:
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684459.html

[Bug c++/120379] [modules] dependency file generation causes ICE when two export module declarations are provided

2025-05-21 Thread nshead at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120379

Nathaniel Shead  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|[modules]   |[modules] dependency file
   |-fdeps-format=p1689r5   |generation causes ICE when
   |causes ICE when two export  |two export module
   |module declarations are |declarations are provided
   |provided|
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-05-21

--- Comment #1 from Nathaniel Shead  ---
Actually, just '-M' is enough.

[Bug cobol/119231] gcobol -static produces a dynamically linked executable

2025-05-21 Thread jklowden at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119231

James K. Lowden  changed:

   What|Removed |Added

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

[Bug cobol/119221] RFE: fix-it hints for cobol syntax errors

2025-05-21 Thread jklowden at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119221
Bug 119221 depends on bug 119256, which changed state.

Bug 119256 Summary: Capture source ranges for tokens in gcobol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119256

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

[Bug c/120382] ICE with hardbool attribute and undeclared variable

2025-05-21 Thread kaelfandrew at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120382

Kael Franco  changed:

   What|Removed |Added

 CC||kaelfandrew at gmail dot com

--- Comment #2 from Kael Franco  ---
This is a regression between 15.1 and 20250519 according to Godbolt.

[Bug cobol/119324] cppcheck meets /cobol/

2025-05-21 Thread dcb314 at hotmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324

--- Comment #7 from David Binderman  ---
(In reply to Robert Dubner from comment #6)
> I don't know what I am doing differently, or why I am seeing errors that
> you're not.

Instead of trying to duplicate my results, you could try just fixing the 
problems I reported.

[Bug c/120382] [14/15/16 Regression] ICE with hardbool attribute and undeclared variable

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120382

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.3
  Known to fail||14.2.0
  Known to work||13.3.0
Summary|ICE with hardbool attribute |[14/15/16 Regression] ICE
   |and undeclared variable |with hardbool attribute and
   ||undeclared variable

--- Comment #3 from Andrew Pinski  ---
(In reply to Kael Franco from comment #2)
> This is a regression between 15.1 and 20250519 according to Godbolt.

Not really:
:1: confused by earlier errors, bailing out

GCC 14 and 15 also ICEs but it is hidden due to previous error message and the
release compilers use --enable-checking=release while the trunk is compiled
with --enable-checking=yes.

If anything it is a regression from GCC 13.

[Bug c++/120377] ICE with fmtlib and modules

2025-05-21 Thread cjangus at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120377

--- Comment #3 from Cameron Angus  ---
Just updated to version 16.0.0 20250518 which just came through, but still
seeing the same ICE (error routines re-entered). So will have to wait for the
next one, or if I can work out how maybe I'll try to build from source, since
it seems that would be the best way to avoid wasting time on things that are
already fixed.

[Bug c++/120377] ICE with fmtlib and modules

2025-05-21 Thread nshead at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120377

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org

--- Comment #1 from Nathaniel Shead  ---
Thanks for the report!

(In reply to Cameron Angus from comment #0)
> I also created a reproduction on Compiler Explorer, though the precise ICE
> seems to be slightly different due to a difference in GCC and/or fmtlib
> version: https://godbolt.org/z/j1as93bvv

The godbolt is showing a different error due to the flags that CMake has added
for scanning dependencies; I've created PR120379 for this.  (It looks like
there might have been some accidental copy/pasting of module definitions into
the same file, perhaps?)

Your attached sources don't reproduce for me on my current build of trunk; on
GCC15 I get an "error reporting routines re-entered", so it looks like
something we've possibly already fixed for GCC16.

> I'd also like to ask, in future is logging a bug report with a Compiler
> Explorer reproduction only (no preprocessed sources) an option? I'm not a
> regular user of GCC or Linux systems so the process of recreating on CE is
> simpler for me if that is acceptable.

Having preprocessed sources makes it a lot easier for me, and I understand that
there's some concerns about making sure that bugzilla remains as a source of
truth for the issue even if say godbolt goes down or any of the other links
rot.  But if you can't do that I'd still prefer having a bug over nothing at
all :)

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

2025-05-21 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120341

--- Comment #4 from Zhendong Su  ---
Here is another very similar reproducer that only fails at -Os and seems to go
back to at least as early as 10.1. 

Compiler Explorer: https://godbolt.org/z/7e4jePnY7


[508] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250521 (experimental) (GCC) 
[509] % 
[509] % gcctk -Os small.c; ./a.out
[510] % 
[510] % gcctk -Os -fallow-store-data-races small.c
[511] % ./a.out
Segmentation fault
[512] % 
[512] % cat small.c
char a, *b;
int main() {
  while (a) {
b = "0";
b[0]++;
  }
  return 0;
}

[Bug c++/120385] [14/15/16 Regression] GCC 14 incorrectly accepts array prvalues with certain operators

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120385

--- Comment #1 from Andrew Pinski  ---
Is this still valid?
```
int main()
{
  using IA = int[];
  using IP = int*;
  void(+IP{IA{ 1, 2, 3 }});
}
```

Which makes this kinda of inconsistent after all.

[Bug libstdc++/120386] New: std::unique_copy uses the output type for comparisons

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120386

Bug ID: 120386
   Summary: std::unique_copy uses the output type for comparisons
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

struct X { X(int){} };

void uniq(const int* first, const int* last, X* out)
{
  std::unique_copy(first, last, out);
}

/usr/include/c++/14/bits/predefined_ops.h:117:23: error: no match for
‘operator==’ (operand types are ‘X’ and ‘const int’)
  117 |   { return *__it1 == *__it2; }
  |~~~^

When the output iterator has category std::forward_iterator_tag we choose an
implementation that compares the output value with the input value, even though
they might be different types.

The standard is clear (since C++98) that the comparisons should be on two
values from the input range:

  Copies only the first element from every consecutive group of equal elements
referred
  to by the iterator i in the range [first, last) for which the following
corresponding
  conditions hold: *i == *(i - 1) or pred(*i, *(i - 1)) != false

We seem to have done this wrong since the beginning of time (at least since
2001).

[Bug libstdc++/120386] std::unique_copy uses the output type for comparisons

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120386

Jonathan Wakely  changed:

   What|Removed |Added

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

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

2025-05-21 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118694

--- Comment #6 from Tobias Burnus  ---
> Are we required to diagnose this as an error
> or is it allowable to permit this as an extension?

Answer "no" and "yes" - but the problem is that in general it does not work.
(Potential wrong code issues, albeit as below only bad and not very bad.)

The problem is that for

  #pragma omp target
#pragma teams

on common offload hardware (like the AMD and Nvidia GPUs), the code is
not executed as:
- Start the offload kernel
- then, on the device start multiple teams

But:
- Start the offload kernel with several teams

Thus, it is impossible to add code between 'target' and 'teams'. For user code,
this is really very easy to generate wrong code in this case! And there is also
no directive that syncs multiple teams (contention groups) - except that once
the teams construct has finished, all teams have finished. Otherwise, only
thread synchronization in a single team (contention group works → cgroup ~
pteam).

* * *

In particular, if I execute your code and set the GOMP_DEBUG=1 env var, I see:

  GOMP_OFFLOAD_run: kernel f$_omp_fn$0: launch [(teams: 1), 1, 1] [(lanes: 32),
(threads: 8), 1]
  GOMP_OFFLOAD_run: kernel f$_omp_fn$0: launch [(teams: 1), 1, 1] [(lanes: 32),
(threads: 8), 1]


If I replace the condition by
when (user={condition(1)}: teams loop) \
the result is (twice):

  GOMP_OFFLOAD_run: kernel f$_omp_fn$0: launch [(teams: 60), 1, 1] [(lanes:
32), (threads: 8), 1]


Thus, the code runs with 60 teams while your code is run only with a single
team. This implies that the the runtime could be 60 faster, cutting it down
from 1 hour to 1 minute!

(It could be even a bit faster if memory access + caching improve, but
typically it is quite a bit less than 60×, but it should still be very
visible!)

* * *

BTW: I wonder why it doesn't work for

  constexpr int flag2 = 1;
...
when (user={condition(flag2)}: teams loop) \

shouldn't this be compile-time optimized (assuming C23 or a semi-new C++)?
I still see:

teams2.c:10:11: warning: ‘target’ construct with nested ‘teams’ construct
contains directives outside of the ‘teams’ construct [-Wopenmp]

and for the launch accordingly: "launch [(teams: 1),".


And, unsurprisingly, I also get the same for:

when (device={kind(nohost)}: teams loop) \

which is the case that we want to handle here.

[Bug middle-end/120378] Support narrowing clip idiom

2025-05-21 Thread liuhongt at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120378

--- Comment #1 from Hongtao Liu  ---

> The ifcvt'ed code before vect is:
> 
>   _4 = *_3;
>   x.0_12 = (unsigned int) _4;
>   _38 = -x.0_12;
>   _15 = (int) _38;
>   _16 = _15 >> 31;
>   _29 = x.0_12 > 255;
>   _17 = _29 ? _16 : _4;
>   _18 = (unsigned char) _17;
> 

For the testcase in PR, I think x.0_12 > 255 must be false since it's
zero_extend from unsigned char. So the comparison can be optimized off?

[Bug cobol/119332] cobol frontend does not support version dump options specified in --help

2025-05-21 Thread jklowden at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119332

James K. Lowden  changed:

   What|Removed |Added

 CC||jklowden at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rdubner at gcc dot 
gnu.org

--- Comment #2 from James K. Lowden  ---
$ gcobol -dumpmachine /dev/null
aarch64-unknown-linux-gnu
$ gcobol -dumpmachine 
gcobol: fatal error: no input files

Not sure this is right, either: 

gcobol -dumpversion /dev/null
16.0.0

[Bug c/120382] New: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in extended_tree, at tree.h:6562

2025-05-21 Thread xieym3 at zohomail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120382

Bug ID: 120382
   Summary: internal compiler error: tree check: expected class
'type', have 'exceptional' (error_mark) in
extended_tree, at tree.h:6562
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xieym3 at zohomail dot com
  Target Milestone: ---

$ cat file.c
typedef int __attribute__((hardbool(0, a))) B;
$ gcc -v
Using built-in specs.
COLLECT_GCC=/data/xieym/work-rgf/misc_tools/install/gcc-trunk/bin/gcc
COLLECT_LTO_WRAPPER=/data/xieym/work-rgf/misc_tools/install/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /data/xieym/work-rgf/misc_tools/src/gcc-trunk/configure
--enable-coverage --enable-checking --disable-multilib --disable-shared
--disable-bootstrap --enable-language=c,c++
--prefix=/data/xieym/work-rgf/misc_tools/install/gcc-trunk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250519 (experimental) (GCC)

$ gcc -c file.c -o /dev/null
:1:1: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in extended_tree, at tree.h:6562
1 | typedef int __attribute__((hardbool(0, a))) B;
  | ^~~
0x260c7a5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x262a516 internal_error(char const*, ...)
???:0
0x8fab53 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0xa0ea76 decl_attributes(tree_node**, tree_node*, int, tree_node*)
???:0
0xa307b9 start_decl(c_declarator*, c_declspecs*, bool, tree_node*, bool,
unsigned long*)
???:0
0xabbbee c_parse_file()
???:0
0xb3c959 c_common_parse_file()
???:0

Godbolt url: https://godbolt.org/z/5bnnPThWE

[Bug libstdc++/120367] [15/16 Regression] C++23 ranges::transform | ranges::to exception catching (segfault)

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120367

--- Comment #5 from Jonathan Wakely  ---
Reduced:

#include 

int main()
{
  struct X
  {
X(int) { throw 1; } // Cannot successfully construct an X.
~X() { VERIFY(false); } // So should never need to destroy one.
  };

  try
  {
int i[1]{};
std::vector v(std::from_range, i);
  }
  catch (int)
  {
  }
}

[Bug cobol/119329] cobol frontend does not support -Wall

2025-05-21 Thread jklowden at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119329

James K. Lowden  changed:

   What|Removed |Added

 CC||jklowden at gcc dot gnu.org
   Assignee|pinskia at gcc dot gnu.org |jklowden at gcc dot 
gnu.org

--- Comment #3 from James K. Lowden  ---
This may depend on 117009 but that, if necessary, is insufficient.  Warnings at
present are not enumerated to the framework, and so have no names to turn
on/off, or to elevate to errors. Those changes need to be done in the COBOL FE,
and that makes this PR my job.

[Bug libstdc++/120386] std::unique_copy uses the output type for comparisons

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120386

--- Comment #1 from Jonathan Wakely  ---
It looks like I've rediscovered https://cplusplus.github.io/LWG/issue2439 which
summarized (and fixed) the requirements that imply how this needs to work.

https://cplusplus.github.io/LWG/issue241 and
https://cplusplus.github.io/LWG/issue538 tried to state the requirements for
std::unique_copy, but failed to notice the same-type requirement.

[Bug tree-optimization/120383] New: Improving early break unrolled sequences with Adv. SIMD

2025-05-21 Thread tnfchris at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120383

Bug ID: 120383
   Summary: Improving early break unrolled sequences with Adv.
SIMD
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
Blocks: 53947, 115130
  Target Milestone: ---
Target: aarch64*

Today if we unroll an early break loop such as:

#define N 640
long long a[N] = {};
long long b[N] = {};

int f1 (long long c)
{
  for (int i = 0; i < N; i++)
{
  if (a[i] == c)
return 1;
}
  return 0;
}

we generate an ORR reduction followed by a compression sequence when using Adv.
SIMD.

ldp q31, q30, [x1], 32
cmeqv31.2d, v31.2d, v27.2d
cmeqv30.2d, v30.2d, v27.2d
orr v31.16b, v31.16b, v30.16b
umaxp   v31.4s, v31.4s, v31.4s
fmovx4, d31
cbz x4, .L2
fmovw1, s29

However the dependency chain here is long enough that it removes the vector
profitability.

This sequence can however be replaced by:

ldp q31, q30, [x0], 32
cmeqv31.2d, v31.2d, v29.2d
cmeqv30.2d, v30.2d, v29.2d
addhn   v31.2s, v31.2d, v30.2d
fmovx2, d31
cbz x2, .L15

with addhn replacing the ORR reduction and the UMAXP compression.

When using 3 compare statements, we can use nested addhn, when 4 we can create
2 ORRs + ADDHN.

The AArch64 ADDHN (Add and Halve Narrow) instruction performs an addition of
two vectors of the same size, then truncates (narrow) the result by keeping
only the higher half of each element.

This means that this is hard to do in RTL as you wouldn't be able to match this
long sequence with combine, and the intermediate combinations aren't valid. for
instance it's only possible when the vector mask values are 0 and -1 and so we
would need to know that the values in the registers are vector mask values.

An RTL folder won't work either as it won't let us get the nested variant.

Which leaves a gimple folder or support in the vectorizer for this.

By far the simplest version is using the vectorizer, as it knows about mask
type (e.g. VECTOR_BOOLEAN_P (..)) , it knows about the precision of the mask
type and it's the one generating the sequence so it can choose how to do the
reductions.

However for this to work we have to introduce an optab for addhn. Open coding
the sequence doesn't work as we don't have a way to describe that the addition
is done as a higher precision.

With the optab the final codegen can generate a scalar cbranch rather than a
vector one and gets the result we want.

This makes unrolling an early break loop much more profitable on AArch64.

Having looked into the options and describing the limitations above, are you ok
with a new optab
 for addhn Richi?


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 tree-optimization/120383] Improving early break unrolled sequences with Adv. SIMD

2025-05-21 Thread tnfchris at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120383

Tamar Christina  changed:

   What|Removed |Added

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

[Bug c++/120385] New: Incorrectly accepts array prvalues with certain operators

2025-05-21 Thread language.lawyer at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120385

Bug ID: 120385
   Summary: Incorrectly accepts array prvalues with certain
operators
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: language.lawyer at gmail dot com
  Target Milestone: ---

GCC 14 started accepting array prvalue operands where they are not allowed
(https://godbolt.org/z/6hj5YbTx7)

int main()
{
using IA = int[];

void(+IA{ 1, 2, 3 });
void(*IA{ 1, 2, 3 });
void(IA{ 1, 2, 3 } + 0);
void(IA{ 1, 2, 3 } - 0);
void(0 + IA{ 1, 2, 3 });
void(IA{ 1, 2, 3 } - IA{ 1, 2, 3 });
}

All of the void(...) lines shall make the program ill-formed

[Bug c++/120385] [14/15/16 Regression] Regression] GCC 14 incorrectly accepts array prvalues with certain operators

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120385

Andrew Pinski  changed:

   What|Removed |Added

Summary|[Regression] GCC 14 |[14/15/16 Regression]
   |incorrectly accepts array   |Regression] GCC 14
   |prvalues with certain   |incorrectly accepts array
   |operators   |prvalues with certain
   ||operators
   Target Milestone|--- |14.3

[Bug c/120380] New: internal compiler error: error reporting routines re-entered

2025-05-21 Thread xieym3 at zohomail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120380

Bug ID: 120380
   Summary: internal compiler error: error reporting routines
re-entered
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xieym3 at zohomail dot com
  Target Milestone: ---

$ cat file.c
struct pair_t {
  char c;
  __int128_t i;
} __attribute__((packed));
typedef struct unaligned_int128_t_ {
  struct unaligned_int128_t_ {
struct unaligned_int128_t_ {
  __int128_t value;
}
  }
} __attribute__((packed, may_alias)) unaligned_int128_t;
struct pair_t p = {0, 1};
unaligned_int128_t *addr = (unaligned_int128_t *)&p.i;
int main() {
  addr->value = 0;
  return 0;
}
$ gcc -v
Using built-in specs.
COLLECT_GCC=/data/xieym/work-rgf/misc_tools/install/gcc-trunk/bin/gcc
COLLECT_LTO_WRAPPER=/data/xieym/work-rgf/misc_tools/install/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /data/xieym/work-rgf/misc_tools/src/gcc-trunk/configure
--enable-coverage --enable-checking --disable-multilib --disable-shared
--disable-bootstrap --enable-language=c,c++
--prefix=/data/xieym/work-rgf/misc_tools/install/gcc-trunk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250519 (experimental) (GCC)

$ gcc -c file.c -o /dev/null
internal compiler error: error reporting routines re-entered.
0x260c68e diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x260c7a5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2628d71 warning(diagnostic_option_id, char const*, ...)
???:0
0xa0d188 build_type_attribute_qual_variant(tree_node*, tree_node*, int)
???:0
0x264dec3 pretty_printer::format(text_info&)
???:0
0x260c2e6 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x260c7a5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2629dff error_at(unsigned long, char const*, ...)
???:0
0xa56ae2 build_component_ref(unsigned long, tree_node*, tree_node*, unsigned
long, unsigned long, bool)
???:0
0xabbbee c_parse_file()
???:0
0xb3c959 c_common_parse_file()
???:0

Godbolt url: https://godbolt.org/z/9nMEo96as

[Bug middle-end/119600] HOST_WIDEST_FAST_INT should be used instead of long for BITMAP_WORD in bitmap.h

2025-05-21 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119600

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #3 from Segher Boessenkool  ---
(In reply to Andrew Pinski from comment #1)
> (In reply to Andrew Pinski from comment #0)
> > Looks like I missed this while I implemented PR 13987.
> 
> I missed it because I was changing HOST_WIDE_INT places and bitmap.h was
> changed to use long in r0-47360-g72e42e26cb760d which I assume to fix a
> similar compile time regression.

I did that because the bitmap stuff was very high in the overall profiles.  It
didn't have anything to do with a compile-time regression, at least not
directly.

[Bug target/120368] [16 Regression] wrong code with -O -fno-forward-propagate

2025-05-21 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120368

Jeffrey A. Law  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug cobol/119256] Capture source ranges for tokens in gcobol

2025-05-21 Thread jklowden at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119256

James K. Lowden  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||jklowden at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #3 from James K. Lowden  ---
The source range is indicated as designed.  The dot in 

PROGRAM-ID.

is specified as an optional part of the syntax.   

In the ISO spec under "8.3.5 Separators", it says: 

"3) The COBOL character period, when followed by a space, is a separator.
The separator period shall be used only to indicate the end of a sentence, or
as shown in formats."

This is a "shown in format" case.  

Granted, it's debatable whether or not "an optional part of the syntax" is part
of the error.  Variations in input will provoke slightly different messages. 
But the user is not confused, and the diagnostic is not malformed.

[Bug c++/120243] [15/16 Regression] Exception rethrown from coroutine promise type unhandled_exception not caught under -O1

2025-05-21 Thread iains at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243

--- Comment #6 from Iain Sandoe  ---
a slightly modified testcase (without the lambda, so the dumps are easier to
read)

#include 

struct coro {
 struct promise_type {
promise_type() = default;

std::suspend_never initial_suspend() const noexcept {
  __builtin_printf("initial_suspend\n");
  return {};
}
std::suspend_never final_suspend() const noexcept { return {}; }

void unhandled_exception() { 
  __builtin_printf("unhandled_exception\n");
  throw;
}

coro get_return_object() { return {}; }
void return_void() {}

};
};

coro
test ()
{
  __builtin_printf("test\n");
  throw "hello";
  __builtin_abort();
  co_return;
}

int main() {
   coro C;
try {
   C = test ();
}
catch(...) {
__builtin_printf("Caught!\n");
}
}

===

This fails for O2 and passes for O1
The first difference in the dumps is in fixup_cfg3 and the difference is that
the actor function gets inlined into the ramp.

-fnoinline restores function.  

GCC-14 does not seem to inline the same case.

.. next to figure out how the inlining is breaking the EH.

[Bug c/120381] [14/15/16 Regression] internal compiler error: in composite_type_internal, at c/c-typeck.cc:848

2025-05-21 Thread jsm28 at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120381

--- Comment #2 from Joseph S. Myers  ---
Nesting one definition of struct A inside another is never valid (and the
godbolt link shows the expected "nested redefinition" error that the PR doesn't
quote).

[Bug cobol/119335] cobol frontend ignores -M

2025-05-21 Thread jklowden at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119335

James K. Lowden  changed:

   What|Removed |Added

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

--- Comment #4 from James K. Lowden  ---
Marked as fixed until further notice.  The list produced by -M is taken from
the names recorded by processing COPY statements.  The same list is used to
prevent COPY recursion and to report filenames and line numbers for diagnostic
messages.  It should be right.  

We do not as of now attempt to report nesting; all copybooks used by X are
reported as dependencies of X.  If one copybook in that chain depends on
another, that fact is not evinced by the -M option.

[Bug libstdc++/120384] New: [12/13/14/15/16] _BinaryPredicateConcept checks in std::unique_copy are wrong

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120384

Bug ID: 120384
   Summary: [12/13/14/15/16] _BinaryPredicateConcept checks in
std::unique_copy are wrong
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#define _GLIBCXX_CONCEPT_CHECKS 1
#include 

void uniq(const int* first, const int* last, int* out)
{
  std::unique_copy(first, last, out);
}


This valid code fails to compile with:

/usr/include/c++/14/bits/predefined_ops.h:117:16: error: invalid type argument
of unary ‘*’ (have ‘int’)
  117 |   { return *__it1 == *__it2; }
  |^~
/usr/include/c++/14/bits/predefined_ops.h:117:26: error: invalid type argument
of unary ‘*’ (have ‘int’)
  117 |   { return *__it1 == *__it2; }
  |  ^~


This was broken by r0-125454-gea89b2482f97aa

[Bug libstdc++/120384] [12/13/14/15/16] _BinaryPredicateConcept checks in std::unique_copy are wrong

2025-05-21 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120384

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
  Known to fail||12.4.0, 13.3.0, 14.2.0,
   ||15.1.0, 16.0, 4.9.0
  Known to work||4.8.5
   Last reconfirmed||2025-05-21
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug c/120381] New: internal compiler error: in composite_type_internal, at c/c-typeck.cc:848

2025-05-21 Thread xieym3 at zohomail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120381

Bug ID: 120381
   Summary: internal compiler error: in composite_type_internal,
at c/c-typeck.cc:848
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xieym3 at zohomail dot com
  Target Milestone: ---

$ cat file.c
struct A {
  struct A {
struct A *p;
  } *p;
};
int foo(const struct A *q) { return q->p == q; }
void bar(int);
void baz() {
  struct A a;
  while (foo(&a))
bar(foo(&a));
}
$ gcc -v
Using built-in specs.
COLLECT_GCC=/data/xieym/work-rgf/misc_tools/install/gcc-trunk/bin/gcc
COLLECT_LTO_WRAPPER=/data/xieym/work-rgf/misc_tools/install/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /data/xieym/work-rgf/misc_tools/src/gcc-trunk/configure
--enable-coverage --enable-checking --disable-multilib --disable-shared
--disable-bootstrap --enable-language=c,c++
--prefix=/data/xieym/work-rgf/misc_tools/install/gcc-trunk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250519 (experimental) (GCC)

$ gcc -c file.c -o /dev/null
:6:22: internal compiler error: in composite_type_internal, at
c/c-typeck.cc:848
6 | int foo(const struct A *q) { return q->p == q; }
  |  ^
0x260c7a5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x262a516 internal_error(char const*, ...)
???:0
0x9f37e0 fancy_abort(char const*, int, char const*)
???:0
0xa53093 build_binary_op(unsigned long, tree_code, tree_node*, tree_node*,
bool)
???:0
0xa55496 parser_build_binary_op(unsigned long, tree_code, c_expr, c_expr)
???:0
0xabbbee c_parse_file()
???:0
0xb3c959 c_common_parse_file()
???:0

Godbolt url: https://godbolt.org/z/PKefohbPv

[Bug c/120381] internal compiler error: in composite_type_internal, at c/c-typeck.cc:848

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120381

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed, I don't know if this is valid or not but GCC should NOT ICE. It is a
front-end issue related to the struct tag rules in C23.

[Bug c/120381] [14/15/16 Regression] internal compiler error: in composite_type_internal, at c/c-typeck.cc:848

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120381

Andrew Pinski  changed:

   What|Removed |Added

Summary|internal compiler error: in |[14/15/16 Regression]
   |composite_type_internal, at |internal compiler error: in
   |c/c-typeck.cc:848   |composite_type_internal, at
   ||c/c-typeck.cc:848
   Target Milestone|--- |14.3

[Bug c/120382] ICE with hardbool attribute and undeclared variable

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120382

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug c/120380] [14/15/16 Regression] internal compiler error: error reporting routines re-entered

2025-05-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120380

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||13.3.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |14.3
   Last reconfirmed||2025-05-21
Summary|internal compiler error:|[14/15/16 Regression]
   |error reporting routines|internal compiler error:
   |re-entered  |error reporting routines
   ||re-entered

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

[Bug cobol/119336] cobol: missing copybooks break parser

2025-05-21 Thread jklowden at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119336

James K. Lowden  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |jklowden at gcc dot 
gnu.org
 Resolution|--- |WONTFIX
 CC||jklowden at gcc dot gnu.org

--- Comment #2 from James K. Lowden  ---
This is a comedy of errors, only partly fixable.  

When the COPY statement fails, lexing has moved to the next line.  The reported
error is correct.  But the source range for the caret is wrong on the 2nd
message because of the dance between the CDF parser, the lexer, and the main
parser.  It's not that the caret points to the wrong word ("DIVISION") in a
2-word token.  It's pointing to the column for the '.' on the previous line,
which was abandoned by the CDF is and is invalid in the main program ahead of
IDENTIFICATION DIVISION.  

What actually happens by design might be surprising.  We're using the CDF here
only to report errors.   

COPY processing happens in the file-reader (lexio) before the input stream is
directed to the lexer.  If lexio parses the COPY directive successfully (and
reads the file), the COPY directive is erased from the input, and the file's
text is inserted, bracketed by line-directives to keep the parser informed
about the filenames.  If lexio cannot parse the COPY directive or read the
file, it leaves the COPY directive intact, where it is parsed by the CDF
parser, which naturally reports syntax errors and missing-file problems.  

Errors at the very top of the program are at the very top of the LALR parser. 
Error recovery in Bison proceeds (usually) by discarding tokens that would fill
the current production, and moving "up a level".  If that level is the very
top, it quits.  

IMO that's just fine.  If the problem is the very top of the program, nothing
is gained by parsing, say, 400,000 lines filled with errors due to a missing
copybook.  Most programmers learn early to fix the first error first, and that
lesson is well applied here.

  1   2   >