[Bug other/115110] [15 regression] several failures after r15-512-g9b7cad5884f21c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115110 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I see those on x86_64-linux and i686-linux too.
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- The reproducer isn't self-contained, it uses a lot of modules which aren't defined in the source. You can use tools like delta, see e.g. https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction to reduce the testcase first and then from the minimum number of modules again copy over the module definitions from other files and repeat the reduction until it is a single file. Or provide a tarball with all the *.f90 files that provide recursively needed modules.
[Bug fortran/115108] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115108 Jakub Jelinek changed: What|Removed |Added Resolution|--- |DUPLICATE CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 115107 ***
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107 --- Comment #1 from Jakub Jelinek --- *** Bug 115108 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/114902] [14 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902 Jakub Jelinek changed: What|Removed |Added Summary|[14/15 Regression] wrong|[14 Regression] wrong code |code at -O3 with|at -O3 with "-fno-tree-vrp |"-fno-tree-vrp |-fno-expensive-optimization |-fno-expensive-optimization |s -fno-tree-dominator-opts" |s -fno-tree-dominator-opts" |on x86_64-linux-gnu |on x86_64-linux-gnu | CC||jakub at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #14 from Jakub Jelinek --- Fixed for 15.1+ so far.
[Bug c/115103] No diagnostics for grainsize used together with num_tasks clause or for fortran for nogroup with reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115103 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Keywords||accepts-invalid --- Comment #2 from Jakub Jelinek --- Fixed for GCC 15.1+. As it is accepts-invalid, not planning to backport it.
[Bug c/105863] RFE: C23 #embed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
_Embed opens the pandorra box what should happen when you stringify it or try
to token paste it together with something else etc.
Anyway, for GCC implementation of what C23 specifies, I wonder if we shouldn't
implement it in separate steps, first in a dumb way of just expanding it always
into preprocessor token, a path that could perhaps then be kept for the smaller
sizes when it isn't worth doing something smart.
And only in the second step try to add optimizations to it (guess for C those
could be easier than for C++ because C doesn't try to tokenize everything
first, so for C when we peek at the large embed token outside of the language
contexts where we know how to handle those (e.g. most importantly inside of
aggregate initializers) we could simply replace the token with expanded form of
it, say if one uses
void foo (...);
void bar ()
{
foo (
#embed "foo_arguments"
);
}
it would work without having to bother too much about that specific case.
The LLVM current pull request for this is
https://github.com/llvm/llvm-project/pull/68620
I think we should try to use same options where reasonable.
[Bug c/115103] No diagnostics for grainsize used together with num_tasks clause or for fortran for nogroup with reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115103 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2024-05-15 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Keywords||openmp Status|UNCONFIRMED |ASSIGNED
[Bug c/115103] New: No diagnostics for grainsize used together with num_tasks clause or for fortran for nogroup with reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115103
Bug ID: 115103
Summary: No diagnostics for grainsize used together with
num_tasks clause or for fortran for nogroup with
reduction
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
While working on loop transformations, I've noticed we don't diagnose in C/C++
void
foo (void)
{
#pragma omp taskloop grainsize(2) num_tasks(2)
for (int i = 0; i < 32; ++i)
;
}
or in Fortran
integer :: i
!$omp taskloop grainsize(2) num_tasks(2)
do i = 1, 32
end do
end
or
integer :: i, r
r = 0
!$omp taskloop nogroup reduction(+:r)
do i = 1, 32
end do
end
which are all invalid e.g. in OpenMP 4.5 or later due to mutually exclusive
clauses.
[Bug rtl-optimization/115092] [14/15 Regression] wrong code at -O1 with "-fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre -fno-guess-branch-probability" on x86_64-linux-gnu since r14-4810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092 --- Comment #10 from Jakub Jelinek --- Created attachment 58213 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58213=edit gcc15-pr115092.patch Full patch I'm going to test.
[Bug rtl-optimization/115092] [14/15 Regression] wrong code at -O1 with "-fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre -fno-guess-branch-probability" on x86_64-linux-gnu since r14-4810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092
--- Comment #8 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #7)
> (In reply to Jakub Jelinek from comment #5)
> > I think the bug is in simplify_comparison.
> > We have there
> > GE (sign_extract:SI (reg/v:SI 101 [ g ]) (const_int 1 [0x1]) (const_int 0
> > [0])) (const_int -1 [0x])
> > That is first changed into
> > GE (ashiftrt:SI (ashift:SI (reg/v:SI 101 [ g ]) (const_int 31 [0x1f]))
> > (const_int 31 [0x1f])) (const_int -1 [0x])
> > Both are always true.
> > But then the
> > /* FALLTHROUGH */
> > case LSHIFTRT:
> > /* If we have (compare (xshiftrt FOO N) (const_int C)) and
> > the low order N bits of FOO are known to be zero, we can do
> > this
> > by comparing FOO with C shifted left N bits so long as no
> > overflow occurs. Even if the low order N bits of FOO aren't
> > known
> > to be zero, if the comparison is >= or < we can use the same
> > optimization and for > or <= by setting all the low
> > order N bits in the comparison constant. */
> > optimization triggers and optimizes it into
> > GE (ashift:SI (reg/v:SI 101 [ g ]) (const_int 31 [0x1f])) (const_int
> > -2147483648 [0x8000])
> > I think that is ok too.
> > But then
> > code = simplify_compare_const (code, raw_mode, , );
> > simplifies that to NE and I think that step is wrong, because GE of anything
> > >= INT_MIN
> > is true.
> >
> > So, I think
> > /* If we are comparing against a constant power of two and the value
> > being compared can only have that single bit nonzero (e.g., it was
> > `and'ed with that bit), we can replace this with a comparison
> > with zero. */
> > if (const_op
> > && (code == EQ || code == NE || code == GE || code == GEU
> > || code == LT || code == LTU)
> > && is_a (mode, _mode)
> > && GET_MODE_PRECISION (int_mode) - 1 < HOST_BITS_PER_WIDE_INT
> > && pow2p_hwi (const_op & GET_MODE_MASK (int_mode))
> > && (nonzero_bits (op0, int_mode)
> > == (unsigned HOST_WIDE_INT) (const_op & GET_MODE_MASK
> > (int_mode
> > {
> > code = (code == EQ || code == GE || code == GEU ? NE : EQ);
> > const_op = 0;
> > }
> > in simplify_compare_const is wrong if const_op is the most significant bit
> > of int_mode.
>
> Yeah, that look like it is missing some test.
I'd go with
--- gcc/combine.cc.jj 2024-05-07 18:10:10.415874636 +0200
+++ gcc/combine.cc 2024-05-15 13:33:26.555081215 +0200
@@ -11852,8 +11852,10 @@ simplify_compare_const (enum rtx_code co
`and'ed with that bit), we can replace this with a comparison
with zero. */
if (const_op
- && (code == EQ || code == NE || code == GE || code == GEU
- || code == LT || code == LTU)
+ && (code == EQ || code == NE || code == GEU || code == LTU
+ /* This optimization is incorrect for signed >= INT_MIN or
+< INT_MIN, those are always true or always false. */
+ || ((code == GE || code == LT) && const_op > 0))
&& is_a (mode, _mode)
&& GET_MODE_PRECISION (int_mode) - 1 < HOST_BITS_PER_WIDE_INT
&& pow2p_hwi (const_op & GET_MODE_MASK (int_mode))
Seems there is no canonical way to return this is always true or this is always
false,
sure, we could make up something like NE 1 0 or EQ 1 0 or similar, but it
wouldn't likely match and the question is if it would simplify.
The const_op == -1 handling below this looks correct to me.
> That needs to be fixed of course, but independent of that, this should really
> have been completely folded away earlier already?
It would if one wouldn't carefully disable tons of optimizations (say -O1, so
no (significant) VRP, dom* disabled, fre disabled).
Furthermore, at least in the optimized dump it is obfuscated through:
_22 = _21 & 1;
# RANGE [irange] int [0, 1] MASK 0x1 VALUE 0x0
_24 = 1 >> _22;
_26 = -_24;
:
# prephitmp_27 = PHI <_26(3), -1(2)>
if (prephitmp_27 < -1)
Sure, VRP could see that _26 has [-1, 0] range, unioned with [-1, -1] and that
is
never < -1.
[Bug rtl-optimization/115092] [14/15 Regression] wrong code at -O1 with "-fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre -fno-guess-branch-probability" on x86_64-linux-gnu since r14-4810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092
--- Comment #5 from Jakub Jelinek ---
I think the bug is in simplify_comparison.
We have there
GE (sign_extract:SI (reg/v:SI 101 [ g ]) (const_int 1 [0x1]) (const_int 0 [0]))
(const_int -1 [0x])
That is first changed into
GE (ashiftrt:SI (ashift:SI (reg/v:SI 101 [ g ]) (const_int 31 [0x1f]))
(const_int 31 [0x1f])) (const_int -1 [0x])
Both are always true.
But then the
/* FALLTHROUGH */
case LSHIFTRT:
/* If we have (compare (xshiftrt FOO N) (const_int C)) and
the low order N bits of FOO are known to be zero, we can do this
by comparing FOO with C shifted left N bits so long as no
overflow occurs. Even if the low order N bits of FOO aren't known
to be zero, if the comparison is >= or < we can use the same
optimization and for > or <= by setting all the low
order N bits in the comparison constant. */
optimization triggers and optimizes it into
GE (ashift:SI (reg/v:SI 101 [ g ]) (const_int 31 [0x1f])) (const_int
-2147483648 [0x8000])
I think that is ok too.
But then
code = simplify_compare_const (code, raw_mode, , );
simplifies that to NE and I think that step is wrong, because GE of anything >=
INT_MIN
is true.
So, I think
/* If we are comparing against a constant power of two and the value
being compared can only have that single bit nonzero (e.g., it was
`and'ed with that bit), we can replace this with a comparison
with zero. */
if (const_op
&& (code == EQ || code == NE || code == GE || code == GEU
|| code == LT || code == LTU)
&& is_a (mode, _mode)
&& GET_MODE_PRECISION (int_mode) - 1 < HOST_BITS_PER_WIDE_INT
&& pow2p_hwi (const_op & GET_MODE_MASK (int_mode))
&& (nonzero_bits (op0, int_mode)
== (unsigned HOST_WIDE_INT) (const_op & GET_MODE_MASK (int_mode
{
code = (code == EQ || code == GE || code == GEU ? NE : EQ);
const_op = 0;
}
in simplify_compare_const is wrong if const_op is the most significant bit of
int_mode.
[Bug rtl-optimization/115092] [14/15 Regression] wrong code at -O1 with "-fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre -fno-guess-branch-probability" on x86_64-linux-gnu since r14-4810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092 Jakub Jelinek changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Indeed, combine_simplify_rtx on (set (reg:CCGC 17 flags) (compare:CCGC (sign_extract:SI (reg/v:SI 101 [ g ]) (const_int 1 [0x1]) (const_int 0 [0])) (const_int -1 [0x]))) with VOIDmode, false, false remaining arguments is optimizing it to (set (reg:CCZ 17 flags) (compare:CCZ (zero_extract:SI (reg/v:SI 101 [ g ]) (const_int 1 [0x1]) (const_int 0 [0])) (const_int 0 [0]))) which is ok if it would be used solely in equality/non-equality comparisons, but is not ok when it is used in other comparisons. 1-bit sign_extract has range [-1,0] and [-1,0] < -1 is always false.
[Bug ipa/96252] [11/12/13/14/15 Regression] mis-optimization where identical functions have very different codegen since gcc 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96252 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- (In reply to Andrew Pinski from comment #12) > I wonder if we could mark call statement that icf produces as noinline > unless it is inlined? Or just mark the newly added callgraph edge for the tail call noinlinable?
[Bug ipa/115097] Strange suboptimal codegen specifically at -O2 when copying struct type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115097 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- (In reply to Richard Biener from comment #2) > Why do we use > tail-calls here instead of aliases? The functions are exported, so we can't prove if some other TU won't do return == or similar. > Why do we inline back? But IMHO if we ICF optimize something, we shouldn't undo that, so should disable the inlining across that edge. Or decide not to ICF optimize it. Plus we have the similar problem with fnsplit, where if we split some function and inline it back it causes undesirable debug info differences, ideally the inlining of fnsplit into self should just restore the old body.
[Bug tree-optimization/115092] [14/15 Regression] wrong code at -O1 with "-fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre -fno-guess-branch-probability" on x86_64-linux-gnu since r14-4810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2024-05-14 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org Target Milestone|--- |14.2 Summary|wrong code at -O1 with |[14/15 Regression] wrong |"-fgcse -ftree-pre |code at -O1 with "-fgcse |-fno-tree-dominator-opts|-ftree-pre |-fno-tree-fre |-fno-tree-dominator-opts |-fno-guess-branch-probabili |-fno-tree-fre |ty" on x86_64-linux-gnu |-fno-guess-branch-probabili ||ty" on x86_64-linux-gnu ||since r14-4810 Ever confirmed|0 |1 Priority|P3 |P2 --- Comment #1 from Jakub Jelinek --- Started with r14-4810-ge28869670c9879fe7c67caf6cc11af202509ef78
[Bug tree-optimization/115073] RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115073 --- Comment #3 from Jakub Jelinek --- Or another option is to use C23 , that is well defined for all values. But you need recent glibc (2.39 snapshots or 2.40) & gcc (14) for that.
[Bug tree-optimization/115073] RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115073 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That is misunderstanding of what C[LT]Z_DEFINED_VALUE_AT_ZERO is. The builtin has always UB on zero. If you want to define it for zero, use x ? __builtin_clz (x) : 32 (and the like) or __builtin_clzg (x, 32) in the source. C[LT]Z_DEFINED_VALUE_AT_ZERO returning 2 then makes sure the compiler can fold those conditionals or builtins into .CLZ internal calls with 2 arguments which makes it well defined for all inputs.
[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
(In reply to Tom de Vries from comment #1)
> Looking at the source code, I wonder if this would fix it:
> ...
> diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
> index eedb13bb069..045858bf638 100644
> --- a/gcc/dwarf2out.cc
> +++ b/gcc/dwarf2out.cc
> @@ -29045,7 +29045,7 @@ output_macinfo_op (macinfo_entry *ref)
> && !DWARF2_INDIRECT_STRING_SUPPORT_MISSING_ON_TARGET
> && (debug_str_section->common.flags & SECTION_MERGE) != 0)
> {
> - if (dwarf_split_debug_info && dwarf_version >= 5)
> + if (dwarf_split_debug_info && (!dwarf_strict || dwarf_version >= 5))
> ref->code = ref->code == DW_MACINFO_define
> ? DW_MACRO_define_strx : DW_MACRO_undef_strx;
> else
> ...
Just make it if (dwarf_split_debug_info) then?
I mean, this whole code is guarded with
if ((!dwarf_strict || dwarf_version >= 5)
&& ...)
[Bug middle-end/113982] Poor codegen for 64-bit add with carry widening functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113982 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jakub Jelinek --- Should be fixed now.
[Bug middle-end/113982] Poor codegen for 64-bit add with carry widening functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113982 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Jakub Jelinek --- Created attachment 58179 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58179=edit gcc15-pr113982.patch Untested fix.
[Bug middle-end/113982] Poor codegen for 64-bit add with carry widening functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113982 --- Comment #6 from Jakub Jelinek --- Note, since PR95853 we also recognize bool(r > ~0ULL) as the check rather than bool(r >> 64).
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #26 from Jakub Jelinek --- Fixed then.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 --- Comment #22 from Jakub Jelinek --- Does even the committed version work fine on mingw32?
[Bug c++/113798] [C++26] P2662R3 - Pack indexing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113798 --- Comment #2 from Jakub Jelinek --- Ignore me, functions can't return arrays.
[Bug rtl-optimization/114415] [13 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Jakub Jelinek --- Fixed, thanks.
[Bug c++/115012] noptr-abstract-pack-declarator parsing bug with T... [N]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115012 Jakub Jelinek changed: What|Removed |Added Attachment #58147|0 |1 is obsolete|| --- Comment #2 from Jakub Jelinek --- Created attachment 58148 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58148=edit gcc15-pr115012.patch Updated patch which also handles the T...(args) case.
[Bug c++/115012] noptr-abstract-pack-declarator parsing bug with T... [N]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115012 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-05-09 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 58147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58147=edit gcc15-pr115012.patch Untested fix.
[Bug c++/113798] [C++26] P2662R3 - Pack indexing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113798
--- Comment #1 from Jakub Jelinek ---
Note, I wonder if the paper didn't go too far with the
noptr-abstract-pack-declarator [ constant-expression[opt] ]
attribute-specifier-seq[opt]
production removal. It removes the unwanted
T...[4]
case which ought to be parsed as pack indexing, sure, but doesn't it also
unnecessarily
make
void foo (T...(int)[10])
{
}
invalid as well?
[Bug c++/115012] New: noptr-abstract-pack-declarator parsing bug with T... [N]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115012
Bug ID: 115012
Summary: noptr-abstract-pack-declarator parsing bug with T...
[N]
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: daniel.kruegler at googlemail dot com, egor.pugin at gmail
dot com,
mpolacek at gcc dot gnu.org, unassigned at gcc dot gnu.org,
webrown.cpp at gmail dot com
Depends on: 113798
Blocks: 110338
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #113798 +++
As mentioned in the https://wg21.link/P2662R3 paper, we aren't parsing
correctly T...[N] parameters.
template
void
foo (T... x[N])
{
}
template
void
bar (T [N])
{
}
template
void
baz (T... [N])
{
}
template
void
qux (T... [N][N])
{
}
void
corge (int a[10], double b[10], int c[5][5], float d[5][5])
{
foo <10, int, double> (a, b);
bar <10, int> (a);
baz <10, int, double> (a, b);
qux <5, int, float> (c, d);
}
is accepted by clang++ but not by GCC nor MSCV.
This is going to change in C++26 with pack indexing, but in C++11 .. C++23 it
should be valid.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338
[Bug 110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113798
[Bug 113798] [C++26] P2662R3 - Pack indexing
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #32 from Jakub Jelinek --- (In reply to Liviu Ionescu from comment #30) > in the reported bug I was building 13.2. > > was the fix backported to older versions? Yes, it was, as can be seen above. Though only in March 2024, so it couldn't have affected gcc 13.2 which was released more than 9 months ago. It is fixed on gcc 13.2.1 snapshots after those commits and will be in gcc 13.3, right now planned for release in less than 2 weeks from now.
[Bug tree-optimization/114998] [14/15 Regression] ICE on valid code at -O3 with "-fno-tree-dce" on x86_64-linux-gnu: Segmentation fault since r14-9767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114998 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Summary|[14/15 Regression] ICE on |[14/15 Regression] ICE on |valid code at -O3 with |valid code at -O3 with |"-fno-tree-dce" on |"-fno-tree-dce" on |x86_64-linux-gnu: |x86_64-linux-gnu: |Segmentation fault |Segmentation fault since ||r14-9767 --- Comment #2 from Jakub Jelinek --- Started with r14-9767-ge7b7188b1cf8c174f0e890d4ac279ff480b51043
[Bug rtl-optimization/114415] [13 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415 --- Comment #10 from Jakub Jelinek --- Vlad, do you plan to backport this to 13.3? One of the 2 release blockers we have for that release.
[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 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #17 from Jakub Jelinek --- Fixed also for 13.3.
[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Jakub Jelinek --- Fixed also for 13.3.
[Bug c++/111284] [11/12 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 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 Regression] Some |[11/12 Regression] Some |passing-by-value parameters |passing-by-value parameters |are mishandled since GCC 9, |are mishandled since GCC 9, |affecting libstdc++'s |affecting libstdc++'s |constexpr std::string |constexpr std::string --- Comment #13 from Jakub Jelinek --- Fixed also for 13.3.
[Bug sanitizer/114956] [11/12 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 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 Regression] |[11/12 Regression] |Segmentation fault with |Segmentation fault with |-fsanitize=address |-fsanitize=address |-fsanitize=null -O2 when|-fsanitize=null -O2 when |attribute |attribute |no_sanitize_address is |no_sanitize_address is |enabled since r9-5742 |enabled since r9-5742 --- Comment #8 from Jakub Jelinek --- Fixed also for 13.3.
[Bug tree-optimization/114876] [11/12 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 Regression] |[11/12 Regression] |-fprintf-return-value |-fprintf-return-value |mishandles %lc with a '\0' |mishandles %lc with a '\0' |argument. |argument. --- Comment #10 from Jakub Jelinek --- Fixed also for 13.3.
[Bug fortran/114825] [11/12 Regression] Compiler error using gfortran and OpenMP since r5-1190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 Regression] |[11/12 Regression] Compiler |Compiler error using|error using gfortran and |gfortran and OpenMP since |OpenMP since r5-1190 |r5-1190 | --- Comment #8 from Jakub Jelinek --- Fixed also for 13.3.
[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 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 target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 --- Comment #20 from Jakub Jelinek --- Thanks, I'll test it myself on x86_64-linux/i686-linux and post if it succeeds.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 Jakub Jelinek changed: What|Removed |Added Attachment #58123|0 |1 is obsolete|| --- Comment #17 from Jakub Jelinek --- Created attachment 58125 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58125=edit gcc15-pr114968.patch Here is an updated patch. Note, even when not taking thiscall attribute into consideration, the existing code was wrong on the !targetm.cxx.use_atexit_for_cxa_atexit () targets (aka mingw), because it would happily use the atexit function argument type (aka void (*) ()) for __cxa_thread_atexit.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 --- Comment #16 from Jakub Jelinek --- What is the reason behind /* mingw32 atexit function is safe to use in shared libraries. Use it to register C++ static destructors. */ #define TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT hook_bool_void_true ? Couldn't we just drop that? I mean, when using atexit, GCC needs to emit wrapper functions around the destructors, like __tcf_0: pushq %rbp .seh_pushreg%rbp movq%rsp, %rbp .seh_setframe %rbp, 0 subq$32, %rsp .seh_stackalloc 32 .seh_endprologue leaq_ZZ3foovE1s(%rip), %rax movq%rax, %rcx call_ZN1SD1Ev nop addq$32, %rsp popq%rbp ret while with __cxa_atexit one can just pass the destructor itself to the __cxa_atexit function (indeed with slightly more instructions there because in addition to the function pointer it needs to pass the address of the object and __dso_handle). But it is still smaller. Anyway, if there is some strong reason to keep it, I think it would be better to avoid adding yet another GTY tree, the __cxa_throw last argument type is the same as __cxa_atexit/__cxa_thread_atexit.
[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 Jakub Jelinek changed: What|Removed |Added Summary|[13/14/15 Regression] wrong |[13 Regression] wrong code |code generated for |generated for Emacs/Gnulib |Emacs/Gnulib strftime |strftime (regression from |(regression from 13.2) |13.2) --- Comment #15 from Jakub Jelinek --- Fixed for 14.2+ and 15.1+.
[Bug c++/65608] [meta-bug] friend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608 Bug 65608 depends on bug 114459, which changed state. Bug 114459 Summary: [C++26] P2893R3 - Variadic friends https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114459 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338 Bug 110338 depends on bug 114459, which changed state. Bug 114459 Summary: [C++26] P2893R3 - Variadic friends https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114459 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/114459] [C++26] P2893R3 - Variadic friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114459 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Implemented for 15.1.
[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 --- Comment #11 from Jakub Jelinek --- Should be fixed for 14.2+ for now.
[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 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13/14/15 Regression] |[11/12/13 Regression] |Segmentation fault with |Segmentation fault with |-fsanitize=address |-fsanitize=address |-fsanitize=null -O2 when|-fsanitize=null -O2 when |attribute |attribute |no_sanitize_address is |no_sanitize_address is |enabled since r9-5742 |enabled since r9-5742 --- Comment #6 from Jakub Jelinek --- Fixed for 14.2 and later for now.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 --- Comment #8 from Jakub Jelinek --- Created attachment 58123 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58123=edit gcc15-pr114968.patch This is what I'd do, but completely untested...
[Bug tree-optimization/114965] [13/14/15 Regression] wrong code generated for Emacs/Gnulib strftime (regression from 13.2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965 --- Comment #11 from Jakub Jelinek --- Created attachment 58121 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58121=edit gcc15-pr114965.patch Full untested fix.
[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 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] |-fprintf-return-value |-fprintf-return-value |mishandles %lc with a '\0' |mishandles %lc with a '\0' |argument. |argument. --- Comment #8 from Jakub Jelinek --- Fixed for 14.2+ as well.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #7 from Jakub Jelinek ---
(In reply to LIU Hao from comment #6)
> I suspect this isn't correct. I am getting strange errors like 'ld exited
> with code 5' not sure what could cause it (possibly also recent MSYS2
> updates):
>
> ```
> diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
> index 2af026d255d..f5dce6a93bc 100644
> --- a/gcc/cp/decl.cc
> +++ b/gcc/cp/decl.cc
> @@ -9669,6 +9669,16 @@ get_atexit_fn_ptr_type (void)
>
>fn_type = build_function_type_list (void_type_node,
> arg_type, NULL_TREE);
> +#ifdef IX86_CALLCVT_THISCALL
> + if (flag_use_cxa_atexit
> + && !targetm.cxx.use_atexit_for_cxa_atexit ())
> +{
> + fn_type = copy_node (fn_type);
> + TYPE_ATTRIBUTES (fn_type) = tree_cons (
> +get_identifier ("thiscall"), NULL_TREE,
> +TYPE_ATTRIBUTES (fn_type));
> +}
> +#endif
>atexit_fn_ptr_type_node = build_pointer_type (fn_type);
> }
>
> diff --git a/gcc/cp/except.cc b/gcc/cp/except.cc
> index f1ffda22fd3..00a8843fa2e 100644
> --- a/gcc/cp/except.cc
> +++ b/gcc/cp/except.cc
> @@ -648,6 +648,12 @@ build_throw (location_t loc, tree exp, tsubst_flags_t
> complain)
> {
> tree tmp = build_function_type_list (void_type_node,
> ptr_type_node, NULL_TREE);
> +#ifdef IX86_CALLCVT_THISCALL
> + tmp = copy_node (tmp);
> + TYPE_ATTRIBUTES (tmp) = tree_cons (
> +get_identifier ("thiscall"), NULL_TREE,
> +TYPE_ATTRIBUTES (tmp));
> +#endif
> cleanup_type = build_pointer_type (tmp);
> }
>
>
> ```
Besides wrong formatting and the case that you need to build_variant_type (or
build_distinct_type?, one needs to look at what will be normally done if you
do:
void (__attribute__((thiscall)) *fn) (void);
), you really can't do it like that. IX86_CALLCVT_THISCALL is defined on all
x86_64/i?86 targets, so not limited to mingw 32-bit.
[Bug libgcc/110775] [12/13/14/15 Regression] abort define causing issues in tsystem.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110775
--- Comment #5 from Jakub Jelinek ---
What could work (but still hacky) would be
#define abort(...) gcc_target_abort ()
extern inline __attribute__((__always_inline__)) void
gcc_target_abort (void)
{
__builtin_abort ();
}
[Bug libgcc/110775] [12/13/14/15 Regression] abort define causing issues in tsystem.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110775 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- No, we don't want people to redeclare __builtin_* functions.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 --- Comment #3 from Jakub Jelinek --- Oh, the third argument type for __cxa_throw in cp/except.cc probably needs the same, so the target hook likely should be called similarly to the libstdc++ macro for that.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 Jakub Jelinek changed: What|Removed |Added CC||10walls at gmail dot com, ||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Guess you need to add a target hook next to use_aeabi_atexit and use_atexit_for_cxa_atexit which returns attributes that should be added to a FUNCTION_TYPE constructed by get_atexit_fn_ptr_type (build_function_type_list returns a shared type, so if attributes are to be added, it needs to go on a variant of the type. On all but mingw ia32 it shouldn't add anything, and guess it shouldn't be done if !flag_use_cxa_atexit || !targetm.cxx.use_atexit_for_cxa_atexit () A question is what to do about the __tcf_* cleanup functions that might be sometimes created. Anyway, seems to be primarily mingw maintainer responsibility given that it is the only target with such requirements.
[Bug tree-optimization/114965] [13/14/15 Regression] wrong code generated for Emacs/Gnulib strftime (regression from 13.2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek ---
Untested fix.
If entry_test_needed, earlier code ensures that exp is in [lowi, high] range,
so the optimization is ok. But without it, we need to ensure that if we lower
lowi we can still do the shifts safely.
r in this case is [43,43][48,48][95,95], so we don't need entry test if we
subtract the low bound (43), but 95 is too high for 64-bit prec.
--- gcc/tree-ssa-reassoc.cc.jj 2023-10-15 23:04:06.181422840 +0200
+++ gcc/tree-ssa-reassoc.cc 2024-05-07 13:46:42.722966813 +0200
@@ -3414,7 +3414,8 @@ optimize_range_tests_to_bit_test (enum t
We can avoid then subtraction of the minimum value, but the
mask constant could be perhaps more expensive. */
if (compare_tree_int (lowi, 0) > 0
- && compare_tree_int (high, prec) < 0)
+ && compare_tree_int (high, prec) < 0
+ && (entry_test_needed || wi::ltu_p (r.upper_bound (), prec)))
{
int cost_diff;
HOST_WIDE_INT m = tree_to_uhwi (lowi);
[Bug tree-optimization/114965] [13/14/15 Regression] wrong code generated for Emacs/Gnulib strftime (regression from 13.2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- It is the PR63464 optimization gone wrong.
[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 #20 from Jakub Jelinek --- (In reply to Sergei Trofimovich from comment #18) > > 2) ideally show a gdb session with the important events, which setjmp was > > it (I see _setjmp and __sigsetjmp calls in the function), which exact > > function called from the function ended up aborting/doing longjmp in the > > signal handler and where is the crash Strange. If it is the _setjmp call on line 26315 followed by kill SIGABRT from sig_error(); on the same line, then I don't see any local vars modified in between, except that int t on line 26315 inside of sig_GAP_Enter macro. There is then __sigsetjmp on line 26324, but no further kill calls and I think this isn't in a loop.
[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 #16 from Jakub Jelinek --- (In reply to Sergei Trofimovich from comment #14) > I reproduced the `SIGSEGV` on Gentoo ~amd64 and ::sage-on-gentoo overlay > against sci-mathematics/sagemath-standard package. > > One of the unusual properties of > __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__() is that > it raises 2 signals while it gets executed: > > - SIGABRT handler uses longjmp() to return to the ~beginning of a function > - and then SIGSEGV happens at cleanup when an attempt to dereference the > pointer happens. > > I see no `volatile` annotations anywhere in the > __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__(). > > My wild guess would be that: > 1. `PyObject *__pyx_t_4 = ((void *)0);` gets saved in setjmp() with one > value (probably NULL) > 2. updated at some point later in the same function to non-NULL that `gcc` > can infer and throw away all later `NULL` checks > 3. then SIGABRT returns with longjmp() by accidentally resetting > > I would expect `__pyx_t_4` to require volatile annotation for such an > `element.i` definition. Or `longjmp()` should be called from a `((noipa))` > function to force register spill/reload on stack. > > To cite `man setjmp`: > > """ > CAVEATS >The compiler may optimize variables into registers, and > longjmp() may restore the values of other registers in addition to the stack > pointer and program counter. Consequently, the values of automatic >variables are unspecified after a call to longjmp() if they meet all > the following criteria: >• they are local to the function that made the corresponding > setjmp() call; >• their values are changed between the calls to setjmp() and > longjmp(); and >• they are not declared as volatile. >Analogous remarks apply for siglongjmp(). > """ > > Sounds plausible? So, if you can reproduce it, can you: 1) attach your *.s file and state which exact compiler you used (revision) 2) ideally show a gdb session with the important events, which setjmp was it (I see _setjmp and __sigsetjmp calls in the function), which exact function called from the function ended up aborting/doing longjmp in the signal handler and where is the crash 3) is it __pyx_t_6, __pyx_t_4 or some other pointer that triggers it (from the line numbers in #c0 my guess was __pyx_t_6, but you talk about __pyx_t_4) Yes, there are no volatile keywords on any of the vars, but without knowing which setjmp call it is and from where longjmp jumps to it, it is hard to know if the variables have been modified in between (then volatile would be required) or if they are only modified before the setjmp call or after the call that calls longjmp (then volatile might not be required).
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #33 from Jakub Jelinek --- That is still a hack, but guess can be acceptable for 14.22 and short term trunk if the ARM maintainers approve it. But, for GCC 15+, I think if the behavior is that when the predicate constant/register is used in an instruction, regardless of the element mode it actually performs per-byte predication, then it should be represented as V16BImode, not V8BImode or V4BImode. It is fine if instructions which produce the predicate mask like comparisons produce V8BImode or V4BImode, but what consumes should use subreg of that to V16BImode. At least if the behavior is either perform the operation on all elements and then based on the 16 bits in the predicate choose result between the newly computed result and something else on byte by byte basis. Or perhaps if the operation is performed only on elements where at least one predicate bit for the element is non-zero and then merged. I think it would be useful if you pointed at the docs how the instructions exactly work or tried to explain it here.
[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 #15 from Jakub Jelinek --- (In reply to Dmitrii Pasechnik from comment #12) > A colleague disassembled, using ghidra (https://ghidra-sre.org/), the > results of the compilations with, respectively, -O2 and with -O0 flags. > Comparing the results, in the broken (built with -O2) case one sees a > miscompilation of a call to GAP_CallFunc3Args - it is called with one > argument less than it should, three instead of four! > > broken (-O2): > > > plVar9 = (long *)GAP_CallFunc3Args(*(undefined8 *)(param_1 + > > 0x20),local_a0[4], > > local_a8[4]); > > vs. good (-O0): > > < LAB_0013cbd9: > < plVar10 = (long *)GAP_CallFunc3Args(*(undefined8 *)(param_1 + > 0x20),local_a8[4], > < local_a0[4],plVar16[4]); > > And this is despite the prototype for calling GAP_CallFunc3Args() is > found in "gap/libgap-api.h", which is included in example.c as #include > "gap/libgap-api.h", meant to be respected during the compilation. > > I hope this helps in chasing down the obvious compiler bug. Perhaps it can > be also seen without disassembling, simply on the intermediate data > generated by the compiler. Both calls pass 4 arguments, both in optimized -O2 -fPIC GCC 13.2.1 dump and in assembly: movq-88(%rbp), %rdx movq%r12, %rcx movq%r13, %rsi movq%rax, %rdi callGAP_CallFunc3Args@PLT ... movq-88(%rbp), %rdx movq%r12, %rcx movq%r13, %rsi movq%rax, %rdi callGAP_CallFunc3Args@PLT and GAP_CallFunc3Args (_53, _47, __pyx_v_func_54(D), _49); ... _441 = GAP_CallFunc3Args (_98, _97, _96, _95);
[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 58108 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58108=edit gcc15-pr114907.patch In retrospect, it has been a mistake to export __trunchfbf2 rather than __extendhfbf2, but we've done that already. Given that it is an arbitrary name choice (both are wrong), I think it is better to change what gcc emits rather than what functions libgcc exports, because we can backport what gcc emits but can't the libgcc changes.
[Bug libstdc++/114958] use __builtin_shufflevector for std::experimental::simd split and concat (at least the common cases) to enable better optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114958 --- Comment #4 from Jakub Jelinek --- Strange, the __builtin_shufflevector in GCC has been added for Clang compatibility. __builtin_shuffle is the original native GCC builtin (which Clang doesn't implement).
[Bug libstdc++/114958] use __builtin_shufflevector for std::experimental::simd split and concat (at least the common cases) to enable better optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114958 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I'm not sure the header should use __builtin_shufflevector unconditionally, I think better test it using __has_builtin first. GCC has it since GCC 12 I think, clang indeed much longer, not sure about other compilers (ICC).
[Bug sanitizer/114956] [11/12/13/14/15 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 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 58106 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58106=edit gcc15-pr114956.patch Untested fix.
[Bug sanitizer/114956] [11/12/13/14/15 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
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-05-06
Summary|[11/12/13/14/15 regression] |[11/12/13/14/15 Regression]
|Segmentation fault with |Segmentation fault with
|-fsanitize=address |-fsanitize=address
|-fsanitize=null -O2 when|-fsanitize=null -O2 when
|attribute |attribute
|no_sanitize_address is |no_sanitize_address is
|enabled |enabled since r9-5742
Ever confirmed|0 |1
Target Milestone|--- |11.5
Status|UNCONFIRMED |NEW
Priority|P3 |P2
--- Comment #2 from Jakub Jelinek ---
Started with my r9-5742-g6206a883fe7a741dbb9e09d88255a170a75950f5
-O2 -fsanitize=address,null
int **a;
__attribute__((always_inline)) int *
foo (void)
{
int b[1];
(void) b;
}
__attribute__((no_sanitize_address)) static char
bar (void)
{
*a = foo ();
}
void
baz (void)
{
bar ();
}
[Bug other/114939] [15 regression] c-c++-common/torture/strub-run3.c fails after r15-125-g7117e1f6bf6de2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114939 Jakub Jelinek changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- To me this looks like that test is depending on the invalid assumption that alloca in always_inline calls should behave like it behaved before (which was incorrect).
[Bug c++/114459] [C++26] P2893R3 - Variadic friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114459 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 58100 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58100=edit gcc14-pr114459.patch Untested implementation.
[Bug c/114931] [14/15 regression] ICE in get_alias_set when building tcl with -std=c23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
--- Comment #12 from Jakub Jelinek ---
Anyway, such changes are a partial shift towards the model to update derived
types which you said you don't want; it doesn't actually update them, but
basically forces new types after the base type(s) is/are finalized.
Another possibility might be simply in all the spots where we set
TYPE_CANONICAL (t) = something; to add if (TYPE_STRUCTURAL_EQUALITY_P
(TYPE_CANONICAL (t))) SET_TYPE_STRUCTURAL_EQUALITY (t);
On the build_function_type it could be
--- gcc/tree.cc.jj 2024-04-16 09:56:16.463008446 +0200
+++ gcc/tree.cc 2024-05-03 10:21:04.119086667 +0200
@@ -7511,17 +7511,25 @@ build_function_type (tree value_type, tr
hashval_t hash = type_hash_canon_hash (t);
t = type_hash_canon (hash, t);
- /* Set up the canonical type. */
- any_structural_p = TYPE_STRUCTURAL_EQUALITY_P (value_type);
- any_noncanonical_p = TYPE_CANONICAL (value_type) != value_type;
- canon_argtypes = maybe_canonicalize_argtypes (arg_types,
- _structural_p,
- _noncanonical_p);
- if (any_structural_p)
-SET_TYPE_STRUCTURAL_EQUALITY (t);
- else if (any_noncanonical_p)
-TYPE_CANONICAL (t) = build_function_type (TYPE_CANONICAL (value_type),
- canon_argtypes);
+ if (TYPE_CANONICAL (t) == t)
+{
+ /* Set up the canonical type. */
+ any_structural_p = TYPE_STRUCTURAL_EQUALITY_P (value_type);
+ any_noncanonical_p = TYPE_CANONICAL (value_type) != value_type;
+ canon_argtypes = maybe_canonicalize_argtypes (arg_types,
+ _structural_p,
+ _noncanonical_p);
+ if (any_structural_p)
+ SET_TYPE_STRUCTURAL_EQUALITY (t);
+ else if (any_noncanonical_p)
+ {
+ TYPE_CANONICAL (t)
+ = build_function_type (TYPE_CANONICAL (value_type),
+ canon_argtypes);
+ if (TYPE_STRUCTURAL_EQUALITY_P (TYPE_CANONICAL (t)))
+ SET_TYPE_STRUCTURAL_EQUALITY (t);
+ }
+}
if (!COMPLETE_TYPE_P (t))
layout_type (t);
[Bug c/114931] [14/15 regression] ICE in get_alias_set when building tcl with -std=c23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931 --- Comment #9 from Jakub Jelinek --- Do you really need to hash it on TYPE_CANON, rather than just on whether the type is TYPE_STRUCTURAL_EQUALITY_P or not? I'm worried that always computing the TYPE_CANON before calling type_hash_canon is going to be quite expensive, while just figuring out if it should have TYPE_STRUCTURAL_EQUALITY_P or not should be cheaper. If it should have TYPE_STRUCTURAL_EQUALITY_P, we'd SET_TYPE_STRUCTURAL_EQUALITY, otherwise set TYPE_CANONICAL (t) = t; (I think that is what we generally get from make_node), look up and recompute TYPE_CANONICAL if TYPE_CANONICAL (t) == t.
[Bug c++/110343] [C++26] P2558R2 - Add @, $, and ` to the basic character set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110343 --- Comment #7 from Jakub Jelinek --- Note, GCC 15 stage1 is open, so feel free to post your patch.
[Bug c++/110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338
Bug 110338 depends on bug 114458, which changed state.
Bug 114458 Summary: [C++26] P2573R2 - = delete("reason");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114458
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
[Bug c++/114458] [C++26] P2573R2 - = delete("reason");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114458 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Implemented for GCC 15+.
[Bug libgcc/114907] __trunchfbf2 should be renamed to __extendhfbf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Neither of the modes is a subset or superset of the other, so truncate vs. extend makes no sense. The choice was arbitrary.
[Bug c++/114458] [C++26] P2573R2 - = delete("reason");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114458 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 58078 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58078=edit gcc15-pr114458.patch Untested implementation.
[Bug tree-optimization/114876] [11/12/13/14 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876 --- Comment #6 from Jakub Jelinek --- Fixed for 15+ so far.
[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Jakub Jelinek --- And now cherry-picked to 14.1 as well: commit r14-10153-ge976bef1579086e6e83c6a47f6c5f8f996208f99 Author: Paul Thomas Date: Mon Apr 29 11:52:11 2024 +0100 Fortran: Fix regression caused by r14-9752 [PR114959] 2024-04-29 Paul Thomas gcc/fortran PR fortran/114959 * trans-expr.cc (gfc_trans_class_init_assign): Return NULL_TREE if the default initializer has all NULL fields. Guard this by a requirement that the code not be EXEC_INIT_ASSIGN and that the object be an INTENT_OUT dummy. * trans-stmt.cc (gfc_trans_allocate): Change the initializer code for allocate with mold to EXEC_ALLOCATE to allow an initializer with all NULL fields. gcc/testsuite/ PR fortran/114959 * gfortran.dg/pr114959.f90: New test. (cherry picked from commit bca41a8d55e830c882b0f39246afead4fcfae6f7)
[Bug tree-optimization/114883] [14/15 Regression] 521.wrf_r ICE with -O2 -march=sapphirerapids -fvect-cost-model=cheap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- Fixed.
[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895 --- Comment #6 from Jakub Jelinek --- I've hacked up my libgfortran/configure, added there sleep 60s after writing conftest.c for working stat check, and then rm -f config.cache; ./config.status --recheck in the x86*/32/libgfortran directory and the above conftest.c is what I saw.
[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895 --- Comment #5 from Jakub Jelinek --- Created attachment 58075 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58075=edit conftest.c
[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895
--- Comment #4 from Jakub Jelinek ---
That is really weird.
Because the
checking for _FILE_OFFSET_BITS value needed for large files... 64
test should add
#define _FILE_OFFSET_BITS 64
line to confdefs.h and I believe the working stat testing should use that:
if test "$cross_compiling" = yes; then :
case "${target}" in
*mingw*) libgfor_cv_have_working_stat=no ;;
*) libgfor_cv_have_working_stat=yes;;
esac
else
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
#include
#include
#include
#include
int main ()
{
FILE *f, *g;
struct stat st1, st2;
f = fopen ("foo", "w");
g = fopen ("bar", "w");
if (stat ("foo", ) != 0 || stat ("bar", ))
return 1;
if (st1.st_dev == st2.st_dev && st1.st_ino == st2.st_ino)
return 1;
fclose(f);
fclose(g);
return 0;
}
_ACEOF
The cat should source in all of confdefs.h so far.
[Bug c++/110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338 Bug 110338 depends on bug 114456, which changed state. Bug 114456 Summary: [C++26] P0609R3 - Attributes for structured bindings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114456 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/114456] [C++26] P0609R3 - Attributes for structured bindings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114456 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Implemented for GCC 15.
[Bug tree-optimization/114883] [14/15 Regression] 521.wrf_r ICE with -O2 -march=sapphirerapids -fvect-cost-model=cheap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883 --- Comment #9 from Jakub Jelinek --- Created attachment 58073 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58073=edit gcc14-pr114883.patch Full untested patch.
[Bug tree-optimization/114883] [14/15 Regression] 521.wrf_r ICE with -O2 -march=sapphirerapids -fvect-cost-model=cheap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883 --- Comment #8 from Jakub Jelinek --- Just changing the min in the testcase to max results on ICE with IFN_COND_MAX.
[Bug tree-optimization/114883] [14/15 Regression] 521.wrf_r ICE with -O2 -march=sapphirerapids -fvect-cost-model=cheap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883 --- Comment #7 from Jakub Jelinek --- Slightly more reduced testcase: subroutine pr114883(a, b, c, d, e, f, g, h, o) real(8) :: c(1011), d(1011), e(0:1011) real(8) :: p, q, f, r, g(1011), h(1011), b, bar integer :: o(100), a, t, u p = 0.0_8 r = bar() u = 1 do i = 1,a do k = 1,1011 km1 = max0(k-1,1) h(k) = c(k) * e(k-1) * d(km1) f = g(k) + h(k) if(f.gt.1.e-6)then p = min(p,r) endif end do q = 0.9_8 * p t = integer(b/q + 1) if(t>100)then u = t endif o(u) = o(u) + 1 end do end subroutine pr114883
[Bug tree-optimization/114883] [14/15 Regression] 521.wrf_r ICE with -O2 -march=sapphirerapids -fvect-cost-model=cheap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
(In reply to Hongtao Liu from comment #4)
> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> index a6cf0a5546c..ae6abe00f3e 100644
> --- a/gcc/tree-vect-loop.cc
> +++ b/gcc/tree-vect-loop.cc
> @@ -8505,7 +8505,8 @@ vect_transform_reduction (loop_vec_info loop_vinfo,
> {
>gcc_assert (code == IFN_COND_ADD || code == IFN_COND_SUB
> || code == IFN_COND_MUL || code == IFN_COND_AND
> - || code == IFN_COND_IOR || code == IFN_COND_XOR);
> + || code == IFN_COND_IOR || code == IFN_COND_XOR
> + || code == IFN_COND_MIN);
>gcc_assert (op.num_ops == 4
> && (op.ops[reduc_index]
> == op.ops[internal_fn_else_index ((internal_fn)
> code)]));
>
> Could fix the ICE.
Why IFN_COND_MIN and not IFN_COND_MAX?
What about other binary cond_fns? I see
DIV/MOD/RDIV/COPYSIGN/FMIN/FMAX/SHL/SHR.
Though, SHL/SHR/COPYSIGN/DIV/MOD/RDIV aren't commutative nor associative, dunno
about
if FMIN/FMAX could trigger. But certainly IFN_COND_MAX should be handled next
to IFN_COND_MIN.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #31 from Jakub Jelinek --- Seems most of the V4BI/V8BImode predicates are in UNSPECs, I think long term turning them into just using there V16BImode might help. Keep using V4BI/V8BImode for cases where we know it is all 0 or all 1 bits in each element, say when some comparison produces the mask, and then just use SUBREG to turn that into V16BImode.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #29 from Jakub Jelinek ---
With
--- a/gcc/config/arm/arm-mve-builtins.cc
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -2100,7 +2100,22 @@ function_expander::add_input_operand (insn_code icode,
rtx x)
mode = GET_MODE (x);
}
else if (VALID_MVE_PRED_MODE (mode))
-x = gen_lowpart (mode, x);
+{
+ if (CONST_INT_P (x) && (mode == V8BImode || mode == V4BImode))
+ {
+ /* In V8BI or V4BI each element has 2 or 4 bits, if those
+bits aren't all the same, gen_lowpart might ICE. */
+ unsigned HOST_WIDE_INT xi = UINTVAL (x);
+ if ((xi & 0x) != ((xi >> 1) & 0x)
+ || (mode == V4BImode
+ && (xi & 0x) != ((xi >> 2) & 0x)))
+ x = force_reg (HImode, x);
+ }
+ else if (SUBREG_P (x))
+ /* gen_lowpart on a SUBREG can ICE. */
+ x = force_reg (GET_MODE (x), x);
+ x = gen_lowpart (mode, x);
+}
m_ops.safe_grow (m_ops.length () + 1, true);
create_input_operand (_ops.last (), x, mode);
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #28 from Jakub Jelinek ---
#include
uint32x4_t test_9() {
return vdupq_m_n_u32(vdupq_n_u32(0x), 0, 0x);
}
./cc1 -quiet -isystem include/ -march=armv8.1-m.main+mve -mfloat-abi=hard
pr114801.c -mthumb -O2 -da
during RTL pass: cse1
dump file: pr114801.c.272r.cse1
pr114801.c: In function ‘test_9’:
pr114801.c:4:1: internal compiler error: in find_cached_value, at
rtx-vector-builder.cc:100
4 | }
| ^
0x15a1370 rtx_vector_builder::find_cached_value()
../../gcc/rtx-vector-builder.cc:100
0x15a1123 rtx_vector_builder::build()
../../gcc/rtx-vector-builder.cc:64
0x15f2a57 native_decode_vector_rtx(machine_mode, vec const&, unsigned int, unsigned int, unsigned int)
../../gcc/simplify-rtx.cc:7269
0x15f2b7e native_decode_rtx(machine_mode, vec
const&, unsigned int)
../../gcc/simplify-rtx.cc:7289
0x15f3bd7 simplify_immed_subreg
../../gcc/simplify-rtx.cc:7529
0x15f431b simplify_context::simplify_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
../../gcc/simplify-rtx.cc:7603
0x105c627 simplify_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
../../gcc/rtl.h:3516
0x25c8293 equiv_constant
../../gcc/cse.cc:3804
0x25c65a0 fold_rtx
../../gcc/cse.cc:3138
0x25c9e7e cse_insn
../../gcc/cse.cc:4667
0x25cf1fd cse_extended_basic_block
../../gcc/cse.cc:6574
0x25cf70e cse_main
../../gcc/cse.cc:6719
0x25d1879 rest_of_handle_cse
../../gcc/cse.cc:7549
0x25d1990 execute
../../gcc/cse.cc:7594
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/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 --- Comment #6 from Jakub Jelinek --- I have looked at the IL and I don't see how it could crash that way based on the -fdump-tree-optimized-lineno dump, neither on branch nor on the trunk. On the branch, I see [local count: 462566023]: [element.c:26539:57 discrim 1] __pyx_t_5_522(ab) = 0B; [/usr/include/python3.12/object.h:797:8] if (__pyx_t_6_211(ab) != 0B) goto ; [70.00%] else goto ; [30.00%] [local count: 462566023]: [element.c:26540:57 discrim 1] __pyx_t_6_524(ab) = 0B; [/usr/include/python3.12/object.h:797:8] if (__pyx_t_8_1031(ab) != 0B) goto ; [70.00%] else goto ; [30.00%] [local count: 323796219]: [/usr/include/python3.12/object.h:242:25] _1105 = [/usr/include/python3.12/object.h:242:25] [/usr/include/python3.12/object.h:242:25] __pyx_t_6_211(ab)->D.10046.ob_refcnt; [/usr/include/python3.12/object.h:242:13] _1106 = (int) _1105; [/usr/include/python3.12/object.h:700:8 discrim 1] if (_1106 < 0) goto ; [26.36%] else goto ; [73.64%] [local count: 238443538]: [/usr/include/python3.12/object.h:704:9] _1107 = _1105 + -1; [/usr/include/python3.12/object.h:704:8] [/usr/include/python3.12/object.h:704:13] [/usr/include/python3.12/object.h:704:13] __pyx_t_6_211(ab)->D.10046.ob_refcnt = _1107; [/usr/include/python3.12/object.h:704:8] if (_1107 == 0) goto ; [33.00%] else goto ; [67.00%] [local count: 78686364]: [/usr/include/python3.12/object.h:705:9] _Py_Dealloc (__pyx_t_6_211(ab)); goto ; [100.00%] so the 26540 line case checks if the pointer later passed to the _Py_Dealloc is non-NULL and doesn't let it be called in that case.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #25 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #24)
> Another short term (14.1 only) possibility would be to force_reg a CONST_INT
> operand into a register if it didn't have all bits the same (and hope
> combine or whatever else won't simplify it again), i.e.
>else if (VALID_MVE_PRED_MODE (mode))
> {
>if (CONST_INT_P (x) && (mode == V8BImode || mode == V4BImode))
> {
>/* In V8BI or V4BI each element has 2 or 4 bits, if those
> bits aren't all the same, gen_lowpart might ICE. */
>unsigned HOST_WIDE_INT xi = UINTVAL (xi);
UINTVAL (x) above.
>if ((xi & 0x) != ((xi >> 1) & 0x)
>|| (mode == V4BImode
>&& (xi & 0x) != ((xi >> 2) & 0x)))
> x = force_reg (HImode, x);
> }
>else if (SUBREG_P (x))
> /* gen_lowpart on a SUBREG can ICE. */
> x = force_reg (GET_MODE (x), x);
>x = gen_lowpart (mode, x);
> }
> If that fixes just the ICE during expansion but ICEs during fwprop, combine
> etc.,
> then you might try (temporarily) harder and hide the constant from the
> optimizers,
> e.g. instead of using force_reg emit some (set (reg:HI) (unspec:HI
> (const_int ...) UNSPEC_MVE_PRED)) insn that expands like (set (reg:HI)
> (const_int ...)) but the
> optimizers don't know that.
Indeed, it ICEs e.g. during CSE.
Though, that also means it is just about luck, if something isn't a CONST_INT
at expansion time but simplified into CONST_INT later, it can ICE as well.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #24 from Jakub Jelinek ---
Another short term (14.1 only) possibility would be to force_reg a CONST_INT
operand into a register if it didn't have all bits the same (and hope combine
or whatever else won't simplify it again), i.e.
else if (VALID_MVE_PRED_MODE (mode))
{
if (CONST_INT_P (x) && (mode == V8BImode || mode == V4BImode))
{
/* In V8BI or V4BI each element has 2 or 4 bits, if those
bits aren't all the same, gen_lowpart might ICE. */
unsigned HOST_WIDE_INT xi = UINTVAL (xi);
if ((xi & 0x) != ((xi >> 1) & 0x)
|| (mode == V4BImode
&& (xi & 0x) != ((xi >> 2) & 0x)))
x = force_reg (HImode, x);
}
else if (SUBREG_P (x))
/* gen_lowpart on a SUBREG can ICE. */
x = force_reg (GET_MODE (x), x);
x = gen_lowpart (mode, x);
}
If that fixes just the ICE during expansion but ICEs during fwprop, combine
etc.,
then you might try (temporarily) harder and hide the constant from the
optimizers,
e.g. instead of using force_reg emit some (set (reg:HI) (unspec:HI (const_int
...) UNSPEC_MVE_PRED)) insn that expands like (set (reg:HI) (const_int ...))
but the
optimizers don't know that.
[Bug c++/114888] [14/15 Regression] ICE when cross compiling binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888 --- Comment #5 from Jakub Jelinek --- Though, I think both build_pointer_type and build_reference_type would segfault if it was called on NULL_TREE to_type, and I don't see any spot in the FE that would create pointer/reference types without those routines. SO I think just && type1 should be right.
[Bug c++/114888] [14/15 Regression] ICE when cross compiling binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
--- Comment #4 from Jakub Jelinek ---
(In reply to Patrick Palka from comment #3)
> Seems we're missing a dependence check in the sizeof / sizeof code:
>
> diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
> index e5a52dc2b39..284f6e29e36 100644
> --- a/gcc/cp/typeck.cc
> +++ b/gcc/cp/typeck.cc
> @@ -5500,7 +5500,7 @@ cp_build_binary_op (const op_location_t ,
> type0 = TREE_TYPE (type0);
> if (!TYPE_P (type1))
> type1 = TREE_TYPE (type1);
> - if (type0
> + if (type0 && type1
> && INDIRECT_TYPE_P (type0)
> && same_type_p (TREE_TYPE (type0), type1))
> {
Yeah, I was about to suggest that too (just with && on a separate line.
I wonder if TREE_TYPE (type0) could be NULL even when type0 is INDIRECT_TYPE_P,
if yes,
we should be testing also && TREE_TYPE (type0) after the INDIRECT_TYPE_P check.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #23 from Jakub Jelinek --- (In reply to Christophe Lyon from comment #22) > Sure, that's what I'm worried about. > > So we can: > - leave this as-is for gcc-14 (known bug) > > - commit what we discussed in #c15 #c16, (with an improved testcase as you > mentioned on the list,) thus at least temporarily forcing canonicalization > (preventing users from using 'weird' values) > > - possibly revisit this for gcc-15 by handling predicates differently This primarily needs to be ARM maintainer decision. Anyway, if the predicate is really always a byte predicate, then perhaps best representation would be to always use V16BImode for it and model it in the RTL patterns as VEC_SELECT of a subreg of the actual operation to V16QImode (and then subreg back). That might accurately model what the hw does. Or some UNSPECs with just HImode predicate and then hide what actually happens.
[Bug c++/114888] [14 Regression] ICE when cross compiling binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888 Jakub Jelinek changed: What|Removed |Added Summary|ICE when cross compiling|[14 Regression] ICE when |binutils|cross compiling binutils Target Milestone|--- |14.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org Last reconfirmed||2024-04-29 --- Comment #2 from Jakub Jelinek --- Started with r14-4793-gdad311874ac3b3cf4eca1c04f67cae80c953f7b8
