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

2022-05-10 Thread Yonghong Song via Gcc-patches




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



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



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



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



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

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


Consider the following example:

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

 int __typetag1 * __typetag2 __typetag3 * g;

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


That's not a correct expectation for either GNU __attribute__ or 
C2x [[]]

attribute syntax.  In either syntax, __typetag2 __typetag3 should
apply to
the type to which g points, not to g or its type, just as if you had a
type qualifier there.  You'd need to put the attributes (or qualifier)
after the *, not before, to make them apply to the pointer type.  See
"Attribute Syntax" in the GCC manual for how the syntax is defined for
GNU
attributes and deduce in turn, for each subsequence of the tokens
matching
the syntax for some kind of declarator, what the type for "T D1" 
would be

as defined there and in the C standard, as deduced from the type for
"T D"
for a sub-declarator D.
  >> But GCC's attribute parsing produces a variable 'g' which is "a

pointer with

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


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

If you are concerned with the fine details of what construct an 
attribute

appertains to, I recommend using C2x syntax not GNU syntax.



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

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


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


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

$ cat t.c
int const *ptr;

the llvm ir debuginfo:

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

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

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

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

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

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


OK, thanks.

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


   int __typetag1 * __typetag2 __typetag3 * g;

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


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


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



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


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


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


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


Okay, I think we can 

[PATCH v2] libstdc++: fix pointer type exception catch [PR105387]

2022-05-10 Thread Jakob Hasse via Gcc-patches
Hi Jonathan,

Thanks for fixing the tests and the guidance regarding the patch! I rebased the 
patch on top of that commit (b6b66006787b0991e94f15c7b5c56403f1eb85fb) and 
fixed all issues (I believe) which you pointed out. I also added the original 
reproducer to the test case as you suggested.

I configured as before with
../configure -prefix=/usr --enable-languages=c,c++ --enable-multiarch 
--host=x86_64-linux-gnu --build=x86_64-linux-gnu --target=x86_64-linux-gnu 
--enable-cxx-flags=-fno-rtti
and an additional configuration with -frtti instead to check nothing else 
breaks.

Now the test results look much clearer:

Without RTTI before applying patch:
=== libstdc++ Summary ===

# of expected passes 14560
# of unexpected failures 5
# of expected failures 95
# of unsupported tests 702

Without RTTI after applying patch:
=== libstdc++ Summary ===

# of expected passes 14562
# of unexpected failures 5
# of expected failures 95
# of unsupported tests 702

With RTTI before applying patch:
=== libstdc++ Summary ===

# of expected passes 14598
# of unexpected failures 2
# of expected failures 95
# of unsupported tests 683

With RTTI after applying patch:
=== libstdc++ Summary ===

# of expected passes 14600
# of unexpected failures 2
# of expected failures 95
# of unsupported tests 683

That looks logical to me.
I think ideally a test for the pointer-to-member case should also be added...
From c9271f834d6e01cc269412a02cdb0d9d26dcdb1c Mon Sep 17 00:00:00 2001
From: Jakob Hasse <0xja...@users.noreply.github.com>
Date: Tue, 26 Apr 2022 12:03:47 +0800
Subject: [PATCH] [PATCH] libstdc++: fix pointer type exception catch (no RTTI)
 [PR105387]

PR libstdc++/105387

__pbase_type_info::__do_catch(), used to catch pointer type exceptions,
did not check if the type info object to compare against is a pointer
type info object before doing a static down-cast to a pointer type info
object. If RTTI is disabled, this leads to the following situation:
Since a pointer type info object has additional fields, they would
end up being undefined if the actual type info object was not a pointer
type info object.

A simple check has been added before the down-cast happens.

Note that a consequence of this check is that exceptions of type
pointer-to-member cannot be caught anymore.

In case RTTI is enabled, this does not seem to be a problem because
RTTI-based checks would run before and prevent running into the bad
down-cast. Hence, the fix is disabled if RTTI is enabled and exceptions
of type pointer-to-member can still be caught.

libstdc++-v3/ChangeLog:

	* libsupc++/pbase_type_info.cc (__do_catch):
	* testsuite/18_support/105387.cc: New test.

Signed-off-by: Jakob Hasse 
---
 libstdc++-v3/libsupc++/pbase_type_info.cc   |  7 ++-
 libstdc++-v3/testsuite/18_support/105387.cc | 61 +
 2 files changed, 67 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/testsuite/18_support/105387.cc

diff --git a/libstdc++-v3/libsupc++/pbase_type_info.cc b/libstdc++-v3/libsupc++/pbase_type_info.cc
index 7e5720b84a3..934e049a4e0 100644
--- a/libstdc++-v3/libsupc++/pbase_type_info.cc
+++ b/libstdc++-v3/libsupc++/pbase_type_info.cc
@@ -74,7 +74,12 @@ __do_catch (const type_info *thr_type,
 // Therefore there must at least be a qualification conversion involved
 // But for that to be valid, our outer pointers must be const qualified.
 return false;
-  
+
+#if !__cpp_rtti
+  if (!thr_type->__is_pointer_p ())
+return false;
+#endif
+
   const __pbase_type_info *thrown_type =
 static_cast  (thr_type);
 
diff --git a/libstdc++-v3/testsuite/18_support/105387.cc b/libstdc++-v3/testsuite/18_support/105387.cc
new file mode 100644
index 000..5cec222c334
--- /dev/null
+++ b/libstdc++-v3/testsuite/18_support/105387.cc
@@ -0,0 +1,61 @@
+#include 
+#include 
+#include 
+
+// Test cases for PR libstdc++/105387
+
+// This test is to trigger undefined behavior if the bug 105387 is present
+// in the code. Note, however, given that the bug is present, this test runs
+// into undefined behavior which can also mean that it passes.
+// It has been observed to fail quite reliably on x86_64-linux-gnu but only
+// fail sporadically on Xtensa, depending on the code placement.
+void portable_test()
+{
+  bool exception_thrown = false;
+  try {
+throw std::runtime_error("test");
+  } catch (const char *e) {
+VERIFY(false);
+  } catch (const std::exception ) {
+exception_thrown = true;
+  }
+  VERIFY(exception_thrown);
+}
+
+// This test relies on the types defined in the files typeinfo and cxxabi.h
+// It is therefore less portable then the test case above but should be
+// guaranteed to fail if the implementation has the bug 105387.
+//
+// This test case checks that __pbase_type_info::__do_catch() behaves
+// correctly when called with a non-pointer type info object as argument.
+// In particular, __pbase_type_info::__do_catch() should not cast
+// the given type object into a pointer type and try to access 

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

2022-05-10 Thread Yonghong Song via Gcc-patches




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



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



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



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

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


Consider the following example:

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

 int __typetag1 * __typetag2 __typetag3 * g;

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


That's not a correct expectation for either GNU __attribute__ or C2x 
[[]]

attribute syntax.  In either syntax, __typetag2 __typetag3 should
apply to
the type to which g points, not to g or its type, just as if you had a
type qualifier there.  You'd need to put the attributes (or qualifier)
after the *, not before, to make them apply to the pointer type.  See
"Attribute Syntax" in the GCC manual for how the syntax is defined for
GNU
attributes and deduce in turn, for each subsequence of the tokens
matching
the syntax for some kind of declarator, what the type for "T D1" 
would be

as defined there and in the C standard, as deduced from the type for
"T D"
for a sub-declarator D.
  >> But GCC's attribute parsing produces a variable 'g' which is "a

pointer with

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


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

If you are concerned with the fine details of what construct an 
attribute

appertains to, I recommend using C2x syntax not GNU syntax.



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

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


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


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

$ cat t.c
int const *ptr;

the llvm ir debuginfo:

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

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

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

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

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

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


OK, thanks.

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


   int __typetag1 * __typetag2 __typetag3 * g;

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


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


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



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


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


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


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







This example comes from my testing against clang to check 

Re: [PATCH] [i386] Optimize movzwl + vmovd/vmovq to vmovw.

2022-05-10 Thread Hongtao Liu via Gcc-patches
On Mon, May 9, 2022 at 4:28 PM Uros Bizjak  wrote:
>
> On Mon, May 9, 2022 at 4:03 AM liuhongt  wrote:
> >
> > Similarly optimize movl + vmovq to vmovd.
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > Ok for trunk?
> >
> > gcc/ChangeLog:
> >
> > PR target/104915
> > * config/i386/sse.md (*vec_set_0_zero_extendhi): New
> > pre_reload define_insn_and_split.
> > (*vec_setv2di_0_zero_extendhi_1): Ditto.
> > (*vec_set_0_zero_extendsi): Ditto.
> > (*vec_setv2di_0_zero_extendsi_1): Ditto.
> > (ssewvecmode): New mode attr.
> > (ssewvecmodelower): Ditto.
> > (ssepackmodelower): Ditto.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/i386/pr104915-vmovd.c: New test.
> > * gcc.target/i386/pr104915-vmovw.c: New test.
>
> I wonder if these define_insn_and_splits can instead be implemented
> via combine splitter (which has the unfortunate limitation that the
> output sequence has to be exactly two instructions, which is true in
> your case). Combine splitter is preferred, since it splits immediately
> and the resulting insns can be combined further during the combine
> pass.

try_combine requires at least 3 insns to go into combine_split_insns,
here we just have 2 insns and failed.

-cut from combine.cc
3545  /* If we were combining three insns and the result is a simple SET
 3546 with no ASM_OPERANDS that wasn't recognized, try to split it into two
 3547 insns.  There are two ways to do this.  It can be split using a
 3548 machine-specific method (like when you have an addition of a large
 3549 constant) or by combine in the function find_split_point.  */
 3550
 3551=>if (i1 && insn_code_number < 0 && GET_CODE (newpat) == SET
 3552  && asm_noperands (newpat) < 0)
---cut end-

>
> Uros.
>
> > ---
> >  gcc/config/i386/sse.md| 94 +++
> >  .../gcc.target/i386/pr104915-vmovd.c  | 25 +
> >  .../gcc.target/i386/pr104915-vmovw.c  | 45 +
> >  3 files changed, 164 insertions(+)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr104915-vmovd.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr104915-vmovw.c
> >
> > diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> > index 7b791def542..2ad8a2b46b8 100644
> > --- a/gcc/config/i386/sse.md
> > +++ b/gcc/config/i386/sse.md
> > @@ -985,6 +985,15 @@ (define_mode_attr sseintvecmode
> > (V32HI "V32HI") (V64QI "V64QI")
> > (V32QI "V32QI") (V16QI "V16QI")])
> >
> > +;; Mapping of vector modes to an V*HImode of the same size
> > +(define_mode_attr ssewvecmode
> > +  [(V8DI "V32HI") (V4DI "V16HI") (V2DI "V8HI")
> > +   (V16SI "V32HI") (V8SI "V16HI") (V4SI "V8HI")])
> > +
> > +(define_mode_attr ssewvecmodelower
> > +  [(V8DI "v32hi") (V4DI "v16hi") (V2DI "v8hi")
> > +   (V16SI "v32hi") (V8SI "v16hi") (V4SI "v8hi")])
> > +
> >  (define_mode_attr sseintvecmode2
> >[(V8DF "XI") (V4DF "OI") (V2DF "TI")
> > (V8SF "OI") (V4SF "TI")
> > @@ -1194,6 +1203,11 @@ (define_mode_attr ssepackmode
> > (V16HI "V32QI") (V8SI "V16HI") (V4DI "V8SI")
> > (V32HI "V64QI") (V16SI "V32HI") (V8DI "V16SI")])
> >
> > +(define_mode_attr ssepackmodelower
> > +  [(V8HI "v16qi") (V4SI "v8hi") (V2DI "v4si")
> > +   (V16HI "v32qi") (V8SI "v16hi") (V4DI "v8si")
> > +   (V32HI "v64qi") (V16SI "v32hi") (V8DI "v16si")])
> > +
> >  ;; Mapping of the max integer size for xop rotate immediate constraint
> >  (define_mode_attr sserotatemax
> >[(V16QI "7") (V8HI "15") (V4SI "31") (V2DI "63")])
> > @@ -10681,6 +10695,46 @@ (define_insn "vec_set_0"
> > (set_attr "prefix" "evex")
> > (set_attr "mode" "HF")])
> >
> > +(define_insn_and_split "*vec_set_0_zero_extendhi"
> > +  [(set (match_operand:VI48_AVX512F 0 "register_operand")
> > +   (vec_merge:VI48_AVX512F
> > +(vec_duplicate:VI48_AVX512F
> > + (zero_extend:
> > +   (match_operand:HI 1 "nonimmediate_operand")))
> > +(match_operand:VI48_AVX512F 2 "const0_operand")
> > +(const_int 1)))]
> > +  "TARGET_AVX512FP16 && ix86_pre_reload_split ()"
> > +  "#"
> > +  "&& 1"
> > +  [(const_int 0)]
> > +{
> > +  rtx dest = gen_reg_rtx (mode);
> > +  emit_insn (gen_vec_set_0 (dest,
> > + CONST0_RTX 
> > (mode),
> > + operands[1]));
> > +  emit_move_insn (operands[0],
> > + lowpart_subreg (mode, dest, mode));
> > +  DONE;
> > +})
> > +
> > +(define_insn_and_split "*vec_setv2di_0_zero_extendhi_1"
> > +  [(set (match_operand:V2DI 0 "register_operand")
> > +   (vec_concat:V2DI
> > + (zero_extend:DI
> > +   (match_operand:HI 1 "nonimmediate_operand"))
> > + (const_int 0)))]
> > +  "TARGET_AVX512FP16 && ix86_pre_reload_split ()"
> > +  "#"
> > +  "&& 1"
> > +  [(const_int 0)]
> > +{
> > +  rtx dest = gen_reg_rtx (V8HImode);
> > +  emit_insn 

[PATCH] middle-end/70090: Register __bdos for sanitizers if necessary

2022-05-10 Thread Siddhesh Poyarekar
The asan initializer registers __builtin_object_size for languages that
don't have it, e.g. Fortran.  Register __builtin_dynamic_object_size too
(we need both because __builtin_dynamic_object_size computation may
involve generating __builtin_object_size as a fallback) so that
gfortran.dg/ubsan/bind-c-intent-out-2.f90 does not crash anymore.

gcc/ChangeLog:

PR middle-end/70090
* asan.cc (initialize_sanitizer_builtins): Register
__builtin_dynamic_object_size if necessary.

Signed-off-by: Siddhesh Poyarekar 
---
Testing:
- I realized that for some reason I was looking only at gcc.log in the
  testsuite, so expanded my checks to look at failures in the entire check
  output.  Verified that gfortran.dg/ubsan/bind-c-intent-out-2.f90 failed on
  master and passed with this patch.
- Bootstrapped and tested on x86_64
- Bootstrapped --with-build-config=bootstrap-ubsan
- i686 build and test

 gcc/asan.cc | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/gcc/asan.cc b/gcc/asan.cc
index ef59b77ebc2..4b583e54efd 100644
--- a/gcc/asan.cc
+++ b/gcc/asan.cc
@@ -3457,14 +3457,22 @@ initialize_sanitizer_builtins (void)
 
 #include "sanitizer.def"
 
-  /* -fsanitize=object-size uses __builtin_object_size, but that might
- not be available for e.g. Fortran at this point.  We use
- DEF_SANITIZER_BUILTIN here only as a convenience macro.  */
-  if ((flag_sanitize & SANITIZE_OBJECT_SIZE)
-  && !builtin_decl_implicit_p (BUILT_IN_OBJECT_SIZE))
-DEF_SANITIZER_BUILTIN_1 (BUILT_IN_OBJECT_SIZE, "object_size",
-BT_FN_SIZE_CONST_PTR_INT,
-ATTR_PURE_NOTHROW_LEAF_LIST);
+  /* -fsanitize=object-size uses __builtin_dynamic_object_size and
+ __builtin_object_size, but they might not be available for e.g. Fortran at
+ this point.  We use DEF_SANITIZER_BUILTIN here only as a convenience
+ macro.  */
+  if (flag_sanitize & SANITIZE_OBJECT_SIZE)
+{
+  if (!builtin_decl_implicit_p (BUILT_IN_OBJECT_SIZE))
+   DEF_SANITIZER_BUILTIN_1 (BUILT_IN_OBJECT_SIZE, "object_size",
+BT_FN_SIZE_CONST_PTR_INT,
+ATTR_PURE_NOTHROW_LEAF_LIST);
+  if (!builtin_decl_implicit_p (BUILT_IN_DYNAMIC_OBJECT_SIZE))
+   DEF_SANITIZER_BUILTIN_1 (BUILT_IN_DYNAMIC_OBJECT_SIZE,
+"dynamic_object_size",
+BT_FN_SIZE_CONST_PTR_INT,
+ATTR_PURE_NOTHROW_LEAF_LIST);
+}
 
 #undef DEF_SANITIZER_BUILTIN_1
 #undef DEF_SANITIZER_BUILTIN
-- 
2.35.1



Re: [wwwdocs] gcc-12/changes.html: Document the RISC-V libstdc++ -latomic detection

2022-05-10 Thread Kito Cheng via Gcc-patches
LGTM, I think document what we really did in GCC 12 is never too late :P



On Fri, Apr 29, 2022 at 2:23 AM Palmer Dabbelt  wrote:
>
> ---
> IMO this one is worth documenting too, not sure if it's too late for
> gcc-12's docs (due to those branch commits) so I haven't committed it
> yet to avoid any fallout.
> ---
>  htdocs/gcc-12/changes.html | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> index e9f132c0..e8a9cea2 100644
> --- a/htdocs/gcc-12/changes.html
> +++ b/htdocs/gcc-12/changes.html
> @@ -746,6 +746,9 @@ function Multiply (S1, S2 : Sign) return Sign is
> support architecture testing marco and -march= 
> parsing.
>  The option -mtune=thead-c906 is added to tune for T-HEAD
> c906 cores.
> +libstdc++'s no longer attempts to detect built-in atomics,
> +   distributions that have out-of-tree workarounds for
> +   -latomic should check their ABIs again.
>
>  
>
> --
> 2.34.1
>


Re: [PATCH] testsuite: btf: Fix btf-datasec-1.c for RISC-V

2022-05-10 Thread Kito Cheng via Gcc-patches
LGTM, that's only added a new option for RISC-V and won't affect all
other targets, so I assume I can approve that.

On Wed, May 4, 2022 at 8:27 AM Palmer Dabbelt  wrote:
>
> Similar to 37e65643d3e ("testsuite/101269: fix testcase when used with
> -m32"), RISC-V needs to be told not to put symbols in the
> sdata/srodata/sbss sections.
>
> gcc/testsuite/ChangeLog
>
> * debug/btf/btf-datasec-1.c: Don't use small data on RISC-V.
> ---
>  gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c 
> b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
> index dbb236bbda1..77df88648c5 100644
> --- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
> +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
> @@ -12,6 +12,7 @@
>  /* { dg-do compile )  */
>  /* { dg-options "-O0 -gbtf -dA" } */
>  /* { dg-options "-O0 -gbtf -dA -msdata=none" { target { { powerpc*-*-* } && 
> ilp32 } } } */
> +/* { dg-options "-O0 -gbtf -dA -msmall-data-limit=0" { target { riscv*-*-* } 
> } } */
>  /* { dg-options "-O0 -gbtf -dA -G0" { target { nios2-*-* } } } */
>
>  /* Check for two DATASEC entries with vlen 3, and one with vlen 1.  */
> --
> 2.34.1
>


Supporting RISC-V Vendor Extensions in the GNU Toolchain

2022-05-10 Thread Palmer Dabbelt
[Sorry for cross-posting to a bunch of lists, I figured it'd be best to 
have all the discussions in one thread.]


We currently only support what is defined by official RISC-V 
specifications in the various GNU toolchain projects.  There's certainly 
some grey areas there, but in general that means not taking code that 
relies on drafts or vendor defined extensions, even if that would result 
in higher performance or more featured systems for users.


The original goal of these policies were to steer RISC-V implementers 
towards a common set of specifications, but over the last year or so 
it's become abundantly clear that this is causing more harm that good.  
All extant RISC-V systems rely on behaviors defined outside the official 
specifications, and while that's technically always been the case we've 
gotten to the point where trying to ignore that fact is impacting real 
users on real systems.  There's been consistent feedback from users that 
we're not meeting their needs, which can clearly be seen in the many out 
of tree patch sets in common use.


There's been a handful of discussions about this, but we've yet to have 
a proper discussion on the mailing lists.  From the various discussions 
I've had it seems that folks are broadly in favor of supporting vendor 
extensions, but the devil's always in the details with this sort of 
thing so I thought it'd be best to write something up so we can have a 
concrete discussion.


The idea is to start taking code that depends on vendor-defined behavior 
into the core GNU toolchain ports, as long as it meets the following 
criteria:


* An ISA manual is available that can be redistributed/archived, defines 
 the behaviors in question as one or more vendor-specific extensions, 
 and is clearly versioned.  The RISC-V foundation is setting various 
 guidelines around how vendor-defined extensions and instructions 
 should be named, we strongly suggest that vendors follow those 
 conventions whenever possible (this is all new, though, so exactly 
 what's necessary from vendor specifications will likely evolve as we 
 learn).
* There is a substantial user base that depends on the behavior in 
 question, which probably means there is hardware in the wild that 
 implements the extensions and users that require those extensions in 
 order for that hardware to be useful for common applications.  This is 
 always going to be a grey area, but it's essentially the same spot 
 everyone else is in.
* There is a mechanism for testing the code in question without direct 
 access to hardware, which in practice means a QEMU port (or whatever 
 simulator is relevant in the space and that folks use for testing) or 
 some community commitment to long-term availability of the hardware 
 for testing (something like the GCC compile farm, for example).
* It is possible to produce binaries that are compatible with all 
 upstream vendors' implementations.  That means we'll need mechanisms 
 to allow extensions from multiple vendors to be linked together and 
 then probed at runtime.  That's not to say that all binaries will be 
 compatible, as users are always free to skip the compatibility code 
 and there will be conflicting definitions of instruction encodings, 
 but we can at least provide users with the option of compatibility.


These are pretty loosely written on purpose, both because this is all 
new and because each project has its own set of contribution 
requirements so it's going to be all but impossible to have a single 
concrete set of rules that applies everywhere -- that's nothing specific 
to the vendor extensions (or even RISC-V), it's just life.  Specifically 
a major goal here is to balance the needs of users, both in the short 
term (ie, getting new hardware to work) and the long term (ie, the long 
term stability of their software).  We're not talking about taking code 
that can't be tested, hasn't been reviewed, isn't going to be supported 
long-term, or doesn't have a stable ABI; just dropping the specific 
requirement that a specification must be furnished by the RISC-V 
foundation in order to accept code.


Nothing is decided yet, so happy to hear any thought folks have.  This 
is certainly a very different development methodology than what we've 
done in the past and isn't something that should be entreated into 
lightly, so any comments are welcome.


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

2022-05-10 Thread Marek Polacek via Gcc-patches
On Tue, May 10, 2022 at 02:58:49PM -0700, Palmer Dabbelt wrote:
> On Thu, 05 May 2022 11:45:50 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> > On Thu, May 05, 2022 at 06:33:20PM +0800, jiawei wrote:
> > > Some compiler target like arm-linux\riscv\power\s390x\xtensa-gcc handle
> > > char as unsigned char, then there are no warnings occur and got FAIL 
> > > cases.
> > > Just change the type char into explicit signed char to keep the feature
> > > consistency.
> > > 
> > > gcc/testsuite/ChangeLog:
> > > 
> > > * c-c++-common/Wconversion-1.c: Update type.
> > 
> > Ok, and sorry for introducing this problem!
> 
> So this is OK for trunk?  Happy to commit it if you'd like, just wanted to
> make sure as I'm not seeing it on trunk.

Yes, please go ahead.
 
Marek



Re: [PATCH V2] powerpc: properly check for feenableexcept() on FreeBSD

2022-05-10 Thread Piotr Kubaj via Gcc-patches
Is there anything more required?

On 22-05-03 12:33:43, Piotr Kubaj wrote:
> Here are gmake check-gfortran results requested by FX.
> 
> Before patching:
> === gfortran Summary ===
> 
> # of expected passes65106
> # of unexpected failures6
> # of expected failures  262
> # of unsupported tests  367
> 
> After patching:
> === gfortran Summary ===
> 
> # of expected passes65384
> # of unexpected failures6
> # of expected failures  262
> # of unsupported tests  373
> 
> In both cases, unexpected failures are:
> FAIL: gfortran.dg/pr98076.f90   -O0  execution test
> FAIL: gfortran.dg/pr98076.f90   -O1  execution test
> FAIL: gfortran.dg/pr98076.f90   -O2  execution test
> FAIL: gfortran.dg/pr98076.f90   -O3 -fomit-frame-pointer -funroll-loops 
> -fpeel-loops -ftracer -finline-functions  execution test
> FAIL: gfortran.dg/pr98076.f90   -O3 -g  execution test
> FAIL: gfortran.dg/pr98076.f90   -Os  execution test
> 
> But this seems unrelated to my patch.
> 
> On 22-05-03 12:21:12, pku...@freebsd.org wrote:
> > From: Piotr Kubaj 
> > 
> > FreeBSD/powerpc* has feenableexcept() defined in fenv.h header.
> > 
> > Signed-off-by: Piotr Kubaj 
> > ---
> >  libgfortran/configure| 41 +++-
> >  libgfortran/configure.ac | 17 -
> >  2 files changed, 56 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libgfortran/configure b/libgfortran/configure
> > index ae64dca3114..ad71694ef05 100755
> > --- a/libgfortran/configure
> > +++ b/libgfortran/configure
> > @@ -27338,8 +27338,45 @@ fi
> >  
> >  
> >  
> > +case x$target in
> > +  xpowerpc*-freebsd*)
> > +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for fenv.h and 
> > feenableexcept" >&5
> > +$as_echo_n "checking for fenv.h and feenableexcept... " >&6; }
> > +if ${have_feenableexcept+:} false; then :
> > +  $as_echo_n "(cached) " >&6
> > +else
> > +
> > +cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> > +/* end confdefs.h.  */
> > + #include 
> > +int
> > +main ()
> > +{
> > + feenableexcept(FE_DIVBYZERO | FE_INVALID);
> > +  ;
> > +  return 0;
> > +}
> > +_ACEOF
> > +if ac_fn_c_try_compile "$LINENO"; then :
> > +   have_feenableexcept="yes"
> > +else
> > +   have_feenableexcept="no"
> > +fi
> > +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> > +fi
> > +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $have_feenableexcept" >&5
> > +$as_echo "$have_feenableexcept" >&6; }
> > +if test "x$have_feenableexcept" = "xyes"; then
> > +
> > +cat >>confdefs.h <<_ACEOF
> > +#define HAVE_FEENABLEEXCEPT 1
> > +_ACEOF
> > +
> > +fi;
> > +;;
> > +  *)
> >  # Check for GNU libc feenableexcept
> > -{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for feenableexcept in 
> > -lm" >&5
> > +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for feenableexcept 
> > in -lm" >&5
> >  $as_echo_n "checking for feenableexcept in -lm... " >&6; }
> >  if ${ac_cv_lib_m_feenableexcept+:} false; then :
> >$as_echo_n "(cached) " >&6
> > @@ -27384,6 +27421,8 @@ $as_echo "#define HAVE_FEENABLEEXCEPT 1" 
> > >>confdefs.h
> >  
> >  fi
> >  
> > +;;
> > +esac
> >  
> >  # At least for glibc, clock_gettime is in librt.  But don't
> >  # pull that in if it still doesn't give us the function we want.  This
> > diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
> > index 97cc490cb5e..2dd6d345b22 100644
> > --- a/libgfortran/configure.ac
> > +++ b/libgfortran/configure.ac
> > @@ -602,8 +602,23 @@ fi
> >  # Check whether we have a __float128 type, depends on 
> > enable_libquadmath_support
> >  LIBGFOR_CHECK_FLOAT128
> >  
> > +case x$target in
> > +  xpowerpc*-freebsd*)
> > +AC_CACHE_CHECK([for fenv.h and feenableexcept], have_feenableexcept, [
> > +  AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
> > +[[ #include   ]],
> > +[[ feenableexcept(FE_DIVBYZERO | FE_INVALID); ]])],
> > +[ have_feenableexcept="yes" ],
> > +[ have_feenableexcept="no"  ])])
> > +if test "x$have_feenableexcept" = "xyes"; then
> > +  AC_DEFINE(HAVE_FEENABLEEXCEPT,1,[fenv.h includes feenableexcept])
> > +fi;
> > +;;
> > +  *)
> >  # Check for GNU libc feenableexcept
> > -AC_CHECK_LIB([m],[feenableexcept],[have_feenableexcept=yes 
> > AC_DEFINE([HAVE_FEENABLEEXCEPT],[1],[libm includes feenableexcept])])
> > +AC_CHECK_LIB([m],[feenableexcept],[have_feenableexcept=yes 
> > AC_DEFINE([HAVE_FEENABLEEXCEPT],[1],[libm includes feenableexcept])])
> > +;;
> > +esac
> >  
> >  # At least for glibc, clock_gettime is in librt.  But don't
> >  # pull that in if it still doesn't give us the function we want.  This
> > -- 
> > 2.36.0
> > 




signature.asc
Description: PGP signature


Re: rs6000: Prefer assigning the MMA vector operands to altivec registers [PR105556]

2022-05-10 Thread Peter Bergner via Gcc-patches
On 5/10/22 5:46 PM, Peter Bergner wrote:
>> Out of interest, did you try using v,?wa (so just two alternatives, not
>> four)?  Or did you think it wouldresult in  measurably worse code?  Or
>> did you decide it is not such bad backend code size explosion after
>> all :-)
> 
> I have not tried that, but I will and see what happens.
> I'm slightly worried that since 'v' is part of 'wa', then saying
> '?wa' might just cancel the 'v' usage, but I'll see how it works.
> If it works and simplifies the patch, great!  I'll report back.

So using 'v','?wa' for both vector operands does give us the code we want
for this loop.  Yea!

However, looking closer, that 2 alternative version isn't quite as "optimal"
as the version with 4 alternatives 'v','v','?d','?d' and 'v','?d','v','?d'.
That's because the 2 alt version is an all or nothing thing, you either get
both 'v' operands or you potentially get both 'd'.  The 4 alt version is
more fine grained and has alternatives where one gets a 'v' for sure and the
other a 'd'.

That said, if even one operand is forced into a 'd' register, then our chances
of good performance are lost, so the fact we can get one in a 'v' probably
doesn't matter and given it's cleaner code with fewer alternatives, let's go
with 'v','?wa'.  Ok with you?

I'll kick off a bootstrap and regtest with that change.

Peter


Re: rs6000: Prefer assigning the MMA vector operands to altivec registers [PR105556]

2022-05-10 Thread Peter Bergner via Gcc-patches
On 5/10/22 5:35 PM, Segher Boessenkool wrote:
> If you want to use this same message as commit message, you shouldn't
> say "this patch".  Also, try not to use lines more than 72 positions
> wide (which handily is also a good maximum length for email messages,
> that way it can be quoted a few times without wrapping).

Sure, I can reword that.


> And I assume generated code still looks at least as good otherwise?

If you are asking whether we get the code we want generated with the
patch, the answer is yes.  Otherwise, I'm not sure what you're asking. :-)

 

> This is more involved than just replacing one constrait with two.  You
> shoould say that in the changelog (and in your message).

Ok, I can expand on that.


> Out of interest, did you try using v,?wa (so just two alternatives, not
> four)?  Or did you think it wouldresult in  measurably worse code?  Or
> did you decide it is not such bad backend code size explosion after
> all :-)

I have not tried that, but I will and see what happens.
I'm slightly worried that since 'v' is part of 'wa', then saying
'?wa' might just cancel the 'v' usage, but I'll see how it works.
If it works and simplifies the patch, great!  I'll report back.


> Okay for trunk with a slightly better changelog.  Thanks!

If it doesn't work, I'll go with the code as is, modulo the
changes you asked for.  Thanks.


Peter



Re: rs6000: Prefer assigning the MMA vector operands to altivec registers [PR105556]

2022-05-10 Thread Segher Boessenkool
Hi!

On Tue, May 10, 2022 at 03:47:40PM -0500, Peter Bergner wrote:
> This patch addresses an issue when compiling the MMA optimized DGEMM kernel

If you want to use this same message as commit message, you shouldn't
say "this patch".  Also, try not to use lines more than 72 positions
wide (which handily is also a good maximum length for email messages,
that way it can be quoted a few times without wrapping).

> in OpenBLAS.  The MMA code uses all 8 accumulators, which overlap all vs0-vs31
> vector registers.  Current trunk assigns one of the normal vector inputs to
> one of the MMA instructions, which forces us to spill one of the accumulators
> to memory, leading to poor performance.  The solution here is to replace the
> "wa" constraints for the vector input operands in the MMA instruction patterns
> with "v,?d" so that we disparage using vs0-vs31 and prefer using the altivec
> registers vs32-vs63 instead, which fixes the dgemm performance issue.

And I assume generated code still looks at least as good otherwise?

> This passed bootstrap and regtesting with no regressions on powerpc64le-linux.
> Ok for trunk and after a few days of burn-in to the GCC12 release branch?
> 
> Technically, the same issue exists in GCC11 and GCC10, but the RA
> assignment is OK with the current code, so unless/until we have a
> test case that exhibits the issue, I'm only asking for a backport to
> GCC12 which does show the performance problem.

So, you put everything that shouldn't be in the commit message at the
end of the mail, easy to delete when applying the patch.  Good good :-)

> gcc/
>   PR target/105556
>   * config/rs6000/mma.md (mma_, mma_, mma_, mma_,
>   mma_, mma_, mma_, mma_,
>   mma_, mma_, mma_, mma_,
>   mma_, mma_): Replace "wa" constraint with "v,?d".

> diff --git a/gcc/config/rs6000/mma.md b/gcc/config/rs6000/mma.md
> index 907c9d6d516..9c9920870e4 100644
> --- a/gcc/config/rs6000/mma.md
> +++ b/gcc/config/rs6000/mma.md
> @@ -490,50 +490,50 @@ (define_insn "mma_xxsetaccz"
>[(set_attr "type" "mma")])
>  
>  (define_insn "mma_"
> -  [(set (match_operand:XO 0 "fpr_reg_operand" "=")
> - (unspec:XO [(match_operand:V16QI 1 "vsx_register_operand" "wa")
> - (match_operand:V16QI 2 "vsx_register_operand" "wa")]
> +  [(set (match_operand:XO 0 "fpr_reg_operand" "=,,,")
> + (unspec:XO [(match_operand:V16QI 1 "vsx_register_operand" "v,v,?d,?d")
> + (match_operand:V16QI 2 "vsx_register_operand" "v,?d,v,?d")]

This is more involved than just replacing one constrait with two.  You
shoould say that in the changelog (and in your message).

Out of interest, did you try using v,?wa (so just two alternatives, not
four)?  Or did you think it wouldresult in  measurably worse code?  Or
did you decide it is not such bad backend code size explosion after
all :-)

Okay for trunk with a slightly better changelog.  Thanks!


Segher


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

2022-05-10 Thread Palmer Dabbelt

On Thu, 05 May 2022 11:45:50 PDT (-0700), gcc-patches@gcc.gnu.org wrote:

On Thu, May 05, 2022 at 06:33:20PM +0800, jiawei wrote:

Some compiler target like arm-linux\riscv\power\s390x\xtensa-gcc handle
char as unsigned char, then there are no warnings occur and got FAIL cases.
Just change the type char into explicit signed char to keep the feature
consistency.

gcc/testsuite/ChangeLog:

* c-c++-common/Wconversion-1.c: Update type.


Ok, and sorry for introducing this problem!


So this is OK for trunk?  Happy to commit it if you'd like, just wanted 
to make sure as I'm not seeing it on trunk.



---
 gcc/testsuite/c-c++-common/Wconversion-1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/c-c++-common/Wconversion-1.c 
b/gcc/testsuite/c-c++-common/Wconversion-1.c
index ed65918c70f..7053f6b5dbb 100644
--- a/gcc/testsuite/c-c++-common/Wconversion-1.c
+++ b/gcc/testsuite/c-c++-common/Wconversion-1.c
@@ -10,5 +10,5 @@ void g()
   signed char sc = 300; /* { dg-warning "conversion from .int. to .signed char. 
changes value from .300. to .44." } */
   unsigned char uc = 300; /* { dg-warning "conversion from .int. to .unsigned char. 
changes value from .300. to .44." } */
   unsigned char uc2 = 300u; /* { dg-warning "conversion from .unsigned int. to 
.unsigned char. changes value from .300. to .44." } */
-  char c2 = (double)1.0 + 200; /* { dg-warning "overflow in conversion from 
.double. to .char. changes value from .2.01e\\+2. to .127." } */
+  signed char c2 = (double)1.0 + 200; /* { dg-warning "overflow in conversion from 
.double. to .signed char. changes value from .2.01e\\+2. to .127." } */
 }
--
2.25.1



Marek


[PATCH] PR fortran/105230 - [9/10/11/12/13 Regression] ICE in find_array_section, at fortran/expr.cc:1634

2022-05-10 Thread Harald Anlauf via Gcc-patches
Dear all,

I intend to commit the attached patch as obvious within the next
24 hours unless there are objections.  It fixes the logic which
is intended to prevent a NULL pointer dereference on invalid
code, which is related to PR104849.  (Both PRs by Gerhard).

Co-authored by Steve.  Regtested on x86_64-pc-linux-gnu.
I plan to backport as seems appropriate.

Thanks,
Harald

From eac44ace68dd0476bda93ea49a758904c30e3a33 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Tue, 10 May 2022 23:41:57 +0200
Subject: [PATCH] Fortran: fix error recovery on invalid array section

gcc/fortran/ChangeLog:

	PR fortran/105230
	* expr.cc (find_array_section): Correct logic to avoid NULL
	pointer dereference on invalid array section.

gcc/testsuite/ChangeLog:

	PR fortran/105230
	* gfortran.dg/pr105230.f90: New test.

Co-authored-by: Steven G. Kargl 
---
 gcc/fortran/expr.cc| 4 ++--
 gcc/testsuite/gfortran.dg/pr105230.f90 | 8 
 2 files changed, 10 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr105230.f90

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 86d61fed302..be94c18c836 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -1595,8 +1595,8 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
 	  if ((begin && begin->expr_type != EXPR_CONSTANT)
 	  || (finish && finish->expr_type != EXPR_CONSTANT)
 	  || (step && step->expr_type != EXPR_CONSTANT)
-	  || (!begin && !lower)
-	  || (!finish && !upper))
+	  || !lower
+	  || !upper)
 	{
 	  t = false;
 	  goto cleanup;
diff --git a/gcc/testsuite/gfortran.dg/pr105230.f90 b/gcc/testsuite/gfortran.dg/pr105230.f90
new file mode 100644
index 000..6c6b42ef9bf
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr105230.f90
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! PR fortran/105230 - ICE in find_array_section
+! Contributed by G.Steinmetz
+
+program p
+  integer, parameter :: a(:) = [1, 2] ! { dg-error "deferred shape" }
+  print *, reshape([3, 4], a(1:2))
+end
--
2.35.3



PING Re: [PATCH RFA] attribs: fix typedefs in generic code [PR105492]

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

Ping?

On 5/5/22 14:07, Jason Merrill wrote:

In my patch for PR100545 I added an assert to check for broken typedefs in
set_underlying_type, and it found one in this case:
rs6000_handle_altivec_attribute had the same problem as
handle_mode_attribute.  So let's move the fixup into decl_attributes.

Tested that this fixes the ICE on a cross compiler, regression tested
x86_64-pc-linux-gnu, OK for trunk?

PR c/105492

gcc/ChangeLog:

* attribs.cc (decl_attributes): Fix broken typedefs here.

gcc/c-family/ChangeLog:

* c-attribs.cc (handle_mode_attribute): Don't fix broken typedefs
here.
---
  gcc/attribs.cc| 15 +++
  gcc/c-family/c-attribs.cc | 10 --
  2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/gcc/attribs.cc b/gcc/attribs.cc
index b219f878042..0648391f0c6 100644
--- a/gcc/attribs.cc
+++ b/gcc/attribs.cc
@@ -872,6 +872,21 @@ decl_attributes (tree *node, tree attributes, int flags,
  tree ret = (spec->handler) (cur_and_last_decl, name, args,
  flags|cxx11_flag, _add_attrs);
  
+	  /* Fix up typedefs clobbered by attribute handlers.  */

+ if (TREE_CODE (*node) == TYPE_DECL
+ && anode == _TYPE (*node)
+ && DECL_ORIGINAL_TYPE (*node)
+ && TYPE_NAME (*anode) == *node
+ && TYPE_NAME (cur_and_last_decl[0]) != *node)
+   {
+ tree t = cur_and_last_decl[0];
+ DECL_ORIGINAL_TYPE (*node) = t;
+ tree tt = build_variant_type_copy (t);
+ cur_and_last_decl[0] = tt;
+ TREE_TYPE (*node) = tt;
+ TYPE_NAME (tt) = *node;
+   }
+
  *anode = cur_and_last_decl[0];
  if (ret == error_mark_node)
{
diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index b1953a45f9b..a280987c111 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -2204,16 +2204,6 @@ handle_mode_attribute (tree *node, tree name, tree args,
 TYPE_QUALS (type));
if (TYPE_USER_ALIGN (type))
*node = build_aligned_type (*node, TYPE_ALIGN (type));
-
-  tree decl = node[2];
-  if (decl && TYPE_NAME (type) == decl)
-   {
- /* Set up the typedef all over again.  */
- DECL_ORIGINAL_TYPE (decl) = NULL_TREE;
- TREE_TYPE (decl) = *node;
- set_underlying_type (decl);
- *node = TREE_TYPE (decl);
-   }
  }
  
return NULL_TREE;


base-commit: 000f4480005035d0811e009a7cb25b42721f0a6e




rs6000: Prefer assigning the MMA vector operands to altivec registers [PR105556]

2022-05-10 Thread Peter Bergner via Gcc-patches
This patch addresses an issue when compiling the MMA optimized DGEMM kernel
in OpenBLAS.  The MMA code uses all 8 accumulators, which overlap all vs0-vs31
vector registers.  Current trunk assigns one of the normal vector inputs to
one of the MMA instructions, which forces us to spill one of the accumulators
to memory, leading to poor performance.  The solution here is to replace the
"wa" constraints for the vector input operands in the MMA instruction patterns
with "v,?d" so that we disparage using vs0-vs31 and prefer using the altivec
registers vs32-vs63 instead, which fixes the dgemm performance issue.

This passed bootstrap and regtesting with no regressions on powerpc64le-linux.
Ok for trunk and after a few days of burn-in to the GCC12 release branch?

Technically, the same issue exists in GCC11 and GCC10, but the RA
assignment is OK with the current code, so unless/until we have a
test case that exhibits the issue, I'm only asking for a backport to
GCC12 which does show the performance problem.

Peter


gcc/
PR target/105556
* config/rs6000/mma.md (mma_, mma_, mma_, mma_,
mma_, mma_, mma_, mma_,
mma_, mma_, mma_, mma_,
mma_, mma_): Replace "wa" constraint with "v,?d".

diff --git a/gcc/config/rs6000/mma.md b/gcc/config/rs6000/mma.md
index 907c9d6d516..9c9920870e4 100644
--- a/gcc/config/rs6000/mma.md
+++ b/gcc/config/rs6000/mma.md
@@ -490,50 +490,50 @@ (define_insn "mma_xxsetaccz"
   [(set_attr "type" "mma")])
 
 (define_insn "mma_"
-  [(set (match_operand:XO 0 "fpr_reg_operand" "=")
-   (unspec:XO [(match_operand:V16QI 1 "vsx_register_operand" "wa")
-   (match_operand:V16QI 2 "vsx_register_operand" "wa")]
+  [(set (match_operand:XO 0 "fpr_reg_operand" "=,,,")
+   (unspec:XO [(match_operand:V16QI 1 "vsx_register_operand" "v,v,?d,?d")
+   (match_operand:V16QI 2 "vsx_register_operand" "v,?d,v,?d")]
MMA_VV))]
   "TARGET_MMA"
   " %A0,%x1,%x2"
   [(set_attr "type" "mma")])
 
 (define_insn "mma_"
-  [(set (match_operand:XO 0 "fpr_reg_operand" "=")
-   (unspec:XO [(match_operand:XO 1 "fpr_reg_operand" "0")
-   (match_operand:V16QI 2 "vsx_register_operand" "wa")
-   (match_operand:V16QI 3 "vsx_register_operand" "wa")]
+  [(set (match_operand:XO 0 "fpr_reg_operand" "=,,,")
+   (unspec:XO [(match_operand:XO 1 "fpr_reg_operand" "0,0,0,0")
+   (match_operand:V16QI 2 "vsx_register_operand" "v,v,?d,?d")
+   (match_operand:V16QI 3 "vsx_register_operand" "v,?d,v,?d")]
MMA_AVV))]
   "TARGET_MMA"
   " %A0,%x2,%x3"
   [(set_attr "type" "mma")])
 
 (define_insn "mma_"
-  [(set (match_operand:XO 0 "fpr_reg_operand" "=")
-   (unspec:XO [(match_operand:OO 1 "vsx_register_operand" "wa")
-   (match_operand:V16QI 2 "vsx_register_operand" "wa")]
+  [(set (match_operand:XO 0 "fpr_reg_operand" "=,,,")
+   (unspec:XO [(match_operand:OO 1 "vsx_register_operand" "v,v,?d,?d")
+   (match_operand:V16QI 2 "vsx_register_operand" "v,?d,v,?d")]
MMA_PV))]
   "TARGET_MMA"
   " %A0,%x1,%x2"
   [(set_attr "type" "mma")])
 
 (define_insn "mma_"
-  [(set (match_operand:XO 0 "fpr_reg_operand" "=")
-   (unspec:XO [(match_operand:XO 1 "fpr_reg_operand" "0")
-   (match_operand:OO 2 "vsx_register_operand" "wa")
-   (match_operand:V16QI 3 "vsx_register_operand" "wa")]
+  [(set (match_operand:XO 0 "fpr_reg_operand" "=,,,")
+   (unspec:XO [(match_operand:XO 1 "fpr_reg_operand" "0,0,0,0")
+   (match_operand:OO 2 "vsx_register_operand" "v,v,?d,?d")
+   (match_operand:V16QI 3 "vsx_register_operand" "v,?d,v,?d")]
MMA_APV))]
   "TARGET_MMA"
   " %A0,%x2,%x3"
   [(set_attr "type" "mma")])
 
 (define_insn "mma_"
-  [(set (match_operand:XO 0 "fpr_reg_operand" "=")
-   (unspec:XO [(match_operand:V16QI 1 "vsx_register_operand" "wa")
-   (match_operand:V16QI 2 "vsx_register_operand" "wa")
-   (match_operand:SI 3 "const_0_to_15_operand" "n")
-   (match_operand:SI 4 "const_0_to_15_operand" "n")
-   (match_operand:SI 5 "u8bit_cint_operand" "n")]
+  [(set (match_operand:XO 0 "fpr_reg_operand" "=,,,")
+   (unspec:XO [(match_operand:V16QI 1 "vsx_register_operand" "v,v,?d,?d")
+   (match_operand:V16QI 2 "vsx_register_operand" "v,?d,v,?d")
+   (match_operand:SI 3 "const_0_to_15_operand" "n,n,n,n")
+   (match_operand:SI 4 "const_0_to_15_operand" "n,n,n,n")
+   (match_operand:SI 5 "u8bit_cint_operand" "n,n,n,n")]
MMA_VVI4I4I8))]
   "TARGET_MMA"
   " %A0,%x1,%x2,%3,%4,%5"
@@ -541,13 +541,13 @@ (define_insn "mma_"
(set_attr "prefixed" "yes")])
 
 (define_insn "mma_"
-  [(set (match_operand:XO 0 "fpr_reg_operand" "=")
-   (unspec:XO [(match_operand:XO 1 "fpr_reg_operand" "0")

Re: [PATCH 09/10] libgcc: Add support for HF mode (aka __fp16) in libbid

2022-05-10 Thread Joseph Myers
On Tue, 10 May 2022, Christophe Lyon via Gcc-patches wrote:

> > Note that for conversion from DFP to HFmode, double rounding (going via
> > SFmode) probably produces incorrectly rounded results in some cases
> > (though we already have such incorrect results in the other direction for
> > DPD; see bug 97635).
> 
> Thanks for the pointer.
> I was aware of such imprecision in the code I introduce, but not in existing
> one. I don't think this is a blocker for this patch, is it?

I don't think it's a blocker.

> > Wouldn't it be better to have tests that apply for all targets supporting
> > both HFmode and BID DFP, which includes x86 / x86_64 (with SSE2 support)
> > as well, using _Float16 as the type name (and the float16 /
> > float16_runtime effective-target keywords to test for the relevant support
> > and dg-add-options float16)?
> > 
> Indeed! What would be the appropriate directory for such tests?

Maybe gcc.dg/dfp, or gcc.dg/torture if it's useful to run the tests for 
multiple choices of optimization options.

> > That seems wrong; the __fp16 name is specific to Arm / AArch64.  I'd
> > expect the typedef alone to be specific; in any case, the "mode" attribute
> > is the appropriate way to define this type.
> > 
> I'll change that to __float16 (like __float128 we have a few lines below for
> TFtype).

There's _Float16, but no such type as __float16.

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


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

2022-05-10 Thread Segher Boessenkool
On Tue, May 10, 2022 at 02:56:58PM -0400, Michael Meissner wrote:
> On Tue, May 10, 2022 at 07:27:30AM -0500, Segher Boessenkool wrote:
> > > IMHO, it's something we want to fix as well, based on the reasons:
> > >   1) bif names have the corresponding mnemonics, users would expect 1-1 
> > > mapping here.
> > >   2) clang emits xs{min,max}dp all the time, with cpu type power7/8/9/10.
> > >   3) according to uarch info, xs{min,max}cdp use the same units and have 
> > > the same latency,
> > >  no benefits to replace with xs{min,max}cdp.
> > 
> > I never understood any of this.  Mike?  Why do we do those "c" things
> > at all, ever?
> 
> In the power7, we only had x{s,v}{min,max}{sp,dp}.  But those aren't useful 
> for
> optimizing normal (a > b) ? a : b without using -ffast-math.

But RTL smin (as well as Gimple min_expr) is *undefined* without
-ffast-math (well, -ffinite-math-only and -fno-signed-zeros at least).
The only place we generate xs{min,max}[c]dp uses s{min,max}.  So the
much saner xs{min,max}dp are fine always.

> Power9 added the
> 'c' and 'j' versions of the insns.  GCC never generates the 'j' version.
> 
> Basically for ?: we generate:
> 
> * Code = power8, no -ffast-math:Generate compare, move;
> * Code = power8, -ffast-math:   Generate xsmaxdp/xsmindp;
> * Code = power9, no -ffast-mth: Generate xsmaxcdp/xsmincdp; (and)

This one uses broken RTL (and broken Gimple before that): s{min,max}
cannot be used for FP without -ffast-math.

> * Code = power9, -ffast-math:   Generate xsmaxcdp/xsmincdp.

xs{min,max}dp will work just as well.

> For the __builtin_fmax and __builtin_fmin functions:
> 
> * Code = power8, no -ffast-math:Generate call to fmax/fmin;
> * Code = power8, -ffast-math:   Generate xsmaxdp/xsmindp;
> * Code = power9, no -ffast-mth: Generate call to fmax/fmin; (and)
> * Code = power9, -ffast-math:   Generate xsmaxcdp/xsmincdp.

Same brokenness here.

> For IEEE 128-bit floating point, we only have xs{min,max}cqp.  We do not have
> the version without 'c' nor do we have the 'j' version.

And here.

Why would we ever prefer xsmincdp over xsmindp, other than for machine
code for some not-so-smart C code that wil not do useful things for
signed zeros or NaNs (but using the "c" insns generates faster, smaller
code that has those silly semantics)?


Segher


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

2022-05-10 Thread Michael Meissner via Gcc-patches
On Tue, May 10, 2022 at 07:27:30AM -0500, Segher Boessenkool wrote:
> > IMHO, it's something we want to fix as well, based on the reasons:
> >   1) bif names have the corresponding mnemonics, users would expect 1-1 
> > mapping here.
> >   2) clang emits xs{min,max}dp all the time, with cpu type power7/8/9/10.
> >   3) according to uarch info, xs{min,max}cdp use the same units and have 
> > the same latency,
> >  no benefits to replace with xs{min,max}cdp.
> 
> I never understood any of this.  Mike?  Why do we do those "c" things
> at all, ever?

In the power7, we only had x{s,v}{min,max}{sp,dp}.  But those aren't useful for
optimizing normal (a > b) ? a : b without using -ffast-math.  Power9 added the
'c' and 'j' versions of the insns.  GCC never generates the 'j' version.

Basically for ?: we generate:

*   Code = power8, no -ffast-math:Generate compare, move;
*   Code = power8, -ffast-math:   Generate xsmaxdp/xsmindp;
*   Code = power9, no -ffast-mth: Generate xsmaxcdp/xsmincdp; (and)
*   Code = power9, -ffast-math:   Generate xsmaxcdp/xsmincdp.

For the __builtin_fmax and __builtin_fmin functions:

*   Code = power8, no -ffast-math:Generate call to fmax/fmin;
*   Code = power8, -ffast-math:   Generate xsmaxdp/xsmindp;
*   Code = power9, no -ffast-mth: Generate call to fmax/fmin; (and)
*   Code = power9, -ffast-math:   Generate xsmaxcdp/xsmincdp.

For IEEE 128-bit floating point, we only have xs{min,max}cqp.  We do not have
the version without 'c' nor do we have the 'j' version.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com


Re: [patch gcc13] middle-end/70090: Dynamic sizes for -fsanitize=object-size

2022-05-10 Thread Siddhesh Poyarekar

On 10/05/2022 16:16, Martin Liška wrote:

The revision caused:

$ ./xgcc -B. 
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/ubsan/bind-c-intent-out-2.f90
 -fsanitize=undefined -c -O
during GIMPLE pass: ubsan
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/ubsan/bind-c-intent-out-2.f90:39:19:

39 | end program alloc_p
   |   ^
internal compiler error: Segmentation fault
0x14b45c7 crash_signal
/home/marxin/Programming/gcc/gcc/toplev.cc:322
0x778b83cf ???

/usr/src/debug/glibc-2.35-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xc2cf10 contains_struct_check(tree_node*, tree_node_structure_enum, char 
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3570
0x19100d1 build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**)
/home/marxin/Programming/gcc/gcc/tree.cc:10629
0x19102ff build_call_expr_loc(unsigned int, tree_node*, int, ...)
/home/marxin/Programming/gcc/gcc/tree.cc:10662
0x14f59a3 instrument_object_size
/home/marxin/Programming/gcc/gcc/ubsan.cc:2173
0x14f6770 execute
/home/marxin/Programming/gcc/gcc/ubsan.cc:2428
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


Thanks, I just noticed that my non-ubsan bootstrap didn't enable 
sanitizers because of which I didn't see this at all.  I'm testing a fix 
and I'll post it once bootstraps finish.


Siddhesh


Re: [committed] Fix more problems with new linker warnings

2022-05-10 Thread H.J. Lu via Gcc-patches
On Thu, Apr 28, 2022 at 11:52 PM Richard Biener
 wrote:
>
> On Thu, Apr 28, 2022 at 7:54 PM H.J. Lu  wrote:
> >
> > On Thu, Apr 28, 2022 at 9:59 AM Jeff Law  wrote:
> > >
> > >
> > >
> > > On 4/28/2022 10:27 AM, H.J. Lu wrote:
> > > > On Thu, Apr 28, 2022 at 9:10 AM Jeff Law via Gcc-patches
> > > >  wrote:
> > > >> As I mentioned in the original thread, my change to pr94157_0 was an
> > > >> attempt to avoid these warnings by passing a magic flag to the linker.
> > > >> Of course we may not be using GNU ld.  Or we may be on a non-elf target
> > > >> where the flag I used doesn't exist.  Or we may even be on a ELF target
> > > >> where those bits weren't added to the linker (frv).  Furthermore, we
> > > >> need fixes to all the nested function tests as well.
> > > >>
> > > >> So even though I initially resisted pruning the warning, that seems 
> > > >> like
> > > >> the best course of action.  So this patch removes my recent change to
> > > >> pr94157_0 and instead uses our pruning facilities.
> > > >>
> > > >> I'll be pushing this to the trunk and gcc-12 branch.
> > > >>
> > > > Can you backport it to other release branches?
> > > I wasn't planning to, but can if the RMs want it.
> > > jeff
> >
> > Hi Jakub, Ricard,
> >
> > Is it OK to backport the new linker support to GCC 11 and
> > GCC 10 branches?
>
> It's OK if no problems have been reported for a while.
>
> Thanks,
> Richard.

I am backporting it now.

Thanks.

-- 
H.J.


Re: [PATCH] PR fortran/105526 - [Coarray] Add missing checks for arguments of type TEAM_TYPE

2022-05-10 Thread Mikael Morin

Le 09/05/2022 à 22:20, Harald Anlauf via Fortran a écrit :

Dear Fortranners,

we were lacking checks for arguments of type TEAM_TYPE to some
coarray intrinsics (FORM TEAM, CHANGE TEAM, and SYNC TEAM).
The attached patch adds these, and as a bonus verifies that
TEAM NUMBER is a scalar integer.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?



OK, Thanks.


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

2022-05-10 Thread H.J. Lu via Gcc-patches
When compiling Linux kernel with -fcf-protection=branch to enable x86
Indiret Branch Tracking (IBT), ENDBR is added to all global functions.
This creates more "legal" forward edges than necessary.  -mmanual-endbr
provides a way to insert ENDBR instruction at function entry only via
the 'cf_check' function attribute and programmers can add the 'cf_check'
function attribute to functions which can be reached by indirect branch.

Add -fcf-check-attribute=[yes|no|none] to imply "cf_check" or "nocf_check"
function attributes so that GCC can produce a diagnostic when there is a
mismatch in cf_check or nocf_check function attributes.

This has been tested on Linux kernel.

gcc/

PR target/102953
* attribs.cc (decl_attributes): Add implied cf_check or nocf_check
function attributes.
* common.opt: Add -fcf-check-attribute=.
* flag-types.h (cf_check_attribute): New.
* doc/invoke.texi: Document -fcf-check-attribute=.

gcc/c/

PR target/102953
* c-decl.cc (diagnose_mismatched_decls): Check implied cf_check
and nocf_check function attributes.

gcc/testsuite/

PR target/102953
* gcc.target/i386/pr102953-3.c: New test.
* gcc.target/i386/pr102953-4.c: Likewise.
* gcc.target/i386/pr102953-5.c: Likewise.
* gcc.target/i386/pr102953-6.c: Likewise.
---
 gcc/attribs.cc | 19 +++
 gcc/c/c-decl.cc| 22 +-
 gcc/common.opt | 16 
 gcc/doc/invoke.texi| 12 
 gcc/flag-types.h   |  8 
 gcc/testsuite/gcc.target/i386/pr102953-3.c |  8 
 gcc/testsuite/gcc.target/i386/pr102953-4.c |  7 +++
 gcc/testsuite/gcc.target/i386/pr102953-5.c |  7 +++
 gcc/testsuite/gcc.target/i386/pr102953-6.c |  8 
 9 files changed, 106 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr102953-3.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr102953-4.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr102953-5.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr102953-6.c

diff --git a/gcc/attribs.cc b/gcc/attribs.cc
index b219f878042..34e8707eac1 100644
--- a/gcc/attribs.cc
+++ b/gcc/attribs.cc
@@ -694,6 +694,25 @@ decl_attributes (tree *node, tree attributes, int flags,
attributes = tree_cons (get_identifier ("no_icf"),  NULL, attributes);
 }
 
+  /* -fcf-check-attribute=[yes|no] implies "cf_check" or "nocf_check"
+ function attribute.  */
+  if (TREE_CODE (*node) == FUNCTION_DECL
+  && flag_cf_check_attribute != CF_CHECK_ATTRIBUTE_NONE
+  && !fndecl_built_in_p (*node)
+  && lookup_attribute ("nocf_check",
+  DECL_ATTRIBUTES (*node)) == nullptr
+  && lookup_attribute ("cf_check",
+  DECL_ATTRIBUTES (*node)) == nullptr
+  && (!attributes
+ || (lookup_attribute ("nocf_check", attributes) == nullptr
+ && lookup_attribute ("cf_check", attributes) == nullptr)))
+{
+  const char *attr = (flag_cf_check_attribute == CF_CHECK_ATTRIBUTE_YES
+ ? "cf_check" : "nocf_check");
+  attributes = tree_cons (get_identifier (attr), nullptr,
+ attributes);
+}
+
   targetm.insert_attributes (*node, );
 
   /* Note that attributes on the same declaration are not necessarily
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index c701f07befe..787c39dc0fe 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -2133,7 +2133,27 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
error ("conflicting type qualifiers for %q+D", newdecl);
}
  else
-   error ("conflicting types for %q+D; have %qT", newdecl, newtype);
+   {
+ if (flag_cf_check_attribute == CF_CHECK_ATTRIBUTE_NO
+ && (!lookup_attribute ("nocf_check",
+ TYPE_ATTRIBUTES (oldtype))
+  != !lookup_attribute ("nocf_check",
+TYPE_ATTRIBUTES (newtype
+   error ("conflicting types for %q+D; have %qT with "
+  "implied % attribute",
+  newdecl, newtype);
+ else if (flag_cf_check_attribute == CF_CHECK_ATTRIBUTE_YES
+  && (!lookup_attribute ("cf_check",
+TYPE_ATTRIBUTES (oldtype))
+ != !lookup_attribute ("cf_check",
+   TYPE_ATTRIBUTES (newtype
+   error ("conflicting types for %q+D; have %qT with "
+  "implied % attribute",
+  newdecl, newtype);
+ else
+   error ("conflicting types for %q+D; have %qT",
+  newdecl, newtype);

[PATCH] x86: Skip ENDBR when emitting direct call/jmp to local function

2022-05-10 Thread H.J. Lu via Gcc-patches
Mark a function with SYMBOL_FLAG_FUNCTION_ENDBR when inserting ENDBR at
function entry.  Skip the 4-byte ENDBR when emitting a direct call/jmp
to a local function with ENDBR at function entry.

This has been tested on Linux kernel.

gcc/

PR target/102953
* config/i386/i386-features.cc
(rest_of_insert_endbr_and_patchable_area): Set
SYMBOL_FLAG_FUNCTION_ENDBR when inserting ENDBR.
* config/i386/i386.cc (ix86_print_operand): Skip the 4-byte ENDBR
when calling the local function with ENDBR at function entry.
* config/i386/i386.h (SYMBOL_FLAG_FUNCTION_ENDBR): New.
(SYMBOL_FLAG_FUNCTION_ENDBR_P): Likewise.

gcc/testsuite/

PR target/102953
* gcc.target/i386/pr102953-1.c: New test.
* gcc.target/i386/pr102953-2.c: Likewise.
---
 gcc/config/i386/i386-features.cc   |  2 ++
 gcc/config/i386/i386.cc| 11 +++-
 gcc/config/i386/i386.h |  5 
 gcc/testsuite/gcc.target/i386/pr102953-1.c | 25 ++
 gcc/testsuite/gcc.target/i386/pr102953-2.c | 30 ++
 5 files changed, 72 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr102953-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr102953-2.c

diff --git a/gcc/config/i386/i386-features.cc b/gcc/config/i386/i386-features.cc
index 6fe41c3c24f..3ca1131ed59 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@ -1979,6 +1979,8 @@ rest_of_insert_endbr_and_patchable_area (bool need_endbr,
  || (TARGET_DLLIMPORT_DECL_ATTRIBUTES
  && DECL_DLLIMPORT_P (cfun->decl
{
+ rtx symbol = XEXP (DECL_RTL (cfun->decl), 0);
+ SYMBOL_REF_FLAGS (symbol) |= SYMBOL_FLAG_FUNCTION_ENDBR;
  if (crtl->profile && flag_fentry)
{
  /* Queue ENDBR insertion to x86_function_profiler.
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 86752a6516a..ad1de239bef 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -13787,7 +13787,16 @@ ix86_print_operand (FILE *file, rtx x, int code)
   else if (flag_pic || MACHOPIC_INDIRECT)
output_pic_addr_const (file, x, code);
   else
-   output_addr_const (file, x);
+   {
+ /* Skip ENDBR when emitting a direct call/jmp to a local
+function with ENDBR at function entry.  */
+ if (code == 'P'
+ && GET_CODE (x) == SYMBOL_REF
+ && SYMBOL_REF_LOCAL_P (x)
+ && SYMBOL_FLAG_FUNCTION_ENDBR_P (x))
+   x = gen_rtx_PLUS (Pmode, x, GEN_INT (4));
+ output_addr_const (file, x);
+   }
 }
 }
 
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 363082ba47b..7a6317fea57 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -2792,6 +2792,11 @@ extern GTY(()) tree ms_va_list_type_node;
 #define SYMBOL_REF_STUBVAR_P(X) \
((SYMBOL_REF_FLAGS (X) & SYMBOL_FLAG_STUBVAR) != 0)
 
+/* Flag to mark a function with ENDBR at entry.  */
+#define SYMBOL_FLAG_FUNCTION_ENDBR (SYMBOL_FLAG_MACH_DEP << 5)
+#define SYMBOL_FLAG_FUNCTION_ENDBR_P(X) \
+   ((SYMBOL_REF_FLAGS (X) & SYMBOL_FLAG_FUNCTION_ENDBR) != 0)
+
 extern void debug_ready_dispatch (void);
 extern void debug_dispatch_window (int);
 
diff --git a/gcc/testsuite/gcc.target/i386/pr102953-1.c 
b/gcc/testsuite/gcc.target/i386/pr102953-1.c
new file mode 100644
index 000..2afad391baf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr102953-1.c
@@ -0,0 +1,25 @@
+/* { dg-do compile { target { ! *-*-darwin* } } } */
+/* { dg-options "-O2 -fno-pic -fplt -fcf-protection" } */
+
+extern int func (int);
+
+extern int i;
+
+__attribute__ ((noclone, noinline, noipa))
+static int
+bar (int x)
+{
+  if (x == 0)
+return x;
+  return bar (x - 1) + func (x);
+}
+
+void *
+foo (void)
+{
+  i = bar (2);
+  return bar;
+}
+
+/* { dg-final { scan-assembler-times {call\t_?bar\+4\M} 2 } } */
+/* { dg-final { scan-assembler-times {call\t_?func\M} 1 } } */
diff --git a/gcc/testsuite/gcc.target/i386/pr102953-2.c 
b/gcc/testsuite/gcc.target/i386/pr102953-2.c
new file mode 100644
index 000..5b8d517f4f2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr102953-2.c
@@ -0,0 +1,30 @@
+/* { dg-do compile { target { ! *-*-darwin* } } } */
+/* { dg-options "-O2 -fno-pic -fplt -fcf-protection" } */
+
+static int bar (int x);
+extern int func (int);
+
+int
+foo (int i)
+{
+  return bar (i);
+}
+
+void *
+bar_p (void)
+{
+  return bar;
+}
+
+__attribute__ ((noclone, noinline, noipa))
+static int
+bar (int x)
+{
+  if (x == 0)
+return x;
+  return bar (x - 1) + func (x);
+}
+
+/* { dg-final { scan-assembler-times {call\t_?bar\+4\M} 1 } } */
+/* { dg-final { scan-assembler-times {jmp\t_?bar\+4\M} 1 } } */
+/* { dg-final { scan-assembler-times {call\t_?func\M} 1 } } */
-- 
2.35.1



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

2022-05-10 Thread H.J. Lu via Gcc-patches
When -fcf-protection=branch is used, the compiler will generate jump
tables where the indirect jump is prefixed with the NOTRACK prefix, so
it can jump to non-ENDBR targets. Yet, for NOTRACK prefixes to work, the
NOTRACK specific enable bit must be set, what renders the binary broken
on any environment where this is not the case. In fact, having NOTRACK
disabled was a design choice for the Linux kernel CET support.

Generate jump tables with ENDBR and skip the NOTRACK prefix for indirect
jump.  Document -mno-cet-switch to turn off CET instrumentation on jump
tables for switch statements.

gcc/

PR target/104816
* config/i386/i386.opt: Turn on -mcet-switch by default.
* doc/invoke.texi: Document -mno-cet-switch.

gcc/testsuite/

* gcc.target/i386/cet-switch-1.c: Add -mno-cet-switch.
* gcc.target/i386/cet-switch-2.c: Remove -mcet-switch.
* gcc.target/i386/cet-switch-3.c: Likewise.
---
 gcc/config/i386/i386.opt | 2 +-
 gcc/doc/invoke.texi  | 9 -
 gcc/testsuite/gcc.target/i386/cet-switch-1.c | 2 +-
 gcc/testsuite/gcc.target/i386/cet-switch-2.c | 2 +-
 gcc/testsuite/gcc.target/i386/cet-switch-3.c | 2 +-
 5 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
index a6b0e28f238..96b4a433e44 100644
--- a/gcc/config/i386/i386.opt
+++ b/gcc/config/i386/i386.opt
@@ -1047,7 +1047,7 @@ Enable shadow stack built-in functions from Control-flow 
Enforcement
 Technology (CET).
 
 mcet-switch
-Target Undocumented Var(flag_cet_switch) Init(0)
+Target Var(flag_cet_switch) Init(1)
 Turn on CET instrumentation for switch statements that use a jump table and
 an indirect jump.
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 7a35d9613a4..8bb96c5938a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1420,7 +1420,8 @@ See RS/6000 and PowerPC Options.
 -msse4a  -m3dnow  -m3dnowa  -mpopcnt  -mabm  -mbmi  -mtbm  -mfma4  -mxop @gol
 -madx  -mlzcnt  -mbmi2  -mfxsr  -mxsave  -mxsaveopt  -mrtm  -mhle  -mlwp @gol
 -mmwaitx  -mclzero  -mpku  -mthreads  -mgfni  -mvaes  -mwaitpkg @gol
--mshstk -mmanual-endbr -mforce-indirect-call  -mavx512vbmi2 -mavx512bf16 
-menqcmd @gol
+-mshstk -mmanual-endbr -mno-cet-switch -mforce-indirect-call @gol
+-mavx512vbmi2 -mavx512bf16 -menqcmd @gol
 -mvpclmulqdq  -mavx512bitalg  -mmovdiri  -mmovdir64b  -mavx512vpopcntdq @gol
 -mavx5124fmaps  -mavx512vnni  -mavx5124vnniw  -mprfchw  -mrdpid @gol
 -mrdseed  -msgx -mavx512vp2intersect -mserialize -mtsxldtrk@gol
@@ -32641,6 +32642,12 @@ function attribute. This is useful when used with the 
option
 @option{-fcf-protection=branch} to control ENDBR insertion at the
 function entry.
 
+@item -mno-cet-switch
+@opindex mno-cet-switch
+@opindex mcet-switch
+Turn off CET instrumentation for switch statements that use a jump table
+and an indirect jump.  The default is @option{mcet-switch}.
+
 @item -mcall-ms2sysv-xlogues
 @opindex mcall-ms2sysv-xlogues
 @opindex mno-call-ms2sysv-xlogues
diff --git a/gcc/testsuite/gcc.target/i386/cet-switch-1.c 
b/gcc/testsuite/gcc.target/i386/cet-switch-1.c
index afe5adc2f3d..4931c3ad1d2 100644
--- a/gcc/testsuite/gcc.target/i386/cet-switch-1.c
+++ b/gcc/testsuite/gcc.target/i386/cet-switch-1.c
@@ -1,6 +1,6 @@
 /* Verify that CET works.  */
 /* { dg-do compile } */
-/* { dg-options "-O -fcf-protection" } */
+/* { dg-options "-O -fcf-protection -mno-cet-switch" } */
 /* { dg-final { scan-assembler-times "endbr32" 1 { target ia32 } } } */
 /* { dg-final { scan-assembler-times "endbr64" 1 { target { ! ia32 } } } } */
 /* { dg-final { scan-assembler-times "notrack jmp\[ \t]+\[*]" 1 } } */
diff --git a/gcc/testsuite/gcc.target/i386/cet-switch-2.c 
b/gcc/testsuite/gcc.target/i386/cet-switch-2.c
index 69ddc6fd5b7..11578d1a30c 100644
--- a/gcc/testsuite/gcc.target/i386/cet-switch-2.c
+++ b/gcc/testsuite/gcc.target/i386/cet-switch-2.c
@@ -1,6 +1,6 @@
 /* Verify that CET works.  */
 /* { dg-do compile } */
-/* { dg-options "-O -fcf-protection -mcet-switch" } */
+/* { dg-options "-O -fcf-protection" } */
 /* { dg-final { scan-assembler-times "endbr32" 12 { target ia32 } } } */
 /* { dg-final { scan-assembler-times "endbr64" 12 { target { ! ia32 } } } } */
 /* { dg-final { scan-assembler-times "\[ \t]+jmp\[ \t]+\[*]" 1 } } */
diff --git a/gcc/testsuite/gcc.target/i386/cet-switch-3.c 
b/gcc/testsuite/gcc.target/i386/cet-switch-3.c
index 0d9ed4488dd..a4e2e4dfc16 100644
--- a/gcc/testsuite/gcc.target/i386/cet-switch-3.c
+++ b/gcc/testsuite/gcc.target/i386/cet-switch-3.c
@@ -1,6 +1,6 @@
 /* Verify that CET works.  */
 /* { dg-do compile } */
-/* { dg-options "-O -fcf-protection -mcet-switch" } */
+/* { dg-options "-O -fcf-protection" } */
 /* { dg-final { scan-assembler-times "endbr32" 12 { target ia32 } } } */
 /* { dg-final { scan-assembler-times "endbr64" 12 { target { ! ia32 } } } } */
 /* { dg-final { scan-assembler-times "\[ \t]+jmp\[ \t]+\[*]" 1 } } */
-- 
2.35.1

[PATCH] doc: Fix mode iterator example

2022-05-10 Thread Segher Boessenkool
The example missed the mode condition in the replacement text.

Committed as obvious.


Segher


2022-05-10  Segher Boessenkool  

* doc/md.texi (Defining Mode Iterators): Correct example replacement
text.
---
 gcc/doc/md.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 3b544358bb53..463471f15684 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -11510,7 +11510,7 @@ This is exactly equivalent to:
   [(set (match_operand:DI 0 "register_operand" "=d")
 (minus:DI (match_operand:DI 1 "register_operand" "d")
   (match_operand:DI 2 "register_operand" "d")))]
-  ""
+  "TARGET_64BIT"
   "dsubu\t%0,%1,%2"
   [(set_attr "type" "arith")
(set_attr "mode" "DI")])
-- 
1.8.3.1



Ping: [PATCH, rs6000] Fix passing of Coomplex IEEE 128-bit [PR99685]

2022-05-10 Thread Pat Haugen via Gcc-patches

Ping.

On 4/26/22 3:06 PM, Pat Haugen via Gcc-patches wrote:

Fix register count when not splitting Complex IEEE 128-bit args.

For ABI_V4, we do not split complex args. This created a problem because
even though an arg would be passed in two VSX regs, we were only 
advancing the

function arg counter by one VSX register. Fixed with this patch.

Bootstrapped and regression tested on powerpc64(32/64) and powerpc64le.
Ok for master?

-Pat


2022-04-26  Pat Haugen  

 PR testsuite/99685

gcc/
 * config/rs6000/rs6000-call.cc (rs6000_function_arg_advance_1): Bump
 register count when not splitting IEEE 128-bit Complex.


diff --git a/gcc/config/rs6000/rs6000-call.cc 
b/gcc/config/rs6000/rs6000-call.cc

index f06c692..9d18607 100644
--- a/gcc/config/rs6000/rs6000-call.cc
+++ b/gcc/config/rs6000/rs6000-call.cc
@@ -,6 +,12 @@ rs6000_function_arg_advance_1 (CUMULATIVE_ARGS 
*cum, machine_mode mode,

  {
    cum->vregno += n_elts;

+  /* If we are not splitting Complex IEEE 128-bit args then account 
for

+ the fact that they are passed in 2 VSX regs. */
+  if (! targetm.calls.split_complex_arg && type
+  && TREE_CODE (type) == COMPLEX_TYPE && elt_mode == KCmode)
+    cum->vregno++;
+
    if (!TARGET_ALTIVEC)
  error ("cannot pass argument in vector register because"
     " altivec instructions are disabled, use %qs"




Re: [PATCH] x86: Add .note.GNU-stack section only for Linux

2022-05-10 Thread H.J. Lu via Gcc-patches
On Mon, May 9, 2022 at 7:51 AM H.J. Lu  wrote:
>
> Add .note.GNU-stack section only for Linux since it may not be supported
> on non-Linux OSes.  __ELF__ isn't checked since these tests can only run
> on Linux/x86 ELF systems.
>
> PR target/105472
> * gcc.target/i386/iamcu/asm-support.S: Add .note.GNU-stack section
> only for Linux.
> * gcc.target/x86_64/abi/asm-support.S: Likewise.
> * gcc.target/x86_64/abi/avx/asm-support.S: Likewise.
> * gcc.target/x86_64/abi/avx512f/asm-support.S: Likewise.
> * gcc.target/x86_64/abi/avx512fp16/asm-support.S: Likewise.
> * gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S: Likewise.
> * gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S: Likewise.
> * gcc.target/x86_64/abi/ms-sysv/do-test.S: Likewise.
> ---
>  gcc/testsuite/gcc.target/i386/iamcu/asm-support.S   | 2 ++
>  gcc/testsuite/gcc.target/x86_64/abi/asm-support.S   | 2 ++
>  gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support.S   | 2 ++
>  gcc/testsuite/gcc.target/x86_64/abi/avx512f/asm-support.S   | 2 ++
>  gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/asm-support.S| 2 ++
>  .../gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S| 2 ++
>  .../gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S| 2 ++
>  gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S   | 2 ++
>  8 files changed, 16 insertions(+)
>
> diff --git a/gcc/testsuite/gcc.target/i386/iamcu/asm-support.S 
> b/gcc/testsuite/gcc.target/i386/iamcu/asm-support.S
> index db08f52a34f..9d6be88e7d5 100644
> --- a/gcc/testsuite/gcc.target/i386/iamcu/asm-support.S
> +++ b/gcc/testsuite/gcc.target/i386/iamcu/asm-support.S
> @@ -300,4 +300,6 @@ iamcu_noprintf:
> .align 4
>  .LCiamcu_noprintf1:
> .long   1132527616
> +#ifdef __linux__
> .section.note.GNU-stack,"",@progbits
> +#endif
> diff --git a/gcc/testsuite/gcc.target/x86_64/abi/asm-support.S 
> b/gcc/testsuite/gcc.target/x86_64/abi/asm-support.S
> index 2f8d3a09c6b..b2ad67aef87 100644
> --- a/gcc/testsuite/gcc.target/x86_64/abi/asm-support.S
> +++ b/gcc/testsuite/gcc.target/x86_64/abi/asm-support.S
> @@ -82,4 +82,6 @@ snapshot_ret:
> .comm   xmm_regs,256,32
> .comm   x87_regs,128,32
> .comm   volatile_var,8,8
> +#ifdef __linux__
> .section.note.GNU-stack,"",@progbits
> +#endif
> diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support.S 
> b/gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support.S
> index 77b3480ac32..24c8b3c9023 100644
> --- a/gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support.S
> +++ b/gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support.S
> @@ -79,4 +79,6 @@ snapshot_ret:
> .comm   ymm_regs,512,32
> .comm   x87_regs,128,32
> .comm   volatile_var,8,8
> +#ifdef __linux__
> .section.note.GNU-stack,"",@progbits
> +#endif
> diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx512f/asm-support.S 
> b/gcc/testsuite/gcc.target/x86_64/abi/avx512f/asm-support.S
> index 2e3306c44cb..86d54d11c58 100644
> --- a/gcc/testsuite/gcc.target/x86_64/abi/avx512f/asm-support.S
> +++ b/gcc/testsuite/gcc.target/x86_64/abi/avx512f/asm-support.S
> @@ -95,4 +95,6 @@ snapshot_ret:
> .comm   zmm_regs,2048,64
> .comm   x87_regs,128,32
> .comm   volatile_var,8,8
> +#ifdef __linux__
> .section.note.GNU-stack,"",@progbits
> +#endif
> diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/asm-support.S 
> b/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/asm-support.S
> index 0793acf048b..a8165d86317 100644
> --- a/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/asm-support.S
> +++ b/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/asm-support.S
> @@ -79,4 +79,6 @@ snapshot_ret:
> .comm   xmm_regs,256,32
> .comm   x87_regs,128,32
> .comm   volatile_var,8,8
> +#ifdef __linux__
> .section.note.GNU-stack,"",@progbits
> +#endif
> diff --git 
> a/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S 
> b/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S
> index 77b3480ac32..24c8b3c9023 100644
> --- a/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S
> +++ b/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S
> @@ -79,4 +79,6 @@ snapshot_ret:
> .comm   ymm_regs,512,32
> .comm   x87_regs,128,32
> .comm   volatile_var,8,8
> +#ifdef __linux__
> .section.note.GNU-stack,"",@progbits
> +#endif
> diff --git 
> a/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S 
> b/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S
> index 2e3306c44cb..86d54d11c58 100644
> --- a/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S
> +++ b/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S
> @@ -95,4 +95,6 @@ snapshot_ret:
> .comm   

Re: [RESEND][committed v4] RISC-V: Provide `fmin'/`fmax' RTL patterns

2022-05-10 Thread Kito Cheng via Gcc-patches
Thanks Maciej!

On Tue, May 10, 2022 at 10:05 PM Maciej W. Rozycki  wrote:
>
> As at r2.2 of the RISC-V ISA specification[1] (equivalent to version 2.0
> of the "F" and "D" standard architecture extensions for single-precision
> and double-precision floating-point respectively) the FMIN and FMAX
> machine instructions fully match our requirement for the `fminM3' and
> `fmaxM3' standard RTL patterns:
>
> "For FMIN and FMAX, if at least one input is a signaling NaN, or if both
> inputs are quiet NaNs, the result is the canonical NaN.  If one operand
> is a quiet NaN and the other is not a NaN, the result is the non-NaN
> operand."
>
> suitably for the IEEE 754-2008 `minNum' and `maxNum' operations.
>
> However we only define `sminM3' and `smaxM3' standard RTL patterns to
> produce the FMIN and FMAX machine instructions, which in turn causes the
> `__builtin_fmin' and `__builtin_fmax' family of intrinsics to emit the
> corresponding libcalls rather than the relevant machine instructions.
> This is according to earlier revisions of the RISC-V ISA specification,
> which we however do not support anymore, as from commit 4b81528241ca
> ("RISC-V: Support version controling for ISA standard extensions").
>
> As from r20190608 of the RISC-V ISA specification (equivalent to version
> 2.2 of the "F" and "D" standard ISA extensions for single-precision and
> double-precision floating-point respectively) the definition of the FMIN
> and FMAX machine instructions has been updated[2]:
>
> "Defined the signed-zero behavior of FMIN.fmt and FMAX.fmt, and changed
> their behavior on signaling-NaN inputs to conform to the minimumNumber
> and maximumNumber operations in the proposed IEEE 754-201x
> specification."
>
> and specifically[3]:
>
> "Floating-point minimum-number and maximum-number instructions FMIN.S
> and FMAX.S write, respectively, the smaller or larger of rs1 and rs2 to
> rd.  For the purposes of these instructions only, the value -0.0 is
> considered to be less than the value +0.0.  If both inputs are NaNs, the
> result is the canonical NaN.  If only one operand is a NaN, the result
> is the non-NaN operand.  Signaling NaN inputs set the invalid operation
> exception flag, even when the result is not NaN."
>
> Consequently for forwards compatibility with r20190608+ hardware we
> cannot use the FMIN and FMAX machine instructions unconditionally even
> where the ISA level of r2.2 has been specified with the `-misa-spec=2.2'
> option where operation would be different between ISA revisions, that
> is the handling of signaling NaN inputs.
>
> Therefore provide new `fmin3' and `fmax3' patterns removing
> the need to emit libcalls with the `__builtin_fmin' and `__builtin_fmax'
> family of intrinsics, however limit them to where `-fno-signaling-nans'
> is in effect, deferring to other code generation strategies otherwise as
> applicable.  Use newly-defined UNSPECs as the operation codes so that
> the patterns are only ever used if referred to by their names, as there
> is no RTL expression defined for the IEEE 754-2008 `minNum' and `maxNum'
> operations.
>
> References:
>
> [1] "The RISC-V Instruction Set Manual, Volume I: User-Level ISA",
> Document Version 2.2, May 7, 2017, Section 8.3 "NaN Generation and
> Propagation", p. 48
>
> [1] "The RISC-V Instruction Set Manual, Volume I: Unprivileged ISA",
> Document Version 20190608-Base-Ratified, June 8, 2019, "Preface",
> p. ii
>
> [2] same, Section 11.6 "Single-Precision Floating-Point Computational
> Instructions", p. 66
>
> gcc/
> * config/riscv/riscv.md (UNSPEC_FMIN, UNSPEC_FMAX): New
> constants.
> (fmin3, fmax3): New insns.
>
> gcc/testsuite/
> * gcc.target/riscv/fmax-snan.c: New test.
> * gcc.target/riscv/fmax.c: New test.
> * gcc.target/riscv/fmaxf-snan.c: New test.
> * gcc.target/riscv/fmaxf.c: New test.
> * gcc.target/riscv/fmin-snan.c: New test.
> * gcc.target/riscv/fmin.c: New test.
> * gcc.target/riscv/fminf-snan.c: New test.
> * gcc.target/riscv/fminf.c: New test.
> * gcc.target/riscv/smax-ieee.c: New test.
> * gcc.target/riscv/smax.c: New test.
> * gcc.target/riscv/smaxf-ieee.c: New test.
> * gcc.target/riscv/smaxf.c: New test.
> * gcc.target/riscv/smin-ieee.c: New test.
> * gcc.target/riscv/smin.c: New test.
> * gcc.target/riscv/sminf-ieee.c: New test.
> * gcc.target/riscv/sminf.c: New test.
> ---
> On Mon, 28 Feb 2022, Jim Wilson wrote:
>
> > On Tue, Feb 8, 2022 at 4:35 AM Maciej W. Rozycki  wrote:
> >
> > > gcc/
> > > * config/riscv/riscv.md (UNSPEC_FMIN, UNSPEC_FMAX): New
> > > constants.
> > > (fmin3, fmax3): New insns.
> > > ...
> >
> >
> > I tried testing on some of the hardware I have.  Both the HiFive Unleashed
> > (2018) and HiFive Unmatched (2021) implement the current definition of
> > fmin/fmax.  But the Allwinner Nezha (2021) 

[committed 2/2] libstdc++: Add declarations to [PR105284]

2022-05-10 Thread Jonathan Wakely via Gcc-patches
Tested powerpc64le-linux, pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

PR libstdc++/105284
* include/std/iosfwd: Add declarations for  class
templates and typedefs.
* include/std/spanstream (basic_spanbuf, basic_ispanstream)
(basic_ospanstream, basic_spanstream): Remove default template
arguments.
* testsuite/27_io/headers/iosfwd/synopsis.cc: Add 
declarations.
* testsuite/27_io/headers/iosfwd/types.cc: Check 
default arguments.
---
 libstdc++-v3/include/std/iosfwd   | 23 +
 libstdc++-v3/include/std/spanstream   |  8 +--
 .../27_io/headers/iosfwd/synopsis.cc  | 13 +
 .../testsuite/27_io/headers/iosfwd/types.cc   | 50 +++
 4 files changed, 90 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/include/std/iosfwd b/libstdc++-v3/include/std/iosfwd
index c8c67c86c3b..ddf0c953856 100644
--- a/libstdc++-v3/include/std/iosfwd
+++ b/libstdc++-v3/include/std/iosfwd
@@ -225,6 +225,29 @@ _GLIBCXX_END_NAMESPACE_CXX11
 #endif
 #endif // C++20 && CXX11_ABI
 
+#if __cplusplus > 202002L
+  template>
+class basic_spanbuf;
+  template>
+class basic_ispanstream;
+  template>
+class basic_ospanstream;
+  template>
+class basic_spanstream;
+
+  using spanbuf = basic_spanbuf;
+  using ispanstream = basic_ispanstream;
+  using ospanstream = basic_ospanstream;
+  using spanstream  = basic_spanstream;
+
+#ifdef _GLIBCXX_USE_WCHAR_T
+  using wspanbuf = basic_spanbuf;
+  using wispanstream = basic_ispanstream;
+  using wospanstream = basic_ospanstream;
+  using wspanstream  = basic_spanstream;
+#endif
+#endif // C++23
+
   /** @}  */
 
 _GLIBCXX_END_NAMESPACE_VERSION
diff --git a/libstdc++-v3/include/std/spanstream 
b/libstdc++-v3/include/std/spanstream
index 000bda52a1e..5855b286efe 100644
--- a/libstdc++-v3/include/std/spanstream
+++ b/libstdc++-v3/include/std/spanstream
@@ -45,7 +45,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 #define __cpp_lib_spanstream 202106L
 
-template>
+template
   class basic_spanbuf
   : public basic_streambuf<_CharT, _Traits>
   {
@@ -218,7 +218,7 @@ template
 using spanbuf = basic_spanbuf;
 using wspanbuf = basic_spanbuf;
 
-template>
+template
   class basic_ispanstream
   : public basic_istream<_CharT, _Traits>
   {
@@ -310,7 +310,7 @@ template
 using ispanstream = basic_ispanstream;
 using wispanstream = basic_ispanstream;
 
-template>
+template
   class basic_ospanstream
   : public basic_ostream<_CharT, _Traits>
   {
@@ -378,7 +378,7 @@ template
 using ospanstream = basic_ospanstream;
 using wospanstream = basic_ospanstream;
 
-template>
+template
   class basic_spanstream
   : public basic_iostream<_CharT, _Traits>
   {
diff --git a/libstdc++-v3/testsuite/27_io/headers/iosfwd/synopsis.cc 
b/libstdc++-v3/testsuite/27_io/headers/iosfwd/synopsis.cc
index 48f733bf28a..467d63609bd 100644
--- a/libstdc++-v3/testsuite/27_io/headers/iosfwd/synopsis.cc
+++ b/libstdc++-v3/testsuite/27_io/headers/iosfwd/synopsis.cc
@@ -75,6 +75,12 @@ _GLIBCXX_END_NAMESPACE_CXX11
   typedef basic_ostringstream ostringstream;
   typedef basic_stringstream  stringstream;
 
+#if __cplusplus > 202002L
+  typedef basic_spanbuf spanbuf;
+  typedef basic_ispanstream ispanstream;
+  typedef basic_ospanstream ospanstream;
+  typedef basic_spanstream  spanstream;
+#endif
 
   typedef basic_filebuf  filebuf;
   typedef basic_ifstream ifstream;
@@ -96,6 +102,13 @@ _GLIBCXX_END_NAMESPACE_CXX11
   typedef basic_ostringstream wostringstream;
   typedef basic_stringstream  wstringstream;
 
+#if __cplusplus > 202002L
+  typedef basic_spanbuf wspanbuf;
+  typedef basic_ispanstream wispanstream;
+  typedef basic_ospanstream wospanstream;
+  typedef basic_spanstream  wspanstream;
+#endif
+
   typedef basic_filebuf  wfilebuf;
   typedef basic_ifstream wifstream;
   typedef basic_ofstream wofstream;
diff --git a/libstdc++-v3/testsuite/27_io/headers/iosfwd/types.cc 
b/libstdc++-v3/testsuite/27_io/headers/iosfwd/types.cc
index e2c9c9b8dfa..baf37e910af 100644
--- a/libstdc++-v3/testsuite/27_io/headers/iosfwd/types.cc
+++ b/libstdc++-v3/testsuite/27_io/headers/iosfwd/types.cc
@@ -115,6 +115,56 @@ static_assert(Same,
   >::value,
 "std::basic_stringstream has the correct default template 
argument");
 
+#if __cplusplus > 202002L
+using std::basic_spanbuf;
+
+static_assert(Same,
+  basic_spanbuf>
+  >::value,
+"std::basic_spanbuf has the correct default template argument");
+
+static_assert(Same,
+  basic_spanbuf>
+  >::value,
+"std::basic_spanbuf has the correct default template argument");
+
+using std::basic_ispanstream;
+
+static_assert(Same,
+  basic_ispanstream>
+  >::value,
+"std::basic_ispanstream has the correct default template argument");
+
+static_assert(Same,
+  basic_ispanstream>
+  >::value,
+

[committed 1/2] libstdc++: Add declarations to [PR105284]

2022-05-10 Thread Jonathan Wakely via Gcc-patches
Tested powerpc64le-linux, pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

PR libstdc++/105284
* include/std/iosfwd: Add declarations for  class
templates and typedefs.
* include/std/syncstream (basic_syncbuf, basic_osyncstream):
Remove default template arguments.
* testsuite/27_io/headers/iosfwd/synopsis.cc: New test.
* testsuite/27_io/headers/iosfwd/types.cc: New test.
---
 libstdc++-v3/include/std/iosfwd   |  18 ++
 libstdc++-v3/include/std/syncstream   |   6 +-
 .../27_io/headers/iosfwd/synopsis.cc  | 119 ++
 .../testsuite/27_io/headers/iosfwd/types.cc   | 214 ++
 4 files changed, 353 insertions(+), 4 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/27_io/headers/iosfwd/synopsis.cc
 create mode 100644 libstdc++-v3/testsuite/27_io/headers/iosfwd/types.cc

diff --git a/libstdc++-v3/include/std/iosfwd b/libstdc++-v3/include/std/iosfwd
index 2d79a131631..c8c67c86c3b 100644
--- a/libstdc++-v3/include/std/iosfwd
+++ b/libstdc++-v3/include/std/iosfwd
@@ -207,6 +207,24 @@ _GLIBCXX_END_NAMESPACE_CXX11
   /// Class for @c wchar_t mixed input and output file streams.
   typedef basic_fstream   wfstream;
 #endif
+
+#if __cplusplus >= 202002L && _GLIBCXX_USE_CXX11_ABI
+  template,
+   typename _Allocator = allocator<_CharT>>
+class basic_syncbuf;
+  template,
+   typename _Allocator = allocator<_CharT>>
+class basic_osyncstream;
+
+  using syncbuf = basic_syncbuf;
+  using osyncstream = basic_osyncstream;
+
+#ifdef _GLIBCXX_USE_WCHAR_T
+  using wsyncbuf = basic_syncbuf;
+  using wosyncstream = basic_osyncstream;
+#endif
+#endif // C++20 && CXX11_ABI
+
   /** @}  */
 
 _GLIBCXX_END_NAMESPACE_VERSION
diff --git a/libstdc++-v3/include/std/syncstream 
b/libstdc++-v3/include/std/syncstream
index 3cf2296f723..7a4f731ddd9 100644
--- a/libstdc++-v3/include/std/syncstream
+++ b/libstdc++-v3/include/std/syncstream
@@ -50,8 +50,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
-  template,
-   typename _Alloc = allocator<_CharT>>
+  template
 class basic_syncbuf : public __syncbuf_base<_CharT, _Traits>
 {
 public:
@@ -241,8 +240,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __mutex _M_mtx;
 };
 
-  template ,
-   typename _Alloc = allocator<_CharT>>
+  template 
 class basic_osyncstream : public basic_ostream<_CharT, _Traits>
 {
   using __ostream_type = basic_ostream<_CharT, _Traits>;
diff --git a/libstdc++-v3/testsuite/27_io/headers/iosfwd/synopsis.cc 
b/libstdc++-v3/testsuite/27_io/headers/iosfwd/synopsis.cc
new file mode 100644
index 000..48f733bf28a
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/headers/iosfwd/synopsis.cc
@@ -0,0 +1,119 @@
+// { dg-do compile }
+
+#include 
+
+namespace std
+{
+  // [iosfwd.syn]
+
+  template struct char_traits;
+  template<> struct char_traits;
+#if __cplusplus >= 202002L
+  template<> struct char_traits;
+#endif
+#if __cplusplus >= 201103L
+  template<> struct char_traits;
+  template<> struct char_traits;
+#endif
+  template<> struct char_traits;
+
+  template class allocator;
+
+  template
+class basic_ios;
+  template
+class basic_streambuf;
+  template
+class basic_istream;
+  template
+class basic_ostream;
+  template
+class basic_iostream;
+
+_GLIBCXX_BEGIN_NAMESPACE_CXX11
+  template
+class basic_stringbuf;
+  template
+class basic_istringstream;
+  template
+class basic_ostringstream;
+  template
+class basic_stringstream;
+_GLIBCXX_END_NAMESPACE_CXX11
+
+  template
+class basic_filebuf;
+  template
+class basic_ifstream;
+  template
+class basic_ofstream;
+  template
+class basic_fstream;
+
+#if __cplusplus >= 202002L && _GLIBCXX_USE_CXX11_ABI
+  template
+class basic_syncbuf;
+  template
+class basic_osyncstream;
+#endif
+
+  template
+class istreambuf_iterator;
+  template
+class ostreambuf_iterator;
+
+  typedef basic_iosios;
+  typedef basic_ios wios;
+
+  typedef basic_streambuf streambuf;
+  typedef basic_istream   istream;
+  typedef basic_ostream   ostream;
+  typedef basic_iostream  iostream;
+
+  typedef basic_stringbuf stringbuf;
+  typedef basic_istringstream istringstream;
+  typedef basic_ostringstream ostringstream;
+  typedef basic_stringstream  stringstream;
+
+
+  typedef basic_filebuf  filebuf;
+  typedef basic_ifstream ifstream;
+  typedef basic_ofstream ofstream;
+  typedef basic_fstream  fstream;
+
+#if __cplusplus >= 202002L && _GLIBCXX_USE_CXX11_ABI
+  typedef basic_syncbuf syncbuf;
+  typedef basic_osyncstream osyncstream;
+#endif
+
+  typedef basic_streambuf wstreambuf;
+  typedef basic_istream   wistream;
+  typedef basic_ostream   wostream;
+  typedef basic_iostream  wiostream;
+
+  typedef basic_stringbuf wstringbuf;
+  typedef basic_istringstream wistringstream;
+  typedef basic_ostringstream wostringstream;
+  typedef 

Re: [PATCH] OpenMP, C++: Add template support for the has_device_addr clause.

2022-05-10 Thread Marcel Vollweiler

Hi Jakub,


diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 0cb17a6..452ecfd 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -8534,11 +8534,14 @@ finish_omp_clauses (tree clauses, enum 
c_omp_region_type ort)
 {
   if (handle_omp_array_sections (c, ort))
 remove = true;
+  else if (TREE_CODE (TREE_CHAIN (t)) == PARM_DECL)
+t = TREE_CHAIN (t);
   else
 {
   t = OMP_CLAUSE_DECL (c);
   while (TREE_CODE (t) == INDIRECT_REF
- || TREE_CODE (t) == ARRAY_REF)
+ || TREE_CODE (t) == ARRAY_REF
+ || TREE_CODE (t) == NON_LVALUE_EXPR)
 t = TREE_OPERAND (t, 0);
 }
 }


This is wrong.
When processing_template_decl, handle_omp_array_sections often punts, keeps
things as is because if something is dependent, we can't do much about it.
The else if (TREE_CODE (TREE_CHAIN (t)) == PARM_DECL) is obviously wrong,
there is really nothing specific about PARM_DECLs (just that you used
exactly that in the testcase), nor about array section with exactly one
dimension.  What is done elsewhere is look through all TREE_LISTs to find
the base expression, and if that expression is a VAR_DECL/PARM_DECL, nice,
we can do further processing, if processing_template_decl and it is
something different, just defer and otherwise error out.

So I think you want:
--- gcc/cp/semantics.cc.jj2022-05-05 11:56:16.160443828 +0200
+++ gcc/cp/semantics.cc   2022-05-05 15:52:39.651211448 +0200
@@ -8553,14 +8553,23 @@ finish_omp_clauses (tree clauses, enum c
else
  {
t = OMP_CLAUSE_DECL (c);
+   if (TREE_CODE (t) == TREE_LIST)
+ {
+   while (TREE_CODE (t) == TREE_LIST)
+ t = TREE_CHAIN (t);
+ }
while (TREE_CODE (t) == INDIRECT_REF
   || TREE_CODE (t) == ARRAY_REF)
  t = TREE_OPERAND (t, 0);
  }
  }
-   bitmap_set_bit (_on_device_head, DECL_UID (t));
if (VAR_P (t) || TREE_CODE (t) == PARM_DECL)
- cxx_mark_addressable (t);
+ {
+   bitmap_set_bit (_on_device_head, DECL_UID (t));
+   if (!processing_template_decl
+   && !cxx_mark_addressable (t))
+ remove = true;
+ }
goto check_dup_generic_t;

  case OMP_CLAUSE_USE_DEVICE_ADDR:
instead, as I said look through the TREE_LISTs, then only use DECL_UID
on actual VAR_DECLs/PARM_DECLs not random other expressions and
never call cxx_mark_addressable when processing_template_decl (and remove
clause if cxx_mark_addressable fails).
Note, check_dup_generic_t will do among other things:
   if (!VAR_P (t) && TREE_CODE (t) != PARM_DECL
   && (!field_ok || TREE_CODE (t) != FIELD_DECL))
 {
   if (processing_template_decl && TREE_CODE (t) != OVERLOAD)
 break;
... error ...
  }
so with processing_template_decl it will just defer it for later,
but otherwise if t is something invalid it will diagnose it.
But one really shouldn't rely on t being VAR_DECL/PARM_DECL before
that checking is done...

With your pt.cc change and my semantics.cc change, all your new testcases
look fine.


Thank you very much for your detailed explanation. That helped me a lot for my
understanding!
I adjusted the code accordingly.


diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index f570daa..b1bb5be 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -10285,7 +10285,8 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq 
*pre_p,
 case OMP_CLAUSE_HAS_DEVICE_ADDR:
   decl = OMP_CLAUSE_DECL (c);
   while (TREE_CODE (decl) == INDIRECT_REF
- || TREE_CODE (decl) == ARRAY_REF)
+ || TREE_CODE (decl) == ARRAY_REF
+ || TREE_CODE (decl) == NON_LVALUE_EXPR)
 decl = TREE_OPERAND (decl, 0);
   flags = GOVD_EXPLICIT;
   goto do_add_decl;
@@ -11443,7 +11444,8 @@ gimplify_adjust_omp_clauses (gimple_seq *pre_p, 
gimple_seq body, tree *list_p,
 case OMP_CLAUSE_HAS_DEVICE_ADDR:
   decl = OMP_CLAUSE_DECL (c);
   while (TREE_CODE (decl) == INDIRECT_REF
- || TREE_CODE (decl) == ARRAY_REF)
+ || TREE_CODE (decl) == ARRAY_REF
+ || TREE_CODE (decl) == NON_LVALUE_EXPR)
 decl = TREE_OPERAND (decl, 0);
   n = splay_tree_lookup (ctx->variables, (splay_tree_key) decl);
   remove = n == NULL || !(n->value & GOVD_SEEN);
diff --git a/gcc/omp-low.cc b/gcc/omp-low.cc
index 77176ef..30cc9b6 100644
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ -1384,7 +1384,8 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
 }
   else if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_HAS_DEVICE_ADDR)
 {
-  if (TREE_CODE (decl) == INDIRECT_REF)
+  if 

Re: [PATCH] libiberty: stop using PTR macro.

2022-05-10 Thread Martin Liška
On 5/10/22 16:20, Alan Modra wrote:
> On Tue, May 10, 2022 at 10:56:22AM +0200, Martin Liška wrote:
> 
>> diff --git a/libiberty/hashtab.c b/libiberty/hashtab.c
> 
>> @@ -457,15 +457,15 @@ htab_empty (htab_t htab)
>>else if (htab->free_with_arg_f != NULL)
>>  (*htab->free_with_arg_f) (htab->alloc_arg, htab->entries);
>>if (htab->alloc_with_arg_f != NULL)
>> -htab->entries = (PTR *) (*htab->alloc_with_arg_f) (htab->alloc_arg, 
>> nsize,
>> -   sizeof (PTR *));
>> +htab->entries = (void **) (*htab->alloc_with_arg_f) (htab->alloc_arg, 
>> nsize,
>> +   sizeof (void **));
> 
> Here, and below, the code should really be using "sizeof (void *)".
> You may as well fix that nit while you're at it.  Also, indentation
> looks wrong.
> 
>>else
>> -htab->entries = (PTR *) (*htab->alloc_f) (nsize, sizeof (PTR *));
>> +htab->entries = (void **) (*htab->alloc_f) (nsize, sizeof (void **));
>>   htab->size = nsize;
>>   htab->size_prime_index = nindex;
>>  }
>>else
>> -memset (entries, 0, size * sizeof (PTR));
>> +memset (entries, 0, size * sizeof (void *));
>>htab->n_deleted = 0;
>>htab->n_elements = 0;
>>  }
> 
>> @@ -543,10 +543,10 @@ htab_expand (htab_t htab)
>>  }
>>  
>>if (htab->alloc_with_arg_f != NULL)
>> -nentries = (PTR *) (*htab->alloc_with_arg_f) (htab->alloc_arg, nsize,
>> -  sizeof (PTR *));
>> +nentries = (void **) (*htab->alloc_with_arg_f) (htab->alloc_arg, nsize,
>> +  sizeof (void **));
>>else
>> -nentries = (PTR *) (*htab->alloc_f) (nsize, sizeof (PTR *));
>> +nentries = (void **) (*htab->alloc_f) (nsize, sizeof (void **));
>>if (nentries == NULL)
>>  return 0;
>>htab->entries = nentries;
> 
> Here too.
> 

Thanks for the comments, I'm going to push the following patch.

MartinFrom 5dac43b43c3999f94b451cd7925e24d8e7c38a7a Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 10 May 2022 17:31:24 +0200
Subject: [PATCH] libiberty: fix type in allocation

The allocation function alloc_f is called for nsize
items where each is of type void *.

libiberty/ChangeLog:

	* hashtab.c (htab_empty): Use void * type instead of void **.
	(htab_expand): Likewise.

Co-Authored-By: Alan Modra 
---
 libiberty/hashtab.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libiberty/hashtab.c b/libiberty/hashtab.c
index f7621cd47e5..470d3e66c32 100644
--- a/libiberty/hashtab.c
+++ b/libiberty/hashtab.c
@@ -458,9 +458,9 @@ htab_empty (htab_t htab)
 	(*htab->free_with_arg_f) (htab->alloc_arg, htab->entries);
   if (htab->alloc_with_arg_f != NULL)
 	htab->entries = (void **) (*htab->alloc_with_arg_f) (htab->alloc_arg, nsize,
-		   sizeof (void **));
+			 sizeof (void *));
   else
-	htab->entries = (void **) (*htab->alloc_f) (nsize, sizeof (void **));
+	htab->entries = (void **) (*htab->alloc_f) (nsize, sizeof (void *));
  htab->size = nsize;
  htab->size_prime_index = nindex;
 }
@@ -544,9 +544,9 @@ htab_expand (htab_t htab)
 
   if (htab->alloc_with_arg_f != NULL)
 nentries = (void **) (*htab->alloc_with_arg_f) (htab->alloc_arg, nsize,
-		  sizeof (void **));
+		sizeof (void *));
   else
-nentries = (void **) (*htab->alloc_f) (nsize, sizeof (void **));
+nentries = (void **) (*htab->alloc_f) (nsize, sizeof (void *));
   if (nentries == NULL)
 return 0;
   htab->entries = nentries;
-- 
2.36.0



Re: [PATCH] AArch64: Improve address rematerialization costs

2022-05-10 Thread Richard Sandiford via Gcc-patches
Wilco Dijkstra  writes:
> Hi Richard,
>
>>> There isn't really a better way of doing this within the existing costing 
>>> code.
>>
>> Yeah, I was wondering whether we could change something there.
>> ADRP+LDR is logically more expensive than a single LDR, especially
>> when optimising for size, so I think it's reasonable for the rtx_costs
>> to say so.  But that doesn't/shouldn't mean that spilling is better
>> (for either size or speed).
>>
>> So it feels like there's something missing in the way the costs are
>> being applied.
>
> Calculating accurate spill costs is hard. Spill optimization is done later, so
> until then you can't know the actual cost of a spill decision already made.
> Spills are also more expensive than you think due to store latency, more
> dirty cachelines etc. There is little benefit in lifting an ADRP to the start 
> of
> a function but keep ADD/LDR close to references. Basically ADRP/MOV are
> very cheap, so it's a waste to allocate these to long-lived registers.
>
> Given that there are significant codesize and performance improvements,
> it is clear that doing more rematerialization is better even in cases where it
> takes 2 instructions to recompute the address. Binaries show a significant
> reduction in stack-based loads and stores.

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

Thanks,
Richard


[PATCH] aarch64: Fix va_arg alignment handling (PR target/105549)

2022-05-10 Thread Christophe Lyon via Gcc-patches
While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
caused by DFP types handling. These tests are generated during 'make
check' and enabling DFP made generation different (not sure if new
non-DFP tests are generated, or if existing ones are generated
differently, the tests in question are huge and difficult to compare).

Anyway, I reduced the problem to what I attach at the end of the new
gcc.target/aarch64/aapcs64/va_arg-17.c test and rewrote it in the same
scheme as other va_arg* AArch64 tests.

This is a tough case mixing bitfields and alignment, where
aarch64_gimplify_va_arg_expr did not follow the exact same rule as
aarch64_layout_arg. When the va_arg parameter uses only one general
register, we do not want to introduce double-word alignment.

The fix is thus very small, and this patch adds a new test
(va_arg-17.c), which contains the reduced offending testcase from
struct-layout-1.exp for reference.

2022-04-25  Christophe Lyon  

gcc/
PR target/105549
* config/aarch64/aarch64.cc (aarch64_gimplify_va_arg_expr): Fix
alignment of single-register parameters.

gcc/testssuite/
PR target/105549
* gcc.target/aarch64/aapcs64/va_arg-17.c: New.
---
 gcc/config/aarch64/aarch64.cc |   4 +-
 .../gcc.target/aarch64/aapcs64/va_arg-17.c| 105 ++
 2 files changed, 108 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-17.c

diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index f650abbc4ce..bd855758778 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -19667,7 +19667,9 @@ aarch64_gimplify_va_arg_expr (tree valist, tree type, 
gimple_seq *pre_p,
   rsize = ROUND_UP (size, UNITS_PER_WORD);
   nregs = rsize / UNITS_PER_WORD;
 
-  if (align > 8)
+  /* Align on double-word only if we need 2 registers, like in
+aarch64_layout_arg.  */
+  if (align > 8 && nregs == 2)
{
  if (abi_break && warn_psabi)
inform (input_location, "parameter passing for argument of type "
diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-17.c 
b/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-17.c
new file mode 100644
index 000..24895c3ab48
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-17.c
@@ -0,0 +1,105 @@
+/* Test AAPCS64 layout and __builtin_va_arg.
+
+   This test covers a corner case where a composite type parameter fits in one
+   register: we do not need a double-word alignment when accessing it in the
+   va_arg stack area.  */
+
+/* { dg-do run { target aarch64*-*-* } } */
+
+#ifndef IN_FRAMEWORK
+#define AAPCS64_TEST_STDARG
+#define TESTFILE "va_arg-17.c"
+#include "type-def.h"
+
+enum E6 { e6_0, e6_1, e6_2, e6_3, e6_65533 = 65533, e6_65534, e6_65535 };
+typedef enum E6 Tal16E6 __attribute__((aligned (16)));
+typedef unsigned int Tuint;
+
+int fails;
+
+union S2844 {
+  Tuint a:10) - 1) & 31) + 1);
+  Tal16E6 __attribute__((aligned (2), packed)) b:31;
+  struct{}c[0];
+} ;
+union S2844 s2844;
+union S2844 a2844[5];
+
+#define HAS_DATA_INIT_FUNC
+void init_data ()
+{
+  memset (, '\0', sizeof (s2844));
+  memset (a2844, '\0', sizeof (a2844));
+  s2844.a = 799U;
+  a2844[2].a = 586U;
+}
+
+#include "abitest.h"
+#else
+  ARG   (int  , 1, W0 , LAST_NAMED_ARG_ID)
+  DOTS
+  ANON_PROMOTED  (float   , 1.0f, double, 1.0, D0, 1)
+  ANON  (union S2844  , s2844, X1 , 2)
+  ANON  (long long, 2LL  , X2 , 3)
+  ANON  (union  S2844 , a2844[2] , X3 , 4)
+  LAST_ANON (union  S2844 , a2844[2] , X4 , 5)
+#endif
+
+#if 0
+  /* This test is derived from a case generated by struct-layout-1.exp:  */
+
+enum E6 { e6_0, e6_1, e6_2, e6_3, e6_65533 = 65533, e6_65534, e6_65535 };
+typedef enum E6 Tal16E6 __attribute__((aligned (16)));
+typedef unsigned int Tuint;
+
+int fails;
+
+union S2844 {
+  Tuint a:10) - 1) & 31) + 1);
+  Tal16E6 __attribute__((aligned (2), packed)) b:31;
+  struct{}c[0];
+} ;
+union S2844 s2844;
+union S2844 a2844[5];
+
+typedef __builtin_va_list __gnuc_va_list;
+typedef __gnuc_va_list va_list;
+
+void check2844va (int z, ...) {
+  union S2844 arg, *p;
+  va_list ap;
+
+  __builtin_va_start(ap,z);
+  if (__builtin_va_arg(ap,double) != 1.0)
+printf ("fail %d.%d\n", 2844, 0), ++fails;
+
+  p = 
+  arg = __builtin_va_arg(ap,union S2844);  /* This would fail.  */
+  if (p->a != arg.a)
+printf ("fail %d.%d\n", 2844, 1), ++fails;
+
+  if (__builtin_va_arg(ap,long long) != 3LL)
+printf ("fail %d.%d\n", 2844, 2), ++fails;
+
+  p = [2];
+  arg = __builtin_va_arg(ap,union S2844);  /* This would fail.  */
+  if (p->a != arg.a)
+printf ("fail %d.%d\n", 2844, 3), ++fails;
+
+  arg = __builtin_va_arg(ap,union S2844);  /* This would fail.  */
+  if (p->a != arg.a)
+printf ("fail %d.%d\n", 2844, 4), ++fails;
+
+  

[PATCH][pushed] libiberty: fix bad replacement.

2022-05-10 Thread Martin Liška
Pushed as obvious.

Martin

libiberty/ChangeLog:

* random.c: Remove 'define PTR'.
---
 libiberty/random.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libiberty/random.c b/libiberty/random.c
index be8819dd6b8..cd0b7399e73 100644
--- a/libiberty/random.c
+++ b/libiberty/random.c
@@ -68,12 +68,10 @@ control over the state of the random number generator.
 #defineLONG_MAX   ((long)(ULONG_MAX >> 1))   /* 0x7FFF for 
32-bits*/
 
 #ifdef __STDC__
-#  define void *void *
 #  ifndef NULL
 #define NULL (void *) 0
 #  endif
 #else
-#  define void *char *
 #  ifndef NULL
 #define NULL (void *) 0
 #  endif
-- 
2.36.0



Re: [PATCH] AArch64: Improve address rematerialization costs

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

>> There isn't really a better way of doing this within the existing costing 
>> code.
>
> Yeah, I was wondering whether we could change something there.
> ADRP+LDR is logically more expensive than a single LDR, especially
> when optimising for size, so I think it's reasonable for the rtx_costs
> to say so.  But that doesn't/shouldn't mean that spilling is better
> (for either size or speed).
>
> So it feels like there's something missing in the way the costs are
> being applied.

Calculating accurate spill costs is hard. Spill optimization is done later, so
until then you can't know the actual cost of a spill decision already made.
Spills are also more expensive than you think due to store latency, more
dirty cachelines etc. There is little benefit in lifting an ADRP to the start of
a function but keep ADD/LDR close to references. Basically ADRP/MOV are
very cheap, so it's a waste to allocate these to long-lived registers.

Given that there are significant codesize and performance improvements,
it is clear that doing more rematerialization is better even in cases where it
takes 2 instructions to recompute the address. Binaries show a significant
reduction in stack-based loads and stores.

Cheers,
Wilco



Re: [PATCH] libiberty: stop using PTR macro.

2022-05-10 Thread Alan Modra via Gcc-patches
On Tue, May 10, 2022 at 10:56:22AM +0200, Martin Liška wrote:

> diff --git a/libiberty/hashtab.c b/libiberty/hashtab.c

> @@ -457,15 +457,15 @@ htab_empty (htab_t htab)
>else if (htab->free_with_arg_f != NULL)
>   (*htab->free_with_arg_f) (htab->alloc_arg, htab->entries);
>if (htab->alloc_with_arg_f != NULL)
> - htab->entries = (PTR *) (*htab->alloc_with_arg_f) (htab->alloc_arg, 
> nsize,
> -sizeof (PTR *));
> + htab->entries = (void **) (*htab->alloc_with_arg_f) (htab->alloc_arg, 
> nsize,
> +sizeof (void **));

Here, and below, the code should really be using "sizeof (void *)".
You may as well fix that nit while you're at it.  Also, indentation
looks wrong.

>else
> - htab->entries = (PTR *) (*htab->alloc_f) (nsize, sizeof (PTR *));
> + htab->entries = (void **) (*htab->alloc_f) (nsize, sizeof (void **));
>   htab->size = nsize;
>   htab->size_prime_index = nindex;
>  }
>else
> -memset (entries, 0, size * sizeof (PTR));
> +memset (entries, 0, size * sizeof (void *));
>htab->n_deleted = 0;
>htab->n_elements = 0;
>  }

> @@ -543,10 +543,10 @@ htab_expand (htab_t htab)
>  }
>  
>if (htab->alloc_with_arg_f != NULL)
> -nentries = (PTR *) (*htab->alloc_with_arg_f) (htab->alloc_arg, nsize,
> -   sizeof (PTR *));
> +nentries = (void **) (*htab->alloc_with_arg_f) (htab->alloc_arg, nsize,
> +   sizeof (void **));
>else
> -nentries = (PTR *) (*htab->alloc_f) (nsize, sizeof (PTR *));
> +nentries = (void **) (*htab->alloc_f) (nsize, sizeof (void **));
>if (nentries == NULL)
>  return 0;
>htab->entries = nentries;

Here too.

-- 
Alan Modra
Australia Development Lab, IBM


Re: [PATCH 2/2] c++: Remove SET_PACK_EXPANSION_PATTERN / SET_ARGUMENT_PACK_ARGS

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

On 5/10/22 09:40, Patrick Palka wrote:

Unlike in C, in C++ the conditional operator yields an lvalue if both
branches are lvalues, so we can just assign to PACK_EXPANSION_PATTERN
and ARGUMENT_PACK_ARGS directly.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?


OK.


gcc/cp/ChangeLog:

* coroutines.cc (instantiate_coro_traits): Adjust accordingly.
* cp-tree.h (SET_PACK_EXPANSION_PATTERN): Remove.
(SET_ARGUMENT_PACK_ARGS): Remove.
* module.cc (trees_in::tree_node): Adjust accordingly.
* parser.cc (make_char_string_pack): Likewise.
(make_string_pack): Likewise.
* pt.cc (make_pack_expansion): Likewise.
(template_parm_to_arg): Likewise.
(coerce_template_parameter_pack): Likewise.
(extract_fnparm_pack): Likewise.
(extract_locals_r): Likewise.
(make_argument_pack): Likewise.
(tsubst_argument_pack): Likewise.
(lookup_init_capture_pack): Likewise.
(type_unification_real): Likewise.
(unify_pack_expansion): Likewise.
(tsubst_initializer_list): Likewise.
---
  gcc/cp/coroutines.cc |  2 +-
  gcc/cp/cp-tree.h | 16 
  gcc/cp/module.cc |  4 ++--
  gcc/cp/parser.cc |  4 ++--
  gcc/cp/pt.cc | 30 +++---
  5 files changed, 20 insertions(+), 36 deletions(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 1d886b31c77..edb3b706ddc 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -344,7 +344,7 @@ instantiate_coro_traits (tree fndecl, location_t kw)
  }
  
tree argtypepack = cxx_make_type (TYPE_ARGUMENT_PACK);

-  SET_ARGUMENT_PACK_ARGS (argtypepack, argtypes);
+  ARGUMENT_PACK_ARGS (argtypepack) = argtypes;
  
tree targ = make_tree_vec (2);

TREE_VEC_ELT (targ, 0) = TREE_TYPE (functyp);
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 29fc0e5f829..cfda8337ad8 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -3903,14 +3903,6 @@ struct GTY(()) lang_decl {
(TREE_CODE (PACK_EXPANSION_CHECK (NODE)) == TYPE_PACK_EXPANSION \
 ? TREE_TYPE (NODE) : TREE_OPERAND (NODE, 0))
  
-/* Sets the type or expression pattern for a TYPE_PACK_EXPANSION or

-   EXPR_PACK_EXPANSION.  */
-#define SET_PACK_EXPANSION_PATTERN(NODE,VALUE)  \
-  if (TREE_CODE (PACK_EXPANSION_CHECK (NODE)) == TYPE_PACK_EXPANSION)  \
-TREE_TYPE (NODE) = VALUE;   \
-  else  \
-TREE_OPERAND (NODE, 0) = VALUE
-
  /* The list of parameter packs used in the PACK_EXPANSION_* node. The
 TREE_VALUE of each TREE_LIST contains the parameter packs.  */
  #define PACK_EXPANSION_PARAMETER_PACKS(NODE)  \
@@ -3963,14 +3955,6 @@ struct GTY(()) lang_decl {
(TREE_CODE (ARGUMENT_PACK_CHECK (NODE)) == TYPE_ARGUMENT_PACK \
 ? TREE_TYPE (NODE) : TREE_OPERAND (NODE, 0))
  
-/* Set the arguments stored in an argument pack. VALUE must be a

-   TREE_VEC.  */
-#define SET_ARGUMENT_PACK_ARGS(NODE,VALUE) \
-  if (TREE_CODE (ARGUMENT_PACK_CHECK (NODE)) == TYPE_ARGUMENT_PACK)  \
-TREE_TYPE (NODE) = VALUE;   \
-  else  \
-TREE_OPERAND (NODE, 0) = VALUE
-
  /* Whether the argument pack is "incomplete", meaning that more
 arguments can still be deduced. Incomplete argument packs are only
 used when the user has provided an explicit template argument list
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index bd4771bef72..27b8f64ce75 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -9338,7 +9338,7 @@ trees_in::tree_node (bool is_use)
if (!get_overrun ())
  {
tree pack = cxx_make_type (TYPE_ARGUMENT_PACK);
-   SET_ARGUMENT_PACK_ARGS (pack, res);
+   ARGUMENT_PACK_ARGS (pack) = res;
res = pack;
  }
break;
@@ -9351,7 +9351,7 @@ trees_in::tree_node (bool is_use)
{
  tree expn = cxx_make_type (TYPE_PACK_EXPANSION);
  SET_TYPE_STRUCTURAL_EQUALITY (expn);
- SET_PACK_EXPANSION_PATTERN (expn, res);
+ PACK_EXPANSION_PATTERN (expn) = res;
  PACK_EXPANSION_PARAMETER_PACKS (expn) = param_packs;
  PACK_EXPANSION_LOCAL_P (expn) = local;
  res = expn;
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 5071c030f53..4ed9feaa427 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -4649,7 +4649,7 @@ make_char_string_pack (tree value)
  }
  
/* Build the argument packs.  */

-  SET_ARGUMENT_PACK_ARGS (argpack, charvec);
+  ARGUMENT_PACK_ARGS (argpack) = charvec;
  
TREE_VEC_ELT (argvec, 0) = argpack;
  
@@ -4684,7 +4684,7 @@ make_string_pack (tree value)

double_int::from_buffer (str + i * sz, sz));
  
/* Build the argument packs.  */

-  SET_ARGUMENT_PACK_ARGS (argpack, 

Re: [PATCH 1/2] c++: Harden *_PACK_EXPANSION and *_ARGUMENT_PACK macros

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

On 5/10/22 09:40, Patrick Palka wrote:

The accessor macros for TYPE_PACK_EXPANSION/EXPR_PACK_EXPANSION
and TYPE_ARGUMENT_PACK/NONTYPE_ARGUMENT_PACK should check the
tree code of the argument.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?


OK.


gcc/cp/ChangeLog:

* cp-tree.h (PACK_EXPANSION_CHECK): Define.
(PACK_EXPANSION_PATTERN): Use PACK_EXPANSION_CHECK.
(SET_PACK_EXPANSION_PATTERN): Likewise.
(PACK_EXPANSION_PARAMETER_PACKS): Likewise.
(PACK_EXPANSION_EXTRA_ARGS): Likewise.
(PACK_EXPANSION_LOCAL_P): Likewise.
(PACK_EXPANSION_SIZEOF_P): Likewise.
(PACK_EXPANSION_AUTO_P): Likewise.
(PACK_EXPANSION_FORCE_EXTRA_ARGS_P): Likewise.
(ARGUMENT_PACK_CHECK): Define.
(ARGUMENT_PACK_ARGS): Use ARGUMENT_PACK_CHECK.
(SET_ARGUMENT_PACK_ARGS): Likewise.
* parser.c (cp_parser_sizeof_pack): Check for error_mark_node
before setting PACK_EXPANSION_SIZEOF_P.
---
  gcc/cp/cp-tree.h | 34 ++
  gcc/cp/parser.cc |  3 ++-
  2 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 8a5057a4dff..29fc0e5f829 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -3894,16 +3894,19 @@ struct GTY(()) lang_decl {
(TREE_CODE (NODE) == TYPE_PACK_EXPANSION \
 || TREE_CODE (NODE) == EXPR_PACK_EXPANSION)
  
+#define PACK_EXPANSION_CHECK(NODE) \

+  TREE_CHECK2 (NODE, TYPE_PACK_EXPANSION, EXPR_PACK_EXPANSION)
+
  /* Extracts the type or expression pattern from a TYPE_PACK_EXPANSION or
 EXPR_PACK_EXPANSION.  */
  #define PACK_EXPANSION_PATTERN(NODE)\
-  (TREE_CODE (NODE) == TYPE_PACK_EXPANSION ? TREE_TYPE (NODE)\
-   : TREE_OPERAND (NODE, 0))
+  (TREE_CODE (PACK_EXPANSION_CHECK (NODE)) == TYPE_PACK_EXPANSION \
+   ? TREE_TYPE (NODE) : TREE_OPERAND (NODE, 0))
  
  /* Sets the type or expression pattern for a TYPE_PACK_EXPANSION or

 EXPR_PACK_EXPANSION.  */
  #define SET_PACK_EXPANSION_PATTERN(NODE,VALUE)  \
-  if (TREE_CODE (NODE) == TYPE_PACK_EXPANSION)  \
+  if (TREE_CODE (PACK_EXPANSION_CHECK (NODE)) == TYPE_PACK_EXPANSION)  \
  TREE_TYPE (NODE) = VALUE;   \
else  \
  TREE_OPERAND (NODE, 0) = VALUE
@@ -3911,7 +3914,7 @@ struct GTY(()) lang_decl {
  /* The list of parameter packs used in the PACK_EXPANSION_* node. The
 TREE_VALUE of each TREE_LIST contains the parameter packs.  */
  #define PACK_EXPANSION_PARAMETER_PACKS(NODE)  \
-  *(TREE_CODE (NODE) == EXPR_PACK_EXPANSION\
+  *(TREE_CODE (PACK_EXPANSION_CHECK (NODE)) == EXPR_PACK_EXPANSION \
  ? _OPERAND (NODE, 1) \
  : _MIN_VALUE_RAW (TYPE_PACK_EXPANSION_CHECK (NODE)))
  
@@ -3922,22 +3925,26 @@ struct GTY(()) lang_decl {

 are enclosing functions that provided function parameter packs we'll need
 to map appropriately.  */
  #define PACK_EXPANSION_EXTRA_ARGS(NODE)   \
-  *(TREE_CODE (NODE) == TYPE_PACK_EXPANSION\
+  *(TREE_CODE (PACK_EXPANSION_CHECK (NODE)) == TYPE_PACK_EXPANSION \
  ? _MAX_VALUE_RAW (NODE)  \
  : _OPERAND ((NODE), 2))
  
  /* True iff this pack expansion is within a function context.  */

-#define PACK_EXPANSION_LOCAL_P(NODE) TREE_LANG_FLAG_0 (NODE)
+#define PACK_EXPANSION_LOCAL_P(NODE) \
+  TREE_LANG_FLAG_0 (PACK_EXPANSION_CHECK (NODE))
  
  /* True iff this pack expansion is for sizeof  */

-#define PACK_EXPANSION_SIZEOF_P(NODE) TREE_LANG_FLAG_1 (NODE)
+#define PACK_EXPANSION_SIZEOF_P(NODE) \
+  TREE_LANG_FLAG_1 (PACK_EXPANSION_CHECK (NODE))
  
  /* True iff this pack expansion is for auto... in lambda init-capture.  */

-#define PACK_EXPANSION_AUTO_P(NODE) TREE_LANG_FLAG_2 (NODE)
+#define PACK_EXPANSION_AUTO_P(NODE) \
+  TREE_LANG_FLAG_2 (PACK_EXPANSION_CHECK (NODE))
  
  /* True if we must use PACK_EXPANSION_EXTRA_ARGS and avoid partial

 instantiation of this pack expansion.  */
-#define PACK_EXPANSION_FORCE_EXTRA_ARGS_P(NODE) TREE_LANG_FLAG_3 (NODE)
+#define PACK_EXPANSION_FORCE_EXTRA_ARGS_P(NODE) \
+  TREE_LANG_FLAG_3 (PACK_EXPANSION_CHECK (NODE))
  
  /* True iff the wildcard can match a template parameter pack.  */

  #define WILDCARD_PACK_P(NODE) TREE_LANG_FLAG_0 (NODE)
@@ -3947,16 +3954,19 @@ struct GTY(()) lang_decl {
(TREE_CODE (NODE) == TYPE_ARGUMENT_PACK  \
 || TREE_CODE (NODE) == NONTYPE_ARGUMENT_PACK)
  
+#define ARGUMENT_PACK_CHECK(NODE) \

+  TREE_CHECK2 (NODE, TYPE_ARGUMENT_PACK, NONTYPE_ARGUMENT_PACK)
+
  /* The arguments stored in an argument pack. Arguments are stored in a
 TREE_VEC, which may have length zero.  */
  #define ARGUMENT_PACK_ARGS(NODE)   \
-  (TREE_CODE (NODE) == TYPE_ARGUMENT_PACK? TREE_TYPE (NODE)\
-   : TREE_OPERAND (NODE, 0))
+  (TREE_CODE (ARGUMENT_PACK_CHECK (NODE)) == TYPE_ARGUMENT_PACK \
+   ? TREE_TYPE (NODE) 

Re: [PATCH] Remove non-ANSI C macros in ansidecl.h.

2022-05-10 Thread Martin Liška
On 5/10/22 16:09, Alan Modra wrote:
> On Tue, May 10, 2022 at 10:57:47AM +0200, Martin Liška wrote:
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> @Alan: Are you fine with the change from binutils/gdb perspective?
> 
> I'm fine if this isn't going into the binutils-gdb repo immediately.

Sure.

I've just installed the change:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=137da38377eb4ff53a71b199802a22d28c12d077

> There are occurrences of PTR in the cgen generated parts of opcodes,
> sim, and even gdb.  I have a few patches I haven't yet committed.

So once you're done, please pull the referenced commit change.

Cheers,
Martin



Re: [PATCH] Remove non-ANSI C macros in ansidecl.h.

2022-05-10 Thread Alan Modra via Gcc-patches
On Tue, May 10, 2022 at 10:57:47AM +0200, Martin Liška wrote:
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> @Alan: Are you fine with the change from binutils/gdb perspective?

I'm fine if this isn't going into the binutils-gdb repo immediately.
There are occurrences of PTR in the cgen generated parts of opcodes,
sim, and even gdb.  I have a few patches I haven't yet committed.

-- 
Alan Modra
Australia Development Lab, IBM


[RESEND][committed v4] RISC-V: Provide `fmin'/`fmax' RTL patterns

2022-05-10 Thread Maciej W. Rozycki
As at r2.2 of the RISC-V ISA specification[1] (equivalent to version 2.0 
of the "F" and "D" standard architecture extensions for single-precision 
and double-precision floating-point respectively) the FMIN and FMAX 
machine instructions fully match our requirement for the `fminM3' and 
`fmaxM3' standard RTL patterns:

"For FMIN and FMAX, if at least one input is a signaling NaN, or if both 
inputs are quiet NaNs, the result is the canonical NaN.  If one operand 
is a quiet NaN and the other is not a NaN, the result is the non-NaN 
operand."

suitably for the IEEE 754-2008 `minNum' and `maxNum' operations.

However we only define `sminM3' and `smaxM3' standard RTL patterns to 
produce the FMIN and FMAX machine instructions, which in turn causes the 
`__builtin_fmin' and `__builtin_fmax' family of intrinsics to emit the 
corresponding libcalls rather than the relevant machine instructions.  
This is according to earlier revisions of the RISC-V ISA specification, 
which we however do not support anymore, as from commit 4b81528241ca 
("RISC-V: Support version controling for ISA standard extensions").

As from r20190608 of the RISC-V ISA specification (equivalent to version 
2.2 of the "F" and "D" standard ISA extensions for single-precision and 
double-precision floating-point respectively) the definition of the FMIN 
and FMAX machine instructions has been updated[2]:

"Defined the signed-zero behavior of FMIN.fmt and FMAX.fmt, and changed 
their behavior on signaling-NaN inputs to conform to the minimumNumber 
and maximumNumber operations in the proposed IEEE 754-201x 
specification."

and specifically[3]:

"Floating-point minimum-number and maximum-number instructions FMIN.S 
and FMAX.S write, respectively, the smaller or larger of rs1 and rs2 to 
rd.  For the purposes of these instructions only, the value -0.0 is 
considered to be less than the value +0.0.  If both inputs are NaNs, the 
result is the canonical NaN.  If only one operand is a NaN, the result 
is the non-NaN operand.  Signaling NaN inputs set the invalid operation 
exception flag, even when the result is not NaN."

Consequently for forwards compatibility with r20190608+ hardware we 
cannot use the FMIN and FMAX machine instructions unconditionally even 
where the ISA level of r2.2 has been specified with the `-misa-spec=2.2' 
option where operation would be different between ISA revisions, that 
is the handling of signaling NaN inputs.

Therefore provide new `fmin3' and `fmax3' patterns removing 
the need to emit libcalls with the `__builtin_fmin' and `__builtin_fmax' 
family of intrinsics, however limit them to where `-fno-signaling-nans' 
is in effect, deferring to other code generation strategies otherwise as 
applicable.  Use newly-defined UNSPECs as the operation codes so that 
the patterns are only ever used if referred to by their names, as there
is no RTL expression defined for the IEEE 754-2008 `minNum' and `maxNum' 
operations.

References:

[1] "The RISC-V Instruction Set Manual, Volume I: User-Level ISA",
Document Version 2.2, May 7, 2017, Section 8.3 "NaN Generation and 
Propagation", p. 48

[1] "The RISC-V Instruction Set Manual, Volume I: Unprivileged ISA",
Document Version 20190608-Base-Ratified, June 8, 2019, "Preface",
p. ii

[2] same, Section 11.6 "Single-Precision Floating-Point Computational
Instructions", p. 66

gcc/
* config/riscv/riscv.md (UNSPEC_FMIN, UNSPEC_FMAX): New
constants.
(fmin3, fmax3): New insns.

gcc/testsuite/
* gcc.target/riscv/fmax-snan.c: New test.
* gcc.target/riscv/fmax.c: New test.
* gcc.target/riscv/fmaxf-snan.c: New test.
* gcc.target/riscv/fmaxf.c: New test.
* gcc.target/riscv/fmin-snan.c: New test.
* gcc.target/riscv/fmin.c: New test.
* gcc.target/riscv/fminf-snan.c: New test.
* gcc.target/riscv/fminf.c: New test.
* gcc.target/riscv/smax-ieee.c: New test.
* gcc.target/riscv/smax.c: New test.
* gcc.target/riscv/smaxf-ieee.c: New test.
* gcc.target/riscv/smaxf.c: New test.
* gcc.target/riscv/smin-ieee.c: New test.
* gcc.target/riscv/smin.c: New test.
* gcc.target/riscv/sminf-ieee.c: New test.
* gcc.target/riscv/sminf.c: New test.
---
On Mon, 28 Feb 2022, Jim Wilson wrote:

> On Tue, Feb 8, 2022 at 4:35 AM Maciej W. Rozycki  wrote:
> 
> > gcc/
> > * config/riscv/riscv.md (UNSPEC_FMIN, UNSPEC_FMAX): New
> > constants.
> > (fmin3, fmax3): New insns.
> > ...
> 
> 
> I tried testing on some of the hardware I have.  Both the HiFive Unleashed
> (2018) and HiFive Unmatched (2021) implement the current definition of
> fmin/fmax.  But the Allwinner Nezha (2021) implements the previous
> definition of fmin/fmax.  SiFive was involved with the fmin/fmax change, so
> it isn't surprising that they implemented the new semantics before other
> companies.  The Nezha board with the T-Head C906 is a 

Re: [PATCH] libiberty: stop using PTR macro.

2022-05-10 Thread Martin Liška
On 5/10/22 15:50, Eric Gallager wrote:
> Hi, please preserve existing style when possible when making this
> replacement; ISTR there are some tools (like for generating
> libiberty's documentation) that depend on the return type being on a
> separate line... If all of the relevant Makefile targets still work
> after this change, well, fine, but... well, just something to
> consider...

Hello.

Thanks for heads up. I make the replacement by a tool and wrongly forgot
to append a newline in some cases.

It's fixed in the installed version of the patch.

Martin


Advise to call 'internal_error' instead of 'abort' or 'fancy_abort'

2022-05-10 Thread Thomas Schwinge
Hi!

On 2022-05-03T15:46:43+0200, Richard Biener  wrote:
> On Tue, May 3, 2022 at 2:29 PM Thomas Schwinge  
> wrote:
>> On 2022-05-03T12:53:50+0200, Richard Biener  
>> wrote:
>> > On Tue, May 3, 2022 at 10:16 AM Thomas Schwinge  
>> > wrote:
>> >> On 2022-05-03T09:17:52+0200, Richard Biener  
>> >> wrote:
>> >> > On Mon, May 2, 2022 at 4:01 PM Thomas Schwinge 
>> >> >  wrote:
>> >> > +#if 0
>> >> >gcc_unreachable ();
>> >> > +#else
>> >> > +  /* ..., but due to bugs (PR100400), we may actually come here.
>> >> > +Reliably catch this, regardless of checking level.  */
>> >> > +  abort ();
>> >> > +#endif
>> >> >
>> >> > this doesn't look correct.  If you want a reliable diagnostic here 
>> >> > please [...]
>> >> > call internal_error () manually (the IL verifiers do this).
>> >>
>> >> Hmm, I feel I'm going in circles...  ;-)

>> >> I first had this as 'internal_error', but then saw the following source
>> >> code comment, 'gcc/diagnostic.cc':
>> >>
>> >> /* An internal consistency check has failed.  We make no attempt to
>> >>continue.  Note that unless there is debugging value to be had from
>> >>a more specific message, or some other good reason, you should use
>> >>abort () instead of calling this function directly.  */
>> >> void
>> >> internal_error (const char *gmsgid, ...)
>> >> {
>> >>
>> >> Here, there's no "debugging value to be had from a more specific
>> >> message", and I couldn't think of "some other good reason", so decided to
>> >> "use abort () instead of calling this function directly".
>> >
>> > I think that is misguided.
>>
>> So that I know which one to fix/reconsider: does your "that" refer to the
>> 'gcc/diagnostic.cc:internal_error' source code comment cited above, or my
>> interpretation of it?
>
> The comment to "use abort ()".

Does the attached
"Advise to call 'internal_error' instead of 'abort' or 'fancy_abort'"
capture what you had in mind?

(This is, obviously, not updating any of the many 'abort' or even a few
'fancy_abort' calls that we currently have.)


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From a8017c7b5fa7b5e8210b6446acf7dd09989a7517 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 10 May 2022 15:56:08 +0200
Subject: [PATCH] Advise to call 'internal_error' instead of 'abort' or
 'fancy_abort'

	gcc/
	* diagnostic.cc: Don't advise to call 'abort' instead of
	'internal_error'.
	* system.h: Advise to call 'internal_error' instead of 'abort' or
	'fancy_abort'.

Suggested-by: Richard Biener 
---
 gcc/diagnostic.cc | 4 +---
 gcc/system.h  | 6 --
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index 73324a728fe..fef11467b6f 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -1935,9 +1935,7 @@ fatal_error (location_t loc, const char *gmsgid, ...)
 }
 
 /* An internal consistency check has failed.  We make no attempt to
-   continue.  Note that unless there is debugging value to be had from
-   a more specific message, or some other good reason, you should use
-   abort () instead of calling this function directly.  */
+   continue.  */
 void
 internal_error (const char *gmsgid, ...)
 {
diff --git a/gcc/system.h b/gcc/system.h
index c25cd64366f..187763efcd6 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -770,8 +770,10 @@ extern int vsnprintf (char *, size_t, const char *, va_list);
 #endif
 #endif
 
-/* Redefine abort to report an internal error w/o coredump, and
-   reporting the location of the error in the source file.  */
+/* Redefine 'abort' to report an internal error w/o coredump, and
+   reporting the location of the error in the source file.
+   Instead of directly calling 'abort' or 'fancy_abort', GCC code
+   should normally call 'internal_error' with a specific message.  */
 extern void fancy_abort (const char *, int, const char *)
 	 ATTRIBUTE_NORETURN ATTRIBUTE_COLD;
 #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
-- 
2.25.1



Re: [PATCH v2] c, c++: -Wswitch warning on [[maybe_unused]] enumerator [PR105497]

2022-05-10 Thread Marek Polacek via Gcc-patches
On Tue, May 10, 2022 at 08:58:46AM -0400, Jason Merrill wrote:
> On 5/7/22 18:26, Marek Polacek wrote:
> > Corrected version that avoids an uninitialized warning:
> > 
> > This PR complains that we emit the "enumeration value not handled in
> > switch" warning even though the enumerator was marked with the
> > [[maybe_unused]] attribute.
> > 
> > The first snag was that I couldn't just check TREE_USED, because
> > the enumerator could have been used earlier in the function, which
> > doesn't play well with the c_do_switch_warnings warning.  Instead,
> > I had to check the attributes on the CONST_DECL directly, which led
> > to the second, and worse, snag: in C we don't have direct access to
> > the CONST_DECL for the enumerator.
> 
> I wonder if you want to change that instead of working around it?

I wouldn't mind looking into that; I've hit this discrepancy numerous
times throughout the years and it'd be good to unify it so that the
c-common code doesn't need to hack around it.
 
Let's see how far I'll get...

> > +  const bool unused_p = (lookup_attribute ("unused", attrs)
> > +|| lookup_attribute ("maybe_unused", attrs));
> 
> Why is this calculation...
> 
> > node = splay_tree_lookup (cases, (splay_tree_key) value);
> > if (node)
> > {
> > @@ -1769,6 +1784,10 @@ c_do_switch_warnings (splay_tree cases, location_t 
> > switch_location,
> > /* We've now determined that this enumerated literal isn't
> >  handled by the case labels of the switch statement.  */
> > +  /* Don't warn if the enumerator was marked as unused.  */
> > +  if (unused_p)
> > +   continue;
> 
> ...separate from this test?

Ah, that must be a remnant from a previous version of the patch.  No reason
for the separation anymore.

Thanks,
Marek



Re: [PATCH] libiberty: stop using PTR macro.

2022-05-10 Thread Eric Gallager via Gcc-patches
On Tue, May 10, 2022 at 5:37 AM Martin Liška  wrote:
>
> Hi.
>
> As noticed by Alan, we can stop using the non-ANSI C specific macro (PTR).
> Let's removed its usafe in libiberty.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> include/ChangeLog:
>
> * hashtab.h (HTAB_EMPTY_ENTRY): Use void * instead PTR.
> (HTAB_DELETED_ENTRY): Likewise.
>
> libiberty/ChangeLog:
>
> * alloca.c (C_alloca): Use void * instead PTR.
> * calloc.c (malloc): Likewise.
> (bzero): Likewise.
> (calloc): Likewise.
> * hashtab.c (find_empty_slot_for_expand): Likewise.
> (eq_pointer): Likewise.
> (htab_create_alloc_ex): Likewise.
> (htab_create_typed_alloc): Likewise.
> (htab_set_functions_ex): Likewise.
> (htab_delete): Likewise.
> (htab_empty): Likewise.
> (htab_expand): Likewise.
> (htab_find_with_hash): Likewise.
> (htab_find): Likewise.
> (htab_find_slot_with_hash): Likewise.
> (htab_find_slot): Likewise.
> (htab_remove_elt): Likewise.
> (htab_remove_elt_with_hash): Likewise.
> (htab_clear_slot): Likewise.
> (htab_traverse_noresize): Likewise.
> (htab_traverse): Likewise.
> (htab_hash_string): Likewise.
> (iterative_hash): Likewise.
> (hash_pointer): Likewise.
> * memchr.c (memchr): Likewise.
> * memcmp.c (memcmp): Likewise.
> * memcpy.c (memcpy): Likewise.
> * memmove.c (memmove): Likewise.
> * mempcpy.c (memcpy): Likewise.
> (mempcpy): Likewise.
> * memset.c (memset): Likewise.
> * objalloc.c (malloc): Likewise.
> (free): Likewise.
> (objalloc_create): Likewise.
> (_objalloc_alloc): Likewise.
> (objalloc_free_block): Likewise.
> * random.c (PTR): Likewise.
> (void): Likewise.
> (initstate): Likewise.
> (setstate): Likewise.
> * regex.c: Likewise.
> * spaces.c (malloc): Likewise.
> (free): Likewise.
> * stpcpy.c (memcpy): Likewise.
> * strdup.c (malloc): Likewise.
> (memcpy): Likewise.
> * strerror.c (malloc): Likewise.
> (memset): Likewise.
> * strndup.c (malloc): Likewise.
> (memcpy): Likewise.
> * strsignal.c (malloc): Likewise.
> (memset): Likewise.
> * vasprintf.c (malloc): Likewise.
> * vprintf-support.c: Likewise.
> * xatexit.c (malloc): Likewise.
> * xmalloc.c (xmalloc): Likewise.
> (xcalloc): Likewise.
> (xrealloc): Likewise.
> * xmemdup.c (xmemdup): Likewise.
> ---
>  include/hashtab.h   |  4 +-
>  libiberty/alloca.c  |  7 ++-
>  libiberty/calloc.c  |  9 ++--
>  libiberty/hashtab.c | 92 ++---
>  libiberty/memchr.c  |  5 +-
>  libiberty/memcmp.c  |  2 +-
>  libiberty/memcpy.c  |  3 +-
>  libiberty/memmove.c |  3 +-
>  libiberty/mempcpy.c |  5 +-
>  libiberty/memset.c  |  3 +-
>  libiberty/objalloc.c| 23 +-
>  libiberty/random.c  | 14 +++---
>  libiberty/regex.c   |  8 ++--
>  libiberty/spaces.c  |  4 +-
>  libiberty/stpcpy.c  |  2 +-
>  libiberty/strdup.c  |  4 +-
>  libiberty/strerror.c|  4 +-
>  libiberty/strndup.c |  4 +-
>  libiberty/strsignal.c   |  4 +-
>  libiberty/vasprintf.c   |  2 +-
>  libiberty/vprintf-support.c |  2 +-
>  libiberty/xatexit.c |  2 +-
>  libiberty/xmalloc.c | 15 +++---
>  libiberty/xmemdup.c |  7 ++-
>  24 files changed, 106 insertions(+), 122 deletions(-)
>
> diff --git a/include/hashtab.h b/include/hashtab.h
> index 7117eee2afb..e74d2226e08 100644
> --- a/include/hashtab.h
> +++ b/include/hashtab.h
> @@ -79,12 +79,12 @@ typedef void (*htab_free_with_arg) (void *, void *);
>
>  /* This macro defines reserved value for empty table entry.  */
>
> -#define HTAB_EMPTY_ENTRY((PTR) 0)
> +#define HTAB_EMPTY_ENTRY((void *) 0)
>
>  /* This macro defines reserved value for table entry which contained
> a deleted element. */
>
> -#define HTAB_DELETED_ENTRY  ((PTR) 1)
> +#define HTAB_DELETED_ENTRY  ((void *) 1)
>
>  /* Hash tables are of the following type.  The structure
> (implementation) of this type is not needed for using the hash
> diff --git a/libiberty/alloca.c b/libiberty/alloca.c
> index 9b2e9cb12b6..46f920517e1 100644
> --- a/libiberty/alloca.c
> +++ b/libiberty/alloca.c
> @@ -158,8 +158,7 @@ static header *last_alloca_header = NULL;   /* -> last 
> alloca header.  */
>
>  /* @undocumented C_alloca */
>
> -PTR
> -C_alloca (size_t size)
> +void *C_alloca (size_t size)

Hi, please preserve existing style when possible when making this
replacement; ISTR there are some tools (like for generating
libiberty's 

[PATCH] Use gimple-match folding in fold_build_cond_expr

2022-05-10 Thread Richard Biener via Gcc-patches
The following cleans up if-conversions fold_build_cond_expr to
use gimple-match folding instead of GENERIC folding.

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

2022-05-10  Richard Biener  

* tree-if-conv.cc (fold_build_cond_expr): Use
match-and-simplify to simplify the condition.
(ifcvt_follow_ssa_use_edges): Remove.
(predicate_scalar_phi): Use follow_all_ssa_edges.
---
 gcc/tree-if-conv.cc | 46 +++--
 1 file changed, 11 insertions(+), 35 deletions(-)

diff --git a/gcc/tree-if-conv.cc b/gcc/tree-if-conv.cc
index 7495ed653c0..57cc38567d3 100644
--- a/gcc/tree-if-conv.cc
+++ b/gcc/tree-if-conv.cc
@@ -459,8 +459,6 @@ fold_or_predicates (location_t loc, tree c1, tree c2)
 static tree
 fold_build_cond_expr (tree type, tree cond, tree rhs, tree lhs)
 {
-  tree rhs1, lhs1, cond_expr;
-
   /* If COND is comparison r != 0 and r has boolean type, convert COND
  to SSA_NAME to accept by vect bool pattern.  */
   if (TREE_CODE (cond) == NE_EXPR)
@@ -472,34 +470,20 @@ fold_build_cond_expr (tree type, tree cond, tree rhs, 
tree lhs)
  && (integer_zerop (op1)))
cond = op0;
 }
-  cond_expr = fold_ternary (COND_EXPR, type, cond, rhs, lhs);
-
-  if (cond_expr == NULL_TREE)
-return build3 (COND_EXPR, type, cond, rhs, lhs);
-
-  STRIP_USELESS_TYPE_CONVERSION (cond_expr);
 
-  if (is_gimple_val (cond_expr))
-return cond_expr;
-
-  if (TREE_CODE (cond_expr) == ABS_EXPR)
+  gimple_match_op cexpr (gimple_match_cond::UNCOND, COND_EXPR,
+type, cond, rhs, lhs);
+  if (cexpr.resimplify (NULL, follow_all_ssa_edges))
 {
-  rhs1 = TREE_OPERAND (cond_expr, 1);
-  STRIP_USELESS_TYPE_CONVERSION (rhs1);
-  if (is_gimple_val (rhs1))
-   return build1 (ABS_EXPR, type, rhs1);
+  if (gimple_simplified_result_is_gimple_val ())
+   return cexpr.ops[0];
+  else if (cexpr.code == ABS_EXPR)
+   return build1 (ABS_EXPR, type, cexpr.ops[0]);
+  else if (cexpr.code == MIN_EXPR
+  || cexpr.code == MAX_EXPR)
+   return build2 ((tree_code)cexpr.code, type, cexpr.ops[0], cexpr.ops[1]);
 }
 
-  if (TREE_CODE (cond_expr) == MIN_EXPR
-  || TREE_CODE (cond_expr) == MAX_EXPR)
-{
-  lhs1 = TREE_OPERAND (cond_expr, 0);
-  STRIP_USELESS_TYPE_CONVERSION (lhs1);
-  rhs1 = TREE_OPERAND (cond_expr, 1);
-  STRIP_USELESS_TYPE_CONVERSION (rhs1);
-  if (is_gimple_val (rhs1) && is_gimple_val (lhs1))
-   return build2 (TREE_CODE (cond_expr), type, lhs1, rhs1);
-}
   return build3 (COND_EXPR, type, cond, rhs, lhs);
 }
 
@@ -1897,14 +1881,6 @@ gen_phi_arg_condition (gphi *phi, vec *occur,
   return cond;
 }
 
-/* Local valueization callback that follows all-use SSA edges.  */
-
-static tree
-ifcvt_follow_ssa_use_edges (tree val)
-{
-  return val;
-}
-
 /* Replace a scalar PHI node with a COND_EXPR using COND as condition.
This routine can handle PHI nodes with more than two arguments.
 
@@ -2007,7 +1983,7 @@ predicate_scalar_phi (gphi *phi, gimple_stmt_iterator 
*gsi)
   new_stmt = gimple_build_assign (res, rhs);
   gsi_insert_before (gsi, new_stmt, GSI_SAME_STMT);
   gimple_stmt_iterator new_gsi = gsi_for_stmt (new_stmt);
-  if (fold_stmt (_gsi, ifcvt_follow_ssa_use_edges))
+  if (fold_stmt (_gsi, follow_all_ssa_edges))
{
  new_stmt = gsi_stmt (new_gsi);
  update_stmt (new_stmt);
-- 
2.35.3


[PATCH 2/2] c++: Remove SET_PACK_EXPANSION_PATTERN / SET_ARGUMENT_PACK_ARGS

2022-05-10 Thread Patrick Palka via Gcc-patches
Unlike in C, in C++ the conditional operator yields an lvalue if both
branches are lvalues, so we can just assign to PACK_EXPANSION_PATTERN
and ARGUMENT_PACK_ARGS directly.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

gcc/cp/ChangeLog:

* coroutines.cc (instantiate_coro_traits): Adjust accordingly.
* cp-tree.h (SET_PACK_EXPANSION_PATTERN): Remove.
(SET_ARGUMENT_PACK_ARGS): Remove.
* module.cc (trees_in::tree_node): Adjust accordingly.
* parser.cc (make_char_string_pack): Likewise.
(make_string_pack): Likewise.
* pt.cc (make_pack_expansion): Likewise.
(template_parm_to_arg): Likewise.
(coerce_template_parameter_pack): Likewise.
(extract_fnparm_pack): Likewise.
(extract_locals_r): Likewise.
(make_argument_pack): Likewise.
(tsubst_argument_pack): Likewise.
(lookup_init_capture_pack): Likewise.
(type_unification_real): Likewise.
(unify_pack_expansion): Likewise.
(tsubst_initializer_list): Likewise.
---
 gcc/cp/coroutines.cc |  2 +-
 gcc/cp/cp-tree.h | 16 
 gcc/cp/module.cc |  4 ++--
 gcc/cp/parser.cc |  4 ++--
 gcc/cp/pt.cc | 30 +++---
 5 files changed, 20 insertions(+), 36 deletions(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 1d886b31c77..edb3b706ddc 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -344,7 +344,7 @@ instantiate_coro_traits (tree fndecl, location_t kw)
 }
 
   tree argtypepack = cxx_make_type (TYPE_ARGUMENT_PACK);
-  SET_ARGUMENT_PACK_ARGS (argtypepack, argtypes);
+  ARGUMENT_PACK_ARGS (argtypepack) = argtypes;
 
   tree targ = make_tree_vec (2);
   TREE_VEC_ELT (targ, 0) = TREE_TYPE (functyp);
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 29fc0e5f829..cfda8337ad8 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -3903,14 +3903,6 @@ struct GTY(()) lang_decl {
   (TREE_CODE (PACK_EXPANSION_CHECK (NODE)) == TYPE_PACK_EXPANSION \
? TREE_TYPE (NODE) : TREE_OPERAND (NODE, 0))
 
-/* Sets the type or expression pattern for a TYPE_PACK_EXPANSION or
-   EXPR_PACK_EXPANSION.  */
-#define SET_PACK_EXPANSION_PATTERN(NODE,VALUE)  \
-  if (TREE_CODE (PACK_EXPANSION_CHECK (NODE)) == TYPE_PACK_EXPANSION)  \
-TREE_TYPE (NODE) = VALUE;   \
-  else  \
-TREE_OPERAND (NODE, 0) = VALUE
-
 /* The list of parameter packs used in the PACK_EXPANSION_* node. The
TREE_VALUE of each TREE_LIST contains the parameter packs.  */
 #define PACK_EXPANSION_PARAMETER_PACKS(NODE)   \
@@ -3963,14 +3955,6 @@ struct GTY(()) lang_decl {
   (TREE_CODE (ARGUMENT_PACK_CHECK (NODE)) == TYPE_ARGUMENT_PACK \
? TREE_TYPE (NODE) : TREE_OPERAND (NODE, 0))
 
-/* Set the arguments stored in an argument pack. VALUE must be a
-   TREE_VEC.  */
-#define SET_ARGUMENT_PACK_ARGS(NODE,VALUE) \
-  if (TREE_CODE (ARGUMENT_PACK_CHECK (NODE)) == TYPE_ARGUMENT_PACK)  \
-TREE_TYPE (NODE) = VALUE;   \
-  else  \
-TREE_OPERAND (NODE, 0) = VALUE
-
 /* Whether the argument pack is "incomplete", meaning that more
arguments can still be deduced. Incomplete argument packs are only
used when the user has provided an explicit template argument list
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index bd4771bef72..27b8f64ce75 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -9338,7 +9338,7 @@ trees_in::tree_node (bool is_use)
if (!get_overrun ())
  {
tree pack = cxx_make_type (TYPE_ARGUMENT_PACK);
-   SET_ARGUMENT_PACK_ARGS (pack, res);
+   ARGUMENT_PACK_ARGS (pack) = res;
res = pack;
  }
break;
@@ -9351,7 +9351,7 @@ trees_in::tree_node (bool is_use)
{
  tree expn = cxx_make_type (TYPE_PACK_EXPANSION);
  SET_TYPE_STRUCTURAL_EQUALITY (expn);
- SET_PACK_EXPANSION_PATTERN (expn, res);
+ PACK_EXPANSION_PATTERN (expn) = res;
  PACK_EXPANSION_PARAMETER_PACKS (expn) = param_packs;
  PACK_EXPANSION_LOCAL_P (expn) = local;
  res = expn;
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 5071c030f53..4ed9feaa427 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -4649,7 +4649,7 @@ make_char_string_pack (tree value)
 }
 
   /* Build the argument packs.  */
-  SET_ARGUMENT_PACK_ARGS (argpack, charvec);
+  ARGUMENT_PACK_ARGS (argpack) = charvec;
 
   TREE_VEC_ELT (argvec, 0) = argpack;
 
@@ -4684,7 +4684,7 @@ make_string_pack (tree value)
double_int::from_buffer (str + i * sz, sz));
 
   /* Build the argument packs.  */
-  SET_ARGUMENT_PACK_ARGS (argpack, charvec);
+  ARGUMENT_PACK_ARGS (argpack) = charvec;
 
   TREE_VEC_ELT (argvec, 1) = argpack;

[PATCH 1/2] c++: Harden *_PACK_EXPANSION and *_ARGUMENT_PACK macros

2022-05-10 Thread Patrick Palka via Gcc-patches
The accessor macros for TYPE_PACK_EXPANSION/EXPR_PACK_EXPANSION
and TYPE_ARGUMENT_PACK/NONTYPE_ARGUMENT_PACK should check the
tree code of the argument.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

gcc/cp/ChangeLog:

* cp-tree.h (PACK_EXPANSION_CHECK): Define.
(PACK_EXPANSION_PATTERN): Use PACK_EXPANSION_CHECK.
(SET_PACK_EXPANSION_PATTERN): Likewise.
(PACK_EXPANSION_PARAMETER_PACKS): Likewise.
(PACK_EXPANSION_EXTRA_ARGS): Likewise.
(PACK_EXPANSION_LOCAL_P): Likewise.
(PACK_EXPANSION_SIZEOF_P): Likewise.
(PACK_EXPANSION_AUTO_P): Likewise.
(PACK_EXPANSION_FORCE_EXTRA_ARGS_P): Likewise.
(ARGUMENT_PACK_CHECK): Define.
(ARGUMENT_PACK_ARGS): Use ARGUMENT_PACK_CHECK.
(SET_ARGUMENT_PACK_ARGS): Likewise.
* parser.c (cp_parser_sizeof_pack): Check for error_mark_node
before setting PACK_EXPANSION_SIZEOF_P.
---
 gcc/cp/cp-tree.h | 34 ++
 gcc/cp/parser.cc |  3 ++-
 2 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 8a5057a4dff..29fc0e5f829 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -3894,16 +3894,19 @@ struct GTY(()) lang_decl {
   (TREE_CODE (NODE) == TYPE_PACK_EXPANSION \
|| TREE_CODE (NODE) == EXPR_PACK_EXPANSION)
 
+#define PACK_EXPANSION_CHECK(NODE) \
+  TREE_CHECK2 (NODE, TYPE_PACK_EXPANSION, EXPR_PACK_EXPANSION)
+
 /* Extracts the type or expression pattern from a TYPE_PACK_EXPANSION or
EXPR_PACK_EXPANSION.  */
 #define PACK_EXPANSION_PATTERN(NODE)\
-  (TREE_CODE (NODE) == TYPE_PACK_EXPANSION ? TREE_TYPE (NODE)\
-   : TREE_OPERAND (NODE, 0))
+  (TREE_CODE (PACK_EXPANSION_CHECK (NODE)) == TYPE_PACK_EXPANSION \
+   ? TREE_TYPE (NODE) : TREE_OPERAND (NODE, 0))
 
 /* Sets the type or expression pattern for a TYPE_PACK_EXPANSION or
EXPR_PACK_EXPANSION.  */
 #define SET_PACK_EXPANSION_PATTERN(NODE,VALUE)  \
-  if (TREE_CODE (NODE) == TYPE_PACK_EXPANSION)  \
+  if (TREE_CODE (PACK_EXPANSION_CHECK (NODE)) == TYPE_PACK_EXPANSION)  \
 TREE_TYPE (NODE) = VALUE;   \
   else  \
 TREE_OPERAND (NODE, 0) = VALUE
@@ -3911,7 +3914,7 @@ struct GTY(()) lang_decl {
 /* The list of parameter packs used in the PACK_EXPANSION_* node. The
TREE_VALUE of each TREE_LIST contains the parameter packs.  */
 #define PACK_EXPANSION_PARAMETER_PACKS(NODE)   \
-  *(TREE_CODE (NODE) == EXPR_PACK_EXPANSION\
+  *(TREE_CODE (PACK_EXPANSION_CHECK (NODE)) == EXPR_PACK_EXPANSION \
 ? _OPERAND (NODE, 1)  \
 : _MIN_VALUE_RAW (TYPE_PACK_EXPANSION_CHECK (NODE)))
 
@@ -3922,22 +3925,26 @@ struct GTY(()) lang_decl {
are enclosing functions that provided function parameter packs we'll need
to map appropriately.  */
 #define PACK_EXPANSION_EXTRA_ARGS(NODE)\
-  *(TREE_CODE (NODE) == TYPE_PACK_EXPANSION\
+  *(TREE_CODE (PACK_EXPANSION_CHECK (NODE)) == TYPE_PACK_EXPANSION \
 ? _MAX_VALUE_RAW (NODE)   \
 : _OPERAND ((NODE), 2))
 
 /* True iff this pack expansion is within a function context.  */
-#define PACK_EXPANSION_LOCAL_P(NODE) TREE_LANG_FLAG_0 (NODE)
+#define PACK_EXPANSION_LOCAL_P(NODE) \
+  TREE_LANG_FLAG_0 (PACK_EXPANSION_CHECK (NODE))
 
 /* True iff this pack expansion is for sizeof  */
-#define PACK_EXPANSION_SIZEOF_P(NODE) TREE_LANG_FLAG_1 (NODE)
+#define PACK_EXPANSION_SIZEOF_P(NODE) \
+  TREE_LANG_FLAG_1 (PACK_EXPANSION_CHECK (NODE))
 
 /* True iff this pack expansion is for auto... in lambda init-capture.  */
-#define PACK_EXPANSION_AUTO_P(NODE) TREE_LANG_FLAG_2 (NODE)
+#define PACK_EXPANSION_AUTO_P(NODE) \
+  TREE_LANG_FLAG_2 (PACK_EXPANSION_CHECK (NODE))
 
 /* True if we must use PACK_EXPANSION_EXTRA_ARGS and avoid partial
instantiation of this pack expansion.  */
-#define PACK_EXPANSION_FORCE_EXTRA_ARGS_P(NODE) TREE_LANG_FLAG_3 (NODE)
+#define PACK_EXPANSION_FORCE_EXTRA_ARGS_P(NODE) \
+  TREE_LANG_FLAG_3 (PACK_EXPANSION_CHECK (NODE))
 
 /* True iff the wildcard can match a template parameter pack.  */
 #define WILDCARD_PACK_P(NODE) TREE_LANG_FLAG_0 (NODE)
@@ -3947,16 +3954,19 @@ struct GTY(()) lang_decl {
   (TREE_CODE (NODE) == TYPE_ARGUMENT_PACK  \
|| TREE_CODE (NODE) == NONTYPE_ARGUMENT_PACK)
 
+#define ARGUMENT_PACK_CHECK(NODE) \
+  TREE_CHECK2 (NODE, TYPE_ARGUMENT_PACK, NONTYPE_ARGUMENT_PACK)
+
 /* The arguments stored in an argument pack. Arguments are stored in a
TREE_VEC, which may have length zero.  */
 #define ARGUMENT_PACK_ARGS(NODE)   \
-  (TREE_CODE (NODE) == TYPE_ARGUMENT_PACK? TREE_TYPE (NODE)\
-   : TREE_OPERAND (NODE, 0))
+  (TREE_CODE (ARGUMENT_PACK_CHECK (NODE)) == TYPE_ARGUMENT_PACK \
+   ? TREE_TYPE (NODE) : TREE_OPERAND (NODE, 0))
 
 /* Set the arguments stored in an argument pack. VALUE must be a

Re: [patch][gcc13][i386][pr101891]Adjust -fzero-call-used-regs to always use XOR

2022-05-10 Thread Qing Zhao via Gcc-patches



> On May 10, 2022, at 1:12 AM, Richard Biener  wrote:
> 
> On Mon, 9 May 2022, Uros Bizjak wrote:
> 
>> On Mon, May 9, 2022 at 5:44 PM Qing Zhao  wrote:
>>> 
>>> Another question:
>>> 
>>> I think that this patch might need to be back ported to Gcc12 and GCC11.
>>> 
>>> What?s your opinion on this?
>> 
>> It is not a regression, so following general rules, the patch should
>> not be backported. OTOH, the patch creates functionally equivalent
>> code, better in some security aspects. The functionality is also
>> hidden behind some non-default flag, so I think if release managers
>> (CC'd) are OK with the backport, I'd give it a technical approval.
>> 
>>> If so, when can I backport it?
>> 
>> Let's keep it in the mainline for a week or two, before backporting it
>> to non-EoL branches.
> 
> OK from my POV after a week or two on trunk.

Sure, I will do the back porting after two weeks.

thanks.

Qing
> 
> Richard.
> 
>> Uros.
>> 
>>> 
>>> thanks.
>>> 
>>> Qing
>>> 
 On May 7, 2022, at 4:06 AM, Uros Bizjak  wrote:
 
 On Fri, May 6, 2022 at 6:42 PM Qing Zhao  wrote:
> 
> 
> 
>> On May 6, 2022, at 10:58 AM, Uros Bizjak  wrote:
>> 
>> On Fri, May 6, 2022 at 4:29 PM Qing Zhao  wrote:
>>> 
>>> Hi,
>>> 
>>> As Kee?s requested in this PR: 
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891
>>> 
>>> =
>>> 
>>> Currently -fzero-call-used-regs will use a pattern of:
>>> 
>>> XOR regA,regA
>>> MOV regA,regB
>>> MOV regA,regC
>>> ...
>>> RET
>>> 
>>> However, this introduces both a register ordering dependency (e.g. the 
>>> CPU cannot clear regB without clearing regA first), and while greatly 
>>> reduces available ROP gadgets, it does technically leave a set of "MOV" 
>>> ROP gadgets at the end of functions (e.g. "MOV regA,regC; RET").
>>> 
>>> Please switch to always using XOR:
>>> 
>>> XOR regA,regA
>>> XOR regB,regB
>>> XOR regC,regC
>>> ...
>>> RET
>>> 
>>> ===
>>> 
>>> This patch switch all MOV to XOR on i386.
>>> 
>>> Bootstrapped and regresstion tested on x86_64-linux-gnu.
>>> 
>>> Okay for gcc13?
>>> 
>>> Thanks.
>>> 
>>> Qing
>>> 
>>> ==
>> 
>>> gcc/ChangeLog:
>>> 
>>> * config/i386/i386.cc (zero_all_mm_registers): Use SET to zero instead
>>> of MOV for zeroing scratch registers.
>>> (ix86_zero_call_used_regs): Likewise.
>>> 
>>> gcc/testsuite/ChangeLog:
>>> 
>>> * gcc.target/i386/zero-scratch-regs-1.c: Add -fno-stack-protector
>>> -fno-PIC.
>>> * gcc.target/i386/zero-scratch-regs-10.c: Adjust mov to xor.
>>> * gcc.target/i386/zero-scratch-regs-13.c: Add -msse.
>>> * gcc.target/i386/zero-scratch-regs-14.c: Adjust mov to xor.
>>> * gcc.target/i386/zero-scratch-regs-15.c: Add -fno-stack-protector
>>> -fno-PIC.
>>> * gcc.target/i386/zero-scratch-regs-16.c: Likewise.
>>> * gcc.target/i386/zero-scratch-regs-17.c: Likewise.
>>> * gcc.target/i386/zero-scratch-regs-18.c: Add -fno-stack-protector
>>> -fno-PIC, adjust mov to xor.
>>> * gcc.target/i386/zero-scratch-regs-19.c: Add -fno-stack-protector
>>> -fno-PIC.
>>> * gcc.target/i386/zero-scratch-regs-2.c: Adjust mov to xor.
>>> * gcc.target/i386/zero-scratch-regs-20.c: Add -msse.
>>> * gcc.target/i386/zero-scratch-regs-21.c: Add -fno-stack-protector
>>> -fno-PIC, Adjust mov to xor.
>>> * gcc.target/i386/zero-scratch-regs-22.c: Adjust mov to xor.
>>> * gcc.target/i386/zero-scratch-regs-23.c: Likewise.
>>> * gcc.target/i386/zero-scratch-regs-26.c: Likewise.
>>> * gcc.target/i386/zero-scratch-regs-27.c: Likewise.
>>> * gcc.target/i386/zero-scratch-regs-28.c: Likewise.
>>> * gcc.target/i386/zero-scratch-regs-3.c: Add -fno-stack-protector.
>>> * gcc.target/i386/zero-scratch-regs-31.c: Adjust mov to xor.
>>> * gcc.target/i386/zero-scratch-regs-4.c: Add -fno-stack-protector
>>> -fno-PIC.
>>> * gcc.target/i386/zero-scratch-regs-5.c: Adjust mov to xor.
>>> * gcc.target/i386/zero-scratch-regs-6.c: Add -fno-stack-protector.
>>> * gcc.target/i386/zero-scratch-regs-7.c: Likewise.
>>> * gcc.target/i386/zero-scratch-regs-8.c: Adjust mov to xor.
>>> * gcc.target/i386/zero-scratch-regs-9.c: Add -fno-stack-protector.
>> 
>> Please use something like the attached (functionally equivalent) patch
>> for the last hunk of your patch.
> 
> Sure, I will update the code.
>> 
>> Also, if possible, please use V2SImode as a generic MMX mode instead
>> of V4HImode.
> What?s the major purpose of this change?
 
 Although the generated code is the same, V2SI is used as a "generic"
 MMX move insn in the same way V2DI is used to describe generic SSE
 move instruction.
 
 Uros.
>>> 
>> 
> 
> -- 
> Richard Biener 
> SUSE Software 

Re: [PATCH] Remove non-ANSI C macros in ansidecl.h.

2022-05-10 Thread Jeff Law via Gcc-patches




On 5/10/2022 4:51 AM, Martin Liška wrote:

On 5/10/22 11:55, Andreas Schwab wrote:

The header line should probably be changed since it's no longer about
ANSI or traditional C.


Sure, updated in v2.

OK
jeff



Re: [PATCH] libiberty: stop using PTR macro.

2022-05-10 Thread Jeff Law via Gcc-patches




On 5/10/2022 2:56 AM, Martin Liška wrote:

Hi.

As noticed by Alan, we can stop using the non-ANSI C specific macro (PTR).
Let's removed its usafe in libiberty.

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

Ready to be installed?
Thanks,
Martin

include/ChangeLog:

* hashtab.h (HTAB_EMPTY_ENTRY): Use void * instead PTR.
(HTAB_DELETED_ENTRY): Likewise.

libiberty/ChangeLog:

* alloca.c (C_alloca): Use void * instead PTR.
* calloc.c (malloc): Likewise.
(bzero): Likewise.
(calloc): Likewise.
* hashtab.c (find_empty_slot_for_expand): Likewise.
(eq_pointer): Likewise.
(htab_create_alloc_ex): Likewise.
(htab_create_typed_alloc): Likewise.
(htab_set_functions_ex): Likewise.
(htab_delete): Likewise.
(htab_empty): Likewise.
(htab_expand): Likewise.
(htab_find_with_hash): Likewise.
(htab_find): Likewise.
(htab_find_slot_with_hash): Likewise.
(htab_find_slot): Likewise.
(htab_remove_elt): Likewise.
(htab_remove_elt_with_hash): Likewise.
(htab_clear_slot): Likewise.
(htab_traverse_noresize): Likewise.
(htab_traverse): Likewise.
(htab_hash_string): Likewise.
(iterative_hash): Likewise.
(hash_pointer): Likewise.
* memchr.c (memchr): Likewise.
* memcmp.c (memcmp): Likewise.
* memcpy.c (memcpy): Likewise.
* memmove.c (memmove): Likewise.
* mempcpy.c (memcpy): Likewise.
(mempcpy): Likewise.
* memset.c (memset): Likewise.
* objalloc.c (malloc): Likewise.
(free): Likewise.
(objalloc_create): Likewise.
(_objalloc_alloc): Likewise.
(objalloc_free_block): Likewise.
* random.c (PTR): Likewise.
(void): Likewise.
(initstate): Likewise.
(setstate): Likewise.
* regex.c: Likewise.
* spaces.c (malloc): Likewise.
(free): Likewise.
* stpcpy.c (memcpy): Likewise.
* strdup.c (malloc): Likewise.
(memcpy): Likewise.
* strerror.c (malloc): Likewise.
(memset): Likewise.
* strndup.c (malloc): Likewise.
(memcpy): Likewise.
* strsignal.c (malloc): Likewise.
(memset): Likewise.
* vasprintf.c (malloc): Likewise.
* vprintf-support.c: Likewise.
* xatexit.c (malloc): Likewise.
* xmalloc.c (xmalloc): Likewise.
(xcalloc): Likewise.
(xrealloc): Likewise.
* xmemdup.c (xmemdup): Likewise.

OK
jeff



Re: [PATCH] Remove size limit of PCH

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

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

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


Subject: [PATCH] Remove size limit of PCH


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



Here is the revised patch.





--
Best regards,
LIU Hao
From 2e314baed84fd80b3b3c4c67787a032b86dd54dc Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Tue, 10 May 2022 13:19:07 +0800
Subject: [PATCH] [PR14940] Remove size limit of PCH

There shouldn't be such a limit in practice.

2022-05-03  LIU Hao 

PR pch/14940
* config/i386/host-mingw32.cc (pch_VA_max_size): Remove.
(mingw32_gt_pch_get_address): Remove size limit.
---
 gcc/config/i386/host-mingw32.cc | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/gcc/config/i386/host-mingw32.cc b/gcc/config/i386/host-mingw32.cc
index 3b0d83ffc606..f915b85abd06 100644
--- a/gcc/config/i386/host-mingw32.cc
+++ b/gcc/config/i386/host-mingw32.cc
@@ -44,9 +44,6 @@ static size_t mingw32_gt_pch_alloc_granularity (void);
 
 static inline void w32_error(const char*, const char*, int, const char*);
 
-/* FIXME: Is this big enough?  */
-static const size_t pch_VA_max_size  = 128 * 1024 * 1024;
-
 /* Granularity for reserving address space.  */
 static size_t va_granularity = 0x1;
 
@@ -88,9 +85,6 @@ static void *
 mingw32_gt_pch_get_address (size_t size, int)
 {
   void* res;
-  size = (size + va_granularity - 1) & ~(va_granularity - 1);
-  if (size > pch_VA_max_size)
-return NULL;
 
   /* FIXME: We let system determine base by setting first arg to NULL.
  Allocating at top of available address space avoids unnecessary
@@ -100,7 +94,7 @@ mingw32_gt_pch_get_address (size_t size, int)
  If we allocate at bottom we need to reserve the address as early
  as possible and at the same point in each invocation. */
  
-  res = VirtualAlloc (NULL, pch_VA_max_size,
+  res = VirtualAlloc (NULL, size,
  MEM_RESERVE | MEM_TOP_DOWN,
  PAGE_NOACCESS);
   if (!res)
@@ -150,7 +144,7 @@ mingw32_gt_pch_use_address (void *, size_t size, int 
fd,
 
   /* Offset must be also be a multiple of allocation granularity for
  this to work.  We can't change the offset. */ 
-  if ((offset & (va_granularity - 1)) != 0 || size > pch_VA_max_size)
+  if ((offset & (va_granularity - 1)) != 0)
 return -1;
 
 
-- 
2.36.1



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH v2] c, c++: -Wswitch warning on [[maybe_unused]] enumerator [PR105497]

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

On 5/7/22 18:26, Marek Polacek wrote:

Corrected version that avoids an uninitialized warning:

This PR complains that we emit the "enumeration value not handled in
switch" warning even though the enumerator was marked with the
[[maybe_unused]] attribute.

The first snag was that I couldn't just check TREE_USED, because
the enumerator could have been used earlier in the function, which
doesn't play well with the c_do_switch_warnings warning.  Instead,
I had to check the attributes on the CONST_DECL directly, which led
to the second, and worse, snag: in C we don't have direct access to
the CONST_DECL for the enumerator.


I wonder if you want to change that instead of working around it?


I had to handle that by adding
a new function that extracts the decl from an identifier's binding.

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

PR c++/105497

gcc/c-family/ChangeLog:

* c-common.h (get_decl_for_identifier): Declare.
* c-warn.cc (c_do_switch_warnings): Don't warn about unhandled
enumerator when it was marked as unused.

gcc/c/ChangeLog:

* c-decl.cc (get_decl_for_identifier): New.

gcc/cp/ChangeLog:

* tree.cc (get_decl_for_identifier): New.

gcc/testsuite/ChangeLog:

* c-c++-common/Wswitch-1.c: New test.
* g++.dg/warn/Wswitch-4.C: New test.
---
  gcc/c-family/c-common.h|  1 +
  gcc/c-family/c-warn.cc | 24 ++--
  gcc/c/c-decl.cc| 10 +
  gcc/cp/tree.cc |  8 
  gcc/testsuite/c-c++-common/Wswitch-1.c | 29 ++
  gcc/testsuite/g++.dg/warn/Wswitch-4.C  | 52 ++
  6 files changed, 121 insertions(+), 3 deletions(-)
  create mode 100644 gcc/testsuite/c-c++-common/Wswitch-1.c
  create mode 100644 gcc/testsuite/g++.dg/warn/Wswitch-4.C

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index f10be9bd67e..c4221089a18 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -831,6 +831,7 @@ extern tree (*make_fname_decl) (location_t, tree, int);
  
  /* In c-decl.cc and cp/tree.cc.  FIXME.  */

  extern void c_register_addr_space (const char *str, addr_space_t as);
+extern tree get_decl_for_identifier (tree);
  
  /* In c-common.cc.  */

  extern bool in_late_binary_op;
diff --git a/gcc/c-family/c-warn.cc b/gcc/c-family/c-warn.cc
index cae89294aea..03cbc0541b2 100644
--- a/gcc/c-family/c-warn.cc
+++ b/gcc/c-family/c-warn.cc
@@ -1738,8 +1738,23 @@ c_do_switch_warnings (splay_tree cases, location_t 
switch_location,
for (chain = TYPE_VALUES (type); chain; chain = TREE_CHAIN (chain))
  {
tree value = TREE_VALUE (chain);
+  tree id = TREE_PURPOSE (chain);
+  tree attrs = NULL_TREE;
+  /* In C++, the TREE_VALUE is a CONST_DECL.  */
if (TREE_CODE (value) == CONST_DECL)
-   value = DECL_INITIAL (value);
+   {
+ attrs = DECL_ATTRIBUTES (value);
+ value = DECL_INITIAL (value);
+   }
+  /* In C, the TREE_VALUE is an integer constant.  The TREE_PURPOSE is
+an identifier from which we must tease out the CONST_DECL.  */
+  else if (tree decl = get_decl_for_identifier (id))
+   attrs = DECL_ATTRIBUTES (decl);
+  /* Track if the enumerator was marked as unused.  We can't use
+TREE_USED here: it could have been set on the enumerator if
+the enumerator was used earlier.  */
+  const bool unused_p = (lookup_attribute ("unused", attrs)
+|| lookup_attribute ("maybe_unused", attrs));


Why is this calculation...


node = splay_tree_lookup (cases, (splay_tree_key) value);
if (node)
{
@@ -1769,6 +1784,10 @@ c_do_switch_warnings (splay_tree cases, location_t 
switch_location,
/* We've now determined that this enumerated literal isn't
 handled by the case labels of the switch statement.  */
  
+  /* Don't warn if the enumerator was marked as unused.  */

+  if (unused_p)
+   continue;


...separate from this test?


/* If the switch expression is a constant, we only really care
 about whether that constant is handled by the switch.  */
if (cond && tree_int_cst_compare (cond, value))
@@ -1791,8 +1810,7 @@ c_do_switch_warnings (splay_tree cases, location_t 
switch_location,
  (default_node || !warn_switch
   ? OPT_Wswitch_enum
   : OPT_Wswitch),
- "enumeration value %qE not handled in switch",
- TREE_PURPOSE (chain));
+ "enumeration value %qE not handled in switch", id);
  }
  
/* Warn if there are case expressions that don't correspond to

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index c701f07befe..c2c813d922a 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -12466,4 +12466,14 @@ c_check_in_current_scope (tree decl)
return b != NULL && B_IN_CURRENT_SCOPE (b);
  }
  
+/* Returns the 

Re: [Patch] OpenMP: Fix use_device_{addr, ptr} with in-data-sharing arg

2022-05-10 Thread Thomas Schwinge
Hi!

On 2022-04-20T15:19:38+0200, Tobias Burnus  wrote:
> For
>omp parallel shared(array_desc_var)
> the shared-variable is passed to the generated function as
> argument - and replaced by a DECL_VALUE_EXPR inside the parallel region.
>
> If inside the parallel region, a
>
>omp target data has_device_addr(array_descr_var)
>
> is used, the latter generates a
>omp_arr->array_descr_var = _descr_var.data;
> ...
>tmp_desc = array_descr_var
>tmp_desc.data = omp_o->array_descr_var
>
> that is: 'tmp_desc' gets assigned the original descriptor
> and only the data components is updated.
>
>
> However, if that's inside the parallel region, not 'array_descr_var'
> has to be used – but the value expression ('omp_i->array_descr_var').
>
> Fixed by searching the variable used in use_device_{addr,ptr} in the
> outer OpenMP context – and then checking for a DECL_VALUE_EXPR.

I wonder if corresponding OpenACC clause needs similar consideration --
or maybe is covered with this 'OMP_CLAUSE_USE_DEVICE_PTR',
'OMP_CLAUSE_USE_DEVICE_ADDR' handling here (haven't looked yet).


> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/use_device_addr-5.f90
> @@ -0,0 +1,143 @@
> +program main
> +  use omp_lib
> +  implicit none
> +  integer, allocatable :: aaa(:,:,:)
> +  integer :: i
> +
> +  allocate (aaa(-4:10,-3:8,2))
> +  aaa(:,:,:) = reshape ([(i, i = 1, size(aaa))], shape(aaa))
> +
> +  do i = 0, omp_get_num_devices()
> +!$omp target data map(to: aaa)
> +  call test_addr (aaa, i)
> +  call test_ptr (aaa, i)
> +!$omp end target data
> +  end do

Pushed to master branch commit 798152475559a6be8049692932cc747c6499e7f5
"Fix up 'libgomp.fortran/use_device_addr-5.f90' multi-device testing",
see attached.


Grüße
 Thomas


> +  deallocate (aaa)
> +
> +contains
> +
> +  subroutine test_addr (, dev)
> +use iso_c_binding
> +integer, target, allocatable :: (:,:,:), (:,:,:)
> +integer, value :: dev
> +integer :: i
> +type(c_ptr) :: ptr
> +logical :: is_shared
> +
> +is_shared = .false.
> +!$omp target device(dev) map(to: is_shared)
> +  is_shared = .true.
> +!$omp end target
> +
> +allocate ((-4:10,-3:8,2))
> +(:,:,:) = reshape ([(-i, i = 1, size())], shape())
> +!$omp target enter data map(to: ) device(dev)
> +if (any (lbound () /= [-4, -3, 1])) error stop 1
> +if (any (shape () /= [15, 12, 2])) error stop 2
> +if (any (lbound () /= [-4, -3, 1])) error stop 3
> +if (any (shape () /= [15, 12, 2])) error stop 4
> +if (any ( /= -)) error stop 5
> +if (any ( /= reshape ([(i, i = 1, size())], shape( &
> +  error stop 6
> +
> +!$omp parallel do shared(, )
> +do i = 1,1
> +  if (any (lbound () /= [-4, -3, 1])) error stop 5
> +  if (any (shape () /= [15, 12, 2])) error stop 6
> +  if (any (lbound () /= [-4, -3, 1])) error stop 7
> +  if (any (shape () /= [15, 12, 2])) error stop 8
> +  if (any ( /= -)) error stop 5
> +  if (any ( /= reshape ([(i, i = 1, size())], shape( &
> +error stop 6
> +  ptr = c_loc ()
> +  !$omp target data use_device_addr(, ) device(dev)
> +if (any (lbound () /= [-4, -3, 1])) error stop 9
> +if (any (shape () /= [15, 12, 2])) error stop 10
> +if (any (lbound () /= [-4, -3, 1])) error stop 11
> +if (any (shape () /= [15, 12, 2])) error stop 12
> +if (is_shared) then
> +  if (any ( /= -)) error stop 5
> +  if (any ( /= reshape ([(i, i = 1, size())], shape( 
> &
> +error stop 6
> +end if
> +if (is_shared .neqv. c_associated (ptr, c_loc ())) error stop
> +
> +!$omp target has_device_addr(, ) device(dev)
> +   if (any (lbound () /= [-4, -3, 1])) error stop 9
> +   if (any (shape () /= [15, 12, 2])) error stop 10
> +   if (any (lbound () /= [-4, -3, 1])) error stop 11
> +   if (any (shape () /= [15, 12, 2])) error stop 12
> +   if (any ( /= -)) error stop 5
> +   if (any ( /= reshape ([(i, i = 1, size())], 
> shape( &
> + error stop 6
> +!$omp end target
> +  !$omp end target data
> +end do
> +!$omp target exit data map(delete: ) device(dev)
> +deallocate ()
> +  end subroutine test_addr
> +
> +  subroutine test_ptr (, dev)
> +use iso_c_binding
> +integer, target, allocatable :: (:,:,:), (:,:,:)
> +integer, value :: dev
> +integer :: i
> +type(c_ptr) :: ptr
> +logical :: is_shared
> +
> +is_shared = .false.
> +!$omp target device(dev) map(to: is_shared)
> +  is_shared = .true.
> +!$omp end target
> +
> +allocate ((-4:10,-3:8,2))
> +(:,:,:) = reshape ([(-i, i = 1, size())], shape())
> +

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

2022-05-10 Thread Segher Boessenkool
Hi guys,

On Mon, May 09, 2022 at 12:05:51PM +0800, Kewen.Lin wrote:
> on 2022/5/9 09:54, HAO CHEN GUI wrote:
> >   This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
> > Tests show that outputs of xs[min/max]dp are consistent with the standard
> > of C99 fmin/max.

> > gcc/
> > PR target/103605
> > * rs6000.md (unspec): Add UNSPEC_FMAX and UNSPEC_FMIN.
> 
> Nit: one entry for iterator FMINMAX?

It should be
* rs6000.md (FMINMAX): New.

> > (fminmax): New.
> > (minmax_op): Likewise.

Please say "New." when something is new, never "Likewise."

> > (3): New pattern.  Implemented by UNSPEC_FMAX and
> > UNSPEC_FMIN.

Leave out the "Implemented..." part please.

> > +(define_int_iterator FMINMAX [UNSPEC_FMAX UNSPEC_FMIN])
> > +
> > +(define_int_attr fminmax [(UNSPEC_FMAX "fmax")
> > + (UNSPEC_FMIN "fmin")])
> > +
> > +(define_int_attr  minmax_op [(UNSPEC_FMAX "max")
> > +(UNSPEC_FMIN "min")])
> > +
> 
> Can we use the later one for both?
> 
> Like f3.

Yes.  RTL iterators and attributes are textual replacement and expansion
only: there is no deeper semantic meaning to it.  In fact, we should
have only a "minmax" iterator and a "MINMAX" attribute, and then
simplify everything else.  I'll do this for the existing code.

> > +(define_insn "3"
> > +  [(set (match_operand:SFDF 0 "vsx_register_operand" "=")
> > +   (unspec:SFDF [(match_operand:SFDF 1 "vsx_register_operand" "")
> > + (match_operand:SFDF 2 "vsx_register_operand" "")]
> 
> Nit: both SD and DF are mapped to constraint wa, just hardcode Fv to wa?

(SF and DF)

Please keep  until  is gone as well, it is easier to read that
way.  And at that time get rid of *all* .

Indeed we could get rid of it, but only replacing it in some places and
not others is confusing (or at least distracting).

> PR103605 also exposes another problem on bif __builtin_vsx_xs{min,max}dp, 
> both bifs are
> expanded into xs{min,max}cdp instead of xs{min,max}dp starting from power9.
> 
> IMHO, it's something we want to fix as well, based on the reasons:
>   1) bif names have the corresponding mnemonics, users would expect 1-1 
> mapping here.
>   2) clang emits xs{min,max}dp all the time, with cpu type power7/8/9/10.
>   3) according to uarch info, xs{min,max}cdp use the same units and have the 
> same latency,
>  no benefits to replace with xs{min,max}cdp.

I never understood any of this.  Mike?  Why do we do those "c" things
at all, ever?

> So I wonder if it would be more clear with:
>   1) add new define_insn for xs{min,max}dp

No, the existing thing should always do these insns.

>   2) use them for new define_expand of fmin/fmax
>   3) use them for bif expansion pattern

There is no way to express fmin/fmax without unspecs currently (without
fastmath).  This is a serious problem.


Segher


Re: [PATCH] Remove size limit of PCH

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

> Subject: [PATCH] Remove size limit of PCH

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

> Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
> Signed-off-by: LIU Hao 

You'll need to add yourself into "Contributing under the DCO" section in
MAINTAINERS file first to use Signed-off-by, I guess.

A ChangeLog entry should be included in the commit message like

gcc/

PR pch/14940
* config/i386/host-mingw32.cc (pch_VA_max_size): Remove.
(mingw32_gt_pch_get_address): ... ...

I know almost nothing about Windoge/MinGW so the technical review is
left for others.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: [PATCH] PR fortran/105501 - check for non-optional spaces between adjacent keywords

2022-05-10 Thread Mikael Morin

Le 09/05/2022 à 21:34, Harald Anlauf a écrit :

Hi Mikael,

Am 09.05.22 um 20:24 schrieb Mikael Morin:

The fix itself looks good.  Regarding the test, I don’t understand the
problem.  Can’t there be multiple subroutines, each having one (or more)
problematic statement(s)?


that's why I tried but failed.  Example:

subroutine a
   errorstop
end
subroutine b
   errorstop
end

This now gives just one (the first) error, after which it bails out:


Indeed, I think it’s a bug.
I have submitted a PR for it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547

Thanks for the patch.



[PATCH] Remove size limit of PCH

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

Remove the limit and solve https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940.

I have tested the patch on `x86_64-w64-mingw32` with MSVCRT, by pre-compiling a header of many 
standard and boost headers to generate a 313-MiB-large .gch file and using it to compile a simple 
'hello world' program, and seen no problems so far.



After eighteen years this has eventually been settled. (sigh)


--
Best regards,
LIU Hao
From c084ab275f47cc27621e664d1c63e177525cf321 Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Tue, 10 May 2022 13:19:07 +0800
Subject: [PATCH] Remove size limit of PCH

Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
Signed-off-by: LIU Hao 
---
 gcc/config/i386/host-mingw32.cc | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/gcc/config/i386/host-mingw32.cc b/gcc/config/i386/host-mingw32.cc
index 3b0d83ffc60..f915b85abd0 100644
--- a/gcc/config/i386/host-mingw32.cc
+++ b/gcc/config/i386/host-mingw32.cc
@@ -44,9 +44,6 @@ static size_t mingw32_gt_pch_alloc_granularity (void);
 
 static inline void w32_error(const char*, const char*, int, const char*);
 
-/* FIXME: Is this big enough?  */
-static const size_t pch_VA_max_size  = 128 * 1024 * 1024;
-
 /* Granularity for reserving address space.  */
 static size_t va_granularity = 0x1;
 
@@ -88,9 +85,6 @@ static void *
 mingw32_gt_pch_get_address (size_t size, int)
 {
   void* res;
-  size = (size + va_granularity - 1) & ~(va_granularity - 1);
-  if (size > pch_VA_max_size)
-return NULL;
 
   /* FIXME: We let system determine base by setting first arg to NULL.
  Allocating at top of available address space avoids unnecessary
@@ -100,7 +94,7 @@ mingw32_gt_pch_get_address (size_t size, int)
  If we allocate at bottom we need to reserve the address as early
  as possible and at the same point in each invocation. */
  
-  res = VirtualAlloc (NULL, pch_VA_max_size,
+  res = VirtualAlloc (NULL, size,
  MEM_RESERVE | MEM_TOP_DOWN,
  PAGE_NOACCESS);
   if (!res)
@@ -150,7 +144,7 @@ mingw32_gt_pch_use_address (void *, size_t size, int 
fd,
 
   /* Offset must be also be a multiple of allocation granularity for
  this to work.  We can't change the offset. */ 
-  if ((offset & (va_granularity - 1)) != 0 || size > pch_VA_max_size)
+  if ((offset & (va_granularity - 1)) != 0)
 return -1;
 
 
-- 
2.36.0



OpenPGP_signature
Description: OpenPGP digital signature


[PATCH, OpenMP, v2] Implement uses_allocators clause for target regions

2022-05-10 Thread Chung-Lin Tang

On 2022/5/7 12:40 AM, Tobias Burnus wrote:


Can please also handle the new clause in Fortran's dump-parse-tree.cc?

I did see some split handling in C, but not in Fortran; do you also need
to up update gfc_split_omp_clauses in Fortran's trans-openmp.cc?


Done.


Actually, glancing at the testcases, no combined construct (like
"omp target parallel") is used, I think that would be useful because of ↑.


Okay, added some to testcases.


+/* OpenMP 5.2:
+   uses_allocators ( allocator-list )

That's not completely true: uses_allocators is OpenMP 5.1.
However, 5.1 only supports (for non-predefined allocators):
    uses_allocators( allocator(traits) )
while OpenMP 5.2 added modifiers:
    uses_allocatrors( traits(...), memspace(...) : allocator )
and deprecated the 5.1 'allocator(traits)'. (Scheduled for removal in OMP 6.0)

The advantage of 5.2 syntax is that a memory space can be defined.


I supported both syntaxes, that's why I designated it as "5.2".


BTW: This makes uses_allocators the first OpenMP 5.2 feature which
will make it into GCC :-)


:)



gcc/fortran/openmp.cc:

+  if (gfc_get_symbol ("omp_allocator_handle_kind", NULL, )
+  || !sym->value
+  || sym->value->expr_type != EXPR_CONSTANT
+  || sym->value->ts.type != BT_INTEGER)
+    {
+  gfc_error ("OpenMP % constant not found by "
+ "% clause at %C");
+  goto error;
+    }
+  allocator_handle_kind = sym;

I think you rather want to use
   gfc_find_symbol ("omp_...", NULL, true, )
   || sym == NULL
where true is for parent_flag to search also the parent namespace.
(The function returns 1 if the symbol is ambiguous, 0 otherwise -
including 0 + sym == NULL when the symbol could not be found.)

   || sym->attr.flavor != FL_PARAMETER
   || sym->ts.type != BT_INTEGER
   || sym->attr.dimension

Looks cleaner than to access sym->value. The attr.dimension is just
to makes sure the user did not smuggle an array into this.
(Invalid as omp_... is a reserved namespace but users will still do
this and some are good in finding ICE as hobby.)


Well, the intention here is to search for "omp_allocator_handle_kind" and 
"omp_memspace_handle_kind",
and use their value to check if the kinds are the same as declared allocator 
handles and memspace constant.
Not to generally search for "omp_...".

However the sym->attr.dimension test seems useful, added in new v2 patch.


However, I fear that will fail for the following two examples (both untested):

   use omp_lib, my_kind = omp_allocator_handle_kind
   integer(my_kind) :: my_allocator

as this gives 'my_kind' in the symtree->name (while symtree->n.sym->name is 
"omp_...").
Hence, by searching the symtree for 'omp_...' the symbol will not be found.


It will likely also fail for the following more realistic example:

...

subroutine foo
   use m
   use omp_lib, only: omp_alloctrait

...

   !$omp target uses_allocators(my_allocator(traits_array) 
allocate(my_allocator:A) firstprivate(A)
  ...
   !$omp end target
end


If someone wants to use OpenMP allocators, but intentionally only imports 
insufficient standard symbols from omp_lib,
then he/she is on their own :)

The specification really makes this quite clear: omp_allocator_handle_kind, 
omp_alloctrait, omp_memspace_handle_kind are
all part of the same package.


In this case, omp_allocator_handle_kind is not in the namespace of 'foo'
but the code should be still valid. Thus, an alternative would be to hard-code
the value - as done for the depobj. As we have:

     integer, parameter :: omp_allocator_handle_kind = c_intptr_t
     integer, parameter :: omp_memspace_handle_kind = c_intptr_t

that would be
    sym->ts.type == BT_CHARACTER
    sym->ts.kind == gfc_index_integer_kind
for the allocator variable and the the memspace kind.

However, I grant that either example is not very typical. The second one is more
natural – such a code will very likely be written in the real world. But not
with uses_allocators but rather with "!$omp requires dynamic_allocators" and
omp_init_allocator().

Thoughts?


As above. I mean, what is so hard with including "use omp_lib" where you need 
it? :D


* * *

gcc/fortran/openmp.cc

+  if (++i > 2)
+    {
+  gfc_error ("Only two modifiers are allowed on % "
+ "clause at %C");
+  goto error;
+    }
+


Is this really needed? There is a check for multiple traits and multiple 
memspace
Thus, 'trait(),memspace(),trait()' is already handled and
'trait(),something' give a break and will lead to an error as in that case
a ':' and not ',something' is expected.


I think it could be worth reminding that limitation, instead of a generic error.


+  if (gfc_match_char ('(') == MATCH_YES)
+    {
+  if (memspace_seen || traits_seen)
+    {
+  gfc_error ("Modifiers cannot be used with legacy "
+ "array syntax at %C");

I wouldn't uses the term 'array synax' to denote
   uses_allocators(allocator (alloc_array) )
How about:
   error: "Using both 

Re: [PATCH v2] Skip constant folding for fmin/max when either argument is sNaN [PR105414]

2022-05-10 Thread Richard Biener via Gcc-patches
On Tue, May 10, 2022 at 10:10 AM HAO CHEN GUI  wrote:
>
> Hi,
>This patch skips constant folding for fmin/max when either argument
> is sNaN. According to C standard,
>fmin(sNaN, sNaN)= qNaN, fmin(sNaN, NaN) = qNaN
>So signaling NaN should be tested and skipped for fmin/max in match.pd.
>
>The V2 patch splits the for loop and keeps MIN/MAX_EXPR unchanged.
>
>Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
> Is this okay for trunk? Any recommendations? Thanks a lot.

OK.

Richard.

> ChangeLog
> 2022-05-10 Haochen Gui 
>
> gcc/
> PR target/105414
> * match.pd (minmax): Skip constant folding for fmin/fmax when both
> arguments are sNaN or one is sNaN and another is NaN.
>
> gcc/testsuite/
> PR target/105414
> * gcc.dg/pr105414.c: New.
>
>
> patch.diff
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 6d691d302b3..6fb8806412a 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -3095,10 +3095,16 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>
>  /* Simplifications of MIN_EXPR, MAX_EXPR, fmin() and fmax().  */
>
> -(for minmax (min max FMIN_ALL FMAX_ALL)
> +(for minmax (min max)
>   (simplify
>(minmax @0 @0)
>@0))
> +/* For fmin() and fmax(), skip folding when both are sNaN.  */
> +(for minmax (FMIN_ALL FMAX_ALL)
> + (simplify
> +  (minmax @0 @0)
> +  (if (!tree_expr_maybe_signaling_nan_p (@0))
> +@0)))
>  /* min(max(x,y),y) -> y.  */
>  (simplify
>   (min:c (max:c @0 @1) @1)
> @@ -3198,12 +3204,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> (minmax @1 (convert @2)
>
>  (for minmax (FMIN_ALL FMAX_ALL)
> - /* If either argument is NaN, return the other one.  Avoid the
> -transformation if we get (and honor) a signalling NaN.  */
> + /* If either argument is NaN and other one is not sNaN, return the other
> +one.  Avoid the transformation if we get (and honor) a signalling NaN.  
> */
>   (simplify
>(minmax:c @0 REAL_CST@1)
> -  (if (real_isnan (TREE_REAL_CST_PTR (@1))
> -   && (!HONOR_SNANS (@1) || !TREE_REAL_CST (@1).signalling))
> +   (if (real_isnan (TREE_REAL_CST_PTR (@1))
> +   && (!HONOR_SNANS (@1) || !TREE_REAL_CST (@1).signalling)
> +   && !tree_expr_maybe_signaling_nan_p (@0))
> @0)))
>  /* Convert fmin/fmax to MIN_EXPR/MAX_EXPR.  C99 requires these
> functions to return the numeric arg if the other one is NaN.
> diff --git a/gcc/testsuite/gcc.dg/pr105414.c b/gcc/testsuite/gcc.dg/pr105414.c
> new file mode 100644
> index 000..78772700acf
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr105414.c
> @@ -0,0 +1,30 @@
> +/* { dg-do run { target { *-*-linux* *-*-gnu* } } } */
> +/* { dg-options "-O1 -fsignaling-nans -lm" } */
> +/* { dg-add-options ieee } */
> +/* { dg-require-effective-target issignaling } */
> +
> +
> +#define _GNU_SOURCE
> +#include 
> +#include 
> +
> +int main()
> +{
> +  double a = __builtin_nans ("");
> +
> +  if (issignaling (fmin (a, a)))
> +__builtin_abort ();
> +
> +  if (issignaling (fmax (a, a)))
> +__builtin_abort ();
> +
> +  double b = __builtin_nan ("");
> +
> +  if (issignaling (fmin (a, b)))
> +__builtin_abort ();
> +
> +  if (issignaling (fmax (a, b)))
> +__builtin_abort ();
> +
> +  return 0;
> +}


[c++] Disambiguate ModuleKind flags

2022-05-10 Thread Nathan Sidwell

In modules, 'attached to global module' nearly always means 'not in
module purview'.  Also the implementation treats, 'in global module &&
in module purview' as meaning 'header unit'.  The ModuleKind flags
reflected that.  The 'nearly always' means there are cases that the
first condition is not invariant, and that of course invalidates the
second equivalence.

This disambiguates the ModuleKind flags to allow that 'not quite', and
separate out header-unitness from the GMF & purview flags combination.

1) Separate out named-module vs header-unit from the MODULE/GLOBAL flags.

2) Replace the MODULE/GLOBAL flags with PURVIEW & ATTACH flags.

3) Adjust the parser state handling.

Lays ground-work for language-declaration changes.

nathan

--
Nathan SidwellFrom 92d6a0d28bff543bb2ccb9d9ccadb9ef3349ee29 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell 
Date: Mon, 9 May 2022 04:40:43 -0700
Subject: [PATCH] [c++] Disambiguate ModuleKind flags

In modules, 'attached to global module' nearly always means 'not in
module purview'.  Also the implementation treats, 'in global module &&
in module purview' as meaning 'header unit'.  The ModuleKind flags
reflected that.  The 'nearly always' means there are cases that the
first condition is not invariant, and that of course invalidates the
second equivalence.

This disambiguates the ModuleKind flags to allow that 'not quite', and
separate out header-unitness from the GMF & purview flags combination.

1) Separate out named-module vs header-unit from the MODULE/GLOBAL flags.

2) Replace the MODULE/GLOBAL flags with PURVIEW & ATTACH flags.

3) Adjust the parser state handling.

Lays ground-work for language-declaration changes.

	gcc/cp/
	* cp-tree.h (enum module_kind_bits): Disambiguate purview,
	attach, named module vs header-unit.
	(global_purview_p, not_module_p): Delete.
	(named_module_p): New.
	(header_module_p, module_purview_p): Adjust.
	(module_attach_p, named_module_purview_p): New.
	* decl.cc (duplicate_decls): Adjust.
	* module.cc (declare_module, preprocessed_module): Adjust.
	* name-lookup.cc (init_global_partition): Adjust.
	(get_fixed_binding_slot, pushdecl): Adjust.
	* parser.cc (cp_parser_module_declaration): Adjust.
	(cp_parser_import_declaration, cp_parser_declaration): Adjust.
---
 gcc/cp/cp-tree.h  | 51 +++---
 gcc/cp/decl.cc|  2 +-
 gcc/cp/module.cc  | 29 +++-
 gcc/cp/name-lookup.cc | 24 ++--
 gcc/cp/parser.cc  | 52 ++-
 5 files changed, 76 insertions(+), 82 deletions(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 9fb07d8ea39..8a5057a4dff 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1720,7 +1720,8 @@ check_constraint_info (tree t)
 #define DECL_MODULE_CHECK(NODE)		\
   TREE_NOT_CHECK (NODE, TEMPLATE_DECL)
 
-/* In the purview of a module (including header unit).  */
+/* In the purview of a named module (or in the purview of the
+   header-unit being compiled).  */
 #define DECL_MODULE_PURVIEW_P(N) \
   (DECL_LANG_SPECIFIC (DECL_MODULE_CHECK (N))->u.base.module_purview_p)
 
@@ -7137,40 +7138,26 @@ inline bool modules_p () { return flag_modules != 0; }
 /* The kind of module or part thereof that we're in.  */
 enum module_kind_bits
 {
-  MK_MODULE = 1 << 0, /* This TU is a module.  */
-  MK_GLOBAL = 1 << 1, /* Entities are in the global module.  */
-  MK_INTERFACE = 1 << 2,  /* This TU is an interface.  */
-  MK_PARTITION = 1 << 3,  /* This TU is a partition.  */
-  MK_EXPORTING = 1 << 4,  /* We are in an export region.  */
+  MK_NAMED = 1 << 0,	// TU is a named module
+  MK_HEADER = 1 << 1,	// TU is a header unit
+  MK_INTERFACE = 1 << 2,  // TU is an interface
+  MK_PARTITION = 1 << 3,  // TU is a partition
+
+  MK_PURVIEW = 1 << 4,	// In purview of current module
+  MK_ATTACH = 1 << 5,	// Attaching to named module
+
+  MK_EXPORTING = 1 << 6,  /* We are in an export region.  */
 };
 
 /* We do lots of bit-manipulation, so an unsigned is easier.  */
 extern unsigned module_kind;
 
-/*  MK_MODULE & MK_GLOBAL have the following combined meanings:
- MODULE GLOBAL
-   0	  0	not a module
-   0	  1	GMF of named module (we've not yet seen module-decl)
-   1	  0	purview of named module
-   1	  1	header unit.   */
-
-inline bool module_purview_p ()
-{ return module_kind & MK_MODULE; }
-inline bool global_purview_p ()
-{ return module_kind & MK_GLOBAL; }
-
-inline bool not_module_p ()
-{ return (module_kind & (MK_MODULE | MK_GLOBAL)) == 0; }
+inline bool module_p ()
+{ return module_kind & (MK_NAMED | MK_HEADER); }
 inline bool named_module_p ()
-{ /* This is a named module if exactly one of MODULE and GLOBAL is
- set.  */
-  /* The divides are constant shifts!  */
-  return ((module_kind / MK_MODULE) ^ (module_kind / MK_GLOBAL)) & 1;
-}
+{ return module_kind & MK_NAMED; }
 inline bool header_module_p ()
-{ return (module_kind & (MK_MODULE | MK_GLOBAL)) == (MK_MODULE | MK_GLOBAL); }
-inline bool 

[PATCH] middle-end/105537 - debug processing

2022-05-10 Thread Richard Biener via Gcc-patches
The following makes sure to have a consistent state of
flag_var_tracking_assignments with the distributed handling
in process_options and finish_options by moving everything to
finish_options which also restores diagnostics for
-g0 -fvar-tracking which was lost with previous changes.

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

2022-05-10  Richard Biener  

PR middle-end/105537
* toplev.cc (process_options): Move flag_var_tracking
handling ...
* opts.cc (finish_options): ... here.

* gcc.dg/torture/pr105537.c: New testcase.
---
 gcc/opts.cc | 27 +---
 gcc/testsuite/gcc.dg/torture/pr105537.c | 34 +
 gcc/toplev.cc   | 24 -
 3 files changed, 57 insertions(+), 28 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr105537.c

diff --git a/gcc/opts.cc b/gcc/opts.cc
index a0baec98092..c9badd241a0 100644
--- a/gcc/opts.cc
+++ b/gcc/opts.cc
@@ -1333,10 +1333,29 @@ finish_options (struct gcc_options *opts, struct 
gcc_options *opts_set,
 && !(opts->x_flag_selective_scheduling
  || opts->x_flag_selective_scheduling2));
 
-  /* Note -fvar-tracking is enabled automatically with OPT_LEVELS_1_PLUS and
- so we need to drop it if we are called from optimize attribute.  */
-  if (opts->x_debug_info_level < DINFO_LEVEL_NORMAL)
-opts->x_flag_var_tracking = false;
+  /* We know which debug output will be used so we can set flag_var_tracking
+ and flag_var_tracking_uninit if the user has not specified them.  Note
+ we have not yet initialized debug_hooks so we might uselessly run
+ var-tracking on targets without var_location debug hook support.  */
+  if (opts->x_debug_info_level < DINFO_LEVEL_NORMAL
+  || !dwarf_debuginfo_p (opts))
+{
+  if ((opts_set->x_flag_var_tracking && opts->x_flag_var_tracking == 1)
+ || (opts_set->x_flag_var_tracking_uninit
+ && opts->x_flag_var_tracking_uninit == 1))
+   {
+ if (opts->x_debug_info_level < DINFO_LEVEL_NORMAL)
+   warning_at (UNKNOWN_LOCATION, 0,
+   "variable tracking requested, but useless unless "
+   "producing debug info");
+ else
+   warning_at (UNKNOWN_LOCATION, 0,
+   "variable tracking requested, but not supported "
+   "by this debug format");
+   }
+  opts->x_flag_var_tracking = 0;
+  opts->x_flag_var_tracking_uninit = 0;
+}
 
   /* One could use EnabledBy, but it would lead to a circular dependency.  */
   if (!opts_set->x_flag_var_tracking_uninit)
diff --git a/gcc/testsuite/gcc.dg/torture/pr105537.c 
b/gcc/testsuite/gcc.dg/torture/pr105537.c
new file mode 100644
index 000..2e4825c4720
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr105537.c
@@ -0,0 +1,34 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-ffast-math -fsignaling-nans 
-fvar-tracking-assignments -fno-move-loop-stores -ftree-loop-distribution" } */
+
+int n;
+
+double
+ext1 (int);
+
+void
+ext2 (double);
+
+int
+sum (int v1, int v2)
+{
+  return v1 + v2;
+}
+
+void
+bar (void)
+{
+  ext2 (ext1 (n));
+}
+
+__attribute__ ((optimize ("-O3"))) void
+foo (int *x)
+{
+  static int i;
+
+  bar ();
+  for (i = 0; i != 2; i = sum (i, 1))
+n = *x = 0;
+}
+
+/* { dg-message "other options take precedence" "" { target *-*-* } 0 } */
diff --git a/gcc/toplev.cc b/gcc/toplev.cc
index ed546b2cad8..055e0642f77 100644
--- a/gcc/toplev.cc
+++ b/gcc/toplev.cc
@@ -1458,30 +1458,6 @@ process_options (bool no_backend)
debug_type_names[debug_set_to_format (write_symbols)]);
 }
 
-  /* We know which debug output will be used so we can set flag_var_tracking
- and flag_var_tracking_uninit if the user has not specified them.  */
-  if (debug_info_level < DINFO_LEVEL_NORMAL
-  || !dwarf_debuginfo_p ()
-  || debug_hooks->var_location == do_nothing_debug_hooks.var_location)
-{
-  if ((OPTION_SET_P (flag_var_tracking) && flag_var_tracking == 1)
- || (OPTION_SET_P (flag_var_tracking_uninit)
- && flag_var_tracking_uninit == 1))
-{
- if (debug_info_level < DINFO_LEVEL_NORMAL)
-   warning_at (UNKNOWN_LOCATION, 0,
-   "variable tracking requested, but useless unless "
-   "producing debug info");
- else
-   warning_at (UNKNOWN_LOCATION, 0,
-   "variable tracking requested, but not supported "
-   "by this debug format");
-   }
-  flag_var_tracking = 0;
-  flag_var_tracking_uninit = 0;
-  flag_var_tracking_assignments = 0;
-}
-
   /* The debug hooks are used to implement -fdump-go-spec because it
  gives a simple and stable API for all the information we need to
  dump.  */
-- 
2.35.3


Re: [PATCH] Remove non-ANSI C macros in ansidecl.h.

2022-05-10 Thread Martin Liška
On 5/10/22 11:55, Andreas Schwab wrote:
> The header line should probably be changed since it's no longer about
> ANSI or traditional C.
> 

Sure, updated in v2.

MartinFrom 9359921cd29f9ec4f7536f49160ad54b74e0214a Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 10 May 2022 09:47:08 +0200
Subject: [PATCH] Remove non-ANSI C macros in ansidecl.h.

include/ChangeLog:

	* ansidecl.h (PTR): Remove.
	(const): Likewise.
	(volatile): Likewise.
	(signed): Likewise.
---
 include/ansidecl.h | 28 ++--
 1 file changed, 2 insertions(+), 26 deletions(-)

diff --git a/include/ansidecl.h b/include/ansidecl.h
index efee5b6904b..8fc858cad7e 100644
--- a/include/ansidecl.h
+++ b/include/ansidecl.h
@@ -1,4 +1,4 @@
-/* ANSI and traditional C compatability macros
+/* Compiler compatability macros
Copyright (C) 1991-2022 Free Software Foundation, Inc.
This file is part of the GNU C Library.
 
@@ -16,18 +16,7 @@ You should have received a copy of the GNU General Public License
 along with this program; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA.  */
 
-/* ANSI and traditional C compatibility macros
-
-   ANSI C is assumed if __STDC__ is #defined.
-
-   Macro		ANSI C definition	Traditional C definition
-   -		 - --	--- - --
-   PTR			`void *'		`char *'
-   const		not defined		`'
-   volatile		not defined		`'
-   signed		not defined		`'
-
-   For ease of writing code which uses GCC extensions but needs to be
+/* For ease of writing code which uses GCC extensions but needs to be
portable to other compilers, we provide the GCC_VERSION macro that
simplifies testing __GNUC__ and __GNUC_MINOR__ together, and various
wrappers around __attribute__.  Also, __extension__ will be #defined
@@ -62,19 +51,6 @@ So instead we use the macro below and test it against specific values.  */
 #define GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__)
 #endif /* GCC_VERSION */
 
-/* All known AIX compilers implement these things (but don't always
-   define __STDC__).  The RISC/OS MIPS compiler defines these things
-   in SVR4 mode, but does not define __STDC__.  */
-/* erax...@alumni.rice.edu: The Compaq C++ compiler, unlike many other
-   C++ compilers, does not define __STDC__, though it acts as if this
-   was so. (Verified versions: 5.7, 6.2, 6.3, 6.5) */
-
-#define PTR		void *
-
-#undef const
-#undef volatile
-#undef signed
-
 /* inline requires special treatment; it's in C99, and GCC >=2.7 supports
it too, but it's not in C89.  */
 #undef inline
-- 
2.36.0



Re: [patch gcc13] middle-end/70090: Dynamic sizes for -fsanitize=object-size

2022-05-10 Thread Martin Liška
On 5/9/22 09:37, Jakub Jelinek via Gcc-patches wrote:
> On Mon, May 09, 2022 at 01:02:07PM +0530, Siddhesh Poyarekar wrote:
>> On 07/02/2022 17:37, Jakub Jelinek wrote:
>>> On Mon, Feb 07, 2022 at 05:31:58PM +0530, Siddhesh Poyarekar wrote:
 Use __builtin_dynamic_object_size to get object sizes for ubsan.

 gcc/ChangeLog:

middle-end/70090
* ubsan.cc (ubsan_expand_objsize_ifn): Allow non-constant SIZE.
(instrument_object_size): Get dynamic object size expression.

 gcc/testsuite/ChangeLog:

middle-end/70090
* gcc.dg/ubsan/object-size-dyn.c: New test.

 Signed-off-by: Siddhesh Poyarekar 
 ---
 Proposing for gcc13 since I reckoned this is not feasible for stage 4.
>>>
>>> Ok for stage1.
>>>
>>> Jakub
>>>
>>
>> Hi Jakub, may I rebase and push this now?
> 
> Yes.
> 
>   Jakub
> 

Hi.

The revision caused:

$ ./xgcc -B. 
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/ubsan/bind-c-intent-out-2.f90
 -fsanitize=undefined -c -O
during GIMPLE pass: ubsan
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/ubsan/bind-c-intent-out-2.f90:39:19:

   39 | end program alloc_p
  |   ^
internal compiler error: Segmentation fault
0x14b45c7 crash_signal
/home/marxin/Programming/gcc/gcc/toplev.cc:322
0x778b83cf ???

/usr/src/debug/glibc-2.35-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xc2cf10 contains_struct_check(tree_node*, tree_node_structure_enum, char 
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3570
0x19100d1 build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**)
/home/marxin/Programming/gcc/gcc/tree.cc:10629
0x19102ff build_call_expr_loc(unsigned int, tree_node*, int, ...)
/home/marxin/Programming/gcc/gcc/tree.cc:10662
0x14f59a3 instrument_object_size
/home/marxin/Programming/gcc/gcc/ubsan.cc:2173
0x14f6770 execute
/home/marxin/Programming/gcc/gcc/ubsan.cc:2428
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Martin


Re: [PATCH] Replace PTR with 'void *' in compiler.

2022-05-10 Thread Arnaud Charlet via Gcc-patches
> > Similarly in GCC itself. I've built all FEs with the patch.
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >
> > Ready to be installed?
> 
> OK for the middle-end parts.

and OK for the Ada parts.


Re: [PATCH 02/10] aarch64: Add backend support for DFP

2022-05-10 Thread Christophe Lyon via Gcc-patches




On 5/10/22 11:30, Richard Sandiford wrote:

Richard Sandiford  writes:

The patch changes the scalar handling in aapcs_vfp_sub_candidate,
but not the complex handling.  Is that deliberate?


TIL: we don't support complex decimal floats.  So never mind that :-)


Indeed. Sorry, maybe I should have made this clear in the commit message.


Richard


Re: [PATCH] Replace PTR with 'void *' in compiler.

2022-05-10 Thread Richard Biener via Gcc-patches
On Tue, May 10, 2022 at 11:38 AM Martin Liška  wrote:
>
> Similarly in GCC itself. I've built all FEs with the patch.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?

OK for the middle-end parts.

Richard.

> Thanks,
> Martin
>
> gcc/ada/ChangeLog:
>
> * gcc-interface/decl.cc (compare_field_bitpos): Use void *
> instead PTR.
> * gcc-interface/utils2.cc (compare_elmt_bitpos): Likewise.
>
> gcc/ChangeLog:
>
> * basic-block.h (struct basic_block_d): Use void *
> instead PTR.
> * cfgloop.h: Likewise.
> * cgraph.h: Likewise.
> * gengtype-state.cc (state_ident_by_name): Likewise.
> (record_type): Likewise.
> (read_state_already_seen_type): Likewise.
> * gengtype.cc (dump_type): Likewise.
> (input_file_by_name): Likewise.
> (main): Likewise.
> * ggc-common.cc (ggc_cleared_alloc_ptr_array_two_args): Likewise.
> * ipa-utils.h (struct ipa_dfs_info): Likewise.
> * plugin.cc (htab_hash_plugin): Likewise.
> ---
>  gcc/ada/gcc-interface/decl.cc   | 4 ++--
>  gcc/ada/gcc-interface/utils2.cc | 2 +-
>  gcc/basic-block.h   | 4 ++--
>  gcc/cfgloop.h   | 2 +-
>  gcc/cgraph.h| 4 ++--
>  gcc/gengtype-state.cc   | 6 +++---
>  gcc/gengtype.cc | 6 +++---
>  gcc/ggc-common.cc   | 4 ++--
>  gcc/ipa-utils.h | 2 +-
>  gcc/plugin.cc   | 2 +-
>  10 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/gcc/ada/gcc-interface/decl.cc b/gcc/ada/gcc-interface/decl.cc
> index 1c7a716840e..d52c4fb3623 100644
> --- a/gcc/ada/gcc-interface/decl.cc
> +++ b/gcc/ada/gcc-interface/decl.cc
> @@ -224,7 +224,7 @@ static bool constructor_address_p (tree);
>  static bool allocatable_size_p (tree, bool);
>  static bool initial_value_needs_conversion (tree, tree);
>  static tree update_n_elem (tree, tree, tree);
> -static int compare_field_bitpos (const PTR, const PTR);
> +static int compare_field_bitpos (const void *, const void *);
>  static bool components_to_record (Node_Id, Entity_Id, tree, tree, int, bool,
>   bool, bool, bool, bool, bool, bool, tree,
>   tree *);
> @@ -7712,7 +7712,7 @@ field_has_variable_size (tree field)
>  /* qsort comparer for the bit positions of two record components.  */
>
>  static int
> -compare_field_bitpos (const PTR rt1, const PTR rt2)
> +compare_field_bitpos (const void *rt1, const void *rt2)
>  {
>const_tree const field1 = * (const_tree const *) rt1;
>const_tree const field2 = * (const_tree const *) rt2;
> diff --git a/gcc/ada/gcc-interface/utils2.cc b/gcc/ada/gcc-interface/utils2.cc
> index e5cd85662b9..76622da8081 100644
> --- a/gcc/ada/gcc-interface/utils2.cc
> +++ b/gcc/ada/gcc-interface/utils2.cc
> @@ -1936,7 +1936,7 @@ build_call_raise_range (int msg, Node_Id gnat_node, 
> char kind,
> for record components.  */
>
>  static int
> -compare_elmt_bitpos (const PTR rt1, const PTR rt2)
> +compare_elmt_bitpos (const void *rt1, const void *rt2)
>  {
>const constructor_elt * const elmt1 = (const constructor_elt *) rt1;
>const constructor_elt * const elmt2 = (const constructor_elt *) rt2;
> diff --git a/gcc/basic-block.h b/gcc/basic-block.h
> index 21a9b24dbf9..c9d1fc91bbb 100644
> --- a/gcc/basic-block.h
> +++ b/gcc/basic-block.h
> @@ -36,7 +36,7 @@ public:
>} insns;
>
>/* Auxiliary info specific to a pass.  */
> -  PTR aux;
> +  void *aux;
>
>/* Location of any goto implicit in the edge.  */
>location_t goto_locus;
> @@ -120,7 +120,7 @@ struct GTY((chain_next ("%h.next_bb"), chain_prev 
> ("%h.prev_bb"))) basic_block_d
>vec *succs;
>
>/* Auxiliary info specific to a pass.  */
> -  PTR GTY ((skip (""))) aux;
> +  void *GTY ((skip (""))) aux;
>
>/* Innermost loop containing the block.  */
>class loop *loop_father;
> diff --git a/gcc/cfgloop.h b/gcc/cfgloop.h
> index d2714e20cb0..528b1219bc3 100644
> --- a/gcc/cfgloop.h
> +++ b/gcc/cfgloop.h
> @@ -148,7 +148,7 @@ public:
>class loop *next;
>
>/* Auxiliary info specific to a pass.  */
> -  PTR GTY ((skip (""))) aux;
> +  void *GTY ((skip (""))) aux;
>
>/* The number of times the latch of the loop is executed.  This can be an
>   INTEGER_CST, or a symbolic expression representing the number of
> diff --git a/gcc/cgraph.h b/gcc/cgraph.h
> index 8c512b648ee..4be67e3cea9 100644
> --- a/gcc/cgraph.h
> +++ b/gcc/cgraph.h
> @@ -628,7 +628,7 @@ public:
>/* File stream where this node is being written to.  */
>struct lto_file_decl_data * lto_file_data;
>
> -  PTR GTY ((skip)) aux;
> +  void *GTY ((skip)) aux;
>
>/* Comdat group the symbol is in.  Can be private if GGC allowed that.  */
>tree x_comdat_group;
> @@ -1895,7 +1895,7 @@ public:
>/* Additional information about an indirect call.  Not cleared when an edge
>   

Re: [PATCH] isel: Fix up gimple_expand_vec_set_expr [PR105528]

2022-05-10 Thread Richard Biener via Gcc-patches
On Tue, 10 May 2022, Jakub Jelinek wrote:

> Hi!
> 
> The following testcase ICEs (and only without -g), because we don't replace
> one VEC_COND_EXPR with .VCOND* call.
> We don't do that because gimple_expand_vec_set_expr adds some stmts before
> *gsi and then uses gsi_remove to remove it.  gsi_remove moves the iterator
> to the next stmt and in the caller we then do gsi_next before looking at
> another stmt, which means we can skip processing of one stmt, which in this
> case happened to be a VEC_COND_EXPR but with -g is some debug stmt in
> between.  As we always emit some stmts before it, it is easy to update the
> iterator to the last stmt emitted there, so that caller continues really
> with the next stmt.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Richard.

> 2022-05-10  Jakub Jelinek  
> 
>   PR tree-optimization/105528
>   * gimple-isel.cc (gimple_expand_vec_set_expr): After gsi_remove
>   set *gsi to gsi_for_stmt (ass_stmt).  Fix up function comment.
> 
>   * gcc.dg/pr105528.c: New test.
> 
> --- gcc/gimple-isel.cc.jj 2022-05-09 09:09:20.386472253 +0200
> +++ gcc/gimple-isel.cc2022-05-09 11:28:27.295925124 +0200
> @@ -43,7 +43,7 @@ along with GCC; see the file COPYING3.
>  /* Expand all ARRAY_REF(VIEW_CONVERT_EXPR) gimple assignments into calls to
> internal function based on vector type of selected expansion.
> i.e.:
> - VIEW_CONVERT_EXPR(u)[_1] =  = i_4(D);
> + VIEW_CONVERT_EXPR(u)[_1] = i_4(D);
> =>
>   _7 = u;
>   _8 = .VEC_SET (_7, i_4(D), _1);
> @@ -104,6 +104,7 @@ gimple_expand_vec_set_expr (struct funct
> if (gsi_remove (gsi, true)
> && gimple_purge_dead_eh_edges (bb))
>   cfg_changed = true;
> +   *gsi = gsi_for_stmt (ass_stmt);
>   }
>  }
>  
> --- gcc/testsuite/gcc.dg/pr105528.c.jj2022-05-09 11:30:09.476529621 
> +0200
> +++ gcc/testsuite/gcc.dg/pr105528.c   2022-05-09 11:30:35.091179163 +0200
> @@ -0,0 +1,23 @@
> +/* PR tree-optimization/105528 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -Wno-psabi -fcompare-debug" } */
> +/* { dg-additional-options "-mavx512f" { target i?86-*-* x86_64-*-* } } */
> +
> +typedef unsigned V __attribute__((__vector_size__ (64)));
> +V g;
> +
> +V
> +bar (V v)
> +{
> +  V w;
> +  v <<= (V){(V){}[53]} >= v & 5;
> +  w[w[5]] -= ~0;
> +  v %= ~0;
> +  return v + w;
> +}
> +
> +void
> +foo (void)
> +{
> +  g -= (V){bar((V){~0})[3]};
> +}
> 
>   Jakub
> 
> 

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


Re: [PATCH] Remove non-ANSI C macros in ansidecl.h.

2022-05-10 Thread Andreas Schwab
The header line should probably be changed since it's no longer about
ANSI or traditional C.

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


[PATCH] Properly use opts in finish_options

2022-05-10 Thread Richard Biener via Gcc-patches
When code was moved from process_options to finish_options it
was not properly adjusted to look at and alter the opts set
passed to the function but continued to modify the global options
set.  The following rectifies this and makes sure the same
mistake isn't repeated by poisoning global_options{,_set}.

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

2022-05-10  Richard Biener  

* flags.h (dwarf_debuginfo_p): Add opts argument, guard
API with !GENERATOR_FILE.
* opts.cc (global_options): Poison.
(global_options_set): Likewise.
(finish_options): Refer to options via opts.
---
 gcc/flags.h |  4 +++-
 gcc/opts.cc | 67 ++---
 2 files changed, 41 insertions(+), 30 deletions(-)

diff --git a/gcc/flags.h b/gcc/flags.h
index a9381cf93f2..212e357a0fd 100644
--- a/gcc/flags.h
+++ b/gcc/flags.h
@@ -40,6 +40,7 @@ unsigned int debug_set_count (uint32_t w_symbols);
 
 const char * debug_set_names (uint32_t w_symbols);
 
+#ifndef GENERATOR_FILE
 /* Return true iff BTF debug info is enabled.  */
 
 extern bool btf_debuginfo_p ();
@@ -54,12 +55,13 @@ extern bool ctf_debuginfo_p ();
 
 /* Return true iff DWARF2 debug info is enabled.  */
 
-extern bool dwarf_debuginfo_p ();
+extern bool dwarf_debuginfo_p (struct gcc_options *opts = _options);
 
 /* Return true iff the debug info format is to be generated based on DWARF
DIEs (like CTF and BTF debug info formats).  */
 
 extern bool dwarf_based_debuginfo_p ();
+#endif
 
 extern void strip_off_ending (char *, int);
 extern int base_of_path (const char *path, const char **base_out);
diff --git a/gcc/opts.cc b/gcc/opts.cc
index 2ffbf429b7b..a0baec98092 100644
--- a/gcc/opts.cc
+++ b/gcc/opts.cc
@@ -157,9 +157,9 @@ ctf_debuginfo_p ()
 /* Return TRUE iff dwarf2 debug info is enabled.  */
 
 bool
-dwarf_debuginfo_p ()
+dwarf_debuginfo_p (struct gcc_options *opts)
 {
-  return (write_symbols & DWARF2_DEBUG);
+  return (opts->x_write_symbols & DWARF2_DEBUG);
 }
 
 /* Return true iff the debug info format is to be generated based on DWARF
@@ -171,6 +171,11 @@ bool dwarf_based_debuginfo_p ()
  || (write_symbols & BTF_DEBUG));
 }
 
+/* All flag uses below need to explicitely reference the option sets
+   to operate on.  */
+#define global_options DO_NOT_USE
+#define global_options_set DO_NOT_USE
+
 /* Parse the -femit-struct-debug-detailed option value
and set the flag variables. */
 
@@ -1305,57 +1310,61 @@ finish_options (struct gcc_options *opts, struct 
gcc_options *opts_set,
 SET_OPTION_IF_UNSET (opts, opts_set, flag_vect_cost_model,
 VECT_COST_MODEL_CHEAP);
 
-  if (flag_gtoggle)
+  if (opts->x_flag_gtoggle)
 {
   /* Make sure to process -gtoggle only once.  */
-  flag_gtoggle = false;
-  if (debug_info_level == DINFO_LEVEL_NONE)
+  opts->x_flag_gtoggle = false;
+  if (opts->x_debug_info_level == DINFO_LEVEL_NONE)
{
- debug_info_level = DINFO_LEVEL_NORMAL;
+ opts->x_debug_info_level = DINFO_LEVEL_NORMAL;
 
- if (write_symbols == NO_DEBUG)
-   write_symbols = PREFERRED_DEBUGGING_TYPE;
+ if (opts->x_write_symbols == NO_DEBUG)
+   opts->x_write_symbols = PREFERRED_DEBUGGING_TYPE;
}
   else
-   debug_info_level = DINFO_LEVEL_NONE;
+   opts->x_debug_info_level = DINFO_LEVEL_NONE;
 }
 
   if (!opts_set->x_debug_nonbind_markers_p)
-debug_nonbind_markers_p
-  = (optimize
-&& debug_info_level >= DINFO_LEVEL_NORMAL
-&& dwarf_debuginfo_p ()
-&& !(flag_selective_scheduling || flag_selective_scheduling2));
+opts->x_debug_nonbind_markers_p
+  = (opts->x_optimize
+&& opts->x_debug_info_level >= DINFO_LEVEL_NORMAL
+&& dwarf_debuginfo_p (opts)
+&& !(opts->x_flag_selective_scheduling
+ || opts->x_flag_selective_scheduling2));
 
   /* Note -fvar-tracking is enabled automatically with OPT_LEVELS_1_PLUS and
  so we need to drop it if we are called from optimize attribute.  */
-  if (debug_info_level < DINFO_LEVEL_NORMAL)
-flag_var_tracking = false;
+  if (opts->x_debug_info_level < DINFO_LEVEL_NORMAL)
+opts->x_flag_var_tracking = false;
 
   /* One could use EnabledBy, but it would lead to a circular dependency.  */
   if (!opts_set->x_flag_var_tracking_uninit)
- flag_var_tracking_uninit = flag_var_tracking;
+opts->x_flag_var_tracking_uninit = opts->x_flag_var_tracking;
 
   if (!opts_set->x_flag_var_tracking_assignments)
-flag_var_tracking_assignments
-  = (flag_var_tracking
-&& !(flag_selective_scheduling || flag_selective_scheduling2));
+opts->x_flag_var_tracking_assignments
+  = (opts->x_flag_var_tracking
+&& !(opts->x_flag_selective_scheduling
+ || opts->x_flag_selective_scheduling2));
 
-  if (flag_var_tracking_assignments_toggle)
-flag_var_tracking_assignments = !flag_var_tracking_assignments;
+  if 

Re: [PATCH 00/10] Enable Decimal Floating Point (DFP) on AArch64

2022-05-10 Thread Richard Sandiford via Gcc-patches
Christophe Lyon via Gcc-patches  writes:
> This patch series enables support of DFP on AArch64, using the BID
> format (Binary Integer Decimal).  There is no HW support for DFP on
> AArch64, and we made a choice similar to x86: BID format using
> libgcc's libbid for software emulation.
>
> This work was done independently from Andrew's patch, which I
> discovered some time after I started [1].  The essence is similar
> although the AArch64 back-end evolved quite a bit since then, and I add
> several tests.
>
> The ABI has been documented a few months ago: _Decimal32 is treated
> like float, _Decimal64 is treated like double and _Decimal128 is
> treated like long double, using the same registers and conventions
> (sN, dN, qN, varargs handling).
>
> I have patches for GDB, which I'll send once this series is committed
> in GCC since the first GDB patch is to merge the libdecnumber updated.
>
> As of testing, I have also used libdfp, which required only a couple
> of minor patches, and its testsuite passes.
>
> I have tested the whole series on aarch64, aarch64_be and x86_64, no
> regression, all the DFP tests pass.
>
> OK?

OK for parts 1, 3-7 and 10.  Joseph should have the final say on part 9.

Thanks,
Richard

>
> Thanks,
> Christophe
>
>
>
> [1] https://gcc.gnu.org/legacy-ml/gcc-patches/2017-07/msg00788.html
>
> Christophe Lyon (10):
>   aarch64: Enable DFP (Decimal Floating-point) (BID format)
>   aarch64: Add backend support for DFP
>   libgcc: Enable XF mode conversions to/from DFP modes only if supported
>   libgcc: enable DFP for AArch64
>   testsuite:: Fix pr39986.c testcase for AArch64
>   testsuite: Add new tests for DFP under aarch64/aapcs64
>   testsuite: enable more BID DFP tests for AArch64
>   testsuite: Add C++ unwinding tests with Decimal Floating-Point
>   libgcc: Add support for HF mode (aka __fp16) in libbid
>   libgcc: use __builtin_clz and __builtin_ctz in libbid
>
>  config/dfp.m4 |   3 +-
>  gcc/config/aarch64/aarch64.cc |  95 ++---
>  gcc/config/aarch64/aarch64.md |  86 ++--
>  gcc/config/aarch64/iterators.md   |  28 +++-
>  gcc/configure |   3 +-
>  gcc/doc/sourcebuild.texi  |   3 +
>  gcc/testsuite/c-c++-common/dfp/pr39986.c  |  22 +--
>  gcc/testsuite/g++.dg/eh/dfp-1.C   |  54 +++
>  gcc/testsuite/g++.dg/eh/dfp-2.C   |  54 +++
>  gcc/testsuite/g++.dg/eh/dfp-saves-aarch64.C   |  49 +++
>  .../gcc.dg/dfp/bid-non-canonical-d128-1.c |   3 +-
>  .../gcc.dg/dfp/bid-non-canonical-d128-2.c |   3 +-
>  .../gcc.dg/dfp/bid-non-canonical-d128-3.c |   3 +-
>  .../gcc.dg/dfp/bid-non-canonical-d128-4.c |   3 +-
>  .../gcc.dg/dfp/bid-non-canonical-d32-1.c  |   3 +-
>  .../gcc.dg/dfp/bid-non-canonical-d32-2.c  |   3 +-
>  .../gcc.dg/dfp/bid-non-canonical-d64-1.c  |   3 +-
>  .../gcc.dg/dfp/bid-non-canonical-d64-2.c  |   3 +-
>  .../gcc.target/aarch64/aapcs64/aapcs64.exp|   8 ++
>  .../gcc.target/aarch64/aapcs64/dfp-1.c|  24 
>  .../gcc.target/aarch64/aapcs64/func-ret-1.c   |   7 +
>  .../gcc.target/aarch64/aapcs64/func-ret-3.c   |  67 +
>  .../gcc.target/aarch64/aapcs64/ice_dfp_5.c|  20 +++
>  .../aarch64/aapcs64/test_align_dfp-1.c| 126 +
>  .../aarch64/aapcs64/test_align_dfp-4.c|  42 ++
>  .../gcc.target/aarch64/aapcs64/test_dfp_1.c   |  31 
>  .../gcc.target/aarch64/aapcs64/test_dfp_10.c  |  26 
>  .../gcc.target/aarch64/aapcs64/test_dfp_11.c  |  34 +
>  .../gcc.target/aarch64/aapcs64/test_dfp_12.c  |  44 ++
>  .../gcc.target/aarch64/aapcs64/test_dfp_13.c  |  34 +
>  .../gcc.target/aarch64/aapcs64/test_dfp_14.c  |  35 +
>  .../gcc.target/aarch64/aapcs64/test_dfp_15.c  |  21 +++
>  .../gcc.target/aarch64/aapcs64/test_dfp_16.c  |  32 +
>  .../gcc.target/aarch64/aapcs64/test_dfp_17.c  |  37 +
>  .../gcc.target/aarch64/aapcs64/test_dfp_18.c  |  34 +
>  .../gcc.target/aarch64/aapcs64/test_dfp_19.c  |  35 +
>  .../gcc.target/aarch64/aapcs64/test_dfp_2.c   |  17 +++
>  .../gcc.target/aarch64/aapcs64/test_dfp_20.c  |  22 +++
>  .../gcc.target/aarch64/aapcs64/test_dfp_21.c  |  21 +++
>  .../gcc.target/aarch64/aapcs64/test_dfp_22.c  |  19 +++
>  .../gcc.target/aarch64/aapcs64/test_dfp_23.c  |  42 ++
>  .../gcc.target/aarch64/aapcs64/test_dfp_24.c  |  22 +++
>  .../gcc.target/aarch64/aapcs64/test_dfp_25.c  |  61 
>  .../gcc.target/aarch64/aapcs64/test_dfp_26.c  |  54 +++
>  .../gcc.target/aarch64/aapcs64/test_dfp_27.c  |  46 ++
>  .../gcc.target/aarch64/aapcs64/test_dfp_3.c   |  18 +++
>  .../gcc.target/aarch64/aapcs64/test_dfp_5.c   |  24 
>  .../gcc.target/aarch64/aapcs64/test_dfp_6.c   |  26 
>  .../gcc.target/aarch64/aapcs64/test_dfp_7.c   |  30 
>  .../gcc.target/aarch64/aapcs64/test_dfp_8.c   |  24 
>  .../gcc.target/aarch64/aapcs64/test_dfp_9.c   

Re: [PATCH 02/10] aarch64: Add backend support for DFP

2022-05-10 Thread Richard Sandiford via Gcc-patches
Richard Sandiford  writes:
> The patch changes the scalar handling in aapcs_vfp_sub_candidate,
> but not the complex handling.  Is that deliberate?

TIL: we don't support complex decimal floats.  So never mind that :-)

Richard


[PATCH] Store complicated const into pool

2022-05-10 Thread Jiufu Guo via Gcc-patches
Hi,

To set a constant to a reg, one way is building the constant through
instructions, like lis/ori/sldi...  Another way is loading it from
the constant pool through instruction 'ld'(or 'pld' for P10).

Loading a constant may need 2 instructions (or just 'pld' on P10),
and according to testing, if building the constant needs more than 2
instructions (or more than 1 instruction on P10), it is faster to load
it from constant pool.

This patch reduces the threshold of instruction number for storing
constant to pool.

And after some discussions in the previous review:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591509.html
This patch simply updates the rtx_cost hook to accurate cost on
constant by using 'COSTS_N_INSNS' with 'num_insns_constant'.  This
could avoid CSE eliminate constant loading.


Bootstrap and regtest pass on ppc64le and ppc64.
Is this ok for trunk?


BR,
Jiufu


PR target/63281

gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_cannot_force_const_mem):
Exclude rtx with code 'HIGH'.
(rs6000_emit_move): Update insn num threshold for constant
pool storing.
(rs6000_rtx_costs): Update insn number for constant building.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/medium_offset.c: Update.
* gcc.target/powerpc/pr93012.c: Update.
* gcc.target/powerpc/pr63281.c: New test.

---
 gcc/config/rs6000/rs6000.cc  | 15 ---
 gcc/testsuite/gcc.target/powerpc/medium_offset.c |  2 +-
 gcc/testsuite/gcc.target/powerpc/pr63281.c   | 11 +++
 gcc/testsuite/gcc.target/powerpc/pr93012.c   |  2 +-
 4 files changed, 25 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr63281.c

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 4030864aa1a..e51a2242fe1 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -9714,8 +9714,9 @@ rs6000_init_stack_protect_guard (void)
 static bool
 rs6000_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED, rtx x)
 {
-  if (GET_CODE (x) == HIGH
-  && GET_CODE (XEXP (x, 0)) == UNSPEC)
+  /* Exclude CONSTANT HIGH part.  e.g.
+ (high:DI (symbol_ref:DI ("var") [flags 0xc0] )).  */
+  if (GET_CODE (x) == HIGH)
 return true;
 
   /* A TLS symbol in the TOC cannot contain a sum.  */
@@ -10895,7 +10896,7 @@ rs6000_emit_move (rtx dest, rtx source, machine_mode 
mode)
&& FP_REGNO_P (REGNO (operands[0])))
   || !CONST_INT_P (operands[1])
   || (num_insns_constant (operands[1], mode)
-  > (TARGET_CMODEL != CMODEL_SMALL ? 3 : 2)))
+  > (TARGET_PREFIXED ? 1 : 2)))
   && !toc_relative_expr_p (operands[1], false, NULL, NULL)
   && (TARGET_CMODEL == CMODEL_SMALL
   || can_create_pseudo_p ()
@@ -21857,6 +21858,14 @@ rs6000_rtx_costs (rtx x, machine_mode mode, int 
outer_code,
 
 case CONST_DOUBLE:
 case CONST_WIDE_INT:
+  /* Set a const to reg, it may needs a few insns.  */
+  if (outer_code == SET)
+   {
+ *total = COSTS_N_INSNS (num_insns_constant (x, mode));
+ return true;
+   }
+  /* FALLTHRU */
+
 case CONST:
 case HIGH:
 case SYMBOL_REF:
diff --git a/gcc/testsuite/gcc.target/powerpc/medium_offset.c 
b/gcc/testsuite/gcc.target/powerpc/medium_offset.c
index f29eba08c38..4889e8fa8ec 100644
--- a/gcc/testsuite/gcc.target/powerpc/medium_offset.c
+++ b/gcc/testsuite/gcc.target/powerpc/medium_offset.c
@@ -1,7 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-options "-O" } */
-/* { dg-final { scan-assembler-not "\\+4611686018427387904" } } */
+/* { dg-final { scan-assembler-times {\msldi|pld\M} 1 } } */
 
 static int x;
 
diff --git a/gcc/testsuite/gcc.target/powerpc/pr63281.c 
b/gcc/testsuite/gcc.target/powerpc/pr63281.c
new file mode 100644
index 000..469a8f64400
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr63281.c
@@ -0,0 +1,11 @@
+/* PR target/63281 */
+/* { dg-do compile { target lp64 } } */
+/* { dg-options "-O2 -std=c99" } */
+
+void
+foo (unsigned long long *a)
+{
+  *a = 0x020805006106003;
+}
+
+/* { dg-final { scan-assembler-times {\mp?ld\M} 1 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr93012.c 
b/gcc/testsuite/gcc.target/powerpc/pr93012.c
index 4f764d0576f..5afb4f79c45 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr93012.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr93012.c
@@ -10,4 +10,4 @@ unsigned long long mskh1() { return 0x92349234ULL; }
 unsigned long long mskl1() { return 0x2bcd2bcdULL; }
 unsigned long long mskse() { return 0x12341234ULL; }
 
-/* { dg-final { scan-assembler-times {\mrldimi\M} 7 } } */
+/* { dg-final { scan-assembler-times {\mrldimi|ld|pld\M} 7 } } */
-- 
2.25.1



Re: [PATCH 08/10] testsuite: Add C++ unwinding tests with Decimal Floating-Point

2022-05-10 Thread Richard Sandiford via Gcc-patches
Christophe Lyon via Gcc-patches  writes:
> These tests exercise exception handling with Decimal Floating-Point
> type.
>
> dfp-1.C and dfp-2.C check that thrown objects of such types are
> properly caught, whether when using C++ classes (decimalXX) or via GCC
> mode attributes.
>
> dfp-saves-aarch64.C checks that such objects are properly restored,
> and has to use the mode attribute trick because objects of decimalXX
> class type cannot be assigned to a register variable.
>
> 2022-05-03  Christophe Lyon  
>
>   gcc/testsuite/
>   * g++.dg/eh/dfp-1.C: New test.
>   * g++.dg/eh/dfp-2.C: New test.
>   * g++.dg/eh/dfp-saves-aarch64.C: New test.
> ---
>  gcc/testsuite/g++.dg/eh/dfp-1.C | 54 +
>  gcc/testsuite/g++.dg/eh/dfp-2.C | 54 +
>  gcc/testsuite/g++.dg/eh/dfp-saves-aarch64.C | 49 +++
>  3 files changed, 157 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/eh/dfp-1.C
>  create mode 100644 gcc/testsuite/g++.dg/eh/dfp-2.C
>  create mode 100644 gcc/testsuite/g++.dg/eh/dfp-saves-aarch64.C
>
> diff --git a/gcc/testsuite/g++.dg/eh/dfp-1.C b/gcc/testsuite/g++.dg/eh/dfp-1.C
> new file mode 100644
> index 000..b0da13a4cc5
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/eh/dfp-1.C
> @@ -0,0 +1,54 @@
> +// { dg-do run }
> +// { dg-require-effective-target dfp }
> +
> +extern "C" void abort ();
> +
> +#include 
> +
> +using namespace std::decimal;
> +
> +int
> +foo (double fp)
> +{
> +  if (fp < 32.0)
> +throw (decimal32)32;
> +  if (fp < 64.0)
> +throw (decimal64)64;
> +  if (fp < 128.0)
> +throw (decimal128)128;
> +  return 0;
> +}
> +
> +int bar (double fp)
> +{
> +  try
> +{
> +  foo (fp);
> +  abort ();
> +}
> +  catch (decimal32 df)
> +{
> +  if (df != (decimal32)32)
> + abort ();
> +}
> +  catch (decimal64 dd)
> +{
> +  if (dd != (decimal64)64)
> + abort ();
> +}
> +  catch (decimal128 dl)
> +{
> +  if (dl != (decimal128)128)
> + abort ();
> +}
> +  return 0;
> +}
> +
> +int
> +main ()
> +{
> +  bar (10.0);
> +  bar (20.0);
> +  bar (100.0);
> +  return 0;
> +}
> diff --git a/gcc/testsuite/g++.dg/eh/dfp-2.C b/gcc/testsuite/g++.dg/eh/dfp-2.C
> new file mode 100644
> index 000..aff0e03d1d9
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/eh/dfp-2.C
> @@ -0,0 +1,54 @@
> +// { dg-do run }
> +// { dg-require-effective-target dfp }
> +
> +extern "C" void abort ();
> +
> +typedef float dec32 __attribute__((mode(SD)));
> +typedef float dec64 __attribute__((mode(DD)));
> +typedef float dec128 __attribute__((mode(TD)));
> +
> +int
> +foo (double fp)
> +{
> +  if (fp < 32.0)
> +throw (dec32)32;
> +  if (fp < 64.0)
> +throw (dec64)64;
> +  if (fp < 128.0)
> +throw (dec128)128;
> +  return 0;
> +}
> +
> +int bar (double fp)
> +{
> +  try
> +{
> +  foo (fp);
> +  abort ();
> +}
> +  catch (dec32 df)
> +{
> +  if (df != (dec32)32)
> + abort ();
> +}
> +  catch (dec64 dd)
> +{
> +  if (dd != (dec64)64)
> + abort ();
> +}
> +  catch (dec128 dl)
> +{
> +  if (dl != (dec128)128)
> + abort ();
> +}
> +  return 0;
> +}
> +
> +int
> +main ()
> +{
> +  bar (10.0);
> +  bar (20.0);
> +  bar (100.0);
> +  return 0;
> +}
> diff --git a/gcc/testsuite/g++.dg/eh/dfp-saves-aarch64.C 
> b/gcc/testsuite/g++.dg/eh/dfp-saves-aarch64.C
> new file mode 100644
> index 000..79f6697dd10
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/eh/dfp-saves-aarch64.C
> @@ -0,0 +1,49 @@
> +// { dg-do run { target aarch64*-*-* } }
> +// { dg-require-effective-target dfp }
> +
> +/* Test unwinding of AArch64 register saves.  */
> +/* We cannot use #include  because it defines
> +   decimal* types as classes, which we cannot be assigned to register

Typo: s/which we cannot/which cannot/.

OK with that change, thanks.

Richard

> +   variables.  Hence the use the mode attribute trick.  */
> +
> +#ifdef __aarch64__
> +
> +typedef float dec64 __attribute__((mode(DD)));
> +
> +extern "C" void abort (void);
> +extern "C" void exit (int);
> +
> +void
> +foo (void)
> +{
> +  register dec64 v10 asm("v10") = 0;
> +  register dec64 v11 asm("v11") = 1;
> +  register dec64 v12 asm("v12") = 2;
> +  register dec64 v13 asm("v13") = 3;
> +  asm volatile ("" : "+w" (v10), "+w" (v11), "+w" (v12), "+w" (v13));
> +  throw "";
> +}
> +
> +int
> +main (void)
> +{
> +  register dec64 v10 asm("v10") = 10;
> +  register dec64 v11 asm("v11") = 11;
> +  register dec64 v12 asm("v12") = 12;
> +  register dec64 v13 asm("v13") = 13;
> +  asm volatile ("" : "+w" (v10), "+w" (v11), "+w" (v12), "+w" (v13));
> +  try {
> +foo ();
> +  } catch (...) {
> +asm volatile ("" : "+w" (v10), "+w" (v11), "+w" (v12), "+w" (v13));
> +if (v10 != 10 || v11 != 11 || v12 != 12 || v13 != 13)
> +  abort ();
> +  }
> +  exit (0);
> +}
> +#else
> +int
> +main (void)
> +{
> +}
> +#endif


Re: [PATCH 02/10] aarch64: Add backend support for DFP

2022-05-10 Thread Richard Sandiford via Gcc-patches
Christophe Lyon via Gcc-patches  writes:
> @@ -8464,10 +8464,18 @@ aarch64_gen_storewb_pair (machine_mode mode, rtx 
> base, rtx reg, rtx reg2,
>return gen_storewb_pairdf_di (base, base, reg, reg2,
>   GEN_INT (-adjustment),
>   GEN_INT (UNITS_PER_WORD - adjustment));
> +case E_DDmode:
> +  return gen_storewb_pairdd_di (base, base, reg, reg2,
> + GEN_INT (-adjustment),
> + GEN_INT (UNITS_PER_WORD - adjustment));
>  case E_TFmode:
>return gen_storewb_pairtf_di (base, base, reg, reg2,
>   GEN_INT (-adjustment),
>   GEN_INT (UNITS_PER_VREG - adjustment));
> +case E_TDmode:
> +  return gen_storewb_pairtd_di (base, base, reg, reg2,
> + GEN_INT (-adjustment),
> + GEN_INT (UNITS_PER_VREG - adjustment));
>  default:
>gcc_unreachable ();
>  }
> @@ -8510,9 +8518,15 @@ aarch64_gen_loadwb_pair (machine_mode mode, rtx base, 
> rtx reg, rtx reg2,
>  case E_DFmode:
>return gen_loadwb_pairdf_di (base, base, reg, reg2, GEN_INT 
> (adjustment),
>  GEN_INT (UNITS_PER_WORD));
> +case E_DDmode:
> +  return gen_loadwb_pairdd_di (base, base, reg, reg2, GEN_INT 
> (adjustment),
> +GEN_INT (UNITS_PER_WORD));
>  case E_TFmode:
>return gen_loadwb_pairtf_di (base, base, reg, reg2, GEN_INT 
> (adjustment),
>  GEN_INT (UNITS_PER_VREG));
> +case E_TDmode:
> +  return gen_loadwb_pairtd_di (base, base, reg, reg2, GEN_INT 
> (adjustment),
> +GEN_INT (UNITS_PER_VREG));
>  default:
>gcc_unreachable ();
>  }

Are these changes needed?  I would only have expected them to be
used for stack pushes and pops.

> @@ -8561,9 +8575,15 @@ aarch64_gen_store_pair (machine_mode mode, rtx mem1, 
> rtx reg1, rtx mem2,
>  case E_DFmode:
>return gen_store_pair_dw_dfdf (mem1, reg1, mem2, reg2);
> 
> +case E_DDmode:
> +  return gen_store_pair_dw_ (mem1, reg1, mem2, reg2);
> +
>  case E_TFmode:
>return gen_store_pair_dw_tftf (mem1, reg1, mem2, reg2);
> 
> +case E_TDmode:
> +  return gen_store_pair_dw_tdtd (mem1, reg1, mem2, reg2);
> +
>  case E_V4SImode:
>return gen_vec_store_pairv4siv4si (mem1, reg1, mem2, reg2);
> 
> @@ -8590,9 +8610,15 @@ aarch64_gen_load_pair (machine_mode mode, rtx reg1, 
> rtx mem1, rtx reg2,
>  case E_DFmode:
>return gen_load_pair_dw_dfdf (reg1, mem1, reg2, mem2);
> 
> +case E_DDmode:
> +  return gen_load_pair_dw_ (reg1, mem1, reg2, mem2);
> +
>  case E_TFmode:
>return gen_load_pair_dw_tftf (reg1, mem1, reg2, mem2);
> 
> +case E_TDmode:
> +  return gen_load_pair_dw_tdtd (reg1, mem1, reg2, mem2);
> +
>  case E_V4SImode:
>return gen_load_pairv4siv4si (reg1, mem1, reg2, mem2);
 
Same idea here, in that I think these would only be used for prologue/epilogue
and block operations.

> @@ -20362,7 +20407,8 @@ aarch64_vfp_is_call_or_return_candidate (machine_mode 
> mode,
>machine_mode new_mode = VOIDmode;
>bool composite_p = aarch64_composite_type_p (type, mode);
>  
> -  if ((!composite_p && GET_MODE_CLASS (mode) == MODE_FLOAT)
> +  if ((!composite_p && ((GET_MODE_CLASS (mode) == MODE_FLOAT)
> + || GET_MODE_CLASS (mode) == MODE_DECIMAL_FLOAT))

Formatting nit: doubled brackets.  Now that the condition is spread over
multiple lines, the && should start a new line:

  if ((!composite_p
&& (GET_MODE_CLASS (mode) == MODE_FLOAT)
|| GET_MODE_CLASS (mode) == MODE_DECIMAL_FLOAT)

> -;; Iterator for all scalar floating point modes (SF, DF and TF)
> -(define_mode_iterator GPF_TF [SF DF TF])
> +;; Iterator for all scalar floating point modes (SF, DF, TF SD, DD, and TD)
> +(define_mode_iterator GPF_TF [SF DF TF SD DD TD])

Missing comma after “TF”.

The patch has some changes to the rtx costs for constants.  What happens
with aarch64_reinterpret_float_as_int?  (Genuine question.)  Do dfp
constants get through and do they get converted to an integer?
If so, I guess we need to handle DDmode like DFmode there.

Related, aarch64_legitimate_constant_p has:

  /* Support CSE and rematerialization of common constants.  */
  if (CONST_INT_P (x)
  || (CONST_DOUBLE_P (x) && GET_MODE_CLASS (mode) == MODE_FLOAT))
return true;

which looks it would exclude DFP constants.  Perhaps we should
simply remove the MODE_FLOAT condition, since on AArch64 all
CONST_DOUBLEs are/must be FP constants.

The patch changes the scalar handling in aapcs_vfp_sub_candidate,
but not the complex handling.  Is that deliberate?

I wes wondering whether it would be worth adding some abstraction,
since the same checks appear multiple times.  But 

[PATCH][pushed] libgcov: use proper type for n_functions

2022-05-10 Thread Martin Liška
gcov_info::n_functions type is initialized by generated
code in build_info_type:

/* n_functions */
field = build_decl (BUILTINS_LOCATION, FIELD_DECL, NULL_TREE,
get_gcov_unsigned_t ());

It uses gcov_unsigned_t, but the struct definition in libgcov.h uses
unsigned type. That brings troubled on 16-bit targets.

I'm going to install the patch once tests finish.
Martin

PR gcov-profile/105535

libgcc/ChangeLog:

* libgcov.h (struct gcov_info): Use gcov_unsigned_t for
n_functions.

Co-Authored-By: Hans-Peter Helfert 
---
 libgcc/libgcov.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
index 487bd1464cd..c7545cc746e 100644
--- a/libgcc/libgcov.h
+++ b/libgcc/libgcov.h
@@ -235,7 +235,7 @@ struct gcov_info
   gcov_merge_fn merge[GCOV_COUNTERS];  /* merge functions (null for
  unused) */
   
-  unsigned n_functions;/* number of functions */
+  gcov_unsigned_t n_functions; /* number of functions */
 
 #ifndef IN_GCOV_TOOL
   const struct gcov_fn_info *const *functions; /* pointer to pointers
-- 
2.36.0



[PATCH] Remove non-ANSI C macros in ansidecl.h.

2022-05-10 Thread Martin Liška
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

@Alan: Are you fine with the change from binutils/gdb perspective?

Thanks,
Martin

include/ChangeLog:

* ansidecl.h (PTR): Remove.
(const): Likewise.
(volatile): Likewise.
(signed): Likewise.
---
 include/ansidecl.h | 26 +-
 1 file changed, 1 insertion(+), 25 deletions(-)

diff --git a/include/ansidecl.h b/include/ansidecl.h
index efee5b6904b..76ff868a128 100644
--- a/include/ansidecl.h
+++ b/include/ansidecl.h
@@ -16,18 +16,7 @@ You should have received a copy of the GNU General Public 
License
 along with this program; if not, write to the Free Software
 Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, 
USA.  */
 
-/* ANSI and traditional C compatibility macros
-
-   ANSI C is assumed if __STDC__ is #defined.
-
-   Macro   ANSI C definition   Traditional C definition
-   -    - --   --- - --
-   PTR `void *'`char *'
-   const   not defined `'
-   volatilenot defined `'
-   signed  not defined `'
-
-   For ease of writing code which uses GCC extensions but needs to be
+/* For ease of writing code which uses GCC extensions but needs to be
portable to other compilers, we provide the GCC_VERSION macro that
simplifies testing __GNUC__ and __GNUC_MINOR__ together, and various
wrappers around __attribute__.  Also, __extension__ will be #defined
@@ -62,19 +51,6 @@ So instead we use the macro below and test it against 
specific values.  */
 #define GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__)
 #endif /* GCC_VERSION */
 
-/* All known AIX compilers implement these things (but don't always
-   define __STDC__).  The RISC/OS MIPS compiler defines these things
-   in SVR4 mode, but does not define __STDC__.  */
-/* erax...@alumni.rice.edu: The Compaq C++ compiler, unlike many other
-   C++ compilers, does not define __STDC__, though it acts as if this
-   was so. (Verified versions: 5.7, 6.2, 6.3, 6.5) */
-
-#define PTRvoid *
-
-#undef const
-#undef volatile
-#undef signed
-
 /* inline requires special treatment; it's in C99, and GCC >=2.7 supports
it too, but it's not in C89.  */
 #undef inline
-- 
2.36.0



[PATCH] Replace PTR with 'void *' in compiler.

2022-05-10 Thread Martin Liška
Similarly in GCC itself. I've built all FEs with the patch.

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

Ready to be installed?
Thanks,
Martin

gcc/ada/ChangeLog:

* gcc-interface/decl.cc (compare_field_bitpos): Use void *
instead PTR.
* gcc-interface/utils2.cc (compare_elmt_bitpos): Likewise.

gcc/ChangeLog:

* basic-block.h (struct basic_block_d): Use void *
instead PTR.
* cfgloop.h: Likewise.
* cgraph.h: Likewise.
* gengtype-state.cc (state_ident_by_name): Likewise.
(record_type): Likewise.
(read_state_already_seen_type): Likewise.
* gengtype.cc (dump_type): Likewise.
(input_file_by_name): Likewise.
(main): Likewise.
* ggc-common.cc (ggc_cleared_alloc_ptr_array_two_args): Likewise.
* ipa-utils.h (struct ipa_dfs_info): Likewise.
* plugin.cc (htab_hash_plugin): Likewise.
---
 gcc/ada/gcc-interface/decl.cc   | 4 ++--
 gcc/ada/gcc-interface/utils2.cc | 2 +-
 gcc/basic-block.h   | 4 ++--
 gcc/cfgloop.h   | 2 +-
 gcc/cgraph.h| 4 ++--
 gcc/gengtype-state.cc   | 6 +++---
 gcc/gengtype.cc | 6 +++---
 gcc/ggc-common.cc   | 4 ++--
 gcc/ipa-utils.h | 2 +-
 gcc/plugin.cc   | 2 +-
 10 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/gcc/ada/gcc-interface/decl.cc b/gcc/ada/gcc-interface/decl.cc
index 1c7a716840e..d52c4fb3623 100644
--- a/gcc/ada/gcc-interface/decl.cc
+++ b/gcc/ada/gcc-interface/decl.cc
@@ -224,7 +224,7 @@ static bool constructor_address_p (tree);
 static bool allocatable_size_p (tree, bool);
 static bool initial_value_needs_conversion (tree, tree);
 static tree update_n_elem (tree, tree, tree);
-static int compare_field_bitpos (const PTR, const PTR);
+static int compare_field_bitpos (const void *, const void *);
 static bool components_to_record (Node_Id, Entity_Id, tree, tree, int, bool,
  bool, bool, bool, bool, bool, bool, tree,
  tree *);
@@ -7712,7 +7712,7 @@ field_has_variable_size (tree field)
 /* qsort comparer for the bit positions of two record components.  */
 
 static int
-compare_field_bitpos (const PTR rt1, const PTR rt2)
+compare_field_bitpos (const void *rt1, const void *rt2)
 {
   const_tree const field1 = * (const_tree const *) rt1;
   const_tree const field2 = * (const_tree const *) rt2;
diff --git a/gcc/ada/gcc-interface/utils2.cc b/gcc/ada/gcc-interface/utils2.cc
index e5cd85662b9..76622da8081 100644
--- a/gcc/ada/gcc-interface/utils2.cc
+++ b/gcc/ada/gcc-interface/utils2.cc
@@ -1936,7 +1936,7 @@ build_call_raise_range (int msg, Node_Id gnat_node, char 
kind,
for record components.  */
 
 static int
-compare_elmt_bitpos (const PTR rt1, const PTR rt2)
+compare_elmt_bitpos (const void *rt1, const void *rt2)
 {
   const constructor_elt * const elmt1 = (const constructor_elt *) rt1;
   const constructor_elt * const elmt2 = (const constructor_elt *) rt2;
diff --git a/gcc/basic-block.h b/gcc/basic-block.h
index 21a9b24dbf9..c9d1fc91bbb 100644
--- a/gcc/basic-block.h
+++ b/gcc/basic-block.h
@@ -36,7 +36,7 @@ public:
   } insns;
 
   /* Auxiliary info specific to a pass.  */
-  PTR aux;
+  void *aux;
 
   /* Location of any goto implicit in the edge.  */
   location_t goto_locus;
@@ -120,7 +120,7 @@ struct GTY((chain_next ("%h.next_bb"), chain_prev 
("%h.prev_bb"))) basic_block_d
   vec *succs;
 
   /* Auxiliary info specific to a pass.  */
-  PTR GTY ((skip (""))) aux;
+  void *GTY ((skip (""))) aux;
 
   /* Innermost loop containing the block.  */
   class loop *loop_father;
diff --git a/gcc/cfgloop.h b/gcc/cfgloop.h
index d2714e20cb0..528b1219bc3 100644
--- a/gcc/cfgloop.h
+++ b/gcc/cfgloop.h
@@ -148,7 +148,7 @@ public:
   class loop *next;
 
   /* Auxiliary info specific to a pass.  */
-  PTR GTY ((skip (""))) aux;
+  void *GTY ((skip (""))) aux;
 
   /* The number of times the latch of the loop is executed.  This can be an
  INTEGER_CST, or a symbolic expression representing the number of
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index 8c512b648ee..4be67e3cea9 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -628,7 +628,7 @@ public:
   /* File stream where this node is being written to.  */
   struct lto_file_decl_data * lto_file_data;
 
-  PTR GTY ((skip)) aux;
+  void *GTY ((skip)) aux;
 
   /* Comdat group the symbol is in.  Can be private if GGC allowed that.  */
   tree x_comdat_group;
@@ -1895,7 +1895,7 @@ public:
   /* Additional information about an indirect call.  Not cleared when an edge
  becomes direct.  */
   cgraph_indirect_call_info *indirect_info;
-  PTR GTY ((skip (""))) aux;
+  void *GTY ((skip (""))) aux;
   /* When equal to CIF_OK, inline this call.  Otherwise, points to the
  explanation why function was not inlined.  */
   enum cgraph_inline_failed_t inline_failed;
diff --git a/gcc/gengtype-state.cc 

[PATCH] libiberty: stop using PTR macro.

2022-05-10 Thread Martin Liška
Hi.

As noticed by Alan, we can stop using the non-ANSI C specific macro (PTR).
Let's removed its usafe in libiberty.

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

Ready to be installed?
Thanks,
Martin

include/ChangeLog:

* hashtab.h (HTAB_EMPTY_ENTRY): Use void * instead PTR.
(HTAB_DELETED_ENTRY): Likewise.

libiberty/ChangeLog:

* alloca.c (C_alloca): Use void * instead PTR.
* calloc.c (malloc): Likewise.
(bzero): Likewise.
(calloc): Likewise.
* hashtab.c (find_empty_slot_for_expand): Likewise.
(eq_pointer): Likewise.
(htab_create_alloc_ex): Likewise.
(htab_create_typed_alloc): Likewise.
(htab_set_functions_ex): Likewise.
(htab_delete): Likewise.
(htab_empty): Likewise.
(htab_expand): Likewise.
(htab_find_with_hash): Likewise.
(htab_find): Likewise.
(htab_find_slot_with_hash): Likewise.
(htab_find_slot): Likewise.
(htab_remove_elt): Likewise.
(htab_remove_elt_with_hash): Likewise.
(htab_clear_slot): Likewise.
(htab_traverse_noresize): Likewise.
(htab_traverse): Likewise.
(htab_hash_string): Likewise.
(iterative_hash): Likewise.
(hash_pointer): Likewise.
* memchr.c (memchr): Likewise.
* memcmp.c (memcmp): Likewise.
* memcpy.c (memcpy): Likewise.
* memmove.c (memmove): Likewise.
* mempcpy.c (memcpy): Likewise.
(mempcpy): Likewise.
* memset.c (memset): Likewise.
* objalloc.c (malloc): Likewise.
(free): Likewise.
(objalloc_create): Likewise.
(_objalloc_alloc): Likewise.
(objalloc_free_block): Likewise.
* random.c (PTR): Likewise.
(void): Likewise.
(initstate): Likewise.
(setstate): Likewise.
* regex.c: Likewise.
* spaces.c (malloc): Likewise.
(free): Likewise.
* stpcpy.c (memcpy): Likewise.
* strdup.c (malloc): Likewise.
(memcpy): Likewise.
* strerror.c (malloc): Likewise.
(memset): Likewise.
* strndup.c (malloc): Likewise.
(memcpy): Likewise.
* strsignal.c (malloc): Likewise.
(memset): Likewise.
* vasprintf.c (malloc): Likewise.
* vprintf-support.c: Likewise.
* xatexit.c (malloc): Likewise.
* xmalloc.c (xmalloc): Likewise.
(xcalloc): Likewise.
(xrealloc): Likewise.
* xmemdup.c (xmemdup): Likewise.
---
 include/hashtab.h   |  4 +-
 libiberty/alloca.c  |  7 ++-
 libiberty/calloc.c  |  9 ++--
 libiberty/hashtab.c | 92 ++---
 libiberty/memchr.c  |  5 +-
 libiberty/memcmp.c  |  2 +-
 libiberty/memcpy.c  |  3 +-
 libiberty/memmove.c |  3 +-
 libiberty/mempcpy.c |  5 +-
 libiberty/memset.c  |  3 +-
 libiberty/objalloc.c| 23 +-
 libiberty/random.c  | 14 +++---
 libiberty/regex.c   |  8 ++--
 libiberty/spaces.c  |  4 +-
 libiberty/stpcpy.c  |  2 +-
 libiberty/strdup.c  |  4 +-
 libiberty/strerror.c|  4 +-
 libiberty/strndup.c |  4 +-
 libiberty/strsignal.c   |  4 +-
 libiberty/vasprintf.c   |  2 +-
 libiberty/vprintf-support.c |  2 +-
 libiberty/xatexit.c |  2 +-
 libiberty/xmalloc.c | 15 +++---
 libiberty/xmemdup.c |  7 ++-
 24 files changed, 106 insertions(+), 122 deletions(-)

diff --git a/include/hashtab.h b/include/hashtab.h
index 7117eee2afb..e74d2226e08 100644
--- a/include/hashtab.h
+++ b/include/hashtab.h
@@ -79,12 +79,12 @@ typedef void (*htab_free_with_arg) (void *, void *);
 
 /* This macro defines reserved value for empty table entry.  */
 
-#define HTAB_EMPTY_ENTRY((PTR) 0)
+#define HTAB_EMPTY_ENTRY((void *) 0)
 
 /* This macro defines reserved value for table entry which contained
a deleted element. */
 
-#define HTAB_DELETED_ENTRY  ((PTR) 1)
+#define HTAB_DELETED_ENTRY  ((void *) 1)
 
 /* Hash tables are of the following type.  The structure
(implementation) of this type is not needed for using the hash
diff --git a/libiberty/alloca.c b/libiberty/alloca.c
index 9b2e9cb12b6..46f920517e1 100644
--- a/libiberty/alloca.c
+++ b/libiberty/alloca.c
@@ -158,8 +158,7 @@ static header *last_alloca_header = NULL;   /* -> last 
alloca header.  */
 
 /* @undocumented C_alloca */
 
-PTR
-C_alloca (size_t size)
+void *C_alloca (size_t size)
 {
   auto char probe; /* Probes stack depth: */
   register char *depth = ADDRESS_FUNCTION (probe);
@@ -181,7 +180,7 @@ C_alloca (size_t size)
{
  register header *np = hp->h.next;
 
- free ((PTR) hp);  /* Collect garbage.  */
+ free ((void *) hp);   /* Collect garbage.  */
 
  hp = np;  /* -> next header.  */
}
@@ -210,7 +209,7 @@ C_alloca (size_t size)
 
 /* User 

Re: [PATCH] opts: do not allow Separate+Joined ending with =

2022-05-10 Thread Martin Liška
On 5/9/22 14:26, Richard Biener wrote:
> On Mon, May 9, 2022 at 2:16 PM Martin Liška  wrote:
>>
>> On 5/9/22 13:58, Richard Biener wrote:
>>> The patch would have been a lot smaller if you kept it Joined only?
>>
>> Yes, but the langspec rules append a space for some reason:
>>
>> $ ./xgcc -B. /tmp/1.h -ox.h.pch --save-temps --verbose
>> ...
>> ./cc1 -fpreprocessed x.h.pch-1.i ... --output-pch= x.h.pch
> 
> That's probably because we canonicalize Joined & Separate to
> Separate and '{o*:--output-pch %*}' causes then '-o FOO' to be
> matched with 'o*' and %* also outputs the matched space(?)

I've tried changing Joined & Separate to Joined but as said, it didn't
work out as the space was still added.

> 
> Anyway, I see how your approach avoids this and the --output-pch
> switch doesn't seem documented (if one is concerned about
> backwards compatibility).
> 
> So OK if there are no further comments within 48h.

Sure, thanks.

Martin

> 
> Richard.
> 
>> Martin



[PATCH] aarch64: Fix pac-ret with unusual dwarf in libgcc unwinder [PR104689]

2022-05-10 Thread Szabolcs Nagy via Gcc-patches
The RA_SIGN_STATE dwarf pseudo-register is normally only set using the
DW_CFA_AARCH64_negate_ra_state (== DW_CFA_window_save) operation which
toggles the return address signedness state (the default state is 0).
(It may be set by remember/restore_state CFI too, those save/restore
the state of all registers.)

However RA_SIGN_STATE can be set directly via DW_CFA_val_expression too.
GCC does not generate such CFI but some other compilers reportedly do.

Note: the toggle operation must not be mixed with other dwarf register
rule CFI within the same CIE and FDE.

In libgcc we assume REG_UNSAVED means the RA_STATE is set using toggle
operations, otherwise we assume its value is set by other CFI.

libgcc/ChangeLog:

PR target/104689
* config/aarch64/aarch64-unwind.h (aarch64_frob_update_context):
Handle the !REG_UNSAVED case.
* unwind-dw2.c (execute_cfa_program): Fail toggle if !REG_UNSAVED.

gcc/testsuite/ChangeLog:

PR target/104689
* gcc.target/aarch64/pr104689.c: New test.
---
 gcc/testsuite/gcc.target/aarch64/pr104689.c | 149 
 libgcc/config/aarch64/aarch64-unwind.h  |   8 +-
 libgcc/unwind-dw2.c |   4 +-
 3 files changed, 159 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/pr104689.c

diff --git a/gcc/testsuite/gcc.target/aarch64/pr104689.c 
b/gcc/testsuite/gcc.target/aarch64/pr104689.c
new file mode 100644
index 000..3b7adbdfe7d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr104689.c
@@ -0,0 +1,149 @@
+/* PR target/104689. Unwind across pac-ret frames with unusual dwarf.  */
+/* { dg-do run } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-options "-fexceptions -O2" } */
+
+#include 
+#include 
+#include 
+
+#define die() \
+  do { \
+printf ("%s:%d: reached unexpectedly.\n", __FILE__, __LINE__); \
+fflush (stdout); \
+abort (); \
+  } while (0)
+
+
+/* Code to invoke unwinding with a logging callback.  */
+
+static struct _Unwind_Exception exc;
+
+static _Unwind_Reason_Code
+force_unwind_stop (int version, _Unwind_Action actions,
+   _Unwind_Exception_Class exc_class,
+   struct _Unwind_Exception *exc_obj,
+   struct _Unwind_Context *context,
+   void *stop_parameter)
+{
+  printf ("%s: CFA: %p PC: %p actions: %d\n",
+ __func__,
+ (void *)_Unwind_GetCFA (context),
+ (void *)_Unwind_GetIP (context),
+ (int)actions);
+  if (actions & _UA_END_OF_STACK)
+die ();
+  return _URC_NO_REASON;
+}
+
+static void force_unwind (void)
+{
+#ifndef __USING_SJLJ_EXCEPTIONS__
+  _Unwind_ForcedUnwind (, force_unwind_stop, 0);
+#else
+  _Unwind_SjLj_ForcedUnwind (, force_unwind_stop, 0);
+#endif
+}
+
+
+/* Define functions with unusual pac-ret dwarf via top level asm.  */
+
+#define STR(x) #x
+#define DW_CFA_val_expression 0x16
+#define RA_SIGN_STATE 34
+#define DW_OP_lit0 0x30
+#define DW_OP_lit1 0x31
+
+#define cfi_escape(a1, a2, a3, a4) \
+  ".cfi_escape " STR(a1) ", " STR(a2) ", " STR(a3) ", " STR(a4)
+
+/* Bytes: 0x16 0x22 0x01 0x30  */
+#define SET_RA_STATE_0 \
+  cfi_escape (DW_CFA_val_expression, RA_SIGN_STATE, 1, DW_OP_lit0)
+
+/* Bytes: 0x16 0x22 0x01 0x31  */
+#define SET_RA_STATE_1 \
+  cfi_escape (DW_CFA_val_expression, RA_SIGN_STATE, 1, DW_OP_lit1)
+
+/* These function call their argument.  */
+void unusual_pac_ret (void *);
+void unusual_no_pac_ret (void *);
+
+asm(""
+".global unusual_pac_ret\n"
+".type unusual_pac_ret, %function\n"
+"unusual_pac_ret:\n"
+"  .cfi_startproc\n"
+"  " SET_RA_STATE_0 "\n"
+"  hint25 // paciasp\n"
+"  " SET_RA_STATE_1 "\n"
+"  stp x29, x30, [sp, -16]!\n"
+"  .cfi_def_cfa_offset 16\n"
+"  .cfi_offset 29, -16\n"
+"  .cfi_offset 30, -8\n"
+"  mov x29, sp\n"
+"  blr x0\n"
+"  ldp x29, x30, [sp], 16\n"
+"  .cfi_restore 30\n"
+"  .cfi_restore 29\n"
+"  .cfi_def_cfa_offset 0\n"
+"  hint29 // autiasp\n"
+"  " SET_RA_STATE_0 "\n"
+"  ret\n"
+"  .cfi_endproc\n");
+
+asm(""
+".global unusual_no_pac_ret\n"
+".type unusual_no_pac_ret, %function\n"
+"unusual_no_pac_ret:\n"
+"  .cfi_startproc\n"
+"  " SET_RA_STATE_0 "\n"
+"  stp x29, x30, [sp, -16]!\n"
+"  .cfi_def_cfa_offset 16\n"
+"  .cfi_offset 29, -16\n"
+"  .cfi_offset 30, -8\n"
+"  mov x29, sp\n"
+"  blr x0\n"
+"  ldp x29, x30, [sp], 16\n"
+"  .cfi_restore 30\n"
+"  .cfi_restore 29\n"
+"  .cfi_def_cfa_offset 0\n"
+"  ret\n"
+"  .cfi_endproc\n");
+
+
+/* Functions to create a call chain with mixed pac-ret dwarf.  */
+
+__attribute__((target("branch-protection=pac-ret")))
+static void f2_pac_ret (void)
+{
+  force_unwind ();
+  die ();
+}
+
+__attribute__((target("branch-protection=none")))
+static void f1_no_pac_ret (void)
+{
+  unusual_pac_ret (f2_pac_ret);
+  die ();
+}
+
+__attribute__((noinline, 

[PATCH] isel: Fix up gimple_expand_vec_set_expr [PR105528]

2022-05-10 Thread Jakub Jelinek via Gcc-patches
Hi!

The following testcase ICEs (and only without -g), because we don't replace
one VEC_COND_EXPR with .VCOND* call.
We don't do that because gimple_expand_vec_set_expr adds some stmts before
*gsi and then uses gsi_remove to remove it.  gsi_remove moves the iterator
to the next stmt and in the caller we then do gsi_next before looking at
another stmt, which means we can skip processing of one stmt, which in this
case happened to be a VEC_COND_EXPR but with -g is some debug stmt in
between.  As we always emit some stmts before it, it is easy to update the
iterator to the last stmt emitted there, so that caller continues really
with the next stmt.

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

2022-05-10  Jakub Jelinek  

PR tree-optimization/105528
* gimple-isel.cc (gimple_expand_vec_set_expr): After gsi_remove
set *gsi to gsi_for_stmt (ass_stmt).  Fix up function comment.

* gcc.dg/pr105528.c: New test.

--- gcc/gimple-isel.cc.jj   2022-05-09 09:09:20.386472253 +0200
+++ gcc/gimple-isel.cc  2022-05-09 11:28:27.295925124 +0200
@@ -43,7 +43,7 @@ along with GCC; see the file COPYING3.
 /* Expand all ARRAY_REF(VIEW_CONVERT_EXPR) gimple assignments into calls to
internal function based on vector type of selected expansion.
i.e.:
- VIEW_CONVERT_EXPR(u)[_1] =  = i_4(D);
+ VIEW_CONVERT_EXPR(u)[_1] = i_4(D);
=>
  _7 = u;
  _8 = .VEC_SET (_7, i_4(D), _1);
@@ -104,6 +104,7 @@ gimple_expand_vec_set_expr (struct funct
  if (gsi_remove (gsi, true)
  && gimple_purge_dead_eh_edges (bb))
cfg_changed = true;
+ *gsi = gsi_for_stmt (ass_stmt);
}
 }
 
--- gcc/testsuite/gcc.dg/pr105528.c.jj  2022-05-09 11:30:09.476529621 +0200
+++ gcc/testsuite/gcc.dg/pr105528.c 2022-05-09 11:30:35.091179163 +0200
@@ -0,0 +1,23 @@
+/* PR tree-optimization/105528 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wno-psabi -fcompare-debug" } */
+/* { dg-additional-options "-mavx512f" { target i?86-*-* x86_64-*-* } } */
+
+typedef unsigned V __attribute__((__vector_size__ (64)));
+V g;
+
+V
+bar (V v)
+{
+  V w;
+  v <<= (V){(V){}[53]} >= v & 5;
+  w[w[5]] -= ~0;
+  v %= ~0;
+  return v + w;
+}
+
+void
+foo (void)
+{
+  g -= (V){bar((V){~0})[3]};
+}

Jakub



[Ada] Handle non-standard booleans in if_expression condition

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
We failed to call Adjust_Condition for the condition expression of an
if_expression, so non-standard booleans were expanded like standard
booleans, disregarding representation clauses. Fixed.

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

gcc/ada/

* exp_ch4.adb (Expand_N_If_Expression): Call Adjust_Condition to
handle non-standard booleans.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
@@ -5794,6 +5794,10 @@ package body Exp_Ch4 is
--  Start of processing for Expand_N_If_Expression
 
begin
+  --  Deal with non-standard booleans
+
+  Adjust_Condition (Cond);
+
   --  Check for MINIMIZED/ELIMINATED overflow mode.
   --  Apply_Arithmetic_Overflow_Check will not deal with Then/Else_Actions
   --  so skip this step if any actions are present.




[Ada] Incorrect ineffective use type clause warning

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
This patch fixes an issue in the compiler whereby a use_type_clause
incorrectly gets flagged as ineffective when the use of it comes after a
generic package instantiation where the installation of private use
clauses are required and one such clause references the same type.

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

gcc/ada/

* sem_ch8.adb (Use_One_Type): Remove code in charge of setting
Current_Use_Clause when Id is known to be redundant, and modify
the printing of errors associated with redundant use type
clauses so that line number gets included in more cases.diff --git a/gcc/ada/sem_ch8.adb b/gcc/ada/sem_ch8.adb
--- a/gcc/ada/sem_ch8.adb
+++ b/gcc/ada/sem_ch8.adb
@@ -10571,20 +10571,6 @@ package body Sem_Ch8 is
   --  even if it is redundant at the place of the instantiation.
 
   elsif Redundant_Use (Id) then
-
- --  We must avoid incorrectly setting the Current_Use_Clause when we
- --  are working with a redundant clause that has already been linked
- --  in the Prev_Use_Clause chain, otherwise the chain will break.
-
- if Present (Current_Use_Clause (T))
-   and then Present (Prev_Use_Clause (Current_Use_Clause (T)))
-   and then Parent (Id) = Prev_Use_Clause (Current_Use_Clause (T))
- then
-null;
- else
-Set_Current_Use_Clause (T, Parent (Id));
- end if;
-
  Set_Used_Operations (Parent (Id), New_Elmt_List);
 
   --  If the subtype mark designates a subtype in a different package,
@@ -10689,121 +10675,98 @@ package body Sem_Ch8 is
--  Start of processing for Use_Clause_Known
 
begin
-  --  If both current use_type_clause and the use_type_clause
-  --  for the type are at the compilation unit level, one of
-  --  the units must be an ancestor of the other, and the
-  --  warning belongs on the descendant.
-
-  if Nkind (Parent (Clause1)) = N_Compilation_Unit
-   and then
- Nkind (Parent (Clause2)) = N_Compilation_Unit
-  then
- --  If the unit is a subprogram body that acts as spec,
- --  the context clause is shared with the constructed
- --  subprogram spec. Clearly there is no redundancy.
-
- if Clause1 = Clause2 then
-return;
- end if;
+  --  If the unit is a subprogram body that acts as spec, the
+  --  context clause is shared with the constructed subprogram
+  --  spec. Clearly there is no redundancy.
 
- Unit1 := Unit (Parent (Clause1));
- Unit2 := Unit (Parent (Clause2));
+  if Clause1 = Clause2 then
+ return;
+  end if;
 
- --  If both clauses are on same unit, or one is the body
- --  of the other, or one of them is in a subunit, report
- --  redundancy on the later one.
+  Unit1 := Unit (Enclosing_Comp_Unit_Node (Clause1));
+  Unit2 := Unit (Enclosing_Comp_Unit_Node (Clause2));
 
- if Unit1 = Unit2 or else Nkind (Unit1) = N_Subunit then
-Error_Msg_Sloc := Sloc (Current_Use_Clause (T));
-Error_Msg_NE -- CODEFIX
-  ("& is already use-visible through previous "
-   & "use_type_clause #??", Clause1, T);
-return;
-
- elsif Nkind (Unit2) in N_Package_Body | N_Subprogram_Body
-   and then Nkind (Unit1) /= Nkind (Unit2)
-   and then Nkind (Unit1) /= N_Subunit
- then
-Error_Msg_Sloc := Sloc (Clause1);
-Error_Msg_NE -- CODEFIX
-  ("& is already use-visible through previous "
-   & "use_type_clause #??", Current_Use_Clause (T), T);
-return;
- end if;
+  --  If both clauses are on same unit, or one is the body of
+  --  the other, or one of them is in a subunit, report
+  --  redundancy on the later one.
 
- --  There is a redundant use_type_clause in a child unit.
- --  Determine which of the units is more deeply nested.
- --  If a unit is a package instance, retrieve the entity
- --  and its scope from the instance spec.
+  if Unit1 = Unit2
+or else Nkind (Unit1) = N_Subunit
+or else
+  (Nkind (Unit2) in N_Package_Body | N_Subprogram_Body
+and then 

[Ada] Optimize nonstandard boolean validity checking

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Validity checking of enumerations with nonstandard representation
starts by checking the value range, then calling _rep_to_pos to verify
that the value itself is valid. The value range check is thus
redundant and inefficient: the _rep_to_pos call is normally inlined
when optimizing for speed and the range check slows down the fast
path; it is unnecesary and undesirable when optimizing for size, and
just unnecessary when not optimizing. This patch thus drops the range
check for nonstandard boolean types.

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

gcc/ada/

* exp_attr.adb (Expand_N_Attribute_Reference) :
Drop redundant range check for nonstandard booleans.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
@@ -7281,7 +7281,11 @@ package body Exp_Attr is
   New_Occurrence_Of (Standard_False, Loc))),
 Right_Opnd => Make_Integer_Literal (Loc, 0));
 
-if Ptyp /= PBtyp
+--  Skip the range test for boolean types, as it buys us
+--  nothing. The function called above already fails for
+--  values different from both True and False.
+
+if Ptyp /= PBtyp and then not Is_Boolean_Type (PBtyp)
   and then
 (Type_Low_Bound (Ptyp) /= Type_Low_Bound (PBtyp)
   or else




[Ada] Simplify call to overloaded Earlier_In_Extended_Unit

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
We have two variants of Earlier_In_Extended_Unit that take either
Node_Id or Source_Ptr values. The caller can simply use another variant
and not explicitly convert parameters.

Code cleanup; semantics is unaffected.

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

gcc/ada/

* sem_warn.adb (Check_Unset_Reference): Use variant of
Earlier_In_Extended_Unit that calls Sloc internally.diff --git a/gcc/ada/sem_warn.adb b/gcc/ada/sem_warn.adb
--- a/gcc/ada/sem_warn.adb
+++ b/gcc/ada/sem_warn.adb
@@ -1915,7 +1915,7 @@ package body Sem_Warn is
  and then (No (Unset_Reference (E))
 or else
   Earlier_In_Extended_Unit
-(Sloc (N), Sloc (Unset_Reference (E
+(N, Unset_Reference (E)))
  and then not Has_Pragma_Unmodified_Check_Spec (E)
  and then not Warnings_Off_Check_Spec (E)
  and then not Has_Junk_Name (E)




[Ada] Optimize nonstandard boolean conversions

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
This patch improves the generated code for nonstandard boolean types.

One of the improvements extends the code that avoids converting back
to the nonstandard boolean type an expression computed as standard
boolean, when it will be converted to a(nother) nonstandard boolean
type.

The other improvement involves using the literal representation
constants in an If_Expression instead of dereferencing the T'Val array
when converting to a (nonstandard) boolean type. Avoiding the array
dereference enables the compiler middle-end to propagate the constants
and perform optimizations based on them, to the point of obviating the
improvement above.

Unfortunately, the code generated with this alternate expansion tends
to be slightly larger if it turns out to not enable any further
optimization, though it's most certainly faster, especially on targets
with conditional moves, more so if "store flag" is slow, as on x86.
Still, the array dereference is more straightforward and shorter, so
I've arranged for this alternate expansion to be used only when
optimizing for speed.

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

gcc/ada/

* exp_util.adb (Adjust_Result_Type): Leave result in
Standard.Boolean if it's going to be converted to another
boolean type.
* exp_ch4.adb (Expand_N_Type_Conversion): When optimizing,
convert to nonstandard booleans with an if_expression with
boolean literals.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
@@ -12757,18 +12757,35 @@ package body Exp_Ch4 is
  if not Has_Compatible_Representation (Target_Type, Operand_Type)
and then not Conversion_OK (N)
  then
+if Optimization_Level > 0
+  and then Is_Boolean_Type (Target_Type)
+then
+   --  Convert x(y) to (if y then x'(True) else x'(False)).
+   --  Use literals, instead of indexing x'val, to enable
+   --  further optimizations in the middle-end.
 
---  Convert: x(y) to x'val (ytyp'pos (y))
+   Rewrite (N,
+ Make_If_Expression (Loc,
+   Expressions => New_List (
+ Operand,
+ Convert_To (Target_Type,
+ New_Occurrence_Of (Standard_True, Loc)),
+ Convert_To (Target_Type,
+ New_Occurrence_Of (Standard_False, Loc);
 
-Rewrite (N,
-  Make_Attribute_Reference (Loc,
-Prefix => New_Occurrence_Of (Target_Type, Loc),
-Attribute_Name => Name_Val,
-Expressions=> New_List (
-  Make_Attribute_Reference (Loc,
-Prefix => New_Occurrence_Of (Operand_Type, Loc),
-Attribute_Name => Name_Pos,
-Expressions=> New_List (Operand);
+else
+   --  Convert: x(y) to x'val (ytyp'pos (y))
+
+   Rewrite (N,
+ Make_Attribute_Reference (Loc,
+   Prefix => New_Occurrence_Of (Target_Type, Loc),
+   Attribute_Name => Name_Val,
+   Expressions=> New_List (
+ Make_Attribute_Reference (Loc,
+   Prefix => New_Occurrence_Of (Operand_Type, Loc),
+   Attribute_Name => Name_Pos,
+   Expressions=> New_List (Operand);
+end if;
 
 Analyze_And_Resolve (N, Target_Type);
  end if;


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
@@ -424,6 +424,9 @@ package body Exp_Util is
 elsif KP in N_Op_Boolean
   or else KP in N_Short_Circuit
   or else KP = N_Op_Not
+  or else (KP in N_Type_Conversion
+   | N_Unchecked_Type_Conversion
+and then Is_Boolean_Type (Etype (Parent (N
 then
return;
 




[Ada] Remove repeated conversions between Source_Ptr and Int

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Both Source_Ptr and Int are integer types (and even happen to have equal
ranges). Their values can be calculated without converting
back-and-forth, e.g.:

  Int (Loc1) - Int (Loc2)

can be written simply as:

  Int (Loc1 - Loc2)

Code cleanup related to handling of references to unset objects.
Offending occurrences found with various invocations of grep.

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

gcc/ada/

* par-ch10.adb, scng.adb, sem_res.adb, sinfo-utils.adb,
treepr.adb: Simplify calculations with Source_Ptr and Loc
values.diff --git a/gcc/ada/par-ch10.adb b/gcc/ada/par-ch10.adb
--- a/gcc/ada/par-ch10.adb
+++ b/gcc/ada/par-ch10.adb
@@ -1194,7 +1194,7 @@ package body Ch10 is
   Write_Int (Int (Line));
 
   Write_Str (", file offset ");
-  Write_Int (Int (Loc) - Int (Source_First (Sind)));
+  Write_Int (Int (Loc - Source_First (Sind)));
end Unit_Location;
 
 end Ch10;


diff --git a/gcc/ada/scng.adb b/gcc/ada/scng.adb
--- a/gcc/ada/scng.adb
+++ b/gcc/ada/scng.adb
@@ -130,11 +130,7 @@ package body Scng is
 
procedure Check_End_Of_Line is
   Len : constant Int :=
-  Int (Scan_Ptr) -
-Int (Current_Line_Start) -
-  Wide_Char_Byte_Count;
-
-   --  Start of processing for Check_End_Of_Line
+  Int (Scan_Ptr - Current_Line_Start) - Wide_Char_Byte_Count;
 
begin
   if Style_Check then


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
@@ -11754,7 +11754,7 @@ package body Sem_Res is
 
   Error_Msg
 ("literal out of range of type Standard.Character",
- Source_Ptr (Int (Loc) + J));
+ Loc + Source_Ptr (J));
   return;
end if;
 end loop;
@@ -11783,7 +11783,7 @@ package body Sem_Res is
 
   Error_Msg
 ("literal out of range of type Standard.Wide_Character",
- Source_Ptr (Int (Loc) + J));
+ Loc + Source_Ptr (J));
   return;
end if;
 end loop;


diff --git a/gcc/ada/sinfo-utils.adb b/gcc/ada/sinfo-utils.adb
--- a/gcc/ada/sinfo-utils.adb
+++ b/gcc/ada/sinfo-utils.adb
@@ -191,7 +191,7 @@ package body Sinfo.Utils is
function End_Location (N : Node_Id) return Source_Ptr is
   L : constant Valid_Uint := End_Span (N);
begin
-  return Source_Ptr (Int (Sloc (N)) + UI_To_Int (L));
+  return Sloc (N) + Source_Ptr (UI_To_Int (L));
end End_Location;
 

@@ -214,7 +214,7 @@ package body Sinfo.Utils is
procedure Set_End_Location (N : Node_Id; S : Source_Ptr) is
begin
   Set_End_Span (N,
-UI_From_Int (Int (S) - Int (Sloc (N;
+UI_From_Int (Int (S - Sloc (N;
end Set_End_Location;
 
--


diff --git a/gcc/ada/treepr.adb b/gcc/ada/treepr.adb
--- a/gcc/ada/treepr.adb
+++ b/gcc/ada/treepr.adb
@@ -1229,7 +1229,7 @@ package body Treepr is
 
  else
 Sfile := Get_Source_File_Index (Sloc (N));
-Print_Int (Int (Sloc (N)) - Int (Source_Text (Sfile)'First));
+Print_Int (Int (Sloc (N) - Source_Text (Sfile)'First));
 Write_Str ("  ");
 Write_Location (Sloc (N));
  end if;




[Ada] Reuse Is_Rewrite_Substitution where possible

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Replace comparisons of Original_Node with semantically equivalent but
high-level calls to Is_Rewrite_Substitution. Offending occurrences found
with:

  $ grep -n "Original_Node (\([A-Za-z_]\+\)) /\?= \1" *.adb

Code cleanup only; semantics is unaffected.

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

gcc/ada/

* atree.adb, exp_ch6.adb, exp_ch9.adb, ghost.adb, sem_ch3.adb,
sem_ch4.adb, sem_res.adb, sem_util.adb: Use
Is_Rewrite_Substitution where possible.diff --git a/gcc/ada/atree.adb b/gcc/ada/atree.adb
--- a/gcc/ada/atree.adb
+++ b/gcc/ada/atree.adb
@@ -2146,7 +2146,7 @@ package body Atree is
   --  not already rewritten the node, as indicated by an Orig_Nodes entry
   --  that does not reference the Old_Node.
 
-  if Original_Node (Old_Node) = Old_Node then
+  if not Is_Rewrite_Substitution (Old_Node) then
  Sav_Node := New_Copy (Old_Node);
  Set_Original_Node (Sav_Node, Sav_Node);
  Set_Original_Node (Old_Node, Sav_Node);


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
@@ -3932,7 +3932,7 @@ package body Exp_Ch6 is
 --  First verify the actual is internal
 
 elsif not Comes_From_Source (Prev)
-  and then Original_Node (Prev) = Prev
+  and then not Is_Rewrite_Substitution (Prev)
 
   --  Next check that the actual is a constant
 


diff --git a/gcc/ada/exp_ch9.adb b/gcc/ada/exp_ch9.adb
--- a/gcc/ada/exp_ch9.adb
+++ b/gcc/ada/exp_ch9.adb
@@ -6338,7 +6338,7 @@ package body Exp_Ch9 is
 
 when N_Expression_With_Actions =>
--  this may occur in the case of a Count attribute reference
-   if Original_Node (N) /= N
+   if Is_Rewrite_Substitution (N)
  and then Is_Pure_Barrier (Original_Node (N)) /= Abandon
then
   return Skip;


diff --git a/gcc/ada/ghost.adb b/gcc/ada/ghost.adb
--- a/gcc/ada/ghost.adb
+++ b/gcc/ada/ghost.adb
@@ -1079,7 +1079,7 @@ package body Ghost is
   function Ultimate_Original_Node (Nod : Node_Id) return Node_Id is
  Res : Node_Id := Nod;
   begin
- while Original_Node (Res) /= Res loop
+ while Is_Rewrite_Substitution (Res) loop
 Res := Original_Node (Res);
  end loop;
 


diff --git a/gcc/ada/sem_ch3.adb b/gcc/ada/sem_ch3.adb
--- a/gcc/ada/sem_ch3.adb
+++ b/gcc/ada/sem_ch3.adb
@@ -20185,20 +20185,14 @@ package body Sem_Ch3 is
  =>
 return not Comes_From_Source (Exp)
   and then
---  If the conversion has been rewritten, check Original_Node
+--  If the conversion has been rewritten, check Original_Node;
+--  otherwise, check the expression of the compiler-generated
+--  conversion (which is a conversion that we want to ignore
+--  for purposes of the limited-initialization restrictions).
 
-((Original_Node (Exp) /= Exp
-   and then
- OK_For_Limited_Init_In_05 (Typ, Original_Node (Exp)))
-
-  --  Otherwise, check the expression of the compiler-generated
-  --  conversion (which is a conversion that we want to ignore
-  --  for purposes of the limited-initialization restrictions).
-
-  or else
-(Original_Node (Exp) = Exp
-  and then
-OK_For_Limited_Init_In_05 (Typ, Expression (Exp;
+(if Is_Rewrite_Substitution (Exp)
+ then OK_For_Limited_Init_In_05 (Typ, Original_Node (Exp))
+ else OK_For_Limited_Init_In_05 (Typ, Expression (Exp)));
 
  when N_Explicit_Dereference
 | N_Indexed_Component
@@ -20547,7 +20541,7 @@ package body Sem_Ch3 is
 --  its Original_Node points to the old Discr and the access type
 --  for Discr_Type has already been created.
 
-if Original_Node (Discr) /= Discr then
+if Is_Rewrite_Substitution (Discr) then
Discr_Type := Etype (Discriminant_Type (Discr));
 else
Discr_Type :=


diff --git a/gcc/ada/sem_ch4.adb b/gcc/ada/sem_ch4.adb
--- a/gcc/ada/sem_ch4.adb
+++ b/gcc/ada/sem_ch4.adb
@@ -772,7 +772,7 @@ package body Sem_Ch4 is
--  type.
 
else
-  if Original_Node (N) /= N
+  if Is_Rewrite_Substitution (N)
 and then Nkind (Original_Node (N)) = N_Allocator
   then
  declare


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
@@ -2472,7 +2472,7 @@ package body Sem_Res is
   --  Declare_Expression and requires scope management.
 
   if Nkind (N) = N_Expression_With_Actions then
- if Comes_From_Source (N) 

[Ada] Cleanup detection of No_Elist with No and Present

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Replace equality and inequality operators with calls to No and Present.
Offending occurrences found with:

$ grep -n " /\?= No_Elist" *.adb

Code cleanup only; semantics is unaffected.

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

gcc/ada/

* exp_ch11.adb, exp_ch5.adb, exp_prag.adb, gnat_cuda.adb,
sem_ch12.adb, sem_ch3.adb, sem_ch6.adb, sem_util.adb,
treepr.adb: Replace /= and = operators with No and Present,
respectively.diff --git a/gcc/ada/exp_ch11.adb b/gcc/ada/exp_ch11.adb
--- a/gcc/ada/exp_ch11.adb
+++ b/gcc/ada/exp_ch11.adb
@@ -813,7 +813,7 @@ package body Exp_Ch11 is
   --  case we have to generate possible diagnostics.
 
elsif Has_Local_Raise (Handler)
- and then Local_Raise_Statements (Handler) /= No_Elist
+ and then Present (Local_Raise_Statements (Handler))
then
   Relmt := First_Elmt (Local_Raise_Statements (Handler));
   while Present (Relmt) loop
@@ -1528,7 +1528,7 @@ package body Exp_Ch11 is
 H := Find_Local_Handler (Entity (Name (N)), N);
 
 if Present (H) then
-   if Local_Raise_Statements (H) = No_Elist then
+   if No (Local_Raise_Statements (H)) then
   Set_Local_Raise_Statements (H, New_Elmt_List);
end if;
 


diff --git a/gcc/ada/exp_ch5.adb b/gcc/ada/exp_ch5.adb
--- a/gcc/ada/exp_ch5.adb
+++ b/gcc/ada/exp_ch5.adb
@@ -2101,7 +2101,7 @@ package body Exp_Ch5 is
 --  from the Rhs by selected component because they are invisible
 --  in the type of the right-hand side.
 
-if Stored_Constraint (R_Typ) /= No_Elist then
+if Present (Stored_Constraint (R_Typ)) then
declare
   Assign: Node_Id;
   Discr_Val : Elmt_Id;


diff --git a/gcc/ada/exp_prag.adb b/gcc/ada/exp_prag.adb
--- a/gcc/ada/exp_prag.adb
+++ b/gcc/ada/exp_prag.adb
@@ -1054,7 +1054,7 @@ package body Exp_Prag is
  Result : constant List_Id := New_List;
  Elmt   : Elmt_Id;
   begin
- if Elmts = No_Elist then
+ if No (Elmts) then
 return Result;
  end if;
 


diff --git a/gcc/ada/gnat_cuda.adb b/gcc/ada/gnat_cuda.adb
--- a/gcc/ada/gnat_cuda.adb
+++ b/gcc/ada/gnat_cuda.adb
@@ -149,7 +149,7 @@ package body GNAT_CUDA is
is
   Device_Entities : Elist_Id := Get_CUDA_Device_Entities (Pack_Id);
begin
-  if Device_Entities = No_Elist then
+  if No (Device_Entities) then
  Device_Entities := New_Elmt_List;
  Set_CUDA_Device_Entities (Pack_Id, Device_Entities);
   end if;
@@ -166,7 +166,7 @@ package body GNAT_CUDA is
is
   Kernels : Elist_Id := Get_CUDA_Kernels (Pack_Id);
begin
-  if Kernels = No_Elist then
+  if No (Kernels) then
  Kernels := New_Elmt_List;
  Set_CUDA_Kernels (Pack_Id, Kernels);
   end if;
@@ -687,7 +687,7 @@ package body GNAT_CUDA is
--  Start of processing for Build_And_Insert_CUDA_Initialization
 
begin
-  if CUDA_Node_List = No_Elist then
+  if No (CUDA_Node_List) then
  return;
   end if;
 
@@ -745,7 +745,7 @@ package body GNAT_CUDA is
begin
   pragma Assert (Debug_Flag_Underscore_C);
 
-  if Device_Entities = No_Elist then
+  if No (Device_Entities) then
  return;
   end if;
 
@@ -789,7 +789,7 @@ package body GNAT_CUDA is
   E   : Elist_Id)
is
begin
-  pragma Assert (Get_CUDA_Device_Entities (Pack_Id) = No_Elist);
+  pragma Assert (No (Get_CUDA_Device_Entities (Pack_Id)));
   CUDA_Device_Entities_Table.Set (Pack_Id, E);
end Set_CUDA_Device_Entities;
 
@@ -802,7 +802,7 @@ package body GNAT_CUDA is
   Kernels : Elist_Id)
is
begin
-  pragma Assert (Get_CUDA_Kernels (Pack_Id) = No_Elist);
+  pragma Assert (No (Get_CUDA_Kernels (Pack_Id)));
   CUDA_Kernels_Table.Set (Pack_Id, Kernels);
end Set_CUDA_Kernels;
 


diff --git a/gcc/ada/sem_ch12.adb b/gcc/ada/sem_ch12.adb
--- a/gcc/ada/sem_ch12.adb
+++ b/gcc/ada/sem_ch12.adb
@@ -10224,7 +10224,7 @@ package body Sem_Ch12 is
   Prim  : Node_Id;
 
begin
-  if Prims_List /= No_Elist then
+  if Present (Prims_List) then
  Prim_Elmt := First_Elmt (Prims_List);
  while Present (Prim_Elmt) loop
 Prim := Node (Prim_Elmt);


diff --git a/gcc/ada/sem_ch3.adb b/gcc/ada/sem_ch3.adb
--- a/gcc/ada/sem_ch3.adb
+++ b/gcc/ada/sem_ch3.adb
@@ -5849,7 +5849,7 @@ package body Sem_Ch3 is
  --  Inherit Subprograms_For_Type from the full view, if present
 
  if Present (Full_View (T))
-   and then Subprograms_For_Type (Full_View (T)) /= No_Elist
+   and then Present (Subprograms_For_Type (Full_View (T)))
  then
 Set_Subprograms_For_Type
   (Id, Subprograms_For_Type (Full_View (T)));


diff --git a/gcc/ada/sem_ch6.adb 

[Ada] Prevent search for references in postconditions from going too far

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Add a standard prevention against climbing the entire compilation unit.
Cleanup only; behaviour of the compiler is unaffected.

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

gcc/ada/

* sem_warn.adb (Within_Postcondition): Guard against search
going too far.diff --git a/gcc/ada/sem_warn.adb b/gcc/ada/sem_warn.adb
--- a/gcc/ada/sem_warn.adb
+++ b/gcc/ada/sem_warn.adb
@@ -2007,6 +2007,11 @@ package body Sem_Warn is
   then
  return True;
   end if;
+
+   --  Prevent the search from going too far
+
+   elsif Is_Body_Or_Package_Declaration (Nod) then
+  exit;
end if;
 
Nod := Parent (Nod);




[Ada] Remove tiny and incomplete optimization for unset references

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Code cleanup; behaviour is unaffected.

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

gcc/ada/

* sem_warn.adb (Check_Unset_Reference): The early test was only
saving time of calls to Original_Node, Comes_From_Source and
Nkind, which are all quick and cheap.diff --git a/gcc/ada/sem_warn.adb b/gcc/ada/sem_warn.adb
--- a/gcc/ada/sem_warn.adb
+++ b/gcc/ada/sem_warn.adb
@@ -1882,15 +1882,6 @@ package body Sem_Warn is
  return;
   end if;
 
-  --  Nothing to do for numeric or string literal. Do this test early to
-  --  save time in a common case (it does not matter that we do not include
-  --  character literal here, since that will be caught later on in the
-  --  when others branch of the case statement).
-
-  if Nkind (N) in N_Numeric_Or_String_Literal then
- return;
-  end if;
-
   --  Ignore reference unless it comes from source. Almost always if we
   --  have a reference from generated code, it is bogus (e.g. calls to init
   --  procs to set default discriminant values).




[Ada] Cleanup unnecessary declare block in Check_Unreachable_Code

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Cleanup related to static detection of references to uninitialized
variables. Semantics is unaffected.

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

gcc/ada/

* sem_ch5.adb (Check_Unreachable_Code): Remove inner declare
block; refill code and comments.diff --git a/gcc/ada/sem_ch5.adb b/gcc/ada/sem_ch5.adb
--- a/gcc/ada/sem_ch5.adb
+++ b/gcc/ada/sem_ch5.adb
@@ -4397,149 +4397,145 @@ package body Sem_Ch5 is
 
procedure Check_Unreachable_Code (N : Node_Id) is
   Error_Node : Node_Id;
+  Nxt: Node_Id;
   P  : Node_Id;
 
begin
   if Is_List_Member (N) and then Comes_From_Source (N) then
- declare
-Nxt : Node_Id;
+ Nxt := Original_Node (Next (N));
 
- begin
-Nxt := Original_Node (Next (N));
+ --  Skip past pragmas
 
---  Skip past pragmas
+ while Nkind (Nxt) = N_Pragma loop
+Nxt := Original_Node (Next (Nxt));
+ end loop;
 
-while Nkind (Nxt) = N_Pragma loop
-   Nxt := Original_Node (Next (Nxt));
-end loop;
+ --  If a label follows us, then we never have dead code, since someone
+ --  could branch to the label, so we just ignore it.
 
---  If a label follows us, then we never have dead code, since
---  someone could branch to the label, so we just ignore it.
+ if Nkind (Nxt) = N_Label then
+return;
 
-if Nkind (Nxt) = N_Label then
-   return;
+ --  Otherwise see if we have a real statement following us
 
---  Otherwise see if we have a real statement following us
+ elsif Present (Nxt)
+   and then Comes_From_Source (Nxt)
+   and then Is_Statement (Nxt)
+ then
+--  Special very annoying exception. If we have a return that
+--  follows a raise, then we allow it without a warning, since
+--  the Ada RM annoyingly requires a useless return here.
 
-elsif Present (Nxt)
-  and then Comes_From_Source (Nxt)
-  and then Is_Statement (Nxt)
+if Nkind (Original_Node (N)) /= N_Raise_Statement
+  or else Nkind (Nxt) /= N_Simple_Return_Statement
 then
-   --  Special very annoying exception. If we have a return that
-   --  follows a raise, then we allow it without a warning, since
-   --  the Ada RM annoyingly requires a useless return here.
-
-   if Nkind (Original_Node (N)) /= N_Raise_Statement
- or else Nkind (Nxt) /= N_Simple_Return_Statement
-   then
-  --  The rather strange shenanigans with the warning message
-  --  here reflects the fact that Kill_Dead_Code is very good
-  --  at removing warnings in deleted code, and this is one
-  --  warning we would prefer NOT to have removed.
-
-  Error_Node := Nxt;
+   --  The rather strange shenanigans with the warning message
+   --  here reflects the fact that Kill_Dead_Code is very good at
+   --  removing warnings in deleted code, and this is one warning
+   --  we would prefer NOT to have removed.
 
-  --  If we have unreachable code, analyze and remove the
-  --  unreachable code, since it is useless and we don't
-  --  want to generate junk warnings.
+   Error_Node := Nxt;
 
-  --  We skip this step if we are not in code generation mode
-  --  or CodePeer mode.
+   --  If we have unreachable code, analyze and remove the
+   --  unreachable code, since it is useless and we don't want
+   --  to generate junk warnings.
 
-  --  This is the one case where we remove dead code in the
-  --  semantics as opposed to the expander, and we do not want
-  --  to remove code if we are not in code generation mode,
-  --  since this messes up the tree or loses useful information
-  --  for CodePeer.
+   --  We skip this step if we are not in code generation mode
+   --  or CodePeer mode.
 
-  --  Note that one might react by moving the whole circuit to
-  --  exp_ch5, but then we lose the warning in -gnatc mode.
+   --  This is the one case where we remove dead code in the
+   --  semantics as opposed to the expander, and we do not want
+   --  to remove code if we are not in code generation mode, since
+   --  this messes up the tree or loses useful information for
+   --  CodePeer.
 
-  if Operating_Mode = Generate_Code
-and then not CodePeer_Mode
-  then
- loop
- 

[Ada] Refine iteration from entities to formals

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
When matching formal parameters from spec and body it is cleaner and
more efficient to iterate with First_Formal/Next_Formal and not with
First_Entity/Next_Entity. The previous iteration could unintentionally
pick entities from within the subprogram body, e.g. objects declared
within the subprogram.

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

gcc/ada/

* sem_ch6.adb (Analyze_Subprogram_Body_Helper): Replace
First_Entity/Next_Entity with First_Formal/Next_Formal; rename
E1/E2 to F1/F2.diff --git a/gcc/ada/sem_ch6.adb b/gcc/ada/sem_ch6.adb
--- a/gcc/ada/sem_ch6.adb
+++ b/gcc/ada/sem_ch6.adb
@@ -5407,8 +5407,8 @@ package body Sem_Ch6 is
   --  Check for variables that are never modified
 
   declare
- E1 : Entity_Id;
- E2 : Entity_Id;
+ F1 : Entity_Id;
+ F2 : Entity_Id;
 
   begin
  --  If there is a separate spec, then transfer Never_Set_In_Source
@@ -5417,21 +5417,21 @@ package body Sem_Ch6 is
  --  the body entities, not the spec entities.
 
  if Present (Spec_Id) then
-E1 := First_Entity (Spec_Id);
-while Present (E1) loop
-   if Ekind (E1) = E_Out_Parameter then
-  E2 := First_Entity (Body_Id);
-  while Present (E2) loop
- exit when Chars (E1) = Chars (E2);
- Next_Entity (E2);
+F1 := First_Formal (Spec_Id);
+while Present (F1) loop
+   if Ekind (F1) = E_Out_Parameter then
+  F2 := First_Formal (Body_Id);
+  while Present (F2) loop
+ exit when Chars (F1) = Chars (F2);
+ Next_Formal (F2);
   end loop;
 
-  if Present (E2) then
- Set_Never_Set_In_Source (E2, Never_Set_In_Source (E1));
+  if Present (F2) then
+ Set_Never_Set_In_Source (F2, Never_Set_In_Source (F1));
   end if;
end if;
 
-   Next_Entity (E1);
+   Next_Formal (F1);
 end loop;
  end if;
 




[Ada] Check declare and qualified expressions for unset references

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Detection of references to unset (uninitialized) objects requires calls
to Check_Unset_Reference on every subexpression of a composite statement
and expression. For declare and qualified expressions this was done only
when they occurred within another composite statement/expression.

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

gcc/ada/

* sem_res.adb (Resolve_Declare_Expression): Check expression for
references to unset objects.
(Resolve_Qualified_Expression): Likewise.
* sem_warn.adb (Check_Unset_Reference): Remove handling of
declare and qualified expressions; clarify comment for type
conversions.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
@@ -7673,6 +7673,7 @@ package body Sem_Res is
   end if;
 
   Resolve (Expr, Typ);
+  Check_Unset_Reference (Expr);
end Resolve_Declare_Expression;
 
-
@@ -10586,6 +10587,7 @@ package body Sem_Res is
 
begin
   Resolve (Expr, Target_Typ);
+  Check_Unset_Reference (Expr);
 
   --  A qualified expression requires an exact match of the type, class-
   --  wide matching is not allowed. However, if the qualifying type is


diff --git a/gcc/ada/sem_warn.adb b/gcc/ada/sem_warn.adb
--- a/gcc/ada/sem_warn.adb
+++ b/gcc/ada/sem_warn.adb
@@ -2244,13 +2244,11 @@ package body Sem_Warn is
Check_Unset_Reference (Pref);
 end;
 
- --  For type conversions, qualifications, or expressions with actions,
- --  examine the expression.
+ --  Type conversions can appear in assignment statements both
+ --  as variable names and as expressions. We examine their own
+ --  expressions only when processing their parent node.
 
- when N_Expression_With_Actions
-| N_Qualified_Expression
-| N_Type_Conversion
- =>
+ when N_Type_Conversion =>
 Check_Unset_Reference (Expression (N));
 
  --  For explicit dereference, always check prefix, which will generate




[Ada] Check if- and case-expressions for unset references

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Detection of references to unset (uninitialized) objects requires calls
to Check_Unset_Reference on every subexpression of a composite statement
and expression. This was missing for if-expressions and incomplete for
case-expressions.

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

gcc/ada/

* sem_res.adb (Resolve_Case_Expression): Check alternative
expressions for references to unset objects.
(Resolve_If_Expression): Check condition, then and else
expressions for references to unset objects.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
@@ -7394,6 +7394,7 @@ package body Sem_Res is
  end if;
 
  Resolve (Alt_Expr, Typ);
+ Check_Unset_Reference (Alt_Expr);
  Alt_Typ := Etype (Alt_Expr);
 
  --  When the expression is of a scalar subtype different from the
@@ -9317,6 +9318,9 @@ package body Sem_Res is
 
   Resolve (Condition, Any_Boolean);
   Resolve (Then_Expr, Result_Type);
+  Check_Unset_Reference (Condition);
+  Check_Unset_Reference (Then_Expr);
+
   Apply_Check (Then_Expr);
 
   --  If ELSE expression present, just resolve using the determined type
@@ -9333,6 +9337,8 @@ package body Sem_Res is
 Resolve (Else_Expr, Result_Type);
  end if;
 
+ Check_Unset_Reference (Else_Expr);
+
  Apply_Check (Else_Expr);
 
  --  Apply RM 4.5.7 (17/3): whether the expression is statically or




[Ada] Accept Structural in aspect Subprogram_Variant and pragma Loop_Variant

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Add a new form of variants to ensure termination of loops or recursive
subprograms. Structural variants correspond to objects which designate a
part of the data-structure they used to designate in the previous loop
iteration or recursive call. They only imply termination if the
data-structure is acyclic, which is the case in SPARK but not in Ada in
general. The fact that these variants are correct is only verified
formally by the proof tool and not by the compiler or dynamically at
execution like other forms of variants.

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

gcc/ada/

* snames.ads-tmpl: Add "Structural" as a name.
* sem_prag.adb: (Analyze_Pragma): Accept modifier "Structural"
in pragmas Loop_Variant and Subprogram_Variant. Check that items
associated to Structural occur alone in the pragma associations.
(Analyze_Subprogram_Variant_In_Decl_Part): Idem.
* exp_prag.adb (Expand_Pragma_Loop_Variant): Discard structural
variants.
(Expand_Pragma_Subprogram_Variant): Idem.

gcc/testsuite/

* gnat.dg/loopvar.adb: Update expected error message.diff --git a/gcc/ada/exp_prag.adb b/gcc/ada/exp_prag.adb
--- a/gcc/ada/exp_prag.adb
+++ b/gcc/ada/exp_prag.adb
@@ -2694,10 +2694,15 @@ package body Exp_Prag is
   --  If pragma is not enabled, rewrite as Null statement. If pragma is
   --  disabled, it has already been rewritten as a Null statement.
   --
-  --  Likewise, do this in CodePeer mode, because the expanded code is too
+  --  Likewise, ignore structural variants for execution.
+  --
+  --  Also do this in CodePeer mode, because the expanded code is too
   --  complicated for CodePeer to analyse.
 
-  if Is_Ignored (N) or else CodePeer_Mode then
+  if Is_Ignored (N)
+or else Chars (Last_Var) = Name_Structural
+or else CodePeer_Mode
+  then
  Rewrite (N, Make_Null_Statement (Loc));
  Analyze (N);
  return;
@@ -3058,10 +3063,12 @@ package body Exp_Prag is
 
   Loc : constant Source_Ptr := Sloc (Prag);
 
-  Aggr : Node_Id;
+  Aggr : constant Node_Id :=
+Expression (First (Pragma_Argument_Associations (Prag)));
   Formal_Map   : Elist_Id;
   Last : Node_Id;
-  Last_Variant : Node_Id;
+  Last_Variant : constant Node_Id :=
+Nlists.Last (Component_Associations (Aggr));
   Proc_Bod : Node_Id;
   Proc_Decl: Node_Id;
   Proc_Id  : Entity_Id;
@@ -3069,14 +3076,15 @@ package body Exp_Prag is
   Variant  : Node_Id;
 
begin
-  --  Do nothing if pragma is not present or is disabled
+  --  Do nothing if pragma is not present or is disabled.
+  --  Also ignore structural variants for execution.
 
-  if Is_Ignored (Prag) then
+  if Is_Ignored (Prag)
+or else Chars (Nlists.Last (Choices (Last_Variant))) = Name_Structural
+  then
  return;
   end if;
 
-  Aggr := Expression (First (Pragma_Argument_Associations (Prag)));
-
   --  The expansion of Subprogram Variant is quite distributed as it
   --  produces various statements to capture and compare the arguments.
   --  To preserve the original context, set the Is_Assertion_Expr flag.
@@ -3115,7 +3123,6 @@ package body Exp_Prag is
 
   Last := Proc_Decl;
   Curr_Decls   := New_List;
-  Last_Variant := Nlists.Last (Component_Associations (Aggr));
 
   Variant := First (Component_Associations (Aggr));
   while Present (Variant) loop


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
@@ -19423,7 +19423,8 @@ package body Sem_Prag is
if Chars (Variant) = No_Name then
   Error_Pragma_Arg_Ident ("expect name `Increases`", Variant);
 
-   elsif Chars (Variant) not in Name_Decreases | Name_Increases
+   elsif Chars (Variant) not in
+Name_Decreases | Name_Increases | Name_Structural
then
   declare
  Name : String := Get_Name_String (Chars (Variant));
@@ -19448,11 +19449,24 @@ package body Sem_Prag is
 Error_Pragma_Arg_Ident
   ("expect name `Decreases`", Variant);
 
+ elsif Name'Length >= 4
+   and then Name (1 .. 4) = "stru"
+ then
+Error_Pragma_Arg_Ident
+  ("expect name `Structural`", Variant);
+
  else
 Error_Pragma_Arg_Ident
-  ("expect name `Increases` or `Decreases`", Variant);
+  ("expect name `Increases`, `Decreases`,"
+   & " or `Structural`", Variant);
  end if;
   end;
+
+   elsif Chars (Variant) = Name_Structural
+  

  1   2   >