date:20230624

[Bug middle-end/110148] [14 Regression] TSVC s242 regression between g:c0df96b3cda5738afbba3a65bb054183c5cd5530 and g:e4c986fde56a6248f8fbe6cf0704e1da34b055d8

2023-06-24 Thread lili.cui at intel dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110148

--- Comment #3 from cuilili  ---
I reproduced S1244 regression on znver3.

Src code:

for (int i = 0; i < LEN_1D-1; i++)
  {
a[i] = b[i] + c[i] * c[i] + b[i] * b[i] + c[i];
d[i] = a[i] + a[i+1];
  }

Base version: Base + commit version:

Assembler Assembler 
Loop1:Loop1:
vmovsd 0x60c400(%rax),%xmm2   vmovsd 0x60ba00(%rax),%xmm2   
vmovsd 0x60ba00(%rax),%xmm1   vmovsd 0x60c400(%rax),%xmm1   
add$0x8,%rax  add$0x8,%rax  

vaddsd %xmm1,%xmm2,%xmm0  vmovsd %xmm2,%xmm2,%xmm0  
vmulsd %xmm2,%xmm2,%xmm2  vfmadd132sd %xmm2,%xmm1,%xmm0 
vfmadd132sd %xmm1,%xmm2,%xmm1 vfmadd132sd %xmm1,%xmm2,%xmm1 

vaddsd %xmm1,%xmm0,%xmm0  vaddsd %xmm1,%xmm0,%xmm0  
vmovsd %xmm0,0x60cdf8(%rax)   vmovsd %xmm0,0x60cdf8(%rax)   
vaddsd 0x60ce00(%rax),%xmm0,%xmm0 vaddsd 0x60ce00(%rax),%xmm0,%xmm0 
vmovsd %xmm0,0x60aff8(%rax)   vmovsd %xmm0,0x60aff8(%rax)   
cmp$0x9f8,%raxcmp$0x9f8,%rax
jneLoop1: jneLoop1


For the Base version, mult and FMA have dependencies, which increases the
latency of the critical dependency chain. I didn't find out why znver3 has
regression. Same binary running on ICX has 11% gain (with #define iterations
1).

[Bug target/110400] New: Reuse vector register for both scalar and vector value.

2023-06-24 Thread crazylht at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110400

Bug ID: 110400
   Summary: Reuse vector register for both scalar and vector
value.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

>From PR109812 #c18

Uroš Bizjak 2023-06-21 09:46:43 UTC
One interesting observation:

clang is able to do this:

  0.09 │ │  vmovddup -0x8(%rdx,%rsi,1),%xmm3  ▒
  ...
  0.11 │ │  vfmadd231sd  %xmm2,%xmm3,%xmm1▒
  ...
  0.74 │ │  vfmadd231pd  %xmm2,%xmm3,%xmm0▒

It figures out that duplicated V2DFmode value in %xmm3 can also be accessed in
the same register as DFmode value.

OTOH, current gcc does:

vmovsd  (%rsi,%rax,8), %xmm1
...
vmovddup%xmm1, %xmm4
...
vfmadd231pd %xmm4, %xmm0, %xmm2
...
vfmadd231sd %xmm1, %xmm0, %xmm3

The above code needs two registers.



Similar with below testcase

typedef double v2df __attribute__((vector_size(16)));
v2df c;
double d;
void
foo (double* __restrict a)
{
c = __extension__(v2df) {*a, *a};
d = *a;
}

with option: -O2 -mavx2

GCC generates

foo(double*):
vmovsd  (%rdi), %xmm0
vmovddup%xmm0, %xmm1
vmovsd  %xmm0, d(%rip)
vmovapd %xmm1, c(%rip)

Clang

foo(double*):   # @foo(double*)
vmovddup(%rdi), %xmm0   # xmm0 = mem[0,0]
vmovaps %xmm0, c(%rip)
vmovlps %xmm0, d(%rip)
retq

[Bug target/110309] Wrong code for masked load expansion

2023-06-24 Thread crazylht at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110309

--- Comment #4 from Hongtao.liu  ---
Fixed for GCC14.

Note: unspec is not added to maskstore since vpblendd doesn't support memeory
dest, so there's no chance for a maskstore be optimized to vpblendd?

[Bug target/110309] Wrong code for masked load expansion

2023-06-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110309

--- Comment #3 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:c79476da46728e2ab17e0e546262d2f6377081aa

commit r14-2070-gc79476da46728e2ab17e0e546262d2f6377081aa
Author: liuhongt 
Date:   Tue Jun 20 15:41:00 2023 +0800

Refine maskloadmn pattern with UNSPEC_MASKLOAD.

If mem_addr points to a memory region with less than whole vector size
bytes of accessible memory and k is a mask that would prevent reading
the inaccessible bytes from mem_addr, add UNSPEC_MASKLOAD to prevent
it to be transformed to vpblendd.

gcc/ChangeLog:

PR target/110309
* config/i386/sse.md (maskload):
Refine pattern with UNSPEC_MASKLOAD.
(maskload): Ditto.
(*_load_mask): Extend mode iterator to
VI12HFBF_AVX512VL.
(*_load): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr110309.c: New test.

[Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload

2023-06-24 Thread crazylht at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237

--- Comment #9 from Hongtao.liu  ---

> So we can simply clear only MEM_EXPR (and MEM_OFFSET), that cuts off the
> problematic part of alias analysis.  Together with UNSPEC this might be
> enough to fix things.
> 
Note maskstore won't optimized to vpblendd since it doesn't support memory
dest, so I guess no need to use UNSPEC for maskstore?

[Bug tree-optimization/110371] [14 Regression] gfortran ICE "verify_gimple failed" in gfortran.dg/vect/pr51058-2.f90 since r14-2007

2023-06-24 Thread crazylht at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371

--- Comment #7 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #6)
> (In reply to Thiago Jung Bauermann from comment #0)
> > Created attachment 55387 [details]
> > Output of running gfortran with -freport-bug
> > 
> > In today's trunk (tested commit 33ebb0dff9bb "configure: Implement
> > --enable-host-bind-now") I get these new failures on aarch64-linux-gnu:
> > 
> > Running gcc:gcc.target/aarch64/sve/aarch64-sve.exp ...
> > FAIL: gcc.target/aarch64/sve/pack_fcvt_signed_1.c scan-assembler-times
> > \\tfcvtzs\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.d\\n 2
> > FAIL: gcc.target/aarch64/sve/pack_fcvt_signed_1.c scan-assembler-times
> > \\tuzp1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> > FAIL: gcc.target/aarch64/sve/pack_fcvt_unsigned_1.c scan-assembler-times
> > \\tfcvtzu\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.d\\n 2
> > FAIL: gcc.target/aarch64/sve/pack_fcvt_unsigned_1.c scan-assembler-times
> > \\tuzp1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> > FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
> > \\tscvtf\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.s\\n 2
> > FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
> > \\tzip1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> > FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
> > \\tzip2\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> > FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
> > \\tucvtf\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.s\\n 2
> > FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
> > \\tzip1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> > FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
> > \\tzip2\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> > === gfortran tests ===
> > 
> 
> For this scan-assembler failures, It looks like gcc now generates better
> code, is it ok to adjust testcase to match new assembly?
> 
> current:
> ld1dz31.d, p7/z, [x1, x3, lsl 3]
> faddz31.d, p7/m, z31.d, z30.d
> fcvtzs  z31.d, p6/m, z31.d
> st1wz31.d, p7, [x0, x3, lsl 2]
> add x3, x3, x4
> whilelo p7.d, w3, w2
> b.any   .L3
> 
> vs 
> original
> punpklo p2.h, p0.b
> punpkhi p1.h, p0.b
> ld1dz0.d, p2/z, [x1, x3, lsl 3]
> ld1dz1.d, p1/z, [x5, x3, lsl 3]
> faddz0.d, p2/m, z0.d, z2.d
> faddz1.d, p1/m, z1.d, z2.d
> fcvtzs  z0.s, p3/m, z0.d
> fcvtzs  z1.s, p3/m, z1.d
> uzp1z0.s, z0.s, z1.s
> st1wz0.s, p0, [x0, x3, lsl 2]
> add x3, x3, x4
> whilelo p0.s, w3, w2
> b.any   .L3
> 
> 
> https://godbolt.org/z/b4cW7WKev

Or only adjust testcase for FLOAT_EXPR, not for FIX_TRUNC_EXPR to avoid float-
integer overflow.

[Bug tree-optimization/110371] [14 Regression] gfortran ICE "verify_gimple failed" in gfortran.dg/vect/pr51058-2.f90 since r14-2007

2023-06-24 Thread crazylht at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371

--- Comment #6 from Hongtao.liu  ---
(In reply to Thiago Jung Bauermann from comment #0)
> Created attachment 55387 [details]
> Output of running gfortran with -freport-bug
> 
> In today's trunk (tested commit 33ebb0dff9bb "configure: Implement
> --enable-host-bind-now") I get these new failures on aarch64-linux-gnu:
> 
> Running gcc:gcc.target/aarch64/sve/aarch64-sve.exp ...
> FAIL: gcc.target/aarch64/sve/pack_fcvt_signed_1.c scan-assembler-times
> \\tfcvtzs\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.d\\n 2
> FAIL: gcc.target/aarch64/sve/pack_fcvt_signed_1.c scan-assembler-times
> \\tuzp1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> FAIL: gcc.target/aarch64/sve/pack_fcvt_unsigned_1.c scan-assembler-times
> \\tfcvtzu\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.d\\n 2
> FAIL: gcc.target/aarch64/sve/pack_fcvt_unsigned_1.c scan-assembler-times
> \\tuzp1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
> \\tscvtf\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.s\\n 2
> FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
> \\tzip1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> FAIL: gcc.target/aarch64/sve/unpack_fcvt_signed_1.c scan-assembler-times
> \\tzip2\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
> \\tucvtf\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.s\\n 2
> FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
> \\tzip1\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
> FAIL: gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c scan-assembler-times
> \\tzip2\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 1
>   === gfortran tests ===
> 

For this scan-assembler failures, It looks like gcc now generates better code,
is it ok to adjust testcase to match new assembly?

current:
ld1dz31.d, p7/z, [x1, x3, lsl 3]
faddz31.d, p7/m, z31.d, z30.d
fcvtzs  z31.d, p6/m, z31.d
st1wz31.d, p7, [x0, x3, lsl 2]
add x3, x3, x4
whilelo p7.d, w3, w2
b.any   .L3

vs 
original
punpklo p2.h, p0.b
punpkhi p1.h, p0.b
ld1dz0.d, p2/z, [x1, x3, lsl 3]
ld1dz1.d, p1/z, [x5, x3, lsl 3]
faddz0.d, p2/m, z0.d, z2.d
faddz1.d, p1/m, z1.d, z2.d
fcvtzs  z0.s, p3/m, z0.d
fcvtzs  z1.s, p3/m, z1.d
uzp1z0.s, z0.s, z1.s
st1wz0.s, p0, [x0, x3, lsl 2]
add x3, x3, x4
whilelo p0.s, w3, w2
b.any   .L3


https://godbolt.org/z/b4cW7WKev

[Bug tree-optimization/110371] [14 Regression] gfortran ICE "verify_gimple failed" in gfortran.dg/vect/pr51058-2.f90 since r14-2007

2023-06-24 Thread crazylht at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371

--- Comment #5 from Hongtao.liu  ---
Reproduced with

typedef struct dest
{
  double m[3][3];
} dest;

typedef struct src
{
  int m[3][3];
} src;

void
foo (dest *a, src* s)
{
  for (int i = 0; i != 3; i++)
for (int j = 0; j != 3; j++)
  a->m[i][j] = s->m[i][j];
}


for aarch64-linux-gnu.

The problem is when there's more than 1 vop in vec_oprnds0, vec_dest will be
overwrited to final vectype_out, but here it's expecting cvt_type. I'm testing
below:

Staged changes
1 file changed, 10 insertions(+), 4 deletions(-)
gcc/tree-vect-stmts.cc | 14 ++

modified   gcc/tree-vect-stmts.cc
@@ -5044,7 +5044,7 @@ vectorizable_conversion (vec_info *vinfo,
  gimple **vec_stmt, slp_tree slp_node,
  stmt_vector_for_cost *cost_vec)
 {
-  tree vec_dest;
+  tree vec_dest, cvt_op;
   tree scalar_dest;
   tree op0, op1 = NULL_TREE;
   loop_vec_info loop_vinfo = dyn_cast  (vinfo);
@@ -5568,6 +5568,13 @@ vectorizable_conversion (vec_info *vinfo,
 case NONE:
   vect_get_vec_defs (vinfo, stmt_info, slp_node, ncopies,
  op0, _oprnds0);
+  /* vec_dest is intermediate type operand when multi_step_cvt.  */
+  if (multi_step_cvt)
+{
+  cvt_op = vec_dest;
+  vec_dest = vec_dsts[0];
+}
+
   FOR_EACH_VEC_ELT (vec_oprnds0, i, vop0)
 {
   /* Arguments are ready, create the new vector stmt.  */
@@ -5575,12 +5582,11 @@ vectorizable_conversion (vec_info *vinfo,
   if (multi_step_cvt)
 {
   gcc_assert (multi_step_cvt == 1);
-  new_stmt = vect_gimple_build (vec_dest, codecvt1, vop0);
-  new_temp = make_ssa_name (vec_dest, new_stmt);
+  new_stmt = vect_gimple_build (cvt_op, codecvt1, vop0);
+  new_temp = make_ssa_name (cvt_op, new_stmt);
   gimple_assign_set_lhs (new_stmt, new_temp);
   vect_finish_stmt_generation (vinfo, stmt_info, new_stmt, gsi);
   vop0 = new_temp;
-  vec_dest = vec_dsts[0];
 }
   new_stmt = vect_gimple_build (vec_dest, code1, vop0);
   new_temp = make_ssa_name (vec_dest, new_stmt);

[back]

[Bug middle-end/13421] IA32 bigmem pointer subtraction and –ftrapv option causes unjustified program abort

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13421

Andrew Pinski  changed:

   What|Removed |Added

 CC||baiwfg2 at gmail dot com

--- Comment #16 from Andrew Pinski  ---
*** Bug 110399 has been marked as a duplicate of this bug. ***

[Bug middle-end/110399] pointer substraction causes coredump with ftrapv on edge case

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110399

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Dup of bug 13421.

*** This bug has been marked as a duplicate of bug 13421 ***

[Bug middle-end/110399] pointer substraction causes coredump with ftrapv on edge case

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110399

--- Comment #1 from Andrew Pinski  ---
32 bit, w1=2
w2=2
w3=2
w4=0
w5=2

Program received signal SIGABRT, Aborted.

[Bug c/110399] New: pointer substraction causes coredump with ftrapv on edge case

2023-06-24 Thread baiwfg2 at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110399

Bug ID: 110399
   Summary: pointer substraction causes coredump with ftrapv on
edge case
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baiwfg2 at gmail dot com
  Target Milestone: ---

The demo code is :

```c
#include 
#include 
#include 
#include 

int main() {
{
char *p = (char *)0x8001;
char *q = (char *)0x7fff;
uint32_t w = p - q;
printf("32 bit, w1=%u\n", w);
}

{
char *p = (char *)0x7fff;
char *q = (char *)0x7ffd;
uint32_t w2 = p - q;
printf("w2=%u\n", w2);
}

{
char *p = (char *)0x8003;
char *q = (char *)0x8001;
uint32_t w3 = p - q;
printf("w3=%u\n", w3);
}

{
char *p = (char *)0x8001;
char *q = (char *)0x0001;
uint32_t w4 = p - q;
printf("w4=%u\n", w4); // ans is 0, not crash under -ftrapv
}

{
char *p = (char *)0x8001;
char *q = (char *)0x7fff;
uint32_t w5 = (uintptr_t)p - (uintptr_t)q;
printf("w5=%u\n", w5);
}

{
char *p = (char *)0x8001; // use uint8_t also crash
char *q = (char *)0x7fff; // use smaller num
0x0011, also crash
uint32_t w6 = p - q;
printf("w6=%u\n", w6); // crash under gcc -ftrapv, not crash under
clang -ftrapv
}

return 0;
}
```

The statement w6 = p - q cause coredump. But what program actually means do
pointer unsigned arithmetic operation. How can I make it right(that is, output
2) with ftrapv option ? I find it's ok with clang -ftrapv .

This happens on many gcc versions.

[Bug tree-optimization/110371] [14 Regression] gfortran ICE "verify_gimple failed" in gfortran.dg/vect/pr51058-2.f90 since r14-2007

2023-06-24 Thread crazylht at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371

--- Comment #4 from Hongtao.liu  ---
I'll take a look.

[Bug ada/110398] New: Program_Error sem_eval.adb:4635 explicit raise

2023-06-24 Thread aj at ianozi dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110398

Bug ID: 110398
   Summary: Program_Error sem_eval.adb:4635 explicit raise
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aj at ianozi dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Tested with godbolt: https://ada.godbolt.org/z/ezqshsxzo

Also tested on version 12 (the link is using version 13).

Steps to reproduce:
1) Create "foo.ads" with:
```
package Foo is
  subtype Bar is String (1 .. 3) with 
Dynamic_Predicate => Bar in
"ABC" | "DEF";
end Foo;
```

2) Create "foobar.ads" with:
```
with Foo;
package Foobar is
  subtype Foo_Bar is Foo.Bar;
end Foobar;
```

3) Create "foobar-nested.ads" with:
```
package Foobar.Nested is
function Test_Function
(Item : Foo_Bar) return Boolean is (True);
end Foobar.Nested;
```

4) Create "example.adb" with:
```
with Foobar.Nested;
procedure Example is
  Bug : constant Boolean := Foobar.Nested.Test_Function ("ABC");
begin
  null;
end Example;
```

It fails with:
```
gcc -c -I/app/ -g -fdiagnostics-color=always -S -fverbose-asm -masm=intel -o
/app/example.s -I- 
gnatmake: "" compilation error
+===GNAT BUG DETECTED==+
| 13.1.0 (x86_64-linux-gnu) Program_Error sem_eval.adb:4635 explicit raise |
| Error detected at example.adb:3:42   |
| Compiling|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).


/app/foobar.ads
/app/foo.ads
/app/foobar-nested.ads

compilation abandoned
Compiler returned: 4
```
(I took this from godbolt but the same error happens on my local systems)

If I changed the definition of "Test_Function" to the following it works, so
I'm guessing it has to do with the subtype:
```
function Test_Function
(Item : Foo.Bar) return Boolean is (True);
```

[Bug middle-end/77294] __builtin_object_size inconsistent for member arrays

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77294

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=64715

--- Comment #2 from Andrew Pinski  ---
I think this is an dup of bug 64715.

[Bug middle-end/44384] builtin_object_size_ treatment of multidimensional arrays is unexpected

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44384

Andrew Pinski  changed:

   What|Removed |Added

 CC||siddhesh at gcc dot gnu.org

--- Comment #6 from Andrew Pinski  ---
*** Bug 110373 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/110373] __builtin_object_size does not recognize subarrays in multi-dimensional arrays

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110373

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 44384.

*** This bug has been marked as a duplicate of bug 44384 ***

[Bug middle-end/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)

2023-06-24 Thread vincent-gcc at vinc17 dot net via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173

--- Comment #32 from Vincent Lefèvre  ---
(In reply to Jakub Jelinek from comment #31)
> (In reply to Vincent Lefèvre from comment #30)
> > (In reply to Jakub Jelinek from comment #29)
> > > I mean that if the compiler can't see it is in [0, 1], it will need
> > > to use 2 additions and or the 2 carry bits together.  But, because
> > > the ored carry bits are in [0, 1] range, all the higher limbs could
> > > be done using addc.
> > 
> > If the compiler can't see that carryin is in [0, 1], then it must not "or"
> > the carry bits; it needs to add them, as carryout may be 2.
> 
> That is not how the clang builtin works, which is why I've implemented the |
> and documented it that way, as it is a compatibility builtin.

I'm confused. In Comment 14, you said that

  *carry_out = c1 + c2;

was used. This is an addition, not an OR.

[Bug c++/110395] GCOV stuck in an infinite loop with large std::array

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110395

--- Comment #3 from Andrew Pinski  ---
Note it is not an infinite loop, just many basic blocks (over 4 of them)
causing the performance to be very very slow.

[Bug c++/110395] GCOV stuck in an infinite loop with large std::array

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110395

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Fixed in GCC 12.1.0 by the same patch which fixed PR 92385 .

[Bug gcov-profile/110395] GCOV stuck in an infinite loop with large std::array

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110395

--- Comment #1 from Andrew Pinski  ---
On the trunk it takes no time at all:
[apinski@xeond2 upstream-gcc-git]$ ~/upstream-gcc/bin/g++  t.cc --coverage
[apinski@xeond2 upstream-gcc-git]$ LD_LIBRARY_PATH=~/upstream-gcc/lib64 ./a.out
[apinski@xeond2 upstream-gcc-git]$ LD_LIBRARY_PATH=~/upstream-gcc/lib64
~/upstream-gcc/bin/gcov t.cc
t.gcno:cannot open notes file
t.gcda:cannot open data file, assuming not executed
No executable lines
[apinski@xeond2 upstream-gcc-git]$ LD_LIBRARY_PATH=~/upstream-gcc/lib64
~/upstream-gcc/bin/gcov a-t.cc
File '/home/apinski/upstream-gcc/include/c++/14.0.0/bits/stl_construct.h'
Lines executed:100.00% of 4
Creating 'stl_construct.h.gcov'

File '/home/apinski/upstream-gcc/include/c++/14.0.0/bits/new_allocator.h'
Lines executed:50.00% of 4
Creating 'new_allocator.h.gcov'

File '/home/apinski/upstream-gcc/include/c++/14.0.0/bits/stl_vector.h'
Lines executed:95.45% of 22
Creating 'stl_vector.h.gcov'

File '/home/apinski/upstream-gcc/include/c++/14.0.0/bits/alloc_traits.h'
Lines executed:66.67% of 3
Creating 'alloc_traits.h.gcov'

File '/home/apinski/upstream-gcc/include/c++/14.0.0/bits/allocator.h'
Lines executed:100.00% of 1
Creating 'allocator.h.gcov'

File 't.cc'
Lines executed:100.00% of 5
Creating 't.cc.gcov'

File '/home/apinski/upstream-gcc/include/c++/14.0.0/array'
No executable lines
Removing 'array.gcov'

Lines executed:89.74% of 39

real0m0.043s
user0m0.004s
sys 0m0.002s

[Bug target/78904] zero-extracts are not effective

2023-06-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:8f6c747c8638d4c3c47ba2d4c8be86909e183132

commit r14-2065-g8f6c747c8638d4c3c47ba2d4c8be86909e183132
Author: Roger Sayle 
Date:   Sat Jun 24 23:05:25 2023 +0100

i386: Add alternate representation for {and,or,xor}b %ah,%dh.

A patch that I'm working on to improve RTL simplifications in the
middle-end results in the regression of pr78904-1b.c, due to changes in
the canonical representation of high-byte (%ah, %bh, %ch, %dh) logic.
See also PR target/78904.

This patch avoids/prevents those failures by adding support for the
alternate representation, duplicating the existing *qi_ext_2
as *qi_ext_3 (the new version also replacing any_or with
any_logic to provide *andqi_ext_3 in the same pattern).  Removing
the original pattern isn't trivial, as it's generated by define_split,
but this can be investigated after the other pieces are approved.

The current representation of this instruction is:

(set (zero_extract:DI (reg/v:DI 87 [ aD.2763 ])
(const_int 8 [0x8])
(const_int 8 [0x8]))
(subreg:DI (xor:QI (subreg:QI (zero_extract:DI (reg:DI 94)
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)
(subreg:QI (zero_extract:DI (reg/v:DI 87 [ aD.2763 ])
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)) 0))

after my proposed middle-end improvement, we attempt to recognize:

(set (zero_extract:DI (reg/v:DI 87 [ aD.2763 ])
(const_int 8 [0x8])
(const_int 8 [0x8]))
(zero_extract:DI (xor:DI (reg:DI 94)
(reg/v:DI 87 [ aD.2763 ]))
(const_int 8 [0x8])
(const_int 8 [0x8])))

2023-06-24  Roger Sayle  

gcc/ChangeLog
* config/i386/i386.md (*qi_ext_3): New define_insn.

[Bug middle-end/109986] missing fold (~a | b) ^ a => ~(a & b)

2023-06-24 Thread vanyacpp at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109986

--- Comment #3 from Ivan Sorokin  ---
I tried to investigate why GCC is able to simplify `(a | b) ^ a` and `(a | ~b)
^ a` from comment 2, but not similarly looking `(~a | b) ^ a` from comment 0.

`(a | b) ^ a` matches the following pattern from match.pd:

/* (X | Y) ^ X -> Y & ~ X*/
(simplify
 (bit_xor:c (convert1? (bit_ior:c @@0 @1)) (convert2? @0))
 (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
  (convert (bit_and @1 (bit_not @0)

`(a | ~b) ^ a` matches another pattern:

/* (~X | C) ^ D -> (X | C) ^ (~D ^ C) if (~D ^ C) can be simplified.  */
(simplify
 (bit_xor:c (bit_ior:cs (bit_not:s @0) @1) @2)
  (bit_xor (bit_ior @0 @1) (bit_xor! (bit_not! @2) @1)))

With substitution `X = b, C = a, D = a` it gives:

(b | a) ^ (~a ^ a)
(b | a) ^ -1
~(b | a)

`(~a | b) ^ a` is not simplifiable by this pattern because it requires that `~D
^ C` is simplifiable further, but `~a ^ b` is not. In any case, even if it were
applicable it would produce `(a | b) ^ (~a ^ b)` which has more operations than
the original expression.

[Bug c++/110397] types may not be defined in parameter types leads to ICE with -fdump-tree-original (or no -quiet when invoking cc1plus directly)

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110397

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Dup of bug 93788.

*** This bug has been marked as a duplicate of bug 93788 ***

[Bug c++/93788] Segfault caused by infinite loop in cc1plus

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93788

Andrew Pinski  changed:

   What|Removed |Added

 CC||stevenxia990430 at gmail dot 
com

--- Comment #4 from Andrew Pinski  ---
*** Bug 110397 has been marked as a duplicate of this bug. ***

[Bug c++/110397] types may not be defined in parameter types leads to ICE with -fdump-tree-original (or no -quiet when invoking cc1plus directly)

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110397

--- Comment #1 from Andrew Pinski  ---
Note here is the odd thing about this issue, it only shows up some of the time.
You can reproduce it 100% of the time if you use -fdump-tree-original .
Also don't need the include of iostream (though if using godbolt you do need it
if not using -fdump-tree-original) .

[Bug c++/110344] [C++26] P2738R1 - constexpr cast from void*

2023-06-24 Thread jason at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110344

--- Comment #3 from Jason Merrill  ---
Version of the paper testcase that just adds constexpr, that we currently
reject:

#include 
struct Sheep {
  constexpr std::string_view speak() const noexcept { return "Baa"; }
};
struct Cow {
  constexpr std::string_view speak() const noexcept { return "Mooo"; }
};
class Animal_View {
private:
  const void *animal;
  std::string_view (*speak_function)(const void *);
public:
  template 
  constexpr Animal_View(const Animal )
: animal{}, speak_function{[](const void *object) {
   return static_cast(object)->speak();
 }} {}
  constexpr std::string_view speak() const noexcept {
return speak_function(animal);
  }
};
// This is the key bit here. This is a single concrete function 
// that can take anything that happens to have the "Animal_View"
// interface
constexpr std::string_view do_speak(Animal_View av) { return av.speak(); }
int main() {
  // A Cow is a cow. The only think that makes it special   
  // is that it has a "std::string_view speak() const" member   
  constexpr Cow cow;
  constexpr auto result = do_speak(cow);
  return static_cast(result.size());
}

[Bug c++/110344] [C++26] P2738R1 - constexpr cast from void*

2023-06-24 Thread jason at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110344

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill  ---
Reduced version of the paper's testcase that we already (wrongly) accept:

class Doer {
private:
  const void *ob;
  int (*fn)(const void *);
public:
  template 
  constexpr Doer(const T )
: ob{},
  fn{[](const void *p) { return static_cast(p)->doit(); }}
  {}
  constexpr int operator()() const { return fn(ob); }
};
struct Thing { constexpr int doit() const { return 42; }; };
static_assert (Doer(Thing())() == 42);

[Bug c++/110397] New: types may not be defined in parameter types leads to ICE

2023-06-24 Thread stevenxia990430 at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110397

Bug ID: 110397
   Summary: types may not be defined in parameter types leads to
ICE
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stevenxia990430 at gmail dot com
  Target Milestone: ---

The following invalid program reports an internal compiler error: Segmentation
fault.

To quickly reproduce: https://gcc.godbolt.org/z/dE96K7cGc
```
#include 

int main(){
auto sum = ([](struct A {int b; int c;}a,...){
});
return 0;
}
```

tested on gcc-trunk

[Bug c++/110394] Lambda capture receives wrong value

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394

--- Comment #7 from Andrew Pinski  ---
(In reply to jackyguo18 from comment #6)
> @Andrew Pinski - Thanks, just confirmed that that was the issue.
> 
> Why doesn't GCC choose to delete the function (thus causing the weird
> behaviour) early at lower optimization levels?
> 
> Seems kinda strange it would work at -O2.

Most likely inlining more and being more agressive of doing some optimizations.
Since it is undefined behavior if you use the object after the lifetime ends,
it is just happened to work at different levels of optimization really.

[Bug c++/110394] Lambda capture receives wrong value

2023-06-24 Thread jackyguo18 at hotmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394

jackyguo18 at hotmail dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from jackyguo18 at hotmail dot com ---
@Andrew Pinski - Thanks, just confirmed that that was the issue.

Why doesn't GCC choose to delete the function (thus causing the weird
behaviour) early at lower optimization levels?

Seems kinda strange it would work at -O2.

[Bug c++/110394] Lambda capture receives wrong value

2023-06-24 Thread jackyguo18 at hotmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394

--- Comment #5 from jackyguo18 at hotmail dot com ---
@Andrew Pinski - Thanks, just confirmed that that was the issue.

Why doesn't GCC choose to delete the function (thus causing the weird
behaviour) early at lower optimization levels?

Seems kinda strange it would work at -O2.

[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32

2023-06-24 Thread brechtsanders at users dot sourceforge.net via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678

--- Comment #3 from Brecht Sanders  
---
Any pointers on which files to edit in order to support aarch64-mingw ?

I think it won't require reinventing the wheel as it will probably be a mix of
existing *-mingw and aarch64-* stuff...

[Bug middle-end/102253] scalability issues with large loop depth

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253

--- Comment #5 from Andrew Pinski  ---
On the trunk with the original testcase here we get:
 tree copy headers  :  12.16 ( 19%)   0.01 (  2%)  21.57 ( 28%)
  771k (  0%)


(I suspect the rest is due to not setting release checking ...)

[Bug rtl-optimization/110390] ICE on valid code on x86_64-linux-gnu with sel-scheduling: in av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.cc:3609

2023-06-24 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390

--- Comment #1 from Zhendong Su  ---
Another reproducer with fewer flags (and affects 12.* and later).

Compiler Explorer: https://godbolt.org/z/fYqEz9EWx

[603] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230624 (experimental) [master r14-924-gd709841ae0f] (GCC)
[604] %
[604] % gcctk -O3 -fsel-sched-pipelining -fschedule-insns
-fselective-scheduling2 -fPIC small.c
during RTL pass: sched2
small.c: In function ‘h’:
small.c:20:1: internal compiler error: in
av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.cc:3609
   20 | }
  | ^
0x7d635a av_set_could_be_blocked_by_bookkeeping_p
../../gcc-trunk/gcc/sel-sched.cc:3609
0x7d635a code_motion_process_successors
../../gcc-trunk/gcc/sel-sched.cc:6386
0x7d635a code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.cc:6608
0xf85b69 code_motion_process_successors
../../gcc-trunk/gcc/sel-sched.cc:6342
0xf85b69 code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.cc:6608
0xf86c18 find_used_regs
../../gcc-trunk/gcc/sel-sched.cc:3272
0xf86c18 collect_unavailable_regs_from_bnds
../../gcc-trunk/gcc/sel-sched.cc:1586
0xf86c18 find_best_reg_for_expr
../../gcc-trunk/gcc/sel-sched.cc:1649
0xf8976c fill_vec_av_set
../../gcc-trunk/gcc/sel-sched.cc:3784
0xf8976c fill_ready_list
../../gcc-trunk/gcc/sel-sched.cc:4014
0xf8976c find_best_expr
../../gcc-trunk/gcc/sel-sched.cc:4374
0xf8976c fill_insns
../../gcc-trunk/gcc/sel-sched.cc:5535
0xf8976c schedule_on_fences
../../gcc-trunk/gcc/sel-sched.cc:7353
0xf8976c sel_sched_region_2
../../gcc-trunk/gcc/sel-sched.cc:7491
0xf8a928 sel_sched_region_1
../../gcc-trunk/gcc/sel-sched.cc:7533
0xf8bf46 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.cc:7634
0xf8bf46 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.cc:7619
0xf8c0e9 run_selective_scheduling()
../../gcc-trunk/gcc/sel-sched.cc:7720
0xf6d7ed rest_of_handle_sched2
../../gcc-trunk/gcc/sched-rgn.cc:3743
0xf6d7ed execute
../../gcc-trunk/gcc/sched-rgn.cc:3890
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.
[605] %
[605] % cat small.c
static int a;
int b, c, d, g;
long e, f;
extern void l(char *);
void h() {
  char i;
  int j = 1 >> f / b;
 L:
  f = -(-(f % g || a) * (c && f | e));
  if (a > e)
l("");
  if (f) {
l("A");
i = j / g;
  }
  if (a)
goto L;
  d = i;
  a = 0;
}

[Bug middle-end/102253] scalability issues with large loop depth

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253

--- Comment #4 from Andrew Pinski  ---
VRP/ranger uses SCEV now so it might even be worse, the testcase from PR 110396
has that behavior too.

[Bug middle-end/102253] scalability issues with large loop depth

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253

Andrew Pinski  changed:

   What|Removed |Added

 CC||luydorarko at vusra dot com

--- Comment #3 from Andrew Pinski  ---
*** Bug 110396 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/110396] Compile-time hog with -O2 and -O3

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110396

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Andrew Pinski  ---
This is basically a dup of bug 102253. The problem is there is a known
scalability issues with large loop depth.

How did you generate this testcase, is it from real code or just generated to
try to hit some compile bugs?

*** This bug has been marked as a duplicate of bug 102253 ***

[Bug tree-optimization/110396] Compile-time hog with -O2 and -O3

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110396

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |tree-optimization

--- Comment #1 from Andrew Pinski  ---
#0  0x012f8732 in hash_table_mod1 (index=5, hash=165) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/hash-table.h:344
#1  hash_table::find_slot_with_hash
(insert=INSERT, hash=165, comparable=, this=0x77600b28) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/hash-table.h:1051
#2  hash_table::find_slot (insert=INSERT,
value=, this=0x77600b28) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/hash-table.h:435
#3  find_var_scev_info (instantiated_below=0x75247b40, var=0x75159360)
at /home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:358
#4  0x012f9312 in get_scalar_evolution (scalar=0x75159360,
instantiated_below=0x75247b40) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:556
#5  analyze_scalar_evolution (loop=0x7514eaf0, var=0x75159360) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:2020
#6  0x012f8aa7 in interpret_condition_phi
(condition_phi=0x751fbd00, loop=0x7514eaf0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1603
#7  analyze_scalar_evolution_1 (loop=0x7514eaf0, var=0x751f5dc8) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1969
#8  0x012f8b5b in analyze_scalar_evolution_1 (loop=0x7514e960,
var=0x751f5dc8) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1950
#9  0x012f94e5 in analyze_scalar_evolution (loop=0x7514e960,
var=0x751f5dc8) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:2031
#10 0x012f8aa7 in interpret_condition_phi
(condition_phi=0x75209400, loop=0x7514e960) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1603
#11 analyze_scalar_evolution_1 (loop=0x7514e960, var=0x75207870) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1969
#12 0x012f8b5b in analyze_scalar_evolution_1 (loop=0x7514e7d0,
var=0x75207870) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1950
#13 0x012f94e5 in analyze_scalar_evolution (loop=0x7514e7d0,
var=0x75207870) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:2031
#14 0x012f8aa7 in interpret_condition_phi
(condition_phi=0x7520ab00, loop=0x7514e7d0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1603
#15 analyze_scalar_evolution_1 (loop=0x7514e7d0, var=0x75161900) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1969
#16 0x012f8b5b in analyze_scalar_evolution_1 (loop=0x7514e640,
var=0x75161900) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1950
#17 0x012f94e5 in analyze_scalar_evolution (loop=0x7514e640,
var=0x75161900) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:2031
#18 0x012f8aa7 in interpret_condition_phi
(condition_phi=0x75172a00, loop=0x7514e640) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1603
#19 analyze_scalar_evolution_1 (loop=0x7514e640, var=0x75159318) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1969
#20 0x012f8b5b in analyze_scalar_evolution_1 (loop=0x7514e4b0,
var=0x75159318) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1950
#21 0x012f94e5 in analyze_scalar_evolution (loop=0x7514e4b0,
var=0x75159318) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:2031
#22 0x012f8aa7 in interpret_condition_phi
(condition_phi=0x7520d300, loop=0x7514e4b0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1603
#23 analyze_scalar_evolution_1 (loop=0x7514e4b0, var=0x74d961b0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1969
#24 0x012f8b5b in analyze_scalar_evolution_1 (loop=0x7514e320,
var=0x74d961b0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1950
#25 0x012f94e5 in analyze_scalar_evolution (loop=0x7514e320,
var=0x74d961b0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:2031
#26 0x012f8aa7 in interpret_condition_phi
(condition_phi=0x7520d500, loop=0x7514e320) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1603
#27 analyze_scalar_evolution_1 (loop=0x7514e320, var=0x7505fd80) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-scalar-evolution.cc:1969
#28 0x012f8b5b in analyze_scalar_evolution_1 (loop=0x7514e190,
var=0x7505fd80) at

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-06-24 Thread anlauf at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #23 from anlauf at gcc dot gnu.org ---
You could check the input arguments for validity, e.g. using ieee_is_finite
from the intrinsic ieee_arithmetic module.

  use, intrinsic :: ieee_arithmetic, only: ieee_is_finite

