Re: [PATCH] rs6000: Use subreg for QI/HI vector init

[Kewen.Lin via Gcc-patches]

Hi Segher,

Thanks for the review!

on 2020/12/15 上午2:51, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, Dec 02, 2020 at 05:44:24PM +0800, Kewen.Lin wrote:
>> This patch is to use paradoxical subreg instead of
>> zero_extend for promoting QI/HI to SI/DI when we
>> want to construct one vector with these modes.
>> Since we do the gpr->vsx movement and vector merge
>> or pack later, the high part is useless and safe to
>> use paradoxical subreg.  It can avoid useless rlwinms
>> generated for signed cases.
> 
>> --- a/gcc/config/rs6000/rs6000.c
>> +++ b/gcc/config/rs6000/rs6000.c
>> @@ -6793,17 +6793,8 @@ rs6000_expand_vector_init (rtx target, rtx vals)
>>/* Force the values into word_mode registers.  */
>>for (i = 0; i < n_elts; i++)
>>  {
>> -  rtx tmp = force_reg (GET_MODE_INNER (mode), XVECEXP (vals, 0, i));
>> -  if (TARGET_POWERPC64)
>> -{
>> -  op[i] = gen_reg_rtx (DImode);
>> -  emit_insn (gen_zero_extendqidi2 (op[i], tmp));
>> -}
>> -  else
>> -{
>> -  op[i] = gen_reg_rtx (SImode);
>> -  emit_insn (gen_zero_extendqisi2 (op[i], tmp));
>> -}
>> +  rtx tmp = force_reg (inner_mode, XVECEXP (vals, 0, i));
>> +  op[i] = simplify_gen_subreg (Pmode, tmp, inner_mode, 0);
>>  }
> 
> Pmode is defined based on TARGET_64BIT, not TARGET_POWERPC64.
> 

Good point, you are right, is it ok to change this part with one
explicit mode based on TARGET_POWERPC64?

  rtx tmp = force_reg (inner_mode, XVECEXP (vals, 0, i));
  machine_mode tmode = TARGET_POWERPC64 ? DImode : SImode;
  op[i] = simplify_gen_subreg (tmode, tmp, inner_mode, 0);

> But, can you not always use SImode here?
> 

Sorry that I didn't quite follow here.
It uses DImode when TARGET_POWERPC64, so not SImode always (when
!TARGET_POWERPC64).

BR,
Kewen

AVR maintainership (was: [patch,avr, 1/3] Support 64-bit (long) double: The gcc part.)

[Gerald Pfeifer]

On Mon, 6 Jan 2020, Jeff Law wrote:
>> p.s. You know anything about Denis Chertykov? He used to reply to avr 
>> patches within hours, but my latest patches (after a long period where I 
>> didn't propose any patches) where all approved by you; not a single mail 
>> from Denis.  So I am concerned if he's well.  Maybe he left you or some 
>> other global maintainer a note? He's still listed as maintainer though.
> I haven't heard much from him for a while.  I'm trying to leave enough
> space that he can step in on this stuff, but I'm also hesitant to let
> patches linger for too long.

I don't think I have seen mails from Denis since then (more than 
eleven months).

Do we need to get a new maintainer for AVR in place? Any nominations?

Gerald

[committed] doc: Update link to KernelAddressSanitizer

[Gerald Pfeifer]

A simple redirect; pushed.

Gerald


gcc/ChangeLog:

2020-12-15  Gerald Pfeifer  

* doc/invoke.texi (Instrumentation Options): Update link to
KernelAddressSanitizer.
---
 gcc/doc/invoke.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 691b4cbd287..1e025f3285a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -14586,7 +14586,7 @@ currently supported on is AArch64.
 @item -fsanitize=kernel-address
 @opindex fsanitize=kernel-address
 Enable AddressSanitizer for Linux kernel.
-See @uref{https://github.com/google/kasan/wiki} for more details.
+See @uref{https://github.com/google/kasan} for more details.
 
 @item -fsanitize=hwaddress
 @opindex fsanitize=hwaddress
-- 
2.29.2

[committed] wwwdocs: gcc-10/changes: Update two arm.com URLs

[Gerald Pfeifer]

The webmasters for arm.com appear to be a little bored (and like
ever longer URLs); at least they put a redirect in place.

Pushed.

Gerald
---
 htdocs/gcc-10/changes.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index d40a633c..22bf54bb 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -835,7 +835,7 @@ typedef svbool_t pred512 
__attribute__((arm_sve_vector_bits(512)));
-mtune=cortex-m35p.
   
   Support has been extended for the ACLE
-  https://developer.arm.com/docs/101028/0009/Data-processing-intrinsics;>
+  https://developer.arm.com/documentation/101028/0009/Data-processing-intrinsics;>
   data-processing intrinsics to include 32-bit SIMD, saturating arithmetic,
   16-bit multiplication and other related intrinsics aimed at DSP algorithm
   optimization.
@@ -858,7 +858,7 @@ typedef svbool_t pred512 
__attribute__((arm_sve_vector_bits(512)));
   +mve or +mve.fp option extensions (for
   example: -march=armv8.1-m.main+mve).
   Support for the Custom Datapath Extension beta ACLE
-  https://developer.arm.com/docs/101028/0010/Custom-Datapath-Extension;>
+  https://developer.arm.com/documentation/101028/0010/Custom-Datapath-Extension;>
   intrinsics has been added.
   Support for Armv8.1-M Mainline Security Extensions architecture has been 
added. The -mcmse option,
   when used in combination with an Armv8.1-M Mainline architecture (for 
example: -march=armv8.1-m.main -mcmse),
-- 
2.29.2

[committed] wwwdocs: extensions: Update StarPU link

[Gerald Pfeifer]

A straightforward redirect resolved.

Gerald
---
 htdocs/extensions.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/extensions.html b/htdocs/extensions.html
index 76a89e1a..2e929a5b 100644
--- a/htdocs/extensions.html
+++ b/htdocs/extensions.html
@@ -30,7 +30,7 @@ analysis, debugging, and performance tuning in concurrent 
code.
   and inspect the abstract syntax tree of a translation unit.
 
 
-http://starpu.gforge.inria.fr/;>StarPU
+https://starpu.gitlabpages.inria.fr;>StarPU
 
 StarPU is a GCC extension and run-time support library for hybrid
   CPU/GPU task programming.  Its GCC plug-in allows programmers to
-- 
2.29.2

[COMMITTED] gcc: xtensa: fix PR target/98285

[Max Filippov via Gcc-patches]

2020-12-14  Max Filippov  
gcc/
* config/xtensa/predicates.md (addsubx_operand): Change accepted
values from 2/4/8 to 1..3.
* config/xtensa/xtensa.md (*addx, *subx): Change RTL pattern
to use 'ashift' instead of 'mult'. Update operands[3] value.

gcc/testsuite/
* gcc.target/xtensa/pr98285.c: New test.
---
 gcc/config/xtensa/predicates.md   |  5 +--
 gcc/config/xtensa/xtensa.md   | 18 +---
 gcc/testsuite/gcc.target/xtensa/pr98285.c | 54 +++
 3 files changed, 68 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/xtensa/pr98285.c

diff --git a/gcc/config/xtensa/predicates.md b/gcc/config/xtensa/predicates.md
index 1721640dc79e..eb52b05aafad 100644
--- a/gcc/config/xtensa/predicates.md
+++ b/gcc/config/xtensa/predicates.md
@@ -25,9 +25,8 @@
 
 (define_predicate "addsubx_operand"
   (and (match_code "const_int")
-   (match_test "INTVAL (op) == 2
-   || INTVAL (op) == 4
-   || INTVAL (op) == 8")))
+   (match_test "INTVAL (op) >= 1
+   && INTVAL (op) <= 3")))
 
 (define_predicate "arith_operand"
   (ior (and (match_code "const_int")
diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index 749fe477d562..671c4bea144f 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -162,11 +162,14 @@
 
 (define_insn "*addx"
   [(set (match_operand:SI 0 "register_operand" "=a")
-   (plus:SI (mult:SI (match_operand:SI 1 "register_operand" "r")
- (match_operand:SI 3 "addsubx_operand" "i"))
+   (plus:SI (ashift:SI (match_operand:SI 1 "register_operand" "r")
+   (match_operand:SI 3 "addsubx_operand" "i"))
 (match_operand:SI 2 "register_operand" "r")))]
   "TARGET_ADDX"
-  "addx%3\t%0, %1, %2"
+{
+  operands[3] = GEN_INT (1 << INTVAL (operands[3]));
+  return "addx%3\t%0, %1, %2";
+}
   [(set_attr "type""arith")
(set_attr "mode""SI")
(set_attr "length"  "3")])
@@ -196,11 +199,14 @@
 
 (define_insn "*subx"
   [(set (match_operand:SI 0 "register_operand" "=a")
-   (minus:SI (mult:SI (match_operand:SI 1 "register_operand" "r")
-  (match_operand:SI 3 "addsubx_operand" "i"))
+   (minus:SI (ashift:SI (match_operand:SI 1 "register_operand" "r")
+(match_operand:SI 3 "addsubx_operand" "i"))
  (match_operand:SI 2 "register_operand" "r")))]
   "TARGET_ADDX"
-  "subx%3\t%0, %1, %2"
+{
+  operands[3] = GEN_INT (1 << INTVAL (operands[3]));
+  return "subx%3\t%0, %1, %2";
+}
   [(set_attr "type""arith")
(set_attr "mode""SI")
(set_attr "length"  "3")])
diff --git a/gcc/testsuite/gcc.target/xtensa/pr98285.c 
b/gcc/testsuite/gcc.target/xtensa/pr98285.c
new file mode 100644
index ..2c037d546565
--- /dev/null
+++ b/gcc/testsuite/gcc.target/xtensa/pr98285.c
@@ -0,0 +1,54 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int mul3(int v)
+{
+  return v * 3;
+}
+
+int mul5(int v)
+{
+  return v * 5;
+}
+
+int mul7(int v)
+{
+  return v * 7;
+}
+
+int mul9(int v)
+{
+  return v * 9;
+}
+
+int mul2sub(int a, int b)
+{
+  return a * 2 - b;
+}
+
+int mul4sub(int a, int b)
+{
+  return a * 4 - b;
+}
+
+short index2(short *p, int i)
+{
+  return p[i];
+}
+
+int index4(int *p, int i)
+{
+  return p[i];
+}
+
+long long index8(long long *p, int i)
+{
+  return p[i];
+}
+
+/* { dg-final { scan-assembler-times "addx2" 2 } } */
+/* { dg-final { scan-assembler-times "addx4" 2 } } */
+/* { dg-final { scan-assembler-times "addx8" 2 } } */
+/* { dg-final { scan-assembler-times "subx2" 1 } } */
+/* { dg-final { scan-assembler-times "subx4" 1 } } */
+/* { dg-final { scan-assembler-times "subx8" 1 } } */
-- 
2.20.1

Go testsuite patch committed: Retain any characters at end of ERROR line

[Ian Lance Taylor via Gcc-patches]

This patch to the Go testsuite driver retains any characters at the
end of an ERROR line in a test.  This is needed for at least one
upcoming test.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian

* go.test/go-test.exp (errchk): Retain any characters at the end
of the comment.
diff --git a/gcc/testsuite/go.test/go-test.exp 
b/gcc/testsuite/go.test/go-test.exp
index b03cb16990d..c1b27c09236 100644
--- a/gcc/testsuite/go.test/go-test.exp
+++ b/gcc/testsuite/go.test/go-test.exp
@@ -124,8 +124,7 @@ proc errchk { test opts } {
# to
#   // { dg-error {string} }
# The latter is what go-dg-runtest expects.
-   # Retain an optional trailing */, for syntax/semi6.go.
-   regsub {// (GCCGO_)?ERROR "([^"]*)" *(\*/)?$} $copy_line "// \{ 
dg-error \{\\2\} \}\\3" out_line
+   regsub {// (GCCGO_)?ERROR "([^"]*)"([^"]*)$} $copy_line "// \{ dg-error 
\{\\2\} \}\\3" out_line
 
puts $fdout $out_line
 }

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

[Nikhil Benesch via Gcc-patches]

On 12/14/20 10:34 PM, Ian Lance Taylor wrote:

On Mon, Dec 14, 2020 at 7:14 PM Nikhil Benesch  wrote:

Also godump now emits a dummy `type _u?pad128_t struct {}` entry,
so we just suppress that and conditionally add it back.


I don't understand this bit.  Why are we seeing an empty struct
definition, and why is this change the right fix?

Is the problem that because we don't know how to emit the definition
of the struct, godump.c winds up emitting an empty definition?  That
doesn't sound like the right thing to do for this case.


That's a good question. u?pad128_t is clearly getting marked as a
potential dummy type. But then you'd think it'd *also* get marked as
an invalid type, and then find_dummy_types would suppress it.

Oh, you know, I bet the change to use DECL_ORIGINAL_TYPE means the
pointers in pot_dummy_types and invalid_types no longer line up. It
might be as simple as this:

diff --git a/gcc/godump.c b/gcc/godump.c
index ff3a4a9..2497037 100644
--- a/gcc/godump.c
+++ b/gcc/godump.c
@@ -1177,7 +1177,8 @@ go_output_typedef (class godump_container *container, 
tree decl)
   NULL, false))
{
  fprintf (go_dump_file, "// ");
- slot = htab_find_slot (container->invalid_hash, type, INSERT);
+ slot = htab_find_slot (container->invalid_hash, original_type,
+INSERT);
  *slot = CONST_CAST (void *, (const void *) type);
}
   fprintf (go_dump_file, "type _%s ",

I can't test this theory for a bit though. Probably should couple with a
negative (scan-file-not) test too.

Nikhil

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

[Ian Lance Taylor via Gcc-patches]

On Mon, Dec 14, 2020 at 7:14 PM Nikhil Benesch  wrote:
>
> On 12/14/20 5:30 AM, Rainer Orth wrote:
> > with the revised godump.c patch and this one for mk*sysinfo.sh, I still
> > get failures on all of Solaris 11.3/x86, 11.4/x86, and 11.4/SPARC
> > (didn't try 11.3/SPARC):
> >
> > * Solaris 11.3/x86 and 11.4/x86:
> >
> > runtime_sysinfo.go:5995:6: error: redefinition of '_upad128_t'
> >
> >gen-sysinfo has
> >
> > // type _upad128_t struct { _q INVALID-float-80; Godump_0_pad [4]byte; }
> > type _upad128_t struct {}
> >
> >and mk*sysinfo.sh adds
> >
> > type _upad128_t struct { _l [4]uint32; }
> >
> > * Solaris 11.4/SPARC and x86:
> >
> > runtime_sysinfo.go:1178:55: error: use of undefined type '_in6_addr_t'
> >
> >runtime_sysinfo.go uses _in6_addr_t in _flow_arp_desc_s,
> >_flow_l3_desc_s, _mac_ipaddr_s, _mac_resource_props_s, and
> >_mactun_info_s, but there's no definition and you've removed the
> >section of mk*sysinfo.sh to replace it by [16]byte.
> >
> >The issue is here, I believe:
> >
> > +  -e 's/\([^a-zA-Z0-9_]\)_in6_addr\([^a-zA-Z0-9_]\)/\1[16]byte\2/g' \
> > +  -e 's/\([^a-zA-Z0-9_]\)_in6_addr$/\1[16]byte/g' \
> >
> >Neither line matches _in6_addr_t.  Removing '_' from the second char
> >set on the first line fixes this, but I'm unsure what exactly this is
> >going to match on different systems.
> >
> >   Rainer
> >
>
> Sigh. Thanks. Perhaps the attached will work.
>
> (I'm still waiting on my own compilation to complete. Compilation on
> gcc211 is glacial. I wonder if I'm doing something wrong.)
>
> The idea is to just rewrite both _in_addr and _in_addr_t. Perhaps
> someone smarter than me can figure out how to write a simpler set
> of basic REs.
>
> Also godump now emits a dummy `type _u?pad128_t struct {}` entry,
> so we just suppress that and conditionally add it back.

I don't understand this bit.  Why are we seeing an empty struct
definition, and why is this change the right fix?

Is the problem that because we don't know how to emit the definition
of the struct, godump.c winds up emitting an empty definition?  That
doesn't sound like the right thing to do for this case.

Ian

Re: [PATCH 3/1] c++: Fix return type deduction during satisfaction

[Jason Merrill via Gcc-patches]

On 12/14/20 3:47 PM, Patrick Palka wrote:

On Mon, 14 Dec 2020, Jason Merrill wrote:


On 12/14/20 1:07 PM, Patrick Palka wrote:

During satisfaction that's entered through the three-parameter version
of satisfy_declaration_constraints, current_function_decl gets set to
the dependent DECL_TEMPLATE_RESULT for sake of access checking.  This
makes the predicate in_template_function return true during satisfaction
from this entrypoint, which in turn makes calls to mark_used exit early
before it does its full processing.  This leads to us accepting the
invalid testcase below due to mark_used never attempting to deduce the
return type of A::foo() and detecting failure thereof.

It seems wrong for in_template_function to return true during
instantiation or during satisfaction, so this patch strengthens
in_template_function to additionally check current_instantiation().


This seems like it ought to work, but I also wonder about looking at
cfun->decl (which is less volatile) instead of current_function_decl for
in_template_function.


That works well, so far it's passed make check-c++.  I'm fully testing
the following patch:


OK.


-- >8 --

Subject: [PATCH] c++: Fix return type deduction during satisfaction

During satisfaction that's entered through the three-parameter version
of satisfy_declaration_constraints, current_function_decl gets set to
the dependent DECL_TEMPLATE_RESULT for sake of access checking.  This
makes the predicate in_template_function return true during satisfaction
from this entrypoint, which in turn makes calls to mark_used exit early
before it does its full processing.  This leads to us accepting the
invalid testcase below due to mark_used never attempting to deduce the
return type of A::foo() and detecting failure thereof.

It seems wrong for in_template_function to be true during instantiation
or during satisfaction, so this patch makes in_template_function inspect
the less volatile cfun->decl instead of current_function_decl.

gcc/cp/ChangeLog:

* pt.c (in_template_function): Inspect cfun->decl instead of
current_function_decl.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-requires23.C: New test.
---
  gcc/cp/pt.c  | 6 --
  gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C | 9 +
  2 files changed, 13 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 5b13f125002..ce2e8797aae 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10805,14 +10805,16 @@ uses_template_parms (tree t)
return dependent_p;
  }
  
-/* Returns true iff current_function_decl is an incompletely instantiated

+/* Returns true iff we're processing an incompletely instantiated function
 template.  Useful instead of processing_template_decl because the latter
 is set to 0 during instantiate_non_dependent_expr.  */
  
  bool

  in_template_function (void)
  {
-  tree fn = current_function_decl;
+  /* Inspect the less volatile cfun->decl instead of current_function_decl;
+ the latter might get set for e.g. access checking during satisfaction.  */
+  tree fn = cfun ? cfun->decl : NULL_TREE;
bool ret;
++processing_template_decl;
ret = (fn && DECL_LANG_SPECIFIC (fn)
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C
new file mode 100644
index 000..e109beaac4f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C
@@ -0,0 +1,9 @@
+// { dg-do compile { target c++20 } }
+
+// Verify f's associated constraints evaluate to false due
+// to return type deduction failure for A::foo().
+
+template  concept fooable = requires { T::foo(0); };
+template  int f ();
+struct A { static auto *foo(auto); };
+int a = f(); // { dg-error "no match" }

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

[Nikhil Benesch via Gcc-patches]

On 12/14/20 5:30 AM, Rainer Orth wrote:

with the revised godump.c patch and this one for mk*sysinfo.sh, I still
get failures on all of Solaris 11.3/x86, 11.4/x86, and 11.4/SPARC
(didn't try 11.3/SPARC):

* Solaris 11.3/x86 and 11.4/x86:

runtime_sysinfo.go:5995:6: error: redefinition of '_upad128_t'

   gen-sysinfo has

// type _upad128_t struct { _q INVALID-float-80; Godump_0_pad [4]byte; }
type _upad128_t struct {}

   and mk*sysinfo.sh adds

type _upad128_t struct { _l [4]uint32; }

* Solaris 11.4/SPARC and x86:

runtime_sysinfo.go:1178:55: error: use of undefined type '_in6_addr_t'

   runtime_sysinfo.go uses _in6_addr_t in _flow_arp_desc_s,
   _flow_l3_desc_s, _mac_ipaddr_s, _mac_resource_props_s, and
   _mactun_info_s, but there's no definition and you've removed the
   section of mk*sysinfo.sh to replace it by [16]byte.

   The issue is here, I believe:

+  -e 's/\([^a-zA-Z0-9_]\)_in6_addr\([^a-zA-Z0-9_]\)/\1[16]byte\2/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_in6_addr$/\1[16]byte/g' \

   Neither line matches _in6_addr_t.  Removing '_' from the second char
   set on the first line fixes this, but I'm unsure what exactly this is
   going to match on different systems.

Rainer



Sigh. Thanks. Perhaps the attached will work.

(I'm still waiting on my own compilation to complete. Compilation on
gcc211 is glacial. I wonder if I'm doing something wrong.)

The idea is to just rewrite both _in_addr and _in_addr_t. Perhaps
someone smarter than me can figure out how to write a simpler set
of basic REs.

Also godump now emits a dummy `type _u?pad128_t struct {}` entry,
so we just suppress that and conditionally add it back.

If anyone has suggestions for making this less fragile, I'm all ears.

Nikhil
diff --git a/libgo/mkrsysinfo.sh b/libgo/mkrsysinfo.sh
index c28f0e5..7aebe3a 100755
--- a/libgo/mkrsysinfo.sh
+++ b/libgo/mkrsysinfo.sh
@@ -24,11 +24,20 @@ grep -v '^// ' gen-sysinfo.go | \
   grep -v '^type _timespec ' | \
   grep -v '^type _epoll_' | \
   grep -v '^type _*locale[_ ]' | \
-  grep -v 'in6_addr' | \
+  grep -v '^type _in6_addr' | \
   grep -v 'sockaddr_in6' | \
+  grep -v '^type _upad128_t' | \
+  grep -v '^type _pad128_t' | \
   sed -e 's/\([^a-zA-Z0-9_]\)_timeval\([^a-zA-Z0-9_]\)/\1timeval\2/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_timeval$/\1timeval/g' \
   -e 's/\([^a-zA-Z0-9_]\)_timespec_t\([^a-zA-Z0-9_]\)/\1timespec\2/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_timespec_t$/\1timespec_t/g' \
   -e 's/\([^a-zA-Z0-9_]\)_timespec\([^a-zA-Z0-9_]\)/\1timespec\2/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_timespec$/\1timespec/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_in6_addr\([^a-zA-Z0-9_]\)/\1[16]byte\2/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_in6_addr$/\1[16]byte/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_in6_addr_t\([^a-zA-Z0-9_]\)/\1[16]byte\2/g' \
+  -e 's/\([^a-zA-Z0-9_]\)_in6_addr_t$/\1[16]byte/g' \
 >> ${OUT}
 
 # The C long type, needed because that is the type that ptrace returns.
@@ -44,16 +53,6 @@ else
   exit 1
 fi
 
-# On AIX, the _arpcom struct, is filtered by the above grep sequence, as it as
-# a field of type _in6_addr, but other types depend on _arpcom, so we need to
-# put it back.
-grep '^type _arpcom ' gen-sysinfo.go | \
-  sed -e 's/_in6_addr/[16]byte/' >> ${OUT}
-
-# Same on Solaris for _mld_hdr_t.
-grep '^type _mld_hdr_t ' gen-sysinfo.go | \
-  sed -e 's/_in6_addr/[16]byte/' >> ${OUT}
-
 # The time structures need special handling: we need to name the
 # types, so that we can cast integers to the right types when
 # assigning to the structures.
@@ -169,36 +168,15 @@ grep '^type _sem_t ' gen-sysinfo.go | \
 # double is commented by -fdump-go-spec.
 if grep "^// type _pad128_t" gen-sysinfo.go > /dev/null 2>&1; then
   echo "type _pad128_t struct { _l [4]int32; }" >> ${OUT}
+else
+  grep "^type _pad128_t" gen-sysinfo.go >> ${OUT} || true
 fi
 if grep "^// type _upad128_t" gen-sysinfo.go > /dev/null 2>&1; then
   echo "type _upad128_t struct { _l [4]uint32; }" >> ${OUT}
+else
+  grep "^type _upad128_t" gen-sysinfo.go >> ${OUT} || true
 fi
 
-# The Solaris 11 Update 1 _zone_net_addr_t struct.
-grep '^type _zone_net_addr_t ' gen-sysinfo.go | \
-sed -e 's/_in6_addr/[16]byte/' \
->> ${OUT}
-
-# The Solaris 11.4 _flow_arp_desc_t struct.
-grep '^type _flow_arp_desc_t ' gen-sysinfo.go | \
-sed -e 's/_in6_addr_t/[16]byte/g' \
->> ${OUT}
-
-# The Solaris 11.4 _flow_l3_desc_t struct.
-grep '^type _flow_l3_desc_t ' gen-sysinfo.go | \
-sed -e 's/_in6_addr_t/[16]byte/g' \
->> ${OUT}
-
-# The Solaris 11.3 _mac_ipaddr_t struct.
-grep '^type _mac_ipaddr_t ' gen-sysinfo.go | \
-sed -e 's/_in6_addr_t/[16]byte/g' \
->> ${OUT}
-
-# The Solaris 11.3 _mactun_info_t struct.
-grep '^type _mactun_info_t ' gen-sysinfo.go | \
-sed -e 's/_in6_addr_t/[16]byte/g' \
->> ${OUT}
-
 # The Solaris port_event_t struct.
 grep '^type _port_event_t ' gen-sysinfo.go | \
 sed -e s'/_port_event_t/portevent/' \
diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh
index b32a026..b2268ac 

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Tue, 15 Dec 2020 at 04:01, Jeff Law  wrote:

>
>
> On 12/14/20 12:10 PM, Dimitar Dimitrov wrote:
> > On четвъртък, 10 декември 2020 г. 10:24:50 EET Richard Biener wrote:
> >> On Thu, Dec 10, 2020 at 6:42 AM Dimitar Dimitrov 
> wrote:
> >>> On сряда, 9 декември 2020 г. 15:12:49 EET abebeos via Gcc-patches
> wrote:
>  Essence:
> 
>  I need a confirmation that the testsuite setup as presented in:
> 
>  https://github.com/abebeos/avr-gnu
> 
>  works fine.
> 
>  The problem with the avr target is that the testsuite cannot be run
>  easily,
>  mainly because of the need for a special simulated-target setup, which
>  does
>  not work for avr as documented. This led developers to a dead-end with
>  their non-cc0-avr-backends (the non-cc0 backend is needed thus avr is
>  not
>  dropped from gcc11).
> 
>  I integrated a toolchain/testsetup to be able to run the gcc testsuite
>  against a simulated avr target.
> 
>  I then used this toolchain to test 2 different existent
>  non-cc0-avr-backends (from pipcet and saaadhu, both github).
> 
>  The result is that saaadhu's backend seems to be working 100%. It has
>  identical testsuite results with the existing (but deprecated)
>  cc0-backend,
>  which means that it can be used "as-is" for inclusion in gcc11.
> 
>  Please note that I did this work in context of a bounty @ bountysouce,
>  more
>  information within the issue:
> 
>  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
> >>> Hi,
> >>>
> >>> I tested the trees you have given with my own AVR test setup [1]. I
> >>> confirm
> >>>
> >>> your results:
> >>>   - saaadhu's tree does not introduce any regressions.
> >>>   - pipcet's tree has 142 gcc and 299 g++ regressions (although many of
> >>>   them
> >>>
> >>> are duplicates, e.g. same test case with different optimization
> >>> levels).
> >>>
> >>> It's a bit awkward to copy gcc/config/avr into a mainline tree.
> Looking at
> >>> their github history, both authors made some small changes in other
> areas.
> >>> I would have prefered to cherry-pick or apply patches.
> >>>
> >>> =
> >>> baseline beb9afcaf1466996a301c778596c5df209e7913c
> >>>
> >>> === gcc Summary ===
> >>>
> >>> # of expected passes87504
> >>> # of unexpected failures1105
> >>> # of unexpected successes   15
> >>> # of expected failures  581
> >>> # of unresolved testcases   16786
> >>> # of unsupported tests  5370
> >>>
> >>> === g++ Summary ===
> >>>
> >>> # of expected passes140663
> >>> # of unexpected failures7932
> >>> # of unexpected successes   21
> >>> # of expected failures  620
> >>> # of unresolved testcases   8603
> >>> # of unsupported tests  11305
> >>>
> >>> =
> >>> pipcet/avr-ccmode
> >>>
> >>> === gcc Summary ===
> >>>
> >>> # of expected passes87463
> >>> # of unexpected failures1221
> >>> # of unexpected successes   15
> >>> # of expected failures  581
> >>> # of unresolved testcases   16799
> >>> # of unsupported tests  5359
> >>>
> >>> === g++ Summary ===
> >>>
> >>> # of expected passes140529
> >>> # of unexpected failures8205
> >>> # of unexpected successes   21
> >>> # of expected failures  620
> >>> # of unresolved testcases   8607
> >>> # of unsupported tests  11301
> >>>
> >>> =
> >>> saadhu/avr-cc0
> >>>
> >>> === gcc Summary ===
> >>>
> >>> # of expected passes87504
> >>> # of unexpected failures1105
> >>> # of unexpected successes   15
> >>> # of expected failures  581
> >>> # of unresolved testcases   16786
> >>> # of unsupported tests  5370
> >>>
> >>> === g++ Summary ===
> >>>
> >>> # of expected passes140663
> >>> # of unexpected failures7932
> >>> # of unexpected successes   21
> >>> # of expected failures  620
> >>> # of unresolved testcases   8603
> >>> # of unsupported tests  11305
> >>>
> >>> On a side note, I build and test AVR backend in mainline everyday. If
> >>> there is interest from AVR maintainers I can post daily results to
> >>> gcc-testresults@ mailing list.
> >> I'd appreciate such postings, not necessarily daily (if there are no
> >> changes). Also (as usual) for active release branches (say once a week
> or
> >> biweekly or even monthly).
> > I'll start sending biweekly the AVR testresults from all active branches.
> >
> > Yesterday my test results were temporarily held back due to large email
> size,
> > but eventually reached gcc-testresults@ . I'd like to know if I need to
> trim
> > them somehow.
> 

Re: V3 [PATCH 1/2] Switch to a new section if the SECTION_RETAIN bit doesn't match

[H.J. Lu via Gcc-patches]

On Mon, Dec 14, 2020 at 5:06 PM Jeff Law  wrote:
>
>
>
> On 12/8/20 5:51 AM, H.J. Lu wrote:
> > When definitions marked with used attribute and unmarked definitions are
> > placed in the section with the same name, switch to a new section if the
> > SECTION_RETAIN bit doesn't match.
> >
> > gcc/
> >
> >   PR target/98146
> >   * output.h (switch_to_section): Add a tree argument, default to
> >   nullptr.
> >   * varasm.c (get_section): If the SECTION_RETAIN bit doesn't match,
> >   return and switch to a new section later.
> >   (assemble_start_function): Pass decl to switch_to_section.
> >   (assemble_variable): Likewise.
> >   (switch_to_section): If the SECTION_RETAIN bit doesn't match,
> >   switch to a new section.
> >
> > gcc/testsuite/
> >
> >   PR target/98146
> >   * c-c++-common/attr-used-5.c: New test.
> >   * c-c++-common/attr-used-6.c: Likewise.
> >   * c-c++-common/attr-used-7.c: Likewise.
> >   * c-c++-common/attr-used-8.c: Likewise.
> >   * c-c++-common/attr-used-9.c: Likewise.
> > ---
> >  gcc/output.h |  2 +-
> >  gcc/testsuite/c-c++-common/attr-used-5.c | 26 
> >  gcc/testsuite/c-c++-common/attr-used-6.c | 26 
> >  gcc/testsuite/c-c++-common/attr-used-7.c |  8 +++
> >  gcc/testsuite/c-c++-common/attr-used-8.c |  8 +++
> >  gcc/testsuite/c-c++-common/attr-used-9.c | 28 ++
> >  gcc/varasm.c | 30 
> >  7 files changed, 123 insertions(+), 5 deletions(-)
> >  create mode 100644 gcc/testsuite/c-c++-common/attr-used-5.c
> >  create mode 100644 gcc/testsuite/c-c++-common/attr-used-6.c
> >  create mode 100644 gcc/testsuite/c-c++-common/attr-used-7.c
> >  create mode 100644 gcc/testsuite/c-c++-common/attr-used-8.c
> >  create mode 100644 gcc/testsuite/c-c++-common/attr-used-9.c
> >
> >
> > diff --git a/gcc/varasm.c b/gcc/varasm.c
> > index 0fac3688828..c5ea29c4e4c 100644
> > --- a/gcc/varasm.c
> > +++ b/gcc/varasm.c
> > @@ -342,6 +342,11 @@ get_section (const char *name, unsigned int flags, 
> > tree decl,
> > sect->common.flags |= (SECTION_WRITE | SECTION_RELRO);
> > return sect;
> >   }
> > +   /* If the SECTION_RETAIN bit doesn't match, return and switch
> > +  to a new section later.  */
> > +   if ((sect->common.flags & SECTION_RETAIN)
> > +   != (flags & SECTION_RETAIN))
> > + return sect;
> At the least you need to fix the function comment as it would no longer
> match the behavior in this case.  It also seems to me that having
> SECTION_RETAIN be a special case like this just seems wrong.   In my
> mind there isn't anything fundamentally different with SECTION_RETAIN vs
> other symbols that it deserves to be special cased like this.

Any symbols with SHF_XXX can be special, for example SHF_TLS.

> Clearly we need to fix something as these bits are causing significant
> fallout, but I'm just not sure what the right fix ought to be.
>
> jeff
>


-- 
H.J.

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[Jeff Law via Gcc-patches]

On 12/14/20 12:10 PM, Dimitar Dimitrov wrote:
> On четвъртък, 10 декември 2020 г. 10:24:50 EET Richard Biener wrote:
>> On Thu, Dec 10, 2020 at 6:42 AM Dimitar Dimitrov  wrote:
>>> On сряда, 9 декември 2020 г. 15:12:49 EET abebeos via Gcc-patches wrote:
 Essence:

 I need a confirmation that the testsuite setup as presented in:

 https://github.com/abebeos/avr-gnu

 works fine.

 The problem with the avr target is that the testsuite cannot be run
 easily,
 mainly because of the need for a special simulated-target setup, which
 does
 not work for avr as documented. This led developers to a dead-end with
 their non-cc0-avr-backends (the non-cc0 backend is needed thus avr is
 not
 dropped from gcc11).

 I integrated a toolchain/testsetup to be able to run the gcc testsuite
 against a simulated avr target.

 I then used this toolchain to test 2 different existent
 non-cc0-avr-backends (from pipcet and saaadhu, both github).

 The result is that saaadhu's backend seems to be working 100%. It has
 identical testsuite results with the existing (but deprecated)
 cc0-backend,
 which means that it can be used "as-is" for inclusion in gcc11.

 Please note that I did this work in context of a bounty @ bountysouce,
 more
 information within the issue:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
>>> Hi,
>>>
>>> I tested the trees you have given with my own AVR test setup [1]. I
>>> confirm
>>>
>>> your results:
>>>   - saaadhu's tree does not introduce any regressions.
>>>   - pipcet's tree has 142 gcc and 299 g++ regressions (although many of
>>>   them
>>>   
>>> are duplicates, e.g. same test case with different optimization
>>> levels).
>>>
>>> It's a bit awkward to copy gcc/config/avr into a mainline tree. Looking at
>>> their github history, both authors made some small changes in other areas.
>>> I would have prefered to cherry-pick or apply patches.
>>>
>>> =
>>> baseline beb9afcaf1466996a301c778596c5df209e7913c
>>>
>>> === gcc Summary ===
>>>
>>> # of expected passes87504
>>> # of unexpected failures1105
>>> # of unexpected successes   15
>>> # of expected failures  581
>>> # of unresolved testcases   16786
>>> # of unsupported tests  5370
>>>
>>> === g++ Summary ===
>>>
>>> # of expected passes140663
>>> # of unexpected failures7932
>>> # of unexpected successes   21
>>> # of expected failures  620
>>> # of unresolved testcases   8603
>>> # of unsupported tests  11305
>>>
>>> =
>>> pipcet/avr-ccmode
>>>
>>> === gcc Summary ===
>>>
>>> # of expected passes87463
>>> # of unexpected failures1221
>>> # of unexpected successes   15
>>> # of expected failures  581
>>> # of unresolved testcases   16799
>>> # of unsupported tests  5359
>>>
>>> === g++ Summary ===
>>>
>>> # of expected passes140529
>>> # of unexpected failures8205
>>> # of unexpected successes   21
>>> # of expected failures  620
>>> # of unresolved testcases   8607
>>> # of unsupported tests  11301
>>>
>>> =
>>> saadhu/avr-cc0
>>>
>>> === gcc Summary ===
>>>
>>> # of expected passes87504
>>> # of unexpected failures1105
>>> # of unexpected successes   15
>>> # of expected failures  581
>>> # of unresolved testcases   16786
>>> # of unsupported tests  5370
>>>
>>> === g++ Summary ===
>>>
>>> # of expected passes140663
>>> # of unexpected failures7932
>>> # of unexpected successes   21
>>> # of expected failures  620
>>> # of unresolved testcases   8603
>>> # of unsupported tests  11305
>>>
>>> On a side note, I build and test AVR backend in mainline everyday. If
>>> there is interest from AVR maintainers I can post daily results to
>>> gcc-testresults@ mailing list.
>> I'd appreciate such postings, not necessarily daily (if there are no
>> changes). Also (as usual) for active release branches (say once a week or
>> biweekly or even monthly).
> I'll start sending biweekly the AVR testresults from all active branches.
>
> Yesterday my test results were temporarily held back due to large email size, 
> but eventually reached gcc-testresults@ . I'd like to know if I need to trim 
> them somehow.
You might consider using contrib/compare_tests rather than dumping the
entire results to the list.  compare_tests focuses on things that
changed from one run to the next.  So you need to keep the results from
the prior run for comparison purposes.

Jeff

Re: V3 [PATCH 1/2] Switch to a new section if the SECTION_RETAIN bit doesn't match

[Jeff Law via Gcc-patches]

On 12/8/20 5:51 AM, H.J. Lu wrote:
> When definitions marked with used attribute and unmarked definitions are
> placed in the section with the same name, switch to a new section if the
> SECTION_RETAIN bit doesn't match.
>
> gcc/
>
>   PR target/98146
>   * output.h (switch_to_section): Add a tree argument, default to
>   nullptr.
>   * varasm.c (get_section): If the SECTION_RETAIN bit doesn't match,
>   return and switch to a new section later.
>   (assemble_start_function): Pass decl to switch_to_section.
>   (assemble_variable): Likewise.
>   (switch_to_section): If the SECTION_RETAIN bit doesn't match,
>   switch to a new section.
>
> gcc/testsuite/
>
>   PR target/98146
>   * c-c++-common/attr-used-5.c: New test.
>   * c-c++-common/attr-used-6.c: Likewise.
>   * c-c++-common/attr-used-7.c: Likewise.
>   * c-c++-common/attr-used-8.c: Likewise.
>   * c-c++-common/attr-used-9.c: Likewise.
> ---
>  gcc/output.h |  2 +-
>  gcc/testsuite/c-c++-common/attr-used-5.c | 26 
>  gcc/testsuite/c-c++-common/attr-used-6.c | 26 
>  gcc/testsuite/c-c++-common/attr-used-7.c |  8 +++
>  gcc/testsuite/c-c++-common/attr-used-8.c |  8 +++
>  gcc/testsuite/c-c++-common/attr-used-9.c | 28 ++
>  gcc/varasm.c | 30 
>  7 files changed, 123 insertions(+), 5 deletions(-)
>  create mode 100644 gcc/testsuite/c-c++-common/attr-used-5.c
>  create mode 100644 gcc/testsuite/c-c++-common/attr-used-6.c
>  create mode 100644 gcc/testsuite/c-c++-common/attr-used-7.c
>  create mode 100644 gcc/testsuite/c-c++-common/attr-used-8.c
>  create mode 100644 gcc/testsuite/c-c++-common/attr-used-9.c
>
>
> diff --git a/gcc/varasm.c b/gcc/varasm.c
> index 0fac3688828..c5ea29c4e4c 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -342,6 +342,11 @@ get_section (const char *name, unsigned int flags, tree 
> decl,
> sect->common.flags |= (SECTION_WRITE | SECTION_RELRO);
> return sect;
>   }
> +   /* If the SECTION_RETAIN bit doesn't match, return and switch
> +  to a new section later.  */
> +   if ((sect->common.flags & SECTION_RETAIN)
> +   != (flags & SECTION_RETAIN))
> + return sect;
At the least you need to fix the function comment as it would no longer
match the behavior in this case.  It also seems to me that having
SECTION_RETAIN be a special case like this just seems wrong.   In my
mind there isn't anything fundamentally different with SECTION_RETAIN vs
other symbols that it deserves to be special cased like this.

Clearly we need to fix something as these bits are causing significant
fallout, but I'm just not sure what the right fix ought to be.

jeff

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Tulio Magno Quites Machado Filho via Gcc-patches]

Jonathan Wakely  writes:

>>Hmm, yes, you pointed me to __frexpieee128 a few months ago, but for
>>some reason I either didn't switch to using it, or lost a patch when
>>squashing and rebasing branches. Hopefully I just forgot to change it,
>>but I'll double check to make sure I haven't left any work on an old
>>branch. Thanks for suggesting it (again!)
>
> As expected, it still works with a check for __frexpieee128 instead.
>
> So are you happy for me to push this to master with that change?

LGTM.
I have no objections.

Thank you!

-- 
Tulio Magno

Re: rs6000: add support for powerpc64le-unknown-freebsd

[Segher Boessenkool]

On Tue, Dec 15, 2020 at 12:29:45AM +0100, Gerald Pfeifer wrote:
> On Mon, 14 Dec 2020, Segher Boessenkool wrote:
> >> +  powerpc*le-*-*)
> >> +  tm_file="${tm_file} rs6000/sysv4le.h" ;;
> >> +  esac
> > What an obvious filename ;-)
> 
> ;-)
> 
> > The patch looks fine.  Okay for trunk.  Also okay for any backports you 
> > want (after waiting to see if it creates problems on trunk, as usual).
> 
> Thank you! Segher doesn't have write access, and usually I'd help out,
> alas autoconf in GCC-land and me are, um, slightly divergent.

Piotr doesn't have write access, I think you mean :-)

> Any chance (one of you) can help and commit this?

I'll commit it tomorrow morning, it's too late right now for me to trust
myself doing a commit correctly.

> To make this easier, I've created a proposal for a full ChangeLog 
> entry. :-)

Thanks!  Even less work :-)


Segher

Re: rs6000: add support for powerpc64le-unknown-freebsd

[Piotr Kubaj via Gcc-patches]

Yes, there is, thanks for noticing that!

Fixed patch attached.

On 20-12-15 00:37:02, Gerald Pfeifer wrote:
> On Mon, 14 Dec 2020, Piotr Kubaj via Gcc-patches wrote:
> > --- gcc/configure.ac.orig   2020-12-14 15:22:23 UTC
> > +++ gcc/configure.ac
> > @@ -5874,6 +5874,8 @@ case "$target:$tm_file" in
> >  *-*-linux*)
> >  emul_name="-melf64ppc"
> >   ;;
> >+ *le-*-freebsd*)
> >+ emul_name="-melf64lppc_fbsd"
> >  *-*-freebsd*)
> >  emul_name="-melf64ppc_fbsd"
> >   ;;
> 
> Is there a ;; missing to terminate the *le-*-freebsd* entry?
> 
> (Or am I missing some subtlety of /bin/sh ?)
> 
> Gerald
> 

-- 
--- gcc/config.gcc.orig	2020-12-07 03:00:29 UTC
+++ gcc/config.gcc
@@ -2868,6 +2868,10 @@ powerpc*-*-freebsd*)
 	extra_options="${extra_options} rs6000/sysv4.opt"
 	tmake_file="rs6000/t-fprules rs6000/t-ppcos ${tmake_file} rs6000/t-ppccomm"
 	case ${target} in
+	powerpc*le-*-*)
+		tm_file="${tm_file} rs6000/sysv4le.h" ;;
+	esac
+	case ${target} in
 	 powerpc64*)
 		tm_file="${tm_file} rs6000/default64.h rs6000/freebsd64.h"
 		tmake_file="${tmake_file} rs6000/t-freebsd64"
