[Bug target/103422] New: -march=bogus12323123423452345 -march=armv8-a is accepted

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

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

Bug ID: 103422
   Summary: -march=bogus12323123423452345 -march=armv8-a is
accepted
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Just like PR 103421 but this one is for aarch64.

[Bug libgcc/103420] libatomic fails to compile on aarch64 linux with TFLAGS="-mcpu=octeontx2"

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
 Ever confirmed|1   |0
 Status|ASSIGNED|UNCONFIRMED

--- Comment #2 from Andrew Pinski  ---
Not working on this, there needs to be a way to enable/disabling LSE (and other
extensions) on the command line without needing to use -march= option.

[Bug target/103421] -march=bogus12323123423452345 -march=skylake-avx512 is accepted as a command line option

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

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

--- Comment #1 from Andrew Pinski  ---
Only the last march is passed down to cc1 which does the verification of the
option :).

[Bug target/103421] New: -march=bogus12323123423452345 -march=skylake-avx512 is accepted as a command line option

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

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

Bug ID: 103421
   Summary: -march=bogus12323123423452345 -march=skylake-avx512 is
accepted as a command line option
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64

While looking into figuring out the best way of fixing an aarch64 issue I
decided to test what x86_64 does and lone and behold, x86_64 also allow bogus
values for -march too.

gcc -march=bogus12323123423452345 -march=skylake-avx512
gives no warning or error message.

[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 102611, which changed state.

Bug 102611 Summary: [C++23] P2128R6 - Multidimensional subscript operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102611

   What|Removed |Added

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

[Bug c++/102611] [C++23] P2128R6 - Multidimensional subscript operator

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Jakub Jelinek  ---
Now implemented for GCC 12.

[Bug c++/101180] [12 Regression] Rejected code since r12-299-ga0fdff3cf33f7284

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

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

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

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

commit r12-5511-g8e86218f05c1a866b43ae5af3e303f91fb6d7ff0
Author: Jakub Jelinek 
Date:   Thu Nov 25 08:39:35 2021 +0100

c++: Return early in apply_late_template_attributes if there are no late
attribs [PR101180]

The r12-299-ga0fdff3cf33f7284 change can result in cplus_decl_attributes
being called
even if there are no late attributes (but at least one early attribute) in
apply_late_template_attributes.  This patch fixes that, so that we return
early
if there are no late attrs, only arrange for TYPE_ATTRIBUTES to get the
early
attribute list.

2021-11-25  Jakub Jelinek  

PR c++/101180
* pt.c (apply_late_template_attributes): Return early if there are
no
dependent attributes.

[Bug middle-end/103393] [12 Regression] Generating 256bit register usage with -mprefer-avx128 -mprefer-vector-width=128

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

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

--- Comment #9 from Richard Biener  ---
In particular MOVE_RATIO only looks applicable if the target (or RTL
expansion?) would split the bigger GIMPLE move into pieces honoring MOVE_MAX. 
Though technically even MOVE_MAX only guarantees:

"The maximum number of bytes that a single instruction can move _QUICKLY_
between memory and registers or between two memory locations."

(emphasis mine)

[Bug c++/102611] [C++23] P2128R6 - Multidimensional subscript operator

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

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

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

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

commit r12-5510-gb38c9cf6d570f6c4c1109e00c8b81d82d0f24df3
Author: Jakub Jelinek 
Date:   Thu Nov 25 08:36:20 2021 +0100

c++: Implement C++23 P2128R6 - Multidimensional subscript operator
[PR102611]

The following patch implements the C++23 Multidimensional subscript
operator
P2128R6 paper.
As C++20 and older only allow a single expression in between []s (albeit
for C++20 with a deprecation warning if it is a comma expression) and even
in C++23 and for the coming years I think the vast majority of subscript
expressions will still have a single expression and even in C++23 it is
quite special, as e.g. the builtin operator requires exactly one
assignment expression, the patch attempts to optimize for that case and
if possible not to slow down that common case (or use more memory for it).
So, already during parsing it differentiates between that (uses a single
index_exp tree in that case) and the new cases (zero or two+ expressions
in the list), for which it sets index_exp to NULL_TREE and uses a
releasing_vec instead similarly to how e.g. finish_call_expr uses it.
In call.c it introduces new functions build_op_subscript{,_1} which are
something in between build_new_op{,_1} and build_op_call{,_1}.
The former requires fixed number of arguments (and the patch still uses
it for the common case of subscript with exactly one index expression),
the latter handles variable number of arguments but is too CALL_EXPR
specific
and handles various cases that are unnecessary for the subscript.
Right now the subscript for 0 or 2+ expressions doesn't need to deal with
builtin candidates and so is quite simple.

As discussed in the paper, for backwards compatibility, if for 2+ index
expressions build_op_subscript fails (called with tf_none) and the
expressions together form a valid comma expression (again checked with
tf_none), it is used that C++20-ish way with a pedwarn about it, but if
even that fails, build_op_subscript is called again with standard complain
flags to diagnose it in the new way.  And similarly for the builtin case.

The -Wcomma-subscript warning used to be enabled by default unless
-Wno-deprecated.  Since the C/C++98..20 behavior is no longer deprecated,
but ill-formed or changed meaning, it is now for C++23 enabled by
default regardless of -Wno-deprecated and controls the pedwarn (but not the
errors emitted if something wasn't valid before and isn't valid in C++23
either).

2021-11-25  Jakub Jelinek  

PR c++/102611
gcc/
* doc/invoke.texi (-Wcomma-subscript): Document that for
-std=c++20 the option isn't enabled by default with -Wno-deprecated
but for -std=c++23 it is.
gcc/c-family/
* c-opts.c (c_common_post_options): Enable -Wcomma-subscript by
default for C++23 regardless of warn_deprecated.
* c-cppbuiltin.c (c_cpp_builtins): Predefine
__cpp_multidimensional_subscript=202110L for C++23.
gcc/cp/
* cp-tree.h (build_op_subscript): Implement P2128R6
- Multidimensional subscript operator.  Declare.
(class releasing_vec): Add release method.
(grok_array_decl): Remove bool argument, add vec **
and tsubst_flags_t arguments.
(build_min_non_dep_op_overload): Declare another overload.
* parser.c (cp_parser_parenthesized_expression_list_elt): New
function.
(cp_parser_postfix_open_square_expression): Mention C++23 syntax in
function comment.  For C++23 parse zero or more than one
initializer
clauses in expression list, adjust grok_array_decl caller.
(cp_parser_parenthesized_expression_list): Use
cp_parser_parenthesized_expression_list_elt.
(cp_parser_builtin_offsetof): Adjust grok_array_decl caller.
* decl.c (grok_op_properties): For C++23 don't check number
of arguments of operator[].
* decl2.c (grok_array_decl): Remove decltype_p argument, add
index_exp_list and complain arguments.  If index_exp is NULL,
handle *index_exp_list as the subscript expression list.
* tree.c (build_min_non_dep_op_overload): New overload.
* call.c (add_operator_candidates, build_over_call): Adjust
comments
for removal of build_new_op_1.
(build_op_subscript): New function.
* pt.c (tsubst_copy_and_build_call_args): New function.
(tsubst_copy_and_build) : If second
operand is magic CALL_EXPR with ovl_op_identifier (ARRAY_REF)
as CALL_EXPR_FN, tsubst CALL_EXPR arguments including 

[Bug libgcc/103420] libatomic fails to compile on aarch64 linux with TFLAGS="-mcpu=octeontx2"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Last reconfirmed||2021-11-25

--- Comment #1 from Andrew Pinski  ---
Here is the error message:
/bin/sh ./libtool  --tag=CC   --mode=compile
/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/./gcc/xgcc
-B/home/ubuntu/src/upstream-gcc-aarch64/gcc/objdir/./gcc/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/bin/
-B/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/lib/ -isystem
/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/include -isystem
/home/ubuntu/upstream-gcc/aarch64-unknown-linux-gnu/sys-include  
-mcpu=octeontx2 -fchecking=1 -DHAVE_CONFIG_H
-I/home/ubuntu/src/upstream-gcc-aarch64/gcc/libatomic/config/linux/aarch64
-I/home/ubuntu/src/upstream-gcc-aarch64/gcc/libatomic/config/posix
-I/home/ubuntu/src/upstream-gcc-aarch64/gcc/libatomic -I.-Wall -Werror  
-pthread -g -O2 -MT fior_1_1_.lo -MD -MP -MF .deps/fior_1_1_.lo.Ppo -DN=1
-DIFUNC_ALT=1 -march=armv8-a+lse -c -o fior_1_1_.lo
/home/ubuntu/src/upstream-gcc-aarch64/gcc/libatomic/fior_n.c
cc1: error: switch ‘-mcpu=octeontx2’ conflicts with ‘-march=armv8-a+lse’ switch
[-Werror]
cc1: all warnings being treated as errors

Mine.

[Bug libgcc/103420] New: libatomic fails to compile on aarch64 linux with TFLAGS="-mcpu=octeontx2"

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

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

Bug ID: 103420
   Summary: libatomic fails to compile on aarch64 linux with
TFLAGS="-mcpu=octeontx2"
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu

I was looking at the GCC patches that OpenEmbedded includes and found this one:
https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/gcc/gcc/0037-libatomic-Do-not-enforce-march-on-aarch64.patch

Well I decided to figure out how to reproduce the failure and what I found is
if I use TFLAGS="-mcpu=octeontx2" I run into the failure.

[Bug middle-end/103393] [12 Regression] Generating 256bit register usage with -mprefer-avx128 -mprefer-vector-width=128

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
  Component|target  |middle-end

--- Comment #8 from Richard Biener  ---
So my suggestion would be to revert the * MOVE_RATIO change.

[Bug middle-end/103416] [12 Regression][OpenMP] Bogus firstprivate(n) map(to:n [len: 4][implicit])

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug fortran/103413] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.4

