Re: [PATCH v3] Do not abort compilation when dump file is /dev/*

2021-11-20 Thread Alexandre Oliva via Gcc-patches
Hello, Giuliano, thanks for turning my suggestion into a patch!

On Nov 19, 2021, Richard Biener  wrote:

>> +/* { dg-options "-fdump-ipa-clones -o /dev/null" } */

May I suggest actually checking that the ipa-clones dump file is created
with the same name and the location it would without -o /dev/null?  I
think just using any of the normal dump file scanners would do.

There's a larger set of tests in gcc.misc/outputs.exp, where this test
would be a slightly better fit.  Copying some of the tests under
"Driver-chosen aux outputs", and some of the link tests that use
'$oaout', changing them to use -o /dev/null without any changes to the
expected output file names, would give us more coverage of expected
behavior than just checking that we just don't get an error.

Thanks again,

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 


Re: [PATCH] gfortran: Improve translation of POPPAR intrinsic

2021-11-20 Thread Bernhard Reutner-Fischer via Gcc-patches
Roger pinged this on gcc-patches some time ago fwiw.
[The commit-hooks will likely fix or ignore s/bext/next/ in his
mail-addr]


On Sun, 14 Jun 2020 23:39:32 +0100
"Roger Sayle"  wrote:

>  
> 
> The following patch to gfortran's trans-instrinsic.c tweaks the generic that
> is produced
> 
> for popcnt on integer(kind=16).  Currently, the double word popcnt is
> implemented as
> 
> parityll(hipart(x))^parityll(lopart(x)), but with this patch this is now
> translated as
> 
> parityll(hipart(x)^lopart(x)).  This will be just an aesthetic change once
> my tree-level
> 
> parity optimization patch of 12th June is reviewed and accepted, but
> generating the
> 
> more efficient form initially, avoids a tiny bit of garbage collection when
> the middle-end
> 
> cleans this up into its preferred form.The semantics/correctness of this
> 
> change are tested by the run-time tests in gfortran.dg/popcnt_poppar_2.F90
> 
>  
> 
> This patch has been tested with "make bootstrap" and "make -k check" on
> 
> x86_64-pc-linux-gnu with no regressions.  If approved, I'd very much
> 
> appreciate it if the (gfortran) reviewer could commit this change for me.
> 
>  
> 
> 2020-06-14  Roger Sayle  
> 
>  
> 
> * trans-intrinsic.c (gfc_conv_intrinsic_popcnt_poppar): Translate
> 
> poppar(kind=16) as parityll(hipart(x)^lopart(x)) instead of
> 
> parityll(hipart(x))^parityll(lopart(x)).
> 
>  
> 
>  
> 
> Thanks in advance,
> 
> Roger
> 
> --
> 
> Roger Sayle
> 
> NextMove Software
> 
> Cambridge, UK
> 
>  
> 

diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index fd88099..363874e 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -7153,35 +7153,39 @@ gfc_conv_intrinsic_popcnt_poppar (gfc_se * se, gfc_expr 
*expr, int parity)
 as 'long long'.  */
   gcc_assert (argsize == 2 * LONG_LONG_TYPE_SIZE);
 
-  func = builtin_decl_explicit (parity
-   ? BUILT_IN_PARITYLL
-   : BUILT_IN_POPCOUNTLL);
-
   /* Convert it to an integer, and store into a variable.  */
   utype = gfc_build_uint_type (argsize);
   arg = fold_convert (utype, arg);
   arg = gfc_evaluate_now (arg, >pre);
-
-  /* Call the builtin twice.  */
-  call1 = build_call_expr_loc (input_location, func, 1,
-  fold_convert (long_long_unsigned_type_node,
-arg));
-
-  arg2 = fold_build2_loc (input_location, RSHIFT_EXPR, utype, arg,
- build_int_cst (utype, LONG_LONG_TYPE_SIZE));
-  call2 = build_call_expr_loc (input_location, func, 1,
-  fold_convert (long_long_unsigned_type_node,
-arg2));
+  arg_type = long_long_unsigned_type_node;
 
   /* Combine the results.  */
   if (parity)
-   se->expr = fold_build2_loc (input_location, BIT_XOR_EXPR, result_type,
-   call1, call2);
+   {
+ /* Construct parityll (LOPART (arg) ^ HIPART (arg)) */
+ arg2 = fold_build2_loc (input_location, RSHIFT_EXPR, utype, arg,
+ build_int_cst (utype, LONG_LONG_TYPE_SIZE));
+ arg = fold_build2_loc (input_location, BIT_XOR_EXPR, arg_type,
+fold_convert (arg_type, arg),
+fold_convert (arg_type, arg2));
+ func = builtin_decl_explicit (BUILT_IN_PARITYLL);
+ argsize = LONG_LONG_TYPE_SIZE;
+   }
   else
