Re: [PATCH] c++: Implement -Wuninitialized for mem-initializers (redux) [PR19808]

2021-11-06 Thread Jason Merrill via Gcc-patches

On 11/5/21 19:22, Marek Polacek wrote:

2021 update: Last year I posted a version of this patch:

but it didn't make it in.  The main objection seemed to be that the
patch tried to do too much, and overlapped with the ME uninitialized
warnings.  Since the patch used walk_tree without any data flow info,
it issued false positives for things like a(0 ? b : 42) and similar.

I'll admit I've been dreading resurrecting this because of the lack
of clarity about where we should warn about what.  On the other hand,
I think we really should do something about this.  So I've simplified
the original patch as much as it seemed reasonable.  For instance, it
doesn't even attempt to handle cases like "a((b = 42)), c(b)" -- for
these I simply give up for the whole mem-initializer (but who writes
code like that, anyway?).  I also give up when a member is initialized
with a function call, because we don't know what the call could do.
See Wuninitialized-17.C, for which clang emits a false positive but
we don't.  I remember having a hard time dealing with initializer lists
in my previous patch, so now I only handle simple a{b} cases, but no
more.  It turned out that this abridged version still warns about 90%
cases where users would expect a warning.


Sounds good.


More complicated cases are left for the ME, which, for unused inline
functions, will only warn with -fkeep-inline-functions, but so be it.


This seems like a broader issue that should really be addressed; since 
we have warnings that depend on running optimization passes, there 
should be a way to force the function through to that point even if we 
don't need to write it out.  This is also the problem with bug 21678.



This patch implements the long-desired -Wuninitialized warning for
member initializer lists, so that the front end can detect bugs like

   struct A {
 int a;
 int b;
 A() : b(1), a(b) { }
   };

where the field 'b' is used uninitialized because the order of member
initializers in the member initializer list is irrelevant; what matters
is the order of declarations in the class definition.

I've implemented this by keeping a hash set holding fields that are not
initialized yet, so at first it will be {a, b}, and after initializing
'a' it will be {b} and so on.  Then I use walk_tree to walk the
initializer and if we see that an uninitialized object is used, we warn.
Of course, when we use the address of the object, we may not warn:

   struct B {
 int 
 int *p;
 int a;
 B() : r(a), p(), a(1) { } // ok
   };

Likewise, don't warn in unevaluated contexts such as sizeof.  Classes
without an explicit initializer may still be initialized by their
default constructors; whether or not something is considered initialized
is handled in perform_member_init, see member_initialized_p.

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

PR c++/19808
PR c++/96121

gcc/cp/ChangeLog:

* init.c (perform_member_init): Remove a forward declaration.
Walk the initializer using find_uninit_fields_r.  New parameter
to track uninitialized fields.  If a member is initialized,
remove it from the hash set.
(perform_target_ctor): Return the initializer.
(struct find_uninit_data): New class.
(find_uninit_fields_r): New function.
(emit_mem_initializers): Keep and initialize a set holding fields
that are not initialized.  When handling delegating constructors,
walk the constructor tree using find_uninit_fields_r.  Also when
initializing base clases.  Pass uninitialized down to
perform_member_init.

gcc/ChangeLog:

* doc/invoke.texi: Update documentation for -Wuninitialized.
* tree.c (stabilize_reference): Set location.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wuninitialized-14.C: New test.
* g++.dg/warn/Wuninitialized-15.C: New test.
* g++.dg/warn/Wuninitialized-16.C: New test.
* g++.dg/warn/Wuninitialized-17.C: New test.
* g++.dg/warn/Wuninitialized-18.C: New test.
* g++.dg/warn/Wuninitialized-19.C: New test.
* g++.dg/warn/Wuninitialized-20.C: New test.
* g++.dg/warn/Wuninitialized-21.C: New test.
* g++.dg/warn/Wuninitialized-22.C: New test.
* g++.dg/warn/Wuninitialized-23.C: New test.
* g++.dg/warn/Wuninitialized-24.C: New test.
* g++.dg/warn/Wuninitialized-25.C: New test.
* g++.dg/warn/Wuninitialized-26.C: New test.
* g++.dg/warn/Wuninitialized-27.C: New test.
* g++.dg/warn/Wuninitialized-28.C: New test.
* g++.dg/warn/Wuninitialized-29.C: New test.
---
  gcc/cp/init.c | 187 --
  gcc/doc/invoke.texi   |  12 ++
  gcc/testsuite/g++.dg/warn/Wuninitialized-14.C |  31 +++
  gcc/testsuite/g++.dg/warn/Wuninitialized-15.C | 118 +++
  

Re: [PATCH 2/2] Fortran: Fix memory leak in gfc_add_include_path [PR68800]

2021-11-06 Thread Bernhard Reutner-Fischer via Gcc-patches
On Sat, 6 Nov 2021 20:22:53 +0100
Harald Anlauf  wrote:

> Hi Bernhard,
> 
> I cannot comment on the gcc/ parts, but
> 

> > diff --git a/gcc/fortran/cpp.c b/gcc/fortran/cpp.c
> > index e86386c8b17..04fe8fe460b 100644
> > --- a/gcc/fortran/cpp.c
> > +++ b/gcc/fortran/cpp.c
> > @@ -728,12 +728,20 @@ gfc_cpp_done (void)
> > cpp_clear_file_cache (cpp_in);
> >   }  
> 
> why do you introduce a wrapper for something outside of fortran
> that is used only once,
> 
> > -/* PATH must be malloc-ed and NULL-terminated.  */
> > +/* Free all cpp include dirs.  */
> > +void
> > +gfc_cpp_free_cpp_dirs (void)
> > +{
> > +  free_cpp_dirs ();
> > +}

> > diff --git a/gcc/fortran/cpp.h b/gcc/fortran/cpp.h
> > index 44644a2a333..963b9a9c89e 100644
> > --- a/gcc/fortran/cpp.h
> > +++ b/gcc/fortran/cpp.h
> > @@ -46,6 +46,7 @@ void gfc_cpp_post_options (bool);
> >   bool gfc_cpp_preprocess (const char *source_file);
> >
> >   void gfc_cpp_done (void);
> > +void gfc_cpp_free_cpp_dirs (void);
> >
> >   void gfc_cpp_add_include_path (char *path, bool user_supplied);
> >   void gfc_cpp_add_include_path_after (char *path, bool user_supplied);
> > diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
> > index 58dcaf01d75..ec4c2cf01d9 100644
> > --- a/gcc/fortran/f95-lang.c
> > +++ b/gcc/fortran/f95-lang.c
> > @@ -275,7 +275,7 @@ gfc_finish (void)
> > gfc_cpp_done ();
> > gfc_done_1 ();
> > gfc_release_include_path ();
> > -  return;  
> 
> namely here?
> 
> > +  gfc_cpp_free_cpp_dirs ();
> >   }  
> 
> Why not call free_cpp_dirs () here directly, omit all unnecessary
> stuff, and maybe only add a brief comment here?

cpp.c includes incpath.h, f95-lang.c does not and should not.
So the cleanest thing is to keep the cpp handling in cpp.[ch] and have
the language frontend call into it's cpp bits.

It would be rather rogue to
extern void free_cpp_dirs (void);
in f95-lang.c and directly call it in gfc_finish, i'd say?

thanks,


Re: Some PINGs

2021-11-06 Thread Jeff Law via Gcc-patches




On 11/6/2021 4:20 PM, Roger Sayle wrote:


Simplify paradoxical subreg extensions of TRUNCATE
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578848.html
So the discussion seemed to end with a recommendation to try and address 
this earlier in the call chain rather than in simplify_rtx.


No state on the others...

jeff



[PATCH] c++: designated init of char array by string constant [PR55227]

2021-11-06 Thread Will Wray via Gcc-patches
This patch aims to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227.

There are two underlying bugs in the designated initialization of char array
fields by string literals that cause:

(1) Rejection of valid cases with:
  (a) brace-enclosed string literal initializer (of any valid size), or
  (b) unbraced string literal shorter than the target char array field.

(2) Acceptance of invalid cases with designators appearing within the braces
of a braced string literal, in which case the bogus 'designator' was being
entirely ignored and the string literal treated as a positional initializer.

Please review these changes carefully; there are likely errors of omission,
logic or an anon anomaly.

The fixes above allow to address a FIXME in cp_complete_array_type:

  /* FIXME: this code is duplicated from reshape_init.
 Probably we should just call reshape_init here?  */

