[Bug c++/120363] New: internal compiler error: in tree_node, at cp/module.cc:9956
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120363 Bug ID: 120363 Summary: internal compiler error: in tree_node, at cp/module.cc:9956 Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc at acb dot anonaddy.me Target Milestone: --- I am trying to convert an existing C++ project to modules. It is mostly working fine however on gcc14 and gcc15 with cmake 4.0.1 and cmake 3.31.7 I am getting the following error: /workspaces/gw2cc_private_linux/src/gw2cc/algo/TSPSolver.ixx:6:8: internal compiler error: in tree_node, at cp/module.cc:9956 6 | export module gw2cc.algo:tsp_solver; |^~ 0x7f24d269f1c9 __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x7f24d269f28a __libc_start_main_impl ../csu/libc-start.c:360 Please submit a full bug report, with preprocessed source. I was able to narrow it down to files that use the GDCLASS macro here: https://github.com/godotengine/godot/blob/be3ecaeb3c51433058ad4e96ec892d18f4291efd/core/object/object.h#L415 Modules with a similar structure that do not use the macro work fine. I have attached the output of -freport-bug as instructed by the error message. For what its worth, MSVC has no issues compiling this. Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-linux-gnu/15.1.0/lto-wrapper Target: x86_64-linux-gnu Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu --disable-multilib --enable-languages=c,c++,fortran,go Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.1.0 (GCC)
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #11 from Robin Dapp --- > Yes. I am sure. And SPIKE and QEMU have no problem. So vlre/vsre should execute despite a VILL in VTYPE? At first sight I don't find any specifics in the vector spec. qemu is not very pedantic in that respect, I believe it didn't fault for vmv1r either. Never tried spike, though. That might be a question for Kito.
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #3 from Kito Cheng --- Sounds like PR117544?
[Bug testsuite/120365] New: Flag/skip torture testing in presence of explicit '-O'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120365 Bug ID: 120365 Summary: Flag/skip torture testing in presence of explicit '-O' Product: gcc Version: 16.0 Status: UNCONFIRMED Keywords: internal-improvement Severity: enhancement Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Occasionally during development I run into "non-sensical differences" when 'diff'ing DejaGnu '*.sum' files: for example, when I see a change for a test case's torture testing at '-O0', but expect to see anything only with optimizations enabled. Usually I then find a hard-coded '-O' in the test case 'dg-options' or similar. This means that torture testing effectively tests the same '-O' a number of times, which in addition to being confusing also is wasteful. We could add some linting for that (cross-referencing PR116163), or generally do something like commit r15-9015-g2cb728e14b5640849dad7571b9bbb0091ff5fcab "testsuite: Don't cycle through option list for gfortran.dg and libgomp.fortran dg-do run tests with -O in dg*options", for example.
[Bug c++/120366] New: __PRETTY_FUNCTION__ is sometimes an array of unknown bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120366
Bug ID: 120366
Summary: __PRETTY_FUNCTION__ is sometimes an array of unknown
bound
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Here's a reduced example of an issue we ran into:
using size_t = decltype(sizeof(0));
template
void accepts_bounded(char const(&)[N]) { }
void f() {
accepts_bounded(__PRETTY_FUNCTION__); // ok
[](auto){
accepts_bounded(__PRETTY_FUNCTION__); // ok
}(0);
}
template
void g(T) {
accepts_bounded(__PRETTY_FUNCTION__); // ok
[](auto){
accepts_bounded(__PRETTY_FUNCTION__); // error
}(0);
}
int main() {
accepts_bounded(__PRETTY_FUNCTION__); // ok
[]{
accepts_bounded(__PRETTY_FUNCTION__); // ok
}();
[](auto){
accepts_bounded(__PRETTY_FUNCTION__); // ok
}(0);
[](auto){
[](auto){
accepts_bounded(__PRETTY_FUNCTION__); // error
}(1);
}(0);
f();
g(2);
}
We expect __PRETTY_FUNCTION__ to be some char const[N]. And that seems to be
true... almost all the time. Except for a generic lambda that is inside of a
template, where __PRETTY_FUNCTION__ has type char const[] instead and so that
deduction fails.
[Bug cobol/119883] codegen: recursive user-defined functions don't run recursive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119883 James K. Lowden changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org CC||jklowden at gcc dot gnu.org Last reconfirmed||2025-05-20
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #13 from Li Pan --- Spec has two sentences about this: [1] These instructions are intended to be used to save and restore vector registers when the type or length of the current contents of the vector register is not known, or where modifying vl and vtype would be costly. [2] The instructions operate with an effective vector length, evl=NFIELDS*VLEN/EEW, regardless of current settings in vtype and vl. The usual property that no elements are written if vstart ≥ vl does not apply to these instructions. Instead, no elements are written if vstart ≥ evl. Does the second one indicates it will not be illegal no matter what vtype and vl are?
[Bug target/99912] Unnecessary / inefficient spilling of AVX2 ymm registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99912 Martin Jambor changed: What|Removed |Added CC||19373742 at buaa dot edu.cn --- Comment #13 from Martin Jambor --- *** Bug 110282 has been marked as a duplicate of this bug. ***
[Bug ipa/110282] [12/13/14/15 regression] Segmentation fault with specific optimizations since r10-3311-gff6686d2e5f797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282 Martin Jambor changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #22 from Martin Jambor --- (In reply to mcccs from comment #21) > Okay I'm so sorry for the misinterpretation. I thought DCE should never turn > an invalid program to a valid one because DCE is always an optimization and > optimizations should never modify the behavior of the programs. But since > you're the code owner and someone familiar with GCC internals your word is > worth 100 times my word so this can be closed. Your thinking about DCE, meaning the DCE pass, is actually the one that prevailed. But that is in fact why I was made to write the patch committed as r12-1848. It also adds a special DCE-like feature to IPA-SRA pass but it is there specifically for the pass to clean up after itself, not as a standalone optimization. Before that the pass did rely on the fact that when a parameter is used as a divisor or when it is dereferenced, but then the result is never used, DCE would take care of that operation and remove it. And so IPA-SRA was happy to keep such operations around even if they used uninitialized values from what remained of removed formal parameters of a function. Since it was decided that DCE can be switched off safely, IPA-SRA had to find all such operations it "created" and remove it - or rather not copy it the new clone - itself. The line you removed by sed is an initial part of that process. *** This bug has been marked as a duplicate of bug 99912 ***
[Bug ipa/110282] [12/13/14/15 regression] Segmentation fault with specific optimizations since r10-3311-gff6686d2e5f797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282 --- Comment #23 from Sam James --- Thanks Martin.
[Bug tree-optimization/111873] [12/13/14/15 regression] runtime Segmentation fault with '-O3 -fno-code-hoisting -fno-early-inlining -fno-tree-fre -fno-tree-pre' since r12-434-g93f8cb4965cebe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111873 --- Comment #19 from GCC Commits --- The releases/gcc-15 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:c1db46f7e51d4a546ca536f7f10e548f02e5cc12 commit r15-9717-gc1db46f7e51d4a546ca536f7f10e548f02e5cc12 Author: Martin Jambor Date: Wed May 14 12:08:24 2025 +0200 tree-sra: Do not create stores into const aggregates (PR111873) This patch fixes (hopefully the) one remaining place where gimple SRA was still creating a load into const aggregates. It occurs when there is a replacement for a load but that replacement is not type compatible - typically because it is a single field structure. I have used testcases from duplicates because the original test-case no longer reproduces for me. gcc/ChangeLog: 2025-05-13 Martin Jambor PR tree-optimization/111873 * tree-sra.cc (sra_modify_expr): When processing a load which has a type-incompatible replacement, do not store the contents of the replacement into the original aggregate when that aggregate is const. gcc/testsuite/ChangeLog: 2025-05-13 Martin Jambor * gcc.dg/ipa/pr120044-1.c: New test. * gcc.dg/ipa/pr120044-2.c: Likewise. * gcc.dg/tree-ssa/pr114864.c: Likewise. (cherry picked from commit 9d039eff453f777c58642ff16178c1ce2a4be6ab)
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 Kito Cheng changed: What|Removed |Added CC||andrew at sifive dot com --- Comment #12 from Kito Cheng --- Let us summon the RISC-V judge!!!
[Bug ipa/120295] [15/16 Regression] Wrong code on -O3 for trunk version (live code is wrongly eliminated) since r15-6294-g96fb71883d438b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120295 --- Comment #10 from Martin Jambor --- I have proposed a fix on the mailing list: https://inbox.sourceware.org/gcc-patches/ri6h61fwbp5@virgil.suse.cz/T/#u
[Bug c++/120366] __PRETTY_FUNCTION__ is sometimes an array of unknown bound inside double template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120366 Andrew Pinski changed: What|Removed |Added Summary|__PRETTY_FUNCTION__ is |__PRETTY_FUNCTION__ is |sometimes an array of |sometimes an array of |unknown bound |unknown bound inside double ||template Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-05-20 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86037 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/120360] Horrible code generation for trivial decrement with test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120360
--- Comment #2 from Linus Torvalds ---
Btw, for a similar - but different - comparison optimization failure case, we
had a discussion about our error pointer comparisons in the kernel.
We have this model where we return a pointer or error code in the same word,
with error pointers having values from -MAX_ERR to -1.
So we have a "IS_ERR_OR_NULL()" thing, which is the obvious thing and generates
testq %rdi, %rdi
je .L189
cmpq$-4096, %rdi
ja .L189
for gcc, and clang does this:
testq %rdi, %rdi
sete%al
cmpq$-4095, %rdi# imm = 0xF001
setae %cl
orb %al, %cl
je .LBB3_1
to avoid multiple conditional branches.
But for the case where we know it's a kernel pointer (which is always a
negative value on x86-64) we could just add MAX_ERR and check that it's now
positive. And by "add MAX_ERR", I mean "subtract -MAX_ERR and turn it into just
a comparison".
But I *cannot* get gcc to do that. I can get gcc to generate this:
addq$4095, %rdi
jns .L7
which looks superficially fine, but is actually quite bad because it generates
that extra result, which then results in more register pressure because you
need to keep the original pointer around, of course.
Why doesn't gcc know that an add with a compare and a dead result is the same
as subtract with the negative value, which can be written as "cmp"?
IOW, the code I *tried* to get gcc to generate was
cmpq$-4095, %rdi
jns .L7
but gcc just refuses to do that.
As with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095, I feel like there
should be an obvious peephole optimization where you go "oh, I can turn this
add-with-only-CC to just a cmp".
Stupid test-case:
/*
* Compile with -fwrapv, or cast to 'unsigned long' and then to 'long'
*/
#define MY_MAX_ERRNO 4095
#define MY_IS_ERR_OR_NULL(ptr) ((long)(ptr) + MY_MAX_ERRNO >= 0)
extern void do_something(void);
void failure(void *);
void failure(void *ptr)
{
if (MY_IS_ERR_OR_NULL(ptr)) do_something();
}
[Bug fortran/120099] [16 regression] gfortran.dg/specifics_1.f90 FAILs since r16-372-g064cac730f88dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #23 from anlauf at gcc dot gnu.org --- Fixed.
[Bug target/120360] Horrible code generation for trivial decrement with test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120360
--- Comment #3 from Linus Torvalds ---
(In reply to Linus Torvalds from comment #2)
>
> Stupid test-case:
Actually, that was a bit *too* stupid, since it doesn't show the effect of "we
still need the original value afterwards".
So change it to
void failure(void *ptr)
{
if (MY_IS_ERR_OR_NULL(ptr)) do_something(ptr);
}
to show why the 'add' is bad because it generates extra pointless register
pressure:
movq%rdi, %rax
addq$4095, %rax
jns .L4
(and obviously in this test-case that does nothing else, there is no other
register use, so the "register pressure" is a non-issue and it all just results
in one pointless "mov" instruction - but on real code it tends to result in
more spills and just odd code).
[Bug cobol/119885] libgcobol: SQRT wrong argument check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119885 Robert Dubner changed: What|Removed |Added Resolution|--- |FIXED CC||rdubner at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from Robert Dubner --- Fixed by changing if( value <= GCOB_FP128_LITERAL(0.0) ) to if( value < GCOB_FP128_LITERAL(0.0) )
[Bug cobol/119883] codegen: recursive user-defined functions don't run recursive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119883 Robert Dubner changed: What|Removed |Added Status|NEW |WAITING --- Comment #1 from Robert Dubner --- Simon, I don't understand why you think the function "foo" isn't running recursively. The GCC-16 version is behaving exactly as I would expect it to. And I don't believe it has changed since GCC-15. What do you think it should be doing?
[Bug cobol/119337] cobol: gcobc wrapper should deduce output name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119337 Robert Dubner changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED CC||rdubner at gcc dot gnu.org --- Comment #3 from Robert Dubner --- I am closing this on Jim Lowden's behalf.
[Bug target/120297] [15/16 Regression] RISC-V: Miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297 --- Comment #2 from Edwin Lu --- Created attachment 61477 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61477&action=edit user-config-O3-lto.s Here's the assembly file with -O3
[Bug target/120297] [15/16 Regression] RISC-V: Miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297 --- Comment #3 from Edwin Lu --- Created attachment 61478 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61478&action=edit user-config-O2-lto.s Here's the assembly with -O2
[Bug target/120368] [16 Regression] wrong code with -O -fno-forward-propagate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120368 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|target Target Milestone|--- |16.0
[Bug middle-end/120369] [15/16 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cplxlower0 only in version 15.1 and trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120369 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-05-20 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- z_1 = COMPLEX_EXPR <1.0e+0, 0.0>; = 1.0e+0;
[Bug middle-end/120369] [15/16 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cplxlower0 only in version 15.1 and trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120369 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.2
[Bug fortran/47803] [F95+] Constant inquiry function rejected in PARAMETER definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47803 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Known to work||10.5.0 --- Comment #8 from anlauf at gcc dot gnu.org --- All testcases in this PR work at least since 10.5.0. Therefore closing as FIXED.
[Bug middle-end/120369] [15/16 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cplxlower0 only in version 15.1 and trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120369 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Andrew Pinski --- I am almost positive this is caused by r15-1798-ga17ce10c97fa1d or r15-1797-gd8fe4f05ef448e . Let me look into it then.
[Bug middle-end/120369] [15/16 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cplxlower0 only in version 15.1 and trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120369 --- Comment #4 from Andrew Pinski --- I think I know the issue. it comes down to the LHS of __builtin_cabs is NULL.
[Bug cobol/119883] codegen: recursive user-defined functions don't run recursive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119883
James K. Lowden changed:
What|Removed |Added
Status|WAITING |NEW
Assignee|rdubner at gcc dot gnu.org |jklowden at gcc dot
gnu.org
--- Comment #2 from James K. Lowden ---
The issue appears to boil down to YYLTYPE and YDFLTYPE, which are identical,
being defined differently somehow, somewhere. A clue perhaps: in
gcc/cobol/util.cc, we have
void
cbl_field_t::report_invalid_initial_value(const YYLTYPE& loc) const
which appears to be the source of the complaint about the "type itself" in
warn_odr.
In the util.o, there are 4 definitions:
25d0 T cbl_field_t::report_invalid_initial_value(YYLTYPE const&)
const
2524 t cbl_field_t::report_invalid_initial_value(YYLTYPE const&)
const::{lambda(char)#2}::operator()(char) const
2548 t cbl_field_t::report_invalid_initial_value(YYLTYPE const&)
const::{lambda(char)#3}::operator()(char) const
24f0 t cbl_field_t::report_invalid_initial_value(YYLTYPE const&)
const::{lambda(char)#1}::operator()(char) const
I don't know what
const::{lambda(char)#1}::operator()(char)
refers to.
The sole call to this function is from parse.y:3755
$field->report_invalid_initial_value(@data_clauses);
[Bug rtl-optimization/120374] New: ext-dce fails to realize a shift pair makes bits dead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120374
Bug ID: 120374
Summary: ext-dce fails to realize a shift pair makes bits dead
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
ext-dce may fail to realize that a shift pair that ultimately produces a zero
extended bitfield actually kills all the annoying upper bits. As a result it
may fail to eliminate prior extensions. This can be seen as an extraneous zero
extension in the code below once the 2nd step of the RISC-V logical AND
revamping is installed. Compile with -O2 -march=rv64gcb.
union gimple_statement_d;
typedef union gimple_statement_d *gimple;
enum br_predictor
{
END_PREDICTORS
};
enum prediction
{
NOT_TAKEN,
TAKEN
};
struct gimple_statement_base {
unsigned int subcode : 16;
unsigned num_ops;
};
union gimple_statement_d {
struct gimple_statement_base gsbase;
};
static inline void
gimple_predict_set_predictor (gimple gs, enum br_predictor predictor)
{
gs->gsbase.subcode = (gs->gsbase.subcode & (1 << 15))
| (unsigned) predictor;
}
static inline void
gimple_predict_set_outcome (gimple gs, enum prediction outcome)
{
if (outcome == TAKEN)
gs->gsbase.subcode |= (1 << 15);
else
gs->gsbase.subcode &= ~(1 << 15);
}
gimple stmt;
gimple
gimple_build_predict (enum br_predictor predictor, enum prediction outcome)
{
gimple_predict_set_predictor (stmt, predictor);
gimple_predict_set_outcome (stmt, outcome);
return stmt;
}
The zext.h instruction is redundant because the shifts immediately thereafter
wipe all those bits.
lui a5,%hi(stmt)
ld a4,%lo(stmt)(a5)
li a3,-32768
li a2,1
lhu a5,0(a4)
and a5,a5,a3
or a0,a0,a5
zext.h a0,a0
sllia5,a0,49
srlia5,a5,49
bne a1,a2,.L3
or a5,a0,a3
[Bug rtl-optimization/120374] ext-dce fails to realize a shift pair makes bits dead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120374 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 Keywords||missed-optimization
[Bug middle-end/120369] [15/16 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cplxlower0 only in version 15.1 and trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120369 --- Comment #6 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684319.html
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #5 from David Binderman --- cppcheck says a lot of things that are true but not useful. I use the following grep command to find the more interesting material: grep -E "performance:| error:| warning:| style:" filename
[Bug c++/120273] [15/16 regression] ICE when building corral since r15-3148-g6303cd7e41546e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2025-05-20 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #8 from Iain Sandoe --- hmm we should not be trying to outline coroutine components with dependent types... The coroutine outlining is gated thus: if (flag_coroutines && !processing_template_decl ... so, indeed, something has probably become corrupted.
[Bug middle-end/118994] GCC fails to optimize (a >> 1) + (b >> 1) + ((a | b) & 1) to PAVGB/PAVGW (or equivalent instruction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994 --- Comment #8 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:72f0b446d2c03866ebe4cae125e32fef598e924d commit r16-767-g72f0b446d2c03866ebe4cae125e32fef598e924d Author: liuhongt Date: Tue Feb 25 22:48:27 2025 -0800 Add pattern match in match.pd for .AVG_CEIL 1) Optimize (a >> 1) + (b >> 1) + ((a | b) & 1) to .AVG_CEIL (a, b) 2) Optimize (a | b) - ((a ^ b) >> 1) to .AVG_CEIL (a, b) gcc/ChangeLog: PR middle-end/118994 * match.pd ((a >> 1) + (b >> 1) + ((a | b) & 1) to .AVG_CEIL (a, b)): New pattern. ((a | b) - ((a ^ b) >> 1) to .AVG_CEIL (a, b)): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr118994-1.c: New test. * gcc.target/i386/pr118994-2.c: New test.
[Bug middle-end/118994] GCC fails to optimize (a >> 1) + (b >> 1) + ((a | b) & 1) to PAVGB/PAVGW (or equivalent instruction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994 Hongtao Liu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Known to work||16.0 --- Comment #9 from Hongtao Liu --- Fixed in GCC16
[Bug cobol/119883] codegen: recursive user-defined functions don't run recursive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119883
--- Comment #3 from Robert Dubner ---
(In reply to James K. Lowden from comment #2)
> The issue appears to boil down to YYLTYPE and YDFLTYPE, which are identical,
> being defined differently somehow, somewhere. A clue perhaps: in
> gcc/cobol/util.cc, we have
>
> void
> cbl_field_t::report_invalid_initial_value(const YYLTYPE& loc) const
>
> which appears to be the source of the complaint about the "type itself" in
> warn_odr.
>
> In the util.o, there are 4 definitions:
>
> 25d0 T cbl_field_t::report_invalid_initial_value(YYLTYPE const&)
> const
> 2524 t cbl_field_t::report_invalid_initial_value(YYLTYPE const&)
> const::{lambda(char)#2}::operator()(char) const
> 2548 t cbl_field_t::report_invalid_initial_value(YYLTYPE const&)
> const::{lambda(char)#3}::operator()(char) const
> 24f0 t cbl_field_t::report_invalid_initial_value(YYLTYPE const&)
> const::{lambda(char)#1}::operator()(char) const
>
> I don't know what
>
> const::{lambda(char)#1}::operator()(char)
>
> refers to.
>
> The sole call to this function is from parse.y:3755
>
> $field->report_invalid_initial_value(@data_clauses);
Jim, you put this comment into the wrong PR.
[Bug c++/120373] New: operator overloads inside extern "C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120373
Bug ID: 120373
Summary: operator overloads inside extern "C"
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
struct f{};
extern "C"
{
void operator << (struct f, struct f)
{}
bool operator == (struct f, struct f)
{}
bool operator ++ (struct f, int)
{}
}
```
This really does not make sense.
operator<< is named _Zls, operator==: _Zeq and operator++: _Zpp
None of those make sense at all.
[Bug libstdc++/120367] [15/16 Regression] C++23 ranges::transform | ranges::to exception catching (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120367 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- GCC 14 preprocessed sources compile/run fine with GCC 15/trunk, suggesting a library change is the cause. Maybe the vector(from_range_t) constructor additions?
[Bug middle-end/118694] OpenMP: target/metadirective/teams directive nesting gives error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118694 --- Comment #5 from sandra at gcc dot gnu.org --- Created attachment 61485 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61485&action=edit test case metadirective-1a.c with dynamic selector Hmmm, interesting. I temporarily #ifdef'ed out the code that generates the bogus error. Not only does the libgomp metadirective-1.c test seem to run correctly, this similar test case with a dynamic selector (that implicitly inserts code to test the condition between the #pragma omp target and #pragma omp teams) works too. Are we required to diagnose this as an error or is it allowable to permit this as an extension? Diagnosing it would be rough; in general it can't happen until late resolution, and as I found previously, the optimizers that run before then can rewrite the code in all sorts of ways that make it hard to map it back onto its original structure. I'm thinking doing the check for correct target(?)/metadirective(?)/teams nesting either in the front ends or during gimplification, when we still have it in tree structure as close as possible to what the user wrote, would be better than omp-low, when gimplification has already messed with it.
[Bug c++/120363] internal compiler error: in tree_node, at cp/module.cc:9956
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120363
Nathaniel Shead changed:
What|Removed |Added
Last reconfirmed||2025-05-21
Ever confirmed|0 |1
CC||nshead at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot
gnu.org
--- Comment #2 from Nathaniel Shead ---
Confirmed. Reduced:
export module M;
struct S {
static thread_local int thread_singleton;
inline static int& get_singleton() { return thread_singleton; }
};
We're not setting DECL_CONTEXT on the TLS init func.
[Bug target/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #14 from Andrew Waterman --- > Let us summon the RISC-V judge!!! The key is that vtype.vill affects only those instructions that depend on vtype. vlr and vsr do not depend on vtype and so are unaffected by vtype.vill. > vmv1r also doesn't depend on a specific vtype This actually isn't the case: unlike vlr and vsr, the vmvr instructions' vstart settings are SEW-specific, and so they have a vtype dependence. This is arguably a flaw in the ISA, but the fact is that the moves are more restricted than the loads and stores. > I mean I wouldn't mind not fixing this if it's indeed a hardware issue but > e.g. the Banana Pi is widespread and it might look unfortunate if we just > SIGILL for a preventable reason. It does seem like a hardware bug, but I'm sympathetic to this point of view, assuming we aren't giving anything up by working around it.
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324
--- Comment #4 from Robert Dubner ---
I fear that my ignorance is holed up in a bit of a fortress.
I have installed Cppcheck 2.7 on an Ubuntu 22.04 LTS x86_64 system.
When I try to run it on just one file that you mention, I get the following. I
haven't a clue how to interpret it, or to make it more meaningful. Part of my
problem is that the cppcheck documentation indicates that things known as
"configurations" are of major importance, without giving me anything like a
clue what a "configuration" is.
$ cppcheck genapi.cc --force --enable=all
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...
cbldiag.h:82:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
void error_msg( const YYLTYPE& loc, const char gmsgid[], ... );
^
cbldiag.h:84:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
void dialect_error( const YYLTYPE& loc, const char term[], const char dialect[]
);
^
cbldiag.h:93:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
void cbl_unimplemented_at( const YYLTYPE& loc, const char *gmsgid, ... );
^
cbldiag.h:102:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
void gcc_location_set( const YYLTYPE& loc );
^
symbols.h:156:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
const char * consistent_encoding_check( const YYLTYPE& loc, const char input[]
);
^
symbols.h:167:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
cbl_domain_elem_t( const YYLTYPE& loc,
^
symbols.h:187:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
cbl_domain_t( const YYLTYPE& loc,
^
symbols.h:575:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
void report_invalid_initial_value(const YYLTYPE& loc) const;
^
symbols.h:654:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
YYLTYPE loc;
^
symbols.h:672:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
cbl_refer_t( const YYLTYPE& loc, cbl_field_t *field, bool all = false )
^
symbols.h:1371:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
YYLTYPE loc;
^
symbols.h:1387:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
cbl_alphabet_t(const YYLTYPE& loc, cbl_encoding_t enc)
^
symbols.h:1398:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
cbl_alphabet_t( const YYLTYPE& loc, const cbl_name_t name,
^
symbols.h:1419:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you want to check it. You can use -U to skip it explicitly.
[ConfigurationNotChecked]
add_sequence( const YYLTYPE& loc, const unsigned char seq[] ) {
^
symbols.h:1430:0: information: Skipping configuration
'YYLTYPE;YYLTYPE_IS_DECLARED' since the value of 'YYLTYPE' is unknown. Use -D
if you wan
[Bug c++/120273] [15/16 regression] ICE when building corral since r15-3148-g6303cd7e41546e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273 --- Comment #7 from Sam James --- ``` [...] ==838291== Invalid read of size 1 ==838291==at 0x8EB7F10: __strcmp_avx2 (strcmp-avx2.S:249) ==838291==by 0x5EF52CE: UnknownInlinedFun (splay-tree.c:151) ==838291==by 0x5EF52CE: UnknownInlinedFun (splay-tree.c:467) ==838291==by 0x5EF52CE: get_fileinfo(char const*) (c-lex.cc:112) ==838291==by 0x6163E9B: UnknownInlinedFun (lex.cc:1139) ==838291==by 0x6163E9B: make_class_type(tree_code) (lex.cc:1161) ==838291==by 0x6424ED3: lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int) [clone .constprop.1] (pt.cc:10413) ==838291==by 0x643B2EA: tsubst(tree_node*, tree_node*, int, tree_node*) (pt.cc:16555) ==838291==by 0x5345E0A: tsubst_parameter_mapping(tree_node*, tree_node*, subst_info) [clone .isra.0] (constraint.cc:1805) ==838291==by 0x535BB79: UnknownInlinedFun (constraint.cc:2395) ==838291==by 0x535BB79: satisfy_constraint_r(tree_node*, tree_node*, sat_info) (constraint.cc:2495) ==838291==by 0x535C574: satisfy_normalized_constraints(tree_node*, tree_node*, sat_info) (constraint.cc:2520) ==838291==by 0x535C8F7: UnknownInlinedFun (constraint.cc:2742) ==838291==by 0x535C8F7: constraint_satisfaction_value(tree_node*, tree_node*, sat_info) [clone .lto_priv.0] (constraint.cc:2763) ==838291==by 0x4827F5E: constraints_satisfied_p(tree_node*, tree_node*) [clone .part.0] (constraint.cc:2800) ==838291==by 0x4AA5440: UnknownInlinedFun (tree.h:3692) ==838291==by 0x4AA5440: fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool, bool) [clone .cold] (pt.cc:23272) ==838291==by 0x66E560F: add_template_candidate_real(z_candidate**, tree_node*, tree_node*, tree_node*, tree_node*, vec const*, tree_node*, tree_node*, tree_node*, int, tree_node*, unification_kind_t, bool, int) [clone .isra.0] (call.cc:3723) ==838291== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==838291== in pp_string, at pretty-print.cc:2654 [...] ```
[Bug c/80400] missing -Wattributes on a invalid attribute packed on a typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80400
Campbell changed:
What|Removed |Added
CC||rlcamp.pdx at gmail dot com
--- Comment #4 from Campbell ---
I hit this today in gcc 14.2.1, on
__attribute((packed)) struct ConfigDescriptor {
uint8_t bLength;
uint8_t bDescriptorType;
uint16_t wTotalLength;
uint8_t bNumInterfaces;
uint8_t bConfigurationValue;
uint8_t iConfiguration;
uint8_t bmAttributes;
uint8_t bMaxPower;
};
This was a particularly nefarious one to debug, as the kernel only validates
the lack of packing on this descriptor when plugged in through a USB hub, and
not directly, so the incorrect code was able to persist in production for
years...
[Bug middle-end/120372] canonicalize_comparison uses gen_move_insn to calcualate the cost of the constant formation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120372 --- Comment #3 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684328.html https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684329.html (with extra comments added compared to the patch attached here and split into 2).
[Bug libstdc++/120367] [15/16 Regression] C++23 ranges::transform | ranges::to exception catching (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120367 Richard Biener changed: What|Removed |Added Last reconfirmed||2025-05-21 Ever confirmed|0 |1 Priority|P3 |P2 Status|UNCONFIRMED |NEW
[Bug middle-end/120369] [15/16 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cplxlower0 only in version 15.1 and trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120369 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug fortran/120371] [15.1 regression] erroneously triggered error message on non-matching interfaces with flag -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120371 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.2 Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener --- Duplicate. *** This bug has been marked as a duplicate of bug 119928 ***
[Bug fortran/119928] [15/16 Regression] Bogus "Interface mismatch" in gfortran.dg/proc_ptr_52.f90 with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119928 Richard Biener changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #6 from Richard Biener --- *** Bug 120371 has been marked as a duplicate of this bug. ***
[Bug middle-end/120369] [15 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cplxlower0 only in version 15.1 and trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120369 Andrew Pinski changed: What|Removed |Added Known to work||14.1.0, 14.2.0 Summary|[15/16 Regression] internal |[15 Regression] internal |compiler error: |compiler error: |Segmentation fault during |Segmentation fault during |GIMPLE pass: cplxlower0 |GIMPLE pass: cplxlower0 |only in version 15.1 and|only in version 15.1 and |trunk |trunk Known to fail||15.1.0 --- Comment #8 from Andrew Pinski --- Fixed on the trunk so far. Will backport next week or so.
[Bug middle-end/120369] [15/16 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cplxlower0 only in version 15.1 and trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120369 --- Comment #7 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:95c74f354ae3186e84fbada22d2e7f3845dbb659 commit r16-769-g95c74f354ae3186e84fbada22d2e7f3845dbb659 Author: Andrew Pinski Date: Tue May 20 13:21:28 2025 -0700 middle-end: Fix complex lowering of cabs with no LHS [PR120369] This was introduced by r15-1797-gd8fe4f05ef448e . I had missed that the LHS of the cabs call could be NULL. This seems to only happen at -O0, I tried to produce one that happens at -O1 but needed many different options to prevent the removal of the call. Anyways the fix is just keep around the call if the LHS is null. Bootstrapped and tested on x86_64-linux-gnu. PR middle-end/120369 gcc/ChangeLog: * tree-complex.cc (gimple_expand_builtin_cabs): Return early if the LHS of cabs is null. gcc/testsuite/ChangeLog: * gcc.dg/torture/pr120369-1.c: New test. Signed-off-by: Andrew Pinski
[Bug cobol/119636] compile error: gcobol1 does not find file descriptions in case of obsolete FD phrases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119636 --- Comment #4 from Simon Sobisch --- Please reopen as this is not about doing anything with the obsolete code in any way, but ignoring = "parse in the water". The main issue is that the FD is not recognized any more, and yes, there are a lot of existing code bases (MF and others raise a warning "ignored", if you enable those warnings) that have "VALUE OF" and "LABEL RECORDS" in, some also that include "DATA RECORDS". The important stuff is still recognised correctly with other compilers: 003300 DATA DIVISION. 003400 FILE SECTION. 003500 FD TFIL. 004800 01 FREC. 004900 03 RKEY PIC X(8). while gcobol 15.1 complains about the missing FD definition for TFIL.
[Bug ipa/110282] [12/13/14/15 regression] Segmentation fault with specific optimizations since r10-3311-gff6686d2e5f797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282 --- Comment #21 from mcccs at gmx dot com --- Okay I'm so sorry for the misinterpretation. I thought DCE should never turn an invalid program to a valid one because DCE is always an optimization and optimizations should never modify the behavior of the programs. But since you're the code owner and someone familiar with GCC internals your word is worth 100 times my word so this can be closed.
[Bug libstdc++/120364] New: std::bitset is missing hardened preconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120364 Bug ID: 120364 Summary: std::bitset is missing hardened preconditions Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 110339 Target Milestone: --- constexpr bool operator[](size_t pos) const; Hardened preconditions: pos < size() is true. constexpr bitset::reference operator[](size_t pos); Hardened preconditions: pos < size() is true. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339 [Bug 110339] Implement C++26 library features
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #7 from Li Pan --- Does it possible that the board has set such insn to illegal insn by mistake? The qemu and spike doesn't report any illegal insn. I will go thru the spec for more details. Ideally, the vl1re32.v has the vtype info already.
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #8 from JuzheZhong ---
(In reply to Robin Dapp from comment #6)
> (In reply to Kito Cheng from comment #5)
> > Oh, vsetvli/vill issue should only appeared for whole reg move not whole reg
> > load store
>
> On the Banana Pi I get a SIGILL for
>
> int
> main() {
> asm volatile ("lui a5, 0xdd\n\t"
> "add a5, a5, 904\n\t"
> "vl1re32.v v1,(a5)\n\t"
> :
> :
> :);
>
> return 0;
> }
>
> but a SIGSEGV (which is OK) for
>
> int
> main() {
> asm volatile ("lui a5, 0xdd\n\t"
> "add a5, a5, 904\n\t"
> "vsetivlizero,8,e32,m1,ta,ma\n\t"
> "vl1re32.v v1,(a5)\n\t"
> :
> :
> :);
>
> return 0;
> }
>
> So looks like we also need a vtype for the loads and stores?
No. vlre should not depend on vtype. It should be hardware bug.
[Bug ipa/120345] array subscript is partly outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120345 --- Comment #3 from Orgad Shaneh --- Looks right. See analysis in https://github.com/scummvm/scummvm/pull/6620#issuecomment-2886321894
[Bug c/120362] New: [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
Bug ID: 120362
Summary: [GCC-15.1] Illegal Insn when run spec2017 511 ref size
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pan2.li at intel dot com
Target Milestone: ---
There will be an illegal insn when run spec17 511 with below command:
runcpu -c gcc-15-rvv_fix.cfg --action=validate --size=ref --noreportable
--iterations=1 --tune=base --copies=1 511
compile option are: "-O3 -march=rv64gcvb_zvl256b -mrvv-vector-bits=zvl"
[89405.212442] CPU: 0 PID: 5724 Comm: povray_r_base.g Not tainted 6.6.36
#2.0~rc7.2
[89405.219881] CPU: 7 PID: 5725 Comm: povray_r_base.g Not tainted 6.6.36
#2.0~rc7.2
[89405.225214] Hardware name: spacemit k1-x deb1 board (DT)
[89405.232480] Hardware name: spacemit k1-x deb1 board (DT)
[89405.239748] epc : 000b29e8 ra : 000b2a30 sp :
003fda481eb0
[89405.247023] epc : 000b29e8 ra : 000b2a30 sp :
003fdb576eb0
[89405.254308] gp : 00101240 tp : 003fbce47dc0 t0 :
003fbd2302a0
[89405.261574] gp : 00101240 tp : 003fb85d6dc0 t0 :
003fb89bf2a0
[89405.268840] t1 : 003fbce6f4ac t2 : 0006 s0 :
00101788
[89405.276088] t1 : 003fb85fe4ac t2 : 0006 s0 :
00101788
[89405.283354] s1 : 003fda482218 a0 : 00101788 a1 :
003fda482218
[89405.290602] s1 : 003fdb577218 a0 : 00101788 a1 :
003fdb577218
[89405.297867] a2 : 003fda482230 a3 : a4 :
003fda4820b0
[89405.303223] a2 : 003fdb577230 a3 : a4 :
003fdb5770b0
[89405.311183] a5 : 000dd388 a6 : a7 :
003fbcf85040
[89405.322831] a5 : 000dd388 a6 : a7 :
003fb8714040
[89405.330280] s2 : 0002 s3 : 000f8d10 s4 :
00012c2e
[89405.335636] s2 : 0002 s3 : 000f8d10 s4 :
00012c2e
[89405.342911] s5 : 003fda482230 s6 : 000f8d10 s7 :
003fbd22ed68
[89405.350200] s5 : 003fdb577230 s6 : 000f8d10 s7 :
003fb89bdd68
[89405.357485] s8 : 003fbd22f030 s9 : s10:
002ab7befed8
[89405.364754] s8 : 003fb89be030 s9 : s10:
002ae6fc0ed8
[89405.372029] s11: 002ab7befee4 t3 : 003fbd21e922 t4 :
0003642e
[89405.379298] s11: 002ae6fc0ee4 t3 : 003fb89ad922 t4 :
0003642e
[89405.386574] t5 : 2b43e9ed t6 : 00ad0fa7
[89405.393843] t5 : 2b43e9ed t6 : 00ad0fa7
[89405.401108] status: 80026020 badaddr: 0287e087 cause:
0002
[89405.408377] status: 80026020 badaddr: 0287e087 cause:
0002
The illegal insn comes from POVMSStream_Init @ 0xb29e8 with below asm, take
simple vsetvel still have this issue but disable zvl will not have vl1re32 insn
and can fix this illegal insn.
000b29e0 <_Z16POVMSStream_Initv>:
b29e0: 000dd7b7lui a5,0xdd
b29e4: 38878793add a5,a5,904 # dd388
<_ZTVN8pov_base7OStreamE+0x30>
b29e8: 0287e087vl1re32.v v1,(a5)
b29ec: cd047057vsetivlizero,8,e32,m1,ta,ma
b29f0: 0012f7b7lui a5,0x12f
b29f4: 0d078793add a5,a5,208 # 12f0d0
b29f8: 5208a157vid.v v2
One simple inline asm can also reproduce this issue too.
nt
main() {
asm volatile ("lui a5, 0xdd\n\t"
"add a5, a5, 904\n\t"
"vl1re32.v v1,(a5)\n\t"
:
:
:);
return 0;
}
I am trying to narrow down the POVMSStream_Init for easy debugging, and will
keep posted.
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #1 from Robin Dapp --- That's a misaligned vector load I suppose?
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #2 from Li Pan --- (In reply to Robin Dapp from comment #1) > That's a misaligned vector load I suppose? I see, but when I changed to addia5,a5,912 aka load from 0xdd390, the board still has the illegal insn. 0xdd390 is aligned for -O2 -march=rv64gcv -mrvv-vector-bits=zvl build, right?
[Bug fortran/120355] [15/16 Regression] Type mismatch for passed external function, if external function appears in the same source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120355 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- I am AFK this week, will look at this next week. Thanks for the workaround, Harald, this makes it quite clear what is going on.
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #9 from Robin Dapp --- > No. vlre should not depend on vtype. It should be hardware bug. Are you sure about that? vmv1r also doesn't depend on a specific vtype, each one is OK, but the vtype must at least be valid. So we get a SIGILL for an invalid vtype (i.e. when clobbered by a syscall). I mean I wouldn't mind not fixing this if it's indeed a hardware issue but e.g. the Banana Pi is widespread and it might look unfortunate if we just SIGILL for a preventable reason.
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #10 from JuzheZhong --- (In reply to Robin Dapp from comment #9) > > No. vlre should not depend on vtype. It should be hardware bug. > > Are you sure about that? vmv1r also doesn't depend on a specific vtype, > each one is OK, but the vtype must at least be valid. So we get a SIGILL > for an invalid vtype (i.e. when clobbered by a syscall). > > I mean I wouldn't mind not fixing this if it's indeed a hardware issue but > e.g. the Banana Pi is widespread and it might look unfortunate if we just > SIGILL for a preventable reason. Yes. I am sure. And SPIKE and QEMU have no problem.
[Bug c++/120363] internal compiler error: in tree_node, at cp/module.cc:9956
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120363 --- Comment #1 from ACB --- Created attachment 61476 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61476&action=edit freport-bug
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #6 from Robin Dapp ---
(In reply to Kito Cheng from comment #5)
> Oh, vsetvli/vill issue should only appeared for whole reg move not whole reg
> load store
On the Banana Pi I get a SIGILL for
int
main() {
asm volatile ("lui a5, 0xdd\n\t"
"add a5, a5, 904\n\t"
"vl1re32.v v1,(a5)\n\t"
:
:
:);
return 0;
}
but a SIGSEGV (which is OK) for
int
main() {
asm volatile ("lui a5, 0xdd\n\t"
"add a5, a5, 904\n\t"
"vsetivlizero,8,e32,m1,ta,ma\n\t"
"vl1re32.v v1,(a5)\n\t"
:
:
:);
return 0;
}
So looks like we also need a vtype for the loads and stores?
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #5 from Kito Cheng --- Oh, vsetvli/vill issue should only appeared for whole reg move not whole reg load store
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #4 from Robin Dapp --- > I see, but when I changed to > > addia5,a5,912 > > aka load from 0xdd390, the board still has the illegal insn. 0xdd390 is > aligned for -O2 -march=rv64gcv -mrvv-vector-bits=zvl build, right? Hmm, right, I was mistaken. The original one (904) also is not element misaligned (for 32-bit = 4 byte elements). So no alignment issue. Is it a vsetvl problem? We added vsetvl handling for full-register moves, do we also need it for full-register loads and stores?
[Bug tree-optimization/119835] GCN, nvptx offloading: 'libgomp.c++/pr106445-1.C' with '-fno-inline': ICE 'during GIMPLE pass: nrv'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119835
Thomas Schwinge changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
CC||rguenth at gcc dot gnu.org
Keywords||openacc
Last reconfirmed||2025-05-20
--- Comment #1 from Thomas Schwinge ---
So, this issue can generally be triggered with code that return a struct. For
example, offload-compiling ('-fopenacc' or '-fopenmp')
'libgomp.oacc-c-c++-common/abi-struct-1.c' with '-O1 -fno-inline', we get for
'rempty' (but also 'rschar', for example):
Breakpoint 2, (anonymous namespace)::pass_nrv::execute (this=0x24e0670,
fun=0x7790add0) at ../../source-gcc/gcc/tree-nrv.cc:137
137 {
(gdb) n
138 tree result = DECL_RESULT (current_function_decl);
[...]
173 if (greturn *return_stmt = dyn_cast (stmt))
(gdb) n
178 ret_val = gimple_return_retval (return_stmt);
(gdb) n
179 if (ret_val)
(gdb) n
180 gcc_assert (ret_val == result);
(gdb) print result
$4 = (tree) 0x777fb300
(gdb) call debug_tree(result)
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x777b0a80>
ignored BLK
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c:19:14
size unit-size
align:8 warn_if_not_align:0 context >
(gdb) print ret_val
$5 = (tree) 0x777f4a18
(gdb) call debug_tree(ret_val)
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x777b0a80>
ignored BLK
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c:21:11
size unit-size
align:8 warn_if_not_align:0 context >
..., so there is indeed a disconnect between 'DECL_RESULT' and
'gimple_return_retval'.
The source code says: "In a function with an aggregate return value, the
gimplifier has changed all non-empty RETURN_EXPRs to return the RESULT_DECL.",
so I suppose the issue is that for offloading we're rewriting some DECLs, but
are missing to update something?
If I disable this local check (the 'ret_val' variable isn't used for anything
other than the 'assert'), the ICE goes away -- and the pass doesn't do any
transformations (for 'libgomp.oacc-c-c++-common/abi-struct-1.c'), so not sure
whether that finding implies anything useful.
[Bug tree-optimization/89550] [8/9/10 Regression] Spurious array-bounds warning when using __PRETTY_FUNCTION__ as a string_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89550 Andrew Pinski changed: What|Removed |Added Target Milestone|8.5 |9.0
[Bug libstdc++/120367] [15/16 Regression] C++23 ranges::transform | ranges::to exception catching (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120367 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.2 Keywords||EH, needs-bisection, ||wrong-code
[Bug cobol/119885] libgcobol: SQRT wrong argument check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119885 --- Comment #1 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:d44beb132850a8ced1b0614e2724f18465b4a737 commit r16-761-gd44beb132850a8ced1b0614e2724f18465b4a737 Author: Robert Dubner Date: Tue May 20 11:49:43 2025 -0400 cobol: sqrt(0) is not an ec-argument error. [PR119885] libgcobol PR cobol/119885 * intrinsic.cc: (__gg__sqrt): Change test from <= zero to < zero. gcc/testsuite * cobol.dg/group2/FUNCTION_SQRT__2_.cob: Testcase. * cobol.dg/group2/FUNCTION_SQRT__2_.out: Known-good for the testcase.
[Bug cobol/119770] FLOAT-DECIMAL support + "cannot MOVE '_stack1'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119770 --- Comment #2 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:fba34a0cc55488ad89becf81cf2c9ac517d244d4 commit r16-764-gfba34a0cc55488ad89becf81cf2c9ac517d244d4 Author: Robert Dubner Date: Tue May 20 13:35:15 2025 -0400 cobol: Multiple PRs; formatting; exception processing. The PRs mentined here have either been previously fixed, or are fixed by this commit. gcc/cobol/ChangeLog: PR cobol/119770 PR cobol/119772 PR cobol/119790 PR cobol/119771 PR cobol/119810 PR cobol/119335 PR cobol/119632 * cdf-copy.cc (GLOB_BRACE): Eliminate . * cdfval.h (_CDF_VAL_H_): Switch to C++ headers. * copybook.h (class copybook_elem_t): Eliminate . (class copybook_t): Likewise. * gcobc: Numerous changes to improve utility. * gcobol.1: Correct names in the list of functions. * genapi.cc (compare_binary_binary): Use has_attr() function. * lexio.cc (cdftext::lex_open): Typo; filename logic. (cdftext::process_file): Filename logic. * parse.y: Numerous parsing changes. * parse_ante.h (new_alphanumeric): C++ includes; changes to temporaries. (new_tempnumeric): Likewise. (new_tempnumeric_float): Likewise. (set_real_from_capacity): Created. * scan.l: Use yy_pop_state(). * scan_ante.h (typed_name): Find figconst from data.initial. * symbols.cc (symbol_valid_udf_args): Eliminate. (symbols_update): figconst processing. (new_temporary_impl): For functions, set .initial to function name. (temporaries_t::acquire): Likewise. (new_alphanumeric): Likewise. (new_temporary): Likewise. * symbols.h (_SYMBOLS_H_): Use C++ includes. (cbl_figconst_tok): Change handling of figconst. (cbl_figconst_field_of): Change handling of figconst. (symbol_valid_udf_args): Eliminate. * symfind.cc (symbol_match2): Change declaration. (symbol_match): Change declaration. libgcobol/ChangeLog: * charmaps.cc: Switch to C++ includes. * common-defs.h: Likewise. * constants.cc: Likewise. * ec.h: Remove #include . * gcobolio.h (GCOBOLIO_H_): Switch to C++ includes. * gfileio.cc: Likewise. * gmath.cc: Likewise. * intrinsic.cc: Comment formatting; C++ includes. * io.cc: C++ includes. * libgcobol.cc: (__gg__stash_exceptions): Eliminate. * valconv.cc: Switch to C++ includes. Co-Authored-By: James K. Lowden
[Bug cobol/119810] FE: -include does not unset "included from"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119810 --- Comment #5 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:fba34a0cc55488ad89becf81cf2c9ac517d244d4 commit r16-764-gfba34a0cc55488ad89becf81cf2c9ac517d244d4 Author: Robert Dubner Date: Tue May 20 13:35:15 2025 -0400 cobol: Multiple PRs; formatting; exception processing. The PRs mentined here have either been previously fixed, or are fixed by this commit. gcc/cobol/ChangeLog: PR cobol/119770 PR cobol/119772 PR cobol/119790 PR cobol/119771 PR cobol/119810 PR cobol/119335 PR cobol/119632 * cdf-copy.cc (GLOB_BRACE): Eliminate . * cdfval.h (_CDF_VAL_H_): Switch to C++ headers. * copybook.h (class copybook_elem_t): Eliminate . (class copybook_t): Likewise. * gcobc: Numerous changes to improve utility. * gcobol.1: Correct names in the list of functions. * genapi.cc (compare_binary_binary): Use has_attr() function. * lexio.cc (cdftext::lex_open): Typo; filename logic. (cdftext::process_file): Filename logic. * parse.y: Numerous parsing changes. * parse_ante.h (new_alphanumeric): C++ includes; changes to temporaries. (new_tempnumeric): Likewise. (new_tempnumeric_float): Likewise. (set_real_from_capacity): Created. * scan.l: Use yy_pop_state(). * scan_ante.h (typed_name): Find figconst from data.initial. * symbols.cc (symbol_valid_udf_args): Eliminate. (symbols_update): figconst processing. (new_temporary_impl): For functions, set .initial to function name. (temporaries_t::acquire): Likewise. (new_alphanumeric): Likewise. (new_temporary): Likewise. * symbols.h (_SYMBOLS_H_): Use C++ includes. (cbl_figconst_tok): Change handling of figconst. (cbl_figconst_field_of): Change handling of figconst. (symbol_valid_udf_args): Eliminate. * symfind.cc (symbol_match2): Change declaration. (symbol_match): Change declaration. libgcobol/ChangeLog: * charmaps.cc: Switch to C++ includes. * common-defs.h: Likewise. * constants.cc: Likewise. * ec.h: Remove #include . * gcobolio.h (GCOBOLIO_H_): Switch to C++ includes. * gfileio.cc: Likewise. * gmath.cc: Likewise. * intrinsic.cc: Comment formatting; C++ includes. * io.cc: C++ includes. * libgcobol.cc: (__gg__stash_exceptions): Eliminate. * valconv.cc: Switch to C++ includes. Co-Authored-By: James K. Lowden
[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 --- Comment #11 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:fba34a0cc55488ad89becf81cf2c9ac517d244d4 commit r16-764-gfba34a0cc55488ad89becf81cf2c9ac517d244d4 Author: Robert Dubner Date: Tue May 20 13:35:15 2025 -0400 cobol: Multiple PRs; formatting; exception processing. The PRs mentined here have either been previously fixed, or are fixed by this commit. gcc/cobol/ChangeLog: PR cobol/119770 PR cobol/119772 PR cobol/119790 PR cobol/119771 PR cobol/119810 PR cobol/119335 PR cobol/119632 * cdf-copy.cc (GLOB_BRACE): Eliminate . * cdfval.h (_CDF_VAL_H_): Switch to C++ headers. * copybook.h (class copybook_elem_t): Eliminate . (class copybook_t): Likewise. * gcobc: Numerous changes to improve utility. * gcobol.1: Correct names in the list of functions. * genapi.cc (compare_binary_binary): Use has_attr() function. * lexio.cc (cdftext::lex_open): Typo; filename logic. (cdftext::process_file): Filename logic. * parse.y: Numerous parsing changes. * parse_ante.h (new_alphanumeric): C++ includes; changes to temporaries. (new_tempnumeric): Likewise. (new_tempnumeric_float): Likewise. (set_real_from_capacity): Created. * scan.l: Use yy_pop_state(). * scan_ante.h (typed_name): Find figconst from data.initial. * symbols.cc (symbol_valid_udf_args): Eliminate. (symbols_update): figconst processing. (new_temporary_impl): For functions, set .initial to function name. (temporaries_t::acquire): Likewise. (new_alphanumeric): Likewise. (new_temporary): Likewise. * symbols.h (_SYMBOLS_H_): Use C++ includes. (cbl_figconst_tok): Change handling of figconst. (cbl_figconst_field_of): Change handling of figconst. (symbol_valid_udf_args): Eliminate. * symfind.cc (symbol_match2): Change declaration. (symbol_match): Change declaration. libgcobol/ChangeLog: * charmaps.cc: Switch to C++ includes. * common-defs.h: Likewise. * constants.cc: Likewise. * ec.h: Remove #include . * gcobolio.h (GCOBOLIO_H_): Switch to C++ includes. * gfileio.cc: Likewise. * gmath.cc: Likewise. * intrinsic.cc: Comment formatting; C++ includes. * io.cc: C++ includes. * libgcobol.cc: (__gg__stash_exceptions): Eliminate. * valconv.cc: Switch to C++ includes. Co-Authored-By: James K. Lowden
[Bug cobol/119335] cobol frontend ignores -M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119335 --- Comment #3 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:fba34a0cc55488ad89becf81cf2c9ac517d244d4 commit r16-764-gfba34a0cc55488ad89becf81cf2c9ac517d244d4 Author: Robert Dubner Date: Tue May 20 13:35:15 2025 -0400 cobol: Multiple PRs; formatting; exception processing. The PRs mentined here have either been previously fixed, or are fixed by this commit. gcc/cobol/ChangeLog: PR cobol/119770 PR cobol/119772 PR cobol/119790 PR cobol/119771 PR cobol/119810 PR cobol/119335 PR cobol/119632 * cdf-copy.cc (GLOB_BRACE): Eliminate . * cdfval.h (_CDF_VAL_H_): Switch to C++ headers. * copybook.h (class copybook_elem_t): Eliminate . (class copybook_t): Likewise. * gcobc: Numerous changes to improve utility. * gcobol.1: Correct names in the list of functions. * genapi.cc (compare_binary_binary): Use has_attr() function. * lexio.cc (cdftext::lex_open): Typo; filename logic. (cdftext::process_file): Filename logic. * parse.y: Numerous parsing changes. * parse_ante.h (new_alphanumeric): C++ includes; changes to temporaries. (new_tempnumeric): Likewise. (new_tempnumeric_float): Likewise. (set_real_from_capacity): Created. * scan.l: Use yy_pop_state(). * scan_ante.h (typed_name): Find figconst from data.initial. * symbols.cc (symbol_valid_udf_args): Eliminate. (symbols_update): figconst processing. (new_temporary_impl): For functions, set .initial to function name. (temporaries_t::acquire): Likewise. (new_alphanumeric): Likewise. (new_temporary): Likewise. * symbols.h (_SYMBOLS_H_): Use C++ includes. (cbl_figconst_tok): Change handling of figconst. (cbl_figconst_field_of): Change handling of figconst. (symbol_valid_udf_args): Eliminate. * symfind.cc (symbol_match2): Change declaration. (symbol_match): Change declaration. libgcobol/ChangeLog: * charmaps.cc: Switch to C++ includes. * common-defs.h: Likewise. * constants.cc: Likewise. * ec.h: Remove #include . * gcobolio.h (GCOBOLIO_H_): Switch to C++ includes. * gfileio.cc: Likewise. * gmath.cc: Likewise. * intrinsic.cc: Comment formatting; C++ includes. * io.cc: C++ includes. * libgcobol.cc: (__gg__stash_exceptions): Eliminate. * valconv.cc: Switch to C++ includes. Co-Authored-By: James K. Lowden
[Bug cobol/119790] FE (parser): CONSTANT AS figurative-constant broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119790 --- Comment #2 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:fba34a0cc55488ad89becf81cf2c9ac517d244d4 commit r16-764-gfba34a0cc55488ad89becf81cf2c9ac517d244d4 Author: Robert Dubner Date: Tue May 20 13:35:15 2025 -0400 cobol: Multiple PRs; formatting; exception processing. The PRs mentined here have either been previously fixed, or are fixed by this commit. gcc/cobol/ChangeLog: PR cobol/119770 PR cobol/119772 PR cobol/119790 PR cobol/119771 PR cobol/119810 PR cobol/119335 PR cobol/119632 * cdf-copy.cc (GLOB_BRACE): Eliminate . * cdfval.h (_CDF_VAL_H_): Switch to C++ headers. * copybook.h (class copybook_elem_t): Eliminate . (class copybook_t): Likewise. * gcobc: Numerous changes to improve utility. * gcobol.1: Correct names in the list of functions. * genapi.cc (compare_binary_binary): Use has_attr() function. * lexio.cc (cdftext::lex_open): Typo; filename logic. (cdftext::process_file): Filename logic. * parse.y: Numerous parsing changes. * parse_ante.h (new_alphanumeric): C++ includes; changes to temporaries. (new_tempnumeric): Likewise. (new_tempnumeric_float): Likewise. (set_real_from_capacity): Created. * scan.l: Use yy_pop_state(). * scan_ante.h (typed_name): Find figconst from data.initial. * symbols.cc (symbol_valid_udf_args): Eliminate. (symbols_update): figconst processing. (new_temporary_impl): For functions, set .initial to function name. (temporaries_t::acquire): Likewise. (new_alphanumeric): Likewise. (new_temporary): Likewise. * symbols.h (_SYMBOLS_H_): Use C++ includes. (cbl_figconst_tok): Change handling of figconst. (cbl_figconst_field_of): Change handling of figconst. (symbol_valid_udf_args): Eliminate. * symfind.cc (symbol_match2): Change declaration. (symbol_match): Change declaration. libgcobol/ChangeLog: * charmaps.cc: Switch to C++ includes. * common-defs.h: Likewise. * constants.cc: Likewise. * ec.h: Remove #include . * gcobolio.h (GCOBOLIO_H_): Switch to C++ includes. * gfileio.cc: Likewise. * gmath.cc: Likewise. * intrinsic.cc: Comment formatting; C++ includes. * io.cc: C++ includes. * libgcobol.cc: (__gg__stash_exceptions): Eliminate. * valconv.cc: Switch to C++ includes. Co-Authored-By: James K. Lowden
[Bug cobol/119771] FE (parser): CONSTANT AS LENGTH OF does not error - but result in length of zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119771 --- Comment #2 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:fba34a0cc55488ad89becf81cf2c9ac517d244d4 commit r16-764-gfba34a0cc55488ad89becf81cf2c9ac517d244d4 Author: Robert Dubner Date: Tue May 20 13:35:15 2025 -0400 cobol: Multiple PRs; formatting; exception processing. The PRs mentined here have either been previously fixed, or are fixed by this commit. gcc/cobol/ChangeLog: PR cobol/119770 PR cobol/119772 PR cobol/119790 PR cobol/119771 PR cobol/119810 PR cobol/119335 PR cobol/119632 * cdf-copy.cc (GLOB_BRACE): Eliminate . * cdfval.h (_CDF_VAL_H_): Switch to C++ headers. * copybook.h (class copybook_elem_t): Eliminate . (class copybook_t): Likewise. * gcobc: Numerous changes to improve utility. * gcobol.1: Correct names in the list of functions. * genapi.cc (compare_binary_binary): Use has_attr() function. * lexio.cc (cdftext::lex_open): Typo; filename logic. (cdftext::process_file): Filename logic. * parse.y: Numerous parsing changes. * parse_ante.h (new_alphanumeric): C++ includes; changes to temporaries. (new_tempnumeric): Likewise. (new_tempnumeric_float): Likewise. (set_real_from_capacity): Created. * scan.l: Use yy_pop_state(). * scan_ante.h (typed_name): Find figconst from data.initial. * symbols.cc (symbol_valid_udf_args): Eliminate. (symbols_update): figconst processing. (new_temporary_impl): For functions, set .initial to function name. (temporaries_t::acquire): Likewise. (new_alphanumeric): Likewise. (new_temporary): Likewise. * symbols.h (_SYMBOLS_H_): Use C++ includes. (cbl_figconst_tok): Change handling of figconst. (cbl_figconst_field_of): Change handling of figconst. (symbol_valid_udf_args): Eliminate. * symfind.cc (symbol_match2): Change declaration. (symbol_match): Change declaration. libgcobol/ChangeLog: * charmaps.cc: Switch to C++ includes. * common-defs.h: Likewise. * constants.cc: Likewise. * ec.h: Remove #include . * gcobolio.h (GCOBOLIO_H_): Switch to C++ includes. * gfileio.cc: Likewise. * gmath.cc: Likewise. * intrinsic.cc: Comment formatting; C++ includes. * io.cc: C++ includes. * libgcobol.cc: (__gg__stash_exceptions): Eliminate. * valconv.cc: Switch to C++ includes. Co-Authored-By: James K. Lowden
[Bug cobol/119770] FLOAT-DECIMAL support + "cannot MOVE '_stack1'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119770 Robert Dubner changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug cobol/119790] FE (parser): CONSTANT AS figurative-constant broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119790 Robert Dubner changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED
[Bug cobol/119772] FE: COBOL2025/2026 (original GnuCOBOL extension) LENGTH OF usage-specification missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119772 --- Comment #2 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:fba34a0cc55488ad89becf81cf2c9ac517d244d4 commit r16-764-gfba34a0cc55488ad89becf81cf2c9ac517d244d4 Author: Robert Dubner Date: Tue May 20 13:35:15 2025 -0400 cobol: Multiple PRs; formatting; exception processing. The PRs mentined here have either been previously fixed, or are fixed by this commit. gcc/cobol/ChangeLog: PR cobol/119770 PR cobol/119772 PR cobol/119790 PR cobol/119771 PR cobol/119810 PR cobol/119335 PR cobol/119632 * cdf-copy.cc (GLOB_BRACE): Eliminate . * cdfval.h (_CDF_VAL_H_): Switch to C++ headers. * copybook.h (class copybook_elem_t): Eliminate . (class copybook_t): Likewise. * gcobc: Numerous changes to improve utility. * gcobol.1: Correct names in the list of functions. * genapi.cc (compare_binary_binary): Use has_attr() function. * lexio.cc (cdftext::lex_open): Typo; filename logic. (cdftext::process_file): Filename logic. * parse.y: Numerous parsing changes. * parse_ante.h (new_alphanumeric): C++ includes; changes to temporaries. (new_tempnumeric): Likewise. (new_tempnumeric_float): Likewise. (set_real_from_capacity): Created. * scan.l: Use yy_pop_state(). * scan_ante.h (typed_name): Find figconst from data.initial. * symbols.cc (symbol_valid_udf_args): Eliminate. (symbols_update): figconst processing. (new_temporary_impl): For functions, set .initial to function name. (temporaries_t::acquire): Likewise. (new_alphanumeric): Likewise. (new_temporary): Likewise. * symbols.h (_SYMBOLS_H_): Use C++ includes. (cbl_figconst_tok): Change handling of figconst. (cbl_figconst_field_of): Change handling of figconst. (symbol_valid_udf_args): Eliminate. * symfind.cc (symbol_match2): Change declaration. (symbol_match): Change declaration. libgcobol/ChangeLog: * charmaps.cc: Switch to C++ includes. * common-defs.h: Likewise. * constants.cc: Likewise. * ec.h: Remove #include . * gcobolio.h (GCOBOLIO_H_): Switch to C++ includes. * gfileio.cc: Likewise. * gmath.cc: Likewise. * intrinsic.cc: Comment formatting; C++ includes. * io.cc: C++ includes. * libgcobol.cc: (__gg__stash_exceptions): Eliminate. * valconv.cc: Switch to C++ includes. Co-Authored-By: James K. Lowden
[Bug cobol/119772] FE: COBOL2025/2026 (original GnuCOBOL extension) LENGTH OF usage-specification missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119772 Robert Dubner changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/102891] Passing real part of complex type component using w%z%re to a subroutine gives erroneous value of dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102891 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |15.2 --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed for gcc-16, and backported to 15-branch. Closing. Thanks for the report!
[Bug c/120369] New: internal compiler error: Segmentation fault during GIMPLE pass: cplxlower0 only in version 15.1 and trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120369
Bug ID: 120369
Summary: internal compiler error: Segmentation fault during
GIMPLE pass: cplxlower0 only in version 15.1 and trunk
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
ICE in:
```
#include
#include
#include
int main()
{
double complex z = cos(2.0 * 0.0 + I);
cabs(z);
}
```
Stack dump
```
during GIMPLE pass: cplxlower0
: In function 'main':
:4:5: internal compiler error: Segmentation fault
4 | int main()
| ^~~~
0x2607e45 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2625bb6 internal_error(char const*, ...)
???:0
0x11a683e verify_gimple_in_cfg(function*, bool, bool)
???:0
```
To quickly reproduce:
https://godbolt.org/z/EqvWqh5zP
[Bug c++/120370] New: GCC fails to parse a trailing requires-clause that ends with an identifier when followed by a ctor-initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120370
Bug ID: 120370
Summary: GCC fails to parse a trailing requires-clause that
ends with an identifier when followed by a
ctor-initializer
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
struct C {
int j;
static constexpr bool i = true;
template
C(T&&) requires i : j() {}
};
:5:23: error: found ':' in nested-name-specifier, expected '::'
5 | C(T&&) requires i : j() {}
| ^
| ::
:5:21: error: 'i' is not a class, namespace, or enumeration
5 | C(T&&) requires i : j() {}
| ^
:5:27: error: 'C' declared as function returning a function
5 | C(T&&) requires i : j() {}
| ^
Clang accepts.
[Bug middle-end/120369] [15/16 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cplxlower0 only in version 15.1 and trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120369 --- Comment #1 from Andrew Pinski --- Created attachment 61481 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61481&action=edit No header version
[Bug c++/120370] GCC fails to parse a trailing requires-clause that ends with an identifier when followed by a ctor-initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120370 --- Comment #1 from Andrew Pinski --- Simple workaround is to do `(i)`.
[Bug c++/120370] GCC fails to parse a trailing requires-clause that ends with an identifier when followed by a ctor-initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120370 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-20 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug fortran/120371] [15.1 regression] erroneously triggered error message on non-matching interfaces with flag -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120371 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2025-05-20 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Jürgen, this is likely a duplicate of pr119928/pr120163 and has been fixed after the 15.1 release. Either upgrade to 15-HEAD, or use -Wno-external-argument-mismatch to suppress this check. Can you please check?
[Bug middle-end/120369] [15/16 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cplxlower0 only in version 15.1 and trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120369 --- Comment #5 from Andrew Pinski --- Created attachment 61482 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61482&action=edit Patch which I am testing
[Bug fortran/120371] New: [15.1 regression] erroneously triggered error message on non-matching interfaces with flag -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120371 Bug ID: 120371 Summary: [15.1 regression] erroneously triggered error message on non-matching interfaces with flag -Wall Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Created attachment 61483 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61483&action=edit Reproducer The following code when compiled with -Wall is rejected with erroneous error messages: Error: Interface mismatch in dummy procedure ‘evaluate_special’ at (1): 'evaluate_special' has the wrong number of arguments The -Wall doesn't produce this error message for versions 11.5, 13.3 or 14.2, but with 15.1. The reproducer is listed below and attached: module lorentz implicit none private type :: vector4_t real, dimension(0:3) :: p = [0, 0, 0, 0] end type vector4_t abstract interface subroutine func_spec (p_origin, & p1_in, p1_out, msq_in, jac) import type(vector4_t), intent(in) :: p_origin type(vector4_t), intent(in) :: p1_in type(vector4_t), intent(inout) :: p1_out real, intent(in), optional :: msq_in real, intent(inout), optional :: jac end subroutine func_spec end interface contains recursive subroutine rec_func (p_dec, & p_in, p_out, i_real, msq_in, jac, evaluate_special) type(vector4_t), intent(in) :: p_dec type(vector4_t), intent(in), dimension(:) :: p_in type(vector4_t), intent(inout), dimension(:) :: p_out integer, intent(in) :: i_real real, intent(in), optional :: msq_in real, intent(inout), optional :: jac procedure(func_spec), intent(in), & pointer, optional :: evaluate_special type(vector4_t) :: p_dec_new if (present (evaluate_special)) then call evaluate_special (p_in(1), p_in(2), & p_out(i_real)) call rec_func (p_in(1), p_in (2 : ), p_out, & i_real + 1, msq_in, jac, evaluate_special) else call func (p_in(1), p_in(2), & p_out(i_real), msq_in, jac) end if end subroutine rec_func subroutine func (p_origin, & p1_in, p1_out, msq_in, jac) type(vector4_t), intent(in) :: p_origin type(vector4_t), intent(in) :: p1_in type(vector4_t), intent(inout) :: p1_out real, intent(in), optional :: msq_in real, intent(inout), optional :: jac type(vector4_t) :: p1_rest, p2_rest real :: msq_in_update p1_rest = p1_in p1_out = p1_rest msq_in_update = 42. if (present (jac) .and. present (msq_in)) then jac = jac * msq_in_update end if end subroutine func end module lorentz
[Bug fortran/102599] Wrong simplification of inquiry parameters for complex arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102599 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2025-5-20 Keywords||rejects-valid --- Comment #2 from anlauf at gcc dot gnu.org --- The situation has even degraded in the mean time. While the testcase in comment#0 did at least "compile" with gcc-12, it is rejected at >= 13: pr102599.f90:4:3: 4 | real,parameter :: r(*) = x%re | 1 Error: Unclassifiable statement at (1) pr102599.f90:7:12: 7 | print *, i,all(i== 0) ! wrong |1 Error: Symbol 'i' at (1) has no IMPLICIT type pr102599.f90:6:12: 6 | print *, r,all(r== 1) ! wrong |1 Error: Symbol 'r' at (1) has no IMPLICIT type While the first code substitution from comment#1 helps, the other replacement does not lead to an ICE here but it wrongly rejected.
[Bug fortran/120371] [15.1 regression] erroneously triggered error message on non-matching interfaces with flag -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120371 --- Comment #2 from Jürgen Reuter --- (In reply to anlauf from comment #1) > Jürgen, > > this is likely a duplicate of pr119928/pr120163 and has been fixed after > the 15.1 release. > > Either upgrade to 15-HEAD, or use -Wno-external-argument-mismatch > to suppress this check. > > Can you please check? Harald, I can confirm both points that (1) -Wno-external-argument-mismatch let the compilation pass, and that the bug fix by Thomas Koenig in https://gcc.gnu.org/cgit/gcc/commit/?id=7b38bab21a126512c17c8084ad78b6bf75fc1437 solves also my issue. I would concur to mark this one as duplicate.
[Bug middle-end/120372] New: canonicalize_comparison uses gen_move_insn to calcualate the cost of the constant formation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120372
Bug ID: 120372
Summary: canonicalize_comparison uses gen_move_insn to
calcualate the cost of the constant formation
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Take:
```
int check1 (int x)
{
return x > 0xaa9fff;
}
```
Currently canonicalize_comparison gives:
;; cmp: gt, old cst: (const_int 11182079 [0xaa9fff]) new cst: (const_int
11182080 [0xaaa000])
;; old cst cost: 8, new cst cost: 8
Which is correct if we are forming a constant by itself. But the cmp
instruction can take a different constant than if we are just forming the
constant.
Note the middle-end also checks:
rtx_cost (x, mode, COMPARE, 0, optimize_insn_for_speed_p ())
In a different code. So maybe canonicalize_comparison should use that instead.
[Bug libstdc++/120367] [15/16 Regression] C++23 ranges::transform | ranges::to exception catching (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120367
--- Comment #1 from Andrew Pinski ---
#0 __pthread_kill_implementation (threadid=,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x7788b9b3 in __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78
#2 0x7783e646 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#3 0x778287f3 in __GI_abort () at abort.c:79
#4 0x77829130 in __libc_message (fmt=,
fmt@entry=0x779bb6a8 "%s\n") at ../sysdeps/posix/libc_fatal.c:150
#5 0x778959f7 in malloc_printerr (str=str@entry=0x779be290 "double
free or corruption (out)") at malloc.c:5515
#6 0x778976e0 in _int_free (av=0x779fac80 ,
p=0x407db0, have_lock=) at malloc.c:4455
#7 0x77899d35 in __GI___libc_free (mem=) at
malloc.c:3258
#8 0x00404695 in std::__new_allocator::deallocate
(this=0x41b420, __p=0x407dc0
"\300;\347\367\377\177", __n=140737350674973) at
/home/apinski/upstream-gcc-isel/include/c++/16.0.0/bits/new_allocator.h:172
#9 0x00403f38 in std::allocator::deallocate (this=0x41b420,
__p=0x407dc0
"\300;\347\367\377\177", __n=140737350674973) at
/home/apinski/upstream-gcc-isel/include/c++/16.0.0/bits/allocator.h:215
#10 std::allocator_traits >::deallocate (__a=...,
__p=0x407dc0
"\300;\347\367\377\177", __n=140737350674973) at
/home/apinski/upstream-gcc-isel/include/c++/16.0.0/bits/alloc_traits.h:649
#11 std::__cxx11::basic_string,
std::allocator >::_M_destroy (this=0x41b420, __size=140737350674972) at
/home/apinski/upstream-gcc-isel/include/c++/16.0.0/bits/basic_string.h:305
#12 0x00403b8a in std::__cxx11::basic_string, std::allocator >::_M_dispose (this=0x41b420) at
/home/apinski/upstream-gcc-isel/include/c++/16.0.0/bits/basic_string.h:299
#13 0x0040374c in std::__cxx11::basic_string, std::allocator >::~basic_string (this=0x41b420)
at /home/apinski/upstream-gcc-isel/include/c++/16.0.0/bits/basic_string.h:896
#14 0x0040461d in std::destroy_at, std::allocator > > (__location=0x41b420) at
/home/apinski/upstream-gcc-isel/include/c++/16.0.0/bits/stl_construct.h:88
#15 0x0040439b in std::_Destroy, std::allocator > > (__pointer=0x41b420) at
/home/apinski/upstream-gcc-isel/include/c++/16.0.0/bits/stl_construct.h:164
#16 0x0040415c in std::_Destroy, std::allocator >*> (__first=0x41b420, __last=0x0)
at /home/apinski/upstream-gcc-isel/include/c++/16.0.0/bits/stl_construct.h:212
#17 0x00403a4a in std::_Destroy, std::allocator >*,
std::__cxx11::basic_string, std::allocator >
> (__first=0x41b360, __last=0x0) at
/home/apinski/upstream-gcc-isel/include/c++/16.0.0/bits/alloc_traits.h:1045
#18 std::vector,
std::allocator >, std::allocator, std::allocator > > >::~vector
(this=0x7fffda70) at
/home/apinski/upstream-gcc-isel/include/c++/16.0.0/bits/stl_vector.h:790
#19 0x004027df in std::vector, std::allocator >,
std::allocator,
std::allocator > >
>::vector
> >, main():: > >(std::from_range_t,
std::ranges::transform_view, std::allocator >,
std::allocator,
std::allocator > > > >, main():: > &&, const
std::allocator,
std::allocator > > &) (this=0x7fffda70, __rg=..., __a=...) at
/home/apinski/upstream-gcc-isel/include/c++/16.0.0/bits/stl_vector.h:778
#20 0x004026dc in
std::ranges::to >,
std::ranges::transform_view
> >, main():: >
>(std::ranges::transform_view, std::allocator >,
std::allocator,
std::allocator > > > >, main():: > &&) (__r=...) at
/home/apinski/upstream-gcc-isel/include/c++/16.0.0/ranges:9432
#21 0x00402477 in std::ranges::to
> >, main():: >
>(std::ranges::transform_view, std::allocator >,
std::allocator,
std::allocator > > > >, main():: > &&) (__r=...) at
/home/apinski/upstream-gcc-isel/include/c++/16.0.0/ranges:9534
#22 0x004024ad in
std::ranges::__detail::_To2::operator()
> >, main():: >
>(std::ranges::transform_view, std::allocator >,
std::allocator,
std::allocator > > > >, main():: > &&) const
(this=0x7fffd8e7, __r=...) at
/home/apinski/upstream-gcc-isel/include/c++/16.0.0/ranges:9602
#23 0x004024e6 in operator()<>(void) const (__closure=0x7fffda08)
at /home/apinski/upstream-gcc-isel/include/c++/16.0.0/ranges:1070
#24 0x0040269d in
std::__invoke_impl >,
std::ranges::views::__adaptor::_Partial
>::operator()
>,
std::ranges::transform_view
> >, main():: > >(this
std::ranges::views::__adaptor::_Partial
>&&,
std::ranges::transform_view
> >, main():: >&&)::&>(std::__invoke_other, struct {...} &) (__f=...) at
/home/apinski/upstream-gcc-isel/include/c++/16.0.0/bits/invoke.h:63
#25 0x0040266c in
std::__invoke
>::operator()
>,
std::ranges::transform_view
> >, main():: > >(this
std::ranges::views::__adaptor::_Partial
>&&,
std::ranges::transform_view
> >, main():: >&&)::&>(struct
{...} &) (__fn=...)
at /home/apinski/upstream-gcc-isel/include/c++/16.0.0/bits/invoke.h:99
#26 0x0040251b in
std::__apply_impl
>::operator()
>,
std::ranges::transform_view
> >, main():: > >(th
[Bug c++/120366] [12/13/14/15/16 Regression] __PRETTY_FUNCTION__ is sometimes an array of unknown bound inside double template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120366 Andrew Pinski changed: What|Removed |Added Known to work||8.5.0 Target Milestone|--- |12.5 Summary|__PRETTY_FUNCTION__ is |[12/13/14/15/16 Regression] |sometimes an array of |__PRETTY_FUNCTION__ is |unknown bound inside double |sometimes an array of |template|unknown bound inside double ||template --- Comment #2 from Andrew Pinski --- Oh it is a regression after all.
[Bug tree-optimization/119712] [14 Regression] compiler hang at -O{1,2,3,s} since r14-5109
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119712 Andrew Macleod changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Andrew Macleod --- fixed
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Bug 85316 depends on bug 95801, which changed state. Bug 95801 Summary: Optimiser does not exploit the fact that an integer divisor cannot be zero https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95801 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/95801] Optimiser does not exploit the fact that an integer divisor cannot be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95801 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Macleod --- fixed on trunk.
[Bug libstdc++/120367] New: C++23 ranges::transform | ranges::to exception catching (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120367
Bug ID: 120367
Summary: C++23 ranges::transform | ranges::to exception
catching (segfault)
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lexa.nf at yandex dot ru
Target Milestone: ---
Hello!
My colleague ran into the problem that GCC 15.1 doesn't handle exceptions
properly with std::ranges::transform | std::ranges::to. Program just shuts down
with SIGSEGV, but GCC 14.2 handles this as planned.
System: Arch Linux, x64
Test case:
#include
#include
#include
#include
#include
auto main() -> int
{
try
{
auto vec = std::vector{ "1", "2", "3", "4", "5" };
auto rng = vec
| std::views::transform([](auto elt) { throw std::runtime_error{ "error"
}; return elt; })
| std::ranges::to();
}
catch (const std::runtime_error& err)
{
std::cerr << "Oops: " << err.what() << std::endl;
}
}
Compile options: -std=c++23
No compile errors and warnings.
Debug options shows nothing: -std=c++23 -Wall -Wextra -fno-strict-aliasing
-fwrapv -D_GLIBCXX_ASSERTIONS -fno-aggressive-loop-optimizations
Reproduce online: https://godbolt.org/z/GfxYMMWa3
Correct behaviour online: https://godbolt.org/z/z6fonGjPc
