[pushed] c++: array temporary at file scope [PR104182]

2022-01-22 Thread Jason Merrill via Gcc-patches
This is the same issue as PR104031, but that patch doesn't fix this
testcase because in this case, current_function_decl isn't set when we get
to cp_genericize_target_expr.  But there seems to be no need for
is_local_temp to check for function scope; !TREE_STATIC should be enough.

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

PR c++/104182

gcc/cp/ChangeLog:

* cp-gimplify.cc (cp_genericize_target_expr): Make sure nothing
has set DECL_INITIAL on a TARGET_EXPR slot.
* tree.cc (is_local_temp): Don't check DECL_CONTEXT.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist127.C: New test.
---
 gcc/cp/cp-gimplify.cc|  6 +---
 gcc/cp/tree.cc   |  3 +-
 gcc/testsuite/g++.dg/cpp0x/initlist127.C | 39 
 3 files changed, 41 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist127.C

diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index 0166ef690d2..d1c653c5fda 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -931,13 +931,9 @@ static void
 cp_genericize_target_expr (tree *stmt_p)
 {
   tree slot = TARGET_EXPR_SLOT (*stmt_p);
-  /* If TARGET_EXPR is created for some global var initializer, the slot
- will have NULL and so is_local_temp will return false for it.  If
- this is a ssdf, set DECL_CONTEXT now.  */
-  if (DECL_CONTEXT (slot) == NULL_TREE)
-DECL_CONTEXT (slot) = current_function_decl;
   cp_genericize_init (&TARGET_EXPR_INITIAL (*stmt_p),
  TARGET_EXPR_INITIAL (*stmt_p), slot);
+  gcc_assert (!DECL_INITIAL (slot));
 }
 
 /* Genericization context.  */
diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index f88006aec4f..5d453e49717 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -557,8 +557,7 @@ bool
 is_local_temp (tree decl)
 {
   return (VAR_P (decl) && DECL_ARTIFICIAL (decl)
- && !TREE_STATIC (decl)
- && DECL_FUNCTION_SCOPE_P (decl));
+ && !TREE_STATIC (decl));
 }
 
 /* Set various status flags when building an AGGR_INIT_EXPR object T.  */
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist127.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist127.C
new file mode 100644
index 000..ebe5924bbf9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist127.C
@@ -0,0 +1,39 @@
+// PR c++/104182
+// { dg-do run { target c++11 } }
+
+#include 
+
+int b;
+
+struct stringy {
+  const char *p;
+  stringy(const char *p): p(p) { ++b; }
+  const char& operator[](int i) const { return p[i]; }
+  ~stringy() { --b; }
+};
+
+struct S
+{
+  int A;
+  stringy B;
+};
+
+struct veccy {
+  S s;
+  veccy (const std::initializer_list &l): s(*l.begin()) {}
+  const S& operator[](int i) const { return s; }
+};
+
+struct V
+{
+  veccy v;
+};
+
+static const V v{ { { { 237, "2" } } } };
+
+int main()
+{
+  if (v.v[0].A != 237 || v.v[0].B[0] != '2')
+__builtin_abort();
+  return 0;
+}

base-commit: d43be9dcc1bef95d70fb411d98b4de0d83c6b85d
prerequisite-patch-id: 2611088858b4dd4c0ce09bad7e27f4a837282865
-- 
2.27.0



[pushed] c++: constexpr and -fno-elide-constructors [PR101072]

2022-01-22 Thread Jason Merrill via Gcc-patches
We've been trying for a while to avoid TARGET_EXPRs in template code, but
there were still a few that snuck through, and the one in this case broke
the code that tried to handle it.  Fixed by using IMPLICIT_CONV_EXPR, as we
have done elsewhere.

I also noticed that finish_compound_literal was assuming that all T{init}
were for aggregate T, and we got a few more TARGET_EXPRs from that.  Fixed
by only messing with TARGET_EXPR if we actually have an aggregate init.

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

PR c++/101072

gcc/cp/ChangeLog:

* cp-tree.h (build_implicit_conv_flags): Declare.
* call.cc (build_implicit_conv_flags): Split out from...
(perform_implicit_conversion_flags): ...here.
* decl.cc (check_initializer): Use it.
* pt.cc (tsubst_copy_and_build): Remove TARGET_EXPR handling.
* semantics.cc (finish_compound_literal): Don't treat
scalar values like CONSTRUCTORs.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-empty14a.C: New test.
---
 gcc/cp/cp-tree.h  |  1 +
 gcc/cp/call.cc| 32 ---
 gcc/cp/decl.cc|  7 +++-
 gcc/cp/pt.cc  |  9 --
 gcc/cp/semantics.cc   |  9 --
 .../g++.dg/cpp0x/constexpr-empty14a.C | 11 +++
 6 files changed, 45 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-empty14a.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 186c54424a6..b9eb71fbc3a 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6599,6 +6599,7 @@ extern tree strip_top_quals   (tree);
 extern bool reference_related_p(tree, tree);
 extern bool reference_compatible_p (tree, tree);
 extern int remaining_arguments (tree);
+extern tree build_implicit_conv_flags  (tree, tree, int);
 extern tree perform_implicit_conversion(tree, tree, 
tsubst_flags_t);
 extern tree perform_implicit_conversion_flags  (tree, tree, tsubst_flags_t, 
int);
 extern tree build_converted_constant_expr  (tree, tree, tsubst_flags_t);
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index d4a07a7a9b3..f7f861cd16e 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -12638,6 +12638,25 @@ can_convert_arg_bad (tree to, tree from, tree arg, int 
flags,
   return t != NULL;
 }
 
+/* Return an IMPLICIT_CONV_EXPR from EXPR to TYPE with bits set from overload
+   resolution FLAGS.  */
+
+tree
+build_implicit_conv_flags (tree type, tree expr, int flags)
+{
+  /* In a template, we are only concerned about determining the
+ type of non-dependent expressions, so we do not have to
+ perform the actual conversion.  But for initializers, we
+ need to be able to perform it at instantiation
+ (or instantiate_non_dependent_expr) time.  */
+  expr = build1 (IMPLICIT_CONV_EXPR, type, expr);
+  if (!(flags & LOOKUP_ONLYCONVERTING))
+IMPLICIT_CONV_EXPR_DIRECT_INIT (expr) = true;
+  if (flags & LOOKUP_NO_NARROWING)
+IMPLICIT_CONV_EXPR_BRACED_INIT (expr) = true;
+  return expr;
+}
+
 /* Convert EXPR to TYPE.  Return the converted expression.
 
Note that we allow bad conversions here because by the time we get to
@@ -12674,18 +12693,7 @@ perform_implicit_conversion_flags (tree type, tree 
expr,
   expr = error_mark_node;
 }
   else if (processing_template_decl && conv->kind != ck_identity)
-{
-  /* In a template, we are only concerned about determining the
-type of non-dependent expressions, so we do not have to
-perform the actual conversion.  But for initializers, we
-need to be able to perform it at instantiation
-(or instantiate_non_dependent_expr) time.  */
-  expr = build1 (IMPLICIT_CONV_EXPR, type, expr);
-  if (!(flags & LOOKUP_ONLYCONVERTING))
-   IMPLICIT_CONV_EXPR_DIRECT_INIT (expr) = true;
-  if (flags & LOOKUP_NO_NARROWING)
-   IMPLICIT_CONV_EXPR_BRACED_INIT (expr) = true;
-}
+expr = build_implicit_conv_flags (type, expr, flags);
   else
 {
   /* Give a conversion call the same location as expr.  */
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 8e5421848d1..c5d4f2f5369 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -7235,7 +7235,12 @@ check_initializer (tree decl, tree init, int flags, 
vec **cleanups)
  /* In C++20, the call to build_aggr_init could have created
 an INIT_EXPR with a CONSTRUCTOR as the RHS to handle
 A(1, 2).  */
- init = TREE_OPERAND (init_code, 1);
+ tree rhs = TREE_OPERAND (init_code, 1);
+ if (processing_template_decl && TREE_CODE (rhs) == TARGET_EXPR)
+   /* Avoid leaking TARGET_EXPR into template trees.  */
+   rhs = build_implicit_conv_flags (type, init, flags);
+ init = rhs;
+
  init_cod

Re: [PATCH] x86: Also check VALID_BCST_MODE_P on memory broadcast

2022-01-22 Thread H.J. Lu via Gcc-patches
On Sat, Jan 22, 2022 at 2:24 PM H.J. Lu  wrote:
>
> Return false for invalid broadcast mode in bcst_mem_operand on memory
> broadcast:
>
> (vec_duplicate:V16SF (mem/j:V4SF (reg/v/f:DI 109 [ b ])))
>
> gcc/
>
> PR target/104188
> * config/i386/predicates.md (bcst_mem_operand): Also check
> VALID_BCST_MODE_P on memory broadcast.
>
> gcc/testsuite/
>
> PR target/104188
> * gcc.target/i386/pr104188.c: New test.
> ---
>  gcc/config/i386/predicates.md|  3 +-
>  gcc/testsuite/gcc.target/i386/pr104188.c | 70 
>  2 files changed, 72 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr104188.c
>
> diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
> index eae6ab58e23..fd716f006f3 100644
> --- a/gcc/config/i386/predicates.md
> +++ b/gcc/config/i386/predicates.md
> @@ -1157,7 +1157,8 @@ (define_predicate "bcst_mem_operand"
> (ior (match_test "TARGET_AVX512VL")
>  (match_test "GET_MODE_SIZE (GET_MODE (op)) == 64")))
> (match_test "VALID_BCST_MODE_P (GET_MODE_INNER (GET_MODE (op)))")
> -   (match_test "memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 
> 0)))")))
> +   (match_test "memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0)))")
> +   (match_test "VALID_BCST_MODE_P (GET_MODE (XEXP (op, 0)))")))

Is this one better?

diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index eae6ab58e23..a8cc17a054d 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -1157,6 +1157,8 @@ (define_predicate "bcst_mem_operand"
   (ior (match_test "TARGET_AVX512VL")
   (match_test "GET_MODE_SIZE (GET_MODE (op)) == 64")))
(match_test "VALID_BCST_MODE_P (GET_MODE_INNER (GET_MODE (op)))")
+   (match_test "GET_MODE (XEXP (op, 0))
+ == GET_MODE_INNER (GET_MODE (op))")
(match_test "memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0)))")))

 ; Return true when OP is bcst_mem_operand or vector_memory_operand.

