[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

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

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

--- Comment #6 from Kewen Lin  ---
(In reply to rguent...@suse.de from comment #5)
> On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
> 
> I think apart from the consideration what a single element vector
> is compared to a scalar, a more to-the-point fix is
> 
>   if (VECTOR_TYPE_P (ltype)
>   && memory_access_type != VMAT_ELEMENTWISE)

Thanks for the suggestion! I thought checking lnel can also cover
VMAT_STRIDED_SLP's special case having const_nunits 1, but it seems impossible
to have?  Then it's more clear with explicit VMAT_ELEMENTWISE checking.

[Bug c++/110798] New: The reusult of sizeof operator followed with an 'unsigned typedef-ed generic integer' type is alway 4 bytes（except char）

[13958014620 at 139 dot com via Gcc-bugs]

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

Bug ID: 110798
   Summary: The reusult of sizeof operator followed with an
'unsigned typedef-ed generic integer' type is alway 4
bytes（except char）
   Product: gcc
   Version: og12 (devel/omp/gcc-12)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 13958014620 at 139 dot com
  Target Milestone: ---

Some issues arised when doing some tests.
The reusult of sizeof operator followed with an 'unsigned typedef-ed generic
integer' type is always 4 bytes（except char）.

The following example had run in fedora 37 OS with gcc_12.3.1 and
gcc_13.1.0(compiled myself), both versions of gcc show the same issue.


#include 
int main(int argc, char ** argv){
int ret=0;

typedef char ch_t;
assert( sizeof(unsigned char) == 1); //right
assert( sizeof(ch_t) == 1 ); //right
assert( sizeof(unsigned ch_t) == 1); //the only one right

typedef signed char sch;
assert( sizeof(unsigned char) == 1); //right
assert( sizeof(sch) == 1 ); //right
assert( sizeof(unsigned sch) == 4); //wrong, which should be 1

typedef short sint;
assert( sizeof(unsigned short) == 2 ); //right
assert( sizeof(sint) == 2 ); //right
assert( sizeof(unsigned sint) == 4); //wrong, which should be 8

typedef long lint;
assert( sizeof(unsigned long) == 8); //right
assert( sizeof(lint) == 8 ); //right
assert( sizeof(unsigned lint) == 4); //wrong, which should be 8

typedef long long llint;
assert( sizeof(unsigned long long) == 8); //right
assert( sizeof(llint) == 8 ); //right
assert( sizeof(unsigned llint) ==4); //wrong, which should be 8

/* The same errors as: 
   'typedef signed short ssint', 
   'typedef signed long slint', 
   'typedef signed long long sllint', 
   'typedef unsigned short usint', 
   'typedef unsigned long ulint', 
   'typedef unsigned long long ullint', 
so that seems all sizeof(unsigned ) == 4, 
except typedef char ch_t;
*/
return ret;
}
--- or a version outputting the result on the terminal --

#include 
#include 
using namespace std;
int main(int argc, char ** argv){
int ret=0;

typedef char ch_t;
cout << "typedef char ch_t;"<) == 4,
\n\
except typedef char ch_t;" << endl;
return ret;
}

These issues can't reproduce in pure C language with GCC 12 and 13.

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #5 from rguenther at suse dot de  ---
On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
> 
> Kewen Lin  changed:
> 
>What|Removed |Added
> 
>  CC||rguenth at gcc dot gnu.org
> 
> --- Comment #3 from Kewen Lin  ---
> The failure exposed one special case: there is one stmt 
> 
> # VUSE <.MEM_404>
> _15 = *_14;
> 
> its STMT_VINFO_STRIDED_P (stmt_info) is set, memory_access_type is
> VMAT_ELEMENTWISE and alignment_support_scheme is dr_unaligned_supported, its
> vector type is "vector(1) long int", so in the handling it's taken as:
> 
>   /* Load vector(1) scalar_type if it's 1 element-wise vectype.  */
>   else if (nloads == 1)
> ltype = vectype;
> 
> as its ltype is vector type, we cost it with 
> 
>   if (VECTOR_TYPE_P (ltype))
> vect_get_load_cost (vinfo, stmt_info, 1,
> alignment_support_scheme, 
> misalignment,
> false, &inside_cost, nullptr, 
> cost_vec,
> cost_vec, true);
> 
> as it's dr_unaligned_supported, it's costed as unaligned_load then causes the
> ICE. One idea is to teach rs6000_builtin_vectorization_cost about one single
> lane vector unaligned load as scalar_load. But I think it's simple to treat
> single lane vector load as scalar_load, as I expect veclower will lower it
> later.
> 
> diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
> index 4622d6a04ef..bdf4c12cd03 100644
> --- a/gcc/tree-vect-stmts.cc
> +++ b/gcc/tree-vect-stmts.cc
> @@ -9985,7 +9985,9 @@ vectorizable_load (vec_info *vinfo,
>  {
>if (costing_p)
>  {
> -  if (VECTOR_TYPE_P (ltype))
> +  /* For a single lane vector type, we should cost it as
> + scalar_load to avoid ICE, see PR110776.  */
> +  if (VECTOR_TYPE_P (ltype) && lnel > 1)
>  vect_get_load_cost (vinfo, stmt_info, 1,
>  alignment_support_scheme,
> misalignment,
>  false, &inside_cost, nullptr,
> cost_vec,
> 
> Hi Richi, what do you think of this?

I think apart from the consideration what a single element vector
is compared to a scalar, a more to-the-point fix is

  if (VECTOR_TYPE_P (ltype)
  && memory_access_type != VMAT_ELEMENTWISE)

[Bug c++/110797] New: GCC rejects std::template same_as form

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 110797
   Summary: GCC rejects std::template same_as form
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

#include 

[[maybe_unused]] std::template same_as auto i = 0;

I accidentally found that GCC rejected the above code, not sure if this is
valid code.

https://godbolt.org/z/edd6zx5df

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

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

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

Kewen Lin  changed:

   What|Removed |Added

 Target|powerpc-darwin  |powerpc-darwin,
   ||powerpc64-linux

--- Comment #4 from Kewen Lin  ---
When cooking a patch, I reduced the preprocessed file into:

int a;
long *b;
int c() {
  long e;
  int d = 0;
  for (long f; f; f++) {
e = b[f * a];
if (e)
  d = 1;
  }
  if (d)
for (;;)
  ;
}

and found the ICE can be reproduced on powerpc64 with -O2 -mcpu=power6
-maltivec.

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Kewen Lin  ---
The failure exposed one special case: there is one stmt 

# VUSE <.MEM_404>
_15 = *_14;

its STMT_VINFO_STRIDED_P (stmt_info) is set, memory_access_type is
VMAT_ELEMENTWISE and alignment_support_scheme is dr_unaligned_supported, its
vector type is "vector(1) long int", so in the handling it's taken as:

  /* Load vector(1) scalar_type if it's 1 element-wise vectype.  */
  else if (nloads == 1)
ltype = vectype;

as its ltype is vector type, we cost it with 

  if (VECTOR_TYPE_P (ltype))
vect_get_load_cost (vinfo, stmt_info, 1,
alignment_support_scheme, misalignment,
false, &inside_cost, nullptr, cost_vec,
cost_vec, true);

as it's dr_unaligned_supported, it's costed as unaligned_load then causes the
ICE. One idea is to teach rs6000_builtin_vectorization_cost about one single
lane vector unaligned load as scalar_load. But I think it's simple to treat
single lane vector load as scalar_load, as I expect veclower will lower it
later.

diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 4622d6a04ef..bdf4c12cd03 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -9985,7 +9985,9 @@ vectorizable_load (vec_info *vinfo,
 {
   if (costing_p)
 {
-  if (VECTOR_TYPE_P (ltype))
+  /* For a single lane vector type, we should cost it as
+ scalar_load to avoid ICE, see PR110776.  */
+  if (VECTOR_TYPE_P (ltype) && lnel > 1)
 vect_get_load_cost (vinfo, stmt_info, 1,
 alignment_support_scheme,
misalignment,
 false, &inside_cost, nullptr,
cost_vec,

Hi Richi, what do you think of this?

[Bug target/103605] [PowerPC] fmin/fmax should be inlined always with xsmindp/xsmaxdp

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by HaoChen Gui :

https://gcc.gnu.org/g:54ce3cbd285d453b954c281bb3ad38bee2f65330

commit r14-2758-g54ce3cbd285d453b954c281bb3ad38bee2f65330
Author: Haochen Gui 
Date:   Tue Jul 25 10:40:37 2023 +0800

rs6000: Implemented f[min/max]_optab by xs[min/max]dp

gcc/
PR target/103605
* config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_builtin):
Gimple
fold RS6000_BIF_XSMINDP and RS6000_BIF_XSMAXDP when fast-math is
set.
* config/rs6000/rs6000.md (FMINMAX): New int iterator.
(minmax_op): New int attribute.
(UNSPEC_FMAX, UNSPEC_FMIN): New unspecs.
(f3): New pattern by UNSPEC_FMAX and UNSPEC_FMIN.
* config/rs6000/rs6000-builtins.def (__builtin_vsx_xsmaxdp): Set
pattern to fmaxdf3.
(__builtin_vsx_xsmindp): Set pattern to fmindf3.

gcc/testsuite/
PR target/103605
* gcc.target/powerpc/pr103605.h: New.
* gcc.target/powerpc/pr103605-1.c: New.
* gcc.target/powerpc/pr103605-2.c: New.

[Bug modula2/110174] Using illegal constraints for builtin return_address gives ICE

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

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

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

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

commit r14-2757-gc4637cbed3f23095b98962b41063380c4ab9eda9
Author: Gaius Mulley 
Date:   Tue Jul 25 03:21:12 2023 +0100

PR modula2/110174 Bugfixes to M2GenGCC.mod:CodeInline preventing an ICE

This patch calls skip_const_decl before chaining parameter values and
ensures that all strings passed to build_stmt (..., ASM_EXPR, ...) are
nul terminated.  It also improves the accuracy of locations in
function calls and asm statements.

gcc/m2/

PR modula2/110174
* gm2-compiler/M2GCCDeclare.def (PromoteToCString): New procedure
function.
* gm2-compiler/M2GCCDeclare.mod (PromoteToCString): New procedure
function.
* gm2-compiler/M2GenGCC.mod (BuildTreeFromInterface): Call
skip_const_decl before chaining the parameter value.
Use PromoteToCString to ensure the string is nul terminated.
(CodeInline): Remove all parameters and replace with quad.
Use GetQuadOtok to get operand token numbers.
Remove call to DeclareConstant and replace it with
PromoteToCString.
* gm2-compiler/M2Quads.def (BuildInline): Rename into ...
(BuildAsm): ... this.
* gm2-compiler/M2Quads.mod: (BuildInline): Rename into ...
(BuildAsm): ... this.
(BuildAsmElement): Add debugging.
* gm2-compiler/P1Build.bnf: Remove import of BuildInline.
* gm2-compiler/P2Build.bnf: Remove import of BuildInline.
* gm2-compiler/P3Build.bnf: Remove import of BuildInline and
import BuildAsm.
* gm2-compiler/PHBuild.bnf: Remove import of BuildInline.
* gm2-libs-iso/SysClock.mod (foo): Remove.
* gm2-libs/FIO.mod (BufferedRead): Rename parameter a to dest.
Rename variable t to src.
* m2pp.cc (pf): Correct block comment.
(pe): Correct block comment.
(m2pp_asm_expr): New function.
(m2pp_statement): Call m2pp_asm_expr.

gcc/testsuite/

PR modula2/110174
* gm2/pim/pass/program2.mod: Remove import of BuildInline.
* gm2/extensions/asm/fail/extensions-asm-fail.exp: New test.
* gm2/extensions/asm/fail/stressreturn.mod: New test.
* gm2/extensions/asm/pass/extensions-asm-pass.exp: New test.
* gm2/extensions/asm/pass/fooasm.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug tree-optimization/93044] extra cast is not removed

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

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

--- Comment #6 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625379.html

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

--- Comment #2 from Thiago Jung Bauermann  
---
Thanks for the quick response!

(In reply to Andrew Pinski from comment #1)
> Does pr91323.c fail on arm?

No, all its tests pass:

PASS: gcc.dg/torture/pr91323.c   -O0  (test for excess errors)
PASS: gcc.dg/torture/pr91323.c   -O0  execution test
PASS: gcc.dg/torture/pr91323.c   -O1  (test for excess errors)
PASS: gcc.dg/torture/pr91323.c   -O1  execution test
PASS: gcc.dg/torture/pr91323.c   -O2  (test for excess errors)
PASS: gcc.dg/torture/pr91323.c   -O2  execution test
PASS: gcc.dg/torture/pr91323.c   -O3 -g  (test for excess errors)
PASS: gcc.dg/torture/pr91323.c   -O3 -g  execution test
PASS: gcc.dg/torture/pr91323.c   -Os  (test for excess errors)
PASS: gcc.dg/torture/pr91323.c   -Os  execution test
PASS: gcc.dg/torture/pr91323.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
PASS: gcc.dg/torture/pr91323.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
PASS: gcc.dg/torture/pr91323.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
PASS: gcc.dg/torture/pr91323.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

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

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

--- Comment #1 from Andrew Pinski  ---
Does pr91323.c fail on arm?

[Bug middle-end/110796] New: builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

Bug ID: 110796
   Summary: builtin_iseqsig fails some tests in
armv8l-linux-gnueabihf
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago.bauermann at linaro dot org
CC: fxcoudert at gcc dot gnu.org
  Target Milestone: ---
Target: armv8l-unknown-linux-gnueabihf

Commit 34cf27a64e7a "Add __builtin_iseqsig()" introduced the mentioned builtin
along with some new tests. Unfortunately they have some failures in
armv8l-linux-gnueabihf:

Running gcc:gcc.dg/torture/dg-torture.exp ...
FAIL: gcc.dg/torture/builtin-iseqsig-1.c -Os  execution test
FAIL: gcc.dg/torture/builtin-iseqsig-2.c -Os  execution test
FAIL: gcc.dg/torture/builtin-iseqsig-3.c -Os  execution test

gcc.log doesn't have any hint on what actually went wrong. E.g.:

Executing on host:
/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/xgcc
-B/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/
/home/thiago.bauermann/src/gcc/gcc/testsuite/gcc.dg/torture/builtin-iseqsig-1.c
   -fdiagnostics-plain-output-Os  -fsignaling-nans  -lm  -o
./builtin-iseqsig-1.exe(timeout = 300)
spawn -ignore SIGHUP
/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/xgcc
-B/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/
/home/thiago.bauermann/src/gcc/gcc/testsuite/gcc.dg/torture/builtin-iseqsig-1.c
-fdiagnostics-plain-output -Os -fsignaling-nans -lm -o ./builtin-iseqsig-1.exe
PASS: gcc.dg/torture/builtin-iseqsig-1.c   -Os  (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc::/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc
Execution timeout is: 300
spawn [open ...]
FAIL: gcc.dg/torture/builtin-iseqsig-1.c   -Os  execution test

The problem is still present in trunk as of commit 2a3556376c69 "match.pd:
Implement missed optimization (~X | Y) ^ X -> ~(X & Y) [PR109986]" from today.

Reproduced on Ubuntu 22.04 with:

$ ~/src/gcc/configure \
  --disable-bootstrap \
  --disable-multilib \
  --with-mode=thumb \
  --with-arch=armv8-a \
  --with-float=hard \
  --with-fpu=neon-fp-armv8 \
  && make -j 60 \
  && make -C gcc check-c RUNTESTFLAGS=gcc.dg/torture/dg-torture.exp

[Bug target/110795] Bad code gen for vector compare booleans

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

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

--- Comment #2 from Steven Munroe  ---
Also fails with gcc11/12. Also fails with Advance Toolchain 10.0 GCC 6.4.1.

It might fail for all version between GCC 6 and 13.

[Bug target/110795] Bad code gen for vector compare booleans

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

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

--- Comment #1 from Steven Munroe  ---
Created attachment 55627
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55627&action=edit
Main and unit-test. When compiled and linked with vec_divide.c will verify if
the divide code is correct or not.

[Bug c/110795] New: Bad code gen for vector compare booleans

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

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

Bug ID: 110795
   Summary: Bad code gen for vector compare booleans
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: munroesj at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55626
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55626&action=edit
Test examples for vector code combinining vector compare combined with logical
or,

Combining a vec_cmplt and vec_cmpge with vector logical OR misscompiles.
For example:
  // Capture the carry t as a bool using signed compare
  t = vec_cmplt ((vi32_t) x, zeros);
  ge = vec_cmpge (x, z);
  // Combine t with (x >= z) for 33-bit compare
  t  = vec_or (ge, t);

This seems to work for the minimized example above but fails when used in the
more complex loop of the example vec_divduw_V1. At -O3 the compiler elides any
code generated for vec_cmplt.

With this bug the function vec_divduw_V1 (Vector_Divide double (words by)
unsigned word) fails the unit test.

[Bug middle-end/71065] Missing diagnostic for statements between OpenMP 'target' and 'teams'

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

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

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

https://gcc.gnu.org/g:2e31fe431b08b0302e1fa8a1c18ee51adafd41df

commit r14-2754-g2e31fe431b08b0302e1fa8a1c18ee51adafd41df
Author: Tobias Burnus 
Date:   Mon Jul 24 22:57:07 2023 +0200

OpenMP/Fortran: Reject not strictly nested target -> teams [PR110725,
PR71065]

OpenMP requires: "If a teams region is nested inside a target region, the
corresponding target construct must not contain any statements,
declarations
or directives outside of the corresponding teams construct."

This commit checks now for this restriction.

PR fortran/110725
PR middle-end/71065

gcc/fortran/ChangeLog:

* gfortran.h (gfc_omp_clauses): Add contains_teams_construct.
* openmp.cc (resolve_omp_target): New; check for teams nesting.
(gfc_resolve_omp_directive): Call it.
* parse.cc (decode_omp_directive): Set contains_teams_construct
on enclosing ST_OMP_TARGET.

gcc/testsuite/ChangeLog:

* gfortran.dg/gomp/pr99226.f90: Update dg-error.
* gfortran.dg/gomp/teams-5.f90: New test.

[Bug fortran/110725] [13/14 Regression] internal compiler error: in expand_expr_real_1, at expr.cc:10897

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

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

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

https://gcc.gnu.org/g:2e31fe431b08b0302e1fa8a1c18ee51adafd41df

commit r14-2754-g2e31fe431b08b0302e1fa8a1c18ee51adafd41df
Author: Tobias Burnus 
Date:   Mon Jul 24 22:57:07 2023 +0200

OpenMP/Fortran: Reject not strictly nested target -> teams [PR110725,
PR71065]

OpenMP requires: "If a teams region is nested inside a target region, the
corresponding target construct must not contain any statements,
declarations
or directives outside of the corresponding teams construct."

This commit checks now for this restriction.

PR fortran/110725
PR middle-end/71065

gcc/fortran/ChangeLog:

* gfortran.h (gfc_omp_clauses): Add contains_teams_construct.
* openmp.cc (resolve_omp_target): New; check for teams nesting.
(gfc_resolve_omp_directive): Call it.
* parse.cc (decode_omp_directive): Set contains_teams_construct
on enclosing ST_OMP_TARGET.

gcc/testsuite/ChangeLog:

* gfortran.dg/gomp/pr99226.f90: Update dg-error.
* gfortran.dg/gomp/teams-5.f90: New test.

[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs

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

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

--- Comment #22 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:31c3b67dfc6e67773d13260bc38b833663698b74

commit r14-2753-g31c3b67dfc6e67773d13260bc38b833663698b74
Author: Jonathan Wakely 
Date:   Mon Jul 24 11:45:43 2023 +0100

libstdc++; Do not use strtold for hppa-hpux [PR110653]

When I switched std::stold to depend on HAVE_STRTOLD that enabled it for
hppa-hpux which defines HAVE_BROKEN_STRTOLD. Add a check for that macro
so that we don't use strtold, and fall through to the check for double
and long double having the same representation. That should mean we
define a conforming std::stold in terms of std::stod, instead of trying
to use the broken strtold.

Also fix a logic error in the fallback definition of std::stod, which
should not treat zero as a subnormal number.

libstdc++-v3/ChangeLog:

PR libstdc++/110653
* include/bits/basic_string.h [!HAVE_STOF] (stof): Do not
throw an exception for zero result.
[HAVE_BROKEN_STRTOLD] (stold): Do not use strtold.

[Bug modula2/110174] Using illegal constraints for builtin return_address gives ICE

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

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

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

Here is a patch for gcc-14 which exhibits the same bug.  Will apply to git once
a full bootstrap has successfully completed.  I'll also back port this bugfix.

[Bug tree-optimization/110794] New: FAIL: g++.dg/pr99966.C -std=gnu++17 scan-tree-dump-not vrp1 "throw"

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

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

Bug ID: 110794
   Summary: FAIL: g++.dg/pr99966.C  -std=gnu++17
scan-tree-dump-not vrp1 "throw"
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

Created attachment 55624
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55624&action=edit
vrp1 tree dump

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../xg++
-B
/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../
/home/dave/gnu/gcc/gcc/gcc/
testsuite/g++.dg/pr99966.C -fdiagnostics-plain-output -nostdinc++
-I/home/dave/g
nu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/
home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave
/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/includ
e/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util
-fmessage-length
=0 -std=gnu++17 -O2 -fdump-tree-vrp1 -S -o pr99966.s
PASS: g++.dg/pr99966.C  -std=gnu++17 (test for excess errors)
FAIL: g++.dg/pr99966.C  -std=gnu++17  scan-tree-dump-not vrp1 "throw"

[Bug tree-optimization/110780] aarch64 NEON redundant displaced ld3

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
I guess the problem is that we can only remove the “redundant” loads once we've
added the versioning check between pBE and pCSI2.  We could remove the
redundancy after vectorisation, but it would be nice to do it during, not least
because it might improve costing.

Richard, do you remember an earlier PR for something similar?

We do remove the redundancy if the pointers are marked restrict.

[Bug target/110792] [13/14 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #9)
> Created attachment 55623 [details]
> x86_64 testcase
> 
> Here is a x86_64 testcase which shows the issue is not just with i686 but
> also with int128 and x86_64 too.

Note this started with r13-1907-g525a1a73a5a563 (rather than
r13-1362-g00193676a5a3e7 ) But both patterns have the same issue and should be
both fixed rather than just one or the other.

[Bug target/110792] [13/14 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function

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

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

--- Comment #9 from Andrew Pinski  ---
Created attachment 55623
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55623&action=edit
x86_64 testcase

Here is a x86_64 testcase which shows the issue is not just with i686 but also
with int128 and x86_64 too.

[Bug tree-optimization/110755] [13/14 Regression] Wrong optimization of fabs on ppc64el at -O1

[aurelien at aurel32 dot net via Gcc-bugs]

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

--- Comment #10 from Aurelien Jarno  ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 55616 [details]
> gcc14-pr110755.patch
> 
> Updated patch.

Thanks. I have just tested it, and I confirm it fixes the reported issue.

[Bug libstdc++/70472] is_copy_constructible>>::value is true

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #14 from Arthur O'Dwyer  ---
> The problem is that std::vector does have a copy constructor, so the trait 
> value is true, but instantiating that constructor produces an error when the 
> value_type is not copyable.

Worse, the value_type can be incomplete, as in

struct Node {
  std::vector children_;
};

Askar: see
https://quuxplusone.github.io/blog/2020/02/05/vector-is-copyable-except-when-its-not/
I suggest closing this bug report as Not A Bug. It certainly shouldn't be
tagged `wrong-code`.

[Bug target/110792] [13/14 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> Created attachment 55622 [details]
> Reduced C testcase
> 
> This reduces the previous testcase and forces the overlap ...

Oh and changed it to be able to compile with the C front-end and not just the
C++ front-end.

[Bug target/110792] [13/14 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #55620|0   |1
is obsolete||

--- Comment #7 from Andrew Pinski  ---
Created attachment 55622
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55622&action=edit
Reduced C testcase

This reduces the previous testcase and forces the overlap ...

[Bug target/110792] [13/14 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com
   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=109109|

--- Comment #6 from Andrew Pinski  ---
I am almost positive it started with r13-1362-g00193676a5a3e7 which forgot to
check to see the memory operand overlaps (refers to) with the destination
register.

[Bug target/110792] [13/14 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function

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

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

--- Comment #5 from Andrew Pinski  ---
When this is split:
(insn 12 11 18 2 (set (reg:DI 0 ax [87])
(rotate:DI (mem:DI (plus:SI (mult:SI (reg:SI 0 ax [orig:89 x0 ] [89])
(const_int 8 [0x8]))
(symbol_ref:SI ("WHIRL_S") [flags 0x2]  )) [1 WHIRL_S[_1]+0 S8 A64])
(const_int 32 [0x20]))) "/app/example.cpp":4:75 971
{rotl32di2_doubleword}
 (nil))

It gets split incorrectly into:
(insn 21 11 22 2 (set (reg:SI 0 ax [87])
(mem:SI (plus:SI (mult:SI (reg:SI 0 ax [orig:89 x0 ] [89])
(const_int 8 [0x8]))
(const:SI (plus:SI (symbol_ref:SI ("WHIRL_S") [flags 0x2] 
)
(const_int 4 [0x4] [1 WHIRL_S[_1]+4 S4 A32]))
"/app/example.cpp":4:75 91 {*movsi_internal}
 (nil))
(insn 22 21 18 2 (set (reg:SI 1 dx [+4 ])
(mem:SI (plus:SI (mult:SI (reg:SI 0 ax [orig:89 x0 ] [89])
(const_int 8 [0x8]))
(symbol_ref:SI ("WHIRL_S") [flags 0x2]  )) [1 WHIRL_S[_1]+0 S4 A64])) "/app/example.cpp":4:75 91
{*movsi_internal}
 (nil))

Basically ax set before its use in the memory ...

[Bug target/110792] [13/14 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 55621
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55621&action=edit
almost reduced all the way

[Bug target/110792] [13/14 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function

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

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

--- Comment #3 from Andrew Pinski  ---
Created attachment 55620
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55620&action=edit
semi-reduced testcase

Here is a reduced testcase which also fails on the trunk.

[Bug target/110792] [13 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function

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

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

--- Comment #2 from Andrew Pinski  ---
It seems like it is one of these which is causing the miscompile:
   const uint64_t s0 = WHIRL_S[get_byte<0>(x0)];
   const uint64_t s1 = WHIRL_S[get_byte<1>(x1)];
   const uint64_t s2 = WHIRL_S[get_byte<2>(x2)];
   const uint64_t s3 = WHIRL_S[get_byte<3>(x3)];
   const uint64_t s4 = WHIRL_S[get_byte<4>(x4)];
   const uint64_t s5 = WHIRL_S[get_byte<5>(x5)];
   const uint64_t s6 = WHIRL_S[get_byte<6>(x6)];
   const uint64_t s7 = WHIRL_S[get_byte<7>(x7)];


not inlining get_byte (via gnu::noinline) allows it to run without a seg fault.

[Bug target/110792] [13 Regregression] GCC 13 x86_32 miscompilation of Whirlpool hash function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.2
  Known to work||12.3.0
Summary|GCC 13 x86_32   |[13 Regregression] GCC 13
   |miscompilation of Whirlpool |x86_32 miscompilation of
   |hash function   |Whirlpool hash function

[Bug fortran/87326] [F18] Support the NEW_INDEX= specifier in the FORM TEAM statement

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Brad Richardson from comment #3)
> Was there any more progress on this? I've just run into it.
> 
> FYI I'm trying implement a polymorphic send/receive:
> https://gitlab.com/everythingfunctional/communicator

Unfortunately, no.  gfortran depends on opencoarray for its library support for
coarray Fortran.  Much of the work has been contributed by individuals funded
through the Sourcery Institute (i.e., Damian's organization).  He's turned his
interests towards caffeine (https://github.com/berkeleylab/caffeine).

[Bug tree-optimization/109938] ((a^c) & b) | a is not opimized to (b & c) | a

[drross at redhat dot com via Gcc-bugs]

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

Drew Ross  changed:

   What|Removed |Added

 CC||drross at redhat dot com

--- Comment #2 from Drew Ross  ---
Expanding the pattern as follows: ((a^c) & b) | a --> (a | (a^c)) & (a | b)
allows  other patterns to make the simplification. Namely (a | (a^c)) -> a | c,
then
(a | c) & (a | b) -> a | (b & c). 

This type of expansion also generalizes nicely to patterns like ((a^c) | b) | a
-> a | b | c which can be done through a similar series of simplifications
after expanding the initial.

This brings up the infrastructure question for 3+ operators if it is worth it
to try all (or maybe most?) pairwise simplifications (for instance even in the
case of (a ^ c) | b | d | e | f | g | h | a).

Thoughts?

[Bug c/110789] Internal Compiler Error: Illegal instruction

[pledr at gmx dot net via Gcc-bugs]

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

--- Comment #5 from Peter Lezoch  ---
I built a new gcc with --disable-avx2:

bash-5.2# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr --disable-avx2
--enable-multilib --with-multili
b-list=m64,m32,mx32 --with-system-zlib --enable-default-pie
--enable-default-ssp --with-lon
g-double-128 --enable-languages=c,c++,fortran
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC)
bash-5.2#

BUT: get the same internal error

     ==>> no improvement !!!


On 2023-07-24 10:55, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110789
>
> Andrew Pinski  changed:
>
> What|Removed |Added
> 
>   Status|UNCONFIRMED |WAITING
>   Ever confirmed|0   |1
> Last reconfirmed||2023-07-24
>
> --- Comment #1 from Andrew Pinski  ---
> How did you configure gcc?
>
> I suspect the issue is you compiled gcc to only run on the first machine which
> has avx2 while the second one does not.
>

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

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

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

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

https://gcc.gnu.org/g:2a3556376c69a1fb588dcf25225950575e42784f

commit r14-2751-g2a3556376c69a1fb588dcf25225950575e42784f
Author: Drew Ross 
Date:   Mon Jul 24 17:51:28 2023 +0200

match.pd: Implement missed optimization (~X | Y) ^ X -> ~(X & Y) [PR109986]

Adds a simplification for (~X | Y) ^ X to be folded into ~(X & Y).
Also adds the macro bitwise_equal_p for generic and gimple which
returns true iff EXPR1 and EXPR2 have the same value. This helps
to reduce the number of nop_converts necessary to match the pattern.

PR middle-end/109986

gcc/ChangeLog:

* generic-match-head.cc (bitwise_equal_p): New macro.
* gimple-match-head.cc (bitwise_equal_p): New macro.
(gimple_nop_convert): Declare.
(gimple_bitwise_equal_p): Helper for bitwise_equal_p.
* match.pd ((~X | Y) ^ X -> ~(X & Y)): New simplification.

gcc/testsuite/ChangeLog:

* gcc.c-torture/execute/pr109986.c: New test.
* gcc.dg/tree-ssa/pr109986.c: New test.

Co-authored-by: Jakub Jelinek 

[Bug middle-end/110791] [12/13/14 Regression] arm: Wrong code with -Os -march=armv8.1-m.main

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

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

Wilco  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Component|rtl-optimization|middle-end
 Status|UNCONFIRMED |NEW

--- Comment #6 from Wilco  ---
(In reply to Alex Coplan from comment #5)
> Thanks Wilco for the simpler example.
> 
> It seems to have started with
> r13-1268-g8c99e307b20c502e55c425897fb3884ba8f05882 with both of these
> testcases, but it's probably a latent issue elsewhere (since it doesn't seem
> to show up on other targets). Needs more analysis.

The bug happens on all targets with -fmodulo-sched -Os, eg. AArch64:

bug:
sub x2, x1, x0
add x2, x2, 1
cmp x0, x1
bhi .L7
cmn x0, #1
bne .L9
.L7:
mov x2, 1
.L9:
subsx2, x2, #1
beq .L1
ldrbw0, [x1, -1]
cmp w0, 47
beq .L6
.L1:
ret
.L6:
sub x1, x1, #1
b   .L9

[Bug c/110789] Internal Compiler Error: Illegal instruction

[pledr at gmx dot net via Gcc-bugs]

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

--- Comment #4 from Peter Lezoch  ---
I have a complete buildLog and there is NO  -march=native

I'm just rebuilding now with --disable-avx2

Have to build on R9 because on Zeut gcc reports 'internal error' again !!!





On 2023-07-24 11:04, arsen at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110789
>
> Arsen Arsenović  changed:
>
> What|Removed |Added
> 
>   CC||arsen at gcc dot gnu.org
>
> --- Comment #3 from Arsen Arsenović  ---
> did you happen to se -march=native in CFLAGS or such when building gcc?
>

[Bug fortran/110725] [13/14 Regression] internal compiler error: in expand_expr_real_1, at expr.cc:10897

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
This is certainly accepts-invalid if it is accepted.
E.g. OpenMP 5.0 says on this in 2.20, 5.1 in
https://www.openmp.org/spec-html/5.1/openmpse30.html#x155-1880002.22
"If a teams construct is nested within a target construct, that target
construct must contain no statements, declarations or directives outside of the
teams construct."
Though, diagnosing this is hard, because e.g. parsing of teams construct's
clauses can result in some code in between the target and teams nested in it,
and that is valid.
I mean say
int foo (void) { return 42; }
#pragma omp declare target (foo)

int
main ()
{
#pragma omp target
#pragma omp teams num_teams (foo ())
;
}

[Bug ipa/110793] regression in optimizing unused string

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> For all optimization levels.

I mean for all C++ standards.

[Bug ipa/110793] regression in optimizing unused string

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Actually this is more likely inlining heuristics that know that main is only
> called once ever and does not inline as much into it.
> 
> Try renaming main to foo and try again b

Yes it is this heurstic.
Renaming main to foo produces:
foo():
.LFB1395:
.cfi_startproc
xorl%eax, %eax
ret

For all optimization levels.

[Bug fortran/87326] [F18] Support the NEW_INDEX= specifier in the FORM TEAM statement

[everythingfunctional at protonmail dot com via Gcc-bugs]

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

Brad Richardson  changed:

   What|Removed |Added

 CC||everythingfunctional@proton
   ||mail.com

--- Comment #3 from Brad Richardson  ---
Was there any more progress on this? I've just run into it.

FYI I'm trying implement a polymorphic send/receive:
https://gitlab.com/everythingfunctional/communicator

[Bug ipa/110793] regression in optimizing unused string

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
  Component|c++ |ipa

--- Comment #2 from Andrew Pinski  ---
Actually this is more likely inlining heuristics that know that main is only
called once ever and does not inline as much into it.

Try renaming main to foo and try again b

[Bug rtl-optimization/110791] [12/13/14 Regression] arm: Wrong code with -Os -march=armv8.1-m.main

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

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

Alex Coplan  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #5 from Alex Coplan  ---
Thanks Wilco for the simpler example.

It seems to have started with
r13-1268-g8c99e307b20c502e55c425897fb3884ba8f05882 with both of these
testcases, but it's probably a latent issue elsewhere (since it doesn't seem to
show up on other targets). Needs more analysis.

[Bug c++/110793] regression in optimizing unused string

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Barry Revzin from comment #0)
> Notably, 13.1 C++20 and C++23 also compiles to just xor. 
> 

Probably because we don't use the extern template declarations for C++20.

[Bug c++/110793] New: regression in optimizing unused string

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 110793
   Summary: regression in optimizing unused string
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider this reduced, silly-looking example:

#include 

inline int zero(std::string const& = {}) { return 0; }

int main() {
return zero();
}

In several versions of gcc (12.2, 11.4, 10.5), this simply compiles to:

main:
xor eax, eax
ret

But in 13.1 (C++17, but not C++20), we get:

main:
sub rsp, 40
lea rax, [rsp+16]
mov rdi, rsp
mov BYTE PTR [rsp+16], 0
mov QWORD PTR [rsp], rax
mov QWORD PTR [rsp+8], 0
callstd::__cxx11::basic_string,
std::allocator >::_M_dispose()
xor eax, eax
add rsp, 40
ret

Notably, 13.1 C++20 and C++23 also compiles to just xor. 

I'm not sure if this is a language or library issue, so tagging it language for
now.

[Bug target/110783] bpf; make sure of V4 signed division/modulus instructions

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

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

--- Comment #2 from Jose E. Marchesi  ---
Fixed in git master.

[Bug target/110783] bpf; make sure of V4 signed division/modulus instructions

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jose E. Marchesi :

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

commit r14-2749-g4be3919fb75e3d2a4d2bb80ba33c14e0973bc08f
Author: Jose E. Marchesi 
Date:   Mon Jul 24 15:57:05 2023 +0200

bpf: sdiv/smod are now part of BPF V4

We used to support signed division and signed modulus instructions in
the XBPF GCC-specific extensions to BPF.  However, BPF catched up by
adding these instructions in the V4 of the ISA.

This patch changes GCC in order to use sdiv/smod instructions when
-mcpu=v4 or higher.  The testsuite and the manual have been updated
accordingly.

Tested in bpf-unknown-none.

gcc/ChangeLog

PR target/110783
* config/bpf/bpf.opt: New command-line option -msdiv.
* config/bpf/bpf.md: Conditionalize sdiv/smod on bpf_has_sdiv.
* config/bpf/bpf.cc (bpf_option_override): Initialize
bpf_has_sdiv.
* doc/invoke.texi (eBPF Options): Document -msdiv.

gcc/testsuite/ChangeLog

PR target/110783
* gcc.target/bpf/xbpf-sdiv-1.c: Renamed to sdiv-1.c
* gcc.target/bpf/xbpf-smod-1.c: Renamed to smod-1.c
* gcc.target/bpf/sdiv-1.c: Renamed from xbpf-sdiv-1.c, use
-mcpu=v4.
* gcc.target/bpf/smod-1.c: Renamed from xbpf-smod-1.c, use
-mcpu=v4.
* gcc.target/bpf/diag-sdiv.c: Use -mcpu=v3.
* gcc.target/bpf/diag-smod.c: Likewise.

[Bug target/110787] [14 regression] ICE building SYSTEM.def

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/110790] [14 Regression] gcc -m32 generates invalid bit test code on gmp-6.2.1

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |14.0
   Keywords||wrong-code
 Target||i?86-*-*
 Resolution|--- |FIXED

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

[Bug rtl-optimization/110791] [12/13/14 Regression] arm: Wrong code with -Os -march=armv8.1-m.main

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.4
   Keywords||needs-bisection

[Bug target/110792] GCC 13 x86_32 miscompilation of Whirlpool hash function

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-24
   Keywords||needs-bisection
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed even without -DCAUSE_CODEGEN_BUG

Dump of assembler code for function _Z5whirl:
...
   0x0804857b <+139>:   xor%ebx,%edx
   0x0804857d <+141>:   mov0x8049604(,%ecx,8),%ecx
=> 0x08048584 <+148>:   mov0x8049600(,%ecx,8),%ebx
   0x0804858b <+155>:   xor%ecx,%eax

also faults with -O1 (but not -O0).

[Bug rtl-optimization/110791] [12/13/14 Regression] arm: Wrong code with -Os -march=armv8.1-m.main

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

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #4 from Wilco  ---
Simpler example:

void f(void);

void bug (char *path, char *p)
{
  while( p > path && p[-1] == '/' )
p--;
  if (p < path)
f();
}

bug:
subsr3, r1, r0
cmp r0, r1
add r3, r3, #1
bhi .L7
addsr0, r0, #1
bne .L5
.L7:
movsr3, #1
.L5:
subsr3, r3, #1
bne .L2
bcc .L3   ** this is obviously never taken
bx  lr
.L2:
ldrbr2, [r1, #-1]!  @ zero_extendqisi2
cmp r2, #47
beq .L5
bx  lr
.L3:
b   f

[Bug target/110792] New: GCC 13 x86_32 miscompilation of Whirlpool hash function

[lloyd at randombit dot net via Gcc-bugs]

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

Bug ID: 110792
   Summary: GCC 13 x86_32 miscompilation of Whirlpool hash
function
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lloyd at randombit dot net
  Target Milestone: ---

Created attachment 55619
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55619&action=edit
Reproducing testcase

Attached is a reproducing testcase for an apparent miscompilation bug in GCC 13
when compiling for 32-bit x86.

Upstream issue: https://github.com/randombit/botan/issues/3637

This code is the core loop of the Whirlpool hash function.

In the attachment if `CAUSE_CODEGEN_BUG` is defined then a particular function
is defined in an anonymous namespace. When that happens, GCC apparently
generates invalid code

$ g++ -O2 -std=c++20 -m32 whirl.cpp -o whirl
$ ./whirl
19FA61D75522A466 9B44E39C1D2E1726 C530232130D407F8 9AFEE0964997F7A7
3E83BE698B288FEB CF88E3E03C4F0757 EA8964E59B63D937 08B138CC42A66EB3
# above is the correct Whirlpool hash for the empty message

$ g++ -DCAUSE_CODEGEN_BUG -O2 -std=c++20 -m32 whirl.cpp -o whirl
$ ./whirl
zsh: segmentation fault  ./whirl

If compiled with Ubsan/Asan, the code is ok:

$ g++ -DCAUSE_CODEGEN_BUG -fsanitize=address -fsanitize=undefined -O2
-std=c++20 -m32 whirl.cpp -o whirl
$ ./whirl
19FA61D75522A466 9B44E39C1D2E1726 C530232130D407F8 9AFEE0964997F7A7
3E83BE698B288FEB CF88E3E03C4F0757 EA8964E59B63D937 08B138CC42A66EB3

My GCC is

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

This is the compiler from Arch Linux which is AFAIK stock GCC. The original
report related to the GCC 13 included in Alpine Edge.

[Bug target/110790] [14 Regression] gcc -m32 generates invalid bit test code on gmp-6.2.1

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

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

--- Comment #3 from Sergei Trofimovich  ---
The change fixed `gmp` and `mpfr` test suites on `i686-linux` for me. And also
a `grep` testsuite on `x86_64-linux`. Thank you!

[Bug target/110787] [14 regression] ICE building SYSTEM.def

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

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

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

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

commit r14-2743-g9f66753ef48f37729a88735ae1a2bf2d2558e69f
Author: Roger Sayle 
Date:   Mon Jul 24 12:34:23 2023 +0100

[Committed] PR target/110787: Revert QImode offsets in {zero,sign}_extract.

My recent patch to use QImode for bit offsets in ZERO_EXTRACTs and
SIGN_EXTRACTs in the i386 backend shouldn't have resulted in any change
behaviour, but as reported by Rainer it produces a bootstrap failure in
gm2.  This reverts the problematic patch whilst we investigate the
underlying cause.

Committed as obvious.

2023-07-23  Roger Sayle  

gcc/ChangeLog
PR target/110787
PR target/110790
Revert patch.
* config/i386/i386.md (extv): Use QImode for offsets.
(extzv): Likewise.
(insv): Likewise.
(*testqi_ext_3): Likewise.
(*btr_2): Likewise.
(define_split): Likewise.
(*btsq_imm): Likewise.
(*btrq_imm): Likewise.
(*btcq_imm): Likewise.
(define_peephole2 x3): Likewise.
(*bt): Likewise
(*bt_mask): New define_insn_and_split.
(*jcc_bt): Use QImode for offsets.
(*jcc_bt_1): Delete obsolete pattern.
(*jcc_bt_mask): Use QImode offsets.
(*jcc_bt_mask_1): Likewise.
(define_split): Likewise.
(*bt_setcqi): Likewise.
(*bt_setncqi): Likewise.
(*bt_setnc): Likewise.
(*bt_setncqi_2): Likewise.
(*bt_setc_mask): New define_insn_and_split.
(bmi2_bzhi_3): Use QImode offsets.
(*bmi2_bzhi_3): Likewise.
(*bmi2_bzhi_3_1): Likewise.
(*bmi2_bzhi_3_1_ccz): Likewise.
(@tbm_bextri_): Likewise.

[Bug target/110790] [14 Regression] gcc -m32 generates invalid bit test code on gmp-6.2.1

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

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

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

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

commit r14-2743-g9f66753ef48f37729a88735ae1a2bf2d2558e69f
Author: Roger Sayle 
Date:   Mon Jul 24 12:34:23 2023 +0100

[Committed] PR target/110787: Revert QImode offsets in {zero,sign}_extract.

My recent patch to use QImode for bit offsets in ZERO_EXTRACTs and
SIGN_EXTRACTs in the i386 backend shouldn't have resulted in any change
behaviour, but as reported by Rainer it produces a bootstrap failure in
gm2.  This reverts the problematic patch whilst we investigate the
underlying cause.

Committed as obvious.

2023-07-23  Roger Sayle  

gcc/ChangeLog
PR target/110787
PR target/110790
Revert patch.
* config/i386/i386.md (extv): Use QImode for offsets.
(extzv): Likewise.
(insv): Likewise.
(*testqi_ext_3): Likewise.
(*btr_2): Likewise.
(define_split): Likewise.
(*btsq_imm): Likewise.
(*btrq_imm): Likewise.
(*btcq_imm): Likewise.
(define_peephole2 x3): Likewise.
(*bt): Likewise
(*bt_mask): New define_insn_and_split.
(*jcc_bt): Use QImode for offsets.
(*jcc_bt_1): Delete obsolete pattern.
(*jcc_bt_mask): Use QImode offsets.
(*jcc_bt_mask_1): Likewise.
(define_split): Likewise.
(*bt_setcqi): Likewise.
(*bt_setncqi): Likewise.
(*bt_setnc): Likewise.
(*bt_setncqi_2): Likewise.
(*bt_setc_mask): New define_insn_and_split.
(bmi2_bzhi_3): Use QImode offsets.
(*bmi2_bzhi_3): Likewise.
(*bmi2_bzhi_3_1): Likewise.
(*bmi2_bzhi_3_1_ccz): Likewise.
(@tbm_bextri_): Likewise.

[Bug rtl-optimization/110791] [12/13/14 Regression] arm: Wrong code with -Os -march=armv8.1-m.main

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #3 from Xi Ruoyao  ---
(In reply to Alex Coplan from comment #2)
> (In reply to Xi Ruoyao from comment #1)
> > Isn't this a UB?
> > 
> >   while (p >= path && *p != '/')
> > p--;
> > 
> > This will cause p to become "&main::path[0] - 1".  C23 6.5.6p9:
> 
> In this case, with the input given in main, I think p should end up pointing
> to main::path + 1 (since we pass in main::path + 2, and foo can only ever
> decrement p at most one below its parameter path).

Sorry, I misread the code.  I guess I need to drink some coffee now...

[Bug rtl-optimization/110791] [12/13/14 Regression] arm: Wrong code with -Os -march=armv8.1-m.main

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

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

--- Comment #2 from Alex Coplan  ---
(In reply to Xi Ruoyao from comment #1)
> Isn't this a UB?
> 
>   while (p >= path && *p != '/')
> p--;
> 
> This will cause p to become "&main::path[0] - 1".  C23 6.5.6p9:

In this case, with the input given in main, I think p should end up pointing to
main::path + 1 (since we pass in main::path + 2, and foo can only ever
decrement p at most one below its parameter path).

[Bug rtl-optimization/110791] [12/13/14 Regression] arm: Wrong code with -Os -march=armv8.1-m.main

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 CC||xry111 at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-07-24

--- Comment #1 from Xi Ruoyao  ---
Isn't this a UB?

  while (p >= path && *p != '/')
p--;

This will cause p to become "&main::path[0] - 1".  C23 6.5.6p9:

If the pointer operand and the result do not point to elements of the same
array object or one past the last element of the array object, the behavior is
undefined.

[Bug rtl-optimization/110791] New: [12/13/14 Regression] arm: Wrong code with -Os -march=armv8.1-m.main

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

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

Bug ID: 110791
   Summary: [12/13/14 Regression] arm: Wrong code with -Os
-march=armv8.1-m.main
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following testcase is miscompiled since at least GCC 12 with -Os
-march=armv8.1-m.main:

void __attribute__ ((noinline))
foo (char *path, int *result)
{
  char *p = path;
  while (p >= path && *p != '/')
p--;
  while (p > path && p[-1] == '/')
p--;

  if (p < path)
*result = 1;
}

int main(void)
{
  char path[4] = "usr";
  int x = 0;
  foo (path + 2, &x);
  if (!x)
__builtin_abort ();
}

Below is the assembly we currently generate together with comments showing how
this goes wrong at runtime:

foo:
mov r3, r0 @ r3 <- (p = path)
ldrbr2, [r3], #-1  @ r2 <- *p; p--;
cmp r2, #47
it  eq
moveq   r3, r0 @ if (r2 == 47)  p <- path
subsr2, r3, r0
cmp r0, r3
add r2, r2, #1
bhi .L9@ if (path > p) goto .L9 [taken]
addsr0, r0, #1
bne .L6
.L9:
movsr2, #1
.L6:
subsr2, r2, #1 @ r2 <- 0 [fall through from above]
bne .L3@ [not taken, r2 was #1]
bcc .L4@ [not taken]
bx  lr @ [return without setting *result = 1]
.L3:
ldrbr0, [r3, #-1]!
cmp r0, #47
beq .L6
bx  lr
.L4:
movsr3, #1
str r3, [r1]
bx  lr

At -O2 the code is both correct and much better quality:

foo:
ldrbr3, [r0]@ zero_extendqisi2
cmp r3, #47
itt ne
movne   r3, #1
strne   r3, [r1]
bx  lr

[Bug target/110783] bpf; make sure of V4 signed division/modulus instructions

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jemarch at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-07-24

[Bug target/110790] [14 Regression] gcc -m32 generates invalid bit test code on gmp-6.2.1

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #1 from Sergei Trofimovich  ---
I suspect it's a r14-2728-g59c38ddfe052a4 (the only change I see in recent
commits that have any relevance here). I did not try to revert locally.

[Bug target/110790] New: [14 Regression] gcc -m32 generates invalid bit test code on gmp-6.2.1

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

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

Bug ID: 110790
   Summary: [14 Regression] gcc -m32 generates invalid bit test
code on gmp-6.2.1
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Initially observed test failures on gmp-6.2.1 when building with gcc
r14-2736-gd07504725973cc

Extracted reproducer:

// $ cat /tmp/a.c
typedef unsigned long int mp_limb_t;
typedef const mp_limb_t * mp_srcptr;

__attribute__((noipa))
int
refmpn_tstbit_bad (mp_srcptr ptr, unsigned long bit)
{
  return (((ptr)[(bit)/(32 - 0)] & (((mp_limb_t) 1L) << ((bit)%(32 - 0 !=
0);
}

__attribute__((noipa, optimize(0)))
int
refmpn_tstbit_good (mp_srcptr ptr, unsigned long bit)
{
  return (((ptr)[(bit)/(32 - 0)] & (((mp_limb_t) 1L) << ((bit)%(32 - 0 !=
0);
}

__attribute__((noipa))
int
refmpn_tstbit (mp_srcptr ptr, unsigned long bit)
{
  if (refmpn_tstbit_bad (ptr, bit) != refmpn_tstbit_good (ptr, bit)) {
  __builtin_trap();
  }
  return refmpn_tstbit_bad (ptr, bit);
}

int main(){
unsigned long num[] = { 0x3801ff9f, 0x0, 0x0, 0x0 };
refmpn_tstbit(num, 0);
}

$ gcc -m32 -fomit-frame-pointer /tmp/a.c -o /tmp/a -O2 && /tmp/a
Illegal instruction (core dumped)
$ gcc -m32 -fomit-frame-pointer /tmp/a.c -o /tmp/a && /tmp/a
# ok

It looks like refmpn_tstbit_bad() does something odd with bit shifts:

Dump of assembler code for function refmpn_tstbit_bad:
   0x08049200 <+0>: mov0x8(%esp),%eax ; bit
   0x08049204 <+4>: mov0x4(%esp),%edx ; ptr
   0x08049208 <+8>: mov%eax,%ecx
   0x0804920a <+10>:shr$0x5,%ecx  ; ecx = bit / 32 (limbs)
   0x0804920d <+13>:mov(%edx,%ecx,4),%edx ; edx = ptr[ecx]
   0x08049210 <+16>:bt %eax,%edx  ; might be ok if 'bit' does
not overflow?
   0x08049213 <+19>:setae  %al
   0x08049216 <+22>:movzbl %al,%eax
   0x08049219 <+25>:ret

I can't see any problems with this code on the data we pass here.

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

refmpn_tstbit_bad() gets compile

[Bug target/110787] [14 regression] ICE building SYSTEM.def

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from Roger Sayle  ---
> I'm bootstrapping with --enable-languages=all to investigate what's going on. 
> I'll revert the patch once I (or anyone) can confirm that this restores
> bootstrap, but I'd be happier understanding the actual mechanism (cause and
> effect) of this ICE.  Sorry for the temporary inconvenience.

Both i386-pc-solaris2.11 and x86_64-pc-linux-gnu bootstraps are well
into make check with the patch reverted locally.

[Bug target/110787] [14 regression] ICE building SYSTEM.def

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #2 from Roger Sayle  ---
I'm bootstrapping with --enable-languages=all to investigate what's going on. 
I'll revert the patch once I (or anyone) can confirm that this restores
bootstrap, but I'd be happier understanding the actual mechanism (cause and
effect) of this ICE.  Sorry for the temporary inconvenience.

[Bug target/110786] bpf: make use of the V4 byte swap instructions

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

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

--- Comment #2 from Jose E. Marchesi  ---
GCC updated.

[Bug c/110789] Internal Compiler Error: Illegal instruction

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #3 from Arsen Arsenović  ---
did you happen to se -march=native in CFLAGS or such when building gcc?

[Bug target/110786] bpf: make use of the V4 byte swap instructions

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jose E. Marchesi :

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

commit r14-2741-gf1e34551e4d6e259ab3bd0c9aba4fa1f0c448214
Author: Jose E. Marchesi 
Date:   Mon Jul 24 10:56:27 2023 +0200

bpf: make use of the bswap{16,32,64} V4 BPF instruction

This patch makes the BPF backend to use the new V4 bswap{16,32,64}
instructions in order to implement the __builtin_bswap{16,32,64}
built-ins.  It also adds support for -mcpu=v4 and -m[no]bswap
command-line options.  Tests and doc updates are includes.

Tested in bpf-unknown-none.

gcc/ChangeLog

PR target/110786
* config/bpf/bpf.opt (mcpu): Add ISA_V4 and make it the default.
(mbswap): New option.
* config/bpf/bpf-opts.h (enum bpf_isa_version): New value ISA_V4.
* config/bpf/bpf.cc (bpf_option_override): Set bpf_has_bswap.
* config/bpf/bpf.md: Use bswap instructions if available for
bswap* insn, and fix constraint.
* doc/invoke.texi (eBPF Options): Document -mcpu=v4 and -mbswap.

gcc/testsuite/ChangeLog

PR target/110786
* gcc.target/bpf/bswap-1.c: Pass -mcpu=v3 to build test.
* gcc.target/bpf/bswap-2.c: New test.

[Bug c/110789] Internal Compiler Error: Illegal instruction

[pledr at gmx dot net via Gcc-bugs]

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

Peter Lezoch  changed:

   What|Removed |Added

  Attachment #55617|0   |1
is obsolete||

--- Comment #2 from Peter Lezoch  ---
Created attachment 55618
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55618&action=edit
gcc -v

bash-5.2# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr LD=ld --enable-languages=c,c++
--enable-default-pie --enable-default-ssp --enable-multilib
--with-multilib-list=m64,m32,mx32 --disable-bootstrap --with-system-zlib
--with-long-double-128
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC) 
bash-5.2#

[Bug c/110789] Internal Compiler Error: Illegal instruction

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
How did you configure gcc?

I suspect the issue is you compiled gcc to only run on the first machine which
has avx2 while the second one does not.

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

[swilde--- via Gcc-bugs]

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

--- Comment #30 from Sascha Wilde  ---
Anything else I should test?

[Bug target/107199] AVX512 fully masked loop vectorization needs extract_last pattern for vectorization of live variables

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #1 from Richard Biener  ---
or for better latency compress with full mask, in parallel compute the lane to
extract and then shift/shuffle things to get the lane in zero position.  I also
see compress isn't available for HImode or QImode elements.

To recap, we have operations under a mask and we'd like to extract the
last operation result from a vector.

If we can get a mask with just the last bit set we can use compress.

[Bug c/110789] New: Internal Compiler Error: Illegal instruction

[pledr at gmx dot net via Gcc-bugs]

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

Bug ID: 110789
   Summary: Internal Compiler Error: Illegal instruction
   Product: gcc
   Version: og12 (devel/omp/gcc-12)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pledr at gmx dot net
  Target Milestone: ---

Created attachment 55617
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55617&action=edit
all facts collected in 1 file

see attachment
c++ shows the same error

[Bug target/110788] New: Spilling to mask register for GPR vec_duplicate

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

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

Bug ID: 110788
   Summary: Spilling to mask register for GPR vec_duplicate
   Product: gcc
   Version: 14.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: ---

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

produces the inner loop

.L3:
vmovapd b(%rax), %ymm0{%k1}
movl%edx, %ecx
subl$4, %edx
kmovw   %edx, %k0
vmulpd  %ymm3, %ymm0, %ymm1{%k1}{z}
vmovapd %ymm1, a(%rax){%k1}
vpbroadcastmw2d %k0, %xmm1
addq$32, %rax
vpcmpud $6, %xmm2, %xmm1, %k1
cmpw$4, %cx
ja  .L3

where we implement the splat of %edx as

kmovw   %edx, %k0
vpbroadcastmw2d %k0, %xmm1

instead of

vpbroadcastw%edx, %xmm1

we expand to

(insn 14 13 15 (set (reg:V4SI 96)
(vec_duplicate:V4SI (reg:SI 93 [ _27 ]))) 8167
{*avx512vl_vec_dup_gprv4si}
 (nil))

but at IRA time we instead match that do

(insn 14 13 15 3 (set (reg:V4SI 96)
(vec_duplicate:V4SI (zero_extend:SI (subreg:HI (reg/v:SI 95 [ n ])
0 8247 {avx512cd_maskw_vec_dupv4si}
 (expr_list:REG_DEAD (reg/v:SI 95 [ n ]) 
(nil)))

where combine created this via

Trying 13 -> 14:
   13: r93:SI=zero_extend(r95:SI#0)
  REG_DEAD r95:SI
   14: r96:V4SI=vec_duplicate(r93:SI)
  REG_DEAD r93:SI
Successfully matched this instruction:
(set (reg:V4SI 96)
(vec_duplicate:V4SI (zero_extend:SI (subreg:HI (reg/v:SI 95 [ n ]) 0
allowing combination of insns 13 and 14
original costs 4 + 4 = 8
replacement cost 4

but it didn't anticipate that reg 95 could be allocated to a GPR?  The
vectorizer uses an unsigned short IV for the loop, that's possibly
sub-optimal in this case but important in others.

I suppose it could also be a missed optimization in REE since I think
the HImode regs should already be zero-extended?

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

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

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

Bug 107093 Summary: AVX512 mask operations not simplified in fully masked loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107093

   What|Removed |Added

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

[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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
icelake is able to forward a masked store with a all-ones mask, Zen4 isn't able
to do that.  Other masked stores indeed do not forward.

There's a related problem also when an outer loop causes a low trip inner loop
to use masked load/store to then overlapping vectors:

outer iteration 1
   ... = .MASK_LOAD (p, {-1, -1, -1, -1, 0, 0, 0, 0});
   ...
   .MASK_STORE (p, val, {-1, -1, -1, -1, 0, 0, 0, 0});

outer iteration 2
   ... = .MASK_LOAD (p + delta, {-1, -1, -1, -1, 0, 0, 0, 0});
   ...
   .MASK_STORE (p + delta, val, {-1, -1, -1, -1, 0, 0, 0, 0});

with delta causing the next outer iteration to access the masked out values
from the previous iteration.  That gets a STLF failure (obviously) but
we now also need to wait for the masked store to retire before the masked
load of iteration 2 can be carried out.

We are hitting this case in SPEC CPU 2017 with masked epilogues (the
inner loop just iterates 4 times, vectorized with V8DFmode vectors).

Ideally the implementation (the CPU) would "shorten" loads/stores for
trailing sequences of zeros so this hazard doesn't occur.  Not sure if
that would be allowed by the x86 memory model though (I didn't find
anything specific there with respect to load/store masking).  ISTR store
buffer entries are usually assigned at instruction issue time, I'm not
sure if the mask is resolved there or whether the size of the store could
be adjusted later when it is.  The implementation could also somehow
ignore the "conflict".

Note I didn't yet fully benchmark masked epilogues with
-mpreferred-vector-width=512 on icelake or sapphire rapids, maybe Intel CPUs
are not affected
by this issue.

The original issue in the description seems solved we now generate the
following with the code generation variant that's now on trunk:

.L3:
vmovapd b(%rax), %ymm0{%k1}
movl%edx, %ecx
subl$4, %edx
kmovw   %edx, %k0
vmulpd  %ymm3, %ymm0, %ymm1{%k1}{z}
vmovapd %ymm1, a(%rax){%k1}
vpbroadcastmw2d %k0, %xmm1
addq$32, %rax
vpcmpud $6, %xmm2, %xmm1, %k1
cmpw$4, %cx
ja  .L3

that avoids using the slow mask ops for loop control.  It oddly does

subl$4, %edx
kmovw   %edx, %k0
vpbroadcastmw2d %k0, %xmm1

with -march=cascadelake - with -march=znver4 I get the expected

subl$8, %edx
vpbroadcastw%edx, %xmm1

but I can reproduce the mask register "spill" with -mprefer-vector-width=256.

We expand to

(insn 14 13 15 (set (reg:V4SI 96)
(vec_duplicate:V4SI (reg:SI 93 [ _27 ]))) 8167
{*avx512vl_vec_dup_gprv4si}
 (nil))

I'll file a separate bugreport for this.

[Bug target/110787] [14 regression] ICE building SYSTEM.def

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

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

--- Comment #1 from Andrew Pinski  ---
I am also seeing go failures.

[Bug target/110787] [14 regression] ICE building SYSTEM.def

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/110787] New: [14 regression] ICE building SYSTEM.def

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

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

Bug ID: 110787
   Summary: [14 regression] ICE building SYSTEM.def
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: gaius at gcc dot gnu.org, sayle at gcc dot gnu.org,
ubizjak at gmail dot com
  Target Milestone: ---
Target: i386-pc-solaris2.11, i686-pc-linux-gnu,
amd64-pc-solaris2.11, x86_64-pc-linux-gnu

Between 20230721 and 20230723, Solaris/x86 and Linux/i686 bootstrap broke
building SYSTEM.def in stage 2:

/bin/ksh /vol/gcc/src/hg/master/local/gcc/m2/tools-src/makeSystem -fpim \
 /vol/gcc/src/hg/master/local/gcc/m2/gm2-libs/SYSTEM.def \
 /vol/gcc/src/hg/master/local/gcc/m2/gm2-libs/SYSTEM.mod \
 -I/vol/gcc/src/hg/master/local/gcc/m2/gm2-libs \
 " ./gm2 -B./ -B/vol/gcc/i386-pc-solaris2.11/bin/
-L/var/gcc/regression/master/11.4-gcc/build/gcc/../ld "
/var/gcc/regression/master/11.4-gcc/build/gcc/m2/gm2-libs/SYSTEM.def
terminate called after throwing an instance of 'unsigned int'
during GIMPLE pass: cfg
/vol/gcc/src/hg/master/local/gcc/m2/gm2-libs/SYSTEM.mod: In function
‘ShiftVal’:
/vol/gcc/src/hg/master/local/gcc/m2/gm2-libs/SYSTEM.mod:77:1: internal compiler
error: Abort
   77 | BEGIN
  | ^
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
SYSTEM module creates type: LOC
SYSTEM module creates type: WORD
SYSTEM module creates type: BYTE
SYSTEM module creates type: ADDRESS
SYSTEM module creates type: INTEGER8
SYSTEM module creates type: INTEGER16
SYSTEM module creates type: INTEGER32
SYSTEM module creates type: INTEGER64
SYSTEM module creates type: CARDINAL8
SYSTEM module creates type: CARDINAL16
SYSTEM module creates type: CARDINAL32
SYSTEM module creates type: CARDINAL64
SYSTEM module creates type: WORD16
SYSTEM module creates type: WORD32
SYSTEM module creates type: WORD64
SYSTEM module creates type: BITSET8
SYSTEM module creates type: BITSET16
SYSTEM module creates type: BITSET32
SYSTEM module creates type: REAL32
SYSTEM module creates type: REAL64
SYSTEM module creates type: REAL128
SYSTEM module creates type: COMPLEX32
SYSTEM module creates type: COMPLEX64
SYSTEM module creates type: COMPLEX128
SYSTEM module creates type: CSIZE_T
SYSTEM module creates type: CSSIZE_T
terminate called after throwing an instance of 'unsigned int'
during GIMPLE pass: cfg
/vol/gcc/src/hg/master/local/gcc/m2/gm2-libs/SYSTEM.mod: In function
‘ShiftVal’:
/vol/gcc/src/hg/master/local/gcc/m2/gm2-libs/SYSTEM.mod:77:1: internal compiler
error: Abort
   77 | BEGIN
  | ^

A reghunt identified the following patch as the culprit:

commit 59c38ddfe052a409a690380d0378169f4a3936ad
Author: Roger Sayle 
Date:   Sat Jul 22 21:50:06 2023 +0100

i386: Use QImode for offsets in zero_extract/sign_extract in i386.md

It seems that the same patch also broke configuring 64-bit libphobos in
Solaris/amd64 and Linux/x86_64 builds:

configure: error: can't compile D sources!

configure:5405: /var/gcc/regression/master/11.4-gcc-64/build/./gcc/gdc
-B/var/gcc/regression/master/11.4-gcc-64/build/./gcc/
-B/vol/gcc/amd64-pc-solaris2.11/bin/ -B/vol/gcc/amd64-pc-solaris2.11/lib/
-isystem /vol/gcc/amd64-pc-solaris2.11/include -isystem
/vol/gcc/amd64-pc-solaris2.11/sys-include   -fno-checking -c -fno-druntime
-nostdinc -I /vol/gcc/src/hg/master/local/libphobos/libdruntime  -g -O2  
conftest.d >&5
: internal compiler error: Segmentation Fault
0x1a06ffa
_D3dmd4root11stringtable__T11StringTableTCQBo10identifier10IdentifierZQBr10allocValueMFNaNbMAxaQCcZk
/vol/gcc/src/hg/master/local/gcc/d/dmd/root/stringtable.d:260
0x1a0743f
_D3dmd4root11stringtable__T11StringTableTCQBo10identifier10IdentifierZQBr6updateMFNaNbMAxaZPSQDnQDmQDk__T11StringValueTQDaZQs
/vol/gcc/src/hg/master/local/gcc/d/dmd/root/stringtable.d:193
0x1a07526 _D3dmd10identifier10Identifier6idPoolFNbAxabZCQBsQBrQBi
/vol/gcc/src/hg/master/local/gcc/d/dmd/identifier.d:279
0x1a02264 Id::initialize()
/vol/gcc/src/hg/master/local/gcc/d/dmd/id.d-mixin-36:54

[Bug tree-optimization/110777] [14 Regression] ice: SSA corruption

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
Fixed.  thanks for reporting

[Bug tree-optimization/110766] [13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in gimple_phi_arg_def_from_edge, at gimple.h:4699

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[14 Regression] ICE on  |[13 Regression] ICE on
   |valid code at -O3 on|valid code at -O3 on
   |x86_64-linux-gnu: in|x86_64-linux-gnu: in
   |gimple_phi_arg_def_from_edg |gimple_phi_arg_def_from_edg
   |e, at gimple.h:4699 |e, at gimple.h:4699
   Priority|P3  |P2
   Target Milestone|14.0|13.3
  Known to work||14.0

--- Comment #6 from Richard Biener  ---
Fixed on trunk, latent on the branch - will push there once it re-opens.

[Bug tree-optimization/110766] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in gimple_phi_arg_def_from_edge, at gimple.h:4699

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

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

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

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

commit r14-2737-gfb132cdfb204bc12851eb1d5852eef6f03c13af3
Author: Richard Biener 
Date:   Mon Jul 24 08:40:19 2023 +0200

tree-optimization/110766 - missing PHI location check

The following adds a missing PHI location check before querying
the loop latch PHI arg from it.

PR tree-optimization/110766
* tree-scalar-evolution.cc
(analyze_and_compute_bitwise_induction_effect): Check the PHI
is defined in the loop header.

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

[Bug tree-optimization/110777] [14 Regression] ice: SSA corruption

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

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

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

https://gcc.gnu.org/g:50b5feaa94c26d01fed13f1119f025ae2bc75d2b

commit r14-2738-g50b5feaa94c26d01fed13f1119f025ae2bc75d2b
Author: Richard Biener 
Date:   Mon Jul 24 08:55:11 2023 +0200

tree-optimization/110777 - abnormals and recent PRE optimization

The following avoids propagating abnormals with the recent tweak
to look through PRE introduced copies between equal values.

PR tree-optimization/110777
* tree-ssa-sccvn.cc (eliminate_dom_walker::eliminate_avail):
Avoid propagating abnormals.

* gcc.dg/pr110777.c: New testcase.

[Bug tree-optimization/110755] [13/14 Regression] Wrong optimization of fabs on ppc64el at -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #55594|0   |1
is obsolete||

--- Comment #9 from Jakub Jelinek  ---
Created attachment 55616
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55616&action=edit
gcc14-pr110755.patch

Updated patch.

[Bug tree-optimization/110755] [13/14 Regression] Wrong optimization of fabs on ppc64el at -O1

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

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

--- Comment #8 from Jakub Jelinek  ---
Actually looking at IEEE754, the fix should be limited to +- operations, not
+-*/.
Because only for +- IEEE754 has:
"When the sum of two operands with opposite signs (or the difference of two
operands with like signs) is exactly zero, the sign of that sum (or difference)
shall be +0 in all rounding direction modes except roundTowardNegative; in that
mode, the sign of an exact zero sum (or difference) shall be –0. However, x+x =
x–(–x) retains the same sign as x even when x is zero."