Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

[Martin Uecker]

Am Mittwoch, dem 09.04.2025 um 18:31 + schrieb Qing Zhao:
> Hi, Joseph and Martin,
> 
> When I implemented the patch to attach the counted_by information to an array 
> reference (FAM reference) in C FE, 
> The work was done inside the routine “build_component_ref” in 
> gcc/c/c-typeck.cc .  and this is very reasonable and
> quite clean. 
> 
> Now, If we try to replace a structure pointer reference with counted_by 
> attached to the FAM field, where in the C FE
> I should look at?
> 
> For the following small example, I am trying to replace the pointer reference 
> at line 28, “obj”, and line 34, “q” to a call to
> .ACCESS_WITH_SIZE. However, “p” at line 21 and “q” at line 33 should not be 
> replaced. 
> 
> Do you have any suggestions?
> 
> Thanks a lot for your help here.

Hi Qing,

sorry, I wasn't able to follow the thread.   If I understand correctly,
you want to extend the reach of BDOS by using the information from
counted_by, but not only for the size of the FAM but also for the
size of the struct itself, for scenarious where BDOS can not find
the original allocation.  Is this correct?

I have some questions about this:  The access would add new reads
to the size field.  For counted_by, so far, those are somehow
coupled to the access to the member.  From this you would assume
that inserting the new accesses to the size field are ok (e.g.
one can assume the struct is accessible, there are no new race
conditions under some assumptions, it is initialized).  If you
now want to read the size at different points, all this is even
less clear to me.

I may miss something, but I think one would have to first
define a clear criterion when it is ok to access the size
field.   

So to me it seems we can not simply insert it at specific
point in the C FE where a pointer to the struct is
used, but only when there is some specific trigger.

An example I could imagine is when you memcpy
the struct.   (but it is also not entirely clear why this
should not be allowed to go beyond the counted_by size
if the underlying storage is larger).  

Maybe you could add it when a pointer to an annotated
struct is passed as parameter, but also there it is not
clear to me that we might want to materialize new
accesses to the struct at this point.

An alternative approach could be to just do it when
such a pointer is explicitely passed to the BDOS builtin. 

Martin


> 
> Qing
> 
>   1 #include 
>   2 #include 
>   3
>   4 struct annotated {
>   5   size_t count;
>   6   char array[] __attribute__((counted_by (count)));
>   7 };
>   8 
>   9 /* compute the minimum # of bytes needed to hold a structure “annotated”,
>  10whose # of elements of “array” is COUNT.  */
>  11 #define MAX(A, B) (A > B) ? (A) : (B)
>  12 #define ALLOC_SIZE_ANNOTATED(COUNT) \
>  13   MAX(sizeof (struct annotated), \
>  14   offsetof(struct annotated, array[0]) + (COUNT) * sizeof(char))
>  15 
>  16 /* allocate the memory for the structure with FAM,
>  17update “count” with the # of elements “index”.  */
>  18 static struct annotated * __attribute__((__noinline__)) alloc_buf (int 
> index)
>  19 {
>  20   struct annotated *p;
>  21   p = (struct annotated *) malloc (ALLOC_SIZE_ANNOTATED(index));
>  22   p->count = index;
>  23   return p;
>  24 }
>  25 
>  26 static size_t __attribute__((__noinline__)) size_of (struct annotated * 
> obj)
>  27 {
>  28   return __builtin_dynamic_object_size (obj, 1);
>  29 }
>  30  
>  31 int main()
>  32 {
>  33   struct annotated *q = alloc_buf (10);
>  34   __builtin_printf ("the bdos whole is %d\n", size_of (q));
>  35   return 0;
>  36 }
> 
> 

Re: [PATCH] libbacktrace: Add hpux fileline support

[Ian Lance Taylor]

On Wed, Apr 9, 2025 at 7:16 AM John David Anglin  wrote:
>
> Tested on hppa64-hp-hpux11.11.
>
> Okay?
>
> Dave
> ---
>
> libbacktrace: Add hpux fileline support
>
> Fixes libstdc++ stacktrace tests.
>
> 2025-04-09  John David Anglin  
>
> libbacktrace/ChangeLog:
> * fileline.c (hpux_get_executable_path): New.
> (fileline_initialize): Add pass to get hpux executable path.
>
> diff --git a/libbacktrace/fileline.c b/libbacktrace/fileline.c
> index c9fd86b8c0c..e46ea05e528 100644
> --- a/libbacktrace/fileline.c
> +++ b/libbacktrace/fileline.c
> @@ -66,6 +66,35 @@ POSSIBILITY OF SUCH DAMAGE.  */
>  #define getexecname() NULL
>  #endif
>
> +#ifdef __hpux__
> +#include 

Please move this #include up with the other #include lines.

This is OK with that change. Thanks.

Ian

Re: [committed] cobol: Proper comparison of alphanumeric to refmoded numeric-display [PR119682]

[Richard Biener]

> Am 09.04.2025 um 23:19 schrieb Robert Dubner :
> 
> This patch eliminates the error.
> 
>cobol: Proper comparison of alphanumeric to refmoded numeric-display
> [PR119682]

Can you add the testcase as part of the fix?

