[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695 Aldy Hernandez changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #16 from Aldy Hernandez --- Is there a way to measure peak memory usage in the compiler? I'd like to gather some stats. Also do we have a handful of programs we typically use to measure memory usage? ISTR that Richard (??) had a set of memory hog programs.
[Bug tree-optimization/54627] VRP uses lots of memory and compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54627 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #3 from Aldy Hernandez --- Just ran into this while looking for something else. Should this be closed, as the implementation of VRP is different now? (i.e. no equivalence set bitmaps).
[Bug tree-optimization/104357] Failure to use csinv instead of mvn+csel where possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104357 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > One thing I should note: > _7 = x_3(D) >= 0; > _6 = (unsigned char) _7; > _8 = -_6; > > Should be done on the gimple level as: > t = x_3(D) >> (sizeof(x_3(D))*8 - 1) > _8 = (unsigned char)t; Actually it is: _2 = x_3(D) >> 31; _5 = ~_2; _8 = (unsigned char) _5;
[Bug c++/109678] [13/14 Regression] exponential time behavior on std::variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109678 --- Comment #7 from Quentin Sabah --- @jason Thanks for the fix!
[Bug libfortran/109662] bad namelist input but gfortran accepted it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662 --- Comment #6 from john.harper at vuw dot ac.nz --- OK by me but I'm not in charge of gfortran! On Thu, 4 May 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Thu, 4 May 2023 03:05:49 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted it > Resent-Date: Thu, 4 May 2023 15:05:59 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662 > > --- Comment #5 from Jerry DeLisle --- > Is this acceptable: > > $ ./a.out > Compiler version = GCC version 14.0.0 20230424 (experimental) > Compiler options = -mtune=generic -march=x86-64 -Wpedantic > -fpre-include=/usr/include/finclude/math-vector-fortran.h > At line 9 of file pr109662.f90 > Fortran runtime error: Comma after namelist name not allowed > > Should I allow it with -std=legacy? > > -- > You are receiving this mail because: > You reported the bug. > -- 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 phone +64(0) 4 463 5276
[Bug target/53929] [meta-bug] -masm=intel with global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #13 from LIU Hao ---
dup notwithstanding, I think I had better copy my recommendation here for
reference:
This is how MSVC handles such names:
(https://gcc.godbolt.org/z/TonjYaxqj)
```
static int* volatile rip;
static unsigned int volatile eax;
int
get_value(void)
{
return rip[eax];
}
```
MSVC outputs:
```
get_value PROC ; COMDAT
mov ecx, DWORD PTR eax
mov rax, QWORD PTR rip
mov eax, DWORD PTR [rax+rcx*4]
ret 0
get_value ENDP
```
GCC outputs:
```
get_value:
mov rdx, QWORD PTR rip[rip]
mov eax, DWORD PTR eax[rip]
mov eax, DWORD PTR [rdx+rax*4]
ret
```
In the case of MSVC, `DWORD PTR eax` is unambiguously parsed as the label `eax`
and `DWORD PTR [eax]` is unambiguously parsed as the register `eax`. The
address of all labels are always relative to RIP, but it is implied, and
brackets are not written explicitly.
Maybe GCC can follow MSVC to omit the RIP register and brackets. The x86_64
memory reference syntax matches x86 with the only change in semantics of the
immediate offset (for x86_64 it is relative to the next instruction, while for
i686 it is absolute), but the opcode is the same.
[Bug target/109725] [14 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in riscv_print_operand, at config/riscv/riscv.cc:4430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109725
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-04
Status|UNCONFIRMED |NEW
Target Milestone|--- |14.0
Ever confirmed|0 |1
Keywords||ice-checking
--- Comment #1 from Andrew Pinski ---
Yes this is bad coding:
static void
riscv_print_operand (FILE *file, rtx op, int letter)
{
/* `~` does not take an operand so op will be null
Check for before accessing op.
*/
if (letter == '~')
{
if (TARGET_64BIT)
fputc('w', file);
return;
}
machine_mode mode = GET_MODE (op);
enum rtx_code code = GET_CODE (op);
const enum memmodel model = memmodel_base (INTVAL (op));
model should only be defined where it is used rather than in the top.
[Bug target/53929] [meta-bug] -masm=intel with global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 Andrew Pinski changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #12 from Andrew Pinski --- *** Bug 109726 has been marked as a duplicate of this bug. ***
[Bug target/109726] use of variables whose name happen to match register names or keywords with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109726 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 53929. *** This bug has been marked as a duplicate of bug 53929 ***
[Bug target/109726] New: use of variables whose name happen to match register names or keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109726
Bug ID: 109726
Summary: use of variables whose name happen to match register
names or keywords
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
GAS PR: https://sourceware.org/bugzilla/show_bug.cgi?id=30418
Filed in both places, as we need changes both.
This is how MSVC handles such names:
(https://gcc.godbolt.org/z/TonjYaxqj)
```
static int* volatile rip;
static unsigned int volatile eax;
int
get_value(void)
{
return rip[eax];
}
```
MSVC outputs:
```
get_value PROC ; COMDAT
mov ecx, DWORD PTR eax
mov rax, QWORD PTR rip
mov eax, DWORD PTR [rax+rcx*4]
ret 0
get_value ENDP
```
GCC outputs:
```
get_value:
mov rdx, QWORD PTR rip[rip]
mov eax, DWORD PTR eax[rip]
mov eax, DWORD PTR [rdx+rax*4]
ret
```
In the case of MSVC, `DWORD PTR eax` is unambiguously parsed as the label `eax`
and `DWORD PTR [eax]` is unambiguously parsed as the register `eax`. The
address of all labels are always relative to RIP, but it is implied, and
brackets are not written explicitly.
Maybe GCC can follow MSVC to omit the RIP register and brackets. The x86_64
memory reference syntax matches x86 with the only change in semantics of the
immediate offset (for x86_64 it is relative to the next instruction, while for
i686 it is absolute), but the opcode is the same.
[Bug target/109725] New: [14 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in riscv_print_operand, at config/riscv/riscv.cc:4430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109725
Bug ID: 109725
Summary: [14 Regression] ICE: RTL check: expected code
'const_int', have 'reg' in riscv_print_operand, at
config/riscv/riscv.cc:4430
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: build, 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
RTL checking might need to be enabled.
This currently breaks build with RTL checking enabled.
Compiler output:
$ echo 'void foo(void) {}' | /repo/build-gcc-trunk-riscv64/./gcc/cc1 -quiet -
during RTL pass: final
: In function 'foo':
:1:17: internal compiler error: RTL check: expected code 'const_int',
have 'reg' in riscv_print_operand, at config/riscv/riscv.cc:4430
0x8296e1 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/repo/gcc-trunk/gcc/rtl.cc:916
0x8cf1d3 riscv_print_operand
/repo/gcc-trunk/gcc/config/riscv/riscv.cc:4430
0xdb4aa8 output_operand(rtx_def*, int)
/repo/gcc-trunk/gcc/final.cc:3632
0xdb5508 output_asm_insn(char const*, rtx_def**)
/repo/gcc-trunk/gcc/final.cc:3544
0xdb98f2 output_asm_insn(char const*, rtx_def**)
/repo/gcc-trunk/gcc/final.cc:3421
0xdb98f2 final_scan_insn_1
/repo/gcc-trunk/gcc/final.cc:2841
0xdb9c8b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/repo/gcc-trunk/gcc/final.cc:2887
0xdb9ec4 final_1
/repo/gcc-trunk/gcc/final.cc:1979
0xdbab08 rest_of_handle_final
/repo/gcc-trunk/gcc/final.cc:4240
0xdbab08 execute
/repo/gcc-trunk/gcc/final.cc:4318
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/109722] ABSU == 0 is not optimized to just a == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109722
--- Comment #2 from Andrew Pinski ---
This is the corrected version which surives a bootstrap:
/* Convert ABS[U]_EXPR == 0 or ABS[U]_EXPR != 0 to x == 0 or x != 0. */
(for op (abs absu)
(for eqne (eq ne)
(simplify
(eqne (op @0) zerop@1)
(eqne @0 { build_zero_cst (TREE_TYPE (@0)); }
I forgot the type of ABSU is always unsigned while its operand can be
different.
[Bug target/109535] [13 regression] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #16 from Kito Cheng --- Fixed both on trunk and GCC 13 branch :)
[Bug target/109535] [13 regression] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535 --- Comment #15 from CVS Commits --- The releases/gcc-13 branch has been updated by Kito Cheng : https://gcc.gnu.org/g:5821f378b58443e21c77c0f8c673067fc7655fcb commit r13-7285-g5821f378b58443e21c77c0f8c673067fc7655fcb Author: Ju-Zhe Zhong Date: Wed Apr 19 18:41:51 2023 +0800 RISC-V: Fix wrong check of register occurrences [PR109535] count_occurrences will conly count same RTX (same code and same mode), but what we want to track is the occurrence of a register, a register might appeared in the insn with different mode or contain in SUBREG. Testcase coming from Kito. gcc/ChangeLog: PR target/109535 * config/riscv/riscv-vsetvl.cc (count_regno_occurrences): New function. (pass_vsetvl::cleanup_insns): Fix bug. gcc/testsuite/ChangeLog: PR target/109535 * g++.target/riscv/rvv/base/pr109535.C: New test. * gcc.target/riscv/rvv/base/pr109535.c: New test. Signed-off-by: Ju-Zhe Zhong Co-authored-by: kito-cheng (cherry picked from commit a2d12abedc89a9439fd6aadc38730fdadca0684f)
[Bug c++/109724] [10 regression] Huge memory usage when building qtwebengine's SkOpAngle.cpp since r10-11201-g051f78a5c1d699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109724 --- Comment #3 from Sam James --- Created attachment 54989 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54989=edit reduced.ii This reduced version seems to exhibit the same behaviour but please verify.
[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754
S. Davis Herring changed:
What|Removed |Added
CC||herring at lanl dot gov
--- Comment #8 from S. Davis Herring ---
This also strikes in cases like
struct [[deprecated]] S {};
struct T {[[deprecated]] S *backwards() const;};
[[deprecated]] inline bool f(T t) {return t.backwards();}
where the whole interface is deprecated. Even given the assumption that T's
author controls f, T can't provide a non-deprecated alternative to T::backwards
because its declaration would already provoke a warning.
Clang and ICC don't warn here, although MSVC issues two.
[Bug libfortran/109662] bad namelist input but gfortran accepted it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662 --- Comment #5 from Jerry DeLisle --- Is this acceptable: $ ./a.out Compiler version = GCC version 14.0.0 20230424 (experimental) Compiler options = -mtune=generic -march=x86-64 -Wpedantic -fpre-include=/usr/include/finclude/math-vector-fortran.h At line 9 of file pr109662.f90 Fortran runtime error: Comma after namelist name not allowed Should I allow it with -std=legacy?
[Bug bootstrap/109709] List of prerequisites should include that tar is required (not only for unpacking the source).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109709 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #6 from Sam James --- (In reply to Jonathan Wakely from comment #5) > I suppose we could do something like: > lgtm, even if I think it's a little bit silly
[Bug c++/109724] [10 regression] Huge memory usage when building qtwebengine's SkOpAngle.cpp since r10-11201-g051f78a5c1d699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109724 --- Comment #2 from Sam James --- I'm going to try reduce this with a timeout of ~3s or so and pray, but please tell me if you have a better idea to help speed it up.
[Bug c++/109724] [10 regression] Huge memory usage when building qtwebengine's SkOpAngle.cpp since r10-11201-g051f78a5c1d699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109724 Sam James changed: What|Removed |Added Keywords||compile-time-hog, ||memory-hog --- Comment #1 from Sam James --- Reverting it on the branch makes compile succeed within about a second.
[Bug c++/109724] New: [10 regression] Huge memory usage when building qtwebengine's SkOpAngle.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109724 Bug ID: 109724 Summary: [10 regression] Huge memory usage when building qtwebengine's SkOpAngle.cpp Product: gcc Version: 10.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Created attachment 54988 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54988=edit SkOpAngle.ii.xz Originally reported downstream in Gentoo at https://bugs.gentoo.org/905634. Matthew Ogilvie reports that 10.4.1 20230119 (18bc39a4c83f8d59175061a58637de9f4b2a54d4) is OK, but 10.4.1 20230426 (db0b8927d663cf54ad13dc2629ec195e3883d0d0) is not. releases/gcc-10 is bad too. --- ``` $ g++ -O2 /tmp/SkOpAngle.ii -c [consumes a huge amount of memory quite quickly and takes a long time to compile, OOMs before I can complete compilation (it may not even terminate?)] ``` Bisect says 051f78a5c1d6994c10ee7c35453ff0ccee94e5c6 is the first bad commit commit 051f78a5c1d6994c10ee7c35453ff0ccee94e5c6 Author: Richard Biener Date: Fri Sep 2 13:36:13 2022 +0200 tree-optimization/106809 - compile time hog in VN i.e. r10-11201-g051f78a5c1d699.
[Bug c++/109723] [14 regression] ICE in instantiate_decl, at cp/pt.cc:27066 when building opencv-4.7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109723 Sam James changed: What|Removed |Added Keywords||needs-bisection, ||needs-reduction --- Comment #1 from Sam James --- I'm bisecting something else so would appreciate it if someone else could try. I'm trying a reduction as well but this machine tends to take a while on them.
[Bug c++/109723] New: [14 regression] ICE in instantiate_decl, at cp/pt.cc:27066 when building opencv-4.7.0
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:18827 0x9af79f tsubst_expr(tree_node*, tree_node*, int, tree_node*) /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:19207 0x9be0c7 tsubst_expr(tree_node*, tree_node*, int, tree_node*) /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:18813 0x9be0c7 instantiate_body /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:26889 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. ``` --- ``` $ g++ -O2 bimef.cpp.ii -c [...] 0x9d5eb7 instantiate_decl(tree_node*, bool, bool) /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/pt.cc:27066 0x8356df mark_used(tree_node*, int) /usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/cp/decl2.cc:5875 [...] ``` $ gcc --version gcc (Gentoo 14.0.0. p, commit 490c1c096ca1d3a1f4a84801a46231d64c07ba49) 14.0.0 20230503 (experimental) 6cff5f3da7f263bb11cf48e6011931422b62b364 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ```
[Bug modula2/109675] GCC 13.1: the Modula-2 front-end fails to build on some platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109675 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Gaius Mulley --- Many thanks for the bug report - closing now that the patch has been applied.
[Bug tree-optimization/109722] ABSU == 0 is not optimized to just a == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109722 --- Comment #1 from Andrew Pinski --- Note I accidently found this while creating a patch for PR 101541 and I had messed up creating ABSU when I didn't need to and it was causing the testsuite patterns in tree-ssa/vrp20.c not to match (though it was optimized correctly still).
[Bug tree-optimization/109722] ABSU == 0 is not optimized to just a == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109722 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-05-04 Ever confirmed|0 |1
[Bug tree-optimization/109722] New: ABSU == 0 is not optimized to just a == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109722
Bug ID: 109722
Summary: ABSU == 0 is not optimized to just a == 0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f(signed char a)
{
int t = a;
if (t < 0) t = -t;
a = t;
return a == 0;
}
```
Right now this gets optimized to just:
```
_9 = ABSU_EXPR ;
_1 = _9 == 0;
_7 = (int) _1;
```
If we change `signed char` to `unsigned char`, we get:
_1 = a_2(D) == 0;
_3 = (int) _1;
As we had expected for the original case too.
The fix is to change in match.pd:
/* Convert ABS_EXPR == 0 or ABS_EXPR != 0 to x == 0 or x != 0. */
(for op (eq ne)
(simplify
(op (abs @0) zerop@1)
(op @0 @1)))
to:
/* Convert ABS[U]_EXPR == 0 or ABS[U]_EXPR != 0 to x == 0 or x != 0. */
(for op (abs absu)
(for eqne (eq ne)
(simplify
(eqne (op @0) zerop@1)
(eqne @0 @1)))
[Bug modula2/109675] GCC 13.1: the Modula-2 front-end fails to build on some platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109675 --- Comment #3 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:9525daf0fbc5c836ee028f5b58612857de7da51d commit r14-465-g9525daf0fbc5c836ee028f5b58612857de7da51d Author: Gaius Mulley Date: Thu May 4 01:37:05 2023 +0100 PR modula2/109675 implementation of writeAddress is non portable The implementation of gcc/m2/gm2-libs/DynamicStrings.mod:writeAddress is non portable as it casts a void * into an unsigned long int. This procedure has been re-implemented to use snprintf. As it is a library the support tools 'mc' and 'pge' have been rebuilt. There have been linking changes in the library and the underlying boolean type is now bool since the last rebuild hence the size of the patch. gcc/m2/ChangeLog: PR modula2/109675 * Make-lang.in (MC-LIB-DEFS): Remove M2LINK.def. (BUILD-PGE-O): Remove GM2LINK.o. * Make-maintainer.in (PPG-DEFS): New define. (PPG-LIB-DEFS): Remove M2LINK.def. (BUILD-BOOT-PPG-H): Add PPGDEF .h files. (m2/ppg$(exeext)): Remove M2LINK.o (PGE-DEPS): New define. (m2/pg$(exeext)): Remove M2LINK.o. (m2/gm2-pge-boot/$(SRC_PREFIX)%.o): Add -Im2/gm2-pge-boot. (m2/pge$(exeext)): Remove M2LINK.o. (pge-maintainer): Re-implement. (pge-libs-push): Re-implement. (m2/m2obj3/cc1gm2$(exeext)): Remove M2LINK.o. * gm2-libs/DynamicStrings.mod (writeAddress): Re-implement using snprintf. * gm2-libs/M2Dependent.mod: Remove commented out imports. * mc-boot/GDynamicStrings.cc: Rebuild. * mc-boot/GFIO.cc: Rebuild. * mc-boot/GFormatStrings.cc: Rebuild. * mc-boot/GM2Dependent.cc: Rebuild. * mc-boot/GM2Dependent.h: Rebuild. * mc-boot/GM2RTS.cc: Rebuild. * mc-boot/GM2RTS.h: Rebuild. * mc-boot/GRTExceptions.cc: Rebuild. * mc-boot/GRTint.cc: Rebuild. * mc-boot/GSFIO.cc: Rebuild. * mc-boot/GStringConvert.cc: Rebuild. * mc-boot/Gdecl.cc: Rebuild. * pge-boot/GASCII.cc: Rebuild. * pge-boot/GASCII.h: Rebuild. * pge-boot/GArgs.cc: Rebuild. * pge-boot/GArgs.h: Rebuild. * pge-boot/GAssertion.cc: Rebuild. * pge-boot/GAssertion.h: Rebuild. * pge-boot/GBreak.h: Rebuild. * pge-boot/GCmdArgs.h: Rebuild. * pge-boot/GDebug.cc: Rebuild. * pge-boot/GDebug.h: Rebuild. * pge-boot/GDynamicStrings.cc: Rebuild. * pge-boot/GDynamicStrings.h: Rebuild. * pge-boot/GEnvironment.h: Rebuild. * pge-boot/GFIO.cc: Rebuild. * pge-boot/GFIO.h: Rebuild. * pge-boot/GFormatStrings.h:: Rebuild. * pge-boot/GFpuIO.h:: Rebuild. * pge-boot/GIO.cc: Rebuild. * pge-boot/GIO.h: Rebuild. * pge-boot/GIndexing.cc: Rebuild. * pge-boot/GIndexing.h: Rebuild. * pge-boot/GLists.cc: Rebuild. * pge-boot/GLists.h: Rebuild. * pge-boot/GM2Dependent.cc: Rebuild. * pge-boot/GM2Dependent.h: Rebuild. * pge-boot/GM2EXCEPTION.cc: Rebuild. * pge-boot/GM2EXCEPTION.h: Rebuild. * pge-boot/GM2RTS.cc: Rebuild. * pge-boot/GM2RTS.h: Rebuild. * pge-boot/GNameKey.cc: Rebuild. * pge-boot/GNameKey.h: Rebuild. * pge-boot/GNumberIO.cc: Rebuild. * pge-boot/GNumberIO.h: Rebuild. * pge-boot/GOutput.cc: Rebuild. * pge-boot/GOutput.h: Rebuild. * pge-boot/GPushBackInput.cc: Rebuild. * pge-boot/GPushBackInput.h: Rebuild. * pge-boot/GRTExceptions.cc: Rebuild. * pge-boot/GRTExceptions.h: Rebuild. * pge-boot/GSArgs.h: Rebuild. * pge-boot/GSEnvironment.h: Rebuild. * pge-boot/GSFIO.cc: Rebuild. * pge-boot/GSFIO.h: Rebuild. * pge-boot/GSYSTEM.h: Rebuild. * pge-boot/GScan.h: Rebuild. * pge-boot/GStdIO.cc: Rebuild. * pge-boot/GStdIO.h: Rebuild. * pge-boot/GStorage.cc: Rebuild. * pge-boot/GStorage.h: Rebuild. * pge-boot/GStrCase.cc: Rebuild. * pge-boot/GStrCase.h: Rebuild. * pge-boot/GStrIO.cc: Rebuild. * pge-boot/GStrIO.h: Rebuild. * pge-boot/GStrLib.cc: Rebuild. * pge-boot/GStrLib.h: Rebuild. * pge-boot/GStringConvert.h: Rebuild. * pge-boot/GSymbolKey.cc: Rebuild. * pge-boot/GSymbolKey.h: Rebuild. * pge-boot/GSysExceptions.h: Rebuild. * pge-boot/GSysStorage.cc: Rebuild. * pge-boot/GSysStorage.h: Rebuild.
[Bug tree-optimization/101541] Missing ABSU detection at gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101541
--- Comment #4 from Andrew Pinski ---
Another one missed:
```
unsigned abssat2 (unsigned x)
{
int y = x;
if (y < 0)
x = -x;
return x;
}
```
I have a patch for the this case, I think. Working on the other case now.
[Bug target/109544] implicit declaration of function '__riscv_vsseg4e8_v_i8mf8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109544 --- Comment #4 from JuzheZhong --- (In reply to Mathieu Malaterre from comment #2) > ok then. Closing as resolved/invalid then ! Hi, the GCC master has supported the latest segment intrinsics. Would you mind using the latest segment intrinsics ? Thanks.
[Bug tree-optimization/109721] [14 Regression] predcom-2 started to fail on arc-elf after r14-391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109721 --- Comment #1 from Andrew Pinski --- The testcase might need now -fno-tree-vectorizer .
[Bug tree-optimization/109721] [14 Regression] predcom-2 started to fail on arc-elf after r14-391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109721 Andrew Pinski changed: What|Removed |Added Summary|[14 Regression] predcom-2 |[14 Regression] predcom-2 |fails after recent changes |started to fail on arc-elf ||after r14-391 Keywords||testsuite-fail Target Milestone|--- |14.0
[Bug tree-optimization/109721] New: [14 Regression] predcom-2 fails after recent changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109721 Bug ID: 109721 Summary: [14 Regression] predcom-2 fails after recent changes Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- arc-elf target. FAIL: gcc.dg/tree-ssa/predcom-2.c scan-tree-dump-times pcom "Unrolling 2 times." 2 Bisection points to: f385252b2336a4a57a30fddf82e558c73bcc85cc is the first bad commit commit f385252b2336a4a57a30fddf82e558c73bcc85cc Author: Richard Biener Date: Tue May 2 10:34:48 2023 +0200 tree-optimization/109672 - properly check emulated plus during vect The following refactors the check for emulated vector support for the cases of plus, minus and negate. In the PR we end up with a SImode plus, supported by the target but emulated and in this context fail to verify we are dealing with exactly word_mode. PR tree-optimization/109672 * tree-vect-stmts.cc (vectorizable_operation): For plus, minus and negate always check the vector mode is word mode. It should be visible with a cross-compiler. No need for a full toolchain stack.
[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720 --- Comment #4 from Andrew Pinski --- Some internal GCC Notes: PRE introduces the read from uninitialized memory though it is not used in some pathes. The IR/CFG is very has some interesting twists and turns to it which looks like it confuses both PRE and the uninitialized warning code.
[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720 --- Comment #3 from Paul Smith --- Created attachment 54986 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54986=edit bitset.i.gz compressed preprocessor output Hm, I did attach it when I filed the bug; I guess I forgot to click some final "OK" button because it's not there now! Sorry about that attaching now.
[Bug libstdc++/105844] [10/11 Regression] std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844 --- Comment #15 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b357af31b8d1e93f0f70133e25d3ad4045f7a32b commit r10-11389-gb357af31b8d1e93f0f70133e25d3ad4045f7a32b Author: Jonathan Wakely Date: Wed May 3 21:40:01 2023 +0100 libstdc++: Ensure constexpr std::lcm detects out-of-range result [PR105844] On the gcc-10 branch, __glibcxx_assert does not unconditionally check the condition during constant evaluation. This means we need an explicit additional check for std::lcm results that cannot be represented in an unsigned result type. libstdc++-v3/ChangeLog: PR libstdc++/105844 * include/std/numeric (lcm): Ensure out-of-range result is detected in constant evaluation. * testsuite/26_numerics/lcm/105844.cc: Adjust dg-error string.
[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720 --- Comment #2 from Andrew Pinski --- (In reply to Paul Smith from comment #1) > Hm, maybe it's due to the union. Maybe GCC can't grok that we ensure that > we only use the dynamic_bitset leg of the union after we've initialized it? Once we get the preprocessed source, it should be easy to figure out why the warning is showing up and if it is related to unions or something else.
[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720 --- Comment #1 from Paul Smith --- Hm, maybe it's due to the union. Maybe GCC can't grok that we ensure that we only use the dynamic_bitset leg of the union after we've initialized it? I wonder if this warning could just assume that if the code uses one leg of the union, that the other legs should be avoided. Or something like that. Else I don't see how this warning can ever be used in code which uses unions.
[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 --- Comment #5 from Christoph Reiter --- Taking `libgcc_s_dw2-1.dll` from gcc 12.2 fixes the issue. We also found that gdb and cmake are broken due to broken exception handling (in case of cmake it is flaky). In both those cases taking the old `libgcc_s_dw2-1.dll` also helps. So this is not ada specific, but exception handling being broken for 32bit Windows.
[Bug bootstrap/109709] List of prerequisites should include that tar is required (not only for unpacking the source).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109709
--- Comment #5 from Jonathan Wakely ---
I suppose we could do something like:
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -364,7 +364,9 @@ You must have GNU make installed to build GCC@.
Necessary (only on some platforms) to untar the source code. Many
systems' @command{tar} programs will also work, only try GNU
-@command{tar} if you have problems.
+@command{tar} if you have problems. N.B. a @command{tar} program of some
+kind is always needed to build GCC, the GNU tar requirement is only
+for extracting the sources.
@item Perl version between 5.6.1 and 5.6.24
[Bug bootstrap/109709] List of prerequisites should include that tar is required (not only for unpacking the source).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109709
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Jonathan Wakely ---
gcc/Makefile.in has:
# Install the include directory using tar.
install-headers-tar: stmp-int-hdrs install-include-dir
# We use `pwd`/include instead of just include to problems with CDPATH
# Unless a full pathname is provided, some shells would print the new CWD,
# found in CDPATH, corrupting the output. We could just redirect the
# output of `cd', but some shells lose on redirection within `()'s
(cd `${PWD_COMMAND}`/include ; \
tar -cf - .; exit 0) | (cd $(DESTDIR)$(libsubdir)/include; tar xpf - )
(cd `${PWD_COMMAND}`/include-fixed ; \
tar -cf - .; exit 0) | (cd $(DESTDIR)$(libsubdir)/include-fixed; tar
xpf - )
# /bin/sh on some systems returns the status of the first tar,
# and that can lose with GNU tar which always writes a full block.
# So use `exit 0' to ignore its exit status.
This doesn't require GNU tar though, just any tar, so I think I agree that it's
just like cp and file and sed which are part of any unix-like environment.
The prerequisites page is specifically saying that GNU tar is needed on some
systems, for the reason Andrew stated above.
[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719 Christian Hergert changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #9 from Christian Hergert --- Sure, no worries.
[Bug bootstrap/109709] List of prerequisites should include that tar is required (not only for unpacking the source).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109709
--- Comment #3 from Manuel Jacob ---
(In reply to Richard Biener from comment #1)
> Huh, can you post how it fails?
if [ -d ../prev-gcc ]; then \
cd ../prev-gcc && \
make real-install-headers-tar DESTDIR=`pwd`/../gcc/ \
libsubdir=. ; \
else \
set -e; for ml in `cat fixinc_list`; do \
sysroot_headers_suffix=`echo ${ml} | sed -e 's/;.*$//'`; \
multi_dir=`echo ${ml} | sed -e 's/^[^;]*;//'`; \
fix_dir=include-fixed${multi_dir}; \
if ! false && test ! -d `echo /usr/include | sed -e :a -e
's,[^/]*/\.\.\/,,' -e ta`; then \
echo The directory that should contain system headers does not exist: >&2
; \
echo " `echo /usr/include | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`" >&2
; \
tooldir_sysinc=`echo
"/usr/lib/gcc/x86_64-pc-linux-gnu/13.1.0/../../../../x86_64-pc-linux-gnu/sys-include"
| sed -e :a -e "s,[^/]*/\.\.\/,," -e ta`; \
if test "x`echo /usr/include | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`" =
"x${tooldir_sysinc}"; \
then sleep 1; else exit 1; fi; \
fi; \
/bin/sh /build/source/gcc-13.1.0/gcc/../mkinstalldirs ${fix_dir}; \
chmod a+rx ${fix_dir} || true; \
(TARGET_MACHINE='x86_64-pc-linux-gnu'; srcdir=`cd
/build/source/gcc-13.1.0/gcc; ${PWDCMD-pwd}`; \
SHELL='/bin/sh'; MACRO_LIST=`${PWDCMD-pwd}`/macro_list ; \
gcc_dir=`${PWDCMD-pwd}` ; \
export TARGET_MACHINE srcdir SHELL MACRO_LIST && \
cd ../build-x86_64-pc-linux-gnu/fixincludes && \
/bin/sh ./fixinc.sh "${gcc_dir}/${fix_dir}" \
`echo /usr/include | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` ); \
done; \
fi
make[4]: Entering directory '/build/build/prev-gcc'
(cd `${PWDCMD-pwd}`/include-fixed ; \
tar -cf - .; exit 0) | (cd /build/build/prev-gcc/../gcc/./include-fixed; tar
xpf - )
/bin/sh: line 2: tar: command not found
/bin/sh: line 2: tar: command not found
make[4]: *** [Makefile:4028: real-install-headers-tar] Error 127
make[4]: Leaving directory '/build/build/prev-gcc'
make[3]: *** [Makefile:3309: stmp-fixinc] Error 2
make[3]: Leaving directory '/build/build/gcc'
make[2]: *** [Makefile:5013: all-stage2-gcc] Error 2
make[2]: Leaving directory '/build/build'
make[1]: *** [Makefile:27012: stage2-bubble] Error 2
make[1]: Leaving directory '/build/build'
make: *** [Makefile:1080: all] Error 2
[Bug c++/109720] New: -Wmaybe-uninitialized triggering when I can see no path that would allow it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
Bug ID: 109720
Summary: -Wmaybe-uninitialized triggering when I can see no
path that would allow it
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: psmith at gnu dot org
Target Milestone: ---
I recently upgraded to GCC 13.1 and when building some code that uses
boost::dynamic_bitset I'm seeing the -Wmaybe-ininitialized warning triggering
when it's impossible for any object of the class to be created without the
m_num_bits field being initialized.
I've tried to reduce this without luck. Also if I do other, seemingly
irrelevant things then the warning goes away. I wonder if it's somehow related
to the placement new that we use for the union...?
I'll attach the postprocessed output.
Code:
DynamicBitSet set(200);
size_t setup(size_t ln)
{
size_t count = 0;
DynamicBitSet nbits(set);
for (auto bit: nbits) {
count += bit;
}
return count;
}
I checked and this also failed in GCC 11.3; maybe -Wall didn't used to include
this warning and now it does which is why I didn't notice it before?
Results:
$ /data/src/build/x86_64-linux/bin/x86_64-rl84-linux-gnu-g++
-I/data/src/build/common/boost/include -std=gnu++20 -Wmaybe-uninitialized -O2
-c -o /tmp/bitset.o /tmp/bitset.i
In member function 'boost::dynamic_bitset::size_type
boost::dynamic_bitset::size() const [with Block = long
unsigned int; Allocator = std::allocator]',
inlined from 'boost::dynamic_bitset::size_type
boost::dynamic_bitset::find_next(size_type) const [with Block
= long unsigned int; Allocator = std::allocator]' at
/tmp/bitset.i:70473:30,
inlined from 'DynamicBitSet::size_type DynamicBitSet::find_next(size_type)
const' at /tmp/bitset.i:77301:44,
inlined from 'DynamicBitSet::Iterator&
DynamicBitSet::Iterator::operator++()' at /tmp/bitset.i:77325:38,
inlined from 'size_t setup(size_t)' at /tmp/bitset.i:77340:20:
/tmp/bitset.i:70355:12: warning: '*(const boost::dynamic_bitset >*)((char*) +
offsetof(DynamicBitSet,
DynamicBitSet::)).boost::dynamic_bitset<>::m_num_bits' may be used
uninitialized [-Wmaybe-uninitialized]
70355 | return m_num_bits;
|^~
/tmp/bitset.i: In function 'size_t setup(size_t)':
/tmp/bitset.i:77339:19: note: 'nbits' declared here
77339 | DynamicBitSet nbits(set);
| ^
[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719 --- Comment #8 from Andrew Pinski --- (In reply to Christian Hergert from comment #6) > (In reply to Andrew Pinski from comment #2) > > HUH? omit frame pointer is on by default on x86_64. > > Yes, Fedora 38 changed the default compiler flags to > `-fno-omit-frame-pointer` so that the system can be profiled more reliably. So you should report this to Fedora's team. > > > What target is this on? > > x86_64 > > > What exact command line is being used to compile the sources? If this on > > x86_64, you might still need -mno-omit-leaf-frame-pointer too. > > No doubt, I have `-mno-omit-leaf-frame-pointer` too. I am suspecting the issue is inside the linux kernel ... Anyways we need much more information here. A sample simple program which shows that GCC is doing the wrong thing. Maybe it is the linux frame pointer walker going wrong.
[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719 --- Comment #7 from Christian Hergert --- (In reply to Andrew Pinski from comment #3) > Also on x86_64, frame pointers are not required by the ABI so this is not an > ABI issue. Why instead are you not using the dwarf2 unwind tables that are > generated by default too? Because the stack unwinding comes from the Linux kernel, which the default unwinder can only support frame-pointers. The DWARF unwinder was removed long ago. Additionally, it can't use `.eh_frame_hdr` either.
[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719 --- Comment #6 from Christian Hergert --- (In reply to Andrew Pinski from comment #2) > HUH? omit frame pointer is on by default on x86_64. Yes, Fedora 38 changed the default compiler flags to `-fno-omit-frame-pointer` so that the system can be profiled more reliably. > What target is this on? x86_64 > What exact command line is being used to compile the sources? If this on > x86_64, you might still need -mno-omit-leaf-frame-pointer too. No doubt, I have `-mno-omit-leaf-frame-pointer` too.
[Bug tree-optimization/109717] -Warray-bound error with gnu++20 and fmt library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717 --- Comment #4 from Jonathan Wakely --- Some of the warnings were always present, but suppressed unless you used -Wsystem-headers Now they're issued even when the "problem" is in a system header. This is considered progress ;-)
[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719 --- Comment #5 from Christian Hergert --- Created attachment 54985 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54985=edit First level of stack traces with g++ This shows stack traces when the only change was compiling harfbuzz with g++ instead of clang++. Much of the unwinding done by the kernel becomes corrupted and shallow as you can see by lots of functions which have no business being called before `_start` or `__GI__clone3` are getting called.
[Bug other/105819] comma `,` in directory name causes build to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105819 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #16 from Jonathan Wakely --- (In reply to bug-reports.delphin from comment #14) > Ok but where ? I didn't find it. What file shows me this coma, and what > line/lines, where ? config.log ? my-configure.log ? my-make.log ? I already told you in comment 6: Originally you were trying to use a directory called "_Source/_12,1,x" with two commas. Then you changed it to "_12,2.x" but that still has a comma. Now you're trying to use "_13,1.x" which still has a comma.
[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719 --- Comment #4 from Christian Hergert --- Created attachment 54984 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54984=edit First level of stack traces with clang++ This shows a more proper first-level of stack frames within the program as harfbuzz API will show up in descendants properly.
[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719 --- Comment #3 from Andrew Pinski --- Also on x86_64, frame pointers are not required by the ABI so this is not an ABI issue. Why instead are you not using the dwarf2 unwind tables that are generated by default too?
[Bug target/109719] Truncated frame-pointer unwinding via Linux perf with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-03 Status|UNCONFIRMED |WAITING Component|c++ |target Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- >On Fedora 38, frame-pointers are enabled by default. Caveats of course. HUH? omit frame pointer is on by default on x86_64. What target is this on? What exact command line is being used to compile the sources? If this on x86_64, you might still need -mno-omit-leaf-frame-pointer too.
[Bug bootstrap/109710] Build fails with `,` in the directory name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109710 --- Comment #5 from Jonathan Wakely --- It should not be hard to understand. You are using this path: /Volumes/External_7/_Ze-Bins/_GNU-Compilers/_13,1.x/ There is a comma in _13,1.x Just like you were using _12,1,x earlier. Stop doing that. Change it to _13.1.x and _12.1.x and please stop reporting bugs about this.
[Bug c++/109719] Truncated frame-pointer unwinding via Linux perf with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719 --- Comment #1 from Christian Hergert --- > When I recompile the project with clang++ instead I realize this was a bit vague, by "project" I mean Harfbuzz. Simply compiling Harfbuzz with clang++ made frame-pointer unwinding work by Linux perf.
[Bug tree-optimization/109717] -Warray-bound error with gnu++20 and fmt library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717 --- Comment #3 from Paul Smith --- OK, well, we don't have to say "broken"; all I know is that perfectly respectable code that used to work without triggering these warnings in older versions of GCC, and with older -std=c++..., is now failing in GCC 13.1 / -std=c++20 widely enough that I must disable these warnings, which is unfortunate.
[Bug other/105819] GCC 12.1.0 Make failed - Compiled with GCC 4.9.4 and under Mac OS X lion - I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105819 --- Comment #15 from Jonathan Wakely --- *** Bug 109710 has been marked as a duplicate of this bug. ***
[Bug bootstrap/109710] Build fails with `,` in the directory name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109710 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jonathan Wakely --- We've explained several times that you can't use commas in the path: e.g. PR 106956 which was closed as a duplicate of PR 105819 Please stop it. *** This bug has been marked as a duplicate of bug 105819 ***
[Bug c++/109719] New: Truncated frame-pointer unwinding via Linux perf with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109719 Bug ID: 109719 Summary: Truncated frame-pointer unwinding via Linux perf with g++ Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: chergert at redhat dot com Target Milestone: --- On Fedora 38, frame-pointers are enabled by default. Caveats of course. However, I noticed that clang++ is generating code that can unwind with frame-pointers just fine where as g++ is generating code that fails to unwind past a single frame for some projects. Where I've noticed this is when profiling GTK/GNOME applications. Harfbuzz, which is C++ (no-rtti, no-exceptions, no-threadsafe-statics, and no stdlibc++), regularly results in stacktraces from Linux perf containing 2 frames. One of them looks corrupted, and the second to a Harfbuzz function. When I recompile the project with clang++ instead (leaving the rest of the system still compiled with gcc) I get proper stacktraces from Linux perf showing how the Harfbuzz API was called (via GLib/GTK/Pango/etc). Happy to provide more information and/or be remote hands/eyes. Thanks!
[Bug c++/109649] [13/14 Regression] GCC accepts invalid inaccessible friend declaration of member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109649 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed for 13.2/14.
[Bug c++/91618] [9/10/11 Regression] template-id required to friend a function template, even for a qualified-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91618 --- Comment #15 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7ce078ceca42f184f6f60c3ca921b6e07cf2c4bd commit r14-460-g7ce078ceca42f184f6f60c3ca921b6e07cf2c4bd Author: Jason Merrill Date: Wed May 3 13:32:55 2023 -0400 c++: over-eager friend matching [PR109649] A bug in the simplification I did around 91618; at this point X::f has DECL_IMPLICIT_INSTANTIATION set, but we've already identified what template it corresponds to, so we don't want to call check_explicit_specialization. To distinguish this case we need to look at DECL_TI_TEMPLATE. grokfndecl has for a long time set it to the OVERLOAD in this case, while the new cases I added for 91618 were leaving DECL_TEMPLATE_INFO null; let's adjust them to match. PR c++/91618 PR c++/109649 gcc/cp/ChangeLog: * friend.cc (do_friend): Don't call check_explicit_specialization if DECL_TEMPLATE_INFO is already set. * decl2.cc (check_classfn): Set DECL_TEMPLATE_INFO. * name-lookup.cc (set_decl_namespace): Likewise. gcc/testsuite/ChangeLog: * g++.dg/template/friend77.C: New test.
[Bug c++/109649] [13/14 Regression] GCC accepts invalid inaccessible friend declaration of member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109649 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7ce078ceca42f184f6f60c3ca921b6e07cf2c4bd commit r14-460-g7ce078ceca42f184f6f60c3ca921b6e07cf2c4bd Author: Jason Merrill Date: Wed May 3 13:32:55 2023 -0400 c++: over-eager friend matching [PR109649] A bug in the simplification I did around 91618; at this point X::f has DECL_IMPLICIT_INSTANTIATION set, but we've already identified what template it corresponds to, so we don't want to call check_explicit_specialization. To distinguish this case we need to look at DECL_TI_TEMPLATE. grokfndecl has for a long time set it to the OVERLOAD in this case, while the new cases I added for 91618 were leaving DECL_TEMPLATE_INFO null; let's adjust them to match. PR c++/91618 PR c++/109649 gcc/cp/ChangeLog: * friend.cc (do_friend): Don't call check_explicit_specialization if DECL_TEMPLATE_INFO is already set. * decl2.cc (check_classfn): Set DECL_TEMPLATE_INFO. * name-lookup.cc (set_decl_namespace): Likewise. gcc/testsuite/ChangeLog: * g++.dg/template/friend77.C: New test.
[Bug c++/109649] [13/14 Regression] GCC accepts invalid inaccessible friend declaration of member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109649 --- Comment #3 from CVS Commits --- The releases/gcc-13 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6138e862038180c7cfb94d6c120bd0b76da382ae commit r13-7283-g6138e862038180c7cfb94d6c120bd0b76da382ae Author: Jason Merrill Date: Wed May 3 14:16:00 2023 -0400 Revert "c++: reorganize friend template matching [PR91618]" This patch was just a cleanup after the actual bugfix, so let's revert it on the branch. PR c++/109649 This reverts commit e9d2adc17d0dbe46db67e1b618dea888d5c7aca3.
[Bug sanitizer/105614] mips64: sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614 --- Comment #20 from gagan sidhu (broly) --- my apologies, i should open a new ticket if this is indeed an error. but it may be my fault for not specifying the ARCH parameter when installing the linux headers prior to starting the toolchain. if it isn't my fault, i will open a new ticket.
[Bug bootstrap/109710] Build fails with `,` in the directory name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109710 Andrew Pinski changed: What|Removed |Added Summary|OS X Lio : make failed -> |Build fails with `,` in the |ld: can't open |directory name |-reexported_symbols_list| |file| --- Comment #3 from Andrew Pinski --- Yes using a comma ',' in the directory name will not work. Just stay away from a comma.
[Bug libgcc/109712] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
Last reconfirmed||2023-05-03
--- Comment #3 from Andrew Pinski ---
>find . -iname "*.deb" -exec dpkg-deb -x {} cuda \;
This won't work on non-debian based targets. IIRC debs are archives which
contain two tar files which you can just use ar followed by tar to extract the
files instead of using dpkg-deb.
[Bug sanitizer/105614] mips64: sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614 --- Comment #19 from gagan sidhu (broly) --- seems that 13.1.0 still needs some modification, because i was building the toolchain and now get a static assertion error: > /bin/sh ../libtool --tag=CXX --mode=compile > /Volumes/xtoolshit/bgcc/./gcc/xgcc -shared-libgcc > -B/Volumes/xtoolshit/bgcc/./gcc -nostdinc++ > -L/Volumes/xtoolshit/bgcc/mips64el-none-linux-gnu/libstdc++-v3/src > -L/Volumes/xtoolshit/bgcc/mips64el-none-linux-gnu/libstdc++-v3/src/.libs > -L/Volumes/xtoolshit/bgcc/mips64el-none-linux-gnu/libstdc++-v3/libsupc++/.libs > -B/cross/mips64el-none-linux-gnu/bin/ -B/cross/mips64el-none-linux-gnu/lib/ > -isystem /cross/mips64el-none-linux-gnu/include -isystem > /cross/mips64el-none-linux-gnu/sys-include-D_GNU_SOURCE -D_DEBUG > -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS > -DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I. > -I../../../../gcc-13.1.0/libsanitizer/sanitizer_common -I.. -I > ../../../../gcc-13.1.0/libsanitizer/include -I > ../../../../gcc-13.1.0/libsanitizer -isystem > ../../../../gcc-13.1.0/libsanitizer/include/system -Wall -W > -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC > -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables > -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include > -I../../libstdc++-v3/include/mips64el-none-linux-gnu > -I../../../../gcc-13.1.0/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++14 > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DSANITIZER_LIBBACKTRACE > -DSANITIZER_CP_DEMANGLE -I > ../../../../gcc-13.1.0/libsanitizer/../libbacktrace -I ../libbacktrace -I > ../../../../gcc-13.1.0/libsanitizer/../include -include > ../../../../gcc-13.1.0/libsanitizer/libbacktrace/backtrace-rename.h -g -O2 > -D_GNU_SOURCE -minterlink-mips16 -MT sanitizer_stacktrace.lo -MD -MP -MF > .deps/sanitizer_stacktrace.Tpo -c -o sanitizer_stacktrace.lo > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_stacktrace.cpp > In file included from > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_flags.h:16, > from > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_common.h:18, > from > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:174: > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:986:29: > error: static assertion failed > 986 | COMPILER_CHECK(IOC_SIZEBITS == _IOC_SIZEBITS); > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:352:44: > note: in definition of macro 'COMPILER_CHECK' > 352 | #define COMPILER_CHECK(pred) static_assert(pred, "") > |^~~~ > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:986:29: > note: the comparison reduces to '(13 == 14)' > 986 | COMPILER_CHECK(IOC_SIZEBITS == _IOC_SIZEBITS); > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:352:44: > note: in definition of macro 'COMPILER_CHECK' > 352 | #define COMPILER_CHECK(pred) static_assert(pred, "") > |^~~~ > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:987:28: > error: static assertion failed > 987 | COMPILER_CHECK(IOC_DIRBITS == _IOC_DIRBITS); > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:352:44: > note: in definition of macro 'COMPILER_CHECK' > 352 | #define COMPILER_CHECK(pred) static_assert(pred, "") > |^~~~ > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:987:28: > note: the comparison reduces to '(3 == 2)' > 987 | COMPILER_CHECK(IOC_DIRBITS == _IOC_DIRBITS); > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:352:44: > note: in definition of macro 'COMPILER_CHECK' > 352 | #define COMPILER_CHECK(pred) static_assert(pred, "") > |^~~~ > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:990:29: > error: static assertion failed > 990 | COMPILER_CHECK(IOC_SIZEMASK == _IOC_SIZEMASK); > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:352:44: > note: in definition of macro 'COMPILER_CHECK' > 352 | #define COMPILER_CHECK(pred) static_assert(pred, "") > |^~~~ > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:990:29: > note: the comparison reduces to '(8191 == 16383)' > 990 | COMPILER_CHECK(IOC_SIZEMASK == _IOC_SIZEMASK); > ../../../../gcc-13.1.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:352:44: > note: in definition of macro
[Bug libgcc/109712] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 Andrew Pinski changed: What|Removed |Added Component|c++ |libgcc --- Comment #2 from Andrew Pinski --- >* The problem happens only when using the Gold linker. This could also point to a bug with the GOLD linker. I am not sure if the gold linker is even maintained these days or well enough tested.
[Bug tree-optimization/109716] bogus stringop-overread "reading 4 bytes from a region of size 0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109716 Andrew Pinski changed: What|Removed |Added Blocks||97048 Component|c |tree-optimization Last reconfirmed||2023-05-03 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Keywords||diagnostic --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source as requested on https://gcc.gnu.org/bugs/ ? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 [Bug 97048] [meta-bug] bogus/missing -Wstringop-overread warnings
[Bug tree-optimization/109714] bogus "may be used uninitialized warning"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109714 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2023-05-03 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source as requested on https://gcc.gnu.org/bugs/ ?
[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701 Jakub Jelinek changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- This is a user error. The OpenMP standard makes reduction vars mapped on target only on combined constructs with the target construct, which is not the case here. If you'd use !$omp target teams distribute parallel do simd if(target:is_GPU) reduction(max:max_diff) collapse(2) then max_diff would be mapped. But as it is on a different constructs, the standard rules apply there and max_diff is firstprivatized instead (as it is scalar, no defaultmap clause is used etc.). So, if that isn't what you want, you need to map it explicitly map(tofrom:max_diff) or so on the target.
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-05-03 Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109701 Status|UNCONFIRMED |NEW --- Comment #22 from anlauf at gcc dot gnu.org --- See also pr109701 which is a likely related.
[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Aldy Hernandez --- fixed
[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711 --- Comment #10 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:2b8a27634f5d28e3e7c4a08bf065f2daada7aed2 commit r14-458-g2b8a27634f5d28e3e7c4a08bf065f2daada7aed2 Author: Aldy Hernandez Date: Wed May 3 17:29:24 2023 +0200 Allow varying ranges of unknown types in irange::verify_range [PR109711] The old legacy code allowed building ranges of unknown types so passes like IPA could build and propagate VARYING. For now it's easiest to allow the old behavior, it's not like you can do anything with these ranges except build them and copy them. Eventually we should convert all users of set_varying() to use supported types. I will address this in my upcoming IPA work. PR tree-optimization/109711 gcc/ChangeLog: * value-range.cc (irange::verify_range): Allow types of error_mark_node.
[Bug c++/109649] [13/14 Regression] GCC accepts invalid inaccessible friend declaration of member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109649 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/109666] [13/14 Regression] Segmentation fault with std::array using gcc 13 since r13-6788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jason Merrill --- Fixed for 13.2/14.
[Bug c++/109678] [13/14 Regression] exponential time behavior on std::variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109678 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed for 13.2/14.
[Bug target/109650] avr-gcc incorrect code with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109650 Georg-Johann Lay changed: What|Removed |Added Component|middle-end |target --- Comment #7 from Georg-Johann Lay --- Target issue: Implicitly introduced by PR92729 as avr's machine dependent reorg in avr.cc::avr_reorg() still assumes there is nothing between a comparison and the following conditional branch, like it was with cc0. However, pass "jump2" introduces a label between a comarison and a branch insn. Affected are all versions from v12 onwards.
[Bug c++/109715] abi_tag attribute is not applied to variable templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109715 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-05-03
[Bug sanitizer/90746] __sanitizer_cov_trace_pc should not be tail called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90746 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Alexander Monakov --- Fixed for gcc-14.
[Bug sanitizer/90746] __sanitizer_cov_trace_pc should not be tail called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90746 --- Comment #4 from CVS Commits --- The master branch has been updated by Alexander Monakov : https://gcc.gnu.org/g:cef0c0bb13e2953b41caca0506ab1d41c56f29de commit r14-457-gcef0c0bb13e2953b41caca0506ab1d41c56f29de Author: Alexander Monakov Date: Thu Jan 19 19:25:04 2023 +0300 do not tailcall __sanitizer_cov_trace_pc [PR90746] When instrumentation is requested via -fsanitize-coverage=trace-pc, GCC emits calls of __sanitizer_cov_trace_pc callback in each basic block. This callback is supposed to be implemented by the user, and should be able to identify the containing basic block by inspecting its return address. Tailcalling the callback prevents that, so disallow it. gcc/ChangeLog: PR sanitizer/90746 * calls.cc (can_implement_as_sibling_call_p): Reject calls to __sanitizer_cov_trace_pc. gcc/testsuite/ChangeLog: PR sanitizer/90746 * gcc.dg/sancov/basic0.c: Verify absence of tailcall.
[Bug target/109661] [13 Regression] ICE in aarch64_function_arg_alignment when building erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109661 rsandifo at gcc dot gnu.org changed: What|Removed |Added Summary|[13/14 Regression] ICE in |[13 Regression] ICE in |aarch64_function_arg_alignm |aarch64_function_arg_alignm |ent when building erlang|ent when building erlang --- Comment #9 from rsandifo at gcc dot gnu.org --- Fixed on trunk. Will remove the assert on branches.
[Bug target/109661] [13/14 Regression] ICE in aarch64_function_arg_alignment when building erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109661 --- Comment #8 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:1c26adba4b95f9a79f3aa57637d34cff7982d832 commit r14-456-g1c26adba4b95f9a79f3aa57637d34cff7982d832 Author: Richard Sandiford Date: Wed May 3 17:43:48 2023 +0100 aarch64: Fix ABI handling of aligned enums [PR109661] aarch64_function_arg_alignment has traditionally taken the alignment of a scalar type T from TYPE_ALIGN (TYPE_MAIN_VARIANT (T)). This is supposed to discard any user alignment and give the alignment of the underlying fundamental type. PR109661 shows that this did the wrong thing for enums with a defined underlying type, because: (1) The enum itself could be aligned, using attributes. (2) The enum would pick up any user alignment on the underlying type. We get the right behaviour if we look at the TYPE_MAIN_VARIANT of the underlying type instead. As always, this affects register and stack arguments differently, because: (a) The code that handles register arguments only considers the alignment of types that occupy two registers, whereas the stack alignment is applied regardless of size. (b) The code that handles register arguments tests the alignment for equality with 16 bytes, so that (unexpected) greater alignments are ignored. The code that handles stack arguments instead caps the alignment to 16 bytes. There is now (since GCC 13) an assert to trap the difference between (a) and (b), which is how the new incompatiblity showed up. Clang alredy handled the testcases correctly, so this patch aligns the GCC behaviour with the Clang behaviour. I'm planning to remove the asserts on the branches, since we don't want to change the ABI there. gcc/ PR target/109661 * config/aarch64/aarch64.cc (aarch64_function_arg_alignment): Add a new ABI break parameter for GCC 14. Set it to the alignment of enums that have an underlying type. Take the true alignment of such enums from the TYPE_ALIGN of the underlying type's TYPE_MAIN_VARIANT. (aarch64_function_arg_boundary): Update accordingly. (aarch64_layout_arg, aarch64_gimplify_va_arg_expr): Likewise. Warn about ABI differences. gcc/testsuite/ * g++.target/aarch64/pr109661-1.C: New test. * g++.target/aarch64/pr109661-2.C: Likewise. * g++.target/aarch64/pr109661-3.C: Likewise. * g++.target/aarch64/pr109661-4.C: Likewise. * gcc.target/aarch64/pr109661-1.c: Likewise.
[Bug target/109661] [13/14 Regression] ICE in aarch64_function_arg_alignment when building erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109661 --- Comment #7 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:3a4a39b391e63e5be04cb06ee4cd5400bef63dfc commit r14-455-g3a4a39b391e63e5be04cb06ee4cd5400bef63dfc Author: Richard Sandiford Date: Wed May 3 17:43:48 2023 +0100 aarch64: Rename abi_break parameters [PR109661] aarch64_function_arg_alignment has two related abi_break parameters: abi_break for a change in GCC 9, and abi_break_packed for a related follow-on change in GCC 13. In a sense, abi_break_packed is a "subfix" of abi_break. PR109661 now requires a third ABI break that is independent of the other two. Having abi_break for the GCC 9 break and abi_break_ for the GCC 13 and GCC 14 breaks might give the impression that they're all related, and that the GCC 14 fix (like the GCC 13 fix) is a "subfix" of the GCC 9 one. It therefore seemed like a good idea to rename the existing variables first. It would be difficult to choose names that describe briefly and precisely what went wrong in each case. The next best thing seemed to be to name them after the relevant GCC version. (Of course, this might break down in future if we need two independent fixes in the same version. Let's hope not.) I wondered about putting all the variables in a structure, but one advantage of using independent variables is that it's harder to forget to update a caller. Maybe a fourth parameter would be a tipping point. gcc/ PR target/109661 * config/aarch64/aarch64.cc (aarch64_function_arg_alignment): Rename ABI break variables to abi_break_gcc_9 and abi_break_gcc_13. (aarch64_layout_arg, aarch64_function_arg_boundary): Likewise. (aarch64_gimplify_va_arg_expr): Likewise.
[Bug c++/109717] -Warray-bound error with gnu++20 and fmt library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717 --- Comment #2 from Jonathan Wakely --- It's not actually broken, it's just paranoid, and the overflow detection triggers for dead code. The optimizer analyzes different paths through the code separately, and fails to detect that some of those paths are unreachable, and then warns that they would overflow if those paths were taken.
[Bug libstdc++/105844] [10/11 Regression] std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jonathan Wakely --- Fixed for 11.4 and 10.5
[Bug libstdc++/105844] [10/11 Regression] std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:14175f2262c94868e26f01eef1e14418f2b5e6a9 commit r10-11388-g14175f2262c94868e26f01eef1e14418f2b5e6a9 Author: Jonathan Wakely Date: Fri Jun 10 14:39:13 2022 +0100 libstdc++: Make std::lcm and std::gcd detect overflow [PR105844] When I fixed PR libstdc++/92978 I introduced a regression whereby std::lcm(INT_MIN, 1) and std::lcm(5, 4) would no longer produce errors during constant evaluation. Those calls are undefined, because they violate the preconditions that |m| and the result can be represented in the return type (which is int in both those cases). The regression occurred because __absu(INT_MIN) is well-formed, due to the explicit casts to unsigned in that new helper function, and the out-of-range multiplication is well-formed, because unsigned arithmetic wraps instead of overflowing. To fix 92978 I made std::gcm and std::lcm calculate |m| and |n| immediately, yielding a common unsigned type that was used to calculate the result. That was partly correct, but there's no need to use an unsigned type. Doing so only suppresses the overflow errors so the compiler can't detect them. This change replaces __absu with __abs_r that returns the common type (not its corresponding unsigned type). This way we can detect overflow in __abs_r when required, while still supporting the most-negative value when it can be represented in the result type. To detect LCM results that are out of range of the result type we still need explicit checks, because neither constant evaluation nor UBsan will complain about unsigned wrapping for cases such as std::lcm(50u, 49u). We can detect those overflows efficiently by using __builtin_mul_overflow and asserting. libstdc++-v3/ChangeLog: PR libstdc++/105844 * include/experimental/numeric (experimental::gcd): Simplify assertions. Use __abs_r instead of __absu. (experimental::lcm): Likewise. Remove use of __detail::__lcm so overflow can be detected. * include/std/numeric (__detail::__absu): Rename to __abs_r and change to allow signed result type, so overflow can be detected. (__detail::__lcm): Remove. (gcd): Simplify assertions. Use __abs_r instead of __absu. (lcm): Likewise. Remove use of __detail::__lcm so overflow can be detected. * testsuite/26_numerics/gcd/gcd_neg.cc: Adjust dg-error lines. * testsuite/26_numerics/lcm/lcm_neg.cc: Likewise. * testsuite/26_numerics/gcd/105844.cc: New test. * testsuite/26_numerics/lcm/105844.cc: New test. (cherry picked from commit 671970a5621e18e7079b4ca113e56434c858db66)
[Bug libstdc++/92978] std::gcd mishandles mixed-signedness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92978 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:14175f2262c94868e26f01eef1e14418f2b5e6a9 commit r10-11388-g14175f2262c94868e26f01eef1e14418f2b5e6a9 Author: Jonathan Wakely Date: Fri Jun 10 14:39:13 2022 +0100 libstdc++: Make std::lcm and std::gcd detect overflow [PR105844] When I fixed PR libstdc++/92978 I introduced a regression whereby std::lcm(INT_MIN, 1) and std::lcm(5, 4) would no longer produce errors during constant evaluation. Those calls are undefined, because they violate the preconditions that |m| and the result can be represented in the return type (which is int in both those cases). The regression occurred because __absu(INT_MIN) is well-formed, due to the explicit casts to unsigned in that new helper function, and the out-of-range multiplication is well-formed, because unsigned arithmetic wraps instead of overflowing. To fix 92978 I made std::gcm and std::lcm calculate |m| and |n| immediately, yielding a common unsigned type that was used to calculate the result. That was partly correct, but there's no need to use an unsigned type. Doing so only suppresses the overflow errors so the compiler can't detect them. This change replaces __absu with __abs_r that returns the common type (not its corresponding unsigned type). This way we can detect overflow in __abs_r when required, while still supporting the most-negative value when it can be represented in the result type. To detect LCM results that are out of range of the result type we still need explicit checks, because neither constant evaluation nor UBsan will complain about unsigned wrapping for cases such as std::lcm(50u, 49u). We can detect those overflows efficiently by using __builtin_mul_overflow and asserting. libstdc++-v3/ChangeLog: PR libstdc++/105844 * include/experimental/numeric (experimental::gcd): Simplify assertions. Use __abs_r instead of __absu. (experimental::lcm): Likewise. Remove use of __detail::__lcm so overflow can be detected. * include/std/numeric (__detail::__absu): Rename to __abs_r and change to allow signed result type, so overflow can be detected. (__detail::__lcm): Remove. (gcd): Simplify assertions. Use __abs_r instead of __absu. (lcm): Likewise. Remove use of __detail::__lcm so overflow can be detected. * testsuite/26_numerics/gcd/gcd_neg.cc: Adjust dg-error lines. * testsuite/26_numerics/lcm/lcm_neg.cc: Likewise. * testsuite/26_numerics/gcd/105844.cc: New test. * testsuite/26_numerics/lcm/105844.cc: New test. (cherry picked from commit 671970a5621e18e7079b4ca113e56434c858db66)
[Bug c++/109718] New: Dependency generation for header-units and modules not possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109718
Bug ID: 109718
Summary: Dependency generation for header-units and modules not
possible
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
To generate make-dependencies I use the following command line:
g++ -c -MD -MG -std=c++23 -fconcepts -fmodules-ts test.cc
where test.cc is:
-
import ;
int main() {
}
-
It gives the error:
cc1plus: error: '-MG' may only be used with '-M' or '-MM'
Removing -MG gives also an error, because the precompiled header does not yet
exist:
/usr/local/include/c++/14.0.0/iostream: error: failed to read compiled module:
No such file or directory
/usr/local/include/c++/14.0.0/iostream: note: compiled module file is
'gcm.cache/./usr/local/include/c++/14.0.0/iostream.gcm'
/usr/local/include/c++/14.0.0/iostream: note: imports must be built before
being imported
/usr/local/include/c++/14.0.0/iostream: fatal error: returning to the gate for
a mechanical issue
So, it looks that there is no possiblity to create a valid dependency file with
gcc.
[Bug c++/109717] -Warray-bound error with gnu++20 and fmt library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717 --- Comment #1 from Paul Smith --- This same test case also causes spurious errors for -Wstringop-overflow :( If I use this compile line with the same source file, I get these errors: $ g++-13.1 -I/data/src/build/common/fmt/include -std=gnu++20 -Wstringop-overflow -O2 -c -o /tmp/fmt1.o /tmp/fmt1.cpp In file included from /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/vector:62, from /tmp/fmt1.cpp:1: In static member function 'static constexpr _Up* std::__copy_move<_IsMove, true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp = unsigned int; _Up = unsigned int; bool _IsMove = false]', inlined from 'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false; _II = unsigned int*; _OI = unsigned int*]' at /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:506:30, inlined from 'constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove = false; _II = unsigned int*; _OI = unsigned int*]' at /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:533:42, inlined from 'constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false; _II = unsigned int*; _OI = unsigned int*]' at /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:540:31, inlined from 'constexpr _OI std::copy(_II, _II, _OI) [with _II = unsigned int*; _OI = unsigned int*]' at /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:633:7, inlined from 'static _ForwardIterator std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = unsigned int*; _ForwardIterator = unsigned int*]' at /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_uninitialized.h:147:27, inlined from '_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = unsigned int*; _ForwardIterator = unsigned int*]' at /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_uninitialized.h:185:15, inlined from 'constexpr void fmt::v9::basic_memory_buffer::grow(size_t) [with T = unsigned int; long unsigned int SIZE = 32; Allocator = std::allocator]' at /data/src/build/common/fmt/include/fmt/format.h:925:26, inlined from 'constexpr void fmt::v9::detail::buffer::try_reserve(size_t) [with T = unsigned int]' at /data/src/build/common/fmt/include/fmt/core.h:928:39, inlined from 'constexpr void fmt::v9::detail::buffer::try_reserve(size_t) [with T = unsigned int]' at /data/src/build/common/fmt/include/fmt/core.h:927:24, inlined from 'constexpr void fmt::v9::detail::buffer::try_resize(size_t) [with T = unsigned int]' at /data/src/build/common/fmt/include/fmt/core.h:919:16, inlined from 'constexpr void fmt::v9::basic_memory_buffer::resize(size_t) [with T = unsigned int; long unsigned int SIZE = 32; Allocator = std::allocator]' at /data/src/build/common/fmt/include/fmt/format.h:897:63, inlined from 'constexpr void fmt::v9::detail::bigint::assign(UInt) [with UInt = long unsigned int; typename std::enable_if<(std::is_same::value || std::is_same::value), int>::type = 0]' at /data/src/build/common/fmt/include/fmt/format.h:2792:19, inlined from 'constexpr void fmt::v9::detail::bigint::operator=(Int) [with Int = int]' at /data/src/build/common/fmt/include/fmt/format.h:2813:11, inlined from 'constexpr void fmt::v9::detail::bigint::assign_pow10(int)' at /data/src/build/common/fmt/include/fmt/format.h:2886:32: /data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:437:30: warning: 'void* __builtin_memmove(void*, const void*, long unsigned int)' writing between 5 and 9223372036854775807 bytes into a region of size 4 overflows the destination [-Wstringop-overflow=] 437 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num); | ~^~~ Again that same test works fine with GCC 11.3. It seems that overflow detection in GCC 13.1 is really broken.
[Bug c++/109717] New: -Warray-bound error with gnu++20 and fmt library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717
Bug ID: 109717
Summary: -Warray-bound error with gnu++20 and fmt library
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: psmith at gnu dot org
Target Milestone: ---
Created attachment 54983
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54983=edit
fmt1.i preprocessor output (compressed)
I found SO MANY issues related to -Warray-bound, many of them reported with GCC
11 or so. I can't tell if this is a duplicate or not, although this issue
doesn't reproduce for me with GCC 11.3.
I have built my own GCC 13.1 from source on x86_64 GNU/Linux (as I've been
doing for >10 years) and it works great except for one thing. When I use some
parts of the fmt 9.1.0 library, and "-O2 -Werror-builds -std=gnu++20" (removing
any one of those, or changing to -std=gnu++17, makes the error go away).
I try to compile this:
#include
#include
#include
void add_info(std::vector& buf)
{
fmt::format_to(std::back_inserter(buf), "hello {}", "there");
}
and I get this output:
$ g++-13.1 -I/data/src/build/common/fmt/include -std=gnu++20 -Warray-bounds -O2
-c -o /tmp/fmt1.o /tmp/fmt1.cpp
In file included from
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/vector:62,
from /tmp/fmt1.cpp:1:
In static member function 'static constexpr _Up* std::__copy_move<_IsMove,
true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp =
unsigned int; _Up = unsigned int; bool _IsMove = false]',
inlined from 'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool
_IsMove = false; _II = unsigned int*; _OI = unsigned int*]' at
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:506:30,
inlined from 'constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool
_IsMove = false; _II = unsigned int*; _OI = unsigned int*]' at
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:533:42,
inlined from 'constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool
_IsMove = false; _II = unsigned int*; _OI = unsigned int*]' at
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:540:31,
inlined from 'constexpr _OI std::copy(_II, _II, _OI) [with _II = unsigned
int*; _OI = unsigned int*]' at
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:633:7,
inlined from 'static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator) [with _InputIterator = unsigned int*; _ForwardIterator =
unsigned int*]' at
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_uninitialized.h:147:27,
inlined from '_ForwardIterator std::uninitialized_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator = unsigned int*;
_ForwardIterator = unsigned int*]' at
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_uninitialized.h:185:15,
inlined from 'constexpr void fmt::v9::basic_memory_buffer::grow(size_t) [with T = unsigned int; long unsigned int SIZE = 32;
Allocator = std::allocator]' at
/data/src/build/common/fmt/include/fmt/format.h:925:26,
inlined from 'constexpr void
fmt::v9::detail::buffer::try_reserve(size_t) [with T = unsigned int]' at
/data/src/build/common/fmt/include/fmt/core.h:928:39,
inlined from 'constexpr void
fmt::v9::detail::buffer::try_reserve(size_t) [with T = unsigned int]' at
/data/src/build/common/fmt/include/fmt/core.h:927:24,
inlined from 'constexpr void fmt::v9::detail::buffer::try_resize(size_t)
[with T = unsigned int]' at
/data/src/build/common/fmt/include/fmt/core.h:919:16,
inlined from 'constexpr void fmt::v9::basic_memory_buffer::resize(size_t) [with T = unsigned int; long unsigned int SIZE = 32;
Allocator = std::allocator]' at
/data/src/build/common/fmt/include/fmt/format.h:897:63,
inlined from 'constexpr void fmt::v9::detail::bigint::assign(UInt) [with
UInt = long unsigned int; typename std::enable_if<(std::is_same::value || std::is_same::value),
int>::type = 0]' at
/data/src/build/common/fmt/include/fmt/format.h:2792:19,
inlined from 'constexpr void fmt::v9::detail::bigint::operator=(Int) [with
Int = int]' at /data/src/build/common/fmt/include/fmt/format.h:2813:11,
inlined from 'constexpr void fmt::v9::detail::bigint::assign_pow10(int)' at
/data/src/build/common/fmt/include/fmt/format.h:2886:32:
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/13.1.0/bits/stl_algobase.h:437:30:
warning: 'void* __builtin_memmove(void*, const void*, long unsigned int)'
forming offset 4
[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711 Aldy Hernandez changed: What|Removed |Added Attachment #54980|0 |1 is obsolete|| --- Comment #9 from Aldy Hernandez --- Created attachment 54982 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54982=edit patch in testing I think it's easiest to restore the legacy behavior for now. A proper conversion of IPA should follow.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 --- Comment #42 from Kees Cook --- Exciting! Are you able to attach the latest patch? I'd love to try it out. I've been testing Clang's version as well: https://reviews.llvm.org/D148381
[Bug tree-optimization/109410] [13/14 Regression] ICE: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109410 --- Comment #17 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:dc457bc1c72c53ee8c4800bac84264e0c8085f24 commit r10-11385-gdc457bc1c72c53ee8c4800bac84264e0c8085f24 Author: Jakub Jelinek Date: Wed Apr 12 16:55:15 2023 +0200 reassoc: Fix up another ICE with returns_twice call [PR109410] The following testcase ICEs in reassoc, unlike the last case I've fixed there here SSA_NAME_USED_IN_ABNORMAL_PHI is not the case anywhere. build_and_add_sum places new statements after the later appearing definition of an operand but if both operands are default defs or constants, we place statement at the start of the function. If the very first statement of a function is a call to returns_twice function, this doesn't work though, because that call has to be the first thing in its basic block, so the following patch splits the entry successor edge such that the new statements are added into a different block from the returns_twice call. I think we should in stage1 reconsider such placements, I think it unnecessarily enlarges the lifetime of the new lhs if its operand(s) are used more than once in the function. Unless something sinks those again. Would be nice to place it closer to the actual uses (or where they will be placed). 2023-04-12 Jakub Jelinek PR tree-optimization/109410 * tree-ssa-reassoc.c (build_and_add_sum): Split edge from entry block if first statement of the function is a call to returns_twice function. * gcc.dg/pr109410.c: New test. (cherry picked from commit 51856718a82ce60f067910d9037ca255645b37eb)
[Bug other/109306] The strstr implementation in libiberty might have undefined behavior (out of bounds mem access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109306
--- Comment #11 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:9ae5c50751ef4217b22cc24b67a44a55efef59b9
commit r10-11384-g9ae5c50751ef4217b22cc24b67a44a55efef59b9
Author: Jakub Jelinek
Date: Sun Apr 2 20:05:31 2023 +0200
libiberty: Make strstr.c in libiberty ANSI compliant
On Fri, Nov 13, 2020 at 11:53:43AM -0700, Jeff Law via Gcc-patches wrote:
>
> On 5/1/20 6:06 PM, Seija Kijin via Gcc-patches wrote:
> > The original code in libiberty says "FIXME" and then says it has not
been
> > validated to be ANSI compliant. However, this patch changes the
function to
> > match implementations that ARE compliant, and such code is in the
public
> > domain.
> >
> > I ran the test results, and there are no test failures.
>
> Thanks. This seems to be the standard "simple" strstr implementation.
> There's significantly faster implementations available, but I doubt it's
> worth the effort as the version in this file only gets used if there is
> no system strstr.c.
Except that PR109306 says the new version is non-compliant and
is certainly slower than what we used to have. The only problem I see
on the old version (sure, it is not very fast version) is that for
strstr ("abcd", "") it returned "abcd"+4 rather than "abcd" because
strchr in that case changed p to point to the last character and then
strncmp returned 0.
The question reported in PR109306 is whether memcmp is required not to
access characters beyond the first difference or not.
For all of memcmp/strcmp/strncmp, C17 says:
"The sign of a nonzero value returned by the comparison functions memcmp,
strcmp, and strncmp
is determined by the sign of the difference between the values of the first
pair of characters (both
interpreted as unsigned char) that differ in the objects being compared."
but then in memcmp description says:
"The memcmp function compares the first n characters of the object pointed
to by s1 to the first n
characters of the object pointed to by s2."
rather than something similar to strncmp wording:
"The strncmp function compares not more than n characters (characters that
follow a null character
are not compared) from the array pointed to by s1 to the array pointed to
by
s2."
So, while for strncmp it seems clearly well defined when there is zero
terminator before reaching the n, for memcmp it is unclear if say
int
memcmp (const void *s1, const void *s2, size_t n)
{
int ret = 0;
size_t i;
const unsigned char *p1 = (const unsigned char *) s1;
const unsigned char *p2 = (const unsigned char *) s2;
for (i = n; i; i--)
if (p1[i - 1] != p2[i - 1])
ret = p1[i - 1] < p2[i - 1] ? -1 : 1;
return ret;
}
wouldn't be valid implementation (one which always compares all characters
and just returns non-zero from the first one that differs).
So, shouldn't we just revert and handle the len == 0 case correctly?
I think almost nothing really uses it, but still, the old version
at least worked nicer with a fast strchr.
Could as well strncmp (p + 1, s2 + 1, len - 1) if that is preferred
because strchr already compared the first character.
2023-04-02 Jakub Jelinek
PR other/109306
* strstr.c (strstr): Return s1 if len is 0.
(cherry picked from commit 1719fa40c4ee4def60a2ce2f27e17f8168cf28ba)
[Bug ipa/105685] [10 Regression] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105685 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9fa953c8dfc7ee57ffd33e0b4e8be782c3119666 commit r10-11382-g9fa953c8dfc7ee57ffd33e0b4e8be782c3119666 Author: Jakub Jelinek Date: Sun Mar 26 20:15:05 2023 +0200 predict: Don't emit -Wsuggest-attribute=cold warning for functions which already have that attribute [PR105685] In the following testcase, we predict baz to have cold entry regardless of the user supplied attribute (as it call unconditionally a cold function), but still issue a -Wsuggest-attribute=cold warning despite it having that attribute already. The following patch avoids that. 2023-03-26 Jakub Jelinek PR ipa/105685 * predict.c (compute_function_frequency): Don't call warn_function_cold if function already has cold attribute. * c-c++-common/cold-2.c: New test. (cherry picked from commit 7eca91d4781bb3df941f25c30b971dac66ba1b3d)
[Bug c++/109164] wrong code with thread_local reference, loops and -ftree-pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109164 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:73accd859e80e5d50937b8dc85a4e509fc174b97 commit r10-11381-g73accd859e80e5d50937b8dc85a4e509fc174b97 Author: Jakub Jelinek Date: Mon Mar 20 20:29:47 2023 +0100 c++: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164] The following two testcases are miscompiled, because we keep TREE_READONLY on the vars even when they are (possibly) dynamically initialized by a TLS wrapper function. Normally cp_finish_decl drops TREE_READONLY from vars which need dynamic initialization, but for TLS we do this kind of initialization upon every access to those variables. Keeping them TREE_READONLY means e.g. PRE can hoist loads from those before loops which contain the TLS wrapper calls, so we can access the TLS variables before they are initialized. 2023-03-20 Jakub Jelinek PR c++/109164 * cp-tree.h (var_needs_tls_wrapper): Declare. * decl2.c (var_needs_tls_wrapper): No longer static. * decl.c (cp_finish_decl): Clear TREE_READONLY on TLS variables for which a TLS wrapper will be needed. * g++.dg/tls/thread_local13.C: New test. * g++.dg/tls/thread_local13-aux.cc: New file. * g++.dg/tls/thread_local14.C: New test. * g++.dg/tls/thread_local14-aux.cc: New file. (cherry picked from commit 0a846340b99675d57fc2f2923a0412134eed09d3)
[Bug middle-end/106190] [10 Regression] ICE in expand_builtin_eh_common with -fnon-call-exceptions -fsanitize=address,undefined -fno-sanitize-recover=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106190
--- Comment #15 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:c8dc9e474549c3c6692a71f5d0c791ef900cb60c
commit r10-11383-gc8dc9e474549c3c6692a71f5d0c791ef900cb60c
Author: Jakub Jelinek
Date: Tue Mar 28 10:56:44 2023 +0200
sanopt: Return TODO_cleanup_cfg if any .{UB,HWA,A}SAN_* calls were lowered
[PR106190]
The following testcase ICEs, because without optimization eh lowering
decides not to duplicate finally block of try/finally and so we end up
with variable guarded cleanup. The sanopt pass creates a cfg that ought
to be cleaned up (some IFN_UBSAN_* functions are lowered in this case with
constant conditions in gcond and when not allowing recovery some bbs which
end with noreturn calls actually have successor edges), but the cfg cleanup
is actually (it is -O0) done only during the optimized pass. We notice
there that the d[1][a] = 0; statement which has an EH edge is unreachable
(because ubsan would always abort on the out of bounds d[1] access), remove
the EH landing pad and block, but because that block just sets a variable
and jumps to another one which tests that variable and that one is
reachable
from normal control flow, the __builtin_eh_pointer (1) later in there is
kept in the IL and we ICE during expansion of that statement because the
EH region has been removed.
The following patch fixes it by doing the cfg cleanup already during
sanopt pass if we create something that might need it, while the EH
landing pad is then removed already during sanopt pass, there is ehcleanup
later and we don't ICE anymore.
2023-03-28 Jakub Jelinek
PR middle-end/106190
* sanopt.c (pass_sanopt::execute): Return TODO_cleanup_cfg if any
of the IFN_{UB,HWA,A}SAN_* internal fns are lowered.
* gcc.dg/asan/pr106190.c: New test.
(cherry picked from commit 39a43dc336561e0eba0de477b16c7355f19d84ee)
[Bug c/109151] UBsan misses a divide-by-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109151 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bdd543db33706643993a468740487147c89a4bd2 commit r10-11379-gbdd543db33706643993a468740487147c89a4bd2 Author: Jakub Jelinek Date: Fri Mar 17 16:10:14 2023 +0100 c, ubsan: Instrument even shortened divisions [PR109151] On the following testcase, the C FE decides to shorten the division because it has a guarantee that INT_MIN / -1 division won't be encountered, the first operand is widened from narrower unsigned and/or the second operand is a constant other than all ones (in this case both are true). The problem is that the narrower type in this case is _Bool and ubsan_instrument_division only instruments it if op0's type is INTEGER_TYPE or REAL_TYPE. Strangely this doesn't happen in C++ FE. Anyway, we only shorten divisions if the INT_MIN / -1 case is impossible, so I think we should be fine even with -fstrict-enums in C++ in case it shortened to ENUMERAL_TYPEs. The following patch just instruments those on the ubsan_instrument_division side. Perhaps only the first hunk and testcase might be needed because we shouldn't shorten if the other case could be triggered. 2023-03-17 Jakub Jelinek PR c/109151 * c-ubsan.c (ubsan_instrument_division): Handle all scalar integral types rather than just INTEGER_TYPE. * c-c++-common/ubsan/div-by-zero-8.c: New test. (cherry picked from commit 103d423f6ce72ccb03d55b7b1dfa2dabd5854371)
[Bug target/105554] [10 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554
--- Comment #27 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:06b34c0d76153549fb83001c3d90b798066a1851
commit r10-11380-g06b34c0d76153549fb83001c3d90b798066a1851
Author: Jakub Jelinek
Date: Fri Mar 17 18:59:56 2023 +0100
tree-inline: Fix up multiversioning with vector arguments [PR105554]
The following testcase ICEs, because we call tree_function_versioning from
old_decl which has target attributes not supporting V4DImode and so
DECL_MODE of DECL_ARGUMENTS is BLKmode, while new_decl supports those.
tree_function_versioning initially copies DECL_RESULT and DECL_ARGUMENTS
from old_decl to new_decl, then calls initialize_cfun to create cfun
and only when the cfun is created it can later actually remap_decl
DECL_RESULT and DECL_ARGUMENTS etc.
The problem is that initialize_cfun -> push_struct_function ->
allocate_struct_function calls relayout_decl on DECL_RESULT and
DECL_ARGUMENTS, which clobbers DECL_MODE of old_decl and we then ICE
because
of it.
In particular, allocate_struct_function does:
if (!abstract_p)
{
/* Now that we have activated any function-specific attributes
that might affect layout, particularly vector modes, relayout
each of the parameters and the result. */
relayout_decl (result);
for (tree parm = DECL_ARGUMENTS (fndecl); parm;
parm = DECL_CHAIN (parm))
relayout_decl (parm);
/* Similarly relayout the function decl. */
targetm.target_option.relayout_function (fndecl);
}
if (!abstract_p && aggregate_value_p (result, fndecl))
{
#ifdef PCC_STATIC_STRUCT_RETURN
cfun->returns_pcc_struct = 1;
#endif
cfun->returns_struct = 1;
}
Now, in the case of tree_function_versioning, I believe all that we need
from these is possibly the
targetm.target_option.relayout_function (fndecl);
call (arm only), we will remap DECL_RESULT and DECL_ARGUMENTS later on
and copy_decl_for_dup_finish in that case will handle all we need:
/* For vector typed decls make sure to update DECL_MODE according
to the new function context. */
if (VECTOR_TYPE_P (TREE_TYPE (copy)))
SET_DECL_MODE (copy, TYPE_MODE (TREE_TYPE (copy)));
We don't need the cfun->returns_*struct either, because we override it
in initialize_cfun a few lines later:
/* Copy items we preserve during cloning. */
...
cfun->returns_struct = src_cfun->returns_struct;
cfun->returns_pcc_struct = src_cfun->returns_pcc_struct;
So, to avoid the clobbering of DECL_RESULT/DECL_ARGUMENTS of old_decl,
the following patch arranges allocate_struct_function to be called with
abstract_p true and calls targetm.target_option.relayout_function (fndecl);
by hand.
The removal of DECL_RESULT/DECL_ARGUMENTS copying at the start of
initialize_cfun is removed because the only caller -
tree_function_versioning, does that unconditionally before.
2023-03-17 Jakub Jelinek
PR target/105554
* function.h (push_struct_function): Add ABSTRACT_P argument
defaulted
to false.
* function.c (push_struct_function): Add ABSTRACT_P argument, pass
it
to allocate_struct_function instead of false.
* tree-inline.c (initialize_cfun): Don't copy DECL_ARGUMENTS
nor DECL_RESULT here. Pass true as ABSTRACT_P to
push_struct_function. Call targetm.target_option.relayout_function
after it.
(tree_function_versioning): Formatting fix.
* gcc.target/i386/pr105554.c: New test.
(cherry picked from commit 24c06560a7fa39049911eeb8777325d112e0deb9)