>  ; Return true when OP is bcst_mem_operand or vector_memory_operand.
>  (define_predicate "bcst_vector_operand"
> diff --git a/gcc/testsuite/gcc.target/i386/pr104188.c 
> b/gcc/testsuite/gcc.target/i386/pr104188.c
> new file mode 100644
> index 000..c6f615b9625
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr104188.c
> @@ -0,0 +1,70 @@
> +/* { dg-do run { target avx512f } } */
> +/* { dg-options "-O2 -mfpmath=sse" } */
> +
> +#include 
> +
> +union U {
> +  float m[4][4];
> +  __m128 r[4];
> +  __m512 s;
> +};
> +
> +__attribute__((noipa, target("avx512f")))
> +void
> +foo (union U *x, union U *a, union U *b)
> +{
> +  __m512 c = _mm512_loadu_ps (&a->s);
> +  __m512 d = _mm512_broadcast_f32x4 (b->r[0]);
> +  __m512 e = _mm512_broadcast_f32x4 (b->r[1]);
> +  __m512 f = _mm512_broadcast_f32x4 (b->r[2]);
> +  __m512 g = _mm512_broadcast_f32x4 (b->r[3]);
> +  __m512 h = _mm512_mul_ps (_mm512_permute_ps (c, 0x00), d);
> +  h = _mm512_fmadd_ps (_mm512_permute_ps (c, 0x55), e, h);
> +  h = _mm512_fmadd_ps (_mm512_permute_ps (c, 0xaa), f, h);
> +  h = _mm512_fmadd_ps (_mm512_permute_ps (c, 0xff), g, h);
> +  _mm512_storeu_ps (&x->s, h);
> +}
> +
> +__attribute__((noipa, target("avx512f")))
> +void
> +do_test (void)
> +{
> +  union U a = { .m = { { 1.0f, 2.0f, 3.0f, 4.0f },
> +  { 5.0f, 6.0f, 7.0f, 8.0f },
> +  { 9.0f, 10.0f, 11.0f, 12.0f },
> +  { 13.0f, 14.0f, 15.0f, 16.0f } } };
> +  union U b = { .m = { { 17.0f, 18.0f, 19.0f, 20.0f },
> +  { 21.0f, 22.0f, 23.0f, 24.0f },
> +  { 25.0f, 26.0f, 27.0f, 28.0f },
> +  { 29.0f, 30.0f, 31.0f, 32.0f } } };
> +  union U c;
> +  foo (&c, &a, &b);
> +  if (c.m[0][0] != 250.0f
> +  || c.m[0][1] != 260.0f
> +  || c.m[0][2] != 270.0f
> +  || c.m[0][3] != 280.0f)
> +__builtin_abort ();
> +  if (c.m[1][0] != 618.0f
> +  || c.m[1][1] != 644.0f
> +  || c.m[1][2] != 670.0f
> +  || c.m[1][3] != 696.0f)
> +__builtin_abort ();
> +  if (c.m[2][0] != 986.0f
> +  || c.m[2][1] != 1028.0f
> +  || c.m[2][2] != 1070.0f
> +  || c.m[2][3] != 1112.0f)
> +__builtin_abort ();
> +  if (c.m[3][0] != 1354.0f
> +  || c.m[3][1] != 1412.0f
> +  || c.m[3][2] != 1470.0f
> +  || c.m[3][3] != 1528.0f)
> +__builtin_abort ();
> +}
> +
> +int
> +main ()
> +{
> +  if (__builtin_cpu_supports ("avx512f"))
> +do_test ();
> +  return 0;
> +}
> --
> 2.34.1
>


-- 
H.J.


Re: Difference between 32-bit SPARCv9 and SPARCv8+?

2022-01-22 Thread John Paul Adrian Glaubitz
Hi!

On 1/21/22 15:00, John Paul Adrian Glaubitz wrote:
> While playing around with the compiler options trying to find a solution, I 
> made an interesting
> discovery which is that GCC support 64-bit compare and swap on SPARCv8plus 
> but not on 32-bit
> SPARCv9:
> 
> glaubitz@gcc202:~$ echo | gcc -mv8plus -E -dM -|grep -i SWAP
> #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
> #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
> #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
> #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
> glaubitz@gcc202:~$ echo | gcc -mcpu=v9 -m32 -E -dM -|grep -i SWAP
> #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
> #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
> #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
> glaubitz@gcc202:~$

It gets even more confusing since on Solaris, gcc will actually support 64-bit 
atomic
operations when setting -mcpu=v9:

sysadmin@deimos:~$ echo | gcc -m32 -mcpu=v9 -E -dM -|grep -i SWAP
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
sysadmin@deimos:~$

Does anyone know the reasoning behind this?

Adrian

PS: Please CC me, I'm not subscribed.

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: [PATCH] libgccjit: Add support for register variables [PR104072]

2022-01-22 Thread Antoni Boucher via Gcc-patches
Hi.

Le mardi 18 janvier 2022 à 18:49 -0500, David Malcolm a écrit :
> On Mon, 2022-01-17 at 19:46 -0500, Antoni Boucher via Gcc-patches
> wrote:
> > I missed the comment about the new define, so here's the updated
> > patch.
> 
> Thanks for the patch.
> > 
> > Le lundi 17 janvier 2022 à 19:24 -0500, Antoni Boucher via Jit a
> > écrit :
> > > Hi.
> > > This patch add supports for register variables in libgccjit.
> > > 
> > > It passes the JIT tests, but since I added a function in
> > > reginfo.c,
> > > I
> > > wonder if I should run the whole testsuite.
> 
> We're in stage 4 for gcc 12, so we should be especially careful about
> changes right now, and we're not meant to be adding new GCC 12
> features.
> 
> How close is gcc 12's libgccjit to being usable with your rustc
> backend?  If we're almost there, I'm willing to make our case for
> late-
> breaking libgccjit changes to the release managers, but if you think
> rustc users are going to need to build a patched libgccjit, then
> let's
> queue this up for gcc 13.

As I mentioned in my other email, if the 4 patches currently being
reviewed (and listed here:
https://github.com/antoyo/libgccjit-patches) were included in gcc 12,
I'd be able to build rustc_codegen_gcc with an unpatched gcc.

It is to be noted however, that I'll need more patches for future work.
Off the top of my head, I'll at least need a patch for the inline
attribute, try/catch and target-specific builtins.
The last 2 features will probably take some time to implement, so I'll
let you judge if you think it's worth merging the 4 patches currently
being reviewed for gcc 12.

> 
> > 2022-01-17  Antoni Boucher 
> > 
> > gcc/jit/
> > PR target/104072
> 
> This should be "jit", rather than "target".
> 
> This will need updaing for the various .c to .cc renamings on trunk
> yesterday.

Done.

> 
> [...snip...]
> 
> > diff --git a/gcc/jit/dummy-frontend.c b/gcc/jit/dummy-frontend.c
> > index 84ff359bfe3..04d8fc6ab48 100644
> > --- a/gcc/jit/dummy-frontend.c
> > +++ b/gcc/jit/dummy-frontend.c
> > @@ -599,6 +599,8 @@ jit_langhook_init (void)
> >  
> >    build_common_builtin_nodes ();
> >  
> > +  clear_global_regs_cache ();
> > +
> 
> Similarly to my comments on the bitcasts patch, call this from a
> reginfo_cc_finalize function called from toplev::finalize instead.

Done.

> 
> > diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
> > index 03704ef10b8..1757ad583fe 100644
> > --- a/gcc/jit/libgccjit.c
> > +++ b/gcc/jit/libgccjit.c
> > @@ -2649,6 +2649,18 @@ gcc_jit_lvalue_set_link_section
> > (gcc_jit_lvalue *lvalue,
> >    lvalue->set_link_section (section_name);
> >  }
> >  
> > +/* Public entrypoint.  See description in libgccjit.h.
> > +
> > +   After error-checking, the real work is done by the
> > +   gcc::jit::recording::lvalue::set_register_name method in jit-
> > recording.c.  */
> > +
> > +void
> > +gcc_jit_lvalue_set_register_name (gcc_jit_lvalue *lvalue,
> > + const char *reg_name)
> > +{
> 
> Need error checking here, to gracefully reject NULL value, and NULL
> reg_name.

Done.

> 
> > +  lvalue->set_register_name (reg_name);
> > +}
> > +
> 
> > diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
> > index c93d7055d43..af4427c4503 100644
> > --- a/gcc/jit/jit-playback.h
> > +++ b/gcc/jit/jit-playback.h
> > @@ -24,6 +24,7 @@ along with GCC; see the file COPYING3.  If not
> > see
> >  #include  // for std::pair
> >  
> >  #include "timevar.h"
> > +#include "varasm.h"
> >  
> >  #include "jit-recording.h"
> >  
> > @@ -701,6 +702,14 @@ public:
> >  set_decl_section_name (as_tree (), name);
> >    }
> >  
> > +  void
> > +  set_register_name (const char* reg_name)
> > +  {
> > +    set_user_assembler_name (as_tree (), reg_name);
> > +    DECL_REGISTER (as_tree ()) = 1;
> > +    DECL_HARD_REGISTER (as_tree ()) = 1;
> > +  }
> 
> I'm not familiar enough with the backend to know if this is correct,
> sorry.
> 
> Is there an analogous thing in the C frontend that this corresponds
> to?

Not really as this is doing multiple things in one shot, while in the C
frontend, the register keyword will do one thing, specifying the
register name is another, …

> 
> [...snip...]
> 
> > diff --git a/gcc/reginfo.c b/gcc/reginfo.c
> > index 234f72eceeb..4fe375c4463 100644
> > --- a/gcc/reginfo.c
> > +++ b/gcc/reginfo.c
> > @@ -91,6 +91,14 @@ static const char initial_call_used_regs[] =
> > CALL_USED_REGISTERS;
> >     and are also considered fixed.  */
> >  char global_regs[FIRST_PSEUDO_REGISTER];
> >  
> > +void clear_global_regs_cache (void)
> > +{
> 
> This should be made static and called from a reginfo_cc_finalize,
> called from toplev::finalize.
> 
> > +  for (size_t i = 0 ; i < FIRST_PSEUDO_REGISTER ; i++)
> > +  {
> > +    global_regs[i] = 0;
> 
> Probably should also clear global_regs_decl[i].
> 
> > +  }
> 
> and unset all of global_reg_set, I believe.  I'm not particularly
> familiar with this code, so a backend expert should look at this.

Re: [PATCH][GCC13?] RISC-V: Replace `smin'/`smax' RTL patterns with `fmin'/`fmax'

2022-01-22 Thread Maciej W. Rozycki
On Thu, 20 Jan 2022, Joseph Myers wrote:

> > The old formulation of the instructions were never ratified as a
> > RISC-V standard.  I don't think we need to hamstring ourselves here by
> > assuming the possibility of their implementation.
> 
> If you ignore the old version, then the instructions can unconditionally 
> be used for the fminimum_num / fmaximum_num functions (which GCC doesn't 
> support as built-in functions at present) - but can't be used for the fmin 
> / fmax functions if flag_signaling_nans.

 Fair enough, thank you for your detailed explanation of the requirements 
set by the individual revisions of the relevant standards, very valuable.

 I think we have consensus that we can ignore pre-r2.2 hardware.  What we 
actually support is `-misa-spec=<2.2|20190608|20191213>', so we can assume 
r2.2 semantics as the absolute minimum, matching the description in my 
submission.

 Also GCC documents IEEE 754-2008 semantics for the `fmin' and `fmax' RTL 
operations:

"'fminM3', 'fmaxM3'
 IEEE-conformant minimum and maximum operations.  If one operand is
 a quiet 'NaN', then the other operand is returned.  If both
 operands are quiet 'NaN', then a quiet 'NaN' is returned.  In the
 case when gcc supports signaling 'NaN' (-fsignaling-nans) an
 invalid floating point exception is raised and a quiet 'NaN' is
 returned."

and I think they need to stay as they are for the sake of IEEE 754-2008 
hardware and the `minNum' and `maxNum' (`fmin'/`fmax') operations.

 Looking further r20190608 of the RISC-V ISA specification then has[1]:

"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[2]:

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

 So for forwards compatibility of software built for r2.2 (such that it 
continues producing correct results with r20190608+ hardware) I think we 
need to provide `fmin'/`fmax' insns iff !HONOR_SNANS while keeping 
`smin'/`smax' insns intact.

 Then once we have IEEE 754-2019 support in place, which will require new 
RTL standard pattern names, say `fminimum'/`fmaximum', we will provide 
them iff (!HONOR_SNANS || riscv_isa_spec >= ISA_SPEC_CLASS_20190608).  It 
may be a good idea to start adding IEEE 754-2019 support, including the 
relevant `__builtin_fminimum' and `__builtin_fmaximum' intrinsics, once 
the GCC 13 development cycle has started.

 I'll post v2 then according to this consideration, once it's gone through 
regression testing.  Thanks for your input again.

References:

[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

  Maciej


[PATCH] x86: Also check VALID_BCST_MODE_P on memory broadcast

2022-01-22 Thread H.J. Lu via Gcc-patches
Return false for invalid broadcast mode in bcst_mem_operand on memory
broadcast:

(vec_duplicate:V16SF (mem/j:V4SF (reg/v/f:DI 109 [ b ])))

gcc/

PR target/104188
* config/i386/predicates.md (bcst_mem_operand): Also check
VALID_BCST_MODE_P on memory broadcast.

gcc/testsuite/

PR target/104188
* gcc.target/i386/pr104188.c: New test.
---
 gcc/config/i386/predicates.md|  3 +-
 gcc/testsuite/gcc.target/i386/pr104188.c | 70 
 2 files changed, 72 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr104188.c

diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index eae6ab58e23..fd716f006f3 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -1157,7 +1157,8 @@ (define_predicate "bcst_mem_operand"
(ior (match_test "TARGET_AVX512VL")
 (match_test "GET_MODE_SIZE (GET_MODE (op)) == 64")))
(match_test "VALID_BCST_MODE_P (GET_MODE_INNER (GET_MODE (op)))")
-   (match_test "memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0)))")))
+   (match_test "memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0)))")
+   (match_test "VALID_BCST_MODE_P (GET_MODE (XEXP (op, 0)))")))
 
 ; Return true when OP is bcst_mem_operand or vector_memory_operand.
 (define_predicate "bcst_vector_operand"
diff --git a/gcc/testsuite/gcc.target/i386/pr104188.c 
b/gcc/testsuite/gcc.target/i386/pr104188.c
new file mode 100644
index 000..c6f615b9625
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr104188.c
@@ -0,0 +1,70 @@
+/* { dg-do run { target avx512f } } */
+/* { dg-options "-O2 -mfpmath=sse" } */
+
+#include 
+
+union U {
+  float m[4][4];
+  __m128 r[4];
+  __m512 s;
+};
+
+__attribute__((noipa, target("avx512f")))
+void
+foo (union U *x, union U *a, union U *b)
+{
+  __m512 c = _mm512_loadu_ps (&a->s);
+  __m512 d = _mm512_broadcast_f32x4 (b->r[0]);
+  __m512 e = _mm512_broadcast_f32x4 (b->r[1]);
+  __m512 f = _mm512_broadcast_f32x4 (b->r[2]);
+  __m512 g = _mm512_broadcast_f32x4 (b->r[3]);
+  __m512 h = _mm512_mul_ps (_mm512_permute_ps (c, 0x00), d);
+  h = _mm512_fmadd_ps (_mm512_permute_ps (c, 0x55), e, h);
+  h = _mm512_fmadd_ps (_mm512_permute_ps (c, 0xaa), f, h);
+  h = _mm512_fmadd_ps (_mm512_permute_ps (c, 0xff), g, h);
+  _mm512_storeu_ps (&x->s, h);
+}
+
+__attribute__((noipa, target("avx512f")))
+void
+do_test (void)
+{
+  union U a = { .m = { { 1.0f, 2.0f, 3.0f, 4.0f },
+  { 5.0f, 6.0f, 7.0f, 8.0f },
+  { 9.0f, 10.0f, 11.0f, 12.0f },
+  { 13.0f, 14.0f, 15.0f, 16.0f } } };
+  union U b = { .m = { { 17.0f, 18.0f, 19.0f, 20.0f },
+  { 21.0f, 22.0f, 23.0f, 24.0f },
+  { 25.0f, 26.0f, 27.0f, 28.0f },
+  { 29.0f, 30.0f, 31.0f, 32.0f } } };
+  union U c;
+  foo (&c, &a, &b);
+  if (c.m[0][0] != 250.0f
+  || c.m[0][1] != 260.0f
+  || c.m[0][2] != 270.0f
+  || c.m[0][3] != 280.0f)
+__builtin_abort ();
+  if (c.m[1][0] != 618.0f
+  || c.m[1][1] != 644.0f
+  || c.m[1][2] != 670.0f
+  || c.m[1][3] != 696.0f)
+__builtin_abort ();
+  if (c.m[2][0] != 986.0f
+  || c.m[2][1] != 1028.0f
+  || c.m[2][2] != 1070.0f
+  || c.m[2][3] != 1112.0f)
+__builtin_abort ();
+  if (c.m[3][0] != 1354.0f
+  || c.m[3][1] != 1412.0f
+  || c.m[3][2] != 1470.0f
+  || c.m[3][3] != 1528.0f)
+__builtin_abort ();
+}
+
+int
+main ()
+{
+  if (__builtin_cpu_supports ("avx512f"))
+do_test ();
+  return 0;
+}
-- 
2.34.1



[PATCH] c++: value category of compound object expr [PR104173]

2022-01-22 Thread Patrick Palka via Gcc-patches
Here the call to the &&-qualified toLower() is incorrectly rejected
because the object expression is deemed to be an lvalue, even though it's
really a prvalue.  The object expression, instance()->applicationName(),
is expressed as an INDIRECT_REF of a COMPOUND_EXPR

  *(*instance ();, &TARGET_EXPR ;);

which lvalue_kind categorizes as an lvalue.

This issue seems similar to PR88103 except that here the compound object
expression is a prvalue rather than an xvalue.  The fix there was to
adjust the result of unary_complex_lvalue in build_class_member_access_expr
so that xvalue-ness is preserved.  This patch extends the fix so that
rvalue-ness is preserved more generally.

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

PR c++/104173

gcc/cp/ChangeLog:

* typeck.cc (build_class_member_access_expr): Extend
unary_complex_lvalue result adjustment to preserve all
rvalues, not just xvalues.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/ref-qual21.C: New test.
---
 gcc/cp/typeck.cc| 19 ---
 gcc/testsuite/g++.dg/cpp0x/ref-qual21.C | 16 
 2 files changed, 24 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/ref-qual21.C

diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index 3a28d639cb1..59668203573 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -2726,17 +2726,14 @@ build_class_member_access_expr (cp_expr object, tree 
member,
   /* Transform `(a, b).x' into `(*(a, &b)).x', `(a ? b : c).x' into
  `(*(a ?  &b : &c)).x', and so on.  A COND_EXPR is only an lvalue
  in the front end; only _DECLs and _REFs are lvalues in the back end.  */
-  {
-tree temp = unary_complex_lvalue (ADDR_EXPR, object);
-if (temp)
-  {
-   temp = cp_build_fold_indirect_ref (temp);
-   if (xvalue_p (object) && !xvalue_p (temp))
- /* Preserve xvalue kind.  */
- temp = move (temp);
-   object = temp;
-  }
-  }
+  if (tree temp = unary_complex_lvalue (ADDR_EXPR, object))
+{
+  temp = cp_build_fold_indirect_ref (temp);
+  if (!lvalue_p (object) && lvalue_p (temp))
+   /* Preserve rvalue-ness.  */
+   temp = move (temp);
+  object = temp;
+}
 
   /* In [expr.ref], there is an explicit list of the valid choices for
  MEMBER.  We check for each of those cases here.  */
diff --git a/gcc/testsuite/g++.dg/cpp0x/ref-qual21.C 
b/gcc/testsuite/g++.dg/cpp0x/ref-qual21.C
new file mode 100644
index 000..e2c43c345ab
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/ref-qual21.C
@@ -0,0 +1,16 @@
+// PR c++/104173
+// { dg-do compile { target c++11 } }
+
+struct QString {
+  QString toLower() &&;
+};
+
+struct QCoreApplication {
+  static QString applicationName();
+};
+
+QCoreApplication *instance();
+
+int main() {
+  instance()->applicationName().toLower();
+}
-- 
2.35.0.rc1



[PATCH] Fix build issues for *-linux-android and add aarch64-linux-android support. [PR101785, PR99499]

2022-01-22 Thread cqwrteur via Gcc-patches
I have add aarch64-linux-android target support and fix build issues with 
libstdc++ for android.

Several small issues like no libpthread.a (since android does not need 
libpthread.a) + 'ifunc' is not supported on this target, i will leave other 
people to fix.
---
 gcc/config.gcc |  3 +-
 gcc/config/aarch64/aarch64-linux.h | 48 --
 libstdc++-v3/config/os/bionic/ctype_base.h | 38 +++--
 3 files changed, 72 insertions(+), 17 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 2c4266ce7b0..8d25868e1cd 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1129,10 +1129,11 @@ aarch64*-*-netbsd*)
extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
;;
 aarch64*-*-linux*)
