Re: [PATCH] testsuite: Update Wconversion testcase check type.

2022-05-11 Thread Palmer Dabbelt

On Wed, 11 May 2022 19:37:21 PDT (-0700), jia...@iscas.ac.cn wrote:

   Thank you, it hasn't commited into the trunk yet.


Should be now.


   ISCAS

   å¨ Palmer Dabbelt ï¼2022å¹´5æ11æ¥ ä¸å5:59åéï¼

 On Thu, 05 May 2022 11:45:50 PDT (-0700), [1]gcc-patches@gcc.gnu.org
 wrote:
 > On Thu, May 05, 2022 at 06:33:20PM +0800, jiawei wrote:
 >> Some compiler target like arm-linux\riscv\power\s390x\xtensa-gcc
 handle
 >> char as unsigned char, then there are no warnings occur and got
 FAIL cases.
 >> Just change the type char into explicit signed char to keep the
 feature
 >> consistency.
 >>
 >> gcc/testsuite/ChangeLog:
 >>
 >>Â Â Â Â Â Â Â Â  * c-c++-common/Wconversion-1.c: Update type.
 >
 > Ok, and sorry for introducing this problem!
 So this is OK for trunk?  Happy to commit it if you'd like, just
 wanted
 to make sure as I'm not seeing it on trunk.
 >> ---
 >>Â  gcc/testsuite/c-c++-common/Wconversion-1.c | 2 +-
 >>Â  1 file changed, 1 insertion(+), 1 deletion(-)
 >>
 >> diff --git a/gcc/testsuite/c-c++-common/Wconversion-1.c
 b/gcc/testsuite/c-c++-common/Wconversion-1.c
 >> index ed65918c70f..7053f6b5dbb 100644
 >> --- a/gcc/testsuite/c-c++-common/Wconversion-1.c
 >> +++ b/gcc/testsuite/c-c++-common/Wconversion-1.c
 >> @@ -10,5 +10,5 @@ void g()
 >>Â Â Â  signed char sc = 300; /* { dg-warning "conversion from
 .int. to .signed char. changes value from .300. to .44." } */
 >>Â Â Â  unsigned char uc = 300; /* { dg-warning "conversion from
 .int. to .unsigned char. changes value from .300. to .44." } */
 >>Â Â Â  unsigned char uc2 = 300u; /* { dg-warning "conversion from
 .unsigned int. to .unsigned char. changes value from .300. to .44."
 } */
 >> -Â  char c2 = (double)1.0 + 200; /* { dg-warning "overflow in
 conversion from .double. to .char. changes value from .2.01e\\+2. to
 .127." } */
 >> +Â  signed char c2 = (double)1.0 + 200; /* { dg-warning "overflow
 in conversion from .double. to .signed char. changes value from
 .2.01e\\+2. to .127." } */
 >>Â  }
 >> --
 >> 2.25.1
 >>
 >
 > Marek

References

   1. mailto:gcc-patches@gcc.gnu.org


[PATCH] Remove -mpower8-fusion options

2022-05-11 Thread Michael Meissner via Gcc-patches
Eliminate power8-fusion and power8-fusion-sign options.

As part of PR target/102059, one of the things came up is that we should
eliminate the power8 fusion options altogether.  This patch eliminates the
-mpower8-fusion option.  It does enable power8 fusion if the code is being
tuned for power8.

This patch gives a warning if the user tried to explicitly use -mpower8-fusion
and silently ignores the user using -mno-power8-fusion.

In addition, there used to be an option (-mpower8-fusion-sign) which split load
with sign extend options into an unsigned load (which can be fused with the
code setting up the address) and then an explicit sign extension.  This option
used to be enabled by default at -O3.  Because this option was never
documented, I didn't bother adding compatibility switches to warn if the option
was used.

I did some testing with Spec 2017.  I found that -mpower8-fusion-sign only
helped one benchark (fotonik3d_r by 2.8%), but it slowed down three other
benchmarks (gcc_r by 1.5%, omnetpp_r by 10.7%, and deepsjeng_r by 1.3%).  Over
all, this seems like a win not to do the optimization.

I also measured whether the fusion helps at all.  There are 3 benchmarks that
are slower if I disabled fusion compared to the code this patch generates
(perlbench_r slows down by 2.8%, bwaves_r slows down by 5.4%, and roms_r slows
down by 2%).  So it does seem to help to a limited extent to keep the fusion
support in (but not do the sign fusion support).

In addition to running the Spec 2017 tests, I have tested this patch on the
following systems with bootstraps and regression testing.  There were no
errors:

   1)   Power10, little endian, built with --with-cpu=power10;
   2)   Power9, little endian, built with --with-cpu=power9; (and)
   3)   Power8, big endian, built with --with-cpu=power8, and tested both
32-bit and 64-bit code.

Can I install this patch into the GCC 13 trunk?  At the moment, I don't plan to
back port this to older branches (since Peter has already installed a patch
that fixes PR target/102059).  But if desired, I can certainly do the
backport.

2022-05-11   Michael Meissner  

gcc/

PR target/102059
* config/rs6000/predicates.md (fusion_gpr_mem_load): Remove
support for fusing load with sign extend.
* config/rs6000/rs6000-cpus.def (OTHER_FUSION_MASKS): Delete.
(ISA_3_0_MASKS_SERVER): Don't reset fusion masks.
(POWERPC_MASKS): Delete -mpower8-fusion option.
* config/rs6000/rs6000.cc (rs6000_debug_reg_global): Delete code
to print out power8 fusion status.
(rs6000_option_override_internal): Delete support for power8
fusion options.
(rs6000_opt_masks): Delete power8-fusion and power8-fusion-sign
options.
(rs6000_can_inline_p): Delete resetting power8 fusion.
(fusion_gpr_load_p): Don't fuse load with sign extend.
(expand_fusion_gpr_load): Likewise.
* config/rs6000/rs6000.h (MASK_P8_FUSION): Delete.
(TARGET_P8_FUSION): New macro.
* config/rs6000/rs6000.opt (-mpower8-fusion): Delete option, allow
-mno-power8-fusion without warning.
(-mpower8-fusion-sign): Delete option.
* doc/invoke.texi (RS/6000 and PowerPC Options): Delete
-mpower8-fusion.

gcc/testsuite/

PR target/102059
* gcc.target/powerpc/fusion.c: Remove load + sign extend fusion
tests.
* gcc.target/powerpc/pr102059-3.c: Remove -mno-power8-fusion
option.
---
 gcc/config/rs6000/predicates.md   |  3 +-
 gcc/config/rs6000/rs6000-cpus.def | 18 ++
 gcc/config/rs6000/rs6000.cc   | 64 ++-
 gcc/config/rs6000/rs6000.h|  4 +-
 gcc/config/rs6000/rs6000.opt  | 11 ++--
 gcc/doc/invoke.texi   | 12 +---
 gcc/testsuite/gcc.target/powerpc/fusion.c |  9 +--
 gcc/testsuite/gcc.target/powerpc/pr102059-3.c |  2 +-
 8 files changed, 28 insertions(+), 95 deletions(-)

diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md
index b1fcc69bb60..55b771d142c 100644
--- a/gcc/config/rs6000/predicates.md
+++ b/gcc/config/rs6000/predicates.md
@@ -1877,8 +1877,7 @@ (define_predicate "fusion_gpr_mem_load"
   rtx addr, base, offset;
 
   /* Handle sign/zero extend.  */
-  if (GET_CODE (op) == ZERO_EXTEND
-  || (TARGET_P8_FUSION_SIGN && GET_CODE (op) == SIGN_EXTEND))
+  if (GET_CODE (op) == ZERO_EXTEND)
 {
   op = XEXP (op, 0);
   mode = GET_MODE (op);
diff --git a/gcc/config/rs6000/rs6000-cpus.def 
b/gcc/config/rs6000/rs6000-cpus.def
index 963947f6939..d913a3d6b73 100644
--- a/gcc/config/rs6000/rs6000-cpus.def
+++ b/gcc/config/rs6000/rs6000-cpus.def
@@ -54,19 +54,14 @@
 | OPTION_MASK_QUAD_MEMORY  \
 | OPTION_MASK_QUAD_MEMORY_ATOMIC)
 
-/* ISA masks setting fusion options.  */
-#define OTHER_FUSION_MASKS 

RE: [PATCH] [i386]Add combine splitter to transform pxor/pcmpeqb/pmovmskb/cmp 0xffff to ptest.

2022-05-11 Thread Jiang, Haochen via Gcc-patches
Hi all,

I just refined this patch with more explanation in commit message.

No code change compare to last change, which removed ix86_match_ccmode.

Ok for trunk?

BRs,
Haochen

> -Original Message-
> From: Jiang, Haochen
> Sent: Saturday, May 7, 2022 9:55 AM
> To: Uros Bizjak 
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao 
> Subject: RE: [PATCH] [i386]Add combine splitter to transform
> pxor/pcmpeqb/pmovmskb/cmp 0x to ptest.
> 
> 
> 
> > -Original Message-
> > From: Uros Bizjak 
> > Sent: Friday, May 6, 2022 4:59 PM
> > To: Jiang, Haochen 
> > Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao 
> > Subject: Re: [PATCH] [i386]Add combine splitter to transform
> > pxor/pcmpeqb/pmovmskb/cmp 0x to ptest.
> >
> > On Fri, May 6, 2022 at 10:01 AM Haochen Jiang 
> > wrote:
> > >
> > > Hi all,
> > >
> > > This patch aims to add a combine splitter to transform
> pxor/pcmpeqb/pmovmskb/cmp 0x to ptest.
> > >
> > > Regtested on x86_64-pc-linux-gnu. Ok for trunk?
> > >
> > > BRs,
> > > Haochen
> > >
> > > gcc/ChangeLog:
> > >
> > > PR target/104371
> > > * config/i386/sse.md: Add new define_mode_attr and define_split.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > PR target/104371
> > > * gcc.target/i386/pr104371-1.c: New test.
> > > * gcc.target/i386/pr104371-2.c: Ditto.
> > > ---
> > >  gcc/config/i386/sse.md | 19 +++
> > >  gcc/testsuite/gcc.target/i386/pr104371-1.c | 14 ++
> > > gcc/testsuite/gcc.target/i386/pr104371-2.c | 14 ++
> > >  3 files changed, 47 insertions(+)
> > >  create mode 100644 gcc/testsuite/gcc.target/i386/pr104371-1.c
> > >  create mode 100755 gcc/testsuite/gcc.target/i386/pr104371-2.c
> > >
> > > diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md index
> > > 7b791def542..71afda73c8f 100644
> > > --- a/gcc/config/i386/sse.md
> > > +++ b/gcc/config/i386/sse.md
> > > @@ -20083,6 +20083,25 @@
> > > (set_attr "prefix" "maybe_vex")
> > > (set_attr "mode" "SI")])
> > >
> > > +;; Optimize pxor/pcmpeqb/pmovmskb/cmp 0x to ptest.
> > > +(define_mode_attr vi1avx2const
> > > +  [(V32QI "0x") (V16QI "0x")])
> > > +
> > > +(define_split
> > > +  [(set (reg:CCZ FLAGS_REG)
> > > +   (compare:CCZ (unspec:SI
> > > +   [(eq:VI1_AVX2
> > > +   (match_operand:VI1_AVX2 0 "vector_operand")
> > > +   (match_operand:VI1_AVX2 1 "const0_operand"))]
> > > +   UNSPEC_MOVMSK)
> > > +(match_operand 2 "const_int_operand")))]
> > > +  "TARGET_SSE4_1 && ix86_match_ccmode (insn, CCmode)
> >
> > No need to use ix86_match_ccmode here, the pattern is already limited to
> > CCZmode,
> >
> > Uros.
> >
> 
> Removed this condition in my new patch, also make the testcase change
> according to
> Hongyu's review.
> 
> Is the patch Ok for trunk?
> 
> Haochen
> 
> > > +  && (INTVAL (operands[2]) == (int) ())"
> > > +  [(set (reg:CC FLAGS_REG)
> > > +   (unspec:CC [(match_dup 0)
> > > +   (match_dup 0)]
> > > +  UNSPEC_PTEST))])
> > > +
> > >  (define_expand "sse2_maskmovdqu"
> > >[(set (match_operand:V16QI 0 "memory_operand")
> > > (unspec:V16QI [(match_operand:V16QI 1 "register_operand") diff
> > > --git a/gcc/testsuite/gcc.target/i386/pr104371-1.c
> > > b/gcc/testsuite/gcc.target/i386/pr104371-1.c
> > > new file mode 100644
> > > index 000..df7c0b074e3
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/i386/pr104371-1.c
> > > @@ -0,0 +1,14 @@
> > > +/* { dg-do compile } */
> > > +/* { dg-options "-O2 -msse4" } */
> > > +/* { dg-final { scan-assembler "ptest\[ \\t\]" } } */
> > > +/* { dg-final { scan-assembler-not "pxor\[ \\t\]" } } */
> > > +/* { dg-final { scan-assembler-not "pcmpeqb\[ \\t\]" } } */
> > > +/* { dg-final { scan-assembler-not "pmovmskb\[ \\t\]" } } */
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +bool is_zero(__m128i x)
> > > +{
> > > +  return _mm_movemask_epi8(_mm_cmpeq_epi8(x, _mm_setzero_si128()))
> > ==
> > > +0x; }
> > > diff --git a/gcc/testsuite/gcc.target/i386/pr104371-2.c
> > > b/gcc/testsuite/gcc.target/i386/pr104371-2.c
> > > new file mode 100755
> > > index 000..f0d0afd5897
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/i386/pr104371-2.c
> > > @@ -0,0 +1,14 @@
> > > +/* { dg-do compile } */
> > > +/* { dg-options "-O2 -mavx2" } */
> > > +/* { dg-final { scan-assembler "vptest\[ \\t\]" } } */
> > > +/* { dg-final { scan-assembler-not "vpxor\[ \\t\]" } } */
> > > +/* { dg-final { scan-assembler-not "vpcmpeqb\[ \\t\]" } } */
> > > +/* { dg-final { scan-assembler-not "vpmovmskb\[ \\t\]" } } */
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +bool is_zero256(__m256i x)
> > > +{
> > > +  return _mm256_movemask_epi8(_mm256_cmpeq_epi8(x,
> > > +_mm256_setzero_si256())) == 0x; }
> > > --
> > > 2.18.1
> > >



[PATCH] [PR105455] predict: Check for no REG_BR_PROB in uninitialized case

2022-05-11 Thread Alexandre Oliva via Gcc-patches


There is an assumption in force_edge_cold that, if any edge out of the
same src block has uninitialized probability, then a conditional
branch out of src won't have REG_BR_PROB set.

This assumption is supposed to hold, but buggy gimple passes may turn
unconditional edges into conditional ones, adding edges with
uninitialized probability out of blocks that retain originally
unconditional edges with precise always probability.  Expand may then
copy the formerly-unconditional edge's probability to REG_BR_PROB, and
if that edge ends up forced cold, the probability in the edge will be
modified without adjusting the note, and rtl_verify_edges complains
about that.

This patch adds checking that REG_BR_PROB is absent to the path taken
by force_cold_edge for uninitialized probabilities, so that the
problem is caught earlier and fixed sooner.

I'm not sure it buys us much, but...  Regstrapped on x86_64-linux-gnu.
Ok to install?


for  gcc/ChangeLog

* predict.cc (force_edge_cold): Check for no REG_BR_PROB in
the uninitialized probability case.
---
 gcc/predict.cc |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/gcc/predict.cc b/gcc/predict.cc
index 5734e4c851630..48ac81624ec4a 100644
--- a/gcc/predict.cc
+++ b/gcc/predict.cc
@@ -4378,7 +4378,19 @@ force_edge_cold (edge e, bool impossible)
   /* If we are not guessing profiles but have some other edges out,
  just assume the control flow goes elsewhere.  */
   if (uninitialized_exit)
-e->probability = goal;
+{
+  e->probability = goal;
+#if CHECKING_P
+  /* We don't expect to have a REG_BR_PROB note to adjust when
+there were edges with uninitialized probabilities.  This
+would be a symptom of creating edges, before expand, without
+assigning probabilities, while other edges have them. */
+  if (current_ir_type () != IR_GIMPLE
+ && e->src != ENTRY_BLOCK_PTR_FOR_FN (cfun))
+   gcc_checking_assert (!find_reg_note (BB_END (e->src),
+REG_BR_PROB, NULL_RTX));
+#endif
+}
   /* If there are other edges out of e->src, redistribute probabilitity
  there.  */
   else if (prob_sum > profile_probability::never ())

-- 
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 


Re: [PATCH v2] Strip of a vector load which is only used partially.

2022-05-11 Thread Hongtao Liu via Gcc-patches
On Tue, May 10, 2022 at 2:54 PM Richard Biener via Gcc-patches
 wrote:
>
> On Mon, May 9, 2022 at 7:11 AM liuhongt via Gcc-patches
>  wrote:
> >
> > Here's adjused patch.
> > Ok for trunk?
> >
> > Optimize
> >
> >   _4 = VEC_PERM_EXPR <_1, _1, { 4, 5, 6, 7, 4, 5, 6, 7 }>;
> >   _5 = BIT_FIELD_REF <_4, 128, 0>;
> >
> > to
> >
> >   _5 = BIT_FIELD_REF <_1, 128, 128>;
> >
> > gcc/ChangeLog:
> >
> > PR tree-optimization/102583
> > * tree-ssa-forwprop.cc (simplify_bitfield_ref): Extended to a
> > contiguous stride in the VEC_PERM_EXPR.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/i386/pr102583.c: New test.
> > * gcc.target/i386/pr92645-2.c: Adjust testcase.
> > * gcc.target/i386/pr92645-3.c: Ditto.
> > ---
> >  gcc/testsuite/gcc.target/i386/pr102583.c  | 30 
> >  gcc/testsuite/gcc.target/i386/pr92645-2.c |  4 +-
> >  gcc/testsuite/gcc.target/i386/pr92645-3.c |  4 +-
> >  gcc/tree-ssa-forwprop.cc  | 89 ---
> >  4 files changed, 96 insertions(+), 31 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr102583.c
> >
> > diff --git a/gcc/testsuite/gcc.target/i386/pr102583.c 
> > b/gcc/testsuite/gcc.target/i386/pr102583.c
> > new file mode 100644
> > index 000..4ef2f296d0c
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/i386/pr102583.c
> > @@ -0,0 +1,30 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-mavx512f -O2" } */
> > +/* { dg-final { scan-assembler-times {(?n)vcvtdq2ps[ \t]+32\(%.*%ymm} 1 } 
> > } */
> > +/* { dg-final { scan-assembler-times {(?n)vcvtdq2ps[ \t]+16\(%.*%xmm} 1 } 
> > } */
> > +/* { dg-final { scan-assembler-times {(?n)vmovq[ \t]+16\(%.*%xmm} 1 { 
> > target { ! ia32 } } } } */
> > +/* { dg-final { scan-assembler-not {(?n)vpermd[ \t]+.*%zmm} } } */
> > +
> > +typedef int v16si __attribute__((vector_size(64)));
> > +typedef float v8sf __attribute__((vector_size(32)));
> > +typedef float v4sf __attribute__((vector_size(16)));
> > +typedef float v2sf __attribute__((vector_size(8)));
> > +
> > +v8sf part (v16si *srcp)
> > +{
> > +  v16si src = *srcp;
> > +  return (v8sf) { (float)src[8], (float) src[9], (float)src[10], 
> > (float)src[11],
> > +  (float)src[12], (float)src[13], (float)src[14], (float)src[15] };
> > +}
> > +
> > +v4sf part1 (v16si *srcp)
> > +{
> > +  v16si src = *srcp;
> > +  return (v4sf) { (float)src[4], (float)src[5], (float)src[6], 
> > (float)src[7] };
> > +}
> > +
> > +v2sf part2 (v16si *srcp)
> > +{
> > +  v16si src = *srcp;
> > +  return (v2sf) { (float)src[4], (float)src[5] };
> > +}
> > diff --git a/gcc/testsuite/gcc.target/i386/pr92645-2.c 
> > b/gcc/testsuite/gcc.target/i386/pr92645-2.c
> > index d34ed3aa8e5..f0608de938a 100644
> > --- a/gcc/testsuite/gcc.target/i386/pr92645-2.c
> > +++ b/gcc/testsuite/gcc.target/i386/pr92645-2.c
> > @@ -29,6 +29,6 @@ void odd (v2si *dst, v4si *srcp)
> >  }
> >
> >  /* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 4 "cddce1" } } */
> > -/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 3 "cddce1" } } */
> > +/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 3 "cddce1" { xfail 
> > *-*-* } } } */
> >  /* Ideally highpart extraction would elide the permutation as well.  */
> > -/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 2 "cddce1" { xfail 
> > *-*-* } } } */
> > +/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 2 "cddce1" } } */
> > diff --git a/gcc/testsuite/gcc.target/i386/pr92645-3.c 
> > b/gcc/testsuite/gcc.target/i386/pr92645-3.c
> > index 9c08c9fb632..691011195c9 100644
> > --- a/gcc/testsuite/gcc.target/i386/pr92645-3.c
> > +++ b/gcc/testsuite/gcc.target/i386/pr92645-3.c
> > @@ -32,6 +32,6 @@ void odd (v4sf *dst, v8si *srcp)
> >  /* Four conversions, on the smaller vector type, to not convert excess
> > elements.  */
> >  /* { dg-final { scan-tree-dump-times " = \\\(vector\\\(4\\\) float\\\)" 4 
> > "cddce1" } } */
> > -/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 3 "cddce1" } } */
> > +/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 3 "cddce1" { xfail 
> > *-*-* } } } */
> >  /* Ideally highpart extraction would elide the VEC_PERM_EXPR as well.  */
> > -/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 2 "cddce1" { xfail 
> > *-*-* } } } */
> > +/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 2 "cddce1" } } */
> > diff --git a/gcc/tree-ssa-forwprop.cc b/gcc/tree-ssa-forwprop.cc
> > index 484491fa1c5..f91f738895d 100644
> > --- a/gcc/tree-ssa-forwprop.cc
> > +++ b/gcc/tree-ssa-forwprop.cc
> > @@ -2334,8 +2334,10 @@ simplify_bitfield_ref (gimple_stmt_iterator *gsi)
> >gimple *stmt = gsi_stmt (*gsi);
> >gimple *def_stmt;
> >tree op, op0, op1;
> > -  tree elem_type;
> > -  unsigned idx, size;
> > +  tree elem_type, type;
> > +  tree p, m, tem;
> > +  unsigned HOST_WIDE_INT nelts;
> > +  unsigned idx, size, elem_size;
> >enum tree_code code;
> >
> >op = gimple_assign_rhs1 (stmt);
> > @@ -2353,42 +2355,75 @@ simplify_bitfield_ref 

[PATCH] [PR105455] Set edge probabilities when hardening conditionals

2022-05-11 Thread Alexandre Oliva via Gcc-patches


When turning unconditional edges into conditional, as in
gimple-harden-conditionals.cc:insert_check_and_trap, the newly-created
edge's probability comes out uninitialized, while the previously
unconditional edge's probability is presumably
profile_probability::always.

Mixing initialized and uninitialized probabilities before expand
breaks predict.cc:force_edge_cold: the initialized probability may end
up copied to a REG_BR_PROB note in a conditional branch insn, but if
force_edge_cold is called on that edge, it will find another edge with
uninitialized probability and assume the note is absent.  Later on,
rtl_verify_edges complains that the note does not match the
probability modified by force_edge_cold in the edge.

This patch sets probabilities for edges affected by hardening of
conditionals, both the newly-created edges to trap blocks and the
previously-unconditional edges, so that the former are considered
never taken, while the latter are confirmed as always taken.

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


for  gcc/ChangeLog

PR rtl-optimization/105455
* gimple-harden-conditionals.cc (insert_check_and_trap): Set
probabilities for newly-conditional edges.

for  gcc/testsuite/ChangeLog

PR rtl-optimization/105455
* gcc.dg/pr105455.c: New.
---
 gcc/gimple-harden-conditionals.cc |2 ++
 gcc/testsuite/gcc.dg/pr105455.c   |   17 +
 2 files changed, 19 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr105455.c

diff --git a/gcc/gimple-harden-conditionals.cc 
b/gcc/gimple-harden-conditionals.cc
index 28c4810f0a78e..240d0e5acd87a 100644
--- a/gcc/gimple-harden-conditionals.cc
+++ b/gcc/gimple-harden-conditionals.cc
@@ -254,8 +254,10 @@ insert_check_and_trap (location_t loc, 
gimple_stmt_iterator *gsip,
  equality.  */
   single_succ_edge (chk)->flags &= ~EDGE_FALLTHRU;
   single_succ_edge (chk)->flags |= neg_true_false_flag;
+  single_succ_edge (chk)->probability = profile_probability::always ();
   edge e = make_edge (chk, trp, true_false_flag);
   e->goto_locus = loc;
+  e->probability = profile_probability::never ();
 
   if (dom_info_available_p (CDI_DOMINATORS))
 set_immediate_dominator (CDI_DOMINATORS, trp, chk);
diff --git a/gcc/testsuite/gcc.dg/pr105455.c b/gcc/testsuite/gcc.dg/pr105455.c
new file mode 100644
index 0..81e9154baa1c3
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr105455.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fharden-conditional-branches -funroll-loops --param 
max-loop-header-insns=1" } */
+
+__attribute__ ((cold)) void
+bar (void);
+
+void
+foo (int x)
+{
+  if (x)
+{
+  int i;
+
+  for (i = 0; i < 101; ++i)
+bar ();
+}
+}


-- 
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] Avoid visiting newly-created blocks in harden-conditionals

2022-05-11 Thread Alexandre Oliva via Gcc-patches


Reverse iteration over blocks, in gimple-harden-conditionals.cc, was
supposed to avoid visiting blocks introduced by hardening and
introducing further reversed conditionals and traps for them, but
newly-created blocks may be inserted before the current block, as
shown by the PR105455 testcase.

New blocks use and increment last block number, so test the block
index against the initial last block number to skip new blocks.

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


for  gcc/ChangeLog

* gimple-harden-conditionals.cc
(pass_harden_conditional_branches::execute): Skip new blocks.
(pass_harden_compares::execute): Likewise.
---
 gcc/gimple-harden-conditionals.cc |  401 +++--
 1 file changed, 211 insertions(+), 190 deletions(-)

