Re: [PATCH] x86: Update -mtune=tremont

[Uros Bizjak via Gcc-patches]

On Thu, Dec 9, 2021 at 7:59 AM Cui,Lili  wrote:
>
> Hi Uros,
>
> This patch is to update mtune for tremont.
>
> Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
>
> OK for master?

OK.

Thanks,
Uros.

>
>
> Silvermont has a special handle in add_stmt_cost function, because it has in
> order SIMD pipeline. But for Tremont, its SIMD pipeline is out of order,
> remove Tremont from this special handle.
>
> gcc/ChangeLog
>
> * config/i386/i386.c (ix86_vector_costs::add_stmt_cost): Remove Tremont.
> ---
>  gcc/config/i386/i386.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index f1e41fd55f9..9f4ed34ffd5 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -23144,8 +23144,7 @@ ix86_vector_costs::add_stmt_cost (int count, 
> vect_cost_for_stmt kind,
>   for Silvermont as it has out of order integer pipeline and can execute
>   2 scalar instruction per tick, but has in order SIMD pipeline.  */
>if ((TARGET_CPU_P (SILVERMONT) || TARGET_CPU_P (GOLDMONT)
> -   || TARGET_CPU_P (GOLDMONT_PLUS) || TARGET_CPU_P (TREMONT)
> -   || TARGET_CPU_P (INTEL))
> +   || TARGET_CPU_P (GOLDMONT_PLUS) || TARGET_CPU_P (INTEL))
>&& stmt_info && stmt_info->stmt)
>  {
>tree lhs_op = gimple_get_lhs (stmt_info->stmt);
> --
> 2.17.1
>
> Thanks,
> Lili.

Re: Improve -fprofile-report

[Martin Liška]

On 12/3/21 10:28, Jan Hubicka wrote:

|Do you know how to get that name? With the numbers it is not too hard to find 
the dump, but I do not mind having it either way.|


Hello.

Let's keep the names as they are. I've just added the tracking to all LNT 
instances.

Cheers,
Martin

Re: [committed 4/4] d: Merge upstream phobos 574bf883b

[Andreas Schwab]

Breaks aarch64:

../../../../libphobos/libdruntime/core/sys/linux/unistd.d:10:15: error: module 
'core.sys.linux.syscalls' import 'SystemCall' not found
   10 | public import core.sys.linux.syscalls : SystemCall;
  |   ^

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

RE: POS Customers Database

[Taylor Germain via Gcc-patches]

Hi,
Apologies for interrupting your busy schedule, I'm following up to check if you 
had a chance to review my previous email. Do let me know your interest and we 
shall provide you further details for your perusal.
Waiting for your response.
Best Regards,
Taylor Germain

From: Taylor Germain
Sent: Tuesday, November 16, 2021 6:09 AM
To: 'gcc-patches@gcc.gnu.org' 
Subject: POS Customers Database

Hi,

I was in your website, and I got to know that you are one of the Point Of sales 
(POS) company. We can help you in providing customers/users and competitors' 
business contacts across USA and worldwide which includes entire business 
details that you would require.


Technology Product we track
Number of Users
Square POS
14028
Aloha POS
4852
Lightspeed Retail
1247
Maropost
1547
Total: 21674


If this sounds of any value, please specify your requirement in detail so that 
I can get back to you with more information and few samples just for your 
review.

I look forward to hearing from you soon.

Regards,

Taylor Germain |Business Manager - Partnership Development

As this is not an auto generated email, to discontinue receiving email from us 
reply as "Exclude"

Re: [PATCH] OpenMP: Ensure that offloaded variables are public

[Andrew Stubbs]

On 02/12/2021 16:43, Jakub Jelinek wrote:

On Thu, Dec 02, 2021 at 04:31:36PM +, Andrew Stubbs wrote:

On 02/12/2021 16:05, Andrew Stubbs wrote:

On 02/12/2021 12:58, Jakub Jelinek wrote:

I've tried modifying offload_handle_link_vars but that spot
doesn't catch
the omp_data_sizes variables emitted by
libgomp.c-c++-common/target_42.c,
which was one of the motivating examples.


Why doesn't catch it?  Is the variable created only post-IPA?
I'd think that it should have been created before IPA, streamed and
therefore I don't understand why you don't see it after streaming LTO in.


On closer inspection it does, in fact, catch it as you'd expect, but
then the variable is no longer marked public when it gets to
pass_omp_target_link::execute, so something somewhere is resetting it.
More investigation is needed


The "whole-program" pass is removing the public flag. That's probably
working as intended, and I assume it is run for offload code on purpose?


So you'd stick it somewhere into e.g. symbol_table::compile
after ipa_passes call, guarded with #ifdef ACCEL_COMPILER ?


I've given up on this approach, and switched to loading the symbol 
addresses from the table directly. The relocation issues that I had with 
older assemblers/linkers do not seem to be a problem any more.


This patch requires only a single symbol to be forced global, and since 
that's one that I create in mkoffload there is no issue with previous 
definitions.


I think I can approve this myself, but if you have any observations I'm 
happy to hear them.


Andrewamdgcn: Change offload variable table discovery

Up to now the libgomp GCN plugin has been finding the offload variables
by using a symbol lookup, but the AMD runtime requires that the symbols are
global for that to work. This was ensured by mkoffload as a post-procssing
step, but the LLVM 13 assembler no longer accepts this in the case where the
variable was previously declared differently.

This patch switches to locating the symbols directly from the
offload_var_table, which means that only one symbol needs to be forced
global.

This changes breaks the libgomp image compatibility so GOMP_VERSION_GCN has
also been bumped.

gcc/ChangeLog:

* config/gcn/mkoffload.c (process_asm): Process the variable table
completely differently.
(process_obj): Encode the varaible data differently.

include/ChangeLog:

* gomp-constants.h (GOMP_VERSION_GCN): Bump.

libgomp/ChangeLog:

* plugin/plugin-gcn.c (struct gcn_image_desc): Remove global_variables.
(GOMP_OFFLOAD_load_image): Locate the offload variables via the
table, not individual symbols.

diff --git a/gcc/config/gcn/mkoffload.c b/gcc/config/gcn/mkoffload.c
index b2e71ea5aa0..d609b7a6f9c 100644
--- a/gcc/config/gcn/mkoffload.c
+++ b/gcc/config/gcn/mkoffload.c
@@ -495,10 +495,8 @@ static void
 process_asm (FILE *in, FILE *out, FILE *cfile)
 {
   int fn_count = 0, var_count = 0, dims_count = 0, regcount_count = 0;
-  struct obstack fns_os, vars_os, varsizes_os, dims_os, regcounts_os;
+  struct obstack fns_os, dims_os, regcounts_os;
   obstack_init (&fns_os);
-  obstack_init (&vars_os);
-  obstack_init (&varsizes_os);
   obstack_init (&dims_os);
   obstack_init (®counts_os);
 
@@ -567,16 +565,11 @@ process_asm (FILE *in, FILE *out, FILE *cfile)
unsigned varsize;
if (sscanf (buf, " .8byte %ms\n", &varname))
  {
-   obstack_ptr_grow (&vars_os, varname);
+   fputs (buf, out);
fgets (buf, sizeof (buf), in);
if (!sscanf (buf, " .8byte %u\n", &varsize))
  abort ();
-   obstack_int_grow (&varsizes_os, varsize);
var_count++;
-
-   /* The HSA Runtime cannot locate the symbol if it is not
-  exported from the kernel.  */
-   fprintf (out, "\t.global %s\n", varname);
  }
break;
  }
@@ -595,7 +588,19 @@ process_asm (FILE *in, FILE *out, FILE *cfile)
 
   char dummy;
   if (sscanf (buf, " .section .gnu.offload_vars%c", &dummy) > 0)
-   state = IN_VARS;
+   {
+ state = IN_VARS;
+
+ /* Add a global symbol to allow plugin-gcn.c to locate the table
+at runtime.  It can't use the "offload_var_table.N" emitted by
+the compiler because a) they're not global, and b) there's one
+for each input file combined into the binary.  */
+ fputs (buf, out);
+ fputs ("\t.global .offload_var_table\n"
+"\t.type .offload_var_table, @object\n"
+".offload_var_table:\n",
+out);
+   }
   else if (sscanf (buf, " .section .gnu.offload_funcs%c", &dummy) > 0)
state = IN_FUNCS;
   else if (sscanf (buf, " .amdgpu_metadata%c", &dummy) > 0)
@@ -622,7 +627,7 @@ process_asm (FILE *in, FILE *out, FILE *cfile)
  regcount.sgpr_count = regcount.vgpr_count = -1;
}

Re: [committed] libstdc++: Fix undefined shift when _Atomic_word is 64-bit

[Rainer Orth]

Hi Jonathan,

>> > Ah yes, so we need to disable this optimization. Patch coming up ...
>>
>> Gah, I remembered to check that:
>>
>>   constexpr bool __double_word
>> = sizeof(long long) == 2 * sizeof(_Atomic_word);
>>   // The ref-count members follow the vptr, so are aligned to
>>   // alignof(void*).
>>   constexpr bool __aligned = __alignof(long long) <= alignof(void*);
>>   if _GLIBCXX17_CONSTEXPR (__lock_free && __double_word && __aligned)
>>
>>
>> But for C++11 and C++14 that is a normal runtime condition not
>> if-constexpr, so the undefined shift still gets compiled, even though
>> it can never be reached at runtime.
>
> Fixed like so. Tested sparc-sun-solaris2.11, pushed to trunk.

great, thanks a lot.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] OpenMP: Ensure that offloaded variables are public

[Jakub Jelinek via Gcc-patches]

On Thu, Dec 09, 2021 at 11:41:46AM +, Andrew Stubbs wrote:
> gcc/ChangeLog:
> 
>   * config/gcn/mkoffload.c (process_asm): Process the variable table
>   completely differently.
>   (process_obj): Encode the varaible data differently.
> 
> include/ChangeLog:
> 
>   * gomp-constants.h (GOMP_VERSION_GCN): Bump.
> 
> libgomp/ChangeLog:
> 
>   * plugin/plugin-gcn.c (struct gcn_image_desc): Remove global_variables.
>   (GOMP_OFFLOAD_load_image): Locate the offload variables via the
>   table, not individual symbols.

I'm very happy this worked out.  LGTM, but sure, you can approve it
yourself.

Jakub

Re: [PATCH] Loop unswitching: support gswitch statements.

[Martin Liška]

On 12/3/21 15:09, Andrew MacLeod wrote:

On 12/2/21 11:02, Martin Liška wrote:

On 12/2/21 15:27, Andrew MacLeod wrote:

ranger->gori().outgoing_edge_range_p (irange &r, edge e, tree name, 
*get_global_range_query ());


Thank you! It works for me!

Martin


btw, this applies to names not  on the stmt as well.   The function returns 
TRUE if there is an outgoing range calculable, and false if not.  so:

a = b + 20
if (a > 40)    <- returns TRUE for outgoing range of 'a' or 'b'
     {
    c = foo()
    if (c > 60)   <- returns false for 'a' or 'b'
    {
    if (b < 100)   <- Also returns TRUE for 'a' or 'b'


Hello.

That's quite interesting support. However, for the bug mentioned earlier in 
this email conversion,
I only want local range for a gcond/gswitch, ignoring all path leading to the 
statement.

Martin



The final block, from the EVRP dump:

      :
     if (b_4(D) <= 99)
   goto ; [INV]
     else
   goto ; [INV]

4->5  (T) b_4(D) :  unsigned int [21, 99]
4->5  (T) a_5 : unsigned int [41, 119]
4->6  (F) b_4(D) :  unsigned int [100, 4294967275]
4->6  (F) a_5 : unsigned int [120, +INF]

Shows that it has a range for both 'a' and 'b'.

Just to point out that you can use this query on any conditional edge, even if 
it isnt directly mentioned on the stmt.  so if you are keying of 'a', you could 
simply ask if outgoing_edge_range_p ( , a,...)  rather than parsing the 
condition to see if 'a' is on it.   if there is no chance that 'a' is affected 
by the block, is just returns false.

When its called directly like this, it picks up no ranges from outside the 
basic block you are querying, except via that range query you provide. The 
listing shows the defaultwhic is whatever ranger knows. So if you provided 
get_global_range_query, those ranges would instead be something like:

4->5  (T) b_4(D) :  unsigned int [0, 99]
4->5  (T) a_5 : unsigned int [21, 119]
4->6  (F) b_4(D) :  unsigned int [100, +INF]
4->6  (F) a_5 : unsigned int [0,20] [120, +INF-20 ]

It may simplify things a little if you are unswitching on 'a', you can just ask 
each block with a condition whether 'a's range can be modified

Andrew.

Re: [PATCH] Loop unswitching: support gswitch statements.

[Martin Liška]

On 11/30/21 12:17, Richard Biener wrote:

I'd like to see the gswitch support - that's what was posted before stage3
close, this patch on its own doesn't seem worth pushing for.  That said,
I have some comments below (and the already raised ones about how
things might need to change with gswitch support).  Is it so difficult to
develop gswitch support as a separate change ontop of this?


Hello.

Took me some time, but I have a working version of the patch that makes both
refactoring of the costing model and adds support for gswitch. For quite some
time, I maintained 2 patches, but as commonly happens, I was forced doing quite
some rework. If we really want a separation for bisection purpose, I suggest 
simple
disabling of gswitch support?

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
SPEC 2006 and 2017 survive running -O3 -march=native. There are 2090 
optimization notes
for SPEC 2006 (compared to 1945 before the patch).

Thoughts?
Thanks,
MartinFrom 346f01f6a1812177631bce8896b57de4b1fa9c3f Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 22 Nov 2021 13:54:20 +0100
Subject: [PATCH] Loop unswitching: refactoring & support for gswitch

gcc/ChangeLog:

	* dbgcnt.def (DEBUG_COUNTER): Add loop_unswitch counter.
	* tree-cfg.c (gimple_lv_add_condition_to_bb): Support not
	gimplified expressions.
	* tree-ssa-loop-unswitch.c (struct unswitch_predicate): New.
	(tree_unswitch_single_loop): Rework the function using
	pre-computed predicates.
	(tree_may_unswitch_on): Rename to ...
	(find_unswitching_predicates_for_bb): ... this.
	(clean_up_after_unswitching): New.
	(get_predicates_for_bb): Likewise.
	(set_predicates_for_bb): Likewise.
	(init_loop_unswitch_info): Likewise.
	(tree_ssa_unswitch_loops): Prepare stuff before calling
	tree_unswitch_single_loop.
	(merge_last): New.
	(add_predicate_to_path): Likewise.
	(find_range_for_lhs): Likewise.
	(simplify_using_entry_checks): Rename to ...
	(evaluate_control_stmt_using_entry_checks): ... this.
	(simplify_loop_version): Rework.
	(evaluate_insns): New.
	(evaluate_loop_insns_for_predicate): Likewise.
	(tree_unswitch_loop): Remove an assert.

gcc/testsuite/ChangeLog:

	* gcc.dg/loop-unswitch-10.c: New test.
	* gcc.dg/loop-unswitch-11.c: New test.
	* gcc.dg/loop-unswitch-12.c: New test.
	* gcc.dg/loop-unswitch-13.c: New test.
	* gcc.dg/loop-unswitch-6.c: New test.
	* gcc.dg/loop-unswitch-7.c: New test.
	* gcc.dg/loop-unswitch-8.c: New test.
	* gcc.dg/loop-unswitch-9.c: New test.
---
 gcc/dbgcnt.def  |   1 +
 gcc/testsuite/gcc.dg/loop-unswitch-10.c |  56 ++
 gcc/testsuite/gcc.dg/loop-unswitch-11.c |  45 ++
 gcc/testsuite/gcc.dg/loop-unswitch-12.c |  28 +
 gcc/testsuite/gcc.dg/loop-unswitch-13.c |  34 +
 gcc/testsuite/gcc.dg/loop-unswitch-6.c  |  60 ++
 gcc/testsuite/gcc.dg/loop-unswitch-7.c  |  28 +
 gcc/testsuite/gcc.dg/loop-unswitch-8.c  |  31 +
 gcc/testsuite/gcc.dg/loop-unswitch-9.c  |  27 +
 gcc/tree-cfg.c  |   7 +-
 gcc/tree-ssa-loop-unswitch.c| 935 ++--
 11 files changed, 1044 insertions(+), 208 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/loop-unswitch-10.c
 create mode 100644 gcc/testsuite/gcc.dg/loop-unswitch-11.c
 create mode 100644 gcc/testsuite/gcc.dg/loop-unswitch-12.c
 create mode 100644 gcc/testsuite/gcc.dg/loop-unswitch-13.c
 create mode 100644 gcc/testsuite/gcc.dg/loop-unswitch-6.c
 create mode 100644 gcc/testsuite/gcc.dg/loop-unswitch-7.c
 create mode 100644 gcc/testsuite/gcc.dg/loop-unswitch-8.c
 create mode 100644 gcc/testsuite/gcc.dg/loop-unswitch-9.c

diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def
index f8a15f3d1d1..278fb1112b3 100644
--- a/gcc/dbgcnt.def
+++ b/gcc/dbgcnt.def
@@ -187,6 +187,7 @@ DEBUG_COUNTER (ira_move)
 DEBUG_COUNTER (ivopts_loop)
 DEBUG_COUNTER (lim)
 DEBUG_COUNTER (local_alloc_for_sched)
+DEBUG_COUNTER (loop_unswitch)
 DEBUG_COUNTER (match)
 DEBUG_COUNTER (merged_ipa_icf)
 DEBUG_COUNTER (phiopt_edge_range)
diff --git a/gcc/testsuite/gcc.dg/loop-unswitch-10.c b/gcc/testsuite/gcc.dg/loop-unswitch-10.c
new file mode 100644
index 000..2ab196b527f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/loop-unswitch-10.c
@@ -0,0 +1,56 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -funswitch-loops -fdump-tree-unswitch-optimized" } */
+
+int
+__attribute__((noipa))
+foo(double *a, double *b, double *c, double *d, double *r, int size, int order)
+{
+  for (int i = 0; i < size; i++)
+  {
+double tmp, tmp2;
+
+switch(order)
+{
+  case 0:
+tmp = -8 * a[i];
+tmp2 = 2 * b[i];
+break;
+  case 1: 
+tmp = 3 * a[i] -  2 * b[i];
+tmp2 = 5 * b[i] - 2 * c[i];
+break;
+  case 2:
+tmp = 9 * a[i] +  2 * b[i] + c[i];
+tmp2 = 4 * b[i] + 2 * c[i] + 8 * d[i];
+break;
+  case 3:
+tmp = 3 * a[i] +  2 * b[i] - c[i];
+tmp2 = b[i] - 2 * c[i] + 8 * d[i];
+break;
+  defaut:
+__builtin_unreachable ();
+}
+
+dou

[PATCH] libstdc++: Some time_get fixes [PR78714]

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch is an attempt to fix various time_get related issues.
Sorry, it is long...

One of them is PR78714.  It seems _M_extract_via_format has been written
with how strftime behaves in mind rather than how strptime behaves.
There is a significant difference between the two, for strftime %a and %A
behave differently etc., one emits an abbreviated name, the other full name.
For strptime both should behave the same and accept both the full or
abbreviated names.  This needed large changes in _M_extract_name, which
was assuming the names are unique and names aren't prefixes of other names.
The _M_extract_name changes allow to deal with those cases.  As can be
seen in the new testcase, e.g. for %b and english locales we need to
accept both Apr and April.  If we see Apr in the input, the code looks
at whether there is end right after those 3 chars or if the next
character doesn't match characters in the longer names; in that case
it accepts the abbreviated name.  Otherwise, if the input has Apri, it
commits to a longer name and fails if it isn't April.  This behavior is
different from strptime, which for %bix and Aprix accepts it, but for
an input iterator I'm afraid we can't do better, we can't go back (peek
more than the current character).

Another case is that %d and %e in strptime should work the same, while
previously the code was hardcoding that %d would be 01 to 31 and %e
 1 to 31 (with leading 0 replaced by space).
strptime POSIX 2009 documentation seems to suggest for numbers it should
accept up to the specified number of digits rather than exactly that number
of digits:
The pattern "[x,y]" indicates that the value shall fall within the range
given (both bounds being inclusive), and the maximum number of characters 
scanned
shall be the maximum required to represent any value in the range without 
leading
zeros.
so by my reading "1:" is valid for "%H:".
The glibc strptime implementation actually skips any amount of whitespace
in all the cases where a number is read, my current patch skips a single
space at the start of %d/%e but not the others, but doesn't subtract the
space length from the len characters.
One option would be to do the leading whitespace skipping in _M_extract_num
but take it into account how many digits can be read.
This matters for " 12:" and "%H:", but not for " 12:" and " %H:"
as in the latter case the space in the format string results in all the
whitespace at the start to be consumed.
Note, the allowing of a single digit rather than 2 changes a behavior in
other ways, e.g. when seeing 40 in a number for range [1, 31] we reject
it as before, but previously we'd keep *ret == '4' because it was assuming
it has to be 2 digits and 40 isn't valid, so we know error already on the
4, but now we accept the 4 as value and fail iff the next format string
doesn't match the 0.
Also, previously it wasn't really checking the number was in the right
range, it would accept 00 for [1, 31] numbers, or would accept 39.

Another thing is that %I was parsing 12 as tm_hour 12 rather than as tm_hour 0
like e.g. glibc does.

Another thing is that %t was matching a single tab and %n a single newline,
while strptime docs say it skips over whitespace (again, zero or more).

Another thing is that %p wasn't handled at all, I think this was the main
cause of
FAIL: 22_locale/time_get/get_time/char/2.cc execution test
FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test
FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/2.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_env.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test
before this patch, because en_HK* locales do use %I and %p in it.
The patch handles %p only if it follows %I (i.e. when the hour is parsed
first), which is the more usual case (in glibc):
grep '%I' localedata/locales/* | grep '%I.*%p' | wc -l
282
grep '%I' localedata/locales/* | grep -v '%I.*%p' | wc -l
44
grep '%I' localedata/locales/* | grep -v '%p' | wc -l
17
The last case use %P instead of %p in t_fmt_ampm, not sure if that one
is never used by strptime because %P isn't handled by strptime.
Anyway, the right thing to handle even %p%I would be to pass some state
around through all the _M_extract_via_format calls like glibc passes
  struct __strptime_state
  {
unsigned int have_I : 1;
unsigned int have_wday : 1;
unsigned int have_yday : 1;
unsigned int have_mon : 1;
unsigned int have_mday : 1;
unsigned int have_uweek : 1;
unsigned int have_wweek : 1;
unsigned int is_pm : 1;
unsigned int want_century : 1;
unsigned int want_era : 1;
unsigned int want_xday : 1;
enum ptime_locale_status decided : 2;
signed char week_no;
signed char century;
int era_cnt;
  } s;
around.  That is for the %p case used like:
  if (s.have_I && s.is_pm)
tm->tm_hour += 12;
during finalization, but hand

Re: [PATCH] Loop unswitching: support gswitch statements.

[Andrew MacLeod via Gcc-patches]

On 12/9/21 07:59, Martin Liška wrote:

On 12/3/21 15:09, Andrew MacLeod wrote:

On 12/2/21 11:02, Martin Liška wrote:

On 12/2/21 15:27, Andrew MacLeod wrote:
ranger->gori().outgoing_edge_range_p (irange &r, edge e, tree name, 
*get_global_range_query ());


Thank you! It works for me!

Martin

btw, this applies to names not  on the stmt as well.   The function 
returns TRUE if there is an outgoing range calculable, and false if 
not.  so:


a = b + 20
if (a > 40)    <- returns TRUE for outgoing range of 'a' or 'b'
 {
    c = foo()
    if (c > 60)   <- returns false for 'a' or 'b'
    {
    if (b < 100)   <- Also returns TRUE for 'a' or 'b'


Hello.

That's quite interesting support. However, for the bug mentioned 
earlier in this email conversion,
I only want local range for a gcond/gswitch, ignoring all path leading 
to the statement.


Martin 
In which case just directly invoking gori with the global range query 
should be fine.   You could go directly to the lower level routines like 
gimple_range_calc_op1, but this saves you from doing a little footwork 
to call them.  Ultimately, it works out the same for you on the true 
side of

if (a > 40)
as  setting up and invoking:

   if (gimple_range_calc_op1  (r, stmt, int_range<2> 
(boolean_true_node, boolean_true_node), [40,40])


Its just less work to do it thru gori()->outgoing_edge_range_p ()   :-)

Andrew

Re: [PATCH] pch: Add support for relocation of the PCH data [PR71934]

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 08, 2021 at 08:00:03AM +, Iain Sandoe wrote:
> > On 7 Dec 2021, at 14:50, Jakub Jelinek via Gcc-patches 
> >  wrote:
> The attached patch should be applied before (or merged with) the change for
> relocation when it is applied - since the operation of the PCH hooks needs 
> some
> adjustment on Darwin.

Oops, didn't do this change and therefore likely broke Darwin and apparently
HP-UX.
Went through other targets and they don't do this reading in there and so
aren't problematic.  Of course, as I said before, to enable relocation
support one has to do minor changes to the hook not to fail on those but
update the reference parameter.

I've committed following which should hopefully unbreak it (untested),
please go ahead with your patch without the last hunk incrementally when
you're ready.

2021-12-09  Jakub Jelinek  

PR pch/71934
* config/host-darwin.c (darwin_gt_pch_use_address): When reading
manually the file into mapped area, update mapped_addr as
an automatic variable rather than addr which is a reference parameter.
* config/host-hpux.c (hpux_gt_pch_use_address): When reading
manually the file into mapped area, update addr as
an automatic variable rather than base which is a reference parameter.

--- gcc/config/host-darwin.c.jj 2021-12-09 15:40:06.232022601 +0100
+++ gcc/config/host-darwin.c2021-12-09 15:48:51.397467287 +0100
@@ -185,10 +185,10 @@ darwin_gt_pch_use_address (void *&addr,
 {
   ssize_t nbytes;
 
-  nbytes = read (fd, addr, MIN (sz, (size_t) -1 >> 1));
+  nbytes = read (fd, mapped_addr, MIN (sz, (size_t) -1 >> 1));
   if (nbytes <= 0)
return -1;
-  addr = (char *) addr + nbytes;
+  mapped_addr = (char *) mapped_addr + nbytes;
   sz -= nbytes;
 }
 
--- gcc/config/host-hpux.c.jj   2021-12-09 15:40:06.251022328 +0100
+++ gcc/config/host-hpux.c  2021-12-09 15:49:25.464977378 +0100
@@ -115,10 +115,10 @@ hpux_gt_pch_use_address (void *&base, si
 {
   ssize_t nbytes;
 
-  nbytes = read (fd, base, MIN (size, SSIZE_MAX));
+  nbytes = read (fd, addr, MIN (size, SSIZE_MAX));
   if (nbytes <= 0)
 return -1;
-  base = (char *) base + nbytes;
+  addr = (char *) addr + nbytes;
   size -= nbytes;
 }
 


Jakub

Re: [PATCH] pch: Add support for relocation of the PCH data [PR71934]

[Iain Sandoe via Gcc-patches]

> On 9 Dec 2021, at 14:59, Jakub Jelinek  wrote:
> 
> On Wed, Dec 08, 2021 at 08:00:03AM +, Iain Sandoe wrote:
>>> On 7 Dec 2021, at 14:50, Jakub Jelinek via Gcc-patches 
>>>  wrote:
>> The attached patch should be applied before (or merged with) the change for
>> relocation when it is applied - since the operation of the PCH hooks needs 
>> some
>> adjustment on Darwin.
> 
> Oops, didn't do this change and therefore likely broke Darwin and apparently
> HP-UX.
> Went through other targets and they don't do this reading in there and so
> aren't problematic.  Of course, as I said before, to enable relocation
> support one has to do minor changes to the hook not to fail on those but
> update the reference parameter.
> 
> I've committed following which should hopefully unbreak it (untested),
> please go ahead with your patch without the last hunk incrementally when
> you're ready.

I was just retesting my patch on top of master - will merge the two.
thanks
Iain
> 
> 2021-12-09  Jakub Jelinek  
> 
>   PR pch/71934
>   * config/host-darwin.c (darwin_gt_pch_use_address): When reading
>   manually the file into mapped area, update mapped_addr as
>   an automatic variable rather than addr which is a reference parameter.
>   * config/host-hpux.c (hpux_gt_pch_use_address): When reading
>   manually the file into mapped area, update addr as
>   an automatic variable rather than base which is a reference parameter.
> 
> --- gcc/config/host-darwin.c.jj   2021-12-09 15:40:06.232022601 +0100
> +++ gcc/config/host-darwin.c  2021-12-09 15:48:51.397467287 +0100
> @@ -185,10 +185,10 @@ darwin_gt_pch_use_address (void *&addr,
> {
>   ssize_t nbytes;
> 
> -  nbytes = read (fd, addr, MIN (sz, (size_t) -1 >> 1));
> +  nbytes = read (fd, mapped_addr, MIN (sz, (size_t) -1 >> 1));
>   if (nbytes <= 0)
>   return -1;
> -  addr = (char *) addr + nbytes;
> +  mapped_addr = (char *) mapped_addr + nbytes;
>   sz -= nbytes;
> }
> 
> --- gcc/config/host-hpux.c.jj 2021-12-09 15:40:06.251022328 +0100
> +++ gcc/config/host-hpux.c2021-12-09 15:49:25.464977378 +0100
> @@ -115,10 +115,10 @@ hpux_gt_pch_use_address (void *&base, si
> {
>   ssize_t nbytes;
> 
> -  nbytes = read (fd, base, MIN (size, SSIZE_MAX));
> +  nbytes = read (fd, addr, MIN (size, SSIZE_MAX));
>   if (nbytes <= 0)
> return -1;
> -  base = (char *) base + nbytes;
> +  addr = (char *) addr + nbytes;
>   size -= nbytes;
> }
> 
> 
> 
>   Jakub
> 

Re: [PATCH] pragma: Update target option node when optimization changes [PR103515]

[Martin Liška]

On 12/7/21 03:15, Kewen.Lin wrote:

Hi,

For a function with optimize pragma, it's possible that the target
options change as optimization options change.  Now we create one
optimization option node when parsing pragma optimize, but don't
create target option node for possible target option changes.  It
makes later processing not detect the target options have actually
changed and doesn't update the target options accordingly.

This patch is to check whether target options have changed when
creating one optimization option node for pragma optimize, and
make one target option node if needed.  The associated test case
shows the difference.  Without this patch, the function foo1 will
perform unrolling which is unexpected.  The reason is that flag
unroll_only_small_loops isn't correctly set for it.  The value
is updated after parsing function foo2, but doesn't get restored
later since both decls don't have DECL_FUNCTION_SPECIFIC_TARGET
set and the hook think we don't need to switch.  With this patch,
there is no unrolling for foo1, which is also consistent with the
behavior by replacing pragma by attribute whether w/ and w/o this
patch.

Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu
and powerpc64{,le}-linux-gnu.

Is it ok for trunk?

BR,
Kewen
---
gcc/ChangeLog:

PR target/103515
* attribs.c (decl_attributes): Check if target options change and
create one node if so.

gcc/testsuite/ChangeLog:

PR target/103515
* gcc.target/powerpc/pr103515.c: New test.

-



Hello.

I do support the patch as it does pretty similar thing to what I did in 
g:ebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e.
The revision was about pragmas.

I can confirm the patch can bootstrap on x86_64-linux-gnu and survives 
regression tests.

Martin

[PATCH v3 2/2][GCC] arm: Declare MVE types internally via pragma

[Murray Steele via Gcc-patches]

Changes from original patch:

1. Make mentioned changes to changelog.
2. Add namespace-end comments.
3. Add #error for when arm-mve-builtins.def is included without
   defining DEF_MVE_TYPE.
4. Make placement of '#undef DEF_MVE_TYPE' consistent.

---

This patch moves the implementation of MVE ACLE types from
arm_mve_types.h to inside GCC via a new pragma, which replaces the prior
type definitions. This allows for the types to be used internally for
intrinsic function definitions.

Bootstrapped and regression tested on arm-none-linux-gnuabihf, and
regression tested on arm-eabi -- no issues.

Thanks,
Murray

gcc/ChangeLog:

* config.gcc: Add arm-mve-builtins.o to extra_objs.
* config/arm/arm-c.c (arm_pragma_arm): Handle "#pragma GCC arm".
(arm_register_target_pragmas): Register it.
* config/arm/arm-protos.h: (arm_mve::arm_handle_mve_types_h): New
prototype.
* config/arm/arm_mve_types.h: Replace MVE type definitions with
new pragma.
* config/arm/t-arm: (arm-mve-builtins.o): New target rule.
* config/arm/arm-mve-builtins.cc: New file.
* config/arm/arm-mve-builtins.def: New file.
* config/arm/arm-mve-builtins.h: New file.

gcc/testsuite/ChangeLog:

* gcc.target/arm/mve/mve.exp: Add new subdirectories.
* gcc.target/arm/mve/general-c/type_redef_1.c: New test.
* gcc.target/arm/mve/general/double_pragmas_1.c: New test.
* gcc.target/arm/mve/general/nomve_1.c: New test.diff --git a/gcc/config.gcc b/gcc/config.gcc
index 
edd12655c4a1e6feb09aabbee77eacd9f66b4171..0aa386403112eff80cb5071fa6ff2fdbe610c9fc
 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -352,14 +352,14 @@ arc*-*-*)
;;
 arm*-*-*)
cpu_type=arm
-   extra_objs="arm-builtins.o aarch-common.o"
+   extra_objs="arm-builtins.o arm-mve-builtins.o aarch-common.o"
extra_headers="mmintrin.h arm_neon.h arm_acle.h arm_fp16.h arm_cmse.h 
arm_bf16.h arm_mve_types.h arm_mve.h arm_cde.h"
target_type_format_char='%'
c_target_objs="arm-c.o"
cxx_target_objs="arm-c.o"
d_target_objs="arm-d.o"
extra_options="${extra_options} arm/arm-tables.opt"
-   target_gtfiles="\$(srcdir)/config/arm/arm-builtins.c"
+   target_gtfiles="\$(srcdir)/config/arm/arm-builtins.c 
\$(srcdir)/config/arm/arm-mve-builtins.h 
\$(srcdir)/config/arm/arm-mve-builtins.cc"
;;
 avr-*-*)
cpu_type=avr
diff --git a/gcc/config/arm/arm-c.c b/gcc/config/arm/arm-c.c
index 
cc7901bca8dc9c5c27ed6afc5bc26afd42689e6d..d1414f6e0e1c2bd0a7364b837c16adf493221376
 100644
--- a/gcc/config/arm/arm-c.c
+++ b/gcc/config/arm/arm-c.c
@@ -28,6 +28,7 @@
 #include "c-family/c-pragma.h"
 #include "stringpool.h"
 #include "arm-builtins.h"
+#include "arm-protos.h"
 
 tree
 arm_resolve_cde_builtin (location_t loc, tree fndecl, void *arglist)
@@ -129,6 +130,24 @@ arm_resolve_cde_builtin (location_t loc, tree fndecl, void 
*arglist)
   return call_expr;
 }
 
+/* Implement "#pragma GCC arm".  */
+static void
+arm_pragma_arm (cpp_reader *)
+{
+  tree x;
+  if (pragma_lex (&x) != CPP_STRING)
+{
+  error ("%<#pragma GCC arm%> requires a string parameter");
+  return;
+}
+
+  const char *name = TREE_STRING_POINTER (x);
+  if (strcmp (name, "arm_mve_types.h") == 0)
+arm_mve::handle_arm_mve_types_h ();
+  else
+error ("unknown %<#pragma GCC arm%> option %qs", name);
+}
+
 /* Implement TARGET_RESOLVE_OVERLOADED_BUILTIN.  This is currently only
used for the MVE related builtins for the CDE extension.
Here we ensure the type of arguments is such that the size is correct, and
@@ -476,6 +495,8 @@ arm_register_target_pragmas (void)
   targetm.target_option.pragma_parse = arm_pragma_target_parse;
   targetm.resolve_overloaded_builtin = arm_resolve_overloaded_builtin;
 
+  c_register_pragma ("GCC", "arm", arm_pragma_arm);
+
 #ifdef REGISTER_SUBTARGET_PRAGMAS
   REGISTER_SUBTARGET_PRAGMAS ();
 #endif
diff --git a/gcc/config/arm/arm-mve-builtins.cc 
b/gcc/config/arm/arm-mve-builtins.cc
new file mode 100644
index 
..71838a83caa417195971114239accc1633c238fb
--- /dev/null
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -0,0 +1,196 @@
+/* ACLE support for Arm MVE
+   Copyright (C) 2021 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   GCC is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */

Re: [PATCH] c++: error message for dependent template members [PR70417]

[Jason Merrill via Gcc-patches]

On 12/4/21 12:23, Anthony Sharp wrote:

Hi Jason,

Hope you are well. Apologies for not coming back sooner.

 >I'd put it just above the definition of saved_token_sentinel in parser.c.

Sounds good, done.

 >Maybe cp_parser_require_end_of_template_parameter_list?  Either way is 
fine.


Even better, have changed it.

 >Hmm, good point; operators that are member functions must be non-static,
 >so we couldn't be doing a comparison of the address of the function.

In that case I have set it to return early there.

 >So declarator_p should be true there.  I'll fix that.

Thank you.

 >> +  if (next_token->keyword == RID_TEMPLATE)
 >> +    {
 >> +      /* But at least make sure it's properly formed (e.g. see 
PR19397).  */

 >> +      if (cp_lexer_peek_nth_token (parser->lexer, 2)->type == CPP_NAME)
 >> +       return 1;
 >> +
 >> +      return -1;
 >> +    }
 >> +
 >> +  /* Could be a ~ referencing the destructor of a class template.  */
 >> +  if (next_token->type == CPP_COMPL)
 >> +    {
 >> +      /* It could only be a template.  */
 >> +      if (cp_lexer_peek_nth_token (parser->lexer, 2)->type == CPP_NAME)
 >> +       return 1;
 >> +
 >> +      return -1;
 >> +    }
 >
 >Why don't these check for the < ?

I think perhaps I could have named the function better; instead of
next_token_begins_template_id, how's about next_token_begins_template_name?
That's all I intended to check for.


You're using it to control whether we try to parse a template-id, and 
it's used to initialize variables named looks_like_template_id, so I 
think better to keep the old name.



In the first case, something like "->template some_name" will always be
intended as a template, so no need to check for the <. If there were default
template arguments you could also validly omit the <> completely, I think
(could be wrong).


Or if the template arguments can be deduced, yes:

template  struct A
{
  template  void f(U u);
};

template  void g(A a)
{
  a->template f(42);
}

But 'f' is still not a template-id.

...

Actually, it occurs to me that you might be better off handling this in 
cp_parser_template_name, something like the below, to avoid the complex 
duplicate logic in the id-expression handling.


Note that in this patch I'm using "any_object_scope" as a proxy for "I'm 
parsing an expression", since !is_declaration doesn't work for that; as 
a result, this doesn't handle the static member function template case. 
For that you'd probably still need to pass down a flag so that 
cp_parser_template_name knows it's being called from 
cp_parser_id_expression.


Your patch has a false positive on

template  struct A { };
template  void f()
{
  A();
};

which my patch checks in_template_argument_list_p to avoid, though 
checking any_object_scope also currently avoids it.


What do you think?

JasonFrom 3022a600514f8adf8706fd286387a5f9f34c06ba Mon Sep 17 00:00:00 2001
From: Jason Merrill 
Date: Wed, 8 Dec 2021 17:24:21 -0500
Subject: [PATCH] handle in cp_parser_template_name
To: gcc-patches@gcc.gnu.org

---
 gcc/cp/parser.c | 41 -
 1 file changed, 36 insertions(+), 5 deletions(-)

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index ed0bae33fc1..6ec9da646cf 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -18546,6 +18546,8 @@ cp_parser_template_name (cp_parser* parser,
   /* cp_parser_lookup_name clears OBJECT_TYPE.  */
   tree scope = (parser->scope ? parser->scope
 		: parser->context->object_type);
+  bool any_object_scope = (parser->context->object_type
+			   || parser->object_scope);
 
   /* Look up the name.  */
   decl = cp_parser_lookup_name (parser, identifier,
@@ -18625,12 +18627,41 @@ cp_parser_template_name (cp_parser* parser,
 	found = true;
 	}
 
-  /* "in a type-only context" */
   if (!found && scope
-	  && tag_type != none_type
-	  && dependentish_scope_p (scope)
-	  && cp_parser_nth_token_starts_template_argument_list_p (parser, 1))
-	found = true;
+	  && processing_template_decl
+	  && cp_parser_nth_token_starts_template_argument_list_p (parser, 1)
+	  && dependentish_scope_p (scope))
+	{
+	  /* "in a type-only context" */
+	  if (tag_type != none_type)
+	found = true;
+	  else if (warn_missing_template_keyword
+		   /* If there's an object scope we know we're in an
+		  expression, not a declarator-id.  FIXME is_declaration
+		  ought to make that distinction for us.  */
+		   && any_object_scope
+		   /* In a template argument list a > could be closing
+		  the enclosing targs.  */
+		   && !parser->in_template_argument_list_p
+		   && !token->error_reported
+		   && warning_enabled_at (token->location,
+	  OPT_Wmissing_template_keyword))
+	{
+	  saved_token_sentinel toks (parser->lexer, STS_ROLLBACK);
+	  if (cp_parser_skip_entire_template_parameter_list (parser)
+		  /* An operator after the > suggests that the > ends a
+		 template-id; a name or literal suggests that the > is an
+		 operator.  */
+		  && (cp_lexer_p

Re: [PATCH v4] c++: Handle auto(x) in parameter-declaration-clause [PR103401]

[Jason Merrill via Gcc-patches]

On 12/8/21 18:23, Marek Polacek wrote:

On Wed, Dec 08, 2021 at 03:09:00PM -0500, Jason Merrill wrote:

On 12/8/21 13:32, Marek Polacek wrote:

On Wed, Dec 08, 2021 at 09:15:05AM -0500, Jason Merrill wrote:

On 12/7/21 19:25, Marek Polacek wrote:

On Mon, Dec 06, 2021 at 04:44:06PM -0500, Jason Merrill wrote:

Please also make this change to cp_parser_sizeof_operand, and add tests
involving sizeof/alignof in array bounds.  OK with that change.


Turns out we reject sizeof(auto(4)) because cp_parser_type_id_1 errors
"invalid use of auto".  So I've added a hack to make it work; auto(x)
is *not* a type-id, so reject that parse and let it be parsed as an
expression.

FWIW, I don't think we need to clear auto_is_implicit_function_template_parm_p
in cp_parser_sizeof_operand for parameters like int[sizeof(auto(10))] because
the auto is in a declarator and auto_is_... will have been cleared already in
cp_parser_parameter_declaration before parsing the declarator.  But I've added
it anyway, maybe there are other cases where it matters.

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

-- >8 --
In C++23, auto(x) is valid, so decltype(auto(x)) should also be valid,
so

 void f(decltype(auto(0)));

should be just as

 void f(int);

but currently, everytime we see 'auto' in a parameter-declaration-clause,
we try to synthesize_implicit_template_parm for it, creating a new template
parameter list.  The code above actually has us calling s_i_t_p twice;
once from cp_parser_decltype_expr -> cp_parser_postfix_expression which
fails and then again from cp_parser_decltype_expr -> cp_parser_expression.
So it looks like we have f and we accept ill-formed code.

This shows that we need to be more careful about synthesizing the
implicit template parameter.  [dcl.spec.auto.general] says that "A
placeholder-type-specifier of the form type-constraintopt auto can be
used as a decl-specifier of the decl-specifier-seq of a
parameter-declaration of a function declaration or lambda-expression..."
so this patch turns off auto_is_... after we've parsed the decl-specifier-seq.

That doesn't quite cut it yet though, because we also need to handle an
auto nested in the decl-specifier:

 void f(decltype(new auto{0}));

therefore the cp_parser_decltype change.

To accept "sizeof(auto{10})", the cp_parser_type_id_1 hunk rejects the
current parse if it sees an auto followed by a ( or {.


The problem here doesn't seem specific to the ( or {, but that we're giving
a hard error in tentative parsing context; I think we want to guard that
error with cp_parser_simulate_error like we do a few lines earlier for class
template placeholders.


I agree that that's generally the approach that makes sense, but in this
case it regresses our diagnostic :(.  For example,

int i = *(auto *) 0;

would give

q.C:1:11: error: expected primary-expression before ‘auto’
  1 | int i = *(auto *) 0;
|   ^~~~
q.C:1:11: error: expected ‘)’ before ‘auto’
  1 | int i = *(auto *) 0;
|  ~^~~~
|   )

instead of the current

q.C:1:11: error: invalid use of ‘auto’
  1 | int i = *(auto *) 0;
|   ^~~~

We just reject the parse in cp_parser_type_id_1 and then give an error in
cp_parser_primary_expression:

cp_parser_error (parser, "expected primary-expression");

I suppose I could add 'case RID_AUTO' to cp_parser_primary_expression and
issue an error there, but that doesn't understand decltype(auto) etc, and
still issues multiple error messages.


Or, maybe it would be OK to actually go with the cp_parser_simulate_error
approach and accept that about 5 tests produce somewhat worse diagnostic.

What's your preference?


Hmm.

auto( could be the beginning of e.g. auto(*)(), which is also a type-id, and
might trip your assert instead of giving an error.


Ah, yes.
  

So I think the latter is the way to go.


Patch attached.

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


OK.


I wonder about some time establishing a pattern in the parser that if a
tentative parse results in error_mark_node without simulating an error, we
repeat the same parse again to get the desired semantic error.  But that's a
big project, not something to address this bug.


Interesting.  How would we handle e.g. the case when sizeof gets something
that isn't a valid type-id, so we reject the parse, try to parse it as an
expression, but that fails too -- parse again as a type-id, this time with
errors?  It will probably be hard to say if it's more of a type-id or more
of an expression.  I hope it would improve our parsing of template arguments
where we sometimes just print "parse error".  :]


I was thinking of situations where the argument is a syntactically valid 
type-id that violates some constraint, as in this case, so we would 
never try to parse as an expression.



-- >8 --
In C++23, auto(x) is valid, so decltype(auto(x)) should also be valid,
so

   void f(decltype(auto(0)));

shoul

Re: Limit inlining functions called once

[Jan Hubicka via Gcc-patches]

> > I plan to reduce the value during before christmas after bit more testing 
> > since
> > it seems to be overall win even if we trade fatigue2 performance, but I 
> > would
> > like to get more testing on larger C++ APPs first.
> 
> Will this hurt -Os -finline-limit=0 ?

Why do you use -finline-limit=0 with -Os?
The patch does affect inlining even with -Os.  On my benchmarks inlining
very large functions is hit or miss code size wise (in pure theory
inlining those should be always a win but it is not - even ignoring
build times we stress regalloc and more likely hit various --param
thresholds)

I guess we could experiment with code size impact and possibly make -Os
defaults to differ from -O defaults like we do for some other params.

Honza
> thanks,

Re: [PATCH 0/6] RFC: adding support to GCC for detecting trust boundaries

[Martin Sebor via Gcc-patches]

On 12/6/21 12:40 PM, Segher Boessenkool wrote:

On Mon, Dec 06, 2021 at 11:12:00AM -0700, Martin Sebor wrote:

On 11/13/21 1:37 PM, David Malcolm via Gcc-patches wrote:

Approach 1: Custom Address Spaces
=

GCC's C frontend supports target-specific address spaces; see:
   https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
Quoting the N1275 draft of ISO/IEC DTR 18037:
   "Address space names are ordinary identifiers, sharing the same name
   space as variables and typedef names.  Any such names follow the same
   rules for scope as other ordinary identifiers (such as typedef names).
   An implementation may provide an implementation-defined set of
   intrinsic address spaces that are, in effect, predefined at the start
   of every translation unit.  The names of intrinsic address spaces must
   be reserved identifiers (beginning with an underscore and an uppercase
   letter or with two underscores).  An implementation may also
   optionally support a means for new address space names to be defined
   within a translation unit."

Patch 1a in the following patch kit for GCC implements such a means to
define new address spaces names in a translation unit, via a pragma:
   #prgama GCC custom_address_space(NAME_OF_ADDRESS_SPACE)

For example, the Linux kernel could perhaps write:

   #define __kernel
   #pragma GCC custom_address_space(__user)
   #pragma GCC custom_address_space(__iomem)
   #pragma GCC custom_address_space(__percpu)
   #pragma GCC custom_address_space(__rcu)

and thus the C frontend can complain about code that mismatches __user
and kernel pointers, e.g.:

custom-address-space-1.c: In function ‘test_argpass_to_p’:
custom-address-space-1.c:29:14: error: passing argument 1 of
‘accepts_p’

>from pointer to non-enclosed address space

29 |   accepts_p (p_user);
   |  ^~
custom-address-space-1.c:21:24: note: expected ‘void *’ but argument is
of type ‘__user void *’
21 | extern void accepts_p (void *);
   |^~
custom-address-space-1.c: In function ‘test_cast_k_to_u’:
custom-address-space-1.c:135:12: warning: cast to ‘__user’ address
space
pointer from disjoint generic address space pointer
   135 |   p_user = (void __user *)p_kernel;
   |^


This seems like an excellent use of named address spaces :)


It has some big problems though.

Named address spaces are completely target-specific.


My understanding of these kernel/user address spaces that David
is adding for the benefit of the analyzer is that the correspond
to what TR 18037 calls nested namespaces.  They're nested within
the generic namespace that's a union of the twp.  With that, I'd
expect them to be fully handled early on and be transparent
afterwards.  Is implementing this idea not feasible in the GCC
design?

Martin


Defining them with
a pragma like this does not allow you to set the pointer mode or
anything related to a custom LEGITIMATE_ADDRESS_P.  It does not allow
you to sayy zero pointers are invalid in some address spaces and not in
others.  You cannot provide any of the DWARF address space stuff this
way.  But most importantly, there are only four bits for the address
space field internally, and they are used by however a backend wants to
use them.

None of this cannot be solved, but all of it will have to be solved.

IMO it will be best to not mix this with address spaces in the user
interface (it is of course fine to *implement* it like that, or with
big overlap at least).


The patch doesn't yet maintain a good distinction between implicit
target-specific address spaces and user-defined address spaces,


And that will have to be fixed in the user code syntax at least.


has at
least one known major bug, and has only been lightly tested.  I can
fix these issues, but was hoping for feedback that this approach is the
right direction from both the GCC and Linux development communities.


Allowing the user to define new address spaces does not jibe well with
how targets do (validly!) use them.


Approach 2: An "untrusted" attribute


Alternatively, patch 1b in the kit implements:

   __attribute__((untrusted))

which can be applied to types as a qualifier (similarly to const,
volatile, etc) to mark a trust boundary, hence the kernel could have:

   #define __user __attribute__((untrusted))

where my patched GCC treats
   T *
vs
   T __attribute__((untrusted)) *
as being different types and thus the C frontend can complain (even without
-fanalyzer) about e.g.:

extern void accepts_p(void *);

void test_argpass_to_p(void __user *p_user)
{
   accepts_p(p_user);
}

untrusted-pointer-1.c: In function ‘test_argpass_to_p’:
untrusted-pointer-1.c:22:13: error: passing argument 1 of ‘accepts_p’

>from pointer with different trust level

22 |   accepts_p(p_user);
   |  ^~
untrusted-pointer-1.c:14:23: note: expected ‘void *’ but argument is of
type ‘__attribute__((untr

Re: [PATCH, v5, OpenMP 5.0] Improve OpenMP target support for C++ [PR92120 v5]

[Chung-Lin Tang]

On 2021/12/4 12:47 AM, Jakub Jelinek wrote:

On Tue, Nov 16, 2021 at 08:43:27PM +0800, Chung-Lin Tang wrote:

2021-11-16  Chung-Lin Tang  

PR middle-end/92120

gcc/cp/ChangeLog:


...

+ if (allow_zero_length_array_sections)
+   {
+ /* When allowing attachment to zero-length array sections, we
+allow attaching to NULL pointers when the target region is not
+mapped.  */
+ data = 0;
+   }


No {}s around single statement if body.

Otherwise LGTM.

Jakub



Thanks for the review and approval, Jakub.

Thomas, I pushed another 2766448c5cc3efc4 commit to fix the non-offload config 
FAILs, just FYI.

Chung-Lin

Re: [PATCH] pch: Add support for relocation of the PCH data [PR71934]

[Christophe Lyon via Gcc-patches]

Hi Jakub,


On Thu, Dec 9, 2021 at 4:00 PM Jakub Jelinek via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> On Wed, Dec 08, 2021 at 08:00:03AM +, Iain Sandoe wrote:
> > > On 7 Dec 2021, at 14:50, Jakub Jelinek via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> > The attached patch should be applied before (or merged with) the change
> for
> > relocation when it is applied - since the operation of the PCH hooks
> needs some
> > adjustment on Darwin.
>
> Oops, didn't do this change and therefore likely broke Darwin and
> apparently
> HP-UX.
>

This also broke aarch64 I think:
In file included from
/tmp/6140018_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/aarch64/aarch64-sve-builtins.cc:3920:0:
./gt-aarch64-sve-builtins.h: In function 'void
gt_pch_p_19registered_function(void*, void*, gt_pointer_operator, void*)':
./gt-aarch64-sve-builtins.h:86:44: error: no matching function for call to
'gt_pch_nx(aarch64_sve::function_instance*, void (*&)(void*, void*, void*),
void*&)'
 gt_pch_nx (&((*x).instance), op, cookie);

Can you check?

Thanks

Christophe



> Went through other targets and they don't do this reading in there and so
> aren't problematic.  Of course, as I said before, to enable relocation
> support one has to do minor changes to the hook not to fail on those but
> update the reference parameter.
>
> I've committed following which should hopefully unbreak it (untested),
> please go ahead with your patch without the last hunk incrementally when
> you're ready.
>
> 2021-12-09  Jakub Jelinek  
>
> PR pch/71934
> * config/host-darwin.c (darwin_gt_pch_use_address): When reading
> manually the file into mapped area, update mapped_addr as
> an automatic variable rather than addr which is a reference
> parameter.
> * config/host-hpux.c (hpux_gt_pch_use_address): When reading
> manually the file into mapped area, update addr as
> an automatic variable rather than base which is a reference
> parameter.
>
> --- gcc/config/host-darwin.c.jj 2021-12-09 15:40:06.232022601 +0100
> +++ gcc/config/host-darwin.c2021-12-09 15:48:51.397467287 +0100
> @@ -185,10 +185,10 @@ darwin_gt_pch_use_address (void *&addr,
>  {
>ssize_t nbytes;
>
> -  nbytes = read (fd, addr, MIN (sz, (size_t) -1 >> 1));
> +  nbytes = read (fd, mapped_addr, MIN (sz, (size_t) -1 >> 1));
>if (nbytes <= 0)
> return -1;
> -  addr = (char *) addr + nbytes;
> +  mapped_addr = (char *) mapped_addr + nbytes;
>sz -= nbytes;
>  }
>
> --- gcc/config/host-hpux.c.jj   2021-12-09 15:40:06.251022328 +0100
> +++ gcc/config/host-hpux.c  2021-12-09 15:49:25.464977378 +0100
> @@ -115,10 +115,10 @@ hpux_gt_pch_use_address (void *&base, si
>  {
>ssize_t nbytes;
>
> -  nbytes = read (fd, base, MIN (size, SSIZE_MAX));
> +  nbytes = read (fd, addr, MIN (size, SSIZE_MAX));
>if (nbytes <= 0)
>  return -1;
> -  base = (char *) base + nbytes;
> +  addr = (char *) addr + nbytes;
>size -= nbytes;
>  }
>
>
>
> Jakub
>
>

Re: [PATCH] pch: Add support for relocation of the PCH data [PR71934]

[Jeff Law via Gcc-patches]

On 12/9/2021 9:42 AM, Christophe Lyon via Gcc-patches wrote:

Hi Jakub,


On Thu, Dec 9, 2021 at 4:00 PM Jakub Jelinek via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:


On Wed, Dec 08, 2021 at 08:00:03AM +, Iain Sandoe wrote:

On 7 Dec 2021, at 14:50, Jakub Jelinek via Gcc-patches <

gcc-patches@gcc.gnu.org> wrote:

The attached patch should be applied before (or merged with) the change

for

relocation when it is applied - since the operation of the PCH hooks

needs some

adjustment on Darwin.

Oops, didn't do this change and therefore likely broke Darwin and
apparently
HP-UX.


This also broke aarch64 I think:
In file included from
/tmp/6140018_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/aarch64/aarch64-sve-builtins.cc:3920:0:
./gt-aarch64-sve-builtins.h: In function 'void
gt_pch_p_19registered_function(void*, void*, gt_pointer_operator, void*)':
./gt-aarch64-sve-builtins.h:86:44: error: no matching function for call to
'gt_pch_nx(aarch64_sve::function_instance*, void (*&)(void*, void*, void*),
void*&)'
  gt_pch_nx (&((*x).instance), op, cookie);

I saw similar failures for my latest aarch64 build.

Jakub, if you need an aarch64 system let me know, I've still got AWS 
credits we can use.


jeff

Leverage VX_CPU_PREFIX in aarch64-vxworks.h

[Olivier Hainque via Gcc-patches]

Hello,   

The attached patch tightens the CPU macro definitions issued
for VxWorks system headers on aarch64 to incorporate the common
VX_CPU_PREFIX facility, as the powperpc port does.

The net effect for current configurations is the addition
of an actual "_VX_" prefix to the references to architecture
representative values. The absence of this prefix is most
often compensated for in system headers, but not always (when
going through particular #include paths), and this caused
a couple of spurious test failures.

We have been using this in-house successully for
close to a couple of years now, on variations of VxWorks 7.

I'll commit to mainline shortly.

Olivier

--

2021-04-09  Olivier Hainque  

gcc/
* config/aarch64/aarch64-vxworks.h (TARGET_OS_CPP_BUILTINS):
Use VX_CPU_PREFIX in CPU definitions.



0001-Leverage-VX_CPU_PREFIX-in-aarch64-vxworks.h.patch
Description: Binary data

Re: [PATCH v2 3/5] fix up compute_objsize: factor out PHI handling

[Martin Sebor via Gcc-patches]

On 12/8/21 1:08 PM, Jeff Law wrote:



On 12/6/2021 10:32 AM, Martin Sebor wrote:

Attached is subset of the patch in part (4) below: factor out
PHI handling.  It applies on top of patch 3/5.

On 12/3/21 5:00 PM, Jeff Law wrote:



On 11/8/2021 7:34 PM, Martin Sebor via Gcc-patches wrote:

The pointer-query code that implements compute_objsize() that's
in turn used by most middle end access warnings now has a few
warts in it and (at least) one bug.  With the exception of
the bug the warts aren't behind any user-visible bugs that
I know of but they do cause problems in new code I've been
implementing on top of it.  Besides fixing the one bug (just
a typo) the attached patch cleans up these latent issues:

1) It moves the bndrng member from the access_ref class to
   access_data.  As a FIXME in the code notes, the member never
   did belong in the former and only takes up space in the cache.

2) The compute_objsize_r() function is big, unwieldy, and tedious
   to step through because of all the if statements that are better
   coded as one switch statement.  This change factors out more
   of its code into smaller handler functions as has been suggested
   and done a few times before.

3) (2) exposed a few places where I fail to pass the current
   GIMPLE statement down to ranger.  This leads to worse quality
   range info, including possible false positives and negatives.
   I just spotted these problems in code review but I haven't
   taken the time to come up with test cases.  This change fixes
   these oversights as well.

4) The handling of PHI statements is also in one big, hard-to-
   follow function.  This change moves the handling of each PHI
   argument into its own handler which merges it into the previous
   argument.  This makes the code easier to work with and opens it
   to reuse also for MIN_EXPR and MAX_EXPR.  (This is primarily
   used to print informational notes after warnings.)

5) Finally, the patch factors code to dump each access_ref
   cached by the pointer_query cache out of pointer_query::dump
   and into access_ref::dump.  This helps with debugging.

These changes should have no user-visible effect and other than
a regression test for the typo (PR 103143) come with no tests.
They've been tested on x86_64-linux.
Sigh.  You've identified 6 distinct changes above.  The 5 you've 
enumerated plus a typo fix somewhere.  There's no reason why they 
need to be a single patch and many reasons why they should be a 
series of independent patches.    Combining them into a single patch 
isn't how we do things and it hides the actual bugfix in here.


Please send a fix for the typo first since that should be able to 
trivially go forward.  Then  a patch for item #1.  That should be 
trivial to review when it's pulled out from teh rest of the patch. 
Beyond that, your choice on ordering, but you need to break this down.





Jeff




gcc-pointer_query-refactor-3.diff

commit 6ac1d37947ad5cf07fe133faaf8414f00e0eed13
Author: Martin Sebor 
Date:   Mon Dec 6 09:23:22 2021 -0700

 Introduce access_ref::merge_ref.
 gcc/ChangeLog:
 * pointer-query.cc (access_ref::merge_ref): Define new 
function.

 (access_ref::get_ref): Move code into merge_ref and call it.
 * pointer-query.h (access_ref::merge_ref): Declare new 
function.
OK.  But it's probably worth noting that this patch does more than just 
factoring out the PHI handling.  It also adds the MIN/MAX bits noted in 
the original cover letter.   That's not inherently as bad now that this 
patch isn't intermixed with the other work.


Thank you for the review.

The MIN_MAX change was in the original ChangeLog but I wrote this
one from scratch and neglected to mention it here.  Let me add it.



diff --git a/gcc/pointer-query.cc b/gcc/pointer-query.cc
index c75c4da6b60..24fbac84ec4 100644
--- a/gcc/pointer-query.cc
+++ b/gcc/pointer-query.cc




@ -766,7 +818,14 @@ access_ref::get_ref (vec *all_refs,
    /* Avoid changing *THIS.  */
    if (pref && pref != this)
-    *pref = phi_ref;
+    {
+  /* Keep the SSA_NAME of the PHI unchanged so that all PHI 
arguments

+ can be referred to later if necessary.  This is useful even if
+ they all refer to the same object.  */
+  tree ref = pref->ref;
+  *pref = phi_ref;
+  pref->ref = ref;
+    }

I don't see any mention of this in the ChangeLog.


This only matters for informational notes, and it's necessary
because the new merge_ref() function might replace the ref
member with that of the "merged" object.  It's needed to keep
the existing behavior where we want the informational notes
printed after a warning to point to all the objects that might
be subject to the out of bounds access.  This is verified by
the Wstringop-overflow-58.c and -59.c tests.

So I'm fine with the patch itself.  I would just ask for a better 
ChangeLog.  If one was to read the current ChangeLog they could easily 
be led to believe this patch was just refactoring, but it

[committed] pch: Fix aarch64 build [PR71934]

[Jakub Jelinek via Gcc-patches]

Hi!

On Thu, Dec 09, 2021 at 05:42:10PM +0100, Christophe Lyon wrote:
> This also broke aarch64 I think:
> In file included from
> /tmp/6140018_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/aarch64/aarch64-sve-builtins.cc:3920:0:
> ./gt-aarch64-sve-builtins.h: In function 'void
> gt_pch_p_19registered_function(void*, void*, gt_pointer_operator, void*)':
> ./gt-aarch64-sve-builtins.h:86:44: error: no matching function for call to
> 'gt_pch_nx(aarch64_sve::function_instance*, void (*&)(void*, void*, void*),
> void*&)'
>  gt_pch_nx (&((*x).instance), op, cookie);

Fixed thusly, compile tested on x86_64-linux, committed to trunk.

2021-12-09  Jakub Jelinek  

PR pch/71934
* config/aarch64/aarch64-sve-builtins.cc (gt_pch_nx): Change type of
second argument from function with 2 pointer arguments to function
with 3 pointer arguments.

--- gcc/config/aarch64/aarch64-sve-builtins.cc.jj   2021-09-06 
12:53:10.0 +0200
+++ gcc/config/aarch64/aarch64-sve-builtins.cc  2021-12-09 17:53:37.161178764 
+0100
@@ -3913,7 +3913,7 @@ gt_pch_nx (function_instance *)
 }
 
 inline void
-gt_pch_nx (function_instance *, void (*) (void *, void *), void *)
+gt_pch_nx (function_instance *, void (*) (void *, void *, void *), void *)
 {
 }
 


Jakub

Re: [PATCH v3 4/7] ifcvt/optabs: Allow using a CC comparison for emit_conditional_move.

[Robin Dapp via Gcc-patches]

Hi Jeff,

thanks for looking into this.

> What if the condition has a side effect?  Doesn't this drop the side 
> effect by converting the conditional move into a simple move?
Hmm, good point, if the condition does more than a CC compare, it might
get tricky as we are not canonicalizing here (on purpose). Is there an
easy way out like checking something like side_effects_p ()?

Maybe we should drop this altogether and let the backend deal with it?
It would probably not know what to do and FAIL.

Regards
 Robin

[PATCH] Remove an invalid assert. [PR103619]

[Hafiz Abid Qadeer]

Commit 13b6c7639cf assumed that registers in a span will be in a certain
order. But that assumption is not true at least for the big endian targets.
Currently amdgcn is probably only target where CFA is split into multiple
registers so build_span_loc is only gets called for it. However, the
dwf_cfa_reg function where this ICE was seen can be called for any
architecture from the comparison dwf_cfa_reg (src) == cur_cfa->reg in
dwarf2out_frame_debug_expr. So dwf_cfa_reg should not assume certain
order of registers.

I was tempted to modify the assert to handle big-endian cases but that will
still be error prone and may fail on some other targets.

gcc/ChangeLog:

PR debug/103619
* dwarf2cfi.c (dwf_cfa_reg): Remove gcc_assert.
---
 gcc/dwarf2cfi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/dwarf2cfi.c b/gcc/dwarf2cfi.c
index 9dd1dfe71b7..55ae172eda2 100644
--- a/gcc/dwarf2cfi.c
+++ b/gcc/dwarf2cfi.c
@@ -1136,7 +1136,6 @@ dwf_cfa_reg (rtx reg)
  gcc_assert (GET_MODE_SIZE (GET_MODE (XVECEXP (span, 0, i)))
  .to_constant ()  == result.span_width);
  gcc_assert (REG_P (XVECEXP (span, 0, i)));
- gcc_assert (dwf_regno (XVECEXP (span, 0, i)) == result.reg + i);
}
}
 }
-- 
2.25.1

Re: [PATCH v3 4/7] ifcvt/optabs: Allow using a CC comparison for emit_conditional_move.

[Jeff Law via Gcc-patches]

On 12/9/2021 10:20 AM, Robin Dapp wrote:

Hi Jeff,

thanks for looking into this.
NP.  I'd been watching this set evolve and I think it'll help our target 
as well, so it seemed natural to handle the review :-)





What if the condition has a side effect?  Doesn't this drop the side
effect by converting the conditional move into a simple move?

Hmm, good point, if the condition does more than a CC compare, it might
get tricky as we are not canonicalizing here (on purpose). Is there an
easy way out like checking something like side_effects_p ()?
I think if side_effects_p is true, we can just emit the conditional move 
as-is without trying to collapse it to a simple move.  It should be 
exceedingly rare to have a side effect in the destination.    Checking 
side_effects_p will also reject if the destination is volatile MEM, but 
that should be OK and also exceedingly rare.


Maybe we should drop this altogether and let the backend deal with it?
It would probably not know what to do and FAIL.
I like the idea of collapsing to a simple move if the true/false arms 
are the same.    Did you see that happen in practice?  If so, I'd like 
to keep it, but just guard with the !side_effects_p check.


jeff

[Patch 6/8 V2] Arm: Add pointer authentication for stack-unwinding runtime.

[Andrea Corallo via Gcc-patches]

Richard Earnshaw via Gcc-patches  writes:

> On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:
>> 
>>> -Original Message-
>>> From: Gcc-patches >> bounces+belagod=gcc.gnu@gcc.gnu.org> On Behalf Of Tejas Belagod via
>>> Gcc-patches
>>> Sent: Friday, October 8, 2021 1:18 PM
>>> To: gcc-patches@gcc.gnu.org
>>> Subject: [Patch 5/7, Arm. GCC] Add pointer authentication for stack-
>>> unwinding runtime.
>>>
>>> Hi,
>>>
>>> This patch adds authentication for when the stack is unwound when an
>>> exception is taken.  All the changes here are done to the runtime code in
>>> libgcc's unwinder code for Arm target. All the changes are guarded under
>>> defined (__ARM_FEATURE_PAC_DEFAULT) and activates only if the +pacbti
>>> feature is switched on for the architecture. This means that switching on 
>>> the
>>> target feature via -march or -mcpu is sufficient and -mbranch-protection
>>> need not be enabled. This ensures that the unwinder is authenticated only if
>>> the PACBTI instructions are available in the non-NOP space as it uses AUTG.
>>> Just generating PAC/AUT instructions using -mbranch-protection will not
>>> enable authentication on the unwinder.
>>>
>>> Tested on arm-none-eabi. OK for trunk?
>>>
>>> 2021-10-04  Tejas Belagod  
>>>
>>> gcc/ChangeLog:
>>>
>>> * ginclude/unwind-arm-common.h (_Unwind_VRS_RegClass):
>>> Introduce
>>> new pseudo register class _UVRSC_PAC.
>>> * libgcc/config/arm/pr-support.c (__gnu_unwind_execute): Decode
>>> exception opcode (0xb4) for saving RA_AUTH_CODE and
>>> authenticate
>>> with AUTG if found.
>>> * libgcc/config/arm/unwind-arm.c (struct pseudo_regs): New.
>>> (phase1_vrs): Introduce new field to store pseudo-reg state.
>>> (phase2_vrs): Likewise.
>>> (_Unwind_VRS_Get): Load pseudo register state from virtual reg set.
>>> (_Unwind_VRS_Set): Store pseudo register state to virtual reg set.
>>> (_Unwind_VRS_Pop): Load pseudo register value from stack into
>>> VRS.
>> Rebased and respin based on reviews for previous patches.
>> This patch adds authentication for when the stack is unwound when
>> an exception is taken.  All the changes here are done to the runtime
>> code in libgcc's unwinder code for Arm target. All the changes are
>> guarded under defined (__ARM_FEATURE_PAUTH) and activates only
>> if the +pacbti feature is switched on for the architecture. This means
>> that switching on the target feature via -march or -mcpu is sufficient
>> and -mbranch-protection need not be enabled. This ensures that the
>> unwinder is authenticated only if the PACBTI instructions are available
>> in the non-NOP space as it uses AUTG. Just generating PAC/AUT instructions
>> using -mbranch-protection will not enable authentication on the unwinder.
>> 2021-10-25  Tejas Belagod  
>> gcc/ChangeLog:
>>  * ginclude/unwind-arm-common.h (_Unwind_VRS_RegClass):
>> Introduce
>>  new pseudo register class _UVRSC_PAC.
>>  * libgcc/config/arm/pr-support.c (__gnu_unwind_execute): Decode
>>  exception opcode (0xb4) for saving RA_AUTH_CODE and authenticate
>>  with AUTG if found.
>>  * libgcc/config/arm/unwind-arm.c (struct pseudo_regs): New.
>>  (phase1_vrs): Introduce new field to store pseudo-reg state.
>>  (phase2_vrs): Likewise.
>>  (_Unwind_VRS_Get): Load pseudo register state from virtual reg set.
>>  (_Unwind_VRS_Set): Store pseudo register state to virtual reg set.
>>  (_Unwind_VRS_Pop): Load pseudo register value from stack into VRS.
>> Tested the following configurations, OK for trunk?
>> -mthumb/-march=armv8.1-m.main+pacbti/-mfloat-abi=soft
>> -marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp
>> mcmodel=small and tiny
>> aarch64-none-linux-gnu native test and bootstrap
>> Thanks,
>> Tejas.
>>

> I'd like to try to get rid of most of the ifdefs from this patch; at
> least, it shouldn't be using the ACLE PAUTH feature.  The unwinder
> should be able to cope with any unwind sequence thrown at it.
>
> Things are a little more complicated for pointer authentication,
> though, because some operations in the main code constructing the
> frame may be using architectural NOP instructions, while the unwinder
> cannot do the validation using only the architectural NOPs.
>
> So we need a fall-back: if the unwinder is built without the PAUTH
> feature it needs to unwind the pauth frames without the additional
> validation (but it still needs to be able to handle them).
>
> So the only remaining question is whether the additional support
> should only be enabled for M-profile targets, or whether we should
> just put this code into all builds of the unwinder.  I'm not sure I
> have a complete answer to that.  My inclination is to put it in
> unconditionally - we haven't had conditionals for any other optional
> architecture feature before.  If something similar is added for
> A/R-profiles, then either we will share the code exactly, or we'll end
> up with a different unwind code to use as a sui

Re: [Patch]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables

[Martin Sebor via Gcc-patches]

On 12/7/21 8:36 AM, Qing Zhao via Gcc-patches wrote:

Hi,

This patch is to resolve the following two issues in the current implemenation
of -ftrivial-auto-var-init:

1. The 3rd parameter of function .DEFERRED_INIT is IS_VLA currently, which is
not needed at all;
2. The address taken variable is replaced with a temporary variable during
gimplification, and the original auto variable might be eliminated by
compiler optimization completely. as a result, the current uninitialized
warning analysis cannot report warnings for these variables.

To solve the above problems, we change the 3rd paramter of function
.DEFERRED_INIT from IS_VLA to NAME of the DECL. During uninitialized warning
analysis phase, for the following stmt:

 _1 = .DEFERRED_INIT (4, 2, &"alt_reloc"[0]);

The original user variable has been eliminated from the IR, the LHS is the
temporary variable that was created to replace it. we will get the necessary
information from this stmt for reportinng the warning message:

 A. the name of the DECL from the 3rd parameter of the call;
 B. the location of the DECL from the location of the call;
 C. the LHS is used to hold the information on whether the warning
has been issued or not to suppress warning messages when needed;

the current testing cases are updated to reflect these changes.

The patch has been bootstrapped and regressing tested on both x86 and aarch64, 
no issues.

Okay for commit?


This seems like a nifty solution.  I just have a few notes inline
on the tree-ssa-uninit.c changes.



thanks.

Qing

==
**The complete patch is

 From 5e529c9d36fa36f921c0a2fb23d44848bdd7723a Mon Sep 17 00:00:00 2001
From: Qing Zhao 
Date: Tue, 7 Dec 2021 15:25:23 +
Subject: [PATCH] Enable -Wuninitialized + -ftrivial-auto-var-init for address
  taken variables.

This patch is to resolve the following two issues in the current implemenation
of -ftrivial-auto-var-init:

1. The 3rd parameter of function .DEFERRED_INIT is IS_VLA currently, which is
not needed at all;
2. The address taken variable is replaced with a temporary variable during
gimplification, and the original auto variable might be eliminated by
compiler optimization completely. as a result, the current uninitialized
warning analysis cannot report warnings for these variables.

To solve the above problems, we change the 3rd paramter of function
.DEFERRED_INIT from IS_VLA to NAME of the DECL. During uninitialized warning
analysis phase, for the following stmt:

 _1 = .DEFERRED_INIT (4, 2, &"alt_reloc"[0]);

The original user variable has been eliminated from the IR, the LHS is the
temporary variable that was created to replace it. we will get the necessary
information from this stmt for reportinng the warning message:

 A. the name of the DECL from the 3rd parameter of the call;
 B. the location of the DECL from the location of the call;
 C. the LHS is used to hold the information on whether the warning
has been issued or not to suppress warning messages when needed;

the current testing cases are updated to reflect these changes.

gcc/ChangeLog:

2021-12-07  qing zhao  

* gimplify.c (gimple_add_init_for_auto_var): Delete the 3rd argument.
Change the 3rd argument of function .DEFERRED_INIT to the name of the
decl.
(gimplify_decl_expr): Delete the 3rd argument when call
gimple_add_init_for_auto_var.
* internal-fn.c (expand_DEFERRED_INIT): Update comments to reflect
the 3rd argument change of function .DEFERRED_INIT.
* tree-cfg.c (verify_gimple_call): Update comments and verification
to reflect the 3rd argument change of function .DEFERRED_INIT.
* tree-sra.c (generate_subtree_deferred_init): Delete the 3rd argument.
(sra_modify_deferred_init): Change the 3rd argument of function
.DEFERRED_INIT to the name of the decl.
* tree-ssa-uninit.c (warn_uninit): Handle .DEFERRED_INIT call with an
anonymous SSA_NAME specially.
(check_defs): Likewise.
(warn_uninit_phi_uses): Adjust the message format for warn_uninit.
(warn_uninitialized_vars): Likewise.
(warn_uninitialized_phi): Likewise.

gcc/testsuite/ChangeLog:

2021-12-07  qing zhao  

* c-c++-common/auto-init-1.c: Adjust testcase to reflect the 3rd
argument change of function .DEFERRED_INIT.
* c-c++-common/auto-init-10.c: Likewise.
* c-c++-common/auto-init-11.c: Likewise.
* c-c++-common/auto-init-12.c: Likewise.
* c-c++-common/auto-init-13.c: Likewise.
* c-c++-common/auto-init-14.c: Likewise.
* c-c++-common/auto-init-15.c: Likewise.
* c-c++-common/auto-init-16.c: Likewise.
* c-c++-common/auto-init-2.c: Likewise.
* c-c++-common/auto-init-3.c: Likewise.
* c-c++-common/auto-init-4.c: Likewise.
* c-c++-common/auto-init-5.c: Likewise.
 

[PATCH] Fix path to t-ppc64-fp for ppc*-vxworks7* libgcc tmake_file

[Olivier Hainque via Gcc-patches]

Hello,

This fixes a basic mistake in the relative path used to reference
a rs6000 specific Makefile fragment in the libgcc configuration bits
for powerpc*-vxworks7*.

This addresses build failures from link errors observed
during preliminary work on the support for shared libraries
on powerpc64.

Will commit to mainline shortly.

Olivier

2021-12-09  Fred Konrad  

libgcc/
* config.host (powerpc*-wrs-vxworks7*: Fix path to
rs6000/t-ppc64-fp, relative to config/ not libgcc/.



0001-Fix-path-to-t-ppc64-fp-for-powerpc-wrs-vxworks7.patch
Description: Binary data

Re: [Patch]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables

[Qing Zhao via Gcc-patches]

Hi, Martin,

Thanks a lot for your review and comments.

> On Dec 9, 2021, at 11:43 AM, Martin Sebor  wrote:
>> 
>> diff --git a/gcc/tree-ssa-uninit.c b/gcc/tree-ssa-uninit.c
>> index 1df0bcc42c0..85d1ba866fc 100644
>> --- a/gcc/tree-ssa-uninit.c
>> +++ b/gcc/tree-ssa-uninit.c
>> @@ -182,9 +182,22 @@ warn_uninit (opt_code opt, tree t, tree var, const char 
>> *gmsgid,
>>  }
>>  /* Anonymous SSA_NAMEs shouldn't be uninitialized, but 
>> ssa_undefined_value_p
>> - can return true if the def stmt of an anonymous SSA_NAME is 
>> COMPLEX_EXPR
>> - created for conversion from scalar to complex.  Use the underlying var 
>> of
>> - the COMPLEX_EXPRs real part in that case.  See PR71581.  */
>> + can return true if the def stmt of an anonymous SSA_NAME is
>> + 1. A COMPLEX_EXPR created for conversion from scalar to complex.  Use 
>> the
>> + underlying var of the COMPLEX_EXPRs real part in that case.  See 
>> PR71581.
>> +
>> + 2. A call to .DEFERRED_INIT internal function. Since the original 
>> variable
>> + has been eliminated by optimziation, we need to get the variable name,
>> + and variable declaration location from this call. At the same time, we
>> + should use the temporary variable that was created to replace the 
>> original
>> + variable as a placeholder to record the information on whether the 
>> warning
>> + message for the variable has been issued or not.  */
>> +
>> +  tree var_name = NULL_TREE;
>> +  const char *var_name_str = NULL;
>> +  location_t var_decl_loc = UNKNOWN_LOCATION;
>> +  tree repl_var = NULL_TREE;
>> +
>>if (!var && !SSA_NAME_VAR (t))
>>  {
>>gimple *def_stmt = SSA_NAME_DEF_STMT (t);
>> @@ -197,9 +210,34 @@ warn_uninit (opt_code opt, tree t, tree var, const char 
>> *gmsgid,
>>&& zerop (gimple_assign_rhs2 (def_stmt)))
>>  var = SSA_NAME_VAR (v);
>>  }
>> +
>> +  if (gimple_call_internal_p (def_stmt, IFN_DEFERRED_INIT))
>> +{
>> +  /* Get the variable name from the 3rd argument of call.  */
>> +  var_name = gimple_call_arg (def_stmt, 2);
>> +  var_name = TREE_OPERAND (TREE_OPERAND (var_name, 0), 0);
>> +  var_name_str = TREE_STRING_POINTER (var_name);
>> +
>> +  if (is_gimple_assign (context)
>> +  && TREE_CODE (gimple_assign_lhs (context)) == VAR_DECL
>> +  && DECL_NAME (gimple_assign_lhs (context))
>> +  && IDENTIFIER_POINTER (DECL_NAME (gimple_assign_lhs (context
>> +if (strcmp
>> +  (IDENTIFIER_POINTER (DECL_NAME (gimple_assign_lhs (context))),
>> +   var_name_str) == 0)
> 
> For what it's worth, although the style in GCC is pervasive
> of repeating the same expression in operands of subsequent
> subexpressions of a logical exoression, I think it gets more
> and more difficult to read as the expression become increasingly
> deeply nested.  I find it far more readable when temporaries
> are added for the subexpressions (if it makes the nesting too
> deep I take it as a sign that the logic might be better factored
> out into a helper function).

Agreed. I will add some temporaries with meaningful name to make the above more 
readable.

> 
>> +  return;
>> +
>> +  /* Get the variable declaration location from the def_stmt.  */
>> +  var_decl_loc = gimple_location (def_stmt);
>> +
>> +  /* The LHS of the call is a temporary variable, we use it as a
>> + placeholder to record the information on whether the warning
>> + has been issued or not.  */
>> +  repl_var = gimple_call_lhs (def_stmt);
>> +}
>>  }
>>  -  if (var == NULL_TREE)
>> +  if (var == NULL_TREE && var_name == NULL_TREE)
>>  return;
>>  /* Avoid warning if we've already done so or if the warning has been
>> @@ -207,36 +245,56 @@ warn_uninit (opt_code opt, tree t, tree var, const 
>> char *gmsgid,
>>if (((warning_suppressed_p (context, OPT_Wuninitialized)
>>  || (gimple_assign_single_p (context)
>>  && get_no_uninit_warning (gimple_assign_rhs1 (context)
>> -  || get_no_uninit_warning (var))
>> +  || (var && get_no_uninit_warning (var))
>> +  || (repl_var && get_no_uninit_warning (repl_var)))
>>  return;
>>  /* Use either the location of the read statement or that of the PHI
>>   argument, or that of the uninitialized variable, in that order,
>>   whichever is valid.  */
>> -  location_t location;
>> +  location_t location = UNKNOWN_LOCATION;
>>if (gimple_has_location (context))
>>  location = gimple_location (context);
>>else if (phi_arg_loc != UNKNOWN_LOCATION)
>>  location = phi_arg_loc;
>> -  else
>> +  else if (var)
>>  location = DECL_SOURCE_LOCATION (var);
>> +  else if (var_name)
>> +location = var_decl_loc;
>> +
>>location = linemap_resolve_location (line_table, location,
>> LRK_SPELLING_LOCATION, NULL);
>>  auto_diagnostic_group d;
>> -  if (!warning_at (location

[PATCH] rs6000: Refactor altivec_build_resolved_builtin

[Bill Schmidt via Gcc-patches]

Hi!

While replacing the built-in machinery, we agreed to defer some necessary
refactoring of the overload processing.  This patch cleans it up considerably.

I've put in one FIXME for an additional level of cleanup that should be done
independently.  The various helper functions (resolve_VEC_*) can be simplified
if we move the argument processing in altivec_resolve_overloaded_builtin
earlier.  But this requires making nontrivial changes to those functions that
will need careful review.  Let's do that in a later patch.

Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.  Is this
okay for trunk?

Thanks!
Bill


2021-12-09  Bill Schmidt  

gcc/
* config/rs6000/rs6000-c.c (resolution): New enum.
(resolve_VEC_MUL): New function.
(resolve_VEC_CMPNE): Likewise.
(resolve_VEC_ADDE_SUBE): Likewise.
(resolve_VEC_ADDEC_SUBEC): Likewise.
(resolve_VEC_SPLATS): Likewise.
(resolve_VEC_EXTRACT): Likewise.
(resolve_VEC_INSERT): Likewise.
(resolve_VEC_STEP): Likewise.
(find_instance): Likewise.
(altivec_resolve_overloaded_builtin): Many cleanups:  Call factored-out
functions.  Move variable declarations closer to uses.  Add commentary.
Remove unnecessary levels of braces.  Avoid use of gotos.  Change
misleading variable names.  Use switches over if-else-if chains.
---
 gcc/config/rs6000/rs6000-c.c | 1717 +++---
 1 file changed, 945 insertions(+), 772 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index e0ebdeed548..45f485aab44 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -928,710 +928,939 @@ altivec_build_resolved_builtin (tree *args, int n, tree 
fntype, tree ret_type,
   return fold_convert (ret_type, call);
 }
 
-/* Implementation of the resolve_overloaded_builtin target hook, to
-   support Altivec's overloaded builtins.  FIXME: This code needs
-   to be brutally factored.  */
+/* Enumeration of possible results from attempted overload resolution.
+   This is used by special-case helper functions to tell their caller
+   whether they succeeded and what still needs to be done.
 
-tree
-altivec_resolve_overloaded_builtin (location_t loc, tree fndecl,
-   void *passed_arglist)
+   unresolved = Still needs processing
+ resolved = Resolved (but may be an error_mark_node)
+  resolved_bad = An error that needs handling by the caller.  */
+
+enum resolution { unresolved, resolved, resolved_bad };
+
+/* Resolve an overloaded vec_mul call and return a tree expression for the
+   resolved call if successful.  NARGS is the number of arguments to the call.
+   ARGLIST contains the arguments.  RES must be set to indicate the status of
+   the resolution attempt.  LOC contains statement location information.  */
+
+static tree
+resolve_VEC_MUL (resolution *res, vec *arglist, unsigned nargs,
+location_t loc)
 {
-  vec *arglist = static_cast *> (passed_arglist);
-  unsigned int nargs = vec_safe_length (arglist);
-  enum rs6000_gen_builtins fcode
-= (enum rs6000_gen_builtins) DECL_MD_FUNCTION_CODE (fndecl);
-  tree fnargs = TYPE_ARG_TYPES (TREE_TYPE (fndecl));
-  tree types[MAX_OVLD_ARGS];
-  tree args[MAX_OVLD_ARGS];
+  /* vec_mul needs to be special cased because there are no instructions for it
+ for the {un}signed char, {un}signed short, and {un}signed int types.  */
+  if (nargs != 2)
+{
+  error ("builtin %qs only accepts 2 arguments", "vec_mul");
+  *res = resolved;
+  return error_mark_node;
+}
 
-  /* Return immediately if this isn't an overload.  */
-  if (fcode <= RS6000_OVLD_NONE)
-return NULL_TREE;
+  tree arg0 = (*arglist)[0];
+  tree arg0_type = TREE_TYPE (arg0);
+  tree arg1 = (*arglist)[1];
+  tree arg1_type = TREE_TYPE (arg1);
 
-  unsigned int adj_fcode = fcode - RS6000_OVLD_NONE;
+  /* Both arguments must be vectors and the types must be compatible.  */
+  if (TREE_CODE (arg0_type) != VECTOR_TYPE
+  || !lang_hooks.types_compatible_p (arg0_type, arg1_type))
+{
+  *res = resolved_bad;
+  return error_mark_node;
+}
 
-  if (TARGET_DEBUG_BUILTIN)
-fprintf (stderr, "altivec_resolve_overloaded_builtin, code = %4d, %s\n",
-(int) fcode, IDENTIFIER_POINTER (DECL_NAME (fndecl)));
+  switch (TYPE_MODE (TREE_TYPE (arg0_type)))
+{
+case E_QImode:
+case E_HImode:
+case E_SImode:
+case E_DImode:
+case E_TImode:
+  /* For scalar types just use a multiply expression.  */
+  *res = resolved;
+  return fold_build2_loc (loc, MULT_EXPR, TREE_TYPE (arg0), arg0,
+ fold_convert (TREE_TYPE (arg0), arg1));
+case E_SFmode:
+  {
+   /* For floats use the xvmulsp instruction directly.  */
+   *res = resolved;
+   tree call = rs6000_builtin_decls[RS6000_BIF_XVMULSP];
+   return build_call_expr (call, 2

Re: [PATCH] rs6000: Refactor altivec_build_resolved_builtin

[Bill Schmidt via Gcc-patches]

I forgot to point out that this patch is dependent on the pending patches
to remove the old builtins code.

Thanks,
Bill

On 12/9/21 12:33 PM, Bill Schmidt via Gcc-patches wrote:
> Hi!
>
> While replacing the built-in machinery, we agreed to defer some necessary
> refactoring of the overload processing.  This patch cleans it up considerably.
>
> I've put in one FIXME for an additional level of cleanup that should be done
> independently.  The various helper functions (resolve_VEC_*) can be simplified
> if we move the argument processing in altivec_resolve_overloaded_builtin
> earlier.  But this requires making nontrivial changes to those functions that
> will need careful review.  Let's do that in a later patch.
>
> Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.  Is this
> okay for trunk?
>
> Thanks!
> Bill
>
>
> 2021-12-09  Bill Schmidt  
>
> gcc/
>   * config/rs6000/rs6000-c.c (resolution): New enum.
>   (resolve_VEC_MUL): New function.
>   (resolve_VEC_CMPNE): Likewise.
>   (resolve_VEC_ADDE_SUBE): Likewise.
>   (resolve_VEC_ADDEC_SUBEC): Likewise.
>   (resolve_VEC_SPLATS): Likewise.
>   (resolve_VEC_EXTRACT): Likewise.
>   (resolve_VEC_INSERT): Likewise.
>   (resolve_VEC_STEP): Likewise.
>   (find_instance): Likewise.
>   (altivec_resolve_overloaded_builtin): Many cleanups:  Call factored-out
>   functions.  Move variable declarations closer to uses.  Add commentary.
>   Remove unnecessary levels of braces.  Avoid use of gotos.  Change
>   misleading variable names.  Use switches over if-else-if chains.
> ---
>  gcc/config/rs6000/rs6000-c.c | 1717 +++---
>  1 file changed, 945 insertions(+), 772 deletions(-)
>
> diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
> index e0ebdeed548..45f485aab44 100644
> --- a/gcc/config/rs6000/rs6000-c.c
> +++ b/gcc/config/rs6000/rs6000-c.c
> @@ -928,710 +928,939 @@ altivec_build_resolved_builtin (tree *args, int n, 
> tree fntype, tree ret_type,
>return fold_convert (ret_type, call);
>  }
>
> -/* Implementation of the resolve_overloaded_builtin target hook, to
> -   support Altivec's overloaded builtins.  FIXME: This code needs
> -   to be brutally factored.  */
> +/* Enumeration of possible results from attempted overload resolution.
> +   This is used by special-case helper functions to tell their caller
> +   whether they succeeded and what still needs to be done.
>
> -tree
> -altivec_resolve_overloaded_builtin (location_t loc, tree fndecl,
> - void *passed_arglist)
> + unresolved = Still needs processing
> +   resolved = Resolved (but may be an error_mark_node)
> +  resolved_bad = An error that needs handling by the caller.  */
> +
> +enum resolution { unresolved, resolved, resolved_bad };
> +
> +/* Resolve an overloaded vec_mul call and return a tree expression for the
> +   resolved call if successful.  NARGS is the number of arguments to the 
> call.
> +   ARGLIST contains the arguments.  RES must be set to indicate the status of
> +   the resolution attempt.  LOC contains statement location information.  */
> +
> +static tree
> +resolve_VEC_MUL (resolution *res, vec *arglist, unsigned nargs,
> +  location_t loc)
>  {
> -  vec *arglist = static_cast *> 
> (passed_arglist);
> -  unsigned int nargs = vec_safe_length (arglist);
> -  enum rs6000_gen_builtins fcode
> -= (enum rs6000_gen_builtins) DECL_MD_FUNCTION_CODE (fndecl);
> -  tree fnargs = TYPE_ARG_TYPES (TREE_TYPE (fndecl));
> -  tree types[MAX_OVLD_ARGS];
> -  tree args[MAX_OVLD_ARGS];
> +  /* vec_mul needs to be special cased because there are no instructions for 
> it
> + for the {un}signed char, {un}signed short, and {un}signed int types.  */
> +  if (nargs != 2)
> +{
> +  error ("builtin %qs only accepts 2 arguments", "vec_mul");
> +  *res = resolved;
> +  return error_mark_node;
> +}
>
> -  /* Return immediately if this isn't an overload.  */
> -  if (fcode <= RS6000_OVLD_NONE)
> -return NULL_TREE;
> +  tree arg0 = (*arglist)[0];
> +  tree arg0_type = TREE_TYPE (arg0);
> +  tree arg1 = (*arglist)[1];
> +  tree arg1_type = TREE_TYPE (arg1);
>
> -  unsigned int adj_fcode = fcode - RS6000_OVLD_NONE;
> +  /* Both arguments must be vectors and the types must be compatible.  */
> +  if (TREE_CODE (arg0_type) != VECTOR_TYPE
> +  || !lang_hooks.types_compatible_p (arg0_type, arg1_type))
> +{
> +  *res = resolved_bad;
> +  return error_mark_node;
> +}
>
> -  if (TARGET_DEBUG_BUILTIN)
> -fprintf (stderr, "altivec_resolve_overloaded_builtin, code = %4d, %s\n",
> -  (int) fcode, IDENTIFIER_POINTER (DECL_NAME (fndecl)));
> +  switch (TYPE_MODE (TREE_TYPE (arg0_type)))
> +{
> +case E_QImode:
> +case E_HImode:
> +case E_SImode:
> +case E_DImode:
> +case E_TImode:
> +  /* For scalar types just use a multiply expression.  */
> +  *res = re

Re: [PATCH v2] jit: Add support for global rvalue initialization and ctors

[David Malcolm via Gcc-patches]

On Mon, 2021-12-06 at 10:47 +, Petter Tomner via Gcc-patches wrote:
> Hi!
> 
> Attached is a patch with changes in line with the review of the prior
> patch.
> The patch adds support for initialization of global variables with
> rvalues as well
> as rvalue constructors for structs, arrays and unions.

Thanks for the updated patch.

Antoni: does this patch work for you for your rustc plugin?

> 
> Review: https://gcc.gnu.org/pipermail/jit/2021q4/001400.html
> 
> The points have been addressed, except:
> 
> > Can the type be made const?
> 
> I started to make types_kinda_same_internal () taking const args, but I
> felt the
> patch was ballooning because some spread out methods needed a const 
> signature too. I could submit that in a separate patch.

Fair enough; fixing that isn't a blocker; it's already a big patch.

> 
> I also addressed a problem Antoni found: 
> https://gcc.gnu.org/pipermail/jit/2021q4/001399.html
> 
> , where you could not initialize global pointer variables to point to
> uninitialized variables. I did that by 
> removing a redundant check with validate_var_has_init (), since that
> walking function would
> have to be quite complex to allow pointers to uninitialized variables.
> 
> Any:
> const int foo;
> int bar = foo;
> 
> will instead be reported as "not compile time constant" instead of a
> nice error message with names.
> 
> make check-jit runs fine on gnu-linux-x64 Debian.

Various review comments inline below, which are mostly just nits:

> From a4fef1308eaa72ce4ec51dbe5efcfbbf032e9870 Mon Sep 17 00:00:00 2001
> From: Petter Tomner 
> Date: Mon, 29 Nov 2021 20:44:07 +0100
> Subject: [PATCH] Add support for global rvalue initialization and constructors
> 
> This patch adds support for initialization of global variables
> with rvalues and creating constructors for array, struct and
> union types which can be used as rvalues.
> 
> Signed-off-by:
> 2021-12-06Petter Tomner   

[...snip...]

> diff --git a/gcc/jit/docs/topics/expressions.rst 
> b/gcc/jit/docs/topics/expressions.rst
> index 396259ef07e..5f64ca68595 100644
> --- a/gcc/jit/docs/topics/expressions.rst
> +++ b/gcc/jit/docs/topics/expressions.rst
> @@ -126,6 +126,147 @@ Simple expressions
> underlying string, so it is valid to pass in a pointer to an on-stack
> buffer.
>  
> +Constructor expressions
> +***
> +
> +   The following functions make constructors for array, struct and union
> +   types.
> +
> +   The constructor rvalue can be used for assignment to locals.
> +   It can be used to initialize global variables with
> +   :func:`gcc_jit_global_set_initializer_rvalue`. It can also be used as a
> +   temporary value for function calls and return values, but its address
> +   can't be taken.
> +
> +   Note that arrays in libgccjit does not collapse to pointers like in

s/does not/do not/

> +   C. I.e. if an array constructor is used as e.g. a return value, the whole
> +   array would be returned by value - array constructors can be assigned to
> +   array variables.
> +
> +   The constructor can contain nested constructors.
> +
> +   Note that a string literal rvalue can't be used to construct a char array.
> +   It need one rvalue for each char.

s/char array.  It need one rvalue/char array; the latter needs one rvalue/

> +
> +   These entrypoints were added in :ref:`LIBGCCJIT_ABI_16`; you can test for 
> its

s/16/17/  I believe.

s/its/their/


> +   presense using:

s/presense/presence/

(and in various other places below)


> +   .. code-block:: c
> + #ifdef LIBGCCJIT_HAVE_CTORS
> +
> +.. function:: gcc_jit_rvalue *\
> +   gcc_jit_context_new_array_constructor (gcc_jit_context *ctxt,\
> +  gcc_jit_location *loc,\
> +  gcc_jit_type *type,\
> +  size_t arr_length,\
> +  gcc_jit_rvalue **values)
> +
> +   Create a constructor for an array as a rvalue.
> +
> +   Returns NULL on error. ``values`` are copied and
> +   do not have to outlive the context.
> +
> +   ``type`` specifies what the constructor will build and has to be
> +   an array.
> +
> +   ``arr_length`` specifies the number of elements in ``values`` and
> +   it can't have more elements than the array type.

Let's rename this to ``num_values`` (both in the docs, and in
libgccjit.c and .h, in all of the various places), since this will make
it clearer that we're talking about the size of "values", rather than
that of the type.

> +
> +   Each value in ``values`` sets the corresponding value in the array.
> +   If the array type itself has more elements than ``values``, the
> +   left-over elements will be zeroed.
> +
> +   Each value in ``values`` need to be the same unqualified type as the
> +   array type's element type.
> +
> +   If ``arr_length`` is 0, the ``values`` parameter will be
> +   ignored and zero initializa

[PATCH] PR libfortran/103634 - Runtime crash with PACK on zero-sized arrays

[Harald Anlauf via Gcc-patches]

Dear all,

I had thought that we had fixed this in the past (see PR31001),
but it did fail for me with all gcc versions I have tried (7-12)
for a slightly more elaborate case as in the old testcase.

The loop in pack_internal did try to access the first element of
the array argument to PACK even if one (or more) extents were zero.
This is not good.

Solution: check the extents and return early.  (We already do a
related check for the vector argument if present).

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

As this segfaults on valid code at runtime: I am considering
backporting this, if there are no objections.

Thanks,
Harald

From dfa1e1ac5d8e43f1ca8f13b64330825581174f36 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Thu, 9 Dec 2021 20:55:08 +0100
Subject: [PATCH] Fortran: PACK intrinsic should not try to read from
 zero-sized array

libgfortran/ChangeLog:

	PR libfortran/103634
	* intrinsics/pack_generic.c (pack_internal): Handle case when the
	array argument of PACK has one extent of size zero to avoid
	invalid reads.

gcc/testsuite/ChangeLog:

	PR libfortran/103634
	* gfortran.dg/zero_sized_13.f90: New test.
---
 gcc/testsuite/gfortran.dg/zero_sized_13.f90 | 20 
 libgfortran/intrinsics/pack_generic.c   |  4 
 2 files changed, 24 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/zero_sized_13.f90

diff --git a/gcc/testsuite/gfortran.dg/zero_sized_13.f90 b/gcc/testsuite/gfortran.dg/zero_sized_13.f90
new file mode 100644
index 000..5620514334c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/zero_sized_13.f90
@@ -0,0 +1,20 @@
+! { dg-do run }
+! PR libfortran/103634 - Runtime crash with PACK on zero-sized arrays
+
+program p
+  implicit none
+  type t
+ real :: r(24) = -99.
+  end type
+  type(t), allocatable :: new(:), old(:)
+  logical, allocatable :: mask(:)
+  integer  :: n, m
+! m = 1! works
+  m = 0! failed with SIGSEGV in pack_internal
+  allocate (old(m), mask(m))
+  mask(:) = .false.
+  n = count (mask)
+  allocate (new(n))
+  new(:) = pack (old, mask)
+  print *, size (new)
+end
diff --git a/libgfortran/intrinsics/pack_generic.c b/libgfortran/intrinsics/pack_generic.c
index cad2fbbfbcd..f629e0e8469 100644
--- a/libgfortran/intrinsics/pack_generic.c
+++ b/libgfortran/intrinsics/pack_generic.c
@@ -126,6 +126,10 @@ pack_internal (gfc_array_char *ret, const gfc_array_char *array,
   if (mstride[0] == 0)
 mstride[0] = mask_kind;

+  for (n = 0; n < dim; n++)
+if (extent[n] == 0)
+  return;
+
   if (ret->base_addr == NULL || unlikely (compile_options.bounds_check))
 {
   /* Count the elements, either for allocating memory or
--
2.26.2

[PATCH] c++, symtab: Support &typeid(x) == &typeid(y) in constant evaluation [PR103600]

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 08, 2021 at 08:53:03AM -0500, Jason Merrill wrote:
> > As mentioned in the PR, the varpool/middle-end code is trying to be
> > conservative with address comparisons of different vars if those vars
> > don't bind locally, because of possible aliases in other TUs etc.
> 
> Would it make sense to assume that DECL_ARTIFICIAL variables can't be
> aliases?  If not, could we have some way of marking a variable as
> non-aliasing, perhaps an attribute?

I think DECL_ARTIFICIAL vars generally can overlap.

The following patch adds a GCC internal attribute "non overlapping"
and uses it in symtab_node::equal_address_to.
Not sure what plans has Honza in that area and whether it would be useful
to make the attribute public and let users assert that some variable will
never overlap with other variables, won't have aliases etc.

> During constant evaluation, the operator== could compare the type_info
> address instead of the __name address, reducing this to the previous
> problem.

Ah, indeed, good idea.  FYI, clang++ seems to constant fold
&typeid(x) != &typeid(y) already, so Jonathan could use it even for
clang++ in the constexpr operator==.  But it folds even
extern int &a, &b;
constexpr bool c = &a != &b;
regardless of whether some other TU has
int a;
int b __attribute__((alias (a));
or not.

Here is an updated patch, ok for trunk if it passes bootstrap/regtest?

2021-12-09  Jakub Jelinek  

PR c++/103600
gcc/
* symtab.c (symtab_node::equal_address_to): Return 0 if one of
VAR_DECLs has "non overlapping" attribute and rs1 != rs2.
gcc/c-family/
* c-attribs.c (handle_non_overlapping_attribute): New function.
(c_common_attribute_table): Add "non overlapping" attribute.
gcc/cp/
* rtti.c (get_tinfo_decl_direct): Add "non overlapping" attribute
to DECL_TINFO_P VAR_DECLs.
gcc/testsuite/
* g++.dg/cpp0x/constexpr-typeid2.C: New test.

--- gcc/symtab.c.jj 2021-11-19 09:58:37.268716406 +0100
+++ gcc/symtab.c2021-12-09 20:41:30.085566768 +0100
@@ -2276,6 +2276,14 @@ symtab_node::equal_address_to (symtab_no
   return 0;
 }
 
+  /* If the FE tells us at least one of the decls will never be aliased nor
+ overlapping with other vars in some other way, return 0.  */
+  if (VAR_P (decl)
+  && rs1 != rs2
+  && (lookup_attribute ("non overlapping", DECL_ATTRIBUTES (decl))
+ || lookup_attribute ("non overlapping", DECL_ATTRIBUTES (s2->decl
+return 0;
+
   /* TODO: Alias oracle basically assume that addresses of global variables
  are different unless they are declared as alias of one to another while
  the code folding comparisons doesn't.
--- gcc/c-family/c-attribs.c.jj 2021-09-11 09:33:37.734334126 +0200
+++ gcc/c-family/c-attribs.c2021-12-09 20:44:42.593810421 +0100
@@ -159,6 +159,7 @@ static tree handle_omp_declare_variant_a
 static tree handle_simd_attribute (tree *, tree, tree, int, bool *);
 static tree handle_omp_declare_target_attribute (tree *, tree, tree, int,
 bool *);
+static tree handle_non_overlapping_attribute (tree *, tree, tree, int, bool *);
 static tree handle_designated_init_attribute (tree *, tree, tree, int, bool *);
 static tree handle_patchable_function_entry_attribute (tree *, tree, tree,
   int, bool *);
@@ -512,6 +513,8 @@ const struct attribute_spec c_common_att
  handle_omp_declare_target_attribute, NULL },
   { "omp declare target block", 0, 0, true, false, false, false,
  handle_omp_declare_target_attribute, NULL },
+  { "non overlapping",   0, 0, true, false, false, false,
+ handle_non_overlapping_attribute, NULL },
   { "alloc_align",   1, 1, false, true, true, false,
  handle_alloc_align_attribute,
  attr_alloc_exclusions },
@@ -3764,6 +3767,15 @@ handle_omp_declare_target_attribute (tre
 {
   return NULL_TREE;
 }
+
+/* Handle an "non overlapping" attribute; arguments as in
+   struct attribute_spec.handler.  */
+
+static tree
+handle_non_overlapping_attribute (tree *, tree, tree, int, bool *)
+{
+  return NULL_TREE;
+}
 
 /* Handle a "returns_twice" attribute; arguments as in
struct attribute_spec.handler.  */
--- gcc/cp/rtti.c.jj2021-12-09 15:37:05.330625874 +0100
+++ gcc/cp/rtti.c   2021-12-09 21:02:13.090738268 +0100
@@ -475,6 +475,15 @@ get_tinfo_decl_direct (tree type, tree n
   DECL_IGNORED_P (d) = 1;
   TREE_READONLY (d) = 1;
   TREE_STATIC (d) = 1;
+  /* Tell equal_address_to that different tinfo decls never
+overlap.  */
+  if (vec_safe_is_empty (unemitted_tinfo_decls))
+   DECL_ATTRIBUTES (d)
+ = build_tree_list (get_identifier ("non overlapping"),
+NULL_TREE);
+  else
+   DECL_ATTRIBUTES (d)
+ = DECL_ATTRIBUTES ((*unem

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

[David Malcolm via Gcc-patches]

On Sun, 2021-11-21 at 16:44 -0500, Antoni Boucher wrote:
> Thanks for the review!
> I updated the patch.
> 
> See notes below.

Thanks; the updated patch looks good for trunk.

Dave

Re: [PATCH] PR libfortran/103634 - Runtime crash with PACK on zero-sized arrays

[Mikael Morin]

Hello,

On 09/12/2021 21:05, Harald Anlauf via Fortran wrote:

Dear all,

I had thought that we had fixed this in the past (see PR31001),
but it did fail for me with all gcc versions I have tried (7-12)
for a slightly more elaborate case as in the old testcase.

The loop in pack_internal did try to access the first element of
the array argument to PACK even if one (or more) extents were zero.
This is not good.

Solution: check the extents and return early.  (We already do a
related check for the vector argument if present).


If there is a vector argument, aren’t we supposed to copy it to the result ?
There is something else to pay attention for, the early return should 
come at least after the return array bounds have been set.  In the 
testcase an array with the correct bounds has been allocated beforehand 
to hold the return value, but it’s not always the case.


For what it’s worth, the non-generic variant in pack.m4 (or in 
pack_{i,f,c}{1,2,4,8,10,16}.c) has a zero extent check and it clears the 
source ptr in that case, which makes it setup the return array and then 
jump to the vector copy at the end of the function.

Re: [PATCH] c++, symtab: Support &typeid(x) == &typeid(y) in constant evaluation [PR103600]

[Jan Hubicka via Gcc-patches]

> 
> Ah, indeed, good idea.  FYI, clang++ seems to constant fold
> &typeid(x) != &typeid(y) already, so Jonathan could use it even for
> clang++ in the constexpr operator==.  But it folds even
> extern int &a, &b;
> constexpr bool c = &a != &b;
> regardless of whether some other TU has
> int a;
> int b __attribute__((alias (a));
> or not.
> 
> Here is an updated patch, ok for trunk if it passes bootstrap/regtest?

Looks good to me.  We are somewhat inconsistent on when we support
overleap and when we don't.  Also we produce local symbols that can be
later globalized by partitioning.  So perhaps we want this to eventually
become flag in symtab node and unify the logic in aliasing code etc, but
that can wait for next stage1.

Honza

[PATCH, v2] PR fortran/103418 - random_number() does not accept pointer, intent(in) array argument

[Harald Anlauf via Gcc-patches]

Hi Mikael,

Am 08.12.21 um 10:32 schrieb Mikael Morin:

On 07/12/2021 21:46, Harald Anlauf wrote:

Hi Mikael,

Am 07.12.21 um 21:17 schrieb Mikael Morin:

The existing code looks dubious to me (or at least difficult to
understand), and your patch doesn’t make that any better.
I would rather try to remove the whole block, and fix the fallout on
move_alloc by adding calls to gfc_check_vardef_context in
gfc_check_move_alloc.
Can you try that instead?


I hadn't thought that far but will think about a possibly better
solution.


Hello,

I thought about it some more over night, and it is probably a poor
suggestion to restrict the check to move_alloc only.  The existing code
was added for move_alloc, but it has a broader scope.  Still,
gfc_check_vardef_context has the correct checks and is the one to be used.


I have played a little, and it took some time to understand the fallout.
Your suggestion to rely on gfc_check_vardef_context actually helped to
uncover another bug: a bad check for CLASS pointer.

See attached for an updated patch and the extended testcase.

Regtested again.  OK now?

Thanks,
Harald

From dec60c90d47211d55048e7034e95f3e6fb10a2d4 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Thu, 9 Dec 2021 22:57:13 +0100
Subject: [PATCH] Fortran: fix check for pointer dummy arguments with
 INTENT(IN)

gcc/fortran/ChangeLog:

	PR fortran/103418
	* check.c (variable_check): Replace previous check of procedure
	dummy arguments with INTENT(IN) attribute when passed to intrinsic
	procedures by gfc_check_vardef_context.
	* expr.c (gfc_check_vardef_context): Correct check of INTENT(IN)
	dummy arguments for the case of sub-components of a CLASS pointer.

gcc/testsuite/ChangeLog:

	PR fortran/103418
	* gfortran.dg/move_alloc_8.f90: Adjust error messages.
	* gfortran.dg/pointer_intent_9.f90: New test.
---
 gcc/fortran/check.c   | 32 --
 gcc/fortran/expr.c|  9 +++--
 gcc/testsuite/gfortran.dg/move_alloc_8.f90|  4 +--
 .../gfortran.dg/pointer_intent_9.f90  | 33 +++
 4 files changed, 47 insertions(+), 31 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pointer_intent_9.f90

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index ee3a51ee253..3934336df2e 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1011,33 +1011,13 @@ variable_check (gfc_expr *e, int n, bool allow_proc)
   if (e->expr_type == EXPR_VARIABLE
   && e->symtree->n.sym->attr.intent == INTENT_IN
   && (gfc_current_intrinsic_arg[n]->intent == INTENT_OUT
-	  || gfc_current_intrinsic_arg[n]->intent == INTENT_INOUT))
+	  || gfc_current_intrinsic_arg[n]->intent == INTENT_INOUT)
+  && !gfc_check_vardef_context (e, false, true, false, NULL))
 {
-  gfc_ref *ref;
-  bool pointer = e->symtree->n.sym->ts.type == BT_CLASS
-		 && CLASS_DATA (e->symtree->n.sym)
-		 ? CLASS_DATA (e->symtree->n.sym)->attr.class_pointer
-		 : e->symtree->n.sym->attr.pointer;
-
-  for (ref = e->ref; ref; ref = ref->next)
-	{
-	  if (pointer && ref->type == REF_COMPONENT)
-	break;
-	  if (ref->type == REF_COMPONENT
-	  && ((ref->u.c.component->ts.type == BT_CLASS
-		   && CLASS_DATA (ref->u.c.component)->attr.class_pointer)
-		  || (ref->u.c.component->ts.type != BT_CLASS
-		  && ref->u.c.component->attr.pointer)))
-	break;
-	}
-
-  if (!ref)
-	{
-	  gfc_error ("%qs argument of %qs intrinsic at %L cannot be "
-		 "INTENT(IN)", gfc_current_intrinsic_arg[n]->name,
-		 gfc_current_intrinsic, &e->where);
-	  return false;
-	}
+  gfc_error ("%qs argument of %qs intrinsic at %L cannot be INTENT(IN)",
+		 gfc_current_intrinsic_arg[n]->name,
+		 gfc_current_intrinsic, &e->where);
+  return false;
 }

   if (e->expr_type == EXPR_VARIABLE
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 87089321a3b..b874607db1d 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -6254,10 +6254,13 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer, bool alloc_obj,
 {
   if (ptr_component && ref->type == REF_COMPONENT)
 	check_intentin = false;
-  if (ref->type == REF_COMPONENT && ref->u.c.component->attr.pointer)
+  if (ref->type == REF_COMPONENT)
 	{
-	  ptr_component = true;
-	  if (!pointer)
+	  gfc_component *comp = ref->u.c.component;
+	  ptr_component = (comp->ts.type == BT_CLASS && comp->attr.class_ok)
+			? CLASS_DATA (comp)->attr.class_pointer
+			: comp->attr.pointer;
+	  if (ptr_component && !pointer)
 	check_intentin = false;
 	}
   if (ref->type == REF_INQUIRY
diff --git a/gcc/testsuite/gfortran.dg/move_alloc_8.f90 b/gcc/testsuite/gfortran.dg/move_alloc_8.f90
index f624b703cc9..d968ea0e5cd 100644
--- a/gcc/testsuite/gfortran.dg/move_alloc_8.f90
+++ b/gcc/testsuite/gfortran.dg/move_alloc_8.f90
@@ -60,7 +60,7 @@ subroutine test2 (x, px)
   integer, allocatable :: a
   type(t2), pointer :: ta

-  call move_alloc (px, ta)  ! { dg-error "cannot be INTEN

Re: [committed 4/4] d: Merge upstream phobos 574bf883b

[Iain Buclaw via Gcc-patches]

Excerpts from Andreas Schwab's message of December 9, 2021 11:09 am:
> Breaks aarch64:
> 
> ../../../../libphobos/libdruntime/core/sys/linux/unistd.d:10:15: error: 
> module 'core.sys.linux.syscalls' import 'SystemCall' not found
>10 | public import core.sys.linux.syscalls : SystemCall;
>   |   ^
> 

Hi Andreas,

Thanks!  I've raised a revert for the change in upstream that broke
this.  Unfortunately they only considered X86 and X86_64 in the change.

Iain.

[PR100843] store by mult pieces: punt on max_len < min_len

[Alexandre Oliva via Gcc-patches]

The testcase confuses the code that detects min and max len for the
memset, so max_len ends up less than min_len.  That shouldn't be
possible, but the testcase requires us to handle this case.

The store-by-mult-pieces algorithm actually relies on min and max
lengths, so if we find them to be inconsistent, the best we can do is
punting.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

PR middle-end/100843
* builtins.c (try_store_by_multiple_pieces): Fail if min_len
is greater than max_len.

for  gcc/testsuite/ChangeLog

PR middle-end/100843
* gcc.dg/pr100843.c: New.
---
 gcc/builtins.c  |3 ++-
 gcc/testsuite/gcc.dg/pr100843.c |8 
 2 files changed, 10 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr100843.c

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 03829c03a5a11..304d87dafb750 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -3963,7 +3963,8 @@ try_store_by_multiple_pieces (rtx to, rtx len, unsigned 
int ctz_len,
   else if (max_len == min_len)
 blksize = max_len;
   else
-gcc_unreachable ();
+/* Huh, max_len < min_len?  Punt.  See pr100843.c.  */
+return false;
   if (min_len >= blksize)
 {
   min_len -= blksize;
diff --git a/gcc/testsuite/gcc.dg/pr100843.c b/gcc/testsuite/gcc.dg/pr100843.c
new file mode 100644
index 0..695a2ec3f6818
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr100843.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -w" } */
+
+char c;
+void *memset();
+void test_integer_conversion_memset(void *d) {
+  memset(d, '\0', c);
+}


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

[PR100518] store by mult pieces: keep addr in Pmode

[Alexandre Oliva via Gcc-patches]

The conversion of a MEM address to ptr_mode in
try_store_by_multiple_pieces was misguided: copy_addr_to_reg expects
Pmode for addresses.

Regstrapped on x86_64-linux-gnu, testcase verified with a cross to
aarch64.  Ok to install?


for  gcc/ChangeLog

PR target/100518
* builtins.c (try_store_by_multiple_pieces): Drop address
conversion to ptr_mode.

for  gcc/testsuite/ChangeLog

PR target/100518
* gcc.target/aarch64/pr100518.c: New.
---
 gcc/builtins.c  |2 +-
 gcc/testsuite/gcc.target/aarch64/pr100518.c |9 +
 2 files changed, 10 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/pr100518.c

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 304d87dafb750..cd8947b4de286 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -4003,7 +4003,7 @@ try_store_by_multiple_pieces (rtx to, rtx len, unsigned 
int ctz_len,
   constfundata = &valc;
 }
 
-  rtx ptr = copy_addr_to_reg (convert_to_mode (ptr_mode, XEXP (to, 0), 0));
+  rtx ptr = copy_addr_to_reg (XEXP (to, 0));
   rtx rem = copy_to_mode_reg (ptr_mode, convert_to_mode (ptr_mode, len, 0));
   to = replace_equiv_address (to, ptr);
   set_mem_align (to, align);
diff --git a/gcc/testsuite/gcc.target/aarch64/pr100518.c 
b/gcc/testsuite/gcc.target/aarch64/pr100518.c
new file mode 100644
index 0..5ca599f5d2e0e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr100518.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-mabi=ilp32 -mstrict-align -O2" } */
+
+int unsigned_range_min, unsigned_range_max, a11___trans_tmp_1;
+
+void a11() {
+  a11___trans_tmp_1 = unsigned_range_max < unsigned_range_min;
+  __builtin_memset((char *)1, 0, a11___trans_tmp_1);
+}

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

Re: [PATCH 1b/6] Add __attribute__((untrusted))

[Martin Sebor via Gcc-patches]

On 11/13/21 1:37 PM, David Malcolm via Gcc-patches wrote:

This patch adds a new:

   __attribute__((untrusted))

for use by the C front-end, intended for use by the Linux kernel for
use with "__user", but which could be used by other operating system
kernels, and potentialy by other projects.


It looks like untrusted is a type attribute (rather than one
that applies to variables and/or function return values or
writeable by-reference arguments).  I find that quite surprising.
 I'm used to thinking of trusted vs tainted as dynamic properties
of data so I'm having trouble deciding what to think about
the attribute applying to types.  Can you explain why it's
useful on types?

I'd expect the taint property of a type to be quickly lost as
an object of the type is passed through existing APIs (e.g.,
a char array manipulated by string functions like strchr).

(I usually look at tests to help me understand the design of
a change but I couldn't find an answer to my question in those
in the patch.)

Thanks
Martin

PS I found one paper online that discusses type-based taint
analysis in Java but not much more.  I only quickly skimmed
the paper and although it conceptually makes sense I'm still
having difficulties seeing how it would be useful in C.



Known issues:
- at least one TODO in handle_untrusted_attribute
- should it be permitted to dereference an untrusted pointer?  The patch
   currently allows this

gcc/c-family/ChangeLog:
* c-attribs.c (c_common_attribute_table): Add "untrusted".
(build_untrusted_type): New.
(handle_untrusted_attribute): New.
* c-pretty-print.c (pp_c_cv_qualifiers): Handle
TYPE_QUAL_UNTRUSTED.

gcc/c/ChangeLog:
* c-typeck.c (convert_for_assignment): Complain if the trust
levels vary when assigning a non-NULL pointer.

gcc/ChangeLog:
* doc/extend.texi (Common Type Attributes): Add "untrusted".
* print-tree.c (print_node): Handle TYPE_UNTRUSTED.
* tree-core.h (enum cv_qualifier): Add TYPE_QUAL_UNTRUSTED.
(struct tree_type_common): Assign one of the spare bits to a new
"untrusted_flag".
* tree.c (set_type_quals): Handle TYPE_QUAL_UNTRUSTED.
* tree.h (TYPE_QUALS): Likewise.
(TYPE_QUALS_NO_ADDR_SPACE): Likewise.
(TYPE_QUALS_NO_ADDR_SPACE_NO_ATOMIC): Likewise.

gcc/testsuite/ChangeLog:
* c-c++-common/attr-untrusted-1.c: New test.

Signed-off-by: David Malcolm 
---
  gcc/c-family/c-attribs.c  |  59 +++
  gcc/c-family/c-pretty-print.c |   2 +
  gcc/c/c-typeck.c  |  64 +++
  gcc/doc/extend.texi   |  25 +++
  gcc/print-tree.c  |   3 +
  gcc/testsuite/c-c++-common/attr-untrusted-1.c | 165 ++
  gcc/tree-core.h   |   6 +-
  gcc/tree.c|   1 +
  gcc/tree.h|  11 +-
  9 files changed, 332 insertions(+), 4 deletions(-)
  create mode 100644 gcc/testsuite/c-c++-common/attr-untrusted-1.c

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 007b928c54b..100c2dabab2 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -136,6 +136,7 @@ static tree handle_warn_unused_result_attribute (tree *, 
tree, tree, int,
 bool *);
  static tree handle_access_attribute (tree *, tree, tree, int, bool *);
  
+static tree handle_untrusted_attribute (tree *, tree, tree, int, bool *);

  static tree handle_sentinel_attribute (tree *, tree, tree, int, bool *);
  static tree handle_type_generic_attribute (tree *, tree, tree, int, bool *);
  static tree handle_alloc_size_attribute (tree *, tree, tree, int, bool *);
@@ -536,6 +537,8 @@ const struct attribute_spec c_common_attribute_table[] =
  handle_special_var_sec_attribute, 
attr_section_exclusions },
{ "access", 1, 3, false, true, true, false,
  handle_access_attribute, NULL },
+  { "untrusted",   0, 0, false,  true, false, true,
+ handle_untrusted_attribute, NULL },
/* Attributes used by Objective-C.  */
{ "NSObject",   0, 0, true, false, false, false,
  handle_nsobject_attribute, NULL },
@@ -5224,6 +5227,62 @@ build_attr_access_from_parms (tree parms, bool 
skip_voidptr)
return build_tree_list (name, attrargs);
  }
  
+/* Build (or reuse) a type based on BASE_TYPE, but with

+   TYPE_QUAL_UNTRUSTED.  */
+
+static tree
+build_untrusted_type (tree base_type)
+{
+  int base_type_quals = TYPE_QUALS (base_type);
+  return build_qualified_type (base_type,
+  base_type_quals | TYPE_QUAL_UNTRUSTED);
+}
+
+/* Handle an "untrusted" attribute; arguments as in
+   struct attribute_spec.handler.  */
+
+static tree
+handle_untrusted_attri

Re: [RFC][PATCH] c++/46476 - implement -Wunreachable-code-return

[Jim Wilson via Gcc-patches]

On Mon, Nov 29, 2021 at 5:21 PM Martin Sebor via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> There are some other "unusual" cases worth a look, such as missing
> context of any kind except for like and column:
>
> elfnn-riscv.c:3346:7: warning: statement after return is not reachable
> [-Wunreachable-code-return]
> elfnn-riscv.c:3349:7: warning: statement after return is not reachable
> [-Wunreachable-code-return]
> elfnn-riscv.c:3352:7: warning: statement after return is not reachable
> [-Wunreachable-code-return]
> elfnn-riscv.c:3355:7: warning: statement after return is not reachable
> [-Wunreachable-code-return]
>

That file has "return ...; break;" inside a switch.  Warning for that is
OK, and we shouldn't need a better warning message.  It is pretty obvious
what is wrong.

Jim

Re: [PATCH] c++, symtab: Support &typeid(x) == &typeid(y) in constant evaluation [PR103600]

[Jason Merrill via Gcc-patches]

On 12/9/21 15:15, Jakub Jelinek wrote:

On Wed, Dec 08, 2021 at 08:53:03AM -0500, Jason Merrill wrote:

As mentioned in the PR, the varpool/middle-end code is trying to be
conservative with address comparisons of different vars if those vars
don't bind locally, because of possible aliases in other TUs etc.


Would it make sense to assume that DECL_ARTIFICIAL variables can't be
aliases?  If not, could we have some way of marking a variable as
non-aliasing, perhaps an attribute?


I think DECL_ARTIFICIAL vars generally can overlap.

The following patch adds a GCC internal attribute "non overlapping"
and uses it in symtab_node::equal_address_to.
Not sure what plans has Honza in that area and whether it would be useful
to make the attribute public and let users assert that some variable will
never overlap with other variables, won't have aliases etc.


During constant evaluation, the operator== could compare the type_info
address instead of the __name address, reducing this to the previous
problem.


Ah, indeed, good idea.  FYI, clang++ seems to constant fold
&typeid(x) != &typeid(y) already, so Jonathan could use it even for
clang++ in the constexpr operator==.  But it folds even
extern int &a, &b;
constexpr bool c = &a != &b;
regardless of whether some other TU has
int a;
int b __attribute__((alias (a));
or not.

Here is an updated patch, ok for trunk if it passes bootstrap/regtest?


LGTM for fixing the specific typeid issue, if Honza has no objection.

For the more general comparison of decls like your a != b example above 
I think clang is in the right; in manifestly constant-evaluated context 
(folding_initializer) we should return that they are unequal and prevent 
a later alias declaration, like we do for comparison to 0 in 
maybe_nonzero_address.  It's possible that this gives a wrong answer 
based on something in another translation unit, but that's unlikely, and 
taking that chance seems better than rejecting code that needs a 
constant answer.



2021-12-09  Jakub Jelinek  

PR c++/103600
gcc/
* symtab.c (symtab_node::equal_address_to): Return 0 if one of
VAR_DECLs has "non overlapping" attribute and rs1 != rs2.
gcc/c-family/
* c-attribs.c (handle_non_overlapping_attribute): New function.
(c_common_attribute_table): Add "non overlapping" attribute.
gcc/cp/
* rtti.c (get_tinfo_decl_direct): Add "non overlapping" attribute
to DECL_TINFO_P VAR_DECLs.
gcc/testsuite/
* g++.dg/cpp0x/constexpr-typeid2.C: New test.

--- gcc/symtab.c.jj 2021-11-19 09:58:37.268716406 +0100
+++ gcc/symtab.c2021-12-09 20:41:30.085566768 +0100
@@ -2276,6 +2276,14 @@ symtab_node::equal_address_to (symtab_no
return 0;
  }
  
+  /* If the FE tells us at least one of the decls will never be aliased nor

+ overlapping with other vars in some other way, return 0.  */
+  if (VAR_P (decl)
+  && rs1 != rs2
+  && (lookup_attribute ("non overlapping", DECL_ATTRIBUTES (decl))
+ || lookup_attribute ("non overlapping", DECL_ATTRIBUTES (s2->decl
+return 0;
+
/* TODO: Alias oracle basically assume that addresses of global variables
   are different unless they are declared as alias of one to another while
   the code folding comparisons doesn't.
--- gcc/c-family/c-attribs.c.jj 2021-09-11 09:33:37.734334126 +0200
+++ gcc/c-family/c-attribs.c2021-12-09 20:44:42.593810421 +0100
@@ -159,6 +159,7 @@ static tree handle_omp_declare_variant_a
  static tree handle_simd_attribute (tree *, tree, tree, int, bool *);
  static tree handle_omp_declare_target_attribute (tree *, tree, tree, int,
 bool *);
+static tree handle_non_overlapping_attribute (tree *, tree, tree, int, bool *);
  static tree handle_designated_init_attribute (tree *, tree, tree, int, bool 
*);
  static tree handle_patchable_function_entry_attribute (tree *, tree, tree,
   int, bool *);
@@ -512,6 +513,8 @@ const struct attribute_spec c_common_att
  handle_omp_declare_target_attribute, NULL },
{ "omp declare target block", 0, 0, true, false, false, false,
  handle_omp_declare_target_attribute, NULL },
+  { "non overlapping", 0, 0, true, false, false, false,
+ handle_non_overlapping_attribute, NULL },
{ "alloc_align",1, 1, false, true, true, false,
  handle_alloc_align_attribute,
  attr_alloc_exclusions },
@@ -3764,6 +3767,15 @@ handle_omp_declare_target_attribute (tre
  {
return NULL_TREE;
  }
+
+/* Handle an "non overlapping" attribute; arguments as in
+   struct attribute_spec.handler.  */
+
+static tree
+handle_non_overlapping_attribute (tree *, tree, tree, int, bool *)
+{
+  return NULL_TREE;
+}
  
  /* Handle a "returns_twice" attribute; arguments as in

 struct attribute_spec.handle

[committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

[Jonathan Wakely via Gcc-patches]

These warnings are triggered by perfectly valid code using std::string.
They're particularly bad when --enable-fully-dynamic-string is used,
because even std::string().begin() will give a warning.

Use pragmas to stop the troublesome warnings for copies done by
std::char_traits.

libstdc++-v3/ChangeLog:

PR libstdc++/103332
PR libstdc++/102958
PR libstdc++/103483
* include/bits/char_traits.h: Suppress stringop and array-bounds
warnings.
---
 libstdc++-v3/include/bits/char_traits.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libstdc++-v3/include/bits/char_traits.h 
b/libstdc++-v3/include/bits/char_traits.h
index da3e0aa..3f7befcf8b2 100644
--- a/libstdc++-v3/include/bits/char_traits.h
+++ b/libstdc++-v3/include/bits/char_traits.h
@@ -54,6 +54,11 @@ namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wstringop-overflow"
+#pragma GCC diagnostic ignored "-Wstringop-overread"
+#pragma GCC diagnostic ignored "-Warray-bounds"
+
   /**
*  @brief  Mapping from character type to associated types.
*
@@ -990,6 +995,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   } // namespace __detail
 #endif // C++20
 
+#pragma GCC diagnostic push
+
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace
 
-- 
2.31.1

Re: [PATCH] libstdc++: Fix non-reserved name in std::allocator base class [PR64135]

[Jonathan Wakely via Gcc-patches]

On Thu, 2 Dec 2021 at 17:22, Jonathan Wakely via Libstdc++
 wrote:
>
> I'd like to push this to trunk to fix PR64135.

The attached patch is what I've pushed to trunk, which adds some doc updates.

> It think this fixes the use of a non-reserved name, while preserving the
> ABI as far as class layout goes. It will break any programs which rely
> on std::allocator having a __gnu_cxx::new_allocator base class, e.g. so
> that is_convertible<__gnu_cxx::new_allocator&, std::allocator&> is
> true, but I don't see why anybody would do that.
>
> ...
>
> The possible base classes of std::allocator are new_allocator and
> malloc_allocator, which both cause a non-reserved name to be declared in
> every program that includes the definition of std::allocator. This is
> non-conforming.
>
> This change replaces __gnu_cxx::new_allocator with std::__new_allocator
> which is identical except for using a reserved name. The non-standard
> extension __gnu_cxx::new_allocator is preserved as a thin wrapper over
> std::__new_allocator. There is no problem with the extension using a
> non-reserved name now that it's not included by default in other
> headers.
>
> The same change could be done to __gnu_cxx::malloc_allocator but as it's
> not the default configuration it can wait.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/64135
> * config/allocator/new_allocator_base.h: Include
>  instead of .
> (__allocator_base): Use std::__new_allocator instead of
> __gnu_cxx::new_allocator.
> * include/Makefile.am: Add bits/new_allocator.h.
> * include/Makefile.in: Regenerate.
> * include/experimental/memory_resource (new_delete_resource):
> Use std::__new_allocator instead of __gnu_cxx::new_allocator.
> * include/ext/new_allocator.h (new_allocator): Derive from
> std::__new_allocator. Move implementation to ...
> * include/bits/new_allocator.h: New file.
> * testsuite/20_util/allocator/64135.cc: New test.
commit fe9571a35db53e5203326f854f73e432691d67f6
Author: Jonathan Wakely 
Date:   Wed Dec 1 17:56:23 2021

libstdc++: Fix non-reserved name in std::allocator base class [PR64135]

The possible base classes of std::allocator are new_allocator and
malloc_allocator, which both cause a non-reserved name to be declared in
every program that includes the definition of std::allocator. This is
non-conforming.

This change replaces __gnu_cxx::new_allocator with std::__new_allocator
which is identical except for using a reserved name. The non-standard
extension __gnu_cxx::new_allocator is preserved as a thin wrapper over
std::__new_allocator. There is no problem with the extension using a
non-reserved name now that it's not included by default in other
headers.

The same change could be done to __gnu_cxx::malloc_allocator but as it's
not the default configuration it can wait.

libstdc++-v3/ChangeLog:

PR libstdc++/64135
* config/allocator/new_allocator_base.h: Include
 instead of .
(__allocator_base): Use std::__new_allocator instead of
__gnu_cxx::new_allocator.
* doc/xml/manual/allocator.xml: Document new default base class
for std::allocator.
* doc/xml/manual/evolution.xml: Likewise.
* doc/html/*: Regenerate.
* include/Makefile.am: Add bits/new_allocator.h.
* include/Makefile.in: Regenerate.
* include/experimental/memory_resource (new_delete_resource):
Use std::__new_allocator instead of __gnu_cxx::new_allocator.
* include/ext/new_allocator.h (new_allocator): Derive from
std::__new_allocator. Move implementation to ...
* include/bits/new_allocator.h: New file.
* testsuite/20_util/allocator/64135.cc: New test.

diff --git a/libstdc++-v3/config/allocator/new_allocator_base.h 
b/libstdc++-v3/config/allocator/new_allocator_base.h
index 7c52fef63de..a139f2fb668 100644
--- a/libstdc++-v3/config/allocator/new_allocator_base.h
+++ b/libstdc++-v3/config/allocator/new_allocator_base.h
@@ -30,7 +30,7 @@
 #ifndef _GLIBCXX_CXX_ALLOCATOR_H
 #define _GLIBCXX_CXX_ALLOCATOR_H 1
 
-#include 
+#include 
 
 #if __cplusplus >= 201103L
 namespace std
@@ -38,18 +38,17 @@ namespace std
   /**
*  @brief  An alias to the base class for std::allocator.
*
-   *  Used to set the std::allocator base class to
-   *  __gnu_cxx::new_allocator.
+   *  Used to set the std::allocator base class to std::__new_allocator.
*
*  @ingroup allocators
*  @tparam  _Tp  Type of allocated object.
 */
   template
-using __allocator_base = __gnu_cxx::new_allocator<_Tp>;
+using __allocator_base = __new_allocator<_Tp>;
 }
 #else
-// Define new_allocator as the base class to std::allocator.
-# define __allocator_base  __gnu_cxx::new_allocator
+// Define __new_allocator as the base class to st

Re: [PATCH] libstdc++: Do not leak empty COW strings

[Jonathan Wakely via Gcc-patches]

On Thu, 2 Dec 2021 at 17:21, Jonathan Wakely via Libstdc++
 wrote:
>
> Apart from "don't bother changing the COW string", does anybody see a
> reason we shouldn't do this? This passes all tests for normal COW
> strings and fully-dynamic COW strings.

Pushed to trunk.

>
> When non-const references, pointers or iterators are obtained to the
> contents of a COW std::basic_string, the implementation has to assume it
> could result in a write to the contents. If the string was previously
> shared, it does the "copy-on-write" step of creating a new copy of the
> data that is not shared by another object.  It also marks the string as
> "leaked", so that no future copies of it will share ownership either.
>
> However, if the string is empty then the only character in the sequence
> is the terminating null, and modifying that is undefined behaviour. This
> means that non-const references/pointers/iterators to an empty string
> are effectively const. Since no direct modification is possible, there
> is no need to "leak" the string, it can be safely shared with other
> objects. This avoids unnecessary allocations to create new copies of
> empty strings that can't be modified anyway.
>
> We already did this optimization for strings that share ownership of the
> static _S_empty_rep() object, but not for strings that have non-zero
> capacity, and not for fully-dynamic-strings (where the _S_empty_rep()
> object is never used).
>
> With this change we avoid two allocations in the return statement:
>
>   std::string s;
>   s.reserve(1);   // allocate
>   std::string s2 = s;
>   std::string s3 = s;
>   return s[0] + s2[0] + s3[0]; // leak+allocate twice
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/cow_string.h (basic_string::_M_leak_hard): Do not
> reallocate an empty string.
> ---
>  libstdc++-v3/include/bits/cow_string.h | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/libstdc++-v3/include/bits/cow_string.h 
> b/libstdc++-v3/include/bits/cow_string.h
> index 389b39583e4..b21a7422246 100644
> --- a/libstdc++-v3/include/bits/cow_string.h
> +++ b/libstdc++-v3/include/bits/cow_string.h
> @@ -3366,10 +3366,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  basic_string<_CharT, _Traits, _Alloc>::
>  _M_leak_hard()
>  {
> -#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
> -  if (_M_rep() == &_S_empty_rep())
> +  // No need to create a new copy of an empty string when a non-const
> +  // reference/pointer/iterator into it is obtained. Modifying the
> +  // trailing null character is undefined, so the ref/pointer/iterator
> +  // is effectively const anyway.
> +  if (this->empty())
> return;
> -#endif
> +
>if (_M_rep()->_M_is_shared())
> _M_mutate(0, 0, 0);
>_M_rep()->_M_set_leaked();
> --
> 2.31.1
>

[committed] libstdc++: Avoid unnecessary allocations in std::map insertions [PR92300]

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.


Inserting a pair into a map will allocate a new
node and construct a pair in the node, then check if
the Key is already present in the map. That is because pair
is not the same type as the map's value_type. But it only differs in the
const-qualification on the Key, and so we should be able to do the
lookup directly, without allocating a new node. This avoids allocating
and then deallocating a node for the case where the key is already found
and nothing gets inserted.

We can take this optimization further and lookup the key directly for a
pair, pair, pair etc. for any X. A strict
reading of the standard says we can only do this when we know the
allocator won't do anything funky with the value when constructing a
pair from a slightly different type. Inserting that
type only requires the value_type to be Cpp17EmplaceInsertable into the
container, and that doesn't have any requirement that the value is
unchanged (unlike Cpp17CopyInsertable and Cpp17MoveInsertable). For that
reason, the optimization is only done for maps using std::allocator.

A similar optimization can be done for map.emplace(key, value) where the
first argument is similar to the key_type and so can be looked up
without allocating a new node and constructing a key_type.

Finally, both of the insert and emplace cases can use the same
optimization when key_type is a scalar type and some other scalar is
being passed as the insert/emplace argument. Converting from one scalar
type to another won't have surprising value-altering behaviour, and has
no side effects (unlike e.g. constructing a std::string from a const
char* argument, which might allocate).

We don't need to do this for std::multimap, because we always insert the
new node even if the key is already present. So there's no benefit to
doing the lookup before allocating the new node.

libstdc++-v3/ChangeLog:

PR libstdc++/92300
* include/bits/stl_map.h (insert(Pair&&), emplace(Args&&...)):
Check whether the arguments can be looked up directly without
constructing a temporary node first.
* include/bits/stl_pair.h (__is_pair): Move to here, from ...
* include/bits/uses_allocator_args.h (__is_pair): ... here.
* testsuite/23_containers/map/modifiers/emplace/92300.cc: New test.
* testsuite/23_containers/map/modifiers/insert/92300.cc: New test.
---
 libstdc++-v3/include/bits/stl_map.h   | 49 ++-
 libstdc++-v3/include/bits/stl_pair.h  |  9 
 .../include/bits/uses_allocator_args.h|  6 ---
 .../map/modifiers/emplace/92300.cc| 36 ++
 .../map/modifiers/insert/92300.cc | 38 ++
 5 files changed, 130 insertions(+), 8 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/23_containers/map/modifiers/emplace/92300.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/map/modifiers/insert/92300.cc

diff --git a/libstdc++-v3/include/bits/stl_map.h 
b/libstdc++-v3/include/bits/stl_map.h
index cc87f11fb11..658d5865138 100644
--- a/libstdc++-v3/include/bits/stl_map.h
+++ b/libstdc++-v3/include/bits/stl_map.h
@@ -154,6 +154,13 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 
   typedef __gnu_cxx::__alloc_traits<_Pair_alloc_type> _Alloc_traits;
 
+#if __cplusplus >= 201703L
+  template>
+   static constexpr bool __usable_key
+ = __or_v,
+  __and_, is_scalar<_Key>>>;
+#endif
+
 public:
   // many of these are specified differently in ISO, but the following are
   // "functionally equivalent"
@@ -574,7 +581,27 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   template
std::pair
emplace(_Args&&... __args)
-   { return _M_t._M_emplace_unique(std::forward<_Args>(__args)...); }
+   {
+#if __cplusplus >= 201703L
+ if constexpr (sizeof...(_Args) == 2)
+   if constexpr (is_same_v>)
+ {
+   auto&& [__a, __v] = pair<_Args&...>(__args...);
+   if constexpr (__usable_key)
+ {
+   const key_type& __k = __a;
+   iterator __i = lower_bound(__k);
+   if (__i == end() || key_comp()(__k, (*__i).first))
+ {
+   __i = emplace_hint(__i, std::forward<_Args>(__args)...);
+   return {__i, true};
+ }
+   return {__i, false};
+ }
+ }
+#endif
+ return _M_t._M_emplace_unique(std::forward<_Args>(__args)...);
+   }
 
   /**
*  @brief Attempts to build and insert a std::pair into the %map.
@@ -814,7 +841,25 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
__enable_if_t::value,
  pair>
insert(_Pair&& __x)
-   { return _M_t._M_emplace_unique(std::forward<_Pair>(__x)); }
+   {
+#if __cplusplus >= 201703L
+ using _P2 = remove_reference_t<_Pair>;
+ if constexpr (__is_pair<_P2>)

Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

[Jonathan Wakely via Gcc-patches]

On Wed, 8 Dec 2021 at 17:26, Jonathan Wakely wrote:
>
> On Wed, 8 Dec 2021 at 00:36, Jonathan Wakely wrote:
> >
> > On Tue, 7 Dec 2021 at 21:52, Florian Weimer wrote:
> > >
> > > * Jonathan Wakely:
> > >
> > > > On Tue, 7 Dec 2021, 21:20 Florian Weimer via Libstdc++, 
> > > > 
> > > > wrote:
> > > >
> > > >  * Jonathan Wakely via Libstdc:
> > > >
> > > >  > If necessary we could keep the terminate-on-cancellation behaviour as
> > > >  > 
> > > > _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.4.11
> > > >  > and export the new behaviour as @@GLIBCXX_3.4.30, although this patch
> > > >  > doesn't do that.
> > > >
> > > >  Note that if this fix escapes into the wild and then you have to make
> > > >  the symbol version change, you will break newer applications.  In a few
> > > >  cases in glibc, we proactively added aliases at a different symbol
> > > >  version, but with the same implementation (at first).
> > > >
> > > > To be safe, we probably should preserve the old behaviour for the old
> > > > version of the symbol. If we decide that the new behaviour is always
> > > > preferable, we could change that later by making the old symbol an
> > > > alias for the new. If we don't decide that, we'll be glad we made it a
> > > > separate symbol.
> > >
> > > On the other hand, with separate versions, it's possible to reintroduce
> > > the old behavior at a later date, as a bugfix.  It's not strictly
> > > necessary to do that work upfront.  It's just nice to have this option.
> >
> > Ah yes, a new symbol version gives us more flexibility in every direction.
> >
> > > > I'll see if I can get it working with two versioned symbols. We don't
> > > > actually do that in libstdc++ currently, we only have a single version
> > > > of every symbol.
> > >
> > > Ping me if you want to discuss options. 8->
> >
> > Thanks. I'll try it and let you know how I get on.
>
> After resolving a PEBKAC issue, here's an incremental diff that
> preserves the old behaviour for the existing @GLIBCXX_3.4.11 symbol,
> but adds a new @@GLIBCXX_3.4.30 symbol that supports cancellation via
> __forced_unwind.

Pushed to trunk now, as attached.
commit 9e18a25331fa25c3907249fede65a02c6817b06e
Author: Jonathan Wakely 
Date:   Tue Dec 7 15:11:15 2021

libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

std::condition_variable::wait(unique_lock&) is incorrectly marked
noexcept, which means that the __forced_unwind exception used by NPTL
cancellation will terminate the process. It should allow exceptions to
pass through, so that a thread can be cleanly cancelled when waiting on
a condition variable.

The new behaviour is exported as a new version of the symbol, to avoid
an ABI break for existing code linked to the non-throwing definition of
the function. Code linked against older releases will have a reference
to the @GLIBCXX_3.4.11 version, andcode compiled against the new
libstdc++ will get a reference to the @@GLIBCXX_3.4.30 version.

libstdc++-v3/ChangeLog:

PR libstdc++/103382
* config/abi/pre/gnu.ver (GLIBCXX_3.4.11): Do not export old
symbol if .symver renaming is supported.
(GLIBCXX_3.4.30): Export new symbol if .symver renaming is
supported.
* doc/xml/manual/evolution.xml: Document change.
* doc/html/manual/api.html: Regenerate.
* include/bits/std_mutex.h (__condvar::wait, __condvar::wait_until):
Remove noexcept.
* include/std/condition_variable (condition_variable::wait):
Likewise.
* src/c++11/condition_variable.cc (condition_variable::wait):
Likewise.
* src/c++11/compatibility-condvar.cc (__nothrow_wait_cv::wait):
Define nothrow wrapper around std::condition_variable::wait and
export the old symbol as an alias to it.
* testsuite/30_threads/condition_variable/members/103382.cc: New 
test.

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index 8f3c7b3827e..b747351a1b9 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1285,7 +1285,6 @@ GLIBCXX_3.4.11 {
 # condition_variable
 _ZNSt18condition_variable10notify_allEv;
 _ZNSt18condition_variable10notify_oneEv;
-_ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE;
 _ZNSt18condition_variableC1Ev;
 _ZNSt18condition_variableC2Ev;
 _ZNSt18condition_variableD1Ev;
@@ -1295,6 +1294,12 @@ GLIBCXX_3.4.11 {
 _ZNSt22condition_variable_anyD1Ev;
 _ZNSt22condition_variable_anyD2Ev;
 
+#ifndef HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
+# The original definition of this symbol gets versioned as @GLIBCXX_3.4.11
+# if ".symver" is supported, or as @@GLIBCXX_3.4.11 otherwise.
+_ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE;
+#endif
+
 # thread
 _ZNSt6th

[committed] libstdc++: Implement std::ios_base::noreplace for C++23 [PR59769]

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.


This implements my P2467R0 proposal to support opening an fstream in
exclusive mode. The new constant is also supported pre-C++23 as
std::ios_base::__noreplace.

This proposal hasn't been approved for C++23 yet, but I am confident it
will be, as this is restoring a feture found in pre-ISO C++ iostreams
implementations (and still present in the MSVC library as _Noreplace).
If the proposal fails for C++23 we can remove the ios::noreplace
name and just keep ios::__noreplace as an extension.

libstdc++-v3/ChangeLog:

PR libstdc++/59769
* config/io/basic_file_stdio.cc (fopen_mode): Add support for
exclusive mode.
* include/bits/ios_base.h (_S_noreplace): Define new enumerator.
(ios_base::__noreplace): Define.
(ios_base::noreplace): Define for C++23.
* include/std/version (__cpp_lib_ios_noreplace): Define.
* testsuite/27_io/basic_ofstream/open/char/noreplace.cc: New test.
* testsuite/27_io/basic_ofstream/open/wchar_t/noreplace.cc: New test.
---
 libstdc++-v3/config/io/basic_file_stdio.cc| 46 +++
 libstdc++-v3/include/bits/ios_base.h  |  9 
 libstdc++-v3/include/std/version  |  1 +
 .../basic_ofstream/open/char/noreplace.cc | 29 
 .../basic_ofstream/open/wchar_t/noreplace.cc  | 29 
 5 files changed, 94 insertions(+), 20 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/27_io/basic_ofstream/open/char/noreplace.cc
 create mode 100644 
libstdc++-v3/testsuite/27_io/basic_ofstream/open/wchar_t/noreplace.cc

diff --git a/libstdc++-v3/config/io/basic_file_stdio.cc 
b/libstdc++-v3/config/io/basic_file_stdio.cc
index ce4a6380ebb..06ee016d016 100644
--- a/libstdc++-v3/config/io/basic_file_stdio.cc
+++ b/libstdc++-v3/config/io/basic_file_stdio.cc
@@ -78,32 +78,38 @@ namespace
out= std::ios_base::out,
trunc  = std::ios_base::trunc,
app= std::ios_base::app,
-   binary = std::ios_base::binary
+   binary = std::ios_base::binary,
+   noreplace = std::_S_noreplace
   };
 
 // _GLIBCXX_RESOLVE_LIB_DEFECTS
 // 596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes.
-switch (mode & (in|out|trunc|app|binary))
+switch (mode & (in|out|trunc|app|binary|noreplace))
   {
-  case (   out ): return "w";
-  case (   out  |app   ): return "a";
-  case ( app   ): return "a";
-  case (   out|trunc   ): return "w";
-  case (in ): return "r";
-  case (in|out ): return "r+";
-  case (in|out|trunc   ): return "w+";
-  case (in|out  |app   ): return "a+";
-  case (in  |app   ): return "a+";
+  case (   out   ): return "w";
+  case (   out |noreplace): return "wx";
+  case (   out|trunc ): return "w";
+  case (   out|trunc   |noreplace): return "wx";
+  case (   out  |app ): return "a";
+  case ( app ): return "a";
+  case (in   ): return "r";
+  case (in|out   ): return "r+";
+  case (in|out|trunc ): return "w+";
+  case (in|out|trunc   |noreplace): return "w+x";
+  case (in|out  |app ): return "a+";
+  case (in  |app ): return "a+";
 
-  case (   out  |binary): return "wb";
-  case (   out  |app|binary): return "ab";
-  case ( app|binary): return "ab";
-  case (   out|trunc|binary): return "wb";
-  case (in  |binary): return "rb";
-  case (in|out  |binary): return "r+b";
-  case (in|out|trunc|binary): return "w+b";
-  case (in|out  |app|binary): return "a+b";
-  case (in  |app|binary): return "a+b";
+  case (   out  |binary  ): return "wb";
+  case (   out  |binary|noreplace): return "wbx";
+  case (   out  |app|binary  ): return "ab";
+  case ( app|binary  ): return "ab";
+  case (   out|trunc|binary  ): return "wb";
+  case (in  |binary  ): return "rb";
+  case (in|out  |binary  ): return "r+b";
+  case (in|out|trunc|binary  ): return "w+b";
+  case (in|out|trunc|binary|noreplace): return "w+bx";
+  case (in|out  |app|binary  ): return "a+b";
+  case (in  |app|binary  ): return "a+b";
 
   default: return 0; // invalid
   }
diff --git a/libstdc++-v3/include/bits/ios_base.h 
b/libstdc++-v3/include/bits/ios_base.h
index d6626d4d26b..5db05524e1c 100644
--- a/libstdc++-v3/include/bits/ios_base.h
+++ b/libstdc++-v3/include/bits/ios_base.h
@@ -116,6 +116,7 @@ _GLIBCXX_BEGIN_N

[committed] libstdc++: Fix std::exception_ptr regressions [PR103630]

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.


This restores support for std::make_exception_ptr and for using
std::exception_ptr in C++98.

Because the new non-throwing implementation needs to use std::decay to
handle references the original throwing implementation is used for
C++98.

We also need to change the typeid expression so it doesn't yield the
dynamic type when the function parameter is a reference to a polymorphic
type. Otherwise the new exception object could be caught by any handler
matching the dynamic type, even though the actual exception object is
only a copy of the base class, sliced to the static type.

libstdc++-v3/ChangeLog:

PR libstdc++/103630
* libsupc++/exception_ptr.h (exception_ptr): Fix exception
specifications on inline definitions.
(make_exception_ptr): Decay the template parameter. Use typeid
of the static type.
* testsuite/18_support/exception_ptr/103630.cc: New test.
---
 libstdc++-v3/libsupc++/exception_ptr.h| 19 ++---
 .../18_support/exception_ptr/103630.cc| 39 +++
 2 files changed, 52 insertions(+), 6 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/18_support/exception_ptr/103630.cc

diff --git a/libstdc++-v3/libsupc++/exception_ptr.h 
b/libstdc++-v3/libsupc++/exception_ptr.h
index f9dffd565bf..f59752478b1 100644
--- a/libstdc++-v3/libsupc++/exception_ptr.h
+++ b/libstdc++-v3/libsupc++/exception_ptr.h
@@ -39,6 +39,10 @@
 #include 
 #include 
 
+#if __cplusplus >= 201103L
+# include 
+#endif
+
 #ifdef _GLIBCXX_EH_PTR_RELOPS_COMPAT
 # define _GLIBCXX_EH_PTR_USED __attribute__((__used__))
 #else
@@ -175,13 +179,14 @@ namespace std
 
 _GLIBCXX_EH_PTR_USED
 inline
-exception_ptr::exception_ptr() _GLIBCXX_NOEXCEPT
+exception_ptr::exception_ptr() _GLIBCXX_USE_NOEXCEPT
 : _M_exception_object(0)
 { }
 
 _GLIBCXX_EH_PTR_USED
 inline
-exception_ptr::exception_ptr(const exception_ptr& __other) 
_GLIBCXX_NOEXCEPT
+exception_ptr::exception_ptr(const exception_ptr& __other)
+_GLIBCXX_USE_NOEXCEPT
 : _M_exception_object(__other._M_exception_object)
 {
   if (_M_exception_object)
@@ -232,14 +237,16 @@ namespace std
 exception_ptr 
 make_exception_ptr(_Ex __ex) _GLIBCXX_USE_NOEXCEPT
 {
-#if __cpp_exceptions && __cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI
+#if __cpp_exceptions && __cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI \
+  && __cplusplus >= 201103L
+  using _Ex2 = typename remove_reference<_Ex>::type;
   void* __e = __cxxabiv1::__cxa_allocate_exception(sizeof(_Ex));
   (void) __cxxabiv1::__cxa_init_primary_exception(
- __e, const_cast(&typeid(__ex)),
- __exception_ptr::__dest_thunk<_Ex>);
+ __e, const_cast(&typeid(_Ex)),
+ __exception_ptr::__dest_thunk<_Ex2>);
   try
{
-  ::new (__e) _Ex(__ex);
+ ::new (__e) _Ex2(std::forward<_Ex>(__ex));
   return exception_ptr(__e);
}
   catch(...)
diff --git a/libstdc++-v3/testsuite/18_support/exception_ptr/103630.cc 
b/libstdc++-v3/testsuite/18_support/exception_ptr/103630.cc
new file mode 100644
index 000..58fb2abe4d2
--- /dev/null
+++ b/libstdc++-v3/testsuite/18_support/exception_ptr/103630.cc
@@ -0,0 +1,39 @@
+// { dg-do run }
+
+#include 
+#if __cplusplus < 201103L
+// std::make_exception_ptr is defined for C++98 as a GNU extension
+# include 
+#endif
+
+#include 
+
+struct B
+{
+  virtual bool derived() const { return false; }
+};
+
+struct D : B
+{
+  virtual bool derived() const { return true; }
+};
+
+int main()
+{
+  D d;
+  std::exception_ptr p = std::make_exception_ptr(d); // PR libstdc++/103630
+#if __cpp_exceptions
+  try
+  {
+std::rethrow_exception(p);
+  }
+  catch (const D& d)
+  {
+VERIFY(d.derived()); // PR libstdc++/103630
+  }
+  catch (const B& b)
+  {
+VERIFY(!b.derived());
+  }
+#endif
+}
-- 
2.31.1

[committed] libstdc++: Make std::make_exception_ptr work with -fno-exceptions [PR85813]

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.


This allows std::make_exception_ptr to be used in a translation unit
compiled with -fno-exceptions. This works because the new implementation
added for PR 68297 doesn't need to throw or catch anything. The catch is
there to handle exceptions from the constructor of the exception object,
which we can assume won't happen in a -fno-exceptions TU and so use the
__catch macro instead. If the constructor does throw (because it's
defined in a different TU which was compiled with exceptions enabled)
then that exception will propagate to the make_exception_ptr caller.
That seems acceptable for a program that is trying to mix & match TUs
compiled with and without exceptions, and using types that throw when
constructed. That should be rare, and can't reasonably be expected to
have sensible behaviour.

This also enables the new implementation for targets that use a
non-standard calling convention for the exceptionDestructor callback
(specifically, mingw, which uses __thiscall). All we need to do is mark
the __dest_thunk function template with the right calling convention.

Finally, the useless no-op definition of make_exception_ptr (which is
only used if both RTTI and exceptions are disabled) is marked
always_inline, to ensure that the linker won't keep that definition and
discard the functional ones when both definitions of the function are
present in the link. An alternative would be to add the abi_tag
attribute to the useless definition, but making it always_inline should
work, and it's small enough to always be inlined reliably.

libstdc++-v3/ChangeLog:

PR libstdc++/85813
* libsupc++/exception_ptr.h (__dest_thunk): Add macro for
destructor calling convention.
(make_exception_ptr): Enable non-throwing implementation for
-fno-exceptions and for non-standard calling conventions. Use
always_inline attribute on the useless no-rtti no-exceptions
definition.
* testsuite/18_support/exception_ptr/64241.cc: Add -fno-rtti so
the no-op implementation is still used.
---
 libstdc++-v3/libsupc++/exception_ptr.h| 30 ---
 .../18_support/exception_ptr/64241.cc |  2 +-
 2 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/libstdc++-v3/libsupc++/exception_ptr.h 
b/libstdc++-v3/libsupc++/exception_ptr.h
index f59752478b1..8c700e64265 100644
--- a/libstdc++-v3/libsupc++/exception_ptr.h
+++ b/libstdc++-v3/libsupc++/exception_ptr.h
@@ -225,6 +225,7 @@ namespace std
 
 /// @cond undocumented
 template
+  _GLIBCXX_CDTOR_CALLABI
   inline void
   __dest_thunk(void* __x)
   { static_cast<_Ex*>(__x)->~_Ex(); }
@@ -233,28 +234,28 @@ namespace std
   } // namespace __exception_ptr
 
   /// Obtain an exception_ptr pointing to a copy of the supplied object.
+#if (__cplusplus >= 201103L && __cpp_rtti) || __cpp_exceptions
   template
-exception_ptr 
+exception_ptr
 make_exception_ptr(_Ex __ex) _GLIBCXX_USE_NOEXCEPT
 {
-#if __cpp_exceptions && __cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI \
-  && __cplusplus >= 201103L
-  using _Ex2 = typename remove_reference<_Ex>::type;
+#if __cplusplus >= 201103L && __cpp_rtti
+  using _Ex2 = typename decay<_Ex>::type;
   void* __e = __cxxabiv1::__cxa_allocate_exception(sizeof(_Ex));
   (void) __cxxabiv1::__cxa_init_primary_exception(
  __e, const_cast(&typeid(_Ex)),
  __exception_ptr::__dest_thunk<_Ex2>);
-  try
+  __try
{
- ::new (__e) _Ex2(std::forward<_Ex>(__ex));
-  return exception_ptr(__e);
+ ::new (__e) _Ex2(__ex);
+ return exception_ptr(__e);
}
-  catch(...)
+  __catch(...)
{
  __cxxabiv1::__cxa_free_exception(__e);
  return current_exception();
}
-#elif __cpp_exceptions
+#else
   try
{
   throw __ex;
@@ -263,10 +264,17 @@ namespace std
{
  return current_exception();
}
-#else // no RTTI and no exceptions
-  return exception_ptr();
 #endif
 }
+#else // no RTTI and no exceptions
+  // This is always_inline so the linker will never use this useless definition
+  // instead of a working one compiled with RTTI and/or exceptions enabled.
+  template
+__attribute__ ((__always_inline__))
+exception_ptr
+make_exception_ptr(_Ex) _GLIBCXX_USE_NOEXCEPT
+{ return exception_ptr(); }
+#endif
 
 #undef _GLIBCXX_EH_PTR_USED
 
diff --git a/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc 
b/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc
index 486b16c8dcc..034a0a08a8c 100644
--- a/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc
+++ b/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc
@@ -15,7 +15,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-fno-exceptions -O0" }
+// { dg-options "-fno-exceptions -fno-rtti -O0" }
 // { dg-do 

[committed] libstdc++: Remove bogus dg-error for effective-target c++20

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.


This test no longer has additional errors for C++20 mode, so remove the
dg-error that is now failing, and the unnecessary dg-prune-output.

libstdc++-v3/ChangeLog:

* testsuite/20_util/scoped_allocator/69293_neg.cc: Remove
dg-error for c++20.
---
 libstdc++-v3/testsuite/20_util/scoped_allocator/69293_neg.cc | 4 
 1 file changed, 4 deletions(-)

diff --git a/libstdc++-v3/testsuite/20_util/scoped_allocator/69293_neg.cc 
b/libstdc++-v3/testsuite/20_util/scoped_allocator/69293_neg.cc
index fd37374447f..143adc3f51c 100644
--- a/libstdc++-v3/testsuite/20_util/scoped_allocator/69293_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/scoped_allocator/69293_neg.cc
@@ -47,8 +47,4 @@ test01()
   auto p = sa.allocate(1);
   sa.construct(p);  // this is required to be ill-formed
   // { dg-error "failed: .* uses_allocator is true" "" { target *-*-* } 0 }
-  // { dg-error "too many initializers for 'X'" "" { target c++2a } 0 }
 }
-
-// Needed because of PR c++/92193
-// { dg-prune-output "no matching function for call to" }
-- 
2.31.1

[committed] libstdc++: Fix ambiguous comparisons for iterators in C++20

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.

Since r11-1571 (c++: Refinements to "more constrained") was changed in
the front end, the following comment from stl_iterator.h stopped being
true:

  // These extra overloads are not needed in C++20, because the ones above
  // are constrained with a requires-clause and so overload resolution will
  // prefer them to greedy unconstrained function templates.

The requires-clause is no longer considered when comparing unrelated
function templates. That means that the constrained operator== specified
in the standard is no longer more constrained than the pathological
comparison operators defined in the testsuite_greedy_ops.h header. This
was causing several tests to FAIL in C++20 mode:

FAIL: 23_containers/deque/types/1.cc (test for excess errors)
FAIL: 23_containers/vector/types/1.cc (test for excess errors)
FAIL: 24_iterators/move_iterator/greedy_ops.cc (test for excess errors)
FAIL: 24_iterators/normal_iterator/greedy_ops.cc (test for excess errors)
FAIL: 24_iterators/reverse_iterator/greedy_ops.cc (test for excess errors)

The solution is to restore some of the non-standard comparison operators
that are more specialized than the greedy operators in the testsuite.

libstdc++-v3/ChangeLog:

* include/bits/stl_iterator.h (operator==, operator<=>): Define
overloads for homogeneous specializations of reverse_iterator,
__normal_iterator and move_iterator.
---
 libstdc++-v3/include/bits/stl_iterator.h | 50 +---
 1 file changed, 45 insertions(+), 5 deletions(-)

diff --git a/libstdc++-v3/include/bits/stl_iterator.h 
b/libstdc++-v3/include/bits/stl_iterator.h
index f6504ece560..6bd860b803e 100644
--- a/libstdc++-v3/include/bits/stl_iterator.h
+++ b/libstdc++-v3/include/bits/stl_iterator.h
@@ -574,6 +574,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 operator<=>(const reverse_iterator<_IteratorL>& __x,
const reverse_iterator<_IteratorR>& __y)
 { return __y.base() <=> __x.base(); }
+
+  // Additional, non-standard overloads to avoid ambiguities with greedy,
+  // unconstrained overloads in associated namespaces.
+
+  template
+[[nodiscard]]
+constexpr bool
+operator==(const reverse_iterator<_Iterator>& __x,
+  const reverse_iterator<_Iterator>& __y)
+requires requires { { __x.base() == __y.base() } -> convertible_to; }
+{ return __x.base() == __y.base(); }
+
+  template
+[[nodiscard]]
+constexpr compare_three_way_result_t<_Iterator, _Iterator>
+operator<=>(const reverse_iterator<_Iterator>& __x,
+   const reverse_iterator<_Iterator>& __y)
+{ return __y.base() <=> __x.base(); }
 #endif // C++20
   ///@}
 
@@ -1161,6 +1179,25 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
const __normal_iterator<_IteratorR, _Container>& __rhs)
 noexcept(noexcept(std::__detail::__synth3way(__lhs.base(), __rhs.base(
 { return std::__detail::__synth3way(__lhs.base(), __rhs.base()); }
+
+  template
+[[nodiscard]]
+constexpr bool
+operator==(const __normal_iterator<_Iterator, _Container>& __lhs,
+  const __normal_iterator<_Iterator, _Container>& __rhs)
+noexcept(noexcept(__lhs.base() == __rhs.base()))
+requires requires {
+  { __lhs.base() == __rhs.base() } -> std::convertible_to;
+}
+{ return __lhs.base() == __rhs.base(); }
+
+  template
+[[nodiscard]]
+constexpr std::__detail::__synth3way_t<_Iterator>
+operator<=>(const __normal_iterator<_Iterator, _Container>& __lhs,
+   const __normal_iterator<_Iterator, _Container>& __rhs)
+noexcept(noexcept(std::__detail::__synth3way(__lhs.base(), __rhs.base(
+{ return std::__detail::__synth3way(__lhs.base(), __rhs.base()); }
 #else
// Forward iterator requirements
   template
@@ -1689,14 +1726,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif
 { return !(__x < __y); }
 
-#if ! (__cplusplus > 201703L && __cpp_lib_concepts)
   // Note: See __normal_iterator operators note from Gaby to understand
   // why we have these extra overloads for some move_iterator operators.
 
-  // These extra overloads are not needed in C++20, because the ones above
-  // are constrained with a requires-clause and so overload resolution will
-  // prefer them to greedy unconstrained function templates.
-
   template
 [[__nodiscard__]]
 inline _GLIBCXX17_CONSTEXPR bool
@@ -1704,6 +1736,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   const move_iterator<_Iterator>& __y)
 { return __x.base() == __y.base(); }
 
+#if __cpp_lib_three_way_comparison
+  template
+[[__nodiscard__]]
+constexpr compare_three_way_result_t<_Iterator>
+operator<=>(const move_iterator<_Iterator>& __x,
+   const move_iterator<_Iterator>& __y)
+{ return __x.base() <=> __y.base(); }
+#else
   template
 [[__nodiscard__]]
 inline _GLIBCXX17_CONSTEXPR bool
-- 
2.31.1

Re: [PATCH 0/6] RFC: adding support to GCC for detecting trust boundaries

[Segher Boessenkool]

On Thu, Dec 09, 2021 at 09:42:04AM -0700, Martin Sebor wrote:
> On 12/6/21 12:40 PM, Segher Boessenkool wrote:
> >Named address spaces are completely target-specific.
> 
> My understanding of these kernel/user address spaces that David
> is adding for the benefit of the analyzer is that the correspond
> to what TR 18037 calls nested namespaces.  They're nested within
> the generic namespace that's a union of the twp.  With that, I'd
> expect them to be fully handled early on and be transparent
> afterwards.  Is implementing this idea not feasible in the GCC
> design?

As long as you can explain it, it can be implemented.  What I am saying
though is it is imnsho a very bad idea to try to implement this in terms
of named address spaces (which is a GCC extension).


Segher

Re: [RFC][PATCH] c++/46476 - implement -Wunreachable-code-return

[Martin Sebor via Gcc-patches]

On 12/9/21 3:58 PM, Jim Wilson wrote:
On Mon, Nov 29, 2021 at 5:21 PM Martin Sebor via Gcc-patches 
mailto:gcc-patches@gcc.gnu.org>> wrote:


There are some other "unusual" cases worth a look, such as missing
context of any kind except for like and column:

elfnn-riscv.c:3346:7: warning: statement after return is not reachable
[-Wunreachable-code-return]
elfnn-riscv.c:3349:7: warning: statement after return is not reachable
[-Wunreachable-code-return]
elfnn-riscv.c:3352:7: warning: statement after return is not reachable
[-Wunreachable-code-return]
elfnn-riscv.c:3355:7: warning: statement after return is not reachable
[-Wunreachable-code-return]


That file has "return ...; break;" inside a switch.  Warning for that is 
OK, and we shouldn't need a better warning message.  It is pretty 
obvious what is wrong.


Yes, it's obvious from code inspection.  What I meant is that
the warnings above don't show the code they refer to as other
messages do, like on the second line in:

/src/binutils-gdb/bfd/elf-attrs.c:450:7: warning: statement after return 
is not reachable [-Wunreachable-code-return]

  450 |   break;
  |   ^

If they did, no code inspection would be necessary to understand
that the warnings are valid and why (I suggested elsewhere to
add a note pointing to the statement that makes the one in
the warning unreachable; that would help in cases when the first
statement is obscured by a macro, for instance, or far away from
the warning site).

The above were the only warnings I saw in the Binutils build with
this problem (or ever, that I can think of).

Martin

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

[Martin Sebor via Gcc-patches]

On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote:

These warnings are triggered by perfectly valid code using std::string.
They're particularly bad when --enable-fully-dynamic-string is used,
because even std::string().begin() will give a warning.

Use pragmas to stop the troublesome warnings for copies done by
std::char_traits.


I'm still experimenting with some of the approaches we discussed
last week, but based on my findings so far this was going to be
my suggestion at lest for now, until or unless the problem turns
out to affect more code than just std::string.

That said, I noticed a typo in the patch:



libstdc++-v3/ChangeLog:

PR libstdc++/103332
PR libstdc++/102958
PR libstdc++/103483
* include/bits/char_traits.h: Suppress stringop and array-bounds
warnings.
---
  libstdc++-v3/include/bits/char_traits.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/libstdc++-v3/include/bits/char_traits.h 
b/libstdc++-v3/include/bits/char_traits.h
index da3e0aa..3f7befcf8b2 100644
--- a/libstdc++-v3/include/bits/char_traits.h
+++ b/libstdc++-v3/include/bits/char_traits.h
@@ -54,6 +54,11 @@ namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
  {
  _GLIBCXX_BEGIN_NAMESPACE_VERSION
  
+#pragma GCC diagnostic push

+#pragma GCC diagnostic ignored "-Wstringop-overflow"
+#pragma GCC diagnostic ignored "-Wstringop-overread"
+#pragma GCC diagnostic ignored "-Warray-bounds"


(Just for reference, as I mentioned in my private mail, at -O1
the same code also triggers -Wfree-nonheap-object.)


+
/**
 *  @brief  Mapping from character type to associated types.
 *
@@ -990,6 +995,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
} // namespace __detail
  #endif // C++20
  
+#pragma GCC diagnostic push


This should be pop.

Martin


+
  _GLIBCXX_END_NAMESPACE_VERSION
  } // namespace
  

[committed] d: Align methods to MINIMUM_METHOD_BOUNDARY.

[Iain Buclaw via Gcc-patches]

Hi,

This patch aligns all D defined methods to MINIMUM_METHOD_BOUNDARY,
improving interoperability with C++ methods.

Bootstrapped and regression tested on x86_64-linux-gnu, committed to
mainline and backported to the release branches.

Regards,
Iain.

gcc/d/ChangeLog:

* decl.cc (get_symbol_decl): Align methods to MINIMUM_METHOD_BOUNDARY.
---
 gcc/d/decl.cc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/d/decl.cc b/gcc/d/decl.cc
index a4976b68bf0..55c65759d65 100644
--- a/gcc/d/decl.cc
+++ b/gcc/d/decl.cc
@@ -1248,6 +1248,9 @@ get_symbol_decl (Declaration *decl)
  DECL_VINDEX (decl->csym) = size_int (fd->vtblIndex);
  DECL_VIRTUAL_P (decl->csym) = 1;
}
+
+ /* Align method to the specified target boundary.  */
+ SET_DECL_ALIGN (decl->csym, MINIMUM_METHOD_BOUNDARY);
}
   else if (fd->isMain () || fd->isCMain ())
{
-- 
2.30.2

Re: [PATCH] pch: Add support for relocation of the PCH data [PR71934]

[Eric Gallager via Gcc-patches]

On Wed, Dec 8, 2021 at 6:10 PM Jeff Law via Gcc-patches
 wrote:
>
>
>
> On 12/7/2021 2:55 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > The following patch adds support for relocation of the PCH blob on PCH
> > restore if we don't manage to get the preferred map slot for it.
> > The GTY stuff knows where all the pointers are, after all it relocates
> > it once during PCH save from the addresses where it was initially allocated
> > to addresses in the preferred map slot.
> > But, if we were to do it solely using GTY info upon PCH restore, we'd need
> > another set of GTY functions, which I think would make it less maintainable
> > and I think it would also be more costly at PCH restore time.  Those
> > functions would need to call something to add bias to pointers that haven't
> > been marked yet and make sure not to add bias to any pointer twice.
> >
> > So, this patch instead builds a relocation table (sorted list of addresses
> > in the blob which needs relocation) at PCH save time, stores it in a very
> > compact form into the gch file and upon restore, adjusts pointers in GTY
> > roots (that is right away in the root structures) and the addresses in the
> > relocation table.
> > The cost on stdc++.gch/O2g.gch (previously 85MB large) is about 3% file size
> > growth, there are 2.5 million pointers that need relocation in the gch blob
> > and the relocation table uses uleb128 for address deltas and needs ~1.01 
> > bytes
> > for one address that needs relocation, and about 20% compile time during
> > PCH save (I think it is mainly because of the need to qsort those 2.5
> > million pointers).  On PCH restore, if it doesn't need relocation (the usual
> > case), it is just an extra fread of sizeof (size_t) data and fseek
> > (in my tests real time on vanilla tree for #include  CU
> > was ~0.175s and with the patch but no relocation ~0.173s), while if it needs
> > relocation it took ~0.193s, i.e. 11.5% slower.
> >
> > The discovery of the pointers in the blob that need relocation is done
> > in the relocate_ptrs hook which does the pointer relocation during PCH save.
> > Unfortunately, I had to make one change to the gengtype stuff due to the
> > nested_ptr feature of GTY, which some libcpp headers and stringpool.c use.
> > The relocate_ptrs hook had 2 arguments, pointer to the pointer and a cookie.
> > When relocate_ptrs is done, in most cases it is called solely on the
> > subfields of the current object, so e.g.
> >if ((void *)(x) == this_obj)
> >  op (&((*x).u.fld[0].rt_rtx), cookie);
> > so relocate_ptrs can assert that ptr_p is within the
> > state->ptrs[state->ptrs_i]->obj ..
> > state->ptrs[state->ptrs_i]->obj+state->ptrs[state->ptrs_i]->size-sizeof(void*)
> > range and compute from that the address in the blob which will need
> > relocation (state->ptrs[state->ptrs_i]->new_addr is the new address
> > given to it and ptr_p-state->ptrs[state->ptrs_i]->obj is the relative
> > offset.  Unfortunately, for nested_ptr gengtype emits something like:
> >{
> >  union tree_node * x0 =
> >((*x).val.node.node) ? HT_IDENT_TO_GCC_IDENT (HT_NODE 
> > (((*x).val.node.node))) : NULL;
> >  if ((void *)(x) == this_obj)
> >op (&(x0), cookie);
> >  (*x).val.node.node = (x0) ? CPP_HASHNODE (GCC_IDENT_TO_HT_IDENT 
> > ((x0))) : NULL;
> >}
> > so relocate_ptrs is called with an address of some temporary variable and
> > so doesn't know where the pointer will finally be.
> > So, I've added another argument to relocate_ptrs (and to
> > gt_pointer_operator).  For the most common case I pass NULL as the new 
> > middle
> > argument to that function, first one remains pointer to the pointer that
> > needs adjustment and last the cookie.  The NULL seems to be cheap to compute
> > and short in the gt*.[ch] files and stands for ptr_p is an address within
> > the this_obj's range, remember its address.  For the nested_ptr case, the
> > new middle argument contains actual address of the pointer that might need
> > to be relocated, so instead of the above
> >op (&(x0), &((*x).val.node.node), cookie);
> > in there.  And finally, e.g. for the reorder case I need a way to tell
> > restore_ptrs to ignore a particular address for the relocation purposes
> > and only treat it the old way.  I've used for that the case when
> > the first and second arguments are equal.
> >
> > In order to enable support for mapping PCH as fallback at different
> > addresses than the preferred ones, a small change is needed to the
> > host pch_use_address hooks.  One change I've done to all of them is
> > the change of the type of the first argument from void * to void *&,
> > such that the actual address can be told to the callers (or shall I
> > instead use void **?), but another change that still needs to be done
> > in them if they want the relocation is actually not fail if they couldn't
> > get a preferred address, but instead modify what the first argument
> >

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

[Martin Sebor via Gcc-patches]

On 12/9/21 5:38 PM, Martin Sebor wrote:

On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote:

These warnings are triggered by perfectly valid code using std::string.
They're particularly bad when --enable-fully-dynamic-string is used,
because even std::string().begin() will give a warning.

Use pragmas to stop the troublesome warnings for copies done by
std::char_traits.


I'm still experimenting with some of the approaches we discussed
last week, but based on my findings so far this was going to be
my suggestion at lest for now, until or unless the problem turns
out to affect more code than just std::string.


Just minutes after I wrote this I tried following the clue
in the note printed for the test case from PR 103534 with
an enhancement I'm experimenting with:

/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:426:56: 
warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ 
specified size between 18446744073709551600 and 18446744073709551615 
exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
  426 | return static_cast(__builtin_memcpy(__s1, 
__s2, __n));
  | 
^
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:426:56: 
note: when 
‘(.std::__cxx11::basic_string::_M_string_length > 
18446744073709551599)’


and adding an assert to string::size():

  constexpr
  size_type
  size() const noexcept
  {
if (_M_string_length >= -1LU >> 1)
  __builtin_unreachable ();
return _M_string_length;
  }

That gets rid of the false positive in this PR.  I realize
the others happen for other reasons but this approach at least
suggests that there might be other ways to suppress them than
the #pragma.  Unlike it, the alternative approaches should also
improve codegen.



That said, I noticed a typo in the patch:



libstdc++-v3/ChangeLog:

PR libstdc++/103332
PR libstdc++/102958
PR libstdc++/103483
* include/bits/char_traits.h: Suppress stringop and array-bounds
warnings.
---
  libstdc++-v3/include/bits/char_traits.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/libstdc++-v3/include/bits/char_traits.h 
b/libstdc++-v3/include/bits/char_traits.h

index da3e0aa..3f7befcf8b2 100644
--- a/libstdc++-v3/include/bits/char_traits.h
+++ b/libstdc++-v3/include/bits/char_traits.h
@@ -54,6 +54,11 @@ namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
  {
  _GLIBCXX_BEGIN_NAMESPACE_VERSION
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wstringop-overflow"
+#pragma GCC diagnostic ignored "-Wstringop-overread"
+#pragma GCC diagnostic ignored "-Warray-bounds"


(Just for reference, as I mentioned in my private mail, at -O1
the same code also triggers -Wfree-nonheap-object.)


+
    /**
 *  @brief  Mapping from character type to associated types.
 *
@@ -990,6 +995,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
    } // namespace __detail
  #endif // C++20
+#pragma GCC diagnostic push


This should be pop.

Martin


+
  _GLIBCXX_END_NAMESPACE_VERSION
  } // namespace

Re: libstdc++: Make atomic::wait() const [PR102994]

[Thomas Rodgers via Gcc-patches]

Tested uild-x86_64-pc-linux-gnu, pushed to trunk and gcc-11.

On Thu, Nov 25, 2021 at 1:24 PM Jonathan Wakely  wrote:

> On Wed, 24 Nov 2021 at 01:27, Thomas Rodgers wrote:
> >
> > const qualification was also missing in the free functions for
> wait/wait_explicit/notify_one/notify_all. Revised patch attached.
>
> Please tweak the whitespace in the new test:
>
> > +test1(const std::atomic &a, char*p)
>
> The '&' should be on the type not the variable, and there should be a
> space before 'p':
>
> > +test1(const std::atomic& a, char* p)
>
> OK for trunk and gcc-11 with that tweak, thanks!
>
>

[r12-5874 Regression] FAIL: g++.dg/warn/string1.C (test for warnings, line 17) on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

f8463b0e3ec2438b4cfb8c9a468d59761db2c8a0 is the first bad commit
commit f8463b0e3ec2438b4cfb8c9a468d59761db2c8a0
Author: Jonathan Wakely 
Date:   Thu Dec 2 13:19:41 2021 +

libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

caused

FAIL: g++.dg/warn/string1.C(test for warnings, line 17)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-5874/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=g++.dg/warn/string1.C 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=g++.dg/warn/string1.C 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=g++.dg/warn/string1.C 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=g++.dg/warn/string1.C 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[committed 2/3] d: Update for new front-end interface.

[Iain Buclaw via Gcc-patches]

Hi,

This patch updates the gdc codegen interface for the new front-end.

Bootstrapped and regression tested on x86_64-linux-gnu, committed to
mainline.

Regards,
Iain.

---
gcc/d/ChangeLog:

* Make-lang.in (D_FRONTEND_OBJS): Add d/root-optional.o.
* d-attribs.cc (build_attributes): Update for new front-end interface.
* d-codegen.cc (d_build_call): Likewise.
* d-compiler.cc (Compiler::paintAsType): Likewise.
* d-lang.cc (d_handle_option): Remove OPT_fpreview_intpromote, add
handling of OPT_frevert_intpromote.
* d-port.cc (Port::valcpy): Assert buffer is aligned.
* d-target.cc (Target::isVectorOpSupported): Update for new front-end
interface.
* decl.cc (layout_class_initializer): Likewise.
* expr.cc (lvalue_p): Likewise.
(binop_assignment): Likewise.
(ExprVisitor::visit): Likewise.
(ExprVisitor::visit (AssignExp *)): Remove generation of _d_arrayctor
and _d_arraysetctor library helpers.
(ExprVisitor::visit (VarExp *)): Support __traits(initSymbol).
* intrinsics.cc (expand_intrinsic_rotate): Update for new front-end
interface.
* lang.opt (fpreview=intpromote): Remove.
(frevert=intpromote): New.
* runtime.def (ARRAYCTOR): Remove.
(ARRAYSETCTOR): Remove.
* toir.cc (IRVisitor::visit): Update for new front-end interface.
* types.cc (layout_aggregate_members): Likewise.
---
 gcc/d/Make-lang.in|1 +
 gcc/d/d-attribs.cc|6 +-
 gcc/d/d-codegen.cc|6 +-
 gcc/d/d-compiler.cc   |4 +-
 gcc/d/d-lang.cc   |   11 +-
 gcc/d/d-port.cc   |2 +
 gcc/d/d-target.cc |   30 +-
 gcc/d/decl.cc |2 +-
 gcc/d/expr.cc |  259 +--
 gcc/d/intrinsics.cc   |2 +-
 gcc/d/lang.opt|8 +-
 gcc/d/runtime.def |7 -
 gcc/d/toir.cc |3 +-
 gcc/d/types.cc|2 +-
 14 files changed, 178 insertions(+), 165 deletions(-)

diff --git a/gcc/d/Make-lang.in b/gcc/d/Make-lang.in
index d7f714760f7..00169a743a1 100644
--- a/gcc/d/Make-lang.in
+++ b/gcc/d/Make-lang.in
@@ -162,6 +162,7 @@ D_FRONTEND_OBJS = \
d/root-filename.o \
d/root-hash.o \
d/root-longdouble.o \
+   d/root-optional.o \
d/root-port.o \
d/root-region.o \
d/root-rmem.o \
diff --git a/gcc/d/d-attribs.cc b/gcc/d/d-attribs.cc
index 04b9791ab1b..5c9f569d1c4 100644
--- a/gcc/d/d-attribs.cc
+++ b/gcc/d/d-attribs.cc
@@ -337,10 +337,10 @@ build_attributes (Expressions *eattrs)
continue;
 
   /* Get the result of the attribute if it hasn't already been folded.  */
-  if (attr->op == TOKcall)
+  if (attr->op == EXP::call)
attr = attr->ctfeInterpret ();
 
-  if (attr->op != TOKstructliteral)
+  if (attr->op != EXP::structLiteral)
{
  warning_at (make_location_t (attr->loc), OPT_Wattributes,
  "%qE attribute has no effect",
@@ -353,7 +353,7 @@ build_attributes (Expressions *eattrs)
   Expressions *elems = attr->isStructLiteralExp ()->elements;
   Expression *e0 = (*elems)[0];
 
-  if (e0->op != TOKstring)
+  if (e0->op != EXP::string_)
{
  warning_at (make_location_t (attr->loc), OPT_Wattributes,
  "unknown attribute %qs", e0->toChars());
diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index c082ac5ab80..39c3c6ce987 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -2154,9 +2154,9 @@ d_build_call (TypeFunction *tf, tree callable, tree 
object,
{
Lagain:
  Expression *arg = (*arguments)[i];
- gcc_assert (arg->op != TOKtuple);
+ gcc_assert (arg->op != EXP::tuple);
 
- if (arg->op == TOKcomma)
+ if (arg->op == EXP::comma)
{
  CommaExp *ce = arg->isCommaExp ();
  tree tce = build_expr (ce->e1);
@@ -2200,7 +2200,7 @@ d_build_call (TypeFunction *tf, tree callable, tree 
object,
  /* Nested structs also have ADDRESSABLE set, but if the type has
 neither a copy constructor nor a destructor available, then we
 need to take care of copying its value before passing it.  */
- if (arg->op == TOKstructliteral || (!sd->postblit && !sd->dtor))
+ if (arg->op == EXP::structLiteral || (!sd->postblit && !sd->dtor))
targ = force_target_expr (targ);
 
  targ = convert (build_reference_type (TREE_TYPE (targ)),
diff --git a/gcc/d/d-compiler.cc b/gcc/d/d-compiler.cc
index 3df40073ac5..c1e78c0a5de 100644
--- a/gcc/d/d-compiler.cc
+++ b/gcc/d/d-c

Re: [RFC] Overflow check in simplifying exit cond comparing two IVs.

[Jiufu Guo via Gcc-patches]

Jiufu Guo  writes:

> Richard Biener  writes:
>
>> On Mon, 18 Oct 2021, Jiufu Guo wrote:
>>
>>> With reference the discussions in:
>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574334.html
>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572006.html
>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578672.html
>>> 
>>> Base on the patches in above discussion, we may draft a patch to fix the
>>> issue.
>>> 
>>> In this patch, to make sure it is ok to change '{b0,s0} op {b1,s1}' to
>>> '{b0,s0-s1} op {b1,0}', we also compute the condition which could assume
>>> both 2 ivs are not overflow/wrap: the niter "of '{b0,s0-s1} op {b1,0}'"
>>> < the niter "of untill wrap for iv0 or iv1".
>>> 
>>> Does this patch make sense?
>>
>> Hum, the patch is mightly complex :/  I'm not sure we can throw
>> artficial IVs at number_of_iterations_cond and expect a meaningful
>> result.
>>
>> ISTR the problem is with number_of_iterations_ne[_max], but I would
>> have to go and dig in myself again for a full recap of the problem.
>> I did plan to do that, but not before stage3 starts.
>>
>> Thanks,
>> Richard.
>
> Hi Richard,
>
> Thanks for your comment!  It is really complex, using artificial IVs and
> recursively calling number_of_iterations_cond.  We may use a simpler way.
> Not sure if you had started to dig into the problem.  I refined a patch.
> Hope this patch is helpful.  This patch enhances the conditions in some
> aspects. Attached are two test cases that could be handled.

Some questions, I want to consult here, it may help to make the patch
works better.

- 1. For signed type, I'm wondering if we could leverage the idea about
  "UB on signed overflow" in the phase to call number_of_iterations_cond
  where may be far from user source code.
  If we can, we may just ignore the assumption for signed type.
  But then, there would be inconsitent behavior between noopt(-O0) and
  opt (e.g. -O2/-O3).  For example:
  "{INT_MAX-124, +5} < {INT_MAX-27, +1}".
  At -O0, the 'niter' would be 28; while, at -O3, it may result as 26.

- 2. For NEQ, which you may also concern, the assumption
  "delta % step == 0" would make it safe.  It seems current, we handle
  NEQ where no_overflow is true for both iv0 and iv1.

- 3. In the current patch, DIV_EXPR is used, the cost may be high in
  some cases.  I'm wondering if the below idea is workable:
  Extent to longer type, and using MULT instead DIV, for example:
  a < b/c ===> a*c < b.  a*c may be need to use longer type than 'a'.

-- 3.1 For some special case, e.g. "{b0, 5} < {b1, -5}", the assumption
   may be able to simplied.  For general case, still thinking to reduce
   the runtime cost from assumption.
   

Thanks again!

BR,
Jiufu

>
> ---
>  gcc/tree-ssa-loop-niter.c | 92 +++
>  .../gcc.c-torture/execute/pr100740.c  | 11 +++
>  gcc/testsuite/gcc.dg/vect/pr102131.c  | 47 ++
>  3 files changed, 134 insertions(+), 16 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr100740.c
>  create mode 100644 gcc/testsuite/gcc.dg/vect/pr102131.c
>
> diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
> index 06954e437f5..ee1d7293c5c 100644
> --- a/gcc/tree-ssa-loop-niter.c
> +++ b/gcc/tree-ssa-loop-niter.c
> @@ -1788,6 +1788,70 @@ dump_affine_iv (FILE *file, affine_iv *iv)
>  }
>  }
>  
> +/* Generate expr: (HIGH - LOW) / STEP, under UTYPE. */
> +
> +static tree
> +get_step_count (tree high, tree low, tree step, tree utype,
> + bool end_inclusive = false)
> +{
> +  tree delta = fold_build2 (MINUS_EXPR, TREE_TYPE (low), high, low);
> +  delta = fold_convert (utype,delta);
> +  if (end_inclusive)
> +delta = fold_build2 (PLUS_EXPR, utype, delta, build_one_cst (utype));
> +
> +  if (tree_int_cst_sign_bit (step))
> +step = fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step);
> +  step = fold_convert (utype, step);
> +
> +  return fold_build2 (FLOOR_DIV_EXPR, utype, delta, step);
> +}
> +
> +/*  Get the additional assumption if both two steps are not zero.
> +Assumptions satisfy that there is no overflow or wrap during
> +v0 and v1 chasing.  */
> +
> +static tree
> +extra_iv_chase_assumption (affine_iv *iv0, affine_iv *iv1, tree step,
> +enum tree_code code)
> +{
> +  /* No need additional assumptions.  */
> +  if (code == NE_EXPR)
> +return boolean_true_node;
> +
> +  /* it not safe to transform {b0, 1} < {b1, 2}.  */
> +  if (tree_int_cst_sign_bit (step))
> +return boolean_false_node;
> +
> +  /* No need addition assumption for pointer.  */
> +  tree type = TREE_TYPE (iv0->base);
> +  if (POINTER_TYPE_P (type))
> +return boolean_true_node;
> +
> +  bool positive0 = !tree_int_cst_sign_bit (iv0->step);
> +  bool positive1 = !tree_int_cst_sign_bit (iv1->step);
> +  bool positive = !tree_int_cst_sign_bit (step);
> +  tree utype = unsigned_type_for (type);
> +  bool add1 = code == LE_EXPR;
> +  tree niter = positive
> + 

[PATCH v3 00/12] Add LoongArch support.

[Chenghua Xu]

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

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

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

Note: We split -mabi= into -mabi=lp64d/f/s, the new options not support by 
upstream binutils yet, 
this GCC port requires the following patch applied to binutils to build.
https://github.com/loongson/binutils-gdb/commit/aacb0bf860f02aa5a7dcb76dd0e392bf871c7586
(will be submitted to upstream after gcc side comfirmed)


changelog:

v1 -> v2
1. Split patch set.
2. Change some code style.
3. Add -mabi=lp64d/f/s options.
4. Change GLIBC_DYNAMIC_LINKER_LP64 name.

v2 -> v3
1. Change some code style.
2. Bug fix.

We will donate LoongArch machine to Cfarm for testing.


*** BLURB HERE ***

chenglulu (12):
  LoongArch Port: gcc build
  LoongArch Port: Regenerate gcc/configure.
  LoongArch Port: Machine Decsription files.
  LoongArch Port: Machine description C files and .h files.
  LoongArch Port: Builtin functions.
  LoongArch Port: Builtin macros.
  LoongArch Port: libgcc
  LoongArch Port: Regenerate libgcc/configure.
  LoongArch Port: libgomp
  LoongArch Port: gcc/testsuite
  LoongArch Port: Regenerate configure
  LoongArch Port: Add doc.

 config/picflag.m4 |3 +
 configure |   10 +-
 configure.ac  |   10 +-
 contrib/config-list.mk|5 +-
 .../config/loongarch/loongarch-common.c   |   63 +
 gcc/config.gcc|  400 +-
 gcc/config/host-linux.c   |2 +
 gcc/config/loongarch/constraints.md   |  212 +
 gcc/config/loongarch/generic.md   |  132 +
 gcc/config/loongarch/genopts/genstr.sh|   91 +
 .../loongarch/genopts/loongarch-strings   |   58 +
 gcc/config/loongarch/genopts/loongarch.opt.in |  189 +
 gcc/config/loongarch/gnu-user.h   |   78 +
 gcc/config/loongarch/la464.md |  132 +
 gcc/config/loongarch/larchintrin.h|  413 ++
 gcc/config/loongarch/linux.h  |   48 +
 gcc/config/loongarch/loongarch-builtins.c |  511 ++
 gcc/config/loongarch/loongarch-c.c|  136 +
 gcc/config/loongarch/loongarch-cpu.c  |  206 +
 gcc/config/loongarch/loongarch-cpu.h  |   30 +
 gcc/config/loongarch/loongarch-def.c  |  164 +
 gcc/config/loongarch/loongarch-def.h  |  151 +
 gcc/config/loongarch/loongarch-driver.c   |  187 +
 gcc/config/loongarch/loongarch-driver.h   |   60 +
 gcc/config/loongarch/loongarch-ftypes.def |   95 +
 gcc/config/loongarch/loongarch-modes.def  |   35 +
 gcc/config/loongarch/loongarch-opts.c |  582 ++
 gcc/config/loongarch/loongarch-opts.h |   86 +
 gcc/config/loongarch/loongarch-protos.h   |  244 +
 gcc/config/loongarch/loongarch-str.h  |   57 +
 gcc/config/loongarch/loongarch-tune.h |   72 +
 gcc/config/loongarch/loongarch.c  | 6472 +
 gcc/config/loongarch/loongarch.h  | 1291 
 gcc/config/loongarch/loongarch.md | 3829 ++
 gcc/config/loongarch/loongarch.opt|  189 +
 gcc/config/loongarch/predicates.md|  553 ++
 gcc/config/loongarch/sync.md  |  574 ++
 gcc/config/loongarch/t-linux  |   53 +
 gcc/config/loongarch/t-loongarch  |   59 +
 gcc/configure |   63 +-
 gcc/configure.ac  |   33 +-
 gcc/doc/install.texi  |   47 +-
 gcc/doc/invoke.texi   |  201 +
 gcc/doc/md.texi   |   55 +
 gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C|2 +-
 gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C   |2 +-
 gcc/testsuite/g++.old-deja/g++.pt/ptrmem6.C   |2 +-
 gcc/testsuite/gcc.dg/20020312-2.c |2 +
 gcc/testsuite/gcc.dg/loop-8.c |2 +-
 .../torture/stackalign/builtin-apply-2.c  |2 +-
 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-3.c |2 +-
 .../gcc.target/loongarch/loongarch.exp|   40 +
 .../gcc.target/loongarch/tst-asm-const.c  |   16 +
 gcc/testsuite/go.test/go-test.exp |3 +
 gcc/testsuite/lib/target-supports.exp |   14 +
 libgcc/config.host|   28 +-
 libgcc/config/loongarch/crtfastmath.c |   52 +
 libgcc/config/loongarch/crti.S|   43 +
 libgcc/config/loongarch/crtn.S|   39 +
 libgcc/config/loongarch/lib2funcs.c   |0
 libgcc/config/loongarch/linux-unwind.h|   80 +
 libgcc/co

[PATCH v3 02/12] LoongArch Port: Regenerate gcc/configure.

[Chenghua Xu]

From: chenglulu 

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

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

[PATCH v3 01/12] LoongArch Port: gcc build

[Chenghua Xu]

From: chenglulu 

gcc/

* common/config/loongarch/loongarch-common.c: New file.
* config/loongarch/genopts/genstr.sh: New file.
* config/loongarch/genopts/loongarch-strings: New file.
* config/loongarch/genopts/loongarch.opt.in: New file.
* config/loongarch/gnu-user.h: New file.
* config/loongarch/linux.h: New file.
* config/loongarch/loongarch-cpu.c: New file.
* config/loongarch/loongarch-cpu.h: New file.
* config/loongarch/loongarch-driver.c: New file.
* config/loongarch/loongarch-driver.h: New file.
* config/loongarch/loongarch-opts.c: New file.
* config/loongarch/loongarch-opts.h: New file.
* config/loongarch/loongarch.opt: New file.
* config/loongarch/t-linux: New file.
* config/loongarch/t-loongarch: New file.
* config.gcc: Add LoongArch support.
* configure.ac: Add LoongArch support.
---
 .../config/loongarch/loongarch-common.c   |  63 ++
 gcc/config.gcc| 400 +++-
 gcc/config/loongarch/genopts/genstr.sh|  91 +++
 .../loongarch/genopts/loongarch-strings   |  58 ++
 gcc/config/loongarch/genopts/loongarch.opt.in | 189 ++
 gcc/config/loongarch/gnu-user.h   |  78 +++
 gcc/config/loongarch/linux.h  |  48 ++
 gcc/config/loongarch/loongarch-cpu.c  | 206 +++
 gcc/config/loongarch/loongarch-cpu.h  |  30 +
 gcc/config/loongarch/loongarch-def.c  | 164 +
 gcc/config/loongarch/loongarch-def.h  | 151 +
 gcc/config/loongarch/loongarch-driver.c   | 187 ++
 gcc/config/loongarch/loongarch-driver.h   |  60 ++
 gcc/config/loongarch/loongarch-opts.c | 582 ++
 gcc/config/loongarch/loongarch-opts.h |  86 +++
 gcc/config/loongarch/loongarch-str.h  |  57 ++
 gcc/config/loongarch/loongarch.opt| 189 ++
 gcc/config/loongarch/t-linux  |  53 ++
 gcc/config/loongarch/t-loongarch  |  59 ++
 gcc/configure.ac  |  33 +-
 20 files changed, 2779 insertions(+), 5 deletions(-)
 create mode 100644 gcc/common/config/loongarch/loongarch-common.c
 create mode 100755 gcc/config/loongarch/genopts/genstr.sh
 create mode 100644 gcc/config/loongarch/genopts/loongarch-strings
 create mode 100644 gcc/config/loongarch/genopts/loongarch.opt.in
 create mode 100644 gcc/config/loongarch/gnu-user.h
 create mode 100644 gcc/config/loongarch/linux.h
 create mode 100644 gcc/config/loongarch/loongarch-cpu.c
 create mode 100644 gcc/config/loongarch/loongarch-cpu.h
 create mode 100644 gcc/config/loongarch/loongarch-def.c
 create mode 100644 gcc/config/loongarch/loongarch-def.h
 create mode 100644 gcc/config/loongarch/loongarch-driver.c
 create mode 100644 gcc/config/loongarch/loongarch-driver.h
 create mode 100644 gcc/config/loongarch/loongarch-opts.c
 create mode 100644 gcc/config/loongarch/loongarch-opts.h
 create mode 100644 gcc/config/loongarch/loongarch-str.h
 create mode 100644 gcc/config/loongarch/loongarch.opt
 create mode 100644 gcc/config/loongarch/t-linux
 create mode 100644 gcc/config/loongarch/t-loongarch

diff --git a/gcc/common/config/loongarch/loongarch-common.c 
b/gcc/common/config/loongarch/loongarch-common.c
new file mode 100644
index 000..3f440aef1e7
--- /dev/null
+++ b/gcc/common/config/loongarch/loongarch-common.c
@@ -0,0 +1,63 @@
+/* Common hooks for LoongArch.
+   Copyright (C) 2021 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "common/common-target.h"
+#include "common/common-target-def.h"
+#include "opts.h"
+#include "flags.h"
+#include "diagnostic-core.h"
+
+/* Implement TARGET_HANDLE_OPTION.  */
+
+static bool
+loongarch_handle_option (struct gcc_options *opts,
+struct gcc_options *opts_set ATTRIBUTE_UNUSED,
+const struct cl_decoded_option *decoded,
+location_t loc ATTRIBUTE_UNUSED)
+{
+  size_t code = decoded->opt_index;
+  int value = decoded->value;
+
+  switch (code)
+{
+case OPT_mmemcpy:
+  if (value)
+   {
+ if (opts->x_optimize_size)
+   opts->x_target_flags |= MASK_MEMCPY;
+   }
+  else
+   opts->x_target_flags &= 

[PATCH v3 06/12] LoongArch Port: Builtin macros.

[Chenghua Xu]

From: chenglulu 

gcc/

*config/loongarch/loongarch-c.c
---
 gcc/config/loongarch/loongarch-c.c | 136 +
 1 file changed, 136 insertions(+)
 create mode 100644 gcc/config/loongarch/loongarch-c.c

diff --git a/gcc/config/loongarch/loongarch-c.c 
b/gcc/config/loongarch/loongarch-c.c
new file mode 100644
index 000..80678c5115a
--- /dev/null
+++ b/gcc/config/loongarch/loongarch-c.c
@@ -0,0 +1,136 @@
+/* LoongArch-specific code for C family languages.
+   Copyright (C) 2021 Free Software Foundation, Inc.
+   Contributed by Loongson Ltd.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#define IN_TARGET_CODE 1
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "c-family/c-common.h"
+#include "cpplib.h"
+
+#define preprocessing_asm_p() (cpp_get_options (pfile)->lang == CLK_ASM)
+#define builtin_define(TXT) cpp_define (pfile, TXT)
+#define builtin_assert(TXT) cpp_assert (pfile, TXT)
+
+/* Define preprocessor macros for the -march and -mtune options.
+   PREFIX is either _LOONGARCH_ARCH or _LOONGARCH_TUNE, INFO is
+   the selected processor.  If INFO's canonical name is "foo",
+   define PREFIX to be "foo", and define an additional macro
+   PREFIX_FOO.  */
+#define LARCH_CPP_SET_PROCESSOR(PREFIX, CPU_TYPE)  \
+  do   \
+{  \
+  char *macro, *p; \
+  int cpu_type = (CPU_TYPE);   \
+   \
+  macro = concat ((PREFIX), "_",   \
+ loongarch_cpu_strings[cpu_type], NULL);   \
+  for (p = macro; *p != 0; p++)\
+   *p = TOUPPER (*p);  \
+   \
+  builtin_define (macro);  \
+  builtin_define_with_value ((PREFIX), \
+loongarch_cpu_strings[cpu_type], 1);   \
+  free (macro);\
+}  \
+  while (0)
+
+/* TODO: what is the pfile technique ??? !!! */
+
+void
+loongarch_cpu_cpp_builtins (cpp_reader *pfile)
+{
+  builtin_assert ("machine=loongarch");
+  builtin_assert ("cpu=loongarch");
+  builtin_define ("__loongarch__");
+
+  LARCH_CPP_SET_PROCESSOR ("_LOONGARCH_ARCH", __ACTUAL_ARCH);
+  LARCH_CPP_SET_PROCESSOR ("_LOONGARCH_TUNE", __ACTUAL_TUNE);
+
+  /* Base architecture / ABI.  */
+  if (TARGET_64BIT)
+{
+  builtin_define ("__loongarch_grlen=64");
+  builtin_define ("__loongarch64");
+}
+
+  if (TARGET_ABI_LP64)
+{
+  builtin_define ("_ABILP64=3");
+  builtin_define ("_LOONGARCH_SIM=_ABILP64");
+  builtin_define ("__loongarch_lp64");
+}
+
+  /* These defines reflect the ABI in use, not whether the
+ FPU is directly accessible.  */
+  if (TARGET_DOUBLE_FLOAT_ABI)
+builtin_define ("__loongarch_double_float=1");
+  else if (TARGET_SINGLE_FLOAT_ABI)
+builtin_define ("__loongarch_single_float=1");
+
+  if (TARGET_DOUBLE_FLOAT_ABI || TARGET_SINGLE_FLOAT_ABI)
+builtin_define ("__loongarch_hard_float=1");
+  else
+builtin_define ("__loongarch_soft_float=1");
+
+
+  /* ISA Extensions.  */
+  if (TARGET_DOUBLE_FLOAT)
+builtin_define ("__loongarch_frlen=64");
+  else if (TARGET_SINGLE_FLOAT)
+builtin_define ("__loongarch_frlen=32");
+  else
+builtin_define ("__loongarch_frlen=0");
+
+  /* Native Data Sizes.  */
+  builtin_define_with_int_value ("_LOONGARCH_SZINT", INT_TYPE_SIZE);
+  builtin_define_with_int_value ("_LOONGARCH_SZLONG", LONG_TYPE_SIZE);
+  builtin_define_with_int_value ("_LOONGARCH_SZPTR", POINTER_SIZE);
+  builtin_define_with_int_value ("_LOONGARCH_FPSET", 32 / MAX_FPRS_PER_FMT);
+  builtin_define_with_int_value ("_LOONGARCH_SPFPSET", 32);
+
+  /* Macros dependent on the C dialect.  */
+  if (preprocessing_asm_p ())
+{
+  builtin_define_std ("LANGUAGE_ASSEMBLY");
+  builtin_define ("_LANGUAGE_ASSEMBLY");
+}
+  else if (c_dialect

[PATCH v3 05/12] LoongArch Port: Builtin functions.

[Chenghua Xu]

From: chenglulu 

gcc/

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

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

[PATCH v3 08/12] LoongArch Port: Regenerate libgcc/configure.

[Chenghua Xu]

From: chenglulu 

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

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

[PATCH v3 07/12] LoongArch Port: libgcc

[Chenghua Xu]

From: chenglulu 

libgcc/

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

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

[PATCH v3 09/12] LoongArch Port: libgomp

[Chenghua Xu]

From: chenglulu 

libgomp/

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

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

[PATCH v3 10/12] LoongArch Port: gcc/testsuite

[Chenghua Xu]

From: chenglulu 

gcc/testsuite/

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

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

[PATCH v3 11/12] LoongArch Port: Regenerate configure

[Chenghua Xu]

From: chenglulu 

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

diff --git a/config/picflag.m4 b/config/picflag.m4
index 8b106f9af88..0aefcf619bf 100644
--- a/config/picflag.m4
+++ b/config/picflag.m4
@@ -44,6 +44,9 @@ case "${$2}" in
# sets the default TLS model and affects inlining.
$1=-fPIC
;;
+loongarch*-*-*)
+   $1=-fpic
+   ;;
 mips-sgi-irix6*)
# PIC is the default.
;;
diff --git a/configure b/configure
index f8e6e2c3020..c738c551907 100755
--- a/configure
+++ b/configure
@@ -3054,7 +3054,7 @@ case "${ENABLE_GOLD}" in
   # Check for target supported by gold.
   case "${target}" in
 i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-* \
-| aarch64*-*-* | tilegx*-*-* | mips*-*-* | s390*-*-*)
+| aarch64*-*-* | tilegx*-*-* | mips*-*-* | s390*-*-* | loongarch*-*-*)
  configdirs="$configdirs gold"
  if test x${ENABLE_GOLD} = xdefault; then
default_ld=gold
@@ -3640,6 +3640,9 @@ case "${target}" in
   i[3456789]86-*-*)
 libgloss_dir=i386
 ;;
+  loongarch*-*-*)
+libgloss_dir=loongarch
+;;
   m68hc11-*-*|m6811-*-*|m68hc12-*-*|m6812-*-*)
 libgloss_dir=m68hc11
 ;;
@@ -4024,6 +4027,11 @@ case "${target}" in
   wasm32-*-*)
 noconfigdirs="$noconfigdirs ld"
 ;;
+  loongarch*-*-linux*)
+;;
+  loongarch*-*-*)
+noconfigdirs="$noconfigdirs gprof"
+;;
 esac
 
 # If we aren't building newlib, then don't build libgloss, since libgloss
diff --git a/configure.ac b/configure.ac
index 2de381fe863..14894798124 100644
--- a/configure.ac
+++ b/configure.ac
@@ -353,7 +353,7 @@ case "${ENABLE_GOLD}" in
   # Check for target supported by gold.
   case "${target}" in
 i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-* \
-| aarch64*-*-* | tilegx*-*-* | mips*-*-* | s390*-*-*)
+| aarch64*-*-* | tilegx*-*-* | mips*-*-* | s390*-*-* | loongarch*-*-*)
  configdirs="$configdirs gold"
  if test x${ENABLE_GOLD} = xdefault; then
default_ld=gold
@@ -899,6 +899,9 @@ case "${target}" in
   i[[3456789]]86-*-*)
 libgloss_dir=i386
 ;;
+  loongarch*-*-*)
+libgloss_dir=loongarch
+;;
   m68hc11-*-*|m6811-*-*|m68hc12-*-*|m6812-*-*)
 libgloss_dir=m68hc11
 ;;
@@ -1283,6 +1286,11 @@ case "${target}" in
   wasm32-*-*)
 noconfigdirs="$noconfigdirs ld"
 ;;
+  loongarch*-*-linux*)
+;;
+  loongarch*-*-*)
+noconfigdirs="$noconfigdirs gprof"
+;;
 esac
 
 # If we aren't building newlib, then don't build libgloss, since libgloss
-- 
2.27.0

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

[Chenghua Xu]

From: chenglulu 

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

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