Re: [PATCH] middle-end/104492 - avoid all equality compare dangling pointer diags

[Richard Biener via Gcc-patches]

On Wed, 27 Apr 2022, Jakub Jelinek wrote:

> On Mon, Apr 25, 2022 at 11:54:34AM +0200, Richard Biener wrote:
> > The following extends the equality compare dangling pointer diagnostics
> > suppression for uses following free or realloc to also cover those
> > following invalidation of auto variables via CLOBBERs.  That avoids
> > diagnosing idioms like
> > 
> >   return std::find(std::begin(candidates), std::end(candidates), s)
> >!= std::end(candidates);
> > 
> > for auto candidates which are prone to forwarding of the final
> > comparison across the storage invalidation as then seen by the
> > late run access warning pass.
> > 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > 
> > OK for trunk?
> > 
> > Thanks,
> > Richard.
> > 
> > 2022-04-25  Richard Biener  
> > 
> > PR middle-end/104492
> > * gimple-ssa-warn-access.cc
> > (pass_waccess::warn_invalid_pointer): Exclude equality compare
> > diagnostics for all kind of invalidations.
> > 
> > * c-c++-common/Wdangling-pointer.c: Adjust for changed
> > suppression.
> > * c-c++-common/Wdangling-pointer-2.c: Likewise.
> 
> I spoke with Martin on IRC and his comment was that this is ok
> but should be accompanied with a doc/invoke.texi change that clarifies
> that behavior in the documentation.
> I think that is a reasonable request.

Like so?

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 07b440190c3..4decbf84a43 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -8642,8 +8642,10 @@ Warn about uses of pointers (or C++ references) to 
objects with automatic
 storage duration after their lifetime has ended.  This includes local
 variables declared in nested blocks, compound literals and other unnamed
 temporary objects.  In addition, warn about storing the address of such
-objects in escaped pointers.  The warning is enabled at all optimization
-levels but may yield different results with optimization than without.
+objects in escaped pointers.  As exception we do not warn when pointers
+are used in equality compares after the lifetime of the storage they 
point
+to ended.  The warning is enabled at all optimization levels but may 
yield
+different results with optimization than without.
 
 @table @gcctabopt
 @item -Wdangling-pointer=1

[PATCH 1/2] LoongArch: Add '(clobber (mem:BLK (scratch)))' to PLV instruction templates.

[Lulu Cheng]

gcc/ChangeLog:

* config/loongarch/loongarch.md: Add '(clobber (mem:BLK (scratch)))'
to PLV instruction templates.
---
 gcc/config/loongarch/loongarch.md | 40 +--
 1 file changed, 28 insertions(+), 12 deletions(-)

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index 6c57c8b7025..5a7641703b5 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -2047,13 +2047,17 @@
 
 (define_insn "loongarch_ibar"
   [(unspec_volatile:SI
-  [(match_operand 0 "const_uimm15_operand")] UNSPECV_IBAR)]
+  [(match_operand 0 "const_uimm15_operand")]
+   UNSPECV_IBAR)
+   (clobber (mem:BLK (scratch)))]
   ""
   "ibar\t%0")
 
 (define_insn "loongarch_dbar"
   [(unspec_volatile:SI
-  [(match_operand 0 "const_uimm15_operand")] UNSPECV_DBAR)]
+  [(match_operand 0 "const_uimm15_operand")]
+   UNSPECV_DBAR)
+   (clobber (mem:BLK (scratch)))]
   ""
   "dbar\t%0")
 
@@ -2072,13 +2076,17 @@
 
 (define_insn "loongarch_syscall"
   [(unspec_volatile:SI
-  [(match_operand 0 "const_uimm15_operand")] UNSPECV_SYSCALL)]
+  [(match_operand 0 "const_uimm15_operand")]
+   UNSPECV_SYSCALL)
+   (clobber (mem:BLK (scratch)))]
   ""
   "syscall\t%0")
 
 (define_insn "loongarch_break"
   [(unspec_volatile:SI
-  [(match_operand 0 "const_uimm15_operand")] UNSPECV_BREAK)]
+  [(match_operand 0 "const_uimm15_operand")]
+   UNSPECV_BREAK)
+   (clobber (mem:BLK (scratch)))]
   ""
   "break\t%0")
 
