[Bug libstdc++/113258] Pre-C++17 code that replaces malloc/free crashes when mixed with post-C++17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #26 from Sam James --- Just to close the loop: this ended up being covered originally a few months back with https://airlied.blogspot.com/2023/04/fedora-38-llvm-vs-team-fortress-2-tf2.html and https://gitlab.freedesktop.org/mesa/mesa/-/issues/8133. That's clearly what the original report above is derived from too. Unfortunately, getting fixed copies of libtcmalloc in games which were shipped a decade ago isn't likely. Thanks for the workaround.
[Bug target/107201] [avr] -nodevicelib not working for devices -mmcu=avr...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107201 --- Comment #3 from GCC Commits --- The releases/gcc-13 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:3f6efe203484f7fb29c048d024dd8205e9e0f193 commit r13-8227-g3f6efe203484f7fb29c048d024dd8205e9e0f193 Author: Georg-Johann Lay Date: Mon Jan 15 13:25:59 2024 +0100 AVR: target/107201: Make -nodevicelib work for all devices. driver-avr.cc contains a spec that discriminates between cores and devices by means of a mmcu=avr* spec pattern. This does not work for new devices like AVR128* which also start with mmcu=avr like all cores do. The patch uses a new spec function in order to tell apart cores from devices. gcc/ PR target/107201 * config/avr/avr.h (EXTRA_SPEC_FUNCTIONS): Add no-devlib, avr_no_devlib. * config/avr/driver-avr.cc (avr_no_devlib): New function. (avr_devicespecs_file): Use it to remove -nodevicelib from the options for cores only. * config/avr/avr-arch.h (avr_get_parch): New prototype. * config/avr/avr-devices.cc (avr_get_parch): New function. (cherry picked from commit 86fac7ee1688bdec245a43f6d2ab49fb238892e4)
[Bug modula2/111956] [14 Regression] Many powerpc platforms do _not_ have support for IEEE754 long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956 --- Comment #15 from Richard Biener --- (In reply to Gaius Mulley from comment #14) > Ah apologies, is it best that I revert: > > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git; > h=81d5ca0b9b8431f1bd7a5ec8a2c94f04bb0cf032 > > happy to do this in the morning. I think it might be better to define M2C_LONGREAL_FLOAT128/M2C_LONGREAL_PPC64LE (whatever they exactly indicate) in terms of the existing --with-long-double-128 --with-long-double-format aka the TARGET_DEFAULT_LONG_DOUBLE_128 that's put into the config plus with_long_double_format (I think that causes TARGET_IEEEQUAD_DEFAULT to be defined to 1/0, but only for ppc, via config.gcc and tm_defines). I can't say whether it's better to revert or disable/fix as I can't say how this for example affects the M2 ABI (like if there was any 'long double' before this change and what effective type this used).
[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372 --- Comment #18 from rguenther at suse dot de --- On Mon, 15 Jan 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372 > > --- Comment #17 from Jakub Jelinek --- > (In reply to Richard Biener from comment #15) > > (In reply to Jakub Jelinek from comment #14) > > > Created attachment 57085 [details] > > > gcc14-pr113372.patch > > > > > > The non-propagation workaround which seems to fix^H^H^Hworkaround all > > > those > > > 4 issues (PR90348 testcase actually doesn't FAIL anymore, but I've > > > verified > > > the patch results in in and buf no longer being shared) can look like > > > this. > > > > + || (INTEGRAL_TYPE_P (TREE_TYPE (use)) > > + && TYPE_PRECISION (TREE_TYPE (use)) == POINTER_SIZE))) > > > > ptrofftype_p (TREE_TYPE (use)) > > Aren't there targets where pointers are larger than sizetype? > I thought msp430, but that one uses __int20. There are also address-spaces with pointer sizes different from POINTER_SIZE. I suppose tracking all INTEGRAL_TYPE_P uses and instead relying on the def to identify a pointer source would work as well. > > I think it should be enough to look at gimple_assing_rhs1, that works > > for single non-invariant [i], for conversions and for offsetting of > > an invariant address (pointer-plus). > > Is the invariant operand guaranteed to go first? If it is pointer, guess > POINTER_PLUS_EXPR enforces that, and for sizetype addition guess an operand > can't be ADDR_EXPR, there would need to be a cast in a separate stmt. So > perhaps ok. Yes, I think that works. > As for Micha's fears, I can certainly try to dump statistics during > bootstrap/regtest on how many variables were shared and/or their cumulative > size without/with the patch and see if it has significant effects on > real-world > code. Might be interesting to dump the stack size saved due to sharing instead? Do we really need to handle the PHI nodes btw? With doing propagation we could avoid marking certain use sites as mentions, like compares of the address value. But of course we'd have to give up for uses in calls or other things we can't analyze.
[Bug middle-end/108016] RISC-V：Bad codegen in scalar code comparing to LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108016
--- Comment #2 from JuzheZhong ---
#include
std::pair full_add(unsigned a, unsigned b)
{ return std::make_pair(a + b, a + b < a); }
[Bug target/113416] New: ICE: in force_constant_size, at gimplify.cc:742 (in convert_move, at expr.cc:223) with -march=rv64gcv (-march=rv32gcv) and -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113416
Bug ID: 113416
Summary: ICE: in force_constant_size, at gimplify.cc:742 (in
convert_move, at expr.cc:223) with -march=rv64gcv
(-march=rv32gcv) and -ftree-parallelize-loops=2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu
Created attachment 57098
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57098=edit
reduced testcase
This has been reduced from gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-27.c ;
it fails the same way with -ftree-parallelize-loops=2.
Compiler output:
$ riscv64-unknown-linux-gnu-gcc -O -march=rv64gcv -ftree-parallelize-loops=2
testcase.c
during GIMPLE pass: parloops
testcase.c: In function 'f':
testcase.c:4:1: internal compiler error: in force_constant_size, at
gimplify.cc:743
4 | f(long out, int n)
| ^
0xa18136 force_constant_size
/repo/gcc-trunk/gcc/gimplify.cc:743
0x134e297 gimple_add_tmp_var(tree_node*)
/repo/gcc-trunk/gcc/gimplify.cc:781
0x1304676 create_tmp_var(tree_node*, char const*)
/repo/gcc-trunk/gcc/gimple-expr.cc:491
0x1780c4d separate_decls_in_region
/repo/gcc-trunk/gcc/tree-parloops.cc:2125
0x1782dd1 gen_parallel_loop
/repo/gcc-trunk/gcc/tree-parloops.cc:3162
0x1784a48 parallelize_loops
/repo/gcc-trunk/gcc/tree-parloops.cc:4140
0x1785dc1 execute
/repo/gcc-trunk/gcc/tree-parloops.cc:4228
0x1785dc1 execute
/repo/gcc-trunk/gcc/tree-parloops.cc:4207
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ riscv64-unknown-linux-gnu-gcc -O -march=rv32gcv -mabi=ilp32
-ftree-parallelize-loops=2 testcase.c
during RTL pass: expand
testcase.c: In function 'f._loopfn.0':
testcase.c:6:17: internal compiler error: in convert_move, at expr.cc:223
6 | for (int i; i < n; i++) {
| ^
0x9f3dd1 convert_move(rtx_def*, rtx_def*, int)
/repo/gcc-trunk/gcc/expr.cc:223
0x127807a store_expr(tree_node*, rtx_def*, int, bool, bool)
/repo/gcc-trunk/gcc/expr.cc:6810
0x1279909 expand_assignment(tree_node*, tree_node*, bool)
/repo/gcc-trunk/gcc/expr.cc:6443
0x112715c expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3966
0x112715c expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4064
0x112e2be expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6120
0x112fec7 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6855
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7258-20240115151353-g731444b3c39-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-7258-20240115151353-g731444b3c39-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240115 (experimental) (GCC)
[Bug target/112919] LoongArch: Alignments in tune parameters are not precise and they regress performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919 --- Comment #6 from chenglulu --- Hi，Ruoyao: I am testing the spec2006 scores when the parameters 'align-loops', 'align-jumps', 'align-functions', and 'align-labels' are '1', '8', '16', and '32' respectively. However, the test was suspended due to the company's power maintenance last week, and it will take some time to retest.
[Bug middle-end/113415] ICE: RTL check: -mstringop-strategy=byte_loop vs inline-asm goto with block copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415 Andrew Pinski changed: What|Removed |Added Summary|ICE: RTL check: expected|ICE: RTL check: |elt 3 type 'e' or 'u', have |-mstringop-strategy=byte_lo |'0' (rtx code_label) in |op vs inline-asm goto with |PATTERN, at rtl.h:1511 with |block copies |-mstringop-strategy=byte_lo | |op and invalid __asm__ on | |_BitInt() | Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-16 --- Comment #2 from Andrew Pinski --- This code will not work with anything more fancy than insns, it does not support code_labels. ``` for (rtx_insn *curr = after_rtl_seq; curr != NULL_RTX; curr = NEXT_INSN (curr)) emit_insn (copy_insn (PATTERN (curr))); rtx_insn *copy = get_insns (); end_sequence (); ```
[Bug middle-end/113415] ICE: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx code_label) in PATTERN, at rtl.h:1511 with -mstringop-strategy=byte_loop and invalid __asm__ on _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415
--- Comment #1 from Andrew Pinski ---
This might fail the same way:
```
void
foo(void)
{
unsigned long bitint0[64];
lab:
__asm__ goto("" : "=r"(bitint0) : : : lab);
}
```
[Bug rtl-optimization/113415] New: ICE: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx code_label) in PATTERN, at rtl.h:1511 with -mstringop-strategy=byte_loop and invalid __asm__ on _BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415
Bug ID: 113415
Summary: ICE: RTL check: expected elt 3 type 'e' or 'u', have
'0' (rtx code_label) in PATTERN, at rtl.h:1511 with
-mstringop-strategy=byte_loop and invalid __asm__ on
_BitInt()
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 57097
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57097=edit
reduced testcase
This probably needs RTL checking enabled. The asm constraints are invalid; ICEs
before the diagnostics.
Compiler output:
$ x86_64-pc-linux-gnu-gcc -mstringop-strategy=byte_loop testcase.c
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:6:3: internal compiler error: RTL check: expected elt 3 type 'e' or
'u', have '0' (rtx code_label) in PATTERN, at rtl.h:1511
6 | __asm__ goto("" : "=r"(x) : : : lab);
| ^~~
0x800c3a rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/repo/gcc-trunk/gcc/rtl.cc:761
0x724644 PATTERN(rtx_def*)
/repo/gcc-trunk/gcc/rtl.h:1511
0x726bf6 PATTERN(rtx_def*)
/repo/gcc-trunk/gcc/rtl.h:1479
0x726bf6 expand_asm_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:3655
0xf88909 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3897
0xf88909 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4064
0xf8a007 expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6120
0xf8c66e execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6855
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7258-20240115151353-g731444b3c39-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-7258-20240115151353-g731444b3c39-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240115 (experimental) (GCC)
[Bug c/113414] Incorrent checking for printf format: does not distinguish whether the variable is signed or unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113414 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||diagnostic --- Comment #4 from Eric Gallager --- I forget which other bug I mentioned this in, but this reminds me that I still think a -Wformat=3 that includes -Wformat-signedness would be nice, as currently it only goes up to -Wformat=2, which doesn't include -Wformat-signedness currently.
[Bug target/99913] GCC11 fails to build for MinGW-w64 for Windows 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913 LIU Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #4 from LIU Hao --- Is there still such an error for you? It looks to me that this linker command line did not contain `-pthread` unlike the ones above. Maybe the configure script is worth looking at. ``` configure:16911: /R/winlibs32_stage/gcc-11-20210404/build_mingw/./gcc/xgcc -B/R/winlibs32_stage/gcc-11-20210404/build_mingw/./gcc/ -L/R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/i686-w64-mingw32/lib -L/R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/mingw/lib -isystem /R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/i686-w64-mingw32/include -isystem /R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/mingw/include -B/R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/i686-w64-mingw32/bin/ -B/R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/i686-w64-mingw32/lib/ -isystem /R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/i686-w64-mingw32/include -isystem /R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/i686-w64-mingw32/sys-include --sysroot=/R/winlibs32_stage/gcc-11-20210404/build_mingw/mingw-w64 -o conftest.exe -O0 -include confdefs.h -include ../../../libgomp/config/posix/omp-lock.h -s conftest.c -ldl >&5 D:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\bin\ld.exe: R:/winlibs32_stage/gcc-11-20210404/build_mingw/gcc/libgcc_eh.a(unwind-dw2.o): in function `_gthread_once': R:\winlibs32_stage\gcc-11-20210404\build_mingw\i686-w64-mingw32\libgcc/./gthr-default.h:700: undefined reference to `pthread_once' ```
[Bug target/43613] Some architecture-dependent codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #9 from Xi Ruoyao --- (In reply to nightstrike from comment #8) > (In reply to Andrew Pinski from comment #7) > > So just this one left I think: > > > > /gcc/src/gcc/ira-conflicts.c: Line 125: > > > > Still there, size_t is long long (64bits) while long is 32bits. > > Assuming this is now line 153: > > ``` > diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc > index a4d93c8d734..4f2c2bdfebc 100644 > --- a/gcc/ira-conflicts.cc > +++ b/gcc/ira-conflicts.cc > @@ -150,9 +150,9 @@ build_conflict_bit_table (void) >if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL) > fprintf >(ira_dump_file, > - "+++Allocating %ld bytes for conflict table (uncompressed size > %ld)\n", > - (long) allocated_words_num * sizeof (IRA_INT_TYPE), > - (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)); > + "+++Allocating %zu bytes for conflict table (uncompressed size > %zu)\n", > + (size_t)(allocated_words_num * sizeof (IRA_INT_TYPE)), > + (size_t)(object_set_words * ira_objects_num * sizeof > (IRA_INT_TYPE))); > >objects_live = sparseset_alloc (ira_objects_num); >for (i = 0; i < ira_max_point; i++) > ``` > > Perhaps that will address the remaining issue? Post patches to gcc-patches instead of bugzilla. The patches in bugzilla are not considered candidates to be applied for trunk.
[Bug c/113414] Incorrent checking for printf format: does not distinguish whether the variable is signed or unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113414 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- And IMO it's not really "wrong" to suggest %lld. Using %lld may not be what you really want, but it's at least allowed by the standard (while using %d here is prohibited and leading to an undefined behavior).
[Bug target/43613] Some architecture-dependent codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #8 from nightstrike --- (In reply to Andrew Pinski from comment #7) > So just this one left I think: > > /gcc/src/gcc/ira-conflicts.c: Line 125: > > Still there, size_t is long long (64bits) while long is 32bits. Assuming this is now line 153: ``` diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc index a4d93c8d734..4f2c2bdfebc 100644 --- a/gcc/ira-conflicts.cc +++ b/gcc/ira-conflicts.cc @@ -150,9 +150,9 @@ build_conflict_bit_table (void) if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL) fprintf (ira_dump_file, - "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n", - (long) allocated_words_num * sizeof (IRA_INT_TYPE), - (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)); + "+++Allocating %zu bytes for conflict table (uncompressed size %zu)\n", + (size_t)(allocated_words_num * sizeof (IRA_INT_TYPE)), + (size_t)(object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE))); objects_live = sparseset_alloc (ira_objects_num); for (i = 0; i < ira_max_point; i++) ``` Perhaps that will address the remaining issue?
[Bug c/113414] Incorrent checking for printf format: does not distinguish whether the variable is signed or unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113414 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90205 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > >The code should be warned, but it did not. > > > No that is by design. You need to use -Wformat-signedness for that. > > But for the second example, the fix it note is wrong only with > -Wformat-signedness . But that is already PR 90205 .
[Bug c/113414] Incorrent checking for printf format: does not distinguish whether the variable is signed or unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113414 --- Comment #1 from Andrew Pinski --- >The code should be warned, but it did not. No that is by design. You need to use -Wformat-signedness for that. But for the second example, the fix it note is wrong only with -Wformat-signedness .
[Bug c/113414] New: Incorrent checking for printf format: does not distinguish whether the variable is signed or unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113414
Bug ID: 113414
Summary: Incorrent checking for printf format: does not
distinguish whether the variable is signed or unsigned
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tongxiangzheng.route at gmail dot com
Target Milestone: ---
When checking the printf() function, gcc does not distinguish whether the
variable is signed or unsigned.
for example:
$ gcc test.cpp
#include
int main(){
int n;
printf("%u",n);
}
The code should be warned, but it did not.
example 2:
$ gcc test.cpp
#include
int main(){
unsigned long long int n;
printf("%d",n);
}
The code be warned, but it's wrong:
test.cpp: In function ‘int main()’:
test.cpp:4:18: warning: format ‘%d’ expects argument of type ‘int’, but
argument 2 has type ‘long long unsigned int’ [-Wformat=]
4 | printf("%d",n);
| ~^ ~
| | |
| | long long unsigned int
| int
| %lld
gcc suggests using %lld, but in reality, %llu should be used.
[Bug tree-optimization/113091] Over-estimate SLP vector-to-scalar cost for non-live pattern statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113091 --- Comment #9 from GCC Commits --- The master branch has been updated by Feng Xue : https://gcc.gnu.org/g:57f611604e8bab67af6c0bcfe6ea88c001408412 commit r14-7272-g57f611604e8bab67af6c0bcfe6ea88c001408412 Author: Feng Xue Date: Thu Dec 28 16:55:39 2023 +0800 Do not count unused scalar use when marking STMT_VINFO_LIVE_P [PR113091] When pattern recognition is involved, a statement whose definition is consumed in some pattern, may not be included in the final replacement pattern statements, and would be skipped when building SLP graph. * Original char a_c = *(char *) a; char b_c = *(char *) b; unsigned short a_s = (unsigned short) a_c; int a_i = (int) a_s; int b_i = (int) b_c; int r_i = a_i - b_i; * After pattern replacement a_s = (unsigned short) a_c; a_i = (int) a_s; patt_b_s = (unsigned short) b_c;// b_i = (int) b_c patt_b_i = (int) patt_b_s; // b_i = (int) b_c patt_r_s = widen_minus(a_c, b_c); // r_i = a_i - b_i patt_r_i = (int) patt_r_s; // r_i = a_i - b_i The definitions of a_i(original statement) and b_i(pattern statement) are related to, but actually not part of widen_minus pattern. Vectorizing the pattern does not cause these definition statements to be marked as PURE_SLP. For this case, we need to recursively check whether their uses are all absorbed into vectorized code. But there is an exception that some use may participate in an vectorized operation via an external SLP node containing that use as an element. gcc/ChangeLog: PR tree-optimization/113091 * tree-vect-slp.cc (vect_slp_has_scalar_use): New function. (vect_bb_slp_mark_live_stmts): New parameter scalar_use_map, check scalar use with new function. (vect_bb_slp_mark_live_stmts): New function as entry to existing overriden functions with same name. (vect_slp_analyze_operations): Call new entry function to mark live statements. gcc/testsuite/ChangeLog: * gcc.target/aarch64/bb-slp-pr113091.c: New test.
[Bug target/113404] ICE: in to_constant, at poly-int.h:588 with -march=rv64gcv -mbig-endian --param=riscv-vector-abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113404 --- Comment #1 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:5134d3074ad7a462b4c8e2c0bc904b5ba40b7373 commit r14-7271-g5134d3074ad7a462b4c8e2c0bc904b5ba40b7373 Author: Juzhe-Zhong Date: Tue Jan 16 11:04:49 2024 +0800 RISC-V: Report Sorry when users enable RVV in big-endian mode [PR113404] As PR113404 mentioned: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113404 We have ICE when we enable RVV in big-endian mode: during RTL pass: expand a-float-point-dynamic-frm-66.i:2:14: internal compiler error: in to_constant, at poly-int.h:588 0xab4c2c poly_int<2u, unsigned short>::to_constant() const /repo/gcc-trunk/gcc/poly-int.h:588 0xab4de1 poly_int<2u, unsigned short>::to_constant() const /repo/gcc-trunk/gcc/tree.h:4055 0xab4de1 default_function_arg_padding(machine_mode, tree_node const*) /repo/gcc-trunk/gcc/targhooks.cc:844 0x12e2327 locate_and_pad_parm(machine_mode, tree_node*, int, int, int, tree_node*, args_size*, locate_and_pad_arg_data*) /repo/gcc-trunk/gcc/function.cc:4061 0x12e2aca assign_parm_find_entry_rtl /repo/gcc-trunk/gcc/function.cc:2614 0x12e2c89 assign_parms /repo/gcc-trunk/gcc/function.cc:3693 0x12e59df expand_function_start(tree_node*) /repo/gcc-trunk/gcc/function.cc:5152 0x112fafb execute /repo/gcc-trunk/gcc/cfgexpand.cc:6739 Report users that we don't support RVV in big-endian mode for the following reasons: 1. big-endian in RISC-V is pretty rare case. 2. We didn't test RVV in big-endian and we don't have enough time to test it since it's stage 4 now. Naive disallow RVV in big-endian. Tested no regression, ok for trunk ? gcc/ChangeLog: PR target/113404 * config/riscv/riscv.cc (riscv_override_options_internal): Report sorry for RVV in big-endian mode. gcc/testsuite/ChangeLog: PR target/113404 * gcc.target/riscv/rvv/base/big_endian-1.c: New test. * gcc.target/riscv/rvv/base/big_endian-2.c: New test.
[Bug testsuite/111850] [14 regression] gcc.target/powerpc/fold-vec-extract-char.p7.c fails after r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111850 Kewen Lin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org --- Comment #4 from Kewen Lin --- Just realized that we also escalated test issue to P1, I'm going to make a patch for the test case update.
[Bug testsuite/109705] [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
--- Comment #5 from GCC Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:39fa71a0882928a25bd170580e3e9e89a69dce36
commit r14-7270-g39fa71a0882928a25bd170580e3e9e89a69dce36
Author: Kewen Lin
Date: Mon Jan 15 20:55:40 2024 -0600
testsuite: Fix vect_long_mult on Power [PR109705]
As pointed out by the discussion in PR109705, the current
vect_long_mult effective target check on Power is broken.
This patch is to fix it accordingly.
With additional change by adding a guard vect_long_mult
in gcc.dg/vect/pr25413a.c, it's tested well on Power{8,9}
LE & BE (also on Power10 LE as before).
PR testsuite/109705
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_effective_target_vect_long_mult):
Fix powerpc*-*-* checks.
[Bug fortran/113413] ATAND(Y,X) is unsupported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113413 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-16 Priority|P3 |P4
[Bug fortran/113413] New: ATAND(Y,X) is unsupported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113413 Bug ID: 113413 Summary: ATAND(Y,X) is unsupported Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: --- Fortran 2023 added ATAND(X) and ATAND(Y,X). The former is supported. The latter is unsupported. Consider. program main real(4) x, y x = 1. y = x print*, atand(y,x), atan2d(y,x) end % gfcx -o z a.f90 a.f90:5:10: 5 |print*, atand(y,x), atan2d(y,x) | 1 Error: Too many arguments in call to ‘atand’ at (1)
[Bug c++/112580] [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580 Hans-Peter Nilsson changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Hans-Peter Nilsson --- (In reply to Francois-Xavier Coudert from comment #5) > Not entirely, xtreme-header_b.C is still failing, as indicated above. See > recently: > https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/805380.html > > FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors) > FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) Confirmed for cris-elf @r14-7254-g4f141b051ef4, reopening.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 112580, which changed state. Bug 112580 Summary: [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug testsuite/112419] [14 Regression] gcc.dg/Wnonnull-4.c excess error for 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112419 --- Comment #7 from Hans-Peter Nilsson --- (In reply to Richard Biener from comment #6) > Fixed. I guess. Correct; sorry, I should have close it myself after the commit.
[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-16 Priority|P3 |P4
[Bug fortran/113412] New: ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412 Bug ID: 113412 Summary: ATAN(Y,X) does not check arguments and generates wrong error message. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: --- Fortran 2008 added the misguided form ATAN(Y,X) where Y could be missing. However, if Y is present, then X is required to have the same type and kind as Y. Consider, % cat a.f90 program main real(4) x real(8) y x = 1. y = x print*, atan(y,x), atan2(y,x) end % gfcx -o z a.f90 a.f90:6:10: 6 |print*, atan(y,x), atan2(y,x) | 1 Error: Too many arguments in call to ‘atan’ at (1) a.f90:6:30: 6 |print*, atan(y,x), atan2(y,x) | 1 Error: ‘x’ argument of ‘atan2’ intrinsic at (1) must be the same type and kind as ‘y’ The error message for atan(y,x) is wrong.
[Bug rtl-optimization/111267] [14 Regression] Codegen regression from i386 argument passing changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267 --- Comment #10 from Roger Sayle --- A revised and improved patch has been posted for review at https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643062.html
[Bug modula2/111956] [14 Regression] Many powerpc platforms do _not_ have support for IEEE754 long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956 --- Comment #14 from Gaius Mulley --- Ah apologies, is it best that I revert: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=81d5ca0b9b8431f1bd7a5ec8a2c94f04bb0cf032 happy to do this in the morning.
[Bug tree-optimization/113334] wrong code with _BitInt() shift at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113334 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/113411] New: ABS*ABS can be simplified to ABS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113411
Bug ID: 113411
Summary: ABS*ABS can be simplified to ABS
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
static inline int abs(int a)
{
signed b = a;
if (a < 0)
b = -b;
return b;
}
int foo1(int a, int b)
{
return abs(a) * abs(b);
}
```
foo1 can be simplified down to `abs(a*b)`. Note I think this is only valid for
signed overflowable types and not valid with -fwrapv (but I could be wrong).
Maybe ok for real types with -ffast-math.
[Bug analyzer/106229] False positives from -Wanalyzer-tainted-array-index with unsigned char index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106229 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Should be fixed on trunk for GCC 14 by the above patch. Given that taint checking requires explicit opt-in in earlier releases, I don't plan to backport this. Marking this as resolved.
[Bug analyzer/106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358 Bug 106358 depends on bug 106229, which changed state. Bug 106229 Summary: False positives from -Wanalyzer-tainted-array-index with unsigned char index https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106229 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/113333] analyzer: False positives with calloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 --- Comment #3 from David Malcolm --- Should be fixed on trunk for GCC 14 by the above patch. Still affects GCC 13 and earlier; keeping open to track backporting.
[Bug middle-end/113410] ICE: in maybe_check_access_sizes, at gimple-ssa-warn-access.cc:3423 with _BitInt() used as array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113410 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic, ice-checking Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-01-16 Component|tree-optimization |middle-end --- Comment #1 from Andrew Pinski --- Confirmed. The assert that is being triggered: ``` char sizstr[80]; ... gcc_checking_assert (strlen (s0) + strlen (s1) < sizeof sizstr - 4); sprintf (sizstr, "[%.37s, %.37s]", s0, s1); ``` Yes the size of the array is too small to print out the values now ...
[Bug analyzer/106229] False positives from -Wanalyzer-tainted-array-index with unsigned char index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106229 --- Comment #1 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:ce27b66d952127b7abd0f8cceacb79eb6ecf71db commit r14-7266-gce27b66d952127b7abd0f8cceacb79eb6ecf71db Author: David Malcolm Date: Mon Jan 15 19:01:21 2024 -0500 analyzer: fix false +ves from -Wanalyzer-tainted-array-index with unsigned char index [PR106229] gcc/analyzer/ChangeLog: PR analyzer/106229 * analyzer.h (compare_constants): New decl. * constraint-manager.cc (compare_constants): Make non-static. * sm-taint.cc: Add include "fold-const.h". (class concrete_range): New. (get_possible_range): New. (index_can_be_out_of_bounds_p): New. (region_model::check_region_for_taint): Reject -Wanalyzer-tainted-array-index if the type of the value makes it impossible for it to be out-of-bounds of the array. gcc/testsuite/ChangeLog: PR analyzer/106229 * c-c++-common/analyzer/taint-index-pr106229.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/113333] analyzer: False positives with calloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 --- Comment #2 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:d235bf2e807c5f7e959ca5f3f8d92936801f5b80 commit r14-7265-gd235bf2e807c5f7e959ca5f3f8d92936801f5b80 Author: David Malcolm Date: Mon Jan 15 19:01:16 2024 -0500 analyzer: casting all zeroes should give all zeroes [PR11] In particular, accessing the result of *calloc (1, SZ) (if non-NULL) should be known to be all zeroes. gcc/analyzer/ChangeLog: PR analyzer/11 * region-model-manager.cc (region_model_manager::maybe_fold_unaryop): Casting all zeroes should give all zeroes. gcc/testsuite/ChangeLog: PR analyzer/11 * c-c++-common/analyzer/calloc-1.c: Add tests. * c-c++-common/analyzer/pr96639.c: Update expected results. * gcc.dg/analyzer/data-model-9.c: Likewise. Signed-off-by: David Malcolm
[Bug middle-end/113406] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -fstrub=internal and _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113406
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-01-15
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Component|tree-optimization |middle-end
--- Comment #1 from Andrew Pinski ---
Confirmed, scrub is changing the IR to:
```
void * .strub.watermark.2;
_BitInt(146) retval.1;
[local count: 1]:
__builtin___strub_enter (&.strub.watermark.2);
retval.1_3 = foo.strub.0 (&.strub.watermark.2);
__builtin___strub_leave (&.strub.watermark.2);
.strub.watermark.2 ={v} {CLOBBER};
return retval.1_3;
```
Which looks fine but bitintlower is not expecting a gimple ssa of _BitInt(N) in
the GIMPLE_RETURN .
Here is a reduced _GIMPLE testcase without the need for -fstrub=internal :
```
_BitInt(146)
foo1(void);
_BitInt(146)
__GIMPLE()
foo(void)
{
_BitInt(146) t;
t = foo1();
return t;
}
```
[Bug c++/110065] [11/12/13/14 Regression] [C++20/2b] auto return type in template argument causes ICE, also accepts-invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110065 --- Comment #5 from GCC Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:a3054489117085c095e480c71b6aaeea9a463c37 commit r14-7264-ga3054489117085c095e480c71b6aaeea9a463c37 Author: Marek Polacek Date: Mon Jan 15 09:15:59 2024 -0500 c++: ICE with auto in template arg [PR110065] Here we started crashing with r14-1659 because that removed the auto checking in cp_parser_template_type_arg which seemed like dead code. But the attached test shows that the code can still be reached because cp_parser_type_id_1 checks auto only when auto_is_implicit_function_template_parm_p is on. Then I noticed that we're still crashing in C++20, and that ICE started with r12-4772. So I changed the reemerged check to use flag_concepts_ts rather than flag_concepts on the basis that check_auto_in_tmpl_args also checks flag_concepts_ts. PR c++/110065 gcc/cp/ChangeLog: * parser.cc (cp_parser_template_type_arg): Add auto checking. gcc/testsuite/ChangeLog: * g++.dg/concepts/auto8.C: New test. * g++.dg/concepts/auto8a.C: New test.
[Bug c++/113360] [13/14 Regression] Truncated constexpr error messages with -std=c++23/26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113360
--- Comment #1 from Marek Polacek ---
The "deducing from brace-enclosed initializer" error is emitted during parsing
from listify. The body of init_list is not potentially-constant (due to
erroneous FOR_COND), so we register_constexpr_fundef it with result ==
error_mark_node.
require_rvalue_constant_expression in finish_static_assert thinks init_list is
potentially-constant, so we call cxx_constant_value. new_call.fundef->result
is error_mark_node so we don't bother evaluating the body. We call
explain_invalid_constexpr_fn but that has nothing to say, so we end up with a
missing reason.
But we already said what went wrong, so we shouldn't repeat it here anyway.
The body is:
{
int total = 0;
<>;
{
int x = <<< error >>>;
<<< error >>> __for_range;
<<< error >>> __for_begin;
<<< error >>> __for_end;
<<< Unknown tree: for_stmt
<<< error >>>
<<< error >>>
<>>;>>;
<(x)) >;
>>>;
}
return = VIEW_CONVERT_EXPR(total) == 6;
}
Can be reproduced in C++20 with -Wno-invalid-constexpr.
[Bug c++/109899] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Patrick Palka --- Fixed for GCC 12.4 / 13.3 / 14, thanks for the bug report.
[Bug c++/109899] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 --- Comment #12 from GCC Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:6477b3b9c3e5be5dfe549dcb7b3cef2b49e3690c commit r12-10098-g6477b3b9c3e5be5dfe549dcb7b3cef2b49e3690c Author: Patrick Palka Date: Mon Jan 15 16:49:19 2024 -0500 c++: non-dep array list-init w/ non-triv dtor [PR109899] The get_target_expr call added in r12-7069-g119cea98f66476 causes us for the below testcase to call build_vec_delete in a template context, which builds a templated destructor call and checks expr_noexcept_p for it, which ICEs because the call has templated form. Much of the work of build_vec_delete however is code generation and thus will just get discarded in a template context, and that includes the code guarded by expr_noexcept_p. So this patch narrowly fixes this ICE by eliding the expr_noexcept_p call when in a template context. PR c++/109899 gcc/cp/ChangeLog: * init.cc (build_vec_delete_1): Assume expr_noexcept_p returns false in a template context. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-array21.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit d33c3b5ac9b9b3e314ae9118d483ade7e91a80a5)
[Bug middle-end/113395] RTL expansion of bitfield accesses drops MEM_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113395 Andrew Pinski changed: What|Removed |Added Depends on||45274 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > I am almost positive there is a dup of this bug somewhere ... Yes PR 45274 where the aliasing set is 0 ... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45274 [Bug 45274] __restrict__ type qualifier does not work on pointers to bitfields
[Bug middle-end/113395] RTL expansion of bitfield accesses drops MEM_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113395 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-01-15 Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- I am almost positive there is a dup of this bug somewhere ...
[Bug c++/104634] Explicit template instantiation does not work when there are multiple partial template specialization using concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104634 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Patrick Palka --- Fixed for GCC 13.3 and 14, thanks for the bug report.
[Bug c++/109899] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 --- Comment #11 from GCC Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:766ea9da8ccff3786ec5df414046f6b1640e7e01 commit r13-8224-g766ea9da8ccff3786ec5df414046f6b1640e7e01 Author: Patrick Palka Date: Mon Jan 15 16:49:19 2024 -0500 c++: non-dep array list-init w/ non-triv dtor [PR109899] The get_target_expr call added in r12-7069-g119cea98f66476 causes us for the below testcase to call build_vec_delete in a template context, which builds a templated destructor call and checks expr_noexcept_p for it, which ICEs because the call has templated form. Much of the work of build_vec_delete however is code generation and thus will just get discarded in a template context, and that includes the code guarded by expr_noexcept_p. So this patch narrowly fixes this ICE by eliding the expr_noexcept_p call when in a template context. PR c++/109899 gcc/cp/ChangeLog: * init.cc (build_vec_delete_1): Assume expr_noexcept_p returns false in a template context. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-array21.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit d33c3b5ac9b9b3e314ae9118d483ade7e91a80a5)
[Bug c++/104634] Explicit template instantiation does not work when there are multiple partial template specialization using concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104634 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:854c9b682562b103f60e5f0a823f31df17a97568 commit r13-8225-g854c9b682562b103f60e5f0a823f31df17a97568 Author: Patrick Palka Date: Mon Jan 15 16:53:28 2024 -0500 c++: explicit inst w/ similar constrained partial specs [PR104634] Here we neglect to emit the definitions of A::f2 and A::f4 despite the explicit instantiations ultimately because TREE_PUBLIC isn't set on the corresponding partial specializations, whose declarations are created from maybe_new_partial_specialization which is responsible for disambiguating them from the first and third partial specializations (which have the same class-head but different constraints). This makes grokfndecl in turn clear TREE_PUBLIC for f2 and f4 as if they have internal linkage. This patch fixes this by setting TREE_PUBLIC appropriately for such partial specializations. PR c++/104634 gcc/cp/ChangeLog: * pt.cc (maybe_new_partial_specialization): Propagate TREE_PUBLIC to the newly created partial specialization. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-explicit-inst6.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit 47673571b28278d857371167f4b67a04a1b87b59)
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.3
[Bug c++/113405] Can't access member type alias of concept-constrained class template specialization in global module fragment via alias template in different module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113405 --- Comment #3 from Eddie Nolan --- Fixed (first two commands were superfluous): echo "module1 module1.gcm" >> ./module1.cpp.o.modmap echo "module2 module2.gcm" >> ./module2.cpp.o.modmap echo "module1 module1.gcm" >> ./module2.cpp.o.modmap g++ -I./include -g -std=c++20 -MD -MT ./module1.cpp.o -MF ./module1.cpp.o.d \ -fmodules-ts -fmodule-mapper=./module1.cpp.o.modmap -MD \ -fdeps-format=p1689r5 -x c++ -o ./module1.cpp.o -c ./module1.cpp g++ -g -std=c++20 -MD -MT ./module2.cpp.o -MF ./module2.cpp.o.d \ -fmodules-ts -fmodule-mapper=./module2.cpp.o.modmap -MD \ -fdeps-format=p1689r5 -x c++ -o ./module2.cpp.o -c ./module2.cpp
[Bug c++/104634] Explicit template instantiation does not work when there are multiple partial template specialization using concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104634 --- Comment #3 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:47673571b28278d857371167f4b67a04a1b87b59 commit r14-7261-g47673571b28278d857371167f4b67a04a1b87b59 Author: Patrick Palka Date: Mon Jan 15 16:53:28 2024 -0500 c++: explicit inst w/ similar constrained partial specs [PR104634] Here we neglect to emit the definitions of A::f2 and A::f4 despite the explicit instantiations ultimately because TREE_PUBLIC isn't set on the corresponding partial specializations, whose declarations are created from maybe_new_partial_specialization which is responsible for disambiguating them from the first and third partial specializations (which have the same class-head but different constraints). This makes grokfndecl in turn clear TREE_PUBLIC for f2 and f4 as if they have internal linkage. This patch fixes this by setting TREE_PUBLIC appropriately for such partial specializations. PR c++/104634 gcc/cp/ChangeLog: * pt.cc (maybe_new_partial_specialization): Propagate TREE_PUBLIC to the newly created partial specialization. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-explicit-inst6.C: New test. Reviewed-by: Jason Merrill
[Bug c++/104634] Explicit template instantiation does not work when there are multiple partial template specialization using concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104634 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Target Milestone|--- |13.3 --- Comment #4 from Patrick Palka --- Fixed on trunk so far.
[Bug c++/109899] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/109899] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 Patrick Palka changed: What|Removed |Added Summary|[12/13/14 Regression] ICE |[12/13 Regression] ICE in |in check_noexcept_r, at |check_noexcept_r, at |cp/except.cc:1065 |cp/except.cc:1065 CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #10 from Patrick Palka --- Fixed on trunk so far.
[Bug c++/109899] [12/13/14 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 --- Comment #9 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d33c3b5ac9b9b3e314ae9118d483ade7e91a80a5 commit r14-7260-gd33c3b5ac9b9b3e314ae9118d483ade7e91a80a5 Author: Patrick Palka Date: Mon Jan 15 16:49:19 2024 -0500 c++: non-dep array list-init w/ non-triv dtor [PR109899] The get_target_expr call added in r12-7069-g119cea98f66476 causes us for the below testcase to call build_vec_delete in a template context, which builds a templated destructor call and checks expr_noexcept_p for it, which ICEs because the call has templated form. Much of the work of build_vec_delete however is code generation and thus will just get discarded in a template context, and that includes the code guarded by expr_noexcept_p. So this patch narrowly fixes this ICE by eliding the expr_noexcept_p call when in a template context. PR c++/109899 gcc/cp/ChangeLog: * init.cc (build_vec_delete_1): Assume expr_noexcept_p returns false in a template context. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-array21.C: New test. Reviewed-by: Jason Merrill
[Bug libgcc/113403] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Jason Merrill --- This seems somewhat similar to the C++ issue that led to introducing STB_GNU_UNIQUE; a DSO keeping its own copy of something that we want to be shared. In the C++ case we were dealing with vague linkage variables that we have no control over, and decided that the first copy that gets loaded is used by all later DSOs, and so it can never be unloaded. Here, we have more control over the definition, and could say that everyone should get it from libgcc_s, as Jakub proposes. Or we could force it to be defined in the executable, so all DSOs will use the copy there. That latter might be another way to handle the STB_GNU_UNIQUE situation: if an executable links against a shared library that defines something STB_GNU_UNIQUE, copy the definition from the library into the executable? That would avoid the dlclose problem.
[Bug c++/113405] Can't access member type alias of concept-constrained class template specialization in global module fragment via alias template in different module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113405 --- Comment #2 from Eddie Nolan --- This series of commands reproduces the issue and does not use CMake: g++ -g -std=c++20 -E -x c++ ./module2.cpp \ -MT ./module2.cpp.o.ddi -MD -MF ./module2.cpp.o.ddi.d \ -fmodules-ts -fdeps-file=./module2.cpp.o.ddi -fdeps-target=./module2.cpp.o \ -fdeps-format=p1689r5 -o ./module2.cpp.o.ddi.i g++ -I./include -g -std=c++20 -E -x c++ ./module1.cpp \ -MT ./module1.cpp.o.ddi -MD -MF ./module1.cpp.o.ddi.d \ -fmodules-ts -fdeps-file=./module1.cpp.o.ddi -fdeps-target=./module1.cpp.o \ -fdeps-format=p1689r5 -o ./module1.cpp.o.ddi.i echo "module1 module1.gcm" >> ./module1.cpp.o.modmap echo "module2 module2.gcm" >> ./module2.cpp.o.modmap echo "module1 module1.gcm" >> ./module2.cpp.o.modmap g++ -I./include -g -std=c++20 -MD -MT ./module1.cpp.o -MF ./module1.cpp.o.d \ -fmodules-ts -fmodule-mapper=./module1.cpp.o.modmap -MD \ -fdeps-format=p1689r5 -x c++ -o ./module1.cpp.o -c ./module1.cpp g++ -g -std=c++20 -MD -MT ./module2.cpp.o -MF ./module2.cpp.o.d \ -fmodules-ts -fmodule-mapper=./module2.cpp.o.modmap -MD \ -fdeps-format=p1689r5 -x c++ -o ./module2.cpp.o -c ./module2.cpp
[Bug tree-optimization/113410] New: ICE: in maybe_check_access_sizes, at gimple-ssa-warn-access.cc:3423 with _BitInt() used as array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113410 Bug ID: 113410 Summary: ICE: in maybe_check_access_sizes, at gimple-ssa-warn-access.cc:3423 with _BitInt() used as array length Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57096 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57096=edit reduced testcase This is reduced from gcc.dg/builtin-dynamic-object-size-20.c, when testsuite is run with -Dint=_BitInt($RANDOM) Compiler output: $ x86_64-pc-linux-gnu-gcc testcase.c during GIMPLE pass: waccess testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: in maybe_check_access_sizes, at gimple-ssa-warn-access.cc:3423 4 | foo (int n) | ^~~ 0x783992 maybe_check_access_sizes /repo/gcc-trunk/gcc/gimple-ssa-warn-access.cc:3423 0x1186c57 check_call_access /repo/gcc-trunk/gcc/gimple-ssa-warn-access.cc:3644 0x1186c57 check_call /repo/gcc-trunk/gcc/gimple-ssa-warn-access.cc:4351 0x1186c57 check_block /repo/gcc-trunk/gcc/gimple-ssa-warn-access.cc:4434 0x1186c57 execute /repo/gcc-trunk/gcc/gimple-ssa-warn-access.cc:4769 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7255-20240115165927-g6c703b4eb68-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-7255-20240115165927-g6c703b4eb68-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240115 (experimental) (GCC)
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
--- Comment #9 from john.harper at vuw dot ac.nz ---
This variant of my test program (now called test4) hangs with gfortran
but not with other compilers if iam is written to output_unit (like the
original version) or to a file with a different positive unit number, but
it does not hang if written to a file with a negative unit number obtained
by opening it with newunit=u. Its user has those 3 choices at run time.
I hope it helps you explore this oddity of gfortran.
program test4
use iso_fortran_env, only: output_unit
! Linux with f2008 (newunit=, execute_command_line, allocatable scalar)
implicit none
integer:: u = output_unit+20
character:: ch*1, line(2)*80
print "(A)",'Output from iam will go to unit u;', &
' u=output_unit if you enter a, or',&
' unit=u (u>0) if you enter b, or',&
' newunit=u (u<0) if you enter anything else.'
read "(A)", ch
if(ch=='a') then
u = output_unit
else if(ch=='b') then
open( unit=u,file='test4.out')
else
open(newunit=u,file='test4.out')
end if
print "(A,I0)",'Output from iam will be written to unit ',u
write(u,"(A,L2)")'I am john',iam('john')
write(u,"(A,L2)")'I am JOHN',iam('JOHN')
if(u/=output_unit) then
rewind u
read(u,"(A)") line
print "(A)", line
close(u,status='delete')
end if
contains
logical function iam( name)
character(*),intent(in)::name
integer estat
character(:),allocatable:: cmd
cmd = 'if [ `whoami` != "'//name//'" ]; then exit 1; else exit 0; fi'
call execute_command_line(cmd,exitstat=estat)
iam = (estat==0)
end function iam
end program test4
-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz
[Bug tree-optimization/113409] New: ICE: in omp_extract_for_data, at omp-general.cc:411 with -fopenmp-simd and _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113409 Bug ID: 113409 Summary: ICE: in omp_extract_for_data, at omp-general.cc:411 with -fopenmp-simd and _BitInt() Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57095 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57095=edit reduced testcase This is reduced from gcc.dg/ipa/pr90555.c, when testsuite is run with -Dint=_BitInt($RANDOM) Compiler output: $ x86_64-pc-linux-gnu-gcc -fopenmp-simd testcase.c during GIMPLE pass: omplower testcase.c: In function 'test_simduid2': testcase.c:9:9: internal compiler error: in omp_extract_for_data, at omp-general.cc:411 9 | #pragma omp simd reduction(+: c2) | ^~~ 0x7cb15b omp_extract_for_data(gomp_for*, omp_for_data*, omp_for_data_loop*) /repo/gcc-trunk/gcc/omp-general.cc:411 0x137d0c9 lower_omp_for /repo/gcc-trunk/gcc/omp-low.cc:11782 0x1368804 lower_omp_1 /repo/gcc-trunk/gcc/omp-low.cc:14388 0x1368804 lower_omp /repo/gcc-trunk/gcc/omp-low.cc:14590 0x13681db lower_omp_1 /repo/gcc-trunk/gcc/omp-low.cc:14372 0x13681db lower_omp /repo/gcc-trunk/gcc/omp-low.cc:14590 0x136c420 execute_lower_omp /repo/gcc-trunk/gcc/omp-low.cc:14629 0x136c420 execute /repo/gcc-trunk/gcc/omp-low.cc:14683 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7255-20240115165927-g6c703b4eb68-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-7255-20240115165927-g6c703b4eb68-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240115 (experimental) (GCC)
[Bug c++/113407] [11/12/13/14 Regression] internal_error with const char* as non-type template parameter with index parameter pack in fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113407 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-01-15 Known to work||11.1.0 Known to fail||11.2.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Severity|normal |trivial Summary|internal_error with const |[11/12/13/14 Regression] |char* as non-type template |internal_error with const |parameter with index|char* as non-type template |parameter pack in fold |parameter with index |expression |parameter pack in fold ||expression Target Milestone|--- |11.5 --- Comment #1 from Andrew Pinski --- Confirmed. Looks like the code which crashes: PACK_EXPANSION_LOCAL_P (result) = PACK_EXPANSION_LOCAL_P (t); PACK_EXPANSION_SIZEOF_P (result) = PACK_EXPANSION_SIZEOF_P (t); was added with r12-701-ge7a9f085ffd34b0d7bc4b803c182b41 . Note GCC 12+/11.2.0 will crash too if checking is enabled.
[Bug libgcc/113402] Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr in libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402 --- Comment #3 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #2) > Created attachment 57087 [details] > gcc14-pr113402.patch > > > Though, I wonder if we also shouldn't rename those symbols, having __builtin_ > prefix in the names is highly undesirable. We can easily do this now, if needed; since this is the first release it would have least impact.
[Bug tree-optimization/113408] New: ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at -O with _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113408 Bug ID: 113408 Summary: ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at -O with _BitInt() Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57094 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57094=edit reduced testcase This is reduced from gcc.c-torture/execute/pr82387.c, when testsuite is run with -Dint=_BitInt($RANDOM) Compiler output: $ x86_64-pc-linux-gnu-gcc -O testcase.c during GIMPLE pass: bitintlower testcase.c: In function 'foo': testcase.c:8:1: internal compiler error: in handle_cast, at gimple-lower-bitint.cc:1539 8 | foo(void) | ^~~ 0xd88b9a handle_cast /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:1539 0x2707c50 handle_operand /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:815 0x2713592 lower_mergeable_stmt /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2462 0x2717a7d lower_stmt /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5336 0x271a499 gimple_lower_bitint /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6530 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7255-20240115165927-g6c703b4eb68-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-7255-20240115165927-g6c703b4eb68-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240115 (experimental) (GCC)
[Bug c++/113407] New: internal_error with const char* as non-type template parameter with index parameter pack in fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113407
Bug ID: 113407
Summary: internal_error with const char* as non-type template
parameter with index parameter pack in fold expression
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: miro.palmu at helsinki dot fi
Target Milestone: ---
Created attachment 57093
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57093=edit
The preprocessed source from -freport-bug
I have piece of code that should not compile due to parameter pack not located
at the end of template parameter list. However gcc 14.0.1 20240115 gives
internal compiler error while gcc 13 and earlier do not give internal errors
and the compilation fails gracefully.
Here is the code:
```
// index_sequence implementation:
template struct index_sequence;
template
struct index_sequence{ };
template
struct index_sequence_helper;
template
struct index_sequence_helper <0, I...> {
using type = index_sequence;
};
template
struct index_sequence_helper : public index_sequence_helper { };
template
auto make_index_sequence() -> index_sequence_helper::type {};
// Helpers:
template
void inner_func(char) {}
template
struct Foo {};
constexpr char global_string[] = "abc";
template
bool func() {
return [](index_sequence) {
return (inner_func>(C[I]), ...);
}(make_index_sequence{});
}
int main() {
func();
}
```
It also seems that the const char* being non-type template parameter and not a
normal function parameter is important for the internal_error.
Here is the error message (compile command: g++ error.cpp):
```
error.cpp:19:31: error: need ‘typename’ before ‘index_sequence_helper::type’
because ‘index_sequence_helper’ is a dependent scope
19 | auto make_index_sequence() -> index_sequence_helper::type {};
| ^~~~
| typename
error.cpp:26:11: error: parameter pack ‘T’ must be at the end of the template
parameter list
26 | template
| ^~~~
error.cpp: In lambda function:
error.cpp:35:38: note: so any instantiation with a non-empty parameter pack
would be ill-formed
35 | return (inner_func>(C[I]), ...);
| ^
error.cpp: In function ‘bool func()’:
error.cpp:36:7: error: ‘make_index_sequence’ was not declared in this scope;
did you mean ‘index_sequence’?
36 | }(make_index_sequence{});
| ^~~
| index_sequence
error.cpp:36:40: error: expected primary-expression before ‘{’ token
36 | }(make_index_sequence{});
|^
error.cpp: In instantiation of ‘bool func() [with const char* C = (&
global_string); A = {}]’:
error.cpp:40:24: required from here
error.cpp:36:40: error:40 | func();
error.cpp:36:40: error: | ~~~^~
error.cpp:35:47: internal compiler error: tree check: expected
type_pack_expansion or expr_pack_expansion, have error_mark in
tsubst_pack_expansion, at cp/pt.cc:13632
35 | return (inner_func>(C[I]), ...);
|~~~^~
0x951506 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
.././../gcc/tree.cc:8952
0x7edbaf tree_check2(tree_node*, char const*, int, char const*, tree_code,
tree_code)
.././../gcc/tree.h:3631
0x7edbaf tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
.././../gcc/cp/pt.cc:13632
0xc784c4 tsubst_fold_expr_pack
.././../gcc/cp/pt.cc:13043
0xc784c4 tsubst_unary_right_fold
.././../gcc/cp/pt.cc:13159
0xc5994a tsubst_expr(tree_node*, tree_node*, int, tree_node*)
.././../gcc/cp/pt.cc:21547
0xc68147 tsubst_stmt
.././../gcc/cp/pt.cc:19384
0xc69108 tsubst_stmt
.././../gcc/cp/pt.cc:18351
0xc68d72 tsubst_stmt
.././../gcc/cp/pt.cc:18714
0xc7e4d0 tsubst_stmt
.././../gcc/cp/pt.cc:18327
0xc7e4d0 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
.././../gcc/cp/pt.cc:19732
0xc5b944 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
.././../gcc/cp/pt.cc:21629
0xc58482 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
.././../gcc/cp/pt.cc:20670
0xc68147 tsubst_stmt
.././../gcc/cp/pt.cc:19384
0xc69108 tsubst_stmt
.././../gcc/cp/pt.cc:18351
0xc6918f tsubst_stmt
.././../gcc/cp/pt.cc:18327
0xc6918f tsubst_stmt
.././../gcc/cp/pt.cc:18341
0xc68d72 tsubst_stmt
.././../gcc/cp/pt.cc:18714
0xc66ea2 tsubst_stmt
.././../gcc/cp/pt.cc:18327
0xc66ea2 instantiate_body
.././../gcc/cp/pt.cc:26974
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
[Bug libgcc/113403] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 --- Comment #5 from Iain Sandoe --- Sorry, my intended design was not stated very clearly. 1. IIUC, the objective is to have only one instance of these symbols in the dynamically-linked program. 2. One way to ensure that is to make it a requirement that all DSOs that need these must link with libgcc_s. - However, that is not always what the user wants to do and might link a DSO with -static-libgcc - it makes DSOs built with GCC more difficult to use with other compilers. 3. An alternate solution is to have COMDAT/Weak Definitions (I'm not sure if I've got exactly the right terminology for ELF; Weak Definition is the right one for Mach-o). - then the dynamic linker picks only one in the loaded program, so the duplication is avoided - this also works when DSOs are used with a foreign compiler without libgcc_s --- For my ports the second is the most practical, since my downsteams use GCC and clang together, but I have no strong opinion on what should be done in general.
[Bug tree-optimization/113406] New: ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -fstrub=internal and _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113406 Bug ID: 113406 Summary: ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -fstrub=internal and _BitInt() Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57092 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57092=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -fstrub=internal testcase.c during GIMPLE pass: bitintlower0 testcase.c: In function 'foo': testcase.c:2:1: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 2 | foo(void) | ^~~ 0x89127d tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) /repo/gcc-trunk/gcc/tree.cc:9002 0x77c702 tree_class_check(tree_node*, tree_code_class, char const*, int, char const*) /repo/gcc-trunk/gcc/tree.h:3767 0x77c702 useless_type_conversion_p(tree_node*, tree_node*) /repo/gcc-trunk/gcc/gimple-expr.cc:85 0x15540a4 verify_gimple_return /repo/gcc-trunk/gcc/tree-cfg.cc:4888 0x15540a4 verify_gimple_stmt /repo/gcc-trunk/gcc/tree-cfg.cc:5125 0x1558311 verify_gimple_in_cfg(function*, bool, bool) /repo/gcc-trunk/gcc/tree-cfg.cc:5602 0x13c83d4 execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2088 0x13c892e execute_todo /repo/gcc-trunk/gcc/passes.cc:2142 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7255-20240115165927-g6c703b4eb68-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-7255-20240115165927-g6c703b4eb68-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240115 (experimental) (GCC)
[Bug c++/113405] Can't access member type alias of concept-constrained class template specialization in global module fragment via alias template in different module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113405 Andrew Pinski changed: What|Removed |Added Blocks||103524 --- Comment #1 from Andrew Pinski --- It would be useful if you don't use cmake here since it is so simple to figure out the full command line for building here. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 [Bug 103524] [meta-bug] modules issue
[Bug c++/110065] [11/12/13/14 Regression] [C++20/2b] auto return type in template argument causes ICE, also accepts-invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110065 --- Comment #4 from Marek Polacek --- With -std=c++20 the ICE started with r12-4772.
[Bug c++/113405] New: Can't access member type alias of concept-constrained class template specialization in global module fragment via alias template in different module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113405
Bug ID: 113405
Summary: Can't access member type alias of concept-constrained
class template specialization in global module
fragment via alias template in different module
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eddiejnolan at gmail dot com
Target Milestone: ---
This example shows GCC failing to resolve the member type alias "foobar" in a
concept-constrained specialization of class template "corge" when it's accessed
from module2 via an alias template in module1.
Compiler explorer link: https://godbolt.org/z/4sh6xG6P4
Minimal reproduction:
// CMakeLists.txt
cmake_minimum_required(VERSION 3.28)
project(repro CXX)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_library(module1)
target_sources(module1
PUBLIC
FILE_SET cxx_modules TYPE CXX_MODULES FILES
module1.cpp
)
target_include_directories(module1 PRIVATE "include/")
add_library(module2)
target_sources(module2
PUBLIC
FILE_SET cxx_modules TYPE CXX_MODULES FILES
module2.cpp
)
target_link_libraries(module2 PUBLIC module1)
// include/foo.h
template
concept foo = false;
template
concept bar = true;
template
struct corge {};
template
struct corge {};
template
struct corge {
using foobar = int;
};
// module1.cpp
module;
#include "foo.h"
export module module1;
export template
using corge_alias = corge::foobar;
// module2.cpp
export module module2;
import module1;
struct foobaz{};
using quux = corge_alias;
[Bug testsuite/113369] Many tests with -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113369 --- Comment #5 from H.J. Lu --- Created attachment 57091 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57091=edit The list of compile tests with -save-temps
[Bug testsuite/113369] Many tests with -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113369 --- Comment #4 from H.J. Lu --- I removed -save-temps from some compile tests I can run on x86-64.
[Bug testsuite/113369] Many tests with -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113369 H.J. Lu changed: What|Removed |Added Attachment #57063|0 |1 is obsolete|| --- Comment #3 from H.J. Lu --- Created attachment 57090 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57090=edit The list of tests with -save-temps
[Bug testsuite/113369] Many tests with -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113369 --- Comment #2 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:8108c6be99d23d799e2d00eec3d7d3e51cbd33f3 commit r14-7257-g8108c6be99d23d799e2d00eec3d7d3e51cbd33f3 Author: H.J. Lu Date: Mon Jan 15 11:18:41 2024 -0800 Remove --save-temps from some compile tests --save-temps is needed to scan assembly outputs for assemble, link and run tests. Not all compile tests need --save-temps unless they used to trigger GCC bugs. Run --save-temps from compile tests if not needed. PR testsuite/113369 * g++.dg/abi/ref-temp1.C: Remove --save-temps. * g++.target/i386/bfloat_cpp_typecheck.C: Likewise. * gcc.dg/debug/dwarf2/pr111080.c: Likewise. * gcc.dg/debug/dwarf2/pr47939-1.c: Likewise. * gcc.dg/debug/dwarf2/pr47939-2.c: Likewise. * gcc.dg/debug/dwarf2/pr47939-3.c: Likewise. * gcc.dg/debug/dwarf2/pr47939-4.c: Likewise.
[Bug libstdc++/109203] sort(zip(v1, v2)) fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109203 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Patrick Palka --- I can start working on implementing P2165.
[Bug c/113396] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #3 from David Binderman --- Created attachment 57089 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57089=edit C source code Partly reduced C source code.
[Bug c/113396] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #2 from David Binderman --- The bug seems to exist from sometime before g:d042f118798ae0648b45f97e63b0e5ab7c82c8ef, dated 20230205.
[Bug c++/113347] [12/13 Regression] ICE during gimplification building TVM since r13-8079-gd237e7b291ff52
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113347 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #7 from Marek Polacek --- I cannot figure out what fixed it on trunk because r14-5086 doesn't ICE for me.
[Bug libstdc++/108822] [C++23] Implement P2255R2, type trait to detect reference binding to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108822 --- Comment #6 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1e88a151f878e0a139bf55eb0cee2506fb903274 commit r14-7256-g1e88a151f878e0a139bf55eb0cee2506fb903274 Author: Jonathan Wakely Date: Mon Jan 15 16:51:39 2024 + libstdc++: Fix redefinition error in std::tuple [PR108822] When using a compiler that doesn't define __cpp_conditional_explicit there's a redefinition error for tuple::__nothrow_assignable. This is because it's defined in different places for the pre-C++20 and C++20 implementations, which are controled by different preprocessor conditions. For certain combinations of C++20 feature test macros it's possible for both __nothrow_assignable definitions to be in scope. Move the pre-C++20 __assignable and __nothrow_assignable definitions adjacent to their use, so that only one set of definitions is visible for any given set of feature test macros. libstdc++-v3/ChangeLog: PR libstdc++/108822 * include/std/tuple (__assignable, __is_nothrow_assignable): Move pre-C++20 definitions adjacent to their use.
[Bug c++/113389] ICE when explicit object parameter is not declared as the first parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113389 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-01-15
[Bug target/113404] New: ICE: in to_constant, at poly-int.h:588 with -march=rv64gcv -mbig-endian --param=riscv-vector-abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113404
Bug ID: 113404
Summary: ICE: in to_constant, at poly-int.h:588 with
-march=rv64gcv -mbig-endian --param=riscv-vector-abi
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu
Created attachment 57088
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57088=edit
reduced testcase
This has been reduced from
gcc.target/riscv/rvv/base/float-point-dynamic-frm-66.c
Compiler output:
$ riscv64-unknown-linux-gnu-gcc -march=rv64gcv -mbig-endian
--param=riscv-vector-abi a-float-point-dynamic-frm-66.i
a-float-point-dynamic-frm-66.i: In function 'test_float_point_dynamic_frm':
a-float-point-dynamic-frm-66.i:2:14: warning: ABI for the vector type is
currently in experimental stage and may changes in the upcoming version of GCC.
[-Wpsabi]
2 | vfloat32m1_t test_float_point_dynamic_frm(vfloat32m1_t) {}
| ^~~~
during RTL pass: expand
a-float-point-dynamic-frm-66.i:2:14: internal compiler error: in to_constant,
at poly-int.h:588
0xab4c2c poly_int<2u, unsigned short>::to_constant() const
/repo/gcc-trunk/gcc/poly-int.h:588
0xab4de1 poly_int<2u, unsigned short>::to_constant() const
/repo/gcc-trunk/gcc/tree.h:4055
0xab4de1 default_function_arg_padding(machine_mode, tree_node const*)
/repo/gcc-trunk/gcc/targhooks.cc:844
0x12e2327 locate_and_pad_parm(machine_mode, tree_node*, int, int, int,
tree_node*, args_size*, locate_and_pad_arg_data*)
/repo/gcc-trunk/gcc/function.cc:4061
0x12e2aca assign_parm_find_entry_rtl
/repo/gcc-trunk/gcc/function.cc:2614
0x12e2c89 assign_parms
/repo/gcc-trunk/gcc/function.cc:3693
0x12e59df expand_function_start(tree_node*)
/repo/gcc-trunk/gcc/function.cc:5152
0x112fafb execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6739
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7255-20240115165927-g6c703b4eb68-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-7255-20240115165927-g6c703b4eb68-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240115 (experimental) (GCC)
[Bug libgcc/113403] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- (In reply to Florian Weimer from comment #2) > Weak symbols have no meaning for ELF DSOs, so this wouldn't work for > libgcc_s on ELF targets. Instead we automatically link against dynamic > libgcc_s if certain symbols not in libgcc.a are referenced. Sources built > with -ftrampoline-impl=heap -fexceptions can already trigger such a > dependency for _Unwind_Resume because it's used in the cleanup handler, for > example. What we could do is make -shared-libgcc the default when using -ftrampoline-impl=heap (similarly how linking with g++ instead of gcc makes it the default), obviously unless use explicitly asks for -static-libgcc or -shared-libgcc.
[Bug libgcc/113403] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 --- Comment #3 from Iain Sandoe --- (In reply to Florian Weimer from comment #2) > Weak symbols have no meaning for ELF DSOs, so this wouldn't work for > libgcc_s on ELF targets. Instead we automatically link against dynamic > libgcc_s if certain symbols not in libgcc.a are referenced. Sources built > with -ftrampoline-impl=heap -fexceptions can already trigger such a > dependency for _Unwind_Resume because it's used in the cleanup handler, for > example. So if we remove these symbols from libgcc.a and then the user builds with -static-libgcc - that would just be an error (presumably at runtime if ld allows undefined symbols). I'm not clear about what the scope of "we automatically link against dynamic libgcc_s" is in that case. Assuming that omitting the symbols from libgcc.a means either linking against libgcc_s or providing them from some other source when -static-libgcc is given: - we could use a CRT for that. - I suppose we could also add these symbols to libgcc_eh for that case - but that proved to be a bad choice for emuTLS, so it would also need to be configured per platform. On platforms like Mach-O, the strategy I outlined will work OK (this is configurable per target, so should be OK).
[Bug testsuite/113366] g++.dg/cpp2a/concepts-pr67774.C FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113366 --- Comment #4 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6c703b4eb68cbc32de1d62e5b573cb1b9857af29 commit r14-7255-g6c703b4eb68cbc32de1d62e5b573cb1b9857af29 Author: Jonathan Wakely Date: Sat Jan 13 12:13:33 2024 + libstdc++: Use variable template to fix -fconcepts-ts error [PR113366] There's an error for -fconcepts-ts due to using a concept where a bool NTTP is required, which is fixed by using the vraiable template that already exists in the class scope. This doesn't fix the problem with -fconcepts-ts as changes to the placement of attributes is also needed. libstdc++-v3/ChangeLog: PR testsuite/113366 * include/std/format (basic_format_arg): Use __formattable variable template instead of __format::__formattable_with concept.
[Bug libgcc/113403] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 --- Comment #2 from Florian Weimer --- Weak symbols have no meaning for ELF DSOs, so this wouldn't work for libgcc_s on ELF targets. Instead we automatically link against dynamic libgcc_s if certain symbols not in libgcc.a are referenced. Sources built with -ftrampoline-impl=heap -fexceptions can already trigger such a dependency for _Unwind_Resume because it's used in the cleanup handler, for example.
[Bug libgcc/113403] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 --- Comment #1 from Iain Sandoe --- this seems a somewhat similar dilemma to the emulated TLS case. Perhaps: provide a weak definition of these in a CRT (which is used for -static-libgcc) and weaken the defs in libgcc_s so that mixed scenarios work?
[Bug libgcc/113402] Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr in libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2024-01-15 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 57087 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57087=edit gcc14-pr113402.patch Untested fix. Though, I wonder if we also shouldn't rename those symbols, having __builtin_ prefix in the names is highly undesirable. Weren't we contemplating disabling support of defining or even declaring __builtin_* functions/variables altogether several times?
[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401 --- Comment #2 from Florian Weimer --- (In reply to Iain Sandoe from comment #1) > (In reply to Florian Weimer from comment #0) > > > The fix is to register a TLS destructor to > > deallocate that page, too. On glibc, that also fixes another memory leak for > > -fno-exceptions compilations (the default for C) if pthread_exit is called > > with an active trampoline. > > Does this mean you have a proposed patch already? (before I start > investigation) No, this was a reference to __cxa_thread_atexit, which is unfortunately in libstdc++ (but is a thin shim around __cxa_thread_atexit_impl for current glibc). The pthread_key_create fallback probably needs to be duplicated into libgcc_s.
[Bug tree-optimization/113374] [14 regression] ICE in find_uses_to_rename_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113374
--- Comment #8 from Jakub Jelinek ---
Slightly cleaned up testcase, -O3 -msse4 is what is needed to reproduce:
typedef __SIZE_TYPE__ size_t;
struct S { unsigned char *a, *b; };
void
foo (struct S x)
{
for (size_t i = x.b - x.a; i > 0; --i)
{
size_t t = x.b - x.a;
size_t u = i - 1;
if (u >= t)
__builtin_abort ();
if (x.a[i - 1]--)
break;
}
}
[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #1 from Iain Sandoe --- (In reply to Florian Weimer from comment #0) > The fix is to register a TLS destructor to > deallocate that page, too. On glibc, that also fixes another memory leak for > -fno-exceptions compilations (the default for C) if pthread_exit is called > with an active trampoline. Does this mean you have a proposed patch already? (before I start investigation)
[Bug tree-optimization/113379] `MIN == MAX` should be optimzed to `a == b`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113379 --- Comment #2 from Joseph S. Myers --- Note that some of these aren't valid for floating point in the presence of NaNs.
[Bug libgcc/113402] Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr in libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402 --- Comment #1 from Florian Weimer --- I should say I have only tested this on x86-64, but it is likely that this impacts other supported ABIs as well.
[Bug libgcc/113403] New: __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 Bug ID: 113403 Summary: __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- There are hidden definitions of __builtin_nested_func_ptr_created, __builtin_nested_func_ptr in libgcc.a. As a result of the default link order, the exported global definitions of these functions in libgcc_s.so.1 are never used. This is unfortunate because it means that every DSO that creates a trampoline gets its own trampoline cache (one TLS variable and two data pages for trampolines), increasing the overhead of this feature significantly.
[Bug libgcc/113402] New: Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402 Bug ID: 113402 Summary: Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- The symbols are about to be added to GCC 14, but they use a GCC_7.0.0 symbol version in libgcc_s. The set of symbols associated with a version cannot be changed after a release, otherwise dependency management based on symbol versions does not work.
[Bug rtl-optimization/113048] [13 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1862 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -march=cascadelake since r13-17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113048
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] ICE: in |[13 Regression] ICE: in
|lra_split_hard_reg_for, at |lra_split_hard_reg_for, at
|lra-assigns.cc:1862 (unable |lra-assigns.cc:1862 (unable
|to find a register to |to find a register to
|spill) |spill)
|{*andndi3_doubleword_bmi} |{*andndi3_doubleword_bmi}
|with -march=cascadelake |with -march=cascadelake
|since r13-1716 |since r13-1716
--- Comment #10 from Jakub Jelinek ---
Fixed on the trunk so far.
[Bug rtl-optimization/113048] [13/14 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1862 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -march=cascadelake since r13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113048 --- Comment #9 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2e493b697a4cb135b0af6944d0c1f3c8f59e8caf commit r14-7253-g2e493b697a4cb135b0af6944d0c1f3c8f59e8caf Author: Jakub Jelinek Date: Mon Jan 15 17:35:04 2024 +0100 testsuite: Add testcase for already fixed PR [PR113048] The ICE on this testcase was fixed by r14-7141. 2024-01-15 Jakub Jelinek PR rtl-optimization/113048 * gcc.target/i386/pr113048.c: New test.
[Bug target/113401] New: Memory (resource) leak in -ftrampoline-impl=heap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401
Bug ID: 113401
Summary: Memory (resource) leak in -ftrampoline-impl=heap
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*, aarch64-*
Consider this test program:
#include
#include
#include
static void *volatile compiler_barrier;
void *
thread_routine (void *ignore)
{
int local_variable;
auto int *local_function (void)
{
return _variable;
}
compiler_barrier = local_function;
return NULL;
}
int
main (void)
{
for (int i = 0; i < 1; ++i)
{
pthread_t thread;
int ret = pthread_create (, NULL, thread_routine, NULL);
if (ret != 0)
{
errno = ret;
err (1, "pthread_create");
}
ret = pthread_join (thread, NULL);
if (ret != 0)
{
errno = ret;
err (1, "pthread_join");
}
}
}
With -ftrampoline-impl=stack, I get:
$ \time ./a.out
0.01user 0.16system 0:00.18elapsed 102%CPU (0avgtext+0avgdata 3008maxresident)k
0inputs+0outputs (0major+68minor)pagefaults 0swaps
With -ftrampoline-impl=heap:
$ \time ./a.out
0.03user 0.17system 0:00.20elapsed 101%CPU (0avgtext+0avgdata
41796maxresident)k
0inputs+0outputs (0major+10148minor)pagefaults 0swaps
The reason for the maxresident change is that __builtin_nested_func_ptr_created
and __builtin_nested_func_ptr_deleted cache the last trampoline page even if it
is completely unused. This is required for performance reasons. The fix is to
register a TLS destructor to deallocate that page, too. On glibc, that also
fixes another memory leak for -fno-exceptions compilations (the default for C)
if pthread_exit is called with an active trampoline.
[Bug ada/113397] [14 Regression] ICE: SIGSEGV in tree_check (tree.h:3611) with -fdump-ada-spec-slim on gcc.c-torture/execute/pr22061-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113397 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-15 --- Comment #3 from Eric Botcazou --- Yes, probably just: diff --git a/gcc/c-family/c-ada-spec.cc b/gcc/c-family/c-ada-spec.cc index 7d886c0f92e..4b245ed6975 100644 --- a/gcc/c-family/c-ada-spec.cc +++ b/gcc/c-family/c-ada-spec.cc @@ -1566,6 +1566,8 @@ check_type_name_conflict (pretty_printer *buffer, tree t) s = ""; else if (TREE_CODE (TYPE_NAME (tmp)) == IDENTIFIER_NODE) s = IDENTIFIER_POINTER (TYPE_NAME (tmp)); + else if (!DECL_NAME (TYPE_NAME (tmp))) + s = ""; else s = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (tmp)));
[Bug c++/110997] [13 Regression] internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.cc:8005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110997 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|mpolacek at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #7 from Marek Polacek --- I do not think that r14-4140-g6851e3423c2b5e is backportable to 13.
[Bug rtl-optimization/113048] [13/14 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1862 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -march=cascadelake since r13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113048 --- Comment #8 from Uroš Bizjak --- (In reply to Vladimir Makarov from comment #7) > I believe this PR was recently fixed by > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git; > h=a729b6e002fe76208f33fdcdee49d6a310a1940e Yes, I can confirm that the test compiles OK with recent: xgcc (GCC) 14.0.1 20240115 (experimental) [master r14-7251-g04f22670d32]