diff --git a/gcc/gimple-harden-conditionals.cc 
b/gcc/gimple-harden-conditionals.cc
index c7e5e077a74f6..28c4810f0a78e 100644
--- a/gcc/gimple-harden-conditionals.cc
+++ b/gcc/gimple-harden-conditionals.cc
@@ -301,9 +301,18 @@ insert_edge_check_and_trap (location_t loc, edge e,
 unsigned int
 pass_harden_conditional_branches::execute (function *fun)
 {
+  int orig_last_block = last_basic_block_for_fn (fun);
+
   basic_block bb;
   FOR_EACH_BB_REVERSE_FN (bb, fun)
 {
+  /* Despite our backwards iteration on basic blocks, sometimes
+split_edge will insert the new block before the block we're
+hardening, and then we'd harden the hardening block.  Skip
+newly-created blocks to avoid that.  */
+  if (bb->index >= orig_last_block)
+   continue;
+
   gimple_stmt_iterator gsi = gsi_last_bb (bb);
 
   if (gsi_end_p (gsi))
@@ -383,6 +392,8 @@ non_eh_succ_edge (basic_block bb, edge *ehp = NULL)
 unsigned int
 pass_harden_compares::execute (function *fun)
 {
+  int orig_last_block = last_basic_block_for_fn (fun);
+
   basic_block bb;
   /* Go backwards over BBs and stmts, so that, even if we split the
  block multiple times to insert a cond_expr after each compare we
@@ -390,198 +401,208 @@ pass_harden_compares::execute (function *fun)
  stmt exactly once, and not visiting newly-added blocks or
  stmts.  */
   FOR_EACH_BB_REVERSE_FN (bb, fun)
-for (gimple_stmt_iterator gsi = gsi_last_bb (bb);
-!gsi_end_p (gsi); gsi_prev ())
-  {
-   gassign *asgn = dyn_cast  (gsi_stmt (gsi));
-   if (!asgn)
- continue;
-
-   /* Turn:
-
-  z = x op y;
-
-  into:
-
-  z = x op y;
-  z' = x' cop y';
-  if (z == z') __builtin_trap ();
-
-  where cop is a complementary boolean operation to op; and x'
-  and y' hold the same value as x and y, but in a way that does
-  not enable the compiler to optimize the redundant compare
-  away.
-   */
-
-   enum tree_code op = gimple_assign_rhs_code (asgn);
-
-   enum tree_code cop;
-
-   switch (op)
- {
- case EQ_EXPR:
- case NE_EXPR:
- case GT_EXPR:
- case GE_EXPR:
- case LT_EXPR:
- case LE_EXPR:
- case LTGT_EXPR:
- case UNEQ_EXPR:
- case UNGT_EXPR:
- case UNGE_EXPR:
- case UNLT_EXPR:
- case UNLE_EXPR:
- case ORDERED_EXPR:
- case UNORDERED_EXPR:
-   cop = invert_tree_comparison (op,
- HONOR_NANS
- (gimple_assign_rhs1 (asgn)));
-
-   if (cop == ERROR_MARK)
- /* ??? Can we do better?  */
- continue;
+{
+  /* Despite our backwards iteration on basic blocks, sometimes
+split_edge will insert the new block before the block we're
+hardening, and then we'd harden the hardening block.  Skip
+newly-created blocks to avoid that.  */
+  if (bb->index >= orig_last_block)
+   continue;
 
-   break;
-
-   /* ??? Maybe handle these too?  */
- case TRUTH_NOT_EXPR:
-   /* ??? The code below assumes binary ops, it would have to
-  be adjusted for TRUTH_NOT_EXPR, since it's unary.  */
- case TRUTH_ANDIF_EXPR:
- case TRUTH_ORIF_EXPR:
- case TRUTH_AND_EXPR:
- case TRUTH_OR_EXPR:
- case TRUTH_XOR_EXPR:
- default:
+  for (gimple_stmt_iterator gsi = gsi_last_bb (bb);
+  !gsi_end_p (gsi); gsi_prev ())
+   {
+ gassign *asgn = dyn_cast  (gsi_stmt (gsi));
+ if (!asgn)
+   continue;
+
+ /* Turn:
+
+z = x op y;
+
+into:
+
+z = x op y;
+z' = x' cop y';
+if (z == z') __builtin_trap ();
+
+where cop is a complementary boolean operation to op; and x'
+and y' hold the same value as x and y, but in a way that does
+not enable the compiler to optimize the redundant compare
+away.
+ */
+
+ enum tree_code op = gimple_assign_rhs_code 

Re: [PATCH] Fold GCC_VERSION >= $old_version to TRUE, otherwise to FALSE.

2022-05-11 Thread Eric Gallager via Gcc-patches
On Thu, May 5, 2022 at 2:26 PM Martin Liška  wrote:
>
> On 5/5/22 14:24, Richard Biener wrote:
> > Hmm, but we support C++11 host compilers that are not GCC but
> > may claim to be, with GCC_VERSION 4.2.x for example.  Are we sure
> > all those liars implement what we guard with the version checks?
>
> Do you know about any real example of such a liars?
> Why should we even care about them?
>

Well, there's clang, for one (which pretends to be gcc 4.2), which is
kind of a big deal...

> Martin
>
> >
> > I suppose to be "correct" we'd at least need to preserve
> > #if __GNUC__
> > in places where we might use the host compiler?  (if compilers then lie
> > it's their own fault)
>


RE: [EXTERNAL] Re: [PATCH] Guard against applying scale with 0 denominator

2022-05-11 Thread Eugene Rozenfeld via Gcc-patches
In my case this is not exactly what the FIXME in the comment above says. The 
count is 0 even before
the initial scaling happens. I hit this case with some changes I'm working on 
to enable per-instruction discriminators for AutoFDO.

I looked into saving/restoring the old counts but it would be awkward to do. 
The initial scaling happens here:

if (skip_vector)
{
  split_edge (loop_preheader_edge (loop));

  /* Due to the order in which we peel prolog and epilog, we first
 propagate probability to the whole loop.  The purpose is to
 avoid adjusting probabilities of both prolog and vector loops
 separately.  Note in this case, the probability of epilog loop
 needs to be scaled back later.  */
  basic_block bb_before_loop = loop_preheader_edge (loop)->src;
  if (prob_vector.initialized_p ())
{
  scale_bbs_frequencies (_before_loop, 1, prob_vector);
  scale_loop_profile (loop, prob_vector, 0);
}
}

The scaling happens before we do the cloning for the epilog so to save/restore 
the counts
we would need to maintain a mapping between the original basic blocks and the 
cloned basic blocks in the epilog.

I'd like to get my simple fix in since it makes things better even if it 
doesn't address the issue mentioned
In the FIXME.

-Original Message-
From: Richard Biener  
Sent: Monday, May 09, 2022 12:42 AM
To: Eugene Rozenfeld ; Jan Hubicka 

Cc: gcc-patches@gcc.gnu.org
Subject: [EXTERNAL] Re: [PATCH] Guard against applying scale with 0 denominator

On Fri, May 6, 2022 at 10:32 PM Eugene Rozenfeld via Gcc-patches 
 wrote:
>
> Calling count.apply_scale with a 0 denominator causes an assert.
> This change guards against that.
>
> Tested on x86_64-pc-linux-gnu.
>
> gcc/ChangeLog:
> * tree-loop-vect-manip.cc (vect_do_peeling): Guard against applying 
> scale with 0 denominator.
> ---
>  gcc/tree-vect-loop-manip.cc | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc 
> index 1d4337eb261..db54ae69e45 100644
> --- a/gcc/tree-vect-loop-manip.cc
> +++ b/gcc/tree-vect-loop-manip.cc
> @@ -2989,10 +2989,11 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree 
> niters, tree nitersm1,
>  get lost if we scale down to 0.  */
>   basic_block *bbs = get_loop_body (epilog);
>   for (unsigned int i = 0; i < epilog->num_nodes; i++)
> -   bbs[i]->count = bbs[i]->count.apply_scale
> -(bbs[i]->count,
> - bbs[i]->count.apply_probability
> -   (prob_vector));
> +   if (bbs[i]->count.nonzero_p ())
> + bbs[i]->count = bbs[i]->count.apply_scale
> +  (bbs[i]->count,
> +   bbs[i]->count.apply_probability
> + (prob_vector));

So exactly what the FIXME in the comment above says happens.   It
might be better
to save/restore the old counts if the intent is to get them back.  I'm not 
exactly sure where the other scaling happens though.

Richard.



>   free (bbs);
> }
>
> --
> 2.25.1


[committed] analyzer: fix memory leaks

2022-05-11 Thread David Malcolm via Gcc-patches
These leaks all relate to logging within -fdump-analyzer[-stderr]
or are one-time leaks; seen with valgrind.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Tested with valgrind.
Pushed to trunk as r13-334-g99988b0e8b57b3.

gcc/analyzer/ChangeLog:
* checker-path.cc (state_change_event::get_desc): Call maybe_free
on label_text temporaries.
* diagnostic-manager.cc
(diagnostic_manager::prune_for_sm_diagnostic): Likewise.
* engine.cc (exploded_graph::~exploded_graph): Fix leak of
m_per_point_data and m_per_call_string_data values.  Simplify
cleanup of m_per_function_stats and m_per_point_data values.
(feasibility_state::maybe_update_for_edge): Fix leak of result of
superedge::get_description.
* region-model-manager.cc
(region_model_manager::~region_model_manager): Move cleanup of
m_setjmp_values to match the ordering of the fields within
region_model_manager.  Fix leak of values within
m_repeated_values_map, m_bits_within_values_map,
m_asm_output_values_map, and m_const_fn_result_values_map.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/checker-path.cc |  8 ++--
 gcc/analyzer/diagnostic-manager.cc   |  6 ++
 gcc/analyzer/engine.cc   | 29 +++-
 gcc/analyzer/region-model-manager.cc | 14 +++---
 4 files changed, 39 insertions(+), 18 deletions(-)

diff --git a/gcc/analyzer/checker-path.cc b/gcc/analyzer/checker-path.cc
index 779ff80de7c..a61b3ee0675 100644
--- a/gcc/analyzer/checker-path.cc
+++ b/gcc/analyzer/checker-path.cc
@@ -323,24 +323,28 @@ state_change_event::get_desc (bool can_colorize) const
   if (m_sval)
 {
   label_text sval_desc = m_sval->get_desc ();
+  label_text result;
   if (m_origin)
{
  label_text origin_desc = m_origin->get_desc ();
- return make_label_text
+ result = make_label_text
(can_colorize,
 "state of %qs: %qs -> %qs (origin: %qs)",
 sval_desc.m_buffer,
 m_from->get_name (),
 m_to->get_name (),
 origin_desc.m_buffer);
+ origin_desc.maybe_free ();
}
   else
-   return make_label_text
+   result = make_label_text
  (can_colorize,
   "state of %qs: %qs -> %qs (NULL origin)",
   sval_desc.m_buffer,
   m_from->get_name (),
   m_to->get_name ());
+  sval_desc.maybe_free ();
+  return result;
 }
   else
 {
diff --git a/gcc/analyzer/diagnostic-manager.cc 
b/gcc/analyzer/diagnostic-manager.cc
index 5bd4cd49cac..2d49a3bc6ad 100644
--- a/gcc/analyzer/diagnostic-manager.cc
+++ b/gcc/analyzer/diagnostic-manager.cc
@@ -2171,6 +2171,7 @@ diagnostic_manager::prune_for_sm_diagnostic (checker_path 
*path,
  log ("considering event %i (%s), with sval: %qs, state: %qs",
   idx, event_kind_to_string (base_event->m_kind),
   sval_desc.m_buffer, state->get_name ());
+ sval_desc.maybe_free ();
}
  else
log ("considering event %i (%s), with global state: %qs",
@@ -2238,6 +2239,8 @@ diagnostic_manager::prune_for_sm_diagnostic (checker_path 
*path,
 " switching var of interest from %qs to %qs",
 idx, sval_desc.m_buffer,
 origin_sval_desc.m_buffer);
+   sval_desc.maybe_free ();
+   origin_sval_desc.maybe_free ();
  }
sval = state_change->m_origin;
  }
@@ -2265,6 +2268,7 @@ diagnostic_manager::prune_for_sm_diagnostic (checker_path 
*path,
else
  log ("filtering event %i: state change to %qs",
   idx, change_sval_desc.m_buffer);
+   change_sval_desc.maybe_free ();
  }
else
  log ("filtering event %i: global state change", idx);
@@ -2334,6 +2338,7 @@ diagnostic_manager::prune_for_sm_diagnostic (checker_path 
*path,
 " recording critical state for %qs at call"
 " from %qE in callee to %qE in caller",
 idx, sval_desc.m_buffer, callee_var, caller_var);
+   sval_desc.maybe_free ();
  }
if (expr.param_p ())
  event->record_critical_state (caller_var, state);
@@ -2377,6 +2382,7 @@ diagnostic_manager::prune_for_sm_diagnostic (checker_path 
*path,
 " recording critical state for %qs at return"
 " from %qE in caller to %qE in callee",
 idx, sval_desc.m_buffer, callee_var, callee_var);
+   sval_desc.maybe_free ();
  }
  

Re: [PATCH] options: Make -Ofast switch off -fsemantic-interposition

2022-05-11 Thread Fāng-ruì Sòng via Gcc-patches
On Fri, Nov 19, 2021 at 9:55 AM Martin Jambor  wrote:
>
> Hi,
>
> On Fri, Nov 19 2021, Jan Hubicka wrote:
> >> > Hi,
> >> >
> >> > On Fri, Nov 12 2021, Martin Jambor wrote:
> >> > > Hi,
> >> > >
> >> > > using -fno-semantic-interposition has been reported by various people
> >> > > to bring about considerable speed up at the cost of strict compliance
> >> > > to the ELF symbol interposition rules  See for example
> >> > > https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
> >> > >
> >> > > As such I believe it should be implied by our -Ofast optimization
> >> > > level, not only so that benchmarks that can benefit run faster, but
> >> > > also so that people looking at -Ofast documentation for options that
> >> > > could speed their programs find it.
> >> > >
> >> > > I have verified that with the following patch IPA-CP sees
> >> > > flag_semantic_interposition set to zero at Ofast and that info and pdf
> >> > > manual builds fine with the documentation change.  I am bootstrapping
> >> > > and testing it now in order to comply with submission criteria but I
> >> > > don't think an Ofast change gets much tested.
> >> > >
> >> > > Assuming it passes, is the patch OK?  (If it is, I will also add a note
> >> > > about it in the "Caveats" section in gcc-12/changes.html of wwwdocs
> >> > > after I commit the patch.)
> >> > >
> >> >
> >> > Unfortunately, I was wrong, there are testcases which use the optimize
> >> > attribute to switch a function to Ofast and those ICE because
> >> > -fsemantic-interposition is not an optimization flag and only
> >> > optimization flags can change in an optimize attribute (AFAIK, I only
> >> > had a quick glance at the results).
> >> >
> >> > I am not sure what is the right way to tackle this, whether to set the
> >> > flag at Ofast in some nonstandard way or make the flag an optimization
> >> > flag - probably affecting function definitions, having it affect
> >> > call-sites seems too fine-grained.  I will try to discuss this on IRC on
> >> > Monday (and hope such change is still doable early stage3).
> >> >
> >> > Sorry for posting this a bit prematurely,
> >>
> >> Hi,
> >>
> >> This patch turns flag_semantic_interposition to optimization option so
> >> it can be enabled with per-function granuality.  This is done by adding
> >> the flag among visibility flags into the symbol table.  This fixes the
> >> behaviour on the testcase I added to testsuite.
> >>
> >> There are bugs where get_availability misbehaves on partitioned program.
> >> We can also use the new flag to fix those, but I will do that
> >> incrementally.
> >>
> >> The -Ofast change should be safe now.
> >
> > Also forgot to say it explicitly, the patch is OK, so please commit it.
> >
>
> Thanks a lot for the enabling patch.  I have committed mine after re-testing.
>
> Martin

Perhaps reconsider https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937
(configure: Add --enable-default-semantic-interposition)?
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572018.html

I happen a write-up on
https://maskray.me/blog/2021-05-09-fno-semantic-interposition

-- 
宋方睿


[committed] wwwdocs: branching: Editorial changes re branch_changer.py

2022-05-11 Thread Gerald Pfeifer
This is a minor follow-up to Martin's patch

  commit 6b788fa278b4f863a17ab80e0bf4991c3d8de167
  Author: Martin Liska 
  Date:   Mon Apr 19 14:55:54 2021 +0200

Move branch_changer.py usage to branching.html.

though the markup predates his change (which merely made me notice it).

Pushed.

Gerald


diff --git a/htdocs/branching.html b/htdocs/branching.html
index 40d65271..d3d26ff9 100644
--- a/htdocs/branching.html
+++ b/htdocs/branching.html
@@ -101,13 +101,13 @@ release on the branch.  For example, when branching 3.4, 
create a
 milestone for 3.4.1 for PRs that can't be fixed in time for 3.4.0.
 
 Bug regression summary needs to adjusted by 
maintainer-scripts/branch_changer.py with the following arguments:
-
-./maintainer-scripts/branch_changer.py api_key --add=11:12
-
 
-The script adds '/12' to all PRs marked with a '[Regression x/y/z]' summary 
line.
+
+./maintainer-scripts/branch_changer.py api_key --add=11:12
+
 
-Again, unless you add --doit, the script runs in dry mode 
only.
+The script adds '/12' to all PRs marked with a '[Regression x/y/z]' summary 
line.
+(Unless you add --doit, the script runs in dry mode only.)
 
 
 


[PATCH v2] x86: Document -mcet-switch

2022-05-11 Thread H.J. Lu via Gcc-patches
When -fcf-protection=branch is used, the compiler will generate jump
tables for switch statements where the indirect jump is prefixed with
the NOTRACK prefix, so it can jump to non-ENDBR targets.  Since the
indirect jump targets are generated by the compiler, they are always
valid.

Document -mcet-switch to generate jump tables for switch statements with
ENDBR and skip the NOTRACK prefix for indirect jump.  This option should
be used when the NOTRACK prefix is disabled.

PR target/104816
* config/i386/i386.opt: Remove Undocumented.
* doc/invoke.texi: Document -mcet-switch.
---
 gcc/config/i386/i386.opt | 2 +-
 gcc/doc/invoke.texi  | 8 +++-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
index a6b0e28f238..0dbaacb57ed 100644
--- a/gcc/config/i386/i386.opt
+++ b/gcc/config/i386/i386.opt
@@ -1047,7 +1047,7 @@ Enable shadow stack built-in functions from Control-flow 
Enforcement
 Technology (CET).
 
 mcet-switch
-Target Undocumented Var(flag_cet_switch) Init(0)
+Target Var(flag_cet_switch) Init(0)
 Turn on CET instrumentation for switch statements that use a jump table and
 an indirect jump.
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 7a35d9613a4..968853690f9 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1420,7 +1420,8 @@ See RS/6000 and PowerPC Options.
 -msse4a  -m3dnow  -m3dnowa  -mpopcnt  -mabm  -mbmi  -mtbm  -mfma4  -mxop @gol
 -madx  -mlzcnt  -mbmi2  -mfxsr  -mxsave  -mxsaveopt  -mrtm  -mhle  -mlwp @gol
 -mmwaitx  -mclzero  -mpku  -mthreads  -mgfni  -mvaes  -mwaitpkg @gol
--mshstk -mmanual-endbr -mforce-indirect-call  -mavx512vbmi2 -mavx512bf16 
-menqcmd @gol
+-mshstk -mmanual-endbr -mcet-switch -mforce-indirect-call @gol
+-mavx512vbmi2 -mavx512bf16 -menqcmd @gol
 -mvpclmulqdq  -mavx512bitalg  -mmovdiri  -mmovdir64b  -mavx512vpopcntdq @gol
 -mavx5124fmaps  -mavx512vnni  -mavx5124vnniw  -mprfchw  -mrdpid @gol
 -mrdseed  -msgx -mavx512vp2intersect -mserialize -mtsxldtrk@gol
@@ -32641,6 +32642,11 @@ function attribute. This is useful when used with the 
option
 @option{-fcf-protection=branch} to control ENDBR insertion at the
 function entry.
 
+@item -mcet-switch
+@opindex mcet-switch
+Turn on CET instrumentation for switch statements that use a jump table
+and an indirect jump.
+
 @item -mcall-ms2sysv-xlogues
 @opindex mcall-ms2sysv-xlogues
 @opindex mno-call-ms2sysv-xlogues
-- 
2.35.1



Re: [PATCH] x86: Document -mno-cet-switch

2022-05-11 Thread H.J. Lu via Gcc-patches
On Wed, May 11, 2022 at 12:02 PM Florian Weimer  wrote:
>
> * H. J. Lu:
>
> > On Wed, May 11, 2022 at 11:45 AM Florian Weimer  wrote:
> >>
> >> * H. J. Lu:
> >>
> >> >> NOTRACK avoids the need for ENDBR instructions, right?  That's a
> >> >> hardening improvement, so it should be used by default.
> >> >
> >> > NOTRACK weakens IBT since it disables IBT on the indirect jump 
> >> > instruction.
> >> > GCC uses it in the jump table to avoid ENDBR.
> >>
> >> Typical jump table code looks like this:
> >>
> >> Dump of assembler code for function __cache_sysconf:
> >>0x000f7a80 <+0>: endbr64
> >>0x000f7a84 <+4>: sub$0xb9,%edi
> >>0x000f7a8a <+10>:cmp$0xc,%edi
> >>0x000f7a8d <+13>:ja 0xf7b70 <__cache_sysconf+240>
> >>0x000f7a93 <+19>:lea0xba926(%rip),%rdx# 0x1b23c0
> >>0x000f7a9a <+26>:movslq (%rdx,%rdi,4),%rax
> >>0x000f7a9e <+30>:add%rdx,%rax
> >>0x000f7aa1 <+33>:notrack jmp *%rax
> >>
> >> There's no ENDBR instruction between range check, the address
> >> computation, and the NOTRACK JMP, so it's not possible to redirect that
> >> JMP to some other place.
> >
> > That is the assumption we made.   RAX will always point to the valid
> > address.
>
> Which means that NOTRACK should not weaken anything here.  What am I
> missing?
>

I will send out the v2 patch to document -mcet-switch instead.

-- 
H.J.


Re: [PATCH] Use more ARRAY_SIZE.

2022-05-11 Thread David Malcolm via Gcc-patches
On Wed, 2022-05-11 at 15:04 -0400, Eric Gallager wrote:
> On Wed, May 11, 2022 at 9:53 AM David Malcolm via Gcc-patches
>  wrote:
> > 
> > On Thu, 2022-05-05 at 14:16 +0200, Martin Liška wrote:
> > > Patch can bootstrap on x86_64-linux-gnu and survives regression
> > > tests.
> > > 
> > > Ready to be installed?
> > 
> > I looked over the changes to:
> > 
> >   gcc/analyzer/*.cc
> >   gcc/input.cc
> >   gcc/jit/*.cc
> > 
> > and they look good to me.
> > 
> > I assume that you enabled "jit" during the testing, right?  (it's
> > not
> > in --enable-languages=all, which is a perennial source of issues).
> > 
> 
> So, what remains to be done to include "jit" in "all" anyways? Are
> there still some platforms left that it's not supported on yet or
> something?

IIRC the issue was that it requires --enable-host-shared, which slows
down the compiler for everyone else by a few percent (since it requires
the compiler to be built as position-independent code). 

Dave



[pushed] c++: lambda template in requires [PR105541]

2022-05-11 Thread Jason Merrill via Gcc-patches
Since the patch for PR103408, the template parameters for the lambda in this
test have level 1 instead of 2, and we were treating null template args as 1
level of arguments, so tsubst_template_parms decided it had nothing to do.
Fixed by distinguishing between <> and no args at all, which is what we have
in our "substitution" in a requires-expression.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/105541

gcc/cp/ChangeLog:

* cp-tree.h (TMPL_ARGS_DEPTH): 0 for null args.
* parser.cc (cp_parser_enclosed_template_argument_list):
Use 0-length TREE_VEC for <>.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-requires1.C: New test.
---
 gcc/cp/cp-tree.h  | 12 +++-
 gcc/cp/parser.cc  |  5 -
 gcc/testsuite/g++.dg/cpp2a/lambda-requires1.C |  4 
 3 files changed, 15 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-requires1.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index e16b8d70846..b6961a796af 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -3771,11 +3771,13 @@ struct GTY(()) lang_decl {
 
 /* The depth of a template argument vector.  When called directly by
the parser, we use a TREE_LIST rather than a TREE_VEC to represent
-   template arguments.  In fact, we may even see NULL_TREE if there
-   are no template arguments.  In both of those cases, there is only
-   one level of template arguments.  */
-#define TMPL_ARGS_DEPTH(NODE)  \
-  (TMPL_ARGS_HAVE_MULTIPLE_LEVELS (NODE) ? TREE_VEC_LENGTH (NODE) : 1)
+   template arguments.  In that case, there is only one level of template
+   arguments.  We may even see NULL_TREE if there are 0 levels of
+   template arguments, as in cp_parser_requires_expression.   */
+#define TMPL_ARGS_DEPTH(NODE)  \
+  ((NODE) == NULL_TREE ? 0 \
+   : TMPL_ARGS_HAVE_MULTIPLE_LEVELS (NODE) ? TREE_VEC_LENGTH (NODE)\
+   : 1)
 
 /* The LEVELth level of the template ARGS.  The outermost level of
args is level 1, not level 0.  */
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 4ed9feaa427..d09d5b7c8b7 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -32151,7 +32151,10 @@ cp_parser_enclosed_template_argument_list (cp_parser* 
parser)
   || cp_lexer_next_token_is (parser->lexer, CPP_RSHIFT)
   || cp_lexer_next_token_is (parser->lexer, CPP_GREATER_EQ)
   || cp_lexer_next_token_is (parser->lexer, CPP_RSHIFT_EQ))
-arguments = NULL_TREE;
+{
+  arguments = make_tree_vec (0);
+  SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (arguments, 0);
+}
   else
 arguments = cp_parser_template_argument_list (parser);
   /* Look for the `>' that ends the template-argument-list. If we find
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-requires1.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-requires1.C
new file mode 100644
index 000..fdfdaebcf6a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-requires1.C
@@ -0,0 +1,4 @@
+// PR c++/105541
+// { dg-do compile { target c++20 } }
+
+static_assert(requires { []{}; });

base-commit: 4dc86f716fe6087f1cf786d69c0c6f3f5af810f0
-- 
2.27.0



Re: [PATCH] tree: introduce range adaptor for TREE_VEC

2022-05-11 Thread Jason Merrill via Gcc-patches

On 5/11/22 15:20, Patrick Palka wrote:

This patch implements a simple tree wrapper, named tree_vec_range, which
lets us idiomatically iterate over all the elements of a TREE_VEC using
a C++11 range-based for loop:

   // v is a TREE_VEC
   for (tree e : tree_vec_range (v))
 ...

This is similar to the existing tree-based range adaptors ovl_range and
lkp_range added to the C++ frontend by r12-340-g3307b9a07a3c51.

This patch also converts some existing loops over TREE_VEC within the
C++ frontend to use tree_vec_range and range-for.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
useful?


OK.


gcc/cp/ChangeLog:

* constraint.cc (tsubst_parameter_mapping): Convert loop over
TREE_VEC into a range-based for loop using tree_vec_range.
* pt.cc (iterative_hash_template_arg): Likewise.
(template_parms_level_to_args): Likewise (and simplify).
(deducible_template_args): Likewise.
(check_undeduced_parms): Likewise.
(dependent_type_p_r): Likewise.
(value_dependent_expression_p) :
Likewise.
(dependent_template_arg_p): Likewise.
* tree.cc (cp_walk_subtrees) :
Likewise.

gcc/ChangeLog:

* tree.h (TREE_VEC_BEGIN): Define.
(TREE_VEC_END): Correct access of length member.
(class tree_vec_range): Define.
---
  gcc/cp/constraint.cc |  9 +++
  gcc/cp/pt.cc | 57 +---
  gcc/cp/tree.cc   |  5 ++--
  gcc/tree.h   | 15 +++-
  4 files changed, 41 insertions(+), 45 deletions(-)

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 94f6222b436..591155cee22 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2348,12 +2348,9 @@ tsubst_parameter_mapping (tree map, tree args, 
subst_info info)
if (TREE_CODE (new_arg) == TYPE_ARGUMENT_PACK)
{
  tree pack_args = ARGUMENT_PACK_ARGS (new_arg);
- for (int i = 0; i < TREE_VEC_LENGTH (pack_args); i++)
-   {
- tree& pack_arg = TREE_VEC_ELT (pack_args, i);
- if (TYPE_P (pack_arg))
-   pack_arg = canonicalize_type_argument (pack_arg, complain);
-   }
+ for (tree& pack_arg : tree_vec_range (pack_args))
+   if (TYPE_P (pack_arg))
+ pack_arg = canonicalize_type_argument (pack_arg, complain);
}
if (new_arg == error_mark_node)
return error_mark_node;
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 9932d861af6..2c7c5f8bb5d 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -1811,8 +1811,8 @@ iterative_hash_template_arg (tree arg, hashval_t val)
return iterative_hash_object (IDENTIFIER_HASH_VALUE (arg), val);
  
  case TREE_VEC:

-  for (int i = 0, len = TREE_VEC_LENGTH (arg); i < len; ++i)
-   val = iterative_hash_template_arg (TREE_VEC_ELT (arg, i), val);
+  for (tree elt : tree_vec_range (arg))
+   val = iterative_hash_template_arg (elt, val);
return val;
  
  case TYPE_PACK_EXPANSION:

@@ -4883,15 +4883,15 @@ template_parm_to_arg (tree t)
  tree
  template_parms_level_to_args (tree parms)
  {
-  tree a = copy_node (parms);
-  TREE_TYPE (a) = NULL_TREE;
-  for (int i = TREE_VEC_LENGTH (a) - 1; i >= 0; --i)
-TREE_VEC_ELT (a, i) = template_parm_to_arg (TREE_VEC_ELT (a, i));
+  parms = copy_node (parms);
+  TREE_TYPE (parms) = NULL_TREE;
+  for (tree& parm : tree_vec_range (parms))
+parm = template_parm_to_arg (parm);
  
if (CHECKING_P)

-SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (a, TREE_VEC_LENGTH (a));
+SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (parms, TREE_VEC_LENGTH (parms));
  
-  return a;

+  return parms;
  }
  
  /* Given a set of template parameters, return them as a set of template

@@ -22470,10 +22470,9 @@ deducible_array_bound (tree domain)
  static bool
  deducible_template_args (tree args)
  {
-  for (int i = 0; i < TREE_VEC_LENGTH (args); ++i)
+  for (tree elt : tree_vec_range (args))
  {
bool deducible;
-  tree elt = TREE_VEC_ELT (args, i);
if (ARGUMENT_PACK_P (elt))
deducible = deducible_template_args (ARGUMENT_PACK_ARGS (elt));
else
@@ -24844,12 +24843,11 @@ static bool
  check_undeduced_parms (tree targs, tree args, tree end)
  {
bool found = false;
-  int i;
-  for (i = TREE_VEC_LENGTH (targs) - 1; i >= 0; --i)
-if (TREE_VEC_ELT (targs, i) == NULL_TREE)
+  for (tree& targ : tree_vec_range (targs))
+if (targ == NULL_TREE)
{
found = true;
-   TREE_VEC_ELT (targs, i) = error_mark_node;
+   targ = error_mark_node;
}
if (found)
  {
@@ -27288,10 +27286,9 @@ dependent_type_p_r (tree type)
if (TREE_CODE (type) == TYPE_ARGUMENT_PACK)
  {
tree args = ARGUMENT_PACK_ARGS (type);
-  int i, len = TREE_VEC_LENGTH (args);
-  for (i = 0; i < len; ++i)
-if (dependent_template_arg_p (TREE_VEC_ELT (args, i)))
-  return true;
+  for (tree arg : 

[PATCH] tree: introduce range adaptor for TREE_VEC

2022-05-11 Thread Patrick Palka via Gcc-patches
This patch implements a simple tree wrapper, named tree_vec_range, which
lets us idiomatically iterate over all the elements of a TREE_VEC using
a C++11 range-based for loop:

  // v is a TREE_VEC
  for (tree e : tree_vec_range (v))
...

This is similar to the existing tree-based range adaptors ovl_range and
lkp_range added to the C++ frontend by r12-340-g3307b9a07a3c51.

This patch also converts some existing loops over TREE_VEC within the
C++ frontend to use tree_vec_range and range-for.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
useful?

gcc/cp/ChangeLog:

* constraint.cc (tsubst_parameter_mapping): Convert loop over
TREE_VEC into a range-based for loop using tree_vec_range.
* pt.cc (iterative_hash_template_arg): Likewise.
(template_parms_level_to_args): Likewise (and simplify).
(deducible_template_args): Likewise.
(check_undeduced_parms): Likewise.
(dependent_type_p_r): Likewise.
(value_dependent_expression_p) :
Likewise.
(dependent_template_arg_p): Likewise.
* tree.cc (cp_walk_subtrees) :
Likewise.

gcc/ChangeLog:

* tree.h (TREE_VEC_BEGIN): Define.
(TREE_VEC_END): Correct access of length member.
(class tree_vec_range): Define.
---
 gcc/cp/constraint.cc |  9 +++
 gcc/cp/pt.cc | 57 +---
 gcc/cp/tree.cc   |  5 ++--
 gcc/tree.h   | 15 +++-
 4 files changed, 41 insertions(+), 45 deletions(-)

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 94f6222b436..591155cee22 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2348,12 +2348,9 @@ tsubst_parameter_mapping (tree map, tree args, 
subst_info info)
   if (TREE_CODE (new_arg) == TYPE_ARGUMENT_PACK)
{
  tree pack_args = ARGUMENT_PACK_ARGS (new_arg);
- for (int i = 0; i < TREE_VEC_LENGTH (pack_args); i++)
-   {
- tree& pack_arg = TREE_VEC_ELT (pack_args, i);
- if (TYPE_P (pack_arg))
-   pack_arg = canonicalize_type_argument (pack_arg, complain);
-   }
+ for (tree& pack_arg : tree_vec_range (pack_args))
+   if (TYPE_P (pack_arg))
+ pack_arg = canonicalize_type_argument (pack_arg, complain);
}
   if (new_arg == error_mark_node)
return error_mark_node;
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 9932d861af6..2c7c5f8bb5d 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -1811,8 +1811,8 @@ iterative_hash_template_arg (tree arg, hashval_t val)
   return iterative_hash_object (IDENTIFIER_HASH_VALUE (arg), val);
 
 case TREE_VEC:
-  for (int i = 0, len = TREE_VEC_LENGTH (arg); i < len; ++i)
-   val = iterative_hash_template_arg (TREE_VEC_ELT (arg, i), val);
+  for (tree elt : tree_vec_range (arg))
+   val = iterative_hash_template_arg (elt, val);
   return val;
 
 case TYPE_PACK_EXPANSION:
@@ -4883,15 +4883,15 @@ template_parm_to_arg (tree t)
 tree
 template_parms_level_to_args (tree parms)
 {
-  tree a = copy_node (parms);
-  TREE_TYPE (a) = NULL_TREE;
-  for (int i = TREE_VEC_LENGTH (a) - 1; i >= 0; --i)
-TREE_VEC_ELT (a, i) = template_parm_to_arg (TREE_VEC_ELT (a, i));
+  parms = copy_node (parms);
+  TREE_TYPE (parms) = NULL_TREE;
+  for (tree& parm : tree_vec_range (parms))
+parm = template_parm_to_arg (parm);
 
   if (CHECKING_P)
-SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (a, TREE_VEC_LENGTH (a));
+SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (parms, TREE_VEC_LENGTH (parms));
 
-  return a;
+  return parms;
 }
 
 /* Given a set of template parameters, return them as a set of template
@@ -22470,10 +22470,9 @@ deducible_array_bound (tree domain)
 static bool
 deducible_template_args (tree args)
 {
-  for (int i = 0; i < TREE_VEC_LENGTH (args); ++i)
+  for (tree elt : tree_vec_range (args))
 {
   bool deducible;
-  tree elt = TREE_VEC_ELT (args, i);
   if (ARGUMENT_PACK_P (elt))
deducible = deducible_template_args (ARGUMENT_PACK_ARGS (elt));
   else
@@ -24844,12 +24843,11 @@ static bool
 check_undeduced_parms (tree targs, tree args, tree end)
 {
   bool found = false;
-  int i;
-  for (i = TREE_VEC_LENGTH (targs) - 1; i >= 0; --i)
-if (TREE_VEC_ELT (targs, i) == NULL_TREE)
+  for (tree& targ : tree_vec_range (targs))
+if (targ == NULL_TREE)
   {
found = true;
-   TREE_VEC_ELT (targs, i) = error_mark_node;
+   targ = error_mark_node;
   }
   if (found)
 {
@@ -27288,10 +27286,9 @@ dependent_type_p_r (tree type)
   if (TREE_CODE (type) == TYPE_ARGUMENT_PACK)
 {
   tree args = ARGUMENT_PACK_ARGS (type);
-  int i, len = TREE_VEC_LENGTH (args);
-  for (i = 0; i < len; ++i)
-if (dependent_template_arg_p (TREE_VEC_ELT (args, i)))
-  return true;
+  for (tree arg : tree_vec_range (args))
+   if (dependent_template_arg_p (arg))
+ return true;
 }
 
   /* 

Re: [PATCH] Use more ARRAY_SIZE.

2022-05-11 Thread Eric Gallager via Gcc-patches
On Wed, May 11, 2022 at 9:53 AM David Malcolm via Gcc-patches
 wrote:
>
> On Thu, 2022-05-05 at 14:16 +0200, Martin Liška wrote:
> > Patch can bootstrap on x86_64-linux-gnu and survives regression
> > tests.
> >
> > Ready to be installed?
>
> I looked over the changes to:
>
>   gcc/analyzer/*.cc
>   gcc/input.cc
>   gcc/jit/*.cc
>
> and they look good to me.
>
> I assume that you enabled "jit" during the testing, right?  (it's not
> in --enable-languages=all, which is a perennial source of issues).
>

So, what remains to be done to include "jit" in "all" anyways? Are
there still some platforms left that it's not supported on yet or
something?

> Thanks
> Dave
>
>


Re: [PATCH] x86: Document -mno-cet-switch

2022-05-11 Thread Florian Weimer via Gcc-patches
* H. J. Lu:

> On Wed, May 11, 2022 at 11:45 AM Florian Weimer  wrote:
>>
>> * H. J. Lu:
>>
>> >> NOTRACK avoids the need for ENDBR instructions, right?  That's a
>> >> hardening improvement, so it should be used by default.
>> >
>> > NOTRACK weakens IBT since it disables IBT on the indirect jump instruction.
>> > GCC uses it in the jump table to avoid ENDBR.
>>
>> Typical jump table code looks like this:
>>
>> Dump of assembler code for function __cache_sysconf:
>>0x000f7a80 <+0>: endbr64
>>0x000f7a84 <+4>: sub$0xb9,%edi
>>0x000f7a8a <+10>:cmp$0xc,%edi
>>0x000f7a8d <+13>:ja 0xf7b70 <__cache_sysconf+240>
>>0x000f7a93 <+19>:lea0xba926(%rip),%rdx# 0x1b23c0
>>0x000f7a9a <+26>:movslq (%rdx,%rdi,4),%rax
>>0x000f7a9e <+30>:add%rdx,%rax
>>0x000f7aa1 <+33>:notrack jmp *%rax
>>
>> There's no ENDBR instruction between range check, the address
>> computation, and the NOTRACK JMP, so it's not possible to redirect that
>> JMP to some other place.
>
> That is the assumption we made.   RAX will always point to the valid
> address.

Which means that NOTRACK should not weaken anything here.  What am I
missing?

Thanks,
Florian



Re: [PATCH] x86: Document -mno-cet-switch

2022-05-11 Thread H.J. Lu via Gcc-patches
On Wed, May 11, 2022 at 11:45 AM Florian Weimer  wrote:
>
> * H. J. Lu:
>
> >> NOTRACK avoids the need for ENDBR instructions, right?  That's a
> >> hardening improvement, so it should be used by default.
> >
> > NOTRACK weakens IBT since it disables IBT on the indirect jump instruction.
> > GCC uses it in the jump table to avoid ENDBR.
>
> Typical jump table code looks like this:
>
> Dump of assembler code for function __cache_sysconf:
>0x000f7a80 <+0>: endbr64
>0x000f7a84 <+4>: sub$0xb9,%edi
>0x000f7a8a <+10>:cmp$0xc,%edi
>0x000f7a8d <+13>:ja 0xf7b70 <__cache_sysconf+240>
>0x000f7a93 <+19>:lea0xba926(%rip),%rdx# 0x1b23c0
>0x000f7a9a <+26>:movslq (%rdx,%rdi,4),%rax
>0x000f7a9e <+30>:add%rdx,%rax
>0x000f7aa1 <+33>:notrack jmp *%rax
>
> There's no ENDBR instruction between range check, the address
> computation, and the NOTRACK JMP, so it's not possible to redirect that
> JMP to some other place.

That is the assumption we made.   RAX will always point to the valid
address.

> I don't know if GCC systematically enforces this in its optimizers,
> though.
>
> Thanks,
> Florian
>


-- 
H.J.


Re: [PATCH] opts: improve option suggestion

2022-05-11 Thread David Malcolm via Gcc-patches
On Wed, 2022-05-11 at 16:49 +0200, Martin Liška wrote:
> In case where we have 2 equally good candidates like
> -ftrivial-auto-var-init=
> -Wtrivial-auto-var-init
> 
> for -ftrivial-auto-var-init, we should take the candidate that
> has a difference in trailing sign symbol.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> PR driver/105564
> 
> gcc/ChangeLog:
> 
> * spellcheck.cc (test_find_closest_string): Add new test.
> * spellcheck.h (class best_match): Prefer a difference in
> trailing sign symbol.
> ---
>  gcc/spellcheck.cc |  9 +
>  gcc/spellcheck.h  | 17 ++---
>  2 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/spellcheck.cc b/gcc/spellcheck.cc
> index 3e58344f510..f728573331f 100644
> --- a/gcc/spellcheck.cc
> +++ b/gcc/spellcheck.cc
> @@ -464,6 +464,15 @@ test_find_closest_string ()
>    ASSERT_STREQ ("DWARF_GNAT_ENCODINGS_ALL",
> find_closest_string ("DWARF_GNAT_ENCODINGS_all",
>  ));
> +
> +  /* Example from PR 105564 where option name with missing equal
> + sign should win.  */
> +  candidates.truncate (0);
> +  candidates.safe_push ("-Wtrivial-auto-var-init");
> +  candidates.safe_push ("-ftrivial-auto-var-init=");
> +  ASSERT_STREQ ("-ftrivial-auto-var-init=",
> +   find_closest_string ("-ftrivial-auto-var-init",
> +    ));
>  }
>  
>  /* Test data for test_metric_conditions.  */
> diff --git a/gcc/spellcheck.h b/gcc/spellcheck.h
> index 9b6223695be..9111ea08fc3 100644
> --- a/gcc/spellcheck.h
> +++ b/gcc/spellcheck.h
> @@ -128,11 +128,22 @@ class best_match
>  
>  /* Otherwise, compute the distance and see if the candidate
>     has beaten the previous best value.  */
> +    const char *candidate_str = candidate_traits::get_string
> (candidate);
>  edit_distance_t dist
> -  = get_edit_distance (m_goal, m_goal_len,
> -  candidate_traits::get_string (candidate),
> -  candidate_len);
> +  = get_edit_distance (m_goal, m_goal_len, candidate_str,
> candidate_len);
> +
> +    bool is_better = false;
>  if (dist < m_best_distance)
> +  is_better = true;
> +    else if (dist == m_best_distance)
> +  {
> +   /* Prefer a candidate has a difference in trailing sign
> character.  */
> +   if (candidate_str[candidate_len - 1] == '='
> +   && m_goal[m_goal_len - 1] != '=')
> + is_better = true;
> +  }

Thanks for working on this.

Maybe the comment should read:

/* Prefer a candidate that inserts a trailing '=',
   so that for
 "-ftrivial-auto-var-init"
   we suggest
 "-ftrivial-auto-var-init="
   rather than
 "-Wtrivial-auto-var-init".  */

Is the logic correct?  It's comparing the candidate with the goal,
rather than with the current best.  What if both the candidate and the
current best both add a trailing equal sign?

I find the array access of the final character suspicious - is there
any chance that either of the lengths could be zero?  I don't think so,
but maybe we should bulletproof things, and move the "is better"
comparison to a subroutine?

Hope this is constructive
Dave

> +
> +    if (is_better)
>    {
> m_best_distance = dist;
> m_best_candidate = candidate;




Re: [PATCH] x86: Document -mno-cet-switch

2022-05-11 Thread Florian Weimer via Gcc-patches
* H. J. Lu:

>> NOTRACK avoids the need for ENDBR instructions, right?  That's a
>> hardening improvement, so it should be used by default.
>
> NOTRACK weakens IBT since it disables IBT on the indirect jump instruction.
> GCC uses it in the jump table to avoid ENDBR.

Typical jump table code looks like this:

Dump of assembler code for function __cache_sysconf:
   0x000f7a80 <+0>: endbr64 
   0x000f7a84 <+4>: sub$0xb9,%edi
   0x000f7a8a <+10>:cmp$0xc,%edi
   0x000f7a8d <+13>:ja 0xf7b70 <__cache_sysconf+240>
   0x000f7a93 <+19>:lea0xba926(%rip),%rdx# 0x1b23c0
   0x000f7a9a <+26>:movslq (%rdx,%rdi,4),%rax
   0x000f7a9e <+30>:add%rdx,%rax
   0x000f7aa1 <+33>:notrack jmp *%rax

There's no ENDBR instruction between range check, the address
computation, and the NOTRACK JMP, so it's not possible to redirect that
JMP to some other place.

I don't know if GCC systematically enforces this in its optimizers,
though.

Thanks,
Florian



Re: [ping2][PATCH 0/8][RFC] Support BTF decl_tag and type_tag annotations

2022-05-11 Thread David Faust via Gcc-patches




On 5/10/22 22:05, Yonghong Song wrote:



On 5/10/22 8:43 PM, Yonghong Song wrote:



On 5/6/22 2:18 PM, David Faust wrote:



On 5/5/22 16:00, Yonghong Song wrote:



On 5/4/22 10:03 AM, David Faust wrote:



On 5/3/22 15:32, Joseph Myers wrote:

On Mon, 2 May 2022, David Faust via Gcc-patches wrote:


Consider the following example:

  #define __typetag1 __attribute__((btf_type_tag("tag1")))
  #define __typetag2 __attribute__((btf_type_tag("tag2")))
  #define __typetag3 __attribute__((btf_type_tag("tag3")))

  int __typetag1 * __typetag2 __typetag3 * g;

The expected behavior is that 'g' is "a pointer with tags 'tag2' and
'tag3',
to a pointer with tag 'tag1' to an int". i.e.:


That's not a correct expectation for either GNU __attribute__ or
C2x [[]]
attribute syntax.  In either syntax, __typetag2 __typetag3 should
apply to
the type to which g points, not to g or its type, just as if you had a
type qualifier there.  You'd need to put the attributes (or qualifier)
after the *, not before, to make them apply to the pointer type.  See
"Attribute Syntax" in the GCC manual for how the syntax is defined for
GNU
attributes and deduce in turn, for each subsequence of the tokens
matching
the syntax for some kind of declarator, what the type for "T D1"
would be
as defined there and in the C standard, as deduced from the type for
"T D"
for a sub-declarator D.
   >> But GCC's attribute parsing produces a variable 'g' which is "a

pointer with

tag 'tag1' to a pointer with tags 'tag2' and 'tag3' to an int", i.e.


In GNU syntax, __typetag1 applies to the declaration, whereas in C2x
syntax it applies to int.  Again, if you wanted it to apply to the
pointer
type it would need to go after the * not before.

If you are concerned with the fine details of what construct an
attribute
appertains to, I recommend using C2x syntax not GNU syntax.



Joseph, thank you! This is very helpful. My understanding of the syntax
was not correct.

(Actually, I made a bad mistake in paraphrasing this example from the
discussion of it in the series cover letter. But, the reason why it is
incorrect is the same.)


Yonghong, is the specific ordering an expectation in BPF programs or
other users of the tags?


This is probably a language writing issue. We are saying tags only
apply to pointer. We probably should say it only apply to pointee.

$ cat t.c
int const *ptr;

the llvm ir debuginfo:

!5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64)
!6 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !7)
!7 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)

We could replace 'const' with a tag like below:

int __attribute__((btf_type_tag("tag"))) *ptr;

!5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64,
annotations: !7)
!6 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
!7 = !{!8}
!8 = !{!"btf_type_tag", !"tag"}

In the above IR, we generate annotations to pointer_type because
we didn't invent a new DI type for encode btf_type_tag. But it is
totally okay to have IR looks like

!5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !11, size: 64)
!11 = !DIBtfTypeTagType(..., baseType: !6, name: !"Tag")
!6 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)


OK, thanks.

There is still the question of why the DWARF generated for this case
that I have been concerned about:

    int __typetag1 * __typetag2 __typetag3 * g;

differs between GCC (with this series) and clang. After studying it,
GCC is doing with the attributes exactly as is described in the
Attribute Syntax portion of the GCC manual where the GNU syntax is
described. I do not think there is any problem here.

So the difference in DWARF suggests to me that clang is not handling
the GNU attribute syntax in this particular case correctly, since it
seems to be associating __typetag2 and __typetag3 to g's type rather
than the type to which it points.

I am not sure whether for the use purposes of the tags this difference
is very important, but it is worth noting.


As Joseph suggested, it may be better to encourage users of these tags
to use the C2x attribute syntax if they are concerned with precisely
which construct the tag applies.

This would also be a way around any issues in handling the attributes
due to the GNU syntax.

I tried a few test cases using C2x syntax BTF type tags with a
clang-15 build, but ran into some issues (in particular, some of the
tag attributes being ignored altogether). I couldn't find confirmation
whether C2x attribute syntax is fully supported in clang yet, so maybe
this isn't expected to work. Do you know whether the C2x syntax is
fully supported in clang yet?


Actually, I don't know either. But since the btf decl_tag and type_tag
are also used to compile linux kernel and the minimum compiler version
to compile kernel is gcc5.1 and clang11. I am not sure whether gcc5.1
supports c2x or not, I guess probably not. So I think we most likely
cannot use c2x syntax.



Re: [PATCH] x86: Document -mno-cet-switch

2022-05-11 Thread H.J. Lu via Gcc-patches
On Wed, May 11, 2022 at 11:22 AM Florian Weimer  wrote:
>
> * H. J. Lu:
>
> >> >> > Generate jump tables with ENDBR and skip the NOTRACK prefix for 
> >> >> > indirect
> >> >> > jump.  Document -mno-cet-switch to turn off CET instrumentation on 
> >> >> > jump
> >> >> > tables for switch statements.
> >> >>
> >> >> Of course, that is a slight regression in security hardening.
> >> >>
> >> >> Quite frankly, I'm puzzled why the kernel decided to require these
> >> >> additional ENDBR instructions.
> >> >
> >> > Kernel is using -mcet-switch today.   Should we document -mcet-switch
> >> > and keep it off by default instead?
> >>
> >> Sorry, I'm not 100% certain of the mechanics/options involved.
> >>
> >> I think the default should reflect userspace requirements, like with the
> >> red zone and vector register usage for integer code.
> >
> > The question is if the compiler should use NOTRACK by default for
> > the jump table.   It is independent of whether NOTRACK is enabled or
> > not.
>
> NOTRACK avoids the need for ENDBR instructions, right?  That's a
> hardening improvement, so it should be used by default.

NOTRACK weakens IBT since it disables IBT on the indirect jump instruction.
GCC uses it in the jump table to avoid ENDBR.

-- 
H.J.


Re: [PATCH] x86: Document -mno-cet-switch

2022-05-11 Thread Florian Weimer via Gcc-patches
* H. J. Lu:

>> >> > Generate jump tables with ENDBR and skip the NOTRACK prefix for indirect
>> >> > jump.  Document -mno-cet-switch to turn off CET instrumentation on jump
>> >> > tables for switch statements.
>> >>
>> >> Of course, that is a slight regression in security hardening.
>> >>
>> >> Quite frankly, I'm puzzled why the kernel decided to require these
>> >> additional ENDBR instructions.
>> >
>> > Kernel is using -mcet-switch today.   Should we document -mcet-switch
>> > and keep it off by default instead?
>>
>> Sorry, I'm not 100% certain of the mechanics/options involved.
>>
>> I think the default should reflect userspace requirements, like with the
>> red zone and vector register usage for integer code.
>
> The question is if the compiler should use NOTRACK by default for
> the jump table.   It is independent of whether NOTRACK is enabled or
> not.

NOTRACK avoids the need for ENDBR instructions, right?  That's a
hardening improvement, so it should be used by default.

Thanks,
Florian



Re: [PATCH] x86: Document -mno-cet-switch

2022-05-11 Thread H.J. Lu via Gcc-patches
On Wed, May 11, 2022 at 8:58 AM Florian Weimer  wrote:
>
> * H. J. Lu:
>
> > On Wed, May 11, 2022 at 1:12 AM Florian Weimer  wrote:
> >>
> >> * H. J. Lu via Gcc-patches:
> >>
> >> > When -fcf-protection=branch is used, the compiler will generate jump
> >> > tables where the indirect jump is prefixed with the NOTRACK prefix, so
> >> > it can jump to non-ENDBR targets. Yet, for NOTRACK prefixes to work, the
> >> > NOTRACK specific enable bit must be set, what renders the binary broken
> >> > on any environment where this is not the case. In fact, having NOTRACK
> >> > disabled was a design choice for the Linux kernel CET support.
> >>
> >> Why isn't that a kernel bug?  It doesn't match what is in the current
> >> glibc sources.
> >
> > User space uses NOTRACK in the jump table in assembly codes.
>
> And is expected to continue to use it?

Yes, it should be allowed in user space.

> >> > Generate jump tables with ENDBR and skip the NOTRACK prefix for indirect
> >> > jump.  Document -mno-cet-switch to turn off CET instrumentation on jump
> >> > tables for switch statements.
> >>
> >> Of course, that is a slight regression in security hardening.
> >>
> >> Quite frankly, I'm puzzled why the kernel decided to require these
> >> additional ENDBR instructions.
> >
> > Kernel is using -mcet-switch today.   Should we document -mcet-switch
> > and keep it off by default instead?
>
> Sorry, I'm not 100% certain of the mechanics/options involved.
>
> I think the default should reflect userspace requirements, like with the
> red zone and vector register usage for integer code.

The question is if the compiler should use NOTRACK by default for
the jump table.   It is independent of whether NOTRACK is enabled or
not.

Should I check in my patch asis?

Thanks.

-- 
H.J.


[pushed] c++: fix arm-eabi bootstrap [PR105567]

2022-05-11 Thread Jason Merrill via Gcc-patches
Since my r13-112, in the template we were changing 'return' to 'return this'
on cdtor_returns_this targets, and then getting confused by that when
instantiating.  So only make that change at instantiation time.

Tested x86_64-pc-linux-gnu and arm-eabi sim, applying to trunk.

PR bootstrap/105567

gcc/cp/ChangeLog:

* typeck.cc (check_return_expr): Don't mess with ctor return value
while parsing a template.

gcc/testsuite/ChangeLog:

* g++.dg/template/ctor10.C: New test.
---
 gcc/cp/typeck.cc   |  4 ++--
 gcc/testsuite/g++.dg/template/ctor10.C | 10 ++
 2 files changed, 12 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/template/ctor10.C

diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index 57e55ed48d1..6ecdd97697d 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -10448,7 +10448,7 @@ check_return_expr (tree retval, bool *no_warning)
   if (retval)
error_at (loc, "returning a value from a destructor");
 
-  if (targetm.cxx.cdtor_returns_this ())
+  if (targetm.cxx.cdtor_returns_this () && !processing_template_decl)
retval = current_class_ptr;
   else
return NULL_TREE;
@@ -10463,7 +10463,7 @@ check_return_expr (tree retval, bool *no_warning)
/* You can't return a value from a constructor.  */
error_at (loc, "returning a value from a constructor");
 
-  if (targetm.cxx.cdtor_returns_this ())
+  if (targetm.cxx.cdtor_returns_this () && !processing_template_decl)
retval = current_class_ptr;
   else
return NULL_TREE;
diff --git a/gcc/testsuite/g++.dg/template/ctor10.C 
b/gcc/testsuite/g++.dg/template/ctor10.C
new file mode 100644
index 000..cf10fc5b19a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/ctor10.C
@@ -0,0 +1,10 @@
+// PR bootstrap/105567
+// This was breaking with cdtor_returns_this.
+
+template 
+struct A
+{
+  A() { return; }
+};
+
+A a;

base-commit: 0acdbe29f66017fc5cca40dcbd72a0dd41491d07
-- 
2.27.0



[Patch] OpenMP: Handle descriptors in target's firstprivate [PR104949]

2022-05-11 Thread Tobias Burnus

Dear all, dear Jakub,

this patch handles (for target regions)
  firstprivate(array_descriptor)
by not only firstprivatizing the descriptor but also the data
it points to. This is done by turning it in omp-low.cc the clause
into
  firstprivate(descr) firstprivate(descr.data)
and then attaching the latter to the former. That works by
adding an 'attach' after the last firstprivate (and checking
for it in libgomp). The attached-to device address for a
previous (here: the first) firstprivate is obtained by returning
the device address inside the hostaddrs[i] alias omp_arr array,
i.e. the compiler generates:
  omp_arr.1 =   /* firstprivate */
  omp_arr.2 = descr.data;  /* firstprivate */
  omp_arr.3 = _arr.1;  /* attach; bias:  */
and libgomp then knows that the device address is in the
pointer.

Not implemented, but this scheme can also be used for
  type
integer, allocatable :: A(:),B(:)
  end type
where multiple attachments have to be done to the same
privatized variable.

Side effect: For  has_device_addr(array_descr)  the pre-patch code
changes this to firstprivate – relying on the shallow copying. Thus,
has_device_addr had to be modified to still be shallow.

OK?

* * *

Note: The code is not active for OpenACC. The existing code uses, e.g.,
'goto oacc_firstprivate' – thus, the new code would be
partially active. I went for making it completely inactive for OpenACC
by adding one '!is_gimple_omp_oacc'. I bet that a deep copy would be
also useful for OpenACC, but I have neither checked what the current
code does nor what the OpenACC spec says about this.

* * *

Some crossrefs:
* https://gcc.gnu.org/PR104949 - the PR to this patch.

* has_device_addr + array descriptor, see clarification
for TR11/OpenMP 6 (passed 2nd vote): OpenMP Spec Issue #3180 / Pull Req. #3204
(related to 'firstprivate' above)

* For a pending is_device_ptr(non-c_ptr) -> has_device_addr issue,
see https://gcc.gnu.org/PR105318

* Regarding issues with reallocation of firstprivate, see:
https://gcc.gnu.org/PR105538
  (Not completely clear whether the code is valid; there are
  rules related (re,de)allocation for data mapping but not
  for firstprivate + issue about deallocation at the end of
  the scope in this case.)
* Regarding array constructors with non-const length but
  constant items, see https://gcc.gnu.org/PR91544
  (and testcase)
* Deep mapping patch (but not firstprivate):
  https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593704.html

Tobias
-
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
OpenMP: Handle descriptors in target's firstprivate [PR104949]

For allocatable/pointer arrays, a firstprivate to a device
not only needs to privatize the descriptor but also the actual
data. This is implemented as:
  firstprivate(x) firstprivate(x.data) attach(x [bias: )
where the address of x in device memory is saved in hostaddrs[i]
by libgomp and the middle end actually passes hostaddrs[i]' to
attach.

As side effect, has_device_addr(array_desc) had to be changed:
before, it was converted to firstprivate in the front end; now
it is handled in omp-low.cc as has_device_addr requires a shallow
firstprivate (not touching the data pointer) while the normal
firstprivate requires (now) a deep firstprivate.

gcc/fortran/ChangeLog:

	PR fortran/104949
	* f95-lang.cc (LANG_HOOKS_OMP_ARRAY_SIZE): Redefine.
	* trans-openmp.cc (gfc_omp_array_size): New.
	(gfc_trans_omp_variable_list): Never turn has_device_addr
	to firstprivate.
	* trans.h (gfc_omp_array_size): New.

gcc/ChangeLog:

	PR fortran/104949
	* langhooks-def.h (lhd_omp_array_size): New.
	(LANG_HOOKS_OMP_ARRAY_SIZE): Define
	(LANG_HOOKS_DECLS): Add it.
	* langhooks.cc (lhd_omp_array_size): New.
	* langhooks.h (struct lang_hooks_for_decls): Add hook.
	* omp-low.cc (scan_sharing_clauses, lower_omp_target):
	Handle GOMP_MAP_FIRSTPRIVATE for array descriptors.

libgomp/ChangeLog:

	PR fortran/104949
	* target.c (gomp_map_vars_internal, copy_firstprivate_data):
	Support attach for GOMP_MAP_FIRSTPRIVATE.
	* testsuite/libgomp.fortran/target-firstprivate-1.f90: New test.
	* testsuite/libgomp.fortran/target-firstprivate-2.f90: New test.
	* testsuite/libgomp.fortran/target-firstprivate-3.f90: New test.

 gcc/fortran/f95-lang.cc|   2 +
 gcc/fortran/trans-openmp.cc|  53 --
 gcc/fortran/trans.h|   1 +
 gcc/langhooks-def.h|   3 +
 gcc/langhooks.cc   |   8 ++
 gcc/langhooks.h|   5 +
 gcc/omp-low.cc | 102 ++-
 libgomp/target.c   |  22 
 .../libgomp.fortran/target-firstprivate-1.f90  |  33 ++
 

Re: [PATCH] [12/11/10] Fix invalid format warnings on Windows

2022-05-11 Thread Joseph Myers
On Wed, 11 May 2022, Martin Liška wrote:

> May I please ping review for this?

There are various coding style issues in the patch; at least missing space 
before '(' and '&&' at end of line (should be at start of line).  It will 
also need to be updated for .c files having been renamed to .cc in the GCC 
source tree.

I'd also like to check that "if mingw-w64 is configured to target UCRT" is 
not something that is necessarily known when GCC is built or from the 
command-line options passed to GCC.  Because ideally one might expect the 
TARGET_OVERRIDES_FORMAT_ATTRIBUTES / TARGET_OVERRIDES_FORMAT_INIT 
definitions to handle things appropriately conditionally, so that printf 
attributes are handled as gnu_printf for the "if mingw-w64 is configured 
to target UCRT" case.  Disregarding a built-in format attribute when one 
is also specified explicitly in the header, even though the two are not 
exactly equivalent attributes, as in this patch, seems more like the right 
approach in the case where the attributes in installed header (at the time 
GCC is run, not the time it is built) *are* the way in which GCC gets the 
"configured to target UCRT" information - as opposed to it being something 
available before the header is parsed.

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


Re: [PATCH] x86: Document -mno-cet-switch

2022-05-11 Thread Florian Weimer via Gcc-patches
* H. J. Lu:

> On Wed, May 11, 2022 at 1:12 AM Florian Weimer  wrote:
>>
>> * H. J. Lu via Gcc-patches:
>>
>> > When -fcf-protection=branch is used, the compiler will generate jump
>> > tables where the indirect jump is prefixed with the NOTRACK prefix, so
>> > it can jump to non-ENDBR targets. Yet, for NOTRACK prefixes to work, the
>> > NOTRACK specific enable bit must be set, what renders the binary broken
>> > on any environment where this is not the case. In fact, having NOTRACK
>> > disabled was a design choice for the Linux kernel CET support.
>>
>> Why isn't that a kernel bug?  It doesn't match what is in the current
>> glibc sources.
>
> User space uses NOTRACK in the jump table in assembly codes.

And is expected to continue to use it?

>> > Generate jump tables with ENDBR and skip the NOTRACK prefix for indirect
>> > jump.  Document -mno-cet-switch to turn off CET instrumentation on jump
>> > tables for switch statements.
>>
>> Of course, that is a slight regression in security hardening.
>>
>> Quite frankly, I'm puzzled why the kernel decided to require these
>> additional ENDBR instructions.
>
> Kernel is using -mcet-switch today.   Should we document -mcet-switch
> and keep it off by default instead?

Sorry, I'm not 100% certain of the mechanics/options involved.

I think the default should reflect userspace requirements, like with the
red zone and vector register usage for integer code.

Thanks,
Florian



[PATCH] Extend --with-zstd documentation

2022-05-11 Thread Bruno Haible
The patch that was so far added for documenting --with-zstd is pretty
minimal:
  - it refers to undocumented options --with-zstd-include and
--with-zstd-lib;
  - it suggests that --with-zstd can be used without an argument;
  - it does not clarify how this option applies to cross-compilation.

How about adding the same details as for the --with-isl,
--with-isl-include, --with-isl-lib options, mutatis mutandis? This patch
does that.

PR other/105527

gcc/ChangeLog:

* doc/install.texi (Configuration): Add more details about --with-zstd.
Document --with-zstd-include and --with-zstd-lib
---
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 042241e9fad..ed0d1d882c3 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2360,10 +2360,20 @@ default is derived from glibc's behavior. When glibc 
clamps float_t to double,
 GCC follows and enables the option. For other cross compiles, the default is
 disabled.
 
-@item --with-zstd
-Specify prefix directory for installed zstd library.
-Equivalent to @option{--with-zstd-include=PATH/include} plus
-@option{--with-zstd-lib=PATH/lib}.
+@item --with-zstd=@var{pathname}
+@itemx --with-zstd-include=@var{pathname}
+@itemx --with-zstd-lib=@var{pathname}
+If you do not have the @code{zstd} library installed in a standard
+location and you want to build GCC, you can explicitly specify the
+directory where it is installed (@samp{--with-zstd=@/@var{zstdinstalldir}}).
+The @option{--with-zstd=@/@var{zstdinstalldir}} option is shorthand for
+@option{--with-zstd-lib=@/@var{zstdinstalldir}/lib} and
+@option{--with-zstd-include=@/@var{zstdinstalldir}/include}. If this
+shorthand assumption is not correct, you can use the explicit
+include and lib options directly.
+
+These flags are applicable to the host platform only.  When building
+a cross compiler, they will not be used to configure target libraries.
 @end table
 
 @subheading Cross-Compiler-Specific Options





[PATCH 3/3] rs6000: Remove

2022-05-11 Thread Segher Boessenkool
The  mode iterator always expands to "wa".

2022-05-11  Segher Boessenkool  

* config/rs6000/rs6000.md: Use wa instead of .

---
 gcc/config/rs6000/rs6000.md | 98 +
 1 file changed, 46 insertions(+), 52 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 0100d67e9217..bf85baa53702 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -622,12 +622,6 @@ (define_mode_iterator SIGNBIT [(KF "FLOAT128_VECTOR_P 
(KFmode)")
 ; Iterator for ISA 3.0 supported floating point types
 (define_mode_iterator FP_ISA3 [SF DF])
 
-; SF/DF constraint for arithmetic on VSX registers using instructions added in
-; ISA 2.06 (power7).  This includes instructions that normally target DF mode,
-; but are used on SFmode, since internally SFmode values are kept in the DFmode
-; format.
-(define_mode_attr Fv   [(SF "wa") (DF "wa") (DI "wa")])
-
 ; Which isa is needed for those float instructions?
 (define_mode_attr Fisa [(SF "p8v")  (DF "*") (DI "*")])
 
@@ -4868,8 +4862,8 @@ (define_expand "abs2"
   "")
 
 (define_insn "*abs2_fpr"
-  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,")
-   (abs:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "d,")))]
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,wa")
+   (abs:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "d,wa")))]
   "TARGET_HARD_FLOAT"
   "@
fabs %0,%1
@@ -4877,10 +4871,10 @@ (define_insn "*abs2_fpr"
   [(set_attr "type" "fpsimple")])
 
 (define_insn "*nabs2_fpr"
-  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,")
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,wa")
(neg:SFDF
 (abs:SFDF
- (match_operand:SFDF 1 "gpc_reg_operand" "d,"]
+ (match_operand:SFDF 1 "gpc_reg_operand" "d,wa"]
   "TARGET_HARD_FLOAT"
   "@
fnabs %0,%1
@@ -4894,8 +4888,8 @@ (define_expand "neg2"
   "")
 
 (define_insn "*neg2_fpr"
-  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,")
-   (neg:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "d,")))]
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,wa")
+   (neg:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "d,wa")))]
   "TARGET_HARD_FLOAT"
   "@
fneg %0,%1
@@ -5274,9 +5268,9 @@ (define_expand "copysign3"
 ;; Use an unspec rather providing an if-then-else in RTL, to prevent the
 ;; compiler from optimizing -0.0
 (define_insn "copysign3_fcpsgn"
-  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,")
-   (unspec:SFDF [(match_operand:SFDF 1 "gpc_reg_operand" "d,")
- (match_operand:SFDF 2 "gpc_reg_operand" "d,")]
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,wa")
+   (unspec:SFDF [(match_operand:SFDF 1 "gpc_reg_operand" "d,wa")
+ (match_operand:SFDF 2 "gpc_reg_operand" "d,wa")]
 UNSPEC_COPYSIGN))]
   "TARGET_HARD_FLOAT && (TARGET_CMPB || VECTOR_UNIT_VSX_P (mode))"
   "@
@@ -5308,9 +5302,9 @@ (define_expand "s3"
 })
 
 (define_insn "*s3_vsx"
-  [(set (match_operand:SFDF 0 "vsx_register_operand" "=")
-   (fp_minmax:SFDF (match_operand:SFDF 1 "vsx_register_operand" "")
-   (match_operand:SFDF 2 "vsx_register_operand" "")))]
+  [(set (match_operand:SFDF 0 "vsx_register_operand" "=wa")
+   (fp_minmax:SFDF (match_operand:SFDF 1 "vsx_register_operand" "wa")
+   (match_operand:SFDF 2 "vsx_register_operand" "wa")))]
   "TARGET_VSX && TARGET_HARD_FLOAT"
 {
   return (TARGET_P9_MINMAX
@@ -5465,13 +5459,13 @@ (define_insn "*fsel4"
   [(set_attr "type" "fp")])
 
 (define_insn_and_split "*movcc_p9"
-  [(set (match_operand:SFDF 0 "vsx_register_operand" "=&,")
+  [(set (match_operand:SFDF 0 "vsx_register_operand" "=,wa")
(if_then_else:SFDF
 (match_operator:CCFP 1 "fpmask_comparison_operator"
-   [(match_operand:SFDF2 2 "vsx_register_operand" 
",")
-(match_operand:SFDF2 3 "vsx_register_operand" 
",")])
-(match_operand:SFDF 4 "vsx_register_operand" ",")
-(match_operand:SFDF 5 "vsx_register_operand" ",")))
+   [(match_operand:SFDF2 2 "vsx_register_operand" "wa,wa")
+(match_operand:SFDF2 3 "vsx_register_operand" "wa,wa")])
+(match_operand:SFDF 4 "vsx_register_operand" "wa,wa")
+(match_operand:SFDF 5 "vsx_register_operand" "wa,wa")))
(clobber (match_scratch:V2DI 6 "=0,"))]
   "TARGET_P9_MINMAX"
   "#"
@@ -5497,13 +5491,13 @@ (define_insn_and_split 
"*movcc_p9"
 
 ;; Handle inverting the fpmask comparisons.
 (define_insn_and_split "*movcc_invert_p9"
-  [(set (match_operand:SFDF 0 "vsx_register_operand" "=&,")
+  [(set (match_operand:SFDF 0 "vsx_register_operand" "=,wa")
(if_then_else:SFDF
 (match_operator:CCFP 1 "invert_fpmask_comparison_operator"
-   [(match_operand:SFDF2 2 "vsx_register_operand" 
",")
-(match_operand:SFDF2 3 "vsx_register_operand" 
",")])
-(match_operand:SFDF 4 

[PATCH 2/3] rs6000: Remove

2022-05-11 Thread Segher Boessenkool
The  mode iterator can just use "d" always.

2022-05-11  Segher Boessenkool  

* config/rs6000/rs6000.md: Use d instead of .

---
 gcc/config/rs6000/rs6000.md | 117 +---
 1 file changed, 57 insertions(+), 60 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 64049a6e521c..0100d67e9217 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -622,9 +622,6 @@ (define_mode_iterator SIGNBIT [(KF "FLOAT128_VECTOR_P 
(KFmode)")
 ; Iterator for ISA 3.0 supported floating point types
 (define_mode_iterator FP_ISA3 [SF DF])
 
-; SF/DF constraint for arithmetic on traditional floating point registers
-(define_mode_attr Ff   [(SF "f") (DF "d") (DI "d")])
-
 ; SF/DF constraint for arithmetic on VSX registers using instructions added in
 ; ISA 2.06 (power7).  This includes instructions that normally target DF mode,
 ; but are used on SFmode, since internally SFmode values are kept in the DFmode
@@ -4871,8 +4868,8 @@ (define_expand "abs2"
   "")
 
 (define_insn "*abs2_fpr"
-  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=,")
-   (abs:SFDF (match_operand:SFDF 1 "gpc_reg_operand" ",")))]
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,")
+   (abs:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "d,")))]
   "TARGET_HARD_FLOAT"
   "@
fabs %0,%1
@@ -4880,10 +4877,10 @@ (define_insn "*abs2_fpr"
   [(set_attr "type" "fpsimple")])
 
 (define_insn "*nabs2_fpr"
-  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=,")
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,")
(neg:SFDF
 (abs:SFDF
- (match_operand:SFDF 1 "gpc_reg_operand" ","]
+ (match_operand:SFDF 1 "gpc_reg_operand" "d,"]
   "TARGET_HARD_FLOAT"
   "@
fnabs %0,%1
@@ -4897,8 +4894,8 @@ (define_expand "neg2"
   "")
 
 (define_insn "*neg2_fpr"
-  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=,")
-   (neg:SFDF (match_operand:SFDF 1 "gpc_reg_operand" ",")))]
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,")
+   (neg:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "d,")))]
   "TARGET_HARD_FLOAT"
   "@
fneg %0,%1
@@ -4913,9 +4910,9 @@ (define_expand "add3"
   "")
 
 (define_insn "*add3_fpr"
-  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=,wa")
-   (plus:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "%,wa")
-  (match_operand:SFDF 2 "gpc_reg_operand" ",wa")))]
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,wa")
+   (plus:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "%d,wa")
+  (match_operand:SFDF 2 "gpc_reg_operand" "d,wa")))]
   "TARGET_HARD_FLOAT"
   "@
fadd %0,%1,%2
@@ -4931,9 +4928,9 @@ (define_expand "sub3"
   "")
 
 (define_insn "*sub3_fpr"
-  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=,wa")
-   (minus:SFDF (match_operand:SFDF 1 "gpc_reg_operand" ",wa")
-   (match_operand:SFDF 2 "gpc_reg_operand" ",wa")))]
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,wa")
+   (minus:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "d,wa")
+   (match_operand:SFDF 2 "gpc_reg_operand" "d,wa")))]
   "TARGET_HARD_FLOAT"
   "@
fsub %0,%1,%2
@@ -4949,9 +4946,9 @@ (define_expand "mul3"
   "")
 
 (define_insn "*mul3_fpr"
-  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=,wa")
-   (mult:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "%,wa")
-  (match_operand:SFDF 2 "gpc_reg_operand" ",wa")))]
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,wa")
+   (mult:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "%d,wa")
+  (match_operand:SFDF 2 "gpc_reg_operand" "d,wa")))]
   "TARGET_HARD_FLOAT"
   "@
fmul %0,%1,%2
@@ -4975,9 +4972,9 @@ (define_expand "div3"
 })
 
 (define_insn "*div3_fpr"
-  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=,wa")
-   (div:SFDF (match_operand:SFDF 1 "gpc_reg_operand" ",wa")
- (match_operand:SFDF 2 "gpc_reg_operand" ",wa")))]
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,wa")
+   (div:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "d,wa")
+ (match_operand:SFDF 2 "gpc_reg_operand" "d,wa")))]
   "TARGET_HARD_FLOAT"
   "@
fdiv %0,%1,%2
@@ -4986,8 +4983,8 @@ (define_insn "*div3_fpr"
(set_attr "isa" "*,")])
 
 (define_insn "*sqrt2_internal"
-  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=,wa")
-   (sqrt:SFDF (match_operand:SFDF 1 "gpc_reg_operand" ",wa")))]
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,wa")
+   (sqrt:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "d,wa")))]
   "TARGET_HARD_FLOAT && TARGET_PPC_GPOPT"
   "@