-   se->expr = fold_build2_loc (input_location, PLUS_EXPR, result_type,
-   call1, call2);
-
-  return;
+   {
+ func = builtin_decl_explicit (BUILT_IN_POPCOUNTLL);
+
+ /* Call the builtin twice.  */
+ call1 = build_call_expr_loc (input_location, func, 1,
+  fold_convert (arg_type, arg));
+ arg2 = fold_build2_loc (input_location, RSHIFT_EXPR, utype, arg,
+ build_int_cst (utype, LONG_LONG_TYPE_SIZE));
+ call2 = build_call_expr_loc (input_location, func, 1,
+  fold_convert (arg_type, arg2));
+ se->expr = fold_build2_loc (input_location, PLUS_EXPR, result_type,
+ call1, call2);
+ return;
+   }
 }
 
   /* Convert the actual argument twice: first, to the unsigned type of the


Small tweak to modref pure/const discoverys

2021-11-20 Thread Jan Hubicka via Gcc-patches
Hi,
while looking into the PR I also improved debug output in ipa-modref and
fixed ignore_nondeterminism predicate: looping pures and cont are still
deterministic.

Bootstrapped/regtested x86_64-linux, comitted.

gcc/ChangeLog:

2021-11-21  Jan Hubicka  

PR ipa/103052
* ipa-modref.c (ignore_nondeterminism_p): Allow looping pure/cont.
(merge_call_side_effects): Improve debug output.

diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 57e2aa5d868..20810c74da5 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -923,8 +923,7 @@ record_access_p (tree expr)
 static bool
 ignore_nondeterminism_p (tree caller, int flags)
 {
-  if ((flags & (ECF_CONST | ECF_PURE))
-  && !(flags & ECF_LOOPING_CONST_OR_PURE))
+  if (flags & (ECF_CONST | ECF_PURE))
 return true;
   if ((flags & (ECF_NORETURN | ECF_NOTHROW)) == (ECF_NORETURN | ECF_NOTHROW)
   || (!opt_for_fn (caller, flag_exceptions) && (flags & ECF_NORETURN)))
@@ -1016,6 +1015,10 @@ merge_call_side_effects (modref_summary *cur_summary,
   && !(flags & ECF_LOOPING_CONST_OR_PURE))
 return changed;
 
+  if (dump_file)
+fprintf (dump_file, " - Merging side effects of %s\n",
+callee_node->dump_name ());
+
   if (!(flags & (ECF_CONST | ECF_NOVOPS | ECF_PURE))
   || (flags & ECF_LOOPING_CONST_OR_PURE))
 {
@@ -1061,8 +1064,7 @@ merge_call_side_effects (modref_summary *cur_summary,
 }
 
   if (dump_file)
-fprintf (dump_file, " - Merging side effects of %s with parm map:",
-callee_node->dump_name ());
+fprintf (dump_file, "   Parm map:");
 
   parm_map.safe_grow_cleared (gimple_call_num_args (stmt), true);
   for (unsigned i = 0; i < gimple_call_num_args (stmt); i++)


Fix looping flag discovery in ipa-pure-const

2021-11-20 Thread Jan Hubicka via Gcc-patches
Hi,
The testcase shows situation where there is non-trivial cycle in the callgraph
involving a noreturn call.  This cycle is important for const function discovery
but not important for pure.  IPA pure const uses same strongly connected
components for both propagations which makes it to get suboptimal result
(does not detect the pure flag). However local pure const gets the situation
right becaue it processes functions in right order.  This hits rarely
executed code in propagate_pure_const that merge results with previously
known state that has long standing bug in it that makes it to throw away
the looping flag.

Bootstrapped/regtested x86_64-linux. Comitted.

gcc/ChangeLog:

2021-11-21  Jan Hubicka  

PR ipa/103052
* ipa-pure-const.c (propagate_pure_const): Fix merging of loping flag.

gcc/testsuite/ChangeLog:

2021-11-21  Jan Hubicka  

PR ipa/103052
* gcc.c-torture/execute/pr103052.c: New test.

diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index a332940b55d..fea8b08c4eb 100644
--- a/gcc/ipa-pure-const.c
+++ b/gcc/ipa-pure-const.c
@@ -1782,9 +1782,9 @@ propagate_pure_const (void)
  if (w_l->state_previously_known != IPA_NEITHER
  && this_state > w_l->state_previously_known)
{
-  this_state = w_l->state_previously_known;
  if (this_state == IPA_NEITHER)
-   this_looping = w_l->looping_previously_known;
+   this_looping = w_l->looping_previously_known;
+ this_state = w_l->state_previously_known;
}
  if (!this_looping && self_recursive_p (w))
this_looping = true;
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr103052.c 
b/gcc/testsuite/gcc.c-torture/execute/pr103052.c
new file mode 100644
index 000..bef8674a43c
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr103052.c
@@ -0,0 +1,35 @@
+static void js_error(void);
+static int top;
+static void js_throw(void)
+{
+   __builtin_exit(0);
+}
+
+// LOCATION A -- if js_pop is here, the bug is present
+static void js_pop(void)
+{
+   if (++top > 100)
+   js_error();
+}
+
+static void jsC_error(const char *v)
+{
+   if (v[0] == 0)
+   js_error();
+   js_throw();
+}
+static void checkfutureword(const char *exp)
+{
+   if (!__builtin_strcmp(exp, "const"))
+   jsC_error("boom");
+}
+static void js_error(void) {
+   checkfutureword("foo");
+   checkfutureword("bar");
+   js_pop();
+}
+int main(void)
+{
+   checkfutureword("const");
+   __builtin_abort ();
+}


Re: [PATCH] libgccjit: Add support for TLS variable [PR95415]

2021-11-20 Thread Antoni Boucher via Gcc-patches
Hi.
Here's the updated patch.
See comments below.
Thanks for your reviews!

Le jeudi 20 mai 2021 à 16:11 -0400, David Malcolm a écrit :
> On Tue, 2021-05-18 at 20:43 -0400, Antoni Boucher via Gcc-patches
> wrote:
> > Hello.
> > This patch adds support for TLS variables.
> > One thing to fix before we merge it is the libgccjit.map file which
> > contains LIBGCCJIT_ABI_16 instead of LIBGCCJIT_ABI_17.
> > LIBGCCJIT_ABI_16 was added in one of my other patches.
> > Thanks for the review.
> 
> > diff --git a/gcc/jit/docs/topics/compatibility.rst
> > b/gcc/jit/docs/topics/compatibility.rst
> > index 239b6aa1a92..d10bc1df080 100644
> > --- a/gcc/jit/docs/topics/compatibility.rst
> > +++ b/gcc/jit/docs/topics/compatibility.rst
> > @@ -243,3 +243,12 @@ embedding assembler instructions:
> >    * :func:`gcc_jit_extended_asm_add_input_operand`
> >    * :func:`gcc_jit_extended_asm_add_clobber`
> >    * :func:`gcc_jit_context_add_top_level_asm`
> > +
> > +.. _LIBGCCJIT_ABI_17:
> > +
> > +``LIBGCCJIT_ABI_17``
> > +---
> > +``LIBGCCJIT_ABI_17`` covers the addition of an API entrypoint to set
> > the
> > +thread-local storage model of a variable:
> > +
> > +  * :func:`gcc_jit_lvalue_set_tls_model`
> 
> Sorry about the delay in reviewing patches.
> 
> Is there a summary somewhere of the various outstanding patches and
> their associated ABI versions?  Are there dependencies between the
> patches?

The list of patches is there:
https://github.com/antoyo/libgccjit-patches but I don't keep them up-
to-date.
If that would help you, I could add a README to tell what is the new
ABI version for each patch.
I believe there might be some patches that depend on a previous one.

> 
> > diff --git a/gcc/jit/docs/topics/expressions.rst
> b/gcc/jit/docs/topics/expressions.rst
> > index 396259ef07e..68defd6a311 100644
> > --- a/gcc/jit/docs/topics/expressions.rst
> > +++ b/gcc/jit/docs/topics/expressions.rst
> > @@ -539,6 +539,34 @@ where the rvalue is computed by reading from
> > the storage area.
> >  
> >     in C.
> >  
> > +.. function:: void\
> > +  gcc_jit_lvalue_set_tls_model (gcc_jit_lvalue
> > *lvalue,\
> > +    enum gcc_jit_tls_model
> > model)
> > +
> > +   Make a variable a thread-local variable.
> > +
> > +   The "model" parameter determines the thread-local storage model
> > of the "lvalue":
> > +
> > +   .. type:: enum gcc_jit_tls_model
> > +
> > +   .. c:macro:: GCC_JIT_TLS_MODEL_GLOBAL_DYNAMIC
> > +
> > +   .. c:macro:: GCC_JIT_TLS_MODEL_LOCAL_DYNAMIC
> > +
> > +   .. c:macro:: GCC_JIT_TLS_MODEL_INITIAL_EXEC
> > +
> > +   .. c:macro:: GCC_JIT_TLS_MODEL_LOCAL_EXEC
> > +
> > +   .. c:macro:: GCC_JIT_TLS_MODEL_DEFAULT
> > +
> > +   This is analogous to:
> > +
> > +   .. code-block:: c
> > +
> > + _Thread_local int foo;
> > +
> > +   in C.
> 
> This comment needs the usual "This entrypoint was added in" text to
> state which API version it was added in.
> 
> I confess to being a bit hazy on the different TLS models, and it's
> unclear to me what all the different enum values do.  Is this
> equivalent to the various values for
> __attribute__((tls_model(VALUE)))
> ?  This attribute is documented in
> https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html,
> though sadly that document doesn't seem to have a good anchor for
> that
> attribute.

Yes, it is the equivalent of this attribute.

> 
> https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html currently links
> to
> https://www.akkadia.org/drepper/tls.pdf "for a detailed explanation
> of
> the four thread-local storage addressing models, and how the runtime
> is
> expected to function."
> 
> One thing that should be clarified: does GCC_JIT_TLS_MODEL_DEFAULT
> mean
> (a) thread-local storage, using a default model, or
> (b) non-thread-local storage i.e. normal storage.
> 
> ?
> 
> Reading the docs I thought it meant (a), but when I looked in more
> detail at the implementation it looks like it means (b); is it meant
> to?  This needs clarifying.
> 
> Are you using all of these enum values in your code?  Is this
> something
> you need to expose for the rustc backend?

Yes, I use all of these enum values in the rustc gcc codegen.

> 
> 
> >  Global variables
> >  
> >  
> > diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
> > index 825a3e172e9..654a9c472d4 100644
> > --- a/gcc/jit/jit-playback.h
> > +++ b/gcc/jit/jit-playback.h
> > @@ -650,6 +650,8 @@ public:
> >  
> >  private:
> >    context *m_ctxt;
> > +
> > +protected:
> >    tree m_inner;
> >  };
> 
> As noted in another review, I don't think you need to make this
> protected...
> 
> >  
> > @@ -670,6 +672,12 @@ public:
> >    rvalue *
> >    get_address (location *loc);
> >  
> > +  void
> > +  set_tls_model (enum tls_model tls_model)
> > +  {
> > +    set_decl_tls_model (m_inner, tls_model);
> > +  }
> 
> ...as I think you can use "as_tree ()" to get at m_inner here.
> 
> 
> > diff --git 

*PING* [PATCH] PR fortran/99061 - [10/11/12 Regression] ICE in gfc_conv_intrinsic_atan2d, at fortran/trans-intrinsic.c:4728

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

Early ping.

Am 15.11.21 um 22:38 schrieb Harald Anlauf via Fortran:

Dear Fortranners,

the attached patch fixes the handling of the DEC trigonometric intrinsics
for different argument kinds.  It is based on the original patch by Steve,
which fixes the lookup for the needed intrinsics.

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

Thanks,
Harald





Re: [PATCH] libgccjit: Add support for types used by atomic builtins [PR96066] [PR96067]

2021-11-20 Thread David Malcolm via Gcc-patches
On Sat, 2021-11-20 at 11:27 -0500, Antoni Boucher wrote:
> Hi.
> Here's the updated patch.
> Thanks for the review!

Thanks for the updated patch...

> 
> Le jeudi 20 mai 2021 à 16:24 -0400, David Malcolm a écrit :
> > On Mon, 2021-05-17 at 21:02 -0400, Antoni Boucher via Jit wrote:
> > > Hello.
> > > This patch fixes the issue with using atomic builtins in libgccjit.
> > > Thanks to review it.
> > 
> > [...snip...]
> >  
> > > diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
> > > index 117ff70114c..de876ff9fa6 100644
> > > --- a/gcc/jit/jit-recording.c
> > > +++ b/gcc/jit/jit-recording.c
> > > @@ -2598,8 +2598,18 @@
> > > recording::memento_of_get_pointer::accepts_writes_from (type
> > > *rtype)
> > >  return false;
> > >  
> > >    /* It's OK to assign to a (const T *) from a (T *).  */
> > > -  return m_other_type->unqualified ()
> > > -    ->accepts_writes_from (rtype_points_to);
> > > +  if (m_other_type->unqualified ()
> > > +    ->accepts_writes_from (rtype_points_to)) {
> > > +  return true;
> > > +  }
> > > +
> > > +  /* It's OK to assign to a (volatile const T *) from a (volatile
> > > const T *). */
> > > +  if (m_other_type->unqualified ()->unqualified ()
> > > +    ->accepts_writes_from (rtype_points_to->unqualified ())) {
> > > +  return true;
> > > +  }
> > 
> > Presumably you need this to get the atomic builtins working?
> > 
> > If I'm reading the above correctly, the new test doesn't distinguish
> > between the 3 different kinds of qualifiers (aligned, volatile, and
> > const), it merely tries to strip some of them off.
> > 
> > It's not valid to e.g. assign to a (aligned T *) from a (const T *).
> > 
> > Maybe we need an internal enum to discriminate between different
> > subclasses of decorated_type?

I'm still concerned about this case, my reading of the updated patch is
that this case is still not quite correctly handled (see notes below).
I don't think we currently have test coverage for assignment to e.g.
(aligned T *) from a (const T*); I feel that it should be an error,
without an explicit cast.

Please can you add a testcase for this?

If you want to go the extra mile, given that this is code created
through an API, you could have a testcase that iterates through all
possible combinations of qualifiers (for both source and destination
pointer), and verifies that libgccjit at least doesn't crash on them
(and hopefully does the right thing on each one)  :/

(perhaps doing each one in a different gcc_jit_context)

Might be nice to update test-fuzzer.c for the new qualifiers; I don't
think I've touched it in a long time.

[...snip...]

> diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
> index 4a994fe7094..60aaba2a246 100644
> --- a/gcc/jit/jit-recording.h
> +++ b/gcc/jit/jit-recording.h
> @@ -545,6 +545,8 @@ public:
>virtual bool is_float () const = 0;
>virtual bool is_bool () const = 0;
>virtual type *is_pointer () = 0;
> +  virtual type *is_volatile () { return NULL; }
> +  virtual type *is_const () { return NULL; }
>virtual type *is_array () = 0;
>virtual struct_ *is_struct () { return NULL; }
>virtual bool is_void () const { return false; }
> @@ -687,6 +689,13 @@ public:
>/* Strip off the "const", giving the underlying type.  */
>type *unqualified () FINAL OVERRIDE { return m_other_type; }
>  
> +  virtual bool is_same_type_as (type *other)
> +  {
> +return m_other_type->is_same_type_as (other->is_const ());
> +  }