I believe that this was obstructed by the designator bugs (see comment here
https://patchwork.ozlabs.org/project/gcc/list/?series=199783)

Boostraps/regtests on x86_64-pc-linux-gnu.

PR c++/55227

gcc/cp/ChangeLog:

* decl.c (reshape_init_r): restrict has_designator_check,
(cp_complete_array_type): do reshape_init on braced-init-list.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/desig20.C: New test.
---
 gcc/cp/decl.c| 28 ++--
 gcc/testsuite/g++.dg/cpp2a/desig20.C | 48 
 2 files changed, 57 insertions(+), 19 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/desig20.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 947bbfc6637..f01655c5c14 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6820,6 +6820,7 @@ reshape_init_r (tree type, reshape_iter *d, tree 
first_initializer_p,
 {
   tree str_init = init;
   tree stripped_str_init = stripped_init;
+  reshape_iter stripd = {};
 
   /* Strip one level of braces if and only if they enclose a single
 element (as allowed by [dcl.init.string]).  */
@@ -6827,7 +6828,8 @@ reshape_init_r (tree type, reshape_iter *d, tree 
first_initializer_p,
  && TREE_CODE (stripped_str_init) == CONSTRUCTOR
  && CONSTRUCTOR_NELTS (stripped_str_init) == 1)
{
- str_init = (*CONSTRUCTOR_ELTS (stripped_str_init))[0].value;
+ stripd.cur = CONSTRUCTOR_ELT (stripped_str_init, 0);
+ str_init = stripd.cur->value;
  stripped_str_init = tree_strip_any_location_wrapper (str_init);
}
 
@@ -6836,7 +6838,8 @@ reshape_init_r (tree type, reshape_iter *d, tree 
first_initializer_p,
 array types (one value per array element).  */
   if (TREE_CODE (stripped_str_init) == STRING_CST)
{
- if (has_designator_problem (d, complain))
+ if ((first_initializer_p && has_designator_problem (d, complain))
+ || (stripd.cur && has_designator_problem (, complain)))
return error_mark_node;
  d->cur++;
  return str_init;
@@ -9538,23 +9541,10 @@ cp_complete_array_type (tree *ptype, tree 
initial_value, bool do_default)
 
   if (initial_value)
 {
-  /* An array of character type can be initialized from a
-brace-enclosed string constant.
-
-FIXME: this code is duplicated from reshape_init. Probably
-we should just call reshape_init here?  */
-  if (char_type_p (TYPE_MAIN_VARIANT (TREE_TYPE (*ptype)))
- && TREE_CODE (initial_value) == CONSTRUCTOR
- && !vec_safe_is_empty (CONSTRUCTOR_ELTS (initial_value)))
-   {
- vec *v = CONSTRUCTOR_ELTS (initial_value);
- tree value = (*v)[0].value;
- STRIP_ANY_LOCATION_WRAPPER (value);
-
- if (TREE_CODE (value) == STRING_CST
- && v->length () == 1)
-   initial_value = value;
-   }
+  if (TREE_CODE (initial_value) == CONSTRUCTOR
+ && BRACE_ENCLOSED_INITIALIZER_P (initial_value))
+   initial_value = reshape_init (*ptype, initial_value,
+ tf_warning_or_error);
 
   /* If any of the elements are parameter packs, we can't actually
 complete this type now because the array size is dependent.  */
diff --git a/gcc/testsuite/g++.dg/cpp2a/desig20.C 
b/gcc/testsuite/g++.dg/cpp2a/desig20.C
new file mode 100644
index 000..03eab764325
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/desig20.C
@@ -0,0 +1,48 @@
+// PR c++/55227 
+// Test designated initializer for char array by string constant
+
+// { dg-do compile }
+// { dg-options "-pedantic" }
+
+struct C {char a[2];};
+
+/* Case a; designated, unbraced, string-literal of the same size as the target
+   char array to be initialized; valid and accepted before and after.  */
+
+C a = {.a="a"}; // { dg-warning "designated initializers only available with" 
"" { target c++17_down } .-0 }
+
+/* Cases b,c,d; designated mismatched-size string literal, or designated braced
+   string literal (of any size less than or equal to the 

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

2021-11-06 Thread Bernhard Reutner-Fischer via Gcc-patches
On Sat, 6 Nov 2021 13:04:07 +0100
Mikael Morin  wrote:

> Le 05/11/2021 à 23:08, Bernhard Reutner-Fischer a écrit :
> > On Fri, 5 Nov 2021 19:46:16 +0100
> > Mikael Morin  wrote:
> >   
> >> Le 29/10/2021 à 01:58, Bernhard Reutner-Fischer via Fortran a écrit :  
> >>> On Wed, 27 Oct 2021 23:39:43 +0200
> >>> Bernhard Reutner-Fischer  wrote:
> >>>  
>  On Mon, 15 Oct 2018 10:23:06 +0200
>  Bernhard Reutner-Fischer  wrote:
>  
> > If a finalization is not required we created a namespace containing
> > formal arguments for an internal interface definition but never used
> > any of these. So the whole sub_ns namespace was not wired up to the
> > program and consequently was never freed. The fix is to simply not
> > generate any finalization wrappers if we know that it will be unused.
> > Note that this reverts back to the original r190869
> > (8a96d64282ac534cb597f446f02ac5d0b13249cc) handling for this case
> > by reverting this specific part of r194075
> > (f1ee56b4be7cc3892e6ccc75d73033c129098e87) for PR fortran/37336.
> > 
> >> I’m a bit concerned by the loss of the null_expr’s type interface.
> >> I can’t convince myself that it’s either absolutely necessary or
> >> completely useless.  
> > 
> > It's a delicate spot, yes, but i do think they are completely useless.
> > If we do NOT need a finalization, the initializer can (and has to be
> > AFAIU) be a null_expr and AFAICS then does not need an interface.
> >   
> Well, the null pointer itself doesn’t need a type, but I think it’s 
> better if the pointer it’s assigned to has a type different from void*.
> It will (hopefully) help the middle-end optimizers downstream.

I would not expect this to help all that much or at all TBH.

So i compiled
for i in $(grep -li final $(grep -L dg-error 
/scratch/src/gcc-12.mine/gcc/testsuite/gfortran.dg/*.f*)); do gfortran -O2 
-fcoarray=single -c $i -g -g3 -ggdb3 -fdump-tree-original 
-fdump-tree-optimized;done
and diffed all .original and .optimized dumps against pristine trunk
and they are identical.

I inspected and ran the binary from finalize_14 and there is no change
in the leaks compared to pristine trunk. The 3 shape_w in p leak as
they used to. I do remember that finalize_14 was a good testcase, in
sum i glared at it for quite some time ;)
> 
> I will see if I can manage to create a testcase where it makes a 
> difference (don’t hold your breath, I don’t even have a bootstrapped 
> compiler ready yet).
> 
That'd be great, TIA!
[]

btw.. Just because it's vagely related.
I think f8add009ce300f24b75e9c2e2cc5dd944a020c28 for
PR fortran/88009 (ICE in find_intrinsic_vtab, at fortran/class.c:2761)
is incomplete in that i think all the internal class helpers should be
flagged artificial. All these symbols built in gfc_build_class_symbol,
generate_finalization_wrapper, gfc_find_derived_vtab etc.
Looking at the history it seems the artificial bit often was forgotten.
And most importantly i think it is not correct to ignore artificial in
gfc_check_conflict!

I'm attaching my notes on this to illustrate what i mean.
Not a patch, even if it regtests cleanly..

The hunk in gfc_match_derived_decl() plugs another leak by first
checking if the max extension level is reached before adding the
component. Maybe i should split that hunk out.
Similar to the removal of *head in gfc_match_derived_decl, there's
another spot in gfc_match_decl_type_spec which should get rid of the
*head and just wire the interface up as usual. Just cosmetics.

Several tests do exercise this code: alloc_comp_class_1.f90,
class_19.f03 and 62, unlimited_polymorphic_8.f90 and others.

> >> The rest of the changes (appart from class.c) are mostly OK with the nit
> >> below and should be put in their own commit.
> >>  
> >>   >>> @@ -3826,10 +3828,8 @@ free_tb_tree (gfc_symtree *t)
> >>   >>>
> >>   >>> free_tb_tree (t->left);
> >>   >>> free_tb_tree (t->right);
> >>   >>> -
> >>   >>> -  /* TODO: Free type-bound procedure structs themselves; probably  
> >> needs some  
> >>   >>> - sort of ref-counting mechanism.  */
> >>   >>> free (t->n.tb);  
> >>
> >> Please keep a comment; it remains somehow valid but could be updated
> >> maybe: gfc_typebound_proc’s u.generic field for example is nowhere freed
> >> as far as I know.  
> > 
> > Well that's a valid point, not sure where they are freed indeed.
> > Do you have a specific testcase in mind that leaks tbp's u.generic (or
> > specific for that matter) for me to look at?
> >   
> Any testcase with generic typebound procedures, I guess.
> typebound_generic_3.f03 for example seems like a good candidate.

I'll have a look at these later, thanks for the pointer.
> 
> > I'm happy to change the comment to
> > TODO: Free type-bound procedure u.generic and u.specific fields
> > to reflect the current state. Ok?
> >  
> I don’t think specific leaks because it’s one of gfc_namespace’s 
> sym_root sub-nodes, and it’s freed with 

Fix can_be_discarded_p wrt partitioned functions

2021-11-06 Thread Jan Hubicka via Gcc-patches
Hi,
can_be_discarded_p is testing DECL_EXTERNAL flag to see if the symbol
can be discarded by linker if unreachable.  This is meant to catch
extern inline functions (which is bit side case and it is intded to
avoid gcc from producing new references to them if there were no
refernces before) but it mistakely also matches partitioned functions
during LTO.  This led to the ICE with sanity check I added to
gimple_call_static_chain_flags since we suddenly got interposable nested
functions.

This is fixed by the patch and I checked I can build the failing
testcases with the sanity check re-instatiated which I plan to do after
some more testing.

ltobootstrapped/regtested x86_64. Comitte.

Honza

gcc/ChangeLog:

* cgraph.h (cgraph_node::can_be_discarded_p): Do not
return true on functions from other partition.

gcc/lto/ChangeLog:

PR ipa/103070
PR ipa/103058
* lto-partition.c (must_not_rename): Update comment.
(promote_symbol): Set resolution to LDPR_PREVAILING_DEF_IRONLY.

diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index 4cdb3738b4d..0a1f7c8960e 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -404,7 +404,8 @@ public:
   inline bool
   can_be_discarded_p (void)
   {
-return (DECL_EXTERNAL (decl)
+return ((DECL_EXTERNAL (decl)
+&& !in_other_partition)
|| ((get_comdat_group ()
 || DECL_COMMON (decl)
 || (DECL_SECTION_NAME (decl) && DECL_WEAK (decl)))
diff --git a/gcc/lto/lto-partition.c b/gcc/lto/lto-partition.c
index 15761ac9eb5..bee40218159 100644
--- a/gcc/lto/lto-partition.c
+++ b/gcc/lto/lto-partition.c
@@ -852,7 +852,9 @@ must_not_rename (symtab_node *node, const char *name)
   /* Avoid mangling of already mangled clones. 
  ???  should have a flag whether a symbol has a 'private' name already,
  since we produce some symbols like that i.e. for global constructors
- that are not really clones.  */
+ that are not really clones.
+ ???  it is what unique_name means.  We only need to set it when doing
+ private symbols.  */
   if (node->unique_name)
 {
   if (dump_file)
@@ -995,6 +997,10 @@ promote_symbol (symtab_node *node)
  defined by the non-LTO part.  */
   privatize_symbol_name (node);
   TREE_PUBLIC (node->decl) = 1;
+  /* After privatization the node should not conflict with any other symbol,
+ so it is prevailing.  This is important to keep binds_to_current_def_p
+ to work across partitions.  */
+  node->resolution = LDPR_PREVAILING_DEF_IRONLY;
   DECL_VISIBILITY (node->decl) = VISIBILITY_HIDDEN;
   DECL_VISIBILITY_SPECIFIED (node->decl) = true;
   if (dump_file)


Some PINGs

2021-11-06 Thread Roger Sayle


I wonder if reviewers could take a look (or a second look) at some of my
outstanding patches.

Four nvptx backend patches:

nvptx: Use cvt to perform sign-extension of truncation.
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578256.html

nvptx: Add (experimental) support for HFmode with -misa=sm_53
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579623.html

nvptx: Adds uses of -misa=sm_75 and -misa=sm_80
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579691.html

Transition nvptx backend to STORE_FLAG_VALUE = 1
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581004.html

Two middle-end patches:

Simplify paradoxical subreg extensions of TRUNCATE
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578848.html

PR middle-end/100810: Penalize IV candidates with undefined value bases
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578441.html

And a gfortran patch:

gfortran: Improve translation of POPPAR intrinsic
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548055.html


Many thanks in advance,
Roger
--




Re: [PATCH v5] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

2021-11-06 Thread Bernhard Reutner-Fischer via Gcc-patches
On Sat, 6 Nov 2021 15:29:57 -0400
Jason Merrill  wrote:

> On 11/6/21 14:28, Marek Polacek wrote:
> > On Sat, Nov 06, 2021 at 02:32:26AM +0100, Bernhard Reutner-Fischer wrote:  

> > No, I want q to point into the copy of the string, since I'm about
> > to modify it.  And I'd prefer a single call to xstrdup rather than
> > two.  
> 
> It occurs to me that instead of calling xstrdup at all, since you're 
> already passing the strings to get_identifier you could use 
> get_identifier_with_length instead, and then refer to IDENTIFIER_POINTER 
> of the result.

Right, i should have looked at the full diff.
I can see the point in stripping __attr__ to attr but also stripping
the vendors sounds a bit odd, doesn't it.

IMHO it would have been way easier to just calculate the desired start
and end and get_identifier_with_length for the vendor and attr as Jason
said.

Guess these local lambdas are a thing nowadays :)

Sorry for the noise..


[PATCH] aarch64: [PR101529] Fix vector shuffle insertion expansion

2021-11-06 Thread apinski--- via Gcc-patches
From: Andrew Pinski 

The function aarch64_evpc_ins would reuse the target even though
it might be the same register as the two inputs.
Instead of checking to see if we can reuse the target, creating
a new register always is better.

OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.

PR target/101529

gcc/ChangeLog:

* config/aarch64/aarch64.c (aarch64_evpc_ins): Don't use target
as an input instead create a new reg.

gcc/testsuite/ChangeLog:

* c-c++-common/torture/builtin-convertvector-2.c: New test.
* c-c++-common/torture/builtin-shufflevector-2.c: New test.
---
 gcc/config/aarch64/aarch64.c  |  8 --
 .../torture/builtin-convertvector-2.c | 26 +++
 .../torture/builtin-shufflevector-2.c | 26 +++
 3 files changed, 58 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/torture/builtin-convertvector-2.c
 create mode 100644 gcc/testsuite/c-c++-common/torture/builtin-shufflevector-2.c

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 2c00583e12c..e4fc546fae7 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -23084,11 +23084,15 @@ aarch64_evpc_ins (struct expand_vec_perm_d *d)
 }
   gcc_assert (extractindex < nelt);
 
-  emit_move_insn (d->target, insv);
+  /* Use a new reg instead of target as one of the
+ operands might be target. */
+  rtx original = gen_reg_rtx (GET_MODE (d->target));
+
+  emit_move_insn (original, insv);
   insn_code icode = code_for_aarch64_simd_vec_copy_lane (mode);
   expand_operand ops[5];
   create_output_operand ([0], d->target, mode);
-  create_input_operand ([1], d->target, mode);
+  create_input_operand ([1], original, mode);
   create_integer_operand ([2], 1 << idx);
   create_input_operand ([3], extractv, mode);
   create_integer_operand ([4], extractindex);
diff --git a/gcc/testsuite/c-c++-common/torture/builtin-convertvector-2.c 
b/gcc/testsuite/c-c++-common/torture/builtin-convertvector-2.c
new file mode 100644
index 000..d88f6a72b5c
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/torture/builtin-convertvector-2.c
@@ -0,0 +1,26 @@
+/* { dg-do run } */
+/* PR target/101529 */
+
+typedef unsigned char __attribute__((__vector_size__ (1))) W;
+typedef unsigned char __attribute__((__vector_size__ (8))) V;
+typedef unsigned short __attribute__((__vector_size__ (16))) U;
+
+unsigned short us;
+
+/* aarch64 used to miscompile foo to just return 0. */
+W
+foo (unsigned char uc)
+{
+  V v = __builtin_convertvector ((U){ } >= us, V);
+  return __builtin_shufflevector ((W){ }, v, 4) & uc;
+}
+
+int
+main (void)
+{
+  W x = foo (5);
+  if (x[0] != 5)
+__builtin_abort();
+  return 0;
+}
+
diff --git a/gcc/testsuite/c-c++-common/torture/builtin-shufflevector-2.c 
b/gcc/testsuite/c-c++-common/torture/builtin-shufflevector-2.c
new file mode 100644
index 000..7c4999ed4e9
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/torture/builtin-shufflevector-2.c
@@ -0,0 +1,26 @@
+/* { dg-do run}  */
+/* PR target/101529 */
+typedef unsigned char C;
+typedef unsigned char __attribute__((__vector_size__ (8))) V;
+typedef unsigned char __attribute__((__vector_size__ (32))) U;
+
+C c;
+
+/* aarch64 used to miscompile foo to just return a vector of 0s */
+V
+foo (V v)
+{
+  v |= __builtin_shufflevector (c * v, (U) (0 == (U){ }),
+   0, 1, 8, 32, 8, 20, 36, 36);
+  return v;
+}
+
+int
+main (void)
+{
+  V v = foo ((V) { });
+  for (unsigned i = 0; i < sizeof (v); i++)
+if (v[i] != (i >= 2 ? 0xff : 0))
+  __builtin_abort ();
+  return 0;
+}
-- 
2.17.1



Re: [PATCH v5] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

2021-11-06 Thread Jason Merrill via Gcc-patches

On 11/6/21 14:28, Marek Polacek wrote:

On Sat, Nov 06, 2021 at 02:32:26AM +0100, Bernhard Reutner-Fischer wrote:

On 6 November 2021 01:21:43 CET, Marek Polacek via Gcc-patches 
 wrote:



Thanks, so like this?  I'm including an incremental diff so that it's
clear what changed:

diff --git a/gcc/attribs.c b/gcc/attribs.c
index d5fba7f4bbb..addfe6f6c80 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -237,7 +237,7 @@ check_attribute_tables (void)
the end of parsing of all TUs. */
static vec ignored_attributes_table;

-/* Parse arguments ARGS of -Wno-attributes=.
+/* Parse arguments V of -Wno-attributes=.
Currently we accept:
  vendor::attr
  vendor::
@@ -252,12 +252,15 @@ handle_ignored_attributes_option (vec *v)

   for (auto opt : v)
 {
+  /* We're going to be modifying the string.  */
+  opt = xstrdup (opt);
   char *q = strstr (opt, "::");
   /* We don't accept '::attr'.  */
   if (q == nullptr || q == opt)
{
  error ("wrong argument to ignored attributes");
  inform (input_location, "valid format is % or %");
+ free (opt);
  continue;
}


Only xstrdup here, after the strstr check?
Should maybe strdup the rest here, not full opt..


No, I want q to point into the copy of the string, since I'm about
to modify it.  And I'd prefer a single call to xstrdup rather than
two.


It occurs to me that instead of calling xstrdup at all, since you're 
already passing the strings to get_identifier you could use 
get_identifier_with_length instead, and then refer to IDENTIFIER_POINTER 
of the result.


Jason



Re: [PATCH 2/2] Fortran: Fix memory leak in gfc_add_include_path [PR68800]

2021-11-06 Thread Harald Anlauf via Gcc-patches

Hi Bernhard,

I cannot comment on the gcc/ parts, but

Am 05.11.21 um 22:17 schrieb Bernhard Reutner-Fischer via Gcc-patches:

From: Bernhard Reutner-Fischer 

gcc/fortran/ChangeLog:

PR fortran/68800
* cpp.h (gfc_cpp_free_cpp_dirs): New declaration.
* cpp.c (gfc_cpp_free_cpp_dirs): New definition.
(gfc_cpp_add_include_path, gfc_cpp_add_include_path_after): Add
comment.
* f95-lang.c (gfc_finish): Call gfc_cpp_free_cpp_dirs.
* scanner.c (add_path_to_list): Allocate unzeroed memory.
(gfc_add_include_path): Add comment and fix formatting.

---
Bootstrapped and regtested without regressions on x86_64-unknown-linux.
Ok for trunk?

Note: in add_path_to_list i changed dir->path = XCNEWVEC to XNEWVEC
since strcpy and strcat add a terminating null byte for us anyway.
Fixes:

-== 68 bytes in 1 blocks are still reachable in loss record 228 of 371
-==at : malloc (vg_replace_malloc.c:380)
-==by : xmalloc (xmalloc.c:149)
-==by : xstrdup (xstrdup.c:34)
-==by : gfc_add_include_path(char const*, bool, bool, bool, bool) (scanner.c
:428)
-==by : gfc_handle_option(unsigned long, char const*, long, int, unsigned in
t, cl_option_handlers const*) (options.c:702)
-==by : handle_option(gcc_options*, gcc_options*, cl_decoded_option const*,
unsigned int, int, unsigned int, cl_option_handlers const*, bool, diagnostic_con
text*) (opts-common.c:1181)
-==by : read_cmdline_option(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, cl_option_handlers const*, diagnostic_context*) (opt
s-common.c:1431)
-==by : read_cmdline_options (opts-global.c:237)
-==by : decode_options(gcc_options*, gcc_options*, cl_decoded_option*, unsig
ned int, unsigned int, diagnostic_context*, void (*)()) (opts-global.c:319)
-==by : toplev::main(int, char**) (toplev.c:2273)
-==by : main (main.c:39)
---
  gcc/fortran/cpp.c  | 13 +++--
  gcc/fortran/cpp.h  |  1 +
  gcc/fortran/f95-lang.c |  2 +-
  gcc/fortran/scanner.c  |  7 ---
  4 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/gcc/fortran/cpp.c b/gcc/fortran/cpp.c
index e86386c8b17..04fe8fe460b 100644
--- a/gcc/fortran/cpp.c
+++ b/gcc/fortran/cpp.c
@@ -728,12 +728,20 @@ gfc_cpp_done (void)
cpp_clear_file_cache (cpp_in);
  }


why do you introduce a wrapper for something outside of fortran
that is used only once,


-/* PATH must be malloc-ed and NULL-terminated.  */
+/* Free all cpp include dirs.  */
+void
+gfc_cpp_free_cpp_dirs (void)
+{
+  free_cpp_dirs ();
+}
+
+/* PATH must be NULL-terminated.  */
  void
  gfc_cpp_add_include_path (char *path, bool user_supplied)
  {
/* CHAIN sets cpp_dir->sysp which differs from 0 if PATH is a system
- include path. Fortran does not define any system include paths.  */
+ include path. Fortran does not define any system include paths.
+ incpath.c manages the incoming, xstrdup()ed path.  */
int cxx_aware = 0;
  
add_path (path, INC_BRACKET, cxx_aware, user_supplied);

@@ -742,6 +750,7 @@ gfc_cpp_add_include_path (char *path, bool user_supplied)
  void
  gfc_cpp_add_include_path_after (char *path, bool user_supplied)
  {
+  /* incpath.c manages the incoming, xstrdup()ed path.  */
int cxx_aware = 0;
add_path (path, INC_AFTER, cxx_aware, user_supplied);
  }
diff --git a/gcc/fortran/cpp.h b/gcc/fortran/cpp.h
index 44644a2a333..963b9a9c89e 100644
--- a/gcc/fortran/cpp.h
+++ b/gcc/fortran/cpp.h
@@ -46,6 +46,7 @@ void gfc_cpp_post_options (bool);
  bool gfc_cpp_preprocess (const char *source_file);
  
  void gfc_cpp_done (void);

+void gfc_cpp_free_cpp_dirs (void);
  
  void gfc_cpp_add_include_path (char *path, bool user_supplied);

  void gfc_cpp_add_include_path_after (char *path, bool user_supplied);
diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
index 58dcaf01d75..ec4c2cf01d9 100644
--- a/gcc/fortran/f95-lang.c
+++ b/gcc/fortran/f95-lang.c
@@ -275,7 +275,7 @@ gfc_finish (void)
gfc_cpp_done ();
gfc_done_1 ();
gfc_release_include_path ();
-  return;


namely here?


+  gfc_cpp_free_cpp_dirs ();
  }


Why not call free_cpp_dirs () here directly, omit all unnecessary
stuff, and maybe only add a brief comment here?


  /* These functions and variables deal with binding contours.  We only
diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
index 69b81ab97f8..268d1e3e7fb 100644
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -370,7 +370,7 @@ add_path_to_list (gfc_directorylist **list, const char 
*path,
char *q;
size_t len;
int i;
-
+
p = path;
while (*p == ' ' || *p == '\t')  /* someone might do "-I include" */
  if (*p++ == '\0')
@@ -409,7 +409,7 @@ add_path_to_list (gfc_directorylist **list, const char 
*path,
  *list = dir;
dir->use_for_modules = use_for_modules;
dir->warn = warn; > -  dir->path = XCNEWVEC (char, strlen (p) + 2);
+  dir->path = XNEWVEC (char, strlen (p) + 2);
strcpy (dir->path, p);
   

Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1

2021-11-06 Thread Thomas Koenig via Gcc-patches



Hi Manfred,

looks good to me.

Thanks for the patch!

Best regards

Thomas


Re: [PATCH v5] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

2021-11-06 Thread Marek Polacek via Gcc-patches
On Sat, Nov 06, 2021 at 02:32:26AM +0100, Bernhard Reutner-Fischer wrote:
> On 6 November 2021 01:21:43 CET, Marek Polacek via Gcc-patches 
>  wrote:
> 
> >
> >Thanks, so like this?  I'm including an incremental diff so that it's
> >clear what changed:
> >
> >diff --git a/gcc/attribs.c b/gcc/attribs.c
> >index d5fba7f4bbb..addfe6f6c80 100644
> >--- a/gcc/attribs.c
> >+++ b/gcc/attribs.c
> >@@ -237,7 +237,7 @@ check_attribute_tables (void)
> >the end of parsing of all TUs. */
> > static vec ignored_attributes_table;
> > 
> >-/* Parse arguments ARGS of -Wno-attributes=.
> >+/* Parse arguments V of -Wno-attributes=.
> >Currently we accept:
> >  vendor::attr
> >  vendor::
> >@@ -252,12 +252,15 @@ handle_ignored_attributes_option (vec *v)
> > 
> >   for (auto opt : v)
> > {
> >+  /* We're going to be modifying the string.  */
> >+  opt = xstrdup (opt);
> >   char *q = strstr (opt, "::");
> >   /* We don't accept '::attr'.  */
> >   if (q == nullptr || q == opt)
> > {
> >   error ("wrong argument to ignored attributes");
> >   inform (input_location, "valid format is % or %");
> >+  free (opt);
> >   continue;
> > }
> 
> Only xstrdup here, after the strstr check?
> Should maybe strdup the rest here, not full opt..

No, I want q to point into the copy of the string, since I'm about
to modify it.  And I'd prefer a single call to xstrdup rather than
two.

Marek



Re: [PATCH] Add debug counters to back threader.

2021-11-06 Thread Aldy Hernandez via Gcc-patches
On Tue, Nov 2, 2021 at 3:13 PM Richard Biener
 wrote:
>
> On Tue, Nov 2, 2021 at 2:36 PM Aldy Hernandez  wrote:
> >
> > On Tue, Nov 2, 2021 at 2:27 PM Richard Biener
> >  wrote:
> > >
> > > On Mon, Nov 1, 2021 at 2:03 PM Jeff Law via Gcc-patches
> > >  wrote:
> > > >
> > > >
> > > >
> > > > On 11/1/2021 3:54 AM, Aldy Hernandez wrote:
> > > > > Chasing down stage3 miscomparisons is never fun, and having no way to
> > > > > distinguish between jump threads registered by a particular
> > > > > pass, is even harder.  This patch adds debug counters for the 
> > > > > individual
> > > > > back threading passes.  I've left the ethread pass alone, as that one 
> > > > > is
> > > > > usually benign, but we could easily add it if needed.
> > > > >
> > > > > The fact that we can only pass one boolean argument to the passes
> > > > > infrastructure has us do all sorts of gymnastics to differentiate
> > > > > between the various back threading passes.
> > > > >
> > > > > Tested on x86-64 Linux.
> > > > >
> > > > > OK?
> > > > >
> > > > > gcc/ChangeLog:
> > > > >
> > > > >   * dbgcnt.def: Add debug counter for back_thread[12] and
> > > > >   back_threadfull[12].
> > > > >   * passes.def: Pass "first" argument to each back threading pass.
> > > > >   * tree-ssa-threadbackward.c (back_threader::back_threader): Add
> > > > >   first argument.
> > > > >   (back_threader::debug_counter): New.
> > > > >   (back_threader::maybe_register_path): Call debug_counter.
> > > > OK
> > >
> > > But it's ugly.  Very.  Why isn't a single debug-counter good enough?
> > > You should be able to reduce to a single threading pass via
> > > -fdisable-tree-xyz and then bisect with the debug counter.
> >
> > Indeed.  I'm not a big fan either.
> >
> > The -fdisable-tree-xyz approach is my first line of defense, but
> > sometimes the problem is a combination of threading passes working in
> > tandem.  For example, thread1 threads a path that causes a later
> > thread99 pass to find another path.  So I can't just have one counter.
> > We need to be able to bisect the thread1 path, and then, if there's
> > still a problem, bisect the thread99 pass.
> >
> > I was fighting a bootstrap miscomparison bug when I could reduce the
> > problem to 2 threading passes, and then further to thread1's 123 path,
> > and thread2's 567 and 890 paths.  Not fun.
>
> Btw, you can now do -fdbg-cnt=thread:5:892-1 to continue
> bisecting the number space of thread2 after fixing '5' for thread1.

I think you meant -fdbg-cnt=thread:5-5:892-1, since just the 5 is
1-5 AFAICT.

>
> And -fdbg-cnt-list will tell you the upper bound of the counters
> (for the 1).
>
> But yes, not fun.  But really "bisecting" multiple counters at the same
> time doesn't work better than "bisecting" a single counter into
> multiple slices.

I find it easier to bisect using multiple counters, but if the general
consensus is that bisecting using a single counter and multiple slices
is easier, I'll switch it back.  However, I'd like to get some
feedback from the bugzilla gurus here, as they're doing most of the
heavy lifting here.

Martin, pinskia, do you have opinions here?

Aldy



[PATCH] Fix vsx_splat_v4si in 32 bit mode

2021-11-06 Thread David Edelsohn via Gcc-patches
powerpc: Fix vsx_splat_v4si in 32 bit mode

Tamar's recent patch to teach CSE to perform vector extract exercises
VSX splat more frequently, which exposed a constraint error for the
vsx_splat patterns.  The pattern could be created for Power9, but
the "we constraint only provided alternatives in 64 bit mode. The
instructions are valid in 32 bit mode and SImode is allowed in VSX
registers.  This patch updates the constraints from "we" to "wa" to
allow the pattern and fix the failing testcases.

Bootstrapped on powerpc-ibm-aix7.2.3.0.

gcc/ChangeLog:

* config/rs6000/vsx.md (vsx_splat_v4si): Change constraints to "wa".
(vsx_splat_v4si_di): Change constraint to "wa"

diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index 0bf04feb6c4..a97f7f2a680 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -4565,7 +4565,7 @@ (define_insn "vsx_splat__mem"

 ;; V4SI splat support
 (define_insn "vsx_splat_v4si"
-  [(set (match_operand:V4SI 0 "vsx_register_operand" "=we,we")
+  [(set (match_operand:V4SI 0 "vsx_register_operand" "=wa,wa")
(vec_duplicate:V4SI
 (match_operand:SI 1 "splat_input_operand" "r,Z")))]
   "TARGET_P9_VECTOR"
@@ -4578,7 +4578,7 @@ (define_insn "vsx_splat_v4si"
 ;; allows us to use direct move to get the value in a vector register
 ;; so that we can use XXSPLTW
 (define_insn "vsx_splat_v4si_di"
-  [(set (match_operand:V4SI 0 "vsx_register_operand" "=wa,we")
+  [(set (match_operand:V4SI 0 "vsx_register_operand" "=wa,wa")
(vec_duplicate:V4SI
 (truncate:SI
  (match_operand:DI 1 "gpc_reg_operand" "wa,r"]


Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1

2021-11-06 Thread Manfred Schwarb via Gcc-patches
Am 02.11.21 um 19:39 schrieb Thomas Koenig:
> On 02.11.21 15:22, Manfred Schwarb wrote:
>> Am 02.11.21 um 14:26 schrieb Thomas Koenig:
>>> Hi Manfred,
>>>
 In addition to the patches of Steve Kargl for PR 91497:
 The MIN1 and MAX1 intrinsics do explicit type conversions and should
 be silenced too for -Wconversion and -Wconversion-extra.

 Adjust testcase to only use *4 and *8 real types, provide a second
 testcase for *10 and *16 precisions.
>>> Two points:
>>>
>>> We should modify existing test cases only when necessary, because
>>> modification can impede a regression test.  It is better to create
>>> a new one.
>>>

I only changed the test case to use dg-require-effective-target and real(n) 
notation now.

Added a second case without real(10) and real(16), but for all targets, which
covers MIN1 and MAX1 too.


>>
>> Yes, but this was a quick-and-dirty test of mine, and I realized only 
>> afterwards
>> that Steve had used it as-is. The new testcase is more consistent and more 
>> complete.
>> Sandra got errors on targets without REAL(16) support and requested changes,
>> so I decided to split it.
>>
>> So you want me to "split" it in 3 parts?
>> - existing test as is, only for targets with REAL(16) support
>> - additional tests incl. complex intrinsics for targets with REAL(16) support
>> - additional tests incl. complex intrinsics for all targets, only single and 
>> double precision
>>
>> OTOH, it is perhaps not worth the trouble to do REAL(10) and REAL(16) tests, 
>> either
>> it warns or it does not.
>
> Anything that tests both complex and REAL(16) is fine by me.  I don't
> think you need to test the combination of COMPLEX(16), both
> codepaths have been seen by that time :-)
>
> Or you can split it three ways, like you wrote above.
>
>>> While we do recognize real*4 and real*8 and so on, these are
>>> non-standard extensions, and I would like to avoid to have these
>>> with new test cases.
>>>
>>> Instead of real*8, you can use real(8) or double precision.
>>>
>>
>> Well, double precision is deprecated AFAIK.
>
> Not in Fortran 2018.
>
> Best regards
>
>   Thomas
>

2021-11-06  Manfred Schwarb  

gcc/fortran/ChangeLog:

	PR fortran/91497
	* simplify.c (simplify_min_max): Disable conversion warnings for
	MIN1 and MAX1.

--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -5087,6 +5087,7 @@ min_max_choose (gfc_expr *arg, gfc_expr
 static gfc_expr *
 simplify_min_max (gfc_expr *expr, int sign)
 {
+  int tmp1, tmp2;
   gfc_actual_arglist *arg, *last, *extremum;
   gfc_expr *tmp, *ret;
   const char *fname;
@@ -5131,7 +5132,16 @@ simplify_min_max (gfc_expr *expr, int si
   if ((tmp->ts.type != BT_INTEGER || tmp->ts.kind != gfc_integer_4_kind)
   && (strcmp (fname, "min1") == 0 || strcmp (fname, "max1") == 0))
 {
+  /* Explicit conversion, turn off -Wconversion and -Wconversion-extra
+ warnings.  */
+  tmp1 = warn_conversion;
+  tmp2 = warn_conversion_extra;
+  warn_conversion = warn_conversion_extra = 0;
+
   ret = gfc_convert_constant (tmp, BT_INTEGER, gfc_integer_4_kind);
+
+  warn_conversion = tmp1;
+  warn_conversion_extra = tmp2;
 }
   else if ((tmp->ts.type != BT_REAL || tmp->ts.kind != gfc_real_4_kind)
 	   && (strcmp (fname, "amin0") == 0 || strcmp (fname, "amax0") == 0))
2021-11-06  Manfred Schwarb  

gcc/testsuite/ChangeLog:

	PR fortran/91497
	* gfortran.dg/pr91497.f90: Adjust test to use
	dg-require-effective-target directive.
	* gfortran.dg/pr91497_2.f90: New test to cover all targets.
	Cover MAX1 and MIN1 intrinsics.

--- a/gcc/testsuite/gfortran.dg/pr91497.f90
+++ b/gcc/testsuite/gfortran.dg/pr91497.f90
@@ -1,4 +1,6 @@
-! { dg-do compile { target { i?86-*-* x86_64-*-* } } }
+! { dg-do compile }
+! { dg-require-effective-target fortran_real_10 }
+! { dg-require-effective-target fortran_real_16 }
 ! { dg-options "-Wall" }
 ! Code contributed by Manfred Schwarb 
 ! PR fortran/91497
@@ -8,13 +10,13 @@
 !
 program foo

-  real*4 a,aa
-  real*8 b,bb
-  real*10 c,cc
-  real*16 d
-  integer*2 e,ee
-  integer*4 f,ff
-  integer*8 g,gg
+  real(4) a,aa
+  real(8) b,bb
+  real(10) c,cc
+  real(16) d
+  integer(2) e,ee
+  integer(4) f,ff
+  integer(8) g,gg
   PARAMETER(a=3.1415927_4)
   PARAMETER(b=3.1415927_8)
   PARAMETER(c=3.1415927_10)
@@ -36,11 +38,10 @@ program foo
   aa=CEILING(b)
   aa=CEILING(c)
   aa=CEILING(d)
-  !---unknown but documented type conversions:
+  !---DEC specific type conversions (-fdec):
   !!aa=FLOATI(e)
   !!aa=FLOATJ(f)
   !!aa=FLOATK(g)
-  !---documentation is wrong for sngl:
   aa=SNGL(c)
   aa=SNGL(d)
   bb=REAL(c, kind=8)
@@ -98,7 +99,7 @@ program foo
   ff=IFIX(a)
   ff=IDINT(b)
   ff=IDNINT(b)
-  !---LONG not allowed anymore in gfortran 10 (?):
+  !---LONG support got removed:
   !!ff=LONG(a)
   !!ff=LONG(b)
   !!ff=LONG(c)
--- 

[COMMITTED] path oracle: Do not look at root oracle for killed defs.

2021-11-06 Thread Aldy Hernandez via Gcc-patches
[This is more Andrew's domain, but this is a P1 PR and I'd like to
unbreak the SPEC run, since this is a straigthforward fix.  When he
returns he can double check my work and give additional suggestions.]

The problem here is that we are incorrectly threading 41->20->21 here:

   [local count: 56063504182]:
  _134 = M.10_120 + 1;
  if (_71 <= _134)
goto ; [11.00%]
  else
goto ; [89.00%]
...
...
...
   [local count: 49896518755]:

   [local count: 56063503181]:
  # lb_75 = PHI <_134(41), 1(18)>
  _117 = mstep_49 + lb_75;
  _118 = _117 + -1;
  _119 = mstep_49 + _118;
  M.10_120 = MIN_EXPR <_119, _71>;
  if (lb_75 > M.10_120)
goto ; [11.00%]
  else
goto ; [89.00%]

First, lb_17 == _134 because of the PHI.
Second, _134 > M.10_120 because of _134 = M.10_120 + 1.

We then assume that lb_75 > M.10_120, but this is incorrect because
M.10_120 was killed along the path.

This incorrect thread causes the miscompilation in 527.cam4_r.

Tested on x86-64 and ppc64le Linux.

Committed.

gcc/ChangeLog:

PR tree-optimization/103061
* value-relation.cc (path_oracle::path_oracle): Initialize
m_killed_defs.
(path_oracle::killing_def): Set m_killed_defs.
(path_oracle::query_relation): Do not look at the root oracle for
killed defs.
* value-relation.h (class path_oracle): Add m_killed_defs.
---
 gcc/value-relation.cc | 9 +
 gcc/value-relation.h  | 1 +
 2 files changed, 10 insertions(+)

diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc
index f1e46d38de1..a0105481466 100644
--- a/gcc/value-relation.cc
+++ b/gcc/value-relation.cc
@@ -1235,6 +1235,7 @@ path_oracle::path_oracle (relation_oracle *oracle)
   m_equiv.m_next = NULL;
   m_relations.m_names = BITMAP_ALLOC (_bitmaps);
   m_relations.m_head = NULL;
+  m_killed_defs = BITMAP_ALLOC (_bitmaps);
 }
 
 path_oracle::~path_oracle ()
@@ -1305,6 +1306,8 @@ path_oracle::killing_def (tree ssa)
 
   unsigned v = SSA_NAME_VERSION (ssa);
 
+  bitmap_set_bit (m_killed_defs, v);
+
   // Walk the equivalency list and remove SSA from any equivalencies.
   if (bitmap_bit_p (m_equiv.m_names, v))
 {
@@ -1389,6 +1392,12 @@ path_oracle::query_relation (basic_block bb, 
const_bitmap b1, const_bitmap b2)
 
   relation_kind k = m_relations.find_relation (b1, b2);
 
+  // Do not look at the root oracle for names that have been killed
+  // along the path.
+  if (bitmap_intersect_p (m_killed_defs, b1)
+  || bitmap_intersect_p (m_killed_defs, b2))
+return k;
+
   if (k == VREL_NONE && m_root)
 k = m_root->query_relation (bb, b1, b2);
 
diff --git a/gcc/value-relation.h b/gcc/value-relation.h
index 97be3251144..8086f5552b5 100644
--- a/gcc/value-relation.h
+++ b/gcc/value-relation.h
@@ -233,6 +233,7 @@ private:
   equiv_chain m_equiv;
   relation_chain_head m_relations;
   relation_oracle *m_root;
+  bitmap m_killed_defs;
 
   bitmap_obstack m_bitmaps;
   struct obstack m_chain_obstack;
-- 
2.31.1



Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-06 Thread François Dumont via Gcc-patches
You were right to delay your reply. Here is a new version with less code 
duplication and a bug fix in the new _UContMergeGuard where we were 
using it->second rather than it->first to get the key.


Note also that the change to _M_merge_multi implementation is also 
important because otherwise we might be trying to extract a key from a 
destructed node.


    libstdc++: [_GLIBCXX_DEBUG] Implement unordered container merge

    The _GLIBCXX_DEBUG unordered containers need a dedicated merge 
implementation
    so that any existing iterator on the transfered nodes is properly 
invalidated.


    Add typedef/using declaration for everything used as-is from normal 
implementation.


    libstdc++-v3/ChangeLog:

    * include/bits/hashtable_policy.h (__distance_fw): Replace 
class keyword with

    typename.
    * include/bits/hashtable.h (_Hashtable<>::_M_merge_unique): 
Remove noexcept

    qualification. Use const_iterator for node extraction/reinsert.
    (_Hashtable<>::_M_merge_multi): Likewise. Compute new hash 
code before extract.
    * include/debug/safe_container.h (_Safe_container<>): Make 
all methods

    protected.
    * include/debug/safe_unordered_container.h
(_Safe_unordered_container<>::_UContMergeGuard<_ExtractKey, _Source>): New.
(_Safe_unordered_container<>::_S_uc_guard<_ExtractKey, _Source>): New.
(_Safe_unordered_container<>::_UMContMergeGuard<_ExtractKey, _Source>): New.
(_Safe_unordered_container<>::_S_umc_guard<_ExtractKey, _Source>): New.
    (_Safe_unordered_container<>::_M_invalide_all): Make public.
    (_Safe_unordered_container<>::_M_invalide_if): Likewise.
(_Safe_unordered_container<>::_M_invalide_local_if): Likewise.
    * include/debug/unordered_map
    (unordered_map<>::mapped_type, pointer, const_pointer): New 
typedef.
    (unordered_map<>::reference, const_reference, 
difference_type): New typedef.
    (unordered_map<>::get_allocator, empty, size, max_size): 
Add usings.
    (unordered_map<>::bucket_count, max_bucket_count, bucket): 
Add usings.
    (unordered_map<>::hash_function, key_equal, count, 
contains): Add usings.

    (unordered_map<>::operator[], at, rehash, reserve): Add usings.
    (unordered_map<>::merge): New.
    (unordered_multimap<>::mapped_type, pointer, 
const_pointer): New typedef.
    (unordered_multimap<>::reference, const_reference, 
difference_type): New typedef.
    (unordered_multimap<>::get_allocator, empty, size, 
max_size): Add usings.
    (unordered_multimap<>::bucket_count, max_bucket_count, 
bucket): Add usings.
    (unordered_multimap<>::hash_function, key_equal, count, 
contains): Add usings.

    (unordered_multimap<>::rehash, reserve): Add usings.
    (unordered_multimap<>::merge): New.
    * include/debug/unordered_set
    (unordered_set<>::mapped_type, pointer, const_pointer): New 
typedef.
    (unordered_set<>::reference, const_reference, 
difference_type): New typedef.
    (unordered_set<>::get_allocator, empty, size, max_size): 
Add usings.
    (unordered_set<>::bucket_count, max_bucket_count, bucket): 
Add usings.
    (unordered_set<>::hash_function, key_equal, count, 
contains): Add usings.

    (unordered_set<>::rehash, reserve): Add usings.
    (unordered_set<>::merge): New.
    (unordered_multiset<>::mapped_type, pointer, 
const_pointer): New typedef.
    (unordered_multiset<>::reference, const_reference, 
difference_type): New typedef.
    (unordered_multiset<>::get_allocator, empty, size, 
max_size): Add usings.
    (unordered_multiset<>::bucket_count, max_bucket_count, 
bucket): Add usings.
    (unordered_multiset<>::hash_function, key_equal, count, 
contains): Add usings.

    (unordered_multiset<>::rehash, reserve): Add usings.
    (unordered_multiset<>::merge): New.
    * 
testsuite/23_containers/unordered_map/debug/merge1_neg.cc: New test.
    * 
testsuite/23_containers/unordered_map/debug/merge2_neg.cc: New test.
    * 
testsuite/23_containers/unordered_map/debug/merge3_neg.cc: New test.
    * 
testsuite/23_containers/unordered_map/debug/merge4_neg.cc: New test.
    * 
testsuite/23_containers/unordered_multimap/debug/merge1_neg.cc: New test.
    * 
testsuite/23_containers/unordered_multimap/debug/merge2_neg.cc: New test.
    * 
testsuite/23_containers/unordered_multimap/debug/merge3_neg.cc: New test.
    * 
testsuite/23_containers/unordered_multimap/debug/merge4_neg.cc: New test.
    * 
testsuite/23_containers/unordered_multiset/debug/merge1_neg.cc: New test.
    * 
testsuite/23_containers/unordered_multiset/debug/merge2_neg.cc: New test.
    * 
testsuite/23_containers/unordered_multiset/debug/merge3_neg.cc: New test.

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

2021-11-06 Thread Mikael Morin

Sorry, I hadn’t seen your message.

Le 05/11/2021 à 23:08, Bernhard Reutner-Fischer a écrit :

On Fri, 5 Nov 2021 19:46:16 +0100
Mikael Morin  wrote:


Le 29/10/2021 à 01:58, Bernhard Reutner-Fischer via Fortran a écrit :

On Wed, 27 Oct 2021 23:39:43 +0200
Bernhard Reutner-Fischer  wrote:
   

On Mon, 15 Oct 2018 10:23:06 +0200
Bernhard Reutner-Fischer  wrote:
  

If a finalization is not required we created a namespace containing
formal arguments for an internal interface definition but never used
any of these. So the whole sub_ns namespace was not wired up to the
program and consequently was never freed. The fix is to simply not
generate any finalization wrappers if we know that it will be unused.
Note that this reverts back to the original r190869
(8a96d64282ac534cb597f446f02ac5d0b13249cc) handling for this case
by reverting this specific part of r194075
(f1ee56b4be7cc3892e6ccc75d73033c129098e87) for PR fortran/37336.
  

I’m a bit concerned by the loss of the null_expr’s type interface.
I can’t convince myself that it’s either absolutely necessary or
completely useless.


It's a delicate spot, yes, but i do think they are completely useless.
If we do NOT need a finalization, the initializer can (and has to be
AFAIU) be a null_expr and AFAICS then does not need an interface.

Well, the null pointer itself doesn’t need a type, but I think it’s 
better if the pointer it’s assigned to has a type different from void*.

It will (hopefully) help the middle-end optimizers downstream.

I will see if I can manage to create a testcase where it makes a 
difference (don’t hold your breath, I don’t even have a bootstrapped 
compiler ready yet).




Don’t you get the same effect on the memory leaks if you keep just the
following hunk?


No, i don't think emitting the finalization-wrappers unconditionally is
correct. 

> (... lengthy explaination ...)
>
Agreed, it was a poor suggestion.



The rest of the changes (appart from class.c) are mostly OK with the nit
below and should be put in their own commit.

  >>> @@ -3826,10 +3828,8 @@ free_tb_tree (gfc_symtree *t)
  >>>
  >>> free_tb_tree (t->left);
  >>> free_tb_tree (t->right);
  >>> -
  >>> -  /* TODO: Free type-bound procedure structs themselves; probably
needs some
  >>> - sort of ref-counting mechanism.  */
  >>> free (t->n.tb);

Please keep a comment; it remains somehow valid but could be updated
maybe: gfc_typebound_proc’s u.generic field for example is nowhere freed
as far as I know.


Well that's a valid point, not sure where they are freed indeed.
Do you have a specific testcase in mind that leaks tbp's u.generic (or
specific for that matter) for me to look at?


Any testcase with generic typebound procedures, I guess.
typebound_generic_3.f03 for example seems like a good candidate.


I'm happy to change the comment to
TODO: Free type-bound procedure u.generic and u.specific fields
to reflect the current state. Ok?

I don’t think specific leaks because it’s one of gfc_namespace’s 
sym_root sub-nodes, and it’s freed with gfc_namespace.

OK without "and u.specific".


Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

2021-11-06 Thread Mikael Morin

Le 05/11/2021 à 19:46, Mikael Morin a écrit :
Don’t you get the same effect on the memory leaks if you keep just the 
following hunk?


 >>> @@ -1605,8 +1608,7 @@ generate_finalization_wrapper (gfc_symbol 
*derived, gfc_namespace *ns,

 >>> /* Set up the namespace.  */
 >>> sub_ns = gfc_get_namespace (ns, 0);
 >>> sub_ns->sibling = ns->contained;
 >>> -  if (!expr_null_wrapper)
 >>> -    ns->contained = sub_ns;
 >>> +  ns->contained = sub_ns;
 >>> sub_ns->resolved = 1;
 >>>
 >>> /* Set up the procedure symbol.  */



That’s probably not a good idea on second thought; it’s preferable to 
leak memory and not generate an empty finalization procedure.




Re: [PATCH] Fortran: Diagnose all operands/arguments with constraint violations

2021-11-06 Thread Mikael Morin

Le 05/11/2021 à 03:58, Sandra Loosemore a écrit :
This is an expanded version of the patch for PR 101337 that Bernhard 
sent out a few days ago with a request for me to finish it.  Bernhard 
did the part for operands and I added the pieces for procedure arguments 
and intrinsics, along with fixing up the test cases that were previously 
full of xfails and a few others that were now showing multiple 
diagnostics as a result of this change.


I suspect there might be other places where we are failing to check all 
subexpressions for errors, but this catches all the ones I wrote 
TS29113-related testcases for, at least.


OK to commit?



Ok. Thanks to both of you.

Mikael


Re: [PATCH] PR fortran/102715 - [12 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8184

2021-11-06 Thread Mikael Morin

Le 31/10/2021 à 22:35, Harald Anlauf via Fortran a écrit :

Dear Fortranners,

the fix for initialization of DT arrays caused an apparent regression for
cases where inconsistent ranks were used in such an initialization.
This caused either an ICE in subsequent uses of these arrays, or showed
up in valgrind as invalid reads, all of which seemed to be related to this
rank mismatch.

The cleanest solution seems to be to strictly reject rank mismatch earlier
than we used to, which helps error recovery.  I had to adjust one testcase
accordingly.

The place I inserted the check does not distinguish between explicit shape
and implied shape.  The Intel compiler does give a slightly different
error message for the implied shape case.  If anyone feels strongly about
this, I'm open to suggestions for better choices of handling this.

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



OK, thanks.

Mikael


Re: [PATCH] c++, dyninit: Optimize C++ dynamic initialization by constants into DECL_INITIAL adjustment [PR102876]

2021-11-06 Thread Jakub Jelinek via Gcc-patches
On Fri, Nov 05, 2021 at 11:06:44AM -0600, Martin Sebor wrote:
> In my work-in-progress patch to diagnose stores into constant
> objects (and subobjects) I deal with the same problem.  I had
> considered a pair of markers like those above (David Malcolm
> suggested a smilar approach as well), but decided to go
> a different route, not trusting they could be kept together,
> or that they wouldn't be viewed as overly intrusive.  With
> it, I have been able to distinguish dynamic initialization
> from overwriting stores even at the end of compilation, but
> I'd be fine changing that and running the detection earlier.
> 
> So if the markers are added for the purpose of optimizing
> the dynamic initialization at file scope, could they be added
> for those of locals as well?  That way I wouldn't need to add
> a separate solution.

I'm afraid not.  The ifns by pretending to read the corresponding
variables (and maybe they should be pretending to read from all
namespace scope global variables defined in the TU) prevent code motion of
stores across them and various other optimizations.
I'd hope it is acceptable for the global constructor functions because
those happen just once per process, never happen inside loops etc.
But for automatic or static block scope variables that would be way too
expensive.  We can't affort that.

Jakub



Re: [PATCH v1 5/7] LoongArch Port: libgomp

2021-11-06 Thread Xi Ruoyao via Gcc-patches
On Sat, 2021-11-06 at 16:40 +0800, Chenghua Xu wrote:
> From: chenglulu 
> 
> libgomp/
> 
> * configure.tgt: Add LoongArch tuple.

"tuple" should be "triplet".
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: Values of WIDE_INT_MAX_ELTS in gcc11 and gcc12 are different

2021-11-06 Thread Jakub Jelinek via Gcc-patches
On Fri, Nov 05, 2021 at 05:37:25PM +, Qing Zhao wrote:
> > On Nov 5, 2021, at 11:17 AM, Jakub Jelinek  wrote:
> > 
> > On Fri, Nov 05, 2021 at 04:11:36PM +, Qing Zhao wrote:
> >> 3076   if (TREE_CODE (TREE_TYPE (lhs)) != BOOLEAN_TYPE
> >> 3077   && tree_fits_uhwi_p (var_size)
> >> 3078   && (init_type == AUTO_INIT_PATTERN
> >> 3079   || !is_gimple_reg_type (var_type))
> >> 3080   && int_mode_for_size (tree_to_uhwi (var_size) * 
> >> BITS_PER_UNIT,
> >> 3081 0).exists ())
> >> 3082 {
> >> 3083   unsigned HOST_WIDE_INT total_bytes = tree_to_uhwi 
> >> (var_size);
> >> 3084   unsigned char *buf = (unsigned char *) xmalloc 
> >> (total_bytes);
> >> 3085   memset (buf, (init_type == AUTO_INIT_PATTERN
> >> 3086 ? INIT_PATTERN_VALUE : 0), total_bytes);
> >> 3087   tree itype = build_nonstandard_integer_type
> >> 3088  (total_bytes * BITS_PER_UNIT, 1);
> >> 
> >> The exact failing point is at function 
> >> “set_min_and_max_values_for_integral_type”:
> >> 
> >> 2851   gcc_assert (precision <= WIDE_INT_MAX_PRECISION);
> >> 
> >> For _Complex long double,  “precision” is 256.  
> >> In GCC11, “WIDE_INT_MAX_PRECISION” is 192,  in GCC12, it’s 512. 
> >> As a result, the above assertion failed on GCC11. 
> >> 
> >> I am wondering what’s the best fix for this issue in gcc11? 
> > 
> > Even for gcc 12 the above is wrong, you can't blindly assume that
> > build_nonstandard_integer_type will work for arbitrary precisions,
> > and even if it works that it will actually work.
> > The fact that such a mode exist is one thing, but
> > targetm.scalar_mode_supported_p should be tested for whether the mode
> > is actually supported.
> 
> You mean “int_mode_for_size().exists()” is not enough to make sure
> “build_nonstandard_integer_type” to be valid?  We should add
> “targetm.scalar_mode_supported_p” too ?

Yeah.  The former says whether the backend has that mode at all.
But some modes may be there only in some specific patterns but
without support for mov, add, etc.  Only for
targetm.scalar_mode_supported_p modes the backend guarantees that
one can use them e.g. in mode attribute and can expect expansion
to expand everything with that mode that is needed in some way.
E.g. only if targetm.scalar_mode_supported_p (TImode) the FEs
support __int128_t type, etc.

Jakub



Re: [PATCH v1 6/7] LoongArch Port: gcc/testsuite

2021-11-06 Thread Xi Ruoyao via Gcc-patches
On Sat, 2021-11-06 at 16:40 +0800, Chenghua Xu wrote:
> diff --git a/gcc/testsuite/gcc.dg/20020312-2.c
> b/gcc/testsuite/gcc.dg/20020312-2.c
> index 52c33d09b90..2e35d443a1d 100644
> --- a/gcc/testsuite/gcc.dg/20020312-2.c
> +++ b/gcc/testsuite/gcc.dg/20020312-2.c
> @@ -49,6 +49,8 @@ extern void abort (void);
>  # define PIC_REG "r20"
>  #elif defined(__mips__)
>  /* PIC register is $28, but is used even without -fpic.  */
> +#elif defined(__loongarch__)
> +/* PIC register is $r2, but is used even without -fpic.  */

It seems misleading: $r2 is the thread pointer, not the PIC register.

>  #elif defined(__MMIX__)
>  /* No pic register.  */
>  #elif defined(__mn10300__)

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: [PATCH v1 3/7] LoongArch Port: libgcc

2021-11-06 Thread Xi Ruoyao via Gcc-patches
On Sat, 2021-11-06 at 16:40 +0800, Chenghua Xu wrote:

/* snip */

> diff --git a/libgcc/config/loongarch/crti.S b/libgcc/config/loongarch/crti.S
> new file mode 100644
> index 000..bac029874b5
> --- /dev/null
> +++ b/libgcc/config/loongarch/crti.S
> @@ -0,0 +1,43 @@
> +/* Copyright (C) 2021 Free Software Foundation, Inc.
> +
> +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
> +.  */
> +
> +/* 4 slots for argument spill area.  1 for cpreturn, 1 for stack.
> +   Return spill offset of 8.  Aligned to 16 bytes for lp64.  */
> +
> +   .section .init,"ax",@progbits
> +   .globl  _init
> +   .type   _init,@function
> +_init:
> +   addi.d   $r3,$r3,-16
> +   st.d  $r1,$r3,8
> +   addi.d   $r3,$r3,16
> +   jirl$r0,$r1,0
> +
> +   .section .fini,"ax",@progbits
> +   .globl  _fini
> +   .type   _fini,@function
> +_fini:
> +   addi.d   $r3,$r3,-16
> +   st.d  $r1,$r3,8
> +   addi.d   $r3,$r3,16
> +   jirl$r0,$r1,0

There is some inconsistency of "tabs" or "spaces" between the
instruction and the operands.  Likewisely, other *.S files.

/* snip */

> diff --git a/libgcc/config/loongarch/linux-unwind.h 
> b/libgcc/config/loongarch/linux-unwind.h
> new file mode 100644
> index 000..8c9dfa56a6d
> --- /dev/null
> +++ b/libgcc/config/loongarch/linux-unwind.h
> @@ -0,0 +1,80 @@
> +/* DWARF2 EH unwinding support for LoongArch Linux.
> +   Copyright (C) 2021 Free Software Foundation, Inc.
> +
> +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 inhibit_libc
> +/* Do code reading to identify a signal frame, and set the frame
> +   state data appropriately.  See unwind-dw2.c for the structs.  */
> +
> +#include 
> +#include 
> +#include 
> +
> +#define MD_FALLBACK_FRAME_STATE_FOR loongarch_fallback_frame_state
> +
> +static _Unwind_Reason_Code
> +loongarch_fallback_frame_state (struct _Unwind_Context *context,
> +   _Unwind_FrameState *fs)
> +{
> +  u_int32_t *pc = (u_int32_t *) context->ra;
> +  struct sigcontext *sc;
> +  _Unwind_Ptr new_cfa;
> +  int i;
> +
> +  /* 03822c0b dli a7, 0x8b (sigreturn)  */
> +  /* 002b syscall 0  */
> +  if (pc[1] != 0x002b)
> +    return _URC_END_OF_STACK;
> +  if (pc[0] == 0x03822c0b)
> +    {
> +  struct rt_sigframe
> +  {
> +   siginfo_t info;
> +   ucontext_t uc;
> +  } *rt_ = context->cfa;
> +  sc = _->uc.uc_mcontext;
> +    }
> +  else
> +    return _URC_END_OF_STACK;
> +
> +  new_cfa = (_Unwind_Ptr) sc;
> +  fs->regs.cfa_how = CFA_REG_OFFSET;
> +  fs->regs.cfa_reg = __LIBGCC_STACK_POINTER_REGNUM__;
> +  fs->regs.cfa_offset = new_cfa - (_Unwind_Ptr) context->cfa;
> +
> +  for (i = 0; i < 32; i++)
> +    {
> +  fs->regs.reg[i].how = REG_SAVED_OFFSET;
> +  fs->regs.reg[i].loc.offset = (_Unwind_Ptr) & (sc->sc_regs[i]) - 
> new_cfa;

There shouldn't be a space between the unary & and its operand.  And the
braces around sc->sc_regs[i] seems unnecessary.

In this particular case, the space makes it really looking similar to a
bitwise and expression...


Re: [PATCH v1 0/7] Add LoongArch support.

2021-11-06 Thread Xi Ruoyao via Gcc-patches
On Sat, 2021-11-06 at 16:40 +0800, Chenghua Xu wrote:
> 
> This is a series of patch sets to support LoongArch.
> 
> The LoongArch architecture (LoongArch) is an Instruction Set
> Architecture (ISA) that has a Reduced Instruction Set Computer (RISC)
> style.
> The documents are on
> https://loongson.github.io/LoongArch-Documentation/README-EN.html
> 
> The ELF ABI Documents are on:
> https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
> 
> The binutils has been merged into trunk:
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=560b3fe208255ae909b4b1c88ba9c28b09043307

Congratulations!

> The ABI -mabi=name is still under discussion and may change in the
> next version, 
> the rest can be reviewed.
> 
> chenglulu (7):
>   LoongArch Port: gcc

The [PATCH 1/1] does not arrive at gcc-patches successfully.  I guess
it's because of some mail size limit issue...  According to
https://gcc.gnu.org/contribute.html:

> If the patch is too big or too mechanical, posting it gzipped or
> bzip2ed and uuencoded or encoded as a base64 MIME part is acceptable,
> as long as the ChangeLog is still posted as plain text.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


Re: [committed] Fortran: Add more documentation for mixed-language programming

2021-11-06 Thread Paul Richard Thomas via Gcc-patches
Hi Sandra,

Looks good to me.

Thanks

Paul


On Fri, 5 Nov 2021 at 21:13, Sandra Loosemore 
wrote:

> I was recently pinged about PR35276.  It's an old issue, but a couple of
> the concerns raised there haven't been fixed yet, so I've checked in
> this patch to fill in the gaps.
>
> -Sandra
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein


[PATCH v1 7/7] LoongArch Port: Regenerate configure

2021-11-06 Thread Chenghua Xu
From: chenglulu 

* config/picflag.m4: Default add build option '-fpic' for LoongArch.
* configure: Add LoongArch tuples.
* configure.ac: Like wise.
---
 config/picflag.m4 |  3 +++
 configure | 12 +++-
 configure.ac  | 10 +-
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/config/picflag.m4 b/config/picflag.m4
index 8b106f9af88..0aefcf619bf 100644
--- a/config/picflag.m4
+++ b/config/picflag.m4
@@ -44,6 +44,9 @@ case "${$2}" in
# sets the default TLS model and affects inlining.
$1=-fPIC
;;
+loongarch*-*-*)
+   $1=-fpic
+   ;;
 mips-sgi-irix6*)
# PIC is the default.
;;
diff --git a/configure b/configure
index 58979d6e3b1..fcdb8b3d1b9 100755
--- a/configure
+++ b/configure
@@ -3052,7 +3052,7 @@ case "${ENABLE_GOLD}" in
   # Check for target supported by gold.
   case "${target}" in
 i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-* \
-| aarch64*-*-* | tilegx*-*-* | mips*-*-* | s390*-*-*)
+| aarch64*-*-* | tilegx*-*-* | mips*-*-* | s390*-*-* | loongarch*-*-*)
  configdirs="$configdirs gold"
  if test x${ENABLE_GOLD} = xdefault; then
default_ld=gold
@@ -3638,6 +3638,9 @@ case "${target}" in
   i[3456789]86-*-*)
 libgloss_dir=i386
 ;;
+  loongarch*-*-*)
+libgloss_dir=loongarch
+;;
   m68hc11-*-*|m6811-*-*|m68hc12-*-*|m6812-*-*)
 libgloss_dir=m68hc11
 ;;
@@ -4022,6 +4025,11 @@ case "${target}" in
   wasm32-*-*)
 noconfigdirs="$noconfigdirs ld"
 ;;
+  loongarch*-*-linux*)
+;;
+  loongarch*-*-*)
+noconfigdirs="$noconfigdirs gprof"
+;;
 esac
 
 # If we aren't building newlib, then don't build libgloss, since libgloss
@@ -10083,6 +10091,8 @@ done
 
 
 
+
+
 # Generate default definitions for YACC, M4, LEX and other programs that run
 # on the build machine.  These are used if the Makefile can't locate these
 # programs in objdir.
diff --git a/configure.ac b/configure.ac
index 550e6993b59..8d1cf5eaf27 100644
--- a/configure.ac
+++ b/configure.ac
@@ -353,7 +353,7 @@ case "${ENABLE_GOLD}" in
   # Check for target supported by gold.
   case "${target}" in
 i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-* \
-| aarch64*-*-* | tilegx*-*-* | mips*-*-* | s390*-*-*)
+| aarch64*-*-* | tilegx*-*-* | mips*-*-* | s390*-*-* | loongarch*-*-*)
  configdirs="$configdirs gold"
  if test x${ENABLE_GOLD} = xdefault; then
default_ld=gold
@@ -899,6 +899,9 @@ case "${target}" in
   i[[3456789]]86-*-*)
 libgloss_dir=i386
 ;;
+  loongarch*-*-*)
+libgloss_dir=loongarch
+;;
   m68hc11-*-*|m6811-*-*|m68hc12-*-*|m6812-*-*)
 libgloss_dir=m68hc11
 ;;
@@ -1283,6 +1286,11 @@ case "${target}" in
   wasm32-*-*)
 noconfigdirs="$noconfigdirs ld"
 ;;
+  loongarch*-*-linux*)
+;;
+  loongarch*-*-*)
+noconfigdirs="$noconfigdirs gprof"
+;;
 esac
 
 # If we aren't building newlib, then don't build libgloss, since libgloss
-- 
2.27.0



[PATCH v1 6/7] LoongArch Port: gcc/testsuite

2021-11-06 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<::j>(); // { dg-error "" } 
   g<(void (A::*)()) ::f>(); // { dg-error "" "" { xfail c++11 } }
   h<(int A::*) ::i>(); // { dg-error "" "" { xfail c++11 } }
-  g<(void (A::*)()) ::f>(); // { dg-error "" "" { xfail { c++11 && { 
aarch64*-*-* arm*-*-* mips*-*-* } } } }
+  g<(void (A::*)()) ::f>(); // { dg-error "" "" { xfail { c++11 && { 
aarch64*-*-* arm*-*-* mips*-*-* loongarch*-*-* } } } }
   h<(int A::*) ::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..2e35d443a1d 100644
