[Bug libstdc++/112997] New: _Unwind_Exception conflicts with void*. failed to build with clang

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 112997
   Summary: _Unwind_Exception conflicts with void*. failed to
build with clang
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

../../../gcc/libstdc++-v3/libsupc++/eh_call.cc:39:1: error: conflicting types
for '__cxa_call_terminate'
   39 | __cxa_call_terminate(void* ue_header_in) throw ()
  | ^
../../../gcc/libstdc++-v3/libsupc++/unwind-cxx.h:170:17: note: previous
declaration is here
  170 | extern "C" void __cxa_call_terminate (_Unwind_Exception*) throw ()

[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #7 from 康桓瑋  ---
(In reply to Jonathan Wakely from comment #6)
> Fixed, thanks again for catching this divergence from the wording.

Although the status of this LWG 4016 has not been updated on github, I can
assume that it has been accepted by LWG, right?
In addition, I would like to mention that `using _RefT =
range_reference_t<_Rg>;` in ranges#L9286 can be removed because there is no
place to use it.

[Bug target/112992] Inefficient vector initialization using vec_duplicate/broadcast

[liuhongt at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Hongtao Liu  ---
(In reply to Hongtao Liu from comment #6)
> > Thoughts?  Apologies if this is a dup.  I'm happy to work up a patch if
> > someone could advise on where best this should be fixed.  Perhaps RTL's
> > vec_duplicate could be canonicalized to the most appropriate vector mode?
> That may breaks avx512 embedded broadcast.

But perhaps we can add some postreload splitter to check for load from memory
or broadcast from memeory to see if we can use the smallest constant pool.

[Bug tree-optimization/112991] [14 Regression] ICE during GIMPLE pass: ifcvt on p7zip-17.05 since r14-6457

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Hmpf, so of course we walk outside of the region with tree_expr_nonnegative_p.

[Bug tree-optimization/112961] [13 Regression] middle-end Missed vectorization: failed to vectorize simple reduction max since GCC-13

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #9 from JuzheZhong  ---
(In reply to Richard Biener from comment #8)
> Still eventually for backporting.

Oh. I am sorry for closing it (I didn't notice it needs to be backport).

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 112961, which changed state.

Bug 112961 Summary: [13 Regression] middle-end Missed vectorization: failed to 
vectorize simple reduction max since GCC-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112961

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|FIXED   |---

[Bug tree-optimization/112961] [13 Regression] middle-end Missed vectorization: failed to vectorize simple reduction max since GCC-13

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|FIXED   |---

--- Comment #8 from Richard Biener  ---
Still eventually for backporting.

[Bug rtl-optimization/112995] sel-sched2 ICE without checking verify_changes

[linkw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Kewen Lin  ---
(In reply to Andrew Pinski from comment #2)
> fselective-scheduling has so many issues.

ah, thanks a lot for pointing this out.

I was testing the impact of my proposed scheduling change and found this
feature didn't work well on Power (turning on it by default and failed to build
even without bootstrap). I thought it's able to specify these
selective-scheduling related options on Power, maybe we need to ensure some
quality there. I just know Power is not alone ;-), by scanning those PRs under
meta-bug I noticed at least more than three had the same/similar ICE traces as
what I found in those exposed failures. As noticing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110526#c4, I wonder if they have
become in low priority?

[Bug c/112996] New: Improperly evaluated value of the s390x conditional expression

[22s302h0659 at sonline20 dot sen.go.kr via Gcc-bugs]

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

Bug ID: 112996
   Summary: Improperly evaluated value of the s390x conditional
expression
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 22s302h0659 at sonline20 dot sen.go.kr
  Target Milestone: ---

# Environment

- Compiler: s390x-linux-gnu-gcc (64bit)
- Version: gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
- Platform: Windows 11_5.15.90.1-microsoft-standard-WSL2
- Build Optimization Options: O0, O1, O2, O3

I installed the s390x-linux-gnu toolchain using the 'apt' package manager in
Ubuntu and utilized s390x-linux-gnu-gcc (version 11.4.0) from it.

# build script & excution script

```c
s390x-linux-gnu-gcc -o bug0 bug.c -O0 -fsanitize=undefined 
s390x-linux-gnu-gcc -o bug1 bug.c -O1 -fsanitize=undefined 
s390x-linux-gnu-gcc -o bug2 bug.c -O2 -fsanitize=undefined 
s390x-linux-gnu-gcc -o bug3 bug.c -O3 -fsanitize=undefined 
```

```c
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./bug0
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./bug1
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./bug2
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./bug3
```

This is the build script and the execution script.

# Source Code

```c
#include 

signed short v1 = 1;
signed int v2 = 2;
unsigned long long bug = 0;

int main ()
{
if ((v1 < v2))
{
bug = v2;
}
printf("bug = %llu\n", bug);

return 0;
}
```

The C code built with GCC on the s390x architecture returns incorrect values.
The evaluated value of the conditional expression in the 'if' statement should
be true, but with the O2 and O3 options, it returns false.

# output

```c
Expected output
O0: 2
O1: 2
O2: 2
O3: 2

Actual output
O0: 2
O1: 2
O2: 0
O3: 0
```

[Bug rtl-optimization/112995] sel-sched2 ICE without checking verify_changes

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
fselective-scheduling has so many issues.

[Bug rtl-optimization/112995] sel-sched2 ICE without checking verify_changes

[linkw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Kewen Lin  ---
Initially we have:

(insn 31 6 10 2 (set (reg/v:SI 9 9 [orig:119 c ] [119])
(reg/v:SI 64 0 [orig:119 c ] [119])) "test.i":5:5 555
{*movsi_internal1}
 (expr_list:REG_DEAD (reg/v:SI 64 0 [orig:119 c ] [119])
(nil)))
(insn 10 31 25 2 (set (reg:DI 10 10 [128])
(ashift:DI (sign_extend:DI (reg/v:SI 9 9 [orig:119 c ] [119]))
(const_int 2 [0x2]))) "test.i":7:8 278 {ashdi3_extswsli}
 (nil))
(insn 25 10 27 2 (set (reg:DI 64 0 [135])
(sign_extend:DI (reg/v:SI 9 9 [orig:119 c ] [119]))) "test.i":6:5 31
{extendsidi2}
 (expr_list:REG_DEAD (reg/v:SI 9 9 [orig:119 c ] [119])
(nil)))

with moving up, we have:

(insn 46 0 0 (set (reg:DI 64 0 [135])
(sign_extend:DI (reg/v:SI 64 0 [orig:119 c ] [119]))) 31 {extendsidi2}
 (expr_list:REG_DEAD (reg/v:SI 9 9 [orig:119 c ] [119])
(nil)))

in try_replace_dest_reg, we updated the above EXPR_INSN_RTX to:

(insn 48 0 0 (set (reg:DI 32 0)
(sign_extend:DI (reg/v:SI 64 0 [orig:119 c ] [119]))) 31 {extendsidi2}
 (nil))

This doesn't match any constraint and it's an unexpected modification.

Unfortunately function try_replace_dest_reg just checks the orig insn with:

  if (REGNO (best_reg) != REGNO (INSN_LHS (orig_insn))
  && (! replace_src_with_reg_ok_p (orig_insn, best_reg)
  || ! replace_dest_with_reg_ok_p (orig_insn, best_reg)))

But it doesn't check EXPR_INSN_RTX, I think it's under the assumption that if
the original insn is able to be replaced then the change on EXPR_INSN_RTX is
fine, but this isn't true as the given test case shows.

[Bug rtl-optimization/112995] sel-sched2 ICE without checking verify_changes

[linkw at gcc dot gnu.org via Gcc-bugs]

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

Kewen Lin  changed:

   What|Removed |Added

  Known to fail||11.4.0
   Last reconfirmed||2023-12-13
 Status|UNCONFIRMED |ASSIGNED
   Keywords||ice-on-valid-code
 CC||amonakov at gcc dot gnu.org,
   ||bergner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
 Target||powerpc64le-linux-gnu
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org

[Bug rtl-optimization/112995] New: sel-sched2 ICE without checking verify_changes

[linkw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 112995
   Summary: sel-sched2 ICE without checking verify_changes
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linkw at gcc dot gnu.org
  Target Milestone: ---

With selective scheduling 2 enabled by default, I failed to build gcc with
non-bootstrap on Power10, one reduced test case is listed below:

int a[];
int b(__ieee128 e) {
  int c;
  __ieee128 d;
  c = e;
  d = c;
  d = a[c] + d;
  return d;
}

option: -O2 -S -fselective-scheduling2 -mcpu=power10 (or -mcpu=power9)

ICE reason:

test.c:9:1: error: insn does not satisfy its constraints:
9 | }
  | ^

(insn 48 0 0 (set (reg:DI 32 0)
(sign_extend:DI (reg/v:SI 64 0 [orig:119 c ] [119]))) 31 {extendsidi2}
 (nil))

[Bug tree-optimization/112994] [Regression] Missed optimization for redundancy computation elimination because pattern is broken

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.4
   Keywords||missed-optimization
   Last reconfirmed||2023-12-13
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
It might be a regression but we are still missing a pattern for:
int n,m;
void test(int a, int b){
m=(a*4)/(a*2);
}

[Bug middle-end/111260] [14 Regression] arm/aarch64: ice in maybe_legitimize_operand with ?: and constants and different types since r14-2667-gceae1400cf24f329393e96dd9720

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #10 from Andrew Pinski  ---
I have a fix which I think is correct.
Testing right now.

[Bug middle-end/112917] Most strub execution tests FAIL on SPARC

[aoliva at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Alexandre Oliva  ---
Nevermind, I've managed to log into the cfarm machines running solaris/sparc.

[Bug tree-optimization/112994] New: [Regression] Missed optimization for redundancy computation elimination because pattern is broken

[652023330028 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 112994
   Summary: [Regression] Missed optimization for redundancy
computation elimination because pattern is broken
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we noticed that maybe there is a missed optimization for redundancy
computation elimination.

Different from PR 111718, this missed optimization is a regression and not just
because of one missing pattern, but because of changes that broke patterns that
could have been eliminated:

The pattern /* Simplify (t * 2) / t) -> 2.  */ is broken.

https://godbolt.org/z/3er613Krx
int n,m;
void test(int a, int b){

n=a+a;
b=n;
m=(n+b)/(b);
}

GCC (trunk) -O3:
test(int, int):
lea eax, [0+rdi*4]
lea ecx, [rdi+rdi]
cdq
mov DWORD PTR n[rip], ecx
idivecx
mov DWORD PTR m[rip], eax
ret

Expected code (GCC 11.4 -O3):
test(int, int):
mov DWORD PTR m[rip], 2
add edi, edi
mov DWORD PTR n[rip], edi
ret

If our targeting is accurate, then this issue was caused by this commit:
https://github.com/gcc-mirror/gcc/commit/d846f225c25

Thank you very much for your time and effort! We look forward to hearing from
you.

Dedicated Servers Promotions and offers-gcc-b...@gcc.gnu.org

[gowebing via Gcc-bugs]

Mumara Email Template 

 

 

Dedicated Server Hosting 

 

 

 

Dedicated Servers Promotions and Offers

 

 

CPU:i3  RAM:8G Disk:1T United States

 

79 USD/M 
:http://click.return.gowebing.com/campaign/clicked/MTk5MjAzMzc0__MjM0MQ%3D%3D__MzIxNjI5NTU%3D__ODkx__2036__3100__129/aHR0cHMlM0ElMkYlMkZ3d3cuZ293ZWJpbmcuY29tJTJGcHJvbW90aW9ucy5waHA=
 

 

  

 

 

gowebing  |  
unsubscribe:http://click.return.gowebing.com/campaign/unsub-email/MjM0MQ%3D%3D/MzIxNjI5NTU%3D/MjAzNg%3D%3D__MTk5MjAzMzc0__ODkx

Dedicated Servers Promotions and offers-gcc-b...@gcc.gnu.org

[gowebing via Gcc-bugs]

Mumara Email Template 

 

 

Dedicated Server Hosting 

 

 

 

Dedicated Servers Promotions and Offers

 

 

CPU:i3  RAM:8G Disk:1T United States

 

79 USD/M 
:http://click.return.gowebing.com/campaign/clicked/MTk5MjAzMzc0__MjM0MQ%3D%3D__MzIxNjI5NTU%3D__ODkx__2036__3100__129/aHR0cHMlM0ElMkYlMkZ3d3cuZ293ZWJpbmcuY29tJTJGcHJvbW90aW9ucy5waHA=
 

 

  

 

 

gowebing  |  
unsubscribe:http://click.return.gowebing.com/campaign/unsub-email/MjM0MQ%3D%3D/MzIxNjI5NTU%3D/MjAzNg%3D%3D__MTk5MjAzMzc0__ODkx

[Bug target/112992] Inefficient vector initialization using vec_duplicate/broadcast

[liuhongt at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Hongtao Liu  ---
> Thoughts?  Apologies if this is a dup.  I'm happy to work up a patch if
> someone could advise on where best this should be fixed.  Perhaps RTL's
> vec_duplicate could be canonicalized to the most appropriate vector mode?
That may breaks avx512 embedded broadcast.

[Bug target/112992] Inefficient vector initialization using vec_duplicate/broadcast

[liuhongt at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Hongtao Liu  ---
(In reply to Roger Sayle from comment #0)
> The following four functions should in theory all produce the same code:
> 
> typedef unsigned long long v4di __attribute((vector_size(32)));
> typedef unsigned int v8si __attribute((vector_size(32)));
> typedef unsigned short v16hi __attribute((vector_size(32)));
> typedef unsigned char v32qi __attribute((vector_size(32)));
> 
> #define MASK  0x01010101
> #define MASKL 0x0101010101010101ULL
> #define MASKS 0x0101
> 
> v4di fooq() {
>   return (v4di){MASKL,MASKL,MASKL,MASKL};
> }
> 
> v8si food() {
>   return (v8si){MASK,MASK,MASK,MASK,MASK,MASK,MASK,MASK};
> }
> 
> v16hi foow() {
>   return (v16hi){MASKS,MASKS,MASKS,MASKS,MASKS,MASKS,MASKS,MASKS,
>  MASKS,MASKS,MASKS,MASKS,MASKS,MASKS,MASKS,MASKS};
> }
> 
> v32qi foob() {
>   return (v32qi){1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
>  1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1};
> }
> 
> On x86_64 with -mavx, we currently produce very different implementations:
> 
> fooq:
> movabs  rax, 72340172838076673
> pushrbp
> mov rbp, rsp
> and rsp, -32
> mov QWORD PTR [rsp-8], rax
> vbroadcastsdymm0, QWORD PTR [rsp-8]
> leave
> ret
> food:
> vbroadcastssymm0, DWORD PTR .LC2[rip]
> ret
> foow:
> vmovdqa ymm0, YMMWORD PTR .LC3[rip]
> ret
> foob:
> vmovdqa ymm0, YMMWORD PTR .LC4[rip]
> ret
> 
> clang currently produces the vbroadcastss for all four.
I guess here, you mean .rodata optimization, not sure about this part, with the
fix we now generate 

.file   "test.c"
.text
.p2align 4
.globl  fooq
.type   fooq, @function
fooq:
.LFB0:
.cfi_startproc
vbroadcastsd.LC1(%rip), %ymm0
ret
.cfi_endproc
.LFE0:
.size   fooq, .-fooq
.p2align 4
.globl  food
.type   food, @function
food:
.LFB1:
.cfi_startproc
vbroadcastss.LC3(%rip), %ymm0
ret
.cfi_endproc
.LFE1:
.size   food, .-food
.p2align 4
.globl  foow
.type   foow, @function
foow:
.LFB2:
.cfi_startproc
vmovdqa .LC4(%rip), %ymm0
ret
.cfi_endproc
.LFE2:
.size   foow, .-foow
.p2align 4
.globl  foob
.type   foob, @function
foob:
.LFB3:
.cfi_startproc
vmovdqa .LC5(%rip), %ymm0
ret
.cfi_endproc
.LFE3:
.size   foob, .-foob
.set.LC1,.LC4
.set.LC3,.LC4
.section.rodata.cst32,"aM",@progbits,32
.align 32
.LC4:
.value  257
.value  257
.value  257
.value  257
.value  257
.value  257
.value  257
.value  257
.value  257
.value  257
.value  257
.value  257
.value  257
.value  257
.value  257
.value  257
.set.LC5,.LC4
.ident  "GCC: (GNU) 14.0.0 20231212 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug target/112993] rs6000: Rework precision for 128bit float types and modes

[linkw at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
Bug 112993 depends on bug 112788, which changed state.

Bug 112788 Summary: [14 regression] ICEs in fold_range, at range-op.cc:206 
after r14-5972-gea19de921b01a6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[linkw at gcc dot gnu.org via Gcc-bugs]

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

Kewen Lin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Kewen Lin  ---
Should be fixed on latest trunk, we should get rid of this workaround in next
release, it will be tracked in PR112993.

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r14-6478-gfda8e2f8292a90dac9fcaf952bad6fff3aa7fff2
Author: Kewen Lin 
Date:   Tue Dec 12 20:39:34 2023 -0600

range: Workaround different type precision between _Float128 and long
double [PR112788]

As PR112788 shows, on rs6000 with -mabi=ieeelongdouble type _Float128
has the different type precision (128) from that (127) of type long
double, but actually they has the same underlying mode, so they have
the same precision as the mode indicates the same real type format
ieee_quad_format.

It's not sensible to have such two types which have the same mode but
different type precisions, some fix attempt was posted at [1].
As the discussion there, there are some historical reasons and
practical issues.  Considering we passed stage 1 and it also affected
the build as reported, this patch is trying to temporarily workaround
it.  I thought to introduce a hookpod but that seems a bit overkill,
assuming scalar float type with the same mode should have the same
precision looks sensible.

[1]
https://inbox.sourceware.org/gcc-patches/718677e7-614d-7977-312d-05a75e1fd...@linux.ibm.com/

PR tree-optimization/112788

gcc/ChangeLog:

* value-range.h (range_compatible_p): Workaround same type mode but
different type precision issue for rs6000 scalar float types
_Float128 and long double.

[Bug target/112993] rs6000: Rework precision for 128bit float types and modes

[linkw at gcc dot gnu.org via Gcc-bugs]

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

Kewen Lin  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-13
 Ever confirmed|0   |1
   Keywords|build, ice-checking,|internal-improvement
   |ice-on-valid-code   |
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug target/112993] New: rs6000: Rework precision for 128bit float types and modes

[linkw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 112993
   Summary: rs6000: Rework precision for 128bit float types and
modes
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: build, ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linkw at gcc dot gnu.org
CC: amacleod at redhat dot com, andy at gwentswordclub dot 
co.uk,
bergner at gcc dot gnu.org, linkw at gcc dot gnu.org,
meissner at gcc dot gnu.org, segher at gcc dot gnu.org,
seurer at gcc dot gnu.org, tschwinge at gcc dot gnu.org
Depends on: 112788
  Target Milestone: ---
  Host: powerpc64le-linux-gnu
Target: powerpc64le-linux-gnu
 Build: powerpc64le-linux-gnu

+++ This bug was initially created as a clone of Bug #112788 +++

As PR112788 shows and the review comments from Andrew and Jakub at
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640342.html, we should
get rid of the workaround for PR112788 from GCC 15+.

This PR is filed for tracking this, we would expect that the precision for
those types and modes are all 128 bit, also TFmode becomes one macro
conditionally defined as IFmode or KFmode.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788
[Bug 112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after
r14-5972-gea19de921b01a6

[Bug target/112992] Inefficient vector initialization using vec_duplicate/broadcast

[liuhongt at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Hongtao Liu  ---
(In reply to Hongtao Liu from comment #3)
> I think we need to also guard SImode and DImode case under AVX2 when
> MODE_SIZE==256.

Since there's vbroadcastss only support m alternative under avx

[Bug target/112992] Inefficient vector initialization using vec_duplicate/broadcast

[liuhongt at gcc dot gnu.org via Gcc-bugs]

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

Hongtao Liu  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #3 from Hongtao Liu  ---
I think we need to also guard SImode and DImode case under AVX2 when
MODE_SIZE==256.

[Bug rtl-optimization/64713] Missed ccmp optimization

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
I think most of them are recorded in a different bug report. PR 100942 is where
most is recorded too.

E.g.
  82a544:   7100343fcmp w1, #0xd
  82a548:   7a411824ccmpw1, #0x1, #0x4, ne  // ne = any
  82a54c:   1a9f17f5csetw21, eq  // eq = none
  82a550:   54e1b.ne82a56c
<_ZL9is_subseqP10conversionS0_+0x80>  // b.any

[Bug driver/112759] [13/14 regression] mips -march=native detection broken with gcc 13+

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-13

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

[Bug target/110181] longlong.h for RISCV should define count_leading_zeros and count_trailing_zeros and COUNT_LEADING_ZEROS_0 when ZBB is enabled

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #3 from Andrew Pinski  ---
No longer working on this.

[Bug target/112992] Inefficient vector initialization using vec_duplicate/broadcast

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Using  -mtune=intel, fooq does not use a stack location ...

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78954#c2 for the reasoning on
that.

[Bug target/112992] Inefficient vector initialization using vec_duplicate/broadcast

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
Using  -mtune=intel, fooq does not use a stack location ...

[Bug target/112992] New: Inefficient vector initialization using vec_duplicate/broadcast

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Bug ID: 112992
   Summary: Inefficient vector initialization using
vec_duplicate/broadcast
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roger at nextmovesoftware dot com
  Target Milestone: ---

The following four functions should in theory all produce the same code:

typedef unsigned long long v4di __attribute((vector_size(32)));
typedef unsigned int v8si __attribute((vector_size(32)));
typedef unsigned short v16hi __attribute((vector_size(32)));
typedef unsigned char v32qi __attribute((vector_size(32)));

#define MASK  0x01010101
#define MASKL 0x0101010101010101ULL
#define MASKS 0x0101

v4di fooq() {
  return (v4di){MASKL,MASKL,MASKL,MASKL};
}

v8si food() {
  return (v8si){MASK,MASK,MASK,MASK,MASK,MASK,MASK,MASK};
}

v16hi foow() {
  return (v16hi){MASKS,MASKS,MASKS,MASKS,MASKS,MASKS,MASKS,MASKS,
 MASKS,MASKS,MASKS,MASKS,MASKS,MASKS,MASKS,MASKS};
}

v32qi foob() {
  return (v32qi){1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1};
}

On x86_64 with -mavx, we currently produce very different implementations:

fooq:
movabs  rax, 72340172838076673
pushrbp
mov rbp, rsp
and rsp, -32
mov QWORD PTR [rsp-8], rax
vbroadcastsdymm0, QWORD PTR [rsp-8]
leave
ret
food:
vbroadcastssymm0, DWORD PTR .LC2[rip]
ret
foow:
vmovdqa ymm0, YMMWORD PTR .LC3[rip]
ret
foob:
vmovdqa ymm0, YMMWORD PTR .LC4[rip]
ret

clang currently produces the vbroadcastss for all four.
I discovered that some of my "day job" code used the "fooq" idiom, requiring a
stack frame, and both reads and writes to memory [of a compile-time constant].

I suspect the fix is to add a define_insn_and_split or two to i386/sse.md, and
perhaps something can be done in expand, but I'm confused why LRA/reload spills
the DImode component of V4DI to the stack frame, but places the SImode
component of V8SI in the constant pool.

This is related (distantly) to PRs 100865 and 106060, but is potentially target
independent, and seems to be going wrong in LRA/reload's REG_EQUIV elimination.
Thoughts?  Apologies if this is a dup.  I'm happy to work up a patch if someone
could advise on where best this should be fixed.  Perhaps RTL's vec_duplicate
could be canonicalized to the most appropriate vector mode?

[Bug tree-optimization/112991] [14 Regression] ICE during GIMPLE pass: ifcvt on p7zip-17.05 since r14-6457

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-13
 Ever confirmed|0   |1

[Bug tree-optimization/112991] [14 Regression] ICE during GIMPLE pass: ifcvt on p7zip-17.05 since r14-6457

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |14.0
Summary|[14 Regression] ICE during  |[14 Regression] ICE during
   |GIMPLE pass: ifcvt on   |GIMPLE pass: ifcvt on
   |p7zip-17.05 |p7zip-17.05 since r14-6457

--- Comment #1 from Jakub Jelinek  ---
Started with r14-6457-g878cb5acf0c499702ffd315e273f55e8bd0970b8

[Bug tree-optimization/112991] New: [14 Regression] ICE during GIMPLE pass: ifcvt on p7zip-17.05

[slyfox at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 112991
   Summary: [14 Regression] ICE during GIMPLE pass: ifcvt on
p7zip-17.05
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Noticed ICE on current gcc-master when built p7zip-17.05 with
r14-6466-gcd7d0b4cf78926 . Minimized example:

$ cat a.c.c
typedef struct {
  unsigned links[2];
} RMF_unit;
long RMF_recurseListsBound_count;
int RMF_recurseListsBound_tbl, RMF_recurseListsBound_list_head_1;
unsigned RMF_recurseListsBound_list_head_0;
void RMF_recurseListsBound() {
  int list_count = RMF_recurseListsBound_list_head_1;
  long link = RMF_recurseListsBound_list_head_0;
  for (; RMF_recurseListsBound_count;) {
long next_link =
((RMF_unit *)_recurseListsBound_tbl)[link >> 2].links[0];
if (link)
  --RMF_recurseListsBound_count;
link = next_link;
  }
  while (list_count)
;
}

$ gcc -std=gnu11 -O2  -c a.c.c -O2 -Wall -Werror
a.c.c: In function 'RMF_recurseListsBound':
a.c.c:12:49: error: array subscript 'RMF_unit[0]' is partly outside array
bounds of 'int[1]' [-Werror=array-bounds=]
   12 | ((RMF_unit *)_recurseListsBound_tbl)[link >> 2].links[0];
  | ^~~
a.c.c:5:5: note: object 'RMF_recurseListsBound_tbl' of size 4
5 | int RMF_recurseListsBound_tbl, RMF_recurseListsBound_list_head_1;
  | ^
during GIMPLE pass: ifcvt
a.c.c:7:6: internal compiler error: Segmentation fault
7 | void RMF_recurseListsBound() {
  |  ^
0x1e367b4 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x1e36f99 internal_error(char const*, ...)
???:0
0xd621af crash_signal(int)
???:0
0x9d2ad0 tree_single_nonnegative_warnv_p(tree_node*, bool*, int)
???:0
0xa3be95 gimple_stmt_nonnegative_warnv_p(gimple*, bool*, int)
???:0
0x9d2c45 tree_expr_nonnegative_p(tree_node*)
???:0
0x123e667 gimple_simplify_369(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node*, tree_node**, tree_code)
???:0
0x13978ff gimple_simplify_RSHIFT_EXPR(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*)
???:0
0x139e78d gimple_resimplify2(gimple**, gimple_match_op*, tree_node*
(*)(tree_node*))
???:0
0x139f327 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
???:0
0xa30915 gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
???:0
0xf3f55c visit_stmt(gimple*, bool) [clone .isra.0]
???:0
0xf4000d process_bb(rpo_elim&, basic_block_def*, bool, bool, bool, bool, bool,
bitmap_head*, bool)
???:0
0xf417d7 do_rpo_vn_1(function*, edge_def*, bitmap_head*, bool, bool,
vn_lookup_kind)
???:0
0xf42a2a do_rpo_vn(function*, edge_def*, bitmap_head*, bool, bool,
vn_lookup_kind)
???:0
0xdcdbd6 tree_if_conversion(loop*, vec*)
???:0
0xdd030a (anonymous namespace)::pass_if_conversion::execute(function*)
???: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.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gcc-14.0.0
--with-gmp-include=/<>/gmp-6.3.0-dev/include
--with-gmp-lib=/<>/gmp-6.3.0/lib
--with-mpfr-include=/<>/mpfr-4.2.1-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.1/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-2.38-27-dev/include
--with-build-sysroot=/ --program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<>/isl-0.20 --disable-bootstrap
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0  (experimental) (GCC)

[Bug preprocessor/110558] __has_include argument expansion results in unexpected filename

[lhyatt at gcc dot gnu.org via Gcc-bugs]

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

Lewis Hyatt  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Decembe
   ||r/640386.html

--- Comment #5 from Lewis Hyatt  ---
Patch submitted for review:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640386.html

[Bug sanitizer/112981] [13/14 Regression] Big compile time and run time regression in libasan with g:f732bf6a603721f61102a08ad2d023c7c2670870

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> Yes this is a dup.

I looked into what catch2 was doing and yes it is doing the whole throw and
catch (and using rethrow_exception too in some cases).

[Bug sanitizer/110835] [13/14 Regression] -fsanitize=address causes huge runtime slowdown from std::rethrow_exception not called

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

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

[Bug sanitizer/112981] [13/14 Regression] Big compile time and run time regression in libasan with g:f732bf6a603721f61102a08ad2d023c7c2670870

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Yes this is a dup.

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

[Bug driver/112983] gcc.cc: do_spec_1, ICE if missing '}' for %x{...}

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-12
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||2.95

--- Comment #1 from Andrew Pinski  ---
Confirmed, this code has been there since the driver code was added to revision
control back in 1992.

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #15)
> I think e.g. aarch64 doesn't set nothrow on builtins with
> -fnon-call-exceptions if they might raise floating point exceptions or
> read/write memory.

That is correct, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107209#c7 for
a change related to aarch64's builtins and non-call exceptions and folding
there.

[Bug analyzer/112965] Valgrind error on gcc.dg/analyzer/fd-dup-1.c

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Jakub Jelinek  ---
It could be done just for #ifdef ENABLE_VALGRIND_ANNOTATIONS
Perhaps { const char buf[16] = {}; pp_append_text (pp, buf, buf + 16); } ?
Anyway, I'm really curious why it works for buffers in libcpp.
Because new_buff only aligns length to DEFAULT_ALIGNMENT, which is alignment of
double and pointers; 8 bytes on x86-64, but just 4 bytes on i686.
Obviously, when not under valgrind I think it should be ok in any case, even
when reading random uninitialized bytes after the allocation it shouldn't
change anything on the outcome of the search, and because e.g. the sse4.2
version for < 16 bytes misaligned at the end of page defers to sse2 version and
otherwise does one unaligned load and all the further ones are aligned, so it
should never cross the end of page.
So it is just about valgrind not understanding that the uninitialized bytes
after newline don't matter.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[juzhe.zhong at rivai dot ai via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 112961, which changed state.

Bug 112961 Summary: [13 Regression] middle-end Missed vectorization: failed to 
vectorize simple reduction max since GCC-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112961

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/112961] [13 Regression] middle-end Missed vectorization: failed to vectorize simple reduction max since GCC-13

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from JuzheZhong  ---
Thanks Richard.

Fixed.

[Bug tree-optimization/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26

[bergner at gcc dot gnu.org via Gcc-bugs]

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

Peter Bergner  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #12 from Peter Bergner  ---
This should be fixed now.

[Bug tree-optimization/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Peter Bergner :

https://gcc.gnu.org/g:788e0d48ec639d44294434f4f20ae94023c3759d

commit r14-6470-g788e0d48ec639d44294434f4f20ae94023c3759d
Author: Peter Bergner 
Date:   Tue Dec 12 16:46:16 2023 -0600

testsuite: Add testcase for already fixed PR [PR112822]

Adding a testcase for PR112822 to ensure we won't regress.

2023-12-12  Peter Bergner  

gcc/testsuite/
PR tree-optimization/112822
* g++.dg/pr112822.C: New test.

[Bug analyzer/112965] Valgrind error on gcc.dg/analyzer/fd-dup-1.c

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from David Malcolm  ---
(In reply to David Malcolm from comment #3)
> A workaround might be to pad pp's buffer with trailing zero bytes up to a
> multiple of 16.

The following hack "fixes" it (for some definition of "fix"):

diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 5700c493..4858fec0dc3e 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -1843,6 +1843,11 @@ private:
 pretty_printer pp;
 pp_string (, (const char *) tok.val.str.text);
 pp_newline ();
+
+// FIXME: workaround for PR 112965
+for (int i = 0; i < 16; i++)
+  pp_character (, '\0');
+
 cpp_push_buffer (parse_in,
 (const unsigned char *) pp_formatted_text (),
 strlen (pp_formatted_text ()),

[Bug target/112989] GC ICE with C++, `#include ` and `-fsanitize=address`

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #5 from Andrew Pinski  ---
Here is where the 2 builtins are added:
```
Breakpoint 1, aarch64_sve::function_builder::add_function (this=0x7fffd980,
instance=..., name=0x31d4ca0 "svmla_za64_vg4x1", fntype=0x77434930,
attrs=0x0, required_extensions=5497558138885, overloaded_p=true,
placeholder_p=true) at ../../gcc/config/aarch64/aarch64-sve-builtins.cc:1478
1478if (t != 0)
(gdb) bt
#0  aarch64_sve::function_builder::add_function (this=0x7fffd980,
instance=..., name=0x31d4ca0 "svmla_za64_vg4x1", fntype=0x77434930,
attrs=0x0, required_extensions=5497558138885, overloaded_p=true,
placeholder_p=true) at ../../gcc/config/aarch64/aarch64-sve-builtins.cc:1478
#1  0x017ddeb5 in
aarch64_sve::function_builder::add_overloaded_function (this=0x7fffd980,
instance=..., required_extensions=5497558138885) at
../../gcc/config/aarch64/aarch64-sve-builtins.cc:1581
#2  0x017ddf7d in operator() (__closure=0x7fffd900, types=...,
group_suffix_id=aarch64_sve::GROUP_vg4x1, pi=0) at
../../gcc/config/aarch64/aarch64-sve-builtins.cc:1604
#3  0x017de087 in operator() (__closure=0x7fffd8d0,
group_suffix_id=aarch64_sve::GROUP_vg4x1, pi=0) at
../../gcc/config/aarch64/aarch64-sve-builtins.cc:1628
#4  0x017de1c4 in
aarch64_sve::function_builder::add_overloaded_functions (this=0x7fffd980,
group=..., mode=aarch64_sve::MODE_none) at
../../gcc/config/aarch64/aarch64-sve-builtins.cc:1635
#5  0x017f483d in aarch64_sve::binary_za_slice_opt_single_def::build
(this=, b=..., group=...) at
../../gcc/config/aarch64/aarch64-sve-builtins-shapes.cc:1894
#6  0x017de25d in
aarch64_sve::function_builder::register_function_group (this=0x7fffd980,
group=...) at ../../gcc/config/aarch64/aarch64-sve-builtins.cc:1644
#7  0x017e771b in aarch64_sve::handle_arm_sve_h () at
../../gcc/config/aarch64/aarch64-sve-builtins.cc:4595
#8  0x00da3d75 in aarch64_pragma_aarch64 () at
../../gcc/config/aarch64/aarch64-c.cc:347
#9  0x00bf022f in cp_parser_pragma (parser=0x773409d8,
context=pragma_external, if_p=0x0) at ../../gcc/cp/parser.cc:50751
#10 0x00c2c2ac in cp_parser_toplevel_declaration
(parser=0x773409d8) at ../../gcc/cp/parser.cc:15392
#11 cp_parser_toplevel_declaration (parser=0x773409d8) at
../../gcc/cp/parser.cc:15383
#12 cp_parser_translation_unit (parser=0x773409d8) at
../../gcc/cp/parser.cc:5273
#13 c_parse_file () at ../../gcc/cp/parser.cc:50845
#14 0x00d741d2 in c_common_parse_file () at
../../gcc/c-family/c-opts.cc:1301
#15 0x0133917e in compile_file () at ../../gcc/toplev.cc:446
#16 0x00a4b151 in do_compile () at ../../gcc/toplev.cc:2150
#17 toplev::main (this=this@entry=0x7fffdd5e, argc=,
argc@entry=4, argv=, argv@entry=0x7fffde88) at
../../gcc/toplev.cc:2306
#18 0x00a4d1ef in main (argc=4, argv=0x7fffde88) at
../../gcc/main.cc:39
(gdb) c
Continuing.

Breakpoint 1, aarch64_sve::function_builder::add_function (this=0x7fffd980,
instance=..., name=0x31d4d20 "svmla_za64_vg4x1", fntype=0x7640fe70,
attrs=0x764c4aa0, required_extensions=5497558138885, overloaded_p=false,
placeholder_p=false) at ../../gcc/config/aarch64/aarch64-sve-builtins.cc:1478
1478if (t != 0)
(gdb) bt
#0  aarch64_sve::function_builder::add_function (this=0x7fffd980,
instance=..., name=0x31d4d20 "svmla_za64_vg4x1", fntype=0x7640fe70,
attrs=0x764c4aa0, required_extensions=5497558138885, overloaded_p=false,
placeholder_p=false) at ../../gcc/config/aarch64/aarch64-sve-builtins.cc:1478
#1  0x017ddd0a in aarch64_sve::function_builder::add_unique_function
(this=0x7fffd980, instance=..., return_type=0x77421f18,
argument_types=..., required_extensions=5497558138885,
force_direct_overloads=false) at
../../gcc/config/aarch64/aarch64-sve-builtins.cc:1549
#2  0x017ef6da in aarch64_sve::build_one (b=..., signature=, group=..., mode_suffix_id=, ti=,
gi=, pi=0, force_direct_overloads=false) at
../../gcc/config/aarch64/aarch64-sve-builtins-shapes.cc:331
#3  0x017ef7f9 in aarch64_sve::build_all (b=...,
signature=signature@entry=0x263bcd7 "_,su32,t1,t1", group=...,
mode_suffix_id=mode_suffix_id@entry=aarch64_sve::MODE_none,
force_direct_overloads=force_direct_overloads@entry=false) at
../../gcc/config/aarch64/aarch64-sve-builtins-shapes.cc:470
#4  0x017f4855 in aarch64_sve::binary_za_slice_opt_single_def::build
(this=, b=..., group=...) at
../../gcc/config/aarch64/aarch64-sve-builtins-shapes.cc:1895
#5  0x017de25d in
aarch64_sve::function_builder::register_function_group (this=0x7fffd980,
group=...) at ../../gcc/config/aarch64/aarch64-sve-builtins.cc:1644
#6 

[Bug analyzer/112965] Valgrind error on gcc.dg/analyzer/fd-dup-1.c

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from David Malcolm  ---
A workaround might be to pad pp's buffer with trailing zero bytes up to a
multiple of 16.

[Bug target/112989] GC ICE with C++, `#include ` and `-fsanitize=address`

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
```
simulate_builtin_function_decl (location=255050, name=0x48b5200
"svmla_za64_vg4x1", type=0xf6b1cb70, function_code=31409, library_name=0x0,
attrs=0xf6bced80) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/langhooks.cc:781
781   if (TREE_CODE (new_decl) == FUNCTION_DECL
(gdb)
782   && fndecl_built_in_p (new_decl, function_code, BUILT_IN_MD))
(gdb)
781   if (TREE_CODE (new_decl) == FUNCTION_DECL
(gdb)
785   return decl;
(gdb) p debug_tree(new_decl)
 >
SI
size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
attributes >
value >>
chain 
value >>
value >>>
arg-types 
chain 
chain 
chain >
nothrow public external built-in DI t.cc:1:21
align:32 warn_if_not_align:0 built-in: BUILT_IN_MD:31385 context

attributes >
chain >>>
full-name "void svmla_za64_vg4x1(unsigned int, svint16_t, svint16_t)" chain
>
$2 = void
(gdb) p function_code
$3 = 31409
```


There seems like there are 2 builtins for svmla_za64_vg4x1 

[Bug analyzer/112965] Valgrind error on gcc.dg/analyzer/fd-dup-1.c

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from David Malcolm  ---
In c-parser.cc's consider_macro:
1843pretty_printer pp;
1844pp_string (, (const char *) tok.val.str.text);
1845pp_newline ();
1846cpp_push_buffer (parse_in,
1847 (const unsigned char *) pp_formatted_text (),
1848 strlen (pp_formatted_text ()),
1849 0);

(gdb) p pp_formatted_text ()
$10 = 0x5782360 "3\n"

(gdb) p (size_t)strlen(pp_formatted_text ())
$11 = 2

So we have an aligned buffer, but it's only 2 bytes long aka 3 bytes in size
i.e.:
  ['3', '\n', '\0']

Looking at lex.cc's search_line_sse42:

424   uintptr_t si = (uintptr_t)s;
425   uintptr_t index;
426 
427   /* Check for unaligned input.  */
428   if (si & 15)
429 {
430   v16qi sv;
431 
432   if (__builtin_expect (end - s < 16, 0)
433   && __builtin_expect ((si & 0xfff) > 0xff0, 0))
434 {
435   /* There are less than 16 bytes left in the buffer, and less
436  than 16 bytes left on the page.  Reading 16 bytes at this
437  point might generate a spurious page fault.  Defer to the
438  SSE2 implementation, which already handles alignment.  */
439   return search_line_sse2 (s, end);
440 }

we skip the block starting at line 429, since it's aligned:

(gdb) p ((uintptr_t)s) & 15
$14 = 0

but the length is so short that we presumably don't want to read 16 bytes at a
time:

(gdb) p end - s
$15 = 2

Not sure if this is a false positive, or a bug in search_line_sse42 when
dealing with very short aligned buffers.

[Bug tree-optimization/110199] [12/13/14 Regression] Missing VRP transformation with MIN_EXPR and known relation

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Andrew Macleod  ---
(In reply to Andrew Pinski from comment #2)
> I Kinda see how to implement this by creating
> operator_min::fold_range/operator_max::fold_range but I am still new on
> using these interfaces so I am not 100% sure how to use them.

Actually, on ranger, we'd be able to make the range choice of the range of a_2
or b_3, but it can't rewrite the IL...  and since the range of both is varying,
fold_range would still return varying.  Unless we indicate there are relations.
 fodl_range itself only takes what it is given, so we have to query the
relations first. 

In theory all that is missing is to teach simplification about relation
queries. For instance, in simplify_using_ranges::fold_cond_with_ops, we are
invoking the range-op handler without any relations.. we query the ranges, but
not the relation. If we add something like this (and make sure both operands
are symbolic)

diff --git a/gcc/vr-values.cc b/gcc/vr-values.cc
index ecb294131b0..ad2c2d6c090 100644
--- a/gcc/vr-values.cc
+++ b/gcc/vr-values.cc
@@ -315,10 +315,17 @@ simplify_using_ranges::fold_cond_with_ops (enum tree_code
code,
   || !query->range_of_expr (r1, op1, s))
 return NULL_TREE;

+  relation_kind rel = VREL_VARYING;
+  if (gimple_range_ssa_p (op0) && gimple_range_ssa_p (op1))
+rel = query->query_relation (s, op0, op1);
+  // Create a trio with the relation set between op0 and op2 for folding.
+  // TRIOS are lhs-op0, lhs-op1, op0-op1 relations.
+  relation_trio trio (VREL_VARYING, VREL_VARYING, rel);
+
   tree type = TREE_TYPE (op0);
   int_range<1> res;
   range_op_handler handler (code);
-  if (handler && handler.fold_range (res, type, r0, r1))
+  if (handler && handler.fold_range (res, type, r0, r1, trio))
 {
   if (res == range_true (type))
return boolean_true_node;

This should do what you want I think...   fold_range should use the relation
passed in to determine that the condition is always true or false.

I have not fully tested this patch, fwiw.

[Bug target/112989] GC ICE with C++, `#include ` and `-fsanitize=address`

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
```
Breakpoint 1, ggc_free (p=0xf6bd4900) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ggc-page.cc:1612
1612  if (in_gc)
(gdb) bt
#0  ggc_free (p=0xf6bd4900) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ggc-page.cc:1612
#1  0x00f59a48 in duplicate_decls (newdecl=0xf6bd4900,
olddecl=0xf6bd3d00, hiding=false, was_hidden=false) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/decl.cc:3312
#2  0x010f57a0 in pushdecl (decl=0xf6bd4900, hiding=false) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/name-lookup.cc:3920
#3  0x00f62300 in cxx_simulate_builtin_function_decl
(decl=0xf6bd4900) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/decl.cc:5239
#4  0x01a0c5c8 in simulate_builtin_function_decl (location=255050,
name=0x48b5200 "svmla_za64_vg4x1", type=0xf6b1cb70, function_code=31409,
library_name=0x0, attrs=0xf6bced80) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/langhooks.cc:774
#5  0x023ff6b0 in aarch64_sve::function_builder::add_function
(this=0xf490, instance=..., name=0x48b5200 "svmla_za64_vg4x1",
fntype=0xf6b1cb70, attrs=0xf6bced80, required_extensions=5497558138885,
overloaded_p=false, placeholder_p=false)
at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:1490
#6  0x023ff8e8 in aarch64_sve::function_builder::add_unique_function
(this=0xf490, instance=..., return_type=0xf5b30f18,
argument_types=..., required_extensions=5497558138885,
force_direct_overloads=false)
at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:1542
#7  0x02411fe8 in aarch64_sve::build_one (b=..., signature=0x3c16590
"_,su32,t1,v1", group=..., mode_suffix_id=aarch64_sve::MODE_single, ti=0, gi=0,
pi=0, force_direct_overloads=false) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins-shapes.cc:331
#8  0x02412508 in aarch64_sve::build_all (b=..., signature=0x3c16590
"_,su32,t1,v1", group=..., mode_suffix_id=aarch64_sve::MODE_single,
force_direct_overloads=false) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins-shapes.cc:470
#9  0x02415418 in aarch64_sve::binary_za_slice_opt_single_def::build
(this=0x3c165a0 , b=...,
group=...) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins-shapes.cc:1896
#10 0x023fffec in
aarch64_sve::function_builder::register_function_group (this=0xf490,
group=...) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:1637
#11 0x0240b0bc in aarch64_sve::handle_arm_sve_h () at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:4588
#12 0x01460b1c in aarch64_pragma_aarch64 () at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-c.cc:347
#13 0x01412ebc in c_invoke_pragma_handler (id=14) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/c-family/c-pragma.cc:1741
#14 0x01199f8c in cp_parser_pragma (parser=0xf5e54e18,
context=pragma_external, if_p=0x0) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/parser.cc:50751
#15 0x01137730 in cp_parser_toplevel_declaration
(parser=0xf5e54e18) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/parser.cc:15392
#16 0x0111f240 in cp_parser_translation_unit (parser=0xf5e54e18) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/parser.cc:5273
#17 0x0119a354 in c_parse_file () at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/parser.cc:50845
#18 0x0140a314 in c_common_parse_file () at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/c-family/c-opts.cc:1301
#19 0x01d156a4 in compile_file () at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/toplev.cc:446
#20 0x01d1989c in do_compile () at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/toplev.cc:2150
#21 0x01d19dd4 in toplev::main (this=0xf8d0, argc=5,
argv=0xfa18) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/toplev.cc:2306
#22 0x0358944c in main (argc=5, argv=0xfa18) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/main.cc:39
```

[Bug target/112990] [14 Regression][s390x] ICE in related_vector_mode, at stor-layout.cc:539 since r14-3381-g27de9aa152141e

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/112989] GC ICE with C++, `#include ` and `-fsanitize=address`

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
#1  0x012eeda4 in gt_ggc_mx_lang_tree_node (x_p=0xf6bd4900) at
./gt-cp-tree.h:108
108xlimit = ((union lang_tree_node *) c_tree_chain_next
(&(*xlimit).generic));
(gdb) up
#2  0x0240ca80 in gt_ggc_mx_registered_function (x_p=0xf6b854f0) at
./gt-aarch64-sve-builtins.h:29
29gt_ggc_m_9tree_node ((*x).decl);
(gdb) p x
$8 = (aarch64_sve::registered_function * const) 0xf6b854f0
(gdb) p *x
$9 = {instance = {base_name = 0x3c08b80 "svmla", base = 0x3c21cb8
, shape = 0x3c165a0
, mode_suffix_id =
aarch64_sve::MODE_single, type_suffix_ids = {aarch64_sve::TYPE_SUFFIX_za64,
aarch64_sve::TYPE_SUFFIX_s16},
group_suffix_id = aarch64_sve::GROUP_vg4x1, pred = aarch64_sve::PRED_none},
decl = 0xf6bd4900, required_extensions = 5497558138885, overloaded_p =
false}
(gdb) p x->decl
$10 = (tree) 0xf6bd4900
(gdb) p debug_tree(x->decl)
 

[Bug target/112989] GC ICE with C++, `#include ` and `-fsanitize=address`

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-12
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Confirmed (but I can't reproduce it with a cross, either).

[Bug analyzer/112655] analyzer/infinite-loop.cc:75: Possible performance problem ?

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-12-12

--- Comment #1 from David Malcolm  ---
Thanks!  Am working on a fix.

[Bug target/112990] New: [14 Regression][s390x] ICE in related_vector_mode, at stor-layout.cc:539 since r14-3381-g27de9aa152141e

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 112990
   Summary: [14 Regression][s390x] ICE in related_vector_mode, at
stor-layout.cc:539 since r14-3381-g27de9aa152141e
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: rguenther at suse dot de
  Target Milestone: ---
Target: s390x

Compiling reduced testcase gcc.target/s390/vector/reverse-elements-6.c with
s390x cross compiler results in ICE since r14-3381-g27de9aa152141e.


$ cat reverse-elements-6.c
typedef long __attribute__((vector_size(16))) V2DI;
V2DI v2di_x;
void v2di() {
  V2DI y, z;
  for (int i = 0; i < 2; ++i)
z[i] = y[1];
  v2di_x = z;
}


$ s390x-linux-gnu-gcc reverse-elements-6.c -O1
during RTL pass: expand
reverse-elements-6.c: In function ‘v2di’:
reverse-elements-6.c:7:10: internal compiler error: in related_vector_mode, at
stor-layout.cc:539
7 |   v2di_x = z;
  |   ~~~^~~
0x15dd230 related_vector_mode(machine_mode, scalar_mode, poly_int<1u, unsigned
long>)
/home/mjires/git/GCC/master/gcc/stor-layout.cc:539
0x1428a35 qimode_for_vec_perm(machine_mode)
/home/mjires/git/GCC/master/gcc/optabs-query.cc:358
0x141db61 expand_vec_perm_const(machine_mode, rtx_def*, rtx_def*,
int_vector_builder > const&, machine_mode, rtx_def*)
/home/mjires/git/GCC/master/gcc/optabs.cc:6445
0x106f66f expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/mjires/git/GCC/master/gcc/expr.cc:10844
0x1070df4 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/mjires/git/GCC/master/gcc/expr.cc:11216
0x1068fa1 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/mjires/git/GCC/master/gcc/expr.cc:9407
0x105debf store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/mjires/git/GCC/master/gcc/expr.cc:6709
0x105c5ff expand_assignment(tree_node*, tree_node*, bool)
/home/mjires/git/GCC/master/gcc/expr.cc:6430
0xec1ec7 expand_gimple_stmt_1
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:3960
0xec22b5 expand_gimple_stmt
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:4058
0xeca6e0 expand_gimple_basic_block
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:6114
0xecca96 execute
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:6849
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.


$ s390x-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=s390x-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/s390x-linux-gnu/14.0.0/lto-wrapper
Target: s390x-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=s390x-linux-gnu --disable-bootstrap
--enable-languages=c,c++ --disable-multilib --disable-libsanitizer
--enable-checking : (reconfigured) /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=s390x-linux-gnu --disable-bootstrap
--enable-languages=c,c++ --disable-multilib --disable-libsanitizer
--enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231212 (experimental) (GCC)

[Bug tree-optimization/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r14-6466-gcd7d0b4cf789264cd75ab7df5df232dc58061ed7
Author: Martin Jambor 
Date:   Tue Dec 12 21:19:21 2023 +0100

SRA: Force gimple operand in an additional corner case (PR 112822)

PR 112822 revealed a corner case in load_assign_lhs_subreplacements
where it creates invalid gimple: an assignment where on the LHS there
is a complex variable which however is not a gimple register because
it has partial defs and on the right hand side there is a
VIEW_CONVERT_EXPR.  This patch invokes force_gimple_operand_gsi on
such statements (like it already does when both sides of a generated
assignment have partial definitions.

gcc/ChangeLog:

2023-12-12  Martin Jambor  

PR tree-optimization/112822
* tree-sra.cc (load_assign_lhs_subreplacements): Invoke
force_gimple_operand_gsi also when LHS has partial stores and RHS
is a
VIEW_CONVERT_EXPR.

[Bug target/112989] New: GC ICE with C++, `#include ` and `-fsanitize=address`

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 112989
   Summary: GC ICE with C++, `#include ` and
`-fsanitize=address`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: GC, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu

Just a simple:
```
#pragma GCC aarch64 "arm_sve.h"
```

Causes an ICE:
```
ubuntu@ubuntu:~/src/upstream-gcc-aarch64\#
/bajas/pinskia/src/upstream-gcc-aarch64/gcc/objdir/stage1-gcc/cc1plus t.cc
-quiet -march=armv8.6-a+sve  -fsanitize=address
t.cc:1:32: internal compiler error: Segmentation fault
1 | #pragma GCC aarch64 "arm_sve.h"
  |^
0x1d150ff crash_signal
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/toplev.cc:316
0x12fb314 c_tree_chain_next(tree_node*)
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/c-family/c-common.h:1347
0x12eeda3 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:108
0x240ca7f gt_ggc_mx_registered_function(void*)
./gt-aarch64-sve-builtins.h:29
0x240cb23 gt_ggc_mx(aarch64_sve::registered_function*&)
./gt-aarch64-sve-builtins.h:47
0x240ea3f void
gt_ggc_mx(vec*)
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/vec.h:1449
0x240caef gt_ggc_mx_vec_registered_function__va_gc_(void*)
./gt-aarch64-sve-builtins.h:39
0x17a1237 ggc_mark_root_tab
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ggc-common.cc:75
0x17a13a7 ggc_mark_roots()
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ggc-common.cc:104
0x146d183 ggc_collect(ggc_collect)
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ggc-page.cc:2227
0xfd0567 c_parse_final_cleanups()
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/decl2.cc:5064
0x140a413 c_common_parse_file()
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/c-family/c-opts.cc:1319
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.

```

I have not debugged this but I can't reproduce with a cross though, only a
native build (but stage1)

[Bug modula2/112984] Compiling program with -Wpedantic shows warning in libraries

[gaius at gcc dot gnu.org via Gcc-bugs]

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Gaius Mulley  ---
Closing now that the patch has been applied.

[Bug modula2/112984] Compiling program with -Wpedantic shows warning in libraries

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:01cca857aa3e86a750f5df77ca6c36c0739f10f0

commit r14-6465-g01cca857aa3e86a750f5df77ca6c36c0739f10f0
Author: Gaius Mulley 
Date:   Tue Dec 12 19:29:06 2023 +

PR modula2/112984 Compiling program with -Wpedantic shows warning in
libraries

This patch tidies up the library modules so that -Wpedantic does not
generate any warnings (apart from two procedures with legitimate infinite
loops).

gcc/m2/ChangeLog:

PR modula2/112984
* gm2-libs-coroutines/SYSTEM.mod: Remove redundant import of
memcpy.
* gm2-libs-iso/ClientSocket.mod: Remove redundant import of
IOConsts.
* gm2-libs-iso/IOChan.mod: Remove redundant import of IOConsts.
* gm2-libs-iso/IOLink.mod: Remove redundant import of IOChan and
SYSTEM.
* gm2-libs-iso/IOResult.mod: Remove redundant import of IOChan.
* gm2-libs-iso/LongIO.mod: Remove redundant import of writeString.
* gm2-libs-iso/LongWholeIO.mod: Remove redundant import of IOChan.
* gm2-libs-iso/M2RTS.mod: Remove redundant import of ADDRESS.
* gm2-libs-iso/MemStream.mod: Remove redundant import of ADDRESS.
* gm2-libs-iso/RTdata.mod: Remove redundant import of
DeviceTablePtr.
* gm2-libs-iso/RTfio.mod: Remove redundant import of
DeviceTablePtr.
* gm2-libs-iso/RTgen.mod: Remove redundant import of
DeviceTablePtr.
* gm2-libs-iso/RealIO.mod: Remove redundant import of writeString.
* gm2-libs-iso/RndFile.mod: Remove redundant import of SYSTEM.
* gm2-libs-iso/SYSTEM.mod: Remove redundant import of memcpy.
* gm2-libs-iso/ShortWholeIO.mod: Remove redundant import of
IOConsts.
* gm2-libs-iso/TextIO.mod: Remove redundant import of IOChan.
* gm2-libs-iso/TextUtil.mod: Remove redundant import of IOChan.
* gm2-libs-iso/WholeIO.mod: Remove redundant import of IOChan.
* gm2-libs-log/BitByteOps.mod: Remove redundant import of BYTE.
* gm2-libs-log/FileSystem.mod: Remove redundant import of BYTE and
ADDRESS.
* gm2-libs-log/InOut.mod: Remove redundant import of String.
* gm2-libs-log/RealConversions.mod: Remove redundant import of
StringToLongreal.
* gm2-libs/FIO.mod: Remove redundant import of SIZE.
* gm2-libs/FormatStrings.mod: Remove redundant import of String
and ConCatChar.
* gm2-libs/IO.mod: Remove redundant import of SIZE.
* gm2-libs/Indexing.mod: Remove redundant import of ADDRESS.
* gm2-libs/M2Dependent.mod: Remove redundant import of SIZE.
* gm2-libs/M2RTS.mod: Remove redundant import of ADDRESS.
* gm2-libs/OptLib.mod: Remove redundant import of DynamicStrings.
* gm2-libs/SYSTEM.mod: Remove redundant import of memcpy.
* gm2-libs/StringConvert.mod: Remove redundant import of String.

libgm2/ChangeLog:

* libm2iso/Makefile.am (libm2iso_la_M2FLAGS): Added line breaks.
* libm2iso/Makefile.in: Regenerate.
* libm2log/Makefile.am (libm2log_la_M2FLAGS): Added line breaks.
* libm2log/Makefile.in: Regenerate.
* libm2pim/Makefile.am (libm2pim_la_M2FLAGS): Added line breaks.
* libm2pim/Makefile.in: Regenerate.

gcc/testsuite/ChangeLog:

PR modula2/112984
* gm2/switches/pedantic/pass/hello.mod: New test.
* gm2/switches/pedantic/pass/switches-pedantic-pass.exp: New test.

Signed-off-by: Gaius Mulley 

[Bug preprocessor/112978] Five minute long error message when OpenMP pragma is erroneously placed in macro

[xry111 at gcc dot gnu.org via Gcc-bugs]

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

Xi Ruoyao  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||xry111 at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #3 from Xi Ruoyao  ---
There is nothing we can do here.

Note that GCC security policy is clear that if you need to compile some random
code completely not trust-able, use a sandbox.

And for "excessive amount of diagnostics" you may use -fmax-errors= as a
workaround.

[Bug tree-optimization/112982] Missing optimization: fold max(b, a + 1) to b when a < b

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed. Very much related to PR 110199 .

[Bug target/112987] [14 Regression][aarch64] ICE in aarch64_do_track_speculation, at config/aarch64/aarch64-speculation.cc:214 since r14-5886-g426fddcbdad674

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||pinskia at gcc dot gnu.org

[Bug target/112986] s390x gcc O2, O3: Incorrect logic operation in < comparison with the same values

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
How was gcc configured (gcc -v should print that)?  Mainly, what -march= and
-mtune= does it default to and is it PIE by default or not?
I certainly don't see anything in the -O1 vs. -O2 assembly difference that
would result in a different result.

[Bug c++/98637] Changing active union member via assignment expression should require trivial default constructor in constexpr context

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Patrick Palka  ---
This is fixed on trunk by r14-4771-g1d260ab0e39ea6, so I guess we can mark this
a dup of PR101631.

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

[Bug c++/101631] gcc allows for the changing of an union active member to be changed via a reference

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||m.cencora at gmail dot com

--- Comment #8 from Patrick Palka  ---
*** Bug 98637 has been marked as a duplicate of this bug. ***

[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #9)
> The real fix will be to const_binop .
> Right now const_binop only handles a few cases for VLA's VECTOR_CST and it
> seems like it really only handles +, -, and sometimes * and sometimes left
> shit .

I should say for stepped VLA VECTOR_CST .
In this case have one fully dup 0 and'ed with a stepped VECTOR_CST and that is
not handled.

Maybe a few special cases are needed here for &, |, ^ might be enough.

BIT_AND_EXPR: handle both 0 and -1
BIT_IOR_EXPR: handle both 0 and -1
BIT_XOR_EXPR: handle 0

[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Andrew Pinski  ---
The real fix will be to const_binop .
Right now const_binop only handles a few cases for VLA's VECTOR_CST and it
seems like it really only handles +, -, and sometimes * and sometimes left shit
.

[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

[rdapp at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Robin Dapp  ---
Yes, can confirm that this helps.

[Bug target/112988] New: [14] RISC-V vector: Variadic function call causes runtime failure

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112988
   Summary: [14] RISC-V vector: Variadic function call causes
runtime failure
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
int a = 0;
int p, q, r, x = 230;
short d;
int e[256];
static struct f w;
int *c = 

short y(short z) {
  return z * d;
}

#pragma pack(1)
struct f {
  int g;
  short h;
  int j;
  char k;
  char l;
  long m;
  long n;
  int o;
} s = {1}, v, t, *u = , *b = 

void add_em_up(int count, ...) {
  __builtin_va_list ap;
  __builtin_va_start(ap, count);
  __builtin_va_end(ap);
}

int main() {
  int i = 0;
  for (; i < 256; i++)
e[i] = i;

  p = 0;
  for (; p <= 0; p++) {
*c = 4;
*u = t;
x |= y(6 >= q);
  }

  *b = w;

  add_em_up(1, 1);

  if (a != 0)
return 1;
  if (q != 0)
return 2;
  if (p != 1)
return 3;
  if (r != 4)
return 4;
  if (x != 0xE6)
return 5;
  if (d != 0)
return 6;

  return 0;
}

Commands:
rv64gcv
> /scratch/tc-testing/tc-dec-11-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gcv -mabi=lp64d -O3 red.c -o rv64gcv.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0 
> /scratch/tc-testing/tc-dec-8-trunk/build-rv64gcv/bin/qemu-riscv64 rv64gcv.out
> echo $?
3

rv64gc
> /scratch/tc-testing/tc-dec-11-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gc -mabi=lp64d -O3 red.c -o rv64gc.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0 
> /scratch/tc-testing/tc-dec-8-trunk/build-rv64gcv/bin/qemu-riscv64 rv64gc.out
> echo $?
0

Godbolt:
https://godbolt.org/z/Pq7Yns56G

Testcase seems very similar to pr112929, filing this bug to give people an
additional testcase to look at :)

[Bug target/112987] [14 Regression][aarch64] ICE in aarch64_do_track_speculation, at config/aarch64/aarch64-speculation.cc:214 since r14-5886-g426fddcbdad674

[mjires at suse dot cz via Gcc-bugs]

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

--- Comment #1 from Michal Jireš  ---
Sorry for initially reporting with outdated GCC. Identical ICE is still present
with:

$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=aarch64-linux-gnu
--disable-bootstrap --enable-languages=c,c++ --disable-multilib
--disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231212 (experimental) (GCC)

[Bug tree-optimization/112940] ICE: verify_ssa failed: definition in block 4 does not dominate use in block 8 at -O with _BitInt()

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 56866
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56866=edit
gcc14-pr112940.patch

Untested fix.

[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Andrew Pinski  ---
Can you modify:
```
/* x & 0 -> 0  */
(simplify
 (bit_and @0 integer_zerop@1)
 @1)
```
to
```
/* x & 0 -> 0  */
(simplify
 (bit_and:c @0 integer_zerop@1)
 @1)
```

That in theory should not matter but I don't think we simplify normally VLA
constants ...

[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Andrew Pinski  ---
Looks like `{ 0, ... } & { -9, -8, -7, ... }` is not simplifying down to just
`{ 0, ...}`

[Bug tree-optimization/112982] Missing optimization: fold max(b, a + 1) to b when a < b

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/112987] New: [14 Regression][aarch64] ICE in aarch64_do_track_speculation, at config/aarch64/aarch64-speculation.cc:214 since r14-5886-g426fddcbdad674

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 112987
   Summary: [14 Regression][aarch64] ICE in
aarch64_do_track_speculation, at
config/aarch64/aarch64-speculation.cc:214 since
r14-5886-g426fddcbdad674
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: nszabolcs at gmail dot com
  Target Milestone: ---
Target: aarch64

Compiling testcase gcc.target/aarch64/eh_return-2.c results in ICE since
r14-5886-g426fddcbdad674.

$ cat eh_return-2.c
/* { dg-do compile } */
/* { dg-final { scan-assembler "add\tsp, sp, x5" } } */
/* { dg-final { scan-assembler "br\tx6" } } */

void
foo (unsigned long off, void *handler)
{
  __builtin_eh_return (off, handler);
}


$ aarch64-linux-gnu-gcc eh_return-2.c -mtrack-speculation
during RTL pass: speculation
eh_return-2.c: In function ‘foo’:
eh_return-2.c:9:1: internal compiler error: in aarch64_do_track_speculation, at
config/aarch64/aarch64-speculation.cc:214
9 | }
  | ^
0x8f6f6f aarch64_do_track_speculation()
   
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-speculation.cc:214
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.


$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master-aarch64-linux-gnu/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--target=aarch64-linux-gnu --disable-bootstrap --enable-languages=c,c++
--disable-multilib --prefix=/home/mjires/built/master-aarch64-linux-gnu/
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231207 (experimental) (GCC)

[Bug tree-optimization/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Martin Jambor  ---
Thank you, I have proposed the patch on the mailing list:

https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640356.html

If it is approved, I'd also like you to add the testcase to the testsuite as a
target specific test.

[Bug c++/93259] Unsized temporary array initialization problem

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |12.3

--- Comment #8 from Patrick Palka  ---
Fixed for GCC 12.3+ then, thanks for the heads up.

[Bug target/110625] [14 Regression][AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #22 from Tamar Christina  ---
Bisected the remaining regression to:

dd86a5a69cbda40cf76388a65d3317c91cb2b501 is the first bad commit
commit dd86a5a69cbda40cf76388a65d3317c91cb2b501
Author: Richard Biener 
Date:   Thu Jun 22 11:40:46 2023 +0200

tree-optimization/96208 - SLP of non-grouped loads

The following extends SLP discovery to handle non-grouped loads
in loop vectorization in the case the same load appears in all
lanes.

It looks like our cost model doesn't handle this change correctly,
so we over-vectorize MorphologyApply.constprop.0.  The resulting
code is significantly slower due to all the lane shufflings to
prepare the vector.

Reducing a testcase...

[Bug modula2/112984] Compiling program with -Wpedantic shows warning in libraries

[gaius at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 56865
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56865=edit
Proposed fix

Here is a proposed fix - all libraries can be compiled with -Wpedantic (apart
from two which have necessary infinite loops).  Perhaps the -Wpedantic needs to
be turned off via an attribute in these two modules (one of which is the
procedure SYSTEM.Listen which waits for activity in a set of fds).

[Bug c++/112968] Valgrind error on libstdc++-v3/testsuite/18_support/comparisons/object/93479.cc

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I believe the bug is in
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-04/msg00709.html
aka r8-7885-ga56e2f69fede451499cfcbb58bab7687e4b1643a
When tinst_level::to_list is called, if it allocates new TREE_LIST, all is
fine, but
otherwise it goes through:
  tree ret = tree_list_freelist ().alloc ();
  TREE_PURPOSE (ret) = tldcl;
  TREE_VALUE (ret) = targs;
where alloc does
T *obj = head;
head = next (head);
reinit (obj);
return obj;
and
template <>
inline void
freelist::reinit (tree obj ATTRIBUTE_UNUSED)
{
  tree_base *b ATTRIBUTE_UNUSED = >base;

#ifdef ENABLE_GC_CHECKING
  gcc_checking_assert (TREE_CODE (obj) == TREE_LIST);
  VALGRIND_DISCARD (VALGRIND_MAKE_MEM_UNDEFINED (obj, sizeof (tree_list)));
  memset (obj, 0, sizeof (tree_list));
#endif

  /* Let valgrind know the entire object is available, but
 uninitialized.  */
  VALGRIND_DISCARD (VALGRIND_MAKE_MEM_UNDEFINED (obj, sizeof (tree_list)));

#ifdef ENABLE_GC_CHECKING
  TREE_SET_CODE (obj, TREE_LIST);
#else
  VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (b, sizeof (*b)));
#endif
}

Now, tree_list is:
struct GTY(()) tree_list {
  struct tree_common common;
  tree purpose;
  tree value;
};
struct GTY(()) tree_common {
  struct tree_typed typed;
  tree chain;
};
struct GTY(()) tree_typed {
  struct tree_base base;
  tree type;
};
and the 2 stores to TREE_PURPOSE/TREE_VALUE afterwards initialize those 2, so I
believe
this leaves from valgrind annotation POV TREE_TYPE and TREE_CHAIN of the
TREE_LIST allocated from the freelist uninitialized (even when it actually is
in reality initialized from the initial build_tree_list call before it got put
into the cache).

I must say it is unclear what should be TREE_CHAIN value after
tinst_level::to_list
and what should be TREE_TYPE.  Right now it is sometimes well defined NULL and
NULL (if we allocated it freshly), sometimes NULL and NULL with valgrind think
it is uninitialized (if ENABLE_GC_CHECKING where reinit clears the whole object
and sets TREE_CODE again) and sometimes garbage with valgrind thinking it is
undefined (otherwise).
After pending_template_freelist ().alloc (); we already clear pt->next = NULL;
and
similarly after tinst_level_freelist ().alloc (); we clear new_level->next =
NULL;
so I think it is just the tree_list case.

So, wonder about
--- gcc/cp/pt.cc.jj 2023-12-11 23:52:03.592513063 +0100
+++ gcc/cp/pt.cc2023-12-12 16:40:09.259903877 +0100
@@ -9525,7 +9525,7 @@ template <>
 inline void
 freelist::reinit (tree obj ATTRIBUTE_UNUSED)
 {
-  tree_base *b ATTRIBUTE_UNUSED = >base;
+  tree_common *c ATTRIBUTE_UNUSED = >common;

 #ifdef ENABLE_GC_CHECKING
   gcc_checking_assert (TREE_CODE (obj) == TREE_LIST);
@@ -9540,8 +9540,9 @@ freelist::reinit (tree obj AT
 #ifdef ENABLE_GC_CHECKING
   TREE_SET_CODE (obj, TREE_LIST);
 #else
-  VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (b, sizeof (*b)));
+  TREE_CHAIN (obj) = NULL_TREE;
 #endif
+  VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (c, sizeof (*c)));
 }

 /* Point to the first object in the TREE_LIST freelist.  */
where this (IMHO) ought to ensure that both TREE_TYPE and TREE_CHAIN is
accessible and NULL after tinst_level::to_list regardless of whether it was
freshly allocated or not
and regardless of ENABLE_GC_CHECKING or not.

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #31 from Jan Hubicka  ---
This is Maritn's code, but I agree that equals_wpa should reject pairs with
"dangerous" attributes on them (ideally we should hash them). 
I think we could add test for same attributes to equals_wpa and eventually
white list attributes we consider mergeable?
There are attributes that serves no meaning once we enter backend, so it may be
also good option to strip them, so they are not confusing passes like ICF.

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||rguenth at gcc dot gnu.org
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #30 from Richard Biener  ---
So as a workaround it should be possible to attach no_icf to PROGMEM vars,
either in the Arduino.h header or during backend processing of the progmem
attribute.

This support could be backported if requested.

[Bug tree-optimization/112736] [14 Regression] vectorizer is introducing out of bounds memory access

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug tree-optimization/112736] [14 Regression] vectorizer is introducing out of bounds memory access

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:6d0b0806eb638447c3184c59d996c2f178553d45

commit r14-6459-g6d0b0806eb638447c3184c59d996c2f178553d45
Author: Richard Biener 
Date:   Mon Dec 11 14:39:48 2023 +0100

tree-optimization/112736 - avoid overread with non-grouped SLP load

The following aovids over/under-read of storage when vectorizing
a non-grouped load with SLP.  Instead of forcing peeling for gaps
use a smaller load for the last vector which might access excess
elements.  This builds upon the existing optimization avoiding
peeling for gaps, generalizing it to all gap widths leaving a
power-of-two remaining number of elements (but it doesn't replace
or improve that particular case at this point).

I wonder if the poly relational compares I set up are good enough
to guarantee /* remain should now be > 0 and < nunits.  */.

There is existing test coverage that runs into /* DR will be unused.  */
always when the gap is wider than nunits.  Compared to the
existing gap == nunits/2 case this only adjusts the load that will
cause the overrun at the end, not every load.  Apart from the
poly relational compares it should reliably cover these cases but
I'll leave it for stage1 to remove.

PR tree-optimization/112736
* tree-vect-stmts.cc (vectorizable_load): Extend optimization
to avoid peeling for gaps to handle single-element non-groups
we now allow with SLP.

* gcc.dg/torture/pr112736.c: New testcase.

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #29 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-6458-geee13a3730bd1d7aa7b40687b1ee49c17d95159f
Author: Richard Biener 
Date:   Mon Dec 11 10:08:24 2023 +0100

ipa/92606 - properly handle no_icf attribute for variables

The following adds no_icf handling for variables where the attribute
was rejected.  It also fixes the check for no_icf by checking both
the source and the targets decl.

PR ipa/92606
gcc/c-family/
* c-attribs.cc (handle_noicf_attribute): Also allow the
attribute on global variables.

gcc/
* ipa-icf.cc (sem_item_optimizer::merge_classes): Check
both source and alias for the no_icf attribute.
* doc/extend.texi (no_icf): Document variable attribute.

[Bug tree-optimization/112961] [13 Regression] middle-end Missed vectorization: failed to vectorize simple reduction max since GCC-13

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||14.0
   Priority|P3  |P2
Summary|[13/14 Regression]  |[13 Regression] middle-end
   |middle-end Missed   |Missed vectorization:
   |vectorization: failed to|failed to vectorize simple
   |vectorize simple reduction  |reduction max since GCC-13
   |max since GCC-13|

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/112961] [13/14 Regression] middle-end Missed vectorization: failed to vectorize simple reduction max since GCC-13

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:878cb5acf0c499702ffd315e273f55e8bd0970b8

commit r14-6457-g878cb5acf0c499702ffd315e273f55e8bd0970b8
Author: Richard Biener 
Date:   Tue Dec 12 14:01:47 2023 +0100

tree-optimization/112961 - include latch in if-conversion CSE

The following makes sure to also process the (empty) latch when
performing CSE on the if-converted loop body.  That's important
to get all uses of copies propagated out on the backedge as well.
To avoid CSE on the PHI nodes itself which is prohibitive
(see PR90402) this temporarily adds a fake entry edge to the loop.

PR tree-optimization/112961
* tree-if-conv.cc (tree_if_conversion): Instead of excluding
the latch block from VN, add a fake entry edge.

* g++.dg/vect/pr112961.cc: New testcase.

[Bug analyzer/112704] FAIL: gcc.dg/analyzer/data-model-20.c (test for warnings, line 17)

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from David Malcolm  ---
Aha!  Thanks.

[Bug target/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

[rdapp at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Robin Dapp  ---
Yes that's what I just tried.  No infinite loop anymore then.  But that's not a
new simplification and looks reasonable so there must be something special for
our backend.

[Bug target/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #4 from JuzheZhong  ---
Maybe try to remove this ?

 /* (X & Y) == X becomes (X & ~Y) == 0.  */
 (simplify
  (cmp:c (bit_and:c @0 @1) @0)
  (cmp (bit_and @0 (bit_not! @1)) { build_zero_cst (TREE_TYPE (@0)); }))
 (simplify
  (cmp:c (convert@3 (bit_and (convert@2 @0) INTEGER_CST@1)) (convert @0))
  (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
   && INTEGRAL_TYPE_P (TREE_TYPE (@2))
   && INTEGRAL_TYPE_P (TREE_TYPE (@3))
   && TYPE_PRECISION (TREE_TYPE (@2)) == TYPE_PRECISION (TREE_TYPE (@0))
   && TYPE_PRECISION (TREE_TYPE (@3)) > TYPE_PRECISION (TREE_TYPE (@2))
   && !wi::neg_p (wi::to_wide (@1)))
   (cmp (bit_and @0 (convert (bit_not @1)))
{ build_zero_cst (TREE_TYPE (@0)); })))

[Bug middle-end/112985] LOGICAL_OP_NON_SHORT_CIRCUIT unconditionally execute comparison even if it's very expensive

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Richard Biener  ---
Btw, ideally you'd vectorize these compares ;)  (there's a missed-optimization
bug for this I think)

[Bug target/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

[rdapp at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Robin Dapp  ---
In match.pd we do something like this:


;; Function e (e, funcdef_no=0, decl_uid=2751, cgraph_uid=1, symbol_order=4)


Pass statistics of "forwprop": 

Matching expression match.pd:2771, gimple-match-2.cc:35
Matching expression match.pd:2774, gimple-match-1.cc:66
Matching expression match.pd:2781, gimple-match-2.cc:96
Aborting expression simplification due to deep recursion
Aborting expression simplification due to deep recursion
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
gimple_simplified to _53 = { 0, ... } & { 8, 7, 6, ... };
_63 = { 0, ... } & { -9, -8, -7, ... };
_52 = { 0, ... } & { 8, 7, 6, ... };
_74 = { 0, ... } & { -9, -8, -7, ... };
_38 = { 0, ... } & { 8, 7, 6, ... };
_40 = { 0, ... } & { -9, -8, -7, ... };
_55 = { 0, ... } & { 8, 7, 6, ... };
_57 = { 0, ... } & { -9, -8, -7, ... };
_65 = { 0, ... } & { 8, 7, 6, ... };
_72 = { 0, ... } & { -9, -8, -7, ... };
_32 = { 0, ... } & { 8, 7, 6, ... };
mask__6.19_61 = _32 == { 0, ... };

That doesn't look particularly backend related but we're trying to simplify a
mask so you never know...

[Bug middle-end/112985] LOGICAL_OP_NON_SHORT_CIRCUIT unconditionally execute comparison even if it's very expensive

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #2 from Richard Biener  ---
LOGICAL_OP_NON_SHORT_CIRCUIT is applied very early and is only based on branch
cost (not "compare cost").  It is IMHO premature optimization but it's been
that way forever.  It has similarly be adopted by the later run ifcombine pass
(originally one idea was to get rid of the early short-circuiting in
fold-const.cc but preserving actual behavior).  Note ifcombine also doesn't
care about cost but RTL expansion should when deciding whether to expand
t1x > t2y | t2x < t1y as branch or not.

My suggestion is to look at RTL expansion

[Bug middle-end/112985] LOGICAL_OP_NON_SHORT_CIRCUIT unconditionally execute comparison even if it's very expensive

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #1 from chenglulu  ---
(In reply to Xi Ruoyao from comment #0)
> /* { dg-do compile } */
> /* { dg-options "-O2 -ffast-math -fdump-tree-gimple" } */
> 
> int
> short_circuit (float *a)
> {
>   float t1x = a[0];
>   float t2x = a[1];
>   float t1y = a[2];
>   float t2y = a[3];
>   float t1z = a[4];
>   float t2z = a[5];
> 
>   if (t1x > t2y  || t2x < t1y  || t1x > t2z || t2x < t1z || t1y > t2z || t2y
> < t1z)
> return 0;
> 
>   return 1;
> }
> 
> on LoongArch it produces something like:
> 
>   _1 = t1x > t2y;
>   _2 = t2x < t1y;
>   _3 = _1 | _2; 
>   if (_3 != 0) goto ; else goto ;
>   :
>   _4 = t1x > t2z;
>   _5 = t2x < t1z;
>   _6 = _4 | _5; 
>   if (_6 != 0) goto ; else goto ;
>   :
>   _7 = t1y > t2z;
>   _8 = t2y < t1z;
>   _9 = _7 | _8; 
>   if (_9 != 0) goto ; else goto ;
>   :
>   D.2209 = 0;
> 
> but it's better to produce 6 if (per
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640313.html it will
> produce a 1.8% improvement in SPECCPU 2017 fprate).
> 
> One obvious issue is LoongArch cost model for FP comparison is incorrect
> (PR112936) but even if I set the cost of floating-point comparison to 5000
> the gimple still produces 3 if with non-shorted comparisons.

I agree that the code should generate logic similar to a fixed point:

  slt $r17,$r15,$r14
  slt $r13,$r16,$r12
  or  $r13,$r13,$r17
  bstrpick.w  $r13,$r13,7,0 
  bnez$r13,.L3