[Bug c/117230] [14/15 Regression] ICE: in sizeof_pointer_memaccess_warning, at c-family/c-warn.cc:987 with -Wsizeof-pointer-memaccess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117230
--- Comment #4 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:20c180cf65e81257d40d6e0f3d798b5ec5364b11
commit r14-10830-g20c180cf65e81257d40d6e0f3d798b5ec5364b11
Author: Jakub Jelinek
Date: Tue Oct 22 20:30:41 2024 +0200
c-family: Fix up -Wsizeof-pointer-memaccess ICEs [PR117230]
In the following testcases, we ICE on all 4 function calls.
The problem is using TYPE_PRECISION on vector types (but guess it
would be similarly problematic on structures/unions/arrays).
The test only differentiates between suggestion what to do, whether
to supply explicit size because sizeof (*p) for
{,{,un}signed }char *p is not very likely what the user want, or
dereferencing the pointer, so I think limiting that suggestion
to integral types is ok.
2024-10-22 Jakub Jelinek
PR c/117230
* c-warn.cc (sizeof_pointer_memaccess_warning): Only compare
TYPE_PRECISION of TREE_TYPE (type) to precision of char if
TREE_TYPE (type) is integral type.
* c-c++-common/Wsizeof-pointer-memaccess5.c: New test.
(cherry picked from commit 5fd1c0c1b6968d55e3f997d67a4c149edf20c012)
[Bug target/117268] [14 Regression] GCC target("general-regs-only") leaves __AVX__ defined after a push_options/pop_options 'scope'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117268
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Ville Voutilainen from comment #2)
> > Possibly. It makes fair amounts of sense that predefined macros are
> > reapplied after an options scope is exited. But it does break existing code.
> > See https://bugreports.qt.io/browse/QTBUG-130381
>
> The existing code was only added in 2022:
> https://github.com/qt/qtquick3d/commit/
> 7980cfd07eaaa8e12aecb3a6047805fefe048d80
>
> undefining macros in the implemented defined area is undefined.
>
> The better fix is to use `#pragma GCC target("no-sse3")` instead.
See https://godbolt.org/z/MKE6heY8z to verify that works
[Bug middle-end/116891] [12/13/14 Regression] invalid optimization of -fma(-x,x,-z) when -O3 and -frounding-math are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116891 --- Comment #14 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6603ec4d113dba8dc286140cb440a89dcb411a6e commit r14-10829-g6603ec4d113dba8dc286140cb440a89dcb411a6e Author: Jakub Jelinek Date: Tue Oct 15 19:38:46 2024 +0200 match.pd: Further fma negation fixes [PR116891] On Mon, Oct 14, 2024 at 08:53:29AM +0200, Jakub Jelinek wrote: > > PR middle-end/116891 > > * match.pd ((negate (IFN_FNMS@3 @0 @1 @2)) -> (IFN_FMA @0 @1 @2)): > > Only enable for !HONOR_SIGN_DEPENDENT_ROUNDING. > > Guess it would be nice to have a testcase which FAILs without the patch and > PASSes with it, but it can be added later. I've added such a testcase now, and additionally found the fix only fixed one of the 4 problematic similar cases. Here is a patch which fixes the others too and adds the testcases. fma-pr116891.c FAILed without your patch, FAILs with your patch too (but only due to the bar/baz/qux checks) and PASSes with the patch. 2024-10-15 Jakub Jelinek PR middle-end/116891 * match.pd ((negate (fmas@3 @0 @1 @2)) -> (IFN_FNMS @0 @1 @2)): Only enable for !HONOR_SIGN_DEPENDENT_ROUNDING. ((negate (IFN_FMS@3 @0 @1 @2)) -> (IFN_FNMA @0 @1 @2)): Likewise. ((negate (IFN_FNMA@3 @0 @1 @2)) -> (IFN_FMS @0 @1 @2)): Likewise. * gcc.dg/pr116891.c: New test. * gcc.target/i386/fma-pr116891.c: New test. (cherry picked from commit 4366f0c7e296ea0d7279343c9b0a1d597588a1da)
[Bug c/117230] [14/15 Regression] ICE: in sizeof_pointer_memaccess_warning, at c-family/c-warn.cc:987 with -Wsizeof-pointer-memaccess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117230 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Should be fixed now for 15+ and 14.3+.
[Bug middle-end/117199] [15 regression] libgcrypt-1.11.0 fails to link (warning: relocation against `.LC11' in read-only section `.text')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117199 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek --- Should be fixed now.
[Bug c/117190] [15 Regression] ICE on linux-6.11.3: in size_binop_loc, at fold-const.cc:2085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117190 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #12 from Jakub Jelinek --- Should be fixed now.
[Bug middle-end/116891] [12/13/14 Regression] invalid optimization of -fma(-x,x,-z) when -O3 and -frounding-math are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116891 --- Comment #13 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ffce44e8be1fda467ea7aea02f40c22d03fdd206 commit r14-10828-gffce44e8be1fda467ea7aea02f40c22d03fdd206 Author: Richard Biener Date: Mon Oct 14 08:11:22 2024 +0200 middle-end/116891 - fix (negate (IFN_FNMS@3 @0 @1 @2)) -> (IFN_FMA @0 @1 @2) Transforming -fma (-a, b, -c) to fma (a, b, c) is only valid when not rounding towards -inf or +inf as the sign of the multiplication changes. PR middle-end/116891 * match.pd ((negate (IFN_FNMS@3 @0 @1 @2)) -> (IFN_FMA @0 @1 @2)): Only enable for !HONOR_SIGN_DEPENDENT_ROUNDING. (cherry picked from commit c53bd48c6920bc1f4039b6682aafbf414a600e47)
[Bug middle-end/116891] [12/13 Regression] invalid optimization of -fma(-x,x,-z) when -O3 and -frounding-math are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116891 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14 Regression] |[12/13 Regression] invalid |invalid optimization of |optimization of |-fma(-x,x,-z) when -O3 and |-fma(-x,x,-z) when -O3 and |-frounding-math are used|-frounding-math are used CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek --- Should be fixed for 14.3+ now too.
[Bug c++/117269] New: Lambda with capture is accepted as NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117269
Bug ID: 117269
Summary: Lambda with capture is accepted as NTTP
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ddvamp007 at gmail dot com
Target Milestone: ---
gcc compiles this code, clang rejects it
#include
#include
consteval auto Make(int x) {
return [x]{ return x; };
}
using Closure = decltype(Make(0));
template
struct S {};
S s0;
S s1;
int main() {
std::cout << std::is_same_v; // 0
}
Note: 'Closure' parameter can be replaced by simply auto
[Bug target/116759] [15 Regression] ~2.5% exec time slowdown of 538.imagick_r on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116759 Filip Kastl changed: What|Removed |Added Summary|[15 Regression] 5% exec |[15 Regression] ~2.5% exec |time slowdown of|time slowdown of |538.imagick_r on aarch64|538.imagick_r on aarch64 --- Comment #1 from Filip Kastl --- >From the graph it looks that the slowdown is only ~2.5% now. Maybe this makes the report uninteresting? I'm at least changing the title.
[Bug target/117270] New: [15 Regression] 9% exec time slowdown of 538.imagick_r on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270 Bug ID: 117270 Summary: [15 Regression] 9% exec time slowdown of 538.imagick_r on aarch64 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: missed-optimization, needs-bisection Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: aarch64-gnu-linux Target: aarch64-gnu-linux As seen here https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=585.507.0 there was a 9% exec time slowdown of the 538.imagick_r SPEC 2017 benchmark between commits r15-4033-g1f619fe25925a5 r15-4183-g517d344e416c76 when run with -Ofast -march=generic on an Ampere Altra Neoverse N1 machine. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug target/117270] [15 Regression] 9% exec time slowdown of 538.imagick_r on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270 Filip Kastl changed: What|Removed |Added Target Milestone|--- |15.0
[Bug fortran/117264] Segfault when using assignment for allocatable class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264 --- Comment #8 from Vladimir Terzi --- Created attachment 59414 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59414&action=edit Disassembled executable Since the error seems to be system-dependent, I disassembled the failing executable with `objdump -d -S`.
[Bug rtl-optimization/116488] [15 Regression] wrong code at -O{s,2,3} with "-fno-forward-propagate" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116488 --- Comment #9 from Andreas Schwab --- The test fails if char is unsigned.
[Bug target/80881] Implement Windows native TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881 --- Comment #69 from Julian Waters --- I apologize for vanishing suddenly and not giving progress reports, I am currently busy with some JDK work. The only thing left missing is the configure check. I will return to finishing TLS support once and for all when my JDK fixes have been completed
[Bug fortran/117258] tree check fail in gfc_trans_structure_assign, at fortran/trans-expr.cc:9691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117258 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin --- The command line uses -I/usr/lib64/gfortran/modules, so I guess there might be something of interest in /usr/lib64/gfortran/modules. Regarding the missing file, this one seems to be a good candidate: https://gitlab.com/libxc/libxc/-/blob/devel/src/libxc_master.F90?ref_type=heads
[Bug target/115860] [15 regression] Register pairs and regrename since r15-1579-g792f97b44ffc5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115860 Stefan Schulze Frielinghaus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Stefan Schulze Frielinghaus --- Fixed on master,14,13,12 -> closing
[Bug tree-optimization/116588] [14 Regression] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116588 --- Comment #9 from Jakub Jelinek --- Andrew, do you plan to backport this?
[Bug middle-end/117249] [12/13/14/15 Regression] --disable-checking is broken since r5-2450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249 --- Comment #11 from Jakub Jelinek --- Created attachment 59416 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59416&action=edit gcc15-pr117249-2.patch Untested patch to change the gcc_assert definition.
[Bug c/117267] 'setjmp' can never be copied because it receives a non-local goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #14 from Eric Botcazou --- > GCC has been erroring out since at least 4.5.0 (14 years ago). Changing how > __builtin_setjmp works is not going to happen because it is only designed > for sjlj exceptions for the Ada runtime. Remove "for the Ada runtime" here. It's also used for SJLJ in C++ on 32-bit Windows for example (unless DONT_USE_BUILTIN_SETJMP is defined). See the internal manual, 18.20.9 Assembler Commands for Exception Regions: -- Macro: DONT_USE_BUILTIN_SETJMP Define this macro to 1 if the 'setjmp'/'longjmp'-based scheme should use the 'setjmp'/'longjmp' functions from the C library instead of the '__builtin_setjmp'/'__builtin_longjmp' machinery.
[Bug c/117265] RFE: support for assembly macros/assembly headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265 --- Comment #6 from H. Peter Anvin --- No idea what you mean with #asmoptions. Using hacks in the Makefile is equivalent to having to do dependencies by hand (keep in mind that these statements will generally be part of header files.) In other words, it would mean the -M* options are useless as we would now need to create a completely separate mechanism to generate this information – at which point we might as well use it for C as well.
[Bug tree-optimization/117142] [13/14/15 Regression] ICE: verify_flow_info failed: error: returns_twice call is not first in basic block 2 at -O1 and above since r13-1754-g7a158a5776f5ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117142 --- Comment #4 from GCC Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:29d8f1f0b7ad3c69b3bdb130325300d5f73aa784 commit r15-4564-g29d8f1f0b7ad3c69b3bdb130325300d5f73aa784 Author: Martin Jambor Date: Wed Oct 23 11:30:32 2024 +0200 tree-sra: Avoid SRAing arguments to a function returning_twice (PR 117142) PR 117142 shows that the current SRA probably never worked reliably with arguments passed to a function returning twice, because it then creates statements before the call which however needs to be at the beginning of a basic block. While it should be possible to make at least the case of passing arguments by value work with SRA (the statements would need to be put just on the non-abnormal edges leading to the BB), this would mean large surgery of function sra_modify_expr and I guess the time would better be spent re-organizing the whole pass. gcc/ChangeLog: 2024-10-21 Martin Jambor PR tree-optimization/117142 * tree-sra.cc (build_access_from_call_arg): Disqualify any candidate passed to a function returning twice. gcc/testsuite/ChangeLog: 2024-10-21 Martin Jambor PR tree-optimization/117142 * gcc.dg/tree-ssa/pr117142.c: New test.
[Bug c/117267] 'setjmp' can never be copied because it receives a non-local goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267 --- Comment #17 from Stas Sergeev --- (In reply to Jonathan Wakely from comment #16) > A warning > would be OK. Sure! Add an UB warning and rephrase the initial error. Replace this error: 'setjmp' can never be copied because it receives a non-local goto with: --- Inlining of 'setjmp' is not implemented because it receives a non-local goto. Use macro instead. --- ... and all problems are solved.
[Bug sanitizer/117209] [13/14/15 Regression] ICE: verify_gimple failed with asan.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117209 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 59417 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59417&action=edit gcc15-pr117209.patch Untested fix. As before, calling the testcase valid is wrong, a const/pure function can't return twice.
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Bug 85316 depends on bug 114678, which changed state. Bug 114678 Summary: FAIL: gcc.dg/tree-ssa/range-sincos.c scan-tree-dump-not evrp "link_error" on s390 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114678 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/114678] FAIL: gcc.dg/tree-ssa/range-sincos.c scan-tree-dump-not evrp "link_error" on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114678 Stefan Schulze Frielinghaus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Stefan Schulze Frielinghaus --- Fixed.
[Bug middle-end/117271] New: [13/14/15 regression] GCC trunk emits larger code at -Os than 12.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117271
Bug ID: 117271
Summary: [13/14/15 regression] GCC trunk emits larger code at
-Os than 12.4.0
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dccitaliano at gmail dot com
Target Milestone: ---
Testcase (-Os):
int f(int* a) {
if (*a > 5 && ((*a % 2 == 0 && *a < 20) || (*a > 10 && *a % 3 != 0))) {
*a = *a * 2;
}
int arr[5];
for (int i = 0; i < 5; i++) {
arr[i] = *a + i;
}
for (int j = 0; j < 3; j++) {
for (int k = 0; k < 2 && arr[j] % 2 == 0; k++) {
arr[j] += k * 2;
}
}
int sum = 0;
for (int m = 0; m < 5 && (arr[m] % 3 == 0 || arr[m] > 10); m++) {
sum += arr[m] * (m % 2 == 0 ? 2 : 3);
for (int n = 0; n < 2 && (sum % 2 != 0 || m > 2); n++) {
sum -= n * (m % 2 == 0 ? 1 : 2);
if (n > 0 && sum > 10 && (arr[m] % 2 != 0 || m < 3)) {
sum += arr[m] / 2;
}
}
if (sum > 20 && m > 1) {
sum *= 2;
}
}
arr[0] += sum;
return arr[0];
}
Bisects to:
commit aadc5c07feb0ab08729ab25d0d896b55860ad9e6
Author: Andrew Pinski
Date: Mon Aug 7 00:05:21 2023 -0700
VR-VALUES [PR28794]: optimize compare assignments also
This patch fixes the oldish (2006) bug where VRP was not
optimizing the comparison for assignments while handling
them for GIMPLE_COND only.
It just happens to also solves PR 103281 due to allowing
to optimize `c < 1` to `c == 0` and then we get
`(c == 0) == c` (which was handled by r14-2501-g285c9d04).
OK? Bootstrapped and tested on x86_64-linux-gnu with no
regressions.
PR tree-optimization/103281
PR tree-optimization/28794
gcc/ChangeLog:
* vr-values.cc
(simplify_using_ranges::simplify_cond_using_ranges_1): Split out
majority to ...
(simplify_using_ranges::simplify_compare_using_ranges_1): Here.
(simplify_using_ranges::simplify_casted_cond): Rename to ...
(simplify_using_ranges::simplify_casted_compare): This
and change arguments to take op0 and op1.
(simplify_using_ranges::simplify_compare_assign_using_ranges_1):
New method.
(simplify_using_ranges::simplify): For tcc_comparison assignments
call
simplify_compare_assign_using_ranges_1.
* vr-values.h (simplify_using_ranges): Add
new methods, simplify_compare_using_ranges_1 and
simplify_compare_assign_using_ranges_1.
Rename simplify_casted_cond and simplify_casted_compare and
update argument types.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr103281-1.c: New test.
* gcc.dg/tree-ssa/vrp-compare-1.c: New test.
gcc/testsuite/gcc.dg/tree-ssa/pr103281-1.c| 19 +++
gcc/testsuite/gcc.dg/tree-ssa/vrp-compare-1.c | 13 +++
gcc/vr-values.cc | 160 --
gcc/vr-values.h | 4 +-
4 files changed, 134 insertions(+), 62 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr103281-1.c
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp-compare-1.c
[Bug middle-end/117271] [13/14/15 regression] GCC trunk emits larger code at -Os than 12.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117271 --- Comment #1 from Davide Italiano --- https://godbolt.org/z/eExfPsjzs
[Bug c++/70481] [Regression] Libiberty Demangler segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70481 --- Comment #7 from Jonathan Wakely --- For the record, this was fixed for 4.9.4, 5.4.0, 6.1.0 and later.
[Bug c++/70498] Libiberty Demangler segfaults (3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70498 --- Comment #9 from Jonathan Wakely --- This was fixed for 4.9.4, 5.4.0, 6.2.0 and later.
[Bug middle-end/117249] [12/13/14/15 Regression] --disable-checking is broken since r5-2450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #10 from Jakub Jelinek --- Created attachment 59415 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59415&action=edit gcc15-pr117249-1.patch Untested patch.
[Bug c/117267] 'setjmp' can never be copied because it receives a non-local goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267 --- Comment #15 from Stas Sergeev --- So in this case is this really good to disallow the always_inline attribute? - It just throws the meaningless error. Its meaningless because clang has no such problem, so stating "can never be copied" is plain wrong: it can and clang knows how. - The translation of that error is also wrong. It says: функция «setjmp» не может быть скопирована, поскольку имеют нелокальные переходы в эту функцию It should say: функция «setjmp» не может быть скопирована, поскольку имеютСЯ нелокальные переходы в эту функцию - It complicates the use. You need to use macro and compound statement extension. Also when gcc detects a return after setjmp(), it generates the intentionally bad code. Andrew argues that this is UB anyway, and that's certainly is. But why not to generate an error then, rather than when the properly valid attribute always_inline is used? But gcc choose to generate an error when there is no UB, and generate bad code when there is...
[Bug c/117267] 'setjmp' can never be copied because it receives a non-local goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267 --- Comment #16 from Jonathan Wakely --- If the program never executes the code with UB, then the program is correct, and refusing to compile it with an error would be non-conforming. A warning would be OK.
[Bug c/117145] [14/15 Regression] ICE: in make_ssa_name_fn, at tree-ssanames.cc:355 at -O1 and above with vector_size and VLA in struct argument since r14-1143-g42d1612eb5c3b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117145 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- This doesn't look correct to me. build_pointer_type_for_mode, build_function_type and build_array_type all use type hash tables to share types, so copying such flags into the shared types looks problematic (unless there is a guarantee that if one type has that flag, all types shared with those must have those flags too). If it is not the case, then I think we should build_variant_type_copy before setting such flags. If C_TYPE_VARIABLY_MODIFIED/C_TYPE_VARIABLE_SIZE flags are implied from other properties of the types (compared in the generic code in the canon type hash lookups), say the fact that ARRAY_TYPE domain isn't constant implies C_TYPE_VARIABLY_MODIFIED, then perhaps it would be better to assert somehow that if the type hasn't been newly created, it already has the desired flags, instead of always overwriting them.
[Bug target/117268] [14 Regression] GCC target("general-regs-only") leaves __AVX__ defined after a push_options/pop_options 'scope'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117268 --- Comment #1 from Andrew Pinski --- I think this is by design.
[Bug target/117268] [14 Regression] GCC target("general-regs-only") leaves __AVX__ defined after a push_options/pop_options 'scope'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117268 --- Comment #2 from Ville Voutilainen --- Possibly. It makes fair amounts of sense that predefined macros are reapplied after an options scope is exited. But it does break existing code. See https://bugreports.qt.io/browse/QTBUG-130381
[Bug target/117268] [14 Regression] GCC target("general-regs-only") leaves __AVX__ defined after a push_options/pop_options 'scope'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117268 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- See https://gcc.gnu.org/gcc-14/porting_to.html which documents this.
[Bug target/101017] ICE: Segmentation fault, convert_memory_address_addr_space_1 with vector_size(32) and target_clone arch=core-avx2/default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101017 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #10 from David Binderman --- Did this ever happen ? Similar test case gcc/testsuite/gcc.target/i386/avx10_1-26.c still seems to cause a crash: testsuite $ ~/gcc/results/bin/gcc -c -w ./gcc.target/i386/avx10_1-26.c ./gcc.target/i386/avx10_1-26.c: In function ‘foo’: ./gcc.target/i386/avx10_1-26.c:7:9: note: the ABI for passing parameters with 64-byte alignment has changed in GCC 4.6 7 | __m512d foo(__m512d a, __m512d b) | ^~~ during RTL pass: expand ./gcc.target/i386/avx10_1-26.c: In function ‘foo.avx10_1_512’: ./gcc.target/i386/avx10_1-26.c:10:1: internal compiler error: Segmentation fault 10 | } | ^ 0x231f2bd internal_error(char const*, ...) /home/dcb40b/gcc/working/gcc/../../trunk/gcc/diagnostic-global-context.cc:517 0xf247d9 crash_signal(int) /home/dcb40b/gcc/working/gcc/../../trunk/gcc/toplev.cc:321 0xa29c5e convert_memory_address_addr_space_1(scalar_int_mode, rtx_def*, unsigned char, bool, bool) /home/dcb40b/gcc/working/gcc/../../trunk/gcc/explow.cc:310
[Bug analyzer/117262] [15 regression] Analyzer doesn't handle RAW_DATA_CST properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117262 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0
[Bug target/101017] ICE: Segmentation fault, convert_memory_address_addr_space_1 with vector_size(32) and target_clone arch=core-avx2/default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101017 --- Comment #11 from Hongtao Liu --- (In reply to David Binderman from comment #10) > Did this ever happen ? > > Similar test case gcc/testsuite/gcc.target/i386/avx10_1-26.c > still seems to cause a crash: > > testsuite $ ~/gcc/results/bin/gcc -c -w ./gcc.target/i386/avx10_1-26.c > ./gcc.target/i386/avx10_1-26.c: In function ‘foo’: > ./gcc.target/i386/avx10_1-26.c:7:9: note: the ABI for passing parameters > with 64-byte alignment has changed in GCC 4.6 > 7 | __m512d foo(__m512d a, __m512d b) > | ^~~ Looks like the same error.
[Bug c/117265] RFE: support for assembly macros/assembly headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265 --- Comment #5 from Richard Biener --- So instead of having the #asminclude in the C file you can arrange for it in the Makefile by source specific rules? That said, at what point would you request a #asmoptions directive?
[Bug target/117268] [14 Regression] GCC target("general-regs-only") leaves __AVX__ defined after a push_options/pop_options 'scope'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117268
--- Comment #4 from Andrew Pinski ---
(In reply to Ville Voutilainen from comment #2)
> Possibly. It makes fair amounts of sense that predefined macros are
> reapplied after an options scope is exited. But it does break existing code.
> See https://bugreports.qt.io/browse/QTBUG-130381
The existing code was only added in 2022:
https://github.com/qt/qtquick3d/commit/7980cfd07eaaa8e12aecb3a6047805fefe048d80
undefining macros in the implemented defined area is undefined.
The better fix is to use `#pragma GCC target("no-sse3")` instead.
[Bug fortran/117258] tree check fail in gfc_trans_structure_assign, at fortran/trans-expr.cc:9691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117258 --- Comment #4 from David Binderman --- Even more mysterious: elk-9.2.12 $ find . -name \*.f90 -print | xargs grep xc_f03_lib_m ./src.orig/libxcifc.f90:use xc_f03_lib_m ./src/libxcifc.f90:use xc_f03_lib_m elk-9.2.12 $ I even tried: elk-9.2.12 $ find . -type f -print | xargs grep xc_f03_lib_m ./src.orig/libxcifc.f90:use xc_f03_lib_m ./src/libxcifc.f90:use xc_f03_lib_m elk-9.2.12 $ My working assumption is that the xc_f03_lib_m identifier is provided by some library the compiler accesses somehow. Would trying to duplicate a build of the entire package be easier ?
[Bug c/117030] [C2y] Implement N3367, More Modern Bit Utilities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117030
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
I think stdc_memreverse8 is implementable purely on the library side, perhaps
with an inline version optimizing the common cases using switch with
__builtin_bswap{16,32,64}.
stdc_memreverse8uN with those builtins (or just return value for 8).
Endian-aware loads/stores with __BYTE_ORDER__ dependent
__builtin_bswap{16,32,64} or not, perhaps on memcpy out of the memory into a
local.
stdc_rotate_left_ui etc. can be handled inline using what we pattern recognize
as rotations - (X << Y) | (X >> ((-Y) & (B - 1))) and the like.
For stdc_rotate_{left,right} I guess we want __builtin_stdc_rotate_{left,right}
for the same reason we've added the other __builtin_stdc_* builtins, so that it
can be done without statement expressions and doesn't evaluate arguments
multiple times and doesn't expand them multiple times and can handle arbitrary
unsigned _BitInt.
I'll add these two.
[Bug target/117240] ICE: in copy_to_mode_reg, at explow.cc:657 with __builtin_ia32_vaesenc_v32qi() or __builtin_ia32_vaesenc_v64qi()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117240 --- Comment #3 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:403e361d5aa620e77c9832578b2409a0fdd79d96 commit r15-4566-g403e361d5aa620e77c9832578b2409a0fdd79d96 Author: liuhongt Date: Tue Oct 22 01:54:40 2024 -0700 Fix ICE due to isa mismatch for the builtins. gcc/ChangeLog: PR target/117240 * config/i386/i386-builtin.def: Add avx/avx512f to vaes ymm/zmm builtins. gcc/testsuite/ChangeLog: * gcc.target/i386/pr117240_avx.c: New test. * gcc.target/i386/pr117240_avx512f.c: New test.
[Bug target/117240] ICE: in copy_to_mode_reg, at explow.cc:657 with __builtin_ia32_vaesenc_v32qi() or __builtin_ia32_vaesenc_v64qi()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117240 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:b718f6ec1674c0db30f26c65b7a9215e9388dd6c commit r14-10831-gb718f6ec1674c0db30f26c65b7a9215e9388dd6c Author: liuhongt Date: Tue Oct 22 01:54:40 2024 -0700 Fix ICE due to isa mismatch for the builtins. gcc/ChangeLog: PR target/117240 * config/i386/i386-builtin.def: Add avx/avx512f to vaes ymm/zmm builtins. gcc/testsuite/ChangeLog: * gcc.target/i386/pr117240_avx.c: New test. * gcc.target/i386/pr117240_avx512f.c: New test. (cherry picked from commit 403e361d5aa620e77c9832578b2409a0fdd79d96)
[Bug target/117240] ICE: in copy_to_mode_reg, at explow.cc:657 with __builtin_ia32_vaesenc_v32qi() or __builtin_ia32_vaesenc_v64qi()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117240 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:2452387468423882c0732e0fad3a83e887574ccc commit r13-9145-g2452387468423882c0732e0fad3a83e887574ccc Author: liuhongt Date: Tue Oct 22 01:54:40 2024 -0700 Fix ICE due to isa mismatch for the builtins. gcc/ChangeLog: PR target/117240 * config/i386/i386-builtin.def: Add avx/avx512f to vaes ymm/zmm builtins. gcc/testsuite/ChangeLog: * gcc.target/i386/pr117240_avx.c: New test. * gcc.target/i386/pr117240_avx512f.c: New test. (cherry picked from commit 403e361d5aa620e77c9832578b2409a0fdd79d96)
[Bug c++/117272] New: CWG2518 static_assert(false) when returning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117272
Bug ID: 117272
Summary: CWG2518 static_assert(false) when returning
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Richard1.Kellnberger at web dot de
Target Milestone: ---
Since gcc 13 this is valid code:
```C++
template void f(){
static_assert(false);
}
int main() {
}
```
This is as well:
```C++
#include
template void f(){
if constexpr(std::is_same_v) {
} else {
static_assert(false);
}
}
int main() {
f();
}
```
The `static_assert(false)` is ignored if it is not reached due to templating.
If I placed it into the `if` block instead the code would be ill-formed.
By the same logic the following should be valid, but it is not.
```C++
#include
template void f(){
if constexpr(std::is_same_v) {
return;
}
static_assert(false);
}
int main() {
f();
}
```
[Bug c/117145] [14/15 Regression] ICE: in make_ssa_name_fn, at tree-ssanames.cc:355 at -O1 and above with vector_size and VLA in struct argument since r14-1143-g42d1612eb5c3b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117145 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #9 from Martin Uecker --- These flags are often implied by some element / target type, so creating a copy of the type should not be necessary. For arrays there are some corner cases where one needs to be careful. I have a new patch that adds explicit checking code to make sure it is consistent. But this is an extra function, I could add checking also when reusing old types.
[Bug c++/117273] New: internal compiler error: Segmentation fault at extend_ref_init_temps(tree_node*, tree_node*, vec**, tree_node**)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117273
Bug ID: 117273
Summary: internal compiler error: Segmentation fault at
extend_ref_init_temps(tree_node*, tree_node*,
vec**, tree_node**)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yihan4845 at gmail dot com
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/dfdsq58Yd
The following program:
```
namespace std {
typedef __SIZE_TYPE__ size_t;
template struct initializer_list {
const T *p; size_t n;
const T *p, size_t n;
};
}
struct C { std::initializer_list a; };
C c = {};
```
will trigger segmentation fault for gcc trunk.
The stack dump:
```
0x286e9b5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2882d95 internal_error(char const*, ...)
???:0
0xac5a1a extend_ref_init_temps(tree_node*, tree_node*, vec**, tree_node**)
???:0
0xac5bb1 extend_ref_init_temps(tree_node*, tree_node*, vec**, tree_node**)
???:0
0xd7a0da store_init_value(tree_node*, tree_node*, vec**, int)
???:0
0xb7e50e cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int,
cp_decomp*)
???:0
0xc9a1da c_parse_file()
???:0
0xdf3b39 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/115274] [14/15 regression] Bogus -Wstringop-overread in SQLite source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274 --- Comment #13 from qinzhao at gcc dot gnu.org --- >when adding -fno-tree-sink, the warning disappeared. Before tree-sinking optimization, the IR is: (c.151t.pre) [local count: 1073741824]: c.0_1 = c; _2 = c.0_1 + 1; _5 = strlen (_2); _8 = (int) _5; f_6 = (long int) _8; if (c.0_1 == 0B) goto ; [17.43%] else goto ; [82.57%] [local count: 886588624]: goto ; [100.00%] [local count: 187153200]: a (f_6); [local count: 1073741824]: return; With the tree-sinking optimization, the IR becomes: (c.152t.sink1) [local count: 1073741824]: c.0_1 = c; if (c.0_1 == 0B) goto ; [17.43%] else goto ; [82.57%] [local count: 886588624]: goto ; [100.00%] [local count: 187153200]: _2 = c.0_1 + 1; _5 = strlen (_2); _8 = (int) _5; f_6 = (long int) _8; a (f_6); [local count: 1073741824]: return; >From the above, we can clearly see that, 4 statements including "_5 = strlen (_2)" are sinked from basic block 2 down to basic block 3. The basic block 3 is on the TRUE path of the condition "if (c.0_1 == 0B), therefore, compiler definitely reports the error in the user code, i.e., "strlen (_2)" tries to reference a NULL pointer. This is a real bug in the user's source code. Instead of a code duplication as jump threading optimization, tree-sinking applies a code movement from a joint-point of a CFG to a specific path. We might need to record such information.
[Bug middle-end/117249] [12/13/14/15 Regression] --disable-checking is broken since r5-2450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249 --- Comment #12 from Alexander Monakov --- On IRC Jakub mentioned gcc_assert (token() == TYPEDEF) in gengtype and Richi further noted tree-ssa-loop-ivopts.cc:gcc_assert (use->op_p = gimple_call_arg_ptr (call, 0)); cgraph.cc: gcc_assert (++edges_max_uid != 0); genautomata.cc: gcc_assert (j++ == DECL_INSN_RESERV (decl)->insn_num); config/ia64/ia64.cc:gcc_assert ((code = recog_memoized (insn)) == CODE_FOR_nop config/nvptx/nvptx.cc: gcc_assert (vec_pos = XVECLEN (pat, 0)); I tried injecting a warning for non-pure expressions inside of gcc_assert using the idea from PR 6906 (which spews tons of false positives), checking those I additionally see pair-fusion.cc:gcc_assert (rtl_ssa::restrict_movement (*changes[i], ignore)); df-scan.cc:gcc_assert (df_reg_chain_mark (DF_REG_DEF_CHAIN (i), i, true, false) opts-common.cc:gcc_assert (write (fd, &c, 1) == 1); opts-common.cc:gcc_assert (close (pipefd) == 0);
[Bug tree-optimization/116588] [14 Regression] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116588 --- Comment #10 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #9) > Andrew, do you plan to backport this? Wasn't planning to. Although the fast VRP pass exists in GCC 14, there is no way to call it or test it. There were also a lot of other changes made to the pass as well to make it work well that I don't intend to backport.
[Bug other/116613] RFE: support outputting diagnostics in *multiple* formats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613 Bug 116613 depends on bug 105916, which changed state. Bug 105916 Summary: gfortran -fdiagnostics-format=json/sarif* output contains buffered errors https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105916 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/105916] gfortran -fdiagnostics-format=json/sarif* output contains buffered errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105916 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from David Malcolm --- Should be fixed on trunk for GCC 15 by the above patch. I don't plan to backport this to the release branches (likely to be non-trivial as the code has changed a *lot*), so marking this as resolved.
[Bug jit/117275] New: test-functions.c.exe and test-tls.c.exe FAIL on ppc64le with an assertion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117275 Bug ID: 117275 Summary: test-functions.c.exe and test-tls.c.exe FAIL on ppc64le with an assertion failure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Seen on cfarm120: Within the jit testsuite, test-functions.c and test-tls.c are both failing this assertion on the 2nd compilation within a process: #2 0x763e67d0 in assemble_external_libcall (fun=0x72a4b1d8) at ../../src/gcc/varasm.cc:2650 2650 gcc_assert (!pending_assemble_externals_processed); (gdb) p pending_assemble_externals_processed $1 = true Presumably happens on any target which defines ASM_OUTPUT_EXTERNAL which uses an external libcall. Looks like we need to purge some state in varasm.cc in toplev::finalize; I'm working on a fix.
[Bug jit/117275] test-functions.c.exe and test-tls.c.exe FAIL on ppc64le with an assertion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117275 --- Comment #1 from David Malcolm --- The particular assertion was added in r14-5930-gf31a019d1161ec aka f31a019d1161ec78846473da743aedf49cca8c27, so the test failures presumably affect gcc 14 and trunk. There may be other dormant issues on older releases due to not resetting any of the state in varasm.cc.
[Bug c++/117273] internal compiler error: Segmentation fault at extend_ref_init_temps(tree_node*, tree_node*, vec**, tree_node**)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117273 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2024-10-23 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed. Even GCC 5 ICEs.
[Bug jit/117275] test-functions.c.exe and test-tls.c.exe FAIL on ppc64le with an assertion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117275 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Host||powerpc64le-unknown-linux-g ||nu Build||powerpc64le-unknown-linux-g ||nu Last reconfirmed||2024-10-23 Target||powerpc64le-unknown-linux-g ||nu
[Bug libstdc++/117276] std::sort(par_unseq ,...) leaks memory when called repeatedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276 --- Comment #1 from Oliver Schönrock --- Created attachment 59419 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59419&action=edit patch which solves the problem this patch applies cleanly to libstdc++ 13.2 and 14.2 and also to head I believe. It solves the problem. The code change is from here: https://github.com/oneapi-src/oneDPL/pull/1589/files By one of the people on the TBB / oneDPL team. it cannot be applied to TBB ( I did ask there) because the bug is in the "glue/interface" code between libstdc++ and TBB and managed by libstdc++
[Bug c/117190] [15 Regression] ICE on linux-6.11.3: in size_binop_loc, at fold-const.cc:2085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117190 --- Comment #15 from Sam James --- I meant identify a single file which takes longer, possibly by using -time=/tmp/kernel to record how long each file takes on a good+bad build, then diffing the two.
[Bug tree-optimization/117222] [15 regression] Missed optimization with with std::vector resize in loop since r15-575-gda73261ce7731b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117222 --- Comment #8 from Andrew Macleod --- pointer_diff depends on range_operator::fold_range to do the generic fold, which invokes wi_fold on subranges. It also in turn invokes op1_op2_relation_effect. This worked fine when pointers were implemented with irange, but when the transition to prange was made, a new version of fold_range is invoked by dispatch which uses prange operators. The default fold_range for prange does nothing, expecting the few operators which need it to implement their own fold_range. As a result all calls to fold_range for pointer_diff were returning false, which translates to VARYING. This PR demonstrates a dependency on knowing the relation between the operands is VREL_NE, in which case pointer_diff should return a non-zero result instead of varying. The upcoming patch implements the pointer_diff version of fold_range which then invokes the appropriate op1_op2_relation_effect () routine. This will in turn will cause the result to be non-zero as expected.
[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980 --- Comment #20 from Giuliano Belinassi --- Any updates on this?
[Bug c++/93607] Deprecated alias templates don't produce warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93607
Fedor Chelnokov changed:
What|Removed |Added
CC||fchelnokov at gmail dot com
--- Comment #2 from Fedor Chelnokov ---
The warning is missed in not-template case as well:
```
struct A{};
using B [[deprecated]] = A;
int main() {
B{}; //no GCC warning here
}
```
Here both Clang and MSVC show warnings, but not GCC. Online demo:
https://gcc.godbolt.org/z/9eeTqPPfz
[Bug target/113860] SVE popcount can be used for 16bit, 32bit and 64bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113860 --- Comment #4 from GCC Commits --- The master branch has been updated by Pengxuan Zheng : https://gcc.gnu.org/g:9ffcf1f193b477f417a4c1960cd32696a23b99b4 commit r15-4579-g9ffcf1f193b477f417a4c1960cd32696a23b99b4 Author: Pengxuan Zheng Date: Mon Oct 14 05:37:49 2024 -0700 aarch64: Improve scalar mode popcount expansion by using SVE [PR113860] This is similar to the recent improvements to the Advanced SIMD popcount expansion by using SVE. We can utilize SVE to generate more efficient code for scalar mode popcount too. Changes since v1: * v2: Add a new VNx1BI mode and a new test case for V1DI. * v3: Abandon VNx1BI changes and add a new variant of aarch64_ptrue_reg. PR target/113860 gcc/ChangeLog: * config/aarch64/aarch64-protos.h (aarch64_ptrue_reg): New function. * config/aarch64/aarch64-simd.md (popcount2): Update pattern to also support V1DI mode. * config/aarch64/aarch64.cc (aarch64_ptrue_reg): New function. * config/aarch64/aarch64.md (popcount2): Add TARGET_SVE support. * config/aarch64/iterators.md (VDQHSD_V1DI): New mode iterator. (SVE_VDQ_I): Add V1DI. (bitsize): Likewise. (VPRED): Likewise. (VEC_POP_MODE): New mode attribute. (vec_pop_mode): Likewise. gcc/testsuite/ChangeLog: * gcc.target/aarch64/popcnt-sve.c: Update test. * gcc.target/aarch64/popcnt11.c: New test. * gcc.target/aarch64/popcnt12.c: New test. Signed-off-by: Pengxuan Zheng
[Bug middle-end/117271] [13/14/15 regression] GCC trunk emits larger code at -Os than 12.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117271 --- Comment #2 from Andrew Pinski --- Global Exported: _40 = [irange] int [-2, 2] Global Exported: _71 = [irange] int [0, 1] MASK 0x1 VALUE 0x0 Global Exported: iftmp.0_53 = [irange] int [2, 3] MASK 0x1 VALUE 0x2 Global Exported: n_52 = [irange] int [0, 2] Simplified relational if (n_52 <= 1) into if (n_52 != 2) Global Exported: _70 = [irange] int [0, 1] MASK 0x1 VALUE 0x0 Global Exported: iftmp.2_54 = [irange] int [1, 2] MASK 0x3 VALUE 0x0 Global Exported: _25 = [irange] int [0, 2] Simplified relational _26 = n_52 > 0; into _26 = n_52 == 1; It is the second one which causes the issue. But that has so many things down the line.
[Bug c/117190] [15 Regression] ICE on linux-6.11.3: in size_binop_loc, at fold-const.cc:2085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117190 --- Comment #14 from Frank Scheiner --- (In reply to Sam James from comment #13) > I would file a new bug with preprocessed sources if you can identify a > testcase which is slower. Preprocessed sources for a whole kernel build?
[Bug libstdc++/117276] std::sort(par_unseq ,...) leaks memory when called repeatedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-10-23 Status|UNCONFIRMED |ASSIGNED
[Bug target/113860] SVE popcount can be used for 16bit, 32bit and 64bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113860 Pengxuan Zheng changed: What|Removed |Added CC||pzheng at gcc dot gnu.org Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Pengxuan Zheng --- Fixed.
[Bug testsuite/117274] New: New test case g++.dg/cpp2a/decomp10.C from r14-10826-g7de78f7353f125 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117274 Bug ID: 117274 Summary: New test case g++.dg/cpp2a/decomp10.C from r14-10826-g7de78f7353f125 fails Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:7de78f7353f125663a22f5514159ea966a120049, r14-10826-g7de78f7353f125 make -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/cpp2a/decomp10.C" FAIL: g++.dg/cpp2a/decomp10.C -std=gnu++14 (test for warnings, line 15) FAIL: g++.dg/cpp2a/decomp10.C -std=gnu++17 (test for warnings, line 15) Looks like it is looking for a message that is not generated. spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-14-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-14-test/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-14-test/gcc/testsuite/g++.dg/cpp2a/decomp10.C -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-14-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-14-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-14-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-14-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-14-test/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++14 -S -o decomp10.s /home/seurer/gcc/git/gcc-14-test/gcc/testsuite/g++.dg/cpp2a/decomp10.C: In member function 'void tuple::check_tuple_like()': /home/seurer/gcc/git/gcc-14-test/gcc/testsuite/g++.dg/cpp2a/decomp10.C:14:10: warning: structured bindings only available with '-std=c++17' or '-std=gnu++17' [-Wc++17-extensions] PASS: g++.dg/cpp2a/decomp10.C -std=gnu++14 (test for warnings, line 14) FAIL: g++.dg/cpp2a/decomp10.C -std=gnu++14 (test for warnings, line 15) commit 7de78f7353f125663a22f5514159ea966a120049 (HEAD) Author: Jason Merrill Date: Tue Oct 22 16:37:49 2024 -0400 c++: non-dep structured binding decltype again [PR117107] * g++.dg/cpp2a/decomp10.C: New test.
[Bug c/117190] [15 Regression] ICE on linux-6.11.3: in size_binop_loc, at fold-const.cc:2085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117190 --- Comment #13 from Sam James --- (In reply to Frank Scheiner from comment #11) I would file a new bug with preprocessed sources if you can identify a testcase which is slower.
[Bug fortran/116733] [F202y] Generic processing of assumed rank objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116733 --- Comment #6 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:c5fa2108ce0f3030cb28f47a18bc974c4224b66d commit r15-4573-gc5fa2108ce0f3030cb28f47a18bc974c4224b66d Author: Paul Thomas Date: Wed Oct 23 14:34:20 2024 +0100 Fortran: Generic processing of assumed rank objects (f202y) [PR116733] 2024-10-23 Paul Thomas gcc/fortran PR fortran/116733 * array.cc : White space corrections. * expr.cc (gfc_check_pointer_assign): Permit assumed rank target with -std=f202y. Add constraints that the data pointer object must have rank remapping specified and the that the data target be contiguous. * gfortran.h : Add a gfc_array_ref field 'ar' to the structure 'gfc_association_list'. * interface.cc (gfc_compare_actual_formal): If -Wsurprising is set, emit a warning if an assumed size array is passed to an assumed rank dummy. * intrinsic.cc (do_ts29113_check): Permit an assumed rank arg. for reshape if -std=f202y and the argument is contiguous. * invoke.texi : Introduce -std=f202y. Whitespace errors. * lang.opt : Accept -std=f202y. * libgfortran.h : Define GFC_STD_F202Y. * match.cc (gfc_match_associate): If -std=f202y an assumed rank selector is allowed if it is contiguous and the associate name has rank remapping specified. * options.cc (gfc_init_options): -std=f202y is equivalent to -std=f2023 with experimental f202y features. White space issues * parse.cc (parse_associate): If the selector is assumed rank, use the 'ar' field of the association list to build an array specification. * primary.cc (gfc_match_varspec): Do not resolve the assumed rank selector of a class associate name at this stage to avoid the rank change. * resolve.cc (find_array_spec): If an array_ref dimension is -1 reset it with the rank in the object's array_spec. (gfc_expression_rank): Do not check dimen types for an assumed rank variable expression. (resolve_variable): Do not emit the assumed rank context error if the context is pointer assignment and the variable is a target. (resolve_assoc_var): Resolve the bounds and check for missing bounds in the rank remap of an associate name with an assumed rank selector. Do not correct the rank of an associate name with an assumed rank selector. (resolve_symbol): Allow the reference to an assumed rank object if -std-f202y is enabled and the current operation is EXEC_BLOCK. * st.cc (gfc_free_association_list): Free bounds expressions of the 'ar' field, if present. * trans-array.cc (gfc_conv_ss_startstride): If -std=f202y and bounds checking activated, do not apply the assertion. * trans-expr.cc (gfc_trans_pointer_assignment): An assumed rank target has its offset set to zero. * trans-stmt.cc (trans_associate_var): If the selector is assumed rank, call gfc_trans_pointer_assignment using the 'ar' field in the association list as the array reference for expr1. The data target, expr2, is a copy of the selector expression. gcc/testsuite/ PR fortran/116733 * gfortran.dg/associate_3.f03: Change error message. * gfortran.dg/f202y/f202y.exp: Enable tests of f202y features. * gfortran.dg/f202y/generic_assumed_rank_1.f90: New test. * gfortran.dg/f202y/generic_assumed_rank_2.f90: New test. * gfortran.dg/f202y/generic_assumed_rank_3.f90: New test.
[Bug fortran/105916] gfortran -fdiagnostics-format=json/sarif* output contains buffered errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105916
--- Comment #3 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:f565063a0602ad3b48ac687f575dea7a90cd4105
commit r15-4575-gf565063a0602ad3b48ac687f575dea7a90cd4105
Author: David Malcolm
Date: Wed Oct 23 10:54:42 2024 -0400
diagnostics: implement buffering for non-textual formats [PR105916]
PR fortran/105916 reports stray diagnostics appearing in JSON and SARIF
output from gfortran.
In order to handle various awkard parsing issues, the Fortran frontend
implements buffering of diagnostics, so that diagnostics reported to
global_dc can be either:
(a) immediately issued, or
(b) speculatively reported to global_dc, and stored in a buffer, to
either be issued later or discarded.
This buffering code in gcc/fortran/error.cc directly manipulates
implementation details of the diagnostic_context such as the
pretty_printer's buffer, and the counts of how many diagnostics have
been issued. The issue is that this manipulation of pretty_printer's
buffer doesn't work for formats such as JSON and SARIF where diagnostics
are handled in a different way (such as by accumulating json::object
instances in an array).
This patch moves responsibility for such buffering of diagnostics from
fortran's error.cc to the diagnostic subsystem. It introduces a new
class diagnostic_buffer representing a particular buffer of diagnostics
that have been reported but not yet issued. Each diagnostic output
format implements buffering in a different way, and so there is a
new class hierarchy, diagnostic_per_format_buffer, representing the
various format-specific ways that buffering is to be implemented. This
is hidden as an implementation detail of diagnostic_buffer.
The patch also updates how diagnostics of each kind (e.g. warnings vs
errors) are counted, so that if buffering is enabled, the count is
incremented within the buffer, and the counts in the diagnostic_context
are only updated if and when the buffer is flushed; checking for
max_errors is similarly updated to support both buffered and unbuffered
cases.
For ease of debugging, the patch extends the "dump" functions within the
diagnostics subsystem, so that e.g. global_dc->dump () now prints the
buffering status, e.g.:
(gdb) call global_dc->dump()
diagnostic_context:
counts:
(none)
output format:
sarif_output_format
printer:
m_show_color: false
m_url_format: bel
m_buffer:
m_formatted_obstack current object: length 0:
m_chunk_obstack current object: length 0:
diagnostic buffer:
m_per_format_buffer:
counts:
error: 1
diagnostic_sarif_format_buffer:
result[0]:
{"ruleId": "error",
"level": "error",
"message": {"text": "Function âprogramâ requires an argument list at
(1)"},
"locations": [{"physicalLocation": {"artifactLocation": {"uri":
"../../src/gcc/testsuite/gfortran.dg/pr105954.f90",
"uriBaseId":
"PWD"},
"region": {"startLine": 6,
"startColumn": 8,
"endColumn": 9},
"contextRegion": {"startLine": 6,
"snippet": {"text": "program p\n"]}
which shows that no diagnostics have been issued yet, but the active
diagnostic_buffer has a single error buffered within it, in SARIF form.
Similarly, it's possible to use "dump" on a diagnostic_buffer to directly
query its contents; here's the same example, this time with the text
output format:
(gdb) call error_buffer.buffer.dump()
m_per_format_buffer:
counts:
error: 1
diagnostic_text_format_buffer:
m_formatted_obstack current object: length 232:
: 1b 5b 30 31 6d 1b 5b 4b 2e 2e 2f 2e 2e 2f 73 72 |
.[01m.[K../../sr
0010: 63 2f 67 63 63 2f 74 65 73 74 73 75 69 74 65 2f |
c/gcc/testsuite/
0020: 67 66 6f 72 74 72 61 6e 2e 64 67 2f 70 72 31 30 |
gfortran.dg/pr10
0030: 35 39 35 34 2e 66 39 30 3a 36 3a 38 3a 1b 5b 6d |
5954.f90:6:8:.[m
0040: 1b 5b 4b 0a 0a 20 20 20 20 36 20 7c 20 70 72 6f | .[K..
6 | pro
0050: 67 72 61 6d 20 70 0a 20 20 20 20 20 20 7c 20 20 | gram p.
|
0060: 20 20 20 20 20 20 1b 5b 30 31 3b 33 31 6d 1b 5b |
.[01;31m.[
0070: 4b 31 1b 5b 6d 1b 5b 4b 0a 1b 5b 30 31 3b 33 31 |
K1.[m.[K..[01;31
0080: 6d 1b 5b 4b 45 72 72 6f 72 3a 1b 5b 6d 1b 5b 4b |
m.[KError:.[m.[K
0090: 20 46 75 6e 63 74 69 6f 6e 20 e2 80 98 1b 5b 30 | Function
[0
00a0: 31 6d 1b 5b 4b 70 7
[Bug tree-optimization/117180] Confusing -Warray-bounds output for Tor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117180 --- Comment #3 from qinzhao at gcc dot gnu.org --- Looks like that my RFC patch currently has bugs that cannot locate the event accurately. need more study here to see how to locate the conditional event accurately. I need to reduce this test case a little bit for more study.
[Bug tree-optimization/117179] Confusing -Warray-bounds output for wget (wrong order of conditions in if statement)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117179 --- Comment #4 from qinzhao at gcc dot gnu.org --- Looks like that my RFC patch currently has bugs that cannot locate the event accurately. need more study here to see how to locate the conditional event accurately. I need to reduce this test case a little bit for more study.
[Bug c/117190] [15 Regression] ICE on linux-6.11.3: in size_binop_loc, at fold-const.cc:2085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117190 --- Comment #16 from Frank Scheiner --- (In reply to Sam James from comment #15) > I meant identify a single file which takes longer, possibly by using > -time=/tmp/kernel to record how long each file takes on a good+bad build, > then diffing the two. That could be an interesting exercise though it can't be much per file if the whole build reproduces a difference of around 3 seconds between different GCCs with short of 8 mins for the whole build. But I'm also unsure if the timings for single files will reproduce well enough between builds. Hm, maybe with fixed processor frequency. Still, I don't expect that new results would contradict the existing results.
[Bug c/117190] [15 Regression] ICE on linux-6.11.3: in size_binop_loc, at fold-const.cc:2085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117190 --- Comment #17 from Sam James --- It's not really actionable without some self-contained testcase like that, unless Jakub has some other idea.
[Bug target/114064] [meta-bug] Use SVE instructions more for Advanced. SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114064 Bug 114064 depends on bug 113860, which changed state. Bug 113860 Summary: SVE popcount can be used for 16bit, 32bit and 64bit https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113860 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/117190] [15 Regression] ICE on linux-6.11.3: in size_binop_loc, at fold-const.cc:2085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117190 --- Comment #18 from Frank Scheiner --- (In reply to Sam James from comment #17) > It's not really actionable without some self-contained testcase like that, > unless Jakub has some other idea. Oh, don't get me wrong, I don't urge anybody to do anything about that. My comment (#11) was simply meant as feedback as the commit message spoke of speed up.
[Bug jit/117275] test-functions.c.exe and test-tls.c.exe FAIL on ppc64le with an assertion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117275 --- Comment #2 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:779c0390e3b57d1eebd41bbfe43d1f329c91de6c commit r15-4580-g779c0390e3b57d1eebd41bbfe43d1f329c91de6c Author: David Malcolm Date: Wed Oct 23 14:26:38 2024 -0400 jit: reset state in varasm.cc [PR117275] PR jit/117275 reports various jit test failures seen on powerpc64le-unknown-linux-gnu due to hitting this assertion in varasm.cc on the 2nd compilation in a process: #2 0x763e67d0 in assemble_external_libcall (fun=0x72a4b1d8) at ../../src/gcc/varasm.cc:2650 2650 gcc_assert (!pending_assemble_externals_processed); (gdb) p pending_assemble_externals_processed $1 = true We're not properly resetting state in varasm.cc after a compile for libgccjit. Fixed thusly. gcc/ChangeLog: PR jit/117275 * toplev.cc (toplev::finalize): Call varasm_cc_finalize. * varasm.cc (varasm_cc_finalize): New. * varasm.h (varasm_cc_finalize): New decl. Signed-off-by: David Malcolm
[Bug libstdc++/117276] New: std::sort(par_unseq ,...) leaks memory when called repeatedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276 Bug ID: 117276 Summary: std::sort(par_unseq ,...) leaks memory when called repeatedly Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: oschonrock at gmail dot com Target Milestone: --- Created attachment 59418 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59418&action=edit code to reproduce problem Environment --- ubuntu 24.04 libstdc++ 13.2 from ubuntu repos but also 14.2 and judging by libstdc++ github mirror the latest head also has this problem sudo apt install libtbb-dev ## this is obviously required Problem --- when calling `std::sort(std::execution::par_unseq` repeatedly it leaks memory, and will ultimately deplete the machine and get killed by the kernel. the attached
[Bug target/117251] SHA3 code for PowerPC has a major slow down
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117251 --- Comment #12 from Segher Boessenkool --- (In reply to Richard Biener from comment #7) > Is it possible to define a fused and/xor+xor alternative that's split after > RA, slightly pessimized to prefer the altivec alternative, to allow the XXL > registers to be used? Possibly those could also be made only formed by > late_combine after reload? Yes, we should some way not have the fusing hinder the RA at all. Maybe it is good enough to just pretend VSX insns can be fused as well? That causes non- ideal scheduling for those VSX insns then, but that is all, it still is perfectly valid code!
[Bug libstdc++/117276] std::sort(par_unseq ,...) leaks memory when called repeatedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276 Oliver Schönrock changed: What|Removed |Added URL||https://github.com/oneapi-s ||rc/oneTBB/issues/1533 --- Comment #2 from Oliver Schönrock --- Sorry, premature submit on original report comment. continuing... The attached sort_leak.cpp (59418) shows the problem. Single threaded sort is fine, par_unseq is not. output: Single threaded sort: VM:14544 RSS:11648 (kB) VM:14616 RSS:11588 (kB) VM:14616 RSS:11588 (kB) VM:14616 RSS:11588 (kB) VM:14616 RSS:11588 (kB) par_unseq sort: VM:29372 RSS:17860 (kB) VM:33468 RSS:19652 (kB) VM:33468 RSS:21316 (kB) VM:37564 RSS:23108 (kB) VM:37564 RSS:24772 (kB) Related bug reports: Issue filed by me on oneTBB: https://github.com/oneapi-src/oneTBB/issues/1533 my repo with demo code, instructions and references should they be needed: https://github.com/oneapi-src/oneTBB/issues/1533 Pull request on oneDPL which fixes it https://github.com/oneapi-src/oneDPL/pull/1589/files (that is what my patch is based on) Solution As stated above, the attached patch (59419) fixes the issue
[Bug tree-optimization/117180] Confusing -Warray-bounds output for Tor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117180 --- Comment #5 from Sam James --- Created attachment 59423 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59423&action=edit reduced.i
[Bug c++/117272] CWG2518 static_assert(false) when returning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117272 --- Comment #1 from Andrew Pinski --- https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2593r1.html
[Bug c++/94404] [meta-bug] C++ core issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 Bug 94404 depends on bug 117272, which changed state. Bug 117272 Summary: CWG2518 static_assert(false) when returning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117272 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug c++/117272] CWG2518 static_assert(false) when returning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117272
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Andrew Pinski ---
So in the case of if/else, only one side of the if/else is used as it is both
sides are constrained due to the `if constexpr ` while in your second case the
if is constrained but the rest of the function is not.
That is it is similar to:
```
#include
template
constexpr bool always_false = false;
template void f(){
if constexpr(std::is_same_v) {
return;
}
static_assert(always_false);
}
int main() {
f();
}
```
Which will fail the same way too due to that.
[Bug tree-optimization/117260] [15 Regression] "phiopt: do factor_out_conditional_operation for all phis [PR112418]" vs. GCN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117260 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Andrew Pinski --- Fixed.
[Bug tree-optimization/117260] [15 Regression] "phiopt: do factor_out_conditional_operation for all phis [PR112418]" vs. GCN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117260 --- Comment #8 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:36e3e68250bf54909218298d1141138579803631 commit r15-4583-g36e3e68250bf54909218298d1141138579803631 Author: Andrew Pinski Date: Tue Oct 22 09:05:38 2024 -0700 match: Reject non-const internal functions [PR117260] When internal functions support was added to match (r6-4979-gc9e926ce2bdc8b), the check for ECF_CONST was the builtin function side. Though before r15-4503-g8d6d6d537fdc, there was no use of maybe_push_res_to_seq with non-const internal functions so the check would not make a difference. This adds the check for internal functions just as there is a check for builtins. Note I didn't add a testcase because there was no non-const internal function which could be used on x86_64 in a decent manor. Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: PR tree-optimization/117260 * gimple-match-exports.cc (maybe_push_res_to_seq): Reject non-const internal functions. Signed-off-by: Andrew Pinski
[Bug c++/117269] Lambda with capture is accepted as NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117269
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-10-23
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed. Reduced testcase:
```
constexpr auto Make(int x) {
return [x]{ return x; };
}
template struct S {};
S s;
```
[Bug tree-optimization/117179] Confusing -Warray-bounds output for wget (wrong order of conditions in if statement)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117179 --- Comment #7 from Sam James --- I think your patch here isn't really getting it wrong, it's just that the structure of the if() across multiple lines doesn't make it obvious?
[Bug tree-optimization/117180] Confusing -Warray-bounds output for Tor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117180 --- Comment #4 from Sam James --- Created attachment 59422 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59422&action=edit reduced.i First cut, will run it more.
[Bug tree-optimization/117222] [15 regression] Missed optimization with with std::vector resize in loop since r15-575-gda73261ce7731b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117222 --- Comment #9 from GCC Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:774ad67fba458dd1beaa0f2d3e389aac46ca18b5 commit r15-4578-g774ad67fba458dd1beaa0f2d3e389aac46ca18b5 Author: Andrew MacLeod Date: Mon Oct 21 16:32:00 2024 -0400 Implement operator_pointer_diff::fold_range prange has no default fold_range processing like irange does, so each pointer specific operator needs to implement its own fold routine. PR tree-optimization/117222 gcc/ * range-op-ptr.cc (operator_pointer_diff::fold_range): New. (operator_pointer_diff::op1_op2_relation_effect): Remove irange variant. (operator_pointer_diff::update_bitmask): Likewise. gcc/testsuite * g++.dg/pr117222.C: New.
[Bug tree-optimization/117179] Confusing -Warray-bounds output for wget (wrong order of conditions in if statement)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117179 Sam James changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-10-23 Ever confirmed|0 |1
[Bug jit/117275] test-functions.c.exe and test-tls.c.exe FAIL on ppc64le with an assertion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117275 --- Comment #3 from David Malcolm --- Should be fixed on trunk for gcc 15 by the above patch. Keeping open to track backporting to the active release branches.
[Bug tree-optimization/117222] [15 regression] Missed optimization with with std::vector resize in loop since r15-575-gda73261ce7731b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117222 Sam James changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot com Target Milestone|--- |15.0 Status|NEW |ASSIGNED
[Bug tree-optimization/117179] Confusing -Warray-bounds output for wget (wrong order of conditions in if statement)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117179 --- Comment #5 from Sam James --- Created attachment 59420 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59420&action=edit reduced.i Reduced it a bit, it could be cleaned up more but I think it should be good enough.
[Bug other/116613] RFE: support outputting diagnostics in *multiple* formats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613 --- Comment #26 from David Malcolm --- (In reply to David Malcolm from comment #18) > (In reply to Kamil Dudka from comment #16) > > (In reply to David Malcolm from comment #15) > > > (In reply to Kamil Dudka from comment #14) > > [...snip...] > > > > > > Does the above support all your use-cases? > > > > OSH does not care too much about the names of SARIF files because all the > > important data are contained in the files inside. The ideal SARIF-based > > workflow for OSH would be: > > 1. create an empty directory for scan results > > 2. run the (instrumented) build a of C/C++ project > > 3. each invocation of gcc (that produces warnings) during the build creates > > a unique file with SARIF data in the pre-created directory with scan results > > 4. all the files created in the pre-created directory with scan results can > > be processed after the build > > > > Step 3. can be partially implemented in the compiler wrapper with > > flock/mktemp, which can invoke gcc with an absolute path of an already > > created empty file to write the SARIF data to. If we take this approach, > > OSH will not need any such substitutions in gcc. If a substitution was > > provided by gcc to construct a unique file name (such as %p and %n in > > valgrind), OSH would not need to implement this part in the compiler > > wrapper. > > Given that it seems like you can create a tempfile name for the sarif and > pass that to gcc easily from a script, I decided it would be simpler not to > implement any of the "substitution" ideas in GCC, but to let you specify the > .sarif filename, potentially with an absolute or relative path. > > I have work-in-progress patches that implement this as a new > -fdiagnostics-add-output= > option, but they're not yet ready to push upstream (currently they break > some targets, plus the Fortran, and Modula 2 frontends). I still hope to > get them ready for GCC 15 feature freeze. > > If you want to try them out, I've created a Copr build of gcc trunk with the > patches: > https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-latest/ > where the build > gcc-latest-15.0.0-4.20241006git4782662796ac.pr116613.v0.128.fc42.src.rpm > has the new feature. I've briefly tested them on my laptop, and: FWIW the packaging sources for that build are now here: https://github.com/davidmalcolm/pkg-gcc-latest/tree/pr116613 I'm locally testing an updated version of the patch, which also adds -fdiagnostics-set-output=, as described in comment #20. If that testing succeeds, then I'll update the copr build.
[Bug tree-optimization/117179] Confusing -Warray-bounds output for wget (wrong order of conditions in if statement)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117179 Sam James changed: What|Removed |Added Attachment #59420|0 |1 is obsolete|| --- Comment #6 from Sam James --- Created attachment 59421 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59421&action=edit reduced.i
[Bug target/117240] ICE: in copy_to_mode_reg, at explow.cc:657 with __builtin_ia32_vaesenc_v32qi() or __builtin_ia32_vaesenc_v64qi()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117240 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:ab84a8a4b78990942e006e9f060dc2705f2c6d8f commit r12-10784-gab84a8a4b78990942e006e9f060dc2705f2c6d8f Author: liuhongt Date: Tue Oct 22 01:54:40 2024 -0700 Fix ICE due to isa mismatch for the builtins. gcc/ChangeLog: PR target/117240 * config/i386/i386-builtin.def: Add avx/avx512f to vaes ymm/zmm builtins. gcc/testsuite/ChangeLog: * gcc.target/i386/pr117240_avx.c: New test. * gcc.target/i386/pr117240_avx512f.c: New test. (cherry picked from commit 403e361d5aa620e77c9832578b2409a0fdd79d96)