What happens if other_is_const () returns NULL, and
  m_other_type->is_same_type_as ()
tries to call a vfunc on it...

> +
> +  virtual type *is_const () { return m_other_type; }
> +
>void replay_into (replayer *) FINAL OVERRIDE;
>  
>  private:
> @@ -701,9 +710,16 @@ public:
>memento_of_get_volatile (type *other_type)
>: decorated_type (other_type) {}
>  
> +  virtual bool is_same_type_as (type *other)
> +  {
> +return m_other_type->is_same_type_as (other->is_volatile ());
> +  }

...with similar considerations here.

i.e. is it possible for the user to create combinations of qualifiers
that lead to a vfunc call with NULL "this" (and thus a segfault?)

> +
>/* Strip off the "volatile", giving the underlying type.  */
>type *unqualified () FINAL OVERRIDE { return m_other_type; }
>  
> +  virtual type *is_volatile () { return m_other_type; }
> +
>void replay_into (replayer *) FINAL OVERRIDE;
>  

Hope this is constructive
Dave



Re: [PATCH] libgccjit: Add support for setting the link section of global variables [PR100688]

2021-11-20 Thread David Malcolm via Gcc-patches
On Sat, 2021-11-20 at 11:53 -0500, Antoni Boucher wrote:
> Hi.
> Here's the updated patch.
> See comments below.
> Thanks for the review!

> 
> Le samedi 20 novembre 2021 à 11:20 -0500, David Malcolm a écrit :
> > On Sat, 2021-11-20 at 00:58 -0500, Antoni Boucher wrote:

[...snip...]


> > 
> > 
> > > > > diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > > b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > > > index 4202eb7798b..7e3b59dee0d 100644
> > > > > --- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > > > +++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > > > @@ -181,6 +181,13 @@
> > > > >  #undef create_code
> > > > >  #undef verify_code
> > > > >  
> > > > > +/* test-link-section.c */
> > > > > +#define create_code create_code_link_section
> > > > > +#define verify_code verify_code_link_section
> > > > > +#include "test-link-section.c"
> > > > > +#undef create_code
> > > > > +#undef verify_code
> > 
> > The updated version of the testcase doesn't have a verify_code, so it
> > can't be in the "testcases" array.  
> > Please replace this with something like:
> > 
> > 
> > /* test-link-section.c: This can't be in the testcases array as it
> >    doesn't have a verify_code implementation.  */
> >  
> > 
> > (I'm trying to have all-nonfailing-tests.h refer to each non-failing
> > test, either adding it to the testcases array, or documenting why it
> > isn't in the array; listing them in alphabetical order)
> 
> Hum, that code seems to refer to the previous patch.
> I removed that part and changed the test to test-link-section-
> assembler.c which checks that the assembly contains the link section.
> As far as I know, it does not need to be listed here to be ran.

Right, it's just a comment.  It's not to be run here, I'm just trying
to document those tests that aren't being as part of the
threads/combination tests, since it's so easy to accidentally omit them
when adding a new test - ideally all-non-failing-tests.h will mention
all of the tests that don't have "error" in their titles, either adding
them to the "testcases" array, or documenting why they're not in the
array, with a comment like the one I suggested above (feel free to
directly use that).

[...snip...]

> > 
> > Overall the patch looks good, my comments are all just nit-picks at
> > this point, except that obviously you need to finish updating the
> > symbol name to "section_name" in gcc_jit_lvalue_set_link_section so
> > that it compiles.  Please check it compiles and that the testsuite
> > passes before pushing - though I think this is waiting on another
> > patch, right?  This is OK for trunk, once those fixes and
> > prerequisites
> > are taken care of.
> > 
> > Thanks again
> > Dave

Looks good for trunk, once the earlier patch is in.  As before, please
do a test build and run the testsuite before pushing.

Thanks for the updated patch.
Dave



[wwwdocs] Document some new C++ features in GCC 12

2021-11-20 Thread Marek Polacek via Gcc-patches
Pushed.
---
 htdocs/gcc-12/changes.html | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 5f0214bd..43fc5bc0 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -166,6 +166,11 @@ a work-in-progress.
   Several C++23 features have been implemented:
 
   P1938R3, if consteval
+  P0849R8, auto(x): decay-copy in the language
+  P2242R3, Non-literal variables (and labels and gotos) in constexpr 
functions
+  P2334R1, Support for preprocessing directives elifdef 
and
+ elifndef
+  P2360R0, Extend init-statement to allow 
alias-declaration
   DR 2397, auto specifier for pointers and references to 
arrays
 
   
@@ -175,6 +180,8 @@ a work-in-progress.
   DR 2397, auto specifier for pointers and references to 
arrays
 
   
+  -Wuninitialized warns about using uninitialized variables in
+  member initializer lists
 
 
 Runtime Library (libstdc++)

base-commit: f3c71720ba8ec2a5b44f038d0dd649037bffadf4
-- 
2.33.1



Re: [PATCH] libgccjit: Add support for setting the link section of global variables [PR100688]

2021-11-20 Thread Antoni Boucher via Gcc-patches
Hi.
Here's the updated patch.
See comments below.
Thanks for the review!

Le samedi 20 novembre 2021 à 11:20 -0500, David Malcolm a écrit :
> On Sat, 2021-11-20 at 00:58 -0500, Antoni Boucher wrote:
> > Thanks for your reviews!
> > 
> > Here's the updated patch, ready for another review.
> > See comments/questions below.
> 
> Thanks for the updated patch...
> 
> > 
> > I'll update the other patches over the weekend.
> > 
> > Le jeudi 20 mai 2021 à 15:29 -0400, David Malcolm a écrit :
> > > On Wed, 2021-05-19 at 20:32 -0400, Antoni Boucher via Jit wrote:
> > > > Hello.
> > > > This patch adds support to set the link section of global
> > > > variables.
> > > > I used the ABI 18 because I submitted other patches up to 17.
> > > > Thanks for the review.
> > > 
> > > I didn't see this email until now, and put the review in bugzilla
> > > instead; sorry.
> > > 
> > > Here's a copy-and-paste of what I put in bugzilla:
> > > 
> > > 
> > > Thanks for the patch; I like the idea; various nits below:
> > > 
> 
> [...snip...]
> 
> > > 
> > > >  Global variables
> > > >  
> > > >  
> > > > diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
> > > > index 825a3e172e9..8b0f65e87e8 100644
> > > > --- a/gcc/jit/jit-playback.h
> > > > +++ b/gcc/jit/jit-playback.h
> > > > @@ -650,6 +650,8 @@ public:
> > > >  
> > > >  private:
> > > >    context *m_ctxt;
> > > > +
> > > > +protected:
> > > >    tree m_inner;
> > > >  };
> > > 
> > > I think you only use this...
> > > 
> > > >  
> > > > @@ -670,6 +672,12 @@ public:
> > > >    rvalue *
> > > >    get_address (location *loc);
> > > >  
> > > > +  void
> > > > +  set_link_section (const char* name)
> > > > +  {
> > > > +    set_decl_section_name (m_inner, name);
> > > > +  }
> > > 
> > > ...here, and you can get at rvalue::m_inner using as_tree (), so
> > > I
> > > don't think we need to make m_inner protected.
> 
> Thanks for dropping the "protected" in the updated patch; you need to
> update the ChangeLog entry.
> 
> > > 
> > > 
> > > > +  set_playback_obj (global);
> > > >  }
> > > >  
> > > 
> > > [...snip]
> > > 
> > > > diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
> > > > index 03fa1160cf0..0691fac579d 100644
> > > > --- a/gcc/jit/jit-recording.h
> > > > +++ b/gcc/jit/jit-recording.h
> > > > @@ -1105,7 +1105,8 @@ public:
> > > >    lvalue (context *ctxt,
> > > >   location *loc,
> > > >   type *type_)
> > > > -    : rvalue (ctxt, loc, type_)
> > > > +    : rvalue (ctxt, loc, type_),
> > > > +  m_link_section(NULL)
> > > >  {}
> > > >  
> > > >    playback::lvalue *
> > > > @@ -1127,6 +1128,10 @@ public:
> > > >    const char *access_as_rvalue (reproducer ) OVERRIDE;
> > > >    virtual const char *access_as_lvalue (reproducer );
> > > >    virtual bool is_global () const { return false; }
> > > > +  void set_link_section (const char *name);
> > > > +
> > > > +protected:
> > > > +  string *m_link_section;
> > > >  };
> > > 
> > > Can it be private, rather than protected?
> > 
> > m_link_section can't be private because it's used in
> > recording::global::replay_into.
> 
> Fair enough; thanks.
> 
> > > 
> > > > diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
> > > > index 7fa948007ad..8cfa48aae24 100644
> > > > --- a/gcc/jit/libgccjit.c
> > > > +++ b/gcc/jit/libgccjit.c
> > > > @@ -1953,6 +1953,18 @@ gcc_jit_lvalue_get_address
> > > > (gcc_jit_lvalue
> > > *lvalue,
> > > >    return (gcc_jit_rvalue *)lvalue->get_address (loc);
> > > >  }
> > > >  
> > > > +/* Public entrypoint.  See description in libgccjit.h.
> > > > +
> > > > +   After error-checking, the real work is done by the
> > > > +   gcc::jit::recording::lvalue::set_section method in jit-
> > > recording.c.  */
> > >    ^^^
> > >    set_link_section
> > > 
> > > Also, a newline here please for consistency with the other
> > > entrypoints.
> > 
> > Where should I add a newline?
> 
> Between the closing of the comment and the "void" of the fndecl (all
> the other entrypoints have a blank line separating them).  Thanks for
> fixing my other nitpicks.
> 
> 
> [...snip...]
> 
> > > > diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > > index 4202eb7798b..7e3b59dee0d 100644
> > > > --- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > > +++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > > @@ -181,6 +181,13 @@
> > > >  #undef create_code
> > > >  #undef verify_code
> > > >  
> > > > +/* test-link-section.c */
> > > > +#define create_code create_code_link_section
> > > > +#define verify_code verify_code_link_section
> > > > +#include "test-link-section.c"
> > > > +#undef create_code
> > > > +#undef verify_code
> 
> The updated version of the testcase doesn't have a verify_code, so it
> can't be in the "testcases" array.  
> Please replace this with something like:
> 
> 
> /* test-link-section.c: This 

Re: [PATCH] Tweak tree-ssa-math-opts.c to solve PR target/102117

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




On 11/20/2021 6:14 AM, Roger Sayle wrote:

This patch resolves PR target/102117 on s390.  The problem is that
some of the functionality of GCC's RTL expanders is no longer triggered
following the transition to tree SSA form.  On s390, unsigned widening
multiplications are converted into WIDEN_MULT_EXPR (aka w* in tree dumps),
but signed widening multiplies are left in their original form, which
alas doesn't benefit from the clever logic in expand_widening_mult.

The fix is to teach convert_mult_to_widen, that RTL expansion can
synthesize a signed widening multiplication if the target provides
a suitable umul_widen_optab.

On s390-linux-gnu with -O2 -m64, the code in the bugzilla PR currently
generates:

imul128:
 stmg%r12,%r13,96(%r15)
 srag%r0,%r4,63
 srag%r1,%r3,63
 lgr %r13,%r3
 mlgr%r12,%r4
 msgr%r1,%r4
 msgr%r0,%r3
 lgr %r4,%r12
 agr %r1,%r0
 lgr %r5,%r13
 agr %r4,%r1
 stmg%r4,%r5,0(%r2)
 lmg %r12,%r13,96(%r15)
 br  %r14

but with this patch should now generate the more efficient:

imul128:
 lgr %r1,%r3
 mlgr%r0,%r4
 srag%r5,%r3,63
 ngr %r5,%r4
 srag%r4,%r4,63
 sgr %r0,%r5
 ngr %r4,%r3
 sgr %r0,%r4
 stmg%r0,%r1,0(%r2)
 br  %r14


This patch has been tested s390/z13 with a bootstrap and a regression
test (thanks to Robin Dapp), and on x86_64-pc-linux-gnu with a bootstrap
and regression test just to confirm that there are no unanticipated
side-effects.

Ok for mainline?


2021-11-20  Roger Sayle  
 Robin Dapp  

gcc/ChangeLog
PR target/102117
* tree-ssa-math-opts.c (convert_mult_to_widen): Recognize
signed WIDEN_MULT_EXPR if the target supports umul_widen_optab.

gcc/testsuite/ChangeLog
PR target/102117
* gcc.target/s390/mul-wide.c: New test case.
* gcc.target/s390/umul-wide.c: New test case.

OK
jeff



[committed][PR tree-optimization103226] Clobber the condition code in the bfin doloop patterns

2021-11-20 Thread Jeff Law via Gcc-patches
Per Aldy's excellent, but tough to follow analysis in PR 103226, this 
patch fixes the bfin-elf regression.


In simplest terms the doloop patterns on this port may clobber the 
condition code register, but they do not expose that until after 
register allocation.  That would be fine, except that other patterns 
have exposed CC earlier.  As a result the dataflow, particularly for CC, 
is incorrect.


This leads the register allocators to assume that a value in CC outside 
the loop is still valid inside the loop when in fact, the value has been 
clobbered.  This is what caused pr80974 to start failing.


With this fix, not only do we fix the pr80974 regression, but we fix ~20 
other execution failures in the port.  It also reduces test time for the 
port from ~90 minutes to ~60 minutes.


Committed to the trunk,
Jeffcommit 7950c96ca667ddaab9d6e894da3958ebc2e2dccb
Author: Jeff Law 
Date:   Sat Nov 20 11:20:07 2021 -0500

Clobber the condition code in the bfin doloop patterns

Per Aldy's excellent, but tough to follow analysis in PR 103226, this patch
fixes the bfin-elf regression.

In simplest terms the doloop patterns on this port may clobber the condition
code register, but they do not expose that until after register allocation.
That would be fine, except that other patterns have exposed CC earlier.  As
a result the dataflow, particularly for CC, is incorrect.

This leads the register allocators to assume that a value in CC outside the
loop is still valid inside the loop when in fact, the value has been
clobbered.  This is what caused pr80974 to start failing.

With this fix, not only do we fix the pr80974 regression, but we fix ~20
other execution failures in the port.  It also reduces test time for the
port from ~90 minutes to ~60 minutes.

PR tree-optimization/103226
gcc/
* config/bfin/bfin.md (doloop pattern, splitter and expander): 
Clobber
CC.

diff --git a/gcc/config/bfin/bfin.md b/gcc/config/bfin/bfin.md
index fd65f4d9e63..10a19aac23e 100644
--- a/gcc/config/bfin/bfin.md
+++ b/gcc/config/bfin/bfin.md
@@ -1959,7 +1959,8 @@
   (plus:SI (match_dup 0)
(const_int -1)))
  (unspec [(const_int 0)] UNSPEC_LSETUP_END)
- (clobber (match_dup 2))])] ; match_scratch
+ (clobber (match_dup 2))
+ (clobber (reg:BI REG_CC))])] ; match_scratch
   ""
 {
   /* The loop optimizer doesn't check the predicates... */