--- a/gcc/testsuite/gcc.dg/20020312-2.c
+++ b/gcc/testsuite/gcc.dg/20020312-2.c
@@ -49,6 +49,8 @@ extern void abort (void);
 # define PIC_REG "r20"
 #elif defined(__mips__)
 /* PIC register is $28, but is used even without -fpic.  */
+#elif defined(__loongarch__)
+/* PIC register is $r2, but is used even without -fpic.  */
 #elif defined(__MMIX__)
 /* No pic register.  */
 #elif defined(__mn10300__)
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 

[PATCH v1 5/7] LoongArch Port: libgomp

2021-11-06 Thread Chenghua Xu
From: chenglulu 

libgomp/

* configure.tgt: Add LoongArch tuple.
---
 libgomp/configure.tgt | 4 
 1 file changed, 4 insertions(+)

diff --git a/libgomp/configure.tgt b/libgomp/configure.tgt
index d4f1e741b5a..2cd7272fcd8 100644
--- a/libgomp/configure.tgt
+++ b/libgomp/configure.tgt
@@ -56,6 +56,10 @@ if test x$enable_linux_futex = xyes; then
config_path="linux/ia64 linux posix"
;;
 
+loongarch*-*-linux*)
+   config_path="linux posix"
+   ;;
+
 mips*-*-linux*)
