[Bug c++/114997] ICE with -std=c++20: unexpected expression ‘static_cast('\"')’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114997
--- Comment #3 from Andrew Pinski ---
Reduced testcase:
```
typedef int vv __attribute__((__vector_size__(sizeof(int;
constexpr vv ff(int code) { return vv{code}; }
template struct h {
typedef _Tp type;
};
template void f() {
using ut = h::type;
constexpr auto c = ff(static_cast('\\'));
}
```
[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #17 from GCC Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:d7ff8ae5313bea755f5960786b33a7b151e7b663 commit r15-336-gd7ff8ae5313bea755f5960786b33a7b151e7b663 Author: Aldy Hernandez Date: Fri May 3 11:17:32 2024 +0200 [ranger] Force buffer alignment in Value_Range [PR114912] gcc/ChangeLog: PR tree-optimization/114912 * value-range.h (class Value_Range): Use a union.
[Bug tree-optimization/114965] [13 Regression] wrong code generated for Emacs/Gnulib strftime (regression from 13.2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965
--- Comment #16 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:44d84db11ab724c34a8b1f8c0e06da1cc78439a2
commit r13-8735-g44d84db11ab724c34a8b1f8c0e06da1cc78439a2
Author: Jakub Jelinek
Date: Wed May 8 10:17:32 2024 +0200
reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]
The optimize_range_tests_to_bit_test optimization normally emits a range
test first:
if (entry_test_needed)
{
tem = build_range_check (loc, optype, unshare_expr (exp),
false, lowi, high);
if (tem == NULL_TREE || is_gimple_val (tem))
continue;
}
so during the bit test we already know that exp is in the [lowi, high]
range, but skips it if we have range info which tells us this isn't
necessary.
Also, normally it emits shifts by exp - lowi counter, but has an
optimization to use just exp counter if the mask isn't a more expensive
constant in that case and lowi is > 0 and high is smaller than prec.
The following testcase is miscompiled because the two abnormal cases
are triggered. The range of exp is [43, 43][48, 48][95, 95], so we on
64-bit arch decide we don't need the entry test, because 95 - 43 < 64.
And we also decide to use just exp as counter, because the range test
tests just for exp == 43 || exp == 48, so high is smaller than 64 too.
Because 95 is in the exp range, we can't do that, we'd either need to
do a range test first, i.e.
if (exp - 43U <= 48U - 43U) if ((1UL << exp) & mask1))
or need to subtract lowi from the shift counter, i.e.
if ((1UL << (exp - 43)) & mask2)
but can't do both unless r.upper_bound () is < prec.
The following patch ensures that.
2024-05-08 Jakub Jelinek
PR tree-optimization/114965
* tree-ssa-reassoc.cc (optimize_range_tests_to_bit_test): Don't try
to
optimize away exp - lowi subtraction from shift count unless entry
test is emitted or unless r.upper_bound () is smaller than prec.
* gcc.c-torture/execute/pr114965.c: New test.
(cherry picked from commit 9adec2d91e62a479474ae79df5b455fd4b8463ba)
[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 --- Comment #12 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cad27df08915ead8db3c7d512cfcc1866e7ece69 commit r13-8734-gcad27df08915ead8db3c7d512cfcc1866e7ece69 Author: Jakub Jelinek Date: Tue May 7 21:30:21 2024 +0200 expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907] The HF and BF modes have the same size/precision and neither is a subset nor superset of the other. So, using either __extendhfbf2 or __trunchfbf2 is weird. The expansion apparently emits __extendhfbf2, but on the libgcc side we apparently have __trunchfbf2 implemented. I think it is easier to switch to using what is available rather than adding new entrypoints to libgcc, even alias, because this is backportable. 2024-05-07 Jakub Jelinek PR middle-end/114907 * expr.cc (convert_mode_scalar): Use trunc_optab rather than sext_optab for HF->BF conversions. * optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise. * gcc.dg/pr114907.c: New test. (cherry picked from commit 28ee13db2e9d995bd3728c4ff3a3545e24b39cd2)
[Bug sanitizer/114956] [11/12/13 Regression] Segmentation fault with -fsanitize=address -fsanitize=null -O2 when attribute no_sanitize_address is enabled since r9-5742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114956 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d1ec7bc9cb0639a212422710ba647dc1aaea6eaa commit r13-8733-gd1ec7bc9cb0639a212422710ba647dc1aaea6eaa Author: Jakub Jelinek Date: Tue May 7 21:29:14 2024 +0200 tree-inline: Remove .ASAN_MARK calls when inlining functions into no_sanitize callers [PR114956] In r9-5742 we've started allowing to inline always_inline functions into functions which have disabled e.g. address sanitization even when the always_inline function is implicitly from command line options sanitized. This mostly works fine because most of the asan instrumentation is done only late after ipa, but as the following testcase the .ASAN_MARK ifn calls gimplifier adds can result in ICEs. Fixed by dropping those during inlining, similarly to how we drop .TSAN_FUNC_EXIT calls. 2024-05-07 Jakub Jelinek PR sanitizer/114956 * tree-inline.cc: Include asan.h. (copy_bb): Remove also .ASAN_MARK calls if id->dst_fn has asan/hwasan sanitization disabled. * gcc.dg/asan/pr114956.c: New test. (cherry picked from commit d4e25cf4f7c1f51a8824cc62bbb85a81a41b829a)
[Bug tree-optimization/114876] [11/12/13 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876
--- Comment #9 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:e07df053031e109c50387c92d689950de1d193ab
commit r13-8732-ge07df053031e109c50387c92d689950de1d193ab
Author: Jakub Jelinek
Date: Tue Apr 30 11:22:32 2024 +0200
gimple-ssa-sprintf: Use [0, 1] range for %lc with (wint_t) 0 argument
[PR114876]
Seems when Martin S. implemented this, he coded there strict reading
of the standard, which said that %lc with (wint_t) 0 argument is handled
as wchar_t[2] temp = { arg, 0 }; %ls with temp arg and so shouldn't print
any values. But, most of the libc implementations actually handled that
case like %c with '\0' argument, adding a single NUL character, the only
known exception is musl.
Recently, C23 changed this in response to GB-141 and POSIX in
https://austingroupbugs.net/view.php?id=1647
so that it should have the same behavior as %c with '\0'.
Because there is implementation divergence, the following patch uses
a range rather than hardcoding it to all 1s (i.e. the %c behavior),
though the likely case is still 1 (forward looking plus most of
implementations).
The res.knownrange = true; assignment removed is redundant due to
the same assignment done unconditionally before the if statement,
rest is formatting fixes.
I don't think the min >= 0 && min < 128 case is right either, I'd think
it should be min >= 0 && max < 128, otherwise it is just some possible
inputs are (maybe) ASCII and there can be others, but this code is a total
mess anyway, with the min, max, likely (somewhere in [min, max]?) and then
unlikely possibly larger than max, dunno, perhaps for at least some chars
in the ASCII range the likely case could be for the ascii case; so perhaps
just the one_2_one_ascii shouldn't set max to 1 and mayfail should be true
for max >= 128. Anyway, didn't feel I should touch that right now.
2024-04-30 Jakub Jelinek
PR tree-optimization/114876
* gimple-ssa-sprintf.cc (format_character): For min == 0 && max ==
0,
set max, likely and unlikely members to 1 rather than 0. Remove
useless res.knownrange = true;. Formatting fixes.
* gcc.dg/pr114876.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected
diagnostics.
(cherry picked from commit 6c6b70f07208ca14ba783933988c04c6fc2fff42)
[Bug c++/111284] [11/12/13 Regression] Some passing-by-value parameters are mishandled since GCC 9, affecting libstdc++'s constexpr std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284 --- Comment #12 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6f1b3f9c97e17aa717ae61bc70afa27adcb7ef44 commit r13-8731-g6f1b3f9c97e17aa717ae61bc70afa27adcb7ef44 Author: Jakub Jelinek Date: Thu Apr 25 20:45:04 2024 +0200 c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284] My r9-6136 changes to make a copy of constexpr function bodies before genericization modifies it broke the constant evaluation of non-POD arguments passed by value. In the callers such arguments are passed as reference to usually a TARGET_EXPR, but on the callee side until genericization they are just direct uses of a PARM_DECL with some class type. In cxx_bind_parameters_in_call I've used convert_from_reference to pretend it is passed by value and then cxx_eval_constant_expression is called there and evaluates that as an rvalue, followed by adjust_temp_type if the types don't match exactly (e.g. const Foo argument and passing to it reference to Foo TARGET_EXPR). The reason this doesn't work is that when the TARGET_EXPR in the caller is constant initialized, this for it is the address of the TARGET_EXPR_SLOT, but if the code later on pretends the PARM_DECL is just initialized to the rvalue of the constant evaluation of the TARGET_EXPR, it is as if there is a bitwise copy of the TARGET_EXPR to the callee, so this in the callee is then address of the PARM_DECL in the callee. The following patch attempts to fix that by constexpr evaluation of such arguments in the caller as an lvalue instead of rvalue, and on the callee side when seeing such a PARM_DECL, if we want an lvalue, lookup the value (lvalue) saved in ctx->globals (if any), and if wanting an rvalue, recursing with vc_prvalue on the looked up value (because it is there as an lvalue, nor rvalue). adjust_temp_type doesn't work for lvalues of non-scalarish types, for such types it relies on changing the type of a CONSTRUCTOR, but on the other side we know what we pass to the argument is addressable, so the patch on type mismatch takes address of the argument value, casts to reference to the desired type and dereferences it. 2024-04-25 Jakub Jelinek PR c++/111284 * constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with TREE_ADDRESSABLE types use vc_glvalue rather than vc_prvalue for cxx_eval_constant_expression and if it doesn't have the same type as it should, cast the reference type to reference to type before convert_from_reference and instead of adjust_temp_type take address of the arg, cast to reference to type and then convert_from_reference. (cxx_eval_constant_expression) : For lval case on parameters with TREE_ADDRESSABLE types lookup result in ctx->globals if possible. Otherwise if lookup in ctx->globals was successful for parameter with TREE_ADDRESSABLE type, recurse with vc_prvalue on the returned value. * g++.dg/cpp1z/constexpr-111284.C: New test. (cherry picked from commit f541757ba4632e204169dd08a5f10c782199af42)
[Bug fortran/114825] [11/12/13 Regression] Compiler error using gfortran and OpenMP since r5-1190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6d30cfc3fc88976151d0d10e73e10111ccb71ee0 commit r13-8730-g6d30cfc3fc88976151d0d10e73e10111ccb71ee0 Author: Jakub Jelinek Date: Thu Apr 25 20:09:35 2024 +0200 openmp: Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_? to tree-nested decl copy [PR114825] tree-nested.cc creates in 2 spots artificial VAR_DECLs, one of them is used both for debug info and OpenMP/OpenACC lowering purposes, the other solely for OpenMP/OpenACC lowering purposes. When the decls are used in OpenMP/OpenACC lowering, the OMP langhooks (mostly Fortran, C just a little and C++ doesn't have nested functions) then inspect the flags on the vars and based on that decide how to lower the corresponding clauses. Unfortunately we weren't copying DECL_LANG_SPECIFIC and DECL_LANG_FLAG_?, so the langhooks made decisions on the default flags on those instead. As the original decl isn't necessarily a VAR_DECL, could be e.g. PARM_DECL, using copy_node wouldn't work properly, so this patch just copies those flags in addition to other flags it was copying already. And I've removed code duplication by introducing a helper function which does copying common to both uses. 2024-04-25 Jakub Jelinek PR fortran/114825 * tree-nested.cc (get_debug_decl): New function. (get_nonlocal_debug_decl): Use it. (get_local_debug_decl): Likewise. * gfortran.dg/gomp/pr114825.f90: New test. (cherry picked from commit 14d48516e588ad2b35e2007b3970bdcb1b3f145c)
[Bug testsuite/115001] [14/15 Regression] pr109062.c fails on hybrid Intel CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115001 Xi Ruoyao changed: What|Removed |Added Summary|pr109062.c fails on hybrid |[14/15 Regression] |Intel CPU |pr109062.c fails on hybrid ||Intel CPU Target Milestone|--- |14.2
[Bug testsuite/115001] New: pr109062.c fails on hybrid Intel CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115001 Bug ID: 115001 Summary: pr109062.c fails on hybrid Intel CPU Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at gcc dot gnu.org Target Milestone: --- Since r14-4571 GOMP_SPINCOUNT defaults to 1 on hybrid Intel CPUs, but pr109062.c is not updated for the change.
[Bug c++/115000] Confusing 'cannot convert to 'int' in initialization' error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115000 --- Comment #3 from Andrew Pinski --- I suspect all of the see also bugs here are the same issue, I described my try of fixing that in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113#c8 .
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 --- Comment #10 from chenglulu --- (In reply to Xi Ruoyao from comment #9) > (In reply to chenglulu from comment #8) > > > diff --git a/gcc/config/loongarch/loongarch-def.cc > > b/gcc/config/loongarch/loongarch-def.cc > > index e8c129ce643..f27284cb20a 100644 > > --- a/gcc/config/loongarch/loongarch-def.cc > > +++ b/gcc/config/loongarch/loongarch-def.cc > > @@ -111,11 +111,7 @@ loongarch_rtx_cost_data::loongarch_rtx_cost_data () > > tune targets (i.e. -mtune=native while PRID does not correspond to > > any known "-mtune" type). */ > > array_tune loongarch_cpu_rtx_cost_data = > > - array_tune () > > -.set (CPU_LA664, > > - loongarch_rtx_cost_data () > > - .movcf2gr_ (COSTS_N_INSNS (1)) > > - .movgr2cf_ (COSTS_N_INSNS (1))); > > + array_tune (); > > But why? Isn't movcf2gr and movgr2cf one-cycle on LA664? I think this is weird too. I'm still testing other situations, and I'll find out the reason after the testing is completed.
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 --- Comment #9 from Xi Ruoyao --- (In reply to chenglulu from comment #8) > diff --git a/gcc/config/loongarch/loongarch-def.cc > b/gcc/config/loongarch/loongarch-def.cc > index e8c129ce643..f27284cb20a 100644 > --- a/gcc/config/loongarch/loongarch-def.cc > +++ b/gcc/config/loongarch/loongarch-def.cc > @@ -111,11 +111,7 @@ loongarch_rtx_cost_data::loongarch_rtx_cost_data () > tune targets (i.e. -mtune=native while PRID does not correspond to > any known "-mtune" type). */ > array_tune loongarch_cpu_rtx_cost_data = > - array_tune () > -.set (CPU_LA664, > - loongarch_rtx_cost_data () > - .movcf2gr_ (COSTS_N_INSNS (1)) > - .movgr2cf_ (COSTS_N_INSNS (1))); > + array_tune (); But why? Isn't movcf2gr and movgr2cf one-cycle on LA664?
[Bug c++/115000] Confusing 'cannot convert to 'int' in initialization' error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115000
--- Comment #2 from Andrew Pinski ---
Reduced:
```
template
concept bool c = false;
template
struct ts{};
struct S {};
S s;
ts t33{s};
```
[Bug c++/115000] Confusing 'cannot convert to 'int' in initialization' error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115000 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-05-09 Keywords||error-recovery Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. There is another issue like this. Basically the C++ front-end uses int as a valid type after an error.
[Bug c++/115000] New: Confusing 'cannot convert to 'int' in initialization' error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115000
Bug ID: 115000
Summary: Confusing 'cannot convert to 'int' in initialization'
error message
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Consider the following:
#include
struct S {
S() = default;
S(S&&) = default;
};
S s;
std::ranges::single_view r{s};
https://godbolt.org/z/65nvdaTfP
GCC reports constraints not satisfied which is correct, however, there is more:
:9:31: error: cannot convert 'S' to 'int' in initialization
9 | std::ranges::single_view r{s};
| ^
| |
| S
This is confusing since there is nothing to do with 'int'.
[Bug target/113652] [14/15 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 --- Comment #25 from Peter Bergner --- (In reply to Michael Meissner from comment #23) > 3) Only build the IEEE 128-bit libgcc bits if the user configured the > compiler with --with-cpu=power7, --with-cpu=power8, --with-cpu=power9, > --with-cpu=power10 (and in the future --with-cpu=power11 or > --with-cpu=future). This could be code that if __VSX__ is not defined, the > libgcc support functions won't get built. We would then remove the -mvsx > option from the library support functions. I think this is the solution we want, meaning if the target we're building supports VSX, then we'll build the IEEE128 bits, otherwise, we won't build them. I think that is the only sane answer. I also believe that if the user specifies a -mcpu= option (either implicitly or explicitly) that doesn't support VSX (eg, power4, or 7450, etc.) and they also explicitly use -mvsx, then we should emit an error message saying the -mcpu= option doesn't support using -mvsx at the same time. Ditto for -maltivec, -mmma, etc. We should not be silently enabling instruction support over and above their -mcpu= selection just because its needed for VSX/Altivec/MMA/etc. support. Currently we don't emit an error and instead silently enable generating instructions not supported by their -mcpu= option.
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 --- Comment #8 from chenglulu --- (In reply to Chen Chen from comment #0) > We tested Loongarch64 CPU Loongson 3A6000 with "LA664" architecture in Linux > operating system AOSC OS 11.4.0 (default gcc version is 13.2.0). And we > found the 548.exchange2_r benchmark from SPEC 2017 INTrate suite suffered > significant regressions from 14% to 28% with various compiling options. > > The rate-1 results are following: > /* snip */ > > after snapshot 20240317 score 18-23.1% lower with parameters "-g -Ofast > -march=la664": > 13.2.0:"-march=la664" flag is not supported > 20240317: 11.5 (227s) > 20240324: 8.84 (296s) > 20240430: 9.43 (278s) > 14.1.0:9.42 (278s) > /* snip */ > > > after snapshot 20240317 score 26.3-26.6% lower with parameters "-g -Ofast > -march=la464": > 13.2.0:8.76 (299s) > 20240317: 12.8 (205s) > 20240324: 9.39 (279s) > 20240430: 9.43 (278s) > 14.1.0:9.43 (278s) > > > 20240317: 11.5 (227s) -march=la664 > 20240317: 12.8 (205s) -march=la464 I looked for the reason for the gap between the above two results. The performance regression is caused by r14-6814. If the following modifications are made, the scores of -march=la664 and -march464 will be the same. diff --git a/gcc/config/loongarch/loongarch-def.cc b/gcc/config/loongarch/loongarch-def.cc index e8c129ce643..f27284cb20a 100644 --- a/gcc/config/loongarch/loongarch-def.cc +++ b/gcc/config/loongarch/loongarch-def.cc @@ -111,11 +111,7 @@ loongarch_rtx_cost_data::loongarch_rtx_cost_data () tune targets (i.e. -mtune=native while PRID does not correspond to any known "-mtune" type). */ array_tune loongarch_cpu_rtx_cost_data = - array_tune () -.set (CPU_LA664, - loongarch_rtx_cost_data () - .movcf2gr_ (COSTS_N_INSNS (1)) - .movgr2cf_ (COSTS_N_INSNS (1))); + array_tune ();
[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114999 --- Comment #5 from Andrew Pinski --- The following patterns could be improved/removed while doing this: ``` /* (A - B) == 0 ? (A - B) : (B - A)same as (B - A) */ /* (A - B) != 0 ? (A - B) : (B - A)same as (A - B) */ /* (A - B) >=/> 0 ? (A - B) : (B - A)same as abs (A - B) */ /* (A - B) <=/< 0 ? (A - B) : (B - A)same as -abs (A - B) */ ``` Need to look if we need to improve ctz_table_index match.
[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114999
Andrew Pinski changed:
What|Removed |Added
Blocks||113265
--- Comment #4 from Andrew Pinski ---
`X / -X is -1.` is PR 113265
```
int f(int a, int b, int x)
{
x = a - b;
int y = -x;
return (x >= y ? x : y);
}
```
MAX -> ABS
```
int f(int a, int b, int x)
{
x = a - b;
int y = -x;
return (x >= y ? y : x);
}
```
MIN -> -ABS
```
unsigned f(unsigned a, unsigned b, unsigned X, unsigned Y)
{
X = a - b;
unsigned t = -X;
return (X + 1) > Y ? t : 1;
}
```
// `(X + 1) > Y ? -X : 1` -> `X >= Y ? -X : 1` (unsigned)
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113265
[Bug 113265] [11/12/13/14/15 Regression] Missed optimization for redundancy
computation elimination may be due to constant propagation about 0 too late
[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114999
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Another one:
> ```
> int f(int a, int b, int x)
> {
> x = a - b;
> int y = -x;
> return (x >= 0 ? x : 0) + (x <= 0 ? y : 0);
> }
> ```
>
> This should be detected as `abs` (just like if the assignment to x is
> removed.
```
int f(int a, int b, int x)
{
x = a - b;
int y = -x;
return (x >= 0 ? x : 0) + (y >= 0 ? y : 0);
}
```
[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114999
Andrew Pinski changed:
What|Removed |Added
Summary|`a - b == b - a` -> `a == |A few missing optimizations
|b` |due to `a - b` and `b - a`
||not being detected as
||negatives of each other
--- Comment #2 from Andrew Pinski ---
Another one:
```
int f(int a, int b, int x)
{
x = a - b;
int y = -x;
return (x >= 0 ? x : 0) + (x <= 0 ? y : 0);
}
```
This should be detected as `abs` (just like if the assignment to x is
removed.
[Bug tree-optimization/114999] `a - b == b - a` -> `a == b`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114999 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-05-09 --- Comment #1 from Andrew Pinski --- I have an idea on how to fix this.
[Bug tree-optimization/114999] New: `a - b == b - a` -> `a == b`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114999
Bug ID: 114999
Summary: `a - b == b - a` -> `a == b`
Product: gcc
Version: 15.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(int a, int b, int c)
{
c = a - b;
int d = -c;
int t = c == d;
int t1 = c == 0;
return t == t1;
}
```
This is not able to optimize to 1 as we don't detect that `a - b` and `b - a`
are negative of each other.
```
(for cmp (eq ne)
(simplify
(cmp:c @0 (negate @0))
```
needs to be improved.
[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112659
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> This is the pattern I added for the plus case:
> ```
> (for cnd (cond vec_cond)
> ...
> /* (a != CST1) ? (a + CST2) : 0 -> (a + CST2) iff CST1 == -CST2 */
> (simplify
> (cnd (ne @0 uniform_integer_cst_p@1)
>(plus@3 @0 uniform_integer_cst_p@2)
>integer_zerop)
> (if (wi::to_wide (uniform_integer_cst_p (@1))
>== -wi::to_wide (uniform_integer_cst_p (@2)))
>@3))
> )
> ```
Thinking about this slightly more, we should be able to handle (which LLVM does
not currently handles):
```
int optb(int v, int b) {
// b = 8;
if (v != -b)
return v + b;
else
return 0;
}
```
too. Which means this is similar to PR 113265. So I should fix PR 113265 first
and then add the pattern for this case.
[Bug target/114988] RISC-V: ICE in intrinsic __riscv_vfwsub_wf_f32mf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114988 --- Comment #2 from JuzheZhong --- Li Pan is going to work on it. Hi, kito and Jeff. Can this fix backport to GCC-14 ?
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #7 from seurer at gcc dot gnu.org --- I tried that and with it trunk did finish building. I am running a test of that now.
[Bug c++/114994] [14/15 Regression] fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #5 from Patrick Palka ---
A bit more reduced, demostrating it's not specific to UDLs:
struct udl_arg {
udl_arg operator=(int);
};
void g(udl_arg&&);
template
void h() {
udl_arg x;
g(x=42);
}
int main() {
h();
}
[Bug c++/114992] [13/14/15 Regression] ICE during IPA pass: targetclone in add_to_same_comdat_group with calling a target clone with a lamdba in a comdat function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114992
Andrew Pinski changed:
What|Removed |Added
Summary|ICE during IPA pass:|[13/14/15 Regression] ICE
|targetclone in |during IPA pass:
|add_to_same_comdat_group, |targetclone in
|at symtab.cc:492|add_to_same_comdat_group
||with calling a target clone
||with a lamdba in a comdat
||function
Keywords||ice-on-valid-code
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Target Milestone|--- |13.3
Last reconfirmed||2024-05-08
--- Comment #1 from Andrew Pinski ---
Reduced testcase:
```
template void helper_func(Callable) {}
template
__attribute__((target_clones("avx2", "default")))
void handler(Callable) {}
struct cl {
inline int func();
};
inline int cl::func()
{
helper_func([](int) {});
handler([this]() {});
}
cl f;
int g = f.func();
```
[Bug c++/114997] ICE with -std=c++20: unexpected expression ‘static_cast('\"')’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114997 --- Comment #2 from Carlos Alberto Lopez Perez --- On WebKit we finally work-arounded the problem by replacing `constexpr` with `const` at commit https://github.com/WebKit/WebKit/commit/1ee00a2309c03ed119e8591022ba14f936440d71
[Bug tree-optimization/114995] C++23 Assume keyword not being used for vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- The above examples just show misunderstanding what __builtin_assume_aligned is and what it is not. You need to use the result of the built-in function in the accesses to be able to use the alignment information, if you just try to compare __builtin_assume_aligned (x, 32) == x, it will just fold as always true. The design of the builtin is to attach the alignment information to the result of the builtin function only. CCing Aldy/Andrew for whether prange can or could be taught to handle the assume cases with uintptr_t and bitwise and + comparison.
[Bug c++/114994] [14/15 Regression] fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994
Andrew Pinski changed:
What|Removed |Added
Summary|fmtlib named argument |[14/15 Regression] fmtlib
|compiler error introduced |named argument compiler
|in g++-14.1 |error introduced in
||g++-14.1
Target Milestone|--- |14.2
Ever confirmed|0 |1
Keywords|needs-reduction |rejects-valid
Last reconfirmed||2024-05-08
Status|UNCONFIRMED |NEW
--- Comment #4 from Andrew Pinski ---
Reduced testcase:
```
typedef decltype(sizeof(1)) size_t;
struct udl_arg {
const char *str;
template auto operator=(T &) const -> int {}
};
constexpr auto operator""_a(const char *s, size_t) -> udl_arg
{
return {""};
}
template void h(T &&);
template
int test(int a)
{
h("t"_a="t");
}
auto t = test<1>(1);
[Bug tree-optimization/114998] New: ICE on valid code at -O3 with "-fno-inline -fno-tree-dce -fno-ipa-cp" on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114998
Bug ID: 114998
Summary: ICE on valid code at -O3 with "-fno-inline
-fno-tree-dce -fno-ipa-cp" on x86_64-linux-gnu:
Segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It reproduces for 14.1 and trunk, but not 13.2 and earlier.
Compiler Explorer: https://godbolt.org/z/7xjf7EWGs
[865] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240507 (experimental) (GCC)
[866] %
[866] % gcctk -O3 -fno-inline -fno-tree-dce -fno-ipa-cp small.c
during GIMPLE pass: ldist
small.c: In function ‘main’:
small.c:4:5: internal compiler error: Segmentation fault
4 | int main() {
| ^~~~
0x1175773 crash_signal
../../gcc-trunk/gcc/toplev.cc:319
0x7f4aef65008f ???
/build/glibc-e2p3jK/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x140bb04 vec::quick_push(tree_node* const&)
../../gcc-trunk/gcc/vec.h:1043
0x140bb04 tree_node** vec_safe_push(vec*&, tree_node* const&)
../../gcc-trunk/gcc/vec.h:835
0x140bb04 release_ssa_name_fn(function*, tree_node*)
../../gcc-trunk/gcc/tree-ssanames.cc:619
0x1249bba release_ssa_name(tree_node*)
../../gcc-trunk/gcc/tree-ssanames.h:124
0x1249bba remove_phi_node(gimple_stmt_iterator*, bool)
../../gcc-trunk/gcc/tree-phinodes.cc:457
0x11bc34e gimple_merge_blocks
../../gcc-trunk/gcc/tree-cfg.cc:2175
0xbf0b63 merge_blocks(basic_block_def*, basic_block_def*)
../../gcc-trunk/gcc/cfghooks.cc:820
0x11cbc29 cleanup_tree_cfg_bb
../../gcc-trunk/gcc/tree-cfgcleanup.cc:791
0x11cd564 cleanup_tree_cfg_noloop
../../gcc-trunk/gcc/tree-cfgcleanup.cc:1122
0x11cd564 cleanup_tree_cfg(unsigned int)
../../gcc-trunk/gcc/tree-cfgcleanup.cc:1205
0x102c29c execute_function_todo
../../gcc-trunk/gcc/passes.cc:2058
0x102cb4e execute_todo
../../gcc-trunk/gcc/passes.cc:2143
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/114997] ICE with -std=c++20: unexpected expression ‘static_cast('\"')’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114997 --- Comment #1 from Carlos Alberto Lopez Perez --- The original cpp file that causes the issue can be found here: https://raw.githubusercontent.com/WebKit/WebKit/4855c7a1dc4214523c0b3d0c430215456ed7a0a9/Source/JavaScriptCore/runtime/JSONObject.cpp just for reference, the md5hash of the file is $ md5sum Source/JavaScriptCore/runtime/JSONObject.cpp a4799453f1b2b3c0e2bec60a095c962d Source/JavaScriptCore/runtime/JSONObject.cpp
[Bug c++/114997] New: ICE with -std=c++20: unexpected expression ‘static_cast('\"')’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114997
Bug ID: 114997
Summary: ICE with -std=c++20: unexpected expression
‘static_cast('\"')’ of kind
static_cast_expr
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: clopez at igalia dot com
Target Milestone: ---
Created attachment 58137
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58137=edit
preprocessed file from JSONObject.cpp to reproduce the problem
On the WebKit project recently this commit landed:
https://github.com/WebKit/WebKit/commit/4855c7a1dc4214523c0b3d0c430215456ed7a0a9
It caused GCC-12 to fail with an ICE.
./Source/JavaScriptCore/runtime/JSONObject.cpp: In lambda function:
./Source/JavaScriptCore/runtime/JSONObject.cpp:1124:89: internal compiler
error: unexpected expression ‘static_cast('\"')’ of kind
static_cast_expr
1124 | constexpr auto quoteMask =
WTF::splatBulk(static_cast('"'));
|
^
0x7ffb005ff1c9 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7ffb005ff284 __libc_start_main_impl
../csu/libc-start.c:360
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/114995] C++23 Assume keyword not being used for vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995
--- Comment #6 from Pratik Chowdhury ---
> [[assume((uintptr_t(x_array) & (32-1)) == 0)]];
The Parans in the & have definitely given someone sleepless nights LOL. I
myself was saved by the warnings.
> Right now we don't always prop back what information we get from the assume
> attributes.
Maybe with the recent prange addition, it can for pointers ...
Aah
Guess we will switch to assume in the future.
I tried [something else just about now](https://gcc.godbolt.org/z/d8aPjzMhq)
I think its a bit wrong. Clang seems to be able to handle it.
Is this syntax even valid?
```cpp
if(reinterpret_cast<::std::uintptr_t>(__builtin_assume_aligned((void*)(mul_array),
32)) != reinterpret_cast<::std::uintptr_t>(mul_array))
{
__builtin_unreachable();
}
if(reinterpret_cast<::std::uintptr_t>(__builtin_assume_aligned((void*)(add_array),
32)) != reinterpret_cast<::std::uintptr_t>(add_array))
{
__builtin_unreachable();
}
if(reinterpret_cast<::std::uintptr_t>(__builtin_assume_aligned((void*)(x_array),
32)) != reinterpret_cast<::std::uintptr_t>(x_array))
{
__builtin_unreachable();
}
```
I have my doubts on the previous one
But this should ideally be valid
```cpp
if((reinterpret_cast<::std::uintptr_t>(__builtin_assume_aligned((void*)(mul_array),
32)) & (32-1)) != 0)
{
__builtin_unreachable();
}
if((reinterpret_cast<::std::uintptr_t>(__builtin_assume_aligned((void*)(add_array),
32)) & (32-1)) != 0)
{
__builtin_unreachable();
}
if((reinterpret_cast<::std::uintptr_t>(__builtin_assume_aligned((void*)(x_array),
32)) & (32-1)) != 0)
{
__builtin_unreachable();
}
```
But either of them are unable to change the Load Stores from Unaligned to
Aligned.
Maybe victims of aggressive Dead Code elimination here? GCC intrinsics believe
that there can be no case its false and the code is deleted for the same?
Because __builtin_assume_aligned should always be a multiple of 32 in the above
cases.
Or __builtin_assume_aligned does not support usage like this in GCC and in
Clang it does? And due to that difference, we have a difference in behavior.
Its pretty interesting either way.
[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #16 from Aldy Hernandez --- (In reply to r...@cebitec.uni-bielefeld.de from comment #14) > > --- Comment #13 from Aldy Hernandez --- > > BTW, I'm waiting for a review, or at least a nod from a C++ savvy person > > here: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650634.html > > I can give the patch a whirl, thanks. I've attached a rebased patch against current mainline. Let me know if it works on your end, and I'll commit. > > I had Andrew's patch in my tree to avoid the issue. Unfortunately, > Solaris/SPARC bootstrap is broken again due to PR ipa/114985. I have provided a patch for that PR as well, but the IPA folk need to say if this is the correct approach.
[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #15 from Aldy Hernandez --- Created attachment 58136 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58136=edit proposed patch in testing
[Bug tree-optimization/114995] C++23 Assume keyword not being used for vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109045 --- Comment #5 from Andrew Pinski --- Right now we don't always prop back what information we get from the assume attributes. Maybe with the recent prange addition, it can for pointers ...
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #6 from Aldy Hernandez ---
I wonder if something like this would work.
diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index 5781f50..ea8a685 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -1730,6 +1730,8 @@ ipa_value_range_from_jfunc (vrange ,
}
else
{
+ if (TREE_CODE_CLASS (operation) == tcc_comparison)
+ vr_type = boolean_type_node;
Value_Range op_res (vr_type);
Value_Range res (vr_type);
tree op = ipa_get_jf_pass_through_operand (jfunc);
[Bug tree-optimization/114995] C++23 Assume keyword not being used for vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995 --- Comment #4 from Andrew Pinski --- Oh this is the more correct syntax: [[assume((uintptr_t(x_array) & (32-1)) == 0)]]; [[assume((uintptr_t(mul_array) & (32-1)) == 0)]]; [[assume((uintptr_t(add_array) & (32-1)) == 0)]];
[Bug rtl-optimization/114996] New: [15 Regression] [RISC-V] 2->2 combination no longer occurring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114996
Bug ID: 114996
Summary: [15 Regression] [RISC-V] 2->2 combination no longer
occurring
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
So this test has started failing on RISC-V after re-introduction of the change
to avoid 2->2 combinations when i2 is unchanged:
/* { dg-do compile } */
/* { dg-require-effective-target rv64 } */
/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" "-Os" "-Oz" } } */
/* { dg-options "-march=rv64gc_zba" } */
typedef unsigned int uint32_t;
typedef unsigned long uint64_t;
void foo(uint32_t a, uint64_t *b_ptr, uint64_t b, uint64_t *c_ptr, uint64_t c)
{
uint64_t x = a;
*b_ptr = b + x;
*c_ptr = c + x;
}
/* { dg-final { scan-assembler-not "\\szext.w\\s" } } */
[ That's heavily reduced and twiddled a bit from a hot loop in xz IIRC. ]
The key thing to note about the test is we have a zero extension of a 32 bit
value to 64 bits. The resulting 64 bit value is used in *two* subsequent
instructions.
As we start combine this looks like:
(insn 10 7 11 2 (set (reg/v:DI 136 [ x ])
(zero_extend:DI (subreg/s/u:SI (reg/v:DI 137 [ a ]) 0))) "j.c":11:12
458 {*zero_extendsidi2_bitmanip}
(expr_list:REG_DEAD (reg/v:DI 137 [ a ])
(nil)))
(insn 11 10 12 2 (set (reg:DI 142 [ _1 ])
(plus:DI (reg/v:DI 136 [ x ])
(reg/v:DI 139 [ b ]))) "j.c":12:14 5 {adddi3}
(expr_list:REG_DEAD (reg/v:DI 139 [ b ])
(nil)))
(insn 12 11 13 2 (set (mem:DI (reg/v/f:DI 138 [ b_ptr ]) [1 *b_ptr_7(D)+0 S8
A64])
(reg:DI 142 [ _1 ])) "j.c":12:10 268 {*movdi_64bit}
(expr_list:REG_DEAD (reg:DI 142 [ _1 ])
(expr_list:REG_DEAD (reg/v/f:DI 138 [ b_ptr ])
(nil
(insn 13 12 14 2 (set (reg:DI 143 [ _2 ])
(plus:DI (reg/v:DI 136 [ x ])
(reg/v:DI 141 [ c ]))) "j.c":13:14 5 {adddi3}
(expr_list:REG_DEAD (reg/v:DI 141 [ c ])
(expr_list:REG_DEAD (reg/v:DI 136 [ x ])
(nil
(insn 14 13 0 2 (set (mem:DI (reg/v/f:DI 140 [ c_ptr ]) [1 *c_ptr_10(D)+0 S8
A64])
(reg:DI 143 [ _2 ])) "j.c":13:10 268 {*movdi_64bit}
(expr_list:REG_DEAD (reg:DI 143 [ _2 ])
(expr_list:REG_DEAD (reg/v/f:DI 140 [ c_ptr ])
(nil
Without the problematical combine change we would first combine 10->11 as a
2->2 combination. Insn 10 would remain unchanged, but insn 11 would
incorporate the zero extension (RISC-V as an instruction for this).
After combining 10->11 (reg:DI 136) will have a single use enabling a 2->1
combination 10->13.
With the problematical combiner change the 10->11 combination fails because i2
hasn't changed and the 10->13 combination fails as well. The net result is we
have an unnecessary zero extension in that loop. Proper code for that testcase
is:
add.uw a2,a0,a2
sd a2,0(a1)
add.uw a0,a0,a4
sd a0,0(a3)
With that combiner change instead we're getting:
zext.w a0,a0
add a2,a0,a2
sd a2,0(a1)
add a0,a0,a4
sd a0,0(a3)
[Bug tree-optimization/114995] C++23 Assume keyword not being used for vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995 --- Comment #3 from Pratik Chowdhury --- Yeah definitely. My bad. Sorry. @Andrew Pinski [however even that change does not seem to change the results for GCC with Aligned Loads not being used](https://gcc.godbolt.org/z/9WbMbePc1) Added the more corrected 2 Power Trick function at the very end Any other mistake I could have made?
[Bug tree-optimization/114995] C++23 Assume keyword not being used for vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995 --- Comment #2 from Andrew Pinski --- I suspect the syntax you want instead is: [[assume(uintptr_t(x_array) & (32-1) == 0]]; Becuase __builtin_assume_aligned takes a pointer and returns a pointer that has the assumed alignment
[Bug tree-optimization/114995] C++23 Assume keyword not being used for vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995 --- Comment #1 from Andrew Pinski --- Created attachment 58135 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58135=edit testcase
[Bug c++/114994] fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994 --- Comment #3 from Andrew Pinski --- Trying my hand at reducing this slightly.
[Bug tree-optimization/114995] New: C++23 Assume keyword not being used for vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995
Bug ID: 114995
Summary: C++23 Assume keyword not being used for vectorization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pratikc at live dot co.uk
Target Milestone: ---
I would like to share a [simple example](https://gcc.godbolt.org/z/dbTsb3YMG)
In this, as can be seen in the _second function_
1. GCC is able to take advantage of builtin_unreachable (because removing it
would change the line count)
2. GCC is able to take advantage of __builtin_assume_aligned. (Aligned Loads
and Stores)
Both of these seem fair
However, in the _first function_:-
1. [Assume
Keyword](https://en.cppreference.com/w/cpp/language/attributes/assume) is used
2. Unaligned Load Store is generated by GCC
3. Modulo operation advantage is not taken by GCC.
Clang seems to be taking advantage of the same though.
It seems that thanks to the assume keyword there is scope for further
optimization gains.
The following syntax also seems to work in Clang
```cpp
[[assume(__builtin_assume_aligned(x_array, 32))]];
[[assume(__builtin_assume_aligned(mul_array, 32))]];
[[assume(__builtin_assume_aligned(add_array, 32))]];
```
Why I wanted to use the assume keyword?
1. There is scope for increased const correctness
2. Looks nicer
```cpp
/// @note This prototype works
void MulAddLoop(const float* const __restrict mul_array,
const float*const __restrict add_array, const ::std::size_t
size,
float* const __restrict x_array) {
```
PS:-
1. This is my first time filing a GCC Issue Report (I wouldn't really call this
a bug)
2. I hope I linked to the correct component as I am not as well versed as I
hope I could be with the internals of GCC.
[Bug c++/114994] fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994
--- Comment #2 from Andrew Pinski ---
Note lambdas is not need can happen in any template function:
```
#include
#define FMT_HEADER_ONLY
#include
using namespace fmt::literals;
template
auto test(int a)
{
return fmt::format("{foo} {bar}", "foo"_a="foo", "bar"_a="bar");
}
auto t = test<1>(1);
```
[Bug c++/114994] fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994 Marek Polacek changed: What|Removed |Added Keywords||needs-reduction CC||mpolacek at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Looks like it started with r14-4111: commit 6e92a6a2a72d3b7a5e1b29042d8a6a43fe1085aa Author: Patrick Palka Date: Mon Sep 18 14:47:52 2023 -0400 c++: non-dependent assignment checking [PR63198, PR18474]
[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 --- Comment #28 from Jakub Jelinek --- (In reply to Dmitrii Pasechnik from comment #26) > We have megabytes of code calling libraries where setjmp/longjmp is used, > in github.com/sagemath/sage/ (most of it in Cython). > > It looks like a huge hassle to put volatiles there. > Looks like we would need ways to disable particular optimisations which lead > to these sorts of errors:-( You mean turn off all optimizations then? -O0. Even that doesn't guarantee it will work if some such variables are declared with register keyword. It isn't just POSIX which says this, e.g. C99 also says: "All accessible objects have values, and all other components of the abstract machine have state, as of the time the longjmp function was called, except that the values of objects of automatic storage duration that are local to the function containing the invocation of the corresponding setjmp macro that do not have volatile-qualified type and have been changed between the setjmp invocation and longjmp call are indeterminate." C89 said pretty much the same.
[Bug c++/114994] New: fmtlib named argument compiler error introduced in g++-14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114994
Bug ID: 114994
Summary: fmtlib named argument compiler error introduced in
g++-14.1
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew.corrigan at gmail dot com
Target Milestone: ---
Demo: https://godbolt.org/z/oachhYKcT
First reported to https://github.com/fmtlib/fmt/issues/3953. The fmtlib author
believes the error below is a compiler bug. Using fmtlib's named arguments
inside a generic lambda stopped working as of g++-14.1. The reproducer below
compiles on every other compiler I've tried (earlier versions of g++, clang++,
intel, and msvc)
```
#include
#define FMT_HEADER_ONLY
#include
using namespace fmt::literals;
int main()
{
auto test = [&](auto a)
{
return fmt::format("{foo} {bar}", "foo"_a="foo", "bar"_a="bar");
};
std::cout << test(1) << std::endl;
return 0;
}
```
Error:
```
:12:50: error: cannot bind non-const lvalue reference of type
'fmt::v10::detail::named_arg&' to an rvalue of type
'fmt::v10::detail::named_arg'
12 | return fmt::format("{foo} {bar}", "foo"_a="foo",
"bar"_a="bar");
| ~~~^~
```
Changing `auto a` to `int a` works around the error.
Thank you!
[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=56512 Resolution|--- |INVALID --- Comment #27 from Andrew Pinski --- https://pubs.opengroup.org/onlinepubs/7908799/xsh/longjmp.html The requirement of using volatile has been there a long time before your code was written ...
[Bug fortran/86100] Spurious error with -fcheck=bounds and allocatable class(*) array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100 --- Comment #3 from anlauf at gcc dot gnu.org --- The code fragment in comment#2 was added in r7-3760-g92c5266bbd5378.
[Bug fortran/86100] Spurious error with -fcheck=bounds and allocatable class(*) array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
The problem seems to generally occur for class components of derived types.
program p
implicit none
type t
integer :: i = 0
end type t
type any_matrix
class(t), allocatable :: m(:,:)
end type any_matrix
type(any_matrix) :: a, b
allocate(a%m(3,4))
call foo ()
contains
subroutine foo ()
b = a ! Array bound mismatch for dimension 1 of array '<>'
(12/3)
!b%m = a%m ! no runtime error with -fcheck=bounds
end subroutine foo
end
This fails as indicated.
Note that 12=3*4 is the total size of the array, and 3 is the size of the
first dimension, which - along with the '<>' - points to
gfc_copy_class_to_class:
from_len = gfc_conv_descriptor_size (from_data, 1);
from_len = fold_convert (TREE_TYPE (orig_nelems), from_len);
tmp = fold_build2_loc (input_location, NE_EXPR,
logical_type_node, from_len, orig_nelems);
msg = xasprintf ("Array bound mismatch for dimension %d "
"of array '%s' (%%ld/%%ld)",
1, name);
gfc_trans_runtime_check (true, false, tmp, ,
_current_locus, msg,
fold_convert (long_integer_type_node,
orig_nelems),
fold_convert (long_integer_type_node,
from_len));
So we compare dimension 1 and the full size of the rhs?
Shouldn't we compare lhs and rhs shapes?
[Bug target/114993] ICE when using bpf-unknown-g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114993 Marc Poulhiès changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jemarch at gcc dot gnu.org --- Comment #2 from Marc Poulhiès --- After discussing on IRC, C++ (or anything != C) is not supported by BPF. The fix is probably to display an error when using anything else than the C FE. The Rust FE gives another error: https://c.godbolt.org/z/TeWa3cshd bpf-unknown-gcc: warning: : linker input file unused because linking not done Not sure why it does not even use crab1 in this case.
[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 --- Comment #26 from Dmitrii Pasechnik --- We have megabytes of code calling libraries where setjmp/longjmp is used, in github.com/sagemath/sage/ (most of it in Cython). It looks like a huge hassle to put volatiles there. Looks like we would need ways to disable particular optimisations which lead to these sorts of errors:-(
[Bug target/114993] ICE when using bpf-unknown-g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114993 --- Comment #1 from Marc Poulhiès --- After discussing on IRC, C++ (or anything != C) is not supported by BPF. The fix is probably to display an error when using anything else than the C FE. The Rust FE gives another error: https://c.godbolt.org/z/TeWa3cshd bpf-unknown-gcc: warning: : linker input file unused because linking not done Not sure why it does not even use crab1 in this case.
[Bug target/114993] New: ICE when using bpf-unknown-g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114993
Bug ID: 114993
Summary: ICE when using bpf-unknown-g++
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dkm at gcc dot gnu.org
Target Milestone: ---
bpf-unknown-none-g++ always ICE when using -g:
https://c.godbolt.org/z/EabsM3xjq
Using -g0 builds fine.
```
int square(int num) {
return num * num;
}
```
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/bpf/gcc-trunk/bpf-unknown-none/bin/bpf-unknown-none-g++
Target: bpf-unknown-none
Configured with: /opt/.build/bpf-unknown-none/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=bpf-unknown-none
--prefix=/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none
--exec_prefix=/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none
--with-local-prefix=/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/bpf-unknown-none
--with-headers=/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/bpf-unknown-none/include
--with-newlib --enable-threads=no --disable-shared
--with-pkgversion='crosstool-NG UNKNOWN' --disable-__cxa_atexit
--disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp
--disable-libquadmath --disable-libquadmath-support --disable-libstdcxx-verbose
--disable-libstdcxx --with-gmp=/opt/.build/bpf-unknown-none/buildtools
--with-mpfr=/opt/.build/bpf-unknown-none/buildtools
--with-mpc=/opt/.build/bpf-unknown-none/buildtools
--with-isl=/opt/.build/bpf-unknown-none/buildtools --enable-lto
--enable-target-optspace --disable-nls --disable-multilib
--enable-languages=c,c++
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240507 (experimental) (crosstool-NG UNKNOWN)
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s' '-S'
'-v' '-dumpdir' '/app/'
/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/libexec/gcc/bpf-unknown-none/15.0.0/cc1plus
-quiet -v -quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext
.cpp -g -version -fdiagnostics-color=always -o /app/output.s
GNU C++17 (crosstool-NG UNKNOWN) version 15.0.0 20240507 (experimental)
(bpf-unknown-none)
compiled by GNU C version 14.1.0, GMP version 6.2.1, MPFR version
4.2.1, MPC version 1.3.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/lib/gcc/bpf-unknown-none/15.0.0/../../../../bpf-unknown-none/include/c++/15.0.0"
ignoring nonexistent directory
"/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/lib/gcc/bpf-unknown-none/15.0.0/../../../../bpf-unknown-none/include/c++/15.0.0/bpf-unknown-none"
ignoring nonexistent directory
"/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/lib/gcc/bpf-unknown-none/15.0.0/../../../../bpf-unknown-none/include/c++/15.0.0/backward"
#include "..." search starts here:
#include <...> search starts here:
/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/lib/gcc/bpf-unknown-none/15.0.0/include
/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/lib/gcc/bpf-unknown-none/15.0.0/include-fixed
/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/lib/gcc/bpf-unknown-none/15.0.0/../../../../bpf-unknown-none/sys-include
/opt/compiler-explorer/bpf/gcc-trunk-20240508/bpf-unknown-none/lib/gcc/bpf-unknown-none/15.0.0/../../../../bpf-unknown-none/include
End of search list.
Compiler executable checksum: ed25500f957a8d770dd6c33cfdac0a0b
during RTL pass: final
: In function 'int square(int)':
:4:1: internal compiler error: Segmentation fault
4 | }
| ^
0x1e609e8 internal_error(char const*, ...)
???:0
0x16d7834 btf_ext_add_string
???:0
0x16d7b19 btf_add_func_info_for
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
[Bug c++/114990] Compiler errors in compiling a module-based app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990 --- Comment #2 from Larry Smith --- Thanks for the (very) fast turn-around (!). I'll look into the situation over the coming days and reply further (so if you can keep the issue alive for now, thanks). Just briefly though, can you (or anyone) confirm that the "include-after-import" issue you cited as the probable cause will be rectified eventually or is the situation permanent. Thanks again (appreciated).
[Bug analyzer/106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358 Bug 106358 depends on bug 112792, which changed state. Bug 112792 Summary: -Wanalyzer-out-of-bounds false positives seen on Linux kernel with certain unions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112792 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug analyzer/112792] -Wanalyzer-out-of-bounds false positives seen on Linux kernel with certain unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112792 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Summary|[13 Regression] |-Wanalyzer-out-of-bounds |-Wanalyzer-out-of-bounds|false positives seen on |false positives seen on |Linux kernel with certain |Linux kernel with certain |unions |unions | Status|ASSIGNED|RESOLVED --- Comment #5 from David Malcolm --- Unfortunately, backporting to GCC 13 is too involved (the code has greatly changed since). Closing this out instead.
[Bug c++/114990] Compiler errors in compiling a module-based app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Depends on||99000
--- Comment #1 from Patrick Palka ---
After preprocessing, it seems Main.cpp basically boils down to:
import CompilerVersions; // #1
#include// #2
import TypeTraits; // #3
int main()
{
return 0;
}
The issue here seems to be the #include appearing after the
import of CompilerVersions which (indirectly) also includes (in
its GMF). GCC currently supports import-after-include GMF merging (so #2
followed by #3 is OK) not but include-after-import. See also
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Modules.html
So one workaround would be to arrange that all #includes come before imports
which might include the same thing. Another workaround would be to compile the
problematic headers ( in this case) as a header unit so that
#includes thereof implicitly translated into imports, via e.g.
g++ -fmodules-ts -x c++-system-header type_traits
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99000
[Bug 99000] [modules] merging of textual redefinitions: declaration
std::__copy_move_a2 conflicts with import
[Bug ada/15614] Illegal program not detected, RM 12.1(11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15614 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #8 from Eric Botcazou --- Thanks!
[Bug middle-end/111009] [12/13 regression] -fno-strict-overflow erroneously elides null pointer checks and causes SIGSEGV on perf from linux-6.4.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009 --- Comment #14 from Andrew Macleod --- Created attachment 58134 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58134=edit adjusted patch (In reply to Richard Biener from comment #13) > Andrew - this doesn't pick to gcc-13 because of the following but we should > backport the fix somehow. Can you please see to that in time for GCC 13.3 > (next week)? > Sure. Its just missing the definition of contains_zero_p () from value-range.h that must have been added in an earlier patch. I'm running the following tweaked patch thru testing for GCC 13
[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #25 from Sergei Trofimovich ---
(In reply to Richard Biener from comment #24)
> (In reply to Sergei Trofimovich from comment #23)
> [...]
> > Why did `gcc` generate unconditional NULL dereference here? I suspect it
> > somehow inferred that `__pyx_t_6 = NULL;` in that branch, but not before
> > comparison.
>
> That's what happens if we isolate an unreachable path because of a NULL
> dereference (like if exposed by jump-threading). We make the NULL
> dereference volatile so it stays but DCE/DSE can cleanup code on the path
> leading to it.
>
> If you run into such path the this might suggest that jump-threading
> triggered
> a problem with the setjmp/longjmp, so it's then likely some condition that's
> evaluated in a wrong way after the longjmp, either because a dependent
> value wasn't properly preserved or by GCC breaking that. Seeing stack memory
> arguments used on a call in a previous comment
Yeah, that makes sense. Having stared a bit more at
__pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__() I
think I get the problem now. We deal with the code similar to the following:
__pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__() {
__pyx_t_6 = NULL;
// the loop is not very important, but it forces `__pyx_t_6` initialization
before `setjmp()`
for (;;) {
__pyx_t_6 = something();
int done = use_pre_setjmp(__pyx_t_6);
__pyx_t_6 = NULL;
if (done) break;
}
int mode = setjmp(jb);
switch (mode) {
case 1: // longjmp() case
break;
case 0: // regular case (`case 3:` in real code)
__pyx_t_6 = something_else(); // set __pyx_t_6 to non-zero
int done = use_post_setjmp(__pyx_t_6); // call longjmp(jb, 1) here
__pyx_t_6 = NULL;
break;
}
// get here via longjmp()
if (__pyx_t_6 != NULL) deref(__pyx_t_6);
}
AFAIU `gcc` is smart enough to see that all paths to `deref()` reach with
`__pyx_t_6 = NULL`, but it does not eliminate the `deref()` entirely
and uses `if (__pyx_t_6 != NULL) deref(NULL);` as Richard explained above.
Now due to `longjmp()` `__pyx_t_6 = NULL;` does not get executed (even
though it's present in assembly code as `movq $0, -200(%rbp)` in all the
places where it's present in C code.
As a result after the `longjmp()` `__pyx_t_6` is not `NULL` and we get
to `deref(NNULL)` and SIGSEGV.
Thus it's a matter of missing `volatile __pyx_t_6`. Sounds about right?
> I wondered if POSIX suggests
> that even non-register variables need to be made volatile and thus whether
> SRA or FRE might impose problems with code using setjmp/longjmp.
That matches my understanding as well. Would it be fair to say that sprinkling
`volatile` has to be done for every single local variable in the function to
prevent
possible stack reuse? And that rule should extend to the functions that could
host an inline variant of the function using setjmp()/longjmp() and not just
immediate caller of setjmp()/longjmp()?
[Bug c++/114992] New: ICE during IPA pass: targetclone in add_to_same_comdat_group, at symtab.cc:492
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114992
Bug ID: 114992
Summary: ICE during IPA pass: targetclone in
add_to_same_comdat_group, at symtab.cc:492
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wickmarkus86 at gmail dot com
Target Milestone: ---
Created attachment 58133
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58133=edit
outcome of -freport-bug
Since GCC 13.1, my minimal reproducible example triggers an ICE, reproducable
here: https://gcc.godbolt.org/z/vYK3TvE6j
Thanks a lot for looking at this issue!
--
template void helper_func(Callable) {}
template __attribute__((target_clones("avx2", "default")))
void handler(Callable outer_callback) {
outer_callback();
}
class InnerClass {
public:
template void inner_callback(Callable){};
void func() {
helper_func([&](int) {});
auto outer_callback = [this]() { inner_callback([]() {}); };
handler(outer_callback);
}
};
class OuterClass {
public:
void func();
InnerClass inner;
};
void OuterClass::func() { inner.func(); }
[Bug ada/87778] Remove -q quiet option from some GNAT bootstrap command lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87778 Nicolas Boulenguez changed: What|Removed |Added Attachment #44951|0 |1 is obsolete|| --- Comment #3 from Nicolas Boulenguez --- Created attachment 58132 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58132=edit test exit status and remove -q Ping? The part removing the parenthesis has been reinvented meanwhile. The part testing the exit status has been (partially) reinvented meanwhile. The patch needs a rebase because Make-generated.in has changed a lot meanwhile.
[Bug target/114991] [14/15 Regression] AArch64: LDP pass does not handle some structure copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114991 Wilco changed: What|Removed |Added Target||aarch64-*-* Target Milestone|--- |15.0
[Bug target/114991] New: [14/15 Regression] AArch64: LDP pass does not handle some structure copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114991
Bug ID: 114991
Summary: [14/15 Regression] AArch64: LDP pass does not handle
some structure copies
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The following example no longer emits LDP/STP since GCC14:
#include
typedef struct { int arr[20]; } S;
void g (S *);
void h (S);
void f(int x)
{
S s;
g ();
h (s);
}
f:
stp x29, x30, [sp, -176]!
add x1, sp, 96
mov x29, sp
add x0, sp, 16
ldp q29, q31, [x1]
ldr q30, [x1, 32]
str q29, [sp, 16]
ldr q29, [x1, 48]
str q31, [x0, 16]
ldr q31, [x1, 64]
stp q30, q29, [x0, 32]
str q31, [x0, 64]
bl h
ldp x29, x30, [sp], 176
ret
The expansions for memcpy/move/memset no longer emit LDP directly in RTL and
now rely on the new LDP pass. Stack based loads/stores seem to confuse its
alias checks and it gives up.
Using -fno-schedule-insns fixes this example, but not all cases.
[Bug tree-optimization/109804] [11 Regression] internal compiler error in gimple-ssa-warn-access.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804 Andrew Pinski changed: What|Removed |Added Summary|[11/12 Regression] internal |[11 Regression] internal |compiler error in |compiler error in |gimple-ssa-warn-access.cc |gimple-ssa-warn-access.cc Known to fail||13.2.0 Known to work||12.3.1 --- Comment #17 from Andrew Pinski --- Backported the fix to GCC 12 branch too. GCC 11 requires a different patch so leaving it open if someone wants it fixed there.
[Bug ada/15614] Illegal program not detected, RM 12.1(11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15614 --- Comment #7 from Nicolas Boulenguez --- Hello. First reported as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=244970. This seems fixed in gnat-14, snapshot from the 20240429 in Debian.
[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #13 from Aldy Hernandez --- > BTW, I'm waiting for a review, or at least a nod from a C++ savvy person here: > > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650634.html I can give the patch a whirl, thanks. I had Andrew's patch in my tree to avoid the issue. Unfortunately, Solaris/SPARC bootstrap is broken again due to PR ipa/114985.
[Bug tree-optimization/109804] [11/12 Regression] internal compiler error in gimple-ssa-warn-access.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804 --- Comment #16 from GCC Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:16319f8fba6c049d743046488588f40da2349048 commit r12-10432-g16319f8fba6c049d743046488588f40da2349048 Author: Andrew Pinski Date: Wed Feb 21 20:12:21 2024 -0800 warn-access: Fix handling of unnamed types [PR109804] This looks like an oversight of handling DEMANGLE_COMPONENT_UNNAMED_TYPE. DEMANGLE_COMPONENT_UNNAMED_TYPE only has the u.s_number.number set while the code expected newc.u.s_binary.left would be valid. So this treats DEMANGLE_COMPONENT_UNNAMED_TYPE like we treat function paramaters (DEMANGLE_COMPONENT_FUNCTION_PARAM) and template paramaters (DEMANGLE_COMPONENT_TEMPLATE_PARAM). Note the code in the demangler does this when it sets DEMANGLE_COMPONENT_UNNAMED_TYPE: ret->type = DEMANGLE_COMPONENT_UNNAMED_TYPE; ret->u.s_number.number = num; Committed as obvious after bootstrap/test on x86_64-linux-gnu PR tree-optimization/109804 gcc/ChangeLog: * gimple-ssa-warn-access.cc (new_delete_mismatch_p): Handle DEMANGLE_COMPONENT_UNNAMED_TYPE. gcc/testsuite/ChangeLog: * g++.dg/warn/Wmismatched-new-delete-8.C: New test. Signed-off-by: Andrew Pinski (cherry picked from commit 1076ffda6ce5e6d5fc9577deaf8233e549e5787a)
[Bug target/114942] [14/15 Regression] ICE on valid code at -O1 with "-fno-tree-sra -fno-guess-branch-probability": in extract_constrain_insn, at recog.cc:2713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942 --- Comment #5 from Vladimir Makarov --- I've started to work on this PR. I hope a patch will be ready on this or the next week.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0 Keywords||needs-reduction CC||pinskia at gcc dot gnu.org Component|bootstrap |ipa --- Comment #5 from Andrew Pinski --- (In reply to Aldy Hernandez from comment #4) > > If = OP_EQUAL is valid gimple, then we should > change operator_equal::fold_range() to accept all pointer operands. If not, > then we need to change the IPA pass. > > I would appreciate if an IL expert could opine here. `POINTER = POINTER CMP POINTER` should be invalid gimple as far as I can tell. The result of CMP should be a boolean type (except for vector compares where it is a vector boolean type). We have ran into these issues before with pointer types even. I might get some time later today to reduce the testcase too.
[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #13 from Aldy Hernandez --- BTW, I'm waiting for a review, or at least a nod from a C++ savvy person here: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650634.html
[Bug target/114981] [avr] Improve powi implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114981 --- Comment #2 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:de4eea7d7ea86e54843507c68d6672eca9d8c7bb commit r15-331-gde4eea7d7ea86e54843507c68d6672eca9d8c7bb Author: Georg-Johann Lay Date: Wed May 8 17:56:05 2024 +0200 AVR: target/114981 - Support __builtin_powi[l] / __powidf2. This supports __powidf2 by means of a double wrapper for already existing f7_powi (renamed to __f7_powi by f7-renames.h). It tweaks the implementation so that it does not perform trivial multiplications with 1.0 any more, but instead uses a move. It also fixes the last statement of f7_powi, which was wrong. Notice that f7_powi was unused until now. PR target/114981 libgcc/config/avr/libf7/ * libf7-common.mk (F7_ASM_PARTS): Add D_powi * libf7-asm.sx (F7MOD_D_powi_, __powidf2): New module and function. * libf7.c (f7_powi): Fix last (wrong) statement. Tweak trivial multiplications with 1.0. gcc/testsuite/ * gcc.target/avr/pr114981-powil.c: New test.
[Bug middle-end/114989] Compile time hog when building paml
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114989 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > So expand is usually fast. The only slow part I know of that might be > hitting here is division by constant where we are trying to find if it is > better to do multiplies or the division directly. Actually there is another slow part of expand I know of but since this is for x86_64, it will not hit it (ccmp with long chains can cause slow down due to trying to figure out which order is the best and it tries every possibility).
[Bug middle-end/114989] Compile time hog when building paml
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114989 --- Comment #3 from Sam James --- Created attachment 58131 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58131=edit codeml.i codeml.i from the same project is not great either but it's way less interesting, I think, because it's large. I'll attach it anyway for completeness.
[Bug c++/114990] New: Compiler errors in compiling a module-based app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990
Bug ID: 114990
Summary: Compiler errors in compiling a
module-based app
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at hexadigm dot com
Target Milestone: ---
Hi there,
This is a bit lengthy (code to reproduce reasonably short though) but intended
to provide sufficient detail. I'm getting numerous errors in the
(standard) header in V14.1 of GCC. It's a module-based app and the code below
is stripped down to the minimum required to demonstrate the issue (stripped
down so does nothing but should at least compile AFAIK - it doesn't). You can
run it in Compiler Explorer at https://godbolt.org/z/sh3c3TK8Y (same code
posted below but link itself relies on CMake - read on). See errors in top
executable window at latter link (targeting GCC 14.1) but compiles fine in
bottom executable window (targeting latest Clang). Also compiles in MSVC (not
shown at above link).
Note that if you simply comment out the #include statement seen
in "TypeTraits.h" OR the #include statement seen in
"CompilerVersions.h" the errors disappear.
Unfortunately I have little experience in GCC (I specialize on MSFT platforms)
and don't have my own machine set up to test the situation (in GCC) so I depend
on CMake in the Compiler Explorer environment (not too experienced with CMake
either for that matter but very experienced in C++ - modules still relatively
new to most though).
Note that the "CMakeLists.txt" file at the above link is a bit elaborate
(didn't strip that particular file down) but it handles Clang and MSVC without
issue, and should handle GCC as well (designed to assuming no errors). It does
in fact when I compile a header-based version of the app (not module-based)
which I can control via switches passed to CMake. Presumably (hopefully) it's
not a CMake issue in the module version (or perhaps some issue with Compiler
Explorer) but I don't have access to a pure GCC environment to test things
further. Someone at your end will have to (sorry) but at this point it looks
like a GCC issue.
Here's the code (5 very short files):
###
$ cat CompilerVersions.h
#ifndef COMPILER_VERSIONS
#define COMPILER_VERSIONS
// #defined in "CompilerVersions.cppm" so only when that file is building
(and no other time)
#if !defined(STDEXT_BUILDING_MODULE_COMPILERVERSIONS)
import CompilerVersions;
#define DECLARE_MACROS_ONLY
#endif
#if !defined(DECLARE_MACROS_ONLY)
#include
#endif
#endif
###
$ cat CompilerVersions.cppm
module;
#define STDEXT_BUILDING_MODULE_COMPILERVERSIONS
#include "CompilerVersions.h"
#undef STDEXT_BUILDING_MODULE_COMPILERVERSIONS
export module CompilerVersions;
###
$ cat TypeTraits.h
#ifndef TYPETRAITS
#define TYPETRAITS
#include "CompilerVersions.h"
// #defined in "TypeTraits.cppm" so only when that file is building (and no
other time)
#if !defined(STDEXT_BUILDING_MODULE_TYPETRAITS)
#include
import TypeTraits;
#endif
#endif
###
$ cat TypeTraits.cppm
module;
#define STDEXT_BUILDING_MODULE_TYPETRAITS
#include "TypeTraits.h"
#undef STDEXT_BUILDING_MODULE_TYPETRAITS
export module TypeTraits;
###
$ cat Main.cpp
#include "TypeTraits.h"
int main()
{
return 0;
}
I'm not sure what the command line is to compile the above code directly in GCC
(again, not a GCC developer - some should verify it) but presumably the
following or something similar (or all consolidated into one command if doable,
but would have to research it):
Compile the module interface units:
$ g++ -std=c++20 -fmodules-ts --module-interface -c CompilerVersions.cppm -o
CompilerVersions.o
$ g++ -std=c++20 -fmodules-ts --module-interface -c TypeTraits.cppm -o
TypeTraits.o
Compile the main program:
$ g++ -std=c++20 -fmodules-ts Main.cpp CompilerVersions.o TypeTraits.o -o Main
In Compiler Explorer itself (again, where I'm using CMake instead), many errors
result in but I'd expect the same or similar errors when running
the above GCC commands directly (TBD). Some of them are redefinition errors
which is suspicious given the nature of headers and modules in the same app. To
this end, and I have no idea if it actually has anything to do with the
problem, the "import CompilerVersions;" statement seen in "CompilerVersions.h"
does wind up in the global module fragment section of "TypeTraits.cppm" (where
headers normally go, not import statements), so I'm wondering if that has
something to do
[Bug c++/114986] Seemingly incorrect "ignoring packed attribute" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114986 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- The warning appeared with commit a37e8ce3b66325f0c6de55c80d50ac1664c3d0eb Author: Jason Merrill Date: Tue Dec 14 17:00:40 2021 -0500 c++: layout of aggregate base with DMI [PR103681]
[Bug middle-end/114989] Compile time hog when building paml
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114989 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Keywords||compile-time-hog --- Comment #1 from Andrew Pinski --- > callgraph functions expansion : 3.16 ( 86%) 0.32 ( 52%) 3.50 ( > 81%) 111M ( 75%) So expand is usually fast. The only slow part I know of that might be hitting here is division by constant where we are trying to find if it is better to do multiplies or the division directly.
[Bug c/114989] New: Compile time hog when building paml
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114989 Bug ID: 114989 Summary: Compile time hog when building paml Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Created attachment 58130 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58130=edit baseml.i Noticed this while working on something unrelated, just felt it looked a bit sluggish. The source file is a bit complex, but it's also _not_ huge generated gunk, which I think makes this a bit more interesting. I don't have older non-checking compilers around to see if it's a regression, sorry. ``` # time gcc-13 baseml.i -c -O2 real0m3.877s user0m3.755s sys 0m0.087s ``` ``` # gcc-13 baseml.i -c -O2 -ftime-report Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 1819k ( 1%) phase parsing : 0.09 ( 2%) 0.21 ( 34%) 0.31 ( 7%) 9507k ( 6%) phase opt and generate : 3.59 ( 98%) 0.40 ( 66%) 4.01 ( 93%) 138M ( 93%) dump files : 0.04 ( 1%) 0.01 ( 2%) 0.05 ( 1%) 0 ( 0%) callgraph construction : 0.00 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 3240k ( 2%) callgraph optimization : 0.00 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 2592 ( 0%) callgraph functions expansion : 3.16 ( 86%) 0.32 ( 52%) 3.50 ( 81%) 111M ( 75%) callgraph ipa passes : 0.39 ( 11%) 0.07 ( 11%) 0.46 ( 11%) 14M ( 10%) ipa function summary : 0.02 ( 1%) 0.00 ( 0%) 0.02 ( 0%) 1174k ( 1%) ipa inlining heuristics: 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 54k ( 0%) ipa pure const : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 72k ( 0%) ipa free inline summary: 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 ( 0%) cfg construction : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 580k ( 0%) cfg cleanup: 0.08 ( 2%) 0.00 ( 0%) 0.08 ( 2%) 703k ( 0%) trivially dead code: 0.02 ( 1%) 0.00 ( 0%) 0.02 ( 0%) 0 ( 0%) df reaching defs : 0.03 ( 1%) 0.02 ( 3%) 0.03 ( 1%) 0 ( 0%) df live regs : 0.13 ( 4%) 0.01 ( 2%) 0.14 ( 3%) 0 ( 0%) df live regs : 0.02 ( 1%) 0.01 ( 2%) 0.06 ( 1%) 0 ( 0%) df use-def / def-use chains: 0.04 ( 1%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) df reg dead/unused notes : 0.08 ( 2%) 0.00 ( 0%) 0.05 ( 1%) 1648k ( 1%) register information : 0.03 ( 1%) 0.00 ( 0%) 0.00 ( 0%) 0 ( 0%) alias analysis : 0.02 ( 1%) 0.01 ( 2%) 0.05 ( 1%) 4296k ( 3%) alias stmt walking : 0.10 ( 3%) 0.00 ( 0%) 0.15 ( 3%) 658k ( 0%) register scan : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 24k ( 0%) rebuild jump labels: 0.02 ( 1%) 0.00 ( 0%) 0.00 ( 0%) 0 ( 0%) preprocessing : 0.02 ( 1%) 0.06 ( 10%) 0.11 ( 3%) 331k ( 0%) lexical analysis : 0.03 ( 1%) 0.08 ( 13%) 0.13 ( 3%) 0 ( 0%) parser (global): 0.01 ( 0%) 0.01 ( 2%) 0.03 ( 1%) 2449k ( 2%) parser function body : 0.03 ( 1%) 0.06 ( 10%) 0.04 ( 1%) 6620k ( 4%) early inlining heuristics : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 41k ( 0%) inline parameters : 0.02 ( 1%) 0.00 ( 0%) 0.01 ( 0%) 328k ( 0%) tree gimplify : 0.02 ( 1%) 0.00 ( 0%) 0.02 ( 0%) 7063k ( 5%) tree eh: 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 29k ( 0%) tree CFG construction : 0.01 ( 0%) 0.01 ( 2%) 0.02 ( 0%) 2159k ( 1%) tree CFG cleanup : 0.03 ( 1%) 0.00 ( 0%) 0.04 ( 1%) 97k ( 0%) tree tail merge: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 980k ( 1%) tree VRP : 0.15 ( 4%) 0.00 ( 0%) 0.17 ( 4%) 4202k ( 3%) tree Early VRP : 0.09 ( 2%) 0.01 ( 2%) 0.11 ( 3%) 1768k ( 1%) tree copy propagation : 0.03 ( 1%) 0.00 ( 0%) 0.01 ( 0%) 108k ( 0%) tree PTA : 0.13 ( 4%) 0.01 ( 2%) 0.04 ( 1%) 665k ( 0%) tree SSA rewrite : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 2202k ( 1%) tree SSA incremental : 0.02 ( 1%) 0.01 ( 2%) 0.00 ( 0%) 745k ( 0%) tree operand scan
[Bug rtl-optimization/114810] [14 Regression] internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -m32 -msta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810 --- Comment #17 from GCC Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:2f00e6caca1a14dfe26e94f608e9d79a787ebe08 commit r15-330-g2f00e6caca1a14dfe26e94f608e9d79a787ebe08 Author: Vladimir N. Makarov Date: Wed May 8 10:39:04 2024 -0400 [PR114810][LRA]: Recognize alternatives with lack of available registers for insn and demote them. PR114810 was fixed in machine-dependent way. This patch is a fix of the PR on LRA side. LRA chose alternative with constraints `,r,ro` on i686 when all operands of DImode and there are only 6 available general regs. The patch recognizes such case and significantly increase the alternative cost. It does not reject alternative completely. So the fix is safe but it might not work for all potentially possible cases of registers lack as register classes can have any relations including subsets and intersections. gcc/ChangeLog: PR target/114810 * lra-constraints.cc (process_alt_operands): Calculate union reg class for the alternative, peak matched regs and required reload regs. Recognize alternatives with lack of available registers and make them costly. Add debug print about this case.
[Bug bootstrap/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2024-05-08
Status|UNCONFIRMED |NEW
CC||amacleod at redhat dot com,
||hubicka at gcc dot gnu.org,
||jamborm at gcc dot gnu.org
--- Comment #4 from Aldy Hernandez ---
Confirmed.
Here is some background on tracking discriminator failures.
The sanity check in the range_op dispatch code has noticed that it has an
unsupported pointer range combination. This is the sanity check:
bool
range_op_handler::fold_range (vrange , tree type,
const vrange ,
const vrange ,
relation_trio rel) const
...
...
if (has_pointer_operand_p (r, lh, rh)
&& !m_operator->pointers_handled_p (DISPATCH_FOLD_RANGE,
dispatch_kind (r, lh, rh)))
discriminator_fail (r, lh, rh);
The above code fails if the operator cannot handle the pointer combo it was
passed, and the operator at hand is op_equal:
(gdb) p *this
$11 = {m_operator = 0x1463a590 }
What's being attempted is a = == as per the
somewhat cryptic error:
DISCRIMINATOR FAIL. Dispatch > RO_PPP <
This is because for operator_equal::fold_range(), we only handle INTEGER =
POINTER OP_EQUAL POINTER. That is, the result must be an integer:
bool
operator_equal::pointers_handled_p (range_op_dispatch_type type,
unsigned dispatch) const
{
switch (type)
{
case DISPATCH_FOLD_RANGE:
return dispatch == RO_IPP;
...
...
}
This all comes from ipa_value_range_from_jfunc() which is trying to calculate
the equality of two pointer ranges and store the result in a pointer. I
believe this is incorrect, as the result of equality should be a
boolean_type_node, or at least an integer.
This is where IPA is trying to call fold_range with the invalid combo:
Value_Range op_res (vr_type);
Value_Range res (vr_type);
tree op = ipa_get_jf_pass_through_operand (jfunc);
Value_Range op_vr (TREE_TYPE (op));
range_op_handler handler (operation);
ipa_range_set_and_normalize (op_vr, op);
if (!handler
|| !op_res.supports_type_p (vr_type)
=>|| !handler.fold_range (op_res, vr_type, srcvr, op_vr))
op_res.set_varying (vr_type);
It is trying to call fold_range() with EQ_EXPR for two pointer operands, but
storing the result in a pointer:
(gdb) p operation
$18 = EQ_EXPR
(gdb) p debug(srcvr)
[prange] union tree_node * * [0, +INF] MASK 0xfff8 VALUE 0x0
$14 = void
(gdb) p debug(op_vr)
[prange] union tree_node * * [0, 0] MASK 0x0 VALUE 0x0
$15 = void
IMO op_res should have an integer type, but it is a pointer:
(gdb) p debug_generic_stmt(vr_type)
union tree_node * *
...causing op_res to be a pointer:
(gdb) p debug(op_res)
[prange] UNDEFINED
If = OP_EQUAL is valid gimple, then we should
change operator_equal::fold_range() to accept all pointer operands. If not,
then we need to change the IPA pass.
I would appreciate if an IL expert could opine here.
[Bug bootstrap/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #3 from seurer at gcc dot gnu.org --- Created attachment 58129 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58129=edit pre-processed failing file
[Bug tree-optimization/111331] [11/12 Regression] Wrong code at -O1 on x86_64-linux-gnu since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111331 Andrew Pinski changed: What|Removed |Added Known to work||12.3.1 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #20 from Andrew Pinski --- Fixed everywhere.
[Bug tree-optimization/111331] [11/12 Regression] Wrong code at -O1 on x86_64-linux-gnu since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111331 --- Comment #19 from GCC Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:39d56b96996dd8336652ceac97983c26fd8de4c6 commit r12-10431-g39d56b96996dd8336652ceac97983c26fd8de4c6 Author: Andrew Pinski Date: Thu Sep 7 22:13:31 2023 -0700 Fix PR 111331: wrong code for `a > 28 ? MIN : 29` The problem here is after r6-7425-ga9fee7cdc3c62d0e51730, the comparison to see if the transformation could be done was using the wrong value. Instead of see if the inner was LE (for MIN and GE for MAX) the outer value, it was comparing the inner to the value used in the comparison which was wrong. Committed to GCC 13 branch after bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: PR tree-optimization/111331 * tree-ssa-phiopt.cc (minmax_replacement): Fix the LE/GE comparison for the `(a CMP CST1) ? max : a` optimization. gcc/testsuite/ChangeLog: PR tree-optimization/111331 * gcc.c-torture/execute/pr111331-1.c: New test. * gcc.c-torture/execute/pr111331-2.c: New test. * gcc.c-torture/execute/pr111331-3.c: New test. (cherry picked from commit 30e6ee074588bacefd2dfe745b188bb20c81fe5e)
[Bug tree-optimization/111331] [11/12 Regression] Wrong code at -O1 on x86_64-linux-gnu since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111331 --- Comment #18 from GCC Commits --- The releases/gcc-11 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:16e27b6d03756bf1fae22607fa93107787a7b9cb commit r11-11421-g16e27b6d03756bf1fae22607fa93107787a7b9cb Author: Andrew Pinski Date: Thu Sep 7 22:13:31 2023 -0700 Fix PR 111331: wrong code for `a > 28 ? MIN : 29` The problem here is after r6-7425-ga9fee7cdc3c62d0e51730, the comparison to see if the transformation could be done was using the wrong value. Instead of see if the inner was LE (for MIN and GE for MAX) the outer value, it was comparing the inner to the value used in the comparison which was wrong. Committed to GCC 13 branch after bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: PR tree-optimization/111331 * tree-ssa-phiopt.c (minmax_replacement): Fix the LE/GE comparison for the `(a CMP CST1) ? max : a` optimization. gcc/testsuite/ChangeLog: PR tree-optimization/111331 * gcc.c-torture/execute/pr111331-1.c: New test. * gcc.c-torture/execute/pr111331-2.c: New test. * gcc.c-torture/execute/pr111331-3.c: New test. (cherry picked from commit 30e6ee074588bacefd2dfe745b188bb20c81fe5e)
[Bug c++/113582] incorrect warning about unused label with `pragma GCC diagnostic` around the unused label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113582 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Marek Polacek --- Fixed in GCC 15.
[Bug c++/113582] incorrect warning about unused label with `pragma GCC diagnostic` around the unused label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113582
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:d9318caed3bbff8136d13e00dcfc020a59d10f78
commit r15-329-gd9318caed3bbff8136d13e00dcfc020a59d10f78
Author: Marek Polacek
Date: Wed Jan 24 18:06:48 2024 -0500
c++: #pragma doesn't disable -Wunused-label [PR113582]
The PR complains that
void do_something(){
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-label"
start:;
#pragma GCC diagnostic pop
} #1
doesn't work. That's because we warn_for_unused_label only while we're
in finish_function, meaning we're at #1 where we're outside the #pragma
region. We can use suppress_warning + warning_suppressed_p to fix this.
Note that I'm not using TREE_USED. Propagating it in
tsubst_stmt/LABEL_EXPR
from decl to label would mean that we don't warn in do_something2, but
I think we want the warning there: we're in a template and the goto is
a discarded statement.
PR c++/113582
gcc/c-family/ChangeLog:
* c-warn.cc (warn_for_unused_label): Don't warn if -Wunused-label
has
been suppressed for the label.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_label_for_labeled_statement):
suppress_warning
if it's not enabled at input_location.
* pt.cc (tsubst_stmt): Call copy_warning.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wunused-label-4.C: New test.
[Bug middle-end/95351] [11/12 Regression] Comparison with NAN optimizes incorrectly with -ffast-math disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95351 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||12.3.1, 14.1.0 Resolution|--- |FIXED --- Comment #11 from Andrew Pinski --- Fixed everywhere now.
[Bug middle-end/95351] [11/12 Regression] Comparison with NAN optimizes incorrectly with -ffast-math disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95351 --- Comment #10 from GCC Commits --- The releases/gcc-11 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:6c00c3245e688d00dae3e928f0d03f530640caae commit r11-11420-g6c00c3245e688d00dae3e928f0d03f530640caae Author: Andrew Pinski Date: Sun Mar 10 22:17:09 2024 + Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351] The problem here is that merge_truthop_with_opposite_arm would use the type of the result of the comparison rather than the operands of the comparison to figure out if we are honoring NaNs. This fixes that oversight and now we get the correct results in this case. Committed as obvious after a bootstrap/test on x86_64-linux-gnu. PR middle-end/95351 gcc/ChangeLog: * fold-const.c (merge_truthop_with_opposite_arm): Use the type of the operands of the comparison and not the type of the comparison. gcc/testsuite/ChangeLog: * gcc.dg/float_opposite_arm-1.c: New test. Signed-off-by: Andrew Pinski (cherry picked from commit 31ce2e993d09dcad1ce139a2848a28de5931056d)
[Bug middle-end/95351] [11/12 Regression] Comparison with NAN optimizes incorrectly with -ffast-math disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95351 --- Comment #9 from GCC Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:d88fe8210e4edc2f4ddf722ba788924452c6f6a0 commit r12-10430-gd88fe8210e4edc2f4ddf722ba788924452c6f6a0 Author: Andrew Pinski Date: Sun Mar 10 22:17:09 2024 + Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351] The problem here is that merge_truthop_with_opposite_arm would use the type of the result of the comparison rather than the operands of the comparison to figure out if we are honoring NaNs. This fixes that oversight and now we get the correct results in this case. Committed as obvious after a bootstrap/test on x86_64-linux-gnu. PR middle-end/95351 gcc/ChangeLog: * fold-const.cc (merge_truthop_with_opposite_arm): Use the type of the operands of the comparison and not the type of the comparison. gcc/testsuite/ChangeLog: * gcc.dg/float_opposite_arm-1.c: New test. Signed-off-by: Andrew Pinski (cherry picked from commit 31ce2e993d09dcad1ce139a2848a28de5931056d)
[Bug libstdc++/114750] converting load/store of simd fails compilation on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114750 --- Comment #5 from GCC Commits --- The releases/gcc-12 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:b3097e01cd5d32e9825b7b87dff12b3247bd9819 commit r12-10426-gb3097e01cd5d32e9825b7b87dff12b3247bd9819 Author: Matthias Kretz Date: Wed Apr 17 09:11:25 2024 +0200 libstdc++: Avoid ill-formed types on ARM This resolves failing tests in check-simd. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/114750 * include/experimental/bits/simd_builtin.h (_SimdImplBuiltin::_S_load, _S_store): Fall back to copying scalars if the memory type cannot be vectorized for the target. (cherry picked from commit 0fc7f3c6adc8543f55ec35b309016d9d9c4ddd35)
[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803 --- Comment #4 from GCC Commits --- The releases/gcc-12 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:0ab30fb865e6465156f7db10506b56ef2df19648 commit r12-10429-g0ab30fb865e6465156f7db10506b56ef2df19648 Author: Matthias Kretz Date: Mon Apr 22 16:12:34 2024 +0200 libstdc++: Fix conversion of simd to vector builtin Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/114803 * include/experimental/bits/simd_builtin.h (_SimdBase2::operator __vector_type_t): There is no __builtin() function in _SimdWrapper, instead use its conversion operator. * testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc: New test. (cherry picked from commit 7ef139146a8923a8719873ca3fdae175668e8d63)
[Bug libstdc++/109822] Converting std::experimental::simd masks yields an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822 --- Comment #10 from GCC Commits --- The releases/gcc-12 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:44df51e5826747d089a08fa1a1378454a8d2d0de commit r12-10423-g44df51e5826747d089a08fa1a1378454a8d2d0de Author: Matthias Kretz Date: Fri Jun 2 21:33:04 2023 +0200 libstdc++: Avoid vector casts while still avoiding PR90424 Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/109822 * include/experimental/bits/simd_builtin.h (_S_store): Rewrite to avoid casts to other vector types. Implement store as succession of power-of-2 sized memcpy to avoid PR90424. (cherry picked from commit 9165ede56ababd6471e7a2ce4eab30f3d5129e14)
[Bug libstdc++/110054] stdx::simd masked store should not use non-temporal store instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110054 --- Comment #5 from GCC Commits --- The releases/gcc-12 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:e60ec9b0e02e8647c289d204342e992e91750011 commit r12-10422-ge60ec9b0e02e8647c289d204342e992e91750011 Author: Matthias Kretz Date: Fri Jun 2 13:44:22 2023 +0200 libstdc++: Replace use of incorrect non-temporal store The call to the base implementation sometimes didn't find a matching signature because the _Abi parameter of _SimdImpl* was "wrong" after conversion. It has to call into ::_SimdImpl instead of the current ABI tag's _SimdImpl. This also reduces the number of possible template instantiations. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/110054 * include/experimental/bits/simd_builtin.h (_S_masked_store): Call into deduced ABI's SimdImpl after conversion. * include/experimental/bits/simd_x86.h (_S_masked_store_nocvt): Don't use _mm_maskmoveu_si128. Use the generic fall-back implementation. Also fix masked stores without SSE2, which were not doing anything before. (cherry picked from commit 27e45b7597d6fb1a71927d658a0294797b720c0a)
[Bug target/109762] [12 Regression] gcc/config/aarch64/aarch64-builtins.cc: mismatched sizes for flags variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109762 --- Comment #11 from Andrew Pinski --- The patch does not apply directly to GCC 12.
[Bug target/110066] [13 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #28 from Andrew Pinski --- Fixed.