-   tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h"
+   tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h linux.h linux-android.h 
glibc-stdint.h"
tm_file="${tm_file} aarch64/aarch64-elf.h aarch64/aarch64-errata.h 
aarch64/aarch64-linux.h"
tmake_file="${tmake_file} aarch64/t-aarch64 aarch64/t-aarch64-linux"
tm_defines="${tm_defines}  TARGET_DEFAULT_ASYNC_UNWIND_TABLES=1"
+   extra_options="${extra_options} linux-android.opt"
case $target in
aarch64_be-*)
tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
diff --git a/gcc/config/aarch64/aarch64-linux.h 
b/gcc/config/aarch64/aarch64-linux.h
index 5e4553d79f5..3e6b112ae95 100644
--- a/gcc/config/aarch64/aarch64-linux.h
+++ b/gcc/config/aarch64/aarch64-linux.h
@@ -26,6 +26,9 @@
 #undef MUSL_DYNAMIC_LINKER
 #define MUSL_DYNAMIC_LINKER 
"/lib/ld-musl-aarch64%{mbig-endian:_be}%{mabi=ilp32:_ilp32}.so.1"
 
+#undef BIONIC_DYNAMIC_LINKER
+#define BIONIC_DYNAMIC_LINKER "/system/bin/linker64"
+
 #undef  ASAN_CC1_SPEC
 #define ASAN_CC1_SPEC "%{%:sanitize(address):-funwind-tables}"
 
@@ -46,11 +49,48 @@
%{mbig-endian:-EB} %{mlittle-endian:-EL} \
-maarch64linux%{mabi=ilp32:32}%{mbig-endian:b}"
 
-
-#define LINK_SPEC LINUX_TARGET_LINK_SPEC AARCH64_ERRATA_LINK_SPEC
-
 #define GNU_USER_TARGET_MATHFILE_SPEC \
   "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s}"
+  
+#if defined(TARGET_ANDROID)
+
+#define EXTRA_TARGET_D_OS_VERSIONS()   \
+  ANDROID_TARGET_D_OS_VERSIONS();
+
+#define LINK_SPEC  LINUX_TARGET_LINK_SPEC AARCH64_ERRATA_LINK_SPEC 
ANDROID_LINK_SPEC
+
+#undef  SUBTARGET_CC1_SPEC
+#define SUBTARGET_CC1_SPEC \
+  LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC,   \
+  GNU_USER_TARGET_CC1_SPEC " " ANDROID_CC1_SPEC)
+
+#undef  LIB_SPEC
+#define LIB_SPEC   \
+  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC,   \
+   GNU_USER_TARGET_NO_PTHREADS_LIB_SPEC " " ANDROID_LIB_SPEC)
+
+#undef  STARTFILE_SPEC
+#define STARTFILE_SPEC \
+  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, ANDROID_STARTFILE_SPEC)
+
+#undef  ENDFILE_SPEC
+#define ENDFILE_SPEC   \
+  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC " "   \
+  GNU_USER_TARGET_ENDFILE_SPEC,\
+  GNU_USER_TARGET_MATHFILE_SPEC " "\
+  ANDROID_ENDFILE_SPEC)
+
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+   GNU_USER_TARGET_OS_CPP_BUILTINS();  \
+  ANDROID_TARGET_OS_CPP_BUILTINS();\
+}  \
+  while (0)
+
+#else
+
+#define LINK_SPEC LINUX_TARGET_LINK_SPEC AARCH64_ERRATA_LINK_SPEC
 
 #undef ENDFILE_SPEC
 #define ENDFILE_SPEC   \
@@ -64,6 +104,8 @@
 }  \
   while (0)
 