config_path="linux/mips linux posix"
;;
-- 
2.27.0



[PATCH v1 4/7] LoongArch Port: Regenerate libgcc/configure.

2021-11-06 Thread Chenghua Xu
From: chenglulu 

---
 libgcc/configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/configure b/libgcc/configure
index 4919a56f518..150ea04cb3d 100755
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -5066,7 +5066,7 @@ $as_echo "$libgcc_cv_cfi" >&6; }
 # word size rather than the address size.
 cat > conftest.c <

[PATCH v1 3/7] LoongArch Port: libgcc

2021-11-06 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 |  26 +
 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 |   2 +
 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, 411 insertions(+), 1 deletion(-)
 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 168535b1780..11b0af6f409 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
 ;;
@@ -922,6 +938,16 @@ 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"
+   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..8f3ec599cbc
--- /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_RC_UP  0x200
+#define _FPU_RC_DOWN0x300

[PATCH v1 2/7] LoongArch Port: Regenerate gcc/configure.

2021-11-06 Thread Chenghua Xu
From: chenglulu 

---
 gcc/configure | 63 ++-
 1 file changed, 57 insertions(+), 6 deletions(-)

diff --git a/gcc/configure b/gcc/configure
index 920868bcd33..5044fc27e42 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -7759,6 +7759,9 @@ else
 mips*-*-*)
   enable_fixed_point=yes
   ;;
