[Bug target/115255] sibcall at -O0 causes ICE in df_refs_verify on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255 --- Comment #7 from Andi Kleen --- The patch can be even more minimized. The thumb2_reorg change is not needed because nothing does df_verify() after it (I just noticed it because I added some extra for debugging). So even though thumb2_reorg breaks the DF with -O0 it doesn't matter because nobody cares.
[Bug target/115255] sibcall at -O0 causes ICE in df_refs_verify on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255 --- Comment #6 from Andi Kleen --- Created attachment 58324 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58324=edit patch to fix arm sibcalls with -O0 Better patch that uses the existing cfun flag for tail calls.
[Bug target/115255] sibcall at -O0 causes ICE in df_refs_verify on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255 --- Comment #5 from Andrew Pinski --- The question comes is musttail going to always work at -O0 or should it just fail at -O0 with an error message. Or rather is musttail is just a hack in itself and should never be implemented.
[Bug target/115255] sibcall at -O0 causes ICE in df_refs_verify on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255 --- Comment #4 from Andi Kleen --- Created attachment 58323 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58323=edit hack patch to fix arm sibcalls at -O0 The attached patch makes the test case pass on arm. - Some of the sibcall related code in "pro_and_epilogue" was dependent on optimize Should probably add some cfun flag that indicates musttail? I enabled it unconditionally for now. - The thumb2_reorg code corrupts the DF chains for sibcalls when not optimizing. I just disabled it for now, it shouldn't be needed at -O0 since it's just a size optimization. This may not be clean enough to post however. I'm a bit afraid that other ports may break too, will do some testing.
[Bug c/114493] [11/12/13/14/15 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493 Sam James changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #7 from Sam James --- I've been scratching my head as to why matoro and someone else reported it with Samba today out of nowhere. I assume it's because of https://sourceware.org/git/?p=glibc.git;a=commit;h=26e7005728f0eea2972474e6be2905c467661237. I think it was suggested that a forward decl might work to mitigate the ICE but I haven't tried (yet).
[Bug sanitizer/115273] [12 Regression] passing zero to ctz() check missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115273 --- Comment #4 from Andrew Pinski --- Note ubsan can detect (correctly) a different undefined behavior since GCC 13 (since r13-4988-g8692b15ae7c05e; aka PR108256) but the undefinedness of passing 0 to ctz is still not detected and that is a dup of bug 115127 .
[Bug sanitizer/115127] [12/13/14/15 Regression] passing zero to __builtin_ctz() check missing since r12-151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115127
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2024-05-18 00:00:00 |2024-06-02
Status|UNCONFIRMED |NEW
Keywords|needs-bisection,|
|needs-reduction |
Ever confirmed|0 |1
Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
|passing zero to |passing zero to
|__builtin_ctz() check |__builtin_ctz() check
|missing |missing since r12-151
--- Comment #6 from Andrew Pinski ---
Reduced testcase:
```
int f(int a)
{
return __builtin_ctz(a) == 0;
}
int main(void)
{
__builtin_printf("%d\n", f(0));
}
```
Caused by r12-151-g75f8900159133c .
[Bug sanitizer/115127] [12/13/14/15 Regression] passing zero to __builtin_ctz() check missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115127 --- Comment #5 from Andrew Pinski --- *** Bug 115273 has been marked as a duplicate of this bug. ***
[Bug sanitizer/115273] [12 Regression] passing zero to ctz() check missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115273 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 115127 ***
[Bug sanitizer/115273] [12 Regression] passing zero to ctz() check missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115273
--- Comment #2 from Andrew Pinski ---
Reduced testcase:
```
int f(int a)
{
return __builtin_ctz(a) == 0;
}
int main(void)
{
__builtin_printf("%d\n", f(0));
}
```
[Bug tree-optimization/115060] Probable an issue around usage of vect_look_through_possible_promotion in tree-vect-patterns.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115060 --- Comment #3 from Feng Xue --- Linaro reported a regression: https://linaro.atlassian.net/browse/GNU-1226 Actually, this is not, but exposes a new bug in vect_look_through_possible_promotion. The function fails to figure out root definition if casts involves more than two promotions with sign change as: long a = (long)b; // promotion cast -> int b = (int)c; // promotion cast, sign change -> unsigned short c = ...; For this case, the function thinks the 2nd cast has different sign as the 1st, so stop looking through, while "unsigned short -> integer" is a nature sign extension.
[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
--- Comment #1 from Lewis Hyatt ---
Hmm that is odd. It works fine on x86-64/Linux so I think this is something
target-specific with PCH? If this assert is firing:
void
c_init_preprocess ()
{
gcc_assert (!the_parser);
...
It means that the_parser was not NULL after reading in the PCH. But it should
be, because the_parser is explicitly set to NULL prior to writing the PCH (at
the end of c_parse_file() in cp/parse.cc) and so that's what it should get set
to after reading the PCH back in. Are you able to confirm whether the_parser
stored in the PCH is indeed NULL, maybe? I don't have anywhere to test this
platform myself at the moment. Thanks...
That assert could be simply removed too, but it does seem worth understanding
how it can trigger here...
[Bug c++/115319] New: ICE when mutating a captured parameter in an explicit-this lambda if a capture is not trivially copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115319
Bug ID: 115319
Summary: ICE when mutating a captured parameter in an
explicit-this lambda if a capture is not trivially
copyable
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
struct S
{
S() {}
S(const S&) {}
};
void a()
{
[i=0, x=S{}](this auto self) -> void
{
i++;
}();
}
-std=c++23 (optional, it throws a c++23-extensions warning and the same ICE
without it)
: In lambda function:
:11:9: internal compiler error: in gimplify_compound_lval, at
gimplify.cc:3576
11 | i++;
| ^
0x202ef4c internal_error(char const*, ...)
???:0
0x778915 fancy_abort(char const*, int, char const*)
???:0
0xc4c739 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xc55a00 gimplify_self_mod_expr(tree_node**, gimple**, gimple**, bool,
tree_node*)
???:0
0xc4cf52 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xc4e8c4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xc4ca8d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xc4e8ae gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xc50e8e gimplify_body(tree_node*, bool)
???:0
0xc51250 gimplify_function_tree(tree_node*)
???:0
0xaba647 cgraph_node::analyze()
???:0
0xabd9b1 symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/114493] [11/12/13/14/15 Regression] internal compiler error: in fld_incomplete_type_of, at ipa-free-lang-data.cc:257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493
matoro changed:
What|Removed |Added
CC||matoro_gcc_bugzilla@matoro.
||tk
--- Comment #6 from matoro ---
Hit this as well building samba on 14.
Minimized:
void _talloc_array();
struct sockaddr_storage
resolve_lmhosts_file_as_sockaddr(struct sockaddr_storage **);
struct __attribute__((__may_alias__)) sockaddr_storage {
} resolve_name_multiple_recv() {
_talloc_array();
}
$ x86_64-pc-linux-gnu-gcc-14 -flto -c resolve.c.10.i
during IPA pass: *free_lang_data
resolve.c.10.i:7:1: internal compiler error: in fld_incomplete_type_of, at
ipa-free-lang-data.cc:257
7 | }
| ^
[Bug analyzer/105888] RFE: -fanalyzer should complain when an on-stack address escapes/outlives the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105888 Bug 105888 depends on bug 106203, which changed state. Bug 106203 Summary: Allow to emit diagnostics at return edges for the exit point as well as the call site https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106203 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/106203] Allow to emit diagnostics at return edges for the exit point as well as the call site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106203 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above patch for GCC 15. I don't plan to attempt backporting this, so marking it resolved.
[Bug c++/115314] auto template parameter has const qualifier on it even though the original does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115314 Andrew Pinski changed: What|Removed |Added Summary|Type of the `auto` template |auto template parameter has |parameter in a concept is |const qualifier on it even |not decayed when called as |though the original does |dependent name |not Last reconfirmed||2024-06-01 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107222, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=112555, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104577 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. I thought I had saw an almost exact dup of this issue. The const qualifier is added for the type incorrectly.
[Bug analyzer/106203] Allow to emit diagnostics at return edges for the exit point as well as the call site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106203 --- Comment #2 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:2b0a7fe3abfbd47081f714a0a1263afe00c5cfd9 commit r15-969-g2b0a7fe3abfbd47081f714a0a1263afe00c5cfd9 Author: David Malcolm Date: Sat Jun 1 13:50:32 2024 -0400 analyzer: detect -Wanalyzer-allocation-size at call stmts [PR106203] gcc/analyzer/ChangeLog: PR analyzer/106203 * checker-event.h: Include "analyzer/event-loc-info.h". (struct event_loc_info): Move to its own header file. * diagnostic-manager.cc (diagnostic_manager::emit_saved_diagnostic): Move creation of event_loc_info here from add_final_event, and if we have a stmt_finder, call its update_event_loc_info method. * engine.cc (leak_stmt_finder::update_event_loc_info): New. (exploded_node::detect_leaks): Likewise. (exploded_node::detect_leaks): Pass nullptr as call_stmt arg to region_model::pop_frame. * event-loc-info.h: New file, with content taken from checker-event.h. * exploded-graph.h (stmt_finder::update_event_loc_info): New pure virtual function. * infinite-loop.cc (infinite_loop_diagnostic::add_final_event): Update for change to vfunc signature. * infinite-recursion.cc (infinite_recursion_diagnostic::add_final_event): Likewise. * pending-diagnostic.cc (pending_diagnostic::add_final_event): Pass in the event_loc_info from the caller, rather than generating it from a gimple stmt and enode. * pending-diagnostic.h (pending_diagnostic::add_final_event): Likewise. * region-model.cc (region_model::on_longjmp): Pass nullptr as call_stmt arg to region_model::pop_frame. (region_model::update_for_return_gcall): Likewise, but pass call_stmt. (class caller_context): New. (region_model::pop_frame): Add "call_stmt" argument. Use it and the frame_region with a caller_context when setting result_dst_reg's value so that any diagnostic is reported at the call stmt in the caller. (selftest::test_stack_frames): Pass nullptr as call_stmt arg to region_model::pop_frame. (selftest::test_alloca): Likewise. * region-model.h (region_model::pop_frame): Add "call_stmt" argument. gcc/testsuite/ChangeLog: PR analyzer/106203 * c-c++-common/analyzer/allocation-size-1.c (test_9): Remove xfail. * c-c++-common/analyzer/allocation-size-2.c (test_8): Likewise. * gcc.dg/analyzer/allocation-size-multiline-4.c: New test. * gcc.dg/plugin/analyzer_cpython_plugin.c (refcnt_stmt_finder::update_event_loc_info): New. Signed-off-by: David Malcolm
[Bug jit/103562] Jitted code produces incorrect result when returning 3-member struct from internal function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103562 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |11.3 Resolution|--- |FIXED --- Comment #9 from Andrew Pinski --- Fixed for GCC 11.3.0.
[Bug debug/91507] wrong debug for completed array with previous incomplete declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||mark at gcc dot gnu.org Resolution|--- |FIXED --- Comment #9 from Mark Wielaard --- 10.1 is long since released
[Bug c++/115318] decltype(lambda) from an template function inside a templated lambda causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115318 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|decltype(lambda) with some |decltype(lambda) from an |templates causes ICE|template function inside a ||templated lambda causes ICE Last reconfirmed||2024-06-01 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug fortran/115315] [PDT] valgrind error in gfc_simplify_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115315
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Summary|valgrind error in |[PDT] valgrind error in
|gfc_simplify_expr |gfc_simplify_expr
Priority|P3 |P4
Last reconfirmed||2024-06-01
--- Comment #1 from anlauf at gcc dot gnu.org ---
Reduced testcase:
subroutine p2
type t1(n1,n2)
integer,kind :: n1,n2
integer :: c2(iachar('ABCDEFGHIJ'(n1:n1)))
end type
end
The current implementation is known to be incomplete.
[Bug c/115310] Option -Werror=return-type is too aggressive with -std=gnu89
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115310 --- Comment #5 from Florian Weimer --- (In reply to Martin Jambor from comment #4) > No. Specifically in openSUSE, -Werror=return-type is part of the > default compiler flags. We would like to silence the new errors such > as implicit-int in packages written in pre-99 C with putting > -std=gnu89 rather than -fpermissive in package spec files. We think > that -std=gnu89 option really better describes what is going on, > i.e. that the code is old rather than somewhat broken. We tried to use -std=gnu89 for this purpose in Fedora originally, and it did not quite work. Quite a few packages use C89 (or K) language features *and* C99-only constructs such as for loop initial declarations and C99 inlining semantics.
[Bug c/115310] Option -Werror=return-type is too aggressive with -std=gnu89
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115310 --- Comment #4 from Martin Jambor --- (In reply to Sam James from comment #2) > In such environments, you don't need an explicit > -Werror=return-type. I agree I don't need it but it is there. > So, you're asking presumably about testing with < GCC 14 to emulate > >= GCC 14 behaviour? No. Specifically in openSUSE, -Werror=return-type is part of the default compiler flags. We would like to silence the new errors such as implicit-int in packages written in pre-99 C with putting -std=gnu89 rather than -fpermissive in package spec files. We think that -std=gnu89 option really better describes what is going on, i.e. that the code is old rather than somewhat broken. But because of the behavior described in this bug we cannot - without either also explicitely specifying -Wno-error=return-type or persuading the project to weaken the default warnings. > It works fine without the explicit -Werror=return-type on GCC 14. The compiler sees an explicit -Werror=return-type but it is not explicitely spelled out in the package spec files.
[Bug tree-optimization/115307] [avr] Don't expand isinf() like a built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307 Georg-Johann Lay changed: What|Removed |Added Priority|P4 |P3
[Bug debug/78100] DWARF symbols for an array sometimes missing the array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78100 --- Comment #10 from Kevin Puetz --- The godbolt recipe also nails down the other end of the version range - 5.4 produced something weirder still (a single DW_TAG_variable with DW_AT_external=true, but also with DW_AT_location and DW_AT_upper_bound present - so it kind of mushed the two decls together with all the attributes of both). 6.1 starts emitting two separate DW_TAG_variable DIEs, one with DW_AT_external=true and the other with DW_AT_location, using DW_AT_specification to link them; but it lost the DW_AT_upper_bound. Then 10.1...trunk all seem fixed, emitting an incomplete `extern` and a complete definition, as it should. So "Known to fail" should be 6.1-9.5, "Known to Work" should be 10.0+ (and bug 91507 can also be marked "RESOLVED FIXED" since 10.1 is long since released). I'd update the metadata myself but don't the permission bits...
[Bug c++/115318] New: decltype(lambda) with some templates causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115318
Bug ID: 115318
Summary: decltype(lambda) with some templates causes ICE
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
template struct S {};
template
void foo()
{
using foo_t = decltype([](){});
[]() { S{}; }();
}
void bar() { foo(); }
-std=c++20
: In instantiation of 'foo<>():: [with int k = 6]':
:7:36: required from 'void foo() [with int i = 4]'
7 | []() { S{}; }();
| ~~~^~
:10:17: required from here
10 | void bar() { foo(); }
| ~~~^~
:6:28: internal compiler error: in tsubst, at cp/pt.cc:16401
6 | using foo_t = decltype([](){});
|^~
0x202ef4c internal_error(char const*, ...)
???:0
0x778915 fancy_abort(char const*, int, char const*)
???:0
0x938dd0 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x943a11 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x939200 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x93c437 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0x931a0f instantiate_decl(tree_node*, bool, bool)
???:0
0x831fb7 maybe_instantiate_decl(tree_node*)
???:0
0x8332f7 mark_used(tree_node*, int)
???:0
0x7a20a3 build_op_call(tree_node*, vec**, int)
???:0
0x9602fe finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x931a0f instantiate_decl(tree_node*, bool, bool)
???:0
0x94d2e3 instantiate_pending_templates(int)
???:0
0x835608 c_parse_final_cleanups()
???:0
0xa0c508 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 --- Comment #14 from dave.anglin at bell dot net --- On 2024-05-29 8:17 a.m., ro at CeBiTec dot Uni-Bielefeld.DE wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 > > --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #12 from dave.anglin at bell dot net --- >> It will be a few days before I can test. I've had three hard drives fail on >> my >> main hppa >> system in the past few weeks. > I guess it's best to postpone committing to the gcc-14 branch until you > can report hppa results then. Btw., when you're ready, could you also > check the libbacktrace test results (no .sum file, unfortunately, just > buried deeply in make check output) for comparison? Thanks. Change fixes the following libstdc++ tests on hppa-linux: FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++26 execution test FAIL: 19_diagnostics/stacktrace/entry.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/entry.cc -std=gnu++26 execution test FAIL: 19_diagnostics/stacktrace/output.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/output.cc -std=gnu++26 execution test FAIL: 19_diagnostics/stacktrace/stacktrace.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/stacktrace.cc -std=gnu++26 execution test The libbacktrace tests all pass on hppa-linux.
[Bug debug/78100] DWARF symbols for an array sometimes missing the array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78100 Mark Wielaard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Mark Wielaard --- (In reply to Kevin Puetz from comment #8) > Found it: this is a duplicate of bug 91507, thus fixed by > r276403/31632e2c4327146ea8d21cff33adaa505b17d2bd Thanks for the research. *** This bug has been marked as a duplicate of bug 91507 ***
[Bug debug/91507] wrong debug for completed array with previous incomplete declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507 Mark Wielaard changed: What|Removed |Added CC||gccbugs at dima dot secretsauce.ne ||t --- Comment #8 from Mark Wielaard --- *** Bug 78100 has been marked as a duplicate of this bug. ***
[Bug target/115317] [avr] isinf should return -1 for -Inf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115317 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Georg-Johann Lay --- Fixed in v14.2+ and also in v13.4+.
[Bug tree-optimization/115307] [avr] Don't expand isinf() like a built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:c57d73f4cd5ca61327406fc2521a2235dd49d12e commit r13-8817-gc57d73f4cd5ca61327406fc2521a2235dd49d12e Author: Georg-Johann Lay Date: Sat Jun 1 10:38:00 2024 +0200 AVR: tree-optimization/115307 - Work around isinf bloat from early passes. PR tree-optimization/115307 gcc/ * config/avr/avr.md (SFDF): New mode iterator. (isinf2) [sf, df]: New expanders. gcc/testsuite/ * gcc.target/avr/torture/pr115307-isinf.c: New test. (cherry picked from commit fabb545026f714b7d1cbe586f4c5bbf6430bdde3)
[Bug target/115317] [avr] isinf should return -1 for -Inf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115317 --- Comment #3 from GCC Commits --- The releases/gcc-13 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:b45d7281c1b4eb2cf61280b9f7064229b7ca7581 commit r13-8816-gb45d7281c1b4eb2cf61280b9f7064229b7ca7581 Author: Georg-Johann Lay Date: Sat Jun 1 12:46:31 2024 +0200 AVR: target/115317 - Make isinf(-Inf) return -1. PR target/115317 libgcc/config/avr/libf7/ * libf7-asm.sx (__isinf): Map -Inf to -1. gcc/testsuite/ * gcc.target/avr/torture/pr115317-isinf.c: New test. (cherry picked from commit f12454278dc725fec3520a5d870e967d79292ee6)
[Bug target/115317] [avr] isinf should return -1 for -Inf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115317 --- Comment #2 from GCC Commits --- The releases/gcc-14 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:d7f42794d94e5a26f396253b1698ea1930337df3 commit r14-10268-gd7f42794d94e5a26f396253b1698ea1930337df3 Author: Georg-Johann Lay Date: Sat Jun 1 12:46:31 2024 +0200 AVR: target/115317 - Make isinf(-Inf) return -1. PR target/115317 libgcc/config/avr/libf7/ * libf7-asm.sx (__isinf): Map -Inf to -1. gcc/testsuite/ * gcc.target/avr/torture/pr115317-isinf.c: New test. (cherry picked from commit f12454278dc725fec3520a5d870e967d79292ee6)
[Bug target/115317] [avr] isinf should return -1 for -Inf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115317 --- Comment #1 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:f12454278dc725fec3520a5d870e967d79292ee6 commit r15-968-gf12454278dc725fec3520a5d870e967d79292ee6 Author: Georg-Johann Lay Date: Sat Jun 1 12:46:31 2024 +0200 AVR: target/115317 - Make isinf(-Inf) return -1. PR target/115317 libgcc/config/avr/libf7/ * libf7-asm.sx (__isinf): Map -Inf to -1. gcc/testsuite/ * gcc.target/avr/torture/pr115317-isinf.c: New test.
[Bug target/115317] New: [avr] isinf should return -1 for -Inf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115317 Bug ID: 115317 Summary: [avr] isinf should return -1 for -Inf Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- The isinf implementation in LibF7 currently returns a bool-ish value. However, isinf(-Inf) = -1 should be returned.
[Bug fortran/115316] New: valgrind error in insert_parameter_exprs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115316 Bug ID: 115316 Summary: valgrind error in insert_parameter_exprs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For this F90 source code: ! RUN: %python %S/test_errors.py %s %flang_fc1 ! Check for semantic errors in ALLOCATE statements subroutine C933_a(b1, ca3, ca4, cp3, cp3mold, cp4, cp7, cp8, bsrc) ! If any allocate-object has a deferred type parameter, is unlimited polymorphic, ! or is of abstract type, either type-spec or source-expr shall appear. ! Only testing deferred type parameters here. type SomeType(k, l1, l2) integer, kind :: k = 1 integer, len :: l1 integer, len :: l2 = 3 character(len=l2+l1) str end type type B(l) integer, len :: l character(:), allocatable :: msg type(SomeType(4, l, :)), pointer :: something end type character(len=:), allocatable :: ca1, ca2(:) character(len=*), allocatable :: ca3, ca4(:) character(len=2), allocatable :: ca5, ca6(:) character(len=5) mold type(SomeType(l1=:,l2=:)), pointer :: cp1, cp2(:) type(SomeType(l1=3,l2=4)) cp1mold type(SomeType(1,*,:)), pointer :: cp3, cp4(:) type(SomeType(1,*,5)) cp3mold type(SomeType(l1=:)), pointer :: cp5, cp6(:) type(SomeType(l1=6)) cp5mold type(SomeType(1,*,*)), pointer :: cp7, cp8(:) type(SomeType(1, l1=3)), pointer :: cp9, cp10(:) type(B(*)) b1 type(B(:)), allocatable :: b2 type(B(5)) b3 type(SomeType(4, *, 8)) bsrc ! Expecting errors: need type-spec/src-expr !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(ca1) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(ca2(4)) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(cp1) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(cp2(2)) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(cp3) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(cp4(2)) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(cp5) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(cp6(2)) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(b1%msg) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(b1%something) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(b2%msg) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(b2%something) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(b3%msg) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(b3%something) ! Nominal cases, expecting no errors allocate(character(len=5):: ca2(4)) allocate(character(len=5):: ca1) allocate(character*5:: ca1) allocate(ca2(4), MOLD = "abcde") allocate(ca2(2), MOLD = (/"abcde", "fghij"/)) allocate(ca1, MOLD = mold) allocate(ca2(4), SOURCE = "abcde") allocate(ca2(2), SOURCE = (/"abcde", "fghij"/)) allocate(ca1, SOURCE = mold) allocate(SomeType(l1=1, l2=2):: cp1, cp2(2)) allocate(SomeType(1,*,5):: cp3, cp4(2)) !OK, but segfaults gfortran allocate(SomeType(l1=1):: cp5, cp6(2)) allocate(cp1, cp2(2), mold = cp1mold) allocate(cp3, cp4(2), mold = cp3mold) allocate(cp5, cp6(2), mold = cp5mold) allocate(cp1, cp2(2), source = cp1mold) allocate(cp3, cp4(2), source = cp3mold) allocate(cp5, cp6(2), source = cp5mold) allocate(character(len=10):: b1%msg, b2%msg, b3%msg) allocate(SomeType(4, b1%l, 9):: b1%something) allocate(b2%something, source=bsrc) allocate(SomeType(4, 5, 8):: b3%something) ! assumed/explicit length do not need type-spec/mold allocate(ca3, ca4(4)) allocate(ca5, ca6(4)) allocate(cp7, cp8(2)) allocate(cp9, cp10(2)) end subroutine >From the flang testsuite at https://github.com/llvm/llvm-project/tree/main/flang/test, does this: test $
[Bug libstdc++/105258] std::get_temporary_buffer() does not respect alignment (affects std::stable_sort())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105258 Jonathan Wakely changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-June/65 ||3296.html --- Comment #8 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653296.html
[Bug fortran/115315] New: valgrind error in gfc_simplify_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115315
Bug ID: 115315
Summary: valgrind error in gfc_simplify_expr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this Fortran source code:
! RUN: %python %S/test_errors.py %s %flang_fc1
! Test section subscript
subroutine p1
real :: a(10,10)
real :: b(5,5)
real :: c
integer :: n
n = 2
b = a(1:10:n,1:n+3)
end
! Test substring
subroutine p2
type t1(n1,n2)
integer,kind :: n1,n2
integer :: c2(iachar('ABCDEFGHIJ'(n1:n1)))
end type
character :: a(10)
character :: b(5)
character :: c(0)
integer :: n
n = 3
b = a(n:7)
b = a(n+3:)
b = a(:n+2)
a(n:7) = b
a(n+3:) = b
a(:n+2) = b
n = iachar(1_'ABCDEFGHIJ'(1:1))
c = 'ABCDEFGHIJ'(1:0)
end
! Test pointer assignment with bounds
subroutine p3
integer, pointer :: a(:,:)
integer, target :: b(2,2)
integer :: n
n = 2
a(n:,n:) => b
a(1:n,1:n) => b
end
! Test pointer assignment to array element
subroutine p4
type :: t
real, pointer :: a
end type
type(t) :: x(10)
integer :: i
real, target :: y
x(i)%a => y
end subroutine
A recent valgrind version of gfortran does this:
test $ ~/gcc/results.20240530.valgrind/bin/gfortran -c -w
./Semantics/resolve49.f90
==1331074== Invalid read of size 2
==1331074==at 0x48513A0: memmove (vg_replace_strmem.c:1414)
==1331074==by 0x74F69F: gfc_simplify_expr(gfc_expr*, int) (expr.cc:2305)
==1331074==by 0x74F4FB: gfc_simplify_expr(gfc_expr*, int) (expr.cc:2265)
The source code file is from the flang testsuite at
https://github.com/llvm/llvm-project/tree/main/flang/test
[Bug fortran/107141] ICE: Segmentation fault (in contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107141 --- Comment #5 from David Binderman --- Bit more detail from valgrind: /Lower/derived-type-finalization.f90 ==687074== Invalid read of size 8 ==687074==at 0x856D97: gfc_class_len_get(tree_node*) (trans-expr.cc:273) ==687074==by 0x86F37B: trans_class_vptr_len_assignment(stmtblock_t*, gfc_expr*, gfc_expr*, gfc_se*, tree_node**, tree_node**, tree_node**) (trans-expr.cc:10169)
[Bug libstdc++/115269] Hardcoded links in 14.1 docs to pages from release 4.3.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115269 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.5 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- Fixed on all active branches. Thanks for the report.
[Bug libstdc++/115269] Hardcoded links in 14.1 docs to pages from release 4.3.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115269 --- Comment #6 from GCC Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9b792e0159f7076e5901972be751333006e2ea83 commit r11-11460-g9b792e0159f7076e5901972be751333006e2ea83 Author: Jonathan Wakely Date: Wed May 29 10:59:48 2024 +0100 libstdc++: Replace link to gcc-4.3.2 docs in manual [PR115269] Link to the docs for GCC trunk instead. For the release branches, the link should be to the docs for appropriate release branch. Also replace the incomplete/outdated list of explicit -std options with a single entry for the -std option. libstdc++-v3/ChangeLog: PR libstdc++/115269 * doc/xml/manual/using.xml: Replace link to gcc-4.3.2 docs. Replace list of -std=... options with a single entry for -std. * doc/html/manual/using.html: Regenerate. (cherry picked from commit b460ede64f9471589822831e04eecff4a3dbecf2)
[Bug libstdc++/115269] Hardcoded links in 14.1 docs to pages from release 4.3.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115269 --- Comment #5 from GCC Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:26fa081ad4b7299a33b5ff4525bce8858a1b0dd2 commit r12-10483-g26fa081ad4b7299a33b5ff4525bce8858a1b0dd2 Author: Jonathan Wakely Date: Wed May 29 10:59:48 2024 +0100 libstdc++: Replace link to gcc-4.3.2 docs in manual [PR115269] Link to the docs for GCC trunk instead. For the release branches, the link should be to the docs for appropriate release branch. Also replace the incomplete/outdated list of explicit -std options with a single entry for the -std option. libstdc++-v3/ChangeLog: PR libstdc++/115269 * doc/xml/manual/using.xml: Replace link to gcc-4.3.2 docs. Replace list of -std=... options with a single entry for -std. * doc/html/manual/using.html: Regenerate. (cherry picked from commit b460ede64f9471589822831e04eecff4a3dbecf2)
[Bug libstdc++/115269] Hardcoded links in 14.1 docs to pages from release 4.3.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115269 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3687dcfabfaae566f4b42aa8a805869b809e6247 commit r13-8815-g3687dcfabfaae566f4b42aa8a805869b809e6247 Author: Jonathan Wakely Date: Wed May 29 10:59:48 2024 +0100 libstdc++: Replace link to gcc-4.3.2 docs in manual [PR115269] Link to the docs for GCC trunk instead. For the release branches, the link should be to the docs for appropriate release branch. Also replace the incomplete/outdated list of explicit -std options with a single entry for the -std option. libstdc++-v3/ChangeLog: PR libstdc++/115269 * doc/xml/manual/using.xml: Replace link to gcc-4.3.2 docs. Replace list of -std=... options with a single entry for -std. * doc/html/manual/using.html: Regenerate. (cherry picked from commit b460ede64f9471589822831e04eecff4a3dbecf2)
[Bug libstdc++/115269] Hardcoded links in 14.1 docs to pages from release 4.3.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115269 --- Comment #3 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:2f097c0b3f76b50d96895158b2d80024252cfbd0 commit r14-10267-g2f097c0b3f76b50d96895158b2d80024252cfbd0 Author: Jonathan Wakely Date: Wed May 29 10:59:48 2024 +0100 libstdc++: Replace link to gcc-4.3.2 docs in manual [PR115269] Link to the docs for GCC trunk instead. For the release branches, the link should be to the docs for appropriate release branch. Also replace the incomplete/outdated list of explicit -std options with a single entry for the -std option. libstdc++-v3/ChangeLog: PR libstdc++/115269 * doc/xml/manual/using.xml: Replace link to gcc-4.3.2 docs. Replace list of -std=... options with a single entry for -std. * doc/html/manual/using.html: Regenerate. (cherry picked from commit b460ede64f9471589822831e04eecff4a3dbecf2)
[Bug libstdc++/115269] Hardcoded links in 14.1 docs to pages from release 4.3.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115269 --- Comment #2 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b460ede64f9471589822831e04eecff4a3dbecf2 commit r15-967-gb460ede64f9471589822831e04eecff4a3dbecf2 Author: Jonathan Wakely Date: Wed May 29 10:59:48 2024 +0100 libstdc++: Replace link to gcc-4.3.2 docs in manual [PR115269] Link to the docs for GCC trunk instead. For the release branches, the link should be to the docs for appropriate release branch. Also replace the incomplete/outdated list of explicit -std options with a single entry for the -std option. libstdc++-v3/ChangeLog: PR libstdc++/115269 * doc/xml/manual/using.xml: Replace link to gcc-4.3.2 docs. Replace list of -std=... options with a single entry for -std. * doc/html/manual/using.html: Regenerate.
[Bug tree-optimization/115307] [avr] Don't expand isinf() like a built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307 --- Comment #5 from Georg-Johann Lay --- (In reply to Richard Biener from comment #1) > The issue is that we probably fold isinff early. On x86 I see already in > .original: > > return !(ABS_EXPR u<= 3.4028234663852885981170418348451692544e+38); That looks incorrect. The man 3 page for isinf states that it returns -1 for -Inf, but that expression returns 1 for -Inf (same for the expanded avr code above).
[Bug c/115311] -fno-builtin-xxx allowing anything for xxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115311 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Georg-Johann Lay --- Thanks for the explanation; so it's a feature rather than a bug. Closing as won't fix.
[Bug tree-optimization/115307] [avr] Don't expand isinf() like a built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307 --- Comment #4 from Georg-Johann Lay --- The isinf part is fixied in v14.2+, but there is also isnan etc. which don't currently habe an optabs entry, so defining a failing expander won't work.
[Bug tree-optimization/115307] [avr] Don't expand isinf() like a built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307 --- Comment #3 from GCC Commits --- The releases/gcc-14 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:9d08c55f7c99329f4289ad3a4157c2d8d8a78d8c commit r14-10266-g9d08c55f7c99329f4289ad3a4157c2d8d8a78d8c Author: Georg-Johann Lay Date: Sat Jun 1 10:38:00 2024 +0200 AVR: tree-optimization/115307 - Work around isinf bloat from early passes. PR tree-optimization/115307 gcc/ * config/avr/avr.md (SFDF): New mode iterator. (isinf2) [sf, df]: New expanders. gcc/testsuite/ * gcc.target/avr/torture/pr115307-isinf.c: New test. (cherry picked from commit fabb545026f714b7d1cbe586f4c5bbf6430bdde3)
[Bug tree-optimization/115307] [avr] Don't expand isinf() like a built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307 --- Comment #2 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:fabb545026f714b7d1cbe586f4c5bbf6430bdde3 commit r15-966-gfabb545026f714b7d1cbe586f4c5bbf6430bdde3 Author: Georg-Johann Lay Date: Sat Jun 1 10:38:00 2024 +0200 AVR: tree-optimization/115307 - Work around isinf bloat from early passes. PR tree-optimization/115307 gcc/ * config/avr/avr.md (SFDF): New mode iterator. (isinf2) [sf, df]: New expanders. gcc/testsuite/ * gcc.target/avr/torture/pr115307-isinf.c: New test.
[Bug c++/115314] New: Type of the `auto` template parameter in a concept is not decayed when called as dependent name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115314
Bug ID: 115314
Summary: Type of the `auto` template parameter in a concept is
not decayed when called as dependent name
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
```
struct X {
static constexpr int val = 42;
};
template
concept A = std::same_as;
template
concept B = A;
static_assert(A);
static_assert(B);
```
The first static assert passes while the other one fails. Both cases work on
clang and MSVC: https://godbolt.org/z/v5z6bee7c
Affects all gcc versions from 12 to 15.