@@ -1979,7 +1980,8 @@
(plus (match_dup 2)
  (const_int -1)))
(unspec [(const_int 0)] UNSPEC_LSETUP_END)
-   (clobber (match_scratch:SI 3 "=X,,"))]
+   (clobber (match_scratch:SI 3 "=X,,"))
+   (clobber (reg:BI REG_CC))]
   ""
   "@
/* loop end %0 %l1 */
@@ -1997,7 +1999,8 @@
(plus (match_dup 0)
  (const_int -1)))
(unspec [(const_int 0)] UNSPEC_LSETUP_END)
-   (clobber (match_scratch:SI 2))]
+   (clobber (match_scratch:SI 2))
+   (clobber (reg:BI REG_CC))]
   "memory_operand (operands[0], SImode) || splitting_loops"
   [(set (match_dup 2) (match_dup 0))
(set (match_dup 2) (plus:SI (match_dup 2) (const_int -1)))


Re: [PATCH] libgccjit: Add support for types used by atomic builtins [PR96066] [PR96067]

2021-11-20 Thread Antoni Boucher via Gcc-patches
Hi.
Here's the updated patch.
Thanks for the review!

Le jeudi 20 mai 2021 à 16:24 -0400, David Malcolm a écrit :
> On Mon, 2021-05-17 at 21:02 -0400, Antoni Boucher via Jit wrote:
> > Hello.
> > This patch fixes the issue with using atomic builtins in libgccjit.
> > Thanks to review it.
> 
> [...snip...]
>  
> > diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
> > index 117ff70114c..de876ff9fa6 100644
> > --- a/gcc/jit/jit-recording.c
> > +++ b/gcc/jit/jit-recording.c
> > @@ -2598,8 +2598,18 @@
> > recording::memento_of_get_pointer::accepts_writes_from (type
> > *rtype)
> >  return false;
> >  
> >    /* It's OK to assign to a (const T *) from a (T *).  */
> > -  return m_other_type->unqualified ()
> > -    ->accepts_writes_from (rtype_points_to);
> > +  if (m_other_type->unqualified ()
> > +    ->accepts_writes_from (rtype_points_to)) {
> > +  return true;
> > +  }
> > +
> > +  /* It's OK to assign to a (volatile const T *) from a (volatile
> > const T *). */
> > +  if (m_other_type->unqualified ()->unqualified ()
> > +    ->accepts_writes_from (rtype_points_to->unqualified ())) {
> > +  return true;
> > +  }
> 
> Presumably you need this to get the atomic builtins working?
> 
> If I'm reading the above correctly, the new test doesn't distinguish
> between the 3 different kinds of qualifiers (aligned, volatile, and
> const), it merely tries to strip some of them off.
> 
> It's not valid to e.g. assign to a (aligned T *) from a (const T *).
> 
> Maybe we need an internal enum to discriminate between different
> subclasses of decorated_type?
> 
> 
> > +
> > +  return false;
> >  }
> >  
> >  /* Implementation of pure virtual hook
> > recording::memento::replay_into
> > diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > index 4202eb7798b..dfc6596358c 100644
> > --- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > +++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > @@ -181,6 +181,13 @@
> >  #undef create_code
> >  #undef verify_code
> >  
> > +/* test-builtin-types.c */
> > +#define create_code create_code_builtin_types
> > +#define verify_code verify_code_builtin_types
> > +#include "test-builtin-types.c"
> > +#undef create_code
> > +#undef verify_code
> > +
> >  /* test-hello-world.c */
> >  #define create_code create_code_hello_world
> >  #define verify_code verify_code_hello_world
> 
> As with various other patches, this needs to also add a new entry to
> the "testcases" array making use of the new
> {create|verify}_code_builtin_types functions.
> 
> [...snip...]
> 
> Hope this is constructive
> Dave
> 

From 74230be2c324876b255fc1cc96fae4eece8ff2a2 Mon Sep 17 00:00:00 2001
From: Antoni Boucher 
Date: Sun, 9 May 2021 20:14:37 -0400
Subject: [PATCH] libgccjit: Add support for types used by atomic builtins
 [PR96066] [PR96067]

2021-11-20  Antoni Boucher  

gcc/jit/
PR target/PR96066
PR target/PR96067
* jit-builtins.c: Implement missing types for builtins.
* jit-recording.c:: Allow sending a volatile const void * as
argument.
* jit-recording.h: New functions (is_volatile, is_const) and
  allow comparing qualified types.
gcc/testsuite/
PR target/PR96066
PR target/PR96067
* jit.dg/all-non-failing-tests.h: Add test-builtin-types.c.
* jit.dg/test-builtin-types.c

Signed-off-by: Antoni Boucher 
---
 gcc/jit/jit-builtins.c   | 10 ++---
 gcc/jit/jit-recording.c  |  9 +++-
 gcc/jit/jit-recording.h  | 16 
 gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +
 gcc/testsuite/jit.dg/test-builtin-types.c| 43 
 5 files changed, 81 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/jit.dg/test-builtin-types.c