+#endif
+
 #define TARGET_ASM_FILE_END aarch64_file_end_indicate_exec_stack
 
 /* Uninitialized common symbols in non-PIE executables, even with
diff --git a/libstdc++-v3/config/os/bionic/ctype_base.h 
b/libstdc++-v3/config/os/bionic/ctype_base.h
index bbb499ce749..8c5a505ee8d 100644
--- a/libstdc++-v3/config/os/bionic/ctype_base.h
+++ b/libstdc++-v3/config/os/bionic/ctype_base.h
@@ -27,6 +27,19 @@
 //
 
 // Information as gleaned from /usr/include/ctype.h
+// Define macros by ourselves so we do not get into more troubles.
+#define _GLIBCXX_U 0x01
+#define _GLIBCXX_L 0x02
+#define _GLIBCXX_D 0x04
+#define _GLIBCXX_S 0x08
+#define _GLIBCXX_P 0x10
+#define _GLIBCXX_C 0x20
+#define _GLIBCXX_X 0x40
+#define _GLIBCXX_B 0x80
+#define _GLIBCXX_R (_GLIBCXX_P|_GLIBCXX_U|\
+_GLIBCXX_L|_GLIBCXX_D|_GLIBCXX_B)
+#define _GLIBCXX_A (_GLIBCXX_L|_GLIBCXX_U)
+#define _GLIBCXX_N _GLIBCXX_D
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -41,20 +54,19 @@ _GLIBCXX_BEGIN_NAME

Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc

2022-01-22 Thread Mikael Morin

Hello,

Le 17/01/2022 à 00:11, FX via Fortran a écrit :

This patch is the third in my “signaling NaN” series. For targets with IEEE 
support but without the issignaling macro in libc (i.e., everywhere except 
glibc), this allows us to provide a fallback implementation. In order to keep 
the code in ieee_helper.c relatively readable, I’ve put that new implementation 
in a separate file, issignaling_fallback.h.

The logic is borrowed from different routines in glibc, but gathered into a 
single file and much simpler than the glibc implementation, because we do not 
need to cover all the cases they have (comments with details are available in 
issignaling_fallback.h).

I can’t test this on all the targets I’d like to, obviously. But it was tested 
on x86_64-pc-linux-gnu (where it doesn’t do anything), on x86_64-pc-linux-gnu 
by mimicking the lack of a issignaling macro, and on x86_64-apple-darwin (which 
does not have issignaling).

OK to push?


again, I feel underqualified to review this.
I spotted two unexpected things (to me at least) related to x86 extended 
type:



diff --git a/libgfortran/ieee/issignaling_fallback.h 
b/libgfortran/ieee/issignaling_fallback.h
new file mode 100644
index 000..e824cf8c59b
--- /dev/null
+++ b/libgfortran/ieee/issignaling_fallback.h


...


+
+#elif (__LDBL_DIG__ == 18) && __LDBL_IS_IEC_60559__
+
+/* Long double is x86 extended type.  */
+
+typedef union
+{
+  long double value;
+  struct
+  {
+#if __FLOAT_WORD_ORDER == __BIG_ENDIAN
+int sign_exponent:16;
+unsigned int empty:16;
+uint32_t msw;
+uint32_t lsw;
+#elif __FLOAT_WORD_ORDER == __LITTLE_ENDIAN
+uint32_t lsw;
+uint32_t msw;
+int sign_exponent:16;
+unsigned int empty:16;
+#endif
+  } parts;
+} ieee_long_double_shape_type;
+


- You check for endianness, so the format is not x86-specific?
- Is it expected that the padding bits are in the middle of the data in 
the big-endian case?




Re: [PATCH] Disable -fsplit-stack support on non-glibc targets

2022-01-22 Thread Jakub Jelinek via Gcc-patches
On Sat, Jan 22, 2022 at 01:16:38PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Actually, I suspect we either need something like following patch,
> or need to change gcc/config/{linux,rs6000/linux{,64},alpha/linux}.h
> so that next to those OPTION_GLIBC etc. macros it also defines versions
> of those macros with opts argument.

And here is a larger but perhaps cleaner patch that matches how e.g.
options.h defines TARGET_WHATEVER_P(opts) options and then TARGET_WHATEVER
too.

Only compile tested on x86_64-linux so far.

2022-01-22  Jakub Jelinek  

* config/linux.h (OPTION_GLIBC_P, OPTION_UCLIBC_P,
OPTION_BIONIC_P, OPTION_MUSL_P): Define.
(OPTION_GLIBC, OPTION_UCLIBC, OPTION_BIONIC, OPTION_MUSL): Redefine
using OPTION_*_P macros.
* config/alpha/linux.h (OPTION_GLIBC_P, OPTION_UCLIBC_P,
OPTION_BIONIC_P, OPTION_MUSL_P): Define.
(OPTION_GLIBC, OPTION_UCLIBC, OPTION_BIONIC, OPTION_MUSL): Redefine
using OPTION_*_P macros.
* config/rs6000/linux.h (OPTION_GLIBC_P, OPTION_UCLIBC_P,
OPTION_BIONIC_P, OPTION_MUSL_P): Define.
(OPTION_GLIBC, OPTION_UCLIBC, OPTION_BIONIC, OPTION_MUSL): Redefine
using OPTION_*_P macros.
* config/rs6000/linux64.h (OPTION_GLIBC_P, OPTION_UCLIBC_P,
OPTION_BIONIC_P, OPTION_MUSL_P): Define.
(OPTION_GLIBC, OPTION_UCLIBC, OPTION_BIONIC, OPTION_MUSL): Redefine
using OPTION_*_P macros.
* config/fuchsia.h (OPTION_MUSL_P): Redefine.
* config/glibc-stdint.h (OPTION_MUSL_P): Define if not defined.
* common/config/s390/s390-common.cc (s390_supports_split_stack): Re-add
ATTRIBUTE_UNUSED to opts parameter.  If OPTION_GLIBC_P is defined, use
OPTION_GLIBC_P (opts) as condition, otherwise assume if (false).
* common/config/i386/i386-common.cc (ix86_supports_split_stack): If
OPTION_GLIBC_P is defined use !OPTION_GLIBC_P (opts) as condition,
otherwise assume if (true).

--- gcc/config/linux.h.jj   2022-01-18 11:58:59.160988086 +0100
+++ gcc/config/linux.h  2022-01-22 18:42:25.476235564 +0100
@@ -29,18 +29,23 @@ see the files COPYING3 and COPYING.RUNTI
 
 /* C libraries supported on Linux.  */
 #ifdef SINGLE_LIBC
-#define OPTION_GLIBC  (DEFAULT_LIBC == LIBC_GLIBC)
-#define OPTION_UCLIBC (DEFAULT_LIBC == LIBC_UCLIBC)
-#define OPTION_BIONIC (DEFAULT_LIBC == LIBC_BIONIC)
-#undef OPTION_MUSL
-#define OPTION_MUSL   (DEFAULT_LIBC == LIBC_MUSL)
+#define OPTION_GLIBC_P(opts)   (DEFAULT_LIBC == LIBC_GLIBC)
+#define OPTION_UCLIBC_P(opts)  (DEFAULT_LIBC == LIBC_UCLIBC)
+#define OPTION_BIONIC_P(opts)  (DEFAULT_LIBC == LIBC_BIONIC)
+#undef OPTION_MUSL_P
+#define OPTION_MUSL_P(opts)(DEFAULT_LIBC == LIBC_MUSL)
 #else
-#define OPTION_GLIBC  (linux_libc == LIBC_GLIBC)
-#define OPTION_UCLIBC (linux_libc == LIBC_UCLIBC)
-#define OPTION_BIONIC (linux_libc == LIBC_BIONIC)
-#undef OPTION_MUSL
-#define OPTION_MUSL   (linux_libc == LIBC_MUSL)
+#define OPTION_GLIBC_P(opts)   ((opts)->x_linux_libc == LIBC_GLIBC)
+#define OPTION_UCLIBC_P(opts)  ((opts)->x_linux_libc == LIBC_UCLIBC)
+#define OPTION_BIONIC_P(opts)  ((opts)->x_linux_libc == LIBC_BIONIC)
+#undef OPTION_MUSL_P
+#define OPTION_MUSL_P(opts)((opts)->x_linux_libc == LIBC_MUSL)
 #endif
