[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #40 from Jakub Jelinek --- For unsigned _BitInt(4) or unsigned _BitInt(2) we mask it whenever loading from memory or function argument or whatever other ABI specific spot (and also when storing because that is how RTL expects it; because of that we don't mask it when using it from say automatic variables where we know we've initialized it ourselves).
[Bug target/113766] ICE: in generate_insn, at config/riscv/riscv-vector-builtins.cc:4186 with (invalid?) __riscv_vfredosum_tu()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113766
--- Comment #3 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:9ec08782b45869b33fec2a8772c25118221208e3
commit r14-8875-g9ec08782b45869b33fec2a8772c25118221208e3
Author: Pan Li
Date: Wed Feb 7 16:34:46 2024 +0800
RISC-V: Bugfix for RVV overloaded intrinsic ICE in function checker
There is another corn case when similar as below example:
void test (void)
{
__riscv_vaadd ();
}
We report error when overloaded function with empty args. For example:
test.c: In function 'foo':
test.c:8:3: error: no matching function call to '__riscv_vaadd' with empty
args
8 | __riscv_vaadd ();
| ^~~~
Unfortunately, it will meet another ICE similar to below after above
message. The underlying build function checker will have zero args
and break some assumption of the function checker. For example, the
count of args is not less than 2.
ice.c: In function âfooâ:
ice.c:8:3: internal compiler error: in require_immediate, at
config/riscv/riscv-vector-builtins.cc:4252
8 | __riscv_vaadd ();
| ^
0x20b36ac riscv_vector::function_checker::require_immediate(unsigned
int, long, long) const
.../__RISC-V_BUILD__/../gcc/config/riscv/riscv-vector-builtins.cc:4252
0x20b890c riscv_vector::alu_def::check(riscv_vector::function_checker&)
const
.../__RISC-V_BUILD__/../gcc/config/riscv/riscv-vector-builtins-shapes.cc:387
0x20b38d7 riscv_vector::function_checker::check()
.../__RISC-V_BUILD__/../gcc/config/riscv/riscv-vector-builtins.cc:4315
0x20b4876 riscv_vector::check_builtin_call(unsigned int, vec,
.../__RISC-V_BUILD__/../gcc/config/riscv/riscv-vector-builtins.cc:4605
0x2069393 riscv_check_builtin_call
.../__RISC-V_BUILD__/../gcc/config/riscv/riscv-c.cc:227
Below test are passed for this patch.
* The riscv regression tests.
PR target/113766
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-shapes.cc (struct alu_def):
Make
sure the c.arg_num is >= 2 before checking.
(struct build_frm_base): Ditto.
(struct narrow_alu_def): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr113766-1.c: Add new cases.
Signed-off-by: Pan Li
[Bug fortran/113797] Deferred length character concatenation in openmp region has wrong length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797 --- Comment #4 from Andrew Pinski --- (In reply to martin from comment #3) > typedef character(kind=1) struct > character(kind=1)[1:slen.1][1:slen.1]; > pstr.2 = 0B; > slen.1 = 0; Maybe the order here. slen.1 should be set to 0 before the use inside the typedef. That is kinda of the reason why static works (with not openmp).
[Bug fortran/113797] Deferred length character concatenation in openmp region has wrong length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797
--- Comment #3 from martin ---
Thanks for the patch, it does the job. But if I compile with
"gfortran-14 -fopenmp -Wuninitialized"
then I obtain
20 | out = concat_f('0123456 ', some()) // ' abc'
| ^
note: ‘slen.1’ declared here
So there still seems to be something amiss.
Here is the tree dump of the initial part of check(), where slen.1 is declared.
The problem might be the declaration of pstr.2?
__attribute__((fn spec (". r ")))
void check (integer(kind=4) & restrict i)
{
character(kind=1) out[1:15];
{
struct string D.4330;
struct string * D.4331;
integer(kind=8) slen.1;
character(kind=1)[1:slen.1] * pstr.2;
character(kind=1)[1:] * pstr.3;
void * restrict D.4336;
integer(kind=8) D.4337;
integer(kind=8) D.4338;
void * D.4339;
void * D.4340;
D.4330 = some ();
D.4331 =
typedef character(kind=1) struct character(kind=1)[1:slen.1][1:slen.1];
pstr.2 = 0B;
slen.1 = 0;
concat_f (, , &"0123456 "[1]{lb: 1 sz: 1}, D.4331, 8);
if (D.4331->chars != 0B)
{
__builtin_free ((void *) D.4331->chars);
D.4331->chars = 0B;
}
D.4336 = (void * restrict) __builtin_malloc (MAX_EXPR <(unsigned long)
(slen.1 + 4), 1>);
pstr.3 = (character(kind=1)[1:] *) D.4336;
_gfortran_concat_string (slen.1 + 4, pstr.3, slen.1, pstr.2, 4, &"
abc"[1]{lb: 1 sz: 1});
__builtin_free ((void *) pstr.2);
D.4337 = slen.1 + 4;
D.4338 = slen.1 + 4;
D.4339 = (void *)
D.4340 = (void *) pstr.3;
if (NON_LVALUE_EXPR <= 14)
{
__builtin_memmove (D.4339, D.4340, (unsigned long) NON_LVALUE_EXPR
);
__builtin_memset (D.4339 + (sizetype) NON_LVALUE_EXPR , 32,
(unsigned long) (15 - NON_LVALUE_EXPR ));
}
else
{
__builtin_memmove (D.4339, D.4340, 15);
}
__builtin_free ((void *) pstr.3);
}
...
[Bug fortran/113797] Deferred length character concatenation in openmp region has wrong length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-08 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed. Maybe this: ``` apinski@xeond:~/src/upstream-gcc/gcc/gcc/fortran$ git diff trans-expr.cc diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc index 218fede6a82..8ab7efe5740 100644 --- a/gcc/fortran/trans-expr.cc +++ b/gcc/fortran/trans-expr.cc @@ -7935,7 +7935,6 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym, tmp = len; if (!VAR_P (tmp)) tmp = gfc_evaluate_now (len, >pre); - TREE_STATIC (tmp) = 1; gfc_add_modify (>pre, tmp, build_int_cst (TREE_TYPE (tmp), 0)); tmp = gfc_build_addr_expr (NULL_TREE, tmp); ``` But I don't know the fortran front-end that well.
[Bug fortran/113797] Deferred length character concatenation in openmp region has wrong length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797
--- Comment #1 from Andrew Pinski ---
static integer(kind=8) slen.1;
inside
void check (integer(kind=4) & restrict i)
pstr.2 = 0B;
slen.1 = 0;
concat_f (, , &"0123456 "[1]{lb: 1 sz: 1}, D.4331, 8);
That is it used for the return value of concat_f.
I don't know why it is static but that is almost likely the cause of the issue
there.
[Bug c/113776] [14 regression] postgresql-16.1 build failure with -Werror=vla in configure test since r14-8641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776 --- Comment #6 from Sam James --- Thank you!
[Bug tree-optimization/113808] [14 Regression] FAIL: libgomp.fortran/non-rectangular-loop-1.f90 since r14-8768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
--- Comment #9 from Tamar Christina ---
(In reply to Richard Biener from comment #6)
> With the following I don't see things going wrong, but we end up with the
> loop
> having the STOP exit last instead and thus a PEELED case.
If it's not a PEELED case than the code is wrong indeed.
_100 = BIT_FIELD_REF ;
k.4_43 = _100;
is wrong since for a normal case the primary exit needs to do a last reduction
rather than a first.
_109 = BIT_FIELD_REF ;
_48 = _109;
_100 = BIT_FIELD_REF ;
k.4_43 = _100;
these two reduction orders should never be different.
The bug seems to be in vectorizable_live_operations where we determine if the
index needs to be a first or last reduction.
There's a boolean there
restart_loop = restart_loop || !main_exit_edge;
and we initially set it to
bool restart_loop = LOOP_VINFO_EARLY_BREAKS_VECT_PEELED (loop_vinfo);
outside the USE/DEF loop.
The problem is this depends on seeing the uses for the LOOP_VINFO_IV_EXIT
before seeing that of the early exits.
The code goes wrong because we see the early exit first and then see the main
exit, but once true the boolean can't become false again.
it's a silly bug, the boolean shouldn't be cached between loop iters.
quick hack:
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 190df9ec774..109a7e16abb 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -10966,7 +10966,7 @@ vectorizable_live_operation (vec_info *vinfo,
stmt_vec_info stmt_info,
/* For early exit where the exit is not in the BB that leads
to the latch then we're restarting the iteration in the
scalar loop. So get the first live value. */
- restart_loop = restart_loop || !main_exit_edge;
+ restart_loop = !main_exit_edge;
if (restart_loop
&& STMT_VINFO_DEF_TYPE (stmt_info) == vect_induction_def)
{
works but will revisit this and fix properly now.
Thanks for the reduction.
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #39 from Hongtao Liu --- > > the question is whether that matches the semantics of GIMPLE (the padding > > is inverted, too), whether it invokes undefined behavior (don't do it - it > > seems for people using intrinsics that's what it is?) For the intrinisc, the instructions only care about lower bits, so it's not big issue? And it sounds like similar issue as _BitInt(4)/_BitInt(2), I assume there're garbage in the upper bits.
[Bug target/113822] New: aarch64_evpc_reencode could/should use new_shrunk_vector instead of manually doing it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113822
Bug ID: 113822
Summary: aarch64_evpc_reencode could/should use
new_shrunk_vector instead of manually doing it
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: internal-improvement
Severity: enhancement
Priority: P3
Component: target
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
The current code does:
```
/* Convert the perm constant if we can. Require even, odd as the pairs. */
for (unsigned int i = 0; i < nelt; i += 2)
{
poly_int64 elt0 = d->perm[i];
poly_int64 elt1 = d->perm[i + 1];
poly_int64 newelt;
if (!multiple_p (elt0, 2, ) || maybe_ne (elt0 + 1, elt1))
return false;
newpermconst.quick_push (newelt.to_constant ());
}
newpermconst.finalize ();
```
But that is just:
```
vec_perm_indices newpermindices;
if (!newpermindices.new_shrunk_vector(d->perm, 2))
return false;
...
newd.perm.new_vector (newpermindices.encoding (), d.one_vector_p ? 1 : 2,
newpermindices.nelts_per_input ());
```
Filing so I remember to make this change. Note I noticed this while
implementing V2HI/V4QI support.
[Bug target/113715] RISC-V: If the Zcmp is enabled, the a0 register operates abnormally when the program returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113715 --- Comment #3 from Huaqi --- (In reply to Andrew Pinski from comment #2) > Yes this is where shrink wrapping incorrects incorrectly with > riscv_zcmp_can_use_popretz optimization. Basically popretz should be > disabled for shrink wrapped function call I think ... Maybe just revert this commit is a good approach for now, it won't affect other functions, and later on someone upload new patch to implement this cm.popretz generation
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #14 from Matthias Klose --- the proposed patch also fixes the arm-linux-gnueabi build (armv5t)
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #38 from Hongtao Liu --- > I think we should also mask off the upper bits of variable mask? > > notl%esi > orl %esi, %edi > notl%edi > andl$15, %edi > je .L3 with -mbmi, it's andn%esi, %edi, %edi andl$15, %edi je .L3
[Bug c/113776] [14 regression] postgresql-16.1 build failure with -Werror=vla in configure test since r14-8641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776 Joseph S. Myers changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Joseph S. Myers --- Fixed for GCC 14.
[Bug c/113776] [14 regression] postgresql-16.1 build failure with -Werror=vla in configure test since r14-8641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776 --- Comment #4 from GCC Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:bfd72bb44eca83b0db2b0bab895f27a8a44247a2 commit r14-8874-gbfd72bb44eca83b0db2b0bab895f27a8a44247a2 Author: Joseph Myers Date: Thu Feb 8 01:34:09 2024 + c: Fix boolean conversion of floating constant as integer constant expression [PR113776] My fix for bug 111059 and bug 111911 caused a conversion of a floating constant to boolean to wrongly no longer be considered an integer constant expression, because logic to insert a NOP_EXPR in c_objc_common_truthvalue_conversion for an argument not an integer constant expression itself now took place after rather than before the conversion to bool. In the specific case of casting a floating constant to bool, the result is an integer constant expression even though the argument isn't (build_c_cast deals with ensuring that casts to integer type of anything of floating type more complicated than a single floating constant don't get wrongly treated as integer constant expressions even if they fold to constants), so fix the logic in c_objc_common_truthvalue_conversion to handle that special case. Bootstrapped with no regressions for x86_64-pc-linux-gnu. PR c/113776 gcc/c * c-typeck.cc (c_objc_common_truthvalue_conversion): Return an integer constant expression for boolean conversion of floating constant. gcc/testsuite/ * gcc.dg/pr113776-1.c, gcc.dg/pr113776-2.c, gcc.dg/pr113776-3.c, gcc.dg/pr113776-4.c: New tests.
[Bug c/111911] [11/12/13 Regression] ICE with integer overflow converting to _Bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111911 --- Comment #9 from GCC Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:bfd72bb44eca83b0db2b0bab895f27a8a44247a2 commit r14-8874-gbfd72bb44eca83b0db2b0bab895f27a8a44247a2 Author: Joseph Myers Date: Thu Feb 8 01:34:09 2024 + c: Fix boolean conversion of floating constant as integer constant expression [PR113776] My fix for bug 111059 and bug 111911 caused a conversion of a floating constant to boolean to wrongly no longer be considered an integer constant expression, because logic to insert a NOP_EXPR in c_objc_common_truthvalue_conversion for an argument not an integer constant expression itself now took place after rather than before the conversion to bool. In the specific case of casting a floating constant to bool, the result is an integer constant expression even though the argument isn't (build_c_cast deals with ensuring that casts to integer type of anything of floating type more complicated than a single floating constant don't get wrongly treated as integer constant expressions even if they fold to constants), so fix the logic in c_objc_common_truthvalue_conversion to handle that special case. Bootstrapped with no regressions for x86_64-pc-linux-gnu. PR c/113776 gcc/c * c-typeck.cc (c_objc_common_truthvalue_conversion): Return an integer constant expression for boolean conversion of floating constant. gcc/testsuite/ * gcc.dg/pr113776-1.c, gcc.dg/pr113776-2.c, gcc.dg/pr113776-3.c, gcc.dg/pr113776-4.c: New tests.
[Bug c/111059] [11/12/13 Regression] ICE: in gimplify_expr, at gimplify.cc:17253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111059 --- Comment #8 from GCC Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:bfd72bb44eca83b0db2b0bab895f27a8a44247a2 commit r14-8874-gbfd72bb44eca83b0db2b0bab895f27a8a44247a2 Author: Joseph Myers Date: Thu Feb 8 01:34:09 2024 + c: Fix boolean conversion of floating constant as integer constant expression [PR113776] My fix for bug 111059 and bug 111911 caused a conversion of a floating constant to boolean to wrongly no longer be considered an integer constant expression, because logic to insert a NOP_EXPR in c_objc_common_truthvalue_conversion for an argument not an integer constant expression itself now took place after rather than before the conversion to bool. In the specific case of casting a floating constant to bool, the result is an integer constant expression even though the argument isn't (build_c_cast deals with ensuring that casts to integer type of anything of floating type more complicated than a single floating constant don't get wrongly treated as integer constant expressions even if they fold to constants), so fix the logic in c_objc_common_truthvalue_conversion to handle that special case. Bootstrapped with no regressions for x86_64-pc-linux-gnu. PR c/113776 gcc/c * c-typeck.cc (c_objc_common_truthvalue_conversion): Return an integer constant expression for boolean conversion of floating constant. gcc/testsuite/ * gcc.dg/pr113776-1.c, gcc.dg/pr113776-2.c, gcc.dg/pr113776-3.c, gcc.dg/pr113776-4.c: New tests.
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #37 from Hongtao Liu ---
(In reply to Richard Biener from comment #36)
> For example with AVX512VL and the following, using -O -fgimple -mavx512vl
> we get simply
>
> notl%esi
> orl %esi, %edi
> cmpb$15, %dil
> je .L6
>
> typedef long v4si __attribute__((vector_size(4*sizeof(long;
> typedef v4si v4sib __attribute__((vector_mask));
> typedef _Bool sbool1 __attribute__((signed_bool_precision(1)));
>
> void __GIMPLE (ssa) foo (v4sib v1, v4sib v2)
> {
> v4sib tem;
>
> __BB(2):
> tem_5 = ~v2_2(D);
> tem_3 = v1_1(D) | tem_5;
> tem_4 = _Literal (v4sib) { _Literal (sbool1) -1, _Literal (sbool1) -1,
> _Literal (sbool1) -1, _Literal (sbool1) -1 };
> if (tem_3 == tem_4)
> goto __BB3;
> else
> goto __BB4;
>
> __BB(3):
> __builtin_abort ();
>
> __BB(4):
> return;
> }
>
>
> the question is whether that matches the semantics of GIMPLE (the padding
> is inverted, too), whether it invokes undefined behavior (don't do it - it
> seems for people using intrinsics that's what it is?) or whether we
> should avoid affecting padding.
>
> Note after the patch I proposed on the mailing list the constant mask is
> now expanded with zero padding.
I think we should also mask off the upper bits of variable mask?
notl%esi
orl %esi, %edi
notl%edi
andl$15, %edi
je .L3
[Bug target/113764] [X86] Generates lzcnt when bsr is sufficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113764
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-02-08
--- Comment #1 from Roger Sayle ---
Confirmed. This issue has two parts. The first is that the bsr_1 pattern (and
variants) is (are) conditional on !TARGET_LZCNT, so the bsrl instruction isn't
currently available with -mlzcnt. The second is that the middle-end doesn't
have a preferred canonical RTL representation for this idiom, but all three of
the following equivalent functions should generate identical code:
unsigned bsr1(unsigned x) { return __builtin_clz(x) ^ 31; }
unsigned bsr2(unsigned x) { return 31 - __builtin_clz(x); }
unsigned bsr3(unsigned x) { return ~__builtin_clz(x) & 31; }
[Note that the tree-ssa optimizers do transform bsr3 into bsr1].
A suitable fix would be to add the equivalent clz(x)^31 variant pattern to
i386.md as a "synonymous" define_insn pattern.
[Bug c++/63164] unnecessary calls to __dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164 Andrew Pinski changed: What|Removed |Added CC||janschultke at googlemail dot com --- Comment #7 from Andrew Pinski --- *** Bug 113821 has been marked as a duplicate of this bug. ***
[Bug c++/113821] Missed optimization for final classes: expensive check for result of dynamic cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113821 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 63164. *** This bug has been marked as a duplicate of bug 63164 ***
[Bug c++/113821] Missed optimization for final classes: expensive check for result of dynamic cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113821 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug c++/113821] New: Missed optimization for final classes: expensive check for result of dynamic cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113821
Bug ID: 113821
Summary: Missed optimization for final classes: expensive check
for result of dynamic cast
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janschultke at googlemail dot com
Target Milestone: ---
Code to reproduce (https://godbolt.org/z/48cabYT78)
===
struct Base {
virtual ~Base() = default;
};
struct Derived final : Base {};
bool is_derived(Base& a) {
return dynamic_cast();
}
Expected output (clang)
===
is_derived(Base&):
lea rax, [rip + vtable for Derived+16]
cmp qword ptr [rdi], rax
seteal
ret
Actual output (GCC)
===
is_derived(Base&):
sub rsp, 8
xor ecx, ecx
mov edx, OFFSET FLAT:typeinfo for Derived
mov esi, OFFSET FLAT:typeinfo for Base
call__dynamic_cast
testrax, rax
setne al
add rsp, 8
ret
Explanation
===
For final classes, checking for success of dynamic_cast is equivalent to
checking whether the vtable pointer equals that of the destination type.
GCC is overly pessimistic by calling __dynamic_cast, which is much more
expensive, I'd imagine. Clang emits the same kind of pessimistic code only when
Derived is not final.
[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #14 from Alan Modra --- (In reply to Kewen Lin from comment #11) > I wonder if assembler can enable POWER7 when PPCVSX gets enabled like what > gcc adopts now? That wouldn't be a solution, because gcc needs to deal with older assemblers that won't have such a change. I don't have a strong opinion on whether newer versions of gas ought to enable all power7 instructions when given -mvsx, but I can say that -mvsx followed the precedent of other similar options, eg. -maltivec, -mlsp, where the option adds instructions for some function unit to the current cpu supported.
[Bug fortran/113799] gfc_replace_expr: double free detected ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799 --- Comment #5 from anlauf at gcc dot gnu.org --- Even worse: it's the unary minus: print *, -someInf pr113799.f90:5:19: 5 | print *, -someInf | 1 Error: Arithmetic overflow at (1) free(): invalid pointer f951: internal compiler error: Aborted
[Bug fortran/113799] gfc_replace_expr: double free detected ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799 --- Comment #4 from anlauf at gcc dot gnu.org --- It's the simplification of minval: program p implicit none real, parameter :: inf = real(z'7F80') real, parameter :: someInf(*) = [inf, 0.] print *, minval(-someInf) end pr113799.f90:5:26: 5 | print *, minval(-someInf) | 1 Error: Arithmetic overflow at (1) free(): invalid pointer f951: internal compiler error: Aborted 0x10e0f3f crash_signal ../../gcc-trunk/gcc/toplev.cc:317 0x99d4f8 gfc_replace_expr(gfc_expr*, gfc_expr*) ../../gcc-trunk/gcc/fortran/expr.cc:640 0x99d4f8 simplify_intrinsic_op ../../gcc-trunk/gcc/fortran/expr.cc:1324 0x99d4f8 gfc_simplify_expr(gfc_expr*, int) ../../gcc-trunk/gcc/fortran/expr.cc:2320 0xa2c469 resolve_operator ../../gcc-trunk/gcc/fortran/resolve.cc:4605 0xa288c5 gfc_resolve_expr(gfc_expr*) ../../gcc-trunk/gcc/fortran/resolve.cc:7342 [...]
[Bug libstdc++/113074] std::to_address should be SFINAE safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074 --- Comment #13 from Jonathan Wakely --- It looks like libc++ did it for this reason: [libc++] Fix a hard error in `contiguous_iterator`. Evaluating `contiguous_iterator` on an iterator that satisfies all the constraints except the `to_address` constraint and doesn't have `operator->` defined results in a hard error. This is because instantiating `to_address` ends up instantiating templates dependent on the given type which might lead to a hard error even in a SFINAE context. Differential Revision: https://reviews.llvm.org/D130835 As I said in comment 7, LWG considered this case and it was pointed out that the problem described can only occur if a type defines iterator_concept = contiguous_iterator; but then fails to actually provide the operations needed for a contiguous iterator (i.e. either a pointer_traits specialization with to_address or a sane operator->()). A SFINAE-friendly std::to_address as implemented in libc++ means that such an iterator will fail to satisfy std::contiguous_iterator and will silently degrade to satosfying std::random_access_iterator only. It's not at all clear to me that silently degrading such an iterator (which very explicitly claims to be a contiguous iterator by defining iterator_concept to say so) would be an improvement. I'd rather get an error telling me the thing I thought was a contiguous iterator was not actually.
[Bug testsuite/113085] New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085
--- Comment #5 from seurer at gcc dot gnu.org ---
I should note that pinned-2 also fails on powerpc64 LE.
make -k check-target-libgomp RUNTESTFLAGS="c.exp=libgomp.c/alloc-pinned-*"
FAIL: libgomp.c/alloc-pinned-1.c execution test
FAIL: libgomp.c/alloc-pinned-2.c execution test
On powerpc64 BE pinned-3 and -4 fail (but not -1 and -2):
make -k check-target-libgomp RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
c.exp=libgomp.c/alloc-pinned-*"
FAIL: libgomp.c/alloc-pinned-3.c execution test
FAIL: libgomp.c/alloc-pinned-4.c execution test
[Bug testsuite/111462] [14 regression] gcc.dg/tree-ssa/ssa-sink-18.c fails after r14-4089-gd45ddc2c04e471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111462
seurer at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED|REOPENED
--- Comment #11 from seurer at gcc dot gnu.org ---
I goofed on the original report as this also failed (and still does) on
powerpc64 BE. The patch fixed things on LE.
make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
tree-ssa.exp=gcc.dg/tree-ssa/ssa-sink-18.c"
FAIL: gcc.dg/tree-ssa/ssa-sink-18.c scan-tree-dump-times sink2 "Sunk
statements: 5" 1
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 Andrew Pinski changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #13 from Andrew Pinski --- *** Bug 113820 has been marked as a duplicate of this bug. ***
[Bug d/113820] [14 Regression] libdruntime fails to build on arm-linux-gnueabi (armv5t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113820 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 113772. *** This bug has been marked as a duplicate of bug 113772 ***
[Bug middle-end/113205] [14 Regression] internal compiler error: in backward_pass, at tree-vect-slp.cc:5346 since r14-3220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
--- Comment #7 from Jakub Jelinek ---
-fno-tree-slp-vectorize, either on the command line for the affected
compilation unit or __attribute__((optimize ("no-tree-slp-vectorize"))) on the
problematic routine.
--- Comment #8 from Andrew Pinski ---
(In reply to Sérgio Basto from comment #6)
> and any workaround to build mlt on x86_64 ,exist ?
>
> I tried disable lto, hardening and also disable strict symbols (-Wl,-z,defs
> ) and still not build neither in koji nor in my machine
`-fno-tree-slp-vectorize` should work around it ...
but that only works around the issue on the trunk which will be fixed by the
time release happens.
[Bug middle-end/113205] [14 Regression] internal compiler error: in backward_pass, at tree-vect-slp.cc:5346 since r14-3220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
--- Comment #7 from Jakub Jelinek ---
-fno-tree-slp-vectorize, either on the command line for the affected
compilation unit or __attribute__((optimize ("no-tree-slp-vectorize"))) on the
problematic routine.
[Bug c/113776] [14 regression] postgresql-16.1 build failure with -Werror=vla in configure test since r14-8641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jsm28 at gcc dot gnu.org Last reconfirmed||2024-02-07 Ever confirmed|0 |1 --- Comment #3 from Joseph S. Myers --- Testing a patch.
[Bug d/113820] New: [14 Regression] libdruntime fails to build on arm-linux-gnueabi (armv5t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113820 Bug ID: 113820 Summary: [14 Regression] libdruntime fails to build on arm-linux-gnueabi (armv5t) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with trunk 20240107, worked with 20240201 before the last merge from D upstream: libtool: compile: /home/packages/cross/14/p/gcc-cross-ports/gcc/build/./gcc/gdc -B/home/package s/cross/14/p/gcc-cross-ports/gcc/build/./gcc/ -B/usr/arm-linux-gnueabi/bin/ -B/usr/arm-linux-gnu eabi/lib/ -isystem /usr/arm-linux-gnueabi/include -isystem /usr/arm-linux-gnueabi/sys-include -i system /home/packages/cross/14/p/gcc-cross-ports/gcc/build/sys-include -fversion=Shared -Wall -f release -ffunction-sections -fdata-sections -O2 -g -fpreview=dip1000 -fpreview=fieldwise -fprevi ew=dtorfields -nostdinc -I ../../../../src/libphobos/libdruntime -I . -c ../../../../src/libphob os/libdruntime/core/stdc/stdarg.d -fPIC -fversion=Shared -o core/stdc/stdarg.o >/dev/null 2>&1 /home/packages/cross/14/p/gcc-cross-ports/gcc/src/libphobos/libdruntime/core/internal/atomic.d:6 12:53: error: cannot evaluate unimplemented builtin '__atomic_is_lock_free' at compile time 612 | enum IsAtomicLockFree(T) = __atomic_is_lock_free(T.sizeof, null); | ^ ../../../../src/libphobos/libdruntime/core/stdc/stdatomic.d:65:30: error: template instance 'cor e.internal.atomic.IsAtomicLockFree!ulong' error instantiating 65 | ATOMIC_LLONG_LOCK_FREE = IsAtomicLockFree!ulong ? 2 : 0, | ^ checking for gethostname... make[7]: *** [Makefile:2580: core/stdc/stdatomic.lo] Error 1
[Bug fortran/113799] gfc_replace_expr: double free detected ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Mikael Morin from comment #2) > Reproduced with all versions I have here (14.0, 13.2, 12.3, 11.4 and 10.5). ... but passes with -fno-range-check ...
[Bug middle-end/113205] [14 Regression] internal compiler error: in backward_pass, at tree-vect-slp.cc:5346 since r14-3220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205 --- Comment #6 from Sérgio Basto --- and any workaround to build mlt on x86_64 ,exist ? I tried disable lto, hardening and also disable strict symbols (-Wl,-z,defs ) and still not build neither in koji nor in my machine
[Bug libstdc++/113074] std::to_address should be SFINAE safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074 --- Comment #12 from Jonathan Wakely --- (In reply to Peter Kasting from comment #10) > When Jose reported this issue in Chromium I pushed back on fixing on our > side because I thought libstdc++ had the same issue. But this is a distinct > issue; std::to_address<> is not required to be SFINAE-compatible even if > std::pointer_traits<> now is. Right, LWG 3545 did not touch std::to_address.
[Bug fortran/113793] malloc abort on character allocate with source argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793 --- Comment #2 from anlauf at gcc dot gnu.org --- Created attachment 57354 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57354=edit Tentative partial patch This appears to fix the malloc size for character arrays, but not for allocatable scalars, like in: program p implicit none CHARACTER*30,allocatable :: a(:), b(:,:), d CHARACTER(kind=4,len=15),allocatable :: c(:), e ALLOCATE (a(100),source=" ") ! OK ALLOCATE (b(5,6),source=" ") ! OK ALLOCATE (c(42), source=4_"zzz") ! OK ALLOCATE (d,source="xx") ! malloc too small ALLOCATE (e,source=4_"zz") ! malloc too small END
[Bug libstdc++/113074] std::to_address should be SFINAE safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #11 from Jonathan Wakely ---
(In reply to Peter Kasting from comment #8)
> There's currently no simple and blessed route for consumers to convert
> raw-or-fancy-pointer input types to raw pointers.
I disagree, std::to_address does exactly that.
The problem here seems to be that Chromium is expecting it to do more than
that.
Given a raw-or-fancy-pointer std::to_address will turn it into a raw pointer.
What the testcase above seems to be trying to do is to use std::to_address as a
proxy for answering the question "is this a raw or fancy pointer". That's not
what it's for.
Can't you use something like this to check that instead?
template
concept IsPointerLike = requires { typename std::pointer_traits::pointer; }
|| requires (const T& t) { t.operator->(); };
[Bug libstdc++/113074] std::to_address should be SFINAE safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074 --- Comment #10 from Peter Kasting --- (In reply to Jonathan Wakely from comment #9) > (In reply to Andrew Pinski from comment #5) > > Created attachment 56905 [details] > > testcase which shows libc++ and libstdc++ difference > > > > with libstdc++, both GCC and clang reject this. > > with libc++, clang accepts this (I only tested clang because it was the > > easiest to test there). > > AFAICT only libc++ from llvm trunk accepts this, even 17.0.1 gives an error > outside the immediate context, like libstdc++ does. Yes, but that was because libc++ did not implement LWG3545 until LLVM 18. When Jose reported this issue in Chromium I pushed back on fixing on our side because I thought libstdc++ had the same issue. But this is a distinct issue; std::to_address<> is not required to be SFINAE-compatible even if std::pointer_traits<> now is.
[Bug libstdc++/113074] std::to_address should be SFINAE safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074 --- Comment #9 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #5) > Created attachment 56905 [details] > testcase which shows libc++ and libstdc++ difference > > with libstdc++, both GCC and clang reject this. > with libc++, clang accepts this (I only tested clang because it was the > easiest to test there). AFAICT only libc++ from llvm trunk accepts this, even 17.0.1 gives an error outside the immediate context, like libstdc++ does.
[Bug libstdc++/113792] error: '__size_t' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792 --- Comment #5 from Jonathan Wakely --- https://gcc.gnu.org/pipermail/gcc-patches/2016-January/439448.html described the reason for the current approach.
[Bug libstdc++/113792] error: '__size_t' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792 --- Comment #4 from Jonathan Wakely --- And we have the same pattern in include/c_global/cmath and include/bits/std_abs.h so I'm also very reluctant to change just one.
[Bug libstdc++/113792] error: '__size_t' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792 --- Comment #3 from Jonathan Wakely --- (In reply to John David Anglin from comment #0) > stdlib.h is fixed on this target. The #include_next pulled stdlib.h > from /usr/include instead of ./prev-gcc/include-fixed/stdlib.h. Why did that happen? For my systems, the include search list is: ignoring nonexistent directory "/home/jwakely/gcc/14/lib/gcc/x86_64-pc-linux-gnu/14.0.1/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/jwakely/src/benchmark/include/ /home/jwakely/gcc/14/lib/gcc/x86_64-pc-linux-gnu/14.0.1/../../../../include/c++/14.0.1 /home/jwakely/gcc/14/lib/gcc/x86_64-pc-linux-gnu/14.0.1/../../../../include/c++/14.0.1/x86_64-pc-linux-gnu /home/jwakely/gcc/14/lib/gcc/x86_64-pc-linux-gnu/14.0.1/../../../../include/c++/14.0.1/backward /home/jwakely/gcc/14/lib/gcc/x86_64-pc-linux-gnu/14.0.1/include /usr/local/include /home/jwakely/gcc/14/include /home/jwakely/gcc/14/lib/gcc/x86_64-pc-linux-gnu/14.0.1/include-fixed /usr/include End of search list. Why is /usr/include coming before the include-fixed dir? That seems wrong. I'm extremely reluctant to fiddle with the (historically fragile) ordering between the headers and headers without understanding exactly what's happening here, and why.
[Bug middle-end/113415] ICE: RTL check: -mstringop-strategy=byte_loop vs inline-asm goto with block copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415 --- Comment #5 from Andrew Pinski --- *** Bug 113819 has been marked as a duplicate of this bug. ***
[Bug target/113819] ICE: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx code_label) in PATTERN, at rtl.h:1511 with -mstringop-strategy=loop and asm goto with impossible constraint and _BitIn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113819 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- >This might need RTL checking enabled. It does and it is a dup of bug 113415, that is it is the same issue as PR 113415 . *** This bug has been marked as a duplicate of bug 113415 ***
[Bug tree-optimization/113818] ICE: verify_gimple failed: missing 'PHI' def with -Os -fnon-call-exceptions -finstrument-functions-once and _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113818 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-02-07 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. I tried to get a similar IR with cleanup attribute instead of -finstrument-functions-once but I could not due to cleanup's try/finally being wrapped via the one for clobbers rather than on the outside.
[Bug target/113819] New: ICE: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx code_label) in PATTERN, at rtl.h:1511 with -mstringop-strategy=loop and asm goto with impossible constraint and _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113819
Bug ID: 113819
Summary: ICE: RTL check: expected elt 3 type 'e' or 'u', have
'0' (rtx code_label) in PATTERN, at rtl.h:1511 with
-mstringop-strategy=loop and asm goto with impossible
constraint and _BitInt()
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 57353
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57353=edit
reduced testcase (from gcc.dg/torture/pr100398.c)
This might need RTL checking enabled.
Compiler output:
$ x86_64-pc-linux-gnu-gcc -mstringop-strategy=loop testcase.c
during RTL pass: expand
testcase.c: In function 'test5_limit':
testcase.c:4:3: internal compiler error: RTL check: expected elt 3 type 'e' or
'u', have '0' (rtx code_label) in PATTERN, at rtl.h:1511
4 | __asm__ goto("" : "=r"(addr) : : : t_err);
| ^~~
0x8072bd rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/repo/gcc-trunk/gcc/rtl.cc:761
0x72a1a4 PATTERN(rtx_def*)
/repo/gcc-trunk/gcc/rtl.h:1511
0x72cd2d PATTERN(rtx_def*)
/repo/gcc-trunk/gcc/rtl.h:1479
0x72cd2d expand_asm_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:3681
0xf845a9 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3923
0xf845a9 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4071
0xf8b3be expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6127
0xf8d097 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6866
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8869-20240207154951-g8636c538b68-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8869-20240207154951-g8636c538b68-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240207 (experimental) (GCC)
[Bug tree-optimization/113818] New: ICE: verify_gimple failed: missing 'PHI' def with -Os -fnon-call-exceptions -finstrument-functions-once and _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113818 Bug ID: 113818 Summary: ICE: verify_gimple failed: missing 'PHI' def with -Os -fnon-call-exceptions -finstrument-functions-once and _BitInt() Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57352 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57352=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -Os -fnon-call-exceptions -finstrument-functions-once testcase.c testcase.c: In function 'foo': testcase.c:9:1: error: missing 'PHI' def 9 | foo (void) | ^~~ testcase.c:9:1: error: missing 'PHI' def testcase.c:9:1: error: missing 'PHI' def finally_tmp.7_7 = PHI <0(5), 2(10), 1(9), (8), (6), (7)> during GIMPLE pass: bitintlower testcase.c:9:1: internal compiler error: verify_gimple failed 0x155b7cd verify_gimple_in_cfg(function*, bool, bool) /repo/gcc-trunk/gcc/tree-cfg.cc:5666 0x13cac94 execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2088 0x13cb1ee execute_todo /repo/gcc-trunk/gcc/passes.cc:2142 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8869-20240207154951-g8636c538b68-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-8869-20240207154951-g8636c538b68-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240207 (experimental) (GCC)
[Bug tree-optimization/113731] [14 regression] ICE when building libbsd since r14-8768-g85094e2aa6dba7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113731 Sam James changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #13 from Sam James --- *** Bug 113817 has been marked as a duplicate of this bug. ***
[Bug c/113817] ice in move_early_exit_stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113817 Sam James changed: What|Removed |Added Resolution|--- |DUPLICATE CC||sjames at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Sam James --- Please try a fresh build. *** This bug has been marked as a duplicate of bug 113731 ***
[Bug c/113817] New: ice in move_early_exit_stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113817
Bug ID: 113817
Summary: ice in move_early_exit_stmts
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
char enc_int_dst_orig;
long main_val;
char main_buf[20];
char *enc_int(char *dst, char *end, long value) {
while (value)
if (dst < end)
*dst++ = value >>= 7;
else
return _int_dst_orig;
*dst = 7;
}
void main() { enc_int(main_buf, main_buf + sizeof(main_buf), main_val); }
compiles ok as follows:
$ /home/dcb38/gcc/results.20240202.asan.ubsan/bin/gcc -c -O3 -march=znver3
~/cvise/bug1005.c
$
But a few days later:
$ /home/dcb38/gcc/results.20240205.asan.ubsan/bin/gcc -c -O3 -march=znver3
~/cvise/bug1005.c
during GIMPLE pass: vect
/home/dcb38/cvise/bug1005.c: In function ‘main’:
/home/dcb38/cvise/bug1005.c:12:6: internal compiler error: Segmentation fault
12 | void main() { enc_int(main_buf, main_buf + sizeof(main_buf), main_val);
}
| ^~~~
0xed44e9 crash_signal(int)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317
0x1186bd3 gsi_prev(gimple_stmt_iterator*)
../../trunk.20210101/gcc/gimple-iterator.h:236
0x1186bd3 move_early_exit_stmts(_loop_vec_info*)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/tree-vect-loop.cc:1
1804
$ /home/dcb38/gcc/results.20240202.asan.ubsan/bin/gcc -v 2>&1 | grep exp
gcc version 14.0.1 20240202 (experimental) (639bd5e9b759a6d7)
$ /home/dcb38/gcc/results.20240205.asan.ubsan/bin/gcc -v 2>&1 | grep exp
gcc version 14.0.1 20240205 (experimental) (5b281946c4b51132)
The git range is 40 commits.
[Bug libstdc++/113792] error: '__size_t' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792 --- Comment #2 from dave.anglin at bell dot net --- On 2024-02-07 2:43 a.m., redi at gcc dot gnu.org wrote: > Using #include definitely won't work, that would just create a cycle between > the libstdc++ versions of stdlib.h and cstdlib, at least for all targets that > don't have stdlib.h in include-fixed. Are you sure? The file punct.cc compiles successfully on hppa-unknown-linux-gnu using #include. It doesn't have stdlib.h in include-fixed. Doing a full build.
[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455 --- Comment #6 from Joseph S. Myers --- -frounding-math is only relevant for arithmetic that occurs as-if at runtime in the abstract machine. Conversion of constants to their type (or a type with excess range and precision as indicated by DEC_EVAL_METHOD, but (a) that doesn't apply here and (b) none of the excess precision support in GCC is hooked up for decimal floating point, I think) occurs at translation time, not at runtime, so is never affected by -frounding-math or fe_dec_setround (and GCC doesn't implement the FENV_DEC_ROUND pragma to set a constant rounding mode in a particular scope).
[Bug tree-optimization/113774] wrong code with _BitInt() arithmetics at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113774
--- Comment #3 from Jakub Jelinek ---
unsigned long long a[32], b[32], v[32], r[32];
void
foo (unsigned int n)
{
unsigned long long c = 0;
for (unsigned long i = 0; i < n; i += 2)
{
unsigned long j = i + 1;
b[i] = __builtin_addcll (b[i], v[i], c, );
b[j] = __builtin_addcll (b[j], v[j], c, );
}
b[4] = __builtin_addcll (b[4] & 1, v[4] & 1, c, ) & 1;
c = 0;
for (unsigned long i = 0; i < n; i += 2)
{
unsigned long j = i + 1;
unsigned long long k = i < 3 ? a[i] : 0;
r[i] = b[i] | __builtin_subcll (k, b[i], c, );
unsigned long long l = b[j];
if (j <= 3)
{
if (j == 3)
k = a[3] & 0x7fffULL;
else
k = a[3];
}
else
k = 0;
r[j] = l | __builtin_subcll (k, b[j], c, );
}
r[4] = (b[4] | __builtin_subcll (0, b[4] & 1, c, )) & 1;
}
might help understand better what bitintlower emits there, except it uses
PARM_DECLs or automatic VAR_DECLs instead of the global ones (except for v) and
n is 4 (I've used function argument only to avoid VRP figuring out earlier that
certain paths are dead) and the var sizes is actually just 4 (for a) or 5 elts.
That said, even _134 in the #c2 testcase at -O2 in the PHI argument is fishy,
but the
point is that bb 6 is really dead but it isn't known to the compiler yet; it is
reached if _49 <= 2 is false, but given that _49 is incremented in increments
of 2 and the array size is 5 maybe PRE knows that _49 then would have to be 4.
bb 6 either jumps directly to bb 10 (if _140 (aka _49 + 1) > 3) or hops through
bb 8 to bb 10.
[Bug target/113816] New: Using SVE bit op reduction for SLP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113816
Bug ID: 113816
Summary: Using SVE bit op reduction for SLP
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Take at `-march=armv9-a -O3`:
```
#define SIGN unsigned
#define TYPE int
#define SIZE 16
void sior(SIGN TYPE *a, SIGN TYPE *r)
{
SIGN TYPE b = 0;
b |= a[0];
b |= a[1];
b |= a[2];
b |= a[3];
b |= a[4];
*r = b;
}
void sxor(SIGN TYPE *a, SIGN TYPE *r)
{
SIGN TYPE b = 0;
b ^= a[0];
b ^= a[1];
b ^= a[2];
b ^= a[3];
b ^= a[4];
*r = b;
}
void sand(SIGN TYPE *a, SIGN TYPE *r)
{
SIGN TYPE b = -1;
b &= a[0];
b &= a[1];
b &= a[2];
b &= a[3];
b &= a[4];
*r = b;
}
```
These could use the SVE reduction instructions to handle (neon) SLP reductions
in a similar way 64bit multi isntructions are being used.
That is for srio GCC should produce:
```
ptrue p7.s, vl4
ldq q31, [x0]
orv s30, p7, z31.s
str s30, [x1]
```
(Hopefully I did this correctly)
[Bug libstdc++/113074] std::to_address should be SFINAE safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074 Peter Kasting changed: What|Removed |Added CC||pkasting at google dot com --- Comment #8 from Peter Kasting --- As a Chromium C++ OWNER -- agree that libstdc++ is standards-compliant as-is. We'll fix our code. I do think libc++'s behavior is more usable and an LWG issue would be nice. There's currently no simple and blessed route for consumers to convert raw-or-fancy-pointer input types to raw pointers.
[Bug ada/113815] New: error: there is no applicable operator "*" for a string type (possible regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113815 Bug ID: 113815 Summary: error: there is no applicable operator "*" for a string type (possible regression) Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: p.p11 at orange dot fr CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 57351 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57351=edit Reproducer. Result with GCC 13.2: $ gcc -v -c -gnatX test_20200613_decl.adb ... gcc version 13.2.0 (GCC) ... test_20200613_decl.adb:30:40: warning: value not in range of type "Roman_Number" defined at line 15 [enabled by default] test_20200613_decl.adb:30:40: warning: Constraint_Error will be raised at run time [enabled by default] test_20200613_decl.adb:35:33: error: there is no applicable operator "*" for a string type Expected result with GCC 12: $ gcc -v -c -gnatX test_20200613_decl.adb ... gcc version 12.2.0 (GCC) ... No error nor warning. See test_20200613_decl.adb in attached file.
[Bug c++/113814] [modules] canonical types ICE with imported partial specialization matching existing template-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113814 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Last reconfirmed||2024-02-07
[Bug fortran/113793] malloc abort on character allocate with source argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-02-07 Keywords||wrong-code Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- (In reply to Manfred Schwarb from comment #0) > Allocating an allocatable character array, I get a malloc error > when the source argument is not properly padded: > > CHARACTER*30,allocatable :: a(:),b(:) > ALLOCATE(a(100),source=" ") > ALLOCATE(b(100),source=" ") > END > > yields: > malloc(): corrupted top size Confirmed. > I would have expected that the source argument is automatically padded > as with variable assignments and function call arguments. The dump-tree shows that it is padded, but the actual malloc is too short: a.data = (void * restrict) __builtin_malloc (100); Omitting the source= part, we get the expected: a.data = (void * restrict) __builtin_malloc (3000);
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 113710, which changed state. Bug 113710 Summary: [14 Regression] g++.dg/modules/hello-1 ICE: canonical types differ for identical types since r14-8710-g65b4cba9d6a9ff https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113710 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug testsuite/113710] [14 Regression] g++.dg/modules/hello-1 ICE: canonical types differ for identical types since r14-8710-g65b4cba9d6a9ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113710 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Patrick Palka --- Fixed via a library-side workaround.
[Bug c++/113814] [modules] canonical types ICE with imported partial specialization matching existing template-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113814 --- Comment #1 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ff41862357ca2ea56177209a2e3b7d9c64bcfa8c commit r14-8870-gff41862357ca2ea56177209a2e3b7d9c64bcfa8c Author: Patrick Palka Date: Wed Feb 7 14:24:51 2024 -0500 libstdc++: Work around modules issue causing hello-1 ICE [PR113710] The forward declarations of std::get in added in r14-8710-g65b4cba9d6a9ff are causing an ICE in the test modules/hello-1 due to what seems to be a declaration merging issue in modules. What's happening is that in hello-1_b.C we first include , which indirectly includes which forms the dependent specialization tuple_element<__i, tuple<_Elements...>> (appearing in the signatures of some of the std::get overloads) and adds it to the specializations table. We then import hello which indirectly includes (in the GMF), within which we define a partial specialization of tuple_element with that same template-id. So importing hello in turn streams in this partial specialization but we don't merge it with the previously created dependent specialization, and we end up with two equivalent types for this template-id with different TYPE_CANONICAL. This patch works around this issue by adding a forward declaration of the tuple_element partial specialization from to so that it appears alongside the dependent specialization of the same template-id. So when including we immediately register the template-id as a partial specialization, and if we later stream in the partial specialization the MK_partial case of trees_in::key_mergeable will match them up. (So perhaps a proper modules fix for this might be to make key_mergeable try to match up a streamed in partial specialization with an existing specialization from the table via match_mergeable_specialization.) PR testsuite/113710 PR c++/113814 libstdc++-v3/ChangeLog: * include/bits/stl_pair.h (tuple_element): Add forward declaration of the partial specialization for tuple. Reviewed-by: Jonathan Wakely
[Bug testsuite/113710] [14 Regression] g++.dg/modules/hello-1 ICE: canonical types differ for identical types since r14-8710-g65b4cba9d6a9ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113710 --- Comment #6 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ff41862357ca2ea56177209a2e3b7d9c64bcfa8c commit r14-8870-gff41862357ca2ea56177209a2e3b7d9c64bcfa8c Author: Patrick Palka Date: Wed Feb 7 14:24:51 2024 -0500 libstdc++: Work around modules issue causing hello-1 ICE [PR113710] The forward declarations of std::get in added in r14-8710-g65b4cba9d6a9ff are causing an ICE in the test modules/hello-1 due to what seems to be a declaration merging issue in modules. What's happening is that in hello-1_b.C we first include , which indirectly includes which forms the dependent specialization tuple_element<__i, tuple<_Elements...>> (appearing in the signatures of some of the std::get overloads) and adds it to the specializations table. We then import hello which indirectly includes (in the GMF), within which we define a partial specialization of tuple_element with that same template-id. So importing hello in turn streams in this partial specialization but we don't merge it with the previously created dependent specialization, and we end up with two equivalent types for this template-id with different TYPE_CANONICAL. This patch works around this issue by adding a forward declaration of the tuple_element partial specialization from to so that it appears alongside the dependent specialization of the same template-id. So when including we immediately register the template-id as a partial specialization, and if we later stream in the partial specialization the MK_partial case of trees_in::key_mergeable will match them up. (So perhaps a proper modules fix for this might be to make key_mergeable try to match up a streamed in partial specialization with an existing specialization from the table via match_mergeable_specialization.) PR testsuite/113710 PR c++/113814 libstdc++-v3/ChangeLog: * include/bits/stl_pair.h (tuple_element): Add forward declaration of the partial specialization for tuple. Reviewed-by: Jonathan Wakely
[Bug testsuite/113710] [14 Regression] g++.dg/modules/hello-1 ICE: canonical types differ for identical types since r14-8710-g65b4cba9d6a9ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113710 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113814 Component|c++ |testsuite Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #5 from Patrick Palka --- Changed component to testsuite, and created PR113814 to track the front end bug specifically.
[Bug c++/113814] New: [modules] ICE with imported partial specialization matching existing template-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113814
Bug ID: 113814
Summary: [modules] ICE with imported partial specialization
matching existing template-id
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
Reduced from the hello-1 ICE tracked by PR113710:
$ cat header.h
template
struct tuple_element;
template
struct tuple { };
template
tuple_element<__i, tuple<_Elements...>>
get(tuple<_Elements...>);
$ cat testcase.H
#include "header.h"
template
struct tuple_element<__i, tuple<_Elements...>> { };
$ cat testcase.C
#include "header.h"
import "testcase.H"
int main() {
get<0>(tuple{});
}
$ g++ -fmodules-ts testcase.H testcase.C
testcase.C: In function ‘int main()’:
testcase.C:5:3: internal compiler error: canonical types differ for identical
types ‘tuple_element<__i, tuple<_Elements ...> >’ and ‘tuple_element<__i,
tuple<_Elements ...> >’
5 | get<0>(tuple{});
| ^~~
[Bug target/113813] New: Reduction of xor/and/ior of 16 bytes can be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113813
Bug ID: 113813
Summary: Reduction of xor/and/ior of 16 bytes can be improved
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Take:
```
#define SIGN unsigned
#define TYPE char
#define SIZE 16
void sor(SIGN TYPE *a, SIGN TYPE *r)
{
SIGN TYPE b = 0;
for(int i = 0; i < SIZE; i++)
b |= a[i];
*r = b;
}
void sxor(SIGN TYPE *a, SIGN TYPE *r)
{
SIGN TYPE b = 0;
for(int i = 0; i < SIZE; i++)
b ^= a[i];
*r = b;
}
void sand(SIGN TYPE *a, SIGN TYPE *r)
{
SIGN TYPE b = -1;
for(int i = 0; i < SIZE; i++)
b &= a[i];
*r = b;
}
```
Currently for sor GCC (at `-O3 -march=armv9-a+sve2 -fno-vect-cost-model`)
produces:
```
ptrue p7.b, vl16
ptrue p6.b, all
ld1bz31.b, p7/z, [x0]
mov z30.b, #0
sel z30.b, p7, z31.b, z30.b
orv b30, p6, z30.b
str b30, [x1]
```
But this could be improved to just:
```
ptrue p7.b, vl16
ld1bz31.b, p7/z, [x0]
orv b30, p7, z30.b
str b30, [x1]
```
Similarly for sxor/sand.
The same is true for short/int (8/4).
Note without -fno-vect-cost-model, it is just so much worse (on the trunk
only).
Note we should be able to use the SVE instruction when perfering NEON auto-vec
too.
[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
--- Comment #3 from Tobias Burnus ---
Inside omp_build_struct_sibling_lists, the following assignment:
11654 grp->grp_start = new_next;
has on the LHS the [3] array with value:
(gdb) p *grp
$147 = {grp_start = 0x771f9688, grp_end = 0x771f9630, mark = UNVISITED,
deleted = true, reprocess_struct = false, fragile = false, sibling = 0x0, next
= 0x0}
while
(gdb) p new_next
$146 = (tree *) 0x771f96d0
which causes the alias issue we are seeing. Before the assignment:
(gdb) p debug(*(tree*)0x771f9688)
map(tofrom:S1.b) map(tofrom:S1.p) map(tofrom:*S1.p [len: 400])
map(attach_detach:S1.p [bias: 0])
(gdb) p debug(*(tree*)0x771f96d0)
map(tofrom:S1.p) map(tofrom:*S1.p [len: 400]) map(attach_detach:S1.p [bias: 0])
[Bug tree-optimization/113774] wrong code with _BitInt() arithmetics at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113774
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC||rguenth at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-02-07
--- Comment #2 from Jakub Jelinek ---
/* PR tree-optimization/113774 */
/* { dg-do run { target bitint } } */
/* { dg-options "-std=c23 -pedantic-errors" } */
/* { dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O0" "-O2" } } */
/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
#if __BITINT_MAXWIDTH__ >= 512
unsigned _BitInt(512) u;
unsigned _BitInt(512) v;
void
foo (unsigned _BitInt(255) a, unsigned _BitInt(257) b, unsigned _BitInt(512)
*r)
{
b += v;
b |= a - b;
unsigned _BitInt(512) c = b * 6;
unsigned _BitInt(512) h = c >> u;
*r = h;
}
#endif
int
main ()
{
#if __BITINT_MAXWIDTH__ >= 512
unsigned _BitInt(512) x;
foo (0x1wb, 0x10001wb, );
if (x !=
0x1fffawb)
__builtin_abort ();
#endif
return 0;
}
This looks like a PRE bug to me.
The bug at runtime is that b |= a - b (i.e. the operand of the multiplication)
which ought to be
0x01uwb I think
is different.
What bitint lowering emits to compute this are 2 separate loops + straight line
code after each to handle the most significant limb of 257-bit unsigned
_BitInts.
The first computes b += v; and because v is 0, it doesn't change anything and
uses
the same underlying variable (the PARM_DECL) for both the input and result, the
second
one performs the b |= a - b which is complicated because there needs to be zero
extension from 255-bit a to 257 bits. This loop handles 2 limbs at a time, so
iterates twice:
[local count: 1073741824]:
# _49 = PHI <0(4), _50(11)>
# _55 = PHI <0(4), _56(11)>
_51 = VIEW_CONVERT_EXPR(b)[_49];
if (_49 < 3)
goto ; [80.00%]
else
goto ; [20.00%]
[local count: 1073741824]:
_52 = VIEW_CONVERT_EXPR(a)[_49];
[local count: 1073741824]:
# _53 = PHI <_52(6), 0(5)>
_54 = VIEW_CONVERT_EXPR(b)[_49];
_57 = .USUBC (_53, _54, _55);
_58 = IMAGPART_EXPR <_57>;
_59 = REALPART_EXPR <_57>;
_60 = _59 | _51;
bitint.6[_49] = _60;
_61 = _49 + 1;
_62 = VIEW_CONVERT_EXPR(b)[_61];
if (_61 <= 3)
goto ; [80.00%]
else
goto ; [20.00%]
[local count: 1073741824]:
if (_61 == 3)
goto ; [20.00%]
else
goto ; [80.00%]
[local count: 1073741824]:
_63 = VIEW_CONVERT_EXPR(a)[_61];
goto ; [100.00%]
[local count: 214748360]:
_64 = MEM [(unsigned _BitInt(255) *) + 24B];
_65 = () _64;
_66 = (unsigned long) _65;
[local count: 1073741824]:
# _67 = PHI <_63(9), 0(7), _66(10)>
_68 = VIEW_CONVERT_EXPR(b)[_61];
_69 = .USUBC (_67, _68, _58);
_56 = IMAGPART_EXPR <_69>;
_70 = REALPART_EXPR <_69>;
_71 = _70 | _62;
bitint.6[_61] = _71;
_50 = _49 + 2;
if (_50 != 4)
goto ; [0.05%]
else
goto ; [99.95%]
[local count: 1073741824]:
_72 = MEM [(unsigned _BitInt(257) *) + 32B];
_73 = () _72;
_74 = MEM [(unsigned _BitInt(257) *) + 32B];
_75 = () _74;
_76 = (unsigned long) _75;
_77 = .USUBC (0, _76, _56);
_78 = IMAGPART_EXPR <_77>;
_79 = REALPART_EXPR <_77>;
_80 = () _79;
_81 = _80 | _73;
_82 = (unsigned long) _81;
MEM[(unsigned long *) + 32B] = _82;
a ={v} {CLOBBER(eos)};
bitint.6 is the result of b | (zext (a) - b) which is then used as argument to
__mulbitint3.
Now, there is something I should improve, eventhough later optimizations like
VRP IMHO ought to be able to figure it out, because the loop iterates just
twice, _49 will be in the [0, 2] range (actually 0 or 2), so _49 < 3 condition
is actually always true and similarly _61 <= 3 is also always true (because _61
is in [1, 3] range (actually 1 or 3)).
Guess I should in the handle_cast handling look at the m_upwards_2limb exact
value and figure out conditions which will be always true or always false.
Anyway, with the above which is IMHO correct but non-optimal let's see what
happens to the processing of the second least significant limb, i.e. the second
half of the first iteration which is what is IMHO miscompiled during PRE.
First thread1 pass goes wild and threads everything it thinks it is possible to
thread.
The second least significant limb is handled in
# _67 = PHI <_63(8), 0(6)>
# _144 = PHI <_143(8), _136(6)>
# _146 = PHI <_145(8), _140(6)>
# _148 = PHI <_147(8), _141(6)>
_68 = VIEW_CONVERT_EXPR(b)[_146];
_69 = .USUBC (_67, _68, _144);
_56 = IMAGPART_EXPR <_69>;
_70 = REALPART_EXPR <_69>;
_71 = _70 | _148;
bitint.6[_146] = _71;
and the important thing to look at is the second .USUBC argument there, so _68,
load from
[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
--- Comment #2 from Tobias Burnus ---
Inside: omp_build_struct_sibling_lists
new_next
= omp_accumulate_sibling_list (region_type, code,
struct_map_to_clause, *grpmap,
grp_start_p, grp_end, addr_tokens,
, _p,
grp->reprocess_struct, _tail);
This processing looks okay. But:
/* Delete groups marked for deletion above. At this point the order of the
groups may no longer correspond to the order of the underlying list,
which complicates this a little. First clear out OMP_CLAUSE_DECL for
deleted nodes... */
FOR_EACH_VEC_ELT (*groups, i, grp)
if (grp->deleted)
for (tree d = *grp->grp_start;
d != OMP_CLAUSE_CHAIN (grp->grp_end);
d = OMP_CLAUSE_CHAIN (d))
OMP_CLAUSE_DECL (d) = NULL_TREE;
Where we have the following 4 elements. Note that grp_start is identical for
[1] and [2] – where [2] is deleted = true – which causes that the CLAUSE_DECL
are NULL. Namely, 'p (*groups)[i]' for i = 0...3 gives:
$86 = (omp_mapping_group &) @0x30f7a48: {grp_start = 0x76c92070, grp_end =
0x771f96c0, mark = UNVISITED, deleted = false, reprocess_struct = false,
fragile = false, sibling = 0x0, next = 0x0}
$91 = (omp_mapping_group &) @0x30f7a70: {grp_start = 0x771f96d0, grp_end =
0x771f9678, mark = UNVISITED, deleted = false, reprocess_struct = false,
fragile = false, sibling = 0x0, next = 0x0}
$92 = (omp_mapping_group &) @0x30f7a98: {grp_start = 0x771f96d0, grp_end =
0x771f9630, mark = UNVISITED, deleted = true, reprocess_struct = false,
fragile = false, sibling = 0x0, next = 0x0}
$93 = (omp_mapping_group &) @0x30f7ac0: {grp_start = 0x771f9640, grp_end =
0x771f9708, mark = UNVISITED, deleted = false, reprocess_struct = false,
fragile = false, sibling = 0x0, next = 0x0}
Where the '*grp_start' values of [0],[1]+[2], [3] are:
map(struct:S1 [len: 3]) map(tofrom:S1.a) map(tofrom:S1.b) map(alloc:S1.p [len:
8]) map(tofrom:*S1.p [len: 400]) map(attach_detach:S1.p [bias: 0])
map(tofrom:S1.p)
map(alloc:S1.p [len: 8]) map(tofrom:*S1.p [len: 400]) map(attach_detach:S1.p
[bias: 0]) map(tofrom:S1.p)
(gdb) p debug(*(tree*)0x771f9640)
And 'grp_end' for [0]...[4] is:
map(tofrom:S1.b) map(alloc:S1.p [len: 8]) map(tofrom:*S1.p [len: 400])
map(attach_detach:S1.p [bias: 0]) map(tofrom:S1.p)
map(tofrom:S1.a) map(tofrom:S1.b) map(alloc:S1.p [len: 8]) map(tofrom:*S1.p
[len: 400]) map(attach_detach:S1.p [bias: 0]) map(tofrom:S1.p)
map(tofrom:S1.p)
map(attach_detach:S1.p [bias: 0]) map(tofrom:S1.p)
BEFORE that deleted loop, the result is:
(gdb) p debug(*list_p)
map(struct:S1 [len: 3]) map(tofrom:S1.a) map(tofrom:S1.b) map(alloc:S1.p [len:
8]) map(tofrom:*S1.p [len: 400]) map(attach_detach:S1.p [bias: 0])
map(tofrom:S1.p)
which looks fine. Obviously, after the deleted, all entries after 'alloc:S.p'
have CLAUSE_DECL == NULL_TREE, causing the fail.
* * *
RFC:
* Why are there two 'grp' with the same *grp_start value?
* Why does it get set to 'deleted' while its clauses are actually used?
[Bug c++/29834] g++ thinks it is a declaration when it cannot be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #15 from Marek Polacek ---
A nice short test from Bug 113812:
void f(int x)
{
int(x), 0;
}
I recently fixed similar problems (with auto(x)), so I suppose I ought to take
a look.
[Bug target/112397] Two persistent libstdc++ test failures on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-07 Ever confirmed|0 |1 --- Comment #3 from Iain Sandoe --- (In reply to Iain Sandoe from comment #2) > (In reply to Jonathan Wakely from comment #1) > > The .cold symbol is created by gcc, I don't see any way to control its > > visibility in the source. So maybe a target bug in the compiler, not a > > library bug. > > Agreed its a target issue - it's a question of convincing the linker that > the label is not reachable from a different TU if the implementation of the > non-cold symbol comes from that. The problem is this: We partition the function into hot/cold. so we have weak definition hot . do stuff ... make a call Landingpad1 OK... return epilogue_code: Landingpad2 bad -> jump to error_case cold error_case: ... do stuff jump epilogue_code. The linker says "oh you have a direct jump to that epilogue code in a weak definition which would be broken if a different weak definition was chosen by the dynamic linker". On the face of it, the linker is correct ... ... but what it cannot see is that the only way to be executing the code that makes this jump is if it came from Landingpad2. So actually, we do not have a real error - but I am not sure how we could go about teaching the linker to DTRT (even if we could persuade Apple to do the same for the new closed source one). I'm tempted to suggest that we consider building libstdc++ with `-fno-reorder-blocks-and-partition` and see if there's any measurable performance decrease. NOTE; that Darwin's linker (using subsections_by_symbols) is also able to partition and reorder code without help from the compiler .. (although whether/how much it does I"m not sure). If there's a way to add that [-fno-reorder-blocks-and-partition] flag to that single source for Darwin-only, that would be a short-term workaround.
[Bug c++/113812] Comma expression parsed as declaration when ambiguous type name cast is present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113812 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Yes this is a dup of bug 29834. *** This bug has been marked as a duplicate of bug 29834 ***
[Bug c++/29834] g++ thinks it is a declaration when it cannot be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834 --- Comment #14 from Andrew Pinski --- *** Bug 113812 has been marked as a duplicate of this bug. ***
[Bug c++/108321] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108321 --- Comment #10 from GCC Commits --- The releases/gcc-13 branch has been updated by Torbjorn Svensson : https://gcc.gnu.org/g:0cdb04629641c51498f099db04021e8de51adedb commit r13-8297-g0cdb04629641c51498f099db04021e8de51adedb Author: Andrew Pinski Date: Thu Nov 23 18:55:30 2023 -0800 Fix contracts-tmpl-spec2.C on targets where plain char is unsigned by default Since contracts-tmpl-spec2.C is just testing contracts, I thought it would be better to just add `-fsigned-char` to the options rather than change the testcase to support both cases. Committed after testing on aarch64-linux-gnu. gcc/testsuite/ChangeLog: PR testsuite/108321 * g++.dg/contracts/contracts-tmpl-spec2.C: Add -fsigned-char to options. Signed-off-by: Andrew Pinski (cherry picked from commit 6e15e4e1abed02443a27a69455f4bfa49457c99e)
[Bug c++/113812] Comma expression parsed as declaration when ambiguous type name cast is present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113812
--- Comment #2 from Gabriel Ravier ---
Also I guess this is a simpler minimal example:
void f(int x)
{
int(x), 0;
}
[Bug c++/113812] Comma expression parsed as declaration when ambiguous type name cast is present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113812 --- Comment #1 from Andrew Pinski --- I suspect this is a dup of bug 29834.
[Bug c++/113812] New: Comma expression parsed as declaration when ambiguous type name cast is present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113812
Bug ID: 113812
Summary: Comma expression parsed as declaration when ambiguous
type name cast is present
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f()
{
int(x), a, b, c, d, e, f, g, h, etc;
int(x), a, b, c, d, e, f, g, h, etc, (new int);
}
Clang parses this fine, but GCC errors out, complaining that:
: In function 'void f()':
:4:9: error: redeclaration of 'int x'
4 | int(x), a, b, c, d, e, f, g, h, etc, (new int);
| ^
:3:9: note: 'int x' previously declared here
3 | int(x), a, b, c, d, e, f, g, h, etc;
| ^
:4:13: error: redeclaration of 'int a'
4 | int(x), a, b, c, d, e, f, g, h, etc, (new int);
| ^
:3:13: note: 'int a' previously declared here
3 | int(x), a, b, c, d, e, f, g, h, etc;
| ^
:4:16: error: redeclaration of 'int b'
4 | int(x), a, b, c, d, e, f, g, h, etc, (new int);
|^
:3:16: note: 'int b' previously declared here
3 | int(x), a, b, c, d, e, f, g, h, etc;
|^
:4:19: error: redeclaration of 'int c'
4 | int(x), a, b, c, d, e, f, g, h, etc, (new int);
| ^
:3:19: note: 'int c' previously declared here
3 | int(x), a, b, c, d, e, f, g, h, etc;
| ^
:4:22: error: redeclaration of 'int d'
4 | int(x), a, b, c, d, e, f, g, h, etc, (new int);
| ^
:3:22: note: 'int d' previously declared here
3 | int(x), a, b, c, d, e, f, g, h, etc;
| ^
:4:25: error: redeclaration of 'int e'
4 | int(x), a, b, c, d, e, f, g, h, etc, (new int);
| ^
:3:25: note: 'int e' previously declared here
3 | int(x), a, b, c, d, e, f, g, h, etc;
| ^
:4:28: error: redeclaration of 'int f'
4 | int(x), a, b, c, d, e, f, g, h, etc, (new int);
|^
:3:28: note: 'int f' previously declared here
3 | int(x), a, b, c, d, e, f, g, h, etc;
|^
:4:31: error: redeclaration of 'int g'
4 | int(x), a, b, c, d, e, f, g, h, etc, (new int);
| ^
:3:31: note: 'int g' previously declared here
3 | int(x), a, b, c, d, e, f, g, h, etc;
| ^
:4:34: error: redeclaration of 'int h'
4 | int(x), a, b, c, d, e, f, g, h, etc, (new int);
| ^
:3:34: note: 'int h' previously declared here
3 | int(x), a, b, c, d, e, f, g, h, etc;
| ^
:4:37: error: redeclaration of 'int etc'
4 | int(x), a, b, c, d, e, f, g, h, etc, (new int);
| ^~~
:3:37: note: 'int etc' previously declared here
3 | int(x), a, b, c, d, e, f, g, h, etc;
| ^~~
:4:43: error: expected unqualified-id before 'new'
4 | int(x), a, b, c, d, e, f, g, h, etc, (new int);
| ^~~
:4:43: error: expected ')' before 'new'
4 | int(x), a, b, c, d, e, f, g, h, etc, (new int);
| ~^~~
| )
It appears that GCC is treating the second statement in the function as a
declaration instead of a comma expression, which Clang does.
[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 --- Comment #14 from Martin Jambor --- (In reply to rguent...@suse.de from comment #13) > Might be also an interaction with IPA ICF in case there's a pointer to > the pair involved? Yes, this is exactly what seems to be happening. The problem goes away with -fno-icf. (Possibly because the testcase uses -fno-strict-aliasing,) IPA-ICF merges two functions which copy a structure and that access type it what IPA-SRA saves, but loads only the one of the merged functions. SRA then uses the (wrong) type to split aggregate copies into copies by individual fields. I have talked to Honza about this. It seems that IPA-ICF needs to be careful about aggreage with holes in different places. The ideal next step would be to create a testcase not dependent on IPA-SRA.
[Bug libstdc++/113811] New: std::rotate does 64-bit signed division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113811 Bug ID: 113811 Summary: std::rotate does 64-bit signed division Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: terra at gnome dot org Target Milestone: --- In stl_algo.h, function __rotate for RandomAccessIterator lines 1280-1362 for me, there are two divisions of integers: __n %= __k; on lines 1332 and 1356. They look harmless. But in the common case on x86_64 where _Distance is, essentially, int64_t this is a 64-bit signed division which is absurdly slow. By my reading of https://www.agner.org/optimize/instruction_tables.pdf page 296: 64-bit signed: 57 cycles 64-bit unsigned: 36 cycles smaller sizes: 10 cycles (excluding the 64-to-128-bit sign extension needed too) I believe the numbers involved are all positive, so at the very least the division could be unsigned. It might even make sense to check if __n is smaller than 2^32 and do a 32-bit division instead. Somewhat related: bug 102580 Note: I do not actually have benchmark results that show this matters in a practical case.
[Bug c++/98388] Throwing move-only parameter results in hard error in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98388 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #36 from Richard Biener ---
For example with AVX512VL and the following, using -O -fgimple -mavx512vl
we get simply
notl%esi
orl %esi, %edi
cmpb$15, %dil
je .L6
typedef long v4si __attribute__((vector_size(4*sizeof(long;
typedef v4si v4sib __attribute__((vector_mask));
typedef _Bool sbool1 __attribute__((signed_bool_precision(1)));
void __GIMPLE (ssa) foo (v4sib v1, v4sib v2)
{
v4sib tem;
__BB(2):
tem_5 = ~v2_2(D);
tem_3 = v1_1(D) | tem_5;
tem_4 = _Literal (v4sib) { _Literal (sbool1) -1, _Literal (sbool1) -1,
_Literal (sbool1) -1, _Literal (sbool1) -1 };
if (tem_3 == tem_4)
goto __BB3;
else
goto __BB4;
__BB(3):
__builtin_abort ();
__BB(4):
return;
}
the question is whether that matches the semantics of GIMPLE (the padding
is inverted, too), whether it invokes undefined behavior (don't do it - it
seems for people using intrinsics that's what it is?) or whether we
should avoid affecting padding.
Note after the patch I proposed on the mailing list the constant mask is
now expanded with zero padding.
[Bug c++/95942] [11 regression] offsetof on an array: error: 'e' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942 Andrew Pinski changed: What|Removed |Added CC||jlame646 at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 113804 has been marked as a duplicate of this bug. ***
[Bug c++/113804] offsetof(type, array[run_time_value]) failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113804 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 95942 ***
[Bug c++/113563] Rejects capture of `this` in C++23 `this auto` lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #3 from Patrick Palka ---
It works if we capture 'this' indirectly, e.g. via an init-capture:
struct S {
void f() {
[this_=this](this auto) {
return this_;
};
}
};
[Bug c++/113563] Rejects capture of `this` in C++23 `this auto` lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563 Patrick Palka changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #2 from Patrick Palka --- *** Bug 113810 has been marked as a duplicate of this bug. ***
[Bug c++/113810] A lambda with this auto style that captures this in a member function cannot use this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113810 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 113563 ***
[Bug tree-optimization/113796] [14 Regression] ifcvt does not remove range info before folding: Runtime mismatch at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113796 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed (but possibly latent on branches of course).
[Bug tree-optimization/113796] [14 Regression] ifcvt does not remove range info before folding: Runtime mismatch at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113796 --- Comment #8 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:8636c538b68068cd2a4115fece531dc3e3e3a84a commit r14-8869-g8636c538b68068cd2a4115fece531dc3e3e3a84a Author: Richard Biener Date: Wed Feb 7 13:08:43 2024 +0100 tree-optimization/113796 - if-conversion and ranges The following makes sure to wipe range info before folding the COND_EXPRs we insert as part of replacing PHI nodes when combining blocks in the if-conversion pass. PR tree-optimization/113796 * tree-if-conv.cc (combine_blocks): Wipe range-info before replacing PHIs and inserting predicates. * gcc.dg/torture/pr113796.c: New testcase.
[Bug c++/113810] New: A lambda with this auto style that captures this in a member function cannot use this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113810
Bug ID: 113810
Summary: A lambda with this auto style that captures this in a
member function cannot use this pointer
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: ---
struct S {
int i = 42;
constexpr auto f() {
return [this](this auto) {
return this->i;
}();
};
};
int main() {
return S().f();
}
https://godbolt.org/z/rMqaT9r9E
GCC rejects the above with:
:5:14: error: invalid use of 'this' in non-member function
5 | return this->i;
| ^~~~
But lambda captures this pointer so it should be usable.
[Bug tree-optimization/113808] [14 Regression] FAIL: libgomp.fortran/non-rectangular-loop-1.f90 since r14-8768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808 --- Comment #8 from Richard Biener --- It's surely a bug in the vectorizer early exit handling. I just don't know what exactly is wrong right now ;)
[Bug target/113690] [13/14 Regression] ICE: in as_a, at machmode.h:381 with -O2 -fno-dce -fno-forward-propagate -fno-split-wide-types -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113690 --- Comment #5 from GCC Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:99200573096c03120c8d4514383951acecdd5ab1 commit r14-8868-g99200573096c03120c8d4514383951acecdd5ab1 Author: Roger Sayle Date: Wed Feb 7 14:21:34 2024 + PR target/113690: Remove TImode REG_EQUAL notes in STV. This patch fixes PR target/113690, an ICE-on-valid regression on x86_64 that exhibits with a specific combination of command line options. The cause is that x86's scalar-to-vector pass converts a chain of instructions from TImode to V1TImode, but fails to appropriately update or delete the attached REG_EQUAL note. This implements Uros' recommendation of removing these notes. For convenience, this code (re)factors the logic to convert a TImode constant into a V1TImode constant vector into a subroutine and reuses it. For the record, STV is actually doing something useful in this strange testcase, GCC with -O2 -fno-dce -fno-forward-propagate -fno-split-wide-types -funroll-loops generates: foo:movl$v, %eax pxor%xmm0, %xmm0 movaps %xmm0, 48(%rax) movaps %xmm0, (%rax) movaps %xmm0, 16(%rax) movaps %xmm0, 32(%rax) ret With the addition of -mno-stv (to disable the patched code) it gives: foo:movl$v, %eax movq$0, 48(%rax) movq$0, 56(%rax) movq$0, (%rax) movq$0, 8(%rax) movq$0, 16(%rax) movq$0, 24(%rax) movq$0, 32(%rax) movq$0, 40(%rax) ret 2024-02-07 Roger Sayle Uros Bizjak gcc/ChangeLog PR target/113690 * config/i386/i386-features.cc (timode_convert_cst): New helper function to convert a TImode CONST_SCALAR_INT_P to a V1TImode CONST_VECTOR. (timode_scalar_chain::convert_op): Use timode_convert_cst. (timode_scalar_chain::convert_insn): Delete REG_EQUAL notes. Use timode_convert_cst. gcc/testsuite/ChangeLog PR target/113690 * gcc.target/i386/pr113690.c: New test case.
[Bug tree-optimization/113808] [14 Regression] FAIL: libgomp.fortran/non-rectangular-loop-1.f90 since r14-8768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/113808] [14 Regression] FAIL: libgomp.fortran/non-rectangular-loop-1.f90 since r14-8768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808 --- Comment #7 from Jakub Jelinek --- (In reply to Richard Biener from comment #5) > (In reply to Jakub Jelinek from comment #3) > > Started with r14-8768-g85094e2aa6dba7908f053046f02dd443e8f65d72 > > The regression status is unclear because we emitted sorry on this > > before r14-2634-g85da0b40538fb0d17d89de1e7905984668e3dfef > > I think r14-8768 just exposed this. That is possible. But in gcc 13 we'd never vectorize this due to the early exit, right? Still, even the #c4 testcase started at r14-8768 and that one is a real regression from 11/12/13.
[Bug tree-optimization/113808] [14 Regression] FAIL: libgomp.fortran/non-rectangular-loop-1.f90 since r14-8768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808 --- Comment #6 from Richard Biener --- With the following I don't see things going wrong, but we end up with the loop having the STOP exit last instead and thus a PEELED case. function bar (n) result (k) integer :: n, k !$omp simd lastprivate(k) do k = 1, n + 41 if (k > 11 + 41 .or. k < 1) error stop end do end program main integer :: n, i,k integer :: bar n = 11 k = bar (n) if (k /= 53) then print *, k, 53 error stop endif end
[Bug testsuite/106680] Test gcc.target/powerpc/bswap64-4.c fails on 32-bit BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680 --- Comment #14 from Sebastian Huber --- Thanks for your help, it seems that this patch fixes the issue for RTEMS: diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h index 57a2325991b..b36e64fec77 100644 --- a/gcc/config/rs6000/rtems.h +++ b/gcc/config/rs6000/rtems.h @@ -36,6 +36,10 @@ #endif #endif +/* RTEMS configured for the 32-bit multilibs doesn't support saving and + restoring 64-bit regs. */ +#define OS_MISSING_POWERPC64 !TARGET_64BIT + /* Copy and paste from linux64.h and freebsd64.h */ #undef TARGET_AIX #defineTARGET_AIX TARGET_64BIT
[Bug c++/113809] New: Error of constexpr variable creation due to combined use of std::tuple, copy constructor and static function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113809
Bug ID: 113809
Summary: Error of constexpr variable creation due to combined
use of std::tuple, copy constructor and static
function
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bobk-off at yandex dot ru
Target Milestone: ---
Compiler reports following error on code below:
in 'constexpr' expansion of 'A(MakeFullPGNsMap::value)'
in 'constexpr' expansion of
'((A*)this)->A::A<0>(other.A::mTuple,
(std::make_index_sequence<1>(), std::make_index_sequence<1>()))'
error: the value of 'MakeFullPGNsMap::value' is not usable in a constant
expression
Note: code is strognly reduced to only demonstrate compilation error.
Code:
#include
#include
template
struct ConstantObject { static constexpr T value = { TARGS::value... }; };
template
struct A {
A & operator =(const A & other) = delete;
constexpr A(const std::tuple & tuple) : A(tuple,
std::make_index_sequence()) {}
constexpr A(const A & other) : A(other.mTuple,
std::make_index_sequence()) {}
private:
template
constexpr A(const std::tuple & tuple,
std::index_sequence) : mTuple(tuple), mMap{ ::get(mTuple)... }
{}
std::tuple mTuple;
const void * mMap[sizeof...(Ts)] = {};
};
template
static constexpr A make_a(const std::tuple & spns) {
return A(spns);
}
struct MakeFullPGNsMap {;
static constexpr A value = make_a(std::make_tuple(5));
};
using X = ConstantObject;
const void * y;
int main() {
y = ::value;
return 0;
}
[Bug tree-optimization/113808] [14 Regression] FAIL: libgomp.fortran/non-rectangular-loop-1.f90 since r14-8768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808 --- Comment #5 from Richard Biener --- (In reply to Jakub Jelinek from comment #3) > Started with r14-8768-g85094e2aa6dba7908f053046f02dd443e8f65d72 > The regression status is unclear because we emitted sorry on this > before r14-2634-g85da0b40538fb0d17d89de1e7905984668e3dfef I think r14-8768 just exposed this. We are picking the last exit in the loop, it's not a PEELED case. It's the exit towards the if (k/=53) not towards STOP.
[Bug tree-optimization/113808] [14 Regression] FAIL: libgomp.fortran/non-rectangular-loop-1.f90 since r14-8768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808 --- Comment #4 from Richard Biener --- Reduced a bit, w/o collapse: program main integer :: n, i,k n = 11 do i = 1, n,2 !$omp simd lastprivate(k) do k = 1, i + 41 if (k > 11 + 41 .or. k < 1) error stop end do end do if (k /= 53) then print *, k, 53 error stop endif end