diff --git a/gcc/jit/jit-builtins.c b/gcc/jit/jit-builtins.c
index 1ea96f4e025..c279dd858f9 100644
--- a/gcc/jit/jit-builtins.c
+++ b/gcc/jit/jit-builtins.c
@@ -541,11 +541,11 @@ builtins_manager::make_primitive_type (enum jit_builtin_type type_id)
 // case BT_DFLOAT128:
 // case BT_VALIST_REF:
 // case BT_VALIST_ARG:
-// case BT_I1:
-// case BT_I2:
-// case BT_I4:
-// case BT_I8:
-// case BT_I16:
+case BT_I1: return m_ctxt->get_int_type (1, true);
+case BT_I2: return m_ctxt->get_int_type (2, true);
+case BT_I4: return m_ctxt->get_int_type (4, true);
+case BT_I8: return m_ctxt->get_int_type (8, true);
+case BT_I16: return m_ctxt->get_int_type (16, true);
 // case BT_PTR_CONST_STRING:
 }
 }
diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
index 117ff70114c..2eecf44c8db 100644
--- a/gcc/jit/jit-recording.c
+++ b/gcc/jit/jit-recording.c
@@ -2598,8 +2598,13 @@ recording::memento_of_get_pointer::accepts_writes_from (type *rtype)
 return false;
 
   /* It's OK to assign to a (const T *) from a (T *).  */
-  

Re: [PATCH] libgccjit: Add support for setting the link section of global variables [PR100688]

2021-11-20 Thread David Malcolm via Gcc-patches
On Sat, 2021-11-20 at 00:58 -0500, Antoni Boucher wrote:
> Thanks for your reviews!
> 
> Here's the updated patch, ready for another review.
> See comments/questions below.

Thanks for the updated patch...

> 
> I'll update the other patches over the weekend.
> 
> Le jeudi 20 mai 2021 à 15:29 -0400, David Malcolm a écrit :
> > On Wed, 2021-05-19 at 20:32 -0400, Antoni Boucher via Jit wrote:
> > > Hello.
> > > This patch adds support to set the link section of global
> > > variables.
> > > I used the ABI 18 because I submitted other patches up to 17.
> > > Thanks for the review.
> > 
> > I didn't see this email until now, and put the review in bugzilla
> > instead; sorry.
> > 
> > Here's a copy-and-paste of what I put in bugzilla:
> > 
> > 
> > Thanks for the patch; I like the idea; various nits below:
> > 

[...snip...]

> > 
> > >  Global variables
> > >  
> > >  
> > > diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
> > > index 825a3e172e9..8b0f65e87e8 100644
> > > --- a/gcc/jit/jit-playback.h
> > > +++ b/gcc/jit/jit-playback.h
> > > @@ -650,6 +650,8 @@ public:
> > >  
> > >  private:
> > >    context *m_ctxt;
> > > +
> > > +protected:
> > >    tree m_inner;
> > >  };
> > 
> > I think you only use this...
> > 
> > >  
> > > @@ -670,6 +672,12 @@ public:
> > >    rvalue *
> > >    get_address (location *loc);
> > >  
> > > +  void
> > > +  set_link_section (const char* name)
> > > +  {
> > > +    set_decl_section_name (m_inner, name);
> > > +  }
> > 
> > ...here, and you can get at rvalue::m_inner using as_tree (), so I
> > don't think we need to make m_inner protected.

Thanks for dropping the "protected" in the updated patch; you need to
update the ChangeLog entry.

> > 
> > 
> > > +  set_playback_obj (global);
> > >  }
> > >  
> > 
> > [...snip]
> > 
> > > diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
> > > index 03fa1160cf0..0691fac579d 100644
> > > --- a/gcc/jit/jit-recording.h
> > > +++ b/gcc/jit/jit-recording.h
> > > @@ -1105,7 +1105,8 @@ public:
> > >    lvalue (context *ctxt,
> > >   location *loc,
> > >   type *type_)
> > > -    : rvalue (ctxt, loc, type_)
> > > +    : rvalue (ctxt, loc, type_),
> > > +  m_link_section(NULL)
> > >  {}
> > >  
> > >    playback::lvalue *
> > > @@ -1127,6 +1128,10 @@ public:
> > >    const char *access_as_rvalue (reproducer ) OVERRIDE;
> > >    virtual const char *access_as_lvalue (reproducer );
> > >    virtual bool is_global () const { return false; }
> > > +  void set_link_section (const char *name);
> > > +
> > > +protected:
> > > +  string *m_link_section;
> > >  };
> > 
> > Can it be private, rather than protected?
> 
> m_link_section can't be private because it's used in
> recording::global::replay_into.

Fair enough; thanks.

> > 
> > > diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
> > > index 7fa948007ad..8cfa48aae24 100644
> > > --- a/gcc/jit/libgccjit.c
> > > +++ b/gcc/jit/libgccjit.c
> > > @@ -1953,6 +1953,18 @@ gcc_jit_lvalue_get_address (gcc_jit_lvalue
> > *lvalue,
> > >    return (gcc_jit_rvalue *)lvalue->get_address (loc);
> > >  }
> > >  
> > > +/* Public entrypoint.  See description in libgccjit.h.
> > > +
> > > +   After error-checking, the real work is done by the
> > > +   gcc::jit::recording::lvalue::set_section method in jit-
> > recording.c.  */
> >    ^^^
> >    set_link_section
> > 
> > Also, a newline here please for consistency with the other
> > entrypoints.
> 
> Where should I add a newline?

Between the closing of the comment and the "void" of the fndecl (all
the other entrypoints have a blank line separating them).  Thanks for
fixing my other nitpicks.


[...snip...]

> > > diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > index 4202eb7798b..7e3b59dee0d 100644
> > > --- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > +++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > @@ -181,6 +181,13 @@
> > >  #undef create_code
> > >  #undef verify_code
> > >  
> > > +/* test-link-section.c */
> > > +#define create_code create_code_link_section
> > > +#define verify_code verify_code_link_section
> > > +#include "test-link-section.c"
> > > +#undef create_code
> > > +#undef verify_code

The updated version of the testcase doesn't have a verify_code, so it
can't be in the "testcases" array.  
Please replace this with something like:


/* test-link-section.c: This can't be in the testcases array as it
   doesn't have a verify_code implementation.  */
 

(I'm trying to have all-nonfailing-tests.h refer to each non-failing
test, either adding it to the testcases array, or documenting why it
isn't in the array; listing them in alphabetical order)

[...snip...]

> > > 
> > > +
> > > +extern void
> > > +verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
> > > +{
> > > +}
> > 
> > This is OK, but ideally it would test 

[PATCH] Tweak tree-ssa-math-opts.c to solve PR target/102117

2021-11-20 Thread Roger Sayle

This patch resolves PR target/102117 on s390.  The problem is that
some of the functionality of GCC's RTL expanders is no longer triggered
following the transition to tree SSA form.  On s390, unsigned widening
multiplications are converted into WIDEN_MULT_EXPR (aka w* in tree dumps),
but signed widening multiplies are left in their original form, which
alas doesn't benefit from the clever logic in expand_widening_mult.

The fix is to teach convert_mult_to_widen, that RTL expansion can
synthesize a signed widening multiplication if the target provides
a suitable umul_widen_optab.

On s390-linux-gnu with -O2 -m64, the code in the bugzilla PR currently
generates:

imul128:
stmg%r12,%r13,96(%r15)
srag%r0,%r4,63
srag%r1,%r3,63
lgr %r13,%r3
mlgr%r12,%r4
msgr%r1,%r4
msgr%r0,%r3
lgr %r4,%r12
agr %r1,%r0
lgr %r5,%r13
agr %r4,%r1
stmg%r4,%r5,0(%r2)
lmg %r12,%r13,96(%r15)
br  %r14

but with this patch should now generate the more efficient:

imul128:
lgr %r1,%r3
mlgr%r0,%r4
srag%r5,%r3,63
ngr %r5,%r4
srag%r4,%r4,63
sgr %r0,%r5
ngr %r4,%r3
sgr %r0,%r4
stmg%r0,%r1,0(%r2)
br  %r14


This patch has been tested s390/z13 with a bootstrap and a regression
test (thanks to Robin Dapp), and on x86_64-pc-linux-gnu with a bootstrap
and regression test just to confirm that there are no unanticipated
side-effects.

Ok for mainline?


2021-11-20  Roger Sayle  
Robin Dapp  

gcc/ChangeLog
PR target/102117
* tree-ssa-math-opts.c (convert_mult_to_widen): Recognize
signed WIDEN_MULT_EXPR if the target supports umul_widen_optab.

gcc/testsuite/ChangeLog
PR target/102117
* gcc.target/s390/mul-wide.c: New test case.
* gcc.target/s390/umul-wide.c: New test case.

Thanks in advance,
Roger
--

diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
index c4a6492..a944903 100644
--- a/gcc/tree-ssa-math-opts.c
+++ b/gcc/tree-ssa-math-opts.c
@@ -2723,7 +2723,16 @@ convert_mult_to_widen (gimple *stmt, 
gimple_stmt_iterator *gsi)
  from_unsigned1 = from_unsigned2 = false;
}
   else
-   return false;
+   {
+ /* Expand can synthesize smul_widen_optab if the target
+supports umul_widen_optab.  */
+ op = umul_widen_optab;
+ handler = find_widening_optab_handler_and_mode (op, to_mode,
+ from_mode,
+ _mode);
+ if (handler == CODE_FOR_nothing)
+   return false;
+   }
 }
 
   /* Ensure that the inputs to the handler are in the correct precison
diff --git a/gcc/testsuite/gcc.target/s390/mul-wide.c 
b/gcc/testsuite/gcc.target/s390/mul-wide.c
new file mode 100644
index 000..8a2092e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/mul-wide.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -m64 -fdump-tree-optimized" } */
+
+__int128 foo(long long a, long long b)
+{
+   return (__int128)a * (__int128)b;
+}
+
+/* { dg-final { scan-tree-dump " w\\* " "optimized" } } */
diff --git a/gcc/testsuite/gcc.target/s390/umul-wide.c 
b/gcc/testsuite/gcc.target/s390/umul-wide.c
new file mode 100644
index 000..33a74e5
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/umul-wide.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -m64 -fdump-tree-optimized" } */
+
+unsigned __int128 foo(unsigned long long a, unsigned long long b)
+{
+   return (unsigned __int128)a * (unsigned __int128)b;
+}
+
+/* { dg-final { scan-tree-dump " w\\* " "optimized" } } */