+#define OPTION_GLIBC   OPTION_GLIBC_P (&global_options)
+#define OPTION_UCLIBC  OPTION_UCLIBC_P (&global_options)
+#define OPTION_BIONIC  OPTION_BIONIC_P (&global_options)
+#undef OPTION_MUSL
+#define OPTION_MUSLOPTION_MUSL_P (&global_options)
 
 #define GNU_USER_TARGET_OS_CPP_BUILTINS()  \
 do {   \
--- gcc/config/alpha/linux.h.jj 2022-01-11 23:11:21.692299963 +0100
+++ gcc/config/alpha/linux.h2022-01-22 18:43:59.739923743 +0100
@@ -58,18 +58,23 @@ along with GCC; see the file COPYING3.
 #define WCHAR_TYPE "int"
 
 #ifdef SINGLE_LIBC
-#define OPTION_GLIBC  (DEFAULT_LIBC == LIBC_GLIBC)
-#define OPTION_UCLIBC (DEFAULT_LIBC == LIBC_UCLIBC)
-#define OPTION_BIONIC (DEFAULT_LIBC == LIBC_BIONIC)
-#undef OPTION_MUSL
-#define OPTION_MUSL   (DEFAULT_LIBC == LIBC_MUSL)
+#define OPTION_GLIBC_P(opts)   (DEFAULT_LIBC == LIBC_GLIBC)
+#define OPTION_UCLIBC_P(opts)  (DEFAULT_LIBC == LIBC_UCLIBC)
+#define OPTION_BIONIC_P(opts)  (DEFAULT_LIBC == LIBC_BIONIC)
+#undef OPTION_MUSL_P
+#define OPTION_MUSL_P(opts)(DEFAULT_LIBC == LIBC_MUSL)
 #else
-#define OPTION_GLIBC  (linux_libc == LIBC_GLIBC)
-#define OPTION_UCLIBC (linux_libc == LIBC_UCLIBC)
-#define OPTION_BIONIC (linux_libc == LIBC_BIONIC)
-#undef OPTION_MUSL
-#define OPTION_MUSL   (linux_libc == LIBC_MUSL)
+#define OPTION_GLIBC_P(opts)   ((opts)->x_linux_libc == LIBC_GLIBC)
+#define OPTION_UCLIBC_P(opts)  ((opts)->x_linux_libc == LIBC_UCLIBC)
+#define OPTION_BIONIC_P(opts)  ((opts)->x_linux_libc == LIBC_BIONIC)
+#undef OPTION_MUSL_P
+#define OPTION_MUSL_P(opts)((opts)->x_linux_libc == LIBC_MUSL)
 #endif
+#define OPTION_GLIBC   OPTI

Re: [PATCH] bootstrap: Fix bootstrap with --disable-plugin [PR104176]

2022-01-22 Thread Richard Biener via Gcc-patches



> Am 22.01.2022 um 13:00 schrieb Jakub Jelinek via Gcc-patches 
> :
> 
> Hi!
> 
> With --disable-plugin, bootstrap fails on x86_64-linux or probably
> all other targets with:
> ../../gcc/opts-global.cc: In function ‘void handle_common_deferred_options()’:
> ../../gcc/opts-global.cc:420:62: error: unquoted option name 
> ‘--enable-plugin’ in format [-Werror=format-diag]
>  420 |   error ("plugin support is disabled; configure with 
> --enable-plugin");
>  |  
> ^~~
> ../../gcc/opts-global.cc:428:62: error: unquoted option name 
> ‘--enable-plugin’ in format [-Werror=format-diag]
>  428 |   error ("plugin support is disabled; configure with 
> --enable-plugin");
>  |  
> ^~~
> 
> The following patch fixes that, bootstrapped on x86_64-linux with
> --disable-plugin --enable-languages=c,c++
> without the patch (where it failed as above) and with it (where it
> succeeded), ok for trunk

Ok.
Richard 
> 2022-01-22  Jakub Jelinek  
> 
>PR other/104176
>* opts-global.cc (handle_common_deferred_options): Quote
>--enable-plugin in diagnostics to avoid -Werror=format-diag.
> 
> --- gcc/opts-global.cc.jj2022-01-18 11:58:59.741979785 +0100
> +++ gcc/opts-global.cc2022-01-22 02:18:39.116047945 +0100
> @@ -417,7 +417,8 @@ handle_common_deferred_options (void)
> #ifdef ENABLE_PLUGIN
>  add_new_plugin (opt->arg);
> #else
> -  error ("plugin support is disabled; configure with --enable-plugin");
> +  error ("plugin support is disabled; configure with "
> + "%<--enable-plugin%>");
> #endif
>  break;
> 
> @@ -425,7 +426,8 @@ handle_common_deferred_options (void)
> #ifdef ENABLE_PLUGIN
>  parse_plugin_arg_opt (opt->arg);
> #else
> -  error ("plugin support is disabled; configure with --enable-plugin");
> +  error ("plugin support is disabled; configure with "
> + "%<--enable-plugin%>");
> #endif
>  break;
> 
> 
> 
>Jakub
> 


[committed] testsuite: guard usage of _Float16 in analyzer test [PR104150]

2022-01-22 Thread David Malcolm via Gcc-patches
Committed to trunk as r12-6818-ga1fb81bda97014ba14d55c4c2e143d31ffe2e264.

gcc/testsuite/ChangeLog:
PR analyzer/104150
* gcc.dg/analyzer/pr104089.c: Add "dg-add-options float16"
and "dg-require-effective-target float16" directives.

Signed-off-by: David Malcolm 
---
 gcc/testsuite/gcc.dg/analyzer/pr104089.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/analyzer/pr104089.c 
b/gcc/testsuite/gcc.dg/analyzer/pr104089.c
index c51770411f1..3bf637ec5f6 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pr104089.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pr104089.c
@@ -1,3 +1,5 @@
+/* { dg-add-options float16 } */
+/* { dg-require-effective-target float16 } */
 /* { dg-additional-options "-frounding-math" } */
 
 volatile _Float16 true_min = 5.9604644775390625000e-8F16;
-- 
2.26.3



[committed] analyzer: fix ICE on vector casts [PR104159]

2022-01-22 Thread David Malcolm via Gcc-patches
PR analyzer/104159 describes an ICE attempting to convert a vector_cst,
which occurs when symbolically executing within a recursive call on:

  _4 = BIT_FIELD_REF ;
  _1 = VIEW_CONVERT_EXPR(_4);

where the BIT_FIELD_REF leads to a get_or_create_cast from
  VEC to VEC
which get_code_for_cast erroneously picks NOP_EXPR for the cast, leading
to a bogus input to the VIEW_CONVERT_EXPR.

This patch fixes the issue by giving up on attempts to cast symbolic
values of vector types, treating the result of such casts as unknowable.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-6817-g45b999f642a531c083c982dda79fa6ad65730a7c.

gcc/analyzer/ChangeLog:
PR analyzer/104159
* region-model-manager.cc
(region_model_manager::get_or_create_cast): Bail out if the types
are the same.  Don't attempt to handle casts involving vector
types.

gcc/testsuite/ChangeLog:
PR analyzer/104159
* gcc.dg/analyzer/torture/pr104159.c: New test.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/region-model-manager.cc   | 11 +++
 .../gcc.dg/analyzer/torture/pr104159.c | 18 ++
 2 files changed, 29 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/torture/pr104159.c

diff --git a/gcc/analyzer/region-model-manager.cc 
b/gcc/analyzer/region-model-manager.cc
index bb93526807f..e765e7f484f 100644
--- a/gcc/analyzer/region-model-manager.cc
+++ b/gcc/analyzer/region-model-manager.cc
@@ -497,6 +497,17 @@ const svalue *
 region_model_manager::get_or_create_cast (tree type, const svalue *arg)
 {
   gcc_assert (type);
+
+  /* No-op if the types are the same.  */
+  if (type == arg->get_type ())
+return arg;
+
+  /* Don't attempt to handle casts involving vector types for now.  */
+  if (TREE_CODE (type) == VECTOR_TYPE
+  || (arg->get_type ()
+ && TREE_CODE (arg->get_type ()) == VECTOR_TYPE))
+return get_or_create_unknown_svalue (type);
+
   enum tree_code op = get_code_for_cast (type, arg->get_type ());
   return get_or_create_unaryop (type, op, arg);
 }
diff --git a/gcc/testsuite/gcc.dg/analyzer/torture/pr104159.c 
b/gcc/testsuite/gcc.dg/analyzer/torture/pr104159.c
new file mode 100644
index 000..1346b4b6063
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/torture/pr104159.c
@@ -0,0 +1,18 @@
+/* { dg-additional-options "-Wno-analyzer-use-of-uninitialized-value" } */
+
+typedef int __attribute__((__vector_size__(4))) T;
+typedef unsigned __attribute__((__vector_size__(4))) U;
+typedef unsigned __attribute__((__vector_size__(16))) V;
+typedef unsigned long __attribute__((__vector_size__(16))) W;
+
+U u;
+T t;
+
+void
+foo(W w) {
+  U u = __builtin_shufflevector((V)w, u, 0);
+  t = (T){} + u + u;
+  foo((W){});
+  for (;;)
+;
+}
-- 
2.26.3



Re: [PATCH] PR fortran/104127 - [9/10/11/12 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244

2022-01-22 Thread Thomas Koenig via Gcc-patches

Hello Harald,


when simplifying TRANSFER with a MOLD argument of type character
and with SIZE=0 we lose the character length.

This happens in all gfortran versions and results in wrong code.
The purported regression is that at some point in the 9-development
this lead to a (previously possibly latent) ICE.

The attached patch sets up the character length in the typespec and
fixes the ICE.  There is another generic hidden/latent problem with
array constructors of size 0 passed to procedures (see e.g. pr86277)
which will remain and is beyond the scope of this fix.

Regtested on x86_64-pc-linux-gnu.  I also fixed a minor logic bug
in testcase transfer_simplify_11.f90.

OK for mainline?  Backports to branches?


OK for both.

Thanks for the patch!

Regards

Thomas


Re: [PATCH] Disable -fsplit-stack support on non-glibc targets

2022-01-22 Thread Jakub Jelinek via Gcc-patches
On Sat, Jan 22, 2022 at 10:32:21AM +0100, Martin Liška wrote:
> I've just noticed the patch broke a few cross compilers:
> 
> s390x-ibm-tpf:
> 
> /home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/s390/s390-common.cc:
>  In function ‘bool s390_supports_split_stack(bool, gcc_options*)’:
> /home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/s390/s390-common.cc:126:13:
>  error: ‘struct gcc_options’ has no member named ‘x_linux_libc’
>   126 |   if (opts->x_linux_libc == LIBC_GLIBC)
>   | ^~~~
> 
> i686-kopensolaris-gnu, i686-symbolics-gnu
> 
> /home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/i386/i386-common.cc:
>  In function ‘bool ix86_supports_split_stack(bool, gcc_options*)’:
> /home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/i386/i386-common.cc:1721:13:
>  error: ‘struct gcc_options’ has no member named ‘x_linux_libc’
>  1721 |   if (opts->x_linux_libc != LIBC_GLIBC)
>   | ^~~~
> make[1]: *** [Makefile:2418: i386-common.o] Error 1
> 
> Can you please take a look? Btw. do you have a bugzilla account?

Actually, I suspect we either need something like following patch,
or need to change gcc/config/{linux,rs6000/linux{,64},alpha/linux}.h
so that next to those OPTION_GLIBC etc. macros it also defines versions
of those macros with opts argument.

Untested and I don't have cycles to test this right now.

2022-01-22  Jakub Jelinek  

* common/config/s390/s390-common.cc (s390_supports_split_stack): Re-add
ATTRIBUTE_UNUSED to opts parameter.  If OPTION_GLIBC is defined and
SINGLE_LIBC is defined too, use OPTION_GLIBC as condition, otherwise
if OPTION_GLIBC is defined, use opts->x_linux_libc == LIBC_GLIBC as
condition, otherwise assume if (false).
* common/config/i386/i386-common.cc (ix86_supports_split_stack): If
OPTION_GLIBC is defined and SINGLE_LIBC is defined too, use
!OPTION_GLIBC as condition, otherwise if OPTION_GLIBC is defined,
use opts->x_linux_libc != LIBC_GLIBC as condition, otherwise assume
if (true).

--- gcc/common/config/s390/s390-common.cc.jj2022-01-21 22:43:22.847719836 
+0100
+++ gcc/common/config/s390/s390-common.cc   2022-01-22 13:05:31.205118265 
+0100
@@ -121,10 +121,16 @@ s390_handle_option (struct gcc_options *
 
 static bool
 s390_supports_split_stack (bool report,
-  struct gcc_options *opts)
+  struct gcc_options *opts ATTRIBUTE_UNUSED)
 {
+#ifdef OPTION_GLIBC
+#ifdef SINGLE_LIBC
+  if (OPTION_GLIBC)
+#else
   if (opts->x_linux_libc == LIBC_GLIBC)
+#endif
 return true;
+#endif
 
   if (report)
 error ("%<-fsplit-stack%> currently only supported on GNU/Linux");
--- gcc/common/config/i386/i386-common.cc.jj2022-01-22 12:02:24.572563780 
+0100
+++ gcc/common/config/i386/i386-common.cc   2022-01-22 13:07:12.223700957 
+0100
@@ -1717,9 +1717,13 @@ static bool
 ix86_supports_split_stack (bool report,
   struct gcc_options *opts ATTRIBUTE_UNUSED)
 {
-#ifdef TARGET_THREAD_SPLIT_STACK_OFFSET
+#if defined(TARGET_THREAD_SPLIT_STACK_OFFSET) && defined(OPTION_GLIBC)
+#ifdef SINGLE_LIBC
+  if (!OPTION_GLIBC)
+#else
   if (opts->x_linux_libc != LIBC_GLIBC)
 #endif
+#endif
 {
   if (report)
error ("%<-fsplit-stack%> currently only supported on GNU/Linux");

> 
> Cheers,
> Martin

Jakub



[PATCH] bootstrap: Fix bootstrap with --disable-plugin [PR104176]

2022-01-22 Thread Jakub Jelinek via Gcc-patches
Hi!

With --disable-plugin, bootstrap fails on x86_64-linux or probably
all other targets with:
../../gcc/opts-global.cc: In function ‘void handle_common_deferred_options()’:
../../gcc/opts-global.cc:420:62: error: unquoted option name ‘--enable-plugin’ 
in format [-Werror=format-diag]
  420 |   error ("plugin support is disabled; configure with 
--enable-plugin");
  |  
^~~
../../gcc/opts-global.cc:428:62: error: unquoted option name ‘--enable-plugin’ 
in format [-Werror=format-diag]
  428 |   error ("plugin support is disabled; configure with 
--enable-plugin");
  |  
^~~

The following patch fixes that, bootstrapped on x86_64-linux with
--disable-plugin --enable-languages=c,c++
without the patch (where it failed as above) and with it (where it
succeeded), ok for trunk?

2022-01-22  Jakub Jelinek  

PR other/104176
* opts-global.cc (handle_common_deferred_options): Quote
--enable-plugin in diagnostics to avoid -Werror=format-diag.

--- gcc/opts-global.cc.jj   2022-01-18 11:58:59.741979785 +0100
+++ gcc/opts-global.cc  2022-01-22 02:18:39.116047945 +0100
@@ -417,7 +417,8 @@ handle_common_deferred_options (void)
 #ifdef ENABLE_PLUGIN
  add_new_plugin (opt->arg);
 #else
- error ("plugin support is disabled; configure with --enable-plugin");
+ error ("plugin support is disabled; configure with "
+"%<--enable-plugin%>");
 #endif
  break;
 
@@ -425,7 +426,8 @@ handle_common_deferred_options (void)
 #ifdef ENABLE_PLUGIN
  parse_plugin_arg_opt (opt->arg);
 #else
- error ("plugin support is disabled; configure with --enable-plugin");
+ error ("plugin support is disabled; configure with "
+"%<--enable-plugin%>");
 #endif
  break;
 


Jakub



Re: Re: [PATCH v5 02/12] LoongArch Port: gcc build

2022-01-22 Thread 程璐璐



> -原始邮件-
> 发件人: "Jakub Jelinek" 
> 发送时间: 2022-01-22 17:31:40 (星期六)
> 收件人: "Xi Ruoyao" 
> 抄送: "程璐璐" , "Chenghua Xu" , 
gcc-patches@gcc.gnu.org, jos...@codesourcery.com
> 主题: Re: [PATCH v5 02/12] LoongArch Port: gcc build
> 
> On Sat, Jan 22, 2022 at 05:05:00PM +0800, Xi Ruoyao wrote:
> > On Sat, 2022-01-22 at 16:56 +0800, 程璐璐 wrote:
> > 
> > > Under the MIPS architecture, *.opt files are also generated in
> > > $(srcdir).
> > 
> > Well, but then you should put the commands for generating those files
> > into contrib/gcc_update instead of Makefile.in, just like MIPS.
> 
> The MIPS does it wrong too.  If the generated file is checked into the
> tree as in the mips case, such a make rule can be there, but it
> should be wrapped with
> ifeq($(ENABLE_MAINTAINER_RULES),true)
> ...
> endif
> or so.
> The point is, when not --enable-maintainer-mode, the gcc tree can be stored
> on read-only filesystem.
> When adding new CPUs, one just uses --enable-maintainer-mode and regenates
> the generated but committed files and commits them together with the
> changes.
> There are many other examples of such generated files, configure,
> Makefile.in from Makefile.am, etc.
> 
>Jakub

Ok,thanks! We will modify as soon as possible!

--
程璐璐

芯片研发部 

-
龙芯中科技术有限公司
Loongson Technology Corporation Limited
北京市海淀区北清路中关村环保科技示范园 龙芯产业园 2号楼
Loongson Industrial Park, building 2 , Zhongguancun Environmental 
protection park, Haidian District, Beijing, China
邮编: 100095
电话(Tel):  +86 (10) 62546668-5049
邮箱(Email):  chengl...@loongson.cn
--


北京市海淀区中关村环保科技示范园龙芯产业园2号楼100095
电话: +86 (10) 62546668
传真: +86 (10) 62600826
www.loongson.cn


本邮件及其附件含有龙芯中科的商业秘密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制或散发)本邮件及其附件中的信息。如果您错收本邮件,请您立即电话或邮件通知发件人并删除本邮件。
 
This email and its attachments contain confidential information from Loongson 
Technology , which is intended only for the person or entity whose address is 
listed above. Any use of the information contained herein in any way 
(including, but not limited to, total or partial disclosure, reproduction or 
dissemination) by persons other than the intended recipient(s) is prohibited. 
If you receive this email in error, please notify the sender by phone or email 
immediately and delete it. 

Re: [PATCH] Disable -fsplit-stack support on non-glibc targets

2022-01-22 Thread Jakub Jelinek via Gcc-patches
On Sat, Jan 22, 2022 at 10:32:21AM +0100, Martin Liška wrote:
> Hello.
> 
> I've just noticed the patch broke a few cross compilers:
> 
> s390x-ibm-tpf:
> 
> /home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/s390/s390-common.cc:
>  In function ‘bool s390_supports_split_stack(bool, gcc_options*)’:
> /home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/s390/s390-common.cc:126:13:
>  error: ‘struct gcc_options’ has no member named ‘x_linux_libc’
>   126 |   if (opts->x_linux_libc == LIBC_GLIBC)
>   | ^~~~
> 
> i686-kopensolaris-gnu, i686-symbolics-gnu
> 
> /home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/i386/i386-common.cc:
>  In function ‘bool ix86_supports_split_stack(bool, gcc_options*)’:
> /home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/i386/i386-common.cc:1721:13:
>  error: ‘struct gcc_options’ has no member named ‘x_linux_libc’
>  1721 |   if (opts->x_linux_libc != LIBC_GLIBC)
>   | ^~~~
> make[1]: *** [Makefile:2418: i386-common.o] Error 1
> 
> Can you please take a look? Btw. do you have a bugzilla account?

I bet instead of opts->x_linux_libc != LIBC_GLIBC it needs to use
#ifdef OPTION_GLIBC
  if (!OPTION_GLIBC)
#endif
or so.  I think the first committed patch actually used that
but used it in #if directive, which is wrong because it is something
that needs to be evaluated at runtime.

Jakub



Re: [PATCH] Disable -fsplit-stack support on non-glibc targets

2022-01-22 Thread Martin Liška

Hello.

I've just noticed the patch broke a few cross compilers:

s390x-ibm-tpf:

/home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/s390/s390-common.cc:
 In function ‘bool s390_supports_split_stack(bool, gcc_options*)’:
/home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/s390/s390-common.cc:126:13:
 error: ‘struct gcc_options’ has no member named ‘x_linux_libc’
  126 |   if (opts->x_linux_libc == LIBC_GLIBC)
  | ^~~~

i686-kopensolaris-gnu, i686-symbolics-gnu

/home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/i386/i386-common.cc:
 In function ‘bool ix86_supports_split_stack(bool, gcc_options*)’:
/home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/i386/i386-common.cc:1721:13:
 error: ‘struct gcc_options’ has no member named ‘x_linux_libc’
 1721 |   if (opts->x_linux_libc != LIBC_GLIBC)
  | ^~~~
make[1]: *** [Makefile:2418: i386-common.o] Error 1

Can you please take a look? Btw. do you have a bugzilla account?

Cheers,
Martin


Re: [PATCH v5 02/12] LoongArch Port: gcc build

2022-01-22 Thread Jakub Jelinek via Gcc-patches
On Sat, Jan 22, 2022 at 05:05:00PM +0800, Xi Ruoyao wrote:
> On Sat, 2022-01-22 at 16:56 +0800, 程璐璐 wrote:
> 
> > Under the MIPS architecture, *.opt files are also generated in
> > $(srcdir).
> 
> Well, but then you should put the commands for generating those files
> into contrib/gcc_update instead of Makefile.in, just like MIPS.

The MIPS does it wrong too.  If the generated file is checked into the
tree as in the mips case, such a make rule can be there, but it
should be wrapped with
ifeq($(ENABLE_MAINTAINER_RULES),true)
...
endif
or so.
The point is, when not --enable-maintainer-mode, the gcc tree can be stored
on read-only filesystem.
When adding new CPUs, one just uses --enable-maintainer-mode and regenates
the generated but committed files and commits them together with the
changes.
There are many other examples of such generated files, configure,
Makefile.in from Makefile.am, etc.

Jakub



Re: [PATCH v5 02/12] LoongArch Port: gcc build

2022-01-22 Thread Andreas Schwab
On Jan 22 2022, Xi Ruoyao via Gcc-patches wrote:

> Well, but then you should put the commands for generating those files
> into contrib/gcc_update instead of Makefile.in, just like MIPS.

contrib/gcc_update doesn't regenerate any files, it only updates
timestamps.

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


Re: [PATCH v5 02/12] LoongArch Port: gcc build

2022-01-22 Thread 程璐璐



在 2022/1/22 下午5:05, Xi Ruoyao 写道:

On Sat, 2022-01-22 at 16:56 +0800, 程璐璐 wrote:


Under the MIPS architecture, *.opt files are also generated in
$(srcdir).

Well, but then you should put the commands for generating those files
into contrib/gcc_update instead of Makefile.in, just like MIPS.

Sorry, I will move this commands to contrib/gcc_update.



Re: [PATCH v5 02/12] LoongArch Port: gcc build

2022-01-22 Thread Xi Ruoyao via Gcc-patches
On Sat, 2022-01-22 at 16:56 +0800, 程璐璐 wrote:

> Under the MIPS architecture, *.opt files are also generated in
> $(srcdir).

Well, but then you should put the commands for generating those files
into contrib/gcc_update instead of Makefile.in, just like MIPS.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: [PATCH v5 02/12] LoongArch Port: gcc build

2022-01-22 Thread 程璐璐



在 2022/1/22 下午4:46, Xi Ruoyao 写道:

On Sat, 2022-01-22 at 09:41 +0100, Jakub Jelinek wrote:

On Sat, Jan 22, 2022 at 04:33:08PM +0800, Xi Ruoyao via Gcc-patches
wrote:

On Sat, 2022-01-22 at 15:55 +0800, Chenghua Xu wrote:

+$(srcdir)/config/loongarch/loongarch.opt: \
+   $(srcdir)/config/loongarch/genopts/genstr.sh \
+   $(srcdir)/config/loongarch/genopts/loongarch.opt.in
+   $(SHELL) $< opt > $@
+
+$(LA_STR_H): \
+   $(srcdir)/config/loongarch/genopts/genstr.sh \
+   $(srcdir)/config/loongarch/genopts/loongarch-strings
+   $(SHELL) $< header > $@

I'm not sure about these two rules: is it allowed to modify files in
$(srcdir) running "make"?

No (except in --enable-maintainer-mode), but the above certainly
looks wrong, both should be in the objdir instead.

Does the building system support a .opt file in $(objdir)?  And how to
handle the translations (.po) for loongarch.opt if it's in $(objdir)?


Under the MIPS architecture, *.opt files are also generated in $(srcdir).



Re: [PATCH v5 02/12] LoongArch Port: gcc build

2022-01-22 Thread Xi Ruoyao via Gcc-patches
On Sat, 2022-01-22 at 09:41 +0100, Jakub Jelinek wrote:
> On Sat, Jan 22, 2022 at 04:33:08PM +0800, Xi Ruoyao via Gcc-patches
> wrote:
> > On Sat, 2022-01-22 at 15:55 +0800, Chenghua Xu wrote:
> > > +$(srcdir)/config/loongarch/loongarch.opt: \
> > > +   $(srcdir)/config/loongarch/genopts/genstr.sh \
> > > +   $(srcdir)/config/loongarch/genopts/loongarch.opt.in
> > > +   $(SHELL) $< opt > $@
> > > +
> > > +$(LA_STR_H): \
> > > +   $(srcdir)/config/loongarch/genopts/genstr.sh \
> > > +   $(srcdir)/config/loongarch/genopts/loongarch-strings
> > > +   $(SHELL) $< header > $@
> > 
> > I'm not sure about these two rules: is it allowed to modify files in
> > $(srcdir) running "make"?
> 
> No (except in --enable-maintainer-mode), but the above certainly
> looks wrong, both should be in the objdir instead.

Does the building system support a .opt file in $(objdir)?  And how to
handle the translations (.po) for loongarch.opt if it's in $(objdir)?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: [PATCH v5 02/12] LoongArch Port: gcc build

2022-01-22 Thread Xi Ruoyao via Gcc-patches
On Sat, 2022-01-22 at 15:55 +0800, Chenghua Xu wrote:
> +mstrict-align
> +Target Var(TARGET_STRICT_ALIGN) Init(0)
> +Do not generate unaligned memory accesses.

Section 2.1.8 of LoongArch spec says "load/store instruction *may* be
implemented to allow unaligned memory access".  As it's not a "must",
should we really enable this by default?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: [PATCH v5 02/12] LoongArch Port: gcc build

2022-01-22 Thread Jakub Jelinek via Gcc-patches
On Sat, Jan 22, 2022 at 04:33:08PM +0800, Xi Ruoyao via Gcc-patches wrote:
> On Sat, 2022-01-22 at 15:55 +0800, Chenghua Xu wrote:
> > +$(srcdir)/config/loongarch/loongarch.opt: \
> > +   $(srcdir)/config/loongarch/genopts/genstr.sh \
> > +   $(srcdir)/config/loongarch/genopts/loongarch.opt.in
> > +   $(SHELL) $< opt > $@
> > +
> > +$(LA_STR_H): \
> > +   $(srcdir)/config/loongarch/genopts/genstr.sh \
> > +   $(srcdir)/config/loongarch/genopts/loongarch-strings
> > +   $(SHELL) $< header > $@
> 
> I'm not sure about these two rules: is it allowed to modify files in
> $(srcdir) running "make"?

No (except in --enable-maintainer-mode), but the above certainly
looks wrong, both should be in the objdir instead.

Jakub



Re: [PATCH v5 02/12] LoongArch Port: gcc build

2022-01-22 Thread Xi Ruoyao via Gcc-patches
On Sat, 2022-01-22 at 15:55 +0800, Chenghua Xu wrote:
> +   Copyright (C) 2021 Free Software Foundation, Inc.

All of those should be 2021 - 2022 (or just 2022?) now.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: [PATCH v5 02/12] LoongArch Port: gcc build

2022-01-22 Thread Xi Ruoyao via Gcc-patches
On Sat, 2022-01-22 at 15:55 +0800, Chenghua Xu wrote:
> +$(srcdir)/config/loongarch/loongarch.opt: \
> +   $(srcdir)/config/loongarch/genopts/genstr.sh \
> +   $(srcdir)/config/loongarch/genopts/loongarch.opt.in
> +   $(SHELL) $< opt > $@
> +
> +$(LA_STR_H): \
> +   $(srcdir)/config/loongarch/genopts/genstr.sh \
> +   $(srcdir)/config/loongarch/genopts/loongarch-strings
> +   $(SHELL) $< header > $@

I'm not sure about these two rules: is it allowed to modify files in
$(srcdir) running "make"?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: [PATCH] fortran: Extend -fconvert= option for ppc64le r16_ieee and r16_ibm

2022-01-22 Thread Thomas Koenig via Gcc-patches



Hi Jakub,


This patch on top of the previously posted option handling changes patch
allows specifying -fconvert=swap,r16_ieee etc. (but will error on it
when not on powerpc64le because in the library such swapping is only
implemented for HAVE_REAL_17).

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


OK!

This is a much cleaner solution than what I had in mind, but didn't
start work on, which was to make the option into a string and parse
by hand.

Best regards

Thomas


[PATCH v5 12/12] LoongArch Port: Add doc.

2022-01-22 Thread Chenghua Xu
From: chenglulu 

* contrib/config-list.mk: Add LoongArch triplet.
* gcc/doc/install.texi: Add LoongArch options section.
* gcc/doc/invoke.texi: Add LoongArch options section.
* gcc/doc/md.texi: Add LoongArch options section.
---
 contrib/config-list.mk |   5 +-
 gcc/doc/install.texi   |  47 +-
 gcc/doc/invoke.texi| 201 +
 gcc/doc/md.texi|  55 +++
 4 files changed, 302 insertions(+), 6 deletions(-)

diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index 3e1d1321861..ba6f12e4693 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -57,7 +57,10 @@ LIST = aarch64-elf aarch64-linux-gnu aarch64-rtems \
   i686-wrs-vxworksae \
   i686-cygwinOPT-enable-threads=yes i686-mingw32crt ia64-elf \
   ia64-freebsd6 ia64-linux ia64-hpux ia64-hp-vms iq2000-elf lm32-elf \
-  lm32-rtems lm32-uclinux m32c-rtems m32c-elf m32r-elf m32rle-elf \
+  lm32-rtems lm32-uclinux \
+  loongarch64-linux-gnu loongarch64-linux-gnuf64 \
+  loongarch64-linux-gnuf32 loongarch64-linux-gnusf \
+  m32c-rtems m32c-elf m32r-elf m32rle-elf \
   m68k-elf m68k-netbsdelf \
   m68k-uclinux m68k-linux m68k-rtems \
   mcore-elf microblaze-linux microblaze-elf \
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 96b4dfc871a..337f752192f 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -752,9 +752,9 @@ Here are the possible CPU types:
 @quotation
 aarch64, aarch64_be, alpha, alpha64, amdgcn, arc, arceb, arm, armeb, avr, bfin,
 bpf, cr16, cris, csky, epiphany, fido, fr30, frv, ft32, h8300, hppa, hppa2.0,
-hppa64, i486, i686, ia64, iq2000, lm32, m32c, m32r, m32rle, m68k, mcore,
-microblaze, microblazeel, mips, mips64, mips64el, mips64octeon, mips64orion,
-mips64vr, mipsel, mipsisa32, mipsisa32r2, mipsisa64, mipsisa64r2,
+hppa64, i486, i686, ia64, iq2000, lm32, loongarch64, m32c, m32r, m32rle, m68k,
+mcore, microblaze, microblazeel, mips, mips64, mips64el, mips64octeon,
+mips64orion, mips64vr, mipsel, mipsisa32, mipsisa32r2, mipsisa64, mipsisa64r2,
 mipsisa64r2el, mipsisa64sb1, mipsisa64sr71k, mipstx39, mmix, mn10300, moxie,
 msp430, nds32be, nds32le, nios2, nvptx, or1k, pdp11, powerpc, powerpc64,
 powerpc64le, powerpcle, pru, riscv32, riscv32be, riscv64, riscv64be, rl78, rx,
@@ -1171,8 +1171,9 @@ sysv, aix.
 @itemx --without-multilib-list
 Specify what multilibs to build.  @var{list} is a comma separated list of
 values, possibly consisting of a single value.  Currently only implemented
-for aarch64*-*-*, arm*-*-*, riscv*-*-*, sh*-*-* and x86-64-*-linux*.  The
-accepted values and meaning for each target is given below.
+for aarch64*-*-*, arm*-*-*, loongarch64-*-*, riscv*-*-*, sh*-*-* and
+x86-64-*-linux*.  The accepted values and meaning for each target is given
+below.
 
 @table @code
 @item aarch64*-*-*
@@ -1259,6 +1260,14 @@ profile.  The union of these options is considered when 
specifying both
 @code{-mfloat-abi=hard}
 @end multitable
 
+@item loongarch*-*-*
+@var{list} is a comma-separated list of the following ABI identifiers:
+@code{lp64d[/base]} @code{lp64f[/base]} @code{lp64d[/base]}, where the
+@code{/base} suffix may be omitted, to enable their respective run-time
+libraries.  If @var{list} is empty, @code{default}
+or @option{--with-multilib-list} is not specified, then the default ABI
+as specified by @option{--with-abi} or implied by @option{--target} is 
selected.
+
 @item riscv*-*-*
 @var{list} is a single ABI name.  The target architecture must be either
 @code{rv32gc} or @code{rv64gc}.  This will build a single multilib for the
@@ -4430,6 +4439,34 @@ This configuration is intended for embedded systems.
 Lattice Mico32 processor.
 This configuration is intended for embedded systems running uClinux.
 
+@html
+
+@end html
+@anchor{loongarch}
+@heading LoongArch
+LoongArch processor.
+The following LoongArch targets are available:
+@table @code
+@item loongarch64-linux-gnu*
+LoongArch processor running GNU/Linux.  This target triplet may be coupled
+with a small set of possible suffixes to identify their default ABI type:
+@table @code
+@item f64
+Uses @code{lp64d/base} ABI by default.
+@item f32
+Uses @code{lp64f/base} ABI by default.
+@item sf
+Uses @code{lp64s/base} ABI by default.
+@end table
+
+@item loongarch64-linux-gnu
+Same as @code{loongarch64-linux-gnuf64}, but may be used with
+@option{--with-abi=*} to configure the default ABI type.
+@end table
+
+More information about LoongArch can be found at
+@uref{https://github.com/loongson/LoongArch-Documentation}.
+
 @html
 
 @end html
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 309f5e38a85..579e141e511 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -995,6 +995,16 @@ Objective-C and Objective-C++ Dialects}.
 @gccoptlist{-mbarrel-shift-enabled  -mdivide-enabled  -mmultiply-enabled @gol
 -msign-extend-enabled  -muser-enabled}
 
+@emph{LoongArch Options}
+@gccoptlist{-march=@var{cpu-type}  -mtune=@var{cpu-typ

[PATCH v5 08/12] LoongArch Port: libgcc

2022-01-22 Thread Chenghua Xu
From: chenglulu 

libgcc/

* config/loongarch/crtfastmath.c: New file.
* config/loongarch/crti.S: Like wise.
* config/loongarch/crtn.S: Like wise.
* config/loongarch/lib2funcs.c: Like wise.
* config/loongarch/linux-unwind.h: Like wise.
* config/loongarch/sfp-machine.h: Like wise.
* config/loongarch/t-crtstuff: Like wise.
* config/loongarch/t-elf: Like wise.
* config/loongarch/t-loongarch: Like wise.
* config/loongarch/t-loongarch64: Like wise.
* config/loongarch/t-softfp-tf: Like wise.
* config.host: Add LoongArch tuples.
* configure.ac: Add LoongArch support.
---
 libgcc/config.host |  28 -
 libgcc/config/loongarch/crtfastmath.c  |  52 +
 libgcc/config/loongarch/crti.S |  43 +++
 libgcc/config/loongarch/crtn.S |  39 +++
 libgcc/config/loongarch/lib2funcs.c|   0
 libgcc/config/loongarch/linux-unwind.h |  80 +
 libgcc/config/loongarch/sfp-machine.h  | 152 +
 libgcc/config/loongarch/t-crtstuff |   5 +
 libgcc/config/loongarch/t-elf  |   3 +
 libgcc/config/loongarch/t-loongarch|   9 ++
 libgcc/config/loongarch/t-loongarch64  |   1 +
 libgcc/config/loongarch/t-softfp-tf|   3 +
 libgcc/configure.ac|   2 +-
 13 files changed, 415 insertions(+), 2 deletions(-)
 create mode 100644 libgcc/config/loongarch/crtfastmath.c
 create mode 100644 libgcc/config/loongarch/crti.S
 create mode 100644 libgcc/config/loongarch/crtn.S
 create mode 100644 libgcc/config/loongarch/lib2funcs.c
 create mode 100644 libgcc/config/loongarch/linux-unwind.h
 create mode 100644 libgcc/config/loongarch/sfp-machine.h
 create mode 100644 libgcc/config/loongarch/t-crtstuff
 create mode 100644 libgcc/config/loongarch/t-elf
 create mode 100644 libgcc/config/loongarch/t-loongarch
 create mode 100644 libgcc/config/loongarch/t-loongarch64
 create mode 100644 libgcc/config/loongarch/t-softfp-tf

diff --git a/libgcc/config.host b/libgcc/config.host
index 094fd3ad254..8c56fcae5d2 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -138,6 +138,22 @@ hppa*-*-*)
 lm32*-*-*)
cpu_type=lm32
;;
+loongarch*-*-*)
+   cpu_type=loongarch
+   tmake_file="loongarch/t-loongarch"
+   if test "${libgcc_cv_loongarch_hard_float}" = yes; then
+   tmake_file="${tmake_file} t-hardfp-sfdf t-hardfp"
+   else
+   tmake_file="${tmake_file} t-softfp-sfdf"
+   fi
+   if test "${ac_cv_sizeof_long_double}" = 16; then
+   tmake_file="${tmake_file} loongarch/t-softfp-tf"
+   fi
+   if test "${host_address}" = 64; then
+   tmake_file="${tmake_file} loongarch/t-loongarch64"
+   fi
+   tmake_file="${tmake_file} t-softfp"
+   ;;
 m32r*-*-*)
 cpu_type=m32r
 ;;
@@ -925,7 +941,17 @@ lm32-*-rtems*)
 lm32-*-uclinux*)
 extra_parts="$extra_parts crtbegin.o crtendS.o crtbeginT.o"
 tmake_file="lm32/t-lm32 lm32/t-uclinux t-libgcc-pic t-softfp-sfdf 
t-softfp"
-   ;;  
+   ;;
+loongarch*-*-linux*)
+   extra_parts="$extra_parts crtfastmath.o"
+   tmake_file="${tmake_file} t-crtfm loongarch/t-crtstuff"
+   case ${host} in
+ *)
+   tmake_file="${tmake_file} t-slibgcc-libgcc"
+   ;;
+   esac
+   md_unwind_header=loongarch/linux-unwind.h
+   ;;
 m32r-*-elf*)
tmake_file="$tmake_file m32r/t-m32r t-fdpbit"
extra_parts="$extra_parts crtinit.o crtfini.o"
diff --git a/libgcc/config/loongarch/crtfastmath.c 
b/libgcc/config/loongarch/crtfastmath.c
new file mode 100644
index 000..3523d531e2b
--- /dev/null
+++ b/libgcc/config/loongarch/crtfastmath.c
@@ -0,0 +1,52 @@
+/* Copyright (C) 2021 Free Software Foundation, Inc.
+   Contributed by Loongson Ltd.
+   Based on MIPS target for GNU compiler.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+License for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License
+and a copy of the GCC Runtime Library Exception along with this
+program; see the files COPYING3 and COPYING.RUNTIME respectively.
+If not, see .  */
+
+#ifdef __loongarch_hard_float
+
+/* Rounding control.  */
+#define _FPU_RC_NEAREST 0x000 /* RECOMMENDED.  */
+#define _FPU_RC_ZERO0x100
+#define _FPU_

[PATCH v5 11/12] LoongArch Port: gcc/testsuite

2022-01-22 Thread Chenghua Xu
From: chenglulu 

gcc/testsuite/

* g++.dg/cpp0x/constexpr-rom.C: Add build options for LoongArch.
* g++.old-deja/g++.abi/ptrmem.C: Add LoongArch support.
* g++.old-deja/g++.pt/ptrmem6.C: xfail for LoongArch.
* gcc.dg/20020312-2.c: Add LoongArch support.
* gcc.dg/loop-8.c: Skip on LoongArch.
* gcc.dg/torture/stackalign/builtin-apply-2.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-3.c: Likewise.
* go.test/go-test.exp: Define the LoongArch target.
* lib/target-supports.exp: Like wise.
* gcc.target/loongarch/loongarch.exp: New file.
* gcc.target/loongarch/tst-asm-const.c: Like wise.
---
 gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C|  2 +-
 gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C   |  2 +-
 gcc/testsuite/g++.old-deja/g++.pt/ptrmem6.C   |  2 +-
 gcc/testsuite/gcc.dg/20020312-2.c |  2 +
 gcc/testsuite/gcc.dg/loop-8.c |  2 +-
 .../torture/stackalign/builtin-apply-2.c  |  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-3.c |  2 +-
 .../gcc.target/loongarch/loongarch.exp| 40 +++
 .../gcc.target/loongarch/tst-asm-const.c  | 16 
 gcc/testsuite/go.test/go-test.exp |  3 ++
 gcc/testsuite/lib/target-supports.exp | 14 +++
 11 files changed, 81 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/loongarch.exp
 create mode 100644 gcc/testsuite/gcc.target/loongarch/tst-asm-const.c

diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C
index 2e0ef685f36..424979a604b 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C
@@ -1,6 +1,6 @@
 // PR c++/49673: check that test_data goes into .rodata
 // { dg-do compile { target c++11 } }
-// { dg-additional-options -G0 { target { { alpha*-*-* frv*-*-* ia64-*-* 
lm32*-*-* m32r*-*-* microblaze*-*-* mips*-*-* nios2-*-* powerpc*-*-* 
rs6000*-*-* } && { ! { *-*-darwin* *-*-aix* alpha*-*-*vms* } } } } }
+// { dg-additional-options -G0 { target { { alpha*-*-* frv*-*-* ia64-*-* 
lm32*-*-* m32r*-*-* microblaze*-*-* mips*-*-* loongarch*-*-* nios2-*-* 
powerpc*-*-* rs6000*-*-* } && { ! { *-*-darwin* *-*-aix* alpha*-*-*vms* } } } } 
}
 // { dg-final { scan-assembler "\\.rdata" { target mips*-*-* } } }
 // { dg-final { scan-assembler "rodata" { target { { *-*-linux-gnu *-*-gnu* 