+loongarch*-*-*)
+  enable_fixed_point=yes
+  ;;
 *)
   { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: fixed-point is not 
supported for this target, ignored" >&5
 $as_echo "$as_me: WARNING: fixed-point is not supported for this target, 
ignored" >&2;}
@@ -19455,7 +19458,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19458 "configure"
+#line 19461 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -19561,7 +19564,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19564 "configure"
+#line 19567 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -25326,6 +25329,17 @@ foo:   data8   25
movlr24 = @tprel(foo#)'
tls_as_opt=--fatal-warnings
;;
+  loongarch*-*-*)
+conftest_s='
+   .section .tdata,"awT",@progbits
+x: .word 2
+   .text
+   la.tls.gd $a0,x
+   bl __tls_get_addr'
+   tls_first_major=0
+   tls_first_minor=0
+   tls_as_opt='--fatal-warnings'
+   ;;
   microblaze*-*-*)
 conftest_s='
.section .tdata,"awT",@progbits
@@ -28548,6 +28562,43 @@ $as_echo "#define HAVE_AS_MARCH_ZIFENCEI 1" 
>>confdefs.h
 fi
 
 ;;
+  loongarch*-*-*)
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for 
.dtprelword support" >&5
+$as_echo_n "checking assembler for .dtprelword support... " >&6; }
+if ${gcc_cv_as_loongarch_dtprelword+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  gcc_cv_as_loongarch_dtprelword=no
+  if test x$gcc_cv_as != x; then
+$as_echo '' > conftest.s
+if { ac_try='$gcc_cv_as $gcc_cv_as_flags 2,18,0 -o conftest.o conftest.s 
>&5'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }
+then
+   .section .tdata,"awT",@progbits
+x:
+   .word 2
+   .text
+   .dtprelword x+0x8000
+else
+  echo "configure: failed program was" >&5
+  cat conftest.s >&5
+fi
+rm -f conftest.o conftest.s
+  fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$gcc_cv_as_loongarch_dtprelword" >&5
+$as_echo "$gcc_cv_as_loongarch_dtprelword" >&6; }
+
+if test $gcc_cv_as_loongarch_dtprelword != yes; then
+
+$as_echo "#define HAVE_AS_DTPRELWORD 1" >>confdefs.h
+
+fi
+;;
 s390*-*-*)
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for 
.gnu_attribute support" >&5
 $as_echo_n "checking assembler for .gnu_attribute support... " >&6; }
