[Bug fortran/110241] Redundant temporaries passing empty array constructors

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #1 from Mikael Morin  ---
Somehow related, but with non-empty arguments: PR38111, PR55839

[Bug target/110227] [13/14 Regression] gcc generates invalid AVX-512 code

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

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

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

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

commit r14-1802-gb7e42b85212e03eb59193a712eb523f26911a581
Author: liuhongt 
Date:   Tue Jun 13 14:20:59 2023 +0800

Use x instead of v for alternative 2 (v, BH) in mov_internal.

Since there's no evex version for vpcmpeq ymm, ymm, ymm.

gcc/ChangeLog:

PR target/110227
* config/i386/sse.md (mov_internal>): Use x instead of v
for alternative 2 since there's no evex version for vpcmpeqd
ymm, ymm, ymm.

gcc/testsuite/ChangeLog:

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

[Bug target/110227] [13/14 Regression] gcc generates invalid AVX-512 code

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-13 branch has been updated by hongtao Liu
:

https://gcc.gnu.org/g:66f8f9b35f0499cf54b8a432fbe5f645ad1c523a

commit r13-7445-g66f8f9b35f0499cf54b8a432fbe5f645ad1c523a
Author: liuhongt 
Date:   Tue Jun 13 14:20:59 2023 +0800

Use x instead of v for alternative 2 (v, BH) in mov_internal.

Since there's no evex version for vpcmpeq ymm, ymm, ymm.

gcc/ChangeLog:

PR target/110227
* config/i386/sse.md (mov_internal>): Use x instead of v
for alternative 2 since there's no evex version for vpcmpeqd
ymm, ymm, ymm.

gcc/testsuite/ChangeLog:

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

[Bug target/110227] [13/14 Regression] gcc generates invalid AVX-512 code

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Hongtao.liu  ---
Fixed for GCC14 and GCC13.2

[Bug target/110235] [14 Regression] Wrong use of us_truncate in SSE and AVX RTL representation

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #2)
> FAIL: gcc.target/i386/avx2-vpackssdw-2.c execution test
> 
> This one is about sign saturation which should match rtl SS_TRUNCATE.

I realize for 256-bit/512-bit vpackssdw, it's an 128-bit iterleave of src1 and
src2, and then ss_truncate to the dest, not just vec_concat src1 and src2. So
the simplification exposed the bug.

[Bug middle-end/90094] better handling of x == LONG_MIN on x86-64

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
But then shouldn't we do it not just for equality/non-equality comparisons
against 0x8000, but also for equality/non-equality comparisons
against 0x7fff or signed non-equality comparisons like >
__LONG_MAX__ - 42
or >= __LONG_MAX__ - 0x7f00 etc.

I mean
void fn (void);

unsigned
f1 (long a)
{
  return a == -__LONG_MAX__ - 1;
}

void
f2 (long a)
{
  if (a == -__LONG_MAX__ - 1)
fn ();
}

unsigned
f3 (long a)
{
  return __builtin_sub_overflow_p (0, a, 0L);
}

void
f4 (long a)
{
  if (__builtin_sub_overflow_p (0, a, 0L))
fn ();
}

unsigned
f5 (long a)
{
  return a == __LONG_MAX__;
}

void
f6 (long a)
{
  if (a == __LONG_MAX__)
fn ();
}

unsigned
f7 (long a)
{
  return __builtin_add_overflow_p (a, 1, 0L);
}

void
f8 (long a)
{
  if (__builtin_add_overflow_p (a, 1, 0L))
fn ();
}

unsigned
f9 (long a)
{
  return a >= __LONG_MAX__ - 42;
}

void
f10 (long a)
{
  if (a >= __LONG_MAX__ - 42)
fn ();
}

unsigned
f11 (long a)
{
  return __builtin_add_overflow_p (a, 43, 0L);
}

void
f12 (long a)
{
  if (__builtin_add_overflow_p (a, 43, 0L))
fn ();
}

unsigned
f13 (long a)
{
  return a <= -__LONG_MAX__ + 42;
}

void
f14 (long a)
{
  if (a <= -__LONG_MAX__ + 42)
fn ();
}

unsigned
f15 (long a)
{
  return __builtin_sub_overflow_p (a, 43, 0L);
}

void
f16 (long a)
{
  if (__builtin_sub_overflow_p (a, 43, 0L))
fn ();
}

The question if it should be done in the cstoredi4 and cbranchdi4 expanders, or
matched later say during combine, or peephole2.

[Bug middle-end/90094] better handling of x == LONG_MIN on x86-64

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

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

--- Comment #5 from Jakub Jelinek  ---
One argument against doing it during expansion is that if we need the large
constant for other purposes, loading it with movabsq and just doing comparison
is better, the overflow way also clobbers the register which is being compared.

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

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

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

--- Comment #3 from Aldy Hernandez  ---
(In reply to Andrew Pinski from comment #2)
> VRP2/DOM3 produces the wrong folding for some reason:
> Folding statement: _27 = b.6_9 * 2;
> Queued stmt for removal.  Folds to: 2147483647
> 
> I don't uinderstand how it could get that from:

Putting a breakpoint in execute_ranger_vrp() for the VRP2 instance, and dumping
what the ranger knows with debug_ranger() we see:

=== BB 3 
b.6_9   [irange] int [1334323000, +INF] NONZERO 0x7fff
 [local count: 357878153]:
_28 = b.6_9 * 2;
ivtmp.19_27 = 2147483647;
ivtmp.22_31 = (unsigned long) &f;
goto ; [100.00%]

ivtmp.19_27 : [irange] unsigned int [2147483647, 2147483647] NONZERO 0x7fff
_28 : [irange] int [+INF, +INF] NONZERO 0x7ffe
ivtmp.22_31 : [irange] unsigned long [1, +INF]

So on entry to BB3, b.6_9 is [1334323000, +INF].  This comes from the 2->3
edge, which is the only incoming edge to BB3.

Isn't multiplying any number in that range an overflow, and thus undefined?

Ranger is coming back with:

_28 : [irange] int [+INF, +INF] NONZERO 0x7ffe

which sounds reasonable, and the reason you're seeing 2147483647.

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

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

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

--- Comment #4 from Aldy Hernandez  ---
FWIW, a less intrusive and probably more correct way of seeing what ranger
knows at this point would be to put a breakpoint where you're seeing:

Queued stmt for removal.  Folds to: 2147483647

This is in tree-ssa-propagate.cc.

There you can do:

(gdb) p cfun->x_range_query->dump (stderr)

which will pick up the current ranger and dump what it knows about the IL,
without tickling any new queries:

...
...
=== BB 3 
b.6_9   [irange] int [1334323000, +INF] NONZERO 0x7fff
 [local count: 357878153]:
_28 = b.6_9 * 2;
ivtmp.19_27 = 2147483647;
ivtmp.22_31 = (unsigned long) &f;
goto ; [100.00%]

_28 : [irange] int [+INF, +INF] NONZERO 0x7ffe

[Bug tree-optimization/110248] New: ivopts could under-cost for some addressing modes on len_{load,store}

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

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

Bug ID: 110248
   Summary: ivopts could under-cost for some addressing modes on
len_{load,store}
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linkw at gcc dot gnu.org
  Target Milestone: ---

[Bug target/110104] gcc produces sub-optimal code for _addcarry_u64 chain

[slash.tmp at free dot fr via Gcc-bugs]

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

--- Comment #2 from Mason  ---
You meant PR79173 ;)

Latest update:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621554.html

I didn't see my testcase specifically in Jakub's patch,
but I'll test trunk on godbolt when/if the patch lands.

[Bug target/54089] [SH] Refactor shift patterns

[klepikov.alex+bugs at gmail dot com via Gcc-bugs]

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

--- Comment #73 from Alexander Klepikov  
---
I had to check everything a few more times because I found a bug in my patch
that caused the long shifts to expand incorrectly. I added a test that checks
correct shifts expansion in this regard.

I also managed to make a test that verifies hoisting. It can be done with
'scan-assembler' command and regexp.

If you're interested, there's more powerful command 'check-function-bodies',
but it looks like it works only when C++ cross compiler is built, so I decided
to leave the regexp.

[Bug target/54089] [SH] Refactor shift patterns

[klepikov.alex+bugs at gmail dot com via Gcc-bugs]

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

Alexander Klepikov  changed:

   What|Removed |Added

  Attachment #55284|0   |1
is obsolete||

--- Comment #74 from Alexander Klepikov  
---
Created attachment 55321
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55321&action=edit
Collapsed libcall and additional loop move invariants patch v2

Creating Apps...

[Bianca Townsend via Gcc-bugs]

Hello, 

Hope you are doing well. 

Would you be interested in building your Mobile app or any types of Software
development? 

We have expertise in: 

