Re: [RFC][PATCH] AArch64: Remove AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS

[Jennifer Schmitz]

> On 14 Dec 2024, at 09:32, Richard Biener  wrote:
> 
> External email: Use caution opening links or attachments
> 
> 
>> Am 13.12.2024 um 18:00 schrieb Jennifer Schmitz :
>> 
>> 
>> 
>>> On 13 Dec 2024, at 13:40, Richard Biener  wrote:
>>> 
>>> External email: Use caution opening links or attachments
>>> 
>>> 
 On Thu, Dec 12, 2024 at 5:27 PM Jennifer Schmitz  
 wrote:
 
 
 
> On 6 Dec 2024, at 08:41, Jennifer Schmitz  wrote:
> 
> 
> 
>> On 5 Dec 2024, at 20:07, Richard Sandiford  
>> wrote:
>> 
>> External email: Use caution opening links or attachments
>> 
>> 
>> Jennifer Schmitz  writes:
 On 5 Dec 2024, at 11:44, Richard Biener  wrote:
 
 External email: Use caution opening links or attachments
 
 
 On Thu, 5 Dec 2024, Jennifer Schmitz wrote:
 
> 
> 
>> On 17 Oct 2024, at 19:23, Richard Sandiford 
>>  wrote:
>> 
>> External email: Use caution opening links or attachments
>> 
>> 
>> Jennifer Schmitz  writes:
>>> [...]
>>> Looking at the diff of the vect dumps (below is a section of the 
>>> diff for strided_store_2.c), it seemed odd that vec_to_scalar 
>>> operations cost 0 now, instead of the previous cost of 2:
>>> 
>>> +strided_store_1.c:38:151: note:=== vectorizable_operation ===
>>> +strided_store_1.c:38:151: note:vect_model_simple_cost: 
>>> inside_cost = 1, prologue_cost  = 0 .
>>> +strided_store_1.c:38:151: note:   ==> examining statement: *_6 = 
>>> _7;
>>> +strided_store_1.c:38:151: note:   vect_is_simple_use: operand _3 + 
>>> 1.0e+0, type of def:internal
>>> +strided_store_1.c:38:151: note:   Vectorizing an unaligned access.
>>> +Applying pattern match.pd:236, generic-match-9.cc:4128
>>> +Applying pattern match.pd:5285, generic-match-10.cc:4234
>>> +strided_store_1.c:38:151: note:   vect_model_store_cost: 
>>> inside_cost = 12, prologue_cost = 0 .
>>> *_2 1 times unaligned_load (misalign -1) costs 1 in body
>>> -_3 + 1.0e+0 1 times scalar_to_vec costs 1 in prologue
>>> _3 + 1.0e+0 1 times vector_stmt costs 1 in body
>>> -_7 1 times vec_to_scalar costs 2 in body
>>> + 1 times vector_load costs 1 in prologue
>>> +_7 1 times vec_to_scalar costs 0 in body
>>> _7 1 times scalar_store costs 1 in body
>>> -_7 1 times vec_to_scalar costs 2 in body
>>> +_7 1 times vec_to_scalar costs 0 in body
>>> _7 1 times scalar_store costs 1 in body
>>> -_7 1 times vec_to_scalar costs 2 in body
>>> +_7 1 times vec_to_scalar costs 0 in body
>>> _7 1 times scalar_store costs 1 in body
>>> -_7 1 times vec_to_scalar costs 2 in body
>>> +_7 1 times vec_to_scalar costs 0 in body
>>> _7 1 times scalar_store costs 1 in body
>>> 
>>> Although the aarch64_use_new_vector_costs_p flag was used in 
>>> multiple places in aarch64.cc, the location that causes this 
>>> behavior is this one:
>>> unsigned
>>> aarch64_vector_costs::add_stmt_cost (int count, vect_cost_for_stmt 
>>> kind,
>>>   stmt_vec_info stmt_info, slp_tree,
>>>   tree vectype, int misalign,
>>>   vect_cost_model_location where)
>>> {
>>> [...]
>>> /* Try to get a more accurate cost by looking at STMT_INFO instead
>>> of just looking at KIND.  */
>>> -  if (stmt_info && aarch64_use_new_vector_costs_p ())
>>> +  if (stmt_info)
>>> {
>>> /* If we scalarize a strided store, the vectorizer costs one
>>>   vec_to_scalar for each element.  However, we can store the first
>>>   element using an FP store without a separate extract step.  */
>>> if (vect_is_store_elt_extraction (kind, stmt_info))
>>>  count -= 1;
>>> 
>>> stmt_cost = aarch64_detect_scalar_stmt_subtype (m_vinfo, kind,
>>>stmt_info, 
>>> stmt_cost);
>>> 
>>> if (vectype && m_vec_flags)
>>>  stmt_cost = aarch64_detect_vector_stmt_subtype (m_vinfo, kind,
>>>  stmt_info, vectype,
>>>  where, stmt_cost);
>>> }
>>> [...]
>>> return record_stmt_cost (stmt_info, where, (count * stmt_cost).ceil 
>>> ());
>>> }
>>> 
>>> Previously, for mtune=generic, this function returned a cost of 2 
>>> for a vec_to_scalar operation in the vect body. Now "if 
>>> (stmt_info)" is entered and "if (vect_is_store_elt_extraction 

Re: The COBOL front end, in 8 notes + toplevel patch

[Matthias Klose]

On 14.12.24 15:38, Matthias Klose wrote:
I tried to use the patches to build binary packages for Debian. Found 
some issues:


tried to build libgcobol on more architectures, please find the attached 
patch to disable building libgcobol on some architectures.


how should patches and build failures be reported at this point?

Matthias

the build currently fails on i386, armhf, s390x:

 - on i386-linux:

In file included from ../../src/gcc/cobol/ec.h:35,
 from ../../src/gcc/cobol/cdf.y:32:
../../src/gcc/cobol/symbols.h:283:23: error: enumerator value 
'4294967296' is outside the range of underlying type 'size_t' {aka 
'unsigned int'}
  283 |   depends_on_e  = 0x01, // A group hierachy 
contains a DEPENDING_ON

  |   ^~~~
../../src/gcc/cobol/symbols.h:284:23: error: enumerator value 
'8589934592' is outside the range of underlying type 'size_t' {aka 
'unsigned int'}
  284 |   initialized_e = 0x02, // Don't call 
parser_initialize from parser_symbol_add

  |   ^~~~
../../src/gcc/cobol/symbols.h:285:23: error: enumerator value 
'17179869184' is outside the range of underlying type 'size_t' {aka 
'unsigned int'}
  285 |   has_value_e   = 0x04, // Flag to hierarchical 
descendents to ignore .initial

  |   ^~~~
../../src/gcc/cobol/symbols.h:286:23: error: enumerator value 
'34359738368' is outside the range of underlying type 'size_t' {aka 
'unsigned int'}
  286 |   ieeedec_e = 0x08, // Indicates a FldFloat is 
IEEE 754 decimal, rather than binary

  |   ^~~~
../../src/gcc/cobol/symbols.h:287:23: error: enumerator value 
'68719476736' is outside the range of underlying type 'size_t' {aka 
'unsigned int'}
  287 |   big_endian_e  = 0x10, // Indicates a value is 
big-endian

  |   ^~~~
../../src/gcc/cobol/symbols.h:288:23: error: enumerator value 
'137438953472' is outside the range of underlying type 'size_t' {aka 
'unsigned int'}
  288 |   same_as_e = 0x20, // Field produced by SAME 
AS (cannot take new members)

  |   ^~~~
../../src/gcc/cobol/symbols.h:289:23: error: enumerator value 
'274877906944' is outside the range of underlying type 'size_t' {aka 
'unsigned int'}

  289 |   record_key_e  = 0x40,
  |   ^~~~
../../src/gcc/cobol/symbols.h:290:23: error: enumerator value 
'549755813888' is outside the range of underlying type 'size_t' {aka 
'unsigned int'}

  290 |   typedef_e = 0x80, // IS TYPEDEF
  |   ^~~~
In file included from ../../src/gcc/cobol/cdf.y:85,
 from cobol/cdf.c:249:
../../src/gcc/cobol/cdfval.h:80:3: error: 'cdfval_t::cdfval_t(int64_t)' 
cannot be overloaded with 'cdfval_t::cdfval_t(long long int)'

   80 |   cdfval_t( int64_t value )
  |   ^~~~


on arm-linux-gnueabihf:

In file included from ../../src/gcc/cobol/ec.h:35,
 from ../../src/gcc/cobol/cdf.y:32:
../../src/gcc/cobol/symbols.h:67:23: error: 'output' was not declared in 
this scope
   67 | static_assert( sizeof(output) == sizeof(long double), "long 
doubles?" );

  |   ^~
../../src/gcc/cobol/symbols.h:69:8: error: '_Float128' is not supported 
on this target

   69 | static inline _Float128
  |^~
../../src/gcc/cobol/symbols.h:69:15: error: expected unqualified-id 
before '_Float128'

   69 | static inline _Float128
  |   ^
../../src/gcc/cobol/symbols.h:75:29: error: expected ',' or '...' before 
'string'

   75 | strfromf128 (char *restrict string, size_t size,
  | ^~
../../src/gcc/cobol/symbols.h: In function 'int strfromf128(char*)':
../../src/gcc/cobol/symbols.h:77:20: error: 'str' was not declared in 
this scope; did you mean 'std'?

   77 |   return  strfroml(str, n, format, fp);
  |^~~
  |std
../../src/gcc/cobol/symbols.h:77:25: error: 'n' was not declared in this 
scope

   77 |   return  strfroml(str, n, format, fp);
  | ^
../../src/gcc/cobol/symbols.h:77:28: error: 'format' was not declared in 
this scope

   77 |   return  strfroml(str, n, format, fp);
  |^~
../../src/gcc/cobol/symbols.h:77:36: error: 'fp' was not declared in 
this scope

   77 |   return  strfroml(str, n, format, fp);
  |^~
../../src/gcc/cobol/symbols.h:75:20: warning: unused parameter 
'restrict' [-Wunused-parameter]

   75 | strfromf128 (char *restrict string, size_t size,
  |  ~~^~~~
../../src/gcc/cobol/symbols.h: At global scope:
../../src/gcc/cobol/symbols.h:283:23: error: enumerator value 
'4294967296' is outside the range of underlying type 'size_t' {aka 
'unsign

Re: [PING!, Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.

[Andre Vehreschild]

PING!

On Fri, 6 Dec 2024 19:10:08 +0100
Andre Vehreschild  wrote:

> Hi all,
>
> I had to dive deeply into the issue with handling allocatable components in
> derived types and to find a future proof solution. I hope do have found a
> universal and flexible one now:
>
> For each allocatable (or pointer) component in a derived type a coarray token
> is required. While this is quite easy for the current compilation unit, it is
> very difficult to do for arbitrary compilation units or when one gets
> libraries that are not aware of coarray's needs. The approach this patch now
> implements is to delegate the evaluation of a reference into a coarray into a
> separate access routine. This routine is present on every image, because it
> is generated by the compiler at the time it knows that a coarray access is
> done. With external compilation units or libraries this solves the access
> issue, because each image knows how to access its own objects, but does not
> need a coarray token for allocatable (or pointer) components anymore. The
> access on the remote image's object is done by the remote image itself (for
> the MPI implementation in a separate thread). Therefore it knows about the
> bounds of arrays, allocation and association state of components and can
> handle those.
>
> Furthermore is this approach faster, because it has O(1) complexity regarding
> the communication. The old approach was O(N) where N is the number of
> allocatable/pointer components + array descriptors on the path of the access.
> The new approach sends a set of parameters to the remote image and gets the
> desired data in return.
>
> At the moment the patch handles only getting of data from a remote image. It
> is split into two patchsets. The first one does some preparatory clean up,
> like stopping to add caf_get calls into the expression tree and removing them
> afterwards again, where they are in the way.
>
> The second patch is then doing the access routine creation. Unfortunately is
> this the longer patch. I have also updated the documentation of the caf API. I
> hope to not have overlooked something.
>
> This is the first part of a series to rework all coarray access routines to
> use the new approach and then remove the deprecated calls. This makes things
> clearer and easier to maintain, although the tree-dump now presents some more
> generated routines, which might look odd.
>
> Bootstrapped and regtested ok on x86_64-pc-linux-gnu / Fedora 39 and 41. Ok
> for mainline?
>
> I will continue working on the coarray stuff and fix upcoming bugs in the
> future.
>
> Regards,
>   Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de


--
Andre Vehreschild * Email: vehre ad gmx dot de
From 2ff66c494b1897325d3c332c773ffccf5432088d Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Fri, 6 Dec 2024 08:57:34 +0100
Subject: [PATCH 2/2] Fortran: Replace getting of coarray data with
 accessor-based version. [PR107635]

Getting coarray data from remote images was slow, inefficient and did
not work for object files that where not compiled with coarray support
for derived types with allocatable/pointer components.  The old approach
emulated accessing data through a whole structure ref, which was error
prone for corner cases.  Furthermore was did it have a runtime
complexity of O(N), where N is the number of allocatable/pointer
components and descriptors involved.  Each of those needed communication
twice.  The new approach creates a routine for each access into a
coarray object putting all required operations there.  Looking a
tree-dump one will see those small routines.  But this time it is just
compiled fortran with all the knowledge of the compiler of bounds and so
on.  New paradigms will be available out of the box.  Furthermore is the
complexity of the communication reduced to be O(1).  E.g. the mpi
implementation sends one message for the parameters of the access and
one message back with the results without caring about the number of
allocatable/pointer/descriptor components in the access.

Identification of access routines is done be adding them to a hash map,
where the hash is the same on all images.  Translating the hash to an
index, which is the same on all images again, allows for fast calls of
the access routines.  Resolving the hash to an index is cached at
runtime, preventing additional hash map lookups.  A hashmap was use
because not all processor OS combinations may use the same address for
the access routine.

gcc/fortran/ChangeLog:

	PR fortran/107635

	* gfortran.h (gfc_add_caf_accessor): New function.
	* gfortran.texi: Document new API routines.
	* resolve.cc (get_arrayspec_from_expr): Synthesize the arrayspec
	resulting from an expression, i.e. not only the rank, but also
	the bounds.
	(remove_coarray_from_derived_type): Remove coarray ref from a
	derived type to access it in access routine.
	(convert_coarray_class_to_derived_type): Same but for classes.
	The result is a derived type.
	(split_expr_at_caf_

Re: [PATCH] c++: Diagnose earlier non-static data members with cv containing class type [PR116108]

[Jason Merrill]

On 12/14/24 3:29 AM, Jakub Jelinek wrote:

Hi!

In r10-6457 aka PR92593 fix a check has been added to reject
earlier non-static data members with current_class_type in templates,
as the deduction then can result in endless recursion in reshape_init.
It fixed the
template 
struct S { S s = 1; };
S t{2};
crashes, but as the following testcase shows, didn't catch when there
are cv qualifiers on the non-static data member.

Fixed by using TYPE_MAIN_VARIANT.

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


OK.


2024-12-14  Jakub Jelinek  

PR c++/116108
gcc/cp/
* decl.cc (grokdeclarator): Pass TYYPE_MAIN_VARIANT (type)
rather than type to same_type_p when checking if the non-static
data member doesn't have current class type.
gcc/testsuite/
* g++.dg/cpp1z/class-deduction117.C: New test.

--- gcc/cp/decl.cc.jj   2024-12-11 17:27:52.484221268 +0100
+++ gcc/cp/decl.cc  2024-12-13 17:05:24.445418705 +0100
@@ -15124,7 +15124,8 @@ grokdeclarator (const cp_declarator *dec
  }
else if (!staticp
 && ((current_class_type
- && same_type_p (type, current_class_type))
+ && same_type_p (TYPE_MAIN_VARIANT (type),
+ current_class_type))
 || (!dependent_type_p (type)
 && !COMPLETE_TYPE_P (complete_type (type))
 && (!complete_or_array_type_p (type)
--- gcc/testsuite/g++.dg/cpp1z/class-deduction117.C.jj  2024-12-13 
17:17:38.493973975 +0100
+++ gcc/testsuite/g++.dg/cpp1z/class-deduction117.C 2024-12-13 
17:16:15.233158656 +0100
@@ -0,0 +1,7 @@
+// PR c++/116108
+// { dg-do compile { target c++11 } }
+template 
+struct S { const S s = 1; };   // { dg-error "field 's' has incomplete type 'const 
S'" }
+S t{2};// { dg-error "invalid use of template-name 'S' 
without an argument list" "" { target c++14_down } }
+// { dg-error "class template argument deduction failed" "" { target c++17 } 
.-1 }
+// { dg-error "no matching function for call to 'S\\\(int\\\)'" "" { target 
c++17 } .-2 }

Jakub

[PATCH] RISC-V: Remove svvptc from riscv-ext-bitmask.def

[Yangyu Chen]

There should be no svvptc in the riscv-ext-bitmask.def file since it has
not yet been added to the RISC-V C API Specification or the Linux
hwprobe. And there is no need for userspace software to know that this
extension exists. So remove it from the riscv-ext-bitmask.def file.

Fixes: e4f4b2dc08 ("RISC-V: Minimal support for svvptc extension.")
Signed-off-by: Yangyu Chen 

gcc/ChangeLog:

* common/config/riscv/riscv-ext-bitmask.def (RISCV_EXT_BITMASK): Remove 
svvptc.
---
 gcc/common/config/riscv/riscv-ext-bitmask.def | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/common/config/riscv/riscv-ext-bitmask.def 
b/gcc/common/config/riscv/riscv-ext-bitmask.def
index a733533df98..ca5df1740f3 100644
--- a/gcc/common/config/riscv/riscv-ext-bitmask.def
+++ b/gcc/common/config/riscv/riscv-ext-bitmask.def
@@ -79,6 +79,5 @@ RISCV_EXT_BITMASK ("zcd", 1,  4)
 RISCV_EXT_BITMASK ("zcf",  1,  5)
 RISCV_EXT_BITMASK ("zcmop",1,  6)
 RISCV_EXT_BITMASK ("zawrs",1,  7)
-RISCV_EXT_BITMASK ("svvptc",   1,  8)
 
 #undef RISCV_EXT_BITMASK
-- 
2.45.2

Re: [PATCH] Add fancy pointer support in std::map/set

[Jonathan Wakely]

On Sat, 14 Dec 2024 at 14:59, Jonathan Wakely  wrote:
>
>
>
> On Mon, 9 Dec 2024, 06:05 François Dumont,  wrote:
>>
>>
>> On 04/12/2024 22:48, Jonathan Wakely wrote:
>> > On 04/12/24 19:27 +0100, François Dumont wrote:
>> >> Hi
>> >>
>> >> I've completed the synchronization with your equivalent PR for
>> >> std::list so here is the updated patch.
>> >>
>> >> PR updated a couple of days ago.
>> >>
>> >> Note that I've started to rework the patch for the same in _Hashtable.
>> >
>> > Great, thanks.
>> >
>> >>
>> >> #if __cplusplus < 201103L
>> >>   void
>> >> -  _M_construct_node(_Link_type __node, const value_type& __x)
>> >> +  _M_construct_node(_Base_ptr __p, const value_type& __x)
>> >
>> > And can this be left as _Node_ptr instead of changed to _Base_ptr?
>> > Then it wouldn't need the static_cast, and the callers wouldn't need
>> > to use _M_base_ptr().
>> >
>> > Logically, it has to be a _Node_ptr or the cast isn't valid anyway.
>> >
>> > There seem to be several places like this where we're giving up
>> > valuable type information by using _base_ptr instead of _Node_ptr.
>> >
>> > Is that really necessary? If we have a _Node_ptr we can always get a
>> > _Base_ptr easily by calling _M_base_ptr().
>> >
>> > Is it a constness thing, because _M_begin() const was changed to
>> > return _Base_ptr instead of _Const_link_ptr?
>> >
>> No, just me being lazy and considering that as we store _Base_ptr we can
>> also use it everywhere.
>>
>> In this new version I've preserved _Node_ptr almost everywhere.
>>
>> But _M_begin() is still returning a _Base_ptr and I've introduced
>> _M_begin_node() for rare occasions when a _Node_ptr is needed.
>>
>> Note that I've hesitated to add a _S_nullptr() to get a _Base_ptr null
>> pointer. Is default constructor on fancy pointer type mandatory ?
>
>
> Yes, but default construction can give a singular value (like an 
> uninitialized int*) so you want to use value initialization.
>
> So:
>
> pointer p = pointer();
>
> Or in C++11:
> pointer p{};
>
> And not just:
> pointer p;
>
>
>> I fear
>> that only constructor from nullptr is mandatory.
>
>
> Value init is required to work by the Cpp17NullablePointer requirements.

See https://en.cppreference.com/w/cpp/named_req/NullablePointer for
the cppreference.com version of those requirements.


>
>
>>
>> I've forced push on:
>>
>> https://forge.sourceware.org/gcc/gcc-TEST/pulls/27
>
>
> Thanks, I'll take another look.
>
>

[pushed: r15-6286] sarif-replay: handle embedded links (§3.11.6)

[David Malcolm]

Handle embedded links in plain text messages.  For now, merely
use the link text and discard the destination.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-6286-g7f4f49687b1f1b.

gcc/ChangeLog:
* libsarifreplay.cc (struct embedded_link): New.
(maybe_consume_embedded_link): New.
(sarif_replayer::make_plain_text_within_result_message): Handle
embedded links by using the link text, for now.

gcc/testsuite/ChangeLog:
* sarif-replay.dg/2.1.0-valid/3.11.6-embedded-links.sarif: New test.
* sarif-replay.dg/2.1.0-valid/malloc-vs-local-4.c.sarif: Update
expected output for handling the embedded links.
* sarif-replay.dg/2.1.0-valid/spec-example-4.sarif: Likewise.

Signed-off-by: David Malcolm 
---
 gcc/libsarifreplay.cc | 91 ++-
 .../2.1.0-valid/3.11.6-embedded-links.sarif   | 25 +
 .../2.1.0-valid/malloc-vs-local-4.c.sarif |  5 +-
 .../2.1.0-valid/spec-example-4.sarif  |  2 +-
 4 files changed, 117 insertions(+), 6 deletions(-)
 create mode 100644 
gcc/testsuite/sarif-replay.dg/2.1.0-valid/3.11.6-embedded-links.sarif

diff --git a/gcc/libsarifreplay.cc b/gcc/libsarifreplay.cc
index f1374ec4fc80..074ea90f352b 100644
--- a/gcc/libsarifreplay.cc
+++ b/gcc/libsarifreplay.cc
@@ -1176,11 +1176,91 @@ maybe_consume_placeholder (const char *&iter_src, 
unsigned *out_arg_idx)
   return false;
 }
 
+struct embedded_link
+{
+  std::string text;
+  std::string destination;
+};
+
+/*  If ITER_SRC starts with an embedded link as per §3.11.6, advance ITER_SRC
+to immediately beyond the link, and return the link.
+
+Otherwise, leave ITER_SRC untouched and return nullptr.  */
+
+static std::unique_ptr
+maybe_consume_embedded_link (const char *&iter_src)
+{
+  if (*iter_src != '[')
+return nullptr;
+
+  /* This *might* be an embedded link.
+ See §3.11.6 ("Messages with embedded links") and
+ https://github.com/oasis-tcs/sarif-spec/issues/657 */
+
+  /* embedded link = "[", link text, "](", link destination, ")"; */
+
+  embedded_link result;
+
+  /* Try to get the link text.  */
+  const char *iter = iter_src + 1;
+  while (char ch = *(iter++))
+{
+  if (ch == '\\')
+   {
+ char next_ch = *iter;
+ switch (next_ch)
+   {
+   case '\\':
+   case '[':
+   case ']':
+ /* escaped link character = "\" | "[" | "]";  */
+ result.text += next_ch;
+ iter++;
+ continue;
+
+   default:
+ /* Malformed link text; assume this is not an
+embedded link.  */
+ return nullptr;
+   }
+   }
+  else if (ch == ']')
+   /* End of link text.  */
+   break;
+  else
+   result.text += ch;
+}
+
+  if (*iter++ != '(')
+return nullptr;
+
+  /* Try to get the link destination.  */
+  while (1)
+{
+  char ch = *(iter++);
+  if (ch == '\0')
+   {
+ /* String ended before terminating ')'.
+Assume this is not an embedded link.  */
+ return nullptr;
+   }
+  else if (ch == ')')
+   /* Terminator.  */
+   break;
+  else
+   result.destination += ch;
+}
+
+  iter_src = iter;
+  return ::make_unique (std::move (result));
+}
+
 /* Lookup the plain text string within a result.message (§3.27.11),
-   and substitute for any placeholders (§3.11.5).
+   and substitute for any placeholders (§3.11.5) and handle any
+   embedded links (§3.11.6).
 
Limitations:
-   - we don't yet support embedded links
+   - we don't preserve destinations within embedded links
 
MESSAGE_OBJ is "theMessage"
RULE_OBJ is "theRule".  */
@@ -1255,6 +1335,13 @@ make_plain_text_within_result_message (const 
json::object *tool_component_obj,
  return label_text::borrow (nullptr);
}
}
+  else if (auto link = maybe_consume_embedded_link (iter_src))
+   {
+ accum += link->text;
+ /* TODO: use the destination.  */
+ /* TODO: potentially could try to convert
+intra-sarif links into event ids.  */
+   }
   else
{
  accum += ch;
diff --git 
a/gcc/testsuite/sarif-replay.dg/2.1.0-valid/3.11.6-embedded-links.sarif 
b/gcc/testsuite/sarif-replay.dg/2.1.0-valid/3.11.6-embedded-links.sarif
new file mode 100644
index ..bc64521716c6
--- /dev/null
+++ b/gcc/testsuite/sarif-replay.dg/2.1.0-valid/3.11.6-embedded-links.sarif
@@ -0,0 +1,25 @@
+{"$schema": 
"https://docs.oasis-open.org/sarif/sarif/v2.1.0/errata01/os/schemas/sarif-schema-2.1.0.json";,
+ "version": "2.1.0",
+ "runs": [{"tool": {"driver": {"name": "hand-written"}},
+   "results": [{"message": {"text": "001: this is a test"},
+   "locations": []},
+/* { dg-begin-multiline-output "" }
+hand-written: warning: 001: this is a test
+   { dg-end-multiline-output "" } */
+
+ 

Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

[Paul-Antoine Arras]

Hi Tobias,

See the revised patch attached and my comments below.

On 15/11/2024 14:59, Tobias Burnus wrote:

Hi,

Paul-Antoine Arras wrote:

This patch adds support for the `dispatch` construct and the
`adjust_args` clause to the Fortran front-end.

Handling of `adjust_args` across translation units is missing due
to PR115271.



First, can you add a run-time test?

[I think it helps to have at least one run-time test feature for every
major feature - as we had in the past e.g. C runtime tests and Fortran
compile time tests - but it turned out that some flags was not set,
causing the middle to ignore the feature completely ...]


Added libgomp/testsuite/libgomp.fortran/dispatch-1.f90.


* * *

The following gives an ICE after printing the error (error recovery):

module m
   use iso_c_binding
   implicit none (type, external)
contains
   subroutine foo(x,y)
     !$omp declare variant(bar) match ( construct = { dispatch } )
     type(C_ptr), value :: x, y
   end
   subroutine bar(a,b)
     type(C_ptr), value :: a, b
   end
end

use m
   ! integer, target :: y, z   ! OK
   integer :: y, z  ! ERROR shown but then gives an ICE in 
resolve_omp_dispatch

   !$omp dispatch device(5)
     call foo(c_loc(y),c_loc(z))
end


Fixed error recovery in resolve_omp_dispatch and added testcase.


* * *

The following seems to be valid but gives an error:

Error: argument list item ‘y’ in ‘need_device_ptr’ at (1) must be of 
TYPE(C_PTR)


module m
   use iso_c_binding
   implicit none (type, external)
contains
   subroutine foo(x,y)
     !$omp declare variant(bar) match ( construct = { dispatch } ) 
adjust_args(nothing : x ) adjust_args(need_device_ptr : y )

     type(C_ptr), value :: x, y
   end
   subroutine bar(a,b)
     type(C_ptr), value :: a, b
   end
end

It looks as if the type check is already done during parsing instead
of later during resolve_*.


Renamed gfc_resolve_omp_declare_simd to gfc_resolve_omp_declare and 
moved type(C_ptr) check from gfc_match_omp_declare_variant to there.

Added testcase.


* * *

A duplicate-argument error is missing for 'adjust_args(nothing : x ,x )'
and also for:

module m
   use iso_c_binding
   implicit none (type, external)
contains
   subroutine foo(x,y)
     type(C_ptr), value :: x, y
     !$omp declare variant(bar) match ( construct = { dispatch } ) 
adjust_args(nothing : x ,y ) adjust_args(need_device_ptr : y )

   end
   subroutine bar(a,b)
     type(C_ptr), value :: a, b  ! OK
     ! integer :: a, b   ! wrong type - works & diagnosed (if not ICEing)
   end
end


I think you want to add a flag to 'u' in 'typedef struct 
gfc_omp_namelist' - to set whether an OMP_ LIST_ADJUST_ARGS

is a needs-pointer one or (e.g. unset) a 'nothing' one.

And then also add 'nothing' items to the list.


Added flag as suggested, renamed need_device_ptr_arg_list into 
adjust_args_list and removed nothing_arg_list.

Added testcase.


* * *

The attached testcase shows that you mishandle Fortran calling
conventions (optional, value).

It works for the host (device == -1) but with real offloading,
it segfaults.

(There might be some lang hooks inside trans-openmp* to help
with this; best that you cross check what omp-low.cc does for
'use_device_ptr'.)


Fixed handling of passed-by-reference arguments in gimplify_call_expr.
Added testcase.


* * *

TODO: We need to handle 'type(C), dimension(:)' - but I wonder
whether that shouldn't be handled as part of 'use_device_addr'
and we need to check whether the spec has to be updated.

I filed the OpenMP lang-spec Issue #4443.

* * *

Just a side - no action needed:

We discussed that 'match' is required while 'adjust_args' is
optional.

In C, we had crashes because of a missing 'match' clause;
here it works:

     7 | !$omp declare variant(bar) adjust_args(nothing : x ,x )
   |  1
Error: an ‘adjust_args’ clause at (1) can only be specified if the 
‘dispatch’ selector of the construct selector set appears in the ‘match’ 
clause


Likewise, I think the following error is fine:
     7 | !$omp declare variant(bar)
   |   1
Error: expected ‘match’ or ‘adjust_args’ at (1)


* * *

Otherwise it seems to be okay, but I need to reread it.

Thanks,

Tobias


Thanks,
--
PAcommit e02e75cc9050e42f8887ede95cee56018bc51ad2
Author: Paul-Antoine Arras 
Date:   Fri May 24 19:13:50 2024 +0200

OpenMP: Fortran front-end support for dispatch + adjust_args

This patch adds support for the `dispatch` construct and the `adjust_args`
clause to the Fortran front-end.

Handling of `adjust_args` across translation units is missing due to PR115271.

gcc/fortran/ChangeLog:

* dump-parse-tree.cc (show_omp_clauses): Handle novariants and nocontext
clauses.
(show_omp_node): Handle EXEC_OMP_DISPATCH.
(show_code_node): Likewise.
* frontend-passes.cc (gfc_code_walker): Handle novariants and nocontext.
  

Re: [PATCH 0/5] LoongArch: CRC optimization

[Jeff Law]

On 12/16/24 7:15 AM, Mariam Arutunian wrote:



On Mon, Dec 16, 2024 at 5:20 PM Xi Ruoyao  wrote:

A generic CRC optimization pass has been implemented in r15-5850.  But
without target-specific code, it'll only optimize the CRC loop to a
table lookup.  With LoongArch-specific code we can do it better: for
64-bit LoongArch and the IEEE 802.3 polynomial or the Castagnoli
polynomial, we can directly invoke the hardware instruction; even if a
hardware instruction isn't available, we can still use LoongArch bit
reversion instructions to optimize the bit reverse before looking up the
table.

Xi Ruoyao (5):
   LoongArch: Remove QHSD and use QHWD instead
   LoongArch: Add bit reverse operations
   LoongArch: Add CRC expander to generate faster CRC
   LoongArch: Combine xor and crc instructions
   LoongArch: Add crc tests

  gcc/config/loongarch/loongarch.md             | 138 +-
  gcc/testsuite/g++.target/loongarch/crc-scan.C |  13 ++
  gcc/testsuite/g++.target/loongarch/crc.C      | 113 ++
  3 files changed, 261 insertions(+), 3 deletions(-)
  create mode 100644 gcc/testsuite/g++.target/loongarch/crc-scan.C
  create mode 100644 gcc/testsuite/g++.target/loongarch/crc.C

-- 
2.47.1



Thanks for your work. It's nice to see added support for more architectures!
I’ve looked over the changes, and everything looks good to me.
If any updates are needed on my side, please let me know.
Definitely good news.  I didn't know loongarch had suitable instructions 
for this.  If I did I would have reached out to Xi earlier :-)


Jeff

[committed] i386: Add HImode to VALID_SSE2_REG_MODE

[Uros Bizjak]

Move explicit Himode handling for SSE2 XMM regnos from
ix86_hard_regno_mode_ok to VALID_SSE2_REG_MODE.

No functional change.

gcc/ChangeLog:

* config/i386/i386.cc (ix86_hard_regno_mode_ok):
Remove explicit HImode handling for SSE2 XMM regnos.
* config/i386/i386.h (VALID_SSE2_REG_MODE): Add HImode.

Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32}.

Uros.
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index ca763e1eb33..f74329a941a 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -21155,10 +21155,6 @@ ix86_hard_regno_mode_ok (unsigned int regno, 
machine_mode mode)
   if (EXT_REX_SSE_REGNO_P (regno))
return false;
 
-  /* Use pinsrw/pextrw to mov 16-bit data from/to sse to/from integer.  */
-  if (TARGET_SSE2 && mode == HImode)
-   return true;
-
   /* OImode and AVX modes are available only when AVX is enabled.  */
   return ((TARGET_AVX
   && VALID_AVX256_REG_OR_OI_MODE (mode))
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 85c54c35c5c..61bc20e1868 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -1099,7 +1099,7 @@ extern const char *host_detect_local_cpu (int argc, const 
char **argv);
|| (MODE) == V8HFmode || (MODE) == V4HFmode || (MODE) == V2HFmode   \
|| (MODE) == V8BFmode || (MODE) == V4BFmode || (MODE) == V2BFmode   \
|| (MODE) == V4QImode || (MODE) == V2HImode || (MODE) == V1SImode   \
-   || (MODE) == V2DImode || (MODE) == V2QImode \
+   || (MODE) == V2DImode || (MODE) == V2QImode || (MODE) == HImode \
|| (MODE) == DFmode || (MODE) == DImode \
|| (MODE) == HFmode || (MODE) == BFmode)
 

Re: [PATCH] wwwdocs: Clarify DCO name/identity and (anonymous) pseudonym policy

[Mark Wielaard]

On Mon, Dec 09, 2024 at 11:24:39AM +0100, Mark Wielaard wrote:
> On Mon, 2024-12-02 at 11:16 +0100, Mark Wielaard wrote:
> > Adjust the DCO text to match the broader community usage and
> > clarifications around the use of real names, known identities and
> > (anonymous) pseudonyms.
> > 
> > These changes clarify what was meant by "real name" and that it is not
> > required to be a "legal name" or any other stronger requirement than a
> > known identity that could be contacted to discuss the contribution as
> > adopted by other communities like the linux kernel, elfutils, cncf and
> > gentoo.
> > 
> > Also explain that the FSF assignment policy might be more appropriate
> > when wanting to contribute using an anonymous pseudonym.
> 
> Please let me know if these policy clarifications are OK.
> I can also update the various wikis.

Ping

> > ---
> >  htdocs/dco.html | 17 +++--
> >  1 file changed, 15 insertions(+), 2 deletions(-)
> > 
> > diff --git a/htdocs/dco.html b/htdocs/dco.html
> > index 68fa183b9fc0..5713f003cce3 100644
> > --- a/htdocs/dco.html
> > +++ b/htdocs/dco.html
> > @@ -54,8 +54,21 @@ then you just add a line saying:
> >  
> >  Signed-off-by: Random J Developer 
> > 
> >  
> > -using your real name (sorry, no pseudonyms or anonymous contributions.)  
> > This
> > -will be done for you automatically if you use `git commit -s`.
> > +using a known identity (sorry, no anonymous contributions.)  The name
> > +you use as your identity should not be an anonymous id or false name
> > +that misrepresents who you are.  This will be done for you
> > +automatically if you use `git commit -s`.
> > +
> > +A known identity can be the committer's real, birth or legal name,
> > +but can also be an established (online) identity.  It is the name you
> > +convey to people in the community for them to use to identify you as
> > +you.  The key concern is that your identification is sufficient enough
> > +to contact you if an issue were to arise in the future about your
> > +contribution.  You should not deliberately use a name or email address
> > +that hides your identity.  When you wish to only contribute under an
> > +(anonymous) pseudonym, or when you require an explicit employer
> > +disclaimer, then following the FSF
> > +assignment process is more appropriate.
> >  
> >  Some people also put extra optional tags at the end.  The GCC project 
> > does
> >  not require tags from anyone other than the original author of the patch, 
> > but
> 

Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

[Tobias Burnus]

Hi PA,

Paul-Antoine Arras wrote:

See the revised patch attached and my comments below.


First, for Fortran patches, please also CC fortran@ besides gcc-patches@.

The original patch email can be found at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671763.html

I have not looked in depth at the patch, but managed to
write C-ism code, which caused a segfault (due to a missing "call"),
after gfortran issued a reasonable error. Can you fix it
and, just to make sure, add it as another testcase?

foo.f90:18:7:

   18 |  g(a,b,c)
  |   1
Error: ‘g’ at (1) is not a variable
foo.f90:20:3:

   20 | end
  |   1
Error: Unexpected END statement at (1)

Segmentation fault

* * *

The problem seems to be that during parsing,
the location data is NULL, which the error diagnostic does not like: 
(gdb) p gfc_current_locus $33 = {nextc = 0x0, u = {lb = 0x0, location = 
0}} (gdb) p gfc_at_eof() $36 = true
and st == ST_NONE. I think the simplest is to check for the last one, 
and then return early. This will then print: foo.f90:18:7: 18 | g(a,b,c) 
| 1 Error: ‘g’ at (1) is not a variable foo.f90:20:3: 20 | end | 1 
Error: Unexpected END statement at (1) f951: Error: Unexpected end of 
file in ‘foo.f90’ When the if st is ST_NONE then return check is added: 
+static gfc_statement +parse_omp_dispatch (void) +{ ... + st = 
next_statement (); + if (st == ST_NONE) + return st; + if (st == ST_CALL 
|| st == ST_ASSIGNMENT) + accept_statement (st); + else * * * > Handling 
of `adjust_args` across translation units is missing due to PR115271. 
Namely, https://gcc.gnu.org/PR115271 is about not storing 'declare 
variant' inside module files; when repeating the decl in an interface, 
it obviously works as * * * I think the patch is now okay, but I want to 
re-read it tomorrow - thus, please hold off for a couple of ours. 
Possibly, others have comments as well :-) * * *



TODO: We need to handle 'type(C), dimension(:)' - but I wonder
whether that shouldn't be handled as part of 'use_device_addr'
and we need to check whether the spec has to be updated.

I filed the OpenMP lang-spec Issue #4443.
... and we eventually have to handle 
'need_device_addr'/'has_device_addr', but those are follow-up topics.


Thanks,

Tobias
module m
use iso_c_binding
implicit none(type,external)
contains
subroutine f(x,y,z)
  type(c_ptr) :: x,y,z
end
subroutine g(x,y,z)
  type(c_ptr) :: x,y,z
  !$omp declare variant(f) adjust_args(need_device_ptr: x,y) adjust_args(nothing : z,x) match(construct={dispatch})
end
end 

use m
implicit none(type,external)
  type(c_ptr) :: a,b,c
  !$omp dispatch
 g(a,b,c)
!call g(a,b,c)
end

Re: The COBOL front end, in 8 notes

[Joseph Myers]

On Thu, 12 Dec 2024, James K. Lowden wrote:

> A word about C style, always a lively topic.  For any files already
> present in gcc, the existing style was followed, and any variation from
> it is unintentional.  Files related to the parser use K&R style.  The
> GENERIC interface and runtime library use Whitesmiths style.  All C++
> code uses spaces for indentation.  
> 
> The COBOL front end has been and is being written by two guys with
> decades of experience.  We hope the code is a testament to that
> experience.  Our relatively recent experience, these last four years,
> is that it has been more productive to keep using the styles to which
> we've long become accustomed.  The position of curly braces is hardly
> any hindrance to read another's code, but it's a burden to write that
> way. We think, 83,068 lines later, the proof of the pudding is in the
> eating.  

Regardless of formatting - which we should be able to mostly fix using 
automated tools - I think the GNU coding style principle that every 
function has a comment above it documenting the intended semantics for the 
function (including all its arguments and the return value) is something 
important for all coding styles, and not something that can be fixed with 
automated tools.  So please make sure that every function has such a 
comment.  (If you wish to use specially formatted comments for automatic 
extraction of internal API documentation, rather than e.g. GNU conventions 
with parameters named in uppercase in the comments, that might be a 
reasonable deviation.  But regardless of how the comments are formatted, 
having the documentation of function semantics, including in particular 
the semantics of arguments and return value, is important.)

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] COBOL 8/8 bld: "meta" files, such a gcc/cobol/Make-lang.in

[Joseph Myers]

On Thu, 12 Dec 2024, James K. Lowden wrote:

> diff --git a/configure b/configure
> index 51bf1d1add1..2a8f0cadc0e 100755
> --- a/configure
> +++ b/configure
> @@ -775,6 +775,7 @@ infodir
>  docdir
>  oldincludedir
>  includedir
> +runstatedir
>  localstatedir
>  sharedstatedir
>  sysconfdir

Please make sure to do all regeneration with *unmodified* versions of the 
relevant tools, not ones with distribution changes.

> +CPPFLAGS =   \
> + -std=c++17  \
> + $(MAX_ERRORS)   \
> + -Iinclude   \
> + -I$(BINCLUDE)   \
> + -Wno-cpp\
> + -Wno-missing-field-initializers \
> + -DEXEC_LIB=\"$(DESTDIR)$(libdir)\"
> + $(END)

It's never appropriate for $(DESTDIR) to be built into any programs; it's 
a temporary staging directory used for installation (when the final 
installation will use a distribution package manager or similar) only.  
Paths built into programs should only be within $(prefix) or 
$(exec_prefix) or other configured directories that default to being based 
on those (and when one part of the compiler locates another, it needs to 
use make_relative_prefix from libiberty to handle the possibility that the 
final installed prefix is different from the configure-time one).

> +YACC = bison

Please use BISON as already set by configure in gcc/Makefile.in.  That 
allows people to override the setting at configure time.

> +LEX = flex

Likewise, use FLEX.

> +cobol.install-common: installdirs
> + $(INSTALL_PROGRAM) -v gcobol$(exeext)   \
> + $(DESTDIR)$(bindir)/$(gcobol_INSTALL_NAME)$(exeext)
> + $(INSTALL_PROGRAM) -v $(srcdir)/cobol/gcobc $(DESTDIR)$(bindir)/
> + $(INSTALL_DATA) -v $(srcdir)/cobol/udf/* $(udfdir)/

Apart from the missing definition of $(udfdir), that line is also missing 
a use of $(DESTDIR).

> +cobol.uninstall:
> + -rm -f gcobol$(exeext) cobol1$(exeext)
> + -rm -f $(cobol_OBJS)

The uninstall target should remove exactly the installed files under 
$(DESTDIR).  It shouldn't remove anything from the build directory.  In 
general it *can't* remove anything from the build directory (consider the 
case where "make uninstall" is run as root and the build directory is 
root-squashed NFS, so there is no write access to the build directory from 
"make install" or "make uninstall").

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] COBOL 2/8 par: parser

[Joseph Myers]

The parser appears to contain calls to diagnostic functions, so seems a 
good point to comment on conventions for diagnostics in GCC:

* Please send all diagnostics (except maybe internal ones that indicate a 
bug in the compiler) through the language-independent diagnostic 
machinery.  It appears you're using e.g. the  functions (glibc and 
BSD) at present.

* If you need custom diagnostic functions that wrap that machinery, please 
make sure those follow the parameter naming conventions required for 
messages to be extracted for translation; see ABOUT-GCC-NLS for details 
(and other requirements such as using complete sentences rather than 
building them up from pieces).  (Note also that if you have overloaded 
diagnostic functions with the same name, the parameter extracted for 
translation must be in the same position for all overloads.)

* Once everything is going through appropriate diagnostic machinery, 
please make sure that po/exgettext really does extract all the diagnostics 
for translation.  In particular, note that it doesn't process .y files at 
present, and it would be best not to require 
--enable-generated-files-in-srcdir for it to process a generated .c file.  
(My suggestion would be to move all the logic that generates diagnostics 
out of parser actions into separate .cc files.)

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH] COBOL 1/8 hdr: header files

[Joseph Myers]

On Thu, 12 Dec 2024, James K. Lowden wrote:

> +static char name[PATH_MAX];

Static buffers with a PATH_MAX size will probably break the build on Hurd 
host.

> +__int128  get_power_of_ten(int n);

GCC supports 32-bit hosts; you shouldn't rely on __int128 being available 
on the host.

> +extern "C" __int128 __gg__binary_value_from_qualified_field(int
> *rdigits,
> +cblc_field_t 
> *var,
> +size_t 
> offset,
> +size_t size);
> +extern "C"  _Float128 __gg__float128_from_qualified_field(cblc_field_t 
> *field,
> +  size_t offset,
> +  size_t size);

I'm not entirely sure whether this is host or target code (you always need 
to be clear about which is which in GCC), but in any case, both hosts and 
targets without __int128 or _Float128 are supported in GCC.

In general, target code - including headers - should not go under gcc/ at 
all.  And host code shouldn't be using __* identifiers as those are 
reserved.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH 0/5] LoongArch: CRC optimization

[Mariam Arutunian]

On Mon, Dec 16, 2024 at 5:20 PM Xi Ruoyao  wrote:

> A generic CRC optimization pass has been implemented in r15-5850.  But
> without target-specific code, it'll only optimize the CRC loop to a
> table lookup.  With LoongArch-specific code we can do it better: for
> 64-bit LoongArch and the IEEE 802.3 polynomial or the Castagnoli
> polynomial, we can directly invoke the hardware instruction; even if a
> hardware instruction isn't available, we can still use LoongArch bit
> reversion instructions to optimize the bit reverse before looking up the
> table.
>
> Xi Ruoyao (5):
>   LoongArch: Remove QHSD and use QHWD instead
>   LoongArch: Add bit reverse operations
>   LoongArch: Add CRC expander to generate faster CRC
>   LoongArch: Combine xor and crc instructions
>   LoongArch: Add crc tests
>
>  gcc/config/loongarch/loongarch.md | 138 +-
>  gcc/testsuite/g++.target/loongarch/crc-scan.C |  13 ++
>  gcc/testsuite/g++.target/loongarch/crc.C  | 113 ++
>  3 files changed, 261 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/testsuite/g++.target/loongarch/crc-scan.C
>  create mode 100644 gcc/testsuite/g++.target/loongarch/crc.C
>
> --
> 2.47.1
>


Thanks for your work. It's nice to see added support for more architectures!
I’ve looked over the changes, and everything looks good to me.
If any updates are needed on my side, please let me know.


BR,
Mariam

[PATCH] RISC-V: optimization on checking certain bits set ((x & mask) == val)

[Oliver Kozul]

The patch optimizes code generation for comparisons of the form
X & C1 == C2 by converting them to (X | ~C1) == (C2 | ~C1).
C1 is a constant that requires li and addi to be loaded,
while ~C1 requires a single lui instruction.
As the values of C1 and C2 are not visible within
the equality expression, a plus pattern is matched instead.

2024-12-16  Oliver Kozul  

  PR target/114087

gcc/ChangeLog:

  * config/riscv/riscv.md (*lui_constraint_and_to_or): New 
pattern

gcc/testsuite/ChangeLog:

  * gcc.target/riscv/pr114087-1.c: New test.



CONFIDENTIALITY: The contents of this e-mail are confidential and intended only 
for the above addressee(s). If you are not the intended recipient, or the 
person responsible for delivering it to the intended recipient, copying or 
delivering it to anyone else or using it in any unauthorized manner is 
prohibited and may be unlawful. If you receive this e-mail by mistake, please 
notify the sender and the systems administrator at straym...@rt-rk.com 
immediately.
---
 gcc/config/riscv/riscv.md   | 28 +
 gcc/testsuite/gcc.target/riscv/pr114087-1.c | 16 
 2 files changed, 44 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr114087-1.c

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 3a4cd1d93a0..75b0947e597 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -858,6 +858,34 @@
   [(set_attr "type" "arith")
(set_attr "mode" "SI")])
 
+;; Transform (X & C1) + C2 into (X | ~C1) - (-C2 | ~C1)
+;; Where C1 is not a LUI operand, but ~C1 is a LUI operand
+
+(define_insn_and_split "*lui_constraint_and_to_or"
+   [(set (match_operand:ANYI 0 "register_operand" "=r")
+   (plus:ANYI (and:ANYI (match_operand:ANYI 1 "register_operand" "r")
+(match_operand 2 "const_int_operand"))
+(match_operand 3 "const_int_operand")))
+   (clobber (match_scratch:X 4 "=&r"))]
+  "LUI_OPERAND (~INTVAL (operands[2]))
+   && ((INTVAL (operands[2]) & (-INTVAL (operands[3])))
+   == (-INTVAL (operands[3])))
+   && riscv_const_insns (operands[3], false)
+   && (riscv_const_insns
+   (GEN_INT (~INTVAL (operands[2]) | -INTVAL (operands[3])), false)
+   <= riscv_const_insns (operands[3], false))"
+  "#"
+  "&& reload_completed"
+  [(set (match_dup 4) (match_dup 5))
+   (set (match_dup 0) (ior:X (match_dup 1) (match_dup 4)))
+   (set (match_dup 4) (match_dup 6))
+   (set (match_dup 0) (minus:X (match_dup 0) (match_dup 4)))]
+  {
+operands[5] = GEN_INT (~INTVAL (operands[2]));
+operands[6] = GEN_INT ((~INTVAL (operands[2])) | (-INTVAL (operands[3])));
+  }
+  [(set_attr "type" "arith")])
+
 ;;
 ;;  
 ;;
diff --git a/gcc/testsuite/gcc.target/riscv/pr114087-1.c 
b/gcc/testsuite/gcc.target/riscv/pr114087-1.c
new file mode 100644
index 000..9df02db6d5d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/pr114087-1.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target rv64 } */
+/* { dg-skip-if "" { *-*-* } { "-O0" "-O1" "-Og" } } */
+/* { dg-options "-march=rv64gc -mabi=lp64d" } */
+
+#include 
+#include 
+
+static uint32_t mask1 = 0x5FFF;
+static uint32_t val1  = 0x14501DEF;
+
+bool pred1a(uint32_t x) {
+  return ((x & mask1) == val1);
+}
+
+/* { dg-final { scan-assembler  {or\s*[a-x0-9]+,\s*[a-x0-9]+,\s*[a-x0-9]+} } } 
*/
-- 
2.43.0

[PATCH 1/5] LoongArch: Remove QHSD and use QHWD instead

[Xi Ruoyao]

QHSD and QHWD are basically the same thing, but QHSD will be incorrect
when we start to add LA32 support.  So it's just better to always use
QHWD.

gcc/ChangeLog:

* config/loongarch/loongarch.md (QHSD): Remove.
(loongarch__w__w): Use QHSD instead of QHWD.
(loongarch__w__w_extended): Likewise.
---
 gcc/config/loongarch/loongarch.md | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index a65cc1de2d2..bf322240271 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -4345,13 +4345,12 @@ (define_peephole2
 
 
 
-(define_mode_iterator QHSD [QI HI SI DI])
 (define_int_iterator CRC [UNSPEC_CRC UNSPEC_CRCC])
 (define_int_attr crc [(UNSPEC_CRC "crc") (UNSPEC_CRCC "crcc")])
 
 (define_insn "loongarch__w__w"
   [(set (match_operand:SI 0 "register_operand" "=r")
-   (unspec:SI [(match_operand:QHSD 1 "register_operand" "r")
+   (unspec:SI [(match_operand:QHWD 1 "register_operand" "r")
   (match_operand:SI 2 "register_operand" "r")]
 CRC))]
   ""
@@ -4362,7 +4361,7 @@ (define_insn "loongarch__w__w"
 (define_insn "loongarch__w__w_extended"
   [(set (match_operand:DI 0 "register_operand" "=r")
(sign_extend:DI
- (unspec:SI [(match_operand:QHSD 1 "register_operand" "r")
+ (unspec:SI [(match_operand:QHWD 1 "register_operand" "r")
  (match_operand:SI 2 "register_operand" "r")]
 CRC)))]
   "TARGET_64BIT"
-- 
2.47.1

[PATCH 5/5] LoongArch: Add crc tests

[Xi Ruoyao]

gcc/testsuite/ChangeLog:

* g++.target/loongarch/crc.C: New test.
* g++.target/loongarch/crc-scan.C: New test.
---
 gcc/testsuite/g++.target/loongarch/crc-scan.C |  13 ++
 gcc/testsuite/g++.target/loongarch/crc.C  | 113 ++
 2 files changed, 126 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/loongarch/crc-scan.C
 create mode 100644 gcc/testsuite/g++.target/loongarch/crc.C

diff --git a/gcc/testsuite/g++.target/loongarch/crc-scan.C 
b/gcc/testsuite/g++.target/loongarch/crc-scan.C
new file mode 100644
index 000..971580f0d03
--- /dev/null
+++ b/gcc/testsuite/g++.target/loongarch/crc-scan.C
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -march=loongarch64" } */
+
+#include "crc.C"
+
+/* { dg-final { scan-assembler-times "crc\\.w\\.b\\.w" 2 } } */
+/* { dg-final { scan-assembler-times "crc\\.w\\.h\\.w" 2 } } */
+/* { dg-final { scan-assembler-times "crc\\.w\\.w\\.w" 2 } } */
+/* { dg-final { scan-assembler-times "crcc\\.w\\.b\\.w" 2 } } */
+/* { dg-final { scan-assembler-times "crcc\\.w\\.h\\.w" 2 } } */
+/* { dg-final { scan-assembler-times "crcc\\.w\\.w\\.w" 2 } } */
+/* { dg-final { scan-assembler-not 
"crc\\.w\\.\[bhw\]\\.w\t\\\$r\[0-9\]+,\\\$r0" } } */
+/* { dg-final { scan-assembler-not 
"crcc\\.w\\.\[bhw\]\\.w\t\\\$r\[0-9\]+,\\\$r0" } } */
diff --git a/gcc/testsuite/g++.target/loongarch/crc.C 
b/gcc/testsuite/g++.target/loongarch/crc.C
new file mode 100644
index 000..b96b8d7e21a
--- /dev/null
+++ b/gcc/testsuite/g++.target/loongarch/crc.C
@@ -0,0 +1,113 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+typedef __UINT8_TYPE__ uint8_t;
+typedef __UINT16_TYPE__ uint16_t;
+typedef __UINT32_TYPE__ uint32_t;
+typedef __UINT64_TYPE__ uint64_t;
+typedef __SIZE_TYPE__ size_t;
+
+template  __attribute__ ((always_inline))
+inline uint32_t
+crc32_impl (const T *data, size_t len)
+{
+  uint32_t ret = 0xu;
+  for (size_t k = 0; k < len; k++)
+{
+  ret ^= data[k];
+  for (int i = 0; i < 8 * sizeof (T); i++)
+   if (ret & 1)
+ ret = (ret >> 1) ^ poly;
+   else
+ ret >>= 1;
+}
+  return ret;
+}
+
+template  __attribute__ ((noipa, optimize (0)))
+uint32_t
+crc32_ref (const T *data, size_t len)
+{
+  return crc32_impl (data, len);
+}
+
+template  __attribute__ ((noipa))
+uint32_t
+crc32_opt (const T *data, size_t len)
+{
+  return crc32_impl (data, len);
+}
+
+template  __attribute__ ((noipa))
+uint32_t
+crc32_alt (const T *data, size_t len)
+{
+  uint32_t ret = 0xu;
+  for (size_t k = 0; k < len; k++)
+{
+  T x = data[k];
+  for (int i = 0; i < 8 * sizeof (T); i++)
+   {
+ if ((ret & 1) ^ (x & 1))
+   ret = (ret >> 1) ^ poly;
+ else
+   ret >>= 1;
+ x >>= 1;
+   }
+}
+  return ret;
+}
+
+union test_data_t
+{
+  uint8_t u8[1024];
+  uint16_t u16[512];
+  uint32_t u32[256];
+
+  operator const uint8_t *() const { return u8; }
+  operator const uint16_t *() const { return u16; }
+  operator const uint32_t *() const { return u32; }
+
+  constexpr test_data_t() : u8{} {}
+};
+
+/* Generate test data at compile time with minstd_rand0 algorithm.  */
+constexpr test_data_t gen(uint64_t seed)
+{
+  uint64_t state = seed;
+  test_data_t ret;
+  for (int i = 0; i < sizeof (ret); i++)
+{
+  state = state * 16807 % 2147483647;
+  ret.u8[i] = (uint8_t) state;
+}
+  return ret;
+}
+
+constexpr union test_data_t test_data = gen (0xdeadbeef);
+
+void assert_eq (uint32_t x, uint32_t y)
+{
+  if (x != y)
+__builtin_trap ();
+}
+
+template  void
+test_crc32 ()
+{
+  constexpr size_t len = sizeof (test_data) / sizeof (T);
+  uint32_t ref = crc32_ref (test_data, len);
+  assert_eq (ref, crc32_opt (test_data, len));
+  assert_eq (ref, crc32_alt (test_data, len));
+}
+
+int
+main (void)
+{
+  test_crc32 ();
+  test_crc32 ();
+  test_crc32 ();
+  test_crc32 ();
+  test_crc32 ();
+  test_crc32 ();
+}
-- 
2.47.1

Re: [PATCH] vect: Do not try to duplicate_and_interleave one-element mode.

[Robin Dapp]

> How about going for a slight variation of your original patch.  After:
>
>   nvectors *= 2;
>
> add:
>
>   /* We need to be able to to fuse COUNT / NVECTORS elements together.  */
>   if (!multple_p (count, nvectors))
> return false;
>
> OK like that if it works.

Thank you, it works like that (bootstrapped and regtested on x86, aarch64 and
power10).  Going to commit in the next hours.

-- 
Regards
 Robin

Re: [PATCH] mtd: spi-nor: winbond: add w25q01jv flash chip

[David Malcolm]

On Mon, 2024-12-16 at 11:26 +, Wilken Gottwalt wrote:
> Add Winbond W25Q01JV 128 MiB SPI NOR flash chip, verified working on
> the
> Zynq-7000 platform QSPI controller. The flash chip has quite high
> read
> speeds (about 60+ MiB/s), but erasing is very slow. The slow erasing
> is
> by design.
> 
> Signed-off-by: Wilken Gottwalt 
> ---
>  drivers/mtd/spi-nor/winbond.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
Did you mean to send this to gcc-patches@gcc.gnu.org?  This appears to
be a patch for the kernel.

Dave

[PATCH] RISC-V: Support for zilsd and zclsd extensions.

[Dongyan Chen]

This patch support zilsd and zclsd[1] extensions.
To enable GCC to recognize and process zilsd and zclsd extension correctly at 
compile time.

[1] https://github.com/riscv/riscv-zilsd

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc 
(riscv_subset_list::check_conflict_ext): New extension.
* common/config/riscv/riscv-ext-bitmask.def (RISCV_EXT_BITMASK): Ditto.
* config/riscv/riscv.opt: Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/arch-45.c: New test.
* gcc.target/riscv/arch-46.c: New test.
* gcc.target/riscv/arch-47.c: New test.

---
 gcc/common/config/riscv/riscv-common.cc   | 17 +
 gcc/common/config/riscv/riscv-ext-bitmask.def |  2 ++
 gcc/config/riscv/riscv.opt|  4 
 gcc/testsuite/gcc.target/riscv/arch-45.c  |  5 +
 gcc/testsuite/gcc.target/riscv/arch-46.c  |  6 ++
 gcc/testsuite/gcc.target/riscv/arch-47.c  |  5 +
 6 files changed, 39 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-45.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-46.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-47.c

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index 4c9a72d1180a..eb999b322c78 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -111,6 +111,10 @@ static const riscv_implied_info_t riscv_implied_info[] =
   {"zfinx", "zicsr"},
   {"zdinx", "zicsr"},
 
+  {"zclsd", "zilsd"},
+  {"zilsd", "zicsr"},
+  {"zclsd", "zicsr"},
+
   {"zk", "zkn"},
   {"zk", "zkr"},
   {"zk", "zkt"},
@@ -331,6 +335,9 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
   {"zicntr", ISA_SPEC_CLASS_NONE, 2, 0},
   {"zihpm",  ISA_SPEC_CLASS_NONE, 2, 0},
 
+  {"zilsd",  ISA_SPEC_CLASS_NONE, 1, 0},
+  {"zclsd",  ISA_SPEC_CLASS_NONE, 1, 0},
+
   {"zk",ISA_SPEC_CLASS_NONE, 1, 0},
   {"zkn",   ISA_SPEC_CLASS_NONE, 1, 0},
   {"zks",   ISA_SPEC_CLASS_NONE, 1, 0},
@@ -1301,6 +1308,14 @@ riscv_subset_list::check_conflict_ext ()
   if (lookup ("zcf") && m_xlen == 64)
 error_at (m_loc, "%<-march=%s%>: zcf extension supports in rv32 only",
  m_arch);
+  
+  if (lookup ("zilsd") && m_xlen == 64)
+error_at (m_loc, "%<-march=%s%>: zilsd extension supports in rv32 only",
+ m_arch);
+
+  if (lookup ("zclsd") && m_xlen == 64)
+error_at (m_loc, "%<-march=%s%>: zclsd extension supports in rv32 only",
+ m_arch);
 
   if (lookup ("zfinx") && lookup ("f"))
 error_at (m_loc,
@@ -1641,6 +1656,7 @@ static const riscv_ext_flag_table_t 
riscv_ext_flag_table[] =
   RISCV_EXT_FLAG_ENTRY ("ziccif",  x_riscv_zi_subext, MASK_ZICCIF),
   RISCV_EXT_FLAG_ENTRY ("zicclsm", x_riscv_zi_subext, MASK_ZICCLSM),
   RISCV_EXT_FLAG_ENTRY ("ziccrse", x_riscv_zi_subext, MASK_ZICCRSE),
+  RISCV_EXT_FLAG_ENTRY ("zilsd",   x_riscv_zi_subext, MASK_ZILSD),
 
   RISCV_EXT_FLAG_ENTRY ("zicboz", x_riscv_zicmo_subext, MASK_ZICBOZ),
   RISCV_EXT_FLAG_ENTRY ("zicbom", x_riscv_zicmo_subext, MASK_ZICBOM),
@@ -1721,6 +1737,7 @@ static const riscv_ext_flag_table_t 
riscv_ext_flag_table[] =
   RISCV_EXT_FLAG_ENTRY ("zcd",  x_riscv_zc_subext, MASK_ZCD),
   RISCV_EXT_FLAG_ENTRY ("zcmp", x_riscv_zc_subext, MASK_ZCMP),
   RISCV_EXT_FLAG_ENTRY ("zcmt", x_riscv_zc_subext, MASK_ZCMT),
+  RISCV_EXT_FLAG_ENTRY ("zclsd", x_riscv_zc_subext, MASK_ZCLSD),
 
   RISCV_EXT_FLAG_ENTRY ("svinval", x_riscv_sv_subext, MASK_SVINVAL),
   RISCV_EXT_FLAG_ENTRY ("svnapot", x_riscv_sv_subext, MASK_SVNAPOT),
diff --git a/gcc/common/config/riscv/riscv-ext-bitmask.def 
b/gcc/common/config/riscv/riscv-ext-bitmask.def
index a733533df98e..af3ea47162b9 100644
--- a/gcc/common/config/riscv/riscv-ext-bitmask.def
+++ b/gcc/common/config/riscv/riscv-ext-bitmask.def
@@ -80,5 +80,7 @@ RISCV_EXT_BITMASK ("zcf", 1,  5)
 RISCV_EXT_BITMASK ("zcmop",1,  6)
 RISCV_EXT_BITMASK ("zawrs",1,  7)
 RISCV_EXT_BITMASK ("svvptc",   1,  8)
+RISCV_EXT_BITMASK ("zilsd",1,  9)
+RISCV_EXT_BITMASK ("zclsd",1,  10)
 
 #undef RISCV_EXT_BITMASK
diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
index a6a61a83db1b..f2891ea65e38 100644
--- a/gcc/config/riscv/riscv.opt
+++ b/gcc/config/riscv/riscv.opt
@@ -253,6 +253,8 @@ Mask(ZICCLSM) Var(riscv_zi_subext)
 
 Mask(ZICCRSE) Var(riscv_zi_subext)
 
+Mask(ZILSD)   Var(riscv_zi_subext)
+
 TargetVariable
 int riscv_za_subext
 
@@ -457,6 +459,8 @@ Mask(ZCMP) Var(riscv_zc_subext)
 
 Mask(ZCMT) Var(riscv_zc_subext)
 
+Mask(ZCLSD) Var(riscv_zc_subext)
+
 Mask(XCVBI) Var(riscv_xcv_subext)
 
 TargetVariable
diff --git a/gcc/testsuite/gcc.target/riscv/arch-45.c 
b/gcc/testsuite/gcc.target/riscv/arch-45.c
new file mode 100644
index ..2c2598202714
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/arch-45.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv32

Re: [PATCH] driver: -fhardened and -z lazy/-z norelro [PR117739]

[Marek Polacek]

On Tue, Dec 10, 2024 at 08:42:50PM +, Dimitri John Ledkov wrote:
> On Thu, 28 Nov 2024 at 15:12, Marek Polacek  wrote:
> >
> > On Thu, Nov 28, 2024 at 11:27:32AM +, Dimitri John Ledkov wrote:
> > > Did bootstrap with gcc-14 (clean cherrypick, minor offsets).
> > > Built and tested on arm64 & x86_64.
> > > It resolved the reported problem.
> > > Thank you for this patch.
> >
> > Thanks a lot for testing it!
> 
> Is this awaiting code-review from other developers still?

Yes.
 
> Anything else I can test to help with the review of this code?

I don't think so.  Thanks again for testing it!

> >
> > > On Tue, 26 Nov 2024, 22:37 Marek Polacek,  wrote:
> > >
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > >
> > > > -- >8 --
> > > > As the manual states, using "-fhardened -fstack-protector" will produce
> > > > a warning because -fhardened wants to enable -fstack-protector-strong,
> > > > but it can't since it's been overriden by the weaker -fstack-protector.
> > > >
> > > > -fhardened also attempts to enable -Wl,-z,relro,-z,now.  By the same
> > > > logic as above, "-fhardened -z norelro" or "-fhardened -z lazy" should
> > > > produce the same warning.  But we don't detect this combination, so
> > > > this patch fixes it.  I also renamed a variable to better reflect its
> > > > purpose.
> > > >
> > > > Also don't check warn_hardened in process_command, since it's always
> > > > true there.
> > > >
> > > > Also tweak wording in the manual as Jon Wakely suggested on IRC.
> > > >
> > > > PR driver/117739
> > > >
> > > > gcc/ChangeLog:
> > > >
> > > > * doc/invoke.texi: Tweak wording for -Whardened.
> > > > * gcc.cc (driver_handle_option): If -z lazy or -z norelro was
> > > > specified, don't enable linker hardening.
> > > > (process_command): Don't check warn_hardened.
> > > >
> > > > gcc/testsuite/ChangeLog:
> > > >
> > > > * c-c++-common/fhardened-16.c: New test.
> > > > * c-c++-common/fhardened-17.c: New test.
> > > > * c-c++-common/fhardened-18.c: New test.
> > > > * c-c++-common/fhardened-19.c: New test.
> > > > * c-c++-common/fhardened-20.c: New test.
> > > > * c-c++-common/fhardened-21.c: New test.
> > > > ---
> > > >  gcc/doc/invoke.texi   |  4 ++--
> > > >  gcc/gcc.cc| 20 ++--
> > > >  gcc/testsuite/c-c++-common/fhardened-16.c |  5 +
> > > >  gcc/testsuite/c-c++-common/fhardened-17.c |  5 +
> > > >  gcc/testsuite/c-c++-common/fhardened-18.c |  5 +
> > > >  gcc/testsuite/c-c++-common/fhardened-19.c |  5 +
> > > >  gcc/testsuite/c-c++-common/fhardened-20.c |  5 +
> > > >  gcc/testsuite/c-c++-common/fhardened-21.c |  5 +
> > > >  8 files changed, 46 insertions(+), 8 deletions(-)
> > > >  create mode 100644 gcc/testsuite/c-c++-common/fhardened-16.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/fhardened-17.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/fhardened-18.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/fhardened-19.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/fhardened-20.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/fhardened-21.c
> > > >
> > > > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > > > index 346ac1369b8..371f723539c 100644
> > > > --- a/gcc/doc/invoke.texi
> > > > +++ b/gcc/doc/invoke.texi
> > > > @@ -7012,8 +7012,8 @@ This warning is enabled by @option{-Wall}.
> > > >  Warn when @option{-fhardened} did not enable an option from its set 
> > > > (for
> > > >  which see @option{-fhardened}).  For instance, using 
> > > > @option{-fhardened}
> > > >  and @option{-fstack-protector} at the same time on the command line 
> > > > causes
> > > > -@option{-Whardened} to warn because @option{-fstack-protector-strong} 
> > > > is
> > > > -not enabled by @option{-fhardened}.
> > > > +@option{-Whardened} to warn because @option{-fstack-protector-strong} 
> > > > will
> > > > +not be enabled by @option{-fhardened}.
> > > >
> > > >  This warning is enabled by default and has effect only when
> > > > @option{-fhardened}
> > > >  is enabled.
> > > > diff --git a/gcc/gcc.cc b/gcc/gcc.cc
> > > > index 92c92996401..d2718d263bb 100644
> > > > --- a/gcc/gcc.cc
> > > > +++ b/gcc/gcc.cc
> > > > @@ -305,9 +305,10 @@ static size_t dumpdir_length = 0;
> > > > driver added to dumpdir after dumpbase or linker output name.  */
> > > >  static bool dumpdir_trailing_dash_added = false;
> > > >
> > > > -/* True if -r, -shared, -pie, or -no-pie were specified on the command
> > > > -   line.  */
> > > > -static bool any_link_options_p;
> > > > +/* True if -r, -shared, -pie, -no-pie, -z lazy, or -z norelro were
> > > > +   specified on the command line, and therefore -fhardened should not
> > > > +   add -z now/relro.  */
> > > > +static bool avoid_linker_hardening_p;
> > > >
> > > >  /* True if -static was specified on the command line.  */
> 

[PATCH] c and c++: Make sure LHS and RHS has identical named types [PR116060]

[Torbjörn SVENSSON]

Hi,

I've reg-tested this patch on both the trunk and the releases/gcc-14
branches for x86_64-linux-gnu and arm-none-eabi and it no longer fails
for any of the out-of-bounds-diagram* tests on any of the 2 platforms.

I'm a bit puzzled if the C++ part is enough, but I can't think of a way
to trigger anything that show the wrong output after my change.
Do you think that I need to add any additional tests? I think the
existing test covers the problem well enough.

Ok for trunk and releases/gcc-14?

--

gcc/ChangeLog:

PR c/116060
c/c-typeck.cc: Make sure left hand side and right hand side has
identical named types to aid diagnostic output.
cp/call.cc: Likewise.

gcc/testsuite/ChangeLog:

PR c/116060
c-c++-common/analyzer/out-of-bounds-diagram-8.c: Update to
correct type.
c-c++-common/analyzer/out-of-bounds-diagram-11.c: Likewise.
gcc.dg/analyzer/out-of-bounds-diagram-10.c: Likewise.

Signed-off-by: Torbjörn SVENSSON 
---
 gcc/c/c-typeck.cc |  3 ++
 gcc/cp/call.cc|  9 ++
 .../analyzer/out-of-bounds-diagram-11.c   | 28 +--
 .../analyzer/out-of-bounds-diagram-8.c| 28 +--
 .../analyzer/out-of-bounds-diagram-10.c   | 28 +--
 5 files changed, 54 insertions(+), 42 deletions(-)

diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 902898d1944..e3e85d1ecde 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -7831,6 +7831,9 @@ convert_for_assignment (location_t location, location_t 
expr_loc, tree type,
   if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (rhstype))
 {
   warn_for_address_of_packed_member (type, orig_rhs);
+  if (type != rhstype)
+   /* Convert RHS to TYPE in order to not loose TYPE in diagnostics.  */
+   rhs = convert (type, rhs);
   return rhs;
 }
 
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index c8420db568e..d859ce9a2d6 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -1319,6 +1319,9 @@ standard_conversion (tree to, tree from, tree expr, bool 
c_cast_p,
 {
   if (CLASS_TYPE_P (to) && conv->kind == ck_rvalue)
conv->type = qualified_to;
+  else if (from != to)
+   /* Use TO in order to not loose TO in diagnostics.  */
+   conv->type = to;
   return conv;
 }
 
@@ -8741,6 +8744,12 @@ convert_like_internal (conversion *convs, tree expr, 
tree fn, int argnum,
   continue to warn about uses of EXPR as an integer, rather than as a
   pointer.  */
expr = build_int_cst (totype, 0);
+  if (TREE_CODE (expr) == NON_LVALUE_EXPR && TREE_TYPE (expr) != totype)
+   {
+ /* Use TOTYPE in order to not loose TOTYPE in diagnostics.  */
+  expr = copy_node (expr);
+  TREE_TYPE (expr) = totype;
+   }
   return expr;
 case ck_ambig:
   /* We leave bad_p off ck_ambig because overload resolution considers
diff --git a/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c 
b/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c
index 63ae08347aa..048a1b9698f 100644
--- a/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c
+++ b/gcc/testsuite/c-c++-common/analyzer/out-of-bounds-diagram-11.c
@@ -47,20 +47,20 @@ void test7 (size_t size)
 
 /* { dg-begin-multiline-output "" }
 
- ┌───┐
- │  write of '(int) 42'  │
- └───┘
-   │   │
-   │   │
-   v   v
-  ┌──┐┌──┐
-  │ buffer allocated on stack at (1) ││after valid range │
-  └──┘└──┘
-  ├┬─┤├┬─┤
-   │   │
-  ╭┴───╮ ╭─┴╮
-  │capacity: '(size * 4) + 3' bytes│ │overflow of 1 byte│
-  ╰╯ ╰──╯
+┌┐
+│write of '(int32_t) 42' │
+└┘
+ │ │
+ │ │
+ v v
+  ┌┐ ┌───┐
+  │buffer allocated on stack at (1)│ │ after valid range │
+  └──

Re: [PATCH] mtd: spi-nor: winbond: add w25q01jv flash chip

[Pratyush Yadav]

Hi Wilken,

On Mon, Dec 16 2024, Wilken Gottwalt wrote:

> Add Winbond W25Q01JV 128 MiB SPI NOR flash chip, verified working on the
> Zynq-7000 platform QSPI controller. The flash chip has quite high read
> speeds (about 60+ MiB/s), but erasing is very slow. The slow erasing is
> by design.

Does the flash have support SFDP? If so, you likely don't need specify
the no_sfdp_flags, name, or size. Try the entry only with ID and flags,
and see if the flash continues to work fine for you.

Also see [0] for additional testing requirements.

[0] https://docs.kernel.org/driver-api/mtd/spi-nor.html

>
> Signed-off-by: Wilken Gottwalt 
> ---
>  drivers/mtd/spi-nor/winbond.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c
> index 8d0a00d69e12..e2caf299d19a 100644
> --- a/drivers/mtd/spi-nor/winbond.c
> +++ b/drivers/mtd/spi-nor/winbond.c
> @@ -146,6 +146,12 @@ static const struct flash_info winbond_nor_parts[] = {
>   .name = "w25q512jvq",
>   .size = SZ_64M,
>   .no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | 
> SPI_NOR_QUAD_READ,
> + }, {
> + .id = SNOR_ID(0xef, 0x40, 0x21),
> + .name = "w25q01jv",
> + .size = SZ_128M,
> + .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB,
> + .no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | 
> SPI_NOR_QUAD_READ,
>   }, {
>   .id = SNOR_ID(0xef, 0x50, 0x12),
>   .name = "w25q20bw",

-- 
Regards,
Pratyush Yadav

Re: [Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.

[Damian Rouson]

This is a big deal, Andre!   Thanks for working on this patch.  I have some
test code that I can dig up if that’s helpful.  Have you tested with nested
derived type components, i.e., allocatable components that are themselves
derived types that have allocatable components?

The need for this feature in one of my projects is one of two things that
led me to prioritize other compilers at the end of 2023.  At the time, the
other missing feature was automatic parallelization of `do concurrent`,
including automatic GPU offloading.  Then a few months ago, the death blow
that I couldn’t work around was robust support for kind type parameters.

D


Damian

On Fri, Dec 6, 2024 at 10:13 Andre Vehreschild  wrote:

> Hi all,
>
> I had to dive deeply into the issue with handling allocatable components in
> derived types and to find a future proof solution. I hope do have found a
> universal and flexible one now:
>
> For each allocatable (or pointer) component in a derived type a coarray
> token
> is required. While this is quite easy for the current compilation unit, it
> is
> very difficult to do for arbitrary compilation units or when one gets
> libraries
> that are not aware of coarray's needs. The approach this patch now
> implements
> is to delegate the evaluation of a reference into a coarray into a separate
> access routine. This routine is present on every image, because it is
> generated
> by the compiler at the time it knows that a coarray access is done. With
> external compilation units or libraries this solves the access issue,
> because
> each image knows how to access its own objects, but does not need a coarray
> token for allocatable (or pointer) components anymore. The access on the
> remote
> image's object is done by the remote image itself (for the MPI
> implementation in
> a separate thread). Therefore it knows about the bounds of arrays,
> allocation
> and association state of components and can handle those.
>
> Furthermore is this approach faster, because it has O(1) complexity
> regarding
> the communication. The old approach was O(N) where N is the number of
> allocatable/pointer components + array descriptors on the path of the
> access.
> The new approach sends a set of parameters to the remote image and gets the
> desired data in return.
>
> At the moment the patch handles only getting of data from a remote image.
> It is
> split into two patchsets. The first one does some preparatory clean up,
> like
> stopping to add caf_get calls into the expression tree and removing them
> afterwards again, where they are in the way.
>
> The second patch is then doing the access routine creation. Unfortunately
> is
> this the longer patch. I have also updated the documentation of the caf
> API. I
> hope to not have overlooked something.
>
> This is the first part of a series to rework all coarray access routines
> to use
> the new approach and then remove the deprecated calls. This makes things
> clearer and easier to maintain, although the tree-dump now presents some
> more
> generated routines, which might look odd.
>
> Bootstrapped and regtested ok on x86_64-pc-linux-gnu / Fedora 39 and 41.
> Ok for
> mainline?
>
> I will continue working on the coarray stuff and fix upcoming bugs in the
> future.
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>

[PATCH 0/5] LoongArch: CRC optimization

[Xi Ruoyao]

A generic CRC optimization pass has been implemented in r15-5850.  But
without target-specific code, it'll only optimize the CRC loop to a
table lookup.  With LoongArch-specific code we can do it better: for
64-bit LoongArch and the IEEE 802.3 polynomial or the Castagnoli
polynomial, we can directly invoke the hardware instruction; even if a
hardware instruction isn't available, we can still use LoongArch bit
reversion instructions to optimize the bit reverse before looking up the
table.

Xi Ruoyao (5):
  LoongArch: Remove QHSD and use QHWD instead
  LoongArch: Add bit reverse operations
  LoongArch: Add CRC expander to generate faster CRC
  LoongArch: Combine xor and crc instructions
  LoongArch: Add crc tests

 gcc/config/loongarch/loongarch.md | 138 +-
 gcc/testsuite/g++.target/loongarch/crc-scan.C |  13 ++
 gcc/testsuite/g++.target/loongarch/crc.C  | 113 ++
 3 files changed, 261 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.target/loongarch/crc-scan.C
 create mode 100644 gcc/testsuite/g++.target/loongarch/crc.C

-- 
2.47.1

[PATCH 4/5] LoongArch: Combine xor and crc instructions

[Xi Ruoyao]

For a textbook-style CRC implementation:

uint32_t crc = 0xu;
for (size_t k = 0; k < len; k++)
  {
crc ^= data[k];
for (int i = 0; i < 8 * sizeof (T); i++)
  if (crc & 1)
crc = (crc >> 1) ^ poly;
  else
crc >>= 1;
  }
return crc;

The generic code reports:

Data and CRC are xor-ed before for loop.  Initializing data with 0.

resulting in:

ld.bu $t1, $a0, 0
xor   $t0, $t0, $t1
crc.w.b.w $t0, $zero, $t0

But it's just better to use

ld.bu $t1, $a0, 0
crc.w.b.w $t0, $t1, $t0

instead.  Implement this optimization now.

gcc/ChangeLog:

* config/loongarch/loongarch.md (*crc_combine): New
define_insn_and_split.
---
 gcc/config/loongarch/loongarch.md | 25 +
 1 file changed, 25 insertions(+)

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index 806b0ec0be9..7a110ca9de6 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -4477,6 +4477,31 @@ (define_expand "crc_revsi4"
 DONE;
   })
 
+(define_insn_and_split "*crc_combine"
+  [(set (match_operand:SI 0 "register_operand" "=r,r")
+   (unspec:SI
+ [(reg:SUBDI 0)
+  (subreg:SI
+(xor:DI
+  (match_operand:DI 1 "register_operand" "r,r")
+  ; Our LOAD_EXTEND_OP makes this same as sign_extend
+  ; if SUBDI is SI, or zero_extend if SUBDI is QI or HI.
+  ; For the former the high bits in rk are ignored by
+  ; crc.w.w.w anyway, for the latter the zero extension is
+  ; necessary for the correctness of this transformation.
+  (subreg:DI
+(match_operand:SUBDI 2 "memory_operand" "m,k") 0)) 0)]
+ CRC))]
+  "TARGET_64BIT && loongarch_pre_reload_split ()"
+  "#"
+  "&& true"
+  [(set (match_dup 3) (match_dup 2))
+   (set (match_dup 0)
+   (unspec:SI [(match_dup 3) (subreg:SI (match_dup 1) 0)] CRC))]
+  {
+operands[3] = gen_reg_rtx (mode);
+  })
+
 ;; With normal or medium code models, if the only use of a pc-relative
 ;; address is for loading or storing a value, then relying on linker
 ;; relaxation is not better than emitting the machine instruction directly.
-- 
2.47.1

[PATCH 3/5] LoongArch: Add CRC expander to generate faster CRC

[Xi Ruoyao]

64-bit LoongArch has native CRC instructions for two specific
polynomials.  For other polynomials or 32-bit, use the generic
table-based approach but optimize bit reversing.

gcc/ChangeLog:

* config/loongarch/loongarch.md (crc_revsi4): New
define_expand.
---
 gcc/config/loongarch/loongarch.md | 57 +++
 1 file changed, 57 insertions(+)

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index fe1678c5891..806b0ec0be9 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -4420,6 +4420,63 @@ (define_insn "loongarch__w__w_extended"
   [(set_attr "type" "unknown")
(set_attr "mode" "")])
 
+(define_expand "crc_revsi4"
+  [(match_operand:SI   0 "register_operand")   ; new_chksum
+   (match_operand:SI   1 "register_operand")   ; old_chksum
+   (match_operand:SUBDI2 "reg_or_0_operand")   ; msg
+   (match_operand  3 "const_int_operand")] ; poly
+  ""
+  {
+unsigned HOST_WIDE_INT poly = UINTVAL (operands[3]);
+rtx msg = operands[2];
+rtx (*crc_insn)(rtx, rtx, rtx) = nullptr;
+
+/* TODO: Review this when adding LA32 support.  If we're going to
+   support CRC instructions on LA32 we'll need a "-mcrc" switch as
+   they are optional on LA32.  */
+
+if (TARGET_64BIT)
+  {
+   if (poly == reflect_hwi (0xedb88320u, 32))
+ crc_insn = gen_loongarch_crc_w__w;
+   else if (poly == reflect_hwi (0x82f63b78u, 32))
+ crc_insn = gen_loongarch_crcc_w__w;
+  }
+
+if (crc_insn)
+  {
+   /* We cannot make crc_insn to accept const0_rtx easily:
+  it's not possible to figure out the mode of const0_rtx so we'd
+  have to separate both UNSPEC_CRC and UNSPEC_CRCC to 4 different
+  UNSPECs.  Instead just hack it around here.  */
+   if (msg == const0_rtx)
+ msg = gen_rtx_REG (mode, 0);
+
+   emit_insn (crc_insn (operands[0], msg, operands[1]));
+  }
+else
+  {
+   /* No CRC instruction is suitable, use the generic table-based
+  implementation but optimize bit reversion.  */
+   auto rbit = [](rtx *r)
+ {
+   /* Well, this is ugly.  The problem is
+  expand_reversed_crc_table_based only accepts one helper
+  for reversing data elements and CRC states.  */
+   auto mode = GET_MODE (*r);
+   auto rbit = (mode == mode ? gen_rbit : gen_rbitsi);
+   rtx out = gen_reg_rtx (mode);
+
+   emit_insn (rbit (out, *r));
+   *r = out;
+ };
+   expand_reversed_crc_table_based (operands[0], operands[1],
+msg, operands[3], mode,
+rbit);
+  }
+DONE;
+  })
+
 ;; With normal or medium code models, if the only use of a pc-relative
 ;; address is for loading or storing a value, then relying on linker
 ;; relaxation is not better than emitting the machine instruction directly.
-- 
2.47.1

[PATCH 2/5] LoongArch: Add bit reverse operations

[Xi Ruoyao]

LoongArch supports native bit reverse operation for QI, SI, DI, and for
HI we can expand it into a shift and a bit reverse in word_mode.

I was reluctant to add them because until PR50481 is fixed these
operations will be just useless.  But now it turns out we can use them
to optimize the bit reversing CRC calculation if recognized by the
generic CRC pass.  So add them in prepare for the next patch adding CRC
expanders.

gcc/ChangeLog:

* config/loongarch/loongarch.md (@rbit): New
define_insn template.
(rbitsi_extended): New define_insn.
(rbitqi): New define_insn.
(rbithi): New define_expand.
---
 gcc/config/loongarch/loongarch.md | 51 +++
 1 file changed, 51 insertions(+)

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index bf322240271..fe1678c5891 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -4239,6 +4239,57 @@ (define_insn "bitrev_8b"
   [(set_attr "type" "unknown")
(set_attr "mode" "DI")])
 
+(define_insn "@rbit"
+  [(set (match_operand:GPR 0 "register_operand" "=r")
+   (bitreverse:GPR (match_operand:GPR 1 "register_operand" "r")))]
+  ""
+  "bitrev.\t%0,%1"
+  [(set_attr "type" "unknown")
+   (set_attr "mode" "")])
+
+(define_insn "rbitsi_extended"
+  [(set (match_operand:DI 0 "register_operand" "=r")
+   (sign_extend:DI
+ (bitreverse:SI (match_operand:SI 1 "register_operand" "r"]
+  "TARGET_64BIT"
+  "bitrev.w\t%0,%1"
+  [(set_attr "type" "unknown")
+   (set_attr "mode" "SI")])
+
+;; If we don't care high bits, bitrev.4b can reverse bits of values in
+;; QImode.
+(define_insn "rbitqi"
+  [(set (match_operand:QI 0 "register_operand" "=r")
+   (bitreverse:QI (match_operand:QI 1 "register_operand" "r")))]
+  ""
+  "bitrev.4b\t%0,%1"
+  [(set_attr "type" "unknown")
+   (set_attr "mode" "SI")])
+
+;; For HImode it's a little complicated...
+(define_expand "rbithi"
+  [(match_operand:HI 0 "register_operand")
+   (match_operand:HI 1 "register_operand")]
+  ""
+  {
+rtx t = gen_reg_rtx (word_mode);
+
+/* Oh, using paradoxical subreg.  I learnt the trick from RISC-V,
+   hoping we won't be blown up altogether one day.  */
+emit_insn (gen_rbit(word_mode, t,
+   gen_lowpart (word_mode, operands[1])));
+t = expand_simple_binop (word_mode, LSHIFTRT, t,
+GEN_INT (GET_MODE_BITSIZE (word_mode) - 16),
+NULL_RTX, false, OPTAB_DIRECT);
+
+t = gen_lowpart (HImode, t);
+SUBREG_PROMOTED_VAR_P (t) = 1;
+SUBREG_PROMOTED_SET (t, SRP_UNSIGNED);
+emit_move_insn (operands[0], t);
+
+DONE;
+  })
+
 (define_insn "@stack_tie"
   [(set (mem:BLK (scratch))
(unspec:BLK [(match_operand:X 0 "register_operand" "r")
-- 
2.47.1

Re: [PATCH 1/4] libstdc++: Further simplify _Hashtable inheritance hierarchy

[Jonathan Wakely]

I've pushed this patch series now, and I hope I'm done with
refactoring _Hashtable.

I see about a 2% reduction in memory and in compilation time for an
explicit instantiation of std::unordered_list when
comparing r15-5031-gdd08cdccc36d08 to current trunk. It's not huge,
but it's something, and I find the code easier to understand now.


On Fri, 13 Dec 2024 at 23:07, Jonathan Wakely  wrote:
>
> The main change here is using [[no_unique_address]] instead of the Empty
> Base-class Optimization. Using the attribute allows us to use data
> members instead of base-classes. That simplifies the inheritance
> hierarchy, which means less work for the compiler. It also means that
> ADL has fewer associated classes and associated namespaces to consider,
> further reducing the work the compiler has to do.
>
> Reducing the differences between the _Hashtable_ebo_helper primary
> template and the partial specialization means we no longer need to use
> member functions to access the stored object, because it's now always a
> data member called _M_obj.  This means we can also remove a number of
> other helper functions that were using those member functions to access
> the object, for example we can swap the _Hash and _Equal objects
> directly in _Hashtable::swap instead of calling _Hashtable_base::_M_swap
> which then calls _Hash_code_base::_M_swap.
>
> Although [[no_unique_address]] would allow us to reduce the size for
> empty types that are also 'final', doing so would be an ABI break
> because those types were previously excluded from using the EBO. So we
> still need the _Hashtable_ebo_helper class template and a partial
> specialization, so that we only use the attribute under exactly the same
> conditions as we previously used the EBO. This could be avoided with a
> non-standard [[no_unique_address(expr)]] attribute that took a boolean
> condition, or with reflection and token sequence injection, but we don't
> have either of those things.
>
> Because _Hashtable_ebo_helper is no longer used as a base-class we don't
> need to disambiguate possible identical bases, so it doesn't need an
> integral non-type template parameter.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/hashtable.h (_Hashtable::swap): Swap hash
> function and equality predicate here. Inline allocator swap
> instead of using __alloc_on_swap.
> * include/bits/hashtable_policy.h (_Hashtable_ebo_helper):
> Replace EBO with no_unique_address attribute. Remove NTTP.
> (_Hash_code_base): Replace base class with data member using
> no_unique_address attribute.
> (_Hash_code_base::_M_swap): Remove.
> (_Hash_code_base::_M_hash): Remove.
> (_Hashtable_base): Replace base class with data member using
> no_unique_address attribute.
> (_Hashtable_base::_M_swap): Remove.
> (_Hashtable_alloc): Replace base class with data member using
> no_unique_address attribute.
> ---
>
> Tested x86_64-linux.
>
>  libstdc++-v3/include/bits/hashtable.h|  16 ++-
>  libstdc++-v3/include/bits/hashtable_policy.h | 126 +--
>  2 files changed, 42 insertions(+), 100 deletions(-)
>
> diff --git a/libstdc++-v3/include/bits/hashtable.h 
> b/libstdc++-v3/include/bits/hashtable.h
> index b8bd8c2f418..2dc24985d58 100644
> --- a/libstdc++-v3/include/bits/hashtable.h
> +++ b/libstdc++-v3/include/bits/hashtable.h
> @@ -1829,12 +1829,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  noexcept(__and_<__is_nothrow_swappable<_Hash>,
> __is_nothrow_swappable<_Equal>>::value)
>  {
> -  // The only base class with member variables is hash_code_base.
> -  // We define _Hash_code_base::_M_swap because different
> -  // specializations have different members.
> -  this->_M_swap(__x);
> +  using std::swap;
> +  swap(__hash_code_base::_M_hash._M_obj,
> +  __x.__hash_code_base::_M_hash._M_obj);
> +  swap(__hashtable_base::_M_equal._M_obj,
> +  __x.__hashtable_base::_M_equal._M_obj);
> +
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wc++17-extensions" // if constexpr
> +  if constexpr (__node_alloc_traits::propagate_on_container_swap::value)
> +   swap(this->_M_node_allocator(), __x._M_node_allocator());
> +#pragma GCC diagnostic pop
>
> -  std::__alloc_on_swap(this->_M_node_allocator(), 
> __x._M_node_allocator());
>std::swap(_M_rehash_policy, __x._M_rehash_policy);
>
>// Deal properly with potentially moved instances.
> diff --git a/libstdc++-v3/include/bits/hashtable_policy.h 
> b/libstdc++-v3/include/bits/hashtable_policy.h
> index 6769399bd4d..8b3b7ba2682 100644
> --- a/libstdc++-v3/include/bits/hashtable_policy.h
> +++ b/libstdc++-v3/include/bits/hashtable_policy.h
> @@ -1015,46 +1015,24 @@ namespace __detail
>/**
> *  Primary class template _Hashtable_ebo_helper.
> *
> -   *  Helper class using EBO when it is not forbidden (the type is not
> 

Re: [Fortran, Patch, PR117347, v2] Fix array constructor not resolved in associate

[Andre Vehreschild]

Hi Harald,

thanks for finding the bug so quickly. I took another look and came up with the
attached trivially looking patch, which replaces the old version 1 entirely.

The new v2 version of the patch just makes use of existing code guessing the
type of the associate variable, which once I found it worked surprisingly
well. I have also extended the testcase.

Regtests ok on x86_64-pc-linux-gnu. Ok for mainline?

Regards,
Andre

On Fri, 13 Dec 2024 14:09:25 +0100
Harald Anlauf  wrote:

> Hi Andre,
>
> while the patch works with the reduced testcase, it runs into the
> newly added gcc_assert() when trying the original testcase in the PR.
>
> I also wonder if this use of gcc_assert() is a good idea or good style:
>
> +  gcc_assert (gfc_resolve_expr (tgt_expr));
>
> Since gcc_assert is a macro, and its precise definition depends on
> configuration and could possibly be defined to be a no-op, I suggest
> to evaluate arguments with side-effects outside and pass the
> return code to gcc_assert.  (There are also many other ways to handle
> this situation.
>
> Then removing the gcc_assert around the gfc_resolve_expr() avoids
> the ICE, but restores the reported error.
>
> So not OK yet.  Sorry!
>
> Thanks,
> Harald
>
>
> Am 13.12.24 um 10:10 schrieb Andre Vehreschild:
> > Hi all,
> >
> > attached patch fixes an reject-valid of an array constructor in an
> > associate by resolving the array constructor before parsing the
> > associate-block. I am not 100% sure, if that is the right place to do this.
> > But given, that there is already a special casing before the patch, I just
> > propose to do the resolve there.
> >
> > Regstests ok on x86_64-pc-linux-gnu / F41. Ok for mainline ?
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>


--
Andre Vehreschild * Email: vehre ad gmx dot de
From eaec9ce7c3241b4a8ca915b5d4987e2c51a98e7c Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Fri, 13 Dec 2024 09:06:11 +0100
Subject: [PATCH] Fortran: Fix associate with derived type array construtor
 [PR117347]

gcc/fortran/ChangeLog:

	PR fortran/117347

	* primary.cc (gfc_match_varspec): Add array constructors for
	guessing their type like with unresolved function calls.

gcc/testsuite/ChangeLog:

	* gfortran.dg/associate_71.f90: New test.
---
 gcc/fortran/primary.cc |  1 +
 gcc/testsuite/gfortran.dg/associate_71.f90 | 39 ++
 2 files changed, 40 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/associate_71.f90

diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 1db27929eeb..ab49eac450f 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -2423,6 +2423,7 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, bool sub_flag,
 	 component name 're' or 'im' could be found.  */
   if (tgt_expr
 	  && (tgt_expr->expr_type == EXPR_FUNCTION
+	  || tgt_expr->expr_type == EXPR_ARRAY
 	  || (!resolved && tgt_expr->expr_type == EXPR_OP))
 	  && (sym->ts.type == BT_UNKNOWN
 	  || (inferred_type && sym->ts.type != BT_COMPLEX))
diff --git a/gcc/testsuite/gfortran.dg/associate_71.f90 b/gcc/testsuite/gfortran.dg/associate_71.f90
new file mode 100644
index 000..8f67b53180e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/associate_71.f90
@@ -0,0 +1,39 @@
+! { dg-do run }
+!
+! Check that pr117347 is fixed.
+! Contributed by Ivan Pribec  
+
+program pr117347
+  implicit none
+
+  type :: point
+ real :: x = 42.
+  end type point
+
+  type(point) :: mypoint
+  real:: pi(1)
+  associate (points =>  mypoint )
+pi(:) = points% x
+  end associate
+  if (any(pi /= 42)) stop 1
+  associate (points => (mypoint))
+pi(:) = points% x
+  end associate
+  if (any(pi /= 42)) stop 2
+  associate (points => [mypoint])
+pi(:) = points% x
+  end associate
+  if (any(pi /= 42)) stop 3
+  associate (points => [rpoint()])
+pi(:) = points% x
+  end associate
+  if (any(pi /= 35)) stop 4
+
+contains
+
+  function rpoint() result(r)
+type(point) :: r
+r%x = 35
+  end function
+end program
+
--
2.47.1

Re: [PATCH 1/4] libstdc++: Further simplify _Hashtable inheritance hierarchy

[Jonathan Wakely]

On Mon, 16 Dec 2024 at 14:26, Jonathan Wakely  wrote:
>
> I've pushed this patch series now, and I hope I'm done with
> refactoring _Hashtable.
>
> I see about a 2% reduction in memory and in compilation time for an
> explicit instantiation of std::unordered_list when

For a translation unit that does:

template class std::unordered_set;
template class std::unordered_set;
template class std::unordered_map;
template class std::unordered_map;

I see a bigger improvement for -O2, between 5% and 10%, with fewer
entries (and shorter entries) in the compiler's string pool.

> comparing r15-5031-gdd08cdccc36d08 to current trunk. It's not huge,
> but it's something, and I find the code easier to understand now.

[committed] testsuite: Require int32plus target for gcc.dg/pr117816.c

[Dimitar Dimitrov]

Memmove destination overflows if size of int is less than 3, resulting in
spurious test failures.  Fix by adding a requirement for effective
target int32plus.

This fixes a new FAIL for AVR backend.  Pushed to trunk as obvious.

gcc/testsuite/ChangeLog:

* gcc.dg/pr117816.c: Require effective target int32plus.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.dg/pr117816.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/pr117816.c b/gcc/testsuite/gcc.dg/pr117816.c
index 6a9fc5fa141..bd37a5bb0e1 100644
--- a/gcc/testsuite/gcc.dg/pr117816.c
+++ b/gcc/testsuite/gcc.dg/pr117816.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { int32plus } } } */
 /* { dg-options "-O -fnon-call-exceptions -favoid-store-forwarding 
-fno-forward-propagate -finstrument-functions" } */
 
 char *p;
-- 
2.47.1

Re: [PATCH] RISC-V: Support for zilsd and zclsd extensions.

[Kito Cheng]

On Mon, Dec 16, 2024 at 10:58 PM Dongyan Chen
 wrote:
>
> This patch support zilsd and zclsd[1] extensions.
> To enable GCC to recognize and process zilsd and zclsd extension correctly at 
> compile time.
>
> [1] https://github.com/riscv/riscv-zilsd
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc 
> (riscv_subset_list::check_conflict_ext): New extension.
> * common/config/riscv/riscv-ext-bitmask.def (RISCV_EXT_BITMASK): 
> Ditto.
> * config/riscv/riscv.opt: Ditto.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/arch-45.c: New test.
> * gcc.target/riscv/arch-46.c: New test.
> * gcc.target/riscv/arch-47.c: New test.
>
> ---
>  gcc/common/config/riscv/riscv-common.cc   | 17 +
>  gcc/common/config/riscv/riscv-ext-bitmask.def |  2 ++
>  gcc/config/riscv/riscv.opt|  4 
>  gcc/testsuite/gcc.target/riscv/arch-45.c  |  5 +
>  gcc/testsuite/gcc.target/riscv/arch-46.c  |  6 ++
>  gcc/testsuite/gcc.target/riscv/arch-47.c  |  5 +
>  6 files changed, 39 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/arch-45.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/arch-46.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/arch-47.c
>
> diff --git a/gcc/common/config/riscv/riscv-common.cc 
> b/gcc/common/config/riscv/riscv-common.cc
> index 4c9a72d1180a..eb999b322c78 100644
> --- a/gcc/common/config/riscv/riscv-common.cc
> +++ b/gcc/common/config/riscv/riscv-common.cc
> @@ -111,6 +111,10 @@ static const riscv_implied_info_t riscv_implied_info[] =
>{"zfinx", "zicsr"},
>{"zdinx", "zicsr"},
>
> +  {"zclsd", "zilsd"},
> +  {"zilsd", "zicsr"},
> +  {"zclsd", "zicsr"},
> +
>{"zk", "zkn"},
>{"zk", "zkr"},
>{"zk", "zkt"},
> @@ -331,6 +335,9 @@ static const struct riscv_ext_version 
> riscv_ext_version_table[] =
>{"zicntr", ISA_SPEC_CLASS_NONE, 2, 0},
>{"zihpm",  ISA_SPEC_CLASS_NONE, 2, 0},
>
> +  {"zilsd",  ISA_SPEC_CLASS_NONE, 1, 0},
> +  {"zclsd",  ISA_SPEC_CLASS_NONE, 1, 0},
> +
>{"zk",ISA_SPEC_CLASS_NONE, 1, 0},
>{"zkn",   ISA_SPEC_CLASS_NONE, 1, 0},
>{"zks",   ISA_SPEC_CLASS_NONE, 1, 0},
> @@ -1301,6 +1308,14 @@ riscv_subset_list::check_conflict_ext ()
>if (lookup ("zcf") && m_xlen == 64)
>  error_at (m_loc, "%<-march=%s%>: zcf extension supports in rv32 only",
>   m_arch);
> +
> +  if (lookup ("zilsd") && m_xlen == 64)
> +error_at (m_loc, "%<-march=%s%>: zilsd extension supports in rv32 only",
> + m_arch);
> +
> +  if (lookup ("zclsd") && m_xlen == 64)
> +error_at (m_loc, "%<-march=%s%>: zclsd extension supports in rv32 only",
> + m_arch);
>
>if (lookup ("zfinx") && lookup ("f"))
>  error_at (m_loc,
> @@ -1641,6 +1656,7 @@ static const riscv_ext_flag_table_t 
> riscv_ext_flag_table[] =
>RISCV_EXT_FLAG_ENTRY ("ziccif",  x_riscv_zi_subext, MASK_ZICCIF),
>RISCV_EXT_FLAG_ENTRY ("zicclsm", x_riscv_zi_subext, MASK_ZICCLSM),
>RISCV_EXT_FLAG_ENTRY ("ziccrse", x_riscv_zi_subext, MASK_ZICCRSE),
> +  RISCV_EXT_FLAG_ENTRY ("zilsd",   x_riscv_zi_subext, MASK_ZILSD),
>
>RISCV_EXT_FLAG_ENTRY ("zicboz", x_riscv_zicmo_subext, MASK_ZICBOZ),
>RISCV_EXT_FLAG_ENTRY ("zicbom", x_riscv_zicmo_subext, MASK_ZICBOM),
> @@ -1721,6 +1737,7 @@ static const riscv_ext_flag_table_t 
> riscv_ext_flag_table[] =
>RISCV_EXT_FLAG_ENTRY ("zcd",  x_riscv_zc_subext, MASK_ZCD),
>RISCV_EXT_FLAG_ENTRY ("zcmp", x_riscv_zc_subext, MASK_ZCMP),
>RISCV_EXT_FLAG_ENTRY ("zcmt", x_riscv_zc_subext, MASK_ZCMT),
> +  RISCV_EXT_FLAG_ENTRY ("zclsd", x_riscv_zc_subext, MASK_ZCLSD),
>
>RISCV_EXT_FLAG_ENTRY ("svinval", x_riscv_sv_subext, MASK_SVINVAL),
>RISCV_EXT_FLAG_ENTRY ("svnapot", x_riscv_sv_subext, MASK_SVNAPOT),
> diff --git a/gcc/common/config/riscv/riscv-ext-bitmask.def 
> b/gcc/common/config/riscv/riscv-ext-bitmask.def
> index a733533df98e..af3ea47162b9 100644
> --- a/gcc/common/config/riscv/riscv-ext-bitmask.def
> +++ b/gcc/common/config/riscv/riscv-ext-bitmask.def
> @@ -80,5 +80,7 @@ RISCV_EXT_BITMASK ("zcf", 1,  5)
>  RISCV_EXT_BITMASK ("zcmop",1,  6)
>  RISCV_EXT_BITMASK ("zawrs",1,  7)
>  RISCV_EXT_BITMASK ("svvptc",   1,  8)
> +RISCV_EXT_BITMASK ("zilsd",1,  9)
> +RISCV_EXT_BITMASK ("zclsd",1,  10)

This file should only touched when it added to either linux hwprobe
and/or riscv-c-api

>
>  #undef RISCV_EXT_BITMASK
> diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
> index a6a61a83db1b..f2891ea65e38 100644
> --- a/gcc/config/riscv/riscv.opt
> +++ b/gcc/config/riscv/riscv.opt
> @@ -253,6 +253,8 @@ Mask(ZICCLSM) Var(riscv_zi_subext)
>
>  Mask(ZICCRSE) Var(riscv_zi_subext)
>
> +Mask(ZILSD)   Var(riscv_zi_subext)
> +
>  TargetVariable
>  int riscv_za_subext
>
> @@ -457,6 +459,8 @@ Mask(ZCMP) Var(riscv_zc_subext)
>
>  Mask(ZCMT) Var(riscv_zc_subext)
>
> +Mask(ZCLSD

Re: [PATCH] libstdc++: Move std::basic_ostream to new internal header

[Jonathan Wakely]

On Fri, 13 Dec 2024 at 13:45, Jonathan Wakely  wrote:
>
> This adds  so that other headers don't need to include
> all of , which pulls in all of  since C++23 (for the
> std::print and std::println overloads in ). This new header
> allows the constrained operator<< in  to be defined
> without all of std::format being compiled.
>
> We could also replace  with  in all of
> , , , and . That seems more
> likely to cause problems for users who might be expecting  to
> define std::endl, for example. Although the standard doesn't guarantee
> that, it is more reasonable than expecting  to define it! We can
> look into making those changes for GCC 16.
>
> libstdc++-v3/ChangeLog:
>
> * include/Makefile.am: Add new header.
> * include/Makefile.in: Regenerate.
> * include/bits/unique_ptr.h: Include bits/ostream.h instead of
> ostream.
> * include/std/ostream: Include new header.
> * include/bits/ostream.h: New file.
> ---
>
> Tested x86_64-linux. Any objections?
>
>  libstdc++-v3/include/Makefile.am   |   1 +
>  libstdc++-v3/include/Makefile.in   |   1 +
>  libstdc++-v3/include/bits/ostream.h| 817 +
>  libstdc++-v3/include/bits/unique_ptr.h |   2 +-
>  libstdc++-v3/include/std/ostream   | 763 +--
>  5 files changed, 821 insertions(+), 763 deletions(-)
>  create mode 100644 libstdc++-v3/include/bits/ostream.h
>
> diff --git a/libstdc++-v3/include/Makefile.am 
> b/libstdc++-v3/include/Makefile.am
> index 6efd3cd5f1c..07f3f027c82 100644
> --- a/libstdc++-v3/include/Makefile.am
> +++ b/libstdc++-v3/include/Makefile.am
> @@ -135,6 +135,7 @@ bits_freestanding = \
> ${bits_srcdir}/memoryfwd.h \
> ${bits_srcdir}/monostate.h \
> ${bits_srcdir}/move.h \
> +   ${bits_srcdir}/ostream.h \
> ${bits_srcdir}/out_ptr.h \
> ${bits_srcdir}/predefined_ops.h \
> ${bits_srcdir}/parse_numbers.h \
> diff --git a/libstdc++-v3/include/Makefile.in 
> b/libstdc++-v3/include/Makefile.in
> index 3b5f93ce185..25fc5a27a2b 100644
> --- a/libstdc++-v3/include/Makefile.in
> +++ b/libstdc++-v3/include/Makefile.in
> @@ -490,6 +490,7 @@ bits_freestanding = \
> ${bits_srcdir}/memoryfwd.h \
> ${bits_srcdir}/monostate.h \
> ${bits_srcdir}/move.h \
> +   ${bits_srcdir}/ostream.h \
> ${bits_srcdir}/out_ptr.h \
> ${bits_srcdir}/predefined_ops.h \
> ${bits_srcdir}/parse_numbers.h \
> diff --git a/libstdc++-v3/include/bits/ostream.h 
> b/libstdc++-v3/include/bits/ostream.h
> new file mode 100644
> index 000..b63b8dc51aa
> --- /dev/null
> +++ b/libstdc++-v3/include/bits/ostream.h
> @@ -0,0 +1,817 @@
> +// Output streams -*- C++ -*-
> +
> +// Copyright (C) 1997-2024 Free Software Foundation, Inc.
> +//
> +// This file is part of the GNU ISO C++ Library.  This library 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.
> +
> +// This library 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
> +// .
> +
> +/** @file bits/ostream.h
> + *  This is an internal header file, included by other library headers.
> + *  Do not attempt to use it directly. @headername{ostream}
> + */
> +
> +//
> +// ISO C++ 14882: 27.6.2  Output streams
> +//
> +
> +#ifndef _GLIBCXX_OSTREAM_H
> +#define _GLIBCXX_OSTREAM_H 1
> +
> +#ifdef _GLIBCXX_SYSHDR
> +#pragma GCC system_header
> +#endif
> +
> +#include  // iostreams
> +
> +#include 
> +#include 
> +#if __cplusplus > 202002L
> +# include 

It might help if I didn't copy&paste this include into the new header,
given that avoiding  is a large part of the rationale for this
change in the first place.

With that fixed, including  in an empty C++23 TU produces
37kloc, compared to 55kloc before (as counted by the cloc utility).

[Patch] OpenMP: Add declare variant's 'append_args' clause in C/C++

[Tobias Burnus]

This rather contained OpenMP patch does:

* 'interop' clause - some fixes (-Wunused),

* ICE fix related to omp_interop_t type check.

* Handle 'append_args' in C/C++ (depends on recently added
  'dispatch' and utilizes the existing 'init' clause parser
  of 'omp interop').

* Update gimplify for append_args - for a special case, actual
  code gen happens, replacing a sorry; it also prepares for the
  fully support. Currently, it requires dispatch with 'interop'
  clause (otherwise: libgomp call required) and the 'device'
  clause (requires call to existing routine; still to decide how
  to add a new 'enum' value: hidden, as ompx_gnu_ (+ name?) or
  as new 6.1 official enum? - otherwise: trivial).

* Improve clause error diagnostic with declare_variant.

* Cleanup of 'dispatch' handling in gimplify_call_expr

Thus, in total: less 'sorry', prep for real code, better diagnostic
(for existing code and being less patchy), and one ICE fix.

Comments, remarks, suggestions?

Tobias

PS: For C, to get full interop support, two middle-end sorry calls have to be
replaced by simple libgomp calls (the one in here and the one for 'interop'
itself). For C++, some *_device_addr fixes are required, once I understand how
it is best done (standard support vs. legacy case handling); for Fortran, some
smaller parser additions are required, once 'omp dispatch' is in (revised patch
expected this week).

PPS: OpenMP 5.0/5.1 support is rather complete (except for OMPT/OMPD). For 5.0,
mainly 'metadirectives' is required, but also the second part of Fortran deep
mapping of allocatable components and declare mapper. (All have posted patches.)
For 5.1, 'begin/end declare_variant' and some mapping updates (strided update,
iterator) are missing (patches exist), plus remaining bits of interop and a few
minor issues (features, corner cases and bugs).
OpenMP: Add declare variant's 'append_args' clause in C/C++

Add the append_args clause of 'declare variant' to C and C++,
fix/improve diagnostic for 'interop' clause and 'declare_variant'
clauses on the way.

Cleanup dispatch handling in gimplify_call_expr a bit and
partially handle 'append_args'. (Namely, those parts that
do not require libraries calls, i.e. a dispatch construct
where the 'device' and 'interop' clause has been specified.)

The sorry can be removed once an enum value like
  omp_ipr_(ompx_gnu_)omp_device_num (cf. OpenMP Spec Issue 4451)
has to be added to the runtime side such that omp_get_interop_int
returns the device number of an interop object (as passed to
dispatch via the interop clause); and a call to GOMP_interop
has to be added to create interop objects. Once available, only
a very localized change in gimplify_call_expr is required to
claim for full support. - And Fortran parsing support.

gcc/c-family/ChangeLog:

	* c-omp.cc (c_omp_interop_t_p): Handle error_mark_node.

gcc/c/ChangeLog:

	* c-parser.cc (c_parser_omp_clause_init_modifiers): New;
	split of from ...
	(c_parser_omp_clause_init): ... here; call it.
	(c_finish_omp_declare_variant): Parse 'append_args' clause.
	(c_parser_omp_clause_interop): Set tree used/read.

gcc/cp/ChangeLog:

	* decl.cc (omp_declare_variant_finalize_one): Handle
	append_args.
	* parser.cc (cp_parser_omp_clause_init_modifiers): New;
	split of from ...
	(cp_parser_omp_clause_init):  ... here; call it.
	(cp_parser_omp_all_clauses): Replace interop parsing by
	a call to ...
	(cp_parser_omp_clause_interop): ... this new function;
	set tree used/read.
	(cp_finish_omp_declare_variant): Parse 'append_args' clause.
	(cp_parser_omp_declare): Update comment.
	* pt.cc (tsubst_attribute, tsubst_omp_clauses): Handle template
	substitution also for declare variant's append_args clause,
	using for 'init' the same code as for interop's init clause.

gcc/ChangeLog:

	* gimplify.cc (gimplify_call_expr): Update for OpenMP's
	append_args; cleanup of OpenMP's dispatch clause handling.

gcc/testsuite/ChangeLog:

	* c-c++-common/gomp/declare-variant-2.c: Update dg-error msg.
	* c-c++-common/gomp/dispatch-12.c: Likewise.
	* c-c++-common/gomp/dispatch-11.c: Likewise and extend a bit.
	* c-c++-common/gomp/append-args-1.c: New test.
	* c-c++-common/gomp/append-args-2.c: New test.
	* c-c++-common/gomp/append-args-3.c: New test.
	* g++.dg/gomp/append-args-1.C: New test.
	* g++.dg/gomp/append-args-2.C: New test.
	* g++.dg/gomp/append-args-3.C: New test.

 gcc/c-family/c-omp.cc  |   2 +
 gcc/c/c-parser.cc  | 397 +++--
 gcc/cp/decl.cc |  86 -
 gcc/cp/parser.cc   | 287 ++-
 gcc/cp/pt.cc   |  11 +-
 gcc/gimplify.cc| 162 +++--
 gcc/testsuite/c-c++-common/gomp/append-args-1.c|  85 +
 gcc/testsuite/c-c++-common/gomp/append-args-2.c|  10 +
 gcc/testsuite/c-c++-common/gomp/append-args-3.c|  57 +++
 .../c-c++-common/gomp/decl

Re: [PATCH] RISC-V: Support for zilsd and zclsd extensions.

[Yangyu Chen]

> On Dec 16, 2024, at 23:42, Kito Cheng  wrote:
> 
> On Mon, Dec 16, 2024 at 10:58 PM Dongyan Chen
>  wrote:
>> 
>> This patch support zilsd and zclsd[1] extensions.
>> To enable GCC to recognize and process zilsd and zclsd extension correctly 
>> at compile time.
>> 
>> [1] https://github.com/riscv/riscv-zilsd
>> 
>> gcc/ChangeLog:
>> 
>>* common/config/riscv/riscv-common.cc 
>> (riscv_subset_list::check_conflict_ext): New extension.
>>* common/config/riscv/riscv-ext-bitmask.def (RISCV_EXT_BITMASK): 
>> Ditto.
>>* config/riscv/riscv.opt: Ditto.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>>* gcc.target/riscv/arch-45.c: New test.
>>* gcc.target/riscv/arch-46.c: New test.
>>* gcc.target/riscv/arch-47.c: New test.
>> 
>> ---
>> gcc/common/config/riscv/riscv-common.cc   | 17 +
>> gcc/common/config/riscv/riscv-ext-bitmask.def |  2 ++
>> gcc/config/riscv/riscv.opt|  4 
>> gcc/testsuite/gcc.target/riscv/arch-45.c  |  5 +
>> gcc/testsuite/gcc.target/riscv/arch-46.c  |  6 ++
>> gcc/testsuite/gcc.target/riscv/arch-47.c  |  5 +
>> 6 files changed, 39 insertions(+)
>> create mode 100644 gcc/testsuite/gcc.target/riscv/arch-45.c
>> create mode 100644 gcc/testsuite/gcc.target/riscv/arch-46.c
>> create mode 100644 gcc/testsuite/gcc.target/riscv/arch-47.c
>> 
>> diff --git a/gcc/common/config/riscv/riscv-common.cc 
>> b/gcc/common/config/riscv/riscv-common.cc
>> index 4c9a72d1180a..eb999b322c78 100644
>> --- a/gcc/common/config/riscv/riscv-common.cc
>> +++ b/gcc/common/config/riscv/riscv-common.cc
>> @@ -111,6 +111,10 @@ static const riscv_implied_info_t riscv_implied_info[] =
>>   {"zfinx", "zicsr"},
>>   {"zdinx", "zicsr"},
>> 
>> +  {"zclsd", "zilsd"},
>> +  {"zilsd", "zicsr"},
>> +  {"zclsd", "zicsr"},
>> +
>>   {"zk", "zkn"},
>>   {"zk", "zkr"},
>>   {"zk", "zkt"},
>> @@ -331,6 +335,9 @@ static const struct riscv_ext_version 
>> riscv_ext_version_table[] =
>>   {"zicntr", ISA_SPEC_CLASS_NONE, 2, 0},
>>   {"zihpm",  ISA_SPEC_CLASS_NONE, 2, 0},
>> 
>> +  {"zilsd",  ISA_SPEC_CLASS_NONE, 1, 0},
>> +  {"zclsd",  ISA_SPEC_CLASS_NONE, 1, 0},
>> +
>>   {"zk",ISA_SPEC_CLASS_NONE, 1, 0},
>>   {"zkn",   ISA_SPEC_CLASS_NONE, 1, 0},
>>   {"zks",   ISA_SPEC_CLASS_NONE, 1, 0},
>> @@ -1301,6 +1308,14 @@ riscv_subset_list::check_conflict_ext ()
>>   if (lookup ("zcf") && m_xlen == 64)
>> error_at (m_loc, "%<-march=%s%>: zcf extension supports in rv32 only",
>>  m_arch);
>> +
>> +  if (lookup ("zilsd") && m_xlen == 64)
>> +error_at (m_loc, "%<-march=%s%>: zilsd extension supports in rv32 only",
>> + m_arch);
>> +
>> +  if (lookup ("zclsd") && m_xlen == 64)
>> +error_at (m_loc, "%<-march=%s%>: zclsd extension supports in rv32 only",
>> + m_arch);
>> 
>>   if (lookup ("zfinx") && lookup ("f"))
>> error_at (m_loc,
>> @@ -1641,6 +1656,7 @@ static const riscv_ext_flag_table_t 
>> riscv_ext_flag_table[] =
>>   RISCV_EXT_FLAG_ENTRY ("ziccif",  x_riscv_zi_subext, MASK_ZICCIF),
>>   RISCV_EXT_FLAG_ENTRY ("zicclsm", x_riscv_zi_subext, MASK_ZICCLSM),
>>   RISCV_EXT_FLAG_ENTRY ("ziccrse", x_riscv_zi_subext, MASK_ZICCRSE),
>> +  RISCV_EXT_FLAG_ENTRY ("zilsd",   x_riscv_zi_subext, MASK_ZILSD),
>> 
>>   RISCV_EXT_FLAG_ENTRY ("zicboz", x_riscv_zicmo_subext, MASK_ZICBOZ),
>>   RISCV_EXT_FLAG_ENTRY ("zicbom", x_riscv_zicmo_subext, MASK_ZICBOM),
>> @@ -1721,6 +1737,7 @@ static const riscv_ext_flag_table_t 
>> riscv_ext_flag_table[] =
>>   RISCV_EXT_FLAG_ENTRY ("zcd",  x_riscv_zc_subext, MASK_ZCD),
>>   RISCV_EXT_FLAG_ENTRY ("zcmp", x_riscv_zc_subext, MASK_ZCMP),
>>   RISCV_EXT_FLAG_ENTRY ("zcmt", x_riscv_zc_subext, MASK_ZCMT),
>> +  RISCV_EXT_FLAG_ENTRY ("zclsd", x_riscv_zc_subext, MASK_ZCLSD),
>> 
>>   RISCV_EXT_FLAG_ENTRY ("svinval", x_riscv_sv_subext, MASK_SVINVAL),
>>   RISCV_EXT_FLAG_ENTRY ("svnapot", x_riscv_sv_subext, MASK_SVNAPOT),
>> diff --git a/gcc/common/config/riscv/riscv-ext-bitmask.def 
>> b/gcc/common/config/riscv/riscv-ext-bitmask.def
>> index a733533df98e..af3ea47162b9 100644
>> --- a/gcc/common/config/riscv/riscv-ext-bitmask.def
>> +++ b/gcc/common/config/riscv/riscv-ext-bitmask.def
>> @@ -80,5 +80,7 @@ RISCV_EXT_BITMASK ("zcf", 1,  5)
>> RISCV_EXT_BITMASK ("zcmop",1,  6)
>> RISCV_EXT_BITMASK ("zawrs",1,  7)
>> RISCV_EXT_BITMASK ("svvptc",   1,  8)
>> +RISCV_EXT_BITMASK ("zilsd",1,  9)
>> +RISCV_EXT_BITMASK ("zclsd",1,  10)
> 
> This file should only touched when it added to either linux hwprobe
> and/or riscv-c-api
> 

Indeed. And you can add Zilsd and Zclsd to C-API by submitting PR here:

https://github.com/riscv-non-isa/riscv-c-api-doc/blob/main/src/c-api.adoc#extension-bitmask-definitions

Thanks,
Yangyu Chen

>> 
>> #undef RISCV_EXT_BITMASK
>> diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
>> index a6a61a83db1b..f2891ea65e38 100644
>> --- a/gcc/config/riscv/ris

Re: [PATCH] arm,testsuite: Add -mtune=cortex-m55 to dlstp-int8x16.c

[Richard Earnshaw (lists)]

On 06/12/2024 16:09, Christophe Lyon wrote:
> Like dlstp-compile-asm-1.c, this test would fail if GCC is configured
> with non-default options, such as -mtune=cortex-a9.
> 
> Force -mtune=cortex-m55 to avoid this unexpected issue.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/arm/mve/dlstp-int8x16.c: Add -mtune=cortex-m55
> ---
>  gcc/testsuite/gcc.target/arm/mve/dlstp-int8x16.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/mve/dlstp-int8x16.c 
> b/gcc/testsuite/gcc.target/arm/mve/dlstp-int8x16.c
> index d5f22b50262..8ec0a57a783 100644
> --- a/gcc/testsuite/gcc.target/arm/mve/dlstp-int8x16.c
> +++ b/gcc/testsuite/gcc.target/arm/mve/dlstp-int8x16.c
> @@ -1,6 +1,6 @@
>  /* { dg-do compile { target { arm*-*-* } } } */
>  /* { dg-require-effective-target arm_v8_1m_mve_ok } */
> -/* { dg-options "-O2 -save-temps" } */
> +/* { dg-options "-O2 -save-temps -mtune=cortex-m55" } */
>  /* { dg-add-options arm_v8_1m_mve } */
>  
>  #include 

OK.

R.

Re: [PATCH v4] arm: [MVE intrinsics] Fix support for predicate constants [PR target/114801]

[Richard Earnshaw (lists)]

On 13/12/2024 14:29, Christophe Lyon wrote:
> On Tue, 10 Dec 2024 at 13:14, Richard Earnshaw (lists)
>  wrote:
>>
>> On 09/12/2024 21:11, Christophe Lyon wrote:
>>> In this PR, we have to handle a case where MVE predicates are supplied
>>> as a const_int, where individual predicates have illegal boolean
>>> values (such as 0xc for a 4-bit boolean predicate).  To avoid the ICE,
>>> fix the constant (any non-zero value is converted to all 1s) and emit
>>> a warning.
>>>
>>> On MVE, V8BI and V4BI multi-bit masks are interpreted byte-by-byte at
>>> instruction level, but end-users should describe lanes rather than
>>> bytes (so all bytes of a true-predicated lane should be '1'), see the
>>> section on MVE intrinsics in the Arm ACLE specification.
>>>
>>> Since force_lowpart_subreg cannot handle const_int (because they have VOID 
>>> mode),
>>> use gen_lowpart on them, force_lowpart_subreg otherwise.
>>>
>>> 2024-11-20  Christophe Lyon  
>>>   Jakub Jelinek  
>>>
>>>   PR target/114801
>>>   gcc/
>>>   * config/arm/arm-mve-builtins.cc
>>>   (function_expander::add_input_operand): Handle CONST_INT
>>>   predicates.
>>>
>>>   gcc/testsuite/
>>>   * gcc.target/arm/mve/pr108443.c: Update predicate constant.
>>>   * gcc.target/arm/mve/pr108443-run.c: Likewise.
>>>   * gcc.target/arm/mve/pr114801.c: New test.
>>
>> Thanks, that looks much better.  OK, assuming no regressions.
>>
> 
> Indeed, thanks for your suggestions.
> 
> OK to backport to gcc-14  after a while?

Yes.

R.

Re: [PATCH] c: do not warn about truncating NUL char when initializing nonstring arrays [PR117178]

[Alejandro Colomar]

Hi Kees,

On Sun, Dec 15, 2024 at 08:02:57PM -0800, Kees Cook wrote:
> When initializing a nonstring char array when compiled with
> -Wunterminated-string-initialization the warning trips even when
> truncating the trailing NUL character from the string constant. Only
> warn about this when running under -Wc++-compat since under C++ we should
> not initialize nonstrings from C strings.
> 
>   PR c/117178
> 
> gcc/c/ChangeLog:
> 
> * c-typeck.cc (digest_init): Check for nonstring attribute and
>   avoid warning when only the trailing NUL is truncated.
> (build_c_cast): Update function call prototype.
> (store_init_value): Ditto.
> (output_init_element): Ditto.
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.dg/Wunterminated-string-initialization.c: Update for
>   new warning text and check for nonstring cases.
> * gcc.dg/Wunterminated-string-initialization-c++.c: Duplicate
>   C test for -Wc++-compat.

The log and the code look good to me, but I'm not a maintainer, so can't
review that part.  For the behavior and tests:

Acked-by: Alejandro Colomar 

Thanks!
And have a lovely day!
Alex

> ---
>  gcc/c/c-typeck.cc | 73 ---
>  .../Wunterminated-string-initialization-c++.c | 28 +++
>  .../Wunterminated-string-initialization.c | 26 ++-
>  3 files changed, 98 insertions(+), 29 deletions(-)
>  create mode 100644 
> gcc/testsuite/gcc.dg/Wunterminated-string-initialization-c++.c
> 
> diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
> index 10b02da8752d..5cd0c07b87b1 100644
> --- a/gcc/c/c-typeck.cc
> +++ b/gcc/c/c-typeck.cc
> @@ -116,8 +116,8 @@ static void push_member_name (tree);
>  static int spelling_length (void);
>  static char *print_spelling (char *);
>  static void warning_init (location_t, int, const char *);
> -static tree digest_init (location_t, tree, tree, tree, bool, bool, bool, 
> bool,
> -  bool, bool);
> +static tree digest_init (location_t, tree, tree, tree, tree, bool, bool, 
> bool,
> +  bool, bool, bool);
>  static void output_init_element (location_t, tree, tree, bool, tree, tree, 
> bool,
>bool, struct obstack *);
>  static void output_pending_init_elements (int, struct obstack *);
> @@ -6731,7 +6731,7 @@ build_c_cast (location_t loc, tree type, tree expr)
> t = build_constructor_single (type, field, t);
> if (!maybe_const)
>   t = c_wrap_maybe_const (t, true);
> -   t = digest_init (loc, type, t,
> +   t = digest_init (loc, field, type, t,
>  NULL_TREE, false, false, false, true, false, false);
> TREE_CONSTANT (t) = TREE_CONSTANT (value);
> return t;
> @@ -8646,8 +8646,8 @@ store_init_value (location_t init_loc, tree decl, tree 
> init, tree origtype)
>  }
>bool constexpr_p = (VAR_P (decl)
> && C_DECL_DECLARED_CONSTEXPR (decl));
> -  value = digest_init (init_loc, type, init, origtype, npc, int_const_expr,
> -arith_const_expr, true,
> +  value = digest_init (init_loc, decl, type, init, origtype, npc,
> +int_const_expr, arith_const_expr, true,
>  TREE_STATIC (decl) || constexpr_p, constexpr_p);
>  
>/* Store the expression if valid; else report error.  */
> @@ -8996,8 +8996,8 @@ check_constexpr_init (location_t loc, tree type, tree 
> init,
> on initializers for 'constexpr' objects apply.  */
>  
>  static tree
> -digest_init (location_t init_loc, tree type, tree init, tree origtype,
> -  bool null_pointer_constant, bool int_const_expr,
> +digest_init (location_t init_loc, tree field, tree type, tree init,
> +  tree origtype, bool null_pointer_constant, bool int_const_expr,
>bool arith_const_expr, bool strict_string,
>bool require_constant, bool require_constexpr)
>  {
> @@ -9132,27 +9132,46 @@ digest_init (location_t init_loc, tree type, tree 
> init, tree origtype,
> && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
>   {
> unsigned HOST_WIDE_INT len = TREE_STRING_LENGTH (inside_init);
> -   unsigned unit = TYPE_PRECISION (typ1) / BITS_PER_UNIT;
> -
> -   /* Subtract the size of a single (possibly wide) character
> -  because it's ok to ignore the terminating null char
> -  that is counted in the length of the constant.  */
> -   if (compare_tree_int (TYPE_SIZE_UNIT (type), len - unit) < 0)
> - pedwarn_init (init_loc, 0,
> -   ("initializer-string for array of %qT "
> -"is too long"), typ1);
> -   else if (warn_unterminated_string_initialization
> -&& compare_tree_int (TYPE_SIZE_UNIT (type), len) < 0)
> - warning_at (init_loc, OPT_Wunterminated_string_initialization,
> - ("initializer-string for arra

[PATCH] mtd: spi-nor: winbond: add w25q01jv flash chip

[Wilken Gottwalt]

Add Winbond W25Q01JV 128 MiB SPI NOR flash chip, verified working on the
Zynq-7000 platform QSPI controller. The flash chip has quite high read
speeds (about 60+ MiB/s), but erasing is very slow. The slow erasing is
by design.

Signed-off-by: Wilken Gottwalt 
---
 drivers/mtd/spi-nor/winbond.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c
index 8d0a00d69e12..e2caf299d19a 100644
--- a/drivers/mtd/spi-nor/winbond.c
+++ b/drivers/mtd/spi-nor/winbond.c
@@ -146,6 +146,12 @@ static const struct flash_info winbond_nor_parts[] = {
.name = "w25q512jvq",
.size = SZ_64M,
.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | 
SPI_NOR_QUAD_READ,
+   }, {
+   .id = SNOR_ID(0xef, 0x40, 0x21),
+   .name = "w25q01jv",
+   .size = SZ_128M,
+   .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB,
+   .no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | 
SPI_NOR_QUAD_READ,
}, {
.id = SNOR_ID(0xef, 0x50, 0x12),
.name = "w25q20bw",
-- 
2.47.1

Re: [PATCH] c and c++: Make sure LHS and RHS has identical named types [PR116060]

[Marek Polacek]

On Mon, Dec 16, 2024 at 01:16:37PM +0100, Torbjörn SVENSSON wrote:
> Hi,
> 
> I've reg-tested this patch on both the trunk and the releases/gcc-14
> branches for x86_64-linux-gnu and arm-none-eabi and it no longer fails
> for any of the out-of-bounds-diagram* tests on any of the 2 platforms.
> 
> I'm a bit puzzled if the C++ part is enough, but I can't think of a way
> to trigger anything that show the wrong output after my change.
> Do you think that I need to add any additional tests? I think the
> existing test covers the problem well enough.
> 
> Ok for trunk and releases/gcc-14?
> 
> --
> 
> gcc/ChangeLog:
> 
>   PR c/116060
>   c/c-typeck.cc: Make sure left hand side and right hand side has
>   identical named types to aid diagnostic output.
>   cp/call.cc: Likewise.

Please drop the c/ and cp/ prefixes.  There should be an entry for
c/ChangeLog and another one for cp/ChangeLog.
 
> gcc/testsuite/ChangeLog:
> 
>   PR c/116060
>   c-c++-common/analyzer/out-of-bounds-diagram-8.c: Update to
>   correct type.
>   c-c++-common/analyzer/out-of-bounds-diagram-11.c: Likewise.
>   gcc.dg/analyzer/out-of-bounds-diagram-10.c: Likewise.
> 
> Signed-off-by: Torbjörn SVENSSON 
> ---
>  gcc/c/c-typeck.cc |  3 ++
>  gcc/cp/call.cc|  9 ++
>  .../analyzer/out-of-bounds-diagram-11.c   | 28 +--
>  .../analyzer/out-of-bounds-diagram-8.c| 28 +--
>  .../analyzer/out-of-bounds-diagram-10.c   | 28 +--
>  5 files changed, 54 insertions(+), 42 deletions(-)
> 
> diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
> index 902898d1944..e3e85d1ecde 100644
> --- a/gcc/c/c-typeck.cc
> +++ b/gcc/c/c-typeck.cc
> @@ -7831,6 +7831,9 @@ convert_for_assignment (location_t location, location_t 
> expr_loc, tree type,
>if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (rhstype))
>  {
>warn_for_address_of_packed_member (type, orig_rhs);
> +  if (type != rhstype)
> + /* Convert RHS to TYPE in order to not loose TYPE in diagnostics.  */

As in cp/, loose -> lose.

Marek

Re: [PATCH] mtd: spi-nor: winbond: add w25q01jv flash chip

[Wilken Gottwalt]

On Mon, 16 Dec 2024 08:22:45 -0500
David Malcolm  wrote:

> On Mon, 2024-12-16 at 11:26 +, Wilken Gottwalt wrote:
> > Add Winbond W25Q01JV 128 MiB SPI NOR flash chip, verified working on
> > the
> > Zynq-7000 platform QSPI controller. The flash chip has quite high
> > read
> > speeds (about 60+ MiB/s), but erasing is very slow. The slow erasing
> > is
> > by design.
> > 
> > Signed-off-by: Wilken Gottwalt 
> > ---
> >  drivers/mtd/spi-nor/winbond.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> Did you mean to send this to gcc-patches@gcc.gnu.org?  This appears to
> be a patch for the kernel.

Ah well, this is a good example why you should not stick to copy&paste while
being ill. My fault.

greetings,
Wilken

Re: [PATCH 1/2] RISC-V: Support RISC-V Profiles RV20/22.

[Jiawei]

在 2024/12/15 23:50, Jeff Law 写道:



On 12/3/24 4:02 AM, Jiawei wrote:

This patch introduces support for RISC-V Profiles RV20 and RV22 [1],
enabling developers to utilize these profiles through the -march option.

[1] https://github.com/riscv/riscv-profiles/releases/tag/v1.0

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc (struct riscv_profiles): 
New struct.

(riscv_subset_list::parse_profiles): New parser.
(riscv_subset_list::parse_base_ext): Ditto.
* config/riscv/riscv-subset.h: New def.


[ ... ]



+const char *
+riscv_subset_list::parse_profiles (const char *p)
+{
+  /* Checking if input string contains a Profiles.
+ There are two cases use Profiles in -march option:
+
+ 1. Only use Profiles as -march input
+ 2. Mixed Profiles with other extensions
+
+ Use '+' to split Profiles and other extension.  */
Does LLVM use this same convention (using '+' to split profiles from 
additional extensions)?  I don't see it in the spec so I think we 
really need to make sure LLVM and GCC are in sync on this.


I think we need some kind of documentation around the new option in 
invoke.texi.


I didn't check the precise set of options in the spec.  That should be 
double-checked in the expected update of this patchkit.



jeff


In fact, we do have a PR in 
https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/36 to 
discuss the format, but it was out of date, I will pick up it, and 
update the format doc first in


recent days.


BR,
Jiawei

Re: [PATCH] c and c++: Make sure LHS and RHS has identical named types [PR116060]

[Jason Merrill]

On 12/16/24 7:16 AM, Torbjörn SVENSSON wrote:

Hi,

I've reg-tested this patch on both the trunk and the releases/gcc-14
branches for x86_64-linux-gnu and arm-none-eabi and it no longer fails
for any of the out-of-bounds-diagram* tests on any of the 2 platforms.

I'm a bit puzzled if the C++ part is enough, but I can't think of a way
to trigger anything that show the wrong output after my change.
Do you think that I need to add any additional tests? I think the
existing test covers the problem well enough.

Ok for trunk and releases/gcc-14?


This won't be a candidate for backporting to 14.


--

gcc/ChangeLog:

PR c/116060
c/c-typeck.cc: Make sure left hand side and right hand side has
identical named types to aid diagnostic output.
cp/call.cc: Likewise.

gcc/testsuite/ChangeLog:

PR c/116060
c-c++-common/analyzer/out-of-bounds-diagram-8.c: Update to
correct type.
c-c++-common/analyzer/out-of-bounds-diagram-11.c: Likewise.
gcc.dg/analyzer/out-of-bounds-diagram-10.c: Likewise.

Signed-off-by: Torbjörn SVENSSON 
---
  gcc/c/c-typeck.cc |  3 ++
  gcc/cp/call.cc|  9 ++
  .../analyzer/out-of-bounds-diagram-11.c   | 28 +--
  .../analyzer/out-of-bounds-diagram-8.c| 28 +--
  .../analyzer/out-of-bounds-diagram-10.c   | 28 +--
  5 files changed, 54 insertions(+), 42 deletions(-)

diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 902898d1944..e3e85d1ecde 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -7831,6 +7831,9 @@ convert_for_assignment (location_t location, location_t 
expr_loc, tree type,
if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (rhstype))
  {
warn_for_address_of_packed_member (type, orig_rhs);
+  if (type != rhstype)
+   /* Convert RHS to TYPE in order to not loose TYPE in diagnostics.  */
+   rhs = convert (type, rhs);
return rhs;
  }
  
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc

index c8420db568e..d859ce9a2d6 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -1319,6 +1319,9 @@ standard_conversion (tree to, tree from, tree expr, bool 
c_cast_p,
  {
if (CLASS_TYPE_P (to) && conv->kind == ck_rvalue)
conv->type = qualified_to;
+  else if (from != to)
+   /* Use TO in order to not loose TO in diagnostics.  */


"lose"


+   conv->type = to;
return conv;
  }
  
@@ -8741,6 +8744,12 @@ convert_like_internal (conversion *convs, tree expr, tree fn, int argnum,

   continue to warn about uses of EXPR as an integer, rather than as a
   pointer.  */
expr = build_int_cst (totype, 0);
+  if (TREE_CODE (expr) == NON_LVALUE_EXPR && TREE_TYPE (expr) != totype)


You might check !obvalue_p (expr) instead of just NON_LVALUE_EXPR?


+   {
+ /* Use TOTYPE in order to not loose TOTYPE in diagnostics.  */


"lose"


+  expr = copy_node (expr);
+  TREE_TYPE (expr) = totype;
+   }


Let's use cp_fold_convert instead of manually optimizing the conversion.

You might also adjust the ck_rvalue case later in the function, i.e. here:


  if (! MAYBE_CLASS_TYPE_P (totype))
return expr;


Jason

Re: [PATCH] RISC-V: Remove svvptc from riscv-ext-bitmask.def

[Palmer Dabbelt]

On Mon, 16 Dec 2024 08:37:13 PST (-0800), c...@cyyself.name wrote:

There should be no svvptc in the riscv-ext-bitmask.def file since it has
not yet been added to the RISC-V C API Specification or the Linux
hwprobe. And there is no need for userspace software to know that this
extension exists. So remove it from the riscv-ext-bitmask.def file.

Fixes: e4f4b2dc08 ("RISC-V: Minimal support for svvptc extension.")
Signed-off-by: Yangyu Chen 

gcc/ChangeLog:

* common/config/riscv/riscv-ext-bitmask.def (RISCV_EXT_BITMASK): Remove 
svvptc.
---
 gcc/common/config/riscv/riscv-ext-bitmask.def | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/common/config/riscv/riscv-ext-bitmask.def 
b/gcc/common/config/riscv/riscv-ext-bitmask.def
index a733533df98..ca5df1740f3 100644
--- a/gcc/common/config/riscv/riscv-ext-bitmask.def
+++ b/gcc/common/config/riscv/riscv-ext-bitmask.def
@@ -79,6 +79,5 @@ RISCV_EXT_BITMASK ("zcd",   1,  4)
 RISCV_EXT_BITMASK ("zcf",1,  5)
 RISCV_EXT_BITMASK ("zcmop",  1,  6)
 RISCV_EXT_BITMASK ("zawrs",  1,  7)
-RISCV_EXT_BITMASK ("svvptc", 1,  8)

 #undef RISCV_EXT_BITMASK


Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 

I think we'll likely never expose this to userspace, the mappings are 
all hidden behind kernel interfaces so userspace shouldn't need to know.

[Committed] testsuite: Force max-completely-peeled-insns=300 for CRIS, PR118055

[Hans-Peter Nilsson]

Committed.

An alternative would have been to restrict the
scan-tree-dump-times lines in the tests to a list of known
targets, but that's more of a testsuite maintainer-level
change (not actually a valid excuse).

CC to m68k maintainers, who might want to check that 300
fits and add m68k to the list, or do something different.
I'll close the PR in a week or with m68k handled, whichever
comes first.

-- >8 --
This handles fallout from r15-6097-gee2f19b0937b5e.  A brief
analysis shows that the metric used in that code is computed
by estimate_move_cost, differentiating on the target macro
MOVE_MAX_PIECES (which defaults to MOVE_MAX) which for most
"32-bit targets" is 4 and for "64-bit targets" is 8.  There
are some outliers, like pru, with MOVE_MAX set to 8 but
counting as a 32-bit target.

So, the main difference for this test-case, which is heavy
on 64-bit moves (most targets have "double" mapped to IEEE
64-bit), is between "32-bit" and "64-bit", with the cost up
to twice for the former compared to the latter.  I see no
effective_target_move_max_is_4 or equivalent, and this
instance falls below the threshold of adding one, so I'm
sticking to a list of targets.  For CRIS, it would suffice
with 210, but there's no need to be this specific, and it
would make the test even more brittle.

PR tree-optimization/118055
* gcc.dg/tree-ssa/pr83403-1.c, gcc.dg/tree-ssa/pr83403-2.c: Add
cris-*-* to targets passing --param=max-completely-peeled-insns=300.
---
 gcc/testsuite/gcc.dg/tree-ssa/pr83403-1.c | 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/pr83403-2.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr83403-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr83403-1.c
index 293fd2dbd973..3cfda4f183cd 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr83403-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr83403-1.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O3 -funroll-loops -fdump-tree-lim2-details" } */
 /* { dg-additional-options "--param max-completely-peeled-insns=200" { target 
{ s390*-*-* } } } */
-/* { dg-additional-options "--param max-completely-peeled-insns=300" { target 
{ arm*-*-* } } } */
+/* { dg-additional-options "--param max-completely-peeled-insns=300" { target 
{ arm*-*-* cris-*-* } } } */
 
 #define TYPE unsigned int
 
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr83403-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr83403-2.c
index b421b387bcab..00fa04ecb851 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr83403-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr83403-2.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O3 -funroll-loops -fdump-tree-lim2-details" } */
 /* { dg-additional-options "--param max-completely-peeled-insns=200" { target 
{ s390*-*-* } } } */
-/* { dg-additional-options "--param max-completely-peeled-insns=300" { target 
{ arm*-*-* } } } */
+/* { dg-additional-options "--param max-completely-peeled-insns=300" { target 
{ arm*-*-* cris-*-* } } } */
 
 #define TYPE int
 
-- 
2.30.2

Re: [Fortran, Patch, PR117347, v2] Fix array constructor not resolved in associate

[Harald Anlauf]

Hi Andre,

Am 16.12.24 um 15:26 schrieb Andre Vehreschild:

Hi Harald,

thanks for finding the bug so quickly. I took another look and came up with the
attached trivially looking patch, which replaces the old version 1 entirely.

The new v2 version of the patch just makes use of existing code guessing the
type of the associate variable, which once I found it worked surprisingly
well. I have also extended the testcase.


this patch is really obvious and does work, too!


Regtests ok on x86_64-pc-linux-gnu. Ok for mainline?


Clearly OK for mainline.  And since it is so simple, also for
backporting if you are inclined to do so.  (14 is certainly fine).

Thanks for the patch!

Harald


Regards,
Andre

On Fri, 13 Dec 2024 14:09:25 +0100
Harald Anlauf  wrote:


Hi Andre,

while the patch works with the reduced testcase, it runs into the
newly added gcc_assert() when trying the original testcase in the PR.

I also wonder if this use of gcc_assert() is a good idea or good style:

+  gcc_assert (gfc_resolve_expr (tgt_expr));

Since gcc_assert is a macro, and its precise definition depends on
configuration and could possibly be defined to be a no-op, I suggest
to evaluate arguments with side-effects outside and pass the
return code to gcc_assert.  (There are also many other ways to handle
this situation.

Then removing the gcc_assert around the gfc_resolve_expr() avoids
the ICE, but restores the reported error.

So not OK yet.  Sorry!

Thanks,
Harald


Am 13.12.24 um 10:10 schrieb Andre Vehreschild:

Hi all,

attached patch fixes an reject-valid of an array constructor in an
associate by resolving the array constructor before parsing the
associate-block. I am not 100% sure, if that is the right place to do this.
But given, that there is already a special casing before the patch, I just
propose to do the resolve there.

Regstests ok on x86_64-pc-linux-gnu / F41. Ok for mainline ?

Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de





--
Andre Vehreschild * Email: vehre ad gmx dot de

[pushed: r15-6283] diagnostics: move libgdiagnostics dc from sinks into diagnostic_manager

[David Malcolm]

libgdiagnostics was written before the fixes for PR other/116613 allowed
a diagnostic_context to have multiple output sinks.

Hence each libgdiagnostics sink had its own diagnostic_context with just
one diagnostic_output_format.

This wart is no longer necessary and makes it harder to move state
into the manager/context; in particular for quoting source code
from the .sarif file (PR sarif-replay/117943).

Simplify, by making libgdiagnostics' implementation more similar to
GCC's implementation, by moving the diagnostic_context from sink into
diagnostic_manager.

Doing so requires generalizing where the
diagnostic_source_printing_options comes from in class
diagnostic_text_output_format: for GCC we use
the instance within the diagnostic_context, whereas for
libgdiagnostics each diagnostic_text_sink has its own instance.

No functional change intended.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-6283-gea7da640cf234e.

gcc/c-family/ChangeLog:
PR sarif-replay/117943
* c-format.cc (selftest::test_type_mismatch_range_labels): Use
dc.m_source_printing.
* c-opts.cc (c_diagnostic_text_finalizer): Use source-printing
options from text_output.

gcc/cp/ChangeLog:
PR sarif-replay/117943
* error.cc (auto_context_line::~auto_context_line): Use
source-printing options from text_output.

gcc/ChangeLog:
PR sarif-replay/117943
* diagnostic-format-text.cc
(diagnostic_text_output_format::append_note): Use source-printing
options from text_output.
(diagnostic_text_output_format::update_printer): Copy
source-printing options from dc.
(default_diagnostic_text_finalizer): Use source-printing
options from text_output.
* diagnostic-format-text.h
(diagnostic_text_output_format::diagnostic_text_output_format):
Add optional diagnostic_source_printing_options param, using
the context's if null.
(diagnostic_text_output_format::get_source_printing_options): New
accessor.
(diagnostic_text_output_format::m_source_printing): New field.
* diagnostic-path.cc (event_range::print): Use source-printing
options from text_output.
(selftest::test_interprocedural_path_1): Use source-printing
options from dc.
* diagnostic-show-locus.cc
(gcc_rich_location::add_location_if_nearby): Likewise.
(diagnostic_context::maybe_show_locus): Add "opts" param
and use in place of m_source_printing.  Pass it to source_policy
ctor.
(diagnostic_source_print_policy::diagnostic_source_print_policy):
Add overload taking a const diagnostic_source_printing_options &.
* diagnostic.cc (diagnostic_context::initialize): Pass nullptr
for source options when creating text sink, so that it uses
the dc's options.
(diagnostic_context::dump): Add an "output sinks:" heading and
print "(none)" if there aren't any.
(diagnostic_context::set_output_format): Split out code into...
(diagnostic_context::remove_all_output_sinks): ...this new
function.
* diagnostic.h
(diagnostic_source_print_policy::diagnostic_source_print_policy):
Add overload taking a const diagnostic_source_printing_options &.
(diagnostic_context::maybe_show_locus): Add "opts" param.
(diagnostic_context::remove_all_output_sinks): New decl.
(diagnostic_context::m_source_printing): New field.
(diagnostic_show_locus): Add "opts" param and pass to
maybe_show_locus.
* libgdiagnostics.cc (sink::~sink): Delete.
(sink::begin_group): Delete.
(sink::end_group): Delete.
(sink::emit): Delete.
(sink::m_dc): Drop field.
(diagnostic_text_sink::on_begin_text_diagnostic): Delete.
(diagnostic_text_sink::get_source_printing_options): Use
m_souece_printing.
(diagnostic_text_sink::m_current_logical_loc): Drop field.
(diagnostic_text_sink::m_inner_sink): New field.
(diagnostic_text_sink::m_source_printing): New field.
(diagnostic_manager::diagnostic_manager): Update for changes
to fields.  Initialize m_dc.
(diagnostic_manager::~diagnostic_manager): Call diagnostic_finish.
(diagnostic_manager::get_file_cache): Drop.
(diagnostic_manager::get_dc): New accessor.
(diagnostic_manager::begin_group): Reimplement.
(diagnostic_manager::end_group): Reimplement.
(diagnostic_manager::get_prev_diag_logical_loc): New accessor.
(diagnostic_manager::m_dc): New field.
(diagnostic_manager::m_file_cache): Drop field.
(diagnostic_manager::m_edit_context): Convert to a std::unique_ptr
so that object can be constructed after m_dc is initialized.
(diagnostic_manager::m_prev_diag_logical_loc): New field.
(diagnostic_text_sink::diagnostic_te

[pushed: r15-6282] diagnostics: implement file_cache::dump

[David Malcolm]

This is purely for use when debugging.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-6282-ge55cfebd0016e4.

gcc/ChangeLog:
* diagnostic.cc (diagnostic_context::dump): Dump m_file_cache.
* input.cc (file_cache_slot::dump): New decls and implementations.
(file_cache::dump): New.
* input.h (file_cache::dump): New decl.

Signed-off-by: David Malcolm 
---
 gcc/diagnostic.cc |  5 +
 gcc/input.cc  | 46 ++
 gcc/input.h   |  3 +++
 3 files changed, 54 insertions(+)

diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index 054a61d8afe7..610914b267f9 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -449,6 +449,11 @@ diagnostic_context::dump (FILE *out) const
 m_diagnostic_buffer->dump (out, 4);
   else
 fprintf (out, "(none):\n");
+  fprintf (out, "  file cache:\n");
+  if (m_file_cache)
+m_file_cache->dump (out, 4);
+  else
+fprintf (out, "(none):\n");
 }
 
 /* Return true if sufficiently severe diagnostics have been seen that
diff --git a/gcc/input.cc b/gcc/input.cc
index 7fc683db23f1..b4911581924d 100644
--- a/gcc/input.cc
+++ b/gcc/input.cc
@@ -57,6 +57,9 @@ public:
   file_cache_slot ();
   ~file_cache_slot ();
 
+  void dump (FILE *out, int indent) const;
+  void DEBUG_FUNCTION dump () const { dump (stderr, 0); }
+
   bool read_line_num (size_t line_num,
  char ** line, ssize_t *line_len);
 
@@ -524,6 +527,22 @@ file_cache::~file_cache ()
   delete[] m_file_slots;
 }
 
+void
+file_cache::dump (FILE *out, int indent) const
+{
+  for (size_t i = 0; i < num_file_slots; ++i)
+{
+  fprintf (out, "%*sslot[%i]:\n", indent, "", (int)i);
+  m_file_slots[i].dump (out, indent + 2);
+}
+}
+
+void
+file_cache::dump () const
+{
+  dump (stderr, 0);
+}
+
 /* Lookup the cache used for the content of a given file accessed by
caret diagnostic.  If no cached file was found, create a new cache
for this file, add it to the array of cached file and return
@@ -570,6 +589,33 @@ file_cache_slot::~file_cache_slot ()
   m_line_record.release ();
 }
 
+void
+file_cache_slot::dump (FILE *out, int indent) const
+{
+  if (!m_fp)
+{
+  fprintf (out, "%*s(unused)\n", indent, "");
+  return;
+}
+  fprintf (out, "%*sfile_path: %s\n", indent, "", m_file_path);
+  fprintf (out, "%*sneeds_read_p: %i\n", indent, "", (int)needs_read_p ());
+  fprintf (out, "%*sneeds_grow_p: %i\n", indent, "", (int)needs_grow_p ());
+  fprintf (out, "%*suse_count: %i\n", indent, "", m_use_count);
+  fprintf (out, "%*ssize: %zi\n", indent, "", m_size);
+  fprintf (out, "%*snb_read: %zi\n", indent, "", m_nb_read);
+  fprintf (out, "%*sstart_line_idx: %zi\n", indent, "", m_line_start_idx);
+  fprintf (out, "%*sline_num: %zi\n", indent, "", m_line_num);
+  fprintf (out, "%*stotal_lines: %zi\n", indent, "", m_total_lines);
+  fprintf (out, "%*smissing_trailing_newline: %i\n",
+  indent, "", (int)m_missing_trailing_newline);
+  fprintf (out, "%*sline records (%i):\n",
+  indent, "", m_line_record.length ());
+  for (auto &line : m_line_record)
+fprintf (out, "%*sline %zi: byte offsets: %zi-%zi\n",
+indent + 2, "",
+line.line_num, line.start_pos, line.end_pos);
+}
+
 /* Returns TRUE iff the cache would need to be filled with data coming
from the file.  That is, either the cache is empty or full or the
current line is empty.  Note that if the cache is full, it would
diff --git a/gcc/input.h b/gcc/input.h
index a5863eb9e091..fb3ef120607d 100644
--- a/gcc/input.h
+++ b/gcc/input.h
@@ -138,6 +138,9 @@ class file_cache
   file_cache ();
   ~file_cache ();
 
+  void dump (FILE *out, int indent) const;
+  void DEBUG_FUNCTION dump () const;
+
   file_cache_slot *lookup_or_add_file (const char *file_path);
   void forcibly_evict_file (const char *file_path);
 
-- 
2.26.3

[pushed: r15-6284] sarif-replay: quote source from artifact contents [PR117943]

[David Malcolm]

The diagnostic source-quoting machinery uses class file_cache
implemented in gcc/input.cc for (re)reading the source when
issuing diagnostics.

When sarif-replay issues a saved diagnostic it might be running
in a different path to where the .sarif file was captured, or
on an entirely different machine.

Previously such invocations would lead to the source-quoting
silently failing, even if the content of the file is recorded
in the .sarif file in the artifact "contents" property (which
gcc populates when emitting .sarif output).

This patch:
- adds the ability for slots in file_cache to be populated from memory
rather than from the filesystem
- exposes it in libgdiagnostics via a new entrypoint
- uses this in sarif-replay for any artifacts with a "contents"
property, so that source-quoting uses that rather than trying to read
from the path on the filesystem

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-6284-g778336e0e4f257.

gcc/ChangeLog:
PR sarif-replay/117943
* doc/libgdiagnostics/topics/physical-locations.rst
(diagnostic_manager_new_file): Drop "const" from return type.
* doc/libgdiagnostics/tutorial/02-physical-locations.rst: Drop
"const" from "main_file" decl.
* input.cc (file_cache::add_buffered_content): New.
(file_cache_slot::set_content): New.
(file_cache_slot::dump): Use m_file_path being null rather than
m_fp to determine empty slots.  Dump m_fp.
(find_end_of_line): Drop "const" from return type and param.  Add
forward decl.
(file_cache_slot::get_next_line): Fix "const"-ness.
(selftest::test_reading_source_buffer): New.
(selftest::input_cc_tests): Call it.
* input.h (file_cache::add_buffered_content): New decl.
* libgdiagnostics++.h (class file): Drop const-ness from m_inner.
(file::set_buffered_content): New.
* libgdiagnostics.cc (class content_buffer): New.
(diagnostic_file::diagnostic_file): Add "mgr" param.
(diagnostic_file::get_content): New.
(diagnostic_file::set_buffered_content): New.
(diagnostic_file::m_mgr): New.
(diagnostic_file::m_content): New.
(diagnostic_manager::new_file): Drop const-ness.  Pass *this to
ctor.
(diagnostic_file::set_buffered_content): New.
(diagnostic_manager_new_file): Drop "const" from return type.
(diagnostic_file_set_buffered_content): New entrypoint.
(diagnostic_manager_debug_dump_file): Dump the content size,
if any.
* libgdiagnostics.h (diagnostic_manager_new_file): Drop "const"
from return type.
(diagnostic_file_set_buffered_content): New decl.
* libgdiagnostics.map (diagnostic_file_set_buffered_content): New
symbol.
* libsarifreplay.cc (sarif_replayer::m_artifacts_arr): Convert
from json::value to json::array.
(sarif_replayer::handle_run_obj): Call handle_artifact_obj
on all artifacts.
(sarif_replayer::handle_artifact_obj): New.

gcc/testsuite/ChangeLog:
PR sarif-replay/117943
* sarif-replay.dg/2.1.0-valid/error-with-note.sarif: Update
expected output to include quoted source code and underlines.
* sarif-replay.dg/2.1.0-valid/signal-1.c.moved.sarif: New test.
* sarif-replay.dg/2.1.0-valid/signal-1.c.sarif: Update expected
output to include quoted source code and underlines.

Signed-off-by: David Malcolm 
---
 .../topics/physical-locations.rst |   6 +-
 .../tutorial/02-physical-locations.rst|   2 +-
 gcc/input.cc  |  97 +++-
 gcc/input.h   |   4 +
 gcc/libgdiagnostics++.h   |  16 +-
 gcc/libgdiagnostics.cc|  82 +--
 gcc/libgdiagnostics.h |  13 +-
 gcc/libgdiagnostics.map   |   1 +
 gcc/libsarifreplay.cc |  74 +-
 .../2.1.0-valid/error-with-note.sarif |   5 +-
 .../2.1.0-valid/signal-1.c.moved.sarif| 220 ++
 .../2.1.0-valid/signal-1.c.sarif  |  27 ++-
 12 files changed, 510 insertions(+), 37 deletions(-)
 create mode 100644 
gcc/testsuite/sarif-replay.dg/2.1.0-valid/signal-1.c.moved.sarif

diff --git a/gcc/doc/libgdiagnostics/topics/physical-locations.rst 
b/gcc/doc/libgdiagnostics/topics/physical-locations.rst
index cf10f5315c8e..692dac9bc188 100644
--- a/gcc/doc/libgdiagnostics/topics/physical-locations.rst
+++ b/gcc/doc/libgdiagnostics/topics/physical-locations.rst
@@ -35,9 +35,9 @@ locations.
 
A :type:`diagnostic_file` is an opaque type describing a particular input 
file.
 
-.. function:: const diagnostic_file * diagnostic_manager_new_file 
(diagnostic_manager *diag_mgr, \
-   const char 
*name, \
-  

[pushed: r15-6285] libgdiagnostics: consolidate logical locations

[David Malcolm]

This patch updates diagnostic_manager_new_logical_location so
that repeated calls with the same input values yield the same
instance of diagnostic_logical_location.

Doing so allows the path-printing logic to properly consolidate runs of
events, whereas previously it could treat each event as having a
distinct logical location, and thus require them to be printed
separately; this greatly improves the output of sarif-replay when
displaying execution paths.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-6285-g2af541920787e3.

gcc/ChangeLog:
* doc/libgdiagnostics/topics/logical-locations.rst
(diagnostic_manager_new_logical_location): Add note about repeated
calls.
* libgdiagnostics.cc: Define INCLUDE_MAP.
(class owned_nullable_string): Add copy ctor and move ctor.
(owned_nullable_string::operator<): New.
(diagnostic_logical_location::operator<): New.
(diagnostic_manager::new_logical_location): Use m_logical_locs to
"uniquify" instances, converting it to a std::map.
(diagnostic_manager::logical_locs_map_t): New typedef.
(diagnostic_manager::t m_logical_locs): Convert from a std::vector
to a std::map.
(diagnostic_execution_path::same_function_p): Update comment.

gcc/testsuite/ChangeLog:
* libgdiagnostics.dg/test-logical-location.c: Include .
Verify that creating a diagnostic_logical_location with equal
values yields the same instance.
* sarif-replay.dg/2.1.0-valid/malloc-vs-local-4.c.sarif: New test.
* sarif-replay.dg/2.1.0-valid/signal-1.c.moved.sarif: Update
expected output to show logical location and for consolidation of
events into runs.
* sarif-replay.dg/2.1.0-valid/signal-1.c.sarif: Likewise.
* sarif-replay.dg/2.1.0-valid/spec-example-4.sarif: Likewise.

Signed-off-by: David Malcolm 
---
 .../topics/logical-locations.rst  |   6 +
 gcc/libgdiagnostics.cc|  58 ++-
 .../test-logical-location.c   |  13 +
 .../2.1.0-valid/malloc-vs-local-4.c.sarif | 402 ++
 .../2.1.0-valid/signal-1.c.moved.sarif|  25 +-
 .../2.1.0-valid/signal-1.c.sarif  |  25 +-
 .../2.1.0-valid/spec-example-4.sarif  |  11 +-
 7 files changed, 497 insertions(+), 43 deletions(-)
 create mode 100644 
gcc/testsuite/sarif-replay.dg/2.1.0-valid/malloc-vs-local-4.c.sarif

diff --git a/gcc/doc/libgdiagnostics/topics/logical-locations.rst 
b/gcc/doc/libgdiagnostics/topics/logical-locations.rst
index 85900b6344f2..70bbb00c486d 100644
--- a/gcc/doc/libgdiagnostics/topics/logical-locations.rst
+++ b/gcc/doc/libgdiagnostics/topics/logical-locations.rst
@@ -88,6 +88,12 @@ source location
the SARIF logicalLocation ``decoratedName`` property
(SARIF v2.1.0 `§3.33.6 
`_).
 
+   Repeated calls to :func:`diagnostic_manager_new_logical_location` with
+   "equal" input values on the same :type:`diagnostic_manager` will return
+   the same instance of :type:`diagnostic_logical_location`.  "Equal" here
+   includes different string buffers that compare as equal with
+   :func:``strcmp`.
+
 .. function:: void diagnostic_manager_debug_dump_logical_location (const 
diagnostic_manager *diag_mgr, \
const 
diagnostic_logical_location *loc, \
FILE *out)
diff --git a/gcc/libgdiagnostics.cc b/gcc/libgdiagnostics.cc
index 00f8fefe838e..126ba747f796 100644
--- a/gcc/libgdiagnostics.cc
+++ b/gcc/libgdiagnostics.cc
@@ -18,6 +18,7 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #include "config.h"
+#define INCLUDE_MAP
 #define INCLUDE_VECTOR
 #include "system.h"
 #include "coretypes.h"
@@ -43,6 +44,15 @@ public:
   : m_str (str ? ::xstrdup (str) : nullptr)
   {
   }
+  owned_nullable_string (const owned_nullable_string &other)
+  : m_str (other.xstrdup ())
+  {
+  }
+  owned_nullable_string (owned_nullable_string &&other)
+  {
+m_str = other.m_str;
+other.m_str = nullptr;
+  }
 
   ~owned_nullable_string ()
   {
@@ -62,6 +72,16 @@ public:
 return m_str ? ::xstrdup (m_str) : nullptr;
   }
 
+  bool
+  operator< (const owned_nullable_string &other) const
+  {
+if (m_str && other.m_str)
+  return strcmp (m_str, other.m_str) < 0;
+if (m_str == nullptr && other.m_str != nullptr)
+  return true;
+return false;
+  }
+
 private:
   char *m_str;
 };
@@ -205,6 +225,23 @@ struct diagnostic_logical_location : public 
logical_location
 return label_text::borrow (m_short_name.get_str ());
   }
 
+  bool
+  operator< (const diagnostic_logical_location &other) const
+  {
+if (m_kind < other.m_kind)
+  return true;
+if (m_parent < other.m_

Re: [PATCH 2/5] LoongArch: Add bit reverse operations

[Xi Ruoyao]

On Tue, 2024-12-17 at 11:27 +0800, Lulu Cheng wrote:
> 在 2024/12/16 下午9:20, Xi Ruoyao 写道:
> /* snip */
> > +;; For HImode it's a little complicated...
> > +(define_expand "rbithi"
> I didn't find rtithi's template description. Are there any test cases
> ?

No, it's not a standard name.  I just used the same name as AArch64. 
And due to PR50481 is unimplemented yet, there's no way to directly test
it :(.

The functionality can be tested with the existing test case,
gcc/testsuite/gcc.dg/torture/crc-coremark32-data16.c, with the next
patch (adding crc_revsi4) applied.  The generated code uses the
bitrev instruction to reverse bits:

bitrev.d$r13,$r4
bitrev.w$r5,$r5
srli.d  $r13,$r13,48

I.e. r5 will contain the 32-bit reversal of the original value, and r13
will contain the 16-bit reversal of r4.

This is a "dg-do run" test so the correctness is already verified at
runtime (I've ran the regression test with the entire series applied).

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

Re: [PATCH 2/5] LoongArch: Add bit reverse operations

[Lulu Cheng]

在 2024/12/17 下午12:30, Xi Ruoyao 写道:

On Tue, 2024-12-17 at 11:27 +0800, Lulu Cheng wrote:

在 2024/12/16 下午9:20, Xi Ruoyao 写道:
/* snip */

+;; For HImode it's a little complicated...
+(define_expand "rbithi"

I didn't find rtithi's template description. Are there any test cases
?

No, it's not a standard name.  I just used the same name as AArch64.
And due to PR50481 is unimplemented yet, there's no way to directly test
it :(.


Bitreverse is a standard operation. if  "define_expand "rbithi"" 
implementated using


bitreverse, will it trigger optimization in some cases?

If so, can we add an operation here?



The functionality can be tested with the existing test case,
gcc/testsuite/gcc.dg/torture/crc-coremark32-data16.c, with the next
patch (adding crc_revsi4) applied.  The generated code uses the
bitrev instruction to reverse bits:

 bitrev.d$r13,$r4
 bitrev.w$r5,$r5
 srli.d  $r13,$r13,48

I.e. r5 will contain the 32-bit reversal of the original value, and r13
will contain the 16-bit reversal of r4.

This is a "dg-do run" test so the correctness is already verified at
runtime (I've ran the regression test with the entire series applied).

Re: The COBOL front end, in 8 notes

[Joseph Myers]

On Sat, 14 Dec 2024, Iain Sandoe wrote:

> 1) to introduce new build dependencies on:
>   - bison (we normally commit generated files to the repo not expect the 
> end-user
>to need bison installed).
>   - a version of gm4 that recognises —gnu

We don't commit bison-generated files.  (We don't currently have any Bison 
parsers in the repository, but certainly we don't commit gengtype-lex's 
files generated by Flex.)  Rather, we make sure that 
--enable-generated-files-in-srcdir causes those files to go in the source 
directory so release (not snapshot) tarballs don't need Bison.

However, if introducing a Bison dependency, it needs to be documented 
(being specific about version requirements) in install.texi.

If m4 is needed for something other than regenerating configure scripts, 
or if the requirements on m4 for COBOL are stricter than the existing 
documented "GNU m4 version 1.4.6 (or later)", again that needs documenting 
in install.texi.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: The COBOL front end, in 8 notes + toplevel patch

[Joseph Myers]

On Mon, 16 Dec 2024, Matthias Klose wrote:

> On 14.12.24 15:38, Matthias Klose wrote:
> > I tried to use the patches to build binary packages for Debian. Found some
> > issues:
> 
> tried to build libgcobol on more architectures, please find the attached patch
> to disable building libgcobol on some architectures.

Enabling on x86_64-*-linux* and disabling on i?86-*-linux* is inherently 
suspect since the difference between those is only about what the default 
multilib is, and says nothing about the multilib used for a particular 
compilation of libgcobol.  (Of course we first need to fix multilib 
support for libgcobol if that isn't working correctly - all target 
libraries in GCC need proper multilib support.)

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH 2/5] LoongArch: Add bit reverse operations

[Lulu Cheng]

在 2024/12/16 下午9:20, Xi Ruoyao 写道:
/* snip */

+;; For HImode it's a little complicated...
+(define_expand "rbithi"

I didn't find rtithi's template description. Are there any test cases ?

+  [(match_operand:HI 0 "register_operand")
+   (match_operand:HI 1 "register_operand")]
+  ""
+  {
+rtx t = gen_reg_rtx (word_mode);
+
+/* Oh, using paradoxical subreg.  I learnt the trick from RISC-V,
+   hoping we won't be blown up altogether one day.  */
+emit_insn (gen_rbit(word_mode, t,
+   gen_lowpart (word_mode, operands[1])));
+t = expand_simple_binop (word_mode, LSHIFTRT, t,
+GEN_INT (GET_MODE_BITSIZE (word_mode) - 16),
+NULL_RTX, false, OPTAB_DIRECT);
+
+t = gen_lowpart (HImode, t);
+SUBREG_PROMOTED_VAR_P (t) = 1;
+SUBREG_PROMOTED_SET (t, SRP_UNSIGNED);
+emit_move_insn (operands[0], t);
+
+DONE;
+  })
+
  (define_insn "@stack_tie"
[(set (mem:BLK (scratch))
(unspec:BLK [(match_operand:X 0 "register_operand" "r")

Re: [PATCH v2] RISC-V: Fix ICE for unrecognizable insn `UNSPEC_VSETVL` for XTheadVector

[Jin Ma]

> So I would just do:
> 
> 
> tmp = force_reg (word_mode, x);
> add_input_operand (TYPE_MODE (TREE_TYPE (arg)), tmp);
> 
> In the thead specific code. That generates the initial code correctly.
> At that point we just need to make sure nothing like combine, cprop, etc
> propagates the constant into the vsetvl. The way to prevent that is
> with the operand predicates on the vsetvl insns.
>
> jeff
Thank you so much for your patient guidance. I understand what you mean and
will update the patch accordingly :)
BR
Jin

[PATCH] testsuite: arm: Add -mtune to all arm_cpu_* effective targets

[Torbjörn SVENSSON]

Ok for trunk?

--

Fixes Linaro CI reported regression on r15-6164-gbdf75257aad2 in
https://linaro.atlassian.net/browse/GNU-1463.

gcc/testsuite/ChangeLog:

* lib/target-supports.exp: Added corresponding -mtune= option
for each fo the arm_cpu_* effective targets.

Signed-off-by: Torbjörn SVENSSON 
---
 gcc/testsuite/lib/target-supports.exp | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index fe2970e024b..34a9b4d3816 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5958,18 +5958,18 @@ foreach { armfunc armflag armdefs } {
 # This table should only be used to set -mcpu= (and associated
 # flags).  See above for setting -march=.
 foreach { armfunc armflag armdefs } {
-   xscale_arm "-mcpu=xscale -mfloat-abi=soft -marm" "__XSCALE__ && 
!__thumb__"
-   cortex_a57 "-mcpu=cortex-a57" __ARM_ARCH_8A__
-   cortex_m0 "-mcpu=cortex-m0 -mfloat-abi=soft -mthumb" 
"__ARM_ARCH_6M__ && __thumb__"
-   cortex_m0_small "-mcpu=cortex-m0.small-multiply -mfloat-abi=soft 
-mthumb" "__ARM_ARCH_6M__ && __thumb__"
-   cortex_m0plus_small "-mcpu=cortex-m0plus.small-multiply 
-mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ && __thumb__"
-   cortex_m1_small "-mcpu=cortex-m1.small-multiply -mfloat-abi=soft 
-mthumb" "__ARM_ARCH_6M__ && __thumb__"
-   cortex_m3 "-mcpu=cortex-m3 -mfloat-abi=soft -mthumb" 
"__ARM_ARCH_7M__"
-   cortex_m4 "-mcpu=cortex-m4 -mfpu=auto -mthumb" "__ARM_ARCH_7EM__"
-   cortex_m4_hard "-mcpu=cortex-m4 -mfpu=auto -mfloat-abi=hard 
-mthumb" "__ARM_ARCH_7EM__"
-   cortex_m7 "-mcpu=cortex-m7 -mfpu=auto -mthumb" "__ARM_ARCH_7EM__"
-   cortex_m23 "-mcpu=cortex-m23 -mfloat-abi=soft -mthumb" 
"__ARM_ARCH_8M_BASE__  && __thumb__"
-   cortex_m55 "-mcpu=cortex-m55 -mfpu=auto -mthumb" 
"__ARM_ARCH_8M_MAIN__  && __thumb__"
+   xscale_arm "-mcpu=xscale -mtune=xscale -mfloat-abi=soft -marm" 
"__XSCALE__ && !__thumb__"
+   cortex_a57 "-mcpu=cortex-a57 -mtune=cortex-a57" __ARM_ARCH_8A__
+   cortex_m0 "-mcpu=cortex-m0 -mtune=cortex-m0 -mfloat-abi=soft 
-mthumb" "__ARM_ARCH_6M__ && __thumb__"
+   cortex_m0_small "-mcpu=cortex-m0.small-multiply 
-mtune=cortex-m0.small-multiply -mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ && 
__thumb__"
+   cortex_m0plus_small "-mcpu=cortex-m0plus.small-multiply 
-mtune=cortex-m0plus.small-multiply -mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ 
&& __thumb__"
+   cortex_m1_small "-mcpu=cortex-m1.small-multiply 
-mtune=cortex-m1.small-multiply -mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ && 
__thumb__"
+   cortex_m3 "-mcpu=cortex-m3 -mtune=cortex-m3 -mfloat-abi=soft 
-mthumb" "__ARM_ARCH_7M__"
+   cortex_m4 "-mcpu=cortex-m4 -mtune=cortex-m4 -mfpu=auto -mthumb" 
"__ARM_ARCH_7EM__"
+   cortex_m4_hard "-mcpu=cortex-m4 -mtune=cortex-m4 -mfpu=auto 
-mfloat-abi=hard -mthumb" "__ARM_ARCH_7EM__"
+   cortex_m7 "-mcpu=cortex-m7 -mtune=cortex-m7 -mfpu=auto -mthumb" 
"__ARM_ARCH_7EM__"
+   cortex_m23 "-mcpu=cortex-m23 -mtune=cortex-m23 -mfloat-abi=soft 
-mthumb" "__ARM_ARCH_8M_BASE__  && __thumb__"
+   cortex_m55 "-mcpu=cortex-m55 -mtune=cortex-m55 -mfpu=auto -mthumb" 
"__ARM_ARCH_8M_MAIN__  && __thumb__"
} {
 eval [string map [list FUNC $armfunc FLAG $armflag DEFS $armdefs ] {
proc check_effective_target_arm_cpu_FUNC_ok { } {
-- 
2.25.1

[PATCH] c++: ICE initializing array of aggrs [PR117985]

[Marek Polacek]

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

-- >8 --
This crash started with my r12-7803 but I believe the problem lies
elsewhere.

build_vec_init has cleanup_flags whose purpose is -- if I grok this
correctly -- to avoid destructing an object multiple times.  Let's
say we are initializing an array of A.  Then we might end up in
a scenario similar to initlist-eh1.C:

  try
{
  call A::A in a loop
  // #0
  try
{
  call a fn using the array
}
  finally
{
  // #1
  call A::~A in a loop
}
}
  catch
{
  // #2
  call A::~A in a loop
}

cleanup_flags makes us emit a statement like

  D.3048 = 2;

at #0 to disable performing the cleanup at #2, since #1 will take
care of the destruction of the array.

But if we are not emitting the loop because we can use a constant
initializer (and use a single { a, b, ...}), we shouldn't generate
the statement resetting the iterator to its initial value.  Otherwise
we crash in gimplify_var_or_parm_decl because it gets the stray decl
D.3048.

PR c++/117985

gcc/cp/ChangeLog:

* init.cc (build_vec_init): Clear CLEANUP_FLAGS if we're not
generating the loop.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-array23.C: New test.
* g++.dg/cpp0x/initlist-array24.C: New test.
---
 gcc/cp/init.cc|  4 +++
 gcc/testsuite/g++.dg/cpp0x/initlist-array23.C | 28 +++
 gcc/testsuite/g++.dg/cpp0x/initlist-array24.C | 27 ++
 3 files changed, 59 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-array24.C

diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index ae516407c92..5dcb24ef735 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -5109,6 +5109,10 @@ build_vec_init (tree base, tree maxindex, tree init,
 {
   if (!saw_non_const)
{
+ /* If we're not generating the loop, we don't need to reset the
+iterator.  */
+ if (cleanup_flags)
+   vec_safe_truncate (*cleanup_flags, 0);
  tree const_init = build_constructor (atype, const_vec);
  return build2 (INIT_EXPR, atype, obase, const_init);
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-array23.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
new file mode 100644
index 000..cda2afb9fcc
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
@@ -0,0 +1,28 @@
+// PR c++/117985
+// { dg-do compile { target c++11 } }
+
+struct _Vector_impl {
+  constexpr
+_Vector_impl() {}
+};
+struct _Vector_base {
+  ~_Vector_base();
+  _Vector_impl _M_impl;
+};
+struct vector : private _Vector_base {};
+struct string {
+  string();
+};
+struct VEC {
+  vector pane{};
+};
+struct FOO {
+  VEC screen[1]{};
+  string debug_name;
+};
+
+int
+main ()
+{
+  FOO{};
+}
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-array24.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist-array24.C
new file mode 100644
index 000..7dda00d5c0b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-array24.C
@@ -0,0 +1,27 @@
+// PR c++/117985
+// { dg-do compile { target c++20 } }
+
+struct _Vector_impl {
+  constexpr _Vector_impl() {}
+};
+struct _Vector_base {
+  constexpr ~_Vector_base() {}
+  _Vector_impl _M_impl;
+};
+struct vector : private _Vector_base {};
+struct string {
+  string();
+};
+struct VEC {
+  vector pane{};
+};
+struct FOO {
+  VEC screen[1]{};
+  string debug_name;
+};
+
+int
+main ()
+{
+  FOO{};
+}

base-commit: 56f1863ade1bf416e09da305615ecb2ae04602a8
-- 
2.47.1

Re: [PATCH] COBOL 4/8 cbl: other supporting C++ files

[Joseph Myers]

On Thu, 12 Dec 2024, James K. Lowden wrote:

> +switch(e->type) {
> +case SymFilename:
> +  asprintf(&s, "%4zu %-18s %s", e->program,
> +"Filename", e->elem.filename);
> +  break;

You need to check for errors from allocation functions such as asprintf 
before using the results.  In some places you're checking, but not here.  
I stringly advise using xasprintf from libiberty everywhere you're 
currently using asprintf, to avoid needing to hardcode checks at each call 
site.

-- 
Joseph S. Myers
josmy...@redhat.com

[PATCH] LoongArch: Implement TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS hook

[Jiahao Xu]

The hook changes the allocno class to either FP_REGS or GR_REGS depending on
the mode of the register. This results in better register allocation overall,
fewer spills and reduced codesize - particularly in SPEC2017 lbm.

gcc/ChangeLog:

* config/loongarch/loongarch.cc
(loongarch_ira_change_pseudo_allocno_class): New function.
(TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS): Define macro.
---
 gcc/config/loongarch/loongarch.cc | 38 +++
 1 file changed, 38 insertions(+)

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 861558f07bc..125ecc26c9c 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -6989,6 +6989,40 @@ loongarch_secondary_reload (bool in_p ATTRIBUTE_UNUSED, 
rtx x,
   return NO_REGS;
 }
 
+/* Implement TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS.
+
+   The register allocator chooses ALL_REGS if FP_REGS and GR_REGS have the
+   same cost - even if ALL_REGS has a much higher cost.  ALL_REGS is also used
+   if the cost of both FP_REGS and GR_REGS is lower than the memory cost (in
+   this case the best class is the lowest cost one).  Using ALL_REGS
+   irrespectively of itself cost results in bad allocations with many redundant
+   int<->FP moves which are expensive on various cores.
+
+   To avoid this we don't allow ALL_REGS as the allocno class, but force a
+   decision between FP_REGS and GR_REGS.  We use the allocno class if it isn't
+   ALL_REGS.  Similarly, use the best class if it isn't ALL_REGS.  Otherwise 
Set
+   the allocno class depending on the mode.
+
+   This change has a similar effect to increasing the cost of FPR->GPR register
+   moves for integer modes so that they are higher than the cost of memory but
+   changing the allocno class is more reliable.  */
+
+static reg_class_t
+loongarch_ira_change_pseudo_allocno_class (int regno, reg_class_t 
allocno_class,
+  reg_class_t best_class)
+{
+  enum machine_mode mode;
+
+  if (allocno_class != ALL_REGS)
+return allocno_class;
+
+  if (best_class != ALL_REGS)
+return best_class;
+
+  mode = PSEUDO_REGNO_MODE (regno);
+  return FLOAT_MODE_P (mode) || VECTOR_MODE_P (mode) ? FP_REGS : GR_REGS;
+}
+
 /* Implement TARGET_VALID_POINTER_MODE.  */
 
 static bool
@@ -11148,6 +11182,10 @@ loongarch_asm_code_end (void)
 #undef TARGET_SECONDARY_RELOAD
 #define TARGET_SECONDARY_RELOAD loongarch_secondary_reload
 
+#undef TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS
+#define TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS \
+  loongarch_ira_change_pseudo_allocno_class
+
 #undef  TARGET_HAVE_SPECULATION_SAFE_VALUE
 #define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
 
-- 
2.20.1

[PATCH] LoongArch: Implement vector cbranch optab for LSX and LASX

[Jiahao Xu]

In order to support vectorization of loops with multiple exits, this
patch adds the implementation of the conditional branch optab for
LoongArch LSX/LASX instructions.

This patch causes the gen-vect-{2,25}.c tests to fail.  This is because
the support for vectorizing loops with multiple exits has vectorized
the loop checking the results.  The failure is due to an issue in the
test case's own implementation.

gcc/ChangeLog:

* config/loongarch/lasx.md (cbranch4): New expander.
* config/loongarch/lsx.md (cbranch4): New expander.

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_vect_early_break_hw,
check_effective_target_vect_early_break): Support LoongArch LSX.
* gcc.target/loongarch/vector/lasx/lasx-vseteqz.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vseteqz.c: New test.

Co-authored-by: Deng Jianbo 
---
 gcc/config/loongarch/lasx.md  | 29 +++
 gcc/config/loongarch/lsx.md   | 29 +++
 .../loongarch/vector/lasx/lasx-vseteqz.c  | 14 +
 .../loongarch/vector/lsx/lsx-vseteqz.c| 15 ++
 gcc/testsuite/lib/target-supports.exp |  2 ++
 5 files changed, 89 insertions(+)
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-vseteqz.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vseteqz.c

diff --git a/gcc/config/loongarch/lasx.md b/gcc/config/loongarch/lasx.md
index 2f485de8a65..87e47ff479d 100644
--- a/gcc/config/loongarch/lasx.md
+++ b/gcc/config/loongarch/lasx.md
@@ -4952,3 +4952,32 @@
   emit_insn (gen_addv8si3 (operands[0], t3, operands[3]));
   DONE;
 })
+
+(define_expand "cbranch4"
+ [(set (pc)
+   (if_then_else
+ (match_operator 0 "equality_operator"
+   [(match_operand:ILASX 1 "register_operand")
+(match_operand:ILASX 2 "reg_or_vector_same_val_operand")])
+ (label_ref (match_operand 3 ""))
+ (pc)))]
+ "ISA_HAS_LASX"
+{
+  RTX_CODE code = GET_CODE (operands[0]);
+  rtx tmp = operands[1];
+  rtx const0 = CONST0_RTX (SImode);
+
+  /* If comparing against a non-zero vector we have to do a comparison first
+so we can have a != 0 comparison with the result.  */
+  if (operands[2] != CONST0_RTX (mode))
+{
+  rtx tmp = gen_reg_rtx (mode);
+  emit_insn (gen_xor3 (tmp, operands[1], operands[2]));
+}
+
+  if (code == NE)
+emit_jump_insn (gen_lasx_xbnz_v_b (operands[3], tmp, const0));
+  else
+emit_jump_insn (gen_lasx_xbz_v_b (operands[3], tmp, const0));
+  DONE;
+})
diff --git a/gcc/config/loongarch/lsx.md b/gcc/config/loongarch/lsx.md
index e51bd18d511..36d817be463 100644
--- a/gcc/config/loongarch/lsx.md
+++ b/gcc/config/loongarch/lsx.md
@@ -4298,3 +4298,32 @@
   [(set (match_dup 0)
(vec_duplicate:V2DI (match_dup 1)))]
   "")
+
+(define_expand "cbranch4"
+ [(set (pc)
+   (if_then_else
+ (match_operator 0 "equality_operator"
+   [(match_operand:ILSX 1 "register_operand")
+(match_operand:ILSX 2 "reg_or_vector_same_val_operand")])
+ (label_ref (match_operand 3 ""))
+ (pc)))]
+ "ISA_HAS_LSX"
+{
+  RTX_CODE code = GET_CODE (operands[0]);
+  rtx tmp = operands[1];
+  rtx const0 = CONST0_RTX (SImode);
+
+  /* If comparing against a non-zero vector we have to do a comparison first
+so we can have a != 0 comparison with the result.  */
+  if (operands[2] != CONST0_RTX (mode))
+{
+  tmp = gen_reg_rtx (mode);
+  emit_insn (gen_xor3 (tmp, operands[1], operands[2]));
+}
+
+  if (code == NE)
+emit_jump_insn (gen_lsx_bnz_v_b (operands[3], tmp, const0));
+  else
+emit_jump_insn (gen_lsx_bz_v_b (operands[3], tmp, const0));
+  DONE;
+})
diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-vseteqz.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-vseteqz.c
new file mode 100644
index 000..1f69a80a784
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-vseteqz.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -mlasx" } */
+/* { dg-final { scan-assembler "\txvset.*.v\t" } } */
+/* { dg-final { scan-assembler  "bcnez" } } */
+
+int
+foo (int N)
+{
+  for (int i = 0; i <= N; i++)
+if (i * i == N)
+  return i;
+  return -1;
+}
+
diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vseteqz.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vseteqz.c
new file mode 100644
index 000..2536bb7945e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vseteqz.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -mlsx" } */
+/* { dg-final { scan-assembler "\tvset.*.v\t" } } */
+/* { dg-final { scan-assembler  "bcnez" } } */
+
+int
+foo (int N)
+{
+  for (int i = 0; i <= N; i++)
+if (i * i == N)
+  return i;
+
+  return -1;
+}
+
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index fe2970e024b..cb9c23d

[PATCH] LoongArch: Support immediate_operand for vec_cmp

[Jiahao Xu]

We can't vectorize the code into instructions like vslti.w that compare
with immediate_operand, because we miss immediate_operand support for
integer comparisons.

gcc/ChangeLog:

* config/loongarch/lasx.md: Support immediate_operand.
* config/loongarch/loongarch.cc (loongarch_expand_lsx_cmp):
Ensure vector comparison instructions support CMP_OP1.
* config/loongarch/lsx.md: Support immediate_operand.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lasx/lasx-vcond-3.c: New test.
---
 gcc/config/loongarch/lasx.md  |  4 +-
 gcc/config/loongarch/loongarch.cc |  5 ++
 gcc/config/loongarch/lsx.md   |  4 +-
 .../loongarch/vector/lasx/lasx-vcond-3.c  | 81 +++
 4 files changed, 90 insertions(+), 4 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-vcond-3.c

diff --git a/gcc/config/loongarch/lasx.md b/gcc/config/loongarch/lasx.md
index 90778dd8ff9..2f485de8a65 100644
--- a/gcc/config/loongarch/lasx.md
+++ b/gcc/config/loongarch/lasx.md
@@ -1369,7 +1369,7 @@
   [(set (match_operand: 0 "register_operand")
(match_operator 1 ""
  [(match_operand:LASX 2 "register_operand")
-  (match_operand:LASX 3 "register_operand")]))]
+  (match_operand:LASX 3 "reg_or_vector_same_simm5_operand")]))]
   "ISA_HAS_LASX"
 {
   loongarch_expand_vec_cmp (operands);
@@ -1380,7 +1380,7 @@
   [(set (match_operand: 0 "register_operand")
(match_operator 1 ""
  [(match_operand:ILASX 2 "register_operand")
-  (match_operand:ILASX 3 "register_operand")]))]
+  (match_operand:ILASX 3 "reg_or_vector_same_uimm5_operand")]))]
   "ISA_HAS_LASX"
 {
   loongarch_expand_vec_cmp (operands);
diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 125ecc26c9c..58129295b89 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -10412,6 +10412,9 @@ loongarch_expand_lsx_cmp (rtx dest, enum rtx_code cond, 
rtx op0, rtx op1)
case GT:
case GEU:
case GTU:
+ /* Only supports reg-reg comparison.  */
+ if (!register_operand (op1, cmp_mode))
+   op1 = force_reg (cmp_mode, op1);
  std::swap (op0, op1);
  cond = swap_condition (cond);
  break;
@@ -10427,6 +10430,8 @@ loongarch_expand_lsx_cmp (rtx dest, enum rtx_code cond, 
rtx op0, rtx op1)
 case E_V2DFmode:
 case E_V8SFmode:
 case E_V4DFmode:
+  if (!register_operand (op1, cmp_mode))
+   op1 = force_reg (cmp_mode, op1);
   loongarch_emit_binary (cond, dest, op0, op1);
   break;
 
diff --git a/gcc/config/loongarch/lsx.md b/gcc/config/loongarch/lsx.md
index 2466d8c87be..e51bd18d511 100644
--- a/gcc/config/loongarch/lsx.md
+++ b/gcc/config/loongarch/lsx.md
@@ -512,7 +512,7 @@
   [(set (match_operand: 0 "register_operand")
(match_operator 1 ""
  [(match_operand:LSX 2 "register_operand")
-  (match_operand:LSX 3 "register_operand")]))]
+  (match_operand:LSX 3 "reg_or_vector_same_simm5_operand")]))]
   "ISA_HAS_LSX"
 {
   loongarch_expand_vec_cmp (operands);
@@ -523,7 +523,7 @@
   [(set (match_operand: 0 "register_operand")
(match_operator 1 ""
  [(match_operand:ILSX 2 "register_operand")
-  (match_operand:ILSX 3 "register_operand")]))]
+  (match_operand:ILSX 3 "reg_or_vector_same_uimm5_operand")]))]
   "ISA_HAS_LSX"
 {
   loongarch_expand_vec_cmp (operands);
diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-vcond-3.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-vcond-3.c
new file mode 100644
index 000..0c3d9de2580
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-vcond-3.c
@@ -0,0 +1,81 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -ftree-vectorize -fno-unroll-loops -fno-vect-cost-model 
-mlasx" } */
+
+#include 
+
+#define DEF_VCOND_VAR(DATA_TYPE, CMP_TYPE, COND, SUFFIX, IMM)  \
+  void __attribute__ ((noinline, noclone)) \
+  vcond_var_##CMP_TYPE##_##SUFFIX (DATA_TYPE *__restrict__ r,  \
+  DATA_TYPE *__restrict__ x,   \
+  DATA_TYPE *__restrict__ y,   \
+  CMP_TYPE *__restrict__ a,\
+  int n)   \
+  {\
+for (int i = 0; i < n; i++)\
+  {\
+   DATA_TYPE xval = x[i], yval = y[i]; \
+   CMP_TYPE aval = a[i], bval = IMM;   \
+   r[i] = aval COND bval ? xval : yval;\
+  }\
+  }
+
+#define TEST_COND_VAR_SIGNED_ALL(T, COND, SUFFIX)  \
+  T (int8_t, int8_t, COND

Re: [PATCH] LoongArch: Implement vector cbranch optab for LSX and LASX

[Xi Ruoyao]

On Tue, 2024-12-17 at 10:41 +0800, Jiahao Xu wrote:

/* snip */

> +(define_expand "cbranch4"
> + [(set (pc)
> +   (if_then_else
> + (match_operator 0 "equality_operator"
> +   [(match_operand:ILASX 1 "register_operand")
> +    (match_operand:ILASX 2 "reg_or_vector_same_val_operand")])
> + (label_ref (match_operand 3 ""))
> + (pc)))]
> + "ISA_HAS_LASX"
> +{
> +  RTX_CODE code = GET_CODE (operands[0]);
> +  rtx tmp = operands[1];
> +  rtx const0 = CONST0_RTX (SImode);
> +
> +  /* If comparing against a non-zero vector we have to do a comparison first
> +    so we can have a != 0 comparison with the result.  */
> +  if (operands[2] != CONST0_RTX (mode))
> +    {
> +  rtx tmp = gen_reg_rtx (mode);
> +  emit_insn (gen_xor3 (tmp, operands[1], operands[2]));
> +    }
> +
> +  if (code == NE)
> +    emit_jump_insn (gen_lasx_xbnz_v_b (operands[3], tmp, const0));
> +  else
> +    emit_jump_insn (gen_lasx_xbz_v_b (operands[3], tmp, const0));
> +  DONE;
> +})

Do this in simd.md to avoid duplicating the same logic in lasx.md and
lsx.md?  Something like

+(define_expand "cbranch4"
+ [(set (pc)
+   (if_then_else
+ (match_operator 0 "equality_operator"
+   [(match_operand:IVEC 1 "register_operand")
+(match_operand:IVEC 2 "reg_or_vector_same_val_operand")])
+ (label_ref (match_operand 3 ""))
+ (pc)))]
+ ""
+{
+  RTX_CODE code = GET_CODE (operands[0]);
+  rtx tmp = operands[1];
+  rtx const0 = CONST0_RTX (SImode);
+
+  /* If comparing against a non-zero vector we have to do a comparison first
+so we can have a != 0 comparison with the result.  */
+  if (operands[2] != CONST0_RTX (mode))
+{
+  rtx tmp = gen_reg_rtx (mode);
+  emit_insn (gen_xor3 (tmp, operands[1], operands[2]));
+}
+
+  if (code == NE)
+emit_jump_insn (gen__bnz_v_b (operands[3], tmp, const0));
+  else
+emit_jump_insn (gen__bz_v_b (operands[3], tmp, const0));
+  DONE;
+})

(not really tested, just copied your code and modified in the mail
client to show the idea).

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

Re: [PATCH] LoongArch: Implement vector cbranch optab for LSX and LASX

[Jiahao Xu]

在 2024/12/17 10:58, Xi Ruoyao 写道:

On Tue, 2024-12-17 at 10:41 +0800, Jiahao Xu wrote:

/* snip */


+(define_expand "cbranch4"
+ [(set (pc)
+   (if_then_else
+ (match_operator 0 "equality_operator"
+   [(match_operand:ILASX 1 "register_operand")
+    (match_operand:ILASX 2 "reg_or_vector_same_val_operand")])
+ (label_ref (match_operand 3 ""))
+ (pc)))]
+ "ISA_HAS_LASX"
+{
+  RTX_CODE code = GET_CODE (operands[0]);
+  rtx tmp = operands[1];
+  rtx const0 = CONST0_RTX (SImode);
+
+  /* If comparing against a non-zero vector we have to do a comparison first
+    so we can have a != 0 comparison with the result.  */
+  if (operands[2] != CONST0_RTX (mode))
+    {
+  rtx tmp = gen_reg_rtx (mode);
+  emit_insn (gen_xor3 (tmp, operands[1], operands[2]));
+    }
+
+  if (code == NE)
+    emit_jump_insn (gen_lasx_xbnz_v_b (operands[3], tmp, const0));
+  else
+    emit_jump_insn (gen_lasx_xbz_v_b (operands[3], tmp, const0));
+  DONE;
+})

Do this in simd.md to avoid duplicating the same logic in lasx.md and
lsx.md?  Something like

+(define_expand "cbranch4"
+ [(set (pc)
+   (if_then_else
+ (match_operator 0 "equality_operator"
+   [(match_operand:IVEC 1 "register_operand")
+(match_operand:IVEC 2 "reg_or_vector_same_val_operand")])
+ (label_ref (match_operand 3 ""))
+ (pc)))]
+ ""
+{
+  RTX_CODE code = GET_CODE (operands[0]);
+  rtx tmp = operands[1];
+  rtx const0 = CONST0_RTX (SImode);
+
+  /* If comparing against a non-zero vector we have to do a comparison first
+so we can have a != 0 comparison with the result.  */
+  if (operands[2] != CONST0_RTX (mode))
+{
+  rtx tmp = gen_reg_rtx (mode);
+  emit_insn (gen_xor3 (tmp, operands[1], operands[2]));
+}
+
+  if (code == NE)
+emit_jump_insn (gen__bnz_v_b (operands[3], tmp, const0));
+  else
+emit_jump_insn (gen__bz_v_b (operands[3], tmp, const0));
+  DONE;
+})

(not really tested, just copied your code and modified in the mail
client to show the idea).


Looks good. I'll upload the revised version after testing.

Re: [gcc-wwwdocs PATCH] gcc-15: Mention new ISA and Diamond Rapids support for x86_64 backend

[Gerald Pfeifer]

On Mon, 25 Nov 2024, Jiang, Haochen wrote:
> I will do all of the changes with little tweak here. The "and" should 
> be added (actually changed the previous "or" to "and") between 
> -mtune=knl and -mtune=knm.

Thank you.

I just pushed a little follow up patch, see below.

Gerald


commit 7f4a4f377ca5e5fae8ffe6ab45a300799bd75b6f
Author: Gerald Pfeifer 
Date:   Tue Dec 17 16:54:47 2024 +0900

gcc-15: Copy edit Xeon Phi CPU support removal

diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 23866bde..1c690c4a 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -242,11 +242,11 @@ a work-in-progress.
 CMPccXADD, MOVRS, SHA512, SM3, SM4 and USER_MSR ISA extensions.
   
   Support for Xeon Phi CPUs (a.k.a. Knight Landing and Knight Mill) were
-  removed in GCC 15. GCC will no longer accepts -march=knl,
+  removed in GCC 15. GCC will no longer accept -march=knl,
   -march=knm, -mavx5124fmaps,
   -mavx5124vnniw, -mavx512er,
   -mavx512pf, -mprefetchwt1,
-  -mtune=knl and -mtune=knm compiler switches.
+  -mtune=knl, and -mtune=knm compiler switches.
   
 
 

Re: [PATCH] wwwdocs: Clarify DCO name/identity and (anonymous) pseudonym policy

[Gerald Pfeifer]

On Mon, 2 Dec 2024, Mark Wielaard wrote:
> Adjust the DCO text to match the broader community usage and
> clarifications around the use of real names, known identities and
> (anonymous) pseudonyms.
> 
> These changes clarify what was meant by "real name" and that it is not
> required to be a "legal name" or any other stronger requirement than a
> known identity that could be contacted to discuss the contribution as
> adopted by other communities like the linux kernel, elfutils, cncf and
> gentoo.
> 
> Also explain that the FSF assignment policy might be more appropriate
> when wanting to contribute using an anonymous pseudonym.

This looks fine to me personally, though I don't feel I can simply approve 
this wearing my wwwdocs hat (which is why I haven't responded earlier).

Jason, you have originally contributed this if I remember correctly; how 
do we go about such a change?

(One minor bit: The sentence "This will be done for you automatically if 
you use `git commit -s`" feels a bit off now there is more details on 
something else preceeding it. i.e., `git commit -s` does not establish
real names as such. Maybe leave it earlier in the paragraph?)

Gerald

> ---
>  htdocs/dco.html | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/htdocs/dco.html b/htdocs/dco.html
> index 68fa183b9fc0..5713f003cce3 100644
> --- a/htdocs/dco.html
> +++ b/htdocs/dco.html
> @@ -54,8 +54,21 @@ then you just add a line saying:
>  
>  Signed-off-by: Random J Developer 
> 
>  
> -using your real name (sorry, no pseudonyms or anonymous contributions.)  This
> -will be done for you automatically if you use `git commit -s`.
> +using a known identity (sorry, no anonymous contributions.)  The name
> +you use as your identity should not be an anonymous id or false name
> +that misrepresents who you are.  This will be done for you
> +automatically if you use `git commit -s`.
> +
> +A known identity can be the committer's real, birth or legal name,
> +but can also be an established (online) identity.  It is the name you
> +convey to people in the community for them to use to identify you as
> +you.  The key concern is that your identification is sufficient enough
> +to contact you if an issue were to arise in the future about your
> +contribution.  You should not deliberately use a name or email address
> +that hides your identity.  When you wish to only contribute under an
> +(anonymous) pseudonym, or when you require an explicit employer
> +disclaimer, then following the FSF
> +assignment process is more appropriate.
>  
>  Some people also put extra optional tags at the end.  The GCC project does
>  not require tags from anyone other than the original author of the patch, but
>