--- gcc/config/rs6000/freebsd64.h.orig	2020-07-23 06:35:17 UTC
+++ gcc/config/rs6000/freebsd64.h
@@ -158,8 +157,8 @@ extern int dot_symbols;
 #define ASM_SPEC64 "-a64"
 
 #define ASM_SPEC_COMMON "%(asm_cpu) \
-%{,assembler|,assembler-with-cpp: %{mregnames} %{mno-regnames}} \
-%{mlittle} %{mlittle-endian} %{mbig} %{mbig-endian}"
+%{,assembler|,assembler-with-cpp: %{mregnames} %{mno-regnames}}" \
+  ENDIAN_SELECT(" -mbig", " -mlittle", DEFAULT_ASM_ENDIAN)
 
 #undef	SUBSUBTARGET_EXTRA_SPECS
 #define SUBSUBTARGET_EXTRA_SPECS	\
@@ -181,9 +180,15 @@ extern int dot_symbols;
 %{static:-Bstatic}} \
   %{symbolic:-Bsymbolic}"
 
+#undef  DEFAULT_ASM_ENDIAN
 #define LINK_OS_FREEBSD_SPEC32 "-melf32ppc_fbsd " LINK_OS_FREEBSD_SPEC_DEF
-  
+#if (TARGET_DEFAULT & MASK_LITTLE_ENDIAN)
+#define DEFAULT_ASM_ENDIAN " -mlittle"
+#define LINK_OS_FREEBSD_SPEC64 "-melf64lppc_fbsd " LINK_OS_FREEBSD_SPEC_DEF
+#else
+#define DEFAULT_ASM_ENDIAN " -mbig"
 #define LINK_OS_FREEBSD_SPEC64 "-melf64ppc_fbsd " LINK_OS_FREEBSD_SPEC_DEF
+#endif
 
 #undef	MULTILIB_DEFAULTS
 #define MULTILIB_DEFAULTS { "m64" }
--- gcc/configure.ac.orig	2020-12-14 15:22:23 UTC
+++ gcc/configure.ac
@@ -5874,6 +5874,9 @@ case "$target:$tm_file" in
  *-*-linux*)
  emul_name="-melf64ppc"
   ;;
+ *le-*-freebsd*)
+ emul_name="-melf64lppc_fbsd"
+  ;;
  *-*-freebsd*)
  emul_name="-melf64ppc_fbsd"
   ;;


signature.asc
Description: PGP signature

Re: [committed][wwwdocs] gcc-11/changes: "used" attribute saves decls from linker garbage collection

[Gerald Pfeifer]

On Mon, 7 Dec 2020, Jozef Lawrynowicz wrote:
> Committed as obvious.

Thank you!

+  
+For ELF targets that support the GNU or FreeBSD OSABIs, the
+used attribute will now save the symbol declaration it is
+applied to from linker garbage collection.
+
+To support this behavior, used symbols that have not
+been placed in specific sections (e.g. with the section
+attribute, or the -f{function,data}-sections options) will
+be placed in new, unique sections.
+
+This functionality requires Binutils version 2.36 or later.
+  

Have you considered using ... around the three blocks of
text instead of  in between?

An open question, it's okay to keep as is if you prefer.

Gerald

Re: [wwwdocs] Document new Hardware-assisted AddressSanitizer

[Gerald Pfeifer]

On Mon, 14 Dec 2020, Matthew Malcomson via Gcc-patches wrote:
> gcc-11/changes: Document new Hardware-assisted AddressSanitizer.
> 
> I have put it in the "general" section rather than AArch64 since the 
> feature does add a general framework, so I believe the news is 
> interesting for people interesting in architectures other than AArch64 
> that may want to implement this for their own targets (where possible).

This makes sense (and looks useful), thank you!


Some minor nits; the patch is fine with few changes:

> +Introduce  href="http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html;>

I recommend to make this and the ohter links https; clang.llvm.org
does not redirect from http to https, but offers both.

> +provides probabilistic protection to use less RAM at runtime.

"run time"

(Per https://gcc.gnu.org/codingconventions.html#Spelling we use that
for the noun, and "run-time" for the adjective in that case; "runtime"
for libraries and system support.)

> +  Hardware-assisted AddressSanitizer is not production-ready 
>   for userspace, and is

"user space" (and the line appears quite a bit long)

Cheers,
Gerald

Re: rs6000: add support for powerpc64le-unknown-freebsd

[Gerald Pfeifer]

On Mon, 14 Dec 2020, Piotr Kubaj via Gcc-patches wrote:
> --- gcc/configure.ac.orig   2020-12-14 15:22:23 UTC
> +++ gcc/configure.ac
> @@ -5874,6 +5874,8 @@ case "$target:$tm_file" in
>  *-*-linux*)
>  emul_name="-melf64ppc"
>   ;;
>+ *le-*-freebsd*)
>+ emul_name="-melf64lppc_fbsd"
>  *-*-freebsd*)
>  emul_name="-melf64ppc_fbsd"
>   ;;

Is there a ;; missing to terminate the *le-*-freebsd* entry?

(Or am I missing some subtlety of /bin/sh ?)

Gerald

Re: rs6000: add support for powerpc64le-unknown-freebsd

[Gerald Pfeifer]

On Mon, 14 Dec 2020, Segher Boessenkool wrote:
>> +powerpc*le-*-*)
>> +tm_file="${tm_file} rs6000/sysv4le.h" ;;
>> +esac
> What an obvious filename ;-)

;-)

> The patch looks fine.  Okay for trunk.  Also okay for any backports you 
> want (after waiting to see if it creates problems on trunk, as usual).

Thank you! Segher doesn't have write access, and usually I'd help out,
alas autoconf in GCC-land and me are, um, slightly divergent.

Any chance (one of you) can help and commit this?


To make this easier, I've created a proposal for a full ChangeLog 
entry. :-)

2020-12-15  Piotr Kubaj   
 
* config.gcc (powerpc*le-*-freebsd*): Add. 
* configure.ac (powerpc*le-*-freebsd*): Ditto. 
* config/rs6000/freebsd64.h (ASM_SPEC_COMMON): Use ENDIAN_SELECT. 
(DEFAULT_ASM_ENDIAN): Add little endian support. 
(LINK_OS_FREEBSD_SPEC64): Ditto. 

Thank you,
Gerald

Re: [PATCH 2/3] PowerPC: require IBM long double for pr70117.

[Segher Boessenkool]

Hi!

On Thu, Dec 03, 2020 at 10:57:56PM -0500, Michael Meissner wrote:
> --- a/gcc/testsuite/gcc.target/powerpc/pr70117.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
> @@ -1,5 +1,6 @@
> -/* { dg-do run { target { powerpc*-*-linux* powerpc*-*-darwin* 
> powerpc*-*-aix* rs6000-*-* } } } */
> -/* { dg-options "-std=c99 -mlong-double-128 -O2" } */
> +/* { dg-do run } */
> +/* { dg-require-effective-target ppc_long_double_override_ibm } */
> +/* { dg-options "-std=c99 -O2 -mlong-double-128 -mabi=ibmlongdouble 
> -Wno-psabi" } */


So we probably really want some add_options_for_ thing, and use that
everywhere else?


Before this patch you did not test for anything printf (or glibc at
all); why is that suddenly necessary?


Segher

Re: [PATCH] correct -Wmismatched-new-delete (PR 98160, 98166)

[Jeff Law via Gcc-patches]

On 12/14/20 2:05 PM, Martin Sebor wrote:
> On 12/13/20 10:23 AM, Jeff Law wrote:
>>
>>
>> On 12/8/20 1:46 PM, Martin Sebor wrote:
>>> PR 98160 reports an ICE in pretty printer code called from the newly
>>> added -Wmismatched-new-delete.  The ICE is just a simple oversight,
>>> but much more interesting is the warning issued for the test case.
>>> It highlights an issue I didn't consider in the initial implementation:
>>> that inlining one of a pair of allocation/deallocation functions but
>>> not the other might lead to false positives when the inlined function
>>> calls another allocator that the deallocator isn't associated with.
>>>
>>> In addition, tests for the changes exposed the overly simplistic
>>> nature of the detection of calls to mismatched forms of operator
>>> new and delete which fails to consider member operators, also
>>> resulting in false positives.
>>>
>>> Finally, in a comment on the initial implementation Jonathan notes
>>> that the -Wmismatched-new-delete warning should trigger not only
>>> in user code but also in libstdc++ functions inlined into user code.
>>> I thought I had done that but as it turns out, the "standard code
>>> sequence" I put in place isn't sufficient to make this work.
>>>
>>> The attached changes avoid the false positives a) by ignoring (with
>>> a warning) the new form of the malloc attribute on inline functions,
>>> and disabling the inlining of others by implicitly adding attribute
>>> noinline to their declaration, and b) by making more robust
>>> the detection of mismatched operators new and delete.  Furthermore,
>>> the patch also arranges for the warning to trigger even for inlined
>>> calls to functions defined in system headers.
>>>
>>> To make review a little (marginally) easier the change are two files:
>>> 1) gcc-98166-1.diff: introduces valid_new_delete_pair_p and
>>> tree_inlined_location.
>>> 2) gcc-98166-2.diff: adjusts the atrribute/warning implementation .
>>>
>>> Tested on x86_64-linux.
>>>
>>> Martin
>>>
>>> gcc-98166-1.diff
>>>
>>> Introduce an overload of valid_new_delete_pair_p and
>>> tree_inlined_location.
>>>
>>> gcc/ChangeLog:
>>>
>>> * tree-ssa-dce.c (valid_new_delete_pair_p): Factor code out into
>>> valid_new_delete_pair_p in tree.c.
>>> * tree.c (tree_inlined_location): Define new function.
>>> (valid_new_delete_pair_p): Define.
>>> * tree.h (tree_inlined_location): Declare.
>>> (valid_new_delete_pair_p): Declare.
>> OK
>>
>>
>>>
>>> gcc-98166-2.diff
>>>
>>> Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR
>>> c++/57111, PR middle-end/98160).
>>>
>>> Resolves:
>>> PR middle-end/98166 - bogus -Wmismatched-dealloc on user-defined
>>> allocator and inlining
>>> PR c++/57111 - 57111 - Generalize -Wfree-nonheap-object to delete
>>> PR middle-end/98160 - ICE in default_tree_printer at
>>> gcc/tree-diagnostic.c:270
>>>
>>> gcc/ChangeLog:
>>>
>>> PR middle-end/98166
>>> PR c++/57111
>>> PR middle-end/98160
>>> * builtins.c (call_dealloc_p): Remove unused function.
>>> (new_delete_mismatch_p): Call valid_new_delete_pair_p and rework.
>>> (matching_alloc_calls_p): Handle built-in deallocation functions.
>>> (warn_dealloc_offset): Corrct the handling of user-defined
>>> operators
>>> delete.
>>> (maybe_emit_free_warning): Avoid assuming expression is a decl.
>>> Simplify.
>>> * doc/extend.texi (attribute malloc): Update.
>>>
>>> gcc/c-family/ChangeLog:
>>>
>>> PR middle-end/98166
>>> PR c++/57111
>>> PR middle-end/98160
>>> * c-attribs.c (handle_malloc_attribute): Implicitly add attribute
>>> noinline to functions not declared inline and warn on those.
>>>
>>> libstdc++-v3/ChangeLog:
>>> * testsuite/ext/vstring/requirements/exception/basic.cc: Suppress
>>> a false positive warning.
>>> *
>>> testsuite/ext/vstring/requirements/exception/propagation_consistent.cc:
>>>   Same.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> PR middle-end/98166
>>> PR c++/57111
>>> PR middle-end/98160
>>> * g++.dg/warn/Wmismatched-dealloc-2.C: Adjust test of expected
>>> warning.
>>> * g++.dg/warn/Wmismatched-new-delete.C: Same.
>>> * gcc.dg/Wmismatched-dealloc.c: Same.
>>> * c-c++-common/Wfree-nonheap-object-2.c: New test.
>>> * c-c++-common/Wfree-nonheap-object-3.c: New test.
>>> * c-c++-common/Wfree-nonheap-object.c: New test.
>>> * c-c++-common/Wmismatched-dealloc.c: New test.
>>> * g++.dg/warn/Wfree-nonheap-object-3.C: New test.
>>> * g++.dg/warn/Wfree-nonheap-object-4.C: New test.
>>> * g++.dg/warn/Wmismatched-new-delete-2.C: New test.
>> OK, but there's a follow-up as noted below:
>>
>>
>>>
>>>   diff --git a/gcc/testsuite/g++.dg/warn/Wmismatched-dealloc-2.C
>>> b/gcc/testsuite/g++.dg/warn/Wmismatched-dealloc-2.C
>>> index 7ecc99a325c..3aea02fa63d 100644
>>> --- a/gcc/testsuite/g++.dg/warn/Wmismatched-dealloc-2.C
>>> +++ b/gcc/testsuite/g++.dg/warn/Wmismatched-dealloc-2.C
>> Please fix 

[PATCH, rs6000] Don't set MMA prefixed instruction length to 8

[Pat Haugen via Gcc-patches]

Fix instruction length for MMA insns.


Prefixed instructions should not have their length explicitly set to '8'. The 
function get_attr_length() will adjust the length appropriately based on the 
value of the "prefixed" attribute.

Bootstrap/regtest on powerpc64le (Power8/Power10) with no new regressions. Ok 
for trunk?

-Pat


2020-12-14  Pat Haugen  

gcc/
* config/rs6000/mma.md (*movxo, mma_, mma_,
mma_, mma_, mma_, mma_,
mma_, mma_, mma_, mma_):
Remove explicit setting of length attribute.
diff --git a/gcc/config/rs6000/mma.md b/gcc/config/rs6000/mma.md
index 4d291c42f7a..ef4394416b6 100644
--- a/gcc/config/rs6000/mma.md
+++ b/gcc/config/rs6000/mma.md
@@ -318,7 +318,7 @@ (define_insn_and_split "*movxo"
   DONE;
 }
   [(set_attr "type" "vecload,vecstore,veclogical")
-   (set_attr "length" "8,8,16")
+   (set_attr "length" "*,*,16")
(set_attr "max_prefixed_insns" "2,2,*")])
 
 (define_expand "mma_assemble_pair"
@@ -539,8 +539,7 @@ (define_insn "mma_"
MMA_VVI4I4I8))]
   "TARGET_MMA"
   " %A0,%x1,%x2,%3,%4,%5"
-  [(set_attr "type" "mma")
-   (set_attr "length" "8")])
+  [(set_attr "type" "mma")])
 
 (define_insn "mma_"
   [(set (match_operand:XO 0 "fpr_reg_operand" "=")
@@ -553,8 +552,7 @@ (define_insn "mma_"
MMA_AVVI4I4I8))]
   "TARGET_MMA"
   " %A0,%x2,%x3,%4,%5,%6"
-  [(set_attr "type" "mma")
-   (set_attr "length" "8")])
+  [(set_attr "type" "mma")])
 
 (define_insn "mma_"
   [(set (match_operand:XO 0 "fpr_reg_operand" "=")
@@ -566,8 +564,7 @@ (define_insn "mma_"
MMA_VVI4I4I2))]
   "TARGET_MMA"
   " %A0,%x1,%x2,%3,%4,%5"
-  [(set_attr "type" "mma")
-   (set_attr "length" "8")])
+  [(set_attr "type" "mma")])
 
 (define_insn "mma_"
   [(set (match_operand:XO 0 "fpr_reg_operand" "=")
@@ -580,8 +577,7 @@ (define_insn "mma_"
MMA_AVVI4I4I2))]
   "TARGET_MMA"
   " %A0,%x2,%x3,%4,%5,%6"
-  [(set_attr "type" "mma")
-   (set_attr "length" "8")])
+  [(set_attr "type" "mma")])
 
 (define_insn "mma_"
   [(set (match_operand:XO 0 "fpr_reg_operand" "=")
@@ -592,8 +588,7 @@ (define_insn "mma_"
MMA_VVI4I4))]
   "TARGET_MMA"
   " %A0,%x1,%x2,%3,%4"
-  [(set_attr "type" "mma")
-   (set_attr "length" "8")])
+  [(set_attr "type" "mma")])
 
 (define_insn "mma_"
   [(set (match_operand:XO 0 "fpr_reg_operand" "=")
@@ -605,8 +600,7 @@ (define_insn "mma_"
MMA_AVVI4I4))]
   "TARGET_MMA"
   " %A0,%x2,%x3,%4,%5"
-  [(set_attr "type" "mma")
-   (set_attr "length" "8")])
+  [(set_attr "type" "mma")])
 
 (define_insn "mma_"
   [(set (match_operand:XO 0 "fpr_reg_operand" "=")
@@ -617,8 +611,7 @@ (define_insn "mma_"
MMA_PVI4I2))]
   "TARGET_MMA"
   " %A0,%x1,%x2,%3,%4"
-  [(set_attr "type" "mma")
-   (set_attr "length" "8")])
+  [(set_attr "type" "mma")])
 
 (define_insn "mma_"
   [(set (match_operand:XO 0 "fpr_reg_operand" "=")
@@ -630,8 +623,7 @@ (define_insn "mma_"
MMA_APVI4I2))]
   "TARGET_MMA"
   " %A0,%x2,%x3,%4,%5"
-  [(set_attr "type" "mma")
-   (set_attr "length" "8")])
+  [(set_attr "type" "mma")])
 
 (define_insn "mma_"
   [(set (match_operand:XO 0 "fpr_reg_operand" "=")
@@ -643,8 +635,7 @@ (define_insn "mma_"
MMA_VVI4I4I4))]
   "TARGET_MMA"
   " %A0,%x1,%x2,%3,%4,%5"
-  [(set_attr "type" "mma")
-   (set_attr "length" "8")])
+  [(set_attr "type" "mma")])
 
 (define_insn "mma_"
   [(set (match_operand:XO 0 "fpr_reg_operand" "=")
@@ -657,5 +648,4 @@ (define_insn "mma_"
MMA_AVVI4I4I4))]
   "TARGET_MMA"
   " %A0,%x2,%x3,%4,%5,%6"
-  [(set_attr "type" "mma")
-   (set_attr "length" "8")])
+  [(set_attr "type" "mma")])

Re: [PATCH] Fix _GLIBCXX_DEBUG tests

[François Dumont via Gcc-patches]

On 14/12/20 11:08 am, Jonathan Wakely wrote:



On Mon, 14 Dec 2020, 06:51 François Dumont via Libstdc++, 
mailto:libstdc%2b...@gcc.gnu.org>> wrote:


On 13/12/20 11:17 pm, Jonathan Wakely wrote:
> On 13/12/20 15:52 +0100, François Dumont via Libstdc++ wrote:
>> Some tests are XPASS because array assertions have been
disabled for
>> a good reason in C++11.
>>
>> I wonder if the respective non-constexpr _GLIBCXX_ASSERTION checks
>> shouldn't target C++14 too. At the moment they are failing as
>> expected but because of an Undefined Behavior no ?
>
> Hmm, maybe my "fix" for the bug was too hasty, and I should have
done
> this instead:
>
> --- a/libstdc++-v3/include/bits/c++config
> +++ b/libstdc++-v3/include/bits/c++config
> @@ -684,7 +684,7 @@ namespace std
>
>  #undef _GLIBCXX_HAS_BUILTIN
>
> -#if _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED
> +#if _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED && __cplusplus >=
> 201402L
>  # define __glibcxx_assert_1(_Condition)    \
>  if (__builtin_is_constant_evaluated()) \
>   { \
>
> That would allow us to keep the std::array runtime assertions for
> C++11, and only disable them in constexpr contexts.

I already tried to restore this check in C++11 runtime without
success
but I didn't try this approach.

I'll have a try but C++11 forces constexpr to be just a return
statement
so I fear that it won't appreciate the additional assertion.



Ah yes, we'd need something like Daniel suggested, and it's not worth 
it just for C++11.


Just limiting the tests to c++14 is fine.



Attached patch committed then.

François

diff --git a/libstdc++-v3/testsuite/23_containers/array/debug/back1_neg.cc b/libstdc++-v3/testsuite/23_containers/array/debug/back1_neg.cc
index 8216dea3cfb..ca3172e9e39 100644
--- a/libstdc++-v3/testsuite/23_containers/array/debug/back1_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/array/debug/back1_neg.cc
@@ -16,7 +16,7 @@
 // .
 //
 // { dg-options "-D_GLIBCXX_ASSERTIONS" }
-// { dg-do run { target c++11 xfail *-*-* } }
+// { dg-do run { target c++14 xfail *-*-* } }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/23_containers/array/debug/front1_neg.cc b/libstdc++-v3/testsuite/23_containers/array/debug/front1_neg.cc
index c6871093d2a..0f102103fe5 100644
--- a/libstdc++-v3/testsuite/23_containers/array/debug/front1_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/array/debug/front1_neg.cc
@@ -16,7 +16,7 @@
 // .
 //
 // { dg-options "-D_GLIBCXX_ASSERTIONS" }
-// { dg-do run { target c++11 xfail *-*-* } }
+// { dg-do run { target c++14 xfail *-*-* } }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/23_containers/array/debug/square_brackets_operator1_neg.cc b/libstdc++-v3/testsuite/23_containers/array/debug/square_brackets_operator1_neg.cc
index 3f1ea128902..130325620e8 100644
--- a/libstdc++-v3/testsuite/23_containers/array/debug/square_brackets_operator1_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/array/debug/square_brackets_operator1_neg.cc
@@ -16,7 +16,7 @@
 // .
 //
 // { dg-options "-D_GLIBCXX_ASSERTIONS" }
-// { dg-do run { target c++11  xfail *-*-* } }
+// { dg-do run { target c++14 xfail *-*-* } }
 
 #include 
 

c++: module-related tweak

[Nathan Sidwell]

In manually applying a name-lookup patch, I managed to transpose two 
calls.  That caused a test failure.  Fixed thusly.


gcc/cp/
* name-lookup.c (do_namespace_alias): Set originating module
before pushing.

pushing to trunk
--
Nathan Sidwell
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 03d2bc5984b..ab669bcb720 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -6223,10 +6223,10 @@ do_namespace_alias (tree alias, tree name_space)
   DECL_NAMESPACE_ALIAS (alias) = name_space;
   DECL_EXTERNAL (alias) = 1;
   DECL_CONTEXT (alias) = FROB_CONTEXT (current_scope ());
-  pushdecl (alias);
-
   set_originating_module (alias);
 
+  pushdecl (alias);
+
   /* Emit debug info for namespace alias.  */
   if (!building_stmt_list_p ())
 (*debug_hooks->early_global_decl) (alias);

Re: [PATCH] ira.c: Fix ICE in ira-color [PR97092]

[Vladimir Makarov via Gcc-patches]

On 2020-12-14 11:23 a.m., Andrea Corallo wrote:

Vladimir Makarov  writes:


On 2020-12-10 10:12 a.m., Andrea Corallo wrote:

Hi all,

following discussion on PR97092 I'd like to submit the following patch
with a fix plus associated testcase.

With this patch applied mode is recomputed at each iteration while
looping across different copies in 'update_costs_from_allocno', this
instead of carrying mode over subsequent iterations.

bootstrapped and regtested on aarch64-unknown-linux-gnu.

Okay for trunk?


Yes.

The patch is safe.. Thank you for working on the PR.

Hi Vladimir,

the same patch cleanly applies on gcc-10 where the same bug is present.

I bootstrapped and regtested gcc-10 on aarch64-unknown-linux-gnu.

Is it okay to backport?


Yes.

Thank you.

Re: [PATCH] correct -Wmismatched-new-delete (PR 98160, 98166)

[Martin Sebor via Gcc-patches]

On 12/13/20 10:23 AM, Jeff Law wrote:



On 12/8/20 1:46 PM, Martin Sebor wrote:

PR 98160 reports an ICE in pretty printer code called from the newly
added -Wmismatched-new-delete.  The ICE is just a simple oversight,
but much more interesting is the warning issued for the test case.
It highlights an issue I didn't consider in the initial implementation:
that inlining one of a pair of allocation/deallocation functions but
not the other might lead to false positives when the inlined function
calls another allocator that the deallocator isn't associated with.

In addition, tests for the changes exposed the overly simplistic
nature of the detection of calls to mismatched forms of operator
new and delete which fails to consider member operators, also
resulting in false positives.

Finally, in a comment on the initial implementation Jonathan notes
that the -Wmismatched-new-delete warning should trigger not only
in user code but also in libstdc++ functions inlined into user code.
I thought I had done that but as it turns out, the "standard code
sequence" I put in place isn't sufficient to make this work.

The attached changes avoid the false positives a) by ignoring (with
a warning) the new form of the malloc attribute on inline functions,
and disabling the inlining of others by implicitly adding attribute
noinline to their declaration, and b) by making more robust
the detection of mismatched operators new and delete.  Furthermore,
the patch also arranges for the warning to trigger even for inlined
calls to functions defined in system headers.