. Tours and Travel App 

. Business/ Finance applications 

. Fitness App 

. GPS navigation 

. E-learning App 

. E-commerce App & etc.  

. Service Industry App eg. Doctor, Lawyer, Elevator. Repair, Etc. 

PS: If you are interested, Please share your App idea, requirement.

Kind Regards, 

Bianca Townsend

Business Consultant India

[Bug c++/57111] Generalize -Wfree-nonheap-object to delete

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

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

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

https://gcc.gnu.org/g:9c03391ba447ff86038d6a34c90ae737c3915b5f

commit r14-1805-g9c03391ba447ff86038d6a34c90ae737c3915b5f
Author: Thomas Schwinge 
Date:   Wed Jun 7 16:24:26 2023 +0200

Tighten 'dg-warning' alternatives in
'c-c++-common/Wfree-nonheap-object{,-2,-3}.c'

..., added in commit fe7f75cf16783589eedbab597e6d0b8d35d7e470
"Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR
c++/57111, PR middle-end/98160)".

These use alternatives like, for example, "AB|CDE|FG", but what really
must've
been meant is "A(B|C)D(E|F)G".  The former variant also does "work": it
matches
any of "AB", or "CDE", or "FG", which are components of the latter variant.
(That means, the former variant matches too loosely.)

gcc/testsuite/
* c-c++-common/Wfree-nonheap-object-2.c: Tighten 'dg-warning'
alternatives.
* c-c++-common/Wfree-nonheap-object-3.c: Likewise.
* c-c++-common/Wfree-nonheap-object.c: Likewise.

[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

https://gcc.gnu.org/g:9c03391ba447ff86038d6a34c90ae737c3915b5f

commit r14-1805-g9c03391ba447ff86038d6a34c90ae737c3915b5f
Author: Thomas Schwinge 
Date:   Wed Jun 7 16:24:26 2023 +0200

Tighten 'dg-warning' alternatives in
'c-c++-common/Wfree-nonheap-object{,-2,-3}.c'

..., added in commit fe7f75cf16783589eedbab597e6d0b8d35d7e470
"Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR
c++/57111, PR middle-end/98160)".

These use alternatives like, for example, "AB|CDE|FG", but what really
must've
been meant is "A(B|C)D(E|F)G".  The former variant also does "work": it
matches
any of "AB", or "CDE", or "FG", which are components of the latter variant.
(That means, the former variant matches too loosely.)

gcc/testsuite/
* c-c++-common/Wfree-nonheap-object-2.c: Tighten 'dg-warning'
alternatives.
* c-c++-common/Wfree-nonheap-object-3.c: Likewise.
* c-c++-common/Wfree-nonheap-object.c: Likewise.

[Bug c/110249] New: __builtin_unreachable helps optimisation at -O1 but not at -O2

[david at westcontrol dot com via Gcc-bugs]

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

Bug ID: 110249
   Summary: __builtin_unreachable helps optimisation at -O1 but
not at -O2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at westcontrol dot com
  Target Milestone: ---

Sometimes it can be useful to use __builtin_unreachable() to give the compiler
hints that can improve optimisation.  For example, it can be used here to tell
the compiler that the parameter is always 8-byte aligned:

#include 
#include 

uint64_t read64(const uint64_t * p) {
if ((uint64_t) p % 8 ) {
__builtin_unreachable();
}
 uint64_t value;
 memcpy( &value, p, sizeof(uint64_t) );
 return value; 
}

For some targets, such as 32-bit ARM and especially RISC-V, this can make a
difference to the generated code.  In testing, when given -O1 the compiler
takes advantage of the explicit undefined behaviour to see that the pointer is
aligned, and generates a single 64-bit load.  With -O2, however, it seems that
information is lost - perhaps due to earlier optimisation passes - and now slow
unaligned load code is generated.

Ideally, such optimisation information from undefined behaviour (explicit via a
builtin, or implicit via other code) should be kept - -O2 should have at least
as much information as -O1.  An alternative would be the addition of a more
directed "__builtin_assume" function that could be used.

(I know that in this particular case, __builtin_assume_aligned is available and
works exactly as intended at -O1 and -O2, but I think this is a more general
issue than just alignments.)

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

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
Sorry, was your recent patch g:1c3661e224e3ddfc6f773b095740c0f5a7ddf5fc
tackling a different issue?

[Bug c/110249] __builtin_unreachable helps optimisation at -O1 but not at -O2

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
Please show 'gcc -v' for the case when you get one aligned load at -O1.

[Bug c/110249] __builtin_unreachable helps optimisation at -O1 but not at -O2

[david at westcontrol dot com via Gcc-bugs]

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

--- Comment #2 from David Brown  ---
My apologies - it does not optimise the code to a single aligned load at -O1
(at least, not with the combinations I have now tried).  The code was
originally C++, with a reference, which /does/ exhibit this behaviour of having
better code at -O1 than -O2.  I had translated the reference to a pointer to
get more generic code that is valid as C and C++, but I don't see the same
effect with the pointer.

For a reference, the issue is as I first described:

#include 
#include 

uint64_t read64r(const uint64_t &x) {
if ((uint64_t) &x % 8 ) {
__builtin_unreachable();
}
 uint64_t value;
 memcpy( &value, &x, sizeof(uint64_t) );
 return value; 
}

I tested with 64-bit RISC-V and 32-bit ARM using trunk (gcc 13.1, I think) on
godbolt.org.  The only relevant flag was the optimisation level.

[Bug tree-optimization/110248] ivopts could under-cost for some addressing modes on len_{load,store}

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

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

Kewen Lin  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||juzhe.zhong at rivai dot ai,
   ||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
 Target||powerpc*-linux-gnu

--- Comment #1 from Kewen Lin  ---
Commit r14-1493 caused -4% degradation on SPEC2017 fp bmk 503.bwaves_r at
option -Ofast --param=vect-partial-vector-usage=2 on Power10, as a follow up of
[1], I looked into it and confirmed it had nothing to do with existing load
density heuristics. The gap is from the hotspot mat_times_vec_, perf showed
that the different iv choices leading more latency for the length and further
uses.