@@ -2103,7 +2111,8 @@
 (define_insn "loongarch_csrrd_"
   [(set (match_operand:GPR 0 "register_operand" "=r")
(unspec_volatile:GPR [(match_operand  1 "const_uimm14_operand")]
- UNSPECV_CSRRD))]
+ UNSPECV_CSRRD))
+   (clobber (mem:BLK (scratch)))]
   ""
   "csrrd\t%0,%1"
   [(set_attr "type" "load")
@@ -2114,7 +2123,8 @@
  (unspec_volatile:GPR
[(match_operand:GPR 1 "register_operand" "0")
 (match_operand 2 "const_uimm14_operand")]
-UNSPECV_CSRWR))]
+UNSPECV_CSRWR))
+   (clobber (mem:BLK (scratch)))]
   ""
   "csrwr\t%0,%2"
   [(set_attr "type" "store")
@@ -2126,7 +2136,8 @@
[(match_operand:GPR 1 "register_operand" "0")
 (match_operand:GPR 2 "register_operand" "q")
 (match_operand 3 "const_uimm14_operand")]
-UNSPECV_CSRXCHG))]
+UNSPECV_CSRXCHG))
+   (clobber (mem:BLK (scratch)))]
   ""
   "csrxchg\t%0,%2,%3"
   [(set_attr "type" "load")
@@ -2135,7 +2146,8 @@
 (define_insn "loongarch_iocsrrd_"
   [(set (match_operand:QHWD 0 "register_operand" "=r")
(unspec_volatile:QHWD [(match_operand:SI 1 "register_operand" "r")]
- UNSPECV_IOCSRRD))]
+ UNSPECV_IOCSRRD))
+   (clobber (mem:BLK (scratch)))]
   ""
   "iocsrrd.\t%0,%1"
   [(set_attr "type" "load")
@@ -2144,7 +2156,8 @@
 (define_insn "loongarch_iocsrwr_"
   [(unspec_volatile:QHWD [(match_operand:QHWD 0 "register_operand" "r")
  (match_operand:SI 1 "register_operand" "r")]
- UNSPECV_IOCSRWR)]
+ UNSPECV_IOCSRWR)
+   (clobber (mem:BLK (scratch)))]
   ""
   "iocsrwr.\t%0,%1"
   [(set_attr "type" "load")
@@ -2154,7 +2167,8 @@
   [(unspec_volatile:X [(match_operand 0 "const_uimm5_operand")
   (match_operand:X 1 "register_operand" "r")
   (match_operand 2 "const_imm12_operand")]
-  UNSPECV_CACOP)]
+  UNSPECV_CACOP)
+   (clobber (mem:BLK (scratch)))]
   ""
   "cacop\t%0,%1,%2"
   [(set_attr "type" "load")
@@ -2164,7 +2178,8 @@
   [(unspec_volatile:X [(match_operand:X 0 "register_operand" "r")
   (match_operand:X 1 "register_operand" "r")
   (match_operand 2 "const_uimm5_operand")]
-  UNSPECV_LDDIR)]
+  UNSPECV_LDDIR)
+   (clobber (mem:BLK (scratch)))]
   ""
   "lddir\t%0,%1,%2"
   [(set_attr "type" "load")
@@ -2173,7 +2188,8 @@
 (define_insn "loongarch_ldpte_"
   [(unspec_volatile:X [(match_operand:X 0 "register_operand" "r")
   (match_operand 1 "const_uimm5_operand")]
-  UNSPECV_LDPTE)]
+  UNSPECV_LDPTE)
+   (clobber (mem:BLK (scratch)))]
   ""
   "ldpte\t%0,%1"
   [(set_attr "type" "load")
-- 
2.31.1

[PATCH 2/2] LoongArch: Add fdiv define_expand template.

[Lulu Cheng]

gcc/ChangeLog:

* config/loongarch/loongarch.md: Add fdiv define_expand template,
then generate floating-point division and floating-point reciprocal
instructions.
---
 gcc/config/loongarch/loongarch.md | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index 5a7641703b5..d3c809e25f3 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -713,6 +713,12 @@
 ;;
 
 ;; Float division and modulus.
+(define_expand "div3"
+  [(set (match_operand:ANYF 0 "register_operand")
+   (div:ANYF (match_operand:ANYF 1 "reg_or_1_operand")
+ (match_operand:ANYF 2 "register_operand")))]
+  "")
+
 (define_insn "*div3"
   [(set (match_operand:ANYF 0 "register_operand" "=f")
(div:ANYF (match_operand:ANYF 1 "register_operand" "f")
-- 
2.31.1

Re: [PATCH] middle-end/104492 - avoid all equality compare dangling pointer diags

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 27, 2022 at 09:00:51AM +0200, Richard Biener wrote:
> > > 2022-04-25  Richard Biener  
> > > 
> > >   PR middle-end/104492
> > >   * gimple-ssa-warn-access.cc
> > >   (pass_waccess::warn_invalid_pointer): Exclude equality compare
> > >   diagnostics for all kind of invalidations.
> > > 
> > >   * c-c++-common/Wdangling-pointer.c: Adjust for changed
> > >   suppression.
> > >   * c-c++-common/Wdangling-pointer-2.c: Likewise.
> > 
> > I spoke with Martin on IRC and his comment was that this is ok
> > but should be accompanied with a doc/invoke.texi change that clarifies
> > that behavior in the documentation.
> > I think that is a reasonable request.
> 
> Like so?
> 
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 07b440190c3..4decbf84a43 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -8642,8 +8642,10 @@ Warn about uses of pointers (or C++ references) to 
> objects with automatic
>  storage duration after their lifetime has ended.  This includes local
>  variables declared in nested blocks, compound literals and other unnamed
>  temporary objects.  In addition, warn about storing the address of such
> -objects in escaped pointers.  The warning is enabled at all optimization
> -levels but may yield different results with optimization than without.
> +objects in escaped pointers.  As exception we do not warn when pointers
> +are used in equality compares after the lifetime of the storage they 
> point
> +to ended.  The warning is enabled at all optimization levels but may 
> yield
> +different results with optimization than without.
>  
>  @table @gcctabopt
>  @item -Wdangling-pointer=1

Reading the patch again, I don't think the above is what the patch does,
but furthermore, I'm not sure the patch is right.

Before your change, the code was about 2 warnings, -Wuse-after-free=
with levels 0 (well, -Wno-use-after-free), 1, 2, 3 where 3 is enabling
equality and the warning is done when the invalidating statement is
a call.

Then there is code for the -Wdangling-pointer= warning with levels 0 (well,
-Wno-dangling-pointer), 1, 2.

Your change moves the -Wuse-after-free= stanza for both warnings including
-Wuse-after-free= suppressions for both warnings and kills the
-Wdangling-pointer= stanza.  I think that means there would be no
difference between -Wdangling-pointer=1 and -Wdangling-pointer=2 anymore
and whether the warning is given for the maybe case (or equality case)
would be instead determined by -Wuse-after-free= level.

I'd say the right thing would be to keep the -Wuse-after-free= stuff as is
and just adjust
-  if ((maybe && warn_dangling_pointer < 2)
+  if ((equality && warn_dangling_pointer < 3)
+  || (maybe && warn_dangling_pointer < 2)
   || warning_suppressed_p (use_stmt, OPT_Wdangling_pointer_))
 return;
i.e. basically introduce -Wdangling-pointer=3 level.  That would need
 Wdangling-pointer=
-C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_dangling_pointer) 
Warning LangEnabledBy(C ObjC C++ ObjC++,Wall, 2, 0) IntegerRange(0, 2)
+C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_dangling_pointer) 
Warning LangEnabledBy(C ObjC C++ ObjC++,Wall, 2, 0) IntegerRange(0, 3)
change, documentation what the -Wdangling-pointer=3 level means in
invoke.texi (similar to -Wuse-after-free=3 documentation?) and another
testcase with -Wdangling-pointer=3 in dg-options where it warns also
about equality.

Jakub

[PATCH] middle-end/105376 - invalid REAL_CST for DFP constant

[Richard Biener via Gcc-patches]

We are eventually ICEing in decimal_to_decnumber on non-decimal
REAL_VALUE_TYPE that creep in from uses of build_real (..., dconst*)
for DFP types.  The following fixes the single occurance that matters
for the testcase in the PR by instead using build_real_truncate.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

OK for trunk?

Is this the correct strathegy to deal with this problem?  Would
it be valid to just set ->is_decimal in build_real based on
DECIMAL_FLOAT_TYPE_P for the dconst* cases we "support" (not
checking for them but instead declaring others invalid)?

Richard.

2022-04-27  Richard Biener  

PR middle-end/105376
* match.pd (x + x -> 2.*x): Use build_real_truncate.

* gcc.dg/pr105376.c: New testcase.
---
 gcc/match.pd| 2 +-
 gcc/testsuite/gcc.dg/pr105376.c | 9 +
 2 files changed, 10 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr105376.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 6d691d302b3..663dccf3289 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -3865,7 +3865,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (simplify
  (plus @0 @0)
  (if (SCALAR_FLOAT_TYPE_P (type))
-  (mult @0 { build_real (type, dconst2); })
+  (mult @0 { build_real_truncate (type, dconst2); })
   (if (INTEGRAL_TYPE_P (type))
(mult @0 { build_int_cst (type, 2); }
 
diff --git a/gcc/testsuite/gcc.dg/pr105376.c b/gcc/testsuite/gcc.dg/pr105376.c
new file mode 100644
index 000..f19ecf4aab2
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr105376.c
@@ -0,0 +1,9 @@
+/* { dg-do compile { target dfp } } */
+/* { dg-options "-O -g" } */
+
+void
+foo (_Decimal64 d, _Decimal64 e)
+{
+  d -= -d;
+  d *= -e;
+}
-- 
2.34.1

Re: [PATCH] middle-end/104492 - avoid all equality compare dangling pointer diags

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 27, 2022 at 09:29:21AM +0200, Jakub Jelinek via Gcc-patches wrote:
> I'd say the right thing would be to keep the -Wuse-after-free= stuff as is
> and just adjust
> -  if ((maybe && warn_dangling_pointer < 2)
> +  if ((equality && warn_dangling_pointer < 3)
> +  || (maybe && warn_dangling_pointer < 2)
>|| warning_suppressed_p (use_stmt, OPT_Wdangling_pointer_))
>  return;
> i.e. basically introduce -Wdangling-pointer=3 level.  That would need

Or, if the intent is what you've documented that equality comparisons
are never warned about, then just if (equality || (maybe && ...
But I think the extra warning level might be better especially if we
document that the level can have many false positives and explain why.
But if somebody is willing to go through the false positives to find
some needle in the haystack, let it be his choice.

Jakub

Re: [PATCH] middle-end/104492 - avoid all equality compare dangling pointer diags

[Richard Biener via Gcc-patches]

On Wed, 27 Apr 2022, Jakub Jelinek wrote:

> On Wed, Apr 27, 2022 at 09:00:51AM +0200, Richard Biener wrote:
> > > > 2022-04-25  Richard Biener  
> > > > 
> > > > PR middle-end/104492
> > > > * gimple-ssa-warn-access.cc
> > > > (pass_waccess::warn_invalid_pointer): Exclude equality compare
> > > > diagnostics for all kind of invalidations.
> > > > 
> > > > * c-c++-common/Wdangling-pointer.c: Adjust for changed
> > > > suppression.
> > > > * c-c++-common/Wdangling-pointer-2.c: Likewise.
> > > 
> > > I spoke with Martin on IRC and his comment was that this is ok
> > > but should be accompanied with a doc/invoke.texi change that clarifies
> > > that behavior in the documentation.
> > > I think that is a reasonable request.
> > 
> > Like so?
> > 
> > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > index 07b440190c3..4decbf84a43 100644
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -8642,8 +8642,10 @@ Warn about uses of pointers (or C++ references) to 
> > objects with automatic
> >  storage duration after their lifetime has ended.  This includes local
> >  variables declared in nested blocks, compound literals and other unnamed
> >  temporary objects.  In addition, warn about storing the address of such
> > -objects in escaped pointers.  The warning is enabled at all optimization
> > -levels but may yield different results with optimization than without.
> > +objects in escaped pointers.  As exception we do not warn when pointers
> > +are used in equality compares after the lifetime of the storage they 
> > point
> > +to ended.  The warning is enabled at all optimization levels but may 
> > yield
> > +different results with optimization than without.
> >  
> >  @table @gcctabopt
> >  @item -Wdangling-pointer=1
> 
> Reading the patch again, I don't think the above is what the patch does,
> but furthermore, I'm not sure the patch is right.
> 
> Before your change, the code was about 2 warnings, -Wuse-after-free=
> with levels 0 (well, -Wno-use-after-free), 1, 2, 3 where 3 is enabling
> equality and the warning is done when the invalidating statement is
> a call.
> 
> Then there is code for the -Wdangling-pointer= warning with levels 0 (well,
> -Wno-dangling-pointer), 1, 2.
> 
> Your change moves the -Wuse-after-free= stanza for both warnings including
> -Wuse-after-free= suppressions for both warnings and kills the
> -Wdangling-pointer= stanza.

Whoops, that wasn't my itention.

> I think that means there would be no
> difference between -Wdangling-pointer=1 and -Wdangling-pointer=2 anymore
> and whether the warning is given for the maybe case (or equality case)
> would be instead determined by -Wuse-after-free= level.
> 
> I'd say the right thing would be to keep the -Wuse-after-free= stuff as is
> and just adjust
> -  if ((maybe && warn_dangling_pointer < 2)
> +  if ((equality && warn_dangling_pointer < 3)
> +  || (maybe && warn_dangling_pointer < 2)
>|| warning_suppressed_p (use_stmt, OPT_Wdangling_pointer_))
>  return;
> i.e. basically introduce -Wdangling-pointer=3 level.  That would need
>  Wdangling-pointer=
> -C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_dangling_pointer) 
> Warning LangEnabledBy(C ObjC C++ ObjC++,Wall, 2, 0) IntegerRange(0, 2)
> +C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_dangling_pointer) 
> Warning LangEnabledBy(C ObjC C++ ObjC++,Wall, 2, 0) IntegerRange(0, 3)
> change, documentation what the -Wdangling-pointer=3 level means in
> invoke.texi (similar to -Wuse-after-free=3 documentation?) and another
> testcase with -Wdangling-pointer=3 in dg-options where it warns also
> about equality.

I didn't want to introduce -Wdangling-pointer=3 since I think the
case in the PR is just the tip of the iceberg so that we suppress
for equality compares would have been an implementation detail ...

So I'd do the below then.  I think if we want to introduce
-Wdangling-pointer=3 then we should restrict =2 way more by
excluding all non-memory use stmts.  So we'd still cover

 a.x = ptr; // escape
 foo (ptr); // escape
 *ptr = ..; // store
 .. = *ptr; // load

but not any operations on the pointer value (compare, pointer-plus,
difference, masking, etc.).  A simple-minded implementation would
then be

  if ((!gimple_vuse (use_stmt) && warn_dangling_pointer < 3)
  || (maybe && ...

I'm going to see whether there's any testsuite coverage for !gimple_vuse
use_stmt.

Richard.

diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index 879dbcc1e52..80b5119da7d 100644
--- a/gcc/gimple-ssa-warn-access.cc
+++ b/gcc/gimple-ssa-warn-access.cc
@@ -3923,7 +3923,8 @@ pass_waccess::warn_invalid_pointer (tree ref, gimple 
*use_
stmt,
   return;
 }
 
-  if ((maybe && warn_dangling_pointer < 2)
+  if (equality
+  || (maybe && warn_dangling_pointer < 2)
   || warning_suppressed_p (use_stmt, OPT_Wdangling_pointer_))
 return;
 


>   Jakub
> 
> 

Re: [PATCH] middle-end/104492 - avoid all equality compare dangling pointer diags

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 27, 2022 at 09:43:59AM +0200, Richard Biener wrote:
> but not any operations on the pointer value (compare, pointer-plus,
> difference, masking, etc.).  A simple-minded implementation would
> then be
> 
>   if ((!gimple_vuse (use_stmt) && warn_dangling_pointer < 3)
>   || (maybe && ...

That would consider as memory uses both cases where we actually dereference
the pointer and where we store the pointer in some memory.
But perhaps that would be the goal.

> diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
> index 879dbcc1e52..80b5119da7d 100644
> --- a/gcc/gimple-ssa-warn-access.cc
> +++ b/gcc/gimple-ssa-warn-access.cc
> @@ -3923,7 +3923,8 @@ pass_waccess::warn_invalid_pointer (tree ref, gimple 
> *use_
> stmt,
>return;
>  }
>  
> -  if ((maybe && warn_dangling_pointer < 2)
> +  if (equality
> +  || (maybe && warn_dangling_pointer < 2)
>|| warning_suppressed_p (use_stmt, OPT_Wdangling_pointer_))
>  return;
>  

This is fine too with the invoke.texi change and the testcases.

Jakub

[PATCH] testsuite: Add arm testcase for PR105374

[Christophe Lyon via Gcc-patches]

As discussed in the PR, here is the testcase with the appropriate dg-*
directives.

Tested on arm-none-eabi with
1 -mcpu=cortex-a7/-mfloat-abi=soft/-march=armv7ve+simd
2 -mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd
3 -mthumb/-mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd
4 -mthumb/-mfloat-abi=soft/-march=armv6s-m
5 -mthumb/-mfloat-abi=soft/-march=armv7-m
6 -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp
7 -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp.dp
8 -mthumb/-mfloat-abi=hard/-march=armv8-m.main+fp+dsp
9 -mthumb/-mfloat-abi=hard/-march=armv8.1-m.main+mve.fp+fp.dp
10 -mthumb/-mfloat-abi=hard/-march=armv8.1-m.main+mve

The test is UNSUPPORTED with the first three ones (because of
-mcpu=cortex-a7), ignored with armv6s-m, and PASSes with all the other
ones, while it used crash without Jakub's fix (r12-8263), ie. FAIL
with options 5,6,7,8,10. The test passed without Jakub's fix with
option 9 because the problem happens only with an integer-only MVE.

2022-04-26  Christophe Lyon  

gcc/testsuite/

PR tree-optimization/105374
* gcc.target/arm/simd/pr105374.C: New.
---
 gcc/testsuite/gcc.target/arm/simd/pr105374.C | 8 
 1 file changed, 8 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/arm/simd/pr105374.C

diff --git a/gcc/testsuite/gcc.target/arm/simd/pr105374.C 
b/gcc/testsuite/gcc.target/arm/simd/pr105374.C
new file mode 100644
index 000..2b9096f1f52
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/simd/pr105374.C
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+/* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
+
+typedef float v4f __attribute__((vector_size(4 * sizeof(float;
+v4f f_x, f_y;
+long f() { return (f_x < f_y | f_x <= f_y)[2]; }
-- 
2.17.1

[Ada] Revert r12-6599 (Fix up handling of ghost units [PR104027])

[Pierre-Marie de Rodat via Gcc-patches]

That change was short-circuiting too much, the regular processing (in
particular writing ALI files) was bypassed, causing troubles with e.g.
gnatmake or gprbuild down the road. Thanks to r12-6943, this is no longer
necessary, so revert it.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* gnat1drv.adb: Remove the goto End_Of_Program.diff --git a/gcc/ada/gnat1drv.adb b/gcc/ada/gnat1drv.adb
--- a/gcc/ada/gnat1drv.adb
+++ b/gcc/ada/gnat1drv.adb
@@ -1429,11 +1429,6 @@ begin
 Ecode := E_Success;
 Back_End.Gen_Or_Update_Object_File;
 
---  Use a goto instead of calling Exit_Program so that finalization
---  occurs normally.
-
-goto End_Of_Program;
-
  --  Otherwise the unit is missing a crucial piece that prevents code
  --  generation.
 

Re: [PATCH] testsuite: Add arm testcase for PR105374

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 27, 2022 at 09:50:32AM +0200, Christophe Lyon via Gcc-patches wrote:
> As discussed in the PR, here is the testcase with the appropriate dg-*
> directives.
> 
> Tested on arm-none-eabi with
> 1 -mcpu=cortex-a7/-mfloat-abi=soft/-march=armv7ve+simd
> 2 -mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd
> 3 -mthumb/-mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd
> 4 -mthumb/-mfloat-abi=soft/-march=armv6s-m
> 5 -mthumb/-mfloat-abi=soft/-march=armv7-m
> 6 -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp
> 7 -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp.dp
> 8 -mthumb/-mfloat-abi=hard/-march=armv8-m.main+fp+dsp
> 9 -mthumb/-mfloat-abi=hard/-march=armv8.1-m.main+mve.fp+fp.dp
> 10 -mthumb/-mfloat-abi=hard/-march=armv8.1-m.main+mve
> 
> The test is UNSUPPORTED with the first three ones (because of
> -mcpu=cortex-a7), ignored with armv6s-m, and PASSes with all the other
> ones, while it used crash without Jakub's fix (r12-8263), ie. FAIL
> with options 5,6,7,8,10. The test passed without Jakub's fix with
> option 9 because the problem happens only with an integer-only MVE.
> 
> 2022-04-26  Christophe Lyon  
> 
>   gcc/testsuite/
> 
>   PR tree-optimization/105374
>   * gcc.target/arm/simd/pr105374.C: New.

Ok, thanks.

Jakub

Re: [gcov v2 14/14] gcov: Add section for freestanding environments

[Martin Liška]

On 4/26/22 19:49, Sebastian Huber wrote:
> Should I use "-ftest-coverage -fprofile-arcs" or "--coverage" in the tutorial?

The later one, please.

Cheers,
Martin

Re: [PATCH] middle-end/104492 - avoid all equality compare dangling pointer diags

[Richard Biener via Gcc-patches]

On Wed, 27 Apr 2022, Jakub Jelinek wrote:

> On Wed, Apr 27, 2022 at 09:43:59AM +0200, Richard Biener wrote:
> > but not any operations on the pointer value (compare, pointer-plus,
> > difference, masking, etc.).  A simple-minded implementation would
> > then be
> > 
> >   if ((!gimple_vuse (use_stmt) && warn_dangling_pointer < 3)
> >   || (maybe && ...
> 
> That would consider as memory uses both cases where we actually dereference
> the pointer and where we store the pointer in some memory.
> But perhaps that would be the goal.

I think that was the intention of the diagnostic, yes.  I don't think
it's very useful to diagnose that you add 1 to a dangling pointer,
instead I hope the code will diagnose the dereference of the offsetted
dangling pointer instead (I think it does, though it might miss _1 = 
&MEM[_2 + 4]; from a quick look, likewise _2 & ~3 (aligning a pointer)
and any tricks via uintptr casting).

There's some testsuite fallout with using !gimple_vuse () because
when a diagnostic is suppressed we are _not_ tracking derived pointers.

For c-c++-common/Wdangling-pointer.c at -O0 we diagnose

void* warn_return_local_addr (void)
{
  int *p = 0;
  {
int a[] = { 1, 2, 3 };
p = a;
  }

  /* Unlike the above case, here the pointer is dangling when it's
 used.  */
  return p;   // { dg-warning "using dangling pointer 'p' 
to 'a'" "array" }
}

   _8 = p_6; // <-- here

:
   return _8;

but if we suppress that we do not add _8 to the pointers to check.
Even if we do add it we get a maybe diagnostic because the
post-dominator query uses reversed arguments (oops, we should probably
fix that independently).  Fixing that results in
'using a dangling pointer to 'a'' (instead of naming 'p') since _8
is anonymous.

When optimizing we fail to diagnose this case - we skip return stmts
because of -Wreturn-local-addr but when we do not warn about the
artificial SSA copy the diagnostic is lost.  So that's the only
"intentional" diagnostic that's skipped by !gimple_vuse ().

Still it requires too much changes to code I'm not familiar with
at this point.

> > diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
> > index 879dbcc1e52..80b5119da7d 100644
> > --- a/gcc/gimple-ssa-warn-access.cc
> > +++ b/gcc/gimple-ssa-warn-access.cc
> > @@ -3923,7 +3923,8 @@ pass_waccess::warn_invalid_pointer (tree ref, gimple 
> > *use_
> > stmt,
> >return;
> >  }
> >  
> > -  if ((maybe && warn_dangling_pointer < 2)
> > +  if (equality
> > +  || (maybe && warn_dangling_pointer < 2)
> >|| warning_suppressed_p (use_stmt, OPT_Wdangling_pointer_))
> >  return;
> >  
> 
> This is fine too with the invoke.texi change and the testcases.

So I'm leaning towards this to fix the P1 bug and see what other
cases people come up with in the real world.

As said if not introducing =3 I'd not document this implementation
detail (as said above we miss some cases because we fail to follow
all pointer adjustments as well).

I'm re-testing the variant below, not documenting the implementation
detail but fixing the post-dominator queries.

Richard.

>From 098ab3298b273a56bafe978facdc512789a7628a Mon Sep 17 00:00:00 2001
From: Richard Biener 
Date: Mon, 25 Apr 2022 10:46:16 +0200
Subject: [PATCH] middle-end/104492 - avoid all equality compare dangling
 pointer diags
To: gcc-patches@gcc.gnu.org

The following extends the equality compare dangling pointer diagnostics
suppression for uses following free or realloc to also cover those
following invalidation of auto variables via CLOBBERs.  That avoids
diagnosing idioms like

  return std::find(std::begin(candidates), std::end(candidates), s)
   != std::end(candidates);

for auto candidates which are prone to forwarding of the final
comparison across the storage invalidation as then seen by the
late run access warning pass.

2022-04-25  Richard Biener  

PR middle-end/104492
* gimple-ssa-warn-access.cc
(pass_waccess::warn_invalid_pointer): Exclude equality compare
diagnostics for all kind of invalidations.
(pass_waccess::check_dangling_uses): Fix post-dominator query.
(pass_waccess::check_pointer_uses): Likewise.
---
 gcc/gimple-ssa-warn-access.cc | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index 879dbcc1e52..39aa8186de6 100644
--- a/gcc/gimple-ssa-warn-access.cc
+++ b/gcc/gimple-ssa-warn-access.cc
@@ -3923,7 +3923,8 @@ pass_waccess::warn_invalid_pointer (tree ref, gimple 
*use_stmt,
   return;
 }
 
-  if ((maybe && warn_dangling_pointer < 2)
+  if (equality
+  || (maybe && warn_dangling_pointer < 2)
   || warning_suppressed_p (use_stmt, OPT_Wdangling_pointer_))
 return;
 
@@ -4241,7 +4242,7 @@ pass_waccess::check_pointer_uses (gimple *stmt, tree ptr,
  basic_block use_bb = gimple_bb (use_stmt);
  bool this_maybe
= (maybe
-  

[PATCH] Honor COMDAT for mergeable constant sections

[Ilya Leoshkevich via Gcc-patches]

Bootstrapped and regtested on x86_64-redhat-linux and
s390x-redhat-linux.  Ok for master (or GCC 13 in case this doesn't fit
stage4 criteria)?



Building C++ template-heavy code with ASan sometimes leads to bogus
"defined in discarded section" linker errors.

The reason is that .rodata.FUNC.cstN sections are not placed into
COMDAT group sections FUNC.  This is important, because ASan puts
references to .LASANPC labels into these sections.  Discarding the
respective .text.FUNC section causes the linker error.

Fix by adding SECTION_LINKONCE to .rodata.FUNC.cstN sections in
mergeable_constant_section () if the current function has an associated
COMDAT group.  This is similar to what switch_to_exception_section ()
is currently doing with .gcc_except_table.FUNC sections.

gcc/ChangeLog:

* varasm.cc (mergeable_constant_section): Honor COMDAT.

gcc/testsuite/ChangeLog:

* g++.dg/asan/comdat.C: New test.
---
 gcc/testsuite/g++.dg/asan/comdat.C | 35 ++
 gcc/varasm.cc  |  6 -
 2 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/asan/comdat.C

diff --git a/gcc/testsuite/g++.dg/asan/comdat.C 
b/gcc/testsuite/g++.dg/asan/comdat.C
new file mode 100644
index 000..cd4f3f830a8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/asan/comdat.C
@@ -0,0 +1,35 @@
+/* Check that we don't emit non-COMDAT rodata.  */
+
+/* { dg-do compile } */
+/* { dg-final { scan-assembler-not 
{\.section\t\.rodata\._ZN1hlsIPKcEERS_RKT_\.cst[48],"[^"]*",@progbits,[48]\n} } 
} */
+
+const char *a;
+
+class b
+{
+public:
+  b ();
+};
+
+class h
+{
+public:
+  template 
+  h &
+  operator<< (const c &)
+  {
+d (b ());
+return *this;
+  }
+
+  void d (b);
+};
+
+h e ();
+
+h
+g ()
+{
+  e () << a << a << a;
+  throw;
+}
diff --git a/gcc/varasm.cc b/gcc/varasm.cc
index c41f17d64f7..f2614f0ee39 100644
--- a/gcc/varasm.cc
+++ b/gcc/varasm.cc
@@ -938,7 +938,11 @@ mergeable_constant_section (machine_mode mode 
ATTRIBUTE_UNUSED,
 
   sprintf (name, "%s.cst%d", prefix, (int) (align / 8));
   flags |= (align / 8) | SECTION_MERGE;
-  return get_section (name, flags, NULL);
+  if (current_function_decl
+ && DECL_COMDAT_GROUP (current_function_decl)
+ && HAVE_COMDAT_GROUP)
+   flags |= SECTION_LINKONCE;
+  return get_section (name, flags, current_function_decl);
 }
   return readonly_data_section;
 }
-- 
2.35.1

Re: [PATCH] Honor COMDAT for mergeable constant sections

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 27, 2022 at 11:27:49AM +0200, Ilya Leoshkevich via Gcc-patches 
wrote:
> Bootstrapped and regtested on x86_64-redhat-linux and
> s390x-redhat-linux.  Ok for master (or GCC 13 in case this doesn't fit
> stage4 criteria)?

I'd prefer to defer this to GCC 13 at this point.
Furthermore, does the linker then actually merge the constants with
the same constants from other mergeable linkonce sections or other
mergeable sections?  I'm afraid it would only merge constants within
each comdat group and not across the whole ELF object.

Jakub

Re: [PATCH] middle-end/104492 - avoid all equality compare dangling pointer diags

[Richard Biener via Gcc-patches]

On Wed, 27 Apr 2022, Richard Biener wrote:

> On Wed, 27 Apr 2022, Jakub Jelinek wrote:
> 
> > On Wed, Apr 27, 2022 at 09:43:59AM +0200, Richard Biener wrote:
> > > but not any operations on the pointer value (compare, pointer-plus,
> > > difference, masking, etc.).  A simple-minded implementation would
> > > then be
> > > 
> > >   if ((!gimple_vuse (use_stmt) && warn_dangling_pointer < 3)
> > >   || (maybe && ...
> > 
> > That would consider as memory uses both cases where we actually dereference
> > the pointer and where we store the pointer in some memory.
> > But perhaps that would be the goal.
> 
> I think that was the intention of the diagnostic, yes.  I don't think
> it's very useful to diagnose that you add 1 to a dangling pointer,
> instead I hope the code will diagnose the dereference of the offsetted
> dangling pointer instead (I think it does, though it might miss _1 = 
> &MEM[_2 + 4]; from a quick look, likewise _2 & ~3 (aligning a pointer)
> and any tricks via uintptr casting).
> 
> There's some testsuite fallout with using !gimple_vuse () because
> when a diagnostic is suppressed we are _not_ tracking derived pointers.
> 
> For c-c++-common/Wdangling-pointer.c at -O0 we diagnose
> 
> void* warn_return_local_addr (void)
> {
>   int *p = 0;
>   {
> int a[] = { 1, 2, 3 };
> p = a;
>   }
> 
>   /* Unlike the above case, here the pointer is dangling when it's
>  used.  */
>   return p;   // { dg-warning "using dangling pointer 'p' 
> to 'a'" "array" }
> }
> 
>_8 = p_6; // <-- here
> 
> :
>return _8;
> 
> but if we suppress that we do not add _8 to the pointers to check.
> Even if we do add it we get a maybe diagnostic because the
> post-dominator query uses reversed arguments (oops, we should probably
> fix that independently).  Fixing that results in
> 'using a dangling pointer to 'a'' (instead of naming 'p') since _8
> is anonymous.
> 
> When optimizing we fail to diagnose this case - we skip return stmts
> because of -Wreturn-local-addr but when we do not warn about the
> artificial SSA copy the diagnostic is lost.  So that's the only
> "intentional" diagnostic that's skipped by !gimple_vuse ().
> 
> Still it requires too much changes to code I'm not familiar with
> at this point.
> 
> > > diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
> > > index 879dbcc1e52..80b5119da7d 100644
> > > --- a/gcc/gimple-ssa-warn-access.cc
> > > +++ b/gcc/gimple-ssa-warn-access.cc
> > > @@ -3923,7 +3923,8 @@ pass_waccess::warn_invalid_pointer (tree ref, 
> > > gimple 
> > > *use_
> > > stmt,
> > >return;
> > >  }
> > >  
> > > -  if ((maybe && warn_dangling_pointer < 2)
> > > +  if (equality
> > > +  || (maybe && warn_dangling_pointer < 2)
> > >|| warning_suppressed_p (use_stmt, OPT_Wdangling_pointer_))
> > >  return;
> > >  
> > 
> > This is fine too with the invoke.texi change and the testcases.
> 
> So I'm leaning towards this to fix the P1 bug and see what other
> cases people come up with in the real world.
> 
> As said if not introducing =3 I'd not document this implementation
> detail (as said above we miss some cases because we fail to follow
> all pointer adjustments as well).
> 
> I'm re-testing the variant below, not documenting the implementation
> detail but fixing the post-dominator queries.

Bootstrapped & tested on x86_64-unknown-linux-gnu.

OK?

Thanks,
Richard.

> Richard.
> 
> From 098ab3298b273a56bafe978facdc512789a7628a Mon Sep 17 00:00:00 2001
> From: Richard Biener 
> Date: Mon, 25 Apr 2022 10:46:16 +0200
> Subject: [PATCH] middle-end/104492 - avoid all equality compare dangling
>  pointer diags
> To: gcc-patches@gcc.gnu.org
> 
> The following extends the equality compare dangling pointer diagnostics
> suppression for uses following free or realloc to also cover those
> following invalidation of auto variables via CLOBBERs.  That avoids
> diagnosing idioms like
> 
>   return std::find(std::begin(candidates), std::end(candidates), s)
>!= std::end(candidates);
> 
> for auto candidates which are prone to forwarding of the final
> comparison across the storage invalidation as then seen by the
> late run access warning pass.
> 
> 2022-04-25  Richard Biener  
> 
>   PR middle-end/104492
>   * gimple-ssa-warn-access.cc
>   (pass_waccess::warn_invalid_pointer): Exclude equality compare
>   diagnostics for all kind of invalidations.
>   (pass_waccess::check_dangling_uses): Fix post-dominator query.
>   (pass_waccess::check_pointer_uses): Likewise.
> ---
>  gcc/gimple-ssa-warn-access.cc | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
> index 879dbcc1e52..39aa8186de6 100644
> --- a/gcc/gimple-ssa-warn-access.cc
> +++ b/gcc/gimple-ssa-warn-access.cc
> @@ -3923,7 +3923,8 @@ pass_waccess::warn_invalid_pointer (tree ref, gimple 
> *use_stmt,
>return;
>  }
>  
> -  if ((m

Re: [PATCH] Honor COMDAT for mergeable constant sections

[Ilya Leoshkevich via Gcc-patches]

On Wed, 2022-04-27 at 11:33 +0200, Jakub Jelinek wrote:
> On Wed, Apr 27, 2022 at 11:27:49AM +0200, Ilya Leoshkevich via Gcc-
> patches wrote:
> > Bootstrapped and regtested on x86_64-redhat-linux and
> > s390x-redhat-linux.  Ok for master (or GCC 13 in case this doesn't
> > fit
> > stage4 criteria)?
> 
> I'd prefer to defer this to GCC 13 at this point.
> Furthermore, does the linker then actually merge the constants with
> the same constants from other mergeable linkonce sections or other
> mergeable sections?  I'm afraid it would only merge constants within
> each comdat group and not across the whole ELF object.
> 
> Jakub
> 

I experimented with this a little, and actually having a reloc prevents
merging altogether (the check happens in _bfd_add_merge_section).

I get a .LASANPC reloc there in the first place because of
https://patchwork.ozlabs.org/project/gcc/patch/20190702085154.26981-1-...@linux.ibm.com/
but of course it may happen for other reasons as well.

Re: [PATCH] middle-end/104492 - avoid all equality compare dangling pointer diags

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 27, 2022 at 11:56:55AM +0200, Richard Biener wrote:
> Bootstrapped & tested on x86_64-unknown-linux-gnu.
> 
> OK?

I think a testcase from the #c0 of the PR would be nice, but it can
be added incrementally, so ok for trunk and unless somebody beats me
to it, I'll try to reduce the testcase.  With a fixed and unfixed compiler
around it might be easier for reduction.

Jakub

Re: [PATCH] middle-end/104492 - avoid all equality compare dangling pointer diags

[Richard Biener via Gcc-patches]

On Wed, 27 Apr 2022, Jakub Jelinek wrote:

> On Wed, Apr 27, 2022 at 11:56:55AM +0200, Richard Biener wrote:
> > Bootstrapped & tested on x86_64-unknown-linux-gnu.
> > 
> > OK?
> 
> I think a testcase from the #c0 of the PR would be nice, but it can
> be added incrementally, so ok for trunk and unless somebody beats me
> to it, I'll try to reduce the testcase.  With a fixed and unfixed compiler
> around it might be easier for reduction.

I did that but the reduction result did not resemble the same failure
mode.  I've failed to manually construct a testcase as well.  Possibly
a testcase using libstdc++ but less Qt internals might be possible.

Thanks,
Richard.

Re: [PATCH] Honor COMDAT for mergeable constant sections

[Ilya Leoshkevich via Gcc-patches]

On Wed, 2022-04-27 at 11:59 +0200, Ilya Leoshkevich via Gcc-patches
wrote:
> On Wed, 2022-04-27 at 11:33 +0200, Jakub Jelinek wrote:
> > On Wed, Apr 27, 2022 at 11:27:49AM +0200, Ilya Leoshkevich via Gcc-
> > patches wrote:
> > > Bootstrapped and regtested on x86_64-redhat-linux and
> > > s390x-redhat-linux.  Ok for master (or GCC 13 in case this
> > > doesn't
> > > fit
> > > stage4 criteria)?
> > 
> > I'd prefer to defer this to GCC 13 at this point.
> > Furthermore, does the linker then actually merge the constants with
> > the same constants from other mergeable linkonce sections or other
> > mergeable sections?  I'm afraid it would only merge constants
> > within
> > each comdat group and not across the whole ELF object.
> > 
> > Jakub
> > 
> 
> I experimented with this a little, and actually having a reloc
> prevents
> merging altogether (the check happens in _bfd_add_merge_section).
> 
> I get a .LASANPC reloc there in the first place because of
> https://patchwork.ozlabs.org/project/gcc/patch/20190702085154.26981-1-...@linux.ibm.com/
> but of course it may happen for other reasons as well.

I just realized I forgot to mention the "normal" case.
There, "aMG" seems to works fine with the whole ELF:

$ cat 1.s
.globl _start
_start:
ret
.section .rodata.xxx,"aMG",@progbits,8,.xxx,comdat
.quad 42

$ cat 2.s
.section .rodata.yyy,"aMG",@progbits,8,.yyy,comdat
.quad 42
.quad 43
.section .rodata.xxx,"aMG",@progbits,8,.xxx,comdat
.quad 42

$ gcc -nostartfiles -fPIE 1.s 2.s
$ objdump -D a.out

2000 <.rodata>:
2000:   2a 00   sub(%rax),%al
2002:   00 00   add%al,(%rax)
2004:   00 00   add%al,(%rax)
2006:   00 00   add%al,(%rax)
2008:   2b 00   sub(%rax),%eax
200a:   00 00   add%al,(%rax)
200c:   00 00   add%al,(%rax)
...

[PATCH] testsuite: Add test case for pack/unpack bifs at soft-float [PR105334]

[Kewen.Lin via Gcc-patches]

Hi,

As discussed in PR105334, this patch is to add the test coverage for
the two recent fixes r12-8091 and r12-8226 from Segher, aix is skipped
since it takes soft-float and long-double-128 incompatible.

I noticed the referred test case pack02.c skips if powerpc*-*-darwin*,
but it's for do-run and I didn't have one machine to test that triple,
so I didn't add that and hope it's unnecessary.

Tested on powerpc64-linux-gnu P8, powerpc64le-linux-gnu P9/P10 and
powerpc-ibm-aix7.2.0.0.

Is ok for trunk?

BR,
Kewen
-
gcc/testsuite/ChangeLog:

PR target/105334
* gcc.target/powerpc/pr105334.c: New test.
---
 gcc/testsuite/gcc.target/powerpc/pr105334.c | 31 +
 1 file changed, 31 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr105334.c

diff --git a/gcc/testsuite/gcc.target/powerpc/pr105334.c 
b/gcc/testsuite/gcc.target/powerpc/pr105334.c
new file mode 100644
index 000..7664e033dd0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr105334.c
@@ -0,0 +1,31 @@
+/* Skip this on aix, since it takes soft-float and long-double-128
+   incompatible and warns it.  */
+/* { dg-skip-if "aix long-double-128 soft-float" { powerpc*-*-aix* } } */
+/* { dg-options "-mlong-double-128 -msoft-float" } */
+
+/* Verify there is no ICE.  */
+
+#include 
+#include 
+#include 
+
+#define PACK __builtin_pack_ibm128
+#define UNPACK __builtin_unpack_ibm128
+#define LDOUBLE __ibm128
+
+extern LDOUBLE bar (LDOUBLE);
+
+int
+main (void)
+{
+  double high = pow (2.0, 60);
+  double low = 2.0;
+  LDOUBLE a = ((LDOUBLE) high) + ((LDOUBLE) low);
+  double x0 = UNPACK (a, 0);
+  double x1 = UNPACK (a, 1);
+  LDOUBLE b = PACK (x0, x1);
+  LDOUBLE c = bar (b);
+
+  return c > a;
+}
+
--
2.27.0

Re: [PATCH] vect, tree-optimization/105219: Disable epilogue vectorization when peeling for alignment

[Richard Biener via Gcc-patches]

On Wed, 27 Apr 2022, Richard Biener wrote:

> On Tue, 26 Apr 2022, Richard Sandiford wrote:
> 
> > "Andre Vieira (lists)"  writes:
> > > Hi,
> > >
> > > This patch disables epilogue vectorization when we are peeling for 
> > > alignment in the prologue and we can't guarantee the main vectorized 
> > > loop is entered.  This is to prevent executing vectorized code with an 
> > > unaligned access if the target has indicated it wants to peel for 
> > > alignment. We take this conservative approach as we currently do not 
> > > distinguish between peeling for alignment for correctness or for 
> > > performance.
> > >
> > > A better codegen would be to make it skip to the scalar epilogue in case 
> > > the main loop isn't entered when alignment peeling is required. However, 
> > > that would require a more aggressive change to the codebase which we 
> > > chose to avoid at this point of development.  We can revisit this option 
> > > during stage 1 if we choose to.
> > >
> > > Bootstrapped on aarch64-none-linux and regression tested on 
> > > aarch64-none-elf.
> > >
> > > gcc/ChangeLog:
> > >
> > >      PR tree-optimization/105219
> > >      * tree-vect-loop.cc (vect_epilogue_when_peeling_for_alignment): New 
> > > function.
> > >      (vect_analyze_loop): Use vect_epilogue_when_peeling_for_alignment 
> > > to determine
> > >      whether to vectorize epilogue.
> > >      * testsuite/gcc.target/aarch64/pr105219.c: New.
> > >      * testsuite/gcc.target/aarch64/pr105219-2.c: New.
> > >      * testsuite/gcc.target/aarch64/pr105219-3.c: New.
> > >
> > > diff --git a/gcc/testsuite/gcc.target/aarch64/pr105219-2.c 
> > > b/gcc/testsuite/gcc.target/aarch64/pr105219-2.c
> > > new file mode 100644
> > > index 
> > > ..c97d1dc100181b77af0766e08407e1e352f604fe
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/aarch64/pr105219-2.c
> > > @@ -0,0 +1,29 @@
> > > +/* { dg-do run } */
> > > +/* { dg-options "-O3 -march=armv8.2-a -mtune=thunderx 
> > > -fno-vect-cost-model" } */
> > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-march=*" } { 
> > > "-march=armv8.2-a" } } */
> > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-mtune=*" } { 
> > > "-mtune=thunderx" } } */
> > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-mcpu=*" } } */
> > 
> > I think this should be in gcc.dg/vect, with the options forced
> > for { target aarch64 }.
> > 
> > Are the skips necessary?  It looks like the test should work correctly
> > for all options/targets.
> > 
> > > +/* PR 105219.  */
> > > +int data[128];
> > > +
> > > +void __attribute((noipa))
> > > +foo (int *data, int n)
> > > +{
> > > +  for (int i = 0; i < n; ++i)
> > > +data[i] = i;
> > > +}
> > > +
> > > +int main()
> > > +{
> > > +  for (int start = 0; start < 16; ++start)
> > > +for (int n = 1; n < 3*16; ++n)
> > > +  {
> > > +__builtin_memset (data, 0, sizeof (data));
> > > +foo (&data[start], n);
> > > +for (int j = 0; j < n; ++j)
> > > +  if (data[start + j] != j)
> > > +__builtin_abort ();
> > > +  }
> > > +  return 0;
> > > +}
> > > +
> > > diff --git a/gcc/testsuite/gcc.target/aarch64/pr105219-3.c 
> > > b/gcc/testsuite/gcc.target/aarch64/pr105219-3.c
> > > new file mode 100644
> > > index 
> > > ..444352fc051b787369f6f1be6236d1ff0fc2d392
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/aarch64/pr105219-3.c
> > > @@ -0,0 +1,15 @@
> > > +/* { dg-do compile } */
> > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-march=*" } { 
> > > "-march=armv8.2-a" } } */
> > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-mtune=*" } { 
> > > "-mtune=thunderx" } } */
> > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-mcpu=*" } } */
> > > +/* { dg-options "-O3 -march=armv8.2-a -mtune=thunderx 
> > > -fno-vect-cost-model -fdump-tree-vect-all" } */
> > > +/* PR 105219.  */
> > > +int data[128];
> > > +
> > > +void foo (void)
> > > +{
> > > +  for (int i = 0; i < 9; ++i)
> > > +data[i + 1] = i;
> > > +}
> > > +
> > > +/* { dg-final { scan-tree-dump "EPILOGUE VECTORIZED" "vect" } } */
> > > diff --git a/gcc/testsuite/gcc.target/aarch64/pr105219.c 
> > > b/gcc/testsuite/gcc.target/aarch64/pr105219.c
> > > new file mode 100644
> > > index 
> > > ..bbdefb549f6a4e803852f69d20ce1ef9152a526c
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/aarch64/pr105219.c
> > > @@ -0,0 +1,28 @@
> > > +/* { dg-do run { target aarch64_sve128_hw } } */
> > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-march=*" } { 
> > > "-march=armv8.2-a+sve" } } */
> > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-mtune=*" } { 
> > > "-mtune=thunderx" } } */
> > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-mcpu=*" } } */
> > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-msve-vector-bits=*" 
> > > } { "-msve-vector-bits=128" } } */
> > > +/* { 

Re: [PATCH] vect, tree-optimization/105219: Disable epilogue vectorization when peeling for alignment

[Richard Biener via Gcc-patches]

On Wed, 27 Apr 2022, Richard Biener wrote:

> On Wed, 27 Apr 2022, Richard Biener wrote:
> 
> > On Tue, 26 Apr 2022, Richard Sandiford wrote:
> > 
> > > "Andre Vieira (lists)"  writes:
> > > > Hi,
> > > >
> > > > This patch disables epilogue vectorization when we are peeling for 
> > > > alignment in the prologue and we can't guarantee the main vectorized 
> > > > loop is entered.  This is to prevent executing vectorized code with an 
> > > > unaligned access if the target has indicated it wants to peel for 
> > > > alignment. We take this conservative approach as we currently do not 
> > > > distinguish between peeling for alignment for correctness or for 
> > > > performance.
> > > >
> > > > A better codegen would be to make it skip to the scalar epilogue in 
> > > > case 
> > > > the main loop isn't entered when alignment peeling is required. 
> > > > However, 
> > > > that would require a more aggressive change to the codebase which we 
> > > > chose to avoid at this point of development.  We can revisit this 
> > > > option 
> > > > during stage 1 if we choose to.
> > > >
> > > > Bootstrapped on aarch64-none-linux and regression tested on 
> > > > aarch64-none-elf.
> > > >
> > > > gcc/ChangeLog:
> > > >
> > > >      PR tree-optimization/105219
> > > >      * tree-vect-loop.cc (vect_epilogue_when_peeling_for_alignment): 
> > > > New 
> > > > function.
> > > >      (vect_analyze_loop): Use vect_epilogue_when_peeling_for_alignment 
> > > > to determine
> > > >      whether to vectorize epilogue.
> > > >      * testsuite/gcc.target/aarch64/pr105219.c: New.
> > > >      * testsuite/gcc.target/aarch64/pr105219-2.c: New.
> > > >      * testsuite/gcc.target/aarch64/pr105219-3.c: New.
> > > >
> > > > diff --git a/gcc/testsuite/gcc.target/aarch64/pr105219-2.c 
> > > > b/gcc/testsuite/gcc.target/aarch64/pr105219-2.c
> > > > new file mode 100644
> > > > index 
> > > > ..c97d1dc100181b77af0766e08407e1e352f604fe
> > > > --- /dev/null
> > > > +++ b/gcc/testsuite/gcc.target/aarch64/pr105219-2.c
> > > > @@ -0,0 +1,29 @@
> > > > +/* { dg-do run } */
> > > > +/* { dg-options "-O3 -march=armv8.2-a -mtune=thunderx 
> > > > -fno-vect-cost-model" } */
> > > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-march=*" } { 
> > > > "-march=armv8.2-a" } } */
> > > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-mtune=*" } { 
> > > > "-mtune=thunderx" } } */
> > > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-mcpu=*" } } */
> > > 
> > > I think this should be in gcc.dg/vect, with the options forced
> > > for { target aarch64 }.
> > > 
> > > Are the skips necessary?  It looks like the test should work correctly
> > > for all options/targets.
> > > 
> > > > +/* PR 105219.  */
> > > > +int data[128];
> > > > +
> > > > +void __attribute((noipa))
> > > > +foo (int *data, int n)
> > > > +{
> > > > +  for (int i = 0; i < n; ++i)
> > > > +data[i] = i;
> > > > +}
> > > > +
> > > > +int main()
> > > > +{
> > > > +  for (int start = 0; start < 16; ++start)
> > > > +for (int n = 1; n < 3*16; ++n)
> > > > +  {
> > > > +__builtin_memset (data, 0, sizeof (data));
> > > > +foo (&data[start], n);
> > > > +for (int j = 0; j < n; ++j)
> > > > +  if (data[start + j] != j)
> > > > +__builtin_abort ();
> > > > +  }
> > > > +  return 0;
> > > > +}
> > > > +
> > > > diff --git a/gcc/testsuite/gcc.target/aarch64/pr105219-3.c 
> > > > b/gcc/testsuite/gcc.target/aarch64/pr105219-3.c
> > > > new file mode 100644
> > > > index 
> > > > ..444352fc051b787369f6f1be6236d1ff0fc2d392
> > > > --- /dev/null
> > > > +++ b/gcc/testsuite/gcc.target/aarch64/pr105219-3.c
> > > > @@ -0,0 +1,15 @@
> > > > +/* { dg-do compile } */
> > > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-march=*" } { 
> > > > "-march=armv8.2-a" } } */
> > > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-mtune=*" } { 
> > > > "-mtune=thunderx" } } */
> > > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-mcpu=*" } } */
> > > > +/* { dg-options "-O3 -march=armv8.2-a -mtune=thunderx 
> > > > -fno-vect-cost-model -fdump-tree-vect-all" } */
> > > > +/* PR 105219.  */
> > > > +int data[128];
> > > > +
> > > > +void foo (void)
> > > > +{
> > > > +  for (int i = 0; i < 9; ++i)
> > > > +data[i + 1] = i;
> > > > +}
> > > > +
> > > > +/* { dg-final { scan-tree-dump "EPILOGUE VECTORIZED" "vect" } } */
> > > > diff --git a/gcc/testsuite/gcc.target/aarch64/pr105219.c 
> > > > b/gcc/testsuite/gcc.target/aarch64/pr105219.c
> > > > new file mode 100644
> > > > index 
> > > > ..bbdefb549f6a4e803852f69d20ce1ef9152a526c
> > > > --- /dev/null
> > > > +++ b/gcc/testsuite/gcc.target/aarch64/pr105219.c
> > > > @@ -0,0 +1,28 @@
> > > > +/* { dg-do run { target aarch64_sve128_hw } } */
> > > > +/* { dg-skip-if "incompatible options" { *-*-* } { "-march=*" } { 
> > > > "-march=armv8.2-a+sve" }

[PATCH v2] loongarch: ignore zero-size fields in calling convention

[Xi Ruoyao via Gcc-patches]

On Wed, 2022-04-27 at 14:57 +0800, Lulu Cheng wrote:

> I think the modification should be below.
> > > 
> > > >  if (!TYPE_P (TREE_TYPE (f))) 
> > > >     return -1;

I think (!TYPE_P (TREE_TYPE (f)) will never be true (the code handling
calling convention of other ports does not has this check).  But "first
thing first" so I'll move the change below this for now.

gcc/

* config/loongarch/loongarch.cc
(loongarch_flatten_aggregate_field): Ignore empty fields for
RECORD_TYPE.

gcc/testsuite/

* gcc.target/loongarch/zero-size-field-pass.c: New test.
* gcc.target/loongarch/zero-size-field-ret.c: New test.
---
 gcc/config/loongarch/loongarch.cc |  3 ++
 .../loongarch/zero-size-field-pass.c  | 30 +++
 .../loongarch/zero-size-field-ret.c   | 28 +
 3 files changed, 61 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index f22150a60cc..80046b64006 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -329,6 +329,9 @@ loongarch_flatten_aggregate_field (const_tree type,
if (!TYPE_P (TREE_TYPE (f)))
  return -1;
 
+   if (DECL_SIZE (f) && integer_zerop (DECL_SIZE (f)))
+ continue;
+
HOST_WIDE_INT pos = offset + int_byte_position (f);
n = loongarch_flatten_aggregate_field (TREE_TYPE (f), fields, n,
   pos);
diff --git a/gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c 
b/gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c
new file mode 100644
index 000..999dc913a71
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c
@@ -0,0 +1,30 @@
+/* Test that LoongArch backend ignores zero-sized fields of aggregates in
+   argument passing.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O2 -mdouble-float -mabi=lp64d" } */
+/* { dg-final { scan-assembler "\\\$f1" } } */
+
+struct test
+{
+  int empty1[0];
+  double empty2[0];
+  int : 0;
+  float x;
+  long empty3[0];
+  long : 0;
+  float y;
+  unsigned : 0;
+  char empty4[0];
+};
+
+extern void callee (struct test);
+
+void
+caller (void)
+{
+  struct test test;
+  test.x = 114;
+  test.y = 514;
+  callee (test);
+}
diff --git a/gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c 
b/gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c
new file mode 100644
index 000..40137d97555
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c
@@ -0,0 +1,28 @@
+/* Test that LoongArch backend ignores zero-sized fields of aggregates in
+   returning.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O2 -mdouble-float -mabi=lp64d" } */
+/* { dg-final { scan-assembler-not "\\\$r4" } } */
+
+struct test
+{
+  int empty1[0];
+  double empty2[0];
+  int : 0;
+  float x;
+  long empty3[0];
+  long : 0;
+  float y;
+  unsigned : 0;
+  char empty4[0];
+};
+
+extern struct test callee (void);
+
+float
+caller (void)
+{
+  struct test test = callee ();
+  return test.x + test.y;
+}
-- 
2.36.0

Re: [PATCH v2] loongarch: ignore zero-size fields in calling convention

[Lulu Cheng]

OK!

在 2022/4/27 下午7:45, Xi Ruoyao 写道:

On Wed, 2022-04-27 at 14:57 +0800, Lulu Cheng wrote:


I think the modification should be below.

  if (!TYPE_P (TREE_TYPE (f)))
     return -1;

I think (!TYPE_P (TREE_TYPE (f)) will never be true (the code handling
calling convention of other ports does not has this check).  But "first
thing first" so I'll move the change below this for now.

gcc/

* config/loongarch/loongarch.cc
(loongarch_flatten_aggregate_field): Ignore empty fields for
RECORD_TYPE.

gcc/testsuite/

* gcc.target/loongarch/zero-size-field-pass.c: New test.
* gcc.target/loongarch/zero-size-field-ret.c: New test.
---
  gcc/config/loongarch/loongarch.cc |  3 ++
  .../loongarch/zero-size-field-pass.c  | 30 +++
  .../loongarch/zero-size-field-ret.c   | 28 +
  3 files changed, 61 insertions(+)
  create mode 100644 gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c
  create mode 100644 gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index f22150a60cc..80046b64006 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -329,6 +329,9 @@ loongarch_flatten_aggregate_field (const_tree type,
if (!TYPE_P (TREE_TYPE (f)))
  return -1;
  
+	if (DECL_SIZE (f) && integer_zerop (DECL_SIZE (f)))

+ continue;
+
HOST_WIDE_INT pos = offset + int_byte_position (f);
n = loongarch_flatten_aggregate_field (TREE_TYPE (f), fields, n,
   pos);
diff --git a/gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c 
b/gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c
new file mode 100644
index 000..999dc913a71
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c
@@ -0,0 +1,30 @@
+/* Test that LoongArch backend ignores zero-sized fields of aggregates in
+   argument passing.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O2 -mdouble-float -mabi=lp64d" } */
+/* { dg-final { scan-assembler "\\\$f1" } } */
+
+struct test
+{
+  int empty1[0];
+  double empty2[0];
+  int : 0;
+  float x;
+  long empty3[0];
+  long : 0;
+  float y;
+  unsigned : 0;
+  char empty4[0];
+};
+
+extern void callee (struct test);
+
+void
+caller (void)
+{
+  struct test test;
+  test.x = 114;
+  test.y = 514;
+  callee (test);
+}
diff --git a/gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c 
b/gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c
new file mode 100644
index 000..40137d97555
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c
@@ -0,0 +1,28 @@
+/* Test that LoongArch backend ignores zero-sized fields of aggregates in
+   returning.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O2 -mdouble-float -mabi=lp64d" } */
+/* { dg-final { scan-assembler-not "\\\$r4" } } */
+
+struct test
+{
+  int empty1[0];
+  double empty2[0];
+  int : 0;
+  float x;
+  long empty3[0];
+  long : 0;
+  float y;
+  unsigned : 0;
+  char empty4[0];
+};
+
+extern struct test callee (void);
+
+float
+caller (void)
+{
+  struct test test = callee ();
+  return test.x + test.y;
+}

[PATCH] tree-optimization/105219 - bogus max iters for vectorized epilogue

[Richard Biener via Gcc-patches]

The following makes sure to take into account prologue peeling
when trying to narrow down the maximum number of iterations
computed for the epilogue of a vectorized epilogue.

Bootstrap & regtest running on x86_64-unknown-linux-gnu.

I did not verify this solves the original aarch64 testcase yet
but it looks like a simpler fix and explains why I don't see
the issue on the 11 branch which does otherwise the same transforms.

Richard.

2022-04-27  Richard Biener  

PR tree-optimization/105219
* tree-vect-loop.cc (vect_transform_loop): Disable
special code narrowing the vectorized epilogue epilogue
max iterations when peeling for alignment was in effect.

* gcc.dg/vect/pr105219.c: New testcase.
---
 gcc/testsuite/gcc.dg/vect/pr105219.c | 29 
 gcc/tree-vect-loop.cc|  2 +-
 2 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr105219.c

diff --git a/gcc/testsuite/gcc.dg/vect/pr105219.c 
b/gcc/testsuite/gcc.dg/vect/pr105219.c
new file mode 100644
index 000..0cb7ae2f4d6
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr105219.c
@@ -0,0 +1,29 @@
+/* { dg-do run } */
+/* { dg-additional-options "-O3" } */
+/* { dg-additional-options "-mtune=intel" { target x86_64-*-* i?86-*-* } } */
+
+#include "tree-vect.h"
+
+int data[128];
+
+void __attribute((noipa))
+foo (int *data, int n)
+{
+  for (int i = 0; i < n; ++i)
+data[i] = i;
+}
+
+int main()
+{
+  check_vect ();
+  for (int start = 0; start < 16; ++start)
+for (int n = 1; n < 3*16; ++n)
+  {
+__builtin_memset (data, 0, sizeof (data));
+foo (&data[start], n);
+for (int j = 0; j < n; ++j)
+  if (data[start + j] != j)
+__builtin_abort ();
+  }
+  return 0;
+}
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index d7bc34636bd..217abab814b 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -9977,7 +9977,7 @@ vect_transform_loop (loop_vec_info loop_vinfo, gimple 
*loop_vectorized_call)
lowest_vf) - 1
   : wi::udiv_floor (loop->nb_iterations_upper_bound + bias_for_lowest,
 lowest_vf) - 1);
-  if (main_vinfo)
+  if (main_vinfo && !main_vinfo->peeling_for_alignment)
{
  unsigned int bound;
  poly_uint64 main_iters
-- 
2.34.1

Re: [PATCH] testsuite: Add test case for pack/unpack bifs at soft-float [PR105334]

[Segher Boessenkool]

Hi!

Thank you for doing this testcase.

On Wed, Apr 27, 2022 at 06:29:07PM +0800, Kewen.Lin wrote:
> As discussed in PR105334, this patch is to add the test coverage for
> the two recent fixes r12-8091 and r12-8226 from Segher, aix is skipped
> since it takes soft-float and long-double-128 incompatible.
> 
> I noticed the referred test case pack02.c skips if powerpc*-*-darwin*,
> but it's for do-run and I didn't have one machine to test that triple,
> so I didn't add that and hope it's unnecessary.

That is the best thing to do if you aren't sure, the Darwin people are
in a much better position to decide this themselves.  Cc:ed Iain.

> Tested on powerpc64-linux-gnu P8, powerpc64le-linux-gnu P9/P10 and
> powerpc-ibm-aix7.2.0.0.
> 
> Is ok for trunk?

Okay for trunk, thanks!  Please see if David has some more input?

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr105334.c
> @@ -0,0 +1,31 @@
> +/* Skip this on aix, since it takes soft-float and long-double-128
> +   incompatible and warns it.  */
> +/* { dg-skip-if "aix long-double-128 soft-float" { powerpc*-*-aix* } } */
> +/* { dg-options "-mlong-double-128 -msoft-float" } */

Maybe you just want to add "-w" and not skip on AIX, if the test
generates the correct code anyway?  Either way works for me though.


Segher

Re: [PATCH] Honor COMDAT for mergeable constant sections

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 27, 2022 at 11:59:49AM +0200, Ilya Leoshkevich wrote:
> I get a .LASANPC reloc there in the first place because of
> https://patchwork.ozlabs.org/project/gcc/patch/20190702085154.26981-1-...@linux.ibm.com/
> but of course it may happen for other reasons as well.

In that case I don't see any benefit to put that into a mergeable section.
Why does that happen?

Jakub

Re: [PATCH] c++: enum in generic lambda at global scope [PR105398]

[Patrick Palka via Gcc-patches]

On Tue, 26 Apr 2022, Marek Polacek via Gcc-patches wrote:

> We crash compiling this test since r11-7993 which changed
> lookup_template_class_1 so that we only call tsubst_enum when
> 
>   !uses_template_parms (current_nonlambda_scope ())
> 
> But here current_nonlambda_scope () is the global NAMESPACE_DECL ::, which
> doesn't have a type, therefore is considered type-dependent.  So we don't
> call tsubst_enum, and crash in tsubst_copy/CONST_DECL because we didn't
> find the e1 enumerator.
> 
> I don't think any namespace can depend on any template parameter, so
> this patch tweaks uses_template_parms.
> 
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11?
> 
>   PR c++/105398
> 
> gcc/cp/ChangeLog:
> 
>   * pt.cc (uses_template_parms): Return false for any NAMESPACE_DECL.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/cpp1y/lambda-generic-enum2.C: New test.
> ---
>  gcc/cp/pt.cc  |  2 +-
>  gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum2.C | 15 +++
>  2 files changed, 16 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum2.C
> 
> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> index 3cf1d7af8d2..e785c5db142 100644
> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -10905,7 +10905,7 @@ uses_template_parms (tree t)
>  || uses_template_parms (TREE_CHAIN (t)));
>else if (TREE_CODE (t) == TYPE_DECL)
>  dependent_p = dependent_type_p (TREE_TYPE (t));
> -  else if (t == error_mark_node)
> +  else if (t == error_mark_node || TREE_CODE (t) == NAMESPACE_DECL)

LGTM.  In passing, perhaps we should move this t == error_mark_node test
to the beginning of the function alongside the t == NULL_TREE test?

>  dependent_p = false;
>else
>  dependent_p = instantiation_dependent_expression_p (t);
> diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum2.C 
> b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum2.C
> new file mode 100644
> index 000..77cf0bb9d02
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum2.C
> @@ -0,0 +1,15 @@
> +// PR c++/105398
> +// { dg-do compile { target c++14 } }
> +
> +auto f = [](auto &&m) {
> +enum E { _,e3,e2,e1,C4,C3,C2,C1 };
> +static constexpr int x_coeffs[3][4] = {
> +{e1,C2,C3,C4},
> +{e2,C1,C3,C4},
> +{e3,C1,C2,C4},
> +};
> +};
> +
> +int main() {
> +f(0);
> +}
> 
> base-commit: 9ace5d4dab2ab39072b0f07089621a823580f27c
> -- 
> 2.35.1
> 
> 

[PATCH] ada: Fix build for RTEMS

[Sebastian Huber]

Commit 621cccba3f8b0cd2757feda171e66e3820b55c2c broke the Ada build for all
RTEMS targets except aarch64.

gcc/ada/

* tracebak.c: Add support for ARM RTEMS. Add support for RTEMS to PPC
ELF.  Add support for RTEMS to SPARC.  Merge aarch64 support of Linux
and RTEMS.
---
 gcc/ada/tracebak.c | 32 ++--
 1 file changed, 14 insertions(+), 18 deletions(-)

diff --git a/gcc/ada/tracebak.c b/gcc/ada/tracebak.c
index 54e547d2414..6cc5d301737 100644
--- a/gcc/ada/tracebak.c
+++ b/gcc/ada/tracebak.c
@@ -316,6 +316,13 @@ __gnat_backtrace (void **array,
 #define PC_ADJUST -2
 #define USING_ARM_UNWINDING 1
 
+/*-- ARM RTEMS  -*/
+#elif (defined (__arm__) && defined (__rtems__))
+
+#define USE_GCC_UNWINDER
+#define PC_ADJUST -2
+#define USING_ARM_UNWINDING 1
+
 /*-- PPC AIX/PPC Lynx 178/Older Darwin --*/
 #elif ((defined (_POWER) && defined (_AIX)) || \
(defined (__powerpc__) && defined (__Lynx__) && !defined(__ELF__)) || \
@@ -370,11 +377,12 @@ extern void __runnit(); /* thread entry point.  */
 
 #define BASE_SKIP 1
 
-/*--- PPC ELF (GNU/Linux & VxWorks & Lynx178e) ---*/
+/*--- PPC ELF (GNU/Linux & VxWorks & Lynx178e & RTEMS ) --*/
 
 #elif (defined (_ARCH_PPC) && defined (__vxworks)) ||  \
   (defined (__powerpc__) && defined (__Lynx__) && defined(__ELF__)) || \
-  (defined (__linux__) && defined (__powerpc__))
+  (defined (__linux__) && defined (__powerpc__)) || \
+  (defined (__powerpc__) && defined (__rtems__))
 
 #if defined (_ARCH_PPC64) && !defined (__USING_SJLJ_EXCEPTIONS__)
 #define USE_GCC_UNWINDER
@@ -404,9 +412,9 @@ struct layout
 
 #define BASE_SKIP 1
 
-/*-- SPARC Solaris -*/
+/*-- SPARC Solaris or RTEMS */
 
-#elif defined (__sun__) && defined (__sparc__)
+#elif (defined (__sun__) || defined (__rtems__)) && defined (__sparc__)
 
 #define USE_GENERIC_UNWINDER
 
@@ -551,21 +559,9 @@ is_return_from(void *symbol_addr, void *ret_addr)
 #error Unhandled QNX architecture.
 #endif
 
-/* RTEMS -*/
-
-#elif defined (__rtems__)
-
-#define USE_GCC_UNWINDER
-
-#if defined (__aarch64__)
-#define PC_ADJUST -4
-#else
-#error Unhandled RTEMS architecture.
-#endif
-
-/*--- aarch64-linux --*/
+/*--- aarch64-linux or aarch64-rtems -*/
 
-#elif (defined (__aarch64__) && defined (__linux__))
+#elif (defined (__aarch64__) && (defined (__linux__) || defined (__rtems__)))
 
 #define USE_GCC_UNWINDER
 #define PC_ADJUST -4
-- 
2.34.1

Re: [PATCH] ada: Fix build for RTEMS

[Arnaud Charlet via Gcc-patches]

This patch is OK, thank you and sorry for the breakage!

Arno

> Commit 621cccba3f8b0cd2757feda171e66e3820b55c2c broke the Ada build for all
> RTEMS targets except aarch64.
> 
> gcc/ada/
> 
>* tracebak.c: Add support for ARM RTEMS. Add support for RTEMS to PPC
>ELF.  Add support for RTEMS to SPARC.  Merge aarch64 support of Linux
>and RTEMS.
> ---
> gcc/ada/tracebak.c | 32 ++--
> 1 file changed, 14 insertions(+), 18 deletions(-)
> 
> diff --git a/gcc/ada/tracebak.c b/gcc/ada/tracebak.c
> index 54e547d2414..6cc5d301737 100644
> --- a/gcc/ada/tracebak.c
> +++ b/gcc/ada/tracebak.c
> @@ -316,6 +316,13 @@ __gnat_backtrace (void **array,
> #define PC_ADJUST -2
> #define USING_ARM_UNWINDING 1
> 
> +/*-- ARM RTEMS  -*/
> +#elif (defined (__arm__) && defined (__rtems__))
> +
> +#define USE_GCC_UNWINDER
> +#define PC_ADJUST -2
> +#define USING_ARM_UNWINDING 1
> +
> /*-- PPC AIX/PPC Lynx 178/Older Darwin --*/
> #elif ((defined (_POWER) && defined (_AIX)) || \
>(defined (__powerpc__) && defined (__Lynx__) && !defined(__ELF__)) || \
> @@ -370,11 +377,12 @@ extern void __runnit(); /* thread entry point.  */
> 
> #define BASE_SKIP 1
> 
> -/*--- PPC ELF (GNU/Linux & VxWorks & Lynx178e) ---*/
> +/*--- PPC ELF (GNU/Linux & VxWorks & Lynx178e & RTEMS ) --*/
> 
> #elif (defined (_ARCH_PPC) && defined (__vxworks)) ||  \
>   (defined (__powerpc__) && defined (__Lynx__) && defined(__ELF__)) || \
> -  (defined (__linux__) && defined (__powerpc__))
> +  (defined (__linux__) && defined (__powerpc__)) || \
> +  (defined (__powerpc__) && defined (__rtems__))
> 
> #if defined (_ARCH_PPC64) && !defined (__USING_SJLJ_EXCEPTIONS__)
> #define USE_GCC_UNWINDER
> @@ -404,9 +412,9 @@ struct layout
> 
> #define BASE_SKIP 1
> 
> -/*-- SPARC Solaris -*/
> +/*-- SPARC Solaris or RTEMS */
> 
> -#elif defined (__sun__) && defined (__sparc__)
> +#elif (defined (__sun__) || defined (__rtems__)) && defined (__sparc__)
> 
> #define USE_GENERIC_UNWINDER
> 
> @@ -551,21 +559,9 @@ is_return_from(void *symbol_addr, void *ret_addr)
> #error Unhandled QNX architecture.
> #endif
> 
> -/* RTEMS -*/
> -
> -#elif defined (__rtems__)
> -
> -#define USE_GCC_UNWINDER
> -
> -#if defined (__aarch64__)
> -#define PC_ADJUST -4
> -#else
> -#error Unhandled RTEMS architecture.
> -#endif
> -
> -/*--- aarch64-linux --*/
> +/*--- aarch64-linux or aarch64-rtems -*/
> 
> -#elif (defined (__aarch64__) && defined (__linux__))
> +#elif (defined (__aarch64__) && (defined (__linux__) || defined (__rtems__)))
> 
> #define USE_GCC_UNWINDER
> #define PC_ADJUST -4
> -- 
> 2.34.1
> 

Re: [PATCH] Honor COMDAT for mergeable constant sections

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 27, 2022 at 02:23:00PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 27, 2022 at 11:59:49AM +0200, Ilya Leoshkevich wrote:
> > I get a .LASANPC reloc there in the first place because of
> > https://patchwork.ozlabs.org/project/gcc/patch/20190702085154.26981-1-...@linux.ibm.com/
> > but of course it may happen for other reasons as well.
> 
> In that case I don't see any benefit to put that into a mergeable section.
> Why does that happen?

Because, when a mergeable section doesn't contain any relocations, I don't
see any point in making it comdat.  Because mergeable sections themselves
are garbage collected, if some constant isn't referenced at all, it isn't
emitted, or if referenced, multiple copies of the constant are merged (or
for mergeable strings even string tail merging is performed).

Jakub

Re: [PATCH] testsuite: Add test case for pack/unpack bifs at soft-float [PR105334]

[David Edelsohn via Gcc-patches]

On Wed, Apr 27, 2022 at 8:22 AM Segher Boessenkool
 wrote:
>
> Hi!
>
> Thank you for doing this testcase.
>
> On Wed, Apr 27, 2022 at 06:29:07PM +0800, Kewen.Lin wrote:
> > As discussed in PR105334, this patch is to add the test coverage for
> > the two recent fixes r12-8091 and r12-8226 from Segher, aix is skipped
> > since it takes soft-float and long-double-128 incompatible.
> >
> > I noticed the referred test case pack02.c skips if powerpc*-*-darwin*,
> > but it's for do-run and I didn't have one machine to test that triple,
> > so I didn't add that and hope it's unnecessary.
>
> That is the best thing to do if you aren't sure, the Darwin people are
> in a much better position to decide this themselves.  Cc:ed Iain.
>
> > Tested on powerpc64-linux-gnu P8, powerpc64le-linux-gnu P9/P10 and
> > powerpc-ibm-aix7.2.0.0.
> >
> > Is ok for trunk?
>
> Okay for trunk, thanks!  Please see if David has some more input?
>
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/powerpc/pr105334.c
> > @@ -0,0 +1,31 @@
> > +/* Skip this on aix, since it takes soft-float and long-double-128
> > +   incompatible and warns it.  */
> > +/* { dg-skip-if "aix long-double-128 soft-float" { powerpc*-*-aix* } } */
> > +/* { dg-options "-mlong-double-128 -msoft-float" } */
>
> Maybe you just want to add "-w" and not skip on AIX, if the test
> generates the correct code anyway?  Either way works for me though.

The additional libgcc functions for ibm128 weren't added to the AIX
configuration.  And it' not clear that soft-float on AIX is
interesting anyway.

Thanks, David

Re: [PATCH] c++: enum in generic lambda at global scope [PR105398]

[Marek Polacek via Gcc-patches]

On Wed, Apr 27, 2022 at 08:24:54AM -0400, Patrick Palka wrote:
> On Tue, 26 Apr 2022, Marek Polacek via Gcc-patches wrote:
> 
> > We crash compiling this test since r11-7993 which changed
> > lookup_template_class_1 so that we only call tsubst_enum when
> > 
> >   !uses_template_parms (current_nonlambda_scope ())
> > 
> > But here current_nonlambda_scope () is the global NAMESPACE_DECL ::, which
> > doesn't have a type, therefore is considered type-dependent.  So we don't
> > call tsubst_enum, and crash in tsubst_copy/CONST_DECL because we didn't
> > find the e1 enumerator.
> > 
> > I don't think any namespace can depend on any template parameter, so
> > this patch tweaks uses_template_parms.
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11?
> > 
> > PR c++/105398
> > 
> > gcc/cp/ChangeLog:
> > 
> > * pt.cc (uses_template_parms): Return false for any NAMESPACE_DECL.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/cpp1y/lambda-generic-enum2.C: New test.
> > ---
> >  gcc/cp/pt.cc  |  2 +-
> >  gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum2.C | 15 +++
> >  2 files changed, 16 insertions(+), 1 deletion(-)
> >  create mode 100644 gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum2.C
> > 
> > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > index 3cf1d7af8d2..e785c5db142 100644
> > --- a/gcc/cp/pt.cc
> > +++ b/gcc/cp/pt.cc
> > @@ -10905,7 +10905,7 @@ uses_template_parms (tree t)
> >|| uses_template_parms (TREE_CHAIN (t)));
> >else if (TREE_CODE (t) == TYPE_DECL)
> >  dependent_p = dependent_type_p (TREE_TYPE (t));
> > -  else if (t == error_mark_node)
> > +  else if (t == error_mark_node || TREE_CODE (t) == NAMESPACE_DECL)
> 
> LGTM.  In passing, perhaps we should move this t == error_mark_node test
> to the beginning of the function alongside the t == NULL_TREE test?

Thanks, yeah, maybe.  I also don't like the separate declaration of
saved_processing_template_decl, the return type, but I've resisted cleaning
that up, otherwise I never know when to stop.  But here's a version with more
cleanups:

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index e9a3d09ac4c..d0ebbb7a196 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7311,7 +7311,7 @@ extern tree lookup_template_class (tree, tree, 
tree, tree,
 int, tsubst_flags_t);
 extern tree lookup_template_function   (tree, tree);
 extern tree lookup_template_variable   (tree, tree);
-extern int uses_template_parms (tree);
+extern bool uses_template_parms(tree);
 extern bool uses_template_parms_level  (tree, int);
 extern bool in_template_function   (void);
 extern bool need_generic_capture   (void);
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 3cf1d7af8d2..dc5b9938f2c 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -10884,35 +10884,30 @@ find_template_parameters (tree t, tree ctx_parms)
 
 /* Returns true if T depends on any template parameter.  */
 
-int
+bool
 uses_template_parms (tree t)
 {
-  if (t == NULL_TREE)
+  if (t == NULL_TREE || t == error_mark_node)
 return false;
 
-  bool dependent_p;
-  int saved_processing_template_decl;
+  /* Namespaces can't depend on any template parameters.  */
+  if (TREE_CODE (t) == NAMESPACE_DECL)
+return false;
+
+  processing_template_decl_sentinel ptds (/*reset*/false);
+  ++processing_template_decl;
 
-  saved_processing_template_decl = processing_template_decl;
-  if (!saved_processing_template_decl)
-processing_template_decl = 1;
   if (TYPE_P (t))
-dependent_p = dependent_type_p (t);
+return dependent_type_p (t);
   else if (TREE_CODE (t) == TREE_VEC)
-dependent_p = any_dependent_template_arguments_p (t);
+return any_dependent_template_arguments_p (t);
   else if (TREE_CODE (t) == TREE_LIST)
-dependent_p = (uses_template_parms (TREE_VALUE (t))
-  || uses_template_parms (TREE_CHAIN (t)));
+return (uses_template_parms (TREE_VALUE (t))
+   || uses_template_parms (TREE_CHAIN (t)));
   else if (TREE_CODE (t) == TYPE_DECL)
-dependent_p = dependent_type_p (TREE_TYPE (t));
-  else if (t == error_mark_node)
-dependent_p = false;
+return dependent_type_p (TREE_TYPE (t));
   else
-dependent_p = instantiation_dependent_expression_p (t);
-
-  processing_template_decl = saved_processing_template_decl;
-
-  return dependent_p;
+return instantiation_dependent_expression_p (t);
 }
 
 /* Returns true iff we're processing an incompletely instantiated function


Maybe go with the original patch for GCC 12 and leave the cleanups for GCC 13?

Marek

Re: [PATCH] vect, tree-optimization/105219: Disable epilogue vectorization when peeling for alignment

[Andre Vieira (lists) via Gcc-patches]

On 27/04/2022 07:35, Richard Biener wrote:

On Tue, 26 Apr 2022, Richard Sandiford wrote:


"Andre Vieira (lists)"  writes:

Hi,

This patch disables epilogue vectorization when we are peeling for
alignment in the prologue and we can't guarantee the main vectorized
loop is entered.  This is to prevent executing vectorized code with an
unaligned access if the target has indicated it wants to peel for
alignment. We take this conservative approach as we currently do not
distinguish between peeling for alignment for correctness or for
performance.

A better codegen would be to make it skip to the scalar epilogue in case
the main loop isn't entered when alignment peeling is required. However,
that would require a more aggressive change to the codebase which we
chose to avoid at this point of development.  We can revisit this option
during stage 1 if we choose to.

Bootstrapped on aarch64-none-linux and regression tested on
aarch64-none-elf.

gcc/ChangeLog:

      PR tree-optimization/105219
      * tree-vect-loop.cc (vect_epilogue_when_peeling_for_alignment): New
function.
      (vect_analyze_loop): Use vect_epilogue_when_peeling_for_alignment
to determine
      whether to vectorize epilogue.
      * testsuite/gcc.target/aarch64/pr105219.c: New.
      * testsuite/gcc.target/aarch64/pr105219-2.c: New.
      * testsuite/gcc.target/aarch64/pr105219-3.c: New.

diff --git a/gcc/testsuite/gcc.target/aarch64/pr105219-2.c 
b/gcc/testsuite/gcc.target/aarch64/pr105219-2.c
new file mode 100644
index 
..c97d1dc100181b77af0766e08407e1e352f604fe
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr105219-2.c
@@ -0,0 +1,29 @@
+/* { dg-do run } */
+/* { dg-options "-O3 -march=armv8.2-a -mtune=thunderx -fno-vect-cost-model" } 
*/
+/* { dg-skip-if "incompatible options" { *-*-* } { "-march=*" } { 
"-march=armv8.2-a" } } */
+/* { dg-skip-if "incompatible options" { *-*-* } { "-mtune=*" } { 
"-mtune=thunderx" } } */
+/* { dg-skip-if "incompatible options" { *-*-* } { "-mcpu=*" } } */

I think this should be in gcc.dg/vect, with the options forced
for { target aarch64 }.

Are the skips necessary?  It looks like the test should work correctly
for all options/targets.


+/* PR 105219.  */
+int data[128];
+
+void __attribute((noipa))
+foo (int *data, int n)
+{
+  for (int i = 0; i < n; ++i)
+data[i] = i;
+}
+
+int main()
+{
+  for (int start = 0; start < 16; ++start)
+for (int n = 1; n < 3*16; ++n)
+  {
+__builtin_memset (data, 0, sizeof (data));
+foo (&data[start], n);
+for (int j = 0; j < n; ++j)
+  if (data[start + j] != j)
+__builtin_abort ();
+  }
+  return 0;
+}
+
diff --git a/gcc/testsuite/gcc.target/aarch64/pr105219-3.c 
b/gcc/testsuite/gcc.target/aarch64/pr105219-3.c
new file mode 100644
index 
..444352fc051b787369f6f1be6236d1ff0fc2d392
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr105219-3.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-skip-if "incompatible options" { *-*-* } { "-march=*" } { 
"-march=armv8.2-a" } } */
+/* { dg-skip-if "incompatible options" { *-*-* } { "-mtune=*" } { 
"-mtune=thunderx" } } */
+/* { dg-skip-if "incompatible options" { *-*-* } { "-mcpu=*" } } */
+/* { dg-options "-O3 -march=armv8.2-a -mtune=thunderx -fno-vect-cost-model 
-fdump-tree-vect-all" } */
+/* PR 105219.  */
+int data[128];
+
+void foo (void)
+{
+  for (int i = 0; i < 9; ++i)
+data[i + 1] = i;
+}
+
+/* { dg-final { scan-tree-dump "EPILOGUE VECTORIZED" "vect" } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/pr105219.c 
b/gcc/testsuite/gcc.target/aarch64/pr105219.c
new file mode 100644
index 
..bbdefb549f6a4e803852f69d20ce1ef9152a526c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr105219.c
@@ -0,0 +1,28 @@
+/* { dg-do run { target aarch64_sve128_hw } } */
+/* { dg-skip-if "incompatible options" { *-*-* } { "-march=*" } { 
"-march=armv8.2-a+sve" } } */
+/* { dg-skip-if "incompatible options" { *-*-* } { "-mtune=*" } { 
"-mtune=thunderx" } } */
+/* { dg-skip-if "incompatible options" { *-*-* } { "-mcpu=*" } } */
+/* { dg-skip-if "incompatible options" { *-*-* } { "-msve-vector-bits=*" } { 
"-msve-vector-bits=128" } } */
+/* { dg-options "-O3 -march=armv8.2-a+sve -msve-vector-bits=128 
-mtune=thunderx" } */

Same here.


+/* PR 105219.  */
+int a;
+char b[60];
+short c[18];
+short d[4][19];
+long long f;
+void e(int g, int h, short k[][19]) {
+  for (signed i = 0; i < 3; i += 2)
+for (signed j = 1; j < h + 14; j++) {
+  b[i * 14 + j] = 1;
+  c[i + j] = k[2][j];
+  a = g ? k[i][j] : 0;
+}
+}
+int main() {
+  e(9, 1, d);
+  for (long l = 0; l < 6; ++l)
+for (long m = 0; m < 4; ++m)
+  f ^= b[l + m * 4];
+  if (f)
+__builtin_abort ();
+}
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 
d7bc34636bd52b2f67cdecd3dc16fcff684dba07..a23e6181dec8126bcb691ea9474095bf65483863
 100644
--- a/g

Re: [PATCH] tree-optimization/105219 - bogus max iters for vectorized epilogue

[Richard Biener via Gcc-patches]

On Wed, 27 Apr 2022, Richard Biener wrote:

> The following makes sure to take into account prologue peeling
> when trying to narrow down the maximum number of iterations
> computed for the epilogue of a vectorized epilogue.
> 
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
> 
> I did not verify this solves the original aarch64 testcase yet
> but it looks like a simpler fix and explains why I don't see
> the issue on the 11 branch which does otherwise the same transforms.

So the following also includes ->peeling_for_gaps which should have
a similar issue.  We discussed being more precise here but I think
we should do this as followup during stage1.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

Can you verify the original aarch64 case is fixed and maybe add
a testcase for that to gcc.target/aarch64?

OK for trunk?

Thanks,
Richard.
>From 03f437c9b2d5260888535e0dad570daee694e4b3 Mon Sep 17 00:00:00 2001
From: Richard Biener 
Date: Wed, 27 Apr 2022 14:06:12 +0200
Subject: [PATCH] tree-optimization/105219 - bogus max iters for vectorized
 epilogue
To: gcc-patches@gcc.gnu.org

The following makes sure to take into account prologue peeling
when trying to narrow down the maximum number of iterations
computed for the vectorized epilogue.  A similar issue exists when
peeling for gaps.

2022-04-27  Richard Biener  

PR tree-optimization/105219
* tree-vect-loop.cc (vect_transform_loop): Disable
special code narrowing the vectorized epilogue max
iterations when peeling for alignment or gaps was in effect.

* gcc.dg/vect/pr105219.c: New testcase.
---
 gcc/testsuite/gcc.dg/vect/pr105219.c | 29 
 gcc/tree-vect-loop.cc|  6 +-
 2 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr105219.c

diff --git a/gcc/testsuite/gcc.dg/vect/pr105219.c 
b/gcc/testsuite/gcc.dg/vect/pr105219.c
new file mode 100644
index 000..0cb7ae2f4d6
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr105219.c
@@ -0,0 +1,29 @@
+/* { dg-do run } */
+/* { dg-additional-options "-O3" } */
+/* { dg-additional-options "-mtune=intel" { target x86_64-*-* i?86-*-* } } */
+
+#include "tree-vect.h"
+
+int data[128];
+
+void __attribute((noipa))
+foo (int *data, int n)
+{
+  for (int i = 0; i < n; ++i)
+data[i] = i;
+}
+
+int main()
+{
+  check_vect ();
+  for (int start = 0; start < 16; ++start)
+for (int n = 1; n < 3*16; ++n)
+  {
+__builtin_memset (data, 0, sizeof (data));
+foo (&data[start], n);
+for (int j = 0; j < n; ++j)
+  if (data[start + j] != j)
+__builtin_abort ();
+  }
+  return 0;
+}
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index d7bc34636bd..f53a634a390 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -9977,7 +9977,11 @@ vect_transform_loop (loop_vec_info loop_vinfo, gimple 
*loop_vectorized_call)
lowest_vf) - 1
   : wi::udiv_floor (loop->nb_iterations_upper_bound + bias_for_lowest,
 lowest_vf) - 1);