To make review a little (marginally) easier the change are two files:
1) gcc-98166-1.diff: introduces valid_new_delete_pair_p and
tree_inlined_location.
2) gcc-98166-2.diff: adjusts the atrribute/warning implementation .

Tested on x86_64-linux.

Martin

gcc-98166-1.diff

Introduce an overload of valid_new_delete_pair_p and tree_inlined_location.

gcc/ChangeLog:

* tree-ssa-dce.c (valid_new_delete_pair_p): Factor code out into
valid_new_delete_pair_p in tree.c.
* tree.c (tree_inlined_location): Define new function.
(valid_new_delete_pair_p): Define.
* tree.h (tree_inlined_location): Declare.
(valid_new_delete_pair_p): Declare.

OK




gcc-98166-2.diff

Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR c++/57111, PR 
middle-end/98160).

Resolves:
PR middle-end/98166 - bogus -Wmismatched-dealloc on user-defined allocator and 
inlining
PR c++/57111 - 57111 - Generalize -Wfree-nonheap-object to delete
PR middle-end/98160 - ICE in default_tree_printer at gcc/tree-diagnostic.c:270

gcc/ChangeLog:

PR middle-end/98166
PR c++/57111
PR middle-end/98160
* builtins.c (call_dealloc_p): Remove unused function.
(new_delete_mismatch_p): Call valid_new_delete_pair_p and rework.
(matching_alloc_calls_p): Handle built-in deallocation functions.
(warn_dealloc_offset): Corrct the handling of user-defined operators
delete.
(maybe_emit_free_warning): Avoid assuming expression is a decl.
Simplify.
* doc/extend.texi (attribute malloc): Update.

gcc/c-family/ChangeLog:

PR middle-end/98166
PR c++/57111
PR middle-end/98160
* c-attribs.c (handle_malloc_attribute): Implicitly add attribute
noinline to functions not declared inline and warn on those.

libstdc++-v3/ChangeLog:
* testsuite/ext/vstring/requirements/exception/basic.cc: Suppress
a false positive warning.
* 
testsuite/ext/vstring/requirements/exception/propagation_consistent.cc:
  Same.

gcc/testsuite/ChangeLog:

PR middle-end/98166
PR c++/57111
PR middle-end/98160
* g++.dg/warn/Wmismatched-dealloc-2.C: Adjust test of expected warning.
* g++.dg/warn/Wmismatched-new-delete.C: Same.
* gcc.dg/Wmismatched-dealloc.c: Same.
* c-c++-common/Wfree-nonheap-object-2.c: New test.
* c-c++-common/Wfree-nonheap-object-3.c: New test.
* c-c++-common/Wfree-nonheap-object.c: New test.
* c-c++-common/Wmismatched-dealloc.c: New test.
* g++.dg/warn/Wfree-nonheap-object-3.C: New test.
* g++.dg/warn/Wfree-nonheap-object-4.C: New test.
* g++.dg/warn/Wmismatched-new-delete-2.C: New test.

OK, but there's a follow-up as noted below:




  
diff --git a/gcc/testsuite/g++.dg/warn/Wmismatched-dealloc-2.C b/gcc/testsuite/g++.dg/warn/Wmismatched-dealloc-2.C

index 7ecc99a325c..3aea02fa63d 100644
--- a/gcc/testsuite/g++.dg/warn/Wmismatched-dealloc-2.C
+++ b/gcc/testsuite/g++.dg/warn/Wmismatched-dealloc-2.C

Please fix the non-unique testnames in this file.  This can be done as a
separate follow-up patch as they're pre-existing.

diff --git a/gcc/testsuite/g++.dg/warn/Wmismatched-new-delete.C
b/gcc/testsuite/g++.dg/warn/Wmismatched-new-delete.C

index ed1090be5c5..fc07149995d 100644
--- a/gcc/testsuite/g++.dg/warn/Wmismatched-new-delete.C
+++ 

Re: [PATCH 1/3] PowerPC: Add long double target-supports.

[Segher Boessenkool]

On Thu, Dec 03, 2020 at 11:06:12PM -0500, Michael Meissner wrote:
> +proc check_effective_target_ppc_long_double_ibm { } {
> +return [check_cached_effective_target ppc_long_double_ibm {
> + int main()
> + {
> +   #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IBM128__)
> + return 1;
> +   #else
> + return 0;
> +   #endif
> + }
> +}]
> +}

OK.

> +proc check_effective_target_ppc_long_double_ieee { } {
> +return [check_cached_effective_target ppc_long_double_ieee {
> + int main()
> + {
> +   #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IEEE128__)
> + return 1;
> +   #else
> + return 0;
> +   #endif
> + }
> +}]
> +}

OK.

These names could be without "_ppc", if the functions were defined more
generically.  It's not clear that will be useful right now though.

> +# Like check_effective_target_ppc_long_double_ibm, but check if we can
> +# explicitly override the long double format to use the IBM 128-bit extended
> +# double format, and GLIBC supports doing this override by switching the
> +# sprintf to handle long double.

This comment needs work.

> +proc check_effective_target_ppc_long_double_override_ibm { } {
> +set options "-mlong-double-128 -mabi=ibmlongdouble -Wno-psabi"
> +check_runtime_nocache ppc_long_double_ovveride_ibm {

It is spelled "override".

> + #include 
> + #include 
> + volatile __ibm128 a = (__ibm128) 3.0;
> + volatile long double one = 1.0L;
> + volatile long double two = 2.0L;
> + volatile long double b;
> + char buffer[20];
> + int main()
> + {
> +   #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IBM128__)
> + return 1;
> +   #else
> + b = one + two;
> + if (memcmp ((void *), (void *), sizeof (long double)) != 0)

The pointer casts are unnecessary, and can be harmful.

You should use  sizeof(b)  , and check that  sizeof(a) == sizeof(b)  .

> +   return 1;
> + sprintf (buffer, "%lg", b);
> + return strcmp (buffer, "3") != 0;
> +   #endif
> + }
> +} $options
> +}

The name of this should say it is something to do with libc, or even
glibc in fact ("lg" is not portable), and with text output.

> +# Like check_effective_target_ppc_long_double_ieee, but check if we can
> +# explicitly override the long double format to use the IEEE 128-bit format,
> +# and GLIBC supports doing this override by switching the sprintf to handle
> +# long double.
> +
> +proc check_effective_target_ppc_long_double_override_ieee { } {
> +set options "-mlong-double-128 -mabi=ieeelongdouble -Wno-psabi"
> +check_runtime_nocache ppc_long_double_ovveride_ieee {
> + #include 
> + #include 
> + volatile _Float128 a = 3.0f128;
> + volatile long double one = 1.0L;
> + volatile long double two = 2.0L;
> + volatile long double b;
> + char buffer[20];
> + int main()
> + {
> +   #if !defined(_ARCH_PPC) || !defined(__LONG_DOUBLE_IEEE128__)
> + return 1;
> +   #else
> + b = one + two;
> + if (memcmp ((void *), (void *), sizeof (long double)) != 0)
> +   return 1;
> + sprintf (buffer, "%lg", b);
> + return strcmp (buffer, "3") != 0;
> +   #endif
> + }
> +} $options
> +}

Ditto.

> +# See if the target is a powerpc with the long double format that is 
> 128-bits.
> +
> +proc check_effective_target_ppc_long_double_128bit { } {
> +return [check_cached_effective_target ppc_long_double_128bit {
> + int main()
> + {
> +   #ifndef _ARCH_PPC
> + return 1;
> +   #else
> + return sizeof (long double) != 16;
> + #endif
> + }
> +}]
> +}

In this case checking for PowerPC seems a really bad design: this is
obviously exactly the same on any architecture.

> +proc check_effective_target_ppc_long_double_64bit { } {
> +return [check_cached_effective_target ppc_long_double_64bit {
> + int main()
> + {
> +   #ifndef _ARCH_PPC
> + return 1;
> +   #else
> + return sizeof (long double) != 8;
> +   #endif
> + }
> +}]
> +}

Ditto.


Segher

Re: [PATCH 3/1] c++: Fix return type deduction during satisfaction

[Patrick Palka via Gcc-patches]

On Mon, 14 Dec 2020, Jason Merrill wrote:

> On 12/14/20 1:07 PM, Patrick Palka wrote:
> > During satisfaction that's entered through the three-parameter version
> > of satisfy_declaration_constraints, current_function_decl gets set to
> > the dependent DECL_TEMPLATE_RESULT for sake of access checking.  This
> > makes the predicate in_template_function return true during satisfaction
> > from this entrypoint, which in turn makes calls to mark_used exit early
> > before it does its full processing.  This leads to us accepting the
> > invalid testcase below due to mark_used never attempting to deduce the
> > return type of A::foo() and detecting failure thereof.
> > 
> > It seems wrong for in_template_function to return true during
> > instantiation or during satisfaction, so this patch strengthens
> > in_template_function to additionally check current_instantiation().
> 
> This seems like it ought to work, but I also wonder about looking at
> cfun->decl (which is less volatile) instead of current_function_decl for
> in_template_function.

That works well, so far it's passed make check-c++.  I'm fully testing
the following patch:

-- >8 --

Subject: [PATCH] c++: Fix return type deduction during satisfaction

During satisfaction that's entered through the three-parameter version
of satisfy_declaration_constraints, current_function_decl gets set to
the dependent DECL_TEMPLATE_RESULT for sake of access checking.  This
makes the predicate in_template_function return true during satisfaction
from this entrypoint, which in turn makes calls to mark_used exit early
before it does its full processing.  This leads to us accepting the
invalid testcase below due to mark_used never attempting to deduce the
return type of A::foo() and detecting failure thereof.

It seems wrong for in_template_function to be true during instantiation
or during satisfaction, so this patch makes in_template_function inspect
the less volatile cfun->decl instead of current_function_decl.

gcc/cp/ChangeLog:

* pt.c (in_template_function): Inspect cfun->decl instead of
current_function_decl.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-requires23.C: New test.
---
 gcc/cp/pt.c  | 6 --
 gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C | 9 +
 2 files changed, 13 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 5b13f125002..ce2e8797aae 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10805,14 +10805,16 @@ uses_template_parms (tree t)
   return dependent_p;
 }
 
-/* Returns true iff current_function_decl is an incompletely instantiated
+/* Returns true iff we're processing an incompletely instantiated function
template.  Useful instead of processing_template_decl because the latter
is set to 0 during instantiate_non_dependent_expr.  */
 
 bool
 in_template_function (void)
 {
-  tree fn = current_function_decl;
+  /* Inspect the less volatile cfun->decl instead of current_function_decl;
+ the latter might get set for e.g. access checking during satisfaction.  */
+  tree fn = cfun ? cfun->decl : NULL_TREE;
   bool ret;
   ++processing_template_decl;
   ret = (fn && DECL_LANG_SPECIFIC (fn)
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C
new file mode 100644
index 000..e109beaac4f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C
@@ -0,0 +1,9 @@
+// { dg-do compile { target c++20 } }
+
+// Verify f's associated constraints evaluate to false due
+// to return type deduction failure for A::foo().
+
+template  concept fooable = requires { T::foo(0); };
+template  int f ();
+struct A { static auto *foo(auto); };
+int a = f(); // { dg-error "no match" }
-- 
2.29.2.540.g3cf59784d4

Re: [PATCH 4/1] c++: More precise tracking of potentially unstable satisfaction

[Patrick Palka via Gcc-patches]

On Mon, 14 Dec 2020, Jason Merrill wrote:

> On 12/14/20 1:07 PM, Patrick Palka wrote:
> > This makes tracking of potentially unstable satisfaction results more
> > precise by recording the specific types for which completion failed
> > during satisfaction.  We now recompute a satisfaction result only if one
> > of these types has been completed since the last time we computed the
> > satisfaction result.  Thus the number of times that we recompute a
> > satisfaction result is now bounded by the number of such incomplete
> > types, rather than being effectively unbounded.  This allows us to
> > remove the invalid assumption in note_ftc_for_satisfaction that was
> > added to avoid a compile time performance regression in cmcstl2 due to
> > repeated re-computation of a satisfaction result that depended on
> > completion of a permanently incomplete class template specialization.
> > 
> > In order to continue to detect the instability in concepts-complete3.C,
> > we also need to explicitly keep track of return type deduction failure
> > alongside type completion failure.  So this patch also adds a call to
> > note_ftc_for_satisfaction in require_deduced_type.
> > 
> > gcc/cp/ChangeLog:
> > 
> > * constraint.cc (failed_type_completion_count): Remove.
> > (failed_type_completions): Define.
> > (note_failed_type_completion_for_satisfaction): Append the
> > supplied argument to failed_type_completions.
> > (some_type_complete_p): Define.
> > (sat_entry::maybe_unstable): Replace with ...
> > (sat_entry::ftc_begin, sat_entry::ftc_end): ... these.
> > (satisfaction_cache::ftc_count): Replace with ...
> > (satisfaction_cache::ftc_begin): ... this.
> > (satisfaction_cache::satisfaction_cache): Adjust accordingly.
> > (satisfaction_cache::get): Adjust accordingly, using
> > some_type_complete_p.
> > (satisfaction_cache::save): Adjust accordingly.
> > (satisfy_declaration_constraints): Likewise.
> > * decl.c (require_deduced_type): Call
> > note_failed_type_completion_for_satisfaction.
> > ---
> >   gcc/cp/constraint.cc | 89 +++-
> >   gcc/cp/decl.c|  1 +
> >   2 files changed, 56 insertions(+), 34 deletions(-)
> > 
> > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> > index dc5c34e7e91..fd5d9429c9d 100644
> > --- a/gcc/cp/constraint.cc
> > +++ b/gcc/cp/constraint.cc
> > @@ -2374,26 +2374,44 @@ tsubst_parameter_mapping (tree map, tree args,
> > tsubst_flags_t complain, tree in_
> >   Constraint satisfaction
> >   
> > ---*/
> >   -/* A counter incremented by
> > note_failed_type_completion_for_satisfaction().
> > -   It's used by the satisfaction caches in order to flag "potentially
> > unstable"
> > -   satisfaction results.  */
> > +/* A vector of incomplete types (and declarations with undeduced return
> > types),
> > +   appended to by note_failed_type_completion_for_satisfaction.  The
> > +   satisfaction caches use this in order to keep track of "potentially
> > unstable"
> > +   satisfaction results.
> >   -static unsigned failed_type_completion_count;
> > +   Since references to entries in vector are stored only in the
> > GC-deletable
> > +   sat_cache, it's safe to make this deletable as well.  */
> >   -/* Called whenever a type completion failure occurs that definitely
> > affects
> > -   the semantics of the program, by e.g. inducing substitution failure.  */
> > +static GTY((deletable)) vec *failed_type_completions;
> 
> > +/* Called whenever a type completion (or return type deduction) failure
> > occurs
> > +   that definitely affects the semantics of the program, by e.g. inducing
> > +   substitution failure.  */
> > void
> > -note_failed_type_completion_for_satisfaction (tree type)
> > -{
> > -  gcc_checking_assert (!COMPLETE_TYPE_P (type));
> > -  if (CLASS_TYPE_P (type)
> > -  && CLASSTYPE_TEMPLATE_INSTANTIATION (type))
> > -/* After instantiation, a class template specialization that's
> > -   incomplete will remain incomplete, so for our purposes we can
> > -   ignore this completion failure event.  */;
> > -  else
> > -++failed_type_completion_count;
> > +note_failed_type_completion_for_satisfaction (tree t)
> > +{
> > +  gcc_checking_assert ((TYPE_P (t) && !COMPLETE_TYPE_P (t))
> > +  || (DECL_P (t) && undeduced_auto_decl (t)));
> > +  vec_safe_push (failed_type_completions, t);
> > +}
> 
> It looks like we'll happily add to this table outside of satisfaction, making
> it much larger than it needs to be.

I should've mentioned that in practice these events (type completion
failure or return type deduction failure inducing substitution failure)
seem to be rare enough that the vector ends up being very small even
when we append to it outside of satisfaction.  For example the vector
ends up being appended to at most 13 times in any one test in 

Re: [19/23] rtlanal: Add some new helper classes

[Jeff Law via Gcc-patches]

On 12/14/20 9:37 AM, Richard Sandiford wrote:
> Jeff Law  writes:
>> On 11/13/20 1:20 AM, Richard Sandiford via Gcc-patches wrote:
>>> This patch adds some classes for gathering the list of registers
>>> and memory that are read and written by an instruction, along
>>> with various properties about the accesses.  In some ways it's
>>> similar to the information that DF collects for registers,
>>> but extended to memory.  The main reason for using it instead
>>> of DF is that it can analyse tentative changes to instructions
>>> before they've been committed.
>>>
>>> The classes also collect general information about the instruction,
>>> since it's cheap to do and helps to avoid multiple walks of the same
>>> RTL pattern.
>>>
>>> I've tried to optimise the code quite a bit, since with later patches
>>> it becomes relatively performance-sensitive.  See the discussion in
>>> the comments for the trade-offs involved.
>>>
>>> I put the declarations in a new rtlanal.h header file since it
>>> seemed a bit excessive to put so much new inline stuff in rtl.h.
>>>
>>> gcc/
>>> * rtlanal.h: New file.
>>> (MEM_REGNO): New constant.
>>> (rtx_obj_flags): New namespace.
>>> (rtx_obj_reference, rtx_properties): New classes.
>>> (growing_rtx_properties, vec_rtx_properties_base): Likewise.
>>> (vec_rtx_properties): New alias.
>>> * rtlanal.c: Include it.
>>> (rtx_properties::try_to_add_reg): New function.
>>> (rtx_properties::try_to_add_dest): Likewise.
>>> (rtx_properties::try_to_add_src): Likewise.
>>> (rtx_properties::try_to_add_pattern): Likewise.
>>> (rtx_properties::try_to_add_insn): Likewise.
>>> (vec_rtx_properties_base::grow): Likewise.
>> One might argue at least some of these should become first class
>> properties of insns but then we have the joy of keeping them up-to-date
>> as transformations are made.  It also reminds me a bit of the old
>> var_ann stuff we had in the tree SSA implementation. 
> Yeah.  The RTL SSA insn info does store these properties, but that has
> the advantage of being new code and so can require all updates to go
> through new interfaces.  I agree that ideally we'd store the information
> directly in RTL insns instead.
I guess it's less problematic since we're using real classes.  The old
annotation stuff was done before we had C++ & classes.

>
> I guess one question is where we would store the new flags.  In some
> ways it might be easier to do that after any future split of rtx_insn
> and rtx, since we could then use a smaller code field and potentially
> replace the mode field.  (Things like :TI markers for VLIW bundles
> could use a separate flag instead.)
Dunno offhand.  I'm OK with things as-is for now -- again, having
classes allows us to real wrappers and enforce a degree to access
control, which greatly diminishes the pain we had with var_ann.

Splitting off rtx_insn from rtx is independent, but definitely something
I want to see move forward.

Jeff

Re: [PATCH 4/1] c++: More precise tracking of potentially unstable satisfaction

[Jason Merrill via Gcc-patches]

On 12/14/20 1:07 PM, Patrick Palka wrote:

This makes tracking of potentially unstable satisfaction results more
precise by recording the specific types for which completion failed
during satisfaction.  We now recompute a satisfaction result only if one
of these types has been completed since the last time we computed the
satisfaction result.  Thus the number of times that we recompute a
satisfaction result is now bounded by the number of such incomplete
types, rather than being effectively unbounded.  This allows us to
remove the invalid assumption in note_ftc_for_satisfaction that was
added to avoid a compile time performance regression in cmcstl2 due to
repeated re-computation of a satisfaction result that depended on
completion of a permanently incomplete class template specialization.

In order to continue to detect the instability in concepts-complete3.C,
we also need to explicitly keep track of return type deduction failure
alongside type completion failure.  So this patch also adds a call to
note_ftc_for_satisfaction in require_deduced_type.

gcc/cp/ChangeLog:

* constraint.cc (failed_type_completion_count): Remove.
(failed_type_completions): Define.
(note_failed_type_completion_for_satisfaction): Append the
supplied argument to failed_type_completions.
(some_type_complete_p): Define.
(sat_entry::maybe_unstable): Replace with ...
(sat_entry::ftc_begin, sat_entry::ftc_end): ... these.
(satisfaction_cache::ftc_count): Replace with ...
(satisfaction_cache::ftc_begin): ... this.
(satisfaction_cache::satisfaction_cache): Adjust accordingly.
(satisfaction_cache::get): Adjust accordingly, using
some_type_complete_p.
(satisfaction_cache::save): Adjust accordingly.
(satisfy_declaration_constraints): Likewise.
* decl.c (require_deduced_type): Call
note_failed_type_completion_for_satisfaction.
---
  gcc/cp/constraint.cc | 89 +++-
  gcc/cp/decl.c|  1 +
  2 files changed, 56 insertions(+), 34 deletions(-)

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index dc5c34e7e91..fd5d9429c9d 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2374,26 +2374,44 @@ tsubst_parameter_mapping (tree map, tree args, 
tsubst_flags_t complain, tree in_
  Constraint satisfaction
  ---*/
  
-/* A counter incremented by note_failed_type_completion_for_satisfaction().

-   It's used by the satisfaction caches in order to flag "potentially unstable"
-   satisfaction results.  */
+/* A vector of incomplete types (and declarations with undeduced return types),
+   appended to by note_failed_type_completion_for_satisfaction.  The
+   satisfaction caches use this in order to keep track of "potentially 
unstable"
+   satisfaction results.
  
-static unsigned failed_type_completion_count;

+   Since references to entries in vector are stored only in the GC-deletable
+   sat_cache, it's safe to make this deletable as well.  */
  
-/* Called whenever a type completion failure occurs that definitely affects

-   the semantics of the program, by e.g. inducing substitution failure.  */
+static GTY((deletable)) vec *failed_type_completions;



+/* Called whenever a type completion (or return type deduction) failure occurs
+   that definitely affects the semantics of the program, by e.g. inducing
+   substitution failure.  */
  
  void

-note_failed_type_completion_for_satisfaction (tree type)
-{
-  gcc_checking_assert (!COMPLETE_TYPE_P (type));
-  if (CLASS_TYPE_P (type)
-  && CLASSTYPE_TEMPLATE_INSTANTIATION (type))
-/* After instantiation, a class template specialization that's
-   incomplete will remain incomplete, so for our purposes we can
-   ignore this completion failure event.  */;
-  else
-++failed_type_completion_count;
+note_failed_type_completion_for_satisfaction (tree t)
+{
+  gcc_checking_assert ((TYPE_P (t) && !COMPLETE_TYPE_P (t))
+  || (DECL_P (t) && undeduced_auto_decl (t)));
+  vec_safe_push (failed_type_completions, t);
+}


It looks like we'll happily add to this table outside of satisfaction, 
making it much larger than it needs to be.


For template instantiations, we probably want to remember the template 
itself rather than each individual instantiation, and then check if we 
see a new definition or partial specialization.  That should mean fewer 
elements to consider, and also less impact from order of instantiation.


I also wonder about using a hash_set or _map instead of a vec to reduce 
the size, though that would mean sacrificing the information about which 
specific types a particular atom cares about.



+/* Returns true if the range [BEGIN, END) of elements within the
+   failed_type_completions vector contains a complete type (or a declaration
+   with a non-placeholder return 

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[Dimitar Dimitrov]

On четвъртък, 10 декември 2020 г. 10:24:50 EET Richard Biener wrote:
> On Thu, Dec 10, 2020 at 6:42 AM Dimitar Dimitrov  wrote:
> > On сряда, 9 декември 2020 г. 15:12:49 EET abebeos via Gcc-patches wrote:
> > > Essence:
> > > 
> > > I need a confirmation that the testsuite setup as presented in:
> > > 
> > > https://github.com/abebeos/avr-gnu
> > > 
> > > works fine.
> > > 
> > > The problem with the avr target is that the testsuite cannot be run
> > > easily,
> > > mainly because of the need for a special simulated-target setup, which
> > > does
> > > not work for avr as documented. This led developers to a dead-end with
> > > their non-cc0-avr-backends (the non-cc0 backend is needed thus avr is
> > > not
> > > dropped from gcc11).
> > > 
> > > I integrated a toolchain/testsetup to be able to run the gcc testsuite
> > > against a simulated avr target.
> > > 
> > > I then used this toolchain to test 2 different existent
> > > non-cc0-avr-backends (from pipcet and saaadhu, both github).
> > > 
> > > The result is that saaadhu's backend seems to be working 100%. It has
> > > identical testsuite results with the existing (but deprecated)
> > > cc0-backend,
> > > which means that it can be used "as-is" for inclusion in gcc11.
> > > 
> > > Please note that I did this work in context of a bounty @ bountysouce,
> > > more
> > > information within the issue:
> > > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
> > 
> > Hi,
> > 
> > I tested the trees you have given with my own AVR test setup [1]. I
> > confirm
> > 
> > your results:
> >   - saaadhu's tree does not introduce any regressions.
> >   - pipcet's tree has 142 gcc and 299 g++ regressions (although many of
> >   them
> >   
> > are duplicates, e.g. same test case with different optimization
> > levels).
> > 
> > It's a bit awkward to copy gcc/config/avr into a mainline tree. Looking at
> > their github history, both authors made some small changes in other areas.
> > I would have prefered to cherry-pick or apply patches.
> > 
> > =
> > baseline beb9afcaf1466996a301c778596c5df209e7913c
> > 
> > === gcc Summary ===
> > 
> > # of expected passes87504
> > # of unexpected failures1105
> > # of unexpected successes   15
> > # of expected failures  581
> > # of unresolved testcases   16786
> > # of unsupported tests  5370
> > 
> > === g++ Summary ===
> > 
> > # of expected passes140663
> > # of unexpected failures7932
> > # of unexpected successes   21
> > # of expected failures  620
> > # of unresolved testcases   8603
> > # of unsupported tests  11305
> > 
> > =
> > pipcet/avr-ccmode
> > 
> > === gcc Summary ===
> > 
> > # of expected passes87463
> > # of unexpected failures1221
> > # of unexpected successes   15
> > # of expected failures  581
> > # of unresolved testcases   16799
> > # of unsupported tests  5359
> > 
> > === g++ Summary ===
> > 
> > # of expected passes140529
> > # of unexpected failures8205
> > # of unexpected successes   21
> > # of expected failures  620
> > # of unresolved testcases   8607
> > # of unsupported tests  11301
> > 
> > =
> > saadhu/avr-cc0
> > 
> > === gcc Summary ===
> > 
> > # of expected passes87504
> > # of unexpected failures1105
> > # of unexpected successes   15
> > # of expected failures  581
> > # of unresolved testcases   16786
> > # of unsupported tests  5370
> > 
> > === g++ Summary ===
> > 
> > # of expected passes140663
> > # of unexpected failures7932
> > # of unexpected successes   21
> > # of expected failures  620
> > # of unresolved testcases   8603
> > # of unsupported tests  11305
> > 
> > On a side note, I build and test AVR backend in mainline everyday. If
> > there is interest from AVR maintainers I can post daily results to
> > gcc-testresults@ mailing list.
> 
> I'd appreciate such postings, not necessarily daily (if there are no
> changes). Also (as usual) for active release branches (say once a week or
> biweekly or even monthly).

I'll start sending biweekly the AVR testresults from all active branches.

Yesterday my test results were temporarily held back due to large email size, 
but eventually reached gcc-testresults@ . I'd like to know if I need to trim 
them somehow.


> 
> Without any hints on gcc-testresults its hard to asses whether ports
> pass some very basic functionality criteria (AVR is neither primary nor
> secondary but shipping totally broken ports isn't in our interest).
> 
> Thanks a lot,
> Richard.
> 
> > Regards,
> > Dimitar
> > 
> > [1] 

Re: [Patch] varasm.c: Always output flags in merged .section for LLVM assembler compatibility [PR97827]

[Jakub Jelinek via Gcc-patches]

On Mon, Dec 14, 2020 at 07:44:12PM +0100, Tobias Burnus wrote:
> Regarding this discussion, see also the comments from an LLVM reviewer
> at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827 * — to keep them
> at one place, I won't quote the discussion here.

I think the LLVM people must be completely ignoring hand-written assembler,
the behavior of GNU as is not something specific to GNU as, but to all other
assemblers GCC uses except for this recent LLVM as change, and has been like
that for decades, so I'm sure there is a lot of hand-written assembler that
relies on that.

So, I'm against adding workarounds for bad LLVM decisions.

Jakub

Re: [PATCH 3/1] c++: Fix return type deduction during satisfaction

[Jason Merrill via Gcc-patches]

On 12/14/20 1:07 PM, Patrick Palka wrote:

During satisfaction that's entered through the three-parameter version
of satisfy_declaration_constraints, current_function_decl gets set to
the dependent DECL_TEMPLATE_RESULT for sake of access checking.  This
makes the predicate in_template_function return true during satisfaction
from this entrypoint, which in turn makes calls to mark_used exit early
before it does its full processing.  This leads to us accepting the
invalid testcase below due to mark_used never attempting to deduce the
return type of A::foo() and detecting failure thereof.

It seems wrong for in_template_function to return true during
instantiation or during satisfaction, so this patch strengthens
in_template_function to additionally check current_instantiation().


This seems like it ought to work, but I also wonder about looking at 
cfun->decl (which is less volatile) instead of current_function_decl for 
in_template_function.



Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
commit?

gcc/cp/ChangeLog:

* pt.c (in_template_function): Return false if
current_instantiation() is non-NULL.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-requires23.C: New test.
---
  gcc/cp/pt.c  | 9 +
  gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C | 9 +
  2 files changed, 14 insertions(+), 4 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 5b13f125002..5f7bc7000c4 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10805,9 +10805,9 @@ uses_template_parms (tree t)
return dependent_p;
  }
  
-/* Returns true iff current_function_decl is an incompletely instantiated

-   template.  Useful instead of processing_template_decl because the latter
-   is set to 0 during instantiate_non_dependent_expr.  */
+/* Returns true iff we're processing an incompletely instantiated template.
+   Useful instead of processing_template_decl because the latter is set to
+   0 during instantiate_non_dependent_expr.  */
  
  bool

  in_template_function (void)
@@ -10815,7 +10815,8 @@ in_template_function (void)
tree fn = current_function_decl;
bool ret;
++processing_template_decl;
-  ret = (fn && DECL_LANG_SPECIFIC (fn)
+  ret = (!current_instantiation ()
+&& fn && DECL_LANG_SPECIFIC (fn)
 && DECL_TEMPLATE_INFO (fn)
 && any_dependent_template_arguments_p (DECL_TI_ARGS (fn)));
--processing_template_decl;
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C
new file mode 100644
index 000..e109beaac4f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C
@@ -0,0 +1,9 @@
+// { dg-do compile { target c++20 } }
+
+// Verify f's associated constraints evaluate to false due
+// to return type deduction failure for A::foo().
+
+template  concept fooable = requires { T::foo(0); };
+template  int f ();
+struct A { static auto *foo(auto); };
+int a = f(); // { dg-error "no match" }

Re: [PATCH] rs6000: Use subreg for QI/HI vector init

[Segher Boessenkool]

On Wed, Dec 02, 2020 at 04:32:47PM -0600, will schmidt wrote:
> On Wed, 2020-12-02 at 17:44 +0800, Kewen.Lin via Gcc-patches wrote:
> > * gcc.target/powerpc/pr96933-1.c: Adjusted to check no rlwinm.
> > * gcc.target/powerpc/pr96933-2.c: Likewise.
> 
> Ok.  (I'd hope a few more extend instructions would be eliminated, but
> this only covers the tests that explicitly looked/didn't look for them, so 
> OK).

The patch changes only one very specific case.  To have a bigger effect,
some much more generic thing is needed (and that should *not* use
subregs, subregs are worse most of the time).


Segher

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[Dimitar Dimitrov]

On петък, 11 декември 2020 г. 19:00:35 EET abebeos wrote:
> After "digesting" a bit more your review, I need to thank you for opening
> my eyes re "cherrypick" suggestion and... the missing g++ summaries. I need
> to update my setup to provide the g++ test-deltas, too. Note that in my
> test-setup, more c++ tests pass than in yours, not exactly sure why. It's
> in the "unresovled testcases".

Regarding the additional "unresolved testcases" in my results. I traced it to 
a bug in my setup. I did not prepare $HOME/.dejagnurc properly for AVR. I'll 
rerun the tests and post the results.

I'm using stock avr-libc, while I see you are using the avr-libc3 fork. 
Hopefully the main differences are in HW support, not core libc.

Regards,
Dimitar

Re: [PATCH] rs6000: Use subreg for QI/HI vector init

[Segher Boessenkool]

Hi!

On Wed, Dec 02, 2020 at 05:44:24PM +0800, Kewen.Lin wrote:
> This patch is to use paradoxical subreg instead of
> zero_extend for promoting QI/HI to SI/DI when we
> want to construct one vector with these modes.
> Since we do the gpr->vsx movement and vector merge
> or pack later, the high part is useless and safe to
> use paradoxical subreg.  It can avoid useless rlwinms
> generated for signed cases.

> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -6793,17 +6793,8 @@ rs6000_expand_vector_init (rtx target, rtx vals)
>/* Force the values into word_mode registers.  */
>for (i = 0; i < n_elts; i++)
>   {
> -   rtx tmp = force_reg (GET_MODE_INNER (mode), XVECEXP (vals, 0, i));
> -   if (TARGET_POWERPC64)
> - {
> -   op[i] = gen_reg_rtx (DImode);
> -   emit_insn (gen_zero_extendqidi2 (op[i], tmp));
> - }
> -   else
> - {
> -   op[i] = gen_reg_rtx (SImode);
> -   emit_insn (gen_zero_extendqisi2 (op[i], tmp));
> - }
> +   rtx tmp = force_reg (inner_mode, XVECEXP (vals, 0, i));
> +   op[i] = simplify_gen_subreg (Pmode, tmp, inner_mode, 0);
>   }

Pmode is defined based on TARGET_64BIT, not TARGET_POWERPC64.

But, can you not always use SImode here?

The rest of the patch is fine of course.


Segher

Re: [Patch] varasm.c: Always output flags in merged .section for LLVM assembler compatibility [PR97827]

[Tobias Burnus]

Regarding this discussion, see also the comments from an LLVM reviewer
at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827 * — to keep them
at one place, I won't quote the discussion here.

It would be great if this could be solved one way or the other...

Tobias

*  for the LLVM side, see also https://reviews.llvm.org/D92052

On 19.11.20 11:12, Richard Sandiford wrote:

Jakub Jelinek via Gcc-patches  writes:

On Thu, Nov 19, 2020 at 09:51:41AM +, Richard Sandiford wrote:

I think we shouldn't do this except when targetting the (buggy) llvm
assembler.
Specifying section flags just on first .section directive and not others
is correct, there is no point repeating that and GNU as (but I think many
other assemblers) has been supporting it that way forever.

But are there any negative effects with specifying the flags multiple
times for GNU as?  If not, then it seems simpler to generate the form
that “all” assemblers accept.

It makes the assembler files unnecessarily larger and harder to read.

It certainly makes them larger, but surely not by an amount that would
cause anyone difficulty in practice.  Not sure about harder to read
though.  Personally I've never found reading code that happens to be
after the first switch to a section any harder to read than subsequent
switches to the section.

The problem with switching based on what assembler we think people
are using is that we don't always know.  It can often be useful to
try something with a different tool for comparison purposes, and that
includes using llvm-mc instead of gas.  (Certainly done that myself
a few times, and I know others have.)

I'm not saying we should bend over backwards to support difficult
quirks.  But here we're talking about a choice between (a) doing
something that works “everywhere” unconditionally (and keeping things
simple) vs. (b) having both code that takes a shortcut and code that
doesn't take a shortcut and trying to predict which one we should do.

Thanks,
Richard

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

[PATCH 4/1] c++: More precise tracking of potentially unstable satisfaction

[Patrick Palka via Gcc-patches]

This makes tracking of potentially unstable satisfaction results more
precise by recording the specific types for which completion failed
during satisfaction.  We now recompute a satisfaction result only if one
of these types has been completed since the last time we computed the
satisfaction result.  Thus the number of times that we recompute a
satisfaction result is now bounded by the number of such incomplete
types, rather than being effectively unbounded.  This allows us to
remove the invalid assumption in note_ftc_for_satisfaction that was
added to avoid a compile time performance regression in cmcstl2 due to
repeated re-computation of a satisfaction result that depended on
completion of a permanently incomplete class template specialization.

In order to continue to detect the instability in concepts-complete3.C,
we also need to explicitly keep track of return type deduction failure
alongside type completion failure.  So this patch also adds a call to
note_ftc_for_satisfaction in require_deduced_type.

gcc/cp/ChangeLog:

* constraint.cc (failed_type_completion_count): Remove.
(failed_type_completions): Define.
(note_failed_type_completion_for_satisfaction): Append the
supplied argument to failed_type_completions.
(some_type_complete_p): Define.
(sat_entry::maybe_unstable): Replace with ...
(sat_entry::ftc_begin, sat_entry::ftc_end): ... these.
(satisfaction_cache::ftc_count): Replace with ...
(satisfaction_cache::ftc_begin): ... this.
(satisfaction_cache::satisfaction_cache): Adjust accordingly.
(satisfaction_cache::get): Adjust accordingly, using
some_type_complete_p.
(satisfaction_cache::save): Adjust accordingly.
(satisfy_declaration_constraints): Likewise.
* decl.c (require_deduced_type): Call
note_failed_type_completion_for_satisfaction.
---
 gcc/cp/constraint.cc | 89 +++-
 gcc/cp/decl.c|  1 +
 2 files changed, 56 insertions(+), 34 deletions(-)

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index dc5c34e7e91..fd5d9429c9d 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2374,26 +2374,44 @@ tsubst_parameter_mapping (tree map, tree args, 
tsubst_flags_t complain, tree in_
 Constraint satisfaction
 ---*/
 
-/* A counter incremented by note_failed_type_completion_for_satisfaction().
-   It's used by the satisfaction caches in order to flag "potentially unstable"
-   satisfaction results.  */
+/* A vector of incomplete types (and declarations with undeduced return types),
+   appended to by note_failed_type_completion_for_satisfaction.  The
+   satisfaction caches use this in order to keep track of "potentially 
unstable"
+   satisfaction results.
 
-static unsigned failed_type_completion_count;
+   Since references to entries in vector are stored only in the GC-deletable
+   sat_cache, it's safe to make this deletable as well.  */
 
-/* Called whenever a type completion failure occurs that definitely affects
-   the semantics of the program, by e.g. inducing substitution failure.  */
+static GTY((deletable)) vec *failed_type_completions;
+
+/* Called whenever a type completion (or return type deduction) failure occurs
+   that definitely affects the semantics of the program, by e.g. inducing
+   substitution failure.  */
 
 void
-note_failed_type_completion_for_satisfaction (tree type)
-{
-  gcc_checking_assert (!COMPLETE_TYPE_P (type));
-  if (CLASS_TYPE_P (type)
-  && CLASSTYPE_TEMPLATE_INSTANTIATION (type))
-/* After instantiation, a class template specialization that's
-   incomplete will remain incomplete, so for our purposes we can
-   ignore this completion failure event.  */;
-  else
-++failed_type_completion_count;
+note_failed_type_completion_for_satisfaction (tree t)
+{
+  gcc_checking_assert ((TYPE_P (t) && !COMPLETE_TYPE_P (t))
+  || (DECL_P (t) && undeduced_auto_decl (t)));
+  vec_safe_push (failed_type_completions, t);
+}
+
+/* Returns true if the range [BEGIN, END) of elements within the
+   failed_type_completions vector contains a complete type (or a declaration
+   with a non-placeholder return type).  */
+
+static bool
+some_type_complete_p (int begin, int end)
+{
+  for (int i = begin; i < end; i++)
+{
+  tree t = (*failed_type_completions)[i];
+  if (TYPE_P (t) && COMPLETE_TYPE_P (t))
+   return true;
+  if (DECL_P (t) && !undeduced_auto_decl (t))
+   return true;
+}
+  return false;
 }
 
 /* Hash functions and data types for satisfaction cache entries.  */
@@ -2417,12 +2435,10 @@ struct GTY((for_user)) sat_entry
  performed.  */
   location_t location;
 
-  /* True if this satisfaction result is flagged as "potentially unstable",
- i.e. the result might change at different points in the program if
- 

[PATCH 3/1] c++: Fix return type deduction during satisfaction

[Patrick Palka via Gcc-patches]

During satisfaction that's entered through the three-parameter version
of satisfy_declaration_constraints, current_function_decl gets set to
the dependent DECL_TEMPLATE_RESULT for sake of access checking.  This
makes the predicate in_template_function return true during satisfaction
from this entrypoint, which in turn makes calls to mark_used exit early
before it does its full processing.  This leads to us accepting the
invalid testcase below due to mark_used never attempting to deduce the
return type of A::foo() and detecting failure thereof.

It seems wrong for in_template_function to return true during
instantiation or during satisfaction, so this patch strengthens
in_template_function to additionally check current_instantiation().

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
commit?

gcc/cp/ChangeLog:

* pt.c (in_template_function): Return false if
current_instantiation() is non-NULL.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-requires23.C: New test.
---
 gcc/cp/pt.c  | 9 +
 gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C | 9 +
 2 files changed, 14 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 5b13f125002..5f7bc7000c4 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10805,9 +10805,9 @@ uses_template_parms (tree t)
   return dependent_p;
 }
 
-/* Returns true iff current_function_decl is an incompletely instantiated
-   template.  Useful instead of processing_template_decl because the latter
-   is set to 0 during instantiate_non_dependent_expr.  */
+/* Returns true iff we're processing an incompletely instantiated template.
+   Useful instead of processing_template_decl because the latter is set to
+   0 during instantiate_non_dependent_expr.  */
 
 bool
 in_template_function (void)
@@ -10815,7 +10815,8 @@ in_template_function (void)
   tree fn = current_function_decl;
   bool ret;
   ++processing_template_decl;
-  ret = (fn && DECL_LANG_SPECIFIC (fn)
+  ret = (!current_instantiation ()
+&& fn && DECL_LANG_SPECIFIC (fn)
 && DECL_TEMPLATE_INFO (fn)
 && any_dependent_template_arguments_p (DECL_TI_ARGS (fn)));
   --processing_template_decl;
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C
new file mode 100644
index 000..e109beaac4f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-requires23.C
@@ -0,0 +1,9 @@
+// { dg-do compile { target c++20 } }
+
+// Verify f's associated constraints evaluate to false due
+// to return type deduction failure for A::foo().
+
+template  concept fooable = requires { T::foo(0); };
+template  int f ();
+struct A { static auto *foo(auto); };
+int a = f(); // { dg-error "no match" }
-- 
2.29.2.540.g3cf59784d4

Re: rs6000: Update the processor defaults for FreeBSD

[Segher Boessenkool]

On Mon, Dec 14, 2020 at 05:29:30PM +0100, Piotr Kubaj wrote:
> On 20-12-14 10:22:32, Segher Boessenkool wrote:
> > On Mon, Dec 14, 2020 at 03:57:27PM +0100, Piotr Kubaj wrote:
> > > > It is both, actually (-mcpu= implies -mtune=)
> > > Yes, but -mtune doesn't imply -mcpu. If I set up only -mtune, -mcpu is 
> > > the generic one (ppc970 for BE)
> > 
> > But that is not what the patch does?
> OK, then can you explain to me what it does since the generated assembly 
> still specifies .machine power4?

It's a mystery to me!  This macro *is* used for selecting the default
-mcpu= setting.

> This is my first attempt at improving GCC on powerpc* on FreeBSD and I'd 
> really prefer not to break anything, but this SEEMS to be correct.

You do everything the same as our Linux ports here, and all evidence
shows it does in fact work, so it is fine.  I just cannot see *why* or
*how* it works :-)


Segher

Re: rs6000: add support for powerpc64le-unknown-freebsd

[Segher Boessenkool]

Hi!

On Mon, Dec 14, 2020 at 04:35:38PM +0100, Piotr Kubaj wrote:
> this patch implements support for powerpc64le architecture on FreeBSD. Since 
> we don't have powerpcle (32-bit), I did not add support for powerpcle here. 
> This remains to be changed if there is powerpcle support in the future.
> 
> Patch implements similar endian detection to what linux64.h uses.
> 
> Would it be ok to backport it to at least GCC 10?

> --- gcc/config.gcc.orig   2020-12-07 03:00:29 UTC
> +++ gcc/config.gcc
> @@ -2868,6 +2868,10 @@ powerpc*-*-freebsd*)
>   extra_options="${extra_options} rs6000/sysv4.opt"
>   tmake_file="rs6000/t-fprules rs6000/t-ppcos ${tmake_file} 
> rs6000/t-ppccomm"
>   case ${target} in
> + powerpc*le-*-*)
> + tm_file="${tm_file} rs6000/sysv4le.h" ;;
> + esac

What an obvious filename ;-)

I guess we should put all these header files together into one again,
but that is hard to do without regressing things (I suspect this is
where the mystery power4 stems from as well, fwiw).

The patch looks fine.  Okay for trunk.  Also okay for any backports you
want (after waiting to see if it creates problems on trunk, as usual).

Thanks!


Segher

Re: [19/23] rtlanal: Add some new helper classes

[Richard Sandiford via Gcc-patches]

Jeff Law  writes:
> On 11/13/20 1:20 AM, Richard Sandiford via Gcc-patches wrote:
>> This patch adds some classes for gathering the list of registers
>> and memory that are read and written by an instruction, along
>> with various properties about the accesses.  In some ways it's
>> similar to the information that DF collects for registers,
>> but extended to memory.  The main reason for using it instead
>> of DF is that it can analyse tentative changes to instructions
>> before they've been committed.
>>
>> The classes also collect general information about the instruction,
>> since it's cheap to do and helps to avoid multiple walks of the same
>> RTL pattern.
>>
>> I've tried to optimise the code quite a bit, since with later patches
>> it becomes relatively performance-sensitive.  See the discussion in
>> the comments for the trade-offs involved.
>>
>> I put the declarations in a new rtlanal.h header file since it
>> seemed a bit excessive to put so much new inline stuff in rtl.h.
>>
>> gcc/
>>  * rtlanal.h: New file.
>>  (MEM_REGNO): New constant.
>>  (rtx_obj_flags): New namespace.
>>  (rtx_obj_reference, rtx_properties): New classes.
>>  (growing_rtx_properties, vec_rtx_properties_base): Likewise.
>>  (vec_rtx_properties): New alias.
>>  * rtlanal.c: Include it.
>>  (rtx_properties::try_to_add_reg): New function.
>>  (rtx_properties::try_to_add_dest): Likewise.
>>  (rtx_properties::try_to_add_src): Likewise.
>>  (rtx_properties::try_to_add_pattern): Likewise.
>>  (rtx_properties::try_to_add_insn): Likewise.
>>  (vec_rtx_properties_base::grow): Likewise.
> One might argue at least some of these should become first class
> properties of insns but then we have the joy of keeping them up-to-date
> as transformations are made.  It also reminds me a bit of the old
> var_ann stuff we had in the tree SSA implementation. 

Yeah.  The RTL SSA insn info does store these properties, but that has
the advantage of being new code and so can require all updates to go
through new interfaces.  I agree that ideally we'd store the information
directly in RTL insns instead.

I guess one question is where we would store the new flags.  In some
ways it might be easier to do that after any future split of rtx_insn
and rtx, since we could then use a smaller code field and potentially
replace the mode field.  (Things like :TI markers for VLIW bundles
could use a separate flag instead.)

It might even be possible to do the update fairly cheaply, if we made
the generators record static flags for the fixed part of the pattern
and only computed the operand information dynamically.

Thanks,
Richard

Re: rs6000: Update the processor defaults for FreeBSD

[Piotr Kubaj via Gcc-patches]

On 20-12-14 10:22:32, Segher Boessenkool wrote:
> On Mon, Dec 14, 2020 at 03:57:27PM +0100, Piotr Kubaj wrote:
> > > It is both, actually (-mcpu= implies -mtune=)
> > Yes, but -mtune doesn't imply -mcpu. If I set up only -mtune, -mcpu is the 
> > generic one (ppc970 for BE)
> 
> But that is not what the patch does?
OK, then can you explain to me what it does since the generated assembly still 
specifies .machine power4?

This is my first attempt at improving GCC on powerpc* on FreeBSD and I'd really 
prefer not to break anything, but this SEEMS to be correct.

> 
> > > > Linux also does similarly in linux64.h:
> > > >  74 #undef  PROCESSOR_DEFAULT
> > > >  75 #define PROCESSOR_DEFAULT PROCESSOR_POWER7
> > > >  76 #undef  PROCESSOR_DEFAULT64
> > > >  77 #define PROCESSOR_DEFAULT64 PROCESSOR_POWER8
> > > 
> > > Yes, but we still default to power4 on BE Linux (and power8 on LE).  I
> > > get lost in the macro maze here, not sure how that works :-)
> 
> I still am baffled how this works :-/
> 
> > > > Although there is hard to explain (for me) setting to tune for POWER7 
> > > > on 32-bits. POWER7 is 64-bit and it should be more reasonable to 
> > > > optimize for the last 32-bit machines that still may be in use (so G4).
> > > 
> > > 7450 has very different optimisation than 970.  Power7 and 970 have
> > > largely similar pipelines.
> > Yes, but the point is that users on 32-bit machines don't use POWER7, but 
> > most likely G4.
> 
> Ah, but most users using -m32 are on a 64-bit machine!
> 
> > > > That said, on the 64-bit front, we will just match the Linux setting.
> > > 
> > > Compile a very simple test and look at the .machine in the generated .s?
> > > Does that do what you want?
> > Yes, I just tested it (on BE).
> > pkubaj@talos:$/usr/home/pkubaj$ cat test.c
> > #include 
> > 
> > int main()
> > {
> > printf("Hello world!");
> > }
> > 
> > I built it twice, with GCC 9.3 without my patch and with GCC 10.1 with my 
> > patch. The only difference is:
> > pkubaj@talos:$/usr/home/pkubaj$ diff -u test.s.9 test.s.10
> > --- test.s.92020-12-14 15:51:43.203263000 +0100
> > +++ test.s.10   2020-12-14 15:52:01.147238000 +0100
> > @@ -43,5 +43,5 @@
> > .cfi_endproc
> >  .LFE1:
> > .size   main,.-main
> > -   .ident  "GCC: (FreeBSD Ports Collection) 9.3.0"
> > +   .ident  "GCC: (FreeBSD Ports Collection) 10.2.0"
> > .section.note.GNU-stack,"",@progbits
> > 
> > Both have .machine power4:
> > pkubaj@talos:$/usr/home/pkubaj$ grep .machine test.s.*
> > test.s.10:  .machine power4
> > test.s.9:   .machine power4
> > 
> > I'm not sure where GCC sets power8 for LE, but it's definitely somewhere 
> > else.
> 
> Yes...  And I do not know where this power4 comes from.  Mysteries :-)
> 
> > So IMO this patch is good to go.
> 
> Yes, thanks!
> 
> 
> Segher

-- 


signature.asc
Description: PGP signature

Re: rs6000: Update the processor defaults for FreeBSD

[Segher Boessenkool]

On Mon, Dec 14, 2020 at 03:57:27PM +0100, Piotr Kubaj wrote:
> > It is both, actually (-mcpu= implies -mtune=)
> Yes, but -mtune doesn't imply -mcpu. If I set up only -mtune, -mcpu is the 
> generic one (ppc970 for BE)

But that is not what the patch does?

> > > Linux also does similarly in linux64.h:
> > >  74 #undef  PROCESSOR_DEFAULT
> > >  75 #define PROCESSOR_DEFAULT PROCESSOR_POWER7
> > >  76 #undef  PROCESSOR_DEFAULT64
> > >  77 #define PROCESSOR_DEFAULT64 PROCESSOR_POWER8
> > 
> > Yes, but we still default to power4 on BE Linux (and power8 on LE).  I
> > get lost in the macro maze here, not sure how that works :-)

I still am baffled how this works :-/

> > > Although there is hard to explain (for me) setting to tune for POWER7 on 
> > > 32-bits. POWER7 is 64-bit and it should be more reasonable to optimize 
> > > for the last 32-bit machines that still may be in use (so G4).
> > 
> > 7450 has very different optimisation than 970.  Power7 and 970 have
> > largely similar pipelines.
> Yes, but the point is that users on 32-bit machines don't use POWER7, but 
> most likely G4.

Ah, but most users using -m32 are on a 64-bit machine!

> > > That said, on the 64-bit front, we will just match the Linux setting.
> > 
> > Compile a very simple test and look at the .machine in the generated .s?
> > Does that do what you want?
> Yes, I just tested it (on BE).
> pkubaj@talos:$/usr/home/pkubaj$ cat test.c
> #include 
> 
> int main()
> {
> printf("Hello world!");
> }
> 
> I built it twice, with GCC 9.3 without my patch and with GCC 10.1 with my 
> patch. The only difference is:
> pkubaj@talos:$/usr/home/pkubaj$ diff -u test.s.9 test.s.10
> --- test.s.92020-12-14 15:51:43.203263000 +0100
> +++ test.s.10   2020-12-14 15:52:01.147238000 +0100
> @@ -43,5 +43,5 @@
> .cfi_endproc
>  .LFE1:
> .size   main,.-main
> -   .ident  "GCC: (FreeBSD Ports Collection) 9.3.0"
> +   .ident  "GCC: (FreeBSD Ports Collection) 10.2.0"
> .section.note.GNU-stack,"",@progbits
> 
> Both have .machine power4:
> pkubaj@talos:$/usr/home/pkubaj$ grep .machine test.s.*
> test.s.10:  .machine power4
> test.s.9:   .machine power4
> 
> I'm not sure where GCC sets power8 for LE, but it's definitely somewhere else.

Yes...  And I do not know where this power4 comes from.  Mysteries :-)

> So IMO this patch is good to go.

Yes, thanks!


Segher

Re: [PATCH] ira.c: Fix ICE in ira-color [PR97092]

[Andrea Corallo via Gcc-patches]

Vladimir Makarov  writes:

> On 2020-12-10 10:12 a.m., Andrea Corallo wrote:
>> Hi all,
>>
>> following discussion on PR97092 I'd like to submit the following patch
>> with a fix plus associated testcase.
>>
>> With this patch applied mode is recomputed at each iteration while
>> looping across different copies in 'update_costs_from_allocno', this
>> instead of carrying mode over subsequent iterations.
>>
>> bootstrapped and regtested on aarch64-unknown-linux-gnu.
>>
>> Okay for trunk?
>>
> Yes.
>
> The patch is safe.. Thank you for working on the PR.

Hi Vladimir,

the same patch cleanly applies on gcc-10 where the same bug is present.

I bootstrapped and regtested gcc-10 on aarch64-unknown-linux-gnu.

Is it okay to backport?

Thanks

  Andrea

Re: [PATCH]AArch64: Add NEON, SVE and SVE2 RTL patterns for Complex Addition, Multiply and FMA.

[Richard Sandiford via Gcc-patches]

Tamar Christina  writes:
> Hi Richard, 
>
> Do you object to me splitting off complex add and addressing your remaining
> feedback later when the rewrite of mul and fma are done. 

No, sounds good to me.

Thanks,
Richard

[PATCH] gcov: fix line output for nested functions in JSON format

[Martin Liška]

Hello.

The patch fixes intermediate format for situations where we have
a nested function or a lambda function. In that case, line number
was wrong.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'll install the patch if there are no objections.

Martin

gcc/ChangeLog:

PR gcov-profile/98273
* gcov.c (output_json_intermediate_file): Use stack of nested
functions for lines in a source file.  Pop when a function ends.
---
 gcc/gcov.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/gcc/gcov.c b/gcc/gcov.c
index daa1266db86..8dcec9432a6 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -1165,7 +1165,7 @@ output_json_intermediate_file (json::array *json_files, 
source_info *src)
   json::array *lineso = new json::array ();
   root->set ("lines", lineso);
 
-  function_info *last_non_group_fn = NULL;

+  vector last_non_group_fns;
 
   for (unsigned line_num = 1; line_num <= src->lines.size (); line_num++)

 {
@@ -1177,7 +1177,7 @@ output_json_intermediate_file (json::array *json_files, 
source_info *src)
 it2 != fns->end (); it2++)
  {
if (!(*it2)->is_group)
- last_non_group_fn = *it2;
+ last_non_group_fns.push_back (*it2);
 
 	vector  = (*it2)->lines;

/* The LINES array is allocated only for group functions.  */
@@ -1191,9 +1191,17 @@ output_json_intermediate_file (json::array *json_files, 
source_info *src)
 
   /* Follow with lines associated with the source file.  */

   if (line_num < src->lines.size ())
-   output_intermediate_json_line (lineso, >lines[line_num], line_num,
-  (last_non_group_fn != NULL
-   ? last_non_group_fn->m_name : NULL));
+   {
+ unsigned size = last_non_group_fns.size ();
+ function_info *last_fn = size > 0 ? last_non_group_fns[size - 1] : 
NULL;
+ const char *fname = last_fn ? last_fn->m_name : NULL;
+ output_intermediate_json_line (lineso, >lines[line_num], 
line_num,
+fname);
+
+ /* Pop ending function from stack.  */
+ if (last_fn != NULL && last_fn->end_line == line_num)
+   last_non_group_fns.pop_back ();
+   }
 }
 }
 
