Re: [committed] gimple UIDs, LTO and -fanalyzer [PR98599]

[Jan Hubicka]

Hello
> > Thanks.
> > 
> > I think my earlier analysis was wrong.
Sorry for late reply.  I was looking into it again yesterday but was bit
confused about what is goin gon here.
> > 
> > With the caveat that I'm not as familiar with the IPA code as other
> > parts of the compiler, what I think is going on is:
> > 
> > WPA streams in the input callgraph:
> > 
> >   main/1 ---> a/0  --> b/2
> >  |   |
> >   lto_stmt_uid == 1  lto_stmt_uid == 1
> > 
> > WPA generates a clone of a, and streams out this callgraph:
> > 
> >   main/1 ---> a.isra/3  --> b/2
> > 
> > Without -fanalyzer, the callgraph edges have NULL call_stmt and so
> > the
> > existing lto_stmt_uid values are used when streaming out:
> > 
> >   main/1 ---> a.isra/3  --> b/2
> >  |   |
> >  lto_stmt_uid == 1  lto_stmt_uid == 1
> > 
> > 
> > With -fanalyzer, the functions were materialized, so the callgraph
> > edges have non-NULL call-stmt.
> > 
> > lto_prepare_function_for_streaming is called for "main/1", but not
> > for
> > "a.isra/3", as it is a clone (see the condition at line 310):
> > 
> > 307   /* Do body modifications needed for streaming before we
> > fork out
> > 308  worker processes.  */
> > 309   FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
> > 310 if (!node->clone_of && gimple_has_body_p (node->decl))
> > 311   lto_prepare_function_for_streaming (node);
> > 
> > Hence the uids are written to within main/1, but not within a.isra/3
> > (I
> > think).

This is still correct. The idea here is that clone does not have its own
body but shares it with the original function until it gets materialized
and then it is turned to real function itself.

At WPA time some functions are loaded into memory while others are just
rerefences to LTO data.
So either
  1) we have function referencing LTO data and then the function
 and all its clones should use lto_stmt_uid and stmt pointers should
 be NULL or 
  2) we have function loaded in memory and the function and all its
 clones should have lto_stmt_uid undefined and stmt points used.