>gcc/cobol
> 
>PR cobol/119682
>* genapi.cc: (cobol_compare): Change the call to
> __gg__compare().
> 
>libgcobol
> 
>PR cobol/119682
>* common-defs.h: Define the REFER_T_REFMOD constant.
>* intrinsic.cc: (__gg__max): Change the calls to
> __gg__compare_2(),
>(__gg__min): Likewise, (__gg__ord_min): Likewise,
>(__gg__ord_max): Likewise.
>* libgcobol.cc: (__gg__compare_2): Change definition of
> calling
>parameters, eliminate separate flag bit for ALL and
> ADDRESS_OF,
>change comparison of alphanumeric to numeric when the numeric
>is a refmod.
>* libgcobol.h: Change declaration of __gg__compare_2.
> 
> diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
> index c91237bd8d2c..fdf76aad7b14 100644
> --- a/gcc/cobol/genapi.cc
> +++ b/gcc/cobol/genapi.cc
> @@ -2028,10 +2028,12 @@ cobol_compare(  tree return_int,
> {
> // None of our explicit comparisons up above worked, so we revert to
> the
> // general case:
> -int leftflags  =   (left_side_ref.all  ? REFER_T_MOVE_ALL : 0)
> -+  (left_side_ref.addr_of  ? REFER_T_ADDRESS_OF : 0);
> -int rightflags =   (right_side_ref.all ? REFER_T_MOVE_ALL : 0)
> -+  (right_side_ref.addr_of ? REFER_T_ADDRESS_OF : 0);
> +int leftflags  =   (left_side_ref.all  ? REFER_T_MOVE_ALL   :
> 0)
> ++  (left_side_ref.addr_of  ? REFER_T_ADDRESS_OF :
> 0)
> ++  (left_side_ref.refmod.from  ? REFER_T_REFMOD :
> 0);
> +int rightflags =   (right_side_ref.all ? REFER_T_MOVE_ALL   :
> 0)
> ++  (right_side_ref.addr_of ? REFER_T_ADDRESS_OF :
> 0)
> ++  (right_side_ref.refmod.from ? REFER_T_REFMOD :
> 0);
> gg_assign(  return_int, gg_call_expr(
> INT,
> "__gg__compare",
> @@ -2045,6 +2047,7 @@ cobol_compare(  tree return_int,
> build_int_cst_type(INT, rightflags),
> integer_zero_node,
> NULL_TREE));
> +compared = true;
> }
> 
> //  gg_printf("   result is %d\n", return_int, NULL_TREE);
> diff --git a/libgcobol/common-defs.h b/libgcobol/common-defs.h
> index f9d9c56a0d8d..6bf32ef79cf0 100644
> --- a/libgcobol/common-defs.h
> +++ b/libgcobol/common-defs.h
> @@ -70,6 +70,7 @@
> #define REFER_T_ALL_FLAGS_MASK 0x0FF  // We allow for seven subscripts
> #define REFER_T_MOVE_ALL   0x100  // This is the move_all flag
> #define REFER_T_ADDRESS_OF 0x200  // This is the address_of flag
> +#define REFER_T_REFMOD 0x400  // Indicates to library the refer
> was a refmod
> 
> #define MIN_FIELD_BLOCK_SIZE (16)
> 
> diff --git a/libgcobol/intrinsic.cc b/libgcobol/intrinsic.cc
> index 4bce481b0c04..e0bd3339708e 100644
> --- a/libgcobol/intrinsic.cc
> +++ b/libgcobol/intrinsic.cc
> @@ -1867,8 +1867,7 @@ __gg__max(cblc_field_t *dest,
> unsigned char *best_location   ;
> size_t best_length ;
> intbest_attr   ;
> -bool   best_move_all   ;
> -bool   best_address_of ;
> +intbest_flags  ;
> 
> bool first_time = true;
> assert(ncount);
> @@ -1887,8 +1886,7 @@ __gg__max(cblc_field_t *dest,
>   best_location   = __gg__treeplet_1f[i]->data +
> __gg__treeplet_1o[i];
>   best_length = __gg__treeplet_1s[i];
>   best_attr   = __gg__treeplet_1f[i]->attr;
> -  best_move_all   = !!(__gg__fourplet_flags[i] &
> REFER_T_MOVE_ALL);
> -  best_address_of = !!(__gg__fourplet_flags[i] &
> REFER_T_ADDRESS_OF);
> +  best_flags  = __gg__fourplet_flags[i];
>   }
> else
>   {
> @@ -1896,31 +1894,27 @@ __gg__max(cblc_field_t *dest,
>   unsigned char *candidate_location   =
> __gg__treeplet_1f[i]->data + __gg__treeplet_1o[i];
>   size_t candidate_length = __gg__treeplet_1s[i];
>   intcandidate_attr   =
> __gg__treeplet_1f[i]->attr;
> -  bool   candidate_move_all   =
> !!(__gg__fourplet_flags[i] & REFER_T_MOVE_ALL);
> -  bool   candidate_address_of =
> !!(__gg__fourplet_flags[i] & REFER_T_ADDRESS_OF);
> +  intcandidate_flags  = __gg__fourplet_flags[i];
> 
>   int compare_result = __gg__compare_2(
>  candidate_field,
>  candidate_location,
>  candidate_length,
>  candidate_attr,
> - candidate_move_all,
> - candid

[PATCH] h8300: Fix up bit test and jump splitter [PR119664]

[Jakub Jelinek]

Hi!

r12-2601 has added this define_insn_and_split and corresponding
(define_insn ""
  [(set (reg:CCZ CC_REG)
(eq (zero_extract:HSI (match_operand:HSI 0 "register_operand" "r")
  (const_int 1)
  (match_operand 1 "const_int_operand" "n"))
(const_int 0)))]
  "INTVAL (operands[1]) < 16"
  "btst %Z1,%Y0"
  [(set_attr "length" "2")])
pattern into which the define_insn_and_split wants to splut in addition
to a conditional jump.
But as can be seen, the btst define_insn uses HSI mode iterator while
define_insn_and_split QHSI, so for QImode it splits into something that
can't be recognized.

This was probably latent since r12-2601 and on the attached testcase
is reproduceable starting with r15-1945 - a late combiner change.

Untested except for the testcase with x86_64-linux -> h8300-elf cross.

Ok for trunk?

2025-04-09  Jakub Jelinek  

PR target/119664
* config/h8300/jumpcall.md (bit test and jump define_insn_and_split):
Use HSI iterator rather than QHSI.

* gcc.dg/pr119664.c: New test.

--- gcc/config/h8300/jumpcall.md.jj 2021-08-30 08:36:11.044519071 +0200
+++ gcc/config/h8300/jumpcall.md2025-04-08 13:11:03.643093722 +0200
@@ -146,9 +146,9 @@
 (define_insn_and_split ""
   [(set (pc)
(if_then_else (match_operator 3 "eqne_operator"
-   [(zero_extract:QHSI (match_operand:QHSI 1 
"register_operand" "r")
-   (const_int 1)
-   (match_operand 2 
"const_int_operand" "n"))
+   [(zero_extract:HSI (match_operand:HSI 1 
"register_operand" "r")
+  (const_int 1)
+  (match_operand 2 "const_int_operand" 
"n"))
 (const_int 0)])
  (label_ref (match_operand 0 "" ""))
  (pc)))]
@@ -156,7 +156,7 @@
   "#"
   "&& reload_completed"
   [(set (reg:CCZ CC_REG)
-   (eq (zero_extract:QHSI (match_dup 1) (const_int 1) (match_dup 2))
+   (eq (zero_extract:HSI (match_dup 1) (const_int 1) (match_dup 2))
(const_int 0)))
(set (pc)
(if_then_else (match_op_dup 3 [(reg:CCZ CC_REG) (const_int 0)])
--- gcc/testsuite/gcc.dg/pr119664.c.jj  2024-09-17 09:04:10.523093614 +0200
+++ gcc/testsuite/gcc.dg/pr119664.c 2025-04-09 21:19:29.753086945 +0200
@@ -0,0 +1,15 @@
+/* PR target/119664 */
+/* { dg-do compile } */
+/* { dg-options "-Os" } */
+
+struct S { unsigned : 1, a : 1; } *s;
+int foo (void);
+void bar (void);
+
+int
+baz (void)
+{
+  int a = s->a;
+  bar ();
+  return a && foo ();
+}

Jakub

Re: [PATCH] Fortran: fix issue with impure elemental subroutine and interface [PR119656]

[Harald Anlauf]

Am 09.04.25 um 04:06 schrieb Jerry D:

On 4/8/25 1:43 PM, Harald Anlauf wrote:

Hi all,

the attached patch fixes a rather strange 12/13/14/15 regression.
When walking through the list of procedures in an interface to
find the matching one, the code could remember an inferred type
from a false module procedure within the same interface if and
only if optional arguments were in the procedure declarations,
and the procedure call did not provide an actual argument for
an optional one.  An inferred type could then leak into
gfc_conv_procedure_call and pretend a wrong type for the dummy.

(This bug appears to be related to a code refactoring during
12-development and is not present in 11-releases.)

The simple and obvious solution is to use the type of the formal,
as inferred types are only relevant when there is no explicit
interface.

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

As this is a regression, I would like to backport this as
appropriate.

Thanks,
Harald



This looks OK Harold, thanks!


Thanks for the review!

Pushed as r15-9340-g334545194d9023.


Jerry


Harald

Re: [PATCH] h8300: Fix up bit test and jump splitter [PR119664]

[Jeff Law]

On 4/9/25 1:25 PM, Jakub Jelinek wrote:

Hi!

r12-2601 has added this define_insn_and_split and corresponding
(define_insn ""
   [(set (reg:CCZ CC_REG)
(eq (zero_extract:HSI (match_operand:HSI 0 "register_operand" "r")
  (const_int 1)
  (match_operand 1 "const_int_operand" "n"))
(const_int 0)))]
   "INTVAL (operands[1]) < 16"
   "btst   %Z1,%Y0"
   [(set_attr "length" "2")])
pattern into which the define_insn_and_split wants to splut in addition
to a conditional jump.
But as can be seen, the btst define_insn uses HSI mode iterator while
define_insn_and_split QHSI, so for QImode it splits into something that
can't be recognized.

This was probably latent since r12-2601 and on the attached testcase
is reproduceable starting with r15-1945 - a late combiner change.

Untested except for the testcase with x86_64-linux -> h8300-elf cross.

Ok for trunk?

2025-04-09  Jakub Jelinek  

PR target/119664
* config/h8300/jumpcall.md (bit test and jump define_insn_and_split):
Use HSI iterator rather than QHSI.

* gcc.dg/pr119664.c: New test.
OK.  Not immediately sure why we don't support QI for the bit test, but 
given how dead the chip is, not terribly interested in chasing it down 
(until such time as doing so makes my tester run faster ;-)


It'll spin in my tester < 24hrs after commit.  So figure if you haven't 
heard from me, it's working fine.


Jeff

[PUSHED] aarch64: Add sve testcase for PR 116595 [PR116595]

[Andrew Pinski]

This was fixed with r15-9329-gf183ae0ae891a471764876eb but
only a RISC-V V testcase was added. So this adds an aarch64
SVE testcase too.

Pushed as obvious after a quick test to make sure it passes.

PR middle-end/116595

gcc/testsuite/ChangeLog:

* g++.target/aarch64/sve/pr116595.C: New test.

Signed-off-by: Andrew Pinski 
---
 gcc/testsuite/g++.target/aarch64/sve/pr116595.C | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/aarch64/sve/pr116595.C

diff --git a/gcc/testsuite/g++.target/aarch64/sve/pr116595.C 
b/gcc/testsuite/g++.target/aarch64/sve/pr116595.C
new file mode 100644
index 000..49874dd0db0
--- /dev/null
+++ b/gcc/testsuite/g++.target/aarch64/sve/pr116595.C
@@ -0,0 +1,7 @@
+/* { dg-do compile } */
+#include 
+
+void transpose4x4_ps()
+{
+svfloat32x4_t _r = svfloat32x4_t();
+}
-- 
2.43.0

[committed] modula2: Fix a comment typo

[Jakub Jelinek]

Hi!

During make gcc.pot I've noticed among tons of other warnings (e.g. because
can't appears in non-C/C++ style comment and so gettext considers it
unterminated) a warning where the lack of " looked unintentional.

Committed to trunk as obvious.

2025-04-09  Jakub Jelinek  

* gm2-compiler/M2MetaError.def: Fix comment typo, range" -> "range2".

--- gcc/m2/gm2-compiler/M2MetaError.def.jj  2025-04-08 14:08:52.102270018 
+0200
+++ gcc/m2/gm2-compiler/M2MetaError.def 2025-04-09 18:43:35.032144612 +0200
@@ -109,7 +109,8 @@ FROM NameKey IMPORT Name ;
 describe the symbol.  If ordinary text is copied then it is not quoted.
 
The color strings are: "filename", "quote", "error", "warning", "note",
-  "locus", "insert", "delete", "type", "range1", 
range2".
+  "locus", "insert", "delete", "type", "range1",
+  "range2".
 *)
 
 (*

Jakub

[committed] pretty-print: Fix format specifier description

[Jakub Jelinek]

Hi!

I've noticed we talk about %Ns even when that isn't supported and
we actually only support %.Ns which the comment describes.

Committed to trunk as obvious.

2025-04-09  Jakub Jelinek  

* pretty-print.cc (pretty_printer::format): Use %.Ns instead of
%Ns in function comment.

--- gcc/pretty-print.cc.jj  2025-04-08 14:08:59.815162645 +0200
+++ gcc/pretty-print.cc 2025-04-09 19:04:38.762825842 +0200
@@ -1640,7 +1640,7 @@ push_back_any_text (pp_token_list *tok_l
%@: diagnostic_event_id_ptr, for which event_id->known_p () must be true.
%.*s: a substring the length of which is specified by an argument
 integer.
-   %Ns: likewise, but length specified as constant in the format string.
+   %.Ns: likewise, but length specified as constant in the format string.
Flag 'q': quote formatted text (must come immediately after '%').
%Z: Requires two arguments - array of int, and len. Prints elements
of the array.

Jakub

[committed] libquadmath: Fix up THREEp96 constant in expq

[Jakub Jelinek]

Hi!

Here is a cherry-pick from glibc [BZ #32411] fix.

As mentioned by the reporter in a pull request against gcc-mirror,
the THREEp96 constant in e_expl.c is incorrect, it is actually 0x3.p+94f128
rather than 0x3.p+96f128.

The algorithm uses that to compute the t2 integer (tval2), by whose
delta it adjusts the x+xl pair and then in the result uses the precomputed
exp value for that entry.
Using 0x3.p+94f128 rather than 0x3.p+96f128 results in tval2 sometimes
being one smaller, sometimes one larger than the desired value, thus can mean
the x+xl pair after adjustment will be larger in absolute value than it
should be.

DesWursters created a test program for this
https://github.com/DesWurstes/comparefloats
and his results were
total: 113500 not_equal: 4322 earlier_score: 674 later_score: 3648
I've modified this so with
https://sourceware.org/bugzilla/show_bug.cgi?id=32411#c3
so that it actually tests pseudo-random _Float128 values with range
(-16384.,16384) with strong bias on values larger than 0.0002 in absolute
value (so that tval1/tval2 aren't zero most of the time) and that gave
total: 100 not_equal: 29861 earlier_score: 4606 later_score: 25255
So, in both cases, in most cases the change doesn't result in any differences,
and in those rare cases where does, about 85% have smaller ulp than without
the patch.
Additionally I've tried
https://sourceware.org/bugzilla/show_bug.cgi?id=32411#c4
and in 2 billion iterations it didn't find any case where x+xl after the
adjustments without this change would be smaller in absolute value compared
to x+xl after the adjustments with this change.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2025-04-09  Jakub Jelinek  

* math/expq.c (C): Fix up THREEp96 constant.

--- libquadmath/math/expq.c.jj  2020-01-12 11:54:39.783362565 +0100
+++ libquadmath/math/expq.c 2025-04-09 18:26:46.225037125 +0200
@@ -74,7 +74,7 @@ static const __float128 C[] = {
 
 /* 3x2^96 */
 #define THREEp96 C[2]
- 59421121885698253195157962752.0Q,
+ 237684487542793012780631851008.0Q,
 
 /* 3x2^103 */
 #define THREEp103 C[3]

Jakub

Re: [Stage1][Middle-end][object-size][PATCH v1] Evaluate the object size by the size of the pointee type

[Siddhesh Poyarekar]

On 2025-04-08 12:41, Qing Zhao wrote:

The gimple IR is:

   1 int main ()
   2 {
   3   int D.5072;
   4
   5   {
   6 struct annotated * q;
   7
   8 q = alloc_buf (10);
   9 _1 = __builtin_dynamic_object_size (q, 1);
  10 __builtin_printf ("the bdos whole is %d\n", _1);
  11 D.5072 = 0;
  12 return D.5072;
  13   }
  14   D.5072 = 0;
  15   return D.5072;
  16 }
  17
  18
  19 __attribute__((noinline))
  20 struct annotated * alloc_buf (int index)
  21 {
  22   struct annotated * D.5074;
  23   struct annotated * p;
  24   25   _1 = (long unsigned int) index;
  26   _2 = _1 + 9;
  27   _3 = MAX_EXPR <_2, 16>;
  28   p = malloc (_3);
  29   _4 = (long unsigned int) index;
  30   p->count = _4;
  31   D.5074 = p;
  32   return D.5074;
  33 }

When we generate the .ACCESS_WITH_SIZE for a pointer reference to “struct 
annotated”,
Looks like all the pointer references, at line 8, “q”,  at line 9, “q”, at line 
28, “p”, need to be changed
to a call to .ACCESS_WITH_SIZE. this might increase the IR size unnecessarily.  
 Might have some
Impact on the inlining decision heuristics or other heuristic that depend on 
the code size.


Do you need a .ACCESS_WITH_SIZE for initialization sites?  I was 
thinking we ought to need it only for read/dereference sites (which 
should be sufficient as a barrier too), so in this case it would only be 
for 'q' at line 9.



For a reference to a structure with FAM, such as p, we can generate a call to 
.ACCESS_WITH_SIZE whose 3rd argument
is 0 (the number of bytes). And this information can be used in 
__builtin_object_size. But not in array bound sanitizer.


Would that be necessary though, given that the array bound sanitizer 
only works on arrays and not other kinds of objects?


Thanks,
Sid

Re: [PATCH] lto: lto-opts fixes [PR119625]

[Marek Polacek]

On Fri, Apr 04, 2025 at 08:56:40PM +0200, Jakub Jelinek wrote:
> On Fri, Apr 04, 2025 at 08:52:10PM +0200, Richard Biener wrote:
> > > Or do you want something further (like
> > > switch (global_options.x_flag_cf_protection & ~CF_SET)
> > > )?
> > 
> > Dunno what that CF_SET is, we’re supposed to record options like the user 
> > specified so we can merge them.  Why does the backend alter this?
> 
> The option user specified was -fhardened but that for some reason
> isn't present in gcc.lto_.opts at all.
> Also, it is unclear to me if the options that -fhardened sets
> should be marked also as OPTION_SET_P (as if the user specified
> all those options explicitly when specifying -fhardened explicitly)
> or not.
> CCing Marek on that.

I think it doesn't have to be.  There's --help=hardened which shows
what options will be (attempted to be) enabled.
 
Marek

Re: [PATCH] riscv: Fix r15-9270 fallout on RISC-V

[Kito Cheng]

Hi Jakub:

Checked with SVE's implementation and seems right for RVV, so OK for
trunk, thanks :)

On Wed, Apr 9, 2025 at 9:24 PM Jakub Jelinek  wrote:
>
> Hi!
>
> On Wed, Apr 09, 2025 at 02:38:01PM +0200, Mark Wielaard wrote:
> > Unfortunately this seems to have broken the riscv bootstrap:
> > https://builder.sourceware.org/buildbot/#/builders/337/builds/105
> >
> > ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: 
> > enumeration value ‘TCTX_OMP_MAP’ not handled in switch [-Werror=switch]
> >  4730 |   switch (context)
> >   |  ^
> > ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: 
> > enumeration value ‘TCTX_OMP_MAP_IMP_REF’ not handled in switch 
> > [-Werror=switch]
> > ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: 
> > enumeration value ‘TCTX_OMP_PRIVATE’ not handled in switch [-Werror=switch]
> > ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: 
> > enumeration value ‘TCTX_OMP_FIRSTPRIVATE’ not handled in switch 
> > [-Werror=switch]
> > ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: 
> > enumeration value ‘TCTX_OMP_DEVICE_ADDR’ not handled in switch 
> > [-Werror=switch]
> > cc1plus: all warnings being treated as errors
>
> Indeed, riscv-vector-builtins.cc IMHO needs pretty much the same
> changes as aarch64, just with s/SVE/RVV/g.
> I've also left out default: break; so that it is caught next time
> somebody adds further enumerators.
>
> Tested with compilation of x86_64-linux -> riscv64-linux cross,
> ok for trunk?
>
> 2025-04-09  Jakub Jelinek  
>
> * config/riscv/riscv-vector-builtins.cc (verify_type_context):
> Diagnose RVV types for a given OpenMP context.
>
> diff --git a/gcc/config/riscv/riscv-vector-builtins.cc 
> b/gcc/config/riscv/riscv-vector-builtins.cc
> index d2fe849c693..61dcdabbb40 100644
> --- a/gcc/config/riscv/riscv-vector-builtins.cc
> +++ b/gcc/config/riscv/riscv-vector-builtins.cc
> @@ -4724,7 +4724,11 @@ bool
>  verify_type_context (location_t loc, type_context_kind context, const_tree 
> type,
>  bool silent_p)
>  {
> -  if (!sizeless_type_p (type))
> +  const_tree tmp = type;
> +  if (omp_type_context (context) && POINTER_TYPE_P (type))
> +tmp = strip_pointer_types (tmp);
> +
> +  if (!sizeless_type_p (tmp))
>  return true;
>
>switch (context)
> @@ -4796,6 +4800,34 @@ verify_type_context (location_t loc, type_context_kind 
> context, const_tree type,
> error_at (loc, "capture by copy of RVV type %qT", type);
>
>return false;
> +
> +case TCTX_OMP_MAP:
> +  if (!silent_p)
> +   error_at (loc, "RVV type %qT not allowed in % clause", type);
> +  return false;
> +
> +case TCTX_OMP_MAP_IMP_REF:
> +  if (!silent_p)
> +   error ("cannot reference %qT object types in % region", 
> type);
> +  return false;
> +
> +case TCTX_OMP_PRIVATE:
> +  if (!silent_p)
> +   error_at (loc, "RVV type %qT not allowed in"
> + " % % clause", type);
> +  return false;
> +
> +case TCTX_OMP_FIRSTPRIVATE:
> +  if (!silent_p)
> +   error_at (loc, "RVV type %qT not allowed in"
> + " % % clause", type);
> +  return false;
> +
> +case TCTX_OMP_DEVICE_ADDR:
> +  if (!silent_p)
> +   error_at (loc, "RVV type %qT not allowed in"
> + " % device clauses", type);
> +  return false;
>  }
>
>gcc_unreachable ();
>
> Jakub
>

[committed][RISC-V] Adjust expected output for rvv test

[Jeff Law]

The recent combine changes twiddled code generation ever so slightly on 
risc-v and is causing pr117722.c to fail.


The relevant change is this sequence to perform an abs() across elements 
in a vector:



!   vwsubu.vv   v1,v4,v3
vsetvli zero,zero,e16,mf2,tu,ma
-   vrsub.viv3,v1,0
-   vmax.vv v1,v1,v3


Turns into:


!   vwsubu.vv   v1,v3,v4
!   vwsubu.vv   v5,v4,v3
vsetvli zero,zero,e16,mf2,tu,ma
+   vmax.vv v1,v1,v5



There's other trivial differences, but that highlights the key change in 
the abs sequence.


The first sequence has lower register pressure since it synthesizes the 
negation using vrsub.vi.


The second sequence is better from a data dependency standpoint as the 
two vwsubu instructions can execute in parallel on designs with > 1 
vector ALU.


I don't consider either sequence inherently better than the other.  So 
I'm just adjusting the test to accept our new code.


jeffgcc/testsuite
* gcc.target/riscv/rvv/autovec/pr117722.c: Adjust expected output.

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr117722.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr117722.c
index 493dab05621..02670784fea 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr117722.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr117722.c
@@ -18,6 +18,5 @@ int pixel_sad_n(unsigned char *pix1, unsigned char *pix2, int 
n)
   return sum;
 }
 
-/* { dg-final { scan-assembler {vrsub\.v} } } */
 /* { dg-final { scan-assembler {vmax\.v} } } */
-/* { dg-final { scan-assembler {vwsubu\.v} } } */
+/* { dg-final { scan-assembler-times {vwsubu\.v} 2 } } */

RE: [PATCH][contrib]: support json output from check_GNU_style_lib.py

[Tamar Christina]

Ping

> -Original Message-
> From: Tamar Christina 
> Sent: Tuesday, July 23, 2024 3:30 PM
> To: Jonathan Wakely ; Filip Kastl 
> Cc: gcc-patches@gcc.gnu.org; nd 
> Subject: RE: [PATCH][contrib]: support json output from check_GNU_style_lib.py
> 
> Hi Both,
> 
> > -Original Message-
> > From: Jonathan Wakely 
> > Sent: Monday, July 22, 2024 3:21 PM
> > To: Filip Kastl 
> > Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; nd
> > 
> > Subject: Re: [PATCH][contrib]: support json output from 
> > check_GNU_style_lib.py
> >
> > On Mon, 22 Jul 2024 at 14:54, Filip Kastl  wrote:
> > >
> > > Hi Tamar,
> > >
> > > I wanted to try reviewing a patch and this seemed simple enough so I gave 
> > > it a
> > > shot.  Hopefully this saves some time of the maintainer that eventually
> > > approves this :).
> 
> Thanks for the review! :)
> 
> > >
> > > I don't see any bug in the code.  I also tried running it on my own input 
> > > and
> > > the output was correct.  So functionally the patch is good.  I have some
> > > remarks about the style though:
> > >
> > > - You sometimes put a space between function name and parentheses.  This
> > >   doesn't look python-ish and isn't consistent in the file.
> >
> > It's the GNU C convention, but I really wish we didn't use it for
> > Python code too.
> >
> > > - There's one very long line (check_GNU_style_lib.py:335).  I would 
> > > shorten it
> > >   so it is at most 79 characters long.
> > > - On the same line, there is a space after { but not before }.  For
> > >   consistency, I would erase the space after {
> > > - On the same line there are spaces after :.  I think a more python-ish 
> > > way
> > >   would be not to have those spaces there.  Here I'm maybe being too 
> > > pedantic
> > >   so feel free to ignore this.  I think it will look nice either way.
> > >
> > > To summarize the last 3 points, I would replace this
> > >
> > > errlines.append({ "file" : locs[0], "row" : locs[1], 
> > > "column" : locs[2],
> "err"
> > : e.console_error})
> 
> How about this formatting, I tend to find it a bit easier to read even.
> I also updated the location numbering to be numerical so, removed the quotes.
> 
> Ok for master?
> 
> Thanks,
> Tamar
> 
> contrib/ChangeLog:
> 
>   * check_GNU_style.py: Add json format.
>   * check_GNU_style_lib.py: Likewise.
> 
> -- inline copy of patch --
> 
> diff --git a/contrib/check_GNU_style.py b/contrib/check_GNU_style.py
> index
> 6b946a5bc3610b8ef70ba372ea800f892eeac85b..0890947f1f9b60c37ff62e230
> 07c3a0735fd9c14 100755
> --- a/contrib/check_GNU_style.py
> +++ b/contrib/check_GNU_style.py
> @@ -31,7 +31,7 @@ def main():
>  parser.add_argument('file', help = 'File with a patch')
>  parser.add_argument('-f', '--format', default = 'stdio',
>  help = 'Display format',
> -choices = ['stdio', 'quickfix'])
> +choices = ['stdio', 'quickfix', 'json'])
>  args = parser.parse_args()
>  filename = args.file
>  format = args.format
> diff --git a/contrib/check_GNU_style_lib.py b/contrib/check_GNU_style_lib.py
> index
> 6dbe4b53559c63d2e0276d0ff88619cd2f7f8e06..ab21ed4607593668ab95f247
> 15295a41ac7d8a21 100755
> --- a/contrib/check_GNU_style_lib.py
> +++ b/contrib/check_GNU_style_lib.py
> @@ -29,6 +29,7 @@
>  import sys
>  import re
>  import unittest
> +import json
> 
>  def import_pip3(*args):
>  missing=[]
> @@ -317,6 +318,33 @@ def check_GNU_style_file(file, format):
>  else:
>  print('%d error(s) written to %s file.' % (len(errors), f))
>  exit(1)
> +elif format == 'json':
> +fn = lambda x: x.error_message
> +i = 1
> +result = []
> +for (k, errors) in groupby(sorted(errors, key = fn), fn):
> +errors = list(errors)
> +entry = {}
> +entry['type'] = i
> +entry['msg'] = k
> +entry['count'] = len(errors)
> +i += 1
> +errlines = []
> +for e in errors:
> +locs = e.error_location ().split(':')
> +errlines.append({ "file": locs[0]
> +, "row": int(locs[1])
> +, "column": int(locs[2])
> +, "err": e.console_error })
> +entry['errors'] = errlines
> +result.append(entry)
> +
> +if len(errors) == 0:
> +exit(0)
> +else:
> +json_string = json.dumps(result)
> +print(json_string)
> +exit(1)
>  else:
>  assert False

[PATCH] bf-ms-attrib.c: Fix expected struct size

[Jonathan Yong]

Attached patch OK for master branch? Gcc produced struct sizes match 
those of MSVC when __ms_struct__ is used, both producing a layout size 
of 12.


Will push soon if there are no objections.
From 522b0aa6473e109becc45e57255f14e23fc6a404 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Wed, 9 Apr 2025 14:29:39 +
Subject: [PATCH] bf-ms-attrib.c: Fix expected struct size

Both gcc and msvc agree that the struct size should
be 12, gcc is already correct.

Signed-off-by: Jonathan Yong <10wa...@gmail.com>

gcc/testsuite/ChangeLog:

	PR target/113633
* gcc.dg/bf-ms-attrib.c: Fix expected __ms_struct__ layout
	size.
---
 gcc/testsuite/gcc.dg/bf-ms-attrib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/bf-ms-attrib.c b/gcc/testsuite/gcc.dg/bf-ms-attrib.c
index 2da4f0320d6..5208c7f882f 100644
--- a/gcc/testsuite/gcc.dg/bf-ms-attrib.c
+++ b/gcc/testsuite/gcc.dg/bf-ms-attrib.c
@@ -32,7 +32,7 @@ main()
 /* As long as the sizes are as expected, we know attributes are working.
bf-ms-layout.c makes sure the right thing happens when the attribute
is on. */
-if (sizeof(struct one_ms) != 8)
+if (sizeof(struct one_ms) != 12)
 	abort();
 if (sizeof(struct one_gcc) != 8)
 	abort();
-- 
2.49.0

[PATCH v2] RISC-V: vsetvl: elide abnormal edges from LCM computations [PR119533]

[Vineet Gupta]

Changes since v2
 - Elide abnormal edges before LCM not after LCM
---

vsetvl phase4 uses LCM guided info to insert VSETVL insns, including a
straggler loop for "mising vsetvls" on certain edges. Currently it
asserts on encountering EDGE_ABNORMAL.

When enabling go frontend with V enabled, libgo build hits the assert.

The solution is to filter out abnormal edges from getting into LCM at
all. Existing invalid_opt_bb_p () has such checks for BB predecessors
but not for successors which is what the patch adds.

Crucially, the ICE/fix also depends on avoiding vsetvl hoisting past
non-transparent blocks: That is taken care of by Robin's patch
"RISC-V: Do not lift up vsetvl into non-transparent blocks [PR119547]"
or a different yet related issue.

Reported-by: Heinrich Schuchardt 
Signed-off-by: Vineet Gupta 

PR target/119533

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (invalid_opt_bb_p): Check for
EDGE_ABNOMAL.
(pre_vsetvl::compute_lcm_local_properties): Dump skipped edge.

gcc/testsuite/ChangeLog:

* go.dg/pr119533-riscv.go: New test.
* go.dg/pr119533-riscv-2.go: New test.

Signed-off-by: Vineet Gupta 
---
 gcc/config/riscv/riscv-vsetvl.cc|   7 +-
 gcc/testsuite/go.dg/pr119533-riscv-2.go |  42 +
 gcc/testsuite/go.dg/pr119533-riscv.go   | 120 
 3 files changed, 168 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/go.dg/pr119533-riscv-2.go
 create mode 100644 gcc/testsuite/go.dg/pr119533-riscv.go

diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index c4046bcc3455..a8c92565541a 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -685,7 +685,7 @@ invalid_opt_bb_p (basic_block cfg_bb)
   /* We only do LCM optimizations on blocks that are post dominated by
  EXIT block, that is, we don't do LCM optimizations on infinite loop.  */
   FOR_EACH_EDGE (e, ei, cfg_bb->succs)
-if (e->flags & EDGE_FAKE)
+if ((e->flags & EDGE_FAKE) || (e->flags & EDGE_ABNORMAL))
   return true;
 
   return false;
@@ -2698,6 +2698,7 @@ pre_vsetvl::compute_lcm_local_properties ()
   m_avout = sbitmap_vector_alloc (last_basic_block_for_fn (cfun), num_exprs);
 
   bitmap_vector_clear (m_avloc, last_basic_block_for_fn (cfun));
+  bitmap_vector_clear (m_kill, last_basic_block_for_fn (cfun));
   bitmap_vector_clear (m_antloc, last_basic_block_for_fn (cfun));
   bitmap_vector_ones (m_transp, last_basic_block_for_fn (cfun));
 
@@ -2749,6 +2750,10 @@ pre_vsetvl::compute_lcm_local_properties ()
 
   if (invalid_opt_bb_p (bb->cfg_bb ()))
{
+ if (dump_file && (dump_flags & TDF_DETAILS))
+   fprintf (dump_file, "\n --- skipping bb %u due to weird edge",
+bb->index ());
+
  bitmap_clear (m_antloc[bb_index]);
  bitmap_clear (m_transp[bb_index]);
}
diff --git a/gcc/testsuite/go.dg/pr119533-riscv-2.go 
b/gcc/testsuite/go.dg/pr119533-riscv-2.go
new file mode 100644
index ..ce3ffaffe9d4
--- /dev/null
+++ b/gcc/testsuite/go.dg/pr119533-riscv-2.go
@@ -0,0 +1,42 @@
+// { dg-do compile { target riscv64*-*-* } }
+// { dg-options "-O2 -march=rv64gcv -mabi=lp64d" }
+
+package ast
+
+type as struct {
+   bt []struct{}
+   an string
+}
+
+func bj(a *as) string {
+   if b := a.bt; len(a.an) == 1 {
+   _ = b[0]
+   }
+   return a.an
+}
+
+func MergePackageFiles(f map[string][]interface{}, g uint) []interface{} {
+   bl := make([]string, len(f))
+   var bo []interface{}
+   bu := make(map[string]int)
+   for _, bm := range bl {
+   a := f[bm]
+   for _, d := range a {
+   if g != 0 {
+   if a, p := d.(*as); p {
+   n := bj(a)
+   if j, bp := bu[n]; bp {
+   _ = j
+   }
+   }
+   }
+   }
+   }
+   for _, bm := range bl {
+   _ = bm
+   }
+   for _, bm := range bl {
+   _ = f[bm]
+   }
+   return bo
+}
diff --git a/gcc/testsuite/go.dg/pr119533-riscv.go 
b/gcc/testsuite/go.dg/pr119533-riscv.go
new file mode 100644
index ..30f52d267c5f
--- /dev/null
+++ b/gcc/testsuite/go.dg/pr119533-riscv.go
@@ -0,0 +1,120 @@
+// { dg-do compile { target riscv64*-*-* } }
+// { dg-options "-O2 -march=rv64gcv -mabi=lp64d" }
+
+// Reduced from libgo build (multi-file reduction, merged mnaully
+// and hand reduced again).
+
+package ast
+import (
+   "go/token"
+   "go/scanner"
+   "reflect"
+)
+type v struct {}
+type w func( string,  reflect.Value) bool
+func x( string,  reflect.Value) bool
+type r struct {
+   scanner.ErrorList
+}
+type ab interface {}
+type ae interface {}
+type af interface {}
+type ag struct {}
+func (a

Re: .ACCESS_WITH_SIZE and pointer ranges

[Siddhesh Poyarekar]

On 2025-04-09 08:30, Qing Zhao wrote:

After expand phase, .ACCESS_WITH_SIZE will be replaced by its first argument.
And all the size expression before the call to .ACCESS_WITH_SIZE might be dead
code eliminated later in the RTL phases.

So, I don’t think there will be run-time overhead concern.

However, the IR size increase in the TREE optimization phase might impact the
Optimization heuristics that base on IR size, for example, inlining decision, 
etc.

That’s the major concern for me.


I mean that the IR size estimation should also account for the fact that 
the runtime overhead of .ACCESS_WITH_SIZE is zero.



A good measure of this could be to get a sense of additional coverage one could 
get for __bdos with this change vs without it for, e.g. the kernel.  You could 
maybe use fortify-metrics[1] to find that.


Why there will be additional coverage with this change? (This change means to
replace pointer reference with structure type with FAM by a call to 
.ACCESS_WITH_SIZE
in C FE)

Based on my current patch (expand the counted_by refs to size expressions by 
demand for __bdos),
All the __bdos should be covered, right?


Yes, I mean if you're concerned that there's a performance tradeoff due 
to this change, you could quantify the coverage improvement to make the 
case that there's a measurable improvement in security in the generated 
code, which justifies the performance overhead.


Something like: "The total coverage for __bdos improved by X% for the 
kernel build, which justifies the additional overhead of up to N 
instructions for the size expression caused by this patch".


Thanks,
Sid

Re: [PATCH] rtl-optimization/119689 - compare-debug failure with LRA

[Vladimir Makarov]

On 4/9/25 8:40 AM, Richard Biener wrote:

The previous change to fix LRA rematerialization broke compare-debug
for i586 bootstrap.  Fixed by using prev_nonnote_nondebug_insn
instead of prev_nonnote_insn.

Bootstrapped on i586-linux where the miscompare is gone with this
patch.  Bootstrap and regtest running on x86_64-unknown-linux-gnu.

OK if the latter succeeds?

Yes.  Thank you, Richard.


PR rtl-optimization/119689
PR rtl-optimization/115568
* lra-remat.cc (create_cands): Use prev_nonnote_nondebug_insn
to check whether insn2 is directly before insn.

* g++.target/i386/pr119689.C: New testcase.

New German PO file for 'gcc' (version 15.1-b20250406)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

(This file, 'gcc-15.1-b20250406.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

[PATCH v1 0/4] Add SEH, stack unwinding and C++ exceptions

[Evgeny Karpov]

> This patch series adds SEH, stack unwinding and C++ exceptions
> implementation to the aarch64-w64-mingw32 target.

This patch series is supported by the binutils patch series.
https://sourceware.org/pipermail/binutils/2025-April/140495.html

The Boost library testing identified some issues that needed to be resolved 
in the binutils patch series before posting. 
The required changes for the GCC SEH implementation will be included 
in the next version, along with the requested changes from the last review.

Regards,
Evgeny

Re: [PATCH] c++: wrong targs printed in hard satisfaction error [PR99214]

[Patrick Palka]

On Wed, 5 Mar 2025, Jason Merrill wrote:

> On 3/5/25 10:13 AM, Patrick Palka wrote:
> > On Tue, 4 Mar 2025, Jason Merrill wrote:
> > 
> > > On 3/4/25 2:49 PM, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > > > for trunk/14?
> > > > 
> > > > -- >8 --
> > > > 
> > > > In the three-parameter version of satisfy_declaration_constraints, when
> > > > 't' isn't the most general template, then 't' won't correspond with
> > > > 'args' after we augment the latter via add_outermost_template_args, and
> > > > so the instantiation context that we push via push_tinst_level isn't
> > > > quite correct: 'args' is a complete set of template arguments, but 't'
> > > > is not necessarily the most general template.  This manifests as
> > > > misleading diagnostic context lines when issuing a hard error (or a
> > > > constraint recursion error) that occurred during satisfaction, e.g. for
> > > > the below testcase without this patch we emit:
> > > > In substitution of '... void A::f() [with U = int]'
> > > > and with this patch we emit:
> > > > In substitution of '... void A::f() [with U = char; T = int]'.
> > > > 
> > > > This patch fixes this by always passing the most general template to
> > > > push_tinst_level.
> > > 
> > > That soungs good, but getting it by passing it back from
> > > get_normalized_constraints_from_decl seems confusing; I'd think we should
> > > calculate it in parallel to changing args to correspond to that template.
> > 
> > Hmm, won't that mean duplicating the template adjustment logic in
> > get_normalized_constraints_from_decl, which seems undesirable?  The
> > function has many callers, some of which are for satisfaction where
> > targs are involved, and the rest are for subsumption where no targs are
> > involved, so I don't see a clean way of refactoring the code to avoid
> > duplication of the template adjustment logic.  Right now the targ
> > adjustment logic is unfortunately duplicated across both overloads
> > of satisfy_declaration_constraints and it seems undesirable to add
> > more duplication.
> 
> Fair enough.  Incidentally, I wonder why the two-parm overload doesn't call
> the three-parm overload?
> 
> > Maybe one way to reduce the duplication would be to go the other way and
> > move the targ adjustment logic to get_normalized_constraints_from_decl
> > as well (so that it has two out-parameters, 'gen_d' and 'gen_args').
> > The proposed patch then would be an incremental step towards that.
> 
> That makes sense, passing back something suitable for
> add_outermost_template_args.

I tried combining the two overloads, and/or moving the targ adjustment
logic to get_normalized_constraints_from_decl, but I couldn't arrive at
a formulation that worked and I was happy with (i.e. didn't lead to more
code duplication than the original appproach).

In the meantime I noticed that this bug is more pervasive than I
thought, and leads to wrong diagnostic context lines printed even in the
case of ordinary satisfaction failure -- however the wrong diagnostic
lines are more annoying/noticable during a hard error or constraint
recursion where there's likely no other useful diagnostic lines that
might have the correct args printed.

So I adjusted the testcase in the original patch accordingly.  Could the
following go in for now?

I also attached a diff of the output of all our concepts testcases
currently, before/after this patch.  Each change seems like a clear
improvement/correction to me.

-- >8 --

Subject: [PATCH] c++: wrong targs in satisfaction diagnostic context line
 [PR99214]

In the three-parameter version of satisfy_declaration_constraints, when
't' isn't the most general template, then 't' won't correspond with
'args' after we augment the latter via add_outermost_template_args, and
so the instantiation context that we push via push_tinst_level isn't
quite correct: 'args' is a complete set of template arguments, but 't'
is not necessarily the most general template.  This manifests as
misleading diagnostic context lines when issuing a satisfaction failure
error, e.g.  the below testcase without this patch we emit:
  In substitution of '... void A::f() [with U = int]'
and with this patch we emit:
  In substitution of '... void A::f() [with U = char; T = int]'.

This patch fixes this by always passing the most general template to
push_tinst_level.

PR c++/99214

gcc/cp/ChangeLog:

* constraint.cc (get_normalized_constraints_from_decl): New
optional out-parameter GEN_D.
(satisfy_declaration_constraints): Use it to pass the most
general version of T to push_tinst_level.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/diagnostic20.C: New test.
---
 gcc/cp/constraint.cc | 15 +++
 gcc/testsuite/g++.dg/concepts/diagnostic20.C | 14 ++
 2 files changed, 25 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic20.C

Re: [PATCH] c++: wrong targs printed in hard satisfaction error [PR99214]

[Patrick Palka]

On Wed, 9 Apr 2025, Patrick Palka wrote:

> On Wed, 5 Mar 2025, Jason Merrill wrote:
> 
> > On 3/5/25 10:13 AM, Patrick Palka wrote:
> > > On Tue, 4 Mar 2025, Jason Merrill wrote:
> > > 
> > > > On 3/4/25 2:49 PM, Patrick Palka wrote:
> > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > > > > for trunk/14?
> > > > > 
> > > > > -- >8 --
> > > > > 
> > > > > In the three-parameter version of satisfy_declaration_constraints, 
> > > > > when
> > > > > 't' isn't the most general template, then 't' won't correspond with
> > > > > 'args' after we augment the latter via add_outermost_template_args, 
> > > > > and
> > > > > so the instantiation context that we push via push_tinst_level isn't
> > > > > quite correct: 'args' is a complete set of template arguments, but 't'
> > > > > is not necessarily the most general template.  This manifests as
> > > > > misleading diagnostic context lines when issuing a hard error (or a
> > > > > constraint recursion error) that occurred during satisfaction, e.g. 
> > > > > for
> > > > > the below testcase without this patch we emit:
> > > > > In substitution of '... void A::f() [with U = int]'
> > > > > and with this patch we emit:
> > > > > In substitution of '... void A::f() [with U = char; T = 
> > > > > int]'.
> > > > > 
> > > > > This patch fixes this by always passing the most general template to
> > > > > push_tinst_level.
> > > > 
> > > > That soungs good, but getting it by passing it back from
> > > > get_normalized_constraints_from_decl seems confusing; I'd think we 
> > > > should
> > > > calculate it in parallel to changing args to correspond to that 
> > > > template.
> > > 
> > > Hmm, won't that mean duplicating the template adjustment logic in
> > > get_normalized_constraints_from_decl, which seems undesirable?  The
> > > function has many callers, some of which are for satisfaction where
> > > targs are involved, and the rest are for subsumption where no targs are
> > > involved, so I don't see a clean way of refactoring the code to avoid
> > > duplication of the template adjustment logic.  Right now the targ
> > > adjustment logic is unfortunately duplicated across both overloads
> > > of satisfy_declaration_constraints and it seems undesirable to add
> > > more duplication.
> > 
> > Fair enough.  Incidentally, I wonder why the two-parm overload doesn't call
> > the three-parm overload?
> > 
> > > Maybe one way to reduce the duplication would be to go the other way and
> > > move the targ adjustment logic to get_normalized_constraints_from_decl
> > > as well (so that it has two out-parameters, 'gen_d' and 'gen_args').
> > > The proposed patch then would be an incremental step towards that.
> > 
> > That makes sense, passing back something suitable for
> > add_outermost_template_args.
> 
> I tried combining the two overloads, and/or moving the targ adjustment
> logic to get_normalized_constraints_from_decl, but I couldn't arrive at
> a formulation that worked and I was happy with (i.e. didn't lead to more
> code duplication than the original appproach).
> 
> In the meantime I noticed that this bug is more pervasive than I
> thought, and leads to wrong diagnostic context lines printed even in the
> case of ordinary satisfaction failure -- however the wrong diagnostic
> lines are more annoying/noticable during a hard error or constraint
> recursion where there's likely no other useful diagnostic lines that
> might have the correct args printed.
> 
> So I adjusted the testcase in the original patch accordingly.  Could the
> following go in for now?
> 
> I also attached a diff of the output of all our concepts testcases
> currently, before/after this patch.  Each change seems like a clear
> improvement/correction to me.

Oops, that was not a complete diff of all the concepts tests, here is a
more complete one.

> 
> -- >8 --
> 
> Subject: [PATCH] c++: wrong targs in satisfaction diagnostic context line
>  [PR99214]
> 
> In the three-parameter version of satisfy_declaration_constraints, when
> 't' isn't the most general template, then 't' won't correspond with
> 'args' after we augment the latter via add_outermost_template_args, and
> so the instantiation context that we push via push_tinst_level isn't
> quite correct: 'args' is a complete set of template arguments, but 't'
> is not necessarily the most general template.  This manifests as
> misleading diagnostic context lines when issuing a satisfaction failure
> error, e.g.  the below testcase without this patch we emit:
>   In substitution of '... void A::f() [with U = int]'
> and with this patch we emit:
>   In substitution of '... void A::f() [with U = char; T = int]'.
> 
> This patch fixes this by always passing the most general template to
> push_tinst_level.
> 
>   PR c++/99214
> 
> gcc/cp/ChangeLog:
> 
>   * constraint.cc (get_normalized_constraints_from_decl): New
>   optional out-parameter GEN_D.
>   (satisfy_declaration_constraints): Use it to pass the m

OpenACC: Support GCC/C++-special 'default(_GCC_firstprivate)' clause [PR119692]

[Thomas Schwinge]

Hi!

To allow me to progress with other work items, is the attached
"OpenACC: Support GCC/C++-special 'default(_GCC_firstprivate)' clause 
[PR119692]"
OK to push to trunk branch, with a few test cases added?


(I might also suggest OpenACC 'default(firstprivate)' for standardization
by the OpenACC Technical Committee.)


Grüße
 Thomas


>From 660ffe85a98e9f0ec6ddd6ba1f383a44b672502c Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 9 Apr 2025 17:35:42 +0200
Subject: [PATCH] OpenACC: Support GCC/C++-special 'default(_GCC_firstprivate)'
 clause [PR119692]

... provide an OpenACC work-around, while PR119692
"C++ 'typeinfo', 'vtable' vs. OpenACC, OpenMP 'target' offloading" is
not yet resolved.  This is similar in spirit to OpenMP 'default(firstprivate)'.

	PR c++/119692
	gcc/cp/
	* parser.cc (cp_parser_omp_clause_default): For OpenACC, support
	'default(_GCC_firstprivate)' clause.
	gcc/
	* gimplify.cc (oacc_default_clause): Handle
	'OMP_CLAUSE_DEFAULT_FIRSTPRIVATE'.
---
 gcc/cp/parser.cc | 6 ++
 gcc/gimplify.cc  | 6 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 812a7c5ae7d..169783c5caf 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -39886,6 +39886,12 @@ cp_parser_omp_clause_default (cp_parser *parser, tree list,
 
   switch (p[0])
 	{
+	case '_':
+	  if (strcmp ("_GCC_firstprivate", p) != 0 || !is_oacc)
+	goto invalid_kind;
+	  kind = OMP_CLAUSE_DEFAULT_FIRSTPRIVATE;
+	  break;
+
 	case 'n':
 	  if (strcmp ("none", p) != 0)
 	goto invalid_kind;
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index e90220cc2a0..9ab2e10037a 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -8966,6 +8966,9 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx, tree decl, unsigned flags)
   if (RECORD_OR_UNION_TYPE_P (type))
 is_private = lang_hooks.decls.omp_disregard_value_expr (decl, false);
 
+  if (ctx_default->default_kind == OMP_CLAUSE_DEFAULT_FIRSTPRIVATE)
+is_private = true;
+
   if ((ctx->region_type & (ORT_ACC_PARALLEL | ORT_ACC_KERNELS)) != 0
   && is_global_var (decl)
   && device_resident_p (decl)
@@ -9034,7 +9037,8 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx, tree decl, unsigned flags)
 	  oacc_region_type_name (ctx_default->region_type),
 	  "default(none)");
 }
-  else if (ctx_default->default_kind == OMP_CLAUSE_DEFAULT_PRESENT)
+  else if (ctx_default->default_kind == OMP_CLAUSE_DEFAULT_PRESENT
+	   || ctx_default->default_kind == OMP_CLAUSE_DEFAULT_FIRSTPRIVATE)
 ; /* Handled above.  */
   else
 gcc_checking_assert (ctx_default->default_kind == OMP_CLAUSE_DEFAULT_SHARED);
-- 
2.34.1

Re: [PATCH v4 1/2] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

[H.J. Lu]

On Wed, Apr 9, 2025 at 8:54 AM Ard Biesheuvel  wrote:
>
> On Wed, 9 Apr 2025 at 16:46, H.J. Lu  wrote:
> >
> > On Wed, Apr 9, 2025 at 1:53 AM Ard Biesheuvel  wrote:
> > >
> > > From: Ard Biesheuvel 
> > >
> > > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> > > __fentry__") updated the logic that emits mcount() / __fentry__() calls
> > > into function prologues when profiling is enabled, to avoid GOT-based
> > > indirect calls when a direct call would suffice.
> > >
> > > There are two problems with that change:
> > > - it relies on -mdirect-extern-access rather than -fno-plt to decide
> > >   whether or not a direct [PLT based] call is appropriate;
> > > - for the PLT case, it falls through to x86_print_call_or_nop(), which
> > >   does not emit the @PLT suffix, resulting in the wrong relocation to be
> > >   used (R_X86_64_PC32 instead of R_X86_64_PLT32)
> > >
> > > Fix this by testing flag_plt instead of ix86_direct_extern_access, and
> > > updating x86_print_call_or_nop() to take flag_pic and flag_plt into
> > > account. This also ensures that -mnop-mcount works as expected when
> > > emitting the PLT based profiling calls.
> > >
> > > Note that only 64-bit codegen is affected by this change or by the
> > > commit referenced above; -m32 will yield 'call *mcount@GOT()' as before.
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
> > >
> > > Signed-off-by: Ard Biesheuvel 
> > >
> > > gcc/ChangeLog:
> > >
> > > PR target/119386
> > > * config/i386/i386.cc (x86_print_call_or_nop): Add @PLT suffix
> > > where appropriate.
> > > (x86_function_profiler): Fall through to x86_print_call_or_nop()
> > > for PIC codegen when flag_plt is set.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > PR target/119386
> > > * gcc.target/i386/pr119386-1.c: New test.
> > > * gcc.target/i386/pr119386-2.c: New test.
> > > ---
> > >  gcc/config/i386/i386.cc|  8 +++-
> > >  gcc/testsuite/gcc.target/i386/pr119386-1.c | 11 +++
> > >  gcc/testsuite/gcc.target/i386/pr119386-2.c | 12 
> > >  3 files changed, 30 insertions(+), 1 deletion(-)
> > >  create mode 100644 gcc/testsuite/gcc.target/i386/pr119386-1.c
> > >  create mode 100644 gcc/testsuite/gcc.target/i386/pr119386-2.c
> > >
> > > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > > index be5e27fc391..0b238c3dddc 100644
> > > --- a/gcc/config/i386/i386.cc
> > > +++ b/gcc/config/i386/i386.cc
> > > @@ -23154,6 +23154,12 @@ x86_print_call_or_nop (FILE *file, const char 
> > > *target)
> > >if (flag_nop_mcount || !strcmp (target, "nop"))
> > >  /* 5 byte nop: nopl 0(%[re]ax,%[re]ax,1) */
> > >  fprintf (file, "1:" ASM_BYTE "0x0f, 0x1f, 0x44, 0x00, 0x00\n");
> > > +  else if (!TARGET_PECOFF && flag_pic)
> > > +{
> > > +  gcc_assert (flag_plt);
> > > +
> > > +  fprintf (file, "1:\tcall\t%s@PLT\n", target);
> > > +}
> > >else
> > >  fprintf (file, "1:\tcall\t%s\n", target);
> > >  }
> > > @@ -23317,7 +23323,7 @@ x86_function_profiler (FILE *file, int labelno 
> > > ATTRIBUTE_UNUSED)
> > >   break;
> > > case CM_SMALL_PIC:
> > > case CM_MEDIUM_PIC:
> > > - if (!ix86_direct_extern_access)
> > > + if (!flag_plt)
> > > {
> > >   if (ASSEMBLER_DIALECT == ASM_INTEL)
> > > fprintf (file, "1:\tcall\t[QWORD PTR 
> > > %s@GOTPCREL[rip]]\n",
> > > diff --git a/gcc/testsuite/gcc.target/i386/pr119386-1.c 
> > > b/gcc/testsuite/gcc.target/i386/pr119386-1.c
> > > new file mode 100644
> > > index 000..174d00f1e27
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/i386/pr119386-1.c
> > > @@ -0,0 +1,11 @@
> > > +/* PR target/119386 */
> > > +/* { dg-do compile { target *-*-linux* } } */
> > > +/* { dg-options "-O2 -fpic -pg" } */
> > > +/* { dg-final { scan-assembler "call\[ \t\]mcount@PLT" { target { ! ia32 
> > > } } } } */
> > > +/* { dg-final { scan-assembler "call\[ \t\]\\*mcount@GOT\\(" { target 
> > > ia32 } } } */
> >
> > This is wrong for ia32, which should also generate "call mcount@PLT".
> >
>
> But it hasn't done that for a long time - it is hard to figure out
> from the Git history how long but at least 20 years IIUC
>
> So do you think this change should fix IA-32 as well? Note that the
> issue is about emitting 'call mcount' on 64-bit where 'call
> mcount@PLT' is needed, not about changing the indirect GOT based call
> to a PLT call.

Try this:

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 0c7cf5f827f..20059b775b9 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -23358,7 +23358,9 @@ x86_function_profiler (FILE *file, int labelno
ATTRIBUTE_UNUSED)
  "\tleal\t%sP%d@GOTOFF(%%ebx), %%" PROFILE_COUNT_REGISTER "\n",
  LPREFIX, labelno);
 #endif
-  if (ASSEMBLER_DIALECT == ASM_INTEL)
+  if (flag_plt)
+ x86_print_call_or_nop (f

[committed] d: Use CONSTRUCTOR_ZERO_PADDING_BITS in the D FE [PR117832]

[Iain Buclaw]

Hi,

This patch adds a new wrapper function for `build_constructor', and
calls it instead to ensure that all CONSTRUCTOR nodes explicitly created
by the front-end have CONSTRUCTOR_ZERO_PADDING_BITS set.

Some places may not be necessary as it's guaranteed for there to be no
padding in the type, such as D dynamic arrays.  Other places this gets
turned into a double-memset when optimizations are turned off, as the
front-end already generates a memset call to zero out all padding on
initializing a variable.  The optimizer sees through this so will
correctly clear all bits once, so this can be improved later as-needed.

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

Regards,
Iain.

---
PR d/117832

gcc/d/ChangeLog:

* d-tree.h (build_padded_constructor): New prototype.
* d-codegen.cc (build_padded_constructor): New function.
(d_array_value): Call it.
(build_memset_call): Likewise.
(build_struct_literal): Likewise.
(underlying_complex_expr): Likewise.
(build_array_from_val): Likewise.
(build_array_from_exprs): Likewise.
(d_build_call): Likewise.
(get_frame_for_symbol): Likewise.
* d-convert.cc (convert_for_rvalue): Likewise.
(convert_for_assignment): Likewise.
* decl.cc (class DeclVisitor): Likewise.
* expr.cc (class ExprVisitor): Likewise.
* modules.cc (layout_moduleinfo): Likewise.
* typeinfo.cc (class TypeInfoVisitor): Likewise.
---
 gcc/d/d-codegen.cc | 32 +++-
 gcc/d/d-convert.cc |  4 ++--
 gcc/d/d-tree.h |  1 +
 gcc/d/decl.cc  |  2 +-
 gcc/d/expr.cc  | 22 --
 gcc/d/modules.cc   |  4 ++--
 gcc/d/typeinfo.cc  |  8 
 7 files changed, 45 insertions(+), 28 deletions(-)

diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index ad71486e3ba..1a7575aac22 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -317,7 +317,7 @@ d_array_value (tree type, tree len, tree data)
   CONSTRUCTOR_APPEND_ELT (ce, len_field, len);
   CONSTRUCTOR_APPEND_ELT (ce, ptr_field, data);
 
-  return build_constructor (type, ce);
+  return build_padded_constructor (type, ce);
 }
 
 /* Returns value representing the array length of expression EXP.
@@ -898,7 +898,10 @@ build_memset_call (tree ptr, tree num)
 {
   tree cst = build_zero_cst (valtype);
   if (TREE_CODE (cst) == CONSTRUCTOR)
-   return build_memcpy_call (ptr, build_address (cst), num);
+   {
+ CONSTRUCTOR_ZERO_PADDING_BITS (cst) = 1;
+ return build_memcpy_call (ptr, build_address (cst), num);
+   }
 
   return modify_expr (build_deref (ptr), cst);
 }
@@ -1205,7 +1208,7 @@ build_struct_literal (tree type, vec  *init)
 {
   /* If the initializer was empty, use default zero initialization.  */
   if (vec_safe_is_empty (init))
-return build_constructor (type, NULL);
+return build_padded_constructor (type, NULL);
 
   /* Struct literals can be seen for special enums representing `_Complex',
  make sure to reinterpret the literal as the correct type.  */
@@ -1306,7 +1309,7 @@ build_struct_literal (tree type, vec  *init)
   /* Ensure that we have consumed all values.  */
   gcc_assert (vec_safe_is_empty (init) || ANON_AGGR_TYPE_P (type));
 
-  tree ctor = build_constructor (type, ve);
+  tree ctor = build_padded_constructor (type, ve);
 
   if (constant_p)
 TREE_CONSTANT (ctor) = 1;
@@ -1314,6 +1317,17 @@ build_struct_literal (tree type, vec  *init)
   return ctor;
 }
 
+/* Return a new zero padded CONSTRUCTOR node whose type is TYPE and values are
+   in the vec pointed to by VALS.  */
+
+tree
+build_padded_constructor (tree type, vec *vals)
+{
+  tree ctor = build_constructor (type, vals);
+  CONSTRUCTOR_ZERO_PADDING_BITS (ctor) = 1;
+  return ctor;
+}
+
 /* Given the TYPE of an anonymous field inside T, return the
FIELD_DECL for the field.  If not found return NULL_TREE.
Because anonymous types can nest, we must also search all
@@ -1647,7 +1661,7 @@ underlying_complex_expr (tree type, tree expr)
 real_part (expr));
   CONSTRUCTOR_APPEND_ELT (ve, TREE_CHAIN (TYPE_FIELDS (type)),
 imaginary_part (expr));
-  return build_constructor (type, ve);
+  return build_padded_constructor (type, ve);
 }
 
   /* Replace type in the reinterpret cast with a cast to the record type.  */
@@ -1852,7 +1866,7 @@ build_array_from_val (Type *type, tree val)
   for (size_t i = 0; i < dims; i++)
 CONSTRUCTOR_APPEND_ELT (elms, size_int (i), val);
 
-  return build_constructor (build_ctype (type), elms);
+  return build_padded_constructor (build_ctype (type), elms);
 }
 
 /* Build a static array of type TYPE from an array of EXPS.
@@ -1886,7 +1900,7 @@ build_array_from_exprs (Type *type, Expressions *exps, 
bool const_p)
 init = build_memset_call (var);
 
   /* Initialize the temporary.  */
-  tree assign = modify_expr (var,

Re: [PATCH] deref-before-check-pr113253.c: Fix bogus warnings on lp32

[Jonathan Yong]

On 4/7/25 3:48 PM, Jonathan Yong wrote:

Attached patch OK for master branch?
Will push soon if there are no objections.


Pushed to master branch.

Re: [PATCH v1] RISC-V: Refine the testcases for cond_widen_complicate-3

[Robin Dapp]

I see, reverted. Thanks Robin for reminder.


Thanks!

BTW and just for open discussion, is this really a good way for such kind of 
tests?
Though most of the tests are similar like this but it may hide possible 
unexpected results up to a point.


Yeah we have several flaky tests and in those cases we should try to change the 
test criteria.  This one here, though, I wouldn't count to them as it expects a 
certain number of widening ops.  Due to the combine changes (lack of 2->2 
combinations I think) we couldn't achieve the result we expected and the code 
was indeed slightly worse.


--
Regards
Robin

[PATCH] c++: Use G_ instead of _ around cp/errors.cc gcc-internal-format strings [PR119684]

[Jakub Jelinek]

Hi!

These pp_printf/pp_verbatim format strings should be gcc-internal-format,
they use the pretty-print.cc format specifier handling rather than libc
*printf, but pp_printf/pp_verbatim are intentionally not handled through
exgettext because not everything done through them should be translated
(e.g. its use for dump files shouldn't be).
In addition, composing translatable messages from
"in requirements " and later on "with " might make it harder to be
translated.

I've verified these strings (at least those which don't use format
specifiers added post GCC 4.3 which gettext doesn't handle) are properly
marked as gcc-internal-format in gcc.pot.  The lack of that caused
ICEs on German translation of the "%s%s%sIn instantiation of %q#D:\n"
message because it contained too many %s.

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

2025-04-09  Jakub Jelinek  

PR translation/119684
* error.cc (cp_print_error_function): Use G_ instead of _ for
pp_printf arguments.
(function_category): Use G_ instead of _.
(print_instantiation_full_context): Use G_ instead of _ in pp_verbatim
arguments.
(print_location): Likewise.
(print_instantiation_partial_context): Likewise.
(maybe_print_constexpr_context): Likewise.
(print_constrained_decl_info): Use G_() around pp_verbatim argument.
(print_concept_check_info): Likewise.
(print_constraint_context_head): Likewise.
(print_requires_expression_info): Likewise.  Merge separate pp_verbatim
"in requirements " and "with " into one with conditional messages.

--- gcc/cp/error.cc.jj  2025-04-08 14:08:50.202296469 +0200
+++ gcc/cp/error.cc 2025-04-09 09:13:27.467826410 +0200
@@ -3788,18 +3788,18 @@ cp_print_error_function (diagnostic_text
{
  if (text_output.show_column_p () && s.column != 0)
pp_printf (pp,
-  _("inlined from %qD at %r%s:%d:%d%R"),
+  G_("inlined from %qD at %r%s:%d:%d%R"),
   fndecl,
   "locus", s.file, s.line, s.column);
  else
pp_printf (pp,
-  _("inlined from %qD at %r%s:%d%R"),
+  G_("inlined from %qD at %r%s:%d%R"),
   fndecl,
   "locus", s.file, s.line);
 
}
  else
-   pp_printf (pp, _("inlined from %qD"),
+   pp_printf (pp, G_("inlined from %qD"),
   fndecl);
}
}
@@ -3825,22 +3825,22 @@ function_category (tree fn)
   && DECL_FUNCTION_MEMBER_P (fn))
 {
   if (DECL_STATIC_FUNCTION_P (fn))
-   return _("In static member function %qD");
+   return G_("In static member function %qD");
   else if (DECL_COPY_CONSTRUCTOR_P (fn))
-   return _("In copy constructor %qD");
+   return G_("In copy constructor %qD");
   else if (DECL_CONSTRUCTOR_P (fn))
-   return _("In constructor %qD");
+   return G_("In constructor %qD");
   else if (DECL_DESTRUCTOR_P (fn))
-   return _("In destructor %qD");
+   return G_("In destructor %qD");
   else if (LAMBDA_FUNCTION_P (fn))
-   return _("In lambda function");
+   return G_("In lambda function");
   else if (DECL_XOBJ_MEMBER_FUNCTION_P (fn))
-   return _("In explicit object member function %qD");
+   return G_("In explicit object member function %qD");
   else
-   return _("In member function %qD");
+   return G_("In member function %qD");
 }
   else
-return _("In function %qD");
+return G_("In function %qD");
 }
 
 /* Disable warnings about missing quoting in GCC diagnostics for
@@ -3867,8 +3867,8 @@ print_instantiation_full_context (diagno
   char *indent = text_output.build_indent_prefix (true);
   pp_verbatim (text_output.get_printer (),
   p->list_p ()
-  ? _("%s%s%sIn substitution of %qS:\n")
-  : _("%s%s%sIn instantiation of %q#D:\n"),
+  ? G_("%s%s%sIn substitution of %qS:\n")
+  : G_("%s%s%sIn instantiation of %q#D:\n"),
   indent,
   show_file ? LOCATION_FILE (location) : "",
   show_file ? ": " : "",
@@ -3888,10 +3888,10 @@ print_location (diagnostic_text_output_f
   expanded_location xloc = expand_location (loc);
   pretty_printer *const pp = text_output.get_printer ();
   if (text_output.show_column_p ())
-pp_verbatim (pp, _("%r%s:%d:%d:%R   "),
+pp_verbatim (pp, G_("%r%s:%d:%d:%R   "),
 "locus", xloc.file, xloc.line, xloc.column);
   else
-pp_verbatim (pp, _("%r%s:%d:%R   "),
+pp_verbatim (pp, G_("%r%s:%d:%R   "),

[PATCH] riscv: Fix r15-9270 fallout on RISC-V

[Jakub Jelinek]

Hi!

On Wed, Apr 09, 2025 at 02:38:01PM +0200, Mark Wielaard wrote:
> Unfortunately this seems to have broken the riscv bootstrap:
> https://builder.sourceware.org/buildbot/#/builders/337/builds/105
> 
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: 
> enumeration value ‘TCTX_OMP_MAP’ not handled in switch [-Werror=switch]
>  4730 |   switch (context)
>   |  ^
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: 
> enumeration value ‘TCTX_OMP_MAP_IMP_REF’ not handled in switch 
> [-Werror=switch]
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: 
> enumeration value ‘TCTX_OMP_PRIVATE’ not handled in switch [-Werror=switch]
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: 
> enumeration value ‘TCTX_OMP_FIRSTPRIVATE’ not handled in switch 
> [-Werror=switch]
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: 
> enumeration value ‘TCTX_OMP_DEVICE_ADDR’ not handled in switch 
> [-Werror=switch]
> cc1plus: all warnings being treated as errors

Indeed, riscv-vector-builtins.cc IMHO needs pretty much the same
changes as aarch64, just with s/SVE/RVV/g.
I've also left out default: break; so that it is caught next time
somebody adds further enumerators.

Tested with compilation of x86_64-linux -> riscv64-linux cross,
ok for trunk?

2025-04-09  Jakub Jelinek  

* config/riscv/riscv-vector-builtins.cc (verify_type_context):
Diagnose RVV types for a given OpenMP context.

diff --git a/gcc/config/riscv/riscv-vector-builtins.cc 
b/gcc/config/riscv/riscv-vector-builtins.cc
index d2fe849c693..61dcdabbb40 100644
--- a/gcc/config/riscv/riscv-vector-builtins.cc
+++ b/gcc/config/riscv/riscv-vector-builtins.cc
@@ -4724,7 +4724,11 @@ bool
 verify_type_context (location_t loc, type_context_kind context, const_tree 
type,
 bool silent_p)
 {
-  if (!sizeless_type_p (type))
+  const_tree tmp = type;
+  if (omp_type_context (context) && POINTER_TYPE_P (type))
+tmp = strip_pointer_types (tmp);
+
+  if (!sizeless_type_p (tmp))
 return true;
 
   switch (context)
@@ -4796,6 +4800,34 @@ verify_type_context (location_t loc, type_context_kind 
context, const_tree type,
error_at (loc, "capture by copy of RVV type %qT", type);
 
   return false;
+
+case TCTX_OMP_MAP:
+  if (!silent_p)
+   error_at (loc, "RVV type %qT not allowed in % clause", type);
+  return false;
+
+case TCTX_OMP_MAP_IMP_REF:
+  if (!silent_p)
+   error ("cannot reference %qT object types in % region", type);
+  return false;
+
+case TCTX_OMP_PRIVATE:
+  if (!silent_p)
+   error_at (loc, "RVV type %qT not allowed in"
+ " % % clause", type);
+  return false;
+
+case TCTX_OMP_FIRSTPRIVATE:
+  if (!silent_p)
+   error_at (loc, "RVV type %qT not allowed in"
+ " % % clause", type);
+  return false;
+
+case TCTX_OMP_DEVICE_ADDR:
+  if (!silent_p)
+   error_at (loc, "RVV type %qT not allowed in"
+ " % device clauses", type);
+  return false;
 }
 
   gcc_unreachable ();

Jakub

[PATCH] c++: alias_ctad_tweaks ICE w/ inherited CTAD [PR119687]

[Patrick Palka]

Bootstrap and regtest running on x86_64-pc-linux-gnu, does this look
OK for trunk/14 if successful?

On a similar note, as a small optimization in deduction_guides_for I
think we can replace the lookup_add loop with a single call to
lookup_add, but I'll leave that for GCC 16.

-- >8 --

With inherited CTAD the set of guides may be a two-dimensional overload
set (i.e. OVERLOADs containing OVERLOADs) so alias_ctad_tweaks (which
also handles the inherited CTAD transformation) needs to use the 2D-aware
lkp_iterator instead of ovl_iterator.  Actually, we might as well use
the more idiomatic lkp_range here.

PR c++/119687

gcc/cp/ChangeLog:

* pt.cc (alias_ctad_tweaks): Use lkp_range / lkp_iterator
instead of ovl_iterator.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/class-deduction-inherited8.C: New test.
---
 gcc/cp/pt.cc  |  3 +--
 .../g++.dg/cpp23/class-deduction-inherited8.C | 21 +++
 2 files changed, 22 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp23/class-deduction-inherited8.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index ffd23d9cd13b..c73db02e42e1 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -30922,9 +30922,8 @@ alias_ctad_tweaks (tree tmpl, tree uguides)
   tree aguides = NULL_TREE;
   tree atparms = INNERMOST_TEMPLATE_PARMS (fullatparms);
   unsigned natparms = TREE_VEC_LENGTH (atparms);
-  for (ovl_iterator iter (uguides); iter; ++iter)
+  for (tree f : lkp_range (uguides))
 {
-  tree f = *iter;
   tree in_decl = f;
   location_t loc = DECL_SOURCE_LOCATION (f);
   tree ret = TREE_TYPE (TREE_TYPE (f));
diff --git a/gcc/testsuite/g++.dg/cpp23/class-deduction-inherited8.C 
b/gcc/testsuite/g++.dg/cpp23/class-deduction-inherited8.C
new file mode 100644
index ..79fceadd9e1c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp23/class-deduction-inherited8.C
@@ -0,0 +1,21 @@
+// PR c++/119687
+// { dg-do compile { target c++20 } }
+
+template  class QFlagsStorage{};
+
+template  struct QFlagsStorageHelper : QFlagsStorage  {
+  using QFlagsStorage::QFlagsStorage;
+
+public:
+  QFlagsStorageHelper(Enum);
+};
+
+template  struct QFlags : public QFlagsStorageHelper {
+  using Base = QFlagsStorageHelper;
+  using Base::Base;
+  QFlags(Enum);
+};
+
+void f(int flag) {
+  QFlags{int{}};
+}
-- 
2.49.0.221.g485f5f8636

Re: .ACCESS_WITH_SIZE and pointer ranges

[Qing Zhao]

> On Apr 9, 2025, at 11:31, Siddhesh Poyarekar  wrote:
> 
> On 2025-04-09 08:30, Qing Zhao wrote:
>> After expand phase, .ACCESS_WITH_SIZE will be replaced by its first argument.
>> And all the size expression before the call to .ACCESS_WITH_SIZE might be 
>> dead
>> code eliminated later in the RTL phases.
>> So, I don’t think there will be run-time overhead concern.
>> However, the IR size increase in the TREE optimization phase might impact the
>> Optimization heuristics that base on IR size, for example, inlining 
>> decision, etc.
>> That’s the major concern for me.
> 
> I mean that the IR size estimation should also account for the fact that the 
> runtime overhead of .ACCESS_WITH_SIZE is zero.

Yes, theoretically, we could adjust all the impacted heuristics in GCC to 
ignore IR size 
increase due to the call to .ACCESS_WITH_SIZE and the size computations before 
it. 
That’s doable. -:) 

> 
>>> A good measure of this could be to get a sense of additional coverage one 
>>> could get for __bdos with this change vs without it for, e.g. the kernel.  
>>> You could maybe use fortify-metrics[1] to find that.
>> Why there will be additional coverage with this change? (This change means to
>> replace pointer reference with structure type with FAM by a call to 
>> .ACCESS_WITH_SIZE
>> in C FE)
>> Based on my current patch (expand the counted_by refs to size expressions by 
>> demand for __bdos),
>> All the __bdos should be covered, right?
> 
> Yes, I mean if you're concerned that there's a performance tradeoff due to 
> this change, you could quantify the coverage improvement to make the case 
> that there's a measurable improvement in security in the generated code, 
> which justifies the performance overhead.

> 
> Something like: "The total coverage for __bdos improved by X% for the kernel 
> build, which justifies the additional overhead of up to N instructions for 
> the size expression caused by this patch".

If the performance impact cannot be avoided, yes, we can justify like this.
However, we can avoid this potential performance impact by not generating
the call to .ACCESS_WITH_SIZE in C FE.

Anyway, I agree that replacing every variable with a pointer type to a structure
 with FAM and counted_by attribute by size computations and a call to 
.ACCESS_WITH_SIZE 
in C FE might be a cleaner implementation. 

Need some study in C FE on how to implement this.

Thanks.

Qing


> 
> Thanks,
> Sid

[committed] [RISC-V] Fix more fallout from combine.c changes

[Jeff Law]

Trivial fallout from the recent combine work.  We end up with a srai 
rather than an xor in some of the saturation sequences.  Both variants 
look equally performant, so I'm just adjusting the expected test output.


Pushing to the trunk.

Jeff

commit c08d717ce9e18dcfa5b4efe49a5f570ac32fd1cf
Author: Jeff Law 
Date:   Wed Apr 2 14:30:34 2025 -0600

Revert "RISC-V: Make VXRM as global register [PR118103]"

This reverts commit 1c8e6734d2dd3a6236d94c6e4e0c6780f35ede9f.

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 38f3ae7cd84..36a210f02fc 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -10914,9 +10914,7 @@ riscv_conditional_register_usage (void)
call_used_regs[regno] = 1;
 }
 
-  if (TARGET_VECTOR)
-global_regs[VXRM_REGNUM] = 1;
-  else
+  if (!TARGET_VECTOR)
 {
   for (int regno = V_REG_FIRST; regno <= V_REG_LAST; regno++)
fixed_regs[regno] = call_used_regs[regno] = 1;
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr118103-2.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr118103-2.c
deleted file mode 100644
index d6e3aa09077..000
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr118103-2.c
+++ /dev/null
@@ -1,40 +0,0 @@
-/* { dg-do compile } */
-/* { dg-options "-O3 -march=rv64gcv -mabi=lp64d" } */
-
-#include "riscv_vector.h"
-
-#define N 4
-uint16_t a[N];
-uint16_t b[N];
-uint16_t c[N];
-
-void initialize ()
-{
-  uint16_t tmp_0[N] = { 0xfff, 3213, 238, 275, };
-
-  for (int i = 0; i < N; ++i)
-a[i] = b[i] = tmp_0[i];
-
-  for (int i = 0; i < N; ++i)
-c[i] = 0;
-}
-
-void compute ()
-{
-  size_t vl = __riscv_vsetvl_e16m1 (N);
-  vuint16m1_t va = __riscv_vle16_v_u16m1 (a, vl);
-  vuint16m1_t vb = __riscv_vle16_v_u16m1 (b, vl);
-  vuint16m1_t vc = __riscv_vaaddu_vv_u16m1 (va, vb, __RISCV_VXRM_RDN, vl);
-
-  __riscv_vse16_v_u16m1 (c, vc, vl);
-}
-
-int main ()
-{
-  initialize ();
-  compute();
-
-  return 0;
-}
-
-/* { dg-final { scan-assembler-times {csrwi\s+vxrm,\s*[01234]} 2 } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr118103-run-2.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr118103-run-2.c
deleted file mode 100644
index 89150d4f6b5..000
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr118103-run-2.c
+++ /dev/null
@@ -1,44 +0,0 @@
-/* { dg-do run { target { riscv_v } } } */
-/* { dg-options "-O3" } */
-
-#include "riscv_vector.h"
-
-#define N 4
-uint16_t a[N];
-uint16_t b[N];
-uint16_t c[N];
-
-void initialize () {
-  uint16_t tmp_0[N] = { 0xfff, 3213, 238, 275, };
-  uint16_t tmp_1[N] = { 0x2,  823,  39,   9, };
-
-  for (int i = 0; i < N; ++i)
-{
-  a[i] = tmp_0[i];
-  b[i] = tmp_1[i];
-}
-
-  for (int i = 0; i < N; ++i)
-c[i] = 0;
-}
-
-void compute ()
-{
-  size_t vl = __riscv_vsetvl_e16m1 (N);
-  vuint16m1_t va = __riscv_vle16_v_u16m1 (a, vl);
-  vuint16m1_t vb = __riscv_vle16_v_u16m1 (b, vl);
-  vuint16m1_t vc = __riscv_vaaddu_vv_u16m1 (va, vb, __RISCV_VXRM_RDN, vl);
-
-  __riscv_vse16_v_u16m1 (c, vc, vl);
-}
-
-int main ()
-{
-  initialize ();
-  compute ();
-
-  if (c[0] != 2048)
-__builtin_abort ();
-
-  return 0;
-}

Re: [PATCH] libgcobol: Handle long double as an alternate IEEE754 128b

[Rainer Orth]

Hi Iain,

> Here is what I'm testing as an incremental fix, so far OK on x86_64-darwin
> and powerpcle64 (GLIBC 2.34) .. others in progress.  Does it help the
> Solaris cases?

I'll give it a try.  Here's what I have (I believe it's more readable in
some cases), but as I said something's not right yet (probably something
very stupid).

I'm taking a step back now, going for your original patch with
__float128 support added on sparc to have a baseline, than retry both
your and my patch afresh.

Rainer

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


2025-04-09  Rainer Orth  

libgcobol:
* libgcobol-fp.h (FP128_FMT): Define.
[!HAVE_STRTOF128] (strtof128): Provide fallback.
* intrinsic.cc [!HAVE_STRTOF128] (strtof128): Remove.
(WEIRD_TRANSCENDENT_RETURN_VALUE): Define using
GCOB_FP128_LITERAL.
* libgcobol.cc [!HAVE_STRFROMF128] (strfromf128): New function.
[!HAVE_STRTOF128] (strtof128): Remove.
(format_for_display_internal): Always use strfromf128.  Construct
format string using FP128_FMT.

# HG changeset patch
# Parent  cce3487b5da0bb5001444ca0948d7cbc6d9a5fbf
libgcobol: Support 128-bit IEEE long double

diff --git a/libgcobol/intrinsic.cc b/libgcobol/intrinsic.cc
--- a/libgcobol/intrinsic.cc
+++ b/libgcobol/intrinsic.cc
@@ -54,20 +54,11 @@
 #include "libgcobol.h"
 #include "charmaps.h"
 
-
-#if !defined (HAVE_STRTOF128)
-# if USE_QUADMATH
-#  define strtof128 strtoflt128
-# else
-#  error "no available string to float 128"
-# endif
-#endif
-
 #pragma GCC diagnostic ignored "-Wformat-truncation"
 
 #define JD_OF_1601_01_02 2305812.5
 
-#define WEIRD_TRANSCENDENT_RETURN_VALUE (0.0Q)
+#define WEIRD_TRANSCENDENT_RETURN_VALUE GCOB_FP128_LITERAL (0.0)
 #define NO_RDIGITS (0)
 
 struct cobol_tm
diff --git a/libgcobol/libgcobol-fp.h b/libgcobol/libgcobol-fp.h
--- a/libgcobol/libgcobol-fp.h
+++ b/libgcobol/libgcobol-fp.h
@@ -27,22 +27,35 @@ see the files COPYING3 and COPYING.RUNTI
 // Use long double, l suffix on calls, l or L suffix in literals
 # define GCOB_FP128 long double
 # define GCOB_FP128_LITERAL(lit) (lit ## l)
+# define FP128_FMT "L"
 # define FP128_FUNC(funcname) funcname ## l
 #elif __FLT128_MANT_DIG__ == 113 && __FLT128_MIN_EXP__ == -16381 \
  && defined(USE_IEC_60559)
 // Use _Float128, f128 suffix on calls, f128 or F128 suffix on literals
 # define GCOB_FP128 _Float128
 # define GCOB_FP128_LITERAL(lit) (lit ## f128)
+# define FP128_FMT ""
 # define FP128_FUNC(funcname) funcname ## f128
 #elif __FLT128_MANT_DIG__ == 113 && __FLT128_MIN_EXP__ == -16381
 // Use __float128, q suffix on calls, q or Q suffix on literals
 # define GCOB_FP128 __float128
 # define GCOB_FP128_LITERAL(lit) (lit ## q)
+# define FP128_FMT "Q"
 # define FP128_FUNC(funcname) funcname ## q
 #else
 # error "libgcobol requires 128b floating point"
 #endif
 
+#if !defined (HAVE_STRTOF128)
+# if USE_QUADMATH
+#  define strtof128 strtoflt128
+# elif __LDBL_MANT_DIG__ == 113 && __LDBL_MIN_EXP__ == -16381
+#  define strtof128 strtold
+# else
+#  error "no available string to float 128"
+# endif
+#endif
+
 #if USE_QUADMATH
 /* We will assume that unless we found the 128 to/from string and some
representative trig functions, we need libquadmath to support those.  */
diff --git a/libgcobol/libgcobol.cc b/libgcobol/libgcobol.cc
--- a/libgcobol/libgcobol.cc
+++ b/libgcobol/libgcobol.cc
@@ -94,17 +94,17 @@ strfromf64 (char *s, size_t n, const cha
 #endif
 
 #if !defined (HAVE_STRFROMF128)
-# if !USE_QUADMATH
+static int
+strfromf128 (char *s, size_t n, const char *f, long double v)
+{
+# if USE_QUADMATH
+  return quadmath_snprintf(s, n, f, v);
+# elif __LDBL_MANT_DIG__ == 113 && __LDBL_MIN_EXP__ == -16381
+  return snprintf (s, n, f, v);
+# else
 #  error "no available float 128 to string"
 # endif
-#endif
-
-#if !defined (HAVE_STRTOF128)
-# if USE_QUADMATH
-#  define strtof128 strtoflt128
-# else
-#  error "no available string to float 128"
-# endif
+}
 #endif
 
 // This couldn't be defined in symbols.h because it conflicts with a LEVEL66
@@ -3265,11 +3265,7 @@ format_for_display_internal(char **dest,
   // on a 16-bit boundary.
   GCOB_FP128 floatval;
   memcpy(&floatval, actual_location, 16);
-#if !defined (HAVE_STRFROMF128) && USE_QUADMATH
-  quadmath_snprintf(ach, sizeof(ach), "%.36QE", floatval);
-#else
-  strfromf128(ach, sizeof(ach), "%.36E", floatval);
-#endif
+  strfromf128(ach, sizeof(ach), "%.36" FP128_FMT "E", floatval);
   char *p = strchr(ach, 'E');
   if( !p )
 {
@@ -3291,13 +3287,8 @@ format_for_display_internal(char **dest,
 
   int precision = 36 - exp;
   char achFormat[24];
-#if !defined (HAVE_STRFROMF128) && USE_QUADMATH
-  sprintf(achFormat, "%%.%dQf", precision);
-  quadmath_snprintf(ach, sizeof(ach), achFormat,

[PATCH] libbacktrace: Add hpux fileline support

[John David Anglin]

Tested on hppa64-hp-hpux11.11.

Okay?

Dave
---

libbacktrace: Add hpux fileline support

Fixes libstdc++ stacktrace tests.

2025-04-09  John David Anglin  

libbacktrace/ChangeLog:
* fileline.c (hpux_get_executable_path): New.
(fileline_initialize): Add pass to get hpux executable path.

diff --git a/libbacktrace/fileline.c b/libbacktrace/fileline.c
index c9fd86b8c0c..e46ea05e528 100644
--- a/libbacktrace/fileline.c
+++ b/libbacktrace/fileline.c
@@ -66,6 +66,35 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #define getexecname() NULL
 #endif
 
+#ifdef __hpux__
+#include 
+
+static char *
+hpux_get_executable_path (struct backtrace_state *state,
+ backtrace_error_callback error_callback, void *data)
+{
+  struct shl_descriptor *desc;
+  size_t len = sizeof (struct shl_descriptor);
+
+  desc = backtrace_alloc (state, len, error_callback, data);
+  if (desc == NULL)
+return NULL;
+
+  if (shl_get_r (0, desc) == -1)
+{
+  backtrace_free (state, desc, len, error_callback, data);
+  return NULL;
+}
+
+  return desc->filename;
+}
+
+#else
+
+#define hpux_get_executable_path(state, error_callback, data) NULL
+
+#endif
+
 #if !defined (HAVE_KERN_PROC_ARGS) && !defined (HAVE_KERN_PROC)
 
 #define sysctl_exec_name1(state, error_callback, data) NULL
@@ -245,7 +274,7 @@ fileline_initialize (struct backtrace_state *state,
 
   descriptor = -1;
   called_error_callback = 0;
-  for (pass = 0; pass < 10; ++pass)
+  for (pass = 0; pass < 11; ++pass)
 {
   int does_not_exist;
 
@@ -285,6 +314,9 @@ fileline_initialize (struct backtrace_state *state,
case 9:
  filename = windows_get_executable_path (buf, error_callback, data);
  break;
+   case 10:
+ filename = hpux_get_executable_path (state, error_callback, data);
+ break;
default:
  abort ();
}


signature.asc
Description: PGP signature

Re: [PATCH GCC 14] c++: ICE with nested default targ lambdas [PR119574]

[Jason Merrill]

On 4/8/25 10:29 AM, Patrick Palka wrote:

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for the 14 branch?


OK.


-- >8 --

In GCC 14 we fixed PR116567 in a more conservative way that doesn't
distinguish between the two kinds of deferred substitutions, and we
instead ICE from get_innermost_template_args due to TMPL_PARMS_DEPTH
(2) being greater than the depth (1) of the augmented args.

This patch works around the ICE in a best effort kind of way by guarding
the get_innermost_template_args call appropriately; I don't think it's
possible to get this completely right in GCC 14 without backporting the
proper fix for PR116567.

Note that lambda-targ13b.C present in the GCC 15 version of this patch
never worked in GCC 14, and still doesn't work, so it's not incuded in
this patch.

PR c++/119574

gcc/cp/ChangeLog:

* pt.cc (tsubst_lambda_expr): Don't call
get_innermost_template_args if we're requesting too many
levels.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-targ13.C: New test.
* g++.dg/cpp2a/lambda-targ13a.C: New test.
---
  gcc/cp/pt.cc| 3 ++-
  gcc/testsuite/g++.dg/cpp2a/lambda-targ13.C  | 7 +++
  gcc/testsuite/g++.dg/cpp2a/lambda-targ13a.C | 8 
  3 files changed, 17 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-targ13.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-targ13a.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 2efc7eb19e87..5b9a9c611f24 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -19708,7 +19708,8 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
tree ctx_parms = DECL_TEMPLATE_PARMS (DECL_TI_TEMPLATE (oldfn));
if (generic_lambda_fn_p (oldfn))
ctx_parms = TREE_CHAIN (ctx_parms);
-  args = get_innermost_template_args (args, TMPL_PARMS_DEPTH (ctx_parms));
+  if (TMPL_ARGS_DEPTH (args) > TMPL_PARMS_DEPTH (ctx_parms))
+   args = get_innermost_template_args (args, TMPL_PARMS_DEPTH (ctx_parms));
  }
  
tree r = build_lambda_expr ();

diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-targ13.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-targ13.C
new file mode 100644
index ..8fd0a311e056
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-targ13.C
@@ -0,0 +1,7 @@
+// PR c++/119574
+// { dg-do compile { target c++20 } }
+
+template  () {})>
+void f(F op = {}) { op(); }
+
+int main() { f(); }
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-targ13a.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-targ13a.C
new file mode 100644
index ..8aaefd93356c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-targ13a.C
@@ -0,0 +1,8 @@
+// PR c++/119574
+// A version of lambda-targ13.C with extra template parameters.
+// { dg-do compile { target c++20 } }
+
+template  () {})>
+void f(F op = {}) { op(); }
+
+int main() { f(); }

[PATCH v2] RISC-V: Do not lift up vsetvl into non-transparent blocks [PR119547].

[Robin Dapp]

Hi,

when lifting up a vsetvl into a block we currently don't consider the
block's transparency with respect to the vsetvl as in other parts of the
pass.  This patch does not perform the lift when transparency is not
guaranteed.

This condition is more restrictive than necessary as we can still
perform a vsetvl lift if the conflicting register is only every used
in vsetvls and no regular insns but given how late we are in the GCC 15
cycle it seems better to defer this.  Therefore
gcc.target/riscv/rvv/vsetvl/avl_single-68.c is XFAILed for now.

This issue was found in OpenCV where it manifests as a runtime error.
Zhijin Zeng debugged PR119547 and provided an initial patch.

V2 now uses the transparency property rather than the manual approach before, 
both because it is cleaner and also because it helps with the go ICE

in PR119533.

Regtested on rv64gcv_zvl512b.

Regards
Robin

Reported-By: 曾治金 

PR target/119547

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (pre_vsetvl::earliest_fuse_vsetvl_info):
Do not perform lift if block is not transparent.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/vsetvl/avl_single-68.c: xfail.
* g++.target/riscv/rvv/autovec/pr119547.C: New test.
* g++.target/riscv/rvv/autovec/pr119547-2.C: New test.
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-10.c: Adjust.
---
gcc/config/riscv/riscv-vsetvl.cc  |  12 +
.../g++.target/riscv/rvv/autovec/pr119547-2.C | 212 ++
.../g++.target/riscv/rvv/autovec/pr119547.C   |  82 +++
.../riscv/rvv/vsetvl/avl_single-68.c  |   8 +-
.../riscv/rvv/vsetvl/vlmax_switch_vtype-10.c  |   4 +-
5 files changed, 315 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547-2.C
create mode 100644 gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547.C

diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index 0ac2538f596..c4046bcc345 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -3022,6 +3022,18 @@ pre_vsetvl::earliest_fuse_vsetvl_info (int iter)
  continue;
}

+ /* We cannot lift a vsetvl into the source block if the block is
+not transparent WRT to it.
+This is too restrictive for blocks where a register's use only
+feeds into vsetvls and no regular insns.  One example is the
+test rvv/vsetvl/avl_single-68.c which is currently XFAILed for
+that reason.
+In order to support this case we'd need to check the vsetvl's
+AVL operand's uses in the source block and make sure they are
+only used in other vsetvls.  */
+ if (!bitmap_bit_p (m_transp[eg->src->index], expr_index))
+   continue;
+
  if (dump_file && (dump_flags & TDF_DETAILS))
{
  fprintf (dump_file,
diff --git a/gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547-2.C 
b/gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547-2.C
new file mode 100644
index 000..1200ae04a27
--- /dev/null
+++ b/gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547-2.C
@@ -0,0 +1,212 @@
+/* { dg-do run } */
+/* { dg-require-effective-target riscv_v_ok } */
+/* { dg-options "-O3 -march=rv64gcv -mabi=lp64d 
--param=logical-op-non-short-circuit=0" } */
+
+#include 
+
+using v_uint8 = vuint8m2_t;
+using v_int8 = vint8m2_t;
+using v_uint16 = vuint16m2_t;
+using v_int16 = vint16m2_t;
+using v_uint32 = vuint32m2_t;
+using v_int32 = vint32m2_t;
+using v_uint64 = vuint64m2_t;
+using v_int64 = vint64m2_t;
+using v_float32 = vfloat32m2_t;
+using v_float64 = vfloat64m2_t;
+
+using uchar = unsigned char;
+using schar = signed char;
+using ushort = unsigned short;
+using uint = unsigned int;
+using uint64 = unsigned long int;
+using int64 = long int;
+
+struct Size
+{
+  int width;
+  int height;
+};
+
+template  struct VTraits;
+
+template <> struct VTraits
+{
+  static inline int vlanes () { return __riscv_vsetvlmax_e32m1 (); }
+  using lane_type = int32_t;
+  static const int max_nlanes = 1024 / 32 * 2;
+};
+template <> struct VTraits
+{
+  static inline int vlanes () { return __riscv_vsetvlmax_e32m2 (); }
+  using lane_type = int32_t;
+  static const int max_nlanes = 1024 / 32 * 2;
+};
+template <> struct VTraits
+{
+  static inline int vlanes () { return __riscv_vsetvlmax_e32m4 (); }
+  using lane_type = int32_t;
+  static const int max_nlanes = 1024 / 32 * 2;
+};
+template <> struct VTraits
+{
+  static inline int vlanes () { return __riscv_vsetvlmax_e32m8 (); }
+  using lane_type = int32_t;
+  static const int max_nlanes = 1024 / 32 * 2;
+};
+
+template <> struct VTraits
+{
+  static inline int vlanes () { return __riscv_vsetvlmax_e64m1 (); }
+  using lane_type = double;
+  static const int max_nlanes = 1024 / 64 * 2;
+};
+template <> struct VTraits
+{
+  static inline int vlanes () 

Re: [PATCH v4 1/2] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

[Uros Bizjak]

On Wed, Apr 9, 2025 at 6:21 PM H.J. Lu  wrote:

>   fprintf (file, "1:\tcall\t*%s@GOT(%%ebx)\n", mcount_name);
> diff --git a/gcc/testsuite/gcc.target/i386/pr119386-1.c
> b/gcc/testsuite/gcc.target/i386/pr119386-1.c
> index 174d00f1e27..56e44c89859 100644
> --- a/gcc/testsuite/gcc.target/i386/pr119386-1.c
> +++ b/gcc/testsuite/gcc.target/i386/pr119386-1.c
> @@ -1,8 +1,7 @@
>  /* PR target/119386 */
>  /* { dg-do compile { target *-*-linux* } } */
>  /* { dg-options "-O2 -fpic -pg" } */
> -/* { dg-final { scan-assembler "call\[ \t\]mcount@PLT" { target { !
> ia32 } } } } */
> -/* { dg-final { scan-assembler "call\[ \t\]\\*mcount@GOT\\(" { target
> ia32 } } } */
> +/* { dg-final { scan-assembler "call\[ \t\]mcount@PLT" } } */

Uh, I know this is my part, but please put "+" after "\[ \t]" at all
instances here and in pr119386-2.c. This will handle all sequences of
whitespace (it doesn't fail ATM, because the compiler always emits one
"\t" after "call").

Uros.

[committed] d: Fix forward referenced enums missing type names in debug info [PR118309]

[Iain Buclaw]

Hi,

This patch fixes a crash seen when gdb was debugging D programs.

Calling `rest_of_type_compilation' as the D types were built meant that
debug info was being emitted before all forward references were
resolved, resulting in DW_AT_name's to be missing.

Instead, defer outputting type debug information until all modules have
been parsed and generated in `d_finish_compilation'.

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

Regards,
Iain.

---
PR d/118309

gcc/d/ChangeLog:

* modules.cc: Include debug.h
(d_finish_compilation): Call debug_hooks->type_decl on all TYPE_DECLs.
* types.cc: Remove toplev.h include.
(finish_aggregate_type): Don't call rest_of_type_compilation or
rest_of_decl_compilation on type.
(TypeVisitor::visit (TypeEnum *)): Likewise.

gcc/testsuite/ChangeLog:

* gdc.dg/debug/dwarf2/pr118309.d: New test.
---
 gcc/d/modules.cc |  9 +
 gcc/d/types.cc   | 15 ++--
 gcc/testsuite/gdc.dg/debug/dwarf2/pr118309.d | 36 
 3 files changed, 47 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/debug/dwarf2/pr118309.d

diff --git a/gcc/d/modules.cc b/gcc/d/modules.cc
index 813d94bc5c4..14e4a485043 100644
--- a/gcc/d/modules.cc
+++ b/gcc/d/modules.cc
@@ -30,6 +30,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "function.h"
 #include "cgraph.h"
 #include "stor-layout.h"
+#include "debug.h"
 #include "toplev.h"
 #include "target.h"
 #include "common/common-target.h"
@@ -927,6 +928,14 @@ d_finish_compilation (tree *vec, int len)
   /* Complete all generated thunks.  */
   symtab->process_same_body_aliases ();
 
+  /* Output debug information for all type declarations in this unit.  */
+  for (int i = 0; i < len; i++)
+{
+  tree decl = vec[i];
+  if (TREE_CODE (decl) == TYPE_DECL)
+   debug_hooks->type_decl (decl, false);
+}
+
   /* Process all file scopes in this compilation, and the external_scope,
  through wrapup_global_declarations.  */
   for (int i = 0; i < len; i++)
diff --git a/gcc/d/types.cc b/gcc/d/types.cc
index ea62bc9d05e..e43fa88a5d4 100644
--- a/gcc/d/types.cc
+++ b/gcc/d/types.cc
@@ -33,7 +33,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "langhooks.h"
 #include "tm.h"
 #include "function.h"
-#include "toplev.h"
 #include "target.h"
 #include "stringpool.h"
 #include "stor-layout.h"
@@ -709,13 +708,8 @@ finish_aggregate_type (unsigned structsize, unsigned 
alignsize, tree type)
   TYPE_USER_ALIGN (t) = TYPE_USER_ALIGN (type);
 }
 
-  /* Finish debugging output for this type.  */
-  rest_of_type_compilation (type, TYPE_FILE_SCOPE_P (type));
+  /* Complete any other forward-referenced fields of this aggregate type.  */
   finish_incomplete_fields (type);
-
-  /* Finish processing of TYPE_DECL.  */
-  rest_of_decl_compilation (TYPE_NAME (type),
-   DECL_FILE_SCOPE_P (TYPE_NAME (type)), 0);
 }
 
 /* Returns true if the class or struct type TYPE has already been layed out by
@@ -1185,13 +1179,8 @@ public:
 
layout_type (t->ctype);
 
-   /* Finish debugging output for this type.  */
-   rest_of_type_compilation (t->ctype, TYPE_FILE_SCOPE_P (t->ctype));
+   /* Complete forward-referenced fields of this enum type.  */
finish_incomplete_fields (t->ctype);
-
-   /* Finish processing of TYPE_DECL.  */
-   rest_of_decl_compilation (TYPE_NAME (t->ctype),
- DECL_FILE_SCOPE_P (TYPE_NAME (t->ctype)), 0);
   }
   }
 
diff --git a/gcc/testsuite/gdc.dg/debug/dwarf2/pr118309.d 
b/gcc/testsuite/gdc.dg/debug/dwarf2/pr118309.d
new file mode 100644
index 000..50e42164eef
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/debug/dwarf2/pr118309.d
@@ -0,0 +1,36 @@
+// { dg-do compile }
+// { dg-options "-fno-druntime -gdwarf-4 -dA -fno-merge-debug-strings" }
+// { dg-final { scan-assembler-times "DIE\[^\n\r\]*DW_TAG_enumeration_type" 1 
} }
+// { dg-final { scan-assembler-times " DW_AT_enum_class" 1 } }
+// { dg-final { scan-assembler-times "\"E..\"\[^\n\]*DW_AT_name" 1 } }
+// { dg-final { scan-assembler-times "\"E1..\"\[^\n\]*DW_AT_name" 1 } }
+// { dg-final { scan-assembler-times "\"C1..\"\[^\n\]*DW_AT_name" 1 } }
+// { dg-final { scan-assembler-times "\"C2..\"\[^\n\]*DW_AT_name" 1 } }
+// { dg-final { scan-assembler-times "\"C3..\"\[^\n\]*DW_AT_name" 1 } }
+// { dg-final { scan-assembler-times "\"C4..\"\[^\n\]*DW_AT_name" 1 } }
+// { dg-final { scan-assembler-times "\"S1..\"\[^\n\]*DW_AT_name" 1 } }
+
+module expression;
+extern (C++):
+class C1
+{
+bool bfn() { return true; }
+}
+class C2 : C1
+{
+C4 cfn() { return null; }
+}
+class C3 : C2
+{
+S1.E s;
+}
+class C4 : C3
+{
+S1 s;
+}
+struct S1
+{
+enum E : ubyte { E1 }
+E e;
+C3 c;
+}
-- 
2.43.0

Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

[Qing Zhao]

Hi, Joseph and Martin,

When I implemented the patch to attach the counted_by information to an array 
reference (FAM reference) in C FE, 
The work was done inside the routine “build_component_ref” in gcc/c/c-typeck.cc 
.  and this is very reasonable and
quite clean. 

Now, If we try to replace a structure pointer reference with counted_by 
attached to the FAM field, where in the C FE
I should look at?

For the following small example, I am trying to replace the pointer reference 
at line 28, “obj”, and line 34, “q” to a call to
.ACCESS_WITH_SIZE. However, “p” at line 21 and “q” at line 33 should not be 
replaced. 

Do you have any suggestions?

Thanks a lot for your help here.

Qing

  1 #include 
  2 #include 
  3
  4 struct annotated {
  5   size_t count;
  6   char array[] __attribute__((counted_by (count)));
  7 };
  8 
  9 /* compute the minimum # of bytes needed to hold a structure “annotated”,
 10whose # of elements of “array” is COUNT.  */
 11 #define MAX(A, B) (A > B) ? (A) : (B)
 12 #define ALLOC_SIZE_ANNOTATED(COUNT) \
 13   MAX(sizeof (struct annotated), \
 14   offsetof(struct annotated, array[0]) + (COUNT) * sizeof(char))
 15 
 16 /* allocate the memory for the structure with FAM,
 17update “count” with the # of elements “index”.  */
 18 static struct annotated * __attribute__((__noinline__)) alloc_buf (int 
index)
 19 {
 20   struct annotated *p;
 21   p = (struct annotated *) malloc (ALLOC_SIZE_ANNOTATED(index));
 22   p->count = index;
 23   return p;
 24 }
 25 
 26 static size_t __attribute__((__noinline__)) size_of (struct annotated * obj)
 27 {
 28   return __builtin_dynamic_object_size (obj, 1);
 29 }
 30  
 31 int main()
 32 {
 33   struct annotated *q = alloc_buf (10);
 34   __builtin_printf ("the bdos whole is %d\n", size_of (q));
 35   return 0;
 36 }

[PATCH] libgcobol: Handle long double as an alternate IEEE754 128b

[Iain Sandoe]

Here is what I'm testing as an incremental fix, so far OK on x86_64-darwin
and powerpcle64 (GLIBC 2.34) .. others in progress.  Does it help the
Solaris cases?

--- 8< ---

In some cases, we might be able to use strtold and snprintf for
128b IEEE754 (when the long double format agrees).

libgcobol/ChangeLog:

* intrinsic.cc (strtof128): Move handling
to libgcobol-fp.h.
(WEIRD_TRANSCENDENT_RETURN_VALUE): Handle
F128, Q and L as suffixes.
* libgcobol-fp.h (GCOB_FP128_LD, GCOB_FP128_F128,
GCOB_FP128_Q): New.
HAVE_STRTOF128, HAVE_STRTOF128: Handle long double
as well as __float128.
* libgcobol.cc: MOve handling of HAVE_STRTOF128 and
HAVE_STRTOF128 to libgcobol-fp.h
(format_for_display_internal): Handle long double
as an alternate IEEE754 128b float.

Signed-off-by: Iain Sandoe 
---
 libgcobol/intrinsic.cc   | 19 +--
 libgcobol/libgcobol-fp.h | 19 +++
 libgcobol/libgcobol.cc   | 31 +++
 3 files changed, 43 insertions(+), 26 deletions(-)

diff --git a/libgcobol/intrinsic.cc b/libgcobol/intrinsic.cc
index 9953b341488..e27107109e4 100644
--- a/libgcobol/intrinsic.cc
+++ b/libgcobol/intrinsic.cc
@@ -54,20 +54,19 @@
 #include "libgcobol.h"
 #include "charmaps.h"
 
-
-#if !defined (HAVE_STRTOF128)
-# if USE_QUADMATH
-#  define strtof128 strtoflt128
-# else
-#  error "no available string to float 128"
-# endif
-#endif
-
 #pragma GCC diagnostic ignored "-Wformat-truncation"
 
 #define JD_OF_1601_01_02 2305812.5
 
-#define WEIRD_TRANSCENDENT_RETURN_VALUE (0.0Q)
+#if defined (GCOB_FP128_LD)
+# define WEIRD_TRANSCENDENT_RETURN_VALUE (0.0L)
+#elif defined (GCOB_FP128_F128)
+# define WEIRD_TRANSCENDENT_RETURN_VALUE (0.0F128)
+#elif defined (GCOB_FP128_Q)
+# define WEIRD_TRANSCENDENT_RETURN_VALUE (0.0Q)
+#else
+# define WEIRD_TRANSCENDENT_RETURN_VALUE (0.0)
+#endif
 #define NO_RDIGITS (0)
 
 struct cobol_tm
diff --git a/libgcobol/libgcobol-fp.h b/libgcobol/libgcobol-fp.h
index bd443f3a234..f9f67fd6178 100644
--- a/libgcobol/libgcobol-fp.h
+++ b/libgcobol/libgcobol-fp.h
@@ -25,17 +25,20 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 
 #if __LDBL_MANT_DIG__ == 113 && __LDBL_MIN_EXP__ == -16381
 // Use long double, l suffix on calls, l or L suffix in literals
+# define GCOB_FP128_LD
 # define GCOB_FP128 long double
 # define GCOB_FP128_LITERAL(lit) (lit ## l)
 # define FP128_FUNC(funcname) funcname ## l
 #elif __FLT128_MANT_DIG__ == 113 && __FLT128_MIN_EXP__ == -16381 \
  && defined(USE_IEC_60559)
 // Use _Float128, f128 suffix on calls, f128 or F128 suffix on literals
+# define GCOB_FP128_F128
 # define GCOB_FP128 _Float128
 # define GCOB_FP128_LITERAL(lit) (lit ## f128)
 # define FP128_FUNC(funcname) funcname ## f128
 #elif __FLT128_MANT_DIG__ == 113 && __FLT128_MIN_EXP__ == -16381
 // Use __float128, q suffix on calls, q or Q suffix on literals
+# define GCOB_FP128_Q
 # define GCOB_FP128 __float128
 # define GCOB_FP128_LITERAL(lit) (lit ## q)
 # define FP128_FUNC(funcname) funcname ## q
@@ -48,3 +51,19 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
representative trig functions, we need libquadmath to support those.  */
 # include "quadmath.h"
 #endif
+
+#if !defined (HAVE_STRTOF128)
+# if USE_QUADMATH
+#  define strtof128 strtoflt128
+# elif defined (GCOB_FP128_LD)
+#  define strtof128 strtold
+# else
+#  error "no available string to float 128"
+# endif
+#endif
+
+#if !defined (HAVE_STRFROMF128)
+# if ! defined (USE_QUADMATH) && !defined (GCOB_FP128_LD)
+#  error "no available float 128 to string"
+# endif
+#endif
diff --git a/libgcobol/libgcobol.cc b/libgcobol/libgcobol.cc
index b907b67e9bc..8853b95abf6 100644
--- a/libgcobol/libgcobol.cc
+++ b/libgcobol/libgcobol.cc
@@ -93,20 +93,6 @@ strfromf64 (char *s, size_t n, const char *f, double v)
 # endif
 #endif
 
-#if !defined (HAVE_STRFROMF128)
-# if !USE_QUADMATH
-#  error "no available float 128 to string"
-# endif
-#endif
-
-#if !defined (HAVE_STRTOF128)
-# if USE_QUADMATH
-#  define strtof128 strtoflt128
-# else
-#  error "no available string to float 128"
-# endif
-#endif
-
 // This couldn't be defined in symbols.h because it conflicts with a LEVEL66
 // in parse.h
 #define LEVEL66 (66)
@@ -3265,8 +3251,14 @@ format_for_display_internal(char **dest,
   // on a 16-bit boundary.
   GCOB_FP128 floatval;
   memcpy(&floatval, actual_location, 16);
-#if !defined (HAVE_STRFROMF128) && USE_QUADMATH
+#if !defined (HAVE_STRFROMF128)
+# if defined (GCOB_FP128_LD)
+  snprintf(ach, sizeof(ach), "%.36LE", floatval);
+# elif defined (USE_QUADMATH)
   quadmath_snprintf(ach, sizeof(ach), "%.36QE", floatval);
+# else
+#  error "no supported print for 128b floats"
+# endif
 #else
   strfromf128(ach, sizeof(ach), "%.36E", floatval);
 #endif
@@ -3291,9 +3283,16 @@ format_for_display_internal(char **dest,
 
   int pre

Re: .ACCESS_WITH_SIZE and pointer ranges

[Qing Zhao]

> On Apr 8, 2025, at 21:13, Siddhesh Poyarekar  wrote:
> 
> On 2025-04-08 15:22, Qing Zhao wrote:
>> Changing a pointer reference to a call to .ACCESS_WITH_SIZE will impact the 
>> compiler optimization in two aspects:
>> 1.  The new call site might become a barrier that prevents code movement 
>> around it.
> 
> Yeah, it's not a real problem IMO; it should only prevent code movement that 
> references the struct and the size expression, which is what we want anyway.
> 
>> 2.  Increased insn counts might impact the compiler heuristics that depends 
>> on code size.
> 
>> For 2, When generating .ACCESS_WITH_SIZE to FAM references currently, one 
>> reference REF will become:
>>   (*.ACCESS_WITH_SIZE (REF, COUNTED_BY_REF, 1, (TYPE_OF_SIZE)0, -1,
>>(TYPE_OF_ARRAY *)0))
>> It increase the # of IRs, but not that much.
>> However, when generating .ACCESS_WITH_SIZE to a pointer REF to a structure 
>> with FAM, one reference will become:
>> If (!type_unsigned (typeof (ref->c))
>>   ref->c = (ref->c < 0) ? 0 : ref->c;
>> sz_exp = MAX (sizeof (struct S), offset (struct S, a) + ref->c * sizeof 
>> (char));
>> ref = .ACCESS_WITH_SIZE (&ref, &sz_exp, 0, …);
>> It’s obviously that the # if IRs will increase quite a lot for one pointer 
>> REF. So, I am a little concern on this impact.
> 
> Isn't the only *real* addition the size expression?  The .ACCESS_WITH_SIZE 
> should be zero cost in this context since it shouldn't add any actual code.
After expand phase, .ACCESS_WITH_SIZE will be replaced by its first argument.  
And all the size expression before the call to .ACCESS_WITH_SIZE might be dead 
code eliminated later in the RTL phases.

So, I don’t think there will be run-time overhead concern.

However, the IR size increase in the TREE optimization phase might impact the
Optimization heuristics that base on IR size, for example, inlining decision, 
etc.

That’s the major concern for me. 
> 
> A good measure of this could be to get a sense of additional coverage one 
> could get for __bdos with this change vs without it for, e.g. the kernel.  
> You could maybe use fortify-metrics[1] to find that.

Why there will be additional coverage with this change? (This change means to 
replace pointer reference with structure type with FAM by a call to 
.ACCESS_WITH_SIZE 
in C FE)

Based on my current patch (expand the counted_by refs to size expressions by 
demand for __bdos),
All the __bdos should be covered, right?

thanks.

Qing

> 
> Thanks,
> Sid
> 
> [1] https://github.com/siddhesh/fortify-metrics

[committed] testsuite/x86: Correctly escape asterisk in scan-assembler

[Uros Bizjak]

Asterisk in []* regexp applies to bracket expression. When asterisk is
a part of the word, then it needs to be escaped with \\.

Also use []+ instead of []* to match elements in bracket expression
one or more times.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr67215-1.c: Correctly escape
asterisk in scan-assembler directive.
* gcc.target/i386/pr67215-2.c: Ditto.

Tested on x86_64-linux-gnu {,-m32}.

Uros.
diff --git a/gcc/testsuite/gcc.target/i386/pr67215-1.c 
b/gcc/testsuite/gcc.target/i386/pr67215-1.c
index fd37f8e63db..ab69550db7d 100644
--- a/gcc/testsuite/gcc.target/i386/pr67215-1.c
+++ b/gcc/testsuite/gcc.target/i386/pr67215-1.c
@@ -13,8 +13,8 @@ foo (void)
 arr[i] = bar (128);
 }
 
-/* { dg-final { scan-assembler "call\[ \t\]*.bar@GOTPCREL" { target { ! ia32 } 
} } } */
-/* { dg-final { scan-assembler "call\[ \t\]*.bar@GOT\\(" { target ia32 } } } */
-/* { dg-final { scan-assembler-not "mov(l|q)\[ \t\]*.bar@GOTPCREL" { target { 
! ia32 } } } } */
-/* { dg-final { scan-assembler-not "movl\[ \t\]*.bar@GOT\\(" { target ia32 } } 
} */
-/* { dg-final { scan-assembler-not "call\[ \t\]*.bar@PLT" } } */
+/* { dg-final { scan-assembler "call\[ \t\]+\\*bar@GOTPCREL" { target { ! ia32 
} } } } */
+/* { dg-final { scan-assembler "call\[ \t\]+\\*bar@GOT\\(" { target ia32 } } } 
*/
+/* { dg-final { scan-assembler-not "mov(l|q)\[ \t\]+bar@GOTPCREL" { target { ! 
ia32 } } } } */
+/* { dg-final { scan-assembler-not "movl\[ \t\]+bar@GOT\\(" { target ia32 } } 
} */
+/* { dg-final { scan-assembler-not "call\[ \t\]+\\*bar@PLT" } } */
diff --git a/gcc/testsuite/gcc.target/i386/pr67215-2.c 
b/gcc/testsuite/gcc.target/i386/pr67215-2.c
index ebf2919078c..9fd7469e2d0 100644
--- a/gcc/testsuite/gcc.target/i386/pr67215-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr67215-2.c
@@ -13,8 +13,8 @@ foo (void)
 arr[i] = bar (128);
 }
 
-/* { dg-final { scan-assembler "call\[ \t\]*.bar@GOTPCREL" { target { ! ia32 } 
} } } */
-/* { dg-final { scan-assembler "call\[ \t\]*.bar@GOT\\(" { target ia32 } } } */
-/* { dg-final { scan-assembler-not "mov(l|q)\[ \t\]*.bar@GOTPCREL" { target { 
! ia32 } } } } */
-/* { dg-final { scan-assembler-not "movl\[ \t\]*.bar@GOT\\(" { target ia32 } } 
} */
-/* { dg-final { scan-assembler-not "call\[ \t\]*.bar@PLT" } } */
+/* { dg-final { scan-assembler "call\[ \t\]+\\*bar@GOTPCREL" { target { ! ia32 
} } } } */
+/* { dg-final { scan-assembler "call\[ \t\]+\\*bar@GOT\\(" { target ia32 } } } 
*/
+/* { dg-final { scan-assembler-not "mov(l|q)\[ \t\]+bar@GOTPCREL" { target { ! 
ia32 } } } } */
+/* { dg-final { scan-assembler-not "movl\[ \t\]+bar@GOT\\(" { target ia32 } } 
} */
+/* { dg-final { scan-assembler-not "call\[ \t\]+\\*bar@PLT" } } */

Re: [PATCH v4 1/2] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

[H.J. Lu]

On Wed, Apr 9, 2025 at 1:53 AM Ard Biesheuvel  wrote:
>
> From: Ard Biesheuvel 
>
> Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> __fentry__") updated the logic that emits mcount() / __fentry__() calls
> into function prologues when profiling is enabled, to avoid GOT-based
> indirect calls when a direct call would suffice.
>
> There are two problems with that change:
> - it relies on -mdirect-extern-access rather than -fno-plt to decide
>   whether or not a direct [PLT based] call is appropriate;
> - for the PLT case, it falls through to x86_print_call_or_nop(), which
>   does not emit the @PLT suffix, resulting in the wrong relocation to be
>   used (R_X86_64_PC32 instead of R_X86_64_PLT32)
>
> Fix this by testing flag_plt instead of ix86_direct_extern_access, and
> updating x86_print_call_or_nop() to take flag_pic and flag_plt into
> account. This also ensures that -mnop-mcount works as expected when
> emitting the PLT based profiling calls.
>
> Note that only 64-bit codegen is affected by this change or by the
> commit referenced above; -m32 will yield 'call *mcount@GOT()' as before.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
>
> Signed-off-by: Ard Biesheuvel 
>
> gcc/ChangeLog:
>
> PR target/119386
> * config/i386/i386.cc (x86_print_call_or_nop): Add @PLT suffix
> where appropriate.
> (x86_function_profiler): Fall through to x86_print_call_or_nop()
> for PIC codegen when flag_plt is set.
>
> gcc/testsuite/ChangeLog:
>
> PR target/119386
> * gcc.target/i386/pr119386-1.c: New test.
> * gcc.target/i386/pr119386-2.c: New test.
> ---
>  gcc/config/i386/i386.cc|  8 +++-
>  gcc/testsuite/gcc.target/i386/pr119386-1.c | 11 +++
>  gcc/testsuite/gcc.target/i386/pr119386-2.c | 12 
>  3 files changed, 30 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr119386-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr119386-2.c
>
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index be5e27fc391..0b238c3dddc 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -23154,6 +23154,12 @@ x86_print_call_or_nop (FILE *file, const char 
> *target)
>if (flag_nop_mcount || !strcmp (target, "nop"))
>  /* 5 byte nop: nopl 0(%[re]ax,%[re]ax,1) */
>  fprintf (file, "1:" ASM_BYTE "0x0f, 0x1f, 0x44, 0x00, 0x00\n");
> +  else if (!TARGET_PECOFF && flag_pic)
> +{
> +  gcc_assert (flag_plt);
> +
> +  fprintf (file, "1:\tcall\t%s@PLT\n", target);
> +}
>else
>  fprintf (file, "1:\tcall\t%s\n", target);
>  }
> @@ -23317,7 +23323,7 @@ x86_function_profiler (FILE *file, int labelno 
> ATTRIBUTE_UNUSED)
>   break;
> case CM_SMALL_PIC:
> case CM_MEDIUM_PIC:
> - if (!ix86_direct_extern_access)
> + if (!flag_plt)
> {
>   if (ASSEMBLER_DIALECT == ASM_INTEL)
> fprintf (file, "1:\tcall\t[QWORD PTR %s@GOTPCREL[rip]]\n",
> diff --git a/gcc/testsuite/gcc.target/i386/pr119386-1.c 
> b/gcc/testsuite/gcc.target/i386/pr119386-1.c
> new file mode 100644
> index 000..174d00f1e27
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr119386-1.c
> @@ -0,0 +1,11 @@
> +/* PR target/119386 */
> +/* { dg-do compile { target *-*-linux* } } */
> +/* { dg-options "-O2 -fpic -pg" } */
> +/* { dg-final { scan-assembler "call\[ \t\]mcount@PLT" { target { ! ia32 } } 
> } } */
> +/* { dg-final { scan-assembler "call\[ \t\]\\*mcount@GOT\\(" { target ia32 } 
> } } */

This is wrong for ia32, which should also generate "call mcount@PLT".

> +
> +int
> +main ()
> +{
> +  return 0;
> +}
> diff --git a/gcc/testsuite/gcc.target/i386/pr119386-2.c 
> b/gcc/testsuite/gcc.target/i386/pr119386-2.c
> new file mode 100644
> index 000..808dd9298ce
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr119386-2.c
> @@ -0,0 +1,12 @@
> +/* PR target/119386 */
> +/* { dg-do compile { target *-*-linux* } } */
> +/* { dg-options "-O2 -fpic -fno-plt -pg" } */
> +/* { dg-final { scan-assembler "call\[ \t\]\\*mcount@GOTPCREL\\(" { target { 
> ! ia32 } } } } */
> +/* { dg-final { scan-assembler "call\[ \t\]\\*mcount@GOT\\(" { target ia32 } 
> } } */
> +
> +
> +int
> +main ()
> +{
> +  return 0;
> +}
> --
> 2.49.0.504.g3bcea36a83-goog
>


-- 
H.J.

Re: vsetvl abormal edge (was Re: [PATCH v2] RISC-V: vsetvl: skip abnormal edge on vsetvl insertion [PR119533])

[Vineet Gupta]

Hi Robin,

On 4/8/25 21:56, Robin Dapp wrote:
 Yay ! It does work. Awesome.
 I've uploaded the further reduced test to PR/119533
>>> Hmm, I'm seeing the same ICE as before with my patch.  Did you happen 
>>> to change 
>>> something else on your local tree still?
 Yeah I had some debug stuff lying around. In particular it is missing the
 initializer for kill bitmap.

 @@ -2698,6 +2713,7 @@ pre_vsetvl::compute_lcm_local_properties ()
    m_avout = sbitmap_vector_alloc (last_basic_block_for_fn (cfun), 
 num_exprs);
  
    bitmap_vector_clear (m_avloc, last_basic_block_for_fn (cfun));
 +  bitmap_vector_clear (m_kill, last_basic_block_for_fn (cfun));
    bitmap_vector_clear (m_antloc, last_basic_block_for_fn (cfun));
    bitmap_vector_ones (m_transp, last_basic_block_for_fn (cfun));


>> On top, I'm now seeing a ton of vsetvl test failures vs just the one I 
>> reported...  No idea what I have been testing before.  Grml.
 From your inline diff (with "!= 1" as cue) , I'd placed the check as 
 follows

   if (!curr_info.valid_p ()
   || eg->probability == profile_probability::never ()
   || src_block_info.probability
    == profile_probability::uninitialized ()
   /* When multiple set bits in earliest edge, such edge may
  have infinite loop in preds or succs or multiple conflict
  vsetvl expression which make such edge is unrelated.  We
  don't perform fusion for such situation.  */
   || bitmap_count_bits (e) != 1)
     continue;

 +  if (!bitmap_bit_p (m_transp[eg->src->index], expr_index))
 +    continue;

 With both of above changes both go tests passed in the morning.

> Ah, of course the check was intended to be inside src_block_info.empty_p 
> () and 
> not outside.  That gets rid of the test failures.  But the go tests still 
> ICE 
> for me, one way or another.
 Now I moved the bitmap check further down inside src_block_info.empty_p () 
 and
 both tests still pass.
 So looks like the kill bitmap init is essential as well.
>>> Doh ! Something is weird, I did a clean everything and now I see the issues
>>> still and it seems for baseline build, prinstine trunk is hitting ICE on 
>>> glibc
>>> build as of
>>>
>>>  2025-04-08 0980a6ff7ae3 Daily bump.
>>>
>>> Let me untangle my testing first.
>> The go issue, needs your transparent set check but we also need to tighten
>> tighten invalid_opt_bb_p () for skipping successor edges being abnormal,
>> currently it only does for predecessors only.  If you recall this is 
>> something
>> I'd tried last week, but that alone was not enough.
>>
>> So it seems we might have to seperate out the changes for PR/119547 (opencv) 
>> and
>> 119533 (libgo) with latter dependent on former.
>>  
>> On baseline Daily Bump of April 01, with attached patch including everything
>> (just to test), we see 2 deltas
>>
>>     rv64imafdcv_zvl256b_zba_zbb_zbs_zicond/  lp64d/ medlow |  303 /   101 |  
>>  16
>> / 4 |   67 /    12 |
>>     rv64imafdcv_zvl256b_zba_zbb_zbs_zicond/  lp64d/ medlow |  311 /   103 |  
>>  16
>> / 4 |   67 /    12 |
>>
>>  FAIL: gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-10.c
>>  FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-68.c
>>
>> I still need to figure out if vlmax_switch_vtype-10 is transparency related 
>> or
>> the edge issue.
> vlmax_switch_vtype-10 I already adjusted locally.  It's related but the code 
> with the new changes is better than before.  So IMHO no need to worry about 
> it.

Awesome, thx for the confirmation. I'll post a v2 for the go fix.

-Vineet

Re: [PATCH v3] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

[Ard Biesheuvel]

On Tue, 8 Apr 2025 at 15:33, H.J. Lu  wrote:
>
> On Tue, Apr 8, 2025 at 3:46 AM Ard Biesheuvel  wrote:
> >
> > From: Ard Biesheuvel 
> >
> > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> > __fentry__") updated the logic that emits mcount() / __fentry__() calls
> > into function prologues when profiling is enabled, to avoid GOT-based
> > indirect calls when a direct call would suffice.
> >
> > There are two problems with that change:
> > - it relies on -mdirect-extern-access rather than -fno-plt to decide
> >   whether or not a direct [PLT based] call is appropriate;
> > - for the PLT case, it falls through to x86_print_call_or_nop(), which
> >   does not emit the @PLT suffix, resulting in the wrong relocation to be
> >   used (R_X86_64_PC32 instead of R_X86_64_PLT32)
> >
> > Fix this by testing flag_plt instead of ix86_direct_extern_access, and
> > updating x86_print_call_or_nop() to take flag_pic and flag_plt into
> > account. This also ensures that -mnop-mcount works as expected when
> > emitting the PLT based profiling calls.
> >
> > Note that only 64-bit codegen is affected by this change or by the
> > commit referenced above; -m32 will yield 'call *mcount@GOT()' as before.
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
> >
> > Signed-off-by: Ard Biesheuvel 
> >
> > gcc/ChangeLog:
> >
> > PR target/119386
> > * config/i386/i386.cc (x86_print_call_or_nop): Add @PLT suffix
> > where appropriate.
> > (x86_function_profiler): Fall through to x86_print_call_or_nop()
> > for PIC codegen when flag_plt is set.
> >
> > gcc/testsuite/ChangeLog:
> >
> > PR target/119386
> > * gcc.target/i386/pr119386-1.c: New test.
> > * gcc.target/i386/pr119386-2.c: New test.
> > ---
> >  gcc/config/i386/i386.cc|  8 +++-
> >  gcc/testsuite/gcc.target/i386/pr119386-1.c | 11 +++
> >  gcc/testsuite/gcc.target/i386/pr119386-2.c | 11 +++
> >  3 files changed, 29 insertions(+), 1 deletion(-)
> >
> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > index be5e27fc391..0b238c3dddc 100644
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -23154,6 +23154,12 @@ x86_print_call_or_nop (FILE *file, const char 
> > *target)
> >if (flag_nop_mcount || !strcmp (target, "nop"))
> >  /* 5 byte nop: nopl 0(%[re]ax,%[re]ax,1) */
> >  fprintf (file, "1:" ASM_BYTE "0x0f, 0x1f, 0x44, 0x00, 0x00\n");
> > +  else if (!TARGET_PECOFF && flag_pic)
> > +{
> > +  gcc_assert (flag_plt);
> > +
> > +  fprintf (file, "1:\tcall\t%s@PLT\n", target);
> > +}
> >else
> >  fprintf (file, "1:\tcall\t%s\n", target);
> >  }
> > @@ -23317,7 +23323,7 @@ x86_function_profiler (FILE *file, int labelno 
> > ATTRIBUTE_UNUSED)
> >   break;
> > case CM_SMALL_PIC:
> > case CM_MEDIUM_PIC:
> > - if (!ix86_direct_extern_access)
> > + if (!flag_plt)
> > {
> >   if (ASSEMBLER_DIALECT == ASM_INTEL)
> > fprintf (file, "1:\tcall\t[QWORD PTR 
> > %s@GOTPCREL[rip]]\n",
> > diff --git a/gcc/testsuite/gcc.target/i386/pr119386-1.c 
> > b/gcc/testsuite/gcc.target/i386/pr119386-1.c
> > new file mode 100644
> > index 000..7930fc6f28d
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/i386/pr119386-1.c
> > @@ -0,0 +1,11 @@
> > +/* PR target/119386 */
> > +/* { dg-do compile { target *-*-linux* } } */
> > +/* { dg-require-effective-target lp64 } */
>
> Can this be dropped?
>

I copied that from another test, assuming it would limit the testing
to x86_64. Is there a better way to achieve that?


> > +/* { dg-options "-O2 -fpic -pg" } */
> > +/* { dg-final { scan-assembler "mcount@PLT" } } */
> > +
> > +int
> > +main ()
> > +{
> > +  return 0;
> > +}
> > diff --git a/gcc/testsuite/gcc.target/i386/pr119386-2.c 
> > b/gcc/testsuite/gcc.target/i386/pr119386-2.c
> > new file mode 100644
> > index 000..6334b9b9072
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/i386/pr119386-2.c
> > @@ -0,0 +1,11 @@
> > +/* PR target/119386 */
> > +/* { dg-do compile { target *-*-linux* } } */
> > +/* { dg-require-effective-target lp64 } */
>
> Can this be dropped?
>
> > +/* { dg-options "-O2 -fpic -fno-plt -pg" } */
> > +/* { dg-final { scan-assembler "mcount@GOTPCREL" } } */
>
> Different scans for ia32 and ! ia32?
>

I did not consider IA32 at all - can we just omit it?

Re: [PATCH v2] RISC-V: Disable unsupported vsext/vzext patterns for XTheadVector.

[Jeff Law]

On 4/8/25 8:54 PM, Jin Ma wrote:

On Tue, 8 Apr 2025 14:27:16 -0600, Jeff Law wrote:



On 4/7/25 12:26 AM, Jin Ma wrote:

XThreadVector does not support the vsext/vzext instructions; however,
due to the reuse of RVV optimizations, it may generate these instructions
in certain cases. To prevent the error "Unknown opcode 'th.vsext.vf2',"
we should disable these patterns.

V2:
Change the value of dg-do in the test case from assemble to compile, and
remove the -save-temps option.

gcc/ChangeLog:

* config/riscv/vector.md: Disable vsext/vzext for XTheadVector.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/xtheadvector/vsext.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vzext.c: New test.

OK for the trunk.  Thanks!

Also OK if you wanted to backport to gcc-14.


Thank you very much! After conducting thorough testing locally, I will attempt 
to
cherry-pick them into the gcc-14 branch. By the way, do we have a pre-commit CI
system in place for the gcc-14 branch similar to that of the trunk branch? If 
so,
how can I trigger it and monitor the status of the patches in the CI system?

No, I don't think there's any pre-commit in place on the release branches.

Note Kito cherry-picked a large handful of patches to the gcc-14 tree 
earlier today.  So you'll probably want look at what he did and adjust 
your list accordingly.


Jeff

cobol.1 fix for not using underscores in intrinsic function names

[Simon Sobisch]

just stumbled over this and only have a mail client running, so...
patch as text. The change is in all those cases: change _ (likely parsed 
from the parser or similar) to -.


Kind regards,
Simon



-BASECONVERT BIT_OF BIT_TO_CHAR BOOLEAN_OF_INTEGER BYTE_LENGTH
+BASECONVERT BIT-OF BIT-TO-CHAR BOOLEAN-OF-INTEGER BYTE-LENGTH
 .It
-CHAR CHAR_NATIONAL COMBINED_DATETIME CONCAT CONVERT COS CURRENT_DATE
+CHAR CHAR-NATIONAL COMBINED-DATETIME CONCAT CONVERT COS CURRENT-DATE
 .It
-DATE_OF_INTEGER DATE_TO_MMDD DAY_OF_INTEGER DAY_TO_DDD DISPLAY_OF
+DATE-OF-INTEGER DATE-TO-MMDD DAY-OF-INTEGER DAY-TO-DDD DISPLAY-OF
 .It
-E EXCEPTION_FILE
-EXCEPTION_FILE_N EXCEPTION_LOCATION EXCEPTION_LOCATION_N
-EXCEPTION_STATEMENT EXCEPTION_STATUS EXP EXP10
+E EXCEPTION-FILE
+EXCEPTION-FILE-N EXCEPTION-LOCATION EXCEPTION-LOCATION-N
+EXCEPTION-STATEMENT EXCEPTION-STATUS EXP EXP10
 .It
-FACTORIAL FIND_STRING
-FORMATTED_CURRENT_DATE FORMATTED_DATE FORMATTED_DATETIME
-FORMATTED_TIME FRACTION_PART
+FACTORIAL FIND-STRING
+FORMATTED-CURRENT-DATE FORMATTED-DATE FORMATTED-DATETIME
+FORMATTED-TIME FRACTION-PART
 .It
-HEX_OF HEX_TO_CHAR HIGHEST_ALGEBRAIC
+HEX-OF HEX-TO-CHAR HIGHEST-ALGEBRAIC
 .It
-INTEGER INTEGER_OF_BOOLEAN INTEGER_OF_DATE INTEGER_OF_DAY
-INTEGER_OF_FORMATTED_DATE INTEGER_PART
+INTEGER INTEGER-OF-BOOLEAN INTEGER-OF-DATE INTEGER-OF-DAY
+INTEGER-OF-FORMATTED-DATE INTEGER-PART
 .It
-LENGTH LOCALE_COMPARE
-LOCALE_DATE LOCALE_TIME LOCALE_TIME_FROM_SECONDS LOG LOG10 LOWER_CASE
-LOWEST_ALGEBRAIC
+LENGTH LOCALE-COMPARE
+LOCALE-DATE LOCALE-TIME LOCALE-TIME-FROM-SECONDS LOG LOG10 LOWER-CASE
+LOWEST-ALGEBRAIC
 .It
-MAX MEAN MEDIAN MIDRANGE MIN MOD MODULE_NAME
+MAX MEAN MEDIAN MIDRANGE MIN MOD MODULE-NAME
 .It
-NATIONAL_OF NUMVAL NUMVAL_C NUMVAL_F ORD
+NATIONAL-OF NUMVAL NUMVAL-C NUMVAL-F ORD
 .It
-ORD_MAX ORD_MIN
+ORD-MAX ORD-MIN
 .It
-PI PRESENT_VALUE
+PI PRESENT-VALUE
 .It
 RANDOM RANGE REM REVERSE
 .It
-SECONDS_FROM_FORMATTED_TIME
-SECONDS_PAST_MIDNIGHT SIGN SIN SMALLEST_ALGEBRAIC SQRT
-STANDARD_COMPARE STANDARD_DEVIATION SUBSTITUTE SUM
+SECONDS-FROM-FORMATTED-TIME
+SECONDS-PAST-MIDNIGHT SIGN SIN SMALLEST-ALGEBRAIC SQRT
+STANDARD-COMPARE STANDARD-DEVIATION SUBSTITUTE SUM
 .It
-TAN TEST_DATE_MMDD TEST_DAY_DDD TEST_FORMATTED_DATETIME
-TEST_NUMVAL TEST_NUMVAL_C TEST_NUMVAL_F TRIM
+TAN TEST-DATE-MMDD TEST-DAY-DDD TEST-FORMATTED-DATETIME
+TEST-NUMVAL TEST-NUMVAL-C TEST-NUMVAL-F TRIM

[committed] cobol: Proper comparison of alphanumeric to refmoded numeric-display [PR119682]

[Robert Dubner]

This patch eliminates the error.

cobol: Proper comparison of alphanumeric to refmoded numeric-display
[PR119682]

gcc/cobol

PR cobol/119682
* genapi.cc: (cobol_compare): Change the call to
__gg__compare().

libgcobol

PR cobol/119682
* common-defs.h: Define the REFER_T_REFMOD constant.
* intrinsic.cc: (__gg__max): Change the calls to
__gg__compare_2(),
(__gg__min): Likewise, (__gg__ord_min): Likewise,
(__gg__ord_max): Likewise.
* libgcobol.cc: (__gg__compare_2): Change definition of
calling
parameters, eliminate separate flag bit for ALL and
ADDRESS_OF,
change comparison of alphanumeric to numeric when the numeric
is a refmod.
* libgcobol.h: Change declaration of __gg__compare_2.

diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
index c91237bd8d2c..fdf76aad7b14 100644
--- a/gcc/cobol/genapi.cc
+++ b/gcc/cobol/genapi.cc
@@ -2028,10 +2028,12 @@ cobol_compare(  tree return_int,
 {
 // None of our explicit comparisons up above worked, so we revert to
the
 // general case:
-int leftflags  =   (left_side_ref.all  ? REFER_T_MOVE_ALL : 0)
-+  (left_side_ref.addr_of  ? REFER_T_ADDRESS_OF : 0);
-int rightflags =   (right_side_ref.all ? REFER_T_MOVE_ALL : 0)
-+  (right_side_ref.addr_of ? REFER_T_ADDRESS_OF : 0);
+int leftflags  =   (left_side_ref.all  ? REFER_T_MOVE_ALL   :
0)
++  (left_side_ref.addr_of  ? REFER_T_ADDRESS_OF :
0)
++  (left_side_ref.refmod.from  ? REFER_T_REFMOD :
0);
+int rightflags =   (right_side_ref.all ? REFER_T_MOVE_ALL   :
0)
++  (right_side_ref.addr_of ? REFER_T_ADDRESS_OF :
0)
++  (right_side_ref.refmod.from ? REFER_T_REFMOD :
0);
 gg_assign(  return_int, gg_call_expr(
 INT,
 "__gg__compare",
@@ -2045,6 +2047,7 @@ cobol_compare(  tree return_int,
 build_int_cst_type(INT, rightflags),
 integer_zero_node,
 NULL_TREE));
+compared = true;
 }

 //  gg_printf("   result is %d\n", return_int, NULL_TREE);
diff --git a/libgcobol/common-defs.h b/libgcobol/common-defs.h
index f9d9c56a0d8d..6bf32ef79cf0 100644
--- a/libgcobol/common-defs.h
+++ b/libgcobol/common-defs.h
@@ -70,6 +70,7 @@
 #define REFER_T_ALL_FLAGS_MASK 0x0FF  // We allow for seven subscripts
 #define REFER_T_MOVE_ALL   0x100  // This is the move_all flag
 #define REFER_T_ADDRESS_OF 0x200  // This is the address_of flag
+#define REFER_T_REFMOD 0x400  // Indicates to library the refer
was a refmod

 #define MIN_FIELD_BLOCK_SIZE (16)

diff --git a/libgcobol/intrinsic.cc b/libgcobol/intrinsic.cc
index 4bce481b0c04..e0bd3339708e 100644
--- a/libgcobol/intrinsic.cc
+++ b/libgcobol/intrinsic.cc
@@ -1867,8 +1867,7 @@ __gg__max(cblc_field_t *dest,
 unsigned char *best_location   ;
 size_t best_length ;
 intbest_attr   ;
-bool   best_move_all   ;
-bool   best_address_of ;
+intbest_flags  ;

 bool first_time = true;
 assert(ncount);
@@ -1887,8 +1886,7 @@ __gg__max(cblc_field_t *dest,
   best_location   = __gg__treeplet_1f[i]->data +
__gg__treeplet_1o[i];
   best_length = __gg__treeplet_1s[i];
   best_attr   = __gg__treeplet_1f[i]->attr;
-  best_move_all   = !!(__gg__fourplet_flags[i] &
REFER_T_MOVE_ALL);
-  best_address_of = !!(__gg__fourplet_flags[i] &
REFER_T_ADDRESS_OF);
+  best_flags  = __gg__fourplet_flags[i];
   }
 else
   {
@@ -1896,31 +1894,27 @@ __gg__max(cblc_field_t *dest,
   unsigned char *candidate_location   =
__gg__treeplet_1f[i]->data + __gg__treeplet_1o[i];
   size_t candidate_length = __gg__treeplet_1s[i];
   intcandidate_attr   =
__gg__treeplet_1f[i]->attr;
-  bool   candidate_move_all   =
!!(__gg__fourplet_flags[i] & REFER_T_MOVE_ALL);
-  bool   candidate_address_of =
!!(__gg__fourplet_flags[i] & REFER_T_ADDRESS_OF);
+  intcandidate_flags  = __gg__fourplet_flags[i];

   int compare_result = __gg__compare_2(
  candidate_field,
  candidate_location,
  candidate_length,
  candidate_attr,
- candidate_move_all,
- candidate_address_of,
+ candidate_flags,
  best_field,
  best_location,
  best_length,
  best_attr,
- best_mo

[PATCH] rs6000: Disable __builtin_scalar_byte_in_set when using -m32 [PR119629]

[Peter Bergner]

The __builtin_scalar_byte_in_set() built-in emits the cmpeqb instruction
which produces undefined results when run in 32-bit mode.  The current
selector [power9-64] enables the built-in when using -m32 -mpowerpc64.
Use the  no32bit attribute to fully disable it for all -m32 compiles.

This was bootstrapped and regtested on powerpc64-linux with running the
testsuite in both 32-bit and 64-bit modes with no regressions.  I then
reran the test case with both -m32 -mno-powerpc64 and -m32 -mpowerpc64
and we get PASSes for both compiles.

Ok for trunk and the release branches after some trunk burn-in time?

Peter


gcc/
PR target/119629
* config/rs6000/rs6000-logue.cc (__builtin_scalar_byte_in_set): Use
the no32bit attribute.

gcc/testsuite/
PR target/119629
* gcc.target/powerpc/byte-in-set-2.c (dg-error): Update acceptable
error messages.


diff --git a/gcc/config/rs6000/rs6000-builtins.def 
b/gcc/config/rs6000/rs6000-builtins.def
index 555d7d58950..56b3a544b7d 100644
--- a/gcc/config/rs6000/rs6000-builtins.def
+++ b/gcc/config/rs6000/rs6000-builtins.def
@@ -2650,7 +2650,7 @@
 STXVL stxvl {}
 
   const signed int __builtin_scalar_byte_in_set (signed int, signed long long);
-CMPEQB cmpeqb {}
+CMPEQB cmpeqb {no32bit}
 
   pure vsc __builtin_vsx_lxvl (const void *, signed long);
 LXVL lxvl {}
diff --git a/gcc/testsuite/gcc.target/powerpc/byte-in-set-2.c 
b/gcc/testsuite/gcc.target/powerpc/byte-in-set-2.c
index e7cdebe533d..cf16ca421e2 100644
--- a/gcc/testsuite/gcc.target/powerpc/byte-in-set-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/byte-in-set-2.c
@@ -10,5 +10,8 @@
 int
 test_byte_in_set (unsigned char b, unsigned long long set_members)
 {
-  return __builtin_byte_in_set (b, set_members); /* { dg-error 
"'__builtin_scalar_byte_in_set' requires the" } */
+  /* The built-in machinery gives us two different error messages depending
+ on if -m32 -mno-powerpc64 or -m32 -mpowerpc64 was used to compile this
+ test case.  Accept both error messages.  */
+  return __builtin_byte_in_set (b, set_members); /* { dg-error 
"'__builtin_scalar_byte_in_set' (requires the|is not supported)" } */
 }

Re: [PATCH v3] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

[Uros Bizjak]

On Tue, Apr 8, 2025 at 6:59 PM Ard Biesheuvel  wrote:
>
> On Tue, 8 Apr 2025 at 18:44, H.J. Lu  wrote:
> >
> > On Tue, Apr 8, 2025 at 9:39 AM Ard Biesheuvel  wrote:
> > >
> > > On Tue, 8 Apr 2025 at 15:33, H.J. Lu  wrote:
> > > >
> > > > On Tue, Apr 8, 2025 at 3:46 AM Ard Biesheuvel  
> > > > wrote:
> > > > >
> > > > > From: Ard Biesheuvel 
> > > > >
> > > > > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> > > > > __fentry__") updated the logic that emits mcount() / __fentry__() 
> > > > > calls
> > > > > into function prologues when profiling is enabled, to avoid GOT-based
> > > > > indirect calls when a direct call would suffice.
> > > > >
> > > > > There are two problems with that change:
> > > > > - it relies on -mdirect-extern-access rather than -fno-plt to decide
> > > > >   whether or not a direct [PLT based] call is appropriate;
> > > > > - for the PLT case, it falls through to x86_print_call_or_nop(), which
> > > > >   does not emit the @PLT suffix, resulting in the wrong relocation to 
> > > > > be
> > > > >   used (R_X86_64_PC32 instead of R_X86_64_PLT32)
> > > > >
> > > > > Fix this by testing flag_plt instead of ix86_direct_extern_access, and
> > > > > updating x86_print_call_or_nop() to take flag_pic and flag_plt into
> > > > > account. This also ensures that -mnop-mcount works as expected when
> > > > > emitting the PLT based profiling calls.
> > > > >
> > > > > Note that only 64-bit codegen is affected by this change or by the
> > > > > commit referenced above; -m32 will yield 'call *mcount@GOT()' as 
> > > > > before.
> > > > >
> > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
> > > > >
> > > > > Signed-off-by: Ard Biesheuvel 
> > > > >
> > > > > gcc/ChangeLog:
> > > > >
> > > > > PR target/119386
> > > > > * config/i386/i386.cc (x86_print_call_or_nop): Add @PLT suffix
> > > > > where appropriate.
> > > > > (x86_function_profiler): Fall through to 
> > > > > x86_print_call_or_nop()
> > > > > for PIC codegen when flag_plt is set.
> > > > >
> > > > > gcc/testsuite/ChangeLog:
> > > > >
> > > > > PR target/119386
> > > > > * gcc.target/i386/pr119386-1.c: New test.
> > > > > * gcc.target/i386/pr119386-2.c: New test.
> > > > > ---
> > > > >  gcc/config/i386/i386.cc|  8 +++-
> > > > >  gcc/testsuite/gcc.target/i386/pr119386-1.c | 11 +++
> > > > >  gcc/testsuite/gcc.target/i386/pr119386-2.c | 11 +++
> > > > >  3 files changed, 29 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > > > > index be5e27fc391..0b238c3dddc 100644
> > > > > --- a/gcc/config/i386/i386.cc
> > > > > +++ b/gcc/config/i386/i386.cc
> > > > > @@ -23154,6 +23154,12 @@ x86_print_call_or_nop (FILE *file, const 
> > > > > char *target)
> > > > >if (flag_nop_mcount || !strcmp (target, "nop"))
> > > > >  /* 5 byte nop: nopl 0(%[re]ax,%[re]ax,1) */
> > > > >  fprintf (file, "1:" ASM_BYTE "0x0f, 0x1f, 0x44, 0x00, 0x00\n");
> > > > > +  else if (!TARGET_PECOFF && flag_pic)
> > > > > +{
> > > > > +  gcc_assert (flag_plt);
> > > > > +
> > > > > +  fprintf (file, "1:\tcall\t%s@PLT\n", target);
> > > > > +}
> > > > >else
> > > > >  fprintf (file, "1:\tcall\t%s\n", target);
> > > > >  }
> > > > > @@ -23317,7 +23323,7 @@ x86_function_profiler (FILE *file, int 
> > > > > labelno ATTRIBUTE_UNUSED)
> > > > >   break;
> > > > > case CM_SMALL_PIC:
> > > > > case CM_MEDIUM_PIC:
> > > > > - if (!ix86_direct_extern_access)
> > > > > + if (!flag_plt)
> > > > > {
> > > > >   if (ASSEMBLER_DIALECT == ASM_INTEL)
> > > > > fprintf (file, "1:\tcall\t[QWORD PTR 
> > > > > %s@GOTPCREL[rip]]\n",
> > > > > diff --git a/gcc/testsuite/gcc.target/i386/pr119386-1.c 
> > > > > b/gcc/testsuite/gcc.target/i386/pr119386-1.c
> > > > > new file mode 100644
> > > > > index 000..7930fc6f28d
> > > > > --- /dev/null
> > > > > +++ b/gcc/testsuite/gcc.target/i386/pr119386-1.c
> > > > > @@ -0,0 +1,11 @@
> > > > > +/* PR target/119386 */
> > > > > +/* { dg-do compile { target *-*-linux* } } */
> > > > > +/* { dg-require-effective-target lp64 } */
> > > >
> > > > Can this be dropped?
> > > >
> > >
> > > I copied that from another test, assuming it would limit the testing
> > > to x86_64. Is there a better way to achieve that?
> >
> > -m32 should also generate "call mcount@PLT".
> >
> > >
> > >
> > > > > +/* { dg-options "-O2 -fpic -pg" } */
> > > > > +/* { dg-final { scan-assembler "mcount@PLT" } } */
> > > > > +
> > > > > +int
> > > > > +main ()
> > > > > +{
> > > > > +  return 0;
> > > > > +}
> > > > > diff --git a/gcc/testsuite/gcc.target/i386/pr119386-2.c 
> > > > > b/gcc/testsuite/gcc.target/i386/pr119386-2.c
> > > > > new file mode 100644
> > > > > index 000..6334b9b9072
> > > > > --- /dev/null
> > > > > +++ b/

[PATCH v1 2/4] libstdc++: Add header mdspan to the build-system.

[Luc Grosheintz]

Creates a nearly empty header mdspan and adds it to the build-system and
Doxygen config file.

libstdc++-v3/ChangeLog:

* doc/doxygen/user.cfg.in: Add .
* include/Makefile.am: Ditto.
* include/Makefile.in: Ditto.
* include/precompiled/stdc++.h: Ditto.
* include/std/mdspan: New file.

Signed-off-by: Luc Grosheintz 
---
 libstdc++-v3/doc/doxygen/user.cfg.in  |  1 +
 libstdc++-v3/include/Makefile.am  |  1 +
 libstdc++-v3/include/Makefile.in  |  1 +
 libstdc++-v3/include/precompiled/stdc++.h |  4 ++
 libstdc++-v3/include/std/mdspan   | 48 +++
 5 files changed, 55 insertions(+)
 create mode 100644 libstdc++-v3/include/std/mdspan

diff --git a/libstdc++-v3/doc/doxygen/user.cfg.in 
b/libstdc++-v3/doc/doxygen/user.cfg.in
index ae50f6dd0c7..be42ea5d6b1 100644
--- a/libstdc++-v3/doc/doxygen/user.cfg.in
+++ b/libstdc++-v3/doc/doxygen/user.cfg.in
@@ -878,6 +878,7 @@ INPUT  = @srcdir@/doc/doxygen/doxygroups.cc 
\
  include/list \
  include/locale \
  include/map \
+ include/mdspan \
  include/memory \
  include/memory_resource \
  include/mutex \
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 537774c2668..1140fa0dffd 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -38,6 +38,7 @@ std_freestanding = \
${std_srcdir}/generator \
${std_srcdir}/iterator \
${std_srcdir}/limits \
+   ${std_srcdir}/mdspan \
${std_srcdir}/memory \
${std_srcdir}/numbers \
${std_srcdir}/numeric \
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index 7b96b2207f8..c96e981acd6 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -396,6 +396,7 @@ std_freestanding = \
${std_srcdir}/generator \
${std_srcdir}/iterator \
${std_srcdir}/limits \
+   ${std_srcdir}/mdspan \
${std_srcdir}/memory \
${std_srcdir}/numbers \
${std_srcdir}/numeric \
diff --git a/libstdc++-v3/include/precompiled/stdc++.h 
b/libstdc++-v3/include/precompiled/stdc++.h
index 1ffde3ed450..56c480b6203 100644
--- a/libstdc++-v3/include/precompiled/stdc++.h
+++ b/libstdc++-v3/include/precompiled/stdc++.h
@@ -237,6 +237,10 @@
 #include 
 #endif
 
+#if __cpluslus >= 202207L
+#include 
+#endif
+
 #if __cplusplus > 202302L
 #include 
 #endif
diff --git a/libstdc++-v3/include/std/mdspan b/libstdc++-v3/include/std/mdspan
new file mode 100644
index 000..4094a416d1e
--- /dev/null
+++ b/libstdc++-v3/include/std/mdspan
@@ -0,0 +1,48 @@
+//  -*- C++ -*-
+
+// Copyright (C) 2025 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 mdspan
+ *  This is a Standard C++ Library header.
+ */
+
+#ifndef _GLIBCXX_MDSPAN
+#define _GLIBCXX_MDSPAN 1
+
+#ifdef _GLIBCXX_SYSHDR
+#pragma GCC system_header
+#endif
+
+#define __glibcxx_want_mdspan
+#include 
+
+#ifdef __glibcxx_mdspan
+
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+_GLIBCXX_END_NAMESPACE_VERSION
+}
+#endif
+#endif
-- 
2.49.0

[PATCH v1 0/4] Implement extents from the mdspan header.

[Luc Grosheintz]

Hi,

This is a patch series that implements std::extents from .

I've never contributed to GCC or libstdc++. Hence, any comments about
obvious issues, e.g. too few/many tests, not following conventions
w.r.t. checking prerequisites, use of 'friend class', choice of uglified
names that could clash with other of our uglified names, etc. will be
very well received. In a similar vein let me know if you want the patch
series split differently.

If you deem this an effective way of implementing , I would work
on std::layout_*, std::accessor_default and eventually std::mdspan.

Each commit was tested with 'make check-target-libstdc++-v3' on x86_64.

Thank you!

Luc Grosheintz (4):
  libstdc++: Setup internal FTM for mdspan.
  libstdc++: Add header mdspan to the build-system.
  libstdc++: Implement std::extents [PR107761].
  libstdc++: Add tests for std::extents.

 libstdc++-v3/doc/doxygen/user.cfg.in  |   1 +
 libstdc++-v3/include/Makefile.am  |   1 +
 libstdc++-v3/include/Makefile.in  |   1 +
 libstdc++-v3/include/bits/version.def |   9 +
 libstdc++-v3/include/bits/version.h   |  10 +
 libstdc++-v3/include/precompiled/stdc++.h |   4 +
 libstdc++-v3/include/std/mdspan   | 448 ++
 libstdc++-v3/src/c++23/std.cc.in  |   6 +-
 .../mdspan/extents/assign_copy.cc |  26 +
 .../mdspan/extents/assign_copy_01_neg.cc  |  15 +
 .../mdspan/extents/class_traits.cc|  20 +
 .../23_containers/mdspan/extents/ctor_copy.cc |  34 ++
 .../mdspan/extents/ctor_copy_01_neg.cc|  10 +
 .../mdspan/extents/ctor_copy_02_neg.cc|  10 +
 .../mdspan/extents/ctor_copy_constexpr.cc |  20 +
 .../mdspan/extents/ctor_copy_implicit_00.cc   |  28 ++
 .../mdspan/extents/ctor_copy_implicit_01.cc   |  22 +
 .../extents/ctor_copy_implicit_02_neg.cc  |  10 +
 .../extents/ctor_copy_implicit_03_neg.cc  |   9 +
 .../extents/ctor_copy_implicit_04_neg.cc  |   9 +
 .../mdspan/extents/ctor_ints_00.cc|  30 ++
 .../mdspan/extents/ctor_ints_01.cc|  24 +
 .../mdspan/extents/ctor_ints_02_neg.cc|   9 +
 .../mdspan/extents/ctor_ints_03_neg.cc|   9 +
 .../mdspan/extents/ctor_ints_constexpr.cc |  12 +
 .../extents/ctor_ints_implicit_00_neg.cc  |   9 +
 .../extents/ctor_ints_implicit_01_neg.cc  |   9 +
 .../mdspan/extents/ctor_shape_00.cc   |  35 ++
 .../mdspan/extents/ctor_shape_01.cc   |  17 +
 .../mdspan/extents/ctor_shape_02_neg.cc   |  10 +
 .../mdspan/extents/ctor_shape_03_neg.cc   |  11 +
 .../mdspan/extents/ctor_shape_constexpr.cc|  23 +
 .../mdspan/extents/ctor_shape_implicit_00.cc  |  42 ++
 .../mdspan/extents/ctor_shape_implicit_01.cc  |  19 +
 .../extents/ctor_shape_implicit_02_neg.cc |  11 +
 .../extents/ctor_shape_implicit_03_neg.cc |  12 +
 .../mdspan/extents/ctor_shape_implicit_04.cc  |  24 +
 .../mdspan/extents/custom_integer.cc  |  86 
 .../mdspan/extents/deduction_guide_00.cc  |  23 +
 .../mdspan/extents/deduction_guide_01_neg.cc  |  10 +
 .../23_containers/mdspan/extents/dextents.cc  |  11 +
 .../23_containers/mdspan/extents/extent.cc|  27 ++
 .../mdspan/extents/index_type.cc  |  14 +
 .../23_containers/mdspan/extents/ops_eq.cc|  58 +++
 .../23_containers/mdspan/extents/rank.cc  |  10 +
 .../mdspan/extents/rank_dynamic.cc|  11 +
 .../mdspan/extents/rank_return_type.cc|  14 +
 .../23_containers/mdspan/extents/rank_type.cc |   7 +
 .../23_containers/mdspan/extents/size_type.cc |  16 +
 .../23_containers/mdspan/extents/sizeof.cc|  10 +
 .../mdspan/extents/static_extent.cc   |  15 +
 51 files changed, 1310 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/include/std/mdspan
 create mode 100644 
libstdc++-v3/testsuite/23_containers/mdspan/extents/assign_copy.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/mdspan/extents/assign_copy_01_neg.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/mdspan/extents/class_traits.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/mdspan/extents/ctor_copy.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/mdspan/extents/ctor_copy_01_neg.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/mdspan/extents/ctor_copy_02_neg.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/mdspan/extents/ctor_copy_constexpr.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/mdspan/extents/ctor_copy_implicit_00.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/mdspan/extents/ctor_copy_implicit_01.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/mdspan/extents/ctor_copy_implicit_02_neg.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/mdspan/extents/ctor_copy_implicit_03_neg.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/mdspan/extents/ctor_copy_implicit_04_neg.cc
 create mode 100644 
libstdc++-v3/testsuite/23_co

[PATCH v1 3/4] libstdc++: Implement std::extents [PR107761].

[Luc Grosheintz]

This implements std::extents from  according to N4950 and
contains partial progress towards PR107761.

If an extent changes its type, there's a precondition in the standard,
that the value is representable in the target integer type. This commit
uses a static_cast for all of these conversions, without any additional
checks.

The precondition for 'extents::{static_,}extent' is that '__r < rank()'.
For extents this precondition is always violated and results in
calling __builtin_trap. For all other specializations it's checked via
__glibcxx_assert.

PR libstdc++/107761

libstdc++-v3/ChangeLog:

* include/std/mdspan (extents): New class.
* src/c++23/std.cc.in: Add 'using std::extents'.

Signed-off-by: Luc Grosheintz 
---
 libstdc++-v3/include/std/mdspan  | 400 +++
 libstdc++-v3/src/c++23/std.cc.in |   6 +-
 2 files changed, 405 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/mdspan b/libstdc++-v3/include/std/mdspan
index 4094a416d1e..5c6a1868d62 100644
--- a/libstdc++-v3/include/std/mdspan
+++ b/libstdc++-v3/include/std/mdspan
@@ -33,6 +33,10 @@
 #pragma GCC system_header
 #endif
 
+#include 
+#include 
+#include 
+
 #define __glibcxx_want_mdspan
 #include 
 
@@ -42,6 +46,402 @@ namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
+  namespace __detail
+  {
+// Computed as: sum_i (i == __r) * E_i
+template
+  struct _StaticExtent;
+
+template
+  struct _StaticExtent<_Count, _Extent, _Extents...>
+  {
+   static constexpr size_t
+   _M_value(size_t __r) noexcept
+   {
+ return (_Count == __r) * _Extent
++ _StaticExtent<_Count + 1, _Extents...>::_M_value(__r);
+   }
+  };
+
+template
+  struct _StaticExtent<_Count>
+  {
+   static constexpr size_t
+   _M_value(size_t __r) noexcept
+   { return 0; }
+  };
+
+// Computed as: sum_i (i < __r) * (E_i == dynamic_extent)
+template
+  struct _DynamicIndex;
+
+template
+  struct _DynamicIndex<_Count, _Extent, _Extents...>
+  {
+   static constexpr size_t
+   _M_value(size_t __r) noexcept
+   {
+ return (_Count < __r) * (_Extent == dynamic_extent)
++ _DynamicIndex<_Count + 1, _Extents...>::_M_value(__r);
+   }
+  };
+
+template
+  struct _DynamicIndex<_Count>
+  {
+   static constexpr size_t
+   _M_value(size_t __r) noexcept
+   { return 0; }
+  };
+
+// Computed by: counting the number of dynamic extents (_Dr); and returning
+// the static index first time `__di == _Dr`.
+template
+  struct _DynamicIndexInv;
+
+template
+  struct _DynamicIndexInv<_Si, _Dr, _Extent, _Extents...>
+  {
+   static constexpr size_t
+   _M_value(size_t __di) noexcept
+   {
+ if (_Extent == dynamic_extent && __di == _Dr)
+   return _Si;
+ else
+   return _DynamicIndexInv<_Si+1, _Dr + (_Extent == dynamic_extent),
+   _Extents...>
+  ::_M_value(__di);
+   }
+  };
+
+template
+  struct _DynamicIndexInv<_Si, _Dr, _Extent>
+  {
+   static constexpr size_t
+   _M_value(size_t __di) noexcept
+   {
+ __glibcxx_assert(__di == _Dr);
+ return _Si;
+   }
+  };
+
+// Aim: __ext[i] for template parameter packs.
+template
+  struct _GetPackElement;
+
+template
+  struct _GetPackElement<_Count, _IndexType, _IndexTypes...>
+  {
+   template
+ static constexpr const auto&
+ get(const _IndexType& __current, const _IndexTypes&... __rest)
+ {
+   if constexpr (_Index == _Count)
+ return __current;
+   else
+ return _GetPackElement<_Count+1, _IndexTypes...>
+::template get<_Index>(__rest...);
+ }
+  };
+
+template
+  constexpr const auto&
+  __get_element(const _IndexTypes&... __exts)
+  {
+   return _GetPackElement<0, _IndexTypes...>
+  ::template get<_Di>(__exts...);
+  }
+
+template
+  struct _DynamicRank
+  {
+   static constexpr size_t _S_value = ((_Extents == dynamic_extent) + ...);
+  };
+
+template<>
+  struct _DynamicRank<>
+  {
+   static constexpr size_t _S_value = 0;
+  };
+
+template
+  struct _ExtentsStorage;
+
+template
+  struct _ExtentsStorage<_IndexType, index_sequence<_DynamicIndexes...>,
+index_sequence<_Indexes...>, _Extents...>
+  {
+   static constexpr size_t _S_rank = sizeof...(_Extents);
+
+   static constexpr size_t _S_rank_dynamic =
+ _DynamicRank<_Extents...>::_S_value;
+
+   static constexpr array _S_dynamic_index_inv{
+ _DynamicIndexInv<0, 0, _Extents...> ::_M_value(_DynamicIndexes)...};
+
+   static constexpr array _S_dynamic_index {
+ _Dynam

Re: [PATCH v1 2/4] libstdc++: Add header mdspan to the build-system.

[Jonathan Wakely]

On Wed, 9 Apr 2025, 08:25 Luc Grosheintz,  wrote:

> Creates a nearly empty header mdspan and adds it to the build-system and
> Doxygen config file.
>

Nice, thanks! I'll look at these patches properly another time (I'm
unavailable today) but one quick comment below ...



> libstdc++-v3/ChangeLog:
>
> * doc/doxygen/user.cfg.in: Add .
> * include/Makefile.am: Ditto.
> * include/Makefile.in: Ditto.
> * include/precompiled/stdc++.h: Ditto.
> * include/std/mdspan: New file.
>
> Signed-off-by: Luc Grosheintz 
> ---
>  libstdc++-v3/doc/doxygen/user.cfg.in  |  1 +
>  libstdc++-v3/include/Makefile.am  |  1 +
>  libstdc++-v3/include/Makefile.in  |  1 +
>  libstdc++-v3/include/precompiled/stdc++.h |  4 ++
>  libstdc++-v3/include/std/mdspan   | 48 +++
>  5 files changed, 55 insertions(+)
>  create mode 100644 libstdc++-v3/include/std/mdspan
>
> diff --git a/libstdc++-v3/doc/doxygen/user.cfg.in
> b/libstdc++-v3/doc/doxygen/user.cfg.in
> index ae50f6dd0c7..be42ea5d6b1 100644
> --- a/libstdc++-v3/doc/doxygen/user.cfg.in
> +++ b/libstdc++-v3/doc/doxygen/user.cfg.in
> @@ -878,6 +878,7 @@ INPUT  = 
> @srcdir@/doc/doxygen/doxygroups.cc
> \
>   include/list \
>   include/locale \
>   include/map \
> + include/mdspan \
>   include/memory \
>   include/memory_resource \
>   include/mutex \
> diff --git a/libstdc++-v3/include/Makefile.am
> b/libstdc++-v3/include/Makefile.am
> index 537774c2668..1140fa0dffd 100644
> --- a/libstdc++-v3/include/Makefile.am
> +++ b/libstdc++-v3/include/Makefile.am
> @@ -38,6 +38,7 @@ std_freestanding = \
> ${std_srcdir}/generator \
> ${std_srcdir}/iterator \
> ${std_srcdir}/limits \
> +   ${std_srcdir}/mdspan \
> ${std_srcdir}/memory \
> ${std_srcdir}/numbers \
> ${std_srcdir}/numeric \
> diff --git a/libstdc++-v3/include/Makefile.in
> b/libstdc++-v3/include/Makefile.in
> index 7b96b2207f8..c96e981acd6 100644
> --- a/libstdc++-v3/include/Makefile.in
> +++ b/libstdc++-v3/include/Makefile.in
> @@ -396,6 +396,7 @@ std_freestanding = \
> ${std_srcdir}/generator \
> ${std_srcdir}/iterator \
> ${std_srcdir}/limits \
> +   ${std_srcdir}/mdspan \
> ${std_srcdir}/memory \
> ${std_srcdir}/numbers \
> ${std_srcdir}/numeric \
> diff --git a/libstdc++-v3/include/precompiled/stdc++.h
> b/libstdc++-v3/include/precompiled/stdc++.h
> index 1ffde3ed450..56c480b6203 100644
> --- a/libstdc++-v3/include/precompiled/stdc++.h
> +++ b/libstdc++-v3/include/precompiled/stdc++.h
> @@ -237,6 +237,10 @@
>  #include 
>  #endif
>
> +#if __cpluslus >= 202207L
>

Typo in the macro name here.

+#include 
> +#endif
> +
>  #if __cplusplus > 202302L
>  #include 
>  #endif
> diff --git a/libstdc++-v3/include/std/mdspan
> b/libstdc++-v3/include/std/mdspan
> new file mode 100644
> index 000..4094a416d1e
> --- /dev/null
> +++ b/libstdc++-v3/include/std/mdspan
> @@ -0,0 +1,48 @@
> +//  -*- C++ -*-
> +
> +// Copyright (C) 2025 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 mdspan
> + *  This is a Standard C++ Library header.
> + */
> +
> +#ifndef _GLIBCXX_MDSPAN
> +#define _GLIBCXX_MDSPAN 1
> +
> +#ifdef _GLIBCXX_SYSHDR
> +#pragma GCC system_header
> +#endif
> +
> +#define __glibcxx_want_mdspan
> +#include 
> +
> +#ifdef __glibcxx_mdspan
> +
> +namespace std _GLIBCXX_VISIBILITY(default)
> +{
> +_GLIBCXX_BEGIN_NAMESPACE_VERSION
> +
> +_GLIBCXX_END_NAMESPACE_VERSION
> +}
> +#endif
> +#endif
> --
> 2.49.0
>
>

[PATCH v4 2/2] i386: Enable -mnop-mcount for -fpic with PLTs

[Ard Biesheuvel]

From: Ard Biesheuvel 

On 64-bit, -mnop-mcount can be trivially enabled for -fPIC codegen as
long as PLTs are being used, given that the instruction encodings are
identical, only the target may resolve differently depending on how the
linker decides to incorporate the object file.

So relax the option check, and add a test to ensure that 5-byte NOPs are
emitted in the 64-bit case. On 32-bit, PLTs are never used so
-mnop-mcount remains disallowed in combination with -fPIC.

Signed-off-by: Ard Biesheuvel 

gcc/ChangeLog:

PR target/119386
* config/i386/i386-options.cc: Permit -mnop-mcount on 64-bit
  when using -fpic with PLTs.

gcc/testsuite/ChangeLog:

PR target/119386
* gcc.target/i386/pr119386-3.c: New test.
---
 gcc/config/i386/i386-options.cc|  7 ++-
 gcc/testsuite/gcc.target/i386/pr119386-3.c | 11 +++
 2 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr119386-3.c

diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index fc4d2d2529e..8ecaff8d929 100644
--- a/gcc/config/i386/i386-options.cc
+++ b/gcc/config/i386/i386-options.cc
@@ -2819,7 +2819,12 @@ ix86_option_override_internal (bool main_args_p,
 error ("%<-mnop-mcount%> is not compatible with this target");
 #endif
   if (flag_nop_mcount && flag_pic)
-error ("%<-mnop-mcount%> is not implemented for %<-fPIC%>");
+{
+  if (!TARGET_64BIT)
+   error ("%<-mnop-mcount%> is not implemented for %<-fPIC%>");
+  else if (!flag_plt)
+   error ("%<-mnop-mcount%> is not implemented for %<-fno-plt%>");
+}
 
   /* Accept -msseregparm only if at least SSE support is enabled.  */
   if (TARGET_SSEREGPARM_P (opts->x_target_flags)
diff --git a/gcc/testsuite/gcc.target/i386/pr119386-3.c 
b/gcc/testsuite/gcc.target/i386/pr119386-3.c
new file mode 100644
index 000..b7999c34ce1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr119386-3.c
@@ -0,0 +1,11 @@
+/* PR target/119386 */
+/* { dg-do compile { target *-*-linux* } } */
+/* { dg-options "-O2 -fpic -pg -mnop-mcount" } */
+/* { dg-final { scan-assembler ".byte\[ \t\]0x0f, 0x1f, 0x44, 0x00, 0x00" { 
target { ! ia32 } } } } */
+/* { dg-xfail-if "'-mnop-mcount' is not implemented for '-fPIC'" { ia32 } } */
+
+int
+main ()
+{
+  return 0;
+}
-- 
2.49.0.504.g3bcea36a83-goog

[PATCH v4 1/2] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

[Ard Biesheuvel]

From: Ard Biesheuvel 

Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
__fentry__") updated the logic that emits mcount() / __fentry__() calls
into function prologues when profiling is enabled, to avoid GOT-based
indirect calls when a direct call would suffice.

There are two problems with that change:
- it relies on -mdirect-extern-access rather than -fno-plt to decide
  whether or not a direct [PLT based] call is appropriate;
- for the PLT case, it falls through to x86_print_call_or_nop(), which
  does not emit the @PLT suffix, resulting in the wrong relocation to be
  used (R_X86_64_PC32 instead of R_X86_64_PLT32)

Fix this by testing flag_plt instead of ix86_direct_extern_access, and
updating x86_print_call_or_nop() to take flag_pic and flag_plt into
account. This also ensures that -mnop-mcount works as expected when
emitting the PLT based profiling calls.

Note that only 64-bit codegen is affected by this change or by the
commit referenced above; -m32 will yield 'call *mcount@GOT()' as before.

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

Signed-off-by: Ard Biesheuvel 

gcc/ChangeLog:

PR target/119386
* config/i386/i386.cc (x86_print_call_or_nop): Add @PLT suffix
where appropriate.
(x86_function_profiler): Fall through to x86_print_call_or_nop()
for PIC codegen when flag_plt is set.

gcc/testsuite/ChangeLog:

PR target/119386
* gcc.target/i386/pr119386-1.c: New test.
* gcc.target/i386/pr119386-2.c: New test.
---
 gcc/config/i386/i386.cc|  8 +++-
 gcc/testsuite/gcc.target/i386/pr119386-1.c | 11 +++
 gcc/testsuite/gcc.target/i386/pr119386-2.c | 12 
 3 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr119386-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr119386-2.c

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index be5e27fc391..0b238c3dddc 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -23154,6 +23154,12 @@ x86_print_call_or_nop (FILE *file, const char *target)
   if (flag_nop_mcount || !strcmp (target, "nop"))
 /* 5 byte nop: nopl 0(%[re]ax,%[re]ax,1) */
 fprintf (file, "1:" ASM_BYTE "0x0f, 0x1f, 0x44, 0x00, 0x00\n");
+  else if (!TARGET_PECOFF && flag_pic)
+{
+  gcc_assert (flag_plt);
+
+  fprintf (file, "1:\tcall\t%s@PLT\n", target);
+}
   else
 fprintf (file, "1:\tcall\t%s\n", target);
 }
@@ -23317,7 +23323,7 @@ x86_function_profiler (FILE *file, int labelno 
ATTRIBUTE_UNUSED)
  break;
case CM_SMALL_PIC:
case CM_MEDIUM_PIC:
- if (!ix86_direct_extern_access)
+ if (!flag_plt)
{
  if (ASSEMBLER_DIALECT == ASM_INTEL)
fprintf (file, "1:\tcall\t[QWORD PTR %s@GOTPCREL[rip]]\n",
diff --git a/gcc/testsuite/gcc.target/i386/pr119386-1.c 
b/gcc/testsuite/gcc.target/i386/pr119386-1.c
new file mode 100644
index 000..174d00f1e27
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr119386-1.c
@@ -0,0 +1,11 @@
+/* PR target/119386 */
+/* { dg-do compile { target *-*-linux* } } */
+/* { dg-options "-O2 -fpic -pg" } */
+/* { dg-final { scan-assembler "call\[ \t\]mcount@PLT" { target { ! ia32 } } } 
} */
+/* { dg-final { scan-assembler "call\[ \t\]\\*mcount@GOT\\(" { target ia32 } } 
} */
+
+int
+main ()
+{
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr119386-2.c 
b/gcc/testsuite/gcc.target/i386/pr119386-2.c
new file mode 100644
index 000..808dd9298ce
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr119386-2.c
@@ -0,0 +1,12 @@
+/* PR target/119386 */
+/* { dg-do compile { target *-*-linux* } } */
+/* { dg-options "-O2 -fpic -fno-plt -pg" } */
+/* { dg-final { scan-assembler "call\[ \t\]\\*mcount@GOTPCREL\\(" { target { ! 
ia32 } } } } */
+/* { dg-final { scan-assembler "call\[ \t\]\\*mcount@GOT\\(" { target ia32 } } 
} */
+
+
+int
+main ()
+{
+  return 0;
+}
-- 
2.49.0.504.g3bcea36a83-goog

Re: [PATCH 2/2] libgcobol: Allow libgcobol to use libquadmath [PR119244].

[Iain Sandoe]

> On 9 Apr 2025, at 09:00, Rainer Orth  wrote:
> 
> Jakub Jelinek  writes:
> 
>> On Sun, Apr 06, 2025 at 09:02:07AM +0100, Iain Sandoe wrote:
>>> 
>>> +
>>> +#if !defined (HAVE_STRTOF128)
>>> +# if USE_QUADMATH
>>> +#  define strtof128 strtoflt128
>>> +# else
>>> +#  error "no available string to float 128"
>>> +# endif
>>> +#endif
>> 
>> If there is no strtof128 and not using libquadmath, there is always
>> the possibility to use strtold if long double is IEEE quad.
>> But that can be fixed incrementally.
>> 
>> As for strfromf128, there is always the possibility to use snprintf
>> with %.36LE format specifier if long double is IEEE quad.
> 
> That's what's needed on Solaris/SPARC which has _Float128, 128-bit long
> double, but no __float128 (yet, patch WIP).

OK - so you have the case:
 - long double == ieee753 128b float
 - no support for the io/transcendental functions in libc?

> There's one remaing issue in that case:
> 
> /vol/gcc/src/hg/master/cobol/libgcobol/intrinsic.cc:999:5: error: unsupported 
> non-standard suffix on floating constant
> 
> This needs
> 
> diff --git a/libgcobol/intrinsic.cc b/libgcobol/intrinsic.cc
> --- a/libgcobol/intrinsic.cc
> +++ b/libgcobol/intrinsic.cc
> @@ -67,7 +67,7 @@
> 
> #define JD_OF_1601_01_02 2305812.5
> 
> -#define WEIRD_TRANSCENDENT_RETURN_VALUE (0.0Q)
> +#define WEIRD_TRANSCENDENT_RETURN_VALUE GCOB_FP128_LITERAL (0.0)
> #define NO_RDIGITS (0)
> 
> struct cobol_tm
> 
> I guess it would be better to move that strtof128 and strfromf128
> handling to libgcobol-fp.h to avoid duplication.

I think that the right solution is probably to define something in  
libgcobol-fp.h that
shortens the tests, because IIRC we have to adapt the format string on the basis
of which case we have so some of the work cannot be completely moved to the
header.

Happy to do this incrementally or as a v2 - depending on the maintainer’s views.

Iain



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

Re: [PATCH v1 4/4] libstdc++: Add tests for std::extents.

[Jonathan Wakely]

On Wed, 9 Apr 2025 at 08:30, Luc Grosheintz  wrote:
>
> A prior commit added std::extents, this commits adds the tests. The bulk
> is focussed on testing the constructors. These are split into three
> groups:
>
> 1. the ctor from other extents and the copy ctor,
> 2. the ctor from a pack of integer-like objects,
> 3. the ctor from shapes, i.e. span and array.
>
> For each group check that the ctor:
> * produces an object with the expected values for extent,
> * is implicit if and only if required,
> * is constexpr,
> * doesn't change the rank of the extent.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/23_containers/mdspan/extents/assign_copy.cc: New test.
> * testsuite/23_containers/mdspan/extents/assign_copy_01_neg.cc: New 
> test.
> * testsuite/23_containers/mdspan/extents/class_traits.cc: New test.
> * testsuite/23_containers/mdspan/extents/ctor_copy.cc: New test.
> * testsuite/23_containers/mdspan/extents/ctor_copy_01_neg.cc: New 
> test.
> * testsuite/23_containers/mdspan/extents/ctor_copy_02_neg.cc: New 
> test.
> * testsuite/23_containers/mdspan/extents/ctor_copy_constexpr.cc: New 
> test.
> * testsuite/23_containers/mdspan/extents/ctor_copy_implicit_00.cc: 
> New test.
> * testsuite/23_containers/mdspan/extents/ctor_copy_implicit_01.cc: 
> New test.
> * 
> testsuite/23_containers/mdspan/extents/ctor_copy_implicit_02_neg.cc: New test.
> * 
> testsuite/23_containers/mdspan/extents/ctor_copy_implicit_03_neg.cc: New test.
> * 
> testsuite/23_containers/mdspan/extents/ctor_copy_implicit_04_neg.cc: New test.
> * testsuite/23_containers/mdspan/extents/ctor_ints_00.cc: New test.
> * testsuite/23_containers/mdspan/extents/ctor_ints_01.cc: New test.
> * testsuite/23_containers/mdspan/extents/ctor_ints_02_neg.cc: New 
> test.
> * testsuite/23_containers/mdspan/extents/ctor_ints_03_neg.cc: New 
> test.
> * testsuite/23_containers/mdspan/extents/ctor_ints_constexpr.cc: New 
> test.
> * 
> testsuite/23_containers/mdspan/extents/ctor_ints_implicit_00_neg.cc: New test.
> * 
> testsuite/23_containers/mdspan/extents/ctor_ints_implicit_01_neg.cc: New test.
> * testsuite/23_containers/mdspan/extents/ctor_shape_00.cc: New test.
> * testsuite/23_containers/mdspan/extents/ctor_shape_01.cc: New test.
> * testsuite/23_containers/mdspan/extents/ctor_shape_02_neg.cc: New 
> test.
> * testsuite/23_containers/mdspan/extents/ctor_shape_03_neg.cc: New 
> test.
> * testsuite/23_containers/mdspan/extents/ctor_shape_constexpr.cc: New 
> test.
> * testsuite/23_containers/mdspan/extents/ctor_shape_implicit_00.cc: 
> New test.
> * testsuite/23_containers/mdspan/extents/ctor_shape_implicit_01.cc: 
> New test.
> * 
> testsuite/23_containers/mdspan/extents/ctor_shape_implicit_02_neg.cc: New 
> test.
> * 
> testsuite/23_containers/mdspan/extents/ctor_shape_implicit_03_neg.cc: New 
> test.
> * testsuite/23_containers/mdspan/extents/ctor_shape_implicit_04.cc: 
> New test.
> * testsuite/23_containers/mdspan/extents/custom_integer.cc: New test.
> * testsuite/23_containers/mdspan/extents/deduction_guide_00.cc: New 
> test.
> * testsuite/23_containers/mdspan/extents/deduction_guide_01_neg.cc: 
> New test.
> * testsuite/23_containers/mdspan/extents/dextents.cc: New test.
> * testsuite/23_containers/mdspan/extents/extent.cc: New test.
> * testsuite/23_containers/mdspan/extents/index_type.cc: New test.
> * testsuite/23_containers/mdspan/extents/ops_eq.cc: New test.
> * testsuite/23_containers/mdspan/extents/rank.cc: New test.
> * testsuite/23_containers/mdspan/extents/rank_dynamic.cc: New test.
> * testsuite/23_containers/mdspan/extents/rank_return_type.cc: New 
> test.
> * testsuite/23_containers/mdspan/extents/rank_type.cc: New test.
> * testsuite/23_containers/mdspan/extents/size_type.cc: New test.
> * testsuite/23_containers/mdspan/extents/sizeof.cc: New test.
> * testsuite/23_containers/mdspan/extents/static_extent.cc: New test.
>
> Signed-off-by: Luc Grosheintz 
> ---
>  .../mdspan/extents/assign_copy.cc | 26 ++
>  .../mdspan/extents/assign_copy_01_neg.cc  | 15 
>  .../mdspan/extents/class_traits.cc| 20 +
>  .../23_containers/mdspan/extents/ctor_copy.cc | 34 
>  .../mdspan/extents/ctor_copy_01_neg.cc| 10 +++
>  .../mdspan/extents/ctor_copy_02_neg.cc| 10 +++
>  .../mdspan/extents/ctor_copy_constexpr.cc | 20 +
>  .../mdspan/extents/ctor_copy_implicit_00.cc   | 28 ++
>  .../mdspan/extents/ctor_copy_implicit_01.cc   | 22 +
>  .../extents/ctor_copy_implicit_02_neg.cc  | 10 +++
>  .../extents/ctor_copy_implicit_03_neg.cc  |  9 ++
>  .../extents/ctor_copy_implicit_04_neg.cc  |  9 ++
>  .../mdspan/extents/ctor_ints_00.cc  

Re: [PATCH v3] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

[Uros Bizjak]

On Tue, Apr 8, 2025 at 7:09 PM H.J. Lu  wrote:

> > Are there any existing test cases I should look at?
>
> Please see "gcc.target/i386/pr67215-*.c"

While looking there, I noticed that the asterisk is not correctly
escaped in scan strings. Asterisk in [...]* applies to square
brackets, not scan string.

I'll fix the testcases.

Uros.

New template for 'gcc' made available

[Translation Project Robot]

Hello, gentle maintainer.

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

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

https://translationproject.org/POT-files/gcc-15-b20250406.pot

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

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

https://gcc.gnu.org/pub/gcc/snapshots/15-20250406/gcc-15-20250406.tar.xz

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

Thank you for all your work,

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

[PATCH] testsuite: Add -mabi to pr116595.C

[Robin Dapp]

Hi,

as usual, I forgot to add -mabi=lp64d to the test case.  This patch adds
it.  Going to push as obvious.

Regards
Robin

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/autovec/pr116595.C: Add -mabi.
---
gcc/testsuite/g++.target/riscv/rvv/autovec/pr116595.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.target/riscv/rvv/autovec/pr116595.C 
b/gcc/testsuite/g++.target/riscv/rvv/autovec/pr116595.C
index 6d509d2cf74..37475493a21 100644
--- a/gcc/testsuite/g++.target/riscv/rvv/autovec/pr116595.C
+++ b/gcc/testsuite/g++.target/riscv/rvv/autovec/pr116595.C
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-march=rv64gcv" } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d" } */

#include 

--
2.49.0

Re: [PATCH] libgomp: Update SVE tests

[Tejas Belagod]

On 4/9/25 2:32 AM, Richard Sandiford wrote:

The new SVE tests didn't explicitly force SVE to be enabled,
which meant that they wouldn't work on targets that aren't
configured for SVE by default.  The least invasive way of
fixing that is to add a pragma, which works for most tests.
However, for udr-sve.c, the global:

  #pragma omp declare reduction (+:svint32_t: omp_out = svadd_s32_z 
(svptrue_b32(), omp_in, omp_out)) \
initializer (omp_priv = svindex_s32 (0, 0))

does not work with an earlier:

  #pragma GCC target "+sve"

which is interesting, and maybe worthy of a PR if there isn't one
already.  It seems we have to force SVE (and thus an architecture)
on the command line instead.



Ah sorry for breaking this - I thought { target aarch64_sve256_hw } 
checked for SVE support and bypassed if not being built for SVE target.



However, with that fixed, udr-sve.c fails execution.  One problem
seems to be a missing accumulation in for_reduction.  Fixing that
is enough to reach the final inscan_reduction_incl, but that fails
for reasons I haven't investigated yet.  I would need to read up
more to understand what the loop is doing.

It also looks like there might be a missing "+" in simd_reduction:

   #pragma omp simd reduction (+:va, i)
   for (j = 0; j < 16; j++)
 va = svld1_s32 (svptrue_b32 (), a);

   res = svaddv_s32 (svptrue_b32 (), va);

   if (res != 8)
 __builtin_abort ();

since AFAICT the loop is not doing a reduction as things stand.
But perhaps that's deliberate, since it does match the != 8 test.


That's interesting. I thought the reduction definition in the
'declare reduction' does the reduction from all the individual 
interations according the the rules defined in the reduction 
irrespective of the loop structure.  Maybe 'va' doesn't become implicit 
private and causes a race (which may be why I didn't see it in my 
testing) - I'll try to repro this and have a look.


Thanks,
Tejas.



Tested on aarch64-linux-gnu, where it fixes everything apart from
the udr-sve.c execution failure.  Should I install this as a partial
fix, or would you prefer to fix everything in one go?

Richard


libgomp/
* testsuite/libgomp.c-target/aarch64/firstprivate.c: Add +sve pragma.
* testsuite/libgomp.c-target/aarch64/lastprivate.c: Likewise.
* testsuite/libgomp.c-target/aarch64/private.c: Likewise.
* testsuite/libgomp.c-target/aarch64/shared.c: Likewise.
* testsuite/libgomp.c-target/aarch64/simd-aligned.c: Likewise.
* testsuite/libgomp.c-target/aarch64/simd-nontemporal.c: Likewise.
* testsuite/libgomp.c-target/aarch64/threadprivate.c: Likewise.
* testsuite/libgomp.c-target/aarch64/udr-sve.c: Add an -march option.
(for_reduction): Use "+=" in the reduction loop.
---
  libgomp/testsuite/libgomp.c-target/aarch64/firstprivate.c | 2 ++
  libgomp/testsuite/libgomp.c-target/aarch64/lastprivate.c  | 2 ++
  libgomp/testsuite/libgomp.c-target/aarch64/private.c  | 2 ++
  libgomp/testsuite/libgomp.c-target/aarch64/shared.c   | 2 ++
  libgomp/testsuite/libgomp.c-target/aarch64/simd-aligned.c | 2 ++
  libgomp/testsuite/libgomp.c-target/aarch64/simd-nontemporal.c | 2 ++
  libgomp/testsuite/libgomp.c-target/aarch64/threadprivate.c| 2 ++
  libgomp/testsuite/libgomp.c-target/aarch64/udr-sve.c  | 4 ++--
  8 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/libgomp/testsuite/libgomp.c-target/aarch64/firstprivate.c 
b/libgomp/testsuite/libgomp.c-target/aarch64/firstprivate.c
index 930ca6215b6..58674e23dbb 100644
--- a/libgomp/testsuite/libgomp.c-target/aarch64/firstprivate.c
+++ b/libgomp/testsuite/libgomp.c-target/aarch64/firstprivate.c
@@ -1,6 +1,8 @@
  /* { dg-do run { target aarch64_sve256_hw } } */
  /* { dg-options "-msve-vector-bits=256 -fopenmp -O2" } */
  
+#pragma GCC target "+sve"

+
  #include 
  #include 
  
diff --git a/libgomp/testsuite/libgomp.c-target/aarch64/lastprivate.c b/libgomp/testsuite/libgomp.c-target/aarch64/lastprivate.c

index be5a618c1b8..2f93d7bb312 100644
--- a/libgomp/testsuite/libgomp.c-target/aarch64/lastprivate.c
+++ b/libgomp/testsuite/libgomp.c-target/aarch64/lastprivate.c
@@ -1,6 +1,8 @@
  /* { dg-do run { target aarch64_sve256_hw } } */
  /* { dg-options "-msve-vector-bits=256 -fopenmp -O2" } */
  
+#pragma GCC target "+sve"

+
  #include 
  #include 
  
diff --git a/libgomp/testsuite/libgomp.c-target/aarch64/private.c b/libgomp/testsuite/libgomp.c-target/aarch64/private.c

index 0ca74fe4e4b..fed5370c8d0 100644
--- a/libgomp/testsuite/libgomp.c-target/aarch64/private.c
+++ b/libgomp/testsuite/libgomp.c-target/aarch64/private.c
@@ -1,6 +1,8 @@
  /* { dg-do run { target aarch64_sve256_hw } } */
  /* { dg-options "-msve-vector-bits=256 -fopenmp -O2" } */
  
+#pragma GCC target "+sve"

+
  #include 
  #include 
  
diff --git a/libgomp/testsuite/libgomp.c-target/aarch64/shared.c b/libgomp/testsuite/libgomp.c-target/aarch64/shared.c

index dec41b8003

Re: [PATCH] libgomp: Update SVE tests

[Jakub Jelinek]

On Wed, Apr 09, 2025 at 04:01:49PM +0530, Tejas Belagod wrote:
> > It also looks like there might be a missing "+" in simd_reduction:
> > 
> >#pragma omp simd reduction (+:va, i)
> >for (j = 0; j < 16; j++)
> >  va = svld1_s32 (svptrue_b32 (), a);
> > 
> >res = svaddv_s32 (svptrue_b32 (), va);
> > 
> >if (res != 8)
> >  __builtin_abort ();
> > 
> > since AFAICT the loop is not doing a reduction as things stand.
> > But perhaps that's deliberate, since it does match the != 8 test.
> 
> That's interesting. I thought the reduction definition in the
> 'declare reduction' does the reduction from all the individual interations
> according the the rules defined in the reduction irrespective of the loop
> structure.  Maybe 'va' doesn't become implicit private and causes a race
> (which may be why I didn't see it in my testing) - I'll try to repro this
> and have a look.

No, reduction privatizes the variable, initializes the private variable with
the initializer from UDR and reduces at the end only from all the private
variables to the original one.

For simd, each SIMD lane has one private copy and there are # SIMD lanes
reductions into the original, for e.g. worksharing constructs each thread
has a private copy and there are omp_get_num_threads () reductions, etc.

There is no special action at the end of each loop body, it is up to the
user to merge state from each iteration.  In sane code the loop body does
similar operation to what the reduction does.
So say if you have
float sum = 0;
#pragma omp parallel for reduction (+:sum)
for (int i = 0; i < 1024; ++i)
  sum += a[i];
then if OpenMP pragmas are ignored, all the array members
are summed up in that order, while if say there are 4
threads and each handles 256 iterations, then each thread will
start with sum = 0; and do sum += a[i]; for i omp_get_thread_num () * 256
to omp_get_thread_num () * 256 + 255 inclusive and finally in some random
order the 4 private floats will be summed together.
For floating point that can result in different behavior (different rounding
etc.) but user said it is ok like that.

Jakub

Re: [PATCH v1 2/4] libstdc++: Add header mdspan to the build-system.

[Jonathan Wakely]

On Wed, 9 Apr 2025, 09:12 Jonathan Wakely,  wrote:

>
>
> On Wed, 9 Apr 2025, 08:25 Luc Grosheintz, 
> wrote:
>
>> Creates a nearly empty header mdspan and adds it to the build-system and
>> Doxygen config file.
>>
>
> Nice, thanks! I'll look at these patches properly another time (I'm
> unavailable today) but one quick comment below ...
>
>
>
>> libstdc++-v3/ChangeLog:
>>
>> * doc/doxygen/user.cfg.in: Add .
>> * include/Makefile.am: Ditto.
>> * include/Makefile.in: Ditto.
>> * include/precompiled/stdc++.h: Ditto.
>> * include/std/mdspan: New file.
>>
>> Signed-off-by: Luc Grosheintz 
>> ---
>>  libstdc++-v3/doc/doxygen/user.cfg.in  |  1 +
>>  libstdc++-v3/include/Makefile.am  |  1 +
>>  libstdc++-v3/include/Makefile.in  |  1 +
>>  libstdc++-v3/include/precompiled/stdc++.h |  4 ++
>>  libstdc++-v3/include/std/mdspan   | 48 +++
>>  5 files changed, 55 insertions(+)
>>  create mode 100644 libstdc++-v3/include/std/mdspan
>>
>> diff --git a/libstdc++-v3/doc/doxygen/user.cfg.in
>> b/libstdc++-v3/doc/doxygen/user.cfg.in
>> index ae50f6dd0c7..be42ea5d6b1 100644
>> --- a/libstdc++-v3/doc/doxygen/user.cfg.in
>> +++ b/libstdc++-v3/doc/doxygen/user.cfg.in
>> @@ -878,6 +878,7 @@ INPUT  = 
>> @srcdir@/doc/doxygen/doxygroups.cc
>> \
>>   include/list \
>>   include/locale \
>>   include/map \
>> + include/mdspan \
>>   include/memory \
>>   include/memory_resource \
>>   include/mutex \
>> diff --git a/libstdc++-v3/include/Makefile.am
>> b/libstdc++-v3/include/Makefile.am
>> index 537774c2668..1140fa0dffd 100644
>> --- a/libstdc++-v3/include/Makefile.am
>> +++ b/libstdc++-v3/include/Makefile.am
>> @@ -38,6 +38,7 @@ std_freestanding = \
>> ${std_srcdir}/generator \
>> ${std_srcdir}/iterator \
>> ${std_srcdir}/limits \
>> +   ${std_srcdir}/mdspan \
>> ${std_srcdir}/memory \
>> ${std_srcdir}/numbers \
>> ${std_srcdir}/numeric \
>> diff --git a/libstdc++-v3/include/Makefile.in
>> b/libstdc++-v3/include/Makefile.in
>> index 7b96b2207f8..c96e981acd6 100644
>> --- a/libstdc++-v3/include/Makefile.in
>> +++ b/libstdc++-v3/include/Makefile.in
>> @@ -396,6 +396,7 @@ std_freestanding = \
>> ${std_srcdir}/generator \
>> ${std_srcdir}/iterator \
>> ${std_srcdir}/limits \
>> +   ${std_srcdir}/mdspan \
>> ${std_srcdir}/memory \
>> ${std_srcdir}/numbers \
>> ${std_srcdir}/numeric \
>> diff --git a/libstdc++-v3/include/precompiled/stdc++.h
>> b/libstdc++-v3/include/precompiled/stdc++.h
>> index 1ffde3ed450..56c480b6203 100644
>> --- a/libstdc++-v3/include/precompiled/stdc++.h
>> +++ b/libstdc++-v3/include/precompiled/stdc++.h
>> @@ -237,6 +237,10 @@
>>  #include 
>>  #endif
>>
>> +#if __cpluslus >= 202207L
>>
>
> Typo in the macro name here.
>

And actually I think this #include should just be in the group above, with
expected, stdfloat, and other c++23 headers.



> +#include 
>> +#endif
>> +
>>  #if __cplusplus > 202302L
>>  #include 
>>  #endif
>> diff --git a/libstdc++-v3/include/std/mdspan
>> b/libstdc++-v3/include/std/mdspan
>> new file mode 100644
>> index 000..4094a416d1e
>> --- /dev/null
>> +++ b/libstdc++-v3/include/std/mdspan
>> @@ -0,0 +1,48 @@
>> +//  -*- C++ -*-
>> +
>> +// Copyright (C) 2025 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 mdspan
>> + *  This is a Standard C++ Library header.
>> + */
>> +
>> +#ifndef _GLIBCXX_MDSPAN
>> +#define _GLIBCXX_MDSPAN 1
>> +
>> +#ifdef _GLIBCXX_SYSHDR
>> +#pragma GCC system_header
>> +#endif
>> +
>> +#define __glibcxx_want_mdspan
>> +#include 
>> +
>> +#ifdef __glibcxx_mdspan
>> +
>> +namespace std _GLIBCXX_VISIBILITY(default)
>> +{
>> +_GLIBCXX_BEGIN_NAMESPACE_V

Re: [PATCH v1] RISC-V: Refine the testcases for cond_widen_complicate-3

[Robin Dapp]

Hi Pan,

Richard committed combine patches that restored most of the previous behavior 
so we shouldn't need the refinement any more.
AFAICT the tests should now pass in their previous state but definitely fail in 
their current state.  Do you want to revert this change?


Thanks.

--
Regards
Robin

Re: [PATCH] libstdc++: Fix constraint recursion in basic_const_iterator operator- [PR115046]

[Jonathan Wakely]

On Tue, 8 Apr 2025, 23:01 Patrick Palka,  wrote:

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

OK for both.


> -- >8 --
>
> It was proposed in PR112490 to also adjust basic_const_iterator's friend
> operator-(sent, iter) overload alongside the r15-7757-g4342c50ca84ae5
> adjustments to its comparison operators, but we lacked a concrete
> testcase demonstrating fixable constraint recursion there.  It turns out
> Hewill Kang's PR115046 is such a testcase!  So this patch makes the same
> adjustments to that overload as well, fixing PR115046.  The LWG 4218 P/R
> needs to get adjusted as well.
>

I was going to suggest updating the lwg issue, thanks.


> PR libstdc++/115046
> PR libstdc++/112490
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_iterator.h (basic_const_iterator::operator-):
> Replace non-dependent basic_const_iterator function parameter with
> a dependent one of type basic_const_iterator<_It2> where _It2
> matches _It.
> * testsuite/std/ranges/adaptors/as_const/1.cc (test04): New test.
> ---
>  libstdc++-v3/include/bits/stl_iterator.h|  4 ++--
>  .../testsuite/std/ranges/adaptors/as_const/1.cc | 13 +
>  2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/include/bits/stl_iterator.h
> b/libstdc++-v3/include/bits/stl_iterator.h
> index 33732b1a4287..9203a66b2ff0 100644
> --- a/libstdc++-v3/include/bits/stl_iterator.h
> +++ b/libstdc++-v3/include/bits/stl_iterator.h
> @@ -2933,10 +2933,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>noexcept(noexcept(_M_current - __y))
>{ return _M_current - __y; }
>
> -template<__detail::__not_a_const_iterator _Sent>
> +template<__detail::__not_a_const_iterator _Sent, same_as<_It> _It2>
>requires sized_sentinel_for<_Sent, _It>
>friend constexpr difference_type
> -  operator-(const _Sent& __x, const basic_const_iterator& __y)
> +  operator-(const _Sent& __x, const basic_const_iterator<_It2>& __y)
>noexcept(noexcept(__x - __y._M_current))
>{ return __x - __y._M_current; }
>
> diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/as_const/1.cc
> b/libstdc++-v3/testsuite/std/ranges/adaptors/as_const/1.cc
> index 3f1f8eb17726..5ccf47d4d300 100644
> --- a/libstdc++-v3/testsuite/std/ranges/adaptors/as_const/1.cc
> +++ b/libstdc++-v3/testsuite/std/ranges/adaptors/as_const/1.cc
> @@ -69,10 +69,23 @@ test03()
>  auto r2 = views::as_const(views::all(v));
>  }
>
> +void
> +test04()
> +{
> +  // PR libstdc++/115046 - meta-recursion with join_view and as_const_view
> +  int x[3] = {1,2,3};
> +  auto v = x
> +| views::chunk(3)
> +| views::transform(views::as_const)
> +| views::join;
> +  VERIFY( ranges::equal(v, x) );
> +}
> +
>  int
>  main()
>  {
>static_assert(test01());
>static_assert(test02());
>test03();
> +  test04();
>  }
> --
> 2.49.0.154.g9d22ac5122
>
>

New template for 'gcc' made available

[Translation Project Robot]

Hello, gentle maintainer.

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

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

https://translationproject.org/POT-files/gcc-15.1-b20250406.pot

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

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

https://gcc.gnu.org/pub/gcc/snapshots/15-20250406/gcc-15-20250406.tar.xz

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

Thank you for all your work,

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

New French PO file for 'gcc' (version 15.1-b20250406)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

(This file, 'gcc-15.1-b20250406.fr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

RE: [PATCH v1] RISC-V: Refine the testcases for cond_widen_complicate-3

[Li, Pan2]

I see, reverted. Thanks Robin for reminder.

BTW and just for open discussion, is this really a good way for such kind of 
tests?
Though most of the tests are similar like this but it may hide possible 
unexpected results up to a point.

Pan

-Original Message-
From: Robin Dapp  
Sent: Wednesday, April 9, 2025 6:47 PM
To: Li, Pan2 ; Robin Dapp ; 
gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; Chen, 
Ken ; Robin Dapp 
Subject: Re: [PATCH v1] RISC-V: Refine the testcases for cond_widen_complicate-3

Hi Pan,

Richard committed combine patches that restored most of the previous behavior 
so we shouldn't need the refinement any more.
AFAICT the tests should now pass in their previous state but definitely fail in 
their current state.  Do you want to revert this change?

Thanks.

-- 
Regards
 Robin