--

2.29.2

[PATCH][pushed] gcov: Update comments.

[Martin Liška]

The patch updates comments in gcov.c file.

Pushed to master.

gcc/ChangeLog:

* gcov.c (output_json_intermediate_file): Update comments.
---
 gcc/gcov.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/gcov.c b/gcc/gcov.c
index 36938bd0fce..daa1266db86 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -293,7 +293,7 @@ public:
   /* Index of source file where the function is defined.  */
   unsigned src;
 
-  /* Vector of line information.  */

+  /* Vector of line information (used only for group functions).  */
   vector lines;
 
   /* Next function.  */

@@ -1172,7 +1172,7 @@ output_json_intermediate_file (json::array *json_files, 
source_info *src)
   vector *fns = src->get_functions_at_location (line_num);
 
   if (fns != NULL)

-   /* Print first group functions that begin on the line.  */
+   /* Print info for all group functions that begin on the line.  */
for (vector::iterator it2 = fns->begin ();
 it2 != fns->end (); it2++)
  {
@@ -1180,6 +1180,7 @@ output_json_intermediate_file (json::array *json_files, 
source_info *src)
  last_non_group_fn = *it2;
 
 	vector  = (*it2)->lines;

+   /* The LINES array is allocated only for group functions.  */
for (unsigned i = 0; i < lines.size (); i++)
  {
line_info *line = [i];
--
2.29.2

[Ada] Small adjustments to fixed-point I/O units

[Pierre-Marie de Rodat]

The first adjustment is to the documentation contained in the units,
which explains the implementation choices. The second adjustment is
to the size selection mechanism, which is better done on base types.

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

gcc/ada/

* libgnat/a-tifiio.adb: Adjust documentation.
(OK_Get_32): Compare the object size of the base type.
(OK_Put_32): Likewise.
(OK_Get_64): Likewise.
(OK_Put_64): Likewise.
* libgnat/a-tifiio__128.adb: Adjust documentation.
(OK_Get_32): Compare the object size of the base type.
(OK_Put_32): Likewise.
(OK_Get_64): Likewise.
(OK_Put_64): Likewise.
(OK_Get_128): Likewise.
(OK_Put_128): Likewise.
* libgnat/a-wtfiio.adb (OK_Get_32): Likewise.
(OK_Put_32): Likewise.
(OK_Get_64): Likewise.
(OK_Put_64): Likewise
* libgnat/a-wtfiio__128.adb (OK_Get_32): Likewise.
(OK_Put_32): Likewise.
(OK_Get_64): Likewise.
(OK_Put_64): Likewise.
(OK_Get_128): Likewise.
(OK_Put_128): Likewise.
* libgnat/a-ztfiio.adb (OK_Get_32): Likewise.
(OK_Put_32): Likewise.
(OK_Get_64): Likewise.
(OK_Put_64): Likewise
* libgnat/a-ztfiio__128.adb (OK_Get_32): Likewise.
(OK_Put_32): Likewise.
(OK_Get_64): Likewise.
(OK_Put_64): Likewise.
(OK_Get_128): Likewise.
(OK_Put_128): Likewise.diff --git a/gcc/ada/libgnat/a-tifiio.adb b/gcc/ada/libgnat/a-tifiio.adb
--- a/gcc/ada/libgnat/a-tifiio.adb
+++ b/gcc/ada/libgnat/a-tifiio.adb
@@ -29,8 +29,9 @@
 --  --
 --
 
---  Fixed point I/O
---  ---
+--  ---
+--  - Fixed point I/O -
+--  ---
 
 --  The following text documents implementation details of the fixed point
 --  input/output routines in the GNAT runtime. The first part describes the
@@ -40,7 +41,7 @@
 --  Subsequently these are reduced to implementation constraints and the impact
 --  of these constraints on a few possible approaches to input/output is given.
 --  Based on this analysis, a specific implementation is selected for use in
---  the GNAT runtime. Finally, the chosen algorithm is analyzed numerically in
+--  the GNAT runtime. Finally the chosen algorithms are analyzed numerically in
 --  order to provide user-level documentation on limits for range and precision
 --  of fixed point types as well as accuracy of input/output conversions.
 
@@ -68,7 +69,7 @@
 --  Operations
 --  --
 
---  'Image and 'Wide_Image (see RM 3.5(34))
+--  [Wide_[Wide_]]Image attribute (see RM 3.5(27.1/2))
 
 --  These attributes return a decimal real literal best approximating
 --  the value (rounded away from zero if halfway between) with a
@@ -88,7 +89,7 @@
 --  attributes, although it would be nice to be able to output more
 --  than S'Aft digits after the decimal point for values of subtype S.
 
---  'Value and 'Wide_Value attribute (RM 3.5(40-55))
+--  [Wide_[Wide_]]Value attribute (RM 3.5(39.1/2))
 
 --  Since the input can be given in any base in the range 2..16,
 --  accurate conversion to a fixed point number may require
@@ -121,7 +122,7 @@
 --  be less than 2.0**(-53).
 
 --  In GNAT, Fine_Delta is 2.0**(-63), and Duration for example is a 64-bit
---  type. This means that a floating-point type with 63 bits of mantissa needs
+--  type. This means that a floating-point type with 64 bits of mantissa needs
 --  to be used, which is only generally available on the x86 architecture. It
 --  would still be possible to use multi-precision floating point to perform
 --  calculations using longer mantissas, but this is a much harder approach.
@@ -137,9 +138,21 @@
 
 --  Fixed-precision integer arithmetic has the advantage of simplicity and
 --  speed. For the most common fixed point types this would be a perfect
---  solution. The downside however may be a too limited set of acceptable
+--  solution. The downside however may be a restricted set of acceptable
 --  fixed point types.
 
+--  Implementation Choices
+--  --
+
+--  The current implementation in the GNAT runtime uses fixed-precision integer
+--  arithmetic for fixed point types whose Small is the ratio of two integers
+--  whose magnitude is bounded relatively to the size of the mantissa, with a
+--  two-tiered approach for 32-bit and 64-bit fixed point types. For the other
+--  fixed point types, the implementation uses floating-point arithmetic.
+
+--  The exact requirements of the algorithms are analyzed and documented along
+--  with the implementation in their respective units.
+
 with Interfaces;
 with Ada.Text_IO.Fixed_Aux;
 with Ada.Text_IO.Float_Aux;
@@ -171,7 +184,7 @@ package body Ada.Text_IO.Fixed_IO is
--  

[Ada] Small cleanup in the Ada.Text_IO hierarchy

[Pierre-Marie de Rodat]

This replaces the remaining uses of Current_Input with Current_In and
those of Current_Output with Current_Out for the sake of consistency.

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

gcc/ada/

* libgnat/a-tifiio.adb (Get): Replace Current_Input with Current_In.
* libgnat/a-tifiio__128.adb: (Get): Likewise.
* libgnat/a-wtcoio.adb (Get): Likewise.
(Put): Replace Current_Output with Current_Out.
* libgnat/a-wtdeio.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-wtdeio__128.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-wtenio.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-wtfiio.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-wtfiio__128.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-wtflio.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-wtinio.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-wtinio__128.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-wtmoio.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-wtmoio__128.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-ztcoio.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-ztdeio.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-ztdeio__128.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-ztenio.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-ztfiio.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-ztfiio__128.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-ztflio.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-ztinio.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-ztinio__128.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-ztmoio.adb (Get): Likewise.
(Put): Likewise.
* libgnat/a-ztmoio__128.adb (Get): Likewise.
(Put): Likewise.diff --git a/gcc/ada/libgnat/a-tifiio.adb b/gcc/ada/libgnat/a-tifiio.adb
--- a/gcc/ada/libgnat/a-tifiio.adb
+++ b/gcc/ada/libgnat/a-tifiio.adb
@@ -278,7 +278,7 @@ package body Ada.Text_IO.Fixed_IO is
   Width : Field := 0)
is
begin
-  Get (Current_Input, Item, Width);
+  Get (Current_In, Item, Width);
end Get;
 
procedure Get


diff --git a/gcc/ada/libgnat/a-tifiio__128.adb b/gcc/ada/libgnat/a-tifiio__128.adb
--- a/gcc/ada/libgnat/a-tifiio__128.adb
+++ b/gcc/ada/libgnat/a-tifiio__128.adb
@@ -318,7 +318,7 @@ package body Ada.Text_IO.Fixed_IO is
   Width : Field := 0)
is
begin
-  Get (Current_Input, Item, Width);
+  Get (Current_In, Item, Width);
end Get;
 
procedure Get


diff --git a/gcc/ada/libgnat/a-wtcoio.adb b/gcc/ada/libgnat/a-wtcoio.adb
--- a/gcc/ada/libgnat/a-wtcoio.adb
+++ b/gcc/ada/libgnat/a-wtcoio.adb
@@ -78,7 +78,7 @@ package body Ada.Wide_Text_IO.Complex_IO is
   Width : Field := 0)
is
begin
-  Get (Current_Input, Item, Width);
+  Get (Current_In, Item, Width);
end Get;
 
-
@@ -133,7 +133,7 @@ package body Ada.Wide_Text_IO.Complex_IO is
   Exp  : Field := Default_Exp)
is
begin
-  Put (Current_Output, Item, Fore, Aft, Exp);
+  Put (Current_Out, Item, Fore, Aft, Exp);
end Put;
 
-


diff --git a/gcc/ada/libgnat/a-wtdeio.adb b/gcc/ada/libgnat/a-wtdeio.adb
--- a/gcc/ada/libgnat/a-wtdeio.adb
+++ b/gcc/ada/libgnat/a-wtdeio.adb
@@ -89,7 +89,7 @@ package body Ada.Wide_Text_IO.Decimal_IO is
   Width : Field := 0)
is
begin
-  Get (Current_Input, Item, Width);
+  Get (Current_In, Item, Width);
end Get;
 
procedure Get
@@ -144,7 +144,7 @@ package body Ada.Wide_Text_IO.Decimal_IO is
   Exp  : Field := Default_Exp)
is
begin
-  Put (Current_Output, Item, Fore, Aft, Exp);
+  Put (Current_Out, Item, Fore, Aft, Exp);
end Put;
 
procedure Put


diff --git a/gcc/ada/libgnat/a-wtdeio__128.adb b/gcc/ada/libgnat/a-wtdeio__128.adb
--- a/gcc/ada/libgnat/a-wtdeio__128.adb
+++ b/gcc/ada/libgnat/a-wtdeio__128.adb
@@ -102,7 +102,7 @@ package body Ada.Wide_Text_IO.Decimal_IO is
   Width : Field := 0)
is
begin
-  Get (Current_Input, Item, Width);
+  Get (Current_In, Item, Width);
end Get;
 
procedure Get
@@ -162,7 +162,7 @@ package body Ada.Wide_Text_IO.Decimal_IO is
   Exp  : Field := Default_Exp)
is
begin
-  Put (Current_Output, Item, Fore, Aft, Exp);
+  Put (Current_Out, Item, Fore, Aft, Exp);
end Put;
 
procedure Put


diff --git a/gcc/ada/libgnat/a-wtenio.adb b/gcc/ada/libgnat/a-wtenio.adb
--- a/gcc/ada/libgnat/a-wtenio.adb
+++ b/gcc/ada/libgnat/a-wtenio.adb
@@ -51,7 +51,7 @@ package body Ada.Wide_Text_IO.Enumeration_IO is
 
procedure Get (Item : out Enum) is
begin
-  Get (Current_Input, Item);
+  Get (Current_In, Item);
end Get;
 
procedure Get
@@ -88,7 +88,7 @@ package body 

[Ada] Fix compile time evaluation of shift intrinsics

[Pierre-Marie de Rodat]

Recent improvements to sem_eval.adb (Fold_Shift) do not take into
account that these operations should be performed on the base type.

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

gcc/ada/

* sem_eval.adb (Fold_Shift): Compute values using the base type.diff --git a/gcc/ada/sem_eval.adb b/gcc/ada/sem_eval.adb
--- a/gcc/ada/sem_eval.adb
+++ b/gcc/ada/sem_eval.adb
@@ -4785,7 +4785,7 @@ package body Sem_Eval is
   Static : Boolean := False;
   Check_Elab : Boolean := False)