[Bug fortran/103412] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.4

[Bug target/103393] [12 Regression] Generating 256bit register usage with -mprefer-avx128 -mprefer-vector-width=128

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #7 from rguenther at suse dot de  ---
On Thu, 25 Nov 2021, crazylht at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
> 
> --- Comment #6 from Hongtao.liu  ---
> (In reply to Hongtao.liu from comment #5)
> > (In reply to Richard Biener from comment #3)
> > > (In reply to H.J. Lu from comment #2)
> > > > (In reply to Richard Biener from comment #1)
> > > > > It isn't the vectorizer but memmove inline expansion.  I'm not sure 
> > > > > it's
> > > > > really a bug, but there isn't a way to disable %ymm use besides 
> > > > > disabling
> > > > > AVX entirely.
> > > > > HJ?
> > > > 
> > > > YMM move is generated by loop distribution which doesn't check
> > > > TARGET_PREFER_AVX128.
> > > 
> > > I think it's generated by gimple_fold_builtin_memory_op which since 
> > > Richards
> > > changes accepts bigger now, up to MOVE_MAX * MOVE_RATIO and that ends up
> > > picking an integer mode via
> > > 
> > >   scalar_int_mode mode;
> > >   if (int_mode_for_size (ilen * 8, 0).exists ()
> > >   && GET_MODE_SIZE (mode) * BITS_PER_UNIT == ilen * 8
> > >   && have_insn_for (SET, mode)
> > >   /* If the destination pointer is not aligned we must be
> > > able
> > >  to emit an unaligned store.  */
> > >   && (dest_align >= GET_MODE_ALIGNMENT (mode)
> > >   || !targetm.slow_unaligned_access (mode, dest_align)
> > >   || (optab_handler (movmisalign_optab, mode)
> > >   != CODE_FOR_nothing)))
> > > 
> > > not sure if there's another way to validate things.
> > 
> > For one single set operation, shouldn't the total size be less than MOVE_MAX
> > instead of MOVE_MAX * MOVE_RATIO?
> 
> r12-3482 change MOVE_MAX to MOVE_MAX * MOVE_RATIO

Yes, IIRC it was specifically to allow vector register moves on
aarch64/arm which doesn't seem to have a MOVE_MAX that exceeds
WORD_SIZE.  It looks like x86 carefully tries to have a MOVE_MAX
that honors -mprefer-xxx as to not exceed a single move size.

Both seem to be in conflict here.  Richard - why could arm/aarch64
not increase MOVE_MAX here?

[Bug tree-optimization/44011] missed optimization of min/max_expr or strict overflow warnings for intended code.

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Andrew Pinski  ---
So the missed optimization with -UWARN_AND_OPTIMIZE is fixed in GCC 5.
The warning is fully gone in GCC 8 for both cases since moving over to match
and simplify.

[Bug middle-end/103419] FAIL: gcc.target/i386/pr102566-10b.c with -mx32

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
(In reply to H.J. Lu from comment #2)
> Created attachment 51871 [details]
> A patch
> 
> Hongtao, please take a look.

Yes, i'll use type of second parameter which should be integer type.


582DEF_SYNC_BUILTIN (BUILT_IN_ATOMIC_FETCH_OR_4,
583  "__atomic_fetch_or_4",
584  BT_FN_I4_VPTR_I4_INT, ATTR_NOTHROWCALL_LEAF_LIST)

[Bug middle-end/103419] FAIL: gcc.target/i386/pr102566-10b.c with -mx32

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

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

--- Comment #2 from H.J. Lu  ---
Created attachment 51871
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51871=edit
A patch

Hongtao, please take a look.

[Bug middle-end/103419] FAIL: gcc.target/i386/pr102566-10b.c with -mx32

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

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Component|target  |middle-end
   Last reconfirmed||2021-11-25

--- Comment #1 from H.J. Lu  ---
(match (nop_atomic_bit_test_and_p @0 @1 @4)
 (bit_and (convert?@4 (ATOMIC_FETCH_OR_XOR_N @2 INTEGER_CST@0 @3))
   INTEGER_CST@1)
 (with {
 int ibit = tree_log2 (@0);
 int ibit2 = tree_log2 (@1);
   }
  (if (ibit == ibit2
  && ibit >= 0
  && TYPE_PRECISION (type) <= TYPE_PRECISION (TREE_TYPE (@2))

(match (nop_atomic_bit_test_and_p @0 @1 @3)
 (bit_and (convert?@3 (SYNC_FETCH_OR_XOR_N @2 INTEGER_CST@0))
  INTEGER_CST@1)
 (with {
 int ibit = tree_log2 (@0);
 int ibit2 = tree_log2 (@1);
   }
  (if (ibit == ibit2
  && ibit >= 0
  && TYPE_PRECISION (type) <= TYPE_PRECISION (TREE_TYPE (@2))

(match (nop_atomic_bit_test_and_p @0 @0 @4)
 (bit_and:c
  (convert1?@4
   (ATOMIC_FETCH_OR_XOR_N @2 (nop_convert? (lshift@0 integer_onep@5 @6)) @3))
  (convert2? @0))
 (if (TYPE_PRECISION (type) <= TYPE_PRECISION (TREE_TYPE (@2)

(match (nop_atomic_bit_test_and_p @0 @0 @4)
 (bit_and:c
  (convert1?@4
   (SYNC_FETCH_OR_XOR_N @2 (nop_convert? (lshift@0 integer_onep@3 @5
  (convert2? @0))
 (if (TYPE_PRECISION (type) <= TYPE_PRECISION (TREE_TYPE (@2)

are wrong. Here "type" is an integer type.  But TREE_TYPE (@2) is a pointer
type.  We should compare 2 integer types, not an integer type and a pointer
types.

[Bug c++/47256] "--sysroot" option is not passed to COLLECT_GCC_OPTIONS

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #6 from Andrew Pinski  ---
So I looked into this (since the patch is still in yocto as of today) but the
patch is no longer needed as -frepo support was removed in GCC 10 so keeping
this closed as won't fix.

I suspect yocto can remove this patch also because of that reason too.

[Bug middle-end/103419] New: FAIL: gcc.target/i386/pr102566-10b.c with -mx32

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

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

Bug ID: 103419
   Summary: FAIL: gcc.target/i386/pr102566-10b.c with -mx32
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
  Target Milestone: ---
Target: x86-64

On Linux/x86-64, -mx32 fails the following tests:

FAIL: gcc.target/i386/pr102566-10b.c scan-assembler-not cmpxchg
FAIL: gcc.target/i386/pr102566-10b.c scan-assembler-times lock;?[ \t]*btrq 1
FAIL: gcc.target/i386/pr102566-3b.c scan-assembler-not cmpxchg
FAIL: gcc.target/i386/pr102566-3b.c scan-assembler-times lock;?[ \t]*btsq 1

[Bug target/93453] PPC: rldimi not taken into account to avoid shift+or

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

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

--- Comment #8 from HaoChen Gui  ---
I refined the patch and put all things in a helper - change_pseudo_and_mask. As
you mentioned, it's still a band-aid. The perfect solution might be a better
version of nonzero_bits. Thanks.

diff --git a/gcc/combine.c b/gcc/combine.c
index 892c834a160..f0e6ca5d8cf 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -11539,6 +11539,41 @@ change_zero_ext (rtx pat)
   return changed;
 }

+/* Convert a psuedo to psuedo AND with a mask if its nonzero_bits is less
+   than its mode mask.  */
+static bool
+change_pseudo_and_mask (rtx pat)
+{
+  bool changed = false;
+
+  rtx src = SET_SRC (pat);
+  if ((GET_CODE (src) == IOR
+   || GET_CODE (src) == XOR
+   || GET_CODE (src) == PLUS)
+  && (((GET_CODE (XEXP (src, 0)) == ASHIFT
+   || GET_CODE (XEXP (src, 0)) == LSHIFTRT
+   || GET_CODE (XEXP (src, 0)) == AND)
+  && REG_P (XEXP (src, 1)))
+ || ((GET_CODE (XEXP (src, 1)) == ASHIFT
+  || GET_CODE (XEXP (src, 1)) == LSHIFTRT
+  || GET_CODE (XEXP (src, 1)) == AND)
+ && REG_P (XEXP (src, 0)
+{
+  rtx *reg = REG_P (XEXP (src, 0))
+?  (SET_SRC (pat), 0)
+:  (SET_SRC (pat), 1);
+  machine_mode mode = GET_MODE (*reg);
+  unsigned HOST_WIDE_INT nonzero = nonzero_bits (*reg, mode);
+  if (nonzero < GET_MODE_MASK (mode))
+   {
+ rtx x = gen_rtx_AND (mode, *reg, GEN_INT (nonzero));
+ SUBST (*reg, x);
+ changed = true;
+   }
+ }
+  return changed;
+}
+
 /* Like recog, but we receive the address of a pointer to a new pattern.
We try to match the rtx that the pointer points to.
If that fails, we may try to modify or replace the pattern,
@@ -11565,9 +11600,18 @@ recog_for_combine (rtx *pnewpat, rtx_insn *insn, rtx
*pnotes)

   void *marker = get_undo_marker ();
   bool changed = false;
+  //bool PIX_opt = false;

   if (GET_CODE (pat) == SET)
-changed = change_zero_ext (pat);
+{
+  changed = change_pseudo_and_mask (pat);
+  if (changed)
+   {
+ maybe_swap_commutative_operands (SET_SRC (pat));
+ //PIX_opt = true;
+   }
+  changed |= change_zero_ext (pat);
+}
   else if (GET_CODE (pat) == PARALLEL)
 {
   int i;
@@ -11585,6 +11629,8 @@ recog_for_combine (rtx *pnewpat, rtx_insn *insn, rtx
*pnotes)

   if (insn_code_number < 0)
undo_to_marker (marker);
+  //else if (PIX_opt)
+   //fprintf (stdout, "PIX applied\n");
 }

   return insn_code_number;

[Bug rtl-optimization/103404] ICE: SIGSEGV in insert_with_costs (cse.c:1569) with custom flags

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

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

--- Comment #5 from Tamar Christina  ---
This is a somewhat latent bug in CSE where merge_equiv_classes assumes that all
entries into the equivalence table are unique but CSE makes no attempt to
enforce this constraint.

So inserting the same equivalence into the table twice results in the same
entry being added twice but pointed to the same expression.

Normally this doesn't happen during normal value CSEing because a virtual reg
is assigned only once so you ever only get one SET statement with the given
DEST.

What changed with my patch is that the vectors of const_int also get
equivalences to constants inside a vector, i.e. you can extract an element from
the vector should you need it.

e.g. this instruction

(insn 18 17 24 2 (set (subreg:V1SI (reg:SI 97 [ _10 ]) 0)
(const_vector:V1SI [
(const_int 0 [0])
])) "cse.c":11:9 1363 {*movv1si_internal}
 (expr_list:REG_UNUSED (reg:SI 97 [ _10 ])
(nil)))

ends up generating two equivalences. the first one is that

reg:SI 97 is 0.

The second one is that 0 can be extracted from the V1SI, so subreg (subreg:V1SI
(reg:SI 97) 0) 0 == 0.
This nested subreg gets folded away to just reg:SI 97 and we re-insert the same
equivalence and end up with:

(rr) p dump_class (class1)
Equivalence chain for (reg:SI 105 [ iD.2893 ]):
(reg:SI 105 [ iD.2893 ])
$3 = void

(rr) p dump_class (class2)
Equivalence chain for (const_int 0 [0]):
(const_int 0 [0])
(reg:SI 97 [ _10 ])
(reg:SI 97 [ _10 ])
$4 = void

merge_equiv_classes then crashes because after it merges the first (reg:SI 97 [
_10 ]) the reference to it in class2 is invalid.

So I believe the fix should be that the hash table insertion code should not
insert a value if it already exists
in the table.

Testing a patch.

[Bug tree-optimization/103417] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-5489

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

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

--- Comment #5 from Tamar Christina  ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 51870 [details]
> gcc12-pr103417.patch
> 
> Untested fix.  Handling GE in that simplification is clearly bogus, we
> should just fold it to true elsewhere, not bother with it (it doesn't handle
> LT either,
> which should also fold to false elsewhere).

Indeed, that one is wrong..

> Handling LE and GT there isn't wrong, but makes no sense.  Elsewhere we
> canonicalize x > 0U into x != 0U and x <= 0U into x == 0U and for signed it
> was handling only EQ and NE already before.

Well, the intention is to simplify the bitmask. Most vector ISAs can create the
simple bitmask much easier than the complex one. i.e. 0xFF00 is much harder
to create than 0xFF. for scalar yes it doesn't matter much.

but e.g.

 for (int i = 0; i < (n & -16); i++)
   x[i] = (x[i]&(~255)) <= 0U;

generates worse code when the mask 0xFF00 is to be used.  The patch is
mainly addressing vector code but we added scalar for uniformity.

So I would like LE and GT to stay, at the very least for vector where it makes
a difference.  It's not something we can fix in the backend because we can't
differentiate between signed and unsigned.

[Bug c++/103401] [11/12 Regression] gcc accepts decltype(auto(0)) as the parameter of the function

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

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

--- Comment #4 from Marek Polacek  ---
I think the patch might be just:

--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -7508,6 +7508,8 @@ cp_parser_postfix_expression (cp_parser *parser, bool
address_p, bool cast_p,
   looking at a functional cast.  We could also be looking at
   an id-expression.  So, we try the functional cast, and if
   that doesn't work we fall back to the primary-expression.  */
+   auto cleanup = make_temp_override
+ (parser->auto_is_implicit_function_template_parm_p, false);
cp_parser_parse_tentatively (parser);
/* Look for the simple-type-specifier.  */
 ++parser->prevent_constrained_type_specifiers;


Until C++23 auto(x), we didn't have to think about auto in a
parameter-decl-clause all that much I suspect.

[Bug fortran/103414] [PDT] ICE in gfc_free_actual_arglist, at fortran/expr.c:547

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

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

--- Comment #4 from kargl at gcc dot gnu.org ---
This fixes/catches the type mismatch in the issue raised in comment #1.

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 705d2326a29..0a864da015b 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -1231,9 +1237,17 @@ get_pdt_constructor (gfc_expr *expr, gfc_constructor
**constr,
  if (!t)
return t;
}
- else if ((comp->attr.pdt_kind || comp->attr.pdt_len)
+  else if ((comp->attr.pdt_kind || comp->attr.pdt_len)
   && derived->attr.pdt_template)
{
+ if (comp->ts.type != cons->expr->ts.type)
+   {
+ gfc_error ("Type mismatch for a type parameter and an entity "
+"at %L in the structure constructor",
+>expr->where);
+ return false;
+   }
+
  t = get_pdt_spec_expr (comp, cons->expr);
  if (!t)
return t;

[Bug target/103393] [12 Regression] Generating 256bit register usage with -mprefer-avx128 -mprefer-vector-width=128

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #5)
> (In reply to Richard Biener from comment #3)
> > (In reply to H.J. Lu from comment #2)
> > > (In reply to Richard Biener from comment #1)
> > > > It isn't the vectorizer but memmove inline expansion.  I'm not sure it's
> > > > really a bug, but there isn't a way to disable %ymm use besides 
> > > > disabling
> > > > AVX entirely.
> > > > HJ?
> > > 
> > > YMM move is generated by loop distribution which doesn't check
> > > TARGET_PREFER_AVX128.
> > 
> > I think it's generated by gimple_fold_builtin_memory_op which since Richards
> > changes accepts bigger now, up to MOVE_MAX * MOVE_RATIO and that ends up
> > picking an integer mode via
> > 
> >   scalar_int_mode mode;
> >   if (int_mode_for_size (ilen * 8, 0).exists ()
> >   && GET_MODE_SIZE (mode) * BITS_PER_UNIT == ilen * 8
> >   && have_insn_for (SET, mode)
> >   /* If the destination pointer is not aligned we must be
> > able
> >  to emit an unaligned store.  */
> >   && (dest_align >= GET_MODE_ALIGNMENT (mode)
> >   || !targetm.slow_unaligned_access (mode, dest_align)
> >   || (optab_handler (movmisalign_optab, mode)
> >   != CODE_FOR_nothing)))
> > 
> > not sure if there's another way to validate things.
> 
> For one single set operation, shouldn't the total size be less than MOVE_MAX
> instead of MOVE_MAX * MOVE_RATIO?

r12-3482 change MOVE_MAX to MOVE_MAX * MOVE_RATIO

[Bug tree-optimization/103409] 18% WRF compile-time regression with -O2 -flto between g:264f061997c0a534 and g:3e09331f6aeaf595

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

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

--- Comment #1 from Andrew Pinski  ---
The two main changes during that time period was jump threading and modref.
modref seems might be more likely with wrf being fortran code and even using
nested functions and such.

[Bug target/103393] [12 Regression] Generating 256bit register usage with -mprefer-avx128 -mprefer-vector-width=128

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #5 from Hongtao.liu  ---
(In reply to Richard Biener from comment #3)
> (In reply to H.J. Lu from comment #2)
> > (In reply to Richard Biener from comment #1)
> > > It isn't the vectorizer but memmove inline expansion.  I'm not sure it's
> > > really a bug, but there isn't a way to disable %ymm use besides disabling
> > > AVX entirely.
> > > HJ?
> > 
> > YMM move is generated by loop distribution which doesn't check
> > TARGET_PREFER_AVX128.
> 
> I think it's generated by gimple_fold_builtin_memory_op which since Richards
> changes accepts bigger now, up to MOVE_MAX * MOVE_RATIO and that ends up
> picking an integer mode via
> 
>   scalar_int_mode mode;
>   if (int_mode_for_size (ilen * 8, 0).exists ()
>   && GET_MODE_SIZE (mode) * BITS_PER_UNIT == ilen * 8
>   && have_insn_for (SET, mode)
>   /* If the destination pointer is not aligned we must be
> able
>  to emit an unaligned store.  */
>   && (dest_align >= GET_MODE_ALIGNMENT (mode)
>   || !targetm.slow_unaligned_access (mode, dest_align)
>   || (optab_handler (movmisalign_optab, mode)
>   != CODE_FOR_nothing)))
> 
> not sure if there's another way to validate things.

For one single set operation, shouldn't the total size be less than MOVE_MAX
instead of MOVE_MAX * MOVE_RATIO?


  /* If we can perform the copy efficiently with first doing all loads and
 then all stores inline it that way.  Currently efficiently means that
 we can load all the memory with a single set operation and that the
 total size is less than MOVE_MAX * MOVE_RATIO.  */
  src_align = get_pointer_alignment (src);
  dest_align = get_pointer_alignment (dest);
  if (tree_fits_uhwi_p (len)
  && (compare_tree_int
  (len, (MOVE_MAX
 * MOVE_RATIO (optimize_function_for_size_p (cfun
  <= 0)

[Bug fortran/103414] [PDT] ICE in gfc_free_actual_arglist, at fortran/expr.c:547

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

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

--- Comment #3 from kargl at gcc dot gnu.org ---
The patch in comment #2 does not address the issue in comment #1.
The patch only address an invalid BOZ in a structure constructor.
The issue in comment #1 is technical unrelated.

[Bug fortran/103414] [PDT] ICE in gfc_free_actual_arglist, at fortran/expr.c:547

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
This one took a bit to find where to check for a BOZ.

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 705d2326a29..7add59f50bd 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -1268,6 +1274,17 @@ resolve_structure_cons (gfc_expr *expr, int init)
   else
 resolve_fl_struct (expr->ts.u.derived);

+  /* Walk the constructor looking for an invalid BOZ.  */
+  cons = gfc_constructor_first (expr->value.constructor);
+  for (; cons; cons = gfc_constructor_next (cons))
+   if (cons->expr && cons->expr->ts.type == BT_BOZ)
+ {
+   gfc_error ("boz-literal-constant at %L cannot appear as an "
+   "entity in a structure constructor",
+   >expr->where);
+   return false;
+ }
+
   /* If this is a Parameterized Derived Type template, find the
 instance corresponding to the PDT kind parameters.  */
   if (expr->ts.u.derived->attr.pdt_template)

[Bug tree-optimization/103409] 18% WRF compile-time regression with -O2 -flto between g:1ae8edf5f73ca5c3 and g:1ae8edf5f73ca5c3

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Keywords||missed-optimization

[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
.

[Bug middle-end/103386] -floop-nest-optimize -floop-interchange -fgraphite-identity miscompiles gcc

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|1   |0
Summary|stage1 with PGO produces|-floop-nest-optimize
   |bad offsets in rtl-reload   |-floop-interchange
   |on aarch64  |-fgraphite-identity
   ||miscompiles gcc
 Status|WAITING |UNCONFIRMED

[Bug c++/103401] [11/12 Regression] gcc accepts decltype(auto(0)) as the parameter of the function

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

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

--- Comment #3 from Marek Polacek  ---
This is trickier than it seemed.

void f(decltype(auto(0))) { }
is actually valid in C++23 (probably) since auto(x) is supported.  So I think
it's essentially like
void f(int) { }

The r11-1913 change is OK: we need to make sure that we see '(auto)' after
decltype to go ahead with 'decltype(auto)'.

I think we shouldn't be calling synthesize_implicit_template_parm for auto(x)
in a parameter-list.

More tests:

void f1 (decltype(auto(0)));
void f2 (decltype(auto{0}));
void f3 (int = auto(42));
void f4 (int = auto{42});
void f5 (decltype(auto(0)) = auto(42));
// Careful about just checking ( after auto:
void f6 (auto (x));

[Bug c++/100687] [modules, concepts] imported concept gives different result

[johelegp at gmail dot com via Gcc-bugs]

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

Johel Ernesto Guerrero Peña  changed:

   What|Removed |Added

 CC||johelegp at gmail dot com

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
I happened upon the same bug when changing a trait to be specialized directly
through the variable template rather than a class template. In my case, I
asserted through the variable template, so I can confirm that it's solely a bug
with modules and not with concepts.

See https://godbolt.org/z/jPT9T6ovP.

mod.cpp:
```C++
export module mod;

export
template< class T >
inline constexpr bool probe = false;
//
template< class R, class C >
inline constexpr bool probe = true;

struct S { int f( ); };
using mf_t = decltype( ::f );

static_assert( probe< mf_t > );
```

test.cpp:
```C++
import mod;

struct S { int f( ); };
using mf_t = decltype( ::f );

static_assert( probe< mf_t > );
```

Output:
```
test.cpp:6:16: error: static assertion failed
6 | static_assert( probe< mf_t > );
  |^
```

[Bug preprocessor/103415] [12 Regression] ICE in cpp_interpret_string_1, at libcpp/charset.c:1739

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-11-25
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Confirmed.


(In reply to G. Steinmetz from comment #0)
> Started between 20210808 and 20210822  :

Then it is when __VA_OPT__ support was added in r12-2940-gd56599979211266b.

[Bug testsuite/103244] [12 regression] c-c++-common/goacc/firstprivate-mappings-1.c fails in certain configurations since g:b7e20480630e3eeb9eed8b3941da3b3f0c22c969

[fche2 at elastic dot org via Gcc-bugs]

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

--- Comment #4 from test test  ---
(test, ignore)

[Bug fortran/103418] random_number() does not accept pointer, intent(in) array argument

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

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

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 anlauf from comment #2)
> The nearly obvious fix:
> 
> diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
> index 837eb0912c0..3859e18c6c3 100644
> --- a/gcc/fortran/check.c
> +++ b/gcc/fortran/check.c
> @@ -1031,7 +1031,7 @@ variable_check (gfc_expr *e, int n, bool allow_proc)
> break;
> }
>  
> -  if (!ref)
> +  if (!ref && !pointer)
> {
>   gfc_error ("%qs argument of %qs intrinsic at %L cannot be "
>  "INTENT(IN)", gfc_current_intrinsic_arg[n]->name,
> 
> regresses for gfortran.dg/move_alloc_8.f90, thus needs additional
> investigation.

Did you try the patch posted in Fortran Discourse?

[Bug target/102239] powerpc suboptimal boolean test of contiguous bits

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

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

--- Comment #3 from Segher Boessenkool  ---
(In reply to luoxhu from comment #2)
> (In reply to Segher Boessenkool from comment #1)
> > Confirmed.
> > 
> > So the relevant insn
> > 
> > (parallel [(set (reg:CC 123)
> > (compare:CC (and:DI (reg:DI 124)
> > (const_int 25769803776 [0x6]))
> > (const_int 0 [0])))
> >(clobber (scratch:DI))])
> > 
> > is matched by *and3_2insn but not by any pattern that ends up as just
> > one insn.  Not *and3_mask_dot, because that doesn't do a shift first,
> > is just an AND and there are no machine insns to do that; but there is no
> > pattern for what we can do.
> > 
> > *rotl3_mask_dot cannot do this either; the base and the dot2 of that
> > cannot be done, they return a shifted result, but that doesn't matter for
> > comparing it to 0.  So we should add a specialised version.
> 
> Seems different with what you describe, in combine, it was combined to
> anddi3_2insn_dot:
> 
> (insn 9 8 10 2 (parallel [
> (set (reg:CC 122)
> (compare:CC (and:DI (reg:DI 123)
> (const_int 25769803776 [0x6]))
> (const_int 0 [0])))
> (clobber (scratch:DI))
> ]) "pr102239.c":3:6 210 {*anddi3_2insn_dot}
>  (expr_list:REG_DEAD (reg:DI 123)
> (nil)))
> (jump_insn 10 9 11 2 (set (pc)
> (if_then_else (eq (reg:CC 122)
> (const_int 0 [0]))
> (label_ref 15)
> (pc))) "pr102239.c":3:6 868 {*cbranch}
>  (expr_list:REG_DEAD (reg:CC 122)
> (int_list:REG_BR_PROB 536870916 (nil)))
> 
> 
> 
> Then in pr102239.c.302r.split2, it is split by "*and3_2insn_dot" to
> rotldi3_mask+lshrdi3_dot:
> 
> Splitting with gen_split_80 (rs6000.md:3721)
> 
> (insn 32 8 33 2 (set (reg:DI 3 3 [124])
> (and:DI (ashift:DI (reg:DI 3 3 [123])
> (const_int 29 [0x1d]))
> (const_int -4611686018427387904 [0xc000])))
> "pr102239.c":3:6 236 {*rotldi3_mask}
>  (nil))
> (insn 33 32 10 2 (parallel [
> (set (reg:CC 100 0 [122])
> (compare:CC (lshiftrt:DI (reg:DI 3 3 [124])
> (const_int 29 [0x1d]))
> (const_int 0 [0])))
> (clobber (reg:DI 3 3 [124]))
> ]) "pr102239.c":3:6 281 {*lshrdi3_dot}
>  (nil))
> 
> 
> Why this difference happens?

What difference?  It is split by the same pattern that matched it, and that
is the 2insn pattern.  I'm not sure what problem you see?

> 0x6 is not a valid mask for anddi3_2insn_dot:

It should be though!

>  "(mode == Pmode || UINTVAL (operands[2]) <= 0x7fff)
>&& rs6000_is_valid_2insn_and (operands[2], mode)
>&& !(rs6000_is_valid_and_mask (operands[2], mode)
>   || logical_const_operand (operands[2], mode))"
> 
> 
> (gdb) p UINTVAL (operands[2]) <= 0x7fff
> $84 = false

But we have Pmode here so all is fine.

> (gdb) p rs6000_is_valid_2insn_and (operands[2], E_DImode)
> $85 = true
> (gdb) p logical_const_operand (operands[2], E_DImode)
> $86 = false
> (gdb) p rs6000_is_valid_and_mask (operands[2], E_DImode)
> $87 = false
> (gdb) p Pmode
> $88 = DImode

Yes, and mode is DImode as well.

My point is that we do not have any pattern that can recognise this that
will end up as just one machine insn.  anddi3_2insn_dot split to two
machine insns, and it should: its name indicates we want that!

[Bug fortran/103413] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size

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

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
> index 2bf21434a42..971c2fa1dd6 100644
> --- a/gcc/fortran/match.c
> +++ b/gcc/fortran/match.c
> @@ -4447,6 +4447,15 @@ alloc_opt_list:
> goto cleanup;
>   }
>  
> +   /* A BOZ cannot be a source expression.  */
> +   if (ts.type != BT_BOZ)

Got the logic backwards here!  Should be ts.type == BT_BOZ.

> + {
> +   gfc_error ("boz-literal-constant cannot be a source expression "
> +  "at %L", >where);
> +   goto cleanup;
> + }
> +
> +
> /* The next 2 conditionals check C631.  */
> if (ts.type != BT_UNKNOWN)
>   {
> @@ -4484,6 +4493,14 @@ alloc_opt_list:
> goto cleanup;
>   }
>  
> +   /* A BOZ cannot be a source expression.  */
> +   if (ts.type != BT_BOZ)

Ditto.

> + {
> +   gfc_error ("boz-literal-constant cannot be a mode expression "
> +  "at %L", >where);
> +   goto cleanup;
> + }
> +
> /* Check F08:C637.  */
> if (ts.type != BT_UNKNOWN)
>   {

[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable

[tuliom at ascii dot art.br via Gcc-bugs]

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

Tulio Magno Quites Machado Filho  changed:

   What|Removed |Added

 CC||tuliom at ascii dot art.br

--- Comment #2 from Tulio Magno Quites Machado Filho  ---
(In reply to Michael Meissner from comment #1)
> I tried it on a current trunk compiler (from November 23, 2021) using glibc
> 2.34 (IBM AT 14.0), and it does fail.  It works fine if I build a toolchain
> where the default long double is IEEE 128-bit.

So, it sounds like this is happening because libstdc++ is not distributing cout
implementations for all the supported long double types, but just for the
default type as explained in bug #100912.

[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #11 from joseph at codesourcery dot com  ---
The sign of a NaN result is never specified in C except for fabs, 
copysign, negation, unary + (and assignment to the same format in the case 
where that's copy rather than convertFormat).

The result should of course be NaN (of any sign), not 0.

The reason soft-fp (and thus sfp-machine.h) has special support for 
choosing a NaN result based on NaN operands is because soft-fp is also 
used in the Linux kernel for emulating floating-point instructions, and in 
that context the aim is to follow the semantics of those instructions, 
which specifies things left unspecified in IEEE 754 and its C bindings.  
That isn't relevant at the level of C code or libgcc functions.

[Bug libstdc++/103382] condition_variable::wait() is not cancellable because it is marked noexcept

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

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

--- Comment #4 from Jonathan Wakely  ---
Yes, it's just a lot of work to implement correctly, and non-zero overhead to
change the cancellation state.

[Bug fortran/103418] random_number() does not accept pointer, intent(in) array argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
The nearly obvious fix:

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 837eb0912c0..3859e18c6c3 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1031,7 +1031,7 @@ variable_check (gfc_expr *e, int n, bool allow_proc)
break;
}

-  if (!ref)
+  if (!ref && !pointer)
{
  gfc_error ("%qs argument of %qs intrinsic at %L cannot be "
 "INTENT(IN)", gfc_current_intrinsic_arg[n]->name,

regresses for gfortran.dg/move_alloc_8.f90, thus needs additional
investigation.

[Bug fortran/103414] [PDT] ICE in gfc_free_actual_arglist, at fortran/expr.c:547

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

Summary|[PDT] [10/11/12 Regression] |[PDT] ICE in
   |ICE in  |gfc_free_actual_arglist, at
   |gfc_free_actual_arglist, at |fortran/expr.c:547
   |fortran/expr.c:547  |

--- Comment #1 from G. Steinmetz  ---

Right, primarily PDT specific.
Modified cases with deleted "z" should be treated first.
That changed with the PDT groundwork in r8 before 20180525.

$ cat z3.f90
program p
   type t(n)
  integer, kind :: n
  character(n) :: c = ''
   end type
   type(t(3)) :: x = t('1')
end

[Bug tree-optimization/103417] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-5489

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 51870
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51870=edit
gcc12-pr103417.patch

Untested fix.  Handling GE in that simplification is clearly bogus, we should
just fold it to true elsewhere, not bother with it (it doesn't handle LT
either,
which should also fold to false elsewhere).
Handling LE and GT there isn't wrong, but makes no sense.  Elsewhere we
canonicalize x > 0U into x != 0U and x <= 0U into x == 0U and for signed it
was handling only EQ and NE already before.

[Bug fortran/103418] random_number() does not accept pointer, intent(in) array argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-24

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

As a side note: Intel does not like it, either.  But NAG and Nvidia do.

[Bug fortran/103392] [9/10/11 Regression] ICE in simplify_bound, at fortran/simplify.c:4273

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

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

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

https://gcc.gnu.org/g:56b3036c531929e0dae1103b9f5d20c82643415f

commit r11-9308-g56b3036c531929e0dae1103b9f5d20c82643415f
Author: Harald Anlauf 
Date:   Tue Nov 23 21:39:36 2021 +0100

Fortran: do not attempt simplification of [LU]BOUND for pointer/allocatable

gcc/fortran/ChangeLog:

PR fortran/103392
* simplify.c (simplify_bound): Do not try to simplify
LBOUND/UBOUND for arrays with POINTER or ALLOCATABLE attribute.

gcc/testsuite/ChangeLog:

PR fortran/103392
* gfortran.dg/bound_simplification_7.f90: New test.

(cherry picked from commit 16e95050f71e9fa408e9bd8ccd415b0e7adc66e5)

[Bug other/102718] gtype-desc.c function redefinition error for gt_ggc_xxx (int_hash&)

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=101292|
   Last reconfirmed|2021-10-13 00:00:00 |2021-11-24
 CC||tschwinge at gcc dot gnu.org

--- Comment #2 from Thomas Schwinge  ---
ACK.  See also my "'gengtype' generates duplicate functions" note in
/commit
r12-5050-g088199e5d0fc0d54f48af0783a2630a773bbb387 "Generalize
'gcc/input.h:struct location_hash'" -- "Thus, use a plain ol' '#define'".  ;-\

[Bug fortran/103411] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-11-24
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2021-November/057057.html

[Bug tree-optimization/103417] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-5489

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

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

--- Comment #3 from Jakub Jelinek  ---
generic_simplify_GE_EXPR is called with
BIT_FIELD_REF  & 4294967040U
and
0U
arguments, and transforms that into
BIT_FIELD_REF  <= 255.  That is wrong,
(BIT_FIELD_REF  & 4294967040U) >= 0U
is always true (anything >= 0U is true).

[Bug tree-optimization/103417] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-5489

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2021-11-24
Summary|[12 Regression] wrong code  |[12 Regression] wrong code
   |at -O1 and above on |at -O1 and above on
   |x86_64-linux-gnu|x86_64-linux-gnu since
   ||r12-5489
   Priority|P3  |P1

--- Comment #2 from Jakub Jelinek  ---
Started with r12-5489-g0888d6bbe97e10de0e624f4ab46acc276e5ee1d7

[Bug tree-optimization/103417] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

Version|unknown |12.0
Summary|wrong code at -O1 and above |[12 Regression] wrong code
   |on x86_64-linux-gnu |at -O1 and above on
   ||x86_64-linux-gnu
   Target Milestone|--- |12.0

[Bug tree-optimization/103417] wrong code at -O1 and above on x86_64-linux-gnu

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

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

--- Comment #1 from Andrew Pinski  ---
It worked at r12-5485-ge1d4359264585

[Bug fortran/103418] New: random_number() does not accept pointer, intent(in) array argument

[baradi09 at gmail dot com via Gcc-bugs]

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

Bug ID: 103418
   Summary: random_number() does not accept pointer, intent(in)
array argument
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

The following module is, at least according to the discussion on
fortran-lang.discourse
(https://fortran-lang.discourse.group/t/meaning-of-the-intent-for-pointer-dummy-arguments/2328/11)
is standard complying, but gfortran stops with an error message when compiling
it. Someone in that topic also posted a gcc-patch, which may fix the issue.

Code:

module m
contains
   subroutine s1(a)
  real, pointer, intent(in) :: a
  call s2(a )   !<-- Ok with gfortran
  call random_number(a) !<-- but not this
   end subroutine
   subroutine s2(x)
  real, intent(out) :: x
  call random_number(x)
   end subroutine
end module

Error message:

bug3.f90:6:25:

6 |   call random_number(a) !<-- but not this
  | 1
Error: ‘harvest’ argument of ‘random_number’ intrinsic at (1) cannot be
INTENT(IN)

[Bug fortran/103411] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 51869
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51869=edit
Untested patch

The check is already there.  It just did not trigger for the testcase...

[Bug tree-optimization/103417] New: wrong code at -O1 and above on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 103417
   Summary: wrong code at -O1 and above on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a recent regression.

[557] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211124 (experimental) [master r12-5505-g5deacf6058d] (GCC) 
[558] % 
[558] % gcctk -O0 small.c; ./a.out
[559] % 
[559] % gcctk -O1 small.c
[560] % ./a.out
Aborted
[561] % 
[561] % cat small.c
struct {
  int a : 8;
  int b : 24;
} c = {0, 1};
int main() {
  if (c.b && !c.b)
__builtin_abort();
  return 0;
}

[Bug target/103393] [12 Regression] Generating 256bit register usage with -mprefer-avx128 -mprefer-vector-width=128

[jschoen4 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from John S  ---
I can Confirm from my side that it does appear to be the memmove inline
expansion and not the auto vectorizer.  It also occurs with
builtin_memset/builtin_memcpy as well.

For some context, this is an issue would prevent the usage of gcc in my
production environment.  It will certainly impact other use cases outside of my
own as well.  For example, it becomes impossible to use "-mno-vzeroupper -mavx
-mpreferred-vector-width=128" and use _mm256_xxx + _mm256_zeroupper()
intrinsics to properly manage the ymm state (clear or not) since the compiler
is now able to insert ymm's almost anywhere via the memmove inlining.

Up until now the prefer-width has always behaved as in a way that all auto
generated vector uses will not exceed the preferred width.  Only explicit use
of the _mm256/_mm512_ .. intrinsics or the "vector types" i.e. `__m256 var;
__m512 var;` would result in wider register usage.

I do believe Clang/icc behave this way as well and there are dependencies on
this behavior.  The same also applies w/ avx-512 enabled with ZMM usage +
prefer=128/256 where the downclocking issues can be even more pronounced.

[Bug fortran/87851] [9/10/11/12 Regression] Wrong return type for len_trim

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #18 from anlauf at gcc dot gnu.org ---
The scalarization issue from PR87711 mentioned in comment#0 should be fixed
on mainline and on 11-branch.

As explained by Janne in comment#5, typecasts should get inserted properly.

And when looking at the dump-tree of the committed testcase and playing
with -m32/-m64 and -fdefault-integer-8, I did not see anything suspicious.

@Thomas: do you see anything left to do?

[Bug fortran/87711] ICE in gfc_trans_transfer, at fortran/trans-io.c:2676

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

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

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

https://gcc.gnu.org/g:3e6b9910e8e23d690fa1026b2879d37745ddd740

commit r11-9307-g3e6b9910e8e23d690fa1026b2879d37745ddd740
Author: Harald Anlauf 
Date:   Tue Nov 23 17:51:38 2021 +0100

Fortran: fix scalarization for intrinsic LEN_TRIM with present KIND
argument

gcc/fortran/ChangeLog:

PR fortran/87711
PR fortran/87851
* trans-array.c (arg_evaluated_for_scalarization): Add LEN_TRIM to
list of intrinsics for which an optional KIND argument needs to be
removed before scalarization.

gcc/testsuite/ChangeLog:

PR fortran/87711
PR fortran/87851
* gfortran.dg/len_trim.f90: New test.

(cherry picked from commit 721d8b9e26bf8205c1f2125c2626919a408cdbe4)

[Bug fortran/87851] [9/10/11/12 Regression] Wrong return type for len_trim

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

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

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

https://gcc.gnu.org/g:3e6b9910e8e23d690fa1026b2879d37745ddd740

commit r11-9307-g3e6b9910e8e23d690fa1026b2879d37745ddd740
Author: Harald Anlauf 
Date:   Tue Nov 23 17:51:38 2021 +0100

Fortran: fix scalarization for intrinsic LEN_TRIM with present KIND
argument

gcc/fortran/ChangeLog:

PR fortran/87711
PR fortran/87851
* trans-array.c (arg_evaluated_for_scalarization): Add LEN_TRIM to
list of intrinsics for which an optional KIND argument needs to be
removed before scalarization.

gcc/testsuite/ChangeLog:

PR fortran/87711
PR fortran/87851
* gfortran.dg/len_trim.f90: New test.

(cherry picked from commit 721d8b9e26bf8205c1f2125c2626919a408cdbe4)

[Bug c/92479] missing warnings for unreachable codes with break (i.e. revive the subset of -Wunreachable-code that fits under clang's -Wunreachable-code-break)

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

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

Eric Gallager  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW
 CC||rguenth at gcc dot gnu.org

--- Comment #8 from Eric Gallager  ---
Richi is working on a revival of -Wunreachable-code, so I'm going to un-suspend
this, in case he wants to do this part, too.

[Bug c++/87403] [Meta-bug] Issues that suggest a new warning

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

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

Bug 98750 Summary: does not detect dead code [-Wunreachable-code-break]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98750

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c/92479] missing warnings for unreachable codes with break (i.e. revive the subset of -Wunreachable-code that fits under clang's -Wunreachable-code-break)

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||tiagomacarios at gmail dot com

--- Comment #7 from Eric Gallager  ---
*** Bug 98750 has been marked as a duplicate of this bug. ***

[Bug c++/98750] does not detect dead code [-Wunreachable-code-break]

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

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Eric Gallager  ---
actually this is a dup of bug 92479

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

[Bug middle-end/103416] [12 Regression][OpenMP] Bogus firstprivate(n) map(to:n [len: 4][implicit])

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

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

--- Comment #1 from Chung-Lin Tang  ---
Can you see if adding this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583279.html

fixes this problem? If so, then it should be another occurrence of PR90030

[Bug target/103395] [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier

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

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

--- Comment #12 from Jakub Jelinek  ---
Note, sys/sdt.h is using the "nor" constraints for 11 years already.

[Bug target/103395] [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier

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

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

--- Comment #11 from Jakub Jelinek  ---
Inline asm that only works with memory but in constraints says it accepts both
immediate constant and memory is IMNSHO just broken, it is just fine if the
compiler makes a different choice.
If "nor" with constant input on arm has meant actually just "or", then sure,
systemtap could be changed and after a couple of years it will propagate to all
stap copies used in the wild, but it is quite severe misoptimization of one of
the most common cases.  The systemtap macros don't really know what argument
will be passed to them, whether a constant, something that lives in memory,
something that lives in a register and ideally wants as few actual instructions
before those macros as possible to arrange the arguments so that debugger can
inspect them.

[Bug middle-end/103416] New: [12 Regression][OpenMP] Bogus firstprivate(n) map(to:n [len: 4][implicit])

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

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

Bug ID: 103416
   Summary: [12 Regression][OpenMP] Bogus firstprivate(n) map(to:n
[len: 4][implicit])
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: openmp, wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: cltang at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

Side remark: PR80330 (suggested as possible duplicate) looks a bit similar from
the subject line.

Caused by commit r12-5194-gb7e20480630e3eeb9eed8b3941da3b3f0c22c969
Author: Chung-Lin Tang 
Date:   Fri Nov 12 20:29:00 2021 +0800

openmp: Relax handling of implicit map vs. existing device mappings

Works when undoing the omp-low.c + gimplify.c bits.

I am not 100% sure whether there is some other issue - and this patch just
exposes it or whether it is the cause. However, the dump looks in any case
wrong/odd.

For some reasons, replacing '8' (double-precision complex) by '4'
(single-precision complex) makes it pass. The ptx assembler looks fine at a
glance, but I do observe that there are other DCmode related issues: PR102429
(nvptx, SIMT_XCHG_BFLY)

 * * *

In any case, running
https://github.com/TApplencourt/OvO/blob/master/test_src/fortran/hierarchical_parallelism/memcopy-double_complex/target_parallel_do.F90
or the program below fails with nvptx offloading with:

  libgomp: cuCtxSynchronize error: misaligned address
  libgomp: cuMemFree_v2 error: misaligned address
  libgomp: device finalization failed

PROGRAM target_parallel_do
  implicit none
  INTEGER :: i0, N
  COMPLEX(8) :: scalar
  COMPLEX(8), ALLOCATABLE :: src(:)
  N = 1
  ALLOCATE(src(1), stat=i0)
  !$OMP TARGET PARALLEL DO map(to: src) map(from: scalar) private(i0)
  DO i0 = 1, N
scalar%re = src(i0)%re
  END DO
END PROGRAM target_parallel_do

 * * *

When playing around using not the combined directive but

  !$OMP TARGET map(to: src) map(from: scalar)
  !$OMP PARALLEL DO private(i0)
  DO i0 = 1, N
scalar%re = src(i0)%re
  END DO

it started to work. Looking at the dump of the failing version:

  D.4246 = n;
#pragma omp target map(to:D.4246 [len: 4][implicit]) firstprivate(n) ...
  ...
  #pragma omp parallel firstprivate(D.4246) firstprivate(n) ...


while the second, working version has:

#pragma omp target firstprivate(n)
...
D.4246 = n;

  #pragma omp parallel firstprivate(D.4246)

 * * *

In any case, it is very odd to have both a 'map(to:' and a 'firstprivate' for
the same variable. Especially, if it causes wrong results/a crash.

[Bug target/103395] [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier

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

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

--- Comment #10 from Richard Earnshaw  ---
It's been this way now for over 20 years.  A single instruction cannot take a
constant and a memory for the same operand, so this has been used in the
backend to trigger the minipool generation: a constant in an operand that takes
a memory triggers a minipool spill to be pushed.

If we changed this now we risk breaking existing inline asms that exploit this
feature (good or bad) and expect a constant to be pushed into a minipool entry.

[Bug fortran/103413] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2021-11-24
 Status|UNCONFIRMED |NEW
   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 2bf21434a42..971c2fa1dd6 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -4447,6 +4447,15 @@ alloc_opt_list:
  goto cleanup;
}

+ /* A BOZ cannot be a source expression.  */
+ if (ts.type != BT_BOZ)
+   {
+ gfc_error ("boz-literal-constant cannot be a source expression "
+"at %L", >where);
+ goto cleanup;
+   }
+
+
  /* The next 2 conditionals check C631.  */
  if (ts.type != BT_UNKNOWN)
{
@@ -4484,6 +4493,14 @@ alloc_opt_list:
  goto cleanup;
}

+ /* A BOZ cannot be a source expression.  */
+ if (ts.type != BT_BOZ)
+   {
+ gfc_error ("boz-literal-constant cannot be a mode expression "
+"at %L", >where);
+ goto cleanup;
+   }
+
  /* Check F08:C637.  */
  if (ts.type != BT_UNKNOWN)
{

[Bug fortran/103412] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Priority|P3  |P4
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-24
 Status|UNCONFIRMED |NEW

--- Comment #1 from kargl at gcc dot gnu.org ---
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index d675f2c3aef..596dbb3715c 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -7588,7 +7592,7 @@ gfc_simplify_sizeof (gfc_expr *x)
   mpz_t array_size;
   size_t res_size;

-  if (x->ts.type == BT_CLASS || x->ts.deferred)
+  if (x->ts.type == BT_BOZ || x->ts.type == BT_CLASS || x->ts.deferred)
 return NULL;

   if (x->ts.type == BT_CHARACTER

[Bug preprocessor/103415] [12 Regression] ICE in cpp_interpret_string_1, at libcpp/charset.c:1739

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c/103415] [12 Regression] ICE in cpp_interpret_string_1, at libcpp/charset.c:1739

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

Probably related :


$ cat z2.c
#define n(x...) #__VA_OPT__(x##__VA_ARGS__##c)
const char *c n(1)


$ cat z3.c
#define n(x...) = #__VA_OPT__(x##__VA_ARGS__##c)
const char *c n(1);


$ gcc-12-20211121 -c z2.c
z2.c:1:18: warning: __VA_OPT__ can only appear in the expansion of a C++20
variadic macro
1 | #define n(x...) #__VA_OPT__(x##__VA_ARGS__##c)
  |  ^
z2.c:1:32: warning: __VA_ARGS__ can only appear in the expansion of a C99
variadic macro
1 | #define n(x...) #__VA_OPT__(x##__VA_ARGS__##c)
  |^
z2.c:2:1: internal compiler error: Segmentation fault
2 | const char *c n(1)
  | ^
0xcb463f crash_signal
../../gcc/toplev.c:322
0x18d0cca new_string_token
../../libcpp/macro.c:472
0x18d0cca stringify_arg
../../libcpp/macro.c:941
0x18d32e3 replace_args
../../libcpp/macro.c:2068
0x18d32e3 enter_macro_context
../../libcpp/macro.c:1496
0x18d3750 cpp_get_token_1
../../libcpp/macro.c:2986
0x7ff27d c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc/c-family/c-lex.c:483
0x78743f c_lex_one_token
../../gcc/c/c-parser.c:279
0x788414 c_parser_peek_nth_token(c_parser*, unsigned int)
../../gcc/c/c-parser.c:517
0x7889a0 c_parser_nth_token_starts_std_attributes
../../gcc/c/c-parser.c:5092
0x79524b c_parser_direct_declarator
../../gcc/c/c-parser.c:3951
0x79524b c_parser_declarator(c_parser*, bool, c_dtr_syn, bool*)
../../gcc/c/c-parser.c:3894
0x795033 c_parser_declarator(c_parser*, bool, c_dtr_syn, bool*)
../../gcc/c/c-parser.c:3886
0x7ae573 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2154
0x7b70cf c_parser_external_declaration
../../gcc/c/c-parser.c:1780
0x7b79fb c_parser_translation_unit
../../gcc/c/c-parser.c:1653
0x7b79fb c_parse_file()
../../gcc/c/c-parser.c:23280
0x808eb2 c_common_parse_file()
../../gcc/c-family/c-opts.c:1240

[Bug c/103415] New: [12 Regression] ICE in cpp_interpret_string_1, at libcpp/charset.c:1739

[gscfq--- via Gcc-bugs]

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

Bug ID: 103415
   Summary: [12 Regression] ICE in cpp_interpret_string_1, at
libcpp/charset.c:1739
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210808 and 20210822  :


$ cat z1.c
#define n(x...) = #__VA_OPT__(x##1)
const char *c n(1, 2);


$ gcc-12-20211121 -c z1.c
z1.c:1:20: warning: __VA_OPT__ can only appear in the expansion of a C++20
variadic macro
1 | #define n(x...) = #__VA_OPT__(x##1)
  |^
z1.c:2:1: internal compiler error: in cpp_interpret_string_1, at
libcpp/charset.c:1739
2 | const char *c n(1, 2);
  | ^
0x18b9877 cpp_interpret_string_1
../../libcpp/charset.c:1739
0x18b9aed cpp_interpret_string(cpp_reader*, cpp_string const*, unsigned long,
cpp_string*, cpp_ttype)
../../libcpp/charset.c:1819
0x78aad3 c_parser_string_literal(c_parser*, bool, bool)
../../gcc/c/c-parser.c:7410
0x78b528 c_parser_postfix_expression
../../gcc/c/c-parser.c:9023
0x795b12 c_parser_unary_expression
../../gcc/c/c-parser.c:8255
0x796b5f c_parser_cast_expression
../../gcc/c/c-parser.c:8097
0x796e19 c_parser_binary_expression
../../gcc/c/c-parser.c:7900
0x79800b c_parser_conditional_expression
../../gcc/c/c-parser.c:7600
0x7986d1 c_parser_expr_no_commas
../../gcc/c/c-parser.c:7515
0x79eaf9 c_parser_initializer
../../gcc/c/c-parser.c:5212
0x7aef2a c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2282
0x7b70cf c_parser_external_declaration
../../gcc/c/c-parser.c:1780
0x7b79fb c_parser_translation_unit
../../gcc/c/c-parser.c:1653
0x7b79fb c_parse_file()
../../gcc/c/c-parser.c:23280
0x808eb2 c_common_parse_file()
../../gcc/c-family/c-opts.c:1240

[Bug fortran/103414] New: [10/11/12 Regression] ICE in gfc_free_actual_arglist, at fortran/expr.c:547

[gscfq--- via Gcc-bugs]

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

Bug ID: 103414
   Summary: [10/11/12 Regression] ICE in gfc_free_actual_arglist,
at fortran/expr.c:547
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r10, between 20190630 and 20190728 :


$ cat z1.f90
program p
   type t(n)
  integer, kind :: n
  character(n) :: c = ''
   end type
   type(t(3)) :: x = t(z'1')
end


$ cat z2.f90
program p
   type t(n)
  integer, kind :: n
  character(n) :: c = ''
   end type
   type(t(3)) :: x(1) = [t(z'1')]
end


$ gfortran-12-20211121 -c z2.f90
z2.f90:6:33:

6 |type(t(3)) :: x(1) = [t(z'1')]
  | 1
Error: The parameter expression at (1) must be of INTEGER type and not BOZ type
# hangs ...


$ gfortran-12-20211121 -c z1.f90
*** Error in `.../gcc/x86_64-pc-linux-gnu/12.0.0/f951': double free or
corruption (fasttop): 0x0298bdf0 ***
f951: internal compiler error: Aborted
0xd6009f crash_signal
../../gcc/toplev.c:322
0x79965c gfc_free_actual_arglist(gfc_actual_arglist*)
../../gcc/fortran/expr.c:547
0x788c66 gfc_match_data_decl()
../../gcc/fortran/decl.c:6340
0x7f3df3 match_word
../../gcc/fortran/parse.c:67
0x7f3df3 decode_statement
../../gcc/fortran/parse.c:378
0x7f583a next_free
../../gcc/fortran/parse.c:1397
0x7f583a next_statement
../../gcc/fortran/parse.c:1629
0x7f6f5b parse_spec
../../gcc/fortran/parse.c:4168
0x7fa2bc parse_progunit
../../gcc/fortran/parse.c:6179
0x7fb5a1 gfc_parse_file()
../../gcc/fortran/parse.c:6724
0x848a6f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug fortran/103413] New: [10/11/12 Regression] ICE: Invalid expression in gfc_element_size

[gscfq--- via Gcc-bugs]

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

Bug ID: 103413
   Summary: [10/11/12 Regression] ICE: Invalid expression in
gfc_element_size
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r10, between 20190630 and 20190728 :


$ cat z1.f90
program p
   type t
  class(*), allocatable :: a
   end type
   type(t) :: x
   allocate (x%a, source=z'1')
end


$ cat z2.f90
program p
   type t
  class(*), allocatable :: a
   end type
   type(t) :: x
   allocate (x%a, mold=z'1')
end


$ cat z3.f90
program p
   type t
  class(*), pointer :: a
   end type
   type(t) :: x
   allocate (x%a, mold=z'1')
end


$ gfortran-12-20211121 -c z1.f90
f951: internal compiler error: Invalid expression in gfc_element_size.
0x796be9 gfc_report_diagnostic
../../gcc/fortran/error.c:874
0x798757 gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1494
0x83c8f2 gfc_element_size(gfc_expr*, unsigned long*)
../../gcc/fortran/target-memory.c:137
0x778ca2 find_intrinsic_vtab
../../gcc/fortran/class.c:2774
0x778ca2 gfc_find_vtab(gfc_typespec*)
../../gcc/fortran/class.c:2926
0x80fd4e resolve_allocate_expr
../../gcc/fortran/resolve.c:8039
0x80fd4e resolve_allocate_deallocate
../../gcc/fortran/resolve.c:8419
0x811c81 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:12208
0x813297 resolve_codes
../../gcc/fortran/resolve.c:17536
0x81335e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17571
0x7fb614 resolve_all_program_units
../../gcc/fortran/parse.c:6573
0x7fb614 gfc_parse_file()
../../gcc/fortran/parse.c:6829
0x848a6f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug fortran/103412] New: [10/11/12 Regression] ICE: Invalid expression in gfc_element_size

[gscfq--- via Gcc-bugs]

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

Bug ID: 103412
   Summary: [10/11/12 Regression] ICE: Invalid expression in
gfc_element_size
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r10, between 20190630 and 20190728 :
(a few small remnants of the BOZ revision)


$ cat z1.f90
program p
   integer, parameter :: a = sizeof(z'1')
end


$ gfortran-12-20211121 -c z1.f90
f951: internal compiler error: Invalid expression in gfc_element_size.
0x796be9 gfc_report_diagnostic
../../gcc/fortran/error.c:874
0x798757 gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1494
0x83c8f2 gfc_element_size(gfc_expr*, unsigned long*)
../../gcc/fortran/target-memory.c:137
0x83c953 gfc_target_expr_size(gfc_expr*, unsigned long*)
../../gcc/fortran/target-memory.c:166
0x83086b gfc_simplify_sizeof(gfc_expr*)
../../gcc/fortran/simplify.c:7608
0x7ac972 do_simplify
../../gcc/fortran/intrinsic.c:4641
0x7b7a7a gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:5034
0x80b71c resolve_unknown_f
../../gcc/fortran/resolve.c:2972
0x80b71c resolve_function
../../gcc/fortran/resolve.c:3329
0x80b71c gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7166
0x79cac4 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:3130
0x79f990 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:3178
0x789f44 variable_decl
../../gcc/fortran/decl.c:3004
0x789f44 gfc_match_data_decl()
../../gcc/fortran/decl.c:6297
0x7f3df3 match_word
../../gcc/fortran/parse.c:67
0x7f3df3 decode_statement
../../gcc/fortran/parse.c:378
0x7f583a next_free
../../gcc/fortran/parse.c:1397
0x7f583a next_statement
../../gcc/fortran/parse.c:1629
0x7f7ca4 parse_spec
../../gcc/fortran/parse.c:3984
0x7fa2bc parse_progunit
../../gcc/fortran/parse.c:6179

[Bug fortran/103411] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

Detected :


$ cat z2.f90
program p
   integer, parameter :: b(2,2) = reshape([1,2,3], [2,2])
   print *, b
end


$ gfortran-12-20211121 -c z2.f90
z2.f90:2:42:

2 |integer, parameter :: b(2,2) = reshape([1,2,3], [2,2])
  |  1
Error: Without padding, there are not enough elements in the intrinsic RESHAPE
source at (1) to match the shape

[Bug fortran/103411] New: ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

[gscfq--- via Gcc-bugs]

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

Bug ID: 103411
   Summary: ICE in gfc_conv_array_initializer, at
fortran/trans-array.c:6377
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   integer, parameter :: a(2) = [2,2]
   integer, parameter :: b(2,2) = reshape([1,2,3], a)
   print *, b
end


$ gfortran-12-20211121 -c z1.f90
z1.f90:4:13:

4 |print *, b
  | 1
internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:6377
0x865e1a gfc_conv_array_initializer(tree_node*, gfc_expr*)
../../gcc/fortran/trans-array.c:6377
0x893b60 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:8375
0x874f2b gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1941
0x8843b8 gfc_conv_variable
../../gcc/fortran/trans-expr.c:2997
0x88063a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:9402
0x8833d0 gfc_conv_expr_lhs(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:9432
0x853e98 gfc_conv_ss_descriptor
../../gcc/fortran/trans-array.c:3219
0x85e8db gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-array.c:7494
0x8b2a57 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2630
0x84fa17 trans_code
../../gcc/fortran/trans.c:2136
0x8b02ce build_dt
../../gcc/fortran/trans-io.c:2026
0x84f9f7 trans_code
../../gcc/fortran/trans.c:2108
0x8789fe gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:7644
0x7fbd3e translate_all_program_units
../../gcc/fortran/parse.c:6638
0x7fbd3e gfc_parse_file()
../../gcc/fortran/parse.c:6925
0x848a6f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug c++/103410] ICE: in grokfndecl, at cp/decl.c:9903

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
I haven't found an existing bug report for this, so confirmed.

[Bug c++/67491] [meta-bug] concepts issues

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

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

Bug 71843 Summary: [concepts] Diagnostics issued for constraint satisfaction 
failure fail to elucidate unsatisfied constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71843

   What|Removed |Added

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

[Bug c++/71843] [concepts] Diagnostics issued for constraint satisfaction failure fail to elucidate unsatisfied constraints

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Marek Polacek  ---
Closing as fixed.

[Bug middle-end/103386] stage1 with PGO produces bad offsets in rtl-reload on aarch64

[mittorn at sibmail dot com via Gcc-bugs]

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

--- Comment #2 from mittorn at sibmail dot com ---
Removing -floop-nest-optimize -floop-interchange -fgraphite-identity fixes
build, but removing only -fgraphite-identity not

[Bug target/103395] [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||fche at redhat dot com

--- Comment #9 from Jakub Jelinek  ---
CCing Frank as this is systemtap sys/sdt.h
which has:
# ifndef STAP_SDT_ARG_CONSTRAINT
# if defined __powerpc__
# define STAP_SDT_ARG_CONSTRAINTnZr
# else
# define STAP_SDT_ARG_CONSTRAINTnor
# endif
# endif

All of n, o and r are generic constraints and const0_rtx is valid for the "n"
constraint, so why is the backend trying to put it into memory at all?
What is systemtap trying to do is not use those operands in any instruction,
but note for the debugger how to find out the value of the asm input operand
(read some register, some memory or the immediate constant).

[Bug c++/103410] New: ICE: in grokfndecl, at cp/decl.c:9903

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 103410
   Summary: ICE: in grokfndecl, at cp/decl.c:9903
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

This is an ancient bug that has existed since gcc-6, and I suspect someone has
reported it.

auto f() requires (auto{[]{}});

https://godbolt.org/z/4ajq6h9jK

[Bug tree-optimization/103409] New: 18% WRF compile-time regression with -O2 -flto between g:1ae8edf5f73ca5c3 and g:1ae8edf5f73ca5c3

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

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

Bug ID: 103409
   Summary: 18% WRF compile-time regression with -O2 -flto between
g:1ae8edf5f73ca5c3 and g:1ae8edf5f73ca5c3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

this is visible at
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=226.548.8
and
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=287.548.8

[Bug target/103395] [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier

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

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

--- Comment #8 from Richard Earnshaw  ---
OK, so the real problem in the test case is the constraint ("nor") is
meaningless on Arm (because there is no instruction in the architecture that
can accept both a constant and a memref) and this confuses the minipool code
because it exploits this restriction to detect insns that need to be reworked
by the md_reorg pass.

When processing an ASM we allow only a forward literal pool reference and it
must be less than 250 bytes beyond the /start/ of the pattern (because we don't
know where in the asm it gets used).  So we have to deduct from that range 4
bytes for every asm statement: add too many lines to the asm and we reach the
point where it is impossible to place the literal pool even directly after the
asm.

So I think really this is an ICE on invalid, because the constraint is not
meaningful on Arm.

[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-24
 CC||aldyh at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from ktkachov at gcc dot gnu.org ---
We've received requests from some users for this builtin as well. Given the new
ranger infrastructure, would it be able to make use of the semantics of such a
builtin in a useful way? (It'd be good to see GCC eliminate some redundant
extensions, maybe threading opportunities could be improved etc)

[Bug c++/103408] ICE when requires auto(x) in C++23

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Started with r12-5386, obviously.

[Bug c++/103408] ICE when requires auto(x) in C++23

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/103408] New: ICE when requires auto(x) in C++23

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 103408
   Summary: ICE when requires auto(x) in C++23
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

auto f() requires (auto(0));

https://godbolt.org/z/baEr7nqbW

[Bug ipa/103405] [12 Regression] c67005c FAILs with -fipa-modref

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

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

--- Comment #8 from Jan Hubicka  ---
Created attachment 51868
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51868=edit
Patch in testing

Good to know that there are no more known modref & Ada problems ;)  I recently
extended modref to also handle static chains and some problem may pop out...

The problem is the IPA pass determining incorrect EAF flags for the static
chain (it get NO_INDIRECT_READ which is not true since equal reads indirectly).
This is missed propagation of EAF flags for static chain - I missed this spot
while extending retslot handling to static chain since retslots does not need
this.

[Bug c++/46476] Missing Warning about unreachable code after return [-Wunreachable-code-return]

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Novembe
   ||r/585352.html

--- Comment #19 from Richard Biener  ---
Posted RFC patch.  The C++ frontend poses some more issues in GCC code for
statically true evaluated conditions like

  if (! GATHER_STATISTICS)
{
  fprintf (stderr, "No RTX statistics\n");
  return;
}

where it elides the if ().  It doesn't do that for if (0) though.

[Bug c++/103403] [11/12 Regression] auto return type with a trailing return type of decl(auto) uses rvalue reference type instead of reference type

[enricomaria.dean6elis at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Enrico Maria De Angelis  ---
So there is a relation between this problem and PR 78209. At least a
cause-effect relation.

[Bug c++/103379] ICE: tree check: expected class 'type', have 'declaration' (namespace_decl) in comptypes, at cp/typeck.c:1544

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Looks valid.

[Bug libstdc++/103382] condition_variable::wait() is not cancellable because it is marked noexcept

[vanyacpp at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Ivan Sorokin  ---
> Huh, I thought it was noexcept. Then yes, we should remove it.

Thank you very much! I'm looking forward for a fix.

> There are still lots of other places where the stadnard does require 
> 'noexcept' and cancellation will terminate.

Do you have any specific functions in mind? If so perhaps something can be done
about them too.

Some people claim that noexcept and cancellation and mutually incompatible, but
I don't think this is the case. I believe that by following a simple discipline
noexcept and cancellation can interact very well.

First of all not all noexcept functions are problematic: noexcept functions
that don't call cancellation points are perfectly fine.

The noexcept functions that do call some cancellation points can be fixed by
suppression/restoring of cancellation. For example, a destructor that calls
close() which is a cancellation point should just suppress/restore
cancellation. Same for a destructor that calls pthread_join(). One might say
that because of this we lose some cancellation points and this is true, but I
believe that noexcept are the places where program can not recover preserving
exception guarantees and having cancellation suppressed in these places is
perfectly fine.

[Bug c++/103379] ICE: tree check: expected class 'type', have 'declaration' (namespace_decl) in comptypes, at cp/typeck.c:1544

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started to ICE after r11-5003-gd50310408f54e380, it was rejected before the
revision.