@@ -28711,11 +28762,11 @@ fi
 ;;
 esac
 
-# Mips and HP-UX need the GNU assembler.
+# Mips, LoongArch and HP-UX need the GNU assembler.
 # Linux on IA64 might be able to use the Intel assembler.
 
 case "$target" in
-  mips*-*-* | *-*-hpux* )
+  mips*-*-* | loongarch*-*-* | *-*-hpux* )
 if test x$gas_flag = xyes \
|| test x"$host" != x"$build" \
|| test ! -x "$gcc_cv_as" \
@@ -29152,8 +29203,8 @@ esac
 # ??? Once 2.11 is released, probably need to add first known working
 # version to the per-target configury.
 case "$cpu_type" in
-  aarch64 | alpha | arc | arm | avr | bfin | cris | csky | i386 | m32c | m68k \
-  | microblaze | mips | nds32 | nios2 | pa | riscv | rs6000 | score | sparc \
+  aarch64 | alpha | arc | arm | avr | bfin | cris | csky | i386 | loongarch | 
m32c \
+  | m68k | microblaze | mips | nds32 | nios2 | pa | riscv | rs6000 | score | 
sparc \
   | tilegx | tilepro | visium | xstormy16 | xtensa)
 insn="nop"
 ;;
-- 
2.27.0