is
-  Typ : constant Entity_Id := Etype (Left);
+  Typ : constant Entity_Id := Base_Type (Etype (Left));
 
   procedure Check_Elab_Call;
   --  Add checks related to calls in elaboration code

[Ada] Analyze second parameter of attribute Scaling

[Pierre-Marie de Rodat]

Attribute Scaling has two parameters but only one of them has been
resolved.

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

gcc/ada/

* sem_attr.adb (Analyze_Attribute): Resolve second parameter of
attribute Scaling just like it is resolved for a similar
attribute Compose.diff --git a/gcc/ada/sem_attr.adb b/gcc/ada/sem_attr.adb
--- a/gcc/ada/sem_attr.adb
+++ b/gcc/ada/sem_attr.adb
@@ -5953,6 +5953,7 @@ package body Sem_Attr is
  Check_Floating_Point_Type_2;
  Set_Etype (N, P_Base_Type);
  Resolve (E1, P_Base_Type);
+ Resolve (E2, Any_Integer);
 
   --
   -- Signed_Zeros --

[Ada] Fix internal error on bit-packed array in Volatile_Full_Access record

[Pierre-Marie de Rodat]

This fixes an issue in Remove_Side_Effects, which insists that a renaming
be handled by the back-end whereas Evaluation_Required says that it should
be handled by the front-end (renamings involving Volatile_Full_Access must
be fully expanded by the front-end).

This also reinstates an earlier fix in Expand_Bit_Packed_Element_Set which
was dropped and is again necessary because of the previous change.

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

gcc/ada/

* exp_pakd.adb (Expand_Bit_Packed_Element_Set): Fix again packed
array type in complex cases where array is Volatile.
* exp_util.adb (Remove_Side_Effects): Do not force a renaming to
be handled by the back-end.diff --git a/gcc/ada/exp_pakd.adb b/gcc/ada/exp_pakd.adb
--- a/gcc/ada/exp_pakd.adb
+++ b/gcc/ada/exp_pakd.adb
@@ -1256,8 +1256,15 @@ package body Exp_Pakd is
  --  array type on Obj to get lost. So we save the type of Obj, and
  --  make sure it is reset properly.
 
- New_Lhs := Duplicate_Subexpr (Obj, Name_Req => True);
- New_Rhs := Duplicate_Subexpr_No_Checks (Obj);
+ declare
+T : constant Entity_Id := Etype (Obj);
+ begin
+New_Lhs := Duplicate_Subexpr (Obj, Name_Req => True);
+New_Rhs := Duplicate_Subexpr_No_Checks (Obj);
+Set_Etype (Obj, T);
+Set_Etype (New_Lhs, T);
+Set_Etype (New_Rhs, T);
+ end;
 
  --  First we deal with the "and"
 


diff --git a/gcc/ada/exp_util.adb b/gcc/ada/exp_util.adb
--- a/gcc/ada/exp_util.adb
+++ b/gcc/ada/exp_util.adb
@@ -11798,8 +11798,8 @@ package body Exp_Util is
   --  If this is a packed array component or a selected component with a
   --  nonstandard representation, we cannot generate a reference because
   --  the component may be unaligned, so we must use a renaming and this
-  --  renaming must be handled by the front end, as the back end may balk
-  --  at the nonstandard representation (see Exp_Ch2.Expand_Renaming).
+  --  renaming is handled by the front end, as the back end may balk at
+  --  the nonstandard representation (see Evaluation_Required in Exp_Ch8).
 
   elsif Nkind (Exp) in N_Indexed_Component | N_Selected_Component
 and then Has_Non_Standard_Rep (Etype (Prefix (Exp)))
@@ -11813,8 +11813,7 @@ package body Exp_Util is
  Subtype_Mark=> New_Occurrence_Of (Exp_Type, Loc),
  Name=> Relocate_Node (Exp)));
 
-  --  For an expression that denotes a name, we can use a renaming scheme
-  --  that is handled by the back end, instead of the front end as above.
+  --  For an expression that denotes a name, we can use a renaming scheme.
   --  This is needed for correctness in the case of a volatile object of
   --  a nonvolatile type because the Make_Reference call of the "default"
   --  approach would generate an illegal access value (an access value
@@ -11837,8 +11836,6 @@ package body Exp_Util is
  Subtype_Mark=> New_Occurrence_Of (Exp_Type, Loc),
  Name=> Relocate_Node (Exp)));
 
- Set_Is_Renaming_Of_Object (Def_Id, False);
-
   --  Avoid generating a variable-sized temporary, by generating the
   --  reference just for the function call. The transformation could be
   --  refined to apply only when the array component is constrained by a

[Ada] Process Truncation just like other floating point attributes

[Pierre-Marie de Rodat]

Analysis of attribute Truncation was first calling Resolve and then
Set_Etype, while all the similar attributes had these calls in the
reverse order. This inconsistency was present since the support for
Truncation was added, but it had no semantics implications.

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

gcc/ada/

* sem_attr.adb (Analyze_Attribute): Merge similar code for
Truncation and other floating point attributes.diff --git a/gcc/ada/sem_attr.adb b/gcc/ada/sem_attr.adb
--- a/gcc/ada/sem_attr.adb
+++ b/gcc/ada/sem_attr.adb
@@ -3402,6 +3402,7 @@ package body Sem_Attr is
  | Attribute_Machine_Rounding
  | Attribute_Model
  | Attribute_Rounding
+ | Attribute_Truncation
  | Attribute_Unbiased_Rounding
   =>
  Check_Floating_Point_Type_1;
@@ -6409,10 +6410,7 @@ package body Sem_Attr is
   -- Truncation --
   
 
-  when Attribute_Truncation =>
- Check_Floating_Point_Type_1;
- Resolve (E1, P_Base_Type);
- Set_Etype (N, P_Base_Type);
+  --  Shares processing with Ceiling attribute
 
   
   -- Type_Class --

[Ada] Incorrect accessibility level on type in formal package

[Pierre-Marie de Rodat]

This patch fixes an issue in the compiler whereby a class-wide allocator
for a type declared within a generic formal package was not treated the
same as a formal type with respect to accessibility checks - leading to
spurious accessibility errors.

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

gcc/ada/

* sem_util.adb, sem_util.ads (In_Generic_Formal_Package):
Created to identify type declarations occurring within generic
formal packages.
* sem_res.adb (Resolve_Allocator): Add condition to avoid
emitting an error for allocators when the type being allocated
is class-wide and from a generic formal package.diff --git a/gcc/ada/sem_res.adb b/gcc/ada/sem_res.adb
--- a/gcc/ada/sem_res.adb
+++ b/gcc/ada/sem_res.adb
@@ -5451,9 +5451,12 @@ package body Sem_Res is
 
--  Do not apply Ada 2005 accessibility checks on a class-wide
--  allocator if the type given in the allocator is a formal
-   --  type. A run-time check will be performed in the instance.
+   --  type or within a formal package. A run-time check will be
+   --  performed in the instance.
 
-   elsif not Is_Generic_Type (Exp_Typ) then
+   elsif not Is_Generic_Type (Exp_Typ)
+ and then not In_Generic_Formal_Package (Exp_Typ)
+   then
   Error_Msg_N
 ("type in allocator has deeper level than designated "
  & "class-wide type", E);


diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -13827,6 +13827,28 @@ package body Sem_Util is
   and then Assertion_Expression_Pragma (Get_Pragma_Id (Prag));
end In_Assertion_Expression_Pragma;
 
+   ---
+   -- In_Generic_Formal_Package --
+   ---
+
+   function In_Generic_Formal_Package (E : Entity_Id) return Boolean is
+  Par : Node_Id;
+
+   begin
+  Par := Parent (E);
+  while Present (Par) loop
+ if Nkind (Par) = N_Formal_Package_Declaration
+   or else Nkind (Original_Node (Par)) = N_Formal_Package_Declaration
+ then
+return True;
+ end if;
+
+ Par := Parent (Par);
+  end loop;
+
+  return False;
+   end In_Generic_Formal_Package;
+
--
-- In_Generic_Scope --
--


diff --git a/gcc/ada/sem_util.ads b/gcc/ada/sem_util.ads
--- a/gcc/ada/sem_util.ads
+++ b/gcc/ada/sem_util.ads
@@ -1538,6 +1538,9 @@ package Sem_Util is
--  Returns True if node N appears within a pragma that acts as an assertion
--  expression. See Sem_Prag for the list of qualifying pragmas.
 
+   function In_Generic_Formal_Package (E : Entity_Id) return Boolean;
+   --  Returns True if entity E is inside a generic formal package
+
function In_Generic_Scope (E : Entity_Id) return Boolean;
--  Returns True if entity E is inside a generic scope
 

[Ada] Implement part of System.Fat_Gen more efficiently

[Pierre-Marie de Rodat]

This reimplements the low-level primitives of System.Fat_Gen, i.e.
Copy_Sign, Decompose and Scaling more efficiently, by using the same
direct approach as the existing implementation of Valid; only the
normalization of denormalized numbers and the gradual underflow are
still left to the hardware.

This also speeds up Pred and Succ for denormalized numbers.

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

gcc/ada/

* libgnat/s-fatgen.ads (Compose): Add pragma Inline.
(Copy_Sign): Likewise.
(Exponent): Likewise.
(Fraction): Likewise.
* libgnat/s-fatgen.adb: Remove with clause for System, add
with and use clauses for System.Unsigned_Types.
Add pragma Warnings (Off) for non-static constants.
Remove precomputed tables of powers of radix and add a few
constants describing the floating-point format.
(Gradual_Scaling): Delete.
(Copy_Sign): Reimplement directly.
(Decompose): Likewise.
(Scaling): Likewise.
(Pred): Speed up.
(Succ): Likewise.
(Truncation): Tidy up.
(Valid): Move constants to library level.

patch.diff.gz
Description: application/gzip

[Ada] Adjust again previous change to System.Fat_Gen

[Pierre-Marie de Rodat]

This removes the direct declaration of the smallest denormalized number
and replaces it with an overlay of the equivalent integer constant,
because such a direct declaration cannot be translated into C90.

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

gcc/ada/

* libgnat/s-fatgen.adb: Add with clause for Interfaces and use
type clause for Interfaces.Unsigned_64.
(Small): Comment out.
(Tiny): Likewise.
(Tiny16): New integer constant.
(Tiny32): Likewise.
(Tiny64): Likewise.
(Tiny80): New integer array constant.
(Pred): Declare a local overlay for Tiny.
(Succ): Likewise.diff --git a/gcc/ada/libgnat/s-fatgen.adb b/gcc/ada/libgnat/s-fatgen.adb
--- a/gcc/ada/libgnat/s-fatgen.adb
+++ b/gcc/ada/libgnat/s-fatgen.adb
@@ -35,12 +35,15 @@
 --  floating-point implementations.
 
 with Ada.Unchecked_Conversion;
+with Interfaces;
 with System.Unsigned_Types;
 
 pragma Warnings (Off, "non-static constant in preelaborated unit");
 --  Every constant is static given our instantiation model
 
 package body System.Fat_Gen is