-  if (main_vinfo)
+  if (main_vinfo
+ /* Both peeling for alignment and peeling for gaps can end up
+with the scalar epilogue running for more than VF-1 iterations.  */
+ && !main_vinfo->peeling_for_alignment
+ && !main_vinfo->peeling_for_gaps)
{
  unsigned int bound;
  poly_uint64 main_iters
-- 
2.34.1

Re: [PATCH] vect, tree-optimization/105219: Disable epilogue vectorization when peeling for alignment

[Richard Biener via Gcc-patches]

On Wed, 27 Apr 2022, Andre Vieira (lists) wrote:

> 
> On 27/04/2022 07:35, Richard Biener wrote:
> > On Tue, 26 Apr 2022, Richard Sandiford wrote:
> >
> >> "Andre Vieira (lists)"  writes:
> >>> Hi,
> >>>
> >>> This patch disables epilogue vectorization when we are peeling for
> >>> alignment in the prologue and we can't guarantee the main vectorized
> >>> loop is entered.  This is to prevent executing vectorized code with an
> >>> unaligned access if the target has indicated it wants to peel for
> >>> alignment. We take this conservative approach as we currently do not
> >>> distinguish between peeling for alignment for correctness or for
> >>> performance.
> >>>
> >>> A better codegen would be to make it skip to the scalar epilogue in case
> >>> the main loop isn't entered when alignment peeling is required. However,
> >>> that would require a more aggressive change to the codebase which we
> >>> chose to avoid at this point of development.  We can revisit this option
> >>> during stage 1 if we choose to.
> >>>
> >>> Bootstrapped on aarch64-none-linux and regression tested on
> >>> aarch64-none-elf.
> >>>
> >>> gcc/ChangeLog:
> >>>
> >>>       PR tree-optimization/105219
> >>>       * tree-vect-loop.cc (vect_epilogue_when_peeling_for_alignment): New
> >>> function.
> >>>       (vect_analyze_loop): Use vect_epilogue_when_peeling_for_alignment
> >>> to determine
> >>>       whether to vectorize epilogue.
> >>>       * testsuite/gcc.target/aarch64/pr105219.c: New.
> >>>       * testsuite/gcc.target/aarch64/pr105219-2.c: New.
> >>>       * testsuite/gcc.target/aarch64/pr105219-3.c: New.
> >>>
> >>> diff --git a/gcc/testsuite/gcc.target/aarch64/pr105219-2.c
> >>> b/gcc/testsuite/gcc.target/aarch64/pr105219-2.c
> >>> new file mode 100644
> >>> index
> >>> ..c97d1dc100181b77af0766e08407e1e352f604fe
> >>> --- /dev/null
> >>> +++ b/gcc/testsuite/gcc.target/aarch64/pr105219-2.c
> >>> @@ -0,0 +1,29 @@
> >>> +/* { dg-do run } */
> >>> +/* { dg-options "-O3 -march=armv8.2-a -mtune=thunderx
> >>> -fno-vect-cost-model" } */
> >>> +/* { dg-skip-if "incompatible options" { *-*-* } { "-march=*" } {
> >>> "-march=armv8.2-a" } } */
> >>> +/* { dg-skip-if "incompatible options" { *-*-* } { "-mtune=*" } {
> >>> "-mtune=thunderx" } } */
> >>> +/* { dg-skip-if "incompatible options" { *-*-* } { "-mcpu=*" } } */
> >> I think this should be in gcc.dg/vect, with the options forced
> >> for { target aarch64 }.
> >>
> >> Are the skips necessary?  It looks like the test should work correctly
> >> for all options/targets.
> >>
> >>> +/* PR 105219.  */
> >>> +int data[128];
> >>> +
> >>> +void __attribute((noipa))
> >>> +foo (int *data, int n)
> >>> +{
> >>> +  for (int i = 0; i < n; ++i)
> >>> +data[i] = i;
> >>> +}
> >>> +
> >>> +int main()
> >>> +{
> >>> +  for (int start = 0; start < 16; ++start)
> >>> +for (int n = 1; n < 3*16; ++n)
> >>> +  {
> >>> +__builtin_memset (data, 0, sizeof (data));
> >>> +foo (&data[start], n);
> >>> +for (int j = 0; j < n; ++j)
> >>> +  if (data[start + j] != j)
> >>> +__builtin_abort ();
> >>> +  }
> >>> +  return 0;
> >>> +}
> >>> +
> >>> diff --git a/gcc/testsuite/gcc.target/aarch64/pr105219-3.c
> >>> b/gcc/testsuite/gcc.target/aarch64/pr105219-3.c
> >>> new file mode 100644
> >>> index
> >>> ..444352fc051b787369f6f1be6236d1ff0fc2d392
> >>> --- /dev/null
> >>> +++ b/gcc/testsuite/gcc.target/aarch64/pr105219-3.c
> >>> @@ -0,0 +1,15 @@
> >>> +/* { dg-do compile } */
> >>> +/* { dg-skip-if "incompatible options" { *-*-* } { "-march=*" } {
> >>> "-march=armv8.2-a" } } */
> >>> +/* { dg-skip-if "incompatible options" { *-*-* } { "-mtune=*" } {
> >>> "-mtune=thunderx" } } */
> >>> +/* { dg-skip-if "incompatible options" { *-*-* } { "-mcpu=*" } } */
> >>> +/* { dg-options "-O3 -march=armv8.2-a -mtune=thunderx
> >>> -fno-vect-cost-model -fdump-tree-vect-all" } */
> >>> +/* PR 105219.  */
> >>> +int data[128];
> >>> +
> >>> +void foo (void)
> >>> +{
> >>> +  for (int i = 0; i < 9; ++i)
> >>> +data[i + 1] = i;
> >>> +}
> >>> +
> >>> +/* { dg-final { scan-tree-dump "EPILOGUE VECTORIZED" "vect" } } */
> >>> diff --git a/gcc/testsuite/gcc.target/aarch64/pr105219.c
> >>> b/gcc/testsuite/gcc.target/aarch64/pr105219.c
> >>> new file mode 100644
> >>> index
> >>> ..bbdefb549f6a4e803852f69d20ce1ef9152a526c
> >>> --- /dev/null
> >>> +++ b/gcc/testsuite/gcc.target/aarch64/pr105219.c
> >>> @@ -0,0 +1,28 @@
> >>> +/* { dg-do run { target aarch64_sve128_hw } } */
> >>> +/* { dg-skip-if "incompatible options" { *-*-* } { "-march=*" } {
> >>> "-march=armv8.2-a+sve" } } */
> >>> +/* { dg-skip-if "incompatible options" { *-*-* } { "-mtune=*" } {
> >>> "-mtune=thunderx" } } */
> >>> +/* { dg-skip-if "incompatible options" { *-*-* } { "-mcpu=*" } } */
> >>> +/* { dg-skip-if "incompatible options" { *-*-* } { "-msve-vector-bits=*"
> >>> } { "-msve-

[PATCH] libstdc++: Update {x86_64,i?86,aarch64,s390x,ppc{,64,64le}} baseline_symbols.txt

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch updates baseline_symbols.txt on arches where I have
latest libstdc++ builds (my ws + Fedora package builds).
I've manually excluded:
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
additions on ppc64le as those look unexpected.
Those symbols didn't show up in Fedora 11.3.1 build with recent glibc,
while other GLIBCXX_IEEE128_3.4.29 symbols are in 11.x already.

What this patch includes are only @@GLIBCXX_3.4.30 symbol additions, same
symbols on all files, except that powerpc64 adds also
_ZNSt17__gnu_cxx_ieee12816__convert_from_vERKP15__locale_structPciPKcz@@GLIBCXX_IEEE128_3.4.30
so everything included in the patch looks right to me.

Ok for trunk?

2022-04-27  Jakub Jelinek  

* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt: Update.

--- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt.jj   
2021-04-17 11:31:24.889646366 +0200
+++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt  
2022-04-27 15:42:58.207916058 +0200
@@ -475,6 +475,7 @@ FUNC:_ZNKSt10moneypunctIwLb1EE8groupingE
 FUNC:_ZNKSt10ostrstream5rdbufEv@@GLIBCXX_3.4
 FUNC:_ZNKSt10ostrstream6pcountEv@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE15_M_am_pm_formatEPKc@@GLIBCXX_3.4
+FUNC:_ZNKSt11__timepunctIcE15_M_am_pm_formatEPPKc@@GLIBCXX_3.4.30
 FUNC:_ZNKSt11__timepunctIcE15_M_date_formatsEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE15_M_time_formatsEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE19_M_days_abbreviatedEPPKc@@GLIBCXX_3.4
@@ -485,6 +486,7 @@ FUNC:_ZNKSt11__timepunctIcE7_M_daysEPPKc
 FUNC:_ZNKSt11__timepunctIcE8_M_am_pmEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE9_M_monthsEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE15_M_am_pm_formatEPKw@@GLIBCXX_3.4
+FUNC:_ZNKSt11__timepunctIwE15_M_am_pm_formatEPPKw@@GLIBCXX_3.4.30
 FUNC:_ZNKSt11__timepunctIwE15_M_date_formatsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE15_M_time_formatsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE19_M_days_abbreviatedEPPKw@@GLIBCXX_3.4
@@ -954,6 +956,7 @@ FUNC:_ZNKSt7__cxx118time_getIcSt19istrea
 
FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE15_M_extract_nameES4_S4_RiPPKcmRSt8ios_baseRSt12_Ios_Iostate@@GLIBCXX_3.4.21
 
FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE16do_get_monthnameES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tm@@GLIBCXX_3.4.21
 
FUNC:_ZNKSt7__cx

[committed] libstdc++: Add pretty printer for std::atomic

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux, pushed to trunk.

-- >8 --

For the atomic specializations for shared_ptr and weak_ptr we can reuse
the existing SharedPointerPrinter, with a small tweak.

libstdc++-v3/ChangeLog:

* python/libstdcxx/v6/printers.py (SharedPointerPrinter): Add
support for atomic> and atomic>.
(StdAtomicPrinter): New printer.
(build_libstdcxx_dictionary): Register new printer.
* testsuite/libstdc++-prettyprinters/cxx11.cc: Test std::atomic.
* testsuite/libstdc++-prettyprinters/cxx20.cc: Test atomic smart
pointers.
---
 libstdc++-v3/python/libstdcxx/v6/printers.py  | 53 +--
 .../libstdc++-prettyprinters/cxx11.cc | 10 
 .../libstdc++-prettyprinters/cxx20.cc |  9 
 3 files changed, 69 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py 
b/libstdc++-v3/python/libstdcxx/v6/printers.py
index c31134bcdd2..0bd793c0897 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -218,7 +218,7 @@ class SmartPtrIterator(Iterator):
 return ('get()', val)
 
 class SharedPointerPrinter:
-"Print a shared_ptr or weak_ptr"
+"Print a shared_ptr, weak_ptr, atomic, or atomic"
 
 def __init__ (self, typename, val):
 self.typename = strip_versioned_namespace(typename)
@@ -228,9 +228,21 @@ class SharedPointerPrinter:
 def children (self):
 return SmartPtrIterator(self.pointer)
 
+# Return the _Sp_counted_base<>* that holds the refcounts.
+def _get_refcounts (self):
+if self.typename == 'std::atomic':
+# A tagged pointer is stored as uintptr_t.
+ptr_val = self.val['_M_refcount']['_M_val']['_M_i']
+ptr_val = ptr_val - (ptr_val % 2) # clear lock bit
+ptr_type = find_type(self.val['_M_refcount'].type, 'pointer')
+return ptr_val.cast(ptr_type)
+return self.val['_M_refcount']['_M_pi']
+
 def to_string (self):
 state = 'empty'
-refcounts = self.val['_M_refcount']['_M_pi']
+refcounts = self._get_refcounts()
+targ = self.val.type.template_argument(0)
+
 if refcounts != 0:
 usecount = refcounts['_M_use_count']
 weakcount = refcounts['_M_weak_count']
@@ -238,7 +250,7 @@ class SharedPointerPrinter:
 state = 'expired, weak count %d' % weakcount
 else:
 state = 'use count %d, weak count %d' % (usecount, weakcount - 
1)
-return '%s<%s> (%s)' % (self.typename, 
str(self.val.type.template_argument(0)), state)
+return '%s<%s> (%s)' % (self.typename, str(targ), state)
 
 def _tuple_impl_get(val):
 "Return the tuple element stored in a _Tuple_impl base class."
@@ -1708,6 +1720,40 @@ class StdInitializerListPrinter:
 def display_hint(self):
 return 'array'
 
+class StdAtomicPrinter:
+"Print a std:atomic"
+
+def __init__(self, typename, val):
+self.typename = typename
+self.val = val
+self.shptr_printer = None
+self.value_type = self.val.type.template_argument(0)
+if self.value_type.tag is not None:
+typ = strip_versioned_namespace(self.value_type.tag)
+if typ.startswith('std::shared_ptr<') or 
typ.startswith('std::weak_ptr<'):
+impl = val['_M_impl']
+self.shptr_printer = SharedPointerPrinter(typename, impl)
+self.children = self._shptr_children
+
+def _shptr_children(self):
+return SmartPtrIterator(self.shptr_printer.pointer)
+
+def to_string(self):
+if self.shptr_printer is not None:
+return self.shptr_printer.to_string()
+
+if self.value_type.code == gdb.TYPE_CODE_INT:
+val = self.val['_M_i']
+elif self.value_type.code == gdb.TYPE_CODE_FLT:
+val = self.val['_M_fp']
+elif self.value_type.code == gdb.TYPE_CODE_PTR:
+val = self.val['_M_b']['_M_p']
+elif self.value_type.code == gdb.TYPE_CODE_BOOL:
+val = self.val['_M_base']['_M_i']
+else:
+val = self.val['_M_i']
+return '%s<%s> = { %s }' % (self.typename, str(self.value_type), val)
+
 # A "regular expression" printer which conforms to the
 # "SubPrettyPrinter" protocol from gdb.printing.
 class RxPrinter(object):
@@ -2175,6 +2221,7 @@ def build_libstdcxx_dictionary ():
 
 libstdcxx_printer.add_version('std::', 'initializer_list',
   StdInitializerListPrinter)
+libstdcxx_printer.add_version('std::', 'atomic', StdAtomicPrinter)
 
 # std::regex components
 libstdcxx_printer.add_version('std::__detail::', '_State',
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc 
b/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
index 621d13bd062..f97640a0189 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
+++ b/libstd

Re: [PATCH] c++: ICE with temporary of class type in DMI [PR100252]

[Patrick Palka via Gcc-patches]

On Tue, 26 Apr 2022, Marek Polacek wrote:

> Consider
> 
>   struct A {
> int x;
> int y = x;
>   };
> 
>   struct B {
> int x = 0;
> int y = A{x}.y; // #1
>   };
> 
> where for #1 we end up with
> 
>   {.x=(&)->x, .y=(&)->x}
> 
> that is, two PLACEHOLDER_EXPRs for different types on the same level in
> a {}.  This crashes because our CONSTRUCTOR_PLACEHOLDER_BOUNDARY mechanism to
> avoid replacing unrelated PLACEHOLDER_EXPRs cannot deal with it.
> 
> Here's why we wound up with those PLACEHOLDER_EXPRs: When we're performing
> cp_parser_late_parsing_nsdmi for "int y = A{x}.y;" we use 
> finish_compound_literal
> on type=A, compound_literal={((struct B *) this)->x}.  When digesting this
> initializer, we call get_nsdmi which creates a PLACEHOLDER_EXPR for A -- we 
> don't
> have any object to refer to yet.  After digesting, we have
> 
>   {.x=((struct B *) this)->x, .y=(&)->x}
> 
> and since we've created a PLACEHOLDER_EXPR inside it, we marked the whole ctor
> CONSTRUCTOR_PLACEHOLDER_BOUNDARY.  f_c_l creates a TARGET_EXPR and returns
> 
>   TARGET_EXPR x, .y=(& struct A>)->x}>
> 
> Then we get to
> 
>   B b = {};
> 
> and call store_init_value, which digest the {}, which produces
> 
>   {.x=NON_LVALUE_EXPR <0>, .y=(TARGET_EXPR  struct B>)->x, .y=(&)->x}>).y}
> 
> The call to replace_placeholders in store_init_value will not do anything:
> we've marked the inner { } CONSTRUCTOR_PLACEHOLDER_BOUNDARY, and it's only
> a sub-expression, so replace_placeholders does nothing, so the 
> stays even though now is the perfect time to replace it because we have an
> object for it: 'b'.
> 
> Later, in cp_gimplify_init_expr the *expr_p is
> 
>   D.2395 = {.x=(&)->x, .y=(& struct A>)->x}
> 
> where D.2395 is of type A, but we crash because we hit , which
> has a different type.
> 
> My idea was to replace  with D.2384 in f_c_l after creating the
> TARGET_EXPR because that means we have an object we can refer to.  Then clear
> CONSTRUCTOR_PLACEHOLDER_BOUNDARY because we no longer have a PLACEHOLDER_EXPR
> in the {}.  Then store_init_value will be able to replace  with
> 'b', and we should be good to go.

Makes sense to me.  It seems all was well until break_out_target_exprs,
called from get_nsdmi for B::y, replaced the 'this' in the initializer

  (TARGET_EXPR x, .y=(&)->x}>).y;

with a PLACEHOLDER_EXPR;

  (TARGET_EXPR )->x, 
.y=(&)->x}>).y;

This seems to be the wrong thing to do when the 'this' appears inside a
CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructor because the new
PLACEHOLDER_EXPR then can't be resolved correctly.

So in light of this I wonder if we should instead perform this handling
you added to finish_compound_literal in break_out_target_exprs /
bot_manip instead?

> 
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11.4?
> 
>   PR c++/100252
> 
> gcc/cp/ChangeLog:
> 
>   * semantics.cc (finish_compound_literal): replace_placeholders after
>   creating the TARGET_EXPR.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/cpp1y/nsdmi-aggr14.C: New test.
> ---
>  gcc/cp/semantics.cc   | 31 +++
>  gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr14.C | 46 +++
>  2 files changed, 77 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr14.C
> 
> diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
> index ab48f11c9be..770369458bb 100644
> --- a/gcc/cp/semantics.cc
> +++ b/gcc/cp/semantics.cc
> @@ -3296,6 +3296,37 @@ finish_compound_literal (tree type, tree 
> compound_literal,
>if (TREE_CODE (compound_literal) == CONSTRUCTOR)
>   TREE_HAS_CONSTRUCTOR (compound_literal) = false;
>compound_literal = get_target_expr_sfinae (compound_literal, complain);
> +  /* We may have A{} in a NSDMI.  */
> +  if (parsing_nsdmi ())
> + {
> +   /* Digesting the {} could have introduced a PLACEHOLDER_EXPR
> +  referring to A.  Now that we've built up a TARGET_EXPR, we
> +  have an object we can refer to.  The reason we bother doing
> +  this here is for code like
> +
> +struct A {
> +  int x;
> +  int y = x;
> +};
> +
> +struct B {
> +  int x = 0;
> +  int y = A{x}.y; // #1
> +};
> +
> +  where in #1 we don't want to end up with two PLACEHOLDER_EXPRs
> +  for different types on the same level in a {} as in 100252.  */
> +   tree init = TARGET_EXPR_INITIAL (compound_literal);
> +   if (TREE_CODE (init) == CONSTRUCTOR
> +   && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init))
> + {
> +   tree obj = TARGET_EXPR_SLOT (compound_literal);
> +   replace_placeholders (compound_literal, obj);
> +   /* We should have dealt with the PLACEHOLDER_EXPRs.  */
> +   CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = false;
> +   gcc_checking_assert (!find_placeholders (init));
> + }
> + }
>  }
>else
>  /* For e.g

Re: [PATCH] libstdc++: Update {x86_64, i?86, aarch64, s390x, ppc{, 64, 64le}} baseline_symbols.txt

[Jonathan Wakely via Gcc-patches]

On Wed, 27 Apr 2022 at 15:18, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch updates baseline_symbols.txt on arches where I have
> latest libstdc++ builds (my ws + Fedora package builds).
> I've manually excluded:
> +FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
> +FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
> +FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
> +FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
> +FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
> +FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
> +FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
> +FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
> +FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
> +FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
> +FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
> +FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
> additions on ppc64le as those look unexpected.
> Those symbols didn't show up in Fedora 11.3.1 build with recent glibc,
> while other GLIBCXX_IEEE128_3.4.29 symbols are in 11.x already.

I'll figure out what happened here.

> What this patch includes are only @@GLIBCXX_3.4.30 symbol additions, same
> symbols on all files, except that powerpc64 adds also
> _ZNSt17__gnu_cxx_ieee12816__convert_from_vERKP15__locale_structPciPKcz@@GLIBCXX_IEEE128_3.4.30
> so everything included in the patch looks right to me.
>
> Ok for trunk?

OK, thanks.

[PATCH RFA] c-family: attribute ((aligned, mode)) [PR100545]

[Jason Merrill via Gcc-patches]

The problem here was that handle_mode_attribute clobbered the changes of any
previous attribute, only copying type qualifiers to the new type.  And
common_handle_aligned_attribute had previously set up the typedef, so when
we later called set_underlying_type it saw DECL_ORIGINAL_TYPE set and just
returned, even though handle_mode_attribute had messed up the TREE_TYPE.
So, let's fix handle_mode_attribute to copy attributes, alignment, and
typedefness to the new type.

Tested x86_64-pc-linux-gnu, OK for trunk now or after 12.1?

PR c/100545

gcc/c-family/ChangeLog:

* c-attribs.cc (handle_mode_attribute): Copy attributes, aligned,
and typedef.
* c-common.cc (set_underlying_type): Add assert.

gcc/testsuite/ChangeLog:

* c-c++-common/attr-mode-1.c: New test.
---
 gcc/c-family/c-attribs.cc| 15 ++-
 gcc/c-family/c-common.cc |  7 ---
 gcc/testsuite/c-c++-common/attr-mode-1.c |  3 +++
 3 files changed, 21 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/attr-mode-1.c

diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index 111a33f405a..26876d0f309 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -2199,7 +2199,20 @@ handle_mode_attribute (tree *node, tree name, tree args,
  return NULL_TREE;
}
 
-  *node = build_qualified_type (typefm, TYPE_QUALS (type));
+  /* Copy any quals and attributes to the new type.  */
+  *node = build_type_attribute_qual_variant (typefm, TYPE_ATTRIBUTES 
(type),
+TYPE_QUALS (type));
+  if (TYPE_USER_ALIGN (type))
+   *node = build_aligned_type (*node, TYPE_ALIGN (type));
+  if (typedef_variant_p (type))
+   {
+ /* Set up the typedef all over again.  */
+ tree decl = TYPE_NAME (type);
+ DECL_ORIGINAL_TYPE (decl) = NULL_TREE;
+ TREE_TYPE (decl) = *node;
+ set_underlying_type (decl);
+ *node = TREE_TYPE (decl);
+   }
 }
 
   return NULL_TREE;
diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index bb0544eeaea..730faa9e87f 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -8153,15 +8153,16 @@ check_missing_format_attribute (tree ltype, tree rtype)
 void
 set_underlying_type (tree x)
 {
-  if (x == error_mark_node)
+  if (x == error_mark_node || TREE_TYPE (x) == error_mark_node)
 return;
   if (DECL_IS_UNDECLARED_BUILTIN (x) && TREE_CODE (TREE_TYPE (x)) != 
ARRAY_TYPE)
 {
   if (TYPE_NAME (TREE_TYPE (x)) == 0)
TYPE_NAME (TREE_TYPE (x)) = x;
 }
-  else if (TREE_TYPE (x) != error_mark_node
-  && DECL_ORIGINAL_TYPE (x) == NULL_TREE)
+  else if (DECL_ORIGINAL_TYPE (x))
+gcc_checking_assert (TYPE_NAME (TREE_TYPE (x)) == x);
+  else
 {
   tree tt = TREE_TYPE (x);
   DECL_ORIGINAL_TYPE (x) = tt;
diff --git a/gcc/testsuite/c-c++-common/attr-mode-1.c 
b/gcc/testsuite/c-c++-common/attr-mode-1.c
new file mode 100644
index 000..59b20cd99e8
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/attr-mode-1.c
@@ -0,0 +1,3 @@
+// PR c/100545
+
+typedef int fatp_t __attribute__((aligned, mode(SI)));

base-commit: 6a460a2007dd9c527c5f9d5bbbedb852db7c1373
-- 
2.27.0

[PATCH] testsuite: Add testcase for dangling pointer equality bogus warning [PR104492]

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 27, 2022 at 12:02:33PM +0200, Richard Biener wrote:
> On Wed, 27 Apr 2022, Jakub Jelinek wrote:
> 
> > On Wed, Apr 27, 2022 at 11:56:55AM +0200, Richard Biener wrote:
> > > Bootstrapped & tested on x86_64-unknown-linux-gnu.
> > > 
> > > OK?
> > 
> > I think a testcase from the #c0 of the PR would be nice, but it can
> > be added incrementally, so ok for trunk and unless somebody beats me
> > to it, I'll try to reduce the testcase.  With a fixed and unfixed compiler
> > around it might be easier for reduction.
> 
> I did that but the reduction result did not resemble the same failure
> mode.  I've failed to manually construct a testcase as well.  Possibly
> a testcase using libstdc++ but less Qt internals might be possible.

Here is a testcase that I've managed to reduce, FAILs with:
FAIL: g++.dg/warn/pr104492.C  -std=gnu++14  (test for bogus messages, line 111)
FAIL: g++.dg/warn/pr104492.C  -std=gnu++17  (test for bogus messages, line 111)
FAIL: g++.dg/warn/pr104492.C  -std=gnu++20  (test for bogus messages, line 111)
on both x86_64-linux and i686-linux without your commit and passes with it,
ok for trunk?

2022-04-27  Jakub Jelinek  

PR middle-end/104492
* g++.dg/warn/pr104492.C: New test.

--- gcc/testsuite/g++.dg/warn/pr104492.C.jj 2022-04-27 17:40:52.427671414 
+0200
+++ gcc/testsuite/g++.dg/warn/pr104492.C2022-04-27 17:40:12.524214984 
+0200
@@ -0,0 +1,115 @@
+// PR middle-end/104492
+// { dg-do compile { target c++14 } }
+// { dg-options "-O3 -Wall" }
+
+namespace std {
+typedef decltype (sizeof 0) size_t;
+template  struct integral_constant {
+  static constexpr _Tp value = __v;
+};
+template 
+struct is_same : integral_constant {};
+template  struct enable_if;
+template  _Tp forward;
+}
+class QString;
+struct random_access_iterator_tag {};
+template  struct iterator_traits {
+  typedef random_access_iterator_tag iterator_category;
+};
+template 
+typename iterator_traits<_Iter>::iterator_category __iterator_category(_Iter);
+namespace __gnu_cxx {
+namespace __ops {
+template  struct _Iter_equals_val {
+  template  bool operator()(_Iterator);
+};
+template  _Iter_equals_val<_Value> __iter_equals_val(_Value);
+}
+}
+namespace std {
+template 
+_RandomAccessIterator __find_if(_RandomAccessIterator __first,
+   _RandomAccessIterator __last, _Predicate __pred,
+   random_access_iterator_tag) {
+  if (__pred(__first))
+return __first;
+  return __last;
+}
+template 
+_Iterator __find_if(_Iterator __first, _Iterator __last, _Predicate __pred) {
+  return __find_if(__first, __last, __pred, __iterator_category(__first));
+}
+template  _Tp *begin(_Tp (&__arr)[_Nm]) {
+  return __arr;
+}
+template  _Tp *end(_Tp (&__arr)[_Nm]) {
+  return __arr + _Nm;
+}
+template 
+_InputIterator find(_InputIterator __first, _InputIterator __last, _Tp __val) {
+  return __find_if(__first, __last, 
__gnu_cxx::__ops::__iter_equals_val(__val));
+}
+}
+struct QStringView {
+  template 
+  using if_compatible_qstring_like = std::enable_if::value, bool>;
+  template  QStringView(String);
+};
+template  struct QStringTokenizerBase {
+  class sentinel {};
+  struct iterator {
+Haystack operator*();
+iterator operator++(int);
+bool operator!=(sentinel);
+  };
+  iterator begin();
+  template ::value> sentinel end();
+};
+namespace QtPrivate {
+namespace Tok {
+template 
+using TokenizerBase = QStringTokenizerBase;
+}
+}
+template 
+struct QStringTokenizer
+: public QtPrivate::Tok::TokenizerBase {
+  QStringTokenizer(Haystack, Needle);
+};
+namespace QtPrivate {
+namespace Tok {
+template 
+using TokenizerResult = QStringTokenizer;
+}
+}
+template 
+auto qTokenize(Haystack, Needle)
+-> decltype(QtPrivate::Tok::TokenizerResult{
+   std::forward, std::forward});
+struct QLatin1String {
+  QLatin1String(const char *) {}
+};
+class QString {};
+class QLibrary {
+  bool isLibrary(const QString &);
+};
+
+bool QLibrary::isLibrary(const QString &fileName)
+{
+QString completeSuffix = fileName;
+auto isValidSuffix = [](QStringView s) {
+   const QLatin1String candidates[] = {
+   QLatin1String("so"),
+   };
+   return std::find(std::begin(candidates), std::end(candidates), s) != 
std::end(candidates);
+};
+auto suffixes = qTokenize(completeSuffix, u'.');
+auto it = suffixes.begin();
+const auto end = suffixes.end();
+while (it != end) {
+   if (isValidSuffix(*it++))   // { dg-bogus "dangling pointer to 
.candidates. may be used" }
+ return true;
+}
+return false;
+}


Jakub

Re: [PATCH] c++: enum in generic lambda at global scope [PR105398]

[Jason Merrill via Gcc-patches]

On 4/27/22 08:59, Marek Polacek wrote:

On Wed, Apr 27, 2022 at 08:24:54AM -0400, Patrick Palka wrote:

On Tue, 26 Apr 2022, Marek Polacek via Gcc-patches wrote:


We crash compiling this test since r11-7993 which changed
lookup_template_class_1 so that we only call tsubst_enum when

   !uses_template_parms (current_nonlambda_scope ())

But here current_nonlambda_scope () is the global NAMESPACE_DECL ::, which
doesn't have a type, therefore is considered type-dependent.  So we don't
call tsubst_enum, and crash in tsubst_copy/CONST_DECL because we didn't
find the e1 enumerator.

I don't think any namespace can depend on any template parameter, so
this patch tweaks uses_template_parms.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11?

PR c++/105398

gcc/cp/ChangeLog:

* pt.cc (uses_template_parms): Return false for any NAMESPACE_DECL.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/lambda-generic-enum2.C: New test.
---
  gcc/cp/pt.cc  |  2 +-
  gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum2.C | 15 +++
  2 files changed, 16 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum2.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 3cf1d7af8d2..e785c5db142 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -10905,7 +10905,7 @@ uses_template_parms (tree t)
   || uses_template_parms (TREE_CHAIN (t)));
else if (TREE_CODE (t) == TYPE_DECL)
  dependent_p = dependent_type_p (TREE_TYPE (t));
-  else if (t == error_mark_node)
+  else if (t == error_mark_node || TREE_CODE (t) == NAMESPACE_DECL)


LGTM.  In passing, perhaps we should move this t == error_mark_node test
to the beginning of the function alongside the t == NULL_TREE test?


Thanks, yeah, maybe.  I also don't like the separate declaration of
saved_processing_template_decl, the return type, but I've resisted cleaning
that up, otherwise I never know when to stop.  But here's a version with more
cleanups:

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index e9a3d09ac4c..d0ebbb7a196 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7311,7 +7311,7 @@ extern tree lookup_template_class (tree, tree, 
tree, tree,
 int, tsubst_flags_t);
  extern tree lookup_template_function  (tree, tree);
  extern tree lookup_template_variable  (tree, tree);
-extern int uses_template_parms (tree);
+extern bool uses_template_parms(tree);
  extern bool uses_template_parms_level (tree, int);
  extern bool in_template_function  (void);
  extern bool need_generic_capture  (void);
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 3cf1d7af8d2..dc5b9938f2c 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -10884,35 +10884,30 @@ find_template_parameters (tree t, tree ctx_parms)
  
  /* Returns true if T depends on any template parameter.  */
  
-int

+bool
  uses_template_parms (tree t)
  {
-  if (t == NULL_TREE)
+  if (t == NULL_TREE || t == error_mark_node)
  return false;
  
-  bool dependent_p;

-  int saved_processing_template_decl;
+  /* Namespaces can't depend on any template parameters.  */
+  if (TREE_CODE (t) == NAMESPACE_DECL)
+return false;
+
+  processing_template_decl_sentinel ptds (/*reset*/false);
+  ++processing_template_decl;
  
-  saved_processing_template_decl = processing_template_decl;

-  if (!saved_processing_template_decl)
-processing_template_decl = 1;
if (TYPE_P (t))
-dependent_p = dependent_type_p (t);
+return dependent_type_p (t);
else if (TREE_CODE (t) == TREE_VEC)
-dependent_p = any_dependent_template_arguments_p (t);
+return any_dependent_template_arguments_p (t);
else if (TREE_CODE (t) == TREE_LIST)
-dependent_p = (uses_template_parms (TREE_VALUE (t))
-  || uses_template_parms (TREE_CHAIN (t)));
+return (uses_template_parms (TREE_VALUE (t))
+   || uses_template_parms (TREE_CHAIN (t)));
else if (TREE_CODE (t) == TYPE_DECL)
-dependent_p = dependent_type_p (TREE_TYPE (t));
-  else if (t == error_mark_node)
-dependent_p = false;
+return dependent_type_p (TREE_TYPE (t));
else
-dependent_p = instantiation_dependent_expression_p (t);
-
-  processing_template_decl = saved_processing_template_decl;
-
-  return dependent_p;
+return instantiation_dependent_expression_p (t);
  }
  
  /* Returns true iff we're processing an incompletely instantiated function



Maybe go with the original patch for GCC 12 and leave the cleanups for GCC 13?


Sounds good to me.

Jason

Re: [PATCH] testsuite: Add testcase for dangling pointer equality bogus warning [PR104492]

[Richard Biener via Gcc-patches]

> Am 27.04.2022 um 17:46 schrieb Jakub Jelinek :
> 
> On Wed, Apr 27, 2022 at 12:02:33PM +0200, Richard Biener wrote:
>>> On Wed, 27 Apr 2022, Jakub Jelinek wrote:
>>> 
>>> On Wed, Apr 27, 2022 at 11:56:55AM +0200, Richard Biener wrote:
 Bootstrapped & tested on x86_64-unknown-linux-gnu.
 
 OK?
>>> 
>>> I think a testcase from the #c0 of the PR would be nice, but it can
>>> be added incrementally, so ok for trunk and unless somebody beats me
>>> to it, I'll try to reduce the testcase.  With a fixed and unfixed compiler
>>> around it might be easier for reduction.
>> 
>> I did that but the reduction result did not resemble the same failure
>> mode.  I've failed to manually construct a testcase as well.  Possibly
>> a testcase using libstdc++ but less Qt internals might be possible.
> 
> Here is a testcase that I've managed to reduce, FAILs with:
> FAIL: g++.dg/warn/pr104492.C  -std=gnu++14  (test for bogus messages, line 
> 111)
> FAIL: g++.dg/warn/pr104492.C  -std=gnu++17  (test for bogus messages, line 
> 111)
> FAIL: g++.dg/warn/pr104492.C  -std=gnu++20  (test for bogus messages, line 
> 111)
> on both x86_64-linux and i686-linux without your commit and passes with it,
> ok for trunk?

Ok.

Richard 


> 2022-04-27  Jakub Jelinek  
> 
>PR middle-end/104492
>* g++.dg/warn/pr104492.C: New test.
> 
> --- gcc/testsuite/g++.dg/warn/pr104492.C.jj2022-04-27 17:40:52.427671414 
> +0200
> +++ gcc/testsuite/g++.dg/warn/pr104492.C2022-04-27 17:40:12.524214984 
> +0200
> @@ -0,0 +1,115 @@
> +// PR middle-end/104492
> +// { dg-do compile { target c++14 } }
> +// { dg-options "-O3 -Wall" }
> +
> +namespace std {
> +typedef decltype (sizeof 0) size_t;
> +template  struct integral_constant {
> +  static constexpr _Tp value = __v;
> +};
> +template 
> +struct is_same : integral_constant {};
> +template  struct enable_if;
> +template  _Tp forward;
> +}
> +class QString;
> +struct random_access_iterator_tag {};
> +template  struct iterator_traits {
> +  typedef random_access_iterator_tag iterator_category;
> +};
> +template 
> +typename iterator_traits<_Iter>::iterator_category 
> __iterator_category(_Iter);
> +namespace __gnu_cxx {
> +namespace __ops {
> +template  struct _Iter_equals_val {
> +  template  bool operator()(_Iterator);
> +};
> +template  _Iter_equals_val<_Value> 
> __iter_equals_val(_Value);
> +}
> +}
> +namespace std {
> +template 
> +_RandomAccessIterator __find_if(_RandomAccessIterator __first,
> +_RandomAccessIterator __last, _Predicate __pred,
> +random_access_iterator_tag) {
> +  if (__pred(__first))
> +return __first;
> +  return __last;
> +}
> +template 
> +_Iterator __find_if(_Iterator __first, _Iterator __last, _Predicate __pred) {
> +  return __find_if(__first, __last, __pred, __iterator_category(__first));
> +}
> +template  _Tp *begin(_Tp (&__arr)[_Nm]) {
> +  return __arr;
> +}
> +template  _Tp *end(_Tp (&__arr)[_Nm]) {
> +  return __arr + _Nm;
> +}
> +template 
> +_InputIterator find(_InputIterator __first, _InputIterator __last, _Tp 
> __val) {
> +  return __find_if(__first, __last, 
> __gnu_cxx::__ops::__iter_equals_val(__val));
> +}
> +}
> +struct QStringView {
> +  template 
> +  using if_compatible_qstring_like = std::enable_if QString>::value, bool>;
> +  template  QStringView(String);
> +};
> +template  struct QStringTokenizerBase {
> +  class sentinel {};
> +  struct iterator {
> +Haystack operator*();
> +iterator operator++(int);
> +bool operator!=(sentinel);
> +  };
> +  iterator begin();
> +  template ::value> sentinel end();
> +};
> +namespace QtPrivate {
> +namespace Tok {
> +template 
> +using TokenizerBase = QStringTokenizerBase;
> +}
> +}
> +template 
> +struct QStringTokenizer
> +: public QtPrivate::Tok::TokenizerBase {
> +  QStringTokenizer(Haystack, Needle);
> +};
> +namespace QtPrivate {
> +namespace Tok {
> +template 
> +using TokenizerResult = QStringTokenizer;
> +}
> +}
> +template 
> +auto qTokenize(Haystack, Needle)
> +-> decltype(QtPrivate::Tok::TokenizerResult{
> +std::forward, std::forward});
> +struct QLatin1String {
> +  QLatin1String(const char *) {}
> +};
> +class QString {};
> +class QLibrary {
> +  bool isLibrary(const QString &);
> +};
> +
> +bool QLibrary::isLibrary(const QString &fileName)
> +{
> +QString completeSuffix = fileName;
> +auto isValidSuffix = [](QStringView s) {
> +const QLatin1String candidates[] = {
> +QLatin1String("so"),
> +};
> +return std::find(std::begin(candidates), std::end(candidates), s) != 
> std::end(candidates);
> +};
> +auto suffixes = qTokenize(completeSuffix, u'.');
> +auto it = suffixes.begin();
> +const auto end = suffixes.end();
> +while (it != end) {
> +if (isValidSuffix(*it++))// { dg-bogus "dangling pointer to 
> .candidates. may be used" }
> +  return true;
> +}
> +return false;
> +}
> 
> 
>Jakub
> 

Unreviewed D doc patch

[Rainer Orth]

The following patch

doc: Document Solaris D bootstrap requirements [PR 103528]
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591844.html

has remained unreviewed for 6 weeks now, despite a reminder.  It would
be good to get this into GCC 12.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] middle-end/105376 - invalid REAL_CST for DFP constant

[Joseph Myers]

On Wed, 27 Apr 2022, Richard Biener via Gcc-patches wrote:

> Is this the correct strathegy to deal with this problem?  Would
> it be valid to just set ->is_decimal in build_real based on

Just setting ->decimal isn't correct; that signifies that ->sig stores the 
number in decimal128 format (host-endian DPD), so it's only correct for a 
REAL_VALUE_TYPE that actually is encoded in decimal128 format, not one 
copied from dconst*.

I think build_real is a reasonable place to handle the dconst* special 
cases, but it would need to have an explicit mapping from the binary 
dconst* to corresponding constants using the decimal128 format, in the 
case where the REAL_VALUE_TYPE passed in is binary but the requested type 
is decimal.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH RFA] c-family: attribute ((aligned, mode)) [PR100545]

[Marek Polacek via Gcc-patches]

On Wed, Apr 27, 2022 at 11:19:57AM -0400, Jason Merrill via Gcc-patches wrote:
> The problem here was that handle_mode_attribute clobbered the changes of any
> previous attribute, only copying type qualifiers to the new type.  And
> common_handle_aligned_attribute had previously set up the typedef, so when
> we later called set_underlying_type it saw DECL_ORIGINAL_TYPE set and just
> returned, even though handle_mode_attribute had messed up the TREE_TYPE.
> So, let's fix handle_mode_attribute to copy attributes, alignment, and
> typedefness to the new type.
> 
> Tested x86_64-pc-linux-gnu, OK for trunk now or after 12.1?

I think I'd slightly prefer 12.1, it doesn't seem to be a regression.
 
>   PR c/100545
> 
> gcc/c-family/ChangeLog:
> 
>   * c-attribs.cc (handle_mode_attribute): Copy attributes, aligned,
>   and typedef.
>   * c-common.cc (set_underlying_type): Add assert.
> 
> gcc/testsuite/ChangeLog:
> 
>   * c-c++-common/attr-mode-1.c: New test.
> ---
>  gcc/c-family/c-attribs.cc| 15 ++-
>  gcc/c-family/c-common.cc |  7 ---
>  gcc/testsuite/c-c++-common/attr-mode-1.c |  3 +++
>  3 files changed, 21 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/c-c++-common/attr-mode-1.c
> 
> diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
> index 111a33f405a..26876d0f309 100644
> --- a/gcc/c-family/c-attribs.cc
> +++ b/gcc/c-family/c-attribs.cc
> @@ -2199,7 +2199,20 @@ handle_mode_attribute (tree *node, tree name, tree 
> args,
> return NULL_TREE;
>   }
>  
> -  *node = build_qualified_type (typefm, TYPE_QUALS (type));
> +  /* Copy any quals and attributes to the new type.  */
> +  *node = build_type_attribute_qual_variant (typefm, TYPE_ATTRIBUTES 
> (type),
> +  TYPE_QUALS (type));
> +  if (TYPE_USER_ALIGN (type))
> + *node = build_aligned_type (*node, TYPE_ALIGN (type));
> +  if (typedef_variant_p (type))
> + {
> +   /* Set up the typedef all over again.  */
> +   tree decl = TYPE_NAME (type);
> +   DECL_ORIGINAL_TYPE (decl) = NULL_TREE;
> +   TREE_TYPE (decl) = *node;
> +   set_underlying_type (decl);
> +   *node = TREE_TYPE (decl);
> + }
>  }
>  
>return NULL_TREE;
> diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
> index bb0544eeaea..730faa9e87f 100644
> --- a/gcc/c-family/c-common.cc
> +++ b/gcc/c-family/c-common.cc
> @@ -8153,15 +8153,16 @@ check_missing_format_attribute (tree ltype, tree 
> rtype)
>  void
>  set_underlying_type (tree x)
>  {
> -  if (x == error_mark_node)
> +  if (x == error_mark_node || TREE_TYPE (x) == error_mark_node)

Maybe error_operand_p?

>  return;
>if (DECL_IS_UNDECLARED_BUILTIN (x) && TREE_CODE (TREE_TYPE (x)) != 
> ARRAY_TYPE)
>  {
>if (TYPE_NAME (TREE_TYPE (x)) == 0)
>   TYPE_NAME (TREE_TYPE (x)) = x;
>  }
> -  else if (TREE_TYPE (x) != error_mark_node
> -&& DECL_ORIGINAL_TYPE (x) == NULL_TREE)
> +  else if (DECL_ORIGINAL_TYPE (x))
> +gcc_checking_assert (TYPE_NAME (TREE_TYPE (x)) == x);
> +  else
>  {
>tree tt = TREE_TYPE (x);
>DECL_ORIGINAL_TYPE (x) = tt;
> diff --git a/gcc/testsuite/c-c++-common/attr-mode-1.c 
> b/gcc/testsuite/c-c++-common/attr-mode-1.c
> new file mode 100644
> index 000..59b20cd99e8
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/attr-mode-1.c
> @@ -0,0 +1,3 @@
> +// PR c/100545
> +
> +typedef int fatp_t __attribute__((aligned, mode(SI)));

I think you need to add "dg-options -g", otherwise the bug doesn't
manifest.

Marek

Re: [PATCH] c++: enum in generic lambda at global scope [PR105398]

[Marek Polacek via Gcc-patches]

On Wed, Apr 27, 2022 at 11:47:02AM -0400, Jason Merrill wrote:
> On 4/27/22 08:59, Marek Polacek wrote:
> > On Wed, Apr 27, 2022 at 08:24:54AM -0400, Patrick Palka wrote:
> > > On Tue, 26 Apr 2022, Marek Polacek via Gcc-patches wrote:
> > > 
> > > > We crash compiling this test since r11-7993 which changed
> > > > lookup_template_class_1 so that we only call tsubst_enum when
> > > > 
> > > >!uses_template_parms (current_nonlambda_scope ())
> > > > 
> > > > But here current_nonlambda_scope () is the global NAMESPACE_DECL ::, 
> > > > which
> > > > doesn't have a type, therefore is considered type-dependent.  So we 
> > > > don't
> > > > call tsubst_enum, and crash in tsubst_copy/CONST_DECL because we didn't
> > > > find the e1 enumerator.
> > > > 
> > > > I don't think any namespace can depend on any template parameter, so
> > > > this patch tweaks uses_template_parms.
> > > > 
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11?
> > > > 
> > > > PR c++/105398
> > > > 
> > > > gcc/cp/ChangeLog:
> > > > 
> > > > * pt.cc (uses_template_parms): Return false for any 
> > > > NAMESPACE_DECL.
> > > > 
> > > > gcc/testsuite/ChangeLog:
> > > > 
> > > > * g++.dg/cpp1y/lambda-generic-enum2.C: New test.
> > > > ---
> > > >   gcc/cp/pt.cc  |  2 +-
> > > >   gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum2.C | 15 +++
> > > >   2 files changed, 16 insertions(+), 1 deletion(-)
> > > >   create mode 100644 gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum2.C
> > > > 
> > > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > > > index 3cf1d7af8d2..e785c5db142 100644
> > > > --- a/gcc/cp/pt.cc
> > > > +++ b/gcc/cp/pt.cc
> > > > @@ -10905,7 +10905,7 @@ uses_template_parms (tree t)
> > > >|| uses_template_parms (TREE_CHAIN (t)));
> > > > else if (TREE_CODE (t) == TYPE_DECL)
> > > >   dependent_p = dependent_type_p (TREE_TYPE (t));
> > > > -  else if (t == error_mark_node)
> > > > +  else if (t == error_mark_node || TREE_CODE (t) == NAMESPACE_DECL)
> > > 
> > > LGTM.  In passing, perhaps we should move this t == error_mark_node test
> > > to the beginning of the function alongside the t == NULL_TREE test?
> > 
> > Thanks, yeah, maybe.  I also don't like the separate declaration of
> > saved_processing_template_decl, the return type, but I've resisted cleaning
> > that up, otherwise I never know when to stop.  But here's a version with 
> > more
> > cleanups:
> > 
> > diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> > index e9a3d09ac4c..d0ebbb7a196 100644
> > --- a/gcc/cp/cp-tree.h
> > +++ b/gcc/cp/cp-tree.h
> > @@ -7311,7 +7311,7 @@ extern tree lookup_template_class (tree, 
> > tree, tree, tree,
> >  int, tsubst_flags_t);
> >   extern tree lookup_template_function  (tree, tree);
> >   extern tree lookup_template_variable  (tree, tree);
> > -extern int uses_template_parms (tree);
> > +extern bool uses_template_parms(tree);
> >   extern bool uses_template_parms_level (tree, int);
> >   extern bool in_template_function  (void);
> >   extern bool need_generic_capture  (void);
> > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > index 3cf1d7af8d2..dc5b9938f2c 100644
> > --- a/gcc/cp/pt.cc
> > +++ b/gcc/cp/pt.cc
> > @@ -10884,35 +10884,30 @@ find_template_parameters (tree t, tree ctx_parms)
> >   /* Returns true if T depends on any template parameter.  */
> > -int
> > +bool
> >   uses_template_parms (tree t)
> >   {
> > -  if (t == NULL_TREE)
> > +  if (t == NULL_TREE || t == error_mark_node)
> >   return false;
> > -  bool dependent_p;
> > -  int saved_processing_template_decl;
> > +  /* Namespaces can't depend on any template parameters.  */
> > +  if (TREE_CODE (t) == NAMESPACE_DECL)
> > +return false;
> > +
> > +  processing_template_decl_sentinel ptds (/*reset*/false);
> > +  ++processing_template_decl;
> > -  saved_processing_template_decl = processing_template_decl;
> > -  if (!saved_processing_template_decl)
> > -processing_template_decl = 1;
> > if (TYPE_P (t))
> > -dependent_p = dependent_type_p (t);
> > +return dependent_type_p (t);
> > else if (TREE_CODE (t) == TREE_VEC)
> > -dependent_p = any_dependent_template_arguments_p (t);
> > +return any_dependent_template_arguments_p (t);
> > else if (TREE_CODE (t) == TREE_LIST)
> > -dependent_p = (uses_template_parms (TREE_VALUE (t))
> > -  || uses_template_parms (TREE_CHAIN (t)));
> > +return (uses_template_parms (TREE_VALUE (t))
> > +   || uses_template_parms (TREE_CHAIN (t)));
> > else if (TREE_CODE (t) == TYPE_DECL)
> > -dependent_p = dependent_type_p (TREE_TYPE (t));
> > -  else if (t == error_mark_node)
> > -dependent_p = false;
> > +return dependent_type_p (TREE_TYPE (t));
> > else
> > -dependent_p = instantiation_dependent_express

Re: [PATCH] c++: enum in generic lambda at global scope [PR105398]

[Jason Merrill via Gcc-patches]

On 4/27/22 13:00, Marek Polacek wrote:

On Wed, Apr 27, 2022 at 11:47:02AM -0400, Jason Merrill wrote:

On 4/27/22 08:59, Marek Polacek wrote:

On Wed, Apr 27, 2022 at 08:24:54AM -0400, Patrick Palka wrote:

On Tue, 26 Apr 2022, Marek Polacek via Gcc-patches wrote:


We crash compiling this test since r11-7993 which changed
lookup_template_class_1 so that we only call tsubst_enum when

!uses_template_parms (current_nonlambda_scope ())

But here current_nonlambda_scope () is the global NAMESPACE_DECL ::, which
doesn't have a type, therefore is considered type-dependent.  So we don't
call tsubst_enum, and crash in tsubst_copy/CONST_DECL because we didn't
find the e1 enumerator.

I don't think any namespace can depend on any template parameter, so
this patch tweaks uses_template_parms.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11?

PR c++/105398

gcc/cp/ChangeLog:

* pt.cc (uses_template_parms): Return false for any NAMESPACE_DECL.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/lambda-generic-enum2.C: New test.
---
   gcc/cp/pt.cc  |  2 +-
   gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum2.C | 15 +++
   2 files changed, 16 insertions(+), 1 deletion(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp1y/lambda-generic-enum2.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 3cf1d7af8d2..e785c5db142 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -10905,7 +10905,7 @@ uses_template_parms (tree t)
   || uses_template_parms (TREE_CHAIN (t)));
 else if (TREE_CODE (t) == TYPE_DECL)
   dependent_p = dependent_type_p (TREE_TYPE (t));
-  else if (t == error_mark_node)
+  else if (t == error_mark_node || TREE_CODE (t) == NAMESPACE_DECL)


LGTM.  In passing, perhaps we should move this t == error_mark_node test
to the beginning of the function alongside the t == NULL_TREE test?


Thanks, yeah, maybe.  I also don't like the separate declaration of
saved_processing_template_decl, the return type, but I've resisted cleaning
that up, otherwise I never know when to stop.  But here's a version with more
cleanups:

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index e9a3d09ac4c..d0ebbb7a196 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7311,7 +7311,7 @@ extern tree lookup_template_class (tree, tree, 
tree, tree,
 int, tsubst_flags_t);
   extern tree lookup_template_function (tree, tree);
   extern tree lookup_template_variable (tree, tree);
-extern int uses_template_parms (tree);
+extern bool uses_template_parms(tree);
   extern bool uses_template_parms_level(tree, int);
   extern bool in_template_function (void);
   extern bool need_generic_capture (void);
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 3cf1d7af8d2..dc5b9938f2c 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -10884,35 +10884,30 @@ find_template_parameters (tree t, tree ctx_parms)
   /* Returns true if T depends on any template parameter.  */
-int
+bool
   uses_template_parms (tree t)
   {
-  if (t == NULL_TREE)
+  if (t == NULL_TREE || t == error_mark_node)
   return false;
-  bool dependent_p;
-  int saved_processing_template_decl;
+  /* Namespaces can't depend on any template parameters.  */
+  if (TREE_CODE (t) == NAMESPACE_DECL)
+return false;
+
+  processing_template_decl_sentinel ptds (/*reset*/false);
+  ++processing_template_decl;
-  saved_processing_template_decl = processing_template_decl;
-  if (!saved_processing_template_decl)
-processing_template_decl = 1;
 if (TYPE_P (t))
-dependent_p = dependent_type_p (t);
+return dependent_type_p (t);
 else if (TREE_CODE (t) == TREE_VEC)
-dependent_p = any_dependent_template_arguments_p (t);
+return any_dependent_template_arguments_p (t);
 else if (TREE_CODE (t) == TREE_LIST)
-dependent_p = (uses_template_parms (TREE_VALUE (t))
-  || uses_template_parms (TREE_CHAIN (t)));
+return (uses_template_parms (TREE_VALUE (t))
+   || uses_template_parms (TREE_CHAIN (t)));
 else if (TREE_CODE (t) == TYPE_DECL)
-dependent_p = dependent_type_p (TREE_TYPE (t));
-  else if (t == error_mark_node)
-dependent_p = false;
+return dependent_type_p (TREE_TYPE (t));
 else
-dependent_p = instantiation_dependent_expression_p (t);
-
-  processing_template_decl = saved_processing_template_decl;
-
-  return dependent_p;
+return instantiation_dependent_expression_p (t);
   }
   /* Returns true iff we're processing an incompletely instantiated function


Maybe go with the original patch for GCC 12 and leave the cleanups for GCC 13?


Sounds good to me.


Is the original patch OK for trunk then?


Yes.  And the second patch is OK for stage 1.

Jason

Re: [PATCH RFA] c-family: attribute ((aligned, mode)) [PR100545]

[Joseph Myers]

On Wed, 27 Apr 2022, Jason Merrill via Gcc-patches wrote:

> +  if (typedef_variant_p (type))
> + {
> +   /* Set up the typedef all over again.  */

This seems wrong when the typedef is just being used in another 
declaration with the mode attribute, as opposed to being defined using the 
mode attribute.  E.g. the following test is valid and accepted before the 
patch, but wrongly rejected after the patch because the typedef has had 
its type changed.

typedef int I;
int x;
I y __attribute__ ((mode(QI)));
extern I x;

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [OG11-committed][stage1-patch] Fortran: Fix finalization resolution with deep copy (was: [Patch][Stage 1] Fortran/OpenMP: Support mapping of DT with allocatable components)

[Tobias Burnus]

More testing found more issues. Instead of adding more band aid to the
pre-existing band aid, which was extended before, let's try a different
approach:

Just ensure that all component types are resolved (which includes
finalizers) before continuing with the derived type. This also resolves
the finalizers (but also derived-type procedures) before using it in the
_callback vtable entry (with the deep mapping patch) – or in general:
before creating the vtable.

Committed to OG11 – and stashed for mainline. See attachment.

Tobias

PS: With the deep-mapping patch, the vtable of allocatable DT components
is required. Thus, the _callback code generation tries to get the
associated vtable. That in turned triggered the generation of the
DT-component's vtable, which did fail with an assert, unless it either
does not have finalizers or the type has been resolved before.

On 25.04.22 15:47, Tobias Burnus wrote:

Found another issue – applied to OG11 as attached. Will include it in
the mainline patch once Stage1.

(However, I intent to split the original patch (+ follow ups) into
smaller pieces for mainline incorporation.)

Tobias

On 02.03.22 23:20, Tobias Burnus wrote:

Some testing found an issue in class.cc (in the new _callback
function) – updated patch attached (long version + interdiff).

Tobias

(PS: OG11 - original patch was committed as
https://gcc.gnu.org/g:98961d3a0ccb02d7d54d2d4dd07cca75473d685a ;
follow-up version to be committed in a moment)

On 01.03.22 16:34, Tobias Burnus wrote:

Hi all,

this patch adds support for mapping something like
  type t
type(t2), allocatable :: a, b(:)
integer, allocatable :: c, c(:)
  end type t
  type(t), allocatable :: var, var2(:,:)

  !$omp target enter data map(var, var)

which does a deep walk of the components at runtime.

On the ME side, the static addr/size/kinds arrays are
replaced (only if need) by allocatable arrays – which
are then filled by trans-openmp.c.

All deep-mapping handling happens via the hooks called
late in omp-low.c such that removing mappings or implicitly
added one are handled.

In principle, there is also code to handle polymorphic
variables (new callback function in vtable + two on-the-fly
generated functions to be used for walking the vtable).

Issues: None known, but I am sure with experimenting,
more can be found - especially with arrays/array sections
and polymorphism, I expect issues. I did find some on the
way and fixed them - but (see PR refs in testcase -7.f90),
I also found unrelated bugs, which I did not fix ;-)

Comments? OK for mainline (GCC 13)?

Tobias

PS: I will commit this patch to OG11 for further testing.
PPS: Previously discussed at
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586237.html

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit 492ea356ce4b9e40c417b3740cc298d6cc78e870
Author: Tobias Burnus 
Date:   Wed Apr 27 19:44:52 2022 +0200

Fortran: Fix finalization resolution with deep copy (cont)

gcc/fortran/ChangeLog:

* resolve.c (gfc_resolve_finalizers): Remove
gfc_resolve_finalizers calls, use gfc_is_finalizable.
(resolve_fl_derived): Resolve derived-type components
first.

gcc/testsuite/ChangeLog:

* gfortran.dg/abstract_type_6.f03: Remove dg-error as
now hidden by other errors; copy to ...
* gfortran.dg/abstract_type_6a.f03: ... here; remove
some error to diagnose the error.
* gfortran.dg/finalize_39.f90: New test.
---
 gcc/fortran/resolve.c  |  29 ---
 gcc/testsuite/gfortran.dg/abstract_type_6.f03  |   3 +-
 gcc/testsuite/gfortran.dg/abstract_type_6a.f03 |  46 ++
 gcc/testsuite/gfortran.dg/finalize_39.f90  | 112 +
 4 files changed, 177 insertions(+), 13 deletions(-)

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 10c89de0eaa..84a538ee5bc 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -13582,18 +13582,10 @@ gfc_resolve_finalizers (gfc_symbol* derived, bool *finalizable)
  handle allocatables but avoid issues with (in)direct allocatable types. */
   bool has_final = derived->f2k_derived && derived->f2k_derived->finalizers;
   for (c = derived->components; c; c = c->next)
-if (c->ts.type == BT_DERIVED && !c->attr.pointer && !c->attr.proc_pointer
-	&& (!c->attr.allocatable
-	|| (c->ts.u.derived != derived
-		&& c->ts.u.derived->f2k_derived
-		&& c->ts.u.derived->f2k_derived->finalizers
-		&& !c->ts.u.derived->f2k_derived->finalizers->proc_tree)))
-  {
-	bool has_final2 = false;
-	if (!gfc_resolve_finalizers (c->ts.u.derived, &has_final2))
-	  return false;  /* Error.  */
-	has_final = has_final || has_final2;
-  }
+if (c->t

[PATCH v2] c++: ICE with temporary of class type in DMI [PR100252]

[Marek Polacek via Gcc-patches]

On Wed, Apr 27, 2022 at 11:00:46AM -0400, Patrick Palka wrote:
> On Tue, 26 Apr 2022, Marek Polacek wrote:
> 
> > Consider
> > 
> >   struct A {
> > int x;
> > int y = x;
> >   };
> > 
> >   struct B {
> > int x = 0;
> > int y = A{x}.y; // #1
> >   };
> > 
> > where for #1 we end up with
> > 
> >   {.x=(&)->x, .y=(& > A>)->x}
> > 
> > that is, two PLACEHOLDER_EXPRs for different types on the same level in
> > a {}.  This crashes because our CONSTRUCTOR_PLACEHOLDER_BOUNDARY mechanism 
> > to
> > avoid replacing unrelated PLACEHOLDER_EXPRs cannot deal with it.
> > 
> > Here's why we wound up with those PLACEHOLDER_EXPRs: When we're performing
> > cp_parser_late_parsing_nsdmi for "int y = A{x}.y;" we use 
> > finish_compound_literal
> > on type=A, compound_literal={((struct B *) this)->x}.  When digesting this
> > initializer, we call get_nsdmi which creates a PLACEHOLDER_EXPR for A -- we 
> > don't
> > have any object to refer to yet.  After digesting, we have
> > 
> >   {.x=((struct B *) this)->x, .y=(&)->x}
> > 
> > and since we've created a PLACEHOLDER_EXPR inside it, we marked the whole 
> > ctor
> > CONSTRUCTOR_PLACEHOLDER_BOUNDARY.  f_c_l creates a TARGET_EXPR and returns
> > 
> >   TARGET_EXPR x, .y=(& > struct A>)->x}>
> > 
> > Then we get to
> > 
> >   B b = {};
> > 
> > and call store_init_value, which digest the {}, which produces
> > 
> >   {.x=NON_LVALUE_EXPR <0>, .y=(TARGET_EXPR  > struct B>)->x, .y=(&)->x}>).y}
> > 
> > The call to replace_placeholders in store_init_value will not do anything:
> > we've marked the inner { } CONSTRUCTOR_PLACEHOLDER_BOUNDARY, and it's only
> > a sub-expression, so replace_placeholders does nothing, so the  > B>
> > stays even though now is the perfect time to replace it because we have an
> > object for it: 'b'.
> > 
> > Later, in cp_gimplify_init_expr the *expr_p is
> > 
> >   D.2395 = {.x=(&)->x, .y=(& > struct A>)->x}
> > 
> > where D.2395 is of type A, but we crash because we hit , which
> > has a different type.
> > 
> > My idea was to replace  with D.2384 in f_c_l after creating 
> > the
> > TARGET_EXPR because that means we have an object we can refer to.  Then 
> > clear
> > CONSTRUCTOR_PLACEHOLDER_BOUNDARY because we no longer have a 
> > PLACEHOLDER_EXPR
> > in the {}.  Then store_init_value will be able to replace  
> > with
> > 'b', and we should be good to go.
> 
> Makes sense to me.  It seems all was well until break_out_target_exprs,
> called from get_nsdmi for B::y, replaced the 'this' in the initializer
> 
>   (TARGET_EXPR x, .y=(& struct A>)->x}>).y;
> 
> with a PLACEHOLDER_EXPR;
> 
>   (TARGET_EXPR )->x, 
> .y=(&)->x}>).y;
> 
> This seems to be the wrong thing to do when the 'this' appears inside a
> CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructor because the new
> PLACEHOLDER_EXPR then can't be resolved correctly.