fsqrt %0,%1
@@ -5014,8 +5011,8 @@ (define_expand "sqrt2"
 
 ;; Floating point reciprocal approximation
 (define_insn "fre"
-  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=,wa")
-   (unspec:SFDF [(match_operand:SFDF 1 "gpc_reg_operand" ",wa")]
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=d,wa")
+   (unspec:SFDF [(match_operand:SFDF 1 

[PATCH 1/3] rs6000: Delete RS6000_CONSTRAINT_f

2022-05-11 Thread Segher Boessenkool
Constraint "f" is always exactly the same as constraint "d", so we do
not need RS6000_CONSTRAINT_f.

2022-05-11  Segher Boessenkool  

* config/rs6000/constraints.md (register_constraint "f"): Use
RS6000_CONSTRAINT_d.
* config/rs6000/rs6000.cc (rs6000_debug_reg_global): Do not handle
RS6000_CONSTRAINT_f.
(rs6000_init_hard_regno_mode_ok): Ditto.  Reorder and simplify a bit.
* config/rs6000/rs6000.h (r6000_reg_class_enum): Delete
RS6000_CONSTRAINT_d.

---
 gcc/config/rs6000/constraints.md |  2 +-
 gcc/config/rs6000/rs6000.cc  | 16 +++-
 gcc/config/rs6000/rs6000.h   |  3 +--
 3 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/gcc/config/rs6000/constraints.md b/gcc/config/rs6000/constraints.md
index 7aaffd9f9a89..00ac4b86c058 100644
--- a/gcc/config/rs6000/constraints.md
+++ b/gcc/config/rs6000/constraints.md
@@ -29,7 +29,7 @@ (define_register_constraint "b" "BASE_REGS"
   "A base register.  Like @code{r}, but @code{r0} is not allowed, so
@code{r1}@dots{}@code{r31}.")
 
-(define_register_constraint "f" "rs6000_constraints[RS6000_CONSTRAINT_f]"
+(define_register_constraint "f" "rs6000_constraints[RS6000_CONSTRAINT_d]"
   "A floating point register (FPR), @code{f0}@dots{}@code{f31}.")
 
 (define_register_constraint "d" "rs6000_constraints[RS6000_CONSTRAINT_d]"
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 4030864aa1af..5cb8a53e9ce6 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -2305,7 +2305,6 @@ rs6000_debug_reg_global (void)
   fprintf (stderr,
   "\n"
   "d  reg_class = %s\n"
-  "f  reg_class = %s\n"
   "v  reg_class = %s\n"
   "wa reg_class = %s\n"
   "we reg_class = %s\n"
@@ -2314,7 +2313,6 @@ rs6000_debug_reg_global (void)
   "wA reg_class = %s\n"
   "\n",
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_d]],
-  reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_f]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_v]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wa]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_we]],
@@ -2953,7 +2951,6 @@ rs6000_init_hard_regno_mode_ok (bool global_init_p)
  constraints are:
 
d  - Register class to use with traditional DFmode instructions.
-   f  - Register class to use with traditional SFmode instructions.
v  - Altivec register.
wa - Any VSX register.
wc - Reserved to represent individual CR bits (used in LLVM).
@@ -2962,18 +2959,11 @@ rs6000_init_hard_regno_mode_ok (bool global_init_p)
wx - Float register if we can do 32-bit int stores.  */
 
   if (TARGET_HARD_FLOAT)
-{
-  rs6000_constraints[RS6000_CONSTRAINT_f] = FLOAT_REGS;/* SFmode  */
-  rs6000_constraints[RS6000_CONSTRAINT_d] = FLOAT_REGS;/* DFmode  */
-}
-
-  if (TARGET_VSX)
-rs6000_constraints[RS6000_CONSTRAINT_wa] = VSX_REGS;
-
-  /* Add conditional constraints based on various options, to allow us to
- collapse multiple insn patterns.  */
+rs6000_constraints[RS6000_CONSTRAINT_d] = FLOAT_REGS;
   if (TARGET_ALTIVEC)
 rs6000_constraints[RS6000_CONSTRAINT_v] = ALTIVEC_REGS;
+  if (TARGET_VSX)
+rs6000_constraints[RS6000_CONSTRAINT_wa] = VSX_REGS;
 
   if (TARGET_POWERPC64)
 {
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 523256a5c9d5..20b9d11424db 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -1240,8 +1240,7 @@ extern enum reg_class 
rs6000_regno_regclass[FIRST_PSEUDO_REGISTER];
 /* Register classes for various constraints that are based on the target
switches.  */
 enum r6000_reg_class_enum {
-  RS6000_CONSTRAINT_d, /* fpr registers for double values */
-  RS6000_CONSTRAINT_f, /* fpr registers for single values */
+  RS6000_CONSTRAINT_d, /* FPR registers */
   RS6000_CONSTRAINT_v, /* Altivec registers */
   RS6000_CONSTRAINT_wa,/* Any VSX register */
   RS6000_CONSTRAINT_we,/* VSX register if ISA 3.0 vector. */
-- 
1.8.3.1



[PATCH 0/3] rs6000: Delete and

2022-05-11 Thread Segher Boessenkool
Since 2c2aa74d1dft ("rs6000: Remove Xilinx FP") constraints d and f mean
exactly the same thing, so we can use "d" always.  This series cleans up
the constraint initialisation a bit, and removes the  mode
attribute, since it can now always be "d".  It also removes  since it
always is "wa", and it simplifies things nicely now that we can also
delete .

Tested on powerpc64-linux {-m32,-m64}.  Committing to trunk.


Segher


Segher Boessenkool (3):
  rs6000: Delete RS6000_CONSTRAINT_f
  rs6000: Remove 
  rs6000: Remove 

 gcc/config/rs6000/constraints.md |   2 +-
 gcc/config/rs6000/rs6000.cc  |  16 +---
 gcc/config/rs6000/rs6000.h   |   3 +-
 gcc/config/rs6000/rs6000.md  | 177 +++
 4 files changed, 89 insertions(+), 109 deletions(-)

-- 
1.8.3.1



Re: [PATCH] Add -fcf-check-attribute=[yes|no|none] for Linux kernel

2022-05-11 Thread H.J. Lu via Gcc-patches
On Tue, May 10, 2022 at 11:39 PM Richard Biener  wrote:
>
> On Tue, 10 May 2022, H.J. Lu wrote:
>
> > When compiling Linux kernel with -fcf-protection=branch to enable x86
> > Indiret Branch Tracking (IBT), ENDBR is added to all global functions.
> > This creates more "legal" forward edges than necessary.  -mmanual-endbr
> > provides a way to insert ENDBR instruction at function entry only via
> > the 'cf_check' function attribute and programmers can add the 'cf_check'
> > function attribute to functions which can be reached by indirect branch.
> >
> > Add -fcf-check-attribute=[yes|no|none] to imply "cf_check" or "nocf_check"
> > function attributes so that GCC can produce a diagnostic when there is a
> > mismatch in cf_check or nocf_check function attributes.
> >
> > This has been tested on Linux kernel.
>
> I don't quite understand the purpose but wouldn't
> -fcf-check-attribute=[cf|nocf|off] be better than having no and none?
> Since 'off' is the default you need 'off' only to be able to negate
> an earlier cf/nocf?

This option adds implied "cf_check" or "nocf_check" attributes if there
is none.   I need an option not to add them by default.I can use
 -fcf-check-attribute=none or  -fcf-check-attribute=off.  Which one is
better?

Thanks.

> > gcc/
> >
> >   PR target/102953
> >   * attribs.cc (decl_attributes): Add implied cf_check or nocf_check
> >   function attributes.
> >   * common.opt: Add -fcf-check-attribute=.
> >   * flag-types.h (cf_check_attribute): New.
> >   * doc/invoke.texi: Document -fcf-check-attribute=.
> >
> > gcc/c/
> >
> >   PR target/102953
> >   * c-decl.cc (diagnose_mismatched_decls): Check implied cf_check
> >   and nocf_check function attributes.
> >
> > gcc/testsuite/
> >
> >   PR target/102953
> >   * gcc.target/i386/pr102953-3.c: New test.
> >   * gcc.target/i386/pr102953-4.c: Likewise.
> >   * gcc.target/i386/pr102953-5.c: Likewise.
> >   * gcc.target/i386/pr102953-6.c: Likewise.
> > ---
> >  gcc/attribs.cc | 19 +++
> >  gcc/c/c-decl.cc| 22 +-
> >  gcc/common.opt | 16 
> >  gcc/doc/invoke.texi| 12 
> >  gcc/flag-types.h   |  8 
> >  gcc/testsuite/gcc.target/i386/pr102953-3.c |  8 
> >  gcc/testsuite/gcc.target/i386/pr102953-4.c |  7 +++
> >  gcc/testsuite/gcc.target/i386/pr102953-5.c |  7 +++
> >  gcc/testsuite/gcc.target/i386/pr102953-6.c |  8 
> >  9 files changed, 106 insertions(+), 1 deletion(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr102953-3.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr102953-4.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr102953-5.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr102953-6.c
> >
> > diff --git a/gcc/attribs.cc b/gcc/attribs.cc
> > index b219f878042..34e8707eac1 100644
> > --- a/gcc/attribs.cc
> > +++ b/gcc/attribs.cc
> > @@ -694,6 +694,25 @@ decl_attributes (tree *node, tree attributes, int 
> > flags,
> >   attributes = tree_cons (get_identifier ("no_icf"),  NULL, attributes);
> >  }
> >
> > +  /* -fcf-check-attribute=[yes|no] implies "cf_check" or "nocf_check"
> > + function attribute.  */
> > +  if (TREE_CODE (*node) == FUNCTION_DECL
> > +  && flag_cf_check_attribute != CF_CHECK_ATTRIBUTE_NONE
> > +  && !fndecl_built_in_p (*node)
> > +  && lookup_attribute ("nocf_check",
> > +DECL_ATTRIBUTES (*node)) == nullptr
> > +  && lookup_attribute ("cf_check",
> > +DECL_ATTRIBUTES (*node)) == nullptr
> > +  && (!attributes
> > +   || (lookup_attribute ("nocf_check", attributes) == nullptr
> > +   && lookup_attribute ("cf_check", attributes) == nullptr)))
> > +{
> > +  const char *attr = (flag_cf_check_attribute == CF_CHECK_ATTRIBUTE_YES
> > +   ? "cf_check" : "nocf_check");
> > +  attributes = tree_cons (get_identifier (attr), nullptr,
> > +   attributes);
> > +}
> > +
> >targetm.insert_attributes (*node, );
> >
> >/* Note that attributes on the same declaration are not necessarily
> > diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
> > index c701f07befe..787c39dc0fe 100644
> > --- a/gcc/c/c-decl.cc
> > +++ b/gcc/c/c-decl.cc
> > @@ -2133,7 +2133,27 @@ diagnose_mismatched_decls (tree newdecl, tree 
> > olddecl,
> >   error ("conflicting type qualifiers for %q+D", newdecl);
> >   }
> > else
> > - error ("conflicting types for %q+D; have %qT", newdecl, newtype);
> > + {
> > +   if (flag_cf_check_attribute == CF_CHECK_ATTRIBUTE_NO
> > +   && (!lookup_attribute ("nocf_check",
> > +   TYPE_ATTRIBUTES (oldtype))
> > +!= !lookup_attribute 

Re: [PATCH] configure: add --disable-fix-includes

2022-05-11 Thread Martin Liška
On 5/11/22 14:48, Andreas Schwab wrote:
> On Mai 11 2022, Martin Liška wrote:
> 
>> @Joseph: Can you please help me why --disable-$foo disables building $foo
>> folder during the build?
> 
> # Handle --disable- generically.
> for dir in $configdirs $build_configdirs $target_configdirs ; do
>   dirname=`echo $dir | sed -e s/target-//g -e s/build-//g -e s/-/_/g`
>   varname=`echo $dirname | sed -e s/+/_/g`
>   if eval test x\${enable_${varname}} "=" xno ; then
> noconfigdirs="$noconfigdirs $dir"
>   fi
> done
> 

Great, thanks!

Using that I provide v3 where I renamed the option to 
--{enable,disable}-fixincludes.

Ready to be installed?
Thanks,
MartinFrom 2d3079a14ee26192ebbc81e7c9663ae49ad7a178 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 4 Feb 2022 13:42:14 +0100
Subject: [PATCH] configure: add --disable-fixincludes

Right now, fixinclude takes about 11 seconds on my machine, where
it reads 130MB of header files.

The number of fixed headers is negligible without any significant
change.

fixincludes/ChangeLog:

	* fixinc.in: Add early exit.

gcc/ChangeLog:

	* Makefile.in: Support enable_fixincludes.
	* configure.ac: Add --disable-fixincludes.
	* configure: Regenerate.
	* doc/install.texi: Document the newly added configure options.

ChangeLog:

	* configure.ac: Ignore --disable-fixincludes.
	* configure: Regenerate.
---
 configure |  4 
 configure.ac  |  4 
 fixincludes/fixinc.in |  6 ++
 gcc/Makefile.in   |  6 --
 gcc/configure | 16 ++--
 gcc/configure.ac  |  6 ++
 gcc/doc/install.texi  |  7 +++
 7 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index 5dcaab14ae9..fb3897585b8 100755
--- a/configure
+++ b/configure
@@ -9041,6 +9041,10 @@ fi
 for dir in $configdirs $build_configdirs $target_configdirs ; do
   dirname=`echo $dir | sed -e s/target-//g -e s/build-//g -e s/-/_/g`
   varname=`echo $dirname | sed -e s/+/_/g`
+  # Skip --disable-fixincludes, it is handled in gcc/configure
+  if eval test x${varname} "=" xfixincludes ; then
+continue
+  fi
   if eval test x\${enable_${varname}} "=" xno ; then
 noconfigdirs="$noconfigdirs $dir"
   fi
diff --git a/configure.ac b/configure.ac
index 85977482aee..a0466533a46 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2305,6 +2305,10 @@ fi
 for dir in $configdirs $build_configdirs $target_configdirs ; do
   dirname=`echo $dir | sed -e s/target-//g -e s/build-//g -e s/-/_/g`
   varname=`echo $dirname | sed -e s/+/_/g`
+  # Skip --disable-fixincludes, it is handled in gcc/configure
+  if eval test x${varname} "=" xfixincludes ; then
+continue
+  fi
   if eval test x\${enable_${varname}} "=" xno ; then
 noconfigdirs="$noconfigdirs $dir"
   fi
diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index 0bd8027a554..bc2494c9f3a 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -63,6 +63,12 @@ else
   esac
 fi
 
+if test "x$ENABLE_FIXINCLUDES" = "xno"
+then
+  echo "Skipping fixincludes"
+  exit 0
+fi
+
 # Define what target system we're fixing.
 #
 if test -r ./Makefile; then
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 31ff95500c9..f73c6a731b3 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -401,6 +401,8 @@ PLUGINLIBS = @pluginlibs@
 
 enable_plugin = @enable_plugin@
 
+enable_fixincludes = @enable_fixincludes@
+
 # On MinGW plugin installation involves installing import libraries.
 ifeq ($(enable_plugin),yes)
   plugin_implib := $(if $(strip $(filter mingw%,$(host_os))),yes,no)
@@ -3248,8 +3250,8 @@ stmp-fixinc: gsyslimits.h macro_list fixinc_list \
 	chmod a+rx $${fix_dir} || true; \
 	(TARGET_MACHINE='$(target)'; srcdir=`cd $(srcdir); ${PWD_COMMAND}`; \
 	  SHELL='$(SHELL)'; MACRO_LIST=`${PWD_COMMAND}`/macro_list ; \
-	  gcc_dir=`${PWD_COMMAND}` ; \
-	  export TARGET_MACHINE srcdir SHELL MACRO_LIST && \
+	  gcc_dir=`${PWD_COMMAND}` ; ENABLE_FIXINCLUDES=${enable_fixincludes} \
+	  export TARGET_MACHINE srcdir SHELL MACRO_LIST ENABLE_FIXINCLUDES && \
 	  cd $(build_objdir)/fixincludes && \
 	  $(SHELL) ./fixinc.sh "$${gcc_dir}/$${fix_dir}" \
 	$(BUILD_SYSTEM_HEADER_DIR) $(OTHER_FIXINCLUDES_DIRS) ); \
diff --git a/gcc/configure b/gcc/configure
index 5ce0557719a..04affa93864 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -839,6 +839,7 @@ with_float
 with_cpu
 enable_multiarch
 enable_multilib
+enable_fixincludes
 coverage_flags
 valgrind_command
 valgrind_path_defines
@@ -958,6 +959,7 @@ enable_werror_always
 enable_checking
 enable_coverage
 enable_gather_detailed_mem_stats
+enable_fixincludes
 enable_valgrind_annotations
 enable_multilib
 enable_multiarch
@@ -1688,6 +1690,7 @@ Optional Features:
   Values are opt, noopt, default is noopt
   --enable-gather-detailed-mem-stats
   enable detailed memory allocation stats gathering
+  --disable-fixincludes   skip fixing of includes
   

[PATCH] opts: improve option suggestion

2022-05-11 Thread Martin Liška
In case where we have 2 equally good candidates like
-ftrivial-auto-var-init=
-Wtrivial-auto-var-init

for -ftrivial-auto-var-init, we should take the candidate that
has a difference in trailing sign symbol.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR driver/105564

gcc/ChangeLog:

* spellcheck.cc (test_find_closest_string): Add new test.
* spellcheck.h (class best_match): Prefer a difference in
trailing sign symbol.
---
 gcc/spellcheck.cc |  9 +
 gcc/spellcheck.h  | 17 ++---
 2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/gcc/spellcheck.cc b/gcc/spellcheck.cc
index 3e58344f510..f728573331f 100644
--- a/gcc/spellcheck.cc
+++ b/gcc/spellcheck.cc
@@ -464,6 +464,15 @@ test_find_closest_string ()
   ASSERT_STREQ ("DWARF_GNAT_ENCODINGS_ALL",
find_closest_string ("DWARF_GNAT_ENCODINGS_all",
 ));
+
+  /* Example from PR 105564 where option name with missing equal
+ sign should win.  */
+  candidates.truncate (0);
+  candidates.safe_push ("-Wtrivial-auto-var-init");
+  candidates.safe_push ("-ftrivial-auto-var-init=");
+  ASSERT_STREQ ("-ftrivial-auto-var-init=",
+   find_closest_string ("-ftrivial-auto-var-init",
+));
 }
 
 /* Test data for test_metric_conditions.  */
diff --git a/gcc/spellcheck.h b/gcc/spellcheck.h
index 9b6223695be..9111ea08fc3 100644
--- a/gcc/spellcheck.h
+++ b/gcc/spellcheck.h
@@ -128,11 +128,22 @@ class best_match
 
 /* Otherwise, compute the distance and see if the candidate
has beaten the previous best value.  */
+const char *candidate_str = candidate_traits::get_string (candidate);
 edit_distance_t dist
-  = get_edit_distance (m_goal, m_goal_len,
-  candidate_traits::get_string (candidate),
-  candidate_len);
+  = get_edit_distance (m_goal, m_goal_len, candidate_str, candidate_len);
+
+bool is_better = false;
 if (dist < m_best_distance)
+  is_better = true;
+else if (dist == m_best_distance)
+  {
+   /* Prefer a candidate has a difference in trailing sign character.  */
+   if (candidate_str[candidate_len - 1] == '='
+   && m_goal[m_goal_len - 1] != '=')
+ is_better = true;
+  }
+
+if (is_better)
   {
m_best_distance = dist;
m_best_candidate = candidate;
-- 
2.36.1



Re: [PATCH] AArch64: Cleanup CPU option processing code

2022-05-11 Thread Wilco Dijkstra via Gcc-patches
Hi Richard,

> Although invoking ./cc1 directly only half-works with --with-arch,
> it half-works well-enough that I'd still like to keep it working.
> But I agree we should apply your change first, then I can follow up
> with a patch to make --with-* work with ./cc1 later.  (I have a version
> locally and the net result is much simpler than the status quo, as well
> as hopefully actually working properly.)

That sounds good indeed. Is that changing TARGET_CPU_DEFAULT into
a string can could just be parsed like a -mcpu option?

> Do we still need both selected_arch and explicit_arch?  explicit_arch
> seems a misnomer now, since it includes implicit as well as explicit
> choices.  Same for selected_tune and explicit_tune_core.

At the moment we do since these are settings that must be saved/restored
since they can be overridden. However it may be possible to do further
cleanups to remove some of this. I also wonder whether we can remove the
internal override feature (override_tune_string) since that further complicates
the tunings, and I'm not convinced that it is either useful or being used at 
all.

> aarch64_option_restore has:
>
>  if (opts->x_explicit_tune_core == aarch64_none
>  && opts->x_explicit_arch != aarch64_no_arch)
>    selected_tune = _cores[selected_arch->ident];
>  else
>    selected_tune = aarch64_get_tune_cpu (ptr->x_explicit_tune_core);
>
> Is the “if” condition ever true, or can we now restore the tune
> info unconditionally?

Yes that was added a year or so after I created this patch, so this
is now redundant. I've removed it in v2:


The --with-cpu/--with-arch configure option processing not only checks valid 
arguments
but also sets TARGET_CPU_DEFAULT with a CPU and extension bitmask.  This isn't 
used
however since a --with-cpu is translated into a -mcpu option which is processed 
as if
written on the command-line (so TARGET_CPU_DEFAULT is never accessed).

So remove all the complex processing and bitmask, and just validate the option.
Fix a bug that always reports valid architecture extensions as invalid.  As a 
result
the CPU processing in aarch64.c can be simplified.

Bootstrap OK, regress pass, OK for commit?

ChangeLog:
2022-04-19  Wilco Dijkstra  

* config.gcc (aarch64*-*-*): Simplify --with-cpu and --with-arch
processing.  Add support for architectural extensions.
* config/aarch64/aarch64.h (TARGET_CPU_DEFAULT): Remove
AARCH64_CPU_DEFAULT_FLAGS.
(TARGET_CPU_NBITS): Remove.
(TARGET_CPU_MASK): Remove.
* config/aarch64/aarch64.cc (AARCH64_CPU_DEFAULT_FLAGS): Remove define.
(get_tune_cpu): Assert CPU is always valid.
(get_arch): Assert architecture is always valid.
(aarch64_override_options): Cleanup CPU selection code and simplify 
logic.
(aarch64_option_restore): Remove unnecessary checks on tune.

---

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 
c5064dd376660c192d5573997b4fc86b6b3e3838..b48d5451e8027c93fb1f614812589183d0a88c4b
 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4178,8 +4178,6 @@ case "${target}" in
  pattern=AARCH64_CORE
fi
 
-   ext_mask=AARCH64_CPU_DEFAULT_FLAGS
-
# Find the base CPU or ARCH id in aarch64-cores.def or
# aarch64-arches.def
if [ x"$base_val" = x ] \
@@ -4187,23 +4185,6 @@ case "${target}" in
${srcdir}/config/aarch64/$def \
> /dev/null; then
 
- if [ $which = arch ]; then
-   base_id=`grep "^$pattern(\"$base_val\"," \
- ${srcdir}/config/aarch64/$def | \
- sed -e 's/^[^,]*,[]*//' | \
- sed -e 's/,.*$//'`
-   # Extract the architecture flags from 
aarch64-arches.def
-   ext_mask=`grep "^$pattern(\"$base_val\"," \
-  ${srcdir}/config/aarch64/$def | \
-  sed -e 's/)$//' | \
-  sed -e 's/^.*,//'`
- else
-   base_id=`grep "^$pattern(\"$base_val\"," \
- ${srcdir}/config/aarch64/$def | \
- sed -e 's/^[^,]*,[]*//' | \
- sed -e 's/,.*$//'`
- fi
-
  # Disallow extensions in --with-tune=cortex-a53+crc.
  if [ $which = tune ] && [ x"$ext_val" != x ]; then
echo "Architecture extensions not supported in 
--with-$which=$val" 1>&2
@@ -4234,25 +4215,7 @@ case "${target}" in
grep "^\"$base_ext\""`
 
if [ x"$base_ext" = x ] \
-

Re: [PATCH, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

2022-05-11 Thread Segher Boessenkool
Hi~

On Wed, May 11, 2022 at 04:53:08PM +0800, Kewen.Lin wrote:
> on 2022/5/10 20:27, Segher Boessenkool wrote:
> > Yes.  RTL iterators and attributes are textual replacement and expansion
> > only: there is no deeper semantic meaning to it.  In fact, we should
> > have only a "minmax" iterator and a "MINMAX" attribute, and then
> > simplify everything else.  I'll do this for the existing code.

Iterators of course are *not* just text replacement, which is pretty
nasty, makes inconvenient contentless iterators necessary.  Bah.  But at
least we can get rid of many attributes.

> >>> +(define_insn "3"
> >>> +  [(set (match_operand:SFDF 0 "vsx_register_operand" "=")
> >>> + (unspec:SFDF [(match_operand:SFDF 1 "vsx_register_operand" "")
> >>> +   (match_operand:SFDF 2 "vsx_register_operand" "")]
> >>
> >> Nit: both SD and DF are mapped to constraint wa, just hardcode Fv to wa?
> > 
> > (SF and DF)
> > 
> > Please keep  until  is gone as well, it is easier to read that
> > way.  And at that time get rid of *all* .
> > 
> > Indeed we could get rid of it, but only replacing it in some places and
> > not others is confusing (or at least distracting).
> > 
> 
> aha, thanks for the correction and explanation! 

I'll commit a patch series doing just this in a bit: it removes ,
, and RS6000_CONSTRAINT_f (it is the same as RS6000_CONSTRAINT_d
always after all, since 2c2aa74d1df0 (2018, removing Xilinx FP)).

> >> So I wonder if it would be more clear with:
> >>   1) add new define_insn for xs{min,max}dp
> > 
> > No, the existing thing should always do these insns.
> 
> Currently xs{min,max}dp are only covered by smin/smax, no their own 
> define_insn?

Yeah, smin/smax cannot work if -ffast-math is not enabled, so we need
some new stuff using an unspec, instead.  But ideally we should have an
RTL code that just is the correct thing always!  Maybe "fmin/fmax" :-)

Until such a thing exists we can use an unspec, sure.

> Yeah, I agree.  The above question/proposal still needs UNSPEC for new
> define_insn, and if we want to replace the expansion pattern for bif
> __builtin_vsx_xs{min,max}dp, we seem to have alternatives:
> 
> 1) as Haochen's patch, new define_insn fmin/fmax with UNSPEC_F{MAX,MIN}
> and used for actual insns xs{min,max}dp and replace bif table entry with
> fmin/fmax*.
> 
> 2) new define_insn vsx_xs{min,max}dp with UNSPEC_XS{MAX,MIN}DP and used
> for actual insns xs{min,max}dp, new define_expand for fmin/fmax optabs,
> replace bif table entry with vsx_xs{min,max}dp*.
> 
> I personally felt (wondered) if 2) is more clear?  Because the mnemonics
> xs{min,max}dp don't have fmin/fmax inside the names, ISA doesn't even
> mention they can be used for fmin/fmax in Programming Notes, it seems
> more straight to see vsx_xs{min,max}dp used as bif expansion patterns
> and UNSPEC_XS{MAX,MIN}DP.  But both 1) and 2) are fine to me. :)

I prefer 1), for the time being at least, because we have two different
patterns both resulting in xs{min,max}dp.


Segher


Re: [PATCH] Remove size limit of PCH

2022-05-11 Thread LIU Hao via Gcc-patches

在 2022-05-10 22:28, Jakub Jelinek 写道:


This looks reasonable, but doesn't contain the most important part.
As mentioned in https://gcc.gnu.org/r12-5855
the generic part can now support relocation of PCH, so it is fine if it is
mapped at some other address, it is preferrable if it is mapped at the same
address as it was written for, but if not, the generic code can relocate it.

(... ...)

IMHO you can just drop the loop, sleep of half a second is almost certainly
slower than the relocation handling, so I'd just


Thanks for the hint. I have very little knowledge about how PCH works in GCC, thus I'm gonna propose 
a patch to MSYS2 and see how it works. This can be committed to GCC later, after having been tested 
through many packages.



--
Best regards,
LIU Hao


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH] x86: Document -mno-cet-switch

2022-05-11 Thread H.J. Lu via Gcc-patches
On Wed, May 11, 2022 at 1:12 AM Florian Weimer  wrote:
>
> * H. J. Lu via Gcc-patches:
>
> > When -fcf-protection=branch is used, the compiler will generate jump
> > tables where the indirect jump is prefixed with the NOTRACK prefix, so
> > it can jump to non-ENDBR targets. Yet, for NOTRACK prefixes to work, the
> > NOTRACK specific enable bit must be set, what renders the binary broken
> > on any environment where this is not the case. In fact, having NOTRACK
> > disabled was a design choice for the Linux kernel CET support.
>
> Why isn't that a kernel bug?  It doesn't match what is in the current
> glibc sources.

User space uses NOTRACK in the jump table in assembly codes.

> > Generate jump tables with ENDBR and skip the NOTRACK prefix for indirect
> > jump.  Document -mno-cet-switch to turn off CET instrumentation on jump
> > tables for switch statements.
>
> Of course, that is a slight regression in security hardening.
>
> Quite frankly, I'm puzzled why the kernel decided to require these
> additional ENDBR instructions.

Kernel is using -mcet-switch today.   Should we document -mcet-switch
and keep it off by default instead?

-- 
H.J.


Re: [PATCH] Use more ARRAY_SIZE.

2022-05-11 Thread David Malcolm via Gcc-patches
On Thu, 2022-05-05 at 14:16 +0200, Martin Liška wrote:
> Patch can bootstrap on x86_64-linux-gnu and survives regression
> tests.
> 
> Ready to be installed?

I looked over the changes to:

  gcc/analyzer/*.cc
  gcc/input.cc
  gcc/jit/*.cc

and they look good to me.

I assume that you enabled "jit" during the testing, right?  (it's not
in --enable-languages=all, which is a perennial source of issues).

Thanks
Dave




[c++] Add module attachment

2022-05-11 Thread Nathan Sidwell

This adds module attachment as a distinct flag to 'in module purview'.
A declaration may have neither or both (as before), but can also have
just the 'in [named-module] purview', which was previously not
representable.

This new state allows some cleanup of redeclarations (particularly the
builtins), which was a little warty.  Some other internal APIs get
similarly clarified.

The main event is the next patch though ...

nathan

--
Nathan SidwellFrom a92ed39c416b2a92f404d9851fdfea5cae7e6b21 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell 
Date: Mon, 9 May 2022 04:47:14 -0700
Subject: [PATCH] [c++] Add module attachment

This adds module attachment as a distinct flag to 'in module purview'.
A declaration may have neither or both (as before), but can also have
just the 'in [named-module] purview', which was previously not
representable.

This new state allows some cleanup of redeclarations (particularly the
builtins), which was a little warty.  Some other internal APIs get
similarly clarified.

	gcc/cp/
	* cp-tree.h (DECL_MODULE_ATTACH_P): New.
	(struct lang_decl_base): Add module_attach_p flag.
	* decl.cc (duplicate_decls): Rework module redeclaration
	checking.
	* module.cc (trees_out::lang_decl_bools): Write attach flag.
	(trees_in::lang_decl_bools): ... and read it back.
	(trees_out::decl_value): Rework module attachment handling.
	(trees_in::decl_value): Rename local var to reflect meaning.
	(trees_in::key_mergeable): Likewise.
	(get_originating_module): Use DECL_MODULE_ATTACH_P.  No need
	to special-case mangling.
	(module_may_redeclare): Reimplement.
	(set_originating_module): Deal with attachment.
	* name-lookup.cc (maybe_record_mergeable_decl): Deal with
	attachment.
	(mergeable_namespace_slots): Likewise.
	(do_nonmember_using_decl): Likewise.
	* name-lookup.h (mergeable_namespace_slots): Adjust parm
	meaning.
	* ptree.cc (cxx_print_decl): Adjust purview & attach printing.
---
 gcc/cp/cp-tree.h  |  14 ++---
 gcc/cp/decl.cc|  23 +
 gcc/cp/module.cc  | 117 +-
 gcc/cp/name-lookup.cc |  17 +++---
 gcc/cp/name-lookup.h  |   2 +-
 gcc/cp/ptree.cc   |  20 ++--
 6 files changed, 114 insertions(+), 79 deletions(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index cfda8337ad8..e16b8d70846 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1725,6 +1725,11 @@ check_constraint_info (tree t)
 #define DECL_MODULE_PURVIEW_P(N) \
   (DECL_LANG_SPECIFIC (DECL_MODULE_CHECK (N))->u.base.module_purview_p)
 
+/* Attached to the named module it is in the purview of.  Decls
+   attached to the global module will have this false.  */
+#define DECL_MODULE_ATTACH_P(N) \
+  (DECL_LANG_SPECIFIC (DECL_MODULE_CHECK (N))->u.base.module_attach_p)
+
 /* True if the live version of the decl was imported.  */
 #define DECL_MODULE_IMPORT_P(NODE) \
   (DECL_LANG_SPECIFIC (DECL_MODULE_CHECK (NODE))->u.base.module_import_p)
@@ -2827,13 +2832,8 @@ struct GTY(()) lang_decl_base {
 
   /* The following apply to VAR, FUNCTION, TYPE, CONCEPT, & NAMESPACE
  decls.  */
-  // FIXME: Purview and Attachment are not the same thing, due to
-  // linkage-declarations.  The modules code presumes they are the
-  // same.  (For context, linkage-decl semantics was a very late
-  // change). We need a module_attachment_p flag, and this will allow
-  // some simplification of how we handle header unit entities.
-  // Hurrah!
-  unsigned module_purview_p : 1;	   /* in module purview (not GMF) */
+  unsigned module_purview_p : 1;	   // in named-module purview
+  unsigned module_attach_p : 1;		   // attached to named module
   unsigned module_import_p : 1; 	   /* from an import */
   unsigned module_entity_p : 1;		   /* is in the entitity ary &
 	  hash.  */
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 4099fdeca5a..5654bc754e6 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -2108,30 +2108,31 @@ duplicate_decls (tree newdecl, tree olddecl, bool hiding, bool was_hidden)
   && TREE_CODE (olddecl) != NAMESPACE_DECL
   && !hiding)
 {
-  if (DECL_ARTIFICIAL (olddecl))
+  if (!module_may_redeclare (olddecl))
 	{
-	  if (module_attach_p ())
+	  if (DECL_ARTIFICIAL (olddecl))
 	error ("declaration %qD conflicts with builtin", newdecl);
 	  else
-	DECL_MODULE_EXPORT_P (olddecl) = DECL_MODULE_EXPORT_P (newdecl);
-	}
-  else
-	{
-	  if (!module_may_redeclare (olddecl))
 	{
 	  error ("declaration %qD conflicts with import", newdecl);
 	  inform (olddecl_loc, "import declared %q#D here", olddecl);
-
-	  return error_mark_node;
 	}
 
-	  if (DECL_MODULE_EXPORT_P (newdecl)
-	  && !DECL_MODULE_EXPORT_P (olddecl))
+	  return error_mark_node;
+	}
+
+  tree not_tmpl = STRIP_TEMPLATE (olddecl);
+  if (DECL_LANG_SPECIFIC (not_tmpl) && DECL_MODULE_ATTACH_P (not_tmpl))
+	{
+	  if (DECL_MODULE_EXPORT_P (STRIP_TEMPLATE (newdecl))
+	  && !DECL_MODULE_EXPORT_P (not_tmpl))
 	{
 	  error ("conflicting 

[PATCH] Use variadic template functions for the gimple_build forwarders

2022-05-11 Thread Richard Biener via Gcc-patches
The following consolidates the forwarders to gimple_build with
UNKNOWN_LOCATION by using two variadic template functions.  This
makes the code visually less disturbing and is in preparation
of adding more forwarders with different stmt insertion schemes.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

2022-05-11  Richard Biener  

* gimple-fold.h (gimple_build): Use variadic template
functions for the gimple_build API forwarders without
location_t argument.
---
 gcc/gimple-fold.h | 45 +++--
 1 file changed, 11 insertions(+), 34 deletions(-)

diff --git a/gcc/gimple-fold.h b/gcc/gimple-fold.h
index 3a0ef54394e..850f917bbc1 100644
--- a/gcc/gimple-fold.h
+++ b/gcc/gimple-fold.h
@@ -73,55 +73,32 @@ extern tree tree_vec_extract (gimple_stmt_iterator *, tree, 
tree, tree, tree);
Supposed to replace force_gimple_operand (fold_buildN (...), ...).  */
 extern tree gimple_build (gimple_seq *, location_t,
  enum tree_code, tree, tree);
-inline tree
-gimple_build (gimple_seq *seq,
- enum tree_code code, tree type, tree op0)
-{
-  return gimple_build (seq, UNKNOWN_LOCATION, code, type, op0);
-}
 extern tree gimple_build (gimple_seq *, location_t,
  enum tree_code, tree, tree, tree);
-inline tree
-gimple_build (gimple_seq *seq,
- enum tree_code code, tree type, tree op0, tree op1)
-{
-  return gimple_build (seq, UNKNOWN_LOCATION, code, type, op0, op1);
-}
 extern tree gimple_build (gimple_seq *, location_t,
  enum tree_code, tree, tree, tree, tree);
+template
 inline tree
-gimple_build (gimple_seq *seq,
- enum tree_code code, tree type, tree op0, tree op1, tree op2)
+gimple_build (gimple_seq *seq, enum tree_code code, tree type, Args ...ops)
 {
-  return gimple_build (seq, UNKNOWN_LOCATION, code, type, op0, op1, op2);
+  static_assert (sizeof...(ops) > 0 && sizeof...(ops) <= 3,
+"Number of operands must be from one to three");
+  return gimple_build (seq, UNKNOWN_LOCATION, code, type, ops...);
 }
+
 extern tree gimple_build (gimple_seq *, location_t, combined_fn, tree);
-inline tree
-gimple_build (gimple_seq *seq, combined_fn fn, tree type)
-{
-  return gimple_build (seq, UNKNOWN_LOCATION, fn, type);
-}
 extern tree gimple_build (gimple_seq *, location_t, combined_fn, tree, tree);
-inline tree
-gimple_build (gimple_seq *seq, combined_fn fn, tree type, tree arg0)
-{
-  return gimple_build (seq, UNKNOWN_LOCATION, fn, type, arg0);
-}
 extern tree gimple_build (gimple_seq *, location_t, combined_fn,
  tree, tree, tree);
-inline tree
-gimple_build (gimple_seq *seq, combined_fn fn,
- tree type, tree arg0, tree arg1)
-{
-  return gimple_build (seq, UNKNOWN_LOCATION, fn, type, arg0, arg1);
-}
 extern tree gimple_build (gimple_seq *, location_t, combined_fn,
  tree, tree, tree, tree);
+template
 inline tree
-gimple_build (gimple_seq *seq, combined_fn fn,
- tree type, tree arg0, tree arg1, tree arg2)
+gimple_build (gimple_seq *seq, combined_fn fn, tree type, Args ...args)
 {
-  return gimple_build (seq, UNKNOWN_LOCATION, fn, type, arg0, arg1, arg2);
+  static_assert (sizeof...(args) < 4,
+"Number of arguments must be less than four");
+  return gimple_build (seq, UNKNOWN_LOCATION, fn, type, args...);
 }
 
 extern tree gimple_convert (gimple_seq *, location_t, tree, tree);
-- 
2.35.3


Re: [PATCH] AArch64: Improve address rematerialization costs

2022-05-11 Thread Richard Biener via Gcc-patches
On Wed, May 11, 2022 at 2:23 PM Richard Sandiford via Gcc-patches
 wrote:
>
> Wilco Dijkstra  writes:
> > Hi Richard,
> >
> >> Yeah, I'm not disagreeing with any of that.  It's just a question of
> >> whether the problem should be fixed by artificially lowering the general
> >> rtx costs with one particular user (RA spill costs) in mind, or whether
> >> it should be fixed by making the RA spill code take the factors above
> >> into account.
> >
> > The RA spill code already works fine on immediates but not on address
> > constants. And the reason is that the current rtx costs for addresses are
> > set artificially high without justification (I checked the patch that 
> > increased
> > the costs but there was nothing explaining why it was beneficial).
>
> But even if the costs are too high, the patch seems to be overcompensating.
> It doesn't make logical sense for an ADRP+LDR to be cheaper than an LDR.
>
> Giving X zero cost means that a sequence like:
>
>   (set (reg x0) X)
>   (set (reg x1) X)
>
> should stay as-is rather than be changed to:
>
>   (set (reg x0) X)
>   (set (reg x1) (reg x0))
>
> I don't think we want that for multi-instruction constants when
> optimising for size.
>
> > It's certainly possible to experiment with increasing the spill costs, but 
> > that
> > won't improve the issue with address constants unless they are at least 
> > doubled.
> > And it has the effect of halving all rtx costs in the register allocator 
> > which is
> > likely to cause regressions. So we'd need to adjust many rtx costs to keep 
> > the
> > allocator working, plus fix any further regressions this causes.
>
> Yeah, I wasn't suggesting that we increase the spill costs.  I'm saying
> that we should look at whether the target-independent RA heuristics need
> to change, whether new target hooks are needed, etc.  We shouldn't go
> into this with the assumption that the target-independent code is
> invariant and that any fix must be in existing aarch64 hooks (rtx costs
> or spill costs).
>
> Maybe it would help to turn the question around for a minute.  Can we
> describe the cases in which it's *better* for the RA to spill a constant
> address to the stack and reload it, rather than rematerialise on demand?

>From the discussion in PR102178 it seems that LRA cannot rematerialize
all "constants" (though here it is constant pool loads).  Some constants
might also not be 'constant'.   See the PR for more fun "spilling" behavior
on x86_64.

It's also said that chosen alternatives might be the reason that
rematerialization
is not choosen and alternatives are chosen based on reload heuristics, not based
on actual costs.

Richard.

> Thanks,
> Richard


Re: [PATCH] configure: add --disable-fix-includes

2022-05-11 Thread Andreas Schwab
On Mai 11 2022, Martin Liška wrote:

> @Joseph: Can you please help me why --disable-$foo disables building $foo
> folder during the build?

# Handle --disable- generically.
for dir in $configdirs $build_configdirs $target_configdirs ; do
  dirname=`echo $dir | sed -e s/target-//g -e s/build-//g -e s/-/_/g`
  varname=`echo $dirname | sed -e s/+/_/g`
  if eval test x\${enable_${varname}} "=" xno ; then
noconfigdirs="$noconfigdirs $dir"
  fi
done

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."


[PATCH, 10 backport] libstdc++: Implement P2325 changes to default-constructibility of views

2022-05-11 Thread Patrick Palka via Gcc-patches
Tested on x86_64-pc-linux-gnu, does this look OK for the 10 branch?

NB: This backport of r12-1606 to the 10 branch deliberately omits parts
of P2325R3 so as to maximize backward compatibility with pre-P2325R3 code.
In particular, we don't remove the default ctors for back_insert_iterator,
front_insert_iterator, ostream_iterator, ref_view and basic_istream_view.
And in the 10 branch we we don't have __non_propagating_cache or the
partial specialization of __box, so the changes to them are omitted too.
Finally, we don't update __cpp_lib_ranges to 202106L because many
significant 202106 Ranges changes still aren't implemented in the 10
branch, e.g. P2281R1 and P2210R2.

===

This implements the wording changes of P2325R3 "Views should not be
required to be default constructible".  Changes are relatively
straightforward, besides perhaps those to __box (which now stands
for copyable-box instead of semiregular-box) and __non_propagating_cache.

For __box, this patch implements the recommended practice to also avoid
std::optional when the boxed type is nothrow_move/copy_constructible.

For __non_propagating_cache, now that it's used by split_view::_M_current,
we need to add assignment from a value of the underlying type to the
subset of the std::optional API implemented for the cache (needed by
split_view::begin()).  Hence the new __non_propagating_cache::operator=
overload.

In passing, this fixes the undesirable list-init in the constructors of
the partial specialization of __box as reported in PR100475 comment #7.

PR libstdc++/103904

libstdc++-v3/ChangeLog:

* include/bits/iterator_concepts.h (weakly_incrementable): Remove
default_initializable requirement.
* include/bits/stl_iterator.h (common_iterator): Constrain the
default ctor.
(counted_iterator): Likewise.
* include/std/ranges (ranges::view): Remove default_initializable
requirement.
(subrange): Constrain the default ctor.
(__detail::__box::operator=): Handle self-assignment.
(single_view): Constraint the default ctor.
(iota_view): Relax semiregular constraint to copyable.
Constrain the default ctor.
(iota_view::_Iterator): Constraint the default ctor.
(filter_view): Likewise.
(filter_view::_Iterator): Likewise.
(transform_view): Likewise.
(transform_view::_Iterator): Likewise.
(take_view): Likewise.
(take_view::_Iterator): Likewise.
(take_while_view): Likewise.
(take_while_view::_Iterator): Likewise.
(drop_while_view): Likewise.
(drop_while_view::_Iterator): Likewise.
(join_view): Likewise.
(split_view): Constrain the default ctor.
(common_view): Likewise.
(reverse_view): Likewise.
(elements_view): Likewise.
(elements_view::_Iterator): Likewise.
* include/std/span (enable_view>):
Define this partial specialization to true unconditionally.
* testsuite/std/ranges/p2325.cc: New test.
* testsuite/std/ranges/single_view.cc (test06): New test.
* testsuite/std/ranges/view.cc: Adjust now that view doesn't
require default_initializable.

(cherry picked from commit 4b4f5666b4c2f3aab2a9f3d53d394e390b9b682d)
---
 libstdc++-v3/include/bits/iterator_concepts.h |   3 +-
 libstdc++-v3/include/bits/stl_iterator.h  |   3 +-
 libstdc++-v3/include/std/ranges   |  78 +---
 libstdc++-v3/include/std/span |   3 +-
 libstdc++-v3/testsuite/std/ranges/p2325.cc| 181 ++
 .../testsuite/std/ranges/single_view.cc   |  15 ++
 libstdc++-v3/testsuite/std/ranges/view.cc |   2 +-
 7 files changed, 249 insertions(+), 36 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/p2325.cc

diff --git a/libstdc++-v3/include/bits/iterator_concepts.h 
b/libstdc++-v3/include/bits/iterator_concepts.h
index 4f118df6b02..a533ae2d279 100644
--- a/libstdc++-v3/include/bits/iterator_concepts.h
+++ b/libstdc++-v3/include/bits/iterator_concepts.h
@@ -573,8 +573,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   /// Requirements on types that can be incremented with ++.
   template
-concept weakly_incrementable = default_initializable<_Iter>
-  && movable<_Iter>
+concept weakly_incrementable = movable<_Iter>
   && requires(_Iter __i)
   {
typename iter_difference_t<_Iter>;
diff --git a/libstdc++-v3/include/bits/stl_iterator.h 
b/libstdc++-v3/include/bits/stl_iterator.h
index 91cfeccecf3..a46872fc3c2 100644
--- a/libstdc++-v3/include/bits/stl_iterator.h
+++ b/libstdc++-v3/include/bits/stl_iterator.h
@@ -1729,6 +1729,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 constexpr
 common_iterator()
 noexcept(is_nothrow_default_constructible_v<_It>)
+requires default_initializable<_It>
 : _M_it(), _M_index(0)
 { }
 
@@ -2106,7 +2107,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // iterator_concept defined in 

libgomp: Remove unused '--with-hsa-runtime', '--with-hsa-runtime-include', '--with-hsa-runtime-lib' (was: libgomp GCN plugin: Clean up unused references to system-provided HSA Runtime library)

2022-05-11 Thread Thomas Schwinge
Hi!

On 2022-04-06T12:02:08+0200, Thomas Schwinge  wrote:
> On 2021-01-14T15:50:23+0100, I wrote:
>> I'm raising here an issue with HSA libgomp plugin code changes from a
>> while ago.  While HSA is now no longer relevant for GCC master branch,
>> the same code has also been copied into the GCN libgomp plugin.
>
> Here is another small clean-up patch (to enable further clean-up):
>
>> This is commit b8d89b03db5f212919e4571671ebb4f5f8b1e19d (r242749) "Remove
>> build dependence on HSA run-time":
>>
>> On 2016-11-22T14:27:44+0100, Martin Jambor  wrote:
>>> --- a/libgomp/plugin/configfrag.ac
>>> +++ b/libgomp/plugin/configfrag.ac
>>
>>> @@ -195,8 +183,8 @@ if test x"$enable_offload_targets" != x; then
>>>  tgt_name=hsa
>>>  PLUGIN_HSA=$tgt
>>>  PLUGIN_HSA_CPPFLAGS=$HSA_RUNTIME_CPPFLAGS
>>> -PLUGIN_HSA_LDFLAGS="$HSA_RUNTIME_LDFLAGS $HSA_KMT_LDFLAGS"
>>> -PLUGIN_HSA_LIBS="-lhsa-runtime64 -lhsakmt"
>>> +PLUGIN_HSA_LDFLAGS="$HSA_RUNTIME_LDFLAGS"
>>> +PLUGIN_HSA_LIBS="-ldl"
>>
>> So this switched from directly linking against 'libhsa-runtime64.so' to a
>> 'libdl'-based runtime linking variant.
>
> (Not intending to change anything regarding that.)
>
> Given the 'PLUGIN_HSA_LIBS' change cited above, OK to push the attached
> "libgomp GCN plugin: Clean up unused references to system-provided HSA
> Runtime library"?

With that done, I've then pushed to master branch
commit 876ac21b7e796f9efb859dfb46ae2a4126b0b782
"libgomp: Remove unused '--with-hsa-runtime',
'--with-hsa-runtime-include', '--with-hsa-runtime-lib'",
see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 876ac21b7e796f9efb859dfb46ae2a4126b0b782 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 6 Apr 2022 12:26:13 +0200
Subject: [PATCH] libgomp: Remove unused '--with-hsa-runtime',
 '--with-hsa-runtime-include', '--with-hsa-runtime-lib'

With recent commit 2e309a4eff80e55b53d32d26926a2a94eabfea21 "libgomp testsuite:
Don't amend 'LD_LIBRARY_PATH' for system-provided HSA Runtime library",
and commit d6adba307508c75f1ccb2121eb1a43c9ab1d4056 "libgomp GCN plugin:
 Clean up unused references to system-provided HSA Runtime library", the last
uses of '--with-hsa-runtime' etc. are gone.

	gcc/
	* doc/install.texi: Don't document '--with-hsa-runtime',
	'--with-hsa-runtime-include', '--with-hsa-runtime-lib'.
	libgomp/
	* plugin/configfrag.ac: Remove '--with-hsa-runtime',
	'--with-hsa-runtime-include', '--with-hsa-runtime-lib' processing.
	* Makefile.in: Regenerate.
	* configure: Likewise.
	* testsuite/Makefile.in: Likewise.
---
 gcc/doc/install.texi  | 12 
 libgomp/Makefile.in   |  2 --
 libgomp/configure | 55 ++-
 libgomp/plugin/configfrag.ac  | 29 --
 libgomp/testsuite/Makefile.in |  2 --
 5 files changed, 2 insertions(+), 98 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 76392302653..042241e9fad 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2329,18 +2329,6 @@ those are in separate optional packages and where the presence or absence
 of those optional packages should determine the actual supported offloading
 target set rather than the GCC configure-time selection.
 
-@item --with-hsa-runtime=@var{pathname}
-@itemx --with-hsa-runtime-include=@var{pathname}
-@itemx --with-hsa-runtime-lib=@var{pathname}
-
-If you configure GCC with offloading which uses an HSA run-time such as
-AMDGCN but do not have the HSA run-time library installed in a standard
-location then you can explicitly specify the directory where they are
-installed.  The @option{--with-hsa-runtime=@/@var{hsainstalldir}} option
-is a shorthand for
-@option{--with-hsa-runtime-lib=@/@var{hsainstalldir}/lib} and
-@option{--with-hsa-runtime-include=@/@var{hsainstalldir}/include}.
-
 @item --enable-cet
 @itemx --disable-cet
 Enable building target run-time libraries with control-flow
diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in
index 1c2ac5695ab..f2712aa5133 100644
--- a/libgomp/Makefile.in
+++ b/libgomp/Makefile.in
@@ -385,8 +385,6 @@ FC = @FC@
 FCFLAGS = @FCFLAGS@
 FGREP = @FGREP@
 GREP = @GREP@
-HSA_RUNTIME_INCLUDE = @HSA_RUNTIME_INCLUDE@
-HSA_RUNTIME_LIB = @HSA_RUNTIME_LIB@
 INSTALL = @INSTALL@
 INSTALL_DATA = @INSTALL_DATA@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
diff --git a/libgomp/configure b/libgomp/configure
index e735e4c5f2a..3de8eb2641f 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -675,8 +675,6 @@ offload_targets
 offload_plugins
 PLUGIN_GCN_LIBS
 PLUGIN_GCN
-HSA_RUNTIME_LIB
-HSA_RUNTIME_INCLUDE
 PLUGIN_NVPTX_LIBS
 PLUGIN_NVPTX_LDFLAGS
 PLUGIN_NVPTX_CPPFLAGS
@@ -834,9 +832,6 @@ enable_maintainer_mode
 

libgomp GCN plugin: Clean up always-empty 'PLUGIN_GCN_CPPFLAGS', 'PLUGIN_GCN_LDFLAGS' (was: libgomp GCN plugin: Clean up unused references to system-provided HSA Runtime library)

2022-05-11 Thread Thomas Schwinge
Hi!

On 2022-04-06T12:02:08+0200, I wrote:
> On 2021-01-14T15:50:23+0100, I wrote:
>> I'm raising here an issue with HSA libgomp plugin code changes from a
>> while ago.  While HSA is now no longer relevant for GCC master branch,
>> the same code has also been copied into the GCN libgomp plugin.
>
> Here is another small clean-up patch (to enable further clean-up):
>
>> This is commit b8d89b03db5f212919e4571671ebb4f5f8b1e19d (r242749) "Remove
>> build dependence on HSA run-time":
>>
>> On 2016-11-22T14:27:44+0100, Martin Jambor  wrote:
>>> --- a/libgomp/plugin/configfrag.ac
>>> +++ b/libgomp/plugin/configfrag.ac
>>
>>> @@ -195,8 +183,8 @@ if test x"$enable_offload_targets" != x; then
>>>  tgt_name=hsa
>>>  PLUGIN_HSA=$tgt
>>>  PLUGIN_HSA_CPPFLAGS=$HSA_RUNTIME_CPPFLAGS
>>> -PLUGIN_HSA_LDFLAGS="$HSA_RUNTIME_LDFLAGS $HSA_KMT_LDFLAGS"
>>> -PLUGIN_HSA_LIBS="-lhsa-runtime64 -lhsakmt"
>>> +PLUGIN_HSA_LDFLAGS="$HSA_RUNTIME_LDFLAGS"
>>> +PLUGIN_HSA_LIBS="-ldl"
>>
>> So this switched from directly linking against 'libhsa-runtime64.so' to a
>> 'libdl'-based runtime linking variant.
>
> (Not intending to change anything regarding that.)
>
> Given the 'PLUGIN_HSA_LIBS' change cited above, OK to push the attached
> "libgomp GCN plugin: Clean up unused references to system-provided HSA
> Runtime library"?

With that done, I've then pushed to master branch
commit 91a6dcd14915181b4bce51cd44b56a3e9f9d35d8 "libgomp GCN plugin:
Clean up always-empty 'PLUGIN_GCN_CPPFLAGS', 'PLUGIN_GCN_LDFLAGS'", see
attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 91a6dcd14915181b4bce51cd44b56a3e9f9d35d8 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 6 Apr 2022 12:15:28 +0200
Subject: [PATCH] libgomp GCN plugin: Clean up always-empty
 'PLUGIN_GCN_CPPFLAGS', 'PLUGIN_GCN_LDFLAGS'

After recent commit d6adba307508c75f1ccb2121eb1a43c9ab1d4056
"libgomp GCN plugin: Clean up unused references to system-provided HSA Runtime
library", these aren't set anymore.

	libgomp/
	* plugin/Makefrag.am (libgomp_plugin_gcn_la_CPPFLAGS): Don't
	consider 'PLUGIN_GCN_CPPFLAGS'.
	(libgomp_plugin_gcn_la_LDFLAGS): Don't consider
	'PLUGIN_GCN_LDFLAGS'.
	* plugin/configfrag.ac (PLUGIN_GCN_CPPFLAGS, PLUGIN_GCN_LDFLAGS):
	Remove.
	* Makefile.in: Regenerate.
	* configure: Likewise.
	* testsuite/Makefile.in: Likewise.
---
 libgomp/Makefile.in   | 10 --
 libgomp/configure | 10 ++
 libgomp/plugin/Makefrag.am|  3 +--
 libgomp/plugin/configfrag.ac  |  4 
 libgomp/testsuite/Makefile.in |  2 --
 5 files changed, 7 insertions(+), 22 deletions(-)

diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in
index 22cb2136a08..1c2ac5695ab 100644
--- a/libgomp/Makefile.in
+++ b/libgomp/Makefile.in
@@ -434,8 +434,6 @@ PACKAGE_VERSION = @PACKAGE_VERSION@
 PATH_SEPARATOR = @PATH_SEPARATOR@
 PERL = @PERL@
 PLUGIN_GCN = @PLUGIN_GCN@
-PLUGIN_GCN_CPPFLAGS = @PLUGIN_GCN_CPPFLAGS@
-PLUGIN_GCN_LDFLAGS = @PLUGIN_GCN_LDFLAGS@
 PLUGIN_GCN_LIBS = @PLUGIN_GCN_LIBS@
 PLUGIN_NVPTX = @PLUGIN_NVPTX@
 PLUGIN_NVPTX_CPPFLAGS = @PLUGIN_NVPTX_CPPFLAGS@
@@ -574,12 +572,12 @@ libgomp_la_SOURCES = alloc.c atomic.c barrier.c critical.c env.c \
 # AMD GCN plugin
 @PLUGIN_GCN_TRUE@libgomp_plugin_gcn_version_info = -version-info $(libtool_VERSION)
 @PLUGIN_GCN_TRUE@libgomp_plugin_gcn_la_SOURCES = plugin/plugin-gcn.c
-@PLUGIN_GCN_TRUE@libgomp_plugin_gcn_la_CPPFLAGS = $(AM_CPPFLAGS) $(PLUGIN_GCN_CPPFLAGS) \
+@PLUGIN_GCN_TRUE@libgomp_plugin_gcn_la_CPPFLAGS = $(AM_CPPFLAGS) \
 @PLUGIN_GCN_TRUE@	-D_GNU_SOURCE
 
-@PLUGIN_GCN_TRUE@libgomp_plugin_gcn_la_LDFLAGS =  \
-@PLUGIN_GCN_TRUE@	$(libgomp_plugin_gcn_version_info) \
-@PLUGIN_GCN_TRUE@	$(lt_host_flags) $(PLUGIN_GCN_LDFLAGS)
+@PLUGIN_GCN_TRUE@libgomp_plugin_gcn_la_LDFLAGS = $(libgomp_plugin_gcn_version_info) \
+@PLUGIN_GCN_TRUE@	$(lt_host_flags)
+
 @PLUGIN_GCN_TRUE@libgomp_plugin_gcn_la_LIBADD = libgomp.la $(PLUGIN_GCN_LIBS)
 @PLUGIN_GCN_TRUE@libgomp_plugin_gcn_la_LIBTOOLFLAGS = --tag=disable-static
 nodist_noinst_HEADERS = libgomp_f.h
diff --git a/libgomp/configure b/libgomp/configure
index cf1d1fbe195..e735e4c5f2a 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -674,8 +674,6 @@ offload_additional_options
 offload_targets
 offload_plugins
 PLUGIN_GCN_LIBS
-PLUGIN_GCN_LDFLAGS
-PLUGIN_GCN_CPPFLAGS
 PLUGIN_GCN
 HSA_RUNTIME_LIB
 HSA_RUNTIME_INCLUDE
@@ -11431,7 +11429,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11434 "configure"
+#line 11432 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11537,7 +11535,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   

Re: [PATCH] AArch64: Improve address rematerialization costs

2022-05-11 Thread Richard Sandiford via Gcc-patches
Wilco Dijkstra  writes:
> Hi Richard,
>
>> Yeah, I'm not disagreeing with any of that.  It's just a question of
>> whether the problem should be fixed by artificially lowering the general
>> rtx costs with one particular user (RA spill costs) in mind, or whether
>> it should be fixed by making the RA spill code take the factors above
>> into account.
>
> The RA spill code already works fine on immediates but not on address
> constants. And the reason is that the current rtx costs for addresses are
> set artificially high without justification (I checked the patch that 
> increased
> the costs but there was nothing explaining why it was beneficial).

But even if the costs are too high, the patch seems to be overcompensating.
It doesn't make logical sense for an ADRP+LDR to be cheaper than an LDR.

Giving X zero cost means that a sequence like:

  (set (reg x0) X)
  (set (reg x1) X)

should stay as-is rather than be changed to:

  (set (reg x0) X)
  (set (reg x1) (reg x0))

I don't think we want that for multi-instruction constants when
optimising for size.

> It's certainly possible to experiment with increasing the spill costs, but 
> that
> won't improve the issue with address constants unless they are at least 
> doubled.
> And it has the effect of halving all rtx costs in the register allocator 
> which is
> likely to cause regressions. So we'd need to adjust many rtx costs to keep the
> allocator working, plus fix any further regressions this causes.

Yeah, I wasn't suggesting that we increase the spill costs.  I'm saying
that we should look at whether the target-independent RA heuristics need
to change, whether new target hooks are needed, etc.  We shouldn't go
into this with the assumption that the target-independent code is
invariant and that any fix must be in existing aarch64 hooks (rtx costs
or spill costs).

Maybe it would help to turn the question around for a minute.  Can we
describe the cases in which it's *better* for the RA to spill a constant
address to the stack and reload it, rather than rematerialise on demand?

Thanks,
Richard


Re: [PATCH] docs: document --with-zstd

2022-05-11 Thread Martin Liška
On 5/11/22 13:50, Richard Biener wrote:
> Should that use @option{}?  --with-gmp etc. just refer to
> @option{--with-gmp-include} without PATH/*, so please drop that here, too.

Sure, adjusted and pushed.

Martin


Re: [PATCH] configure: add --disable-fix-includes

2022-05-11 Thread Martin Liška
On 5/11/22 13:31, Rainer Orth wrote:
> Hi Martin,
> 
 Subject: [PATCH] configure: add --disable-fix-includes
>>>
>>> As I've mentioned before, I believe, the command is called fixincludes
>>> in current gcc docs, and the option should reflect that, not introduce a
>>> name used nowhere else.
>>
>> No, I can't use it, because even with current master using 
>> --disable-fixincludes
>> means the tool is not built at all. It results with:
>>
>> g++ -g -DIN_GCC -fPIC -fno-exceptions -fno-rtti
>> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
>> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
>> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common
>> -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o
>> build/genchecksum \
>> build/genchecksum.o 
>> ../build-x86_64-pc-linux-gnu/libiberty/pic/libiberty.a
>> make: *** No rule to make target
>> '../build-x86_64-pc-linux-gnu/fixincludes/fixinc.sh', needed by
>> 'stmp-fixinc'.  Stop.
>> make: *** Waiting for unfinished jobs
> 
> and why not just fix that, rather than introducing yet another option?

I would like to, but I don't understant autoconf much :/

@Joseph: Can you please help me why --disable-$foo disables building $foo
folder during the build?

Thanks,
Martin

> This error suggests current --disable-fixincludes is useless on it's
> own.
> 
>   Rainer
> 



Re: [PATCH] Remove size limit of PCH

2022-05-11 Thread Jakub Jelinek via Gcc-patches
On Tue, May 10, 2022 at 09:30:03PM +0800, LIU Hao via Gcc-patches wrote:
> From 2e314baed84fd80b3b3c4c67787a032b86dd54dc Mon Sep 17 00:00:00 2001
> From: LIU Hao 
> Date: Tue, 10 May 2022 13:19:07 +0800
> Subject: [PATCH] [PR14940] Remove size limit of PCH
> 
> There shouldn't be such a limit in practice.
> 
> 2022-05-03  LIU Hao 
> 
>   PR pch/14940
>   * config/i386/host-mingw32.cc (pch_VA_max_size): Remove.
>   (mingw32_gt_pch_get_address): Remove size limit.

This looks reasonable, but doesn't contain the most important part.
As mentioned in https://gcc.gnu.org/r12-5855
the generic part can now support relocation of PCH, so it is fine if it is
mapped at some other address, it is preferrable if it is mapped at the same
address as it was written for, but if not, the generic code can relocate it.

So, beyond your changes, I'd suggest to change:
  /* Retry five times, as here might occure a race with multiple gcc's
 instances at same time.  */
  for (r = 0; r < 5; r++)
   {
  mmap_addr = MapViewOfFileEx (mmap_handle, FILE_MAP_COPY, 0, offset,
   size, addr);
  if (mmap_addr == addr)
break;
  if (r != 4)
Sleep (500);
   }

  if (mmap_addr != addr)
{
  w32_error (__FUNCTION__, __FILE__, __LINE__, "MapViewOfFileEx");
  CloseHandle(mmap_handle);
  return  -1;
}

IMHO you can just drop the loop, sleep of half a second is almost certainly
slower than the relocation handling, so I'd just
  mmap_addr = MapViewOfFileEx (mmap_handle, FILE_MAP_COPY, 0, offset,
   size, addr);
  if (mmap_addr == NULL)
{
  w32_error (__FUNCTION__, __FILE__, __LINE__, "MapViewOfFileEx");
  CloseHandle(mmap_handle);
  return -1;
}

  addr = mmap_addr;

This, if it mmaps the file at the right address, nice, if not, let the
caller know (through updating addr) that it needs to relocate it,
but if the mapping failed, fail.

Jakub



Re: [PATCH] docs: document --with-zstd

2022-05-11 Thread Richard Biener via Gcc-patches
On Wed, May 11, 2022 at 1:22 PM Martin Liška  wrote:
>
> Ready to be installed?
> Thanks,
> Martin
>
> PR other/105527
>
> gcc/ChangeLog:
>
> * doc/install.texi: Document the configure option --with-zstd.
> ---
>  gcc/doc/install.texi | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index 10bfceffceb..1d7e8530a23 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -2371,6 +2371,11 @@ For a native build and cross compiles that have target 
> headers, the option's
>  default is derived from glibc's behavior. When glibc clamps float_t to 
> double,
>  GCC follows and enables the option. For other cross compiles, the default is
>  disabled.
> +
> +@item --with-zstd
> +Specify prefix directory for installed zstd library.
> +Equivalent to @code{--with-zstd-include=PATH/include} plus
> +@code{--with-zstd-lib=PATH/lib}.

Should that use @option{}?  --with-gmp etc. just refer to
@option{--with-gmp-include} without PATH/*, so please drop that here, too.

OK whith those changes.

Richard.

>  @end table
>
>  @subheading Cross-Compiler-Specific Options
> --
> 2.36.1
>


Re: [PATCH] rtl-optimization/105559 - avoid quadratic behavior in delete_insn_and_edges

2022-05-11 Thread Jakub Jelinek via Gcc-patches
On Wed, May 11, 2022 at 01:45:13PM +0200, Richard Biener via Gcc-patches wrote:
> On Wed, 11 May 2022, Richard Biener wrote:
> 
> > When the insn to delete is a debug insn there's no point in figuring
> > out whether it might be the last real insn and thus we have to purge
> > dead edges.
> > 
> > Bootstrap and regtest running on x86_64-unknown-linux-gnu.
> 
> Actually revisiting PR94618 which introduced this the following is better
> and is what I'm going to test, making sure to never purge edges for
> DEBUG_INSNs.
> 
> diff --git a/gcc/cfgrtl.cc b/gcc/cfgrtl.cc
> index 74ea14efc61..06be46d75df 100644
> --- a/gcc/cfgrtl.cc
> +++ b/gcc/cfgrtl.cc
> @@ -235,7 +235,7 @@ delete_insn_and_edges (rtx_insn *insn)
>  {
>bool purge = false;
>  
> -  if (INSN_P (insn) && BLOCK_FOR_INSN (insn))
> +  if (NONDEBUG_INSN_P (insn) && BLOCK_FOR_INSN (insn))
>  {
>basic_block bb = BLOCK_FOR_INSN (insn);
>if (BB_END (bb) == insn)

Yeah, wanted to suggest the same.  Because
purge_dead_edges actually doesn't punt on DEBUG_INSNs, but instead
it looks for the last non-debug insn in the same bb before it if any.

Jakub



Re: [PATCH] rtl-optimization/105559 - avoid quadratic behavior in delete_insn_and_edges

2022-05-11 Thread Richard Biener via Gcc-patches
On Wed, 11 May 2022, Richard Biener wrote:

> When the insn to delete is a debug insn there's no point in figuring
> out whether it might be the last real insn and thus we have to purge
> dead edges.
> 
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Actually revisiting PR94618 which introduced this the following is better
and is what I'm going to test, making sure to never purge edges for
DEBUG_INSNs.

diff --git a/gcc/cfgrtl.cc b/gcc/cfgrtl.cc
index 74ea14efc61..06be46d75df 100644
--- a/gcc/cfgrtl.cc
+++ b/gcc/cfgrtl.cc
@@ -235,7 +235,7 @@ delete_insn_and_edges (rtx_insn *insn)
 {
   bool purge = false;
 
-  if (INSN_P (insn) && BLOCK_FOR_INSN (insn))
+  if (NONDEBUG_INSN_P (insn) && BLOCK_FOR_INSN (insn))
 {
   basic_block bb = BLOCK_FOR_INSN (insn);
   if (BB_END (bb) == insn)



> 2022-05-11  Richard Biener  
> 
>   PR rtl-optimization/105559
>   * cfgrtl.cc (delete_insn_and_edges): Only perform search to BB_END
>   for non-debug insns.
> ---
>  gcc/cfgrtl.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/cfgrtl.cc b/gcc/cfgrtl.cc
> index 74ea14efc61..8e9fd1266b3 100644
> --- a/gcc/cfgrtl.cc
> +++ b/gcc/cfgrtl.cc
> @@ -240,7 +240,7 @@ delete_insn_and_edges (rtx_insn *insn)
>basic_block bb = BLOCK_FOR_INSN (insn);
>if (BB_END (bb) == insn)
>   purge = true;
> -  else if (DEBUG_INSN_P (BB_END (bb)))
> +  else if (NONDEBUG_INSN_P (insn) && DEBUG_INSN_P (BB_END (bb)))
>   for (rtx_insn *dinsn = NEXT_INSN (insn);
>DEBUG_INSN_P (dinsn); dinsn = NEXT_INSN (dinsn))
> if (BB_END (bb) == dinsn)
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)


Re: [PATCH] Remove size limit of PCH

2022-05-11 Thread Jonathan Yong via Gcc-patches

On 5/10/22 13:30, LIU Hao wrote:

在 2022-05-10 20:00, Xi Ruoyao 写道:

On Tue, 2022-05-10 at 19:35 +0800, LIU Hao via Gcc-patches wrote:


Subject: [PATCH] Remove size limit of PCH


Make it "Remove size limit of PCH [PR14940]", so once it's committed a
message will show up in bugzilla.



Here is the revised patch.







Thanks, I will commit soon if there are no objections.



OpenPGP_0x713B5FE29C145D45_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


[PATCH] rtl-optimization/105559 - avoid quadratic behavior in delete_insn_and_edges

2022-05-11 Thread Richard Biener via Gcc-patches
When the insn to delete is a debug insn there's no point in figuring
out whether it might be the last real insn and thus we have to purge
dead edges.

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

2022-05-11  Richard Biener  

PR rtl-optimization/105559
* cfgrtl.cc (delete_insn_and_edges): Only perform search to BB_END
for non-debug insns.
---
 gcc/cfgrtl.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/cfgrtl.cc b/gcc/cfgrtl.cc
index 74ea14efc61..8e9fd1266b3 100644
--- a/gcc/cfgrtl.cc
+++ b/gcc/cfgrtl.cc
@@ -240,7 +240,7 @@ delete_insn_and_edges (rtx_insn *insn)
   basic_block bb = BLOCK_FOR_INSN (insn);
   if (BB_END (bb) == insn)
purge = true;
-  else if (DEBUG_INSN_P (BB_END (bb)))
+  else if (NONDEBUG_INSN_P (insn) && DEBUG_INSN_P (BB_END (bb)))
for (rtx_insn *dinsn = NEXT_INSN (insn);
 DEBUG_INSN_P (dinsn); dinsn = NEXT_INSN (dinsn))
  if (BB_END (bb) == dinsn)
-- 
2.35.3


Re: [PATCH] configure: add --disable-fix-includes

2022-05-11 Thread Rainer Orth
Hi Martin,

>>> Subject: [PATCH] configure: add --disable-fix-includes
>> 
>> As I've mentioned before, I believe, the command is called fixincludes
>> in current gcc docs, and the option should reflect that, not introduce a
>> name used nowhere else.
>
> No, I can't use it, because even with current master using 
> --disable-fixincludes
> means the tool is not built at all. It results with:
>
> g++ -g -DIN_GCC -fPIC -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common
> -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o
> build/genchecksum \
> build/genchecksum.o ../build-x86_64-pc-linux-gnu/libiberty/pic/libiberty.a
> make: *** No rule to make target
> '../build-x86_64-pc-linux-gnu/fixincludes/fixinc.sh', needed by
> 'stmp-fixinc'.  Stop.
> make: *** Waiting for unfinished jobs

and why not just fix that, rather than introducing yet another option?
This error suggests current --disable-fixincludes is useless on it's
own.

Rainer

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


[PATCH] docs: document --with-zstd

2022-05-11 Thread Martin Liška
Ready to be installed?
Thanks,
Martin

PR other/105527

gcc/ChangeLog:

* doc/install.texi: Document the configure option --with-zstd.
---
 gcc/doc/install.texi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 10bfceffceb..1d7e8530a23 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2371,6 +2371,11 @@ For a native build and cross compiles that have target 
headers, the option's
 default is derived from glibc's behavior. When glibc clamps float_t to double,
 GCC follows and enables the option. For other cross compiles, the default is
 disabled.
+
+@item --with-zstd
+Specify prefix directory for installed zstd library.
+Equivalent to @code{--with-zstd-include=PATH/include} plus
+@code{--with-zstd-lib=PATH/lib}.
 @end table
 
 @subheading Cross-Compiler-Specific Options
-- 
2.36.1



[PATCH] Implement some of fold_binary_op_with_conditional_arg in match.pd

2022-05-11 Thread Richard Biener via Gcc-patches
The following allows (c != 0 ? 0 : 100) != 0 to be simplified as
c != 0 as fold_binary_op_with_conditional_arg would have done
via forwprop and GENERIC folding.  Likewise it allows to combine
(a != 0) != 0 directly via match.pd instead of only via
forwprop and again fold_binary_op_with_conditional_arg.

The patterns do not fully implement all cases of
fold_binary_op_with_conditional_arg, some aspects like
"any of the operands simplify" cannot currently be expressed.

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

2022-05-11  Richard Biener  

* generic-match-head.cc: Include tree-eh.h.
* match.pd ((cond ...) cmp X): New simplification inspired
by fold_binary_op_with_conditional_arg.
(eq/ne (cmp ...) true/false): Likewise.

* gcc.dg/tree-ssa/pr61839_1.c: Adjust.
* gcc.dg/tree-ssa/vrp24.c: Likewise.
---
 gcc/generic-match-head.cc |  1 +
 gcc/match.pd  | 41 ++-
 gcc/testsuite/gcc.dg/tree-ssa/pr61839_1.c |  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/vrp24.c |  4 +--
 4 files changed, 44 insertions(+), 4 deletions(-)

diff --git a/gcc/generic-match-head.cc b/gcc/generic-match-head.cc
index e11a736b343..cb0fbd32fa6 100644
--- a/gcc/generic-match-head.cc
+++ b/gcc/generic-match-head.cc
@@ -38,6 +38,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "optabs-tree.h"
 #include "dbgcnt.h"
 #include "tm.h"
+#include "tree-eh.h"
 
 /* Routine to determine if the types T1 and T2 are effectively
the same for GENERIC.  If T1 or T2 is not a type, the test
diff --git a/gcc/match.pd b/gcc/match.pd
index 632243ea92e..f5efa77560c 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4656,7 +4656,34 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (ic == icmp)
 (icmp @0 @1)
 (if (ic == ncmp)
- (ncmp @0 @1))
+ (ncmp @0 @1)
+ /* The following bits are handled by fold_binary_op_with_conditional_arg.  */
+ (simplify
+  (ne (cmp@2 @0 @1) integer_zerop)
+  (if (types_match (type, TREE_TYPE (@2)))
+   (cmp @0 @1)))
+ (simplify
+  (eq (cmp@2 @0 @1) integer_truep)
+  (if (types_match (type, TREE_TYPE (@2)))
+   (cmp @0 @1)))
+ (simplify
+  (ne (cmp@2 @0 @1) integer_truep)
+  (if (types_match (type, TREE_TYPE (@2)))
+   (with { enum tree_code ic = invert_tree_comparison
+(cmp, HONOR_NANS (@0)); }
+(if (ic == icmp)
+ (icmp @0 @1)
+ (if (ic == ncmp)
+  (ncmp @0 @1))
+ (simplify
+  (eq (cmp@2 @0 @1) integer_zerop)
+  (if (types_match (type, TREE_TYPE (@2)))
+   (with { enum tree_code ic = invert_tree_comparison
+(cmp, HONOR_NANS (@0)); }
+(if (ic == icmp)
+ (icmp @0 @1)
+ (if (ic == ncmp)
+  (ncmp @0 @1)))
 
 /* Transform comparisons of the form X - Y CMP 0 to X CMP Y.
??? The transformation is valid for the other operators if overflow
@@ -5486,6 +5513,18 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   (cmp (bit_and@2 @0 integer_pow2p@1) @1)
   (icmp @2 { build_zero_cst (TREE_TYPE (@0)); })))
 
+/* From fold_binary_op_with_conditional_arg handle the case of
+   rewriting (a ? b : c) > d to a ? (b > d) : (c > d) when the
+   compares simplify.  */
+(for cmp (simple_comparison)
+ (simplify
+  (cmp:c (cond @0 @1 @2) @3)
+  /* Do not move possibly trapping operations into the conditional as this
+ pessimizes code and causes gimplification issues when applied late.  */
+  (if (!FLOAT_TYPE_P (TREE_TYPE (@3))
+   || operation_could_trap_p (cmp, true, false, @3))
+   (cond @0 (cmp! @1 @3) (cmp! @2 @3)
+
 (for cmp (ge lt)
 /* x < 0 ? ~y : y into (x >> (prec-1)) ^ y. */
 /* x >= 0 ? ~y : y into ~((x >> (prec-1)) ^ y). */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr61839_1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr61839_1.c
index f5af7a1d6b6..d41256736a2 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr61839_1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr61839_1.c
@@ -38,7 +38,7 @@ int main ()
 }
 
 /* Scan for c = 972195717) >> [0, 1] in function foo.  */
-/* { dg-final { scan-tree-dump-times "486097858 : 972195717" 1  "vrp1" } } */
+/* { dg-final { scan-tree-dump-times "972195717 : 486097858" 1  "vrp1" } } */
 
 /* Previously we were checking for two ?: with constant PHI arguments,
but now we collapse them into one.  */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp24.c 
b/gcc/testsuite/gcc.dg/tree-ssa/vrp24.c
index 91015da86ae..c28ca473fc6 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/vrp24.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp24.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fno-tree-forwprop -fdump-tree-evrp-details 
-fdump-tree-optimized -fno-tree-ccp" } */
+/* { dg-options "-O2 -fno-tree-forwprop -fdump-tree-evrp-details 
-fdump-tree-optimized -fno-tree-ccp --param logical-op-non-short-circuit=1" } */
 
 
 struct rtx_def;
@@ -89,5 +89,5 @@ L7:
boolean operation.  */
 
 /* { dg-final { scan-tree-dump-times "Simplified relational" 2 "evrp" } } */
-/* { dg-final { scan-tree-dump-times "if " 4 "optimized" } } 

Re: [PATCH] configure: add --disable-fix-includes

2022-05-11 Thread Martin Liška
On 5/11/22 13:00, Rainer Orth wrote:
> Hi Martin,
> 
>> On 5/9/22 23:14, Joseph Myers wrote:
>>> If you add a new configure option, it should be documented in 
>>> install.texi.
>>>
>>
>> Both comments fixed in the v2.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>> From 58d431568d6b6163dd9cdc920239f173689a769c Mon Sep 17 00:00:00 2001
>> From: Martin Liska 
>> Date: Fri, 4 Feb 2022 13:42:14 +0100
>> Subject: [PATCH] configure: add --disable-fix-includes
> 
> As I've mentioned before, I believe, the command is called fixincludes
> in current gcc docs, and the option should reflect that, not introduce a
> name used nowhere else.

No, I can't use it, because even with current master using --disable-fixincludes
means the tool is not built at all. It results with:

g++   -g   -DIN_GCC -fPIC-fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  
-DHAVE_CONFIG_H  -DGENERATOR_FILE -static-libstdc++ -static-libgcc   -o 
build/genchecksum \
build/genchecksum.o ../build-x86_64-pc-linux-gnu/libiberty/pic/libiberty.a
make: *** No rule to make target 
'../build-x86_64-pc-linux-gnu/fixincludes/fixinc.sh', needed by 'stmp-fixinc'.  
Stop.
make: *** Waiting for unfinished jobs

Martin

> 
>> Right now, fixinclude takes about 11 seconds on my machine, where
>> it reads 130MB of header files.
>>
>> The number of fixed headers is negligible without any significant
>> change.
> 
> Please speak for Linux, but not for other targets ;-)
> 
>   Rainer
> 



Re: [PATCH] AArch64: Improve address rematerialization costs

2022-05-11 Thread Wilco Dijkstra via Gcc-patches
Hi Richard,

> Yeah, I'm not disagreeing with any of that.  It's just a question of
> whether the problem should be fixed by artificially lowering the general
> rtx costs with one particular user (RA spill costs) in mind, or whether
> it should be fixed by making the RA spill code take the factors above
> into account.

The RA spill code already works fine on immediates but not on address
constants. And the reason is that the current rtx costs for addresses are
set artificially high without justification (I checked the patch that increased
the costs but there was nothing explaining why it was beneficial).

It's certainly possible to experiment with increasing the spill costs, but that
won't improve the issue with address constants unless they are at least doubled.
And it has the effect of halving all rtx costs in the register allocator which 
is
likely to cause regressions. So we'd need to adjust many rtx costs to keep the
allocator working, plus fix any further regressions this causes.

Cheers,
Wilco


Re: [PATCH] configure: add --disable-fix-includes

2022-05-11 Thread Rainer Orth
Hi Martin,

> On 5/9/22 23:14, Joseph Myers wrote:
>> If you add a new configure option, it should be documented in 
>> install.texi.
>> 
>
> Both comments fixed in the v2.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> From 58d431568d6b6163dd9cdc920239f173689a769c Mon Sep 17 00:00:00 2001
> From: Martin Liska 
> Date: Fri, 4 Feb 2022 13:42:14 +0100
> Subject: [PATCH] configure: add --disable-fix-includes

As I've mentioned before, I believe, the command is called fixincludes
in current gcc docs, and the option should reflect that, not introduce a
name used nowhere else.

> Right now, fixinclude takes about 11 seconds on my machine, where
> it reads 130MB of header files.
>
> The number of fixed headers is negligible without any significant
> change.

Please speak for Linux, but not for other targets ;-)

Rainer

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


Re: [PATCH] configure: add --disable-fix-includes

2022-05-11 Thread Martin Liška
On 5/9/22 23:14, Joseph Myers wrote:
> If you add a new configure option, it should be documented in 
> install.texi.
> 

Both comments fixed in the v2.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
MartinFrom 58d431568d6b6163dd9cdc920239f173689a769c Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 4 Feb 2022 13:42:14 +0100
Subject: [PATCH] configure: add --disable-fix-includes

Right now, fixinclude takes about 11 seconds on my machine, where
it reads 130MB of header files.

The number of fixed headers is negligible without any significant
change.

fixincludes/ChangeLog:

	* fixinc.in: Add early exit.

gcc/ChangeLog:

	* Makefile.in: Support disable_fix_includes.
	* configure.ac: Add --disable-fix-includes.
	* configure: Regenerate.
	* doc/install.texi: Document the newly added configure options.
---
 fixincludes/fixinc.in |  6 ++
 gcc/Makefile.in   |  6 --
 gcc/configure | 16 ++--
 gcc/configure.ac  |  6 ++
 gcc/doc/install.texi  |  7 +++
 5 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index 0bd8027a554..9baec3f871d 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -63,6 +63,12 @@ else
   esac
 fi
 
+if test "x$ENABLE_FIX_INCLUDES" = "xno"
+then
+  echo "Skipping fixincludes"
+  exit 0
+fi
+
 # Define what target system we're fixing.
 #
 if test -r ./Makefile; then
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 31ff95500c9..80de547231a 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -401,6 +401,8 @@ PLUGINLIBS = @pluginlibs@
 
 enable_plugin = @enable_plugin@
 
+enable_fix_includes = @enable_fix_includes@
+
 # On MinGW plugin installation involves installing import libraries.
 ifeq ($(enable_plugin),yes)
   plugin_implib := $(if $(strip $(filter mingw%,$(host_os))),yes,no)
@@ -3248,8 +3250,8 @@ stmp-fixinc: gsyslimits.h macro_list fixinc_list \
 	chmod a+rx $${fix_dir} || true; \
 	(TARGET_MACHINE='$(target)'; srcdir=`cd $(srcdir); ${PWD_COMMAND}`; \
 	  SHELL='$(SHELL)'; MACRO_LIST=`${PWD_COMMAND}`/macro_list ; \
-	  gcc_dir=`${PWD_COMMAND}` ; \
-	  export TARGET_MACHINE srcdir SHELL MACRO_LIST && \
+	  gcc_dir=`${PWD_COMMAND}` ; ENABLE_FIX_INCLUDES=${enable_fix_includes} \
+	  export TARGET_MACHINE srcdir SHELL MACRO_LIST ENABLE_FIX_INCLUDES && \
 	  cd $(build_objdir)/fixincludes && \
 	  $(SHELL) ./fixinc.sh "$${gcc_dir}/$${fix_dir}" \
 	$(BUILD_SYSTEM_HEADER_DIR) $(OTHER_FIXINCLUDES_DIRS) ); \
diff --git a/gcc/configure b/gcc/configure
index 5ce0557719a..e29f2cf7d2e 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -839,6 +839,7 @@ with_float
 with_cpu
 enable_multiarch
 enable_multilib
+enable_fix_includes
 coverage_flags
 valgrind_command
 valgrind_path_defines
@@ -958,6 +959,7 @@ enable_werror_always
 enable_checking
 enable_coverage
 enable_gather_detailed_mem_stats
+enable_fix_includes
 enable_valgrind_annotations
 enable_multilib
 enable_multiarch
@@ -1688,6 +1690,7 @@ Optional Features:
   Values are opt, noopt, default is noopt
   --enable-gather-detailed-mem-stats
   enable detailed memory allocation stats gathering
+  --disable-fix-includes  skip fixing of includes
   --enable-valgrind-annotations
   enable valgrind runtime interaction
   --enable-multilib   enable library support for multiple ABIs
@@ -7783,6 +7786,15 @@ cat >>confdefs.h <<_ACEOF
 _ACEOF
 
 
+# Check whether --enable-fix-includes was given.
+if test "${enable_fix_includes+set}" = set; then :
+  enableval=$enable_fix_includes;
+else
+  enable_fix_includes=yes
+fi
+
+
+
 # Check whether --enable-valgrind-annotations was given.
 if test "${enable_valgrind_annotations+set}" = set; then :
   enableval=$enable_valgrind_annotations;
@@ -19673,7 +19685,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19676 "configure"
+#line 19688 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -19779,7 +19791,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19782 "configure"
+#line 19794 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 23bee7010a3..0e20435d38b 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -842,6 +842,12 @@ gather_stats=`if test $enable_gather_detailed_mem_stats != no; then echo 1; else
 AC_DEFINE_UNQUOTED(GATHER_STATISTICS, $gather_stats,
 [Define to enable detailed memory allocation stats gathering.])
 
+AC_ARG_ENABLE(fix-includes,
+[AS_HELP_STRING([--disable-fix-includes],
+		[skip fixing of includes])], [],
+[enable_fix_includes=yes])
+AC_SUBST(enable_fix_includes)
+
 AC_ARG_ENABLE(valgrind-annotations,
 [AS_HELP_STRING([--enable-valgrind-annotations],
 		

[PATCH v2, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

2022-05-11 Thread HAO CHEN GUI via Gcc-patches
Hi,
  This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
Tests show that outputs of xs[min/max]dp are consistent with the standard
of C99 fmin/max.

  This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
of smin/max. So the builtins always generate xs[min/max]dp on all
platforms.

  Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
Is this okay for trunk? Any recommendations? Thanks a lot.

ChangeLog
2022-05-11 Haochen Gui 

gcc/
PR target/103605
* rs6000.md (FMINMAX): New.
(minmax_op): New.
(f3): New pattern by UNSPEC_FMAX and UNSPEC_FMIN.
* rs6000-builtins.def (__builtin_vsx_xsmaxdp): Set pattern to
fmaxdf3.
(__builtin_vsx_xsmindp): Set pattern to fmindf3.

gcc/testsuite/
PR target/103605
* gcc.dg/pr103605.c: New.

patch.diff
diff --git a/gcc/config/rs6000/rs6000-builtins.def 
b/gcc/config/rs6000/rs6000-builtins.def
index f4a9f24bcc5..8b735493b40 100644
--- a/gcc/config/rs6000/rs6000-builtins.def
+++ b/gcc/config/rs6000/rs6000-builtins.def
@@ -1613,10 +1613,10 @@
 XSCVSPDP vsx_xscvspdp {}

   const double __builtin_vsx_xsmaxdp (double, double);
-XSMAXDP smaxdf3 {}
+XSMAXDP fmaxdf3 {}

   const double __builtin_vsx_xsmindp (double, double);
-XSMINDP smindf3 {}
+XSMINDP fmindf3 {}

   const double __builtin_vsx_xsrdpi (double);
 XSRDPI vsx_xsrdpi {}
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 64049a6e521..53c94456eb5 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -158,6 +158,8 @@ (define_c_enum "unspec"
UNSPEC_HASHCHK
UNSPEC_XXSPLTIDP_CONST
UNSPEC_XXSPLTIW_CONST
+   UNSPEC_FMAX
+   UNSPEC_FMIN
   ])

 ;;
@@ -5350,6 +5352,22 @@ (define_insn_and_split "*s3_fpr"
   DONE;
 })

+
+(define_int_iterator FMINMAX [UNSPEC_FMAX UNSPEC_FMIN])
+
+(define_int_attr  minmax_op [(UNSPEC_FMAX "max")
+(UNSPEC_FMIN "min")])
+
+(define_insn "f3"
+  [(set (match_operand:SFDF 0 "vsx_register_operand" "=")
+   (unspec:SFDF [(match_operand:SFDF 1 "vsx_register_operand" "")
+ (match_operand:SFDF 2 "vsx_register_operand" "")]
+ FMINMAX))]
+"TARGET_VSX"
+"xsdp %x0,%x1,%x2"
+[(set_attr "type" "fp")]
+)
+
 (define_expand "movcc"
[(set (match_operand:GPR 0 "gpc_reg_operand")
 (if_then_else:GPR (match_operand 1 "comparison_operator")
diff --git a/gcc/testsuite/gcc.target/powerpc/pr103605.c 
b/gcc/testsuite/gcc.target/powerpc/pr103605.c
new file mode 100644
index 000..e43ac40c2d1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr103605.c
@@ -0,0 +1,37 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-O1 -mvsx" } */
+/* { dg-final { scan-assembler-times {\mxsmaxdp\M} 3 } } */
+/* { dg-final { scan-assembler-times {\mxsmindp\M} 3 } } */
+
+#include 
+
+double test1 (double d0, double d1)
+{
+  return fmin (d0, d1);
+}
+
+float test2 (float d0, float d1)
+{
+  return fmin (d0, d1);
+}
+
+double test3 (double d0, double d1)
+{
+  return fmax (d0, d1);
+}
+
+float test4 (float d0, float d1)
+{
+  return fmax (d0, d1);
+}
+
+double test5 (double d0, double d1)
+{
+  return __builtin_vsx_xsmindp (d0, d1);
+}
+
+double test6 (double d0, double d1)
+{
+  return __builtin_vsx_xsmaxdp (d0, d1);
+}



Re: [PATCH] i386: simplify cpu_feature handling

2022-05-11 Thread Uros Bizjak via Gcc-patches
On Wed, May 11, 2022 at 10:50 AM Martin Liška  wrote:
>
> On 5/11/22 10:27, Uros Bizjak wrote:
> > On Wed, May 11, 2022 at 10:19 AM Martin Liška  wrote:
> >>
> >> On 5/2/22 09:57, Martin Liška wrote:
> >>> On 3/31/22 09:01, Martin Liška wrote:
>  @Jakub: May I install it once stage1 opens?
> >>>
> >>> May I please ping this?
> >>>
> >>> Thanks,
> >>> Martin
> >>>
> 
>  Cheers,
>  Martin
> 
>  On 1/3/22 12:43, Martin Liška wrote:
> > PING: Jakub?
> >
> > On 12/15/21 10:57, Martin Liška wrote:
> >> On 12/14/21 17:12, Jakub Jelinek wrote:
> >>> I'd use INT_TYPE_SIZE - 1 instead of 31.  Otherwise LGTM.
> >>
> >> Installed with that change, thanks.
> >>
> >> Moreover, I'm suggesting a simplification:
> >>
> >> The patch removes unneeded loops for cpu_features2 and CONVERT_EXPR
> >> that can be simplified with NOP_EXPR.
> >>
> >> Survives i386.exp tests, may I install the patch after testing or
> >> is it a stage1 material?
> >>
> >> Thanks,
> >> Martin
> >
> 
> >>>
> >>
> >> CCing Uros.
> >>
> >> May I install the patch?
> >
> > Can you please attach the latest version of the patch? I only found
> > the version from Dec. 15. 2021, which I'm not sure is the latest,
> >
> > Thanks,
> > Uros.
>
> Sure, there's the rebased version of the patch.

LGTM.

Thanks,
Uros.


Re: [PATCH] rs6000: Fix constraint v with rs6000_constraints[RS6000_CONSTRAINT_v]

2022-05-11 Thread Kewen.Lin via Gcc-patches
on 2022/1/27 20:51, Segher Boessenkool wrote:
> On Thu, Jan 27, 2022 at 07:24:53PM +0800, Kewen.Lin wrote:
>> on 2022/1/27 上午1:57, Segher Boessenkool wrote:
>>> I like your original patch better.  But for stage 1, sorry.
>>
>> Thanks Segher!  Is it ok to commit it then?  Or I'll repost this once
>> next stage1 starts.
> 
> Either is fine in this case.
> 

Thanks!  Re-tested and pushed in r13-283.

BR,
Kewen


[Ada] Proof of 'Image support for unsigned integers

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Prove System.Image_U, making the connection with the space available in
the string as computed with System.Width_U and the functions that
support the other direction of 'Value in System.Value_U.

The units that support 'Image cannot be marked Pure anymore, as they now
depend on non-pure units.

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

gcc/ada/

* libgnat/s-imaged.ads: Remove Pure.
* libgnat/s-imagef.ads: Remove Pure.
* libgnat/s-imager.ads: Remove Pure.
* libgnat/s-imageu.adb: Add ghost code.
* libgnat/s-imageu.ads: Add contracts.
* libgnat/s-imde128.ads: Remove Pure.
* libgnat/s-imde32.ads: Remove Pure.
* libgnat/s-imde64.ads: Remove Pure.
* libgnat/s-imfi128.ads: Remove Pure.
* libgnat/s-imfi32.ads: Remove Pure.
* libgnat/s-imfi64.ads: Remove Pure.
* libgnat/s-imgflt.ads: Remove Pure.
* libgnat/s-imglfl.ads: Remove Pure.
* libgnat/s-imgllf.ads: Remove Pure.
* libgnat/s-imglllu.ads: Instantiate with ghost subprograms.
* libgnat/s-imgllu.ads: Instantiate with ghost subprograms.
* libgnat/s-imgrea.ads: Remove Pure.
* libgnat/s-imguns.ads: Instantiate with ghost subprograms.
* libgnat/s-imguti.ads: Remove Pure.
* libgnat/s-valueu.adb (Prove_Iter_Scan_Based_Number_Ghost,
Prove_Scan_Only_Decimal_Ghost): New lemmas.
* libgnat/s-valueu.ads (Uns_Option): Do not make type ghost to
be able to use it as formal in instantiations.
(Only_Decimal_Ghost): New ghost query.
(Prove_Iter_Scan_Based_Number_Ghost,
Prove_Scan_Only_Decimal_Ghost): New lemmas.
* libgnat/s-widlllu.ads: Adapt to changes in Width_U.
* libgnat/s-widllu.ads: Adapt to changes in Width_U.
* libgnat/s-widthu.adb: Change generic function in generic
package in order to complete the postcondition. Tighten the
upper bound on the result by 1.
* libgnat/s-widthu.ads: Same.
* libgnat/s-widuns.ads: Adapt to changes in Width_U.
* gcc-interface/Make-lang.in: Add dependencies on a-nubinu,
a-numeri.ads and a-widuns.ads.

patch.diff.gz
Description: application/gzip


[Ada] Sort Detect_Blocking alphabetically among names and pragmas

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
In GNAT User's Guide section about configuration pragmas the
Detect_Blocking has been recently moved to an alphabetic order.  This
patch moves the its Name_Id and Pragma_Is in the source code to match
this order.

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

gcc/ada/

* snames.ads-tmpl (Detect_Blocking): Move after
Default_Storage_Pool.diff --git a/gcc/ada/snames.ads-tmpl b/gcc/ada/snames.ads-tmpl
--- a/gcc/ada/snames.ads-tmpl
+++ b/gcc/ada/snames.ads-tmpl
@@ -417,7 +417,6 @@ package Snames is
Name_Component_Alignment: constant Name_Id := N + $; -- GNAT
Name_Convention_Identifier  : constant Name_Id := N + $; -- GNAT
Name_Debug_Policy   : constant Name_Id := N + $; -- GNAT
-   Name_Detect_Blocking: constant Name_Id := N + $; -- Ada 05
 
--  Note: Default_Scalar_Storage_Order is not in this list because its name
--  matches the name of the corresponding attribute. However, it is included
@@ -425,6 +424,7 @@ package Snames is
--  and Is_Pragma_Name correctly recognize Default_Scalar_Storage_Order.
 
Name_Default_Storage_Pool   : constant Name_Id := N + $; -- Ada 12
+   Name_Detect_Blocking: constant Name_Id := N + $; -- Ada 05
Name_Disable_Atomic_Synchronization : constant Name_Id := N + $; -- GNAT
Name_Discard_Names  : constant Name_Id := N + $;
Name_Elaboration_Checks : constant Name_Id := N + $; -- GNAT
@@ -1741,8 +1741,8 @@ package Snames is
   Pragma_Component_Alignment,
   Pragma_Convention_Identifier,
   Pragma_Debug_Policy,
-  Pragma_Detect_Blocking,
   Pragma_Default_Storage_Pool,
+  Pragma_Detect_Blocking,
   Pragma_Disable_Atomic_Synchronization,
   Pragma_Discard_Names,
   Pragma_Elaboration_Checks,




[Ada] Fix unbalanced paren in documentation marker for GNAT Studio

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Unbalanced parens can be found when editing in emacs using the
"check-parens" command. Offending occurrences must be examined manually,
because few of them are intentional.

Minor cleanup of typos in documentation.

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

gcc/ada/

* doc/gnat_rm/implementation_defined_pragmas.rst,
doc/gnat_rm/implementation_of_specific_ada_features.rst,
doc/gnat_rm/representation_clauses_and_pragmas.rst,
doc/gnat_rm/the_gnat_library.rst,
doc/gnat_rm/the_implementation_of_standard_i_o.rst,
doc/gnat_ugn/building_executable_programs_with_gnat.rst,
doc/gnat_ugn/gnat_and_program_execution.rst,
doc/gnat_ugn/platform_specific_information.rst: Fix unbalanced
parentheses and brackets.
* sem_prag.adb (pragma Obsolescent): Likewise.
* gnat_rm.texi, gnat_ugn.texi: Regenerate.diff --git a/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst b/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
--- a/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
+++ b/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
@@ -508,7 +508,7 @@ applies to both the ``Precondition`` pragma
 and the aspect ``Precondition``. Note that the identifiers for
 pragmas Pre_Class and Post_Class are Pre'Class and Post'Class (not
 Pre_Class and Post_Class), since these pragmas are intended to be
-identical to the corresponding aspects).
+identical to the corresponding aspects.
 
 If the policy is ``CHECK``, then assertions are enabled, i.e.
 the corresponding pragma or aspect is activated.
@@ -1177,7 +1177,7 @@ Syntax:
 
 .. code-block:: ada
 
-  pragma Contract_Cases ((CONTRACT_CASE {, CONTRACT_CASE));
+  pragma Contract_Cases (CONTRACT_CASE {, CONTRACT_CASE});
 
   CONTRACT_CASE ::= CASE_GUARD => CONSEQUENCE
 
@@ -3261,7 +3261,7 @@ with some extended implementations of this pragma in certain Ada 83
 implementations.  The only difference between pragma ``Interface``
 and pragma ``Import`` is that there is special circuitry to allow
 both pragmas to appear for the same subprogram entity (normally it
-is illegal to have multiple ``Import`` pragmas. This is useful in
+is illegal to have multiple ``Import`` pragmas). This is useful in
 maintaining Ada 83/Ada 95 compatibility and is compatible with other
 Ada 83 compilers.
 
@@ -4275,12 +4275,12 @@ Syntax:
 
   pragma Obsolescent (
 [Message =>] static_string_EXPRESSION
-  [,[Version =>] Ada_05]]);
+  [,[Version =>] Ada_05]);
 
   pragma Obsolescent (
 [Entity  =>] NAME
   [,[Message =>] static_string_EXPRESSION
-  [,[Version =>] Ada_05]] );
+  [,[Version =>] Ada_05]]);
 
 
 This pragma can occur immediately following a declaration of an entity,
@@ -6134,7 +6134,7 @@ Syntax:
 Use this to override the normal naming convention.  It is a configuration
 pragma, and so has the usual applicability of configuration pragmas
 (i.e., it applies to either an entire partition, or to all units in a
-compilation, or to a single unit, depending on how it is used.
+compilation, or to a single unit, depending on how it is used).
 ``unit_name`` is mapped to ``file_name_literal``.  The identifier for
 the second argument is required, and indicates whether this is the file
 name for the spec or for the body.
@@ -7176,7 +7176,7 @@ for this purpose, see :ref:`Pragma_Obsolescent`.
 The second form of pragma ``Unreferenced`` is used within a context
 clause. In this case the arguments must be unit names of units previously
 mentioned in ``with`` clauses (similar to the usage of pragma
-``Elaborate_All``. The effect is to suppress warnings about unreferenced
+``Elaborate_All``). The effect is to suppress warnings about unreferenced
 units and unreferenced entities within these units.
 
 For the variable case, warnings are never given for unreferenced variables


diff --git a/gcc/ada/doc/gnat_rm/implementation_of_specific_ada_features.rst b/gcc/ada/doc/gnat_rm/implementation_of_specific_ada_features.rst
--- a/gcc/ada/doc/gnat_rm/implementation_of_specific_ada_features.rst
+++ b/gcc/ada/doc/gnat_rm/implementation_of_specific_ada_features.rst
@@ -402,7 +402,7 @@ routines, since these are architecture independent.
 If active synchronization is required for access to the variables in the
 shared passive package, then as described in the Ada Reference Manual, the
 package may contain protected objects used for this purpose. In this case
-a lock file (whose name is :file:`___lock` (three underscores)
+a lock file (whose name is :file:`___lock`, with three underscores)
 is created in the shared memory directory.
 
 .. index:: ___lock file (for shared passive packages)


diff --git a/gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst b/gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst
--- a/gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst
+++ b/gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst
@@ -525,7 +525,7 @@ The default rules for the value of ``Value_Size`` are 

[Ada] Fix Compile_Time_(Error|Warning) as non-configuration pragmas

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Uses of Compile_Time_Error and Compile_Time_Warning as configuration
pragmas were detected with a custom check in semantic analysis. Now they
are detected with an existing general check in parser.

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

gcc/ada/

* sem_prag.adb (Analyze_Pragma): Remove custom check for
Compile_Time_Error and Compile_Time_Warning pragmas.
* snames.ads-tmpl (Compile_Time_Error, Compile_Time_Warning):
Move beyond Last_Configuration_Pragma_Name.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -14322,15 +14322,6 @@ package body Sem_Prag is
  when Pragma_Compile_Time_Error | Pragma_Compile_Time_Warning =>
 GNAT_Pragma;
 
---  These pragmas rely on the context. In adc files they raise
---  Constraint_Error. Ban them from use as configuration pragmas
---  even in cases where such a use could work.
-
-if Is_Configuration_Pragma then
-   Error_Pragma
-  ("pragma% is not allowed as a configuration pragma");
-end if;
-
 Process_Compile_Time_Warning_Or_Error;
 
  -


diff --git a/gcc/ada/snames.ads-tmpl b/gcc/ada/snames.ads-tmpl
--- a/gcc/ada/snames.ads-tmpl
+++ b/gcc/ada/snames.ads-tmpl
@@ -414,8 +414,6 @@ package Snames is
Name_Check_Float_Overflow   : constant Name_Id := N + $; -- GNAT
Name_Check_Name : constant Name_Id := N + $; -- GNAT
Name_Check_Policy   : constant Name_Id := N + $; -- GNAT
-   Name_Compile_Time_Error : constant Name_Id := N + $; -- GNAT
-   Name_Compile_Time_Warning   : constant Name_Id := N + $; -- GNAT
Name_Component_Alignment: constant Name_Id := N + $; -- GNAT
Name_Convention_Identifier  : constant Name_Id := N + $; -- GNAT
Name_Debug_Policy   : constant Name_Id := N + $; -- GNAT
@@ -508,6 +506,8 @@ package Snames is
Name_Check  : constant Name_Id := N + $; -- GNAT
Name_Comment: constant Name_Id := N + $; -- GNAT
Name_Common_Object  : constant Name_Id := N + $; -- GNAT
+   Name_Compile_Time_Error : constant Name_Id := N + $; -- GNAT
+   Name_Compile_Time_Warning   : constant Name_Id := N + $; -- GNAT
Name_Complete_Representation: constant Name_Id := N + $; -- GNAT
Name_Complex_Representation : constant Name_Id := N + $; -- GNAT
Name_Constant_After_Elaboration : constant Name_Id := N + $; -- GNAT
@@ -1738,8 +1738,6 @@ package Snames is
   Pragma_Check_Float_Overflow,
   Pragma_Check_Name,
   Pragma_Check_Policy,
-  Pragma_Compile_Time_Error,
-  Pragma_Compile_Time_Warning,
   Pragma_Component_Alignment,
   Pragma_Convention_Identifier,
   Pragma_Debug_Policy,
@@ -1819,6 +1817,8 @@ package Snames is
   Pragma_Check,
   Pragma_Comment,
   Pragma_Common_Object,
+  Pragma_Compile_Time_Error,
+  Pragma_Compile_Time_Warning,
   Pragma_Complete_Representation,
   Pragma_Complex_Representation,
   Pragma_Constant_After_Elaboration,




[Ada] Correctly reject record aggregate using brackets

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Ada 2022 bracket syntax is only allowed for arrays and containers, not
records. This change correctly rejects record aggregates using brackets
along with few cases of brackets being used instead of parentheses.

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

gcc/ada/

* libgnat/a-direct.adb (Start_Search_Internal): Use parentheses
for record aggregate.
* libgnat/a-stbubo.adb (Get_UTF_8): Likewise.
* libgnat/a-stbuun.adb (Get_UTF_8): Likewise.
* libgnat/a-stzbou.ads (Null_Bounded_Wide_Wide_String):
Likewise.
* libgnat/a-swmwco.ads (Lower_Case_Mapping, Basic_Mapping):
Likewise.
* libgnat/a-szmzco.ads (Lower_Case_Mapping, Basic_Mapping):
Likewise.
* libgnat/s-statxd.adb (Fields): Likewise.
* libgnat/s-stausa.adb (Initialize): Likewise.
* sem_aggr.adb (Resolve_Record_Aggregate): Reject aggregates
using brackets.diff --git a/gcc/ada/libgnat/a-direct.adb b/gcc/ada/libgnat/a-direct.adb
--- a/gcc/ada/libgnat/a-direct.adb
+++ b/gcc/ada/libgnat/a-direct.adb
@@ -1404,11 +1404,11 @@ package body Ada.Directories is
   if Error /= 0 then
  Search.State.Dir_Contents.Append
(Directory_Entry_Type'
-  [Valid   => True,
+  (Valid   => True,
Name=> To_Unbounded_String (File_Name),
Full_Name   => To_Unbounded_String (Path),
Attr_Error_Code => Error,
-   others  => <>]);
+   others  => <>));
 
   --  Otherwise, if the file exists and matches the file kind
   --  Filter, add the file to the search results. We capture
@@ -1445,14 +1445,14 @@ package body Ada.Directories is
  if Found then
 Search.State.Dir_Contents.Append
   (Directory_Entry_Type'
- [Valid => True,
+ (Valid => True,
   Name  =>
 To_Unbounded_String (File_Name),
   Full_Name => To_Unbounded_String (Path),
   Attr_Error_Code   => 0,
   Kind  => Kind,
   Modification_Time => Modification_Time (Path),
-  Size  => Size]);
+  Size  => Size));
  end if;
   end if;
end;


diff --git a/gcc/ada/libgnat/a-stbubo.adb b/gcc/ada/libgnat/a-stbubo.adb
--- a/gcc/ada/libgnat/a-stbubo.adb
+++ b/gcc/ada/libgnat/a-stbubo.adb
@@ -91,9 +91,9 @@ package body Ada.Strings.Text_Buffers.Bounded is
 --  forget to add corresponding assignment statement below.
 Dummy : array (1 .. 0) of Buffer_Type (0) :=
   [others =>
- [Max_Characters => 0, Chars => <>, Indentation => <>,
+ (Max_Characters => 0, Chars => <>, Indentation => <>,
   Indent_Pending => <>, UTF_8_Length => <>, UTF_8_Column => <>,
-  All_7_Bits => <>, All_8_Bits => <>, Truncated => <>]];
+  All_7_Bits => <>, All_8_Bits => <>, Truncated => <>)];
  begin
 Buffer.Indentation:= Defaulted.Indentation;
 Buffer.Indent_Pending := Defaulted.Indent_Pending;


diff --git a/gcc/ada/libgnat/a-stbuun.adb b/gcc/ada/libgnat/a-stbuun.adb
--- a/gcc/ada/libgnat/a-stbuun.adb
+++ b/gcc/ada/libgnat/a-stbuun.adb
@@ -104,9 +104,9 @@ package body Ada.Strings.Text_Buffers.Unbounded is
 --  forget to add corresponding assignment statement below.
 Dummy : array (1 .. 0) of Buffer_Type :=
   [others =>
- [Indentation  => <>, Indent_Pending => <>, UTF_8_Length => <>,
+ (Indentation  => <>, Indent_Pending => <>, UTF_8_Length => <>,
   UTF_8_Column => <>, All_7_Bits => <>, All_8_Bits => <>,
-  List => <>, Last_Used => <>]];
+  List => <>, Last_Used => <>)];
  begin
 Buffer.Indentation:= Defaulted.Indentation;
 Buffer.Indent_Pending := Defaulted.Indent_Pending;


diff --git a/gcc/ada/libgnat/a-stzbou.ads b/gcc/ada/libgnat/a-stzbou.ads
--- a/gcc/ada/libgnat/a-stzbou.ads
+++ b/gcc/ada/libgnat/a-stzbou.ads
@@ -493,11 +493,11 @@ package Ada.Strings.Wide_Wide_Bounded is
   --  the Wide_Wide_Superbounded package.
 
   Null_Bounded_Wide_Wide_String : constant Bounded_Wide_Wide_String :=
-   [Max_Length => Max_Length,
+   (Max_Length => Max_Length,
 

[Ada] New No_Local_Tagged_Types restriction

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Add new configuration restriction No_Local_Tagged_Types. This new
restriction ensures at compile time that all tagged types are only
declared at the library level.

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

gcc/ada/

* libgnat/s-rident.ads (Restriction_Id): Add
No_Local_Tagged_Types, update comment for adding new GNAT
specific restriction.
* restrict.ads (Implementation_Restriction): Add
No_Local_Tagged_Types.
* sem_ch3.adb (Analyze_Full_Type_Declaration): Add check for
tagged type at library level.
* doc/gnat_rm/standard_and_implementation_defined_restrictions.rst:
Add No_Local_Tagged_Types description.
* gnat_rm.texi: Regenerate.

patch.diff.gz
Description: application/gzip


[Ada] Fix spurious ambiguity for if_expression containing operator

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
It comes from a discrepancy in the analysis of binary operators, between
the predefined ones for which we register an interpretation with the base
type and the user-defined ones for which we register an interpretation
with the subtype directly.

This is harmless in almost all cases because the two interpretations do not
differ by this type property only, but is problematic when the operation is
the dependent expression of a conditional expression, because it causes two
interpretations of the conditional expression to be registered, which this
time differ by this type property only, thus making them impossible to be
disambiguated later.

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

gcc/ada/

* sem_ch4.adb (Analyze_User_Defined_Binary_Op): Use the base type
in the interpretation of the operator.diff --git a/gcc/ada/sem_ch4.adb b/gcc/ada/sem_ch4.adb
--- a/gcc/ada/sem_ch4.adb
+++ b/gcc/ada/sem_ch4.adb
@@ -5934,7 +5934,7 @@ package body Sem_Ch4 is
and then (Has_Compatible_Type (Right_Opnd (N), Etype (F2))
   or else Etype (F2) = Any_Type)
  then
-Add_One_Interp (N, Op_Id, Etype (Op_Id));
+Add_One_Interp (N, Op_Id, Base_Type (Etype (Op_Id)));
 
 --  If the operands are overloaded, indicate that the current
 --  type is a viable candidate. This is redundant in most cases,




[Ada] Do not create useless itype in Constrain_Access

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
In the case of a constrained access definition for a record component we
are calling create_itype twice the former not being updated.  This leads
to a malformed node that crashes -gnatG when predicates are activated.
Instead of creating a default Itype for Desig_Subtype, create it with
the correct scope in each case.

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

gcc/ada/

* sem_ch3.adb (Constrain_Access): Call Desig_Subtype in each if
branch to avoid calling it twice.diff --git a/gcc/ada/sem_ch3.adb b/gcc/ada/sem_ch3.adb
--- a/gcc/ada/sem_ch3.adb
+++ b/gcc/ada/sem_ch3.adb
@@ -13345,11 +13345,12 @@ package body Sem_Ch3 is
is
   T : constant Entity_Id := Entity (Subtype_Mark (S));
   Desig_Type: constant Entity_Id := Designated_Type (T);
-  Desig_Subtype : Entity_Id := Create_Itype (E_Void, Related_Nod);
+  Desig_Subtype : Entity_Id;
   Constraint_OK : Boolean := True;
 
begin
   if Is_Array_Type (Desig_Type) then
+ Desig_Subtype := Create_Itype (E_Void, Related_Nod);
  Constrain_Array (Desig_Subtype, S, Related_Nod, Def_Id, 'P');
 
   elsif (Is_Record_Type (Desig_Type)
@@ -13445,12 +13446,14 @@ package body Sem_Ch3 is
 end;
  end if;
 
+ Desig_Subtype := Create_Itype (E_Void, Related_Nod);
  Constrain_Discriminated_Type (Desig_Subtype, S, Related_Nod,
For_Access => True);
 
   elsif Is_Concurrent_Type (Desig_Type)
 and then not Is_Constrained (Desig_Type)
   then
+ Desig_Subtype := Create_Itype (E_Void, Related_Nod);
  Constrain_Concurrent (Desig_Subtype, S, Related_Nod, Desig_Type, ' ');
 
   else




[Ada] Detect infinite loops with operators in exit conditions

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
To warn about infinite loops we detect variables referenced in loop exit
conditions. We handle references within boolean operators, i.e.
comparison and negation, which are likely to appear at the top level of
the condition (e.g. "X > 0"). However, we can easily handle all
operators, because they are likely to appear inside the condition (e.g.
"abs (X) > 0.0").

Cleanup related to a new restriction No_Uninitialized_Local_Scalars.

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

gcc/ada/

* sem_warn.adb (Find_Var): Detect all operators; replace
"condition" to "expression" in comments, because when this
routine is called recursively it no longer examines the
condition.
(Is_Suspicious_Function_Name): Reduce scope of a local variable
to avoid shadowing with a parameter of a nested
Substring_Present function.diff --git a/gcc/ada/sem_warn.adb b/gcc/ada/sem_warn.adb
--- a/gcc/ada/sem_warn.adb
+++ b/gcc/ada/sem_warn.adb
@@ -284,15 +284,15 @@ package body Sem_Warn is
 
   procedure Find_Var (N : Node_Id) is
   begin
- --  Condition is a direct variable reference
+ --  Expression is a direct variable reference
 
  if Is_Entity_Name (N) then
 Ref := N;
 Var := Entity (Ref);
 
- --  Case of condition is a comparison with compile time known value
+ --  If expression is an operator, check its operands
 
- elsif Nkind (N) in N_Op_Compare then
+ elsif Nkind (N) in N_Binary_Op then
 if Compile_Time_Known_Value (Right_Opnd (N)) then
Find_Var (Left_Opnd (N));
 
@@ -305,9 +305,9 @@ package body Sem_Warn is
return;
 end if;
 
- --  If condition is a negation, check its operand
+ --  If expression is a unary operator, check its operand
 
- elsif Nkind (N) = N_Op_Not then
+ elsif Nkind (N) in N_Unary_Op then
 Find_Var (Right_Opnd (N));
 
  --  Case of condition is function call
@@ -445,8 +445,6 @@ package body Sem_Warn is
   -
 
   function Is_Suspicious_Function_Name (E : Entity_Id) return Boolean is
- S : Entity_Id;
-
  function Substring_Present (S : String) return Boolean;
  --  Returns True if name buffer has given string delimited by non-
  --  alphabetic characters or by end of string. S is lower case.
@@ -473,6 +471,10 @@ package body Sem_Warn is
 return False;
  end Substring_Present;
 
+ --  Local variables
+
+ S : Entity_Id;
+
   --  Start of processing for Is_Suspicious_Function_Name
 
   begin




[Ada] Adapt proof of System.Arith_Double after update of Z3

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Update to version 4.8.14 of prover Z3 requires minor adjustments of the
ghost code to add necessary intermediate assertions that drive the
automatic proof.

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

gcc/ada/

* libgnat/s-aridou.adb (Double_Divide, Scaled_Divide): Add
intermediate assertions.diff --git a/gcc/ada/libgnat/s-aridou.adb b/gcc/ada/libgnat/s-aridou.adb
--- a/gcc/ada/libgnat/s-aridou.adb
+++ b/gcc/ada/libgnat/s-aridou.adb
@@ -924,6 +924,8 @@ is
 else
Q := 0;
 
+   pragma Assert (Double_Uns'(Yhi * Zhi) >= Double_Uns (Yhi));
+   pragma Assert (Double_Uns'(Yhi * Zhi) >= Double_Uns (Zhi));
pragma Assert (Big (Double_Uns'(Yhi * Zhi)) >= 1);
if Yhi > 1 or else Zhi > 1 then
   pragma Assert (Big (Double_Uns'(Yhi * Zhi)) > 1);
@@ -938,10 +940,12 @@ is
 return;
  else
 T2 := Yhi * Zlo;
+pragma Assert (Big (T2) = Big (Double_Uns'(Yhi * Zlo)));
  end if;
 
   else
  T2 := Ylo * Zhi;
+ pragma Assert (Big (T2) = Big (Double_Uns'(Ylo * Zhi)));
   end if;
 
   T1 := Ylo * Zlo;
@@ -1527,10 +1531,14 @@ is
 Raise_Error;
  else
 T2 := Xhi * Ylo;
+pragma Assert (Big (T2) = Big (Double_Uns'(Xhi * Ylo))
++ Big (Double_Uns'(Xlo * Yhi)));
  end if;
 
   elsif Yhi /= 0 then
  T2 := Xlo * Yhi;
+ pragma Assert (Big (T2) = Big (Double_Uns'(Xhi * Ylo))
+ + Big (Double_Uns'(Xlo * Yhi)));
 
   else -- Yhi = Xhi = 0
  T2 := 0;
@@ -1544,7 +1552,7 @@ is
   pragma Assert (Big (T2) = Big (Double_Uns'(Xhi * Ylo))
   + Big (Double_Uns'(Xlo * Yhi)));
   Lemma_Mult_Distribution (Big_2xxSingle, Big (Double_Uns'(Xhi * Ylo)),
-  Big (Double_Uns'(Xlo * Yhi)));
+  Big (Double_Uns'(Xlo * Yhi)));
   pragma Assert (Mult = Big_2xxSingle * Big (T2) + Big (T1));
   Lemma_Add_Commutation (T2, Hi (T1));
   pragma Assert
@@ -2575,7 +2583,13 @@ is
   Big (Double_Uns (Qd (J))) - 1,
   Big (Double_Uns (Qd (J) - 1)), 0);
 
-  Qd (J) := Qd (J) - 1;
+  declare
+ Prev : constant Single_Uns := Qd (J) - 1 with Ghost;
+  begin
+ Qd (J) := Qd (J) - 1;
+
+ pragma Assert (Qd (J) = Prev);
+  end;
 
   pragma Assert
 (Big3 (S1, S2, S3) = Big (Double_Uns (Qd (J))) * Big (Zu));




[Ada] Update categorization of implementation restrictions

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Some of the restrictions were initially implemented as specific to GNAT,
but now they are part of Ada; likewise, some of recently added
restrictions were considered to be part of Ada, but are not yet in the
standard. This patch updates their categorization based on Ada 202x
Draft 32.

Only a No_Implementation_Restrictions restriction, which is specific to
GNAT, is affected.

Cleanup related to a new restriction No_Uninitialized_Local_Scalars.

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

gcc/ada/

* libgnat/s-rident.ads (Implementation_Restriction): Remove
No_Dynamic_Attachment, No_Implementation_Attributes,
No_Implementation_Pragmas, No_Local_Protected_Objects,
No_Protected_Type_Allocators, No_Relative_Delay,
No_Requeue_Statements, No_Select_Statements,
No_Task_Termination, Pure_Barriers and Simple_Barriers; add
No_Dynamic_Sized_Objects,
No_Implicit_Protected_Object_Allocations,
No_Implicit_Task_Allocations, No_Task_At_Interrupt_Priority and
Static_Dispatch_Tables; sort alphabetically.
* restrict.ads (Restriction_Id): Change Pure_Barriers and
No_Task_Termination from GNAT to Ada restrictions.diff --git a/gcc/ada/libgnat/s-rident.ads b/gcc/ada/libgnat/s-rident.ads
--- a/gcc/ada/libgnat/s-rident.ads
+++ b/gcc/ada/libgnat/s-rident.ads
@@ -90,7 +90,7 @@ package System.Rident is
   --  does not violate the restriction.
 
  (Simple_Barriers,   -- Ada 2012 (D.7 (10.9/3))
-  Pure_Barriers, -- GNAT
+  Pure_Barriers, -- Ada 2022 (D.7(10.11/5))
   No_Abort_Statements,   -- (RM D.7(5), H.4(3))
   No_Access_Parameter_Allocators,-- Ada 2012 (RM H.4 (8.3/3))
   No_Access_Subprograms, -- (RM H.4(17))
@@ -150,7 +150,7 @@ package System.Rident is
   No_Task_Attributes_Package,-- GNAT
   No_Task_At_Interrupt_Priority, -- GNAT
   No_Task_Hierarchy, -- (RM D.7(3), H.4(3))
-  No_Task_Termination,   -- GNAT (Ravenscar)
+  No_Task_Termination,   -- Ada 2005 (D.7(15.1/2))
   No_Tasks_Unassigned_To_CPU,-- Ada 202x (D.7(10.10/4))
   No_Tasking,-- GNAT
   No_Terminate_Alternatives, -- (RM D.7(6))


diff --git a/gcc/ada/restrict.ads b/gcc/ada/restrict.ads
--- a/gcc/ada/restrict.ads
+++ b/gcc/ada/restrict.ads
@@ -109,50 +109,44 @@ package Restrict is
--  is why this restriction itself is excluded from the list).
 
Implementation_Restriction : constant array (All_Restrictions) of Boolean :=
- (Simple_Barriers=> True,
-  No_Calendar=> True,
-  No_Default_Initialization  => True,
-  No_Direct_Boolean_Operators=> True,
-  No_Dispatching_Calls   => True,
-  No_Dynamic_Accessibility_Checks=> True,
-  No_Dynamic_Attachment  => True,
-  No_Elaboration_Code=> True,
-  No_Enumeration_Maps=> True,
-  No_Entry_Calls_In_Elaboration_Code => True,
-  No_Entry_Queue => True,
-  No_Exception_Handlers  => True,
-  No_Exception_Propagation   => True,
-  No_Exception_Registration  => True,
-  No_Finalization=> True,
-  No_Fixed_IO=> True,
-  No_Implementation_Attributes   => True,
-  No_Implementation_Pragmas  => True,
-  No_Implicit_Conditionals   => True,
-  No_Implicit_Aliasing   => True,
-  No_Implicit_Dynamic_Code   => True,
-  No_Implicit_Loops  => True,
-  No_Initialize_Scalars  => True,
-  No_Local_Protected_Objects => True,
-  No_Long_Long_Integers  => True,
-  No_Multiple_Elaboration=> True,
-  No_Protected_Type_Allocators   => True,
-  No_Relative_Delay  => True,
-  No_Requeue_Statements  => True,
-  No_Secondary_Stack => True,
-  No_Select_Statements   => True,
-  No_Standard_Storage_Pools  => True,
-  No_Stream_Optimizations=> True,
-  No_Streams => True,
-  No_Tagged_Type_Registration=> True,
-  No_Task_Attributes_Package => True,
-  No_Task_Termination=> True,
-  No_Tasking => True,
-  No_Wide_Characters => True,
-  Static_Priorities  => True,
-  Static_Storage_Size=> True,
-  Pure_Barriers  => True,
-  SPARK_05   => True,
-  others => 

[Ada] Add SUSE 32bit dependency

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
On SUSE 15, glibc-locale-base-32bit is needed to run 32bit versions
of Libadalang tools.

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

gcc/ada/

* doc/gnat_ugn/platform_specific_information.rst: Add
glibc-locale-base-32bit as a dependency in SUSE distributions.
* gnat_ugn.texi: Regenerate.diff --git a/gcc/ada/doc/gnat_ugn/platform_specific_information.rst b/gcc/ada/doc/gnat_ugn/platform_specific_information.rst
--- a/gcc/ada/doc/gnat_ugn/platform_specific_information.rst
+++ b/gcc/ada/doc/gnat_ugn/platform_specific_information.rst
@@ -233,7 +233,6 @@ GNU/Linux Topics
 This section describes topics that are specific to GNU/Linux platforms.
 
 .. _Required_packages_on_GNU_Linux:
-.. _A_GNU_Linux_debug_quirk:
 
 Required Packages on GNU/Linux
 --
@@ -248,11 +247,15 @@ If using the 32-bit version of GNAT on a 64-bit version of GNU/Linux,
 you'll need the 32-bit version of the following packages:
 
 * RedHat, SUSE: ``glibc.i686``, ``glibc-devel.i686``, ``ncurses-libs.i686``
+* SUSE: ``glibc-locale-base-32bit``
 * Debian, Ubuntu: ``libc6:i386``, ``libc6-dev:i386``, ``lib32ncursesw5``
 
 Other GNU/Linux distributions might be choosing a different name
 for those packages.
 
+
+.. _A_GNU_Linux_debug_quirk:
+
 A GNU/Linux Debug Quirk
 ---
 


diff --git a/gcc/ada/gnat_ugn.texi b/gcc/ada/gnat_ugn.texi
--- a/gcc/ada/gnat_ugn.texi
+++ b/gcc/ada/gnat_ugn.texi
@@ -22654,7 +22654,7 @@ have sufficient priviledge for running the container image.
 
 
 This section describes topics that are specific to GNU/Linux platforms.
-@anchor{gnat_ugn/platform_specific_information required-packages-on-gnu-linux}@anchor{1bd}
+
 @menu
 * Required Packages on GNU/Linux:: 
 * A GNU/Linux Debug Quirk:: 
@@ -22662,7 +22662,7 @@ This section describes topics that are specific to GNU/Linux platforms.
 @end menu
 
 @node Required Packages on GNU/Linux,A GNU/Linux Debug Quirk,,GNU/Linux Topics
-@anchor{gnat_ugn/platform_specific_information a-gnu-linux-debug-quirk}@anchor{1be}@anchor{gnat_ugn/platform_specific_information id7}@anchor{1bf}
+@anchor{gnat_ugn/platform_specific_information id7}@anchor{1bd}@anchor{gnat_ugn/platform_specific_information required-packages-on-gnu-linux}@anchor{1be}
 @subsection Required Packages on GNU/Linux
 
 
@@ -22688,6 +22688,9 @@ you’ll need the 32-bit version of the following packages:
 @item 
 RedHat, SUSE: @code{glibc.i686}, @code{glibc-devel.i686}, @code{ncurses-libs.i686}
 
+@item 
+SUSE: @code{glibc-locale-base-32bit}
+
 @item 
 Debian, Ubuntu: @code{libc6:i386}, @code{libc6-dev:i386}, @code{lib32ncursesw5}
 @end itemize
@@ -22696,7 +22699,7 @@ Other GNU/Linux distributions might be choosing a different name
 for those packages.
 
 @node A GNU/Linux Debug Quirk,,Required Packages on GNU/Linux,GNU/Linux Topics
-@anchor{gnat_ugn/platform_specific_information id8}@anchor{1c0}
+@anchor{gnat_ugn/platform_specific_information a-gnu-linux-debug-quirk}@anchor{1bf}@anchor{gnat_ugn/platform_specific_information id8}@anchor{1c0}
 @subsection A GNU/Linux Debug Quirk
 
 




[Ada] Fix "S p e c" and "B o d y" file headers

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Fix Spec/Body headers in .adb/.ads files, respectively; all violations
detected with grep and manually filtered because of .tmpl files.

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

gcc/ada/

* exp_atag.adb, lib-util.ads, libgnat/g-decstr.adb,
libgnat/g-exptty.adb, libgnat/g-socpol.adb,
libgnat/s-strhas.adb: Fix headers.diff --git a/gcc/ada/exp_atag.adb b/gcc/ada/exp_atag.adb
--- a/gcc/ada/exp_atag.adb
+++ b/gcc/ada/exp_atag.adb
@@ -4,7 +4,7 @@
 --  --
 -- E X P _ A T A G  --
 --  --
--- S p e c  --
+-- B o d y  --
 --  --
 --  Copyright (C) 2006-2022, Free Software Foundation, Inc. --
 --  --


diff --git a/gcc/ada/lib-util.ads b/gcc/ada/lib-util.ads
--- a/gcc/ada/lib-util.ads
+++ b/gcc/ada/lib-util.ads
@@ -4,7 +4,7 @@
 --  --
 -- L I B . U T I L  --
 --  --
--- B o d y  --
+-- S p e c  --
 --  --
 --  Copyright (C) 1992-2022, Free Software Foundation, Inc. --
 --  --


diff --git a/gcc/ada/libgnat/g-decstr.adb b/gcc/ada/libgnat/g-decstr.adb
--- a/gcc/ada/libgnat/g-decstr.adb
+++ b/gcc/ada/libgnat/g-decstr.adb
@@ -4,7 +4,7 @@
 --  --
 --G N A T . D E C O D E _ S T R I N G   --
 --  --
--- S p e c  --
+-- B o d y  --
 --  --
 -- Copyright (C) 2007-2022, AdaCore --
 --  --


diff --git a/gcc/ada/libgnat/g-exptty.adb b/gcc/ada/libgnat/g-exptty.adb
--- a/gcc/ada/libgnat/g-exptty.adb
+++ b/gcc/ada/libgnat/g-exptty.adb
@@ -4,7 +4,7 @@
 --  --
 --  G N A T . E X P E C T . T T Y   --
 --  --
--- S p e c  --
+-- B o d y  --
 --  --
 --Copyright (C) 2000-2022, AdaCore  --
 --  --


diff --git a/gcc/ada/libgnat/g-socpol.adb b/gcc/ada/libgnat/g-socpol.adb
--- a/gcc/ada/libgnat/g-socpol.adb
+++ b/gcc/ada/libgnat/g-socpol.adb
@@ -4,7 +4,7 @@
 --  --
 --G N A T . S O C K E T S . P O L L --
 --  --
--- S p e c  --
+-- B o d y  --
 --  --
 --   Copyright (C) 2020-2022, AdaCore   --
 --  --


diff --git a/gcc/ada/libgnat/s-strhas.adb b/gcc/ada/libgnat/s-strhas.adb
--- a/gcc/ada/libgnat/s-strhas.adb
+++ b/gcc/ada/libgnat/s-strhas.adb
@@ -4,7 +4,7 @@
 --  --
 --S Y S T E M . S T R I N G _ H A S H   --
 --  --
--- S p e c  --
+-- B o d y  --
 --  --
 --  Copyright (C) 2009-2022, Free Software Foundation, 

[Ada] Fix formatting glitches in GNAT User's Guide

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Only enhancement of formatting.

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

gcc/ada/

* doc/gnat_ugn/gnat_and_program_execution.rst,
doc/gnat_ugn/gnat_utility_programs.rst,
doc/gnat_ugn/inline_assembler.rst: Fix typos and formatting
glitches.
* gnat_ugn.texi: Regenerate.diff --git a/gcc/ada/doc/gnat_ugn/gnat_and_program_execution.rst b/gcc/ada/doc/gnat_ugn/gnat_and_program_execution.rst
--- a/gcc/ada/doc/gnat_ugn/gnat_and_program_execution.rst
+++ b/gcc/ada/doc/gnat_ugn/gnat_and_program_execution.rst
@@ -433,7 +433,7 @@ Ada Tasks
 
 .. index:: Breakpoints and tasks
 
-* ``break``*linespec* ``task`` *taskid*, ``break`` *linespec* ``task`` *taskid* ``if`` ...
+* ``break`` *linespec* ``task`` *taskid*, ``break`` *linespec* ``task`` *taskid* ``if`` ...
 
 These commands are like the ``break ... thread ...``.
 *linespec* specifies source lines.
@@ -1306,7 +1306,7 @@ or simply:
 
   ::
 
-$  gprof my_prog
+$ gprof my_prog
 
 The complete form of the gprof command line is the following:
 


diff --git a/gcc/ada/doc/gnat_ugn/gnat_utility_programs.rst b/gcc/ada/doc/gnat_ugn/gnat_utility_programs.rst
--- a/gcc/ada/doc/gnat_ugn/gnat_utility_programs.rst
+++ b/gcc/ada/doc/gnat_ugn/gnat_utility_programs.rst
@@ -630,13 +630,13 @@ building specialized scripts.
 
.. index:: --wide-character-encoding (gnatmetric)
 
-   :switch:`--wide-character-encoding={e}`
- Specify the wide character encoding method for the input and output
- files. ``e`` is one of the following:
+  :switch:`--wide-character-encoding={e}`
+Specify the wide character encoding method for the input and output
+files. ``e`` is one of the following:
 
- * *8* - UTF-8 encoding
+* *8* - UTF-8 encoding
 
- * *b* - Brackets encoding (default value)
+* *b* - Brackets encoding (default value)
 
 
   .. index:: Disable Metrics For Local Units in gnatmetric
@@ -1161,7 +1161,7 @@ building specialized scripts.
 Report maximal loop nesting level
 
 
-  :switch:`-no-loop-nesting`
+  :switch:`--no-loop-nesting`
 Do not report maximal loop nesting level
 
 


diff --git a/gcc/ada/doc/gnat_ugn/inline_assembler.rst b/gcc/ada/doc/gnat_ugn/inline_assembler.rst
--- a/gcc/ada/doc/gnat_ugn/inline_assembler.rst
+++ b/gcc/ada/doc/gnat_ugn/inline_assembler.rst
@@ -138,7 +138,7 @@ To see this output, invoke the compiler as follows:
 
   ::
 
- $  gcc -c -S -fomit-frame-pointer -gnatp nothing.adb
+ $ gcc -c -S -fomit-frame-pointer -gnatp nothing.adb
 
 where the options are:
 


diff --git a/gcc/ada/gnat_ugn.texi b/gcc/ada/gnat_ugn.texi
--- a/gcc/ada/gnat_ugn.texi
+++ b/gcc/ada/gnat_ugn.texi
@@ -18498,7 +18498,7 @@ to refer to tasks in the following commands.
 @itemize *
 
 @item 
-@code{break`@w{`}*linespec* `@w{`}task} @emph{taskid}, @code{break} @emph{linespec} @code{task} @emph{taskid} @code{if} …
+@code{break} @emph{linespec} @code{task} @emph{taskid}, @code{break} @emph{linespec} @code{task} @emph{taskid} @code{if} …
 
 @quotation
 
@@ -19517,7 +19517,7 @@ or simply:
 @quotation
 
 @example
-$  gprof my_prog
+$ gprof my_prog
 @end example
 @end quotation
 
@@ -28015,7 +28015,7 @@ To see this output, invoke the compiler as follows:
 @quotation
 
 @example
-$  gcc -c -S -fomit-frame-pointer -gnatp nothing.adb
+$ gcc -c -S -fomit-frame-pointer -gnatp nothing.adb
 @end example
 @end quotation
 




[Ada] Use pygments for Ada code examples of elaboration control

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Only enhancement of formatting.

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

gcc/ada/

* doc/gnat_ugn/elaboration_order_handling_in_gnat.rst: Change
blocks from plain code to Ada.diff --git a/gcc/ada/doc/gnat_ugn/elaboration_order_handling_in_gnat.rst b/gcc/ada/doc/gnat_ugn/elaboration_order_handling_in_gnat.rst
--- a/gcc/ada/doc/gnat_ugn/elaboration_order_handling_in_gnat.rst
+++ b/gcc/ada/doc/gnat_ugn/elaboration_order_handling_in_gnat.rst
@@ -93,7 +93,7 @@ Elaboration code may appear in two distinct contexts:
   [body] compilation unit, ignoring any other package [body] declarations in
   between.
 
-  ::
+  .. code-block:: ada
 
  with Server;
  package Client is
@@ -116,7 +116,7 @@ Elaboration code may appear in two distinct contexts:
   bounded by the region starting from the ``begin`` keyword of the package body
   and ending at the ``end`` keyword of the package body.
 
-  ::
+  .. code-block:: ada
 
  package body Client is
 procedure Proc is
@@ -142,7 +142,7 @@ executed is referred to as **elaboration order**.
 
 Within a single unit, elaboration code is executed in sequential order.
 
-  ::
+  .. code-block:: ada
 
  package body Client is
 Result : ... := Server.Func;
@@ -190,13 +190,13 @@ factors:
 
 A program may have several elaboration orders depending on its structure.
 
-  ::
+  .. code-block:: ada
 
  package Server is
 function Func (Index : Integer) return Integer;
  end Server;
 
-  ::
+  .. code-block:: ada
 
  package body Server is
 Results : array (1 .. 5) of Integer := (1, 2, 3, 4, 5);
@@ -207,14 +207,14 @@ A program may have several elaboration orders depending on its structure.
 end Func;
  end Server;
 
-  ::
+  .. code-block:: ada
 
  with Server;
  package Client is
 Val : constant Integer := Server.Func (3);
  end Client;
 
-  ::
+  .. code-block:: ada
 
  with Client;
  procedure Main is begin null; end Main;
@@ -320,7 +320,7 @@ the desired elaboration order and avoiding ABE problems altogether.
   A library package which does not require a completing body does not suffer
   from ABE problems.
 
-  ::
+  .. code-block:: ada
 
  package Pack is
 generic
@@ -358,7 +358,7 @@ the desired elaboration order and avoiding ABE problems altogether.
   scenario can invoke a server target before the target body has been
   elaborated because the spec and body are effectively "glued" together.
 
-  ::
+  .. code-block:: ada
 
  package Server is
 pragma Elaborate_Body;
@@ -366,7 +366,7 @@ the desired elaboration order and avoiding ABE problems altogether.
 function Func return Integer;
  end Server;
 
-  ::
+  .. code-block:: ada
 
  package body Server is
 function Func return Integer is
@@ -375,7 +375,7 @@ the desired elaboration order and avoiding ABE problems altogether.
 end Func;
  end Server;
 
-  ::
+  .. code-block:: ada
 
  with Server;
  package Client is
@@ -425,13 +425,13 @@ depend on.
   be elaborated prior to the unit with the pragma. Note that other unrelated
   units may be elaborated in between the spec and the body.
 
-  ::
+  .. code-block:: ada
 
  package Server is
 function Func return Integer;
  end Server;
 
-  ::
+  .. code-block:: ada
 
  package body Server is
 function Func return Integer is
@@ -440,7 +440,7 @@ depend on.
 end Func;
  end Server;
 
-  ::
+  .. code-block:: ada
 
  with Server;
  pragma Elaborate (Server);
@@ -479,13 +479,13 @@ depend on.
   |withed| by the spec and body of the argument, recursively. Note that other
   unrelated units may be elaborated in between the spec and the body.
 
-  ::
+  .. code-block:: ada
 
  package Math is
 function Factorial (Val : Natural) return Natural;
  end Math;
 
-  ::
+  .. code-block:: ada
 
  package body Math is
 function Factorial (Val : Natural) return Natural is
@@ -494,7 +494,7 @@ depend on.
 end Factorial;
  end Math;
 
-  ::
+  .. code-block:: ada
 
  package Computer is
 type Operation_Kind is (None, Op_Factorial);
@@ -504,7 +504,7 @@ depend on.
Op  : Operation_Kind) return Natural;
  end Computer;
 
-  ::
+  .. code-block:: ada
 
  with Math;
  package body Computer is
@@ -520,7 +520,7 @@ depend on.
 end Compute;
  end Computer;
 
-  ::
+  .. code-block:: ada
 
  with Computer;
  pragma Elaborate_All (Computer);
@@ -738,7 +738,7 @@ execution. The warnings can be suppressed selectively with ``pragma Warnings
 A *guaranteed ABE* arises when the body of a target is not elaborated early
 enough, and causes *all* scenarios that directly invoke the target to fail.
 
-  ::
+  .. code-block:: ada
 
  package body Guaranteed_ABE is
 function ABE return Integer;
@@ -765,7 +765,7 @@ the declaration of ``Val``. This invokes function ``ABE``, however the body of
 

[Ada] Excess finalization on assignment with target name symbol

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
In cases where the Ada 2022 feature of target name symbols (@) is used
and the evaluation of the name is side-effect free, the compiler creates
a temporary object to hold the value of the target object for use as
the value of "@" symbols in the right-hand side expression. In the case
where the target's type is controlled, or has controlled subcomponents,
this can result in extra finalization calls (for the temporary object).
The correction is to bypass the use of a temp and fall back on the more
general approach of creating and calling a procedure with an in-out
parameter for performing the assignment.

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

gcc/ada/

* exp_ch5.adb (Expand_Assign_With_Target_Names): Bypass the temp
object approach in the case where the type of the LHS is
controlled or has controlled subcomponents (Needs_Finalization
is True), and use the procedure approach instead.diff --git a/gcc/ada/exp_ch5.adb b/gcc/ada/exp_ch5.adb
--- a/gcc/ada/exp_ch5.adb
+++ b/gcc/ada/exp_ch5.adb
@@ -2246,9 +2246,15 @@ package body Exp_Ch5 is
  Expression => New_RHS));
 
   --  The left-hand side is not a direct name, but is side-effect free.
-  --  Capture its value in a temporary to avoid multiple evaluations.
-
-  elsif Side_Effect_Free (LHS) then
+  --  Capture its value in a temporary to avoid generating a procedure.
+  --  We don't do this optimization if the target object's type may need
+  --  finalization actions, because we don't want extra finalizations to
+  --  be done for the temp object, and instead we use the more general
+  --  procedure-based approach below.
+
+  elsif Side_Effect_Free (LHS)
+and then not Needs_Finalization (Etype (LHS))
+  then
  Ent := Make_Temporary (Loc, 'T');
  Replace_Target_Name (New_RHS);
 




[Ada] fix crash on Secondary_Stack_Size with discriminant

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
This patch fixes a crash caused by specifying the Secondary_Stack_Size
aspect of a task type as the value of a discriminant of the task type,
and then declaring a record component whose type is the task type,
constrained to a discriminant of the record.

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

gcc/ada/

* sem_ch3.adb (Get_Discr_Value): Copy the result. Otherwise, the
"tree" can be malformed (a DAG, not a tree) because
Get_Discr_Value could be returning some subtree already attached
to the tree.diff --git a/gcc/ada/sem_ch3.adb b/gcc/ada/sem_ch3.adb
--- a/gcc/ada/sem_ch3.adb
+++ b/gcc/ada/sem_ch3.adb
@@ -13963,7 +13963,7 @@ package body Sem_Ch3 is
   or else D = CR_Discriminant (Discr_Id)
   or else Corresponding_Discriminant (D) = Discr_Id
 then
-   return Node (E);
+   return New_Copy_Tree (Node (E));
 end if;
 
 Next_Discriminant (D);
@@ -13987,7 +13987,7 @@ package body Sem_Ch3 is
 E := First_Elmt (Constraints);
 while Present (D) loop
if D = Discr_Id then
-  return Node (E);
+  return New_Copy_Tree (Node (E));
end if;
 
Next_Discriminant (D);




[Ada] Reset Reachable field when mutating label into loop entity

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
An entity flag Reachable now only applies to E_Label entities and needs
to be explicitly reset when mutating labels into loop entities. Only
needed to prevent cascaded errors when compiling a malicious ACATS test
with -gnatq (try semantics, even if parse errors).

Cleanup related to detection of uninitialized scalars with GOTO
statements.

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

gcc/ada/

* sem_ch5.adb (Analyze_Statements): Only clear Reachable flag on
proper label entities.diff --git a/gcc/ada/sem_ch5.adb b/gcc/ada/sem_ch5.adb
--- a/gcc/ada/sem_ch5.adb
+++ b/gcc/ada/sem_ch5.adb
@@ -4012,6 +4012,7 @@ package body Sem_Ch5 is
 
 if Ekind (Ent) = E_Label then
Reinit_Field_To_Zero (Ent, F_Enclosing_Scope);
+   Reinit_Field_To_Zero (Ent, F_Reachable);
Mutate_Ekind (Ent, E_Loop);
 
if Nkind (Parent (Ent)) = N_Implicit_Label_Declaration then




[Ada] Fix layout of tables in PDF version of GNAT RM

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Tables with small left columns and large right columns had colliding
text in the PDF version of GNAT RM.

Spotted while adding description of pragma Ada_2022.

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

gcc/ada/

* doc/gnat_rm/implementation_defined_characteristics.rst: Add
tabularcolums directive, as explained in documentation of Sphinx
and tabular LaTeX package.diff --git a/gcc/ada/doc/gnat_rm/implementation_defined_characteristics.rst b/gcc/ada/doc/gnat_rm/implementation_defined_characteristics.rst
--- a/gcc/ada/doc/gnat_rm/implementation_defined_characteristics.rst
+++ b/gcc/ada/doc/gnat_rm/implementation_defined_characteristics.rst
@@ -100,6 +100,8 @@ The Static_Predicate case is handled analogously.
   "The predefined integer types declared in
   ``Standard``.  See 3.5.4(25)."
 
+.. tabularcolumns:: |l|L|
+
 = ===
 Type   Representation
 = ===
@@ -837,6 +839,8 @@ Containers.Count_Type'Last is 2**31 - 1.
 
 The following convention names are supported
 
+.. tabularcolumns:: |l|L|
+
 === ==
 Convention Name Interpretation
 === ==




[Ada] Fix layout in description of aspects and pragmas

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Remove extra whitespace in examples of pragmas and aspects.

Spotted while adding description of pragma Ada_2022.

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

gcc/ada/

* doc/gnat_rm/implementation_defined_aspects.rst,
doc/gnat_rm/implementation_defined_pragmas.rst: Remove extra
whitespace.
* gnat_rm.texi: Regenerate.diff --git a/gcc/ada/doc/gnat_rm/implementation_defined_aspects.rst b/gcc/ada/doc/gnat_rm/implementation_defined_aspects.rst
--- a/gcc/ada/doc/gnat_rm/implementation_defined_aspects.rst
+++ b/gcc/ada/doc/gnat_rm/implementation_defined_aspects.rst
@@ -315,10 +315,10 @@ The following is a typical example of use:
 .. code-block:: ada
 
   type List is private with
-  Iterable => (First=> First_Cursor,
-   Next => Advance,
-   Has_Element  => Cursor_Has_Element,
-  [Element  => Get_Element]);
+  Iterable => (First   => First_Cursor,
+   Next=> Advance,
+   Has_Element => Cursor_Has_Element,
+  [Element => Get_Element]);
 
 * The value denoted by ``First`` must denote a primitive operation of the
   container type that returns a ``Cursor``, which must a be a type declared in


diff --git a/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst b/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
--- a/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
+++ b/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
@@ -2847,12 +2847,12 @@ Syntax:
 ::
 
   pragma Import_Function (
-   [Internal =>] LOCAL_NAME,
-[, [External =>] EXTERNAL_SYMBOL]
-[, [Parameter_Types  =>] PARAMETER_TYPES]
-[, [Result_Type  =>] SUBTYPE_MARK]
-[, [Mechanism=>] MECHANISM]
-[, [Result_Mechanism =>] MECHANISM_NAME]);
+   [Internal =>] LOCAL_NAME,
+[, [External =>] EXTERNAL_SYMBOL]
+[, [Parameter_Types  =>] PARAMETER_TYPES]
+[, [Result_Type  =>] SUBTYPE_MARK]
+[, [Mechanism=>] MECHANISM]
+[, [Result_Mechanism =>] MECHANISM_NAME]);
 
   EXTERNAL_SYMBOL ::=
 IDENTIFIER
@@ -2938,10 +2938,10 @@ Syntax:
 ::
 
   pragma Import_Procedure (
-   [Internal =>] LOCAL_NAME
-[, [External =>] EXTERNAL_SYMBOL]
-[, [Parameter_Types  =>] PARAMETER_TYPES]
-[, [Mechanism=>] MECHANISM]);
+   [Internal=>] LOCAL_NAME
+[, [External=>] EXTERNAL_SYMBOL]
+[, [Parameter_Types =>] PARAMETER_TYPES]
+[, [Mechanism   =>] MECHANISM]);
 
   EXTERNAL_SYMBOL ::=
 IDENTIFIER
@@ -2978,10 +2978,10 @@ Syntax:
 ::
 
   pragma Import_Valued_Procedure (
-   [Internal =>] LOCAL_NAME
-[, [External =>] EXTERNAL_SYMBOL]
-[, [Parameter_Types  =>] PARAMETER_TYPES]
-[, [Mechanism=>] MECHANISM]);
+   [Internal=>] LOCAL_NAME
+[, [External=>] EXTERNAL_SYMBOL]
+[, [Parameter_Types =>] PARAMETER_TYPES]
+[, [Mechanism   =>] MECHANISM]);
 
   EXTERNAL_SYMBOL ::=
 IDENTIFIER
@@ -6121,12 +6121,12 @@ Syntax:
 ::
 
   pragma Source_File_Name (
-[Unit_Name   =>] unit_NAME,
+[Unit_Name =>] unit_NAME,
 Spec_File_Name =>  STRING_LITERAL,
 [Index => INTEGER_LITERAL]);
 
   pragma Source_File_Name (
-[Unit_Name   =>] unit_NAME,
+[Unit_Name =>] unit_NAME,
 Body_File_Name =>  STRING_LITERAL,
 [Index => INTEGER_LITERAL]);
 


diff --git a/gcc/ada/gnat_rm.texi b/gcc/ada/gnat_rm.texi
--- a/gcc/ada/gnat_rm.texi
+++ b/gcc/ada/gnat_rm.texi
@@ -4320,12 +4320,12 @@ Syntax:
 
 @example
 pragma Import_Function (
- [Internal =>] LOCAL_NAME,
-  [, [External =>] EXTERNAL_SYMBOL]
-  [, [Parameter_Types  =>] PARAMETER_TYPES]
-  [, [Result_Type  =>] SUBTYPE_MARK]
-  [, [Mechanism=>] MECHANISM]
-  [, [Result_Mechanism =>] MECHANISM_NAME]);
+ [Internal =>] LOCAL_NAME,
+  [, [External =>] EXTERNAL_SYMBOL]
+  [, [Parameter_Types  =>] PARAMETER_TYPES]
+  [, [Result_Type  =>] SUBTYPE_MARK]
+  [, [Mechanism=>] MECHANISM]
+  [, [Result_Mechanism =>] MECHANISM_NAME]);
 
 EXTERNAL_SYMBOL ::=
   IDENTIFIER
@@ -4411,10 +4411,10 @@ Syntax:
 
 @example
 pragma Import_Procedure (
- [Internal =>] LOCAL_NAME
-  [, [External =>] EXTERNAL_SYMBOL]
-  [, [Parameter_Types  =>] PARAMETER_TYPES]
-  [, [Mechanism=>] MECHANISM]);
+ [Internal=>] LOCAL_NAME
+  [, [External=>] EXTERNAL_SYMBOL]
+  [, [Parameter_Types =>] PARAMETER_TYPES]
+  [, [Mechanism   =>] MECHANISM]);
 
 EXTERNAL_SYMBOL ::=
   IDENTIFIER
@@ -4451,10 +4451,10 @@ Syntax:
 
 @example
 pragma Import_Valued_Procedure (
- [Internal =>] LOCAL_NAME
-  [, [External 

[Ada] Fix markup in description of implementation-defined characteristics

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Fix formatting of description lists, i.e. continuation lines are now
indented like their preceding lines.

Spotted while adding description of pragma Ada_2022.

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

gcc/ada/

* doc/gnat_rm/implementation_defined_characteristics.rst: Remove
extra indent in continuation lines; indent both descriptions of
Max_Picture_Length.
* gnat_rm.texi: Regenerate.diff --git a/gcc/ada/doc/gnat_rm/implementation_defined_characteristics.rst b/gcc/ada/doc/gnat_rm/implementation_defined_characteristics.rst
--- a/gcc/ada/doc/gnat_rm/implementation_defined_characteristics.rst
+++ b/gcc/ada/doc/gnat_rm/implementation_defined_characteristics.rst
@@ -54,7 +54,7 @@ See separate section on source representation.
 
 *
   "The semantics of an Ada program whose text is not in
-   Normalization Form C.  See 2.1(4)."
+  Normalization Form C.  See 2.1(4)."
 
 See separate section on source representation.
 
@@ -227,7 +227,7 @@ Round to even is used in all such cases.
 
 *
   "The maximum number of chunks for a parallel generalized iterator without
-   a chunk_specification.  See 5.5.2(10)."
+  a chunk_specification.  See 5.5.2(10)."
 
 Feature unimplemented.
 
@@ -286,7 +286,7 @@ There are no such limits.
 
 *
   "The result of Calendar.Formatting.Image if its argument represents more
-   than 100 hours.  See 9.6.1(86)."
+  than 100 hours.  See 9.6.1(86)."
 
 Calendar.Time_Error is raised.
 
@@ -491,7 +491,7 @@ Unsuppress match those for the second argument of pragma Suppress.
 
 *
   "The cases that cause conflicts between the representation of the
-   ancestors of a type_declaration.  See 13.1(13.1)."
+  ancestors of a type_declaration.  See 13.1(13.1)."
 
 No such cases exist.
 
@@ -782,19 +782,19 @@ Directories.File_Size'Last is equal to Long_Long_Integer'Last .
 
 *
   "The result for Directories.Size for a directory or special file.
-   See A.16(93)."
+  See A.16(93)."
 
 Name_Error is raised.
 
 *
   "The result for Directories.Modification_Time for a directory or special file.
-   See A.16(93)."
+  See A.16(93)."
 
 Name_Error is raised.
 
 *
   "The interpretation of a nonnull search pattern in Directories.
-   See A.16(104)."
+  See A.16(104)."
 
 When the ``Pattern`` parameter is not the null string, it is interpreted
 according to the syntax of regular expressions as defined in the
@@ -804,7 +804,7 @@ See :ref:`GNAT.Regexp_(g-regexp.ads)`.
 
 *
   "The results of a Directories search if the contents of the directory are
-   altered while a search is in progress.  See A.16(110)."
+  altered while a search is in progress.  See A.16(110)."
 
 The effect of a call to Get_Next_Entry is determined by the current
 state of the directory.
@@ -972,7 +972,7 @@ There are no such forms.
 
 *
   "The semantics of some attributes and functions of an entity for which
-   aspect Discard_Names is True.  See C.5(7)."
+  aspect Discard_Names is True.  See C.5(7)."
 
 If Discard_Names is True for an enumeration type, the Image attribute
 provides the image of the Pos of the literal, and Value accepts
@@ -1126,13 +1126,13 @@ Unknown.
 
 *
   "When restriction No_Task_Termination applies to a partition, what happens
-   when a task terminates.  See D.7(15.1)."
+  when a task terminates.  See D.7(15.1)."
 
 Execution is erroneous in that case.
 
 *
   "The behavior when restriction Max_Storage_At_Blocking is violated.
-   See D.7(17)."
+  See D.7(17)."
 
 Execution is erroneous in that case.
 
@@ -1148,10 +1148,10 @@ Execution is erroneous in that case.
 Execution is erroneous in that case.
 
 * "Whether the use of pragma Restrictions results in a reduction in program
-   code or data size or execution time.  See D.7(20)."
+  code or data size or execution time.  See D.7(20)."
 
-   Yes it can, but the precise circumstances and properties of such reductions
-   are difficult to characterize.
+  Yes it can, but the precise circumstances and properties of such reductions
+  are difficult to characterize.
 
 *
   "The value of Barrier_Limit'Last in Synchronous_Barriers.  See D.10.1(4)."
@@ -1166,7 +1166,7 @@ Difficult to characterize.
 
 *
   "The value of Min_Handler_Ceiling in Execution_Time.Group_Budgets.
-   See D.14.2(7)."
+  See D.14.2(7)."
 
 See source file :file:`a-etgrbu.ads`.
 
@@ -1237,13 +1237,13 @@ Named Number Value
   "The value of ``Max_Picture_Length`` in the package
   ``Text_IO.Editing``.  See F.3.3(16)."
 
-64
+  64
 
 *
   "The value of ``Max_Picture_Length`` in the package
   ``Wide_Text_IO.Editing``.  See F.3.4(5)."
 
-64
+  64
 
 *
   "The accuracy actually achieved by the complex elementary
@@ -1368,15 +1368,15 @@ Information on those subjects is not yet available.
 
 *
   "The accuracy requirements for the subprograms Solve, Inverse,
-   Determinant, Eigenvalues and Eigensystem for type Real_Matrix.
-   See G.3.1(81)."
+  Determinant, Eigenvalues and Eigensystem for type Real_Matrix.
+  See G.3.1(81)."
 
 Information on those subjects is 

[Ada] Fix markup in description of pragma Eliminate

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Fix formatting of a nested bullet lists. Spotted while adding
description of pragma Ada_2022.

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

gcc/ada/

* doc/gnat_rm/implementation_defined_pragmas.rst (Pragma
Eliminate): Fix markup.
* gnat_rm.texi: Regenerate.diff --git a/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst b/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
--- a/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
+++ b/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
@@ -1765,27 +1765,23 @@ The pragma has the following semantics, where ``U`` is the unit specified by
 the ``Unit_Name`` argument and ``E`` is the entity specified by the ``Entity``
 argument:
 
-*  ``E`` must be a subprogram that is explicitly declared either:
-
-   o  Within ``U``, or
-
-   o  Within a generic package that is instantiated in ``U``, or
-
-   o  As an instance of generic subprogram instantiated in ``U``.
-
-   Otherwise the pragma is ignored.
-
-*  If ``E`` is overloaded within ``U`` then, in the absence of a
-   ``Source_Location`` argument, all overloadings are eliminated.
-
-*  If ``E`` is overloaded within ``U`` and only some overloadings
-   are to be eliminated, then each overloading to be eliminated
-   must be specified in a corresponding pragma ``Eliminate``
-   with a ``Source_Location`` argument identifying the line where the
-   declaration appears, as described below.
-
-*  If ``E`` is declared as the result of a generic instantiation, then
-   a ``Source_Location`` argument is needed, as described below
+* ``E`` must be a subprogram that is explicitly declared either:
+
+  * Within ``U``, or
+  * Within a generic package that is instantiated in ``U``, or
+  * As an instance of generic subprogram instantiated in ``U``.
+
+  Otherwise the pragma is ignored.
+
+* If ``E`` is overloaded within ``U`` then, in the absence of a
+  ``Source_Location`` argument, all overloadings are eliminated.
+* If ``E`` is overloaded within ``U`` and only some overloadings
+  are to be eliminated, then each overloading to be eliminated
+  must be specified in a corresponding pragma ``Eliminate``
+  with a ``Source_Location`` argument identifying the line where the
+  declaration appears, as described below.
+* If ``E`` is declared as the result of a generic instantiation, then
+  a ``Source_Location`` argument is needed, as described below.
 
 Pragma ``Eliminate`` allows a program to be compiled in a system-independent
 manner, so that unused entities are eliminated but without


diff --git a/gcc/ada/gnat_rm.texi b/gcc/ada/gnat_rm.texi
--- a/gcc/ada/gnat_rm.texi
+++ b/gcc/ada/gnat_rm.texi
@@ -3185,11 +3185,18 @@ argument:
 @item 
 @code{E} must be a subprogram that is explicitly declared either:
 
-o  Within @code{U}, or
 
-o  Within a generic package that is instantiated in @code{U}, or
+@itemize *
+
+@item 
+Within @code{U}, or
 
-o  As an instance of generic subprogram instantiated in @code{U}.
+@item 
+Within a generic package that is instantiated in @code{U}, or
+
+@item 
+As an instance of generic subprogram instantiated in @code{U}.
+@end itemize
 
 Otherwise the pragma is ignored.
 
@@ -3206,7 +3213,7 @@ declaration appears, as described below.
 
 @item 
 If @code{E} is declared as the result of a generic instantiation, then
-a @code{Source_Location} argument is needed, as described below
+a @code{Source_Location} argument is needed, as described below.
 @end itemize
 
 Pragma @code{Eliminate} allows a program to be compiled in a system-independent




[Ada] Document pragma Ada_2022

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Pragma Ada_2022 is similar to existing pragma Ada_2012 and similarly
deserves to be documented.

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

gcc/ada/

* doc/gnat_rm/implementation_defined_pragmas.rst (Pragma
Ada_2022): Copy description from pragma Ada 2012 and adapt.
* doc/gnat_ugn/the_gnat_compilation_model.rst (Configuration
Pragmas): List pragma Ada 2022.
* gnat_rm.texi, gnat_ugn.texi: Regenerate.

patch.diff.gz
Description: application/gzip


[Ada] Add guard for making only legal labels unreachable

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
An entity flag Reachable now only applies to E_Label entities. We had an
appropriate guard for setting this flag, but not for clearing.

Cleanup related to detection of uninitialized scalars with GOTO
statements.

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

gcc/ada/

* sem_ch5.adb (Analyze_Statements): Only clear Reachable flag on
proper label entities.diff --git a/gcc/ada/sem_ch5.adb b/gcc/ada/sem_ch5.adb
--- a/gcc/ada/sem_ch5.adb
+++ b/gcc/ada/sem_ch5.adb
@@ -4383,7 +4383,9 @@ package body Sem_Ch5 is
 
   S := First (L);
   while Present (S) loop
- if Nkind (S) = N_Label then
+ if Nkind (S) = N_Label
+   and then Ekind (Entity (Identifier (S))) = E_Label
+ then
 Set_Reachable (Entity (Identifier (S)), False);
  end if;
 




[Ada] Properly reject unsupported address specifications

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
In the case of an object declaration with an indefinite nominal subtype
(roughly speaking, that's an object that takes its bounds,
discriminants, and/or tag from its explicit initial value), GNAT does
not support address specifications unless the size of the object is
known at compile time.  In some cases, such unsupported address
specifications were not properly rejected. This could lead to either an
internal error during compilation or (in the class-wide case) to a
warning accompanied by raising Program_Error at run time.

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

gcc/ada/

* sem_ch13.adb (Analyze_Attribute_Definition_Clause): Replace
the existing check for an address specification for an object of
a class-wide type with a more general check which rejects either
the class-wide case or the case where the FE would (if the
address specification were accepted) build a malformed
tree (specifically, an object renaming declaration with a
specified address). In the case where the check fails, reject
the construct at compile time instead of generating an
unconditional raise of Program_Error.
* doc/gnat_rm/representation_clauses_and_pragmas.rst: Update
documentation to reflect these changes.
* gnat_rm.texi: Regenerate.diff --git a/gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst b/gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst
--- a/gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst
+++ b/gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst
@@ -1585,9 +1585,20 @@ check Alignment_Check is suppressed, or if
 ``pragma Restrictions (No_Elaboration_Code)`` is in effect. It is also
 suppressed by default on non-strict alignment machines (such as the x86).
 
-Finally, GNAT does not permit overlaying of objects of class-wide types. In
-most cases, the compiler can detect an attempt at such overlays and will
-generate a warning at compile time and a Program_Error exception at run time.
+In some cases, GNAT does not support an address specification (using either
+form of aspect specification syntax) for the declaration of an object that has
+an indefinite nominal subtype. An object declaration has an indefinite
+nominal subtype if it takes its bounds (for an array type), discriminant
+values (for a discriminated type whose discriminants lack defaults), or tag
+(for a class-wide type) from its initial value, as in
+
+.. code-block:: ada
+
+X : String := Some_Function_Call;
+-- String has no constraint, so bounds for X come from function call
+
+This restriction does not apply if the size of the object's initial value is
+known at compile time and the type of the object is not class-wide.
 
 .. index:: Export
 


diff --git a/gcc/ada/gnat_rm.texi b/gcc/ada/gnat_rm.texi
--- a/gcc/ada/gnat_rm.texi
+++ b/gcc/ada/gnat_rm.texi
@@ -20176,9 +20176,20 @@ check Alignment_Check is suppressed, or if
 @code{pragma Restrictions (No_Elaboration_Code)} is in effect. It is also
 suppressed by default on non-strict alignment machines (such as the x86).
 
-Finally, GNAT does not permit overlaying of objects of class-wide types. In
-most cases, the compiler can detect an attempt at such overlays and will
-generate a warning at compile time and a Program_Error exception at run time.
+In some cases, GNAT does not support an address specification (using either
+form of aspect specification syntax) for the declaration of an object that has
+an indefinite nominal subtype. An object declaration has an indefinite
+nominal subtype if it takes its bounds (for an array type), discriminant
+values (for a discriminated type whose discriminants lack defaults), or tag
+(for a class-wide type) from its initial value, as in
+
+@example
+X : String := Some_Function_Call;
+-- String has no constraint, so bounds for X come from function call
+@end example
+
+This restriction does not apply if the size of the object’s initial value is
+known at compile time and the type of the object is not class-wide.
 
 @geindex Export
 


diff --git a/gcc/ada/sem_ch13.adb b/gcc/ada/sem_ch13.adb
--- a/gcc/ada/sem_ch13.adb
+++ b/gcc/ada/sem_ch13.adb
@@ -6550,22 +6550,47 @@ package body Sem_Ch13 is
 ("\?j?use interrupt procedure instead", N);
end if;
 
---  Case of an address clause for a class-wide object, which is
---  considered erroneous.
-
-elsif Is_Class_Wide_Type (Etype (U_Ent)) then
-   Error_Msg_NE
- ("??class-wide object & must not be overlaid", Nam, U_Ent);
-   Error_Msg_N
- ("\??Program_Error will be raised at run time", Nam);
-   Insert_Action (Declaration_Node (U_Ent),
- Make_Raise_Program_Error (Loc,
-   Reason => PE_Overlaid_Controlled_Object));
-   return;
-
 --  Case of address clause for an object
 
 elsif 

[Ada] Move Reachable flag to E_Label entities

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
An entity flag Reachable is described as "defined in labels". It is only
read and written for entities of kind E_Label (the code has necessary
guards for that). There no need for this flag to be specified for all
entities in the generated AST.

Cleanup related to detection of uninitialized scalars with GOTO
statements.

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

gcc/ada/

* gen_il-gen-gen_entities.adb (Reachable): Move from
Root_Entity_Type to E_Label.diff --git a/gcc/ada/gen_il-gen-gen_entities.adb b/gcc/ada/gen_il-gen-gen_entities.adb
--- a/gcc/ada/gen_il-gen-gen_entities.adb
+++ b/gcc/ada/gen_il-gen-gen_entities.adb
@@ -217,7 +217,6 @@ begin -- Gen_IL.Gen.Gen_Entities
 Sm (No_Return, Flag),
 Sm (Overlays_Constant, Flag),
 Sm (Prev_Entity, Node_Id),
-Sm (Reachable, Flag),
 Sm (Referenced, Flag),
 Sm (Referenced_As_LHS, Flag),
 Sm (Referenced_As_Out_Parameter, Flag),
@@ -1241,6 +1240,7 @@ begin -- Gen_IL.Gen.Gen_Entities
--  implicit label declaration, not the occurrence of the label itself,
--  which is simply a direct name referring to the label.
(Sm (Enclosing_Scope, Node_Id),
+Sm (Reachable, Flag),
 Sm (Renamed_Or_Alias, Node_Id)));
 
Cc (E_Loop, Entity_Kind,




[Ada] Set_Is_Known_Valid only if Safe_To_Capture_Value

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
Library-level variables with initializers could have Is_Known_Valid
set when analyzing their definition, and the flag would only be
cleared when analyzing a statement that assigned to them. Procedures
and functions analyzed before the flag got cleared could skip validity
checking for the corresponding variable. This patch fixes this
problem: we no longer set Is_Known_Valid when analyzing initializers
of library-level variables,and use the same Safe_To_Capture_Value
predicate that prevents assignments from recording known-valid states.

This causes any variable with an initialization value, that would have
had its initializer value used as its known constant value if the use
is analyzed before any assignment to the variable, to no longer be
regarded as holding a constant value. Some might turn out to have a
constant value, after all, but we don't know that yet: we can only
tell after analyzing every subprogram that could possibly assign to
it. At the points where Safe_To_Capture_Value calls are introduced,
Never_Set_In_Source does not yet hold its final value.

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

gcc/ada/

* exp_ch3.adb (Expand_N_Object_Declaration): Guard
Set_Is_Known_Valid with Safe_To_Capture_Value.diff --git a/gcc/ada/exp_ch3.adb b/gcc/ada/exp_ch3.adb
--- a/gcc/ada/exp_ch3.adb
+++ b/gcc/ada/exp_ch3.adb
@@ -7534,6 +7534,7 @@ package body Exp_Ch3 is
 elsif Comes_From_Source (N)
   and then Is_Discrete_Type (Typ)
   and then Expr_Known_Valid (Expr)
+  and then Safe_To_Capture_Value (N, Def_Id)
 then
Set_Is_Known_Valid (Def_Id);
 
@@ -7564,7 +7565,9 @@ package body Exp_Ch3 is
   and then not Is_Generic_Type (Etype (Def_Id))
 then
Ensure_Valid (Expr);
-   Set_Is_Known_Valid (Def_Id);
+   if Safe_To_Capture_Value (N, Def_Id) then
+  Set_Is_Known_Valid (Def_Id);
+   end if;
 end if;
  end if;
 




[Ada] Avoid crash for -gnatR -gnatc

2022-05-11 Thread Pierre-Marie de Rodat via Gcc-patches
If the -gnatR -gnatc are both given, then the compiler crashes.  This
patch fixes that, and avoids printing the uncomputed sizes and
alignments that were causing the crash. (Previous versions of the
compiler printed incorrect values in such cases.)

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

gcc/ada/

* repinfo.adb (List_Object_Info): Do not try to print values
that have not been computed (and so are No_Uint).
(Rep_Not_Constant): Reverse sense and change name to
Compile_Time_Known_Rep. This makes the code at call sites a
little more readable. Simplify code to a single return
statement.diff --git a/gcc/ada/repinfo.adb b/gcc/ada/repinfo.adb
--- a/gcc/ada/repinfo.adb
+++ b/gcc/ada/repinfo.adb
@@ -190,9 +190,9 @@ package body Repinfo is
procedure List_Type_Info (Ent : Entity_Id);
--  List type info for type Ent
 
-   function Rep_Not_Constant (Val : Node_Ref_Or_Val) return Boolean;
-   --  Returns True if Val represents a variable value, and False if it
-   --  represents a value that is fixed at compile time.
+   function Compile_Time_Known_Rep (Val : Node_Ref_Or_Val) return Boolean;
+   --  Returns True if Val represents a representation value that is known at
+   --  compile time.
 
procedure Spaces (N : Natural);
--  Output given number of spaces
@@ -908,10 +908,12 @@ package body Repinfo is
 
procedure List_Object_Info (Ent : Entity_Id) is
begin
-  --  The information has not been computed in a generic unit, so don't try
-  --  to print it.
+  --  If size and alignment have not been computed (e.g. if we are in a
+  --  generic unit, or if the back end is not being run), don't try to
+  --  print them.
 
-  if Sem_Util.In_Generic_Scope (Ent) then
+  pragma Assert (Known_Esize (Ent) = Known_Alignment (Ent));
+  if not Known_Alignment (Ent) then
  return;
   end if;
 
@@ -1055,20 +1057,7 @@ package body Repinfo is
Get_Decoded_Name_String (Chars (Comp));
Name_Length := Prefix_Length + Name_Len;
 
-   if Rep_Not_Constant (Bofs) then
-
-  --  If the record is not packed, then we know that all fields
-  --  whose position is not specified have starting normalized
-  --  bit position of zero.
-
-  if not Known_Normalized_First_Bit (Comp)
-and then not Is_Packed (Ent)
-  then
- Set_Normalized_First_Bit (Comp, Uint_0);
-  end if;
-
-  UI_Image_Length := 2; -- For "??" marker
-   else
+   if Compile_Time_Known_Rep (Bofs) then
   Npos := Bofs / SSU;
   Fbit := Bofs mod SSU;
 
@@ -1098,6 +1087,18 @@ package body Repinfo is
   end if;
 
   UI_Image (Spos);
+   else
+  --  If the record is not packed, then we know that all fields
+  --  whose position is not specified have starting normalized
+  --  bit position of zero.
+
+  if not Known_Normalized_First_Bit (Comp)
+and then not Is_Packed (Ent)
+  then
+ Set_Normalized_First_Bit (Comp, Uint_0);
+  end if;
+
+  UI_Image_Length := 2; -- For "??" marker
end if;
 
Max_Name_Length := Natural'Max (Max_Name_Length, Name_Length);
@@ -2118,18 +2119,14 @@ package body Repinfo is
   end if;
end List_Type_Info;
 
-   --
-   -- Rep_Not_Constant --
-   --
+   
+   -- Compile_Time_Known_Rep --
+   
 
-   function Rep_Not_Constant (Val : Node_Ref_Or_Val) return Boolean is
+   function Compile_Time_Known_Rep (Val : Node_Ref_Or_Val) return Boolean is
begin
-  if No (Val) or else Val < 0 then
- return True;
-  else
- return False;
-  end if;
-   end Rep_Not_Constant;
+  return Present (Val) and then Val >= 0;
+   end Compile_Time_Known_Rep;
 
---
-- Rep_Value --
@@ -2408,24 +2405,20 @@ package body Repinfo is
 
procedure Write_Val (Val : Node_Ref_Or_Val; Paren : Boolean := False) is
begin
-  if Rep_Not_Constant (Val) then
- if List_Representation_Info < 3 or else No (Val) then
-Write_Unknown_Val;
-
- else
-if Paren then
-   Write_Char ('(');
-end if;
+  if Compile_Time_Known_Rep (Val) then
+ UI_Write (Val, Decimal);
+  elsif List_Representation_Info < 3 or else No (Val) then
+ Write_Unknown_Val;
+  else
+ if Paren then
+Write_Char ('(');
+ end if;
 
-List_GCC_Expression (Val);
+ List_GCC_Expression (Val);
 
-if Paren then
-   Write_Char (')');
-end if;

Re: [PATCH, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

2022-05-11 Thread Kewen.Lin via Gcc-patches
Hi Segher,

on 2022/5/10 20:27, Segher Boessenkool wrote:
> Hi guys,
> 
> On Mon, May 09, 2022 at 12:05:51PM +0800, Kewen.Lin wrote:
>> on 2022/5/9 09:54, HAO CHEN GUI wrote:
>>>   This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
>>> Tests show that outputs of xs[min/max]dp are consistent with the standard
>>> of C99 fmin/max.
> 
>>> gcc/
>>> PR target/103605
>>> * rs6000.md (unspec): Add UNSPEC_FMAX and UNSPEC_FMIN.
>>
>> Nit: one entry for iterator FMINMAX?
> 
> It should be
>   * rs6000.md (FMINMAX): New.
> 
>>> (fminmax): New.
>>> (minmax_op): Likewise.
> 
> Please say "New." when something is new, never "Likewise."
> 
>>> (3): New pattern.  Implemented by UNSPEC_FMAX and
>>> UNSPEC_FMIN.
> 
> Leave out the "Implemented..." part please.
> 
>>> +(define_int_iterator FMINMAX [UNSPEC_FMAX UNSPEC_FMIN])
>>> +
>>> +(define_int_attr fminmax [(UNSPEC_FMAX "fmax")
>>> + (UNSPEC_FMIN "fmin")])
>>> +
>>> +(define_int_attr  minmax_op [(UNSPEC_FMAX "max")
>>> +(UNSPEC_FMIN "min")])
>>> +
>>
>> Can we use the later one for both?
>>
>> Like f3.
> 
> Yes.  RTL iterators and attributes are textual replacement and expansion
> only: there is no deeper semantic meaning to it.  In fact, we should
> have only a "minmax" iterator and a "MINMAX" attribute, and then
> simplify everything else.  I'll do this for the existing code.
> 
>>> +(define_insn "3"
>>> +  [(set (match_operand:SFDF 0 "vsx_register_operand" "=")
>>> +   (unspec:SFDF [(match_operand:SFDF 1 "vsx_register_operand" "")
>>> + (match_operand:SFDF 2 "vsx_register_operand" "")]
>>
>> Nit: both SD and DF are mapped to constraint wa, just hardcode Fv to wa?
> 
> (SF and DF)
> 
> Please keep  until  is gone as well, it is easier to read that
> way.  And at that time get rid of *all* .
> 
> Indeed we could get rid of it, but only replacing it in some places and
> not others is confusing (or at least distracting).
> 

aha, thanks for the correction and explanation! 

>> PR103605 also exposes another problem on bif __builtin_vsx_xs{min,max}dp, 
>> both bifs are
>> expanded into xs{min,max}cdp instead of xs{min,max}dp starting from power9.
>>
>> IMHO, it's something we want to fix as well, based on the reasons:
>>   1) bif names have the corresponding mnemonics, users would expect 1-1 
>> mapping here.
>>   2) clang emits xs{min,max}dp all the time, with cpu type power7/8/9/10.
>>   3) according to uarch info, xs{min,max}cdp use the same units and have the 
>> same latency,
>>  no benefits to replace with xs{min,max}cdp.
> 
> I never understood any of this.  Mike?  Why do we do those "c" things
> at all, ever?
> 
>> So I wonder if it would be more clear with:
>>   1) add new define_insn for xs{min,max}dp
> 
> No, the existing thing should always do these insns.

Currently xs{min,max}dp are only covered by smin/smax, no their own define_insn?

> 
>>   2) use them for new define_expand of fmin/fmax
>>   3) use them for bif expansion pattern
> 
> There is no way to express fmin/fmax without unspecs currently (without
> fastmath).  This is a serious problem.
> 
Yeah, I agree.  The above question/proposal still needs UNSPEC for new
define_insn, and if we want to replace the expansion pattern for bif
__builtin_vsx_xs{min,max}dp, we seem to have alternatives:

1) as Haochen's patch, new define_insn fmin/fmax with UNSPEC_F{MAX,MIN}
and used for actual insns xs{min,max}dp and replace bif table entry with
fmin/fmax*.

2) new define_insn vsx_xs{min,max}dp with UNSPEC_XS{MAX,MIN}DP and used
for actual insns xs{min,max}dp, new define_expand for fmin/fmax optabs,
replace bif table entry with vsx_xs{min,max}dp*.

I personally felt (wondered) if 2) is more clear?  Because the mnemonics
xs{min,max}dp don't have fmin/fmax inside the names, ISA doesn't even
mention they can be used for fmin/fmax in Programming Notes, it seems
more straight to see vsx_xs{min,max}dp used as bif expansion patterns
and UNSPEC_XS{MAX,MIN}DP.  But both 1) and 2) are fine to me. :)

BR,
Kewen


Re: [PATCH] i386: simplify cpu_feature handling

2022-05-11 Thread Martin Liška
On 5/11/22 10:27, Uros Bizjak wrote:
> On Wed, May 11, 2022 at 10:19 AM Martin Liška  wrote:
>>
>> On 5/2/22 09:57, Martin Liška wrote:
>>> On 3/31/22 09:01, Martin Liška wrote:
 @Jakub: May I install it once stage1 opens?
>>>
>>> May I please ping this?
>>>
>>> Thanks,
>>> Martin
>>>

 Cheers,
 Martin

 On 1/3/22 12:43, Martin Liška wrote:
> PING: Jakub?
>
> On 12/15/21 10:57, Martin Liška wrote:
>> On 12/14/21 17:12, Jakub Jelinek wrote:
>>> I'd use INT_TYPE_SIZE - 1 instead of 31.  Otherwise LGTM.
>>
>> Installed with that change, thanks.
>>
>> Moreover, I'm suggesting a simplification:
>>
>> The patch removes unneeded loops for cpu_features2 and CONVERT_EXPR
>> that can be simplified with NOP_EXPR.
>>
>> Survives i386.exp tests, may I install the patch after testing or
>> is it a stage1 material?
>>
>> Thanks,
>> Martin
>

>>>
>>
>> CCing Uros.
>>
>> May I install the patch?
> 
> Can you please attach the latest version of the patch? I only found
> the version from Dec. 15. 2021, which I'm not sure is the latest,
> 
> Thanks,
> Uros.

Sure, there's the rebased version of the patch.

Thanks,
MartinFrom 72aa0459f84baa845fef7f9f7f0d04edda410d87 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 15 Dec 2021 10:54:23 +0100
Subject: [PATCH] i386: simplify cpu_feature handling

The patch removes unneeded loops for cpu_features2 and CONVERT_EXPR
that can be simplified with NOP_EXPR.

gcc/ChangeLog:

	* common/config/i386/cpuinfo.h (has_cpu_feature): Directly
	compute index in cpu_features2.
	(set_cpu_feature): Likewise.
	* config/i386/i386-builtins.cc (fold_builtin_cpu): Also remove
	loop for cpu_features2 and use NOP_EXPRs.
---
 gcc/common/config/i386/cpuinfo.h | 50 +++-
 gcc/config/i386/i386-builtins.cc | 79 
 2 files changed, 67 insertions(+), 62 deletions(-)

diff --git a/gcc/common/config/i386/cpuinfo.h b/gcc/common/config/i386/cpuinfo.h
index 239759dc766..6d6171f4555 100644
--- a/gcc/common/config/i386/cpuinfo.h
+++ b/gcc/common/config/i386/cpuinfo.h
@@ -55,43 +55,49 @@ struct __processor_model2
 static inline int
 has_cpu_feature (struct __processor_model *cpu_model,
 		 unsigned int *cpu_features2,
-		 enum processor_features f)
+		 enum processor_features feature)
 {
-  unsigned int i;
+  unsigned index, offset;
+  unsigned f = feature;
+
   if (f < 32)
 {
   /* The first 32 features.  */
-  return cpu_model->__cpu_features[0] & (1U << (f & 31));
+  return cpu_model->__cpu_features[0] & (1U << f);
+}
+  else
+{
+  /* The rest of features.  cpu_features2[i] contains features from
+	 (32 + i * 32) to (31 + 32 + i * 32), inclusively.  */
+  f -= 32;
+  index = f / 32;
+  offset = f % 32;
+  return cpu_features2[index] & (1U << offset);
 }
-  /* The rest of features.  cpu_features2[i] contains features from
- (32 + i * 32) to (31 + 32 + i * 32), inclusively.  */
-  for (i = 0; i < SIZE_OF_CPU_FEATURES; i++)
-if (f < (32 + 32 + i * 32))
-return cpu_features2[i] & (1U << ((f - (32 + i * 32)) & 31));
-  gcc_unreachable ();
 }
 
 static inline void
 set_cpu_feature (struct __processor_model *cpu_model,
 		 unsigned int *cpu_features2,
-		 enum processor_features f)
+		 enum processor_features feature)
 {
-  unsigned int i;
+  unsigned index, offset;
+  unsigned f = feature;
+
   if (f < 32)
 {
   /* The first 32 features.  */
-  cpu_model->__cpu_features[0] |= (1U << (f & 31));
-  return;
+  cpu_model->__cpu_features[0] |= (1U << f);
+}
+  else
+{
+  /* The rest of features.  cpu_features2[i] contains features from
+	 (32 + i * 32) to (31 + 32 + i * 32), inclusively.  */
+  f -= 32;
+  index = f / 32;
+  offset = f % 32;
+  cpu_features2[index] |= (1U << offset);
 }
-  /* The rest of features.  cpu_features2[i] contains features from
- (32 + i * 32) to (31 + 32 + i * 32), inclusively.  */
-  for (i = 0; i < SIZE_OF_CPU_FEATURES; i++)
-if (f < (32 + 32 + i * 32))
-  {
-	cpu_features2[i] |= (1U << ((f - (32 + i * 32)) & 31));
-	return;
-  }
-  gcc_unreachable ();
 }
 
 /* Get the specific type of AMD CPU and return AMD CPU name.  Return
diff --git a/gcc/config/i386/i386-builtins.cc b/gcc/config/i386/i386-builtins.cc
index 8c6d0fe9631..59c7da25a14 100644
--- a/gcc/config/i386/i386-builtins.cc
+++ b/gcc/config/i386/i386-builtins.cc
@@ -2280,7 +2280,7 @@ fold_builtin_cpu (tree fndecl, tree *args)
   /* Check the value.  */
   final = build2 (EQ_EXPR, unsigned_type_node, ref,
 		  build_int_cstu (unsigned_type_node, field_val));
-  return build1 (CONVERT_EXPR, integer_type_node, final);
+  return build1 (NOP_EXPR, integer_type_node, final);
 }
   else if (fn_code == IX86_BUILTIN_CPU_SUPPORTS)
 {
@@ -2305,7 +2305,8 @@ fold_builtin_cpu (tree fndecl, tree *args)
 	  return integer_zero_node;
 	}
 
-  if 

  1   2   >