[pushed] Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556].

2021-11-20 Thread Iain Sandoe via Gcc-patches
This addresses a long-standing problem where a work-around for an unwinder
issue (also a regression) regresses other functionality.  The patch replaces
several work-arounds with a fix for PR80556 and a work-around for PR88590.

* The fix for PR80556 requires a bump to the SO name for libgcc_s, since we
need to remove the unwinder symbols from it.  This would trigger PR88590
hence the work-around for that.

* We weaken the symbols for emulated TLS support so that it is possible
for a DSO linked with static-libgcc to interoperate with a DSO linked with
libgcc_s.  Likewise main exes.

* We remove all the gcc-4.2.1 era stubs machinery and workarounds.

* libgcc is always now linked ahead of libc, which avoids fails where the
libc (libSystem) builtins implementations are not up to date.

* The unwinder now always comes from the system
 - for Darwin9 from /usr/lib/libgcc_s.1.dylib
 - for Darwin10 from /usr/lib/libSystem.dylib
 - for Darwin11+ from /usr/lib/system/libunwind.dylib.
 
 We still insert a shim on Darwin10 to fix an omitted unwind function, but
 the underlying unwinder remains the system one.

* The work-around for PR88590 has two parts (1) we always link libgcc from
its convenience lib (avoiding the need to find the DSO path); (2) we add and
export the emutls functions from DSOs - this makes a relatively small (20k)
addition to a DSO.  These can be backed out when a proper fix for PR88590 is
committed.

For distributions that wish to install a libgcc_s.1.dylib to satisfy linkage
from exes that linked against the stubs can use a reexported libgcc_s.1.1
(since that contains all the symbols that were previously exported via the
 stubs).
 
Tested on *-darwin*, x86-64, powerpc64le-linux,
pushed to master, thanks
Iain

gcc/ChangeLog:

PR target/80556
* config/darwin.c (darwin_rename_builtins): Remove workaround.
* config/darwin.h (LINK_GCC_C_SEQUENCE_SPEC): Provide __eprintf via
libgcc for macOS <= 10.4. (REAL_LIBGCC_SPEC): Adjust for the revised
library naming.
* config/i386/darwin.h (REAL_LIBGCC_SPEC): Remove workaround.
* config/i386/darwin32-biarch.h (REAL_LIBGCC_SPEC): Likewise.
* config/i386/darwin64-biarch.h (REAL_LIBGCC_SPEC): Likewise.

libgcc/ChangeLog:

PR target/80556
* config.host: Adjust target fragments to omit the unwinder from
Darwin libgcc builds.  Add a weak emutls crt.
* config/i386/t-darwin: Add X86-specific libgcc symbols.
* config/t-darwin: Build a crat containing weak definitions for the
emuTLS routines.
* config/t-slibgcc-darwin: Bump SO version, remove all the handling
for stub libraries.
* emutls.c (EMUTLS_ATTR): New.
(__emutls_get_address): Allow a target to add a weak
attribute if provided.
(__emutls_register_common): Likewise.
* config/i386/libgcc-darwin.10.4.ver: Removed.
* config/i386/libgcc-darwin.10.5.ver: Removed.
* config/libgcc-libsystem.ver: Removed.
* config/rs6000/libgcc-darwin.10.4.ver: Removed.
* config/rs6000/libgcc-darwin.10.5.ver: Removed.
* config/i386/libgcc-darwin.ver: New file.
* config/t-darwin-noeh: New file.

gcc/testsuite/ChangeLog:

PR target/80556
* gcc.dg/torture/fp-int-convert-timode-3.c: Revert XFAIL.
* gcc.dg/torture/fp-int-convert-timode-4.c: Likewise.
---
 gcc/config/darwin-driver.c|  18 +++
 gcc/config/darwin.c   |  24 
 gcc/config/darwin.h   |  98 ++--
 gcc/config/darwin.opt |   4 +
 gcc/config/i386/darwin.h  |  31 -
 gcc/config/i386/darwin32-biarch.h |  13 ---
 gcc/config/i386/darwin64-biarch.h |  13 ---
 .../gcc.dg/torture/fp-int-convert-timode-3.c  |   1 -
 .../gcc.dg/torture/fp-int-convert-timode-4.c  |   1 -
 libgcc/config.host|   7 +-
 libgcc/config/i386/darwin-lib.h   |   9 --
 libgcc/config/i386/libgcc-darwin.10.4.ver |  98 
 libgcc/config/i386/libgcc-darwin.10.5.ver | 102 -
 libgcc/config/libgcc-libsystem.ver|  38 ++-
 libgcc/config/rs6000/libgcc-darwin.10.4.ver   |  93 ---
 libgcc/config/rs6000/libgcc-darwin.10.5.ver   | 106 --
 libgcc/config/t-darwin-noeh   |   4 +
 libgcc/config/t-slibgcc-darwin|  74 
 18 files changed, 153 insertions(+), 581 deletions(-)
 delete mode 100644 libgcc/config/i386/libgcc-darwin.10.4.ver
 delete mode 100644 libgcc/config/i386/libgcc-darwin.10.5.ver
 delete mode 100644 libgcc/config/rs6000/libgcc-darwin.10.4.ver
 delete mode 100644 libgcc/config/rs6000/libgcc-darwin.10.5.ver
 create mode 100644 libgcc/config/t-darwin-noeh

diff --git a/gcc/config/darwin-driver.c b/gcc/config/darwin-driver.c
index 4f0c6bad61f..7fa80abc314 100644
--- 

Re: [RFC PATCH] gcc: Improve reproducability when building cc1/cc1plus

2021-11-20 Thread Jacob Kroon via Gcc-patches

On 11/20/21 09:32, Jakub Jelinek wrote:

On Sat, Nov 20, 2021 at 12:24:21AM -0800, Andrew Pinski via Gcc-patches wrote:

On Sat, Nov 20, 2021 at 12:18 AM Jacob Kroon via Gcc-patches
 wrote:


cc1/cc1plus both include a checksum of the object files, archives and
options used during linking. Unless the host binutils has been built
with --enable-deterministic-archives, the archives will have different
checksums each build due to changes in timestamps of the containing
object files, and thus the checksum that is embedded in cc1/cc1plus will
also change.

Fix this by passing "D" to ar/ranlib when creating the archives.


How portable is the D option? That does it work with Mac OS X's ar;
what about AIX's ar; what about Solaris's ar, etc?
GNU binutils is not the only ar which is supported for the host.


It isn't portable and even if ar/ranlib do support that option, not all
users will want it, so forcing it upon them unconditionally is IMO not a
good idea.  If anything, configure needs to check if those options are
supported and there needs to be preferrably non-default gcc configure
option to request it.



Aha, I see. Then perhaps an easier and more portable solution for 
improving the reproducibility would be to make it optional whether or 
not to include the archives when calculating the checksums.


Or perhaps by checksumming the containing object files instead of the 
archives themselves ?


Would something like that be acceptable ?

Jacob


[PATCH] openacc: Fix up C++ #pragma acc routine handling [PR101731]

2021-11-20 Thread Jakub Jelinek via Gcc-patches
Hi!

The following testcase ICEs because two function declarations are nested in
each other and the acc routine handling code isn't prepared to put the
pragma on both.

The fix is similar to what #pragma omp declare {simd,variant} does,
in particular set the fndecl_seen flag already in cp_parser_late_parsing*
when we encounter it rather than only after we finalize it.

In cp_finalize_oacc_routine I had to move the fndecl_seen diagnostics to
non-FUNCTION_DECL block, because for FUNCTION_DECLs the flag is already
known to be set from cp_parser_late_parsing_oacc_routine, but can't be
removed altogether, because that regresses quality of 2 goacc/routine-5.c
diagnostics - we drop "a single " from the
'#pragma acc routine' not immediately followed by a single function declaration 
or definition
diagnostic say on
#pragma acc routine
int foo (), b;
if we drop it altogether.

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

2021-11-20  Jakub Jelinek  

PR c++/101731
* parser.c (cp_parser_late_parsing_oacc_routine): Set
parser->oacc_routine->fndecl_seen here, rather than ...
(cp_finalize_oacc_routine): ... here.  Don't error if
parser->oacc_routine->fndecl_seen is set for FUNCTION_DECLs.

* c-c++-common/goacc/routine-6.c: New test.

--- gcc/cp/parser.c.jj  2021-11-19 16:39:51.534595887 +0100
+++ gcc/cp/parser.c 2021-11-19 22:14:41.209591009 +0100
@@ -46852,8 +46852,8 @@ cp_parser_late_parsing_oacc_routine (cp_
  emission easier.  */
   parser->oacc_routine->clauses = nreverse (parser->oacc_routine->clauses);
   cp_parser_pop_lexer (parser);
-  /* Later, cp_finalize_oacc_routine will process the clauses, and then set
- fndecl_seen.  */
+  /* Later, cp_finalize_oacc_routine will process the clauses.  */
+  parser->oacc_routine->fndecl_seen = true;
 
   return attrs;
 }
@@ -46871,16 +46871,17 @@ cp_finalize_oacc_routine (cp_parser *par
  || fndecl == error_mark_node)
return;
 
