New Swedish PO file for 'gcc' (version 12.1-b20220213)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

https://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-12.1-b20220213.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[Bug lto/104895] lto1: issue with space in library filename

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

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

--- Comment #3 from Andrew Pinski  ---
White spaces and even special characters will always be a problem with anything
that interacts with make or the shell.
I am not saying this is not a fixable issue, just fixing this might even
require huge changes to way POSIX make works.

[Bug target/96787] rs6000 mcpu=power10 miscompiles libiberty htab_delete() causing bootstrap failure

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|10.2|11.0

[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||powerpc64le-linux-gnu
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=96787
   Target Milestone|--- |11.3
Summary|[ppc64le] gcc11 ICE with|[11/12 Regression] ICE with
   |-fno-plt|-fno-plt -mcpu=power10 on
   ||PowerPC64 LE Linux

Re: [PATCH RFC] mips: add TARGET_ZERO_CALL_USED_REGS hook [PR104817, PR104820]

[Xi Ruoyao via Gcc-patches]

On Sat, 2022-03-12 at 18:48 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2022-03-11 at 21:26 +, Qing Zhao wrote:
> > Hi, Ruoyao,
> > 
> > (I might not be able to reply to this thread till next Wed due to a
> > short vacation).
> > 
> > First, some comments on opening bugs against Gcc:
> > 
> > I took a look at the bug reports PR104817 and PR104820:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104820
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104817
> > 
> > I didn’t see a testing case and a script to repeat the error, so I
> > cannot repeat the error at my side.
> 
> I've put the test case, but maybe you didn't see it because it is too
> simple:
> 
> echo 'int t() {}' | /home/xry111/git-repos/gcc-test-mips/gcc/cc1 -
> nostdinc -fzero-call-used-regs=all
> 
> An empty function is enough to break -fzero-call-used-regs=all.  And
> if
> you append -mips64r2 to the cc1 command line you'll get 104820.  I
> enabled 4 existing tests for MIPS (reported "not work" on MIPS) in the
> patch so I think it's unnecessary to add new test cases.
> 
> Richard: can we use MIPS_EPILOGUE_TEMP as a scratch register in the
> sequence for zeroing the call-used registers, and then zero itself
> (despite it's not in need_zeroed_hardregs)?

No, it leads to an ICE at stage 3 bootstrapping :(.

Now I think the only rational ways are:

(1) allow zeroing more registers than need_zeroed_hardregs.

Or

(2) allow zeroing less registers than need_zeroed_hardregs (then I'll
skip ST_REGS, after all they are just 8 bits in total).

If all these are unacceptable, then

(3) I'll just call sorry in MIPS target hook to tell not to use this
feature on MIPS.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

[Bug fortran/104900] New: segfault with parameterized derived type with kind parameter and allocatable component

[a.shahmoradi at gmail dot com via Gcc-bugs]

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

Bug ID: 104900
   Summary: segfault with parameterized derived type with kind
parameter and allocatable component
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a.shahmoradi at gmail dot com
  Target Milestone: ---

Created attachment 52617
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52617=edit
sample source code

The attached file contains a is a valid Fortran standard program with
parameterized derived types with kind type parameter (no len parameter) and an
allocatable component. However, gfortran yields a runtime segfault with this
code,

```
use, intrinsic :: iso_fortran_env!, only: real64, int64

integer, parameter :: RK1 = real_kinds(1)
integer, parameter :: RK2 = real_kinds(2)

type :: Container_type(RK)
integer, kind :: RK = RK1
real(RK), allocatable :: value(:)
end type

type(Container_type(RK1)), allocatable :: List(:)

interface wrap
procedure :: wrap_RK1, wrap_RK2
end interface

List = wrap([1.,2.,3.,4.,5.,6.])
print *, List(1)%value
print *, List(2)%value

contains

function wrap_RK1(array) result(List)
real(RK1), intent(in) :: array(:)
type(Container_type(RK1)), allocatable :: List(:)
allocate(List(2))
List(1)%value = array(1:size(array)/2)
List(2)%value = array(size(array)/2 + 1 : size(array))
end function

function wrap_RK2(array) result(List)
real(RK2), intent(in) :: array(:)
type(Container_type(RK2)), allocatable :: List(:)
allocate(List(2))
List(1)%value = array(1:size(array)/2)
List(2)%value = array(size(array)/2 + 1 : size(array))
end function

end
```

Here is the error message,
```

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f1e57dcc8d2 in ???
#1  0x7f1e57dcba65 in ???
#2  0x7f1e57a430bf in ???
#3  0x401927 in wrap_rk1
at /app/example.f90:27
#4  0x4012f4 in MAIN__
at /app/example.f90:17
#5  0x401bfc in main
at /app/example.f90:19
```

There segfault happen where the automatic allocation of the `value` component
occurs in the procedures. Here is an online test:
https://godbolt.org/z/8n5fs44sa

[Bug testsuite/103324] RFE: Add a `make quickcheck` or `make smoketest` Makefile target to allow only running a portion of the testsuite

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

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

--- Comment #4 from Eric Gallager  ---
Another thing that would be useful would be to have (more) comments in the
source code saying stuff like "/* this codepath is tested by 
*/" or something... although I guess it could be a problem keeping them in
sync...

[Bug target/104890] [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu (--enable-default-pie)

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

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

--- Comment #4 from Matthias Klose  ---
about the configure options, apparently pie is not the culprit, configuring
with --enable-cet is.  note that I didn't use --disable-bootstrap.

[Bug target/104890] [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu (--enable-default-pie)

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

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

Matthias Klose  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug target/104890] [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu (--enable-default-pie)

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

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

--- Comment #3 from Matthias Klose  ---
Created attachment 52616
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52616=edit
preprocessed source

/home/packages/gcc/12/gcc-12-12-20220313/build/./gcc/cc1 -E -quiet -v -I . -I .
-I ../../.././gcc -I ../../../../src/libgcc -
I ../../../../src/libgcc/. -I ../../../../src/libgcc/../gcc -I
../../../../src/libgcc/../include -I ../../../../src/libgcc/con
fig/libbid -imultilib 32 -imultiarch i386-linux-gnu -iprefix
/home/packages/gcc/12/gcc-12-12-20220313/build/gcc/../lib/gcc/x86
_64-linux-gnu/12/ -isystem
/home/packages/gcc/12/gcc-12-12-20220313/build/./gcc/include -isystem
/home/packages/gcc/12/gcc-12-
12-20220313/build/./gcc/include-fixed -MD unwind-dw2.d -MF unwind-dw2.dep -MP
-MT unwind-dw2.o -D IN_GCC -D USE_ELF_SYMVER -D 
IN_LIBGCC2 -D USE_ELF_SYMVER -D ENABLE_DECIMAL_BID_FORMAT -D HAVE_CC_TLS -D
USE_TLS -D HIDE_EXPORTS -isystem /usr/x86_64-linux
-gnu/include -isystem /usr/x86_64-linux-gnu/sys-include -isystem
/home/packages/gcc/12/gcc-12-12-20220313/build/sys-include -i
system ./include ../../../../src/libgcc/unwind-dw2.c -m32 -mlong-double-80
-mshstk -mtune=generic -march=i686 -Wextra -Wall -W
no-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -fchecking=1 -fcf-pro
tection=full -fbuilding-libgcc -fno-stack-protector -fpic -fcf-protection=full
-fexceptions -fvisibility=hidden -g -g -g -fwor
king-directory -O2 -O2 -O2 -fpch-preprocess -fasynchronous-unwind-tables -o
unwind-dw2.i

In file included from
/home/packages/gcc/12/gcc-12-12-20220313/build/gcc/include/x86gprintrin.h:45,
 from
../../../../src/libgcc/config/i386/shadow-stack-unwind.h:25,
 from ./md-unwind-support.h:27,
 from ../../../../src/libgcc/unwind-dw2.c:412:
/home/packages/gcc/12/gcc-12-12-20220313/build/gcc/include/cetintrin.h: In
function ‘_Unwind_RaiseException’:
/home/packages/gcc/12/gcc-12-12-20220313/build/gcc/include/cetintrin.h:47:1:
error: inlining failed in call to ‘always_inline’ ‘_get_ssp’: target specific
option mismatch
   47 | _get_ssp (void)
  | ^~~~
In file included from ../../../../src/libgcc/unwind-dw2.c:1728:
../../../../src/libgcc/unwind.inc:140:217: note: called from here
  140 |   uw_install_context (_context, _context, frames);
  |
   
^  
/home/packages/gcc/12/gcc-12-12-20220313/build/gcc/include/cetintrin.h:55:1:
error: inlining failed in call to ‘always_inline’ ‘_inc_ssp’: target specific
option mismatch
   55 | _inc_ssp (unsigned int __B)
  | ^~~~
../../../../src/libgcc/unwind.inc:140:295: note: called from here
  140 |   uw_install_context (_context, _context, frames);
  |
   
   
  ^ 
/home/packages/gcc/12/gcc-12-12-20220313/build/gcc/include/cetintrin.h:55:1:
error: inlining failed in call to ‘always_inline’ ‘_inc_ssp’: target specific
option mismatch
   55 | _inc_ssp (unsigned int __B)
  | ^~~~
../../../../src/libgcc/unwind.inc:140:325: note: called from here
  140 |   uw_install_context (_context, _context, frames);
  |
   
   
   
^

[Bug translation/104552] Mistakes in strings to be translated in GCC 12

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC|amacleod at redhat dot com |

--- Comment #39 from Eric Gallager  ---
(In reply to Roland Illig from comment #38)
> (In reply to Roland Illig from comment #7)
> > From params.opt:
> > > --param=ranger-debug=[none|trace|gori|cache|tracegori|all]
> > > Specifies the output mode for debugging ranger.
> > 
> > Why " " instead of the usual "\t" after the "]"?
> Everything is OK here, I wrongly thought that the usual separator in that
> file were a tab. The other similar entries use a space as well.
> 
> @egallager you can remove Andrew MacLeod from the CC list.

ok, done

[Bug c++/98767] Function signature lost in concept diagnostic message

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Closing as fixed for GCC 12

Re: [PATCH] PR tree-optimization/101895: Fold VEC_PERM to help recognize FMA.

[Marc Glisse via Gcc-patches]

On Fri, 11 Mar 2022, Roger Sayle wrote:

+(match vec_same_elem_p
+  CONSTRUCTOR@0
+  (if (uniform_vector_p (TREE_CODE (@0) == SSA_NAME
+? gimple_assign_rhs1 (SSA_NAME_DEF_STMT (@0)) : @0

Ah, I didn't remember we needed that, we don't seem to be very consistent 
about it. Probably for this reason, the transformation "Prefer vector1 << 
scalar to vector1 << vector2" does not match


typedef int vec __attribute__((vector_size(16)));
vec f(vec a, int b){
  vec bb = { b, b, b, b };
  return a << bb;
}

which is only optimized at vector lowering time.

+/* Push VEC_PERM earlier if that may help FMA perception (PR101895).  */
+(for plusminus (plus minus)
+  (simplify
+(plusminus (vec_perm (mult@0 @1 vec_same_elem_p@2) @0 @3) @4)
+(plusminus (mult (vec_perm @1 @1 @3) @2) @4)))

Don't you want :s on mult and vec_perm?

--
Marc Glisse

[Bug c/104899] New: typo "cannott"

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

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

Bug ID: 104899
   Summary: typo "cannott"
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
CC: egallager at gcc dot gnu.org
  Target Milestone: ---

in bfin.cc and range-op.cc

This typo doesn't appear in any tests so it should be trivial to fix.

[Bug target/104898] New: missing %q in diagnostic

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

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

Bug ID: 104898
   Summary: missing %q in diagnostic
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
CC: egallager at gcc dot gnu.org, sje at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

>From aarch64.cc:
> invalid feature modifier %s
The %s should be %qs, like in the related messages.

The parentheses in "(%qs)" look redundant.  They are only used 18 times in
total, in the whole tree.  For comparison, "%qs" is used more than 2700 times
in the whole tree.  I would remove the parentheses.

gcc-11-20220312 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20220312 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20220312/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 908e612067e42ded881db10d38768f23307bf55e

You'll find:

 gcc-11-20220312.tar.xz   Complete GCC

  SHA256=7a4030bd3857655fbd9e740c01dd39d9ca8b189d6ead9c0ce3474eafba28a8bc
  SHA1=ba3d342f5eff5cc15dbc3934eef146af9e019bfd

Diffs from 11-20220305 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug target/104897] New: wrong plural form in diagnostic

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

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

Bug ID: 104897
   Summary: wrong plural form in diagnostic
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
CC: egallager at gcc dot gnu.org, rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

>From aarch64-sve-builtins.cc:
> error_at (location, "passing single vector %qT to argument %d"
>   " of %qE, which expects a tuple of %d vectors",
>   actual, argno + 1, fndecl, num_vectors);
"%d vectors" must use the correct plural form, for the benefit of Polish,
Russian, Arabic and several more.

=> Richard Sandiford's string (https://gcc.gnu.org/g:624d0f07)

"%d vectors" appears twice in this file.

[Bug translation/104552] Mistakes in strings to be translated in GCC 12

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

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

--- Comment #38 from Roland Illig  ---
(In reply to Roland Illig from comment #7)
> From params.opt:
> > --param=ranger-debug=[none|trace|gori|cache|tracegori|all]
> > Specifies the output mode for debugging ranger.
> 
> Why " " instead of the usual "\t" after the "]"?
Everything is OK here, I wrongly thought that the usual separator in that file
were a tab. The other similar entries use a space as well.

@egallager you can remove Andrew MacLeod from the CC list.

[Bug c/104896] New: Messages use %<%s%> instead of the idiomatic %qs

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

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

Bug ID: 104896
   Summary: Messages use %<%s%> instead of the idiomatic %qs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
CC: egallager at gcc dot gnu.org, msebor at gcc dot gnu.org
  Target Milestone: ---

As of 2022-03-12, the GCC tree contains 44 instances of the string "%<%s%>".
Please have a look whether they can be replaced with the idiomatic %qs, and if
not, document them.

[PATCH] wwwdocs: fedora-devel-list archives changes

[Gerald Pfeifer]

I have *NOT* pushed this yet, looking for feedback:

It appears redhat.com has lost Fedora mailing list archives, which are
now at lists.fedoraproject.org using completely different tooling.

Jakub, is there a better way than the patch below?

Gerald

diff --git a/htdocs/gcc-4.3/porting_to.html b/htdocs/gcc-4.3/porting_to.html
index 630290ce..5301729f 100644
--- a/htdocs/gcc-4.3/porting_to.html
+++ b/htdocs/gcc-4.3/porting_to.html
@@ -527,7 +527,7 @@ svn diff -r529854:529855 
http://svn.apache.org/repos/asf/ant/core/trunk/src/main
 
 
 Jakub Jelinek,
-https://listman.redhat.com/archives/fedora-devel-list/2008-January/msg00128.html;>
+https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/WV3KUDEP2JNOWGWES42RQZFYFNLFLAMJ/;>
 Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220
 
 

[Bug lto/104895] lto1: issue with space in library filename

[christophm30 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Christoph Müllner  ---
Further analysis shows that '-flto=1' works as well and '-flto=16' fails as
well.

This brings us right to the spot:

Bad:
[...]
make -f /tmp/ccyzs8VX.mk -j16 all
Using built-in specs.
[...]

Good:
[...]
gcc @/tmp/cclqDb0Y
Using built-in specs.
[...]

Let's look deeper:
$ mkdir tmpdir
$ export TEMP=$(pwd)/tmpdir/
$ gcc -v -fPIC -flto=16  -shared -Wl,-soname,"lib'do it'.so" -o "lib'do it'.so"
doit.o -save-temps
$ cat tmpdir/ccM8aNK8.mk 
./lib'do it'.so.ltrans0.ltrans.o:
@gcc  '-xlto' '-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none'
'-mtune=generic' '-march=x86-64' '-fPIC' '-v' '-fPIC' '-shared' '-save-temps'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'lib'do it'.so.' '-dumpbase'
'./lib'do it'.so.ltrans0.ltrans' '-fltrans' '-o' './lib'do
it'.so.ltrans0.ltrans.o' './lib'do it'.so.ltrans0.o'
.PHONY: all
all: \
./lib'do it'.so.ltrans0.ltrans.o

The invocation of GCC will be:
gcc  '-xlto' '-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none'
'-mtune=generic' '-march=x86-64' '-fPIC' '-v' '-fPIC' '-save-temps' '-shared'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'libdon't do it.so.' '-dumpbase'
'./libdon't do it.so.ltrans0.ltrans' '-fltrans' '-o' './libdon't do
it.so.ltrans0.ltrans.o' './libdon't do it.so.ltrans0.o'

And here we see the issue!
The options are each quoted with '-characters. But the filename itself contains
these characters as well, which will terminate the string. The space between
the '-characters will therefore be interpreted as a separator.

One thing to mention is that GNU Make has limitations how to handle spaces:
http://savannah.gnu.org/bugs/?712

[Bug c++/104641] Deduction guide for member template class rejected at class scope when used with typename dependant type

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 12.

[Bug c++/104622] [12 Regression] ICE in compare_ics, at cp/call.cc:11419

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed.

[Bug c++/104527] [11 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[11/12 Regression] ICE: |[11 Regression] ICE: tree
   |tree check: accessed elt 1  |check: accessed elt 1 of
   |of 'tree_vec' with 0 elts   |'tree_vec' with 0 elts in
   |in hash, at |hash, at
   |cp/constraint.cc:2486   |cp/constraint.cc:2486

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 12 so far.

[Bug c++/98644] [10/11 Regression] [concepts] ICE in satisfaction_value, at cp/constraint.cc:2825

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[10/11/12 Regression]   |[10/11 Regression]
   |[concepts] ICE in   |[concepts] ICE in
   |satisfaction_value, at  |satisfaction_value, at
   |cp/constraint.cc:2825   |cp/constraint.cc:2825

--- Comment #5 from Patrick Palka  ---
Fixed (finally) for GCC 12 so far.

[Bug c++/104641] Deduction guide for member template class rejected at class scope when used with typename dependant type

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r12-7633-gd3b0dc686c00bfe9e7f4fe0490def68e9b92157a
Author: Patrick Palka 
Date:   Sat Mar 12 15:00:51 2022 -0500

c++: naming a dependently-scoped template for CTAD [PR104641]

In order to be able to perform CTAD for a dependently-scoped template
(such as A::B in the testcase below), we need to permit a
typename-specifier to resolve to a template as per [dcl.type.simple]/3,
at least when it appears in a CTAD-enabled context.

This patch implements this using a new tsubst flag tf_tst_ok to control
when a TYPENAME_TYPE is allowed to name a template, and sets this flag
when substituting into the type of a CAST_EXPR, CONSTRUCTOR or VAR_DECL
(each of which is a CTAD-enabled context).

PR c++/104641

gcc/cp/ChangeLog:

* cp-tree.h (tsubst_flags::tf_tst_ok): New flag.
* decl.cc (make_typename_type): Allow a typename-specifier to
resolve to a template when tf_tst_ok, in which case return
a CTAD placeholder for the template.
* pt.cc (tsubst_decl) : Set tf_tst_ok when
substituting the type.
(tsubst): Clear tf_tst_ok and remember if it was set.
: Pass tf_tst_ok to make_typename_type
appropriately.
(tsubst_copy) : Set tf_tst_ok when substituting
the type.
(tsubst_copy_and_build) : Likewise.
: Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction107.C: New test.

[Bug c++/104622] [12 Regression] ICE in compare_ics, at cp/call.cc:11419

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:03c83cf7aa1110e427beb00ea95767dfaf50d694

commit r12-7632-g03c83cf7aa1110e427beb00ea95767dfaf50d694
Author: Patrick Palka 
Date:   Sat Mar 12 15:00:49 2022 -0500

c++: ICE with bad conversion shortcutting [PR104622]

When shortcutting bad argument conversions during overload resolution,
we assume conversions get computed in sequential order and that therefore
the conversion array is incomplete iff the last conversion is missing.
But this assumption turns out to be wrong for templates, because during
deduction check_non_deducible_conversion can compute an argument
conversion out of order.

So in the testcase below, at the end of add_template_candidate the
conversion array looks like {bad_conv, NULL, good_conv} where the last
conversion was computed during deduction and the first one later from
add_function_candidate.  We need to add this candidate to bad_fns since
not all of its argument conversions were computed, but we don't do so
because the last conversion isn't missing.

This patch fixes this by checking for a missing conversion exhaustively
instead.  In passing, this cleans up check_non_deducible_conversion given
that the only values of 'strict' we expect to see here the enumerators
of unification_kind_t.

PR c++/104622

gcc/cp/ChangeLog:

* call.cc (missing_conversion_p): Define.
(add_candidates): Use it.
* pt.cc (check_non_deducible_conversion): Change type of strict
parameter to unification_kind_t and directly test for DEDUCE_CALL.

gcc/testsuite/ChangeLog:

* g++.dg/template/conv18.C: New test.

[Bug c++/104527] [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:9413bb55185b9e88d84e91d5145d59f9f83b884a

commit r12-7631-g9413bb55185b9e88d84e91d5145d59f9f83b884a
Author: Patrick Palka 
Date:   Sat Mar 12 15:00:40 2022 -0500

c++: return-type-req in constraint using only outer tparms [PR104527]

Here the template context for the atomic constraint has two levels of
template parameters, but since it depends only on the innermost parameter
T we use a single-level argument vector (built by get_mapped_args) during
substitution into the atom.  We eventually pass this vector to
do_auto_deduction as part of checking the return-type-requirement within
the atom, but do_auto_deduction expects outer_targs to be a full set of
arguments for sake of satisfaction.

This patch fixes this by making get_mapped_args always return an
argument vector whose depth corresponds to the template depth of the
context in which the atomic constraint expression was written, instead
of the highest parameter level that the expression happens to use.

PR c++/104527

gcc/cp/ChangeLog:

* constraint.cc (normalize_atom): Set
ATOMIC_CONSTR_EXPR_FROM_CONCEPT_P appropriately.
(get_mapped_args):  Make static, adjust parameters.  Always
return a vector whose depth corresponds to the template depth of
the context of the atomic constraint expression.  Micro-optimize
by passing false as exact to safe_grow_cleared and by collapsing
a multi-level depth-one argument vector.
(satisfy_atom): Adjust call to get_mapped_args and
diagnose_atomic_constraint.
(diagnose_atomic_constraint): Replace map parameter with an args
parameter.
* cp-tree.h (ATOMIC_CONSTR_EXPR_FROM_CONCEPT_P): Define.
(get_mapped_args): Remove declaration.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-return-req4.C: New test.

[Bug c++/98644] [10/11/12 Regression] [concepts] ICE in satisfaction_value, at cp/constraint.cc:2825

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r12-7630-gab71d3fe4b23af4c29a8d6fcf1e914fed4393e3b
Author: Patrick Palka 
Date:   Sat Mar 12 14:57:59 2022 -0500

c++: ICE with non-constant satisfaction value [PR98644]

Here during satisfaction, the expression of the atomic constraint after
substitution is (int *) NON_LVALUE_EXPR <1> != 0B, which is not a C++
constant expression due to the reinterpret_cast, but TREE_CONSTANT is
set since its value is otherwise effectively constant.  We then call
maybe_constant_value on it, which proceeds via its fail-fast path to
exit early without clearing TREE_CONSTANT.  But satisfy_atom relies
on checking TREE_CONSTANT of the result of maybe_constant_value in order
to detect non-constant satisfaction.

This patch fixes this by making the fail-fast path of maybe_constant_value
clear TREE_CONSTANT in this case, like cxx_eval_outermost_constant_expr
in the normal path would have done.

PR c++/98644

gcc/cp/ChangeLog:

* constexpr.cc (mark_non_constant): Define, split out from ...
(cxx_eval_outermost_constant_expr): ... here.
(maybe_constant_value): Use it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-pr98644.C: New test.
* g++.dg/parse/array-size2.C: Remove expected diagnostic about a
narrowing conversion.

Co-authored-by: Jason Merrill 

New French PO file for 'gcc' (version 12.1-b20220213)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators.  The file is available at:

https://translationproject.org/latest/gcc/fr.po

(This file, 'gcc-12.1-b20220213.fr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei

[i at rvalue dot moe via Gcc-bugs]

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

--- Comment #7 from rvalue  ---
Well, I've found something that could be problematic here:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/arch-canonicalize;h=49a6204b9cb64cb0e375c6003c423bf115a0a8a6;hb=HEAD#l60

It's never updated in ISA spec version bumping.

[Bug middle-end/104885] ICE in compiling new test case g++.dg/other/pr84964.C after r12-7607-ga717376e99fb33

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-03-12
 CC||roger at nextmovesoftware dot 
com
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com

--- Comment #1 from Roger Sayle  ---
Patch proposed.
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591665.html

[PATCH] PR middle-end/104885: Fix ICE with large stack frame on powerpc64.

[Roger Sayle]

My recent testcase for PR c++/84964.C stress tests the middle-end by
attempting to pass a UINT_MAX sized structure on the stack.  Although
my fix to PR84964 avoids the ICE after sorry() on x86_64 and similar
targets, a related issue still exists on powerpc64 (and similar
ACCUMULATE_OUTGOING_ARGS/ARGS_GROW_DOWNWARD targets) which don't
issue a "sorry, unimplemented" message, but instead ICE elsewhere.

After attempting several alternate fixes, the simplest solution is
to just defensively check in mark_stack_region_used that the upper
bound of the region lies within the allocated stack_usage_map
array, which is of size highest_outgoing_arg_in_use.  When this isn't
the case, the code now follows the same path as for variable sized
regions, and uses stack_usage_watermark rather than a map.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check to confirm there are no surprises, and with the cc1plus
of a cross-compiler to powerpc64-linux-gnu to confirm the new test
case no longer ICEs.  Ok for mainline?


2022-03-12  Roger Sayle  

gcc/ChangeLog
PR middle-end/104885
* calls.cc (mark_stack_region_used): Check that the region
is within the allocated size of stack_usage_map.


Thanks in advance,
Roger
--

diff --git a/gcc/calls.cc b/gcc/calls.cc
index 50fa7b8..1ca96e7 100644
--- a/gcc/calls.cc
+++ b/gcc/calls.cc
@@ -201,7 +201,8 @@ mark_stack_region_used (poly_uint64 lower_bound, 
poly_uint64 upper_bound)
 {
   unsigned HOST_WIDE_INT const_lower, const_upper;
   const_lower = constant_lower_bound (lower_bound);
-  if (upper_bound.is_constant (_upper))
+  if (upper_bound.is_constant (_upper)
+  && const_upper <= highest_outgoing_arg_in_use)
 for (unsigned HOST_WIDE_INT i = const_lower; i < const_upper; ++i)
   stack_usage_map[i] = 1;
   else

[PATCH] lra: Fix up debug_p handling in lra_substitute_pseudo [PR104778]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase ICEs on powerpc-linux, because lra_substitute_pseudo
substitutes (const_int 1) into a subreg operand.  First a subreg of subreg
of a reg appears in a debug insn (which surely is invalid outside of
debug insns, but in debug insns we allow even what is normally invalid in
RTL like subregs which the target doesn't like, because either dwarf2out
is able to handle it, or we just throw away the location expression,
making some var .

lra_substitute_pseudo already has some code to deal with specifically
SUBREG of REG with the REG being substituted for VOIDmode constant,
but that doesn't cover this case, so the following patch extends
lra_substitute_pseudo for debug_p mode to treat stuff like e.g.
combiner's subst function to ensure we don't lose mode which is essential
for the IL.

Bootstrapped/regtested on {powerpc64{,le},x86_64,i686}-linux, ok for trunk?

2022-03-12  Jakub Jelinek  

PR debug/104778
* lra.cc (lra_substitute_pseudo): For debug_p mode, simplify
SUBREG, ZERO_EXTEND, SIGN_EXTEND, FLOAT or UNSIGNED_FLOAT if recursive
call simplified the first operand into VOIDmode constant.

* gcc.target/powerpc/pr104778.c: New test.

--- gcc/lra.cc.jj   2022-02-04 14:36:55.375600131 +0100
+++ gcc/lra.cc  2022-03-11 18:47:15.555025540 +0100
@@ -2015,8 +2015,39 @@ lra_substitute_pseudo (rtx *loc, int old
 {
   if (fmt[i] == 'e')
{
- if (lra_substitute_pseudo ( (x, i), old_regno,
-new_reg, subreg_p, debug_p))
+ if (debug_p
+ && i == 0
+ && (code == SUBREG
+ || code == ZERO_EXTEND
+ || code == SIGN_EXTEND
+ || code == FLOAT
+ || code == UNSIGNED_FLOAT))
+   {
+ rtx y = XEXP (x, 0);
+ if (lra_substitute_pseudo (, old_regno,
+new_reg, subreg_p, debug_p))
+   {
+ result = true;
+ if (CONST_SCALAR_INT_P (y))
+   {
+ if (code == SUBREG)
+   y = simplify_subreg (GET_MODE (x), y,
+GET_MODE (SUBREG_REG (x)),
+SUBREG_BYTE (x));
+ else
+   y = simplify_unary_operation (code, GET_MODE (x), y,
+ GET_MODE (XEXP (x, 0)));
+ if (y)
+   *loc = y;
+ else
+   *loc = gen_rtx_CLOBBER (GET_MODE (x), const0_rtx);
+   }
+ else
+   XEXP (x, 0) = y;
+   }
+   }
+ else if (lra_substitute_pseudo ( (x, i), old_regno,
+ new_reg, subreg_p, debug_p))
result = true;
}
   else if (fmt[i] == 'E')
--- gcc/testsuite/gcc.target/powerpc/pr104778.c.jj  2022-03-11 
18:54:09.455264514 +0100
+++ gcc/testsuite/gcc.target/powerpc/pr104778.c 2022-03-11 18:52:57.216269904 
+0100
@@ -0,0 +1,51 @@
+/* PR debug/104778 */
+/* { dg-do compile } */
+/* { dg-options "-mcmpb -Og -g" } */
+/* { dg-additional-options "-fpie" { target pie } } */
+
+unsigned long long int p;
+short int m, n;
+
+void
+foo (double u, int v, int x, int y, int z)
+{
+  long long int a = v;
+  short int b = v;
+  int c = 0, d = m, e = u;
+
+  if (n)
+{
+  int q = b;
+
+  while (p / 1.0)
+c = 0;
+
+  if (n * n == (d + 1) / (1LL << x))
+a = 1;
+
+  b = u;
+  while (d)
+{
+  u = m + 1ULL;
+  b = a - (unsigned long long int) u + a + (char) (u + 1.0);
+  d = (v - 1LL) * n / d + q + x;
+  q = m;
+}
+}
+
+  while (c < 1)
+{
+  int r;
+
+  if (m == y)
+m = e * z;
+
+  e = !a;
+
+  while (!r)
+;
+
+  if (b)
+m = d;
+}
+}

Jakub

[PATCH] i386: Fix up _mm_loadu_si{16,32} [PR99754]

[Jakub Jelinek via Gcc-patches]

Hi!

These intrinsics are supposed to do an unaligned may_alias load
of a 16-bit or 32-bit value and store it as the first element of
a 128-bit integer vector, with all other elements cleared.

The current _mm_storeu_* implementation implements that correctly, uses
__*_u types to do the store and extracts the first element of a vector into
it.
But _mm_loadu_si{16,32} gets it all wrong.  It performs an aligned
non-may_alias load and because _mm_set_epi{16,32} has the args reversed,
it also inserts it into the last vector element instead of first.

The following patch fixes that, bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk and affected release branches?

Note, while the Intrinsics guide for _mm_loadu_si32 says SSE2,
for _mm_loadu_si16 it says strangely SSE.  But the intrinsics
returns __m128i, which is only defined in emmintrin.h, and
_mm_set_epi16 is also only SSE2 and later in emmintrin.h.
Even clang defines it in emmintrin.h and ends up with inlining
failure when calling _mm_loadu_si16 from sse,no-sse2 function.
So, isn't that a bug in the intrinsic guide instead?

2022-03-12  Jakub Jelinek  

PR target/99754
* config/i386/emmintrin.h (_mm_loadu_si32): Put loaded value into
first   rather than last element of the vector, use __m32_u to do
a really unaligned load, use just 0 instead of (int)0.
(_mm_loadu_si16): Put loaded value into first rather than last
element of the vector, use __m16_u to do a really unaligned load,
use just 0 instead of (short)0.

* gcc.target/i386/pr99754-1.c: New test.
* gcc.target/i386/pr99754-2.c: New test.

--- gcc/config/i386/emmintrin.h.jj  2022-01-11 23:11:21.766298923 +0100
+++ gcc/config/i386/emmintrin.h 2022-03-11 16:47:24.789884825 +0100
@@ -718,14 +718,13 @@ _mm_loadu_si64 (void const *__P)
 extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
 _mm_loadu_si32 (void const *__P)
 {
-  return _mm_set_epi32 (*(int *)__P, (int)0, (int)0, (int)0);
+  return _mm_set_epi32 (0, 0, 0, (*(__m32_u *)__P)[0]);
 }
 
 extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
 _mm_loadu_si16 (void const *__P)
 {
-  return _mm_set_epi16 (*(short *)__P, (short)0, (short)0, (short)0,
-   (short)0, (short)0, (short)0, (short)0);
+  return _mm_set_epi16 (0, 0, 0, 0, 0, 0, 0, (*(__m16_u *)__P)[0]);
 }
 
 extern __inline void __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
--- gcc/testsuite/gcc.target/i386/pr99754-1.c.jj2022-03-11 
16:43:30.621120896 +0100
+++ gcc/testsuite/gcc.target/i386/pr99754-1.c   2022-03-11 16:43:18.250291856 
+0100
@@ -0,0 +1,20 @@
+/* PR target/99754 */
+/* { dg-do run } */
+/* { dg-options "-O2 -msse2" } */
+/* { dg-require-effective-target sse2 } */
+
+#include "sse2-check.h"
+#include 
+
+static void
+sse2_test (void)
+{
+  union { unsigned char buf[32]; long long ll; } u;
+  u.buf[1] = 0xfe;
+  u.buf[2] = 0xca;
+  u.buf[17] = 0xaa;
+  u.buf[18] = 0x55;
+  _mm_storeu_si16 ([17], _mm_loadu_si16 ([1]));
+  if (u.buf[17] != 0xfe || u.buf[18] != 0xca)
+abort ();
+}
--- gcc/testsuite/gcc.target/i386/pr99754-2.c.jj2022-03-11 
16:43:41.701967763 +0100
+++ gcc/testsuite/gcc.target/i386/pr99754-2.c   2022-03-11 16:45:16.391659211 
+0100
@@ -0,0 +1,24 @@
+/* PR target/99754 */
+/* { dg-do run } */
+/* { dg-options "-O2 -msse2" } */
+/* { dg-require-effective-target sse2 } */
+
+#include "sse2-check.h"
+#include 
+
+static void
+sse2_test (void)
+{
+  union { unsigned char buf[32]; long long ll; } u;
+  u.buf[1] = 0xbe;
+  u.buf[2] = 0xba;
+  u.buf[3] = 0xfe;
+  u.buf[4] = 0xca;
+  u.buf[17] = 0xaa;
+  u.buf[18] = 0x55;
+  u.buf[19] = 0xaa;
+  u.buf[20] = 0x55;
+  _mm_storeu_si32 ([17], _mm_loadu_si32 ([1]));
+  if (u.buf[17] != 0xbe || u.buf[18] != 0xba || u.buf[19] != 0xfe || u.buf[20] 
!= 0xca)
+abort ();
+}

Jakub

[PATCH] c++: Fix up cp_parser_skip_to_pragma_eol [PR104623]

[Jakub Jelinek via Gcc-patches]

Hi!

We ICE on the following testcase, because we tentatively parse it multiple
times and the erroneous attribute syntax results in
cp_parser_skip_to_end_of_statement, which when seeing CPP_PRAGMA (can be
any deferred one, OpenMP/OpenACC/ivdep etc.) it calls
cp_parser_skip_to_pragma_eol, which calls cp_lexer_purge_tokens_after.
That call purges all the tokens from CPP_PRAGMA until CPP_PRAGMA_EOL,
excluding the initial CPP_PRAGMA though (but including the final
CPP_PRAGMA_EOL).  This means the second time we parse this, we see
CPP_PRAGMA with no tokens after it from the pragma, most importantly
not the CPP_PRAGMA_EOL, so either if it is the last pragma in the TU,
we ICE, or if there are other pragmas we treat everything in between
as a pragma.

I've tried various things, including making the CPP_PRAGMA token
itself also purged, or changing the cp_parser_skip_to_end_of_statement
(and cp_parser_skip_to_end_of_block_or_statement) to call it with
NULL instead of token, so that this purging isn't done there,
but each patch resulted in lots of regressions.
But removing the purging altogether surprisingly doesn't regress anything,
and I think it is the right thing, if we e.g. parse tentatively, why can't
we parse the pragma multiple times or at least skip over it?

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2022-03-12  Jakub Jelinek  

PR c++/104623
* parser.cc (cp_parser_skip_to_pragma_eol): Don't purge any tokens.

* g++.dg/gomp/pr104623.C: New test.

--- gcc/cp/parser.cc.jj 2022-03-11 13:11:53.622094878 +0100
+++ gcc/cp/parser.cc2022-03-11 14:45:36.877647173 +0100
@@ -4111,8 +4111,6 @@ cp_parser_skip_to_pragma_eol (cp_parser*
 
   if (pragma_tok)
 {
-  /* Ensure that the pragma is not parsed again.  */
-  cp_lexer_purge_tokens_after (parser->lexer, pragma_tok);
   parser->lexer->in_pragma = false;
   if (parser->lexer->in_omp_attribute_pragma
  && cp_lexer_next_token_is (parser->lexer, CPP_EOF))
--- gcc/testsuite/g++.dg/gomp/pr104623.C.jj 2022-03-11 14:22:15.724288282 
+0100
+++ gcc/testsuite/g++.dg/gomp/pr104623.C2022-03-11 14:22:06.746413835 
+0100
@@ -0,0 +1,9 @@
+// PR c++/104623
+// { dg-do compile }
+
+void
+foo ()
+{
+  struct __attribute__() a // { dg-error "expected primary-expression 
before" }
+  #pragma omp task
+}

Jakub

[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei

[i at rvalue dot moe via Gcc-bugs]

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

--- Comment #6 from rvalue  ---
I've got some verbose output from gcc, and it seems that a duplicate `-march`
is passed to `as`

$ gcc -c test.c -march=rv64g --verbose
Using built-in specs.
COLLECT_GCC=/usr/sbin/gcc
Target: riscv64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,fortran,go,lto,objc,obj-c++,d --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-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-linker-build-id --enable-lto
--disable-multilib --enable-plugin --enable-shared --enable-threads=posix
--disable-libssp --disable-libstdcxx-pch --disable-werror
--with-build-config=bootstrap-lto --enable-link-serialization=1
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)
COLLECT_GCC_OPTIONS='-c' '-march=rv64g' '-v' '-mabi=lp64d' '-march=rv64imafd'
 /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/cc1 -quiet -v test.c -quiet
-dumpbase test.c -dumpbase-ext .c -march=rv64g -mabi=lp64d -march=rv64imafd
-version -o /tmp/ccCK3sIZ.s
GNU C17 (GCC) version 11.2.0 (riscv64-unknown-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/../../../../riscv64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/include
 /usr/local/include
 /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/include-fixed
 /usr/include
End of search list.
GNU C17 (GCC) version 11.2.0 (riscv64-unknown-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 42e88359d8058cfa8524073dbb277472
COLLECT_GCC_OPTIONS='-c' '-march=rv64g' '-v' '-mabi=lp64d' '-march=rv64imafd'
 as -v --traditional-format -fpic -march=rv64g -march=rv64imafd -mabi=lp64d -o
test.o /tmp/ccCK3sIZ.s
GNU assembler version 2.38 (riscv64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.38
test.c: Assembler messages:
test.c:2: Error: unrecognized opcode `fence.i'

[x86 PATCH] Fix libitm.c/memset-1.c test fails with new peephole2s.

[Roger Sayle]

My sincere apologies for the breakage, but alas handling SImode in the
recently added "xorl;movb -> movzbl" peephole2 turns out to be slightly
more complicated that just using SWI48 as a mode iterator.  I'd failed
to check the machine description carefully, but the *zero_extendsi2
define_insn is conditionally defined, based on x86 target tuning using
TARGET_ZERO_EXTEND_WITH_AND, and therefore unavailable on 486 and pentium
unless optimizing the code for size.  It turns out that the libitm testsuite
specifies -m486 with make check RUNTESTFLAGS="--target_board='unix{-m32}'"
and therefore encounters/catches my oversight.

Fixed by adding the appropriate conditions to the new peephole2 patterns.
It don't think it's worth the effort to provide an equivalent optimization
for
these (very) old architectures.

Tested on x86_64-pc-linux-gnu with make bootstrap and make -k check
with no new failures.  Confirmed using RUNTESTFLAGS that this
fixes the above failure, and the recently added testcase with -march=i486.
Ok for mainline?


2022-03-12  Roger Sayle  

gcc/ChangeLog
* config/i386/i386.md (peephole2 xorl;movb -> movzbl): Disable
transformation when *zero_extendsi2 is not available.

gcc/testsuite/ChangeLog
* gcc.target/i386/pr98335.c: Skip this test if tuning for i486
or pentium, and not optimizing for size.


Sorry for the noise.
Roger
--

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index c8fbf60..80b5974 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -4316,7 +4316,10 @@
  (clobber (reg:CC FLAGS_REG))])
(set (strict_low_part (match_operand:SWI12 1 "general_reg_operand"))
(match_operand:SWI12 2 "nonimmediate_operand"))]
-  "REGNO (operands[0]) == REGNO (operands[1])"
+  "REGNO (operands[0]) == REGNO (operands[1])
+   && ( != 4
+   || !TARGET_ZERO_EXTEND_WITH_AND
+   || !optimize_function_for_speed_p (cfun))"
   [(set (match_dup 0) (zero_extend:SWI48 (match_dup 2)))])
 
 ;; Likewise, but preserving FLAGS_REG.
@@ -4324,7 +4327,10 @@
   [(set (match_operand:SWI48 0 "general_reg_operand") (const_int 0))
(set (strict_low_part (match_operand:SWI12 1 "general_reg_operand"))
(match_operand:SWI12 2 "nonimmediate_operand"))]
-  "REGNO (operands[0]) == REGNO (operands[1])"
+  "REGNO (operands[0]) == REGNO (operands[1])
+   && ( != 4
+   || !TARGET_ZERO_EXTEND_WITH_AND
+   || !optimize_function_for_speed_p (cfun))"
   [(set (match_dup 0) (zero_extend:SWI48 (match_dup 2)))])
 
 ;; Sign extension instructions
diff --git a/gcc/testsuite/gcc.target/i386/pr98335.c 
b/gcc/testsuite/gcc.target/i386/pr98335.c
index 7fa7ad7..bf731b4 100644
--- a/gcc/testsuite/gcc.target/i386/pr98335.c
+++ b/gcc/testsuite/gcc.target/i386/pr98335.c
@@ -1,5 +1,10 @@
 /* { dg-do compile } */
 /* { dg-options "-O2" } */
+/* { dg-skip-if "" { *-*-* } { "-march=i[45]86" } { "-O[sz]" } } */
+/* { dg-skip-if "" { *-*-* } { "-march=pentium" } { "-O[sz]" } } */
+/* { dg-skip-if "" { *-*-* } { "-mtune=i[45]86" } { "-O[sz]" } } */
+/* { dg-skip-if "" { *-*-* } { "-mtune=pentium" } { "-O[sz]" } } */
+
 union Data { char a; short b; };
 
 char c;

[Bug lto/104895] lto1: issue with space in library filename

[christophm30 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Christoph Müllner  ---
Compiling with '-v' shows the following differences:

BAD:
gcc -v -fPIC -flto=auto  -shared -Wl,-soname,"lib'do it'.so" -o "lib'do it'.so"
doit.o
[...]
COLLECT_GCC_OPTIONS='-v' '-fPIC' '-flto=auto' '-shared' '-o' 'lib'\''do
it'\''.so' '-mtune=generic' '-march=x86-64' '-dumpdir' 'lib'\''do it'\''.so.'
[...]
COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none'
'-v' '-fPIC' '-shared' '-mtune=generic' '-march=x86-64'  
'-fltrans-output-list=/tmp/ccfiSKsT.ltrans.out' '-fwpa=16'
'-fresolution=/tmp/ccOyShqf.res' '-flinker-output=dyn'
[...]
COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none'
'-v' '-fPIC' '-shared' '-mtune=generic' '-march=x86-64'  
'-fltrans-output-list=/tmp/ccfiSKsT.ltrans.out' '-fwpa=16'
'-fresolution=/tmp/ccOyShqf.res' '-flinker-output=dyn' '-dumpdir' './lib'\''do
it'\''.so.wpa.'
make -f /tmp/ccNUrSeQ.mk -j16 all
[...]
COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none'
'-v' '-fPIC' '-shared' '-mtune=generic' '-march=x86-64'   '-fltrans' '-o'
'/tmp/ccfiSKsT.ltrans0.ltrans.o' '-dumpdir' './libdo-'
 /usr/libexec/gcc/x86_64-redhat-linux/11/lto1 -quiet -dumpdir ./libdo-
-dumpbase ccfiSKsT.ltrans0.ltrans. -dumpbase-ext . -mtune=generic -march=x86-64
-version -fno-openmp -fno-openacc -fcf-protection=none -fPIC -fltrans it.so.
it.so.ltrans0.ltrans /tmp/ccfiSKsT.ltrans0.o -o /tmp/ccCtIFo1.s
[...]

GOOD:
gcc -v -fPIC -flto  -shared -Wl,-soname,"lib'do it'.so" -o "lib'do it'.so"
doit.o
[...]
COLLECT_GCC_OPTIONS='-v' '-fPIC' '-flto' '-shared' '-o' 'lib'\''do it'\''.so'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'lib'\''do it'\''.so.'
[...]
COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none'
'-v' '-fPIC' '-shared' '-mtune=generic' '-march=x86-64'  
'-fltrans-output-list=/tmp/ccMA9joX.ltrans.out' '-fwpa'
'-fresolution=/tmp/cceTYxPV.res' '-flinker-output=dyn'
[...]
COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none'
'-v' '-fPIC' '-shared' '-mtune=generic' '-march=x86-64'  
'-fltrans-output-list=/tmp/ccMA9joX.ltrans.out' '-fwpa'
'-fresolution=/tmp/cceTYxPV.res' '-flinker-output=dyn' '-dumpdir' './lib'\''do
it'\''.so.wpa.'
[...]
COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none'
'-v' '-fPIC' '-shared' '-mtune=generic' '-march=x86-64'   '-fltrans' '-o'
'/tmp/ccMA9joX.ltrans0.ltrans.o'
 /usr/libexec/gcc/x86_64-redhat-linux/11/lto1 -quiet -dumpbase ./lib'do
it'.so.ltrans0.ltrans -mtune=generic -march=x86-64 -version -fno-openmp
-fno-openacc -fcf-protection=none -fPIC -fltrans @/tmp/ccpufIq0 -o
/tmp/ccyVUMgZ.s

The first three differences look ok:
In the good case we have '-fwpa', and in the base case '-fwpa=16', which looks
sane.

In the last diff we can see a wrong behaviour:

In the good case we have:
* '-dumpbase ./lib'do it'.so.ltrans0.ltrans', and
* '-fltrans it.so. it.so.ltrans0.ltrans /tmp/ccfiSKsT.ltrans0.o'

In the bad case we have:
* '-dumpdir ./libdo- -dumpbase ccfiSKsT.ltrans0.ltrans. -dumpbase-ext .'
* '-fltrans @/tmp/ccpufIq0 -o /tmp/ccyVUMgZ.s'

[Bug c++/70536] g++ doesn't emit DW_AT_name for DW_TAG_GNU_formal_parameter_pack

[ed at catmur dot uk via Gcc-bugs]

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

--- Comment #3 from Ed Catmur  ---
Updated: https://github.com/gcc-mirror/gcc/compare/master...ecatmur:pr-70536

[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei

[i at rvalue dot moe via Gcc-bugs]

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

--- Comment #5 from rvalue  ---
(In reply to Kito Cheng from comment #4)
> Thanks your info, that cause by the default ISA spec version bump issue,
> binutils 2.38 and GCC 11.* using different default ISA spec cause this
> issue, I've push a patch to GCC 11 branch [1] for this issue, could you try
> this patch? thanks.
> 
> 
> See more detail for the full story about ISA spec:
> 
> https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4
> 
> [1]
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=9871d39f752bc9c114ed694662a519d04896f491

I've tried this patch just now.
Unfortunately, the gcc rebuilt reports the same error as before.

[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #17 from Segher Boessenkool  ---
Fixed.

[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Segher Boessenkool :

https://gcc.gnu.org/g:80fcc4b6afee72443bef551064826b3b4b6785e6

commit r12-7628-g80fcc4b6afee72443bef551064826b3b4b6785e6
Author: Segher Boessenkool 
Date:   Fri Mar 11 21:15:18 2022 +

rs6000: Do not use rs6000_cpu for .machine ppc and ppc64 (PR104829)

Fixes: 77eccbf39ed5

rs6000.h has
  #define PROCESSOR_POWERPC   PROCESSOR_PPC604
  #define PROCESSOR_POWERPC64 PROCESSOR_RS64A
which means that if you use things like  -mcpu=powerpc -mvsx  it will no
longer work after my latest .machine patch.  This causes GCC build errors
in some cases, not a good idea (even if the errors are actually
pre-existing: using -mvsx with a machine that does not have VSX cannot
work properly).

2022-03-11  Segher Boessenkool  

PR target/104829
* config/rs6000/rs6000.cc (rs6000_machine_from_flags): Don't output
"ppc" and "ppc64" based on rs6000_cpu.

Re: GSoC

[David Edelsohn via Gcc]

On Sat, Mar 12, 2022 at 10:40 AM Γιωργος Μελλιος via Gcc
 wrote:
>
> Greetings,
>
> I am sending this email in order to show my interest in your GSoC program
> for this summer.
> To begin with, I would like to learn some general information about your
> project in order to judge if I am capable of participating in it. I am
> currently studying Compilers and Programming Languages in my university
> (Computer Science Department, University of Crete) and I am very interested
> in it, so finding you as a GSoC organization made me extremely happy.
>
> Thanks in advance,
> Georgios Panagiotis Mellios

Hi, Georgios

Thanks for your interest in GCC.  Welcome!

A good place to start is the GCC Wiki Getting Started page:
https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development

The GSoC application process is not open yet, but you can look at
previous GSoC projects and project ideas on the GCC Wiki:

https://gcc.gnu.org/wiki/SummerOfCode

Thanks, David

Re: [PATCH, V3] PR target/99708- Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__

[Segher Boessenkool]

On Fri, Mar 11, 2022 at 05:51:05PM -0500, Michael Meissner wrote:
> On Fri, Mar 11, 2022 at 02:51:23PM -0600, Segher Boessenkool wrote:
> > On Fri, Mar 11, 2022 at 08:42:27PM +, Joseph Myers wrote:
> > > The version of this patch applied to GCC 10 branch (commit 
> > > 641b407763ecfee5d4ac86d8ffe9eb1eeea5fd10) has broken the glibc build for 
> > > powerpc64le-linux-gnu (it's fine with GCC 11 branch and master, just GCC 
> > > 10 branch is broken) 
> > 
> > Mike, please revert it then?
> 
> Ok, I will revert both the GCC 11 and GCC 10 backport once I make sure the fix
> builds.  Sorry about that.  Obviously, we will want to backport whatever we do
> shortly to the older branches.

Yes, except the "shortly".  Experience shows that we need more thorough
testing for this, which means we need to wait longer, so that other
projects have time to do their testing.  Rushing things only causes more
problems :-/


Segher

GSoC

[Γιωργος Μελλιος via Gcc]

Greetings,

I am sending this email in order to show my interest in your GSoC program
for this summer.
To begin with, I would like to learn some general information about your
project in order to judge if I am capable of participating in it. I am
currently studying Compilers and Programming Languages in my university
(Computer Science Department, University of Crete) and I am very interested
in it, so finding you as a GSoC organization made me extremely happy.

Thanks in advance,
Georgios Panagiotis Mellios

[Bug target/104890] [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu (--enable-default-pie)

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-12
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #2 from H.J. Lu  ---
I can't reproduce it with

--disable-bootstrap --enable-cet --with-demangler-in-ld 
--prefix=/usr/gcc-12.0.1-x86-64-pie --with-local-prefix=/usr/local
--enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib
--with-target-system-zlib --disable-libcc1 --disable-libcilkrts
--disable-libsanitizer --enable-default-pie --enable-languages=c,c++

Please provide the prepossessed unwind-dw2.c and show the command-line
passed to cc1 with "gcc -v".

[Bug target/104794] arm: use translation pattern for repetitive messages

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

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

--- Comment #11 from Roland Illig  ---
Thank you, looks good now.

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||joshua.england@worldprogram
   ||ming.com

--- Comment #18 from Roger Sayle  ---
*** Bug 78249 has been marked as a duplicate of this bug. ***

[Bug middle-end/78249] In consistent results for 0.0 * inf when optimizer is enabled

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Roger Sayle  ---
After a little investigating it turns out that this is a duplicate of PR
middle-end/51446.  When multiplying 0 * Inf, x86/ia64 chips return -NaN, where
other architectures return NaN.  Alas IEEE doesn't specify the sign of the NaN,
so GCC isn't "wrong", but it's odd that multiplications performed at run-time
produce
a different result to those computed at compile-time (hence the -O0 vs -O1/2/3
differences).  Ideally this should (perhaps) be controlled by a target hook.

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

[Bug lto/104895] New: lto1: issue with space in library filename

[christophm30 at gmail dot com via Gcc-bugs]

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

Bug ID: 104895
   Summary: lto1: issue with space in library filename
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophm30 at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

When building Souffle, I ran into an LTO issue with a library that contains a
space in its filename (see
https://github.com/souffle-lang/souffle/issues/2214).

I've isolated the issue as follows (Fedora 35: gcc (GCC) 11.2.1 20220127 (Red
Hat 11.2.1-9)):

Makefile:
CC=gcc
CFLAGS=-fPIC
CFLAGS:=$(CFLAGS) -flto=auto
RM=rm -f
all: ltomain

"lib do it".so: doit.o
$(CC) $(CFLAGS) $(LDFLAGS) -shared -Wl,-soname,"lib'do it'.so" -o
"lib'do it'.so" doit.o

ltomain: main.o "lib do it".so
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ main.o -L. -l"'do it'"
clean:
$(RM) *.o *.so ltomain

doit.c:
#include 
void doit(void)
{
  printf("Hello world!\n");
}
void doit();

main.c:
int main()
{
  doit();
}

This gives the following error:
$ make clean all
rm -f *.o *.so ltomain
gcc -fPIC -flto=auto   -c -o main.o main.c
gcc -fPIC -flto=auto   -c -o doit.o doit.c
gcc -fPIC -flto=auto  -shared -Wl,-soname,"lib'do it'.so" -o "lib'do it'.so"
doit.o
lto1: error: open it.so. failed: No such file or directory
make[1]: *** [/tmp/ccetIqO9.mk:2: /tmp/ccIqDtkB.ltrans0.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [Makefile:9: "lib] Error 1

Replacing '-flto=auto' by '-flto' works:
$ make clean all
rm -f *.o *.so ltomain
gcc -fPIC -flto   -c -o main.o main.c
gcc -fPIC -flto   -c -o doit.o doit.c
gcc -fPIC -flto  -shared -Wl,-soname,"lib'do it'.so" -o "lib'do it'.so" doit.o
gcc -fPIC -flto  -shared -Wl,-soname,"lib'do it'.so" -o "lib'do it'.so" doit.o
gcc -fPIC -flto  -shared -Wl,-soname,"lib'do it'.so" -o "lib'do it'.so" doit.o
gcc -fPIC -flto  -o ltomain main.o -L. -l"'do it'"

$ LD_LIBRARY_PATH=. ./ltomain
Hello world!

[Bug translation/104552] Mistakes in strings to be translated in GCC 12

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

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

--- Comment #37 from Roland Illig  ---
I'm splitting this bug report into multiple bug reports, to clean up the mess
that the 36 comments created.  It was a bad idea from the beginning. :)

[Bug middle-end/104892] OpenACC 'kernels' decomposition: wrong-code cases unless manually making certain variables addressable

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

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Schwinge  ---
.

OpenACC 'kernels' decomposition: resolve wrong-code cases unless manually making certain variables addressable [PR100280, PR104892]

[Thomas Schwinge]

Hi!

On 2022-03-12T15:54:31+0100, I wrote:
> On 2022-03-01T17:46:20+0100, I wrote:
>> On 2022-01-13T10:54:16+0100, I wrote:
>>> On 2019-05-08T14:51:57+0100, Julian Brown  wrote:
  - The "addressable" bit is set during the kernels conversion pass for
variables that have "create" (alloc) clauses created for them in the
synthesised outer data region (instead of in the front-end, etc.,
where it can't be done accurately). Such variables actually have
their address taken during transformations made in a later pass
(omp-low, I think), but there's a phase-ordering problem that means
the flag should be set earlier.
>>>
>>> The actual issue is a bit different, but yes, there is a problem.
>>> The related ICE has also been reported as 
>>> "ICE in lower_omp_target, at omp-low.c:12287".  [...]
>
> We've resolved all such known ICEs -- but still have open
>  "OpenACC 'kernels' decomposition:
> wrong-code cases unless manually making certain variables addressable".
> This is avoided by:
>
>> workaround patches like
>> we have on the og11 development branch:
>>   - "Avoid introducing 'create' mapping clauses for loop index variables in 
>> kernels regions",
>>   - "Run all kernels regions with GOMP_MAP_FORCE_TOFROM mappings 
>> synchronously",
>>   - "Fix for is_gimple_reg vars to 'data kernels'"
>
> ..., but the misbehavior is visible without the workaround patches, for
> example on the master branch.

..., and to avoid the need for those (thus, please remove for
the upcoming og12 branch, Kwok), pushed to master branch
commit a07b8f4fb756484893b5612cbe9410970dc76db9
"OpenACC 'kernels' decomposition: resolve wrong-code cases unless
manually making certain variables addressable [PR100280, PR104892]",
see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From a07b8f4fb756484893b5612cbe9410970dc76db9 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 11 Mar 2022 22:31:51 +0100
Subject: [PATCH] OpenACC 'kernels' decomposition: resolve wrong-code cases
 unless manually making certain variables addressable [PR100280, PR104892]

Currently in OpenACC 'kernels' decomposition, there is special handling of
'GOMP_MAP_FORCE_TOFROM', documented to be done to avoid "internal compiler
errors in later passes".  For performance reasons, the current repetitive
to/from device copying for every region is not ideal, compared to using
'present' clauses, as done for almost all other 'GOMP_MAP_*'.  Also, the
current special handling (incomplete, evidently) is the reason for the PR104892
misbehavior.  For PR100280 etc. we've resolved all such known ICEs -- removing
the special handling for 'GOMP_MAP_FORCE_TOFROM' now resolves PR104892.

	PR middle-end/100280
	PR middle-end/104892
	gcc/
	* omp-oacc-kernels-decompose.cc (omp_oacc_kernels_decompose_1):
	Remove special handling of 'GOMP_MAP_FORCE_TOFROM'.
	gcc/testsuite/
	* c-c++-common/goacc/kernels-decompose-2.c: Adjust.
	* c-c++-common/goacc/kernels-decompose-pr100400-1-1.c: Likewise.
	* c-c++-common/goacc/kernels-decompose-pr100400-1-2.c: Likewise.
	* c-c++-common/goacc/kernels-decompose-pr100400-1-3.c: Likewise.
	* c-c++-common/goacc/kernels-decompose-pr100400-1-4.c: Likewise.
	* c-c++-common/goacc/kernels-decompose-pr104061-1-1.c: Likewise.
	* c-c++-common/goacc/kernels-decompose-pr104061-1-2.c: Likewise.
	* c-c++-common/goacc/kernels-decompose-pr104061-1-3.c: Likewise.
	* c-c++-common/goacc/kernels-decompose-pr104061-1-4.c: Likewise.
	* c-c++-common/goacc/kernels-decompose-pr104132-1.c: Likewise.
	* c-c++-common/goacc/kernels-decompose-pr104133-1.c: Likewise.
	* c-c++-common/goacc/kernels-decompose-pr104774-1.c: Likewise.
	* gfortran.dg/goacc/classify-kernels.f95: Likewise.
	* gfortran.dg/goacc/kernels-decompose-2.f95: Likewise.
	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/declare-vla.c: Adjust.
	* testsuite/libgomp.oacc-c-c++-common/default-1.c: Likewise.
	* testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/kernels-reduction-1.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Likewise.
	* testsuite/libgomp.oacc-fortran/asyncwait-1.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/kernels-reduction-1.f90:
	Likewise.
---
 gcc/omp-oacc-kernels-decompose.cc |  1 -
 .../c-c++-common/goacc/kernels-decompose-2.c  | 32 +
 .../goacc/kernels-decompose-pr100400-1-1.c|  2 ++
 .../goacc/kernels-decompose-pr100400-1-2.c|  2 ++
 .../goacc/kernels-decompose-pr100400-1-3.c|  2 ++
 .../goacc/kernels-decompose-pr100400-1-4.c|  2 ++
 .../goacc/kernels-decompose-pr104061-1-1.c|  2 ++
 .../goacc/kernels-decompose-pr104061-1-2.c

OpenACC 'kernels' decomposition: wrong-code cases unless manually making certain variables addressable [PR104892]

[Thomas Schwinge]

Hi!

On 2022-03-01T17:46:20+0100, I wrote:
> On 2022-01-13T10:54:16+0100, I wrote:
>> On 2019-05-08T14:51:57+0100, Julian Brown  wrote:
>>>  - The "addressable" bit is set during the kernels conversion pass for
>>>variables that have "create" (alloc) clauses created for them in the
>>>synthesised outer data region (instead of in the front-end, etc.,
>>>where it can't be done accurately). Such variables actually have
>>>their address taken during transformations made in a later pass
>>>(omp-low, I think), but there's a phase-ordering problem that means
>>>the flag should be set earlier.
>>
>> The actual issue is a bit different, but yes, there is a problem.
>> The related ICE has also been reported as 
>> "ICE in lower_omp_target, at omp-low.c:12287".  [...]

We've resolved all such known ICEs -- but still have open
 "OpenACC 'kernels' decomposition:
wrong-code cases unless manually making certain variables addressable".
This is avoided by:

> workaround patches like
> we have on the og11 development branch:
>   - "Avoid introducing 'create' mapping clauses for loop index variables in 
> kernels regions",
>   - "Run all kernels regions with GOMP_MAP_FORCE_TOFROM mappings 
> synchronously",
>   - "Fix for is_gimple_reg vars to 'data kernels'"

..., but the misbehavior is visible without the workaround patches, for
example on the master branch.

Pushed to master branch commit 535afbd959bc72de85fca36ba6417f075cca1018
"OpenACC 'kernels' decomposition: wrong-code cases unless manually making
certain variables addressable [PR104892]", see attached, to "Document a
few examples of the status quo".


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 535afbd959bc72de85fca36ba6417f075cca1018 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 11 Mar 2022 15:11:25 +0100
Subject: [PATCH] OpenACC 'kernels' decomposition: wrong-code cases unless
 manually making certain variables addressable [PR104892]

Document a few examples of the status quo.

	PR middle-end/104892
	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c: Point
	to PR104892.
	* testsuite/libgomp.oacc-c-c++-common/default-1.c: Likewise,
	enable '--param=openacc-kernels=decompose' and adjust.
	* testsuite/libgomp.oacc-c-c++-common/kernels-reduction-1.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Likewise.
	* testsuite/libgomp.oacc-fortran/kernels-reduction-1.f90:
	Likewise.
---
 .../libgomp.oacc-c-c++-common/default-1.c | 14 ++--
 .../kernels-decompose-1.c |  4 +--
 .../kernels-reduction-1.c |  8 -
 .../libgomp.oacc-c-c++-common/parallel-dims.c | 34 +--
 .../kernels-reduction-1.f90   | 15 +++-
 5 files changed, 59 insertions(+), 16 deletions(-)

diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/default-1.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/default-1.c
index 0ac8d7132d4..fed65c8dccc 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/default-1.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/default-1.c
@@ -1,3 +1,5 @@
+/* { dg-additional-options "--param=openacc-kernels=decompose" } */
+
 /* { dg-additional-options "-fopt-info-all-omp" }
{ dg-additional-options "-foffload=-fopt-info-all-omp" } */
 
@@ -63,6 +65,8 @@ int test_parallel ()
 int test_kernels ()
 {
   int val = 2;
+  /*TODO  */
+  (volatile int *) 
   int ary[32];
   int ondev = 0;
 
@@ -71,12 +75,18 @@ int test_kernels ()
 
   /* val defaults to copy, ary defaults to copy.  */
 #pragma acc kernels copy(ondev) /* { dg-line l_compute[incr c_compute] } */
-  /* { dg-note {variable 'i' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} {} { target *-*-* } l_compute$c_compute } */
-  /* { dg-optimized {assigned OpenACC seq loop parallelism} {} { target *-*-* } l_compute$c_compute } */
+  /* { dg-note {variable 'ondev\.[0-9]+' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} {} { target *-*-* } l_compute$c_compute } */
+  /* { dg-note {variable 'val\.[0-9]+' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} {} { target *-*-* } l_compute$c_compute } */
   {
+/* { dg-note {beginning 'gang-single' part in OpenACC 'kernels' region} {} { target *-*-* } .+1 } */
 ondev = acc_on_device (acc_device_not_host);
+/* { dg-optimized {assigned OpenACC seq loop parallelism} {} { target { c++ && { ! __OPTIMIZE__ } } } .-1 }
+   ..., as without optimizations, we're not inlining the C++ 'acc_on_device' wrapper.  */
 #pragma acc loop /* { dg-line l_loop_i[incr 

[Bug tree-optimization/100280] ICE in lower_omp_target, at omp-low.c:12287

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

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

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

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

commit r12-7627-ga07b8f4fb756484893b5612cbe9410970dc76db9
Author: Thomas Schwinge 
Date:   Fri Mar 11 22:31:51 2022 +0100

OpenACC 'kernels' decomposition: resolve wrong-code cases unless manually
making certain variables addressable [PR100280, PR104892]

Currently in OpenACC 'kernels' decomposition, there is special handling of
'GOMP_MAP_FORCE_TOFROM', documented to be done to avoid "internal compiler
errors in later passes".  For performance reasons, the current repetitive
to/from device copying for every region is not ideal, compared to using
'present' clauses, as done for almost all other 'GOMP_MAP_*'.  Also, the
current special handling (incomplete, evidently) is the reason for the
PR104892
misbehavior.  For PR100280 etc. we've resolved all such known ICEs --
removing
the special handling for 'GOMP_MAP_FORCE_TOFROM' now resolves PR104892.

PR middle-end/100280
PR middle-end/104892
gcc/
* omp-oacc-kernels-decompose.cc (omp_oacc_kernels_decompose_1):
Remove special handling of 'GOMP_MAP_FORCE_TOFROM'.
gcc/testsuite/
* c-c++-common/goacc/kernels-decompose-2.c: Adjust.
* c-c++-common/goacc/kernels-decompose-pr100400-1-1.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr100400-1-2.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr100400-1-3.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr100400-1-4.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr104061-1-1.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr104061-1-2.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr104061-1-3.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr104061-1-4.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr104132-1.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr104133-1.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr104774-1.c: Likewise.
* gfortran.dg/goacc/classify-kernels.f95: Likewise.
* gfortran.dg/goacc/kernels-decompose-2.f95: Likewise.
libgomp/
* testsuite/libgomp.oacc-c-c++-common/declare-vla.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/default-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/kernels-reduction-1.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Likewise.
* testsuite/libgomp.oacc-fortran/asyncwait-1.f90: Likewise.
* testsuite/libgomp.oacc-fortran/kernels-reduction-1.f90:
Likewise.

[Bug middle-end/104892] OpenACC 'kernels' decomposition: wrong-code cases unless manually making certain variables addressable

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

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

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

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

commit r12-7627-ga07b8f4fb756484893b5612cbe9410970dc76db9
Author: Thomas Schwinge 
Date:   Fri Mar 11 22:31:51 2022 +0100

OpenACC 'kernels' decomposition: resolve wrong-code cases unless manually
making certain variables addressable [PR100280, PR104892]

Currently in OpenACC 'kernels' decomposition, there is special handling of
'GOMP_MAP_FORCE_TOFROM', documented to be done to avoid "internal compiler
errors in later passes".  For performance reasons, the current repetitive
to/from device copying for every region is not ideal, compared to using
'present' clauses, as done for almost all other 'GOMP_MAP_*'.  Also, the
current special handling (incomplete, evidently) is the reason for the
PR104892
misbehavior.  For PR100280 etc. we've resolved all such known ICEs --
removing
the special handling for 'GOMP_MAP_FORCE_TOFROM' now resolves PR104892.

PR middle-end/100280
PR middle-end/104892
gcc/
* omp-oacc-kernels-decompose.cc (omp_oacc_kernels_decompose_1):
Remove special handling of 'GOMP_MAP_FORCE_TOFROM'.
gcc/testsuite/
* c-c++-common/goacc/kernels-decompose-2.c: Adjust.
* c-c++-common/goacc/kernels-decompose-pr100400-1-1.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr100400-1-2.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr100400-1-3.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr100400-1-4.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr104061-1-1.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr104061-1-2.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr104061-1-3.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr104061-1-4.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr104132-1.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr104133-1.c: Likewise.
* c-c++-common/goacc/kernels-decompose-pr104774-1.c: Likewise.
* gfortran.dg/goacc/classify-kernels.f95: Likewise.
* gfortran.dg/goacc/kernels-decompose-2.f95: Likewise.
libgomp/
* testsuite/libgomp.oacc-c-c++-common/declare-vla.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/default-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/kernels-reduction-1.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Likewise.
* testsuite/libgomp.oacc-fortran/asyncwait-1.f90: Likewise.
* testsuite/libgomp.oacc-fortran/kernels-reduction-1.f90:
Likewise.

[Bug middle-end/104892] OpenACC 'kernels' decomposition: wrong-code cases unless manually making certain variables addressable

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

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

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

https://gcc.gnu.org/g:535afbd959bc72de85fca36ba6417f075cca1018

commit r12-7626-g535afbd959bc72de85fca36ba6417f075cca1018
Author: Thomas Schwinge 
Date:   Fri Mar 11 15:11:25 2022 +0100

OpenACC 'kernels' decomposition: wrong-code cases unless manually making
certain variables addressable [PR104892]

Document a few examples of the status quo.

PR middle-end/104892
libgomp/
* testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c: Point
to PR104892.
* testsuite/libgomp.oacc-c-c++-common/default-1.c: Likewise,
enable '--param=openacc-kernels=decompose' and adjust.
* testsuite/libgomp.oacc-c-c++-common/kernels-reduction-1.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Likewise.
* testsuite/libgomp.oacc-fortran/kernels-reduction-1.f90:
Likewise.

[Bug c/104894] New: [ppc64le] gcc11 ICE with -fno-plt

[rafaelcfsousa at ibm dot com via Gcc-bugs]

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

Bug ID: 104894
   Summary: [ppc64le] gcc11 ICE with -fno-plt
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafaelcfsousa at ibm dot com
  Target Milestone: ---

When I use the flag "-fno-plt" together with "-O2 -mcpu=power10" on gcc11, the
compilation fails.

Some important points:
- The ICE shows up only when I use optimization level -O2 or higher
- If I replace "-mcpu=power10" by "-mcpu=power9", the compilation works fine
- The same error does not happen on gcc10

gcc version:
- gcc (GCC) 11.2.1 20220312 [remotes/origin/releases/gcc-11 revision
6f581f90e3:53ab7b79c6:908e612067e42ded881db10d38768f23307bf55e]
- gcc (GCC) 11.2.1 20220211 (Advance-Toolchain 15.0-2) [64575dfb22ae]
- gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1)
- gcc (GCC) 12.0.1 20220312 (experimental) [remotes/origin/HEAD
r12-7622-g828335beb7]
The error shows up on all GCCs above.

the system type: ppc64le (powerpc64le-unknown-linux-gnu)

Configured with: /home/gccbuild/gcc_11_git/gcc/configure
--prefix=/opt/gcc-nightly/11 --with-as=/home/gccbuild/binutils/install/bin/as
--with-ld=/home/gccbuild/binutils/install/bin/ld
--enable-languages=c,c++,fortran,objc,obj-c++ --with-cpu=power10

source file:
issue.c
```
void foo();

void bar() {
   foo();
}
```

the complete command line that triggers the bug:
gcc -O3 -mcpu=power10 -mtune=power10 -fno-plt -c issue.c -o issue.o


the compiler output (error messages, warnings, etc.):
during RTL pass: expand
issue.c: In function ‘bar’:
issue.c:4:4: internal compiler error: in rs6000_sibcall_aix, at
config/rs6000/rs6000.cc:25654
4 |foo();
  |^
0x11073563 rs6000_sibcall_aix(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
/home/gccbuild/gcc_trunk_git/gcc/gcc/config/rs6000/rs6000.cc:25654
0x116acc5f gen_sibcall(rtx_def*, rtx_def*, rtx_def*)
/home/gccbuild/gcc_trunk_git/gcc/gcc/config/rs6000/rs6000.md:11573
0x1104f17f target_gen_sibcall
/home/gccbuild/gcc_trunk_git/gcc/gcc/config/rs6000/rs6000.md:13266
0x10486a0f emit_call_1
/home/gccbuild/gcc_trunk_git/gcc/gcc/calls.cc:469
0x1048f363 expand_call(tree_node*, rtx_def*, int)
/home/gccbuild/gcc_trunk_git/gcc/gcc/calls.cc:3608
0x106614eb expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/gccbuild/gcc_trunk_git/gcc/gcc/expr.cc:11539
0x104b0887 expand_expr
/home/gccbuild/gcc_trunk_git/gcc/gcc/expr.h:301
0x104b0887 expand_call_stmt
/home/gccbuild/gcc_trunk_git/gcc/gcc/cfgexpand.cc:2831
0x104b0887 expand_gimple_stmt_1
/home/gccbuild/gcc_trunk_git/gcc/gcc/cfgexpand.cc:3869
0x104b0887 expand_gimple_stmt
/home/gccbuild/gcc_trunk_git/gcc/gcc/cfgexpand.cc:4033
0x104b850b expand_gimple_tailcall
/home/gccbuild/gcc_trunk_git/gcc/gcc/cfgexpand.cc:4079
0x104b850b expand_gimple_basic_block
/home/gccbuild/gcc_trunk_git/gcc/gcc/cfgexpand.cc:6054
0x104ba5d7 execute
/home/gccbuild/gcc_trunk_git/gcc/gcc/cfgexpand.cc:6806
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


using --save-temps:
issue.s
```
.file   "issue.c"
.machinepower10
.abiversion 2
.section".text"
```

issue.i
```
# 0 "issue.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "issue.c"
void foo();

void bar() {
   foo();
}
```

[Bug target/104893] New: [nvptx] Handle Independent Thread Scheduling for sm_70+ with -msoft-stack

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

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

Bug ID: 104893
   Summary: [nvptx] Handle Independent Thread Scheduling for
sm_70+ with -msoft-stack
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

We use -msoft-stack for openmp programs:
...
'-msoft-stack'
 Generate code that does not use '.local' memory directly for stack
 storage.  Instead, a per-warp stack pointer is maintained
 explicitly.  This enables variable-length stack allocation (with
 variable-length arrays or 'alloca'), and when global memory is used
 for underlying storage, makes it possible to access automatic
 variables from other threads, or with atomic instructions.
...

Starting with sm_70, we have Independent Thread Scheduling: "the GPU maintains
execution state per thread, including a program counter and call stack".

The per-thread call stack is handled for .local memory by the CUDA driver.

For the 'soft stack' that's not the case.  So, it's possible that different
threads start to read and write values to a stack address that is meant to be
thread private, but which in reality is shared between all threads in the warp.

Enhance further testcases to verify handling of OpenACC privatization level [PR90115]

[Thomas Schwinge]

Hi!

On 2021-05-21T21:29:19+0200, I wrote:
> I've pushed "[OpenACC privatization] Largely extend diagnostics and
> corresponding testsuite coverage [PR90115]" to master branch in commit
> 11b8286a83289f5b54e813f14ff56d730c3f3185

To demonstrate that later changes don't vs. how they do change things,
pushed to master branch commit 2e53fa7bb2ae9fe1152c27e423be9e261da82ddc
"Enhance further testcases to verify handling of OpenACC privatization
level [PR90115]", see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 2e53fa7bb2ae9fe1152c27e423be9e261da82ddc Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 11 Mar 2022 15:10:59 +0100
Subject: [PATCH] Enhance further testcases to verify handling of OpenACC
 privatization level [PR90115]

As originally introduced in commit 11b8286a83289f5b54e813f14ff56d730c3f3185
"[OpenACC privatization] Largely extend diagnostics and corresponding testsuite
coverage [PR90115]".

	PR middle-end/90115
	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/default-1.c: Enhance.
	* testsuite/libgomp.oacc-c-c++-common/kernels-reduction-1.c: Likewise.
	* testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Likewise.
	* testsuite/libgomp.oacc-fortran/kernels-reduction-1.f90: Likewise.
---
 .../libgomp.oacc-c-c++-common/default-1.c |  32 ++-
 .../kernels-reduction-1.c |  14 +-
 .../libgomp.oacc-c-c++-common/parallel-dims.c | 261 +++---
 .../kernels-reduction-1.f90   |  14 +-
 4 files changed, 266 insertions(+), 55 deletions(-)

diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/default-1.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/default-1.c
index 1ac0b9587b9..0ac8d7132d4 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/default-1.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/default-1.c
@@ -1,4 +1,18 @@
-/* { dg-do run } */
+/* { dg-additional-options "-fopt-info-all-omp" }
+   { dg-additional-options "-foffload=-fopt-info-all-omp" } */
+
+/* { dg-additional-options "--param=openacc-privatization=noisy" }
+   { dg-additional-options "-foffload=--param=openacc-privatization=noisy" }
+   Prune a few: uninteresting, and potentially varying depending on GCC configuration (data types):
+   { dg-prune-output {note: variable 'D\.[0-9]+' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} } */
+
+/* It's only with Tcl 8.5 (released in 2007) that "the variable 'varName'
+   passed to 'incr' may be unset, and in that case, it will be set to [...]",
+   so to maintain compatibility with earlier Tcl releases, we manually
+   initialize counter variables:
+   { dg-line l_dummy[variable c_compute 0 c_loop_i 0] }
+   { dg-message dummy {} { target iN-VAl-Id } l_dummy } to avoid
+   "WARNING: dg-line var l_dummy defined, but not used".  */
 
 #include  
 
@@ -13,10 +27,15 @@ int test_parallel ()
 ary[i] = ~0;
 
   /* val defaults to firstprivate, ary defaults to copy.  */
-#pragma acc parallel num_gangs (32) copy (ok) copy(ondev)
+#pragma acc parallel num_gangs (32) copy (ok) copy(ondev) /* { dg-line l_compute[incr c_compute] } */
+  /* { dg-note {variable 'i' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} {} { target *-*-* } l_compute$c_compute } */
   {
 ondev = acc_on_device (acc_device_not_host);
-#pragma acc loop gang(static:1)
+/* { dg-optimized {assigned OpenACC seq loop parallelism} {} { target { c++ && { ! __OPTIMIZE__ } } } .-1 }
+   ..., as without optimizations, we're not inlining the C++ 'acc_on_device' wrapper.  */
+#pragma acc loop gang(static:1) /* { dg-line l_loop_i[incr c_loop_i] } */
+/* { dg-note {variable 'i' in 'private' clause isn't candidate for adjusting OpenACC privatization level: not addressable} {} { target *-*-* } l_loop_i$c_loop_i } */
+/* { dg-optimized {assigned OpenACC gang loop parallelism} {} { target *-*-* } l_loop_i$c_loop_i } */
 for (unsigned i = 0; i < 32; i++)
   {
 	if (val != 2)
@@ -51,10 +70,13 @@ int test_kernels ()
 ary[i] = ~0;
 
   /* val defaults to copy, ary defaults to copy.  */
-#pragma acc kernels copy(ondev)
+#pragma acc kernels copy(ondev) /* { dg-line l_compute[incr c_compute] } */
+  /* { dg-note {variable 'i' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} {} { target *-*-* } l_compute$c_compute } */
+  /* { dg-optimized {assigned OpenACC seq loop parallelism} {} { target *-*-* } l_compute$c_compute } */
   {
 ondev = acc_on_device (acc_device_not_host);
-#pragma acc loop 
+#pragma acc loop /* { dg-line l_loop_i[incr c_loop_i] } */
+/* { dg-note {variable 'i' in 'private' clause isn't candidate for adjusting OpenACC privatization level: not 

[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks

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

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

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

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

commit r12-7625-g2e53fa7bb2ae9fe1152c27e423be9e261da82ddc
Author: Thomas Schwinge 
Date:   Fri Mar 11 15:10:59 2022 +0100

Enhance further testcases to verify handling of OpenACC privatization level
[PR90115]

As originally introduced in commit 11b8286a83289f5b54e813f14ff56d730c3f3185
"[OpenACC privatization] Largely extend diagnostics and corresponding
testsuite
coverage [PR90115]".

PR middle-end/90115
libgomp/
* testsuite/libgomp.oacc-c-c++-common/default-1.c: Enhance.
* testsuite/libgomp.oacc-c-c++-common/kernels-reduction-1.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Likewise.
* testsuite/libgomp.oacc-fortran/kernels-reduction-1.f90: Likewise.

[Bug middle-end/104892] New: OpenACC 'kernels' decomposition: wrong-code cases unless manually making certain variables addressable

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

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

Bug ID: 104892
   Summary: OpenACC 'kernels' decomposition: wrong-code cases
unless manually making certain variables addressable
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: openacc, wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Even with the PR100280 etc. ICEs fixed, we still have the problem that we
generate wrong code in certain scenarios.  For example, see the remark in
current 'libgomp.oacc-c-c++-common/kernels-decompose-1.c' that "Without making
'[...]' addressable, [...] we will not see the expected value copied out".

[Bug middle-end/104086] ICE in lower_omp_target, at omp-low.c:13075

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
  Component|tree-optimization   |middle-end
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from Thomas Schwinge  ---
.

OpenACC 'kernels' decomposition: Mark variables used in 'present' clauses as addressable [PR100280, PR104086]

[Thomas Schwinge]

Hi!

On 2022-03-12T13:38:38+0100, I wrote:
> On 2020-11-13T23:22:30+0100, I wrote:
>> On 2019-02-01T00:59:30+0100, I wrote:
>>> I've just pushed the attached nine patches to openacc-gcc-8-branch:
>>> OpenACC 'kernels' construct changes: splitting of the construct into
>>> several regions.
>>
>> Now, slightly more polished, I've pushed to master branch a variant of
>> most of these patches combined in commit
>> e898ce7997733c29dcab9c3c62ca102c7f9fa6eb "Decompose OpenACC 'kernels'
>> constructs into parts, a sequence of compute constructs", see attached.
>>
>>> There's more work to be done there, and we're aware of a number of TODO
>>> items, but nevertheless: it's a good first step.
>>
>> That's still the case...  :-)
>
>> --- /dev/null
>> +++ 
>> b/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose-ice-1.c
>> @@ -0,0 +1,8 @@
>> +/* { dg-additional-options "-fopenacc-kernels=decompose" } */
>> +/* Hopefully, this is the same issue as 
>> '../../../gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-1.c'.

(Related, but not the same.)

>> +   { dg-ice "TODO" }
>> +   TODO { dg-prune-output "during GIMPLE pass: omplower" }
>> +   TODO { dg-do link } */
>> +
>> +#undef KERNELS_DECOMPOSE_ICE_HACK
>> +#include "declare-vla.c"
>
> Arseny had later reduced that, and filed .
> To document the status quo, pushed to master branch
> commit 9781ae3a254a8c17ef4ffa70f21ed1728ff3c707
> "Add 'c-c++-common/goacc/kernels-decompose-pr104086-1.c' [PR104086]"

>> --- /dev/null
>> +++ 
>> b/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose.c
>> @@ -0,0 +1,6 @@
>> +/* { dg-additional-options "-fopenacc-kernels=decompose" } */
>> +
>> +/* See also 'declare-vla-kernels-decompose-ice-1.c'.  */
>> +
>> +#define KERNELS_DECOMPOSE_ICE_HACK
>> +#include "declare-vla.c"

>> --- a/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla.c
>> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla.c
>> @@ -38,6 +38,12 @@ f_data (void)
>>  for (i = 0; i < N; i++)
>>A[i] = -i;
>>
>> +/* See 'declare-vla-kernels-decompose.c'.  */
>> +#ifdef KERNELS_DECOMPOSE_ICE_HACK
>> +(volatile int *) 
>> +(volatile int *) 
>> +#endif
>> +
>>  # pragma acc kernels
>>  for (i = 0; i < N; i++)
>>A[i] = i;

Pushed to master branch commit 337ed336d7dd83526891bdb436f0bfe9e351f69d
"OpenACC 'kernels' decomposition: Mark variables used in 'present'
clauses as addressable [PR100280, PR104086]", see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 337ed336d7dd83526891bdb436f0bfe9e351f69d Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 17 Feb 2022 14:18:57 +0100
Subject: [PATCH] OpenACC 'kernels' decomposition: Mark variables used in
 'present' clauses as addressable [PR100280, PR104086]

... like in recent commit 9b32c1669aad5459dd053424f9967011348add83
"OpenACC 'kernels' decomposition: Mark variables used in synthesized
data clauses as addressable [PR100280]".  Otherwise, we may run into
'gcc/omp-low.cc:lower_omp_target':

13125   else if (is_gimple_reg (var))
13126 {
13127   gcc_assert (offloaded);

	PR middle-end/100280
	PR middle-end/104086
	gcc/
	* omp-oacc-kernels-decompose.cc (omp_oacc_kernels_decompose_1):
	Mark variables used in 'present' clauses as addressable.
	* omp-low.cc (scan_sharing_clauses) : Gracefully
	handle duplicate 'OMP_CLAUSE_MAP_DECL_MAKE_ADDRESSABLE'.
	gcc/testsuite/
	* c-c++-common/goacc/kernels-decompose-pr104086-1.c: Adjust,
	extend.
	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose-ice-1.c:
	Merge this...
	* testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose.c:
	..., and this...
	* testsuite/libgomp.oacc-c-c++-common/declare-vla.c: ... into
	this, and adjust.
	* testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c:
	Extend.
---
 gcc/omp-low.cc| 27 +---
 gcc/omp-oacc-kernels-decompose.cc | 32 +
 .../goacc/kernels-decompose-pr104086-1.c  | 37 +--
 .../declare-vla-kernels-decompose-ice-1.c | 22 ---
 .../declare-vla-kernels-decompose.c   | 29 
 .../libgomp.oacc-c-c++-common/declare-vla.c   | 38 ++-
 .../kernels-decompose-1.c | 66 ++-
 7 files changed, 168 insertions(+), 83 deletions(-)
 delete mode 100644 libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose-ice-1.c
 delete mode 100644 libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose.c

diff --git a/gcc/omp-low.cc b/gcc/omp-low.cc
index d932d74cb03..cfc63d6a104 100644
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ 

[Bug debug/104891] New: Possibly wrong location definition in DWARF with -fschedule-insns2 at -O2/-O3

[assaiante at diag dot uniroma1.it via Gcc-bugs]

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

Bug ID: 104891
   Summary: Possibly wrong location definition in DWARF with
-fschedule-insns2 at -O2/-O3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: assaiante at diag dot uniroma1.it
  Target Milestone: ---

In this minimized C example variables l_29 and l_30, which are defined and used
in the scope within brackets spanning lines 4-8, are associated to DWARF
symbols having a possibly wrong location definition, which causes variables to
not be available during debugging, despite their DIEs being correctly defined.
We observe the bug at -O2 and -O3 with the cause likely being
-fschedule-insns2. Please find below a detailed analysis for -O3 on x64,
including a comparison with prior gcc versions where the bug is sometimes not
present.

$ cat a.c
volatile char a;
int main() {
  int print_hash_value = 0;
  {
int l_29 = 7, l_30 = 9551615;
a = l_30 >= l_29;
printf("%X\n", 0);
  }
}

GCC and GDB version (GCC commit id: 500d3f0a302):
$ gcc --version
gcc (GCC) 12.0.0 20211227 (experimental)
Copyright (C) 2021 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.

$ gdb --version
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

GDB trace:
$ gcc -O3 -g a.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 6
Breakpoint 1 at 0x400410: file a.c, line 6.
(gdb) r
Starting program: /home/stepping/debuginfo-analysis/dd-mismatches/66/reduce/opt 

Breakpoint 1, main () at a.c:6
6   a = l_30 >= l_29;
(gdb) info locals
print_hash_value = 0

By dumping the DWARF info, we can see how the location of the lexical block
associated to the inner scope is defined by ranges where the first one is empty
(400410-400410), while the values for l_29 and l_30 are correctly specified:

ASM:
00400410 :
  400410:   48 83 ec 08 sub$0x8,%rsp
  400414:   31 f6   xor%esi,%esi
  400416:   bf a4 05 40 00  mov$0x4005a4,%edi
  40041b:   31 c0   xor%eax,%eax
  40041d:   c6 05 0d 0c 20 00 01movb   $0x1,0x200c0d(%rip)#
601031 
  400424:   e8 d7 ff ff ff  call   400400 
  400429:   31 c0   xor%eax,%eax
  40042b:   48 83 c4 08 add$0x8,%rsp
  40042f:   c3  ret 

DWARF info:
0x007d: DW_TAG_lexical_block
  DW_AT_ranges  (0x000c
 [0x00400410, 0x00400410)
 [0x00400414, 0x00400429))

0x0082:   DW_TAG_variable
DW_AT_name  ("l_29")
DW_AT_decl_file ("/home/test/dd/66/reduce/a.c")
DW_AT_decl_line (5)
DW_AT_decl_column   (0x09)
DW_AT_type  (0x00d6 "int")
DW_AT_const_value   (0x07)

0x008e:   DW_TAG_variable
DW_AT_name  ("l_30")
DW_AT_decl_file ("/home/test/dd/66/reduce/a.c")
DW_AT_decl_line (5)
DW_AT_decl_column   (0x13)
DW_AT_type  (0x00d6 "int")
DW_AT_const_value   (0x0091beff)

When we manually patch the first range to be (400410-400414), the variables are
displayed correctly in gdb.

Through some testing we found out that the optimization flag that introduces
the bug is likely -fschedule-insns2. If we add -fno-schedule-insns2 to the
compilation command line used above, variables l_29 and l_30 appear in the
current frame with their values correctly available at line 6. The location of
the lexical block appears now to be correctly defined (see low pc and high pc
attributes):

ASM with -fno-schedule-insns2:
00400410 :
  400410:   48 83 ec 08 sub$0x8,%rsp
  400414:   c6 05 16 0c 20 00 01movb   $0x1,0x200c16(%rip)#
601031 
  40041b:   31 f6   xor%esi,%esi
  40041d:   bf a4 05 40 00  mov$0x4005a4,%edi
  400422:   31 c0   xor%eax,%eax
  400424:   e8 d7 ff ff ff  call   400400 
  400429:   31 c0   xor%eax,%eax
  40042b:   48 83 c4 08 add$0x8,%rsp
  40042f:   c3  ret

DWARF info with -fno-schedule-insns2:
0x007d: DW_TAG_lexical_block
  DW_AT_low_pc  

Add 'c-c++-common/goacc/kernels-decompose-pr104086-1.c' [PR104086]

[Thomas Schwinge]

Hi!

On 2020-11-13T23:22:30+0100, I wrote:
> On 2019-02-01T00:59:30+0100, I wrote:
>> I've just pushed the attached nine patches to openacc-gcc-8-branch:
>> OpenACC 'kernels' construct changes: splitting of the construct into
>> several regions.
>
> Now, slightly more polished, I've pushed to master branch a variant of
> most of these patches combined in commit
> e898ce7997733c29dcab9c3c62ca102c7f9fa6eb "Decompose OpenACC 'kernels'
> constructs into parts, a sequence of compute constructs", see attached.
>
>> There's more work to be done there, and we're aware of a number of TODO
>> items, but nevertheless: it's a good first step.
>
> That's still the case...  :-)

> --- /dev/null
> +++ 
> b/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose-ice-1.c
> @@ -0,0 +1,8 @@
> +/* { dg-additional-options "-fopenacc-kernels=decompose" } */
> +/* Hopefully, this is the same issue as 
> '../../../gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-1.c'.
> +   { dg-ice "TODO" }
> +   TODO { dg-prune-output "during GIMPLE pass: omplower" }
> +   TODO { dg-do link } */
> +
> +#undef KERNELS_DECOMPOSE_ICE_HACK
> +#include "declare-vla.c"

Arseny had later reduced that, and filed .
To document the status quo, pushed to master branch
commit 9781ae3a254a8c17ef4ffa70f21ed1728ff3c707
"Add 'c-c++-common/goacc/kernels-decompose-pr104086-1.c' [PR104086]",
see attached.


Grüße
 Thomas


> --- /dev/null
> +++ 
> b/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose.c
> @@ -0,0 +1,6 @@
> +/* { dg-additional-options "-fopenacc-kernels=decompose" } */
> +
> +/* See also 'declare-vla-kernels-decompose-ice-1.c'.  */
> +
> +#define KERNELS_DECOMPOSE_ICE_HACK
> +#include "declare-vla.c"

> --- a/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla.c
> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla.c
> @@ -38,6 +38,12 @@ f_data (void)
>  for (i = 0; i < N; i++)
>A[i] = -i;
>
> +/* See 'declare-vla-kernels-decompose.c'.  */
> +#ifdef KERNELS_DECOMPOSE_ICE_HACK
> +(volatile int *) 
> +(volatile int *) 
> +#endif
> +
>  # pragma acc kernels
>  for (i = 0; i < N; i++)
>A[i] = i;


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 9781ae3a254a8c17ef4ffa70f21ed1728ff3c707 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 18 Jan 2022 17:22:14 +0100
Subject: [PATCH] Add 'c-c++-common/goacc/kernels-decompose-pr104086-1.c'
 [PR104086]

..., currently XFAILed with 'dg-ice', as it runs into
'gcc/omp-low.cc:lower_omp_target':

13125			else if (is_gimple_reg (var))
13126			  {
13127			gcc_assert (offloaded);

This means, the recent PR100280 etc. changes are still not sufficient.

	gcc/testsuite/
	PR middle-end/104086
	* c-c++-common/goacc/kernels-decompose-pr104086-1.c: New file.
---
 .../goacc/kernels-decompose-pr104086-1.c  | 25 +++
 1 file changed, 25 insertions(+)
 create mode 100644 gcc/testsuite/c-c++-common/goacc/kernels-decompose-pr104086-1.c

diff --git a/gcc/testsuite/c-c++-common/goacc/kernels-decompose-pr104086-1.c b/gcc/testsuite/c-c++-common/goacc/kernels-decompose-pr104086-1.c
new file mode 100644
index 000..eab10cf6c72
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/goacc/kernels-decompose-pr104086-1.c
@@ -0,0 +1,25 @@
+/* Reduced from 'libgomp.oacc-c-c++-common/declare-vla.c'.  */
+
+/* { dg-additional-options "-fchecking" }
+   { dg-ice TODO }
+   { dg-prune-output {during GIMPLE pass: omplower} } */
+
+/* { dg-additional-options "--param openacc-kernels=decompose" } */
+
+/* { dg-additional-options "-fopt-info-all-omp" } */
+
+/* { dg-additional-options "--param=openacc-privatization=noisy" } */
+
+void
+foo (void)
+{
+#pragma acc data /* { dg-line l_data1 } */
+  /* { dg-bogus {note: variable 'i' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} {TODO 'data'} { xfail *-*-* } l_data1 } */
+  {
+int i;
+
+#pragma acc kernels
+/* { dg-note {beginning 'gang-single' part in OpenACC 'kernels' region} {} { target *-*-* } .+1 } */
+i = 0;
+  }
+}
-- 
2.34.1

[Bug tree-optimization/104086] ICE in lower_omp_target, at omp-low.c:13075

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

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

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

https://gcc.gnu.org/g:337ed336d7dd83526891bdb436f0bfe9e351f69d

commit r12-7624-g337ed336d7dd83526891bdb436f0bfe9e351f69d
Author: Thomas Schwinge 
Date:   Thu Feb 17 14:18:57 2022 +0100

OpenACC 'kernels' decomposition: Mark variables used in 'present' clauses
as addressable [PR100280, PR104086]

... like in recent commit 9b32c1669aad5459dd053424f9967011348add83
"OpenACC 'kernels' decomposition: Mark variables used in synthesized
data clauses as addressable [PR100280]".  Otherwise, we may run into
'gcc/omp-low.cc:lower_omp_target':

13125   else if (is_gimple_reg (var))
13126 {
13127   gcc_assert (offloaded);

PR middle-end/100280
PR middle-end/104086
gcc/
* omp-oacc-kernels-decompose.cc (omp_oacc_kernels_decompose_1):
Mark variables used in 'present' clauses as addressable.
* omp-low.cc (scan_sharing_clauses) : Gracefully
handle duplicate 'OMP_CLAUSE_MAP_DECL_MAKE_ADDRESSABLE'.
gcc/testsuite/
* c-c++-common/goacc/kernels-decompose-pr104086-1.c: Adjust,
extend.
libgomp/
*
testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose-ice-1.c:
Merge this...
*
testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose.c:
..., and this...
* testsuite/libgomp.oacc-c-c++-common/declare-vla.c: ... into
this, and adjust.
* testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c:
Extend.

[Bug tree-optimization/100280] ICE in lower_omp_target, at omp-low.c:12287

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

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

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

https://gcc.gnu.org/g:337ed336d7dd83526891bdb436f0bfe9e351f69d

commit r12-7624-g337ed336d7dd83526891bdb436f0bfe9e351f69d
Author: Thomas Schwinge 
Date:   Thu Feb 17 14:18:57 2022 +0100

OpenACC 'kernels' decomposition: Mark variables used in 'present' clauses
as addressable [PR100280, PR104086]

... like in recent commit 9b32c1669aad5459dd053424f9967011348add83
"OpenACC 'kernels' decomposition: Mark variables used in synthesized
data clauses as addressable [PR100280]".  Otherwise, we may run into
'gcc/omp-low.cc:lower_omp_target':

13125   else if (is_gimple_reg (var))
13126 {
13127   gcc_assert (offloaded);

PR middle-end/100280
PR middle-end/104086
gcc/
* omp-oacc-kernels-decompose.cc (omp_oacc_kernels_decompose_1):
Mark variables used in 'present' clauses as addressable.
* omp-low.cc (scan_sharing_clauses) : Gracefully
handle duplicate 'OMP_CLAUSE_MAP_DECL_MAKE_ADDRESSABLE'.
gcc/testsuite/
* c-c++-common/goacc/kernels-decompose-pr104086-1.c: Adjust,
extend.
libgomp/
*
testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose-ice-1.c:
Merge this...
*
testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose.c:
..., and this...
* testsuite/libgomp.oacc-c-c++-common/declare-vla.c: ... into
this, and adjust.
* testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c:
Extend.

[Bug tree-optimization/104086] ICE in lower_omp_target, at omp-low.c:13075

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

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

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

https://gcc.gnu.org/g:9781ae3a254a8c17ef4ffa70f21ed1728ff3c707

commit r12-7623-g9781ae3a254a8c17ef4ffa70f21ed1728ff3c707
Author: Thomas Schwinge 
Date:   Tue Jan 18 17:22:14 2022 +0100

Add 'c-c++-common/goacc/kernels-decompose-pr104086-1.c' [PR104086]

..., currently XFAILed with 'dg-ice', as it runs into
'gcc/omp-low.cc:lower_omp_target':

13125   else if (is_gimple_reg (var))
13126 {
13127   gcc_assert (offloaded);

This means, the recent PR100280 etc. changes are still not sufficient.

gcc/testsuite/
PR middle-end/104086
* c-c++-common/goacc/kernels-decompose-pr104086-1.c: New file.

[Bug target/104890] [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu

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

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

--- Comment #1 from Matthias Klose  ---
that is only seen when configuring with --enable-default-pie

Re: [PATCH RFC] mips: add TARGET_ZERO_CALL_USED_REGS hook [PR104817, PR104820]

[Xi Ruoyao via Gcc-patches]

On Fri, 2022-03-11 at 21:26 +, Qing Zhao wrote:
> Hi, Ruoyao,
> 
> (I might not be able to reply to this thread till next Wed due to a
> short vacation).
> 
> First, some comments on opening bugs against Gcc:
> 
> I took a look at the bug reports PR104817 and PR104820:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104820
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104817
> 
> I didn’t see a testing case and a script to repeat the error, so I
> cannot repeat the error at my side.

I've put the test case, but maybe you didn't see it because it is too
simple:

echo 'int t() {}' | /home/xry111/git-repos/gcc-test-mips/gcc/cc1 -nostdinc 
-fzero-call-used-regs=all

An empty function is enough to break -fzero-call-used-regs=all.  And if
you append -mips64r2 to the cc1 command line you'll get 104820.  I
enabled 4 existing tests for MIPS (reported "not work" on MIPS) in the
patch so I think it's unnecessary to add new test cases.

Richard: can we use MIPS_EPILOGUE_TEMP as a scratch register in the
sequence for zeroing the call-used registers, and then zero itself
(despite it's not in need_zeroed_hardregs)?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

[Bug target/104890] New: [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu

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

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

Bug ID: 104890
   Summary: [12 Regression] fails to build the 32bit libgcc on
x86_64-linux-gnu
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk 20220312 fails to build the 32bit libgcc on x86_64-linux-gnu:

/home/packages/gcc/12/gcc-12-12-20220312/build/./gcc/xgcc
-B/home/packages/gcc/12/gcc-12-12-20220312/build/./gcc/ -B/usr/x86_6
4-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem
/usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-includ
e -isystem /home/packages/gcc/12/gcc-12-12-20220312/build/sys-include  
-fchecking=1 -g -O2 -m32 -O2  -g -O2 -DIN_GCC-W -W
all -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./inc
lude  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  
-fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I.
-I../../.././gcc -I../../../../src/libgcc -I../../../.
./src/libgcc/. -I../../../../src/libgcc/../gcc
-I../../../../src/libgcc/../include -I../../../../src/libgcc/config/libbid -DEN
ABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS  -o unwind-dw2.o -MT
unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c 
../../../../src/libgcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from
/home/packages/gcc/12/gcc-12-12-20220312/build/gcc/include/x86gprintrin.h:45,
 from
../../../../src/libgcc/config/i386/shadow-stack-unwind.h:25,
 from ./md-unwind-support.h:27,
 from ../../../../src/libgcc/unwind-dw2.c:412:
/home/packages/gcc/12/gcc-12-12-20220312/build/gcc/include/cetintrin.h: In
function '_Unwind_RaiseException':
/home/packages/gcc/12/gcc-12-12-20220312/build/gcc/include/cetintrin.h:47:1:
error: inlining failed in call to 'always_inline' '_get_ssp': target specific
option mismatch
   47 | _get_ssp (void)
  | ^~~~
../../../../src/libgcc/config/i386/shadow-stack-unwind.h:32:26: note: called
from here
   32 |   _Unwind_Word ssp = _get_ssp ();   \
  |  ^~~
../../../../src/libgcc/unwind-dw2.c:1654:7: note: in expansion of macro
'_Unwind_Frames_Extra'
 1654 |   _Unwind_Frames_Extra (FRAMES);   
\
  |   ^~~~
../../../../src/libgcc/unwind.inc:140:3: note: in expansion of macro
'uw_install_context'
  140 |   uw_install_context (_context, _context, frames);
  |   ^~
/home/packages/gcc/12/gcc-12-12-20220312/build/gcc/include/cetintrin.h:55:1:
error: inlining failed in call to 'always_inline' '_inc_ssp': target specific
option mismatch
   55 | _inc_ssp (unsigned int __B)
  | ^~~~
../../../../src/libgcc/config/i386/shadow-stack-unwind.h:38:15: note: called
from here
   38 |   _inc_ssp (255);   \
  |   ^~
../../../../src/libgcc/unwind-dw2.c:1654:7: note: in expansion of macro
'_Unwind_Frames_Extra'
 1654 |   _Unwind_Frames_Extra (FRAMES);   
\
  |   ^~~~
../../../../src/libgcc/unwind.inc:140:3: note: in expansion of macro
'uw_install_context'
  140 |   uw_install_context (_context, _context, frames);
  |   ^~
/home/packages/gcc/12/gcc-12-12-20220312/build/gcc/include/cetintrin.h:55:1:
error: inlining failed in call to 'always_inline' '_inc_ssp': target specific
option mismatch
   55 | _inc_ssp (unsigned int __B)
  | ^~~~
../../../../src/libgcc/config/i386/shadow-stack-unwind.h:41:11: note: called
from here
   41 |   _inc_ssp (tmp);   \
  |   ^~
../../../../src/libgcc/unwind-dw2.c:1654:7: note: in expansion of macro
'_Unwind_Frames_Extra'
 1654 |   _Unwind_Frames_Extra (FRAMES);   
\
  |   ^~~~

../../../../src/libgcc/unwind.inc:140:3: note: in expansion of macro
'uw_install_context'
  140 |   uw_install_context (_context, _context, frames);
  |   ^~
make[7]: *** [../../../../src/libgcc/shared-object.mk:14: unwind-dw2.o] Error 1
make[7]: Leaving directory
'/home/packages/gcc/12/gcc-12-12-20220312/build/x86_64-linux-gnu/32/libgcc'

GCC is configured with:

Configured with: -v
 --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2
 --prefix=/usr
 --with-gcc-major-version-only
 --program-suffix=-12
 --program-prefix=x86_64-linux-gnu-
 --enable-shared
 --enable-linker-build-id
 --libexecdir=/usr/lib
 --without-included-gettext
 --enable-threads=posix

Add 'gcc/tree.cc:user_omp_clause_code_name' [PR65095]

[Thomas Schwinge]

Hi!

On 2022-02-17T13:33:45+0100, I wrote:
> On 2019-10-18T14:28:18+0200, I wrote:
>> On 2019-10-06T15:32:34-0700, Julian Brown  wrote:
>>> This patch adds a function to pretty-print OpenACC clause names from
>>> OMP_CLAUSE_MAP_KINDs, for error output.
>>
>> Indeed talking about (OpenMP) 'map' clauses in an OpenACC context is not
>> quite ideal -- that's what PR65095 is about
>
>>> Previously approved as part of:
>>>
>>>   https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01292.html
>
>
>> A few more comments, for later:
>>
>>>  gcc/c-family/c-common.h |  1 +
>>>  gcc/c-family/c-omp.c| 33 +
>>
>> As I'd mentioned before: 'Eventually (that is, later), this should move
>> into generic code, next to the other "clause printing".
>
> As part of an ICE bug fix that I'm working on, I now need to use
> this in GCC middle end code.

Pushed to master branch commit 828335beb77676acffb5911e575672cb55beb2e9
"Add 'gcc/tree.cc:user_omp_clause_code_name' [PR65095]", see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 828335beb77676acffb5911e575672cb55beb2e9 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 17 Feb 2022 12:46:57 +0100
Subject: [PATCH] Add 'gcc/tree.cc:user_omp_clause_code_name' [PR65095]

Re PR65095 "Adapt OpenMP diagnostic messages for OpenACC", move C/C++
front end 'gcc/c-family/c-omp.cc:c_omp_map_clause_name' to generic
'gcc/tree.cc:user_omp_clause_code_name' .  No functional change.

	PR other/65095
	gcc/
	* tree-core.h (user_omp_claus_code_name): Declare function.
	* tree.cc (user_omp_clause_code_name): New function.
	gcc/c/
	* c-typeck.cc (handle_omp_array_sections_1)
	(c_oacc_check_attachments): Call 'user_omp_clause_code_name'
	instead of 'c_omp_map_clause_name'.
	gcc/cp/
	* semantics.cc (handle_omp_array_sections_1)
	(cp_oacc_check_attachments): Call 'user_omp_clause_code_name'
	instead of 'c_omp_map_clause_name'.
	gcc/c-family/
	* c-common.h (c_omp_map_clause_name): Remove.
	* c-omp.cc (c_omp_map_clause_name): Remove.
---
 gcc/c-family/c-common.h |  1 -
 gcc/c-family/c-omp.cc   | 33 -
 gcc/c/c-typeck.cc   |  4 ++--
 gcc/cp/semantics.cc |  4 ++--
 gcc/tree-core.h |  1 +
 gcc/tree.cc | 36 
 6 files changed, 41 insertions(+), 38 deletions(-)

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index a8d6f82bb2c..5f0b5d99d07 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1250,7 +1250,6 @@ extern enum omp_clause_default_kind c_omp_predetermined_sharing (tree);
 extern enum omp_clause_defaultmap_kind c_omp_predetermined_mapping (tree);
 extern tree c_omp_check_context_selector (location_t, tree);
 extern void c_omp_mark_declare_variant (location_t, tree, tree);
-extern const char *c_omp_map_clause_name (tree, bool);
 extern void c_omp_adjust_map_clauses (tree, bool);
 
 enum c_omp_directive_kind {
diff --git a/gcc/c-family/c-omp.cc b/gcc/c-family/c-omp.cc
index cd9d86641e1..777cdc65572 100644
--- a/gcc/c-family/c-omp.cc
+++ b/gcc/c-family/c-omp.cc
@@ -2996,39 +2996,6 @@ c_omp_predetermined_mapping (tree decl)
 }
 
 
-/* For OpenACC, the OMP_CLAUSE_MAP_KIND of an OMP_CLAUSE_MAP is used internally
-   to distinguish clauses as seen by the user.  Return the "friendly" clause
-   name for error messages etc., where possible.  See also
-   c/c-parser.cc:c_parser_oacc_data_clause and
-   cp/parser.cc:cp_parser_oacc_data_clause.  */
-
-const char *
-c_omp_map_clause_name (tree clause, bool oacc)
-{
-  if (oacc && OMP_CLAUSE_CODE (clause) == OMP_CLAUSE_MAP)
-switch (OMP_CLAUSE_MAP_KIND (clause))
-{
-case GOMP_MAP_FORCE_ALLOC:
-case GOMP_MAP_ALLOC: return "create";
-case GOMP_MAP_FORCE_TO:
-case GOMP_MAP_TO: return "copyin";
-case GOMP_MAP_FORCE_FROM:
-case GOMP_MAP_FROM: return "copyout";
-case GOMP_MAP_FORCE_TOFROM:
-case GOMP_MAP_TOFROM: return "copy";
-case GOMP_MAP_RELEASE: return "delete";
-case GOMP_MAP_FORCE_PRESENT: return "present";
-case GOMP_MAP_ATTACH: return "attach";
-case GOMP_MAP_FORCE_DETACH:
-case GOMP_MAP_DETACH: return "detach";
-case GOMP_MAP_DEVICE_RESIDENT: return "device_resident";
-case GOMP_MAP_LINK: return "link";
-case GOMP_MAP_FORCE_DEVICEPTR: return "deviceptr";
-default: break;
-}
-  return omp_clause_code_name[OMP_CLAUSE_CODE (clause)];
-}
-
 /* Used to merge map clause information in c_omp_adjust_map_clauses.  */
 struct map_clause
 {
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 54b0b0d369b..c0812de84b4 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -13373,7 +13373,7 @@ handle_omp_array_sections_1 (tree c, tree t, vec ,
 	{
 	  error_at (OMP_CLAUSE_LOCATION (c),
 	

[Bug c++/97198] __is_constructible(int[], int) should return true

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

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

--- Comment #6 from Jonathan Wakely  ---
I'll add a note to the lwg issue, as I'll never remember there was a comment
about it here.

[Bug other/65095] Adapt OpenMP diagnostic messages for OpenACC

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

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

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

https://gcc.gnu.org/g:828335beb77676acffb5911e575672cb55beb2e9

commit r12-7622-g828335beb77676acffb5911e575672cb55beb2e9
Author: Thomas Schwinge 
Date:   Thu Feb 17 12:46:57 2022 +0100

Add 'gcc/tree.cc:user_omp_clause_code_name' [PR65095]

Re PR65095 "Adapt OpenMP diagnostic messages for OpenACC", move C/C++
front end 'gcc/c-family/c-omp.cc:c_omp_map_clause_name' to generic
'gcc/tree.cc:user_omp_clause_code_name' .  No functional change.

PR other/65095
gcc/
* tree-core.h (user_omp_claus_code_name): Declare function.
* tree.cc (user_omp_clause_code_name): New function.
gcc/c/
* c-typeck.cc (handle_omp_array_sections_1)
(c_oacc_check_attachments): Call 'user_omp_clause_code_name'
instead of 'c_omp_map_clause_name'.
gcc/cp/
* semantics.cc (handle_omp_array_sections_1)
(cp_oacc_check_attachments): Call 'user_omp_clause_code_name'
instead of 'c_omp_map_clause_name'.
gcc/c-family/
* c-common.h (c_omp_map_clause_name): Remove.
* c-omp.cc (c_omp_map_clause_name): Remove.

[Bug tree-optimization/104475] [12 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #8 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #7)
> I think we shouldn't do anything on the optimization side - sure, the path
> isolation in the end turns out not profitable, but it's likely hard to decide
> that.
> 
> Maybe we can somehow avoid threading for a ptr == 0 condition?  Why do we
> make
> the threading profitable?

The threaders are mostly blind wrt threading a path.  If they see it, they will
thread it.  There are some minor things we disallow (see calls to cancel_thread
throughout) and the big hammer we introduced in this release with
cancel_invalid_paths() where we disallow problematic loop transformations.  But
mostly we thread everything that's possible.

Disallowing ptr == 0 as well as highly unlikely paths should be trivial.  We
could add a simple check in cancel_invalid_paths(). Though, I assume that would
affect warning code all over, since we're reducing the amount of threadable
paths on which they depend?

[Bug middle-end/98420] Invalid simplification of x - x with -frounding-math

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

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

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

https://gcc.gnu.org/g:72c243017dee611bf3c32ea7bfad6ac538021aaf

commit r12-7621-g72c243017dee611bf3c32ea7bfad6ac538021aaf
Author: Roger Sayle 
Date:   Sat Mar 12 09:20:52 2022 +

PR middle-end/98420: Don't fold x - x to 0.0 with -frounding-math

This patch addresses PR middle-end/98420, which is inappropriate constant
folding of x - x to 0.0 (in match.pd) when -frounding-math is specified.
Specifically, x - x may be -0.0 with FE_DOWNWARD as the rounding mode.

To summarize, the desired IEEE behaviour, x - x for floating point x,
(1) can't be folded to 0.0 by default, due to the possibility of NaN or Inf
(2) can be folded to 0.0 with -ffinite-math-only
(3) can't be folded to 0.0 with -ffinite-math-only -frounding-math
(4) can be folded with -ffinite-math-only -frounding-math -fno-signed-zeros

2022-03-12  Roger Sayle  

gcc/ChangeLog
PR middle-end/98420
* match.pd (minus @0 @0): Additional checks for -fno-rounding-math
(the defaut) or -fno-signed-zeros.

gcc/testsuite/ChangeLog
PR middle-end/98420
* gcc.dg/pr98420.c: New test case.