*-*-elf } && { ! { mips*-*-* riscv*-*-* } } } } } }
 
diff --git a/gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C 
b/gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C
index bda7960d8a2..f69000e9081 100644
--- a/gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C
+++ b/gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C
@@ -7,7 +7,7 @@
function.  However, some platforms use all bits to encode a
function pointer.  Such platforms use the lowest bit of the delta,
that is shifted left by one bit.  */
-#if defined __MN10300__ || defined __SH5__ || defined __arm__ || defined 
__thumb__ || defined __mips__ || defined __aarch64__ || defined __PRU__
+#if defined __MN10300__ || defined __SH5__ || defined __arm__ || defined 
__thumb__ || defined __mips__ || defined __aarch64__ || defined __PRU__ || 
defined __loongarch__
 #define ADJUST_PTRFN(func, virt) ((void (*)())(func))
 #define ADJUST_DELTA(delta, virt) (((delta) << 1) + !!(virt))
 #else
diff --git a/gcc/testsuite/g++.old-deja/g++.pt/ptrmem6.C 
b/gcc/testsuite/g++.old-deja/g++.pt/ptrmem6.C
index 9f4bbe43f89..8f8f7017ab7 100644
--- a/gcc/testsuite/g++.old-deja/g++.pt/ptrmem6.C
+++ b/gcc/testsuite/g++.old-deja/g++.pt/ptrmem6.C
@@ -25,7 +25,7 @@ int main() {
   h<&B::j>(); // { dg-error "" } 
   g<(void (A::*)()) &A::f>(); // { dg-error "" "" { xfail c++11 } }
   h<(int A::*) &A::i>(); // { dg-error "" "" { xfail c++11 } }
-  g<(void (A::*)()) &B::f>(); // { dg-error "" "" { xfail { c++11 && { 
aarch64*-*-* arm*-*-* mips*-*-* } } } }
+  g<(void (A::*)()) &B::f>(); // { dg-error "" "" { xfail { c++11 && { 
aarch64*-*-* arm*-*-* mips*-*-* loongarch*-*-* } } } }
   h<(int A::*) &B::j>(); // { dg-error "" } 
   g<(void (A::*)()) 0>(); // { dg-error "" "" { target { ! c++11 } } }
   h<(int A::*) 0>(); // { dg-error "" "" { target { ! c++11 } } }