Exactly.

> So in light of this I wonder if we should instead perform this handling
> you added to finish_compound_literal in break_out_target_exprs /
> bot_manip instead?

Unfortunately that causes an ICE in gimplify_var_or_parm_decl on the new
testcase I've added here.  bot_manip is a different context and so I can't
use parsing_nsdmi anymore, and it seems we'd replace the placeholders too
aggressively in bot_manip.  So I'm not sure if that's the best place.

-- >8 --
Consider

  struct A {
int x;
int y = x;
  };

  struct B {
int x = 0;
int y = A{x}.y; // #1
  };

where for #1 we end up with

  {.x=(&)->x, .y=(&)->x}

that is, two PLACEHOLDER_EXPRs for different types on the same level in
a {}.  This crashes because our CONSTRUCTOR_PLACEHOLDER_BOUNDARY mechanism to
avoid replacing unrelated PLACEHOLDER_EXPRs cannot deal with it.

Here's why we wound up with those PLACEHOLDER_EXPRs: When we're performing
cp_parser_late_parsing_nsdmi for "int y = A{x}.y;" we use 
finish_compound_literal
on type=A, compound_literal={((struct B *) this)->x}.  When digesting this
initializer, we call get_nsdmi which creates a PLACEHOLDER_EXPR for A -- we 
don't
have any object to refer to yet.  After digesting, we have

  {.x=((struct B *) this)->x, .y=(&)->x}

