[Bug c++/16663] Poor parse error recovery with mispelled type in function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16663 Andrew Pinski changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #10 from Andrew Pinski --- *** Bug 80684 has been marked as a duplicate of this bug. ***
[Bug c++/80684] poor error message and fix-it hint for a function with an argument of undeclared type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80684 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #3 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 16663 ***
[Bug libstdc++/119081] New: libstdc++.modules.json generated with incorrect relative path if configured with '--prefix=/' or '--prefix=' (empty)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119081
Bug ID: 119081
Summary: libstdc++.modules.json generated with incorrect
relative path if configured with '--prefix=/' or
'--prefix=' (empty)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: c at cyano dot cn
Target Milestone: ---
Output of `gcc -v`:
```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/gcc-git/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix= --enable-languages=c,c++
--disable-bootstrap --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250301 (experimental) (GCC)
```
(Install with `sudo make DESTDIR=/opt/gcc-git install`)
Content of `/opt/gcc-git/lib64/libstdc++.modules.json`:
```json
{
"version": 1,
"revision": 1,
"modules": [
{
"logical-name": "std",
"source-path": "/include/c++/15.0.1/bits/std.cc",
"is-std-library": true
},
{
"logical-name": "std.compat",
"source-path": "/include/c++/15.0.1/bits/std.compat.cc",
"is-std-library": true
}
]
}
```
The expected relative path is `../include/c++/15.0.1/bits/std.cc` and
`../include/c++/15.0.1/bits/std.compat.cc`.
It seems to be caused by `contrib/relpath.sh` not correctly handling the case:
```bash-session
$ ./contrib/relpath.sh /lib /include/c++/15.0.1/bits/std.cc
/include/c++/15.0.1/bits/std.cc
$ ./contrib/relpath.sh /usr/lib /usr/include/c++/15.0.1/bits/std.cc
../include/c++/15.0.1/bits/std.cc
```
[Bug c++/119082] New: GCC Incorrectly Accepts Explicit Destructor Call for Scalar Type in constexpr Context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119082
Bug ID: 119082
Summary: GCC Incorrectly Accepts Explicit Destructor Call for
Scalar Type in constexpr Context
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: qurong at ios dot ac.cn
Target Milestone: ---
GCC 12.4/13.3/11.4 erroneously compiles code that explicitly calls the
destructor of a scalar type (e.g., int) within a constexpr function, while
MSVC/Clang correctly reject it. This violates the C++ standard rules.
For the following code test.cpp:
```
template
constexpr bool test_scope() {
{
T x{};
x.~T(); // Ill-formed if T is a scalar type (e.g., int)
}
return true;
}
int main() {
constexpr bool a = test_scope();
return 0;
}
```
Compile with GCC:
g++ -std=c++20 test.cpp
Expected Result:
Compilation fails with an error about invalid destructor call for scalar types.
Actual Result:
GCC compiles the code without errors.
Environment:
Compiler: GCC 12.4/13.3/11.4
Flags: -std=c++20
Standard References:
C++20 §7.6.1.4: "The use of a pseudo-destructor-name after a dot . or arrow ->
operator represents the destructor for the non-class type denoted by the
type-name [...] The result can only be used as the operand for the function
call operator ()."
C++20 §7.6.1.4/5: "The postfix-expression before the dot . or arrow -> shall
have class type."
Compiler Explorer link: https://godbolt.org/z/5W1b4zWoj
[Bug libstdc++/119081] libstdc++.modules.json generated with incorrect relative path if configured with '--prefix=/' or '--prefix=' (empty)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119081 --- Comment #1 from Andrew Pinski --- I am not even sure if prefix of / is valid use case. Shouldn't it be /usr ?
[Bug ipa/119012] [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012 --- Comment #11 from Levi Zim --- When building 14.2.1+r711+g3228df20cfa3, I got a different object that is different between stage 2 and 3: Comparing stages 2 and 3 Bootstrap comparison failure! gcc/builtins.o differs It comes with a similar pattern that .gnu.lto_.jmpfuncs.1 is the most different section ignoring offset differences and lto opts.
[Bug c++/119082] GCC Incorrectly Accepts Explicit Destructor Call for Scalar Type in constexpr Context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119082 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 71093 ***
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 119082, which changed state. Bug 119082 Summary: GCC Incorrectly Accepts Explicit Destructor Call for Scalar Type in constexpr Context https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119082 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug target/118934] [15 Regression] RISC-V: ICE: output_operand: invalid expression as operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118934 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org Status|WAITING |ASSIGNED
[Bug target/69374] install.texi is bit-rotten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374 --- Comment #30 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:4fee152dc36ba6ffa39dd29b6493dc1840374b05 commit r15--g4fee152dc36ba6ffa39dd29b6493dc1840374b05 Author: Gerald Pfeifer Date: Sat Mar 1 22:37:46 2025 +0100 doc: Simplify description of *-*-freebsd* gcc: PR target/69374 * doc/install.texi (Specific, *-*-freebsd*): Simplify description.
[Bug c++/119073] [15 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:911 with temporary vector in range-for with -std=c++23 since r15-7481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119073
--- Comment #7 from Jakub Jelinek ---
struct A { ~A (); };
struct B { B (const A &a = A ()); int *begin (); int *end (); ~B (); };
void
foo (bool x)
{
for (auto i : (x ? B{} : B{}))
;
}
ICEs as well.
[Bug c/118765] c23 tag matching broken for multiple redeclarations of typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765 --- Comment #13 from uecker at gcc dot gnu.org --- Yes thanks, I need to analyze this a bit more but I narrowed the problem down to this. What do you mean by "my non-toy sources compiles/works correctly now"? There should be no existing code affected as this affects code not allowed before C23. Or does this affect existing code somehow?
[Bug fortran/119078] New: Abstract bind(c) interface should not be a global entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119078 Bug ID: 119078 Summary: Abstract bind(c) interface should not be a global entity Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- module x abstract interface subroutine foo() bind(c) end subroutine foo end interface end module x subroutine foo(a) real :: a end subroutine foo currently yields abstract.f90:8:1: 3 | subroutine foo() bind(c) | 2~ .. 8 | subroutine foo(a) | 1~ Warnung: 'foo' has the wrong number of arguments zwischen (1) und (2) which is wrong - the abstract interface cannot be a global symbol.
[Bug fortran/119078] Abstract bind(c) interface should not be a global entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119078 Thomas Koenig changed: What|Removed |Added Keywords||diagnostic, needs-stdcheck --- Comment #1 from Thomas Koenig --- (Well, it makes absolutely no sense, but I am adding needs-stdcheck anyway).
[Bug target/119079] Intel assembly output should use MOVSXD instead of MOVSX for 32b->64b sign extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119079 --- Comment #1 from Tibor Győri --- Created attachment 60630 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60630&action=edit Intel manual page for MOVSX/MOVSXD
[Bug target/119079] New: Intel assembly output should use MOVSXD instead of MOVSX for 32b->64b sign extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119079 Bug ID: 119079 Summary: Intel assembly output should use MOVSXD instead of MOVSX for 32b->64b sign extensions Product: gcc Version: 15.0 URL: https://gcc.godbolt.org/z/GrEP9GTr6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tiborgyri at gmail dot com CC: tiborgyri at gmail dot com Target Milestone: --- Target: x86-64 Created attachment 60629 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60629&action=edit -O3 -march=znver3 -S -masm=intel Currently, x86-64 backend is happy to generate Intel syntax assembly that is strictly speaking not valid: > movsx rax, r10d According to the relevant page of the Intel Software Developer’s Manual, MOVSX is not a valid mnemonic for 32b --> 64b sign extensions, and MOVSXD should be generated instead.
[Bug ipa/119012] [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012 --- Comment #12 from Levi Zim --- The bad commit is 3228df20cfa3581015dc32657eb17d6f24af3104 "rtl: Remove invalid compare simplification" [PR117186]
[Bug ipa/119012] [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012 --- Comment #10 from Levi Zim --- Sometimes I didn't get the comparison failure but a hard ICE instead: *** stack smashing detected ***: terminated during RTL pass: combine /usr/src/debug/gcc/gcc/gcc/config/riscv/corev.md: In function ‘recog_84.isra’: /usr/src/debug/gcc/gcc/gcc/config/riscv/corev.md:2557:1: internal compiler error: Aborted 0x9c9f05 crash_signal /usr/src/debug/gcc/gcc/gcc/toplev.cc:319 0x1690b13 try_combine /usr/src/debug/gcc/gcc/gcc/combine.cc:4772 0x16926e3 combine_instructions /usr/src/debug/gcc/gcc/gcc/combine.cc:1285 0x16926e3 rest_of_handle_combine /usr/src/debug/gcc/gcc/gcc/combine.cc:15116 0x16926e3 execute /usr/src/debug/gcc/gcc/gcc/combine.cc:15160
[Bug c++/119080] New: Poor error message when parameter type is unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119080 Bug ID: 119080 Summary: Poor error message when parameter type is unknown Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: higher.performance.github at gmail dot com Target Milestone: --- If you have a declaration such as void foo(intptr_t); the first error message produced ends up being quite confusing: https://godbolt.org/z/414c6zE8q :1:6: error: variable or field 'foo' declared void 1 | void foo(intptr_t); | ^~~ The subsequent error messages end up clarifying the situation: :1:10: error: 'intptr_t' was not declared in this scope 1 | void foo(intptr_t); | ^~~~ :1:1: note: 'intptr_t' is defined in header ''; this is probably fixable by adding '#include ' +++ |+#include 1 | void foo(intptr_t); but they aren't always immediately visible to users, and users don't necessarily expect subsequent errors to pinpoint problems in previous error messages. Given that the error already first occurs at the parameter and *then* on the function, emitting the errors in the opposite order would be super helpful.
[Bug c++/119076] ICE with Segmentation fault with modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119076 --- Comment #5 from Andrew Pinski --- Created attachment 60631 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60631&action=edit test script This is the testscript which I used to reproduce the ICE
[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #27 from Andrew Clayton --- Thanks for the update!
[Bug c++/119076] ICE with Segmentation fault with modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119076 --- Comment #6 from Andrew Pinski --- Trying to reduce this.
[Bug tree-optimization/117919] [14/15 Regression] ICE: in propagate, at gimple-ssa-sccopy.cc:625 with -O -fno-tree-forwprop -fnon-call-exceptions --param=early-inlining-insns=192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117919 --- Comment #5 from GCC Commits --- The master branch has been updated by Filip Kastl : https://gcc.gnu.org/g:5349aa2accdf34a7bf9cabd1447878aaadfc0e87 commit r15-7779-g5349aa2accdf34a7bf9cabd1447878aaadfc0e87 Author: Filip Kastl Date: Sun Mar 2 06:39:17 2025 +0100 gimple: sccopy: Prune removed statements from SCCs [PR117919] While writing the sccopy pass I didn't realize that 'replace_uses_by ()' can remove portions of the CFG. This happens when replacing arguments of some statement results in the removal of an EH edge. Because of this sccopy can then work with GIMPLE statements that aren't part of the IR anymore. In PR117919 this triggered an assertion within the pass which assumes that statements the pass works with are reachable. This patch tells the pass to notice when a statement isn't in the IR anymore and remove it from it's worklist. PR tree-optimization/117919 gcc/ChangeLog: * gimple-ssa-sccopy.cc (scc_copy_prop::propagate): Prune statements that 'replace_uses_by ()' removed. gcc/testsuite/ChangeLog: * g++.dg/pr117919.C: New test. Signed-off-by: Filip Kastl
[Bug tree-optimization/117919] [14/15 Regression] ICE: in propagate, at gimple-ssa-sccopy.cc:625 with -O -fno-tree-forwprop -fnon-call-exceptions --param=early-inlining-insns=192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117919 Filip Kastl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Filip Kastl --- Should be fixed now.
[Bug c++/119080] Poor error message when parameter type is unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119080 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 16663 ***
[Bug c++/16663] Poor parse error recovery with mispelled type in function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16663 Andrew Pinski changed: What|Removed |Added CC||higher.performance.github@g ||mail.com --- Comment #11 from Andrew Pinski --- *** Bug 119080 has been marked as a duplicate of this bug. ***
[Bug target/119083] New: Remove SSE_FIRST_REG from ix86_class_likely_spilled_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119083 Bug ID: 119083 Summary: Remove SSE_FIRST_REG from ix86_class_likely_spilled_p Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: liuhongt at gcc dot gnu.org Target Milestone: --- Target: x86 SSE_FIRST_REG was added to CLASS_LIKELY_SPILLED_P, which became TARGET_CLASS_LIKELY_SPILLED_P, for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40470 Since RA has been improved and xmm0 is a commonly used register, should SSE_FIRST_REG be removed from ix86_class_likely_spilled_p to improve xmm0 codegen?
[Bug c++/71093] use of pseudo-destructor accepted in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71093 Andrew Pinski changed: What|Removed |Added CC||qurong at ios dot ac.cn --- Comment #8 from Andrew Pinski --- *** Bug 119082 has been marked as a duplicate of this bug. ***
[Bug target/119077] gcc option -mint8 leads to undefined reference to `__builtin_avr_delay_cycles'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119077 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- _delay_ms and _delay_us are not provided by GCC. The problem seems whoever authored them wrongly assumes __builtin_avr_delay_cycles would be always available. Not a GCC bug to me.
[Bug c++/119082] GCC Incorrectly Accepts Explicit Destructor Call for Scalar Type in constexpr Context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119082
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #1 from Andrew Pinski ---
: In function 'int main()':
:12:39: in 'constexpr' expansion of 'test_scope()'
:7:5: error: destroying 'x' outside its lifetime
7 | }
| ^
:5:11: note: declared here
5 | T x{};
| ^
[Bug c++/119076] ICE with Segmentation fault with modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119076
--- Comment #4 from Andrew Pinski ---
here is the full backtrace:
In file included from ./include/nlohmann/json.hpp:60,
of module ./json.hpp, imported at main.cxx:1:
./include/nlohmann/detail/output/serializer.hpp: In instantiation of ‘static
uint8_t
nlohmann::json_abi_v3_11_3::detail::serializer::decode(uint8_t&,
uint32_t&, uint8_t) [with BasicJsonType =
nlohmann::json_abi_v3_11_3::basic_json<>; uint8_t = unsigned char; uint32_t =
unsigned int]’:
./include/nlohmann/detail/output/serializer.hpp:405:27: required from ‘void
nlohmann::json_abi_v3_11_3::detail::serializer::dump_escaped(const
string_t&, bool) [with BasicJsonType =
nlohmann::json_abi_v3_11_3::basic_json<>; string_t =
std::__cxx11::basic_string]’
./include/nlohmann/detail/output/serializer.hpp:140:25: required from ‘void
nlohmann::json_abi_v3_11_3::detail::serializer::dump(const
BasicJsonType&, bool, bool, unsigned int, unsigned int) [with BasicJsonType =
nlohmann::json_abi_v3_11_3::basic_json<>]’
./include/nlohmann/json.hpp:4014:15: required from ‘std::ostream&
nlohmann::json_abi_v3_11_3::operator<<(std::ostream&, const basic_json<>&)’
main.cxx:3:42: required from here
3 | int main() { std::cout << nlohmann::json{}; }
| ^
./include/nlohmann/detail/output/serializer.hpp:902:52: internal compiler
error: Segmentation fault
0x288d94f internal_error(char const*, ...)
/home/apinski/src/upstream-gcc-isel/gcc/gcc/diagnostic-global-context.cc:517
0x1411a0f crash_signal
/home/apinski/src/upstream-gcc-isel/gcc/gcc/toplev.cc:322
0xdb0f9b braced_list_to_string
/home/apinski/src/upstream-gcc-isel/gcc/gcc/c-family/c-common.cc:10144
0xdb1f3f braced_lists_to_strings
/home/apinski/src/upstream-gcc-isel/gcc/gcc/c-family/c-common.cc:10363
0xda32f3 store_init_value(tree_node*, tree_node*, vec**, int)
/home/apinski/src/upstream-gcc-isel/gcc/gcc/cp/typeck2.cc:863
0xb97630 check_initializer
/home/apinski/src/upstream-gcc-isel/gcc/gcc/cp/decl.cc:8023
0xb9bd52 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int,
cp_decomp*)
/home/apinski/src/upstream-gcc-isel/gcc/gcc/cp/decl.cc:9196
0xcf1552 tsubst_stmt
/home/apinski/src/upstream-gcc-isel/gcc/gcc/cp/pt.cc:19033
0xcefc81 tsubst_stmt
/home/apinski/src/upstream-gcc-isel/gcc/gcc/cp/pt.cc:18840
0xcefe1e tsubst_stmt
/home/apinski/src/upstream-gcc-isel/gcc/gcc/cp/pt.cc:19205
0xd15646 tsubst_stmt
/home/apinski/src/upstream-gcc-isel/gcc/gcc/cp/pt.cc:18826
0xd15646 instantiate_body
/home/apinski/src/upstream-gcc-isel/gcc/gcc/cp/pt.cc:27670
0xced9fd instantiate_decl(tree_node*, bool, bool)
/home/apinski/src/upstream-gcc-isel/gcc/gcc/cp/pt.cc:27954
0xd2694b instantiate_pending_templates(int)
/home/apinski/src/upstream-gcc-isel/gcc/gcc/cp/pt.cc:28030
0xbaf1dd c_parse_final_cleanups()
/home/apinski/src/upstream-gcc-isel/gcc/gcc/cp/decl2.cc:5541
0xe1e7b0 c_common_parse_file()
/home/apinski/src/upstream-gcc-isel/gcc/gcc/c-family/c-opts.cc:1397
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/118765] c23 tag matching broken for multiple redeclarations of typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #12 from Hime Haieto ---
This is a good weekend indeed! While I can't say that all is well, this patch
is good progress - at least one of my non-toy sources compiles/works correctly
now with workarounds.
It seems like if you typedef, then redeclare the struct (with or without being
part of a typedef), then you get problems the moment you make a third typedef
(ordering doesn't seem to matter much). Try adding a third copy of the typedef
at the end of the test case you were using:
typedef struct q { int x; } q_t;
struct q { int x; };
typedef struct q { int x; } q_t;
typedef struct q { int x; } q_t;
In fact, you don't even need to declare the struct contents with the typedef -
the following also breaks:
struct q { int x; };
typedef struct q q_t;
struct q { int x; };
typedef struct q q_t;
typedef struct q q_t;
[Bug c++/119076] ICE with Segmentation fault with modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119076 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED
[Bug jit/117047] [15 regression] Segfault in libgccjit garbage collection when compiling GNU Emacs with Native Compilation since r15-571-g1e0ae1f52741f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047 --- Comment #44 from Jakub Jelinek --- In any case, libgccjit should be fixed to use just ggc_internal_alloc instead of ggc_internal_cleared_alloc in the operator new so that one doesn't actually even think of relying on the zero initialization instead of properly constructing the values in the constructors. Because all the previous values are lost at the start of the constructor.
[Bug c/119058] wbN: A suffix for specifying the width of a bit-precise integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119058 --- Comment #6 from Alejandro Colomar --- (In reply to Jakub Jelinek from comment #5) > (In reply to Alejandro Colomar from comment #3) > > Not yet. I commented it yesterday with Aaron Ballman during a break in the > > C Committee meeting, and he was in support for this. So, my intention was > > to > > propose this feature first as an extension in GNU C (where _ExtInt() was > > born), > > _ExtInt was born in clang, not GCC. I meant GNU C as including Clang, not GNU C as GCC. :) > I'd say feel free to implement this on a branch in gcc, as a proof of > concept, you can cite that branch in the paper then, but it should be > upstreamed into GCC only when the paper is approved into C2y. Sounds reasonable. That's what happened with _Countof, and I've liked it.
[Bug middle-end/115871] [14/15 Regression] ICE with declare simd since r14-5057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115871
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:6589eb4efe39545ec7f7e641e1d302c89b260350
commit r15-7769-g6589eb4efe39545ec7f7e641e1d302c89b260350
Author: Jakub Jelinek
Date: Sat Mar 1 09:15:57 2025 +0100
openmp: Fix up simd clone mask argument creation on x86 [PR115871]
The following testcase ICEs since r14-5057.
The Intel vector ABI says that in the ZMM case the masks is passed
in unsigned int or unsigned long long arguments and how many bits in
them and how many of those arguments are is determined by the
characteristic
data type of the function. In the testcase simdlen is 32 and
characteristic
data type is double, so return as well as first argument is passed in 4
V8DFmode arguments and the mask is supposed to be passed in 4 unsigned int
arguments (8 bits in each).
Before the r14-5057 change there was
sc->args[i].orig_type = parm_type;
...
case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_CONSTANT_STEP:
case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_VARIABLE_STEP:
case SIMD_CLONE_ARG_TYPE_VECTOR:
if (INTEGRAL_TYPE_P (parm_type) || POINTER_TYPE_P (parm_type))
veclen = sc->vecsize_int;
else
veclen = sc->vecsize_float;
if (known_eq (veclen, 0U))
veclen = sc->simdlen;
else
veclen
= exact_div (veclen,
GET_MODE_BITSIZE (SCALAR_TYPE_MODE
(parm_type)));
for the argument handling and
if (sc->inbranch)
{
tree base_type = simd_clone_compute_base_data_type (sc->origin, sc);
...
if (INTEGRAL_TYPE_P (base_type) || POINTER_TYPE_P (base_type))
veclen = sc->vecsize_int;
else
veclen = sc->vecsize_float;
if (known_eq (veclen, 0U))
veclen = sc->simdlen;
else
veclen = exact_div (veclen,
GET_MODE_BITSIZE (SCALAR_TYPE_MODE
(base_type)));
for the mask handling. r14-5057 moved this argument creation later and
unified that:
case SIMD_CLONE_ARG_TYPE_MASK:
case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_CONSTANT_STEP:
case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_VARIABLE_STEP:
case SIMD_CLONE_ARG_TYPE_VECTOR:
if (sc->args[i].arg_type == SIMD_CLONE_ARG_TYPE_MASK
&& sc->mask_mode != VOIDmode)
elem_type = boolean_type_node;
else
elem_type = TREE_TYPE (sc->args[i].vector_type);
if (INTEGRAL_TYPE_P (elem_type) || POINTER_TYPE_P (elem_type))
veclen = sc->vecsize_int;
else
veclen = sc->vecsize_float;
if (known_eq (veclen, 0U))
veclen = sc->simdlen;
else
veclen
= exact_div (veclen,
GET_MODE_BITSIZE (SCALAR_TYPE_MODE
(elem_type)));
This is correct for the argument cases (so linear or vector) (though
POINTER_TYPE_P will never appear as TREE_TYPE of a vector), but the
boolean_type_node in there is completely bogus, when using AVX512 integer
masks as I wrote above we need the characteristic data type, not bool,
and bool is strange in that it has bitsize of 8 (or 32 on darwin), while
the masks are 1 bit per lane anyway.
Fixed thusly.
2025-03-01 Jakub Jelinek
PR middle-end/115871
* omp-simd-clone.cc (simd_clone_adjust): For
SIMD_CLONE_ARG_TYPE_MASK
and sc->mask_mode not VOIDmode, set elem_type to the characteristic
type rather than boolean_type_node.
* gcc.dg/gomp/simd-clones-8.c: New test.
[Bug c/119058] wbN: A suffix for specifying the width of a bit-precise integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119058 --- Comment #3 from Alejandro Colomar --- (In reply to Andrew Pinski from comment #2) > Plus why not just use casts? They tend to be dangerous when misplaced or when their type is accidentally wrong. For example, the following could be diagnosed with a suffix, but not with a cast: 10wb3; // doesn't fit the type (_BitInt(3)) 10wb; // valid narrowing conversion(In reply to Andrew Pinski from comment #1) > Is there a proposed C paper for this? Not yet. I commented it yesterday with Aaron Ballman during a break in the C Committee meeting, and he was in support for this. So, my intention was to propose this feature first as an extension in GNU C (where _ExtInt() was born), and later propose it for standardization. > Do you have edits that could be applied to the C23 standard to support this? If you'd like me to prepare an N paper with a diff to the C2y standard to make it more clear what I'm asking to do, I could. But I prefer not proposing for standardization before having it in GNU C; it would be incoherent with my opinion that the standard should not be inventing. So, I'll call the document GNU119058r0, to be clear that it's not officially proposed at the moment, and to not waste an N number for something not proposed.
[Bug middle-end/115871] [14 Regression] ICE with declare simd since r14-5057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115871 Jakub Jelinek changed: What|Removed |Added Summary|[14/15 Regression] ICE with |[14 Regression] ICE with |declare simd since r14-5057 |declare simd since r14-5057 --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c/119058] wbN: A suffix for specifying the width of a bit-precise integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119058 --- Comment #4 from Alejandro Colomar --- I can still show the paper to other members of the C Committee, though, to see their opinion. But I prefer not proposing it officially.
[Bug c/119058] wbN: A suffix for specifying the width of a bit-precise integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119058 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- (In reply to Alejandro Colomar from comment #3) > Not yet. I commented it yesterday with Aaron Ballman during a break in the > C Committee meeting, and he was in support for this. So, my intention was to > propose this feature first as an extension in GNU C (where _ExtInt() was > born), _ExtInt was born in clang, not GCC. I'd say feel free to implement this on a branch in gcc, as a proof of concept, you can cite that branch in the paper then, but it should be upstreamed into GCC only when the paper is approved into C2y.
[Bug jit/117047] [15 regression] Segfault in libgccjit garbage collection when compiling GNU Emacs with Native Compilation since r15-571-g1e0ae1f52741f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #46 from Jakub Jelinek --- Fixed.
[Bug jit/117047] [15 regression] Segfault in libgccjit garbage collection when compiling GNU Emacs with Native Compilation since r15-571-g1e0ae1f52741f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047
--- Comment #45 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8c15a6cefa0d1f8ec12701af1f528f473c33ff6b
commit r15-7770-g8c15a6cefa0d1f8ec12701af1f528f473c33ff6b
Author: Jakub Jelinek
Date: Sat Mar 1 11:22:27 2025 +0100
ggc: Avoid using ATTRIBUTE_MALLOC for allocations that need finalization
[PR117047]
As analyzed by Andrew/David/Richi/Sam in the PR, the reason for the
libgccjit ICE is that there are GC allocations with finalizers and we
still mark ggc_internal_{,cleared_}alloc with ATTRIBUTE_MALLOC, which
to the optimizers hints that nothing will actually read the state
of the objects when they get out of lifetime. The finalizer actually
inspects those though. What actually happens in the testcases is that on
tree expr_size = TYPE_SIZE (expr->get_type ()->as_tree ());
we see that expr->get_type () was allocated using something with malloc
attribute but it doesn't escape and only the type size from it is queried,
so there is no need to store other members of it. Except that it does
escape
in the GC internals. Normal GC allocations are fine, they don't look at
the
data in the allocated objects on "free", but the ones with finalizers
actually
call a function on that object and expect the data to be in there.
So that we don't lose ATTRIBUTE_MALLOC for the common case when no
finalization is needed, the following patch uses the approach used e.g.
for glibc error function which can sometimes be noreturn but at other
times just return normally.
If possible, it uses __attribute__((alias ("..."))) to add an alias
to the function, where one is without ATTRIBUTE_MALLOC and one
(with _no_dtor suffix) is with ATTRIBUTE_MALLOC (note, as this is
C++ and I didn't want to hardcode particular mangling I used an
extern "C" function with 2 aliases to it), and otherwise adds a wrapper
(for the ggc-page/ggc-common case with noinline attribute if possible,
for ggc-none that doesn't matter because ggc-none doesn't support
finalizers).
The *_no_dtor aliases/wrappers are then used in inline functions which
pass unconditional NULL, 0 as the f/s pair.
2025-03-01 Jakub Jelinek
PR jit/117047
* acinclude.m4 (gcc_CHECK_ATTRIBUTE_ALIAS): New.
* configure.ac: Add gcc_CHECK_ATTRIBUTE_ALIAS.
* ggc.h (ggc_internal_alloc): Remove ATTRIBUTE_MALLOC from
overload with finalizer pointer. Call ggc_internal_alloc_no_dtor
in inline overload without finalizer pointer.
(ggc_internal_alloc_no_dtor): Declare.
(ggc_internal_cleared_alloc): Remove ATTRIBUTE_MALLOC from
overload with finalizer pointer. Call
ggc_internal_cleared_alloc_no_dtor in inline overload without
finalizer pointer.
(ggc_internal_cleared_alloc_no_dtor): Declare.
(ggc_alloc): Call ggc_internal_alloc_no_dtor if no finalization
is needed.
(ggc_alloc_no_dtor): Call ggc_internal_alloc_no_dtor.
(ggc_cleared_alloc): Call ggc_internal_cleared_alloc_no_dtor if no
finalization is needed.
(ggc_vec_alloc): Call ggc_internal_alloc_no_dtor if no finalization
is needed.
(ggc_cleared_vec_alloc): Call ggc_internal_cleared_alloc_no_dtor if
no
finalization is needed.
* ggc-page.cc (ggc_internal_alloc): If HAVE_ATTRIBUTE_ALIAS, turn
overload with finalizer into alias to ggc_internal_alloc_ and
rename it to ...
(ggc_internal_alloc_): ... this, make it extern "C".
(ggc_internal_alloc_no_dtor): New alias if HAVE_ATTRIBUTE_ALIAS,
otherwise new noinline wrapper.
* ggc-common.cc (ggc_internal_cleared_alloc): If
HAVE_ATTRIBUTE_ALIAS,
turn overload with finalizer into alias to ggc_internal_alloc_ and
rename it to ...
(ggc_internal_cleared_alloc_): ... this, make it extern "C".
(ggc_internal_cleared_alloc_no_dtor): New alias if
HAVE_ATTRIBUTE_ALIAS, otherwise new noinline wrapper.
* ggc-none.cc (ggc_internal_alloc): If HAVE_ATTRIBUTE_ALIAS, turn
overload with finalizer into alias to ggc_internal_alloc_ and
rename it to ...
(ggc_internal_alloc_): ... this, make it extern "C".
(ggc_internal_alloc_no_dtor): New alias if HAVE_ATTRIBUTE_ALIAS,
otherwise new wrapper.
(ggc_internal_cleared_alloc): If HAVE_ATTRIBUTE_ALIAS, turn
overload
with finalizer into alias to ggc_internal_alloc_ and rename it to
...
(ggc_internal_cleared_alloc_): ... this, make it extern "C".
(ggc_internal_cleared_alloc_no_dtor): New alias if
HAVE_ATTRIBUTE_ALIAS, otherwise new wrapper.
[Bug c++/118981] "_GLOBAL__sub_I.00099_tzdb.cc" defined twice in the assembly output for c++20/tzdb.cc with -fvtable-verify=std (--enable-vtable-verify)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981 --- Comment #50 from Erich Löw --- Q_1 What would happen if saying (just hypothetically) --> All prios in range 0 ... 2^^16 - 1 are allowed --> Imho consequence of removing split in reserved and not-reserved prios. Q_2 Without usage of [[gnu::init_priority(x)] to what prio maps it?
[Bug rtl-optimization/119071] [12/13/14/15 Regression] Miscompile at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119071 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- #c6 at -O2 started with r10-7268-g529ea7d9596b26ba103578eeab448e9862a2d2c5
[Bug target/112465] libgcc: aarch64: lse runtime does not work with big data segments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112465 john henning changed: What|Removed |Added CC||mailboxnotfound at yahoo dot com --- Comment #3 from john henning --- (In reply to Wilco from comment #2) > it is best to use -mcpu=native and > only use -mcmodel=large if there is no other option. For the record if anyone else running large OpenMP programs (such as McCalpin Stream) should find their way here, the first two below work, the last two fail: DOIT="/export/GCC/gcc-14.2.0/bin/gcc -O3 -DSTREAM_ARRAY_SIZE=1073741824 -fopenmp stream.c " $DOIT -mcmodel=large -mcpu=native $DOIT -mcmodel=large -mno-outline-atomics $DOIT -mcpu=native $DOIT -mno-outline-atomics The above use gcc 14.2 for target=aarch64-unknown-linux-gnu configured with --enable-languages=c,c++,fortran --enable-lto plus unmodified stream.c,v 5.10 2013/01/17 16:01:06 mccalpin For both of the failing cases, the symptoms are: stream.c:(.text+0x ): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against `.bss' The above repeats for several nnn, and ends with stream.c:(.text+0x nnn ): additional relocation overflows omitted from the output
[Bug fortran/119074] New: Mismatched arguments for external dummy argument not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119074 Bug ID: 119074 Summary: Mismatched arguments for external dummy argument not caught Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Looking at PR119049, it surprised me that we do not have a formal argument list check for subroutine foo (f) external :: f call f(1) call f(1,2) end subroutine foo which we currently accept without error or warning.
[Bug c++/117787] [C++26] P3247R2 - Deprecating the notion of trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117787 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #2 from Jiang An --- I don't think this paper changed the core language specification at all. It merely deprecates std::is_trivial(v), and the library changes have been implemented in libstdc++.
[Bug libstdc++/119075] New: LWG4140 seems incompletely implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119075 Bug ID: 119075 Summary: LWG4140 seems incompletely implemented Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: de34 at live dot cn Target Milestone: --- As of LWG4140, the following code snippet should be accepted, but libstdc++ is still rejecting it because the private default constructor of std::vector::reference isn't removed yet. https://godbolt.org/z/3bnaqrreW ``` #include #include #include int test1(std::bitset<42>::reference); void test1(std::enable_if); static_assert(std::is_same::value, ""); int test2(std::vector::reference); void test2(std::enable_if); static_assert(std::is_same::value, ""); ``` I think the existence of private or delete default constructor is somehow observable, see also LWG3160 (https://cplusplus.github.io/LWG/issue3160).
[Bug pch/119076] New: ICE with Segmentation fault if using PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119076
Bug ID: 119076
Summary: ICE with Segmentation fault if using PCH
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pch
Assignee: unassigned at gcc dot gnu.org
Reporter: trinxery at firemail dot cc
Target Milestone: ---
Shell to reproduce:
```
mkdir gccbug2
cd gccbug2
git clone --depth=1 'https://github.com/nlohmann/json'
cd json
mkdir build
cd build
cmake -DJSON_BuildTests=Off -DCMAKE_INSTALL_PREFIX=. ..
make -j
make install
echo '#include "./include/nlohmann/json.hpp"\n#include \nint main() {
std::cout << nlohmann::json{}; }' > ./main.cxx
g++-15 -O0 -fmodules-ts './include/nlohmann/json.hpp' -std=c++20 -I'./include/'
g++-15 -v -save-temps -freport-bug -Winvalid-pch -O0 -fmodules-ts './main.cxx'
-std=c++20
```
(Is not reproducible without `-fmodules-ts`, or with g++-14 and g++-13, or
without precompiling `json.hpp`)
Output on machine with `gcc version 15.0.1 20250213 (experimental) [master
r15-7502-g26baa2c09b3] (Debian 15-20250213-1)`:
```
COLLECT_GCC=g++-15
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/15/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 15-20250213-1'
--with-bugurl=file:///usr/share/doc/gcc-15/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust,cobol
--prefix=/usr --with-gcc-major-version-only --program-suffix=-15
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-libstdcxx-backtrace --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/reproducible-path/gcc-15-15-20250213/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/reproducible-path/gcc-15-15-20250213/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver
--enable-checking=yes,extra,rtl --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250213 (experimental) [master r15-7502-g26baa2c09b3]
(Debian 15-20250213-1)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-freport-bug' '-Winvalid-pch' '-O0'
'-fmodules' '-std=c++20' '-foffload-options=-l_GCC_m' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
/usr/libexec/gcc/x86_64-linux-gnu/15/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE ./main.cxx -mtune=generic -march=x86-64
-std=c++20 -Winvalid-pch -freport-bug -fmodules -foffload-options=-l_GCC_m -O0
-fpch-preprocess -fasynchronous-unwind-tables -o a-main.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/15"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/15/include-fixed/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/15/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/15/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/15
/usr/include/x86_64-linux-gnu/c++/15
/usr/include/c++/15/backward
/usr/lib/gcc/x86_64-linux-gnu/15/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-freport-bug' '-Winvalid-pch' '-O0'
'-fmodules' '-std=c++20' '-foffload-options=-l_GCC_m' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
/usr/libexec/gcc/x86_64-linux-gnu/15/cc1plus -fpreprocessed a-main.ii -quiet
-dumpdir a- -dumpbase main.cxx -dumpbase-ext .cxx -mtune=generic -march=x86-64
-O0 -Winvalid-pch -std=c++20 -version -freport-bug -fmodules
-foffload-options=-l_GCC_m -fasynchronous-unwind-tables -o a-main.s
GNU C++20 (Debian 15-20250213-1) version 15.0.1 20250213 (experimental) [master
r15-7502-g26baa2c09b3] (x86_64-linux-gnu)
compiled by GNU C version 15.0.1 20250213 (experimental) [master
r15-7502-g26baa2c09b3], GMP version 6.3.0, MPFR version 4.2.1, MPC version
1.3.1, isl version isl-0.27-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 93a4481bddb607656af83a1985fd9568
In file included from ./include/nlohmann/json.hpp:60,
of module ././include/nlohmann/json.hpp, imported at ./main.cxx:1
[Bug c++/119076] ICE with Segmentation fault with modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119076 Andrew Pinski changed: What|Removed |Added Component|pch |c++ Status|UNCONFIRMED |WAITING Blocks||103524 Last reconfirmed||2025-03-01 Summary|ICE with Segmentation fault |ICE with Segmentation fault |if using PCH|with modules Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- -fmodules-ts causes the use of modules intead of PCH. Can you include the preprocessed source of the following 2 invokations of gcc: g++-15 -O0 -fmodules-ts './include/nlohmann/json.hpp' -std=c++20 -I'./include/' g++-15 -v -save-temps -freport-bug -Winvalid-pch -O0 -fmodules-ts './main.cxx' -std=c++20 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 [Bug 103524] [meta-bug] modules issue
[Bug libstdc++/119075] LWG4140 seems incompletely implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119075 --- Comment #1 from Andrew Pinski --- Reading pr 115098 seems to this on purpose.
[Bug ada/113815] error: there is no applicable operator "*" for a string type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113815
--- Comment #2 from Pascal Pignard ---
No more error but warning still remains with version 14.2:
% gcc -c -gnatv -gnat2022 test_20200613_decl.adb
GNAT 14.2.0
Copyright 1992-2024, Free Software Foundation, Inc.
Compiling: 2020/test_20200613_decl.adb
Source file time stamp: 2022-07-02 16:40:48
Compiled at: 2025-03-01 18:52:02
30. 'Reduce("+", 0)
|
>>> warning: value not in range of type "Roman_Number" defined at line
15 [enabled by default]
>>> warning: Constraint_Error will be raised at run time [enabled by
default]
[Bug other/119052] [15 regression] Uninitialized memory use in selftest::check_line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119052 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:dfdbad87aeb2deff9e13a394659ac7b37173648a commit r15-7772-gdfdbad87aeb2deff9e13a394659ac7b37173648a Author: Jakub Jelinek Date: Sat Mar 1 16:09:07 2025 +0100 input: Fix UB during self-tests [PR119052] As the comment in check_line says: /* get_buffer is not null terminated, but the sscanf stops after a number. */ the buffer is not null terminated, there is line.length () to determine the size of the line. But unlike what the comment says, sscanf actually still requires null terminated string argument, anything else is UB. E.g. glibc when initializing the temporary FILE stream for the string does if (size == 0) end = strchr (ptr, '\0'); and this strchr/rawmemchr is what shows up in valgrind report on cc1/cc1plus doing self-tests. The function is used only in a test with 1000 lines, each containg its number, so numbers from 1 to 1000 inclusive (each time with '\n' separator, but that isn't included in line.length ()). So the function just uses a temporary buffer which can fit numbers from 1 to 1000 as strings with terminating '\0' and runs sscanf on that (why not strtoul?). Furthermore, the caller allocated number of lines * 15 bytes for the string, but 1000\n is 5 bytes, so I think * 5 is more than enough. 2025-03-01 Jakub Jelinek PR other/119052 * input.cc (check_line): Don't call sscanf on non-null terminated buffer, instead copy line.length () bytes from line.get_buffer () to a local buffer, null terminate it and call sscanf on that. Formatting fix. (test_replacement): Just allocate maxline * 5 rather than maxline * 15 bytes for the file. Formatting fix.
[Bug target/114222] gcc.c-torture/execute/builtin-bitops-1.c fails for H8/300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114222 --- Comment #6 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:898f22d15805229a932fff7f22a0a8054e1b9b31 commit r15-7773-g898f22d15805229a932fff7f22a0a8054e1b9b31 Author: Jan Dubiec Date: Sat Mar 1 08:21:16 2025 -0700 [PATCH] H8/300, libgcc: PR target/114222 For HImode call internal ffs() implementation instead of an external one When INT_TYPE_SIZE < BITS_PER_WORD gcc emits a call to an external ffs() implementation instead of a call to "__builtin_ffs()" â see function init_optabs() in /gcc/optabs-libfuncs.cc. External ffs() (which is usually the one from newlib) in turn calls __builtin_ffs() what causes infinite recursion and stack overflow. This patch overrides default gcc bahaviour for H8/300H (and newer) and provides a generic ffs() implementation for HImode. PR target/114222 gcc/ChangeLog: * config/h8300/h8300.cc (h8300_init_libfuncs): For HImode override calls to external ffs() (from newlib) with calls to __ffshi2() from libgcc. The implementation of ffs() in newlib calls __builtin_ffs() what causes infinite recursion and finally a stack overflow. libgcc/ChangeLog: * config/h8300/t-h8300: Add __ffshi2(). * config/h8300/ffshi2.c: New file.
[Bug target/118906] RISC-V: zcf is not implied by zce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118906 --- Comment #1 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:a0d29dd218e7d96f0715360a2ab6fdd8dc9b3446 commit r15-7774-ga0d29dd218e7d96f0715360a2ab6fdd8dc9b3446 Author: Yuriy Kolerov Date: Sat Mar 1 08:35:55 2025 -0700 [PR target/118906] [PATCH v2] RISC-V: Fix a typo in zce to zcf implication zce must imply zcf but this rule was corrupted after refactoring in 9e12010b5e724277ea. This may be observed ater generating an .s file from any source code file with -mriscv-attribute -march=rv32if_zce -mabi=ilp32 -S options. A full march will be presented in arch attribute: rv32i2p1_f2p2_zicsr2p0_zca1p0_zcb1p0_zce1p0_zcmp1p0_zcmt1p0 As you see, zcf is not presented here though f_zce pair is passed in -march. According to The RISC-V Instruction Set Manual: Specifying Zce on RV32 with F includes Zca, Zcb, Zcmp, Zcmt and Zcf. PR target/118906 gcc/ChangeLog: * common/config/riscv/riscv-common.cc: fix zce to zcf implication. gcc/testsuite/ChangeLog: * gcc.target/riscv/attribute-zce-1.c: New test. * gcc.target/riscv/attribute-zce-2.c: New test. * gcc.target/riscv/attribute-zce-3.c: New test. * gcc.target/riscv/attribute-zce-4.c: New test.
[Bug target/118906] RISC-V: zcf is not implied by zce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118906 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law --- Fixed by Yuriy's patch on the trunk.
[Bug other/119052] [15 regression] Uninitialized memory use in selftest::check_line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119052 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/119073] New: [14/15 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:911 with temporary vector in range-for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119073
Bug ID: 119073
Summary: [14/15 Regression] ICE in cp_gimplify_expr, at
cp/cp-gimplify.cc:911 with temporary vector in
range-for
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: philipp at fent dot de
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/fYjYreWaa
The following program generates an ICE on trunk, but compiles on 14.2:
#include
int main() {
for (auto i : (true ? std::vector{1, 2} : std::vector{2, 1})) {
}
}
Stack trace:
: In function 'int main()':
:4:31: internal compiler error: in cp_gimplify_expr, at
cp/cp-gimplify.cc:911
4 |for (auto i : (true ? std::vector{1, 2} : std::vector{2,
1})) {
| ^
0x2917fc5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x292ef96 internal_error(char const*, ...)
???:0
0xacfd5e fancy_abort(char const*, int, char const*)
???:0
0x110920b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0x110d7da gimplify_stmt(tree_node**, gimple**)
???:0
0x110b8f9 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0x110d7da gimplify_stmt(tree_node**, gimple**)
???:0
0x110b3b7 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0x110b398 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0x1109e52 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0x110b5e5 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0x110d7da gimplify_stmt(tree_node**, gimple**)
???:0
0x110acab gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0x110d7da gimplify_stmt(tree_node**, gimple**)
???:0
0x110b5fc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0x110d7da gimplify_stmt(tree_node**, gimple**)
???:0
0x110b5fc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0x110d7da gimplify_stmt(tree_node**, gimple**)
???:0
0x110acab gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0x1113b36 gimplify_body(tree_node*, bool)
???: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++/119073] [15 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:911 with temporary vector in range-for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119073 Sam James changed: What|Removed |Added Summary|[14/15 Regression] ICE in |[15 Regression] ICE in |cp_gimplify_expr, at|cp_gimplify_expr, at |cp/cp-gimplify.cc:911 with |cp/cp-gimplify.cc:911 with |temporary vector in |temporary vector in |range-for |range-for Keywords||ice-on-valid-code Target Milestone|--- |15.0
[Bug rtl-optimization/119071] [12/13/14/15 Regression] Miscompile at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119071 --- Comment #9 from Jeffrey A. Law --- WRT c#8. That would be a bit of a surprise. In *theory* it just allowed us to remove reg->reg moves when the source and destination where the same reg. So if that caused a regression I suspect it was just latent.
[Bug c++/119073] [15 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:911 with temporary vector in range-for with -std=c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119073 --- Comment #3 from Philipp Fent --- Thanks for mentioning it Andrew, this indeed seems to be related to a behavioral change in range-for lifetimes in C++23. I found commit 650e915 from Jakub Jelinek that implements the new behavior. There's also the -fno-range-for-ext-temps flag that switches back to the old behavior where the ICE does not happen. So the following causes the ICE: g++ crash.cpp -std=c++23 Those are ok though: g++ crash.cpp -std=c++20 g++ crash.cpp -std=c++23 -fno-range-for-ext-temps
[Bug c++/119073] [15 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:911 with temporary vector in range-for with -std=c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119073 Andrew Pinski changed: What|Removed |Added Summary|[15 Regression] ICE in |[15 Regression] ICE in |cp_gimplify_expr, at|cp_gimplify_expr, at |cp/cp-gimplify.cc:911 with |cp/cp-gimplify.cc:911 with |temporary vector in |temporary vector in |range-for |range-for with -std=c++23 --- Comment #1 from Andrew Pinski --- Note -std=c++23 is required ...
[Bug c++/110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338 Bug 110338 depends on bug 117787, which changed state. Bug 117787 Summary: [C++26] P3247R2 - Deprecating the notion of trivial types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117787 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/117787] [C++26] P3247R2 - Deprecating the notion of trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117787 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |15.0 Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- https://gcc.gnu.org/g:6c41a912f5e654a1b6f7cf8d6b23f00d8612988c commit r15-6063-g6c41a912f5e654a1b6f7cf8d6b23f00d8612988c Author: Giuseppe D'Angelo Date: Mon Dec 9 01:28:08 2024 +0100 libstdc++: deprecate is_trivial for C++26 (P3247R2) This actually implements P3247R2 by deprecating the is_trivial type trait. libstdc++-v3/ChangeLog: * include/std/type_traits: Deprecate is_trivial and is_trivial_v. * include/experimental/type_traits: Suppress the deprecation warning. * testsuite/20_util/is_trivial/requirements/explicit_instantiation.cc: Amend the test to suppress the deprecation warning. * testsuite/20_util/is_trivial/requirements/typedefs.cc: Likewise. * testsuite/20_util/is_trivial/value.cc: Likewise. * testsuite/20_util/variable_templates_for_traits.cc: Likewise. * testsuite/experimental/type_traits/value.cc: Likewise. * testsuite/18_support/max_align_t/requirements/2.cc: Update the test with P3247R2's new wording. Signed-off-by: Giuseppe D'Angelo
[Bug c++/119073] [15 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:911 with temporary vector in range-for with -std=c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119073 --- Comment #2 from Andrew Pinski --- Next time please mention the full command line which is causing the ICE and NOT just give a link to godbolt for the command line.
[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943 --- Comment #11 from Manuel López-Ibáñez --- I think having -Wignored-pragma-omp would be useful: 1. It is useful to have a warning that warns that you need to use -fopenmp for #pragma omp to have an effect. 2. However, it is very common to want to compile code with and without -fopenmp. 3. Using -Wno-unknown-pragma means that any typos in pragmas (#pragma oomp) will not be detected. -Wignored-pragma-omp could say something like: warming: ‘#pragma omp for’ ignored without '-fopenmp'
[Bug tree-optimization/100922] CSE leads to fully redundant (back to back) zero-extending loads of the same thing in a loop, or a register copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100922 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jeffrey A. Law --- The trunk converts the 2nd load into a simple reg->reg copy, as it should. So fixed.
[Bug target/99089] unnecessary zero extend before AND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99089 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jeffrey A. Law --- Fixed on the trunk. Didn't chase down precisely when.
[Bug c++/119073] [15 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:911 with temporary vector in range-for with -std=c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119073 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-03-01 Ever confirmed|0 |1 --- Comment #5 from Andrew Pinski --- Confirmed.
[Bug middle-end/19466] [meta-bug] bit-fields are non optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19466 Bug 19466 depends on bug 97747, which changed state. Bug 97747 Summary: [12/13/14/15 Regression] missed combine opt with logical ops after zero extended load https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97747 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/119073] [15 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:911 with temporary vector in range-for with -std=c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119073 --- Comment #4 from Andrew Pinski --- Created attachment 60624 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60624&action=edit Reduced testcase
[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 --- Comment #26 from Sam James --- Jakub's revised patch: https://inbox.sourceware.org/gcc-patches/Z63vQc7tBvolrk27@tucnak/
[Bug c++/119073] [15 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:911 with temporary vector in range-for with -std=c++23 since r15-7481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119073 Jakub Jelinek changed: What|Removed |Added CC|jakub at redhat dot com|jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Summary|[15 Regression] ICE in |[15 Regression] ICE in |cp_gimplify_expr, at|cp_gimplify_expr, at |cp/cp-gimplify.cc:911 with |cp/cp-gimplify.cc:911 with |temporary vector in |temporary vector in |range-for with -std=c++23 |range-for with -std=c++23 ||since r15-7481 --- Comment #6 from Jakub Jelinek --- Started with r15-7481-g0d2a5f3cb715fd95f1fa4a13b5d67c7eea28f178
[Bug c++/119073] [15 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:911 with temporary vector in range-for with -std=c++23 since r15-7481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119073 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug rtl-optimization/92656] The zero_extend insn can't be eliminated in the combine pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Jeffrey A. Law --- Fixed, on the trunk. But I didn't chase down precisely what change fixed it.
[Bug middle-end/71942] [ARM] Zero-extending whats allready zero-extended even when -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71942 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jeffrey A. Law --- Fixed on the trunk, but I'm not sure when.
[Bug tree-optimization/97747] [12/13/14/15 Regression] missed combine opt with logical ops after zero extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97747 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Jeffrey A. Law --- Gives good code on the trunk. But I didn't chase down precisely when it got fixed.
[Bug c++/119076] ICE with Segmentation fault with modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119076 --- Comment #2 from trinxery at firemail dot cc --- Created attachment 60626 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60626&action=edit preprocessed json.hpp
[Bug c++/119076] ICE with Segmentation fault with modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119076
--- Comment #3 from trinxery at firemail dot cc ---
and main.cxx is:
# 0 "./main.cxx"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "./main.cxx"
import "././include/nlohmann/json.hpp" [[__translated]];
# 1 "/usr/include/c++/15/iostream" 1 3
# 40 "/usr/include/c++/15/iostream" 3
# 1 "/usr/include/c++/15/bits/requires_hosted.h" 1 3
# 41 "/usr/include/c++/15/iostream" 2 3
# 1 "/usr/include/x86_64-linux-gnu/c++/15/bits/c++config.h" 1 3
# 43 "/usr/include/c++/15/iostream" 2 3
# 1 "/usr/include/c++/15/ostream" 1 3
# 44 "/usr/include/c++/15/iostream" 2 3
# 1 "/usr/include/c++/15/istream" 1 3
# 45 "/usr/include/c++/15/iostream" 2 3
# 46 "/usr/include/c++/15/iostream" 3
namespace std __attribute__ ((__visibility__ ("default")))
{
# 64 "/usr/include/c++/15/iostream" 3
extern istream cin;
extern ostream cout;
extern ostream cerr;
extern ostream clog;
extern wistream wcin;
extern wostream wcout;
extern wostream wcerr;
extern wostream wclog;
# 84 "/usr/include/c++/15/iostream" 3
__extension__ __asm (".globl _ZSt21ios_base_library_initv");
}
# 3 "./main.cxx" 2
# 3 "./main.cxx"
int main() { std::cout << nlohmann::json{}; }
[Bug jit/117047] [15 regression] Segfault in libgccjit garbage collection when compiling GNU Emacs with Native Compilation since r15-571-g1e0ae1f52741f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047 --- Comment #47 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ff38712bcba97ff9cba168a4e864c5a8ac453b7f commit r15-7776-gff38712bcba97ff9cba168a4e864c5a8ac453b7f Author: Jakub Jelinek Date: Sat Mar 1 20:48:16 2025 +0100 ggc: Fix up ggc_internal_cleared_alloc_no_dtor [PR117047] Apparently I got one of the !HAVE_ATTRIBUTE_ALIAS fallbacks wrong. It compiled with a warning: ../../gcc/ggc-common.cc: In function 'void* ggc_internal_cleared_alloc_no_dtor(size_t, void (*)(void*), size_t, size_t)': ../../gcc/ggc-common.cc:154:44: warning: unused parameter 'size' [-Wunused-parameter] 154 | ggc_internal_cleared_alloc_no_dtor (size_t size, void (*f)(void *), | ~~~^~~~ and obviously didn't work right (always allocated 0-sized objects). Fixed thusly. 2025-03-01 Jakub Jelinek PR jit/117047 * ggc-common.cc (ggc_internal_cleared_alloc_no_dtor): Pass size rather than s as the first argument to ggc_internal_cleared_alloc.
[Bug target/119077] New: gcc option -mint8 leads to undefined reference to `__builtin_avr_delay_cycles'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119077 Bug ID: 119077 Summary: gcc option -mint8 leads to undefined reference to `__builtin_avr_delay_cycles' Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ul...@t-online.de Target Milestone: --- Created attachment 60625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60625&action=edit example If the avr-gcc option -mint8 is used with a _delay_ms() or _delay_us() function, ld exits with the error-message "undefined reference to `__builtin_avr_delay_cycles'". GCC version and build flags: $ avr-gcc -v Using built-in specs. Reading specs from /usr/local/avr/lib/gcc/avr/14.2.0/device-specs/specs-avr2 COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/usr/local/avr/libexec/gcc/avr/14.2.0/lto-wrapper Target: avr Configured with: ../configure --prefix=/usr/local/avr --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2 Thread model: single Supported LTO compression algorithms: zlib gcc version 14.2.0 (GCC) Compilation: avr-gcc -mint8 -Os -fwhole-program -mrelax -Wall -Wextra --save-temps -mmcu=avr25 -DF_CPU=100 main.c -o main.elf Error message: /usr/local/avr/lib/gcc/avr/14.2.0/../../../../avr/bin/ld: main.elf-main.o: in function `main': main.c:(.text.startup+0x4): undefined reference to `__builtin_avr_delay_cycles' collect2: error: ld returned 1 exit status
[Bug c/118061] [15 regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in tagged_types_tu_compatible_p, at c/c-typeck.cc:1946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118061 --- Comment #3 from uecker at gcc dot gnu.org --- Created attachment 60627 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60627&action=edit patch Patch adding checking for errors.
[Bug c/118765] c23 tag matching broken for multiple redeclarations of typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765 --- Comment #11 from uecker at gcc dot gnu.org --- Created attachment 60628 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60628&action=edit patch Tentative fix.
[Bug c++/118981] "_GLOBAL__sub_I.00099_tzdb.cc" defined twice in the assembly output for c++20/tzdb.cc with -fvtable-verify=std (--enable-vtable-verify)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981 --- Comment #51 from Jonathan Wakely --- (In reply to Erich Löw from comment #50) > Q_1 > What would happen if saying (just hypothetically) > --> All prios in range 0 ... 2^^16 - 1 are allowed > --> Imho consequence of removing split in reserved and not-reserved prios. It would be impossible for the compiler and standard library to safely implement the requirements of the C++ standard. There's a reason we have a reserved range that user code is not allowed to use. If users were allowed to use 1-101 then we'd need to reserve negative values for the standard library to use. > Q_2 > Without usage of [[gnu::init_priority(x)] to what prio maps it? See Bug 65115