diff --git a/gcc/testsuite/gcc.dg/20020312-2.c 
b/gcc/testsuite/gcc.dg/20020312-2.c
index 52c33d09b90..92bc150df0f 100644
--- a/gcc/testsuite/gcc.dg/20020312-2.c
+++ b/gcc/testsuite/gcc.dg/20020312-2.c
@@ -37,6 +37,8 @@ extern void abort (void);
 /* PIC register is r1, but is used even without -fpic.  */
 #elif defined(__lm32__)
 /* No pic register.  */
+#elif defined(__loongarch__)
+/* No pic register.  */
 #elif defined(__M32R__)
 /* No pic register.  */
 #elif defined(__m68k__)
diff --git a/gcc/testsuite/gcc.dg/loop-8.c b/gcc/testsuite/gcc.dg/loop-8.c
index a685fc25056..8e5f2087831 100644
--- a/gcc/testsuite/gcc.dg/loop-8.c
+++ b/gcc/testsuite/gcc.dg/loop-8.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O1 -fdump-rtl-loop2_invariant" 

[PATCH v5 06/12] LoongArch Port: Builtin functions.

2022-01-22 Thread Chenghua Xu
From: chenglulu 

gcc/

* config/loongarch/larchintrin.h: New file.
* config/loongarch/loongarch-builtins.cc: New file.
---
 gcc/config/loongarch/larchintrin.h | 413 +
 gcc/config/loongarch/loongarch-builtins.cc | 511 +
 2 files changed, 924 insertions(+)
 create mode 100644 gcc/config/loongarch/larchintrin.h
 create mode 100644 gcc/config/loongarch/loongarch-builtins.cc

