[PATCH] builtins: Fix up strspn/strcspn folding [PR119219]

[Jakub Jelinek]

Hi!

The PR119204 r15-7955 fix caused some regressions.
The problem is that the fold_builtin* APIs document that expr is
either a CALL_EXPR of the call or NULL, so using TREE_TYPE (expr)
can crash e.g. during constexpr evaluation etc.

As can be seen in the surrounding patch, for the neighbouring builtins
(both modf and strpbrk) fold_builtin_2 passes down type, which is the
result type, TREE_TYPE (TREE_TYPE (fndecl)) and those builtins use it
to build the return value, while strspn was always building size_type_node
and strcspn had this change from that to TREE_TYPE (expr).
The patch passes type to these two and uses it there as well.

The patch keeps passing expr because it is used in the
check_nul_terminated_array calls done for both strspn and strcspn,
those calls clearly can deal with NULL expr but prefer if it is non-NULL
for some warning.

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

2025-03-12  Jakub Jelinek  

PR middle-end/119204
PR middle-end/119219
* builtins.cc (fold_builtin_2): Pass type as another argument
to fold_builtin_strspn and fold_builtin_strcspn.
(fold_builtin_strspn): Add type argument, use it instead of
size_type_node.
(fold_builtin_strcspn): Add type argument, use it instead of
TREE_TYPE (expr).

--- gcc/builtins.cc.jj  2025-03-11 12:05:42.561533453 +0100
+++ gcc/builtins.cc 2025-03-11 15:36:47.774314011 +0100
@@ -176,8 +176,8 @@ static tree fold_builtin_iseqsig (locati
 static tree fold_builtin_varargs (location_t, tree, tree*, int);
 
 static tree fold_builtin_strpbrk (location_t, tree, tree, tree, tree);
-static tree fold_builtin_strspn (location_t, tree, tree, tree);
-static tree fold_builtin_strcspn (location_t, tree, tree, tree);
+static tree fold_builtin_strspn (location_t, tree, tree, tree, tree);
+static tree fold_builtin_strcspn (location_t, tree, tree, tree, tree);
 
 static rtx expand_builtin_object_size (tree);
 static rtx expand_builtin_memory_chk (tree, rtx, machine_mode,
@@ -10800,10 +10800,10 @@ fold_builtin_2 (location_t loc, tree exp
   return fold_builtin_modf (loc, arg0, arg1, type);
 
 case BUILT_IN_STRSPN:
-  return fold_builtin_strspn (loc, expr, arg0, arg1);
+  return fold_builtin_strspn (loc, expr, arg0, arg1, type);
 
 case BUILT_IN_STRCSPN:
-  return fold_builtin_strcspn (loc, expr, arg0, arg1);
+  return fold_builtin_strcspn (loc, expr, arg0, arg1, type);
 
 case BUILT_IN_STRPBRK:
   return fold_builtin_strpbrk (loc, expr, arg0, arg1, type);
@@ -11304,7 +11304,7 @@ fold_builtin_strpbrk (location_t loc, tr
form of the builtin function call.  */
 
 static tree
-fold_builtin_strspn (location_t loc, tree expr, tree s1, tree s2)
+fold_builtin_strspn (location_t loc, tree expr, tree s1, tree s2, tree type)
 {
   if (!validate_arg (s1, POINTER_TYPE)
   || !validate_arg (s2, POINTER_TYPE))
@@ -11320,8 +11320,7 @@ fold_builtin_strspn (location_t loc, tre
   if ((p1 && *p1 == '\0') || (p2 && *p2 == '\0'))
 /* Evaluate and ignore both arguments in case either one has
side-effects.  */
-return omit_two_operands_loc (loc, size_type_node, size_zero_node,
- s1, s2);
+return omit_two_operands_loc (loc, type, size_zero_node, s1, s2);
   return NULL_TREE;
 }
 
@@ -11344,7 +11343,7 @@ fold_builtin_strspn (location_t loc, tre
form of the builtin function call.  */
 
 static tree
-fold_builtin_strcspn (location_t loc, tree expr, tree s1, tree s2)
+fold_builtin_strcspn (location_t loc, tree expr, tree s1, tree s2, tree type)
 {
   if (!validate_arg (s1, POINTER_TYPE)
   || !validate_arg (s2, POINTER_TYPE))
@@ -11360,8 +11359,7 @@ fold_builtin_strcspn (location_t loc, tr
 {
   /* Evaluate and ignore argument s2 in case it has
 side-effects.  */
-  return omit_one_operand_loc (loc, TREE_TYPE (expr),
-  size_zero_node, s2);
+  return omit_one_operand_loc (loc, type, size_zero_node, s2);
 }
 
   /* If the second argument is "", return __builtin_strlen(s1).  */
@@ -11375,7 +11373,7 @@ fold_builtin_strcspn (location_t loc, tr
   if (!fn)
return NULL_TREE;
 
-  return fold_convert_loc (loc, TREE_TYPE (expr),
+  return fold_convert_loc (loc, type,
   build_call_expr_loc (loc, fn, 1, s1));
 }
   return NULL_TREE;

Jakub

Re: [v5,2/4] RISC-V: Add Zicfilp ISA extension

[Jin Ma]

Hi, Monk Chiang

I noticed that at -O0, static functions are emitting lpad instructions, whereas
they do not at -O2. I'm not sure if this is expected behavior.

Upon further investigation, I found that c_node->only_called_directly_p() 
returns
false, which is caused by force_output being set to 1. Tracing back, I 
encountered
the following patch[1] and PR25961[2], which set force_output to 1 for static
functions at -O0, while it is 0 at -O2.

Do you have any comments on this?


Example code:

int cc = 333;
extern int aa;

__attribute__((noinline))
static void
foo(void)
{
  cc = aa;
}
int main(void)

{
  foo();
  return 0;
}

[1] https://gcc.gnu.org/legacy-ml/gcc-patches/2006-05/msg00315.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24561

Re: [PATCH][v3] Simple cobol.dg testsuite

[Richard Biener]

On Wed, 12 Mar 2025, Jakub Jelinek wrote:

> On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:
> > Earlier in this discussion of a testsuite, the question came up about
> > generating an error return in COBOL source code.
> > 
> > In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;".  When
> > executed in  the initial "top-level" program-id, it results in the value 1
> > being passed back to the _start stub.
> > 
> > "STOP RUN ERROR 1." is the equivalent of (and is in fact implemented with)
> > "exit(1)".
> 
> Note, in most of the testsuite we try to signal failure from a runtime
> testcase through calling abort (or e.g. fortran STOP N statement).
> On Linux at least when not cross-compiling, exit(1) (or this
> STOP RUN ERROR 1) will work as well, I believe the reason is for some
> bare metal targets which just don't propagate return value from main or
> exit back to the dejagnu testing framework.
> Does COBOL have something that is implemented as call to abort()?

For now, given the supported host/target limits I've verified that
STOP RUN ERROR 1. works.  I have now pushed the following.

Richard.

>From 1eefd65af8bcc0f8582967782eb4ee97f6775813 Mon Sep 17 00:00:00 2001
From: Richard Biener 
Date: Tue, 11 Mar 2025 09:39:06 +0100
Subject: [PATCH] Simple cobol.dg testsuite
To: gcc-patches@gcc.gnu.org

The following adds a simple cobol.dg test harness, based on gfortran.dg.
It's invoked by make check-cobol, has three tests, two execution test and
one test exercising dg-error.  The existing FAIL is due to an assembling
error, tracked by PR119214.

Running /home/rguenther/src/gcc/gcc/testsuite/cobol.dg/dg.exp ...
FAIL: cobol.dg/pass.cob   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops 
-ftracer -finline-functions  (test for excess errors)
FAIL: cobol.dg/fail.cob   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops 
-ftracer -finline-functions  (test for excess errors)

=== cobol Summary ===

 # of expected passes12
 # of unexpected failures1
 # of unresolved testcases   1

gcc/cobol/
* Make-lang.in (lang_checks): Add check-cobol.

gcc/testsuite/
* lib/cobol-dg.exp: New, based on gfortran-dg.exp.
* lib/cobol.exp: New, based on gfortran.exp.
* cobol.dg/dg.exp: New.
* cobol.dg/pass.cob: New test.
* cobol.dg/fail.cob: Likewise.
* cobol.dg/error-1.cob: Likewise.
---
 gcc/cobol/Make-lang.in |   2 +
 gcc/testsuite/cobol.dg/dg.exp  |  41 
 gcc/testsuite/cobol.dg/error-1.cob |   9 +
 gcc/testsuite/cobol.dg/fail.cob|   6 +
 gcc/testsuite/cobol.dg/pass.cob|   6 +
 gcc/testsuite/lib/cobol-dg.exp |  85 +
 gcc/testsuite/lib/cobol.exp| 291 +
 7 files changed, 440 insertions(+)
 create mode 100644 gcc/testsuite/cobol.dg/dg.exp
 create mode 100644 gcc/testsuite/cobol.dg/error-1.cob
 create mode 100644 gcc/testsuite/cobol.dg/fail.cob
 create mode 100644 gcc/testsuite/cobol.dg/pass.cob
 create mode 100644 gcc/testsuite/lib/cobol-dg.exp
 create mode 100644 gcc/testsuite/lib/cobol.exp

diff --git a/gcc/cobol/Make-lang.in b/gcc/cobol/Make-lang.in
index a4e005ac2bd..cbb31d63c30 100644
--- a/gcc/cobol/Make-lang.in
+++ b/gcc/cobol/Make-lang.in
@@ -367,3 +367,5 @@ cobol.stagefeedback: stagefeedback-start
-mv cobol/*$(objext) stagefeedback/cobol
 
 selftest-cobol:
+
+lang_checks += check-cobol
diff --git a/gcc/testsuite/cobol.dg/dg.exp b/gcc/testsuite/cobol.dg/dg.exp
new file mode 100644
index 000..c81634ac817
--- /dev/null
+++ b/gcc/testsuite/cobol.dg/dg.exp
@@ -0,0 +1,41 @@
+#   Copyright (C) 2004-2025 Free Software Foundation, Inc.
+
+# This program 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 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# GCC testsuite that uses the `dg.exp' driver.
+
+# Load support procs.
+load_lib cobol-dg.exp
+
+# If a testcase doesn't have special options, use these.
+global DEFAULT_COBFLAGS
+if ![info exists DEFAULT_COBFLAGS] then {
+set DEFAULT_COBFLAGS " "
+}
+
+# Initialize `dg'.
+dg-init
+
+global cobol_test_path
+set cobol_test_path $srcdir/$subdir
+
+set all_flags $DEFAULT_COBFLAGS
+
+# Main loop.
+cobol-dg-runtest [lsort \
+   [glob -nocomplain $srcdir/$subdir/*.cob ] ] "" $all_flags
+
+# All done.
+dg-finish
diff --git a/gcc/testsuite/cobol.dg/error-1.cob 
b/gcc/testsuite/cobol.dg/error-1.cob
new file mode 100644
index 0

Re: [PATCH] libstdc++: Optimize basic_format_parse_context::__check_dynamic_spec_types

[Tomasz Kaminski]

On Wed, Mar 12, 2025 at 9:23 AM Jonathan Wakely  wrote:

> On Wed, 12 Mar 2025 at 07:59, Tomasz Kaminski  wrote:
> >
> >
> >
> > On Tue, Mar 11, 2025 at 11:46 PM Jonathan Wakely 
> wrote:
> >>
> >> This change makes the consteval function slightly faster to compile.
> >> Instead of keeping the counts in an array and looping over that array,
> >> we can just keep a sum of how many valid types are present, and check
> >> that it equals the total number of types in the pack. We can also avoid
> >> doing the check entirely for the common cases where the call comes from
> >> check_dynamic_spec_integer or check_dynamic_spec_string, because those
> >> always use valid lists of types.
> >>
> >> The diagnostic is slightly worse now, because there's only a single
> >> "invalid template argument types" string that appears in the output,
> >> where previously we had either "non-unique template argument type" or
> >> "disallowed template argument type" depending on the failure mode.
> >>
> >> Given that most users will never use this function directly, and
> >> probably won't use invalid types anyway, the inferior diagnostic seems
> >> acceptable.
> >>
> >> libstdc++-v3/ChangeLog:
> >>
> >> * include/std/format
> (basic_format_parse_context::__check_types):
> >> New variable template and partial specializations.
> >> (basic_format_parse_context::__check_dynamic_spec_types):
> >> Simplify for faster compilation.
> >> (basic_format_parse_context::check_dynamic_spec): Only use
> >> __check_dynamic_spec_types when __check_types is true. Use it as
> >> the condition for a constexpr if statement instead of as the
> >> initializer for a constexpr variable.
> >> (basic_format_parse_context::check_dynamic_spec_string): Use
> >> _CharT instead of char_type consistently.
> >> ---
> >>
> >> Tested x86_64-linux.
> >>
> >>  libstdc++-v3/include/std/format | 81 +++--
> >>  1 file changed, 47 insertions(+), 34 deletions(-)
> >>
> >> diff --git a/libstdc++-v3/include/std/format
> b/libstdc++-v3/include/std/format
> >> index 0d6cc7f6bef..6269cbb80e6 100644
> >> --- a/libstdc++-v3/include/std/format
> >> +++ b/libstdc++-v3/include/std/format
> >> @@ -305,41 +305,51 @@ namespace __format
> >>constexpr void
> >>check_dynamic_spec_string(size_t __id) noexcept
> >>{
> >> -   check_dynamic_spec basic_string_view<_CharT>>(__id);
> >> +   check_dynamic_spec basic_string_view<_CharT>>(__id);
> >>}
> >>
> >>  private:
> >> -  // Check the Mandates: condition for check_dynamic_spec(n)
> >> +  template
> >> +   static constexpr bool __once = (is_same_v<_Tp, _Ts> + ...) == 1;
> >> +
> >> +  // True if we need to call __check_dynamic_spec_types for the
> pack Ts
> >> +  template
> >> +   static constexpr bool __check_types = sizeof...(_Ts) > 0;
> >> +  // The pack used by check_dynamic_spec_integral is valid, don't
> check it.
> >> +  // FIXME: simplify these when PR c++/85282 is supported.
> >> +  template
> >> +   static constexpr bool
> >> +   __check_types<_Tp, unsigned, long long, unsigned long long>
> >> + = ! is_same_v<_Tp, int>;
> >
> > These seem to produce wrong answer (false) if the user called
> check_dynamic_spec, unsigned, long long, unsigned
> long long>,
> > which is a valid set of types.
>
> The variable template __check_types means "do we need to check the
> types", so false is the correct answer here. We do not need to check
> the types for this list of types, because we know it's a valid set of
> types.
>
> The variable template is used to decide whether to call
> __check_dynamic_spec_types or to skip calling it.
>
Any particular reason to use this as a solution, as compared to
alternatives with implementation defined function?
I find the latter much more understandable, and while this allows us to
avoid checking if user specified types in exactly same order,
passing  to check_dynamic_spec will still perform
checking.

>
> >>
> >> +  // The pack used by check_dynamic_spec_string is valid, don't
> check it.
> >> +  template
> >> +   static constexpr bool
> >> +   __check_types<_Tp, basic_string_view<_CharT>>
> >> + = ! is_same_v;
> >
> > As above check_dynamic_spec>.
> > I think much batter solution would be to have
> __check_dynamic_spec private function,
> > that would not perform the check at all and will be called without
> checking from check_dynamic_spec_integrral, e.t.c.
> > And in check_dynamic_spec, we would do
> __check_dynamic_spec_types<_Ts...>() and sizeof..(Ts) > 0, before
> > calling __check_dynamic_spec.
>
> Yes I considered that, and that would also work.
>
> >> +
> >> +  // Check the Mandates: conditions for
> check_dynamic_spec(n)
> >>template
> >> static consteval bool
> >> __check_dynamic_spec_types()
> >> {
> >> - if constexpr (sizeof...(_Ts))

Re: [PATCH] tree.def: Improve RAW_DATA_CST documentation

[Richard Biener]

On Wed, 12 Mar 2025, Jakub Jelinek wrote:

> Hi!
> 
> In PR117262 David was asking for better documentation of RAW_DATA_CST
> and in the review of the PR119076 patch Jason was asking for that as well.
> 
> Here is an attempt to do so.
> 
> Ok for trunk?

OK.

Richard.

> 2025-03-12  Jakub Jelinek  
> 
>   * tree.def (RAW_DATA_CST): Document meaning of NULL RAW_DATA_OWNER.
>   (CONSTRUCTOR): Document meaning of RAW_DATA_CST used as element
>   value.
> 
> --- gcc/tree.def.jj   2025-01-15 08:43:39.818915636 +0100
> +++ gcc/tree.def  2025-03-12 08:11:24.230196310 +0100
> @@ -313,7 +313,9 @@ DEFTREECODE (STRING_CST, "string_cst", t
> of the raw data, plus RAW_DATA_OWNER for owner of the
> data.  That can be either a STRING_CST, used e.g. when writing
> PCH header, or another RAW_DATA_CST representing data owned by
> -   libcpp and representing the original range (if possible).
> +   libcpp and representing the original range (if possible)
> +   or NULL_TREE if it is the RAW_DATA_OWNER of other RAW_DATA_CST
> +   nodes (and represents data owned by libcpp).
> TREE_TYPE is the type of each of the RAW_DATA_LENGTH elements.  */
>  DEFTREECODE (RAW_DATA_CST, "raw_data_cst", tcc_constant, 0)
>  
> @@ -505,6 +507,14 @@ DEFTREECODE (OBJ_TYPE_REF, "obj_type_ref
> one for each index in the range.  (If the corresponding field VALUE
> has side-effects, they are evaluated once for each element.  Wrap the
> value in a SAVE_EXPR if you want to evaluate side effects only once.)
> +   If the index is INTEGER_CST or NULL_TREE and value RAW_DATA_CST, it is
> +   a short-hand for RAW_DATA_LENGTH consecutive nodes, first at the given
> +   index or current location, each node being
> +   build_int_cst (TREE_TYPE (value), TYPE_UNSIGNED (TREE_TYPE (value))
> +   ? (HOST_WIDE_INT) RAW_DATA_UCHAR_ELT (value, n)
> +   : (HOST_WIDE_INT) RAW_DATA_SCHAR_ELT (value, n)) at index
> +   tree_to_uhwi (index) + n (or current location + n) for n from 0 to
> +   RAW_DATA_LENGTH (value) - 1.
>  
> Components that aren't present are cleared as per the C semantics,
> unless the CONSTRUCTOR_NO_CLEARING flag is set, in which case their
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

Re: [PATCH 1/6] [RFC] c: Add front-end hook for related vector type.

[Richard Biener]

On Wed, 12 Mar 2025, Tejas Belagod wrote:

> On 3/10/25 7:21 PM, Richard Biener wrote:
> > On Sat, 8 Mar 2025, Tejas Belagod wrote:
> > 
> >> On 3/8/25 12:55 AM, Tejas Belagod wrote:
> >>> On 3/7/25 5:34 PM, Richard Biener wrote:
>  On Fri, 7 Mar 2025, Tejas Belagod wrote:
> 
> > On 3/7/25 4:38 PM, Richard Biener wrote:
> >> On Fri, 7 Mar 2025, Tejas Belagod wrote:
> >>
> >>> Given a vector mode and its corresponding element mode, this new new
> >>> language
> >>> hook returns a vector type that has properties of the vector mode and
> >>> element
> >>> type of that of the element mode.  For eg. on AArch64, given VNx16BI
> >>> and
> >>> QImode
> >>> it returns VNx16QI i.e. the wider mode to BImode that is an SVE mode.
> >>
> >> What's the rationale for this to be a new frontend hook?  It seems
> >> to be a composition of a target hook (related_mode) and a
> >> frontend hook (type_for_mode).
> >
> > I don't know this part of the FE very well, so pardon if its wrong way
> > to
> > do
> > it.
> >
> > I was trying to find a generic way to determine a wider vtype for a
> > given
> > vmode in a language-agnostic way. It looks like lang hooks are the
> > generic
> > way
> > for the mid-end to communicate to the FE to determine types the FE seems
> > fit,
> > so I decided to make it a langhook.
> 
>  Who is supposed to call this hook and for what reason?  Why would the
>  frontend be involved here?
> 
> >>>
> >>> Ah, sorry, I should've mentioned. This hook is called in Patch 4/6 during
> >>> gimplification (gimplify_compound_lval) that implements the subscript
> >>> operator for svbool_t - this hook returns a 'container' type for an n-bit
> >>> boolean type which in this case is a byte vector for the 1- bit svbool_t
> >>> vector. I involve the FE here in the same principle as for eg.
> >>> TYPE_FOR_SIZE
> >>> as the FE is best-placed to return the right 'container' type as defined
> >>> by
> >>> the language. The type returned by the FE is used to unpack svbool_t to
> >>> its
> >>> container vector type to implement the subscript operator.
> >>>
> > And how can it survive without
> >> a default implementation?
> >>
> >
> > I saw a comment in langhooks-def.h that says:
> >
> > /* Types hooks.  There are no reasonable defaults for most of them,
> >      so we create a compile-time error instead.  */
> >
> > So I assumed it was OK to have a NULL default which presumably fails at
> > build
> > time when a hook is not defined for a language. Is there a more graceful
> > way
> > to remedy this?
> 
>  Well, you made the default a NULL pointer - what do you do at the use
>  point of the hook when it's not defined?
> 
> >>>
> >>> True. I saw some of the other type hooks had NULL, so AIUI, I imagined it
> >>> could be NULL and it would crash when used for a FE that didn't implement
> >>> it. I admit I'm not even sure if this is the right way to do this.
> >>>
> >>> So, before I embarked on a 'default' implementation (which I'm not fully
> >>> sure how to do) my main intention was to clarify (via this RFC) if the
> >>> langhook approach was indeed the best way for gimple to obtain the related
> >>> vtype it needed for the vbool type it was unpacking to do the subscript
> >>> operation on?
> >>>
> >>
> >> Thinking about this a bit more, I realize my mistake - I've made this a
> >> langhook only for the purpose of gimplify to communicate to the FE to call
> >> c_common_related_vtype_for_mode (). I think I need to go back to the
> >> drawing
> >> board on this one - I'm not so convinced now that this is actually serving
> >> a
> >> new langhook need.
> >>
> >> If this new 'hook' is just a wrapper for targetm.vectorize.related_mode ()
> >> and
> >> type_for_mode () I can probably just call them directly during gimplify or
> >> c-common.cc instead of inventing this new hook.
> > 
> > That was my thinking.  The alternative is to (pre-)gimplify this either
> > during genericization or in the already existing gimplify_expr
> > langhook.  Or perform the "decay" as part of GENERIC building.
> > 
> 
> When I tried to decay svbool to char[] during genericization, it is quite
> straighforward for svbool[] reads, but for writes I need to introduce a
> temporary (because VEC_CONVERT IFN can't be an lvalue) and I don't know if
> Generic is too early to allow for introducing temporaries.

You might be doing the lvalues wrong then?  For _Bool b = int the
frontend converts the int to _Bool, it doesn't decay _Bool to a
int "lvalue".  So I'd expect the frontend, for svbool b = x to
have the 'x' possibly decayed as char[] and a conversion
via VEC_CONVERT inserted?

> If I leave the decay too late till gimplification of the base expression of
> svbool happens in gimplify_compound_lval (), it becomes a bit tedious to
> rewrite parent nodes w

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

[Li, Pan2]

> I'm not opposed to refactoring but what's the reason for it?  We have a large 
> number of similar tests that also include all possible types.  And aren't all 
> the tests you touch FAILing anyway right now?  (Due to the combine change...)

Yes, the cond_widen_complicate-3 need some tweak for the asm check failure.
Simply adjust the count cannot guarantee that each type has generated at least
one vw/vfw. For example, i8 doesn't generate vw but i16 generate 2 vw insn,
and the final asm check times is the same.

Thus, I refactor them into different types to meet current behavior.

Pan

-Original Message-
From: Robin Dapp  
Sent: Wednesday, March 12, 2025 7:11 PM
To: Li, Pan2 ; 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

> From: Pan Li 
>
> Rearrange the test cases of cond_widen_complicate-3 by different types
> into different files, instead of put all types together.  Then we can
> easily reduce the range when asm check fails.

I'm not opposed to refactoring but what's the reason for it?  We have a large 
number of similar tests that also include all possible types.  And aren't all 
the tests you touch FAILing anyway right now?  (Due to the combine change...)

-- 
Regards
 Robin

[COMMITTED] Regenerate cobol/lang.opt.urls

[Mark Wielaard]

With the COBOL: Frontend (commit 3c5ed996a) came a lang.opt.urls,
which is different from what regenerate-opt-urls.py generates. Make
the CI bot happy by regenerating it.

Longer term, the COBOL docs need to be sorted out (see e.g. PR119227)
and then perhaps regenerate-opt-urls.py adjusted so that it can deal
with the COBOL docs.

gcc/cobol/ChangeLog:

* lang.opt.urls: Regenerated.
---
 gcc/cobol/lang.opt.urls | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/gcc/cobol/lang.opt.urls b/gcc/cobol/lang.opt.urls
index a0e1f1944fe3..6a5dc1c0f580 100644
--- a/gcc/cobol/lang.opt.urls
+++ b/gcc/cobol/lang.opt.urls
@@ -10,20 +10,27 @@ UrlSuffix(gcc/Preprocessor-Options.html#index-D-1)
 I
 UrlSuffix(gcc/Directory-Options.html#index-I) 
LangUrlSuffix_D(gdc/Directory-Options.html#index-I)
 
+ffixed-form
+LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-ffixed-form)
+
 fsyntax-only
-UrlSuffix(gcc/Warning-Options.html#index-fsyntax-only) 
LangUrlSuffix_D(gdc/Warnings.html#index-fno-syntax-only)
+UrlSuffix(gcc/Warning-Options.html#index-fsyntax-only) 
LangUrlSuffix_D(gdc/Warnings.html#index-fno-syntax-only) 
LangUrlSuffix_Fortran(gfortran/Error-and-Warning-Options.html#index-fsyntax-only)
+
+ffree-form
+LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-ffree-form)
 
 fmax-errors
 UrlSuffix(gcc/Warning-Options.html#index-fmax-errors) 
LangUrlSuffix_D(gdc/Warnings.html#index-fmax-errors)
 
 iprefix
-UrlSuffix(gcc/Directory-Options.html#index-iprefix) 
LangUrlSuffix_D(gdc/Directory-Options.html#index-iprefix)
+UrlSuffix(gcc/Directory-Options.html#index-iprefix) 
LangUrlSuffix_D(gdc/Directory-Options.html#index-iprefix) 
LangUrlSuffix_Fortran(gfortran/Preprocessing-Options.html#index-iprefix)
 
 include
 UrlSuffix(gcc/Preprocessor-Options.html#index-include)
 
 isysroot
-UrlSuffix(gcc/Directory-Options.html#index-isysroot)
+UrlSuffix(gcc/Directory-Options.html#index-isysroot) 
LangUrlSuffix_Fortran(gfortran/Preprocessing-Options.html#index-isysroot)
 
 isystem
-UrlSuffix(gcc/Directory-Options.html#index-isystem)
+UrlSuffix(gcc/Directory-Options.html#index-isystem) 
LangUrlSuffix_Fortran(gfortran/Preprocessing-Options.html#index-isystem)
+
-- 
2.48.1

[PATCH v2] libstdc++: Optimize basic_format_parse_context::check_dynamic_spec

[Jonathan Wakely]

On 12/03/25 09:33 +0100, Tomasz Kaminski wrote:

On Wed, Mar 12, 2025 at 9:23 AM Jonathan Wakely  wrote:


On Wed, 12 Mar 2025 at 07:59, Tomasz Kaminski  wrote:
>
>
>
> On Tue, Mar 11, 2025 at 11:46 PM Jonathan Wakely 
wrote:
>>
>> This change makes the consteval function slightly faster to compile.
>> Instead of keeping the counts in an array and looping over that array,
>> we can just keep a sum of how many valid types are present, and check
>> that it equals the total number of types in the pack. We can also avoid
>> doing the check entirely for the common cases where the call comes from
>> check_dynamic_spec_integer or check_dynamic_spec_string, because those
>> always use valid lists of types.
>>
>> The diagnostic is slightly worse now, because there's only a single
>> "invalid template argument types" string that appears in the output,
>> where previously we had either "non-unique template argument type" or
>> "disallowed template argument type" depending on the failure mode.
>>
>> Given that most users will never use this function directly, and
>> probably won't use invalid types anyway, the inferior diagnostic seems
>> acceptable.
>>
>> libstdc++-v3/ChangeLog:
>>
>> * include/std/format
(basic_format_parse_context::__check_types):
>> New variable template and partial specializations.
>> (basic_format_parse_context::__check_dynamic_spec_types):
>> Simplify for faster compilation.
>> (basic_format_parse_context::check_dynamic_spec): Only use
>> __check_dynamic_spec_types when __check_types is true. Use it as
>> the condition for a constexpr if statement instead of as the
>> initializer for a constexpr variable.
>> (basic_format_parse_context::check_dynamic_spec_string): Use
>> _CharT instead of char_type consistently.
>> ---
>>
>> Tested x86_64-linux.
>>
>>  libstdc++-v3/include/std/format | 81 +++--
>>  1 file changed, 47 insertions(+), 34 deletions(-)
>>
>> diff --git a/libstdc++-v3/include/std/format
b/libstdc++-v3/include/std/format
>> index 0d6cc7f6bef..6269cbb80e6 100644
>> --- a/libstdc++-v3/include/std/format
>> +++ b/libstdc++-v3/include/std/format
>> @@ -305,41 +305,51 @@ namespace __format
>>constexpr void
>>check_dynamic_spec_string(size_t __id) noexcept
>>{
>> -   check_dynamic_spec>(__id);
>> +   check_dynamic_spec>(__id);
>>}
>>
>>  private:
>> -  // Check the Mandates: condition for check_dynamic_spec(n)
>> +  template
>> +   static constexpr bool __once = (is_same_v<_Tp, _Ts> + ...) == 1;
>> +
>> +  // True if we need to call __check_dynamic_spec_types for the
pack Ts
>> +  template
>> +   static constexpr bool __check_types = sizeof...(_Ts) > 0;
>> +  // The pack used by check_dynamic_spec_integral is valid, don't
check it.
>> +  // FIXME: simplify these when PR c++/85282 is supported.
>> +  template
>> +   static constexpr bool
>> +   __check_types<_Tp, unsigned, long long, unsigned long long>
>> + = ! is_same_v<_Tp, int>;
>
> These seem to produce wrong answer (false) if the user called
check_dynamic_spec, unsigned, long long, unsigned
long long>,
> which is a valid set of types.

The variable template __check_types means "do we need to check the
types", so false is the correct answer here. We do not need to check
the types for this list of types, because we know it's a valid set of
types.

The variable template is used to decide whether to call
__check_dynamic_spec_types or to skip calling it.


Any particular reason to use this as a solution, as compared to
alternatives with implementation defined function?
I find the latter much more understandable, and while this allows us to
avoid checking if user specified types in exactly same order,
passing  to check_dynamic_spec will still perform
checking.


No particular reason, no.

Here's a patch implementing the alternative approach, which does seem
cleaner.

This passes std/format/* tests, I'm running the full testsuite now.


commit 7e407b33b0799717cf13a8ca0e4ceb8490457f97
Author: Jonathan Wakely 
AuthorDate: Sat Mar 8 12:07:40 2025
Commit: Jonathan Wakely 
CommitDate: Wed Mar 12 09:36:28 2025

libstdc++: Optimize basic_format_parse_context::check_dynamic_spec

This change makes the check_dynamic_spec precondition checks slightly
faster to compile, and avoids those checks entirely for the common cases
of calling check_dynamic_spec_integer or check_dynamic_spec_string.

Instead of checking for unique types by keeping counts in an array and
looping over that array, we can just keep a sum of how many valid types
are present, and check that it equals the total number of types in the
pack.

The diagnostic is slightly worse now, because there's only a single
"invalid template argument types" string that appears in the output,
where previously we had either "non-unique templ

Re: [PATCH] contrib/gcc-changelog: Accept only [PRnnnn] in subject

[Richard Biener]

On Tue, Mar 11, 2025 at 5:58 PM Christophe Lyon
 wrote:
>
> In https://gcc.gnu.org/contribute.html#patches we ask to use [PR]
> without the Bugzilla component identifier and with no space between
> 'PR' and the number, but git_check_commit.py accepts all forms.  The
> patch enforces what we document.
>
> Note that this would reject a few of the recent commits.

Why would we be this restrictive?  I personally am using

bugzilla-component/number - description

IMO 'PR' is redundant and the component helps screening for area of
maintenance.

That said, I suppose my form wouldn't be rejected, so I'm happy.  I just
wonder why we should force something I don't remember we discussed
at any point.

Richard.

> contrib/ChangeLog:
>
> * gcc-changelog/git_commit.py (subject_pr_regex): Rename into
> subject_pr_component_regex.
> (subject_pr_space_regex): New.
> (subject_pr_paren_regex): New.
> (subject_pr2_regex): Remove matching parentheses and rename into
> subject_pr_regex.
> (GitCommit): Add checks for new regexps.
> ---
>  contrib/gcc-changelog/git_commit.py | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/contrib/gcc-changelog/git_commit.py 
> b/contrib/gcc-changelog/git_commit.py
> index 5c0596c2627..245c8496553 100755
> --- a/contrib/gcc-changelog/git_commit.py
> +++ b/contrib/gcc-changelog/git_commit.py
> @@ -167,8 +167,10 @@ author_line_regex = \
>  re.compile(r'^(?P\d{4}-\d{2}-\d{2})\ {2}(?P.*  
> <.*>)')
>  additional_author_regex = re.compile(r'^\t(?P\ *)?(?P.*  
> <.*>)')
>  changelog_regex = re.compile(r'^(?:[fF]or +)?([a-z0-9+-/]*)ChangeLog:?')
> -subject_pr_regex = 
> re.compile(r'(^|\W)PR\s+(?P[a-zA-Z0-9+-]+)/(?P\d{4,7})')
> -subject_pr2_regex = re.compile(r'[(\[]PR\s*(?P\d{4,7})[)\]]')
> +subject_pr_regex = re.compile(r'\[PR(?P\d{4,7})\]')# 
> [PR]
> +subject_pr_space_regex = re.compile(r'\[PR\s+(?P\d{4,7})\]')   # 
> [PR ]
> +subject_pr_paren_regex = re.compile(r'\(PR\s*(?P\d{4,7})\)')   # 
> (PR) / (PR )
> +subject_pr_component_regex = 
> re.compile(r'(^|\W)PR\s*(?P[a-zA-Z0-9+-]+)/(?P\d{4,7})') # 
> PRcomponent/ or PR component/
>  pr_regex = re.compile(r'\tPR (?P[a-z0-9+-]+\/)?(?P[0-9]+)$')
>  dr_regex = re.compile(r'\tDR ([0-9]+)$')
>  star_prefix_regex = re.compile(r'\t\*(?P\ *)(?P.*)')
> @@ -346,13 +348,15 @@ class GitCommit:
>  self.check_commit_email()
>
>  # Extract PR numbers form the subject line
> -# Match either [PR] / (PR) or PR component/
> +# Reject [PR ] / (PR ) or PR component/
>  if self.info.lines and not self.revert_commit:
> -self.subject_prs = {m.group('pr') for m in 
> subject_pr2_regex.finditer(info.lines[0])}
> -for m in subject_pr_regex.finditer(info.lines[0]):
> -if not m.group('component') in bug_components:
> -self.errors.append(Error('invalid PR component in 
> subject', info.lines[0]))
> -self.subject_prs.add(m.group('pr'))
> +self.subject_prs = {m.group('pr') for m in 
> subject_pr_regex.finditer(info.lines[0])}
> +for m in subject_pr_space_regex.finditer(info.lines[0]):
> +self.errors.append(Error('Use [PRnnn] in subject, not [PR 
> nnn]', info.lines[0]))
> +for m in subject_pr_paren_regex.finditer(info.lines[0]):
> +self.errors.append(Error('Use [PRnnn] in subject, not 
> (PRnnn)', info.lines[0]))
> +for m in subject_pr_component_regex.finditer(info.lines[0]):
> +self.errors.append(Error('Do not use PR component in 
> subject', info.lines[0]))
>
>  # Allow complete deletion of ChangeLog files in a commit
>  project_files = [f for f in self.info.modified_files
> --
> 2.34.1
>

[PATCH] cobol: Remove unnecesssary CPPFLAGS update and restore MacOS build

[Simon Martin]

The build currently fails on MacOS even when the Cobol front-end and
libgcobol builds are disabled.

The problem is that gcc/cobol/Make-lang.in adds -Iinclude to CPPFLAGS,
which somehow makes clang unhappy about the include order:
  error:  tried including  but didn't find libc++'s
   header. This usually means that your header search paths
  are not configured properly.

It turns out that this addition is unnecessary: simply removing it fixes
the build on MacOS, without impacting the build x86_64-pc-linux-gnu when
configured with --enable-languages=default,cobol.

It feels like there might be more cleanup opportunities there, but they
can be taken care of later.

OK for trunk?

gcc/cobol/ChangeLog:

* Make-lang.in: Remove unnecessary CPPFLAGS update.

---
 gcc/cobol/Make-lang.in | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/cobol/Make-lang.in b/gcc/cobol/Make-lang.in
index a4e005ac2bd..7888c116d70 100644
--- a/gcc/cobol/Make-lang.in
+++ b/gcc/cobol/Make-lang.in
@@ -56,7 +56,6 @@ LIB_SOURCE ?= $(srcdir)/../libgcobol
 #
 CPPFLAGS = \
  -std=c++14\
- -Iinclude \
  -I$(BINCLUDE) \
  -I$(LIB_INCLUDE)  \
  -DEXEC_LIB=\"$(prefix)/lib64\"\
-- 
2.44.0

[PATCH] LoongArch: Fix up [su]dot_prod*

[Jakub Jelinek]

On Fri, Feb 14, 2025 at 08:21:39PM +0800, Xi Ruoyao wrote:
> +(define_expand "dot_prod"
> +  [(match_operand: 0 "register_operand" "=f,f")
> +   (match_operand:IVEC 1 "register_operand" " f,f")
> +   (match_operand:IVEC 2 "register_operand" " f,f")
> +   (match_operand: 3 "reg_or_0_operand" " 0,YG")
> +   (any_extend (const_int 0))]
> +  ""
> +{
> +  auto [op0, op1, op2, op3] = operands;

GCC is written in C++14 these days and will be for a few years, we've
just switched from C++11 to C++14.
The above construct is C++17, so not appropriate in GCC sources
(at least not conditionalized on C++ version).
Furthermore, if it was added to help formatting, I think it still
didn't help much, the emit_insn (
on one line and argument on another is just ugly.  The problem
aren't the not so long operands[0] etc. arguments, but the too long
names of the gen_* functions.

> +
> +  if (op3 == CONST0_RTX (mode))
> +emit_insn (
> +  gen__vmulwev__ (op0, op1, op2));
> +  else
> +emit_insn (
> +  gen__vmaddwev__ (op0, op3, op1,
> +op2));
> +
> +  emit_insn (
> +gen__vmaddwod__ (op0, op0, op1, 
> op2));
> +  DONE;
> +})

So, I'd suggest following instead.

Tested by building a cross until cc1/cc1plus is built (I don't have binutils
built for the target around).

Ok for trunk?

2025-03-12  Jakub Jelinek  

PR target/119238
* config/loongarch/simd.md (dot_prod): Don't use
structured bindings.  Instead, use function pointers to improve
formatting.

--- gcc/config/loongarch/simd.md.jj 2025-03-05 06:39:50.198297885 +0100
+++ gcc/config/loongarch/simd.md2025-03-12 10:42:05.769933119 +0100
@@ -809,18 +809,21 @@ (define_expand "dot_prod<
(any_extend (const_int 0))]
   ""
 {
-  auto [op0, op1, op2, op3] = operands;
-
-  if (op3 == CONST0_RTX (mode))
-emit_insn (
-  gen__vmulwev__ (op0, op1, op2));
+  rtx (*gen4) (rtx, rtx, rtx, rtx);
+  if (operands[3] == CONST0_RTX (mode))
+{
+  rtx (*gen3) (rtx, rtx, rtx)
+   = gen__vmulwev__;
+  emit_insn (gen3 (operands[0], operands[1], operands[2]));
+}
   else
-emit_insn (
-  gen__vmaddwev__ (op0, op3, op1,
-  op2));
+{
+  gen4 = gen__vmaddwev__;
+  emit_insn (gen4 (operands[0], operands[1], operands[2], operands[3]));
+}
 
-  emit_insn (
-gen__vmaddwod__ (op0, op0, op1, op2));
+  gen4 = gen__vmaddwod__;
+  emit_insn (gen4 (operands[0], operands[1], operands[2], operands[3]));
   DONE;
 })
 


Jakub

Re: [PATCH] libstdc++: Prevent dangling references in std::unique_ptr::operator*

[Jonathan Wakely]

On Wed, 12 Mar 2025 at 07:38, Tomasz Kaminski  wrote:
>
>
>
> On Tue, Mar 11, 2025 at 10:26 PM Jonathan Wakely  wrote:
>>
>> LWG 4148 (approved in Wrocław, November 2024) makes it ill-formed to
>> dereference a std::unique_ptr if that would return a dangling reference.
>>
>> That can happen with a custom pointer type and a const-qualified
>> element_type, such that std::add_lvalue_reference_t is a
>> reference-to-const that could bind to a short-lived temporary.
>>
>> libstdc++-v3/ChangeLog:
>>
>> * include/bits/unique_ptr.h (unique_ptr::operator*): Add
>> static_assert to check for dangling reference, as per LWG 4148.
>> * testsuite/20_util/unique_ptr/lwg4148.cc: New test.
>> ---
>>
>> Tested x86_64-linux.
>
> LGTM.
> In C++26 binding reference to temporary in the return is ill-formed per 
> language rules,
> but it's good QoI to raise these errors in eariel standards.

Yes, the new test expects a -Wreturn-local-addr warning for <= C++23
and an error for C++26, but I think having the static_assert
consistently is good.

Especially because the C++26 error can be disabled by -Wno-return-local-addr
With the static_assert, unique_ptr::operator* will still be ill-formed
even if the required compiler diagnostic has been disabled.

>>
>>
>>  libstdc++-v3/include/bits/unique_ptr.h|  8 +
>>  .../testsuite/20_util/unique_ptr/lwg4148.cc   | 31 +++
>>  2 files changed, 39 insertions(+)
>>  create mode 100644 libstdc++-v3/testsuite/20_util/unique_ptr/lwg4148.cc
>>
>> diff --git a/libstdc++-v3/include/bits/unique_ptr.h 
>> b/libstdc++-v3/include/bits/unique_ptr.h
>> index 746989dfe47..6ae46a93800 100644
>> --- a/libstdc++-v3/include/bits/unique_ptr.h
>> +++ b/libstdc++-v3/include/bits/unique_ptr.h
>> @@ -445,6 +445,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>typename add_lvalue_reference::type
>>operator*() const noexcept(noexcept(*std::declval()))
>>{
>> +#if _GLIBCXX_USE_BUILTIN_TRAIT(__reference_converts_from_temporary)
>> +   // _GLIBCXX_RESOLVE_LIB_DEFECTS
>> +   // 4148. unique_ptr::operator* should not allow dangling references
>> +   using _ResT = typename add_lvalue_reference::type;
>> +   using _DerefT = decltype(*get());
>> +   static_assert(!__reference_converts_from_temporary(_ResT, _DerefT),
>> + "operator* must not return a dangling reference");
>> +#endif
>> __glibcxx_assert(get() != pointer());
>> return *get();
>>}
>> diff --git a/libstdc++-v3/testsuite/20_util/unique_ptr/lwg4148.cc 
>> b/libstdc++-v3/testsuite/20_util/unique_ptr/lwg4148.cc
>> new file mode 100644
>> index 000..c70d7a60631
>> --- /dev/null
>> +++ b/libstdc++-v3/testsuite/20_util/unique_ptr/lwg4148.cc
>> @@ -0,0 +1,31 @@
>> +// { dg-do compile { target c++11 } }
>> +
>> +// LWG 4148. unique_ptr::operator* should not allow dangling references
>> +
>> +#include 
>> +
>> +struct pointer
>> +{
>> +  pointer() { }
>> +  pointer(std::nullptr_t) { }
>> +  int operator*() const { return 0; }
>> +  bool operator==(pointer) const { return true; }
>> +  bool operator==(std::nullptr_t) const { return false; }
>> +#ifndef __cpp_lib_three_way_comparison
>> +  bool operator!=(pointer) const { return false; }
>> +  bool operator!=(std::nullptr_t) const { return true; }
>> +#endif
>> +};
>> +
>> +struct Deleter
>> +{
>> +  using pointer = ::pointer;
>> +  void operator()(pointer) const { }
>> +};
>> +
>> +std::unique_ptr up;
>> +int i = *up; // { dg-error "here" }
>> +// { dg-error "dangling reference" "" { target *-*-* } 0 }
>> +
>> +// { dg-warning "returning reference to temporary" "" { target c++23_down } 
>> 0 }
>> +// { dg-error "returning reference to temporary" "" { target c++26 } 0 }
>> --
>> 2.48.1
>>

gcc-patches@gcc.gnu.org

[Jonathan Wakely]

>Could you add a test for functor that is only rvalue-callable (only
>operator() &&).
>There was discussion about this case on reflector, so I think it would be
>good to document that they are not supported.

Like this?



LWG 4154 (approved in Wrocław, November 2024) fixed the Mandates:
precondition for std::packaged_task::packaged_task(F&&) to match what
the implementation actually requires. We already gave a diagnostic in
the right cases as required by the issue resolution, so strictly
speaking we don't need to do anything. But the current diagnostic comes
from inside the implementation of std::__invoke_r and could be more
user-friendly.

For C++17 (when std::is_invocable_r_v is available) add a static_assert
to the constructor, so the error is clear:

.../include/c++/15.0.1/future: In instantiation of 
'std::packaged_task<_Res(_ArgTypes ...)>::packaged_task(_Fn&&) [with _Fn = 
const F&;  = void; _Res = void; _ArgTypes = {}]':
lwg4154_neg.cc:15:31:   required from here
   15 | std::packaged_task p(f); // { dg-error "here" "" { target c++17 
} }
  |   ^
.../include/c++/15.0.1/future:1575:25: error: static assertion failed
 1575 |   static_assert(is_invocable_r_v<_Res, decay_t<_Fn>&, 
_ArgTypes...>);
  | 
^~~

Also add a test to confirm we get a diagnostic as the standard requires.

libstdc++-v3/ChangeLog:

* include/std/future (packaged_task::packaged_task(F&&)): Add
static_assert.
* testsuite/30_threads/packaged_task/cons/dangling_ref.cc: Add
dg-error for new static assertion.
* testsuite/30_threads/packaged_task/cons/lwg4154_neg.cc: New
test.

---
 libstdc++-v3/include/std/future   |  9 -
 .../packaged_task/cons/dangling_ref.cc|  1 +
 .../packaged_task/cons/lwg4154_neg.cc | 38 +++
 3 files changed, 47 insertions(+), 1 deletion(-)
 create mode 100644 
libstdc++-v3/testsuite/30_threads/packaged_task/cons/lwg4154_neg.cc

diff --git a/libstdc++-v3/include/std/future b/libstdc++-v3/include/std/future
index 2a855f262a0..b7ab233b85f 100644
--- a/libstdc++-v3/include/std/future
+++ b/libstdc++-v3/include/std/future
@@ -1567,7 +1567,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
packaged_task(_Fn&& __fn)
: _M_state(
__create_task_state<_Res(_ArgTypes...)>(std::forward<_Fn>(__fn)))
-   { }
+   {
+#ifdef __cpp_lib_is_invocable // C++ >= 17
+ // _GLIBCXX_RESOLVE_LIB_DEFECTS
+ // 4154. The Mandates for std::packaged_task's constructor
+ // from a callable entity should consider decaying
+ static_assert(is_invocable_r_v<_Res, decay_t<_Fn>&, _ArgTypes...>);
+#endif
+   }
 
 #if __cplusplus < 201703L
   // _GLIBCXX_RESOLVE_LIB_DEFECTS
diff --git 
a/libstdc++-v3/testsuite/30_threads/packaged_task/cons/dangling_ref.cc 
b/libstdc++-v3/testsuite/30_threads/packaged_task/cons/dangling_ref.cc
index 225b65fe6a7..51c6ade91c3 100644
--- a/libstdc++-v3/testsuite/30_threads/packaged_task/cons/dangling_ref.cc
+++ b/libstdc++-v3/testsuite/30_threads/packaged_task/cons/dangling_ref.cc
@@ -10,3 +10,4 @@ std::packaged_task task(f);
 // { dg-error "reference to temporary" "" { target { c++14_down } } 0 }
 // { dg-error "no matching function" "" { target c++17 } 0 }
 // { dg-error "enable_if" "" { target c++17 } 0 }
+// { dg-error "static assertion failed" "" { target c++17 } 0 }
diff --git 
a/libstdc++-v3/testsuite/30_threads/packaged_task/cons/lwg4154_neg.cc 
b/libstdc++-v3/testsuite/30_threads/packaged_task/cons/lwg4154_neg.cc
new file mode 100644
index 000..6ba1bb1a53e
--- /dev/null
+++ b/libstdc++-v3/testsuite/30_threads/packaged_task/cons/lwg4154_neg.cc
@@ -0,0 +1,38 @@
+// { dg-do compile { target c++11 } }
+
+// LWG 4154. The Mandates for std::packaged_task's constructor from
+// a callable entity should consider decaying
+
+#include 
+
+struct F {
+  void operator()() & = delete;
+  void operator()() const & { }
+};
+
+// Mandates: is_invocable_r_v&, ArgTypes...> is true.
+const F f;
+std::packaged_task p(f); // { dg-error "here" "" { target c++17 } }
+// { dg-error "static assertion failed" "" { target c++17 } 0 }
+// { dg-error "invoke_r" "" { target *-*-* } 0 }
+// { dg-prune-output "enable_if p2(Frv{}); // { dg-error "here" "" { target c++17 } 
}
+
+// Only callable as non-const lvalue
+struct Fnc {
+  void operator()() const & = delete;
+  void operator()() & { }
+};
+
+// In C++11/14/17/20 std::packaged_task::packaged_task(F&&) incorrectly
+// required that the callable passed to the constructor can be invoked.
+// If the type of the parameter is const F& we might not be able to invoke
+// the parameter, but that's OK because we store and invoke a non-const F.
+// So this should work without errors:
+const Fnc fnc;
+std::packaged_task p3(fnc);
-- 
2.48.1

Re: The COBOL front end -- The Initial Onslaught

[Mark Wielaard]

Hi,

On Wed, Mar 12, 2025 at 04:19:10AM +, Sam James wrote:
> Robert Dubner  writes:
> >
> > I need to be able to change, at the very least, the Assignment field.  I 
> > don't seem to have any way of doing that.
> 
> Make sure your email address on Bugzilla is x...@gcc.gnu.org. Using that
> address grants the account editbugs privileges.

And if you already have a different bugzilla account we can merge it
into your new x...@gcc.gnu.org one. Please sent email to
account-reque...@sourceware.org to do that.

Cheers,

Mark

Re: [PATCH v2] libstdc++: Optimize basic_format_parse_context::check_dynamic_spec

[Jonathan Wakely]

On Wed, 12 Mar 2025 at 10:47, Tomasz Kaminski  wrote:
>
>
>
> On Wed, Mar 12, 2025 at 11:06 AM Jonathan Wakely  wrote:
>>
>> On 12/03/25 09:33 +0100, Tomasz Kaminski wrote:
>> >On Wed, Mar 12, 2025 at 9:23 AM Jonathan Wakely  wrote:
>> >
>> >> On Wed, 12 Mar 2025 at 07:59, Tomasz Kaminski  wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Mar 11, 2025 at 11:46 PM Jonathan Wakely 
>> >> wrote:
>> >> >>
>> >> >> This change makes the consteval function slightly faster to compile.
>> >> >> Instead of keeping the counts in an array and looping over that array,
>> >> >> we can just keep a sum of how many valid types are present, and check
>> >> >> that it equals the total number of types in the pack. We can also avoid
>> >> >> doing the check entirely for the common cases where the call comes from
>> >> >> check_dynamic_spec_integer or check_dynamic_spec_string, because those
>> >> >> always use valid lists of types.
>> >> >>
>> >> >> The diagnostic is slightly worse now, because there's only a single
>> >> >> "invalid template argument types" string that appears in the output,
>> >> >> where previously we had either "non-unique template argument type" or
>> >> >> "disallowed template argument type" depending on the failure mode.
>> >> >>
>> >> >> Given that most users will never use this function directly, and
>> >> >> probably won't use invalid types anyway, the inferior diagnostic seems
>> >> >> acceptable.
>> >> >>
>> >> >> libstdc++-v3/ChangeLog:
>> >> >>
>> >> >> * include/std/format
>> >> (basic_format_parse_context::__check_types):
>> >> >> New variable template and partial specializations.
>> >> >> (basic_format_parse_context::__check_dynamic_spec_types):
>> >> >> Simplify for faster compilation.
>> >> >> (basic_format_parse_context::check_dynamic_spec): Only use
>> >> >> __check_dynamic_spec_types when __check_types is true. Use it 
>> >> >> as
>> >> >> the condition for a constexpr if statement instead of as the
>> >> >> initializer for a constexpr variable.
>> >> >> (basic_format_parse_context::check_dynamic_spec_string): Use
>> >> >> _CharT instead of char_type consistently.
>> >> >> ---
>> >> >>
>> >> >> Tested x86_64-linux.
>> >> >>
>> >> >>  libstdc++-v3/include/std/format | 81 +++--
>> >> >>  1 file changed, 47 insertions(+), 34 deletions(-)
>> >> >>
>> >> >> diff --git a/libstdc++-v3/include/std/format
>> >> b/libstdc++-v3/include/std/format
>> >> >> index 0d6cc7f6bef..6269cbb80e6 100644
>> >> >> --- a/libstdc++-v3/include/std/format
>> >> >> +++ b/libstdc++-v3/include/std/format
>> >> >> @@ -305,41 +305,51 @@ namespace __format
>> >> >>constexpr void
>> >> >>check_dynamic_spec_string(size_t __id) noexcept
>> >> >>{
>> >> >> -   check_dynamic_spec> >> basic_string_view<_CharT>>(__id);
>> >> >> +   check_dynamic_spec> >> basic_string_view<_CharT>>(__id);
>> >> >>}
>> >> >>
>> >> >>  private:
>> >> >> -  // Check the Mandates: condition for 
>> >> >> check_dynamic_spec(n)
>> >> >> +  template
>> >> >> +   static constexpr bool __once = (is_same_v<_Tp, _Ts> + ...) == 
>> >> >> 1;
>> >> >> +
>> >> >> +  // True if we need to call __check_dynamic_spec_types for the
>> >> pack Ts
>> >> >> +  template
>> >> >> +   static constexpr bool __check_types = sizeof...(_Ts) > 0;
>> >> >> +  // The pack used by check_dynamic_spec_integral is valid, don't
>> >> check it.
>> >> >> +  // FIXME: simplify these when PR c++/85282 is supported.
>> >> >> +  template
>> >> >> +   static constexpr bool
>> >> >> +   __check_types<_Tp, unsigned, long long, unsigned long long>
>> >> >> + = ! is_same_v<_Tp, int>;
>> >> >
>> >> > These seem to produce wrong answer (false) if the user called
>> >> check_dynamic_spec, unsigned, long long, 
>> >> unsigned
>> >> long long>,
>> >> > which is a valid set of types.
>> >>
>> >> The variable template __check_types means "do we need to check the
>> >> types", so false is the correct answer here. We do not need to check
>> >> the types for this list of types, because we know it's a valid set of
>> >> types.
>> >>
>> >> The variable template is used to decide whether to call
>> >> __check_dynamic_spec_types or to skip calling it.
>> >>
>> >Any particular reason to use this as a solution, as compared to
>> >alternatives with implementation defined function?
>> >I find the latter much more understandable, and while this allows us to
>> >avoid checking if user specified types in exactly same order,
>> >passing  to check_dynamic_spec will still perform
>> >checking.
>>
>> No particular reason, no.
>>
>> Here's a patch implementing the alternative approach, which does seem
>> cleaner.
>
> LGTM.
> Nice touch on making __check_dynamic_spec consteval, so it never get symbol 
> emitted.

I suppose we could even add [[__gnu__::__always_inline__]] to all
three of check_dynamic_spec, check_dynamic_sp

[PATCH] libstdc++: Update tzdata to 2025a

[Jonathan Wakely]

Import the new 2025a tzdata.zi file. The leapseconds file was also
updated to have a new expiry (no new leap seconds were added).

libstdc++-v3/ChangeLog:

* include/std/chrono (__detail::__get_leap_second_info): Update
expiry date for leap seconds list.
* src/c++20/tzdata.zi: Import new file from 2025a release.
* src/c++20/tzdb.cc (tzdb_list::_Node::_S_read_leap_seconds)
Update expiry date for leap seconds list.
---

Tested x86_64-linux.
This should be backported to the branches too, especially as the
previous leap second expiry date was 2024-12-28 so all uses of leap
seconds for recent times are calling into the library to check for an
updated list. If we update the expiry date in the  header then
that library call can be avoided, because the list of leap seconds in
the inline function is good until 2025-12-28.

 libstdc++-v3/include/std/chrono  |2 +-
 libstdc++-v3/src/c++20/tzdata.zi | 1682 +++---
 libstdc++-v3/src/c++20/tzdb.cc   |4 +-
 3 files changed, 840 insertions(+), 848 deletions(-)

diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono
index 095a35e5b75..8eb9fd9baac 100644
--- a/libstdc++-v3/include/std/chrono
+++ b/libstdc++-v3/include/std/chrono
@@ -3260,7 +3260,7 @@ namespace __detail
   };
   // The list above is known to be valid until (at least) this date
   // and only contains positive leap seconds.
-  const sys_seconds __expires(1735344000s); // 2024-12-28 00:00:00 UTC
+  const sys_seconds __expires(176688s); // 2025-12-28 00:00:00 UTC
 
 #if _GLIBCXX_USE_CXX11_ABI || ! _GLIBCXX_USE_DUAL_ABI
   if (__ss > __expires)
diff --git a/libstdc++-v3/src/c++20/tzdata.zi b/libstdc++-v3/src/c++20/tzdata.zi
index be1c4085920..db6ba4af2b0 100644
--- a/libstdc++-v3/src/c++20/tzdata.zi
+++ b/libstdc++-v3/src/c++20/tzdata.zi
@@ -1,4 +1,4 @@
-# version 2024a
+# version 2025a
 # This zic input file is in the public domain.
 R d 1916 o - Jun 14 23s 1 S
 R d 1916 1919 - O Su>=1 23s 0 -
@@ -721,12 +721,16 @@ R P 2085 o - Ap 21 2 0 -
 R P 2085 o - Jun 9 2 1 S
 R P 2086 o - Ap 13 2 0 -
 R P 2086 o - May 25 2 1 S
-R PH 1936 o - N 1 0 1 D
-R PH 1937 o - F 1 0 0 S
-R PH 1954 o - Ap 12 0 1 D
-R PH 1954 o - Jul 1 0 0 S
-R PH 1978 o - Mar 22 0 1 D
-R PH 1978 o - S 21 0 0 S
+R PH 1936 o - O 31 24 1 D
+R PH 1937 o - Ja 15 24 0 S
+R PH 1941 o - D 15 24 1 D
+R PH 1945 o - N 30 24 0 S
+R PH 1954 o - Ap 11 24 1 D
+R PH 1954 o - Jun 4 24 0 S
+R PH 1977 o - Mar 27 24 1 D
+R PH 1977 o - S 21 24 0 S
+R PH 1990 o - May 21 0 1 D
+R PH 1990 o - Jul 28 24 0 S
 R S 1920 1923 - Ap Su>=15 2 1 S
 R S 1920 1923 - O Su>=1 2 0 -
 R S 1962 o - Ap 29 2 1 S
@@ -1324,14 +1328,10 @@ R O 1961 1964 - May lastSu 1s 1 S
 R O 1962 1964 - S lastSu 1s 0 -
 R p 1916 o - Jun 17 23 1 S
 R p 1916 o - N 1 1 0 -
-R p 1917 o - F 28 23s 1 S
-R p 1917 1921 - O 14 23s 0 -
-R p 1918 o - Mar 1 23s 1 S
-R p 1919 o - F 28 23s 1 S
-R p 1920 o - F 29 23s 1 S
-R p 1921 o - F 28 23s 1 S
+R p 1917 1921 - Mar 1 0 1 S
+R p 1917 1921 - O 14 24 0 -
 R p 1924 o - Ap 16 23s 1 S
-R p 1924 o - O 14 23s 0 -
+R p 1924 o - O 4 23s 0 -
 R p 1926 o - Ap 17 23s 1 S
 R p 1926 1929 - O Sa>=1 23s 0 -
 R p 1927 o - Ap 9 23s 1 S
@@ -1349,8 +1349,9 @@ R p 1938 o - Mar 26 23s 1 S
 R p 1939 o - Ap 15 23s 1 S
 R p 1939 o - N 18 23s 0 -
 R p 1940 o - F 24 23s 1 S
-R p 1940 1941 - O 5 23s 0 -
+R p 1940 o - O 7 23s 0 -
 R p 1941 o - Ap 5 23s 1 S
+R p 1941 o - O 5 23s 0 -
 R p 1942 1945 - Mar Sa>=8 23s 1 S
 R p 1942 o - Ap 25 22s 2 M
 R p 1942 o - Au 15 22s 1 S
@@ -1360,16 +1361,16 @@ R p 1943 1945 - Au Sa>=25 22s 1 S
 R p 1944 1945 - Ap Sa>=21 22s 2 M
 R p 1946 o - Ap Sa>=1 23s 1 S
 R p 1946 o - O Sa>=1 23s 0 -
-R p 1947 1965 - Ap Su>=1 2s 1 S
+R p 1947 1966 - Ap Su>=1 2s 1 S
 R p 1947 1965 - O Su>=1 2s 0 -
-R p 1977 o - Mar 27 0s 1 S
-R p 1977 o - S 25 0s 0 -
-R p 1978 1979 - Ap Su>=1 0s 1 S
-R p 1978 o - O 1 0s 0 -
-R p 1979 1982 - S lastSu 1s 0 -
-R p 1980 o - Mar lastSu 0s 1 S
-R p 1981 1982 - Mar lastSu 1s 1 S
-R p 1983 o - Mar lastSu 2s 1 S
+R p 1976 o - S lastSu 1 0 -
+R p 1977 o - Mar lastSu 0s 1 S
+R p 1977 o - S lastSu 0s 0 -
+R p 1978 1980 - Ap Su>=1 1s 1 S
+R p 1978 o - O 1 1s 0 -
+R p 1979 1980 - S lastSu 1s 0 -
+R p 1981 1986 - Mar lastSu 0s 1 S
+R p 1981 1985 - S lastSu 0s 0 -
 R z 1932 o - May 21 0s 1 S
 R z 1932 1939 - O Su>=1 0s 0 -
 R z 1933 1939 - Ap Su>=2 0s 1 S
@@ -1728,7 +1729,7 @@ R Y 1972 2006 - O lastSu 2 0 S
 R Y 1987 2006 - Ap Su>=1 2 1 D
 R Yu 1965 o - Ap lastSu 0 2 DD
 R Yu 1965 o - O lastSu 2 0 S
-R m 1931 o - May 1 23 1 D
+R m 1931 o - Ap 30 0 1 D
 R m 1931 o - O 1 0 0 S
 R m 1939 o - F 5 0 1 D
 R m 1939 o - Jun 25 0 0 S
@@ -2022,9 +2023,9 @@ R y 2002 2004 - Ap Su>=1 0 0 -
 R y 2002 2003 - S Su>=1 0 1 -
 R y 2004 2009 - O Su>=15 0 1 -
 R y 2005 2009 - Mar Su>=8 0 0 -
-R y 2010 ma - O Su>=1 0 1 -
+R y 2010 2024 - O Su>=1 0 1 -
 R y 2010 2012 - Ap Su>=8 0 0 -
-R y 2013 ma - Mar Su>=22 0 0 -
+R y 2013 2024 - Mar Su>=22 0 0 -
 R PE 1938 o - 

Re: [PATCH v2] libstdc++: Optimize basic_format_parse_context::check_dynamic_spec

[Tomasz Kaminski]

On Wed, Mar 12, 2025 at 11:06 AM Jonathan Wakely  wrote:

> On 12/03/25 09:33 +0100, Tomasz Kaminski wrote:
> >On Wed, Mar 12, 2025 at 9:23 AM Jonathan Wakely 
> wrote:
> >
> >> On Wed, 12 Mar 2025 at 07:59, Tomasz Kaminski 
> wrote:
> >> >
> >> >
> >> >
> >> > On Tue, Mar 11, 2025 at 11:46 PM Jonathan Wakely 
> >> wrote:
> >> >>
> >> >> This change makes the consteval function slightly faster to compile.
> >> >> Instead of keeping the counts in an array and looping over that
> array,
> >> >> we can just keep a sum of how many valid types are present, and check
> >> >> that it equals the total number of types in the pack. We can also
> avoid
> >> >> doing the check entirely for the common cases where the call comes
> from
> >> >> check_dynamic_spec_integer or check_dynamic_spec_string, because
> those
> >> >> always use valid lists of types.
> >> >>
> >> >> The diagnostic is slightly worse now, because there's only a single
> >> >> "invalid template argument types" string that appears in the output,
> >> >> where previously we had either "non-unique template argument type" or
> >> >> "disallowed template argument type" depending on the failure mode.
> >> >>
> >> >> Given that most users will never use this function directly, and
> >> >> probably won't use invalid types anyway, the inferior diagnostic
> seems
> >> >> acceptable.
> >> >>
> >> >> libstdc++-v3/ChangeLog:
> >> >>
> >> >> * include/std/format
> >> (basic_format_parse_context::__check_types):
> >> >> New variable template and partial specializations.
> >> >> (basic_format_parse_context::__check_dynamic_spec_types):
> >> >> Simplify for faster compilation.
> >> >> (basic_format_parse_context::check_dynamic_spec): Only use
> >> >> __check_dynamic_spec_types when __check_types is true. Use
> it as
> >> >> the condition for a constexpr if statement instead of as the
> >> >> initializer for a constexpr variable.
> >> >> (basic_format_parse_context::check_dynamic_spec_string): Use
> >> >> _CharT instead of char_type consistently.
> >> >> ---
> >> >>
> >> >> Tested x86_64-linux.
> >> >>
> >> >>  libstdc++-v3/include/std/format | 81
> +++--
> >> >>  1 file changed, 47 insertions(+), 34 deletions(-)
> >> >>
> >> >> diff --git a/libstdc++-v3/include/std/format
> >> b/libstdc++-v3/include/std/format
> >> >> index 0d6cc7f6bef..6269cbb80e6 100644
> >> >> --- a/libstdc++-v3/include/std/format
> >> >> +++ b/libstdc++-v3/include/std/format
> >> >> @@ -305,41 +305,51 @@ namespace __format
> >> >>constexpr void
> >> >>check_dynamic_spec_string(size_t __id) noexcept
> >> >>{
> >> >> -   check_dynamic_spec >> basic_string_view<_CharT>>(__id);
> >> >> +   check_dynamic_spec >> basic_string_view<_CharT>>(__id);
> >> >>}
> >> >>
> >> >>  private:
> >> >> -  // Check the Mandates: condition for
> check_dynamic_spec(n)
> >> >> +  template
> >> >> +   static constexpr bool __once = (is_same_v<_Tp, _Ts> + ...)
> == 1;
> >> >> +
> >> >> +  // True if we need to call __check_dynamic_spec_types for the
> >> pack Ts
> >> >> +  template
> >> >> +   static constexpr bool __check_types = sizeof...(_Ts) > 0;
> >> >> +  // The pack used by check_dynamic_spec_integral is valid,
> don't
> >> check it.
> >> >> +  // FIXME: simplify these when PR c++/85282 is supported.
> >> >> +  template
> >> >> +   static constexpr bool
> >> >> +   __check_types<_Tp, unsigned, long long, unsigned long long>
> >> >> + = ! is_same_v<_Tp, int>;
> >> >
> >> > These seem to produce wrong answer (false) if the user called
> >> check_dynamic_spec, unsigned, long long,
> unsigned
> >> long long>,
> >> > which is a valid set of types.
> >>
> >> The variable template __check_types means "do we need to check the
> >> types", so false is the correct answer here. We do not need to check
> >> the types for this list of types, because we know it's a valid set of
> >> types.
> >>
> >> The variable template is used to decide whether to call
> >> __check_dynamic_spec_types or to skip calling it.
> >>
> >Any particular reason to use this as a solution, as compared to
> >alternatives with implementation defined function?
> >I find the latter much more understandable, and while this allows us to
> >avoid checking if user specified types in exactly same order,
> >passing  to check_dynamic_spec will still perform
> >checking.
>
> No particular reason, no.
>
> Here's a patch implementing the alternative approach, which does seem
> cleaner.
>
LGTM.
Nice touch on making __check_dynamic_spec consteval, so it never get symbol
emitted.

>
> This passes std/format/* tests, I'm running the full testsuite now.
>
>
>

Re: The COBOL front end, version 3, now in 14 easy pieces

[Jakub Jelinek]

On Wed, Mar 12, 2025 at 12:09:44PM +0100, Mark Wielaard wrote:
> Hi David,
> 
> On Mon, Mar 10, 2025 at 05:40:18PM -0400, David Malcolm wrote:
> > FWIW gcc/cobol/lang.opt.urls has some D-specific things that look like
> > copy-and-paste cruft, but hopefully it won't cause problems.
> 
> And some Fortran stuff. The autoregen bot currently flags it with the
> following diff:
> 
> diff --git a/gcc/cobol/lang.opt.urls b/gcc/cobol/lang.opt.urls
> index a0e1f1944fe..6a5dc1c0f58 100644
> --- a/gcc/cobol/lang.opt.urls
> +++ b/gcc/cobol/lang.opt.urls
> @@ -10,20 +10,27 @@ UrlSuffix(gcc/Preprocessor-Options.html#index-D-1)
>  I
>  UrlSuffix(gcc/Directory-Options.html#index-I) 
> LangUrlSuffix_D(gdc/Directory-Options.html#index-I)
>  
> +ffixed-form
> +LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-ffixed-form)
> +
>  fsyntax-only
> -UrlSuffix(gcc/Warning-Options.html#index-fsyntax-only) 
> LangUrlSuffix_D(gdc/Warnings.html#index-fno-syntax-only)
> +UrlSuffix(gcc/Warning-Options.html#index-fsyntax-only) 
> LangUrlSuffix_D(gdc/Warnings.html#index-fno-syntax-only) 
> LangUrlSuffix_Fortran(gfortran/Error-and-Warning-Options.html#index-fsyntax-only)
> +
> +ffree-form
> +LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-ffree-form)
>  
>  fmax-errors
>  UrlSuffix(gcc/Warning-Options.html#index-fmax-errors) 
> LangUrlSuffix_D(gdc/Warnings.html#index-fmax-errors)
>  
>  iprefix
> -UrlSuffix(gcc/Directory-Options.html#index-iprefix) 
> LangUrlSuffix_D(gdc/Directory-Options.html#index-iprefix)
> +UrlSuffix(gcc/Directory-Options.html#index-iprefix) 
> LangUrlSuffix_D(gdc/Directory-Options.html#index-iprefix) 
> LangUrlSuffix_Fortran(gfortran/Preprocessing-Options.html#index-iprefix)
>  
>  include
>  UrlSuffix(gcc/Preprocessor-Options.html#index-include)
>  
>  isysroot
> -UrlSuffix(gcc/Directory-Options.html#index-isysroot)
> +UrlSuffix(gcc/Directory-Options.html#index-isysroot) 
> LangUrlSuffix_Fortran(gfortran/Preprocessing-Options.html#index-isysroot)
>  
>  isystem
> -UrlSuffix(gcc/Directory-Options.html#index-isystem)
> +UrlSuffix(gcc/Directory-Options.html#index-isystem) 
> LangUrlSuffix_Fortran(gfortran/Preprocessing-Options.html#index-isystem)
> +
> 
> I don't really understand what these D and Fortran references are
> for. Are these expected? Should we simply regenerate them with the
> above diff? Or does the make regenerate-opt-urls target need an
> update?

I'd commit this patch as is if it makes the CI bot happy.
Longer term, the COBOL docs need to be sorted out (see e.g. PR119227)
and then perhaps regenerate-opt-urls.py adjusted so that it can
deal with the COBOL docs.

Jakub

[committed] libphobos: Merge upstream phobos 0faae92d6

[Iain Buclaw]

Hi,

This patch merges the D standard library with upstream phobos 0faae92d6.

Synchronizing with the upstream release of v2.111.0-beta.1.

Phobos changes:

- Import phobos v2.111.0-beta.1.
- Added `bitCast' function to `std.conv'.
- Added `readfln' and `File.readfln' functions to `std.stdio'.
- New procedural API for `std.sumtype'.

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

Regards,
Iain.

---
libphobos/ChangeLog:

* src/MERGE: Merge upstream phobos 0faae92d6.
* testsuite/libphobos.phobos/std_array.d: Regenerate.
* testsuite/libphobos.phobos/std_conv.d: Regenerate.
* testsuite/libphobos.phobos/std_functional.d: Regenerate.
* testsuite/libphobos.phobos/std_sumtype.d: Regenerate.
---
 libphobos/src/MERGE   |   2 +-
 libphobos/src/std/algorithm/iteration.d   |  34 +-
 libphobos/src/std/array.d | 387 +---
 libphobos/src/std/bigint.d|  26 +-
 libphobos/src/std/checkedint.d|   2 +-
 libphobos/src/std/container/dlist.d   |   2 +-
 libphobos/src/std/conv.d  |  36 ++
 libphobos/src/std/datetime/stopwatch.d|   1 -
 libphobos/src/std/format/internal/floats.d| 193 +++---
 libphobos/src/std/format/internal/read.d  |   5 +-
 libphobos/src/std/format/internal/write.d |  13 +-
 libphobos/src/std/format/read.d   |  10 +
 libphobos/src/std/functional.d|  72 ++-
 libphobos/src/std/getopt.d| 111 +++-
 libphobos/src/std/math/operations.d   |  95 +--
 libphobos/src/std/process.d   |  60 +-
 libphobos/src/std/random.d| 127 +++-
 libphobos/src/std/range/interfaces.d  |   2 +-
 libphobos/src/std/range/package.d |  21 +-
 libphobos/src/std/stdio.d | 144 +
 libphobos/src/std/sumtype.d   | 560 --
 libphobos/src/std/typecons.d  | 109 ++--
 .../testsuite/libphobos.phobos/std_array.d|  17 +
 .../testsuite/libphobos.phobos/std_conv.d |  12 +
 .../libphobos.phobos/std_functional.d |  33 ++
 .../testsuite/libphobos.phobos/std_sumtype.d  | 153 +
 26 files changed, 1787 insertions(+), 440 deletions(-)

diff --git a/libphobos/src/MERGE b/libphobos/src/MERGE
index 9603e65aa42..a5a685de236 100644
--- a/libphobos/src/MERGE
+++ b/libphobos/src/MERGE
@@ -1,4 +1,4 @@
-1b242048c9db88c52cb0df6cd50c2b7455bedc01
+0faae92d62bdc1cc1982f0e9c65830ece1677289
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/phobos repository.
diff --git a/libphobos/src/std/algorithm/iteration.d 
b/libphobos/src/std/algorithm/iteration.d
index 8a3add3b733..f8e1c05b658 100644
--- a/libphobos/src/std/algorithm/iteration.d
+++ b/libphobos/src/std/algorithm/iteration.d
@@ -446,35 +446,21 @@ if (fun.length >= 1)
 auto map(Range)(Range r)
 if (isInputRange!(Unqual!Range))
 {
-import std.meta : AliasSeq, staticMap;
+import std.meta : staticMap;
+import std.functional : adjoin;
 
 alias RE = ElementType!(Range);
-static if (fun.length > 1)
-{
-import std.functional : adjoin;
-import std.meta : staticIndexOf;
 
-alias _funs = staticMap!(unaryFun, fun);
-alias _fun = adjoin!_funs;
+alias _funs = staticMap!(unaryFun, fun);
+alias _fun = adjoin!_funs;
 
-// Once https://issues.dlang.org/show_bug.cgi?id=5710 is fixed
-// accross all compilers (as of 2020-04, it wasn't fixed in LDC 
and GDC),
-// this validation loop can be moved into a template.
-foreach (f; _funs)
-{
-static assert(!is(typeof(f(RE.init)) == void),
-"Mapping function(s) must not return void: " ~ 
_funs.stringof);
-}
-}
-else
+// Once https://issues.dlang.org/show_bug.cgi?id=5710 is fixed
+// accross all compilers (as of 2020-04, it wasn't fixed in LDC and 
GDC),
+// this validation loop can be moved into a template.
+foreach (f; _funs)
 {
-alias _fun = unaryFun!fun;
-alias _funs = AliasSeq!(_fun);
-
-// Do the validation separately for single parameters due to
-// https://issues.dlang.org/show_bug.cgi?id=15777.
-static assert(!is(typeof(_fun(RE.init)) == void),
-"Mapping function(s) must not return void: " ~ _funs.stringof);
+static assert(!is(typeof(f(RE.init)) == void),
+"Mapping function(s) must not return void: " ~ 
_funs.stringof);
 }
 
 return MapResult!(_fun, Range)(r);
diff --git a/libphobos/src/std/array.d b/libphobos/src/std/array.d
index fea70258ebf..53ffb06905f 100644
--- a/libphobos/src/std/array.d
+++ b

Re: [PATCH v2] c++/modules: Handle gnu_inline attribute, cleanup linkage determination [PR119154]

[Nathaniel Shead]

On Wed, Mar 12, 2025 at 08:52:19AM -0400, Jason Merrill wrote:
> On 3/10/25 9:50 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > 
> > Alternatively, a more minimal fix for the PR would be to just special
> > case the note_vague_linkage_fn calls to not be performed for gnu_inline
> > functions, if that's a preferable fix this late into stage 4.
> > 
> > -- >8 --
> > 
> > Currently, note_vague_linkage_fn is called on all definitions imported
> > from modules.  This is not correct, however; among other things, a
> > gnu_inline function does not have vague linkage, and causes an ICE if
> > its treated as such.
> > 
> > There are other things that we seem to potentially miss (e.g. dllexport
> > handling), so it seems sensible to stop trying to manage linkage in such
> > an ad-hoc manner but to use the normal interfaces more often.
> 
> Agreed.
> 
> > The change to use expand_or_defer_fn exposes a checking-only ICE in
> > trees_in::assert_definition, where we forget that we already installed a
> > definition for a function.  We work around this by instead of clearing
> > DECL_SAVED_TREE entirely in expand_or_defer_fn_1, we instead set it to a
> > dummy value.  This way we can also avoid the check for !TREE_ASM_WRITTEN
> > beforehand.
> 
> Makes sense.
> 
> > PR c++/119154
> > 
> > gcc/cp/ChangeLog:
> > 
> > * module.cc (trees_out::core_bools): Clear DECL_INTERFACE_KNOWN
> > for external-linkage functions, except gnu_inline.
> 
> ...but why is this change needed?  It seems like adding an ad-hoc subset of
> vague_linkage_p while we're trying to remove ad-hocery elsewhere. And I'm
> skeptical about doing this here for vague linkage in general; the
> typeinfo/vtable bits are for a specific ABI requirement, not because they're
> vague linkage.
> 
> It does seem like we need to teach vague_linkage_p about gnu_inline, would
> that remove the motivation for this change?

Thanks.  And right, that's a good point.  We still need a bit of this
change (as otherwise import_export_decl would never attempt to
redetermine whether we need to actually emit vague linkage entities,
since DECL_INTERFACE_KNOWN would still be set from when the exporter
processed these declarations) but it seems reasonable to move this
special-casing of gnu_inline into vague_linkage_p.

My initial concern with this was whether this would stop us from
emitting the definition of the function, but has_definition just uses
DECL_DECLARED_INLINE_P for FUNCTION_DECLs so it should continue working
correctly.

Here's an updated patch which does this, and also as a drive-by fix I
noticed while working on this, ensures that imported inline variables
are correctly marked as COMDAT.  Maybe there's a better way to do this
though: I'm not sure how concerned to be about !flag_weak handling?

Tested modules.exp so far on x86_64-pc-linux-gnu, OK for trunk if full
bootstrap and regtest succeeds?

-- >8 --

Currently, note_vague_linkage_fn is called on all definitions imported
from modules.  This is not correct, however; among other things, a
gnu_inline function does not have vague linkage, and causes an ICE if
its treated as such.

There are other things that we seem to potentially miss (e.g. dllexport
handling), so it seems sensible to stop trying to manage linkage in such
an ad-hoc manner but to use the normal interfaces more often.  While
looking at this I also found that we seem to miss marking vague linkage
variables as COMDAT, so this patch fixes that as well.

The change to use expand_or_defer_fn exposes a checking-only ICE in
trees_in::assert_definition, where we forget that we already installed a
definition for a function.  We work around this by instead of clearing
DECL_SAVED_TREE entirely in expand_or_defer_fn_1, we instead set it to a
dummy value.  This way we can also avoid the check for !TREE_ASM_WRITTEN
beforehand.

PR c++/119154

gcc/cp/ChangeLog:

* decl2.cc (vague_linkage_p): Don't treat gnu_inline functions
as having vague linkage.
* module.cc (trees_out::core_bools): Clear DECL_INTERFACE_KNOWN
for vague-linkage entities.
(read_var_def): Maybe set comdat linkage for imported var
definitions.
(module_state::read_cluster): Use expand_or_defer_fn instead of
ad-hoc linkage management.
(post_load_processing): Likewise.
* semantics.cc (expand_or_defer_fn_1): Don't forget that we had
a definition at all.

gcc/testsuite/ChangeLog:

* g++.dg/modules/linkage-3_a.C: New test.
* g++.dg/modules/linkage-3_b.C: New test.
* g++.dg/modules/pr119154_a.C: New test.
* g++.dg/modules/pr119154_b.C: New test.

Signed-off-by: Nathaniel Shead 
---
 gcc/cp/decl2.cc|  4 ++-
 gcc/cp/module.cc   | 33 ++
 gcc/cp/semantics.cc|  2 +-
 gcc/testsuite/g++.dg/modules/linkage-3_a.C |  5 
 gcc/testsuite/

Re: [PATCH] c++/modules: Better handle no-linkage decls in unnamed namespaces [PR118799]

[Jason Merrill]

On 3/7/25 6:00 AM, Nathaniel Shead wrote:

On Fri, Mar 07, 2025 at 09:48:27PM +1100, Nathaniel Shead wrote:

On Thu, Mar 06, 2025 at 11:20:59AM -0500, Jason Merrill wrote:

On 2/9/25 6:38 AM, Nathaniel Shead wrote:

On Sun, Feb 09, 2025 at 01:16:00AM +1100, Nathaniel Shead wrote:

Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap + regtest
passes?

-- >8 --

There are two issues with no-linkage decls (e.g. explicit type aliases)
in unnamed namespaces that this patch fixes.

Firstly, we don't currently handle exporting no-linkage decls in unnamed
namespaces.  This should be ill-formed in [module.export], since having
an exported declaration within a namespace-definition makes the
namespace definition exported (p2), but an unnamed namespace has
internal linkage thus violating p3.

Secondly, by the standard it appears to be possible to emit unnamed
namespaces from named modules in certain scenarios.  This patch makes
the adjustments needed to ensure we don't error in this case.



One thing to note with this is that it means that the following sample:

export module M;
namespace {
  struct Internal {};
  using Alias = Internal;
}

will still error:

test.cpp:4:9: error: ‘using {anonymous}::Alias = struct {anonymous}::Internal’ 
exposes TU-local entity ‘struct {anonymous}::Internal’
  4 |   using Alias = Internal;
| ^
test.cpp:3:10: note: ‘struct {anonymous}::Internal’ declared with internal 
linkage
  3 |   struct Internal {};
|  ^~~~

https://eel.is/c++draft/basic.link#17 is the relevant paragraph here,
but I'm not 100% sure what it says about this example; I suppose that
given Alias isn't really an entity maybe this should be OK?


Right; a non-template alias isn't an entity, and p17 only makes exposure
ill-formed if the declaration declares an entity.


But either way we definitely don't want to emit this alias.

Maybe the correct approach here is to mark an explicit type alias
TU-local iff the type it refers to is itself TU-local?  So something
like this on top of this patch:


Hmm, since it isn't an entity, it also isn't a TU-local entity.  Maybe in
finalize_dependencies, ignore is_exposure if the dep is not an entity?

Jason



Unfortunately this is not sufficient, as none of the following streaming
logic is prepared to handle TU-local dependencies.  I think marking
these aliases as TU-local is the most straightforward way to achieve the
required semantics of them not being streamed, since we don't really
have a general way to talk about deps referring to non-entities and how
they should be handled.

I've done this in the below patch, OK for trunk?


Whoops, attached the wrong version of the patch...

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?


OK.


-- >8 --

There are two issues with no-linkage decls (e.g. explicit type aliases)
in unnamed namespaces that this patch fixes.

Firstly, we don't currently handle exporting no-linkage decls in unnamed
namespaces.  This should be ill-formed in [module.export], since having
an exported declaration within a namespace-definition makes the
namespace definition exported (p2), but an unnamed namespace has
internal linkage thus violating p3.

Secondly, by the standard it appears to be possible to emit unnamed
namespaces from named modules in certain scenarios, for instance when
they contain a type alias (which is not itself an entity).  This patch
makes the adjustments needed to ensure we don't error in this scenario.

PR c++/118799

gcc/cp/ChangeLog:

* module.cc (depset::hash::is_tu_local_entity): Only types,
functions, variables, and template (specialisations) can be
TU-local.  Explicit type aliases are TU-local iff the type they
refer to are.
(module_state::write_namespaces): Allow unnamed namespaces in
named modules.
(check_module_decl_linkage): Error for all exported declarations
in an unnamed namespace.

gcc/testsuite/ChangeLog:

* g++.dg/modules/export-6.C: Adjust error message, add check for
no-linkage decls in namespace.
* g++.dg/modules/internal-4_b.C: Allow exposing a namespace with
internal linkage.  Type aliases are not entities and so never
exposures.
* g++.dg/modules/using-30_a.C: New test.
* g++.dg/modules/using-30_b.C: New test.
* g++.dg/modules/using-30_c.C: New test.

Signed-off-by: Nathaniel Shead 
---
  gcc/cp/module.cc| 58 -
  gcc/testsuite/g++.dg/modules/export-6.C | 33 +++-
  gcc/testsuite/g++.dg/modules/internal-4_b.C | 19 ---
  gcc/testsuite/g++.dg/modules/using-30_a.C   | 13 +
  gcc/testsuite/g++.dg/modules/using-30_b.C   | 10 
  gcc/testsuite/g++.dg/modules/using-30_c.C   | 17 ++
  6 files changed, 116 insertions(+), 34 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/modules/using-30_a.C
  create mode 100644 gcc/testsui

[PATCH][v2] tree-optimization/119155 - wrong aligned access for vectorized packed access

[Richard Biener]

When doing strided SLP vectorization we use the wrong alignment for
the possibly piecewise access of the vector elements for loads and
stores.  While we are carefully using element aligned loads and
stores that isn't enough for the case the original scalar accesses
are packed.  The following instead honors larger alignment when
present but correctly falls back to the original scalar alignment
used.

v2 fixes an issue with vector composition from larger scalar loads
and alignment noted by arm CI.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Richard.

PR tree-optimization/119155
* tree-vect-stmts.cc (vectorizable_store): Do not always
use vector element alignment for VMAT_STRIDED_SLP but
a more correct alignment towards both ends.
(vectorizable_load): Likewise.

* gcc.dg/vect/pr119155.c: New testcase.
---
 gcc/testsuite/gcc.dg/vect/pr119155.c | 26 ++
 gcc/tree-vect-stmts.cc   | 25 +
 2 files changed, 47 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr119155.c

diff --git a/gcc/testsuite/gcc.dg/vect/pr119155.c 
b/gcc/testsuite/gcc.dg/vect/pr119155.c
new file mode 100644
index 000..b860cf24b0f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr119155.c
@@ -0,0 +1,26 @@
+#include 
+#include "tree-vect.h"
+
+struct s { int x; } __attribute__((packed));
+
+void __attribute__((noipa))
+f (char *xc, char *yc, int z)
+{
+  for (int i = 0; i < 100; ++i)
+{
+  struct s *x = (struct s *) xc;
+  struct s *y = (struct s *) yc;
+  x->x += y->x;
+  xc += z;
+  yc += z;
+}
+}
+
+int main ()
+{
+  check_vect ();
+  char *x = malloc (100 * sizeof (struct s) + 1);
+  char *y = malloc (100 * sizeof (struct s) + 1);
+  f (x + 1, y + 1, sizeof (struct s));
+  return 0;
+}
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index f894787f7bf..17e3b1db894 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -8904,7 +8904,15 @@ vectorizable_store (vec_info *vinfo,
}
}
}
- ltype = build_aligned_type (ltype, TYPE_ALIGN (elem_type));
+ unsigned align;
+ if (alignment_support_scheme == dr_aligned)
+   align = known_alignment (DR_TARGET_ALIGNMENT (first_dr_info));
+ else
+   align = dr_alignment (vect_dr_behavior (vinfo, first_dr_info));
+ /* Alignment is at most the access size if we do multiple stores.  */
+ if (nstores > 1)
+   align = MIN (tree_to_uhwi (TYPE_SIZE_UNIT (ltype)), align);
+ ltype = build_aligned_type (ltype, align * BITS_PER_UNIT);
  ncopies = SLP_TREE_NUMBER_OF_VEC_STMTS (slp_node);
}
 
@@ -10851,7 +10859,7 @@ vectorizable_load (vec_info *vinfo,
  &ptype);
  if (vtype != NULL_TREE)
{
- dr_alignment_support dr_align = dr_aligned;
+ dr_alignment_support dr_align;
  int mis_align = 0;
  if (VECTOR_TYPE_P (ptype))
{
@@ -10860,6 +10868,8 @@ vectorizable_load (vec_info *vinfo,
= vect_supportable_dr_alignment (vinfo, dr_info, ptype,
 mis_align);
}
+ else
+   dr_align = dr_unaligned_supported;
  if (dr_align == dr_aligned
  || dr_align == dr_unaligned_supported)
{
@@ -10872,8 +10882,15 @@ vectorizable_load (vec_info *vinfo,
}
}
}
- /* Else fall back to the default element-wise access.  */
- ltype = build_aligned_type (ltype, TYPE_ALIGN (TREE_TYPE (vectype)));
+ unsigned align;
+ if (alignment_support_scheme == dr_aligned)
+   align = known_alignment (DR_TARGET_ALIGNMENT (first_dr_info));
+ else
+   align = dr_alignment (vect_dr_behavior (vinfo, first_dr_info));
+ /* Alignment is at most the access size if we do multiple loads.  */
+ if (nloads > 1)
+   align = MIN (tree_to_uhwi (TYPE_SIZE_UNIT (ltype)), align);
+ ltype = build_aligned_type (ltype, align * BITS_PER_UNIT);
}
 
   if (slp)
-- 
2.43.0

Re: c++/modules: Stream section, tls_model, and comdat_group

[Nathaniel Shead]

On Mon, Mar 10, 2025 at 02:52:07PM -0400, Jason Merrill wrote:
> On 3/10/25 9:52 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > Or should this wait for GCC16?
> > 
> > -- >8 --
> > 
> > While looking at PR c++/119154 I noticed some more properties that we
> > don't stream or check properly.  This patch adds the ones we were
> > missing, and adds checks that the values don't clash with existing
> > decls.
> 
> These seem to me like properties that should be recomputed rather than
> streamed; aren't we already streaming the section attribute?
> 

Hm, right; we're streaming the attributes but in general we don't
reapply any of the effects they have that aren't streamed regardless.
We should probably do that somehow; it looks like using decl_attributes
directly for this might do too much so I suppose we would need another
interface for this.

This is probably the way to go to fix PR108080, too; rather than messing
around with trying to work out how to stream OPTIMIZATION_NODEs etc. we
can just reapply the attribute, which also would probably have the
expected behaviour in the case of mismatching optimisation flags between
exporter and consumer.

> This comment also applies to the existing streaming of tls_model.
> 

I assume we can just use 'decl_default_tls_model' in the no-attribute
case?  Is there anything we should worry about wrt to it potentially
providing different results in different modules (due to different
choices of -ftls-model)?

Also, while reworking my other patch I'm now semi-convinced that there's
no need to stream comdat group, it should be recalculated correctly
anyway in all cases that I could find.  But I definitely might have
missed something; either way it hasn't bitten us yet.

Nathaniel

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

[pan2 . li]

From: Pan Li 

Rearrange the test cases of cond_widen_complicate-3 by different types
into different files, instead of put all types together.  Then we can
easily reduce the range when asm check fails.

The below test suites are passed locally, let's wait online CI says.
* The rv64gcv fully regression test.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3.c: Removed.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f16.c: New 
test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f32.c: New 
test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i16.c: New 
test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i32.c: New 
test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i8.c: New 
test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u16.c: New 
test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u32.c: New 
test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u8.c: New 
test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3.h: New test.

Signed-off-by: Pan Li 
---
 .../cond/cond_widen_complicate-3-f16.c|  9 +
 .../cond/cond_widen_complicate-3-f32.c|  9 +
 .../cond/cond_widen_complicate-3-i16.c|  9 +
 .../cond/cond_widen_complicate-3-i32.c|  9 +
 .../autovec/cond/cond_widen_complicate-3-i8.c |  9 +
 .../cond/cond_widen_complicate-3-u16.c|  9 +
 .../cond/cond_widen_complicate-3-u32.c|  9 +
 .../autovec/cond/cond_widen_complicate-3-u8.c |  9 +
 .../autovec/cond/cond_widen_complicate-3.c| 36 ---
 .../autovec/cond/cond_widen_complicate-3.h| 21 +++
 10 files changed, 93 insertions(+), 36 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f16.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f32.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i16.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i32.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i8.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u16.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u32.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u8.c
 delete mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3.h

diff --git 
a/gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f16.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f16.c
new file mode 100644
index 000..e4ff3106b0e
--- /dev/null
+++ 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f16.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=rv32gcv_zvfh -mabi=ilp32d 
-mrvv-vector-bits=scalable -ffast-math" } */
+
+#include "cond_widen_complicate-3.h"
+
+TEST_TYPE (float, _Float16)
+
+/* { dg-final { scan-assembler-times {\tvfwmul\.vv} 1 } } */
+/* { dg-final { scan-assembler-not {\tvmerge\.vvm\t} } } */
diff --git 
a/gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f32.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f32.c
new file mode 100644
index 000..7d2b44827cd
--- /dev/null
+++ 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f32.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=rv32gcv -mabi=ilp32d 
-mrvv-vector-bits=scalable -ffast-math" } */
+
+#include "cond_widen_complicate-3.h"
+
+TEST_TYPE (double, float)
+
+/* { dg-final { scan-assembler-times {\tvfwmul\.vv} 1 } } */
+/* { dg-final { scan-assembler-not {\tvmerge\.vvm\t} } } */
diff --git 
a/gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i16.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i16.c
new file mode 100644
index 000..dc7e1da76b8
--- /dev/null
+++ 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i16.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=rv32gcv -mabi=ilp32d 
-mrvv-vector-bits=scalable" } */
+
+#include "cond_widen_complicate-3.h"
+
+TEST_TYPE (int32_t, int16_t)
+
+/* { dg-final { scan-assembler-times {\tvwmul\.vv} 1 } } */
+/* { dg-final { scan-assembler-not {\tvmerge\.vvm\t} } } */
diff --git 
a/gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i32.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i32.

Re: [PATCH] contrib/gcc-changelog: Accept only [PRnnnn] in subject

[Jakub Jelinek]

On Wed, Mar 12, 2025 at 10:49:58AM +0100, Christophe Lyon wrote:
> On Wed, 12 Mar 2025 at 08:05, Richard Biener  
> wrote:
> >
> > On Tue, Mar 11, 2025 at 5:58 PM Christophe Lyon
> >  wrote:
> > >
> > > In https://gcc.gnu.org/contribute.html#patches we ask to use [PR]
> > > without the Bugzilla component identifier and with no space between
> > > 'PR' and the number, but git_check_commit.py accepts all forms.  The
> > > patch enforces what we document.
> > >
> > > Note that this would reject a few of the recent commits.
> >
> > Why would we be this restrictive?  I personally am using
> 
> Well, someone made me realize that I should have used [PR] rather
> than (PR ) in a recent commit, as documented in "Contributing to
> GCC".
> 
> Since I use gcc-verify, I looked at why I missed that, and hence
> proposed this patch, so that our tools match what we document
> 
> >
> > bugzilla-component/number - description
> >
> > IMO 'PR' is redundant and the component helps screening for area of
> > maintenance.

The documented style is
bugzilla-component: description [PRnumber]
(it doesn't need to be exactly bugzilla-component, though sometimes the
component and bugzilla-component are the same thing).
I believe it has been discussed on the mailing lists before it was
added to contribute.html.

Jakub

[PATCH v2] libstdc++: Hide 128-bit int and float types behind handle for basic_format_arg visitation [PR108053]

[Tomasz Kamiński]

Implement visit_format_arg and basic_format_arg::visit function,
in terms of  _M_visit_user member functions, that wraps any type
stored inside basic_format_arg, that is not specified as standard
into the handle. This affects __in128, unsigned __in128,
PowerPC specific __iee128 and __ibm128, and  _Float128 for architectures
where long double is not 128bits.

The bfloat16, _Float16, _Float32, _Float32, and _Float128 for
128bits long double are not are not addressed, as they
are transformed into standard floating point types.

For internal purposes __format::__visit_format_arg function is
used, that provides an umodifed access to stored object.

PR libstdc++/108053

libstdc++-v3/ChangeLog:

* include/std/format (basic_format_arg::_M_visit_user):
Helper function for wrapping extension types into handle
(visit_format_arg): Call `_M_visit_user` instead of `_M_visit`.
(basic_format_arg::visit): As above.
(__format::__visit_format_arg): Provides direct access to
values stored in basic_format_arg.
(__format::__int_from_arg): Use __format::__visit_format_arg
instead of std::visit_format_arg.
(_Formatting_scanner::_M_format_arg): As above.
(_Checking_scanner::__do_vformat_to): As above.
* testsuite/std/format/arguments/args.cc: New tests.
* testsuite/std/format/string.cc: Test for using __int128
as width/precision.
---
Revision added missing decltype(auto) return type for lambda in _M_user_visit.
Tested on x84_64-linux. Tested arguments/args.cc` with -mlong-double-128.
Tested `std/format` test on ppc64le-linux, with both -mabi=ieeelongdouble and 
-mabi=ibmlongdouble.
OK for trunk?

 libstdc++-v3/include/std/format   | 49 +++--
 .../testsuite/std/format/arguments/args.cc| 73 +++
 libstdc++-v3/testsuite/std/format/string.cc   | 10 ++-
 3 files changed, 123 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
index e7e0d2d142b..5085658cdb7 100644
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -3290,10 +3290,12 @@ namespace __format
   template
 class _Arg_store;
 
+  template
+decltype(auto) __visit_format_arg(_Visitor&&, basic_format_arg<_Ctx>);
+
   template
 consteval _Arg_t
 __to_arg_t_enum() noexcept;
-
 } // namespace __format
 /// @endcond
 
@@ -3365,12 +3367,12 @@ namespace __format
   template
decltype(auto)
visit(this basic_format_arg __arg, _Visitor&& __vis)
-   { return __arg._M_visit(std::forward<_Visitor>(__vis), __arg._M_type); }
+   { return __arg._M_visit_user(std::forward<_Visitor>(__vis), 
__arg._M_type); }
 
   template
_Res
visit(this basic_format_arg __arg, _Visitor&& __vis)
-   { return __arg._M_visit(std::forward<_Visitor>(__vis), __arg._M_type); }
+   { return __arg._M_visit_user(std::forward<_Visitor>(__vis), 
__arg._M_type); }
 #endif
 
 private:
@@ -3587,6 +3589,10 @@ namespace __format
friend decltype(auto)
visit_format_arg(_Visitor&& __vis, basic_format_arg<_Ctx>);
 
+  template
+   friend decltype(auto)
+   __format::__visit_format_arg(_Visitor&&, basic_format_arg<_Ctx>);
+
   template
friend consteval __format::_Arg_t
__format::__to_arg_t_enum() noexcept;
@@ -3655,6 +3661,28 @@ namespace __format
  __builtin_unreachable();
  }
}
+
+  template
+   decltype(auto)
+   _M_visit_user(_Visitor&& __vis, __format::_Arg_t __type)
+   {
+ return _M_visit([&__vis](_Tp& __val) -> decltype(auto)
+   {
+ constexpr bool __user_facing = __is_one_of<_Tp,
+   monostate, bool, _CharT,
+   int, unsigned int, long long int, unsigned long long int,
+   float, double, long double,
+   const _CharT*, basic_string_view<_CharT>,
+   const void*, handle>::value;
+if constexpr (__user_facing)
+  return std::forward<_Visitor>(__vis)(__val);
+else
+  {
+handle __h(__val);
+return std::forward<_Visitor>(__vis)(__h);
+  }
+  }, __type);
+   }
 };
 
   template
@@ -3662,12 +3690,19 @@ namespace __format
 inline decltype(auto)
 visit_format_arg(_Visitor&& __vis, basic_format_arg<_Context> __arg)
 {
-  return __arg._M_visit(std::forward<_Visitor>(__vis), __arg._M_type);
+  return __arg._M_visit_user(std::forward<_Visitor>(__vis), __arg._M_type);
 }
 
 /// @cond undocumented
 namespace __format
 {
+  template
+inline decltype(auto)
+__visit_format_arg(_Visitor&& __vis, basic_format_arg<_Ctx> __arg)
+{
+  return __arg._M_visit(std::forward<_Visitor>(__vis), __arg._M_type);
+}
+
   struct _WidthPrecVisitor
   {
 template
@@ -3699,7 +3734,7 @@ namespace __format
   template
 inline

[committed] arm: allow type-punning subregs in vpr_register_operand [PR115439]

[Richard Earnshaw]

Subregs that only change the mode of an operand (ie don't change the
size) should be safe for the VPR register.  If we don't permit them
we may end up with some redundant copy instructions.

gcc:
PR target/115439
* config/arm/predicates.md (vpr_register_operand): Allow type-punning
subregs.
---
 gcc/config/arm/predicates.md | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/gcc/config/arm/predicates.md b/gcc/config/arm/predicates.md
index 5c78421ff69..75c06d9be25 100644
--- a/gcc/config/arm/predicates.md
+++ b/gcc/config/arm/predicates.md
@@ -99,11 +99,21 @@ (define_predicate "guard_operand"
 })
 
 (define_predicate "vpr_register_operand"
-  (match_code "reg")
+  (match_code "reg,subreg")
 {
-  return REG_P (op)
+  if (SUBREG_P (op))
+{
+  /* Only allow subregs if they are strictly type punning. */
+  if ((GET_MODE_SIZE (GET_MODE (SUBREG_REG (op)))
+  != GET_MODE_SIZE (GET_MODE (op)))
+ || SUBREG_BYTE (op) != 0)
+   return false;
+  op = SUBREG_REG (op);
+}
+
+  return (REG_P (op)
  && (REGNO (op) >= FIRST_PSEUDO_REGISTER
- || IS_VPR_REGNUM (REGNO (op)));
+ || IS_VPR_REGNUM (REGNO (op;
 })
 
 (define_predicate "imm_for_neon_inv_logic_operand"
-- 
2.34.1

Re: AArch64: Turn off outline atomics with -mcmodel=large (PR112465)

[Wilco Dijkstra]

Hi Richard,

> That was also what I was trying to say.  In the worst case, the linked
> object has to meet the requirements of the lowest common denominator.
>
> And my supposition was that that isn't a property of static vs dynamic.

But it is. Dynamic linking supports mixing different code models without even
knowing which library uses which model. However with static linking you need
all libraries to be built for the same model, and if not, you end up with the 
lowest
common denominator.

Quite a fundamental difference.

> It applies to both (assuming that dynamic is supported by -mcmodel=large,
> despite the current documentation).  If you link medium and large code
> together statically, the result (in general) has to be small enough for
> the medium model.  The same is true if you link medium and large code
> together in a dynamic executable.

Did you mean "small" here rather than "medium"? Note mixing medium and
large models as currently specified would result in small model.

> So -static isn't intrinsically incompatible with -mcmodel=large.
> The documentation seems to be describing a property of the way that
> GLIBC is built on GNU/Linux systems, rather than a feature of -static
> vs -mcmodel=large per se.

AFAIK no libraries have been ported to -mcmodel=large. That includes not only
GLIBC or newlib, but also internal libraries like libatomic, libgcc and 
libstdc++.
Plus you'd need multi-libs.

It's unlikely anyone will ever do all this work. So not only does it not work 
today,
it is not going to work for as long as we insist that those libraries are the 
issue
(or worse, the user), rather than the large model.

This patch is an example of an issue that can be fixed easily so more cases work
out of the box. The large model could also be fixed to support PIC/PIE and 
static
linking with small model libraries.

> On aarch64-elf, everything is linked statically (unless you go to
> heroic lengths to use aarch64-elf on a "full" custom OS).  And that's
> fine provided that everything is built with the right model.

And guess what? -mcmodel=large doesn't work on aarch64-elf. I've lost count
how many times I had to explain why large model code links to dynamic libraries
without errors but fails to link statically.

Cheers,
Wilco

Re: [PATCH] contrib/gcc-changelog: Accept only [PRnnnn] in subject

[Richard Biener]

On Wed, Mar 12, 2025 at 11:02 AM Jonathan Wakely  wrote:
>
> On Wed, 12 Mar 2025 at 09:55, Jakub Jelinek  wrote:
> >
> > On Wed, Mar 12, 2025 at 10:49:58AM +0100, Christophe Lyon wrote:
> > > On Wed, 12 Mar 2025 at 08:05, Richard Biener  
> > > wrote:
> > > >
> > > > On Tue, Mar 11, 2025 at 5:58 PM Christophe Lyon
> > > >  wrote:
> > > > >
> > > > > In https://gcc.gnu.org/contribute.html#patches we ask to use [PR]
> > > > > without the Bugzilla component identifier and with no space between
> > > > > 'PR' and the number, but git_check_commit.py accepts all forms.  The
> > > > > patch enforces what we document.
> > > > >
> > > > > Note that this would reject a few of the recent commits.
> > > >
> > > > Why would we be this restrictive?  I personally am using
> > >
> > > Well, someone made me realize that I should have used [PR] rather
> > > than (PR ) in a recent commit, as documented in "Contributing to
> > > GCC".
> > >
> > > Since I use gcc-verify, I looked at why I missed that, and hence
> > > proposed this patch, so that our tools match what we document
> > >
> > > >
> > > > bugzilla-component/number - description
> > > >
> > > > IMO 'PR' is redundant and the component helps screening for area of
> > > > maintenance.
> >
> > The documented style is
> > bugzilla-component: description [PRnumber]
>
> And so I do think we should reject (PR nnn) at the end, for example.
>
> Maybe the other checks don't need to be so strict, I don't feel
> strongly about that.

The question is whether there's good heuristic to detect this is a fix
for a PR - such heuristic should look at the bugzilla relevant line
before the ChangeLog (though rejecting otherwise heuristically
identified PR fixes with that missing would be nice as well)

Richard.

>
> > (it doesn't need to be exactly bugzilla-component, though sometimes the
> > component and bugzilla-component are the same thing).
> > I believe it has been discussed on the mailing lists before it was
> > added to contribute.html.
> >
> > Jakub
> >
>

Re: [PATCH] df: Treat partial defs as uses in df_simulate_defs [PR116564]

[Alex Coplan]

On 11/03/2025 17:39, Richard Sandiford wrote:
> Alex Coplan  writes:
> > Hi,
> >
> > The PR shows us spinning in dce.cc:fast_dce at the start of combine.
> > This spinning appears to be because of a disagreement between the fast_dce 
> > code
> > and the code in df-problems.cc:df_lr_bb_local_compute.  Specifically, they
> > disagree on the treatment of partial defs.  For the testcase in the PR, we 
> > have
> > the following insn in bb 3:
> >
> > (insn 10 8 13 3 (clobber (subreg:V1DF (reg/v:V2x1DF 104 [ __val ]) 8)) -1
> >  (nil))
> >
> > which gives rise to a DF def with DF_REF_FLAGS = 0x8b0, i.e.
> > DF_REF_PARTIAL | DF_REF_READ_WRITE | DF_REF_MUST_CLOBBER | DF_REF_SUBREG.
> >
> > Eliding the large block comment for readability, the code in
> > df_lr_bb_local_compute does the following (for each insn):
> >
> >   FOR_EACH_INSN_INFO_DEF (def, insn_info)
> > {
> >   unsigned int dregno = DF_REF_REGNO (def);
> >   bitmap_set_bit (&bb_info->def, dregno);
> >   if (DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL))
> > bitmap_set_bit (&bb_info->use, dregno);
> >   else
> > bitmap_clear_bit (&bb_info->use, dregno);
> > }
> >
> > i.e. it models partial defs as a RMW operation; thus for the def arising
> > from i10 above, it records a use of r104; hence it ends up in the
> > live-in set for bb 3.
> >
> > However, as it stands, the code in dce.cc:fast_dce (and its callee
> > dce_process_block) has no such provision for DF_REF_PARTIAL defs.  It
> > does not treat these as a RMW and does not compute r104 above as being
> > live-in to bb 3.  At the end of dce_process_block we compute the
> > following "did something happen" condition used to decide termination of
> > the analysis:
> >
> >   block_changed = !bitmap_equal_p (local_live, DF_LR_IN (bb));
> >   if (block_changed)
> > bitmap_copy (DF_LR_IN (bb), local_live);
> >
> >   BITMAP_FREE (local_live);
> >   return block_changed;
> >
> > because of the disagreement between df_lr_local_compute and the local
> > analysis done by fast_dce, we invariably have r104 in DF_LR_IN, but not
> > in local_live.  Hence we always return true here, call
> > df_analyze_problem (which re-computes DF_LR_IN according to
> > df_lr_bb_local_compute, re-adding r104), and so the analysis never
> > terminates.
> >
> > This patch therefore adjusts df_simulate_defs (called from
> > dce_process_block) to match the behaviour of df_lr_bb_local_compute in
> > this respect, namely we make it model partial defs as RMW operations by
> > setting the relevant register live.  This fixes the spinning in fast_dce
> > for this testcase.
> >
> > Bootstrapped/regtested on aarch64-linux-gnu, arm-linux-gnueabihf, and
> > x86_64-linux-gnu: no regressions.  I also checked that this is netural
> > for SPEC CPU 2017 on Graviton 3.  OK for trunk?  If so, what about
> > backports?
> >
> > Thanks,
> > Alex
> >
> > gcc/ChangeLog:
> >
> > PR rtl-optimization/116564
> > * df-problems.cc (df_simulate_defs): For partial defs, mark the
> > register live (treat it as a RMW operation).
> >
> > gcc/testsuite/ChangeLog:
> >
> > PR rtl-optimization/116564
> > * gcc.target/aarch64/torture/pr116564.c: New test.
> 
> OK, thanks.  I think it's also ok to backport after a settling period
> (but probably best to leave a reasonable amount of time before backporting,
> since this is sensitive code).

Thanks, pushed to trunk as g:758e617bcf224dc9d4a7e26dd858d43c1e63b916.

Yes this seems like sensitive code indeed, so I'll leave this for at
least a couple of weeks before thinking about backports.

Alex

> 
> Richard
> 
> >
> > diff --git a/gcc/df-problems.cc b/gcc/df-problems.cc
> > index f32185b3eac..90753793098 100644
> > --- a/gcc/df-problems.cc
> > +++ b/gcc/df-problems.cc
> > @@ -3893,9 +3893,11 @@ df_simulate_defs (rtx_insn *insn, bitmap live)
> >  {
> >unsigned int dregno = DF_REF_REGNO (def);
> >  
> > -  /* If the def is to only part of the reg, it does
> > -not kill the other defs that reach here.  */
> > -  if (!(DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL)))
> > +  /* If the def is to only part of the reg, model it as a RMW operation
> > +by marking it live.  It only kills the reg if it is a complete def.  */
> > +  if (DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL))
> > +   bitmap_set_bit (live, dregno);
> > +  else
> > bitmap_clear_bit (live, dregno);
> >  }
> >  }
> > diff --git a/gcc/testsuite/gcc.target/aarch64/torture/pr116564.c 
> > b/gcc/testsuite/gcc.target/aarch64/torture/pr116564.c
> > new file mode 100644
> > index 000..d471e097294
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/aarch64/torture/pr116564.c
> > @@ -0,0 +1,11 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "" } */
> > +#include 
> > +void test()
> > +{
> > +  for (int L = 0; L < 4; ++L) {
> > +float64_t ResData[1 * 2];
> > +float64x1x2_t 

[PATCH] c++, v2: Evaluate immediate invocation call arguments with mce_true [PR119150]

[Jakub Jelinek]

On Wed, Mar 12, 2025 at 09:01:17AM -0400, Jason Merrill wrote:
> Why not use new_ctx for this instead of creating another copy?
> 
> I would think once we see that we have an immediate function, we want to go
> ahead and set ctx->manifestly_const_eval and new_call->manifestly_const_eval
> to true.  It looks like we currently cache immediate invocations separately
> depending on whether they're in an enclosing immediate function context,
> which seems redundant.
> 
> Incidentally, I don't remember why we need a separate call_ctx either.

So like this then?
Passes
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 make check-g++ 
RUNTESTFLAGS="dg.exp=consteval*"
ok if it passes full bootstrap/regtest?

2025-03-12  Jakub Jelinek  

PR c++/119150
* constexpr.cc (cxx_eval_call_expression): For
DECL_IMMEDIATE_FUNCTION_P (fun) set manifestly_const_eval in new_ctx
and new_call to mce_true and set ctx to &new_ctx.

* g++.dg/cpp2a/consteval41.C: New test.

--- gcc/cp/constexpr.cc.jj  2025-03-01 09:13:17.694075636 +0100
+++ gcc/cp/constexpr.cc 2025-03-12 16:30:29.376492168 +0100
@@ -3077,6 +3077,15 @@ cxx_eval_call_expression (const constexp
   ctx->global->put_value (new_ctx.object, ctor);
   ctx = &new_ctx;
 }
+  /* An immediate invocation is manifestly constant evaluated including the
+ arguments of the call, so use mce_true even for the argument
+ evaluation.  */
+  if (DECL_IMMEDIATE_FUNCTION_P (fun))
+{
+  new_ctx.manifestly_const_eval = mce_true;
+  new_call.manifestly_const_eval = mce_true;
+  ctx = &new_ctx;
+}
 
   /* We used to shortcut trivial constructor/op= here, but nowadays
  we can only get a trivial function here with -fno-elide-constructors.  */
--- gcc/testsuite/g++.dg/cpp2a/consteval41.C.jj 2025-03-07 13:39:34.526101144 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/consteval41.C2025-03-07 13:38:38.128871572 
+0100
@@ -0,0 +1,37 @@
+// PR c++/119150
+// { dg-do run { target c++20 } }
+
+consteval bool
+foo (bool x)
+{
+  return x;
+}
+
+constexpr bool
+bar ()
+{
+#if __cpp_if_consteval >= 202106L
+  if consteval
+{
+  return true;
+}
+  else
+{
+  return false;
+}
+#else
+  return __builtin_is_constant_evaluated ();
+#endif
+}
+
+int
+main ()
+{
+  bool a = false;
+  a = foo (bar ());
+  if (!a)
+__builtin_abort ();
+  bool b = foo (bar ());
+  if (!b)
+__builtin_abort ();
+}


Jakub

Regression? Re: [patch, fortran] Fix PR 119078, putting a procedure in an abstract interface into global namespace

[Andre Vehreschild]

Hi Thomas,

I think this patch produced a regression:

FAIL: gfortran.dg/binding_label_tests_26b.f90   -O   (test for errors, line 8)
FAIL: gfortran.dg/binding_label_tests_26b.f90   -O   (test for errors, line 9)

When I revert your patch and test again, above fails do not occur. Could you
please investigate, if I am right?

Regards,
Andre

On Tue, 11 Mar 2025 17:45:16 +0100
Thomas Koenig  wrote:

> Am 11.03.25 um 10:22 schrieb Andre Vehreschild:
> > Hi Thomas,
> >
> > looks good to me as well. Thanks for the patch.
>
> Committed as r15-7964.
>
> Thanks Harald and Andre!
>
> Best regards
>
>   Thomas
>


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

[PATCH] cobol/119229 - fix external variable declaration

[Richard Biener]

The following makes vs_external_reference behave like documented,
declare a variable defined elsewhere which means not setting
TREE_STATIC but DECL_EXTERNAL.

Built on x86_64-unknown-linux-gnu, tested with the cobol.dg
testsuite (which doesn't mean much).  The removed comment mentions
'stderr', possibly the NIST testsuite has coverage.

OK for trunk?

Thanks,
Richard.

PR cobol/119229
* gengen.cc (gg_declare_variable): Use DECL_EXTERNAL and
drop TREE_STATIC for vs_external_reference.

* cobol.dg/pr119229.cob: New testcase.
---
 gcc/cobol/gengen.cc |  6 +-
 gcc/testsuite/cobol.dg/pr119229.cob | 16 
 2 files changed, 17 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/cobol.dg/pr119229.cob

diff --git a/gcc/cobol/gengen.cc b/gcc/cobol/gengen.cc
index fc625faecf0..ea0521e0f24 100644
--- a/gcc/cobol/gengen.cc
+++ b/gcc/cobol/gengen.cc
@@ -1013,13 +1013,9 @@ gg_declare_variable(tree type_decl,
   break;
 case vs_external_reference:
   // This is for referencing variables defined elsewhere
-  // TODO: Figure out why this is working.  For accessing "stderr", it
-  // doesn't matter if TREE_PUBLIC is on, but TREE_STATIC has to be on. 
This
-  // does *not* match what is seen when compiling a C program that accesses
-  // "stderr".
   DECL_CONTEXT (var_decl) = gg_trans_unit.trans_unit_decl;
   TREE_USED(var_decl)   = 1;
-  TREE_STATIC(var_decl) = 1;
+  DECL_EXTERNAL (var_decl) = 1;
   TREE_PUBLIC(var_decl) = 1;
   break;
 }
diff --git a/gcc/testsuite/cobol.dg/pr119229.cob 
b/gcc/testsuite/cobol.dg/pr119229.cob
new file mode 100644
index 000..e7b500067ee
--- /dev/null
+++ b/gcc/testsuite/cobol.dg/pr119229.cob
@@ -0,0 +1,16 @@
+*> { dg-do compile }
+*> { dg-options "-flto" { target lto } }
+IDENTIFICATION DIVISION.
+PROGRAM-ID. CobolGreeting.
+*>Program to display COBOL greetings
+DATA DIVISION.
+WORKING-STORAGE SECTION.
+01  IterNum   PIC 9 VALUE 5.
+
+PROCEDURE DIVISION.
+BeginProgram.
+   PERFORM DisplayGreeting IterNum TIMES.
+   STOP RUN.
+
+DisplayGreeting.
+   DISPLAY "Greetings from COBOL".
-- 
2.43.0

Re: [PATCH] cfgexpand: Special case expansion of dead COMPLEX_EXPRs at -O0 [PR119120]

[Richard Biener]

On Wed, 12 Mar 2025, Jakub Jelinek wrote:

> On Tue, Mar 11, 2025 at 12:13:13PM +0100, Richard Biener wrote:
> > On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> > 
> > > On Tue, Mar 11, 2025 at 10:18:18AM +0100, Richard Biener wrote:
> > > > I think the patch as-is is more robust, but still - ugh ... I wonder
> > > > whether we can instead avoid introducing the COMPLEX_EXPR at all
> > > > at -O0?
> > > 
> > > Can we set DECL_NOT_GIMPLE_REG_P at -O0 during gimplification (where
> > > we've already handled some uses/setters of it), at least when
> > > gimplify_modify_expr_complex_part sees {REAL,IMAG}PART_EXPR on
> > > {VAR,PARM,RESULT}_DECL?
> > 
> > Yes, that should work for LHS __real / __imag.
> 
> Unfortunately it doesn't.
> 
> Although successfully bootstrapped on x86_64-linux and i686-linux,
> it caused g++.dg/cpp1z/decomp2.C, g++.dg/torture/pr109262.C and
> g++.dg/torture/pr88149.C regressions.
> 
> Minimal testcase is -O0:
> void
> foo (float x, float y)
> {
>   __complex__ float z = x + y * 1.0fi;
>   __real__ z = 1.0f;
> }
> which ICEs with
> pr88149.c: In function ‘foo’:
> pr88149.c:2:1: error: non-register as LHS of binary operation
> 2 | foo (float x, float y)
>   | ^~~
> z = COMPLEX_EXPR <_2, y.0>;
> pr88149.c:2:1: internal compiler error: ‘verify_gimple’ failed
> When the initialization is being gimplified, z is still
> not DECL_NOT_GIMPLE_REG_P and so is_gimple_reg is true for it and
> so it gimplifies it as
>   z = COMPLEX_EXPR <_2, y.0>;
> later, instead of building
>   _3 = IMAGPART_EXPR ;
>   z = COMPLEX_EXPR <1.0e+0, _3>;
> like before, the patch forces z to be not a gimple reg and uses
>   REALPART_EXPR  = 1.0e+0;
> but it is too late, nothing fixes up the gimplification of the COMPLEX_EXPR
> anymore.

Ah, yeah - setting DECL_NOT_GIMPLE_REG_P "after the fact" doesn't work.

> So, I think we'd really need to do it the old way with adjusted naming
> of the flag, so assume for all non-addressable
> VAR_DECLs/PARM_DECLs/RESULT_DECLs with COMPLEX_TYPE if (!optimize) they
> are DECL_NOT_GIMPLE_REG_P (perhaps with the exception of
> get_internal_tmp_var), and at some point (what) if at all optimize that
> away if the partial accesses aren't done.

We could of course do that in is_gimple_reg (), but I'm not sure if
all places that would need to check do so.  Alternatively gimplify

__real x = ..

into

tem[DECL_NOT_GIMPLE_REG_P] = x;
__real tem = ...;
x = tem;

when 'x' is a is_gimple_reg?  Of course for -O0 this would be quite bad.
Likewise for your idea - where would we do this optimization when not
optimizing?

So it would need to be the frontend(s) setting DECL_NOT_GIMPLE_REG_P
when producing lvalue __real/__imag accesses?

Richard.


> Thoughts on this?
> 
> 2025-03-11  Jakub Jelinek  
> 
>   PR target/119120
>   * gimplify.cc (gimplify_modify_expr): Don't call
>   gimplify_modify_expr_complex_part for -O0, instead set
>   DECL_NOT_GIMPLE_REG_P on the {REAL,IMAG}PART_EXPR operand.
> 
> --- gcc/gimplify.cc.jj2025-03-10 09:31:20.579772627 +0100
> +++ gcc/gimplify.cc   2025-03-11 15:03:27.633636148 +0100
> @@ -7237,7 +7237,15 @@ gimplify_modify_expr (tree *expr_p, gimp
>if ((TREE_CODE (*to_p) == REALPART_EXPR
> || TREE_CODE (*to_p) == IMAGPART_EXPR)
>&& is_gimple_reg (TREE_OPERAND (*to_p, 0)))
> -return gimplify_modify_expr_complex_part (expr_p, pre_p, want_value);
> +{
> +  if (optimize)
> + return gimplify_modify_expr_complex_part (expr_p, pre_p, want_value);
> +  /* When not optimizing, instead set DECL_NOT_GIMPLE_REG_P on it and
> +  keep using {REAL,IMAG}PART_EXPR on the partial initializations
> +  in order to avoid copying around uninitialized parts.  See
> +  PR119120.  */
> +  DECL_NOT_GIMPLE_REG_P (TREE_OPERAND (*to_p, 0)) = 1;
> +}
>  
>/* Try to alleviate the effects of the gimplification creating artificial
>   temporaries (see for example is_gimple_reg_rhs) on the debug info, but
> 
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

RE: [PATCH][v3] Simple cobol.dg testsuite

[Robert Dubner]

> -Original Message-
> From: Jakub Jelinek 
> Sent: Wednesday, March 12, 2025 03:23
> To: Robert Dubner 
> Cc: Richard Biener ; Iain Sandoe
> ; GCC Patches ;
> jklow...@schemamania.org
> Subject: Re: [PATCH][v3] Simple cobol.dg testsuite
> 
> On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:
> > Earlier in this discussion of a testsuite, the question came up about
> > generating an error return in COBOL source code.
> >
> > In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;".
> > When executed in  the initial "top-level" program-id, it results in
> > the value 1 being passed back to the _start stub.
> >
> > "STOP RUN ERROR 1." is the equivalent of (and is in fact implemented
> > with) "exit(1)".
> 
> Note, in most of the testsuite we try to signal failure from a runtime
> testcase through calling abort (or e.g. fortran STOP N statement).
> On Linux at least when not cross-compiling, exit(1) (or this STOP RUN
> ERROR 1) will work as well, I believe the reason is for some bare metal
> targets which just don't propagate return value from main or exit back
to
> the dejagnu testing framework.
> Does COBOL have something that is implemented as call to abort()?

Jim and I had the design goal of making gcobol object files completely
compatible with other gcc object files, so they can be linked together
without surprises.  There are issues of naming things; COBOL allows for
names with embedded hyphens, and is case-insensitive, and so a complete
answer can be involved.  But that's not important for addressing your
question.

The result is that putting in the COBOL statement 

  CALL "abort".

does just what you'd expect.

So, for that matter, does

  CALL "exit" USING BY VALUE 123.

although that's the same as 

  STOP RUN ERROR 123.

Bob D.

Re: The COBOL front end, version 3, now in 14 easy pieces

[David Malcolm]

On Wed, 2025-03-12 at 12:09 +0100, Mark Wielaard wrote:
> Hi David,
> 
> On Mon, Mar 10, 2025 at 05:40:18PM -0400, David Malcolm wrote:
> > FWIW gcc/cobol/lang.opt.urls has some D-specific things that look
> > like
> > copy-and-paste cruft, but hopefully it won't cause problems.
> 
> And some Fortran stuff. The autoregen bot currently flags it with the
> following diff:
> 
> diff --git a/gcc/cobol/lang.opt.urls b/gcc/cobol/lang.opt.urls
> index a0e1f1944fe..6a5dc1c0f58 100644
> --- a/gcc/cobol/lang.opt.urls
> +++ b/gcc/cobol/lang.opt.urls
> @@ -10,20 +10,27 @@ UrlSuffix(gcc/Preprocessor-Options.html#index-D-
> 1)
>  I
>  UrlSuffix(gcc/Directory-Options.html#index-I)
> LangUrlSuffix_D(gdc/Directory-Options.html#index-I)
>  
> +ffixed-form
> +LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-
> ffixed-form)
> +
>  fsyntax-only
> -UrlSuffix(gcc/Warning-Options.html#index-fsyntax-only)
> LangUrlSuffix_D(gdc/Warnings.html#index-fno-syntax-only)
> +UrlSuffix(gcc/Warning-Options.html#index-fsyntax-only)
> LangUrlSuffix_D(gdc/Warnings.html#index-fno-syntax-only)
> LangUrlSuffix_Fortran(gfortran/Error-and-Warning-Options.html#index-
> fsyntax-only)
> +
> +ffree-form
> +LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-
> ffree-form)
>  
>  fmax-errors
>  UrlSuffix(gcc/Warning-Options.html#index-fmax-errors)
> LangUrlSuffix_D(gdc/Warnings.html#index-fmax-errors)
>  
>  iprefix
> -UrlSuffix(gcc/Directory-Options.html#index-iprefix)
> LangUrlSuffix_D(gdc/Directory-Options.html#index-iprefix)
> +UrlSuffix(gcc/Directory-Options.html#index-iprefix)
> LangUrlSuffix_D(gdc/Directory-Options.html#index-iprefix)
> LangUrlSuffix_Fortran(gfortran/Preprocessing-Options.html#index-
> iprefix)
>  
>  include
>  UrlSuffix(gcc/Preprocessor-Options.html#index-include)
>  
>  isysroot
> -UrlSuffix(gcc/Directory-Options.html#index-isysroot)
> +UrlSuffix(gcc/Directory-Options.html#index-isysroot)
> LangUrlSuffix_Fortran(gfortran/Preprocessing-Options.html#index-
> isysroot)
>  
>  isystem
> -UrlSuffix(gcc/Directory-Options.html#index-isystem)
> +UrlSuffix(gcc/Directory-Options.html#index-isystem)
> LangUrlSuffix_Fortran(gfortran/Preprocessing-Options.html#index-
> isystem)
> +
> 
> I don't really understand what these D and Fortran references are
> for. 

These eventually get processed by options-urls-cc-gen.awk; the dups
aren't a problem.


> Are these expected? Should we simply regenerate them with the
> above diff? 

Yes, and thanks for fixing this.

> Or does the make regenerate-opt-urls target need an
> update?
> 

Yes; I took a look at this, but PR web/119227 would need fixing first
(so that we have URLs to point at).

Dave

Re: [PATCH] cobol: Remove unnecesssary CPPFLAGS update and restore MacOS build

[Simon Martin]

Hi Robert,

On Wed Mar 12, 2025 at 2:12 PM CET, Robert Dubner wrote:
>
>
>> -Original Message-
>> From: Simon Martin 
>> Sent: Wednesday, March 12, 2025 06:27
>> To: gcc-patches@gcc.gnu.org
>> Cc: rdub...@symas.com
>> Subject: [PATCH] cobol: Remove unnecesssary CPPFLAGS update and restore
>> MacOS build
>> 
>> The build currently fails on MacOS even when the Cobol front-end and
>> libgcobol builds are disabled.
>> 
>> The problem is that gcc/cobol/Make-lang.in adds -Iinclude to CPPFLAGS,
>> which somehow makes clang unhappy about the include order:
>>   error:  tried including  but didn't find libc++'s
>>header. This usually means that your header search paths
>>   are not configured properly.
>> 
>> It turns out that this addition is unnecessary: simply removing it fixes
>> the build on MacOS, without impacting the build x86_64-pc-linux-gnu when
>> configured with --enable-languages=default,cobol.
>> 
>> It feels like there might be more cleanup opportunities there, but they
>> can be taken care of later.
>> 
>> OK for trunk?
>
> I am still trying to get up to speed, here.  Jim and I have been living in
> our tidy little world; he's been developing in an Ubuntu instances on a
> aarch64 Mac M2, and I've been developing on an Ubuntu environment on a
> x86_64.
This is a lot more standard than the 2013 Mac I was compiling on :-) I
definitely expect the build to break at times on it, and it's fine.

> But now we've gotten off the train at Grand Central Station, and I feel
> like there are cars whizzing by, and horns honking, and pedestrians
> pushing past me muttering, "Brush the hay out of your hair!"
I copied you primarily for information and as Cobol maintainer, but did
not expect any action from you; sorry if it was unclear.

> So, if I am supposed to answer that question, and if indeed the change
> doesn't affect x86_64-pc-linux-gnu builds, then by all means, it is "OK
> for trunk".
Thanks. Richard already approved and I've pushed the fix, so it's all
good.

Simon

Re: [PATCH] cfgexpand: Special case expansion of dead COMPLEX_EXPRs at -O0 [PR119120]

[Jakub Jelinek]

On Tue, Mar 11, 2025 at 12:13:13PM +0100, Richard Biener wrote:
> On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> 
> > On Tue, Mar 11, 2025 at 10:18:18AM +0100, Richard Biener wrote:
> > > I think the patch as-is is more robust, but still - ugh ... I wonder
> > > whether we can instead avoid introducing the COMPLEX_EXPR at all
> > > at -O0?
> > 
> > Can we set DECL_NOT_GIMPLE_REG_P at -O0 during gimplification (where
> > we've already handled some uses/setters of it), at least when
> > gimplify_modify_expr_complex_part sees {REAL,IMAG}PART_EXPR on
> > {VAR,PARM,RESULT}_DECL?
> 
> Yes, that should work for LHS __real / __imag.

Unfortunately it doesn't.

Although successfully bootstrapped on x86_64-linux and i686-linux,
it caused g++.dg/cpp1z/decomp2.C, g++.dg/torture/pr109262.C and
g++.dg/torture/pr88149.C regressions.

Minimal testcase is -O0:
void
foo (float x, float y)
{
  __complex__ float z = x + y * 1.0fi;
  __real__ z = 1.0f;
}
which ICEs with
pr88149.c: In function ‘foo’:
pr88149.c:2:1: error: non-register as LHS of binary operation
2 | foo (float x, float y)
  | ^~~
z = COMPLEX_EXPR <_2, y.0>;
pr88149.c:2:1: internal compiler error: ‘verify_gimple’ failed
When the initialization is being gimplified, z is still
not DECL_NOT_GIMPLE_REG_P and so is_gimple_reg is true for it and
so it gimplifies it as
  z = COMPLEX_EXPR <_2, y.0>;
later, instead of building
  _3 = IMAGPART_EXPR ;
  z = COMPLEX_EXPR <1.0e+0, _3>;
like before, the patch forces z to be not a gimple reg and uses
  REALPART_EXPR  = 1.0e+0;
but it is too late, nothing fixes up the gimplification of the COMPLEX_EXPR
anymore.

So, I think we'd really need to do it the old way with adjusted naming
of the flag, so assume for all non-addressable
VAR_DECLs/PARM_DECLs/RESULT_DECLs with COMPLEX_TYPE if (!optimize) they
are DECL_NOT_GIMPLE_REG_P (perhaps with the exception of
get_internal_tmp_var), and at some point (what) if at all optimize that
away if the partial accesses aren't done.

Thoughts on this?

2025-03-11  Jakub Jelinek  

PR target/119120
* gimplify.cc (gimplify_modify_expr): Don't call
gimplify_modify_expr_complex_part for -O0, instead set
DECL_NOT_GIMPLE_REG_P on the {REAL,IMAG}PART_EXPR operand.

--- gcc/gimplify.cc.jj  2025-03-10 09:31:20.579772627 +0100
+++ gcc/gimplify.cc 2025-03-11 15:03:27.633636148 +0100
@@ -7237,7 +7237,15 @@ gimplify_modify_expr (tree *expr_p, gimp
   if ((TREE_CODE (*to_p) == REALPART_EXPR
|| TREE_CODE (*to_p) == IMAGPART_EXPR)
   && is_gimple_reg (TREE_OPERAND (*to_p, 0)))
-return gimplify_modify_expr_complex_part (expr_p, pre_p, want_value);
+{
+  if (optimize)
+   return gimplify_modify_expr_complex_part (expr_p, pre_p, want_value);
+  /* When not optimizing, instead set DECL_NOT_GIMPLE_REG_P on it and
+keep using {REAL,IMAG}PART_EXPR on the partial initializations
+in order to avoid copying around uninitialized parts.  See
+PR119120.  */
+  DECL_NOT_GIMPLE_REG_P (TREE_OPERAND (*to_p, 0)) = 1;
+}
 
   /* Try to alleviate the effects of the gimplification creating artificial
  temporaries (see for example is_gimple_reg_rhs) on the debug info, but


Jakub

Re: [TO-BE-COMMITED,PATCH] s390: Deprecate ESA/390 support

[Joseph Myers]

This commit has changed int __attribute__ ((__mode__ (__word__))) on s390 
-m31 from int to long long.  That introduces a glibc testsuite failure - 
the glibc testsuite verifies the expected C++ name mangling of various 
types, including register_t (which is defined with that attribute).

https://sourceware.org/pipermail/libc-testresults/2025q1/013529.html

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

Re: [Fortran, Patch, PR98903, v1] Add parsing and code gen for TEAM_NUMBER in coindexes.

[Andre Vehreschild]

Hi Harald,

thanks for the review. Committed with the requested changes (intrinsic module
ISO_FORTRAN_ENV and indexes -> indices in the description) as
gcc-15-7997-gbaa9b2b8d2e

I haven't added F2023 NOTIFY= image-selector yet, because at the moment I am
striving to get F2018 more complete.

Thanks again for the review.

Regards,
Andre

On Tue, 11 Mar 2025 21:49:05 +0100
Harald Anlauf  wrote:

> Hi Andre!
>
> Am 11.03.25 um 17:13 schrieb Andre Vehreschild:
> > Hi all,
> >
> > attached patch adds parsing of TEAM_NUMBER= named arguments in coindexed
> > expressions. The patch also ensures that once in an image_selector_list no
> > more regular coarray indexes are accepted, i.e. coarray[1,2,3, STAT=S, 5] is
> > rejected, because the 5 must not come after any of (STAT, TEAM,
> > TEAM_NUMBER).
>
> This agrees with how I read F2023:
>
> R926: image-selector  is
>   lbracket cosubscript-list [ , image-selector-spec-list ] rbracket
>
> R928: image-selector-spec  is
>   NOTIFY = notify-variable
> or
>   STAT = stat-variable
> or
>   TEAM = team-value
> or
>   TEAM_NUMBER = scalar-int-expr
>
> > The availability of TEAM_NUMBER is from F2018 onwards, although F2015
> > already defined it. But because F2015 is not present as standard in
> > GFortran I moved it to F2018.
>
> We had a f2008ts for TS29113 as an intermediate version, but this is now
> the same as f2018 (see options.cc).  I would rather not refer to F2015,
> this sounds outdated to me...  F2018 is the right thing.
>
> I would also explicitly refer to the *intrinsic module* ISO_FORTRAN_ENV
> in the following error message, as we do that elsewhere:
>
> +   gfc_error ("TEAM argument at %L must be of TEAM_TYPE from "
> +  "ISO_FORTRAN_ENV module, found %s",
> +  &ar->team->where,
> +  gfc_basic_typename (ar->team->ts.type));
>
>
> > Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
>
> Besides some spelling nits, this is OK.
>
> Note: I am not a native speaker, but please check the following:
>
> "indexes" -> indices,
> "coindexes" -> coindices (or co-indices?)
>
> (you wont find any "indexes" in the standard document)
>
> "coindexed" is correct.
>
> > I have seen that in the PR also FORM TEAM and fellows is used, but left them
> > out of the test, because those are addressed in PR87326. That PR is not yet
> > merged. I intent to rebase, complete/adapt and merge it next. Then also
> > caf_single gets support for team expressions. And of course OpenCoarrays.
>
> This is fine.  Let's go step by step.
>
> Thanks for the patch!
>
> Harald
>
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>


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

Re: [PATCH] c++, v2: Evaluate immediate invocation call arguments with mce_true [PR119150]

[Jason Merrill]

On 3/12/25 11:38 AM, Jakub Jelinek wrote:

On Wed, Mar 12, 2025 at 09:01:17AM -0400, Jason Merrill wrote:

Why not use new_ctx for this instead of creating another copy?

I would think once we see that we have an immediate function, we want to go
ahead and set ctx->manifestly_const_eval and new_call->manifestly_const_eval
to true.  It looks like we currently cache immediate invocations separately
depending on whether they're in an enclosing immediate function context,
which seems redundant.

Incidentally, I don't remember why we need a separate call_ctx either.


So like this then?
Passes
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 make check-g++ 
RUNTESTFLAGS="dg.exp=consteval*"
ok if it passes full bootstrap/regtest?


OK.


2025-03-12  Jakub Jelinek  

PR c++/119150
* constexpr.cc (cxx_eval_call_expression): For
DECL_IMMEDIATE_FUNCTION_P (fun) set manifestly_const_eval in new_ctx
and new_call to mce_true and set ctx to &new_ctx.

* g++.dg/cpp2a/consteval41.C: New test.

--- gcc/cp/constexpr.cc.jj  2025-03-01 09:13:17.694075636 +0100
+++ gcc/cp/constexpr.cc 2025-03-12 16:30:29.376492168 +0100
@@ -3077,6 +3077,15 @@ cxx_eval_call_expression (const constexp
ctx->global->put_value (new_ctx.object, ctor);
ctx = &new_ctx;
  }
+  /* An immediate invocation is manifestly constant evaluated including the
+ arguments of the call, so use mce_true even for the argument
+ evaluation.  */
+  if (DECL_IMMEDIATE_FUNCTION_P (fun))
+{
+  new_ctx.manifestly_const_eval = mce_true;
+  new_call.manifestly_const_eval = mce_true;
+  ctx = &new_ctx;
+}
  
/* We used to shortcut trivial constructor/op= here, but nowadays

   we can only get a trivial function here with -fno-elide-constructors.  */
--- gcc/testsuite/g++.dg/cpp2a/consteval41.C.jj 2025-03-07 13:39:34.526101144 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/consteval41.C2025-03-07 13:38:38.128871572 
+0100
@@ -0,0 +1,37 @@
+// PR c++/119150
+// { dg-do run { target c++20 } }
+
+consteval bool
+foo (bool x)
+{
+  return x;
+}
+
+constexpr bool
+bar ()
+{
+#if __cpp_if_consteval >= 202106L
+  if consteval
+{
+  return true;
+}
+  else
+{
+  return false;
+}
+#else
+  return __builtin_is_constant_evaluated ();
+#endif
+}
+
+int
+main ()
+{
+  bool a = false;
+  a = foo (bar ());
+  if (!a)
+__builtin_abort ();
+  bool b = foo (bar ());
+  if (!b)
+__builtin_abort ();
+}


Jakub

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

[Qing Zhao]

> On Mar 10, 2025, at 15:34, Martin Uecker  wrote:
> 
> Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall:
>> 
> 
> ...
> 
>> That said, my preference is still to just give preference to the field name,
>> which sidesteps any need for disambiguation syntax and avoids this whole
>> problem where structs can be broken by just adding a global variable that
>> happens to collide with a field.
> 
> I don't think it is a good idea when the 'n' in 'buf' refers to the
> previous global 'n' coming before and the 'n' in attribute 
> refers to a member 'n' coming later in the following example.
> 
> constexpr int n = 1;
> 
> struct foo {
>  char *p [[gnu::counted_by(n)]];
>  char buf[n];
>  int n;
> };
> 
> How are you going to explain this to anyone?
> 
> 
> And neither global names nor struct members may always be under
> the control of the programmer.  Also that simply bringing
> a new identifier into scope can break code elsewhere worries me.
> 
> 
> Finally, the following does not even compile in C++.
> 
> struct foo {
>  char buf[n];
>  const static int n = 2;
> };
> 
> While the next example is also ok in C++.
> 
> constexpr int n = 2;
> 
> struct foo {
>  char buf[n];
> };
> 
> With both declarations of 'n' the example has UB in C++. 
> So I am not convinced the proposed rules make a lot
> of sense for C++ either.
> 
> 
> Disambiguation with '__self__.'  completely avoids all these issues
> while keeping the door open for later improvements.  
> 
> I still think one could use designator syntax, i.e. '.n', which
> would be clearer and intuitive for both C and C++ programmers.

I think the major reason to use __self.n instead of .n is:

The dot (.) operator, i.e., the member access operator in C, is used to access 
the member of an _instance_ of 
a structure/union.
We should declare a variable with a structure type first, and then append this 
member access operator to this 
variable and followed by the member name to access the member, and then use it 
in the expressions. 

To me, this is clearer. But I am okay with the designator syntax. 

Qing

> 
> 
> Martin
> 
> 
> 
> 
> 

[PATCH] aarch64: xfail pr109072_1.c's s16x4_2 [PR117092]

[Andrew Pinski]

The fix for this depends on much more infrastructure which won't
be done for another few weeks. Pengxuan is working on the fix for GCC 16.
So let's xfail the testcase since it is a minor code quality regression.
we get:
```
moviv0.2s, 0
ins v0.h[0], w0
```
vs what we should get:
```
and x0, x0, 65535
fmovd0, x0
```
or
```
fmovh0, x0
```

Tested for aarch64-linux-gnu.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr109072_1.c: xfail s16x4_2.

Signed-off-by: Andrew Pinski 
---
 gcc/testsuite/gcc.target/aarch64/pr109072_1.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/pr109072_1.c 
b/gcc/testsuite/gcc.target/aarch64/pr109072_1.c
index 0fc195a598f..39d80222142 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr109072_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr109072_1.c
@@ -77,7 +77,8 @@ s16x4_1 (int16_t x)
 }
 
 /*
-** s16x4_2:
+PR target/117092
+** s16x4_2: { xfail *-*-* }
 ** ...
 ** fmov[dsh]0, [wx][0-9]+
 ** ret
@@ -127,7 +128,7 @@ s64x2_1 (int64_t x)
 }
 
 /*
-** s64x2_2: { xfail *-*-* }
+** s64x2_2:
 ** fmovd0, x0
 ** ret
 */
-- 
2.43.0

Re: [PATCH] contrib/gcc-changelog: Accept only [PRnnnn] in subject

[Jonathan Wakely]

On Wed, 12 Mar 2025 at 09:55, Jakub Jelinek  wrote:
>
> On Wed, Mar 12, 2025 at 10:49:58AM +0100, Christophe Lyon wrote:
> > On Wed, 12 Mar 2025 at 08:05, Richard Biener  
> > wrote:
> > >
> > > On Tue, Mar 11, 2025 at 5:58 PM Christophe Lyon
> > >  wrote:
> > > >
> > > > In https://gcc.gnu.org/contribute.html#patches we ask to use [PR]
> > > > without the Bugzilla component identifier and with no space between
> > > > 'PR' and the number, but git_check_commit.py accepts all forms.  The
> > > > patch enforces what we document.
> > > >
> > > > Note that this would reject a few of the recent commits.
> > >
> > > Why would we be this restrictive?  I personally am using
> >
> > Well, someone made me realize that I should have used [PR] rather
> > than (PR ) in a recent commit, as documented in "Contributing to
> > GCC".
> >
> > Since I use gcc-verify, I looked at why I missed that, and hence
> > proposed this patch, so that our tools match what we document
> >
> > >
> > > bugzilla-component/number - description
> > >
> > > IMO 'PR' is redundant and the component helps screening for area of
> > > maintenance.
>
> The documented style is
> bugzilla-component: description [PRnumber]

And so I do think we should reject (PR nnn) at the end, for example.

Maybe the other checks don't need to be so strict, I don't feel
strongly about that.

> (it doesn't need to be exactly bugzilla-component, though sometimes the
> component and bugzilla-component are the same thing).
> I believe it has been discussed on the mailing lists before it was
> added to contribute.html.
>
> Jakub
>

[PATCH v2] c++: ICE with aligned member and trivial assign op [PR117512]

[Marek Polacek]

On Wed, Mar 12, 2025 at 12:28:58AM -0400, Jason Merrill wrote:
> On 3/10/25 6:31 PM, Marek Polacek wrote:
> > build_over_call has:
> > 
> >   t = build2 (MODIFY_EXPR, void_type_node,
> >   build2 (MEM_REF, array_type, arg0, alias_set),
> >   build2 (MEM_REF, array_type, arg, alias_set));
> >   val = build2 (COMPOUND_EXPR, TREE_TYPE (to), t, to);
> > 
> > which creates an expression that can look like:
> > 
> >d = MEM  [(struct A *)&TARGET_EXPR  >  = MEM  [(struct A *)(const struct A &) &e],
> >TARGET_EXPR 
> > 
> > that is, a COMPOUND_EXPR where a TARGET_EXPR is used twice, and its
> > address is taken in the left-hand side operand, so it can't be elided.
> > But set_target_expr_eliding simply recurses on the second operand of
> > a COMPOUND_EXPR and marks the TARGET_EXPR as eliding.  This then causes
> > a crash.
> 
> The problem is with build_over_call returning a prvalue (TARGET_EXPR) when
> operator= should return an lvalue.

Ah yes.  I wish the compiler/testsuite had given me a slap on the wrist.

> I guess the issue is the call to cp_build_fold_indirect_ref (argarray[0])
> messing up the value category.

Yes.  Instead of an lvalue we were returning a clk_class prvalue.

> Perhaps the do_fold code in that function should only happen if the result
> is an lvalue.

Like this?

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

-- >8 --
build_over_call has:

  t = build2 (MODIFY_EXPR, void_type_node,
  build2 (MEM_REF, array_type, arg0, alias_set),
  build2 (MEM_REF, array_type, arg, alias_set));
  val = build2 (COMPOUND_EXPR, TREE_TYPE (to), t, to);

which creates an expression that can look like:

  d = MEM  [(struct A *)&TARGET_EXPR  [(struct A *)(const struct A &) &e],
  TARGET_EXPR 

that is, a COMPOUND_EXPR where a TARGET_EXPR is used twice, and its
address is taken in the left-hand side operand, so it can't be elided.
But set_target_expr_eliding simply recurses on the second operand of
a COMPOUND_EXPR and marks the TARGET_EXPR as eliding.  This then causes
a crash.

cp_build_indirect_ref_1 should not be changing the value category.
While *&TARGET_EXPR is an lvalue, folding it into TARGET_EXPR would
render is a prvalue of class type.

PR c++/117512

gcc/cp/ChangeLog:

* typeck.cc (cp_build_indirect_ref_1): Only do the *&e -> e
folding if the result would be an lvalue.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alignas23.C: New test.
* g++.dg/ext/align3.C: New test.
* g++.dg/ext/align4.C: New test.
* g++.dg/ext/align5.C: New test.
---
 gcc/cp/typeck.cc   |  6 +-
 gcc/testsuite/g++.dg/cpp0x/alignas23.C | 15 +++
 gcc/testsuite/g++.dg/ext/align3.C  | 14 ++
 gcc/testsuite/g++.dg/ext/align4.C  | 14 ++
 gcc/testsuite/g++.dg/ext/align5.C  | 18 ++
 5 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/alignas23.C
 create mode 100644 gcc/testsuite/g++.dg/ext/align3.C
 create mode 100644 gcc/testsuite/g++.dg/ext/align4.C
 create mode 100644 gcc/testsuite/g++.dg/ext/align5.C

diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index fe8aceddffa..4b382b95de1 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -3870,7 +3870,11 @@ cp_build_indirect_ref_1 (location_t loc, tree ptr, 
ref_operator errorstring,
  return error_mark_node;
}
   else if (do_fold && TREE_CODE (pointer) == ADDR_EXPR
-  && same_type_p (t, TREE_TYPE (TREE_OPERAND (pointer, 0
+  && same_type_p (t, TREE_TYPE (TREE_OPERAND (pointer, 0)))
+  /* Don't let this change the value category.  '*&TARGET_EXPR'
+ is an lvalue, but folding it into 'TARGET_EXPR' would turn
+ it into a prvalue of class type.  */
+  && lvalue_p (TREE_OPERAND (pointer, 0)))
/* The POINTER was something like `&x'.  We simplify `*&x' to
   `x'.  */
return TREE_OPERAND (pointer, 0);
diff --git a/gcc/testsuite/g++.dg/cpp0x/alignas23.C 
b/gcc/testsuite/g++.dg/cpp0x/alignas23.C
new file mode 100644
index 000..3c218a3542c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alignas23.C
@@ -0,0 +1,15 @@
+// PR c++/117512
+// { dg-do compile { target c++11 } }
+
+struct A {
+  alignas(sizeof (long long)) int b;
+  ~A ();
+};
+A foo (int);
+
+void
+bar ()
+{
+  A e = { 0 };
+  A d = foo (0) = e;
+}
diff --git a/gcc/testsuite/g++.dg/ext/align3.C 
b/gcc/testsuite/g++.dg/ext/align3.C
new file mode 100644
index 000..6a20dfc57b1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/align3.C
@@ -0,0 +1,14 @@
+// PR c++/117512
+
+struct A {
+  __attribute__((aligned)) int b;
+  ~A ();
+};
+A foo (int);
+
+void
+bar ()
+{
+  A e = { 0 };
+  A d = foo (0) = e;
+}
diff --git a/gcc/testsuite/g++.dg/ext/align4.C 
b/gcc/testsuite/g++.dg/ext/align4.C
new file mod

Re: [PATCH 1/6] [RFC] c: Add front-end hook for related vector type.

[Tejas Belagod]

On 3/10/25 7:21 PM, Richard Biener wrote:

On Sat, 8 Mar 2025, Tejas Belagod wrote:


On 3/8/25 12:55 AM, Tejas Belagod wrote:

On 3/7/25 5:34 PM, Richard Biener wrote:

On Fri, 7 Mar 2025, Tejas Belagod wrote:


On 3/7/25 4:38 PM, Richard Biener wrote:

On Fri, 7 Mar 2025, Tejas Belagod wrote:


Given a vector mode and its corresponding element mode, this new new
language
hook returns a vector type that has properties of the vector mode and
element
type of that of the element mode.  For eg. on AArch64, given VNx16BI and
QImode
it returns VNx16QI i.e. the wider mode to BImode that is an SVE mode.


What's the rationale for this to be a new frontend hook?  It seems
to be a composition of a target hook (related_mode) and a
frontend hook (type_for_mode).


I don't know this part of the FE very well, so pardon if its wrong way to
do
it.

I was trying to find a generic way to determine a wider vtype for a given
vmode in a language-agnostic way. It looks like lang hooks are the generic
way
for the mid-end to communicate to the FE to determine types the FE seems
fit,
so I decided to make it a langhook.


Who is supposed to call this hook and for what reason?  Why would the
frontend be involved here?



Ah, sorry, I should've mentioned. This hook is called in Patch 4/6 during
gimplification (gimplify_compound_lval) that implements the subscript
operator for svbool_t - this hook returns a 'container' type for an n-bit
boolean type which in this case is a byte vector for the 1- bit svbool_t
vector. I involve the FE here in the same principle as for eg. TYPE_FOR_SIZE
as the FE is best-placed to return the right 'container' type as defined by
the language. The type returned by the FE is used to unpack svbool_t to its
container vector type to implement the subscript operator.


And how can it survive without

a default implementation?



I saw a comment in langhooks-def.h that says:

/* Types hooks.  There are no reasonable defaults for most of them,
     so we create a compile-time error instead.  */

So I assumed it was OK to have a NULL default which presumably fails at
build
time when a hook is not defined for a language. Is there a more graceful
way
to remedy this?


Well, you made the default a NULL pointer - what do you do at the use
point of the hook when it's not defined?



True. I saw some of the other type hooks had NULL, so AIUI, I imagined it
could be NULL and it would crash when used for a FE that didn't implement
it. I admit I'm not even sure if this is the right way to do this.

So, before I embarked on a 'default' implementation (which I'm not fully
sure how to do) my main intention was to clarify (via this RFC) if the
langhook approach was indeed the best way for gimple to obtain the related
vtype it needed for the vbool type it was unpacking to do the subscript
operation on?



Thinking about this a bit more, I realize my mistake - I've made this a
langhook only for the purpose of gimplify to communicate to the FE to call
c_common_related_vtype_for_mode (). I think I need to go back to the drawing
board on this one - I'm not so convinced now that this is actually serving a
new langhook need.

If this new 'hook' is just a wrapper for targetm.vectorize.related_mode () and
type_for_mode () I can probably just call them directly during gimplify or
c-common.cc instead of inventing this new hook.


That was my thinking.  The alternative is to (pre-)gimplify this either
during genericization or in the already existing gimplify_expr
langhook.  Or perform the "decay" as part of GENERIC building.



When I tried to decay svbool to char[] during genericization, it is 
quite straighforward for svbool[] reads, but for writes I need to 
introduce a temporary (because VEC_CONVERT IFN can't be an lvalue) and I 
don't know if Generic is too early to allow for introducing temporaries.


If I leave the decay too late till gimplification of the base expression 
of svbool happens in gimplify_compound_lval (), it becomes a bit tedious 
to rewrite parent nodes while walking back up the tree from the base 
expression - hence the hybrid approach to decay.


Do you think leaving the tree in a partially rewritten state until 
gimplification can cause consistency checks to fail?


Thanks,
Tejas.


Richard.


Thanks for your reviews - I think I might be able to drop this patch and merge
the necessary parts into later ones in the series!

Thanks,
Tejas.

[committed] arm: testsuite: remove gcc.target/arm/lp1243022.c [PR117931]

[Richard Earnshaw]

This test has been failing since gcc-6.  The test was always very
fragile anyway since it relied on an auto-inc being created and then
split by the subreg2 (later the subreg3) pass.  But the code to get
precisely these conditions was very long-winded and unlikely to be
immune to other changes in the compiler (as proved to be the case).

There's no obvious way to recreate the exact conditions we were
testing for, so just remove the test.

gcc/testsuite:

PR target/117931
* gcc.target/arm/lp1243022.c: Delete non-functional test.
---
 gcc/testsuite/gcc.target/arm/lp1243022.c | 202 ---
 1 file changed, 202 deletions(-)
 delete mode 100644 gcc/testsuite/gcc.target/arm/lp1243022.c

diff --git a/gcc/testsuite/gcc.target/arm/lp1243022.c 
b/gcc/testsuite/gcc.target/arm/lp1243022.c
deleted file mode 100644
index 11025eebd71..000
--- a/gcc/testsuite/gcc.target/arm/lp1243022.c
+++ /dev/null
@@ -1,202 +0,0 @@
-/* { dg-do compile { target arm_thumb2 } } */
-/* { dg-options "-O2 -fdump-rtl-subreg2" } */
-
-/* { dg-final { scan-rtl-dump "REG_INC" "subreg2" { target { ! arm_neon } } } 
} */
-struct device;
-typedef unsigned int __u32;
-typedef unsigned long long u64;
-typedef __u32 __le32;
-typedef u64 dma_addr_t;
-typedef unsigned gfp_t;
-int dev_warn (const struct device *dev, const char *fmt, ...);
-struct usb_bus
-{
-struct device *controller;
-};
-struct usb_hcd
-{
-struct usb_bus self;
-};
-struct xhci_generic_trb
-{
-__le32 field[4];
-};
-union xhci_trb
-{
-struct xhci_generic_trb generic;
-};
-struct xhci_segment
-{
-union xhci_trb *trbs;
-dma_addr_t dma;
-};
-struct xhci_ring
-{
-struct xhci_segment *first_seg;
-};
-struct xhci_hcd
-{
-struct xhci_ring *cmd_ring;
-struct xhci_ring *event_ring;
-};
-struct usb_hcd *xhci_to_hcd (struct xhci_hcd *xhci)
-{
-}
-dma_addr_t xhci_trb_virt_to_dma (struct xhci_segment * seg,
-union xhci_trb * trb);
-struct xhci_segment *trb_in_td (struct xhci_segment *start_seg,
-   dma_addr_t suspect_dma);
-int
-xhci_test_trb_in_td (struct xhci_hcd *xhci, struct xhci_segment *input_seg,
-union xhci_trb *start_trb, union xhci_trb *end_trb,
-dma_addr_t input_dma, struct xhci_segment *result_seg,
-char *test_name, int test_number)
-{
-unsigned long long start_dma;
-unsigned long long end_dma;
-struct xhci_segment *seg;
-start_dma = xhci_trb_virt_to_dma (input_seg, start_trb);
-end_dma = xhci_trb_virt_to_dma (input_seg, end_trb);
-{
-dev_warn (xhci_to_hcd (xhci)->self.controller,
-  "%d\n", test_number);
-dev_warn (xhci_to_hcd (xhci)->self.controller,
-  "Expected seg %p, got seg %p\n", result_seg, seg);
-}
-}
-int
-xhci_check_trb_in_td_math (struct xhci_hcd *xhci, gfp_t mem_flags)
-{
-struct
-{
-dma_addr_t input_dma;
-struct xhci_segment *result_seg;
-}
-simple_test_vector[] =
-{
-{
-0, ((void *) 0)
-}
-,
-{
-xhci->event_ring->first_seg->dma - 16, ((void *) 0)}
-,
-{
-xhci->event_ring->first_seg->dma - 1, ((void *) 0)}
-,
-{
-xhci->event_ring->first_seg->dma, xhci->event_ring->first_seg}
-,
-{
-xhci->event_ring->first_seg->dma + (64 - 1) * 16,
-xhci->event_ring->first_seg
-}
-,
-{
-xhci->event_ring->first_seg->dma + (64 - 1) * 16 + 1, ((void 
*) 0)}
-,
-{
-xhci->event_ring->first_seg->dma + (64) * 16, ((void *) 0)}
-,
-{
-(dma_addr_t) (~0), ((void *) 0)
-}
-};
-struct
-{
-struct xhci_segment *input_seg;
-union xhci_trb *start_trb;
-union xhci_trb *end_trb;
-dma_addr_t input_dma;
-struct xhci_segment *result_seg;
-}
-complex_test_vector[] =
-{
-{
-.input_seg = xhci->event_ring->first_seg,.start_trb =
-xhci->event_ring->first_seg->trbs,.end_trb =
-&xhci->event_ring->first_seg->trbs[64 - 1],.input_dma =
-xhci->cmd_ring->first_seg->dma,.result_seg = ((void *) 0),
-}
-,
-{
-.input_seg = xhci->event_ring->first_seg,.start_trb =
-xhci->event_ring->first_seg->trbs,.end_trb =
-&xhci->cmd_ring->first_seg->trbs[64 - 1],.input_dma =
-xhci->cmd_ring->first_seg->dma,.result_seg = ((void *) 0),
-}
-,
-{
-.input_seg = xhci->event_ring->first_seg,.start_trb =
-xhci->cmd_ring->first_seg->trbs,.end_trb =
-&xhci->cmd_ring->

Re: [PATCH] LoongArch: Don't use C++17 feature [PR119238]

[Lulu Cheng]

在 2025/3/12 下午9:14, Xi Ruoyao 写道:

Structured binding is a C++17 feature but the GCC code base is in C++14.


I couldn't find the description of the standards followed by GCC code in 
the document yesterday.


Therefore, I assumed that this standard is the same as the default 
standard set during GCC compilation.


Is this described in the documentation?



gcc/ChangeLog:

PR target/119238
* config/loongarch/simd.md (dot_prod):
Stop using structured binding.
---

Ok for trunk?


Ok,thanks!




  gcc/config/loongarch/simd.md | 14 --
  1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/gcc/config/loongarch/simd.md b/gcc/config/loongarch/simd.md
index 8f7e912982e..dd17cd13fc5 100644
--- a/gcc/config/loongarch/simd.md
+++ b/gcc/config/loongarch/simd.md
@@ -809,18 +809,20 @@ (define_expand "dot_prod"
 (any_extend (const_int 0))]
""
  {
-  auto [op0, op1, op2, op3] = operands;
+  rtx *op = operands;
  
-  if (op3 == CONST0_RTX (mode))

+  if (op[3] == CONST0_RTX (mode))
  emit_insn (
-  gen__vmulwev__ (op0, op1, op2));
+  gen__vmulwev__ (op[0], op[1],
+ op[2]));
else
  emit_insn (
-  gen__vmaddwev__ (op0, op3, op1,
-  op2));
+  gen__vmaddwev__ (op[0], op[3],
+  op[1], op[2]));
  
emit_insn (

-gen__vmaddwod__ (op0, op0, op1, op2));
+gen__vmaddwod__ (op[0], op[0],
+op[1], op[2]));
DONE;
  })
  

Re: [PATCH] LoongArch: Don't use C++17 feature [PR119238]

[Andrew Pinski]

On Wed, Mar 12, 2025 at 6:23 PM Lulu Cheng  wrote:
>
>
> 在 2025/3/12 下午9:14, Xi Ruoyao 写道:
> > Structured binding is a C++17 feature but the GCC code base is in C++14.
>
> I couldn't find the description of the standards followed by GCC code in
> the document yesterday.
>
> Therefore, I assumed that this standard is the same as the default
> standard set during GCC compilation.
>
> Is this described in the documentation?

yes it is described right here:
https://gcc.gnu.org/install/prerequisites.html

```
ISO C++14 compiler

Necessary to bootstrap GCC. GCC 5.4 or newer has sufficient support
for used C++14 features.

Versions of GCC prior to 15 allow bootstrapping with an ISO C++11
compiler, versions prior to 10.5 allow bootstrapping with an ISO C++98
compiler, and versions prior to 4.8 allow bootstrapping with an ISO
C89 compiler.

If you need to build an intermediate version of GCC in order to
bootstrap current GCC, consider GCC 9.5: it can build the current Ada
and D compilers, and was also the version that declared C++17 support
stable.
```

Notice it says C++ 2014.

Thanks,
Andrew

>
> >
> > gcc/ChangeLog:
> >
> >   PR target/119238
> >   * config/loongarch/simd.md (dot_prod):
> >   Stop using structured binding.
> > ---
> >
> > Ok for trunk?
>
> Ok,thanks!
>
>
> >
> >   gcc/config/loongarch/simd.md | 14 --
> >   1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/gcc/config/loongarch/simd.md b/gcc/config/loongarch/simd.md
> > index 8f7e912982e..dd17cd13fc5 100644
> > --- a/gcc/config/loongarch/simd.md
> > +++ b/gcc/config/loongarch/simd.md
> > @@ -809,18 +809,20 @@ (define_expand "dot_prod"
> >  (any_extend (const_int 0))]
> > ""
> >   {
> > -  auto [op0, op1, op2, op3] = operands;
> > +  rtx *op = operands;
> >
> > -  if (op3 == CONST0_RTX (mode))
> > +  if (op[3] == CONST0_RTX (mode))
> >   emit_insn (
> > -  gen__vmulwev__ (op0, op1, op2));
> > +  gen__vmulwev__ (op[0], op[1],
> > +   op[2]));
> > else
> >   emit_insn (
> > -  gen__vmaddwev__ (op0, op3, op1,
> > -op2));
> > +  gen__vmaddwev__ (op[0], op[3],
> > +op[1], op[2]));
> >
> > emit_insn (
> > -gen__vmaddwod__ (op0, op0, op1, 
> > op2));
> > +gen__vmaddwod__ (op[0], op[0],
> > +  op[1], op[2]));
> > DONE;
> >   })
> >
>

Re: [PATCH] libiberty: move DW_LANG_* definitions to dwarf2.def

[Simon Marchi]

Ping.

On 2/20/25 10:51 AM, Simon Marchi wrote:
> [Note: I don't have push access to gcc, so if approved, please push it
>  on my behalf, thanks.]
> 
> I need to have a "DW_LANG_* to string" function for a change I'm making
> in binutils-gdb.  I'm sending this patch to gcc first, once merged I'll
> sync it to binutils-gdb.
> 
>   - move the "DW_LANG_*" definitions from dwarf2.h to dwarf2.def
>   - add the necessary macros in dwarf2.h to generate the enumeration
>   - add the necessary macros in dwarfnames.c to generate the "to string"
> function
> 
> include/ChangeLog:
> 
> * dwarf2.h (DW_LANG, DW_FIRST_LANG, DW_END_LANG): Define then
> undefine.
> (enum dwarf_source_language): Remove.
> (get_DW_LANG_name): Declare.
> * dwarf2.def: Define DW_LANG_* constants.
> 
> libiberty/ChangeLog:
> 
> * dwarfnames.c (DW_FIRST_LANG, DW_END_LANG, DW_LANG): Define
> then undefine.
> ---
>  include/dwarf2.def |  89 +++
>  include/dwarf2.h   | 103 +
>  libiberty/dwarfnames.c |   9 
>  3 files changed, 109 insertions(+), 92 deletions(-)
> 
> diff --git a/include/dwarf2.def b/include/dwarf2.def
> index 989f078041d4..4326e63646ee 100644
> --- a/include/dwarf2.def
> +++ b/include/dwarf2.def
> @@ -830,3 +830,92 @@ DW_UT (DW_UT_split_type, 0x06)
>  DW_UT (DW_UT_lo_user, 0x80)
>  DW_UT (DW_UT_hi_user, 0xff)
>  DW_END_UT
> +
> +DW_FIRST_LANG (DW_LANG_C89, 0x0001)
> +DW_LANG (DW_LANG_C, 0x0002)
> +DW_LANG (DW_LANG_Ada83, 0x0003)
> +DW_LANG (DW_LANG_C_plus_plus, 0x0004)
> +DW_LANG (DW_LANG_Cobol74, 0x0005)
> +DW_LANG (DW_LANG_Cobol85, 0x0006)
> +DW_LANG (DW_LANG_Fortran77, 0x0007)
> +DW_LANG (DW_LANG_Fortran90, 0x0008)
> +DW_LANG (DW_LANG_Pascal83, 0x0009)
> +DW_LANG (DW_LANG_Modula2, 0x000a)
> +/* DWARF 3.  */
> +DW_LANG (DW_LANG_Java, 0x000b)
> +DW_LANG (DW_LANG_C99, 0x000c)
> +DW_LANG (DW_LANG_Ada95, 0x000d)
> +DW_LANG (DW_LANG_Fortran95, 0x000e)
> +DW_LANG (DW_LANG_PLI, 0x000f)
> +DW_LANG (DW_LANG_ObjC, 0x0010)
> +DW_LANG (DW_LANG_ObjC_plus_plus, 0x0011)
> +DW_LANG (DW_LANG_UPC, 0x0012)
> +DW_LANG (DW_LANG_D, 0x0013)
> +/* DWARF 4.  */
> +DW_LANG (DW_LANG_Python, 0x0014)
> +/* DWARF 5.  */
> +DW_LANG (DW_LANG_OpenCL, 0x0015)
> +DW_LANG (DW_LANG_Go, 0x0016)
> +DW_LANG (DW_LANG_Modula3, 0x0017)
> +DW_LANG (DW_LANG_Haskell, 0x0018)
> +DW_LANG (DW_LANG_C_plus_plus_03, 0x0019)
> +DW_LANG (DW_LANG_C_plus_plus_11, 0x001a)
> +DW_LANG (DW_LANG_OCaml, 0x001b)
> +DW_LANG (DW_LANG_Rust, 0x001c)
> +DW_LANG (DW_LANG_C11, 0x001d)
> +DW_LANG (DW_LANG_Swift, 0x001e)
> +DW_LANG (DW_LANG_Julia, 0x001f)
> +DW_LANG (DW_LANG_Dylan, 0x0020)
> +DW_LANG (DW_LANG_C_plus_plus_14, 0x0021)
> +DW_LANG (DW_LANG_Fortran03, 0x0022)
> +DW_LANG (DW_LANG_Fortran08, 0x0023)
> +DW_LANG (DW_LANG_RenderScript, 0x0024)
> +DW_LANG (DW_LANG_BLISS, 0x0025)
> +/* Post DWARF 5 additions to the DWARF set.
> +See https://dwarfstd.org/languages.html .  */
> +DW_LANG (DW_LANG_Kotlin, 0x0026)
> +DW_LANG (DW_LANG_Zig, 0x0027)
> +DW_LANG (DW_LANG_Crystal, 0x0028)
> +DW_LANG (DW_LANG_C_plus_plus_17, 0x002a)
> +DW_LANG (DW_LANG_C_plus_plus_20, 0x002b)
> +DW_LANG (DW_LANG_C17, 0x002c)
> +DW_LANG (DW_LANG_Fortran18, 0x002d)
> +DW_LANG (DW_LANG_Ada2005, 0x002e)
> +DW_LANG (DW_LANG_Ada2012, 0x002f)
> +DW_LANG (DW_LANG_HIP, 0x0030)
> +DW_LANG (DW_LANG_Assembly, 0x0031)
> +DW_LANG (DW_LANG_C_sharp, 0x0032)
> +DW_LANG (DW_LANG_Mojo, 0x0033)
> +DW_LANG (DW_LANG_GLSL, 0x0034)
> +DW_LANG (DW_LANG_GLSL_ES, 0x0035)
> +DW_LANG (DW_LANG_HLSL, 0x0036)
> +DW_LANG (DW_LANG_OpenCL_CPP, 0x0037)
> +DW_LANG (DW_LANG_CPP_for_OpenCL, 0x0038)
> +DW_LANG (DW_LANG_SYCL, 0x0039)
> +DW_LANG (DW_LANG_C_plus_plus_23, 0x003a)
> +DW_LANG (DW_LANG_Odin, 0x003b)
> +DW_LANG (DW_LANG_P4, 0x003c)
> +DW_LANG (DW_LANG_Metal, 0x003d)
> +DW_LANG (DW_LANG_C23, 0x003e)
> +DW_LANG (DW_LANG_Fortran23, 0x003f)
> +DW_LANG (DW_LANG_Ruby, 0x0040)
> +DW_LANG (DW_LANG_Move, 0x0041)
> +DW_LANG (DW_LANG_Hylo, 0x0042)
> +
> +DW_LANG (DW_LANG_lo_user, 0x8000)/* Implementation-defined range start.  
> */
> +DW_LANG (DW_LANG_hi_user, 0x)/* Implementation-defined range start.  
> */
> +
> +/* MIPS.  */
> +DW_LANG (DW_LANG_Mips_Assembler, 0x8001)
> +/* UPC.  */
> +DW_LANG (DW_LANG_Upc, 0x8765)
> +/* HP extensions.  */
> +DW_LANG (DW_LANG_HP_Bliss, 0x8003)
> +DW_LANG (DW_LANG_HP_Basic91, 0x8004)
> +DW_LANG (DW_LANG_HP_Pascal91, 0x8005)
> +DW_LANG (DW_LANG_HP_IMacro, 0x8006)
> +DW_LANG (DW_LANG_HP_Assembler, 0x8007)
> +
> +/* Rust extension, but replaced in DWARF 5.  */
> +DW_LANG (DW_LANG_Rust_old, 0x9000)
> +DW_END_LANG
> diff --git a/include/dwarf2.h b/include/dwarf2.h
> index 37fbc368..43744818611d 100644
> --- a/include/dwarf2.h
> +++ b/include/dwarf2.h
> @@ -56,6 +56,7 @@
>  #define DW_IDX(name, value) , name = value
>  #define DW_IDX_DUP(name, value) , name = value
>  #define DW_UT(name, value) , name = value
> +#define DW_LANG(name, value) , name = value
>  
>  #define DW_FIRST

[PATCH 0/2] Two match.pd folds for sve/pr98119.c

[Richard Sandiford]

gcc.target/aarch64/sve/pr98119.c has been failing since r15-268.
The test expects pointer alignment to be done with a plain AND,
but that no longer happens.

It was combine that previously generated the ANDs, but I think it's
fair to argue that it isn't combine's job to handle this case.
The test's gimple output is pretty suboptimal.

The current gimple is:

  _21 = (unsigned long) vectp_x.4_22;
  _20 = _21 >> 1;
  _17 = (unsigned int) _20;
  _16 = _17 & 15;
  _9 = (sizetype) _16;
  _18 = (unsigned int) _9;
  _32 = _18 w* 2;
  _33 = -_32;// -(_21 & 30)
  vectp_x.6_10 = x_13(D) + _33;  // x_31(D) & ~30
  _41 = 18446744073709551584 - _32;  // -32 - (_21 & 30)
  vectp_x.9_38 = x_13(D) + _41;  // (x_31(D) - 32) & ~30
  _55 = _16 + 1000;

This series adds two groups of folds that together give:

  _21 = (unsigned long) vectp_x.4_22;
  _20 = _21 >> 1;
  _17 = (unsigned int) _20;
  _16 = _17 & 15;
  vectp_x.6_10 = x_13(D) & -31B;
  _18 = x_13(D) & -31B;
  vectp_x.9_38 = _18 + 18446744073709551584;
  _55 = _16 + 1000;

The duplicate "x_13(D) & -31B"s are unfortunate, but RTL CSE does get
rid of them.

I asked on IRC whether new folds to fix this kind of regression were
acceptable, but I admit that the patches ended up being bigger than
I'd imagined.  I'll fully understand if they seem like too much for
stage 4 after all.

Bootstrapped & regression-tested on aarch64-linux-gnu.  I'll also
test on x86_64-linux-gnu.  OK to install if that passes?

Richard


Richard Sandiford (2):
  match.pd: Fold ((X >> C1) & C2) * (1 << C1)
  match.pd: Extend pointer alignment folds

 gcc/match.pd | 56 +
 gcc/testsuite/gcc.dg/fold-mul-and-lshift-1.c | 59 ++
 gcc/testsuite/gcc.dg/fold-mul-and-lshift-2.c | 15 
 gcc/testsuite/gcc.dg/pointer-arith-11.c  | 39 ++
 gcc/testsuite/gcc.dg/pointer-arith-12.c  | 82 
 5 files changed, 251 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/fold-mul-and-lshift-1.c
 create mode 100644 gcc/testsuite/gcc.dg/fold-mul-and-lshift-2.c
 create mode 100644 gcc/testsuite/gcc.dg/pointer-arith-11.c
 create mode 100644 gcc/testsuite/gcc.dg/pointer-arith-12.c

-- 
2.25.1

[PATCH 1/2] match.pd: Fold ((X >> C1) & C2) * (1 << C1)

[Richard Sandiford]

Using a combination of rules, we were able to fold

  ((X >> C1) & C2) * (1 << C1)  -->  X & (C2 << C1)

if everything was done at the same precision, but we couldn't fold
it if the AND was done at a different precision.  The optimisation is
often (but not always) valid for that case too.

This patch adds a dedicated rule for the case where different precisions
are involved.

An alternative would be to extend the individual folds that together
handle the same-precision case so that those rules handle differing
precisions.  But the risk is that that could replace narrow operations
with wide operations, which would be especially harmful on targets
like avr.  It's also not obviously free of cycles.

I also wondered whether the converts should be non-optional.

gcc/
* match.pd: Fold ((X >> C1) & C2) * (1 << C1) to X & (C2 << C1).

gcc/testsuite/
* gcc.dg/fold-mul-and-lshift-1.c: New test.
* gcc.dg/fold-mul-and-lshift-2.c: Likewise.
---
 gcc/match.pd | 29 ++
 gcc/testsuite/gcc.dg/fold-mul-and-lshift-1.c | 59 
 gcc/testsuite/gcc.dg/fold-mul-and-lshift-2.c | 15 +
 3 files changed, 103 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/fold-mul-and-lshift-1.c
 create mode 100644 gcc/testsuite/gcc.dg/fold-mul-and-lshift-2.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 5c679848bdf..3197d1cac75 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -5231,6 +5231,35 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (if (mask)
   (bit_op (shift (convert @0) @1) { mask; })))
 
+/* Fold ((X >> C1) & C2) * (1 << C1) into X & (C2 << C1), including cases where
+   the & happens in a different type.  It is the conversion case that isn't
+   a composition of other folds.
+
+   Let the type of the * and >> be T1 and the type of the & be T2.
+   The fold is valid if the conversion to T2 preserves all information;
+   that is, if T2 is wider than T1 or drops no more than C1 bits from T1.
+   In that case, the & might operate on bits that are dropped by the
+   later conversion to T1 and the multiplication by (1 << C1), but those
+   bits are also dropped by ANDing with C2 << C1 (converted to T1).
+
+   If the conversion to T2 is not information-preserving, we have to be
+   careful about the later conversion to T1 acting as a sign extension.
+   We need either T2 to be unsigned or the top (sign) bit of C2 to be clear.
+   That is equivalent to testing whether C2 is nonnegative.  */
+(simplify
+ (mult
+  (convert? (bit_and (convert? (rshift @0 INTEGER_CST@1)) INTEGER_CST@2))
+  INTEGER_CST@3)
+ (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
+  (with { auto prec = element_precision (type); }
+   (if (wi::ltu_p (wi::to_widest (@1), prec))
+(with { auto shift = tree_to_uhwi (@1); }
+ (if ((prec <= element_precision (TREE_TYPE (@2)) + shift
+  || wi::to_widest (@2) >= 0)
+ && wi::to_wide (@3) == wi::set_bit_in_zero (shift, prec))
+  (with { auto mask = wide_int::from (wi::to_wide (@2), prec, UNSIGNED); }
+   (bit_and @0 { wide_int_to_tree (type, mask << shift); }
+
 /* ~(~X >> Y) -> X >> Y (for arithmetic shift).  */
 (simplify
  (bit_not (convert1?:s (rshift:s (convert2?@0 (bit_not @1)) @2)))
diff --git a/gcc/testsuite/gcc.dg/fold-mul-and-lshift-1.c 
b/gcc/testsuite/gcc.dg/fold-mul-and-lshift-1.c
new file mode 100644
index 000..b1ce10495e3
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/fold-mul-and-lshift-1.c
@@ -0,0 +1,59 @@
+/* { dg-do compile { target lp64 } } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump-not { >> } "optimized" } } */
+/* { dg-final { scan-tree-dump-not { \* } "optimized" } } */
+
+unsigned int
+f1 (unsigned int x)
+{
+x >>= 1;
+unsigned long y = x;
+y &= 255;
+x = y;
+x *= 2;
+return x;
+}
+
+unsigned int
+f2 (unsigned int x)
+{
+x >>= 1;
+unsigned long y = x;
+y &= -2UL;
+x = y;
+x *= 2;
+return x;
+}
+
+unsigned int
+f3 (unsigned int x)
+{
+x >>= 1;
+unsigned short y = x;
+y &= 255;
+x = y;
+x *= 2;
+return x;
+}
+
+unsigned int
+f4 (unsigned int x)
+{
+x >>= 1;
+short y = x;
+y &= (unsigned short) ~0U >> 1;
+x = y;
+x *= 2;
+return x;
+}
+
+unsigned int
+f5 (unsigned int x)
+{
+x >>= 16;
+short y = x;
+y &= -2;
+x = y;
+x *= 1 << 16;
+return x;
+}
diff --git a/gcc/testsuite/gcc.dg/fold-mul-and-lshift-2.c 
b/gcc/testsuite/gcc.dg/fold-mul-and-lshift-2.c
new file mode 100644
index 000..86eabef0fef
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/fold-mul-and-lshift-2.c
@@ -0,0 +1,15 @@
+/* { dg-do compile { target int32 } } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump { >> 15;} "optimized" } } */
+/* { dg-final { scan-tree-dump { \* 32768;} "optimized" } } */
+
+unsigned int
+f1 (unsigned int x)
+{
+x >>= 15;
+short y = x;
+y &= -2;
+x = y;
+x *= 1 << 15;
+r

Re: [PATCH] libstdc++: Optimize basic_format_parse_context::__check_dynamic_spec_types

[Jonathan Wakely]

On Wed, 12 Mar 2025 at 07:59, Tomasz Kaminski  wrote:
>
>
>
> On Tue, Mar 11, 2025 at 11:46 PM Jonathan Wakely  wrote:
>>
>> This change makes the consteval function slightly faster to compile.
>> Instead of keeping the counts in an array and looping over that array,
>> we can just keep a sum of how many valid types are present, and check
>> that it equals the total number of types in the pack. We can also avoid
>> doing the check entirely for the common cases where the call comes from
>> check_dynamic_spec_integer or check_dynamic_spec_string, because those
>> always use valid lists of types.
>>
>> The diagnostic is slightly worse now, because there's only a single
>> "invalid template argument types" string that appears in the output,
>> where previously we had either "non-unique template argument type" or
>> "disallowed template argument type" depending on the failure mode.
>>
>> Given that most users will never use this function directly, and
>> probably won't use invalid types anyway, the inferior diagnostic seems
>> acceptable.
>>
>> libstdc++-v3/ChangeLog:
>>
>> * include/std/format (basic_format_parse_context::__check_types):
>> New variable template and partial specializations.
>> (basic_format_parse_context::__check_dynamic_spec_types):
>> Simplify for faster compilation.
>> (basic_format_parse_context::check_dynamic_spec): Only use
>> __check_dynamic_spec_types when __check_types is true. Use it as
>> the condition for a constexpr if statement instead of as the
>> initializer for a constexpr variable.
>> (basic_format_parse_context::check_dynamic_spec_string): Use
>> _CharT instead of char_type consistently.
>> ---
>>
>> Tested x86_64-linux.
>>
>>  libstdc++-v3/include/std/format | 81 +++--
>>  1 file changed, 47 insertions(+), 34 deletions(-)
>>
>> diff --git a/libstdc++-v3/include/std/format 
>> b/libstdc++-v3/include/std/format
>> index 0d6cc7f6bef..6269cbb80e6 100644
>> --- a/libstdc++-v3/include/std/format
>> +++ b/libstdc++-v3/include/std/format
>> @@ -305,41 +305,51 @@ namespace __format
>>constexpr void
>>check_dynamic_spec_string(size_t __id) noexcept
>>{
>> -   check_dynamic_spec> basic_string_view<_CharT>>(__id);
>> +   check_dynamic_spec>(__id);
>>}
>>
>>  private:
>> -  // Check the Mandates: condition for check_dynamic_spec(n)
>> +  template
>> +   static constexpr bool __once = (is_same_v<_Tp, _Ts> + ...) == 1;
>> +
>> +  // True if we need to call __check_dynamic_spec_types for the pack Ts
>> +  template
>> +   static constexpr bool __check_types = sizeof...(_Ts) > 0;
>> +  // The pack used by check_dynamic_spec_integral is valid, don't check 
>> it.
>> +  // FIXME: simplify these when PR c++/85282 is supported.
>> +  template
>> +   static constexpr bool
>> +   __check_types<_Tp, unsigned, long long, unsigned long long>
>> + = ! is_same_v<_Tp, int>;
>
> These seem to produce wrong answer (false) if the user called 
> check_dynamic_spec, unsigned, long long, unsigned 
> long long>,
> which is a valid set of types.

The variable template __check_types means "do we need to check the
types", so false is the correct answer here. We do not need to check
the types for this list of types, because we know it's a valid set of
types.

The variable template is used to decide whether to call
__check_dynamic_spec_types or to skip calling it.

>>
>> +  // The pack used by check_dynamic_spec_string is valid, don't check 
>> it.
>> +  template
>> +   static constexpr bool
>> +   __check_types<_Tp, basic_string_view<_CharT>>
>> + = ! is_same_v;
>
> As above check_dynamic_spec>.
> I think much batter solution would be to have __check_dynamic_spec 
> private function,
> that would not perform the check at all and will be called without checking 
> from check_dynamic_spec_integrral, e.t.c.
> And in check_dynamic_spec, we would do __check_dynamic_spec_types<_Ts...>() 
> and sizeof..(Ts) > 0, before
> calling __check_dynamic_spec.

Yes I considered that, and that would also work.

>> +
>> +  // Check the Mandates: conditions for check_dynamic_spec(n)
>>template
>> static consteval bool
>> __check_dynamic_spec_types()
>> {
>> - if constexpr (sizeof...(_Ts))
>> -   {
>> - int __counts[] = {
>> -   (is_same_v + ...),
>> -   (is_same_v<_CharT, _Ts> + ...),
>> -   (is_same_v + ...),
>> -   (is_same_v + ...),
>> -   (is_same_v + ...),
>> -   (is_same_v + ...),
>> -   (is_same_v + ...),
>> -   (is_same_v + ...),
>> -   (is_same_v + ...),
>> -   (is_same_v + ...),
>> -   (is_same_v, _Ts> + ...),
>> -   (is_same_v + ...)
>> - };
>> - int __sum = 0;
>> -  

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

[Martin Uecker]

Am Mittwoch, dem 12.03.2025 um 16:20 + schrieb Qing Zhao:
> 
> > On Mar 10, 2025, at 15:34, Martin Uecker  wrote:
> > 
> > Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall:
> > > 
> > 
> > ...
> > 
> > > That said, my preference is still to just give preference to the field 
> > > name,
> > > which sidesteps any need for disambiguation syntax and avoids this whole
> > > problem where structs can be broken by just adding a global variable that
> > > happens to collide with a field.
> > 
> > I don't think it is a good idea when the 'n' in 'buf' refers to the
> > previous global 'n' coming before and the 'n' in attribute 
> > refers to a member 'n' coming later in the following example.
> > 
> > constexpr int n = 1;
> > 
> > struct foo {
> >  char *p [[gnu::counted_by(n)]];
> >  char buf[n];
> >  int n;
> > };
> > 
> > How are you going to explain this to anyone?
> > 
> > 
> > And neither global names nor struct members may always be under
> > the control of the programmer.  Also that simply bringing
> > a new identifier into scope can break code elsewhere worries me.
> > 
> > 
> > Finally, the following does not even compile in C++.
> > 
> > struct foo {
> >  char buf[n];
> >  const static int n = 2;
> > };
> > 
> > While the next example is also ok in C++.
> > 
> > constexpr int n = 2;
> > 
> > struct foo {
> >  char buf[n];
> > };
> > 
> > With both declarations of 'n' the example has UB in C++. 
> > So I am not convinced the proposed rules make a lot
> > of sense for C++ either.
> > 
> > 
> > Disambiguation with '__self__.'  completely avoids all these issues
> > while keeping the door open for later improvements.  
> > 
> > I still think one could use designator syntax, i.e. '.n', which
> > would be clearer and intuitive for both C and C++ programmers.
> 
> I think the major reason to use __self.n instead of .n is:
> 
> The dot (.) operator, i.e., the member access operator in C, is used to 
> access the member of an _instance_ of 
> a structure/union.
> We should declare a variable with a structure type first, and then append 
> this member access operator to this 
> variable and followed by the member name to access the member, and then use 
> it in the expressions. 

For a designator

struct foo { int n; } a = { .n = 1 };

we also refer to a member 'n' of an instance 'a' of a structure type.
The instance is simply implied by the context.

For 

struct foo { int n; char *x __counted_by(.n) };

is also refers to a member of an instance of the struct. The
instance is the 'a' which is later used in an expression 'a.x'
So the instance would again be implied by the context.

So for me this makes perfect sense in both cases (and
for both C and C++)

> 
> To me, this is clearer. But I am okay with the designator syntax. 

I am also okay with __self__ if people have concerns about
resuing the designator syntax.  We could still always drop the
requirement for writing __self__  later. 

Martin

> 
> Qing
> 
> > 
> > 
> > Martin
> > 
> > 
> > 
> > 
> > 
> 

Re: [PATCH] middle-end/119204 - ICE with strcspn folding

[Jakub Jelinek]

On Wed, Mar 12, 2025 at 09:41:01AM -0700, H.J. Lu wrote:
> This caused:
> 
> https://gcc.gnu.org/pipermail/gcc-regression/2025-March/081862.html

This should have been fixed with r15-7981 already.

Jakub

Re: [PATCH] middle-end/119204 - ICE with strcspn folding

[Andrew Pinski]

On Wed, Mar 12, 2025 at 9:43 AM H.J. Lu  wrote:
>
> On Tue, Mar 11, 2025 at 2:58 AM Richard Biener  wrote:
> >
> > The following makes sure to convert the folded expression to the
> > original expression type.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> >
> > Thanks,
> > Richard.
> >
> > PR middle-end/119204
> > * builtins.cc (fold_builtin_strcspn): Preserve the original
> > expression type.
> >
> > * gcc.dg/pr119204.c: New testcase.
> > ---
> >  gcc/builtins.cc |  5 +++--
> >  gcc/testsuite/gcc.dg/pr119204.c | 13 +
> >  2 files changed, 16 insertions(+), 2 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.dg/pr119204.c
> >
> > diff --git a/gcc/builtins.cc b/gcc/builtins.cc
> > index c8841032f03..02556e6615a 100644
> > --- a/gcc/builtins.cc
> > +++ b/gcc/builtins.cc
> > @@ -11360,7 +11360,7 @@ fold_builtin_strcspn (location_t loc, tree expr, 
> > tree s1, tree s2)
> >  {
> >/* Evaluate and ignore argument s2 in case it has
> >  side-effects.  */
> > -  return omit_one_operand_loc (loc, size_type_node,
> > +  return omit_one_operand_loc (loc, TREE_TYPE (expr),
> >size_zero_node, s2);
> >  }
> >
> > @@ -11375,7 +11375,8 @@ fold_builtin_strcspn (location_t loc, tree expr, 
> > tree s1, tree s2)
> >if (!fn)
> > return NULL_TREE;
> >
> > -  return build_call_expr_loc (loc, fn, 1, s1);
> > +  return fold_convert_loc (loc, TREE_TYPE (expr),
> > +  build_call_expr_loc (loc, fn, 1, s1));
> >  }
> >return NULL_TREE;
> >  }
> > diff --git a/gcc/testsuite/gcc.dg/pr119204.c 
> > b/gcc/testsuite/gcc.dg/pr119204.c
> > new file mode 100644
> > index 000..ecbd8dd1c22
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/pr119204.c
> > @@ -0,0 +1,13 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-w" } */
> > +
> > +extern void abort(void);
> > +extern long long strcspn(const char *, const char *);
> > +
> > +void main_test(void) {
> > +  const char *const s1 = "hello world";
> > +  char dst[64], *d2;
> > +
> > +  if (strcspn(++d2 + 5, "") != 5 || d2 != dst + 1)
> > +abort();
> > +}
> > --
> > 2.43.0
>
> This caused:
>
> https://gcc.gnu.org/pipermail/gcc-regression/2025-March/081862.html

Fixed with r15-7981 already.
https://gcc.gnu.org/pipermail/gcc-cvs/2025-March/418506.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677372.html

Thanks,
Andrew

>
> --
> H.J.

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

[Joseph Myers]

On Wed, 12 Mar 2025, Martin Uecker wrote:

> For a designator
> 
> struct foo { int n; } a = { .n = 1 };
> 
> we also refer to a member 'n' of an instance 'a' of a structure type.
> The instance is simply implied by the context.
> 
> For 
> 
> struct foo { int n; char *x __counted_by(.n) };
> 
> is also refers to a member of an instance of the struct. The
> instance is the 'a' which is later used in an expression 'a.x'
> So the instance would again be implied by the context.
> 
> So for me this makes perfect sense in both cases (and
> for both C and C++)

The main concern with the designator syntax is if you try to embed it in 
arbitrary expressions (that is, say that __counted_by takes an expression, 
but with an additional kind of primary-expression .IDENTIFIER that can be 
used as a sub-expression therein).  The above is fine, but

struct foo { int n; char *x __counted_by((struct bar){.n = 1}.n };

leaves an ambiguity of whether ".n = 1" is a designated initializer in the 
struct bar compound literal, or an assignment expression where .n refers 
to the member of the struct foo for which the number of elements of x is 
being counted.  Note that N3188 definitely does not allow .IDENTIFIER as 
part of an expression, only as an alternative to an expression in an array 
declarator.

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

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

[Michael Matz]

Hello,

On Wed, 12 Mar 2025, Martin Uecker wrote:

> > To me, this is clearer. But I am okay with the designator syntax.
> 
> I am also okay with __self__ if people have concerns about resuing the 
> designator syntax.  We could still always drop the requirement for 
> writing __self__ later.

So, __self__ please, pretty please?  ;-))  (And no to ". IDENTIFIER" being 
a primary-expression?)


Ciao,
Michael.

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

[Bill Wendling]

On Mon, Mar 10, 2025 at 11:33 PM Henrik Olsson  wrote:
>
>
>
> On Mar 10, 2025, at 11:04 PM, Martin Uecker  wrote:
>
> Am Montag, dem 10.03.2025 um 19:30 -0400 schrieb John McCall:
>
> On 10 Mar 2025, at 18:30, Martin Uecker wrote:
>
> Am Montag, dem 10.03.2025 um 16:45 -0400 schrieb John McCall:
>
>
>
> ..
>
>
>
> While the next example is also ok in C++.
>
> constexpr int n = 2;
>
> struct foo {
>  char buf[n];
> };
>
> With both declarations of 'n' the example has UB in C++.
> So I am not convinced the proposed rules make a lot
> of sense for C++ either.
>
>
> If C required a diagnostic in your first example, it would actually
> put a fair amount of pressure on the C++ committee to get rid of
> this spurious UB rule.
>
>
> Why would C want a diagnostic here?
>
>
> When I said “your first example”, Martin, I did actually mean your
> first example:
>
>
> Sorry, I meant "there". No reason to be condescending though.
>
> But I think it’s clear that you and I just differ on some basic design
> philosophy, so let’s just end the conversation here.
>
>
> I think the issue that if one does not agree with the
> design decisions made previously for the name lookup rules
> in the C and C++ languages and wants to change those (or
> adding new inconsistent ones), then this is not simply
> a question of language design preferences.
>
> Martin
>
>
> John.
>
> I still think one could use designator syntax, i.e. '.n', which
> would be clearer and intuitive for both C and C++ programmers.
>
>
> This doesn’t really solve the ambiguity problem. If n is a field name,
> a programmer who writes __counted_by(n) almost certainly means to name
> the field. “The proper syntax is .n” is the cause of the bug, not its
> solution.
>
>
> Field names in C are in a different namespace. So far, when you write
> 'n' this *never* refers to field member in any context.  And I have
> never seen anybody request a warning for the examples above. So, no,
> "a programmer almost certainly means this" can not possible be true.
>
> Martin
>
>
> I won't speak for John, but the way I see it you can optimise for 
> theoretically consistent minimalist semantics, or strive to optimise each 
> feature for its most common use cases. That's a difference in design 
> philosophy.

It's not about having consistent minimalist semantics vs. optimizing
for the common case. Qing pointed out that the current way
'counted_by' and related attributes are implemented results in a real
conflict in parsing. She also pointed out that by continuing with the
current design, we're literally adding a new scoping rule to C. This
is a *massive* overreach for a new attribute feature. This won't be
less of an overreach by adding new diagnostics, no matter how helpful
they are. (Especially diagnostics which are suppresable, because once
a project suppresses a diagnostic, it's rarely turned back on.)

> Although I don't think these ambiguities matter in practice (as long as there 
> are workarounds) since their occurrence will be vanishingly rare, the fact 
> that 'n' currently means one thing doesn't mean that it should have to mean 
> the same thing in another context with different design goals, especially 
> when that is a completely new context. The context of "__counted_by(...)" 
> surrounding the expression should be enough to infer what is meant. The fact 
> that code could be structured in a way to mislead the reader is nothing new 
> to C, and when the context where that even could be a concern is largely 
> hypothetical I don't think eliminating it should be a priority.

Qing pointed out in four lines of code how there are two different
token resolution rules being used: one which is reliant upon C's
current scoping rules and the other which requires a completely new
scoping rule. This is no longer a question about what a programmer is
most likely to infer what is meant or if the documentation makes it
clear what's happening or any other ambiguous issues that me and
others put forth before. This is a serious problem. There are
essentially two options we have:

1. Create a proposal to the C standards committee adding an "instance
scope" into the language and use that for the feature, or
2. Find some other way, which doesn't require modifying the base language.

The suggestion is to use "__self" to refer to elements within the
least enclosing, non-anonymous struct, where "__self.name" is a field
in that struct and "name" is a global or shadowed local variable.
There have been other suggestions, such as using a function pointer,
e.g.:

struct b;
size_t do_calc(struct b *);

struct b {
  int num_elems;
  int *buf __counted_by(do_calc); // a pointer to 'struct b' is
implicitly passed in
};

size_t do_calc(struct b *ptr) { ... }

This solves everything, but has the disadvantage of being a bit heavy
handed (though I'd like to see this used for expressions).

We could possibly aid parsing when the 'count' occurs after the
attributed member by adding a declaration:

struct b {
  

[committed] libgcobol: Fix typo in comment

[Jonathan Wakely]

libgcobol/ChangeLog:

* charmaps.cc: Fix typo in comment.
---

Committed as obvious.

 libgcobol/charmaps.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcobol/charmaps.cc b/libgcobol/charmaps.cc
index 3b75c08dd2f..561fe230121 100644
--- a/libgcobol/charmaps.cc
+++ b/libgcobol/charmaps.cc
@@ -250,7 +250,7 @@ cp1252_to_utf8_values[256] =
 0x00f0, 0x00f1, 0x00f2, 0x00f3, 0x00f4, 0x00f5, 0x00f6, 0x00f7, 0x00f8, 
0x00f9, 0x00fa, 0x00fb, 0x00fc, 0x00fd, 0x00fe, 0x00ff, // F0
 };
 
-// This map table doe the reverse UTF-8 conversion back to cp1252
+// This map table does the reverse UTF-8 conversion back to cp1252
 static const std::unordered_maputf8_to_cp1252_values =
 {
 {0x, 0x00}, {0x0001, 0x01}, {0x0002, 0x02}, {0x0003, 0x03}, {0x0004, 
0x04}, {0x0005, 0x05}, {0x0006, 0x06}, {0x0007, 0x07},
-- 
2.48.1

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

[Robin Dapp]

From: Pan Li 

Rearrange the test cases of cond_widen_complicate-3 by different types
into different files, instead of put all types together.  Then we can
easily reduce the range when asm check fails.


I'm not opposed to refactoring but what's the reason for it?  We have a large 
number of similar tests that also include all possible types.  And aren't all 
the tests you touch FAILing anyway right now?  (Due to the combine change...)


--
Regards
Robin

[pushed] contrib: relpath.sh /lib /include [PR119081]

[Jason Merrill]

Applying to trunk.

-- 8< --

Previously, if the common ancestor of the two paths is / we would print the
absolute second argument, but this PR asks for a relative path in that case
as well, which makes sense for the libstdc++.modules.json use case.

PR libstdc++/119081

contrib/ChangeLog:

* relpath.sh: Give relative path even at /.
---
 contrib/relpath.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/contrib/relpath.sh b/contrib/relpath.sh
index ac6b769ef81..1b329fc04a7 100755
--- a/contrib/relpath.sh
+++ b/contrib/relpath.sh
@@ -59,9 +59,9 @@ while [ "${to#$from}" = "$to" ]; do
 from=$(dirname $from);
 back=../$back
 
-if [ "$from" = "/" ]; then
-   echo $to
-   exit 0
+if [ "$from" = / ] && [ "${to#/}" = "$to" ]; then
+   echo no common ancestor between $1 and $2 >&2
+   exit 1
 elif [ "$from" = . ]; then
echo no common ancestor between $1 and $2 >&2
exit 1

base-commit: 445128c12cf22081223f7385196ee3889ef4c4b2
-- 
2.48.1

Re: [PATCH] c++: Evaluate immediate invocation call arguments with mce_true [PR119150]

[Jason Merrill]

On 3/7/25 11:53 AM, Jakub Jelinek wrote:

Hi!

Since Marek's r14-4140 which moved immediate invocation evaluation
from build_over_call to cp_fold_r, the following testcase is miscompiled.

The a = foo (bar ()); case is actually handled right, that is handled
in cp_fold_r and the whole CALL_EXPR is at that point evaluated by
cp_fold_immediate_r with cxx_constant_value (stmt, tf_none);
and that uses mce_true for evaluation of the argument as well as the actual
call.

But in the bool b = foo (bar ()); case we actually try to evaluate this
as non-manifestly constant-evaluated.  And while
   /* Make sure we fold std::is_constant_evaluated to true in an
  immediate function.  */
   if (DECL_IMMEDIATE_FUNCTION_P (fun))
 call_ctx.manifestly_const_eval = mce_true;
ensures that if consteval and __builtin_is_constant_evaluated () is true
inside of that call, this happens after arguments to the function
have been already constant evaluated in cxx_bind_parameters_in_call.
The call_ctx in that case also includes new call_ctx.call, something that
shouldn't be used for the arguments, so the following patch just arranges
to call cxx_bind_parameters_in_call with manifestly_constant_evaluated =
mce_true.

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

2025-03-07  Jakub Jelinek  

PR c++/119150
* constexpr.cc (cxx_eval_call_expression): Call
cxx_bind_parameters_in_call for immediate invocations with
manifestly_const_eval set to mce_true.

* g++.dg/cpp2a/consteval41.C: New test.

--- gcc/cp/constexpr.cc.jj  2025-03-01 09:13:17.694075636 +0100
+++ gcc/cp/constexpr.cc 2025-03-07 13:45:35.909164389 +0100
@@ -3074,9 +3074,21 @@ cxx_eval_call_expression (const constexp
   || cp_noexcept_operand);
  
bool non_constant_args = false;

-  new_call.bindings
-= cxx_bind_parameters_in_call (ctx, t, fun, non_constant_p,
-  overflow_p, &non_constant_args);
+  /* An immediate invocation is manifestly constant evaluated including the
+ arguments of the call, so use mce_true for the argument evaluation.  */
+  if (DECL_IMMEDIATE_FUNCTION_P (fun)
+  && ctx->manifestly_const_eval != mce_true)
+{
+  constexpr_ctx call_ctx = *ctx;


Why not use new_ctx for this instead of creating another copy?

I would think once we see that we have an immediate function, we want to 
go ahead and set ctx->manifestly_const_eval and 
new_call->manifestly_const_eval to true.  It looks like we currently 
cache immediate invocations separately depending on whether they're in 
an enclosing immediate function context, which seems redundant.


Incidentally, I don't remember why we need a separate call_ctx either.

Jason

[PING] [PATCH v3] c++: Use capture from outer lambda, if any, instead of erroring out [PR110584]

[Simon Martin]

Hi,

On Thu Mar 6, 2025 at 8:06 PM CET, Simon Martin wrote:
> Hi Jason,
>
> On Wed Mar 5, 2025 at 9:40 PM CET, Jason Merrill wrote:
>> On 3/5/25 10:39 AM, Simon Martin wrote:
>>> Hi Jason,
>>> 
>>> On Wed Mar 5, 2025 at 12:03 AM CET, Jason Merrill wrote:
 On 2/18/25 5:12 AM, Simon Martin wrote:
> We've been rejecting this valid code since r8-4571:
>
> === cut here ===
> void foo (float);
> int main () {
> constexpr float x = 0;
> (void) [&] () {
>   foo (x);
>   (void) [] () {
> foo (x);
>   };
> };
> }
> === cut here ===
>
> The problem is that when processing X in the inner lambda,
> process_outer_var_ref errors out even though it does find the capture
>>> 
> from the enclosing lambda.
>
> This patch changes process_outer_var_ref to accept and return the outer
> proxy if it finds any.
>
> Successfully tested on x86_64-pc-linux-gnu.
>
>   PR c++/110584
>
> gcc/cp/ChangeLog:
>
>   * semantics.cc (process_outer_var_ref): Use capture from
>   enclosing lambda, if any.
>
> gcc/testsuite/ChangeLog:
>
>   * g++.dg/cpp0x/lambda/lambda-nested10.C: New test.
>
> ---
>gcc/cp/semantics.cc   |  4 ++
>.../g++.dg/cpp0x/lambda/lambda-nested10.C | 46 +++
>2 files changed, 50 insertions(+)
>create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested10.C
>
> diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
> index 7c7d3e3c432..7bbc82f7dc1 100644
> --- a/gcc/cp/semantics.cc
> +++ b/gcc/cp/semantics.cc
> @@ -4598,6 +4598,10 @@ process_outer_var_ref (tree decl, tsubst_flags_t 
> complain, bool odr_use)
>  if (!odr_use && context == containing_function)
>decl = add_default_capture (lambda_stack,
>   /*id=*/DECL_NAME (decl), initializer);
> +  /* When doing lambda capture, if we found a capture in an enclosing 
> lambda,
> + we can use it.  */
> +  else if (!odr_use && is_capture_proxy (decl))
> +return decl;

 What makes this OK is not that it's a capture, but that the captured
>
 variable is constant, so it should have satisfied this branch:

>/* Only an odr-use of an outer automatic variable causes an
>   error, and a constant variable can decay to a prvalue
>   constant without odr-use.  So don't complain yet.  */
>else if (!odr_use && decl_constant_var_p (decl))
>  return decl;

 is_constant_capture_proxy might be useful here.  And/or a new
 strip_normal_capture function (that I'm surprised doesn't exist yet).
>>> Yeah, that makes a lot of sense, thanks. This is what the attached updated
>>> patch does, successfully tested on x86_64-pc-linux-gnu. OK for trunk?
>>
>>> @@ -4601,7 +4599,7 @@ process_outer_var_ref (tree decl, tsubst_flags_t 
>>> complain, bool odr_use)
>>>/* Only an odr-use of an outer automatic variable causes an
>>>   error, and a constant variable can decay to a prvalue
>>>   constant without odr-use.  So don't complain yet.  */
>>> -  else if (!odr_use && decl_constant_var_p (decl))
>>> +  else if (!odr_use && decl_constant_var_p (strip_normal_capture_proxy 
>>> (decl)))
>>>  return decl;
>>
>> We also want to strip the proxy from the return value.
> Doh, of course, sorry for overlooking this :-/ I checked if I could come up
> with a test case that would fail with this mistake but failed to.
>
> Anyway, I attach another revision that fixes the issue, and was successfully
> tested on x86_64-pc-linux-gnu. OK for trunk?
Friendly ping.

Thanks, Simon

RE: [PATCH] cobol: Remove unnecesssary CPPFLAGS update and restore MacOS build

[Robert Dubner]

> -Original Message-
> From: Simon Martin 
> Sent: Wednesday, March 12, 2025 06:27
> To: gcc-patches@gcc.gnu.org
> Cc: rdub...@symas.com
> Subject: [PATCH] cobol: Remove unnecesssary CPPFLAGS update and restore
> MacOS build
> 
> The build currently fails on MacOS even when the Cobol front-end and
> libgcobol builds are disabled.
> 
> The problem is that gcc/cobol/Make-lang.in adds -Iinclude to CPPFLAGS,
> which somehow makes clang unhappy about the include order:
>   error:  tried including  but didn't find libc++'s
>header. This usually means that your header search paths
>   are not configured properly.
> 
> It turns out that this addition is unnecessary: simply removing it fixes
> the build on MacOS, without impacting the build x86_64-pc-linux-gnu when
> configured with --enable-languages=default,cobol.
> 
> It feels like there might be more cleanup opportunities there, but they
> can be taken care of later.
> 
> OK for trunk?

I am still trying to get up to speed, here.  Jim and I have been living in
our tidy little world; he's been developing in an Ubuntu instances on a
aarch64 Mac M2, and I've been developing on an Ubuntu environment on a
x86_64.

But now we've gotten off the train at Grand Central Station, and I feel
like there are cars whizzing by, and horns honking, and pedestrians
pushing past me muttering, "Brush the hay out of your hair!"

So, if I am supposed to answer that question, and if indeed the change
doesn't affect x86_64-pc-linux-gnu builds, then by all means, it is "OK
for trunk".

We'll deal with any downstream problems later; right now Jim and I are
very sensitive to the goal of "Don't break the build".

> 
> gcc/cobol/ChangeLog:
> 
>   * Make-lang.in: Remove unnecessary CPPFLAGS update.
> 
> ---
>  gcc/cobol/Make-lang.in | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/gcc/cobol/Make-lang.in b/gcc/cobol/Make-lang.in index
> a4e005ac2bd..7888c116d70 100644
> --- a/gcc/cobol/Make-lang.in
> +++ b/gcc/cobol/Make-lang.in
> @@ -56,7 +56,6 @@ LIB_SOURCE ?= $(srcdir)/../libgcobol  #
>  CPPFLAGS =   \
>   -std=c++14  \
> - -Iinclude   \
>   -I$(BINCLUDE)   \
>   -I$(LIB_INCLUDE)\
>   -DEXEC_LIB=\"$(prefix)/lib64\"  \
> --
> 2.44.0

Re: [PATCH] c++: ICE with lambda in fold expression in requires [PR119134]

[Jason Merrill]

On 3/7/25 11:40 AM, Marek Polacek wrote:

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


OK.


-- >8 --
The r12-8258 fix assumes that DECL_CONTEXT of 'pack' in
check_for_bare_parameter_packs is going to be an operator()
but as this test shows, it can be empty.

PR c++/119134

gcc/cp/ChangeLog:

* pt.cc (check_for_bare_parameter_packs): Check DECL_CONTEXT.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-uneval24.C: New test.
---
  gcc/cp/pt.cc | 1 +
  gcc/testsuite/g++.dg/cpp2a/lambda-uneval24.C | 4 
  2 files changed, 5 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-uneval24.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 2378f892a53..630826069b8 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -4375,6 +4375,7 @@ check_for_bare_parameter_packs (tree t, location_t loc /* 
= UNKNOWN_LOCATION */)
tree pack = TREE_VALUE (parameter_packs);
if (is_capture_proxy (pack)
|| (TREE_CODE (pack) == PARM_DECL
+   && DECL_CONTEXT (pack)
&& DECL_CONTEXT (DECL_CONTEXT (pack)) == lam))
  break;
}
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-uneval24.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-uneval24.C
new file mode 100644
index 000..a2b45595e47
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-uneval24.C
@@ -0,0 +1,4 @@
+// PR c++/119134
+// { dg-do compile { target c++20 } }
+
+void f(auto... args) requires(([args] {}, ..., true)) {}

base-commit: b7f5d9114801716924a67ea393f0c30ab793e505

Re: [PATCH v3] c++: Use capture from outer lambda, if any, instead of erroring out [PR110584]

[Jason Merrill]

On 3/6/25 2:06 PM, Simon Martin wrote:

Hi Jason,

On Wed Mar 5, 2025 at 9:40 PM CET, Jason Merrill wrote:

On 3/5/25 10:39 AM, Simon Martin wrote:

Hi Jason,

On Wed Mar 5, 2025 at 12:03 AM CET, Jason Merrill wrote:

On 2/18/25 5:12 AM, Simon Martin wrote:

We've been rejecting this valid code since r8-4571:

=== cut here ===
void foo (float);
int main () {
 constexpr float x = 0;
 (void) [&] () {
   foo (x);
   (void) [] () {
 foo (x);
   };
 };
}
=== cut here ===

The problem is that when processing X in the inner lambda,
process_outer_var_ref errors out even though it does find the capture



from the enclosing lambda.

This patch changes process_outer_var_ref to accept and return the outer
proxy if it finds any.

Successfully tested on x86_64-pc-linux-gnu.

PR c++/110584

gcc/cp/ChangeLog:

* semantics.cc (process_outer_var_ref): Use capture from
enclosing lambda, if any.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-nested10.C: New test.

---
gcc/cp/semantics.cc   |  4 ++
.../g++.dg/cpp0x/lambda/lambda-nested10.C | 46 +++
2 files changed, 50 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested10.C

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 7c7d3e3c432..7bbc82f7dc1 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -4598,6 +4598,10 @@ process_outer_var_ref (tree decl, tsubst_flags_t 
complain, bool odr_use)
  if (!odr_use && context == containing_function)
decl = add_default_capture (lambda_stack,
/*id=*/DECL_NAME (decl), initializer);
+  /* When doing lambda capture, if we found a capture in an enclosing lambda,
+ we can use it.  */
+  else if (!odr_use && is_capture_proxy (decl))
+return decl;


What makes this OK is not that it's a capture, but that the captured



variable is constant, so it should have satisfied this branch:


/* Only an odr-use of an outer automatic variable causes an
   error, and a constant variable can decay to a prvalue
   constant without odr-use.  So don't complain yet.  */
else if (!odr_use && decl_constant_var_p (decl))
  return decl;


is_constant_capture_proxy might be useful here.  And/or a new
strip_normal_capture function (that I'm surprised doesn't exist yet).

Yeah, that makes a lot of sense, thanks. This is what the attached updated
patch does, successfully tested on x86_64-pc-linux-gnu. OK for trunk?



@@ -4601,7 +4599,7 @@ process_outer_var_ref (tree decl, tsubst_flags_t 
complain, bool odr_use)
/* Only an odr-use of an outer automatic variable causes an
   error, and a constant variable can decay to a prvalue
   constant without odr-use.  So don't complain yet.  */
-  else if (!odr_use && decl_constant_var_p (decl))
+  else if (!odr_use && decl_constant_var_p (strip_normal_capture_proxy (decl)))
  return decl;


We also want to strip the proxy from the return value.

Doh, of course, sorry for overlooking this :-/ I checked if I could come up
with a test case that would fail with this mistake but failed to.

Anyway, I attach another revision that fixes the issue, and was successfully
tested on x86_64-pc-linux-gnu. OK for trunk?


OK.

Jason

Re: [PATCH] libstdc++: Correct preprocessing checks for floatX_t and bfloat_16 formatting

[Jonathan Wakely]

On Tue, 11 Mar 2025 at 12:22, Tomasz Kamiński wrote:
>
> Floating points types _Float16, _Float32, _Float64, and bfloat16,
> can be formatted only if std::to_chars overloads for such types
> where provided. Currently this is only the case for architectures

Spelling: "were provided"

With that fixed, OK for trunk, thanks for noticing this.

I think we also want this on the gcc-14 and gcc-13 branches, but after
it's sat on trunk for a while.

> where float and double are 32-bits and 64-bits IEEE floating points types.
>
> This patch updates the preprocessing checks for formatters
> for above types to check _GLIBCXX_FLOAT_IS_IEEE_BINARY32
> and _GLIBCXX_DOUBLE_IS_IEEE_BINARY64. Making them non-formattable
> on non-IEEE architectures.
>
> Remove a potential UB, where we could produce basic_format_arg
> with _M_type set to _Arg_fp32 or _Arg_fp64, that was later not
> handled by `_M_visit`.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/format (formatter<_Float16, _CharT>): Define only if
> _GLIBCXX_FLOAT_IS_IEEE_BINARY32 macro is defined.
> (formatter<_Float16, _CharT>): As above.
> (formatter<__gnu_cxx::__bfloat16_t, _CharT>): As above.
> (formatter<_Float64, _CharT>): Define only if
> _GLIBCXX_DOUBLE_IS_IEEE_BINARY64 is defined.
> (basic_format_arg::_S_to_arg_type): Normalize _Float32 and _Float64
> only to float and double respectivelly.
> (basic_format_arg::_S_to_enum): Remove handling of _Float32 and 
> _Float64.
> ---
> Tested on x86_64-linux. OK for trunk?
>
>  libstdc++-v3/include/std/format | 32 
>  1 file changed, 8 insertions(+), 24 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
> index e7e0d2d142b..1809f040077 100644
> --- a/libstdc++-v3/include/std/format
> +++ b/libstdc++-v3/include/std/format
> @@ -2276,7 +2276,7 @@ namespace __format
>  };
>  #endif
>
> -#ifdef __STDCPP_FLOAT16_T__
> +#if defined(__STDCPP_FLOAT16_T__) && defined(_GLIBCXX_FLOAT_IS_IEEE_BINARY32)
>// Reuse __formatter_fp::format for _Float16.
>template<__format::__char _CharT>
>  struct formatter<_Float16, _CharT>
> @@ -2298,7 +2298,7 @@ namespace __format
>  };
>  #endif
>
> -#if defined(__FLT32_DIG__)
> +#if defined(__FLT32_DIG__) && defined(_GLIBCXX_FLOAT_IS_IEEE_BINARY32)
>// Reuse __formatter_fp::format for _Float32.
>template<__format::__char _CharT>
>  struct formatter<_Float32, _CharT>
> @@ -2320,7 +2320,7 @@ namespace __format
>  };
>  #endif
>
> -#if defined(__FLT64_DIG__)
> +#if defined(__FLT64_DIG__) && defined(_GLIBCXX_DOUBLE_IS_IEEE_BINARY64)
>// Reuse __formatter_fp::format for _Float64.
>template<__format::__char _CharT>
>  struct formatter<_Float64, _CharT>
> @@ -2364,7 +2364,7 @@ namespace __format
>  };
>  #endif
>
> -#ifdef __STDCPP_BFLOAT16_T__
> +#if defined(__STDCPP_BFLOAT16_T__) && 
> defined(_GLIBCXX_FLOAT_IS_IEEE_BINARY32)
>// Reuse __formatter_fp::format for bfloat16_t.
>template<__format::__char _CharT>
>  struct formatter<__gnu_cxx::__bfloat16_t, _CharT>
> @@ -3443,22 +3443,16 @@ namespace __format
> return type_identity();
>  #endif
>
> -#ifdef __FLT32_DIG__
> +#if defined(__FLT32_DIG__) && defined(_GLIBCXX_FLOAT_IS_IEEE_BINARY32)
>   else if constexpr (is_same_v<_Td, _Float32>)
> -# ifdef _GLIBCXX_FLOAT_IS_IEEE_BINARY32
> return type_identity();
> -# else
> -   return type_identity<_Float32>();
> -# endif
>  #endif
> -#ifdef __FLT64_DIG__
> +
> +#if defined(__FLT64_DIG__) && defined(_GLIBCXX_DOUBLE_IS_IEEE_BINARY64)
>   else if constexpr (is_same_v<_Td, _Float64>)
> -# ifdef _GLIBCXX_DOUBLE_IS_IEEE_BINARY64
> return type_identity();
> -# else
> -   return type_identity<_Float64>();
> -# endif
>  #endif
> +
>  #if _GLIBCXX_FORMAT_F128
>  # if __FLT128_DIG__
>   else if constexpr (is_same_v<_Td, _Float128>)
> @@ -3538,16 +3532,6 @@ namespace __format
> return _Arg_u128;
>  #endif
>
> - // N.B. some of these types will never actually be used here,
> - // because they get normalized to a standard floating-point type.
> -#if defined __FLT32_DIG__ && ! _GLIBCXX_FLOAT_IS_IEEE_BINARY32
> - else if constexpr (is_same_v<_Tp, _Float32>)
> -   return _Arg_f32;
> -#endif
> -#if defined __FLT64_DIG__ && ! _GLIBCXX_DOUBLE_IS_IEEE_BINARY64
> - else if constexpr (is_same_v<_Tp, _Float64>)
> -   return _Arg_f64;
> -#endif
>  #if _GLIBCXX_FORMAT_F128 == 2
>   else if constexpr (is_same_v<_Tp, __format::__float128_t>)
> return _Arg_f128;
> --
> 2.48.1
>

[PATCH] to MAINTAINERS; remove extraneous Robert Dubner entries.

[Robert Dubner]

Removing extraneous/erroneous entries, leaving me just Front End
Maintainers

I pushed this change to origin/master

diff --git a/MAINTAINERS b/MAINTAINERS
index 34e2f9f53b7..5b3fe407860 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -277,7 +277,6 @@ check in changes outside of the parts of the compiler
they maintain.
 arm port (MVE)  Christophe Lyon 
 callgraph   Martin Jambor   
 C front end Marek Polacek   
-COBOL front end Robert Dubner   
 CTF, BTFIndu Bhagat 
 CTF, BTF, bpf port  David Faust 
 dataflowPaolo Bonzini   
@@ -447,7 +446,6 @@ Dimitar Dimitrovdimitar

 Benoit Dupont de Dinechin   bd3

 Lehua Ding  -   
 Ulrich Drepper  drepper 
-Robert Dubner   rdubner 
 François Dumont fdumont 
 Zdenek Dvorak   rakdver 
 Michael Eager   eager   

[PATCH] testsuite: Remove sve/pre_cond_share_1.c [PR115248]

[Richard Sandiford]

gcc.target/aarch64/sve/pre_cond_share_1.c started failing after
r15-276-gbed6ec161be8c5ca.  However, that was incidental.
The test's inner loop is duplicated by -fswitch-loops and
that patch happened to change the copy of the loop that was
not the original focus of the test.

The test was added as part of r14-4713-g4b39aeef594f311e (patch A).
Before patch A we had:

  mask__109.48_201 = vect_distbb_170.43_191 < vect_cst__200;
  _263 = .COND_MUL (mask__109.48_201, vect_iftmp.45_195, vect_cst__198, { 0.0, 
... });
  vect_prephitmp_153.50_205 = .VCOND (vect_distbb_170.43_191, { 0.0, ... }, 
_263, vect_cst__198, 112);

which, expanding the .VCOND, is equivalent to:

  mask__102.46_197 = vect_distbb_170.43_191 >= { 0.0, ... };
  mask__109.48_201 = vect_distbb_170.43_191 < vect_cst__200;
  _263 = .COND_MUL (mask__109.48_201, vect_iftmp.45_195, vect_cst__198, { 0.0, 
... });
  vect_prephitmp_153.50_205 = mask__102.46_197 ? _263 : vect_cst__198

After patch A we had:

  mask__102.46_197 = vect_distbb_170.43_191 >= { 0.0, ... };
  mask__109.48_201 = vect_distbb_170.43_191 < vect_cst__200;
  _70 = mask__102.46_197 & mask__109.48_201;
  vect_prephitmp_153.50_205 = .COND_MUL (_70, vect_iftmp.45_195, vect_cst__198, 
{ 0.0, ... });

But this changes the behaviour when vect_distbb_170.43_191 < { 0.0, ... }.
In that case, the original code would pick an else value of vect_cst__198,
whereas the new code would pick an else value of { 0.0, ... }.

That was fixed in r14-8668-g8123f3ca3fd89103 (PR113607, patch B),
but fixing the bug (rightly) reverted the code to the previous output.
Patch B therefore XFAILed the thing that patch A was originally testing.

Since the test was added for patch A and since patch A seems to generate
incorrect code for the test, I think we should just remove it.

I'll leave this for a day or so for comments/corrections.

Richard


gcc/testsuite/
PR testsuite/115248
* gcc.target/aarch64/sve/pre_cond_share_1.c: Delete
---
 .../gcc.target/aarch64/sve/pre_cond_share_1.c | 132 --
 1 file changed, 132 deletions(-)
 delete mode 100644 gcc/testsuite/gcc.target/aarch64/sve/pre_cond_share_1.c

diff --git a/gcc/testsuite/gcc.target/aarch64/sve/pre_cond_share_1.c 
b/gcc/testsuite/gcc.target/aarch64/sve/pre_cond_share_1.c
deleted file mode 100644
index e4f754d739c..000
--- a/gcc/testsuite/gcc.target/aarch64/sve/pre_cond_share_1.c
+++ /dev/null
@@ -1,132 +0,0 @@
-/* { dg-do compile } */
-/* { dg-options "-Ofast -fdump-tree-optimized" } */
-
-#include 
-#include 
-#include 
-#include 
-
-typedef struct __attribute__((__packed__)) _Atom {
-float x, y, z;
-int32_t type;
-} Atom;
-
-typedef struct __attribute__((__packed__)) _FFParams {
-int32_t hbtype;
-float radius;
-float hphb;
-float elsc;
-} FFParams;
-
-#ifndef PPWI
-#define PPWI (64)
-#endif
-
-#ifndef ITERS
-#define ITERS 8
-#endif
-
-#define DIFF_TOLERANCE_PCT 0.025f
-
-#define POSES_SIZE 393216
-#define PROTEIN_SIZE 938
-#define LIGAND_SIZE 26
-#define FORCEFIELD_SIZE 34
-
-#define ZERO 0.0f
-#define QUARTER 0.25f
-#define HALF 0.5f
-#define ONE 1.0f
-#define TWO 2.0f
-#define FOUR 4.0f
-#define CNSTNT 45.0f
-
-// Energy evaluation parameters
-#define HBTYPE_F 70
-#define HBTYPE_E 69
-#define HARDNESS 38.0f
-#define NPNPDIST 5.5f
-#define NPPDIST 1.0f
-
-void
-fasten_main(size_t group, size_t ntypes, size_t nposes, size_t natlig, size_t 
natpro,//
-const Atom *protein, const Atom *ligand,   
  //
-const float *transforms_0, const float *transforms_1, const float 
*transforms_2, //
-const float *transforms_3, const float *transforms_4, const float 
*transforms_5, //
-const FFParams *forcefield, float *energies
  //
-) {
-
-float etot[PPWI];
-float lpos_x[PPWI];
-
-for (int l = 0; l < PPWI; l++) {
-etot[l] = 0.f;
-lpos_x[l] = 0.f;
-}
-
-// Loop over ligand atoms
-for (int il = 0; il < natlig; il++) {
-// Load ligand atom data
-const Atom l_atom = ligand[il];
-const FFParams l_params = forcefield[l_atom.type];
-const int lhphb_ltz = l_params.hphb < 0.f;
-const int lhphb_gtz = l_params.hphb > 0.f;
-
-// Transform ligand atom
-
-// Loop over protein atoms
-for (int ip = 0; ip < natpro; ip++) {
-// Load protein atom data
-const Atom p_atom = protein[ip];
-const FFParams p_params = forcefield[p_atom.type];
-
-const float radij = p_params.radius + l_params.radius;
-const float r_radij = ONE / radij;
-
-const float elcdst = (p_params.hbtype == HBTYPE_F && 
l_params.hbtype == HBTYPE_F) ? FOUR
-   
   : TWO;
-const float elcdst1 = (p_params.hbtype == HBTYPE_F && 
l_params.hbtype == HBTYPE_F)
-

[PATCH] LoongArch: Don't use C++17 feature [PR119238]

[Xi Ruoyao]

Structured binding is a C++17 feature but the GCC code base is in C++14.

gcc/ChangeLog:

PR target/119238
* config/loongarch/simd.md (dot_prod):
Stop using structured binding.
---

Ok for trunk?

 gcc/config/loongarch/simd.md | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/gcc/config/loongarch/simd.md b/gcc/config/loongarch/simd.md
index 8f7e912982e..dd17cd13fc5 100644
--- a/gcc/config/loongarch/simd.md
+++ b/gcc/config/loongarch/simd.md
@@ -809,18 +809,20 @@ (define_expand "dot_prod"
(any_extend (const_int 0))]
   ""
 {
-  auto [op0, op1, op2, op3] = operands;
+  rtx *op = operands;
 
-  if (op3 == CONST0_RTX (mode))
+  if (op[3] == CONST0_RTX (mode))
 emit_insn (
-  gen__vmulwev__ (op0, op1, op2));
+  gen__vmulwev__ (op[0], op[1],
+ op[2]));
   else
 emit_insn (
-  gen__vmaddwev__ (op0, op3, op1,
-  op2));
+  gen__vmaddwev__ (op[0], op[3],
+  op[1], op[2]));
 
   emit_insn (
-gen__vmaddwod__ (op0, op0, op1, op2));
+gen__vmaddwod__ (op[0], op[0],
+op[1], op[2]));
   DONE;
 })
 
-- 
2.48.1

[PATCH] tree.def: Improve RAW_DATA_CST documentation

[Jakub Jelinek]

Hi!

In PR117262 David was asking for better documentation of RAW_DATA_CST
and in the review of the PR119076 patch Jason was asking for that as well.

Here is an attempt to do so.

Ok for trunk?

2025-03-12  Jakub Jelinek  

* tree.def (RAW_DATA_CST): Document meaning of NULL RAW_DATA_OWNER.
(CONSTRUCTOR): Document meaning of RAW_DATA_CST used as element
value.

--- gcc/tree.def.jj 2025-01-15 08:43:39.818915636 +0100
+++ gcc/tree.def2025-03-12 08:11:24.230196310 +0100
@@ -313,7 +313,9 @@ DEFTREECODE (STRING_CST, "string_cst", t
of the raw data, plus RAW_DATA_OWNER for owner of the
data.  That can be either a STRING_CST, used e.g. when writing
PCH header, or another RAW_DATA_CST representing data owned by
-   libcpp and representing the original range (if possible).
+   libcpp and representing the original range (if possible)
+   or NULL_TREE if it is the RAW_DATA_OWNER of other RAW_DATA_CST
+   nodes (and represents data owned by libcpp).
TREE_TYPE is the type of each of the RAW_DATA_LENGTH elements.  */
 DEFTREECODE (RAW_DATA_CST, "raw_data_cst", tcc_constant, 0)
 
@@ -505,6 +507,14 @@ DEFTREECODE (OBJ_TYPE_REF, "obj_type_ref
one for each index in the range.  (If the corresponding field VALUE
has side-effects, they are evaluated once for each element.  Wrap the
value in a SAVE_EXPR if you want to evaluate side effects only once.)
+   If the index is INTEGER_CST or NULL_TREE and value RAW_DATA_CST, it is
+   a short-hand for RAW_DATA_LENGTH consecutive nodes, first at the given
+   index or current location, each node being
+   build_int_cst (TREE_TYPE (value), TYPE_UNSIGNED (TREE_TYPE (value))
+ ? (HOST_WIDE_INT) RAW_DATA_UCHAR_ELT (value, n)
+ : (HOST_WIDE_INT) RAW_DATA_SCHAR_ELT (value, n)) at index
+   tree_to_uhwi (index) + n (or current location + n) for n from 0 to
+   RAW_DATA_LENGTH (value) - 1.
 
Components that aren't present are cleared as per the C semantics,
unless the CONSTRUCTOR_NO_CLEARING flag is set, in which case their

Jakub

Re: [PATCH] cobol: Remove unnecesssary CPPFLAGS update and restore MacOS build

[Richard Biener]

On Wed, Mar 12, 2025 at 11:28 AM Simon Martin  wrote:
>
> The build currently fails on MacOS even when the Cobol front-end and
> libgcobol builds are disabled.
>
> The problem is that gcc/cobol/Make-lang.in adds -Iinclude to CPPFLAGS,
> which somehow makes clang unhappy about the include order:
>   error:  tried including  but didn't find libc++'s
>header. This usually means that your header search paths
>   are not configured properly.
>
> It turns out that this addition is unnecessary: simply removing it fixes
> the build on MacOS, without impacting the build x86_64-pc-linux-gnu when
> configured with --enable-languages=default,cobol.
>
> It feels like there might be more cleanup opportunities there, but they
> can be taken care of later.
>
> OK for trunk?

OK.

Richard.

> gcc/cobol/ChangeLog:
>
> * Make-lang.in: Remove unnecessary CPPFLAGS update.
>
> ---
>  gcc/cobol/Make-lang.in | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/gcc/cobol/Make-lang.in b/gcc/cobol/Make-lang.in
> index a4e005ac2bd..7888c116d70 100644
> --- a/gcc/cobol/Make-lang.in
> +++ b/gcc/cobol/Make-lang.in
> @@ -56,7 +56,6 @@ LIB_SOURCE ?= $(srcdir)/../libgcobol
>  #
>  CPPFLAGS = \
>   -std=c++14\
> - -Iinclude \
>   -I$(BINCLUDE) \
>   -I$(LIB_INCLUDE)  \
>   -DEXEC_LIB=\"$(prefix)/lib64\"\
> --
> 2.44.0
>

Re: c++/modules: Handle gnu_inline attribute, cleanup linkage determination [PR119154]

[Jason Merrill]

On 3/10/25 9:50 AM, Nathaniel Shead wrote:

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?

Alternatively, a more minimal fix for the PR would be to just special
case the note_vague_linkage_fn calls to not be performed for gnu_inline
functions, if that's a preferable fix this late into stage 4.

-- >8 --

Currently, note_vague_linkage_fn is called on all definitions imported
from modules.  This is not correct, however; among other things, a
gnu_inline function does not have vague linkage, and causes an ICE if
its treated as such.

There are other things that we seem to potentially miss (e.g. dllexport
handling), so it seems sensible to stop trying to manage linkage in such
an ad-hoc manner but to use the normal interfaces more often.


Agreed.


The change to use expand_or_defer_fn exposes a checking-only ICE in
trees_in::assert_definition, where we forget that we already installed a
definition for a function.  We work around this by instead of clearing
DECL_SAVED_TREE entirely in expand_or_defer_fn_1, we instead set it to a
dummy value.  This way we can also avoid the check for !TREE_ASM_WRITTEN
beforehand.


Makes sense.


PR c++/119154

gcc/cp/ChangeLog:

* module.cc (trees_out::core_bools): Clear DECL_INTERFACE_KNOWN
for external-linkage functions, except gnu_inline.


...but why is this change needed?  It seems like adding an ad-hoc subset 
of vague_linkage_p while we're trying to remove ad-hocery elsewhere. 
And I'm skeptical about doing this here for vague linkage in general; 
the typeinfo/vtable bits are for a specific ABI requirement, not because 
they're vague linkage.


It does seem like we need to teach vague_linkage_p about gnu_inline, 
would that remove the motivation for this change?



(module_state::read_cluster): Use expand_or_defer_fn instead of
ad-hoc linkage management.
(post_load_processing): Likewise.
* semantics.cc (expand_or_defer_fn_1): Don't forget that we had
a definition at all.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr119154_a.C: New test.
* g++.dg/modules/pr119154_b.C: New test.

Signed-off-by: Nathaniel Shead 
---
  gcc/cp/module.cc  | 33 ---
  gcc/cp/semantics.cc   |  2 +-
  gcc/testsuite/g++.dg/modules/pr119154_a.C |  6 +
  gcc/testsuite/g++.dg/modules/pr119154_b.C | 10 +++
  4 files changed, 28 insertions(+), 23 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/modules/pr119154_a.C
  create mode 100644 gcc/testsuite/g++.dg/modules/pr119154_b.C

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 8b0f42951c2..8e0fa3c5bfc 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -212,6 +212,7 @@ Classes used:
  #define INCLUDE_VECTOR
  #include "system.h"
  #include "coretypes.h"
+#include "target.h"
  #include "cp-tree.h"
  #include "timevar.h"
  #include "stringpool.h"
@@ -5620,6 +5621,14 @@ trees_out::core_bools (tree t, bits_out& bits)
bool interface_known = t->decl_common.lang_flag_5;
if (VAR_P (t) && (DECL_VTABLE_OR_VTT_P (t) || DECL_TINFO_P (t)))
  interface_known = false;
+   /* External linkage functions should also be redetermined on
+  stream-in, except gnu_inline which is always external.  */
+   if (interface_known
+   && TREE_CODE (t) == FUNCTION_DECL
+   && TREE_PUBLIC (t)
+   && !(DECL_DECLARED_INLINE_P (t)
+&& lookup_attribute("gnu_inline", DECL_ATTRIBUTES (t
+ interface_known = false;
WB (interface_known);
}
  
@@ -16417,12 +16426,7 @@ module_state::read_cluster (unsigned snum)

  cfun->returns_pcc_struct = aggr;
  #endif
  cfun->returns_struct = aggr;
-
- if (DECL_COMDAT (decl))
-   // FIXME: Comdat grouping?
-   comdat_linkage (decl);
- note_vague_linkage_fn (decl);
- cgraph_node::finalize_function (decl, true);
+ expand_or_defer_fn (decl);
}
  
  }

@@ -18901,22 +18905,7 @@ post_load_processing ()
dump () && dump ("Post-load processing of %N", decl);
  
gcc_checking_assert (DECL_MAYBE_IN_CHARGE_CDTOR_P (decl));

-
-  if (DECL_COMDAT (decl))
-   comdat_linkage (decl);
-  if (!TREE_ASM_WRITTEN (decl))
-   {
- /* Cloning can cause loading -- specifically operator delete for
-the deleting dtor.  */
- if (maybe_clone_body (decl))
-   TREE_ASM_WRITTEN (decl) = 1;
- else
-   {
- /* We didn't clone the cdtor, make sure we emit it.  */
- note_vague_linkage_fn (decl);
- cgraph_node::finalize_function (decl, true);
-   }
-   }
+  expand_or_defer_fn (decl);
  }
  
cfun = old_cfun;

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 7c7d3e3c432..914502abe7a 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -5504,7 +5504,7 @@ expand_or_defer_fn_

Re: [PATCH v2] c++/modules: Handle gnu_inline attribute, cleanup linkage determination [PR119154]

[Jason Merrill]

On 3/12/25 10:43 AM, Nathaniel Shead wrote:

On Wed, Mar 12, 2025 at 08:52:19AM -0400, Jason Merrill wrote:

On 3/10/25 9:50 AM, Nathaniel Shead wrote:

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?

Alternatively, a more minimal fix for the PR would be to just special
case the note_vague_linkage_fn calls to not be performed for gnu_inline
functions, if that's a preferable fix this late into stage 4.

-- >8 --

Currently, note_vague_linkage_fn is called on all definitions imported
from modules.  This is not correct, however; among other things, a
gnu_inline function does not have vague linkage, and causes an ICE if
its treated as such.

There are other things that we seem to potentially miss (e.g. dllexport
handling), so it seems sensible to stop trying to manage linkage in such
an ad-hoc manner but to use the normal interfaces more often.


Agreed.


The change to use expand_or_defer_fn exposes a checking-only ICE in
trees_in::assert_definition, where we forget that we already installed a
definition for a function.  We work around this by instead of clearing
DECL_SAVED_TREE entirely in expand_or_defer_fn_1, we instead set it to a
dummy value.  This way we can also avoid the check for !TREE_ASM_WRITTEN
beforehand.


Makes sense.


PR c++/119154

gcc/cp/ChangeLog:

* module.cc (trees_out::core_bools): Clear DECL_INTERFACE_KNOWN
for external-linkage functions, except gnu_inline.


...but why is this change needed?  It seems like adding an ad-hoc subset of
vague_linkage_p while we're trying to remove ad-hocery elsewhere. And I'm
skeptical about doing this here for vague linkage in general; the
typeinfo/vtable bits are for a specific ABI requirement, not because they're
vague linkage.

It does seem like we need to teach vague_linkage_p about gnu_inline, would
that remove the motivation for this change?


Thanks.  And right, that's a good point.  We still need a bit of this
change (as otherwise import_export_decl would never attempt to
redetermine whether we need to actually emit vague linkage entities,
since DECL_INTERFACE_KNOWN would still be set from when the exporter
processed these declarations)


Ah, so expand_or_defer_fn_1 wouldn't call tentative_decl_linkage, so 
note_vague_linkage_fn wouldn't happen.


So, we want to clear DECL_INTERFACE_KNOWN at some point.  It might make 
sense to do that in read_var_def/read_function_def instead of 
core_bools, but it's certainly more straightforward to stick with the 
existing location.



but it seems reasonable to move this
special-casing of gnu_inline into vague_linkage_p.

My initial concern with this was whether this would stop us from
emitting the definition of the function, but has_definition just uses
DECL_DECLARED_INLINE_P for FUNCTION_DECLs so it should continue working
correctly.

Here's an updated patch which does this, and also as a drive-by fix I
noticed while working on this, ensures that imported inline variables
are correctly marked as COMDAT.  Maybe there's a better way to do this
though: I'm not sure how concerned to be about !flag_weak handling?

Tested modules.exp so far on x86_64-pc-linux-gnu, OK for trunk if full
bootstrap and regtest succeeds?

-- >8 --

Currently, note_vague_linkage_fn is called on all definitions imported
from modules.  This is not correct, however; among other things, a
gnu_inline function does not have vague linkage, and causes an ICE if
its treated as such.

There are other things that we seem to potentially miss (e.g. dllexport
handling), so it seems sensible to stop trying to manage linkage in such
an ad-hoc manner but to use the normal interfaces more often.  While
looking at this I also found that we seem to miss marking vague linkage
variables as COMDAT, so this patch fixes that as well.

The change to use expand_or_defer_fn exposes a checking-only ICE in
trees_in::assert_definition, where we forget that we already installed a
definition for a function.  We work around this by instead of clearing
DECL_SAVED_TREE entirely in expand_or_defer_fn_1, we instead set it to a
dummy value.  This way we can also avoid the check for !TREE_ASM_WRITTEN
beforehand.

PR c++/119154

gcc/cp/ChangeLog:

* decl2.cc (vague_linkage_p): Don't treat gnu_inline functions
as having vague linkage.
* module.cc (trees_out::core_bools): Clear DECL_INTERFACE_KNOWN
for vague-linkage entities.
(read_var_def): Maybe set comdat linkage for imported var
definitions.
(module_state::read_cluster): Use expand_or_defer_fn instead of
ad-hoc linkage management.
(post_load_processing): Likewise.
* semantics.cc (expand_or_defer_fn_1): Don't forget that we had
a definition at all.

gcc/testsuite/ChangeLog:

* g++.dg/modules/linkage-3_a.C: New test.
* g++.dg/modules/linkage-3_b.C: New test.
* g++.dg/modules/pr119154_a.C: New test.
* g++.dg/modules/pr119154_b.C: New test.

Signed-off-by: Nat

Re: Regression? Re: [patch, fortran] Fix PR 119078, putting a procedure in an abstract interface into global namespace

[Thomas Koenig]

Hi Andre,


FAIL: gfortran.dg/binding_label_tests_26b.f90   -O   (test for errors, line 8)
FAIL: gfortran.dg/binding_label_tests_26b.f90   -O   (test for errors, line 9)

When I revert your patch and test again, above fails do not occur. Could you
please investigate, if I am right?


Jep, I missed that.

The warning in the test case is bogus.  binding_label_tests_26a.f90 has

module fg
contains
  function fffi(f)
interface
   function f() bind(c)
   end function
end interface
  end function
end module

so f is a dummy argument, which is not a global entity.

binding_label_tests_26b.f90 has

module f! { dg-error "uses the same global identifier" }
  use fg! { dg-error "uses the same global identifier" }
end module

so it tests for that error.

The test case should stay, but I will remove the dg-error directives.

Best regards

Thomas

RE: [PATCH][v3] Simple cobol.dg testsuite

[Richard Biener]

On Tue, 11 Mar 2025, Robert Dubner wrote:

> Earlier in this discussion of a testsuite, the question came up about
> generating an error return in COBOL source code.
> 
> In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;".  When
> executed in  the initial "top-level" program-id, it results in the value 1
> being passed back to the _start stub.
> 
> "STOP RUN ERROR 1." is the equivalent of (and is in fact implemented with)
> "exit(1)".

Thanks, I'll add a fail.cob test checking this is catched by dejagnu.

Richard.

> Bob D.
> 
> > -Original Message-
> > From: Jakub Jelinek 
> > Sent: Tuesday, March 11, 2025 11:27
> > To: Richard Biener 
> > Cc: Iain Sandoe ; GCC Patches  > patc...@gcc.gnu.org>; jklow...@schemamania.org
> > Subject: Re: [PATCH][v3] Simple cobol.dg testsuite
> > 
> > On Tue, Mar 11, 2025 at 04:18:32PM +0100, Richard Biener wrote:
> > > On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> > >
> > > > On Tue, Mar 11, 2025 at 02:45:33PM +, Iain Sandoe wrote:
> > > > > > The following incremental patch does this.  The result has
> > > > > > everything needed but also some weird entries:
> > > > > >
> > > > > > Setting LD_LIBRARY_PATH to
> > > > > > .:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64
> > > > > > -pc-linux-gnu/./libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/co
> > > > > > bol/../..:/tmp/obj/gcc/testsuite/cobol/../../32:.:/tmp/obj/x86_6
> > > > > > 4-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./
> > > > > > libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/cobol/../..:/tmp/o
> > > > > > bj/gcc/testsuite/cobol/../../32
> > > > > >
> > > > > > Richard.
> > > > > >
> > > > > >
> > > > > > diff --git a/gcc/testsuite/lib/cobol.exp
> > > > > > b/gcc/testsuite/lib/cobol.exp index 65687bc64ae..73dfeab5ba8
> > > > > > 100644
> > > > > > --- a/gcc/testsuite/lib/cobol.exp
> > > > > > +++ b/gcc/testsuite/lib/cobol.exp
> > > > > > @@ -119,6 +119,9 @@ proc cobol_link_flags { paths } {
> > > > > >}
> > > > > >append ld_library_path ":${gccpath}/libgcobol/.libs"
> > > > > >   }
> > > > > > +  if { [file exists
> > > > > > "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
> > > > >
> > > > > I think Darwin at least, will need a -B for the
> > > > > libstdc++-v3/src/.libs path adding to the flags; this is used to
> > > > > set the embedded runpaths and the OS is getting picky about not
> > falling back to alternate shared libs.
> > > > > (not any way urgent since we cannot build the FE yet)
> > > >
> > > > Yeah, I'd just add -B with libstdc++-src-v3/src/.libs on all targets
> > > > too, not just the ld_library_path part.
> > >
> > > Fair enough, then additionally the following
> > >
> > > diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
> > > index 73dfeab5ba8..cd88bcb66d1 100644
> > > --- a/gcc/testsuite/lib/cobol.exp
> > > +++ b/gcc/testsuite/lib/cobol.exp
> > > @@ -119,7 +119,13 @@ proc cobol_link_flags { paths } {
> > > }
> > > append ld_library_path ":${gccpath}/libgcobol/.libs"
> > >}
> > > -  if { [file exists
> > > "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
> > > +  if { [file exists
> > > + "${gccpath}/libstdc++-v3/src/.libs/libstdc++.a"]
> > > ||
> > > +  [file exists
> > > "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
> > > +   if { $target_wants_B_option } {
> > > +  append flags "-B${gccpath}/libstdc++-v3/src/.libs "
> > > +   } else {
> > > +  append flags "-L${gccpath}/libstdc++-v3/src/.libs "
> > > +   }
> > > append ld_library_path ":${gccpath}/libstdc++-v3/src/.libs"
> > >}
> > >
> > 
> > Looks good to me.
> > 
> > Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

Re: [PATCH v2] libstdc++: Hide 128-bit int and float types behind handle for basic_format_arg visitation [PR108053]

[Jonathan Wakely]

On 12/03/25 15:39 +0100, Tomasz Kamiński wrote:

Implement visit_format_arg and basic_format_arg::visit function,
in terms of  _M_visit_user member functions, that wraps any type
stored inside basic_format_arg, that is not specified as standard
into the handle. This affects __in128, unsigned __in128,


Spelling: __int128 (both times)


PowerPC specific __iee128 and __ibm128, and  _Float128 for architectures


__ieee128


where long double is not 128bits.

The bfloat16, _Float16, _Float32, _Float32, and _Float128 for
128bits long double are not are not addressed, as they
are transformed into standard floating point types.

For internal purposes __format::__visit_format_arg function is
used, that provides an umodifed access to stored object.


unmodified



PR libstdc++/108053

libstdc++-v3/ChangeLog:

* include/std/format (basic_format_arg::_M_visit_user):
Helper function for wrapping extension types into handle


Missing '.' at the end of the sentence.


(visit_format_arg): Call `_M_visit_user` instead of `_M_visit`.
(basic_format_arg::visit): As above.
(__format::__visit_format_arg): Provides direct access to
values stored in basic_format_arg.
(__format::__int_from_arg): Use __format::__visit_format_arg
instead of std::visit_format_arg.
(_Formatting_scanner::_M_format_arg): As above.
(_Checking_scanner::__do_vformat_to): As above.
* testsuite/std/format/arguments/args.cc: New tests.
* testsuite/std/format/string.cc: Test for using __int128
as width/precision.
---
Revision added missing decltype(auto) return type for lambda in _M_user_visit.
Tested on x84_64-linux. Tested arguments/args.cc` with -mlong-double-128.
Tested `std/format` test on ppc64le-linux, with both -mabi=ieeelongdouble and 
-mabi=ibmlongdouble.
OK for trunk?


Some more minor comments below, mostly typos in comments, but one
small change to _M_visit_user.

OK for trunk with those changes, thanks.



libstdc++-v3/include/std/format   | 49 +++--
.../testsuite/std/format/arguments/args.cc| 73 +++
libstdc++-v3/testsuite/std/format/string.cc   | 10 ++-
3 files changed, 123 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
index e7e0d2d142b..5085658cdb7 100644
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -3290,10 +3290,12 @@ namespace __format
  template
class _Arg_store;

+  template
+decltype(auto) __visit_format_arg(_Visitor&&, basic_format_arg<_Ctx>);
+
  template
consteval _Arg_t
__to_arg_t_enum() noexcept;
-
} // namespace __format
/// @endcond

@@ -3365,12 +3367,12 @@ namespace __format
  template
decltype(auto)
visit(this basic_format_arg __arg, _Visitor&& __vis)
-   { return __arg._M_visit(std::forward<_Visitor>(__vis), __arg._M_type); }
+   { return __arg._M_visit_user(std::forward<_Visitor>(__vis), 
__arg._M_type); }

  template
_Res
visit(this basic_format_arg __arg, _Visitor&& __vis)
-   { return __arg._M_visit(std::forward<_Visitor>(__vis), __arg._M_type); }
+   { return __arg._M_visit_user(std::forward<_Visitor>(__vis), 
__arg._M_type); }
#endif

private:
@@ -3587,6 +3589,10 @@ namespace __format
friend decltype(auto)
visit_format_arg(_Visitor&& __vis, basic_format_arg<_Ctx>);

+  template
+   friend decltype(auto)
+   __format::__visit_format_arg(_Visitor&&, basic_format_arg<_Ctx>);
+
  template
friend consteval __format::_Arg_t
__format::__to_arg_t_enum() noexcept;
@@ -3655,6 +3661,28 @@ namespace __format
  __builtin_unreachable();
  }
}
+
+  template
+   decltype(auto)
+   _M_visit_user(_Visitor&& __vis, __format::_Arg_t __type)
+   {
+ return _M_visit([&__vis](_Tp& __val) -> decltype(auto)
+   {
+ constexpr bool __user_facing = __is_one_of<_Tp,
+   monostate, bool, _CharT,


I think the only way it's possible to get a monostate here is for a
default constructed format arg, and visiting that is probably a
mistake. So let's put monostate at the end of this list, otherwise every
time we evaluate this __is_one_of check the first instantiation is
is_same<_Tp, monostate> which will fail nearly every time.



+   int, unsigned int, long long int, unsigned long long int,
+   float, double, long double,
+   const _CharT*, basic_string_view<_CharT>,
+   const void*, handle>::value;
+if constexpr (__user_facing)
+  return std::forward<_Visitor>(__vis)(__val);
+else
+  {
+handle __h(__val);
+return std::forward<_Visitor>(__vis)(__h);
+  }
+  }, __type);
+   }
};

  template
@@ -3662,12 +3690,19 @@ namespace __format
inline decltype(a

Re: The COBOL front end, version 3, now in 14 easy pieces

[Mark Wielaard]

Hi David,

On Mon, Mar 10, 2025 at 05:40:18PM -0400, David Malcolm wrote:
> FWIW gcc/cobol/lang.opt.urls has some D-specific things that look like
> copy-and-paste cruft, but hopefully it won't cause problems.

And some Fortran stuff. The autoregen bot currently flags it with the
following diff:

diff --git a/gcc/cobol/lang.opt.urls b/gcc/cobol/lang.opt.urls
index a0e1f1944fe..6a5dc1c0f58 100644
--- a/gcc/cobol/lang.opt.urls
+++ b/gcc/cobol/lang.opt.urls
@@ -10,20 +10,27 @@ UrlSuffix(gcc/Preprocessor-Options.html#index-D-1)
 I
 UrlSuffix(gcc/Directory-Options.html#index-I) 
LangUrlSuffix_D(gdc/Directory-Options.html#index-I)
 
+ffixed-form
+LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-ffixed-form)
+
 fsyntax-only
-UrlSuffix(gcc/Warning-Options.html#index-fsyntax-only) 
LangUrlSuffix_D(gdc/Warnings.html#index-fno-syntax-only)
+UrlSuffix(gcc/Warning-Options.html#index-fsyntax-only) 
LangUrlSuffix_D(gdc/Warnings.html#index-fno-syntax-only) 
LangUrlSuffix_Fortran(gfortran/Error-and-Warning-Options.html#index-fsyntax-only)
+
+ffree-form
+LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-ffree-form)
 
 fmax-errors
 UrlSuffix(gcc/Warning-Options.html#index-fmax-errors) 
LangUrlSuffix_D(gdc/Warnings.html#index-fmax-errors)
 
 iprefix
-UrlSuffix(gcc/Directory-Options.html#index-iprefix) 
LangUrlSuffix_D(gdc/Directory-Options.html#index-iprefix)
+UrlSuffix(gcc/Directory-Options.html#index-iprefix) 
LangUrlSuffix_D(gdc/Directory-Options.html#index-iprefix) 
LangUrlSuffix_Fortran(gfortran/Preprocessing-Options.html#index-iprefix)
 
 include
 UrlSuffix(gcc/Preprocessor-Options.html#index-include)
 
 isysroot
-UrlSuffix(gcc/Directory-Options.html#index-isysroot)
+UrlSuffix(gcc/Directory-Options.html#index-isysroot) 
LangUrlSuffix_Fortran(gfortran/Preprocessing-Options.html#index-isysroot)
 
 isystem
-UrlSuffix(gcc/Directory-Options.html#index-isystem)
+UrlSuffix(gcc/Directory-Options.html#index-isystem) 
LangUrlSuffix_Fortran(gfortran/Preprocessing-Options.html#index-isystem)
+

I don't really understand what these D and Fortran references are
for. Are these expected? Should we simply regenerate them with the
above diff? Or does the make regenerate-opt-urls target need an
update?

Cheers,

Mark

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

[Martin Uecker]

Am Mittwoch, dem 12.03.2025 um 16:58 + schrieb Joseph Myers:
> On Wed, 12 Mar 2025, Martin Uecker wrote:
> 
> > For a designator
> > 
> > struct foo { int n; } a = { .n = 1 };
> > 
> > we also refer to a member 'n' of an instance 'a' of a structure type.
> > The instance is simply implied by the context.
> > 
> > For 
> > 
> > struct foo { int n; char *x __counted_by(.n) };
> > 
> > is also refers to a member of an instance of the struct. The
> > instance is the 'a' which is later used in an expression 'a.x'
> > So the instance would again be implied by the context.
> > 
> > So for me this makes perfect sense in both cases (and
> > for both C and C++)
> 
> The main concern with the designator syntax is if you try to embed it in 
> arbitrary expressions (that is, say that __counted_by takes an expression, 
> but with an additional kind of primary-expression .IDENTIFIER that can be 
> used as a sub-expression therein).  The above is fine, but
> 
> struct foo { int n; char *x __counted_by((struct bar){.n = 1}.n };
> 
> leaves an ambiguity of whether ".n = 1" is a designated initializer in the 
> struct bar compound literal, or an assignment expression where .n refers 
> to the member of the struct foo for which the number of elements of x is 
> being counted.  Note that N3188 definitely does not allow .IDENTIFIER as 
> part of an expression, only as an alternative to an expression in an array 
> declarator.

My solution for this would be to simply state that in a position
in the grammar where a designator is allowed, this then has to be
parsed as a designator.  So if struct bar has no member 'n' this
would  be a syntax error.


Martin


> 

Re: [PATCH] libstdc++: fix compile error when converting std::weak_ptr

[Jonathan Wakely]

On Tue, 10 Dec 2024 at 00:59, Giuseppe D'Angelo
 wrote:
>
> Hello,
>
> The attached patch fixes a compile error when converting a weak_ptr of
> array type to a compatible type, for instance:
>
> std::weak_ptr wptr;
> std::weak_ptr wptr2 = wptr; // ERROR
>
> https://gcc.godbolt.org/z/EWYb73Mvf
>
> The reason seems to be a typo: the inner __weak_ptr class has a lock()
> implementation which doesn't work with arrays because it accidentally
> uses `element_type` instead of `_Tp`. That lock() (and *not*
> std::weak_ptr::lock(), which is instead fine) is called by the
> converting constructors of __weak_ptr and that causes the compile error.
>
> I'm not sure if this has been already reported somewhere.

I don't think so, not that I can remember.

> Tested on x86-64 Linux.

The newer version of this patch at
https://forge.sourceware.org/gcc/gcc-TEST/pulls/35 is OK for trunk,
thanks.

We should consider it for backporting too, since it's a C++17 feature
that isn't working correctly.

Re: [PATCH] builtins: Fix up strspn/strcspn folding [PR119219]

[Richard Biener]

On Wed, 12 Mar 2025, Jakub Jelinek wrote:

> Hi!
> 
> The PR119204 r15-7955 fix caused some regressions.
> The problem is that the fold_builtin* APIs document that expr is
> either a CALL_EXPR of the call or NULL, so using TREE_TYPE (expr)
> can crash e.g. during constexpr evaluation etc.
> 
> As can be seen in the surrounding patch, for the neighbouring builtins
> (both modf and strpbrk) fold_builtin_2 passes down type, which is the
> result type, TREE_TYPE (TREE_TYPE (fndecl)) and those builtins use it
> to build the return value, while strspn was always building size_type_node
> and strcspn had this change from that to TREE_TYPE (expr).
> The patch passes type to these two and uses it there as well.
> 
> The patch keeps passing expr because it is used in the
> check_nul_terminated_array calls done for both strspn and strcspn,
> those calls clearly can deal with NULL expr but prefer if it is non-NULL
> for some warning.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

> 2025-03-12  Jakub Jelinek  
> 
>   PR middle-end/119204
>   PR middle-end/119219
>   * builtins.cc (fold_builtin_2): Pass type as another argument
>   to fold_builtin_strspn and fold_builtin_strcspn.
>   (fold_builtin_strspn): Add type argument, use it instead of
>   size_type_node.
>   (fold_builtin_strcspn): Add type argument, use it instead of
>   TREE_TYPE (expr).
> 
> --- gcc/builtins.cc.jj2025-03-11 12:05:42.561533453 +0100
> +++ gcc/builtins.cc   2025-03-11 15:36:47.774314011 +0100
> @@ -176,8 +176,8 @@ static tree fold_builtin_iseqsig (locati
>  static tree fold_builtin_varargs (location_t, tree, tree*, int);
>  
>  static tree fold_builtin_strpbrk (location_t, tree, tree, tree, tree);
> -static tree fold_builtin_strspn (location_t, tree, tree, tree);
> -static tree fold_builtin_strcspn (location_t, tree, tree, tree);
> +static tree fold_builtin_strspn (location_t, tree, tree, tree, tree);
> +static tree fold_builtin_strcspn (location_t, tree, tree, tree, tree);
>  
>  static rtx expand_builtin_object_size (tree);
>  static rtx expand_builtin_memory_chk (tree, rtx, machine_mode,
> @@ -10800,10 +10800,10 @@ fold_builtin_2 (location_t loc, tree exp
>return fold_builtin_modf (loc, arg0, arg1, type);
>  
>  case BUILT_IN_STRSPN:
> -  return fold_builtin_strspn (loc, expr, arg0, arg1);
> +  return fold_builtin_strspn (loc, expr, arg0, arg1, type);
>  
>  case BUILT_IN_STRCSPN:
> -  return fold_builtin_strcspn (loc, expr, arg0, arg1);
> +  return fold_builtin_strcspn (loc, expr, arg0, arg1, type);
>  
>  case BUILT_IN_STRPBRK:
>return fold_builtin_strpbrk (loc, expr, arg0, arg1, type);
> @@ -11304,7 +11304,7 @@ fold_builtin_strpbrk (location_t loc, tr
> form of the builtin function call.  */
>  
>  static tree
> -fold_builtin_strspn (location_t loc, tree expr, tree s1, tree s2)
> +fold_builtin_strspn (location_t loc, tree expr, tree s1, tree s2, tree type)
>  {
>if (!validate_arg (s1, POINTER_TYPE)
>|| !validate_arg (s2, POINTER_TYPE))
> @@ -11320,8 +11320,7 @@ fold_builtin_strspn (location_t loc, tre
>if ((p1 && *p1 == '\0') || (p2 && *p2 == '\0'))
>  /* Evaluate and ignore both arguments in case either one has
> side-effects.  */
> -return omit_two_operands_loc (loc, size_type_node, size_zero_node,
> -   s1, s2);
> +return omit_two_operands_loc (loc, type, size_zero_node, s1, s2);
>return NULL_TREE;
>  }
>  
> @@ -11344,7 +11343,7 @@ fold_builtin_strspn (location_t loc, tre
> form of the builtin function call.  */
>  
>  static tree
> -fold_builtin_strcspn (location_t loc, tree expr, tree s1, tree s2)
> +fold_builtin_strcspn (location_t loc, tree expr, tree s1, tree s2, tree type)
>  {
>if (!validate_arg (s1, POINTER_TYPE)
>|| !validate_arg (s2, POINTER_TYPE))
> @@ -11360,8 +11359,7 @@ fold_builtin_strcspn (location_t loc, tr
>  {
>/* Evaluate and ignore argument s2 in case it has
>side-effects.  */
> -  return omit_one_operand_loc (loc, TREE_TYPE (expr),
> -size_zero_node, s2);
> +  return omit_one_operand_loc (loc, type, size_zero_node, s2);
>  }
>  
>/* If the second argument is "", return __builtin_strlen(s1).  */
> @@ -11375,7 +11373,7 @@ fold_builtin_strcspn (location_t loc, tr
>if (!fn)
>   return NULL_TREE;
>  
> -  return fold_convert_loc (loc, TREE_TYPE (expr),
> +  return fold_convert_loc (loc, type,
>  build_call_expr_loc (loc, fn, 1, s1));
>  }
>return NULL_TREE;
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

Re: [PATCH][v3] Simple cobol.dg testsuite

[Jakub Jelinek]

On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:
> Earlier in this discussion of a testsuite, the question came up about
> generating an error return in COBOL source code.
> 
> In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;".  When
> executed in  the initial "top-level" program-id, it results in the value 1
> being passed back to the _start stub.
> 
> "STOP RUN ERROR 1." is the equivalent of (and is in fact implemented with)
> "exit(1)".

Note, in most of the testsuite we try to signal failure from a runtime
testcase through calling abort (or e.g. fortran STOP N statement).
On Linux at least when not cross-compiling, exit(1) (or this
STOP RUN ERROR 1) will work as well, I believe the reason is for some
bare metal targets which just don't propagate return value from main or
exit back to the dejagnu testing framework.
Does COBOL have something that is implemented as call to abort()?

Jakub

Re: [PATCH] builtins: Fix up strspn/strcspn folding [PR119219]

[Jakub Jelinek]

On Wed, Mar 12, 2025 at 12:04:52AM -0700, Andrew Pinski wrote:
> I think it would be useful to add the C testcase that fails during DOM
> from PR 119226 since that is another path to get the ICE.

I've committed the patch already.
Feel free to commit the testcase for it (preferably a little bit cleaned
up, replacing the fancy identifiers in the test with something short and
__SIZE_TYPE__ as return type from strcspn prototype).

Jakub

Re: [PATCH] libstdc++: Reject basic_format_parse_context::check_dynamic_spec<>(n)

[Tomasz Kaminski]

On Tue, Mar 11, 2025 at 10:14 PM Jonathan Wakely  wrote:

> LWG 4142 (approved in Wrocław, November 2024) made it ill-formed to call
> basic_format_parse_context::check_dynamic_spec with an empty template
> argument list.
>
> This adds a static_assert to enforce that, and adjusts the tests.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/format
> (basic_format_parse_context::check_dynamic_spec): Require a
> non-empty parameter pack, as per LWG 4142.
> * testsuite/std/format/parse_ctx.cc: Remove call of
> check_dynamic_spec with empty template argument list.
> * testsuite/std/format/parse_ctx_neg.cc: Add dg-error to call of
> check_dynamic_spec with empty template argument list.
> ---
>
> Tested x86_64-linux.
>
LGTM

>
>  libstdc++-v3/include/std/format| 3 +++
>  libstdc++-v3/testsuite/std/format/parse_ctx.cc | 1 -
>  libstdc++-v3/testsuite/std/format/parse_ctx_neg.cc | 8 ++--
>  3 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/format
> b/libstdc++-v3/include/std/format
> index e7e0d2d142b..0d6cc7f6bef 100644
> --- a/libstdc++-v3/include/std/format
> +++ b/libstdc++-v3/include/std/format
> @@ -4338,6 +4338,9 @@ namespace __format
>  constexpr void
>  basic_format_parse_context<_CharT>::check_dynamic_spec(size_t __id)
> noexcept
>  {
> +  // _GLIBCXX_RESOLVE_LIB_DEFECTS
> +  // 4142. check_dynamic_spec should require at least one type
> +  static_assert(sizeof...(_Ts) >= 1);
>// This call enforces the Mandates: condition that _Ts contains
> valid
>// types and each type appears at most once. It could be a
> static_assert
>// but this way failures give better diagnostics, due to calling the
> diff --git a/libstdc++-v3/testsuite/std/format/parse_ctx.cc
> b/libstdc++-v3/testsuite/std/format/parse_ctx.cc
> index 88ffd77debe..b5dd7cdba78 100644
> --- a/libstdc++-v3/testsuite/std/format/parse_ctx.cc
> +++ b/libstdc++-v3/testsuite/std/format/parse_ctx.cc
> @@ -491,7 +491,6 @@ test_dynamic_type_check()
>std::format_parse_context pc("{1}.{2}");
>
>// None of these calls should do anything at runtime, only during
> consteval:
> -  pc.check_dynamic_spec<>(0);
>pc.check_dynamic_spec(0);
>pc.check_dynamic_spec_integral(0);
>pc.check_dynamic_spec_string(0);
> diff --git a/libstdc++-v3/testsuite/std/format/parse_ctx_neg.cc
> b/libstdc++-v3/testsuite/std/format/parse_ctx_neg.cc
> index f19107c886f..d83fd8c7a7b 100644
> --- a/libstdc++-v3/testsuite/std/format/parse_ctx_neg.cc
> +++ b/libstdc++-v3/testsuite/std/format/parse_ctx_neg.cc
> @@ -12,8 +12,9 @@ test_invalid()
>pc.check_dynamic_spec unsigned long long, float, double, long double,
> const char*, std::string_view, const void*>(0);
> -  // For some reason, an empty pack of types is valid:
> -  pc.check_dynamic_spec<>(0);
> +
> +  // LWG 4142. check_dynamic_spec should require at least one type
> +  pc.check_dynamic_spec<>(0); // { dg-error "here" }
>
>pc.check_dynamic_spec(0); // { dg-error "here" }
>// const void* is allowed, but void* is not
> @@ -25,6 +26,7 @@ test_invalid()
>pc.check_dynamic_spec(0); // { dg-error "here" }
>// std::string_view is allowed, but std::string is not
>pc.check_dynamic_spec(0); // { dg-error "here" }
> +  // The types in the pack must be unique.
>pc.check_dynamic_spec(0); // { dg-error "here" }
>
>std::wformat_parse_context wpc(L"");
> @@ -38,3 +40,5 @@ test_invalid()
>
>  // Each failure above will point to a call to this non-constexpr function:
>  // { dg-error "__invalid_dynamic_spec" "" { target *-*-* } 0 }
> +// Except the check_dynamic_spec<>(0) one for LWG 4142 which matches this:
> +// { dg-error "static assertion failed" "" { target *-*-* } 0 }
> --
> 2.48.1
>
>

gcc-patches@gcc.gnu.org

[Tomasz Kaminski]

On Tue, Mar 11, 2025 at 10:22 PM Jonathan Wakely  wrote:

> LWG 4154 (approved in Wrocław, November 2024) fixed the Mandates:
> precondition for std::packaged_task::packaged_task(F&&) to match what
> the implementation actually requires. We already gave a diagnostic in
> the right cases as required by the issue resolution, so strictly
> speaking we don't need to do anything. But the current diagnostic comes
> from inside the implementation of std::__invoke_r and could be more
> user-friendly.
>
> For C++17 (when std::is_invocable_r_v is available) add a static_assert
> to the constructor, so the error is clear:
>
> .../include/c++/15.0.1/future: In instantiation of
> 'std::packaged_task<_Res(_ArgTypes ...)>::packaged_task(_Fn&&) [with _Fn =
> const F&;  = void; _Res = void; _ArgTypes = {}]':
> lwg4154_neg.cc:15:31:   required from here
>15 | std::packaged_task p(f); // { dg-error "here" "" { target
> c++17 } }
>   |   ^
> .../include/c++/15.0.1/future:1575:25: error: static assertion failed
>  1575 |   static_assert(is_invocable_r_v<_Res, decay_t<_Fn>&,
> _ArgTypes...>);
>   |
>  ^~~
>
> Also add a test to confirm we get a diagnostic as the standard requires.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/future (packaged_task::packaged_task(F&&)): Add
> static_assert.
> * testsuite/30_threads/packaged_task/cons/dangling_ref.cc: Add
> dg-error for new static assertion.
> * testsuite/30_threads/packaged_task/cons/lwg4154_neg.cc: New
> test.
> ---
>
> Tested x86_64-linux.
>
>  libstdc++-v3/include/std/future   |  9 -
>  .../packaged_task/cons/dangling_ref.cc|  1 +
>  .../packaged_task/cons/lwg4154_neg.cc | 36 +++
>  3 files changed, 45 insertions(+), 1 deletion(-)
>  create mode 100644
> libstdc++-v3/testsuite/30_threads/packaged_task/cons/lwg4154_neg.cc
>
> diff --git a/libstdc++-v3/include/std/future
> b/libstdc++-v3/include/std/future
> index 2a855f262a0..b7ab233b85f 100644
> --- a/libstdc++-v3/include/std/future
> +++ b/libstdc++-v3/include/std/future
> @@ -1567,7 +1567,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> packaged_task(_Fn&& __fn)
> : _M_state(
>
> __create_task_state<_Res(_ArgTypes...)>(std::forward<_Fn>(__fn)))
> -   { }
> +   {
> +#ifdef __cpp_lib_is_invocable // C++ >= 17
> + // _GLIBCXX_RESOLVE_LIB_DEFECTS
> + // 4154. The Mandates for std::packaged_task's constructor
> + // from a callable entity should consider decaying
> + static_assert(is_invocable_r_v<_Res, decay_t<_Fn>&,
> _ArgTypes...>);
> +#endif
> +   }
>
>  #if __cplusplus < 201703L
>// _GLIBCXX_RESOLVE_LIB_DEFECTS
> diff --git
> a/libstdc++-v3/testsuite/30_threads/packaged_task/cons/dangling_ref.cc
> b/libstdc++-v3/testsuite/30_threads/packaged_task/cons/dangling_ref.cc
> index 225b65fe6a7..51c6ade91c3 100644
> --- a/libstdc++-v3/testsuite/30_threads/packaged_task/cons/dangling_ref.cc
> +++ b/libstdc++-v3/testsuite/30_threads/packaged_task/cons/dangling_ref.cc
> @@ -10,3 +10,4 @@ std::packaged_task task(f);
>  // { dg-error "reference to temporary" "" { target { c++14_down } } 0 }
>  // { dg-error "no matching function" "" { target c++17 } 0 }
>  // { dg-error "enable_if" "" { target c++17 } 0 }
> +// { dg-error "static assertion failed" "" { target c++17 } 0 }
> diff --git
> a/libstdc++-v3/testsuite/30_threads/packaged_task/cons/lwg4154_neg.cc
> b/libstdc++-v3/testsuite/30_threads/packaged_task/cons/lwg4154_neg.cc
> new file mode 100644
> index 000..57472a3d798
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/30_threads/packaged_task/cons/lwg4154_neg.cc
> @@ -0,0 +1,36 @@
> +// { dg-do compile { target c++11 } }
> +
> +// LWG 4154. The Mandates for std::packaged_task's constructor from
> +// a callable entity should consider decaying
> +
> +#include 
> +
> +struct F {
> +  void operator()() & = delete;
> +  void operator()() const & { }
> +};
> +
> +// Mandates: is_invocable_r_v&, ArgTypes...> is true.
> +const F f;
> +std::packaged_task p(f); // { dg-error "here" "" { target c++17 }
> }
> +// { dg-error "static assertion failed" "" { target c++17 } 0 }
> +// { dg-error "invoke_r" "" { target *-*-* } 0 }
> +// { dg-prune-output "enable_if
Could you add a test for functor that is only rvalue-callable (only
operator() &&).
There was discussion about this case on reflector, so I think it would be
good to document that they are not supported.

> +
> +namespace good
> +{
> +  struct F {
> +void operator()() const & = delete;
> +void operator()() & { }
> +  };
> +
> +  // In C++11/14/17/20 std::packaged_task::packaged_task(F&&)
> incorrectly
> +  // required that the callable passed to the constructor can be invoked.
> +  // If the type of the parameter is const F& we might not be able to
> invoke
> +  // the parameter, but that's OK because we store and invoke a non-con

Re: [PATCH] libstdc++: Prevent dangling references in std::unique_ptr::operator*

[Tomasz Kaminski]

On Tue, Mar 11, 2025 at 10:26 PM Jonathan Wakely  wrote:

> LWG 4148 (approved in Wrocław, November 2024) makes it ill-formed to
> dereference a std::unique_ptr if that would return a dangling reference.
>
> That can happen with a custom pointer type and a const-qualified
> element_type, such that std::add_lvalue_reference_t is a
> reference-to-const that could bind to a short-lived temporary.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/unique_ptr.h (unique_ptr::operator*): Add
> static_assert to check for dangling reference, as per LWG 4148.
> * testsuite/20_util/unique_ptr/lwg4148.cc: New test.
> ---
>
> Tested x86_64-linux.
>
LGTM.
In C++26 binding reference to temporary in the return is ill-formed per
language rules,
but it's good QoI to raise these errors in eariel standards.

>
>  libstdc++-v3/include/bits/unique_ptr.h|  8 +
>  .../testsuite/20_util/unique_ptr/lwg4148.cc   | 31 +++
>  2 files changed, 39 insertions(+)
>  create mode 100644 libstdc++-v3/testsuite/20_util/unique_ptr/lwg4148.cc
>
> diff --git a/libstdc++-v3/include/bits/unique_ptr.h
> b/libstdc++-v3/include/bits/unique_ptr.h
> index 746989dfe47..6ae46a93800 100644
> --- a/libstdc++-v3/include/bits/unique_ptr.h
> +++ b/libstdc++-v3/include/bits/unique_ptr.h
> @@ -445,6 +445,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>typename add_lvalue_reference::type
>operator*() const noexcept(noexcept(*std::declval()))
>{
> +#if _GLIBCXX_USE_BUILTIN_TRAIT(__reference_converts_from_temporary)
> +   // _GLIBCXX_RESOLVE_LIB_DEFECTS
> +   // 4148. unique_ptr::operator* should not allow dangling references
> +   using _ResT = typename add_lvalue_reference::type;
> +   using _DerefT = decltype(*get());
> +   static_assert(!__reference_converts_from_temporary(_ResT, _DerefT),
> + "operator* must not return a dangling reference");
> +#endif
> __glibcxx_assert(get() != pointer());
> return *get();
>}
> diff --git a/libstdc++-v3/testsuite/20_util/unique_ptr/lwg4148.cc
> b/libstdc++-v3/testsuite/20_util/unique_ptr/lwg4148.cc
> new file mode 100644
> index 000..c70d7a60631
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/20_util/unique_ptr/lwg4148.cc
> @@ -0,0 +1,31 @@
> +// { dg-do compile { target c++11 } }
> +
> +// LWG 4148. unique_ptr::operator* should not allow dangling references
> +
> +#include 
> +
> +struct pointer
> +{
> +  pointer() { }
> +  pointer(std::nullptr_t) { }
> +  int operator*() const { return 0; }
> +  bool operator==(pointer) const { return true; }
> +  bool operator==(std::nullptr_t) const { return false; }
> +#ifndef __cpp_lib_three_way_comparison
> +  bool operator!=(pointer) const { return false; }
> +  bool operator!=(std::nullptr_t) const { return true; }
> +#endif
> +};
> +
> +struct Deleter
> +{
> +  using pointer = ::pointer;
> +  void operator()(pointer) const { }
> +};
> +
> +std::unique_ptr up;
> +int i = *up; // { dg-error "here" }
> +// { dg-error "dangling reference" "" { target *-*-* } 0 }
> +
> +// { dg-warning "returning reference to temporary" "" { target c++23_down
> } 0 }
> +// { dg-error "returning reference to temporary" "" { target c++26 } 0 }
> --
> 2.48.1
>
>

Re: [PATCH] builtins: Fix up strspn/strcspn folding [PR119219]

[Andrew Pinski]

On Wed, Mar 12, 2025 at 12:01 AM Jakub Jelinek  wrote:
>
> Hi!
>
> The PR119204 r15-7955 fix caused some regressions.
> The problem is that the fold_builtin* APIs document that expr is
> either a CALL_EXPR of the call or NULL, so using TREE_TYPE (expr)
> can crash e.g. during constexpr evaluation etc.
>
> As can be seen in the surrounding patch, for the neighbouring builtins
> (both modf and strpbrk) fold_builtin_2 passes down type, which is the
> result type, TREE_TYPE (TREE_TYPE (fndecl)) and those builtins use it
> to build the return value, while strspn was always building size_type_node
> and strcspn had this change from that to TREE_TYPE (expr).
> The patch passes type to these two and uses it there as well.
>
> The patch keeps passing expr because it is used in the
> check_nul_terminated_array calls done for both strspn and strcspn,
> those calls clearly can deal with NULL expr but prefer if it is non-NULL
> for some warning.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

I think it would be useful to add the C testcase that fails during DOM
from PR 119226 since that is another path to get the ICE.

Thanks,
Andrew Pinski

>
> 2025-03-12  Jakub Jelinek  
>
> PR middle-end/119204
> PR middle-end/119219
> * builtins.cc (fold_builtin_2): Pass type as another argument
> to fold_builtin_strspn and fold_builtin_strcspn.
> (fold_builtin_strspn): Add type argument, use it instead of
> size_type_node.
> (fold_builtin_strcspn): Add type argument, use it instead of
> TREE_TYPE (expr).
>
> --- gcc/builtins.cc.jj  2025-03-11 12:05:42.561533453 +0100
> +++ gcc/builtins.cc 2025-03-11 15:36:47.774314011 +0100
> @@ -176,8 +176,8 @@ static tree fold_builtin_iseqsig (locati
>  static tree fold_builtin_varargs (location_t, tree, tree*, int);
>
>  static tree fold_builtin_strpbrk (location_t, tree, tree, tree, tree);
> -static tree fold_builtin_strspn (location_t, tree, tree, tree);
> -static tree fold_builtin_strcspn (location_t, tree, tree, tree);
> +static tree fold_builtin_strspn (location_t, tree, tree, tree, tree);
> +static tree fold_builtin_strcspn (location_t, tree, tree, tree, tree);
>
>  static rtx expand_builtin_object_size (tree);
>  static rtx expand_builtin_memory_chk (tree, rtx, machine_mode,
> @@ -10800,10 +10800,10 @@ fold_builtin_2 (location_t loc, tree exp
>return fold_builtin_modf (loc, arg0, arg1, type);
>
>  case BUILT_IN_STRSPN:
> -  return fold_builtin_strspn (loc, expr, arg0, arg1);
> +  return fold_builtin_strspn (loc, expr, arg0, arg1, type);
>
>  case BUILT_IN_STRCSPN:
> -  return fold_builtin_strcspn (loc, expr, arg0, arg1);
> +  return fold_builtin_strcspn (loc, expr, arg0, arg1, type);
>
>  case BUILT_IN_STRPBRK:
>return fold_builtin_strpbrk (loc, expr, arg0, arg1, type);
> @@ -11304,7 +11304,7 @@ fold_builtin_strpbrk (location_t loc, tr
> form of the builtin function call.  */
>
>  static tree
> -fold_builtin_strspn (location_t loc, tree expr, tree s1, tree s2)
> +fold_builtin_strspn (location_t loc, tree expr, tree s1, tree s2, tree type)
>  {
>if (!validate_arg (s1, POINTER_TYPE)
>|| !validate_arg (s2, POINTER_TYPE))
> @@ -11320,8 +11320,7 @@ fold_builtin_strspn (location_t loc, tre
>if ((p1 && *p1 == '\0') || (p2 && *p2 == '\0'))
>  /* Evaluate and ignore both arguments in case either one has
> side-effects.  */
> -return omit_two_operands_loc (loc, size_type_node, size_zero_node,
> - s1, s2);
> +return omit_two_operands_loc (loc, type, size_zero_node, s1, s2);
>return NULL_TREE;
>  }
>
> @@ -11344,7 +11343,7 @@ fold_builtin_strspn (location_t loc, tre
> form of the builtin function call.  */
>
>  static tree
> -fold_builtin_strcspn (location_t loc, tree expr, tree s1, tree s2)
> +fold_builtin_strcspn (location_t loc, tree expr, tree s1, tree s2, tree type)
>  {
>if (!validate_arg (s1, POINTER_TYPE)
>|| !validate_arg (s2, POINTER_TYPE))
> @@ -11360,8 +11359,7 @@ fold_builtin_strcspn (location_t loc, tr
>  {
>/* Evaluate and ignore argument s2 in case it has
>  side-effects.  */
> -  return omit_one_operand_loc (loc, TREE_TYPE (expr),
> -  size_zero_node, s2);
> +  return omit_one_operand_loc (loc, type, size_zero_node, s2);
>  }
>
>/* If the second argument is "", return __builtin_strlen(s1).  */
> @@ -11375,7 +11373,7 @@ fold_builtin_strcspn (location_t loc, tr
>if (!fn)
> return NULL_TREE;
>
> -  return fold_convert_loc (loc, TREE_TYPE (expr),
> +  return fold_convert_loc (loc, type,
>build_call_expr_loc (loc, fn, 1, s1));
>  }
>return NULL_TREE;
>
> Jakub
>

Re: [PATCH] libstdc++: Make range adaptor __has_arrow helper use a const type

[Tomasz Kaminski]

On Tue, Mar 11, 2025 at 10:28 PM Jonathan Wakely  wrote:

> LWG 4112 (approved in Wrocław, November 2024) changes the has-arrow
> helper to require operator-> to be valid on a const-qualified lvalue.
> This affects the constraints for filter_view::_Iterator::operator-> and
> join_view::_Iterator::operator-> so that they can only be used if the
> underlying iterator supports operator-> on const.
>
> The change also adds semantic (i.e. not checkable and not enforced)
> requirements that operator-> must have the same semantics whether called
> on a const or non-const value, and on an lvalue or rvalue (due to the
> implicit expression variation rules in [concepts.equality]).
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_util.h (ranges::_detail::__has_arrow):
> Require operator->() to be valid on const-qualified type, as per
> LWG 4112.
> * testsuite/std/ranges/adaptors/lwg4112.cc: New test.
> ---
>
> Tested x86_64-linux.
>
LGTM

>
>  libstdc++-v3/include/bits/ranges_util.h   |  5 ++-
>  .../testsuite/std/ranges/adaptors/lwg4112.cc  | 41 +++
>  2 files changed, 45 insertions(+), 1 deletion(-)
>  create mode 100644 libstdc++-v3/testsuite/std/ranges/adaptors/lwg4112.cc
>
> diff --git a/libstdc++-v3/include/bits/ranges_util.h
> b/libstdc++-v3/include/bits/ranges_util.h
> index 54e4f6261b0..53b7f5c17f1 100644
> --- a/libstdc++-v3/include/bits/ranges_util.h
> +++ b/libstdc++-v3/include/bits/ranges_util.h
> @@ -54,9 +54,12 @@ namespace ranges
> && same_as, iterator_t>
> && same_as, sentinel_t>;
>
> +// _GLIBCXX_RESOLVE_LIB_DEFECTS
> +// 4112. has-arrow should required operator->() to be const-qualified
>  template
>concept __has_arrow = input_iterator<_It>
> -   && (is_pointer_v<_It> || requires(_It __it) { __it.operator->();
> });
> +   && (is_pointer_v<_It>
> + || requires(const _It __it) { __it.operator->(); });
>
>  using std::__detail::__different_from;
>} // namespace __detail
> diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/lwg4112.cc
> b/libstdc++-v3/testsuite/std/ranges/adaptors/lwg4112.cc
> new file mode 100644
> index 000..a283504b636
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/std/ranges/adaptors/lwg4112.cc
> @@ -0,0 +1,41 @@
> +// { dg-do compile { target c++20 } }
> +
> +// LWG 4112. has-arrow should required operator->() to be const-qualified
> +
> +// The issue resolution means that range adaptors which use has-arrow to
> +// constrain their iterator's operator-> should require a const-qualified
> +// operator-> on the underlying view's iterator.
> +
> +#include 
> +
> +struct Int { int i = 0; };
> +
> +struct Iter
> +{
> +  using value_type = Int;
> +  using difference_type = int;
> +
> +  mutable Int val;
> +
> +  Int& operator*() const { return val; }
> +  Int* operator->() /* non-const */ { return &val; }
> +  Iter& operator++() { ++val.i; return *this; }
> +  void operator++(int) { ++val.i; }
> +  bool operator==(const Iter& j) const { return val.i == j.val.i; }
> +};
> +
> +template
> +concept has_op_arrow = requires (T t) { t.operator->(); };
> +
> +static_assert( has_op_arrow );
> +static_assert( ! has_op_arrow );
> +
> +using Range = std::ranges::subrange;
> +using Pred = bool(*)(Int);
> +using FilterView = std::ranges::filter_view;
> +using FilterIterator = std::ranges::iterator_t;
> +
> +static_assert( ! has_op_arrow );
> +static_assert( ! has_op_arrow );
> +static_assert( ! has_op_arrow );
> +static_assert( ! has_op_arrow );
> --
> 2.48.1
>
>

Re: [PATCH] libstdc++: Optimize basic_format_parse_context::__check_dynamic_spec_types

[Tomasz Kaminski]

On Tue, Mar 11, 2025 at 11:46 PM Jonathan Wakely  wrote:

> This change makes the consteval function slightly faster to compile.
> Instead of keeping the counts in an array and looping over that array,
> we can just keep a sum of how many valid types are present, and check
> that it equals the total number of types in the pack. We can also avoid
> doing the check entirely for the common cases where the call comes from
> check_dynamic_spec_integer or check_dynamic_spec_string, because those
> always use valid lists of types.
>
> The diagnostic is slightly worse now, because there's only a single
> "invalid template argument types" string that appears in the output,
> where previously we had either "non-unique template argument type" or
> "disallowed template argument type" depending on the failure mode.
>
> Given that most users will never use this function directly, and
> probably won't use invalid types anyway, the inferior diagnostic seems
> acceptable.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/format (basic_format_parse_context::__check_types):
> New variable template and partial specializations.
> (basic_format_parse_context::__check_dynamic_spec_types):
> Simplify for faster compilation.
> (basic_format_parse_context::check_dynamic_spec): Only use
> __check_dynamic_spec_types when __check_types is true. Use it as
> the condition for a constexpr if statement instead of as the
> initializer for a constexpr variable.
> (basic_format_parse_context::check_dynamic_spec_string): Use
> _CharT instead of char_type consistently.
> ---
>
> Tested x86_64-linux.
>
>  libstdc++-v3/include/std/format | 81 +++--
>  1 file changed, 47 insertions(+), 34 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/format
> b/libstdc++-v3/include/std/format
> index 0d6cc7f6bef..6269cbb80e6 100644
> --- a/libstdc++-v3/include/std/format
> +++ b/libstdc++-v3/include/std/format
> @@ -305,41 +305,51 @@ namespace __format
>constexpr void
>check_dynamic_spec_string(size_t __id) noexcept
>{
> -   check_dynamic_spec basic_string_view<_CharT>>(__id);
> +   check_dynamic_spec>(__id);
>}
>
>  private:
> -  // Check the Mandates: condition for check_dynamic_spec(n)
> +  template
> +   static constexpr bool __once = (is_same_v<_Tp, _Ts> + ...) == 1;
> +
> +  // True if we need to call __check_dynamic_spec_types for the pack
> Ts
> +  template
> +   static constexpr bool __check_types = sizeof...(_Ts) > 0;
> +  // The pack used by check_dynamic_spec_integral is valid, don't
> check it.
> +  // FIXME: simplify these when PR c++/85282 is supported.
> +  template
> +   static constexpr bool
> +   __check_types<_Tp, unsigned, long long, unsigned long long>
> + = ! is_same_v<_Tp, int>;
>
These seem to produce wrong answer (false) if the user called
check_dynamic_spec, unsigned, long long, unsigned
long long>,
which is a valid set of types.

> +  // The pack used by check_dynamic_spec_string is valid, don't check
> it.
> +  template
> +   static constexpr bool
> +   __check_types<_Tp, basic_string_view<_CharT>>
> + = ! is_same_v;
>
As above check_dynamic_spec>.
I think much batter solution would be to have __check_dynamic_spec
private function,
that would not perform the check at all and will be called without checking
from check_dynamic_spec_integrral, e.t.c.
And in check_dynamic_spec, we would do __check_dynamic_spec_types<_Ts...>()
and sizeof..(Ts) > 0, before
calling __check_dynamic_spec.

+
> +  // Check the Mandates: conditions for check_dynamic_spec(n)
>template
> static consteval bool
> __check_dynamic_spec_types()
> {
> - if constexpr (sizeof...(_Ts))
> -   {
> - int __counts[] = {
> -   (is_same_v + ...),
> -   (is_same_v<_CharT, _Ts> + ...),
> -   (is_same_v + ...),
> -   (is_same_v + ...),
> -   (is_same_v + ...),
> -   (is_same_v + ...),
> -   (is_same_v + ...),
> -   (is_same_v + ...),
> -   (is_same_v + ...),
> -   (is_same_v + ...),
> -   (is_same_v, _Ts> + ...),
> -   (is_same_v + ...)
> - };
> - int __sum = 0;
> - for (int __c : __counts)
> -   {
> - __sum += __c;
> - if (__c > 1)
> -   __invalid_dynamic_spec("non-unique template argument
> type");
> -   }
> - if (__sum != sizeof...(_Ts))
> -   __invalid_dynamic_spec("disallowed template argument
> type");
> -   }
> + // The types in Ts... are unique. Each type in Ts... is one of
> + // bool, char_type, int, unsigned int, long long int,
> + // unsigned long long int, float, double, long

[committed] testsuite: Add testcase for already fixed PR [PR119226]

[Jakub Jelinek]

Hi!

On Wed, Mar 12, 2025 at 08:31:27AM +0100, Jakub Jelinek wrote:
> On Wed, Mar 12, 2025 at 12:04:52AM -0700, Andrew Pinski wrote:
> > I think it would be useful to add the C testcase that fails during DOM
> > from PR 119226 since that is another path to get the ICE.
> 
> I've committed the patch already.
> Feel free to commit the testcase for it (preferably a little bit cleaned
> up, replacing the fancy identifiers in the test with something short and
> __SIZE_TYPE__ as return type from strcspn prototype).

I went ahead and committed this as obvious:

2025-03-12  Jakub Jelinek  

PR middle-end/119226
* gcc.c-torture/compile/pr119226.c: New test.

--- gcc/testsuite/gcc.c-torture/compile/pr119226.c.jj   2025-03-12 
10:32:12.600079450 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr119226.c  2025-03-12 
10:31:51.832364744 +0100
@@ -0,0 +1,12 @@
+/* PR middle-end/119226 */
+
+char a[64];
+void bar (void);
+
+void
+foo (int x)
+{
+  char *b = a + __builtin_strcspn (a, x ? "" : "ab");
+  if (b[0])
+bar ();
+}


Jakub

Re: [PATCH 1/2] match.pd: Fold ((X >> C1) & C2) * (1 << C1)

[Richard Sandiford]

Thanks for the review!

Andrew Pinski  writes:
> On Wed, Mar 12, 2025 at 12:00 PM Richard Sandiford
>  wrote:
>>
>> Using a combination of rules, we were able to fold
>>
>>   ((X >> C1) & C2) * (1 << C1)  -->  X & (C2 << C1)
>>
>> if everything was done at the same precision, but we couldn't fold
>> it if the AND was done at a different precision.  The optimisation is
>> often (but not always) valid for that case too.
>>
>> This patch adds a dedicated rule for the case where different precisions
>> are involved.
>>
>> An alternative would be to extend the individual folds that together
>> handle the same-precision case so that those rules handle differing
>> precisions.  But the risk is that that could replace narrow operations
>> with wide operations, which would be especially harmful on targets
>> like avr.  It's also not obviously free of cycles.
>>
>> I also wondered whether the converts should be non-optional.
>>
>> gcc/
>> * match.pd: Fold ((X >> C1) & C2) * (1 << C1) to X & (C2 << C1).
>>
>> gcc/testsuite/
>> * gcc.dg/fold-mul-and-lshift-1.c: New test.
>> * gcc.dg/fold-mul-and-lshift-2.c: Likewise.
>> ---
>>  gcc/match.pd | 29 ++
>>  gcc/testsuite/gcc.dg/fold-mul-and-lshift-1.c | 59 
>>  gcc/testsuite/gcc.dg/fold-mul-and-lshift-2.c | 15 +
>>  3 files changed, 103 insertions(+)
>>  create mode 100644 gcc/testsuite/gcc.dg/fold-mul-and-lshift-1.c
>>  create mode 100644 gcc/testsuite/gcc.dg/fold-mul-and-lshift-2.c
>>
>> diff --git a/gcc/match.pd b/gcc/match.pd
>> index 5c679848bdf..3197d1cac75 100644
>> --- a/gcc/match.pd
>> +++ b/gcc/match.pd
>> @@ -5231,6 +5231,35 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>>   (if (mask)
>>(bit_op (shift (convert @0) @1) { mask; })))
>>
>> +/* Fold ((X >> C1) & C2) * (1 << C1) into X & (C2 << C1), including cases 
>> where
>> +   the & happens in a different type.  It is the conversion case that isn't
>> +   a composition of other folds.
>> +
>> +   Let the type of the * and >> be T1 and the type of the & be T2.
>> +   The fold is valid if the conversion to T2 preserves all information;
>> +   that is, if T2 is wider than T1 or drops no more than C1 bits from T1.
>> +   In that case, the & might operate on bits that are dropped by the
>> +   later conversion to T1 and the multiplication by (1 << C1), but those
>> +   bits are also dropped by ANDing with C2 << C1 (converted to T1).
>> +
>> +   If the conversion to T2 is not information-preserving, we have to be
>> +   careful about the later conversion to T1 acting as a sign extension.
>> +   We need either T2 to be unsigned or the top (sign) bit of C2 to be clear.
>> +   That is equivalent to testing whether C2 is nonnegative.  */
>> +(simplify
>> + (mult
>> +  (convert? (bit_and (convert? (rshift @0 INTEGER_CST@1)) INTEGER_CST@2))
>> +  INTEGER_CST@3)
>> + (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
>> +  (with { auto prec = element_precision (type); }
> Since we know this needs to be a scalar, Using TREE_PRECISION here is fine 
> too.

Yeah, agreed.  I'd wondered whether to use TREE_PRECISION instead,
but then I'd also wondered about trying to make the fold work for ectors.
Guess I ended up between two stools.

>> +   (if (wi::ltu_p (wi::to_widest (@1), prec))
>
> I think using wi::to_wide is better than using wi::to_widest here.

What's the reason for preferring wi::to_wide?  wi::to_widest should
usually be more efficient for this kind of check, since the tree
representation allows the underlying HWIs to be used directly.
wi::to_wide instead requires masking off bits above the precision.

E.g. on an --enable-checking=release compiler:

bool
foo (tree t, unsigned int n)
{
  return wi::ltu_p (wi::to_widest (t), n);
}

gives:

188c:   79400c02ldrhw2, [x0, #6]
1890:   7100045fcmp w2, #0x1
1894:   5460b.eq18a0   // b.none
1898:   5280mov w0, #0x0// #0
189c:   d65f03c0ret
18a0:   f9400800ldr x0, [x0, #16]
18a4:   eb21401fcmp x0, w1, uxtw
18a8:   1a9f27e0csetw0, cc  // cc = lo, ul, last
18ac:   d65f03c0ret

whereas:

bool
foo (tree t, unsigned int n)
{
  return wi::ltu_p (wi::to_wide (t), n);
}

gives:

188c:   79400802ldrhw2, [x0, #4]
1890:   7100045fcmp w2, #0x1
1894:   5460b.eq18a0   // b.none
1898:   5280mov w0, #0x0// #0
189c:   d65f03c0ret
18a0:   a9408800ldp x0, x2, [x0, #8]
18a4:   79406c03ldrhw3, [x0, #54]
18a8:   9280mov x0, #0x // #-1
18ac:   7100fc7fcmp w3, #0x3f
18b0:   9ac32000lsl x0, x0, x3
18b4:   8a200040bic x0, x2, x0
18b8

Re: [PATCH 1/2] match.pd: Fold ((X >> C1) & C2) * (1 << C1)

[Andrew Pinski]

On Wed, Mar 12, 2025 at 1:38 PM Richard Sandiford
 wrote:
>
> Thanks for the review!
>
> Andrew Pinski  writes:
> > On Wed, Mar 12, 2025 at 12:00 PM Richard Sandiford
> >  wrote:
> >>
> >> Using a combination of rules, we were able to fold
> >>
> >>   ((X >> C1) & C2) * (1 << C1)  -->  X & (C2 << C1)
> >>
> >> if everything was done at the same precision, but we couldn't fold
> >> it if the AND was done at a different precision.  The optimisation is
> >> often (but not always) valid for that case too.
> >>
> >> This patch adds a dedicated rule for the case where different precisions
> >> are involved.
> >>
> >> An alternative would be to extend the individual folds that together
> >> handle the same-precision case so that those rules handle differing
> >> precisions.  But the risk is that that could replace narrow operations
> >> with wide operations, which would be especially harmful on targets
> >> like avr.  It's also not obviously free of cycles.
> >>
> >> I also wondered whether the converts should be non-optional.
> >>
> >> gcc/
> >> * match.pd: Fold ((X >> C1) & C2) * (1 << C1) to X & (C2 << C1).
> >>
> >> gcc/testsuite/
> >> * gcc.dg/fold-mul-and-lshift-1.c: New test.
> >> * gcc.dg/fold-mul-and-lshift-2.c: Likewise.
> >> ---
> >>  gcc/match.pd | 29 ++
> >>  gcc/testsuite/gcc.dg/fold-mul-and-lshift-1.c | 59 
> >>  gcc/testsuite/gcc.dg/fold-mul-and-lshift-2.c | 15 +
> >>  3 files changed, 103 insertions(+)
> >>  create mode 100644 gcc/testsuite/gcc.dg/fold-mul-and-lshift-1.c
> >>  create mode 100644 gcc/testsuite/gcc.dg/fold-mul-and-lshift-2.c
> >>
> >> diff --git a/gcc/match.pd b/gcc/match.pd
> >> index 5c679848bdf..3197d1cac75 100644
> >> --- a/gcc/match.pd
> >> +++ b/gcc/match.pd
> >> @@ -5231,6 +5231,35 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >>   (if (mask)
> >>(bit_op (shift (convert @0) @1) { mask; })))
> >>
> >> +/* Fold ((X >> C1) & C2) * (1 << C1) into X & (C2 << C1), including cases 
> >> where
> >> +   the & happens in a different type.  It is the conversion case that 
> >> isn't
> >> +   a composition of other folds.
> >> +
> >> +   Let the type of the * and >> be T1 and the type of the & be T2.
> >> +   The fold is valid if the conversion to T2 preserves all information;
> >> +   that is, if T2 is wider than T1 or drops no more than C1 bits from T1.
> >> +   In that case, the & might operate on bits that are dropped by the
> >> +   later conversion to T1 and the multiplication by (1 << C1), but those
> >> +   bits are also dropped by ANDing with C2 << C1 (converted to T1).
> >> +
> >> +   If the conversion to T2 is not information-preserving, we have to be
> >> +   careful about the later conversion to T1 acting as a sign extension.
> >> +   We need either T2 to be unsigned or the top (sign) bit of C2 to be 
> >> clear.
> >> +   That is equivalent to testing whether C2 is nonnegative.  */
> >> +(simplify
> >> + (mult
> >> +  (convert? (bit_and (convert? (rshift @0 INTEGER_CST@1)) INTEGER_CST@2))
> >> +  INTEGER_CST@3)
> >> + (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
> >> +  (with { auto prec = element_precision (type); }
> > Since we know this needs to be a scalar, Using TREE_PRECISION here is fine 
> > too.
>
> Yeah, agreed.  I'd wondered whether to use TREE_PRECISION instead,
> but then I'd also wondered about trying to make the fold work for ectors.
> Guess I ended up between two stools.
>
> >> +   (if (wi::ltu_p (wi::to_widest (@1), prec))
> >
> > I think using wi::to_wide is better than using wi::to_widest here.
>
> What's the reason for preferring wi::to_wide?  wi::to_widest should
> usually be more efficient for this kind of check, since the tree
> representation allows the underlying HWIs to be used directly.
> wi::to_wide instead requires masking off bits above the precision.
>
> E.g. on an --enable-checking=release compiler:
>
> bool
> foo (tree t, unsigned int n)
> {
>   return wi::ltu_p (wi::to_widest (t), n);
> }
>
> gives:
>
> 188c:   79400c02ldrhw2, [x0, #6]
> 1890:   7100045fcmp w2, #0x1
> 1894:   5460b.eq18a0  int)+0x14>  // b.none
> 1898:   5280mov w0, #0x0// #0
> 189c:   d65f03c0ret
> 18a0:   f9400800ldr x0, [x0, #16]
> 18a4:   eb21401fcmp x0, w1, uxtw
> 18a8:   1a9f27e0csetw0, cc  // cc = lo, ul, last
> 18ac:   d65f03c0ret
>
> whereas:
>
> bool
> foo (tree t, unsigned int n)
> {
>   return wi::ltu_p (wi::to_wide (t), n);
> }
>
> gives:
>
> 188c:   79400802ldrhw2, [x0, #4]
> 1890:   7100045fcmp w2, #0x1
> 1894:   5460b.eq18a0  int)+0x14>  // b.none
> 1898:   5280mov w0, #0x0// #0
> 189c:   d65f03c0ret
> 18a0:   a9408800  

[PATCH v2] cobol: capture source ranges for tokens, rather than just points (v2)

[David Malcolm]

Here's an updated version of this patch which adds a testcase to the
DejaGnu test suite, using *<< and *>> for a multiline comment (used to
express a fragment of the expected output on stderr).

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu, but
I *haven't* tested this patch with the NIST testsuite.

OK for trunk?

Blurb follows:

This patch changes the output on the simple test I tried from:

$ ./gcobol -B. hello.cob -S
hello.cob:2:8: error: syntax error, unexpected NAME, expecting FUNCTION or 
PROGRAM-ID
2 |porgram-id. hello.
  |^
cobol1: error: failed compiling hello.cob

to:

$ ./gcobol -B. hello.cob -S
hello.cob:2:8: error: syntax error, unexpected NAME, expecting FUNCTION or 
PROGRAM-ID
2 |porgram-id. hello.
  |^~~
cobol1: error: failed compiling hello.cob

gcc/cobol/ChangeLog:
* util.cc (gcc_location_set_impl): Capture the start and end of "loc"
as a range, rather than just the (last_line, first_column).

gcc/testsuite/ChangeLog:
* cobol.dg/typo-1.cob: New test.
---
 gcc/cobol/util.cc | 16 ++--
 gcc/testsuite/cobol.dg/typo-1.cob | 15 +++
 2 files changed, 29 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/cobol.dg/typo-1.cob

diff --git a/gcc/cobol/util.cc b/gcc/cobol/util.cc
index 6ade146b5dda..aba4a1003554 100644
--- a/gcc/cobol/util.cc
+++ b/gcc/cobol/util.cc
@@ -1857,11 +1857,23 @@ cobol_filename_restore() {
 
 static location_t token_location;
 
+/* Update global token_location with a location_t expressing a source
+   range with start and caret at the first line/column of LOC, and
+   finishing at the last line/column of LOC.  */
+
 template 
 static void
 gcc_location_set_impl( const LOC& loc ) {
-  token_location = linemap_line_start( line_table, loc.last_line, 80 );
-  token_location = linemap_position_for_column( line_table, loc.first_column);
+  const location_t start_line
+= linemap_line_start( line_table, loc.first_line, 80 );
+  const location_t token_start
+= linemap_position_for_column( line_table, loc.first_column);
+  const location_t finish_line
+= linemap_line_start( line_table, loc.last_line, 80 );
+  const location_t token_finish
+= linemap_position_for_column( line_table, loc.last_column);
+  token_location
+= make_location (token_start, token_start, token_finish);
   location_dump(__func__, __LINE__, "parser", loc);
 }
 
diff --git a/gcc/testsuite/cobol.dg/typo-1.cob 
b/gcc/testsuite/cobol.dg/typo-1.cob
new file mode 100644
index ..a806863db190
--- /dev/null
+++ b/gcc/testsuite/cobol.dg/typo-1.cob
@@ -0,0 +1,15 @@
+*> { dg-options "-fdiagnostics-show-caret" } 
+*> { dg-do compile }
+
+   identification division.
+   porgram-id. hello. *> { dg-error "8: syntax error, unexpected NAME, 
expecting FUNCTION or PROGRAM-ID" }
+   procedure division.
+   display "Hello World!".
+   stop run.
+
+*<<
+{ dg-begin-multiline-output "" }
+porgram-id. hello.
+^~~
+{ dg-end-multiline-output "" }
+*>>
-- 
2.26.3

Re: [PATCH][_Hashtable] Fix hash code cache usage

[Florian Weimer]

* François Dumont:

> +  // Get hash code for a node that comes from another _Hashtable.
> +  // Reuse a cached hash code if the hash function is stateless,
> +  // otherwise recalculate it using our own hash function.
> +  __hash_code
> +  _M_hash_code_ext(const __node_value_type& __from) const
> +  {
> + if constexpr (__and_<__hash_cached, is_empty<_Hash>>::value)
> +   return __from._M_hash_code;
> + else
> +   return this->_M_hash_code(_ExtractKey{}(__from._M_v()));
> +  }

Does C++ support stateful hash functions?  I don't think so, and I don't
see it documented as a GNU extension, either.

Thanks,
Florian

Re: [PATCH] libstdc++: Fix ref_view branch of views::as_const [PR119135]

[Patrick Palka]

On Wed, 12 Mar 2025, Patrick Palka wrote:

> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and
> perhaps 13?
> 
> N.B. the use of a constrained auto instead of a separate static_assert
> in the testcase is unfortunate but I opted for local consistency for
> now.
> 
> -- >8 --
> 
> Unlike for span and empty_view, the range_reference_t of
> ref_view doesn't correspond to X.  This patch fixes the ref_view
> branch of views::as_const to correctly query the underlying range
> type X.
> 
>   PR libstdc++/119135
> 
> libstdc++-v3/ChangeLog:
> 
>   * include/std/ranges: Include .
>   (views::__detail::__is_ref_view): Replace with ...
>   (views::__detail::__is_constable_ref_view): ... this.
>   (views::_AsConst::operator()): Correct the ref_view branch.
>   * testsuite/std/ranges/adaptors/as_const/1.cc (test03): Extend
>   test.
> ---
>  libstdc++-v3/include/std/ranges  | 12 ++--
>  .../testsuite/std/ranges/adaptors/as_const/1.cc  |  4 
>  2 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index c2a2d6f4e05..31d62454895 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -48,6 +48,7 @@
>  #include 
>  #include 
>  #if __cplusplus > 202002L
> +#include 
>  #include 
>  #endif
>  #include 
> @@ -9324,10 +9325,11 @@ namespace views::__adaptor
>  namespace __detail
>  {
>template
> - inline constexpr bool __is_ref_view = false;
> + inline constexpr bool __is_constable_ref_view = false;
>  
>template
> - inline constexpr bool __is_ref_view> = true;
> + inline constexpr bool __is_constable_ref_view>
> +   = constant_range;
>  
>template
>   concept __can_as_const_view = requires { 
> as_const_view(std::declval<_Range>()); };
> @@ -9349,10 +9351,8 @@ namespace views::__adaptor
> return views::empty;
>   else if constexpr (std::__detail::__is_span<_Tp>)
> return span _Tp::extent>(std::forward<_Range>(__r));
> - else if constexpr (__detail::__is_ref_view<_Tp>
> -&& constant_range)
> -   return ref_view(static_cast
> -   (std::forward<_Range>(__r).base()));
> + else if constexpr (__detail::__is_constable_ref_view<_Tp>)
> +   return ref_view(std::as_const(__r.base()));

Whoops, just noticed that I got rid of the perfect forwarding of __r
here for no good reason.  It shouldn't matter since its base() member
function is const, but consider the std::forward restored for
consistency.

>   else if constexpr (is_lvalue_reference_v<_Range>
>  && constant_range
>  && !view<_Tp>)
> 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 c36786a8c5f..3f1f8eb1772 100644
> --- a/libstdc++-v3/testsuite/std/ranges/adaptors/as_const/1.cc
> +++ b/libstdc++-v3/testsuite/std/ranges/adaptors/as_const/1.cc
> @@ -63,6 +63,10 @@ test03()
>std::vector v;
>std::same_as>>
>  auto r = views::as_const(v);
> +
> +  // PR libstdc++/119135
> +  std::same_as>>
> +auto r2 = views::as_const(views::all(v));
>  }
>  
>  int
> -- 
> 2.49.0.rc1.37.ge969bc8759
> 
> 

Re: [PATCH] LoongArch: Don't use C++17 feature [PR119238]

[Lulu Cheng]

在 2025/3/13 上午10:36, Andrew Pinski 写道:

On Wed, Mar 12, 2025 at 6:23 PM Lulu Cheng  wrote:


在 2025/3/12 下午9:14, Xi Ruoyao 写道:

Structured binding is a C++17 feature but the GCC code base is in C++14.

I couldn't find the description of the standards followed by GCC code in
the document yesterday.

Therefore, I assumed that this standard is the same as the default
standard set during GCC compilation.

Is this described in the documentation?

yes it is described right here:
https://gcc.gnu.org/install/prerequisites.html

```
ISO C++14 compiler

Necessary to bootstrap GCC. GCC 5.4 or newer has sufficient support
for used C++14 features.

Versions of GCC prior to 15 allow bootstrapping with an ISO C++11
compiler, versions prior to 10.5 allow bootstrapping with an ISO C++98
compiler, and versions prior to 4.8 allow bootstrapping with an ISO
C89 compiler.

If you need to build an intermediate version of GCC in order to
bootstrap current GCC, consider GCC 9.5: it can build the current Ada
and D compilers, and was also the version that declared C++17 support
stable.
```

Notice it says C++ 2014.

Thanks,
Andrew


Oh, I see it.

Thank you very much.


gcc/ChangeLog:

   PR target/119238
   * config/loongarch/simd.md (dot_prod):
   Stop using structured binding.
---

Ok for trunk?

Ok,thanks!



   gcc/config/loongarch/simd.md | 14 --
   1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/gcc/config/loongarch/simd.md b/gcc/config/loongarch/simd.md
index 8f7e912982e..dd17cd13fc5 100644
--- a/gcc/config/loongarch/simd.md
+++ b/gcc/config/loongarch/simd.md
@@ -809,18 +809,20 @@ (define_expand "dot_prod"
  (any_extend (const_int 0))]
 ""
   {
-  auto [op0, op1, op2, op3] = operands;
+  rtx *op = operands;

-  if (op3 == CONST0_RTX (mode))
+  if (op[3] == CONST0_RTX (mode))
   emit_insn (
-  gen__vmulwev__ (op0, op1, op2));
+  gen__vmulwev__ (op[0], op[1],
+   op[2]));
 else
   emit_insn (
-  gen__vmaddwev__ (op0, op3, op1,
-op2));
+  gen__vmaddwev__ (op[0], op[3],
+op[1], op[2]));

 emit_insn (
-gen__vmaddwod__ (op0, op0, op1, op2));
+gen__vmaddwod__ (op[0], op[0],
+  op[1], op[2]));
 DONE;
   })

[PATCH] libstdc++: Fix ref_view branch of views::as_const [PR119135]

[Patrick Palka]

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

N.B. the use of a constrained auto instead of a separate static_assert
in the testcase is unfortunate but I opted for local consistency for
now.

-- >8 --

Unlike for span and empty_view, the range_reference_t of
ref_view doesn't correspond to X.  This patch fixes the ref_view
branch of views::as_const to correctly query the underlying range
type X.

PR libstdc++/119135

libstdc++-v3/ChangeLog:

* include/std/ranges: Include .
(views::__detail::__is_ref_view): Replace with ...
(views::__detail::__is_constable_ref_view): ... this.
(views::_AsConst::operator()): Correct the ref_view branch.
* testsuite/std/ranges/adaptors/as_const/1.cc (test03): Extend
test.
---
 libstdc++-v3/include/std/ranges  | 12 ++--
 .../testsuite/std/ranges/adaptors/as_const/1.cc  |  4 
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index c2a2d6f4e05..31d62454895 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -48,6 +48,7 @@
 #include 
 #include 
 #if __cplusplus > 202002L
+#include 
 #include 
 #endif
 #include 
@@ -9324,10 +9325,11 @@ namespace views::__adaptor
 namespace __detail
 {
   template
-   inline constexpr bool __is_ref_view = false;
+   inline constexpr bool __is_constable_ref_view = false;
 
   template
-   inline constexpr bool __is_ref_view> = true;
+   inline constexpr bool __is_constable_ref_view>
+ = constant_range;
 
   template
concept __can_as_const_view = requires { 
as_const_view(std::declval<_Range>()); };
@@ -9349,10 +9351,8 @@ namespace views::__adaptor
  return views::empty;
else if constexpr (std::__detail::__is_span<_Tp>)
  return span(std::forward<_Range>(__r));
-   else if constexpr (__detail::__is_ref_view<_Tp>
-  && constant_range)
- return ref_view(static_cast
- (std::forward<_Range>(__r).base()));
+   else if constexpr (__detail::__is_constable_ref_view<_Tp>)
+ return ref_view(std::as_const(__r.base()));
else if constexpr (is_lvalue_reference_v<_Range>
   && constant_range
   && !view<_Tp>)
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 c36786a8c5f..3f1f8eb1772 100644
--- a/libstdc++-v3/testsuite/std/ranges/adaptors/as_const/1.cc
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/as_const/1.cc
@@ -63,6 +63,10 @@ test03()
   std::vector v;
   std::same_as>>
 auto r = views::as_const(v);
+
+  // PR libstdc++/119135
+  std::same_as>>
+auto r2 = views::as_const(views::all(v));
 }
 
 int
-- 
2.49.0.rc1.37.ge969bc8759

Re: [PATCH] libstdc++: Fix ref_view branch of views::as_const [PR119135]

[Patrick Palka]

On Wed, 12 Mar 2025, Patrick Palka wrote:

> On Wed, 12 Mar 2025, Patrick Palka wrote:
> 
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and
> > perhaps 13?
> > 
> > N.B. the use of a constrained auto instead of a separate static_assert
> > in the testcase is unfortunate but I opted for local consistency for
> > now.
> > 
> > -- >8 --
> > 
> > Unlike for span and empty_view, the range_reference_t of
> > ref_view doesn't correspond to X.  This patch fixes the ref_view
> > branch of views::as_const to correctly query the underlying range
> > type X.
> > 
> > PR libstdc++/119135
> > 
> > libstdc++-v3/ChangeLog:
> > 
> > * include/std/ranges: Include .
> > (views::__detail::__is_ref_view): Replace with ...
> > (views::__detail::__is_constable_ref_view): ... this.
> > (views::_AsConst::operator()): Correct the ref_view branch.
> > * testsuite/std/ranges/adaptors/as_const/1.cc (test03): Extend
> > test.
> > ---
> >  libstdc++-v3/include/std/ranges  | 12 ++--
> >  .../testsuite/std/ranges/adaptors/as_const/1.cc  |  4 
> >  2 files changed, 10 insertions(+), 6 deletions(-)
> > 
> > diff --git a/libstdc++-v3/include/std/ranges 
> > b/libstdc++-v3/include/std/ranges
> > index c2a2d6f4e05..31d62454895 100644
> > --- a/libstdc++-v3/include/std/ranges
> > +++ b/libstdc++-v3/include/std/ranges
> > @@ -48,6 +48,7 @@
> >  #include 
> >  #include 
> >  #if __cplusplus > 202002L
> > +#include 
> >  #include 
> >  #endif
> >  #include 
> > @@ -9324,10 +9325,11 @@ namespace views::__adaptor
> >  namespace __detail
> >  {
> >template
> > -   inline constexpr bool __is_ref_view = false;
> > +   inline constexpr bool __is_constable_ref_view = false;
> >  
> >template
> > -   inline constexpr bool __is_ref_view> = true;
> > +   inline constexpr bool __is_constable_ref_view>
> > + = constant_range;
> >  
> >template
> > concept __can_as_const_view = requires { 
> > as_const_view(std::declval<_Range>()); };
> > @@ -9349,10 +9351,8 @@ namespace views::__adaptor
> >   return views::empty;
> > else if constexpr (std::__detail::__is_span<_Tp>)
> >   return span > _Tp::extent>(std::forward<_Range>(__r));
> > -   else if constexpr (__detail::__is_ref_view<_Tp>
> > -  && constant_range)
> > - return ref_view(static_cast
> > - (std::forward<_Range>(__r).base()));
> > +   else if constexpr (__detail::__is_constable_ref_view<_Tp>)
> > + return ref_view(std::as_const(__r.base()));
> 
> Whoops, just noticed that I got rid of the perfect forwarding of __r
> here for no good reason.  It shouldn't matter since its base() member
> function is const, but consider the std::forward restored for
> consistency.

Like so:

-- >8 --

Subject: [PATCH v2] libstdc++: Fix ref_view branch of views::as_const [PR119135]

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

N.B. the use of a constrained auto instead of a separate static_assert
in the testcase is unfortunate but I opted for local consistency for
now.

-- >8 --

Unlike for span and empty_view, the range_reference_t of
ref_view doesn't correspond to X.  This patch fixes the ref_view
branch of views::as_const to correctly query its underlying range
type X.

PR libstdc++/119135

libstdc++-v3/ChangeLog:

* include/std/ranges: Include .
(views::__detail::__is_ref_view): Replace with ...
(views::__detail::__is_constable_ref_view): ... this.
(views::_AsConst::operator()): Correct the ref_view branch.
* testsuite/std/ranges/adaptors/as_const/1.cc (test03): Extend
test.
---
 libstdc++-v3/include/std/ranges  | 12 ++--
 .../testsuite/std/ranges/adaptors/as_const/1.cc  |  4 
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index c2a2d6f4e05..ef277b81bd3 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -48,6 +48,7 @@
 #include 
 #include 
 #if __cplusplus > 202002L
+#include 
 #include 
 #endif
 #include 
@@ -9324,10 +9325,11 @@ namespace views::__adaptor
 namespace __detail
 {
   template
-   inline constexpr bool __is_ref_view = false;
+   inline constexpr bool __is_constable_ref_view = false;
 
   template
-   inline constexpr bool __is_ref_view> = true;
+   inline constexpr bool __is_constable_ref_view>
+ = constant_range;
 
   template
concept __can_as_const_view = requires { 
as_const_view(std::declval<_Range>()); };
@@ -9349,10 +9351,8 @@ namespace views::__adaptor
  return views::empty;
else if constexpr (std::__detail::__is_span<_Tp>)
  return span(std::forward<_Range>(__r));
-   else if constexpr (__detail::__is_ref_view<_Tp>
-  && constant_range)
- return ref_view(static_cast
-