[Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Rich Felker from comment #1)
> There's also a potentially related test case at
> https://godbolt.org/z/jfv1Ge6v4 - I'm not yet clear on whether it's likely
> to have the same root cause.

This might be a different issue I think.

[Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization
Summary|Wrong codegen from TBAA |[10/11/12/13 Regression]
   |when stores to distinct |Wrong codegen from TBAA
   |same-mode types are |when stores to distinct
   |collapsed?  |same-mode types are
   ||collapsed?
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |10.5
   Last reconfirmed||2022-10-01
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
Note this has been to be a regression since tree level PRE is what is causing
the issue and that was added in GCC 4 or 4.1.

[Bug middle-end/107107] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||4.1.2, 4.4.7, 4.5.3

--- Comment #3 from Andrew Pinski  ---
Here is a testcase which has failed since before 4.1.2:
```
static inline void set_longish(int is_long_long, void *p, long x)
{
if (is_long_long)
*(long long*)p = x;
else
*(long*)p = x;
}
static long test(long long *p, int index, int mode)
{
*p = 1;
set_longish(mode, p+index, 2);
return *p;
}
long (*volatile vtest)(long long*, int, int) = test;
#include 
int main(void)
{
long long x;
long result = vtest(, 0, 1);
printf("%lu/%llu\n", result, x);
}
```
The only difference from the original testcase is marking set_longish as static
inline. I suspect what changed between 4.7 and 4.8 for the original testcase is
inlining.

[Bug middle-end/107107] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?

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

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

--- Comment #2 from Andrew Pinski  ---
Confirmed. I don't think it is exactly TBAA which is causing the issue but
rather the way PRE does aliasing walks.

Take:
```
static inline void set_longish(int is_long, void *p, long x)
{
if (is_long)
*(long*)p = x;
else
*(long long*)p = x;
}
static long test(long long *p, int index, int mode)
{
*p = 1;
set_longish(mode, p+index, 2);
return *p;
}
long (*volatile vtest)(long long*, int, int) = test;
#include 
int main(void)
{
long long x;
long result = vtest(, 0, 0);
printf("%lu/%llu\n", result, x);
}
```
Which is only difference by which order the if statement (and mode which is
swapped). This case works.

[Bug demangler/107108] New: Uncontrolled stack recursion in rust-demangler.c

[bjchan9an at foxmail dot com via Gcc-bugs]

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

Bug ID: 107108
   Summary: Uncontrolled stack recursion in rust-demangler.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bjchan9an at foxmail dot com
  Target Milestone: ---

Created attachment 53647
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53647=edit
nm-new poc file

There is an uncontrolled stack recursion vulnerability in
libiberty/rust-demangle.c in binutils-2.38, which allows stack consumption in
demangle_path_maybe_open_generics().

To reproduce this bug, build the binutils-2.38 release, use the poc file in
attachments and run the following commands:

```
nm-new -C ./poc
```


The gdb crash trace is as follows:
```
Program received signal SIGSEGV, Segmentation fault.
0x005f2a2d in demangle_path_maybe_open_generics (rdm=0x7fffe0b8) at
../../libiberty/rust-demangle.c:1087
1087  backref = parse_integer_62 (rdm);
(gdb) bt
#0  0x005f2a2d in demangle_path_maybe_open_generics
(rdm=0x7fffe0b8) at ../../libiberty/rust-demangle.c:1087
#1  0x005f2a6d in demangle_path_maybe_open_generics
(rdm=0x7fffe0b8) at ../../libiberty/rust-demangle.c:1092
#2  0x005f2a6d in demangle_path_maybe_open_generics
(rdm=0x7fffe0b8) at ../../libiberty/rust-demangle.c:1092
#3  0x005f2a6d in demangle_path_maybe_open_generics
(rdm=0x7fffe0b8) at ../../libiberty/rust-demangle.c:1092
#4  0x005f2a6d in demangle_path_maybe_open_generics
(rdm=0x7fffe0b8) at ../../libiberty/rust-demangle.c:1092
#5  0x005f2a6d in demangle_path_maybe_open_generics
(rdm=0x7fffe0b8) at ../../libiberty/rust-demangle.c:1092
#6  0x005f2a6d in demangle_path_maybe_open_generics
(rdm=0x7fffe0b8) at ../../libiberty/rust-demangle.c:1092
#7  0x005f2a6d in demangle_path_maybe_open_generics
(rdm=0x7fffe0b8) at ../../libiberty/rust-demangle.c:1092
#8  0x005f2a6d in demangle_path_maybe_open_generics
(rdm=0x7fffe0b8) at ../../libiberty/rust-demangle.c:1092
#9  0x005f2a6d in demangle_path_maybe_open_generics
(rdm=0x7fffe0b8) at ../../libiberty/rust-demangle.c:1092
#10 0x005f2a6d in demangle_path_maybe_open_generics
(rdm=0x7fffe0b8) at ../../libiberty/rust-demangle.c:1092
#11 0x005f2a6d in demangle_path_maybe_open_generics
(rdm=0x7fffe0b8) at ../../libiberty/rust-demangle.c:1092
#12 0x005f2a6d in demangle_path_maybe_open_generics
(rdm=0x7fffe0b8) at ../../libiberty/rust-demangle.c:1092
```

[Bug middle-end/107107] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?

[bugdal at aerifal dot cx via Gcc-bugs]

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

--- Comment #1 from Rich Felker  ---
There's also a potentially related test case at https://godbolt.org/z/jfv1Ge6v4
- I'm not yet clear on whether it's likely to have the same root cause.

[Bug analyzer/107106] Incorrect use of uninitialized value warning

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-09-30
 Blocks||97110

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug; confirmed.

Note that the simpler:

std::string square(int num) {
return std::to_string(num);
}

also gives the warning.

Note that I recommend *not* using -fanalyzer on C++ code for now; see tracker
bug 97110.  I'm guessing the issue is due to -fanalyzer failing to cope with
exceptions and exception-handling (bug 97111).  In the meantime, this is a test
case that we'll eventually want to get working, so keeping open.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97110
[Bug 97110] [meta-bug] tracker bug for supporting C++ in -fanalyzer

[Bug c/91669] #pragma's and _Pragma's work but _Pragma's used in an equivalent macro don't

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gcc dot gnu.org

--- Comment #4 from Lewis Hyatt  ---
This is already fixed on the latest GCC 10, 11, and 12 branches and on trunk
for GCC 13.

There were two separate issues contributing to this problem. The first one was
common to both C and C++, and it was fixed by r10-325 for PR90382. (That PR was
primarily about something else so was not focused on _Pragma locations, but the
fix resolved this PR too.)

The second issue made it stay broken longer for C only, not C++. In that sense
it's partially a dupe of PR97498 and this aspect was fixed by r13-1596. (Issue
was that in C, input_location used to be always the start of the line.) That
fix has been backported to 10, 11, and 12 branches already.

The testcase I added in r13-1596 provides partial coverage for this issue as
well, but it does not quite cover the issue with adhoc locations addressed by
r10-325. Here is a reduced testcase for this PR:

===
#define ENDFUNC \
_Pragma("GCC diagnostic push") \
_Pragma("GCC diagnostic ignored \"-Wreturn-type\"") \
 } \
 _Pragma("GCC diagnostic pop")

int f () {
ENDFUNC
===

I will submit a patch to add this testcase and then close this one once that's
applied.

[Bug target/106815] [13 Regression] ICE: in riscv_excess_precision, at config/riscv/riscv.cc:5967 with -fexcess-precision=16 on any input

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

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

--- Comment #2 from CVS Commits  ---
The trunk branch has been updated by Palmer Dabbelt :

https://gcc.gnu.org/g:75c0899493cd84e64bd30210e848d0d1e9979494

commit r13-3000-g75c0899493cd84e64bd30210e848d0d1e9979494
Author: Palmer Dabbelt 
Date:   Fri Sep 9 02:43:26 2022 -0700

RISC-V: Support -fexcess-precision=16

This fixes f19a327077e ("Support -fexcess-precision=16 which will enable
FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 when backend supports _Float16.") on
RISC-V targets.

gcc/ChangeLog

PR target/106815
* config/riscv/riscv.cc (riscv_excess_precision): Add support
for EXCESS_PRECISION_TYPE_FLOAT16.

[Bug middle-end/107107] New: Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?

[bugdal at aerifal dot cx via Gcc-bugs]

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

Bug ID: 107107
   Summary: Wrong codegen from TBAA when stores to distinct
same-mode types are collapsed?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

Created attachment 53646
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53646=edit
original test case by supercat

The attached test case is from user supercat on Stack Overflow (original
source:
https://stackoverflow.com/questions/42178179/will-casting-around-sockaddr-storage-and-sockaddr-in-break-strict-aliasing/42178347?noredirect=1#comment130509588_42178347,
https://godbolt.org/z/83v4ssrn4) and demonstrates wrong TBAA apparently
assuming an object of type long long was not modified after the code path
modifying it was collapsed with a different code path performing the
modification via an lvalue of type long.

On 64-bit targets, the test program outputs 1/2 with optimization levels that
enable -fstrict-aliasing. The expected output is 2/2. Using
-fno-strict-aliasing fixes it.

I have not checked this myself, but according to others who have looked at the
test case, the regression came between GCC 4.7 and 4.8.

[Bug fortran/102312] [10/11 Regression] ICE in gfc_get_dtype_rank_type, at fortran/trans-types.c:1558 since r9-5424-g92f3a180aaf6f3cd

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||anlauf at gcc dot gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
Both testcases work for me on current mainline.
Do we know what fixed it?

[Bug fortran/102334] [12/13 Regression] ICE in trans_associate_var, at fortran/trans-stmt.c:1794 since r12-1482-g1de31913d20a467b

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
 Status|NEW |WAITING

--- Comment #4 from anlauf at gcc dot gnu.org ---
Both testcases in comment#0 work for me with current mainline.
Do we know what fixed it?

[Bug fortran/83700] [Meta-bug] Fortran Coarray issues

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

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

Bug 82868 Summary: ICE in generate_coarray_sym_init, at 
fortran/trans-decl.c:5203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82868

   What|Removed |Added

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

[Bug fortran/82868] ICE in generate_coarray_sym_init, at fortran/trans-decl.c:5203

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |10.5
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug fortran/107054] [10/11/12/13 Regression] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8461

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed on all affected branches.  Closing.

Thanks for the report!

[Bug fortran/107054] [10/11/12/13 Regression] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8461

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-11013-gb2bd7622721c3a35a9884135e719ae6b0fdc3e2d
Author: Harald Anlauf 
Date:   Tue Sep 27 20:54:28 2022 +0200

Fortran: error recovery while simplifying intrinsic UNPACK [PR107054]

gcc/fortran/ChangeLog:

PR fortran/107054
* simplify.c (gfc_simplify_unpack): Replace assert by condition
that terminates simplification when there are not enough elements
in the constructor of argument VECTOR.

gcc/testsuite/ChangeLog:

PR fortran/107054
* gfortran.dg/pr107054.f90: New test.

(cherry picked from commit 78bc6497fc61bbdacfb416ee0246a775360d9af6)

[Bug fortran/82868] ICE in generate_coarray_sym_init, at fortran/trans-decl.c:5203

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-11012-gf2509f6195869fd01aec02714af2d0c3346fa917
Author: Harald Anlauf 
Date:   Wed Sep 21 19:55:30 2022 +0200

Fortran: fix ICE in generate_coarray_sym_init [PR82868]

gcc/fortran/ChangeLog:

PR fortran/82868
* trans-decl.c (generate_coarray_sym_init): Skip symbol
if attr.associate_var.

gcc/testsuite/ChangeLog:

PR fortran/82868
* gfortran.dg/associate_26a.f90: New test.

(cherry picked from commit bc71318a91286b5f00e88f07aab818ac82510692)

[Bug fortran/106985] ICE in gfc_simplify_expr, at fortran/expr.cc:2290

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:12cd4a7c465b1a0874f5bc4419bd19d8041a8e2a

commit r10-11011-g12cd4a7c465b1a0874f5bc4419bd19d8041a8e2a
Author: Harald Anlauf 
Date:   Tue Sep 20 22:23:43 2022 +0200

Fortran: NULL pointer dereference in invalid simplification [PR106985]

gcc/fortran/ChangeLog:

PR fortran/106985
* expr.c (gfc_simplify_expr): Avoid NULL pointer dereference.

gcc/testsuite/ChangeLog:

PR fortran/106985
* gfortran.dg/pr106985.f90: New test.

(cherry picked from commit 8dbb15bc2d019488240c1e69d93121b0347ac092)

[Bug fortran/107054] [10/11/12/13 Regression] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8461

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

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

commit r11-10284-gc4f53f59aaa208f6c7aff0a8b4fb1950b1dc75a0
Author: Harald Anlauf 
Date:   Tue Sep 27 20:54:28 2022 +0200

Fortran: error recovery while simplifying intrinsic UNPACK [PR107054]

gcc/fortran/ChangeLog:

PR fortran/107054
* simplify.c (gfc_simplify_unpack): Replace assert by condition
that terminates simplification when there are not enough elements
in the constructor of argument VECTOR.

gcc/testsuite/ChangeLog:

PR fortran/107054
* gfortran.dg/pr107054.f90: New test.

(cherry picked from commit 78bc6497fc61bbdacfb416ee0246a775360d9af6)

[Bug fortran/103694] [12/13 Regression] ICE in gfc_conv_expr_op, at fortran/trans-expr.c:3882 since r12-3993-gb19bbfb148250536

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-11010-gc59d1e73a617277fea13e785bb0e3f8c1df6ffc4
Author: Harald Anlauf 
Date:   Tue Aug 23 22:16:14 2022 +0200

Fortran: improve error recovery while simplifying size of bad array
[PR103694]

gcc/fortran/ChangeLog:

PR fortran/103694
* simplify.c (simplify_size): The size expression of an array
cannot
be simplified if an error occurs while resolving the array spec.

gcc/testsuite/ChangeLog:

PR fortran/103694
* gfortran.dg/pr103694.f90: New test.

(cherry picked from commit 55d8c5409325001c89c35c3d04d425dec9127146)

[Bug fortran/82868] ICE in generate_coarray_sym_init, at fortran/trans-decl.c:5203

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

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

commit r11-10283-g8a24700c64cabd99802a77ab13080d6f66ee0be7
Author: Harald Anlauf 
Date:   Wed Sep 21 19:55:30 2022 +0200

Fortran: fix ICE in generate_coarray_sym_init [PR82868]

gcc/fortran/ChangeLog:

PR fortran/82868
* trans-decl.c (generate_coarray_sym_init): Skip symbol
if attr.associate_var.

gcc/testsuite/ChangeLog:

PR fortran/82868
* gfortran.dg/associate_26a.f90: New test.

(cherry picked from commit bc71318a91286b5f00e88f07aab818ac82510692)

[Bug fortran/106985] ICE in gfc_simplify_expr, at fortran/expr.cc:2290

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

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

commit r11-10282-g0a4fff071ff48d699b1af94b88f8878da006c770
Author: Harald Anlauf 
Date:   Tue Sep 20 22:23:43 2022 +0200

Fortran: NULL pointer dereference in invalid simplification [PR106985]

gcc/fortran/ChangeLog:

PR fortran/106985
* expr.c (gfc_simplify_expr): Avoid NULL pointer dereference.

gcc/testsuite/ChangeLog:

PR fortran/106985
* gfortran.dg/pr106985.f90: New test.

(cherry picked from commit 8dbb15bc2d019488240c1e69d93121b0347ac092)

[Bug fortran/103694] [12/13 Regression] ICE in gfc_conv_expr_op, at fortran/trans-expr.c:3882 since r12-3993-gb19bbfb148250536

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

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

commit r11-10281-g6a552015b9c4b2e029a47f44f1866578e3af5bd0
Author: Harald Anlauf 
Date:   Tue Aug 23 22:16:14 2022 +0200

Fortran: improve error recovery while simplifying size of bad array
[PR103694]

gcc/fortran/ChangeLog:

PR fortran/103694
* simplify.c (simplify_size): The size expression of an array
cannot
be simplified if an error occurs while resolving the array spec.

gcc/testsuite/ChangeLog:

PR fortran/103694
* gfortran.dg/pr103694.f90: New test.

(cherry picked from commit 55d8c5409325001c89c35c3d04d425dec9127146)

[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #15 from Steve Kargl  ---
On Fri, Sep 30, 2022 at 07:46:24PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
> 
> --- Comment #14 from anlauf at gcc dot gnu.org ---
> (In reply to Mikael Morin from comment #13)
> > If we pass this check, we proceed to reduce_binary, where if one (or both)
> > of the operands is an array, we do numerical evaluation for every element of
> > the array.
> > 
> > With the guarding check above, it is safe, with the assumption that elements
> > of an array have the same type as the array itself.  If that condition is
> > not true, well, it doesn't work obviously.
> > 
> > I don't see right now where an additional check would fit well, but the fix
> > doesn't belong to walk_array_constructor in any case from my point of view.
> 
> We could walk through the elements of each array passed to reduce_binary
> and check the types of the elements there, or do this check in a somewhat
> more clever way than in the patch attached to comment#3.
> 
> This patch tried to perform checks in reduce_binary_ac, but I was not happy
> with that particular implementation.
> 
> When looping over the elements, we currently have
> 
>   gfc_simplify_expr (c->expr, 0);
> 
>   if (c->expr->expr_type == EXPR_CONSTANT)
> rc = eval (c->expr, op2, );
>   else
> rc = reduce_binary_ac (eval, c->expr, op2, );
> 
> and do not handle the case that c->expr->ts.type == BT_UNKNOWN.
> Should we return sth. like rc = ARITH_INCOMMENSURATE, except that it is
> not array .op. array?
> 

walk_array_constructor was introduced when I added the typespec
to an array constructor, ie., [typespec :: xxx].  It was meant
to walk the constructor to do conversions if it could.   If
conversion could not be done, it was left for resolution stage.
It did not occur to me that someone might not write conforming
Fortran.  The purposed change to walk_array_constructor can
catch the simple cases.  Unfortuantely, if EXPR_OP leads to 
INTRINSIC_PARENTHESIS, there appears to be no way to easily
determine the type.  Harald's example of +(-(.true.)) is a
good example of the problem.

[Bug c++/107080] ICE in verify_symtab_nodes using _Float64x with long double

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:61786edf7a82ffb4979207b43a8204ebc2a7671d

commit r13-2995-g61786edf7a82ffb4979207b43a8204ebc2a7671d
Author: Jakub Jelinek 
Date:   Fri Sep 30 21:54:08 2022 +0200

arm, csky: Fix C++ ICEs with _Float16 and __fp16 [PR107080]

On Fri, Sep 30, 2022 at 09:54:49AM -0400, Jason Merrill wrote:
> > Note, there is one further problem on aarch64/arm, types with HFmode
> > (_Float16 and __fp16) are there mangled as Dh (which is standard
> > Itanium mangling:
> >   ::= Dh # IEEE 754r half-precision floating point (16
bits)
> >   ::= DF  _ # ISO/IEC TS 18661 binary floating
point type _FloatN (N bits)
> > so in theory is also ok, but DF16_ is more specific.  Should we just
> > change Dh to DF16_ in those backends, or should __fp16 there be
distinct
> > type from _Float16 where __fp16 would mangle Dh and _Float16 DF16_ ?
>
> You argued for keeping __float128 separate from _Float128, does the same
> argument not apply to this case?

Actually, they already were distinct types that just mangled the same.
So the same issue that had to be solved on i?86, ia64 and rs6000 for
_Float64x vs. long double is a problem on arm and aarch64 with _Float16
vs. __fp16.
The following patch fixes it for arm after aarch64 has been changed
already before.

> > And there is csky, which mangles __fp16 (but only if type's name is
__fp16,
> > not _Float16) as __fp16, that looks clearly invalid to me as it isn't
> > valid in the mangling grammar.  So perhaps just nuke csky's mangle_type
> > and have it mangled as DF16_ by the generic code?

And seems even on csky __fp16 is distinct type from _Float16 (which is a
good thing for consistency, these 3 targets are the only ones that have
__fp16 type), so instead the patch handles it the same as on arm/aarch64,
Dh mangling for __fp16 and DF16_ for _Float16.

2022-09-30  Jakub Jelinek  

PR c++/107080
* config/arm/arm.cc (arm_mangle_type): Mangle just __fp16 as Dh
and _Float16 as DF16_.
* config/csky/csky.cc (csky_init_builtins): Fix a comment typo.
(csky_mangle_type): Mangle __fp16 as Dh and _Float16 as DF16_
rather than mangling __fp16 as __fp16.

* g++.target/arm/pr107080.C: New test.

[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243

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

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

--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #13)
> If we pass this check, we proceed to reduce_binary, where if one (or both)
> of the operands is an array, we do numerical evaluation for every element of
> the array.
> 
> With the guarding check above, it is safe, with the assumption that elements
> of an array have the same type as the array itself.  If that condition is
> not true, well, it doesn't work obviously.
> 
> I don't see right now where an additional check would fit well, but the fix
> doesn't belong to walk_array_constructor in any case from my point of view.

We could walk through the elements of each array passed to reduce_binary
and check the types of the elements there, or do this check in a somewhat
more clever way than in the patch attached to comment#3.

This patch tried to perform checks in reduce_binary_ac, but I was not happy
with that particular implementation.

When looping over the elements, we currently have

  gfc_simplify_expr (c->expr, 0);

  if (c->expr->expr_type == EXPR_CONSTANT)
rc = eval (c->expr, op2, );
  else
rc = reduce_binary_ac (eval, c->expr, op2, );

and do not handle the case that c->expr->ts.type == BT_UNKNOWN.
Should we return sth. like rc = ARITH_INCOMMENSURATE, except that it is
not array .op. array?

[Bug c++/107105] Consider folding `__and_`, `__or_`, and `__not_` at the front-end level

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2022-09-30
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
You didn't set the Version field, so I don't know what GCC version your results
are from. I assume you're not using GCC trunk and don't have this patch:

commit g:390f94eee1ae694901f896ac45bfb148f8126baa
Author: Patrick Palka
Date:   Fri Aug 26 20:10:57 2022

libstdc++: Optimize std::con/disjunction, __and_/__or_, etc

[Bug c++/107106] New: Incorrect use of uninitialized value warning

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 107106
   Summary: Incorrect use of uninitialized value warning
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlame646 at gmail dot com
  Target Milestone: ---

The following program with `-fanalyzer` flag produces incorrect warning. Demo:
https://godbolt.org/z/YWd4cKbGc


```

#include 

std::string square(int num) {
return std::to_string(num * num);
}

```

The warning says:

```
: In function 'std::string square(int)':
:4:36: warning: use of uninitialized value '' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
4 | return std::to_string(num * num);
  |^
  'std::string square(int)': events 1-2
|
|3 | std::string square(int num) {
|  |   ^
|  |   |
|  |   (1) region created on stack here
|4 | return std::to_string(num * num);
|  |~
|  ||
|  |(2) use of uninitialized value
'' here
|
:4:36: warning: use of uninitialized value '' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
4 | return std::to_string(num * num);
  |^
  'std::string square(int)': events 1-2
|
|3 | std::string square(int num) {
|  |   ^
|  |   |
|  |   (1) region created on stack here
|4 | return std::to_string(num * num);
|  |~
|  ||
|  |(2) use of uninitialized value
'' here
|
```

On searching for possible dupes, i came across this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13025 that may be related to this
bug.

[Bug c++/107105] New: Consider folding `__and_`, `__or_`, and `__not_` at the front-end level

[vittorio.romeo at outlook dot com via Gcc-bugs]

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

Bug ID: 107105
   Summary: Consider folding `__and_`, `__or_`, and `__not_` at
the front-end level
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vittorio.romeo at outlook dot com
  Target Milestone: ---

This is another possible compilation speed improvement that came to mind after
running ClangBuildAnalyzer on a few open source projects (gzdoom, SFML, some of
my own, ...) and noticing results like these:

 Template sets that took longest to instantiate:
35407 ms: std::__and_<$> (20262 times, avg 1 ms)
17745 ms: std::unique_ptr<$> (916 times, avg 19 ms)
14302 ms: std::__uniq_ptr_data<$> (916 times, avg 15 ms)
14153 ms: std::__uniq_ptr_impl<$> (916 times, avg 15 ms)
13537 ms: std::__or_<$> (15100 times, avg 0 ms)
13046 ms: std::basic_string<$> (2248 times, avg 5 ms)
11706 ms: std::_Hashtable<$> (1051 times, avg 11 ms)
10527 ms: std::unordered_map<$> (545 times, avg 19 ms)
10379 ms: std::is_convertible<$> (11737 times, avg 0 ms)

It looks like `__and_`, `__or_`, and `__not_` are widely used throughout
libstdc++'s implementation, and are used to implement most type traits. 

I was wondering whether it would be possible and somewhat easy to fold these in
the front-end, similarly to what has been done for `std::move` and similar
functions. Another option is to use a compiler intrinsic.

I have not done any research, but I suppose that if this is possible, reducing
the number of instantiations of these small helpers would benefit pretty much
every project using libstdc++. Just an idea -- feel free to close this ticket
if this is not possible or not worth the effort.

[Bug preprocessor/69543] [10/11/12/13 Regression] _Pragma does not apply within macro

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

[Bug preprocessor/69543] [10/11/12/13 Regression] _Pragma does not apply within macro

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

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

--- Comment #21 from CVS Commits  ---
The master branch has been updated by Lewis Hyatt :

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

commit r13-2994-gb52b99b62df8fc9b3a3010cb0a8cf49bc35037f0
Author: Lewis Hyatt 
Date:   Fri Sep 30 14:10:00 2022 -0400

diagnostics: Fix virtual location for -Wuninitialized [PR69543]

Warnings issued for -Wuninitialized have been using the spelling location
of
the problematic usage, discarding any information on the location of the
macro
expansion point if such usage was in a macro. This makes the warnings
impossible to control reliably with #pragma GCC diagnostic, and also
discards
useful context in the diagnostic output. There seems to be no need to
discard
the virtual location information, so this patch fixes that.

PR69543 was mostly about _Pragma issues which have been fixed for many
years
now. The PR remains open because two of the testcases added in response to
it
still have xfails, but those xfails have nothing to do with _Pragma and
rather
just with the issue fixed by this patch, so the PR can be closed now as
well.

The other testcase modified here, pragma-diagnostic-2.c, was explicitly
testing for the undesirable behavior that was xfailed in pr69543-3.c. I
have
adjusted that and also added a new testcase verifying all 3 types of
warning
that come from tree-ssa-uninit.cc get the proper location information now.

gcc/ChangeLog:

PR preprocessor/69543
* tree-ssa-uninit.cc (warn_uninit): Stop stripping macro tracking
information away from the diagnostic location.
(maybe_warn_read_write_only): Likewise.
(maybe_warn_operand): Likewise.

gcc/testsuite/ChangeLog:

PR preprocessor/69543
* c-c++-common/pr69543-3.c: Remove xfail.
* c-c++-common/pr69543-4.c: Likewise.
* gcc.dg/cpp/pragma-diagnostic-2.c: Adjust test for new behavior.
* c-c++-common/pragma-diag-16.c: New test.

[Bug c++/107080] ICE in verify_symtab_nodes using _Float64x with long double

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-2993-ge564021e4c225420cd8986e9a7a42efe741f92d1
Author: Jakub Jelinek 
Date:   Fri Sep 30 19:52:49 2022 +0200

aarch64: Fix C++ ICEs with _Float16 and __fp16 [PR107080]

On Fri, Sep 30, 2022 at 09:54:49AM -0400, Jason Merrill wrote:
> > Note, there is one further problem on aarch64/arm, types with HFmode
> > (_Float16 and __fp16) are there mangled as Dh (which is standard
> > Itanium mangling:
> >   ::= Dh # IEEE 754r half-precision floating point (16
bits)
> >   ::= DF  _ # ISO/IEC TS 18661 binary floating
point type _FloatN (N bits)
> > so in theory is also ok, but DF16_ is more specific.  Should we just
> > change Dh to DF16_ in those backends, or should __fp16 there be
distinct
> > type from _Float16 where __fp16 would mangle Dh and _Float16 DF16_ ?
>
> You argued for keeping __float128 separate from _Float128, does the same
> argument not apply to this case?

Actually, they already were distinct types that just mangled the same.
So the same issue that had to be solved on i?86, ia64 and rs6000 for
_Float64x vs. long double is a problem on arm and aarch64 with _Float16
vs. __fp16.
The following patch fixes it so far for aarch64.

2022-09-30  Jakub Jelinek  

PR c++/107080
* config/aarch64/aarch64.cc (aarch64_mangle_type): Mangle just
__fp16
as Dh and _Float16 as DF16_.

* g++.target/aarch64/pr107080.C: New test.

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

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

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

--- Comment #9 from Francois-Xavier Coudert  ---
OK so there are three things tested here:

- underflow mode
- rounding mode
- trapping mode

For glibc targets, underflow control is only marked as supported for the float
and double types on __alpha__. For rounding mode, the code makes incorrect
assumptions and I have proposed a prototype patch to
support_fpu_rounding_mode().

For trapping modes, it means that support_fpu_trap() needs to perform correct
runtime checks. As I understand, this can be done by calling feenableexcept()
and checking whether it returns -1 (flag not supported) or something else (flag
supported). Then I need to restore the flag with fedisableexcept(), if the flag
was not already set prior to the feenableexcept() call.

I will write a patch when I have time. Thanks for pointing the issue out to me.

[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6

[dan at stahlke dot org via Gcc-bugs]

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

--- Comment #25 from Dan Stahlke  ---
The test case I just posted appears in the bug 105651 discussion.  So maybe or
maybe not related to the present discussion.

[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6

[dan at stahlke dot org via Gcc-bugs]

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

Dan Stahlke  changed:

   What|Removed |Added

 CC||dan at stahlke dot org

--- Comment #24 from Dan Stahlke  ---
Here is another test case, broken on 12.2 with "-std=c++20 -Wrestrict -O3" but
working on trunk and working on 12.2 with -O2 rather than -O3.

#include 
#include  // std::ignore

int main()
{
std::string s = "b";
std::ignore = "a" + std::move(s);
}

[Bug c++/107104] New: semantics of __builtin_constant_p within static_assert and return value

[me at inclyc dot cn via Gcc-bugs]

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

Bug ID: 107104
   Summary: semantics of __builtin_constant_p within static_assert
and return value
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: me at inclyc dot cn
  Target Milestone: ---

https://godbolt.org/z/oz4e7bobT
https://godbolt.org/z/hE6x9G49q

illustrate different occasions about this issue. 

Consider passing the same operand __builtin_constant_p in static assertions and
return value, expression with in static assertion passed, but the same
expression evaluates to 0 as the return value.

Are there some different scopes / contexts that causes different result?

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158
Link: https://github.com/llvm/llvm-project/issues/58078

[Bug c++/107080] ICE in verify_symtab_nodes using _Float64x with long double

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Should be fixed now.

[Bug c++/107080] ICE in verify_symtab_nodes using _Float64x with long double

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-2992-ga6d8c61a498e9daa1bc7fe419055ae44ad8289cc
Author: Jakub Jelinek 
Date:   Fri Sep 30 18:40:35 2022 +0200

i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128
[PR107080]

The following testcase ICEs on x86 as well as ppc64le (the latter
with -mabi=ieeelongdouble), because _Float64x there isn't mangled as
DF64x but e or u9__ieee128 instead.
Those are the mangling that should be used for the non-standard
types with the same mode or for long double, but not for _Float64x.
All the 4 mangle_type targhook implementations start with
type = TYPE_MAIN_VARIANT (type);
so I think it is cleanest to handle it the same in all and return NULL
before the switches on mode or whatever other tests.
s390 doesn't actually have a bug, but while I was there, having
type = TYPE_MAIN_VARIANT (type);
if (TYPE_MAIN_VARIANT (type) == long_double_type_node)
looked useless to me.

Note, there is one further problem on aarch64/arm, types with HFmode
(_Float16 and __fp16) are there mangled as Dh (which is standard
Itanium mangling:
 ::= Dh # IEEE 754r half-precision floating point (16 bits)
 ::= DF  _ # ISO/IEC TS 18661 binary floating point
type _FloatN (N bits)
so in theory is also ok, but DF16_ is more specific.  Should we just
change Dh to DF16_ in those backends, or should __fp16 there be distinct
type from _Float16 where __fp16 would mangle Dh and _Float16 DF16_ ?
And there is csky, which mangles __fp16 (but only if type's name is __fp16,
not _Float16) as __fp16, that looks clearly invalid to me as it isn't
valid in the mangling grammar.  So perhaps just nuke csky's mangle_type
and have it mangled as DF16_ by the generic code?

2022-09-30  Jakub Jelinek  

PR c++/107080
* config/i386/i386.cc (ix86_mangle_type): Always return NULL
for float128_type_node or float64x_type_node, don't check
float128t_type_node later on.
* config/ia64/ia64.cc (ia64_mangle_type): Always return NULL
for float128_type_node or float64x_type_node.
* config/rs6000/rs6000.cc (rs6000_mangle_type): Likewise.
Don't check float128_type_node later on.
* config/s390/s390.cc (s390_mangle_type): Don't use
TYPE_MAIN_VARIANT on type which was set to TYPE_MAIN_VARIANT
a few lines earlier.

* g++.dg/cpp23/ext-floating11.C: New test.

[Bug target/107103] New: '-fcompare-debug' failure w/ -mcpu=power4 -O1 -fschedule-insns -funroll-all-loops -fno-sched-pressure --param max-sched-ready-insns=1

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 107103
   Summary: '-fcompare-debug' failure w/ -mcpu=power4 -O1
-fschedule-insns -funroll-all-loops
-fno-sched-pressure --param max-sched-ready-insns=1
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: compare-debug-failure
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu

gcc 13.0.0 20220925 snapshot (g:77bbf69d2981dafc2ef3e59bfbefb645d88bab9d) fails
-fcompare-debug check when compiling the following testcase, reduced from
gcc/testsuite/g++.target/powerpc/pr65240-1.C, w/ -mcpu=power4 -O1
-fschedule-insns -funroll-all-loops -fno-sched-pressure --param
max-sched-ready-insns=1:

int *p;
int n;

int
bar (int);

void
foo (int x)
{
  for (;;)
if (x)
  p[n] = bar (x);
}

% powerpc-e300c3-linux-gnu-gcc-13.0.0 -mcpu=power4 -O1 -fcompare-debug
-fschedule-insns -funroll-all-loops -fno-sched-pressure --param
max-sched-ready-insns=1 -c ke3djyoc.c
powerpc-e300c3-linux-gnu-gcc-13.0.0: error: ke3djyoc.c: '-fcompare-debug'
failure

--- ke3djyoc.c.gkd  2022-09-30 23:33:02.202245982 +0700
+++ ke3djyoc.gk.c.gkd   2022-09-30 23:33:02.218245953 +0700
@@ -102,16 +102,16 @@
 (code_label # 0 0 19 (nil) [8 uses])
 (note # 0 0 [bb 3] NOTE_INSN_BASIC_BLOCK)
 (note # 0 0 NOTE_INSN_DELETED)
+(insn # 0 0 (set (reg/f:SI 30 30 [orig:131 p ] [131])
+(mem/f/c:SI (lo_sum:SI (reg/f:SI 27 27 [126])
+(symbol_ref:SI ("p") [flags 0x86]  )) [ p+0 S4
A32])) "ke3djyoc.c":12:8# {*movsi_internal1}
+ (nil))
 (insn # 0 0 (set (reg:SI 31 31 [orig:130 n ] [130])
 (mem/c:SI (lo_sum:SI (reg/f:SI 28 28 [128])
 (symbol_ref:SI ("n") [flags 0x86]  )) [ n+0 S4
A32])) "ke3djyoc.c":12:8# {*movsi_internal1}
  (expr_list:REG_EQUIV (mem/c:SI (lo_sum:SI (reg/f:SI 28 28 [128])
 (symbol_ref:SI ("n") [flags 0x86]  )) [ n+0 S4
A32])
 (nil)))
-(insn # 0 0 (set (reg/f:SI 30 30 [orig:131 p ] [131])
-(mem/f/c:SI (lo_sum:SI (reg/f:SI 27 27 [126])
-(symbol_ref:SI ("p") [flags 0x86]  )) [ p+0 S4
A32])) "ke3djyoc.c":12:8# {*movsi_internal1}
- (nil))
 (insn # 0 0 (set (reg:SI 3 3)
 (reg/v:SI 29 29 [orig:123 x ] [123])) "ke3djyoc.c":12:14#
{*movsi_internal1}
  (nil))

[Bug target/107102] New: SVE function fails to realize it doesn't need the frame-pointer in the tail call.

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

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

Bug ID: 107102
   Summary: SVE function fails to realize it doesn't need the
frame-pointer in the tail call.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*

The following example:

#include 

void foo(svbool_t p, svbool_t q);

void bar() {
foo(svptrue_b32(), svptrue_b8());
}

generates at -O2 -march=armv8-a+sve2:

bar:
stp x29, x30, [sp, -16]!
ptrue   p1.b, all
ptrue   p0.s, all
mov x29, sp
bl  foo
ldp x29, x30, [sp], 16
ret

The tail-call gets de-optimized and GCC fails to realize it doesn't need a
frame pointer nor the stack pointer at all.

In RTL before frame layout there is no stack usage at all however this looks to
happen because in the expansion there's a clobber on the LR:

(call_insn 7 6 10 2 (parallel [
(call (mem:DI (symbol_ref:DI ("foo") [flags 0x41]  ) [0 foo S8 A8])
(const_int 0 [0]))
(unspec:DI [
(const_int 2 [0x2])
] UNSPEC_CALLEE_ABI)
(clobber (reg:DI 30 x30))
]) "example.c":6:5 46 {*call_insn}

and it, it looks like the expansion missed the sibcall?

[Bug d/107101] d: Add stub for object module when libphobos is not compiled, or supported

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #1 from Iain Buclaw  ---
This also affects when compiling with `-nostdinc`.

[Bug d/107101] New: d: Add stub for object module when libphobos is not compiled, or supported

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 107101
   Summary: d: Add stub for object module when libphobos is not
compiled, or supported
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Currently behaviour is that object.d is searched for anyway, resulting in an
error that it cannot be found.

---
/opt/compiler-explorer/sh/gcc-12.2.0/sh-multilib-linux-gnu/bin/sh-multilib-linux-gnu-gdc
-c /tmp/test.d
d21: error: cannot find source code for runtime library file 'object.d'
d21: note: dmd might not be correctly installed. Run 'dmd -man' for
installation instructions.
d21: note: config file: not found
---


Just declaring a stub module means that although the language at compile-time
would be crippled, at least you'll be able to build *something*.

[Bug c/107100] -fanalyzer false positive about leak in function with attribute((malloc)) obtained from another function with attribute((malloc(free,1)))

[eblake at redhat dot com via Gcc-bugs]

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

--- Comment #1 from Eric Blake  ---
Might be a dup of bug#101648

[Bug c++/107083] [modules] internal compiler error: in core_vals, at cp/module.cc:6127

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

Alexander Lelyakin  changed:

   What|Removed |Added

 CC||alexander.lelyakin@googlema
   ||il.com

--- Comment #1 from Alexander Lelyakin  ---
Similar output while precompiling header  :

g++ --param=hash-table-verification-limit=1000 -std=c++20 -fmodules-ts -x
c++-system-header execution

/usr/local/include/c++/13.0.0/execution: internal compiler error: in core_vals,
at cp/module.cc:6234
0x77c95d trees_out::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6234
0xb386b4 trees_out::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7178
0xb386b4 trees_out::tree_value(tree_node*)
../../gcc/gcc/cp/module.cc:9043
0xb34411 trees_out::tree_node(tree_node*)
../../gcc/gcc/cp/module.cc:9241
0xb35ac3 trees_out::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6142
0xb32f1a trees_out::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7178
0xb32f1a trees_out::decl_value(tree_node*, depset*)
../../gcc/gcc/cp/module.cc:7757
0xb3a7a2 depset::hash::find_dependencies(module_state*)
../../gcc/gcc/cp/module.cc:13315
0xb3af31 module_state::write_begin(elf_out*, cpp_reader*, module_state_config&,
unsigned int&)
../../gcc/gcc/cp/module.cc:17887
0xb3c324 finish_module_processing(cpp_reader*)
../../gcc/gcc/cp/module.cc:20221
0xac9a1b c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.cc:5112
0xcf3610 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.cc:1273
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.

g++ (GCC) 13.0.0 20220929 (experimental)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c/107100] New: -fanalyzer false positive about leak in function with attribute((malloc)) obtained from another function with attribute((malloc(free,1)))

[eblake at redhat dot com via Gcc-bugs]

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

Bug ID: 107100
   Summary: -fanalyzer false positive about leak in function with
attribute((malloc)) obtained from another function
with attribute((malloc(free,1)))
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eblake at redhat dot com
  Target Milestone: ---

I'm at a loss for why disabling -O2 or removing __attribute__((malloc(free,1)))
from function f silences a false-positive warning about a memory leak in
function g with __attribute((malloc)) specifically documenting that g() wants
to return a just-allocated pointer:

$ cat foo.c
#include 
#include 

char *
__attribute__((malloc))
#ifndef HACK
__attribute__((malloc(free,1)))
#endif
f (const char *i)
{
  return strdup (i);
}

char *
__attribute__((malloc))
__attribute__((malloc(free,1)))
bar (void)
{
  char *x = f ("test");
  return x;
}
$ gcc -O2 -Wsuggest-attribute=malloc -fanalyzer -o foo.o -c foo.c
$ gcc -DHACK -Wsuggest-attribute=malloc -fanalyzer -o foo.o -c foo.c
$ gcc -Wsuggest-attribute=malloc -fanalyzer -o foo.o -c foo.c
foo.c: In function ‘f’:
foo.c:11:10: warning: leak of ‘x’ [CWE-401] [-Wanalyzer-malloc-leak]
   11 |   return strdup (i);
  |  ^~
  ‘bar’: events 1-3
|
|   17 | bar (void)
|  | ^~~
|  | |
|  | (1) entry to ‘bar’
|   18 | {
|   19 |   char *x = f ("test");
|  | ~~
|  | |
|  | (2) allocated here
|  | (3) calling ‘f’ from ‘bar’
|
+--> ‘f’: events 4-5
   |
   |9 | f (const char *i)
   |  | ^
   |  | |
   |  | (4) entry to ‘f’
   |   10 | {
   |   11 |   return strdup (i);
   |  |  ~~
   |  |  |
   |  |  (5) ‘x’ leaks here; was allocated at (2)
   |

[Bug tree-optimization/107099] New: uncprop a bit

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

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

Bug ID: 107099
   Summary: uncprop a bit
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

For the following testcase

#include 

__attribute__((target("avx")))
int f(__m128i a[], long n)
{
for (long i = 0; i < n; i++)
if (!_mm_testz_si128(a[i], a[i]))
return 0;
return 1;
}

gcc -O2 generates

f:
testrsi, rsi
jle .L4
xor eax, eax
jmp .L3
.L10:
add rax, 1
cmp rsi, rax
je  .L4
.L3:
mov rdx, rax
sal rdx, 4
vmovdqa xmm0, XMMWORD PTR [rdi+rdx]
xor edx, edx
vptest  xmm0, xmm0
setedl
je  .L10
mov eax, edx
ret
.L4:
mov edx, 1
mov eax, edx
ret

Note the redundant assignments to edx in the loop and compare with gcc -O2
-fdisable-tree-uncprop1

Also note that generally uncprop adds a data dependency where only a control
dependency existed, hurting speculative execution (hence more appropriate for
-Os than -O2).

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

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

[Bug other/107098] [13 regression] failure in 453.povray after r13-2810-gb7fd7fb5011106

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup

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

[Bug other/107098] [13 regression] failure in 453.povray after r13-2810-gb7fd7fb5011106

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[13 regression] failure in  |[13 regression] failure in
   |453.povray  |453.povray after
   ||r13-2810-gb7fd7fb5011106

--- Comment #1 from seurer at gcc dot gnu.org ---
g:b7fd7fb5011106c062df9275ca8fddcbce4ebdeb, r13-2810-gb7fd7fb5011106

[Bug other/107098] New: [13 regression] failure in 453.povray

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

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

Bug ID: 107098
   Summary: [13 regression] failure in 453.povray
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Now at commit g:b7fd7fb5011106c062df9275ca8fddcbce4ebdeb, r13-2810 

commit b7fd7fb5011106c062df9275ca8fddcbce4ebdeb
Author: Aldy Hernandez 
Date:   Thu Sep 22 18:20:39 2022 +0200

frange: drop endpoints to min/max representable numbers for
-ffinite-math-only.


This commit breaks one of the spec2006 test cases on powerpc64 LE

Running Benchmarks
  Running 453.povray ref base ppc64 default
453.povray: copy 0 non-zero return code (exit code=127, signal=0)
Invalid run; unable to continue.

Note that -ffinite-math-only is not used in compiling the source.  Sample
compilation:

/home/seurer/gcc/git/install/gcc-test/bin/g++ -c -o bcyl.o -DSPEC_CPU -DNDEBUG 
 -m64 -O3 -mcpu=power8 -ffast-math -funroll-loops -fpeel-loops
-fvect-cost-model -mpopcntd -mrecip=rsqrt   bcyl.cpp

Or is that option included by one of the others?

I am not seeing anything in the log of the run that indicates what the error
was unfortunately.

[Bug c++/107097] Implement floating point excess precision in C++

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

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

Jason Merrill  changed:

   What|Removed |Added

   Last reconfirmed||2022-09-30
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=106652
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Severity|normal  |enhancement

[Bug c++/107097] New: Implement floating point excess precision in C++

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

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

Bug ID: 107097
   Summary: Implement floating point excess precision in C++
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
  Target Milestone: ---

Joseph Myers implemented C99 excess precision support for C in 4.5:
https://gcc.gnu.org/legacy-ml/gcc-patches/2008-11/msg00105.html

C++ has a similar rule in [expr.pre]p6:

"The values of the floating-point operands and the results of floating-point
expressions may be represented in greater precision and range than that
required by the type; the types are not changed thereby. [Footnote: The cast
and assignment operators must still perform their specific conversions.]"

Implementing this seems particularly important for users wanting to use 16-bit
floating point types in C++.

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

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

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
See the comment above rgroup_controls in tree-vectorizer.h for the
current assumptions around loop predication.  If AVX512 wants something
different then some extensions will be needed :-)

[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #13 from Mikael Morin  ---
Here is my understanding of the problem.

There is a check on operand types in eval_intrinsic guarding numerical
evaluation:

1573case INTRINSIC_PLUS:
1574case INTRINSIC_MINUS:
1575case INTRINSIC_TIMES:
1576case INTRINSIC_DIVIDE:
1577case INTRINSIC_POWER:
1578  if (!gfc_numeric_ts (>ts) || !gfc_numeric_ts (>ts))
1579goto runtime;

If we pass this check, we proceed to reduce_binary, where if one (or both) of
the operands is an array, we do numerical evaluation for every element of the
array.

With the guarding check above, it is safe, with the assumption that elements of
an array have the same type as the array itself.  If that condition is not
true, well, it doesn't work obviously.

I don't see right now where an additional check would fit well, but the fix
doesn't belong to walk_array_constructor in any case from my point of view.

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

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

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

--- Comment #8 from Richard Earnshaw  ---
(In reply to Francois-Xavier Coudert from comment #7)
> @Richard The test in gfortran.dg/ieee/modes_1.f90 is not doing that. It is
> checking that the floating-point modes (rounding mode, underflow mode, and
> halting modes) can be set and restored. It is not actually performing any FP
> operation at all.

This is to do with the trapping, though, isn't it?  The failing test is trying
to test the halting mode setting and restoration.  The code is currently
assuming that because the flag bit exists, it can set and restore it, but
although the bit is defined in the architecture, on some (most) implementations
it's RAZ/WI (read-as-zero, write-ignored).  So the code that assumes this goes
wrong.

I might be slightly on the wrong lines here, but in the glibc fp support we
have

int
support_fpu_trap (int flag)
{
  return support_fpu_flag (flag);
}

So we're immediately assuming that if we have the flag, we can support the
trap.  And of course, support_fpu_flag only tests that the relevant flag bit is
defined, not if the HW supports changing it.

[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #14 from Kewen Lin  ---
Fixed.

[Bug target/99889] Add powerpc ELFv1 support for -fpatchable-function-entry* with "o" sections

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

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

Bug 99888 Summary: Add powerpc ELFv2 support for -fpatchable-function-entry*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888

   What|Removed |Added

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

[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||giuliano.belinassi at gmail 
dot co
   ||m

--- Comment #13 from Kewen Lin  ---
*** Bug 105649 has been marked as a duplicate of this bug. ***

[Bug target/105649] Wrong .localentry address on powerpc64le with -fpatchable-function-entry=1

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #4 from Kewen Lin  ---
r13-2984 makes gcc emit error for -fpatchable-function-entry=1 on ppc64le if
the relavant function needs dual entry, I think we can close this one.

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

[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

 Target||x86_64-*-*
 CC||rsandifo at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Take the simplified

void foo (int * __restrict dst, short *src, int n)
{
  for (int i = 0; i < n; ++i)
dst[i] = src[2*i] + src[2*i+1];
}

here we get vect_record_loop_mask twice with nvectors == 2 and V16HImode
for the load which populates masks[2].  Then we once get V8SImode but
also with nvectors == 2 which leaves the data unadjusted since it
looks at masks[2] as well but if it were to come first we'd have recorded
a different mask vector type.

The masks seem to be constructed in a way to produce two bits per lane
(but we still apply it naively?!) and the V_C_E does actually look wrong
to me.  Huh.

With SVE I seem to get (besides a .LOAD_LANE version) permutes of the
mask vector:

  loop_mask_116 = VEC_PERM_EXPR ;
  loop_mask_117 = VEC_PERM_EXPR ;
...
  vect__69.20_118 = .MASK_LOAD (vectp_src.18_114, 16B, loop_mask_116);
  vectp_src.18_119 = vectp_src.18_114 + POLY_INT_CST [8, 8];
  vect__69.21_120 = .MASK_LOAD (vectp_src.18_119, 16B, loop_mask_117);
...
  .MASK_STORE (vectp_dst.25_129, 32B, loop_mask_131, vect__79.24_125);

so the original mask provider here is the larger element vector type
and the smaller element masks are produced from that.  That's something
I'd expect for AVX512 as well, not sure where it goes "wrong".

See PR107093 for a patch implementing WHILE_ULT for AVX512.

[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #10 from Kewen Lin  ---
Should be fixed on trunk.

[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r13-2984-gc23b5006d3ffeda1a9edf5fd817765a6da3696ca
Author: Kewen Lin 
Date:   Fri Sep 30 07:16:49 2022 -0500

rs6000: Rework ELFv2 support for -fpatchable-function-entry* [PR99888]

As PR99888 and its related show, the current support for
-fpatchable-function-entry on powerpc ELFv2 doesn't work
well with global entry existence.  For example, with one
command line option -fpatchable-function-entry=3,2, it got
below w/o this patch:

  .LPFE1:
  nop
  nop
  .type   foo, @function
  foo:
  nop
  .LFB0:
  .cfi_startproc
  .LCF0:
  0:  addis 2,12,.TOC.-.LCF0@ha
  addi 2,2,.TOC.-.LCF0@l
  .localentry foo,.-foo

, the assembly is unexpected since the patched nops have
no effects when being entered from local entry.

This patch is to update the nops patched before and after
local entry, it looks like:

  .type   foo, @function
  foo:
  .LFB0:
  .cfi_startproc
  .LCF0:
  0:  addis 2,12,.TOC.-.LCF0@ha
  addi 2,2,.TOC.-.LCF0@l
  nop
  nop
  .localentry foo,.-foo
  nop

PR target/99888
PR target/105649

gcc/ChangeLog:

* doc/invoke.texi (option -fpatchable-function-entry): Adjust the
documentation for PowerPC ELFv2 ABI dual entry points.
* config/rs6000/rs6000-internal.h
(rs6000_print_patchable_function_entry): New function declaration.
* config/rs6000/rs6000-logue.cc (rs6000_output_function_prologue):
Support patchable-function-entry by emitting nops before and after
local entry for the function that needs global entry.
* config/rs6000/rs6000.cc (rs6000_print_patchable_function_entry):
Skip
the function that needs global entry till global entry has been
emitted.
* config/rs6000/rs6000.h (struct machine_function): New bool member
global_entry_emitted.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr99888-1.c: New test.
* gcc.target/powerpc/pr99888-2.c: New test.
* gcc.target/powerpc/pr99888-3.c: New test.
* gcc.target/powerpc/pr99888-4.c: New test.
* gcc.target/powerpc/pr99888-5.c: New test.
* gcc.target/powerpc/pr99888-6.c: New test.
* c-c++-common/patchable_function_entry-default.c: Adjust for
powerpc_elfv2 to avoid compilation error.

[Bug target/105649] Wrong .localentry address on powerpc64le with -fpatchable-function-entry=1

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r13-2984-gc23b5006d3ffeda1a9edf5fd817765a6da3696ca
Author: Kewen Lin 
Date:   Fri Sep 30 07:16:49 2022 -0500

rs6000: Rework ELFv2 support for -fpatchable-function-entry* [PR99888]

As PR99888 and its related show, the current support for
-fpatchable-function-entry on powerpc ELFv2 doesn't work
well with global entry existence.  For example, with one
command line option -fpatchable-function-entry=3,2, it got
below w/o this patch:

  .LPFE1:
  nop
  nop
  .type   foo, @function
  foo:
  nop
  .LFB0:
  .cfi_startproc
  .LCF0:
  0:  addis 2,12,.TOC.-.LCF0@ha
  addi 2,2,.TOC.-.LCF0@l
  .localentry foo,.-foo

, the assembly is unexpected since the patched nops have
no effects when being entered from local entry.

This patch is to update the nops patched before and after
local entry, it looks like:

  .type   foo, @function
  foo:
  .LFB0:
  .cfi_startproc
  .LCF0:
  0:  addis 2,12,.TOC.-.LCF0@ha
  addi 2,2,.TOC.-.LCF0@l
  nop
  nop
  .localentry foo,.-foo
  nop

PR target/99888
PR target/105649

gcc/ChangeLog:

* doc/invoke.texi (option -fpatchable-function-entry): Adjust the
documentation for PowerPC ELFv2 ABI dual entry points.
* config/rs6000/rs6000-internal.h
(rs6000_print_patchable_function_entry): New function declaration.
* config/rs6000/rs6000-logue.cc (rs6000_output_function_prologue):
Support patchable-function-entry by emitting nops before and after
local entry for the function that needs global entry.
* config/rs6000/rs6000.cc (rs6000_print_patchable_function_entry):
Skip
the function that needs global entry till global entry has been
emitted.
* config/rs6000/rs6000.h (struct machine_function): New bool member
global_entry_emitted.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr99888-1.c: New test.
* gcc.target/powerpc/pr99888-2.c: New test.
* gcc.target/powerpc/pr99888-3.c: New test.
* gcc.target/powerpc/pr99888-4.c: New test.
* gcc.target/powerpc/pr99888-5.c: New test.
* gcc.target/powerpc/pr99888-6.c: New test.
* c-c++-common/patchable_function_entry-default.c: Adjust for
powerpc_elfv2 to avoid compilation error.

[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r13-2983-gc28957176dc0adff6e4b8fcbe6b91f5b82900563
Author: Kewen Lin 
Date:   Fri Sep 30 07:16:36 2022 -0500

rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516]

As PR106516 shows, we can get unexpected gimple outputs for
function thud on some target which supports modulus operation
for vector int.  This patch introduces one effective target
vect_int_mod for it, then adjusts the test case with it.

PR testsuite/106516

gcc/testsuite/ChangeLog:

* gcc.dg/pr104992.c: Adjust with vect_int_mod.
* lib/target-supports.exp (check_effective_target_vect_int_mod):
New
effective target.

[Bug middle-end/107088] [13 Regression] cselib ICE building __trunctfxf2 on ia64

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

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

--- Comment #9 from Andrew Stubbs  ---
I can confirm that the patch fixes the amdgcn build.

[Bug rtl-optimization/107094] [13 Regression] ICE in require, at machmode.h:297 since r13-2916-gd0b00b63a39108

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug middle-end/107088] [13 Regression] cselib ICE building __trunctfxf2 on ia64

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

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
(In reply to Stefan Schulze Frielinghaus from comment #6)
> I did a quick test using
> 
> diff --git a/gcc/cselib.cc b/gcc/cselib.cc
> index 9b582e5d3d6..2fd0190bc79 100644
> --- a/gcc/cselib.cc
> +++ b/gcc/cselib.cc
> @@ -1571,6 +1571,7 @@ new_cselib_val (unsigned int hash, machine_mode mode,
> rtx x)
>  
>scalar_int_mode int_mode;
>if (REG_P (x) && is_int_mode (mode, _mode)
> +  && int_mode != BImode
>&& REG_VALUES (REGNO (x)) != NULL
>&& (!cselib_current_insn || !DEBUG_INSN_P (cselib_current_insn)))
>  {
>  
> which solved the cross ia64 build for me. Maybe there are further integer
> modes which I didn't consider, i.e., I will have a thorough look at it next
> week.
Looks good, but maybe:

  GET_MODE_SIZE (int_mode) > 1

would be more general.

BImode being MODE_INT is a horrible wart (it should be MODE_PARTIAL_INT
instead).  But unfortunately ia64 is the target that would be most
affected by "fixing" this, and it's not an easy target to test.
So I think in practice nothing will change while ia64 is the in tree.

[Bug middle-end/107088] [13 Regression] cselib ICE building __trunctfxf2 on ia64

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

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

Andrew Stubbs  changed:

   What|Removed |Added

 Target|ia64-*-*|ia64-*-*, amdgcn-*-*
 CC||ams at gcc dot gnu.org

--- Comment #7 from Andrew Stubbs  ---
I get the same failure on amdgcn building newlib/libm/math/kf_rem_pio2.c

[Bug tree-optimization/107095] gcc.dg/vect/vect-89.c gets miscompiled by DSE

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/107095] gcc.dg/vect/vect-89.c gets miscompiled by DSE

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:44510e44e717d9c05b0c5d197a73676a9427e32f

commit r13-2981-g44510e44e717d9c05b0c5d197a73676a9427e32f
Author: Richard Biener 
Date:   Fri Sep 30 12:47:22 2022 +0200

tree-optimization/107095 - fix typo in .MASK_STORE DSE handling

We were using the size of the mask argument rather than the data
argument for the ao_ref.

PR tree-optimization/107095
* tree-ssa-dse.cc (initialize_ao_ref_for_dse): Use data arg
for .MASK_STORE size.

[Bug fortran/105318] [OpenMP][5.1] is_device_ptr rejects valid arguments to has_device_addr

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
FIXED in GCC 13. (Side note: has_device_addr was added in GCC 12.)

[Bug tree-optimization/107096] New: 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

Bug ID: 107096
   Summary: Fully masking vectorization with AVX512 ICEs
gcc.dg/vect/vect-over-widen-*.c
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

With like

/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/vect-over-widen-2.c:11:1:
error: conversion of register to a different size in 'view_convert_expr'
VIEW_CONVERT_EXPR>(loop_mask_11);

_164 = VIEW_CONVERT_EXPR>(loop_mask_11);
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/vect-over-widen-2.c:11:1:
error: conversion of register to a different size in 'view_convert_expr'
VIEW_CONVERT_EXPR>(loop_mask_8);

_167 = VIEW_CONVERT_EXPR>(loop_mask_8);
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/vect-over-widen-2.c:11:1:
error: conversion of register to a different size in 'view_convert_expr'
VIEW_CONVERT_EXPR>(loop_mask_118);

_170 = VIEW_CONVERT_EXPR>(loop_mask_118);
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/vect-over-widen-2.c:11:1:
error: conversion of register to a different size in 'view_convert_expr'
VIEW_CONVERT_EXPR>(loop_mask_119);

_173 = VIEW_CONVERT_EXPR>(loop_mask_119);
during GIMPLE pass: vect
dump file: ./vect-over-widen-2.c.172t.vect
/home/rguenther/src/trunk/gcc/testsuite/gcc.dg/vect/vect-over-widen-2.c:11:1:
internal compiler error: verify_gimple failed


The issue is that in vect_get_loop_mask we do

  if (maybe_ne (TYPE_VECTOR_SUBPARTS (mask_type),
TYPE_VECTOR_SUBPARTS (vectype)))
{
  /* A loop mask for data type X can be reused for data type Y
 if X has N times more elements than Y and if Y's elements
 are N times bigger than X's.  In this case each sequence
 of N elements in the loop mask will be all-zero or all-one.
 We can then view-convert the mask so that each sequence of
 N elements is replaced by a single element.  */
  gcc_assert (multiple_p (TYPE_VECTOR_SUBPARTS (mask_type),
  TYPE_VECTOR_SUBPARTS (vectype)));
  gimple_seq seq = NULL;
  mask_type = truth_type_for (vectype);
  mask = gimple_build (, VIEW_CONVERT_EXPR, mask_type, mask);

but that ends up VIEW_CONVERTing vector(16)  to
vector(8) , in this case a HImode mask to a QImode mask.

If I understand the comment correctly then it wants to re-use a mask
for V16QI for V8HI indicating that the mask bits should be set in pairs
for the V16QImask.  But then I don't understand how VIEW_CONVERTing
should perform the desired conversion.  It might be OK if the mask is
a byte mask (like for classic AVX2) but for AVX512 it would require
unpacking even/odd bits.

The actual error is likely in the setup of the loop masks though, thinking
we could do this re-use.

[Bug fortran/105318] [OpenMP][5.1] is_device_ptr rejects valid arguments to has_device_addr

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:10a116104969b3ecc9ea4abdd5436c66fd78d537

commit r13-2980-g10a116104969b3ecc9ea4abdd5436c66fd78d537
Author: Tobias Burnus 
Date:   Fri Sep 30 13:27:32 2022 +0200

Fortran: Update use_device_ptr for OpenMP 5.1 [PR105318]

OpenMP 5.1 added has_device_addr and relaxed the restrictions for
use_device_ptr, including processing non-type(c_ptr) arguments as
if has_device_addr was used. (There is a semantic difference.)

For completeness, the likewise change was done for 'use_device_ptr',
where non-type(c_ptr) arguments now use use_device_addr.

Finally, a warning for 'device(omp_{initial,invalid}_device)' was
silenced on the way as affecting the new testcase.

PR fortran/105318

gcc/fortran/ChangeLog:
* openmp.cc (resolve_omp_clauses): Update is_device_ptr
restrictions
for OpenMP 5.1 and map to has_device_addr where applicable; map
use_device_ptr to use_device_addr where applicable.
Silence integer-range warning for
device(omp_{initial,invalid}_device).

libgomp/ChangeLog:
* testsuite/libgomp.fortran/is_device_ptr-2.f90: New test.

gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/is_device_ptr-1.f90: Remove dg-error.
* gfortran.dg/gomp/is_device_ptr-2.f90: Likewise.
* gfortran.dg/gomp/is_device_ptr-3.f90: Update tree-scan-dump.

[Bug tree-optimization/106884] ifcombine may move shift so it shifts more than bitwidth

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

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

--- Comment #3 from Krister Walfridsson  ---
A similar case is

int r1, r2;

int foo(int a, int s1, int s2)
{
  if (a & (1 << s1))
return r1;
  if (a & (1 << s2))
return r1;
  return r2;
}

where reassoc2 optimizes this to always shift by s2.

[Bug middle-end/107088] [13 Regression] cselib ICE building __trunctfxf2 on ia64

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #6 from Stefan Schulze Frielinghaus  
---
I did a quick test using

diff --git a/gcc/cselib.cc b/gcc/cselib.cc
index 9b582e5d3d6..2fd0190bc79 100644
--- a/gcc/cselib.cc
+++ b/gcc/cselib.cc
@@ -1571,6 +1571,7 @@ new_cselib_val (unsigned int hash, machine_mode mode, rtx
x)

   scalar_int_mode int_mode;
   if (REG_P (x) && is_int_mode (mode, _mode)
+  && int_mode != BImode
   && REG_VALUES (REGNO (x)) != NULL
   && (!cselib_current_insn || !DEBUG_INSN_P (cselib_current_insn)))
 {

which solved the cross ia64 build for me. Maybe there are further integer modes
which I didn't consider, i.e., I will have a thorough look at it next week.

[Bug libstdc++/107092] std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type

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

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

--- Comment #2 from Jonathan Wakely  ---
https://cplusplus.github.io/LWG/issue3213 is relevant, but we didn't address
the ambiguity question.

[Bug libstdc++/107092] std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-09-30
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
The reason I added overloads for floating-point types is that they can be
converted to integral types. But if you read "is convertible to **an** integral
type" as meaning unambiguously convertible to exactly one integral type, then
that's not true for FP types.

I did add tests for PR 87982 that FP types can be used, but I don't think there
were any pre-existing tests, and maybe nobody needs that.

I could retain support for real FP types, but reject your testcase, like this:

  constexpr long long
  __size_to_integer(floating_point auto __n) { return (long long)__n; }

But maybe I should just drop the FP overloads.

[Bug tree-optimization/107095] gcc.dg/vect/vect-89.c gets miscompiled by DSE

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2022-09-30
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Richard Biener  ---
Caused by a typo of mine.

[Bug tree-optimization/107095] New: gcc.dg/vect/vect-89.c gets miscompiled by DSE

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

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

Bug ID: 107095
   Summary: gcc.dg/vect/vect-89.c gets miscompiled by DSE
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

When fully masked the loop with 256bit vectors gets optimized by FRE4 to

   [local count: 63136016]:
  .MASK_STORE (, 256B, { 0, -1, -1, -1, -1, -1, -1, -1 }, { 5, 5, 5, 5, 5,
5, 5, 5 });
  MEM  [(int *) + 32B] = { 5, 5, 5, 5, 5, 5, 5, 5 };
  .MASK_STORE (  [(void *) + 64B], 256B, { -1, 0, 0,
0, 0, 0, 0, 0 }, { 5, 5, 5, 5, 5, 5, 5, 5 });

   [local count: 1010605809]:
  # i_18 = PHI 
  # ivtmp_3 = PHI 
  _1 = tmp.y[i_18];
  if (_1 != 5)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  abort ();

   [local count: 1010605809]:
  i_8 = i_18 + 1;
  ivtmp_5 = ivtmp_3 - 1;
  if (ivtmp_5 != 0)
goto ; [94.12%]
  else
goto ; [5.88%]

   [local count: 951182190]:
  goto ; [100.00%]

   [local count: 63136016]:
  tmp ={v} {CLOBBER(eol)};
  return 0;

but then DSE comes along and removes the first .MASK_STORE:

  Deleted dead call: .MASK_STORE (, 256B, { 0, -1, -1, -1, -1, -1, -1, -1
}, { 5, 5, 5, 5, 5, 5, 5, 5 });

[Bug target/107025] gas doesn't accept code produced by -mcpu=thunderx3t110

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk, not worth a backport.

[Bug rtl-optimization/107094] [13 Regression] ICE in require, at machmode.h:297 since r13-2916-gd0b00b63a39108

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #1 from Stefan Schulze Frielinghaus  
---
Looks like related to PR107088

[Bug rtl-optimization/107094] [13 Regression] ICE in require, at machmode.h:297 since r13-2916-gd0b00b63a39108

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-09-30
 Status|UNCONFIRMED |NEW

[Bug rtl-optimization/107094] New: [13 Regression] ICE in require, at machmode.h:297 since r13-2916-gd0b00b63a39108

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

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

Bug ID: 107094
   Summary: [13 Regression] ICE in require, at machmode.h:297
since r13-2916-gd0b00b63a39108
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: stefansf at linux dot ibm.com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: amdgcn-amdhsa

The following cross compiler crashes:

$ cat amd.i
int _vfwprintf_r_ch;

int btowc();
int __sprint_r();
int iov_len();

void
_vfwprintf_r() {
  int uio_0, buf;
  for (;;) {
switch (_vfwprintf_r_ch) {
case L'c':
  int wc = btowc();
  if (wc)
goto error;
  if (buf)
if (++uio_0)
  __sprint_r();
}
iov_len();
  }
error:
}

$ ./xgcc -B. amd.i -c -O2 
during RTL pass: postreload
amd.i: In function ‘_vfwprintf_r’:
amd.i:23:1: internal compiler error: in require, at machmode.h:297
   23 | }
  | ^
0xc47789 opt_mode::require() const
/home/marxin/Programming/gcc/gcc/machmode.h:297
0xcff5c8 void mode_iterator::get_known_wider(scalar_int_mode*)
/home/marxin/Programming/gcc/gcc/machmode.h:1124
0xcf9d81 new_cselib_val
/home/marxin/Programming/gcc/gcc/cselib.cc:1579
0xcfba7a cselib_lookup_1
/home/marxin/Programming/gcc/gcc/cselib.cc:2315
0xcfc183 cselib_lookup(rtx_def*, machine_mode, int, machine_mode)
/home/marxin/Programming/gcc/gcc/cselib.cc:2431
0xcfd498 cselib_record_sets
/home/marxin/Programming/gcc/gcc/cselib.cc:2932
0xcfe00a cselib_process_insn(rtx_insn*)
/home/marxin/Programming/gcc/gcc/cselib.cc:3159
0x123eac4 reload_cse_regs_1
/home/marxin/Programming/gcc/gcc/postreload.cc:229
0x123e5b4 reload_cse_regs
/home/marxin/Programming/gcc/gcc/postreload.cc:72
0x1244156 execute
/home/marxin/Programming/gcc/gcc/postreload.cc:2347
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.

[Bug target/107093] AVX512 mask operations not simplified in fully masked loop

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

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

--- Comment #1 from Richard Biener  ---
Created attachment 53645
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53645=edit
prototype for WHILE_ULT

I'm playing with the attached.  Note it requires the third operand patch for
WHILE_ULT (but it's basically approved).

[Bug target/107093] New: AVX512 mask operations not simplified in fully masked loop

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

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

Bug ID: 107093
   Summary: AVX512 mask operations not simplified in fully masked
loop
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Trying to implement WHILE_ULT for AVX512 I run into optimization issues. 
Consider

double a[1024], b[1024];

void foo (int n)
{
  for (int i = 0; i < n; ++i)
a[i] = b[i] * 3.;
}

compiled with -O3 -march=cascadelake --param vect-partial-vector-usage=2

I get snippets like

kxnorb  %k1, %k1, %k1
kortestb%k1, %k1
je  .L11

or

kxorb   %k1, %k1, %k1
kxnorb  %k1, %k1, %k1

where we fail to simplify the operations.  Looking at the RTL it looks
like missed jump threading, but I do see the ops being

(insn 18 72 74 5 (parallel [
(set (reg:QI 69 k1 [orig:86 loop_mask_15 ] [86])
(not:QI (xor:QI (reg:QI 69 k1 [orig:86 loop_mask_15 ] [86])
(reg:QI 69 k1 [orig:86 loop_mask_15 ] [86]
(unspec [
(const_int 0 [0])
] UNSPEC_MASKOP)
]) 1912 {kxnorqi}
 (expr_list:REG_EQUAL (const_int -1 [0x])
(nil)))

thus having an UNSPEC in them.  When emitting a SET from constm1 I end up
with mask<->GPR moves and if-converted code which isn't optimal either.
When doing -fno-if-conversion I get

.L7:
vmovapd b(%rax), %ymm1{%k1}
addl$4, %ecx
movl%edi, %edx
vmulpd  %ymm2, %ymm1, %ymm0
subl%ecx, %edx
vmovapd %ymm0, a(%rax){%k1}
kxnorb  %k1, %k1, %k1
cmpl$4, %edx
jge .L5
vpbroadcastd%edx, %xmm0
vpcmpd  $1, %xmm0, %xmm3, %k1
.L5:
addq$32, %rax
kortestb%k1, %k1
jne .L7

which also doesn't have the desired short-cut from the cmpl $4, %edx.

[Bug c++/107065] GCC treats rvalue as an lvalue

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

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

--- Comment #13 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #12)
> Doing it on the match.pd side doesn't look right, there could be many other
> optimizations that result in something similar.

$ grep -c non_lvalue match.pd   
12

probably they should be removed and those that were useful should be fixed by
similar techniques as you are considering...

To add one more option to your list, maybe the generic-simplify machinery could
add non_lvalue automatically in some cases? I still prefer your first option
though, tweaking the warning code, which probably expected x!=0 and now gets
!(x==0) or something similar.

[Bug c++/107065] GCC treats rvalue as an lvalue

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Guess one possibility would be to teach the warning code to look through
TRUTH_NOT_EXPR around stuff.
Or we could at least temporarily invert_truthvalue_loc if arg is tcc_comparison
or some similar special case.
Or similarly we could (for the time being) always invert_truthvalue_loc, but if
the lvalue_kind of arg and val changes wrap it in NON_LVALUE_EXPR.
Doing it on the match.pd side doesn't look right, there could be many other
optimizations that result in something similar.

[Bug target/93062] Failed to generate indirect branch for long branches on riscv

[christophm30 at gmail dot com via Gcc-bugs]

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

Christoph Müllner  changed:

   What|Removed |Added

 CC||christophm30 at gmail dot com

--- Comment #2 from Christoph Müllner  ---
Linking duplicate downstream issue:
https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1045

[Bug middle-end/107088] [13 Regression] cselib ICE building __trunctfxf2 on ia64

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
Thanks for looking into this! Currently I'm out of office and have very limited
internet access. I will be back on Tuesday and look right into this. If this is
to late feel free to revert my patch. Sorry for the inconvenience!

[Bug c++/107065] GCC treats rvalue as an lvalue

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

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

--- Comment #11 from Marc Glisse  ---
Did you try adding "non_lvalue" in match.pd? It looks less intrusive. Although
in the long term your approach seems better and the failures should be fixable.

[Bug c++/107065] GCC treats rvalue as an lvalue

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug c++/107065] GCC treats rvalue as an lvalue

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #53642|0   |1
is obsolete||

--- Comment #10 from Jakub Jelinek  ---
Created attachment 53644
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53644=edit
gcc13-pr107065.patch

Unfortunately that patch broke bootstrap, we now get an extra warning in
c-attribs.cc which has a function with nonnull(3) attribute and tests that
parameter against NULL in an assertion.

Fixing that, the patch shows quite a lot of regressions:
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++11  (test for
warnings, line 21)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++11  (test for
warnings, line 22)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++11  (test for
warnings, line 23)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++14  (test for
warnings, line 21)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++14  (test for
warnings, line 22)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++14  (test for
warnings, line 23)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++17  (test for
warnings, line 21)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++17  (test for
warnings, line 22)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++17  (test for
warnings, line 23)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++20  (test for
warnings, line 21)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++20  (test for
warnings, line 22)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++20  (test for
warnings, line 23)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++2b  (test for
warnings, line 21)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++2b  (test for
warnings, line 22)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++2b  (test for
warnings, line 23)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++98  (test for
warnings, line 21)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++98  (test for
warnings, line 22)
+FAIL: c-c++-common/Wlogical-not-parentheses-1.c  -std=gnu++98  (test for
warnings, line 23)
+FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++11  (test for
warnings, line 11)
+FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++11  expected
multiline pattern lines 13-17 not found: "\\s*r \\+= !aaa == bbb;[^\\n\\r]*\\n 
   \\^~\\n   r \\+= !aaa == bbb;[^\\n\\r]*\\n\\^~~~\\n   
\\(   \\)[^\\n\\r]*\\n"
+FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++14  (test for
warnings, line 11)
+FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++14  expected
multiline pattern lines 13-17 not found: "\\s*r \\+= !aaa == bbb;[^\\n\\r]*\\n 
   \\^~\\n   r \\+= !aaa == bbb;[^\\n\\r]*\\n\\^~~~\\n   
\\(   \\)[^\\n\\r]*\\n"
+FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++17  (test for
warnings, line 11)
+FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++17  expected
multiline pattern lines 13-17 not found: "\\s*r \\+= !aaa == bbb;[^\\n\\r]*\\n 
   \\^~\\n   r \\+= !aaa == bbb;[^\\n\\r]*\\n\\^~~~\\n   
\\(   \\)[^\\n\\r]*\\n"
+FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++20  (test for
warnings, line 11)
+FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++20  expected
multiline pattern lines 13-17 not found: "\\s*r \\+= !aaa == bbb;[^\\n\\r]*\\n 
   \\^~\\n   r \\+= !aaa == bbb;[^\\n\\r]*\\n\\^~~~\\n   
\\(   \\)[^\\n\\r]*\\n"
+FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++2b  (test for
warnings, line 11)
+FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++2b  expected
multiline pattern lines 13-17 not found: "\\s*r \\+= !aaa == bbb;[^\\n\\r]*\\n 
   \\^~\\n   r \\+= !aaa == bbb;[^\\n\\r]*\\n\\^~~~\\n   
\\(   \\)[^\\n\\r]*\\n"
+FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++98  (test for
warnings, line 11)
+FAIL: c-c++-common/Wlogical-not-parentheses-2.c  -std=gnu++98  expected
multiline pattern lines 13-17 not found: "\\s*r \\+= !aaa == bbb;[^\\n\\r]*\\n 
   \\^~\\n   r \\+= !aaa == bbb;[^\\n\\r]*\\n\\^~~~\\n   
\\(   \\)[^\\n\\r]*\\n"
+FAIL: c-c++-common/Wlogical-not-parentheses-3.c  -std=gnu++11  (test for
warnings, line 28)
+FAIL: c-c++-common/Wlogical-not-parentheses-3.c  -std=gnu++14  (test for
warnings, line 28)
+FAIL: c-c++-common/Wlogical-not-parentheses-3.c  -std=gnu++17  (test for
warnings, line 28)
+FAIL: c-c++-common/Wlogical-not-parentheses-3.c  -std=gnu++20  (test for
warnings, line 28)
+FAIL: c-c++-common/Wlogical-not-parentheses-3.c  -std=gnu++2b  (test for
warnings, line 28)
+FAIL: c-c++-common/Wlogical-not-parentheses-3.c  -std=gnu++98 

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

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

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

--- Comment #19 from Alexander Monakov  ---
(In reply to rguent...@suse.de from comment #18)
> True - but does that catch the cases people are interested and are
> allowed by the FP contraction rules?  I'm thinking of
> 
>  x = a*b + c*d + e + f;
> 
> with -fassociative-math we can form two FMAs here?

Yes; it might be reasonable to limit the match.pd rule to
-fno-associative-math, leaving mul/adds as-is for tree-ssa-math-opts to
recombine otherwise.

>  Of course with
> strict IEEE compliance but allowed FP contraction we can only
> do FMA (a, b, c*d) + e + f, right?

I think so.

>  Does that mean -ffp-contract=on
> only makes sense in absence of any other -ffast-math flags?

Well, the proposal was to make -ffp-contract=fast an '-ffast-math' flag, not
=on. I don't want to judge if '-ffp-contract=on -ffast-math' combination is
reasonable or not, because -ffast-math by itself quite nonsensical already.