and since we've created a PLACEHOLDER_EXPR inside it, we marked the whole ctor
CONSTRUCTOR_PLACEHOLDER_BOUNDARY.  f_c_l creates a TARGET_EXPR and returns

  TARGET_EXPR x, .y=(&)->x}>

Then we get to

  B b = {};

and call store_init_value, which digest the {}, which produces

  {.x=NON_LVALUE_EXPR <0>, .y=(TARGET_EXPR )->x, .y=(&)->x}>).y}

The call to replace_placeholders in store_init_value will not do anything:
we've marked the inner { } CONSTRUCTOR_PLACEHOLDER_BOUNDARY, and it's only
a sub-expression, so replace_placeholders does nothing, so the 
stays even though now is the perfect time to replace it because we have an
object for it: 'b'.

Later, in cp_gimplify_init_expr the *expr_p is

  D.2395 = {.x=(&)->x, .y=(&)->x}

where D.2395 is of type A, but we crash because we hit , which
has a different type.

My idea was to replace  with D.2384 in f_c_l after cre

[patch, fortran, doc] Mention new CONVERT options for POWER

[Thomas Koenig via Gcc-patches]

Hi,

as we say in German "Nicht documentiert ist nicht gemacht", if
it is not documented, it wasn't done.

So I thought it would be time to document the changes to the various
ways of specifying CONVERT before gcc12 went out of the door, so
here is a patch for that.

