[Bug other/120905] Unable to compile GCC 6.5.0 with GCC 5.5.0 on Solaris 10 SPARC (linker error?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905 --- Comment #13 from TCH --- @Eric Botcazou: You were right: using the GNU assembler, but not using the GNU linker did the trick. (I tried to compile GCC6 without using neither of the GNU assembler nor the linker before, but then the assembler errored during compilation.) Thank you very much, finally i've managed to compile GCC6. I had to fix some errors i've encountered in the meantime (along with the 'rlim_t' bug from ticket #86615 [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86615]), but in the end, it did work. I attached a patch which fixes these problems. So, by doing: tar -xzf gcc-6.5.0.tar.gz cd gcc-6.5.0 patch -p0 < ../gcc6_solaris10.patch cd .. mkdir gcc6 cd gcc6 ../gcc-6.5.0/configure --prefix=/opt/gcc6 --build=sparc-sun-solaris2.10 --with-gnu-as --enable-shared --disable-nls --enable-languages=c,c++,objc --with-gmp=/opt/csw --with-mpfr=/opt/csw --with-mpc=/opt/csw export LD_LIBRARY_PATH="$LD_LIBRARY_PATH"':/opt/csw/lib/' make make install GCC 6.5 compiles with GCC 5.5 roughly in 31 hours on a Sun Blade 100. Thank you again.
[Bug target/120782] RISC-V: vector-strict-align not working for spec17 521 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120782
--- Comment #8 from Robin Dapp ---
The vlse comes from a vec_duplicate:V2DI that has a reg pointing to a
"real(kind=4)", so a float.
What's interesting, though, is that the MEM is supposedly 64-bit aligned (see
below, A64).
(insn 285 282 287 13 (set (reg:V2DI 474)
(vec_duplicate:V2DI (mem:DI (reg:DI 202 [ ivtmp.4273 ]) [0 MEM
[(real(kind=4) *)_173]+0 S8 A64])))
"module_ra_rrtm.fppized.f90":5172:83 3602 {*vec_duplicatev2di}
(nil))
We expand the vec_duplicate as vlse64.v eventually. I audited several other
uses of vlse for broadcast and they appear safe (at first sight) to me. There
is one split where we create a new stack slot for broadcasting a 64-bit value
on rv32 but even that should be ok.
So just from this issue here I'd be wary to unconditionally require
TARGET_VECTOR_MISALIGN_SUPPORTED for zero-stride broadcast.
I'm not very accustomed with the alignment attributes of a MEM but shouldn't
they be correct/reliable? Guess I need to dig some more but from my current
understanding I wouldn't rule out a frontend/middle-end issue either.
[Bug c/120965] New: gcc 14.3 aarch64 be failed with pr78542.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120965
Bug ID: 120965
Summary: gcc 14.3 aarch64 be failed with pr78542.c
Product: gcc
Version: 14.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hanwei62 at huawei dot com
Target Milestone: ---
target: aarch64 big-endian
compile option: -O0
Hi, i found gcc 14.3 could not pass pr78542.c
souce code:
/* { dg-do run } */
/* { dg-additional-options "-w -Wno-psabi" } */
#include
typedef unsigned V __attribute__ ((vector_size (16)));
V
foo (unsigned x, V v)
{
do {
v %= x;
x = 1;
} while (v[1]);
return v;
}
int
main ()
{
V x = foo (5, (V) { 0, 1 }); //{0, 1, 0, 0}
printf("x[0]: %d, x[1]: %d, x[2]: %d, x[3]: %d\n", x[0], x[1], x[2], x[3]);
if (x[0] || x[1] || x[2] || x[3])
__builtin_abort();
return 0;
}
qemu result
gcc 14.3: x[0]: 1, x[1]: 0, x[2]: 0, x[3]: 0
gcc 7.3: x[0]: 0, x[1]: 0, x[2]: 0, x[3]: 0
When I examined the assembly code, I found that the issue might lie with the
zip1 instruction. GCC 14.3 little endian is ok with pr78542.c。It is possible
that the GCC 14.3 code generation phase did not adapt the zip1 instruction for
big-endian systems.
https://godbolt.org/z/T9qx1ve6v
thanks
[Bug c/120964] New: aarch64 be failed with pr78542.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120964
Bug ID: 120964
Summary: aarch64 be failed with pr78542.c
Product: gcc
Version: 14.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hanwei62 at huawei dot com
Target Milestone: ---
target: aarch64 big-endian
compile option: -O0
Hi, i found gcc 14.3 could not pass pr78542.c
souce code:
/* { dg-do run } */
/* { dg-additional-options "-w -Wno-psabi" } */
#include
typedef unsigned V __attribute__ ((vector_size (16)));
V
foo (unsigned x, V v)
{
do {
v %= x;
x = 1;
} while (v[1]);
return v;
}
int
main ()
{
V x = foo (5, (V) { 0, 1 }); //{0, 1, 0, 0}
printf("x[0]: %d, x[1]: %d, x[2]: %d, x[3]: %d\n", x[0], x[1], x[2], x[3]);
if (x[0] || x[1] || x[2] || x[3])
__builtin_abort();
return 0;
}
qemu result
gcc 14.3: x[0]: 1, x[1]: 0, x[2]: 0, x[3]: 0
gcc 7.3: x[0]: 0, x[1]: 0, x[2]: 0, x[3]: 0
When I examined the assembly code, I found that the issue might lie with the
zip1 instruction. GCC 14.3 little endian is ok with pr78542.c。It is possible
that the GCC 14.3 code generation phase did not adapt the zip1 instruction for
big-endian systems.
https://godbolt.org/z/T9qx1ve6v
thanks
[Bug target/120782] RISC-V: vector-strict-align not working for spec17 521 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120782 --- Comment #7 from Robin Dapp --- Ok, I was able to reproduce it with r15-9904-g2498cbbcdb23da.
[Bug bootstrap/56954] Bootstrap failure: ./auto-host.h:1994:16: error: declaration does not declare anything [-fpermissive]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56954 TCH changed: What|Removed |Added CC||tch at protonmail dot com --- Comment #5 from TCH --- Can be fixed by changing '#define rlim_t long' to 'typedef unsigned long long rlim_t;', see bug #86615 for the details.
[Bug other/120905] Unable to compile GCC 6.5.0 with GCC 5.5.0 on Solaris 10 SPARC (linker error?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905 --- Comment #15 from TCH --- I'll try to recompile GCC 6.5 with GCC 5.5 again, but this time not with just '--with-gnu-as', buth with also '--with-as=/usr/local/bin/as'. Perhaps that will fix this.
[Bug target/118891] [14/15/16 regression] gcc 14 fails to build from source on aarch64_be: "error: ‘dynamic_cast’ not permitted with ‘-fno-rtti’"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891 Sam James changed: What|Removed |Added CC||hanwei62 at huawei dot com --- Comment #25 from Sam James --- *** Bug 120964 has been marked as a duplicate of this bug. ***
[Bug target/120965] gcc 14.3 aarch64 be failed with pr78542.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120965 Sam James changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Sam James --- rsandifo's fixes for PR118891 should sort this, he has one for zip1 already *** This bug has been marked as a duplicate of bug 118891 ***
[Bug target/118891] [14/15/16 regression] gcc 14 fails to build from source on aarch64_be: "error: ‘dynamic_cast’ not permitted with ‘-fno-rtti’"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891 --- Comment #26 from Sam James --- *** Bug 120965 has been marked as a duplicate of this bug. ***
[Bug c/120964] aarch64 be failed with pr78542.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120964 Sam James changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Sam James --- rsandifo's fixes for PR118891 should sort this, he has one for zip1 already *** This bug has been marked as a duplicate of bug 118891 ***
[Bug rtl-optimization/101882] [16 Regression] combine vs. insn with earlyclobber and input and output set to a hard register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed|2021-08-12 00:00:00 |2025-7-5
Component|target |rtl-optimization
CC||chenglulu at loongson dot cn,
||xen0n at gentoo dot org,
||xry111 at gcc dot gnu.org
Target|powerpc |powerpc, loongarch64
Summary|modulus with input and |[16 Regression] combine vs.
|output set to a hard|insn with earlyclobber and
|register|input and output set to a
||hard register
Keywords||ice-on-valid-code,
||testsuite-fail
--- Comment #13 from Xi Ruoyao ---
I'm almost sure this is causing
gcc.target/loongarch/bitwise-shift-reassoc-clobber.c ICE in GCC 16:
bitwise-shift-reassoc-clobber.c:12:1: error: unable to generate reloads for
impossible constraints:
12 | }
| ^
(insn 12 10 15 2 (set (reg/v:DI 23 $r23 [ x ])
(sign_extend:DI (plus:SI (subreg:SI (and:DI (ashift:DI (reg/v:DI 23
$r23 [ x ])
(const_int 3 [0x3]))
(const_int 2208 [0x8a0])) 0)
(reg:SI 23 $r23 [ x ]
"bitwise-shift-reassoc-clobber.c":11:7 272 {and_alsl_reversesi_extended}
(nil))
We get:
Trying 10 -> 12:
10: r91:DI=sign_extend($r23:DI<<0x3&0x8a0#0+$r23:SI)
REG_DEAD $r23:DI
12: $r23:DI=r91:DI
REG_DEAD r91:DI
Successfully matched this instruction:
(set (reg/v:DI 23 $r23 [ x ])
(sign_extend:DI (plus:SI (subreg:SI (and:DI (ashift:DI (reg/v:DI 23 $r23 [
x ])
(const_int 3 [0x3]))
(const_int 2208 [0x8a0])) 0)
(reg:SI 23 $r23 [ x ]
allowing combination of insns 10 and 12
which violates the earlyclobber in _alsl_reversesi_extended:
[(set (match_operand:DI 0 "register_operand" "=&r")
(sign_extend:DI
(plus:SI
(subreg:SI
(any_bitwise:DI
(ashift:DI
(match_operand:DI 1 "register_operand" "r0")
(match_operand:SI 2 "const_immalsl_operand" ""))
(match_operand:DI 3 "const_int_operand" "i"))
0)
(match_operand:SI 4 "register_operand" "r"]
[Bug libstdc++/120967] New: std::format produces incorrect results when printing large floating point numbers when using the alternate flag and precision set to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120967
Bug ID: 120967
Summary: std::format produces incorrect results when printing
large floating point numbers when using the alternate
flag and precision set to 0
Product: gcc
Version: 14.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dominick.allen1989 at gmail dot com
Target Milestone: ---
Created attachment 61806
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61806&action=edit
Bug reproducing input file
When printing using format specifications, be it std::print or std::format, the
use of the alternate flag with a precision of 0 produces incorrect results
where the decimal point is off by one, and a leading null terminating byte is
present. The transition point for a suitably large number happens to be
`std::numeric_limits::max() / exp2(512 + 64 + 16 + 8 + 2)`, where after
that point the correct behavior is present. This is only the case for
libstdc++; clang only reproduces this behavior if it is not configured to use
libc++, in which case it produces correct results.
```
#include
#include
#include
#include
#include
#include
void demoBug(double value) {
std::print("Printing {:e} with std::print and std::format\n", value);
std::print("With std::print\n{0:#.0f}\n{0:f}\n", value);
std::print("With std::format\n");
auto output1 = std::format("{:#.0f}\n", value);
auto output2 = std::format("{:f}\n", value);
std::cout << output1;
std::cout << std::format("{:f}\n", value);
std::print("The first byte of output1 is {:#X}\n", output1[0]);
std::print("The first byte of output2 is {:#X}\n", output2[0]);
}
int main() {
demoBug(std::numeric_limits::max());
std::print("Printing {:e} printf\n", std::numeric_limits::max());
printf("%#010.0f\n%f\n", std::numeric_limits::max(),
std::numeric_limits::max());
demoBug(std::numeric_limits::max() /
exp2(512 + 64 + 16 + 8 + 2));
demoBug(std::numeric_limits::max() /
exp2(512 + 64 + 16 + 8 + 2 + 1));
return 0;
}
```
Output:
```
libfud@localhost ~/Documents/bug_reports/format $ g++ -std=c++23 main.cpp -o
format_float_fixed && ./format_float_fixed
Printing 1.797693e+308 with std::print and std::format
With std::print
17976931348623157081452742373170435679807056752584499659891747680315726078002853876058955863276687817154045895351438246423432132688946418276846754670353751698604991057655128207624549009038932894407586850845513394230458323690322294816580855933212334827479782620414472316873817718091929988125040402618412485836.8
179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
With std::format
17976931348623157081452742373170435679807056752584499659891747680315726078002853876058955863276687817154045895351438246423432132688946418276846754670353751698604991057655128207624549009038932894407586850845513394230458323690322294816580855933212334827479782620414472316873817718091929988125040402618412485836.8
179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
The first byte of output1 is 0X0
The first byte of output2 is 0X31
Printing 1.797693e+308 printf
179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.
179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
Printing 1.083074e+127 with std::print and std::format
With std::print
1083074099265943184277437802660630803713451676954622548041022082071609068148274766550887916516477217352904724481640675010622259.2
10830740992659431842774378026606308037134516769546225480410220820716090681482747665508879165164772173529047244816406750106222592.00
With std::format
1083074099265943184277437802660630803713451676954622548041022082071609068148274766550887916516477217352904724481640675010622259.2
10830740992659431842774378026606308037134516769
[Bug rtl-optimization/101882] [16 Regression] combine vs. insn with earlyclobber and input and output set to a hard register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #14 from Segher Boessenkool ---
(match_operand:DI 1 "register_operand" "r0")
That means either a general register ("r"), or the same thing as operand 0
(that's what "0" means)!
So the backend explicitly allows it here.
[Bug c/120921] gimple verifier (and gimple FE) accepts CST on LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120921
--- Comment #3 from Andrew Pinski ---
So looking into this further, the problem is only with
verify_gimple_assign_single where the issue is.
Another testcase:
```
void __GIMPLE b(int t, int t1) {
&t1 = &t;
}
```
And another one:
```
#define vector __attribute__((vector_size(sizeof(int
typedef vector int vi;
void __GIMPLE b(vi t, vi t1) {
_Literal(vi){0} = _Literal(vi){1};
}
void __GIMPLE c(vi t, vi t1) {
_Literal(vi){t} = _Literal(vi){t1};
}
```
[Bug bootstrap/86615] gcc build failure: auto-host.h error: declaration does not declare anything [-fpermissive]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86615
TCH changed:
What|Removed |Added
CC||tch at protonmail dot com
--- Comment #3 from TCH ---
This bug can be fixed by changing '#define rlim_t long' to 'typedef unsigned
long long rlim_t;' or 'typedef ulonglong_t rlim_t;', if you include the header
'ulonglong_t' is defined in.
Changing it to '#define rlim_t unsigned long long' will not work, it will just
throw a different error ("multiple definitions") and 'typedef'-ing it to
anything else than 'unsigned long long' (or 'ulonglong_t') will throw an error
that it is different than the previous declaration somewhere, what defined it
as 'ulonglong_t'.
So, by changing the line
$as_echo "#define rlim_t long" >>confdefs.h
in 'gcc-6.X.0/gcc/configure' to
$as_echo "typedef unsigned long long rlim_t;" >>confdefs.h
this error is a goner.
A patch which fixes this and the other errors i ran into when compiling GCC
6.5.0 with GCC 5.5.0 on Solaris 10 SPARC is available under the bugticket
#120905: [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905]
[Bug target/120870] [16 regression] CPython miscompiled with preserve_none and CFLAGS="-O2 -march=znver2 -ggdb3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870 Sam James changed: What|Removed |Added Target Milestone|--- |16.0 Keywords||needs-reduction Summary|CPython miscompiled with|[16 regression] CPython |preserve_none and |miscompiled with |CFLAGS="-O2 -march=znver2 |preserve_none and |-ggdb3" |CFLAGS="-O2 -march=znver2 ||-ggdb3"
[Bug other/120905] Unable to compile GCC 6.5.0 with GCC 5.5.0 on Solaris 10 SPARC (linker error?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905 --- Comment #12 from TCH --- Created attachment 61805 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61805&action=edit Fixes all of the errors of compiling GCC6 on Solaris 10 SPARC The fix of the 'NAN' and 'INFINITY' problem is an ugly 'union' hack, where the hexa values of 'NaN' and 'inf' are directly fed to an 'union.uint64_t' and pulled from the 'union.double', but it does work. It also fixes the error from bug #86615, and the errors of extern char *strstr (const char *, const char *) and extern const char *strsignal (int) are being different from their previous declarations of extern const char *strstr (const char *, const char *) and extern char *strsignal (int)
[Bug tree-optimization/120948] Cannot detect potential division-by-zero when numerator is 1 and denominator is variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120948 --- Comment #6 from Andrew Pinski --- (In reply to Richard Biener from comment #5) > But of course if we'd want to expose > this to the user it might instead be > > x = __builtin_assume (x != 0); I dont see why we want to expose this to the user with the builtin as there is already the assume attribute which we already translate to if(...) __builtin_unreachable(); Which we could translate into the internal assume ...
[Bug other/120905] Unable to compile GCC 6.5.0 with GCC 5.5.0 on Solaris 10 SPARC (linker error?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #14 from TCH ---
The resulting binary however has a problem: it tries to use the non-GNU
assembler under '/usr/ccs/bin/as', instead of using the GNU assembler under
'/usr/local/as', despite being configured to use the GNU assembler and thus,
any compilation with it will fail:
/usr/ccs/bin/as: error: unknown option '3'
/usr/ccs/bin/as: error: unknown option '2'
usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s]
[-S] [-K {pic,PIC}] [-o objfile] [-L] [-T]
[-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
[-m [-Ym,path]] [-n] [-ul] [-xF]
[-m32] [-m64]
[-xarch={v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis,
sparcvis2,sparcfmaf,sparcima}]
[-xcode={pic13,pic32}] file.s...
This of course can be workarounded by backing up '/usr/ccs/bin/as' and
symlinking '/usr/local/bin/as' to there, but it should work without this.
Note: '/usr/local/bin' has higher priority in '$PATH' than '/usr/ccs/bin'.
Further note: to use it, first
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH"':/opt/csw/lib/'
needs to be done, or it will die:
ld.so.1: cc1: fatal: libmpc.so.3: open failed: No such file or directory
gcc: internal compiler error: Killed (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
This also means, that this exporting line must be moved from behind to before
the '../configure' line, if one tries to compile GCC6 with itself.
[Bug c++/120942] internal compiler error happend when i lose include some file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120942 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Andrew Pinski --- As mentioned the released version of GCC works so closing as works for me.
[Bug c/120966] ++/-- for short still uses unsigned types even if sizeof(int) == sizeof(short)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120966
Andrew Pinski changed:
What|Removed |Added
Summary|-Waggressive-loop-optimizat |++/-- for short still uses
|ions warns for int but not |unsigned types even if
|for short overflow |sizeof(int) ==
||sizeof(short)
Status|UNCONFIRMED |NEW
Keywords||diagnostic,
||missed-optimization
Ever confirmed|0 |1
Last reconfirmed||2025-07-05
Target||sizeof(int)==sizeof(short)
--- Comment #2 from Andrew Pinski ---
The issue is the C/C++ shared gimplifier does:
```
case PREINCREMENT_EXPR:
case PREDECREMENT_EXPR:
case POSTINCREMENT_EXPR:
case POSTDECREMENT_EXPR:
{
tree type = TREE_TYPE (TREE_OPERAND (*expr_p, 0));
if (INTEGRAL_TYPE_P (type) && c_promoting_integer_type_p (type))
{
if (!TYPE_OVERFLOW_WRAPS (type))
type = unsigned_type_for (type);
return gimplify_self_mod_expr (expr_p, pre_p, post_p, 1, type);
}
break;
}
```
c_promoting_integer_type_p returns true even if sizeof(type) == sizeof(int).
Most likely this should have `(TYPE_PRECISION (type) != TYPE_PRECISION
(integer_type_node))` added to it.
This is a missed optimization in some cases since it is signed integer overflow
is undefined and this just forces `short_var++` to being defined which is ok.
[Bug tree-optimization/120951] [16 regression] error: gimple cond condition cannot throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120951 --- Comment #10 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688651.html
[Bug c++/120968] New: Using global C name with import std recommends using the same undeclared name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120968
Bug ID: 120968
Summary: Using global C name with import std recommends using
the same undeclared name
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: luigighiron at gmail dot com
Target Milestone: ---
The following program demonstrates a strange diagnostic (compiled with C++23,
-fmodules, and when set up correctly to use import std):
import std;
int main(){
uint32_t x;
}
Error ( is the name of the file on godbolt):
:3:5: error: 'uint32_t' was not declared in this scope; did you mean
'uint32_t'?
3 | uint32_t x;
| ^~~~
| uint32_t
It doesn't seem that helpful to recommend using uint32_t when the program is
using uint32_t already and results in an error.
[Bug middle-end/120918] -Wreturn-type warning location is seemly wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120918
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Summary|-Wreturn-type warning is|-Wreturn-type warning
|confused by macro |location is seemly wrong
CC||pinskia at gcc dot gnu.org
Last reconfirmed||2025-07-05
Component|c++ |middle-end
--- Comment #1 from Andrew Pinski ---
So I don't think it is the macro which is causing the confusion but rather than
the lambda:
[/app/example.cpp:5:3] D.2986 = {CLOBBER(eos)};
That is where the warning is picking up the location from.
Even this gives a bad location:
```
int f()
{
[]{return 1;}() ? (void)1 : __builtin_abort();
}
```
:
```
: In function 'int f()':
:3:3: warning: control reaches end of non-void function [-Wreturn-type]
3 | []{return 1;}() ? (void)1 : __builtin_abort();
| ^
```
Confirmed.
Using `-flifetime-dse=0 -fstack-reuse=none` gives the better location:
```
: In function 'int f()':
:6:1: warning: control reaches end of non-void function [-Wreturn-type]
6 | }
| ^
```
I suspect pass_warn_function_return::execute should ignore CLOBBERS for
location purposes.
[Bug c++/120969] New: two consecutive '[' shall only introduce an attribute before '[' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969
Bug ID: 120969
Summary: two consecutive '[' shall only introduce an attribute
before '[' token
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
Target Milestone: ---
(see output below)
- First of all, GCC is complaining about its own standard library here!
- The first message doesn't seem to make much sense at all, attribute only
before '[' token, what? (The actual usage looks like a perfectly cromulent
attribute to me, anyway. That's why I'm reporting this against the compiler,
not the library, as I suspect the bug is in the compiler.)
- The errors only appear with "-fconcepts-ts" which I only use because GCC
suggested (required) me to
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917). If someone could comment
on my proposed workaround there
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917#c17), maybe I could avoid
using this flag and these errors. (Though even then, the errors seem strange
and worth investigating ...)
% dpkg -l | grep libstdc++
ii libstdc++-14-dev:amd64 14.2.0-19
amd64GNU Standard C++ Library v3 (development files)
ii libstdc++6:amd64 14.2.0-19
amd64GNU Standard C++ Library v3
% tail -n+3750 /usr/include/c++/14/format | head -n 7
template
requires (sizeof...(_Tp) == sizeof...(_Args))
[[__gnu__::__always_inline__]]
_Arg_store(_Tp&... __a) noexcept
: _M_args{_S_make_elt(__a)...}
{ }
% cat test.cpp
#include
% g++ --std="c++23" -Wpedantic -pedantic -pedantic-errors -Wall -Wextra
-fconcepts-ts -c /tmp/test.cpp
cc1plus: note: '-fconcepts-ts' is deprecated and will be removed in GCC 15;
please convert your code to C++20 concepts
In file included from /usr/include/c++/14/ostream:43,
from /usr/include/c++/14/bits/unique_ptr.h:43,
from /usr/include/c++/14/memory:78,
from /tmp/test.cpp:1:
/usr/include/c++/14/format:3753:9: error: two consecutive '[' shall only
introduce an attribute before '[' token
3753 | [[__gnu__::__always_inline__]]
| ^
/usr/include/c++/14/format:4220:5: error: two consecutive '[' shall only
introduce an attribute before '[' token
4220 | [[__gnu__::__always_inline__]]
| ^
/usr/include/c++/14/format:4227:5: error: two consecutive '[' shall only
introduce an attribute before '[' token
4227 | [[__gnu__::__always_inline__]]
| ^
/usr/include/c++/14/format:4234:5: error: two consecutive '[' shall only
introduce an attribute before '[' token
4234 | [[__gnu__::__always_inline__]]
| ^
/usr/include/c++/14/format:4244:5: error: two consecutive '[' shall only
introduce an attribute before '[' token
4244 | [[__gnu__::__always_inline__]]
| ^
/usr/include/c++/14/format: In function 'std::string std::vformat(string_view,
format_args)':
/usr/include/c++/14/format:4258:20: error: no matching function for call to
'vformat_to(std::__format::_Sink_iter, std::string_view&,
std::format_args&)'
4258 | std::vformat_to(__buf.out(), __fmt, __args);
| ~~~^~~~
/usr/include/c++/14/format:4222:5: note: candidate: 'template
requires _Out std::vformat_to(_Out, string_view,
format_args)'
4222 | vformat_to(_Out __out, string_view __fmt, format_args __args)
| ^~
/usr/include/c++/14/format:4222:5: note: template argument
deduction/substitution failed:
/usr/include/c++/14/format:4222:5: note: constraints not satisfied
/usr/include/c++/14/format:4229:5: note: candidate: 'template
requires _Out std::vformat_to(_Out, wstring_view,
wformat_args)'
4229 | vformat_to(_Out __out, wstring_view __fmt, wformat_args __args)
| ^~
/usr/include/c++/14/format:4229:5: note: template argument
deduction/substitution failed:
/usr/include/c++/14/format:4229:5: note: constraints not satisfied
/usr/include/c++/14/format:4236:5: note: candidate: 'template
requires _Out std::vformat_to(_Out, const locale&,
string_view, format_args)'
4236 | vformat_to(_Out __out, const locale& __loc, string_view __fmt,
| ^~
/usr/include/c++/14/format:4236:5: note: candidate expects 4 arguments, 3
provided
/usr/include/c++/14/format:4246:5: note: candidate: 'template
requires _Out std::vformat_to(_Out, const locale&,
wstring_view, wformat_args)'
4246 | vformat_to(_Out __out, const locale& __loc, wstring_view __fmt,
| ^~
/usr/include/c++/14/format:4246:5: note: candidate expects 4 arguments, 3
provided
/usr/include/c++/14/format: In function 'std::wstring
std::vformat(
[Bug c++/120942] internal compiler error happend when i lose include some file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120942 --- Comment #6 from Renze Lin --- (In reply to Andrew Pinski from comment #5) > (In reply to Renze Lin from comment #4) > > (In reply to Andrew Pinski from comment #2) > > > Also can you provide the full output of "gcc -v" ? > > > > The output is > > """ > > (base) root@ef26e3b1bbd5:/GCC-15-COVERAGE/bin# ./gcc -v > > Using built-in specs. > > COLLECT_GCC=./gcc > > COLLECT_LTO_WRAPPER=/GCC-15-COVERAGE/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/ > > lto-wrapper > > Target: x86_64-pc-linux-gnu > > Configured with: ./../gcc-15/configure --enable-languages=c,c++ > > --prefix=/GCC-15-COVERAGE --enable-coverage > > Thread model: posix > > Supported LTO compression algorithms: zlib zstd > > gcc version 15.0.1 20250225 (experimental) (GCC) > > """ > > Can you try the official GCC 15.1.0 release? Instead of a GCC 15 from > Feburary? I can't reproduce it with the official relase nor the trunk. I didn't find this issue on the latest version, it may be specific to GCC in February. I will use the latest gcc later, thank you
[Bug other/120905] Unable to compile GCC 6.5.0 with GCC 5.5.0 on Solaris 10 SPARC (linker error?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905 --- Comment #16 from Eric Botcazou --- > I'll try to recompile GCC 6.5 with GCC 5.5 again, but this time not with > just '--with-gnu-as', buth with also '--with-as=/usr/local/bin/as'. Perhaps > that will fix this. Yes, that's the right thing to do.
[Bug c/120921] gimple verifier (and gimple FE) accepts CST on LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120921 --- Comment #5 from Andrew Pinski --- Created attachment 61808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61808&action=edit Patch which I am testing
[Bug c/120921] gimple verifier (and gimple FE) accepts CST on LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120921 --- Comment #4 from Andrew Pinski --- Created attachment 61807 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61807&action=edit testcases for the invalid cases
[Bug tree-optimization/120954] [12/13/14/15 Regression] False positive -Warray-bounds=2 warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120954 Jakub Jelinek changed: What|Removed |Added Target Milestone|15.2|12.5 Summary|[15/16 Regression] False|[12/13/14/15 Regression] |positive -Warray-bounds=2 |False positive |warning |-Warray-bounds=2 warning --- Comment #6 from Jakub Jelinek --- It is actually a regression on all release branches (12-15). But C++ specific one, in C it was warning all the time. The primary question is what to do for 12.5, one possibility is backport r16-2000 (but without it having enough time on trunk), another is revert r12-11244 and r12-11245. A choice between clear wrong-code which we had for years and possible wrong-code and false positive warning which we had also for years but only for C on this testcase.
[Bug c/120966] -Waggressive-loop-optimizations warns for int but not for short overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120966 --- Comment #1 from Andreas Schwab --- There is no short overflow due to integer promotion.
[Bug c++/120969] two consecutive '[' shall only introduce an attribute before '[' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969 --- Comment #2 from Frank Heckenbach --- (In reply to Andrew Pinski from comment #1) > I am almost want to close this as won't fix since -fconcepts-ts has already > been removed in GCC 15 which was released 3 months ago. So much for the "deprecation period" (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917#c13) ...
[Bug c++/120969] two consecutive '[' shall only introduce an attribute before '[' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969 --- Comment #1 from Andrew Pinski --- I am almost want to close this as won't fix since -fconcepts-ts has already been removed in GCC 15 which was released 3 months ago.
[Bug c++/120969] two consecutive '[' shall only introduce an attribute before '[' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969 --- Comment #3 from Andrew Pinski --- (In reply to Frank Heckenbach from comment #2) > (In reply to Andrew Pinski from comment #1) > > I am almost want to close this as won't fix since -fconcepts-ts has already > > been removed in GCC 15 which was released 3 months ago. > > So much for the "deprecation period" > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917#c13) ... The deprecation period started when GCC 14.1.0 was released back in May 7, 2024 (see https://gcc.gnu.org/releases.html for the dates of the releases). So much for not understanding how upstream releases are handled. Plus -fconcepts-ts was always considered as experimental and subject to change. Even C++20 support is not fully done for GCC 15 so depending on it is subject to your own risk.
[Bug c++/120969] two consecutive '[' shall only introduce an attribute before '[' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #6 from Andrew Pinski --- (In reply to Frank Heckenbach from comment #5) > I never used "-fconcepts-ts" until now that GCC forces me to. Not exactly. The code was accepted by accident in GCC 12 with C++20 and then finally was rejected correctly in GCC 14. It was only by accident because it was part of the original concept paper and was finally noticed it should be removed. So basically you were using some experimental part of GCC which was never claimed as being finished and now GCC is correctly having it under -fconcepts-ts and removing the support there you are complaining. Again the C++20 support in GCC is still not fully complete (it is closer). So there will be bugs. Your code is invalid C++ 20 code even and you are complaining that GCC is forcing you to use the -fconcepts-ts option for that purpose? This is all hashed out in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917#c5 . Again GCC never declared it fully supports C++20 in either GCC 12, 13 or 14. It comes closest in GCC 15 though. The library side of C++20 (libstdc++) is still considered experimental even. So if you depend on that backwards compatibility is not guaranteed.
[Bug c++/120969] two consecutive '[' shall only introduce an attribute before '[' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969 --- Comment #4 from Frank Heckenbach --- (In reply to Andrew Pinski from comment #3) > (In reply to Frank Heckenbach from comment #2) > > (In reply to Andrew Pinski from comment #1) > > > I am almost want to close this as won't fix since -fconcepts-ts has > > > already > > > been removed in GCC 15 which was released 3 months ago. > > > > So much for the "deprecation period" > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917#c13) ... > > The deprecation period started when GCC 14.1.0 was released back in May 7, > 2024 > (see https://gcc.gnu.org/releases.html for the dates of the releases). > So much for not understanding how upstream releases are handled. > > Plus -fconcepts-ts was always considered as experimental and subject to > change. > Even C++20 support is not fully done for GCC 15 so depending on it is > subject to your own risk. I don't want to rehash the whole thread at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917 where this was all discussed. BTW, it was Jonathan Wakely's claim.
[Bug c++/120969] two consecutive '[' shall only introduce an attribute before '[' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969 --- Comment #5 from Frank Heckenbach --- (In reply to Andrew Pinski from comment #3) > (In reply to Frank Heckenbach from comment #2) > > (In reply to Andrew Pinski from comment #1) > > > I am almost want to close this as won't fix since -fconcepts-ts has > > > already > > > been removed in GCC 15 which was released 3 months ago. > > > > So much for the "deprecation period" > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917#c13) ... > > The deprecation period started when GCC 14.1.0 was released back in May 7, > 2024 > (see https://gcc.gnu.org/releases.html for the dates of the releases). > So much for not understanding how upstream releases are handled. > > Plus -fconcepts-ts was always considered as experimental and subject to > change. I never used "-fconcepts-ts" until now that GCC forces me to.
[Bug c++/120969] two consecutive '[' shall only introduce an attribute before '[' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969 --- Comment #7 from Andrew Pinski --- From https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Standards.html#C_002b_002b-Language : Another revised ISO C++ standard was published in 2020 as ISO/IEC 14882:2020, and is referred to as C++20; before its publication it was sometimes referred to as C++2a. GCC supports most of the changes in the new specification. For further details see https://gcc.gnu.org/projects/cxx-status.html#cxx20. To select this standard in GCC, use the option -std=c++20. Note the use of "most" there. compare that to C++17: The C++ language was further revised in 2017 and ISO/IEC 14882:2017 was published. This is referred to as C++17, and before publication was often referred to as C++1z. GCC supports all the changes in that specification. For further details see https://gcc.gnu.org/projects/cxx-status.html#cxx17. Use the option -std=c++17 to select this variant of C++. See how the use of "all" there.
[Bug c++/118697] static_assert message is not escaped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118697 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102613 --- Comment #1 from Andrew Pinski --- Wait this might be a dup of bug 102613 ...
[Bug c++/120969] two consecutive '[' shall only introduce an attribute before '[' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969 --- Comment #9 from Frank Heckenbach --- (In reply to Andrew Pinski from comment #6) > (In reply to Frank Heckenbach from comment #5) > > I never used "-fconcepts-ts" until now that GCC forces me to. > > Not exactly. The code was accepted by accident in GCC 12 with C++20 and then > finally was rejected correctly in GCC 14. It was only by accident because it > was part of the original concept paper and was finally noticed it should be > removed. > > So basically you were using some experimental part of GCC which was never > claimed as being finished and now GCC is correctly having it under > -fconcepts-ts and removing the support there you are complaining. > > Again the C++20 support in GCC is still not fully complete (it is closer). > So there will be bugs. > > Your code is invalid C++ 20 code even and you are complaining that GCC is > forcing you to use the -fconcepts-ts option for that purpose? > > This is all hashed out in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917#c5 . > > Again GCC never declared it fully supports C++20 in either GCC 12, 13 or 14. > It comes closest in GCC 15 though. The library side of C++20 (libstdc++) is > still considered experimental even. So if you depend on that backwards > compatibility is not guaranteed. This discussion seems to be pointless. We went through all that in the other bug report. So can anyone please comment on my workaround there (or some other possible workaround), so I can adjust me code and finally be done with this ...
[Bug c++/120969] two consecutive '[' shall only introduce an attribute before '[' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969 --- Comment #8 from Andrew Pinski --- Also from https://gcc.gnu.org/projects/cxx-status.html#cxx20 : Important: Because the ISO C++20 standard is recent, GCC's support is experimental.
[Bug c++/120969] two consecutive '[' shall only introduce an attribute before '[' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969 --- Comment #10 from Frank Heckenbach --- (In reply to Andrew Pinski from comment #7) > From > https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Standards.html#C_002b_002b- > Language : > Another revised ISO C++ standard was published in 2020 as ISO/IEC > 14882:2020, and is referred to as C++20; before its publication it was > sometimes referred to as C++2a. GCC supports most of the changes in the new > specification. For further details see > https://gcc.gnu.org/projects/cxx-status.html#cxx20. To select this standard > in GCC, use the option -std=c++20. > > > > Note the use of "most" there. So "most" means "some of the features of the standard plus some non-standard features which will then suddenly be withdrawn"?
[Bug c++/120969] two consecutive '[' shall only introduce an attribute before '[' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969 --- Comment #11 from Andrew Pinski --- (In reply to Frank Heckenbach from comment #10) > > So "most" means "some of the features of the standard plus some non-standard > features which will then suddenly be withdrawn"? YES. Especially based on https://gcc.gnu.org/projects/cxx-status.html#cxx20 which says C++20 support is experimental still.
[Bug c++/120955] [15/16 Regression] 50 % increase in data segment size on avr-gcc for -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955 --- Comment #3 from fiesh at zefix dot tv --- Thank you for the feedback. I tried to generate a test case, but it proved really hard for me. Is there some other output, like nm or objdump, that could help?
[Bug tree-optimization/120948] Cannot detect potential division-by-zero when numerator is 1 and denominator is variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120948 --- Comment #5 from Richard Biener --- A better representation than if (...) __builtin_unrechable (); for asserts would be nice. We have with __builtin_assume_aligned something very related. So in GIMPLE we could have _2 = .ASSUME (_1, !=, 0); with != encoded as integer tree code. But of course if we'd want to expose this to the user it might instead be x = __builtin_assume (x != 0); with the syntactic requirement that the argument is a compare and the left operator is a ID (IIRC OpenMP pragmas often have similar constraints). Of course there's no need to expose this to users in the first place. Having _3 = _1 != 0; _2 = .ASSUME (_1, _3); is more difficult because the separate predicate stmt will confuse size/time metrics. So _2 = 1 / x_1 would be turned into x_3 = .ASSUME (x_1, !=, 0); _2 = x_3 == 1; note that nothing prevents code motion of the above and the conditional would still be if (x_1 == 0) return 5; which means unless we rewrite all uses of x_1 to x_3 it might not achieve what we intend to.
[Bug target/120959] [16 Regression] 9% slowdown of 549.fotonik3d_r on Zen5 since r16-1645-g309dbcea2cabb3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120959 --- Comment #3 from Richard Biener --- (In reply to Richard Biener from comment #2) > That change shouldn't have caused code generation changes IIRC. That is, I would have expected RTL expansion to expand the division/multiplications as shifts.
[Bug target/120959] [16 Regression] 9% slowdown of 549.fotonik3d_r on Zen5 since r16-1645-g309dbcea2cabb3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120959 Richard Biener changed: What|Removed |Added Target Milestone|--- |16.0 --- Comment #2 from Richard Biener --- That change shouldn't have caused code generation changes IIRC.
[Bug tree-optimization/120954] [15/16 Regression] False positive -Warray-bounds=2 warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120954 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.2
[Bug c++/120955] [15/16 Regression] 50 % increase in data segment size on avr-gcc for -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955 --- Comment #4 from Georg-Johann Lay --- (In reply to fiesh from comment #3) > Is there some other output, like nm or objdump, that could help? Not very helpful IMO. You can try the following steps: 1) It's unlikely that LTO is essential. Thus try without -flto and identify a module where the problem occurs. Non-LTO test cases are much simpler since they only require one module and compiling + assembling is enough. In your case, the issue can be seen with avr-size some-module.o. 2) Use a pre-compiled file (*.ii file with -save-temps). This removes dependencies from headers as all #-directives are resolved. 3) Simplify the test case, for example with creduce https://github.com/csmith-project/creduce (also available as install packages, depending on your OS). creduce may come up with results that throw tons of warnings, therefore use options like -Wall -Werror in the interestingness test. The output of creduce is obfuscated code, so running it on closed source input it usually no issue. creduce may take a while. Simplifying the test case by hand prior to step 2) can safe you some time.
[Bug c/120966] New: -Waggressive-loop-optimizations warns for int but not for short overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120966
Bug ID: 120966
Summary: -Waggressive-loop-optimizations warns for int but not
for short overflow
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tvijlbrief at gmail dot com
Target Milestone: ---
=undef.c=
int sum;
int main()
{
short s= 1;
while (s) {
s++;
sum += s;
}
int i= 1;
while (i) {
i++;
sum += i;
}
}
==
$ gcc -O2 undef.c
undef.c: In function ‘main’:
undef.c:13:6: warning: iteration 2147483646 invokes undefined behavior
[-Waggressive-loop-optimizations]
13 | i++;
| ~^~
undef.c:12:10: note: within this loop
12 | while (i) {
| ^
===
gcc should give the same warning for the short integer s.
Note that this report is generated on a Linux system with 32bit int and 16bit
short:
tom@swan-ubu20:~/src/rust/arduino-hal-test/bug$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/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='Ubuntu
13.3.0-6ubuntu2~24.04' --with-bugurl=file:///u
sr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --wit
h-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-lin
ker-build-id --libexecdir=/usr/libexec --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --
enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --wit
h-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-syst
em-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror
--enable-cet --with-arch-32=i686 --wit
h-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-offload-targets=nv
ptx-none=/build/gcc-13-fG75Ri/gcc-13-13.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-fG75Ri/gcc-13-13
.3.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver
--enable-checking=release --build=x8
6_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --ena
ble-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04)
But the same issue is present with avr-gcc version 14, which has 16 bit int and
16 bit short.
[Bug c++/120917] warning: use of 'auto' in template argument only available with '-fconcepts-ts'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #18 from Frank Heckenbach ---
(In reply to Frank Heckenbach from comment #17)
> Maybe I've found a work-around. I took the is_instance_of_v template from
> https://indii.org/blog/is-type-instantiation-of-template/ and turned it into
> a concept, so I can replace:
>
> void f (S );
> void g (T );
>
> with:
>
> void f (instance_of auto);
> void g (instance_of auto);
>
> which at least keeps the required changes localized.
>
> I think it won't work with "partially auto instantiations" such as:
>
> void g (T );
>
> But fortunately I don't have many of them.
>
> Since I'm not so well versed with concepts yet, can you please confirm
> whether this is effectively equivalent?
To answer my own question, no it's not. T also accepts derived types,
instance_of does not.
So another attempt:
#include
template void CheckIsDerivedFromTemplate (const volatile Template &);
template typename Template> concept
DerivedFromTemplate = requires (T v) { CheckIsDerivedFromTemplate
(v); };
template struct S { };
struct U: S { };
struct V: U { };
class W: U { };
void f (S ) { }
void f_ (DerivedFromTemplate auto) { }
int main ()
{
S a;
// OK
f (a);
f_ (a);
f (S ());
f_ (S ());
f (V ());
f_ (V ());
// error
// f (1);
// f_ (1);
// f (nullptr);
// f_ (nullptr);
// f (W ());
// f_ (W ());
}
The diagnostics are worse, especially with W, but at least it accepts V and
rejects W as it should.
So, could this be a viable workaround?
[Bug rtl-optimization/101882] [16 Regression] combine vs. insn with earlyclobber and input and output set to a hard register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #15 from Xi Ruoyao ---
(In reply to Segher Boessenkool from comment #14)
> (match_operand:DI 1 "register_operand" "r0")
>
> That means either a general register ("r"), or the same thing as operand 0
> (that's what "0" means)!
>
> So the backend explicitly allows it here.
The problem is operand 4 does not have "0", and it's also assigned the hard
register r23. It's fine for operand 0 and 1 to be the same, also for operand 1
and 4 to be the same, but operand 0 and 4 cannot be same. Thus this combine
breaks the code.
[Bug rtl-optimization/101882] [16 Regression] combine vs. insn with earlyclobber and input and output set to a hard register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882 --- Comment #16 from Segher Boessenkool --- It is allowed by recog(). Most likely your pattern is incorrect, but it is not completely impossible there is something wrong in genrecog.cc -- but that isn't combine either.
[Bug c++/90569] __STDCPP_DEFAULT_NEW_ALIGNMENT__ is wrong for i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569 mirh at protonmail dot ch changed: What|Removed |Added CC||mirh at protonmail dot ch --- Comment #11 from mirh at protonmail dot ch --- I'm fairly sure this is still a problem. Microsoft’s runtime(s?) ain't guaranteeing malloc on anything but 4 or 8 alignment.
[Bug c++/116928] Error on NTTP with '>' in braced default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116928 --- Comment #2 from eczbek.void at gmail dot com --- I made a patch: https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685831.html
[Bug bootstrap/119430] profiledbootstrap fails on armv7a-unknown-linux-gnueabhif (crashes in elists__append_elmt during stagefeedback)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106338 --- Comment #11 from Andrew Pinski --- If it is the static chain it might show up on riscv too.
[Bug middle-end/120709] [15/16 Regression] ICE in expand_builtin_crc_table_based with __builtin_crc8_data8 and non constant poly argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120709 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Andrew Pinski --- I am going to implement the error message about being a constant and adding the documentation that the poly argument needs to be a constant.
[Bug target/120941] [16 Regression] 24-40% slowdown of 519.lbm_r on Zen2 and 470.lbm on Zen5 since r16-1644-gaba3b9d3a48a07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941 --- Comment #10 from H.J. Lu --- (In reply to Filip Kastl from comment #8) > The same commit (r16-1644-gaba3b9d3a48a07) causes ~20% slowdown of 470lbm > from 2006 SPEC on Zen5 with -Ofast -march=native -flto -fprofile-use. > > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1283.240.0 Can you extra a small testcase to show the issue?
[Bug bootstrap/119430] profiledbootstrap fails on armv7a-unknown-linux-gnueabhif (crashes in elists__append_elmt during stagefeedback)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430 --- Comment #9 from Alexandre Oliva --- I'm not sure I've run into the same problem, but the one I'm looking at is in the training stage, in ali.o, one of many that raise an assertion failure from SInput.Get_Source_File_Index.Assertions. Interesting situation: the caller is inlined into expand_sloc (cross-language inlinining, wheee :-), it sets up the static chain record correctly, stores it in r12, and then calls the Assertions nested function. But the call seems to go through an lto-introduced (?) mi thunk that clobbers r12 (used as a scratch register). Very very "ugh!" moment. Not sure yet how to go about this.
[Bug bootstrap/119430] profiledbootstrap fails on armv7a-unknown-linux-gnueabhif (crashes in elists__append_elmt during stagefeedback)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430 --- Comment #10 from Alexandre Oliva --- Sorry, I'd missed the build scripts, that presumably would have enabled me to trigger the problem more readily. Anyhow, this explains why lto and PIE are both needed to trigger the problem. As for a solution, unless the arm port can find some way to avoid the register overlap for thunks that need the static chain. Failing that, I have a hunch that the issue has to do with the call's crossing lto (re)compilation units, in which case one solution could be to sacrifice some optimization opportunities and force functions and their inner functions to remain in a single unit.
[Bug libstdc++/118681] [C++17] unsynchronized_pool_resource may fail to respect alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118681 --- Comment #10 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688627.html
[Bug libstdc++/120949] [16 regression] rejected with clang-20.1.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120949
--- Comment #5 from Jonathan Wakely ---
But not with Clang 20:
:5:34: error: an attribute list cannot appear here
5 | __attribute__((always_inline)) [[nodiscard]] friend inline int baz ()
{ return 42; }
| ^
1 error generated.
Compiler returned: 1
Patch posted https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688628.html
[Bug libstdc++/120949] [16 regression] rejected with clang-20.1.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120949 --- Comment #6 from Jonathan Wakely --- I think https://github.com/llvm/llvm-project/pull/133107 fixed clang trunk.
[Bug target/118891] [14/15/16 regression] gcc 14 fails to build from source on aarch64_be: "error: ‘dynamic_cast’ not permitted with ‘-fno-rtti’"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891 --- Comment #24 from marcus at mc dot pp.se --- I can confirm that with those two patches a 3-stage build of 14.2.1 completes with stage 2 and 3 compared as equal. The number of failed tests with "vect" somewhere in the name is down to 6: FAIL: gcc.target/aarch64/vect-widen-shift.c check-function-bodies sshll_opt1 FAIL: gcc.target/aarch64/vect-widen-shift.c check-function-bodies sshll_opt2 FAIL: gcc.target/aarch64/vect_copy_lane_1.c scan-assembler-times ins\\tv0.d\\[1\\], v1.d\\[1\\] 3 FAIL: gcc.target/aarch64/vect-widen-shift.c check-function-bodies sshll_opt1 FAIL: gcc.target/aarch64/vect-widen-shift.c check-function-bodies sshll_opt2 FAIL: gcc.target/aarch64/vect_copy_lane_1.c scan-assembler-times ins\\tv0.d\\[1\\], v1.d\\[1\\] 3