diff --git a/gcc/config/loongarch/larchintrin.h 
b/gcc/config/loongarch/larchintrin.h
new file mode 100644
index 000..fcf5043841d
--- /dev/null
+++ b/gcc/config/loongarch/larchintrin.h
@@ -0,0 +1,413 @@
+/* Intrinsics for LoongArch BASE operations.
+   Copyright (C) 2021 Free Software Foundation, Inc.
+   Contributed by Loongson Ltd.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published
+by the Free Software Foundation; either version 3, or (at your
+option) any later version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+License for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+#ifndef _GCC_LOONGARCH_BASE_INTRIN_H
+#define _GCC_LOONGARCH_BASE_INTRIN_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+typedef struct drdtime
+{
+  unsigned long dvalue;
+  unsigned long dtimeid;
+} __drdtime_t;
+
+typedef struct rdtime
+{
+  unsigned int value;
+  unsigned int timeid;
+} __rdtime_t;
+
+#ifdef __loongarch64
+extern __inline __drdtime_t
+__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
+__builtin_loongarch_rdtime_d (void)
+{
+  __drdtime_t drdtime;
+  __asm__ volatile (
+"rdtime.d\t%[val],%[tid]\n\t"
+: [val]"=&r"(drdtime.dvalue),[tid]"=&r"(drdtime.dtimeid)
+:);
+  return drdtime;
+}
+#define __rdtime_d __builtin_loongarch_rdtime_d
+#endif
+
+extern __inline __rdtime_t
+__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
+__builtin_loongarch_rdtimeh_w (void)
+{
+  __rdtime_t rdtime;
+  __asm__ volatile (
+"rdtimeh.w\t%[val],%[tid]\n\t"
+: [val]"=&r"(rdtime.value),[tid]"=&r"(rdtime.timeid)
+:);
+  return rdtime;
+}
+#define __rdtimel_w __builtin_loongarch_rdtimel_w
+
+extern __inline __rdtime_t
+__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
+__builtin_loongarch_rdtimel_w (void)
+{
+  __rdtime_t rdtime;
+  __asm__ volatile (
+"rdtimel.w\t%[val],%[tid]\n\t"
+: [val]"=&r"(rdtime.value),[tid]"=&r"(rdtime.timeid)
+:);
+  return rdtime;
+}
+#define __rdtimeh_w __builtin_loongarch_rdtimeh_w
+
+/* Assembly instruction format:rj, fcsr.  */
+/* Data types in instruction templates:  USI, UQI.  */
+#define __movfcsr2gr(/*ui5*/ _1) __builtin_loongarch_movfcsr2gr ((_1));
+
+/* Assembly instruction format:0, fcsr, rj.  */
+/* Data types in instruction templates:  VOID, UQI, USI.  */
+#define __movgr2fcsr(/*ui5*/ _1, _2) \
+  __builtin_loongarch_movgr2fcsr ((unsigned short) _1, (unsigned int) _2);
+
+#if defined __loongarch64
+/* Assembly instruction format:ui5, rj, si12.  */
+/* Data types in instruction templates:  VOID, USI, UDI, SI.  */
+#define __dcacop(/*ui5*/ _1, /*unsigned long int*/ _2, /*si12*/ _3) \
+  ((void) __builtin_loongarch_dcacop ((_1), (unsigned long int) (_2), (_3)))
+#else
+#error "Don't support this ABI."
+#endif
+
+/* Assembly instruction format:rd, rj.  */
+/* Data types in instruction templates:  USI, USI.  */
+extern __inline unsigned int
+__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
+__cpucfg (unsigned int _1)
+{
+  return (unsigned int) __builtin_loongarch_cpucfg ((unsigned int) _1);
+}
+
+#ifdef __loongarch64
+/* Assembly instruction format:rd, rj.  */
+/* Data types in instruction templates:  DI, DI.  */
+extern __inline void
+__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
+__asrtle_d (long int _1, long int _2)
+{
+  __builtin_loongarch_asrtle_d ((long int) _1, (long int) _2);
+}
+
+/* Assembly instruction format:rd, rj.  */
+/* Data types in instruction templates:  DI, DI.  */
+extern __inline void
+__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
+__asrtgt_d (long int _1, long int _2)
+{
+  __builtin_loongarch_asrtgt_d ((long int) _1, (long int) _2);
+}
+#endif
+
+#if defined __loongarch64
+/* Assembly instruction format:rd, rj, ui5.  */
+/* Data types in instruction templates:  DI, DI, UQI.  */
+#