By further checking, I think it exposed one issue that currently we only checks
the addressing mode supported or not against the mode, it's without any other
information like gimple statement. Unfortunately for IFNs len_{load,store}
which are generated with lxvl/stxvl only supporting the addressing mode: base
register (+ length register, which isn't even index register), but when
determining the group cost with cand (determine_group_iv_cost_address), it's
unable to consider this characteristic, as the current valid_mem_ref_p
(valid_mem_ref_p-> memory_address_addr_space_p ->legitimate_address_p) only
checking mode, address_space, constructed rtx. For V16QImode, the normal vector
load/store do support addressing modes "base + offset (DQ-form)", "base +
index" since power9, so ivopts would consider it's fine to use base + index
addressing mode for LEN_{load,store} uses and the related cost of adopting the
scalar (no address object based) candidate with step 16 for those
LEN_{load,store} uses is zero.

For example:

| Group 1:
|   Type: POINTER ARGUMENT ADDRESS
|   Use 1.0:
| At stmt:vect_434 = .LEN_LOAD (vectp_y.124_438, 64B, loop_len_436, 0);
| At pos: vectp_y.124_438
| IV struct:
|   Type: vector(2) real(kind=8) *
|   Base: (vector(2) real(kind=8) *) vectp_y.125_195
|   Step: 32
|   Object:   (void *) vectp_y.125_195
|   Biv:  N
|   Overflowness wrto loop niter: Overflow
|   Use 1.1:
| At stmt:.LEN_STORE (vectp_y.173_213, 64B, loop_len_436, vect_211, 0);
| At pos: vectp_y.173_213
| IV struct:
|   Type: vector(2) real(kind=8) *
|   Base: (vector(2) real(kind=8) *) vectp_y.125_195
|   Step: 32
|   Object:   (void *) vectp_y.125_195
|   Biv:  N
|   Overflowness wrto loop niter: Overflow

| Candidate 7:
|   Var befor: ivtmp.182
|   Var after: ivtmp.182
|   Incr POS: before exit test
|   IV struct:
| Type:   sizetype
| Base:   0
| Step:   32
| Biv:N
| Overflowness wrto loop niter:   No-overflow

  Group 1:
cand  costcompl.  inv.expr.   inv.vars
1 8   2   NIL;1
2 12  2   18; NIL;
3 8   2   NIL;1
4 12  2   19; NIL;
5 12  2   19; NIL;
6 0   2   NIL;NIL;
7 0   2   NIL;1 ==> zero cost
8 0   0   NIL;NIL;
9 0   0   NIL;NIL;
310   0   NIL;NIL;

[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620305.html

[Bug tree-optimization/110248] ivopts could under-cost for some addressing modes on len_{load,store}

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

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

--- Comment #2 from Kewen Lin  ---
Can you extend the current hook legitimate_address_p with one default value
nullptr gimple* argument? When middle-end passes like ivopts want to query with
the constructed address reference, it can pass the gimple statement as the
context?

[Bug tree-optimization/110248] ivopts could under-cost for some addressing modes on len_{load,store}

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

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

--- Comment #3 from JuzheZhong  ---
You mean add a default argument = nullptr to targethook legitimate_address_p to
let powerPC do more middle-end address ivopts analysis?

If yes, I am ok with that. Let's see Richard and Richi more comments.

Thanks.

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

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

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

--- Comment #2 from Richard Biener  ---
(In reply to Alexander Monakov from comment #1)
> Sorry, was your recent patch g:1c3661e224e3ddfc6f773b095740c0f5a7ddf5fc
> tackling a different issue?

Yes, the issue in this bug persists after the above fix.

[Bug tree-optimization/110243] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/110249] __builtin_unreachable helps optimisation at -O1 but not at -O2

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

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

--- Comment #3 from Richard Biener  ---
We could pattern-match this to

 p = __builtin_assume_aligned (p, 8);

which is btw the better way to write this.

[Bug web/110250] New: Broken url to README in st/cli-be project

[jivanhakobyan9 at gmail dot com via Gcc-bugs]

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

Bug ID: 110250
   Summary: Broken url to README in st/cli-be project
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jivanhakobyan9 at gmail dot com
  Target Milestone: ---

In the CLI project link to README is broken (error 404).
https://gcc.gnu.org/projects/cli.html#contributing

I may try to fix that, but not sure to which file should be referred.

[Bug tree-optimization/110248] ivopts could under-cost for some addressing modes on len_{load,store}

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

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

--- Comment #4 from Richard Biener  ---
I think the main issue is that IVOPTs treats all of the memory access
internal functions as calls and thus the pointer "argument" as
address calculation only and thus costs it as such.

To fix this IVOPTs needs to treat those internal functions as memory
accesses and accordingly represent this to the target when building
the fake RTL to cost (and there neither masks nor lens are considered).

The GIMPLE in the end will have the address calculation split out
(as if it could be CSEd between different references) to sth like

 _1 = &TARGET_MEM_REF <>;
 .LEN_STORE (_1, ...);

where &TARGET_MEM_REF <> is then a LEA and the .LEN_STORE the
simplest register indirect reference.  Currently IVOPTs should
get the LEA part right but it doesn't cost the simple register indirect
reference.

Of course in the end we'd like to anticipate merging the LEA with
the .LEN_STORE (for the cases valid).

Do I understand the issue is that only the last bit doesn't work
but costing the LEA does?

[Bug d/109231] [13/14 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

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

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #39 from Rainer Orth  ---
(In reply to Jakub Jelinek from comment #38)
> As nobody but Rainer managed to reproduce this and we don't know what's
> going on, postponing for 13.2.

When building the gcc-13 branch for the first time, I forgot to include the
workaround patch for this PR, still the build went just fine without.  Later
on, I disabled the workaround for trunk, too, without ill effect.  I guess
we can close this for now: should the issue ever reappear, I'll reopen.

[Bug modula2/108344] Many tests time out: isatty called in a tight loop

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

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #6 from Rainer Orth  ---
I hadn't seen those timeout for quite some time even before your patch
(roughly since 20230123). So it seems whatever caused this is fixed (or at
least masked).

[Bug middle-end/96365] GCC report impossible constraint on possible inline assembly output constraints

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

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

wierton <141242068 at smail dot nju.edu.cn> changed:

   What|Removed |Added

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

--- Comment #3 from wierton <141242068 at smail dot nju.edu.cn> ---
Compiler has no need to take it as a CSP problem.

[Bug c/110249] __builtin_unreachable helps optimisation at -O1 but not at -O2

[david at westcontrol dot com via Gcc-bugs]

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

--- Comment #4 from David Brown  ---
Yes, __builtin_assume_aligned is the best way to write things in this
particular case (and optimises fine for -O1 and -O2).  It is also clearer in
the source code (IMHO), as it shows the programmer's intention better.

I am just a little concerned that optimisation hints provided by the programmer
via __builtin_unreachable are getting lost at -O2.  When the compiler knows
that something cannot happen - whether by __builtin_unreachable or by other
code analysis - it can often use that information to generate more efficient
code.  If that information can be used for better code at -O1, but is lost at
-O2, then something is wrong in the way that information is collected or passed
on inside the compiler.  Any case of -O1 generating more efficient code than
-O2 is a sign of a problem or limitation.

So I am not particularly bothered about this one piece of code - I am reporting
the issue because it might be an indication of a wider problem.

[Bug middle-end/108410] x264 averaging loop not optimized well for avx512

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

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug tree-optimization/107096] Fully masking vectorization with AVX512 ICEs gcc.dg/vect/vect-over-widen-*.c

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Resolution|--- |INVALID

--- Comment #14 from Richard Biener  ---
Not a bug.

[Bug tree-optimization/110248] ivopts could under-cost for some addressing modes on len_{load,store}

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

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
ivopts does have code to treat ifn pointer arguments specially,
see get_mem_type_for_internal_fn &co.  But like Kewen says,
it's still only based on the mode.

Personally I'd prefer an internal_fn rather than a gimple* though.
It can be useful to test these things on a possible future statement,
not just on one that already exists.

[Bug tree-optimization/110248] ivopts could under-cost for some addressing modes on len_{load,store}

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

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

--- Comment #6 from Richard Biener  ---
(In reply to rsand...@gcc.gnu.org from comment #5)
> ivopts does have code to treat ifn pointer arguments specially,
> see get_mem_type_for_internal_fn &co.  But like Kewen says,
> it's still only based on the mode.

But the dump quoted says 'Type: POINTER ARGUMENT ADDRESS' which means
that doesn't work as desired.  That is, the use is classified wrongly
and the above function only seems to be useful to get the mode of
the memory access done by the internal function?

USE_PTR_ADDRESS doesn't seem to be a very good match to capture
constraints for a memory dereference?

> Personally I'd prefer an internal_fn rather than a gimple* though.
> It can be useful to test these things on a possible future statement,
> not just on one that already exists.

Well yes, passing down a gimple * looks like too generic here.  Maybe
use a code_helper so we can pass down MEM_REF for dereference context
and nothing (ERROR_MARK_NODE?) for plain address use?

[Bug web/110250] Broken url to README in st/cli-be project

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
It's under refs/vendors/st in the new git repo:

https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=README;h=1b3709666818ce43833c42bd858e14ff3d233ff6;hb=refs/vendors/st/heads/README

You can use 'git ls-remote git://gcc.gnu.org/git/gcc.git' to view the list of
all remote heads and tags (or just 'git ls-remote' from a cloned repo).

[Bug web/110250] Broken url to README in st/cli-be project

[jivanhakobyan9 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Jivan Hakobyan  ---
Thank you.
Will fix and send the patch to gcc-patches.

[Bug rtl-optimization/110215] RA fails to allocate register when loop invariant lives across calls and eh

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

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

--- Comment #4 from Vladimir Makarov  ---
(In reply to Richard Biener from comment #3)
> 
> 
> We don't have any pass after reload that would perform loop invatiant motion,
> I'm not sure how this situation is handled in general in RA - is a post-RA
> pass optimizing the spill/reload placement "globally" usually done?

LRA does not do placement of reload insns.  Global RA is supposed to do this
when it forms regions for the allocation.

I've been working on this issue.  I hope the fix will be ready on this week.

[Bug c++/86521] [8 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template

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

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

--- Comment #18 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:4ec6b627cb008e31ea3d1ee93a209297f56c6a3e

commit r14-1810-g4ec6b627cb008e31ea3d1ee93a209297f56c6a3e
Author: Jason Merrill 
Date:   Fri Mar 3 15:04:25 2023 -0500

c++: tweak c++17 ctor/conversion tiebreaker [DR2327]

In discussion of this issue CWG decided that the change of behavior on
well-formed code like overload-conv-4.C is undesirable.  In further
discussion of possible resolutions, we discovered that we can avoid that
change while still getting the desired behavior on overload-conv-3.C by
making this a tiebreaker after comparing conversions, rather than before.
This also simplifies the implementation.

The issue resolution has not yet been finalized, but this seems like a
clear
improvement.

DR 2327
PR c++/86521

gcc/cp/ChangeLog:

* call.cc (joust_maybe_elide_copy): Don't change cand.
(joust): Move the elided tiebreaker later.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/overload-conv-4.C: Remove warnings.
* g++.dg/cpp1z/elide7.C: New test.

[Bug c/110251] New: Hang at -O3 on x86_64-linux-gnu

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 110251
   Summary: Hang at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
  Target Milestone: ---

Since GCC-13, gcc -O3 would hang on the following testcase.

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

$ cat a.c
int a, b;
char c;
int d(int e) {
  if (e >= 'a')
return e;
}
int f(unsigned short e) {
  for (; e; a++)
e &= e - 1;
}
void g() {
  for (; c < 1;)
;
  for (; f(c - 1); b = d(c))
;
}
$
$ gcc-tk -O3 a.c 
Killed - processing time exceeded
$
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-bf470895905e9152424076d1630a9d2c60de023b/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-bf470895905e9152424076d1630a9d2c60de023b
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230612 (experimental) (GCC) 
$

[Bug c/110252] New: Wrong code at -O2/3/s on x86_64-linux-gnu

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 110252
   Summary: Wrong code at -O2/3/s on x86_64-linux-gnu
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
  Target Milestone: ---

This seems to be a recent regression. 

Compiler explorer: https://godbolt.org/z/TW97cdYxv

$ cat a.c
int printf(const char *, ...);
int d, f;
const char a = 239;
short e, b, h = 2;
long g;
short *c = &e;
int *i = &f;
int(j)(int k, int l) { return k < 0 ? k : k >> l; }
int main() {
  for (;;) {
g = (char)d + a;
b = h && j(g, 6);
*c = b;
*i = e;
break;
  }
  printf("%d\n", f);
}
$
$ gcc-tk -O0 a.c && ./a.out
1
$ gcc-tk -O1 a.c && ./a.out
1
$ gcc-tk -O2 a.c && ./a.out
-1
$ gcc-tk -O3 a.c && ./a.out
-1
$ gcc-tk -Os a.c && ./a.out
-1
$
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-bf470895905e9152424076d1630a9d2c60de023b/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-bf470895905e9152424076d1630a9d2c60de023b
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230612 (experimental) (GCC) 
$

[Bug other/110253] New: The documentation for -ftrapv seems to have an incomplete list of operations

[gennaro.prota+gccbugzilla at gmail dot com via Gcc-bugs]

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

Bug ID: 110253
   Summary: The documentation for -ftrapv seems to have an
incomplete list of operations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gennaro.prota+gccbugzilla at gmail dot com
  Target Milestone: ---

The documentation
() for
`-ftrapv` states:

-ftrapv

This option generates traps for signed overflow on addition, subtraction,
multiplication operations.

Is there any reason why division and negation (unary minus) are not mentioned?
If the intent is to check for any signed overflow, I'd suggest not listing the
operations at all, and simply say something like this, instead:

This option generates traps for signed overflow.

[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-14
  Component|c   |tree-optimization
 Status|UNCONFIRMED |ASSIGNED
Summary|Wrong code at -O2/3/s on|[14 Regression] Wrong code
   |x86_64-linux-gnu|at -O2/3/s on
   ||x86_64-linux-gnu
   Target Milestone|--- |14.0
   Keywords||wrong-code
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
So phiopt does this:
phiopt match-simplify trying:
_4 >= 0 ? iftmp.0_16 : 1
Matching expression match.pd:1990, gimple-match-5.cc:23
Matching expression match.pd:1990, gimple-match-5.cc:23
Applying pattern match.pd:5283, gimple-match-2.cc:942
Applying pattern match.pd:1378, gimple-match-2.cc:7699
Applying pattern match.pd:1885, gimple-match-3.cc:2770
Applying pattern match.pd:4745, gimple-match-7.cc:15371
Folded into the sequence:
_22 = _4 >= 0;
_21 = (int) _22;
_23 = _4 < 0;
_24 = (int) _23;
_25 = iftmp.0_16 | _24;
statement un-sinked:
iftmp.0_16 = _4 >> 6;

The problem is `_4 >> 6` only has a [0,1] range iff `_4 < 0`.
I have to think of a way of fixing this without too much trouble. Maybe
reverting the patch might be the best for now. But there could be other issues
dealing with phiopt and match-and-simplify later on for a similar reasons ...

[Bug tree-optimization/59660] We fail to optimize common boolean checks pre-inlining

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

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

--- Comment #16 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Andrew Pinski from comment #13)
> > Using the C front-end we still have a casting issue.
> 
> There are a few issues of even for the C++ front-end IR:
> I will have to think of how to handle this in the current code but it is
> definitely more complex really because you have 2 phi nodes to worry about
> and such.

So I accidently stumbled on why the C++ IR is this way.
make_forwarders_with_degenerate_phis for cd_dce undoes what mergephi did (which
is was before dse). I can fix this by moving the mergephi right after cd_dce. I
am still deciding if this is the best thing.

[Bug target/110247] suboptimal code about `no_caller_saved_registers` on caller side

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #1 from Andrew Pinski  ---
The way I read the documentation, it will NOT be used when dealing with calls
to that function but rather the function that has that attribute will save all
registers and restore them at the end.
And it is used only for calls from an interrupt handler (e.g. directly from
assembly). and even more you need to use -mgeneral-regs-only too.

[Bug driver/71850] @file should be used to cc1/cc1plus when @file is used

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Costas Argyris  ---
Fixed by
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=180ebb8a24d24fc5b105f2257d6216f6dfde62df

Also this is windows-host-specific (Host field in the PR is empty).

[Bug rtl-optimization/110254] New: improve_allocation() routine does not update allocated_hardreg_p[] array

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

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

Bug ID: 110254
   Summary: improve_allocation() routine does not update
allocated_hardreg_p[] array
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jskumari at gcc dot gnu.org
  Target Milestone: ---

"allocated_hardreg_p[]" is a boolean array whose element value is TRUE is the
corresponding hard register was already allocated for an allocno.
This array is used in calculate_saved_nregs().

The improve_allocation() function improves the allocation by spilling some
allocnos and assigning the freed hard registers to other allocnos if it
decreases the overall allocation cost.

If the register chosen in improve_allocation() is one that already has been
assigned to a conflicting allocno, then allocated_hardreg_p[] already has the
corresponding bit set to TRUE, so nothing needs to be done.

But improve_allocation() can also choose a register that has not been assigned
to a conflicting allocno, and also has not been assigned to any other allocno.
In this case, allocated_hardreg_p[] has to be updated. improve_allocation()
calls assign_hard_reg() to check if any of the spilled allocnos can get hard
registers.
And assign_hard_reg() calls calculate_saved_nregs() which uses the array.
Hence, the array needs to be updated.

[Bug target/110255] New: arm: MVE intrinsics C++ polymorphism with -flax-vector-conversions

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

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

Bug ID: 110255
   Summary: arm: MVE intrinsics C++ polymorphism with
-flax-vector-conversions
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stammark at gcc dot gnu.org
  Target Milestone: ---

Hi all,
See: https://godbolt.org/z/53ME1fGfM

The compiler with the error is the one that is using -flax-vector-conversions
through the C++ frontend.
Unsure if this is something to do with the C++ front-end or something in the
target backend (and how the builtins are registered with the front-end).

This seems to happen regardless of if the vaddq intrinsic has been
"restructured" by Christophe's
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615997.html (so going back
to older GCC12,13 still gives the error), but another intrinsic, like vbicq,
doesn't give the error at all (although that has a different context of the
`int` immediate having to be a compile-time constant).
(clang handles all this fine FWIW)

Has anyone seen this kind of thing before, have any ideas on workarounds, or
have any insight on if this this invalid C++ to begin with?

[Bug target/110255] arm: MVE intrinsics C++ polymorphism with -flax-vector-conversions

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

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

--- Comment #1 from Andrew Pinski  ---
My suggestion is yes it is ambigious because of -flax-vector-conversions . and
really don't use -flax-vector-conversions unless you can't fix the original
code.

[Bug target/110255] arm: MVE intrinsics C++ polymorphism with -flax-vector-conversions

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
See bug 88698 comment #3 about -flax-vector-conversions history and even some
history on clang.

[Bug target/110255] arm: MVE intrinsics C++ polymorphism with -flax-vector-conversions

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

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

Stam Markianos-Wright  changed:

   What|Removed |Added

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

--- Comment #3 from Stam Markianos-Wright  ---
Aha! Thanks, Andrew, that makes sense. I'll go back to the original authors for
this and check if there's any good reason why they are using
-flax-vector-conversions and if they can just change their code :)

Also woops, the godbolt link I gave above was in the middle of me messing
around with casts. Here is a clean one: https://godbolt.org/z/c9vaas6P8 . And
indeed, casting to the "correct" scalar type for the intrinsic (in this case
uint16_t), does indeed make this work

However, this is sounding like this bugzilla should also go to RESOLVED
INVALID. Sorry for the false alarm!

[Bug c++/110256] New: passing concept to concept compiles

[ldalessandro at gmail dot com via Gcc-bugs]

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

Bug ID: 110256
   Summary: passing concept to concept compiles
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

I accidentally passed a concept to convertible_to and was surprised to see it
compile.

```
#include 

template 
concept b = requires (T t ) {
{ auto(t) } -> std::convertible_to;
};

static_assert(b);
```

https://godbolt.org/z/jh53n185s

[Bug c++/110256] passing concept to concept compiles

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

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

--- Comment #1 from Andrew Pinski  ---
Reduced to:
```
template
concept c = true;
template
concept  d = false;

template 
concept b = requires (T t ) {
{ t } -> d;
};

static_assert(!b);
```

[Bug c++/110256] passing concept to concept compiles

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

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

--- Comment #2 from Andrew Pinski  ---
MSVC also accepts this code ...
It might be the case that clang is incorrectly rejecting it.
Basically the way I understand is that b will always be false due to incorrect
usage of std::integral/c here. templates can be used as a template argument
even.

[Bug driver/45749] Response file unwrapped between collect2.exe and ld.exe

[costas.argyris at gmail dot com via Gcc-bugs]

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

Costas Argyris  changed:

   What|Removed |Added

 CC||costas.argyris at gmail dot com

--- Comment #16 from Costas Argyris  ---
Very likely fixed by

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=180ebb8a24d24fc5b105f2257d6216f6dfde62df

[Bug driver/86030] specs file processing does not create response files for input directories

[costas.argyris at gmail dot com via Gcc-bugs]

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

Costas Argyris  changed:

   What|Removed |Added

 CC||costas.argyris at gmail dot com

--- Comment #5 from Costas Argyris  ---
Very likely fixed by

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=180ebb8a24d24fc5b105f2257d6216f6dfde62df

[Bug driver/71850] @file should be used to cc1/cc1plus when @file is used

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Segher Boessenkool  ---
Costas says this is fixed by g:180ebb8a24d2 .  Marking as such.  Thanks :-)

[Bug c++/110257] New: [13 Regression] Excessive compile time and memory consumption

[manuel.bergler at mvtec dot com via Gcc-bugs]

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

Bug ID: 110257
   Summary: [13 Regression] Excessive compile time and memory
consumption
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manuel.bergler at mvtec dot com
  Target Milestone: ---

Compiling the attached file with GCC 13.1 consumes ~95GB of RAM and takes 23
minutes to compile, compared to GCC 12.1 which required only ~250KB of RAM and
only takes 1.8s.

File was compiled with command

g++ -O3 -g -std=c++20 -c a-exploding_compilation_time.ii

There are no warnings or other output when compiling this file, it just takes
forever.

gcc -v reports:

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

[Bug c++/110257] [13 Regression] Excessive compile time and memory consumption

[manuel.bergler at mvtec dot com via Gcc-bugs]

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

--- Comment #1 from Manuel Bergler  ---
Created attachment 55322
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55322&action=edit
Source file that reproduces the problem; I couldn't attach the pre-processed
file because it exceeds the file size limit

[Bug c++/110257] [13 Regression] Excessive compile time and memory consumption

[manuel.bergler at mvtec dot com via Gcc-bugs]

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

Manuel Bergler  changed:

   What|Removed |Added

  Attachment #55322|Source file that reproduces |Source file that reproduces
description|the problem; I couldn't |the problem
   |attach the pre-processed|
   |file because it exceeds the |
   |file size limit |

--- Comment #2 from Manuel Bergler  ---
Comment on attachment 55322
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55322
Source file that reproduces the problem

I couldn't attach the pre-processed file because it exceeds the file size limit

[Bug rtl-optimization/110254] improve_allocation() routine does not update allocated_hardreg_p[] array

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

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

--- Comment #1 from Segher Boessenkool  ---
Off topic / pet peeve: it's not an array of functions, so it should not be
called
something_p .

[Bug c++/110257] [13 Regression] Excessive compilation time and memory consumption

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work|12.1.0  |12.3.0

--- Comment #3 from Andrew Pinski  ---
Works fast on the trunk:
[apinski@xeond2 upstream-gcc-git]$ ~/upstream-gcc/bin/gcc -S -g t5.cc
-std=c++20 -O3 -ftime-report

Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 1770k (  1%)
 phase parsing  :   1.06 ( 39%)   0.47 ( 57%)   1.53 ( 43%)
   63M ( 37%)
 phase lang. deferred   :   1.62 ( 59%)   0.35 ( 42%)   1.98 ( 55%)
   97M ( 58%)
 phase opt and generate :   0.04 (  1%)   0.01 (  1%)   0.04 (  1%)
 6431k (  4%)
 phase last asm :   0.01 (  0%)   0.00 (  0%)   0.02 (  1%)
  377k (  0%)
 phase finalize :   0.00 (  0%)   0.00 (  0%)   0.02 (  1%)
0  (  0%)
 |name lookup   :   0.26 ( 10%)   0.10 ( 12%)   0.47 ( 13%)
 3816k (  2%)
 |overload resolution   :   0.90 ( 33%)   0.22 ( 27%)   1.26 ( 35%)
   61M ( 36%)
 garbage collection :   0.46 ( 17%)   0.00 (  0%)   0.46 ( 13%)
0  (  0%)
 callgraph construction :   0.04 (  1%)   0.01 (  1%)   0.04 (  1%)
 6428k (  4%)
 preprocessing  :   0.14 (  5%)   0.09 ( 11%)   0.22 (  6%)
 1619k (  1%)
 parser (global):   0.17 (  6%)   0.17 ( 20%)   0.29 (  8%)
   16M ( 10%)
 parser struct body :   0.15 (  5%)   0.00 (  0%)   0.17 (  5%)
   10M (  6%)
 parser function body   :   0.00 (  0%)   0.01 (  1%)   0.00 (  0%)
  221k (  0%)
 parser inl. func. body :   0.04 (  1%)   0.02 (  2%)   0.10 (  3%)
 3111k (  2%)
 parser inl. meth. body :   0.10 (  4%)   0.05 (  6%)   0.16 (  4%)
 6386k (  4%)
 template instantiation :   1.41 ( 52%)   0.44 ( 53%)   1.84 ( 51%)
   95M ( 57%)
 constant expression evaluation :   0.06 (  2%)   0.01 (  1%)   0.12 (  3%)
 1000k (  1%)
 constraint normalization   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
  153k (  0%)
 constraint satisfaction:   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
  414k (  0%)
 varconst   :   0.03 (  1%)   0.00 (  0%)   0.01 (  0%)
0  (  0%)
 symout :   0.12 (  4%)   0.03 (  4%)   0.14 (  4%)
   25M ( 15%)
 TOTAL  :   2.73  0.83  3.60   
  169M
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.

[Bug c++/110258] New: Undefined reference to intrinsic when taking function reference at namespace scope

[magnus.hegdahl at gmail dot com via Gcc-bugs]

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

Bug ID: 110258
   Summary: Undefined reference to intrinsic when taking function
reference at namespace scope
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: magnus.hegdahl at gmail dot com
  Target Milestone: ---

Tested on g++ (GCC) 13.1.1 20230429 on Linux

```
#include 

// this doesn't work in GCC (but does in clang)
constexpr auto set1 = _mm_set1_epi32;

// this works
struct S {
  static constexpr auto set1 = _mm_set1_epi32;
};

int main() {
  // and this works
  _mm_set1_epi32(1);
}
```

output:
/usr/bin/ld: /tmp/ccaN0gLC.o:(.data.rel.ro+0x0): undefined reference to
`_mm_set1_epi32(int)'
collect2: error: ld returned 1 exit status

The code seems to work as expected with other function pointers,
even when defined in other translation units.
I've only seen the problem with intrinsics.

[Bug target/110258] Undefined reference to intrinsic when taking function reference at namespace scope

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is by design.

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

[Bug target/100005] undefined reference to `_rdrand64_step'

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||magnus.hegdahl at gmail dot com

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

[Bug c/110259] New: Wrong warning 'conversion to unsigned int' with enum and comma

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 110259
   Summary: Wrong warning 'conversion to unsigned int' with enum
and comma
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

~~~c
enum e {
e1,
e2,
};

int side_effect(void);

enum e demo(_Bool, enum e);

enum e
demo(_Bool cond, enum e c1)
{
enum e var = cond
 ?
 c1
 :
 (
 side_effect(),
 e2
 );
return var;
}
~~~

gcc-12.2.0 gcc -O2 -Wconversion -c indent.c
indent.c: In function ‘demo’:
indent.c:16:22: warning: conversion to ‘unsigned int’ from ‘int’ may change the
sign of the result [-Wsign-conversion]
   16 |  :
  |  ^


Same result for -ansi, -std=c99, -std=c2x, as well as for GCC 10.4.0.

Removing the 'side_effect(),' makes the warning disappear.

The comma operator has the type of its right operand, therefore I don't see
where the 'unsigned' might come from.

[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 55323
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55323&action=edit
Patch which fixes this issue

This patch fixes the issue by temporary removing the flow sensitive information
on the statement that will be moved while trying out match-and-simplify.

We don't want to remove the flow sensitive information always because if we
don't decide to move it in the end, we just lost it.
I am not the best at naming things so the name of the class will most likely
change before I submit the patch. But I wanted to give a preview here.
Note this is a latent bug in phiopt since the match-and-simplify usage was
added really; just only recently has been noticed due to range information
being used more in match.

[Bug c++/110257] [13 Regression] Excessive compilation time and memory consumption

[manuel.bergler at mvtec dot com via Gcc-bugs]

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

--- Comment #4 from Manuel Bergler  ---
I don't know if it helps find the offending commit and/or fix, but these are
the numbers I got from -ftime-report with the broken GCC 13.1:

Time variable   usr   sys  wall
  GGC
 phase setup:   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
 1763k (  0%)
 phase parsing  :   0.83 (  0%)   0.34 (  1%)   1.30 (  0%)
   62M (  0%)
 phase lang. deferred   :1327.73 (100%)  59.04 ( 99%)1386.92 (100%)
88645M (100%)
 phase opt and generate :   0.02 (  0%)   0.02 (  0%)   0.03 (  0%)
 6489k (  0%)
 phase last asm :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
  354k (  0%)
 |name lookup   :   0.30 (  0%)   0.07 (  0%)   0.39 (  0%)
 3750k (  0%)
 |overload resolution   :  36.61 (  3%)   0.94 (  2%)  37.63 (  3%)
   60M (  0%)
 garbage collection :   1.00 (  0%)   0.10 (  0%)   1.10 (  0%)
0  (  0%)
 callgraph construction :   0.02 (  0%)   0.02 (  0%)   0.03 (  0%)
 6486k (  0%)
 preprocessing  :   0.13 (  0%)   0.10 (  0%)   0.32 (  0%)
 1628k (  0%)
 parser (global):   0.14 (  0%)   0.11 (  0%)   0.32 (  0%)
   16M (  0%)
 parser struct body :   0.13 (  0%)   0.03 (  0%)   0.11 (  0%)
   10M (  0%)
 parser function body   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
  216k (  0%)
 parser inl. func. body :   0.05 (  0%)   0.02 (  0%)   0.05 (  0%)
 2629k (  0%)
 parser inl. meth. body :   0.08 (  0%)   0.03 (  0%)   0.15 (  0%)
 7090k (  0%)
 template instantiation :  10.21 (  1%)   0.48 (  1%)  10.79 (  1%)
   95M (  0%)
 constant expression evaluation :1247.10 ( 94%)  57.06 ( 96%)1304.35 ( 94%)
88547M (100%)
 varconst   :   0.02 (  0%)   0.00 (  0%)   0.00 (  0%)
0  (  0%)
 symout :  69.71 (  5%)   1.45 (  2%)  71.03 (  5%)
   26M (  0%)
 TOTAL  :1328.60 59.40   1388.27   
88716M

[Bug c++/110257] [13 Regression] Excessive compilation time and memory consumption

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Manuel Bergler from comment #4)
> I don't know if it helps find the offending commit and/or fix, but these are
> the numbers I got from -ftime-report with the broken GCC 13.1:

Yes it does. PR 109678

[Bug c++/109678] [13/14 Regression] exponential time behavior on std::variant

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||manuel.bergler at mvtec dot com

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

[Bug c++/110257] [13 Regression] Excessive compilation time and memory consumption

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
>gcc version 13.1.1 20230429 (GCC)

This is before the fix for PR 109678 .

So marking this as a dup of bug 109678 .

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

[Bug other/110260] New: Multiple applications misbehave when compiled with -march=znver4

[chiitoo at gentoo dot org via Gcc-bugs]

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

Bug ID: 110260
   Summary: Multiple applications misbehave when compiled with
-march=znver4
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chiitoo at gentoo dot org
  Target Milestone: ---

While hunting for the cause for a stack alignment issue in Wine [1], it started
to look more and more that '-march=znver4' is at least related to the issue.

I had compiled a few hundred other packages mistakingly with certain testing
flags in between building Wine and the mingw-toolchain, and noticed a certain
issue related to KWin disappear [2].

The issue came back the next day, after resting X11, and it took me a while to
realise what had happened.  I saw from my build logs that KWin was one of those
packages that I had compiled with the testing C{XX}FLAGS (-march=x86-64 -O2
-g), and I had then later compiled it again with the usual flags (-march=znver4
-O2 -fomit-frame-pointer -pipe -mindirect-branch=thunk), and so I did some test
builds with -march=x86-64 and -march=znver3 and the problem goes away.

There's at least one more recent issue with my LXQt panel task manager widget,
but I'm not sure yet if this will make that go away as well.

Let me know if I can help pinpoint the issue more, or/and confirm this to be a
GCC issue or not.

Next I'm thinking of trying to see if I can spot one or more of the
instructions do it that is not included with znver3 per the x86-Options
documentation [3].

(By the by, is ADCX a typo of ADX?  I see -madx as an option but only one use
of it otherwise, and no -adcx as an option and lots of mentions of it... but
perhaps I'm not reading them correct-like.)

Thank you!


1. https://bugs.winehq.org/show_bug.cgi?id=55007
2. https://bugs.kde.org/show_bug.cgi?id=469426
3. https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

[Bug target/110260] Multiple applications misbehave when compiled with -march=znver4

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110237,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=109780,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=109093,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=109087,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=109982

--- Comment #1 from Andrew Pinski  ---
Could be multiple things really.
PR 109780, PR 109093, PR 109087 and PR 109982 are related to an aligment issue
with -march=znver* even.

[Bug target/110260] Multiple applications misbehave when compiled with -march=znver4

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #2 from Sam James  ---
The case I've looked at the most is KWin (https://bugs.gentoo.org/895750) where
we narrowed it down to https://bugs.kde.org/show_bug.cgi?id=460572#c28 with:
"""
To emphasise:
- -O2 -march=x86-64-v3 works
- -O2 -march=x86-64-v4 (or -march=rocketlake) triggers it
"""

It may not be the same as Chiitoo's bug here, but it probably is given the
symptoms are the same & both likely involve AVX512.

I couldn't reproduce it on my machine with AVX512 (only one machine, Tiger
Lake) and couldn't really do any more at that point. I guess a good start would
be seeing what the minimal file(s) required to break kwin are w/ -march=znver4.

[Bug middle-end/110261] New: vec.h mentions C++03 requirement for PODs and with respect to unions

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

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

Bug ID: 110261
   Summary: vec.h mentions C++03 requirement for PODs and with
respect to unions
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Since GCC is now written in C++11 (since GCC 11, r11-462-g5329b59a2e13dabbe2),
the comment in vec.h:
   As long as we use C++03, we cannot have constructors nor
   destructors in classes that are stored in unions.  */
No longer applies. 

I have not tested using a non-POD with vec yet but I just wanted to record this
here for future reference and for others when some one finally notices this and
decides to test it.

[Bug c/110259] Wrong warning 'conversion to unsigned int' with enum and comma

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c/53277] -Wconversion cannot handle compound expressions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||roland.illig at gmx dot de

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

[Bug target/110119] RISC-V: RVV --param=riscv-autovec-preference=fixed-vlmax ICE

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:0ec3fbb5903ac3ad735b3154e814b46724fe1a27

commit r14-1829-g0ec3fbb5903ac3ad735b3154e814b46724fe1a27
Author: Lehua Ding 
Date:   Wed Jun 14 19:56:11 2023 +0800

RISC-V: Ensure vector args and return use function stack to pass [PR110119]

The V2 patch address comments from Juzhe, thanks.

Hi,

The reason for this bug is that in the case where the vector register is
set
to a fixed length (with `--param=riscv-autovec-preference=fixed-vlmax`
option),
TARGET_PASS_BY_REFERENCE thinks that variables of type vint32m1 can be
passed
through two scalar registers, but when GCC calls FUNCTION_VALUE (call
function
riscv_get_arg_info inside) it returns NULL_RTX. These two functions are not
unified. The current treatment is to pass all vector arguments and returns
through the function stack, and a new calling convention for vector
registers
will be added in the future.

https://github.com/riscv-non-isa/riscv-elf-psabi-doc/
   
https://github.com/palmer-dabbelt/riscv-elf-psabi-doc/commit/126fa719972ff998a8a239c47d506c7809aea363

Best,
Lehua

gcc/ChangeLog:
PR target/110119
* config/riscv/riscv.cc (riscv_get_arg_info): Return NULL_RTX for
vector mode
(riscv_pass_by_reference): Return true for vector mode

gcc/testsuite/ChangeLog:
PR target/110119
* gcc.target/riscv/rvv/base/pr110119-1.c: New test.
* gcc.target/riscv/rvv/base/pr110119-2.c: New test.

[Bug other/110253] Documentation: possibly incomplete list in the docs of -ftrapv

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

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

--- Comment #1 from Andrew Pinski  ---
ftrapv also does not always work either ...

[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

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

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

--- Comment #3 from Andrew Pinski  ---
smallest testcase:
```
signed char f() __attribute__((__noipa__));
signed char f() { return 0; }
int main()
{
  int g = f() - 1;
  int e = g < 0 ? 1 : ((g >> (8-2))!=0);
  asm("":"+r"(e));
  if (e != 1)
__builtin_abort();
}
```

Note I changed 6 to 8-2 as it better explains what is going on and why 6 is the
one needed here.
Second the 239 is just changed over to -1 as it just needs any subtraction.
third is j is inlined and the != is moved over to the conditional expression.
4th and not least, removed all of the pointers and just changed over to using
inline-asm to hide the range of e at the if statement.

[Bug tree-optimization/110248] ivopts could under-cost for some addressing modes on len_{load,store}

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

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

--- Comment #7 from Kewen Lin  ---
(In reply to Richard Biener from comment #6)
> (In reply to rsand...@gcc.gnu.org from comment #5)
> > ivopts does have code to treat ifn pointer arguments specially,
> > see get_mem_type_for_internal_fn &co.  But like Kewen says,
> > it's still only based on the mode.
> 
> But the dump quoted says 'Type: POINTER ARGUMENT ADDRESS' which means
> that doesn't work as desired.  That is, the use is classified wrongly
> and the above function only seems to be useful to get the mode of
> the memory access done by the internal function?

As Richard mentioned above, currently ivopts special-cases LEN and MASK
load/store IFNs, USE_PTR_ADDRESS is the special use type for address-like use,
currently it only handles the point arguments of these LEN and MASK load/store
IFNs which will become an address when expanding the IFN statement. function
find_address_like_use detects this kind of argument, determine_group_iv_cost
and the others will treat USE_PTR_ADDRESS as the same as USE_REF_ADDRESS,
excepting when rewriting it we will generate it with ADDR_EXPR (LEA). So
costing doesn't distinguish USE_PTR_ADDRESS and USE_REF_ADDRESS. One thing
seems to be improved is that unlike USE_REF_ADDRESS USE_PTR_ADDRESS uses will
need ADDR_EXPR, it can generate something CSE'd, we can consider this during
costing.

> 
> USE_PTR_ADDRESS doesn't seem to be a very good match to capture
> constraints for a memory dereference?
> 
> > Personally I'd prefer an internal_fn rather than a gimple* though.
> > It can be useful to test these things on a possible future statement,
> > not just on one that already exists.
> 
> Well yes, passing down a gimple * looks like too generic here.  Maybe
> use a code_helper so we can pass down MEM_REF for dereference context
> and nothing (ERROR_MARK_NODE?) for plain address use?

Thanks for the suggestions with internal_fn and code_helper! I thought gimple*
can be generic but as the above comments I agree code_helper is better.

[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

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

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

--- Comment #4 from Andrew Pinski  ---
here is another testcase which is reduced from sel-sched.cc which we currently
miscompile:
```
[[gnu::noipa]]
int g(int min_need_stall)
{
  return  min_need_stall < 0 ? 1 : ((min_need_stall) < (1) ? (min_need_stall) :
(1));
}
int main(void)
{
  for(int i = -100; i <= 100; i++)
{
  int t = g(i);
  if (t != (i!=0))
__builtin_abort();
}
}
```

Note g really could be reduced down to (min_need_stall != 0) but we don't do
that currently (nor does clang).

[Bug tree-optimization/110262] New: `t < 0 ? 1 : min(t, 1)` is not simplified down to just `t != 0`

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

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

Bug ID: 110262
   Summary: `t < 0 ? 1 : min(t, 1)` is not simplified down to just
`t != 0`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int g(int min_need_stall)
{
  return  min_need_stall < 0 ? 1 : ((min_need_stall) < (1) ? (min_need_stall) :
(1));
}
```
This should just be the same as `min_need_stall != 0` but currently is not.

Yes this code does shows up in real code, it is from sel-sched.cc:
  min_need_stall = min_need_stall < 0 ? 1 : MIN (min_need_stall, 1);

Note we currently miscompile it but that is due to PR 110252 (which I have a
fix).

[Bug target/110119] RISC-V: RVV --param=riscv-autovec-preference=fixed-vlmax ICE

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

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #2 from JuzheZhong  ---
fix on trunk.

[Bug tree-optimization/110251] [14 Regression] Hang at -O3 on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||compile-time-hog
Summary|Hang at -O3 on  |[14 Regression] Hang at -O3
   |x86_64-linux-gnu|on x86_64-linux-gnu
  Component|c   |tree-optimization
 Ever confirmed|0   |1
   Target Milestone|--- |14.0
   Last reconfirmed||2023-06-15
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
dom3 :
```
#0  0x012add4b in irange::intersect (this=, v=...) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.cc:1523
#1  0x01c93506 in Value_Range::intersect (r=..., this=0x7ffe17a0)
at /home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.h:541
#2  gori_compute::compute_operand2_range (this=0x2f4dcd0, r=..., handler=...,
lhs=..., name=0x779dc000, src=..., rel=) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1267
#3  0x01c946de in gori_compute::compute_operand1_and_operand2_range
(this=0x2f4dcd0, r=..., handler=..., lhs=..., name=0x779dc000, src=...,
rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1296
#4  0x01c9165b in gori_compute::compute_operand_range (this=0x2f4dcd0,
r=..., stmt=0x776015d8, lhs=..., name=0x779dc000, src=..., rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:708
#5  0x01c94028 in gori_compute::compute_operand_range (rel=0x0,
src=..., name=0x779dc000, lhs=..., stmt=, r=...,
this=0x2f4dcd0) at /home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.h:757
#6  gori_compute::compute_operand1_range (this=0x2f4dcd0, r=..., handler=...,
lhs=..., name=0x779dc000, src=..., rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1178
#7  0x01c9159b in gori_compute::compute_operand_range (this=0x2f4dcd0,
r=..., stmt=0x77601688, lhs=..., name=0x779dc000, src=..., rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:711
#8  0x01c94028 in gori_compute::compute_operand_range (rel=0x0,
src=..., name=0x779dc000, lhs=..., stmt=, r=...,
this=0x2f4dcd0) at /home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.h:757
#9  gori_compute::compute_operand1_range (this=0x2f4dcd0, r=..., handler=...,
lhs=..., name=0x779dc000, src=..., rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1178
#10 0x01c94757 in gori_compute::compute_operand1_and_operand2_range
(this=0x2f4dcd0, r=..., handler=..., lhs=..., name=, src=...,
rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1300
#11 0x01c9165b in gori_compute::compute_operand_range (this=0x2f4dcd0,
r=..., stmt=0x776016e0, lhs=..., name=0x779dc000, src=..., rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:708
#12 0x01c94028 in gori_compute::compute_operand_range (rel=0x0,
src=..., name=0x779dc000, lhs=..., stmt=, r=...,
this=0x2f4dcd0) at /home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.h:757
#13 gori_compute::compute_operand1_range (this=0x2f4dcd0, r=..., handler=...,
lhs=..., name=0x779dc000, src=..., rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1178
#14 0x01c9159b in gori_compute::compute_operand_range (this=0x2f4dcd0,
r=..., stmt=0x77601790, lhs=..., name=0x779dc000, src=..., rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:711
#15 0x01c94028 in gori_compute::compute_operand_range (rel=0x0,
src=..., name=0x779dc000, lhs=..., stmt=, r=...,
this=0x2f4dcd0) at /home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.h:757
#16 gori_compute::compute_operand1_range (this=0x2f4dcd0, r=..., handler=...,
lhs=..., name=0x779dc000, src=..., rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1178
#17 0x01c94757 in gori_compute::compute_operand1_and_operand2_range
(this=0x2f4dcd0, r=..., handler=..., lhs=..., name=, src=...,
rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1300
#18 0x01c9165b in gori_compute::compute_operand_range (this=0x2f4dcd0,
r=..., stmt=0x776017e8, lhs=..., name=0x779dc000, src=..., rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:708
#19 0x01c93552 in gori_compute::compute_operand_range (rel=0x0,
src=..., name=0x779dc000, lhs=..., stmt=, r=...,
this=0x2f4dcd0) at /home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.h:757
#20 gori_compute::compute_operand2_range (this=0x2f4dcd0, r=..., handler=...,
lhs=..., name=0x779dc000, src=..., rel=) at
/home/apinski/src/upstream-gcc-git/

[Bug target/110247] suboptimal code about `no_caller_saved_registers` on caller side

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #2 from LIU Hao  ---
(In reply to Andrew Pinski from comment #1)
> The way I read the documentation, it will NOT be used when dealing with

If it is known, then why shouldn't it?

One potential usecase where this would be helpful is `__errno_location()` in
GNU libc., and maybe `__emutls_get_address()`.


> And it is used only for calls from an interrupt handler (e.g. directly from
> assembly). and even more you need to use -mgeneral-regs-only too.

That function will be compiled with `-mgeneral-regs-only`, but callers need
not.

[Bug tree-optimization/110251] [14 Regression] Hang at -O3 on x86_64-linux-gnu

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

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

--- Comment #2 from Andrew Pinski  ---
Looks like it is uninitialized variable related.
Here is one which shows that:
```
int a, b;
char c;
int d(int e) {
  int t = 0;
  if (e >= 'a')
return e;
  return t;
}
int f(unsigned short e) {
  int t2;
  for (; e; a++)
e &= e - 1;
  return t2;
}
void g() {
  for (; c < 1;)
;
  for (; f(c - 1); b = d(c))
;
}
```

If you initialize t2 to either 1 or 0, GCC will not hang.

[Bug tree-optimization/110251] [13/14 Regression] Hang at -O3 on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to fail||13.1.0
Summary|[14 Regression] Hang at -O3 |[13/14 Regression] Hang at
   |on x86_64-linux-gnu |-O3 on x86_64-linux-gnu
  Known to work||12.3.0
   Target Milestone|14.0|13.2

[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.

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

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

--- Comment #9 from Andrew Pinski  ---
That is these exports:
2->3  (T) c.5_7 :   [irange] int [1334323000, +INF] NONZERO 0x7fff
2->3  (T) _8 :  [irange] long unsigned int [1334323000, 2147483647] NONZERO
0x7fff
2->3  (T) b.6_9 :   [irange] int [1334323000, +INF] NONZERO 0x7fff
2->3  (T) _10 : [irange] long unsigned int [1334323000, 2147483647]
NONZERO 0x7fff
2->3  (T) _11 : [irange] long unsigned int [3481806647, 3481806649]
NONZERO 0xcf88273f
2->3  (T) _12 : [irange] long unsigned int [0, 2] NONZERO 0x3

seems wrong.
We originally had:
c.5_7 = c;
_8 = (long unsigned int) c.5_7;
b.6_9 = b;
_10 = (long unsigned int) b.6_9;
_11 = _8 + _10;
_12 = _11 + 18446744070227744969;
if (_12 <= 2)

so _11 export seems correct but _8 and _10 added together needs to be make _11.
Since it is unsigned, the whole range for both numbers can make _11's range;
that is we can't say anything about _8 or _10. Even if _11 is signed, I don't
see how _8 and _10 could be described at all ... since _8 could be 0 and _10
could be 3481806647 and the range that is exported for _8 does not even include
0.

Unless I am missing something obvious here.

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Aldy Hernandez from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > VRP2/DOM3 produces the wrong folding for some reason:
> > Folding statement: _27 = b.6_9 * 2;
> > Queued stmt for removal.  Folds to: 2147483647
> > 
> > I don't uinderstand how it could get that from:
> 
> Putting a breakpoint in execute_ranger_vrp() for the VRP2 instance, and
> dumping what the ranger knows with debug_ranger() we see:
> 
> === BB 3 
> b.6_9 [irange] int [1334323000, +INF] NONZERO 0x7fff
>  [local count: 357878153]:
> _28 = b.6_9 * 2;
> ivtmp.19_27 = 2147483647;
> ivtmp.22_31 = (unsigned long) &f;
> goto ; [100.00%]
> 
> ivtmp.19_27 : [irange] unsigned int [2147483647, 2147483647] NONZERO
> 0x7fff
> _28 : [irange] int [+INF, +INF] NONZERO 0x7ffe
> ivtmp.22_31 : [irange] unsigned long [1, +INF]
> 
> So on entry to BB3, b.6_9 is [1334323000, +INF].  This comes from the 2->3
> edge, which is the only incoming edge to BB3.
> 
> Isn't multiplying any number in that range an overflow, and thus undefined?

ok, that part makes sense but how did that b.6_9 get that range in the first
place? Because it does not even makes sense.

That is these exports:
2->3  (T) c.5_7 :   [irange] int [1334323000, +INF] NONZERO 0x7fff
2->3  (T) _8 :  [irange] long unsigned int [1334323000, 2147483647] NONZERO
0x7fff
2->3  (T) b.6_9 :   [irange] int [1334323000, +INF] NONZERO 0x7fff
2->3  (T) _10 : [irange] long unsigned int [1334323000, 2147483647]
NONZERO 0x7fff
2->3  (T) _11 : [irange] long unsigned int [3481806647, 3481806649]
NONZERO 0xcf88273f
2->3  (T) _12 : [irange] long unsigned int [0, 2] NONZERO 0x3

seems wrong.
We originally had (c and d cause a memory read):
c.5_7 = c;
_8 = (long unsigned int) c.5_7;
b.6_9 = b;
_10 = (long unsigned int) b.6_9;
_11 = _8 + _10;
_12 = _11 + 18446744070227744969;
if (_12 <= 2)

so _11 export seems correct but _8 and _10 added together needs to be make _11.
Since it is unsigned, the whole range for both numbers can make _11's range;
that is we can't say anything about _8 or _10. Even if _11 is signed, I don't
see how _8 and _10 could be described at all ... since _8 could be 0 and _10
could be 3481806647 and the range that is exported for _8 does not even include
0.

Unless I am missing something obvious here.

[Bug middle-end/110200] genmatch generating questionable code with convert and !

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||11.4.1, 12.3.1, 13.1.1
  Known to fail||11.4.0, 12.3.0, 13.1.0
   Target Milestone|--- |11.5

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||5.3.0, 5.5.0
  Known to fail||5.2.0
   Keywords|needs-bisection |

--- Comment #6 from Andrew Pinski  ---
Oh never mind, the problem is IV-OPTS introducing the overflow.
before IVOPTs we have:
  _1 = b.6_9 + -1691021644;
  _2 = _1 + b.6_9;
  _3 = _2 + -1691021636;
  _4 = _3 + g_13;
Which does not have any overflow ...

But afterwards we have one:
  _28 = b.6_9 * 2;
...

that was broken even in GCC 4.7 and most likely earlier.
I had missed that.

[Bug middle-end/110233] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu

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

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

--- Comment #7 from Andrew Pinski  ---
So what I am suspecting is ranger/VRP information was improved which exposed
the latent bug in IVOPTs.

[Bug tree-optimization/110251] [13/14 Regression] Hang at -O3 on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

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

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

--- Comment #5 from Richard Biener  ---
You can probably follow what maybe_fold_comparisons_from_match_pd does,
possibly exactly the same thing (or even use a similar helper extended to
maybe_fold_cond_expr_from_match_pd?!)

[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug other/110253] Documentation: possibly incomplete list in the docs of -ftrapv

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
There's at least a negv optab, there's also [us]divv but that optab isn't
documented.  There's also absv.  There isn't a divv libgcc function.

[Bug target/110260] Multiple applications misbehave when compiled with -march=znver4

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

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

--- Comment #3 from Richard Biener  ---
Can you try if -fno-schedule-insns helps in (all?) cases?

[Bug tree-optimization/109156] Support Absolute Difference detection in GCC

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

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

--- Comment #5 from CVS Commits  ---
The trunk branch has been updated by Richard Sandiford :

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

commit r14-1833-gea616f687dccbe42012f786c0ebade5b05850206
Author: Oluwatamilore Adebayo 
Date:   Thu Jun 15 07:36:48 2023 +0100

AArch64: New RTL for ABD

This patch adds new RTL and tests for sabd and uabd

PR tree-optimization/109156

gcc/ChangeLog:

* config/aarch64/aarch64-simd.md (aarch64_abd):
Rename to abd3.
* config/aarch64/aarch64-sve.md (abd_3): Rename
to abd3.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/abd.h: New file.
* gcc.target/aarch64/abd_2.c: New test.
* gcc.target/aarch64/abd_3.c: New test.
* gcc.target/aarch64/abd_4.c: New test.
* gcc.target/aarch64/abd_none_2.c: New test.
* gcc.target/aarch64/abd_none_3.c: New test.
* gcc.target/aarch64/abd_none_4.c: New test.
* gcc.target/aarch64/abd_run_1.c: New test.
* gcc.target/aarch64/sve/abd_1.c: New test.
* gcc.target/aarch64/sve/abd_none_1.c: New test.
* gcc.target/aarch64/sve/abd_2.c: New test.
* gcc.target/aarch64/sve/abd_none_2.c: New test.