[Bug target/111745] [14 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -ffloat-store -mavx512fp16 -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111745 --- Comment #3 from Hongtao.liu --- Fixed.
[Bug target/111745] [14 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -ffloat-store -mavx512fp16 -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111745 --- Comment #2 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:4efe9085d087a8d94261e4c38dd2ba840f3419ac commit r14-4549-g4efe9085d087a8d94261e4c38dd2ba840f3419ac Author: liuhongt Date: Tue Oct 10 11:32:09 2023 +0800 Refine predicate of operands[2] in divv4hf3 with register_operand. In the expander, it will emit below insn. rtx tmp = gen_rtx_VEC_CONCAT (V4SFmode, operands[2], force_reg (V2SFmode, CONST1_RTX (V2SFmode))); but *vec_concat only allow register_operand. gcc/ChangeLog: PR target/111745 * config/i386/mmx.md (divv4hf3): Refine predicate of operands[2] with register_operand. gcc/testsuite/ChangeLog: * gcc.target/i386/pr111745.c: New test.
[Bug tree-optimization/111765] RISC-V: Faild to vectorize gen-vect-34.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111765 --- Comment #3 from JuzheZhong --- If we specify the vector length to RVV and SVE: https://godbolt.org/z/njvsqYWhn Both can vectorize. ARM SVE: -msve-vector-bits=128 RVV: --param=riscv-autovec-preference=fixed-vlmax
[Bug tree-optimization/111765] RISC-V: Faild to vectorize gen-vect-34.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111765
--- Comment #2 from JuzheZhong ---
(In reply to Andrew Pinski from comment #1)
> For SVE:
> /app/example.cpp:6:18: missed: missing target support for reduction on
> variable-length vectors.
>
> I assume it is the same issue for RVV.
Yeah.
So may be we should adjust the dump check:
/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target
vect_masked_load && !vect_variable_length } } } */
?
[Bug tree-optimization/111765] RISC-V: Faild to vectorize gen-vect-34.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111765 --- Comment #1 from Andrew Pinski --- For SVE: /app/example.cpp:6:18: missed: missing target support for reduction on variable-length vectors. I assume it is the same issue for RVV.
[Bug tree-optimization/111766] New: Missed optimization with __builtin_unreachable and ands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111766
Bug ID: 111766
Summary: Missed optimization with __builtin_unreachable and
ands
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int
foo3n(int c, int bb)
{
if ((bb & ~3)!=0) __builtin_unreachable(); // bb = [0,3]
if ((bb & 1)==0) __builtin_unreachable(); // bb&1 == 0 // [0],[3]
if(bb == 2) __builtin_trap();
return bb;
}
```
The condition `bb == 2` is never true as (bb&1) has to be zero.
I Noticed this while looking into PR 111432. Note clang/LLVM is able to
optimize this ...
[Bug tree-optimization/111282] `a & (b ^ ~a)` (or `a & ~(a ^ b)`) not optimized to `a & b` in gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111282 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-October ||/632589.html --- Comment #5 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632589.html
[Bug c/111765] New: RISC-V: Faild to vectorize gen-vect-34.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111765
Bug ID: 111765
Summary: RISC-V: Faild to vectorize gen-vect-34.c
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
https://godbolt.org/z/17qYYKWPM
float summul(int n, float *arg1, float *arg2)
{
int i;
float res1 = 1.0;
for(i = 0; i < n; i++) {
if(arg2[i])
res1 *= arg1[i];
}
return res1;
}
I found both ARM SVE and RVV failed to vectorize this case wheras X86 can
vectorize it with -mavx2.
It seems that we need some tricks on both SVE and RVV backend ?
[Bug target/93062] Failed to generate indirect branch for long branches on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93062 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||law at gcc dot gnu.org --- Comment #3 from Jeffrey A. Law --- This should be fixed on the trunk now. No plans to backport to the release branches.
[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760
--- Comment #5 from JuzheZhong ---
(In reply to Robin Dapp from comment #2)
> https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629904.html
>
> prevents the wrong code but still leaves us with a redundant negation (and
> it is not the only missed optimization of that kind):
>
> vect_neg_xi_14.4_23 = -vect_xi_13.3_22;
> vect_res_2.5_24 = .COND_LEN_ADD ({ -1, ... }, vect_res_1.0_17,
> vect_neg_xi_14.4_23, vect_res_1.0_17, _29, 0);
>
> That's because my "hackaround" doesn't recognize a valueized sequence
> _30 = vect_res_1.0_17 - vect_xi_13.3_22;
>
> Of course I could (reverse valueize) recognize that again and convert it to
> a COND_LEN... but that doesn't seem elegant at all. There must be a simpler
> way that I'm missing entirely right now. That said, converting the last
> statement of such a sequence should be sufficient?
Yeah. That's what I want to point it out. Your patch will disable the
optimization
I made in GIMPLE_FOLD for COND_LEN_xxx.
I am not sure how to fix it, I think we need Richi's help for that since he
knows
the GIMPLE FOLD stuff the best.
[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760 --- Comment #4 from Andrew Pinski --- (In reply to JuzheZhong from comment #3) > (In reply to Andrew Pinski from comment #1) > > *** Bug 111761 has been marked as a duplicate of this bug. *** > > Oh. So sorry about that. I don't know why I file 2 consecutive bugs here. > > Really sorry for my mistake to file duplicate bugs. > > I guess my internet issue make such mistake :). Bugzilla sometimes does that, I have had it happen on me more than once. that is why I didn't really ask why you filed it twice even.
[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760 --- Comment #3 from JuzheZhong --- (In reply to Andrew Pinski from comment #1) > *** Bug 111761 has been marked as a duplicate of this bug. *** Oh. So sorry about that. I don't know why I file 2 consecutive bugs here. Really sorry for my mistake to file duplicate bugs. I guess my internet issue make such mistake :).
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 --- Comment #1 from David Malcolm --- Am trying to reproduce locally, but when I run this in my BUILDDIR/gcc: ./gdc -B. -S -fanalyzer oob.d I get: d21: error: cannot find source code for runtime library file 'object.d' Possibly a silly question, but what am I doing wrong?
[Bug tree-optimization/111432] `bool & (a|1)` is not optimized to just `bool`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111432 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Last reconfirmed||2023-10-10 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- The reason why this is correct is: a & (x | CST) -> (a & x) | (a & CST) -> // due to `a & CST -> a` (a & x) | a -> a So: ``` /* `a & (x | CST)` -> a if we know that (a & ~CST) == 0 */ (simplify (bit_and:c SSA_NAME@0 (bit_ior @1 INTEGER_CST@2)) (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) && wi::bit_and_not (get_nonzero_bits (@0), wi::to_wide (@2)) == 0) @0)) ``` // a | (x & CST) simplifies down to `(a | x) & CST` but I don't see if that is an improvement here as we still have 2 operations.
[Bug c++/109422] wrong depth used for template parameter mangling for lambdas in function signatures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109422 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:bd5719bd7f7cb23e5ed96a1f1a28efbb3dec4a31 commit r14-4544-gbd5719bd7f7cb23e5ed96a1f1a28efbb3dec4a31 Author: Jason Merrill Date: Fri Oct 6 11:41:20 2023 -0400 c++: mangle multiple levels of template parms [PR109422] This becomes be more important with concepts, but can also be seen with generic lambdas. PR c++/109422 gcc/cp/ChangeLog: * mangle.cc (write_template_param): Also mangle level. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-generic-mangle1.C: New test. * g++.dg/cpp2a/lambda-generic-mangle1a.C: New test.
[Bug c/111758] #pragma region/endregion fails between if/else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111758 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=85487 --- Comment #3 from Andrew Pinski --- (In reply to Domen Stangar from comment #2) > I don't agree. This works fine with 12.x version and bug report is for > version 4.9.1. > And this compiles with 4.9.1 version. yes it might have "worked" in 12.x but these pragma were not recognized until r13-3887-gd3fe767c16e7c528e4fc71c8a68ac14b4573d880 (PR 85487) so you run into the same issue as PR 63326 after that patch.
[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #2 from Robin Dapp ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629904.html
prevents the wrong code but still leaves us with a redundant negation (and it
is not the only missed optimization of that kind):
vect_neg_xi_14.4_23 = -vect_xi_13.3_22;
vect_res_2.5_24 = .COND_LEN_ADD ({ -1, ... }, vect_res_1.0_17,
vect_neg_xi_14.4_23, vect_res_1.0_17, _29, 0);
That's because my "hackaround" doesn't recognize a valueized sequence
_30 = vect_res_1.0_17 - vect_xi_13.3_22;
Of course I could (reverse valueize) recognize that again and convert it to a
COND_LEN... but that doesn't seem elegant at all. There must be a simpler way
that I'm missing entirely right now. That said, converting the last statement
of such a sequence should be sufficient?
[Bug fortran/104351] ICE in gfc_generate_initializer, at fortran/expr.cc:5140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104351 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid CC||anlauf at gcc dot gnu.org Last reconfirmed||2023-10-10 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from anlauf at gcc dot gnu.org --- The following untested, semi-obvious patch fixes the ICE: diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc index 4a3c5b86de0..892e3788b9d 100644 --- a/gcc/fortran/decl.cc +++ b/gcc/fortran/decl.cc @@ -1404,7 +1421,9 @@ get_proc_name (const char *name, gfc_symbol **result, bool module_fcn_entry) /* Trap declarations of attributes in encompassing scope. The signature for this is that ts.kind is nonzero for no-CLASS entity. For a CLASS entity, ts.kind is zero. */ - if ((sym->ts.kind != 0 || sym->ts.type == BT_CLASS) + if ((sym->ts.kind != 0 + || sym->ts.type == BT_CLASS + || sym->ts.type == BT_DERIVED) && !sym->attr.implicit_type && sym->attr.proc == 0 && gfc_current_ns->parent != NULL @@ -7622,6 +7641,10 @@ gfc_match_function_decl (void) if (current_ts.type != BT_UNKNOWN && !gfc_add_type (result, _ts, _current_locus)) goto cleanup; + if (current_ts.type != BT_UNKNOWN + && sym->ts.type != BT_UNKNOWN + && sym->ts.type != current_ts.type) + goto cleanup; sym->result = result; }
[Bug tree-optimization/111764] [11/12/13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Note r11-5965-g04bff1bbfc1 just exposed the issue, you can reproduce the > issue before that with `-fno-vector-cost-model` added and it worked with > that option in GCC 9.5.0 but was broken in GCC 10.1.0. Sorry I mean `-fno-vect-cost-model`.
[Bug tree-optimization/111764] [11/12/13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-10-10 Target Milestone|--- |11.5 Summary|Wrong code at -O3 on|[11/12/13/14 Regression] |x86_64-linux-gnu since |Wrong code at -O3 on |r11-5965-g04bff1bbfc1 |x86_64-linux-gnu Ever confirmed|0 |1 Known to work||10.5.0 Keywords||needs-bisection Known to fail||11.1.0, 12.1.0, 13.1.0 --- Comment #1 from Andrew Pinski --- Note r11-5965-g04bff1bbfc1 just exposed the issue, you can reproduce the issue before that with `-fno-vector-cost-model` added and it worked with that option in GCC 9.5.0 but was broken in GCC 10.1.0. Confirmed.
[Bug tree-optimization/111764] New: Wrong code at -O3 on x86_64-linux-gnu since r11-5965-g04bff1bbfc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764
Bug ID: 111764
Summary: Wrong code at -O3 on x86_64-linux-gnu since
r11-5965-g04bff1bbfc1
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
gcc at -O3 produced the wrong code.
Bisected to r11-5965-g04bff1bbfc1
Compiler explorer: https://godbolt.org/z/7vaqadYfP
$ cat a.c
int printf(const char *, ...);
char a;
short b, c;
static short *d = , *e =
short(f)(short g, short h) { return g * h; }
int main() {
*e = 2;
a = 1;
for (; a <= 9; a++) {
short *i =
*i = *d = f(*e, *e);
}
printf("%d\n", c);
}
$
$ gcc -O0 a.c && ./a.out
0
$ gcc -O3 a.c && ./a.out
4
%
[Bug c++/71283] Inconsistent location for C++ warning options in the manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71283 Eric Gallager changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #18 from Eric Gallager --- Florian Weimer was wondering about this general issue (of inconsistency in location of documentation for common C/C++ options) on the mailing lists recently: https://gcc.gnu.org/pipermail/gcc/2023-October/242669.html
[Bug tree-optimization/111282] `a & (b ^ ~a)` (or `a & ~(a ^ b)`) not optimized to `a & b` in gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111282 --- Comment #4 from Andrew Pinski --- Created attachment 56090 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56090=edit Patch under testing
[Bug libstdc++/111747] Problem with large float list initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111747 --- Comment #2 from oplata.kes1 at mail dot ru --- (In reply to Andrew Pinski from comment #1) > > 32bit floating point has the following characteristics: > Sign bit: 1 bit > Exponent width: 8 bits > Significand precision: 24 bits (23 explicitly stored) > > > 5000 is 0x2faf080 which is more than 24bits in precision which means it > cannot be represented exactly and when you start to add 1 to something which > is greater than 0xf0 (which is what 1.67772e+07 is), the value stays the > same and you start to lose precision. Thank you very much!
[Bug target/111763] New: `(a & ~1) | 2` could be done as `(a & ~(1 | 2)) + 2` which allows to use leal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111763
Bug ID: 111763
Summary: `(a & ~1) | 2` could be done as `(a & ~(1 | 2)) + 2`
which allows to use leal
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: x86_64-linux-gnu
Take:
```
int f1(int in) {
in = (in & ~(unsigned long)1);
in = in | 2;
return in;
}
int f2(int in) {
in = (in & ~(unsigned long)(1|2));
in = in + 2;
return in;
}
```
We currently get:
```
f1:
movl%edi, %eax
andl$-2, %eax
orl $2, %eax
ret
f2:
andl$-4, %edi
leal2(%rdi), %eax
ret
```
The leal version is better because it saves more move due to leal not being a 2
operand but 3 operand instruction so it could improve register allocation ...
I noticed this whole looking into PR 111762 (and PR 111282) and looking at
clang/LLVM's code generation here .
Also I don't know how often this shows up though.
[Bug tree-optimization/111762] New: `(a | 3) ^ 1` and `(a & ~1) | 2` should produce the same code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111762
Bug ID: 111762
Summary: `(a | 3) ^ 1` and `(a & ~1) | 2` should produce the
same code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: internal-improvement
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f(int in) {
in = in | 3;
in = in ^ 1;
return in;
}
int f1(int in) {
in = (in & ~(unsigned long)1);
in = in | 2;
return in;
}
```
These 2 functions produce the same result but the code generated is different.
I noticed this while writing the patch for PR 111282 and noticing that
`gcc.dg/tree-ssa/and-1.c` testcase now fails (test needs to be fixed).
LLVM/clang looks like canonicalizes to f1. I suspect xor is harder to optimize
when dealing with reassociation so doing f1 is better.
[Bug target/111428] RISC-V vector: Flaky segfault in {min|max}val_char_{1|2}.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111428 --- Comment #3 from Robin Dapp --- Still difficult to track down. The following is a smaller reproducer: program main implicit none integer, parameter :: n=5, m=3 integer, dimension(n,m) :: v real, dimension(n,m) :: r do call random_number(r) v = int(r * 2) if (count(v < 1) > 1) exit end do write (*,*) 'asdf' end program main I compiled libgfortran without vector but this doesn't change anything. It's really just the vectorization of that snippet but I haven't figured out why, yet. The stack before the random_number call looks identical. Also tried valgrind which complains about compares dependent on uninitialized data (those only show up once compiled with vectorization). However I suspect those are false negatives after chasing them for some hours. Going to try another angle of attack. Maybe it's a really simple thing I overlooked.
[Bug middle-end/17886] variable rotate and unsigned long long rotate should be better optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #27 from Roger Sayle ---
I believe that this issue has been fixed (for a long time). For Andi's
testcases in comment #3, -fdump-tree-optimized reveals all these cases are
perceived as rotations by the early middle-end.
long long unsigned int f (long long unsigned int x, int y)
{
return x_1(D) r<< y_2(D);
}
unsigned int f2 (unsigned int x, int y)
{
return x_1(D) r<< y_2(D);
}
long long unsigned int f3 (long long unsigned int x)
{
return x_1(D) r>> 55;
}
long unsigned int f4 (unsigned int x)
{
return x_1(D) r>> 22;
}
[Bug c++/111544] [14 regression] assignment of read-only location after r14-4111-g6e92a6a2a72d3b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544 seurer at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #14 from seurer at gcc dot gnu.org --- I modified the code to remove the "const" as that what was done to xerces itself.
[Bug middle-end/111732] genmatch missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111732 Andrew Pinski changed: What|Removed |Added Keywords||internal-improvement Last reconfirmed||2023-10-10 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Severity|normal |enhancement --- Comment #3 from Andrew Pinski --- .
[Bug c/111761] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111761 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- . *** This bug has been marked as a duplicate of bug 111760 ***
[Bug c/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760 --- Comment #1 from Andrew Pinski --- *** Bug 111761 has been marked as a duplicate of this bug. ***
[Bug target/106101] [12 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #30 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #29)
> (In reply to Florian Weimer from comment #28)
> > (In reply to Richard Biener from comment #1)
> > > Created attachment 53207 [details]
> > > reduced testcase
> >
> > Do you happen to have the unreduced test case still?
> >
> > int *yyvsp = 0;
> >
> > followed by:
> >
> > if (strncmp( yyvsp[0], "~", 1) == 0) {
> >
> > and
> >
> >free(yyvsp[0]);
> >
> > looks rather bogus.
>
> You can make `yyvsp` and argument if you are worried about the null pointer
> and you still get the crash back in 12.1.0.
> That is:
> ```
> int yyparse (int *yyvsp)
> {
> int yystate = 0;
> ```
>
> See https://godbolt.org/z/9YMsar1Ej .
And you can even make it a pointer to a pointer of char to hit the same bug to
get around the even more fuzziness of freeing an int rather than a pointer:
```
int yyparse (char **yyvsp)
```
See https://godbolt.org/z/v7xKxWE3K
[Bug target/106101] [12 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #29 from Andrew Pinski ---
(In reply to Florian Weimer from comment #28)
> (In reply to Richard Biener from comment #1)
> > Created attachment 53207 [details]
> > reduced testcase
>
> Do you happen to have the unreduced test case still?
>
> int *yyvsp = 0;
>
> followed by:
>
> if (strncmp( yyvsp[0], "~", 1) == 0) {
>
> and
>
>free(yyvsp[0]);
>
> looks rather bogus.
You can make `yyvsp` and argument if you are worried about the null pointer and
you still get the crash back in 12.1.0.
That is:
```
int yyparse (int *yyvsp)
{
int yystate = 0;
```
See https://godbolt.org/z/9YMsar1Ej .
[Bug tree-optimization/111679] `(~a) | (a ^ b)` is not simplified to `~(a & b)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111679 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed.
[Bug tree-optimization/111679] `(~a) | (a ^ b)` is not simplified to `~(a & b)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111679 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:975da6fa9170c9cf1ec4a9a9d8177f8561d464d1 commit r14-4543-g975da6fa9170c9cf1ec4a9a9d8177f8561d464d1 Author: Andrew Pinski Date: Mon Oct 9 11:07:08 2023 -0700 MATCH: [PR111679] Add alternative simplification of `a | ((~a) ^ b)` So currently we have a simplification for `a | ~(a ^ b)` but that does not match the case where we had originally `(~a) | (a ^ b)` so we need to add a new pattern that matches that and uses bitwise_inverted_equal_p that also catches comparisons too. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/111679 gcc/ChangeLog: * match.pd (`a | ((~a) ^ b)`): New pattern. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/bitops-5.c: New test.
[Bug middle-end/111754] [14 Regression] ICE: in decompose, at rtl.h:2313 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754
--- Comment #8 from rguenther at suse dot de ---
> Am 10.10.2023 um 16:07 schrieb prathamesh3492 at gcc dot gnu.org
> :
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754
>
> --- Comment #6 from prathamesh3492 at gcc dot gnu.org ---
> (In reply to rguent...@suse.de from comment #4)
>>> On Tue, 10 Oct 2023, prathamesh3492 at gcc dot gnu.org wrote:
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754
>>>
>>> --- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
>>> The issue is that we only support integral vector types in
>>> fold_vec_perm_cst,
>>> but fail to check for the same before calling it from fold_vec_perm.
>>> The following tweak fixes the ICE:
>>>
>>> diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
>>> index 4f8561509ff..a29a8af6d2f 100644
>>> --- a/gcc/fold-const.cc
>>> +++ b/gcc/fold-const.cc
>>> @@ -10801,7 +10801,8 @@ fold_vec_perm (tree type, tree arg0, tree arg1,
>>> const
>>> vec_perm_indices )
>>> return NULL_TREE;
>>>
>>> if (TREE_CODE (arg0) == VECTOR_CST
>>> - && TREE_CODE (arg1) == VECTOR_CST)
>>> + && TREE_CODE (arg1) == VECTOR_CST
>>> + && INTEGRAL_TYPE_P (TREE_TYPE (type)))
>>> return fold_vec_perm_cst (type, arg0, arg1, sel);
>>
>> Huh, that looks wrong. I fail to see how the element type matters
>> at all.
>
> IIUC, the element type matters for VLA folding when sel has a stepped sequence
> because in that case we need to derive elements from the encoding using
> vector_cst_elt / vector_cst_int_elt, and it gets enforced for VLS vectors too
> because they are handled in unified manner in fold_vec_perm_cst.
>
> Another possible approach is to use "VLS exception" in fold_vec_perm_cst to
> encode all the elements:
> res_npatterns = res_nelts;
> res_nelts_per_patterns = 1
> just like we do if valid_mask_for_fold_vec_perm_cst_p returns false.
>
> Does the following fix look OK instead ?
I think so, the important part is to fold for VLS types. I defer to Richard S.
For whether we can do better for VLA here
> diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
> index 4f8561509ff..356eb052fbc 100644
> --- a/gcc/fold-const.cc
> +++ b/gcc/fold-const.cc
> @@ -10642,6 +10642,11 @@ valid_mask_for_fold_vec_perm_cst_p (tree arg0, tree
> arg1,
> if (sel_nelts_per_pattern < 3)
> return true;
>
> + /* If SEL contains stepped sequence, ensure that we are dealing with
> + integral vector_cst. */
> + if (!INTEGRAL_TYPE_P (TREE_TYPE (arg0)))
> +return false;
> +
> for (unsigned pattern = 0; pattern < sel_npatterns; pattern++)
> {
> poly_uint64 a1 = sel[pattern + sel_npatterns];
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
[Bug ada/111434] [13/14 regression] infinite loop with multiple limited with clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111434 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.3 --- Comment #5 from Eric Botcazou --- Fixed on mainline and 13 branch. Thanks for reporting the problem.
[Bug ada/111434] [13/14 regression] infinite loop with multiple limited with clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111434 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:8a5fe7fc0c4aecca1fec88b7aa608745ade1b045 commit r13-7942-g8a5fe7fc0c4aecca1fec88b7aa608745ade1b045 Author: Eric Botcazou Date: Tue Sep 26 22:54:12 2023 +0200 ada: Fix infinite loop with multiple limited with clauses This occurs when one of the types has an incomplete declaration in addition to its full declaration in its package. In this case AI05-129 says that the incomplete type is not part of the limited view of the package, i.e. only the full view is. Now, in the GNAT implementation, it's the opposite in the regular view of the package, i.e. the incomplete type is the visible one. That's why the implementation needs to also swap the types on the visibility chain while it is swapping the views when the clauses are either installed or removed. This works correctly for the installation, but does not for the removal, so this change rewrites the code doing the latter. gcc/ada/ PR ada/111434 * sem_ch10.adb (Replace): New procedure to replace an entity with another on the homonym chain. (Install_Limited_With_Clause): Rename Non_Lim_View to Typ for the sake of consistency. Call Replace to do the replacements and split the code into the regular and the special cases. Add debuggging output controlled by -gnatdi. (Install_With_Clause): Print the Parent_With and Implicit_With flags in the debugging output controlled by -gnatdi. (Remove_Limited_With_Unit.Restore_Chain_For_Shadow (Shadow)): Rewrite using a direct replacement of E4 by E2. Call Replace to do the replacements. Add debuggging output controlled by -gnatdi.
[Bug middle-end/111754] [14 Regression] ICE: in decompose, at rtl.h:2313 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754
--- Comment #7 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
> It seems we have VECTOR_CST_NELTS_PER_PATTERN ({ 9.0e+0, 0.0, 0.0, 0.0 })
> 2 and VECTOR_CST_NPATTERNS == 1. And the selector { 1, 0, 1, 2 } has
> npatterns == 1 and nelts-per-pattern == 3.
>
> /* (1) If SEL is a suitable mask as determined by
> valid_mask_for_fold_vec_perm_cst_p, then:
> res_npatterns = max of npatterns between ARG0, ARG1, and SEL
> res_nelts_per_pattern = max of nelts_per_pattern between
> ARG0, ARG1 and SEL.
> (2) If SEL is not a suitable mask, and TYPE is VLS then:
> res_npatterns = nelts in result vector.
> res_nelts_per_pattern = 1.
> This exception is made so that VLS ARG0, ARG1 and SEL work as before.
> */
> if (valid_mask_for_fold_vec_perm_cst_p (arg0, arg1, sel, reason))
> {
> res_npatterns
> = std::max (VECTOR_CST_NPATTERNS (arg0),
> std::max (VECTOR_CST_NPATTERNS (arg1),
> sel.encoding ().npatterns ()));
>
> res_nelts_per_pattern
> = std::max (VECTOR_CST_NELTS_PER_PATTERN (arg0),
> std::max (VECTOR_CST_NELTS_PER_PATTERN (arg1),
> sel.encoding ().nelts_per_pattern ()));
>
> res_nelts = res_npatterns * res_nelts_per_pattern;
>
> this seems to be a case that doesn't fit, so the fix needs to be to
> valid_mask_for_fold_vec_perm_cst_p which really looks a bit
> unwieldly.
valid_mask_for_fold_vec_perm_cst_p returns incorrectly true here,
which is being addressed in PR111648 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631926.html
Even if the vectors had integral element type:
arg0 = arg1 = (v4si){ 9, 0, 0, 0 } // encoded as {9, 0, ...}
and sel = { 1, 0, 1, 2 } // encoded as {1, 0, 1, ...}
The pattern in sel {1, 0, 1, ...}
would choose elements from arg0, and
res would have incorrect encoding with step = -9:
res = { arg0[1], arg0[0], arg0[1], ... }
= { 0, 9, 0, ... }
And res[3] will be incorrectly computed as -9 instead of arg0[2].
However, for floating element types, even if encoding is correct,
I assume it will still ICE when trying to derive elements not present in
encoding since poly_int_cst can only deal with integral elements ?
>
> An assert that res_nelts is power-of-two would be nice to add.
Sorry, I don't understand. res_nelts for VLA need not be power of 2,
since res_nelts_per_pattern can be 3. The encoding for res is chosen
to be max of npatterns and max of nelts_per_pattern between arg0, arg1, and
sel.
Thanks,
Prathamesh
[Bug c/111760] New: risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760
Bug ID: 111760
Summary: risc-v regression: COND_LEN_* incorrect fold/simplify
in middle-end
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects scan-tree-dump
optimized " = \\.COND_(LEN_)?SUB"
FAIL: gcc.dg/vect/vect-cond-arith-2.c scan-tree-dump optimized " =
\\.COND_(LEN_)?SUB"
https://godbolt.org/z/hEz51qf6a
double __GIMPLE (ssa, startwith("loop"))
neg_xi (double *x)
{
int i;
long unsigned int index;
long unsigned int offset;
double * xi_ptr;
double xi;
double neg_xi;
double res;
unsigned int ivtmp;
__BB(5):
goto __BB2;
__BB(2):
res_1 = __PHI (__BB5: 0.0, __BB3: res_2);
i_4 = __PHI (__BB5: 0, __BB3: i_5);
ivtmp_6 = __PHI (__BB5: 100U, __BB3: ivtmp_7);
index = (long unsigned int) i_4;
offset = index * 8UL;
xi_ptr = x_8(D) + offset;
xi = *xi_ptr;
neg_xi = -xi;
res_2 = neg_xi + res_1;
i_5 = i_4 + 1;
ivtmp_7 = ivtmp_6 - 1U;
if (ivtmp_7 != 0U)
goto __BB3;
else
goto __BB4;
__BB(3):
goto __BB2;
__BB(4):
res_3 = __PHI (__BB2: res_2);
return res_3;
}
There is no COND_LEN_ADD IR here which is incorrect.
[Bug c/111761] New: risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111761
Bug ID: 111761
Summary: risc-v regression: COND_LEN_* incorrect fold/simplify
in middle-end
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects scan-tree-dump
optimized " = \\.COND_(LEN_)?SUB"
FAIL: gcc.dg/vect/vect-cond-arith-2.c scan-tree-dump optimized " =
\\.COND_(LEN_)?SUB"
https://godbolt.org/z/hEz51qf6a
double __GIMPLE (ssa, startwith("loop"))
neg_xi (double *x)
{
int i;
long unsigned int index;
long unsigned int offset;
double * xi_ptr;
double xi;
double neg_xi;
double res;
unsigned int ivtmp;
__BB(5):
goto __BB2;
__BB(2):
res_1 = __PHI (__BB5: 0.0, __BB3: res_2);
i_4 = __PHI (__BB5: 0, __BB3: i_5);
ivtmp_6 = __PHI (__BB5: 100U, __BB3: ivtmp_7);
index = (long unsigned int) i_4;
offset = index * 8UL;
xi_ptr = x_8(D) + offset;
xi = *xi_ptr;
neg_xi = -xi;
res_2 = neg_xi + res_1;
i_5 = i_4 + 1;
ivtmp_7 = ivtmp_6 - 1U;
if (ivtmp_7 != 0U)
goto __BB3;
else
goto __BB4;
__BB(3):
goto __BB2;
__BB(4):
res_3 = __PHI (__BB2: res_2);
return res_3;
}
There is no COND_LEN_ADD IR here which is incorrect.
[Bug target/106101] [12 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #28 from Florian Weimer ---
(In reply to Richard Biener from comment #1)
> Created attachment 53207 [details]
> reduced testcase
Do you happen to have the unreduced test case still?
int *yyvsp = 0;
followed by:
if (strncmp( yyvsp[0], "~", 1) == 0) {
and
free(yyvsp[0]);
looks rather bogus.
[Bug middle-end/111754] [14 Regression] ICE: in decompose, at rtl.h:2313 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754
--- Comment #6 from prathamesh3492 at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #4)
> On Tue, 10 Oct 2023, prathamesh3492 at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754
> >
> > --- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
> > The issue is that we only support integral vector types in
> > fold_vec_perm_cst,
> > but fail to check for the same before calling it from fold_vec_perm.
> > The following tweak fixes the ICE:
> >
> > diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
> > index 4f8561509ff..a29a8af6d2f 100644
> > --- a/gcc/fold-const.cc
> > +++ b/gcc/fold-const.cc
> > @@ -10801,7 +10801,8 @@ fold_vec_perm (tree type, tree arg0, tree arg1,
> > const
> > vec_perm_indices )
> > return NULL_TREE;
> >
> >if (TREE_CODE (arg0) == VECTOR_CST
> > - && TREE_CODE (arg1) == VECTOR_CST)
> > + && TREE_CODE (arg1) == VECTOR_CST
> > + && INTEGRAL_TYPE_P (TREE_TYPE (type)))
> > return fold_vec_perm_cst (type, arg0, arg1, sel);
>
> Huh, that looks wrong. I fail to see how the element type matters
> at all.
IIUC, the element type matters for VLA folding when sel has a stepped sequence
because in that case we need to derive elements from the encoding using
vector_cst_elt / vector_cst_int_elt, and it gets enforced for VLS vectors too
because they are handled in unified manner in fold_vec_perm_cst.
Another possible approach is to use "VLS exception" in fold_vec_perm_cst to
encode all the elements:
res_npatterns = res_nelts;
res_nelts_per_patterns = 1
just like we do if valid_mask_for_fold_vec_perm_cst_p returns false.
Does the following fix look OK instead ?
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 4f8561509ff..356eb052fbc 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -10642,6 +10642,11 @@ valid_mask_for_fold_vec_perm_cst_p (tree arg0, tree
arg1,
if (sel_nelts_per_pattern < 3)
return true;
+ /* If SEL contains stepped sequence, ensure that we are dealing with
+ integral vector_cst. */
+ if (!INTEGRAL_TYPE_P (TREE_TYPE (arg0)))
+return false;
+
for (unsigned pattern = 0; pattern < sel_npatterns; pattern++)
{
poly_uint64 a1 = sel[pattern + sel_npatterns];
[Bug libstdc++/84949] -ffast-math bugged with respect to NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84949 Andrew Pinski changed: What|Removed |Added CC||Zahira.Ammarguellat at intel dot c ||om --- Comment #10 from Andrew Pinski --- *** Bug 111759 has been marked as a duplicate of this bug. ***
[Bug c++/111759] __FLT_HAS_INFINITY__ has value 1 even when -ffinite-math-only is used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111759 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Yes this is a dup. There is talk about infinite there too. *** This bug has been marked as a duplicate of bug 84949 ***
[Bug c++/111759] __FLT_HAS_INFINITY__ has value 1 even when -ffinite-math-only is used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111759 --- Comment #1 from Andrew Pinski --- I think this is basically a dup of bug 84949
[Bug c++/111759] New: __FLT_HAS_INFINITY__ has value 1 even when -ffinite-math-only is used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111759 Bug ID: 111759 Summary: __FLT_HAS_INFINITY__ has value 1 even when -ffinite-math-only is used. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: Zahira.Ammarguellat at intel dot com Target Milestone: --- Not sure if this is a bug but would like community feedback. In https://godbolt.org/z/fqMdqfM7n we see that __FLT_HAS_INFINITY__ is set to 1 even when -ffast-math and -ffinite-math-only are used. Shouldn't this be set to 0 in presence of these options? In limits header: static _GLIBCXX_USE_CONSTEXPR bool has_infinity = __FLT_HAS_INFINITY__; That means the value of std::numeric_limits::has_infinity will always be 1 even with -ffast-math and -ffinite-math-only. See https://godbolt.org/z/M6W6Ejc7W Is this acceptable? Any feedback appreciated. Thanks.
[Bug middle-end/111754] [14 Regression] ICE: in decompose, at rtl.h:2313 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #5 from Richard Biener ---
It seems we have VECTOR_CST_NELTS_PER_PATTERN ({ 9.0e+0, 0.0, 0.0, 0.0 })
2 and VECTOR_CST_NPATTERNS == 1. And the selector { 1, 0, 1, 2 } has
npatterns == 1 and nelts-per-pattern == 3.
/* (1) If SEL is a suitable mask as determined by
valid_mask_for_fold_vec_perm_cst_p, then:
res_npatterns = max of npatterns between ARG0, ARG1, and SEL
res_nelts_per_pattern = max of nelts_per_pattern between
ARG0, ARG1 and SEL.
(2) If SEL is not a suitable mask, and TYPE is VLS then:
res_npatterns = nelts in result vector.
res_nelts_per_pattern = 1.
This exception is made so that VLS ARG0, ARG1 and SEL work as before. */
if (valid_mask_for_fold_vec_perm_cst_p (arg0, arg1, sel, reason))
{
res_npatterns
= std::max (VECTOR_CST_NPATTERNS (arg0),
std::max (VECTOR_CST_NPATTERNS (arg1),
sel.encoding ().npatterns ()));
res_nelts_per_pattern
= std::max (VECTOR_CST_NELTS_PER_PATTERN (arg0),
std::max (VECTOR_CST_NELTS_PER_PATTERN (arg1),
sel.encoding ().nelts_per_pattern ()));
res_nelts = res_npatterns * res_nelts_per_pattern;
this seems to be a case that doesn't fit, so the fix needs to be to
valid_mask_for_fold_vec_perm_cst_p which really looks a bit
unwieldly.
An assert that res_nelts is power-of-two would be nice to add.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 --- Comment #21 from JuzheZhong --- Hi, Richi. Finish and confirm RISC-V regression. All pass. Thank you so much!
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 --- Comment #20 from CVS Commits --- The trunk branch has been updated by Lehua Ding : https://gcc.gnu.org/g:5255273ee8b14ea565eb43f067a86370d25df114 commit r14-4538-g5255273ee8b14ea565eb43f067a86370d25df114 Author: Juzhe-Zhong Date: Tue Oct 10 20:15:35 2023 +0800 RISC-V: Add VLS BOOL mode vcond_mask[PR111751] Richard patch resolve PR111751: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7c76c876e917a1f20a788f602cc78fff7d0a2a65 which cause ICE in RISC-V regression: FAIL: gcc.dg/torture/pr53144.c -O2 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:328) FAIL: gcc.dg/torture/pr53144.c -O2 (test for excess errors) FAIL: gcc.dg/torture/pr53144.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:328) FAIL: gcc.dg/torture/pr53144.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: gcc.dg/torture/pr53144.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:328) FAIL: gcc.dg/torture/pr53144.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gcc.dg/torture/pr53144.c -O3 -g (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:328) FAIL: gcc.dg/torture/pr53144.c -O3 -g (test for excess errors) VLS BOOL modes vcond_mask is needed to fix this regression ICE. More details: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 Tested and Committed. PR target/111751 gcc/ChangeLog: * config/riscv/autovec.md: Add VLS BOOL modes.
[Bug c/111758] #pragma region/endregion fails between if/else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111758 --- Comment #2 from Domen Stangar --- I don't agree. This works fine with 12.x version and bug report is for version 4.9.1. And this compiles with 4.9.1 version.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 --- Comment #19 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:70b5c6981fcdff246f90e57e91f3e1667eab2eb3 commit r14-4537-g70b5c6981fcdff246f90e57e91f3e1667eab2eb3 Author: Richard Biener Date: Tue Oct 10 13:33:34 2023 +0200 tree-optimization/111751 - support 1024 bit vector constant reinterpretation The following ups the limit in fold_view_convert_expr to handle 1024bit vectors as used by GCN and RVV. It also robustifies the handling in visit_reference_op_load to properly give up when constants cannot be re-interpreted. PR tree-optimization/111751 * fold-const.cc (fold_view_convert_expr): Up the buffer size to 128 bytes. * tree-ssa-sccvn.cc (visit_reference_op_load): Special case constants, giving up when re-interpretation to the target type fails.
[Bug ada/111434] [13/14 regression] infinite loop with multiple limited with clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111434 --- Comment #3 from CVS Commits --- The master branch has been updated by Marc Poulhi?s : https://gcc.gnu.org/g:6bd83c90191a512d2c9094623248219d610b4372 commit r14-4532-g6bd83c90191a512d2c9094623248219d610b4372 Author: Eric Botcazou Date: Tue Sep 26 22:54:12 2023 +0200 ada: Fix infinite loop with multiple limited with clauses This occurs when one of the types has an incomplete declaration in addition to its full declaration in its package. In this case AI05-129 says that the incomplete type is not part of the limited view of the package, i.e. only the full view is. Now, in the GNAT implementation, it's the opposite in the regular view of the package, i.e. the incomplete type is the visible one. That's why the implementation needs to also swap the types on the visibility chain while it is swapping the views when the clauses are either installed or removed. This works correctly for the installation, but does not for the removal, so this change rewrites the code doing the latter. gcc/ada/ PR ada/111434 * sem_ch10.adb (Replace): New procedure to replace an entity with another on the homonym chain. (Install_Limited_With_Clause): Rename Non_Lim_View to Typ for the sake of consistency. Call Replace to do the replacements and split the code into the regular and the special cases. Add debuggging output controlled by -gnatdi. (Install_With_Clause): Print the Parent_With and Implicit_With flags in the debugging output controlled by -gnatdi. (Remove_Limited_With_Unit.Restore_Chain_For_Shadow (Shadow)): Rewrite using a direct replacement of E4 by E2. Call Replace to do the replacements. Add debuggging output controlled by -gnatdi.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Andrew Pinski changed: What|Removed |Added CC||domen.stangar at gmail dot com --- Comment #34 from Andrew Pinski --- *** Bug 111758 has been marked as a duplicate of this bug. ***
[Bug c/111758] #pragma region/endregion fails between if/else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111758 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 63326. *** This bug has been marked as a duplicate of bug 63326 ***
[Bug c/111758] New: #pragma region/endregion fails between if/else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111758
Bug ID: 111758
Summary: #pragma region/endregion fails between if/else
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: domen.stangar at gmail dot com
Target Milestone: ---
#include
int main() {
#pragma region test
if(1){}
#pragma endregion
else{}
}
gcc 13.x fails with output
: In function 'main':
:7:5: error: 'else' without a previous 'if'
7 | else
| ^~~~
Compiler returned: 1
while 12.x works fine.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #18 from JuzheZhong ---
(In reply to Richard Biener from comment #16)
> (In reply to JuzheZhong from comment #14)
> > Also this case ICE:
> >
> > typedef unsigned char __attribute__((vector_size(4))) uvec;
> >
> > int main (int argc, char *argv[]) {
> > int i;
> > int x = 0;
> > uvec uc0 = (uvec) {argc, 1, 2, 10};
> > unsigned char uc1[4] = {0, 3, 2, 200};
> > signed char ucg[4] = {1, 0, 0, 0 };
> > signed char ucl[4] = {0, 1, 0, 1 };
> >
> > #define uc0_ ((unsigned char *))
> >
> > for (i = 0; i < 4; i ++) {
> > x |= ucg[i] != (uc0_[i] > uc1[i]);
> > x |= ucl[i] != (uc0_[i] < uc1[i]);
> > }
> > return x;
> > }
> >
> > during GIMPLE pass: isel
> > dump file: auto.c.256t.isel
> > auto.c: In function 'main':
> > auto.c:3:5: internal compiler error: in gimple_expand_vec_cond_expr, at
> > gimple-isel.cc:328
> > 3 | int main (int argc, char *argv[]) {
> > | ^~~~
> > 0x1bb55bd gimple_expand_vec_cond_expr
> > ../../../../gcc/gcc/gimple-isel.cc:325
> > 0x1bb57c6 execute
> > ../../../../gcc/gcc/gimple-isel.cc:390
> >
> >
> > Looks odd, it ICE at gimple-isel.cc:
> >
> > gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0))
>
> I have a fix for the first issue. For this one the issue seems to be that
> we do have vec_cmp for _2 > { 0, 3, 2, 200 } when doing instruction
> selection for
>
> mask__11.18_97 = VEC_COND_EXPR 0, 0 }>;
>
> note the value is of vector boolean type. But we fail to have
> vcond_maskV4BIV4BI.
>
> ISTR we have fixed sth similar
> by adding missing patterns with VnBImode result? But maybe forgot about
> VLS modes here?
Confirm the second issue is fixed after I added vcond_mask of VLS BOOL mask
mode
I will commit it after I finish RISC-V regression.
[Bug middle-end/111754] [14 Regression] ICE: in decompose, at rtl.h:2313 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754 --- Comment #4 from rguenther at suse dot de --- On Tue, 10 Oct 2023, prathamesh3492 at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754 > > --- Comment #3 from prathamesh3492 at gcc dot gnu.org --- > The issue is that we only support integral vector types in fold_vec_perm_cst, > but fail to check for the same before calling it from fold_vec_perm. > The following tweak fixes the ICE: > > diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc > index 4f8561509ff..a29a8af6d2f 100644 > --- a/gcc/fold-const.cc > +++ b/gcc/fold-const.cc > @@ -10801,7 +10801,8 @@ fold_vec_perm (tree type, tree arg0, tree arg1, const > vec_perm_indices ) > return NULL_TREE; > >if (TREE_CODE (arg0) == VECTOR_CST > - && TREE_CODE (arg1) == VECTOR_CST) > + && TREE_CODE (arg1) == VECTOR_CST > + && INTEGRAL_TYPE_P (TREE_TYPE (type))) > return fold_vec_perm_cst (type, arg0, arg1, sel); Huh, that looks wrong. I fail to see how the element type matters at all.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 --- Comment #17 from CVS Commits --- The trunk branch has been updated by Lehua Ding : https://gcc.gnu.org/g:a704603d458b1e55b561ddfb4e513581ee863ed6 commit r14-4528-ga704603d458b1e55b561ddfb4e513581ee863ed6 Author: Juzhe-Zhong Date: Tue Oct 10 19:47:06 2023 +0800 RISC-V: Add testcase for SCCVN optimization[PR111751] Add testcase for PR111751 which has been fixed: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632474.html PR target/111751 gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr111751.c: New test.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #16 from Richard Biener ---
(In reply to JuzheZhong from comment #14)
> Also this case ICE:
>
> typedef unsigned char __attribute__((vector_size(4))) uvec;
>
> int main (int argc, char *argv[]) {
> int i;
> int x = 0;
> uvec uc0 = (uvec) {argc, 1, 2, 10};
> unsigned char uc1[4] = {0, 3, 2, 200};
> signed char ucg[4] = {1, 0, 0, 0 };
> signed char ucl[4] = {0, 1, 0, 1 };
>
> #define uc0_ ((unsigned char *))
>
> for (i = 0; i < 4; i ++) {
> x |= ucg[i] != (uc0_[i] > uc1[i]);
> x |= ucl[i] != (uc0_[i] < uc1[i]);
> }
> return x;
> }
>
> during GIMPLE pass: isel
> dump file: auto.c.256t.isel
> auto.c: In function 'main':
> auto.c:3:5: internal compiler error: in gimple_expand_vec_cond_expr, at
> gimple-isel.cc:328
> 3 | int main (int argc, char *argv[]) {
> | ^~~~
> 0x1bb55bd gimple_expand_vec_cond_expr
> ../../../../gcc/gcc/gimple-isel.cc:325
> 0x1bb57c6 execute
> ../../../../gcc/gcc/gimple-isel.cc:390
>
>
> Looks odd, it ICE at gimple-isel.cc:
>
> gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0))
I have a fix for the first issue. For this one the issue seems to be that
we do have vec_cmp for _2 > { 0, 3, 2, 200 } when doing instruction
selection for
mask__11.18_97 = VEC_COND_EXPR ;
note the value is of vector boolean type. But we fail to have
vcond_maskV4BIV4BI.
ISTR we have fixed sth similar
by adding missing patterns with VnBImode result? But maybe forgot about
VLS modes here?
[Bug middle-end/111754] [14 Regression] ICE: in decompose, at rtl.h:2313 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754
--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
The issue is that we only support integral vector types in fold_vec_perm_cst,
but fail to check for the same before calling it from fold_vec_perm.
The following tweak fixes the ICE:
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 4f8561509ff..a29a8af6d2f 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -10801,7 +10801,8 @@ fold_vec_perm (tree type, tree arg0, tree arg1, const
vec_perm_indices )
return NULL_TREE;
if (TREE_CODE (arg0) == VECTOR_CST
- && TREE_CODE (arg1) == VECTOR_CST)
+ && TREE_CODE (arg1) == VECTOR_CST
+ && INTEGRAL_TYPE_P (TREE_TYPE (type)))
return fold_vec_perm_cst (type, arg0, arg1, sel);
/* For fall back case, we want to ensure we have VLS vectors
and results in the following .optimized dump:
F bar (F a, F b)
{
F c;
[local count: 1073741824]:
c_2 = VEC_PERM_EXPR ;
__builtin_logbl (0.0);
return c_2;
}
F foo ()
{
[local count: 1073741824]:
__builtin_logbl (0.0);
return { 0.0, 9.0e+0, 0.0, 0.0 };
}
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #15 from JuzheZhong ---
Also, I find this following case that ARM SVE failed to optimize:
https://godbolt.org/z/d6YnneETj
#define N 16
typedef int half_word;
int foo2 ()
{
int i;
half_word ia[N];
half_word ic[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};
half_word ib[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};
/* Not worthwhile, only 2 parts per int */
for (i = 0; i < N; i++)
{
ia[i] = ib[i] + ic[i];
}
/* check results: */
for (i = 0; i < N; i++)
{
if (ia[i] != ib[i] + ic[i])
abort ();
}
return 0;
}
I guess your approach can fix that for ARM SVE. Maybe ARM SVE can also add
this case too.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #14 from JuzheZhong ---
Also this case ICE:
typedef unsigned char __attribute__((vector_size(4))) uvec;
int main (int argc, char *argv[]) {
int i;
int x = 0;
uvec uc0 = (uvec) {argc, 1, 2, 10};
unsigned char uc1[4] = {0, 3, 2, 200};
signed char ucg[4] = {1, 0, 0, 0 };
signed char ucl[4] = {0, 1, 0, 1 };
#define uc0_ ((unsigned char *))
for (i = 0; i < 4; i ++) {
x |= ucg[i] != (uc0_[i] > uc1[i]);
x |= ucl[i] != (uc0_[i] < uc1[i]);
}
return x;
}
during GIMPLE pass: isel
dump file: auto.c.256t.isel
auto.c: In function 'main':
auto.c:3:5: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:328
3 | int main (int argc, char *argv[]) {
| ^~~~
0x1bb55bd gimple_expand_vec_cond_expr
../../../../gcc/gcc/gimple-isel.cc:325
0x1bb57c6 execute
../../../../gcc/gcc/gimple-isel.cc:390
Looks odd, it ICE at gimple-isel.cc:
gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0))
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #13 from JuzheZhong ---
Thanks, Richi.
It does fix this issue.
This patch seems to cause an ICE in RISC-V:
#include
#include
#define N 128
int
main ()
{
uint8_t mask[N]
= {0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1};
uint8_t out[N] = {0};
for (uint8_t i = 0; i < N; ++i)
if (mask[i])
out[i] = i;
for (uint8_t i = 0; i < N; ++i)
{
if (mask[i])
assert (out[i] == i);
else
assert (out[i] == 0);
}
}
riscv64-unknown-elf-gcc --param riscv-autovec-preference=fixed-vlmax --param
riscv-autovec-lmul=m8 -O3 -S auto.c
during GIMPLE pass: fre
auto.c: In function 'main':
auto.c:7:1: internal compiler error: in execute_todo, at passes.cc:2137
7 | main ()
| ^~~~
0x1714290 execute_todo
../../../../gcc/gcc/passes.cc:2137
I guess this is caused by this following IR:
mask =
"\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01";
out = "\x00";
_51 = VIEW_CONVERT_EXPR("\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01");
mask__27.12_47 = _51 != { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0 };
.MASK_LEN_STORE (, 8B, mask__27.12_47, 128, 0, { 0, 1, 2, 3, 4, 5, 6, 7,
8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,
28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67,
68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87,
88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105,
106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121,
122, 123, 124, 125, 126, 127 });
There is a VIEW_CONVERT_EXPR here.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Richard Biener --- Should be fixed. Feel free to add a RISC-V specific testcase so we don't regress.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 --- Comment #11 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7c76c876e917a1f20a788f602cc78fff7d0a2a65 commit r14-4527-g7c76c876e917a1f20a788f602cc78fff7d0a2a65 Author: Richard Biener Date: Tue Oct 10 11:09:16 2023 +0200 Fix missed CSE with a BLKmode entity The following fixes fallout of r10-7145-g1dc00a8ec9aeba which made us cautionous about CSEing a load to an object that has padding bits. The added check also triggers for BLKmode entities like STRING_CSTs but by definition a BLKmode entity does not have padding bits. PR tree-optimization/111751 * tree-ssa-sccvn.cc (visit_reference_op_load): Exempt BLKmode result from the padding bits check.
[Bug tree-optimization/111519] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-455-g1fe04c497d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111519
--- Comment #8 from Richard Biener ---
(In reply to Richard Biener from comment #6)
> Created attachment 56089 [details]
> patch
>
> This patch (against the 13 branch) fixes the bug but it might be a bit
> conservative since some entries (the _addr one for example) may not have
> a live virtual use. Maybe getting the relevant one from up the call chain
> is better.
>
> I'm going to throw this at testing but expect some testsuite fallout because
> of this conservativeness.
It causes
FAIL: gcc.dg/Wstringop-overflow-69.c (test for warnings, line 60)
FAIL: gcc.dg/Wstringop-overflow-69.c (test for warnings, line 62)
the testcase has
*(VC4*)a2 = c4; // { dg-warning "writing 4 bytes into a region of size
2" }
*(VC4*)a3 = c4; // { dg-warning "writing 4 bytes into a region of size
3" }
*(VC8*)a4 = c8; // { dg-warning "writing 8 bytes into a region of size
4" }
*(VC8*)a7 = c8; // { dg-warning "writing 8 bytes into a region of size
7" }
and the later of the two assignments from c4 and c8 fail to be diagnosed
as their load is CSEd to a definition before the earlier of the two
assignments. Which means the fix is working, not sure if we want to beef
it up with an alias walk, that definitely would require careful looking
as to what random trees we feed into this kitchen-sink routine.
I'm inclined to XFAIL the sub-test, at least on branches, and only maybe
fix it on trunk (well, not myself actually).
[Bug middle-end/111754] [14 Regression] ICE: in decompose, at rtl.h:2313 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754 --- Comment #2 from prathamesh3492 at gcc dot gnu.org --- Hi, Sorry for the breakage, will take a look. Thanks, Prathamesh
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #10 from rguenther at suse dot de ---
On Tue, 10 Oct 2023, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
>
> --- Comment #9 from JuzheZhong ---
> (In reply to Richard Biener from comment #8)
> > ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > vect__1.7_10 = MEM [(char *)];
> > vect__2.10_34 = MEM [(char *)];
> >
> > so these. The lookup result is a STRING_CST object. I'm testing a patch.
>
> I have compare and debug between ARM SVE and RVV.
> It seems that ARM SVE produce result of visit_reference_op_load is
> CONST_VECTOR:
>
> (gdb) p debug(to)
> { 0, 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, 36, 39, 42, 45 }
> (gdb) p to->typed.type->type_common.mode
> $23 = E_V16QImode
>
> However, RVV produce result of visit_reference_op_load is STRING_CST:
>
> (gdb) p debug (result)
> "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"
>
> This is the BLKmode.
>
> Could you tell me where I should fix in RISC-V backend?
> It seems that it is not middle-end issue.
The IL into the SVE case is likely different. The difference is
wheher we have a direct hashtable hit for the load or whether we
need to go through vn_reference_lookup_3 which will perform the
type punning on its own.
[Bug middle-end/111754] [14 Regression] ICE: in decompose, at rtl.h:2313 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-10-10
Component|rtl-optimization|middle-end
Ever confirmed|0 |1
Target Milestone|--- |14.0
Priority|P3 |P1
Keywords||needs-bisection
--- Comment #1 from Richard Biener ---
(gdb) p debug_tree (exp)
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76d672a0 precision:32
pointer_to_this >
sizes-gimplified V4SF
size
unit-size
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76e99b28 nunits:4>
constant npatterns:1 nelts-per-pattern:3
elt:0:
constant 0.0>
elt:1:
constant 9.0e+0> elt:2: >
Confirmed. That's an odd vector mode 'F'!? And we have three elements?
Happens after inlining bar () into foo ():
F bar (F a, F b)
{
F c;
[local count: 1073741824]:
c_2 = VEC_PERM_EXPR ;
__builtin_logbl (0.0);
return c_2;
F foo ()
{
F _3;
[local count: 1073741824]:
_3 = bar ({ 9.0e+0, 0.0, 0.0, 0.0 }, { 0.0, 0.0, 0.0, 0.0 });
and the constant folding of the VEC_PERM_EXPR causes this.
ICEs way earlier (during inlining) when you do -fdump-ipa-inline
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #9 from JuzheZhong ---
(In reply to Richard Biener from comment #8)
> ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> vect__1.7_10 = MEM [(char *)];
> vect__2.10_34 = MEM [(char *)];
>
> so these. The lookup result is a STRING_CST object. I'm testing a patch.
I have compare and debug between ARM SVE and RVV.
It seems that ARM SVE produce result of visit_reference_op_load is
CONST_VECTOR:
(gdb) p debug(to)
{ 0, 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, 36, 39, 42, 45 }
(gdb) p to->typed.type->type_common.mode
$23 = E_V16QImode
However, RVV produce result of visit_reference_op_load is STRING_CST:
(gdb) p debug (result)
"\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"
This is the BLKmode.
Could you tell me where I should fix in RISC-V backend?
It seems that it is not middle-end issue.
[Bug rtl-optimization/111753] [14 Regression] ICE: in extract_constrain_insn, at recog.cc:2692 insn does not satisfy its constraints: {*movsf_internal} with -O2 -mavx512bw -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111753 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug middle-end/111752] -Wfree-nonheap-object (vec.h:347:10: warning: 'free' called on unallocated object 'dest_bbs') during bootstrap with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111752 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Keywords||diagnostic, ||missed-optimization --- Comment #1 from Richard Biener --- I think this is one of the usual false positives resulting from either too active diagnostics, threading or from missed optimizations.
[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org CC||rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from Richard Biener --- ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"; ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"; vect__1.7_10 = MEM [(char *)]; vect__2.10_34 = MEM [(char *)]; so these. The lookup result is a STRING_CST object. I'm testing a patch.
[Bug target/111746] [14 Regression] ICE: infinite recursion in try_split (emit-rtl.cc:3972) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111746 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/111519] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-455-g1fe04c497d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111519 --- Comment #7 from Richard Biener --- I'll note the problem appears to be latent for longer.
[Bug tree-optimization/111519] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-455-g1fe04c497d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111519 --- Comment #6 from Richard Biener --- Created attachment 56089 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56089=edit patch This patch (against the 13 branch) fixes the bug but it might be a bit conservative since some entries (the _addr one for example) may not have a live virtual use. Maybe getting the relevant one from up the call chain is better. I'm going to throw this at testing but expect some testsuite fallout because of this conservativeness.
[Bug tree-optimization/111519] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-455-g1fe04c497d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111519
--- Comment #5 from Richard Biener ---
Reverting
@@ -5089,8 +5123,9 @@ strlen_pass::handle_store (bool *zero_write)
return false;
}
- if (storing_all_zeros_p
- || storing_nonzero_p
+ if (storing_nonzero_p
+ || storing_all_zeros_p
+ || (full_string_p && lenrange[1] == 0)
|| (offset != 0 && store_before_nul[1] > 0))
{
/* When STORING_NONZERO_P, we know that the string will start
fixes the issue. We somehow compute a lenrange of { 0, 0, 1 } for
d = _8 but also set storing_all_zeros_p to false.
It seems that strlen_pass::count_nonzero_bytes happily skips intermediate
stores when it handles SSA names here:
gimple *stmt = SSA_NAME_DEF_STMT (exp);
if (gimple_assign_single_p (stmt))
{
exp = gimple_assign_rhs1 (stmt);
if (!DECL_P (exp)
&& TREE_CODE (exp) != CONSTRUCTOR
&& TREE_CODE (exp) != MEM_REF)
return false;
/* Handle DECLs, CONSTRUCTOR and MEM_REF below. */
we have
_8 = *_7;
...
*_7 = prephitmp_89;
d = _8;
when we recursively process a memory reference we need to verify there
are no intermediate aliases, the simplest thing would be to pass down
a virtual use. Trying some prototype.
[Bug tree-optimization/111519] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-455-g1fe04c497d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111519
--- Comment #4 from Jakub Jelinek ---
Slightly cleaned up testcase:
int a, o;
char b, f, i;
long c;
static signed char d;
static char g;
unsigned *h;
signed char *e =
static signed char **j =
static long k[2];
unsigned **l =
short m;
volatile int z;
__attribute__((noipa)) void
foo (char *p)
{
(void) p;
}
int
main ()
{
int p = z;
signed char *n =
*n = 0;
while (c)
for (; i; i--)
;
for (g = 0; g <= 1; g++)
{
*n = **j;
k[g] = 0 !=
*e = l && k[0];
}
if (p)
foo ();
for (; o < 4; o++)
{
a = d;
if (p)
foo ();
}
if (a != 1)
__builtin_abort ();
}
[Bug tree-optimization/111519] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-455-g1fe04c497d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111519
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
g = 0;
for (; g <= 1; g++) {
*n = **j;
k[g] = 0 !=
*e = l && k[0];
}
this is
g = 0;
d = f; // 0
k[0] = 1;
f = 1;
g = 1;
d = f; // 1
k[1] = 1;
f = 1;
g = 2;
that looks still equivalent to what we have after unrolling this loop in
cunroll
and also after DOM3 which really points to strlen wrongly considering 'd' zero.
Before strlen we have
[local count: 1605787]:
_2 = e;
_3 = *_2;
k[0] = 1;
l.8_91 = l;
if (l.8_91 != 0B)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 1124051]:
[local count: 1605787]:
# prephitmp_82 = PHI <0(7), 1(8)>
*_2 = prephitmp_82;
_7 = e;
_8 = *_7;
k[1] = 1;
l.8_10 = l;
if (l.8_10 != 0B)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 1124051]:
[local count: 14598063]:
# prephitmp_89 = PHI <1(10), 0(9)>
*_7 = prephitmp_89;
d = _8;
g = 2;
if (q_32(D) == 0)
goto ; [33.00%]
else
goto ; [67.00%]
that's the OK part, now into the tail loop - q_32(D) is 1:
[local count: 9780702]:
o.16_80 = o;
if (o.16_80 <= 3)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 8704825]:
d_lsm0.28_35 = d;
[local count: 79134774]:
# prephitmp_6 = PHI
_96 = (int) d_lsm0.28_35;
_85 = prephitmp_6 + 1;
if (_85 != 4)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 8704825]:
a = _96;
o = 4;
[local count: 14598063]:
a.17_23 = a;
printf ("%d\n", a.17_23);
return 0;
and the strlen pass replaces d_lsm0.28_35 = d; with d_lsm0.28_35 = 0; which
is wrong.
Your assessment
"Here the assignment to *_73 overwrites the value of f (at *e) which then
invalidates the use of _72 resulting in the wrong value for d."
seems odd, it's exactly writing the correct value (in fact both stores
write the value one, only the very original value is zero).
I don't know the strlen pass at all so I can't tell where it goes wrong.
[Bug target/104610] memcmp () == 0 can be optimized better for avx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104610
--- Comment #22 from Hongtao.liu ---
For 64-byte memory comparison
int compare (const char* s1, const char* s2)
{
return __builtin_memcmp (s1, s2, 64) == 0;
}
We're generating
vmovdqu (%rsi), %ymm0
vpxorq (%rdi), %ymm0, %ymm0
vptest %ymm0, %ymm0
jne .L2
vmovdqu 32(%rsi), %ymm0
vpxorq 32(%rdi), %ymm0, %ymm0
vptest %ymm0, %ymm0
je .L5
.L2:
movl$1, %eax
xorl$1, %eax
vzeroupper
ret
An alternative way is using vpcmpeq + kortest and check Carry bit
vmovdqu64 (%rsi), %zmm0
xorl%eax, %eax
vpcmpeqd(%rdi), %zmm0, %k0
kortestw%k0, %k0
setc%al
vzeroupper
Not sure if it's better or not.
[Bug modula2/111756] New: Re-building all-gcc after source changes fails to link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111756 Bug ID: 111756 Summary: Re-building all-gcc after source changes fails to link Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- When having modula-2 enabled in a development tree and there are any changes that trigger rebuilds in m2/ doing a 'make all-gcc' in the build directory will end up with make[1]: Entering directory '/spc/abuild/rguenther/gcc13-g/gcc' test -d m2/stage1 || /bin/sh /space/rguenther/src/gcc-13-branch/gcc/../mkinstalldirs m2/stage1 g++ -no-pie -g -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o m2/stage1/cc1gm2 m2/gm2-lang.o m2/m2pp.o m2/gm2-gcc/m2assert.o m2/gm2-gcc/m2block.o m2/gm2-gcc/m2builtins.o m2/gm2-gcc/m2except.o m2/gm2-gcc/m2color.o m2/gm2-gcc/m2configure.o m2/gm2-gcc/m2convert.o m2/gm2-gcc/m2decl.o m2/gm2-gcc/m2expr.o m2/gm2-gcc/m2linemap.o m2/gm2-gcc/m2statement.o m2/gm2-gcc/m2type.o m2/gm2-gcc/m2tree.o m2/gm2-gcc/m2treelib.o m2/gm2-gcc/m2top.o m2/gm2-gcc/m2misc.o m2/gm2-gcc/init.o m2/gm2-compiler-boot/m2flex.o \ attribs.o \ m2/gm2-compiler-boot/gm2.a m2/gm2-libs-boot/libgm2.a m2/mc-boot-ch/Glibc.o m2/mc-boot-ch/Gmcrts.o \ m2/gm2-gcc/rtegraph.o \ libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lisl -lmpc -lmpfr -lgmp -rdynamic -ldl -L./../zlib -lz -lzstd /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: m2/gm2-compiler-boot/gm2.a(P3Build.o): in function `AsmStatement(unsigned int, unsigned int, unsigned int)': /abuild/rguenther/gcc13-g/gcc/m2/gm2-compiler-boot/P3Build.c:8848:(.text+0xa387): undefined reference to `M2Quads_BuildInline' collect2: error: ld returned 1 exit status make[1]: *** [/space/rguenther/src/gcc-13-branch/gcc/m2/Make-lang.in:554: m2/stage1/cc1gm2] Error 1 make[1]: Leaving directory '/spc/abuild/rguenther/gcc13-g/gcc' make: *** [Makefile:4629: all-gcc] Error 2 this looks like a dependency issue, maybe triggered by the change renaming BuildInline to BuildAsm. When I remove P3Build.[co] it seems to work. How's dependency tracking (not) working here?
[Bug tree-optimization/111715] Missed optimization in FRE because of weak TBAA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715 --- Comment #8 from Sam James --- (In reply to Richard Biener from comment #7) > (In reply to Sam James from comment #6) > > I started hitting the original warning Jakub hit with 13.2.1 20231007 but > > I've not tried to figure out which backported change caused it to appear. > > With what configuration? I was a bit wrong - not quite the same warning, filed PR111752 for it.
[Bug tree-optimization/111715] Missed optimization in FRE because of weak TBAA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715 --- Comment #7 from Richard Biener --- (In reply to Sam James from comment #6) > I started hitting the original warning Jakub hit with 13.2.1 20231007 but > I've not tried to figure out which backported change caused it to appear. With what configuration?
[Bug target/111755] The built-in memset function in GCC inadvertently generates code like "vst1.8 {d8-d9}, [sp:64]", which assumes an 8-byte alignment on the stack pointer $sp, leading to alignment vi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111755 --- Comment #3 from Andrew Pinski --- The ARM EABI says the stack is always aligned to 8 byte so unless you change GCC to be do this, this is exacted and the incoming stack needs to be aligned correctly.