-  if (parser->oacc_routine->fndecl_seen)
-   {
- error_at (parser->oacc_routine->loc,
-   "%<#pragma acc routine%> not immediately followed by"
-   " a single function declaration or definition");
- parser->oacc_routine = NULL;
- return;
-   }
   if (TREE_CODE (fndecl) != FUNCTION_DECL)
{
+ if (parser->oacc_routine->fndecl_seen)
+   {
+ error_at (parser->oacc_routine->loc,
+   "%<#pragma acc routine%> not immediately followed by"
+   " a single function declaration or definition");
+ parser->oacc_routine = NULL;
+ return;
+   }
+
  cp_ensure_no_oacc_routine (parser);
  return;
}
@@ -46921,11 +46922,6 @@ cp_finalize_oacc_routine (cp_parser *par
 parser->oacc_routine->clauses,
 DECL_ATTRIBUTES (fndecl));
}
-
-  /* Don't unset parser->oacc_routine here: we may still need it to
-diagnose wrong usage.  But, remember that we've used this "#pragma acc
-routine".  */
-  parser->oacc_routine->fndecl_seen = true;
 }
 }
 
--- gcc/testsuite/c-c++-common/goacc/routine-6.c.jj 2021-11-19 
22:13:11.150864445 +0100
+++ gcc/testsuite/c-c++-common/goacc/routine-6.c2021-11-19 
22:13:11.150864445 +0100
@@ -0,0 +1,4 @@
+/* PR c++/101731 */
+
+#pragma acc routine/* { dg-error "not immediately followed by a single 
function declaration or definition" "" { target c++ } } */
+int foo (int bar ());

Jakub



Re: [RFC PATCH] gcc: Improve reproducability when building cc1/cc1plus

2021-11-20 Thread Jakub Jelinek via Gcc-patches
On Sat, Nov 20, 2021 at 12:24:21AM -0800, Andrew Pinski via Gcc-patches wrote:
> On Sat, Nov 20, 2021 at 12:18 AM Jacob Kroon via Gcc-patches
>  wrote:
> >
> > cc1/cc1plus both include a checksum of the object files, archives and
> > options used during linking. Unless the host binutils has been built
> > with --enable-deterministic-archives, the archives will have different
> > checksums each build due to changes in timestamps of the containing
> > object files, and thus the checksum that is embedded in cc1/cc1plus will
> > also change.
> >
> > Fix this by passing "D" to ar/ranlib when creating the archives.
> 
> How portable is the D option? That does it work with Mac OS X's ar;
> what about AIX's ar; what about Solaris's ar, etc?
> GNU binutils is not the only ar which is supported for the host.

It isn't portable and even if ar/ranlib do support that option, not all
users will want it, so forcing it upon them unconditionally is IMO not a
good idea.  If anything, configure needs to check if those options are
supported and there needs to be preferrably non-default gcc configure
option to request it.

Jakub



Re: [RFC PATCH] gcc: Improve reproducability when building cc1/cc1plus

2021-11-20 Thread Andrew Pinski via Gcc-patches
On Sat, Nov 20, 2021 at 12:18 AM Jacob Kroon via Gcc-patches
 wrote:
>
> cc1/cc1plus both include a checksum of the object files, archives and
> options used during linking. Unless the host binutils has been built
> with --enable-deterministic-archives, the archives will have different
> checksums each build due to changes in timestamps of the containing
> object files, and thus the checksum that is embedded in cc1/cc1plus will
> also change.
>
> Fix this by passing "D" to ar/ranlib when creating the archives.

How portable is the D option? That does it work with Mac OS X's ar;
what about AIX's ar; what about Solaris's ar, etc?
GNU binutils is not the only ar which is supported for the host.

Thanks,
Andrew Pinski


>
> Signed-off-by: Jacob Kroon 
> ---
>  Makefile.in  | 4 ++--
>  gcc/Makefile.in  | 2 +-
>  libbacktrace/configure   | 2 +-
>  libcody/Makefile.in  | 4 ++--
>  libcpp/Makefile.in   | 4 ++--
>  libdecnumber/Makefile.in | 4 ++--
>  libiberty/Makefile.in| 6 +++---
>  7 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/Makefile.in b/Makefile.in
> index 860cf8f067b..8c451ed2121 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -416,7 +416,7 @@ MAKEINFOFLAGS = --split-size=500
>
>  AS = @AS@
>  AR = @AR@
> -AR_FLAGS = rc
> +AR_FLAGS = rcD
>  CC = @CC@
>  CXX = @CXX@
>  DLLTOOL = @DLLTOOL@
> @@ -23571,7 +23571,7 @@ configure-libbacktrace:
>   $$s/$$module_srcdir/configure \
>   --srcdir=$${topdir}/$$module_srcdir \
>   $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
> - --target=${target_alias}  \
> + --target=${target_alias}  RANLIB="ranlib -D" \
>   || exit 1
>  @endif libbacktrace
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 571e9c28e29..828b13d9b54 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -243,7 +243,7 @@ AR = @AR@
>  AR_FLAGS = rc
>  NM = @NM@
>  RANLIB = @RANLIB@
> -RANLIB_FLAGS = @ranlib_flags@
> +RANLIB_FLAGS = @ranlib_flags@ -D
>
>  # Libraries to use on the host.
>  HOST_LIBS = @HOST_LIBS@
> diff --git a/libbacktrace/configure b/libbacktrace/configure
> index a2f33c0f35d..5b18966ea80 100755
> --- a/libbacktrace/configure
> +++ b/libbacktrace/configure
> @@ -6669,7 +6669,7 @@ else
>  fi
>
>  test -z "$AR" && AR=ar
> -test -z "$AR_FLAGS" && AR_FLAGS=cru
> +test -z "$AR_FLAGS" && AR_FLAGS=crD
>
>
>
> diff --git a/libcody/Makefile.in b/libcody/Makefile.in
> index 7eaf8ace8ce..f1e8be352b5 100644
> --- a/libcody/Makefile.in
> +++ b/libcody/Makefile.in
> @@ -126,8 +126,8 @@ LIBCODY.O := buffer.o client.o fatal.o netclient.o 
> netserver.o \
>  all:: libcody.a
>
>  libcody.a: $(LIBCODY.O)
> -   $(AR) -cr $@ $^
> -   $(RANLIB) $@
> +   $(AR) -crD $@ $^
> +   $(RANLIB) -D $@
>
>  mostlyclean::
>
> diff --git a/libcpp/Makefile.in b/libcpp/Makefile.in
> index 34e4206957d..53d220c4e0b 100644
> --- a/libcpp/Makefile.in
> +++ b/libcpp/Makefile.in
> @@ -26,7 +26,7 @@ top_builddir = .
>  VPATH = @srcdir@
>  INSTALL = @INSTALL@
>  AR = @AR@
> -ARFLAGS = cru
> +ARFLAGS = crD
>  ACLOCAL = @ACLOCAL@
>  AUTOCONF = @AUTOCONF@
>  AUTOHEADER = @AUTOHEADER@
> @@ -101,7 +101,7 @@ all: libcpp.a $(USED_CATALOGS)
>  libcpp.a: $(libcpp_a_OBJS)
> -rm -f libcpp.a
> $(AR) $(ARFLAGS) libcpp.a $(libcpp_a_OBJS)
> -   $(RANLIB) libcpp.a
> +   $(RANLIB) -D libcpp.a
>
>  # Rules to rebuild the configuration
>
> diff --git a/libdecnumber/Makefile.in b/libdecnumber/Makefile.in
> index 7e086fccafa..3b03064fc4d 100644
> --- a/libdecnumber/Makefile.in
> +++ b/libdecnumber/Makefile.in
> @@ -26,7 +26,7 @@ top_builddir = .
>  VPATH = @srcdir@
>  INSTALL = @INSTALL@
>  AR = @AR@
> -ARFLAGS = cru
> +ARFLAGS = crD
>  ACLOCAL = @ACLOCAL@
>  AUTOCONF = @AUTOCONF@
>  AUTOHEADER = @AUTOHEADER@
> @@ -88,7 +88,7 @@ all: libdecnumber.a
>  libdecnumber.a: $(libdecnumber_a_OBJS)
> -rm -f $@
> $(AR) $(ARFLAGS) $@ $(libdecnumber_a_OBJS)
> -   $(RANLIB) $@
> +   $(RANLIB) -D $@
>
>  # Rules to rebuild the configuration
>
> diff --git a/libiberty/Makefile.in b/libiberty/Makefile.in
> index 884cc6c4af2..9f507a54657 100644
> --- a/libiberty/Makefile.in
> +++ b/libiberty/Makefile.in
> @@ -252,19 +252,19 @@ $(TARGETLIB): $(REQUIRED_OFILES) $(EXTRA_OFILES) 
> $(LIBOBJS)
> -rm -f $(TARGETLIB) pic/$(TARGETLIB) noasan/$(TARGETLIB)
> $(AR) $(AR_FLAGS) $(TARGETLIB) \
>   $(REQUIRED_OFILES) $(EXTRA_OFILES) $(LIBOBJS)
> -   $(RANLIB) $(TARGETLIB)
> +   $(RANLIB) -D $(TARGETLIB)
> if [ x"$(PICFLAG)" != x ]; then \
>   cd pic; \
>   $(AR) $(AR_FLAGS) $(TARGETLIB) \
> $(REQUIRED_OFILES) $(EXTRA_OFILES) $(LIBOBJS); \
> - $(RANLIB) $(TARGETLIB); \
> + $(RANLIB) -D $(TARGETLIB); \
>   cd ..; \
> else true; fi; \
> if [ x"$(NOASANFLAG)" != x ]; then \
>   cd noasan; \
>   $(AR) $(AR_FLAGS) $(TARGETLIB) \
> $(REQUIRED_OFILES) 

[PATCH] i386: Fix up handling of target attribute [PR101180]

2021-11-20 Thread Jakub Jelinek via Gcc-patches
Hi!

As shown in the testcase below, if a function has multiple target attributes
(rather than a single one with one or more arguments) or if a function
gets one target attribute on one declaration and another one on another
declaration, on x86 their effect is not combined into
DECL_FUNCTION_SPECIFIC_TARGET, but instead only the last processed target
attribute wins.  aarch64 handles this right, the following patch follows
what it does, i.e. only start with target_option_default_node if
DECL_FUNCTION_SPECIFIC_TARGET is previously NULL (i.e. the first target
attribute being processed on a function) and otherwise start from the
previous DECL_FUNCTION_SPECIFIC_TARGET.

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

2021-11-20  Jakub Jelinek  