Since you load function to memory we should end up using stmt pointers.
Since there is only one body, you want to call
lto_prepare_function_for_streaming just once - for the function and not
for its clones.
> > Hence this callgraph is written out if the functions bodies were
> > loaded:
> > 
> >   main/1 ---> a.isra/3  --> b/2
> >  |   |
> >  call_stmt->uid == 0   call_stmt->uid == 2
> > so lto_stmt_uid == 1  so lto_stmt_uid == 3
> > 
> > 
> > At the ltrans stream-in, it reads in the edges, and then
> > calls fixup_call_stmt_edges_1 on both the original node *and* any
> > clones:
> > 
> > 1237fixup_call_stmt_edges_1 (orig, stmts, fn);
> > 1238  if (orig->clones)
> > 1239for (node = orig->clones; node != orig;)
> > 1240  {
> > 1241if (!node->thunk)
> > 1242  fixup_call_stmt_edges_1 (node, stmts, fn);

This is also intended - if you load the body and to maintain the
invariant above, you want to change the representation of all edges
(including those in clones)
> > 
> > WPA has renumbered the stmts in non-clone functions, but has not
> > renumbered them for clones.

And this is where things seem to be wrong - since function body is in
memory at WPA time, the uids sould be cleared by fixup_call_stmt_edges
at WPA time and thus edge->call_stmt != 0 for all callgraph edges in the
function and all its clones.
Consequently while streaming out we should use:
uid = !edge->call_stmt ? edge->lto_stmt_uid
   : gimple_uid (edge->call_stmt) + 1;
So all the uids should go from gimple_uid (edge->call_stmt) and those
all points to the call statements that has been renumbered
by lto_prepare_function.  So I do not see how these are going out of
sync.
> > 
> > Note that fixup_call_stmt_edges passes the same array of stmts to
> > both
> > calls to fixup_call_stmt_edges_1 (both the original and the clones)
> > i.e. it's trying to fixup the edges for "a.isra/3" with the stmts in
> > "a/0".   Should it be doing this?  "stmts" is constructed in
Yes, since these are same call statements (there is only one gimple body
around).
> > input_function by walking the BBs of cfun.  Is that going to find the
> > stmts of the clones?  (sorry, I'm not familiar with how clones work
> > within our IPA implementation).
> > 
> > fixup_call_stmt_edges_1 attempts to fixup the call edge from a.isra/3
> > to b/2, which has lto_stmt_uid == 3 and thus stmt->uid == 2, but
> > there
> > are only 2 stmts within the function "a/0", hence it's one past the
> > end
> > of the array, and fails 

Committed: gcc.dg/analyzer/data-model-1.c: Inverse xfail for cris-*-*, PR99212

[Hans-Peter Nilsson via Gcc-patches]

See PR99212.  Now, cris-elf isn't the only target for which this line
shows a failure; pru-unknown-elf and m68k-unknown-linux-gnu are two
others.  I'll leave adjustments to the respective maintainers, but
trivially appending more triplets should work: no extra bracketing needed.
A specific effective_target specifier would as always be perferable, but I
couldn't without accountable effort find out what was the common factor.

Besides cris-elf, sanity-checked for native x86_64-*-linux*.

gcc/testsuite:
PR analyzer/99212
* gcc.dg/analyzer/data-model-1.c (test_45): Inverse xfail at
line 971 for cris-*-*.
---
 gcc/testsuite/gcc.dg/analyzer/data-model-1.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/analyzer/data-model-1.c 
b/gcc/testsuite/gcc.dg/analyzer/data-model-1.c
index afd155694600..c0f54637693c 100644
--- a/gcc/testsuite/gcc.dg/analyzer/data-model-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/data-model-1.c
@@ -968,8 +968,8 @@ void test_45 (void)
 {
   struct ubits bits;
   bits.b0 = 1;
-  __analyzer_eval (bits.b0 == 1); /* { dg-warning "TRUE" "desired" { xfail 
*-*-* } } */
-  /* { dg-warning "UNKNOWN" "status quo" { target *-*-* } .-1 } */
+  __analyzer_eval (bits.b0 == 1); /* { dg-warning "TRUE" "desired, PR99212" { 
xfail { ! { cris-*-* } } } } */
+  /* { dg-warning "UNKNOWN" "status quo, PR99212" { target { *-*-* } xfail { 
cris-*-* } } .-1 } */
   // TODO(xfail): 
 
   bits.b456 = 5;
-- 
2.11.0

[committed] gimple UIDs, LTO and -fanalyzer [PR98599]

[David Malcolm via Gcc-patches]

On Thu, 2021-01-21 at 22:07 -0500, David Malcolm via Gcc-patches wrote:
> On Thu, 2021-01-21 at 20:09 +0100, Jan Hubicka wrote:
> > > On Thu, 2021-01-14 at 15:00 +0100, Jan Hubicka wrote:
> > > > > On Wed, Jan 13, 2021 at 11:04 PM David Malcolm via
> > > > > Gcc-patches
> > > > >  wrote:
> > > > > > gimple.h has this comment for gimple's uid field:
> > > > > > 
> > > > > >   /* UID of this statement.  This is used by passes that
> > > > > > want
> > > > > > to
> > > > > >  assign IDs to statements.  It must be assigned and
> > > > > > used
> > > > > > by
> > > > > > each
> > > > > >  pass.  By default it should be assumed to contain
> > > > > > garbage.  */
> > > > > >   unsigned uid;
> > > > > > 
> > > > > > and gimple_set_uid has:
> > > > > > 
> > > > > >Please note that this UID property is supposed to be
> > > > > > undefined
> > > > > > at
> > > > > >pass boundaries.  This means that a given pass should
> > > > > > not
> > > > > > assume it
> > > > > >contains any useful value when the pass starts and thus
> > > > > > can
> > > > > > set it
> > > > > >to any value it sees fit.
> > > > > > 
> > > > > > which suggests that any pass can use the uid field as an
> > > > > > arbitrary
> > > > > > scratch space.
> > > > > > 
> > > > > > PR analyzer/98599 reports a case where this error occurs in
> > > > > > LTO
> > > > > > mode:
> > > > > >   fatal error: Cgraph edge statement index out of range
> > > > > > on certain inputs with -fanalyzer.
> > > > > > 
> > > > > > The error occurs in the LTRANS phase after -fanalyzer runs
> > > > > > in
> > > > > > the
> > > > > > WPA phase.  The analyzer pass writes to the uid fields of
> > > > > > all
> > > > > > stmts.
> > > > > > 
> > > > > > The error occurs when LTRANS is streaming callgraph edges
> > > > > > back
> > > > > > in.
> > > > > > If I'm reading things correctly, the LTO format uses stmt
> > > > > > uids to
> > > > > > associate call stmts with callgraph edges between WPA and
> > > > > > LTRANS.
> > > > > > For example, in lto-cgraph.c, lto_output_edge writes out
> > > > > > the
> > > > > > gimple_uid, and input_edge reads it back in.
> > > > > > 
> > > > > > Hence IPA passes that touch the uids in WPA need to restore
> > > > > > them,
> > > > > > or the stream-in at LTRANS will fail.
> > > > > > 
> > > > > > Is it intended that the LTO machinery relies on the value
> > > > > > of
> > > > > > the
> > > > > > uid
> > > > > > field being preserved during WPA (or, at least, needs to be
> > > > > > saved
> > > > > > and
> > > > > > restored by passes that touch it)?
> > > > > 
> > > > > I belive this is solely at the cgraph stream out to stream in
> > > > > boundary but
> > > > > this may be a blurred area since while we materialize the
> > > > > whole
> > > > > cgraph
> > > > > at once the function bodies are streamed in on demand.
> > > > > 
> > > > > Honza can probably clarify things.
> > > > 
> > > > Well, the uids are used to associate cgraph edges with
> > > > statements.  At
> > > > WPA stage you do not have function bodies and thus uids serves
> > > > role
> > > > of
> > > > pointers to the statement.  If you load the body in (via
> > > > get_body)
> > > > the
> > > > uids are replaced by pointers and when you stream out uids are
> > > > recomputed again.
> > > > 
> > > > When do you touch the uids? At WPA time or from small IPA pass
> > > > in
> > > > ltrans?
> > > 
> > > The analyzer is here in passes.def:
> > >   INSERT_PASSES_AFTER (all_regular_ipa_passes)
> > >   NEXT_PASS (pass_analyzer);
> > > 
> > > and so in LTO runs as the first regular IPA pass at WPA time,
> > > when do_whole_program_analysis calls:
> > >   execute_ipa_pass_list (g->get_passes
> > > ()->all_regular_ipa_passes);
> > > 
> > > FWIW I hope to eventually have a way to summarize function bodies
> > > in
> > > the analyzer, but I don't yet, so I'm currently brute forcing
> > > things by
> > > loading all function bodies at the start of the analyzer (when
> > > -fanalyzer is enabled).
> > > 
> > > I wonder if that's messing things up somehow?
> > 
> > Actually I think it should work.  If you do get_body or
> > get_untransformed_body (that will be equal at that time) you ought
> > to
> > get ids in symtab datastructure rewritten to pointers and at stream
> > out
> > time we should assign new ids...
> > > Does the stream-out from WPA make any assumptions about the stmt
> > > uids?
> > > For example, 
> > >   #define STMT_UID_NOT_IN_RANGE(uid) \
> > > (gimple_stmt_max_uid (fn) < uid || uid == 0)
> > > seems to assume that the UIDs are per-function ranges from
> > >   [0-gimple_stmt_max_uid (fn)]
> > > which isn't the case for the uids set by the analyzer.  Maybe
> > > that's
> > > the issue here?
> > > 
> > > Sorry for not being more familiar with the IPA/LTO code
> > 
> > There is lto_prepare_function_for_streaming which assigns uids to
> > be
> > incremental.   So I guess problem is that it is not called at WPA
> > time
> > if function is in memory 

Re: [GCC 12] [PATCH v2] Add inline_ignore_target function attribute

[H.J. Lu via Gcc-patches]

On Mon, Apr 12, 2021 at 4:55 PM Martin Sebor  wrote:
>
> On 4/12/21 3:53 PM, H.J. Lu via Gcc-patches wrote:
> > On Mon, Apr 12, 2021 at 2:21 AM Richard Biener
> >  wrote:
> >>
> >> On Sat, Apr 10, 2021 at 5:11 PM H.J. Lu via Gcc-patches
> >>  wrote:
> >>>
> >>> Add inline_ignore_target function attribute to inform the compiler that
> >>> target specific option mismatch on functions with the always_inline
> >>> attribute may be ignored.  On x86 targets, this attribute can be used on
> >>> integer functions to ignore target non-integer option mismatch.
> >>
> >> I'm not sure I like such attribute but please adjust 
> >> default_target_can_inline_p
> >> accordingly (only few targets override this hook).
> >>
> >> Richard.
> >>
> >
> > Like this?
> >
> > Thanks.
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 1ddafb3ff2c..44588566f2d 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -3187,6 +3187,14 @@ int S::interface (int) __attribute__ ((ifunc
> ("_ZN1S8resolverEv")));
>   Indirect functions cannot be weak.  Binutils version 2.20.1 or higher
>   and GNU C Library version 2.11.1 are required to use this feature.
>
> +@item inline_ignore_target
> +@cindex @code{inline_ignore_target} function attribute
> +The @code{inline_ignore_target} attribute on functions is used to
> +inform the compiler that target specific option mismatch on functions
> +with the @code{always_inline} attribute may be ignored.  On x86 targets,
> +this attribute can be used on integer functions to ignore target
> +non-integer option mismatch.
> +
>   @item interrupt
>   @itemx interrupt_handler
>   Many GCC back ends support attributes to indicate that a function is
>
> I'm having a hard time understanding the description above (or
> the attribute's name for that matter).

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744

has a testcase.

>The inline_ignore_target function attribute informs the compiler
>that "target specific option mismatch on functions with the
>@code{always_inline} attribute" may be ignored.
>
> What does "target specific option mismatch" mean?  Is it a mismatch

This refers to the message from GCC:

/usr/gcc-11.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/ia32intrin.h:112:1:
error: inlining failed in call to ‘always_inline’ ‘__rdtsc’: target
specific option mismatch
  112 | __rdtsc (void)
  | ^~~

> between target-specific optimization options added to a function by
> attribute optimize vs other target-specific optimization options of
> the function callers (e.g., added to them by another instance of
> attribue optimize, or by #pragma GCC optimize), into which a function
> with the attribute may be inlined, and where the conflict between
> the two sets of options needs to be reconciled?  And if so, should

It is added to support integer functions with always_inline attribute.
Currently x86 integer functions with always_inline attribute fail to
compile when caller has general-regs-only target attribute and
SSE is enabled by default.

> it be provided as a generic attribute for all targets?

Different targets can have different sets of conflict target specific
options.

> Also, what's "integer functions" supposed to mean?  Functions that
> return integers?

An integer function can be compiled with -mgeneral-regs-only.

> This new attribute seems sufficiently specialized that I think
> the description ought to be expanded to make it clearer what it's
> for, why it's needed, and when and how to use it.  Adding an example
> or two might help, as would using more precise terminology.
>
> Separately, seeing no tests for it in the patch, I wonder how

There are 2 existing tests: gcc.target/i386/pr99744-1.c and
gcc.target/i386/pr99744-2.c.  If we want to go with this approach,
I will add inline_ignore_target to all x86 integer intrinsics with
tests.

> the new attribute interacts (or should interact) with other
> attributes or other kinds of functions than the ones it's tested
> with.  For example, what happens when the attribute is added to
> a function that's not declared inline, or that's declared with
> the noinline attribute.
>

This attribute should be used together with always_inline attribute.


-- 
H.J.

Re: [GCC 12] [PATCH v2] Add inline_ignore_target function attribute

[Martin Sebor via Gcc-patches]

On 4/12/21 3:53 PM, H.J. Lu via Gcc-patches wrote:

On Mon, Apr 12, 2021 at 2:21 AM Richard Biener
 wrote:


On Sat, Apr 10, 2021 at 5:11 PM H.J. Lu via Gcc-patches
 wrote:


Add inline_ignore_target function attribute to inform the compiler that
target specific option mismatch on functions with the always_inline
attribute may be ignored.  On x86 targets, this attribute can be used on
integer functions to ignore target non-integer option mismatch.


I'm not sure I like such attribute but please adjust default_target_can_inline_p
accordingly (only few targets override this hook).

Richard.



Like this?

Thanks.


diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 1ddafb3ff2c..44588566f2d 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3187,6 +3187,14 @@ int S::interface (int) __attribute__ ((ifunc 
("_ZN1S8resolverEv")));

 Indirect functions cannot be weak.  Binutils version 2.20.1 or higher
 and GNU C Library version 2.11.1 are required to use this feature.

+@item inline_ignore_target
+@cindex @code{inline_ignore_target} function attribute
+The @code{inline_ignore_target} attribute on functions is used to
+inform the compiler that target specific option mismatch on functions
+with the @code{always_inline} attribute may be ignored.  On x86 targets,
+this attribute can be used on integer functions to ignore target
+non-integer option mismatch.
+
 @item interrupt
 @itemx interrupt_handler
 Many GCC back ends support attributes to indicate that a function is

I'm having a hard time understanding the description above (or
the attribute's name for that matter).

  The inline_ignore_target function attribute informs the compiler
  that "target specific option mismatch on functions with the
  @code{always_inline} attribute" may be ignored.

What does "target specific option mismatch" mean?  Is it a mismatch
between target-specific optimization options added to a function by
attribute optimize vs other target-specific optimization options of
the function callers (e.g., added to them by another instance of
attribue optimize, or by #pragma GCC optimize), into which a function
with the attribute may be inlined, and where the conflict between
the two sets of options needs to be reconciled?  And if so, should
it be provided as a generic attribute for all targets?

Also, what's "integer functions" supposed to mean?  Functions that
return integers?

This new attribute seems sufficiently specialized that I think
the description ought to be expanded to make it clearer what it's
for, why it's needed, and when and how to use it.  Adding an example
or two might help, as would using more precise terminology.

Separately, seeing no tests for it in the patch, I wonder how
the new attribute interacts (or should interact) with other
attributes or other kinds of functions than the ones it's tested
with.  For example, what happens when the attribute is added to
a function that's not declared inline, or that's declared with
the noinline attribute.

Martin

Re: [PATCH] combine: Don't fold away side-effects in simplify_and_const_int_1 [PR99830]

[Segher Boessenkool]

Hi!

On Sat, Apr 10, 2021 at 08:02:29AM +0200, Jakub Jelinek wrote:
> Here is an alternate patch for the PR99830 bug.
> As discussed on IRC and in the PR, the reason why a (clobber:TI (const_int 0))
> has been propagated into the debug insns is that it got optimized away
> during simplification from the i3 instruction pattern.
> 
> And that happened because
> simplify_and_const_int_1 (SImode, varop, 255)
> with varop of
> (ashift:SI (subreg:SI (and:TI (clobber:TI (const_int 0 [0]))
> (const_int 255 [0xff])) 0)
>(const_int 16 [0x10]))
> was called and through nonzero_bits determined that (whatever << 16) & 255
> is const0_rtx.
> It is, but if there are side-effects in varop and such clobbers are
> considered as such, we shouldn't optimize those away.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Okay for trunk.  Thank you!

We'll need to audit all other code doing similar things as well, or add
some assert at some strategic spot.  Something for GCC 12 :-)


Segher

Re: [PATCH] combine: Avoid propagation of (clobber (const_int 0)) into DEBUG_INSNs [PR99830]

[Segher Boessenkool]

Hi!

On Fri, Apr 09, 2021 at 09:49:30AM +0200, Jakub Jelinek wrote:
> On the following testcase on aarch64 the combiner propagates
> (clobber:TI (const_int 0)) into a DEBUG_INSN.  Such clobbers are
> specific to the combiner, created by gen_lowpart_for_combine:
>  fail:
>   return gen_rtx_CLOBBER (omode, const0_rtx);
> which can be embedded anywhere and the combiner hopes they never match
> anything.

It doesn't just hope that, there is code all over the place that
guarantees this is true.  Yes, that isn't super robust, I agree.  But
that is what we have until someone manages to change it.

> That is hopefully the case of all instructions that go through
> recog, but for DEBUG_INSNs we don't have any strict rules on what matches
> and what doesn't and so if combiner calls propagate_for_debug with
> src containing such clobbers embedded in it, it will happily propagate it
> into DEBUG_INSNs and cause problems later (in this case ICEs during LRA).

It should never get that far.

(We talked about this; just adding it here to archive it for posterity.)


Segher

Re: [PATCH] c++: Reject alias CTAD in C++17 [PR99008]

[Patrick Palka via Gcc-patches]

On Mon, 12 Apr 2021, Jason Merrill wrote:

> On 4/10/21 3:57 PM, Patrick Palka wrote:
> > Here, in C++17 mode, we only pedwarn about the use of alias CTAD and
> > then later ICE from alias_ctad_tweaks when attempting to add a
> > constraint to one of the guides.  Since the construction of the guides
> > of an alias template effectively relies on concepts, we shouldn't be
> > permissive about alias CTAD in C++17 mode, so this patch turns the
> > pertinent pedwarn in do_class_deduction into an error.
> 
> Sounds good.
> 
> > In order to get a consistent diagnostic for B() vs the other forms in
> > the added testcase, I had to remove the special handling of CTAD with
> > empty initializer in build_functional_cast_1 so that we always pass
> > 'complain' to do_auto_deduction.
> 
> Did you compare the resulting diagnostics when deduction fails other than for
> trying to do alias deduction in C++17 mode?

For plain CTAD, e.g. for

  template  struct A { };
  auto a = A();

we previously emitted

test.C:2:10: error: cannot deduce template arguments for ‘A<...auto...>’ from 
‘()’
2 | auto a = A();
  |  ^~~

and now we emit

test.C:2:12: error: class template argument deduction failed:
2 | auto a = A();
  |^
test.C:2:12: error: no matching function for call to ‘A()’
test.C:1:27: note: candidate: ‘template A()-> A’
1 | template  struct A { };
  |   ^
test.C:1:27: note:   template argument deduction/substitution failed:
test.C:2:12: note:   couldn’t deduce template parameter ‘T’
2 | auto a = A();
  |^
test.C:1:27: note: candidate: ‘template A(A)-> A’
1 | template  struct A { };
  |   ^
test.C:1:27: note:   template argument deduction/substitution failed:
test.C:2:12: note:   candidate expects 1 argument, 0 provided
2 | auto a = A();
  |^

which is consistent with what we already emit for failed CTAD of the
form A{}, A(args) and A{args}.

I think this change should have no diagnostic/functional impact in other
deduction situations because the code path is guarded by a
CLASS_PLACEHOLDER_TEMPLATE check (and we create template placeholders
only in C++17 mode).

libgo patch committed: Update to Go1.16.3 release

[Ian Lance Taylor via Gcc-patches]

This patch updates libgo to the Go1.16.3 release.  Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
dfbc12e031900c1f30bb94332823d39e5b241b40
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index a3eef239eca..efb7a772882 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-4bdff733a0c2a9ddc3eff104b1be03df058a79c4
+9782e85bef1c16c72a4980856d921cea104b129c
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/MERGE b/libgo/MERGE
index a52dceb182f..81cd0623486 100644
--- a/libgo/MERGE
+++ b/libgo/MERGE
@@ -1,4 +1,4 @@
-3979fb9af9ccfc0b7ccb613dcf256b18c2c295f0
+9baddd3f21230c55f0ad2a10f5f20579dcf0a0bb
 
 The first line of this file holds the git revision number of the
 last merge done from the master library sources.
diff --git a/libgo/VERSION b/libgo/VERSION
index d0b0a900460..e592dfd1338 100644
--- a/libgo/VERSION
+++ b/libgo/VERSION
@@ -1 +1 @@
-go1.16.2
+go1.16.3
diff --git a/libgo/go/cmd/go.mod b/libgo/go/cmd/go.mod
index 35582f3975f..70b1b0690b3 100644
--- a/libgo/go/cmd/go.mod
+++ b/libgo/go/cmd/go.mod
@@ -6,7 +6,7 @@ require (
github.com/google/pprof v0.0.0-20201203190320-1bf35d6f28c2
golang.org/x/arch v0.0.0-20201008161808-52c3e6f60cff
golang.org/x/crypto v0.0.0-20201016220609-9e8e0b390897
-   golang.org/x/mod v0.4.2-0.20210302225053-d515b24adc21
+   golang.org/x/mod v0.4.2-0.20210325185522-dbbbf8a3c6ea
golang.org/x/sys v0.0.0-20201204225414-ed752295db88 // indirect
golang.org/x/tools v0.0.0-20210107193943-4ed967dd8eff
 )
diff --git a/libgo/go/cmd/go/alldocs.go b/libgo/go/cmd/go/alldocs.go
index e7c63f0749d..84f89c9d2d2 100644
--- a/libgo/go/cmd/go/alldocs.go
+++ b/libgo/go/cmd/go/alldocs.go
@@ -692,18 +692,22 @@
 // arguments must satisfy the following constraints:
 //
 // - Arguments must be package paths or package patterns (with "..." 
wildcards).
-//   They must not be standard packages (like fmt), meta-patterns (std, cmd,
-//   all), or relative or absolute file paths.
+// They must not be standard packages (like fmt), meta-patterns (std, cmd,
+// all), or relative or absolute file paths.
+//
 // - All arguments must have the same version suffix. Different queries are not
-//   allowed, even if they refer to the same version.
+// allowed, even if they refer to the same version.
+//
 // - All arguments must refer to packages in the same module at the same 
version.
+//
 // - No module is considered the "main" module. If the module containing
-//   packages named on the command line has a go.mod file, it must not contain
-//   directives (replace and exclude) that would cause it to be interpreted
-//   differently than if it were the main module. The module must not require
-//   a higher version of itself.
+// packages named on the command line has a go.mod file, it must not contain
+// directives (replace and exclude) that would cause it to be interpreted
+// differently than if it were the main module. The module must not require
+// a higher version of itself.
+//
 // - Package path arguments must refer to main packages. Pattern arguments
-//   will only match main packages.
+// will only match main packages.
 //
 // If the arguments don't have version suffixes, "go install" may run in
 // module-aware mode or GOPATH mode, depending on the GO111MODULE environment
diff --git a/libgo/go/cmd/go/internal/modfetch/cache.go 
b/libgo/go/cmd/go/internal/modfetch/cache.go
index 3a2ff63721c..07e046c8cba 100644
--- a/libgo/go/cmd/go/internal/modfetch/cache.go
+++ b/libgo/go/cmd/go/internal/modfetch/cache.go
@@ -84,6 +84,7 @@ func DownloadDir(m module.Version) (string, error) {
return "", err
}
 
+   // Check whether the directory itself exists.
dir := filepath.Join(cfg.GOMODCACHE, enc+"@"+encVer)
if fi, err := os.Stat(dir); os.IsNotExist(err) {
return dir, err
@@ -92,6 +93,9 @@ func DownloadDir(m module.Version) (string, error) {
} else if !fi.IsDir() {
return dir, {dir, errors.New("not a 
directory")}
}
+
+   // Check if a .partial file exists. This is created at the beginning of
+   // a download and removed after the zip is extracted.
partialPath, err := CachePath(m, "partial")
if err != nil {
return dir, err
@@ -101,6 +105,19 @@ func DownloadDir(m module.Version) (string, error) {
} else if !os.IsNotExist(err) {
return dir, err
}
+
+   // Check if a .ziphash file exists. It should be created before the
+   // zip is extracted, but if it was deleted (by another program?), we 
need
+   // to re-calculate it.
+   ziphashPath, err := CachePath(m, "ziphash")
+   if err != nil {
+   return dir, err
+   }
+   if _, err := os.Stat(ziphashPath); os.IsNotExist(err) {
+   return dir, {dir, 

Re: [PATCH] Fix logic error in 32-bit trampolines, PR target/98952

[will schmidt via Gcc-patches]

On Fri, 2021-04-09 at 17:09 -0400, Michael Meissner wrote:
> Fix logic error in 32-bit trampolines, PR target/98952.
> 
> The test in the PowerPC 32-bit trampoline support is backwards.  It aborts
> if the trampoline size is greater than the expected size.  It should abort
> when the trampoline size is less than the expected size.
> 
> I verified this by creating a 32-bit trampoline program and manually
> changing the size of the trampoline to be 48 instead of 40.  The program
> aborted with the larger size.  I updated this code and ran the test again
> and it passed.
> 
> I did a bootstrap build on a big endian power8 system that supports both
> 32-bit and 64-bit executables, and there were no regressions.  Can I check
> this patch into the trunk?
> 
> libgcc/
> 2021-04-09  Michael Meissner  
> 
>   PR target/98952
>   * config/rs6000/tramp.S (__trampoline_setup): Fix trampoline size
>   comparison in 32-bit.
> ---
>  libgcc/config/rs6000/tramp.S | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libgcc/config/rs6000/tramp.S b/libgcc/config/rs6000/tramp.S
> index 4236a82b402..6b61d892da6 100644
> --- a/libgcc/config/rs6000/tramp.S
> +++ b/libgcc/config/rs6000/tramp.S
> @@ -64,8 +64,7 @@ FUNC_START(__trampoline_setup)
>  mflr r11
>  addi r7,r11,trampoline_initial-4-.LCF0 /* trampoline address -4 */
> 
> - li  r8,trampoline_size  /* verify that the trampoline is big 
> enough */
> - cmpwcr1,r8,r4
> + cmpwi   cr1,r4,trampoline_size  /* verify that the trampoline is big 
> enough */


Hmm, I spent several minutes trying to determine how cmpw behaves
differently than cmpwi before noticing you also swapped the
order of the r4,r8 operands. 

That seems OK.

A statement in the description indicating that you used a cmpwi instead
of a cmpw since you were in the neighborhood would help call that out. 


The #elif  _CALL_ELF == 2  portion of tramp.S (line 159 or so) has a
similar compare stanza with respect to the order of operands on the
compare.  Will this also have a backwards greater-than less-than issue?

li  r8,trampoline_size  /* verify that the trampoline is big 
enough */
cmpwcr1,r8,r4
srwir4,r4,3 /* # doublewords to move */
addir9,r3,-8/* adjust pointer for stdu */
mtctr   r4
blt cr1,.Labort




thanks
-Will


>   srwir4,r4,2 /* # words to move */
>   addir9,r3,-4/* adjust pointer for lwzu */
>   mtctr   r4
> -- 
> 2.22.0
> 
> 

[GCC 12] [PATCH v2] Add inline_ignore_target function attribute

[H.J. Lu via Gcc-patches]

On Mon, Apr 12, 2021 at 2:21 AM Richard Biener
 wrote:
>
> On Sat, Apr 10, 2021 at 5:11 PM H.J. Lu via Gcc-patches
>  wrote:
> >
> > Add inline_ignore_target function attribute to inform the compiler that
> > target specific option mismatch on functions with the always_inline
> > attribute may be ignored.  On x86 targets, this attribute can be used on
> > integer functions to ignore target non-integer option mismatch.
>
> I'm not sure I like such attribute but please adjust 
> default_target_can_inline_p
> accordingly (only few targets override this hook).
>
> Richard.
>

Like this?

Thanks.

-- 
H.J.
From 2ad302dd41978b87fdf8623c6943e2b3b981be2a Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Sat, 10 Apr 2021 07:45:35 -0700
Subject: [PATCH v2] Add inline_ignore_target function attribute

Add inline_ignore_target function attribute to inform the compiler that
target specific option mismatch on functions with the always_inline
attribute may be ignored.  On x86 targets, this attribute can be used on
integer functions to ignore target non-integer option mismatch.

gcc/c-family/

	PR target/99744
	* c-family/c-attribs.c (c_common_attribute_table): Add
	inline_ignore_target.

gcc/

	PR target/99744
	* targhooks.c (default_target_can_inline_p): Use the default
	target option for callee if it has inline_ignore_target function
	attribute.
	* common/config/i386/i386-common.c (OPTION_MASK_*) to ...
	* common/config/i386/i386-common.h: Here.  New file.
	* config/i386/i386.c (ix86_can_inline_p): Ignore target
	non-integer option mismatch if callee has inline_ignore_target
	attribute.
	* config/i386/i386.h: Include common/config/i386/i386-common.h.
	* config/i386/ia32intrin.h (__rdtsc): Use always_inline function
	with inline_ignore_target attribute.
	(__rdtscp): Likewise.
	* config/i386/serializeintrin.h (_serialize): Likewise.
	* doc/extend.texi: Document inline_ignore_target function
	attribute.

gcc/testsuite/

	PR target/99744
	* gcc.target/i386/pr99744-3.c: New test.
---
 gcc/c-family/c-attribs.c  |   2 +
 gcc/common/config/i386/i386-common.c  | 297 
 gcc/common/config/i386/i386-common.h  | 315 ++
 gcc/config/i386/i386.c|  29 +-
 gcc/config/i386/i386.h|   1 +
 gcc/config/i386/ia32intrin.h  |  16 +-
 gcc/config/i386/serializeintrin.h |   8 +-
 gcc/doc/extend.texi   |   8 +
 gcc/targhooks.c   |  13 +-
 gcc/testsuite/gcc.target/i386/pr99744-3.c |  13 +
 10 files changed, 394 insertions(+), 308 deletions(-)
 create mode 100644 gcc/common/config/i386/i386-common.h
 create mode 100644 gcc/testsuite/gcc.target/i386/pr99744-3.c

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index c1f652d1dc9..863936af7ca 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -323,6 +323,8 @@ const struct attribute_spec c_common_attribute_table[] =
 	  attr_inline_exclusions },
   { "artificial", 0, 0, true,  false, false, false,
 			  handle_artificial_attribute, NULL },
+  { "inline_ignore_target",   0, 0, true,  false, false, false,
+			  handle_artificial_attribute, NULL },
   { "flatten",0, 0, true,  false, false, false,
 			  handle_flatten_attribute, NULL },
   { "used",   0, 0, true,  false, false, false,
diff --git a/gcc/common/config/i386/i386-common.c b/gcc/common/config/i386/i386-common.c
index 1e6c1590ac4..37ff47bd676 100644
--- a/gcc/common/config/i386/i386-common.c
+++ b/gcc/common/config/i386/i386-common.c
@@ -29,303 +29,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "opts.h"
 #include "flags.h"
 
-/* Define a set of ISAs which are available when a given ISA is
-   enabled.  MMX and SSE ISAs are handled separately.  */
-
-#define OPTION_MASK_ISA_MMX_SET OPTION_MASK_ISA_MMX
-#define OPTION_MASK_ISA_3DNOW_SET \
-  (OPTION_MASK_ISA_3DNOW | OPTION_MASK_ISA_MMX_SET)
-#define OPTION_MASK_ISA_3DNOW_A_SET \
-  (OPTION_MASK_ISA_3DNOW_A | OPTION_MASK_ISA_3DNOW_SET)
-
-#define OPTION_MASK_ISA_SSE_SET OPTION_MASK_ISA_SSE
-#define OPTION_MASK_ISA_SSE2_SET \
-  (OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_SSE_SET)
-#define OPTION_MASK_ISA_SSE3_SET \
-  (OPTION_MASK_ISA_SSE3 | OPTION_MASK_ISA_SSE2_SET)
-#define OPTION_MASK_ISA_SSSE3_SET \
-  (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_SSE3_SET)
-#define OPTION_MASK_ISA_SSE4_1_SET \
-  (OPTION_MASK_ISA_SSE4_1 | OPTION_MASK_ISA_SSSE3_SET)
-#define OPTION_MASK_ISA_SSE4_2_SET \
-  (OPTION_MASK_ISA_SSE4_2 | OPTION_MASK_ISA_SSE4_1_SET)
-#define OPTION_MASK_ISA_AVX_SET \
-  (OPTION_MASK_ISA_AVX | OPTION_MASK_ISA_SSE4_2_SET \
-   | OPTION_MASK_ISA_XSAVE_SET)
-#define OPTION_MASK_ISA_FMA_SET \
-  (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_AVX_SET)
-#define OPTION_MASK_ISA_AVX2_SET \
-  (OPTION_MASK_ISA_AVX2 | OPTION_MASK_ISA_AVX_SET)
-#define OPTION_MASK_ISA_FXSR_SET OPTION_MASK_ISA_FXSR
-#define 

[pushed] c++: premature overload resolution [PR93085]

[Jason Merrill via Gcc-patches]

We can't resolve the call to foo<42> before instantiation of G, because the
template parameter of #1 has dependent type.  But we were missing that in
our dependency check, because the tree walk of DECL_TEMPLATE_PARMS doesn't
look into the types of template parameters.  So look at them directly.

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

gcc/cp/ChangeLog:

PR c++/93085
* pt.c (uses_outer_template_parms): Handle non-type and template
template parameters specifically.

gcc/testsuite/ChangeLog:

PR c++/93085
* g++.dg/template/dependent-tmpl1.C: New test.
---
 gcc/cp/pt.c   | 21 ++-
 .../g++.dg/template/dependent-tmpl1.C |  9 
 2 files changed, 25 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/template/dependent-tmpl1.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index abd1ad4d1a6..efcbc59f5c9 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10846,11 +10846,22 @@ uses_outer_template_parms (tree decl)
  , NULL, /*include_nondeduced_p=*/true))
 return true;
   if (PRIMARY_TEMPLATE_P (decl)
-  && for_each_template_parm (INNERMOST_TEMPLATE_PARMS
-(DECL_TEMPLATE_PARMS (decl)),
-template_parm_outer_level,
-, NULL, /*include_nondeduced_p=*/true))
-return true;
+  || DECL_TEMPLATE_TEMPLATE_PARM_P (decl))
+{
+  tree parms = INNERMOST_TEMPLATE_PARMS (DECL_TEMPLATE_PARMS (decl));
+  for (int i = TREE_VEC_LENGTH (parms) - 1; i >= 0; --i)
+   {
+ tree parm = TREE_VALUE (TREE_VEC_ELT (parms, i));
+ if (TREE_CODE (parm) == PARM_DECL
+ && for_each_template_parm (TREE_TYPE (parm),
+template_parm_outer_level,
+, NULL, /*nondeduced*/true))
+   return true;
+ if (TREE_CODE (parm) == TEMPLATE_DECL
+ && uses_outer_template_parms (parm))
+   return true;
+   }
+}
   tree ci = get_constraints (decl);
   if (ci)
 ci = CI_ASSOCIATED_CONSTRAINTS (ci);
diff --git a/gcc/testsuite/g++.dg/template/dependent-tmpl1.C 
b/gcc/testsuite/g++.dg/template/dependent-tmpl1.C
new file mode 100644
index 000..7b800b6869a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/dependent-tmpl1.C
@@ -0,0 +1,9 @@
+// PR c++/93085
+// { dg-do compile { target c++11 } }
+
+template
+struct G {
+template static int foo();// #1
+template static int foo();  // #2
+int x = foo<42>();  // OK
+};

base-commit: 7650259de8f86c403113f7186d82737eddb65ef6
-- 
2.27.0

Re: [PATCH] c++: constraints are unevaluated operands [PR99961]

[Jason Merrill via Gcc-patches]

On 4/11/21 11:37 AM, Patrick Palka wrote:

According to [temp.concept]/6 and [temp.pre]/9, a concept definition and
a requires clause are both unevaluated contexts, and hence satisfaction
deals only with unevaluated operands, so we should set cp_unevaluated
in these three situations.

(I guess we should set cp_unevaluated during normalization too, but I
wasn't able to construct a testcase for which it makes a difference.)

Bootstrapped and regtested on x86_64-pc-linux-gnu, and also tested on
cmcstl2 and range-v3, does this look OK for trunk?

gcc/cp/ChangeLog:

PR c++/99961
* constraint.cc (satisfy_normalized_constraints): Set
cp_unevaluated.
* parser.c (cp_parser_concept_definition): Likewise.
(cp_parser_requires_clause_opt): Likewise.

gcc/testsuite/ChangeLog:

PR c++/99961
* g++.dg/cpp2a/concepts-uneval1.C: New test.
---
  gcc/cp/constraint.cc  |  3 +++
  gcc/cp/parser.c   |  6 ++
  gcc/testsuite/g++.dg/cpp2a/concepts-uneval1.C | 10 ++
  3 files changed, 19 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-uneval1.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 0ddb2990dd9..6c8e29d809f 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3066,6 +3066,9 @@ satisfy_normalized_constraints (tree t, tree args, 
sat_info info)
/* We need to check access during satisfaction.  */
deferring_access_check_sentinel acs (dk_no_deferred);
  
+  /* Constraints are an unevaluated operands.  */


OK fixing the grammar of this sentence.


+  cp_unevaluated u;
+
return satisfy_constraint_r (t, args, info);
  }
  
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c

index b6f94bdda23..8b7801b2be7 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -28353,6 +28353,9 @@ cp_parser_label_declaration (cp_parser* parser)
  static tree
  cp_parser_concept_definition (cp_parser *parser)
  {
+  /* A concept definition is an unevaluated context.  */
+  cp_unevaluated u;
+
gcc_assert (cp_lexer_next_token_is_keyword (parser->lexer, RID_CONCEPT));
cp_lexer_consume_token (parser->lexer);
  
@@ -28714,6 +28717,9 @@ cp_parser_constraint_expression (cp_parser *parser)

  static tree
  cp_parser_requires_clause_opt (cp_parser *parser, bool lambda_p)
  {
+  /* A requires clause is an unevaluated context.  */
+  cp_unevaluated u;
+
cp_token *tok = cp_lexer_peek_token (parser->lexer);
if (tok->keyword != RID_REQUIRES)
  {
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-uneval1.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-uneval1.C
new file mode 100644
index 000..4c5f1b5c019
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-uneval1.C
@@ -0,0 +1,10 @@
+// PR c++/99961
+// { dg-do compile { target c++20 } }
+
+struct A { static const int x = 42; bool y; };
+
+void f(auto a) requires (a.x == 42) { }
+template void f(A);
+
+template  concept C = V || A::y;
+static_assert(C);

Re: [PATCH] c++: variadic class placeholder template deduction [PR97134]

[Jason Merrill via Gcc-patches]

On 4/9/21 5:25 PM, Patrick Palka wrote:

do_class_deduction handles specially the case where we're deducing one
placeholder from another equivalent one, but here the initializer passed
to do_class_deduction is wrapped in an EXPR_PACK_EXPANSION (we're being
called from unify during get_partial_spec_bindings).  This patch makes
do_class_deduction look through EXPR_PACK_EXPANSIONs so that we detect
this case as well.

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


OK for trunk.


gcc/cp/ChangeLog:

PR c++/97134
* pt.c (do_class_deduction): Look through EXPR_PACK_EXPANSION
when checking if the initializer is an equivalent class
placeholder template parameter.

gcc/testsuite/ChangeLog:

PR c++/97134
* g++.dg/cpp2a/nontype-class43.C: New test.
---
  gcc/cp/pt.c  |  6 +-
  gcc/testsuite/g++.dg/cpp2a/nontype-class43.C | 11 +++
  2 files changed, 16 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class43.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 01c807be1bb..872b08ec9ad 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29265,7 +29265,11 @@ do_class_deduction (tree ptype, tree tmpl, tree init,
  return ptype;
  
/* Initializing one placeholder from another.  */

-  if (init && TREE_CODE (init) == TEMPLATE_PARM_INDEX
+  if (init
+  && (TREE_CODE (init) == TEMPLATE_PARM_INDEX
+ || (TREE_CODE (init) == EXPR_PACK_EXPANSION
+ && (TREE_CODE (PACK_EXPANSION_PATTERN (init))
+ == TEMPLATE_PARM_INDEX)))
&& is_auto (TREE_TYPE (init))
&& CLASS_PLACEHOLDER_TEMPLATE (TREE_TYPE (init)) == tmpl)
  return cp_build_qualified_type (TREE_TYPE (init), cp_type_quals (ptype));
diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-class43.C 
b/gcc/testsuite/g++.dg/cpp2a/nontype-class43.C
new file mode 100644
index 000..f51684f7a62
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/nontype-class43.C
@@ -0,0 +1,11 @@
+// PR c++/97134
+// { dg-do compile { target c++20 } }
+
+template
+struct templ {};
+
+template
+struct wrapper {};
+
+template requires true
+struct wrapper {};

Re: [PATCH] c++: Reject alias CTAD in C++17 [PR99008]

[Jason Merrill via Gcc-patches]

On 4/10/21 3:57 PM, Patrick Palka wrote:

Here, in C++17 mode, we only pedwarn about the use of alias CTAD and
then later ICE from alias_ctad_tweaks when attempting to add a
constraint to one of the guides.  Since the construction of the guides
of an alias template effectively relies on concepts, we shouldn't be
permissive about alias CTAD in C++17 mode, so this patch turns the
pertinent pedwarn in do_class_deduction into an error.


Sounds good.


In order to get a consistent diagnostic for B() vs the other forms in
the added testcase, I had to remove the special handling of CTAD with
empty initializer in build_functional_cast_1 so that we always pass
'complain' to do_auto_deduction.


Did you compare the resulting diagnostics when deduction fails other 
than for trying to do alias deduction in C++17 mode?



Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

gcc/cp/ChangeLog:

PR c++/99008
* pt.c (do_class_deduction): Reject alias CTAD in C++17 mode
rather than issuing a pedwarn.
* typeck2.c (build_functional_cast_1): Handle CTAD uniformly.

gcc/testsuite/ChangeLog:

PR c++/99008
* g++.dg/parse/template2.C: Adjust expected diagnostic.
* g++.dg/template/error8.C: Likewise.
* g++.dg/cpp1z/class-deduction84.C: New test.
---
  gcc/cp/pt.c|  8 
  gcc/cp/typeck2.c   | 17 +++--
  gcc/testsuite/g++.dg/cpp1z/class-deduction84.C |  9 +
  gcc/testsuite/g++.dg/parse/template2.C |  2 +-
  gcc/testsuite/g++.dg/template/error8.C |  2 +-
  5 files changed, 18 insertions(+), 20 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction84.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index abd1ad4d1a6..40458102304 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29290,10 +29290,10 @@ do_class_deduction (tree ptype, tree tmpl, tree init,
  }
else if (cxx_dialect < cxx20 && DECL_ALIAS_TEMPLATE_P (tmpl))
  {
-  /* This doesn't affect conforming C++17 code, so just pedwarn.  */
-  if (complain & tf_warning_or_error)
-   pedwarn (input_location, 0, "alias template deduction only available "
-"with %<-std=c++20%> or %<-std=gnu++20%>");
+  if (complain & tf_error)
+   error ("alias template deduction only available "
+  "with %<-std=c++20%> or %<-std=gnu++20%>");
+  return error_mark_node;
  }
  
tree type = TREE_TYPE (tmpl);

diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index a58d397ca3f..4e9632f6a7d 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -2197,24 +2197,13 @@ build_functional_cast_1 (location_t loc, tree exp, tree 
parms,
error_at (loc, "invalid use of %qT", anode);
  return error_mark_node;
}
-  else if (!parms)
+  else
{
- /* Even if there are no parameters, we might be able to deduce from
-default template arguments.  Pass TF_NONE so that we don't
-generate redundant diagnostics.  */
- type = do_auto_deduction (type, parms, anode, tf_none,
+ type = do_auto_deduction (type, parms, anode, complain,
adc_variable_type);
  if (type == error_mark_node)
-   {
- if (complain & tf_error)
-   error_at (loc, "cannot deduce template arguments "
- "for %qT from %<()%>", anode);
- return error_mark_node;
-   }
+   return error_mark_node;
}
-  else
-   type = do_auto_deduction (type, parms, anode, complain,
- adc_variable_type);
  }
  
if (processing_template_decl)

diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction84.C 
b/gcc/testsuite/g++.dg/cpp1z/class-deduction84.C
new file mode 100644
index 000..29f25e50c9e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction84.C
@@ -0,0 +1,9 @@
+// PR c++/99008
+// { dg-do compile { target c++17 } }
+
+template  struct A { A(int = 0); };
+template  using B = A;
+auto x = B{};  // { dg-error "alias template deduction only available with" "" 
{ target c++17_only } }
+auto y = B();  // { dg-error "alias template deduction only available with" "" 
{ target c++17_only } }
+auto z = B{1}; // { dg-error "alias template deduction only available with" "" 
{ target c++17_only } }
+auto w = B(1); // { dg-error "alias template deduction only available with" "" 
{ target c++17_only } }
diff --git a/gcc/testsuite/g++.dg/parse/template2.C 
b/gcc/testsuite/g++.dg/parse/template2.C
index 3cb27a85c00..3cafd9f1f01 100644
--- a/gcc/testsuite/g++.dg/parse/template2.C
+++ b/gcc/testsuite/g++.dg/parse/template2.C
@@ -3,6 +3,6 @@ namespace N {
  }
  
  int main() {

-  N::C(); // { dg-error "6:cannot deduce template arguments" "" { target c++17 
} }
+  N::C(); // { dg-error "8:class template argument deduction failed|no match" 
"" { target c++17 } 

Re: [PATCH] combine: Fix up expand_compound_operation [PR99905]

[Segher Boessenkool]

Hi!

On Thu, Apr 08, 2021 at 11:24:04AM +0200, Jakub Jelinek wrote:

[ snip great explanation ]

> The following patch fixes it, by doing the shift in inner_mode properly
> and then after the shift doing the lowpart subreg and masking already
> in mode.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Okay for trunk.  Thank you!


Segher


> 2021-04-08  Jakub Jelinek  
> 
>   PR rtl-optimization/99905
>   * combine.c (expand_compound_operation): If pos + len > modewidth,
>   perform the right shift by pos in inner_mode and then convert to mode,
>   instead of trying to simplify a shift of rtx with inner_mode by pos
>   as if it was a shift in mode.
> 
>   * gcc.target/i386/pr99905.c: New test.

Re: enable __ieee128 for p9vector tests

[Segher Boessenkool]

Hi!

Sorry for the late answer.

On Fri, Apr 02, 2021 at 01:52:59PM -0300, Alexandre Oliva wrote:
> Several compile tests that use the __ieee128 type do not ensure it is
> defined.  This patch adds -mfloat128 to their command lines, and
> disregards the warning that may be issued by it.

But they do make sure it is defined, they use -mcpu=power9 (etc.).  What
is different in your setup that that does not work?


Segher

[PATCH] simplify-rtx: Punt on simplify_{,gen_}subreg to IBM double double if bits are lost [PR99648]

[Jakub Jelinek via Gcc-patches]

Hi!

Similarly to PR95450 done on GIMPLE, this patch punts if we try to
simplify_{gen_,}subreg from some constant into the IBM double double
IFmode (or sometimes TFmode) if the double double format wouldn't preserve
the bits.  Not all values are valid in IBM double double, e.g. the format
requires that the upper double is the whole value rounded to double, and
if in some cases such as in the pr71522.c testcase with -m32 -Os -mcpu=power7
some non-floating data is copied through long double variable, we can
simplify a subreg into something that has different value.

Fixed by punting if the planned simplify_immed_subreg result doesn't
encode to bitwise identical values compared to what we were decoding.

As for the simplify_gen_subreg change, I think it would be desirable
to just avoid creating SUBREGs of constants on all targets and for all
constants, if simplify_immed_subreg simplified, fine, otherwise punt,
but as we are late in GCC11 development, the patch instead guards this
behavior on MODE_COMPOSITE_P (outermode) - i.e. only conversions to
powerpc{,64,64le} double double long double - and only for the cases where
simplify_immed_subreg was called.

Bootstrapped/regtested on powerpc64{,le}-linux, on powerpc64-linux tested
with -m32/-m64, ok for trunk?

2021-04-12  Jakub Jelinek  

PR target/99648
* simplify-rtx.c (simplify_immed_subreg): For MODE_COMPOSITE_P
outermode, return NULL if the result doesn't encode back to the
original byte sequence.
(simplify_gen_subreg): Don't create SUBREGs from constants to
MODE_COMPOSITE_P outermode.

--- gcc/simplify-rtx.c.jj   2021-04-10 12:45:22.189863341 +0200
+++ gcc/simplify-rtx.c  2021-04-12 12:06:01.469088000 +0200
@@ -7035,12 +7035,19 @@ simplify_immed_subreg (fixed_size_mode o
   while (buffer.length () < buffer_bytes)
buffer.quick_push (filler);
 }
-  else
+  else if (!native_encode_rtx (innermode, x, buffer, first_byte, inner_bytes))
+return NULL_RTX;
+  rtx ret = native_decode_rtx (outermode, buffer, 0);
+  if (ret && MODE_COMPOSITE_P (outermode))
 {
-  if (!native_encode_rtx (innermode, x, buffer, first_byte, inner_bytes))
+  auto_vec buffer2 (buffer_bytes);
+  if (!native_encode_rtx (outermode, ret, buffer2, 0, buffer_bytes))
return NULL_RTX;
-  }
-  return native_decode_rtx (outermode, buffer, 0);
+  for (unsigned int i = 0; i < buffer_bytes; ++i)
+   if (buffer[i] != buffer2[i])
+ return NULL_RTX;
+}
+  return ret;
 }
 
 /* Simplify SUBREG:OUTERMODE(OP:INNERMODE, BYTE)
@@ -7336,6 +7343,13 @@ simplify_context::simplify_gen_subreg (m
   || GET_MODE (op) == VOIDmode)
 return NULL_RTX;
 
+  if (MODE_COMPOSITE_P (outermode)
+  && (CONST_SCALAR_INT_P (op)
+ || CONST_DOUBLE_AS_FLOAT_P (op)
+ || CONST_FIXED_P (op)
+ || GET_CODE (op) == CONST_VECTOR))
+return NULL_RTX;
+
   if (validate_subreg (outermode, innermode, op, byte))
 return gen_rtx_SUBREG (outermode, op, byte);
 

Jakub

Patch ping for PR95176 fix

[Victor Tong via Gcc-patches]

Hello,

I'd like to ping this patch. It contains two new tree-opt patterns in match.pd.

[PATCH] tree-optimization: Optimize division followed by multiply [PR95176] 
(gnu.org)

Thanks,
Victor

[PATCH] c++: do_class_deduction and dependent init [PR93383]

[Patrick Palka via Gcc-patches]

Here we're crashing during deduction for a template placeholder from a
dependent initializer because one of the initializer's elements has an
empty TREE_TYPE, something which resolve_args and later unify_one_argument
don't expect.  And if the deduction from a dependent initializer
otherwise fails, we prematurely issue an error rather than reattempting
the deduction at instantiation time.

This patch makes do_class_deduction more tolerant about dependent
initializers, in a manner similar to what do_auto_deduction does: if
deduction from a dependent initializer fails, just return the original
placeholder unchanged.

Bootstrapped and regtested on x86_64-pc-linux-gnu, and also tested on
cmcstl2 and range-v3, and on all the testcases in PR93383, does this
look OK for trunk?

gcc/cp/ChangeLog:

PR c++/89565
PR c++/93383
PR c++/99200
* pt.c (do_class_deduction): If an argument has no type, don't
attempt deduction.  If deduction fails and the initializer is
type-dependent, try again at instantiation time.

gcc/testsuite/ChangeLog:

PR c++/89565
PR c++/93383
PR c++/99200
* g++.dg/cpp2a/nontype-class39.C: Remove dg-ice.
* g++.dg/cpp2a/nontype-class44.C: New test.
* g++.dg/cpp2a/nontype-class45.C: New test.
---
 gcc/cp/pt.c  | 11 +++
 gcc/testsuite/g++.dg/cpp2a/nontype-class39.C |  1 -
 gcc/testsuite/g++.dg/cpp2a/nontype-class44.C | 11 +++
 gcc/testsuite/g++.dg/cpp2a/nontype-class45.C | 32 
 4 files changed, 54 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class44.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class45.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 0ce7fa359c1..612feac7976 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29334,6 +29334,13 @@ do_class_deduction (tree ptype, tree tmpl, tree init,
   else
 args = make_tree_vector_single (init);
 
+  /* If an argument is missing its type, we can't possibly deduce from this
+ (type-dependent) initializer ahead of time.  */
+  if (processing_template_decl)
+for (tree arg : *args)
+  if (!TREE_TYPE (arg))
+   return ptype;
+
   /* Do this now to avoid problems with erroneous args later on.  */
   args = resolve_args (args, complain);
   if (args == NULL)
@@ -29419,6 +29426,10 @@ do_class_deduction (tree ptype, tree tmpl, tree init,
 
   if (call == error_mark_node)
 {
+  if (type_dependent_expression_p (init))
+   /* Try again at instantiation time.  */
+   return ptype;
+
   if (complain & tf_warning_or_error)
{
  error ("class template argument deduction failed:");
diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-class39.C 
b/gcc/testsuite/g++.dg/cpp2a/nontype-class39.C
index f5f79a71ec2..9b4da4f02ea 100644
--- a/gcc/testsuite/g++.dg/cpp2a/nontype-class39.C
+++ b/gcc/testsuite/g++.dg/cpp2a/nontype-class39.C
@@ -1,6 +1,5 @@
 // PR c++/89565
 // { dg-do compile { target c++20 } }
-// { dg-ice "resolve_args" }
 
 template 
 struct N{};
diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-class44.C 
b/gcc/testsuite/g++.dg/cpp2a/nontype-class44.C
new file mode 100644
index 000..d91e800424f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/nontype-class44.C
@@ -0,0 +1,11 @@
+// PR c++/93383
+// { dg-do compile { target c++20 } }
+
+template  struct A {};
+
+template  struct B {
+  void foo(B<+a>);
+  void bar(B);
+  template  using type = B;
+  template  static inline auto y = A{0}; // { dg-error "deduction|no 
match" }
+};
diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-class45.C 
b/gcc/testsuite/g++.dg/cpp2a/nontype-class45.C
new file mode 100644
index 000..e7addf5f291
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/nontype-class45.C
@@ -0,0 +1,32 @@
+// PR c++/99200
+// { dg-do compile { target c++20 } }
+
+template 
+struct A
+{
+  constexpr A (const char ()[N]) { for (int i = 0; i < N; i++) v[i] = s[i]; 
v[N] = 0; }
+  char v[N + 1];
+};
+
+template 
+struct B
+{
+  constexpr operator const char *() { return s.v; }
+};
+
+template 
+const char *
+foo ()
+{ 
+  return B<__PRETTY_FUNCTION__>{};
+}
+
+template 
+const char *
+bar ()
+{ 
+  return B<__FUNCTION__>{};
+}
+
+auto a = foo  ();
+auto b = bar  ();
-- 
2.31.1.272.g89b43f80a5

New Swedish PO file for 'gcc' (version 11.1-b20210321)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

https://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-11.1-b20210321.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[r11-8133 Regression] Failed to bootstrap on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

bb8f2c32306445979be10a91bd4a3febf34c554e is the first bad commit
commit bb8f2c32306445979be10a91bd4a3febf34c554e
Author: Martin Liska 
Date:   Mon Apr 12 13:42:33 2021 +0200

docs: update symver attribute description

caused build failure when configured with:

../gcc/configure --with-arch=skylake-avx512 --with-cpu=skylake-avx512  
--enable-clocale=gnu --with-system-zlib --enable-shared --enable-cet 
--with-demangler-in-ld --enable-libmpx --with-fpmath=sse 

Build log(last 100 lines):

g++ -std=c++11 -c   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE -fno-PIE 
-I. -Ibuild -I../../../gcc/gcc -I../../../gcc/gcc/build 
-I../../../gcc/gcc/../include  -I../../../gcc/gcc/../libcpp/include  \
-o build/genconditions.o ../../../gcc/gcc/genconditions.c
g++ -std=c++11 -c   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE -fno-PIE 
-I. -Ibuild -I../../../gcc/gcc -I../../../gcc/gcc/build 
-I../../../gcc/gcc/../include  -I../../../gcc/gcc/../libcpp/include  \
-o build/genattr.o ../../../gcc/gcc/genattr.c
g++ -std=c++11 -c   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE -fno-PIE 
-I. -Ibuild -I../../../gcc/gcc -I../../../gcc/gcc/build 
-I../../../gcc/gcc/../include  -I../../../gcc/gcc/../libcpp/include  \
-o build/genattr-common.o ../../../gcc/gcc/genattr-common.c
g++ -std=c++11 -c   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE -fno-PIE 
-I. -Ibuild -I../../../gcc/gcc -I../../../gcc/gcc/build 
-I../../../gcc/gcc/../include  -I../../../gcc/gcc/../libcpp/include  \
-o build/gencodes.o ../../../gcc/gcc/gencodes.c
g++ -std=c++11 -c   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE -fno-PIE 
-I. -Ibuild -I../../../gcc/gcc -I../../../gcc/gcc/build 
-I../../../gcc/gcc/../include  -I../../../gcc/gcc/../libcpp/include  \
-o build/genconfig.o ../../../gcc/gcc/genconfig.c
g++ -std=c++11 -c   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE -fno-PIE 
-I. -Ibuild -I../../../gcc/gcc -I../../../gcc/gcc/build 
-I../../../gcc/gcc/../include  -I../../../gcc/gcc/../libcpp/include  \
-o build/gentarget-def.o ../../../gcc/gcc/gentarget-def.c
cp doc/gcc.1 doc/g++.1
g++ -std=c++11   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE -fno-PIE 
-static-libstdc++ -static-libgcc  -no-pie -o build/gencfn-macros \
build/gencfn-macros.o build/errors.o build/hash-table.o build/vec.o 
build/ggc-none.o build/sort.o ../build-x86_64-linux/libiberty/libiberty.a
build/gencfn-macros -c \
  > tmp-case-cfn-macros.h
build/gencfn-macros -o \
  > tmp-cfn-operators.pd
/bin/sh ../../../gcc/gcc/../move-if-change tmp-case-cfn-macros.h \
  case-cfn-macros.h
/bin/sh ../../../gcc/gcc/../move-if-change tmp-cfn-operators.pd \
  cfn-operators.pd
echo timestamp > s-cfn-operators
echo timestamp > s-case-cfn-macros
g++ -std=c++11 -c   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 

[PATCH] docs: Remove empty table column.

[Martin Liška]

A column with empty values seems suspicious.

Ready to be installed?
Thanks,
Martin

gcc/fortran/ChangeLog:

* intrinsic.texi: The table has first column empty and it makes
trouble when processing makeinfo --xml output.
---
 gcc/fortran/intrinsic.texi | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 73baa34104e..c74a7f56c60 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -4764,15 +4764,15 @@ Unavailable time and date parameters return blanks.
 
 @var{VALUES} is @code{INTENT(OUT)} and provides the following:
 
-@multitable @columnfractions .15 .30 .40
-@item @tab @code{VALUE(1)}: @tab The year
-@item @tab @code{VALUE(2)}: @tab The month
-@item @tab @code{VALUE(3)}: @tab The day of the month
-@item @tab @code{VALUE(4)}: @tab Time difference with UTC in minutes
-@item @tab @code{VALUE(5)}: @tab The hour of the day
-@item @tab @code{VALUE(6)}: @tab The minutes of the hour
-@item @tab @code{VALUE(7)}: @tab The seconds of the minute
-@item @tab @code{VALUE(8)}: @tab The milliseconds of the second
+@multitable @columnfractions .15 .70
+@item @code{VALUE(1)}: @tab The year
+@item @code{VALUE(2)}: @tab The month
+@item @code{VALUE(3)}: @tab The day of the month
+@item @code{VALUE(4)}: @tab Time difference with UTC in minutes
+@item @code{VALUE(5)}: @tab The hour of the day
+@item @code{VALUE(6)}: @tab The minutes of the hour
+@item @code{VALUE(7)}: @tab The seconds of the minute
+@item @code{VALUE(8)}: @tab The milliseconds of the second
 @end multitable
 
 @item @emph{Standard}:
-- 
2.31.1

Re: [PATCH] docs: update symver attribute description

[Martin Liška]

On 4/12/21 3:50 PM, H.J. Lu wrote:
> GCC failed to bootstrap:
> 
> /export/gnu/import/git/sources/gcc/gcc/doc/extend.texi:3870: misplaced {
> /export/gnu/import/git/sources/gcc/gcc/doc/extend.texi:3872: misplaced }
> /export/gnu/import/git/sources/gcc/gcc/doc/extend.texi:3874: unknown
> command `VERS'
> make[2]: *** [Makefile:3396: doc/gcc.info] Error 1

Whoops. Sorry for that, should be fixed now.

Martin

Re: [PATCH] IBM Z: Add alternative to *movdi_{31, 64} in order to load a DFP zero

[Andreas Krebbel via Gcc-patches]

On 4/12/21 3:40 PM, Stefan Schulze Frielinghaus wrote:
> Bootstraped and regtested on IBM Z.  Ok for mainline?
> 
> gcc/ChangeLog:
> 
>   * config/s390/s390.md ("*movdi_31", "*movdi_64"): Add
> alternative in order to load a DFP zero.

Ok. Thanks!

Andreas

> ---
>  gcc/config/s390/s390.md | 25 ++---
>  1 file changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
> index c10f25b2472..7faf775fbf2 100644
> --- a/gcc/config/s390/s390.md
> +++ b/gcc/config/s390/s390.md
> @@ -1868,9 +1868,9 @@
>  
>  (define_insn "*movdi_64"
>[(set (match_operand:DI 0 "nonimmediate_operand"
> - "=d,d,d,d,d, d,d,
> d,f,d,d,d,d,d,T,!*f,!*f,!*f,!R,!T,b,Q,d,t,Q,t,v,v,v,d,v,R,d")
> + "=d,d,d,d,d, d,d,
> d,f,d,!*f,d,d,d,d,T,!*f,!*f,!*f,!R,!T,b,Q,d,t,Q,t,v,v,v,d,v,R,d")
>  (match_operand:DI 1 "general_operand"
> - " K,N0HD0,N1HD0,N2HD0,N3HD0,Os,N0SD0,N1SD0,d,f,L,b,d,T,d, *f,  R,  
> T,*f,*f,d,K,t,d,t,Q,K,v,d,v,R,v,ZL"))]
> + " K,N0HD0,N1HD0,N2HD0,N3HD0,Os,N0SD0,N1SD0,d,f,j00,L,b,d,T,d, *f,  
> R,  T,*f,*f,d,K,t,d,t,Q,K,v,d,v,R,v,ZL"))]
>"TARGET_ZARCH"
>"@
> lghi\t%0,%h1
> @@ -1883,6 +1883,7 @@
> llilf\t%0,%k1
> ldgr\t%0,%1
> lgdr\t%0,%1
> +   lzdr\t%0
> lay\t%0,%a1
> lgrl\t%0,%1
> lgr\t%0,%1
> @@ -1906,13 +1907,13 @@
> vleg\t%v0,%1,0
> vsteg\t%v1,%0,0
> larl\t%0,%1"
> -  [(set_attr "op_type" "RI,RI,RI,RI,RI,RIL,RIL,RIL,RRE,RRE,RXY,RIL,RRE,RXY,
> +  [(set_attr "op_type" 
> "RI,RI,RI,RI,RI,RIL,RIL,RIL,RRE,RRE,RRE,RXY,RIL,RRE,RXY,
>  
> RXY,RR,RX,RXY,RX,RXY,RIL,SIL,*,*,RS,RS,VRI,VRR,VRS,VRS,
>  VRX,VRX,RIL")
> -   (set_attr "type" "*,*,*,*,*,*,*,*,floaddf,floaddf,la,larl,lr,load,store,
> +   (set_attr "type" 
> "*,*,*,*,*,*,*,*,floaddf,floaddf,fsimpdf,la,larl,lr,load,store,
>   floaddf,floaddf,floaddf,fstoredf,fstoredf,larl,*,*,*,*,
>   *,*,*,*,*,*,*,larl")
> -   (set_attr "cpu_facility" "*,*,*,*,*,extimm,extimm,extimm,dfp,dfp,longdisp,
> +   (set_attr "cpu_facility" 
> "*,*,*,*,*,extimm,extimm,extimm,dfp,dfp,*,longdisp,
>   z10,*,*,*,*,*,longdisp,*,longdisp,
>   z10,z10,*,*,*,*,vx,vx,vx,vx,vx,vx,*")
> (set_attr "z10prop" "z10_fwd_A1,
> @@ -1925,6 +1926,7 @@
>  z10_fwd_E1,
>  *,
>  *,
> + *,
>  z10_fwd_A1,
>  z10_fwd_A3,
>  z10_fr_E1,
> @@ -1942,7 +1944,7 @@
>  *,
>  *,*,*,*,*,*,*,
>  z10_super_A1")
> -   (set_attr "relative_long" "*,*,*,*,*,*,*,*,*,*,
> +   (set_attr "relative_long" "*,*,*,*,*,*,*,*,*,*,*,
>*,yes,*,*,*,*,*,*,*,*,
>yes,*,*,*,*,*,*,*,*,*,
>*,*,yes")
> @@ -2002,9 +2004,9 @@
>  
>  (define_insn "*movdi_31"
>[(set (match_operand:DI 0 "nonimmediate_operand"
> -"=d,d,Q,S,d  ,o,!*f,!*f,!*f,!R,!T,d")
> +"=d,d,Q,S,d  ,o,!*f,!*f,!*f,!*f,!R,!T,d")
>  (match_operand:DI 1 "general_operand"
> -" Q,S,d,d,dPT,d, *f,  R,  T,*f,*f,b"))]
> +" Q,S,d,d,dPT,d, *f,  R,  T,j00,*f,*f,b"))]
>"!TARGET_ZARCH"
>"@
> lm\t%0,%N0,%S1
> @@ -2016,12 +2018,13 @@
> ldr\t%0,%1
> ld\t%0,%1
> ldy\t%0,%1
> +   lzdr\t%0
> std\t%1,%0
> stdy\t%1,%0
> #"
> -  [(set_attr "op_type" "RS,RSY,RS,RSY,*,*,RR,RX,RXY,RX,RXY,*")
> -   (set_attr "type" 
> "lm,lm,stm,stm,*,*,floaddf,floaddf,floaddf,fstoredf,fstoredf,*")
> -   (set_attr "cpu_facility" 
> "*,longdisp,*,longdisp,*,*,*,*,longdisp,*,longdisp,z10")])
> +  [(set_attr "op_type" "RS,RSY,RS,RSY,*,*,RR,RX,RXY,RRE,RX,RXY,*")
> +   (set_attr "type" 
> "lm,lm,stm,stm,*,*,floaddf,floaddf,floaddf,fsimpdf,fstoredf,fstoredf,*")
> +   (set_attr "cpu_facility" 
> "*,longdisp,*,longdisp,*,*,*,*,longdisp,*,*,longdisp,z10")])
>  
>  ; For a load from a symbol ref we can use one of the target registers
>  ; together with larl to load the address.
> 

Re: [PATCH] docs: update symver attribute description

[H.J. Lu via Gcc-patches]

On Mon, Apr 12, 2021 at 5:54 AM Martin Liška  wrote:
>
> On 4/12/21 2:18 PM, Jakub Jelinek wrote:
> > On Mon, Apr 12, 2021 at 02:15:16PM +0200, Martin Liška wrote:
> >> The old syntax with the alias is quite ugly..
> >
> > Not that much.  And users have no other option (besides inline asm
> > but that doesn't work with LTO well).
> >
> >>> so that people who don't have gcc configured against
> >>> binutils 2.35 or newer know what to do instead.
> >>
> >> ... and symver support for older binutils releases is fragile due to:
> >>
> >> Changes in 2.35:
> >>
> >> * Extend .symver directive to update visibility of the original symbol
> >>   and assign one original symbol to different versioned symbols.
> >
> > That is a change that allows the new syntax.
> > The old syntax (on the as/ld side) have worked for the last 20+ years
> > just fine.
> >
> >   Jakub
> >
>
> All right, so something like this?
>
> Thanks,
> Martin

GCC failed to bootstrap:

/export/gnu/import/git/sources/gcc/gcc/doc/extend.texi:3870: misplaced {
/export/gnu/import/git/sources/gcc/gcc/doc/extend.texi:3872: misplaced }
/export/gnu/import/git/sources/gcc/gcc/doc/extend.texi:3874: unknown
command `VERS'
make[2]: *** [Makefile:3396: doc/gcc.info] Error 1


-- 
H.J.

[PATCH] IBM Z: Add alternative to *movdi_{31, 64} in order to load a DFP zero

[Stefan Schulze Frielinghaus via Gcc-patches]

Bootstraped and regtested on IBM Z.  Ok for mainline?

gcc/ChangeLog:

* config/s390/s390.md ("*movdi_31", "*movdi_64"): Add
  alternative in order to load a DFP zero.
---
 gcc/config/s390/s390.md | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index c10f25b2472..7faf775fbf2 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -1868,9 +1868,9 @@
 
 (define_insn "*movdi_64"
   [(set (match_operand:DI 0 "nonimmediate_operand"
- "=d,d,d,d,d, d,d,
d,f,d,d,d,d,d,T,!*f,!*f,!*f,!R,!T,b,Q,d,t,Q,t,v,v,v,d,v,R,d")
+ "=d,d,d,d,d, d,d,
d,f,d,!*f,d,d,d,d,T,!*f,!*f,!*f,!R,!T,b,Q,d,t,Q,t,v,v,v,d,v,R,d")
 (match_operand:DI 1 "general_operand"
- " K,N0HD0,N1HD0,N2HD0,N3HD0,Os,N0SD0,N1SD0,d,f,L,b,d,T,d, *f,  R,  
T,*f,*f,d,K,t,d,t,Q,K,v,d,v,R,v,ZL"))]
+ " K,N0HD0,N1HD0,N2HD0,N3HD0,Os,N0SD0,N1SD0,d,f,j00,L,b,d,T,d, *f,  R, 
 T,*f,*f,d,K,t,d,t,Q,K,v,d,v,R,v,ZL"))]
   "TARGET_ZARCH"
   "@
lghi\t%0,%h1
@@ -1883,6 +1883,7 @@
llilf\t%0,%k1
ldgr\t%0,%1
lgdr\t%0,%1
+   lzdr\t%0
lay\t%0,%a1
lgrl\t%0,%1
lgr\t%0,%1
@@ -1906,13 +1907,13 @@
vleg\t%v0,%1,0
vsteg\t%v1,%0,0
larl\t%0,%1"
-  [(set_attr "op_type" "RI,RI,RI,RI,RI,RIL,RIL,RIL,RRE,RRE,RXY,RIL,RRE,RXY,
+  [(set_attr "op_type" "RI,RI,RI,RI,RI,RIL,RIL,RIL,RRE,RRE,RRE,RXY,RIL,RRE,RXY,
 RXY,RR,RX,RXY,RX,RXY,RIL,SIL,*,*,RS,RS,VRI,VRR,VRS,VRS,
 VRX,VRX,RIL")
-   (set_attr "type" "*,*,*,*,*,*,*,*,floaddf,floaddf,la,larl,lr,load,store,
+   (set_attr "type" 
"*,*,*,*,*,*,*,*,floaddf,floaddf,fsimpdf,la,larl,lr,load,store,
  floaddf,floaddf,floaddf,fstoredf,fstoredf,larl,*,*,*,*,
  *,*,*,*,*,*,*,larl")
-   (set_attr "cpu_facility" "*,*,*,*,*,extimm,extimm,extimm,dfp,dfp,longdisp,
+   (set_attr "cpu_facility" "*,*,*,*,*,extimm,extimm,extimm,dfp,dfp,*,longdisp,
  z10,*,*,*,*,*,longdisp,*,longdisp,
  z10,z10,*,*,*,*,vx,vx,vx,vx,vx,vx,*")
(set_attr "z10prop" "z10_fwd_A1,
@@ -1925,6 +1926,7 @@
 z10_fwd_E1,
 *,
 *,
+   *,
 z10_fwd_A1,
 z10_fwd_A3,
 z10_fr_E1,
@@ -1942,7 +1944,7 @@
 *,
 *,*,*,*,*,*,*,
 z10_super_A1")
-   (set_attr "relative_long" "*,*,*,*,*,*,*,*,*,*,
+   (set_attr "relative_long" "*,*,*,*,*,*,*,*,*,*,*,
   *,yes,*,*,*,*,*,*,*,*,
   yes,*,*,*,*,*,*,*,*,*,
   *,*,yes")
@@ -2002,9 +2004,9 @@
 
 (define_insn "*movdi_31"
   [(set (match_operand:DI 0 "nonimmediate_operand"
-"=d,d,Q,S,d  ,o,!*f,!*f,!*f,!R,!T,d")
+"=d,d,Q,S,d  ,o,!*f,!*f,!*f,!*f,!R,!T,d")
 (match_operand:DI 1 "general_operand"
-" Q,S,d,d,dPT,d, *f,  R,  T,*f,*f,b"))]
+" Q,S,d,d,dPT,d, *f,  R,  T,j00,*f,*f,b"))]
   "!TARGET_ZARCH"
   "@
lm\t%0,%N0,%S1
@@ -2016,12 +2018,13 @@
ldr\t%0,%1
ld\t%0,%1
ldy\t%0,%1
+   lzdr\t%0
std\t%1,%0
stdy\t%1,%0
#"
-  [(set_attr "op_type" "RS,RSY,RS,RSY,*,*,RR,RX,RXY,RX,RXY,*")
-   (set_attr "type" 
"lm,lm,stm,stm,*,*,floaddf,floaddf,floaddf,fstoredf,fstoredf,*")
-   (set_attr "cpu_facility" 
"*,longdisp,*,longdisp,*,*,*,*,longdisp,*,longdisp,z10")])
+  [(set_attr "op_type" "RS,RSY,RS,RSY,*,*,RR,RX,RXY,RRE,RX,RXY,*")
+   (set_attr "type" 
"lm,lm,stm,stm,*,*,floaddf,floaddf,floaddf,fsimpdf,fstoredf,fstoredf,*")
+   (set_attr "cpu_facility" 
"*,longdisp,*,longdisp,*,*,*,*,longdisp,*,*,longdisp,z10")])
 
 ; For a load from a symbol ref we can use one of the target registers
 ; together with larl to load the address.
-- 
2.23.0

Re: [PATCH] docs: update symver attribute description

[Jakub Jelinek via Gcc-patches]

On Mon, Apr 12, 2021 at 03:24:00PM +0200, Martin Liška wrote:
> On 4/12/21 2:45 PM, Jakub Jelinek wrote:
> > On Mon, Apr 12, 2021 at 02:32:35PM +0200, Martin Liška wrote:
> >> +If you have an older release of binutils release, then symbol alias needs 
> >> to
> > 
> > s/binutils release/binutils/
> 
> Fixed.
> 
> > 
> >> +be used:
> >> +
> >> +@smallexample
> >> +__attribute__ ((__symver__ ("foo@@VERS_2")))
> >> +__attribute__ ((alias ("foo_v1")))
> >> +int symver_foo_v1 (void);
> >> +@end smallexample
> > 
> > The example should show two versions of foo rather than just one, otherwise
> > it will confuse users.  For symbol versions which just a single symbol they
> > don't need any aliases...
> 
> Very good point! Is it fine now?

Ok, thanks.

> >From 6dda0ec10a1b0c60e6e9afe7fc45370d0132b5e3 Mon Sep 17 00:00:00 2001
> From: Martin Liska 
> Date: Mon, 12 Apr 2021 13:42:33 +0200
> Subject: [PATCH] docs: update symver attribute description
> 
> gcc/ChangeLog:
> 
>   * doc/extend.texi: Be more precise in documentation
>   of symver attribute.
> ---
>  gcc/doc/extend.texi | 28 +++-
>  1 file changed, 19 insertions(+), 9 deletions(-)
> 
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index e28e1860990..6542ada6583 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -3848,23 +3848,33 @@ foo_v1 (void)
>  Will produce a @code{.symver foo_v1, foo@@VERS_1} directive in the assembler
>  output. 
>  
> -One can also define multiple version for a given symbol.
> +One can also define multiple version for a given symbol
> +(starting from binutils 2.35).
>  
>  @smallexample
>  __attribute__ ((__symver__ ("foo@@VERS_2"), __symver__ ("foo@@VERS_3")))
>  int symver_foo_v1 (void)
>  @{
>  @}
> -
> -__attribute__ ((__symver__ ("bar@@VERS_2")))
> -__attribute__ ((__symver__ ("bar@@VERS_3")))
> -int symver_bar_v1 (void)
> -@{
> -@}
>  @end smallexample
>  
> -This example creates an alias of @code{foo_v1} with symbol name
> -@code{symver_foo_v1} which will be version @code{VERS_2} of @code{foo}.
> +This example creates a symbol name @code{symver_foo_v1}
> +which will be version @code{VERS_2} and @code{VERS_3} of @code{foo}.
> +
> +If you have an older release of binutils, then symbol alias needs to
> +be used:
> +
> +@smallexample
> +__attribute__ ((__symver__ ("foo@@VERS_2")))
> +int foo_v1 (void)
> +{
> +  return 0;
> +}
> +
> +__attribute__ ((__symver__ ("foo@VERS_3")))
> +__attribute__ ((alias ("foo_v1")))
> +int symver_foo_v1 (void);
> +@end smallexample
>  
>  Finally if the parameter is @code{"@var{name2}@var{nodename}"} then in
>  addition to creating a symbol version (as if
> -- 
> 2.31.1
> 


Jakub

Re: [PATCH] docs: update symver attribute description

[Martin Liška]

On 4/12/21 2:45 PM, Jakub Jelinek wrote:
> On Mon, Apr 12, 2021 at 02:32:35PM +0200, Martin Liška wrote:
>> +If you have an older release of binutils release, then symbol alias needs to
> 
> s/binutils release/binutils/

Fixed.

> 
>> +be used:
>> +
>> +@smallexample
>> +__attribute__ ((__symver__ ("foo@@VERS_2")))
>> +__attribute__ ((alias ("foo_v1")))
>> +int symver_foo_v1 (void);
>> +@end smallexample
> 
> The example should show two versions of foo rather than just one, otherwise
> it will confuse users.  For symbol versions which just a single symbol they
> don't need any aliases...

Very good point! Is it fine now?

Thanks,
Martin

> 
>   Jakub
> 

>From 6dda0ec10a1b0c60e6e9afe7fc45370d0132b5e3 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 12 Apr 2021 13:42:33 +0200
Subject: [PATCH] docs: update symver attribute description

gcc/ChangeLog:

	* doc/extend.texi: Be more precise in documentation
	of symver attribute.
---
 gcc/doc/extend.texi | 28 +++-
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index e28e1860990..6542ada6583 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3848,23 +3848,33 @@ foo_v1 (void)
 Will produce a @code{.symver foo_v1, foo@@VERS_1} directive in the assembler
 output. 
 
-One can also define multiple version for a given symbol.
+One can also define multiple version for a given symbol
+(starting from binutils 2.35).
 
 @smallexample
 __attribute__ ((__symver__ ("foo@@VERS_2"), __symver__ ("foo@@VERS_3")))
 int symver_foo_v1 (void)
 @{
 @}
-
-__attribute__ ((__symver__ ("bar@@VERS_2")))
-__attribute__ ((__symver__ ("bar@@VERS_3")))
-int symver_bar_v1 (void)
-@{
-@}
 @end smallexample
 
-This example creates an alias of @code{foo_v1} with symbol name
-@code{symver_foo_v1} which will be version @code{VERS_2} of @code{foo}.
+This example creates a symbol name @code{symver_foo_v1}
+which will be version @code{VERS_2} and @code{VERS_3} of @code{foo}.
+
+If you have an older release of binutils, then symbol alias needs to
+be used:
+
+@smallexample
+__attribute__ ((__symver__ ("foo@@VERS_2")))
+int foo_v1 (void)
+{
+  return 0;
+}
+
+__attribute__ ((__symver__ ("foo@VERS_3")))
+__attribute__ ((alias ("foo_v1")))
+int symver_foo_v1 (void);
+@end smallexample
 
 Finally if the parameter is @code{"@var{name2}@var{nodename}"} then in
 addition to creating a symbol version (as if
-- 
2.31.1

Re: [Patch, fortran] PR fortran/100018 - ICE on missing polymorphic argument

[Tobias Burnus]

On 10.04.21 22:45, José Rui Faustino de Sousa via Fortran wrote:

On 10/04/21 17:37, Tobias Burnus wrote:

And you need an additional single-line summary for git – which should
be part of the patch submission.


In case you are waiting for me, I did write:

'LGTM – Thanks for the patch. Two nits:'

and expected that you just fixed them when committing the patch.
(Actually, as they were tiny comments and to the commit log only,
I did not even expect a posting of the committed patch or its commit log.)

But as you didn't commit it it yet, I gathered you are waiting for me.
Hence, you get another LGTM from me :-)

Thanks again for the patch – and the other patches (which still need to
be reviewed).

Tobias


Fortran: Fix ICE due to referencing a NULL pointer [PR100018]

gcc/fortran/ChangeLog:

   PR fortran/100018
   * resolve.c: Add association check before de-referencing
   pointer.


gcc/testsuite/ChangeLog:

   PR fortran/100018
   * gfortran.dg/PR10018.f90: New test.


Thank you very much.

Best regards,
José Rui

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf

[GCC][Patch] arm: Fix the mve multilib for the broken cmse support (pr99939).

[Srinath Parvathaneni via Gcc-patches]

Hi,

The current CMSE support in the multilib build for "-march=armv8.1-m.main+mve 
-mfloat-abi=hard -mfpu=auto"
is broken as specified in PR99939 and this patch fixes the issue.

Regression tested on arm-none-eabi and found no regressions.

Ok for master? and Ok for GCC-10 branch?

Regards,
Srinath.

gcc/testsuite/ChangeLog:

2021-04-12  Srinath Parvathaneni  

PR target/99939
* gcc.target/arm/cmse/cmse-20.c: New test.

libgcc/ChangeLog:

2021-04-12  Srinath Parvathaneni  

PR target/99939
* config/arm/t-arm: Make changes to use cmse.c for all the
armv8.1-m.main mulitlibs.



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


diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c 
b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
new file mode 100644
index 
..7e2739e14792624adf5b4280ca58a5d8320acbf0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
@@ -0,0 +1,28 @@
+/* { dg-do run } */
+/* { dg-additional-options "-mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0019" } */
+
+#include 
+#include 
+#include 
+
+void __attribute__((cmse_nonsecure_entry))
+secure_fun (int a, int *p)
+{
+  void *b = cmse_check_address_range ((void *)p, a, 1);
+
+  if (b == NULL)
+   __builtin_abort ();
+  printf("%d", *((int *)b));
+}
+
+int
+main (void)
+{
+  int *ptr;
+  int size = 1;
+  ptr = (int *) calloc (1, sizeof(int *));
+  *ptr = 1315852292;
+  secure_fun (size, ptr);
+  free (ptr);
+  return 0;
+}
diff --git a/libgcc/config/arm/t-arm b/libgcc/config/arm/t-arm
index 
3625a2590beec4e4e0e0881be9ad284c595c7190..949e2ee06653680211ff2dcf0b55a41a6aedc31c
 100644
--- a/libgcc/config/arm/t-arm
+++ b/libgcc/config/arm/t-arm
@@ -9,11 +9,12 @@ CMSE_OPTS:=-mcmse
 endif
 
 ifdef HAVE_CMSE
-ifndef HAVE_V81M
-libgcc-objects += cmse.o cmse_nonsecure_call.o
+libgcc-objects += cmse.o
 
 cmse.o: $(srcdir)/config/arm/cmse.c
$(gcc_compile) -c $(CMSE_OPTS) $<
+ifndef HAVE_V81M
+libgcc-objects += cmse_nonsecure_call.o
 cmse_nonsecure_call.o: $(srcdir)/config/arm/cmse_nonsecure_call.S
   $(gcc_compile) -c $<
 endif

diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c 
b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
new file mode 100644
index 
..7e2739e14792624adf5b4280ca58a5d8320acbf0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
@@ -0,0 +1,28 @@
+/* { dg-do run } */
+/* { dg-additional-options "-mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0019" } */
+
+#include 
+#include 
+#include 
+
+void __attribute__((cmse_nonsecure_entry))
+secure_fun (int a, int *p)
+{
+  void *b = cmse_check_address_range ((void *)p, a, 1);
+
+  if (b == NULL)
+   __builtin_abort ();
+  printf("%d", *((int *)b));
+}
+
+int
+main (void)
+{
+  int *ptr;
+  int size = 1;
+  ptr = (int *) calloc (1, sizeof(int *));
+  *ptr = 1315852292;
+  secure_fun (size, ptr);
+  free (ptr);
+  return 0;
+}
diff --git a/libgcc/config/arm/t-arm b/libgcc/config/arm/t-arm
index 
3625a2590beec4e4e0e0881be9ad284c595c7190..949e2ee06653680211ff2dcf0b55a41a6aedc31c
 100644
--- a/libgcc/config/arm/t-arm
+++ b/libgcc/config/arm/t-arm
@@ -9,11 +9,12 @@ CMSE_OPTS:=-mcmse
 endif
 
 ifdef HAVE_CMSE
-ifndef HAVE_V81M
-libgcc-objects += cmse.o cmse_nonsecure_call.o
+libgcc-objects += cmse.o
 
 cmse.o: $(srcdir)/config/arm/cmse.c
$(gcc_compile) -c $(CMSE_OPTS) $<
+ifndef HAVE_V81M
+libgcc-objects += cmse_nonsecure_call.o
 cmse_nonsecure_call.o: $(srcdir)/config/arm/cmse_nonsecure_call.S
   $(gcc_compile) -c $<
 endif

Re: [PATCH] docs: update symver attribute description

[Jakub Jelinek via Gcc-patches]

On Mon, Apr 12, 2021 at 02:32:35PM +0200, Martin Liška wrote:
> +If you have an older release of binutils release, then symbol alias needs to

s/binutils release/binutils/

> +be used:
> +
> +@smallexample
> +__attribute__ ((__symver__ ("foo@@VERS_2")))
> +__attribute__ ((alias ("foo_v1")))
> +int symver_foo_v1 (void);
> +@end smallexample

The example should show two versions of foo rather than just one, otherwise
it will confuse users.  For symbol versions which just a single symbol they
don't need any aliases...

Jakub

Re: [PATCH] docs: update symver attribute description

[Martin Liška]

On 4/12/21 2:18 PM, Jakub Jelinek wrote:
> On Mon, Apr 12, 2021 at 02:15:16PM +0200, Martin Liška wrote:
>> The old syntax with the alias is quite ugly..
> 
> Not that much.  And users have no other option (besides inline asm
> but that doesn't work with LTO well).
> 
>>> so that people who don't have gcc configured against
>>> binutils 2.35 or newer know what to do instead.
>>
>> ... and symver support for older binutils releases is fragile due to:
>>
>> Changes in 2.35:
>>
>> * Extend .symver directive to update visibility of the original symbol
>>   and assign one original symbol to different versioned symbols.
> 
> That is a change that allows the new syntax.
> The old syntax (on the as/ld side) have worked for the last 20+ years
> just fine.
> 
>   Jakub
> 

All right, so something like this?

Thanks,
Martin
>From 750b715225d480fcb74e765623d54acc42ac25e3 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 12 Apr 2021 13:42:33 +0200
Subject: [PATCH] docs: update symver attribute description

gcc/ChangeLog:

	* doc/extend.texi: Be more precise in documentation
	of symver attribute.
---
 gcc/doc/extend.texi | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index e28e1860990..75e4a43a8c5 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3848,23 +3848,27 @@ foo_v1 (void)
 Will produce a @code{.symver foo_v1, foo@@VERS_1} directive in the assembler
 output. 
 
-One can also define multiple version for a given symbol.
+One can also define multiple version for a given symbol
+(starting from binutils 2.35).
 
 @smallexample
 __attribute__ ((__symver__ ("foo@@VERS_2"), __symver__ ("foo@@VERS_3")))
 int symver_foo_v1 (void)
 @{
 @}
-
-__attribute__ ((__symver__ ("bar@@VERS_2")))
-__attribute__ ((__symver__ ("bar@@VERS_3")))
-int symver_bar_v1 (void)
-@{
-@}
 @end smallexample
 
-This example creates an alias of @code{foo_v1} with symbol name
-@code{symver_foo_v1} which will be version @code{VERS_2} of @code{foo}.
+This example creates a symbol name @code{symver_foo_v1}
+which will be version @code{VERS_2} and @code{VERS_3} of @code{foo}.
+
+If you have an older release of binutils release, then symbol alias needs to
+be used:
+
+@smallexample
+__attribute__ ((__symver__ ("foo@@VERS_2")))
+__attribute__ ((alias ("foo_v1")))
+int symver_foo_v1 (void);
+@end smallexample
 
 Finally if the parameter is @code{"@var{name2}@var{nodename}"} then in
 addition to creating a symbol version (as if
-- 
2.31.1

[committed] libstdc++: Implement LWG 3404 for C++20 subrange [PR 100044]

[Jonathan Wakely via Gcc-patches]

These deduction guides became useless with LWG 3282 (implemented in
commit r10-6741) and so were removed by LWG 3404.

libstdc++-v3/ChangeLog:

PR libstdc++/100044
* include/bits/ranges_util.h (__detail::__iterator_sentinel_pair):
Remove helper concept.
(subrange(_Pr), subrange(Pr, __make_unsigned_like<...>)): Remove
deduction guides, as per LWG 3404.
* testsuite/std/ranges/subrange/lwg3282_neg.cc: Check that class
template argument deduction fails.

Tested powerpc64le-linux. Committed to trunk.

I'll backport this to gcc-10 too.

commit 7569ce583f540ae22c585cc5159e3b23deedd987
Author: Jonathan Wakely 
Date:   Mon Apr 12 12:49:17 2021

libstdc++: Implement LWG 3404 for C++20 subrange [PR 100044]

These deduction guides became useless with LWG 3282 (implemented in
commit r10-6741) and so were removed by LWG 3404.

libstdc++-v3/ChangeLog:

PR libstdc++/100044
* include/bits/ranges_util.h (__detail::__iterator_sentinel_pair):
Remove helper concept.
(subrange(_Pr), subrange(Pr, __make_unsigned_like<...>)): Remove
deduction guides, as per LWG 3404.
* testsuite/std/ranges/subrange/lwg3282_neg.cc: Check that class
template argument deduction fails.

diff --git a/libstdc++-v3/include/bits/ranges_util.h 
b/libstdc++-v3/include/bits/ranges_util.h
index ae53afd97bd..9d51e1b874e 100644
--- a/libstdc++-v3/include/bits/ranges_util.h
+++ b/libstdc++-v3/include/bits/ranges_util.h
@@ -186,11 +186,6 @@ namespace ranges
&& __convertible_to_non_slicing<_Up, tuple_element_t<0, _Tp>>
&& convertible_to<_Vp, tuple_element_t<1, _Tp>>;
 
-template
-  concept __iterator_sentinel_pair
-   = !range<_Tp> && __pair_like<_Tp>
-   && sentinel_for, tuple_element_t<0, _Tp>>;
-
   } // namespace __detail
 
   enum class subrange_kind : bool { unsized, sized };
@@ -352,16 +347,6 @@ namespace ranges
 __detail::__make_unsigned_like_t>)
   -> subrange<_It, _Sent, subrange_kind::sized>;
 
-  template<__detail::__iterator_sentinel_pair _Pr>
-subrange(_Pr)
-  -> subrange, tuple_element_t<1, _Pr>>;
-
-  template<__detail::__iterator_sentinel_pair _Pr>
-subrange(_Pr, __detail::__make_unsigned_like_t>>)
-  -> subrange, tuple_element_t<1, _Pr>,
- subrange_kind::sized>;
-
   template
 subrange(_Rng&&)
   -> subrange, sentinel_t<_Rng>,
diff --git a/libstdc++-v3/testsuite/std/ranges/subrange/lwg3282_neg.cc 
b/libstdc++-v3/testsuite/std/ranges/subrange/lwg3282_neg.cc
index d9894e4f137..170f4d2962b 100644
--- a/libstdc++-v3/testsuite/std/ranges/subrange/lwg3282_neg.cc
+++ b/libstdc++-v3/testsuite/std/ranges/subrange/lwg3282_neg.cc
@@ -29,3 +29,16 @@ struct Base {};
 struct Derived : Base {};
 subrange sd;
 subrange sb = sd; // { dg-error "conversion" }
+
+void
+test_lwg3404()
+{
+  // LWG 3404. Finish removing subrange's conversions from pair-like
+  std::pair p;
+  subrange sb1(p); // { dg-error "no matching function" }
+  // { dg-error "class template argument deduction" "" { target *-*-* } 38 }
+  subrange sb2(p, p.second - p.first); // { dg-error "no matching function" }
+  // { dg-error "class template argument deduction" "" { target *-*-* } 40 }
+
+  // { dg-prune-output "in requirements with" }
+}

Re: [PATCH] docs: update symver attribute description

[Jakub Jelinek via Gcc-patches]

On Mon, Apr 12, 2021 at 02:15:16PM +0200, Martin Liška wrote:
> The old syntax with the alias is quite ugly..

Not that much.  And users have no other option (besides inline asm
but that doesn't work with LTO well).

> > so that people who don't have gcc configured against
> > binutils 2.35 or newer know what to do instead.
> 
> ... and symver support for older binutils releases is fragile due to:
> 
> Changes in 2.35:
> 
> * Extend .symver directive to update visibility of the original symbol
>   and assign one original symbol to different versioned symbols.

That is a change that allows the new syntax.
The old syntax (on the as/ld side) have worked for the last 20+ years
just fine.

Jakub

Re: [PATCH] docs: update symver attribute description

[Martin Liška]

On 4/12/21 1:50 PM, Jakub Jelinek wrote:
> On Mon, Apr 12, 2021 at 01:44:54PM +0200, Martin Liška wrote:
>> This improves documentation as noticed by Jakub.
>>
>> Ready for master?
>> Thanks,
>> Martin
>>
>> gcc/ChangeLog:
>>
>>  * doc/extend.texi: Be more precise in documentation
>>  of symver attribute.
> 
> Ok, but I'd prefer to see the old example with the old description in the
> documentation too

The old syntax with the alias is quite ugly..

> so that people who don't have gcc configured against
> binutils 2.35 or newer know what to do instead.

... and symver support for older binutils releases is fragile due to:

Changes in 2.35:

* Extend .symver directive to update visibility of the original symbol
  and assign one original symbol to different versioned symbols.

Martin

> 
>> --- a/gcc/doc/extend.texi
>> +++ b/gcc/doc/extend.texi
>> @@ -3848,7 +3848,8 @@ foo_v1 (void)
>>  Will produce a @code{.symver foo_v1, foo@@VERS_1} directive in the assembler
>>  output. 
>>  
>> -One can also define multiple version for a given symbol.
>> +One can also define multiple version for a given symbol
>> +(starting from binutils 2.35).
>>  
>>  @smallexample
>>  __attribute__ ((__symver__ ("foo@@VERS_2"), __symver__ ("foo@@VERS_3")))
>> @@ -3863,8 +3864,8 @@ int symver_bar_v1 (void)
>>  @}
>>  @end smallexample
>>  
>> -This example creates an alias of @code{foo_v1} with symbol name
>> -@code{symver_foo_v1} which will be version @code{VERS_2} of @code{foo}.
>> +This example creates a symbol name @code{symver_foo_v1}
>> +which will be version @code{VERS_2} and @code{VERS_3} of @code{foo}.
>>  
>>  Finally if the parameter is @code{"@var{name2}@var{nodename}"} then in
>>  addition to creating a symbol version (as if
>> -- 
>> 2.31.1
> 
>   Jakub
> 

Re: [ping] Fix thinko in libcpp preparation patch for modules

[Jeff Law via Gcc-patches]

On 4/12/2021 2:45 AM, Eric Botcazou wrote:

This is a regression in Ada on the mainline, 10 and 9 branches:
   https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567143.html

Thanks in advance.


OK

jeff

Re: [PATCH] docs: update symver attribute description

[Jakub Jelinek via Gcc-patches]

On Mon, Apr 12, 2021 at 01:44:54PM +0200, Martin Liška wrote:
> This improves documentation as noticed by Jakub.
> 
> Ready for master?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
>   * doc/extend.texi: Be more precise in documentation
>   of symver attribute.

Ok, but I'd prefer to see the old example with the old description in the
documentation too, so that people who don't have gcc configured against
binutils 2.35 or newer know what to do instead.

> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -3848,7 +3848,8 @@ foo_v1 (void)
>  Will produce a @code{.symver foo_v1, foo@@VERS_1} directive in the assembler
>  output. 
>  
> -One can also define multiple version for a given symbol.
> +One can also define multiple version for a given symbol
> +(starting from binutils 2.35).
>  
>  @smallexample
>  __attribute__ ((__symver__ ("foo@@VERS_2"), __symver__ ("foo@@VERS_3")))
> @@ -3863,8 +3864,8 @@ int symver_bar_v1 (void)
>  @}
>  @end smallexample
>  
> -This example creates an alias of @code{foo_v1} with symbol name
> -@code{symver_foo_v1} which will be version @code{VERS_2} of @code{foo}.
> +This example creates a symbol name @code{symver_foo_v1}
> +which will be version @code{VERS_2} and @code{VERS_3} of @code{foo}.
>  
>  Finally if the parameter is @code{"@var{name2}@var{nodename}"} then in
>  addition to creating a symbol version (as if
> -- 
> 2.31.1

Jakub

[PATCH] docs: update symver attribute description

[Martin Liška]

This improves documentation as noticed by Jakub.

Ready for master?
Thanks,
Martin

gcc/ChangeLog:

* doc/extend.texi: Be more precise in documentation
of symver attribute.
---
 gcc/doc/extend.texi | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index e28e1860990..61d9a684b24 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3848,7 +3848,8 @@ foo_v1 (void)
 Will produce a @code{.symver foo_v1, foo@@VERS_1} directive in the assembler
 output. 
 
-One can also define multiple version for a given symbol.
+One can also define multiple version for a given symbol
+(starting from binutils 2.35).
 
 @smallexample
 __attribute__ ((__symver__ ("foo@@VERS_2"), __symver__ ("foo@@VERS_3")))
@@ -3863,8 +3864,8 @@ int symver_bar_v1 (void)
 @}
 @end smallexample
 
-This example creates an alias of @code{foo_v1} with symbol name
-@code{symver_foo_v1} which will be version @code{VERS_2} of @code{foo}.
+This example creates a symbol name @code{symver_foo_v1}
+which will be version @code{VERS_2} and @code{VERS_3} of @code{foo}.
 
 Finally if the parameter is @code{"@var{name2}@var{nodename}"} then in
 addition to creating a symbol version (as if
-- 
2.31.1

Re: [PATCH] ASAN: do not unpoison in OpenMP context

[Jakub Jelinek via Gcc-patches]

On Mon, Apr 12, 2021 at 01:21:29PM +0200, Martin Liška wrote:
> gcc/ChangeLog:
> 
>   PR sanitizer/99877
>   * gimplify.c (gimplify_expr): Right now, we unpoison all
>   variables before a goto . We should not do it if we are
>   in a omp context.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR sanitizer/99877
>   * g++.dg/asan/pr99877.C: New test.

Okay.

Jakub

Re: [committed] libstdc++: Fix test that fails in C++20 mode [PR 99995]

[Jonathan Wakely via Gcc-patches]

And this one fixes a couple more tests that fail with C++20.

Tested x86_64-linux. Committed to trunk.


commit 91dd7954c44b201aa3b16e66b18d7a5df00fded9
Author: Jonathan Wakely 
Date:   Mon Apr 12 11:45:21 2021

libstdc++: Fix some tests that fail in C++20 mode

The linear_congruential_engine negative tests fail with a different
error in C++20 mode, because double is no longer an invalid type for
NTTP. Adjust the expected errors.

libstdc++-v3/ChangeLog:

* testsuite/26_numerics/random/linear_congruential_engine/requirements/non_uint_neg.cc:
Adjust expected error for C++20 mode.
* testsuite/tr1/5_numerical_facilities/random/linear_congruential/requirements/non_uint_neg.cc:
Likewise.

diff --git a/libstdc++-v3/testsuite/26_numerics/random/linear_congruential_engine/requirements/non_uint_neg.cc b/libstdc++-v3/testsuite/26_numerics/random/linear_congruential_engine/requirements/non_uint_neg.cc
index e04e8ca6972..a36d63c6c7b 100644
--- a/libstdc++-v3/testsuite/26_numerics/random/linear_congruential_engine/requirements/non_uint_neg.cc
+++ b/libstdc++-v3/testsuite/26_numerics/random/linear_congruential_engine/requirements/non_uint_neg.cc
@@ -20,10 +20,12 @@
 
 // { dg-do compile { target c++11 } }
 // { dg-require-cstdint "" }
+// { dg-error "not a valid type" "" { target { ! c++20 } } 31 }
+// { dg-error "from 'int' to 'double'" "" { target c++20 } 31 }
 
 // 26.4.3.1 class template linear_congruential_engine [rand.eng.lcong]
 // 26.4.2.2 Concept RandomNumberEngine [rand.concept.eng]
 
 #include 
 
-std::linear_congruential_engine x; // { dg-error "not a valid type" }
+std::linear_congruential_engine x;
diff --git a/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/linear_congruential/requirements/non_uint_neg.cc b/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/linear_congruential/requirements/non_uint_neg.cc
index 5ad82db1def..53b15f32516 100644
--- a/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/linear_congruential/requirements/non_uint_neg.cc
+++ b/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/linear_congruential/requirements/non_uint_neg.cc
@@ -19,7 +19,8 @@
 
 // { dg-do compile }
 // { dg-options "-D_GLIBCXX_CONCEPT_CHECKS" }
-// { dg-error "not a valid type" "" { target *-*-* } 29 }
+// { dg-error "not a valid type" "" { target { ! c++20 } } 30 }
+// { dg-error "from 'int' to 'double'" "" { target c++20 } 30 }
 
 // 5.1.4.1 class template linear_congruential [tr.rand.eng.lcong]
 // 5.1.4.1 [4]

[PATCH] ASAN: do not unpoison in OpenMP context

[Martin Liška]

Hello.

Right now, we do not allow ASAN poisoning/unpoisoning for auto variables
if we are in a gimplify_omp_ctxp context. That's fine, but also need to
omit emission of unpoison calls when there's a goto jump pointing from OMP
context.

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

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

PR sanitizer/99877
* gimplify.c (gimplify_expr): Right now, we unpoison all
variables before a goto . We should not do it if we are
in a omp context.

gcc/testsuite/ChangeLog:

PR sanitizer/99877
* g++.dg/asan/pr99877.C: New test.
---
 gcc/gimplify.c  |  3 ++-
 gcc/testsuite/g++.dg/asan/pr99877.C | 19 +++
 2 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/asan/pr99877.C

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 1f417a52702..b65106b1459 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -14328,7 +14328,8 @@ gimplify_expr (tree *expr_p, gimple_seq *pre_p, 
gimple_seq *post_p,
 Doing so would prevent us from reporting a false positives.  */
  if (asan_poisoned_variables
  && asan_used_labels != NULL
- && asan_used_labels->contains (label))
+ && asan_used_labels->contains (label)
+ && !gimplify_omp_ctxp)
asan_poison_variables (asan_poisoned_variables, false, pre_p);
  break;
 
diff --git a/gcc/testsuite/g++.dg/asan/pr99877.C 
b/gcc/testsuite/g++.dg/asan/pr99877.C
new file mode 100644
index 000..95a86411405
--- /dev/null
+++ b/gcc/testsuite/g++.dg/asan/pr99877.C
@@ -0,0 +1,19 @@
+/* PR sanitizer/99877*/
+/* { dg-options "-fsanitize=address -fopenmp -O2" } */
+
+struct vector
+{
+  int size ();
+};
+int
+main ()
+{
+  vector outqueue;
+#pragma omp parallel
+  {
+goto continueloop;
+  continueloop:;
+  }
+  for (; outqueue.size ();)
+;
+}
-- 
2.31.1

[PATCH][pushed] mklog: support long filenames

[Martin Liška]

Pushed to master.

Martin

contrib/ChangeLog:

* gcc-changelog/git_commit.py: Support long filenames
in entries.
* gcc-changelog/test_email.py: Test it.
* gcc-changelog/test_patches.txt: Likewise.
---
 contrib/gcc-changelog/git_commit.py|  6 +++--
 contrib/gcc-changelog/test_email.py|  4 +++
 contrib/gcc-changelog/test_patches.txt | 35 ++
 3 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index 43fa7f40e4e..90e908e375c 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -415,8 +415,10 @@ class GitCommit:
 if line != line.rstrip():
 self.errors.append(Error('trailing whitespace', line))
 if len(line.replace('\t', ' ' * TAB_WIDTH)) > LINE_LIMIT:
-self.errors.append(Error('line exceeds %d character limit'
- % LINE_LIMIT, line))
+# support long filenames
+if not line.startswith('\t* ') or not line.endswith(':'):
+self.errors.append(Error('line exceeds %d character limit'
+ % LINE_LIMIT, line))
 m = changelog_regex.match(line)
 if m:
 last_entry = ChangeLogEntry(m.group(1).rstrip('/'),
diff --git a/contrib/gcc-changelog/test_email.py 
b/contrib/gcc-changelog/test_email.py
index 9d052e06467..8abf5c37487 100755
--- a/contrib/gcc-changelog/test_email.py
+++ b/contrib/gcc-changelog/test_email.py
@@ -420,3 +420,7 @@ class TestGccChangelog(unittest.TestCase):
 def test_changelog_removal(self):
 email = self.from_patch_glob('0001-ChangeLog-removal.patch', 
strict=True)
 assert not email.errors
+
+def test_long_filenames(self):
+email = self.from_patch_glob('0001-long-filenames')
+assert not email.errors
diff --git a/contrib/gcc-changelog/test_patches.txt 
b/contrib/gcc-changelog/test_patches.txt
index 012573b4845..3f9806dc076 100644
--- a/contrib/gcc-changelog/test_patches.txt
+++ b/contrib/gcc-changelog/test_patches.txt
@@ -3511,3 +3511,38 @@ index 5dd33a75c3a..c4ce432cb98 100644
 -- 
 2.30.1
 
+=== 0001-long-filenames ===
+From 0a5b3f87bdac5e61f9a626c795d30f9e93198585 Mon Sep 17 00:00:00 2001
+From: Martin Liska 
+Date: Mon, 12 Apr 2021 13:10:14 +0200
+Subject: [PATCH] libstdc++: Fix some tests that fail in C++20 mode
+
+The linear_congruential_engine negative tests fail with a different
+error in C++20 mode, because double is no longer an invalid type for
+NTTP. Adjust the expected errors.
+
+libstdc++-v3/ChangeLog:
+
+   * 
testsuite/26_numerics/random/linear_congruential_engine/requirements/non_uint_neg.cc:
+   Adjust expected error for C++20 mode.
+   * 
testsuite/tr1/5_numerical_facilities/random/linear_congruential/requirements/non_uint_neg.cc:
+   Likewise.
+---
+ .../linear_congruential_engine/requirements/non_uint_neg.cc   | 4 +++-
+ .../random/linear_congruential/requirements/non_uint_neg.cc   | 3 ++-
+ 2 files changed, 5 insertions(+), 2 deletions(-)
+
+diff --git 
a/libstdc++-v3/testsuite/26_numerics/random/linear_congruential_engine/requirements/non_uint_neg.cc
 
b/libstdc++-v3/testsuite/26_numerics/random/linear_congruential_engine/requirements/non_uint_neg.cc
+index e04e8ca6972..a36d63c6c7b 100644
+--- 
a/libstdc++-v3/testsuite/26_numerics/random/linear_congruential_engine/requirements/non_uint_neg.cc
 
b/libstdc++-v3/testsuite/26_numerics/random/linear_congruential_engine/requirements/non_uint_neg.cc
+@@ -1 +1,2 @@
+ 
++
+diff --git 
a/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/linear_congruential/requirements/non_uint_neg.cc
 
b/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/linear_congruential/requirements/non_uint_neg.cc
+index 5ad82db1def..53b15f32516 100644
+--- 
a/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/linear_congruential/requirements/non_uint_neg.cc
 
b/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/linear_congruential/requirements/non_uint_neg.cc
+@@ -1 +1,2 @@
+ 
++
-- 
2.31.1

[committed] libstdc++: Fix test that fails in C++20 mode [PR 99995]

[Jonathan Wakely via Gcc-patches]

The 17_intro/headers/c++1998/49745.cc test fails for C++20 mode with PCH
enabled, because PCH makes it include , which includes
, and that includes  in C++20 mode. The 
dependency should go away when C++20 atomic waiting is stable, but will
probably remain while the feature is experimental. Change the test to
always include , and XFAIL for C++20 and later.

libstdc++-v3/ChangeLog:

PR libstdc++/5
* testsuite/17_intro/headers/c++1998/49745.cc: Include all
standard headers and XFAIL for effective-target c++20.

Tested x86_64-linux. Committed to trunk.

commit 29046e02b84a16b6315d952d7f76c502d0d021c2
Author: Jonathan Wakely 
Date:   Mon Apr 12 11:12:47 2021

libstdc++: Fix test that fails in C++20 mode [PR 5]

The 17_intro/headers/c++1998/49745.cc test fails for C++20 mode with PCH
enabled, because PCH makes it include , which includes
, and that includes  in C++20 mode. The 
dependency should go away when C++20 atomic waiting is stable, but will
probably remain while the feature is experimental. Change the test to
always include , and XFAIL for C++20 and later.

libstdc++-v3/ChangeLog:

PR libstdc++/5
* testsuite/17_intro/headers/c++1998/49745.cc: Include all
standard headers and XFAIL for effective-target c++20.

diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++1998/49745.cc 
b/libstdc++-v3/testsuite/17_intro/headers/c++1998/49745.cc
index a13a40ec7db..204975e0316 100644
--- a/libstdc++-v3/testsuite/17_intro/headers/c++1998/49745.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++1998/49745.cc
@@ -18,5 +18,7 @@
 // .
 
 // libstdc++/49745
-#include 
+#include 
 int truncate = 0;
+
+// { dg-xfail-if "PR libstdc++/5" { c++20 } }

Re: [GCC 9] [PR47785] COLLECT_AS_OPTIONS

[Richard Biener via Gcc-patches]

On Fri, Apr 9, 2021 at 10:16 PM H.J. Lu  wrote:
>
> On Sun, Feb 23, 2020 at 10:32 PM Prathamesh Kulkarni
>  wrote:
> >
> > On Wed, 19 Feb 2020 at 19:54, Richard Biener  
> > wrote:
>
> > > > >
> > > > > OK with those changes.  Did you try if the diagnostics are visible
> > > > > (when you add -Wl,-debug or/and -Wl,-v to the link command?)
> > > > Made the changes in attached patch, thanks.
> > > > The diagnostics are visible with -Wl,-v and -Wl,-debug.
> > > > LTO bootstrap in progress on x86_64 and arm.
> > > > OK to commit if passes ?
> > >
> > > OK.
> > Thanks, I committed the patch in f1a681a174cdfb82e62c246d6f4add9a25fc2e43,
> > after verifying LTO+bootstrap passed on x86_64-unknown-linux-gnu.
> >
> > Thanks,
> > Prathamesh
>
> I'd like to backport this to GCC 9.   OK for GCC 9 branch?

OK.

Thanks,
Richard.

> Thanks.
>
> --
> H.J.

[PATCH wwwdoc] Mention Rocketlake [GCC11]

[Cui, Lili via Gcc-patches]

Updated wwwdocs for Rocketlake [GCC11], thanks.

 [PATCH] Mention Rocketlake
---
 htdocs/gcc-11/changes.html | 4 
 1 file changed, 4 insertions(+)

diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index a7fa4e1b..38725abc 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -634,6 +634,10 @@ a work-in-progress.
 The switch enables the CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, KEYLOCKER,
 AVX-VNNI, and HRESET ISA extensions.
   
+  GCC now supports the Intel CPU named Rocketlake through
+-march=rocketlake.
+Rocket Lake is based on Icelake client and minus SGX.
+  
 
 
-- 
2.17.1
Thanks,
Lili.


0001-Mention-Rocketlake.patch
Description: 0001-Mention-Rocketlake.patch

Re: [GCC 12] [PATCH] Add inline_ignore_target function attribute

[Richard Biener via Gcc-patches]

On Sat, Apr 10, 2021 at 5:11 PM H.J. Lu via Gcc-patches
 wrote:
>
> Add inline_ignore_target function attribute to inform the compiler that
> target specific option mismatch on functions with the always_inline
> attribute may be ignored.  On x86 targets, this attribute can be used on
> integer functions to ignore target non-integer option mismatch.

I'm not sure I like such attribute but please adjust default_target_can_inline_p
accordingly (only few targets override this hook).

Richard.

> gcc/c-family/
>
> PR target/99744
> * c-family/c-attribs.c (c_common_attribute_table): Add
> inline_ignore_target.
>
> gcc/
>
> PR target/99744
> * common/config/i386/i386-common.c (OPTION_MASK_*) to ...
> * common/config/i386/i386-common.h: Here.  New file.
> * config/i386/i386.c (ix86_can_inline_p): Ignore target
> non-integer option mismatch if callee has inline_ignore_target
> attribute.
> * config/i386/i386.h: Include common/config/i386/i386-common.h.
> * config/i386/ia32intrin.h (__rdtsc): Use always_inline function
> with inline_ignore_target attribute.
> (__rdtscp): Likewise.
> * config/i386/serializeintrin.h (_serialize): Likewise.
> * doc/extend.texi: Document inline_ignore_target function
> attribute.
>
> gcc/testsuite/
>
> PR target/99744
> * gcc.target/i386/pr99744-3.c: New test.
> ---
>  gcc/c-family/c-attribs.c  |   2 +
>  gcc/common/config/i386/i386-common.c  | 297 
>  gcc/common/config/i386/i386-common.h  | 315 ++
>  gcc/config/i386/i386.c|  41 ++-
>  gcc/config/i386/i386.h|   1 +
>  gcc/config/i386/ia32intrin.h  |  16 +-
>  gcc/config/i386/serializeintrin.h |   8 +-
>  gcc/doc/extend.texi   |   8 +
>  gcc/testsuite/gcc.target/i386/pr99744-3.c |  13 +
>  9 files changed, 396 insertions(+), 305 deletions(-)
>  create mode 100644 gcc/common/config/i386/i386-common.h
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr99744-3.c
>
> diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
> index c1f652d1dc9..863936af7ca 100644
> --- a/gcc/c-family/c-attribs.c
> +++ b/gcc/c-family/c-attribs.c
> @@ -323,6 +323,8 @@ const struct attribute_spec c_common_attribute_table[] =
>   attr_inline_exclusions },
>{ "artificial", 0, 0, true,  false, false, false,
>   handle_artificial_attribute, NULL },
> +  { "inline_ignore_target",   0, 0, true,  false, false, false,
> + handle_artificial_attribute, NULL },
>{ "flatten",0, 0, true,  false, false, false,
>   handle_flatten_attribute, NULL },
>{ "used",   0, 0, true,  false, false, false,
> diff --git a/gcc/common/config/i386/i386-common.c 
> b/gcc/common/config/i386/i386-common.c
> index b89183b830e..5caa53ac93f 100644
> --- a/gcc/common/config/i386/i386-common.c
> +++ b/gcc/common/config/i386/i386-common.c
> @@ -29,303 +29,6 @@ along with GCC; see the file COPYING3.  If not see
>  #include "opts.h"
>  #include "flags.h"
>
> -/* Define a set of ISAs which are available when a given ISA is
> -   enabled.  MMX and SSE ISAs are handled separately.  */
> -
> -#define OPTION_MASK_ISA_MMX_SET OPTION_MASK_ISA_MMX
> -#define OPTION_MASK_ISA_3DNOW_SET \
> -  (OPTION_MASK_ISA_3DNOW | OPTION_MASK_ISA_MMX_SET)
> -#define OPTION_MASK_ISA_3DNOW_A_SET \
> -  (OPTION_MASK_ISA_3DNOW_A | OPTION_MASK_ISA_3DNOW_SET)
> -
> -#define OPTION_MASK_ISA_SSE_SET OPTION_MASK_ISA_SSE
> -#define OPTION_MASK_ISA_SSE2_SET \
> -  (OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_SSE_SET)
> -#define OPTION_MASK_ISA_SSE3_SET \
> -  (OPTION_MASK_ISA_SSE3 | OPTION_MASK_ISA_SSE2_SET)
> -#define OPTION_MASK_ISA_SSSE3_SET \
> -  (OPTION_MASK_ISA_SSSE3 | OPTION_MASK_ISA_SSE3_SET)
> -#define OPTION_MASK_ISA_SSE4_1_SET \
> -  (OPTION_MASK_ISA_SSE4_1 | OPTION_MASK_ISA_SSSE3_SET)
> -#define OPTION_MASK_ISA_SSE4_2_SET \
> -  (OPTION_MASK_ISA_SSE4_2 | OPTION_MASK_ISA_SSE4_1_SET)
> -#define OPTION_MASK_ISA_AVX_SET \
> -  (OPTION_MASK_ISA_AVX | OPTION_MASK_ISA_SSE4_2_SET \
> -   | OPTION_MASK_ISA_XSAVE_SET)
> -#define OPTION_MASK_ISA_FMA_SET \
> -  (OPTION_MASK_ISA_FMA | OPTION_MASK_ISA_AVX_SET)
> -#define OPTION_MASK_ISA_AVX2_SET \
> -  (OPTION_MASK_ISA_AVX2 | OPTION_MASK_ISA_AVX_SET)
> -#define OPTION_MASK_ISA_FXSR_SET OPTION_MASK_ISA_FXSR
> -#define OPTION_MASK_ISA_XSAVE_SET OPTION_MASK_ISA_XSAVE
> -#define OPTION_MASK_ISA_XSAVEOPT_SET \
> -  (OPTION_MASK_ISA_XSAVEOPT | OPTION_MASK_ISA_XSAVE_SET)
> -#define OPTION_MASK_ISA_AVX512F_SET \
> -  (OPTION_MASK_ISA_AVX512F | OPTION_MASK_ISA_AVX2_SET)
> -#define OPTION_MASK_ISA_AVX512CD_SET \
> -  (OPTION_MASK_ISA_AVX512CD | OPTION_MASK_ISA_AVX512F_SET)
> -#define OPTION_MASK_ISA_AVX512PF_SET \
> -  (OPTION_MASK_ISA_AVX512PF 

[ping] Fix thinko in libcpp preparation patch for modules

[Eric Botcazou]

This is a regression in Ada on the mainline, 10 and 9 branches:
  https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567143.html

Thanks in advance.

-- 
Eric Botcazou

Re: [PATCH] testsuite/arm: Fix scan-assembler-times in pr96770.c with movt/movw

[Christophe Lyon via Gcc-patches]

ping?

On Tue, 6 Apr 2021 at 14:02, Christophe Lyon  wrote:
>
> ping?
>
> On Mon, 29 Mar 2021 at 11:01, Christophe Lyon
>  wrote:
> >
> > The previous change to this testcase missed the fact that the data may
> > be accessed via an anchor, depending on the optimization level,
> > leading to false failures.
> >
> > This patch restricts matching to upper16:lower16 followed by
> > non-spaces, followed by +4 (in f4) or +320 (in f5).
> >
> > Using '.*' instead of '[^ \]' would match accross the whole assembly
> > file, which is not what we want, hence the limitation with spaces.
> >
> > 2021-03-29  Christophe Lyon  
> >
> > gcc/testsuite/
> > PR target/96770
> > * gcc.target/arm/pure-code/pr96770.c: Fix scan-assembler-times
> > with movt/movw.
> > ---
> >  gcc/testsuite/gcc.target/arm/pure-code/pr96770.c | 12 +++-
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c 
> > b/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
> > index ae1bd10..3c69614 100644
> > --- a/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
> > +++ b/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
> > @@ -4,12 +4,13 @@
> >  int arr[1000];
> >  int *f4 (void) { return [1]; }
> >
> > -/* For cortex-m0 (thumb-1/v6m), we generate 4 movs with 
> > upper/lower:#arr+4.  */
> > +/* For cortex-m0 (thumb-1/v6m), we generate 2 pairs of movs/adds with 
> > upper/lower:#arr+4.  */
> >  /* { dg-final { scan-assembler-times "arr\\+4" 4 { target { { ! 
> > arm_thumb1_movt_ok } && { ! arm_thumb2_ok } } } } } */
> >
> >  /* For cortex-m with movt/movw (thumb-1/v8m.base or thumb-2), we
> > -   generate a movt/movw pair with upper/lower:#arr+4.  */
> > -/* { dg-final { scan-assembler-times "arr\\+4" 2 { target { 
> > arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
> > +   generate a movt/movw pair with upper/lower:#arr+4 possibly via an 
> > anchor.  */
> > +/* { dg-final { scan-assembler-times "upper16:\[^ \]+.\\+4" 1 { target { 
> > arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
> > +/* { dg-final { scan-assembler-times "lower16:\[^ \]+\\+4" 1 { target { 
> > arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
> >
> >  int *f5 (void) { return [80]; }
> >
> > @@ -17,5 +18,6 @@ int *f5 (void) { return [80]; }
> >  /* { dg-final { scan-assembler-times "arr\\+320" 1 { target { { ! 
> > arm_thumb1_movt_ok } && { ! arm_thumb2_ok } } } } } */
> >
> >  /* For cortex-m with movt/movw (thumb-1/v8m.base or thumb-2), we
> > -   generate a movt/movw pair with upper/lower:arr+320.  */
> > -/* { dg-final { scan-assembler-times "arr\\+320" 2 { target { 
> > arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
> > +   generate a movt/movw pair with upper/lower:arr+320 possibly via an 
> > anchor.  */
> > +/* { dg-final { scan-assembler-times "upper16:\[^ \]+\\+320" 1 { target { 
> > arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
> > +/* { dg-final { scan-assembler-times "lower16:\[^ \]+\\+320" 1 { target { 
> > arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
> > --
> > 2.7.4
> >

Re: [PATCH] Change march=alderlake ISA list and add m_ALDERLAKE to m_CORE_AVX2

[Hongtao Liu via Gcc-patches]

On Mon, Apr 12, 2021 at 3:20 PM Uros Bizjak via Gcc-patches
 wrote:
>
> On Mon, Apr 12, 2021 at 5:13 AM Cui, Lili  wrote:
> >
> > Hi Uros,
> >
> > This patch is about to change Alder Lake ISA list to GCC add m_ALDERLAKE to 
> > m_CORE_AVX2.
> > Alder Lake Intel Hybrid Technology is based on Tremont and plus 
> > ADCX/AVX/AVX2/BMI/BMI2/F16C/FMA/LZCNT/
> > PCONFIG/PKU/VAES/VPCLMULQDQ/SERIALIZE/HRESET/KL/WIDEKL/AVX-VNNI
> > For detailed information, please refer to 
> > https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
> >
> > Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
> >
> > OK for master backport to GCC 10?

This should be a typo, no need to backport since -march=alderlake is
introduced in GCC11.
I've committed the patch, thx for the review.

>
> OK for both.
>
> Thanks,
> Uros.
>
> >  [PATCH] Change march=alderlake ISA list and add m_ALDERLAKE to
> >  m_CORE_AVX2
> >
> > Alder Lake Intel Hybrid Technology will not support Intel(r) AVX-512. ISA
> > features such as Intel(r) AVX, AVX-VNNI, Intel(r) AVX2, and 
> > UMONITOR/UMWAIT/TPAUSE
> > are supported.
> >
> > gcc/
> > * config/i386/i386.h
> > (PTA_ALDERLAKE): Change alderlake ISA list.
> > * config/i386/i386-options.c
> > (m_CORE_AVX2): Add m_ALDERLAKE.
> > *common/config/i386/cpuinfo.h:
> > (get_intel_cpu): Add rocketlake model.
> > * doc/invoke.texi: Change alderlake ISA list.
> > ---
> >  gcc/common/config/i386/cpuinfo.h | 1 +
> >  gcc/config/i386/i386-options.c   | 2 +-
> >  gcc/config/i386/i386.h   | 7 ---
> >  gcc/doc/invoke.texi  | 9 +
> >  4 files changed, 11 insertions(+), 8 deletions(-)
> >
> > diff --git a/gcc/common/config/i386/cpuinfo.h 
> > b/gcc/common/config/i386/cpuinfo.h
> > index dbce022620a..c1ee7a1f8b8 100644
> > --- a/gcc/common/config/i386/cpuinfo.h
> > +++ b/gcc/common/config/i386/cpuinfo.h
> > @@ -476,6 +476,7 @@ get_intel_cpu (struct __processor_model *cpu_model,
> >cpu_model->__cpu_subtype = INTEL_COREI7_TIGERLAKE;
> >break;
> >   case 0x97:
> > +case 0x9a:   /* Alder Lake.  */
> >cpu = "alderlake";
> >CHECK___builtin_cpu_is ("corei7");
> > diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
> > index a8d06735d79..02e9c97d174 100644
> > --- a/gcc/config/i386/i386-options.c
> > +++ b/gcc/config/i386/i386-options.c
> > @@ -129,7 +129,7 @@ along with GCC; see the file COPYING3.  If not see
> >  #define m_CORE_AVX512 (m_SKYLAKE_AVX512 | m_CANNONLAKE \
> >| m_ICELAKE_CLIENT | m_ICELAKE_SERVER | 
> > m_CASCADELAKE \
> >| m_TIGERLAKE | m_COOPERLAKE | m_SAPPHIRERAPIDS)
> > -#define m_CORE_AVX2 (m_HASWELL | m_SKYLAKE | m_CORE_AVX512)
> > +#define m_CORE_AVX2 (m_HASWELL | m_SKYLAKE | m_ALDERLAKE | m_CORE_AVX512)
> >  #define m_CORE_ALL (m_CORE2 | m_NEHALEM  | m_SANDYBRIDGE | m_CORE_AVX2)
> >  #define m_GOLDMONT (HOST_WIDE_INT_1U< >  #define m_GOLDMONT_PLUS (HOST_WIDE_INT_1U< > diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> > index b4001d21b70..24894b4422a 100644
> > --- a/gcc/config/i386/i386.h
> > +++ b/gcc/config/i386/i386.h
> > @@ -2547,9 +2547,6 @@ constexpr wide_int_bitmask PTA_SAPPHIRERAPIDS = 
> > PTA_COOPERLAKE | PTA_MOVDIRI
> >| PTA_MOVDIR64B | PTA_AVX512VP2INTERSECT | PTA_ENQCMD | PTA_CLDEMOTE
> >| PTA_PTWRITE | PTA_WAITPKG | PTA_SERIALIZE | PTA_TSXLDTRK | PTA_AMX_TILE
> >| PTA_AMX_INT8 | PTA_AMX_BF16 | PTA_UINTR | PTA_AVXVNNI;
> > -constexpr wide_int_bitmask PTA_ALDERLAKE = PTA_SKYLAKE | PTA_CLDEMOTE
> > -  | PTA_PTWRITE | PTA_WAITPKG | PTA_SERIALIZE | PTA_HRESET | PTA_KL
> > -  | PTA_WIDEKL | PTA_AVXVNNI;
> >  constexpr wide_int_bitmask PTA_KNL = PTA_BROADWELL | PTA_AVX512PF
> >| PTA_AVX512ER | PTA_AVX512F | PTA_AVX512CD | PTA_PREFETCHWT1;
> >  constexpr wide_int_bitmask PTA_BONNELL = PTA_CORE2 | PTA_MOVBE;
> > @@ -2562,6 +2559,10 @@ constexpr wide_int_bitmask PTA_GOLDMONT_PLUS = 
> > PTA_GOLDMONT | PTA_RDPID
> >| PTA_SGX | PTA_PTWRITE;
> >  constexpr wide_int_bitmask PTA_TREMONT = PTA_GOLDMONT_PLUS | PTA_CLWB
> >| PTA_GFNI | PTA_MOVDIRI | PTA_MOVDIR64B | PTA_CLDEMOTE | PTA_WAITPKG;
> > +constexpr wide_int_bitmask PTA_ALDERLAKE = PTA_TREMONT | PTA_ADX | PTA_AVX
> > +  | PTA_AVX2 | PTA_BMI | PTA_BMI2 | PTA_F16C | PTA_FMA | PTA_LZCNT
> > +  | PTA_PCONFIG | PTA_PKU | PTA_VAES | PTA_VPCLMULQDQ | PTA_SERIALIZE
> > +  | PTA_HRESET | PTA_KL | PTA_WIDEKL | PTA_AVXVNNI;
> >  constexpr wide_int_bitmask PTA_KNM = PTA_KNL | PTA_AVX5124VNNIW
> >| PTA_AVX5124FMAPS | PTA_AVX512VPOPCNTDQ;
> >
> > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > index 46876ea2961..6b585cec740 100644
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -30188,10 +30188,11 @@ instruction set support.
> >
> >  @item alderlake
> >  Intel Alderlake CPU with 64-bit extensions, MOVBE, MMX, SSE, 

Re: [PATCH] Add rocketlake to gcc.

[Uros Bizjak via Gcc-patches]

On Mon, Apr 12, 2021 at 5:16 AM Cui, Lili  wrote:
>
> Hi Uros,
>
> This patch is about to add Rocket Lake to GCC.
> Rocket Lake is based on Ice Lake client  and minus SGX.
>
> For detailed information, please refer to 
> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>
> Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
>
> OK for master?

OK. The patch can be considered as  a fix, although a borderline one.

Thanks,
Uros.

>  [PATCH] Add rocketlake to gcc.
>
> gcc/
> * common/config/i386/cpuinfo.h
> (get_intel_cpu): Handle rocketlake.
> * common/config/i386/i386-common.c
> (processor_names): Add rocketlake.
> (processor_alias_table): Add rocketlake.
> * common/config/i386/i386-cpuinfo.h
> (processor_subtypes): Add INTEL_COREI7_ROCKETLAKE.
> * config.gcc: Add -march=rocketlake.
> * config/i386/i386-c.c
> (ix86_target_macros_internal): Handle rocketlake.
> * config/i386/i386-options.c
> (m_ROCKETLAKE)  : Define.
> (processor_cost_table): Add rocketlake cost.
> * config/i386/i386.h
> (ix86_size_cost) : Define TARGET_ROCKETLAKE.
> (processor_type) : Add PROCESSOR_ROCKETLAKE.
> (PTA_ROCKETLAKE): Ditto.
> * doc/extend.texi: Add rocketlake.
> * doc/invoke.texi: Add rocketlake.
>
> gcc/testsuite/
> * gcc.target/i386/funcspec-56.inc: Handle new march.
> * g++.target/i386/mv16.C: Handle new march
> ---
>  gcc/common/config/i386/cpuinfo.h  | 10 --
>  gcc/common/config/i386/i386-common.c  |  4 
>  gcc/common/config/i386/i386-cpuinfo.h |  1 +
>  gcc/config.gcc|  2 +-
>  gcc/config/i386/i386-c.c  |  7 +++
>  gcc/config/i386/i386-options.c|  5 -
>  gcc/config/i386/i386.h|  3 +++
>  gcc/doc/extend.texi   |  3 +++
>  gcc/doc/invoke.texi   |  8 
>  gcc/testsuite/g++.target/i386/mv16.C  |  6 ++
>  gcc/testsuite/gcc.target/i386/funcspec-56.inc |  1 +
>  11 files changed, 46 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/common/config/i386/cpuinfo.h 
> b/gcc/common/config/i386/cpuinfo.h
> index c1ee7a1f8b8..458f41de776 100644
> --- a/gcc/common/config/i386/cpuinfo.h
> +++ b/gcc/common/config/i386/cpuinfo.h
> @@ -404,14 +404,20 @@ get_intel_cpu (struct __processor_model *cpu_model,
>  case 0xa5:
>  case 0xa6:
>/* Comet Lake.  */
> -case 0xa7:
> -  /* Rocket Lake.  */
>cpu = "skylake";
>CHECK___builtin_cpu_is ("corei7");
>CHECK___builtin_cpu_is ("skylake");
>cpu_model->__cpu_type = INTEL_COREI7;
>cpu_model->__cpu_subtype = INTEL_COREI7_SKYLAKE;
>break;
> +case 0xa7:
> +  /* Rocket Lake.  */
> +  cpu = "rocketlake";
> +  CHECK___builtin_cpu_is ("corei7");
> +  CHECK___builtin_cpu_is ("rocketlake");
> +  cpu_model->__cpu_type = INTEL_COREI7;
> +  cpu_model->__cpu_subtype = INTEL_COREI7_ROCKETLAKE;
> +  break;
>  case 0x55:
>CHECK___builtin_cpu_is ("corei7");
>cpu_model->__cpu_type = INTEL_COREI7;
> diff --git a/gcc/common/config/i386/i386-common.c 
> b/gcc/common/config/i386/i386-common.c
> index b89183b830e..1e6c1590ac4 100644
> --- a/gcc/common/config/i386/i386-common.c
> +++ b/gcc/common/config/i386/i386-common.c
> @@ -1743,6 +1743,7 @@ const char *const processor_names[] =
>"skylake-avx512",
>"cannonlake",
>"icelake-client",
> +  "rocketlake",
>"icelake-server",
>"cascadelake",
>"tigerlake",
> @@ -1845,6 +1846,9 @@ const pta processor_alias_table[] =
>{"icelake-client", PROCESSOR_ICELAKE_CLIENT, CPU_HASWELL,
>  PTA_ICELAKE_CLIENT,
>  M_CPU_SUBTYPE (INTEL_COREI7_ICELAKE_CLIENT), P_PROC_AVX512F},
> +  {"rocketlake", PROCESSOR_ROCKETLAKE, CPU_HASWELL,
> +PTA_ROCKETLAKE,
> +M_CPU_SUBTYPE (INTEL_COREI7_ROCKETLAKE), P_PROC_AVX512F},
>{"icelake-server", PROCESSOR_ICELAKE_SERVER, CPU_HASWELL,
>  PTA_ICELAKE_SERVER,
>  M_CPU_SUBTYPE (INTEL_COREI7_ICELAKE_SERVER), P_PROC_AVX512F},
> diff --git a/gcc/common/config/i386/i386-cpuinfo.h 
> b/gcc/common/config/i386/i386-cpuinfo.h
> index 869115c4b6a..e68dd656046 100644
> --- a/gcc/common/config/i386/i386-cpuinfo.h
> +++ b/gcc/common/config/i386/i386-cpuinfo.h
> @@ -88,6 +88,7 @@ enum processor_subtypes
>INTEL_COREI7_SAPPHIRERAPIDS,
>INTEL_COREI7_ALDERLAKE,
>AMDFAM19H_ZNVER3,
> +  INTEL_COREI7_ROCKETLAKE,
>CPU_SUBTYPE_MAX
>  };
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 997a9f61a5c..357b0bed067 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -677,7 +677,7 @@ opteron-sse3 nocona core2 corei7 corei7-avx core-avx-i 
> core-avx2 atom \
>  slm nehalem westmere sandybridge ivybridge haswell broadwell bonnell 

Re: [PATCH] Change march=alderlake ISA list and add m_ALDERLAKE to m_CORE_AVX2

[Uros Bizjak via Gcc-patches]

On Mon, Apr 12, 2021 at 5:13 AM Cui, Lili  wrote:
>
> Hi Uros,
>
> This patch is about to change Alder Lake ISA list to GCC add m_ALDERLAKE to 
> m_CORE_AVX2.
> Alder Lake Intel Hybrid Technology is based on Tremont and plus 
> ADCX/AVX/AVX2/BMI/BMI2/F16C/FMA/LZCNT/
> PCONFIG/PKU/VAES/VPCLMULQDQ/SERIALIZE/HRESET/KL/WIDEKL/AVX-VNNI
> For detailed information, please refer to 
> https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>
> Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
>
> OK for master backport to GCC 10?

OK for both.

Thanks,
Uros.

>  [PATCH] Change march=alderlake ISA list and add m_ALDERLAKE to
>  m_CORE_AVX2
>
> Alder Lake Intel Hybrid Technology will not support Intel(r) AVX-512. ISA
> features such as Intel(r) AVX, AVX-VNNI, Intel(r) AVX2, and 
> UMONITOR/UMWAIT/TPAUSE
> are supported.
>
> gcc/
> * config/i386/i386.h
> (PTA_ALDERLAKE): Change alderlake ISA list.
> * config/i386/i386-options.c
> (m_CORE_AVX2): Add m_ALDERLAKE.
> *common/config/i386/cpuinfo.h:
> (get_intel_cpu): Add rocketlake model.
> * doc/invoke.texi: Change alderlake ISA list.
> ---
>  gcc/common/config/i386/cpuinfo.h | 1 +
>  gcc/config/i386/i386-options.c   | 2 +-
>  gcc/config/i386/i386.h   | 7 ---
>  gcc/doc/invoke.texi  | 9 +
>  4 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/gcc/common/config/i386/cpuinfo.h 
> b/gcc/common/config/i386/cpuinfo.h
> index dbce022620a..c1ee7a1f8b8 100644
> --- a/gcc/common/config/i386/cpuinfo.h
> +++ b/gcc/common/config/i386/cpuinfo.h
> @@ -476,6 +476,7 @@ get_intel_cpu (struct __processor_model *cpu_model,
>cpu_model->__cpu_subtype = INTEL_COREI7_TIGERLAKE;
>break;
>   case 0x97:
> +case 0x9a:   /* Alder Lake.  */
>cpu = "alderlake";
>CHECK___builtin_cpu_is ("corei7");
> diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
> index a8d06735d79..02e9c97d174 100644
> --- a/gcc/config/i386/i386-options.c
> +++ b/gcc/config/i386/i386-options.c
> @@ -129,7 +129,7 @@ along with GCC; see the file COPYING3.  If not see
>  #define m_CORE_AVX512 (m_SKYLAKE_AVX512 | m_CANNONLAKE \
>| m_ICELAKE_CLIENT | m_ICELAKE_SERVER | m_CASCADELAKE \
>| m_TIGERLAKE | m_COOPERLAKE | m_SAPPHIRERAPIDS)
> -#define m_CORE_AVX2 (m_HASWELL | m_SKYLAKE | m_CORE_AVX512)
> +#define m_CORE_AVX2 (m_HASWELL | m_SKYLAKE | m_ALDERLAKE | m_CORE_AVX512)
>  #define m_CORE_ALL (m_CORE2 | m_NEHALEM  | m_SANDYBRIDGE | m_CORE_AVX2)
>  #define m_GOLDMONT (HOST_WIDE_INT_1U<  #define m_GOLDMONT_PLUS (HOST_WIDE_INT_1U< diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> index b4001d21b70..24894b4422a 100644
> --- a/gcc/config/i386/i386.h
> +++ b/gcc/config/i386/i386.h
> @@ -2547,9 +2547,6 @@ constexpr wide_int_bitmask PTA_SAPPHIRERAPIDS = 
> PTA_COOPERLAKE | PTA_MOVDIRI
>| PTA_MOVDIR64B | PTA_AVX512VP2INTERSECT | PTA_ENQCMD | PTA_CLDEMOTE
>| PTA_PTWRITE | PTA_WAITPKG | PTA_SERIALIZE | PTA_TSXLDTRK | PTA_AMX_TILE
>| PTA_AMX_INT8 | PTA_AMX_BF16 | PTA_UINTR | PTA_AVXVNNI;
> -constexpr wide_int_bitmask PTA_ALDERLAKE = PTA_SKYLAKE | PTA_CLDEMOTE
> -  | PTA_PTWRITE | PTA_WAITPKG | PTA_SERIALIZE | PTA_HRESET | PTA_KL
> -  | PTA_WIDEKL | PTA_AVXVNNI;
>  constexpr wide_int_bitmask PTA_KNL = PTA_BROADWELL | PTA_AVX512PF
>| PTA_AVX512ER | PTA_AVX512F | PTA_AVX512CD | PTA_PREFETCHWT1;
>  constexpr wide_int_bitmask PTA_BONNELL = PTA_CORE2 | PTA_MOVBE;
> @@ -2562,6 +2559,10 @@ constexpr wide_int_bitmask PTA_GOLDMONT_PLUS = 
> PTA_GOLDMONT | PTA_RDPID
>| PTA_SGX | PTA_PTWRITE;
>  constexpr wide_int_bitmask PTA_TREMONT = PTA_GOLDMONT_PLUS | PTA_CLWB
>| PTA_GFNI | PTA_MOVDIRI | PTA_MOVDIR64B | PTA_CLDEMOTE | PTA_WAITPKG;
> +constexpr wide_int_bitmask PTA_ALDERLAKE = PTA_TREMONT | PTA_ADX | PTA_AVX
> +  | PTA_AVX2 | PTA_BMI | PTA_BMI2 | PTA_F16C | PTA_FMA | PTA_LZCNT
> +  | PTA_PCONFIG | PTA_PKU | PTA_VAES | PTA_VPCLMULQDQ | PTA_SERIALIZE
> +  | PTA_HRESET | PTA_KL | PTA_WIDEKL | PTA_AVXVNNI;
>  constexpr wide_int_bitmask PTA_KNM = PTA_KNL | PTA_AVX5124VNNIW
>| PTA_AVX5124FMAPS | PTA_AVX512VPOPCNTDQ;
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 46876ea2961..6b585cec740 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -30188,10 +30188,11 @@ instruction set support.
>
>  @item alderlake
>  Intel Alderlake CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, 
> SSSE3,
> -SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI,
> -BMI2, F16C, RDSEED, ADCX, PREFETCHW, CLFLUSHOPT, XSAVEC, XSAVES, CLDEMOTE,
> -PTWRITE, WAITPKG, SERIALIZE, KEYLOCKER, HRESET and AVX-VNNI instruction set
> -support.
> +SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES,
> +XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, UMIP, GFNI-SSE, CLWB,