...

  if (.not. ieee_is_finite (a)) then
 print *, "bad: a=", a
 stop 1
  end if

As last resort I still recommend what I wrote in comment#15: build (=link)
your executable from *.o from your project build tree with known-good objects
but replacing one candidate.o by the one from the build tree showing the
problem.

And I really mean: link only und run.

[Bug c++/110396] New: Compile-time hog with -O2 and -O3

2023-06-24 Thread luydorarko at vusra dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110396

Bug ID: 110396
   Summary: Compile-time hog with -O2 and -O3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luydorarko at vusra dot com
  Target Milestone: ---

Created attachment 55397
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55397=edit
Preprocessed file created by `-O2 -save-temps`

Compile time hog behavior can be reproduced with:
```
g++ -O2 tmp.cpp 
```
Also same behavior with `-O3`.

Compiler takes far too long (more than one hour in one case) and was killed
after a while.

Output of `g++ -v`:
```
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.1 20230429 (GCC) 
```

Attachment: a-tmp.ii file created with `g++ -O2 tmp.cpp -save-temps`

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-06-24 Thread juergen.reuter at desy dot de via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #22 from Jürgen Reuter  ---
(In reply to anlauf from comment #21)
> I forgot to mention that you need to check that the location where a symptom
> is seen sometimes may not be the location of the cause.

Indeed, I think you are right and the problem is elsewhere. I don't really know
where to continue.

[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type

2023-06-24 Thread jvdelisle at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #14 from Jerry DeLisle  ---
(In reply to Alexander Westbrooks from comment #13)
> I sent in the patch to those emails. Hopefully now the ball will start
> rolling and I can slowly get this packaged into a legitimate fix. I'll post
> updates here as I receive them.
> 
> The patch is below, if you would like to try it. I did this in the GCC 14
> code.
> 
I saw your email. Thanks for getting involved!

[Bug fortran/110360] ABI issue with character,value dummy argument

2023-06-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:3f97d10aa1ff5984d6fd657f246d3f251b254ff1

commit r14-2064-g3f97d10aa1ff5984d6fd657f246d3f251b254ff1
Author: Harald Anlauf 
Date:   Sat Jun 24 20:36:53 2023 +0200

Fortran: ABI for scalar CHARACTER(LEN=1),VALUE dummy argument [PR110360]

gcc/fortran/ChangeLog:

PR fortran/110360
* trans-expr.cc (gfc_conv_procedure_call): Truncate constant string
argument of length > 1 passed to scalar CHARACTER(1),VALUE dummy.

[Bug fortran/110360] ABI issue with character,value dummy argument

2023-06-24 Thread anlauf at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #11)
> Created attachment 55393 [details]
> Patch to truncate string argument longer than 1
> 
> This truncates the string to length 1 and appears to work on x86 / -m32 .
> Would be interesting to get feedback on big-endian platforms.

As this works here, cross-checked with valgrind, and not feedback so far,
I'll push this update and watch the testers.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-06-24 Thread anlauf at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #21 from anlauf at gcc dot gnu.org ---
I forgot to mention that you need to check that the location where a symptom
is seen sometimes may not be the location of the cause.

[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type

2023-06-24 Thread ctechnodev at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943

--- Comment #13 from Alexander Westbrooks  ---
I sent in the patch to those emails. Hopefully now the ball will start rolling
and I can slowly get this packaged into a legitimate fix. I'll post updates
here as I receive them.

The patch is below, if you would like to try it. I did this in the GCC 14 code.



diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index d09c8bc97d9..9043a4d427f 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -4063,6 +4063,21 @@ gfc_get_pdt_instance (gfc_actual_arglist *param_list,
gfc_symbol **sym,
  continue;
}

+  /* 
+Addressing PR82943, this will fix the issue where a function/subroutine is
declared as not
+a member of the PDT instance. The reason for this is because the PDT
instance did not have
+access to its template's f2k_derived namespace in order to find the
typebound procedures.
+
+The number of references to the PDT template's f2k_derived will ensure
that f2k_derived is 
+properly freed later on.
+  */
+
+  if (!instance->f2k_derived && pdt->f2k_derived)
+  {
+instance->f2k_derived = pdt->f2k_derived;
+instance->f2k_derived->refs++;
+  }
+
   /* Set the component kind using the parameterized expression.  */
   if ((c1->ts.kind == 0 || c1->ts.type == BT_CHARACTER)
   && c1->kind_expr != NULL)
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index a58c60e9828..6854edb3467 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3536,6 +3536,7 @@ void gfc_traverse_gsymbol (gfc_gsymbol *, void
(*)(gfc_gsymbol *, void *), void
 gfc_typebound_proc* gfc_get_typebound_proc (gfc_typebound_proc*);
 gfc_symbol* gfc_get_derived_super_type (gfc_symbol*);
 bool gfc_type_is_extension_of (gfc_symbol *, gfc_symbol *);
+bool gfc_pdt_is_instance_of(gfc_symbol *, gfc_symbol *);
 bool gfc_type_compatible (gfc_typespec *, gfc_typespec *);

 void gfc_copy_formal_args_intr (gfc_symbol *, gfc_intrinsic_sym *,
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 50b49d0cb83..6af55760321 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -14705,14 +14705,34 @@ resolve_typebound_procedure (gfc_symtree* stree)
  goto error;
}

-  if (CLASS_DATA (me_arg)->ts.u.derived
- != resolve_bindings_derived)
-   {
- gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of"
-" the derived-type %qs", me_arg->name, proc->name,
-me_arg->name, , resolve_bindings_derived->name);
- goto error;
-   }
+  /* The derived type is not a PDT template. Resolve as usual */
+  if ( !resolve_bindings_derived->attr.pdt_template && 
+(CLASS_DATA (me_arg)->ts.u.derived != resolve_bindings_derived))
+  {
+gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of"
+" the derived-type %qs", me_arg->name, proc->name,
+me_arg->name, , resolve_bindings_derived->name);
+goto error;
+  }
+  
+  if ( resolve_bindings_derived->attr.pdt_template && 
+!gfc_pdt_is_instance_of(resolve_bindings_derived,
CLASS_DATA(me_arg)->ts.u.derived) )
+  {
+gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of"
+  " the parametric derived-type %qs", me_arg->name, proc->name,
+  me_arg->name, , resolve_bindings_derived->name);
+goto error;
+  }
+
+  if ( resolve_bindings_derived->attr.pdt_template 
+&& gfc_pdt_is_instance_of(resolve_bindings_derived,
CLASS_DATA(me_arg)->ts.u.derived)
+&& (me_arg->param_list != NULL)
+&& (gfc_spec_list_type(me_arg->param_list,
CLASS_DATA(me_arg)->ts.u.derived) != SPEC_ASSUMED))
+  {
+gfc_error ("All LEN type parameters of the passed dummy argument %qs of
%qs"
+" at %L must be ASSUMED.", me_arg->name, proc->name, );
+goto error;
+  }

   gcc_assert (me_arg->ts.type == BT_CLASS);
   if (CLASS_DATA (me_arg)->as && CLASS_DATA (me_arg)->as->rank != 0)
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 37a9e8fa0ae..77f84de0989 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -5134,6 +5134,35 @@ gfc_type_is_extension_of (gfc_symbol *t1, gfc_symbol
*t2)
   return gfc_compare_derived_types (t1, t2);
 }

+/* Check if a parameterized derived type t2 is an instance of a PDT template
t1 */
+
+bool
+gfc_pdt_is_instance_of(gfc_symbol *t1, gfc_symbol *t2)
+{
+  if ( !t1->attr.pdt_template || !t2->attr.pdt_type )
+return false;
+
+  /* 
+in decl.cc, gfc_get_pdt_instance, a pdt instance is given a 3 character
prefix "Pdt", followed 
+by an underscore list of the kind parameters, up to a maximum of 8. 
+
+So to check if a PDT Type corresponds to the template, extract the core
derive_type name,
+and then see if it is type compatible by name...
+
+For example:
+
+Pdtf_2_2 -> extract out the 'f' -> see if the derived type 'f' is
compatible with symbol t1
+  */
+
+  // Starting at index 3 of

[Bug c++/110394] Lambda capture receives wrong value

2023-06-24 Thread xry111 at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #4 from Xi Ruoyao  ---
(In reply to Andrew Pinski from comment #3)
> You can also try -fno-lifetime-dse to see if you get the behavior you were
> expecting too. Though I am not sure it will help extend the lifetime of the
> temporary here ...
> 
> 
> https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Optimize-Options.html#index-
> flifetime-dse

-fstack-reuse=named_vars maybe needed as well.  -flifetime-dse preserves the
stores outside of the lifetime, and -fstack-reuse=named_vars disallows reusing
the stack space of the temporary object for other objects.

[Bug c++/110394] Lambda capture receives wrong value

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394

--- Comment #3 from Andrew Pinski  ---
You can also try -fno-lifetime-dse to see if you get the behavior you were
expecting too. Though I am not sure it will help extend the lifetime of the
temporary here ...


https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Optimize-Options.html#index-flifetime-dse

[Bug c++/110394] Lambda capture receives wrong value

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-06-24
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
I am almost think this is a bug in your code.
Take:

  auto wait_handle = tc::g_postbox->wait(
"UpdateInputs"sv, [=](const msgpack::object& obj) -> bool {

  });


The temporary for tc::postbox::acceptor_type will end its lifetime at the end
of that statement but tc::g_postbox->wait stores it off into m_awaiters.

And then gets poped off with:
  wait_handle.await();


You can fix this via extending the temporary via:
```
  tc::postbox::acceptor_type t = [=](const msgpack::object& obj) -> bool {
auto [rcv_index, rcv_value] = obj.as>();
tc::tracef(M64MSG_VERBOSE, "index = {}", index);
if (rcv_index != index)
  return false;

keys->Value = rcv_value;
return true;
  };
  auto wait_handle = tc::g_postbox->wait(
"UpdateInputs"sv, t);

```


Note `-fsantize=address` should catch this at runtime too.

[Bug gcov-profile/110395] New: GCOV stuck in an infinite loop with large std::array

2023-06-24 Thread carlosgalvezp at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110395

Bug ID: 110395
   Summary: GCOV stuck in an infinite loop with large std::array
   Product: gcc
   Version: 9.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlosgalvezp at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi!

We are bumping from GCC 7.5.0 to GCC 9.4.0 (Ubuntu 20.04) and observe that GCOV
is stuck when analyzing the following minimal repro code:

#include 
#include 

template 
class StaticVector
{
 public:
StaticVector() = default;
void foo(){}

 private:
std::array data{};
};

class Foo
{
StaticVector, 4> data_{};
};

int main()
{
Foo f;
return 0;
}


$ g++ --coverage main.cpp
$ ./a.out
$ gcov main.cpp

The problem goes away if I remove the value initialization for std::array in
the StaticVector class (i.e. I leave the member "data" uninitialized).

The same problem happens also on GCC 11 

What might be the reason for this? 

Thanks!

[Bug c++/110394] Lambda capture receives wrong value

2023-06-24 Thread jackyguo18 at hotmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394

--- Comment #1 from jackyguo18 at hotmail dot com ---
Created attachment 55396
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55396=edit
.ii file which triggers the bug

I couldn't attach the original .ii file, so I had to compress it under gzip.

[Bug other/110394] New: Lambda capture receives wrong value

2023-06-24 Thread jackyguo18 at hotmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394

Bug ID: 110394
   Summary: Lambda capture receives wrong value
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jackyguo18 at hotmail dot com
  Target Milestone: ---

Note that this doesn't occur in Clang, and to my knowledge, disabling strict
aliasing and overflow would make no difference.

The code submitted here is actually part of a larger library. When I go to
debug it, a lambda in `GetKeys(int index, BUTTONS* keys)` captures the wrong
value for `index`--it should be 0, but it's 23.

Changing the capture type from value to reference causes the lambda to
inexplicably call the address 0x17 (decimal 23).

[Bug tree-optimization/110389] [12/13/14 Regression] wrong code at -Os and -O2 with "-fno-tree-ch -fno-expensive-optimizations -fno-ivopts -fno-tree-loop-ivcanon" on x86_64-linux-gnu

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110389

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.4
 Ever confirmed|0   |1
Summary|wrong code at -Os and -O2   |[12/13/14 Regression] wrong
   |with "-fno-tree-ch  |code at -Os and -O2 with
   |-fno-expensive-optimization |"-fno-tree-ch
   |s -fno-ivopts   |-fno-expensive-optimization
   |-fno-tree-loop-ivcanon" on  |s -fno-ivopts
   |x86_64-linux-gnu|-fno-tree-loop-ivcanon" on
   ||x86_64-linux-gnu
   Last reconfirmed||2023-06-24

--- Comment #1 from Andrew Pinski  ---
Something goes really wrong in DOM3.

  _7 = e.5_26 + 1;
  if (_7 <= 2)
goto ; [89.57%]
  else
goto ; [10.43%]

is optimized to always true.

[Bug rtl-optimization/110391] [12/13/14 Regression] wrong code at -O2 and -O3 with "-fsel-sched-pipelining -fselective-scheduling2" on x86_64-linux-gnu

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110391

Andrew Pinski  changed:

   What|Removed |Added

Summary|wrong code at -O2 and -O3   |[12/13/14 Regression] wrong
   |with|code at -O2 and -O3 with
   |"-fsel-sched-pipelining |"-fsel-sched-pipelining
   |-fselective-scheduling2" on |-fselective-scheduling2" on
   |x86_64-linux-gnu|x86_64-linux-gnu
Version|unknown |14.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=95123
   Target Milestone|--- |12.4

[Bug tree-optimization/110392] [13/14 Regression] ICE at -O3 with "-O3 -Wall -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-copy-prop -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop": in find_var_cmp

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110392

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-24

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/110392] ICE at -O3 with "-O3 -Wall -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-copy-prop -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop": in find_var_cmp_const, at gimple-p

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110392

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE at -O3 with "-w -O3 |ICE at -O3 with "-O3 -Wall
   |-Wall -fno-tree-vrp |-fno-tree-vrp
   |-fno-tree-dominator-opts|-fno-tree-dominator-opts
   |-fno-tree-copy-prop |-fno-tree-copy-prop
   |-fno-tree-fre -fno-tree-ccp |-fno-tree-fre -fno-tree-ccp
   |-fno-tree-forwprop": in |-fno-tree-forwprop": in
   |find_var_cmp_const, at  |find_var_cmp_const, at
   |gimple-predicate-analysis.c |gimple-predicate-analysis.c
   |c:257   |c:257
Version|unknown |14.0
   Target Milestone|--- |13.2
   Keywords||ice-on-valid-code

[Bug ada/105212] -gnatwu gives false error message for certain arrays.

2023-06-24 Thread service at totalplanlos dot de via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105212

--- Comment #2 from Honki Tonk  ---
The error still occurs with version 13.1.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-06-24 Thread anlauf at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #20 from anlauf at gcc dot gnu.org ---
If that doesn't help: there appear to be recent optimizations for divmod.
Try declaring a1, a2 as volatile.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-06-24 Thread juergen.reuter at desy dot de via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #19 from Jürgen Reuter  ---
(In reply to anlauf from comment #18)
> (In reply to Jürgen Reuter from comment #17)
> > How would I set up such a bisection for the n git commits between June 12 to
> > June 19? Unfortunately, I cannot really get a small reproducer 
> 
> I didn't mean that.  I meant doing a bisection on the .o files of your code.
> 
> But given that you have isolated a procedure, that is not necessary.
> 
> You could try to defeat optimization by using a temporary v0 for v and
> declare it as volatile.  Would be interesting to see if that makes a
> difference.

I tried both things, or at least partially, didn't help. It also is a problem
only when called in a very complicated setup in our program, in complicated
setups, it works. I fear, we have to change the functionality in our program,
sadly, if we are not to be stuck for all times to version of gcc < 14.

[Bug rtl-optimization/110393] New: ICE at -O3 with "-fselective-scheduling2 -fPIC": in move_op_ascend, at sel-sched.cc:6150

2023-06-24 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110393

Bug ID: 110393
   Summary: ICE at -O3 with "-fselective-scheduling2 -fPIC": in
move_op_ascend, at sel-sched.cc:6150
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a regression from 12.*, and affects 13.* and later.

Compiler Explorer: https://godbolt.org/z/Tqsbhv461

[629] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230623 (experimental) [master r14-924-gd709841ae0f] (GCC)
[630] %
[630] % gcctk -O3 -fselective-scheduling2 -fPIC small.c
during RTL pass: sched2
small.c: In function ‘main’:
small.c:40:1: internal compiler error: in move_op_ascend, at sel-sched.cc:6150
   40 | }
  | ^
0x7d606f move_op_ascend
../../gcc-trunk/gcc/sel-sched.cc:6150
0x7d606f move_op_ascend
../../gcc-trunk/gcc/sel-sched.cc:6142
0xf85287 code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.cc:6648
0xf85dd9 move_op
../../gcc-trunk/gcc/sel-sched.cc:6702
0xf85dd9 move_exprs_to_boundary
../../gcc-trunk/gcc/sel-sched.cc:5223
0xf85dd9 schedule_expr_on_boundary
../../gcc-trunk/gcc/sel-sched.cc:5436
0xf8834f fill_insns
../../gcc-trunk/gcc/sel-sched.cc:5578
0xf8834f schedule_on_fences
../../gcc-trunk/gcc/sel-sched.cc:7353
0xf8834f sel_sched_region_2
../../gcc-trunk/gcc/sel-sched.cc:7491
0xf8a568 sel_sched_region_1
../../gcc-trunk/gcc/sel-sched.cc:7533
0xf8bb86 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.cc:7634
0xf8bb86 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.cc:7619
0xf8bd29 run_selective_scheduling()
../../gcc-trunk/gcc/sel-sched.cc:7720
0xf6d42d rest_of_handle_sched2
../../gcc-trunk/gcc/sched-rgn.cc:3743
0xf6d42d execute
../../gcc-trunk/gcc/sched-rgn.cc:3890
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
[631] %
[631] % cat small.c
extern void r();
struct a {
  int b : 21;
  int c : 17;
  volatile int d : 3;
  int e;
} l;
int f, j, m, n, o;
volatile struct a g;
static struct a h, k;
static int i;
int main() {
  int p, u, v;
q:
  if (m) {
r();
if (j) {
  k.b = 0;
  goto s;
}
  }
  h.d;
t:
  u = f * (i || g.b | k.e);
  v = (f || 0) * (l.c - (50 & u));
  if (v) {
if (k.c)
  goto q;
  s:
if (u)
  goto w;
  }
  short a = p;
  o = -a * n;
  h.d = 0 > h.d;
  p = o;
  goto t;
w:
  return 0;
}

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-06-24 Thread anlauf at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #18 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #17)
> How would I set up such a bisection for the n git commits between June 12 to
> June 19? Unfortunately, I cannot really get a small reproducer 

I didn't mean that.  I meant doing a bisection on the .o files of your code.

But given that you have isolated a procedure, that is not necessary.

You could try to defeat optimization by using a temporary v0 for v and
declare it as volatile.  Would be interesting to see if that makes a
difference.

[Bug tree-optimization/110392] New: ICE at -O3 with "-w -O3 -Wall -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-copy-prop -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop": in find_var_cmp_const, at

2023-06-24 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110392

Bug ID: 110392
   Summary: ICE at -O3 with "-w -O3 -Wall -fno-tree-vrp
-fno-tree-dominator-opts -fno-tree-copy-prop
-fno-tree-fre -fno-tree-ccp -fno-tree-forwprop": in
find_var_cmp_const, at
gimple-predicate-analysis.cc:257
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a regression from 12.*, and affects 13.* and later.

Compiler Explorer: https://godbolt.org/z/hWsKnGdqz

[528] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230623 (experimental) [master r14-924-gd709841ae0f] (GCC)
[529] %
[529] % gcctk -w -O3 -Wall -fno-tree-vrp -fno-tree-dominator-opts
-fno-tree-copy-prop -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop small.c
during GIMPLE pass: uninit
small.c: In function ‘b’:
small.c:2:6: internal compiler error: in find_var_cmp_const, at
gimple-predicate-analysis.cc:257
2 | void b() {
  |  ^
0x8c4b9b find_var_cmp_const
../../gcc-trunk/gcc/gimple-predicate-analysis.cc:257
0x1d636a3 uninit_analysis::overlap(gphi*, unsigned int, hash_set >*, predicate const&)
../../gcc-trunk/gcc/gimple-predicate-analysis.cc:649
0x1d631a8 uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*,
unsigned int, hash_set >*)
../../gcc-trunk/gcc/gimple-predicate-analysis.cc:2226
0x1d637d9 uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*,
unsigned int)
../../gcc-trunk/gcc/gimple-predicate-analysis.cc:2264
0x1213ee0 find_uninit_use
../../gcc-trunk/gcc/tree-ssa-uninit.cc:1243
0x1214916 warn_uninitialized_phi
../../gcc-trunk/gcc/tree-ssa-uninit.cc:1313
0x1214916 execute_late_warn_uninitialized
../../gcc-trunk/gcc/tree-ssa-uninit.cc:1434
0x1214916 execute
../../gcc-trunk/gcc/tree-ssa-uninit.cc:1451
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
[530] %
[530] % cat small.c
int a;
void b() {
  int c, d, f, g, i;
  if (a)
goto L2;
  for (;;) {
g = 2;
for (;;) {
  if (f)
  L1:
if (d)
  break;
  g | f && c;
  if (c)
goto L1;
  i = ~c;
L2:
  c = i;
}
  }
}

[Bug c/92220] -Wconversion generates a false warning for modulo expression when the modulus has smaller type

2023-06-24 Thread xry111 at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92220

--- Comment #6 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #5)
> Unfortunately the value range info is not available in the frontend :(.

Here "value range info" means the info from the VRP pass.  For this case we can
specially check MOD_EXPR, but doing so won't help with the general cases like
"return a % b / 2;".

[Bug c/92220] -Wconversion generates a false warning for modulo expression when the modulus has smaller type

2023-06-24 Thread xry111 at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92220

--- Comment #5 from Xi Ruoyao  ---
Unfortunately the value range info is not available in the frontend :(.

[Bug rtl-optimization/110317] [12/13/14 Regression] ICE at -O2 and -O3 with "-fno-tree-pre -fno-tree-dce -fno-tree-dse -fselective-scheduling2": in move_exprs_to_boundary, at sel-sched.cc:5228

2023-06-24 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110317

--- Comment #1 from Zhendong Su  ---
Here is another related reproducer that only needs -fselective-scheduling2.

It affects 13.* and later.

Compiler Explorer: https://godbolt.org/z/zY7vMh9rj

[593] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230623 (experimental) [master r14-924-gd709841ae0f] (GCC) 
[594] % 
[594] % gcctk -O3 -fselective-scheduling2 small.c
during RTL pass: sched2
small.c: In function ‘j’:
small.c:17:1: internal compiler error: in move_exprs_to_boundary, at
sel-sched.cc:5228
   17 | }
  | ^
0x7d651c move_exprs_to_boundary
../../gcc-trunk/gcc/sel-sched.cc:5228
0x7d651c schedule_expr_on_boundary
../../gcc-trunk/gcc/sel-sched.cc:5436
0xf8834f fill_insns
../../gcc-trunk/gcc/sel-sched.cc:5578
0xf8834f schedule_on_fences
../../gcc-trunk/gcc/sel-sched.cc:7353
0xf8834f sel_sched_region_2
../../gcc-trunk/gcc/sel-sched.cc:7491
0xf8a568 sel_sched_region_1
../../gcc-trunk/gcc/sel-sched.cc:7533
0xf8bb86 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.cc:7634
0xf8bb86 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.cc:7619
0xf8bd29 run_selective_scheduling()
../../gcc-trunk/gcc/sel-sched.cc:7720
0xf6d42d rest_of_handle_sched2
../../gcc-trunk/gcc/sched-rgn.cc:3743
0xf6d42d execute
../../gcc-trunk/gcc/sched-rgn.cc:3890
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
[595] % 
[595] % cat small.c
int a, b, *c, d, f, h;
int ***volatile e;
short g;
extern int k();
static void i() {
  while (1) {
if (d && f)
  while (1)
;
h = 1;
(a ^= ***e) | (*c ^= (g = (b > 8) << h) && f);
  }
}
void j() {
  if (b && k())
i();
}

[Bug rtl-optimization/110391] wrong code at -O2 and -O3 with "-fsel-sched-pipelining -fselective-scheduling2" on x86_64-linux-gnu

2023-06-24 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110391

Zhendong Su  changed:

   What|Removed |Added

Summary|wrong code at -O2 and -O3   |wrong code at -O2 and -O3
   |with "on x86_64-linux-gnu   |with
   ||"-fsel-sched-pipelining
   ||-fselective-scheduling2" on
   ||x86_64-linux-gnu

--- Comment #1 from Zhendong Su  ---
It appears to be a regression from 11.*, and affects 12.* and later.

Compiler Explorer: https://godbolt.org/z/WEhzh66Pz

[571] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230623 (experimental) [master r14-924-gd709841ae0f] (GCC) 
[572] % 
[572] % gcctk -O3 -fsel-sched-pipelining -fselective-scheduling2 -fPIC small.c
[573] % ./a.out
Floating point exception
[574] % 
[574] % gcctk -O3 small.c; ./a.out
[575] % 
[575] % cat small.c
int printf(const char *, ...);
int a, d, b, i = 2, e;
static unsigned c = 1;
char f, g = 1;
void j() {
k:
  if (b)
for (;;)
  __builtin_abort();
  unsigned l = i && 2 / c * d % g;
  if (a) {
l = c;
g = i;
if (d > 1) {
  printf("%d", c);
  goto k;
}
  }
  a = c = l;
}
int main() {
  a = -2;
  j();
  i = 0;
  f = ~c;
  if (f > 0) {
printf("%d", f);
a = 2 % i;
  }
  return 0;
}

[Bug rtl-optimization/110391] New: wrong code at -O2 and -O3 with "on x86_64-linux-gnu

2023-06-24 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110391

Bug ID: 110391
   Summary: wrong code at -O2 and -O3 with "on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[Bug middle-end/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)

2023-06-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173

--- Comment #31 from Jakub Jelinek  ---
(In reply to Vincent Lefèvre from comment #30)
> (In reply to Jakub Jelinek from comment #29)
> > (In reply to Vincent Lefèvre from comment #28)
> > > What do you mean by "the first additions will be less optimized"? (If you
> > > don't know anything about the initial carryin and the arguments, you can't
> > > optimize at all, AFAIK.)
> > 
> > I mean that if the compiler can't see it is in [0, 1], it will need to use 2
> > additions and or the 2 carry bits together.  But, because the ored carry
> > bits are in [0, 1] range, all the higher limbs could be done using addc.
> 
> If the compiler can't see that carryin is in [0, 1], then it must not "or"
> the carry bits; it needs to add them, as carryout may be 2.

That is not how the clang builtin works, which is why I've implemented the |
and documented it that way, as it is a compatibility builtin.

[Bug middle-end/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)

2023-06-24 Thread vincent-gcc at vinc17 dot net via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173

--- Comment #30 from Vincent Lefèvre  ---
(In reply to Jakub Jelinek from comment #29)
> (In reply to Vincent Lefèvre from comment #28)
> > What do you mean by "the first additions will be less optimized"? (If you
> > don't know anything about the initial carryin and the arguments, you can't
> > optimize at all, AFAIK.)
> 
> I mean that if the compiler can't see it is in [0, 1], it will need to use 2
> additions and or the 2 carry bits together.  But, because the ored carry
> bits are in [0, 1] range, all the higher limbs could be done using addc.

If the compiler can't see that carryin is in [0, 1], then it must not "or" the
carry bits; it needs to add them, as carryout may be 2. So each part of the
whole chain would need 2 __builtin_add_overflow and an addition of the carry
bits. However, if the compiler can detect that at some point, the arguments
cannot be both 0x at the same time (while carryin is in [0, 2]), then
an optimization is possible for the rest of the chain.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-06-24 Thread juergen.reuter at desy dot de via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #17 from Jürgen Reuter  ---
How would I set up such a bisection for the n git commits between June 12 to
June 19? Unfortunately, I cannot really get a small reproducer

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-06-24 Thread juergen.reuter at desy dot de via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #16 from Jürgen Reuter  ---
It seems that it is this function where the NaNs appear:
  function mult_mod (a, b, c, m) result (v)
real(default), intent(in) :: a
real(default), intent(in) :: b
real(default), intent(in) :: c
real(default), intent(in) :: m
real(default) :: v
integer :: a1
real(default) :: a2
v = a * b + c
if (v >= two53 .or. v <= -two53) then
   a1 = int (a / two17)
   a2 = a - a1 * two17
   v = mod (a1 * b, m)
   v = v * two17 + a2 * b + c
end if
v = mod (v, m)
if (v < 0.0_default) v = v + m
  end function mult_mod

particularly mod (v, m) gets evaluated to NaN, even if a replace it with
v = mod (v0, m) to avoid potential aliasing problems. It appears only in a very
complex setup, not in a 100 line program.

[Bug tree-optimization/110388] wrong code with on x86_64-linux-gnu

2023-06-24 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110388

Zhendong Su  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Zhendong Su  ---
(In reply to Xi Ruoyao from comment #1)
> Is this created unintentionally?

Sorry; indeed unintended, and close it as invalid

[Bug tree-optimization/110388] wrong code with on x86_64-linux-gnu

2023-06-24 Thread xry111 at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110388

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #1 from Xi Ruoyao  ---
Is this created unintentionally?

[Bug rtl-optimization/110390] New: ICE on valid code on x86_64-linux-gnu with sel-scheduling: in av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.cc:3609

2023-06-24 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390

Bug ID: 110390
   Summary: ICE on valid code on x86_64-linux-gnu with
sel-scheduling: in
av_set_could_be_blocked_by_bookkeeping_p, at
sel-sched.cc:3609
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a regression from 12.*, and affects 13.* and later.

Compiler Explorer: https://godbolt.org/z/Gd15nnhrv

[571] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230623 (experimental) [master r14-924-gd709841ae0f] (GCC)
[572] %
[572] % gcctk -O2 -fno-tree-dce -fsel-sched-pipelining -fno-dce -fno-tree-ter
-fno-gcse -fno-ssa-phiopt -fno-tree-dse -fno-if-conversion -fno-thread-jumps
-fselective-scheduling2 -fno-guess-branch-probability small.c
during RTL pass: sched2
small.c: In function ‘main’:
small.c:23:1: internal compiler error: in
av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.cc:3609
   23 | }
  | ^
0x7d6356 av_set_could_be_blocked_by_bookkeeping_p
../../gcc-trunk/gcc/sel-sched.cc:3609
0x7d6356 code_motion_process_successors
../../gcc-trunk/gcc/sel-sched.cc:6386
0x7d6356 code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.cc:6608
0xf857a9 code_motion_process_successors
../../gcc-trunk/gcc/sel-sched.cc:6342
0xf857a9 code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.cc:6608
0xf857a9 code_motion_process_successors
../../gcc-trunk/gcc/sel-sched.cc:6342
0xf857a9 code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.cc:6608
0xf86858 find_used_regs
../../gcc-trunk/gcc/sel-sched.cc:3272
0xf86858 collect_unavailable_regs_from_bnds
../../gcc-trunk/gcc/sel-sched.cc:1586
0xf86858 find_best_reg_for_expr
../../gcc-trunk/gcc/sel-sched.cc:1649
0xf893ac fill_vec_av_set
../../gcc-trunk/gcc/sel-sched.cc:3784
0xf893ac fill_ready_list
../../gcc-trunk/gcc/sel-sched.cc:4014
0xf893ac find_best_expr
../../gcc-trunk/gcc/sel-sched.cc:4374
0xf893ac fill_insns
../../gcc-trunk/gcc/sel-sched.cc:5535
0xf893ac schedule_on_fences
../../gcc-trunk/gcc/sel-sched.cc:7353
0xf893ac sel_sched_region_2
../../gcc-trunk/gcc/sel-sched.cc:7491
0xf8a568 sel_sched_region_1
../../gcc-trunk/gcc/sel-sched.cc:7533
0xf8bb86 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.cc:7634
0xf8bb86 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.cc:7619
0xf8bd29 run_selective_scheduling()
../../gcc-trunk/gcc/sel-sched.cc:7720
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
[573] %
[573] % cat small.c
int a, b, c, d, e, f;
extern void k();
int main() {
  int h = 6, i;
j:
  if (b)
h = 0;
  if (c) {
k();
goto l;
  }
  int m = i = 0;
  for (; i < 2; i++)
;
  long n = a;
l:
  d = ~m || n ^ (a & f);
  m = f;
  f = ~(n && h | e) && a;
  if (h && a)
goto j;
  return 0;
}

[Bug tree-optimization/110389] New: wrong code at -Os and -O2 with "-fno-tree-ch -fno-expensive-optimizations -fno-ivopts -fno-tree-loop-ivcanon" on x86_64-linux-gnu

2023-06-24 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110389

Bug ID: 110389
   Summary: wrong code at -Os and -O2 with "-fno-tree-ch
-fno-expensive-optimizations -fno-ivopts
-fno-tree-loop-ivcanon" on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a regression from 11.*, and affects 12.* and later.

Compiler Explorer: https://godbolt.org/z/1nsvMbaPW


[567] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230623 (experimental) [master r14-924-gd709841ae0f] (GCC) 
[568] % 
[568] % gcctk -O2 -fno-tree-ch -fno-expensive-optimizations -fno-ivopts
-fno-tree-loop-ivcanon small.c
[569] % ./a.out
Segmentation fault
[570] % 
[570] % gcctk -O2 small.c; ./a.out
[571] % 
[571] % cat small.c
int a, b, c, d[3][1], e;
int main() {
  int f = 1, g;
  for (e = 0; e < 3; e++) {
if (f)
  c--;
for (g = 0; g < 1; g++) {
  if (b && a)
return 0;
  f = 0;
  d[e][g] = 1;
}
  }
  return 0;
}

[Bug tree-optimization/110388] New: wrong code with on x86_64-linux-gnu

2023-06-24 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110388

Bug ID: 110388
   Summary: wrong code with  on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[Bug c++/110380] [feature request] "-pg-constexpr=coverage-output" emit coverage metrics for constexpr code evaluated at compile time

2023-06-24 Thread gasper.azman at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110380

--- Comment #2 from Gašper Ažman  ---
-fprofile-constexpr is perfectly fine :), as long as it gets a filename
argument for the output; build automation will be thankful.

[Bug middle-end/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)

2023-06-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173

--- Comment #29 from Jakub Jelinek  ---
(In reply to Vincent Lefèvre from comment #28)
> (In reply to Jakub Jelinek from comment #27)
> > Given that the builtins exist for 10 years already, I think changing it for
> > them is too late, though they don't seem to take backwards compatibility as
> > seriously.
> > They don't document the [0, 1] restriction and the behavior implemented in
> > GCC is what I saw when trying it.
> 
> Their documentation at https://clang.llvm.org/docs/LanguageExtensions.html
> is currently just
> 
>   unsigned sum = __builtin_addc(x, y, carryin, );
> 
> But a carry for a 2-ary addition is always 0 or 1, so the [0, 1] restriction
> is implicit (by the language that is used).

That is something that would need to be said explicitly, that it is undefined
behavior if it is some other value.  Like we document that e.g. __builtin_clz
is undefined behavior on 0 input.

> What do you mean by "the first additions will be less optimized"? (If you
> don't know anything about the initial carryin and the arguments, you can't
> optimize at all, AFAIK.)

I mean that if the compiler can't see it is in [0, 1], it will need to use 2
additions and or the 2 carry bits together.  But, because the ored carry bits
are in [0, 1] range, all the higher limbs could be done using addc.

If you try clang trunk with -O2
unsigned int foo (unsigned x, unsigned y, unsigned carry_in, unsigned
*carry_out) { return __builtin_addc (x, y, carry_in, carry_out); }
unsigned int bar (unsigned x, unsigned y, unsigned carry_in, unsigned
*carry_out) { if (carry_in > 1) __builtin_unreachable (); return __builtin_addc
(x, y, carry_in, carry_out); }
it shows exactly those 2 additions, rather than trying to optimize it, in both
cases.
GCC trunk emits something comparable for the first case, and 
unsigned int foo (unsigned x, unsigned y, unsigned carry_in, unsigned
*carry_out) { return __builtin_addc (x, y, carry_in, carry_out); }
you get
addb$-1, %dl; adcl%esi, %eax
for the main work.

[Bug middle-end/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)

2023-06-24 Thread vincent-gcc at vinc17 dot net via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173

--- Comment #28 from Vincent Lefèvre  ---
(In reply to Jakub Jelinek from comment #27)
> Given that the builtins exist for 10 years already, I think changing it for
> them is too late, though they don't seem to take backwards compatibility as
> seriously.
> They don't document the [0, 1] restriction and the behavior implemented in
> GCC is what I saw when trying it.

Their documentation at https://clang.llvm.org/docs/LanguageExtensions.html is
currently just

  unsigned sum = __builtin_addc(x, y, carryin, );

But a carry for a 2-ary addition is always 0 or 1, so the [0, 1] restriction is
implicit (by the language that is used).

And in their example, the carries are always 0 or 1.

> Note, in many cases it isn't that big deal, because if carry_in is in [0, 1]
> range and compiler can see it from VRP, it can still optimize it.  And given
> that carry_out is always in [0, 1] range, for chained cases worst case the
> first additions will be less optimized but the chained will be already
> better.

What do you mean by "the first additions will be less optimized"? (If you don't
know anything about the initial carryin and the arguments, you can't optimize
at all, AFAIK.)

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-06-24 Thread anlauf at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC|anlauf at gmx dot de   |

--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #14)
> Did anybody manage to reproduce this? 
> Download https://whizard.hepforge.org/downloads/?f=whizard-3.1.2.tar.gz
> You need OCaml as a prerequisite, though.
> Then configure, make, 
> cd tests/functional_tests
> make check TESTS=nlo_9.run
> This will fail, as there are NaNs produced in our RNG module which are
> presumably caused by this regression in the tree-optimizer. At the moment I
> am deeply struggling with generating a reproducer but I don't know how tbh.

I may be telling you the obvious, but here's what I do in cases where changes
in optimization in new compilers cause failures and recompiling is expensive:

- create standalone-version of Fortran code and testcase
- have two build trees in parallel, (a) working and (b) failing
- relink by successively replacing objects in (a) by those from (b)
- run each binary until the failure occurs

In your case you are lucky in that you get a crash.

If testing is expensive, it may be worth to do bisecting on sets of objects.

I avoid building of shared libs for the project to ease testing.

Note: there might be multiple bad objects.

This works for me even with  compilers on  platforms, even if that
takes a day or two.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-06-24 Thread juergen.reuter at desy dot de via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #14 from Jürgen Reuter  ---
Did anybody manage to reproduce this? 
Download https://whizard.hepforge.org/downloads/?f=whizard-3.1.2.tar.gz
You need OCaml as a prerequisite, though.
Then configure, make, 
cd tests/functional_tests
make check TESTS=nlo_9.run
This will fail, as there are NaNs produced in our RNG module which are
presumably caused by this regression in the tree-optimizer. At the moment I am
deeply struggling with generating a reproducer but I don't know how tbh.

[Bug target/109456] `-ffixed-reg` cannot prevent using `reg` for ABI-mandated roles (argument register etc) and the behavior should be documented more clearly

2023-06-24 Thread xry111 at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456

--- Comment #14 from Xi Ruoyao  ---
(In reply to Andreas Schwab from comment #10)
> Or "other ABI-mandated fixed roles".  This also includes return value
> registers.

Hmm, even "ABI-mandated fixed roles" is not enough.  For example, or RISC-V we
have

extern int foo(char *);

int test()
{
char x[12345678];
return foo(x);
}

Then t0 is used by the function prologue, and -ffixed-t0 cannot stop it
(because the use of t0 is hard coded in the target hook).

[Bug middle-end/110375] -ftrivial-auto-var-init=zero issues with pointers to data members

2023-06-24 Thread dangelog at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375

--- Comment #4 from Giuseppe D'Angelo  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Giuseppe D'Angelo from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > The code is undefined,
> > 
> > Sure, although there are C++ proposals to make it well-defined /
> > implementatiopn-defined (see
> > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1.html and
> > https://isocpp.org/files/papers/P2795R1.html).
> > 
> > But that's beside the point, I'm not claiming that the code does not have UB
> > -- although I'm not sure whether, if -ftrivial-auto-var-init is in use, an
> > optimizer stops considering such reads as UB. At least Clang stops:
> > https://gcc.godbolt.org/z/bKW5Mccsa
> 
> But those proposals will be done in the front-end

That's not P2723R1's claim. Quoting:

"We propose to zero-initialize all objects of automatic storage duration,
making C++ safer by default.

This was implemented as an opt-in compiler flag in 2018 for LLVM [LLVMReview]
and MSVC [WinKernel], and 2021 in for GCC [GCCReview]."


This report (and Clang's) shows that that's misleading.


> while
> -ftrivial-auto-var-init=zero is a generic non-front-end option. The
> middle-end will see the right thing and that option will not have an effect
> really.


Fair enough; then, please, could this report be turned into a feature request
for the C/C++ frontends?

[Bug middle-end/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)

2023-06-24 Thread jakub at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173

--- Comment #27 from Jakub Jelinek  ---
Given that the builtins exist for 10 years already, I think changing it for
them is too late, though they don't seem to take backwards compatibility as
seriously.
They don't document the [0, 1] restriction and the behavior implemented in GCC
is what I saw when trying it.
Note, in many cases it isn't that big deal, because if carry_in is in [0, 1]
range and compiler can see it from VRP, it can still optimize it.  And given
that carry_out is always in [0, 1] range, for chained cases worst case the
first additions will be less optimized but the chained will be already better.

[Bug target/109456] `-ffixed-reg` cannot prevent using `reg` for ABI-mandated roles (argument register etc) and the behavior should be documented more clearly

2023-06-24 Thread xry111 at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456

--- Comment #13 from Xi Ruoyao  ---
(In reply to gccriscvuser from comment #12)
> Updating the documentation is good, but there should also be an error
> diagnostic, right?

It would be a backward-incompatible change.  IMO it's perfectly legal to
disable a register for RA with -ffixed- but still allowing it for fixed roles. 
And I bet there are existing uses of this feature in the wild.

[Bug target/87281] qsort checking ICE in ia64_reorg building libgo

2023-06-24 Thread jbglaw--- via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281

--- Comment #14 from Jan-Benedict Glaw  ---
Still observable as of a8994014041:

[...]
  ia64-linux-gcc -Wp,-MMD,kernel/.kallsyms.o.d -nostdinc -I./arch/ia64/include
-I./arch/ia64/include/generated  -I./include -I./arch/ia64/include/uapi
-I./arch/ia64/include/generated/uapi -I.
/include/uapi -I./include/generated/uapi -include
./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include
./include/linux/compiler_types.h -D__KERNEL__ -DHAVE_WORKING_TEXT_ALIGN
-DHAVE_MODEL_SMALL_ATTRIBUTE -DHAVE_SERIALIZE_DIRECTIVE -fmacro-prefix-map=./=
-Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration
-Werror=implicit-int -Werror=return-type -Wno-format-security -funsigned-char
-std=gnu11 -pipe -ffixed-r13 -mfixed-range=f12-f15,f32-f127 -frename-registers
-fno-optimize-sibling-calls -fno-delete-null-pointer-checks -Wno-frame-address
-Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2
-fno-allow-store-data-races -Wframe-larger-than=2048 -fno-stack-protector
-Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable
-Wno-dangling-pointer -fomit-frame-pointer -ftrivial-auto-var-init=zero
-fno-stack-clash-protection -falign-functions=32 -Wdeclaration-after-statement
-Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation
-Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -Wno-array-bounds
-Wno-alloc-size-larger-than -Wimplicit-fallthrough=5 -fno-strict-overflow
-fno-stack-check -fconserve-stack -Werror=date-time
-Werror=incompatible-pointer-types -Werror=designated-init
-Wno-packed-not-aligned  -mconstant-gp  -DKBUILD_MODFILE='"kernel/kallsyms"'
-DKBUILD_BASENAME='"kallsyms"' -DKBUILD_MODNAME='"kallsyms"'
-D__KBUILD_MODNAME=kmod_kallsyms -c -o kernel/kallsyms.o kernel/kallsyms.c  
kernel/kallsyms.c: In function 'kallsyms_lookup_names':
kernel/kallsyms.c:268:1: error: qsort comparator non-negative on sorted output:
1
  268 | }
  | ^
during RTL pass: mach
kernel/kallsyms.c:268:1: internal compiler error: qsort checking failed
0x188b086 internal_error(char const*, ...)
 ???:0
0x18bf855 gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
 ???:0
0x15c7a08 schedule_block(basic_block_def**, void*)
 ???:0
0x1685c1b schedule_ebb(rtx_insn*, rtx_insn*, bool)
 ???:0
0x168622d schedule_ebbs()
 ???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [scripts/Makefile.build:252: kernel/kallsyms.o] Error 1
make[1]: *** [scripts/Makefile.build:494: kernel] Error 2
make: *** [Makefile:2026: .] Error 2

[Bug middle-end/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)

2023-06-24 Thread glisse at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173

--- Comment #26 from Marc Glisse  ---
(In reply to CVS Commits from comment #22)
> While the design of these builtins in clang is questionable,
> rather than being say
> unsigned __builtin_addc (unsigned, unsigned, bool, bool *)
> so that it is clear they add two [0, 0x] range numbers
> plus one [0, 1] range carry in and give [0, 0x] range
> return plus [0, 1] range carry out, they actually instead
> add 3 [0, 0x] values together but the carry out
> isn't then the expected [0, 2] value because
> 0xULL + 0x + 0x is 0x2fffd,
> but just [0, 1] whether there was any overflow at all.

That is very strange. I always thought that the original intent was for
__builtin_addc to assume that its third argument was in [0, 1] and generate a
single addc instruction on hardware that has it, and the type only ended up
being the same as the others for convenience (also C used not to have a bool
type). The final overflow never being 2 confirms this.

It may be worth discussing with clang developers if they would be willing to
document such a [0, 1] restriction, and maybe have ubsan check it.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

2023-06-24 Thread juergen.reuter at desy dot de via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311

--- Comment #13 from Jürgen Reuter  ---
I changed the component from fortran to tree-optimization, as the problematic
commit during that week was in that component. The only commit in the fortran
component turns out to be unproblematic.

[Bug middle-end/110375] -ftrivial-auto-var-init=zero issues with pointers to data members

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375

--- Comment #3 from Andrew Pinski  ---
(In reply to Giuseppe D'Angelo from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > The code is undefined,
> 
> Sure, although there are C++ proposals to make it well-defined /
> implementatiopn-defined (see
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1.html and
> https://isocpp.org/files/papers/P2795R1.html).
> 
> But that's beside the point, I'm not claiming that the code does not have UB
> -- although I'm not sure whether, if -ftrivial-auto-var-init is in use, an
> optimizer stops considering such reads as UB. At least Clang stops:
> https://gcc.godbolt.org/z/bKW5Mccsa

But those proposals will be done in the front-end while
-ftrivial-auto-var-init=zero is a generic non-front-end option. The middle-end
will see the right thing and that option will not have an effect really.

Note GCC with that option is not exactly undefined behavior but rather it is
defined to be using that pattern. But what I was saying is rather it is the
pattern 0 rather the 0.

[Bug middle-end/110375] -ftrivial-auto-var-init=zero issues with pointers to data members

2023-06-24 Thread dangelog at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375

--- Comment #2 from Giuseppe D'Angelo  ---
(In reply to Andrew Pinski from comment #1)
> The code is undefined,

Sure, although there are C++ proposals to make it well-defined /
implementatiopn-defined (see
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1.html and
https://isocpp.org/files/papers/P2795R1.html).

But that's beside the point, I'm not claiming that the code does not have UB --
although I'm not sure whether, if -ftrivial-auto-var-init is in use, an
optimizer stops considering such reads as UB. At least Clang stops:
https://gcc.godbolt.org/z/bKW5Mccsa



> the point to initialize it something which might be
> safe enough for most cases. Yes in the case of pointer to data members, it
> is not the same as null but that is ok, it is still intialized to something.

What I'm asking is to make it safe for *more* cases, so I don't see what's
wrong with such a feature request. -ftrivial-auto-var-init has several options
precisely because one may want different bit patterns of initialization for
various purposes (safety/ease of debugging/...); right now it's just 

* all 0 (=zero)
* all 0xFE (=pattern)


Something that zero-initializes is missing, and I'm asking to make =zero do so.

--

Anyhow, this is useful information, because P2795R1 claims its proposed
behavior is already implemented by GCC, while it actually isn't. It also isn't
by Clang (twin bug report https://github.com/llvm/llvm-project/issues/63471 ).

[Bug tree-optimization/110327] [12/13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r12-4790-g4b3a325f07a

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110327

--- Comment #1 from Andrew Pinski  ---
What is interesting is that the call to foo is still there on the gimple level
in GCC 11, it is only on the RTL level it is able to be removed 

What I see missing on the gimple level on the trunk is a jump threading
opportunity (but might be too complex to do):
   [local count: 12528922893]:
  # c.3_16 = PHI <0(4), 2(7)>
  _9 = h;
  _10 = *_9;
  _11 = *_10;
  _12 = *_11;
  if (_12 <= 4)
goto ; [50.00%]
  else
goto ; [50.00%]

...

   [local count: 6264461501]:
  _15 = d;
  *_10 = _15;
  if (c.3_16 == 0)
goto ; [5.50%]
  else
goto ; [94.50%]

   [local count: 5919916023]:
  if (a.11_30 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

The threading is:
4->8->10->11
7->8->10->12

This requires copying bb 8 and 10. I am not saying it is the right thing to do
but rather that is how to optimize this out I think.


There is also this one too:
   [local count: 12528922784]:
  # a.11_30 = PHI <_18(14), -28(2)>
  c.0_3 = c;
  if (a.11_30 != 0)
goto ; [5.50%]
  else
goto ; [94.50%]


2->3->4
14->3

But as I said I have not looked into more than that.

[Bug middle-end/110375] -ftrivial-auto-var-init=zero issues with pointers to data members

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andrew Pinski  ---
The code is undefined, the point to initialize it something which might be safe
enough for most cases. Yes in the case of pointer to data members, it is not
the same as null but that is ok, it is still intialized to something.

[Bug c++/110380] [feature request] "-pg-constexpr=coverage-output" emit coverage metrics for constexpr code evaluated at compile time

2023-06-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110380

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug analyzer/110387] New: [14 Regression] ICE: in key_t, at analyzer/region.h:1110 with -fanalyzer

2023-06-24 Thread zsojka at seznam dot cz via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110387

Bug ID: 110387
   Summary: [14 Regression] ICE: in key_t, at
analyzer/region.h:1110 with -fanalyzer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 55395
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55395=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fanalyzer testcase.c 
during IPA pass: analyzer
testcase.c: In function '_S_copy':
testcase.c:7:3: internal compiler error: in key_t, at analyzer/region.h:1110
7 |   __builtin_memcpy (, , __n);
  |   ^~
0x89211a ana::cast_region::key_t::key_t(ana::region const*, tree_node*)
/repo/gcc-trunk/gcc/analyzer/region.h:1110
0x89211a ana::cast_region::key_t::key_t(ana::region const*, tree_node*)
/repo/gcc-trunk/gcc/analyzer/region.h:1107
0x89211a ana::region_model_manager::get_cast_region(ana::region const*,
tree_node*)
/repo/gcc-trunk/gcc/analyzer/region-model-manager.cc:1588
0x25c60f5 ana::region_model::check_symbolic_bounds(ana::region const*,
ana::svalue const*, ana::svalue const*, ana::svalue const*,
ana::access_direction, ana::svalue const*, ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/bounds-checking.cc:923
0x25c633b ana::region_model::check_region_bounds(ana::region const*,
ana::access_direction, ana::svalue const*, ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/bounds-checking.cc:1026
0x182e94d ana::region_model::check_region_access(ana::region const*,
ana::access_direction, ana::svalue const*, ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:2809
0x182e94d ana::region_model::check_region_access(ana::region const*,
ana::access_direction, ana::svalue const*, ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:2798
0x182e94d ana::region_model::check_region_for_read(ana::region const*,
ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:2843
0x182e94d ana::region_model::check_region_for_read(ana::region const*,
ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:2840
0x182e94d ana::region_model::get_store_value(ana::region const*,
ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:2376
0x18164f1 ana::kf_memcpy_memmove::impl_call_pre(ana::call_details const&) const
/repo/gcc-trunk/gcc/analyzer/kf.cc:518
0x1839e21 ana::region_model::on_call_pre(gcall const*,
ana::region_model_context*)
/repo/gcc-trunk/gcc/analyzer/region-model.cc:1541
0x183a014 ana::region_model::on_stmt_pre(gimple const*, bool*,
ana::region_model_context*)
/repo/gcc-trunk/gcc/analyzer/region-model.cc:1260
0x1804310 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*,
ana::path_context*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:1471
0x1806f4d ana::exploded_graph::process_node(ana::exploded_node*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:4063
0x1807e9a ana::exploded_graph::process_worklist()
/repo/gcc-trunk/gcc/analyzer/engine.cc:3466
0x180a58f ana::impl_run_checkers(ana::logger*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:6125
0x180b416 ana::run_checkers()
/repo/gcc-trunk/gcc/analyzer/engine.cc:6213
0x17fa868 execute
/repo/gcc-trunk/gcc/analyzer/analyzer-pass.cc:87
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-2060-20230624140803-gad5ab848cc4-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/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-2060-20230624140803-gad5ab848cc4-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230624 (experimental) (GCC)

95 matches

Mail list logo