PR c++/101180
* config/i386/i386-options.c (ix86_valid_target_attribute_p): If
fndecl already has DECL_FUNCTION_SPECIFIC_TARGET, use that as base
instead of target_option_default_node.

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

--- gcc/config/i386/i386-options.c.jj   2021-11-19 12:48:56.507415161 +0100
+++ gcc/config/i386/i386-options.c  2021-11-19 13:04:31.618044781 +0100
@@ -1443,8 +1443,11 @@ ix86_valid_target_attribute_p (tree fnde
 
   /* Initialize func_options to the default before its target options can
  be set.  */
+  tree old_target = DECL_FUNCTION_SPECIFIC_TARGET (fndecl);
+  if (old_target == NULL_TREE)
+old_target = target_option_default_node;
   cl_target_option_restore (_options, _options_set,
-   TREE_TARGET_OPTION (target_option_default_node));
+   TREE_TARGET_OPTION (old_target));
 
   /* FLAGS == 1 is used for target_clones attribute.  */
   new_target
--- gcc/testsuite/gcc.target/i386/pr101180.c.jj 2021-11-19 13:24:19.334132937 
+0100
+++ gcc/testsuite/gcc.target/i386/pr101180.c2021-11-19 13:23:56.676454806 
+0100
@@ -0,0 +1,12 @@
+/* PR c++/101180 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -mno-avx -mno-crc32" } */
+
+#include 
+
+__attribute__((target ("avx"))) __attribute__((target ("crc32"))) void
+foo (__m256 *p, unsigned int *q)
+{
+  __m256 c = _mm256_and_ps (p[0], p[1]);
+  *q = __crc32b (*q, 0x55);
+}

Jakub



[RFC PATCH] gcc: Improve reproducability when building cc1/cc1plus

2021-11-20 Thread Jacob Kroon via Gcc-patches
cc1/cc1plus both include a checksum of the object files, archives and
options used during linking. Unless the host binutils has been built
with --enable-deterministic-archives, the archives will have different
checksums each build due to changes in timestamps of the containing
object files, and thus the checksum that is embedded in cc1/cc1plus will
also change.

Fix this by passing "D" to ar/ranlib when creating the archives.

Signed-off-by: Jacob Kroon 
---
 Makefile.in  | 4 ++--
 gcc/Makefile.in  | 2 +-
 libbacktrace/configure   | 2 +-
 libcody/Makefile.in  | 4 ++--
 libcpp/Makefile.in   | 4 ++--
 libdecnumber/Makefile.in | 4 ++--
 libiberty/Makefile.in| 6 +++---
 7 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index 860cf8f067b..8c451ed2121 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -416,7 +416,7 @@ MAKEINFOFLAGS = --split-size=500
 
 AS = @AS@
 AR = @AR@
-AR_FLAGS = rc
+AR_FLAGS = rcD
 CC = @CC@
 CXX = @CXX@
 DLLTOOL = @DLLTOOL@
@@ -23571,7 +23571,7 @@ configure-libbacktrace:
  $$s/$$module_srcdir/configure \
  --srcdir=$${topdir}/$$module_srcdir \
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
- --target=${target_alias}  \
+ --target=${target_alias}  RANLIB="ranlib -D" \
  || exit 1
 @endif libbacktrace
 
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 571e9c28e29..828b13d9b54 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -243,7 +243,7 @@ AR = @AR@
 AR_FLAGS = rc
 NM = @NM@
 RANLIB = @RANLIB@
-RANLIB_FLAGS = @ranlib_flags@
+RANLIB_FLAGS = @ranlib_flags@ -D
 
 # Libraries to use on the host.
 HOST_LIBS = @HOST_LIBS@
diff --git a/libbacktrace/configure b/libbacktrace/configure
index a2f33c0f35d..5b18966ea80 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -6669,7 +6669,7 @@ else
 fi
 
 test -z "$AR" && AR=ar
-test -z "$AR_FLAGS" && AR_FLAGS=cru
+test -z "$AR_FLAGS" && AR_FLAGS=crD
 
 
 
diff --git a/libcody/Makefile.in b/libcody/Makefile.in
index 7eaf8ace8ce..f1e8be352b5 100644
--- a/libcody/Makefile.in
+++ b/libcody/Makefile.in
@@ -126,8 +126,8 @@ LIBCODY.O := buffer.o client.o fatal.o netclient.o 
netserver.o \
 all:: libcody.a
 
 libcody.a: $(LIBCODY.O)
-   $(AR) -cr $@ $^
-   $(RANLIB) $@
+   $(AR) -crD $@ $^
+   $(RANLIB) -D $@
 
 mostlyclean::
 
diff --git a/libcpp/Makefile.in b/libcpp/Makefile.in
index 34e4206957d..53d220c4e0b 100644
--- a/libcpp/Makefile.in
+++ b/libcpp/Makefile.in
@@ -26,7 +26,7 @@ top_builddir = .
 VPATH = @srcdir@
 INSTALL = @INSTALL@
 AR = @AR@
-ARFLAGS = cru
+ARFLAGS = crD
 ACLOCAL = @ACLOCAL@
 AUTOCONF = @AUTOCONF@
 AUTOHEADER = @AUTOHEADER@
@@ -101,7 +101,7 @@ all: libcpp.a $(USED_CATALOGS)
 libcpp.a: $(libcpp_a_OBJS)
-rm -f libcpp.a
$(AR) $(ARFLAGS) libcpp.a $(libcpp_a_OBJS)
-   $(RANLIB) libcpp.a
+   $(RANLIB) -D libcpp.a
 
 # Rules to rebuild the configuration
 
diff --git a/libdecnumber/Makefile.in b/libdecnumber/Makefile.in
index 7e086fccafa..3b03064fc4d 100644
--- a/libdecnumber/Makefile.in
+++ b/libdecnumber/Makefile.in
@@ -26,7 +26,7 @@ top_builddir = .
 VPATH = @srcdir@
 INSTALL = @INSTALL@
 AR = @AR@
-ARFLAGS = cru
+ARFLAGS = crD
 ACLOCAL = @ACLOCAL@
 AUTOCONF = @AUTOCONF@
 AUTOHEADER = @AUTOHEADER@
@@ -88,7 +88,7 @@ all: libdecnumber.a
 libdecnumber.a: $(libdecnumber_a_OBJS)
-rm -f $@
$(AR) $(ARFLAGS) $@ $(libdecnumber_a_OBJS)
-   $(RANLIB) $@
+   $(RANLIB) -D $@
 
 # Rules to rebuild the configuration
 
diff --git a/libiberty/Makefile.in b/libiberty/Makefile.in
index 884cc6c4af2..9f507a54657 100644
--- a/libiberty/Makefile.in
+++ b/libiberty/Makefile.in
@@ -252,19 +252,19 @@ $(TARGETLIB): $(REQUIRED_OFILES) $(EXTRA_OFILES) 
$(LIBOBJS)
-rm -f $(TARGETLIB) pic/$(TARGETLIB) noasan/$(TARGETLIB)
$(AR) $(AR_FLAGS) $(TARGETLIB) \
  $(REQUIRED_OFILES) $(EXTRA_OFILES) $(LIBOBJS)
-   $(RANLIB) $(TARGETLIB)
+   $(RANLIB) -D $(TARGETLIB)
if [ x"$(PICFLAG)" != x ]; then \
  cd pic; \
  $(AR) $(AR_FLAGS) $(TARGETLIB) \
$(REQUIRED_OFILES) $(EXTRA_OFILES) $(LIBOBJS); \
- $(RANLIB) $(TARGETLIB); \
+ $(RANLIB) -D $(TARGETLIB); \
  cd ..; \
else true; fi; \
if [ x"$(NOASANFLAG)" != x ]; then \
  cd noasan; \
  $(AR) $(AR_FLAGS) $(TARGETLIB) \
$(REQUIRED_OFILES) $(EXTRA_OFILES) $(LIBOBJS); \
- $(RANLIB) $(TARGETLIB); \
+ $(RANLIB) -D $(TARGETLIB); \
  cd ..; \
else true; fi
 


Re: [PATCH] gcc: vxworks: fix providing stdint.h header

2021-11-20 Thread Olivier Hainque via Gcc-patches



> On 19 Nov 2021, at 21:47, Rasmus Villemoes  wrote:
>> 
>> Your error triggers on O2ggnu++0x.gch and we configure with
>> --disable-libstdcxx-pch.
>> 
> 
> ISTR I already tried that, but just for good measure I did it again, and
> no luck:
> 
> /bin/sh ../libtool --tag CXX --tag disable-shared   --mode=compile
> .../gcc-build/./gcc/xgcc -shared-libgcc -B.../gcc-build/./gcc
> -nostdinc++ -L.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/src
> -L.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/src/.libs
> -L.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/libsupc++/.libs
> -B/usr/powerpc-wrs-vxworks/bin/ -B/usr/powerpc-wrs-vxworks/lib/ -isystem
> /usr/powerpc-wrs-vxworks/include -isystem
> /usr/powerpc-wrs-vxworks/sys-include
> --sysroot=/usr/powerpc-wrs-vxworks/sys-root
> -fdebug-prefix-map=.../gcc-build/= -fdebug-prefix-map=.../gcc-src/=
> -I.../gcc-src/libstdc++-v3/../libgcc
> -I.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/powerpc-wrs-vxworks
> -I.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include
> -I.../gcc-src/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall
> -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
> -fdiagnostics-show-location=once-ffunction-sections -fdata-sections
> -frandom-seed=del_opant.lo  -g -O2 -mstrict-align -mmultiple
> -fvisibility=hidden  -c -o del_opant.lo
> .../gcc-src/libstdc++-v3/libsupc++/del_opant.cc
> .../gcc-src/libstdc++-v3/libsupc++/new_opa.cc:28:10: fatal error:
> stdint.h: No such file or directory
>   28 | #include 
>  |  ^~

Ok, thanks. Another diff is we're using fixincludes for vx6
(not 7), and have a local patch setting sysroot_headers_dir in
a particular fashion to handle kernel vs rtp (part of what I was
intending to propagate as well). We're not using --sysroot directly.

I'll check how our build sequence proceeds.