+   use type Interfaces.Unsigned_64;
+
pragma Assert (T'Machine_Radix = 2);
--  This version does not handle radix 16
 
@@ -53,13 +56,22 @@ package body System.Fat_Gen is
Invrad : constant T := 1.0 / Rad;
--  Smallest positive mantissa in the canonical form (RM A.5.3(4))
 
-   Small : constant T := Rad ** (T'Machine_Emin - 1);
-   pragma Unreferenced (Small);
+   --  Small : constant T := Rad ** (T'Machine_Emin - 1);
--  Smallest positive normalized number
 
-   Tiny : constant T := Rad ** (T'Machine_Emin - Mantissa);
+   --  Tiny : constant T := Rad ** (T'Machine_Emin - Mantissa);
--  Smallest positive denormalized number
 
+   Tiny16 : constant Interfaces.Unsigned_16 := 1;
+   Tiny32 : constant Interfaces.Unsigned_32 := 1;
+   Tiny64 : constant Interfaces.Unsigned_64 := 1;
+   Tiny80 : constant array (1 .. 2) of Interfaces.Unsigned_64 :=
+  (1 * Standard'Default_Bit_Order,
+   2**48 * (1 - Standard'Default_Bit_Order));
+   --  We cannot use the direct declaration because it cannot be translated
+   --  into C90, as the hexadecimal floating constants were introduced in C99.
+   --  So we work around this by using an overlay of the integer constant.
+
RM1 : constant T := Rad ** (Mantissa - 1);
--  Smallest positive member of the large consecutive integers. It is equal
--  to the ratio Small / Tiny, which means that multiplying by it normalizes
@@ -411,6 +423,13 @@ package body System.Fat_Gen is
--
 
function Pred (X : T) return T is
+  Tiny : constant T;
+  pragma Import (Ada, Tiny);
+  for Tiny'Address use (if T'Size   = 16 then Tiny16'Address
+ elsif T'Size   = 32 then Tiny32'Address
+ elsif T'Size   = 64 then Tiny64'Address
+ elsif Mantissa = 64 then Tiny80'Address
+ else raise Program_Error);
   X_Frac : T;
   X_Exp  : UI;
 
@@ -676,6 +695,13 @@ package body System.Fat_Gen is
--
 
function Succ (X : T) return T is
+  Tiny : constant T;
+  pragma Import (Ada, Tiny);
+  for Tiny'Address use (if T'Size   = 16 then Tiny16'Address
+ elsif T'Size   = 32 then Tiny32'Address
+ elsif T'Size   = 64 then Tiny64'Address
+ elsif Mantissa = 64 then Tiny80'Address
+ else raise Program_Error);
   X_Frac : T;
   X_Exp  : UI;
 

[Ada] Adjust previous change to System.Fat_Gen

[Pierre-Marie de Rodat]

This removes the use clause for System.Unsigned_Type and replaces it
with a localized use type clause for Long_Long_Unsigned.

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

gcc/ada/

* libgnat/s-fatgen.adb: Remove use clause for
System.Unsigned_Types.
(Scaling): Add renaming of System.Unsigned_Types and use type
clause for Long_Long_Unsigned.diff --git a/gcc/ada/libgnat/s-fatgen.adb b/gcc/ada/libgnat/s-fatgen.adb
--- a/gcc/ada/libgnat/s-fatgen.adb
+++ b/gcc/ada/libgnat/s-fatgen.adb
@@ -35,7 +35,7 @@
 --  floating-point implementations.
 
 with Ada.Unchecked_Conversion;
-with System.Unsigned_Types; use System.Unsigned_Types;
+with System.Unsigned_Types;
 
 pragma Warnings (Off, "non-static constant in preelaborated unit");
 --  Every constant is static given our instantiation model
@@ -586,6 +586,9 @@ package body System.Fat_Gen is
   pragma Assert (Mantissa <= 64);
   --  This implementation handles only 80-bit IEEE Extended or smaller
 
+  package UST renames System.Unsigned_Types;
+  use type UST.Long_Long_Unsigned;
+
   XX : T := T'Machine (X);
 
   Rep : Float_Rep;
@@ -661,7 +664,7 @@ package body System.Fat_Gen is
 Float_Word (IEEE_Ebias + Expf) * Exp_Factor;
 
  if Expi < 0 then
-XX := XX / T (Long_Long_Unsigned (2) ** (-Expi));
+XX := XX / T (UST.Long_Long_Unsigned (2) ** (-Expi));
  end if;
 
  return XX;

[Ada] Implement AI12-0398-1/03

[Pierre-Marie de Rodat]

This commit implements AI12-0398-1/03, which adds the ability to specify
aspects on discriminant specifications, extended return object
declarations and entry index specifications.

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

gcc/ada/

* par-ch3.adb (P_Discriminant_Part_Opt): Parse aspects, update
documentation.
* par-ch6.adb (P_Return_Statement): Likewise.
* par-ch9.adb (P_Entry_Index_Specification): Likewise.diff --git a/gcc/ada/par-ch3.adb b/gcc/ada/par-ch3.adb
--- a/gcc/ada/par-ch3.adb
+++ b/gcc/ada/par-ch3.adb
@@ -3002,9 +3002,9 @@ package body Ch3 is
 
--  DISCRIMINANT_SPECIFICATION ::=
--DEFINING_IDENTIFIER_LIST : [NULL_EXCLUSION] SUBTYPE_MARK
-   --  [:= DEFAULT_EXPRESSION]
+   --  [:= DEFAULT_EXPRESSION] [ASPECT_SPECIFICATION]
--  | DEFINING_IDENTIFIER_LIST : ACCESS_DEFINITION
-   --  [:= DEFAULT_EXPRESSION]
+   --  [:= DEFAULT_EXPRESSION] [ASPECT_SPECIFICATION]
 
--  If no known discriminant part is present, then No_List is returned
 
@@ -3098,6 +3098,10 @@ package body Ch3 is
Set_Expression
  (Specification_Node, Init_Expr_Opt (True));
 
+   if Token = Tok_With then
+  P_Aspect_Specifications (Specification_Node, False);
+   end if;
+
if Ident > 1 then
   Set_Prev_Ids (Specification_Node, True);
end if;


diff --git a/gcc/ada/par-ch6.adb b/gcc/ada/par-ch6.adb
--- a/gcc/ada/par-ch6.adb
+++ b/gcc/ada/par-ch6.adb
@@ -1770,7 +1770,8 @@ package body Ch6 is
--
--  EXTENDED_RETURN_STATEMENT ::=
--return DEFINING_IDENTIFIER : [aliased] RETURN_SUBTYPE_INDICATION
-   --   [:= EXPRESSION] [do
+   --   [:= EXPRESSION]
+   --   [ASPECT_SPECIFICATION] [do
--  HANDLED_SEQUENCE_OF_STATEMENTS
--end return];
--
@@ -1916,6 +1917,7 @@ package body Ch6 is
   Ret_Sloc : constant Source_Ptr := Token_Ptr;
   Ret_Strt : constant Column_Number := Start_Column;
   Ret_Node : Node_Id;
+  Decl : Node_Id;
 
--  Start of processing for P_Return_Statement
 
@@ -1955,8 +1957,12 @@ package body Ch6 is
 end if;
 
 Ret_Node := New_Node (N_Extended_Return_Statement, Ret_Sloc);
-Set_Return_Object_Declarations
-  (Ret_Node, New_List (P_Return_Object_Declaration));
+Decl := P_Return_Object_Declaration;
+Set_Return_Object_Declarations (Ret_Node, New_List (Decl));
+
+if Token = Tok_With then
+   P_Aspect_Specifications (Decl, False);
+end if;
 
 if Token = Tok_Do then
Push_Scope_Stack;


diff --git a/gcc/ada/par-ch9.adb b/gcc/ada/par-ch9.adb
--- a/gcc/ada/par-ch9.adb
+++ b/gcc/ada/par-ch9.adb
@@ -1316,6 +1316,7 @@ package body Ch9 is
 
--  ENTRY_INDEX_SPECIFICATION ::=
--for DEFINING_IDENTIFIER in DISCRETE_SUBTYPE_DEFINITION
+   --[ASPECT_SPECIFICATION]
 
--  Error recovery: can raise Error_Resync
 
@@ -1329,6 +1330,11 @@ package body Ch9 is
   T_In;
   Set_Discrete_Subtype_Definition
 (Iterator_Node, P_Discrete_Subtype_Definition);
+
+  if Token = Tok_With then
+ P_Aspect_Specifications (Iterator_Node, False);
+  end if;
+
   return Iterator_Node;
end P_Entry_Index_Specification;
 

[Ada] Additional fixes for Default_Initial_Condition

[Pierre-Marie de Rodat]

After the recent implementation work for the Default_Initial_Condition
aspect there were still some cases where DIC checks weren't performed
properly with respect to calls to Initialize in the case of array and
record components of controlled types. That is now corrected. There was
also an issue of Output_Verification_Call getting called on partial DIC
procedures, when it should only be applied to the main DIC procedure
of a type, which could result in extraneous warnings, and that is also
corrected.

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

gcc/ada/

* exp_aggr.adb (Build_Array_Aggr_Code.Gen_Assign): Move
generation of the call for DIC check past the optional
generation of calls to controlled Initialize procedures.
* exp_ch3.adb
(Build_Array_Init_Proc.Init_One_Dimension.Possible_DIC_Call):
Suppress generation of a DIC call when the array component type
is controlled.  The call will now be generated later inside the
array's DI (Deep_Initialize) procedure.
* exp_ch7.adb
(Make_Deep_Array_Body.Build_Initialize_Statements): Generate a
DIC call (when needed by the array component type) after any
call to the component type's controlled Initialize procedure, or
generate the DIC call by itself if there's no Initialize to
call.
* sem_aggr.adb (Resolve_Record_Aggregate.Add_Association):
Simplify condition to only test Is_Box_Init_By_Default (previous
condition was overkill, as well as incorrect in some cases).
* sem_elab.adb (Active_Scenarios.Output_Call): For
Default_Initial_Condition, suppress call to
Output_Verification_Call when the subprogram is a partial DIC
procedure.diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
--- a/gcc/ada/exp_aggr.adb
+++ b/gcc/ada/exp_aggr.adb
@@ -1865,21 +1865,6 @@ package body Exp_Aggr is
Typ   => Ctype,
With_Default_Init => True));
 
-   --  If Default_Initial_Condition applies to the component type,
-   --  add a DIC check after the component is default-initialized.
-   --  It will be analyzed and resolved before the code for
-   --  initialization of other components.
-
-   --  Theoretically this might also be needed for cases where
-   --  the component type doesn't have an init proc (such as for
-   --  Default_Value cases), but those should be uncommon, and for
-   --  now we only support the init proc case. ???
-
-   if Has_DIC (Ctype) and then Present (DIC_Procedure (Ctype)) then
-  Append_To (Stmts,
-Build_DIC_Call (Loc, New_Copy_Tree (Indexed_Comp), Ctype));
-   end if;
-
--  If the component type has invariants, add an invariant
--  check after the component is default-initialized. It will
--  be analyzed and resolved before the code for initialization
@@ -1910,6 +1895,22 @@ package body Exp_Aggr is
   Append_To (Stmts, Init_Call);
end if;
 end if;
+
+--  If Default_Initial_Condition applies to the component type,
+--  add a DIC check after the component is default-initialized,
+--  as well as after an Initialize procedure is called, in the
+--  case of components of a controlled type. It will be analyzed
+--  and resolved before the code for initialization of other
+--  components.
+
+--  Theoretically this might also be needed for cases where Expr
+--  is not empty, but a default init still applies, such as for
+--  Default_Value cases, in which case we won't get here. ???
+
+if Has_DIC (Ctype) and then Present (DIC_Procedure (Ctype)) then
+   Append_To (Stmts,
+ Build_DIC_Call (Loc, New_Copy_Tree (Indexed_Comp), Ctype));
+end if;
  end if;
 
  return Add_Loop_Actions (Stmts);


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
@@ -697,6 +697,11 @@ package body Exp_Ch3 is
 
   and then not GNATprove_Mode
 
+  --  DIC checks for components of controlled types are done later
+  --  (see Exp_Ch7.Make_Deep_Array_Body).
+
+  and then not Is_Controlled (Comp_Type)
+
   and then Present (DIC_Procedure (Comp_Type))
 
   and then not Has_Null_Body (DIC_Procedure (Comp_Type))


diff --git a/gcc/ada/exp_ch7.adb b/gcc/ada/exp_ch7.adb
--- a/gcc/ada/exp_ch7.adb
+++ b/gcc/ada/exp_ch7.adb
@@ -6848,22 +6848,49 @@ package body Exp_Ch7 is
 
  Init_Call := Build_Initialization_Call;
 
- --  Only create finalization block if there is a non-trivial
- --  call to initialization.
-
- 

[Ada] Remove double initialization of the known value cache

[Pierre-Marie de Rodat]

Global variable CV_Cache, where values known at compilation time are
stored, was initialization both by elaboration and by
Sem_Eval.Initialize, which is called from Gnatdrv1 and required by the
GNSA (GNAT Semantic Analyzer).

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

gcc/ada/

* sem_eval.adb (CV_Cache): Remove initialization at elaboration.diff --git a/gcc/ada/sem_eval.adb b/gcc/ada/sem_eval.adb
--- a/gcc/ada/sem_eval.adb
+++ b/gcc/ada/sem_eval.adb
@@ -124,7 +124,7 @@ package body Sem_Eval is
 
type CV_Cache_Array is array (CV_Range) of CV_Entry;
 
-   CV_Cache : CV_Cache_Array := (others => (Node_High_Bound, Uint_0));
+   CV_Cache : CV_Cache_Array;
--  This is the actual cache, with entries consisting of node/value pairs,
--  and the impossible value Node_High_Bound used for unset entries.
 

[Ada] armhf-linux: symbolic tracebacks

[Pierre-Marie de Rodat]

Implement non-symbolic tracebacks as a first step towards symbolic.

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

gcc/ada/

* tracebak.c: Add a section for ARM Linux.diff --git a/gcc/ada/tracebak.c b/gcc/ada/tracebak.c
--- a/gcc/ada/tracebak.c
+++ b/gcc/ada/tracebak.c
@@ -309,6 +309,13 @@ __gnat_backtrace (void **array,
 #define USING_ARM_UNWINDING 1
 #endif
 
+/*-- ARM Linux  -*/
+#elif (defined (__ARMEL__) && defined (__linux))
+
+#define USE_GCC_UNWINDER
+#define PC_ADJUST -2
+#define USING_ARM_UNWINDING 1
+
 /*-- PPC AIX/PPC Lynx 178/Older Darwin --*/
 #elif ((defined (_POWER) && defined (_AIX)) || \
(defined (__powerpc__) && defined (__Lynx__) && !defined(__ELF__)) || \

[Ada] Simplify prevention of cascaded errors for Refined_State

[Pierre-Marie de Rodat]

The condition for adding a dummy constituent is now simpler (and seems
more robust) and the dummy constituent is Any_Id (which exists precisely
for avoiding cascaded errors). Finally, an assertion guards against
returning with an ill-formed refinement.

Cleanup only; the tool behaviour is unaffected.

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

gcc/ada/

* sem_prag.adb (Analyze_Refinement_Clause): Simplify recently
added code for preventing cascaded errors.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
@@ -28978,24 +28978,19 @@ package body Sem_Prag is
 
  Report_Unused_Constituents (Part_Of_Constits);
 
- --  Avoid a cascading error reporting a missing refinement by adding
- --  State_Id as dummy constituent of itself.
+ --  Avoid a cascading error reporting a missing refinement by adding a
+ --  dummy constituent.
 
- if Non_Null_Seen
-   and then not Has_Non_Null_Refinement (State_Id)
- then
-declare
-   Constits : Elist_Id := Refinement_Constituents (State_Id);
-begin
-   if No (Constits) then
-  Constits := New_Elmt_List;
-  Set_Refinement_Constituents (State_Id, Constits);
-   end if;
-
-   Append_Elmt (State_Id, Constits);
-   Set_Encapsulating_State (State_Id, State_Id);
-end;
+ if No (Refinement_Constituents (State_Id)) then
+Set_Refinement_Constituents (State_Id, New_Elmt_List (Any_Id));
  end if;
+
+ --  At this point the refinement might be dummy, but must be
+ --  well-formed, to prevent cascaded errors.
+
+ pragma Assert (Has_Null_Refinement (State_Id)
+  xor
+Has_Non_Null_Refinement (State_Id));
   end Analyze_Refinement_Clause;
 
   -

[Ada] Fix couple of bugs in the implementation of Round attribute

[Pierre-Marie de Rodat]

The first issue is that the attribute leaks into a multiplication or
a division explicitly done in another fixed-point type before being
passed to the attribute.  The second issue is that the attribute is
ignored for simple conversions from another fixed-point type.

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

gcc/ada/

* exp_attr.adb (Expand_N_Attribute_Reference) :
Adjust commentary and set the Rounded_Result flag on the type
conversion node when the node is needed.
* exp_ch4.adb (Expand_N_Type_Conversion): Minor tweak.
(Fixup_Universal_Fixed_Operation): Look through the type conversion
only when it is to Universal_Real.
* exp_fixd.adb: Remove with and use clauses for Snames.
(Build_Divide): Remove redundant test.
(Expand_Convert_Float_To_Fixed): Use Rounded_Result flag on the
node to set the truncation parameter.diff --git a/gcc/ada/exp_attr.adb b/gcc/ada/exp_attr.adb
--- a/gcc/ada/exp_attr.adb
+++ b/gcc/ada/exp_attr.adb
@@ -6196,20 +6196,19 @@ package body Exp_Attr is
   -- Round --
   ---
 
-  --  The handling of the Round attribute is quite delicate. The processing
-  --  in Sem_Attr introduced a conversion to universal real, reflecting the
-  --  semantics of Round, but we do not want anything to do with universal
-  --  real at runtime, since this corresponds to using floating-point
-  --  arithmetic.
+  --  The handling of the Round attribute is delicate when the operand is
+  --  universal fixed. In this case, the processing in Sem_Attr introduced
+  --  a conversion to universal real, reflecting the semantics of Round,
+  --  but we do not want anything to do with universal real at run time,
+  --  since this corresponds to using floating-point arithmetic.
 
   --  What we have now is that the Etype of the Round attribute correctly
   --  indicates the final result type. The operand of the Round is the
   --  conversion to universal real, described above, and the operand of
   --  this conversion is the actual operand of Round, which may be the
-  --  special case of a fixed point multiplication or division (Etype =
-  --  universal fixed)
+  --  special case of a fixed point multiplication or division.
 
-  --  The exapander will expand first the operand of the conversion, then
+  --  The expander will expand first the operand of the conversion, then
   --  the conversion, and finally the round attribute itself, since we
   --  always work inside out. But we cannot simply process naively in this
   --  order. In the semantic world where universal fixed and real really
@@ -6217,14 +6216,13 @@ package body Exp_Attr is
   --  implementation world, where universal real is a floating-point type,
   --  we would get the wrong result.
 
-  --  So the approach is as follows. First, when expanding a multiply or
-  --  divide whose type is universal fixed, we do nothing at all, instead
-  --  deferring the operation till later.
-
-  --  The actual processing is done in Expand_N_Type_Conversion which
-  --  handles the special case of Round by looking at its parent to see if
-  --  it is a Round attribute, and if it is, handling the conversion (or
-  --  its fixed multiply/divide child) in an appropriate manner.
+  --  So the approach is as follows. When expanding a multiply or divide
+  --  whose type is universal fixed, Fixup_Universal_Fixed_Operation will
+  --  look up and skip the conversion to universal real if its parent is
+  --  a Round attribute, taking information from this attribute node. In
+  --  the other cases, Expand_N_Type_Conversion does the same by looking
+  --  at its parent to see if it is a Round attribute, before calling the
+  --  fixed-point expansion routine.
 
   --  This means that by the time we get to expanding the Round attribute
   --  itself, the Round is nothing more than a type conversion (and will
@@ -6232,8 +6230,12 @@ package body Exp_Attr is
   --  appropriate conversion operation.
 
   when Attribute_Round =>
- Rewrite (N,
-   Convert_To (Etype (N), Relocate_Node (First (Exprs;
+ if Etype (First (Exprs)) = Etype (N) then
+Rewrite (N, Relocate_Node (First (Exprs)));
+ else
+Rewrite (N, Convert_To (Etype (N), First (Exprs)));
+Set_Rounded_Result (N);
+ end if;
  Analyze_And_Resolve (N);
 
   --


diff --git a/gcc/ada/exp_ch4.adb b/gcc/ada/exp_ch4.adb
--- a/gcc/ada/exp_ch4.adb
+++ b/gcc/ada/exp_ch4.adb
@@ -12556,9 +12556,9 @@ package body Exp_Ch4 is
and then Nkind (Parent (N)) = N_Attribute_Reference
and then Attribute_Name (Parent (N)) = Name_Round
  then
-Set_Rounded_Result (N);
 Set_Etype (N, Etype (Parent (N)));
 Target_Type := 

[Ada] Compiler crash on call to function instance

[Pierre-Marie de Rodat]

This patch fixes a bug that causes the compiler to crash if a
renaming-as-body renames a function that is an instance of a generic
function that returns a generic formal type, and the actual type is
controlled, and the instantiation is nested within a procedure.

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

gcc/ada/

* exp_ch6.adb (Is_Build_In_Place_Result_Type): Further narrow
the conditions under which we enable build-in-place for
controlled types.diff --git a/gcc/ada/exp_ch6.adb b/gcc/ada/exp_ch6.adb
--- a/gcc/ada/exp_ch6.adb
+++ b/gcc/ada/exp_ch6.adb
@@ -8091,6 +8091,7 @@ package body Exp_Ch6 is
 
if True then
   Result := Is_Controlled (T)
+and then not Is_Generic_Actual_Type (T)
 and then Present (Enclosing_Subprogram (T))
 and then not Is_Compilation_Unit (Enclosing_Subprogram (T))
 and then Ekind (Enclosing_Subprogram (T)) = E_Procedure;

[Ada] Avoid reanalysis of malformed dependency relations

[Pierre-Marie de Rodat]

When analysis of pragma Depends/Refined_Depends returns early because of
a malformed pragma, it marks the pragma as analyzed to avoid repeated
work.  This is now done consistently for all early returns.

Cleanup only; the GNAT and GNATprove behaviours are not really affected
by this patch.

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

gcc/ada/

* sem_prag.adb (Analyze_Depends_In_Decl_Part): Replace early
returns with goto Leave.
(Collect_Subprogram_Inputs_Outputs): Fix style in comment.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
@@ -1975,7 +1975,7 @@ package body Sem_Prag is
  --  clause as this will lead to misleading errors.
 
  if Has_Extra_Parentheses (Deps) then
-return;
+goto Leave;
  end if;
 
  if Present (Component_Associations (Deps)) then
@@ -2066,7 +2066,7 @@ package body Sem_Prag is
 
  else
 Error_Msg_N ("malformed dependency relation", Deps);
-return;
+goto Leave;
  end if;
 
   --  The top level dependency relation is malformed. This is a syntax
@@ -30226,7 +30226,7 @@ package body Sem_Prag is
  Global  := Get_Pragma (Subp_Id, Pragma_Refined_Global);
 
   --  Subprogram declaration or stand-alone body case, look for pragmas
-  --  Depends and Global
+  --  Depends and Global.
 
   else
  Depends := Get_Pragma (Spec_Id, Pragma_Depends);

[Ada] Fix analysis of access objects in Depends contracts

[Pierre-Marie de Rodat]

In the Depends/Refined_Depends contracts we now accept constant objects
as the dependency outputs if they are of an access-to-variable type, but
not when they are of an access-to-constant or access-to-subprogram
types.

This needs to be implemented in two places: for checking the Depends
contract alone, but also for checking the Depends -vs- Global contract.

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

gcc/ada/

* sem_prag.adb (Find_Role): Constant object of
access-to-constant and access-to-subprogram types are not
writable.
(Collect_Subprogram_Inputs_Outputs): In-parameters of
access-to-variable type can act as outputs of the Depends
contracts.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
@@ -1267,9 +1267,9 @@ package body Sem_Prag is
(Item_Is_Input  : out Boolean;
 Item_Is_Output : out Boolean)
  is
---  A constant or IN parameter of access type should be handled
---  like a variable, as the underlying memory pointed-to can be
---  modified. Use Adjusted_Kind to do this adjustment.
+--  A constant or IN parameter of access-to-variable type should be
+--  handled like a variable, as the underlying memory pointed-to
+--  can be modified. Use Adjusted_Kind to do this adjustment.
 
 Adjusted_Kind : Entity_Kind := Ekind (Item_Id);
 
@@ -1277,7 +1277,7 @@ package body Sem_Prag is
 if Ekind (Item_Id) in E_Constant
 | E_Generic_In_Parameter
 | E_In_Parameter
-  and then Is_Access_Type (Etype (Item_Id))
+  and then Is_Access_Variable (Etype (Item_Id))
 then
Adjusted_Kind := E_Variable;
 end if;
@@ -30175,13 +30175,23 @@ package body Sem_Prag is
  Formal := First_Entity (Spec_Id);
  while Present (Formal) loop
 if Ekind (Formal) in E_In_Out_Parameter | E_In_Parameter then
+
+   --  IN parameters can act as output when the related type is
+   --  access-to-variable.
+
+   if Ekind (Formal) = E_In_Parameter
+ and then Is_Access_Variable (Etype (Formal))
+   then
+  Append_New_Elmt (Formal, Subp_Outputs);
+   end if;
+
Append_New_Elmt (Formal, Subp_Inputs);
 end if;
 
 if Ekind (Formal) in E_In_Out_Parameter | E_Out_Parameter then
Append_New_Elmt (Formal, Subp_Outputs);
 
-   --  Out parameters can act as inputs when the related type is
+   --  OUT parameters can act as inputs when the related type is
--  tagged, unconstrained array, unconstrained record, or record
--  with unconstrained components.
 

[Ada] Tidy up implementation of System.Fat_Gen.Valid and inline it again

[Pierre-Marie de Rodat]

Besides the improved commentary, the removal of superfluous subtypes and
other small tweaks throughout to make it more readable, this replaces the
use of T'Mantissa by the more appropriate T'Machine_Mantissa in the body
of System.Fat_Gen.Valid and also removes an unnecessary trick used to
distinguish zero from other denormalized numbers when T'Denorm is False.

This also inlines again the function, because it compiles to only a few
machine instructions for most architectures.

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

gcc/ada/

* libgnat/s-fatgen.ads (Valid): Add again pragma Inline.
* libgnat/s-fatgen.adb (Valid): Improve commentary, tidy up left
and right, and remove superfluous trick for denormalized numbers.diff --git a/gcc/ada/libgnat/s-fatgen.adb b/gcc/ada/libgnat/s-fatgen.adb
--- a/gcc/ada/libgnat/s-fatgen.adb
+++ b/gcc/ada/libgnat/s-fatgen.adb
@@ -38,6 +38,7 @@
 
 with Ada.Unchecked_Conversion;
 with System;
+
 package body System.Fat_Gen is
 
Float_Radix: constant T := T (T'Machine_Radix);
@@ -807,130 +808,110 @@ package body System.Fat_Gen is
function Valid (X : not null access T) return Boolean is
   IEEE_Emin : constant Integer := T'Machine_Emin - 1;
   IEEE_Emax : constant Integer := T'Machine_Emax - 1;
+  --  The mantissa is a fraction with first digit set in Ada whereas it is
+  --  shifted by 1 digit to the left in the IEEE floating-point format.
 
-  IEEE_Bias : constant Integer := -(IEEE_Emin - 1);
+  subtype IEEE_Erange is Integer range IEEE_Emin - 1 .. IEEE_Emax + 1;
+  --  The IEEE floating-point format extends the machine range by 1 to the
+  --  left for denormalized numbers and 1 to the right for infinities/NaNs.
 
-  subtype IEEE_Exponent_Range is
-Integer range IEEE_Emin - 1 .. IEEE_Emax + 1;
+  IEEE_Ebias : constant Integer := -(IEEE_Emin - 1);
+  --  The exponent is biased such that denormalized numbers have it zero
 
-  --  The implementation of this floating point attribute uses a
-  --  representation type Float_Rep that allows direct access to the
-  --  exponent and mantissa parts of a floating point number.
+  --  The implementation uses a representation type Float_Rep that allows
+  --  direct access to exponent and mantissa of the floating point number.
 
-  --  The Float_Rep type is an array of Float_Word elements. This
+  --  The Float_Rep type is a simple array of Float_Word elements. This
   --  representation is chosen to make it possible to size the type based
   --  on a generic parameter. Since the array size is known at compile
   --  time, efficient code can still be generated. The size of Float_Word
   --  elements should be large enough to allow accessing the exponent in
-  --  one read, but small enough so that all floating point object sizes
-  --  are a multiple of the Float_Word'Size.
+  --  one read, but small enough so that all floating-point object sizes
+  --  are a multiple of Float_Word'Size.
 
   --  The following conditions must be met for all possible instantiations
-  --  of the attributes package:
+  --  of the attribute package:
 
   --- T'Size is an integral multiple of Float_Word'Size
 
   --- The exponent and sign are completely contained in a single
-  --  component of Float_Rep, named Most_Significant_Word (MSW).
+  --  component of Float_Rep, named Most Significant Word (MSW).
 
   --- The sign occupies the most significant bit of the MSW and the
-  --  exponent is in the following bits. Unused bits (if any) are in
-  --  the least significant part.
-
-  type Float_Word is mod 2**Positive'Min (System.Word_Size, 32);
-  type Rep_Index is range 0 .. 7;
-
-  Rep_Words : constant Positive :=
-(T'Size + Float_Word'Size - 1) / Float_Word'Size;
-  Rep_Last  : constant Rep_Index :=
-Rep_Index'Min
-  (Rep_Index (Rep_Words - 1),
-   (T'Mantissa + 16) / Float_Word'Size);
+  --  exponent is in the following bits. The exception is 80-bit
+  --  double extended, where they occupy the low 16-bit halfword.
+
+  Siz : constant :=
+  (if System.Word_Size > 32 then 32 else System.Word_Size);
+  type Float_Word is mod 2**Siz;
+
+  N : constant Natural := (T'Size + Siz - 1) / Siz;
+  Rep_Last : constant Natural :=
+   Natural'Min (N - 1, (T'Machine_Mantissa + 16) / Siz);
   --  Determine the number of Float_Words needed for representing the
   --  entire floating-point value. Do not take into account excessive
   --  padding, as occurs on IA-64 where 80 bits floats get padded to 128
   --  bits. In general, the exponent field cannot be larger than 15 bits,
   --  even for 128-bit floating-point types, so the final format size
-  --  won't be larger than 

[Ada] Correctly mark subprogram as not always inlined in GNATprove mode

[Pierre-Marie de Rodat]

In GNATprove mode, a call inside a Subprogram_Variant should lead to the
called subprogram being marked as not always inlined. This was not
always the case, now fixed.

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

gcc/ada/

* inline.adb (Cannot_Inline): Add No_Info parameter to disable
info message.
* inline.ads (Cannot_Inline): When No_Info is set to True, do
not issue info message in GNATprove mode, but still mark the
subprogram as not always inlined.
* sem_res.adb (Resolve_Call): Always call Cannot_Inline inside
an assertion expression.diff --git a/gcc/ada/inline.adb b/gcc/ada/inline.adb
--- a/gcc/ada/inline.adb
+++ b/gcc/ada/inline.adb
@@ -1945,10 +1945,11 @@ package body Inline is
---
 
procedure Cannot_Inline
- (Msg: String;
-  N  : Node_Id;
-  Subp   : Entity_Id;
-  Is_Serious : Boolean := False)
+ (Msg   : String;
+  N : Node_Id;
+  Subp  : Entity_Id;
+  Is_Serious: Boolean := False;
+  Suppress_Info : Boolean := False)
is
begin
   --  In GNATprove mode, inlining is the technical means by which the
@@ -1971,7 +1972,7 @@ package body Inline is
 New_Msg (1 .. Len2) := "info: no contextual analysis of";
 New_Msg (Len2 + 1 .. Msg'Length + Len2 - Len1) :=
   Msg (Msg'First + Len1 .. Msg'Last);
-Cannot_Inline (New_Msg, N, Subp, Is_Serious);
+Cannot_Inline (New_Msg, N, Subp, Is_Serious, Suppress_Info);
 return;
  end;
   end if;
@@ -1992,14 +1993,14 @@ package body Inline is
  then
 null;
 
- --  In GNATprove mode, issue a warning when -gnatd_f is set, and
- --  indicate that the subprogram is not always inlined by setting
- --  flag Is_Inlined_Always to False.
+ --  In GNATprove mode, issue an info message when -gnatd_f is set and
+ --  Suppress_Info is False, and indicate that the subprogram is not
+ --  always inlined by setting flag Is_Inlined_Always to False.
 
  elsif GNATprove_Mode then
 Set_Is_Inlined_Always (Subp, False);
 
-if Debug_Flag_Underscore_F then
+if Debug_Flag_Underscore_F and not Suppress_Info then
Error_Msg_NE (Msg, N, Subp);
 end if;
 
@@ -2022,14 +2023,14 @@ package body Inline is
 
  Error_Msg_NE (Msg (Msg'First .. Msg'Last - 1), N, Subp);
 
-  --  In GNATprove mode, issue a warning when -gnatd_f is set, and
-  --  indicate that the subprogram is not always inlined by setting
-  --  flag Is_Inlined_Always to False.
+  --  In GNATprove mode, issue an info message when -gnatd_f is set and
+  --  Suppress_Info is False, and indicate that the subprogram is not
+  --  always inlined by setting flag Is_Inlined_Always to False.
 
   elsif GNATprove_Mode then
  Set_Is_Inlined_Always (Subp, False);
 
- if Debug_Flag_Underscore_F then
+ if Debug_Flag_Underscore_F and not Suppress_Info then
 Error_Msg_NE (Msg, N, Subp);
  end if;
 


diff --git a/gcc/ada/inline.ads b/gcc/ada/inline.ads
--- a/gcc/ada/inline.ads
+++ b/gcc/ada/inline.ads
@@ -154,15 +154,17 @@ package Inline is
--  its treatment of the subprogram.
 
procedure Cannot_Inline
- (Msg: String;
-  N  : Node_Id;
-  Subp   : Entity_Id;
-  Is_Serious : Boolean := False);
+ (Msg   : String;
+  N : Node_Id;
+  Subp  : Entity_Id;
+  Is_Serious: Boolean := False;
+  Suppress_Info : Boolean := False);
--  This procedure is called if the node N, an instance of a call to
--  subprogram Subp, cannot be inlined. Msg is the message to be issued,
--  which ends with ? (it does not end with ?p?, this routine takes care of
-   --  the need to change ? to ?p?). The behavior of this routine depends on
-   --  the value of Back_End_Inlining:
+   --  the need to change ? to ?p?). Suppress_Info is set to True to prevent
+   --  issuing an info message in GNATprove mode. The behavior of this routine
+   --  depends on the value of Back_End_Inlining:
--
--* If Back_End_Inlining is not set (ie. legacy frontend inlining model)
--  then if Subp has a pragma Always_Inlined, then an error message is


diff --git a/gcc/ada/sem_res.adb b/gcc/ada/sem_res.adb
--- a/gcc/ada/sem_res.adb
+++ b/gcc/ada/sem_res.adb
@@ -7122,10 +7122,9 @@ package body Sem_Res is
 --  on expression functions.
 
 elsif In_Assertion_Expr /= 0 then
-   if Present (Body_Id) then
-  Cannot_Inline
-("cannot inline & (in assertion expression)?", N, Nam_UA);
-   end if;
+   Cannot_Inline
+ ("cannot inline & (in assertion expression)?", N, Nam_UA,
+  Suppress_Info 

[Ada] Adjust documentation of System.Img_Util.Set_Decimal_Digits

[Pierre-Marie de Rodat]

The routine is now used both for decimal and for ordinary fixed-point types.

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

gcc/ada/

* libgnat/s-imguti.ads (Set_Decimal_Digits): Adjust documentation.diff --git a/gcc/ada/libgnat/s-imguti.ads b/gcc/ada/libgnat/s-imguti.ads
--- a/gcc/ada/libgnat/s-imguti.ads
+++ b/gcc/ada/libgnat/s-imguti.ads
@@ -45,14 +45,17 @@ package System.Img_Util is
   Exp   : Natural);
--  Sets the image of Digs (1 .. NDigs), which is a string of decimal digits
--  preceded by either a minus sign or a space, i.e. the integer image of
-   --  the value in units of delta of a decimal fixed point type with the given
-   --  Scale, starting at S (P + 1), updating P to point to the last character
-   --  stored, the caller promises that the buffer is large enough and no check
-   --  is made for this. Constraint_Error will not necessarily be raised if the
-   --  requirement is violated since it is perfectly valid to compile this unit
-   --  with checks off. The Fore, Aft and Exp values can be set to any valid
-   --  values for the case of use by Text_IO.Decimal_IO. Note that there is no
-   --  leading space stored. The call may destroy the value in Digs, which is
-   --  why Digs is in-out (this happens if rounding is required).
+   --  the value in units of delta if this is for a decimal fixed point type
+   --  with the given Scale, or the integer image of the value converted to an
+   --  implicit decimal fixed point type with the given Scale if this is for an
+   --  ordinary fixed point type, starting at S (P + 1), updating P to point to
+   --  the last character stored. The caller promises that the buffer is large
+   --  enough and therefore no check is made for it. Constraint_Error will not
+   --  necessarily be raised if the requirement is violated since it is valid
+   --  to compile this unit with checks off. The Fore, Aft and Exp values can
+   --  be set to any valid values for the case of use by Text_IO.Decimal_IO or
+   --  Text_IO.Fixed_IO. Note that there is no leading space stored. The call
+   --  may destroy the value in Digs, which is why Digs is in-out (this happens
+   --  if rounding is required).
 
 end System.Img_Util;

[Ada] Update comment for processing of pragma Assertion_Policy

[Pierre-Marie de Rodat]

The code for pragma Assertion_Policy has been recently updated to
include Subprogram_Variant and change the kind of
Default_Initial_Condition, but the comment was not modified.

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

gcc/ada/

* sa_messages.ads: Reference Subprogram_Variant in the comment
for Assertion_Check.
* sem_prag.adb (Analyze_Pragma): Add Subprogram_Variant as an
ID_ASSERTION_KIND; move Default_Initial_Condition as an
RM_ASSERTION_KIND.diff --git a/gcc/ada/sa_messages.ads b/gcc/ada/sa_messages.ads
--- a/gcc/ada/sa_messages.ads
+++ b/gcc/ada/sa_messages.ads
@@ -94,7 +94,7 @@ package SA_Messages is
--  type invariant checks (specific and class-wide), and checks for
--  implementation-defined assertions such as Assert_And_Cut, Assume,
--  Contract_Cases, Default_Initial_Condition, Initial_Condition,
-   --  Loop_Invariant, Loop_Variant, and Refined_Post.
+   --  Loop_Invariant, Loop_Variant, Refined_Post, and Subprogram_Variant.
--
--  TBD: it might be nice to distinguish these different kinds of assertions
--  as is done in SPARK's VC_Kind enumeration type, but any distinction


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
@@ -12903,30 +12903,31 @@ package body Sem_Prag is
 
  --  ASSERTION_KIND ::= RM_ASSERTION_KIND | ID_ASSERTION_KIND
 
- --  RM_ASSERTION_KIND ::= Assert   |
- --Static_Predicate |
- --Dynamic_Predicate|
- --Pre  |
- --Pre'Class|
- --Post |
- --Post'Class   |
- --Type_Invariant   |
- --Type_Invariant'Class
-
- --  ID_ASSERTION_KIND ::= Assert_And_Cut|
- --Assume|
- --Contract_Cases|
- --Debug |
- --Default_Initial_Condition |
- --Ghost |
- --Initial_Condition |
- --Loop_Invariant|
- --Loop_Variant  |
- --Postcondition |
- --Precondition  |
- --Predicate |
- --Refined_Post  |
- --Statement_Assertions
+ --  RM_ASSERTION_KIND ::= Assert |
+ --Static_Predicate   |
+ --Dynamic_Predicate  |
+ --Pre|
+ --Pre'Class  |
+ --Post   |
+ --Post'Class |
+ --Type_Invariant |
+ --Type_Invariant'Class   |
+ --Default_Initial_Condition
+
+ --  ID_ASSERTION_KIND ::= Assert_And_Cut   |
+ --Assume   |
+ --Contract_Cases   |
+ --Debug|
+ --Ghost|
+ --Initial_Condition|
+ --Loop_Invariant   |
+ --Loop_Variant |
+ --Postcondition|
+ --Precondition |
+ --Predicate|
+ --Refined_Post |
+ --Statement_Assertions |
+ --Subprogram_Variant
 
  --  Note: The RM_ASSERTION_KIND list is language-defined, and the
  --  ID_ASSERTION_KIND list contains implementation-defined additions

Re: [PATCH]AArch64: Add NEON, SVE and SVE2 RTL patterns for Complex Addition, Multiply and FMA.

[Tamar Christina via Gcc-patches]

Hi Richard,

Do you object to me splitting off complex add and addressing your remaining 
feedback later when the rewrite of mul and fma are done.

Thanks,
Tamar

From: Richard Sandiford 
Sent: Monday, December 14, 2020 1:30 PM
To: Tamar Christina 
Cc: gcc-patches@gcc.gnu.org ; nd ; 
Richard Earnshaw ; Marcus Shawcroft 
; Kyrylo Tkachov 
Subject: Re: [PATCH]AArch64: Add NEON, SVE and SVE2 RTL patterns for Complex 
Addition, Multiply and FMA.

Rearranging slightly…

> @@ -708,6 +713,10 @@ (define_c_enum "unspec"
>  UNSPEC_FCMLA90   ; Used in aarch64-simd.md.
>  UNSPEC_FCMLA180  ; Used in aarch64-simd.md.
>  UNSPEC_FCMLA270  ; Used in aarch64-simd.md.
> +UNSPEC_FCMUL ; Used in aarch64-simd.md.
> +UNSPEC_FCMUL180  ; Used in aarch64-simd.md.
> +UNSPEC_FCMLS ; Used in aarch64-simd.md.
> +UNSPEC_FCMLS180  ; Used in aarch64-simd.md.
>  UNSPEC_ASRD  ; Used in aarch64-sve.md.
>  UNSPEC_ADCLB ; Used in aarch64-sve2.md.
>  UNSPEC_ADCLT ; Used in aarch64-sve2.md.
> @@ -726,6 +735,10 @@ (define_c_enum "unspec"
>  UNSPEC_CMLA180   ; Used in aarch64-sve2.md.
>  UNSPEC_CMLA270   ; Used in aarch64-sve2.md.
>  UNSPEC_CMLA90; Used in aarch64-sve2.md.
> +UNSPEC_CMLS  ; Used in aarch64-sve2.md.
> +UNSPEC_CMLS180   ; Used in aarch64-sve2.md.
> +UNSPEC_CMUL  ; Used in aarch64-sve2.md.
> +UNSPEC_CMUL180   ; Used in aarch64-sve2.md.
>  UNSPEC_COND_FCVTLT   ; Used in aarch64-sve2.md.
>  UNSPEC_COND_FCVTNT   ; Used in aarch64-sve2.md.
>  UNSPEC_COND_FCVTX; Used in aarch64-sve2.md.
> […]
> @@ -3418,7 +3457,85 @@ (define_int_attr rot [(UNSPEC_CADD90 "90")
>  (UNSPEC_COND_FCMLA "0")
>  (UNSPEC_COND_FCMLA90 "90")
>  (UNSPEC_COND_FCMLA180 "180")
> -   (UNSPEC_COND_FCMLA270 "270")])
> +   (UNSPEC_COND_FCMLA270 "270")
> +   (UNSPEC_FCMUL "0")
> +   (UNSPEC_FCMUL180 "180")])
> +
> +;; A conjucate is a negation of the imaginary component
> +;; The number in the inspecs are the rotation component of the instruction, 
> e.g

unspecs

> +;; FCMLS180 means use the instruction with #180.
> +;; The iterator is used to produce the right name mangling for the function.
> +;;
> +;; The rotation value does not directly correlate to a rotation along the 
> argant
> +;; plane as the instructions only perform half the computation.
> +;;
> +;; For the implementation we threat any rotation by 0 as normal and 180 as
> +;; conjucate.  This is only for implementing the vectorizer patterns.
> +(define_int_attr rot_op [(UNSPEC_FCMLS "")
> +  (UNSPEC_FCMLS180 "_conj")
> +  (UNSPEC_FCMLA "")
> +  (UNSPEC_FCMLA180 "_conj")
> +  (UNSPEC_FCMUL "")
> +  (UNSPEC_FCMUL180 "_conj")
> +  (UNSPEC_CMLS "")
> +  (UNSPEC_CMLA "")
> +  (UNSPEC_CMLA180 "_conj")
> +  (UNSPEC_CMUL "")
> +  (UNSPEC_CMUL180 "_conj")])
> +

Realise this is being awkward, sorry, but: I think it would be clearer
to use unspecs with _CONJ in the name for the conjugated forms, rather
than explain away how 180 is being used.

All four rotations make sense as a pair (i.e. as a full complex
multiplication), rather than just as a standalone instruction:

  FMLA= a + b * c
  FMLA90  = a + b * c * i
  FMLA180 = a - b * c
  FMLA270 = a - b * c * i

I.e. FMLA180 == FMLS and FMLA270 == “FMLS90” (a made-up term).
“FMLS180” is equivalent to FMLA.

We can then additionally conjugate “b” in each of the four forms above.

At the moment, FMLA90 and FMLA270/FMLS90 (and their conjugate forms)
aren't exposed as optabs, but that could change in future.

So I think we should avoid introducing FMLS and FMLS180 and instead use
(name in patch -> suggested replacement):

  FMLA -> FMLA
  FMLS -> FMLA180
  FMLA180 -> FMLA_CONJ
  FMLS180 -> FMLA180_CONJ

where _CONJ has the effect of adding 180 degrees to the second
rotation amount.

Then:

> +;; The complex operations when performed on a real complex number require two
> +;; instructions to perform the operation. e.g. complex multiplication 
> requires
> +;; two FCMUL with a particular rotation value.
> +;;
> +;; These values can be looked up in rotsplit1 and rotsplit2.  as an example
> +;; FCMUL needs the first instruction to use #0 and the second #90.
> +(define_int_attr rotsplit1 [(UNSPEC_FCMLA "0")
> + (UNSPEC_FCMLA180 "0")
> + (UNSPEC_FCMUL "0")
> + (UNSPEC_FCMUL180 "0")
> + (UNSPEC_FCMLS "270")
> + (UNSPEC_FCMLS180 "90")])
> +
> +(define_int_attr rotsplit2 [(UNSPEC_FCMLA "90")
> + (UNSPEC_FCMLA180 "270")
> +

rs6000: add support for powerpc64le-unknown-freebsd

[Piotr Kubaj via Gcc-patches]

Hello,

this patch implements support for powerpc64le architecture on FreeBSD. Since we 
don't have powerpcle (32-bit), I did not add support for powerpcle here. This 
remains to be changed if there is powerpcle support in the future.

Patch implements similar endian detection to what linux64.h uses.

Would it be ok to backport it to at least GCC 10?

gcc/Changelog:
2020-12-14  Piotr Kubaj  

* config.gcc: add support for powerpc64le-unknown-freebsd
--- gcc/config.gcc.orig	2020-12-07 03:00:29 UTC
+++ gcc/config.gcc
@@ -2868,6 +2868,10 @@ powerpc*-*-freebsd*)
 	extra_options="${extra_options} rs6000/sysv4.opt"
 	tmake_file="rs6000/t-fprules rs6000/t-ppcos ${tmake_file} rs6000/t-ppccomm"
 	case ${target} in
+	powerpc*le-*-*)
+		tm_file="${tm_file} rs6000/sysv4le.h" ;;
+	esac
+	case ${target} in
 	 powerpc64*)
 		tm_file="${tm_file} rs6000/default64.h rs6000/freebsd64.h"
 		tmake_file="${tmake_file} rs6000/t-freebsd64"
--- gcc/config/rs6000/freebsd64.h.orig	2020-07-23 06:35:17 UTC
+++ gcc/config/rs6000/freebsd64.h
@@ -158,8 +157,8 @@ extern int dot_symbols;
 #define ASM_SPEC64 "-a64"
 
 #define ASM_SPEC_COMMON "%(asm_cpu) \
-%{,assembler|,assembler-with-cpp: %{mregnames} %{mno-regnames}} \
-%{mlittle} %{mlittle-endian} %{mbig} %{mbig-endian}"
+%{,assembler|,assembler-with-cpp: %{mregnames} %{mno-regnames}}" \
+  ENDIAN_SELECT(" -mbig", " -mlittle", DEFAULT_ASM_ENDIAN)
 
 #undef	SUBSUBTARGET_EXTRA_SPECS
 #define SUBSUBTARGET_EXTRA_SPECS	\
@@ -181,9 +180,15 @@ extern int dot_symbols;
 %{static:-Bstatic}} \
   %{symbolic:-Bsymbolic}"
 
+#undef  DEFAULT_ASM_ENDIAN
 #define LINK_OS_FREEBSD_SPEC32 "-melf32ppc_fbsd " LINK_OS_FREEBSD_SPEC_DEF
-  
+#if (TARGET_DEFAULT & MASK_LITTLE_ENDIAN)
+#define DEFAULT_ASM_ENDIAN " -mlittle"
+#define LINK_OS_FREEBSD_SPEC64 "-melf64lppc_fbsd " LINK_OS_FREEBSD_SPEC_DEF
+#else
+#define DEFAULT_ASM_ENDIAN " -mbig"
 #define LINK_OS_FREEBSD_SPEC64 "-melf64ppc_fbsd " LINK_OS_FREEBSD_SPEC_DEF
+#endif
 
 #undef	MULTILIB_DEFAULTS
 #define MULTILIB_DEFAULTS { "m64" }
--- gcc/configure.ac.orig	2020-12-14 15:22:23 UTC
+++ gcc/configure.ac
@@ -5874,6 +5874,8 @@ case "$target:$tm_file" in
  *-*-linux*)
  emul_name="-melf64ppc"
   ;;
+ *le-*-freebsd*)
+ emul_name="-melf64lppc_fbsd"
  *-*-freebsd*)
  emul_name="-melf64ppc_fbsd"
   ;;


signature.asc
Description: PGP signature

Re: [PATCH] testsuite: Fix various scan-assembler-symbol-section issues

[David Edelsohn via Gcc-patches]

On Mon, Dec 14, 2020 at 9:44 AM Rainer Orth  
wrote:
>
> Hi David,
>
> > On Fri, Dec 4, 2020 at 5:35 AM Rainer Orth  
> > wrote:
> >
> >> On AIX 7.2, there are changes like
> >>
> >> -PASS: g++.dg/gomp/tls-5.C -std=c++2a scan-assembler-symbol-section
> >> symbol ^_?ir$ (found ir) has section ^\\.tbss|\\[TL\\] (found
> >> _tls5.tls_[TL],4)
> >> +PASS: g++.dg/gomp/tls-5.C -std=c++2a scan-assembler-symbol-section
> >> symbol ^_?ir$ (found ir) has section ^\\.tbss|\\[TL\\] (found
> >> _tls5.tls_[TL])
> >>
> >> i.e. the ",4" after (?) the section name is now stripped.  I believe
> >> this is benign: David?
> >
> > The ",4" is the symbol alignment.  It is not necessary for the purpose
> > of the tests.
>
> fine, thanks for the clarification.
>
> > Thanks for looking further into this problem.  As I mentioned in my
> > earlier reply to the patch itself, I believe that this new feature and
> > infrastructure change should have been tested and fixed on
> > non-Linux/ELF/x86 architectures, not left as an exercise for the
> > maintainers of other targets.  A patch that introduces regressions in
> > the testsuite should be fixed or reverted and should be the
> > responsibility of the author -- whether the change is to the compiler
> > or to the testsuite.
>
> Yes and no: given the trouble I had myself trying an AIX bootstrap and
> test and the effort it took guiding Iain through a Solaris 11.3
> bootstrap on gcc211, I fear it's unreasonable to demand developers to do
> all this testing themselves: if you have to address only one issue per
> unfamiliar target while trying to, we'll loose contributors very
> quickly.  I believe we should be able to get the setup of the various
> cfarm hosts better in sync with the guidelines documented in the wiki to
> avoid such trouble.

I respectfully disagree.  I find the GCC community very inconsistent
about this policy and I will continue to object.  Sometimes the
community demands thorough testing on all major targets and sometimes
the community says that it's too much trouble.  It depends on the
patch, and the developer, and the target that the patch is trying to
fix.  I believe that this inconsistent policy is driving away
developers also.

Many other software packages have a policy that any test suite
regression requires patch reversion.  GCC historically has not had
that policy.  But GCC does have a policy that testsuite failures are
the responsibility of the person who created the patch.  The GCC
community historically has decided that it is impractical and
unscalable for one person to install a patch and generate
unanticipated work for every other maintainer in the community.
Software developers do not want to work on a software package where
another developer can break their configuration, generate extra,
unanticipated work, and have no responsibility.

Most active maintainers are willing to help.  Most maintainers are
willing to help a developer debug a problem on their target.

Bootstrap on AIX works best with some additional configuration
parameters that are mentioned in the Compile Farm wiki.  Bootstrap on
AIX would have been much easier for you if you had asked for help and
advice.

>
> Ultimately, something like the trybot feature of the (now mostly
> defunct) gdb buildbots could ease such pre-commit tests.

I agree that GCC needs better CI and there are efforts in that direction.

>
> But I fully agree that the original patch should have seen way wider
> cross-platform testing before being committed: asking target maintainers
> for help usually works well enough: one just cannot expect them to spot
> any patch that might require such testing themselves.

Thanks, David

Re: [PATCH] Fix -save-temp leaking lto files in /tmp

[Bernd Edlinger]

Hi,

On 2/21/20 8:35 AM, Richard Biener wrote:
> 
> IIRC this definitely clashes with Alex work to overhaul
> -auxdir/-dumpdir queued for GCC 11 where some of the above
> is improved.
> 
> So whatever we do we should do it for GCC 11 after Alex patches
> land.
> 
> Richard.
> 

Okay, I think this patch was applied in the mean time.
Just some 20-30 temp files are left from a full run of the testsuite.

So I rewrote my patch, and found this time it looks
feasible to avoid all remaining temp files with unpredictable
random names, so that is an improvement over the state earlier
this year.


Attached is my new patch, to clean up the rest of the -save-temps
files.  That consist just of a couple of @file parameters.

I added a few test cases, and the testsuite runs without any
temp files leaking.

Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
From 5e07f814f102d6dabebcb6652a40f5a1b9716479 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Sun, 13 Dec 2020 08:24:57 +0100
Subject: [PATCH] Fix -save-temp leaking lto files in /tmp

When linking with -flto and -save-temps, various
temporary files are created in /tmp.
The same happens when invoking the driver with @file
parameter, and using -L or -I options.

2020-12-12  Bernd Edlinger  

	* collect-utils.c (collect_execute): Check dumppfx.
	* collect2.c (maybe_run_lto_and_relink, do_link): Pass atsuffix
	to collect_execute.
	(do_link): Add new parameter atsuffix.
	(main): Handle -dumpdir option.  Skip one argument for
	-o, -isystem and -B options.
	* gcc.c (make_at_file): New helper function.
	(close_at_file): Use it.

gcc/testsuite:
2020-12-12  Bernd Edlinger  

	* gcc.misc-tests/outputs.exp: Adjust testcase.
---
 gcc/collect-utils.c  |  2 +-
 gcc/collect2.c   | 43 
 gcc/gcc.c| 28 -
 gcc/testsuite/gcc.misc-tests/outputs.exp | 31 ++-
 4 files changed, 74 insertions(+), 30 deletions(-)

diff --git a/gcc/collect-utils.c b/gcc/collect-utils.c
index 095db8d..921bb34 100644
--- a/gcc/collect-utils.c
+++ b/gcc/collect-utils.c
@@ -127,7 +127,7 @@ collect_execute (const char *prog, char **argv, const char *outname,
   /* Note: we assume argv contains at least one element; this is
  checked above.  */
 
-  if (!save_temps || !atsuffix)
+  if (!save_temps || !atsuffix || !dumppfx)
 	response_file = make_temp_file ("");
   else
 	response_file = concat (dumppfx, atsuffix, NULL);
diff --git a/gcc/collect2.c b/gcc/collect2.c
index 3a43a5a..3f097f9 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -644,7 +644,7 @@ maybe_run_lto_and_relink (char **lto_ld_argv, char **object_lst,
 
   /* Run the LTO back end.  */
   pex = collect_execute (prog, lto_c_argv, NULL, NULL, PEX_SEARCH,
-			 at_file_supplied, NULL);
+			 at_file_supplied, "lto_args");
   {
 	int c;
 	FILE *stream;
@@ -728,7 +728,7 @@ maybe_run_lto_and_relink (char **lto_ld_argv, char **object_lst,
   /* Run the linker again, this time replacing the object files
  optimized by the LTO with the temporary file generated by the LTO.  */
   fork_execute ("ld", out_lto_ld_argv, HAVE_GNU_LD && at_file_supplied,
-		NULL);
+		"ld_args");
   /* We assume that temp files were created, and therefore we need to take
  that into account (maybe run dsymutil).  */
   post_ld_pass (/*temp_file*/true);
@@ -740,7 +740,8 @@ maybe_run_lto_and_relink (char **lto_ld_argv, char **object_lst,
 {
   /* Our caller is relying on us to do the link
  even though there is no LTO back end work to be done.  */
-  fork_execute ("ld", lto_ld_argv, HAVE_GNU_LD && at_file_supplied, NULL);
+  fork_execute ("ld", lto_ld_argv, HAVE_GNU_LD && at_file_supplied,
+		"ld_args");
   /* No LTO objects were found, so no new temp file.  */
   post_ld_pass (/*temp_file*/false);
 }
@@ -751,13 +752,13 @@ maybe_run_lto_and_relink (char **lto_ld_argv, char **object_lst,
LD_ARGV is an array of arguments for the linker.  */
 
 static void
-do_link (char **ld_argv)
+do_link (char **ld_argv, const char *atsuffix)
 {
   struct pex_obj *pex;
   const char *prog = "ld";
   pex = collect_execute (prog, ld_argv, NULL, NULL,
 			 PEX_LAST | PEX_SEARCH,
-			 HAVE_GNU_LD && at_file_supplied, NULL);
+			 HAVE_GNU_LD && at_file_supplied, atsuffix);
   int ret = collect_wait (prog, pex);
   if (ret)
 {
@@ -973,10 +974,10 @@ main (int argc, char **argv)
 	  {
 	/* Parse the output filename if it's given so that we can make
 	   meaningful temp filenames.  */
-	if (argv[i][2] == '\0')
-	  output_file = argv[i+1];
-	else
+	if (argv[i][2] != '\0')
 	  output_file = [i][2];
+	else if (argv[i+1] != NULL)
+	  output_file = argv[++i];
 	  }
 
 #ifdef COLLECT_EXPORT_LIST
@@ -1022,6 +1023,12 @@ main (int argc, char **argv)
 	else if (strncmp (q, 

preprocessor: Deferred macro support

[Nathan Sidwell]

For deferred macros we also need a new field on the macro itself, so
that the module machinery can determine the macro was imported.  Also
the documentation for the hashnode's deferred field was incomplete.

libcpp/
* include/cpplib.h (struct cpp_macro): Add imported_p field.
(struct cpp_hashnode): Tweak deferred field documentation.
* macro.c (_cpp_new_macro): Clear new field.
(cpp_get_deferred_macro, get_deferred_or_lazy_macro): Assert
more.

pushing to trunk
--
Nathan Sidwell
diff --git i/libcpp/include/cpplib.h w/libcpp/include/cpplib.h
index 692aee58d19..50d28dc9d5a 100644
--- i/libcpp/include/cpplib.h
+++ w/libcpp/include/cpplib.h
@@ -826,7 +826,10 @@ struct GTY(()) cpp_macro {
  tokens.  */
   unsigned int extra_tokens : 1;
 
-  /* 1 bits spare (32-bit). 33 on 64-bit target.  */
+  /* Imported C++20 macro (from a header unit).  */
+  unsigned int imported_p : 1;
+
+  /* 0 bits spare (32-bit). 32 on 64-bit target.  */
 
   union cpp_exp_u
   {
@@ -921,9 +924,11 @@ struct GTY(()) cpp_hashnode {
 
   /* 5 bits spare.  */
 
-  /* On a 64-bit system there would be 32-bits of padding to the value
+  /* The deferred cookie is applicable to NT_USER_MACRO or NT_VOID.
+ The latter for when a macro had a prevailing undef.
+ On a 64-bit system there would be 32-bits of padding to the value
  field.  So placing the deferred index here is not costly.   */
-  unsigned deferred;			/* Deferred index, (unless zero).  */
+  unsigned deferred;			/* Deferred cookie  */
 
   union _cpp_hashnode_value GTY ((desc ("%1.type"))) value;
 };
diff --git i/libcpp/macro.c w/libcpp/macro.c
index 05755859cd6..cdb182112bc 100644
--- i/libcpp/macro.c
+++ w/libcpp/macro.c
@@ -3708,6 +3708,7 @@ _cpp_new_macro (cpp_reader *pfile, cpp_macro_kind kind, void *placement)
   macro->used = !CPP_OPTION (pfile, warn_unused_macros);
   macro->count = 0;
   macro->fun_like = 0;
+  macro->imported_p = false;
   macro->extra_tokens = 0;
   /* To suppress some diagnostics.  */
   macro->syshdr = pfile->buffer && pfile->buffer->sysp != 0;
@@ -3791,6 +3792,8 @@ cpp_macro *
 cpp_get_deferred_macro (cpp_reader *pfile, cpp_hashnode *node,
 			location_t loc)
 {
+  gcc_checking_assert (node->type == NT_USER_MACRO);
+
   node->value.macro = pfile->cb.user_deferred_macro (pfile, loc, node);
 
   if (!node->value.macro)
@@ -3807,11 +3810,9 @@ get_deferred_or_lazy_macro (cpp_reader *pfile, cpp_hashnode *node,
   if (!macro)
 {
   macro = cpp_get_deferred_macro (pfile, node, loc);
-  if (!macro)
-	return NULL;
+  gcc_checking_assert (!macro || !macro->lazy);
 }
-
-  if (macro->lazy)
+  else if (macro->lazy)
 {
   pfile->cb.user_lazy_macro (pfile, macro, macro->lazy - 1);
   macro->lazy = 0;

[PATCH]middle-end vect: Exclude TOP permute from blend considerations

[Tamar Christina via Gcc-patches]

Hi All,

Similarly to UNKNOWN permutes, TOP needs to be excluded from being considered
for blends because it produces no permute to check.

Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
and no issues.

Committed under the GCC obvious rules.

Thanks,
Tamar

gcc/ChangeLog:

PR middle-end/98264
* tree-vect-slp-patterns.c (linear_loads_p): Exclude TOP permute.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr98264.c: New test.

--- inline copy of patch --

diff --git a/gcc/testsuite/gcc.target/i386/pr98264.c 
b/gcc/testsuite/gcc.target/i386/pr98264.c
new file mode 100644
index 
..ea235277911f2a48b4b6f2ccd75a4f9000918599
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr98264.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-O3 -w" } */
+
+a[], g[], h[];
+double b, c;
+double j[];
+i;
+l() {
+  int e = 0;
+  for (; e < 80; e += 4) {
+a[0] = h[e];
+a[1] = h[e + 1];
+j[0] = a[0] - c;
+j[1] = a[1] + b;
+__attribute__(()) k = *(double *)a, e, f = e = 0;
+*g = k;
+double *d = j;
+for (; e < 2; e++)
+  if (d[e])
+i = f;
+  }
+}
diff --git a/gcc/tree-vect-slp-patterns.c b/gcc/tree-vect-slp-patterns.c
index 
bb2830d1d35d1607d1566868ffbcead97e4790d7..fede88923af8521ee4954c8ae27b0e589f975610
 100644
--- a/gcc/tree-vect-slp-patterns.c
+++ b/gcc/tree-vect-slp-patterns.c
@@ -240,7 +240,8 @@ linear_loads_p (slp_tree_to_load_perm_map_t *perm_cache, 
slp_tree root)
 {
   complex_load_perm_t res = linear_loads_p (perm_cache, child);
   kind = vect_merge_perms (kind, res.first);
-  if (kind == PERM_UNKNOWN)
+  /* Unknown and Top are not valid on blends as they produce no permute.  
*/
+  if (kind == PERM_UNKNOWN || kind == PERM_TOP)
return retval;
   all_loads.safe_push (res.second);
 }


-- 
diff --git a/gcc/testsuite/gcc.target/i386/pr98264.c b/gcc/testsuite/gcc.target/i386/pr98264.c
new file mode 100644
index ..ea235277911f2a48b4b6f2ccd75a4f9000918599
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr98264.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-O3 -w" } */
+
+a[], g[], h[];
+double b, c;
+double j[];
+i;
+l() {
+  int e = 0;
+  for (; e < 80; e += 4) {
+a[0] = h[e];
+a[1] = h[e + 1];
+j[0] = a[0] - c;
+j[1] = a[1] + b;
+__attribute__(()) k = *(double *)a, e, f = e = 0;
+*g = k;
+double *d = j;
+for (; e < 2; e++)
+  if (d[e])
+i = f;
+  }
+}
diff --git a/gcc/tree-vect-slp-patterns.c b/gcc/tree-vect-slp-patterns.c
index bb2830d1d35d1607d1566868ffbcead97e4790d7..fede88923af8521ee4954c8ae27b0e589f975610 100644
--- a/gcc/tree-vect-slp-patterns.c
+++ b/gcc/tree-vect-slp-patterns.c
@@ -240,7 +240,8 @@ linear_loads_p (slp_tree_to_load_perm_map_t *perm_cache, slp_tree root)
 {
   complex_load_perm_t res = linear_loads_p (perm_cache, child);
   kind = vect_merge_perms (kind, res.first);
-  if (kind == PERM_UNKNOWN)
+  /* Unknown and Top are not valid on blends as they produce no permute.  */
+  if (kind == PERM_UNKNOWN || kind == PERM_TOP)
 	return retval;
   all_loads.safe_push (res.second);
 }

Re: [PATCH] i386: Make -march=x86-64-v[234] behave more like other -march= options

[H.J. Lu via Gcc-patches]

On Mon, Dec 14, 2020 at 7:09 AM Uros Bizjak  wrote:
>
> On Mon, Dec 14, 2020 at 2:13 PM Jakub Jelinek  wrote:
> >
> > Hi!
> >
> > If somebody has -march=x86-64-v2 (or -v3 or -v4) in $CFLAGS, $CXXFLAGS etc.,
> > then -m32 or -mabi=ms stops working.
> > What is worse, if one configures gcc --with-arch-32=x86-64-v2 (or -v3 or 
> > -v4),
> > then -mabi=ms stops working.
> >
> > I think that is a nightmare user experience.  It is ok that x86-64-v[234]
> > behave slightly different from other -march= options (in that they imply
> > unless overridden -mtune=generic rather then -mtune= equal to the -march
> > argument), but the error when one mixes it with -mabi=ms, or -m32 doesn't
> > improve anything.
> > It is true that the exact option set is only defined in the x86-64 psABI
> > (IMHO that is a mistake too, we should copy that into the GCC documentation
> > like we document it for any other -march= option), but there is no reason
> > why that exact set of CPU features can't be used for other ABIs, it is just
> > a set of CPU features.  If we add micro-architecture levels to the 32-bit
> > ABI (I doubt anyone wants to do that, but just hypothetically), then those
> > micro-architecture levels wouldn't certainly be called x86-64-v* but perhaps
> > i386-v*.
> > In the tests, __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 can't be expected on -m32
> > not because the CPU feature wouldn't be set, but because the instruction
> > is 64-bit only and 32-bit code doesn't have __int128 etc. support.
> >
> > Ok for trunk if this passes full bootstrap/regtest?
> >
> > 2020-12-14  Jakub Jelinek  
> >
> > * config/i386/i386-options.c (ix86_option_override_internal): Don't
> > error on -march=x86-64-v[234] with -m32 or -mabi=ms.
> > * config.gcc: Don't reject --with-arch=x86-64-v[234] or
> > --with-arch_32=x86-64-v[234].
> > * doc/invoke.texi (-march=x86-64-v[234]): Document what the option
> > does for other ABIs.
> >
> > * gcc.target/i386/x86-64-v2.c: Don't expect
> > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 to be defined with -m32.
> > * gcc.target/i386/x86-64-v2-other.c: New test.
> > * gcc.target/i386/x86-64-v2-msabi.c: New test.
> > * gcc.target/i386/x86-64-v3.c: Fix a comment pasto.  Don't expect
> > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 to be defined with -m32.
> > * gcc.target/i386/x86-64-v3-other.c: New test.
> > * gcc.target/i386/x86-64-v3-msabi.c: New test.
> > * gcc.target/i386/x86-64-v4.c:Don't expect
> > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 to be defined with -m32.
> > * gcc.target/i386/x86-64-v4-other.c: New test.
> > * gcc.target/i386/x86-64-v4-msabi.c: New test.
>
> LGTM, but please allow some time for HJ to comment.

LGTM too.

Thanks.

> Thanks,
> Uros.
>
> >
> > --- gcc/config/i386/i386-options.c.jj   2020-12-08 15:43:46.641140657 +0100
> > +++ gcc/config/i386/i386-options.c  2020-12-14 13:31:51.864733294 +0100
> > @@ -2084,17 +2084,6 @@ ix86_option_override_internal (bool main
> > return false;
> >   }
> >
> > -   /* The feature-only micro-architecture levels that use
> > -  PTA_NO_TUNE are only defined for the x86-64 psABI.  */
> > -   if ((processor_alias_table[i].flags & PTA_NO_TUNE) != 0
> > -   && (!TARGET_64BIT_P (opts->x_ix86_isa_flags)
> > -   || opts->x_ix86_abi != SYSV_ABI))
> > - {
> > -   error (G_("%qs architecture level is only defined"
> > - " for the x86-64 psABI"), opts->x_ix86_arch_string);
> > -   return false;
> > - }
> > -
> > ix86_schedule = processor_alias_table[i].schedule;
> > ix86_arch = processor_alias_table[i].processor;
> >
> > --- gcc/config.gcc.jj   2020-12-08 10:36:28.817303511 +0100
> > +++ gcc/config.gcc  2020-12-14 14:00:27.571656138 +0100
> > @@ -4517,10 +4517,8 @@ case "${target}" in
> > case " $x86_64_archs " in
> > *" ${val} "*)
> > # Disallow x86-64-v* for 
> > --with-cpu=/--with-tune=
> > -   # or --with-arch= or 
> > --with-arch_32=
> > -   # It can be only specified 
> > in --with-arch_64=
> > case "x$which$val" in
> > -   
> > xcpu*x86-64-v*|xtune*x86-64-v*|xarchx86-64-v*|xarch_32x86-64-v*)
> > +   
> > xcpu*x86-64-v*|xtune*x86-64-v*)
> > echo "Unknown CPU 
> > given in --with-$which=$val." 1>&2
> > exit 1
> > ;;
> > --- gcc/doc/invoke.texi.jj  2020-12-09 23:51:01.284558982 +0100
> > +++ 

Re: [PATCH] i386: Make -march=x86-64-v[234] behave more like other -march= options

[Uros Bizjak via Gcc-patches]

On Mon, Dec 14, 2020 at 2:13 PM Jakub Jelinek  wrote:
>
> Hi!
>
> If somebody has -march=x86-64-v2 (or -v3 or -v4) in $CFLAGS, $CXXFLAGS etc.,
> then -m32 or -mabi=ms stops working.
> What is worse, if one configures gcc --with-arch-32=x86-64-v2 (or -v3 or -v4),
> then -mabi=ms stops working.
>
> I think that is a nightmare user experience.  It is ok that x86-64-v[234]
> behave slightly different from other -march= options (in that they imply
> unless overridden -mtune=generic rather then -mtune= equal to the -march
> argument), but the error when one mixes it with -mabi=ms, or -m32 doesn't
> improve anything.
> It is true that the exact option set is only defined in the x86-64 psABI
> (IMHO that is a mistake too, we should copy that into the GCC documentation
> like we document it for any other -march= option), but there is no reason
> why that exact set of CPU features can't be used for other ABIs, it is just
> a set of CPU features.  If we add micro-architecture levels to the 32-bit
> ABI (I doubt anyone wants to do that, but just hypothetically), then those
> micro-architecture levels wouldn't certainly be called x86-64-v* but perhaps
> i386-v*.
> In the tests, __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 can't be expected on -m32
> not because the CPU feature wouldn't be set, but because the instruction
> is 64-bit only and 32-bit code doesn't have __int128 etc. support.
>
> Ok for trunk if this passes full bootstrap/regtest?
>
> 2020-12-14  Jakub Jelinek  
>
> * config/i386/i386-options.c (ix86_option_override_internal): Don't
> error on -march=x86-64-v[234] with -m32 or -mabi=ms.
> * config.gcc: Don't reject --with-arch=x86-64-v[234] or
> --with-arch_32=x86-64-v[234].
> * doc/invoke.texi (-march=x86-64-v[234]): Document what the option
> does for other ABIs.
>
> * gcc.target/i386/x86-64-v2.c: Don't expect
> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 to be defined with -m32.
> * gcc.target/i386/x86-64-v2-other.c: New test.
> * gcc.target/i386/x86-64-v2-msabi.c: New test.
> * gcc.target/i386/x86-64-v3.c: Fix a comment pasto.  Don't expect
> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 to be defined with -m32.
> * gcc.target/i386/x86-64-v3-other.c: New test.
> * gcc.target/i386/x86-64-v3-msabi.c: New test.
> * gcc.target/i386/x86-64-v4.c:Don't expect
> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 to be defined with -m32.
> * gcc.target/i386/x86-64-v4-other.c: New test.
> * gcc.target/i386/x86-64-v4-msabi.c: New test.

LGTM, but please allow some time for HJ to comment.

Thanks,
Uros.

>
> --- gcc/config/i386/i386-options.c.jj   2020-12-08 15:43:46.641140657 +0100
> +++ gcc/config/i386/i386-options.c  2020-12-14 13:31:51.864733294 +0100
> @@ -2084,17 +2084,6 @@ ix86_option_override_internal (bool main
> return false;
>   }
>
> -   /* The feature-only micro-architecture levels that use
> -  PTA_NO_TUNE are only defined for the x86-64 psABI.  */
> -   if ((processor_alias_table[i].flags & PTA_NO_TUNE) != 0
> -   && (!TARGET_64BIT_P (opts->x_ix86_isa_flags)
> -   || opts->x_ix86_abi != SYSV_ABI))
> - {
> -   error (G_("%qs architecture level is only defined"
> - " for the x86-64 psABI"), opts->x_ix86_arch_string);
> -   return false;
> - }
> -
> ix86_schedule = processor_alias_table[i].schedule;
> ix86_arch = processor_alias_table[i].processor;
>
> --- gcc/config.gcc.jj   2020-12-08 10:36:28.817303511 +0100
> +++ gcc/config.gcc  2020-12-14 14:00:27.571656138 +0100
> @@ -4517,10 +4517,8 @@ case "${target}" in
> case " $x86_64_archs " in
> *" ${val} "*)
> # Disallow x86-64-v* for 
> --with-cpu=/--with-tune=
> -   # or --with-arch= or 
> --with-arch_32=
> -   # It can be only specified in 
> --with-arch_64=
> case "x$which$val" in
> -   
> xcpu*x86-64-v*|xtune*x86-64-v*|xarchx86-64-v*|xarch_32x86-64-v*)
> +   
> xcpu*x86-64-v*|xtune*x86-64-v*)
> echo "Unknown CPU 
> given in --with-$which=$val." 1>&2
> exit 1
> ;;
> --- gcc/doc/invoke.texi.jj  2020-12-09 23:51:01.284558982 +0100
> +++ gcc/doc/invoke.texi 2020-12-14 13:36:45.523458639 +0100
> @@ -29778,8 +29778,9 @@ A generic CPU with 64-bit extensions.
>  @itemx x86-64-v3
>  @itemx x86-64-v4
>  These choices for @var{cpu-type} select the corresponding
> -micro-architecture level from the x86-64 psABI.  They 

Re: rs6000: Update the processor defaults for FreeBSD

[Piotr Kubaj via Gcc-patches]

On 20-12-13 09:48:35, Segher Boessenkool wrote:
> Hi!
> 
> On Sun, Dec 13, 2020 at 03:34:57PM +0100, Piotr Kubaj wrote:
> > this is only default tuning (-mtune, not -mcpu).
> 
> It is both, actually (-mcpu= implies -mtune=)
Yes, but -mtune doesn't imply -mcpu. If I set up only -mtune, -mcpu is the 
generic one (ppc970 for BE)
> 
> > Linux also does similarly in linux64.h:
> >  74 #undef  PROCESSOR_DEFAULT
> >  75 #define PROCESSOR_DEFAULT PROCESSOR_POWER7
> >  76 #undef  PROCESSOR_DEFAULT64
> >  77 #define PROCESSOR_DEFAULT64 PROCESSOR_POWER8
> 
> Yes, but we still default to power4 on BE Linux (and power8 on LE).  I
> get lost in the macro maze here, not sure how that works :-)
> 
> > Although there is hard to explain (for me) setting to tune for POWER7 on 
> > 32-bits. POWER7 is 64-bit and it should be more reasonable to optimize for 
> > the last 32-bit machines that still may be in use (so G4).
> 
> 7450 has very different optimisation than 970.  Power7 and 970 have
> largely similar pipelines.
Yes, but the point is that users on 32-bit machines don't use POWER7, but most 
likely G4.

> 
> > That said, on the 64-bit front, we will just match the Linux setting.
> 
> Compile a very simple test and look at the .machine in the generated .s?
> Does that do what you want?
Yes, I just tested it (on BE).
pkubaj@talos:$/usr/home/pkubaj$ cat test.c
#include 

int main()
{
printf("Hello world!");
}

I built it twice, with GCC 9.3 without my patch and with GCC 10.1 with my 
patch. The only difference is:
pkubaj@talos:$/usr/home/pkubaj$ diff -u test.s.9 test.s.10
--- test.s.92020-12-14 15:51:43.203263000 +0100
+++ test.s.10   2020-12-14 15:52:01.147238000 +0100
@@ -43,5 +43,5 @@
.cfi_endproc
 .LFE1:
.size   main,.-main
-   .ident  "GCC: (FreeBSD Ports Collection) 9.3.0"
+   .ident  "GCC: (FreeBSD Ports Collection) 10.2.0"
.section.note.GNU-stack,"",@progbits

Both have .machine power4:
pkubaj@talos:$/usr/home/pkubaj$ grep .machine test.s.*
test.s.10:  .machine power4
test.s.9:   .machine power4

I'm not sure where GCC sets power8 for LE, but it's definitely somewhere else.

So IMO this patch is good to go.

Thanks,
Piotr Kubaj.


signature.asc
Description: PGP signature

Re: [PATCH] testsuite: Fix various scan-assembler-symbol-section issues

[Rainer Orth]

Hi David,

> On Fri, Dec 4, 2020 at 5:35 AM Rainer Orth  
> wrote:
>
>> On AIX 7.2, there are changes like
>>
>> -PASS: g++.dg/gomp/tls-5.C -std=c++2a scan-assembler-symbol-section
>> symbol ^_?ir$ (found ir) has section ^\\.tbss|\\[TL\\] (found
>> _tls5.tls_[TL],4)
>> +PASS: g++.dg/gomp/tls-5.C -std=c++2a scan-assembler-symbol-section
>> symbol ^_?ir$ (found ir) has section ^\\.tbss|\\[TL\\] (found
>> _tls5.tls_[TL])
>>
>> i.e. the ",4" after (?) the section name is now stripped.  I believe
>> this is benign: David?
>
> The ",4" is the symbol alignment.  It is not necessary for the purpose
> of the tests.

fine, thanks for the clarification.

> Thanks for looking further into this problem.  As I mentioned in my
> earlier reply to the patch itself, I believe that this new feature and
> infrastructure change should have been tested and fixed on
> non-Linux/ELF/x86 architectures, not left as an exercise for the
> maintainers of other targets.  A patch that introduces regressions in
> the testsuite should be fixed or reverted and should be the
> responsibility of the author -- whether the change is to the compiler
> or to the testsuite.

Yes and no: given the trouble I had myself trying an AIX bootstrap and
test and the effort it took guiding Iain through a Solaris 11.3
bootstrap on gcc211, I fear it's unreasonable to demand developers to do
all this testing themselves: if you have to address only one issue per
unfamiliar target while trying to, we'll loose contributors very
quickly.  I believe we should be able to get the setup of the various
cfarm hosts better in sync with the guidelines documented in the wiki to
avoid such trouble.

Ultimately, something like the trybot feature of the (now mostly
defunct) gdb buildbots could ease such pre-commit tests.

But I fully agree that the original patch should have seen way wider
cross-platform testing before being committed: asking target maintainers
for help usually works well enough: one just cannot expect them to spot
any patch that might require such testing themselves.

Rainer

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

Re: [PATCH] testsuite: Fix various scan-assembler-symbol-section issues

[Rainer Orth]

Hi Iain,

>> * Next, I ran the tests on Darwin 11 and found two failing tests:
[...]
>>  The other failing test is
>>
>> FAIL: g++.dg/gomp/tls-5.C  -std=c++14  scan-assembler-symbol-section
>> symbol ^_?_ZGR2ir_\$ (symbol not found) has section
>> ^.tdata|[TL]
>> FAIL: g++.dg/gomp/tls-5.C  -std=c++14  scan-assembler-symbol-section
>> symbol ^_?ir\$ (symbol not found) has section ^.tbss|[TL]
>>
>>  Other scans are guarded by target tls_native, and indeed the assembler
>>  output has
>>
>> ___emutls_v._ZGR2ir_:
>> ___emutls_t._ZGR2ir_:
>>
>> ___emutls_v.ir:
>
> I was half in mind to test for those symbols for emulated TLS (since they
> indicate
> the moral equivalent of placing the data in the special sections) - but
> this wasn’t
> possible absent the selector / xfail.

indeed.  One could now add such a check if desired.

>>  Unfortunately scan-assembler-symbol-section doesn't support selects
>>  yet, which this test implements both for the benefit of this test and
>>  for symmetry.
>
> … so now we ought to be able to make the test meaningful on emulated TLS
> otherwise, it’s just consuming cpu - and we might as well have :
>
> +// { dg-require-effective-target tls_native }
>
> at the top…

>> * Last but no least, I have an issue with the section argument to
>>  scan-assembler-symbol-section: right now the test developer needs to
>>  know about all possible formats of section names on a wide range of
>>  targets (just as he needs to take USER_LABEL_PREFIX etc. into account
>>  for the symbol name).  This feels like a bad abstraction to me,
>>  although I'm uncertain what a better one would be.  One vague idea is
>>  to use the ELF section name as a token.  The framework can then
>>  translate it into the name appropriate for the current target.  This
>>  way the knowledge would at least be centralized in one place and the
>>  task would only come up once per section name/type.  Thoughts?
>
> I think this is very hard to get right generically - I don’t see an
> algorithmic
> mapping between . or per-function ELF section naming semantics and,
> for example, MACH-O section names.  I fear that it would end up being a
> look-up table and therefore probably better overt in the individual tests.

I'd been thinking of a lookup table myself.  We're doing something
similar already in scanasm.exp (hidden-scan-for).  The advantage of
doing it in the framework is one has to worry about the issue only once
per target, rather than (potentially) several times in different tests.

>> I guess this patch could go in now as is since it addresses all current
>> failures on all targets I could test, with room for later improvement?
>>
>> Sorry for this long and winded mail, but the issue is messy beyond belief.
>
> indeed it is - so much so that I punted on trying to fix it (very happy you
> picked it up).

Given that the patch is a strict improvement as is and there were no
objections, I've now committed it.  I expect to work on the framework
test issues later, but that's not urgent given they aren't run by
default, so maybe GCC 12 material.

Rainer

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

Re: [PATCH v2] aix: Fixinclude updates [PR98208]

[Nathan Sidwell]

On 12/14/20 7:19 AM, Ilya Leoshkevich wrote:

On Fri, 2020-12-11 at 07:51 -0500, Nathan Sidwell wrote:


I'm pretty sure this is wrong.  I think the test_text in
inclhack.def
should be a pre-fixed string that the testsuite presumably checks is
converted.


You're right; I've added your change from the Bugzilla and updated the
expectation.  Does the following look better?


Yes thanks.  I don;t really understand why the base/sys/types.h change 
is needed, (surely there are other types.h fixincs?)   But if this makes 
the tests pass, so be it!


nathan



After 92648faa1cb2 ("aix: Fixinclude") make check-fixincludes began to
fail (at least on gcc121 machine).  Fix by updating fixincludes/tests
and rerunning genfixes.

Co-developed-by: Nathan Sidwell 

fixincludes/ChangeLog:

2020-12-11  Ilya Leoshkevich  

* fixincl.x: Rerun genfixes.
* inclhack.def(aix_physadr_t): Change test_text to something
that needs to be replaced.
* tests/base/sys/types.h(aix_physadr_t): Add expectation.
---
  fixincludes/fixincl.x  | 4 ++--
  fixincludes/inclhack.def   | 2 +-
  fixincludes/tests/base/sys/types.h | 5 +
  3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/fixincludes/fixincl.x b/fixincludes/fixincl.x
index 21439652bce..cc17edfba0b 100644
--- a/fixincludes/fixincl.x
+++ b/fixincludes/fixincl.x
@@ -2,11 +2,11 @@
   *
   * DO NOT EDIT THIS FILE   (fixincl.x)
   *
- * It has been AutoGen-ed  October 21, 2020 at 10:43:22 AM by AutoGen 5.18.16
+ * It has been AutoGen-ed  December  9, 2020 at 11:16:08 AM by AutoGen 5.18.16
   * From the definitionsinclhack.def
   * and the template file   fixincl
   */
-/* DO NOT SVN-MERGE THIS FILE, EITHER Wed Oct 21 10:43:22 EDT 2020
+/* DO NOT SVN-MERGE THIS FILE, EITHER Wed Dec  9 11:16:08 EST 2020
   *
   * You must regenerate it.  Use the ./genfixes script.
   *
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 80c9adfb07c..3a4cfe06542 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -731,7 +731,7 @@ fix = {
  select= "typedef[ \t]*struct[ \t]*([{][^}]*[}][ \t]*\\*[ 
\t]*physadr_t;)";
  c_fix = format;
  c_fix_arg = "typedef struct __physadr_s %1";
-test_text = "typedef struct __physadr_s {";
+test_text = "typedef  struct { random stuff } *   physadr_t;";
  };
  
  /*

diff --git a/fixincludes/tests/base/sys/types.h 
b/fixincludes/tests/base/sys/types.h
index 683b5e93ecd..7340e76b175 100644
--- a/fixincludes/tests/base/sys/types.h
+++ b/fixincludes/tests/base/sys/types.h
@@ -9,6 +9,11 @@
  
  
  
+#if defined( AIX_PHYSADR_T_CHECK )

+typedef struct __physadr_s { random stuff } *  physadr_t;
+#endif  /* AIX_PHYSADR_T_CHECK */
+
+
  #if defined( GNU_TYPES_CHECK )
  #if !defined(_GCC_PTRDIFF_T)
  #define _GCC_PTRDIFF_T




--
Nathan Sidwell

Re: [PATCH] gcc: handle double quotes in symbol name during stabstrings generation

[CHIGOT, CLEMENT via Gcc-patches]

Hi Ian,

Yes it is.

Thanks,
Clément

From: Ian Lance Taylor 
Sent: Friday, December 11, 2020 6:58 PM
To: CHIGOT, CLEMENT 
Cc: gcc-patches@gcc.gnu.org ; David Edelsohn 
; gofrontend-dev 
Subject: Re: [PATCH] gcc: handle double quotes in symbol name during 
stabstrings generation

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

On Thu, Dec 10, 2020 at 9:09 PM Ian Lance Taylor  wrote:
>
> On Tue, Dec 8, 2020 at 5:15 AM CHIGOT, CLEMENT  
> wrote:
> >
> > Any news about this bug ? It's not urgent even if it's breaking gcc builds 
> > with Go language, but I just want to know if you need any inputs/help from 
> > me.
>
> I sent 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgolang.org%2Fcl%2F277232data=04%7C01%7Cclement.chigot%40atos.net%7C237c1d4eb8f24966de6e08d89dfe60e2%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637433063155263771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=NFRDFAbOGs%2FPqcYp%2BN4U80xXQctwoX3pUSY%2FVrca%2B4w%3Dreserved=0
>  to fix this problem.

Should be fixed now.

Ian


> > 
> > From: CHIGOT, CLEMENT 
> > Sent: Wednesday, December 2, 2020 5:14 PM
> > To: Ian Lance Taylor 
> > Cc: gcc-patches@gcc.gnu.org ; David Edelsohn 
> > 
> > Subject: Re: [PATCH] gcc: handle double quotes in symbol name during 
> > stabstrings generation
> >
> > Hi Ian,
> >
> > Here is the test case.
> > If you're compiling with -gstabs you should have a line looking like:
> > .stabs  "type..struct{Type go.bug1.ObjectIdentifier;Value 
> > [][]go.bug1.Extension{asn1:"set"}}:G(0,7)=xsStructType:",32,0,0,0
> >
> > As you can see the " around for "set" aren't escaped.
> > I didn't try to reproduce it on linux/amd64, but I did on linux/ppc64le and 
> > I don't think it's a ppc-only bug.
> >
> > Clément
> > 
> > From: Ian Lance Taylor 
> > Sent: Wednesday, December 2, 2020 4:55 PM
> > To: CHIGOT, CLEMENT 
> > Cc: gcc-patches@gcc.gnu.org ; David Edelsohn 
> > 
> > Subject: Re: [PATCH] gcc: handle double quotes in symbol name during 
> > stabstrings generation
> >
> > Caution! External email. Do not open attachments or click links, unless 
> > this email comes from a known sender and you know the content is safe.
> >
> > On Wed, Dec 2, 2020 at 4:24 AM CHIGOT, CLEMENT  
> > wrote:
> > >
> > > Since the new gccgo mangling scheme, libgo compilation is broken on AIX 
> > > (or in Linux with -gstabs) because of a type symbol having a " in its 
> > > name. I've made a patch (see attachment) in order to fix stabstring 
> > > generation, because, IMO, it should be handled anyway.
> > > However, it happens only once in the whole libgo so I don't know if this 
> > > " is intended or not. The problematic type is there: 
> > > https://github.com/golang/go/blob/master/src/crypto/x509/x509.go#L2674. 
> > > Other similar types don't trigger the bug though.
> > >
> > > I've a minimal test which might can be added if you wish, in Golang tests 
> > > or in Gcc Go tests or in both ?
> > >
> > > If the patch is okay, could you please apply it for me ?
> >
> > Could you show me the small test case?  I don't think I understand the
> > problem.  In DWARF I don't see any symbol names with quotation marks.
> > I'm not yet sure that your patch is the right fix.  Thanks.
> >
> > Ian

Re: C++ Module Binding Vector

[Nathan Sidwell]

On 12/11/20 3:39 PM, Jason Merrill wrote:

On 12/2/20 9:19 AM, Nathan Sidwell wrote:
This is modified from the original patch.  firstly it contains a few 
more necessary bits.  But mainly I renamed the entities from 



+extern tree make_binding_vec    (tree, unsigned clusters);

...

+make_binding_vec (tree name, unsigned clusters MEM_STAT_DECL)


You need the MEM_STAT decoration on the declaration as well, or building 
with --enable-gather-detailed-mem-stats breaks.


oops, thanks for fixing

nathan

--
Nathan Sidwell

Re: [PATCH]AArch64: Add NEON, SVE and SVE2 RTL patterns for Complex Addition, Multiply and FMA.

[Richard Sandiford via Gcc-patches]

Rearranging slightly…

> @@ -708,6 +713,10 @@ (define_c_enum "unspec"
>  UNSPEC_FCMLA90   ; Used in aarch64-simd.md.
>  UNSPEC_FCMLA180  ; Used in aarch64-simd.md.
>  UNSPEC_FCMLA270  ; Used in aarch64-simd.md.
> +UNSPEC_FCMUL ; Used in aarch64-simd.md.
> +UNSPEC_FCMUL180  ; Used in aarch64-simd.md.
> +UNSPEC_FCMLS ; Used in aarch64-simd.md.
> +UNSPEC_FCMLS180  ; Used in aarch64-simd.md.
>  UNSPEC_ASRD  ; Used in aarch64-sve.md.
>  UNSPEC_ADCLB ; Used in aarch64-sve2.md.
>  UNSPEC_ADCLT ; Used in aarch64-sve2.md.
> @@ -726,6 +735,10 @@ (define_c_enum "unspec"
>  UNSPEC_CMLA180   ; Used in aarch64-sve2.md.
>  UNSPEC_CMLA270   ; Used in aarch64-sve2.md.
>  UNSPEC_CMLA90; Used in aarch64-sve2.md.
> +UNSPEC_CMLS  ; Used in aarch64-sve2.md.
> +UNSPEC_CMLS180   ; Used in aarch64-sve2.md.
> +UNSPEC_CMUL  ; Used in aarch64-sve2.md.
> +UNSPEC_CMUL180   ; Used in aarch64-sve2.md.
>  UNSPEC_COND_FCVTLT   ; Used in aarch64-sve2.md.
>  UNSPEC_COND_FCVTNT   ; Used in aarch64-sve2.md.
>  UNSPEC_COND_FCVTX; Used in aarch64-sve2.md.
> […]
> @@ -3418,7 +3457,85 @@ (define_int_attr rot [(UNSPEC_CADD90 "90")
> (UNSPEC_COND_FCMLA "0")
> (UNSPEC_COND_FCMLA90 "90")
> (UNSPEC_COND_FCMLA180 "180")
> -   (UNSPEC_COND_FCMLA270 "270")])
> +   (UNSPEC_COND_FCMLA270 "270")
> +   (UNSPEC_FCMUL "0")
> +   (UNSPEC_FCMUL180 "180")])
> +
> +;; A conjucate is a negation of the imaginary component
> +;; The number in the inspecs are the rotation component of the instruction, 
> e.g

unspecs

> +;; FCMLS180 means use the instruction with #180.
> +;; The iterator is used to produce the right name mangling for the function.
> +;;
> +;; The rotation value does not directly correlate to a rotation along the 
> argant
> +;; plane as the instructions only perform half the computation.
> +;;
> +;; For the implementation we threat any rotation by 0 as normal and 180 as
> +;; conjucate.  This is only for implementing the vectorizer patterns.
> +(define_int_attr rot_op [(UNSPEC_FCMLS "")
> +  (UNSPEC_FCMLS180 "_conj")
> +  (UNSPEC_FCMLA "")
> +  (UNSPEC_FCMLA180 "_conj")
> +  (UNSPEC_FCMUL "")
> +  (UNSPEC_FCMUL180 "_conj")
> +  (UNSPEC_CMLS "")
> +  (UNSPEC_CMLA "")
> +  (UNSPEC_CMLA180 "_conj")
> +  (UNSPEC_CMUL "")
> +  (UNSPEC_CMUL180 "_conj")])
> +

Realise this is being awkward, sorry, but: I think it would be clearer
to use unspecs with _CONJ in the name for the conjugated forms, rather
than explain away how 180 is being used.

All four rotations make sense as a pair (i.e. as a full complex
multiplication), rather than just as a standalone instruction:

  FMLA= a + b * c
  FMLA90  = a + b * c * i
  FMLA180 = a - b * c
  FMLA270 = a - b * c * i

I.e. FMLA180 == FMLS and FMLA270 == “FMLS90” (a made-up term).
“FMLS180” is equivalent to FMLA.

We can then additionally conjugate “b” in each of the four forms above.

At the moment, FMLA90 and FMLA270/FMLS90 (and their conjugate forms)
aren't exposed as optabs, but that could change in future.

So I think we should avoid introducing FMLS and FMLS180 and instead use
(name in patch -> suggested replacement):

  FMLA -> FMLA
  FMLS -> FMLA180
  FMLA180 -> FMLA_CONJ
  FMLS180 -> FMLA180_CONJ

where _CONJ has the effect of adding 180 degrees to the second
rotation amount.

Then:

> +;; The complex operations when performed on a real complex number require two
> +;; instructions to perform the operation. e.g. complex multiplication 
> requires
> +;; two FCMUL with a particular rotation value.
> +;;
> +;; These values can be looked up in rotsplit1 and rotsplit2.  as an example
> +;; FCMUL needs the first instruction to use #0 and the second #90.
> +(define_int_attr rotsplit1 [(UNSPEC_FCMLA "0")
> + (UNSPEC_FCMLA180 "0")
> + (UNSPEC_FCMUL "0")
> + (UNSPEC_FCMUL180 "0")
> + (UNSPEC_FCMLS "270")
> + (UNSPEC_FCMLS180 "90")])
> +
> +(define_int_attr rotsplit2 [(UNSPEC_FCMLA "90")
> + (UNSPEC_FCMLA180 "270")
> + (UNSPEC_FCMUL "90")
> + (UNSPEC_FCMUL180 "270")
> + (UNSPEC_FCMLS "180")
> + (UNSPEC_FCMLS180 "180")])

would become something like:

(define_int_attr rotsplit1 [(UNSPEC_FCMLA "0")
(UNSPEC_FCMLA_CONJ "0")
(UNSPEC_FCMLA180 "180")
(UNSPEC_FCMLA180_CONJ "180")
(UNSPEC_FCMUL "0")

[PATCH] i386: Make -march=x86-64-v[234] behave more like other -march= options

[Jakub Jelinek via Gcc-patches]

Hi!

If somebody has -march=x86-64-v2 (or -v3 or -v4) in $CFLAGS, $CXXFLAGS etc.,
then -m32 or -mabi=ms stops working.
What is worse, if one configures gcc --with-arch-32=x86-64-v2 (or -v3 or -v4),
then -mabi=ms stops working.

I think that is a nightmare user experience.  It is ok that x86-64-v[234]
behave slightly different from other -march= options (in that they imply
unless overridden -mtune=generic rather then -mtune= equal to the -march
argument), but the error when one mixes it with -mabi=ms, or -m32 doesn't
improve anything.
It is true that the exact option set is only defined in the x86-64 psABI
(IMHO that is a mistake too, we should copy that into the GCC documentation
like we document it for any other -march= option), but there is no reason
why that exact set of CPU features can't be used for other ABIs, it is just
a set of CPU features.  If we add micro-architecture levels to the 32-bit
ABI (I doubt anyone wants to do that, but just hypothetically), then those
micro-architecture levels wouldn't certainly be called x86-64-v* but perhaps
i386-v*.
In the tests, __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 can't be expected on -m32
not because the CPU feature wouldn't be set, but because the instruction
is 64-bit only and 32-bit code doesn't have __int128 etc. support.

Ok for trunk if this passes full bootstrap/regtest?

2020-12-14  Jakub Jelinek  

* config/i386/i386-options.c (ix86_option_override_internal): Don't
error on -march=x86-64-v[234] with -m32 or -mabi=ms.
* config.gcc: Don't reject --with-arch=x86-64-v[234] or
--with-arch_32=x86-64-v[234].
* doc/invoke.texi (-march=x86-64-v[234]): Document what the option
does for other ABIs.

* gcc.target/i386/x86-64-v2.c: Don't expect
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 to be defined with -m32.
* gcc.target/i386/x86-64-v2-other.c: New test.
* gcc.target/i386/x86-64-v2-msabi.c: New test.
* gcc.target/i386/x86-64-v3.c: Fix a comment pasto.  Don't expect
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 to be defined with -m32.
* gcc.target/i386/x86-64-v3-other.c: New test.
* gcc.target/i386/x86-64-v3-msabi.c: New test.
* gcc.target/i386/x86-64-v4.c:Don't expect
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 to be defined with -m32.
* gcc.target/i386/x86-64-v4-other.c: New test.
* gcc.target/i386/x86-64-v4-msabi.c: New test.

--- gcc/config/i386/i386-options.c.jj   2020-12-08 15:43:46.641140657 +0100
+++ gcc/config/i386/i386-options.c  2020-12-14 13:31:51.864733294 +0100
@@ -2084,17 +2084,6 @@ ix86_option_override_internal (bool main
return false;
  }
 
-   /* The feature-only micro-architecture levels that use
-  PTA_NO_TUNE are only defined for the x86-64 psABI.  */
-   if ((processor_alias_table[i].flags & PTA_NO_TUNE) != 0
-   && (!TARGET_64BIT_P (opts->x_ix86_isa_flags)
-   || opts->x_ix86_abi != SYSV_ABI))
- {
-   error (G_("%qs architecture level is only defined"
- " for the x86-64 psABI"), opts->x_ix86_arch_string);
-   return false;
- }
-
ix86_schedule = processor_alias_table[i].schedule;
ix86_arch = processor_alias_table[i].processor;
 
--- gcc/config.gcc.jj   2020-12-08 10:36:28.817303511 +0100
+++ gcc/config.gcc  2020-12-14 14:00:27.571656138 +0100
@@ -4517,10 +4517,8 @@ case "${target}" in
case " $x86_64_archs " in
*" ${val} "*)
# Disallow x86-64-v* for 
--with-cpu=/--with-tune=
-   # or --with-arch= or 
--with-arch_32=
-   # It can be only specified in 
--with-arch_64=
case "x$which$val" in
-   
xcpu*x86-64-v*|xtune*x86-64-v*|xarchx86-64-v*|xarch_32x86-64-v*)
+   xcpu*x86-64-v*|xtune*x86-64-v*)
echo "Unknown CPU given 
in --with-$which=$val." 1>&2
exit 1
;;
--- gcc/doc/invoke.texi.jj  2020-12-09 23:51:01.284558982 +0100
+++ gcc/doc/invoke.texi 2020-12-14 13:36:45.523458639 +0100
@@ -29778,8 +29778,9 @@ A generic CPU with 64-bit extensions.
 @itemx x86-64-v3
 @itemx x86-64-v4
 These choices for @var{cpu-type} select the corresponding
-micro-architecture level from the x86-64 psABI.  They are only available
-when compiling for an x86-64 target that uses the System V psABI@.
+micro-architecture level from the x86-64 psABI.  On ABIs other than
+the x86-64 psABI they select the same CPU features as the x86-64 psABI
+documents for the particular micro-architecture level.
 
 Since these 

Re: [PATCH][GCC][PR target/98177] aarch64: SVE: ICE in expand_direct_optab_fn

[Richard Sandiford via Gcc-patches]

Przemyslaw Wirkus  writes:
> Hi,
>
> Recent 'support SVE comparisons for unpacked integers' patch extends
> operands of define_expands from SVE_FULL to SVE_ALL. This causes an ICE
> hence this PR patch.
>
> This patch adds this relaxation for:
> + reduc__scal_ and
> + arch64_pred_reduc__
> in order to support extra modes. Missing modes were used in REDUC_MAX.
>
> Original PR snippet proposed to reproduce issue was only causing ICE for C++
> compiler (see pr98177-1 test cases). I've slightly modified original snippet 
> in
> order to reproduce issue on both C and C++ compilers. These are pr98177-2
> test cases.
>
> Bootstrap/regression test for AArch64 aarch64-elf and no issues.

This is a bug in the vectoriser: the vectoriser shouldn't generate
IFN_REDUC_MAX calls that the target doesn't support.

I think the problem comes from using the wrong interface to get the
index type for a COND_REDUCTION.  vectorizable_reduction has:

  cr_index_vector_type = build_vector_type (cr_index_scalar_type,
nunits_out);

which means that for fixed-length SVE we get a V2SI (a 64-bit Advanced
SIMD vector) instead of a VNx2SI (an SVE vector that stores SI elements
in DI containers).  It should be using:

  cr_index_vector_type = get_same_sized_vectype (cr_index_scalar_type,
 vectype_out);

instead.  Same idea for the build_vector_type call in
vect_create_epilog_for_reduction.

Thanks,
Richard

[wwwdocs] Document new Hardware-assisted AddressSanitizer

[Matthew Malcomson via Gcc-patches]

gcc-11/changes: Document new Hardware-assisted AddressSanitizer.

I have put it in the "general" section rather than AArch64 since the feature
does add a general framework, so I believe the news is interesting for people
interesting in architectures other than AArch64 that may want to implement this
for their own targets (where possible).


### Attachment also inlined for ease of reply###


diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 
46a6a37225526227fb6a46d9d3248d6ba9f36a07..0127a3f99f2ca897bf1c32e967d359fb9ace6f6b
 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -116,6 +116,24 @@ a work-in-progress.
   option (which defaults to 8 spaces per tab stop).
 
   
+  
+
+Introduce http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html;>
+  Hardware-assisted AddressSanitizer support.  This sanitizer 
currently only works
+for the AArch64 target.  It helps debug address problems similarly to
+https://github.com/google/sanitizers/wiki/AddressSanitizer;>
+  AddressSanitizer but is based on partial hardware assistance and
+provides probabilistic protection to use less RAM at runtime.
+http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html;>
+  Hardware-assisted AddressSanitizer is not production-ready for 
userspace, and is
+provided mainly for use compiling the Linux Kernel.
+
+To use this sanitizer the command line arguments are:
+
+  -fsanitize=hwaddress to instrument userspace code.
+  -fsanitize=kernel-hwaddress to instrument kernel 
code.
+
+  
 
 
 

diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 
46a6a37225526227fb6a46d9d3248d6ba9f36a07..0127a3f99f2ca897bf1c32e967d359fb9ace6f6b
 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -116,6 +116,24 @@ a work-in-progress.
   option (which defaults to 8 spaces per tab stop).
 
   
+  
+
+Introduce http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html;>
+  Hardware-assisted AddressSanitizer support.  This sanitizer 
currently only works
+for the AArch64 target.  It helps debug address problems similarly to
+https://github.com/google/sanitizers/wiki/AddressSanitizer;>
+  AddressSanitizer but is based on partial hardware assistance and
+provides probabilistic protection to use less RAM at runtime.
+http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html;>
+  Hardware-assisted AddressSanitizer is not production-ready for 
userspace, and is
+provided mainly for use compiling the Linux Kernel.
+
+To use this sanitizer the command line arguments are:
+
+  -fsanitize=hwaddress to instrument userspace code.
+  -fsanitize=kernel-hwaddress to instrument kernel 
code.
+
+  
 
 
 

[PATCH v2] aix: Fixinclude updates [PR98208]

[Ilya Leoshkevich via Gcc-patches]

On Fri, 2020-12-11 at 07:51 -0500, Nathan Sidwell wrote:
>
> I'm pretty sure this is wrong.  I think the test_text in
> inclhack.def
> should be a pre-fixed string that the testsuite presumably checks is
> converted.

You're right; I've added your change from the Bugzilla and updated the
expectation.  Does the following look better?



After 92648faa1cb2 ("aix: Fixinclude") make check-fixincludes began to
fail (at least on gcc121 machine).  Fix by updating fixincludes/tests
and rerunning genfixes.

Co-developed-by: Nathan Sidwell 

fixincludes/ChangeLog:

2020-12-11  Ilya Leoshkevich  

* fixincl.x: Rerun genfixes.
* inclhack.def(aix_physadr_t): Change test_text to something
that needs to be replaced.
* tests/base/sys/types.h(aix_physadr_t): Add expectation.
---
 fixincludes/fixincl.x  | 4 ++--
 fixincludes/inclhack.def   | 2 +-
 fixincludes/tests/base/sys/types.h | 5 +
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/fixincludes/fixincl.x b/fixincludes/fixincl.x
index 21439652bce..cc17edfba0b 100644
--- a/fixincludes/fixincl.x
+++ b/fixincludes/fixincl.x
@@ -2,11 +2,11 @@
  *
  * DO NOT EDIT THIS FILE   (fixincl.x)
  *
- * It has been AutoGen-ed  October 21, 2020 at 10:43:22 AM by AutoGen 5.18.16
+ * It has been AutoGen-ed  December  9, 2020 at 11:16:08 AM by AutoGen 5.18.16
  * From the definitionsinclhack.def
  * and the template file   fixincl
  */
-/* DO NOT SVN-MERGE THIS FILE, EITHER Wed Oct 21 10:43:22 EDT 2020
+/* DO NOT SVN-MERGE THIS FILE, EITHER Wed Dec  9 11:16:08 EST 2020
  *
  * You must regenerate it.  Use the ./genfixes script.
  *
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 80c9adfb07c..3a4cfe06542 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -731,7 +731,7 @@ fix = {
 select= "typedef[ \t]*struct[ \t]*([{][^}]*[}][ \t]*\\*[ 
\t]*physadr_t;)";
 c_fix = format;
 c_fix_arg = "typedef struct __physadr_s %1";
-test_text = "typedef struct __physadr_s {";
+test_text = "typedef   struct { random stuff } *   physadr_t;";
 };
 
 /*
diff --git a/fixincludes/tests/base/sys/types.h 
b/fixincludes/tests/base/sys/types.h
index 683b5e93ecd..7340e76b175 100644
--- a/fixincludes/tests/base/sys/types.h
+++ b/fixincludes/tests/base/sys/types.h
@@ -9,6 +9,11 @@
 
 
 
+#if defined( AIX_PHYSADR_T_CHECK )
+typedef struct __physadr_s { random stuff } *  physadr_t;
+#endif  /* AIX_PHYSADR_T_CHECK */
+
+
 #if defined( GNU_TYPES_CHECK )
 #if !defined(_GCC_PTRDIFF_T)
 #define _GCC_PTRDIFF_T
-- 
2.25.4

Re: [PATCH v5] cacheflush.2: Document __builtin___clear_cache() as a more portable alternative

[Heinrich Schuchardt via Gcc-patches]

On 12/14/20 12:43 PM, Alejandro Colomar wrote:

Reported-by: Heinrich Schuchardt 
Signed-off-by: Alejandro Colomar 


Reviewed-by: Heinrich Schuchardt 


---
  man2/cacheflush.2 | 24 
  1 file changed, 24 insertions(+)

diff --git a/man2/cacheflush.2 b/man2/cacheflush.2
index aba625721..7a2eed506 100644
--- a/man2/cacheflush.2
+++ b/man2/cacheflush.2
@@ -86,6 +86,30 @@ On Linux, this call first appeared on the MIPS architecture,
  but nowadays, Linux provides a
  .BR cacheflush ()
  system call on some other architectures, but with different arguments.
+.SH NOTES
+Unless you need the finer grained control that this system call provides,
+you probably want to use the GCC built-in function
+.BR __builtin___clear_cache (),
+which provides a portable interface
+across platforms supported by GCC and compatible compilers:
+.PP
+.in +4n
+.EX
+.BI "void __builtin___clear_cache(void *" begin ", void *" end );
+.EE
+.in
+.PP
+On platforms that don't require instruction cache flushes,
+.BR __builtin___clear_cache ()
+has no effect.
+.PP
+.IR Note :
+Until GCC 9.1.0,
+the prototype for this built-in function used
+.I char *
+instead of
+.I void *
+for the parameters.
  .SH BUGS
  Linux kernels older than version 2.6.11 ignore the
  .I addr

[PATCH v5] cacheflush.2: Document __builtin___clear_cache() as a more portable alternative

[Alejandro Colomar via Gcc-patches]

Reported-by: Heinrich Schuchardt 
Signed-off-by: Alejandro Colomar 
---
 man2/cacheflush.2 | 24 
 1 file changed, 24 insertions(+)

diff --git a/man2/cacheflush.2 b/man2/cacheflush.2
index aba625721..7a2eed506 100644
--- a/man2/cacheflush.2
+++ b/man2/cacheflush.2
@@ -86,6 +86,30 @@ On Linux, this call first appeared on the MIPS architecture,
 but nowadays, Linux provides a
 .BR cacheflush ()
 system call on some other architectures, but with different arguments.
+.SH NOTES
+Unless you need the finer grained control that this system call provides,
+you probably want to use the GCC built-in function
+.BR __builtin___clear_cache (),
+which provides a portable interface
+across platforms supported by GCC and compatible compilers:
+.PP
+.in +4n
+.EX
+.BI "void __builtin___clear_cache(void *" begin ", void *" end );
+.EE
+.in
+.PP
+On platforms that don't require instruction cache flushes,
+.BR __builtin___clear_cache ()
+has no effect.
+.PP
+.IR Note :
+Until GCC 9.1.0,
+the prototype for this built-in function used
+.I char *
+instead of
+.I void *
+for the parameters.
 .SH BUGS
 Linux kernels older than version 2.6.11 ignore the
 .I addr
-- 
2.29.2

[committed] .dir-locals.el: Set 'fill-column' to 80 for c-mode

[Andrea Corallo via Gcc-patches]

Hi all,

I've committed the attached patch as obvious.

This is to set `fill-column' to 80 in c-mode (Emacs default it to 70) so
now M-q does the right thing.  I think is very handy especially in
comments.

Question: should we update the copyright manually for this file or have
it updated by 'update-copyright.py'?  I think this is not scanning the
root of the repo.

Thanks

  Andrea

>From f60c1b3102791b98de7c1ce951bce335394682ca Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Fri, 11 Dec 2020 15:35:25 +0100
Subject: [PATCH] .dir-locals.el: Set 'fill-column' to 80 for c-mode

ChangeLog

2020-12-11  Andrea Corallo  

* .dir-locals.el (c-mode): Set 'fill-column' to 80 columns.
---
 .dir-locals.el | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/.dir-locals.el b/.dir-locals.el
index b748c8d085f..44a0db68241 100644
--- a/.dir-locals.el
+++ b/.dir-locals.el
@@ -14,11 +14,10 @@
 ;; You should have received a copy of the GNU General Public License
 ;; along with this program.  If not, see .
 
-(
- (tcl-mode . ((tcl-indent-level . 4)
+((tcl-mode . ((tcl-indent-level . 4)
  (tcl-continued-indent-level . 4)
  (indent-tabs-mode . t)))
  (nil . ((bug-reference-url-format . "http://gcc.gnu.org/PR%s;)))
  (c-mode . ((c-file-style . "GNU")
-   (indent-tabs-mode . t)))
-)
+   (indent-tabs-mode . t)
+   (fill-column . 80
-- 
2.17.1

Re: V3 [PATCH 1/2] Switch to a new section if the SECTION_RETAIN bit doesn't match

[Vaseeharan Vinayagamoorthy via Gcc-patches]

This patch fixes the section type conflict that I have been seeing. I have 
tested this patch using :
Build: x86_64
Host: x86_64
Target: aarch64-none-linux-gnu



On 08/12/2020, 12:52, "Gcc-patches on behalf of H.J. Lu via Gcc-patches" 
 wrote:

When definitions marked with used attribute and unmarked definitions are
placed in the section with the same name, switch to a new section if the
SECTION_RETAIN bit doesn't match.

gcc/

PR target/98146
* output.h (switch_to_section): Add a tree argument, default to
nullptr.
* varasm.c (get_section): If the SECTION_RETAIN bit doesn't match,
return and switch to a new section later.
(assemble_start_function): Pass decl to switch_to_section.
(assemble_variable): Likewise.
(switch_to_section): If the SECTION_RETAIN bit doesn't match,
switch to a new section.

gcc/testsuite/

PR target/98146
* c-c++-common/attr-used-5.c: New test.
* c-c++-common/attr-used-6.c: Likewise.
* c-c++-common/attr-used-7.c: Likewise.
* c-c++-common/attr-used-8.c: Likewise.
* c-c++-common/attr-used-9.c: Likewise.
---
 gcc/output.h |  2 +-
 gcc/testsuite/c-c++-common/attr-used-5.c | 26 
 gcc/testsuite/c-c++-common/attr-used-6.c | 26 
 gcc/testsuite/c-c++-common/attr-used-7.c |  8 +++
 gcc/testsuite/c-c++-common/attr-used-8.c |  8 +++
 gcc/testsuite/c-c++-common/attr-used-9.c | 28 ++
 gcc/varasm.c | 30 
 7 files changed, 123 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-5.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-6.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-7.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-8.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-9.c

diff --git a/gcc/output.h b/gcc/output.h
index fa8ace1f394..1f9af46da1d 100644
--- a/gcc/output.h
+++ b/gcc/output.h
@@ -548,7 +548,7 @@ extern void switch_to_other_text_partition (void);
 extern section *get_cdtor_priority_section (int, bool);

 extern bool unlikely_text_section_p (section *);
-extern void switch_to_section (section *);
+extern void switch_to_section (section *, tree = nullptr);
 extern void output_section_asm_op (const void *);

 extern void record_tm_clone_pair (tree, tree);
diff --git a/gcc/testsuite/c-c++-common/attr-used-5.c 
b/gcc/testsuite/c-c++-common/attr-used-5.c
new file mode 100644
index 000..9fc0d3834e9
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/attr-used-5.c
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-Wall -O2" } */
+
+struct dtv_slotinfo_list
+{
+  struct dtv_slotinfo_list *next;
+};
+
+extern struct dtv_slotinfo_list *list;
+
+static int __attribute__ ((section ("__libc_freeres_fn")))
+free_slotinfo (struct dtv_slotinfo_list **elemp)
+{
+  if (!free_slotinfo (&(*elemp)->next))
+return 0;
+  return 1;
+}
+
+__attribute__ ((used, section ("__libc_freeres_fn")))
+static void free_mem (void)
+{
+  free_slotinfo ();
+}
+
+/* { dg-final { scan-assembler "__libc_freeres_fn,\"ax\"" { target 
R_flag_in_section } } } */
+/* { dg-final { scan-assembler "__libc_freeres_fn,\"axR\"" { target 
R_flag_in_section } } } */
diff --git a/gcc/testsuite/c-c++-common/attr-used-6.c 
b/gcc/testsuite/c-c++-common/attr-used-6.c
new file mode 100644
index 000..0cb82ade5a9
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/attr-used-6.c
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-Wall -O2" } */
+
+struct dtv_slotinfo_list
+{
+  struct dtv_slotinfo_list *next;
+};
+
+extern struct dtv_slotinfo_list *list;
+
+static int __attribute__ ((used, section ("__libc_freeres_fn")))
+free_slotinfo (struct dtv_slotinfo_list **elemp)
+{
+  if (!free_slotinfo (&(*elemp)->next))
+return 0;
+  return 1;
+}
+
+__attribute__ ((section ("__libc_freeres_fn")))
+void free_mem (void)
+{
+  free_slotinfo ();
+}
+
+/* { dg-final { scan-assembler "__libc_freeres_fn,\"ax\"" { target 
R_flag_in_section } } } */
+/* { dg-final { scan-assembler "__libc_freeres_fn,\"axR\"" { target 
R_flag_in_section } } } */
diff --git a/gcc/testsuite/c-c++-common/attr-used-7.c 
b/gcc/testsuite/c-c++-common/attr-used-7.c
new file mode 100644
index 000..fba2706ffc1
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/attr-used-7.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-Wall -O2" } */
+
+int __attribute__((used,section(".data.foo"))) 

RE: [PATCH]AArch64: Add NEON, SVE and SVE2 RTL patterns for Complex Addition, Multiply and FMA.

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Tamar Christina 
> Sent: 10 December 2020 17:00
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Kyrylo Tkachov
> ; Richard Sandiford
> 
> Subject: [PATCH]AArch64: Add NEON, SVE and SVE2 RTL patterns for
> Complex Addition, Multiply and FMA.
> 
> Hi All,
> 
> This adds implementation for the optabs for complex operations.  With this
> the
> following C code:
> 
>   void f90 (float complex a[restrict N], float complex b[restrict N],
>   float complex c[restrict N])
>   {
> for (int i=0; i < N; i++)
>   c[i] = a[i] + (b[i] * I);
>   }
> 
> generates
> 
>   f90:
> mov x3, 0
> .p2align 3,,7
>   .L2:
> ldr q0, [x0, x3]
> ldr q1, [x1, x3]
> fcadd   v0.4s, v0.4s, v1.4s, #90
> str q0, [x2, x3]
> add x3, x3, 16
> cmp x3, 1600
> bne .L2
> ret
> 
> instead of
> 
>   f90:
> add x3, x1, 1600
> .p2align 3,,7
>   .L2:
> ld2 {v4.4s - v5.4s}, [x0], 32
> ld2 {v2.4s - v3.4s}, [x1], 32
> fsubv0.4s, v4.4s, v3.4s
> faddv1.4s, v5.4s, v2.4s
> st2 {v0.4s - v1.4s}, [x2], 32
> cmp x3, x1
> bne .L2
> ret
> 
> It defined a new iterator VALL_ARITH which contains types for which we can
> do
> general arithmetic (excludes bfloat16).
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> Checked with armv8-a+sve2+fp16 and no issues.  Note that sue to a mid-end
> limitation SLP for SVE currently fails for some permutes.  The tests have
> these
> marked as XFAIL.  I do intend to fix this soon.
> 
> Matching tests for these are in the mid-end patches.
> Note that The mid-end patches are still being respun and I may need to
> change the order of some parameters but no other change is expected and
> would like to decrease the size of future patches.  As such..
> 
> Ok for master?

Ok. The patterns look clean to me from a back-end perspective.
Thanks,
Kyrill

> 
> Thanks,
> Tamar
> 
> 
> gcc/ChangeLog:
> 
>   * config/aarch64/aarch64-simd.md (cadd3,
>   cml4, cmul3): New.
>   * config/aarch64/iterators.md (VALL_ARITH, UNSPEC_FCMUL,
>   UNSPEC_FCMUL180, UNSPEC_FCMLS, UNSPEC_FCMLS180,
> UNSPEC_CMLS,
>   UNSPEC_CMLS180, UNSPEC_CMUL, UNSPEC_CMUL180, FCMLA_OP,
> FCMUL_OP, rot_op,
>   rotsplit1, rotsplit2, fcmac1, sve_rot1, sve_rot2, SVE2_INT_CMLA_OP,
>   SVE2_INT_CMUL_OP, SVE2_INT_CADD_OP): New.): New.): New.
>   (rot): Add UNSPEC_FCMLS, UNSPEC_FCMUL, UNSPEC_FCMUL180.
>   * config/aarch64/aarch64-sve.md (cadd3,
>   cml4, cmul3): New.
>   * config/aarch64/aarch64-sve2.md (cadd3,
>   cml4, cmul3): New.
> 
> --

Re: [PATCH, v2, OpenMP 5.0, libgomp] Structure element mapping for OpenMP 5.0

[Chung-Lin Tang]

Ping.

On 2020/12/4 10:15 PM, Chung-Lin Tang wrote:

Hi Jakub,
this is a new version of the structure element mapping patch for OpenMP 5.0 
requirement
changes.

This one uses the approach you've outlined in your concept patch [1], basically 
to
use more special REFCOUNT_* values to mark them, and link following structure 
element
splay_tree_keys back to the first key's refcount.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557622.html

Implementation notes of the attached patch:

(1) This patch solves the 5.0 requirements of "not already 
incremented/decremented
because of the effect of a map clause on the construct" by pulling in 
libgomp/hashtab.h
and using htab_t as a pointer set. A "htab_t *refcount_set" is added in 
map/unmap
routines to track the processing status of the uintptr_t* addresses of refcount
fields in splay_tree_keys.

    * Currently this patch is using the same htab_create/htab_free routines 
like in task.c.
  I toyed with creating a 'htab_alloca' macro (allocating a fixed size 
htab) to speed
  things further, but decided to play it safer for the current patch.

(2) Because of the use of pointer-to-refcounts as the basis, and structure 
element
siblings all share a same refcount, uniform increment/decrement without 
repeating is
also naturally achieved.

(3) Because of the need to remove whole structure element sibling sequences out 
of
context, it appears we need to mark the first/last of such a sequence. You'll 
see that
the special REFCOUNT_* values have been expanded a bit more than your concept 
patch
(at some point we should think about stop abusing it and add a proper flags 
word)

(4) The new increment/decrement routines combine most of the new refcount_set 
lookup
code with the refcount adjusting. For the decrement routine, "copy" and 
"removal" are
now separate return values, since for structure element sequences, even when 
signalling
"removal" you may still need to finish the "copy" work of following 
target_var_descs.

(5) There are some re-organizing changes to oacc-parallel.c and oacc-mem.c, but 
most
of the code that matters is in target.c.

(6) New testcases have been added to reflect the cases discussed on omp-lang 
list.

This patch has been tested for libgomp with no regressions on x86_64-linux with
nvptx offloading. Since I submitted the first "v1" patch long ago, is this okay 
to be
considered as committable now after approval?

Thanks,
Chung-Lin

2020-12-04  Chung-Lin Tang  

 libgomp/
 * hashtab.h (htab_clear): New function with initialization code
 factored out from...
 (htab_create): ...here, adjust to use htab_clear function.

 * libgomp.h (REFCOUNT_SPECIAL): New symbol to denote range of
 special refcount values, add comments.
 (REFCOUNT_INFINITY): Adjust definition to use REFCOUNT_SPECIAL.
 (REFCOUNT_LINK): Likewise.
 (REFCOUNT_STRUCTELEM): New special refcount range for structure
 element siblings.
 (REFCOUNT_STRUCTELEM_P): Macro for testing for structure element
 sibling maps.
 (REFCOUNT_STRUCTELEM_FLAG_FIRST): Flag to indicate first sibling.
 (REFCOUNT_STRUCTELEM_FLAG_LAST):  Flag to indicate last sibling.
 (REFCOUNT_STRUCTELEM_FIRST_P): Macro to test _FIRST flag.
 (REFCOUNT_STRUCTELEM_LAST_P): Macro to test _LAST flag.
 (struct splay_tree_key_s): Add structelem_refcount and
 structelem_refcount_ptr fields into a union with dynamic_refcount.
 Add comments.
 (gomp_map_vars): Delete declaration.
 (gomp_map_vars_async): Likewise.
 (gomp_unmap_vars): Likewise.
 (gomp_unmap_vars_async): Likewise.
 (goacc_map_vars): New declaration.
 (goacc_unmap_vars): Likewise.

 * oacc-mem.c (acc_map_data): Adjust to use goacc_map_vars.
 (goacc_enter_datum): Likewise.
 (goacc_enter_data_internal): Likewise.
 * oacc-parallel.c (GOACC_parallel_keyed): Adjust to use goacc_map_vars
 and goacc_unmap_vars.
 (GOACC_data_start): Adjust to use goacc_map_vars.
 (GOACC_data_end): Adjust to use goacc_unmap_vars.

 * target.c (hash_entry_type): New typedef.
 (htab_alloc): New function hook for hashtab.h.
 (htab_free): Likewise.
 (htab_hash): Likewise.
 (htab_eq): Likewise.
 (hashtab.h): Add file include.
 (gomp_increment_refcount): New function.
 (gomp_decrement_refcount): Likewise.
 (gomp_map_vars_existing): Add refcount_set parameter, adjust to use
 gomp_increment_refcount.
 (gomp_map_fields_existing): Add refcount_set parameter, adjust calls
 to gomp_map_vars_existing.

 (gomp_map_vars_internal): Add refcount_set parameter, add local openmp_p
 variable to guard OpenMP specific paths, adjust calls to
 gomp_map_vars_existing, add structure element sibling splay_tree_key
 sequence creation code, adjust Fortran map case to avoid increment
 under OpenMP.
 (gomp_map_vars): Adjust to static, add refcount_set parameter, manage
 local refcount_set if caller passed in