[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[asolokha at gmx dot com via Gcc-bugs]

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

Arseny Solokha  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code

--- Comment #1 from Arseny Solokha  ---
Hit Enter too early…

gcc 13.0.0 20220821 snapshot (g:d6a39c25c05c6ed5df8ce49eda719d17e40e29bb) ICEs
when compiling gcc/testsuite/gcc.target/powerpc/pr106016.c and similar
testcases requiring -mmma support:

% powerpc-e300c3-linux-gnu-gcc-13.0.0 -c
gcc/testsuite/gcc.target/powerpc/pr106016.c
during RTL pass: expand
gcc/testsuite/gcc.target/powerpc/pr106016.c: In function 'foo':
gcc/testsuite/gcc.target/powerpc/pr106016.c:12:27: internal compiler error: in
gen_movxo, at config/rs6000/mma.md:333
   12 |   __vector_quad arr[2] = {*a, *b};
  |   ^~
0x7d8391 gen_movxo(rtx_def*, rtx_def*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/config/rs6000/mma.md:333
0xae1dbe rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/recog.h:407
0xae1dbe emit_move_ccmode
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:3871
0xae1dbe emit_move_insn_1(rtx_def*, rtx_def*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:4016
0xae222e emit_move_insn(rtx_def*, rtx_def*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:4167
0xae9e11 store_expr(tree_node*, rtx_def*, int, bool, bool)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:6342
0xaeb910 expand_assignment(tree_node*, tree_node*, bool)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/expr.cc:5876
0x9aa3fa expand_gimple_stmt_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/cfgexpand.cc:3946
0x9aa3fa expand_gimple_stmt
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/cfgexpand.cc:4044
0x9b01b4 expand_gimple_basic_block
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/cfgexpand.cc:6096
0x9b2396 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220821/work/gcc-13-20220821/gcc/cfgexpand.cc:6822

For me, it does not ICE only w/ -mcpu=power10.

[Bug target/106736] New: [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 106736
   Summary: [13 Regression] ICE in gen_movxo, at
config/rs6000/mma.md:333
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu

[Bug middle-end/106725] LTO semantics for __attribute__((leaf))

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #3 from rguenther at suse dot de  ---
On Wed, 24 Aug 2022, dthorn at google dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106725
> 
> --- Comment #2 from Daniel Thornburgh  ---
> (In reply to Richard Biener from comment #1)
> > If GCC, with LTO, would partition the program into two LTRANS partitions,
> > one containing main and bar and one containing foo then applying this
> > optimization promise during LTRANS time on the main/bar partition would
> > be wrong as you say - but I think GCC doesn't do this.
> 
> In this case, foo() was already compiled to native code outside of LTO.
> Wouldn't this then mean that its contents wouldn't be available for the WPA 
> and
> LTRANS phases of the LTO code generation? It seems like the compiler wouldn't
> know that foo() might call bar(), and the presence of `__attribute__((leaf))`
> would cause it to assume that it doesn't call bar().

As said, GCC shouldn't assume this since leaf is defined at translation
unit level, not at LTO level.

[Bug target/106728] Cannot Compile EXE on Shared Network Drive (Windows, MinGW)

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

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

--- Comment #6 from Andrew Pinski  ---
I had a typo, it should have been -S rather than just S.

[Bug target/106728] Cannot Compile EXE on Shared Network Drive (Windows, MinGW)

[johntravolski1 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from John Smith  ---
(In reply to Andrew Pinski from comment #4)
> Try the following:
> g++ -std=c++11 iterate.cpp S -o "Z:\28sec\out.s"
> 
> If this works, then you should report it to binutils.
> Though I suspect it is https://sourceware.org/bugzilla/show_bug.cgi?id=25713
> which was only fixed earlier in the year.

Unfortunately it did not work. Here's what I got:

```
g++ -std=c++11 iterate.cpp S -o "Z:\28sec\out.s"
c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
cannot open output file Z:\28sec\out.s: No such file or directory
collect2.exe: error: ld returned 1 exit status
```

Any suggestions for what I should do now?

[Bug target/106728] Cannot Compile EXE on Shared Network Drive (Windows, MinGW)

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

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

--- Comment #4 from Andrew Pinski  ---
Try the following:
g++ -std=c++11 iterate.cpp S -o "Z:\28sec\out.s"

If this works, then you should report it to binutils.
Though I suspect it is https://sourceware.org/bugzilla/show_bug.cgi?id=25713
which was only fixed earlier in the year.

[Bug target/106728] Cannot Compile EXE on Shared Network Drive (Windows, MinGW)

[johntravolski1 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from John Smith  ---
Please ignore the different machine names in the output I posted above, I
forgot to change it in both appearances. I attempted to change it to
"machine_name" to avoid confusion but missed it in one spot and I don't know
how to edit comments.

[Bug target/106728] Cannot Compile EXE on Shared Network Drive (Windows, MinGW)

[johntravolski1 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from John Smith  ---
(In reply to Andrew Pinski from comment #1)
> > g++ -std=c++11 iterate.cpp -o "Z:\28sec\out.exe"
> 
> 
> Does `g++ -c -std=c++11 iterate.cpp -o "\\machine_name\d\performance
> testing\t.o" ` work?
> 
> Also if it is failing like this, it is not a problem with GCC rather than
> mingw.

Here's what I got:

```
g++ -c -std=c++11 iterate.cpp -o "\\the-warpstar\d\perfor
mance testing\t.o"
Assembler messages:
Fatal error: can't create \\machine_name\d\performance testing\t.o: Invalid
argument
```

Same if I use the mapped drive letter Z.

The mingw people told me to come here.

https://github.com/brechtsanders/winlibs_mingw/issues/112

Should I go back to them? I'm confused with whom the issue actually lies.

[Bug target/106459] Compiler crashing for loongarch64-linux-gnu on windows

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Chenghua Xu
:

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

commit r12-8713-gce753c2792363f1b4cfe2ac56b2da562b34151f3
Author: Chenghua Xu 
Date:   Wed Aug 24 15:34:07 2022 +0800

LoongArch: Fix pr106459 by use HWIT instead of 1UL.

gcc/ChangeLog:

PR target/106459
* config/loongarch/loongarch.cc (loongarch_build_integer):
Use HOST_WIDE_INT.
* config/loongarch/loongarch.h (IMM_REACH): Likewise.
(HWIT_1U): New Defined.
(LU12I_OPERAND): Use HOST_WIDE_INT.
(LU32I_OPERAND): Likewise.
(LU52I_OPERAND): Likewise.
(HWIT_UC_0xFFF): Likwise.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/pr106459.c: New test.

(cherry picked from commit b169b67d7dafe2b786f87c31d6b2efc603fd880c)

[Bug target/106459] Compiler crashing for loongarch64-linux-gnu on windows

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Chenghua Xu :

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

commit r13-2195-gb169b67d7dafe2b786f87c31d6b2efc603fd880c
Author: Chenghua Xu 
Date:   Wed Aug 24 15:34:07 2022 +0800

LoongArch: Fix pr106459 by use HWIT instead of 1UL.

gcc/ChangeLog:

PR target/106459
* config/loongarch/loongarch.cc (loongarch_build_integer):
Use HOST_WIDE_INT.
* config/loongarch/loongarch.h (IMM_REACH): Likewise.
(HWIT_1U): New Defined.
(LU12I_OPERAND): Use HOST_WIDE_INT.
(LU32I_OPERAND): Likewise.
(LU52I_OPERAND): Likewise.
(HWIT_UC_0xFFF): Likwise.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/pr106459.c: New test.

[Bug libstdc++/106735] tens of thousands of errors in C++ library

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Reverted at r13-2192-ge5428086c2c8daf69e5916dd5016d1e7b85d3f0d

lxo identified the problem:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600268.html
But I'll revisit when the sun is up and figure out why my testing didn't see
it.

[Bug libstdc++/106735] tens of thousands of errors in C++ library

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Target Milestone|--- |13.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug libstdc++/106735] tens of thousands of errors in C++ library

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||jwakely.gcc at gmail dot com

--- Comment #3 from Marek Polacek  ---
I think it started with r13-2175-g0b7c9254998b3f.

[Bug libstdc++/106735] tens of thousands of errors in C++ library

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

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

--- Comment #2 from seurer at gcc dot gnu.org ---
It it causing so many error messages that emails to the gcc test results list
from my autotesters are being rejected as they are 3.9MB in size.

[Bug libstdc++/106735] tens of thousands of errors in C++ library

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-24
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Confirmed, I see it too (vanilla trunk).

[Bug libstdc++/106735] New: tens of thousands of errors in C++ library

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

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

Bug ID: 106735
   Summary: tens of thousands of errors in C++ library
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I am seeing over 42,000 new errors after some recent trunk commit in the C++
library or usage of the C++ library.

A couple of examples (they are all or mostly like these):

FAIL: g++.dg/gomp/pr88182.C  -std=gnu++98 (test for excess errors)
Excess errors:
/home/seurer/binutils/install/bin/ld:
/home/seurer/gcc/git/build/gcc-trunk/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs/libstdc++.so:
undefined reference to `std::__cxx11::basic_string, std::allocator > std::operator+, std::allocator >(std::__cxx11::basic_string, std::allocator > const&, char const*)'


FAIL: g++.dg/ext/tmplattr4.C  -std=c++98 (test for excess errors)
Excess errors:
/home/seurer/binutils/install/bin/ld:
/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs/libstdc++.so:
undefined reference to `std::__cxx11::basic_string, std::allocator > std::operator+, std::allocator >(std::__cxx11::basic_string, std::allocator > const&, char const*)'


I have a bisect running and will report if it finds a culprit.

[Bug target/100736] ICE: unrecognizable insn

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

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

--- Comment #6 from Segher Boessenkool  ---
There are so many things here, it's hard to start.  Two big things:

Firstly, this is not floating point at all, so -ffinite-math-only should not
make any difference.  We currently abuse CCFP (in a non-safe way), this should
be fixed.

Secondly, -mcpu=power9 (to get isel) or -mcpu=power10 (to get setbc) are more
interesting.  What is the generated machine code for those?

More things:

crnot is needed to get the polarity of the result correct.  We could instead
do a xori 1 (or similar) on the eventual GPR.  If we do say a cror and a crnot
we should make this can be combined to a crnor (all 14 logic functions are
supported), but if the inversion is done in the GPR (with such a xori, say),
this is much harder to optimise.

If we are not interested in overflows, always one of LT GT EQ is set, so we
never need any crlogical insn here.

To be exact, this is whenever we have valid inputs: if there is output
overflow cr6.3 will be set as well, but still exactly one of cr6.0, cr6.1,
cr6.2 will be set.

But if there is an invalid *input* cr6 is set to 0b0001 always.  I don't think
we need to care here (otoh it isn't obvious how to best model it!)

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #18 from anlauf at gcc dot gnu.org ---
Tentative patch, regtests cleanly but otherwise untested:

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 850007fd2e1..0a1520e95ba 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6503,8 +6503,19 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
  else
{
  bool add_clobber;
- add_clobber = fsym && fsym->attr.intent == INTENT_OUT
-   && !fsym->attr.allocatable && !fsym->attr.pointer
+ gfc_symbol *dsym = fsym;
+ gfc_dummy_arg *dummy;
+
+ /* Use associated dummy as fallback for formal
+argument if there is no explicit interface.  */
+ if (dsym == NULL
+ && (dummy = arg->associated_dummy)
+ && dummy->intrinsicness ==
GFC_NON_INTRINSIC_DUMMY_ARG
+ && dummy->u.non_intrinsic->sym)
+   dsym = dummy->u.non_intrinsic->sym;
+
+ add_clobber = dsym && dsym->attr.intent == INTENT_OUT
+   && !dsym->attr.allocatable && !dsym->attr.pointer
&& e->symtree && e->symtree->n.sym
&& !e->symtree->n.sym->attr.dimension
&& !e->symtree->n.sym->attr.pointer

Does this fix the remaining issue?

What is the best way to write a testcase that checks that the clobber is
inserted properly?

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

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

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

--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to Richard Biener from comment #11)
> (In reply to Richard Biener from comment #10)
> > likely triggered by the INTENT(out), it looks like gfortran fails to 
> > properly
> > name-lookup a variable of the same name as the function?  The intent is
> > likely
> > to have the return value assigned by CALERF_r8.  So it also looks like
> > gfortran miscompiles such testcase.
[...]
> SUBROUTINE Y (Z)
>   real(8), intent(out) :: Z
>   Z = 1.
> END SUBROUTINE Y
> FUNCTION X()
>   real(8) :: X
>   CALL Y (X)
> END FUNCTION X
> PROGRAM TEST
> real(8) :: Z
> Z = X();
> if (Z.ne.1.) STOP 1
> END PROGRAM
> 
> but still
> 
> t.f90:11:9:
> 
>11 | Z = X();
>   | 1
> Error: Return type mismatch of function 'x' at (1) (REAL(4)/REAL(8))

The error message is correct.  The main program is missing a decl that
X is real(8) not real(4).  E.g. adding

  real(8) :: X

resolves the type mismatch.

(Replacing 1. by 1._8 also eliminates some conversions in the dump.)

The dummy argument Z of Y is marked as intent(out):

Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = y
  symtree: 'y'   || symbol: 'y'
type spec : (UNKNOWN 0)
attributes: (PROCEDURE  SUBROUTINE)
Formal arglist: z
  symtree: 'z'   || symbol: 'z'
type spec : (REAL 8)
attributes: (VARIABLE  DUMMY(OUT))

A quick glance at trans-expr.cc::gfc_conv_procedure_call suggests that
the logic that determines whether to generate a clobber depends on the
properties of the formal argument being available.

6505  bool add_clobber;
6506  add_clobber = fsym && fsym->attr.intent ==
INTENT_OUT
6507&& !fsym->attr.allocatable &&
!fsym->attr.pointer
6508&& e->symtree && e->symtree->n.sym
6509&& !e->symtree->n.sym->attr.dimension
6510&& !e->symtree->n.sym->attr.pointer
6511&& !e->symtree->n.sym->attr.allocatable
6512/* See PR 41453.  */
6513&& !e->symtree->n.sym->attr.dummy
6514/* FIXME - PR 87395 and PR 41453  */
6515&& e->symtree->n.sym->attr.save == SAVE_NONE
6516&& !e->symtree->n.sym->attr.associate_var
6517&& e->ts.type != BT_CHARACTER && e->ts.type !=
BT_DERIVED
6518&& e->ts.type != BT_CLASS &&
!sym->attr.elemental;
6519
6520  gfc_conv_expr_reference (, e,
add_clobber);
(gdb) p fsym
$7 = (gfc_symbol *) 0x0

Without an explicit interface, stone-age-style code is not supported here yet.

[Bug fortran/106731] ICE on automatic array of derived type with DTIO

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

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

--- Comment #5 from Steve Kargl  ---
On Wed, Aug 24, 2022 at 07:10:20PM +, federico.perini at gmail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
> 
> --- Comment #4 from federico  ---
> The TREE_STATIC assert should be valid according to what reported in the
> implementation at report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 
> 
> But, I can't tell what that means.
> 

I can only report what I find.  If the gcc_assert()
is commented out your code compiles and executes.
Whether the output is correct or not, I don't know
as I don't use DTIO.  I guess someone else will need
to fire up gdb and debug this problem for you.

[Bug target/106588] The constraints on most of the patterns in bitmanip.md are broken

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug target/106632] undefined code causes assembler failure

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Fixed.

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #15 from Andrew Pinski  ---
Fixed.

[Bug target/106632] undefined code causes assembler failure

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

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

--- Comment #2 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r13-2190-gdf5204ddd4b8e3a2d02bb3ad5bcdb9d636b02537
Author: Andrew Pinski 
Date:   Mon Aug 15 22:58:09 2022 +

[RISCV] Fix PR 106632 and PR 106588 a few constraints in bitmanip.md

The constraints should be n instead of i. Also there
needs to a check for out of bounds zero_extract for
*bexti.

gcc/ChangeLog:

PR target/106632
PR target/106588
* config/riscv/bitmanip.md (*shNadduw): Use n constraint
instead of i.
(*slliuw): Likewise.
(*bexti): Likewise. Also add a check for operands[2] to be less
than the mode bitsize.

[Bug target/106588] The constraints on most of the patterns in bitmanip.md are broken

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r13-2190-gdf5204ddd4b8e3a2d02bb3ad5bcdb9d636b02537
Author: Andrew Pinski 
Date:   Mon Aug 15 22:58:09 2022 +

[RISCV] Fix PR 106632 and PR 106588 a few constraints in bitmanip.md

The constraints should be n instead of i. Also there
needs to a check for out of bounds zero_extract for
*bexti.

gcc/ChangeLog:

PR target/106632
PR target/106588
* config/riscv/bitmanip.md (*shNadduw): Use n constraint
instead of i.
(*slliuw): Likewise.
(*bexti): Likewise. Also add a check for operands[2] to be less
than the mode bitsize.

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

--- Comment #14 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r13-2188-g2c721ea9473ad7615bb47b66509097bd254bb839
Author: Andrew Pinski 
Date:   Mon Aug 15 22:25:13 2022 +

[RISCV] Fix PR 106586: riscv32 vs ZBS

The problem here is two fold. With RISCV32, 32bit
const_int are always signed extended to 64bit in HWI.
So that means for SINGLE_BIT_MASK_OPERAND, it should
mask off the upper bits to see it is a single bit
for !TARGET_64BIT.
Plus there are a few locations which forget to call
trunc_int_for_mode when generating a SImode constant
so they are not sign extended correctly for HWI.
The predicates single_bit_mask_operand and
not_single_bit_mask_operand need get the same handling
as SINGLE_BIT_MASK_OPERAND so just use SINGLE_BIT_MASK_OPERAND.

OK? Built and tested on riscv32-linux-gnu and riscv64-linux-gnu with
--with-arch=rvNimafdc_zba_zbb_zbc_zbs where N is replaced with 32 or 64.

Thanks,
Andrew Pinski

gcc/ChangeLog:

PR target/106586
* config/riscv/predicates.md (single_bit_mask_operand):
Use SINGLE_BIT_MASK_OPERAND instead of directly calling pow2p_hwi.
(not_single_bit_mask_operand): Likewise.
* config/riscv/riscv.cc (riscv_build_integer_1): Don't special case
1<<31 for 32bits as it is already handled.
Call trunc_int_for_mode on the upper part after the subtraction.
(riscv_move_integer): Call trunc_int_for_mode before generating
the integer just make sure the constant has been sign extended
corectly.
(riscv_emit_int_compare): Call trunc_int_for_mode after doing the
addition for the new rhs.
* config/riscv/riscv.h (SINGLE_BIT_MASK_OPERAND): If !TARGET64BIT,
then mask off the upper 32bits of the HWI as it will be sign
extended.

[Bug fortran/106731] ICE on automatic array of derived type with DTIO

[federico.perini at gmail dot com via Gcc-bugs]

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

--- Comment #4 from federico  ---
The TREE_STATIC assert should be valid according to what reported in the
implementation at report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 

But, I can't tell what that means.

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

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

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

--- Comment #8 from Peter Bergner  ---
(In reply to Kewen Lin from comment #7)
> In this patch, I mainly
> followed the existing practice vect_int_mult (there are also some similar
> effective targets describing target vector support capability). With this
> way, if some other arches support this in future, target owners need to add
> their own conditions.

Yes, and those target maintainers will notice when they add the HW support and
then see this test case FAIL, just like we did on P10.

[Bug target/106601] __builtin_bswap16 code gen could be improved with ZBB enabled

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Fixed.

[Bug target/106600] __builtin_bswap32 is not hooked up for ZBB

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug testsuite/106690] check_effective_target_bswap should be enabled for riscv if ZBB ISA extension is enabled

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug testsuite/106690] check_effective_target_bswap should be enabled for riscv if ZBB ISA extension is enabled

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r13-2180-gdec5faa2b2f0d311daa6defd4b4f3c1965748ddf
Author: Andrew Pinski 
Date:   Fri Aug 19 22:09:30 2022 +

Fix PR 106690: enable effective_target_bswap for RISCV targets with ZBB
enabled by default

While looking for testcases to quickly test, I Noticed that
check_effective_target_bswap was not enabled for riscv when
ZBB is enabled. This patch checks if ZBB is enabled when
targeting RISCV* for bswap.

OK? Ran the testsuite for riscv32-linux-gnu both with and without ZBB
enabled.

PR testsuite/106690
gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_bswap):
Return true if riscv and ZBB ISA extension is enabled.

[Bug target/106601] __builtin_bswap16 code gen could be improved with ZBB enabled

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

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r13-2179-ge5e6983c3da53729e58a32af1d531ea74b3dbf5d
Author: Andrew Pinski 
Date:   Fri Aug 19 17:46:40 2022 +

Fix PR 106601: __builtin_bswap16 code gen could be improved with ZBB
enabled

The default expansion for bswap16 is two extractions (shift/and)
followed by an insertation (ior) and then a zero extend. This can be
improved
with ZBB enabled to just full byteswap followed by a (logical) shift right.
This patch adds a new pattern for this which does that.

OK? Built and tested on riscv32-linux-gnu and riscv64-linux-gnu.

gcc/ChangeLog:

PR target/106601
* config/riscv/bitmanip.md (bswaphi2): New pattern.

gcc/testsuite/ChangeLog:

PR target/106601
* gcc.target/riscv/zbb_32_bswap-2.c: New test.
* gcc.target/riscv/zbb_bswap-2.c: New test.

[Bug target/106600] __builtin_bswap32 is not hooked up for ZBB

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r13-2178-gcb2daf5acce003300ee948a89860c0d13ebcae79
Author: Andrew Pinski 
Date:   Fri Aug 19 17:01:02 2022 +

Fix PR 106600: __builtin_bswap32 is not hooked up for ZBB for 32bit

The problem here is the bswap2 pattern had a check for TARGET_64BIT
but then used the X iterator. Since the X iterator is either SI or DI
depending
on the setting TARGET_64BIT, there is no reason for the TARGET_64BIT.

OK? Built and tested on both riscv32-linux-gnu and riscv64-linux-gnu.

Thanks,
Andrew Pinski

gcc/ChangeLog:

PR target/106600
* config/riscv/bitmanip.md (bswap2): Remove
condition on TARGET_64BIT as X is already conditional there.

gcc/testsuite/ChangeLog:

PR target/106600
* gcc.target/riscv/zbb_32_bswap-1.c: New test.
* gcc.target/riscv/zbb_bswap-1.c: New test.

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

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:55d8c5409325001c89c35c3d04d425dec9127146

commit r13-2177-g55d8c5409325001c89c35c3d04d425dec9127146
Author: Harald Anlauf 
Date:   Tue Aug 23 22:16:14 2022 +0200

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

gcc/fortran/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

[Bug debug/106718] GCC does not follow DWARF5 standard for DW_AT_ranges and DW_FORM_rnglistx

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

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

Navid Rahimi  changed:

   What|Removed |Added

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

--- Comment #3 from Navid Rahimi  ---
Status change to Invalid report.

[Bug debug/106718] GCC does not follow DWARF5 standard for DW_AT_ranges and DW_FORM_rnglistx

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

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

--- Comment #2 from Navid Rahimi  ---
Thanks for clarifying it. I was able to fix a bug somewhere else with your
explanation.

[Bug fortran/106731] ICE on automatic array of derived type with DTIO

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to federico from comment #0)
> A derived type that has user-defined I/O causes ICE on all gfortran versions
> 7 to 12.1.0, whenever it's being used as an automatic object.
> 
> The error is at 
> 
> 
>63 | type(t) :: automatic(n)
>   |   1
> internal compiler error: in gfc_trans_auto_array_allocation, at
> fortran/trans-array.cc:6617
> 
> This does not happen if the derived type is allocated.
> 
> Here's the simplest example: 
> 
> module causes_ice
> implicit none
> 
> type :: t
> real(8) :: x
> contains
> procedure, private :: write_formatted
> generic :: write(formatted) => write_formatted
> end type t
> 
> contains
> 
> subroutine write_formatted(this, unit, iotype, v_list, iostat, iomsg)
>class(t), intent(in) :: this
>integer, intent(in) :: unit
>character(*), intent(in) :: iotype
>integer, intent(in) :: v_list(:)
>integer, intent(out) :: iostat
>character(*), intent(inout) :: iomsg
>write(unit, '(a)', iostat=iostat, iomsg=iomsg) 'dummy'
> end subroutine write_formatted
> 
> end module causes_ice
> 
> module use_t
> use causes_ice
> implicit none
> 
> public :: automatic_alloc
> 
> contains
> 
> subroutine automatic_alloc(n)
> integer, intent(in) :: n
> 
> ! Automatic array: ICE!
> type(t) :: automatic(n)
> 
> ! Allocatable: works
> type(t), allocatable :: alloc(:)
> allocate(alloc(n))
> 
> ! Do anything
> print *, 'n=',n,automatic(n)%x
> 
> end subroutine automatic_alloc
> 
> end module use_t
> 
> program test
> use use_t
> call automatic_alloc(1)
> end program test
> 
> I could find other DTIO-related bugs, but none seemed related with the
> allocation type.

You're hitting an assert() in trans-array.cc.  It's unclear to me why the
assert() is there.  If it is commented out, the code compiles and executes.

% git diff gcc/fortran/trans-array.cc | cat
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 05134952db4..c5916aeee53 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -6614,7 +6614,7 @@ gfc_trans_auto_array_allocation (tree decl, gfc_symbol *
sym,
   type = TREE_TYPE (type);

   gcc_assert (!sym->attr.use_assoc);
-  gcc_assert (!TREE_STATIC (decl));
+//  gcc_assert (!TREE_STATIC (decl));
   gcc_assert (!sym->module);

   if (sym->ts.type == BT_CHARACTER

[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #4 from joseph at codesourcery dot com  ---
Regarding mangling: I expect this change should fix bug 85518.

General: I expect some glibc header changes might be appropriate, where 
they currently assume __FloatN keywords aren't supported in C++.  And 
where glibc headers handle type-generic operations for C++ by defining 
appropriate overloaded functions in the headers, make sure the overloads 
for _Float128 work with both _Float128 and __float128 where supported and 
distinct, or otherwise adjust the headers as needed to handle both types.

(Also, so far we don't have _Float16 support in glibc, and while it would 
be a sensible feature in principle, there would be issues to consider with 
the impact on minimum GCC versions for building glibc on relevant 
architectures, unless some kind of hack is used to allow _Float16 
functions to be built and to get the correct ABI even when built with an 
older compiler.  Requiring GCC 7 to build glibc for AArch64 and Arm might 
well be reasonable now; requiring GCC 12 for x86/x86_64 or GCC 13 for 
RISC-V probably not for a few years.)

[Bug target/102146] [11 regression] several test cases fails after r11-8940

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #21 from Segher Boessenkool  ---
Closing as fixed then (pr56605.c still fails on older branches, but that is
harmless).

[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names

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

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

--- Comment #3 from Jakub Jelinek  ---
Testcase for the already implemented features:
// P1467R9 - Extended floating-point types and standard names.
// { dg-do compile { target c++23 } }
// { dg-options "" }

namespace std
{
  #ifdef __STDCPP_FLOAT16_T__
  using float16_t = _Float16;
  #endif
  #ifdef __STDCPP_FLOAT32_T__
  using float32_t = _Float32;
  #endif
  #ifdef __STDCPP_FLOAT64_T__
  using float64_t = _Float64;
  #endif
  #ifdef __STDCPP_FLOAT128_T__
  using float128_t = _Float128;
  #endif
  template struct integral_constant {
static constexpr T value = v;
  };
  typedef integral_constant false_type;
  typedef integral_constant true_type;
  template
  struct is_same : std::false_type {};
  template 
  struct is_same : std::true_type {};
}
#ifdef __STRICT_ANSI__
#undef __SIZEOF_FLOAT128__
#endif

using namespace std;

static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
#ifdef __SIZEOF_FLOAT128__
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#ifdef __STDCPP_FLOAT16_T__
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#ifdef __STDCPP_FLOAT32_T__
static_assert (!is_same::value);
static_assert (!is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (!is_same::value);
static_assert (!is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#ifdef __STDCPP_FLOAT64_T__
static_assert (!is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (!is_same::value);
static_assert (!is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#ifdef __STDCPP_FLOAT128_T__
static_assert (!is_same::value);
static_assert (!is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (!is_same::value);
static_assert (!is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
#ifdef __SIZEOF_FLOAT128__
static_assert (!is_same::value);
static_assert (!is_same::value);
static_assert (!is_same::value);
static_assert (!is_same::value);
#endif
#endif
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
#if defined(__STDCPP_FLOAT16_T__) && defined(__STDCPP_FLOAT32_T__)
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#if defined(__STDCPP_FLOAT16_T__) && defined(__STDCPP_FLOAT64_T__)
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#if defined(__STDCPP_FLOAT16_T__) && defined(__STDCPP_FLOAT128_T__)
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#if defined(__STDCPP_FLOAT32_T__) && defined(__STDCPP_FLOAT64_T__)
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#if defined(__STDCPP_FLOAT32_T__) && defined(__STDCPP_FLOAT128_T__)
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#if defined(__STDCPP_FLOAT64_T__) && defined(__STDCPP_FLOAT128_T__)
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#ifdef __STDCPP_FLOAT32_T__
#if __FLT_MAX_EXP__ == __FLT32_MAX_EXP__ && __FLT_MANT_DIG__ ==
__FLT32_MANT_DIG__
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#if __DBL_MAX_EXP__ > __FLT32_MAX_EXP__ && __DBL_MANT_DIG__ >
__FLT32_MANT_DIG__
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#if __LDBL_MAX_EXP__ > __FLT32_MAX_EXP__ && __LDBL_MANT_DIG__ >
__FLT32_MANT_DIG__
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#endif
#ifdef __STDCPP_FLOAT64_T__
#if __FLT_MAX_EXP__ < __FLT64_MAX_EXP__ && __FLT_MANT_DIG__ <
__FLT64_MANT_DIG__
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#if __DBL_MAX_EXP__ == __FLT64_MAX_EXP__ && __DBL_MANT_DIG__ ==
__FLT64_MANT_DIG__
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#if __LDBL_MAX_EXP__ > __FLT64_MAX_EXP__ && __LDBL_MANT_DIG__ >
__FLT64_MANT_DIG__
static_assert (is_same::value);
static_assert (is_same::value);
#endif
#if __LDBL_MAX_EXP__ == __FLT64_MAX_EXP__ && __LDBL_MANT_DIG__ ==
__FLT64_MANT_DIG__ \
&& __DBL_MAX_EXP__ == __FLT64_MAX_EXP__ && __DBL_MANT_DIG__ ==
__FLT64_MANT_DIG__
// An extended floating-point type with the same set of values as more than one
// cv-unqualified standard floating-point type has a rank equal to the rank of
// double.
// Then long double will have higher rank than float64_t.
static_assert (is_same::value);

[Bug middle-end/106725] LTO semantics for __attribute__((leaf))

[dthorn at google dot com via Gcc-bugs]

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

--- Comment #2 from Daniel Thornburgh  ---
(In reply to Richard Biener from comment #1)
> If GCC, with LTO, would partition the program into two LTRANS partitions,
> one containing main and bar and one containing foo then applying this
> optimization promise during LTRANS time on the main/bar partition would
> be wrong as you say - but I think GCC doesn't do this.

In this case, foo() was already compiled to native code outside of LTO.
Wouldn't this then mean that its contents wouldn't be available for the WPA and
LTRANS phases of the LTO code generation? It seems like the compiler wouldn't
know that foo() might call bar(), and the presence of `__attribute__((leaf))`
would cause it to assume that it doesn't call bar().

[Bug target/106728] Cannot Compile EXE on Shared Network Drive (Windows, MinGW)

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

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

--- Comment #1 from Andrew Pinski  ---
> g++ -std=c++11 iterate.cpp -o "Z:\28sec\out.exe"


Does `g++ -c -std=c++11 iterate.cpp -o "\\machine_name\d\performance
testing\t.o" ` work?

Also if it is failing like this, it is not a problem with GCC rather than
mingw.

[Bug target/106724] logical-op-non-short-circuit maybe should be 1

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Richard Biener from comment #3)
> we usually define logical-op-non-short-circuit based on branch cost

Right, I think this definition was copied from the MIPS backend even which is
wrong there too which was done back in 2005 way before the main uses of
LOGICAL_OP_NON_SHORT_CIRCUIT was done.

[Bug target/106723] Unreplaced mode/code attributes in aarch64/arm backends

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

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

--- Comment #3 from Richard Earnshaw  ---
I think we should error if the name matches some iteration values, but not
others.  If  is valid in the assembler output 'as-is' then it's bad form
to have an attribute that overloads this - and the fix is easy: rename the
iterator attribute.

[Bug middle-end/91213] Missed optimization: (sub X Y) -> (xor X Y) when Y <= X and isPowerOf2(X + 1)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #5 from Andrew Pinski  ---
I am no longer working on this. Yes expansion should do it rather than match.

[Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Dup of bug 91213.

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

[Bug middle-end/91213] Missed optimization: (sub X Y) -> (xor X Y) when Y <= X and isPowerOf2(X + 1)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jens.seifert at de dot ibm.com

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

[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
On targets that do have __float128, I believe we want to mangle it as before
and also handle usual arithmetic conversions etc. the same we did before unless
the
C++23 extended floating-point types are involved.
Which is why I've introduced the float128t_type_node hack, where non-C++ can
continue to do what it did before but for C++ __float128 will be a new distinct
type.
For mangling of std::float{16,32,64,128}_t I'm using the Itanium ABI
_Float{16,32,64,128} mangling, i.e. DF{16,32,64,128}_
This collides with the apparently never really used mangling of
FIXED_POINT_TYPEs 
(fixed points are really only supported in C on a few platforms, not in C++,
and at some point they leaked into the C++ FE through 0r and similar literals,
but that has been fixed shortly afterwards).
The patch only introduces _Float{16,32,64,128}, not _Float{32,64,128}x that C
also supports, so I've removed __FLT{32,64,128}X_* predefined macros.

The patch is still incomplete and I'm getting stuck on it (except I can surely
provide testsuite coverage for what is already implemented):

1) there is no bf16/BF16 constant suffix nor underlying type for
std::bfloat16_t
   for now; I think we need to come to agreement on how the underlying type
   would be called (__bf16 like aarch64/arm/i386 currently have their extension
   type?) and how to mangle it (all 3 currently mangle it as u6__bf16) and
   if we choose a different keyword for it whether it is distinct from __bf16

2) I haven't implemented the [conv.double] addition:
   "with a greater or equal conversion rank ([conv.rank]). A prvalue of
standard 
   floating-point type can be converted to a prvalue of another standard
   floating-point type" - not really sure where it should be done
   (but the new cp_compare_floating_point_conversion_ranks function can be
   used to compare ranks and subranks)

3) for the [expr.static.cast] addition, I wonder if there is anything to do,
   I'd expect it would just work as is

4) for the [expr.arith.conv] changes, I think I've implement those in
   cp_common_type, except for the
   "Otherwise, the expression is ill-formed."
   part where I just return error_mark_node, but cp_common_type doesn't
   emit any diagnostics whatsoever, so I wonder if it should be done
   somewhere in the callers, or if the function and its wrappers should
   get tsubst_flags_t complain argument or what.

5) I've skipped the [over.ics.rank] changes, I'm afraid it is another thing
   I'm not really familiar with

6) the library part is unimplemented altogether, the __FLT* macros can be used
   to implement numerical limits, but e.g. for the / stuff
   not really sure how far can we get for std::float128_t if not on glibc or
   on old glibc (guess the others at least when they match float/double
   which can be tested through preprocessor macros can be handled by casts
   to those types)

[Bug libstdc++/106669] incorrect definition of viewable_range ("more madness with move-only views")

[h2+bugs at fsfe dot org via Gcc-bugs]

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

Hannes Hauswedell  changed:

   What|Removed |Added

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

--- Comment #3 from Hannes Hauswedell  ---
According to LWG, this "works as intended". I will try to prepare some more
arguments for changing this, but in any case it is not a GCC issue –– yet ;-)

[Bug c++/106734] [requires] std::same_as in compound requirements doesn't produce expected result

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

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

--- Comment #7 from Jonathan Wakely  ---
decltype(bar) and decltype((bar)) are not the same type.

[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 53504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53504=edit
gcc13-pr106652-wip.patch

Untested WIP.

The plan is to use _Float{16,32,64,128} types (keywords like in C, so that
_Complex _Float64 etc. works) for underlying types of
std::float{16,32,64,128}_t
implementation.

[Bug c++/106734] [requires] std::same_as in compound requirements doesn't produce expected result

[jakob at schmutz dot co.uk via Gcc-bugs]

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

jakob at schmutz dot co.uk changed:

   What|Removed |Added

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

--- Comment #6 from jakob at schmutz dot co.uk ---
Will close then as I agree that GCC is correct

(I just found it a little confusing)

[Bug c++/106734] [requires] std::same_as in compound requirements doesn't produce expected result

[jakob at schmutz dot co.uk via Gcc-bugs]

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

--- Comment #5 from jakob at schmutz dot co.uk ---
oh I see `std::same_as` is false

[Bug c++/106734] [requires] std::same_as in compound requirements doesn't produce expected result

[jakob at schmutz dot co.uk via Gcc-bugs]

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

--- Comment #4 from jakob at schmutz dot co.uk ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to jakob from comment #0)
> > Bar bar;
> > constexpr bool same = requires
> > {
> > { bar } -> std::same_as;
> 
> This is false. The type of decltype((bar)) is Bar&.
> 
> So I think GCC is correct.



Right but then why is `std::same_as` true? Shouldn't that
also be false then?

[Bug c++/106734] [requires] std::same_as in compound requirements doesn't produce expected result

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to jakob from comment #0)
> Bar bar;
> constexpr bool same = requires
> {
> { bar } -> std::same_as;

This is false. The type of decltype((bar)) is Bar&.

So I think GCC is correct.

[Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #4 from rguenther at suse dot de  ---
On Wed, 24 Aug 2022, rdapp at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701
> 
> --- Comment #3 from rdapp at gcc dot gnu.org ---
> I though expand (or combine) were independent of value range. What would be 
> the
> proper place for it then?

I think we use ranges during expansion already, otherwise gimple-isel.cc
might be a good place.

[Bug c++/106734] [requires] std::same_as in compound requirements doesn't produce expected result

[jakob at schmutz dot co.uk via Gcc-bugs]

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

--- Comment #2 from jakob at schmutz dot co.uk ---
Created attachment 53503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53503=edit
preprocessed file

[Bug target/106733] bpf: facilitate constant propagation of function addresses

[jose.marchesi at oracle dot com via Gcc-bugs]

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

Jose E. Marchesi  changed:

   What|Removed |Added

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

--- Comment #3 from Jose E. Marchesi  ---
Changing status to fixed.

[Bug c++/106734] [requires] std::same_as in compound requirements doesn't produce expected result

[jakob at schmutz dot co.uk via Gcc-bugs]

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

--- Comment #1 from jakob at schmutz dot co.uk ---

> but instead it returns
> 
> ```
> IS SAME
> REQUIRES SAME
> CONVERTIBLE
> ```


whoops this was supposed to be

```
AS SAME
IS SAME
CONVERTIBLE
```

[Bug target/106733] bpf: facilitate constant propagation of function addresses

[jose.marchesi at oracle dot com via Gcc-bugs]

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

--- Comment #2 from Jose E. Marchesi  ---
Urgh I obviously meant bpf-unknown-none.

[Bug c++/106734] New: [requires] std::same_as in compound requirements doesn't produce expected result

[jakob at schmutz dot co.uk via Gcc-bugs]

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

Bug ID: 106734
   Summary: [requires] std::same_as in compound requirements
doesn't produce expected result
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakob at schmutz dot co.uk
  Target Milestone: ---

On gcc version 12.2.0 (and 11.3.0) I would expect the following code


```
#include 

struct Bar {
};

int main()
{
Bar bar;
constexpr bool same = requires
{
{ bar } -> std::same_as;
};

constexpr bool conv = requires
{
{ bar } -> std::convertible_to;
};

if constexpr (std::same_as)
{
std::cout << "AS SAME" << std::endl;
}

if constexpr (std::is_same_v)
{
std::cout << "IS SAME" << std::endl;
}

if constexpr (same)
{
std::cout << "REQUIRES SAME" << std::endl;
}

if constexpr (conv)
{
std::cout << "CONVERTIBLE" << std::endl;
}

return 0;
}
```

to return

```
AS SAME
IS SAME
REQUIRES SAME
CONVERTIBLE
```

based on how how [compound
requires](https://en.cppreference.com/w/cpp/language/requires) section reads


but instead it returns

```
IS SAME
REQUIRES SAME
CONVERTIBLE
```

compiled with `g++ temp.cpp -std=c++20`

compiling with `clang++ temp.cpp -std=c++20` produces the expected output

[Bug target/106733] bpf: facilitate constant propagation of function addresses

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

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

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

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

commit r13-2173-g6d1f144b3e6e3761375bea657718f58fb720fb44
Author: Jose E. Marchesi 
Date:   Wed Aug 24 13:07:57 2022 +0200

bpf: facilitate constant propagation of function addresses

eBPF effectively supports two kind of call instructions:

- The so called pseudo-calls ("bpf to bpf").
- External calls ("bpf to kernel").

The BPF call instruction always gets an immediate argument, whose
interpretation varies depending on the purpose of the instruction:

- For pseudo-calls, the immediate argument is interpreted as a
  32-bit PC-relative displacement measured in number of 64-bit words
  minus one.

- For external calls, the immediate argument is interpreted as the
  identification of a kernel helper.

In order to differenciate both flavors of CALL instructions the SRC
field of the instruction (otherwise unused) is abused as an opcode;
if the field holds 0 the instruction is an external call, if it holds
BPF_PSEUDO_CALL the instruction is a pseudo-call.

C-to-BPF toolchains, including the GNU toolchain, use the following
practical heuristic at assembly time in order to determine what kind
of CALL instruction to generate: call instructions requiring a fixup
at assembly time are interpreted as pseudo-calls.  This means that in
practice a call instruction involving symbols at assembly time (such
as `call foo') is assembled into a pseudo-call instruction, whereas
something like `call 12' is assembled into an external call
instruction.

In both cases, the argument of CALL is an immediate: at the time of
writing eBPF lacks support for indirect calls, i.e. there is no
call-to-register instruction.

This is the reason why BPF programs, in practice, rely on certain
optimizations to happen in order to generate calls to immediates.
This is a typical example involving a kernel helper:

  static void * (*bpf_map_lookup_elem)(void *map, const void *key)
= (void *) 1;

  int foo (...)
  {
char *ret;

ret = bpf_map_lookup_elem (args...);
if (ret)
  return 1;
return 0;
  }

Note how the code above relies on the compiler to do constant
propagation so the call to bpf_map_lookup_elem can be compiled to a
`call 1' instruction.

While GCC provides a kernel_helper function declaration attribute that
can be used in a robust way to tell GCC to generate an external call
despite of optimization level and any other consideration, the Linux
kernel bpf_helpers.h file relies on tricks like the above.

This patch modifies the BPF backend to avoid SSA sparse constant
propagation to be "undone" by the expander loading the function
address into a register.  A new test is also added.

Tested in bpf-unknown-linux-gnu.
No regressions.

gcc/ChangeLog:

PR target/106733
* config/bpf/bpf.cc (bpf_legitimate_address_p): Recognize integer
constants as legitimate addresses for functions.
(bpf_small_register_classes_for_mode_p): Define target hook.

gcc/testsuite/ChangeLog:

PR target/106733
* gcc.target/bpf/constant-calls.c: Rename to ...
* gcc.target/bpf/constant-calls-1.c: and modify to not expect
failure anymore.
* gcc.target/bpf/constant-calls-2.c: New test.

[Bug target/106733] New: bpf: facilitate constant propagation of function addresses

[jose.marchesi at oracle dot com via Gcc-bugs]

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

Bug ID: 106733
   Summary: bpf: facilitate constant propagation of function
addresses
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jose.marchesi at oracle dot com
  Target Milestone: ---

eBPF effectively supports two kind of call instructions:

- The so called pseudo-calls ("bpf to bpf").
- External calls ("bpf to kernel").

The BPF call instruction always gets an immediate argument, whose
interpretation varies depending on the purpose of the instruction:

- For pseudo-calls, the immediate argument is interpreted as a
  32-bit PC-relative displacement measured in number of 64-bit words
  minus one.

- For external calls, the immediate argument is interpreted as the
  identification of a kernel helper.

In order to differenciate both flavors of CALL instructions the SRC
field of the instruction (otherwise unused) is abused as an opcode;
if the field holds 0 the instruction is an external call, if it holds
BPF_PSEUDO_CALL the instruction is a pseudo-call.

C-to-BPF toolchains, including the GNU toolchain, use the following
practical heuristic at assembly time in order to determine what kind
of CALL instruction to generate: call instructions requiring a fixup
at assembly time are interpreted as pseudo-calls.  This means that in
practice a call instruction involving symbols at assembly time (such
as `call foo') is assembled into a pseudo-call instruction, whereas
something like `call 12' is assembled into an external call
instruction.

In both cases, the argument of CALL is an immediate: at the time of
writing eBPF lacks support for indirect calls, i.e. there is no
call-to-register instruction.

This is the reason why BPF programs, in practice, rely on certain
optimizations to happen in order to generate calls to immediates.
This is a typical example involving a kernel helper:

  static void * (*bpf_map_lookup_elem)(void *map, const void *key
= (void *) 1;

  int foo (...)
  {
char *ret;

ret = bpf_map_lookup_elem (args...);
if (ret)
  return 1;
return 0;
  }

Note how the code above relies on the compiler to do constant
propagation so the call to bpf_map_lookup_elem can be compiled to a
`call 1' instruction.

While GCC provides a kernel_helper function declaration attribute that
can be used in a robust way to tell GCC to generate an external call
despite of optimization level and any other consideration, the Linux
kernel bpf_helpers.h file relies on tricks like the above.

The BPF backend is currently causing the expander to "undo" SSA constant
propagations like the above by loading function addresses into registers.  This
makes code like the above to not compile properly even with optimization levels
of O2 or more.

[Bug libstdc++/106589] [12 Regression] visit rejects lambdas that do not return void

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Fixed for 12.3, thanks for the report.

[Bug libstdc++/106589] [12 Regression] visit rejects lambdas that do not return void

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:219d9f61a241d370b7933aecae56ce0905465830

commit r12-8711-g219d9f61a241d370b7933aecae56ce0905465830
Author: Jonathan Wakely 
Date:   Tue Aug 23 15:46:16 2022 +0100

libstdc++: Fix visit(v) for non-void visitors [PR106589]

The optimization for the common case of std::visit forgot to handle the
edge case of passing zero variants to a non-void visitor and converting
the result to void.

libstdc++-v3/ChangeLog:

PR libstdc++/106589
* include/std/variant (__do_visit): Handle is_void for zero
argument case.
* testsuite/20_util/variant/visit_r.cc: Check std::visit(v).

(cherry picked from commit e85bb1881e57e53306ede2a15f30d06480d69886)

[Bug c++/66995] [DR317] First declaration as inline after definition of function

[whh8b at obs dot cr via Gcc-bugs]

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

--- Comment #5 from Will Hawkins  ---
Not sure that I will have any success, but I'd like to give fixing this issue a
try. I will keep you posted.

[Bug c++/106729] Missing diagnostic for violation of 9.2.8.5

[whh8b at obs dot cr via Gcc-bugs]

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

--- Comment #2 from Will Hawkins  ---
Thanks for the feedback, Jonathan. Sorry for the duplicate.

Will

[Bug libstdc++/103629] [11/12/13 Regression] wrong-code when mixing mutex with visibility=hidden

[malat at debian dot org via Gcc-bugs]

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

--- Comment #26 from Mathieu Malaterre  ---
This may be related to:

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

[Bug libstdc++/103629] [11/12/13 Regression] wrong-code when mixing mutex with visibility=hidden

[malat at debian dot org via Gcc-bugs]

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

--- Comment #25 from Mathieu Malaterre  ---
Looks like there is an easy fix (work-around?):

% cat Tree.h
#pragma once

#include 
#include 

class
#ifdef VIS
__attribute__((visibility("default")))
#endif
Tree {
public:
  static const std::string treeType() {
static std::once_flag once;
std::call_once(once, []() {
  std::printf("%p\n", );
  sTreeTypeName.reset(new std::string());
});
std::printf("%p\n", );
if (!sTreeTypeName)
  throw "uhoh";
return *sTreeTypeName;
  }

private:
  static std::unique_ptr sTreeTypeName;
};

std::unique_ptr Tree::sTreeTypeName;

[Bug libstdc++/103629] [11/12/13 Regression] Possible miscompilation visible using pthread + exception

[malat at debian dot org via Gcc-bugs]

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

--- Comment #24 from Mathieu Malaterre  ---
I have change the openvdb.cc code into:

% cat openvdb.cc
#include "Tree.h"

static std::string do_segfault() { return Tree::treeType(); }

#ifdef VIS
__attribute__((visibility("default")))
#endif
void initialize()
{
  do_segfault();
}

Now I can demonstrate that the issue only happen when using the visibility flag
(no-symptom using the default UNIX mechanism to export all symbols).

[Bug libstdc++/103629] [11/12/13 Regression] Possible miscompilation visible using pthread + exception

[malat at debian dot org via Gcc-bugs]

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

--- Comment #23 from Mathieu Malaterre  ---
Created attachment 53502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53502=edit
non-working save-temps

[Bug libstdc++/103629] [11/12/13 Regression] Possible miscompilation visible using pthread + exception

[malat at debian dot org via Gcc-bugs]

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

--- Comment #22 from Mathieu Malaterre  ---
Created attachment 53501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53501=edit
working save-temps

[Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate

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

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

--- Comment #3 from rdapp at gcc dot gnu.org ---
I though expand (or combine) were independent of value range. What would be the
proper place for it then?

[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b

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

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

--- Comment #19 from Segher Boessenkool  ---
(In reply to Andreas Krebbel from comment #18)
> (In reply to Segher Boessenkool from comment #17)
> ...
> > Yes, but that says the high 48 bits of the hardware reg are untouched, which
> > is not true (only the high 16 of the low 32 are guaranteed unmodified).
> 
> Right, if the original register mode does not match the mode of the full
> hardreg, we continue to need that mode as the upper bound. So with the
> subreg folding in reload we appear to loose information we need to interpret
> the STRICT_LOW_PART correctly.

Exactly.  This is why strict_low_part of anything else than a subreg is
ill-defined.

[Bug c++/66995] [DR317] First declaration as inline after definition of function

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2021-08-04 00:00:00 |2022-8-24

--- Comment #4 from Jonathan Wakely  ---
Clang rejects this:

in.C:2:13: error: inline declaration of 'f' follows non-inline definition
inline void f();
^
in.C:1:6: note: previous definition is here
void f() {}
 ^
1 error generated.

EDG accepts it by default, but rejects it with --strict:

"in.C", line 2: error: function "f" cannot be declared inline after its
  definition at line 1
  inline void f();
  ^

1 error detected in the compilation of "in.C".

[Bug c++/66995] [DR317] First declaration as inline after definition of function

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||whh8b at obs dot cr

--- Comment #3 from Jonathan Wakely  ---
*** Bug 106729 has been marked as a duplicate of this bug. ***

[Bug c++/106729] Missing diagnostic for violation of 9.2.8.5

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Will Hawkins from comment #0)
> According to 9.2.8.5 of the C++ standard,

The subclause numbers change with each revision of the standard, so although
"the C++ standard" is currently unambigously C++20, it's more helpful to state
which revision you're referring to, or use the stable tags. In C++20 9.2.8/5 is
[dcl.inline]/5, which says:

"If a definition of a function or variable is reachable at the point of its
first declaration as inline, the program is ill-formed."

This rule first appeared in C++11, added by , and we
already have a bug for that: PR 66995

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

[Bug c++/66995] [DR317] First declaration as inline after definition of function

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> So this is DR317.

And the new rule first appeared in C++11.

[Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate

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

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

--- Comment #2 from Richard Biener  ---
I'd say all single-operation magic shouldn't happen in match.pd, this really
looks like something for RTL expansion to decide.  For example some targets
might have instructions that can either do cst - a or cst ^ a with an immediate
(when integer_pow2p (cst + 1)).

match.pd should be about canonicalization here (none of the two is "simpler"),
but canonicalization based on value-range looks a bit iffy.

[Bug middle-end/104069] -Werror=use-after-free false positive on elfutils-0.186

[vincent at systemli dot org via Gcc-bugs]

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

vincent at systemli dot org changed:

   What|Removed |Added

 CC||vincent at systemli dot org

--- Comment #24 from vincent at systemli dot org ---
elfutils 0.187 with gcc 12.2.0

In function 'bigger_buffer',
inlined from '__libdw_gunzip' at gzip.c:376:12:
gzip.c:98:9: error: pointer may be used after 'realloc'
[-Werror=use-after-free]
   98 | b = realloc (state->buffer, more -= 1024);
  | ^
gzip.c:96:13: note: call to 'realloc' here
   96 |   char *b = realloc (state->buffer, more);
  | ^
cc1: all warnings being treated as errors

[Bug fortran/106731] ICE on automatic array of derived type with DTIO

[federico.perini at gmail dot com via Gcc-bugs]

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

--- Comment #2 from federico  ---
For the sake of completeness, fixed-size does not cause an ICE: 

type(t) :: fixed(5) ! works

[Bug sanitizer/106726] ICE: verify_gimple failed (dead statement in EH table) on __builtin_alloca_with_align() with -fsanitize=hwaddress -fstack-check=generic -fexceptions

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||matmal01 at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
So started with r11-5377-g93a732514865f3.

[Bug c++/106646] [C++23] P2437R1 - Support for #warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Implemented for GCC 13.

[Bug c++/98940] Implement C++23 language features

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

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

Bug 106646 Summary: [C++23] P2437R1 - Support for #warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106646

   What|Removed |Added

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

[Bug target/106721] Error: invalid character '<' in mnemonic since r13-2122-g86c0d98620ee3a

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

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

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

https://gcc.gnu.org/g:846e5c009e360f0c4fe58ff0d3aee03ebe3ca1a9

commit r13-2168-g846e5c009e360f0c4fe58ff0d3aee03ebe3ca1a9
Author: Jakub Jelinek 
Date:   Wed Aug 24 09:57:09 2022 +0200

i386: Fix up mode iterators that weren't expanded [PR106721]

Currently, when md file reader sees  and something is valid mode
(or code) attribute but which doesn't include case for the current mode
(or code), it just keeps the  untouched.
I went through all cases matching <[a-zA-Z] in tmp-mddump.md after make
mddump.
Most of the cases were related to the recent V*BF mode additions, some
to V*HF mode too, and there was one typo.

2022-08-24  Jakub Jelinek  

PR target/106721
* config/i386/sse.md (shuffletype): Add V32BF, V16BF and V8BF
entries.
Change V32HF, V16HF and V8HF entries from "f" to "i".
(iptr): Add V32BF, V16BF, V8BF and BF entries.
(i128vldq): Add V16HF and V16BF entries.
(avx512er_vmrcp28): Fix typo,
mask_opernad3 -> mask_operand3.

* gcc.target/i386/avx512vl-pr106721.c: New test.

[Bug c++/106732] New: lock cannot be generated in a special case

[benni.probst at gmx dot de via Gcc-bugs]

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

Bug ID: 106732
   Summary: lock cannot be generated in a special case
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benni.probst at gmx dot de
  Target Milestone: ---

Created attachment 53500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53500=edit
CLion bug analysis picture

when using a recursive mutex and a scoped lock or unique lock or lock guard
(does not matter) on the recursive mutex, code cannot be generated even if it
worked in the function above.

//
// Created by benjamin-elias on 09.05.22.
//

#include "config_files.h"
#include "global_custom_functions.h"

#ifndef SCHOOL_PROJECT_DATABASE_CALL_OPS_H
#define SCHOOL_PROJECT_DATABASE_CALL_OPS_H


class database_call_ops {
bool connection_set=false;
std::recursive_mutex database_mutex{};
pqxx::connection *connection;
protected:
std::string addr, p, user, pass, datab;
//TODO: set up connection and custom database call ops
public:
std::string schem, tab;
protected:
bool open=false;

virtual std::string currentSchema() {
const std::lock_guard lock(database_mutex);
return schem;
}

virtual std::string currentTableName() {
const std::lock_guard lock(database_mutex);
return tab;
}

[[nodiscard]] bool isOpen(const std::string ) const {
const std::scoped_lock lock(database_mutex);
return open and tab==table;
}

std::string currentDatabase() {
return datab;
}

bool checkSchemaExists(const std::string ) {
try{
std::string sql = "SELECT EXISTS(SELECT schema_name FROM
information_schema.schemata WHERE schema_name = '"+schema+"');";
custom_function::replace_string_occurencies(sql,"  "," ");
pqxx::nontransaction n(connection);
pqxx::result r(n.exec(sql));
n.commit();
for (pqxx::result::const_iterator c = r.begin(); c != r.end();) {
auto it = c;
if(++c == r.end())[[likely]]{ return it[0].as();}
else break;
}
}
catch (std::exception ){
std::cerr << "checkSchemaExists on " << schema << " failed for this
reason: " << e.what();
}
return false;
}

//returns if schema exists now
bool createSchema(const std::string ) {
if (checkSchemaExists(schema))[[likely]]return true;
try{
std::string sql = "CREATE SCHEMA IF NOT EXISTS " + schema + "
AUTHORIZATION " + user + " ; GRANT ALL ON SCHEMA " + schema + " TO " + datab +
" ; GRANT ALL ON SCHEMA " + schema + " TO public;";
custom_function::replace_string_occurencies(sql,"  "," ");
pqxx::work n(connection);
n.exec(sql);
n.commit();
}
catch (std::exception ){
std::cerr << "createSchema on " << schema << " failed for this
reason: " << e.what();
exit(EXIT_FAILURE);
}

return checkSchemaExists(schema);
}

bool deleteSchema(const std::string ) {
if (!checkSchemaExists(schema))[[unlikely]]{return false;}
try{
std::string sql = "DROP SCHEMA IF EXISTS "+schema+" CASCADE;";
custom_function::replace_string_occurencies(sql,"  "," ");
pqxx::work n(connection);
n.exec(sql);
n.commit();
}
catch (std::exception ){
std::cerr << "deleteSchema on " << schema << " failed for this
reason: " << e.what();
}

return !checkSchemaExists(schema);
}

bool checkTableExists(const std::string , const std::string )
{
if (!checkSchemaExists(schema))[[unlikely]]{return false;}
try{
std::string sql = "SELECT EXISTS (SELECT FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_namespace n"
  " ON n.oid = c.relnamespace WHERE n.nspname =
'"+schema+"' AND c.relname = '"+table+
  "' AND c.relkind = 'r' );";
custom_function::replace_string_occurencies(sql,"  "," ");
pqxx::nontransaction n(connection);
pqxx::result r(n.exec(sql));
n.commit();
for (pqxx::result::const_iterator c = r.begin(); c != r.end();) {
auto it = c;
if(++c == r.end())[[likely]]{return it[0].as();}
else break;
}
}
catch (std::exception ){
std::cerr << "checkTableExists on (Schema: " << schema << ", Table:
" << table << ") failed for this reason: " << e.what();
}
return false;
}


std::vector>
table_info(const std::string , const std::string ) {
std::vector> out;
try{
//table_name, column_name, 

[Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate

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

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

rdapp at gcc dot gnu.org changed:

   What|Removed |Added

 Target|s390|s390 x86_64-linux-gnu
 CC||glisse at gcc dot gnu.org,
   ||rdapp at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
Summary|s390: Compiler does not |Compiler does not take into
   |take into account number|account number range
   |range limitation to avoid   |limitation to avoid
   |subtract from immediate |subtract from immediate

--- Comment #1 from rdapp at gcc dot gnu.org ---
Added x86 to targets because we don't seem to optimize this there either (at
least I didn't see it on my recent-ish GCC).

The following (not regtested) helps on s390

diff --git a/gcc/match.pd b/gcc/match.pd
index e486b4be282c..2ebbf68010f9 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -7992,3 +7992,27 @@ and,
 (match (bitwise_induction_p @0 @2 @3)
  (bit_not
   (nop_convert1? (bit_xor@0 (convert2? (lshift integer_onep@1 @2)) @3
+
+/* cst - a -> cst ^ a if 0 >= a <= cst and integer_pow2p (cst + 1).  */
+#if GIMPLE
+(simplify
+ (minus INTEGER_CST@0 @1)
+ (with {
+wide_int w = wi::to_wide (@0) + 1;
+value_range vr;
+wide_int wmin = w;
+wide_int wmax = w;
+if (get_global_range_query ()->range_of_expr (vr, @1)
+   && vr.kind () == VR_RANGE)
+   {
+ wmin = vr.lower_bound ();
+ wmax = vr.upper_bound ();
+   }
+  }
+   (if (wi::exact_log2 (w) != -1
+   && wi::geu_p (wmin, 0)
+   && wi::leu_p (wmax, w))
+(bit_xor @0 @1))
+ )
+)
+#endif

but it can surely be improved by some match.pd magic still.  A second question
would be, do we unconditionally want to simplify this or should it rather be
backend dependent?

[Bug c++/106646] [C++23] P2437R1 - Support for #warning

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

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

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

https://gcc.gnu.org/g:365202625d2f2d6694dba889ca67498fefb59c68

commit r13-2167-g365202625d2f2d6694dba889ca67498fefb59c68
Author: Jakub Jelinek 
Date:   Wed Aug 24 09:55:57 2022 +0200

preprocessor: Implement C++23 P2437R1 - Support for #warning [PR106646]

On Thu, Aug 18, 2022 at 11:02:44PM +, Joseph Myers wrote:
> ISO C2x standardizes the existing #warning extension.  Arrange
> accordingly for it not to be diagnosed with -std=c2x -pedantic, but to
> be diagnosed with -Wc11-c2x-compat.

And here is the corresponding C++ version.
Don't pedwarn about this for C++23/GNU++23 and tweak the diagnostics
for C++ otherwise, + testsuite coverage.
The diagnostic wording is similar e.g. to the #elifdef diagnostics.

2022-08-24  Jakub Jelinek  

PR c++/106646
* init.cc: Implement C++23 P2437R1 - Support for #warning.
(lang_defaults): Set warning_directive for GNUCXX23 and CXX23.
* directives.cc (directive_diagnostics): Use different wording of
#warning pedwarn for C++.

* g++.dg/cpp/warning-1.C: New test.
* g++.dg/cpp/warning-2.C: New test.
* g++.dg/cpp/warning-3.C: New test.

[Bug target/106459] Compiler crashing for loongarch64-linux-gnu on windows

[paul.hua.gm at gmail dot com via Gcc-bugs]

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

Paul Hua  changed:

   What|Removed |Added

 CC||paul.hua.gm at gmail dot com

--- Comment #6 from Paul Hua  ---
Fix patch.
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600185.html

[Bug fortran/106731] ICE on automatic array of derived type with DTIO

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-08-24
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Likely started with r7-2882-ge73d3ca6d1caf9c1.

[Bug fortran/106731] New: ICE on automatic array of derived type with DTIO

[federico.perini at gmail dot com via Gcc-bugs]

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

Bug ID: 106731
   Summary: ICE on automatic array of derived type with DTIO
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico.perini at gmail dot com
  Target Milestone: ---

A derived type that has user-defined I/O causes ICE on all gfortran versions 7
to 12.1.0, whenever it's being used as an automatic object.

The error is at 


   63 | type(t) :: automatic(n)
  |   1
internal compiler error: in gfc_trans_auto_array_allocation, at
fortran/trans-array.cc:6617

This does not happen if the derived type is allocated.

Here's the simplest example: 

module causes_ice
implicit none

type :: t
real(8) :: x
contains
procedure, private :: write_formatted
generic :: write(formatted) => write_formatted
end type t

contains

subroutine write_formatted(this, unit, iotype, v_list, iostat, iomsg)
   class(t), intent(in) :: this
   integer, intent(in) :: unit
   character(*), intent(in) :: iotype
   integer, intent(in) :: v_list(:)
   integer, intent(out) :: iostat
   character(*), intent(inout) :: iomsg
   write(unit, '(a)', iostat=iostat, iomsg=iomsg) 'dummy'
end subroutine write_formatted

end module causes_ice

module use_t
use causes_ice
implicit none

public :: automatic_alloc

contains

subroutine automatic_alloc(n)
integer, intent(in) :: n

! Automatic array: ICE!
type(t) :: automatic(n)

! Allocatable: works
type(t), allocatable :: alloc(:)
allocate(alloc(n))

! Do anything
print *, 'n=',n,automatic(n)%x

end subroutine automatic_alloc

end module use_t

program test
use use_t
call automatic_alloc(1)
end program test

I could find other DTIO-related bugs, but none seemed related with the
allocation type.

[Bug target/106723] Unreplaced mode/code attributes in aarch64/arm backends

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

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

--- Comment #2 from Jakub Jelinek  ---
I think better would be to error out (or just warn) if we see a valid mode/code
attribute which doesn't handle the corresponding mode/code.
For the PR106721, that would diagnose all but the last issue where there was a
typo, but that one is hard to distinguish from  or  etc. appearing in
comments or perhaps assembly syntax on some targets.

[Bug middle-end/106727] Missed fold / canonicalization for checking if a number is a power of 2

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-08-24

--- Comment #1 from Richard Biener  ---
Confirmed.  Expanding __builtin_popcount (n) <= 1 as (n & (n - 1)) == 0 might
be already done.  The canonicalization could be applied if .POPCOUNT is
available.

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

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

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

--- Comment #11 from Kewen Lin  ---
Oops, the reference links in #c10 are:

[1] https://gcc.gnu.org/pipermail/gcc-patches/2016-September/458210.html
[2] https://gcc.gnu.org/pipermail/gcc-patches/2016-September/458287.html
[3] https://gcc.gnu.org/pipermail/gcc-patches/2016-October/458587.html

[Bug middle-end/106725] LTO semantics for __attribute__((leaf))

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
For GCC "leaf" is interpreted at the LTO WPA stage where 'compilation unit'
then
means the whole program.  Note that "leaf" doesn't mean calls "back" into the
CU that GCC _can see_ are invalid - those are treated correctly.  It's
basically an optimization promise that if GCC doesn't see such call it can
assume there
are no "hidden" ones.

If GCC, with LTO, would partition the program into two LTRANS partitions,
one containing main and bar and one containing foo then applying this
optimization promise during LTRANS time on the main/bar partition would
be wrong as you say - but I think GCC doesn't do this.

As for documentation I think 'compilation unit' should be changed to
'translation unit', since that's the only thing a user can reason about.
The compiler then has to make sure to apply compatible reasoning when
combining multiple translation units.

Honza?

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

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

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

--- Comment #10 from Kewen Lin  ---
By searching the history of this feature, I found its initial versions only
proposed to place nops after the function entry, such as: v2[1], then it's
requested to be more generic to handle some "exploited atomically" requirements
for RISV arches. Please see the below quoted content posted by Jose for
SPARC[2] and more [3] to extend it for preceding nops.

"
  How is this supposed to be exploited atomically in RISC arches such as
  sparc?  In such architectures you usually need to patch several
  instructions to load an absolute address into a register.

  If a general mechanism is what is intended I would suggest to offer the
  possibility of extending the nops _before_ the function entry point,
  like in:

  (a) nop   ! Load address
  nop   ! Load address
  nop   ! Load address
  nop   ! Load address
  nop   ! Jump to loaded address.
  entry:
  (b) nop   ! PC-relative jump to (a)
  save %sp, bleh, %sp
  ...

  So after the live-patcher patches the loading of the destination address
  and the jump, it can atomically patch (b) to effectively replace the
  implementation of `entry'.
"

So placing just only one nop after function entry and leaving multiple nops to
be patched before function entry was meant to make it exploited atomically.

I'm not sure if there will be this kind of requirement for future uses of this
feature on ppc64le. If we assume there is, we need to consider if the current
proposal can support it and even easily.

With proposal 1) in #c1, that is to place nops before and after local entry
point. It allows three kinds of counts for preceding nops: 2, 6 and 14. IMHO,
the count 14 seems to be enough for most cases? But people can blame it's not
flexible for all kinds of counts, and it can take more size if the required
count doesn't perfectly match one allowable count. Besides, it can offer bad
user experience when users port their workable cases here but get errors.

With proposal in #5, it doesn't have the restriction on the count of preceding
nops, it's a very good thing. The main concern is what Segher pointed out, the
patched nops are concluded to be consecutive, in the initial versions it's more
explicit as the option name is "prolog-pad". And the separated nop sequences
are for different function entry points, not for "the" function entry.

To offer more flexibility to users, proposal in #5 looks better, but it
requires one documentation update by saying the particularity on ppc64le, that
is dual entries and the patching way.

[Bug target/106724] logical-op-non-short-circuit maybe should be 1

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

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

--- Comment #3 from Richard Biener  ---
we usually define logical-op-non-short-circuit based on branch cost

[Bug target/106723] Unreplaced mode/code attributes in aarch64/arm backends

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

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

--- Comment #1 from Richard Biener  ---
I wonder if the generator should simply skip mode combinations when a mode
attribute fails to expand?  That could be also used as "conditional iteration"
using a mode attribute expanding to "".

[Bug fortran/106730] [OpenMP][valid since 5.0] ICE in install_var_field, at omp-low.cc:797 for 'map(alloc:var) map(to:var)' (more than once in map clause)

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

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

Tobias Burnus  changed:

   What|Removed |Added

Summary|[OpenMP] ICE in |[OpenMP][valid since 5.0]
   |install_var_field, at   |ICE in install_var_field,
   |omp-low.cc:797  |at omp-low.cc:797 for
   ||'map(alloc:var)
   ||map(to:var)' (more than
   ||once in map clause)

--- Comment #1 from Tobias Burnus  ---
Okay – that's the
  ‘member’ appears more than once in map clauses
issue

For C/C++, there is this error – for Fortran not:
  error: ‘member’ appears more than once in map clauses
(same for 'a' and 'scalar') using the C testcase at
https://github.com/SOLLVE/sollve_vv/blob/master/tests/5.0/target/test_target_mapping_before_alloc.c
for the C/C++ testcase.

I think one pending patch was addressing on this.
Indeed, using devel/omp/gcc-12 (OG12), it compiles + runs for Fortran -
but still fails for C/C++ with the "more than once" error.

I think it is part of the following patch set:
* [PATCH 00/16] OpenMP: lvalues in "map" clauses and struct handling rework
   https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586600.html
   and January + February updates (search for metadirective)
+ patch review end of May, e.g.
   https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595762.html (+ 4 more
emails)