[PATCH v1 0/7] Add LoongArch support.

2021-11-06 Thread Chenghua Xu


This is a series of patch sets to support LoongArch.

The LoongArch architecture (LoongArch) is an Instruction Set
Architecture (ISA) that has a Reduced Instruction Set Computer (RISC)
style.
The documents are on
https://loongson.github.io/LoongArch-Documentation/README-EN.html

The ELF ABI Documents are on:
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html

The binutils has been merged into trunk:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=560b3fe208255ae909b4b1c88ba9c28b09043307

The ABI -mabi=name is still under discussion and may change in the next 
version, 
the rest can be reviewed.

chenglulu (7):
  LoongArch Port: gcc
  LoongArch Port: Regenerate gcc/configure.
  LoongArch Port: libgcc
  LoongArch Port: Regenerate libgcc/configure.
  LoongArch Port: libgomp
  LoongArch Port: gcc/testsuite
  LoongArch Port: Regenerate configure

 config/picflag.m4 |3 +
 configure |   12 +-
 configure.ac  |   10 +-
 .../config/loongarch/loongarch-common.c   |   63 +
 gcc/config.gcc|  248 +-
 gcc/config/host-linux.c   |2 +
 gcc/config/loongarch/constraints.md   |  212 +
 gcc/config/loongarch/generic.md   |  132 +
 gcc/config/loongarch/gnu-user.h   |   86 +
 gcc/config/loongarch/la464.md |  132 +
 gcc/config/loongarch/larchintrin.h|  413 ++
 gcc/config/loongarch/linux.h  |   57 +
 gcc/config/loongarch/loongarch-builtins.c |  511 ++
 gcc/config/loongarch/loongarch-c.c|  137 +
 gcc/config/loongarch/loongarch-cpu.c  |  182 +
 gcc/config/loongarch/loongarch-cpu.h  |   55 +
 gcc/config/loongarch/loongarch-cpucfg.h   |   29 +
 gcc/config/loongarch/loongarch-driver.c   |  201 +
 gcc/config/loongarch/loongarch-driver.h   |   49 +
 gcc/config/loongarch/loongarch-ftypes.def |   95 +
 gcc/config/loongarch/loongarch-modes.def  |   35 +
 gcc/config/loongarch/loongarch-opts.c |  311 +
 gcc/config/loongarch/loongarch-opts.h |  133 +
 gcc/config/loongarch/loongarch-protos.h   |  244 +
 gcc/config/loongarch/loongarch-rtx-cost.h |   80 +
 gcc/config/loongarch/loongarch.c  | 6485 +
 gcc/config/loongarch/loongarch.h  | 1292 
 gcc/config/loongarch/loongarch.md | 3836 ++
 gcc/config/loongarch/loongarch.opt|  206 +
 gcc/config/loongarch/predicates.md|  553 ++
 gcc/config/loongarch/sync.md  |  614 ++
 gcc/config/loongarch/t-linux  |   51 +
 gcc/config/loongarch/t-loongarch  |   46 +
 gcc/configure |   63 +-
 gcc/configure.ac  |   33 +-
 gcc/doc/invoke.texi   |  193 +
 gcc/doc/md.texi   |   55 +
 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 +
 libgcc/config.host|   26 +
 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|2 +
 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  |2 +-
 libgcc/configure.ac   |2 +-
 libgomp/configure.tgt |4 +
 63 files changed, 17343 insertions(+), 21 deletions(-)
 create mode 100644 gcc/common/config/loongarch/loongarch-common.c
 create mode 100644 gcc/config/loongarch/constraints.md
 create mode 100644 gcc/config/loongarch/generic.md
 create mode 100644 gcc/config/loongarch/gnu-user.h
 create mode 100644 gcc/config/loongarch/la464.md
 create mode 100644 gcc/config/loongarch/larchintrin.h
 create mode 100644 gcc/config/loongarch/linux.h
 create mode 100644 gcc/config/loongarch/loongarch-builtins.c
 create mode 100644 

Re: [PATCH] Add TSVC tests.

2021-11-06 Thread Martin Liška

Hello.

Sorry for issue related to portability.

On 11/6/21 03:45, David Edelsohn wrote:

I just noticed that Iain adjusted the tsvc.h for Darwin in the same
way that I need to adjust it for AIX.  Are we trying to keep the
testcase directory pristine and in sync with its upstream source or
can we fix it locally?


We can fix it locally as the source files are split from the original
all-in-one tsvc.c file.

Thanks,
Martin



Thanks, David

On Fri, Nov 5, 2021 at 8:24 PM David Edelsohn  wrote:


Hi, Martin

These testcases rely on memalign in tsvc.h.  memalign is provided in
Linux and Solaris, but is not part of Posix, and it is not available
in AIX.  Posix defines posix_memalign, which also is available in AIX.

Should the tsvc.h use posix_memalign?  Always?  Only when memalign is
not available?

Thanks, David