If that goes in, I will also write up something for gcc-12/changes.html.

OK for trunk?  Suggestions for improvements?

Best regards

Thomas

Document changes to CONVERT for -mabi-ieeelongdouble for POWER

gcc/fortran/ChangeLog:

* gfortran.texi: Mention r16_ieee and r16_ibm.
* invoke.texi: Likewise.diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index f8737f4d323..6f622fb9898 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -589,7 +589,7 @@ Malformed environment variables are silently ignored.
 * GFORTRAN_SHOW_LOCUS::  Show location for runtime errors
 * GFORTRAN_OPTIONAL_PLUS:: Print leading + where permitted
 * GFORTRAN_LIST_SEPARATOR::  Separator for list output
-* GFORTRAN_CONVERT_UNIT::  Set endianness for unformatted I/O
+* GFORTRAN_CONVERT_UNIT::  Set conversion for unformatted I/O
 * GFORTRAN_ERROR_BACKTRACE:: Show backtrace on run-time errors
 * GFORTRAN_FORMATTED_BUFFER_SIZE:: Buffer size for formatted files
 * GFORTRAN_UNFORMATTED_BUFFER_SIZE:: Buffer size for unformatted files
@@ -686,11 +686,12 @@ when @command{a.out} is the compiled Fortran program that you want to run.
 Default is a single space.
 
 @node GFORTRAN_CONVERT_UNIT
-@section @env{GFORTRAN_CONVERT_UNIT}---Set endianness for unformatted I/O
+@section @env{GFORTRAN_CONVERT_UNIT}---Set conversion for unformatted I/O
 
 By setting the @env{GFORTRAN_CONVERT_UNIT} variable, it is possible
 to change the representation of data for unformatted files.
-The syntax for the @env{GFORTRAN_CONVERT_UNIT} variable is:
+The syntax for the @env{GFORTRAN_CONVERT_UNIT} variable for
+most systems is:
 @smallexample
 GFORTRAN_CONVERT_UNIT: mode | mode ';' exception | exception ;
 mode: 'native' | 'swap' | 'big_endian' | 'little_endian' ;
@@ -711,14 +712,24 @@ the modes are the same as for the @code{CONVERT} specifier:
 for unformatted files.
 @item @code{BIG_ENDIAN} Use the big-endian format for unformatted files.
 @end itemize
+For POWER systems which support @option{-mabi=ieeelongdouble},
+there are additional options, which can be combined with the
+others with commas. Those are
+@itemize @w{}
+@item @code{R16_IEEE} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{R16_IBM} Use IBM @code{long double} format for
+@code{REAL(KIND=16)}.
+@end itemize
 A missing mode for an exception is taken to mean @code{BIG_ENDIAN}.
 Examples of values for @env{GFORTRAN_CONVERT_UNIT} are:
 @itemize @w{}
-@item @code{'big_endian'}  Do all unformatted I/O in big_endian mode.
+@item @code{'big_endian'}  Do all unformatted I/O in big_endian mod.e
 @item @code{'little_endian;native:10-20,25'}  Do all unformatted I/O
 in little_endian mode, except for units 10 to 20 and 25, which are in
 native format.
 @item @code{'10-20'}  Units 10 to 20 are big-endian, the rest is native.
+@item @code{'big_endian,r16_ibm'} Do all unformatted I/O in big-endian
+mode and use IBM long double for output of @code{REAL(KIND=16)} values.
 @end itemize
 
 Setting the environment variables should be done on the command
@@ -1736,7 +1747,7 @@ the @code{CONVERT} specifier on the @code{OPEN} statement.
 @xref{GFORTRAN_CONVERT_UNIT}, for an alternative way of specifying
 the data format via an environment variable.
 
-Valid values for @code{CONVERT} are:
+Valid values for @code{CONVERT} on most systems are:
 @itemize @w{}
 @item @code{CONVERT='NATIVE'} Use the native format.  This is the default.
 @item @code{CONVERT='SWAP'} Swap between little- and big-endian.
@@ -1745,6 +1756,15 @@ for unformatted files.
 @item @code{CONVERT='BIG_ENDIAN'} Use the big-endian representation for
 unformatted files.
 @end itemize
+On POWER systems which support @option{-mabi=ieeelongdouble},
+there are additional options, which can be combined with the others
+with commas. Those are
+@itemize @w{}
+@item @code{CONVERT='R16_IEEE'} Use IEEE 128-bit format for
+@code{REAL(KIND=16)}.
+@item @code{CONVERT='R16_IBM'} Use IBM @code{long double} format for
+real@code{REAL(KIND=16)}.
+@end itemize
 
 Using the option could look like this:
 @smallexample
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 5c7501a28b1..c0932f6cd70 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1435,10 +1435,20 @@ These options affect the runtime behavior of programs compiled with GNU Fortran.
 @item -fconvert=@var{conversion}
 @opindex @code{fconvert=}@var{conversion}
 Specify the representation of data for unformatted files.  Valid
-values for conversion are: @samp{native}, the default; @samp{swap},
-swap between big- and little-endian; @samp{big-endian}, use big-endian
-representation for unformatted files; @samp{little-endian}, use little-endian
-representati

[PATCH] c++: global-namespace-qualified var after class def [PR90107]

[Marek Polacek via Gcc-patches]

Here we wrongly reject the definition of "::N::a"

  struct A;
  namespace N { extern A a; }
  struct A {} ::N::a;

because our code to diagnose a missing ; after a class definition doesn't
realize that :: can follow a class definition.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11.4?

PR c++/90107

gcc/cp/ChangeLog:

* parser.cc (cp_parser_class_specifier_1): Accept :: after a class
definition.

gcc/testsuite/ChangeLog:

* g++.dg/parse/qualified6.C: New test.
---
 gcc/cp/parser.cc|  1 +
 gcc/testsuite/g++.dg/parse/qualified6.C | 10 ++
 2 files changed, 11 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/parse/qualified6.C

diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 169e6a62f5f..2235da10c7c 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -25933,6 +25933,7 @@ cp_parser_class_specifier_1 (cp_parser* parser)
   case CPP_OPEN_PAREN:
   case CPP_CLOSE_PAREN:
   case CPP_COMMA:
+  case CPP_SCOPE:
 want_semicolon = false;
 break;
 
diff --git a/gcc/testsuite/g++.dg/parse/qualified6.C 
b/gcc/testsuite/g++.dg/parse/qualified6.C
new file mode 100644
index 000..68b51f771ec
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/qualified6.C
@@ -0,0 +1,10 @@
+// PR c++/90107
+// { dg-do compile }
+
+struct A;
+namespace N { extern A a; }
+struct A {} ::N::a;
+
+struct A1;
+struct B { static A1 a1; };
+struct A1 {} ::B::a1;

base-commit: 58e4a744b6e8140499ed6c33a8e9a6557e102f74
-- 
2.35.1

Re: [PATCH RFA] c-family: attribute ((aligned, mode)) [PR100545]

[Jason Merrill via Gcc-patches]

On 4/27/22 13:02, Joseph Myers wrote:

On Wed, 27 Apr 2022, Jason Merrill via Gcc-patches wrote:


+  if (typedef_variant_p (type))
+   {
+ /* Set up the typedef all over again.  */


This seems wrong when the typedef is just being used in another
declaration with the mode attribute, as opposed to being defined using the
mode attribute.  E.g. the following test is valid and accepted before the
patch, but wrongly rejected after the patch because the typedef has had
its type changed.

typedef int I;
int x;
I y __attribute__ ((mode(QI)));
extern I x;


Ah, good point.  Fixed thus:From 35210478aa12623dcf027b7a14ea5216d93a46e4 Mon Sep 17 00:00:00 2001
From: Jason Merrill 
Date: Fri, 15 Apr 2022 16:27:05 -0400
Subject: [PATCH] c-family: attribute ((aligned, mode)) [PR100545]
To: gcc-patches@gcc.gnu.org

The problem here was that handle_mode_attribute clobbered the changes of any
previous attribute, only copying type qualifiers to the new type.  And
common_handle_aligned_attribute had previously set up the typedef, so when
we later called set_underlying_type it saw DECL_ORIGINAL_TYPE set and just
returned, even though handle_mode_attribute had messed up the TREE_TYPE.
So, let's fix handle_mode_attribute to copy attributes, alignment, and
typedefness to the new type.

	PR c/100545

gcc/c-family/ChangeLog:

	* c-attribs.cc (handle_mode_attribute): Copy attributes, aligned,
	and typedef.
	* c-common.cc (set_underlying_type): Add assert.

gcc/testsuite/ChangeLog:

	* c-c++-common/attr-mode-1.c: New test.
	* c-c++-common/attr-mode-2.c: New test.
---
 gcc/c-family/c-attribs.cc| 16 +++-
 gcc/c-family/c-common.cc |  7 ---
 gcc/testsuite/c-c++-common/attr-mode-1.c |  3 +++
 gcc/testsuite/c-c++-common/attr-mode-2.c |  4 
 4 files changed, 26 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/attr-mode-1.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-mode-2.c

diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index 111a33f405a..b1953a45f9b 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -2199,7 +2199,21 @@ handle_mode_attribute (tree *node, tree name, tree args,
 	  return NULL_TREE;
 	}
 
-  *node = build_qualified_type (typefm, TYPE_QUALS (type));
+  /* Copy any quals and attributes to the new type.  */
+  *node = build_type_attribute_qual_variant (typefm, TYPE_ATTRIBUTES (type),
+		 TYPE_QUALS (type));
+  if (TYPE_USER_ALIGN (type))
+	*node = build_aligned_type (*node, TYPE_ALIGN (type));
+
+  tree decl = node[2];
+  if (decl && TYPE_NAME (type) == decl)
+	{
+	  /* Set up the typedef all over again.  */
+	  DECL_ORIGINAL_TYPE (decl) = NULL_TREE;
+	  TREE_TYPE (decl) = *node;
+	  set_underlying_type (decl);
+	  *node = TREE_TYPE (decl);
+	}
 }
 
   return NULL_TREE;
diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index bb0544eeaea..730faa9e87f 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -8153,15 +8153,16 @@ check_missing_format_attribute (tree ltype, tree rtype)
 void
 set_underlying_type (tree x)
 {
-  if (x == error_mark_node)
+  if (x == error_mark_node || TREE_TYPE (x) == error_mark_node)
 return;
   if (DECL_IS_UNDECLARED_BUILTIN (x) && TREE_CODE (TREE_TYPE (x)) != ARRAY_TYPE)
 {
   if (TYPE_NAME (TREE_TYPE (x)) == 0)
 	TYPE_NAME (TREE_TYPE (x)) = x;
 }
-  else if (TREE_TYPE (x) != error_mark_node
-	   && DECL_ORIGINAL_TYPE (x) == NULL_TREE)
+  else if (DECL_ORIGINAL_TYPE (x))
+gcc_checking_assert (TYPE_NAME (TREE_TYPE (x)) == x);
+  else
 {
   tree tt = TREE_TYPE (x);
   DECL_ORIGINAL_TYPE (x) = tt;
diff --git a/gcc/testsuite/c-c++-common/attr-mode-1.c b/gcc/testsuite/c-c++-common/attr-mode-1.c
new file mode 100644
index 000..59b20cd99e8
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/attr-mode-1.c
@@ -0,0 +1,3 @@
+// PR c/100545
+
+typedef int fatp_t __attribute__((aligned, mode(SI)));
diff --git a/gcc/testsuite/c-c++-common/attr-mode-2.c b/gcc/testsuite/c-c++-common/attr-mode-2.c
new file mode 100644
index 000..de65f49c6b6
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/attr-mode-2.c
@@ -0,0 +1,4 @@
+typedef int I;
+int x;
+I y __attribute__ ((mode(QI)));
+extern I x;
-- 
2.27.0

Re: [PATCH] c++: global-namespace-qualified var after class def [PR90107]

[Jason Merrill via Gcc-patches]

On 4/27/22 18:45, Marek Polacek wrote:

Here we wrongly reject the definition of "::N::a"

   struct A;
   namespace N { extern A a; }
   struct A {} ::N::a;

because our code to diagnose a missing ; after a class definition doesn't
realize that :: can follow a class definition.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11.4?


OK.


PR c++/90107

gcc/cp/ChangeLog:

* parser.cc (cp_parser_class_specifier_1): Accept :: after a class
definition.

gcc/testsuite/ChangeLog:

* g++.dg/parse/qualified6.C: New test.
---
  gcc/cp/parser.cc|  1 +
  gcc/testsuite/g++.dg/parse/qualified6.C | 10 ++
  2 files changed, 11 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/parse/qualified6.C

diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 169e6a62f5f..2235da10c7c 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -25933,6 +25933,7 @@ cp_parser_class_specifier_1 (cp_parser* parser)
case CPP_OPEN_PAREN:
case CPP_CLOSE_PAREN:
case CPP_COMMA:
+  case CPP_SCOPE:
  want_semicolon = false;
  break;
  
diff --git a/gcc/testsuite/g++.dg/parse/qualified6.C b/gcc/testsuite/g++.dg/parse/qualified6.C

new file mode 100644
index 000..68b51f771ec
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/qualified6.C
@@ -0,0 +1,10 @@
+// PR c++/90107
+// { dg-do compile }
+
+struct A;
+namespace N { extern A a; }
+struct A {} ::N::a;
+
+struct A1;
+struct B { static A1 a1; };
+struct A1 {} ::B::a1;

base-commit: 58e4a744b6e8140499ed6c33a8e9a6557e102f74

Re: [PATCH v2] loongarch: ignore zero-size fields in calling convention

[Lulu Cheng]

I have pushed upstream. Thanks. Lulu Cheng

在 2022/4/27 下午7:45, Xi Ruoyao 写道:

On Wed, 2022-04-27 at 14:57 +0800, Lulu Cheng wrote:


I think the modification should be below.

  if (!TYPE_P (TREE_TYPE (f)))
     return -1;

I think (!TYPE_P (TREE_TYPE (f)) will never be true (the code handling
calling convention of other ports does not has this check).  But "first
thing first" so I'll move the change below this for now.

gcc/

* config/loongarch/loongarch.cc
(loongarch_flatten_aggregate_field): Ignore empty fields for
RECORD_TYPE.

gcc/testsuite/

* gcc.target/loongarch/zero-size-field-pass.c: New test.
* gcc.target/loongarch/zero-size-field-ret.c: New test.
---
  gcc/config/loongarch/loongarch.cc |  3 ++
  .../loongarch/zero-size-field-pass.c  | 30 +++
  .../loongarch/zero-size-field-ret.c   | 28 +
  3 files changed, 61 insertions(+)
  create mode 100644 gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c
  create mode 100644 gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index f22150a60cc..80046b64006 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -329,6 +329,9 @@ loongarch_flatten_aggregate_field (const_tree type,
if (!TYPE_P (TREE_TYPE (f)))
  return -1;
  
+	if (DECL_SIZE (f) && integer_zerop (DECL_SIZE (f)))

+ continue;
+
HOST_WIDE_INT pos = offset + int_byte_position (f);
n = loongarch_flatten_aggregate_field (TREE_TYPE (f), fields, n,
   pos);
diff --git a/gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c 
b/gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c
new file mode 100644
index 000..999dc913a71
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/zero-size-field-pass.c
@@ -0,0 +1,30 @@
+/* Test that LoongArch backend ignores zero-sized fields of aggregates in
+   argument passing.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O2 -mdouble-float -mabi=lp64d" } */
+/* { dg-final { scan-assembler "\\\$f1" } } */
+
+struct test
+{
+  int empty1[0];
+  double empty2[0];
+  int : 0;
+  float x;
+  long empty3[0];
+  long : 0;
+  float y;
+  unsigned : 0;
+  char empty4[0];
+};
+
+extern void callee (struct test);
+
+void
+caller (void)
+{
+  struct test test;
+  test.x = 114;
+  test.y = 514;
+  callee (test);
+}
diff --git a/gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c 
b/gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c
new file mode 100644
index 000..40137d97555
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/zero-size-field-ret.c
@@ -0,0 +1,28 @@
+/* Test that LoongArch backend ignores zero-sized fields of aggregates in
+   returning.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O2 -mdouble-float -mabi=lp64d" } */
+/* { dg-final { scan-assembler-not "\\\$r4" } } */
+
+struct test
+{
+  int empty1[0];
+  double empty2[0];
+  int : 0;
+  float x;
+  long empty3[0];
+  long : 0;
+  float y;
+  unsigned : 0;
+  char empty4[0];
+};
+
+extern struct test callee (void);
+
+float
+caller (void)
+{
+  struct test test = callee ();
+  return test.x + test.y;
+}

Re: [PATCH] testsuite: Skip target not support -pthread [pr104676].

[Kito Cheng via Gcc-patches]

Committed to trunk.

On Tue, Apr 19, 2022 at 3:08 PM Richard Biener via Gcc-patches
 wrote:
>
> On Tue, 19 Apr 2022, jiawei wrote:
>
> > The "ftree-parallelize-loops=" imply -pthread option in gcc/gcc.cc,
> > some target are not support pthread like elf target use newlib,
> > and will get an error:
> >
> > "*-*-elf-gcc: error: unrecognized command-line option '-pthread'"
> >
> > so we add an additional condition "{target pthread}" to make sure the
> > dg-additional-options runs on support targets.
>
> OK.
>
> > ---
> >  gcc/testsuite/gcc.dg/torture/pr104676.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/gcc/testsuite/gcc.dg/torture/pr104676.c 
> > b/gcc/testsuite/gcc.dg/torture/pr104676.c
> > index 50845bb9e15..0991b78f758 100644
> > --- a/gcc/testsuite/gcc.dg/torture/pr104676.c
> > +++ b/gcc/testsuite/gcc.dg/torture/pr104676.c
> > @@ -1,5 +1,5 @@
> >  /* { dg-do compile } */
> > -/* { dg-additional-options "-ftree-loop-distribution 
> > -ftree-parallelize-loops=2" } */
> > +/* { dg-additional-options "-ftree-loop-distribution 
> > -ftree-parallelize-loops=2" { target pthread } } */
> >
> >  struct S {
> >int f;
> >
>
> --
> Richard Biener 
> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
> Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)

Re: [PATCH 0/3] RISC-V: Add Ratified Cache Management Operation ISA Extensions

[Kito Cheng via Gcc-patches]

Generally this patch LGTM, but let's defer to GCC 13 :)

For builtin function...I guess we might need a document in
https://github.com/riscv-non-isa/riscv-c-api-doc first.


On Fri, Mar 25, 2022 at 2:21 PM  wrote:
>
> From: yulong-plct 
>
> This patchset adds support for three recently ratified RISC-V extensions:
>
> -   Zicbom (Cache-Block Management Instructions)
> -   Zicbop (Cache-Block Prefetch hint instructions)
> -   Zicboz (Cache-Block Zero Instructions)
>
> The naming of builtin caused oddities, so in this release we have changed the 
> names of builtin. For example, change "__builtin_riscv_zero()" to 
> "__builtin_riscv_zicboz_cbo_zero"
>
> Patch 1: Add Zicbom/z/p mininal support
> Patch 2: Add Zicbom/z/p instructions arch support
> Patch 3: Add Zicbom/z/p instructions testcases
>
> cf. 
> ;
>
> *** BLURB HERE ***
>
> yulong-plct (3):
>   RISC-V: Add mininal support for Zicbo[mzp]
>   RISC-V:Cache Management Operation instructions
>   RISC-V:Cache Management Operation instructions testcases
>
>  gcc/common/config/riscv/riscv-common.cc   |  6 +++
>  gcc/config/riscv/predicates.md|  4 ++
>  gcc/config/riscv/riscv-builtins.cc| 16 ++
>  gcc/config/riscv/riscv-cmo.def| 17 ++
>  gcc/config/riscv/riscv-ftypes.def |  4 ++
>  gcc/config/riscv/riscv-opts.h |  9 
>  gcc/config/riscv/riscv.md | 52 +++
>  gcc/config/riscv/riscv.opt|  3 ++
>  gcc/testsuite/gcc.target/riscv/cmo-zicbom-1.c | 21 
>  gcc/testsuite/gcc.target/riscv/cmo-zicbom-2.c | 21 
>  gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c | 23 
>  gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c | 23 
>  gcc/testsuite/gcc.target/riscv/cmo-zicboz-1.c |  9 
>  gcc/testsuite/gcc.target/riscv/cmo-zicboz-2.c |  9 
>  14 files changed, 217 insertions(+)
>  create mode 100644 gcc/config/riscv/riscv-cmo.def
>  create mode 100644 gcc/testsuite/gcc.target/riscv/cmo-zicbom-1.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/cmo-zicbom-2.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/cmo-zicbop-1.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/cmo-zicbop-2.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/cmo-zicboz-1.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/cmo-zicboz-2.c
>
> --
> 2.17.1
>

[committed][wwwdocs] gcc-12/changes.html: Document RISC-V changes

[Kito Cheng]

---
 htdocs/gcc-12/changes.html | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 78b7b05f..e9f132c0 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -736,7 +736,18 @@ function Multiply (S1, S2 : Sign) return Sign is
 
 
 
-
+RISC-V
+
+Default ISA spec version was bump to 20191213, more detail see this https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4";>
+announcement
+New ISA extension support for zba, zbb, zbc, zbs was added.
+New ISA extension support for vector and scalar crypto was added, only
+   support architecture testing marco and -march= 
parsing.
+The option -mtune=thead-c906 is added to tune for T-HEAD
+   c906 cores.
+  
+
 
 
 
-- 
2.17.1

Re: [PATCH] testsuite: Add test case for pack/unpack bifs at soft-float [PR105334]

[Kewen.Lin via Gcc-patches]

on 2022/4/27 8:46 PM, David Edelsohn wrote:
> On Wed, Apr 27, 2022 at 8:22 AM Segher Boessenkool
>  wrote:
>>
>> Hi!
>>
>> Thank you for doing this testcase.
>>
>> On Wed, Apr 27, 2022 at 06:29:07PM +0800, Kewen.Lin wrote:
>>> As discussed in PR105334, this patch is to add the test coverage for
>>> the two recent fixes r12-8091 and r12-8226 from Segher, aix is skipped
>>> since it takes soft-float and long-double-128 incompatible.
>>>
>>> I noticed the referred test case pack02.c skips if powerpc*-*-darwin*,
>>> but it's for do-run and I didn't have one machine to test that triple,
>>> so I didn't add that and hope it's unnecessary.
>>
>> That is the best thing to do if you aren't sure, the Darwin people are
>> in a much better position to decide this themselves.  Cc:ed Iain.
>>
>>> Tested on powerpc64-linux-gnu P8, powerpc64le-linux-gnu P9/P10 and
>>> powerpc-ibm-aix7.2.0.0.
>>>
>>> Is ok for trunk?
>>
>> Okay for trunk, thanks!  Please see if David has some more input?
>>
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/powerpc/pr105334.c
>>> @@ -0,0 +1,31 @@
>>> +/* Skip this on aix, since it takes soft-float and long-double-128
>>> +   incompatible and warns it.  */
>>> +/* { dg-skip-if "aix long-double-128 soft-float" { powerpc*-*-aix* } } */
>>> +/* { dg-options "-mlong-double-128 -msoft-float" } */
>>
>> Maybe you just want to add "-w" and not skip on AIX, if the test
>> generates the correct code anyway?  Either way works for me though.
> 
> The additional libgcc functions for ibm128 weren't added to the AIX
> configuration.  And it' not clear that soft-float on AIX is
> interesting anyway.
> 

Thanks for both your reviews and comments!  Pushed as r12-8296.

BR,
Kewen

[PATCH][_GLIBCXX_INLINE_VERSION] Fix std::random_device definition

[François Dumont via Gcc-patches]

Hi

    Still time for this fix for gcc 12 ?

    If so I'll make sure to run tests quickly, especially the abi.exp 
one to confirm that the cleanup in gnu-versioned-namespace.ver do not 
need to be replaced by the same in __8 namespace.


libstdc++: [_GLIBCXX_INLINE_VERSION] Fix std::random_device definition

Definition shall be put in _GLIBCXX_BEGIN_VERSION_NAMESPACE/
_GLIBCXX_END_VERSION_NAMESPACE like the declaration.

libstdc++-v3/ChangeLog

    * src/c++11/cow-string-inst.cc: Put random_device member definitions
    in versioned namespace.
    * src/c++11/random.cc: Likewise.
    * config/abi/pre/gnu-versioned-namespace.ver: Remove std::random_device
    symbols.

François
diff --git a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
index e9520a6421e..b37199ece72 100644
--- a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
+++ b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
@@ -28,7 +28,6 @@ GLIBCXX_8.0 {
 {
   std::*;
   std::__8::*;
-  std::random_device::*
 };
 
 # operator new(size_t)
diff --git a/libstdc++-v3/src/c++11/cow-string-inst.cc b/libstdc++-v3/src/c++11/cow-string-inst.cc
index e5331bb029a..f038d0018f0 100644
--- a/libstdc++-v3/src/c++11/cow-string-inst.cc
+++ b/libstdc++-v3/src/c++11/cow-string-inst.cc
@@ -38,6 +38,8 @@
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
   void
   random_device::_M_init(const std::string& token)
   { _M_init(token.c_str(), token.length()); }
@@ -45,5 +47,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
   void
   random_device::_M_init_pretr1(const std::string& token)
   { _M_init(token.c_str(), token.length()); }
+
+_GLIBCXX_END_NAMESPACE_VERSION
 } // namespace
 #endif
diff --git a/libstdc++-v3/src/c++11/random.cc b/libstdc++-v3/src/c++11/random.cc
index 8b5175a4ebf..9c806b92559 100644
--- a/libstdc++-v3/src/c++11/random.cc
+++ b/libstdc++-v3/src/c++11/random.cc
@@ -301,7 +301,9 @@ namespace std _GLIBCXX_VISIBILITY(default)
 
   return any; // should be unreachable
 }
-  }
+  } // namespace
+
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   void
   random_device::_M_init(const std::string& token)
@@ -665,5 +667,6 @@ namespace std _GLIBCXX_VISIBILITY(default)
 linear_congruential_engine;
   template struct __detail::_Mod;
 #endif
+_GLIBCXX_END_NAMESPACE_VERSION
 }
 #endif // _GLIBCXX_USE_C99_STDINT_TR1

[PATCH] cgraph: Don't verify semantic_interposition flag for aliases [PR105399]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase ICEs, because the ctors during cc1plus all have
!opt_for_fn (decl, flag_semantic_interposition) - they have NULL
DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl) and optimization_default_node
is for -Ofast and so has flag_semantic_interposition cleared.
During free lang data, we set DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl)
for the ctor which has body (or for thunks), but don't touch it for
aliases.
During lto1 optimization_default_node reflects the lto1 flags which
are -O2 rather than -Ofast and so has flag_semantic_interposition
set, for the ctor which has body that makes no difference, but as the
alias doesn't still have DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl) set,
we now trigger this verification check.

The following patch just doesn't verify it for aliases during lto1.
Another possibility would be to set DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl)
during free lang data even for aliases.

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

2022-04-28  Jakub Jelinek  

PR lto/105399
* cgraph.cc (cgraph_node::verify_node): Don't verify
semantic_interposition flag against
opt_for_fn (decl, flag_semantic_interposition) for aliases in lto1.

* g++.dg/lto/pr105399_0.C: New test.

--- gcc/cgraph.cc.jj2022-04-20 09:24:12.194579146 +0200
+++ gcc/cgraph.cc   2022-04-27 11:53:52.102173154 +0200
@@ -3488,7 +3488,9 @@ cgraph_node::verify_node (void)
 "returns a pointer");
   error_found = true;
 }
-  if (definition && externally_visible
+  if (definition
+  && externally_visible
+  && (!alias || thunk || !in_lto_p)
   && semantic_interposition
 != opt_for_fn (decl, flag_semantic_interposition))
 {
--- gcc/testsuite/g++.dg/lto/pr105399_0.C.jj2022-04-27 11:54:25.659703199 
+0200
+++ gcc/testsuite/g++.dg/lto/pr105399_0.C   2022-04-27 11:48:31.387664565 
+0200
@@ -0,0 +1,9 @@
+// PR lto/105399
+// { dg-lto-do link }
+// { dg-lto-options { { -fPIC -flto -Ofast } } }
+// { dg-require-effective-target shared }
+// { dg-require-effective-target fpic }
+// { dg-extra-ld-options "-shared -O2" }
+
+struct S { S (); };
+S::S () {}

Jakub

[PATCH] testsuite: vect: update unaligned message

[Alexandre Oliva via Gcc-patches]

gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c covers ppc variants
that accept and reject misaligned accesses.  The message that it
expects for rejection was removed in the gcc-11 development cycle by
commit r11-1969.  The patch adjusted multiple tests to use the message
introduced in r11-1945, but missed this one.

Regstrapped on powerpc64el-linux-gnu.  Ok to install?

Also tested on x86_64-linux-gnu-x-ppc64-vx7r2 with gcc-11.  Ok for
gcc-11?


for  gcc/testsuite/ChangeLog

* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Update
the expected message for the case in which unaligned accesses
are not allowed.
---
 .../gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c 
b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
index 72b4930d9bbbe..c57f065cccdd6 100644
--- a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
@@ -46,5 +46,5 @@ int main (void)
   return main1 ();
 } 
 
-/* { dg-final { scan-tree-dump-times "not vectorized: unsupported unaligned 
store" 1 "vect" { target { ! vect_hw_misalign } } } } */
+/* { dg-final { scan-tree-dump-times "unsupported unaligned access" 1 "vect" { 
target { ! vect_hw_misalign } } } } */
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" { target { 
! vect_hw_misalign } } } } */

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH][stage1] Embed real_value into REAL_CST

[Richard Biener via Gcc-patches]

The following removes the indirection to real_value from REAL_CST
which doesn't seem to serve any useful purpose.  Any sharing can
be achieved by sharing the actual REAL_CST (which is what usually
happens when copying trees) and sharing of real_value amongst
different REAL_CST doesn't happen as far as I can see and would
only lead to further issues like mismatching type and real_value.

Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for stage1.

Richard.

2022-04-27  Richard Biener  

* tree-core.h (tree_real_cst::real_cst_ptr): Remove pointer
to real_value field.
(tree_real_cst::value): Add real_value field.
* tree.h (TREE_REAL_CST_PTR): Adjust.
* tree.cc (build_real): Remove separate allocation.
* tree-streamer-in.cc (unpack_ts_real_cst_value_fields):
Likewise.

cp/
* module.cc (trees_in::core_vals): Remove separate allocation
for REAL_CST.
---
 gcc/cp/module.cc| 4 +---
 gcc/tree-core.h | 2 +-
 gcc/tree-streamer-in.cc | 5 +
 gcc/tree.cc | 6 +-
 gcc/tree.h  | 2 +-
 5 files changed, 5 insertions(+), 14 deletions(-)

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index cebf9c35c1d..18dabfcc9ac 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -6468,9 +6468,7 @@ trees_in::core_vals (tree t)
 
 case REAL_CST:
   if (const void *bytes = buf (sizeof (real_value)))
-   TREE_REAL_CST_PTR (t)
- = reinterpret_cast (memcpy (ggc_alloc (),
-   bytes, sizeof 
(real_value)));
+   memcpy (TREE_REAL_CST_PTR (t), bytes, sizeof (real_value));
   break;
 
 case STRING_CST:
diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index f1c2b6413a3..cb4cefd369b 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1461,7 +1461,7 @@ struct GTY(()) tree_int_cst {
 
 struct GTY(()) tree_real_cst {
   struct tree_typed typed;
-  struct real_value * real_cst_ptr;
+  struct real_value value;
 };
 
 struct GTY(()) tree_fixed_cst {
diff --git a/gcc/tree-streamer-in.cc b/gcc/tree-streamer-in.cc
index a35a810f4d1..196f19c759f 100644
--- a/gcc/tree-streamer-in.cc
+++ b/gcc/tree-streamer-in.cc
@@ -190,7 +190,6 @@ unpack_ts_real_cst_value_fields (struct bitpack_d *bp, tree 
expr)
 {
   unsigned i;
   REAL_VALUE_TYPE r;
-  REAL_VALUE_TYPE *rp;
 
   /* Clear all bits of the real value type so that we can later do
  bitwise comparisons to see if two values are the same.  */
@@ -204,9 +203,7 @@ unpack_ts_real_cst_value_fields (struct bitpack_d *bp, tree 
expr)
   for (i = 0; i < SIGSZ; i++)
 r.sig[i] = (unsigned long) bp_unpack_value (bp, HOST_BITS_PER_LONG);
 
-  rp = ggc_alloc ();
-  memcpy (rp, &r, sizeof (REAL_VALUE_TYPE));
-  TREE_REAL_CST_PTR (expr) = rp;
+  memcpy (TREE_REAL_CST_PTR (expr), &r, sizeof (REAL_VALUE_TYPE));
 }
 
 
diff --git a/gcc/tree.cc b/gcc/tree.cc
index 3c39be4f501..1d2cdc82aba 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -2380,18 +2380,14 @@ tree
 build_real (tree type, REAL_VALUE_TYPE d)
 {
   tree v;
-  REAL_VALUE_TYPE *dp;
   int overflow = 0;
 
   /* ??? Used to check for overflow here via CHECK_FLOAT_TYPE.
  Consider doing it via real_convert now.  */
 
   v = make_node (REAL_CST);
-  dp = ggc_alloc ();
-  memcpy (dp, &d, sizeof (REAL_VALUE_TYPE));
-
   TREE_TYPE (v) = type;
-  TREE_REAL_CST_PTR (v) = dp;
+  memcpy (TREE_REAL_CST_PTR (v), &d, sizeof (REAL_VALUE_TYPE));
   TREE_OVERFLOW (v) = overflow;
   return v;
 }
diff --git a/gcc/tree.h b/gcc/tree.h
index 8844471e9a5..82eb8ba39d2 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -1048,7 +1048,7 @@ extern void omp_clause_range_check_failed (const_tree, 
const char *, int,
 #define POLY_INT_CST_COEFF(NODE, I) \
   (POLY_INT_CST_CHECK (NODE)->poly_int_cst.coeffs[I])
 
-#define TREE_REAL_CST_PTR(NODE) (REAL_CST_CHECK (NODE)->real_cst.real_cst_ptr)
+#define TREE_REAL_CST_PTR(NODE) (&REAL_CST_CHECK (NODE)->real_cst.value)
 #define TREE_REAL_CST(NODE) (*TREE_REAL_CST_PTR (NODE))
 
 #define TREE_FIXED_CST_PTR(NODE) \
-- 
2.34.1

[PATCH] libstdc++: ppc: conditionalize vsx-only simd intrinsics

[Alexandre Oliva via Gcc-patches]

libstdc++'s bits/simd.h section for PPC (Altivec) defines various
intrinsic vector types that are only available along with VSX: 64-bit
long double, double, (un)signed long long, and 64-bit (un)signed long.

experimental/simd/standard_abi_usable{,_2}.cc tests error out reporting
the unmet requirements when the target cpu doesn't enable VSX.  Make the
reported instrinsic types conditional on VSX so that 
can be used on ppc variants that do not have VSX support.

Regstrapped on powerpc64el-linux-gnu.  Ok to install?

This is also relevant for gcc-11.  Tested with
x86_64-linux-gnu-x-ppc64-vx7r2.  Ok for gcc-11?


for  libstdc++-v3/ChangeLog

* include/experimental/bits/simd.h [__ALTIVEC__]: Require VSX
for double, long long, and 64-bit long and 64-bit long double
intrinsic types.
---
 libstdc++-v3/include/experimental/bits/simd.h |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/experimental/bits/simd.h 
b/libstdc++-v3/include/experimental/bits/simd.h
index 82e9841195e1d..66c07127ec435 100644
--- a/libstdc++-v3/include/experimental/bits/simd.h
+++ b/libstdc++-v3/include/experimental/bits/simd.h
@@ -2430,17 +2430,23 @@ template 
   template <>  
\
 struct __intrinsic_type_impl<_Tp> { using type = __vector _Tp; }
 _GLIBCXX_SIMD_PPC_INTRIN(float);
+# ifdef __VSX__
 _GLIBCXX_SIMD_PPC_INTRIN(double);
+# endif
 _GLIBCXX_SIMD_PPC_INTRIN(signed char);
 _GLIBCXX_SIMD_PPC_INTRIN(unsigned char);
 _GLIBCXX_SIMD_PPC_INTRIN(signed short);
 _GLIBCXX_SIMD_PPC_INTRIN(unsigned short);
 _GLIBCXX_SIMD_PPC_INTRIN(signed int);
 _GLIBCXX_SIMD_PPC_INTRIN(unsigned int);
+# if defined __VSX__ || __LONG_WIDTH__ == 32
 _GLIBCXX_SIMD_PPC_INTRIN(signed long);
 _GLIBCXX_SIMD_PPC_INTRIN(unsigned long);
+# endif
+# ifdef __VSX__
 _GLIBCXX_SIMD_PPC_INTRIN(signed long long);
 _GLIBCXX_SIMD_PPC_INTRIN(unsigned long long);
+# endif
 #undef _GLIBCXX_SIMD_PPC_INTRIN
 
 template 
@@ -2452,8 +2458,9 @@ template 
 static_assert(!(_S_is_ldouble && sizeof(long double) > sizeof(double)),
  "no __intrinsic_type support for long double on PPC");
 #ifndef __VSX__
-static_assert(!is_same_v<_Tp, double>,
- "no __intrinsic_type support for double on PPC w/o VSX");
+static_assert(!(is_same_v<_Tp, double>
+   || (_S_is_ldouble && sizeof(long double) == 
sizeof(double))),
+ "no __intrinsic_type support for [long] double on PPC w/o 
VSX");
 #endif
 using type =
   typename __intrinsic_type_impl<


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about