[PATCH][pushed] mklog: fix test_mklog.py tests.

[Martin Liška]

This fixed what I broke in g:c38f679eebffd601d977330f24def69f4b620c93.

Thanks,
Martin

contrib/ChangeLog:

* mklog.py: Fix broken tests.
---
 contrib/mklog.py | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/contrib/mklog.py b/contrib/mklog.py
index 00a001ec5ae..1604f0516d0 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -65,13 +65,13 @@ PATCH must be generated using diff(1)'s -up or -cp options
 """
 
 script_folder = os.path.realpath(__file__)

-gcc_root = os.path.dirname(os.path.dirname(script_folder))
+root = os.path.dirname(os.path.dirname(script_folder))
 
 
 def find_changelog(path):

 folder = os.path.split(path)[0]
 while True:
-if os.path.exists(os.path.join(args.directory, folder, 'ChangeLog')):
+if os.path.exists(os.path.join(root, folder, 'ChangeLog')):
 return folder
 folder = os.path.dirname(folder)
 if folder == '':
@@ -277,7 +277,7 @@ if __name__ == '__main__':
 help='Do not generate function names in ChangeLogs')
 parser.add_argument('-p', '--fill-up-bug-titles', action='store_true',
 help='Download title of mentioned PRs')
-parser.add_argument('-d', '--directory', default=gcc_root,
+parser.add_argument('-d', '--directory',
 help='Root directory where to search for ChangeLog '
 'files')
 parser.add_argument('-c', '--changelog',
@@ -288,6 +288,8 @@ if __name__ == '__main__':
 args = parser.parse_args()
 if args.input == '-':
 args.input = None
+if args.directory:
+root = args.directory
 
 data = open(args.input) if args.input else sys.stdin

 if args.update_copyright:
--
2.30.2

Re: [PATCH RFC][PR98736]Compute and use programing order preserved RPO in loop distribution

[bin.cheng via Gcc-patches]

> > In the patch, I just duplicated and created new function 
> > loop_first_rev_post_order_compute_fn.
> > I am not sure if I should change the original function 
> > pre_and_rev_post_order_compute_fn
> > (maybe not at this stage)? I am neither sure about the name, though haven't 
> > got a better one.
> > Any comment is appreciated?
> 
> So your new function seems to do what rev_post_order_and_mark_dfs_back_seme 
> does
> when you specify for_iteration = true.  Specifically that function then does
> 
>If FOR_ITERATION is true then compute an RPO where SCCs form a
>contiguous region in the RPO array.

Right, this is exactly what I need.  Attachment is the updated patch.  
Bootstrap and test on x86_64.
> 
> it in particular should handle the situation well where there are multiple 
> exits
> from a loop to different outer loops (consider a switch stmt exiting to
> the immediate outer or to the next outer loop) - something your patch
> likely still handles "randomly" (though we of course generally do not handle
> such exits well).
> 
> The idea of the rev_post_order_and_mark_dfs_back_seme algorithm is to
> treat SCCs as single nodes for the "outermost" RPO walk and then
> continuously expand SCCs from outer to inner.
> 
> So for the testcase I'm quite sure using the this function for computing
> the RPO would work but extra thoughts are appreciated.
Maybe another more straightforward or easier to understand function name?

Thanks,
bin
> 
> Thanks,
> Richard.
>

pr98736-20210323.txt
Description: Binary data

Re: [committed][nvptx] Set -misa=sm_35 by default

[Thomas Schwinge]

Hi Tom!

Ping, one item specifically: "backporting [...] to release branches" (see
below) -- this ping is dedicated to the upcoming GCC 10.3 release.  ;-)

On 2021-01-13T12:59:14+0100, I wrote:
> On 2020-10-09T13:56:09+0200, Tom de Vries  wrote:
>> The nvptx-as assembler verifies the ptx code using ptxas, if there's any
>> in the PATH.
>>
>> The default in the nvptx port for -misa=sm_xx is sm_30, but the ptxas of the
>> latest cuda release (11.1) no longer supports sm_30.
>>
>> Consequently we cannot build gcc against that release (although we should
>> still be able to build without any cuda release).
>>
>> Fix this by setting -misa=sm_35 by default.
>>
>> Tested check-gcc on nvptx.
>>
>> Tested libgomp on x86_64-linux with nvpx accelerator.
>>
>> Both build against cuda 9.1.
>>
>> Committed to trunk.
>
> ACK.
>
> What is your opinion about backporting that (plus Tobias' documentation
> update, plus corresponding web 'changes.html' updates?) to release
> branches, so that nvptx offloading users may use GCC 10/9/8 with CUDA
> 11.0+?
>
> I don't think losing sm_30 support is a major concern: support for sm_35
> has been introduced with PTX ISA 3.1, CUDA 5.0, driver r302.


Grüße
 Thomas


> Further:

> After quite some digression to first add a testsuite to nvptx-tools (see
>  or just
> ), which
> I found advisable generally, and then given the kinds of changes we're
> now doing :-) -- I've now prepared nvptx-as code changes as discussed in
>  "nvptx-as
> should not assume a default sm version".  (Currently testing.)

>> [nvptx] Set -misa=sm_35 by default
>
>>  PR target/97348
>>  * config/nvptx/nvptx.h (ASM_SPEC): Also pass -m to nvptx-as if
>>  default is used.
>>  * config/nvptx/nvptx.opt (misa): Init with PTX_ISA_SM35.
>
>> --- a/gcc/config/nvptx/nvptx.h
>> +++ b/gcc/config/nvptx/nvptx.h
>
>> -#define ASM_SPEC "%{misa=*:-m %*}"
>> +/* Default needs to be in sync with default for misa in nvptx.opt.
>> +   We add a default here to work around a hard-coded sm_30 default in
>> +   nvptx-as.  */
>> +#define ASM_SPEC "%{misa=*:-m %*; :-m sm_35}"
>
>> --- a/gcc/config/nvptx/nvptx.opt
>> +++ b/gcc/config/nvptx/nvptx.opt
>
>> +; Default needs to be in sync with default in ASM_SPEC in nvptx.h.
>>  misa=
>> -Target RejectNegative ToLower Joined Enum(ptx_isa) Var(ptx_isa_option) 
>> Init(PTX_ISA_SM30)
>> +Target RejectNegative ToLower Joined Enum(ptx_isa) Var(ptx_isa_option) 
>> Init(PTX_ISA_SM35)
>>  Specify the version of the ptx ISA to use.
>
> As I'd suggested in
>  "nvptx-as
> should not assume a default sm version", I'd then push the attached
> "[nvptx] Let nvptx-as figure out the target architecture [PR97348]" to
> GCC master branch, OK?  (Currently testing.)
>
> That one I wouldn't backport to GCC release branches, so that we don't
> require users to update nvptx-tools for these builds.
>
>
> Grüße
>  Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf
>From eac0d3458f38cd5bb4c930b2887a547b64b046ef Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 13 Jan 2021 09:04:47 +0100
Subject: [PATCH] [nvptx] Let nvptx-as figure out the target architecture
 [PR97348]

... now that it has been enhanced to do so.

This is a follow-up to PR97348 commit 383400a6078d75bbfa1216c9af2c37f7e88740c9
"[nvptx] Set -misa=sm_35 by default".

	gcc/
	PR target/97348
	* config/nvptx/nvptx.h (ASM_SPEC): Don't set.
	* config/nvptx/nvptx.opt (misa): Adjust comment.
---
 gcc/config/nvptx/nvptx.h   | 5 -
 gcc/config/nvptx/nvptx.opt | 1 -
 2 files changed, 6 deletions(-)

diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index 2451703e77f..1a61e6207f6 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -29,11 +29,6 @@
 
 #define STARTFILE_SPEC "%{mmainkernel:crt0.o}"
 
-/* Default needs to be in sync with default for misa in nvptx.opt.
-   We add a default here to work around a hard-coded sm_30 default in
-   nvptx-as.  */
-#define ASM_SPEC "%{misa=*:-m %*; :-m sm_35}"
-
 #define TARGET_CPU_CPP_BUILTINS()		\
   do		\
 {		\
diff --git a/gcc/config/nvptx/nvptx.opt b/gcc/config/nvptx/nvptx.opt
index 51363e4e276..cf7f9022663 100644
--- a/gcc/config/nvptx/nvptx.opt
+++ b/gcc/config/nvptx/nvptx.opt
@@ -61,7 +61,6 @@ Enum(ptx_isa) String(sm_30) Value(PTX_ISA_SM30)
 EnumValue
 Enum(ptx_isa) String(sm_35) Value(PTX_ISA_SM35)
 
-; Default needs to be in sync with default in ASM_SPEC in nvptx.h.
 misa=
 Target RejectNegative ToLower Joined Enum(ptx_isa) Var(ptx_isa_option) Init(PTX_ISA_SM35)
 Specify the version of the ptx ISA to use.
-- 
2.17.1

Re: [PATCH 3/3] x86: Update memcpy/memset inline strategies for -mtune=generic

[Richard Biener via Gcc-patches]

On Tue, Mar 23, 2021 at 3:41 AM Hongyu Wang  wrote:
>
> > Hongyue, please collect code size differences on SPEC CPU 2017 and
> > eembc.
>
> Here is code size difference for this patch

Thanks, nothing too bad although slightly larger impacts than envisioned.

> SPEC CPU 2017
>difference w patch  w/o 
> patch
> 500.perlbench_r  0.051% 1622637  1621805
> 502.gcc_r 0.039% 6930877  6928141
> 505.mcf_r 0.098% 16413  16397
> 520.omnetpp_r   0.083% 1327757  1326653
> 523.xalancbmk_r0.001% 3575709  3575677
> 525.x264_r   -0.067%   769095769607
> 531.deepsjeng_r 0.071% 67629  67581
> 541.leela_r   -3.062%   127629131661
> 548.exchange2_r-0.338%66141  66365
> 557.xz_r0.946%128061126861
>
> 503.bwaves_r  0.534% 33117  32941
> 507.cactuBSSN_r0.004% 2993645  2993517
> 508.namd_r 0.006% 851677851629
> 510.parest_r0.488% 6741277  6708557
> 511.povray_r   -0.021%   849290849466
> 521.wrf_r 0.022% 29682154   29675530
> 526.blender_r  0.054% 7544057  7540009
> 527.cam4_r  0.043% 6102234  6099594
> 538.imagick_r  -0.015%   1625770  1626010
> 544.nab_r 0.155% 155453155213
> 549.fotonik3d_r  0.000% 351757351757
> 554.roms_r  0.041% 735837735533
>
> eembc
> differencew patch  w/o patch
> aifftr01  0.762% 14813
> 14701
> aiifft01  0.556% 14477
> 14397
> idctrn010.101% 1585315837
> cjpeg-rose7-preset 0.114% 56125  56061
> nnet_test -0.848%   35549  35853
> aes   0.125% 38493
> 38445
> cjpegv2data 0.108% 59213  59149
> djpegv2data 0.025% 63821  63805
> huffde   -0.104%   30621  
> 30653
> mp2decoddata-0.047%   68285  68317
> mp2enf32data1  0.018% 86925  86909
> mp2enf32data2  0.018% 89357  89341
> mp2enf32data3  0.018% 88253  88237
> mp3playerfixeddata   0.103% 46877  46829
> ip_pktcheckb1m  0.191% 25213  25165
> nat   0.527% 45757 
> 45517
> ospfv2   0.196% 24573 
> 24525
> routelookup 0.189% 25389  25341
> tcpbulk0.155% 30925  30877
> textv2data0.055% 29101  29085
>
> H.J. Lu via Gcc-patches  于2021年3月22日周一 下午9:39写道：
> >
> > On Mon, Mar 22, 2021 at 6:29 AM Richard Biener
> >  wrote:
> > >
> > > On Mon, Mar 22, 2021 at 2:19 PM H.J. Lu via Gcc-patches
> > >  wrote:
> > > >
> > > > Simply memcpy and memset inline strategies to avoid branches for
> > > > -mtune=generic:
> > > >
> > > > 1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
> > > >load and store for up to 16 * 16 (256) bytes when the data size is
> > > >fixed and known.
> > > > 2. Inline only if data size is known to be <= 256.
> > > >a. Use "rep movsb/stosb" with simple code sequence if the data size
> > > >   is a constant.
> > > >b. Use loop if data size is not a constant.
> > > > 3. Use memcpy/memset libray function if data size is unknown or > 256.
> > > >
> > > > With -mtune=generic -O2,
> > >
> > > Is there any visible code-size effect of increasing CLEAR_RATIO on
> >
> > Hongyue, please collect code size differences on SPEC CPU 2017 and
> > eembc.
> >
> > > SPEC/eembc?  Did you play with other values of MOVE/CLEAR_RATIO?
> > > 17 memory-to-memory/memory-clear insns looks quite a lot.
> > >
> >
> > Yes, we did.  256 bytes is the threshold above which memcpy/memset in libc
> > win. Below 256 bytes, 16 by_pieces move/sto

Re: [PATCH RFC][PR98736]Compute and use programing order preserved RPO in loop distribution

[Richard Biener via Gcc-patches]

On Tue, Mar 23, 2021 at 8:55 AM bin.cheng  wrote:
>
> > > In the patch, I just duplicated and created new function 
> > > loop_first_rev_post_order_compute_fn.
> > > I am not sure if I should change the original function 
> > > pre_and_rev_post_order_compute_fn
> > > (maybe not at this stage)? I am neither sure about the name, though 
> > > haven't got a better one.
> > > Any comment is appreciated?
> >
> > So your new function seems to do what rev_post_order_and_mark_dfs_back_seme 
> > does
> > when you specify for_iteration = true.  Specifically that function then does
> >
> >If FOR_ITERATION is true then compute an RPO where SCCs form a
> >contiguous region in the RPO array.
>
> Right, this is exactly what I need.  Attachment is the updated patch.  
> Bootstrap and test on x86_64.

OK - Thank you.

> >
> > it in particular should handle the situation well where there are multiple 
> > exits
> > from a loop to different outer loops (consider a switch stmt exiting to
> > the immediate outer or to the next outer loop) - something your patch
> > likely still handles "randomly" (though we of course generally do not handle
> > such exits well).
> >
> > The idea of the rev_post_order_and_mark_dfs_back_seme algorithm is to
> > treat SCCs as single nodes for the "outermost" RPO walk and then
> > continuously expand SCCs from outer to inner.
> >
> > So for the testcase I'm quite sure using the this function for computing
> > the RPO would work but extra thoughts are appreciated.
> Maybe another more straightforward or easier to understand function name?

Heh ;)  I suppose we could wrap it with an easier to grok name for the
callers not wanting to apply it on a region.

Richard.

> Thanks,
> bin
> >
> > Thanks,
> > Richard.
> >

Re: [RFC] Run pass_sink_code once more after ivopts/fre

[Richard Biener]

On Tue, 23 Mar 2021, Xionghu Luo wrote:

> 
> 
> On 2020/12/23 00:53, Richard Biener wrote:
> > On December 21, 2020 10:03:43 AM GMT+01:00, Xiong Hu Luo
> >  wrote:
> >> Here comes another case that requires run a pass once more, as this is
> >> not the common suggested direction to solve problems, not quite sure
> >> whether it is still a reasonble fix here.  Source code is something
> >> like:
> >>
> >> ref = ip + *hslot;
> >> while (ip < in_end - 2) {
> >>   unsigned int len = 2;
> >>   len++;
> >> for ()   {
> >>   do len++;
> >>   while (len < maxlen && ref[len] == ip[len]); //sink code here.
> >>   break;
> >> }
> >>   len -= 2;
> >>   ip++;
> >>   ip += len + 1;
> >>   if (ip >= in_end - 2)
> >> break;
> >> }
> >>
> >> Before ivopts, the gimple for inner while loop is xxx.c.172t.slp1:
> >>
> >>[local count: 75120046]:
> >>   # len_160 = PHI 
> >>   len_189 = len_160 + 1;
> >>   _423 = (sizetype) len_189;
> >>   _424 = ip_229 + _423;
> >>   if (maxlen_186 > len_189)
> >> goto ; [94.50%]
> >>   else
> >> goto ; [5.50%]
> >>
> >>[local count: 70988443]:
> >>   _84 = *_424;
> >>   _86 = ref_182 + _423;
> >>   _87 = *_86;
> >>   if (_84 == _87)
> >> goto ; [94.50%]
> >>   else
> >> goto ; [5.50%]
> >>
> >>[local count: 67084079]:
> >>   goto ; [100.00%]
> >>
> >>[local count: 14847855]:
> >>   # len_263 = PHI 
> >>   # _262 = PHI <_423(32), _423(31)>
> >>   # _264 = PHI <_424(32), _424(31)>
> >>   len_190 = len_263 + 4294967295;
> >>   if (len_190 <= 6)
> >> goto ; [0.00%]
> >>   else
> >> goto ; [100.00%]
> >>
> >> Then in ivopts, instructions are updated to xxx.c.174t.ivopts:
> >>
> >>[local count: 75120046]:
> >>   # ivtmp.30_29 = PHI 
> >>   _34 = (unsigned int) ivtmp.30_29;
> >>   len_160 = _34 + 4294967295;
> >>   _423 = ivtmp.30_29;
> >>   _35 = (unsigned long) ip_229;
> >>   _420 = ivtmp.30_29 + _35;
> >>   _419 = (uint8_t *) _420;
> >>   _424 = _419;
> >>   len_418 = (unsigned int) ivtmp.30_29;
> >>   if (maxlen_186 > len_418)
> >> goto ; [94.50%]
> >>   else
> >> goto ; [5.50%]
> >>
> >>[local count: 70988443]:
> >>   _84 = MEM[(uint8_t *)ip_229 + ivtmp.30_29 * 1];
> >>   ivtmp.30_31 = ivtmp.30_29 + 1;
> >>   _417 = ref_182 + 18446744073709551615;
> >>   _87 = MEM[(uint8_t *)_417 + ivtmp.30_31 * 1];
> >>   if (_84 == _87)
> >> goto ; [94.50%]
> >>   else
> >> goto ; [5.50%]
> >>
> >>[local count: 67084079]:
> >>   goto ; [100.00%]
> >>
> >>[local count: 14847855]:
> >>   # len_263 = PHI 
> >>   # _262 = PHI <_423(32), _423(31)>
> >>   # _264 = PHI <_424(32), _424(31)>
> >>   len_190 = len_263 + 4294967295;
> >>   if (len_190 <= 6)
> >> goto ; [0.00%]
> >>   else
> >> goto ; [100.00%]
> >>
> >> Some instructions in BB 31 are not used in the loop and could be sinked
> >> out of loop to reduce the computation, but they are not sinked
> >> throughout all passes later.  Run the sink_code pass once more at least
> >> after fre5 could improve this typical case performance 23% due to few
> >> instructions exausted in loop.
> >> xxx.c.209t.sink2:
> >>
> >> Sinking _419 = (uint8_t *) _420;
> >> from bb 31 to bb 89
> >> Sinking _420 = ivtmp.30_29 + _35;
> >> from bb 31 to bb 89
> >> Sinking _35 = (unsigned long) ip_229;
> >> from bb 31 to bb 89
> >> Sinking len_160 = _34 + 4294967295;
> >> from bb 31 to bb 33
> >>
> >> I also tested the SPEC2017 performance on P8LE, 544.nab_r is improved
> >> by 2.43%, but no big changes to other cases, GEOMEAN is improved quite
> >> small with 0.25%.
> >>
> >> The reason why it should be run after fre5 is fre would do some phi
> >> optimization to expose the optimization.  The patch put it after
> >> pass_modref is due to my guess that some gimple optimizations like
> >> thread_jumps, dse, dce etc. could provide more opportunities for
> >> sinking code.  Not sure it is the correct place to put.  I also
> >> verified this issue exists in both X86 and ARM64.
> >> Any comments?  Thanks.
> > 
> > It definitely should be before uncprop (but context stops there). And yes,
> > re-running passes isn't the very, very best thing to do without explaining
> > it cannot be done in other ways. Not for late stage 3 anyway.
> > 
> > Richard.
> > 
> 
> Thanks.  Also tried to implement this in a seperate RTL pass, which
> would be better?  I guess this would also be stage1 issues...

Yes, that's also for stage1 obviously.  Can you check how the number
of sink opportunities of your RTL pass changes if you add the
2nd GIMPLE sinking pass?

I'll note that you are not sinking later stmts first (you only
walk insns reverse but not BBs).  GIMPLE sinking performs a
domwalk over post dominators (but it has an easier job because
of PHIs).  I guess you'd want to walk starting from loop exit
blocks (from innermost loops as you do) in reverse program order.

I'll also note that you don't have to check whether stmts you
want to sink have their uses set after it - you can emit copies
to a new pseudo 

[Patch] Fortran: Extend buffer, use snprintf to avoid overflows [PR99369]

[Tobias Burnus]

For details, see PR.

If I have not miscounted, the failing message has
32 characters + three names → (3*62 + 1 + 32) = 219 > 200.
I add another 18 characters for longer translation strings.
If that is not enough, there will be truncation but
no buffer overflow thanks to snprintf.

OK for mainline and GCC 10?
[If there are no comments or an OK,
I intent to commit it as obvious tomorrow.]

Tobias

PS: Patches which I would like to see in GCC 11 and 10,
but which are still pending review:
* [Patch] Fortran: Fix intrinsic null() handling [PR99651]
* [Patch] Fortran: Fix func decl mismatch [PR93660]

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf
Fortran: Extend buffer, use snprintf to avoid overflows [PR99369]

gcc/fortran/ChangeLog:

	PR fortran/99369
	* resolve.c (resolve_operator): Make 'msg' buffer larger
	and use snprintf.

gcc/testsuite/ChangeLog:

	PR fortran/99369
	* gfortran.dg/longnames.f90: New test.

 gcc/fortran/resolve.c   | 82 -
 gcc/testsuite/gfortran.dg/longnames.f90 | 92 +
 2 files changed, 137 insertions(+), 37 deletions(-)

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 715fecd4b3a..1c9b0c5cb62 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -3994,7 +3994,8 @@ static bool
 resolve_operator (gfc_expr *e)
 {
   gfc_expr *op1, *op2;
-  char msg[200];
+  /* One error uses 3 names; additional space for wording (also via gettext). */
+  char msg[3*GFC_MAX_SYMBOL_LEN + 1 + 50];
   bool dual_locus_error;
   bool t = true;
 
@@ -4047,7 +4048,8 @@ resolve_operator (gfc_expr *e)
   if ((op1 && op1->expr_type == EXPR_NULL)
   || (op2 && op2->expr_type == EXPR_NULL))
 {
-  sprintf (msg, _("Invalid context for NULL() pointer at %%L"));
+  snprintf (msg, sizeof (msg),
+		_("Invalid context for NULL() pointer at %%L"));
   goto bad_op;
 }
 
@@ -4063,8 +4065,9 @@ resolve_operator (gfc_expr *e)
 	  break;
 	}
 
-  sprintf (msg, _("Operand of unary numeric operator %%<%s%%> at %%L is %s"),
-	   gfc_op2string (e->value.op.op), gfc_typename (e));
+  snprintf (msg, sizeof (msg),
+		_("Operand of unary numeric operator %%<%s%%> at %%L is %s"),
+		gfc_op2string (e->value.op.op), gfc_typename (e));
   goto bad_op;
 
 case INTRINSIC_PLUS:
@@ -4079,14 +4082,14 @@ resolve_operator (gfc_expr *e)
 	}
 
   if (op1->ts.type == BT_DERIVED || op2->ts.type == BT_DERIVED)
-	sprintf (msg,
-	   _("Unexpected derived-type entities in binary intrinsic "
-		 "numeric operator %%<%s%%> at %%L"),
+	snprintf (msg, sizeof (msg),
+		  _("Unexpected derived-type entities in binary intrinsic "
+		  "numeric operator %%<%s%%> at %%L"),
 	   gfc_op2string (e->value.op.op));
   else
-  	sprintf (msg,
-	   _("Operands of binary numeric operator %%<%s%%> at %%L are %s/%s"),
-	   gfc_op2string (e->value.op.op), gfc_typename (op1),
+	snprintf (msg, sizeof(msg),
+		  _("Operands of binary numeric operator %%<%s%%> at %%L are %s/%s"),
+		  gfc_op2string (e->value.op.op), gfc_typename (op1),
 	   gfc_typename (op2));
   goto bad_op;
 
@@ -4099,9 +4102,9 @@ resolve_operator (gfc_expr *e)
 	  break;
 	}
 
-  sprintf (msg,
-	   _("Operands of string concatenation operator at %%L are %s/%s"),
-	   gfc_typename (op1), gfc_typename (op2));
+  snprintf (msg, sizeof (msg),
+		_("Operands of string concatenation operator at %%L are %s/%s"),
+		gfc_typename (op1), gfc_typename (op2));
   goto bad_op;
 
 case INTRINSIC_AND:
@@ -4142,9 +4145,10 @@ resolve_operator (gfc_expr *e)
 	  goto simplify_op;
 	}
 
-  sprintf (msg, _("Operands of logical operator %%<%s%%> at %%L are %s/%s"),
-	   gfc_op2string (e->value.op.op), gfc_typename (op1),
-	   gfc_typename (op2));
+  snprintf (msg, sizeof (msg),
+		_("Operands of logical operator %%<%s%%> at %%L are %s/%s"),
+		gfc_op2string (e->value.op.op), gfc_typename (op1),
+		gfc_typename (op2));
 
   goto bad_op;
 
@@ -4165,8 +4169,8 @@ resolve_operator (gfc_expr *e)
 	  break;
 	}
 
-  sprintf (msg, _("Operand of .not. operator at %%L is %s"),
-		  gfc_typename (op1));
+  snprintf (msg, sizeof (msg), _("Operand of .not. operator at %%L is %s"),
+		gfc_typename (op1));
   goto bad_op;
 
 case INTRINSIC_GT:
@@ -4276,16 +4280,16 @@ resolve_operator (gfc_expr *e)
 	}
 
   if (op1->ts.type == BT_LOGICAL && op2->ts.type == BT_LOGICAL)
-	sprintf (msg,
-		 _("Logicals at %%L must be compared with %s instead of %s"),
-		 (e->value.op.op == INTRINSIC_EQ
-		  || e->value.op.op == INTRINSIC_EQ_OS)
-		 ? ".eqv." : ".neqv.", gfc_op2string (e->value.op.op));
+	snprintf (msg, sizeof (msg),
+		  _("Logicals at %%L must be compared with %s instead of %s"),
+		  (e->value.op.op == INTRINSIC_EQ
+		   || e->value.op.op == INTRINSIC_EQ_OS)
+		  ? ".eqv." : ".ne

Re: [PATCH v4 0/7] RISC-V big endian support

[Kito Cheng via Gcc-patches]

Hi Marcus:

Verified with spike for rv32be and rv64be.

Committed to trunk, appreciate your work on this, RISC-V big-endian
support just reached a great milestone today!

On Sat, Mar 20, 2021 at 3:50 AM Marcus Comstedt  wrote:
>
> New update of the RISC-V big endian support.
>
> Changes since v3:
>
> * Changed riscv_subword to take endianness into account.  This
>   fixed multiple issues with long long on 32-bit.
>
> Testsuite results are now on par with little endian also on 32 bit.
> The only exception is gcc.c-torture/compile/pr35318.c, which has an
> internal compiler error (test fail) on 32 bit big endian, but not
> on 32 bit little endian (test pass, even though the generated code
> looks suspicious).
>
>
>   // Marcus
>
>

[PATCH] c++: Fix source_location inconsistency between calls from templates and non-templates [PR99672]

[Jakub Jelinek via Gcc-patches]

Hi!

The srcloc19.C testcase shows inconsistency in
std::source_location::current() locations between calls from
templates and non-templates.  The location used by __builtin_source_location
comes in both cases from input_location which is set on it by bot_manip
when handling the default argument, called during finish_call_expr.
The problem is that in templates that input_location comes from the
CALL_EXPR we built earlier and that has the combined locus with
range between first character of the function name and closing paren
with caret on the opening paren, so something printed as caret as:
foobar ();
~~~^~
But outside of templates, finish_call_expr is called when input_location
is just the closing paren token, i.e.
foobar ();
^
and only after that returns we create the combined location and set
the CALL_EXPR location to that.  So, it means std::source_location::current()
reports in templates the column of opening (, while outside of templates
closing ).

The following patch makes it consistent by creating the combined location
already before calling finish_call_expr and temporarily overriding
input_location to that.

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

2021-03-23  Jakub Jelinek  

PR c++/99672
* parser.c (cp_parser_postfix_expression): For calls, create
combined_loc and temporarily set input_location to it before
calling finish_call_expr.

* g++.dg/concepts/diagnostic2.C: Adjust expected caret line.
* g++.dg/cpp1y/builtin_location.C (f4, n6): Move #line directives
to match locus changes.
* g++.dg/cpp2a/srcloc1.C: Adjust expected column numbers.
* g++.dg/cpp2a/srcloc2.C: Likewise.
* g++.dg/cpp2a/srcloc15.C: Likewise.
* g++.dg/cpp2a/srcloc16.C: Likewise.
* g++.dg/cpp2a/srcloc19.C: New test.
* g++.dg/modules/adhoc-1_b.C: Adjust expected column numbers
and caret line.
* g++.dg/modules/macloc-1_c.C: Adjust expected column numbers.
* g++.dg/modules/macloc-1_d.C: Likewise.
* g++.dg/plugin/diagnostic-test-expressions-1.C: Adjust expected
caret line.

* testsuite/18_support/source_location/consteval.cc (main): Adjust
expected column numbers.
* testsuite/18_support/source_location/1.cc (main): Likewise.

--- gcc/cp/parser.c.jj  2021-03-19 10:14:37.449724617 +0100
+++ gcc/cp/parser.c 2021-03-19 17:35:11.216322995 +0100
@@ -7564,6 +7564,7 @@ cp_parser_postfix_expression (cp_parser
tsubst_flags_t complain = complain_flags (decltype_p);
vec *args;
location_t close_paren_loc = UNKNOWN_LOCATION;
+   location_t combined_loc = UNKNOWN_LOCATION;
 
 is_member_access = false;
 
@@ -7669,6 +7670,20 @@ cp_parser_postfix_expression (cp_parser
  }
  }
 
+   /* Temporarily set input_location to the combined location
+  with call expression range, as e.g. build_out_target_exprs
+  called from convert_default_arg relies on input_location,
+  so updating it only when the call is fully built results
+  in inconsistencies between location handling in templates
+  and outside of templates.  */
+   if (close_paren_loc != UNKNOWN_LOCATION)
+ combined_loc = make_location (token->location, start_loc,
+   close_paren_loc);
+   auto cleanup
+ = make_temp_override (input_location,
+   combined_loc != UNKNOWN_LOCATION
+   ? combined_loc : input_location);
+
if (TREE_CODE (postfix_expression) == COMPONENT_REF)
  {
tree instance = TREE_OPERAND (postfix_expression, 0);
@@ -7726,12 +7741,7 @@ cp_parser_postfix_expression (cp_parser
complain);
 
if (close_paren_loc != UNKNOWN_LOCATION)
- {
-   location_t combined_loc = make_location (token->location,
-start_loc,
-close_paren_loc);
-   postfix_expression.set_location (combined_loc);
- }
+ postfix_expression.set_location (combined_loc);
 
/* The POSTFIX_EXPRESSION is certainly no longer an id.  */
idk = CP_ID_KIND_NONE;
--- gcc/testsuite/g++.dg/concepts/diagnostic2.C.jj  2020-08-24 
21:41:17.644520408 +0200
+++ gcc/testsuite/g++.dg/concepts/diagnostic2.C 2021-03-22 19:04:59.947515357 
+0100
@@ -25,6 +25,6 @@ baz()
   bar(); // { dg-error "no match" }
 /* { dg-begin-multiline-output "" }
bar();
-^
+   ^~
{ dg-end-multiline-output "" } */
 }
--- gcc/testsuite/g++.dg/cpp1y/builtin_location.C.jj2020-01-14 
20:02:46.771610014 +0100
+++ gcc/testsuite/g++.dg/cpp1y/builtin_location.C   2

Re: [PATCH] x86: Add __volatile__ to __cpuid and __cpuid_count

[Uros Bizjak via Gcc-patches]

On Mon, Mar 22, 2021 at 5:19 AM H.J. Lu  wrote:
>
> Tested on Linux/x86-64 and Linux/i686.  OK for master and release
> branches?
>
> Thanks.
>
> H.J.
> ---
> Since CPUID instruction may return different values on hybrid core.
> volatile is needed on asm statements in .
>
> PR target/99704
> * config/i386/cpuid.h (__cpuid): Add __volatile__.
> (__cpuid_count): Likewise.

OK.

Thanks,
Uros.

> ---
>  gcc/config/i386/cpuid.h | 36 ++--
>  1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/gcc/config/i386/cpuid.h b/gcc/config/i386/cpuid.h
> index 539325d6438..aebc17c6827 100644
> --- a/gcc/config/i386/cpuid.h
> +++ b/gcc/config/i386/cpuid.h
> @@ -212,28 +212,28 @@
>  /* At least one cpu (Winchip 2) does not set %ebx and %ecx
> for cpuid leaf 1. Forcibly zero the two registers before
> calling cpuid as a precaution.  */
> -#define __cpuid(level, a, b, c, d) \
> -  do { \
> -if (__builtin_constant_p (level) && (level) != 1)  \
> -  __asm__ ("cpuid\n\t" \
> - : "=a" (a), "=b" (b), "=c" (c), "=d" (d)  \
> - : "0" (level));   \
> -else   \
> -  __asm__ ("cpuid\n\t" \
> - : "=a" (a), "=b" (b), "=c" (c), "=d" (d)  \
> - : "0" (level), "1" (0), "2" (0)); \
> +#define __cpuid(level, a, b, c, d) \
> +  do { \
> +if (__builtin_constant_p (level) && (level) != 1)  \
> +  __asm__ __volatile__ ("cpuid\n\t"  
>   \
> +   : "=a" (a), "=b" (b), "=c" (c), "=d" (d)\
> +   : "0" (level)); \
> +else   \
> +  __asm__ __volatile__ ("cpuid\n\t"  
>   \
> +   : "=a" (a), "=b" (b), "=c" (c), "=d" (d)\
> +   : "0" (level), "1" (0), "2" (0));   \
>} while (0)
>  #else
> -#define __cpuid(level, a, b, c, d) \
> -  __asm__ ("cpuid\n\t" \
> -  : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \
> -  : "0" (level))
> +#define __cpuid(level, a, b, c, d) \
> +  __asm__ __volatile__ ("cpuid\n\t"\
> +   : "=a" (a), "=b" (b), "=c" (c), "=d" (d)\
> +   : "0" (level))
>  #endif
>
> -#define __cpuid_count(level, count, a, b, c, d)\
> -  __asm__ ("cpuid\n\t" \
> -  : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \
> -  : "0" (level), "2" (count))
> +#define __cpuid_count(level, count, a, b, c, d)  
>   \
> +  __asm__ __volatile__ ("cpuid\n\t"\
> +   : "=a" (a), "=b" (b), "=c" (c), "=d" (d)\
> +   : "0" (level), "2" (count))
>
>
>  /* Return highest supported input value for cpuid instruction.  ext can
> --
> 2.30.2
>

[PATCH] tree-optimization/99721 - avoid SLP nodes we cannot schedule

[Richard Biener]

This makes sure we'll not run into SLP scheduling issues later by
rejecting all-constant children nodes without any scalar stmts early.

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

2021-03-23  Richard Biener  

PR tree-optimization/99721
* tree-vect-slp.c (vect_slp_analyze_node_operations):
Make sure we can schedule the node.

* gfortran.dg/vect/pr99721.f90: New testcase.
---
 gcc/testsuite/gfortran.dg/vect/pr99721.f90 | 11 +++
 gcc/tree-vect-slp.c| 15 ++-
 2 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/vect/pr99721.f90

diff --git a/gcc/testsuite/gfortran.dg/vect/pr99721.f90 
b/gcc/testsuite/gfortran.dg/vect/pr99721.f90
new file mode 100644
index 000..651e86ac3f8
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/vect/pr99721.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! { dg-additional-options "-O3" }
+! { dg-additional-options "-march=armv8.3-a" { target aarch64-*-* } }
+subroutine sub_c
+  complex, dimension(2,3) :: at
+  complex, dimension(2,4) :: b
+  complex, dimension(3,4) :: c
+  data b / (41., 43.), 0, 0, 0, 0, 0, 0, 0/
+  c = matmul(transpose(at), b)
+  if (any (c /= cres)) stop
+end subroutine sub_c
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 0d24be796e8..f1a2b5d60fa 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -3893,7 +3893,7 @@ vect_slp_analyze_node_operations (vec_info *vinfo, 
slp_tree node,
 {
   if (dump_enabled_p ())
dump_printf_loc (MSG_NOTE, vect_location,
-"Failed cyclic SLP reference in %p", node);
+"Failed cyclic SLP reference in %p\n", node);
   return false;
 }
   gcc_assert (SLP_TREE_DEF_TYPE (node) == vect_internal_def);
@@ -3907,6 +3907,7 @@ vect_slp_analyze_node_operations (vec_info *vinfo, 
slp_tree node,
   bool res = true;
   unsigned visited_rec_start = visited_vec.length ();
   unsigned cost_vec_rec_start = cost_vec->length ();
+  bool seen_non_constant_child = false;
   FOR_EACH_VEC_ELT (SLP_TREE_CHILDREN (node), i, child)
 {
   res = vect_slp_analyze_node_operations (vinfo, child, node_instance,
@@ -3914,6 +3915,18 @@ vect_slp_analyze_node_operations (vec_info *vinfo, 
slp_tree node,
  cost_vec);
   if (!res)
break;
+  if (child && SLP_TREE_DEF_TYPE (child) != vect_constant_def)
+   seen_non_constant_child = true;
+}
+  /* We're having difficulties scheduling nodes with just constant
+ operands and no scalar stmts since we then cannot compute a stmt
+ insertion place.  */
+  if (!seen_non_constant_child && SLP_TREE_SCALAR_STMTS (node).is_empty ())
+{
+  if (dump_enabled_p ())
+   dump_printf_loc (MSG_NOTE, vect_location,
+"Cannot vectorize all-constant op node %p\n", node);
+  res = false;
 }
 
   if (res)
-- 
2.26.2

[PATCH] c++: Fix ICE with nsdmi [PR99705]

[Jakub Jelinek via Gcc-patches]

Hi!

When adding P0784R7 constexpr new support, we still didn't have
P1331R2 implemented and so I had to change also build_vec_delete_1
- instead of having uninitialized tbase temporary later initialized
by MODIFY_EXPR I've set the DECL_INITIAL for it - because otherwise
it would be rejected during constexpr evaluation which didn't like
uninitialized vars.  Unfortunately, that change broke the following
testcase.
The problem is that these temporaries (not just tbase but tbase was
the only one with an initializer) are created during NSDMI parsing
and current_function_decl is NULL at that point.  Later when we
clone body of constructors, auto_var_in_fn_p is false for those
(as they have NULL DECL_CONTEXT) and so they aren't duplicated,
and what is worse, the DECL_INITIAL isn't duplicated either nor processed,
and during expansion we ICE because the code from DECL_INITIAL of that
var refers to the abstract constructor's PARM_DECL (this) rather than
the actual constructor's one.

So, either we can just revert those build_vec_delete_1 changes (as done
in the second patch - in attachment), or, as the first patch does, we can
copy the temporaries during bot_manip like we copy the temporaries of
TARGET_EXPRs.  To me that looks like a better fix because e.g. if
break_out_of_target_exprs is called for the same NSDMI multiple times,
sharing the temporaries looks just wrong to me.  If the temporaries
are declared as BIND_EXPR_VARS of some BIND_EXPR (which is the case
of the tbase variable built by build_vec_delete_1 and is the only way
how the DECL_INITIAL can be walked by *walk_tree*), then we need to
copy it also in the BIND_EXPR BIND_EXPR_VARS chain, other temporaries
(those that don't need DECL_INITIAL) often have just DECL_EXPR and no
corresponding BIND_EXPR.
Note, ({ }) are rejected in nsdmis, so all we run into are temporaries
the FE creates artificially.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or do you prefer the patch in attachment (or something else)?

2021-03-23  Jakub Jelinek  

PR c++/99705
* tree.c (bot_manip): Remap artificial automatic temporaries with
NULL DECL_CONTEXT mentioned in DECL_EXPR or in BIND_EXPR_VARS.

* g++.dg/cpp0x/new5.C: New test.

--- gcc/cp/tree.c.jj2021-03-18 09:49:22.112712307 +0100
+++ gcc/cp/tree.c   2021-03-23 00:08:35.901724895 +0100
@@ -3128,6 +3128,35 @@ bot_manip (tree* tp, int* walk_subtrees,
}
   return NULL_TREE;
 }
+  if (TREE_CODE (*tp) == DECL_EXPR
+  && VAR_P (DECL_EXPR_DECL (*tp))
+  && DECL_ARTIFICIAL (DECL_EXPR_DECL (*tp))
+  && !TREE_STATIC (DECL_EXPR_DECL (*tp))
+  && DECL_CONTEXT (DECL_EXPR_DECL (*tp)) == NULL_TREE
+  && !splay_tree_lookup (target_remap,
+(splay_tree_key) DECL_EXPR_DECL (*tp)))
+{
+  tree t = create_temporary_var (TREE_TYPE (DECL_EXPR_DECL (*tp)));
+  splay_tree_insert (target_remap, (splay_tree_key) DECL_EXPR_DECL (*tp),
+(splay_tree_value) t);
+}
+  if (TREE_CODE (*tp) == BIND_EXPR && BIND_EXPR_VARS (*tp))
+{
+  copy_tree_r (tp, walk_subtrees, NULL);
+  for (tree *p = &BIND_EXPR_VARS (*tp); *p; p = &DECL_CHAIN (*p))
+   {
+ gcc_assert (VAR_P (*p) && DECL_ARTIFICIAL (*p) && !TREE_STATIC (*p));
+ tree t = create_temporary_var (TREE_TYPE (*p));
+ DECL_INITIAL (t) = DECL_INITIAL (*p);
+ DECL_CHAIN (t) = DECL_CHAIN (*p);
+ splay_tree_insert (target_remap, (splay_tree_key) *p,
+(splay_tree_value) t);
+ *p = t;
+   }
+  if (data.clear_location && EXPR_HAS_LOCATION (*tp))
+   SET_EXPR_LOCATION (*tp, input_location);
+  return NULL_TREE;
+}
 
   /* Make a copy of this node.  */
   t = copy_tree_r (tp, walk_subtrees, NULL);
--- gcc/testsuite/g++.dg/cpp0x/new5.C.jj2021-03-22 14:08:29.168782588 
+0100
+++ gcc/testsuite/g++.dg/cpp0x/new5.C   2021-03-22 14:07:35.253378808 +0100
@@ -0,0 +1,21 @@
+// PR c++/99705
+// { dg-do compile { target c++11 } }
+
+template 
+struct C
+{
+  C () { f (); }
+  ~C () {}
+  static void f () {}
+};
+
+struct X
+{
+  X ();
+  int n = 10;
+  C *p = new C[n];
+};
+
+X::X ()
+{
+}

Jakub
2021-03-22  Jakub Jelinek  

PR c++/99705
* init.c (build_vec_delete_1): Revert to using a MODIFY_EXPR for tbase
initialization instead of DECL_INITIAL.

* g++.dg/cpp0x/new5.C: New test.

--- gcc/cp/init.c.jj2021-03-22 13:25:30.153349516 +0100
+++ gcc/cp/init.c   2021-03-22 13:35:34.206653080 +0100
@@ -3903,10 +3903,13 @@ build_vec_delete_1 (location_t loc, tree
 fold_convert (sizetype, maxindex));
 
   tbase = create_temporary_var (ptype);
-  DECL_INITIAL (tbase)
+  tbase_init
 = fold_build_pointer_plus_loc (loc, fold_convert (ptype, base),
   virtual_size);
-  tbase_init = build_stmt (loc, DECL_EXPR, tbase);
+  tbase_init = cp_build_modify_expr

[testsuite] Skip couple of Go tests on 32-bit SPARC

[Eric Botcazou]

Since they are already skipped on other 32-bit architectures.

Tested on x86-64/Linux and SPARC/Solaris, OK for the mainline?


2021-03-23  Eric Botcazou  

* go.test/test/fixedbugs/issue6036.go: Skip on sparc.
* go.test/test/fixedbugs/issue22200b.go: Likewise.

-- 
Eric Botcazoudiff --git a/gcc/testsuite/go.test/test/fixedbugs/issue22200b.go b/gcc/testsuite/go.test/test/fixedbugs/issue22200b.go
index ce20923334c..5c2d7ca6ada 100644
--- a/gcc/testsuite/go.test/test/fixedbugs/issue22200b.go
+++ b/gcc/testsuite/go.test/test/fixedbugs/issue22200b.go
@@ -4,7 +4,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
-// +build !386,!amd64p32,!arm,!mips,!mipsle
+// +build !386,!amd64p32,!arm,!mips,!mipsle,!sparc
 
 package p
 
diff --git a/gcc/testsuite/go.test/test/fixedbugs/issue6036.go b/gcc/testsuite/go.test/test/fixedbugs/issue6036.go
index 8ebef5a447c..0bac74d20b3 100644
--- a/gcc/testsuite/go.test/test/fixedbugs/issue6036.go
+++ b/gcc/testsuite/go.test/test/fixedbugs/issue6036.go
@@ -1,4 +1,4 @@
-// +build !386,!arm,!mips,!mipsle,!amd64p32
+// +build !386,!arm,!mips,!mipsle,!amd64p32,!sparc
 // compile
 
 // Copyright 2013 The Go Authors. All rights reserved.

New template for 'gcc' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'gcc' has been made available
to the language teams for translation.  It is archived as:

https://translationproject.org/POT-files/gcc-11.1-b20210321.pot

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.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://gcc.gnu.org/pub/gcc/snapshots/11-20210321/gcc-11-20210321.tar.xz

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

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

[patch] Fix thinko in libcpp preparation patch for modules

[Eric Botcazou]

Hi,

this is a regression present on the mainline, 10 and 9 branches introduced by 
a preparation patch for modules applied to libcpp a while ago by Nathan:

2018-10-31  Nathan Sidwell  

* include/line-map.h (IS_ORDINARY_LOC, IS_MACRO_LOC): New
predicates.
(IS_ADHOC_LOC): Move earlier.
(MAP_ORDINARY_P): Use IS_ORDINARY_LOC.
* line-map.c (linemap_location_from_macro_expansion_p): Use
IS_MACRO_LOC.

The problem is that the new IS_MACRO_LOC macro:

inline bool
IS_MACRO_LOC (location_t loc)
{
  return !IS_ORDINARY_LOC (loc) && !IS_ADHOC_LOC (loc);
}

is not fully correct since the position of the macro lines is not fixed:

/* Returns the lowest location [of a token resulting from macro
   expansion] encoded in this line table.  */
inline location_t
LINEMAPS_MACRO_LOWEST_LOCATION (const line_maps *set)
{
  return LINEMAPS_MACRO_USED (set)
 ? MAP_START_LOCATION (LINEMAPS_LAST_MACRO_MAP (set))
 : MAX_LOCATION_T + 1;
}

In Ada, LINEMAPS_MACRO_USED is false so LINEMAPS_MACRO_LOWEST_LOCATION is 
MAX_LOCATION_T + 1, but IS_MACRO_LOC nevertheless returns true for anything in 
the range [LINE_MAP_MAX_LOCATION; MAX_LOCATION_T], thus yielding an ICE in 
linemap_macro_map_lookup for very large files:

  linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set));

during GIMPLE pass: lower
in linemap_macro_map_lookup, at libcpp/line-map.c:1080during GIMPLE pass: 
lower
in linemap_macro_map_lookup, at libcpp/line-map.c:1080Internal compiler error: 
Error reporting routines re-entered.
0x210b2bf linemap_macro_map_lookup
/home/eric/cvs/gcc/libcpp/line-map.c:1080
0x210b2bf linemap_lookup(line_maps const*, unsigned int)
/home/eric/cvs/gcc/libcpp/line-map.c:1020
0x210b436 linemap_macro_loc_to_exp_point
/home/eric/cvs/gcc/libcpp/line-map.c:1560
0x20e5b55 expand_location_1
/home/eric/cvs/gcc/gcc/input.c:190
0x20e6f90 expand_location(unsigned int)
/home/eric/cvs/gcc/gcc/input.c:809
0xb48119 internal_error_function
/home/eric/cvs/gcc/gcc/ada/gcc-interface/misc.c:339
0x20c5108 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/eric/cvs/gcc/gcc/diagnostic.c:1225
0x20c56ff diagnostic_impl
/home/eric/cvs/gcc/gcc/diagnostic.c:1406
0x20c6087 internal_error(char const*, ...)
/home/eric/cvs/gcc/gcc/diagnostic.c:1808
0xb1d217 fancy_abort(char const*, int, char const*)
/home/eric/cvs/gcc/gcc/diagnostic.c:1907
0x210b2bf linemap_macro_map_lookup
/home/eric/cvs/gcc/libcpp/line-map.c:1080
0x210b2bf linemap_lookup(line_maps const*, unsigned int)
/home/eric/cvs/gcc/libcpp/line-map.c:1020
0x210b436 linemap_macro_loc_to_exp_point
/home/eric/cvs/gcc/libcpp/line-map.c:1560
0x20e5b55 expand_location_1
/home/eric/cvs/gcc/gcc/input.c:190
0x20e6f90 expand_location(unsigned int)
/home/eric/cvs/gcc/gcc/input.c:809
0xb48119 internal_error_function
/home/eric/cvs/gcc/gcc/ada/gcc-interface/misc.c:339
0x20c5108 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/eric/cvs/gcc/gcc/diagnostic.c:1225
0x20c56ff diagnostic_impl
/home/eric/cvs/gcc/gcc/diagnostic.c:1406
0x20c6087 internal_error(char const*, ...)
/home/eric/cvs/gcc/gcc/diagnostic.c:1808
0xb1d217 fancy_abort(char const*, int, char const*)
/home/eric/cvs/gcc/gcc/diagnostic.c:1907
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The attached fix simply deletes IS_MACRO_LOC and replaces it with the proper 
test, taking into account that IS_ADHOC_LOC has always already been tested.

Tested on x86-64/Linux, OK for mainline, 10 and 9 branches?


2021-03-23  Eric Botcazou  

libcpp/
* include/line-map.h (IS_MACRO_LOC): Delete.
* line-map.c (linemap_location_from_macro_expansion_p): Test
against the LINEMAPS_MACRO_LOWEST_LOCATION of the linemap.
gcc/cp/
* module.cc (ordinary_loc_of): Likewise.
(module_state::write_location): Likewise.

-- 
Eric Botcazoudiff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 6dbdc926cb4..f5f48e078ea 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -13774,7 +13774,7 @@ ordinary_loc_of (line_maps *lmaps, location_t from)
 {
   if (IS_ADHOC_LOC (from))
 	from = get_location_from_adhoc_loc (lmaps, from);
-  if (IS_MACRO_LOC (from))
+  if (from >= LINEMAPS_MACRO_LOWEST_LOCATION (lmaps))
 	{
 	  /* Find the ordinary location nearest FROM.  */
 	  const line_map *map = linemap_lookup (lmaps, from);
@@ -15608,7 +15608,7 @@ module_state::write_location (bytes_out &sec, location_t loc)
   write_location (sec, range.m_start);
   write_location (sec, range.m_finish);
 }
-  else if (IS_MACRO_LOC (loc))
+  else if (loc >= LINEMAPS_MACRO_LOWEST_LOCATION (line_table))
 {
   if (const loc_spans::span *span = spans.ma

Re: [PATCH v2] aarch64: Fix SVE ACLE builtins with LTO [PR99216]

[Alex Coplan via Gcc-patches]

On 09/03/2021 15:41, Alex Coplan via Gcc-patches wrote:
> Hi all,
> 
> Here is a v2 patch which provides a more obviously fake answer to
> TARGET_BUILTIN_DECL: this can hopefully go in for GCC 11. For GCC 12, it
> seems that we should consider removing the target hook.
> 
> Original patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566405.html

Ping. OK for trunk?

> 
> ---
> 
> As discussed in the PR, we currently have two different numbering
> schemes for SVE builtins: one for C, and one for C++. This is
> problematic for LTO, where we end up getting confused about which
> intrinsic we're talking about. This patch inserts placeholders into the
> registered_functions vector to ensure that there is a consistent
> numbering scheme for both C and C++.
> 
> This patch uses integer_zero_node as a placeholder node instead of
> building a function decl. This is safe because the node is only returned
> by the TARGET_BUILTIN_DECL hook, which (on AArch64) is only used for
> validation when builtin decls are streamed into lto1.
> 
> Bootstrapped and regtested on aarch64-linux-gnu, OK for trunk?
> 
> Thanks,
> Alex
> 
> gcc/ChangeLog:
> 
>   PR target/99216
>   * config/aarch64/aarch64-sve-builtins.cc
>   (function_builder::add_function): Add placeholder_p argument, use
>   placeholder decls if this is set.
>   (function_builder::add_unique_function): Instead of conditionally adding
>   direct overloads, unconditionally add either a direct overload or a
>   placeholder.
>   (function_builder::add_overloaded_function): Set placeholder_p if we're
>   using C++ overloads. Use the obstack for string storage instead
>   of relying on the tree nodes.
>   (function_builder::add_overloaded_functions): Don't return early for
>   m_direct_overloads: we need to add placeholders.
>   * config/aarch64/aarch64-sve-builtins.h
>   (function_builder::add_function): Add placeholder_p argument.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR target/99216
>   * g++.target/aarch64/sve/pr99216.C: New test.

> diff --git a/gcc/config/aarch64/aarch64-sve-builtins.cc 
> b/gcc/config/aarch64/aarch64-sve-builtins.cc
> index 25612d2ea52..f44f81f1375 100644
> --- a/gcc/config/aarch64/aarch64-sve-builtins.cc
> +++ b/gcc/config/aarch64/aarch64-sve-builtins.cc
> @@ -999,12 +999,29 @@ registered_function &
>  function_builder::add_function (const function_instance &instance,
>   const char *name, tree fntype, tree attrs,
>   uint64_t required_extensions,
> - bool overloaded_p)
> + bool overloaded_p,
> + bool placeholder_p)
>  {
>unsigned int code = vec_safe_length (registered_functions);
>code = (code << AARCH64_BUILTIN_SHIFT) | AARCH64_BUILTIN_SVE;
> -  tree decl = simulate_builtin_function_decl (input_location, name, fntype,
> -   code, NULL, attrs);
> +
> +  /* We need to be able to generate placeholders to enusre that we have a
> + consistent numbering scheme for function codes between the C and C++
> + frontends, so that everything ties up in LTO.
> +
> + Currently, tree-streamer-in.c:unpack_ts_function_decl_value_fields
> + validates that tree nodes returned by TARGET_BUILTIN_DECL are non-NULL 
> and
> + some node other than error_mark_node. This is a holdover from when 
> builtin
> + decls were streamed by code rather than by value.
> +
> + Ultimately, we should be able to remove this validation of BUILT_IN_MD
> + nodes and remove the target hook. For now, however, we need to appease 
> the
> + validation and return a non-NULL, non-error_mark_node node, so we
> + arbitrarily choose integer_zero_node.  */
> +  tree decl = placeholder_p
> +? integer_zero_node
> +: simulate_builtin_function_decl (input_location, name, fntype,
> +   code, NULL, attrs);
>  
>registered_function &rfn = *ggc_alloc  ();
>rfn.instance = instance;
> @@ -1036,7 +1053,7 @@ function_builder::add_unique_function (const 
> function_instance &instance,
>  argument_types.address ());
>tree attrs = get_attributes (instance);
>registered_function &rfn = add_function (instance, name, fntype, attrs,
> -required_extensions, false);
> +required_extensions, false, false);
>  
>/* Enter the function into the hash table.  */
>hashval_t hash = instance.hash ();
> @@ -1047,16 +1064,14 @@ function_builder::add_unique_function (const 
> function_instance &instance,
>  
>/* Also add the function under its overloaded alias, if we want
>   a separate decl for each instance of an overloaded function.  */
> -  if (m_direct_overloads || force_direct_overloads)
> +  char *overload_name = get_name (instance, true);
> 

RE: znver3 tuning part 1

[Kumar, Venkataramanan via Gcc-patches]

[AMD Public Use]

Hi Honza,


> -Original Message-
> From: Jan Hubicka 
> Sent: Monday, March 22, 2021 4:31 PM
> To: Kumar, Venkataramanan 
> Cc: gcc-patches@gcc.gnu.org; mjam...@suse.cz
> Subject: Re: znver3 tuning part 1
> 
> [CAUTION: External Email]
> 
> > > Hi,
> > > I plan to commit some retuning of znver3 codegen that is based on
> > > real hardware benchmarks.  It turns out that there are not too many
> > > changes necessary sinze Zen3 is quite smooth upgrade to Zen2.  In summary:
> > >
> > >  - some instructions (like idiv) have shorter latencies.  Adjusting
> > >costs reduces code size a bit but seems within noise in benchmark
> > >(since our cost calculation is quite off anyway because it does not
> > >account register pressure and parallelism that does make huge
> > >difference here)
> > >  - gather instructions are still microcoded but a lot faster than in
> > >znver1/znver2 and it turns out they are now beneficial for few tsmc
> > >benchmarks, so I plan to enable them.
> >
> > Can we get a copy of this benchmark to try ?
> > we need to check on bigger benchmarks like SPEC also.
> 
> Yes, I am also running specs.  However for basic instruction selection tuning
> smaller benchmarks are doing quite well.  In general if there are relatively
> natural loops where gather helps, i think we should enable it and try to fix
> possible regressions (I did not see one in spec runs, but I plan to do more
> benhcmarking this week).

Okay Thank you.  

> 
> I did some work on TSVC mostly because zen3 seems very smooth update to
> zen2 for instruction selection (which is already happy with almost everything
> especially for scalar code) and vectorizer costs seems to be place where we
> seem to have most room for improvement.
> 
> I briefly analyzed all tsvc kernels where we regress compared to clang, aocc 
> and
> icc.  You can search tsvc in bugzilla. Richard also wrote some observations 
> there.
> These are related to missing features rather than cost model however.
> 
> One problem of tsvc is that it is FP only.  I hacked it for integer but it 
> would be
> nice to have someting else as well.
> >
> > >
> > >It seems we missed revisiting this for znver2 tuning.
> > >I think even for znver2 it may make sense to re-enable them, so I
> > >will benchmark this as well.
> > >  - memcpy/memset expansion seems to work same way as for znver2,
> > >so I am keeping same changes.
> > >  - instruction scheduler is already modified in trunk to some degree
> > >reflecting new units.  Problem with instruction scheduling is that
> > >it treats zen as in-order CPU and is unlikely going to fill all
> > >execution resources this way.
> > >We may want to try to model the out-of-order nature similar way as
> > >LLVM does, but at the other hand the current scheduling logic seems
> > >to do mostly fine (i.e. not worse than llvm's).  What matters is
> > >to schedule for long latencies and just after branch boundaries
> > >where simplified model seems to do just fine.
> >
> > So we can keep the existing model for znver3 for GCC 11 ?
> 
> I think so - I experimented with making the model bit more precise and it does
> not seem to add any performance improvements and makes the automaton a
> lot bigger.  The existing model already handles the updated
> zen3 latencies...
> 
> I think the only possible iprovment here would be to start modelling 
> explicitly the
> out of order nature but even then I am not sure how much benefits that can
> bring (given that we are limited to relatively small basic blocks and do not 
> have a
> lot of information needed to model the execution precisely). Do you have some
> options on this?

Given that basic blocks are small and hardware itself reorders the 
instructions, I don't think precisely modelling the scheduler will give much 
benefit.

> 
> Honza

Regards,
Venkat.

c++: Over-zealous assert [PR 99239]

[Nathan Sidwell]

This was simply	an overzealous assert.	Possibly correct thinking at the 
time that code was written, but not true now.  Of course we can have 
imported artificial decls.


PR c++/99239
gcc/cp/
* decl.c (duplicate_decls): Remove assert about maybe-imported
artificial decls.
gcc/testsuite/
* g++.dg/modules/pr99239_a.H: New.
* g++.dg/modules/pr99239_b.H: New.

--
Nathan Sidwell
diff --git c/gcc/cp/decl.c w/gcc/cp/decl.c
index 8e8f37d060e..289db3074be 100644
--- c/gcc/cp/decl.c
+++ w/gcc/cp/decl.c
@@ -2041,8 +2041,6 @@ duplicate_decls (tree newdecl, tree olddecl, bool hiding, bool was_hidden)
 {
   if (DECL_ARTIFICIAL (olddecl))
 	{
-	  gcc_checking_assert (!(DECL_LANG_SPECIFIC (olddecl)
- && DECL_MODULE_IMPORT_P (olddecl)));
 	  if (!(global_purview_p () || not_module_p ()))
 	error ("declaration %qD conflicts with builtin", newdecl);
 	  else
diff --git c/gcc/testsuite/g++.dg/modules/pr99239_a.H w/gcc/testsuite/g++.dg/modules/pr99239_a.H
new file mode 100644
index 000..35f006fe9b2
--- /dev/null
+++ w/gcc/testsuite/g++.dg/modules/pr99239_a.H
@@ -0,0 +1,13 @@
+// PR 99239 ICE on catch clause
+// { dg-additional-options -fmodule-header }
+// { dg-module-cmi {} }
+
+inline void Foo ()
+{
+  try
+{}
+  catch(...)
+{
+}
+}
+
diff --git c/gcc/testsuite/g++.dg/modules/pr99239_b.H w/gcc/testsuite/g++.dg/modules/pr99239_b.H
new file mode 100644
index 000..92638d663c7
--- /dev/null
+++ w/gcc/testsuite/g++.dg/modules/pr99239_b.H
@@ -0,0 +1,12 @@
+// { dg-additional-options {-fmodule-header -fno-module-lazy} }
+// { dg-module-cmi {} }
+import  "pr99239_a.H";
+   
+inline void
+  _M_remove_reference() throw()
+{
+  try
+{ }
+  catch(...)
+{ }
+}

Re: [PATCH v3] fwprop: Fix single_use_p calculation

[Richard Sandiford via Gcc-patches]

Ilya Leoshkevich  writes:
> +inline use_info *
> +set_info::single_nondebug_use () const
> +{
> +  use_info *nondebug_insn = single_nondebug_insn_use ();
> +  if (nondebug_insn)
> +return has_phi_uses () ? nullptr : nondebug_insn;
> +  use_info *phi = single_phi_use ();
> +  if (phi)
> +return has_nondebug_insn_uses() ? nullptr : phi;
> +  return nullptr;

Very minor, but I think this is simpler as:

  if (!has_phi_uses ())
return single_nondebug_insn_use ();
  if (!has_nondebug_insn_uses ())
return single_phi_use ();
  return nullptr;

OK with that change (or without if you prefer the original).
Thanks for the fix and for your patience. :-)

Richard

Re: [PATCH] c++: Fix bogus warning in deprecated namespace [PR99318]

[Jason Merrill via Gcc-patches]

On 3/9/21 10:22 PM, Marek Polacek wrote:

In GCC 10, I introduced cp_warn_deprecated_use_scopes so that we can
handle attribute deprecated on a namespace declaration.  This
function walks the decl's contexts so that we warn for code like

   namespace [[deprecated]] N { struct S { }; }
   N::S s;

We call cp_warn_deprecated_use_scopes when we encounter a TYPE_DECL.


Hmm, I'd think we should warn about N as a consequence of seeing N::, 
not because we are using S.  For instance, in


namespace [[deprecated]] N { struct S { }; }
using namespace N;
S s;

we should warn about the using-directive, but not also the declaration 
of 's'.


But the patch is OK, that's just a possible future direction.


But in the following testcase we have a TYPE_DECL whose context is
a deprecated function; that itself is not a reason to warn.  This
patch limits for which entities we call cp_warn_deprecated_use;
essentially it's what can follow ::.

I noticed that we didn't test that

   struct [[deprecated]] S { static void fn(); };
   S::fn();

produces the expected warning, so I've added gen-attrs-73.C.

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

gcc/cp/ChangeLog:

PR c++/99318
* decl2.c (cp_warn_deprecated_use_scopes): Only call
cp_warn_deprecated_use when decl is a namespace, class, or enum.

gcc/testsuite/ChangeLog:

PR c++/99318
* g++.dg/cpp0x/attributes-namespace6.C: New test.
* g++.dg/cpp0x/gen-attrs-73.C: New test.
---
  gcc/cp/decl2.c|  3 ++-
  .../g++.dg/cpp0x/attributes-namespace6.C  | 21 +++
  gcc/testsuite/g++.dg/cpp0x/gen-attrs-73.C | 20 ++
  3 files changed, 43 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/attributes-namespace6.C
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/gen-attrs-73.C

diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index c46100de89a..ef79f6cc6d1 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -5529,7 +5529,8 @@ cp_warn_deprecated_use_scopes (tree scope)
 && scope != error_mark_node
 && scope != global_namespace)
  {
-  if (cp_warn_deprecated_use (scope))
+  if ((TREE_CODE (scope) == NAMESPACE_DECL || OVERLOAD_TYPE_P (scope))
+ && cp_warn_deprecated_use (scope))
return;
if (TYPE_P (scope))
scope = CP_TYPE_CONTEXT (scope);
diff --git a/gcc/testsuite/g++.dg/cpp0x/attributes-namespace6.C 
b/gcc/testsuite/g++.dg/cpp0x/attributes-namespace6.C
new file mode 100644
index 000..2fbc8e1158f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/attributes-namespace6.C
@@ -0,0 +1,21 @@
+// PR c++/99318
+// { dg-do compile { target c++11 } }
+
+template 
+struct S {
+[[deprecated("foo")]] unsigned m_fn (char const chr)
+{
+using index_t = unsigned;
+return T::arr[static_cast(chr)]; // { dg-bogus "deprecated" }
+}
+};
+
+extern unsigned int arr[];
+
+struct R {
+[[deprecated("foo")]] unsigned m_fn (char const chr)
+{
+using index_t = unsigned;
+return arr[static_cast(chr)]; // { dg-bogus "deprecated" }
+}
+};
diff --git a/gcc/testsuite/g++.dg/cpp0x/gen-attrs-73.C 
b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-73.C
new file mode 100644
index 000..75f4077af7b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-73.C
@@ -0,0 +1,20 @@
+// { dg-do compile { target c++11 } }
+// Test attribute deprecated on :: with class, enum, and namespace.
+
+struct [[deprecated]] S { static void fn(); static const int s = 0; };
+union [[deprecated]] U { static void fn(); static const int u = 0; };
+enum [[deprecated]] E { X };
+enum class [[deprecated]] SE { Y };
+namespace [[deprecated]] N { struct S { }; }
+
+void
+g ()
+{
+  S::fn(); // { dg-warning "deprecated" }
+  (void) S::s; // { dg-warning "deprecated" }
+  U::fn(); // { dg-warning "deprecated" }
+  (void) U::u; // { dg-warning "deprecated" }
+  (void) E::X; // { dg-warning "deprecated" }
+  (void) SE::Y; // { dg-warning "deprecated" }
+  N::S s; // { dg-warning "deprecated" }
+}

base-commit: 63d74fed4566f1de583c368ecb9e2fc423fb1c87

Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64

[Christophe Lyon via Gcc-patches]

On Mon, 22 Mar 2021 at 18:38, Vladimir Makarov via Gcc-patches
 wrote:
>
>
> On 2021-03-21 8:51 a.m., Richard Sandiford wrote:
> > Vladimir Makarov  writes:
> >> On 2021-03-19 11:42 a.m., Richard Sandiford wrote:
> >>> Vladimir Makarov via Gcc-patches  writes:
>  The following patch solves P1 PR99581
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
> 
>  The patch was successfully tested and bootstrapped on x86-64, ppc64le,
>  aarch64.
> 
>  Is it ok for the trunk?
> >>> I'm not trying to reject the patch as such.  I just think we need to
> >>> have a clearer picture first.
> >>>
> >> I agree that 'o' should be treated as a subset of 'm' and therefore its
> >> definition should have a check as 'm' has.  Still my patch is not about
> >> treatment of constraint 'o' only.
> >>
> >> My approach for LRA development is minimal changes, as radical changes
> >> (even if they look right) results long lasting unpredictable effects on
> >> many targets.
> >>
> >> The patch in which you introduced a new function valid_address_p and new
> >> treatment of **all** memory constraints was too big change with this
> >> point of view and finally it resulted in this problem after recent
> >> partially fixing mess in process_address_1.
> >>
> >> My patch fixes this radical change. So I think we still need the patch
> >> I've submitted.
> > OK, fair enough.  I have some minor cosmetic comments below, but
> > otherwise the patch is OK for trunk and branch.
> >
> Richard, thank you for your review and approval.  I incorporated all
> your proposals into the patch and committed it into the trunk.  The
> final patch is in the attachment.
>

Hi,

This patch causes regressions (116) on aarch64:
gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp
gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
check-function-bodies ld1ro_bf16_112
gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
check-function-bodies ld1ro_bf16_16
gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
check-function-bodies ld1ro_bf16_index
gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
check-function-bodies ld1ro_bf16_m128
gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
check-function-bodies ld1ro_bf16_m16
[]

Not sure why you didn't see them during your testing?

Can you check?

Thanks

[committed] aarch64: Make aarch64_add_offset work with -ftrapv [PR99540]

[Richard Sandiford via Gcc-patches]

aarch64_add_offset uses expand_mult to multiply the SVE VL by an
out-of-range constant.  expand_mult takes an argument to indicate
whether the multiplication is signed or unsigned, but in this
context the multiplication is effectively signless and so the
choice seemed arbitrary.

However, one of the things that the signedness input does is
indicate whether signed overflow should be trapped for -ftrapv.
We don't want that here, so we must treat the multiplication
as unsigned.

Tested on aarch64-linux-gnu (with and without SVE).  Pushed to
trunk so far.  Will backport to GCC 10 tomorrow.

Richard


gcc/
2021-03-23  Jakub Jelinek  

PR target/99540
* config/aarch64/aarch64.c (aarch64_add_offset): Tell
expand_mult to perform an unsigned rather than a signed
multiplication.

gcc/testsuite/
2021-03-23  Richard Sandiford  

PR target/99540
* gcc.dg/vect/pr99540.c: New test.
---
 gcc/config/aarch64/aarch64.c|  2 +-
 gcc/testsuite/gcc.dg/vect/pr99540.c | 20 
 2 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr99540.c

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index db69e6983d0..c8a87fe858a 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -4639,7 +4639,7 @@ aarch64_add_offset (scalar_int_mode mode, rtx dest, rtx 
src,
  if (can_create_pseudo_p ())
{
  rtx coeff1 = gen_int_mode (factor, mode);
- val = expand_mult (mode, val, coeff1, NULL_RTX, false, true);
+ val = expand_mult (mode, val, coeff1, NULL_RTX, true, true);
}
  else
{
diff --git a/gcc/testsuite/gcc.dg/vect/pr99540.c 
b/gcc/testsuite/gcc.dg/vect/pr99540.c
new file mode 100644
index 000..9136b099d94
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr99540.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-ftrapv -ffloat-store -march=armv8.2-a+sve" { 
target aarch64*-*-* } } */
+
+float *MSalign2m2m_rec_initverticalw, *MSalign2m2m_rec_currentw;
+
+void
+match_ribosum (int MSalign2m2m_rec_i, int MSalign2m2m_rec_lgth1,
+   int MSalign2m2m_rec_lgth2)
+{
+  float **WMMTX;
+
+  while (MSalign2m2m_rec_i < 1)
+WMMTX[MSalign2m2m_rec_i++][0] = MSalign2m2m_rec_initverticalw[0];
+
+  while (MSalign2m2m_rec_i < MSalign2m2m_rec_lgth1)
+MSalign2m2m_rec_initverticalw[MSalign2m2m_rec_i++] += 0.1;
+
+  while (MSalign2m2m_rec_i < MSalign2m2m_rec_lgth2)
+MSalign2m2m_rec_currentw[MSalign2m2m_rec_i++] += 0.1;
+}

[wwwdocs] aarch64: Record RNG intrinsics bug fix in 10.3 changes.htm

[Kyrylo Tkachov via Gcc-patches]

Hi all,

I'd like to record the fix for the RNG intrinsics fix in the 10.3 release notes.
The GCC 10 branch is the only released branch that was affected by the bug.

Pushing to wwwdocs.
Thanks,
Kyrill


wwwdocs-rng.patch
Description: wwwdocs-rng.patch

RE: [wwwdocs] arm,aarc64: add initial gcc-11/changes.html entries

[Kyrylo Tkachov via Gcc-patches]

Hi Gerald,

> -Original Message-
> From: Gerald Pfeifer 
> Sent: 20 March 2021 16:31
> To: Kyrylo Tkachov 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [wwwdocs] arm,aarc64: add initial gcc-11/changes.html entries
> 
> Hi Kyrylo,
> 
> On Tue, 26 Jan 2021, Kyrylo Tkachov via Gcc-patches wrote:
> > This patch adds the arm and aarch64 sections changes.html for GCC 11.
> 
> this is nice!
> 
> One question: why GCC 11.0 in the following? The first release is going
> to be GCC 11.1, and we general refer to major releases - could we say
> "GCC 11" instead? Or do you want to use GCC 11.1?
> 

Indeed, I meant to use GCC 11.
Fixed with the attached (pushed) patch.
Thanks,
Kyrill

> +  The availability of Advanced SIMD intrinsics available through the
> +  arm_neon.h header is improved and GCC 11.0 supports the
> full
> +  set of intrinsics defined by ACLE Q3 2020.
> 
> 
> > There's more than that that went into the release, but this can serve as
> > a starting point for filling the sections in.
> 
> Looking forward to more! :)
> 
> Gerald


wwwdocs-gcc-11.patch
Description: wwwdocs-gcc-11.patch

[PATCH 0/8] testsuite/arm: Various cleanups

[Christophe Lyon via Gcc-patches]

Several arm tests fail in various testing configurations due to
incomplete or incorrect effective-target or
dg-options/dg-additional-options settings.

This series improves this, to avoid repeated reports with lots of
useless errors. Hopefully this will help focus on real compiler bugs.

There's still the concern of the complexity of effective-target
settings on arm, these patches do not try to address that.

OK for stage4?

Thanks,

Christophe

Christophe Lyon (8):
  testsuite/arm: Add arm_v8_2a_fp16_neon and arm_v8_2a_bf16_neon options
  testsuite/arm: Add arm_v8_2a_i8mm options in
gcc.target/arm/simd/vmmla_1.c
  testsuite/arm: Remove useless -mfloat-abi option
  testsuite/arm: Add arm_softfp_ok or arm_hard_ok as needed.
  testsuite/arm: Add arm_hard_ok check in armv8_2-fp16-scalar-2.c
  testsuite/arm: Fix -mfloat-abi order in arm_v8_2a_bf16_neon_ok_nocache
and arm_v8_2a_i8mm_ok_nocache
  testsuite/arm: Fix -mfloat-abi order in arm_v8_1m_mve_ok_nocache and
arm_v8_1m_mve_fp_ok_nocache
  testsuite/arm: Add arm_dsp_ok effective target and use it in
arm/acle/dsp_arith.c

 gcc/doc/sourcebuild.texi   | 11 +
 gcc/testsuite/gcc.target/arm/acle/dsp_arith.c  |  4 +-
 .../gcc.target/arm/armv8_1m-fp16-move-1.c  |  3 +-
 .../gcc.target/arm/armv8_1m-fp32-move-1.c  |  3 +-
 .../gcc.target/arm/armv8_1m-fp64-move-1.c  |  3 +-
 .../gcc.target/arm/armv8_1m-shift-imm-1.c  |  2 +-
 .../gcc.target/arm/armv8_1m-shift-reg-1.c  |  2 +-
 .../gcc.target/arm/armv8_2-fp16-scalar-2.c |  2 +
 gcc/testsuite/gcc.target/arm/bf16_dup.c|  2 +-
 gcc/testsuite/gcc.target/arm/bf16_reinterpret.c|  2 +-
 gcc/testsuite/gcc.target/arm/bfloat16_scalar_1_1.c |  3 +-
 .../gcc.target/arm/bfloat16_scalar_typecheck.c |  2 +
 gcc/testsuite/gcc.target/arm/bfloat16_simd_1_1.c   |  3 +-
 gcc/testsuite/gcc.target/arm/bfloat16_simd_1_2.c   |  1 +
 gcc/testsuite/gcc.target/arm/bfloat16_simd_2_1.c   |  1 +
 gcc/testsuite/gcc.target/arm/bfloat16_simd_2_2.c   |  1 +
 gcc/testsuite/gcc.target/arm/bfloat16_simd_3_1.c   |  1 +
 gcc/testsuite/gcc.target/arm/bfloat16_simd_3_2.c   |  1 +
 .../gcc.target/arm/bfloat16_vector_typecheck_1.c   |  2 +
 .../gcc.target/arm/bfloat16_vector_typecheck_2.c   |  6 ++-
 .../arm/mve/intrinsics/mve_vector_float2.c |  2 +
 .../gcc.target/arm/mve/intrinsics/mve_vector_int.c |  2 +
 .../arm/mve/intrinsics/mve_vector_uint.c   |  2 +
 .../arm/mve/intrinsics/mve_vector_uint1.c  |  2 +
 .../arm/mve/intrinsics/mve_vector_uint2.c  |  2 +
 .../gcc.target/arm/mve/intrinsics/vgetq_lane_s64.c |  3 +-
 .../gcc.target/arm/mve/intrinsics/vgetq_lane_u64.c |  3 +-
 .../gcc.target/arm/mve/intrinsics/vsetq_lane_s64.c |  3 +-
 .../gcc.target/arm/mve/intrinsics/vsetq_lane_u64.c |  3 +-
 gcc/testsuite/gcc.target/arm/pr51534.c |  2 +-
 gcc/testsuite/gcc.target/arm/pr51968.c |  3 +-
 gcc/testsuite/gcc.target/arm/simd/bf16_ma_1.c  |  3 +-
 gcc/testsuite/gcc.target/arm/simd/bf16_mmla_1.c|  3 +-
 gcc/testsuite/gcc.target/arm/simd/bf16_vldn_1.c|  1 +
 gcc/testsuite/gcc.target/arm/simd/bf16_vstn_1.c|  1 +
 gcc/testsuite/gcc.target/arm/simd/vdot-2-1.c   |  3 +-
 gcc/testsuite/gcc.target/arm/simd/vdot-2-2.c   |  3 +-
 gcc/testsuite/gcc.target/arm/simd/vmmla_1.c|  3 +-
 gcc/testsuite/lib/target-supports.exp  | 48 --
 39 files changed, 119 insertions(+), 28 deletions(-)

-- 
2.7.4

[PATCH 1/8] testsuite/arm: Add arm_v8_2a_fp16_neon and arm_v8_2a_bf16_neon options

[Christophe Lyon via Gcc-patches]

A few tests lack the dg-add-options directives associated with the
dg-require-effective-target they are using. Adding them enables to
pass the right float-abi option, and thus make the tests pass instead
of emit an error.

For instance, we now pass -mfloat-abi=softfp on arm-linux-gnueabi
targets and the tests pass.

2021-03-19  Christophe Lyon  

gcc/testsuite/
* gcc.target/arm/bfloat16_scalar_typecheck.c: Add
arm_v8_2a_fp16_neon and arm_v8_2a_bf16_neon.
* gcc.target/arm/bfloat16_vector_typecheck_1.c: Likewise.
* gcc.target/arm/bfloat16_vector_typecheck_2.c: Likewise.
---
 gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c   | 2 ++
 gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c | 2 ++
 gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c | 6 --
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c 
b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
index 672641e..8c80c55 100644
--- a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
+++ b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
@@ -2,6 +2,8 @@
 /* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } } */
 /* { dg-require-effective-target arm_v8_2a_fp16_neon_ok } */
 /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
+/* { dg-add-options arm_v8_2a_fp16_neon } */
+/* { dg-add-options arm_v8_2a_bf16_neon } */
 /* { dg-additional-options "-march=armv8.6-a+bf16+fp16 -Wno-pedantic -O3 
--save-temps" }  */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c 
b/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c
index ba39cb6..f3c350b 100644
--- a/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c
+++ b/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c
@@ -2,6 +2,8 @@
 /* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } } */
 /* { dg-require-effective-target arm_v8_2a_fp16_neon_ok } */
 /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
+/* { dg-add-options arm_v8_2a_fp16_neon } */
+/* { dg-add-options arm_v8_2a_bf16_neon } */
 /* { dg-additional-options "-march=armv8.6-a+bf16+fp16 -Wno-pedantic -O3 
--save-temps" }  */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c 
b/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c
index 16669dc..de0ade5 100644
--- a/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c
+++ b/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c
@@ -2,6 +2,8 @@
 /* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } } */
 /* { dg-require-effective-target arm_v8_2a_fp16_neon_ok } */
 /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
+/* { dg-add-options arm_v8_2a_fp16_neon } */
+/* { dg-add-options arm_v8_2a_bf16_neon } */
 /* { dg-additional-options "-march=armv8.6-a+bf16+fp16 -Wno-pedantic -O3 
--save-temps" }  */
 
 #include 
@@ -25,8 +27,8 @@ float is_a_float16;
 double is_a_double;
 
 bfloat16x8_t foo3 (void) { return (bfloat16x8_t) 
0x12345678123456781234567812345678; }
- /* { dg-error {integer constant is too large for its type} "" {target *-*-*} 
27 } */
- /* { dg-error {cannot convert a value of type 'long long int' to vector type 
'__simd128_bfloat16_t' which has different size} "" {target *-*-*} 27 } */
+ /* { dg-error {integer constant is too large for its type} "" {target *-*-*} 
.-1 } */
+ /* { dg-error {cannot convert a value of type 'long long int' to vector type 
'__simd128_bfloat16_t' which has different size} "" {target *-*-*} .-2 } */
 
 bfloat16x8_t footest (bfloat16x8_t vector0)
 {
-- 
2.7.4

[PATCH 2/8] testsuite/arm: Add arm_v8_2a_i8mm options in gcc.target/arm/simd/vmmla_1.c

[Christophe Lyon via Gcc-patches]

We need to add the options corresponding to the arm_v8_2a_i8mm_ok
effective target in order to use the right float-abi option:
-mfloat-abi=softfp makes the test pass for arm-linux-gnueabi,
while no -mfloat-abi option is needed for arm-linux-gnueabihf.

2021-03-19  Christophe Lyon  

gcc/testsuite/
* gcc.target/arm/simd/vmmla_1.c: Add arm_v8_2a_i8mm options.
---
 gcc/testsuite/gcc.target/arm/simd/vmmla_1.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/arm/simd/vmmla_1.c 
b/gcc/testsuite/gcc.target/arm/simd/vmmla_1.c
index d33ebf3..a88c4ea 100644
--- a/gcc/testsuite/gcc.target/arm/simd/vmmla_1.c
+++ b/gcc/testsuite/gcc.target/arm/simd/vmmla_1.c
@@ -1,6 +1,7 @@
 /* { dg-do assemble } */
 /* { dg-require-effective-target arm_v8_2a_i8mm_ok } */
-/* { dg-options "-save-temps -O2 -march=armv8.2-a+i8mm -mfpu=auto 
-mfloat-abi=hard" } */
+/* { dg-options "-save-temps -O2 -mfpu=auto" } */
+/* { dg-add-options arm_v8_2a_i8mm } */
 
 #include "arm_neon.h"
 
-- 
2.7.4

[PATCH 3/8] testsuite/arm: Remove useless -mfloat-abi option

[Christophe Lyon via Gcc-patches]

These tests pass with their current dg-add-options, no need to force
-mfloat=abi.

I've noticed no impact on armv8_1m-shift-imm-1.c and
armv8_1m-shift-reg-1.c, bf16_reinterpret.c now passes on
arm-linux-gnueabi and bf16_dup.c now passes on arm-linux-gnueabihf.

This allows pr51534.c to pass when forcing -mfloat-abi=soft in
runtestflags, otherwise we get an error '-mfloat-abi=soft and
-mfloat-abi=hard may not be used together' because we try to compile
with both flags.

2021-03-19  Christophe Lyon  

gcc/testsuite/
* gcc.target/arm/armv8_1m-shift-imm-1.c: Remove -mfloat=abi option.
* gcc.target/arm/armv8_1m-shift-reg-1.c: Likewise.
* gcc.target/arm/bf16_dup.c: Likewise.
* gcc.target/arm/bf16_reinterpret.c: Likewise.
* gcc.target/arm/pr51534.c: Remove -mfloat=abi option.
---
 gcc/testsuite/gcc.target/arm/armv8_1m-shift-imm-1.c | 2 +-
 gcc/testsuite/gcc.target/arm/armv8_1m-shift-reg-1.c | 2 +-
 gcc/testsuite/gcc.target/arm/bf16_dup.c | 2 +-
 gcc/testsuite/gcc.target/arm/bf16_reinterpret.c | 2 +-
 gcc/testsuite/gcc.target/arm/pr51534.c  | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/armv8_1m-shift-imm-1.c 
b/gcc/testsuite/gcc.target/arm/armv8_1m-shift-imm-1.c
index 883fbb09..84f13e2 100644
--- a/gcc/testsuite/gcc.target/arm/armv8_1m-shift-imm-1.c
+++ b/gcc/testsuite/gcc.target/arm/armv8_1m-shift-imm-1.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -mfloat-abi=softfp -mlittle-endian" } */
 /* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-options "-O2 -mlittle-endian" } */
 /* { dg-add-options arm_v8_1m_mve } */
 
 long long longval1;
diff --git a/gcc/testsuite/gcc.target/arm/armv8_1m-shift-reg-1.c 
b/gcc/testsuite/gcc.target/arm/armv8_1m-shift-reg-1.c
index e125ff8..8668b6b 100644
--- a/gcc/testsuite/gcc.target/arm/armv8_1m-shift-reg-1.c
+++ b/gcc/testsuite/gcc.target/arm/armv8_1m-shift-reg-1.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -mfloat-abi=softfp -mlittle-endian" } */
 /* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-options "-O2 -mlittle-endian" } */
 /* { dg-add-options arm_v8_1m_mve } */
 
 long long longval2;
diff --git a/gcc/testsuite/gcc.target/arm/bf16_dup.c 
b/gcc/testsuite/gcc.target/arm/bf16_dup.c
index 94be99a..b62bce1 100644
--- a/gcc/testsuite/gcc.target/arm/bf16_dup.c
+++ b/gcc/testsuite/gcc.target/arm/bf16_dup.c
@@ -1,7 +1,7 @@
 /* { dg-do assemble { target { arm*-*-* } } } */
 /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
 /* { dg-add-options arm_v8_2a_bf16_neon }  */
-/* { dg-additional-options "-save-temps -march=armv8.2-a+bf16+fp16 
-mfloat-abi=softfp" } */
+/* { dg-additional-options "-save-temps -march=armv8.2-a+bf16+fp16" } */
 
 #include "arm_neon.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/bf16_reinterpret.c 
b/gcc/testsuite/gcc.target/arm/bf16_reinterpret.c
index e7d30a9..9e36fc5 100644
--- a/gcc/testsuite/gcc.target/arm/bf16_reinterpret.c
+++ b/gcc/testsuite/gcc.target/arm/bf16_reinterpret.c
@@ -1,7 +1,7 @@
 /* { dg-do assemble { target { arm*-*-* } } } */
 /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
 /* { dg-add-options arm_v8_2a_bf16_neon }  */
-/* { dg-additional-options "-save-temps -march=armv8.2-a+fp16+bf16 
-mfloat-abi=hard -mfpu=crypto-neon-fp-armv8" } */
+/* { dg-additional-options "-save-temps -march=armv8.2-a+fp16+bf16 
-mfpu=crypto-neon-fp-armv8" } */
 
 #include 
 
diff --git a/gcc/testsuite/gcc.target/arm/pr51534.c 
b/gcc/testsuite/gcc.target/arm/pr51534.c
index f675a44..3711b45 100644
--- a/gcc/testsuite/gcc.target/arm/pr51534.c
+++ b/gcc/testsuite/gcc.target/arm/pr51534.c
@@ -3,7 +3,7 @@
 
 /* { dg-do assemble } */
 /* { dg-require-effective-target arm_neon_ok } */
-/* { dg-options "-save-temps -mfloat-abi=hard -O3" } */
+/* { dg-options "-save-temps -O3" } */
 /* { dg-add-options arm_neon } */
 
 #include 
-- 
2.7.4

[PATCH 4/8] testsuite/arm: Add arm_softfp_ok or arm_hard_ok as needed.

[Christophe Lyon via Gcc-patches]

Several tests override the -mfloat-abi option detected by their
effective targets. Make sure it is supported, so that these tests are
unsupported rather than failures (the inclusion of arm_neon.h
otherwise fails for lack of gnu/stubs-*.h)

This avoids failures with
bfloat16_simd_2_1.c
bfloat16_simd_3_1.c
bf16_vldn_1.c
bf16_vstn_1.c on arm-linux-gnueabi
and
pr51968.c
bfloat16_simd_1_2.c
bfloat16_simd_2_2.c
bfloat16_simd_3_2.c on arm-linux-gnueabihf.

On arm-eabi with default cpu/fpu/mode and a+rm multilibs,
bfloat16_simd_2_1.c, bfloat16_simd_3_1.c, bf16_vstn_1.c and
bf16_vldn_1.c become unsupported instead of pass because arm_hard_ok
fails with "selected processor lacks an FPU". Since we also override
the fpu in dg-additional-options, we'd need another effective target
(say arm_hard_neon_ok) that would check -mfloat-abi=hard -mfpu=neon at
the same time. But we have already so many arm effective targets, it
doesn't seem like a good way forward.

2021-03-19  Christophe Lyon  

gcc/testsuite/
* gcc.target/arm/bfloat16_simd_1_2.c: Add arm_softfp_ok.
* gcc.target/arm/bfloat16_simd_2_2.c: Likewise.
* gcc.target/arm/bfloat16_simd_3_2.c: Likewise.
* gcc.target/arm/pr51968.c: Likewise.
* gcc.target/arm/bfloat16_simd_2_1.c: arm_hard_ok.
* gcc.target/arm/bfloat16_simd_3_1.c: Likewise.
* gcc.target/arm/simd/bf16_vldn_1.c: Likewise.
* gcc.target/arm/simd/bf16_vstn_1.c: Likewise.
---
 gcc/testsuite/gcc.target/arm/bfloat16_simd_1_2.c | 1 +
 gcc/testsuite/gcc.target/arm/bfloat16_simd_2_1.c | 1 +
 gcc/testsuite/gcc.target/arm/bfloat16_simd_2_2.c | 1 +
 gcc/testsuite/gcc.target/arm/bfloat16_simd_3_1.c | 1 +
 gcc/testsuite/gcc.target/arm/bfloat16_simd_3_2.c | 1 +
 gcc/testsuite/gcc.target/arm/pr51968.c   | 3 ++-
 gcc/testsuite/gcc.target/arm/simd/bf16_vldn_1.c  | 1 +
 gcc/testsuite/gcc.target/arm/simd/bf16_vstn_1.c  | 1 +
 8 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_2.c 
b/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_2.c
index 4ffcc54..95eecec 100644
--- a/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_2.c
+++ b/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_2.c
@@ -1,4 +1,5 @@
 /* { dg-do assemble { target { arm*-*-* } } } */
+/* { dg-require-effective-target arm_softfp_ok } */
 /* { dg-require-effective-target arm_v8_neon_ok } */
 /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
 /* { dg-additional-options "-march=armv8.2-a+bf16 -mfloat-abi=softfp 
-mfpu=auto" } */
diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_1.c 
b/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_1.c
index 05ee4d8..02b4c41 100644
--- a/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_1.c
+++ b/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_1.c
@@ -1,4 +1,5 @@
 /* { dg-do assemble { target { arm*-*-* } } } */
+/* { dg-require-effective-target arm_hard_ok } */
 /* { dg-require-effective-target arm_v8_neon_ok } */
 /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
 /* { dg-additional-options "-march=armv8.2-a -mfloat-abi=hard 
-mfpu=neon-fp-armv8" } */
diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_2.c 
b/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_2.c
index 15fba31..175bfa5 100644
--- a/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_2.c
+++ b/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_2.c
@@ -1,4 +1,5 @@
 /* { dg-do assemble { target { arm*-*-* } } } */
+/* { dg-require-effective-target arm_softfp_ok } */
 /* { dg-require-effective-target arm_v8_neon_ok } */
 /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
 /* { dg-additional-options "-march=armv8.2-a -mfloat-abi=softfp 
-mfpu=neon-fp-armv8" } */
diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_1.c 
b/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_1.c
index b9b7606..d2326c2 100644
--- a/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_1.c
+++ b/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_1.c
@@ -1,4 +1,5 @@
 /* { dg-do assemble { target { arm*-*-* } } } */
+/* { dg-require-effective-target arm_hard_ok } */
 /* { dg-require-effective-target arm_v8_neon_ok } */
 /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
 /* { dg-additional-options "-march=armv8.2-a -mfloat-abi=hard 
-mfpu=neon-fp-armv8" } */
diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_2.c 
b/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_2.c
index ab1fe10..346253b 100644
--- a/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_2.c
+++ b/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_2.c
@@ -1,4 +1,5 @@
 /* { dg-do assemble { target { arm*-*-* } } } */
+/* { dg-require-effective-target arm_softfp_ok } */
 /* { dg-require-effective-target arm_v8_neon_ok } */
 /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
 /* { dg-additional-options "-march=armv8.2-a -mfloat-abi=softfp 
-mfpu=neon-fp-armv8" } */
diff --git a/gcc/testsuite/gcc.target/arm/pr51968.c 
b/gcc/testsuite/gcc.target/arm/pr51968.c
index 7814702..c06da48 100644
--- a/gcc/testsuit

[PATCH 5/8] testsuite/arm: Add arm_hard_ok check in armv8_2-fp16-scalar-2.c

[Christophe Lyon via Gcc-patches]

This test relies on -mfloat-abi=hard to pass (otherwise
test_mov_imm_[12] directly build the 1.0 fp16 representation via movw
r0, #15360 rather than using vmov.f16 s0, #1.0e+0 as expected by
scan-assembler-times)

Adding the arm_hard_ok check makes the test unsupported eg. on
arm-linux-gnueabi instead of reporting a failure.

2021-03-20  Christophe Lyon  

gcc/testsuite/
* gcc.target/arm/armv8_2-fp16-scalar-2.c: Add arm_hard_ok.
---
 gcc/testsuite/gcc.target/arm/armv8_2-fp16-scalar-2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/testsuite/gcc.target/arm/armv8_2-fp16-scalar-2.c 
b/gcc/testsuite/gcc.target/arm/armv8_2-fp16-scalar-2.c
index fa4828d..de5adf3 100644
--- a/gcc/testsuite/gcc.target/arm/armv8_2-fp16-scalar-2.c
+++ b/gcc/testsuite/gcc.target/arm/armv8_2-fp16-scalar-2.c
@@ -1,7 +1,9 @@
 /* { dg-do compile }  */
+/* { dg-require-effective-target arm_hard_ok }  */
 /* { dg-require-effective-target arm_v8_2a_fp16_scalar_ok }  */
 /* { dg-options "-O2 -std=c11" }  */
 /* { dg-add-options arm_v8_2a_fp16_scalar }  */
+/* { dg-additional-options "-mfloat-abi=hard" } */
 
 /* Test compiler use of FP16 instructions.  */
 #include 
-- 
2.7.4

[PATCH 6/8] testsuite/arm: Fix -mfloat-abi order in arm_v8_2a_bf16_neon_ok_nocache and arm_v8_2a_i8mm_ok_nocache

[Christophe Lyon via Gcc-patches]

Make the order in which we try -mfloat-abi options consistent with the
other similar effective targets: try softfp first, then hard.

This shows that a few tests implicitly rely on -mfloat-abi=hard, so we
now check arm_hard_ok where needed.

This makes these tests unsupported rather than fail on
arm-linux-gnueabi.

2021-03-19  Christophe Lyon  

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_v8_2a_i8mm_ok_nocache): Fix
-mfloat-abi= options order.
(check_effective_target_arm_v8_2a_bf16_neon_ok_nocache): Likewise.
* gcc.target/arm/bfloat16_scalar_1_1.c: Add arm_hard_ok effective
target and -mfloat-abi=hard additional option.
* gcc.target/arm/bfloat16_simd_1_1.c: Likewise.
* gcc.target/arm/simd/bf16_ma_1.c: Likewise.
* gcc.target/arm/simd/bf16_mmla_1.c: Likewise.
* gcc.target/arm/simd/vdot-2-1.c: Likewise.
* gcc.target/arm/simd/vdot-2-2.c: Likewise.
---
 gcc/testsuite/gcc.target/arm/bfloat16_scalar_1_1.c | 3 ++-
 gcc/testsuite/gcc.target/arm/bfloat16_simd_1_1.c   | 3 ++-
 gcc/testsuite/gcc.target/arm/simd/bf16_ma_1.c  | 3 ++-
 gcc/testsuite/gcc.target/arm/simd/bf16_mmla_1.c| 3 ++-
 gcc/testsuite/gcc.target/arm/simd/vdot-2-1.c   | 3 ++-
 gcc/testsuite/gcc.target/arm/simd/vdot-2-2.c   | 3 ++-
 gcc/testsuite/lib/target-supports.exp  | 4 ++--
 7 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_1_1.c 
b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_1_1.c
index efcc561..7a6c177 100644
--- a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_1_1.c
+++ b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_1_1.c
@@ -1,7 +1,8 @@
 /* { dg-do assemble { target { arm*-*-* } } } */
+/* { dg-require-effective-target arm_hard_ok } */
 /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
 /* { dg-add-options arm_v8_2a_bf16_neon }  */
-/* { dg-additional-options "-O3 --save-temps -std=gnu90" } */
+/* { dg-additional-options "-O3 --save-temps -std=gnu90 -mfloat-abi=hard" } */
 /* { dg-final { check-function-bodies "**" "" } } */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_1.c 
b/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_1.c
index cad7d54..72b4a1b 100644
--- a/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_1.c
+++ b/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_1.c
@@ -1,7 +1,8 @@
 /* { dg-do assemble { target { arm*-*-* } } } */
+/* { dg-require-effective-target arm_hard_ok } */
 /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
 /* { dg-add-options arm_v8_2a_bf16_neon }  */
-/* { dg-additional-options "-O3 --save-temps -std=gnu90" } */
+/* { dg-additional-options "-O3 --save-temps -std=gnu90 -mfloat-abi=hard" } */
 /* { dg-final { check-function-bodies "**" "" } } */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/arm/simd/bf16_ma_1.c 
b/gcc/testsuite/gcc.target/arm/simd/bf16_ma_1.c
index 6729af7..c043049 100644
--- a/gcc/testsuite/gcc.target/arm/simd/bf16_ma_1.c
+++ b/gcc/testsuite/gcc.target/arm/simd/bf16_ma_1.c
@@ -1,7 +1,8 @@
 /* { dg-do assemble } */
+/* { dg-require-effective-target arm_hard_ok } */
 /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
 /* { dg-add-options arm_v8_2a_bf16_neon } */
-/* { dg-additional-options "-save-temps -O2" }  */
+/* { dg-additional-options "-save-temps -O2 -mfloat-abi=hard" }  */
 /* { dg-final { check-function-bodies "**" "" } } */
 
 #include "arm_neon.h"
diff --git a/gcc/testsuite/gcc.target/arm/simd/bf16_mmla_1.c 
b/gcc/testsuite/gcc.target/arm/simd/bf16_mmla_1.c
index 5f9c85b..cc64e23 100644
--- a/gcc/testsuite/gcc.target/arm/simd/bf16_mmla_1.c
+++ b/gcc/testsuite/gcc.target/arm/simd/bf16_mmla_1.c
@@ -1,7 +1,8 @@
 /* { dg-do assemble } */
+/* { dg-require-effective-target arm_hard_ok } */
 /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
 /* { dg-add-options arm_v8_2a_bf16_neon } */
-/* { dg-additional-options "-save-temps -O2" } */
+/* { dg-additional-options "-save-temps -O2 -mfloat-abi=hard" } */
 /* { dg-final { check-function-bodies "**" "" } } */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/arm/simd/vdot-2-1.c 
b/gcc/testsuite/gcc.target/arm/simd/vdot-2-1.c
index 4d5f07b..88b80cf 100644
--- a/gcc/testsuite/gcc.target/arm/simd/vdot-2-1.c
+++ b/gcc/testsuite/gcc.target/arm/simd/vdot-2-1.c
@@ -1,7 +1,8 @@
 /* { dg-do assemble { target { arm*-*-* } } } */
+/* { dg-require-effective-target arm_hard_ok } */
 /* { dg-require-effective-target arm_v8_2a_i8mm_ok } */
 /* { dg-add-options arm_v8_2a_i8mm }  */
-/* { dg-additional-options "-O -save-temps" } */
+/* { dg-additional-options "-O -save-temps -mfloat-abi=hard" } */
 /* { dg-final { check-function-bodies "**" "" } } */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/arm/simd/vdot-2-2.c 
b/gcc/testsuite/gcc.target/arm/simd/vdot-2-2.c
index b7b76e2..1c74718 100644
--- a/gcc/testsuite/gcc.target/arm/simd/vdot-2-2.c
+++ b/gcc/testsuite/gcc.target/arm/simd/vdot-2-2.c
@

[PATCH 7/8] testsuite/arm: Fix -mfloat-abi order in arm_v8_1m_mve_ok_nocache and arm_v8_1m_mve_fp_ok_nocache

[Christophe Lyon via Gcc-patches]

Make the order in which we try -mfloat-abi options consistent with the
other similar effective targets: try softfp first, then hard.

This shows that a few tests implicitly rely on -mfloat-abi=hard, so we
add this option via dg-additional-options so that it comes after any
potential -mfloat-abi option that the preceding effective-targets
might have added.

armv8_1m-fpXX-move-1.c tests don't need arm_hard_ok because they don't
include arm_mve.h: adding -mfloat-abi=hard when using a soft/softfp
toolchain does not lead to the missing include gnu/stubs-*.h error.

This patch makes armv8_1m-fpXX-move-1.c pass on arm-linux-gnueabi, and
the other tests become unsupported (instead of fail) on this target.

On arm-eabi with default cpu/fpu/mode and a+rm multilibs, the same
mve/intrinsics/* tests become unsupported instead of pass because
arm_hard_ok fails with "selected processor lacks an FPU". Since we
also override the fpu via dg-options, we'd need another effective
target (say arm_hard_mve_ok) that would check -mfloat-abi=hard
-mfpu=auto -march=armv8.1-m.main+mve.fp at the same time. But we have
already so many arm effective targets, it doesn't seem like a good way
forward.

2021-03-19  Christophe Lyon  

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_v8_1m_mve_fp_ok_nocache): Fix
-mfloat-abi= options order.
(check_effective_target_arm_v8_1m_mve_ok_nocache): Likewise
* gcc.target/arm/mve/intrinsics/mve_vector_float2.c: Add
arm_hard_ok effective target and -mfloat-abi=hard additional
option.
* gcc.target/arm/mve/intrinsics/mve_vector_int.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_uint.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_uint1.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_uint2.c: Likewise.
* gcc.target/arm/mve/intrinsics/vgetq_lane_s64.c: Likewise.
* gcc.target/arm/mve/intrinsics/vgetq_lane_u64.c: Likewise.
* gcc.target/arm/mve/intrinsics/vsetq_lane_s64.c: Likewise.
* gcc.target/arm/mve/intrinsics/vsetq_lane_u64.c: Likewise.
* gcc.target/arm/armv8_1m-fp16-move-1.c: Add -mfloat-abi=hard
additional option.
* gcc.target/arm/armv8_1m-fp32-move-1.c: Likewise.
* gcc.target/arm/armv8_1m-fp64-move-1.c: Likewise.
---
 gcc/testsuite/gcc.target/arm/armv8_1m-fp16-move-1.c | 3 ++-
 gcc/testsuite/gcc.target/arm/armv8_1m-fp32-move-1.c | 3 ++-
 gcc/testsuite/gcc.target/arm/armv8_1m-fp64-move-1.c | 3 ++-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c | 2 ++
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c| 2 ++
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint.c   | 2 ++
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint1.c  | 2 ++
 gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint2.c  | 2 ++
 gcc/testsuite/gcc.target/arm/mve/intrinsics/vgetq_lane_s64.c| 3 ++-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/vgetq_lane_u64.c| 3 ++-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/vsetq_lane_s64.c| 3 ++-
 gcc/testsuite/gcc.target/arm/mve/intrinsics/vsetq_lane_u64.c| 3 ++-
 gcc/testsuite/lib/target-supports.exp   | 4 ++--
 13 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/armv8_1m-fp16-move-1.c 
b/gcc/testsuite/gcc.target/arm/armv8_1m-fp16-move-1.c
index 67a9f41..f5ab6e7 100644
--- a/gcc/testsuite/gcc.target/arm/armv8_1m-fp16-move-1.c
+++ b/gcc/testsuite/gcc.target/arm/armv8_1m-fp16-move-1.c
@@ -1,7 +1,8 @@
 /* { dg-do compile } */
-/* { dg-options "-O -mfloat-abi=hard -mfp16-format=ieee" } */
+/* { dg-options "-O -mfp16-format=ieee" } */
 /* { dg-require-effective-target arm_v8_1m_mve_ok } */
 /* { dg-add-options arm_v8_1m_mve } */
+/* { dg-additional-options "-mfloat-abi=hard" } *
 /* { dg-final { check-function-bodies "**" "" } } */
 
 /*
diff --git a/gcc/testsuite/gcc.target/arm/armv8_1m-fp32-move-1.c 
b/gcc/testsuite/gcc.target/arm/armv8_1m-fp32-move-1.c
index 1ecb839..2f62e839 100644
--- a/gcc/testsuite/gcc.target/arm/armv8_1m-fp32-move-1.c
+++ b/gcc/testsuite/gcc.target/arm/armv8_1m-fp32-move-1.c
@@ -1,7 +1,8 @@
 /* { dg-do compile } */
-/* { dg-options "-O -mfloat-abi=hard" } */
+/* { dg-options "-O" } */
 /* { dg-require-effective-target arm_v8_1m_mve_ok } */
 /* { dg-add-options arm_v8_1m_mve } */
+/* { dg-additional-options "-mfloat-abi=hard" } *
 /* { dg-final { check-function-bodies "**" "" } } */
 
 /*
diff --git a/gcc/testsuite/gcc.target/arm/armv8_1m-fp64-move-1.c 
b/gcc/testsuite/gcc.target/arm/armv8_1m-fp64-move-1.c
index 3f81350..d236f08 100644
--- a/gcc/testsuite/gcc.target/arm/armv8_1m-fp64-move-1.c
+++ b/gcc/testsuite/gcc.target/arm/armv8_1m-fp64-move-1.c
@@ -1,7 +1,8 @@
 /* { dg-do compile } */
-/* { dg-options "-O -mfloat-abi=hard" } */
+/* { dg-options "-O" } */
 /* { dg-require-effective-target arm_v8_1m_mve_ok

[PATCH 8/8] testsuite/arm: Add arm_dsp_ok effective target and use it in arm/acle/dsp_arith.c

[Christophe Lyon via Gcc-patches]

gcc.target/arm/acle/dsp_arith.c uses DSP intrinsics, which arm_acle.h
defines only with __ARM_FEATURE_DSP, so make the test check for that
property rather than arm_qbit_ok.

However, the existing arm_dsp effective target only checks if DSP
features are supported with the current multilib rather than trying
-march and -mfloat-abi options. Thus we introduce a similar effective
target, arm_dsp_ok and associated dg-add-options.

This makes dsp_arith.c unsupported rather than failed when no option
combination is suitable, for instance when running the tests with
-mcpu=cortex-m3.

2021-03-19  Christophe Lyon  

gcc/
* doc/sourcebuild.texi (arm_dsp_ok, arm_dsp): Document.

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_dsp_ok_nocache)
(check_effective_target_arm_dsp_ok, add_options_for_arm_dsp): New.
* gcc.target/arm/acle/dsp_arith.c: Use arm_dsp_ok effective target
and add arm_dsp options.
---
 gcc/doc/sourcebuild.texi  | 11 
 gcc/testsuite/gcc.target/arm/acle/dsp_arith.c |  4 +--
 gcc/testsuite/lib/target-supports.exp | 40 +++
 3 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 1fa3656..2bc362b 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2044,6 +2044,12 @@ ARM Target supports options suitable for accessing the 
Q-bit manipulation
 intrinsics from @code{arm_acle.h}.
 Some multilibs may be incompatible with these options.
 
+@item arm_dsp_ok
+@anchor{arm_dsp_ok}
+ARM Target supports options suitable for accessing the DSP intrinsics
+from @code{arm_acle.h}.
+Some multilibs may be incompatible with these options.
+
 @item arm_softfp_ok
 @anchor{arm_softfp_ok}
 ARM target supports the @code{-mfloat-abi=softfp} option.
@@ -2778,6 +2784,11 @@ Add options to enable generation of the @code{VFMAL} and 
@code{VFMSL}
 instructions, if this is supported by the target; see the
 @ref{arm_fp16fml_neon_ok} effective target keyword.
 
+@item arm_dsp
+Add options for ARM DSP intrinsics support, if this is supported by
+the target; see the @ref{arm_dsp_ok,,arm_dsp_ok effective target
+keyword}.
+
 @item bind_pic_locally
 Add the target-specific flags needed to enable functions to bind
 locally when using pic/PIC passes in the testsuite.
diff --git a/gcc/testsuite/gcc.target/arm/acle/dsp_arith.c 
b/gcc/testsuite/gcc.target/arm/acle/dsp_arith.c
index 9ebd55a..7bf458e 100644
--- a/gcc/testsuite/gcc.target/arm/acle/dsp_arith.c
+++ b/gcc/testsuite/gcc.target/arm/acle/dsp_arith.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target arm_qbit_ok } */
-/* { dg-add-options arm_qbit  } */
+/* { dg-require-effective-target arm_dsp_ok } */
+/* { dg-add-options arm_dsp } */
 
 #include 
 
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 1af7619..733b6c8 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -4200,6 +4200,46 @@ proc add_options_for_arm_qbit { flags } {
 return "$flags $et_arm_qbit_flags"
 }
 
+# Return 1 if this is an ARM target supporting the DSP intrinsics from
+# arm_acle.h.  Some multilibs may be incompatible with these options.
+# Also set et_arm_dsp_flags to the best options to add.
+# arm_acle.h includes stdint.h which can cause trouble with incompatible
+# -mfloat-abi= options.
+# check_effective_target_arm_dsp also exists, which checks the current
+# multilib, without trying other options.
+
+proc check_effective_target_arm_dsp_ok_nocache { } {
+global et_arm_dsp_flags
+set et_arm_dsp_flags ""
+foreach flags {"" "-march=armv5te" "-march=armv5te -mfloat-abi=softfp" 
"-march=armv5te -mfloat-abi=hard"} {
+  if { [check_no_compiler_messages_nocache et_arm_dsp_ok object {
+   #include 
+   int dummy;
+   #ifndef __ARM_FEATURE_DSP
+   #error not DSP
+   #endif
+  } "$flags"] } {
+   set et_arm_dsp_flags $flags
+   return 1
+  }
+}
+
+  return 0
+}
+
+proc check_effective_target_arm_dsp_ok { } {
+return [check_cached_effective_target et_arm_dsp_flags \
+   check_effective_target_arm_dsp_ok_nocache]
+}
+
+proc add_options_for_arm_dsp { flags } {
+if { ! [check_effective_target_arm_dsp_ok] } {
+   return "$flags"
+}
+global et_arm_dsp_flags
+return "$flags $et_arm_dsp_flags"
+}
+
 # Return 1 if this is an ARM target supporting -mfpu=neon without any
 # -mfloat-abi= option.  Useful in tests where add_options is not
 # supported (such as lto tests).
-- 
2.7.4

Re: [Patch] Fortran: Fix func decl mismatch [PR93660]

[Paul Richard Thomas via Gcc-patches]

Hi Tobias,

The patch looks fine to me. OK for 10- and 11-branches. I am not convinced
that a delay is needed for the backport.

Thanks

Paul


On Thu, 11 Mar 2021 at 18:19, Tobias Burnus  wrote:

> This fixes an ICE with OpenMP 'omp decare simd' but is a generic bug.
>
> Namely TREE_TYPE(fndecl) has a mismatch to the arglist chain,
> missing some hidden arguments with -fcoarray=lib.
>
> OK for mainline and GCC 10?
>
> Tobias
>
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
> Thürauf
>


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

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

[Iain Sandoe]

Hi

I expect this to be my last (substantial) regression fix for GCC-11.

Although this is a Darwin patch, I’d welcome any comments - if none appear
then I plan to apply the patch later in the week.

tested on Darwin8 .20, x86_64-linux-gnu and powerpc-linux-gnu.

thanks
Iain

==


This addresses a long-standing problem where a work-around for an unwinder
issue (also a regression) regresses other functionality.  The patch replaces
the work-arounds.

TL;DR:
 * we provide a bumped libgcc_s.1.1 that contains the routines that were
   previously exported via symbols in libgcc_ext
 * we always use the builtins from the [new] compiler's libgcc.

This allows us to clean up a bunch of stuff and back out of the various work-
arounds.  (With 20:20 hindsight, we should have done this in the first place
but the libgcc_ext solution, described below, appeared less invasive at the
time).



MacOS system configurations are considered immutable by end-users - there is
no general equivalent of "apt-getting" additions to the system components,
instead updates come from Apple, at least, until an OS version is out of
support.  Additions typically come from one of the macOS OSS 'distributions'
(e.g. macports, homebrew, fink).

OSS distributions install alongside the system rather than into it - and  
policy

(for at least the major distributions) is that they do not modify the Apple-
provided one.  As far as the Darwin maintainers of GCC are concerned, this is
the only realistically supportable policy here too.

The issue here concerns the shared libgcc which not only provides the  
compiler

built-ins but also support for emulated TLS and the language-neutral parts of
the unwinder.

On macOS, there is no user-space equivalent of a completely "static"  
executable

they are all launched via the dynamic loader (dyld) and use the shared libc
(libSystem) which is only available as a dynamic library.  Nevertheless, the
static linker can use convenience libraries - so that (other than  
libSystem) an

executable can be statically-linked.

Until 10.3.9, there was no shared libgcc (or libstdc++) and all exceptions-
handling code was added from convenience libraries by the static linker.

Between 10.3.9 and 10.5.8, there is a shared libgcc_s, which provides the
unwinder and is based on gcc-4.2.1.  This is /usr/lib/libgcc_s.1.dylib.

From 10.6 onwards the unwinder is provided (via libSystem) by libunwind  
which

is part of the LLVM project.  However, for backwards compatibility, there is
a symlink /usr/lib/libgcc_s.1.dylib => /usr/lib/libSystem.B.dylib.  Note,  
that

this link has (currently) been removed from macOS 11 systems.

We want to be able to install a new version of GCC alongside existing system
compilers, but policy dictates that we are not able to overwrite or replace
the system unwinder with the one in the new libgcc_s (it would be essentially
unworkable on any system after 10.6 anyway).

On Darwin systems /path1/to/library.dylib and /path2/to/library.dylib are
considered to be different libraries (so-called, two-level library  
namespace).


Darwin can also provide 'stub' libraries that simply re-export a sub-set of
the symbols from another library.

These two points allowed us to use two stub libraries; one containing the
symbols from the original /usr/lib/libgcc_s.1.dylib and one containing new
symbols from /path/to/compiler/install/lib/libgcc_s.1.dylib.  Since the two
libraries are distinct by the two-level namespace rules, there was no need to
alter the library build (a complete set of builtins and unwinder components  
are

still present in the /path/to/compiler/install/lib/libgcc_s.1.dylib).
The system SDKs provide the stub libraries that export the symbols present in
/usr/lib/libgcc_s.1.dylib; we added a 'libgcc_ext' stub (describing the new
symbols available with the updated GCC).

NOTE (important) that this means that code referring to
/path/to/compiler/install/lib/libgcc_s.1.dylib via libgcc_ext
will not reference any unwinder symbols in that lib [even though they were
present in the built libraries, they were not exposed via the stub].

Unfortunately the system SDKs do not provide a libgcc_s.10.X for 10.6+ and we
are not able to add our own (since SDKs are considered part of the immutable
content).  Since the systems *do* provide /usr/lib/libgcc_s.1.dylib as a link
to libSystem and /usr/lib is a necessary path for library searches, this
conflicts with any -lgcc_s.1 we add.

A series of workarounds have been used to try and resolve this, but none are
completely satisfactory; hence this patch.

--- dynamic objects

This change removes all the stubs machinery and workarounds and:

 * bumps the SO version for Darwin's libgcc_s => 1.1 avoiding the conflict.
 * the new version does not contain an unwinder, so it can be symlinked as
   libgcc_s.1 [in the compiler install path] and be backward-compatible with
   the symbols exported by libgcc_ext (per NOTE above).
 * builtins will be resolved from the new libgc

RE: [PATCH 1/8] testsuite/arm: Add arm_v8_2a_fp16_neon and arm_v8_2a_bf16_neon options

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Gcc-patches  On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 1/8] testsuite/arm: Add arm_v8_2a_fp16_neon and
> arm_v8_2a_bf16_neon options
> 
> A few tests lack the dg-add-options directives associated with the
> dg-require-effective-target they are using. Adding them enables to
> pass the right float-abi option, and thus make the tests pass instead
> of emit an error.
> 
> For instance, we now pass -mfloat-abi=softfp on arm-linux-gnueabi
> targets and the tests pass.
> 

Ok.
Thanks,
Kyrill

> 2021-03-19  Christophe Lyon  
> 
>   gcc/testsuite/
>   * gcc.target/arm/bfloat16_scalar_typecheck.c: Add
>   arm_v8_2a_fp16_neon and arm_v8_2a_bf16_neon.
>   * gcc.target/arm/bfloat16_vector_typecheck_1.c: Likewise.
>   * gcc.target/arm/bfloat16_vector_typecheck_2.c: Likewise.
> ---
>  gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c   | 2 ++
>  gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c | 2 ++
>  gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c | 6 --
>  3 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
> b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
> index 672641e..8c80c55 100644
> --- a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
> +++ b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
> @@ -2,6 +2,8 @@
>  /* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } } */
>  /* { dg-require-effective-target arm_v8_2a_fp16_neon_ok } */
>  /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
> +/* { dg-add-options arm_v8_2a_fp16_neon } */
> +/* { dg-add-options arm_v8_2a_bf16_neon } */
>  /* { dg-additional-options "-march=armv8.6-a+bf16+fp16 -Wno-pedantic -
> O3 --save-temps" }  */
> 
>  #include 
> diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c
> b/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c
> index ba39cb6..f3c350b 100644
> --- a/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c
> +++ b/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c
> @@ -2,6 +2,8 @@
>  /* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } } */
>  /* { dg-require-effective-target arm_v8_2a_fp16_neon_ok } */
>  /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
> +/* { dg-add-options arm_v8_2a_fp16_neon } */
> +/* { dg-add-options arm_v8_2a_bf16_neon } */
>  /* { dg-additional-options "-march=armv8.6-a+bf16+fp16 -Wno-pedantic -
> O3 --save-temps" }  */
> 
>  #include 
> diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c
> b/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c
> index 16669dc..de0ade5 100644
> --- a/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c
> +++ b/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c
> @@ -2,6 +2,8 @@
>  /* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } } */
>  /* { dg-require-effective-target arm_v8_2a_fp16_neon_ok } */
>  /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
> +/* { dg-add-options arm_v8_2a_fp16_neon } */
> +/* { dg-add-options arm_v8_2a_bf16_neon } */
>  /* { dg-additional-options "-march=armv8.6-a+bf16+fp16 -Wno-pedantic -
> O3 --save-temps" }  */
> 
>  #include 
> @@ -25,8 +27,8 @@ float is_a_float16;
>  double is_a_double;
> 
>  bfloat16x8_t foo3 (void) { return (bfloat16x8_t)
> 0x12345678123456781234567812345678; }
> - /* { dg-error {integer constant is too large for its type} "" {target 
> *-*-*} 27 }
> */
> - /* { dg-error {cannot convert a value of type 'long long int' to vector type
> '__simd128_bfloat16_t' which has different size} "" {target *-*-*} 27 } */
> + /* { dg-error {integer constant is too large for its type} "" {target 
> *-*-*} .-1 }
> */
> + /* { dg-error {cannot convert a value of type 'long long int' to vector type
> '__simd128_bfloat16_t' which has different size} "" {target *-*-*} .-2 } */
> 
>  bfloat16x8_t footest (bfloat16x8_t vector0)
>  {
> --
> 2.7.4

RE: [PATCH 2/8] testsuite/arm: Add arm_v8_2a_i8mm options in gcc.target/arm/simd/vmmla_1.c

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Gcc-patches  On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 2/8] testsuite/arm: Add arm_v8_2a_i8mm options in
> gcc.target/arm/simd/vmmla_1.c
> 
> We need to add the options corresponding to the arm_v8_2a_i8mm_ok
> effective target in order to use the right float-abi option:
> -mfloat-abi=softfp makes the test pass for arm-linux-gnueabi,
> while no -mfloat-abi option is needed for arm-linux-gnueabihf.

Ok.
Thanks,
Kyrill

> 
> 2021-03-19  Christophe Lyon  
> 
>   gcc/testsuite/
>   * gcc.target/arm/simd/vmmla_1.c: Add arm_v8_2a_i8mm options.
> ---
>  gcc/testsuite/gcc.target/arm/simd/vmmla_1.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/simd/vmmla_1.c
> b/gcc/testsuite/gcc.target/arm/simd/vmmla_1.c
> index d33ebf3..a88c4ea 100644
> --- a/gcc/testsuite/gcc.target/arm/simd/vmmla_1.c
> +++ b/gcc/testsuite/gcc.target/arm/simd/vmmla_1.c
> @@ -1,6 +1,7 @@
>  /* { dg-do assemble } */
>  /* { dg-require-effective-target arm_v8_2a_i8mm_ok } */
> -/* { dg-options "-save-temps -O2 -march=armv8.2-a+i8mm -mfpu=auto -
> mfloat-abi=hard" } */
> +/* { dg-options "-save-temps -O2 -mfpu=auto" } */
> +/* { dg-add-options arm_v8_2a_i8mm } */
> 
>  #include "arm_neon.h"
> 
> --
> 2.7.4

RE: [PATCH 3/8] testsuite/arm: Remove useless -mfloat-abi option

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Gcc-patches  On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 3/8] testsuite/arm: Remove useless -mfloat-abi option
> 
> These tests pass with their current dg-add-options, no need to force
> -mfloat=abi.
> 
> I've noticed no impact on armv8_1m-shift-imm-1.c and
> armv8_1m-shift-reg-1.c, bf16_reinterpret.c now passes on
> arm-linux-gnueabi and bf16_dup.c now passes on arm-linux-gnueabihf.
> 
> This allows pr51534.c to pass when forcing -mfloat-abi=soft in
> runtestflags, otherwise we get an error '-mfloat-abi=soft and
> -mfloat-abi=hard may not be used together' because we try to compile
> with both flags.

Ok.
Thanks,
Kyrill

> 
> 2021-03-19  Christophe Lyon  
> 
>   gcc/testsuite/
>   * gcc.target/arm/armv8_1m-shift-imm-1.c: Remove -mfloat=abi
> option.
>   * gcc.target/arm/armv8_1m-shift-reg-1.c: Likewise.
>   * gcc.target/arm/bf16_dup.c: Likewise.
>   * gcc.target/arm/bf16_reinterpret.c: Likewise.
>   * gcc.target/arm/pr51534.c: Remove -mfloat=abi option.
> ---
>  gcc/testsuite/gcc.target/arm/armv8_1m-shift-imm-1.c | 2 +-
>  gcc/testsuite/gcc.target/arm/armv8_1m-shift-reg-1.c | 2 +-
>  gcc/testsuite/gcc.target/arm/bf16_dup.c | 2 +-
>  gcc/testsuite/gcc.target/arm/bf16_reinterpret.c | 2 +-
>  gcc/testsuite/gcc.target/arm/pr51534.c  | 2 +-
>  5 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/armv8_1m-shift-imm-1.c
> b/gcc/testsuite/gcc.target/arm/armv8_1m-shift-imm-1.c
> index 883fbb09..84f13e2 100644
> --- a/gcc/testsuite/gcc.target/arm/armv8_1m-shift-imm-1.c
> +++ b/gcc/testsuite/gcc.target/arm/armv8_1m-shift-imm-1.c
> @@ -1,6 +1,6 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O2 -mfloat-abi=softfp -mlittle-endian" } */
>  /* { dg-require-effective-target arm_v8_1m_mve_ok } */
> +/* { dg-options "-O2 -mlittle-endian" } */
>  /* { dg-add-options arm_v8_1m_mve } */
> 
>  long long longval1;
> diff --git a/gcc/testsuite/gcc.target/arm/armv8_1m-shift-reg-1.c
> b/gcc/testsuite/gcc.target/arm/armv8_1m-shift-reg-1.c
> index e125ff8..8668b6b 100644
> --- a/gcc/testsuite/gcc.target/arm/armv8_1m-shift-reg-1.c
> +++ b/gcc/testsuite/gcc.target/arm/armv8_1m-shift-reg-1.c
> @@ -1,6 +1,6 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O2 -mfloat-abi=softfp -mlittle-endian" } */
>  /* { dg-require-effective-target arm_v8_1m_mve_ok } */
> +/* { dg-options "-O2 -mlittle-endian" } */
>  /* { dg-add-options arm_v8_1m_mve } */
> 
>  long long longval2;
> diff --git a/gcc/testsuite/gcc.target/arm/bf16_dup.c
> b/gcc/testsuite/gcc.target/arm/bf16_dup.c
> index 94be99a..b62bce1 100644
> --- a/gcc/testsuite/gcc.target/arm/bf16_dup.c
> +++ b/gcc/testsuite/gcc.target/arm/bf16_dup.c
> @@ -1,7 +1,7 @@
>  /* { dg-do assemble { target { arm*-*-* } } } */
>  /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
>  /* { dg-add-options arm_v8_2a_bf16_neon }  */
> -/* { dg-additional-options "-save-temps -march=armv8.2-a+bf16+fp16 -
> mfloat-abi=softfp" } */
> +/* { dg-additional-options "-save-temps -march=armv8.2-a+bf16+fp16" } */
> 
>  #include "arm_neon.h"
> 
> diff --git a/gcc/testsuite/gcc.target/arm/bf16_reinterpret.c
> b/gcc/testsuite/gcc.target/arm/bf16_reinterpret.c
> index e7d30a9..9e36fc5 100644
> --- a/gcc/testsuite/gcc.target/arm/bf16_reinterpret.c
> +++ b/gcc/testsuite/gcc.target/arm/bf16_reinterpret.c
> @@ -1,7 +1,7 @@
>  /* { dg-do assemble { target { arm*-*-* } } } */
>  /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
>  /* { dg-add-options arm_v8_2a_bf16_neon }  */
> -/* { dg-additional-options "-save-temps -march=armv8.2-a+fp16+bf16 -
> mfloat-abi=hard -mfpu=crypto-neon-fp-armv8" } */
> +/* { dg-additional-options "-save-temps -march=armv8.2-a+fp16+bf16 -
> mfpu=crypto-neon-fp-armv8" } */
> 
>  #include 
> 
> diff --git a/gcc/testsuite/gcc.target/arm/pr51534.c
> b/gcc/testsuite/gcc.target/arm/pr51534.c
> index f675a44..3711b45 100644
> --- a/gcc/testsuite/gcc.target/arm/pr51534.c
> +++ b/gcc/testsuite/gcc.target/arm/pr51534.c
> @@ -3,7 +3,7 @@
> 
>  /* { dg-do assemble } */
>  /* { dg-require-effective-target arm_neon_ok } */
> -/* { dg-options "-save-temps -mfloat-abi=hard -O3" } */
> +/* { dg-options "-save-temps -O3" } */
>  /* { dg-add-options arm_neon } */
> 
>  #include 
> --
> 2.7.4

RE: [PATCH 4/8] testsuite/arm: Add arm_softfp_ok or arm_hard_ok as needed.

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Gcc-patches  On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 4/8] testsuite/arm: Add arm_softfp_ok or arm_hard_ok as
> needed.
> 
> Several tests override the -mfloat-abi option detected by their
> effective targets. Make sure it is supported, so that these tests are
> unsupported rather than failures (the inclusion of arm_neon.h
> otherwise fails for lack of gnu/stubs-*.h)
> 
> This avoids failures with
> bfloat16_simd_2_1.c
> bfloat16_simd_3_1.c
> bf16_vldn_1.c
> bf16_vstn_1.c on arm-linux-gnueabi
> and
> pr51968.c
> bfloat16_simd_1_2.c
> bfloat16_simd_2_2.c
> bfloat16_simd_3_2.c on arm-linux-gnueabihf.
> 
> On arm-eabi with default cpu/fpu/mode and a+rm multilibs,
> bfloat16_simd_2_1.c, bfloat16_simd_3_1.c, bf16_vstn_1.c and
> bf16_vldn_1.c become unsupported instead of pass because arm_hard_ok
> fails with "selected processor lacks an FPU". Since we also override
> the fpu in dg-additional-options, we'd need another effective target
> (say arm_hard_neon_ok) that would check -mfloat-abi=hard -mfpu=neon at
> the same time. But we have already so many arm effective targets, it
> doesn't seem like a good way forward.

Yeah, I think the approach you took is the best one for these tests.
Ok.
Thanks,
Kyrill

> 
> 2021-03-19  Christophe Lyon  
> 
>   gcc/testsuite/
>   * gcc.target/arm/bfloat16_simd_1_2.c: Add arm_softfp_ok.
>   * gcc.target/arm/bfloat16_simd_2_2.c: Likewise.
>   * gcc.target/arm/bfloat16_simd_3_2.c: Likewise.
>   * gcc.target/arm/pr51968.c: Likewise.
>   * gcc.target/arm/bfloat16_simd_2_1.c: arm_hard_ok.
>   * gcc.target/arm/bfloat16_simd_3_1.c: Likewise.
>   * gcc.target/arm/simd/bf16_vldn_1.c: Likewise.
>   * gcc.target/arm/simd/bf16_vstn_1.c: Likewise.
> ---
>  gcc/testsuite/gcc.target/arm/bfloat16_simd_1_2.c | 1 +
>  gcc/testsuite/gcc.target/arm/bfloat16_simd_2_1.c | 1 +
>  gcc/testsuite/gcc.target/arm/bfloat16_simd_2_2.c | 1 +
>  gcc/testsuite/gcc.target/arm/bfloat16_simd_3_1.c | 1 +
>  gcc/testsuite/gcc.target/arm/bfloat16_simd_3_2.c | 1 +
>  gcc/testsuite/gcc.target/arm/pr51968.c   | 3 ++-
>  gcc/testsuite/gcc.target/arm/simd/bf16_vldn_1.c  | 1 +
>  gcc/testsuite/gcc.target/arm/simd/bf16_vstn_1.c  | 1 +
>  8 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_2.c
> b/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_2.c
> index 4ffcc54..95eecec 100644
> --- a/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_2.c
> +++ b/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_2.c
> @@ -1,4 +1,5 @@
>  /* { dg-do assemble { target { arm*-*-* } } } */
> +/* { dg-require-effective-target arm_softfp_ok } */
>  /* { dg-require-effective-target arm_v8_neon_ok } */
>  /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
>  /* { dg-additional-options "-march=armv8.2-a+bf16 -mfloat-abi=softfp -
> mfpu=auto" } */
> diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_1.c
> b/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_1.c
> index 05ee4d8..02b4c41 100644
> --- a/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_1.c
> +++ b/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_1.c
> @@ -1,4 +1,5 @@
>  /* { dg-do assemble { target { arm*-*-* } } } */
> +/* { dg-require-effective-target arm_hard_ok } */
>  /* { dg-require-effective-target arm_v8_neon_ok } */
>  /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
>  /* { dg-additional-options "-march=armv8.2-a -mfloat-abi=hard -
> mfpu=neon-fp-armv8" } */
> diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_2.c
> b/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_2.c
> index 15fba31..175bfa5 100644
> --- a/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_2.c
> +++ b/gcc/testsuite/gcc.target/arm/bfloat16_simd_2_2.c
> @@ -1,4 +1,5 @@
>  /* { dg-do assemble { target { arm*-*-* } } } */
> +/* { dg-require-effective-target arm_softfp_ok } */
>  /* { dg-require-effective-target arm_v8_neon_ok } */
>  /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
>  /* { dg-additional-options "-march=armv8.2-a -mfloat-abi=softfp -
> mfpu=neon-fp-armv8" } */
> diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_1.c
> b/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_1.c
> index b9b7606..d2326c2 100644
> --- a/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_1.c
> +++ b/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_1.c
> @@ -1,4 +1,5 @@
>  /* { dg-do assemble { target { arm*-*-* } } } */
> +/* { dg-require-effective-target arm_hard_ok } */
>  /* { dg-require-effective-target arm_v8_neon_ok } */
>  /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
>  /* { dg-additional-options "-march=armv8.2-a -mfloat-abi=hard -
> mfpu=neon-fp-armv8" } */
> diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_2.c
> b/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_2.c
> index ab1fe10..346253b 100644
> --- a/gcc/testsuite/gcc.target/arm/bfloat16_simd_3_2.c
> +++ b/gcc/te

RE: [PATCH 5/8] testsuite/arm: Add arm_hard_ok check in armv8_2-fp16-scalar-2.c

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Gcc-patches  On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 5/8] testsuite/arm: Add arm_hard_ok check in armv8_2-
> fp16-scalar-2.c
> 
> This test relies on -mfloat-abi=hard to pass (otherwise
> test_mov_imm_[12] directly build the 1.0 fp16 representation via movw
> r0, #15360 rather than using vmov.f16 s0, #1.0e+0 as expected by
> scan-assembler-times)
> 
> Adding the arm_hard_ok check makes the test unsupported eg. on
> arm-linux-gnueabi instead of reporting a failure.

Ok.
Thanks,
Kyrill

> 
> 2021-03-20  Christophe Lyon  
> 
>   gcc/testsuite/
>   * gcc.target/arm/armv8_2-fp16-scalar-2.c: Add arm_hard_ok.
> ---
>  gcc/testsuite/gcc.target/arm/armv8_2-fp16-scalar-2.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/armv8_2-fp16-scalar-2.c
> b/gcc/testsuite/gcc.target/arm/armv8_2-fp16-scalar-2.c
> index fa4828d..de5adf3 100644
> --- a/gcc/testsuite/gcc.target/arm/armv8_2-fp16-scalar-2.c
> +++ b/gcc/testsuite/gcc.target/arm/armv8_2-fp16-scalar-2.c
> @@ -1,7 +1,9 @@
>  /* { dg-do compile }  */
> +/* { dg-require-effective-target arm_hard_ok }  */
>  /* { dg-require-effective-target arm_v8_2a_fp16_scalar_ok }  */
>  /* { dg-options "-O2 -std=c11" }  */
>  /* { dg-add-options arm_v8_2a_fp16_scalar }  */
> +/* { dg-additional-options "-mfloat-abi=hard" } */
> 
>  /* Test compiler use of FP16 instructions.  */
>  #include 
> --
> 2.7.4

RE: [PATCH 6/8] testsuite/arm: Fix -mfloat-abi order in arm_v8_2a_bf16_neon_ok_nocache and arm_v8_2a_i8mm_ok_nocache

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Gcc-patches  On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 6/8] testsuite/arm: Fix -mfloat-abi order in
> arm_v8_2a_bf16_neon_ok_nocache and arm_v8_2a_i8mm_ok_nocache
> 
> Make the order in which we try -mfloat-abi options consistent with the
> other similar effective targets: try softfp first, then hard.
> 
> This shows that a few tests implicitly rely on -mfloat-abi=hard, so we
> now check arm_hard_ok where needed.
> 
> This makes these tests unsupported rather than fail on
> arm-linux-gnueabi.
> 

Ok.
Thanks,
Kyrill

> 2021-03-19  Christophe Lyon  
> 
>   gcc/testsuite/
>   * lib/target-supports.exp
>   (check_effective_target_arm_v8_2a_i8mm_ok_nocache): Fix
>   -mfloat-abi= options order.
>   (check_effective_target_arm_v8_2a_bf16_neon_ok_nocache):
> Likewise.
>   * gcc.target/arm/bfloat16_scalar_1_1.c: Add arm_hard_ok effective
>   target and -mfloat-abi=hard additional option.
>   * gcc.target/arm/bfloat16_simd_1_1.c: Likewise.
>   * gcc.target/arm/simd/bf16_ma_1.c: Likewise.
>   * gcc.target/arm/simd/bf16_mmla_1.c: Likewise.
>   * gcc.target/arm/simd/vdot-2-1.c: Likewise.
>   * gcc.target/arm/simd/vdot-2-2.c: Likewise.
> ---
>  gcc/testsuite/gcc.target/arm/bfloat16_scalar_1_1.c | 3 ++-
>  gcc/testsuite/gcc.target/arm/bfloat16_simd_1_1.c   | 3 ++-
>  gcc/testsuite/gcc.target/arm/simd/bf16_ma_1.c  | 3 ++-
>  gcc/testsuite/gcc.target/arm/simd/bf16_mmla_1.c| 3 ++-
>  gcc/testsuite/gcc.target/arm/simd/vdot-2-1.c   | 3 ++-
>  gcc/testsuite/gcc.target/arm/simd/vdot-2-2.c   | 3 ++-
>  gcc/testsuite/lib/target-supports.exp  | 4 ++--
>  7 files changed, 14 insertions(+), 8 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_1_1.c
> b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_1_1.c
> index efcc561..7a6c177 100644
> --- a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_1_1.c
> +++ b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_1_1.c
> @@ -1,7 +1,8 @@
>  /* { dg-do assemble { target { arm*-*-* } } } */
> +/* { dg-require-effective-target arm_hard_ok } */
>  /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
>  /* { dg-add-options arm_v8_2a_bf16_neon }  */
> -/* { dg-additional-options "-O3 --save-temps -std=gnu90" } */
> +/* { dg-additional-options "-O3 --save-temps -std=gnu90 -mfloat-abi=hard" }
> */
>  /* { dg-final { check-function-bodies "**" "" } } */
> 
>  #include 
> diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_1.c
> b/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_1.c
> index cad7d54..72b4a1b 100644
> --- a/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_1.c
> +++ b/gcc/testsuite/gcc.target/arm/bfloat16_simd_1_1.c
> @@ -1,7 +1,8 @@
>  /* { dg-do assemble { target { arm*-*-* } } } */
> +/* { dg-require-effective-target arm_hard_ok } */
>  /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
>  /* { dg-add-options arm_v8_2a_bf16_neon }  */
> -/* { dg-additional-options "-O3 --save-temps -std=gnu90" } */
> +/* { dg-additional-options "-O3 --save-temps -std=gnu90 -mfloat-abi=hard" }
> */
>  /* { dg-final { check-function-bodies "**" "" } } */
> 
>  #include 
> diff --git a/gcc/testsuite/gcc.target/arm/simd/bf16_ma_1.c
> b/gcc/testsuite/gcc.target/arm/simd/bf16_ma_1.c
> index 6729af7..c043049 100644
> --- a/gcc/testsuite/gcc.target/arm/simd/bf16_ma_1.c
> +++ b/gcc/testsuite/gcc.target/arm/simd/bf16_ma_1.c
> @@ -1,7 +1,8 @@
>  /* { dg-do assemble } */
> +/* { dg-require-effective-target arm_hard_ok } */
>  /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
>  /* { dg-add-options arm_v8_2a_bf16_neon } */
> -/* { dg-additional-options "-save-temps -O2" }  */
> +/* { dg-additional-options "-save-temps -O2 -mfloat-abi=hard" }  */
>  /* { dg-final { check-function-bodies "**" "" } } */
> 
>  #include "arm_neon.h"
> diff --git a/gcc/testsuite/gcc.target/arm/simd/bf16_mmla_1.c
> b/gcc/testsuite/gcc.target/arm/simd/bf16_mmla_1.c
> index 5f9c85b..cc64e23 100644
> --- a/gcc/testsuite/gcc.target/arm/simd/bf16_mmla_1.c
> +++ b/gcc/testsuite/gcc.target/arm/simd/bf16_mmla_1.c
> @@ -1,7 +1,8 @@
>  /* { dg-do assemble } */
> +/* { dg-require-effective-target arm_hard_ok } */
>  /* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
>  /* { dg-add-options arm_v8_2a_bf16_neon } */
> -/* { dg-additional-options "-save-temps -O2" } */
> +/* { dg-additional-options "-save-temps -O2 -mfloat-abi=hard" } */
>  /* { dg-final { check-function-bodies "**" "" } } */
> 
>  #include 
> diff --git a/gcc/testsuite/gcc.target/arm/simd/vdot-2-1.c
> b/gcc/testsuite/gcc.target/arm/simd/vdot-2-1.c
> index 4d5f07b..88b80cf 100644
> --- a/gcc/testsuite/gcc.target/arm/simd/vdot-2-1.c
> +++ b/gcc/testsuite/gcc.target/arm/simd/vdot-2-1.c
> @@ -1,7 +1,8 @@
>  /* { dg-do assemble { target { arm*-*-* } } } */
> +/* { dg-require-effective-target arm_hard_ok } */
>  /* { dg-require-effective-target arm

RE: [PATCH 7/8] testsuite/arm: Fix -mfloat-abi order in arm_v8_1m_mve_ok_nocache and arm_v8_1m_mve_fp_ok_nocache

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Gcc-patches  On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 7/8] testsuite/arm: Fix -mfloat-abi order in
> arm_v8_1m_mve_ok_nocache and arm_v8_1m_mve_fp_ok_nocache
> 
> Make the order in which we try -mfloat-abi options consistent with the
> other similar effective targets: try softfp first, then hard.
> 
> This shows that a few tests implicitly rely on -mfloat-abi=hard, so we
> add this option via dg-additional-options so that it comes after any
> potential -mfloat-abi option that the preceding effective-targets
> might have added.
> 
> armv8_1m-fpXX-move-1.c tests don't need arm_hard_ok because they don't
> include arm_mve.h: adding -mfloat-abi=hard when using a soft/softfp
> toolchain does not lead to the missing include gnu/stubs-*.h error.
> 
> This patch makes armv8_1m-fpXX-move-1.c pass on arm-linux-gnueabi, and
> the other tests become unsupported (instead of fail) on this target.
> 
> On arm-eabi with default cpu/fpu/mode and a+rm multilibs, the same
> mve/intrinsics/* tests become unsupported instead of pass because
> arm_hard_ok fails with "selected processor lacks an FPU". Since we
> also override the fpu via dg-options, we'd need another effective
> target (say arm_hard_mve_ok) that would check -mfloat-abi=hard
> -mfpu=auto -march=armv8.1-m.main+mve.fp at the same time. But we have
> already so many arm effective targets, it doesn't seem like a good way
> forward.

Ok.
Thanks,
Kyrill

> 
> 2021-03-19  Christophe Lyon  
> 
>   gcc/testsuite/
>   * lib/target-supports.exp
>   (check_effective_target_arm_v8_1m_mve_fp_ok_nocache): Fix
>   -mfloat-abi= options order.
>   (check_effective_target_arm_v8_1m_mve_ok_nocache): Likewise
>   * gcc.target/arm/mve/intrinsics/mve_vector_float2.c: Add
>   arm_hard_ok effective target and -mfloat-abi=hard additional
>   option.
>   * gcc.target/arm/mve/intrinsics/mve_vector_int.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/mve_vector_uint.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/mve_vector_uint1.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/mve_vector_uint2.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vgetq_lane_s64.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vgetq_lane_u64.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vsetq_lane_s64.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vsetq_lane_u64.c: Likewise.
>   * gcc.target/arm/armv8_1m-fp16-move-1.c: Add -mfloat-abi=hard
>   additional option.
>   * gcc.target/arm/armv8_1m-fp32-move-1.c: Likewise.
>   * gcc.target/arm/armv8_1m-fp64-move-1.c: Likewise.
> ---
>  gcc/testsuite/gcc.target/arm/armv8_1m-fp16-move-1.c | 3 ++-
>  gcc/testsuite/gcc.target/arm/armv8_1m-fp32-move-1.c | 3 ++-
>  gcc/testsuite/gcc.target/arm/armv8_1m-fp64-move-1.c | 3 ++-
>  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c | 2 ++
>  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c| 2 ++
>  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint.c   | 2 ++
>  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint1.c  | 2 ++
>  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint2.c  | 2 ++
>  gcc/testsuite/gcc.target/arm/mve/intrinsics/vgetq_lane_s64.c| 3 ++-
>  gcc/testsuite/gcc.target/arm/mve/intrinsics/vgetq_lane_u64.c| 3 ++-
>  gcc/testsuite/gcc.target/arm/mve/intrinsics/vsetq_lane_s64.c| 3 ++-
>  gcc/testsuite/gcc.target/arm/mve/intrinsics/vsetq_lane_u64.c| 3 ++-
>  gcc/testsuite/lib/target-supports.exp   | 4 ++--
>  13 files changed, 26 insertions(+), 9 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/armv8_1m-fp16-move-1.c
> b/gcc/testsuite/gcc.target/arm/armv8_1m-fp16-move-1.c
> index 67a9f41..f5ab6e7 100644
> --- a/gcc/testsuite/gcc.target/arm/armv8_1m-fp16-move-1.c
> +++ b/gcc/testsuite/gcc.target/arm/armv8_1m-fp16-move-1.c
> @@ -1,7 +1,8 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O -mfloat-abi=hard -mfp16-format=ieee" } */
> +/* { dg-options "-O -mfp16-format=ieee" } */
>  /* { dg-require-effective-target arm_v8_1m_mve_ok } */
>  /* { dg-add-options arm_v8_1m_mve } */
> +/* { dg-additional-options "-mfloat-abi=hard" } *
>  /* { dg-final { check-function-bodies "**" "" } } */
> 
>  /*
> diff --git a/gcc/testsuite/gcc.target/arm/armv8_1m-fp32-move-1.c
> b/gcc/testsuite/gcc.target/arm/armv8_1m-fp32-move-1.c
> index 1ecb839..2f62e839 100644
> --- a/gcc/testsuite/gcc.target/arm/armv8_1m-fp32-move-1.c
> +++ b/gcc/testsuite/gcc.target/arm/armv8_1m-fp32-move-1.c
> @@ -1,7 +1,8 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O -mfloat-abi=hard" } */
> +/* { dg-options "-O" } */
>  /* { dg-require-effective-target arm_v8_1m_mve_ok } */
>  /* { dg-add-options arm_v8_1m_mve } */
> +/* { dg-additional-options "-mfloat-abi=hard" } *
>  /* { dg-final { check-function-bodies "**" "" 

RE: [PATCH 8/8] testsuite/arm: Add arm_dsp_ok effective target and use it in arm/acle/dsp_arith.c

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Gcc-patches  On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 8/8] testsuite/arm: Add arm_dsp_ok effective target and
> use it in arm/acle/dsp_arith.c
> 
> gcc.target/arm/acle/dsp_arith.c uses DSP intrinsics, which arm_acle.h
> defines only with __ARM_FEATURE_DSP, so make the test check for that
> property rather than arm_qbit_ok.
> 
> However, the existing arm_dsp effective target only checks if DSP
> features are supported with the current multilib rather than trying
> -march and -mfloat-abi options. Thus we introduce a similar effective
> target, arm_dsp_ok and associated dg-add-options.
> 
> This makes dsp_arith.c unsupported rather than failed when no option
> combination is suitable, for instance when running the tests with
> -mcpu=cortex-m3.

Ok.
Thanks for working on these,
Kyrill

> 
> 2021-03-19  Christophe Lyon  
> 
>   gcc/
>   * doc/sourcebuild.texi (arm_dsp_ok, arm_dsp): Document.
> 
>   gcc/testsuite/
>   * lib/target-supports.exp
>   (check_effective_target_arm_dsp_ok_nocache)
>   (check_effective_target_arm_dsp_ok, add_options_for_arm_dsp):
> New.
>   * gcc.target/arm/acle/dsp_arith.c: Use arm_dsp_ok effective target
>   and add arm_dsp options.
> ---
>  gcc/doc/sourcebuild.texi  | 11 
>  gcc/testsuite/gcc.target/arm/acle/dsp_arith.c |  4 +--
>  gcc/testsuite/lib/target-supports.exp | 40
> +++
>  3 files changed, 53 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> index 1fa3656..2bc362b 100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -2044,6 +2044,12 @@ ARM Target supports options suitable for
> accessing the Q-bit manipulation
>  intrinsics from @code{arm_acle.h}.
>  Some multilibs may be incompatible with these options.
> 
> +@item arm_dsp_ok
> +@anchor{arm_dsp_ok}
> +ARM Target supports options suitable for accessing the DSP intrinsics
> +from @code{arm_acle.h}.
> +Some multilibs may be incompatible with these options.
> +
>  @item arm_softfp_ok
>  @anchor{arm_softfp_ok}
>  ARM target supports the @code{-mfloat-abi=softfp} option.
> @@ -2778,6 +2784,11 @@ Add options to enable generation of the
> @code{VFMAL} and @code{VFMSL}
>  instructions, if this is supported by the target; see the
>  @ref{arm_fp16fml_neon_ok} effective target keyword.
> 
> +@item arm_dsp
> +Add options for ARM DSP intrinsics support, if this is supported by
> +the target; see the @ref{arm_dsp_ok,,arm_dsp_ok effective target
> +keyword}.
> +
>  @item bind_pic_locally
>  Add the target-specific flags needed to enable functions to bind
>  locally when using pic/PIC passes in the testsuite.
> diff --git a/gcc/testsuite/gcc.target/arm/acle/dsp_arith.c
> b/gcc/testsuite/gcc.target/arm/acle/dsp_arith.c
> index 9ebd55a..7bf458e 100644
> --- a/gcc/testsuite/gcc.target/arm/acle/dsp_arith.c
> +++ b/gcc/testsuite/gcc.target/arm/acle/dsp_arith.c
> @@ -1,6 +1,6 @@
>  /* { dg-do compile } */
> -/* { dg-require-effective-target arm_qbit_ok } */
> -/* { dg-add-options arm_qbit  } */
> +/* { dg-require-effective-target arm_dsp_ok } */
> +/* { dg-add-options arm_dsp } */
> 
>  #include 
> 
> diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-
> supports.exp
> index 1af7619..733b6c8 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -4200,6 +4200,46 @@ proc add_options_for_arm_qbit { flags } {
>  return "$flags $et_arm_qbit_flags"
>  }
> 
> +# Return 1 if this is an ARM target supporting the DSP intrinsics from
> +# arm_acle.h.  Some multilibs may be incompatible with these options.
> +# Also set et_arm_dsp_flags to the best options to add.
> +# arm_acle.h includes stdint.h which can cause trouble with incompatible
> +# -mfloat-abi= options.
> +# check_effective_target_arm_dsp also exists, which checks the current
> +# multilib, without trying other options.
> +
> +proc check_effective_target_arm_dsp_ok_nocache { } {
> +global et_arm_dsp_flags
> +set et_arm_dsp_flags ""
> +foreach flags {"" "-march=armv5te" "-march=armv5te -mfloat-
> abi=softfp" "-march=armv5te -mfloat-abi=hard"} {
> +  if { [check_no_compiler_messages_nocache et_arm_dsp_ok object {
> + #include 
> + int dummy;
> + #ifndef __ARM_FEATURE_DSP
> + #error not DSP
> + #endif
> +  } "$flags"] } {
> + set et_arm_dsp_flags $flags
> + return 1
> +  }
> +}
> +
> +  return 0
> +}
> +
> +proc check_effective_target_arm_dsp_ok { } {
> +return [check_cached_effective_target et_arm_dsp_flags \
> + check_effective_target_arm_dsp_ok_nocache]
> +}
> +
> +proc add_options_for_arm_dsp { flags } {
> +if { ! [check_effective_target_arm_dsp_ok] } {
> + return "$flags"
> +}
> +global et_arm_dsp_flags
> +return "$flags $et_arm_dsp_flags

[committed] libstdc++: Disable "ALT128" long double support for Clang

[Jonathan Wakely via Gcc-patches]

Clang does not currently support the __ibm128 type [1] and only supports
the __ieee128 type in the unreleased 12.0.0 version [2]. That means it
is not possible to provide support for -mabi=ieeelongdouble with Clang
in an ABI compatible way (as we do for GCC by defining new facets and
other types in the __gnu_cxx_ldbl128 namespace).

By preventing the definition of _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT when
compiling with Clang, all uses of __ibm128 and __ieee128 types will be
disabled. This can be revisited in future when Clang supports the types
(and provides a way to detect that support using the preprocessor).

[1] https://reviews.llvm.org/D93377
[2] https://reviews.llvm.org/D97846

libstdc++-v3/ChangeLog:

* include/bits/c++config (_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT):
Do not define when compiling with Clang.

Tested powerpc64le-linux. Committed to trunk.

commit baef0cffb58be7f5d9aeac6313ea9d8becc017b1
Author: Jonathan Wakely 
Date:   Tue Mar 23 13:08:32 2021

libstdc++: Disable "ALT128" long double support for Clang

Clang does not currently support the __ibm128 type [1] and only supports
the __ieee128 type in the unreleased 12.0.0 version [2]. That means it
is not possible to provide support for -mabi=ieeelongdouble with Clang
in an ABI compatible way (as we do for GCC by defining new facets and
other types in the __gnu_cxx_ldbl128 namespace).

By preventing the definition of _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT when
compiling with Clang, all uses of __ibm128 and __ieee128 types will be
disabled. This can be revisited in future when Clang supports the types
(and provides a way to detect that support using the preprocessor).

[1] https://reviews.llvm.org/D93377
[2] https://reviews.llvm.org/D97846

libstdc++-v3/ChangeLog:

* include/bits/c++config (_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT):
Do not define when compiling with Clang.

diff --git a/libstdc++-v3/include/bits/c++config 
b/libstdc++-v3/include/bits/c++config
index b57ff339990..72ec91949de 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -425,9 +425,12 @@ _GLIBCXX_END_NAMESPACE_VERSION
 // GLIBCXX_ABI Deprecated
 // Define if compatibility should be provided for -mlong-double-64.
 #undef _GLIBCXX_LONG_DOUBLE_COMPAT
+
 // Define if compatibility should be provided for alternative 128-bit long
-// double formats.
+// double formats. Not possible for Clang until __ibm128 is supported.
+#ifndef __clang__
 #undef _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT
+#endif
 
 // Inline namespaces for long double 128 modes.
 #if defined _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT \

Re: [PATCH] c++: Fix bogus warning in deprecated namespace [PR99318]

[Marek Polacek via Gcc-patches]

On Tue, Mar 23, 2021 at 09:05:42AM -0400, Jason Merrill via Gcc-patches wrote:
> On 3/9/21 10:22 PM, Marek Polacek wrote:
> > In GCC 10, I introduced cp_warn_deprecated_use_scopes so that we can
> > handle attribute deprecated on a namespace declaration.  This
> > function walks the decl's contexts so that we warn for code like
> > 
> >namespace [[deprecated]] N { struct S { }; }
> >N::S s;
> > 
> > We call cp_warn_deprecated_use_scopes when we encounter a TYPE_DECL.
> 
> Hmm, I'd think we should warn about N as a consequence of seeing N::, not
> because we are using S.  For instance, in
> 
> namespace [[deprecated]] N { struct S { }; }
> using namespace N;
> S s;
> 
> we should warn about the using-directive, but not also the declaration of
> 's'.

I agree, opened 99729.

> But the patch is OK, that's just a possible future direction.

Thanks, pushed.

Marek

Re: [PATCH 8/8] testsuite/arm: Add arm_dsp_ok effective target and use it in arm/acle/dsp_arith.c

[Christophe Lyon via Gcc-patches]

On Tue, 23 Mar 2021 at 15:59, Kyrylo Tkachov  wrote:
>
>
>
> > -Original Message-
> > From: Gcc-patches  On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 23 March 2021 14:33
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH 8/8] testsuite/arm: Add arm_dsp_ok effective target and
> > use it in arm/acle/dsp_arith.c
> >
> > gcc.target/arm/acle/dsp_arith.c uses DSP intrinsics, which arm_acle.h
> > defines only with __ARM_FEATURE_DSP, so make the test check for that
> > property rather than arm_qbit_ok.
> >
> > However, the existing arm_dsp effective target only checks if DSP
> > features are supported with the current multilib rather than trying
> > -march and -mfloat-abi options. Thus we introduce a similar effective
> > target, arm_dsp_ok and associated dg-add-options.
> >
> > This makes dsp_arith.c unsupported rather than failed when no option
> > combination is suitable, for instance when running the tests with
> > -mcpu=cortex-m3.
>
> Ok.
> Thanks for working on these,

Pushed, thanks for the quick review!

> Kyrill
>
> >
> > 2021-03-19  Christophe Lyon  
> >
> >   gcc/
> >   * doc/sourcebuild.texi (arm_dsp_ok, arm_dsp): Document.
> >
> >   gcc/testsuite/
> >   * lib/target-supports.exp
> >   (check_effective_target_arm_dsp_ok_nocache)
> >   (check_effective_target_arm_dsp_ok, add_options_for_arm_dsp):
> > New.
> >   * gcc.target/arm/acle/dsp_arith.c: Use arm_dsp_ok effective target
> >   and add arm_dsp options.
> > ---
> >  gcc/doc/sourcebuild.texi  | 11 
> >  gcc/testsuite/gcc.target/arm/acle/dsp_arith.c |  4 +--
> >  gcc/testsuite/lib/target-supports.exp | 40
> > +++
> >  3 files changed, 53 insertions(+), 2 deletions(-)
> >
> > diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> > index 1fa3656..2bc362b 100644
> > --- a/gcc/doc/sourcebuild.texi
> > +++ b/gcc/doc/sourcebuild.texi
> > @@ -2044,6 +2044,12 @@ ARM Target supports options suitable for
> > accessing the Q-bit manipulation
> >  intrinsics from @code{arm_acle.h}.
> >  Some multilibs may be incompatible with these options.
> >
> > +@item arm_dsp_ok
> > +@anchor{arm_dsp_ok}
> > +ARM Target supports options suitable for accessing the DSP intrinsics
> > +from @code{arm_acle.h}.
> > +Some multilibs may be incompatible with these options.
> > +
> >  @item arm_softfp_ok
> >  @anchor{arm_softfp_ok}
> >  ARM target supports the @code{-mfloat-abi=softfp} option.
> > @@ -2778,6 +2784,11 @@ Add options to enable generation of the
> > @code{VFMAL} and @code{VFMSL}
> >  instructions, if this is supported by the target; see the
> >  @ref{arm_fp16fml_neon_ok} effective target keyword.
> >
> > +@item arm_dsp
> > +Add options for ARM DSP intrinsics support, if this is supported by
> > +the target; see the @ref{arm_dsp_ok,,arm_dsp_ok effective target
> > +keyword}.
> > +
> >  @item bind_pic_locally
> >  Add the target-specific flags needed to enable functions to bind
> >  locally when using pic/PIC passes in the testsuite.
> > diff --git a/gcc/testsuite/gcc.target/arm/acle/dsp_arith.c
> > b/gcc/testsuite/gcc.target/arm/acle/dsp_arith.c
> > index 9ebd55a..7bf458e 100644
> > --- a/gcc/testsuite/gcc.target/arm/acle/dsp_arith.c
> > +++ b/gcc/testsuite/gcc.target/arm/acle/dsp_arith.c
> > @@ -1,6 +1,6 @@
> >  /* { dg-do compile } */
> > -/* { dg-require-effective-target arm_qbit_ok } */
> > -/* { dg-add-options arm_qbit  } */
> > +/* { dg-require-effective-target arm_dsp_ok } */
> > +/* { dg-add-options arm_dsp } */
> >
> >  #include 
> >
> > diff --git a/gcc/testsuite/lib/target-supports.exp 
> > b/gcc/testsuite/lib/target-
> > supports.exp
> > index 1af7619..733b6c8 100644
> > --- a/gcc/testsuite/lib/target-supports.exp
> > +++ b/gcc/testsuite/lib/target-supports.exp
> > @@ -4200,6 +4200,46 @@ proc add_options_for_arm_qbit { flags } {
> >  return "$flags $et_arm_qbit_flags"
> >  }
> >
> > +# Return 1 if this is an ARM target supporting the DSP intrinsics from
> > +# arm_acle.h.  Some multilibs may be incompatible with these options.
> > +# Also set et_arm_dsp_flags to the best options to add.
> > +# arm_acle.h includes stdint.h which can cause trouble with incompatible
> > +# -mfloat-abi= options.
> > +# check_effective_target_arm_dsp also exists, which checks the current
> > +# multilib, without trying other options.
> > +
> > +proc check_effective_target_arm_dsp_ok_nocache { } {
> > +global et_arm_dsp_flags
> > +set et_arm_dsp_flags ""
> > +foreach flags {"" "-march=armv5te" "-march=armv5te -mfloat-
> > abi=softfp" "-march=armv5te -mfloat-abi=hard"} {
> > +  if { [check_no_compiler_messages_nocache et_arm_dsp_ok object {
> > + #include 
> > + int dummy;
> > + #ifndef __ARM_FEATURE_DSP
> > + #error not DSP
> > + #endif
> > +  } "$flags"] } {
> > + set et_arm_dsp_flags $flags
> > + return 1
> > +  }
> > +}
> > +
> > +  return 0
> > +}
> > +
> > +proc check_effective_target_arm_dsp_

Re: [PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation

[Thomas Rodgers]

On 2021-03-22 08:29, Thiago Macieira via Libstdc++ wrote:


Discussion at:
https://gcc.gnu.org/pipermail/libstdc++/2021-February/052043.html

This patch set includes the uncontroversial parts that improve
performance but don't otherwise change ABI.

Please note we still need to decide on how to deal with the future ABI
break.

Thiago Macieira (3):
Atomic __platform_wait: accept any 32-bit type, not just int
std::latch: reduce internal implementation from ptrdiff_t to int
barrier: optimise by not having the hasher in a loop

libstdc++-v3/include/bits/atomic_wait.h |  7 ---
libstdc++-v3/include/std/barrier| 10 +-
libstdc++-v3/include/std/latch  |  4 ++--
3 files changed, 11 insertions(+), 10 deletions(-)


ping?


I will be submitting a new patch for the 
atomic.wait/barrier/latch/semaphore functionality a bit later today that 
subsumes the changes to atomic_wait and latch, and includes the changes 
to barrier.

Re: [PATCH] Complete __gnu_debug::basic_string

[Jonathan Wakely via Gcc-patches]

On 20/03/21 22:32 +0100, François Dumont wrote:
Following your feedback here is the simplified version. I grouped it 
with the patch I submitted before.



On 19/03/21 8:41 pm, Jonathan Wakely wrote:

On 16/03/21 21:55 +0100, François Dumont via Libstdc++ wrote:

Following:

https://gcc.gnu.org/pipermail/libstdc++/2021-March/052158.html

Here is the patch to complete __gnu_debug::basic_string support. 
Contrarily to what I thought code in std::basic_string to generate 
a basic_string_view works just fine for __gnu_debug::basic_string.


    libstdc++: [_GLIBCXX_DEBUG] Add __gnu_debug 
u8string/u16string/u32string


    Complete __gnu_debug::basic_string support so that it can be 
used as a

    transparent replacement of std::basic_string.

    libstdc++-v3/ChangeLog:

    * include/debug/string
    (basic_string(const _CharT*, const _Allocator&)): 
Remove assign call.
    (basic_string<>::insert(const_iterator, _InputIte, 
_InputIte)): Try to

    remove iterator debug layer even if !_GLIBCXX_USE_CXX11_ABI.
    [_GLIBCXX_USE_CHAR8_T] (__gnu_debug::u8string): New.
    (__gnu_debug::u16string, __gnu_debug::u32string): New.
[!_GLIBCXX_COMPATIBILITY_CXX0X](std::hash<__gnu_debug::string>): New.
[!_GLIBCXX_COMPATIBILITY_CXX0X][_GLIBCXX_USE_WCHAR_T](std::hash<__gnu_debug::wstring>): 
New.

[_GLIBCXX_USE_CHAR8_T](std::hash<__gnu_debug::u8string>): New.
    (std::hash<__gnu_debug::u16string>): New.
    (std::hash<__gnu_debug::u32string>): New.
    * 
testsuite/21_strings/basic_string/hash/hash_char8_t.cc: Adapt for

    __gnu_debug basic_string.

Tested under Linux x86_64.

Ok to commit ?

François



diff --git a/libstdc++-v3/include/debug/string 
b/libstdc++-v3/include/debug/string

index d6eb5280ade..dec23f6277b 100644
--- a/libstdc++-v3/include/debug/string
+++ b/libstdc++-v3/include/debug/string
@@ -41,6 +41,14 @@
    __gnu_debug::_Error_formatter::_S_at(_File, _Line, _Func)    \
  ._M_message(#_Cond)._M_error()

+#if _GLIBCXX_USE_CXX11_ABI && __cplusplus >= 201103
+# define _GLIBCXX_CPP11_AND_CXX11_ABI 1
+# define _GLIBCXX_CPP11_AND_CXX11_ABI_ONLY(Statement) Statement


This takes an expression, not a statement.


I've been inspired by _GLIBCXX_DEBUG_ONLY


Which is generally used with complete statements, not just
expressions. See _GLIBCXX20_ONLY which is used for expressions, and
uses __expr for the argument name.



I think it would be better to use more descriptive names for these:

# define _GLIBCXX_INSERT_RETURNS_ITERATOR 1
# define _GLIBCXX_INSERT_RETURNS_ITERATOR_ONLY(expr) expr

(And don't forget to change the #undef lines too).


+#if __cplusplus >= 201103L
+
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+  // DR 1182.
+
+#ifndef _GLIBCXX_COMPATIBILITY_CXX0X
+  /// std::hash specialization for string.
+  template<>
+    struct hash<__gnu_debug::string>
+    : public __hash_base


I think we could just define on partial specialization that works for
all cases:


Yes, sounds better. But I relied on std::__hash_base which gives 
directly the correct definition.


But that is wrong.

The requirements in https://wg21.link/unord.hash say that std::hash
must be disabled for unsupported types. With std::basic_string the
specialization std::hash> is disabled, because there
is no specialization for that type, so it uses the primary template of
std::hash, which is empty:

  /// Primary class template hash, usable for enum types only.
  // Use with non-enum types still SFINAES.
  template
struct hash : __hash_enum<_Tp>
{ };

With your patch, std::hash<__gnu_debug::basic_string> will not be
empty. It will provide argument_type and result_type and operator()
but calling operator() will fail to compile.

My suggestion doesn't have that problem. With my suggestion,
hash<_gnu_debug::basic_string> is enabled if (and only if)
hash> is enabled.


Why only make this change for the char8_t version? Why not test
hash<__gnu_debug::string> as well?


This file also test std::string and so also __gnu_debug::string.


Ah yes.


    libstdc++: Fix and complete __gnu_debug::basic_string implementation

    Fix and complete __gnu_debug::basic_string so that it can be used 
as a transparent

    replacement of std::basic_string.

    libstdc++-v3/ChangeLog:

    * include/debug/string
    (basic_string(const _CharT*, const _Allocator&)): Remove 
assign call.
    (basic_string<>::insert(const_iterator, _InputIte, 
_InputIte)): Try to

    remove iterator debug layer even if !_GLIBCXX_USE_CXX11_ABI.
    [_GLIBCXX_USE_CHAR8_T] (__gnu_debug::u8string): New.
    (__gnu_debug::u16string, __gnu_debug::u32string): New.
    (std::hash<__gnu_debug::basic_string<>>): New partial 
specialization.

(std::__is_fast_hash<__gnu_debug::basic_string<>>): Likewise.
    (basic_string(const basic_string&, const _Alloc&)): Define 
even if !_GLIBCXX_USE_CXX

Re: [PATCH] libstdc++: Avoid accidental ADL when calling make_reverse_iterator

[Jonathan Wakely via Gcc-patches]

On 03/03/21 20:26 +0100, Moritz Sichert via Libstdc++ wrote:

Thanks for the review. I attached the updated patch.

Can you commit this for me or point me to what I should do next? This is my 
first contribution here.


I was about to do this, but ...


+namespace test_ns
+{
+  struct A {};
+  template 
+  void make_reverse_iterator(T&&) {}
+} // namespace test_ns
+
+void test()
+{
+  test_ns::A as[] = {{}, {}};
+  auto v = as | std::views::reverse;
+  static_assert(std::ranges::view);
+  static_assert(std::ranges::view);


Was this tested? A view must be movable, which requires
move-assignable. You can't assign to a const view, so const
decltype(v) does not model movable so does not model view.

Re: [PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation

[Thiago Macieira via Gcc-patches]

On Tuesday, 23 March 2021 08:39:43 PDT Thomas Rodgers wrote:
> I will be submitting a new patch for the
> atomic.wait/barrier/latch/semaphore functionality a bit later today that
> subsumes the changes to atomic_wait and latch, and includes the changes
> to barrier.

Thanks, Thomas

Is that meant to be part of GCC 11's release?

If not, what do we do about preventing the future BC break and potential 
heisenbugs?

 1) do nothing, accept they will happen silently
 2) cause non-silent BC breaks
 3) disable the code for now (unless explicitly opted-in)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering

[PATCH][PR94156] Split COMDAT groups on target that do not support them

[Markus Böck via Gcc-patches]

GCC at the moment uses COMDAT groups for things like virtual thunks,
even on targets that do not support COMDAT groups. This has not been a
problem as on platforms not supporting these (such as PE COFF on
Windows), the backend handled it through directives to GAS. GCC would
simply use a .linkonce directive telling the assembler that this
symbol may occur multiple times, and GAS would translate that into a
"select any" COMDAT, containing only the symbol itself (as Windows
does support COMDAT, just not groups).

When using LTO on Windows however, a few problems occur: The COMDAT
group is transmitted as part of the IR and the linker (ld) will try to
resolve symbols. On Windows the COMDAT information is put into the
symbol table, instead of in sections, leading to the linker to error
out with a multiple reference error before even calling the
lto-wrapper and LTRANS on the IR, which would otherwise resolve the
use of COMDAT groups.

This patch removes comdat groups for symbols in the ipa-visibility
pass and instead puts them into their own comdat. An exception to this
rule are aliases which (at least on Windows) are also allowed to be in
the same comdat group as the symbol they are referencing.

This fixes PR94156: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94156
A previous discussion on the problems this patch attempts to fix were
had here: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550148.html

I tested this patch with a x86_64-w64-mingw32 target on a Linux host.
No regressions between before and after of this patch were noted. The
Test cases provided with this patch have been confirmed to reproduce
before this patch, and link and work after the application of the
patch.

Feedback is very welcome, especially on implications I might not be aware of.

gcc/ChangeLog:

2020-03-23  Markus Böck  

* ipa-visibility.c (function_and_variable_visibility): Split
COMDAT groups on targets not supporting them

gcc/testsuite/ChangeLog:

2020-03-23  Markus Böck  

* g++.dg/lto/pr94156.h: New test.
* g++.dg/lto/pr94156_0.C: New test.
* g++.dg/lto/pr94156_1.C: New test.

--
diff --git a/gcc/ipa-visibility.c b/gcc/ipa-visibility.c
index eb0ebf770e3..76f1a8ff72a 100644
--- a/gcc/ipa-visibility.c
+++ b/gcc/ipa-visibility.c
@@ -709,6 +709,14 @@ function_and_variable_visibility (bool whole_program)
  }
node->dissolve_same_comdat_group_list ();
  }
+
+  if (!HAVE_COMDAT_GROUP && node->same_comdat_group
+  && !node->alias && !node->has_aliases_p())
+{
+  node->remove_from_same_comdat_group();
+  node->set_comdat_group(DECL_ASSEMBLER_NAME_RAW(node->decl));
+}
+
   gcc_assert ((!DECL_WEAK (node->decl)
&& !DECL_COMDAT (node->decl))
  || TREE_PUBLIC (node->decl)
@@ -742,8 +750,11 @@ function_and_variable_visibility (bool whole_program)
  {
gcc_checking_assert (DECL_COMDAT (node->decl)
 == DECL_COMDAT (decl_node->decl));
-   gcc_checking_assert (node->in_same_comdat_group_p (decl_node));
-   gcc_checking_assert (node->same_comdat_group);
+   if (HAVE_COMDAT_GROUP)
+{
+  gcc_checking_assert (node->in_same_comdat_group_p
(decl_node));
+  gcc_checking_assert (node->same_comdat_group);
+}
  }
node->forced_by_abi = decl_node->forced_by_abi;
if (DECL_EXTERNAL (decl_node->decl))
diff --git a/gcc/testsuite/g++.dg/lto/pr94156.h
b/gcc/testsuite/g++.dg/lto/pr94156.h
new file mode 100644
index 000..3990ac46fcb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lto/pr94156.h
@@ -0,0 +1,20 @@
+class Base0 {
+public:
+  virtual ~Base0() {}
+};
+
+class Base1 {
+public:
+  virtual void foo() = 0;
+};
+
+class Base2 {
+public:
+  virtual void foo() = 0;
+};
+
+class Derived : public Base0, public Base1, public Base2 {
+public:
+  virtual ~Derived();
+  virtual void foo() override {}
+};
diff --git a/gcc/testsuite/g++.dg/lto/pr94156_0.C
b/gcc/testsuite/g++.dg/lto/pr94156_0.C
new file mode 100644
index 000..1a2e30badc7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lto/pr94156_0.C
@@ -0,0 +1,6 @@
+// { dg-lto-do link }
+#include "pr94156.h"
+
+Derived::~Derived() {}
+
+int main() {}
diff --git a/gcc/testsuite/g++.dg/lto/pr94156_1.C
b/gcc/testsuite/g++.dg/lto/pr94156_1.C
new file mode 100644
index 000..d7a40efa96c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lto/pr94156_1.C
@@ -0,0 +1,6 @@
+#include "pr94156.h"
+
+void bar(Derived* p)
+{
+  p->foo();
+}

Re: [PATCH 0/3] Uncontroversial improvements to C++20 wait-related implementation

[Jonathan Wakely via Gcc-patches]

On 23/03/21 09:26 -0700, Thiago Macieira via Libstdc++ wrote:

On Tuesday, 23 March 2021 08:39:43 PDT Thomas Rodgers wrote:

I will be submitting a new patch for the
atomic.wait/barrier/latch/semaphore functionality a bit later today that
subsumes the changes to atomic_wait and latch, and includes the changes
to barrier.


Thanks, Thomas

Is that meant to be part of GCC 11's release?


Yes.


If not, what do we do about preventing the future BC break and potential
heisenbugs?

1) do nothing, accept they will happen silently


This is our current policy for experimental features and it isn't
going to change for GCC 11.



2) cause non-silent BC breaks
3) disable the code for now (unless explicitly opted-in)

--
Thiago Macieira - thiago.macieira (AT) intel.com
 Software Architect - Intel DPG Cloud Engineering

Re: [PATCH, rs6000 V2] Update "prefix" attribute for Power10 [PR99133]

[Segher Boessenkool]

Hi!

On Wed, Mar 17, 2021 at 03:49:09PM -0500, Pat Haugen wrote:
> This patch creates a new attribute, prepend_prefixed_insn, which is used to 
> mark
> those instructions that are prefixed and need to have a 'p' prepended to their
> mnemonic at asm emit time. The existing "prefix" attribute is now used to mark
> all instructions that are prefixed form.

But it doesn't.  The "prepend_prefixed_insn" attribute forces the
"prefixed" attribute to be on, whether the insn is prefixed or not.

Please change it so that "prefixed" just means whether the instruction
is prefixed, and a new attribute "maybe_prefixed" that marks the insns
that potentially are prefixed.  Similar to how "var_shift" and
"maybe_var_shift" work.  The default value of "prefixed" can set the
attribute to either "yes" if "maybe_prefixed" is set, and the insn
should get a "p" mnemonic.

Btw, attributes describe some property of insns.  They do not say what
any particular part of the compiler should do with the insns.

> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -26283,7 +26283,8 @@ static bool prepend_p_to_next_insn;
>  void
>  rs6000_final_prescan_insn (rtx_insn *insn, rtx [], int)
>  {
> -  prepend_p_to_next_insn = (get_attr_prefixed (insn) != PREFIXED_NO);
> +  prepend_p_to_next_insn = (get_attr_prepend_prefixed_insn (insn)
> + == PREPEND_PREFIXED_INSN_YES);
>return;
>  }

But the new attribute here is set if the insn *can* be prefixed, not if
it *is*.

> --- a/gcc/config/rs6000/sync.md
> +++ b/gcc/config/rs6000/sync.md
> @@ -132,9 +132,10 @@ (define_insn "load_quadpti"
>"lq %0,%1"
>[(set_attr "type" "load")
> (set_attr "size" "128")
> -   (set (attr "prefixed") (if_then_else (match_test "TARGET_PREFIXED")
> - (const_string "yes")
> - (const_string "no")))])
> +   (set (attr "prepend_prefixed_insn")
> + (if_then_else (match_test "TARGET_PREFIXED")
> +   (const_string "yes")
> +   (const_string "no")))])

(bad whitespace)

I don't think this is correct.  We need to force the use of "plq" here
(for LE only actually, that should be fixed some day).  Maybe we should
have a separate instruction pattern for it, even, since its semantics
differ very significantly :-)


Segher

Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64

[Vladimir Makarov via Gcc-patches]

On 2021-03-23 9:07 a.m., Christophe Lyon wrote:

On Mon, 22 Mar 2021 at 18:38, Vladimir Makarov via Gcc-patches
 wrote:



Hi,

This patch causes regressions (116) on aarch64:
gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp
 gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
check-function-bodies ld1ro_bf16_112
 gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
check-function-bodies ld1ro_bf16_16
 gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
check-function-bodies ld1ro_bf16_index
 gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
check-function-bodies ld1ro_bf16_m128
 gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
-fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
check-function-bodies ld1ro_bf16_m16
[]

Not sure why you didn't see them during your testing?

Can you check?

Sorry, I've rerun (cd gcc && make check-gcc) on gcc114 for today trunk 
and I don't see the regressions mentioned above.


Can you check this too and if I am doing something wrong for testing, 
please point me out.

Re: [PATCH] libstdc++: Avoid accidental ADL when calling make_reverse_iterator

[Jonathan Wakely via Gcc-patches]

On 23/03/21 16:25 +, Jonathan Wakely wrote:

On 03/03/21 20:26 +0100, Moritz Sichert via Libstdc++ wrote:

Thanks for the review. I attached the updated patch.

Can you commit this for me or point me to what I should do next? This is my 
first contribution here.


I was about to do this, but ...


+namespace test_ns
+{
+  struct A {};
+  template 
+  void make_reverse_iterator(T&&) {}
+} // namespace test_ns
+
+void test()
+{
+  test_ns::A as[] = {{}, {}};
+  auto v = as | std::views::reverse;
+  static_assert(std::ranges::view);
+  static_assert(std::ranges::view);


Was this tested? A view must be movable, which requires
move-assignable. You can't assign to a const view, so const
decltype(v) does not model movable so does not model view.


Here's what I've committed. Thanks for the bugfix.


commit 09f08fef71fb776a1d850a7b854c7ccf8a3d6c11
Author: Moritz Sichert 
Date:   Tue Mar 23 15:47:37 2021

libstdc++: Avoid accidental ADL when calling make_reverse_iterator

std::ranges::reverse_view uses make_reverse_iterator in its
implementation as described in [range.reverse.view]. This accidentally
allows ADL as an unqualified name is used in the call. According to
[contents], however, this should be treated as a qualified lookup into
the std namespace.

This leads to errors due to ambiguous name lookups when another
make_reverse_iterator function is found via ADL.

libstdc++-v3/Changelog:

* include/std/ranges (reverse_view::begin, reverse_view::end):
Qualify make_reverse_iterator calls to avoid ADL.
* testsuite/std/ranges/adaptors/reverse.cc: Test that
views::reverse works when make_reverse_iterator is defined
in an associated namespace.

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 1be74beb860..adbc6d7b274 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -2958,29 +2958,29 @@ namespace views
   {
 	if constexpr (_S_needs_cached_begin)
 	  if (_M_cached_begin._M_has_value())
-	return make_reverse_iterator(_M_cached_begin._M_get(_M_base));
+	return std::make_reverse_iterator(_M_cached_begin._M_get(_M_base));
 
 	auto __it = ranges::next(ranges::begin(_M_base), ranges::end(_M_base));
 	if constexpr (_S_needs_cached_begin)
 	  _M_cached_begin._M_set(_M_base, __it);
-	return make_reverse_iterator(std::move(__it));
+	return std::make_reverse_iterator(std::move(__it));
   }
 
   constexpr auto
   begin() requires common_range<_Vp>
-  { return make_reverse_iterator(ranges::end(_M_base)); }
+  { return std::make_reverse_iterator(ranges::end(_M_base)); }
 
   constexpr auto
   begin() const requires common_range
-  { return make_reverse_iterator(ranges::end(_M_base)); }
+  { return std::make_reverse_iterator(ranges::end(_M_base)); }
 
   constexpr reverse_iterator>
   end()
-  { return make_reverse_iterator(ranges::begin(_M_base)); }
+  { return std::make_reverse_iterator(ranges::begin(_M_base)); }
 
   constexpr auto
   end() const requires common_range
-  { return make_reverse_iterator(ranges::begin(_M_base)); }
+  { return std::make_reverse_iterator(ranges::begin(_M_base)); }
 
   constexpr auto
   size() requires sized_range<_Vp>
diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/reverse.cc b/libstdc++-v3/testsuite/std/ranges/adaptors/reverse.cc
index 593b77e4a37..47386575192 100644
--- a/libstdc++-v3/testsuite/std/ranges/adaptors/reverse.cc
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/reverse.cc
@@ -131,6 +131,23 @@ test05()
   VERIFY( test_wrapper::increment_count == 5 );
 }
 
+namespace test_ns
+{
+  struct A {};
+  template 
+  void make_reverse_iterator(T&&) {}
+} // namespace test_ns
+
+void test06()
+{
+  // Check that views::reverse works and does not use ADL which could lead
+  // to accidentally finding test_ns::make_reverse_iterator(const A&).
+  test_ns::A as[] = {{}, {}};
+  auto v = as | std::views::reverse;
+  static_assert(std::ranges::view);
+  static_assert(std::ranges::view);
+}
+
 int
 main()
 {
@@ -139,4 +156,5 @@ main()
   test03();
   test04();
   test05();
+  test06();
 }

Re: Ping^2: [PATCH v2] rs6000: Convert the vector element register to SImode [PR98914]

[Segher Boessenkool]

On Thu, Mar 18, 2021 at 05:13:38PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 18, 2021 at 09:27:17AM +0800, Xionghu Luo via Gcc-patches wrote:
> > gcc/ChangeLog:
> > 
> > 2021-03-18  Xionghu Luo  
> > 
> > PR target/98914
> > * config/rs6000/rs6000.c (rs6000_expand_vector_set_var_p9):
> > Convert idx to DImode.
> > (rs6000_expand_vector_set_var_p8): Likewise.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > 2021-03-18  Xionghu Luo  
> > 
> > PR target/98914
> > * gcc.target/powerpc/pr98914.c: New test.
> 
> LGTM.  But please give Segher some time to chime in if he disagrees.

It looks fine to me as well.  Okay for trunk.  Thanks!


Segher

Re: [Patch] Fortran: Fix intrinsic null() handling [PR99651]

[Paul Richard Thomas via Gcc-patches]

Hi Tobias,

I took something of a detour in reviewing this patch. Although short,
understanding it is not straightforward!

Your patch works as advertised and regtests OK (with the patch for PR93660
on board as well). Is NULL the only case where this can happen?
Just to aid my understanding, I tried:
diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index a6df885c80c..f4c43a7c38b 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -3922,6 +3922,9 @@ gfc_match_rvalue (gfc_expr **result)
   if (m == MATCH_NO)
m = MATCH_YES;

+  if (!strcmp (sym->name, "NULL") || !strcmp (sym->name, "null"))
+   sym->attr.intrinsic = 1;
+
   break;

 generic_function:

which also works and regtests OK. (I couldn't remember whether sym->name is
upper or lower case at this stage.)

Thus, I THINK that your patch is OK and haven't managed to find any tests
which it breaks. I'll come back with a more definitive opinion tomorrow.

Paul



On Fri, 19 Mar 2021 at 08:51, Tobias Burnus  wrote:

> See PR for some analysis. The problem is that during
> gfc_intrinsic_func_interface, sym->attr.flavor == FL_PROCEDURE,
> hence, attr.intrinsic is not set – but later when parsing
> 'null()', gfortran calls:
>
>if (sym->attr.proc != PROC_INTRINSIC
>&& !(sym->attr.use_assoc && sym->attr.intrinsic)
>&& (!gfc_add_procedure(&sym->attr, PROC_INTRINSIC, sym->name, NULL)
>|| !gfc_add_function (&sym->attr, sym->name, NULL)))
>  return MATCH_ERROR;
>
> The gfc_add_procedure call fails as 'sym' is use-associated and
> may not be modified.
>
> The obvious solution to also set attr.intrinsic for FL_PROCEDURE fails
> in multiple ways, e.g. for gfortran.dg/char_length_16.f90 which has:
>CHARACTER (LEN(ITEMVAL)) :: ITEM
>INTRINSIC LEN
> the error is that INTRINSIC has been speicified twice. It also affects
> the error diagnostic in for generic resolution due to  (I think):
>if (sym->attr.intrinsic)
>  return gfc_intrinsic_func_interface (expr, 0);
> For gfortran.dg/allocatable_scalar_11.f90 the specific
>‘array’ argument of ‘allocated’ intrinsic at (1) must be a variable
> gets replaced by the generic
>Generic function 'allocated' at (1) is not consistent with a specific
> intrinsic interface
>
> I have now tried it as shown. I think attr.function was not set, but
> am not sure. But setting it again for FL_PROCEDURE looks sensible.
>
> I am far from certain that now everything fits together, but I do hope
> that nothing fails which did work before ...
>
> OK for mainline? And after waiting a while for GCC 10?
>
> Tobias
>
> PS: I did see once a fail for pr93792.f90 (additional error as 't' in
> type(t)
> is not known) – but I could not reproduce it; the error is valid but later
> runs
> stopped with 'cannot open module file' and did not reach that follow-up
> error.
>
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
> Thürauf
>


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

Re: [Patch] Fortran: Fix intrinsic null() handling [PR99651]

[Paul Richard Thomas via Gcc-patches]

Cancel the thought on my patchlet null_5.f90 fails on excess errors.

Paul


On Tue, 23 Mar 2021 at 17:34, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:

> Hi Tobias,
>
> I took something of a detour in reviewing this patch. Although short,
> understanding it is not straightforward!
>
> Your patch works as advertised and regtests OK (with the patch for PR93660
> on board as well). Is NULL the only case where this can happen?
> Just to aid my understanding, I tried:
> diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
> index a6df885c80c..f4c43a7c38b 100644
> --- a/gcc/fortran/primary.c
> +++ b/gcc/fortran/primary.c
> @@ -3922,6 +3922,9 @@ gfc_match_rvalue (gfc_expr **result)
>if (m == MATCH_NO)
> m = MATCH_YES;
>
> +  if (!strcmp (sym->name, "NULL") || !strcmp (sym->name, "null"))
> +   sym->attr.intrinsic = 1;
> +
>break;
>
>  generic_function:
>
> which also works and regtests OK. (I couldn't remember whether sym->name
> is upper or lower case at this stage.)
>
> Thus, I THINK that your patch is OK and haven't managed to find any tests
> which it breaks. I'll come back with a more definitive opinion tomorrow.
>
> Paul
>
>
>
> On Fri, 19 Mar 2021 at 08:51, Tobias Burnus 
> wrote:
>
>> See PR for some analysis. The problem is that during
>> gfc_intrinsic_func_interface, sym->attr.flavor == FL_PROCEDURE,
>> hence, attr.intrinsic is not set – but later when parsing
>> 'null()', gfortran calls:
>>
>>if (sym->attr.proc != PROC_INTRINSIC
>>&& !(sym->attr.use_assoc && sym->attr.intrinsic)
>>&& (!gfc_add_procedure(&sym->attr, PROC_INTRINSIC, sym->name, NULL)
>>|| !gfc_add_function (&sym->attr, sym->name, NULL)))
>>  return MATCH_ERROR;
>>
>> The gfc_add_procedure call fails as 'sym' is use-associated and
>> may not be modified.
>>
>> The obvious solution to also set attr.intrinsic for FL_PROCEDURE fails
>> in multiple ways, e.g. for gfortran.dg/char_length_16.f90 which has:
>>CHARACTER (LEN(ITEMVAL)) :: ITEM
>>INTRINSIC LEN
>> the error is that INTRINSIC has been speicified twice. It also affects
>> the error diagnostic in for generic resolution due to  (I think):
>>if (sym->attr.intrinsic)
>>  return gfc_intrinsic_func_interface (expr, 0);
>> For gfortran.dg/allocatable_scalar_11.f90 the specific
>>‘array’ argument of ‘allocated’ intrinsic at (1) must be a variable
>> gets replaced by the generic
>>Generic function 'allocated' at (1) is not consistent with a specific
>> intrinsic interface
>>
>> I have now tried it as shown. I think attr.function was not set, but
>> am not sure. But setting it again for FL_PROCEDURE looks sensible.
>>
>> I am far from certain that now everything fits together, but I do hope
>> that nothing fails which did work before ...
>>
>> OK for mainline? And after waiting a while for GCC 10?
>>
>> Tobias
>>
>> PS: I did see once a fail for pr93792.f90 (additional error as 't' in
>> type(t)
>> is not known) – but I could not reproduce it; the error is valid but
>> later runs
>> stopped with 'cannot open module file' and did not reach that follow-up
>> error.
>>
>> -
>> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
>> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
>> Thürauf
>>
>
>
> --
> "If you can't explain it simply, you don't understand it well enough" -
> Albert Einstein
>


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

Re: [PATCH] libstdc++: Avoid accidental ADL when calling make_reverse_iterator

[Moritz Sichert via Gcc-patches]

Thank you!

You are right. The idea was that the test also tests the const overloads of 
begin() and end() of reverse_view. But the view concept requires movable. 
Maybe, this should just be

static_assert(std::ranges::range);

instead?

The test in the patch now has the same static_assert twice.

Am 23.03.21 um 18:09 schrieb Jonathan Wakely:

On 23/03/21 16:25 +, Jonathan Wakely wrote:

On 03/03/21 20:26 +0100, Moritz Sichert via Libstdc++ wrote:

Thanks for the review. I attached the updated patch.

Can you commit this for me or point me to what I should do next? This is my 
first contribution here.


I was about to do this, but ...


+namespace test_ns
+{
+  struct A {};
+  template 
+  void make_reverse_iterator(T&&) {}
+} // namespace test_ns
+
+void test()
+{
+  test_ns::A as[] = {{}, {}};
+  auto v = as | std::views::reverse;
+  static_assert(std::ranges::view);
+  static_assert(std::ranges::view);


Was this tested? A view must be movable, which requires
move-assignable. You can't assign to a const view, so const
decltype(v) does not model movable so does not model view.


Here's what I've committed. Thanks for the bugfix.






smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Patch] Fortran: Fix intrinsic null() handling [PR99651]

[Tobias Burnus]

Hi Paul,

On 23.03.21 18:34, Paul Richard Thomas wrote:

I took something of a detour in reviewing this patch. Although short,
understanding it is not straightforward!


I concur – and as I wrote both in the patch email and in the PR, it is
not straight forward which message is showing with which setting.

Actually, I think there are many straight-forward ways to fix it
"properly" but they tend to hide some nicer error messages in favour of
a more generic one. Only by taking into account all the diagnostic and
hidden/delayed diagnostic, the patch becomes complex. (-:


Your patch works as advertised and regtests OK (with the patch for
PR93660 on board as well). Is NULL the only case where this can happen?


I am not sure whether any other code would profit form getting one of
the attributes conditionally assigned in intrinsic.c.

Otherwise, I think that's the only code which verifies like that it in
such a way whether an intrinsic function was used. I think the reason
that it does so is because 'null' is turned early during parsing into
EXPR_NULL, which is not a function and, hence, bypasses some of the
later checking code in resolve.c.



Just to aid my understanding, I tried:
diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c

--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -3922,6 +3922,9 @@ gfc_match_rvalue (gfc_expr **result)
   if (m == MATCH_NO)
m = MATCH_YES;

+  if (!strcmp (sym->name, "NULL") || !strcmp (sym->name, "null"))
+   sym->attr.intrinsic = 1;
+
   break;

 generic_function:

which also works and regtests OK. (I couldn't remember whether
sym->name is upper or lower case at this stage.)


Should be always lowercase, I think. But I am also not sure that your
aid-understanding patch will work correctly with 'external null' or a
use-/host-associated/interface 'null' procedure or some array variable.
Inside intrinsic.c, we are at least sure that we did get an intrinsic
function after having passed all intrinsic checks.

Tobias

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

Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64

[Christophe Lyon via Gcc-patches]

On Tue, 23 Mar 2021 at 17:54, Vladimir Makarov  wrote:
>
>
> On 2021-03-23 9:07 a.m., Christophe Lyon wrote:
> > On Mon, 22 Mar 2021 at 18:38, Vladimir Makarov via Gcc-patches
> >  wrote:
> >>
> > Hi,
> >
> > This patch causes regressions (116) on aarch64:
> > gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp
> >  gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
> > -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
> > check-function-bodies ld1ro_bf16_112
> >  gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
> > -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
> > check-function-bodies ld1ro_bf16_16
> >  gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
> > -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
> > check-function-bodies ld1ro_bf16_index
> >  gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
> > -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
> > check-function-bodies ld1ro_bf16_m128
> >  gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c  -std=gnu90 -O2
> > -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL
> > check-function-bodies ld1ro_bf16_m16
> > []
> >
> > Not sure why you didn't see them during your testing?
> >
> > Can you check?
> >
> Sorry, I've rerun (cd gcc && make check-gcc) on gcc114 for today trunk
> and I don't see the regressions mentioned above.
>
> Can you check this too and if I am doing something wrong for testing,
> please point me out.
>

I'm testing with cross-compilers with ST hat, but I'm not the only one
seeing these failures, see gcc-testresults.
Andreas and in Linaro we are both testing native compilers.

These tests are driven by aarch64-sve-acle-asm.exp

Is it possible that the binutils version matters? I'm using 2.34 for
the cross-toolchains.

Christophe

Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64

[Vladimir Makarov via Gcc-patches]

On 2021-03-23 1:55 p.m., Christophe Lyon wrote:

On Tue, 23 Mar 2021 at 17:54, Vladimir Makarov  wrote:


Can you check?

Sorry, I've rerun (cd gcc && make check-gcc) on gcc114 for today trunk
and I don't see the regressions mentioned above.

Can you check this too and if I am doing something wrong for testing,
please point me out.


I'm testing with cross-compilers with ST hat, but I'm not the only one
seeing these failures, see gcc-testresults.
Andreas and in Linaro we are both testing native compilers.

These tests are driven by aarch64-sve-acle-asm.exp

Is it possible that the binutils version matters? I'm using 2.34 for
the cross-toolchains.

Sorry, I looked at the tests in more details.  They require 
aarch64_asm_f64mm and gcc114.fsffrance.org is not that kind of machine.  
Therefore they are not even compiled on this machine. As I understand 
the tests should check the right assembler generation but the tests 
require to be run.


The problem can be in necessity to use more relaxed memory constraints 
for aarch64.


I'll investigate the regressions more.

Re: [PATCH] libstdc++: Avoid accidental ADL when calling make_reverse_iterator

[Jonathan Wakely via Gcc-patches]

On 23/03/21 18:45 +0100, Moritz Sichert via Libstdc++ wrote:

Thank you!

You are right. The idea was that the test also tests the const overloads of 
begin() and end() of reverse_view. But the view concept requires movable. 
Maybe, this should just be

static_assert(std::ranges::range);

instead?


Oops, I mean to delete the second line, not just the 'const' keyword.
But checking that it models range is better.

Also the comment is slightly wrong, it won't call
make_reserve_iterator(const A&) it will call make_reserve_iterator(A*)
or make_reserve_iterator(const A*).

I've committed the attached patch. Thanks again.


commit d1aa5f57db7c14a62e9b7e2a2aa8a9c402a89363
Author: Jonathan Wakely 
Date:   Tue Mar 23 18:22:18 2021

libstdc++: Improve test for views::reverse

libstdc++-v3/ChangeLog:

* testsuite/std/ranges/adaptors/reverse.cc: Replace duplicated
line with a check that uses the const being/end overloads.

diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/reverse.cc b/libstdc++-v3/testsuite/std/ranges/adaptors/reverse.cc
index 47386575192..0d52498e207 100644
--- a/libstdc++-v3/testsuite/std/ranges/adaptors/reverse.cc
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/reverse.cc
@@ -141,11 +141,12 @@ namespace test_ns
 void test06()
 {
   // Check that views::reverse works and does not use ADL which could lead
-  // to accidentally finding test_ns::make_reverse_iterator(const A&).
+  // to accidentally finding test_ns::make_reverse_iterator(A*).
   test_ns::A as[] = {{}, {}};
   auto v = as | std::views::reverse;
-  static_assert(std::ranges::view);
-  static_assert(std::ranges::view);
+  using V = decltype(v);
+  static_assert( std::ranges::view );
+  static_assert( std::ranges::range );
 }
 
 int

Re: [PATCH v3] fwprop: Fix single_use_p calculation

[Ilya Leoshkevich via Gcc-patches]

On Tue, 2021-03-23 at 12:48 +, Richard Sandiford wrote:
> Ilya Leoshkevich  writes:
> > +inline use_info *
> > +set_info::single_nondebug_use () const
> > +{
> > +  use_info *nondebug_insn = single_nondebug_insn_use ();
> > +  if (nondebug_insn)
> > +    return has_phi_uses () ? nullptr : nondebug_insn;
> > +  use_info *phi = single_phi_use ();
> > +  if (phi)
> > +    return has_nondebug_insn_uses() ? nullptr : phi;
> > +  return nullptr;
> 
> Very minor, but I think this is simpler as:
> 
>   if (!has_phi_uses ())
>     return single_nondebug_insn_use ();
>   if (!has_nondebug_insn_uses ())
>     return single_phi_use ();
>   return nullptr;
> 
> OK with that change (or without if you prefer the original).
> Thanks for the fix and for your patience. :-)
> 
> Richard

Retested with the change above and pushed as:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b61461ac7f9bdd0e98145be79423d19b933afaa0

Thanks for all the suggestions!

Best regards,
Ilya

[PATCH] [libstdc++] Refactor/cleanup of atomic wait implementation

[Thomas Rodgers]

From: Thomas Rodgers 

* This patch addresses jwakely's previous feedback.
* This patch also subsumes thiago.macie...@intel.com 's 'Uncontroversial
  improvements to C++20 wait-related implementation'.
* This patch also changes the atomic semaphore implementation to avoid
  checking for any waiters before a FUTEX_WAKE op.

This is a substantial rewrite of the atomic wait/notify (and timed wait
counterparts) implementation.

The previous __platform_wait looped on EINTR however this behavior is
not required by the standard. A new _GLIBCXX_HAVE_PLATFORM_WAIT macro
now controls whether wait/notify are implemented using a platform
specific primitive or with a platform agnostic mutex/condvar. This
patch only supplies a definition for linux futexes. A future update
could add support __ulock_wait/wake on Darwin, for instance.

The members of __waiters were lifted to a new base class. The members
are now arranged such that overall sizeof(__waiters_base) fits in two
cache lines (on platforms with at least 64 byte cache lines). The
definition will also use destructive_interference_size for this if it
is available.

The __waiters type is now specific to untimed waits. Timed waits have a
corresponding __timed_waiters type. Much of the code has been moved from
the previous __atomic_wait() free function to the __waiter_base template
and a __waiter derived type is provided to implement the un-timed wait
operations. A similar change has been made to the timed wait
implementation.

The __atomic_spin code has been extended to take a spin policy which is
invoked after the initial busy wait loop. The default policy is to
return from the spin. The timed wait code adds a timed backoff spinning
policy. The code from  which implements this_thread::sleep_for,
sleep_until has been moved to a new  header
which allows the thread sleep code to be consumed without pulling in the
whole of .

The entry points into the wait/notify code have been restructured to
support either -
   * Testing the current value of the atomic stored at the given address
 and waiting on a notification.
   * Applying a predicate to determine if the wait was satisfied.
The entry points were renamed to make it clear that the wait and wake
operations operate on addresses. The first variant takes the expected
value and a function which returns the current value that should be used
in comparison operations, these operations are named with a _v suffix
(e.g. 'value'). All atomic<_Tp> wait/notify operations use the first
variant. Barriers, latches and semaphores use the predicate variant.

This change also centralizes what it means to compare values for the
purposes of atomic::wait rather than scattering through individual
predicates.

This change also centralizes the repetitive code which adjusts for
different user supplied clocks (this should be moved elsewhere
and all such adjustments should use a common implementation).

This change also removes the hashing of the pointer and uses
the pointer value directly for indexing into the waiters table.

libstdc++-v3/ChangeLog:
* include/Makefile.am: Add new  header.
* include/Makefile.in: Regenerate.
* include/bits/atomic_base.h: Adjust all calls
to __atomic_wait/__atomic_notify for new call signatures.
* include/bits/atomic_wait.h: Extensive rewrite.
* include/bits/atomic_timed_wait.h: Likewise.
* include/bits/semaphore_base.h: Adjust all calls
to __atomic_wait/__atomic_notify for new call signatures.
* include/bits/std_thread_sleep.h: New file.
* include/std/atomic: Likewise.
* include/std/barrier: Likewise.
* include/std/latch: Likewise.
* testsuite/29_atomics/atomic/wait_notify/bool.cc: Simplify
test.
* testsuite/29_atomics/atomic/wait_notify/generic.cc: Likewise.
* testsuite/29_atomics/atomic/wait_notify/pointers.cc: Likewise.
* testsuite/29_atomics/atomic_flag/wait_notify.cc: Likewise.
* testsuite/29_atomics/atomic_float/wait_notify.cc: Likewise.
* testsuite/29_atomics/atomic_integral/wait_notify.cc: Likewise.
* testsuite/29_atomics/atomic_ref/wait_notify.cc: Likewise.
---
 libstdc++-v3/include/Makefile.am  |   1 +
 libstdc++-v3/include/Makefile.in  |   1 +
 libstdc++-v3/include/bits/atomic_base.h   |  36 +-
 libstdc++-v3/include/bits/atomic_timed_wait.h | 444 ++--
 libstdc++-v3/include/bits/atomic_wait.h   | 475 --
 libstdc++-v3/include/bits/semaphore_base.h| 192 +++
 libstdc++-v3/include/bits/std_thread_sleep.h  | 119 +
 libstdc++-v3/include/std/atomic   |  15 +-
 libstdc++-v3/include/std/barrier  |  13 +-
 libstdc++-v3/include/std/latch|   8 +-
 libstdc++-v3/include/std/semaphore|   9 +-
 libstdc++-v3/include/std/thread   |  68 +--
 .../29_atomics/atomic/wait_notify/bool.cc |  37 +-
 .../29_atomics/atomic/wait_notify/

[PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

[Jose E. Marchesi via Gcc-patches]

ping

Any hope for getting this in?  We really need this support.
Thanks!

> On 3/12/21 6:39 PM, Martin Liška wrote:
> PING^2
> 
> On 3/1/21 1:07 PM, Martin Liška wrote:
>> PING
>> On 2/18/21 10:18 AM, Martin Liška wrote:
>>> On 2/16/21 10:17 PM, Qing Zhao wrote:
 Hello,
 
 What’s the status of this patch now? Is there any major technical issue 
 with the patch?
 
 Our company has been waiting for this patch for almost one year,
 we need it for our important application.
>>> 
>>> Hello.
>>> 
>>> You are right, we've been waiting for quite some time.
>>> 
 
 Could this one be approved and committed to gcc11?
>>> 
>>> @richi: ?
>>> 
>>> Thanks,
>>> Martin
>>> 
 
 Thanks.
 
 Qing
 
> On Feb 5, 2021, at 3:34 AM, Martin Liška  wrote:
> 
> Hello.
> 
> Based on discussion with Richi, I'm re-sending the patch. Note that the 
> patch
> has been waiting for a review for almost one year and I would like to see
> it in GCC 11.1.
> 
> Thank you,
> Martin
> <0001-Change-semantics-of-frecord-gcc-switches-and-add-fre.patch>
 
>>> 
> 

c++: Note duplicates in symbol table [PR 99283]

[Nathan Sidwell]

I ran into this	reducing 99283,	we were	failing	to mark	binding vectors 
when the current TU declares a duplicate decl (as opposed to  an import 
introduces a duplicate).


PR c++/99283
gcc/cp/
* name-lookup.c (check_module_override): Set global or partition
DUP on the binding vector.
gcc/testsuite/
* g++.dg/modules/pr99283-1_a.H: New.
* g++.dg/modules/pr99283-1_b.H: New.

--
Nathan Sidwell
diff --git c/gcc/cp/name-lookup.c w/gcc/cp/name-lookup.c
index a6257f5da32..f4263f15f62 100644
--- c/gcc/cp/name-lookup.c
+++ w/gcc/cp/name-lookup.c
@@ -3528,6 +3528,7 @@ static tree
 check_module_override (tree decl, tree mvec, bool hiding,
 		   tree scope, tree name)
 {
+  tree match = NULL_TREE;
   bitmap imports = get_import_bitmap ();
   binding_cluster *cluster = BINDING_VECTOR_CLUSTER_BASE (mvec);
   unsigned ix = BINDING_VECTOR_NUM_CLUSTERS (mvec);
@@ -3566,13 +3567,15 @@ check_module_override (tree decl, tree mvec, bool hiding,
 	  bind = STAT_VISIBLE (bind);
 
 	for (ovl_iterator iter (bind); iter; ++iter)
-	  if (iter.using_p ())
-	;
-	  else if (tree match = duplicate_decls (decl, *iter, hiding))
-	return match;
+	  if (!iter.using_p ())
+	{
+	  match = duplicate_decls (decl, *iter, hiding);
+	  if (match)
+		goto matched;
+	}
   }
 
-  if (TREE_PUBLIC (scope) && TREE_PUBLIC (decl) && !not_module_p ()
+  if (TREE_PUBLIC (scope) && TREE_PUBLIC (STRIP_TEMPLATE (decl))
   /* Namespaces are dealt with specially in
 	 make_namespace_finish.  */
   && !(TREE_CODE (decl) == NAMESPACE_DECL && !DECL_NAMESPACE_ALIAS (decl)))
@@ -3588,14 +3591,26 @@ check_module_override (tree decl, tree mvec, bool hiding,
 
   for (ovl_iterator iter (mergeable); iter; ++iter)
 	{
-	  tree match = *iter;
-	  
-	  if (duplicate_decls (decl, match, hiding))
-	return match;
+	  match = duplicate_decls (decl, *iter, hiding);
+	  if (match)
+	goto matched;
 	}
 }
 
   return NULL_TREE;
+
+ matched:
+  if (match != error_mark_node)
+{
+  if (named_module_p ())
+	BINDING_VECTOR_PARTITION_DUPS_P (mvec) = true;
+  else
+	BINDING_VECTOR_GLOBAL_DUPS_P (mvec) = true;
+}
+
+  return match;
+
+  
 }
 
 /* Record DECL as belonging to the current lexical scope.  Check for
diff --git c/gcc/testsuite/g++.dg/modules/pr99283-1_a.H w/gcc/testsuite/g++.dg/modules/pr99283-1_a.H
new file mode 100644
index 000..95c8c06bec6
--- /dev/null
+++ w/gcc/testsuite/g++.dg/modules/pr99283-1_a.H
@@ -0,0 +1,6 @@
+// PR 99283 part 1 ICE on specialization
+// { dg-additional-options -fmodule-header }
+// { dg-module-cmi {} }
+
+template
+_Facet &use_facet ();
diff --git c/gcc/testsuite/g++.dg/modules/pr99283-1_b.H w/gcc/testsuite/g++.dg/modules/pr99283-1_b.H
new file mode 100644
index 000..cd15a1b1e0c
--- /dev/null
+++ w/gcc/testsuite/g++.dg/modules/pr99283-1_b.H
@@ -0,0 +1,10 @@
+// { dg-additional-options -fmodule-header }
+// { dg-module-cmi {} }
+
+import  "pr99283-1_a.H";
+
+template
+_Facet &use_facet ();
+
+extern template
+char &use_facet ();

New Finnish 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 Finnish team of translators.  The file is available at:

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

(This file, 'gcc-11.1-b20210321.fi.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.

[pushed] Darwin : Address a translation comment.

[Iain Sandoe]

Hi

I modified the diagnostic message to avoid a  build-time warning
omitting a colon intentionally; since that has produced a translation
comment, this adds the colon back.

tested with a build of host-darwin (produces no build-time diagnostic).
pushed to master,
thanks
Iain



Add a ':' to make the diagnostic read 'pch_address_space': xxx.

gcc/ChangeLog:

PR target/99733
* config/host-darwin.c (darwin_gt_pch_use_address): Add a
colon to the diagnostic message.
---
 gcc/config/host-darwin.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/host-darwin.c b/gcc/config/host-darwin.c
index b101fca5c96..14a01fe71f2 100644
--- a/gcc/config/host-darwin.c
+++ b/gcc/config/host-darwin.c
@@ -62,7 +62,7 @@ darwin_gt_pch_use_address (void *addr, size_t sz, int fd, 
size_t off)
 
   if (munmap (pch_address_space + sz, sizeof (pch_address_space) - sz) != 0)
 fatal_error (input_location,
-"could not unmap % %m");
+"could not unmap %: %m");
 
   if (ret)
 {
-- 
2.24.1

Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64

[Vladimir Makarov via Gcc-patches]

On 2021-03-23 2:24 p.m., Vladimir Makarov wrote:


On 2021-03-23 1:55 p.m., Christophe Lyon wrote:
On Tue, 23 Mar 2021 at 17:54, Vladimir Makarov  
wrote:


Can you check?

Sorry, I've rerun (cd gcc && make check-gcc) on gcc114 for today trunk
and I don't see the regressions mentioned above.

Can you check this too and if I am doing something wrong for testing,
please point me out.


I'm testing with cross-compilers with ST hat, but I'm not the only one
seeing these failures, see gcc-testresults.
Andreas and in Linaro we are both testing native compilers.

These tests are driven by aarch64-sve-acle-asm.exp

Is it possible that the binutils version matters? I'm using 2.34 for
the cross-toolchains.

Sorry, I looked at the tests in more details.  They require 
aarch64_asm_f64mm and gcc114.fsffrance.org is not that kind of 
machine.  Therefore they are not even compiled on this machine. As I 
understand the tests should check the right assembler generation but 
the tests require to be run.


The problem can be in necessity to use more relaxed memory constraints 
for aarch64.


I'll investigate the regressions more.




Here is the patch solving the problem.

Also although asm tests only checks assembler code, a lot of them use 
dg-require-effective-target and therefore can not be tested on other 
aarch64 machines.  So the patch removes them.


Richard, if the patch is ok, I could commit the patch.  Just let me 
know, please.



diff --git a/gcc/config/aarch64/constraints.md 
b/gcc/config/aarch64/constraints.md
index f08eea8b..fd3e925 100644
--- a/gcc/config/aarch64/constraints.md
+++ b/gcc/config/aarch64/constraints.md
@@ -323,7 +323,7 @@
   (and (match_code "mem")
(match_test "aarch64_simd_mem_operand_p (op)")))
 
-(define_memory_constraint "Utq"
+(define_relaxed_memory_constraint "Utq"
   "@internal
An address valid for loading or storing a 128-bit AdvSIMD register"
   (and (match_code "mem")
@@ -336,32 +336,32 @@
   (and (match_code "mem")
(match_test "aarch64_sve_ld1rq_operand_p (op)")))
 
-(define_memory_constraint "UOb"
+(define_relaxed_memory_constraint "UOb"
   "@internal
An address valid for SVE LD1ROH."
   (and (match_code "mem")
(match_test "aarch64_sve_ld1ro_operand_p (op, QImode)")))
 
-(define_memory_constraint "UOh"
+(define_relaxed_memory_constraint "UOh"
   "@internal
An address valid for SVE LD1ROH."
   (and (match_code "mem")
(match_test "aarch64_sve_ld1ro_operand_p (op, HImode)")))
 
 
-(define_memory_constraint "UOw"
+(define_relaxed_memory_constraint "UOw"
   "@internal
An address valid for SVE LD1ROW."
   (and (match_code "mem")
(match_test "aarch64_sve_ld1ro_operand_p (op, SImode)")))
 
-(define_memory_constraint "UOd"
+(define_relaxed_memory_constraint "UOd"
   "@internal
An address valid for SVE LD1ROD."
   (and (match_code "mem")
(match_test "aarch64_sve_ld1ro_operand_p (op, DImode)")))
 
-(define_memory_constraint "Uty"
+(define_relaxed_memory_constraint "Uty"
   "@internal
An address valid for SVE LD1Rs."
   (and (match_code "mem")
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfdot_f32.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfdot_f32.c
index 376622d..635da34 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfdot_f32.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfdot_f32.c
@@ -1,5 +1,5 @@
 /* { dg-additional-options "-march=armv8.2-a+sve+bf16" } */
-/* { dg-require-effective-target aarch64_asm_bf16_ok }  */
+
 /* { dg-final { check-function-bodies "**" "" "-DCHECK_ASM" } } */
 
 #include "test_sve_acle.h"
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfdot_lane_f32.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfdot_lane_f32.c
index 0f624fe..45a80f5 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfdot_lane_f32.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfdot_lane_f32.c
@@ -1,5 +1,5 @@
 /* { dg-additional-options "-march=armv8.2-a+sve+bf16" } */
-/* { dg-require-effective-target aarch64_asm_bf16_ok }  */
+
 /* { dg-final { check-function-bodies "**" "" "-DCHECK_ASM" } } */
 
 #include "test_sve_acle.h"
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfmlalb_f32.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfmlalb_f32.c
index 0f81011..b55fbc5 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfmlalb_f32.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfmlalb_f32.c
@@ -1,5 +1,5 @@
 /* { dg-additional-options "-march=armv8.2-a+sve+bf16" } */
-/* { dg-require-effective-target aarch64_asm_bf16_ok }  */
+
 /* { dg-final { check-function-bodies "**" "" "-DCHECK_ASM" } } */
 
 #include "test_sve_acle.h"
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfmlalb_lane_f32.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfmlalb_lane_f32.c
index b0ec088..a4c25c7 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfmlalb_lane_f32.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/bfmlal

Re: [PATCH] c++: Fix ICE with nsdmi [PR99705]

[Jason Merrill via Gcc-patches]

On 3/23/21 5:57 AM, Jakub Jelinek wrote:

Hi!

When adding P0784R7 constexpr new support, we still didn't have
P1331R2 implemented and so I had to change also build_vec_delete_1
- instead of having uninitialized tbase temporary later initialized
by MODIFY_EXPR I've set the DECL_INITIAL for it - because otherwise
it would be rejected during constexpr evaluation which didn't like
uninitialized vars.  Unfortunately, that change broke the following
testcase.
The problem is that these temporaries (not just tbase but tbase was
the only one with an initializer) are created during NSDMI parsing
and current_function_decl is NULL at that point.  Later when we
clone body of constructors, auto_var_in_fn_p is false for those
(as they have NULL DECL_CONTEXT) and so they aren't duplicated,
and what is worse, the DECL_INITIAL isn't duplicated either nor processed,
and during expansion we ICE because the code from DECL_INITIAL of that
var refers to the abstract constructor's PARM_DECL (this) rather than
the actual constructor's one.

So, either we can just revert those build_vec_delete_1 changes (as done
in the second patch - in attachment), or, as the first patch does, we can
copy the temporaries during bot_manip like we copy the temporaries of
TARGET_EXPRs.  To me that looks like a better fix because e.g. if
break_out_of_target_exprs is called for the same NSDMI multiple times,
sharing the temporaries looks just wrong to me.  If the temporaries
are declared as BIND_EXPR_VARS of some BIND_EXPR (which is the case
of the tbase variable built by build_vec_delete_1 and is the only way
how the DECL_INITIAL can be walked by *walk_tree*), then we need to
copy it also in the BIND_EXPR BIND_EXPR_VARS chain, other temporaries
(those that don't need DECL_INITIAL) often have just DECL_EXPR and no
corresponding BIND_EXPR.
Note, ({ }) are rejected in nsdmis, so all we run into are temporaries
the FE creates artificially.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or do you prefer the patch in attachment (or something else)?

2021-03-23  Jakub Jelinek  

PR c++/99705
* tree.c (bot_manip): Remap artificial automatic temporaries with
NULL DECL_CONTEXT mentioned in DECL_EXPR or in BIND_EXPR_VARS.

* g++.dg/cpp0x/new5.C: New test.

--- gcc/cp/tree.c.jj2021-03-18 09:49:22.112712307 +0100
+++ gcc/cp/tree.c   2021-03-23 00:08:35.901724895 +0100
@@ -3128,6 +3128,35 @@ bot_manip (tree* tp, int* walk_subtrees,
}
return NULL_TREE;
  }
+  if (TREE_CODE (*tp) == DECL_EXPR
+  && VAR_P (DECL_EXPR_DECL (*tp))
+  && DECL_ARTIFICIAL (DECL_EXPR_DECL (*tp))
+  && !TREE_STATIC (DECL_EXPR_DECL (*tp))
+  && DECL_CONTEXT (DECL_EXPR_DECL (*tp)) == NULL_TREE


I might drop the DECL_CONTEXT check; I'd think any embedded temporaries 
that happen to have it set would also need this treatment.



+  && !splay_tree_lookup (target_remap,
+(splay_tree_key) DECL_EXPR_DECL (*tp)))
+{
+  tree t = create_temporary_var (TREE_TYPE (DECL_EXPR_DECL (*tp)));


You don't need to copy DECL_INITIAL here?


+  splay_tree_insert (target_remap, (splay_tree_key) DECL_EXPR_DECL (*tp),
+(splay_tree_value) t);
+}
+  if (TREE_CODE (*tp) == BIND_EXPR && BIND_EXPR_VARS (*tp))
+{
+  copy_tree_r (tp, walk_subtrees, NULL);
+  for (tree *p = &BIND_EXPR_VARS (*tp); *p; p = &DECL_CHAIN (*p))
+   {
+ gcc_assert (VAR_P (*p) && DECL_ARTIFICIAL (*p) && !TREE_STATIC (*p));
+ tree t = create_temporary_var (TREE_TYPE (*p));
+ DECL_INITIAL (t) = DECL_INITIAL (*p);
+ DECL_CHAIN (t) = DECL_CHAIN (*p);
+ splay_tree_insert (target_remap, (splay_tree_key) *p,
+(splay_tree_value) t);
+ *p = t;
+   }
+  if (data.clear_location && EXPR_HAS_LOCATION (*tp))
+   SET_EXPR_LOCATION (*tp, input_location);
+  return NULL_TREE;
+}
  
/* Make a copy of this node.  */

t = copy_tree_r (tp, walk_subtrees, NULL);
--- gcc/testsuite/g++.dg/cpp0x/new5.C.jj2021-03-22 14:08:29.168782588 
+0100
+++ gcc/testsuite/g++.dg/cpp0x/new5.C   2021-03-22 14:07:35.253378808 +0100
@@ -0,0 +1,21 @@
+// PR c++/99705
+// { dg-do compile { target c++11 } }
+
+template 
+struct C
+{
+  C () { f (); }
+  ~C () {}
+  static void f () {}
+};
+
+struct X
+{
+  X ();
+  int n = 10;
+  C *p = new C[n];
+};
+
+X::X ()
+{
+}

Jakub

Re: [PATCH] c++: Fix source_location inconsistency between calls from templates and non-templates [PR99672]

[Jason Merrill via Gcc-patches]

On 3/23/21 5:34 AM, Jakub Jelinek wrote:

Hi!

The srcloc19.C testcase shows inconsistency in
std::source_location::current() locations between calls from
templates and non-templates.  The location used by __builtin_source_location
comes in both cases from input_location which is set on it by bot_manip
when handling the default argument, called during finish_call_expr.
The problem is that in templates that input_location comes from the
CALL_EXPR we built earlier and that has the combined locus with
range between first character of the function name and closing paren
with caret on the opening paren, so something printed as caret as:
foobar ();
~~~^~
But outside of templates, finish_call_expr is called when input_location
is just the closing paren token, i.e.
foobar ();
 ^
and only after that returns we create the combined location and set
the CALL_EXPR location to that.  So, it means std::source_location::current()
reports in templates the column of opening (, while outside of templates
closing ).

The following patch makes it consistent by creating the combined location
already before calling finish_call_expr and temporarily overriding
input_location to that.

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

2021-03-23  Jakub Jelinek  

PR c++/99672
* parser.c (cp_parser_postfix_expression): For calls, create
combined_loc and temporarily set input_location to it before
calling finish_call_expr.

* g++.dg/concepts/diagnostic2.C: Adjust expected caret line.
* g++.dg/cpp1y/builtin_location.C (f4, n6): Move #line directives
to match locus changes.
* g++.dg/cpp2a/srcloc1.C: Adjust expected column numbers.
* g++.dg/cpp2a/srcloc2.C: Likewise.
* g++.dg/cpp2a/srcloc15.C: Likewise.
* g++.dg/cpp2a/srcloc16.C: Likewise.
* g++.dg/cpp2a/srcloc19.C: New test.
* g++.dg/modules/adhoc-1_b.C: Adjust expected column numbers
and caret line.
* g++.dg/modules/macloc-1_c.C: Adjust expected column numbers.
* g++.dg/modules/macloc-1_d.C: Likewise.
* g++.dg/plugin/diagnostic-test-expressions-1.C: Adjust expected
caret line.

* testsuite/18_support/source_location/consteval.cc (main): Adjust
expected column numbers.
* testsuite/18_support/source_location/1.cc (main): Likewise.

--- gcc/cp/parser.c.jj  2021-03-19 10:14:37.449724617 +0100
+++ gcc/cp/parser.c 2021-03-19 17:35:11.216322995 +0100
@@ -7564,6 +7564,7 @@ cp_parser_postfix_expression (cp_parser
tsubst_flags_t complain = complain_flags (decltype_p);
vec *args;
location_t close_paren_loc = UNKNOWN_LOCATION;
+   location_t combined_loc = UNKNOWN_LOCATION;
  
  is_member_access = false;
  
@@ -7669,6 +7670,20 @@ cp_parser_postfix_expression (cp_parser

  }
  }
  
+	/* Temporarily set input_location to the combined location

+  with call expression range, as e.g. build_out_target_exprs
+  called from convert_default_arg relies on input_location,
+  so updating it only when the call is fully built results
+  in inconsistencies between location handling in templates
+  and outside of templates.  */
+   if (close_paren_loc != UNKNOWN_LOCATION)
+ combined_loc = make_location (token->location, start_loc,
+   close_paren_loc);
+   auto cleanup
+ = make_temp_override (input_location,
+   combined_loc != UNKNOWN_LOCATION
+   ? combined_loc : input_location);


It's simpler to use iloc_sentinel for this.


+
if (TREE_CODE (postfix_expression) == COMPONENT_REF)
  {
tree instance = TREE_OPERAND (postfix_expression, 0);
@@ -7726,12 +7741,7 @@ cp_parser_postfix_expression (cp_parser
complain);
  
  	if (close_paren_loc != UNKNOWN_LOCATION)

- {
-   location_t combined_loc = make_location (token->location,
-start_loc,
-close_paren_loc);
-   postfix_expression.set_location (combined_loc);
- }
+ postfix_expression.set_location (combined_loc);
  
  	/* The POSTFIX_EXPRESSION is certainly no longer an id.  */

idk = CP_ID_KIND_NONE;
--- gcc/testsuite/g++.dg/concepts/diagnostic2.C.jj  2020-08-24 
21:41:17.644520408 +0200
+++ gcc/testsuite/g++.dg/concepts/diagnostic2.C 2021-03-22 19:04:59.947515357 
+0100
@@ -25,6 +25,6 @@ baz()
bar(); // { dg-error "no match" }
  /* { dg-begin-multiline-output "" }
 bar();
-^
+   ^~
 { dg-end-multiline-output "" } */
  }
--- gcc/testsuite/g++.dg/cpp1y/builtin_location.C.jj202

Re: [PATCH] c++: Fix ICE with nsdmi [PR99705]

[Jakub Jelinek via Gcc-patches]

On Tue, Mar 23, 2021 at 04:51:52PM -0400, Jason Merrill wrote:
> > --- gcc/cp/tree.c.jj2021-03-18 09:49:22.112712307 +0100
> > +++ gcc/cp/tree.c   2021-03-23 00:08:35.901724895 +0100
> > @@ -3128,6 +3128,35 @@ bot_manip (tree* tp, int* walk_subtrees,
> > }
> > return NULL_TREE;
> >   }
> > +  if (TREE_CODE (*tp) == DECL_EXPR
> > +  && VAR_P (DECL_EXPR_DECL (*tp))
> > +  && DECL_ARTIFICIAL (DECL_EXPR_DECL (*tp))
> > +  && !TREE_STATIC (DECL_EXPR_DECL (*tp))
> > +  && DECL_CONTEXT (DECL_EXPR_DECL (*tp)) == NULL_TREE
> 
> I might drop the DECL_CONTEXT check; I'd think any embedded temporaries that
> happen to have it set would also need this treatment.

I had that first that way but it broke g++.dg/cpp0x/nsdmi12.C test.
I can have another look why tomorrow.

> > +  && !splay_tree_lookup (target_remap,
> > +(splay_tree_key) DECL_EXPR_DECL (*tp)))
> > +{
> > +  tree t = create_temporary_var (TREE_TYPE (DECL_EXPR_DECL (*tp)));
> 
> You don't need to copy DECL_INITIAL here?

No, because all the temporaries that have DECL_INITIAL need to be manually
put into BIND_EXPR_VARS of some BIND_EXPR, otherwise they wouldn't be
handled properly elsewhere (e.g. walk_tree only walks DECL_INITIAL on
BIND_EXPR).  I can add there
gcc_assert (DECL_INITIAL (DECL_EXPR_DECL (*tp)) == NULL_TREE);

Jakub

Re: [PATCH v2] c++: -Wconversion vs value-dependent expressions [PR99331]

[Jason Merrill via Gcc-patches]

On 3/8/21 7:34 PM, Marek Polacek wrote:

On Fri, Mar 05, 2021 at 05:03:45PM -0500, Jason Merrill wrote:

On 3/4/21 9:37 PM, Marek Polacek wrote:

This PR complains that we issue a -Wconversion warning in

template  struct X {};
template  X foo();

saying "conversion from 'long unsigned int' to 'int' may change value".
While it's not technically wrong, I suspect -Wconversion warnings aren't
all that useful for value-dependent expressions.  So this patch disables
them, though I'm open to other ideas.


How about suppressing -Wconversion in
build_converted_constant_expr_internal?  If the size_t value ended up being
too large for the int parameter, we would give an error about overflow in a
constant expression, not just a warning.


That works for me too.  As you say, if we convert to a type that cannot
represent all the values of the original type, we give a pedantic-error
warning in check_narrowing.

I've slightly enhanced the test, too.

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


OK.  I tried Martin's testcase, and get the expected

wa.C:2:35: error: narrowing conversion of ‘256’ from ‘long unsigned int’ 
to ‘char’ [-Wnarrowing]


Don't you?

Jason


-- >8 --
This PR complains that we issue a -Wconversion warning in

   template  struct X {};
   template  X foo();

saying "conversion from 'long unsigned int' to 'int' may change value".
While it's not technically wrong, I suspect -Wconversion warnings aren't
all that useful for value-dependent expressions.  So this patch disables
them.  This is a regression that started with r241425:

@@ -7278,7 +7306,7 @@ convert_template_argument (tree parm,
   val = error_mark_node;
 }
 }
-  else if (!dependent_template_arg_p (orig_arg)
+  else if (!type_dependent_expression_p (orig_arg)
&& !uses_template_parms (t))
 /* We used to call digest_init here.  However, digest_init
will report errors, which we don't want when complain

Here orig_arg is SIZEOF_EXPR; dependent_template_arg_p (orig_arg) was
true, but type_dependent_expression_p (orig_arg) is false so we warn in
convert_nontype_argument.

gcc/cp/ChangeLog:

PR c++/99331
* call.c (build_converted_constant_expr_internal): Don't emit
-Wconversion warnings.

gcc/testsuite/ChangeLog:

PR c++/99331
* g++.dg/warn/Wconversion5.C: New test.
---
  gcc/cp/call.c|  3 +++
  gcc/testsuite/g++.dg/warn/Wconversion5.C | 19 +++
  2 files changed, 22 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wconversion5.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 7d12fea60f2..55d7e71c0c9 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -4484,6 +4484,9 @@ build_converted_constant_expr_internal (tree type, tree 
expr,
  && processing_template_decl)
conv = next_conversion (conv);
  
+  /* Issuing conversion warnings for value-dependent expressions is

+likely too noisy.  */
+  warning_sentinel w (warn_conversion);
conv->check_narrowing = true;
conv->check_narrowing_const_only = true;
expr = convert_like (conv, expr, complain);
diff --git a/gcc/testsuite/g++.dg/warn/Wconversion5.C 
b/gcc/testsuite/g++.dg/warn/Wconversion5.C
new file mode 100644
index 000..f5ae6312bc5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wconversion5.C
@@ -0,0 +1,19 @@
+// PR c++/99331
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wconversion" }
+// Don't issue -Wconversion warnings for value-dependent expressions.
+
+template  struct X {};
+template  struct Y {};
+template  X foo();
+template  X foo2();
+template Y foo3();
+template Y<1024> foo4(); // { dg-error "narrowing conversion" }
+template Y<1u> foo5();
+template X<__INT_MAX__ + 1U> foo6(); // { dg-error "narrowing conversion" 
}
+
+template 
+struct S {
+  using t = X;
+  using u = X;
+};

base-commit: bd85b4dd2dd7b00b6342ed1e33fb48035a3dcb61

Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64

[Richard Sandiford via Gcc-patches]

Vladimir Makarov  writes:
> On 2021-03-23 2:24 p.m., Vladimir Makarov wrote:
>>
>> On 2021-03-23 1:55 p.m., Christophe Lyon wrote:
>>> On Tue, 23 Mar 2021 at 17:54, Vladimir Makarov  
>>> wrote:

 Can you check?

 Sorry, I've rerun (cd gcc && make check-gcc) on gcc114 for today trunk
 and I don't see the regressions mentioned above.

 Can you check this too and if I am doing something wrong for testing,
 please point me out.

>>> I'm testing with cross-compilers with ST hat, but I'm not the only one
>>> seeing these failures, see gcc-testresults.
>>> Andreas and in Linaro we are both testing native compilers.
>>>
>>> These tests are driven by aarch64-sve-acle-asm.exp
>>>
>>> Is it possible that the binutils version matters? I'm using 2.34 for
>>> the cross-toolchains.
>>>
>> Sorry, I looked at the tests in more details.  They require 
>> aarch64_asm_f64mm and gcc114.fsffrance.org is not that kind of 
>> machine.  Therefore they are not even compiled on this machine. As I 
>> understand the tests should check the right assembler generation but 
>> the tests require to be run.
>>
>> The problem can be in necessity to use more relaxed memory constraints 
>> for aarch64.
>>
>> I'll investigate the regressions more.
>>
>>
>
> Here is the patch solving the problem.
>
> Also although asm tests only checks assembler code, a lot of them use 
> dg-require-effective-target and therefore can not be tested on other 
> aarch64 machines.  So the patch removes them.

I think they're still needed.  The harness tries to use assemble
rather than compile tests by default, so that the assembler picks
up any invalid instructions.  However, we can't assume that everyone
has a version of binutils that supports SVE and .variant_pcs, so the
tests fall back to compile tests unless:

if { [check_effective_target_aarch64_asm_sve_ok]
 && [check_effective_target_aarch64_variant_pcs] } {

is true.

However, the same problem then occurs for features that were added
by later architecture revisions, such as the ones being tested here.
Not everyone will have an assembler that understands these newer
instructions.

So the dg-require-effective-target are needed for the case in which
the system assembler is recent enough to support SVE but is not
recent enough to support these other extensions.

In other words, it wasn't your fault that these regressions didn't
show up.  But the fact that they didn't show up is kind-of deliberate,
since the testing provided by the assembler is a really useful sanity
check in this context.

The constraints.md patch is OK though.  Thanks for the quick fix.

Richard

Re: [PATCH v8] Practical improvement to libgcc complex divide

[Joseph Myers]

On Mon, 22 Feb 2021, Patrick McGehearty via Gcc-patches wrote:

> diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
> index 9f993c4..7dd319c 100644
> --- a/gcc/c-family/c-cppbuiltin.c
> +++ b/gcc/c-family/c-cppbuiltin.c
> @@ -1026,10 +1026,10 @@ c_cpp_builtins (cpp_reader *pfile)
> cpp_define (pfile, "__cpp_using_enum=201907L");
>   }
>if (cxx_dialect > cxx20)
> - {
> -   /* Set feature test macros for C++23.  */
> -   cpp_define (pfile, "__cpp_size_t_suffix=202011L");
> - }
> +{
> +  /* Set feature test macros for C++23.  */
> +  cpp_define (pfile, "__cpp_size_t_suffix=202011L");
> +}

This is a spurious whitespace change that does not belong in this patch.

> sprintf (macro_name, "__LIBGCC_%s_FUNC_EXT__", name);
> char suffix[20] = "";
> if (mode == TYPE_MODE (double_type_node))
> - ; /* Empty suffix correct.  */
> + {
> +   ; /* Empty suffix correct.  */
> +   memcpy (float_h_prefix, "DBL", 4);

No need for the empty statement any more; remove the "; " and just leave 
the comment.

> diff --git a/gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkld.c 
> b/gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkld.c
> new file mode 100644
> index 000..74046ee
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkld.c
> @@ -0,0 +1,123 @@
> +/*
> +  Program to test complex divide for correct results on selected values.
> +  Checking known failure points.
> +*/
> +
> +extern void abort();
> +extern void exit();

In all the tests, please use prototype function declarations rather than 
unprototyped.  Although tests don't need to follow GNU coding style, new 
tests should avoid legacy features such as unprototyped functions unless 
specifically intended to test those features.

> +extern long double log2l(long double);
> +
> +#define SMALL (0x1.0p-16384L)
> +#define MAXBIT 63
> +#define ERRLIM 6
> +
> +/*
> +  Compare c (computed value) with z (expected value).
> +  Return 0 if within allowed range.  Return 1 if not.
> +*/
> +int match(_Complex c, _Complex z)

In general, for all the tests, I don't think you should use _Complex 
meaning double _Complex; you should say double _Complex explicitly.

In this test (the long double test), it looks particularly wrong, because 
I'd expect this function to take long double _Complex arguments, not 
double _Complex; it's probably not verifying anything useful otherwise.

This test seems very specific to one particular long double format (the 
x86 "extended" format).  Maybe the test still works for binary128 long 
double, but it probably doesn't verify much useful in that case (because 
it will only be checking for about 64 accurate bits of results rather than 
for about 113 bits).  On targets where long double has the same (binary64) 
format as double, it might well fail; likewise IBM long double.

You could instead have #if conditionals (on the various LDBL_* constants) 
to distinguish between binary128, x86/m68k "extended", IBM long double, 
long double = double, other formats, and have appropriate test inputs and 
expected outputs for each.  Rather than hardcoding MAXBIT and SMALL 
definitions, it would be better to base things on LDBL_MANT_DIG and 
LDBL_MIN; then only the specific test inputs should need adjusting for the 
different formats.

It will then be necessary to run this test for GCC targets using the 
various different formats to make sure it works correctly for them.  
Hopefully there are suitable GCC Compile Farm systems for doing so.

> +  biterr = log2l(rmax) + MAXBIT + 1;

I'd tend to think it's better to use ilogbl rather than log2l, to compute 
an integer exponent; likewise in the other tests.

> diff --git a/libgcc/config/rs6000/_divkc3.c b/libgcc/config/rs6000/_divkc3.c
> index d261f40..62a29cf 100644
> --- a/libgcc/config/rs6000/_divkc3.c
> +++ b/libgcc/config/rs6000/_divkc3.c
> @@ -37,31 +37,118 @@ see the files COPYING3 and COPYING.RUNTIME respectively. 
>  If not, see
>  #define __divkc3 __divkc3_sw
>  #endif
>  
> +# define RBIG   ((__LIBGCC_TF_MAX__)/2)
> +# define RMIN   (__LIBGCC_TF_MIN__)
> +# define RMIN2  (__LIBGCC_TF_EPSILON__)
> +# define RMINSCAL (1/__LIBGCC_TF_EPSILON__)
> +# define RMAX2  ((RBIG)*(RMIN2))

Coding style issues here:

* No space between "#" and "define"; it's not being used above.

* Space around binary operators '*' and '/'.

* No need for parentheses around the expansions of __LIBGCC_* macros, or 
around RBIG and RMIN2 in the definition of RMAX2.

So RBIG should expand to (__LIBGCC_TF_MAX__ / 2), for example; RMIN should 
expand to __LIBGCC_TF_MIN__; RMAX2 should expand to (RBIG * RMIN2).

Likewise for similar definitions in libgcc2.c.  *But*, in libgcc2.c, the 
space between "#" and "define" *is* appropriate, as it's already being 
used there (to indicate that the #define is inside a #if conditional - the 
defines in libgcc2.c are conditional, those in _di

Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64

[Vladimir Makarov via Gcc-patches]

On 2021-03-23 5:33 p.m., Richard Sandiford wrote:

Vladimir Makarov  writes:

On 2021-03-23 2:24 p.m., Vladimir Makarov wrote:



Here is the patch solving the problem.

Also although asm tests only checks assembler code, a lot of them use
dg-require-effective-target and therefore can not be tested on other
aarch64 machines.  So the patch removes them.

I think they're still needed.  The harness tries to use assemble
rather than compile tests by default, so that the assembler picks
up any invalid instructions.  However, we can't assume that everyone
has a version of binutils that supports SVE and .variant_pcs, so the
tests fall back to compile tests unless:

if { [check_effective_target_aarch64_asm_sve_ok]
  && [check_effective_target_aarch64_variant_pcs] } {

is true.

However, the same problem then occurs for features that were added
by later architecture revisions, such as the ones being tested here.
Not everyone will have an assembler that understands these newer
instructions.

So the dg-require-effective-target are needed for the case in which
the system assembler is recent enough to support SVE but is not
recent enough to support these other extensions.

In other words, it wasn't your fault that these regressions didn't
show up.  But the fact that they didn't show up is kind-of deliberate,
since the testing provided by the assembler is a really useful sanity
check in this context.

The constraints.md patch is OK though.  Thanks for the quick fix.


Thanks for the explanation, Richard.

I think it would be nice to have a check for binutils instead of 
effective target.  Otherwise, the same situation can be repeated in the 
future.  Although I don't know how to implement this in dejagnu.


In any case, I've committed the patch with changes only in constraints.md.

[PATCH 0/2] GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs

[H.J. Lu via Gcc-patches]

Check if host supports multi-byte NOPs before enabling CET on host.
This fixes:

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

H.J. Lu (2):
  GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs
  GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs

 config/cet.m4  | 19 +++--
 gcc/configure  | 45 +-
 libbacktrace/configure | 29 +++
 libcc1/configure   | 45 +-
 libcpp/configure   | 29 +++
 libdecnumber/configure | 29 +++
 libiberty/configure| 29 +++
 lto-plugin/configure   | 63 +++---
 8 files changed, 243 insertions(+), 45 deletions(-)

-- 
2.30.2

[PATCH 1/2] GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs

[H.J. Lu via Gcc-patches]

Check if host supports multi-byte NOPs before enabling CET on host.

config/

PR binutils/27397
* cet.m4 (GCC_CET_HOST_FLAGS): Check if host supports multi-byte
NOPs.

libiberty/

PR binutils/27397
* configure: Regenerated.
---
 config/cet.m4   | 19 ---
 libiberty/configure | 29 +
 2 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/config/cet.m4 b/config/cet.m4
index c67fb4f35b6..7718be1afe8 100644
--- a/config/cet.m4
+++ b/config/cet.m4
@@ -130,6 +130,18 @@ fi
 if test x$may_have_cet = xyes; then
   if test x$cross_compiling = xno; then
 AC_TRY_RUN([
+int
+main ()
+{
+  asm ("endbr32");
+  return 0;
+}
+],
+[have_multi_byte_nop=yes],
+[have_multi_byte_nop=no])
+have_cet=no
+if test x$have_multi_byte_nop = xyes; then
+  AC_TRY_RUN([
 static void
 foo (void)
 {
@@ -155,9 +167,10 @@ main ()
   bar ();
   return 0;
 }
-],
-[have_cet=no],
-[have_cet=yes])
+  ],
+  [have_cet=no],
+  [have_cet=yes])
+fi
 if test x$enable_cet = xno -a x$have_cet = xyes; then
   AC_MSG_ERROR([Intel CET must be enabled on Intel CET enabled host])
 fi
diff --git a/libiberty/configure b/libiberty/configure
index 2ea7c119809..fc0c953dd1a 100755
--- a/libiberty/configure
+++ b/libiberty/configure
@@ -5396,6 +5396,34 @@ else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
+int
+main ()
+{
+  asm ("endbr32");
+  return 0;
+}
+
+_ACEOF
+if ac_fn_c_try_run "$LINENO"; then :
+  have_multi_byte_nop=yes
+else
+  have_multi_byte_nop=no
+fi
+rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
+  conftest.$ac_objext conftest.beam conftest.$ac_ext
+fi
+
+have_cet=no
+if test x$have_multi_byte_nop = xyes; then
+  if test "$cross_compiling" = yes; then :
+  { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
+$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
+as_fn_error $? "cannot run test program while cross compiling
+See \`config.log' for more details" "$LINENO" 5; }
+else
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
 static void
 foo (void)
 {
@@ -5432,6 +5460,7 @@ rm -f core *.core core.conftest.* gmon.out bb.out 
conftest$ac_exeext \
   conftest.$ac_objext conftest.beam conftest.$ac_ext
 fi
 
+fi
 if test x$enable_cet = xno -a x$have_cet = xyes; then
   as_fn_error $? "Intel CET must be enabled on Intel CET enabled host" 
"$LINENO" 5
 fi
-- 
2.30.2

[PATCH 2/2] GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs

[H.J. Lu via Gcc-patches]

Check if host supports multi-byte NOPs before enabling CET on host.

gcc/

PR bootstrap/99703
* configure: Regenerated.

libbacktrace/

PR bootstrap/99703
* configure: Regenerated.

libcc1/

PR bootstrap/99703
* configure: Regenerated.

libcpp/

PR bootstrap/99703
* configure: Regenerated.

libdecnumber/

PR bootstrap/99703
* configure: Regenerated.

lto-plugin/

PR bootstrap/99703
* configure: Regenerated.
---
 gcc/configure  | 45 +-
 libbacktrace/configure | 29 +++
 libcc1/configure   | 45 +-
 libcpp/configure   | 29 +++
 libdecnumber/configure | 29 +++
 lto-plugin/configure   | 63 +++---
 6 files changed, 198 insertions(+), 42 deletions(-)

diff --git a/gcc/configure b/gcc/configure
index 9bb436ce7bd..1d5cbeb7465 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -19392,7 +19392,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19405 "configure"
+#line 19395 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -19498,7 +19498,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19511 "configure"
+#line 19501 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -22237,16 +22237,6 @@ freebsd* | dragonfly*)
   esac
   ;;
 
-gnu*)
-  version_type=linux
-  need_lib_prefix=no
-  need_version=no
-  library_names_spec='${libname}${release}${shared_ext}$versuffix 
${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
-  soname_spec='${libname}${release}${shared_ext}$major'
-  shlibpath_var=LD_LIBRARY_PATH
-  hardcode_into_libs=yes
-  ;;
-
 haiku*)
   version_type=linux
   need_lib_prefix=no
@@ -22368,7 +22358,7 @@ linux*oldld* | linux*aout* | linux*coff*)
 # project, but have not yet been accepted: they are GCC-local changes
 # for the time being.  (See
 # https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg0.html)
-linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu* | uclinuxfdpiceabi)
   version_type=linux
   need_lib_prefix=no
   need_version=no
@@ -31951,6 +31941,34 @@ else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
+int
+main ()
+{
+  asm ("endbr32");
+  return 0;
+}
+
+_ACEOF
+if ac_fn_cxx_try_run "$LINENO"; then :
+  have_multi_byte_nop=yes
+else
+  have_multi_byte_nop=no
+fi
+rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
+  conftest.$ac_objext conftest.beam conftest.$ac_ext
+fi
+
+have_cet=no
+if test x$have_multi_byte_nop = xyes; then
+  if test "$cross_compiling" = yes; then :
+  { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
+$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
+as_fn_error $? "cannot run test program while cross compiling
+See \`config.log' for more details" "$LINENO" 5; }
+else
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
 static void
 foo (void)
 {
@@ -31987,6 +32005,7 @@ rm -f core *.core core.conftest.* gmon.out bb.out 
conftest$ac_exeext \
   conftest.$ac_objext conftest.beam conftest.$ac_ext
 fi
 
+fi
 if test x$enable_cet = xno -a x$have_cet = xyes; then
   as_fn_error $? "Intel CET must be enabled on Intel CET enabled host" 
"$LINENO" 5
 fi
diff --git a/libbacktrace/configure b/libbacktrace/configure
index 9b66bf5563a..a2f33c0f35d 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -12517,6 +12517,34 @@ else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
+int
+main ()
+{
+  asm ("endbr32");
+  return 0;
+}
+
+_ACEOF
+if ac_fn_c_try_run "$LINENO"; then :
+  have_multi_byte_nop=yes
+else
+  have_multi_byte_nop=no
+fi
+rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
+  conftest.$ac_objext conftest.beam conftest.$ac_ext
+fi
+
+have_cet=no
+if test x$have_multi_byte_nop = xyes; then
+  if test "$cross_compiling" = yes; then :
+  { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
+$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
+as_fn_error $? "cannot run test program while cross compiling
+See \`config.log' for more details" "$LINENO" 5; }
+else
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
 static void
 foo (void)
 {
@@ -12553,6 +12581,7 @@ rm -f core *.core core.conftest.* gmon.out bb.out 
conftest$ac_exeext \
   conftest.$ac_objext conftest.beam conftest.$ac_ext
 fi
 
+fi
 if test x$enable_cet = xno -a x$have_cet = xyes; then
   as_fn_error $? "Intel CET must be enabled on Intel CET enabled host" 
"$LINENO" 5
 fi
diff --git a/libcc1/configure b/libcc1/configure
index 021ec265526..b198b0b9074 100755
--- a/libcc1/co

[PATCH] c++, v2: Fix source_location inconsistency between calls from templates and non-templates [PR99672]

[Jakub Jelinek via Gcc-patches]

On Tue, Mar 23, 2021 at 04:53:54PM -0400, Jason Merrill via Gcc-patches wrote:
> It's simpler to use iloc_sentinel for this.

Indeed, it is.
Here is the new version, bootstrapped on x86_64-linux and i686-linux,
so far regtested on i686-linux, regtest on x86_64 ongoing, ok for trunk
if it passes?

2021-03-23  Jakub Jelinek  

PR c++/99672
* parser.c (cp_parser_postfix_expression): For calls, create
combined_loc and temporarily set input_location to it before
calling finish_call_expr.

* g++.dg/concepts/diagnostic2.C: Adjust expected caret line.
* g++.dg/cpp1y/builtin_location.C (f4, n6): Move #line directives
to match locus changes.
* g++.dg/cpp2a/srcloc1.C: Adjust expected column numbers.
* g++.dg/cpp2a/srcloc2.C: Likewise.
* g++.dg/cpp2a/srcloc15.C: Likewise.
* g++.dg/cpp2a/srcloc16.C: Likewise.
* g++.dg/cpp2a/srcloc19.C: New test.
* g++.dg/modules/adhoc-1_b.C: Adjust expected column numbers
and caret line.
* g++.dg/modules/macloc-1_c.C: Adjust expected column numbers.
* g++.dg/modules/macloc-1_d.C: Likewise.
* g++.dg/plugin/diagnostic-test-expressions-1.C: Adjust expected
caret line.

* testsuite/18_support/source_location/consteval.cc (main): Adjust
expected column numbers.
* testsuite/18_support/source_location/1.cc (main): Likewise.

--- gcc/cp/parser.c.jj  2021-03-19 10:14:37.449724617 +0100
+++ gcc/cp/parser.c 2021-03-19 17:35:11.216322995 +0100
@@ -7564,6 +7564,7 @@ cp_parser_postfix_expression (cp_parser
tsubst_flags_t complain = complain_flags (decltype_p);
vec *args;
location_t close_paren_loc = UNKNOWN_LOCATION;
+   location_t combined_loc = UNKNOWN_LOCATION;
 
 is_member_access = false;
 
@@ -7669,6 +7670,17 @@ cp_parser_postfix_expression (cp_parser
  }
  }
 
+   /* Temporarily set input_location to the combined location
+  with call expression range, as e.g. build_out_target_exprs
+  called from convert_default_arg relies on input_location,
+  so updating it only when the call is fully built results
+  in inconsistencies between location handling in templates
+  and outside of templates.  */
+   if (close_paren_loc != UNKNOWN_LOCATION)
+ combined_loc = make_location (token->location, start_loc,
+   close_paren_loc);
+   iloc_sentinel ils (combined_loc);
+
if (TREE_CODE (postfix_expression) == COMPONENT_REF)
  {
tree instance = TREE_OPERAND (postfix_expression, 0);
@@ -7726,12 +7738,7 @@ cp_parser_postfix_expression (cp_parser
complain);
 
if (close_paren_loc != UNKNOWN_LOCATION)
- {
-   location_t combined_loc = make_location (token->location,
-start_loc,
-close_paren_loc);
-   postfix_expression.set_location (combined_loc);
- }
+ postfix_expression.set_location (combined_loc);
 
/* The POSTFIX_EXPRESSION is certainly no longer an id.  */
idk = CP_ID_KIND_NONE;
--- gcc/testsuite/g++.dg/concepts/diagnostic2.C.jj  2020-08-24 
21:41:17.644520408 +0200
+++ gcc/testsuite/g++.dg/concepts/diagnostic2.C 2021-03-22 19:04:59.947515357 
+0100
@@ -25,6 +25,6 @@ baz()
   bar(); // { dg-error "no match" }
 /* { dg-begin-multiline-output "" }
bar();
-^
+   ^~
{ dg-end-multiline-output "" } */
 }
--- gcc/testsuite/g++.dg/cpp1y/builtin_location.C.jj2020-01-14 
20:02:46.771610014 +0100
+++ gcc/testsuite/g++.dg/cpp1y/builtin_location.C   2021-03-22 
17:27:59.121756869 +0100
@@ -103,10 +103,10 @@ A (0 == __builtin_strcmp (f3, FILE_3));
 #define FILE_4 "next_file_name.another_suffix"
 #line 1 "foobar"
 constexpr const char* f4 = this_file
-  (
 #line 1 FILE_4
-   )
+  (
 #line 1 "foobar"
+   )
   ;
 A (0 == __builtin_strcmp (f4, FILE_4));
 
@@ -167,9 +167,9 @@ A (n5 == 9);
 // of the function call.
 #line 1
 constexpr int n6 = this_line
-  (
 #line 99
-   )
+  (
 #line 1
+   )
   ;
 A (n6 == 99);
--- gcc/testsuite/g++.dg/cpp2a/srcloc1.C.jj 2020-12-04 16:02:57.300153753 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/srcloc1.C2021-03-20 00:30:14.245469602 
+0100
@@ -80,7 +80,7 @@ constexpr source_location s2 = baz <1> (
 const source_location *p1 = &s1;
 const source_location *p2 = &s2;
 static_assert (source_location::current ().line () == __LINE__);
-static_assert (source_location::current ().column () == 42);
+static_assert (source_location::current ().column () == 41);
 
 constexpr bool
 quux ()
@@ -106,7 +106,7 @@ quux ()
 return false;
   if (line1 != line2)
 return false;
-  if (column != 33)
+

Re: [PATCH v2 0/5] RISC-V big endian support

[Jim Wilson]

On Fri, Mar 19, 2021 at 9:22 AM Kito Cheng via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> On Mon, Mar 15, 2021 at 5:42 AM Marcus Comstedt  wrote:
> > I've now delved a bit deeper into the failure of the testcase
> > gcc.c-torture/compile/pr35318.c on big endian RV32.
>

Looking at this testcase, I think this is triggering undefined behavior for
extended asms.

We have an SImode integer constant 8, a DFmode input/output, a 0
constraint that matches the input to output, and then a % commutative
operator that lets us swap operands, except once we swap operands we are
now trying to force SImode and DFmode values to match via the 0 constraint
which is unreasonable, plus a m constraint that then forces an input to
memory.  It works by accident for little-endian because we reload the +0
word of the double and it is still considered the same operand, and it
fails for big-endian by accident because we reload the +4 word of the
double and now it is considered a different operand.

If I change the "8" to "(double)8" or "8.0" then the testcase works for
both big and little endian, as now we have only DFmode values.

I tried ppc-eabi and ppcle-eabi to see what happens there, and the main
difference is that it chooses the 1 alternative in both cases.  However,
for RISC-V, we choose the 0 alternative with operands swapped.  The reason
for this is that we have a DFmode pseudo that wants an FP reg for a load,
and the same pseudo wants a general reg in the asm, and rv32gc does not
have an instruction to move directly between 64-bit FP regs and 32-bit
general regs, so it gets put in memory as the lowest cost option.  That
then leads to the case that alt 0 with swapped operands has the lowest
cost, except this case is the invalid case that tries to match SImode and
DFmode operands with 0 and m constraints and fails.

To summarize, I think that there are two problems here.
1) The testcase is invalid, and can be fixed by changing the "8" to
"(double)8" or "8.0" to ensure that we have a double constant that matches
the type of the other operands.
2) GCC should be giving an error for an asm like this rather than an ICE.
Note that if I manually swap the operands and remove the % I get
void
foo ()
{
  double x = 4, y;
  __asm__ volatile ("" : "=r" (x), "=r" (y) : "0" (8), "m" (x));
}
which fails with an ICE for big-endian ppc exactly the same as it does for
big-endian RISC-V.  We should be generating an error here rather than an
ICE.

Jim

Re: [PATCH] AIX struct alignment (PR 99557)

[David Edelsohn via Gcc-patches]

On Mon, Mar 22, 2021 at 4:10 AM Richard Biener
 wrote:

> Oh, and for a type like
>
>  struct { struct { struct { ... { double x; } } } } } };
>
> the layout now looks quadratic in work (each field layout will look at
> the nest rooted at it
> up to the bottom).  It looks to me as we require(?) the field types to
> be laid out and thus
> at least an early out checking the type alignment to be >= 64 can work?

rs6000_special_round_type_align and rs6000_special_adjust_field_align
both can have early exits to handle some easy cases.  Thanks for
pointing that out.

struct A { struct { struct { ... { double x; } } } };
struct B { struct A; struct A; struct A; struct A; ...; };

is a particularly ugly situation.

When I originally had implemented this in GCC, the recursive nature of
the requirement was not clear. Changing the alignment for a type
(struct) in two different contexts (bare versus member) is bizarre,
but that is what IBM XL compilers implement.

If this becomes a time-sink for for in real use cases, one could
create a side cache of the type with the previously calculated
alignment value.  Or are there some preferred, available flag bit in
the tree that can record that the type alignment has been checked and
either use TYPE_ALIGN or use 32?  Maybe protected_flag or
side_effects_flag or nothrow_flag?

Thanks, David

[wwwdoc] gcc-11/changes: Document RISC-V changes

[Kito Cheng]

---
 htdocs/gcc-11/changes.html | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 69869309..ec136349 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -688,7 +688,37 @@ a work-in-progress.
   
 
 
-
+RISC-V
+
+  Support big-endian for RISC-V, thanks to Marcus Comstedt.
+  Implement new style of architecture extension test macros,
+  each architecture extension has corresponding feature test macro, which
+  could use to test its existence and version information.
+  
+  Legacy architecture extension test macro like 
__riscv_atomic,
+  but it will still supported for at least 2 release cycles.
+  
+  Support IFUNC for riscv*-*-linux*.
+  Introduce --with-multilib-generator to configure time 
option,
+  this option could flexible config multi-lib settings, syntax is same as
+  RISC-V's multilib-generator.
+  
+  Extend the sytax for multilib-generator, support expansion
+  operator * to reduce the complexity of complicated multi-lib
+  re-use rule.
+  
+  Support -mcpu=* option, the behavior is aligned to RISC-V
+  clang/LLVM, it will set pipeline model and architecture extension, like
+  -mtune=* plus -march=*.
+  
+  Support for TLS stack protector canary access, thanks to Cooper Qu.
+  
+  Support __builtin_thread_pointer for RISC-V.
+  Introduce shorten_memrefs optimization, which could reduce 
the
+  code size for memory access, thanks to Craig Blackmore.
+  
+
+
 
 
 
-- 
2.30.2

[PATCH] rs6000: Correct Power8 cost of l2 cache size [PR97329]

[Xionghu Luo via Gcc-patches]

l2 cache size for Power8 is 512kB, correct the copy paste error from Power7.
Tested no performance change for SPEC2017.

gcc/ChangeLog:

2021-03-24  Xionghu Luo  

* config/rs6000/rs6000.c (struct processor_costs): Change to
512.
---
 gcc/config/rs6000/rs6000.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 616dae35bae..34c4edae20e 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -1055,7 +1055,7 @@ struct processor_costs power8_cost = {
   COSTS_N_INSNS (17),  /* ddiv */
   128, /* cache line size */
   32,  /* l1 cache */
-  256, /* l2 cache */
+  512, /* l2 cache */
   12,  /* prefetch streams */
   COSTS_N_INSNS (3),   /* SF->DF convert */
 };
-- 
2.25.1

[PATCH] rs6000: Don't generate IFN VEC_SET for m32 [PR99718]

[Xionghu Luo via Gcc-patches]

UNSPEC_SI_FROM_SF is not supported for -m32 caused ICE on P8BE-32bit,
since P8 Vector and above doesn't have fast mechanism to move SFmode to
SImode for m32, don't generate IFN VEC_SET for it.

Tested pass on P8BE/LE {m32,m64}.

gcc/ChangeLog:

2021-03-24  Xionghu Luo  

* config/rs6000/predicates.md (vec_set_index_operand): New
predicate.
* config/rs6000/vector.md: Use vec_set_index_operand.
---
 gcc/config/rs6000/predicates.md | 6 ++
 gcc/config/rs6000/vector.md | 3 +--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md
index 859af75dfbd..51184390d24 100644
--- a/gcc/config/rs6000/predicates.md
+++ b/gcc/config/rs6000/predicates.md
@@ -1940,3 +1940,9 @@ (define_predicate "d_form_memory"
 
   return !indexed_address (addr, mode);
 })
+
+;; Return true if m64 on p8v and above for vec_set with variable index.
+(define_predicate "vec_set_index_operand"
+ (if_then_else (match_test "TARGET_P8_VECTOR && TARGET_DIRECT_MOVE_64BIT")
+  (match_operand 0 "reg_or_cint_operand")
+  (match_operand 0 "const_int_operand")))
diff --git a/gcc/config/rs6000/vector.md b/gcc/config/rs6000/vector.md
index e5191bd1424..c9ed5adfa4c 100644
--- a/gcc/config/rs6000/vector.md
+++ b/gcc/config/rs6000/vector.md
@@ -1227,7 +1227,7 @@ (define_expand "vec_init"
 (define_expand "vec_set"
   [(match_operand:VEC_E 0 "vlogical_operand")
(match_operand: 1 "register_operand")
-   (match_operand 2 "reg_or_cint_operand")]
+   (match_operand 2 "vec_set_index_operand")]
   "VECTOR_MEM_ALTIVEC_OR_VSX_P (mode)"
 {
   rs6000_expand_vector_set (operands[0], operands[1], operands[2]);
@@ -1505,7 +1505,6 @@ (define_expand "vashr3"
 ; is to allow us to use a code iterator, but not completely list all of the
 ; vector rotates, etc. to prevent canonicalization
 
-
 (define_expand "reduc__scal_"
   [(match_operand: 0 "register_operand")
(VEC_reduc:VEC_F (match_operand:VEC_F 1 "vfloat_operand")
-- 
2.25.1

Re: fix ssse3_pshufbv8qi3 post-reload const pool load

[Alexandre Oliva]

Hello, Jakub,

On Mar 19, 2021, Jakub Jelinek  wrote:

> On Fri, Mar 19, 2021 at 07:44:01PM -0300, Alexandre Oliva wrote:

>> However, I had a total of 15 similar fails within gcc.target/i386 in a
>> gcc-10 tree configured with -mcmodel=large

> But then we should add at least one new testcase for that

Yeah, that's a good idea.  I don't suppose x86_64 -mcmodel=large gets
much community testing.

This (minus lp64 in the test) was regstrapped on x86_64-linux-gnu, along
with other testsuite patches I'm about to post, and tested on
x86_64-vx7r2.  After noticing the failure to constrain the new test to
lp64 only, I fixed and retested it on x86_64-linux-gnu.  Ok to install?


fix ssse3_pshufbv8qi3 post-reload const pool load

The split in ssse3_pshufbv8qi3 forces a const vector into the constant
pool, and loads from it.  That runs after reload, so if the load
requires any reloading, we're out of luck.  Indeed, if the load
address is not legitimate, e.g. -mcmodel=large, the insn is no longer
recognized.

This patch turns the constant into an input operand, introduces an
expander to generate the constant unconditionally, and arranges for
this input operand to be retained as an unused immediate in the
alternatives that don't undergo splitting, and for it to be loaded
into the scratch register for those that do.

It is now the register allocator that arranges to load the const
vector into a register, so it deals with whatever legitimizing steps
needed for the target configuration.


for  gcc/ChangeLog

* config/i386/predicates.md (reg_or_const_vec_operand): New.
* config/i386/sse.md (ssse3_pshufbv8qi3): Add an expander for
the now *-prefixed insn_and_split, turn the splitter const vec
into an input for the insn, making it an ignored immediate for
non-split cases, and loaded into the scratch register
otherwise.

for  gcc/testsuite/ChangeLog

* gcc.target/i386/pr94467-3.c: New.
---
 gcc/config/i386/predicates.md |6 ++
 gcc/config/i386/sse.md|   25 ++---
 gcc/testsuite/gcc.target/i386/pr94467-3.c |4 
 3 files changed, 28 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr94467-3.c

diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index b6dd5e9d3b243..b1df8548af639 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -1153,6 +1153,12 @@ (define_predicate "nonimmediate_or_const_vector_operand"
   (ior (match_operand 0 "nonimmediate_operand")
(match_code "const_vector")))
 
+;; Return true when OP is either register operand, or any
+;; CONST_VECTOR.
+(define_predicate "reg_or_const_vector_operand"
+  (ior (match_operand 0 "register_operand")
+   (match_code "const_vector")))
+
 ;; Return true when OP is nonimmediate or standard SSE constant.
 (define_predicate "nonimmediate_or_sse_const_operand"
   (ior (match_operand 0 "nonimmediate_operand")
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 43e4d57ec6a3d..9d3728d1cb08b 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -17159,10 +17159,25 @@ (define_insn "_pshufb3"
(set_attr "btver2_decode" "vector")
(set_attr "mode" "")])
 
-(define_insn_and_split "ssse3_pshufbv8qi3"
+(define_expand "ssse3_pshufbv8qi3"
+  [(parallel
+[(set (match_operand:V8QI 0 "register_operand")
+ (unspec:V8QI [(match_operand:V8QI 1 "register_operand")
+   (match_operand:V8QI 2 "register_mmxmem_operand")
+   (match_dup 3)] UNSPEC_PSHUFB))
+ (clobber (match_scratch:V4SI 4))])]
+  "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
+{
+  operands[3] = ix86_build_const_vector (V4SImode, true,
+ gen_int_mode (0xf7f7f7f7, SImode));
+})
+
+(define_insn_and_split "*ssse3_pshufbv8qi3"
   [(set (match_operand:V8QI 0 "register_operand" "=y,x,Yv")
(unspec:V8QI [(match_operand:V8QI 1 "register_operand" "0,0,Yv")
- (match_operand:V8QI 2 "register_mmxmem_operand" 
"ym,x,Yv")]
+ (match_operand:V8QI 2 "register_mmxmem_operand" "ym,x,Yv")
+ (match_operand:V4SI 4 "reg_or_const_vector_operand"
+ "i,3,3")]
 UNSPEC_PSHUFB))
(clobber (match_scratch:V4SI 3 "=X,&x,&Yv"))]
   "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
@@ -17172,8 +17187,7 @@ (define_insn_and_split "ssse3_pshufbv8qi3"
#"
   "TARGET_SSSE3 && reload_completed
&& SSE_REGNO_P (REGNO (operands[0]))"
-  [(set (match_dup 3) (match_dup 5))
-   (set (match_dup 3)
+  [(set (match_dup 3)
(and:V4SI (match_dup 3) (match_dup 2)))
(set (match_dup 0)
(unspec:V16QI [(match_dup 1) (match_dup 4)] UNSPEC_PSHUFB))]
@@ -17188,9 +17202,6 @@ (define_insn_and_split "ssse3_pshufbv8qi3"
GET_MODE (operands[2]));
   operands[4] = lo

tighten funcspec regexps

[Alexandre Oliva]

In -mcmodel=large, callee symbols are pulled ahead of the call insns.

The patterns in funcspec-[12].c tests in gcc.target/i386 match even
line breaks between 'call' and a function symbol expected to be
called, however, so it ends up unexpectedly matching a previous,
unrelated indirect call, up to the insn that loads the address of the
intended callee to a register, for all but the first callee, that
doesn't have a call insn before it.

All of these apparent passes are false positives.  We are NOT
generating the expected call insns.

This patch fixes only the patterns, so that they won't trigger false
positives any more.  There are several dozens of other tests that fail
with -mcmodel=large for similar reasons, but I'm still not sure about
how to deal with them.  I see no point in holding up this small
improvement over the lack of a larger solution of a different problem,
though.

Regstrapped on x86_64-linux-gnu and cross-tested for x86_64-vx7r2 along
with other patches, mostly for the testsuite.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/i386/funcspec-2.c: Tighten regexps to avoid false
positives with -mcmodel=large.
* gcc.target/i386/funcspec-3.c: Likewise.
---
 gcc/testsuite/gcc.target/i386/funcspec-2.c |   16 
 gcc/testsuite/gcc.target/i386/funcspec-3.c |6 +++---
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/funcspec-2.c 
b/gcc/testsuite/gcc.target/i386/funcspec-2.c
index d607fbc79c91d..147f62321fd77 100644
--- a/gcc/testsuite/gcc.target/i386/funcspec-2.c
+++ b/gcc/testsuite/gcc.target/i386/funcspec-2.c
@@ -89,11 +89,11 @@ int main ()
 /* { dg-final { scan-assembler "vfnmaddsd" } } */
 /* { dg-final { scan-assembler "vfnmsubss" } } */
 /* { dg-final { scan-assembler "vfnmsubsd" } } */
-/* { dg-final { scan-assembler "call\t(.*)flt_mul_add" } } */
-/* { dg-final { scan-assembler "call\t(.*)flt_mul_sub" } } */
-/* { dg-final { scan-assembler "call\t(.*)flt_neg_mul_add" } } */
-/* { dg-final { scan-assembler "call\t(.*)flt_neg_mul_sub" } } */
-/* { dg-final { scan-assembler "call\t(.*)dbl_mul_add" } } */
-/* { dg-final { scan-assembler "call\t(.*)dbl_mul_sub" } } */
-/* { dg-final { scan-assembler "call\t(.*)dbl_neg_mul_add" } } */
-/* { dg-final { scan-assembler "call\t(.*)dbl_neg_mul_sub" } } */
+/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)flt_mul_add" } } */
+/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)flt_mul_sub" } } */
+/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)flt_neg_mul_add" } } */
+/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)flt_neg_mul_sub" } } */
+/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)dbl_mul_add" } } */
+/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)dbl_mul_sub" } } */
+/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)dbl_neg_mul_add" } } */
+/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)dbl_neg_mul_sub" } } */
diff --git a/gcc/testsuite/gcc.target/i386/funcspec-3.c 
b/gcc/testsuite/gcc.target/i386/funcspec-3.c
index 613a1a0fb9521..8fb425b925add 100644
--- a/gcc/testsuite/gcc.target/i386/funcspec-3.c
+++ b/gcc/testsuite/gcc.target/i386/funcspec-3.c
@@ -63,6 +63,6 @@ int main ()
 /* { dg-final { scan-assembler "popcntl" { target { ! *-*-darwin* } } } } */
 /* { dg-final { scan-assembler "popcntq" { target { ! *-*-darwin* } } } } */
 /* { dg-final { scan-assembler-times "popcnt" 2 { target *-*-darwin* } } } */
-/* { dg-final { scan-assembler "call\t(.*)sse4a_pop_i" } } */
-/* { dg-final { scan-assembler "call\t(.*)sse42_pop_l" } } */
-/* { dg-final { scan-assembler "call\t(.*)popcountdi2" } } */
+/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)sse4a_pop_i" } } */
+/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)sse42_pop_l" } } */
+/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)popcountdi2" } } */


-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Re: fix ssse3_pshufbv8qi3 post-reload const pool load

[Uros Bizjak via Gcc-patches]

On Wed, Mar 24, 2021 at 7:46 AM Alexandre Oliva  wrote:
>
> Hello, Jakub,
>
> On Mar 19, 2021, Jakub Jelinek  wrote:
>
> > On Fri, Mar 19, 2021 at 07:44:01PM -0300, Alexandre Oliva wrote:
>
> >> However, I had a total of 15 similar fails within gcc.target/i386 in a
> >> gcc-10 tree configured with -mcmodel=large
>
> > But then we should add at least one new testcase for that
>
> Yeah, that's a good idea.  I don't suppose x86_64 -mcmodel=large gets
> much community testing.
>
> This (minus lp64 in the test) was regstrapped on x86_64-linux-gnu, along
> with other testsuite patches I'm about to post, and tested on
> x86_64-vx7r2.  After noticing the failure to constrain the new test to
> lp64 only, I fixed and retested it on x86_64-linux-gnu.  Ok to install?
>
>
> fix ssse3_pshufbv8qi3 post-reload const pool load
>
> The split in ssse3_pshufbv8qi3 forces a const vector into the constant
> pool, and loads from it.  That runs after reload, so if the load
> requires any reloading, we're out of luck.  Indeed, if the load
> address is not legitimate, e.g. -mcmodel=large, the insn is no longer
> recognized.
>
> This patch turns the constant into an input operand, introduces an
> expander to generate the constant unconditionally, and arranges for
> this input operand to be retained as an unused immediate in the
> alternatives that don't undergo splitting, and for it to be loaded
> into the scratch register for those that do.
>
> It is now the register allocator that arranges to load the const
> vector into a register, so it deals with whatever legitimizing steps
> needed for the target configuration.
>
>
> for  gcc/ChangeLog
>
> * config/i386/predicates.md (reg_or_const_vec_operand): New.
> * config/i386/sse.md (ssse3_pshufbv8qi3): Add an expander for
> the now *-prefixed insn_and_split, turn the splitter const vec
> into an input for the insn, making it an ignored immediate for
> non-split cases, and loaded into the scratch register
> otherwise.
>
> for  gcc/testsuite/ChangeLog
>
> * gcc.target/i386/pr94467-3.c: New.

OK.

Thanks,
Uros.

> ---
>  gcc/config/i386/predicates.md |6 ++
>  gcc/config/i386/sse.md|   25 ++---
>  gcc/testsuite/gcc.target/i386/pr94467-3.c |4 
>  3 files changed, 28 insertions(+), 7 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr94467-3.c
>
> diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
> index b6dd5e9d3b243..b1df8548af639 100644
> --- a/gcc/config/i386/predicates.md
> +++ b/gcc/config/i386/predicates.md
> @@ -1153,6 +1153,12 @@ (define_predicate 
> "nonimmediate_or_const_vector_operand"
>(ior (match_operand 0 "nonimmediate_operand")
> (match_code "const_vector")))
>
> +;; Return true when OP is either register operand, or any
> +;; CONST_VECTOR.
> +(define_predicate "reg_or_const_vector_operand"
> +  (ior (match_operand 0 "register_operand")
> +   (match_code "const_vector")))
> +
>  ;; Return true when OP is nonimmediate or standard SSE constant.
>  (define_predicate "nonimmediate_or_sse_const_operand"
>(ior (match_operand 0 "nonimmediate_operand")
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 43e4d57ec6a3d..9d3728d1cb08b 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -17159,10 +17159,25 @@ (define_insn "_pshufb3"
> (set_attr "btver2_decode" "vector")
> (set_attr "mode" "")])
>
> -(define_insn_and_split "ssse3_pshufbv8qi3"
> +(define_expand "ssse3_pshufbv8qi3"
> +  [(parallel
> +[(set (match_operand:V8QI 0 "register_operand")
> + (unspec:V8QI [(match_operand:V8QI 1 "register_operand")
> +   (match_operand:V8QI 2 "register_mmxmem_operand")
> +   (match_dup 3)] UNSPEC_PSHUFB))
> + (clobber (match_scratch:V4SI 4))])]
> +  "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
> +{
> +  operands[3] = ix86_build_const_vector (V4SImode, true,
> + gen_int_mode (0xf7f7f7f7, SImode));
> +})
> +
> +(define_insn_and_split "*ssse3_pshufbv8qi3"
>[(set (match_operand:V8QI 0 "register_operand" "=y,x,Yv")
> (unspec:V8QI [(match_operand:V8QI 1 "register_operand" "0,0,Yv")
> - (match_operand:V8QI 2 "register_mmxmem_operand" 
> "ym,x,Yv")]
> + (match_operand:V8QI 2 "register_mmxmem_operand" 
> "ym,x,Yv")
> + (match_operand:V4SI 4 "reg_or_const_vector_operand"
> + "i,3,3")]
>  UNSPEC_PSHUFB))
> (clobber (match_scratch:V4SI 3 "=X,&x,&Yv"))]
>"(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
> @@ -17172,8 +17187,7 @@ (define_insn_and_split "ssse3_pshufbv8qi3"
> #"
>"TARGET_SSSE3 && reload_completed
> && SSE_REGNO_P (REGNO (operands[0]))"
> -  [(set (match_dup 3) (match_dup 5))
> -   (set (match_dup 3)
> +  [(set (ma

require et random_device for cons token test

[Alexandre Oliva]

On target systems that don't support any random_device, not even the
default one, other random_device constructor tests are disabled by
dg-require-effective-target random_device.  The token.cc also
exercises the default constructor, in a way that doesn't expect an
exception to be raised, but it's not guarded by the same requirement.

Other potentially-raising ctors in token.cc expect exceptions and
handle them, but the ("default")-constructed one does not, so the
program terminates and the test fails without exercising the other
constructor variants.

This patch arranges to disable the test altogether when the
random_device feature is not available.  A reasonable alternative
would be to install a std::runtime_error handler around the test01
body, so that we exercise at least the exception raising, but then
test03 would have to be relaxed, since without even "default", it
likely wouldn't meet the tested requirement there.

Regstrapped on x86_64-linux-gnu and cross-tested for x86_64-vx7r2 along
with other patches, mostly for the testsuite.  Ok to install?


for  libstdc++-v3/ChangeLog

* testsuite/26_numerics/random/random_device/cons/token.cc:
Require effective target feature random_device.
---
 .../26_numerics/random/random_device/cons/token.cc |1 +
 1 file changed, 1 insertion(+)

diff --git 
a/libstdc++-v3/testsuite/26_numerics/random/random_device/cons/token.cc 
b/libstdc++-v3/testsuite/26_numerics/random/random_device/cons/token.cc
index defb8d58c586a..105ae0ba87743 100644
--- a/libstdc++-v3/testsuite/26_numerics/random/random_device/cons/token.cc
+++ b/libstdc++-v3/testsuite/26_numerics/random/random_device/cons/token.cc
@@ -1,4 +1,5 @@
 // { dg-do run { target c++11 } }
+// { dg-require-effective-target random_device }
 // { dg-require-cstdint "" }
 //
 // 2008-11-24  Edward M. Smith-Rowland <3dw...@verizon.net>


-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

require et feature pie for PIE tests

[Alexandre Oliva]

Both of these tests fail on platforms that reject -fPIC/-fPIE
altogether.

Other tests that perform PIE compilation or linking require the pie
feature, whether for -fpie/-fPIE compilation or for -pie linking.

This patch annotates both tests with the required target feature.

Regstrapped on x86_64-linux-gnu and cross-tested for x86_64-vx7r2 along
with other patches, mostly for the testsuite.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/i386/pr97313.c: Require effective target feature pie.
* g++.target/i386/pr94185.C: Likewise.
---
 gcc/testsuite/g++.target/i386/pr94185.C |1 +
 gcc/testsuite/gcc.target/i386/pr97313.c |1 +
 2 files changed, 2 insertions(+)

diff --git a/gcc/testsuite/g++.target/i386/pr94185.C 
b/gcc/testsuite/g++.target/i386/pr94185.C
index 2b3f7a1d676bd..ed3998010ae39 100644
--- a/gcc/testsuite/g++.target/i386/pr94185.C
+++ b/gcc/testsuite/g++.target/i386/pr94185.C
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fPIE -fstack-protector-strong" } */
+/* { dg-require-effective-target pie } */
 
 struct a {
   int b;
diff --git a/gcc/testsuite/gcc.target/i386/pr97313.c 
b/gcc/testsuite/gcc.target/i386/pr97313.c
index ef93cf1cca8f4..711766b413211 100644
--- a/gcc/testsuite/gcc.target/i386/pr97313.c
+++ b/gcc/testsuite/gcc.target/i386/pr97313.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fPIE" } */
+/* { dg-require-effective-target pie } */
 
 typedef struct {
   int unspecified : 1;

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Re: tighten funcspec regexps

[Uros Bizjak via Gcc-patches]

On Wed, Mar 24, 2021 at 7:51 AM Alexandre Oliva  wrote:
>
>
> In -mcmodel=large, callee symbols are pulled ahead of the call insns.
>
> The patterns in funcspec-[12].c tests in gcc.target/i386 match even
> line breaks between 'call' and a function symbol expected to be
> called, however, so it ends up unexpectedly matching a previous,
> unrelated indirect call, up to the insn that loads the address of the
> intended callee to a register, for all but the first callee, that
> doesn't have a call insn before it.
>
> All of these apparent passes are false positives.  We are NOT
> generating the expected call insns.
>
> This patch fixes only the patterns, so that they won't trigger false
> positives any more.  There are several dozens of other tests that fail
> with -mcmodel=large for similar reasons, but I'm still not sure about
> how to deal with them.  I see no point in holding up this small
> improvement over the lack of a larger solution of a different problem,
> though.
>
> Regstrapped on x86_64-linux-gnu and cross-tested for x86_64-vx7r2 along
> with other patches, mostly for the testsuite.  Ok to install?
>
>
> for  gcc/testsuite/ChangeLog
>
> * gcc.target/i386/funcspec-2.c: Tighten regexps to avoid false
> positives with -mcmodel=large.
> * gcc.target/i386/funcspec-3.c: Likewise.

OK.

Thanks,
Uros.

> ---
>  gcc/testsuite/gcc.target/i386/funcspec-2.c |   16 
>  gcc/testsuite/gcc.target/i386/funcspec-3.c |6 +++---
>  2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/i386/funcspec-2.c 
> b/gcc/testsuite/gcc.target/i386/funcspec-2.c
> index d607fbc79c91d..147f62321fd77 100644
> --- a/gcc/testsuite/gcc.target/i386/funcspec-2.c
> +++ b/gcc/testsuite/gcc.target/i386/funcspec-2.c
> @@ -89,11 +89,11 @@ int main ()
>  /* { dg-final { scan-assembler "vfnmaddsd" } } */
>  /* { dg-final { scan-assembler "vfnmsubss" } } */
>  /* { dg-final { scan-assembler "vfnmsubsd" } } */
> -/* { dg-final { scan-assembler "call\t(.*)flt_mul_add" } } */
> -/* { dg-final { scan-assembler "call\t(.*)flt_mul_sub" } } */
> -/* { dg-final { scan-assembler "call\t(.*)flt_neg_mul_add" } } */
> -/* { dg-final { scan-assembler "call\t(.*)flt_neg_mul_sub" } } */
> -/* { dg-final { scan-assembler "call\t(.*)dbl_mul_add" } } */
> -/* { dg-final { scan-assembler "call\t(.*)dbl_mul_sub" } } */
> -/* { dg-final { scan-assembler "call\t(.*)dbl_neg_mul_add" } } */
> -/* { dg-final { scan-assembler "call\t(.*)dbl_neg_mul_sub" } } */
> +/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)flt_mul_add" } } */
> +/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)flt_mul_sub" } } */
> +/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)flt_neg_mul_add" } } */
> +/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)flt_neg_mul_sub" } } */
> +/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)dbl_mul_add" } } */
> +/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)dbl_mul_sub" } } */
> +/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)dbl_neg_mul_add" } } */
> +/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)dbl_neg_mul_sub" } } */
> diff --git a/gcc/testsuite/gcc.target/i386/funcspec-3.c 
> b/gcc/testsuite/gcc.target/i386/funcspec-3.c
> index 613a1a0fb9521..8fb425b925add 100644
> --- a/gcc/testsuite/gcc.target/i386/funcspec-3.c
> +++ b/gcc/testsuite/gcc.target/i386/funcspec-3.c
> @@ -63,6 +63,6 @@ int main ()
>  /* { dg-final { scan-assembler "popcntl" { target { ! *-*-darwin* } } } } */
>  /* { dg-final { scan-assembler "popcntq" { target { ! *-*-darwin* } } } } */
>  /* { dg-final { scan-assembler-times "popcnt" 2 { target *-*-darwin* } } } */
> -/* { dg-final { scan-assembler "call\t(.*)sse4a_pop_i" } } */
> -/* { dg-final { scan-assembler "call\t(.*)sse42_pop_l" } } */
> -/* { dg-final { scan-assembler "call\t(.*)popcountdi2" } } */
> +/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)sse4a_pop_i" } } */
> +/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)sse42_pop_l" } } */
> +/* { dg-final { scan-assembler "call\t(\[^\n\r\]*)popcountdi2" } } */
>
>
> --
> Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
>Free Software Activist GNU Toolchain Engineer
> Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Re: require et feature pie for PIE tests

[Uros Bizjak via Gcc-patches]

On Wed, Mar 24, 2021 at 7:55 AM Alexandre Oliva  wrote:
>
>
> Both of these tests fail on platforms that reject -fPIC/-fPIE
> altogether.
>
> Other tests that perform PIE compilation or linking require the pie
> feature, whether for -fpie/-fPIE compilation or for -pie linking.
>
> This patch annotates both tests with the required target feature.
>
> Regstrapped on x86_64-linux-gnu and cross-tested for x86_64-vx7r2 along
> with other patches, mostly for the testsuite.  Ok to install?
>
>
> for  gcc/testsuite/ChangeLog
>
> * gcc.target/i386/pr97313.c: Require effective target feature pie.
> * g++.target/i386/pr94185.C: Likewise.

OK (even obvious).

Thanks,
Uros.

> ---
>  gcc/testsuite/g++.target/i386/pr94185.C |1 +
>  gcc/testsuite/gcc.target/i386/pr97313.c |1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/gcc/testsuite/g++.target/i386/pr94185.C 
> b/gcc/testsuite/g++.target/i386/pr94185.C
> index 2b3f7a1d676bd..ed3998010ae39 100644
> --- a/gcc/testsuite/g++.target/i386/pr94185.C
> +++ b/gcc/testsuite/g++.target/i386/pr94185.C
> @@ -1,5 +1,6 @@
>  /* { dg-do compile } */
>  /* { dg-options "-O2 -fPIE -fstack-protector-strong" } */
> +/* { dg-require-effective-target pie } */
>
>  struct a {
>int b;
> diff --git a/gcc/testsuite/gcc.target/i386/pr97313.c 
> b/gcc/testsuite/gcc.target/i386/pr97313.c
> index ef93cf1cca8f4..711766b413211 100644
> --- a/gcc/testsuite/gcc.target/i386/pr97313.c
> +++ b/gcc/testsuite/gcc.target/i386/pr97313.c
> @@ -1,5 +1,6 @@
>  /* { dg-do compile } */
>  /* { dg-options "-O2 -fPIE" } */
> +/* { dg-require-effective-target pie } */
>
>  typedef struct {
>int unspecified : 1;
>
> --
> Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
>Free Software Activist GNU Toolchain Engineer
> Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

run sysconf-requiring test on systems that support it

[Alexandre Oliva]

The gcc.target/i386 test sse2-mmx-maskmovq.c requires the mmap
feature, but that's not enough for the test to be able to call
sysconf.

I've combined the target triplets used in other sysconf-calling tests,
omitting non-x86 ones, with the preexisting mmap requirement in this
test.

Regstrapped on x86_64-linux-gnu and cross-tested for x86_64-vx7r2 along
with other patches, mostly for the testsuite.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/i386/sse2-mmx-maskmovq.c: Require
sysconf-supporting x86 target triplets.
---
 gcc/testsuite/gcc.target/i386/sse2-mmx-maskmovq.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/i386/sse2-mmx-maskmovq.c 
b/gcc/testsuite/gcc.target/i386/sse2-mmx-maskmovq.c
index 037f665f1178a..ad4bbf7c76451 100644
--- a/gcc/testsuite/gcc.target/i386/sse2-mmx-maskmovq.c
+++ b/gcc/testsuite/gcc.target/i386/sse2-mmx-maskmovq.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target mmap } } */
+/* { dg-do run { target { { *-*-linux* *-*-gnu* *-*-darwin[912]* *-*-uclinux* 
} && mmap } } } */
 /* { dg-options "-O2 -fno-strict-aliasing -msse2" } */
 /* { dg-additional-options "-mno-mmx" { target { ! ia32 } } } */
 

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar