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

[Rainer Orth]

Hi Jakub,

> On Wed, Apr 09, 2025 at 02:22:16PM +0200, Rainer Orth wrote:
>> > Here is what I'm testing as an incremental fix, so far OK on x86_64-darwin
>> > and powerpcle64 (GLIBC 2.34) .. others in progress.  Does it help the
>> > Solaris cases?
>> 
>> I'll give it a try.  Here's what I have (I believe it's more readable in
>> some cases), but as I said something's not right yet (probably something
>> very stupid).
>
> Yes, most importantly
>
>>  #if !defined (HAVE_STRFROMF128)
>> -# if !USE_QUADMATH
>> +static int
>> +strfromf128 (char *s, size_t n, const char *f, long double v)
>
> this long double should have been GCOB_FP128.

ugh, I knew it would be something dumb ;-)

> Anyway, I think there should be consistency in what we use, so like
> libgcobol-fp.h specifies, IEEE quad long double should have highest
> priority, then _Float128 with *f128 APIs, then libquadmath.
> And when we decide to use say long double, we shouldn't mix that with
> strfromf128/strtof128.

Makes perfect sense.

> So, here is an updated patch based on your patch, so far briefly
> tested on x86_64 with recent glibc (i.e. with the *f128 APIs).

I've successfully bootstrapped that now on both Solaris/amd64 and
Solaris/sparcv9, with --enable-languages=cobol --enable-libgcobol and a
bunch of patches (to be posted shortly) that enable cobol and libgcobol
compilation on Solaris.

Test results are not stellar so far, though:

* amd64-pc-solaris2.11, which uses the libquadmath path:

=== cobol Summary for unix ===

# of expected passes2925
# of unexpected failures108
# of expected failures  6
# of unresolved testcases   72

  According to Iain, Darwin/x86_64 is similar, though.

* sparcv9-sun-solaris2.11, which used the 128-bit long double path:

=== cobol Summary for unix ===

# of expected passes2516
# of unexpected failures440
# of expected failures  6
# of unresolved testcases   126

  I do have a WIP patch to support __float128 on SPARC (which I'd use
  with Iain's initial patch), but that's no longer exercised now that
  128-bit long double takes precedence.

I haven't even started looking into the failures since my initial goal
was to get both cobol and libgcobol to compile on Solaris at all.  I
suppose SPARC being the first big-endian and strict-alignment target
accounts for a considerable part of the failures.

Thanks a lot for following through with this.

Rainer

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

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

[Iain Sandoe]

> On 11 Apr 2025, at 08:34, Rainer Orth  wrote:
> 
> Hi Jakub,
> 
>> On Wed, Apr 09, 2025 at 02:22:16PM +0200, Rainer Orth wrote:
 Here is what I'm testing as an incremental fix, so far OK on x86_64-darwin
 and powerpcle64 (GLIBC 2.34) .. others in progress.  Does it help the
 Solaris cases?
>>> 
>>> I'll give it a try.  Here's what I have (I believe it's more readable in
>>> some cases), but as I said something's not right yet (probably something
>>> very stupid).
>> 
>> Yes, most importantly
>> 
>>> #if !defined (HAVE_STRFROMF128)
>>> -# if !USE_QUADMATH
>>> +static int
>>> +strfromf128 (char *s, size_t n, const char *f, long double v)
>> 
>> this long double should have been GCOB_FP128.
> 
> ugh, I knew it would be something dumb ;-)
> 
>> Anyway, I think there should be consistency in what we use, so like
>> libgcobol-fp.h specifies, IEEE quad long double should have highest
>> priority, then _Float128 with *f128 APIs, then libquadmath.
>> And when we decide to use say long double, we shouldn't mix that with
>> strfromf128/strtof128.
> 
> Makes perfect sense.
> 
>> So, here is an updated patch based on your patch, so far briefly
>> tested on x86_64 with recent glibc (i.e. with the *f128 APIs).
> 
> I've successfully bootstrapped that now on both Solaris/amd64 and
> Solaris/sparcv9, with --enable-languages=cobol --enable-libgcobol and a
> bunch of patches (to be posted shortly) that enable cobol and libgcobol
> compilation on Solaris.
> 
> Test results are not stellar so far, though:
> 
> * amd64-pc-solaris2.11, which uses the libquadmath path:
> 
>   === cobol Summary for unix ===
> 
> # of expected passes  2925
> # of unexpected failures  108
> # of expected failures6
> # of unresolved testcases 72
> 
>  According to Iain, Darwin/x86_64 is similar, though.

On x86_64 Darwin 102 fails almost exactly 50/50 PR119377 / PR119524
On aarch64 Darwin 108 fails, I did not yet analyse the additional failing case 
on aarch64.
Iain

> 
> * sparcv9-sun-solaris2.11, which used the 128-bit long double path:
> 
>   === cobol Summary for unix ===
> 
> # of expected passes  2516
> # of unexpected failures  440
> # of expected failures6
> # of unresolved testcases 126
> 
>  I do have a WIP patch to support __float128 on SPARC (which I'd use
>  with Iain's initial patch), but that's no longer exercised now that
>  128-bit long double takes precedence.
> 
> I haven't even started looking into the failures since my initial goal
> was to get both cobol and libgcobol to compile on Solaris at all.  I
> suppose SPARC being the first big-endian and strict-alignment target
> accounts for a considerable part of the failures.
> 
> Thanks a lot for following through with this.
> 
>   Rainer
> 
> -- 
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] libstdc++: Use constexpr-if for std::basic_string::_S_copy_chars

[Tomasz Kaminski]

On Thu, Apr 10, 2025 at 6:29 PM Jonathan Wakely  wrote:

> For C++11 and later we can remvoe four overloads of _S_copy_chars and
> use constexpr-if in the generic _S_copy_chars. This simplifies overload
> resolution for _S_copy_chars, and also means that we optimize for other
> iterators such as std::vector::iterator.
>
> We still need all the _S_copy_chars overloads to be part of the explicit
> instantiation definition, so make them depend on the macro that is
> defined by src/c++11/string-inst.cc for that purpose.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/basic_string.h (_S_copy_chars): Replace overloads
> with constexpr-if and extend optimization to all contiguous
> iterators.
> * src/c++11/string-inst.cc: Extend comment.
> ---
>
> Tested x86_64-linux.
>
LGTM with one clarification question.

>
>  libstdc++-v3/include/bits/basic_string.h | 31 ++--
>  libstdc++-v3/src/c++11/string-inst.cc|  3 ++-
>  2 files changed, 25 insertions(+), 9 deletions(-)
>
> diff --git a/libstdc++-v3/include/bits/basic_string.h
> b/libstdc++-v3/include/bits/basic_string.h
> index 886e7e6b19e..067c7915c76 100644
> --- a/libstdc++-v3/include/bits/basic_string.h
> +++ b/libstdc++-v3/include/bits/basic_string.h
> @@ -468,6 +468,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>   traits_type::assign(__d, __n, __c);
>}
>
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wc++17-extensions"
>// _S_copy_chars is a separate template to permit specialization
>// to optimize for the common case of pointers as iterators.
>template
> @@ -475,31 +477,44 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>  static void
>  _S_copy_chars(_CharT* __p, _Iterator __k1, _Iterator __k2)
>  {
> +#if __cplusplus >= 201103L
> + using _IterBase = decltype(std::__niter_base(__k1));
> + if constexpr (__or_,
> + is_same<_IterBase, const _CharT*>>::value)
> +   _S_copy(__p, std::__niter_base(__k1), __k2 - __k1);
> +#if __cpp_lib_concepts
> + else if constexpr (contiguous_iterator<_Iterator>
> +  && is_same_v,
> _CharT>)
> +   {
> + const auto __d = __k2 - __k1;
> + (void) (__k1 + __d); // See P3349R1
> + _S_copy(__p, std::to_address(__k1),
> static_cast(__d));
> +   }
> +#endif
> + else
> +#endif
>   for (; __k1 != __k2; ++__k1, (void)++__p)
> traits_type::assign(*__p, *__k1); // These types are off.
> }
> +#pragma GCC diagnostic pop
>
> -  _GLIBCXX20_CONSTEXPR
> +#if __cplusplus < 201103L || defined
> _GLIBCXX_DEFINING_STRING_INSTANTIATIONS
>static void
> -  _S_copy_chars(_CharT* __p, iterator __k1, iterator __k2)
> _GLIBCXX_NOEXCEPT
>
The  `_GLIBCXX_DEFINING_STRING_INSTANTIATIONS` seem to be used for
c++11/string-inst.cc, in
which case the noexcept was meaningful. The macro is not used in
c++17/string-inst.cc file, so noexcept
would be part of the function signature, so I do not think we change
emitted symbols. Is this the reason
why did you remove it?

> +  _S_copy_chars(_CharT* __p, iterator __k1, iterator __k2)
>{ _S_copy_chars(__p, __k1.base(), __k2.base()); }
>
> -  _GLIBCXX20_CONSTEXPR
>static void
>_S_copy_chars(_CharT* __p, const_iterator __k1, const_iterator __k2)
> -  _GLIBCXX_NOEXCEPT
>{ _S_copy_chars(__p, __k1.base(), __k2.base()); }
>
> -  _GLIBCXX20_CONSTEXPR
>static void
> -  _S_copy_chars(_CharT* __p, _CharT* __k1, _CharT* __k2)
> _GLIBCXX_NOEXCEPT
> +  _S_copy_chars(_CharT* __p, _CharT* __k1, _CharT* __k2)
>{ _S_copy(__p, __k1, __k2 - __k1); }
>
> -  _GLIBCXX20_CONSTEXPR
>static void
>_S_copy_chars(_CharT* __p, const _CharT* __k1, const _CharT* __k2)
> -  _GLIBCXX_NOEXCEPT
>{ _S_copy(__p, __k1, __k2 - __k1); }
> +#endif
>
>_GLIBCXX20_CONSTEXPR
>static int
> diff --git a/libstdc++-v3/src/c++11/string-inst.cc
> b/libstdc++-v3/src/c++11/string-inst.cc
> index c4864794d40..34df909b31a 100644
> --- a/libstdc++-v3/src/c++11/string-inst.cc
> +++ b/libstdc++-v3/src/c++11/string-inst.cc
> @@ -40,7 +40,8 @@
>  // replaced by constrained function templates, so that we instantiate the
>  // pre-C++17 definitions.
>  // This also causes the instantiation of the non-standard C++0x-era
> -// insert(iterator, initializer_list) overload, see PR libstdc++/83328
> +// insert(iterator, initializer_list) overload, see PR libstdc++/83328,
> +// and overloads of _S_copy_chars for string iterators and pointers.
>  #define _GLIBCXX_DEFINING_STRING_INSTANTIATIONS 1
>
>  #include 
> --
> 2.49.0
>
>

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

[Jakub Jelinek]

On Fri, Apr 11, 2025 at 09:34:32AM +0200, Rainer Orth wrote:
> * amd64-pc-solaris2.11, which uses the libquadmath path:
> 
>   === cobol Summary for unix ===
> 
> # of expected passes  2925
> # of unexpected failures  108
> # of expected failures6
> # of unresolved testcases 72
> 
>   According to Iain, Darwin/x86_64 is similar, though.

Note, while on my WS with glibc 2.35 on x86_64-linux make check-cobol
is clean, in our Fedora 42/43 distro build I'm getting
FAIL: cobol.dg/group1/check_88.cob   -O0  output pattern test
FAIL: cobol.dg/group1/check_88.cob   -O1  output pattern test
FAIL: cobol.dg/group1/check_88.cob   -O2  output pattern test
FAIL: cobol.dg/group1/check_88.cob   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  output pattern test
FAIL: cobol.dg/group1/check_88.cob   -O3 -g  output pattern test
FAIL: cobol.dg/group1/check_88.cob   -Os  output pattern test
FAIL: INSPECT_CONVERTING_TO_figurative_constants.out output file test
FAIL: INSPECT_CONVERTING_TO_figurative_constants.out output file test
FAIL: INSPECT_CONVERTING_TO_figurative_constants.out output file test
FAIL: INSPECT_CONVERTING_TO_figurative_constants.out output file test
FAIL: INSPECT_CONVERTING_TO_figurative_constants.out output file test
FAIL: INSPECT_CONVERTING_TO_figurative_constants.out output file test
(dunno if that is because of newer glibc or what).
Both are likely because of the U+0080 and above characters,
in cobol.log from my WS I see
->

Re: [PATCH v2] libstdc++: Implement C++26 features (P2546R5)

[Jonathan Wakely]

On Fri, 11 Apr 2025 at 08:00, Tomasz Kaminski  wrote:
>
>
>
> On Thu, Apr 10, 2025 at 6:53 PM Jonathan Wakely  wrote:
>>
>> It would be good to provide a macOS definition of is_debugger_present as
>> per https://developer.apple.com/library/archive/qa/qa1361/_index.html
>> but that isn't included in this change.
>>
>> libstdc++-v3/ChangeLog:
>>
>> * config.h.in: Regenerate.
>> * configure: Regenerate.
>> * configure.ac: Check for facilities needed by .
>> * include/Makefile.am: Add new header.
>> * include/Makefile.in: Regenerate.
>> * include/bits/version.def (debugging): Add.
>> * include/bits/version.h: Regenerate.
>> * src/c++26/Makefile.am: Add new file.
>> * src/c++26/Makefile.in: Regenerate.
>> * include/std/debugging: New file.
>> * src/c++26/debugging.cc: New file.
>> * testsuite/19_diagnostics/debugging/breakpoint.cc: New test.
>> * testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc:
>> New test.
>> * testsuite/19_diagnostics/debugging/is_debugger_present.cc: New
>> test.
>> ---
>>
>> I sent v1 of this patch in June last year:
>> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653293.html
>> My comments about testing with GDB still apply.
>>
>> Compared to v1, this adds a void __gnu_cxx::attach_debugger(bool)
>> function that could be called by debuggers to announce that they are
>> attaching and detaching. It also adds a systemtap probe point to
>> std::breakpoint().
>>
>> Tested x86_64-linux.
>>
>> N.B. this only adds new symbols to the libstdc++exp.a archive, not to
>> libstdc++.so so it's not a risky change at this stage.
>>
>>  libstdc++-v3/config.h.in  |   9 +
>>  libstdc++-v3/configure|  22 +++
>>  libstdc++-v3/configure.ac |   9 +
>>  libstdc++-v3/include/Makefile.am  |   1 +
>>  libstdc++-v3/include/Makefile.in  |   1 +
>>  libstdc++-v3/include/bits/version.def |   8 +
>>  libstdc++-v3/include/bits/version.h   |  10 ++
>>  libstdc++-v3/include/std/debugging|  77 
>>  libstdc++-v3/src/c++26/Makefile.am|   4 +-
>>  libstdc++-v3/src/c++26/Makefile.in|   7 +-
>>  libstdc++-v3/src/c++26/debugging.cc   | 165 ++
>>  .../19_diagnostics/debugging/breakpoint.cc|  13 ++
>>  .../debugging/breakpoint_if_debugging.cc  |  13 ++
>>  .../debugging/is_debugger_present.cc  |  14 ++
>>  14 files changed, 350 insertions(+), 3 deletions(-)
>>  create mode 100644 libstdc++-v3/include/std/debugging
>>  create mode 100644 libstdc++-v3/src/c++26/debugging.cc
>>  create mode 100644 
>> libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint.cc
>>  create mode 100644 
>> libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc
>>  create mode 100644 
>> libstdc++-v3/testsuite/19_diagnostics/debugging/is_debugger_present.cc
>>
>> diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
>> index 77bbaf1beaa..3f1331ff36f 100644
>> --- a/libstdc++-v3/config.h.in
>> +++ b/libstdc++-v3/config.h.in
>> @@ -70,6 +70,9 @@
>>  /* Define to 1 if you have the `cosl' function. */
>>  #undef HAVE_COSL
>>
>> +/* Define to 1 if you have the  header file. */
>> +#undef HAVE_DEBUGAPI_H
>> +
>>  /* Define to 1 if you have the declaration of `strnlen', and to 0 if you
>> don't. */
>>  #undef HAVE_DECL_STRNLEN
>> @@ -439,6 +442,9 @@
>>  /* Define to 1 if you have the  header file. */
>>  #undef HAVE_SYS_PARAM_H
>>
>> +/* Define to 1 if you have the  header file. */
>> +#undef HAVE_SYS_PTRACE_H
>> +
>>  /* Define to 1 if you have the  header file. */
>>  #undef HAVE_SYS_RESOURCE_H
>>
>> @@ -850,6 +856,9 @@
>>  /* Define if nl_langinfo_l should be used for std::text_encoding. */
>>  #undef _GLIBCXX_USE_NL_LANGINFO_L
>>
>> +/* Define if /proc/self/status should be used for . */
>> +#undef _GLIBCXX_USE_PROC_SELF_STATUS
>> +
>>  /* Define if pthreads_num_processors_np is available in . */
>>  #undef _GLIBCXX_USE_PTHREADS_NUM_PROCESSORS_NP
>>
>> diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
>> index 819a1d82876..8143df91c38 100755
>> --- a/libstdc++-v3/configure
>> +++ b/libstdc++-v3/configure
>> @@ -54700,6 +54700,28 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
>>
>>
>>
>> +# For std::is_debugger_present
>> +case "$target_os" in
>> +  linux*)
>> +
>> +$as_echo "#define _GLIBCXX_USE_PROC_SELF_STATUS 1" >>confdefs.h
>> +
>> +;;
>> +esac
>> +for ac_header in sys/ptrace.h debugapi.h
>> +do :
>> +  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
>> +ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" 
>> "$ac_includes_default"
>> +if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
>> +  cat >>confdefs.h <<_ACEOF
>> +#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
>> +_ACEOF
>> +
>> +fi
>> +
>> +done
>> +
>> +
>>  # Define documentation rule

[PATCH] libstdc++: Implement C++26 features (P2546R5)

[Jonathan Wakely]

On Friday, 11 April 2025, Jonathan Wakely  wrote:
> On Fri, 11 Apr 2025 at 08:00, Tomasz Kaminski  wrote:
>>
>>
>>
>> On Thu, Apr 10, 2025 at 6:53 PM Jonathan Wakely 
wrote:
>>>
>>> It would be good to provide a macOS definition of is_debugger_present as
>>> per https://developer.apple.com/library/archive/qa/qa1361/_index.html
>>> but that isn't included in this change.
>>>
>>> libstdc++-v3/ChangeLog:
>>>
>>> * config.h.in: Regenerate.
>>> * configure: Regenerate.
>>> * configure.ac: Check for facilities needed by .
>>> * include/Makefile.am: Add new header.
>>> * include/Makefile.in: Regenerate.
>>> * include/bits/version.def (debugging): Add.
>>> * include/bits/version.h: Regenerate.
>>> * src/c++26/Makefile.am: Add new file.
>>> * src/c++26/Makefile.in: Regenerate.
>>> * include/std/debugging: New file.
>>> * src/c++26/debugging.cc: New file.
>>> * testsuite/19_diagnostics/debugging/breakpoint.cc: New test.
>>> * testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc:
>>> New test.
>>> * testsuite/19_diagnostics/debugging/is_debugger_present.cc: New
>>> test.
>>> ---
>>>
>>> I sent v1 of this patch in June last year:
>>> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653293.html
>>> My comments about testing with GDB still apply.
>>>
>>> Compared to v1, this adds a void __gnu_cxx::attach_debugger(bool)
>>> function that could be called by debuggers to announce that they are
>>> attaching and detaching. It also adds a systemtap probe point to
>>> std::breakpoint().
>>>
>>> Tested x86_64-linux.
>>>
>>> N.B. this only adds new symbols to the libstdc++exp.a archive, not to
>>> libstdc++.so so it's not a risky change at this stage.
>>>
>>>  libstdc++-v3/config.h.in  |   9 +
>>>  libstdc++-v3/configure|  22 +++
>>>  libstdc++-v3/configure.ac |   9 +
>>>  libstdc++-v3/include/Makefile.am  |   1 +
>>>  libstdc++-v3/include/Makefile.in  |   1 +
>>>  libstdc++-v3/include/bits/version.def |   8 +
>>>  libstdc++-v3/include/bits/version.h   |  10 ++
>>>  libstdc++-v3/include/std/debugging|  77 
>>>  libstdc++-v3/src/c++26/Makefile.am|   4 +-
>>>  libstdc++-v3/src/c++26/Makefile.in|   7 +-
>>>  libstdc++-v3/src/c++26/debugging.cc   | 165 ++
>>>  .../19_diagnostics/debugging/breakpoint.cc|  13 ++
>>>  .../debugging/breakpoint_if_debugging.cc  |  13 ++
>>>  .../debugging/is_debugger_present.cc  |  14 ++
>>>  14 files changed, 350 insertions(+), 3 deletions(-)
>>>  create mode 100644 libstdc++-v3/include/std/debugging
>>>  create mode 100644 libstdc++-v3/src/c++26/debugging.cc
>>>  create mode 100644
libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint.cc
>>>  create mode 100644
libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc
>>>  create mode 100644
libstdc++-v3/testsuite/19_diagnostics/debugging/is_debugger_present.cc
>>>
>>> diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
>>> index 77bbaf1beaa..3f1331ff36f 100644
>>> --- a/libstdc++-v3/config.h.in
>>> +++ b/libstdc++-v3/config.h.in
>>> @@ -70,6 +70,9 @@
>>>  /* Define to 1 if you have the `cosl' function. */
>>>  #undef HAVE_COSL
>>>
>>> +/* Define to 1 if you have the  header file. */
>>> +#undef HAVE_DEBUGAPI_H
>>> +
>>>  /* Define to 1 if you have the declaration of `strnlen', and to 0 if
you
>>> don't. */
>>>  #undef HAVE_DECL_STRNLEN
>>> @@ -439,6 +442,9 @@
>>>  /* Define to 1 if you have the  header file. */
>>>  #undef HAVE_SYS_PARAM_H
>>>
>>> +/* Define to 1 if you have the  header file. */
>>> +#undef HAVE_SYS_PTRACE_H
>>> +
>>>  /* Define to 1 if you have the  header file. */
>>>  #undef HAVE_SYS_RESOURCE_H
>>>
>>> @@ -850,6 +856,9 @@
>>>  /* Define if nl_langinfo_l should be used for std::text_encoding. */
>>>  #undef _GLIBCXX_USE_NL_LANGINFO_L
>>>
>>> +/* Define if /proc/self/status should be used for . */
>>> +#undef _GLIBCXX_USE_PROC_SELF_STATUS
>>> +
>>>  /* Define if pthreads_num_processors_np is available in . */
>>>  #undef _GLIBCXX_USE_PTHREADS_NUM_PROCESSORS_NP
>>>
>>> diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
>>> index 819a1d82876..8143df91c38 100755
>>> --- a/libstdc++-v3/configure
>>> +++ b/libstdc++-v3/configure
>>> @@ -54700,6 +54700,28 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
>>>
>>>
>>>
>>> +# For std::is_debugger_present
>>> +case "$target_os" in
>>> +  linux*)
>>> +
>>> +$as_echo "#define _GLIBCXX_USE_PROC_SELF_STATUS 1" >>confdefs.h
>>> +
>>> +;;
>>> +esac
>>> +for ac_header in sys/ptrace.h debugapi.h
>>> +do :
>>> +  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
>>> +ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header"
"$ac_includes_default"
>>> +if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
>>> +  cat 

RE: [EXTERNAL]Re: [PATCH] RISCV :Added MIPS P8700 Subtarget.

[Umesh Kalappa]

Thank you @Kito Cheng for early suggestions ,we will break down the patch like 
suggested and address the below comments .

~U

-Original Message-
From: Kito Cheng  
Sent: 11 April 2025 12:37
To: Umesh Kalappa 
Cc: gcc-patches@gcc.gnu.org; kito.ch...@sifive.com; Jesse Huang 
; pal...@dabbelt.com; and...@sifive.com; j...@sifive.com
Subject: [EXTERNAL]Re: [PATCH] RISCV :Added MIPS P8700 Subtarget.

[You don't often get email from kito.ch...@gmail.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Could you break this patch into two pieces:
1) Add new extensions.
2) Add new core (for -mcpu), pipeline model and cost model


> diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 
> 1326c67563a..d2642390b2a 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,24 @@
> +2025-04-09  Umesh Kalappa  
> +
> +P8700 is a high-performance processor from MIPS by extending RISCV
> +with the MIPS custom instructions.
> +The following changes enable P8700 processor for RISCV and
> +added MIPS specific insns.

GCC does not require editing the changelog directly, put that on the git commit 
log instead, and then there is a script that will update that automatically.

> index b34409adf39..c8467016c87 100644
> --- a/gcc/common/config/riscv/riscv-common.cc
> +++ b/gcc/common/config/riscv/riscv-common.cc
> @@ -442,6 +442,11 @@ static const struct riscv_ext_version 
> riscv_ext_version_table[] =
>{"xsfvqmaccdod",ISA_SPEC_CLASS_NONE, 1, 0},
>{"xsfvfnrclipxfqf", ISA_SPEC_CLASS_NONE, 1, 0},
>
> +  {"xmipscbop", ISA_SPEC_CLASS_NONE, 1, 0},  {"xmipscmov", 
> + ISA_SPEC_CLASS_NONE, 1, 0},  {"xmipsexectl", ISA_SPEC_CLASS_NONE, 1, 
> + 0},  {"xmipslsp", ISA_SPEC_CLASS_NONE, 1, 0},

one extension one line

> diff --git a/gcc/config/riscv/mips-insn.md 
> b/gcc/config/riscv/mips-insn.md new file mode 100644 index 
> 000..0c92a9d9e94
> --- /dev/null
> +++ b/gcc/config/riscv/mips-insn.md
> @@ -0,0 +1,37 @@
> +;; Machine description for MIPS custom instructioins.

s/instructioins/instructions/

> +;; Copyright (C) 2021-2025 Free Software Foundation, Inc.

2025 rather than 2021-2025

> +
> +;; This file is part of GCC.
> +
> +;; GCC is free software; you can redistribute it and/or modify ;; it 
> +under the terms of the GNU General Public License as published by ;; 
> +the Free Software Foundation; either version 3, or (at your option) 
> +;; any later version.
> +
> +;; GCC is distributed in the hope that it will be useful, ;; but 
> +WITHOUT ANY WARRANTY; without even the implied warranty of ;; 
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the ;; GNU 
> +General Public License for more details.
> +
> +;; You should have received a copy of the GNU General Public License 
> +;; along with GCC; see the file COPYING3.  If not see ;; 
> +.
> +
> +(define_insn "*movcc_bitmanip"

^^ the pattern name starting with * does not really matter to GCC itself, but 
it is useful when debugging, so maybe rename that to 
"*movcc_xmipscomv"?

> diff --git a/gcc/config/riscv/mips-p8700.md 
> b/gcc/config/riscv/mips-p8700.md new file mode 100644 index 
> 000..7cf50381cab
> --- /dev/null
> +++ b/gcc/config/riscv/mips-p8700.md
> @@ -0,0 +1,139 @@
> +;; DFA-based pipeline description for MIPS P8700.
> +;;
> +;; Copyright (C) 2018-2025 Free Software Foundation, Inc.

2025 rather than 2021-2025

> diff --git a/gcc/config/riscv/riscv-cores.def 
> b/gcc/config/riscv/riscv-cores.def
> index 2918496bcd0..73df04148fa 100644
> --- a/gcc/config/riscv/riscv-cores.def
> +++ b/gcc/config/riscv/riscv-cores.def
> @@ -44,6 +44,7 @@ RISCV_TUNE("thead-c906", generic, 
> thead_c906_tune_info)  RISCV_TUNE("xiangshan-nanhu", xiangshan, 
> xiangshan_nanhu_tune_info)  RISCV_TUNE("generic-ooo", generic_ooo, 
> generic_ooo_tune_info)  RISCV_TUNE("size", generic, 
> optimize_size_tune_info)
> +RISCV_TUNE("mips-p8700", mips_p8700, mips_p8700_tune_info)
>
>  #undef RISCV_TUNE
>
> diff --git a/gcc/config/riscv/riscv-opts.h 
> b/gcc/config/riscv/riscv-opts.h index 26fe228e0f8..3ae284b0d95 100644
> --- a/gcc/config/riscv/riscv-opts.h
> +++ b/gcc/config/riscv/riscv-opts.h
> @@ -58,7 +58,8 @@ enum riscv_microarchitecture_type {
>sifive_p400,
>sifive_p600,
>xiangshan,
> -  generic_ooo
> +  generic_ooo,
> +  mips_p8700,
>  };
>  extern enum riscv_microarchitecture_type riscv_microarchitecture;
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc 
> index 38f3ae7cd84..a8325ece2e9 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -642,6 +642,72 @@ static const struct riscv_tune_param 
> optimize_size_tune_info = {
>NULL,/* loop_align */
>  };
>
> +/* Costs to use when optimizing for MIPS P8700.  */ static const 
> +struct riscv_tune_param mips_p8700_tune_info = {

^^^ Why does this repeat 3 times?

>  static bool riscv_avoid_shrink_wrapping

[PATCH] cobol: Don't require GLOB_BRACE etc. [PR119217]

[Rainer Orth]

cdf-copy.cc doesn't compile on Solaris:

/vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc: In member function ‘int 
copybook_elem_t::open_file(const char*, bool)’:
/vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc:317:34: error: ‘GLOB_BRACE’ 
was not declared in this scope; did you mean ‘GLOB_ERR’?
  317 |   static int flags = GLOB_MARK | GLOB_BRACE | GLOB_TILDE;
  |  ^~
  |  GLOB_ERR
/vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc:317:47: error: ‘GLOB_TILDE’ 
was not declared in this scope
  317 |   static int flags = GLOB_MARK | GLOB_BRACE | GLOB_TILDE;
  |   ^~

GLOB_BRACE and GLOB_TILDE are BSD extensions not in POSIX.1, thus
missing on Solaris probably due to its System V heritage.

This patch introduces fallback definitions to avoid this.

Bootstrapped without regressions on amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.

Ok for trunk?

Rainer

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


2025-04-08  Rainer Orth  

gcc/cobol:
PR cobol/119217
* cdf-copy.cc (GLOB_BRACE): Define fallback.
(GLOB_TILDE): Likewise.

# HG changeset patch
# Parent  a65df53e81219bab53c7be13dc884eb08ee84d7b
cobol: Don't require GLOB_BRACE etc. [PR119217]

diff --git a/gcc/cobol/cdf-copy.cc b/gcc/cobol/cdf-copy.cc
--- a/gcc/cobol/cdf-copy.cc
+++ b/gcc/cobol/cdf-copy.cc
@@ -41,6 +41,16 @@
 #include "util.h"
 #include "copybook.h"
 
+// GLOB_BRACE and GLOB_TILDE are BSD extensions.  Provide fallback definitions
+// if necessary.
+#ifndef GLOB_BRACE
+#define GLOB_BRACE 0
+#endif
+
+#ifndef GLOB_TILDE
+#define GLOB_TILDE 0
+#endif
+
 #define COUNT_OF(X) (sizeof(X) / sizeof(X[0]))
 
 /*

[PATCH] cobol: Initialize regmatch_t portably [PR119217]

[Rainer Orth]

The dts.h initialization of regmatch_t currently breaks Solaris compilation:

In file included from /vol/gcc/src/hg/master/local/gcc/cobol/lexio.h:208,
 from /vol/gcc/src/hg/master/local/gcc/cobol/lexio.cc:36:
/vol/gcc/src/hg/master/local/gcc/cobol/dts.h: In constructor 
‘dts::csub_match::csub_match(const char*)’:
/vol/gcc/src/hg/master/local/gcc/cobol/dts.h:36:35: error: invalid conversion 
from ‘int’ to ‘const char*’ [-fpermissive]
   36 |   static regmatch_t empty = { -1, -1 };
  |   ^~
  |   |
  |   int


The problem is that Solaris regmatch_t has additional members before
rm_so and rm_eo, as is always allowed by POSIX.1

typedef struct {
const char  *rm_sp, *rm_ep; /* Start pointer, end pointer */
regoff_trm_so, rm_eo;   /* Start offset, end offset */
int rm_ss, rm_es;   /* Used internally */
} regmatch_t;

so the initialization doesn't do what it's supposed to do.

Fixed by initializing the rm_so and rm_eo members explicitly.

Bootstrapped without regressions on amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.

Ok for trunk?

Rainer

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


2025-04-08  Rainer Orth  

gcc/cobol:
PR cobol/119217
* dts.h (csub_match): Initialize rm_so, rm_eo fields explicitly.

# HG changeset patch
# Parent  6f227ddea0046a0164509bdb8069e96184304054
cobol: Initialize regmatch_t portably [PR119217]

diff --git a/gcc/cobol/dts.h b/gcc/cobol/dts.h
--- a/gcc/cobol/dts.h
+++ b/gcc/cobol/dts.h
@@ -33,7 +33,8 @@ namespace dts {
   : input(input)
   , first(NULL), second(NULL), matched(false)
 {
-  static regmatch_t empty = { -1, -1 };
+  static regmatch_t empty;
+  empty.rm_so = empty.rm_eo = -1;
   regmatch_t& self(*this);
   self = empty;
 }

[PATCH] cobol: Heed ASM_COMMENT_START

[Rainer Orth]

When building COBOL on Solaris/sparcv9 with the native assembler, many
tests FAIL to assemble at -O0 like this:

FAIL: cobol.dg/data1.cob   -O0  (test for excess errors)
Excess errors:
/usr/ccs/bin/as: "/var/tmp//ccUduuqd.s", line 302: error: invalid character 
(0x50)
/usr/ccs/bin/as: "/var/tmp//ccUduuqd.s", line 302: error: unknown opcode 
"PERFORM"
/usr/ccs/bin/as: "/var/tmp//ccUduuqd.s", line 302: error: statement syntax

The problem is that genapi.cc hardcodes # as assembler comment
character, which isn't valid in general.

Instead, this patch uses ASM_COMMENT_START.

Bootstrapped without regressions on sparcv9-sun-solaris2.11,
amd64-pc-solaris2.11, and x86_64-pc-linux-gnu.

Ok for trunk?

Rainer

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


2025-04-08  Rainer Orth  

gcc/cobol:
* genapi.cc: Include target.h.
(section_label): Use ASM_COMMENT_START.
(paragraph_label): Likewise.
(parser_perform): Likewise.
(internal_perform_through): Likewise.
(hijack_for_development): Likewise.

# HG changeset patch
# Parent  e01495f7d62304ed87b39abf54ef8573b35849c8
cobol: Heed ASM_COMMENT_START

diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
--- a/gcc/cobol/genapi.cc
+++ b/gcc/cobol/genapi.cc
@@ -34,6 +34,7 @@
 #include "tree-iterator.h"
 #include "stringpool.h"
 #include "diagnostic-core.h"
+#include "target.h"
 
 #include "../../libgcobol/ec.h"
 #include "../../libgcobol/common-defs.h"
@@ -2354,7 +2355,8 @@ section_label(struct cbl_proc_t *procedu
 
   cbl_label_t *label = procedure->label;
   // The _initialize_program section isn't relevant.
-  char *psz = xasprintf("# SECTION %s in %s (%ld)",
+  char *psz = xasprintf("%s SECTION %s in %s (%ld)",
+ASM_COMMENT_START,
 label->name,
 current_function->our_unmangled_name,
 deconflictor);
@@ -2405,7 +2407,8 @@ paragraph_label(struct cbl_proc_t *proce
   
   char *psz1 = 
   xasprintf(
-  "# PARAGRAPH %s of %s in %s (%ld)",
+  "%s PARAGRAPH %s of %s in %s (%ld)",
+  ASM_COMMENT_START,
   para_name ? para_name: "" ,
   section_name ? section_name: "(null)" ,
   current_function->our_unmangled_name ? current_function->our_unmangled_name: "" ,
@@ -3003,7 +3006,8 @@ parser_perform(cbl_label_t *label, bool 
 para_name = label->name;
 sect_name = section_label->name;
 sprintf(ach,
-"# PERFORM %s of %s of %s (%ld)",
+"%s PERFORM %s of %s of %s (%ld)",
+ASM_COMMENT_START,
 para_name,
 sect_name,
 program_name,
@@ -3015,7 +3019,8 @@ parser_perform(cbl_label_t *label, bool 
 {
 sect_name = label->name;
 sprintf(ach,
-"# PERFORM %s of %s (%ld)",
+"%s PERFORM %s of %s (%ld)",
+ASM_COMMENT_START,
 sect_name,
 program_name,
 deconflictor);
@@ -3167,8 +3172,8 @@ internal_perform_through( cbl_label_t *p
   pseudo_return_push(proc2, return_addr);
 
   // Create the code that will launch the first procedure
-  gg_insert_into_assembler("# PERFORM %s THROUGH %s",
-proc_1->name, proc_2->name);
+  gg_insert_into_assembler("%s PERFORM %s THROUGH %s",
+ASM_COMMENT_START, proc_1->name, proc_2->name);
 
   if( !suppress_nexting )
 {
@@ -13612,7 +13617,7 @@ hijack_for_development(const char *funcn
   // Assume that funcname is lowercase with no hyphens
   enter_program_common(funcname, funcname);
   parser_display_literal("You have been hijacked by a program named \"dubner\"");
-  gg_insert_into_assembler("# HIJACKED DUBNER CODE START");
+  gg_insert_into_assembler("%s HIJACKED DUBNER CODE START", ASM_COMMENT_START);
 
   for(int i=0; i<10; i++)
 {
@@ -13625,7 +13630,7 @@ hijack_for_development(const char *funcn
 NULL_TREE);
 }
 
-  gg_insert_into_assembler("# HIJACKED DUBNER CODE END");
+  gg_insert_into_assembler("%s HIJACKED DUBNER CODE END", ASM_COMMENT_START);
   gg_return(0);
   }
 

[PATCH] cobol: Avoid conflict with OVERFLOW in system headers [PR119217]

[Rainer Orth]

parse.h causes the COBOL build to break on Solaris:

cobol/parse.h:356:5: error: expected identifier before numeric constant
  356 | OVERFLOW = 305,/* OVERFLOW  */
  | ^~~~ 

The problem is that  has

#define OVERFLOW3

To avoid the conflict, this patch renames OVERFLOW to OVERFLOW_kw,
following existing praxis.

I wonder if such a * -> *_kw rename should be done globally instead on a
case-by-case basis?

Btw., token_names.h has a comment claiming

// generated by ./token_names.h.gen ../../build/gcc/cobol/parse.h

but there's no token_names.h.gen anywhere in the tree, so I've updated
the file manually.

Bootstrapped without regressions on amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.

Ok for trunk?

Rainer

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


2025-04-08  Rainer Orth  

gcc/cobol:
PR cobol/119217
* parse.y: Rename OVERFLOW to OVERFLOW_kw.
* scan.l: Likewise.
* token_names.h: Regenerate.

# HG changeset patch
# Parent  27b255cba8a177f6e7d5fdbed305620463b6f2cf
cobol: Avoid conflict with OVERFLOW in system headers [PR119217]

diff --git a/gcc/cobol/parse.y b/gcc/cobol/parse.y
--- a/gcc/cobol/parse.y
+++ b/gcc/cobol/parse.y
@@ -337,7 +337,7 @@
 %token  INVALID
 %token  NUMBER NEGATIVE
 %token  NUMSTR"numeric literal"
-%token  OVERFLOW
+%token  OVERFLOW_kw
 %token   COMPUTATIONAL
 
 %token PERFORM BACKWARD
@@ -996,7 +996,7 @@
 DELETE DISPLAY DIVIDE EVALUATE END EOP EXIT FILLER_kw
 GOBACK GOTO
 INITIALIZE INSPECT
-MERGE MOVE MULTIPLY OPEN OVERFLOW PARAGRAPH PERFORM
+MERGE MOVE MULTIPLY OPEN OVERFLOW_kw PARAGRAPH PERFORM
 READ RELEASE RETURN REWRITE
 SEARCH SET SELECT SORT SORT_MERGE
 STRING_kw STOP SUBTRACT START
@@ -9493,7 +9493,7 @@ call_except:EXCEPTION
 std::swap($$.on_error, $$.not_error);
   }
 }
-|   OVERFLOW
+|   OVERFLOW_kw
 {
   $$.not_error = NULL;
   $$.on_error = label_add(LblArith,
@@ -9501,7 +9501,7 @@ call_except:EXCEPTION
   if( !$$.on_error ) YYERROR;
   parser_call_exception( $$.on_error );
 
-  assert( $1 == OVERFLOW || $1 == NOT );
+  assert( $1 == OVERFLOW_kw || $1 == NOT );
   if( $1 == NOT ) {
 std::swap($$.on_error, $$.not_error);
   }
@@ -9756,7 +9756,7 @@ on_overflows:   on_overflow[over] statem
 }
 ;
 
-on_overflow:OVERFLOW
+on_overflow:OVERFLOW_kw
 {
   $$.not_error = NULL;
   $$.on_error = label_add(LblString,
@@ -9764,7 +9764,7 @@ on_overflow:OVERFLOW
   if( !$$.on_error ) YYERROR;
   parser_string_overflow( $$.on_error );
 
-  assert( $1 == OVERFLOW || $1 == NOT );
+  assert( $1 == OVERFLOW_kw || $1 == NOT );
   if( $1 == NOT ) {
 std::swap($$.on_error, $$.not_error);
   }
diff --git a/gcc/cobol/scan.l b/gcc/cobol/scan.l
--- a/gcc/cobol/scan.l
+++ b/gcc/cobol/scan.l
@@ -1543,9 +1543,9 @@ USE({SPC}FOR)?		{ return USE; }
   NOT{SPC}(ON{SPC})?EXCEPTION {
   yylval.number = NOT;   return EXCEPTION; }
 
- (ON{SPC})?OVERFLOW  { yylval.number = OVERFLOW; return OVERFLOW; }
+ (ON{SPC})?OVERFLOW  { yylval.number = OVERFLOW_kw; return OVERFLOW_kw; }
   NOT{SPC}(ON{SPC})?OVERFLOW {
-  yylval.number = NOT;  return OVERFLOW; }
+  yylval.number = NOT;  return OVERFLOW_kw; }
 
  (AT{SPC})?END/[[:space:]]{ yylval.number = END;
return END; }
@@ -2312,7 +2312,7 @@ BASIS		{ yy_push_state(basis); return BA
   ORGANIZATION	{ return ORGANIZATION; }
   OTHER	{ return OTHER; }
   OUTPUT	{ return OUTPUT; }
-  OVERFLOW	{ return OVERFLOW; }
+  OVERFLOW	{ return OVERFLOW_kw; }
   OVERRIDE	{ return OVERRIDE; }
   PACKED-DECIMAL	{ return PACKED_DECIMAL; }
   PAGE	{ return PAGE; }
diff --git a/gcc/cobol/token_names.h b/gcc/cobol/token_names.h
--- a/gcc/cobol/token_names.h
+++ b/gcc/cobol/token_names.h
@@ -49,7 +49,7 @@ tokens = {
 { "number", NUMBER }, // 302
 { "negative", NEGATIVE }, // 303
 { "numstr", NUMSTR }, // 304
-{ "overflow", OVERFLOW }, // 305
+{ "overflow", OVERFLOW_kw }, // 305
 { "computational", COMPUTATIONAL }, // 306
 { "perform", PERFORM }, // 307
  

Re: [PATCH v2] libstdc++: Implement C++26 features (P2546R5)

[Jonathan Wakely]

On Fri, 11 Apr 2025 at 09:12, Jonathan Wakely  wrote:
>
> On Fri, 11 Apr 2025 at 08:00, Tomasz Kaminski  wrote:
> >
> >
> >
> > On Thu, Apr 10, 2025 at 6:53 PM Jonathan Wakely  wrote:
> >>
> >> It would be good to provide a macOS definition of is_debugger_present as
> >> per https://developer.apple.com/library/archive/qa/qa1361/_index.html
> >> but that isn't included in this change.
> >>
> >> libstdc++-v3/ChangeLog:
> >>
> >> * config.h.in: Regenerate.
> >> * configure: Regenerate.
> >> * configure.ac: Check for facilities needed by .
> >> * include/Makefile.am: Add new header.
> >> * include/Makefile.in: Regenerate.
> >> * include/bits/version.def (debugging): Add.
> >> * include/bits/version.h: Regenerate.
> >> * src/c++26/Makefile.am: Add new file.
> >> * src/c++26/Makefile.in: Regenerate.
> >> * include/std/debugging: New file.
> >> * src/c++26/debugging.cc: New file.
> >> * testsuite/19_diagnostics/debugging/breakpoint.cc: New test.
> >> * testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc:
> >> New test.
> >> * testsuite/19_diagnostics/debugging/is_debugger_present.cc: New
> >> test.
> >> ---
> >>
> >> I sent v1 of this patch in June last year:
> >> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653293.html
> >> My comments about testing with GDB still apply.
> >>
> >> Compared to v1, this adds a void __gnu_cxx::attach_debugger(bool)
> >> function that could be called by debuggers to announce that they are
> >> attaching and detaching. It also adds a systemtap probe point to
> >> std::breakpoint().
> >>
> >> Tested x86_64-linux.
> >>
> >> N.B. this only adds new symbols to the libstdc++exp.a archive, not to
> >> libstdc++.so so it's not a risky change at this stage.
> >>
> >>  libstdc++-v3/config.h.in  |   9 +
> >>  libstdc++-v3/configure|  22 +++
> >>  libstdc++-v3/configure.ac |   9 +
> >>  libstdc++-v3/include/Makefile.am  |   1 +
> >>  libstdc++-v3/include/Makefile.in  |   1 +
> >>  libstdc++-v3/include/bits/version.def |   8 +
> >>  libstdc++-v3/include/bits/version.h   |  10 ++
> >>  libstdc++-v3/include/std/debugging|  77 
> >>  libstdc++-v3/src/c++26/Makefile.am|   4 +-
> >>  libstdc++-v3/src/c++26/Makefile.in|   7 +-
> >>  libstdc++-v3/src/c++26/debugging.cc   | 165 ++
> >>  .../19_diagnostics/debugging/breakpoint.cc|  13 ++
> >>  .../debugging/breakpoint_if_debugging.cc  |  13 ++
> >>  .../debugging/is_debugger_present.cc  |  14 ++
> >>  14 files changed, 350 insertions(+), 3 deletions(-)
> >>  create mode 100644 libstdc++-v3/include/std/debugging
> >>  create mode 100644 libstdc++-v3/src/c++26/debugging.cc
> >>  create mode 100644 
> >> libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint.cc
> >>  create mode 100644 
> >> libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc
> >>  create mode 100644 
> >> libstdc++-v3/testsuite/19_diagnostics/debugging/is_debugger_present.cc
> >>
> >> diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
> >> index 77bbaf1beaa..3f1331ff36f 100644
> >> --- a/libstdc++-v3/config.h.in
> >> +++ b/libstdc++-v3/config.h.in
> >> @@ -70,6 +70,9 @@
> >>  /* Define to 1 if you have the `cosl' function. */
> >>  #undef HAVE_COSL
> >>
> >> +/* Define to 1 if you have the  header file. */
> >> +#undef HAVE_DEBUGAPI_H
> >> +
> >>  /* Define to 1 if you have the declaration of `strnlen', and to 0 if you
> >> don't. */
> >>  #undef HAVE_DECL_STRNLEN
> >> @@ -439,6 +442,9 @@
> >>  /* Define to 1 if you have the  header file. */
> >>  #undef HAVE_SYS_PARAM_H
> >>
> >> +/* Define to 1 if you have the  header file. */
> >> +#undef HAVE_SYS_PTRACE_H
> >> +
> >>  /* Define to 1 if you have the  header file. */
> >>  #undef HAVE_SYS_RESOURCE_H
> >>
> >> @@ -850,6 +856,9 @@
> >>  /* Define if nl_langinfo_l should be used for std::text_encoding. */
> >>  #undef _GLIBCXX_USE_NL_LANGINFO_L
> >>
> >> +/* Define if /proc/self/status should be used for . */
> >> +#undef _GLIBCXX_USE_PROC_SELF_STATUS
> >> +
> >>  /* Define if pthreads_num_processors_np is available in . */
> >>  #undef _GLIBCXX_USE_PTHREADS_NUM_PROCESSORS_NP
> >>
> >> diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
> >> index 819a1d82876..8143df91c38 100755
> >> --- a/libstdc++-v3/configure
> >> +++ b/libstdc++-v3/configure
> >> @@ -54700,6 +54700,28 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
> >>
> >>
> >>
> >> +# For std::is_debugger_present
> >> +case "$target_os" in
> >> +  linux*)
> >> +
> >> +$as_echo "#define _GLIBCXX_USE_PROC_SELF_STATUS 1" >>confdefs.h
> >> +
> >> +;;
> >> +esac
> >> +for ac_header in sys/ptrace.h debugapi.h
> >> +do :
> >> +  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
> >> +ac_fn_c_check_head

[PATCH] cobol: Avoid conflict with timespec_t in system headers [PR119217]

[Rainer Orth]

util.cc doesn't compile on Solaris:

/vol/gcc/src/hg/master/local/gcc/cobol/util.cc:2135:7: error: using 
typedef-name ‘timespec_t’ after ‘class’
 2135 | class timespec_t {
  |   ^~

This happens because  declares timespec_t itself.  In fact,
POSIX.1 reserves every *_t identifier, so this is benign.

To avoid the problem, this patch renames the cobol timespec_t to
cbl_timespec.

Bootstrapped without regressions on amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.

Ok for trunk?

Rainer

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


2025-04-08  Rainer Orth  

gcc/cobol:
PR cobol/119217
* util.cc (class timespec_t): Rename to cbl_timespec.

# HG changeset patch
# Parent  a197b84b9d8ad6e9e48f7d6f99e686f84406364e
cobol: Avoid conflict with timespec_t in system headers  [PR119217]

diff --git a/gcc/cobol/util.cc b/gcc/cobol/util.cc
--- a/gcc/cobol/util.cc
+++ b/gcc/cobol/util.cc
@@ -2132,20 +2132,20 @@ cobol_fileline_set( const char line[] ) 
   return file.name;
 }
 
-class timespec_t {
+class cbl_timespec {
   struct timespec now;
  public:
-  timespec_t() {
+  cbl_timespec() {
 clock_gettime(CLOCK_MONOTONIC, &now);
   }
   double ns() const {
 return now.tv_sec * 10 + now.tv_nsec;
   }
-  friend double operator-( const timespec_t& now, const timespec_t& then );
+  friend double operator-( const cbl_timespec& now, const cbl_timespec& then );
 };
 
 double
-operator-( const timespec_t& then, const timespec_t& now ) {
+operator-( const cbl_timespec& then, const cbl_timespec& now ) {
   return (now.ns() - then.ns()) / 10;
 }
 
@@ -2158,11 +2158,11 @@ parse_file( const char filename[] )
 
   parser_enter_file(filename);
 
-  timespec_t start;
+  cbl_timespec start;
 
   int erc = yyparse();
 
-  timespec_t finish;
+  cbl_timespec finish;
   double dt  = finish - start;
   parser_leave_file();
 

[PATCH] libgcobol: Check for struct tm tm_zone

[Rainer Orth]

intrinsic.cc doesn't compile on Solaris:

/vol/gcc/src/hg/master/cobol/libgcobol/intrinsic.cc: In function ‘void 
__gg__formatted_current_date(cblc_field_t*, cblc_field_t*, std::size_t, 
std::size_t)’:
/vol/gcc/src/hg/master/cobol/libgcobol/intrinsic.cc:1480:6: error: ‘struct 
std::tm’ has no member named ‘tm_zone’; did you mean ‘tm_mon’?
 1480 |   tm.tm_zone = "GMT";
  |  ^~~
  |  tm_mon

struct tm.tm_zone is new in POSIX.1-2024, thus cannot be assumed to be
present universally.

This patch uses Autoconf's AC_STRUCT_TIMEZONE to determine its presence
and guard the use accordingly.

Bootstrapped without regressions on amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11, and x86_64-pc-solaris2.11.

Ok for trunk?

Rainer

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


2025-04-08  Rainer Orth  

libgcobol:
* configure.ac (AC_STRUCT_TIMEZONE): Invoke.
* configure, config.h.in: Regenerate.
* intrinsic.cc (__gg__formatted_current_date): Guard tm.tm_zone
use with HAVE_STRUCT_TM_TM_ZONE.

# HG changeset patch
# Parent  2539416fae8a4be2bb28b4acd8a3a54f0d164792
libgcobol: Check for struct tm tm_zone

diff --git a/libgcobol/config.h.in b/libgcobol/config.h.in
--- a/libgcobol/config.h.in
+++ b/libgcobol/config.h.in
@@ -6,6 +6,10 @@
 /* Define to 1 if you have the  header file. */
 #undef HAVE_COMPLEX_H
 
+/* Define to 1 if you have the declaration of `tzname', and to 0 if you don't.
+   */
+#undef HAVE_DECL_TZNAME
+
 /* Define to 1 if you have the  header file. */
 #undef HAVE_DLFCN_H
 
@@ -72,12 +76,23 @@
 /* Define to 1 if you have the `strtof128' function. */
 #undef HAVE_STRTOF128
 
+/* Define to 1 if `tm_zone' is a member of `struct tm'. */
+#undef HAVE_STRUCT_TM_TM_ZONE
+
 /* Define to 1 if you have the  header file. */
 #undef HAVE_SYS_STAT_H
 
 /* Define to 1 if you have the  header file. */
 #undef HAVE_SYS_TYPES_H
 
+/* Define to 1 if your `struct tm' has `tm_zone'. Deprecated, use
+   `HAVE_STRUCT_TM_TM_ZONE' instead. */
+#undef HAVE_TM_ZONE
+
+/* Define to 1 if you don't have `tm_zone' but do have the external array
+   `tzname'. */
+#undef HAVE_TZNAME
+
 /* Define to 1 if you have the  header file. */
 #undef HAVE_UNISTD_H
 
@@ -112,6 +127,9 @@
 /* Define to 1 if you have the ANSI C header files. */
 #undef STDC_HEADERS
 
+/* Define to 1 if your  declares `struct tm'. */
+#undef TM_IN_SYS_TIME
+
 /* Define if IEC 60559 *f128 APIs should be used for _Float128. */
 #undef USE_IEC_60559
 
diff --git a/libgcobol/configure b/libgcobol/configure
--- a/libgcobol/configure
+++ b/libgcobol/configure
@@ -2449,6 +2449,109 @@ eval ac_res=\$$3
   eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
 
 } # ac_fn_cxx_check_func
+
+# ac_fn_cxx_check_member LINENO AGGR MEMBER VAR INCLUDES
+# --
+# Tries to find if the field MEMBER exists in type AGGR, after including
+# INCLUDES, setting cache variable VAR accordingly.
+ac_fn_cxx_check_member ()
+{
+  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2.$3" >&5
+$as_echo_n "checking for $2.$3... " >&6; }
+if eval \${$4+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$5
+int
+main ()
+{
+static $2 ac_aggr;
+if (ac_aggr.$3)
+return 0;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_compile "$LINENO"; then :
+  eval "$4=yes"
+else
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$5
+int
+main ()
+{
+static $2 ac_aggr;
+if (sizeof ac_aggr.$3)
+return 0;
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_compile "$LINENO"; then :
+  eval "$4=yes"
+else
+  eval "$4=no"
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+eval ac_res=\$$4
+	   { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
+$as_echo "$ac_res" >&6; }
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+
+} # ac_fn_cxx_check_member
+
+# ac_fn_cxx_check_decl LINENO SYMBOL VAR INCLUDES
+# ---
+# Tests whether SYMBOL is declared in INCLUDES, setting cache variable VAR
+# accordingly.
+ac_fn_cxx_check_decl ()
+{
+  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
+  as_decl_name=`echo $2|sed 's/ *(.*//'`
+  as_decl_use=`echo $2|sed -e 's/(/((/' -e 's/)/) 0&/' -e 's/,/) 0& (/g'`
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $as_decl_name is declared" >&5
+$as_echo_n "checking whether $as_decl_name is declared... " >&6; }
+if eval \${$3+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+int
+main ()
+{
+#ifndef $as_decl_name
+#ifdef __cplusplus
+  (void) 

[PATCH] libgcobol: Heed --enable-libgcobol

[Rainer Orth]

If some target isn't listed as supported in configure.tgt,
--enable-libgcobol cannot override that.  However, that's what should
happen just like an explicit --enable-languages=cobol forces the
frontend to be built.

This patch, shamelessly adapted from libphobos, does just that.

Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11, and
x86_64-pc-linux-gnu.

Ok for trunk?

Rainer

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


2025-04-08  Rainer Orth  

libgcobol:
* configure.ac: Handle --enable-libgcobol.
Let it override LIBGCOBOL_SUPPORTED.
* configure: Regenerate.

# HG changeset patch
# Parent  8f74fa645e6abe23c5084a2f2b0b05c3a34e3e0a
libgcobol: Heed --enable-libgcobol

diff --git a/libgcobol/configure b/libgcobol/configure
--- a/libgcobol/configure
+++ b/libgcobol/configure
@@ -788,6 +788,7 @@ enable_option_checking
 enable_multilib
 enable_maintainer_mode
 enable_silent_rules
+enable_libgcobol
 enable_version_specific_runtime_libs
 enable_dependency_tracking
 enable_shared
@@ -1438,6 +1439,7 @@ Optional Features:
   sometimes confusing) to the casual installer
   --enable-silent-rules   less verbose build output (undo: "make V=1")
   --disable-silent-rules  verbose build output (undo: "make V=0")
+  --enable-libgcobol  Enable libgcobol
   --enable-version-specific-runtime-libs
   Specify that runtime libraries should be installed
   in a compiler-specific directory
@@ -3721,6 +3723,16 @@ END
 fi
 
 
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for --enable-libgcobol" >&5
+$as_echo_n "checking for --enable-libgcobol... " >&6; }
+# Check whether --enable-libgcobol was given.
+if test "${enable_libgcobol+set}" = set; then :
+  enableval=$enable_libgcobol;
+fi
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $enable_libgcobol" >&5
+$as_echo "$enable_libgcobol" >&6; }
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for --enable-version-specific-runtime-libs" >&5
 $as_echo_n "checking for --enable-version-specific-runtime-libs... " >&6; }
 # Check whether --enable-version-specific-runtime-libs was given.
@@ -11796,7 +11808,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11799 "configure"
+#line 11811 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11902,7 +11914,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11905 "configure"
+#line 11917 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -16793,6 +16805,14 @@ cat >>confdefs.h <<_ACEOF
 unset LIBGCOBOL_SUPPORTED
 . ${srcdir}/configure.tgt
 
+# Decide if it's usable.
+case $LIBGCOBOL_SUPPORTED:$enable_libgcobol in
+*:no)  use_libgcobol=no  ;;
+*:yes) use_libgcobol=yes ;;
+yes:*) use_libgcobol=yes ;;
+*:*)   use_libgcobol=no  ;;
+esac
+
 # -
 # __int128 support
 # -
@@ -16885,7 +16905,7 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $libgcobol_cv_have_int128" >&5
 $as_echo "$libgcobol_cv_have_int128" >&6; }
 
- if test "x$LIBGCOBOL_SUPPORTED" = xyes && test "x$libgcobol_cv_have_int128" = xyes; then
+ if test "x$use_libgcobol" = xyes && test "x$libgcobol_cv_have_int128" = xyes; then
   BUILD_LIBGCOBOL_TRUE=
   BUILD_LIBGCOBOL_FALSE='#'
 else
diff --git a/libgcobol/configure.ac b/libgcobol/configure.ac
--- a/libgcobol/configure.ac
+++ b/libgcobol/configure.ac
@@ -40,6 +40,11 @@ AM_MAINTAINER_MODE
 
 AM_INIT_AUTOMAKE([1.15.1 no-define foreign no-dist -Wall -Wno-portability])
 
+AC_MSG_CHECKING([for --enable-libgcobol])
+AC_ARG_ENABLE(libgcobol,
+  [AS_HELP_STRING([--enable-libgcobol], [Enable libgcobol])])
+AC_MSG_RESULT($enable_libgcobol)
+
 AC_MSG_CHECKING([for --enable-version-specific-runtime-libs])
 AC_ARG_ENABLE(version-specific-runtime-libs,
 AS_HELP_STRING([--enable-version-specific-runtime-libs],
@@ -138,6 +143,14 @@ AC_CHECK_SIZEOF([void *])
 unset LIBGCOBOL_SUPPORTED
 . ${srcdir}/configure.tgt
 
+# Decide if it's usable.
+case $LIBGCOBOL_SUPPORTED:$enable_libgcobol in
+*:no)  use_libgcobol=no  ;;
+*:yes) use_libgcobol=yes ;;
+yes:*) use_libgcobol=yes ;;
+*:*)   use_libgcobol=no  ;;
+esac
+
 # -
 # __int128 support
 # -
@@ -164,7 +177,7 @@ AC_CACHE_CHECK([whether __int128 is supp
 libgcobol_cv_have_int128=no
 ])])
 
-AM_CONDITIONAL(BUILD_LIBGCOBOL, [test "x$LIBGCOBOL_SUPPORTED" = xyes && test "x$libgcobol_cv_have_int128" = xyes])
+AM_CONDITIONAL(BUILD_LIBGCOBOL, [test "x$use_libgcobol" = xyes && test "x$libgcobol_cv_have_int128" = xyes])
 
 # Check if functions are available in libc before adding extra libs.
 AC_SEARCH_LIBS([malloc], [c])

Re: [PATCH] aarch64: Fix CFA offsets in non-initial stack probes [PR119610]

[Richard Sandiford]

Richard Biener  writes:
> On Thu, Apr 10, 2025 at 10:10 PM Richard Sandiford
>  wrote:
>>
>> PR119610 is about incorrect CFI output for a stack probe when that
>> probe is not the initial allocation.  The main aarch64 stack probe
>> function, aarch64_allocate_and_probe_stack_space, implicitly assumed
>> that the incoming stack pointer pointed to the top of the frame,
>> and thus held the CFA.
>>
>> aarch64_save_callee_saves and aarch64_restore_callee_saves use a
>> parameter called bytes_below_sp to track how far the stack pointer
>> is above the base of the static frame.  This patch does the same
>> thing for aarch64_allocate_and_probe_stack_space.
>>
>> Also, I noticed that the SVE path was attaching the first CFA note
>> to the wrong instruction: it was attaching the note to the calculation
>> of the stack size, rather than to the r11<-sp copy.
>>
>> Bootstrapped & regression-tested on aarch64-linux-gnu.  I'll push on
>> Monday if there are no comments before then.  I'd appreciate a second
>> pair of eyes though, since this is a sensitive area.
>
> Do you happen to know if the backports to older branches you provided for
> the change that triggered this issue (in particular to GCC 7) are also 
> affected?

GCC 7 and GCC 8 should be ok.  The bug relies on stack protection being
enabled (-fstack-protector-strong for the testcase in the PR, but just
-fstack-protector for others) and that was added in GCC 9.

> The testcase from the PR does not fail in the reported way for me, but I guess
> that very much depends on "details".

Oh, even on trunk?  Does adding:

  volatile int unused[N] = {};

to main for various N change things?

Thanks,
Richard

Re: [PATCH v2] libstdc++: Implement C++26 features (P2546R5)

[Tomasz Kaminski]

On Fri, Apr 11, 2025 at 10:13 AM Jonathan Wakely  wrote:

> On Fri, 11 Apr 2025 at 08:00, Tomasz Kaminski  wrote:
> >
> >
> >
> > On Thu, Apr 10, 2025 at 6:53 PM Jonathan Wakely 
> wrote:
> >>
> >> It would be good to provide a macOS definition of is_debugger_present as
> >> per https://developer.apple.com/library/archive/qa/qa1361/_index.html
> >> but that isn't included in this change.
> >>
> >> libstdc++-v3/ChangeLog:
> >>
> >> * config.h.in: Regenerate.
> >> * configure: Regenerate.
> >> * configure.ac: Check for facilities needed by .
> >> * include/Makefile.am: Add new header.
> >> * include/Makefile.in: Regenerate.
> >> * include/bits/version.def (debugging): Add.
> >> * include/bits/version.h: Regenerate.
> >> * src/c++26/Makefile.am: Add new file.
> >> * src/c++26/Makefile.in: Regenerate.
> >> * include/std/debugging: New file.
> >> * src/c++26/debugging.cc: New file.
> >> * testsuite/19_diagnostics/debugging/breakpoint.cc: New test.
> >> * testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc:
> >> New test.
> >> * testsuite/19_diagnostics/debugging/is_debugger_present.cc: New
> >> test.
> >> ---
> >>
> >> I sent v1 of this patch in June last year:
> >> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653293.html
> >> My comments about testing with GDB still apply.
> >>
> >> Compared to v1, this adds a void __gnu_cxx::attach_debugger(bool)
> >> function that could be called by debuggers to announce that they are
> >> attaching and detaching. It also adds a systemtap probe point to
> >> std::breakpoint().
> >>
> >> Tested x86_64-linux.
> >>
> >> N.B. this only adds new symbols to the libstdc++exp.a archive, not to
> >> libstdc++.so so it's not a risky change at this stage.
> >>
> >>  libstdc++-v3/config.h.in  |   9 +
> >>  libstdc++-v3/configure|  22 +++
> >>  libstdc++-v3/configure.ac |   9 +
> >>  libstdc++-v3/include/Makefile.am  |   1 +
> >>  libstdc++-v3/include/Makefile.in  |   1 +
> >>  libstdc++-v3/include/bits/version.def |   8 +
> >>  libstdc++-v3/include/bits/version.h   |  10 ++
> >>  libstdc++-v3/include/std/debugging|  77 
> >>  libstdc++-v3/src/c++26/Makefile.am|   4 +-
> >>  libstdc++-v3/src/c++26/Makefile.in|   7 +-
> >>  libstdc++-v3/src/c++26/debugging.cc   | 165 ++
> >>  .../19_diagnostics/debugging/breakpoint.cc|  13 ++
> >>  .../debugging/breakpoint_if_debugging.cc  |  13 ++
> >>  .../debugging/is_debugger_present.cc  |  14 ++
> >>  14 files changed, 350 insertions(+), 3 deletions(-)
> >>  create mode 100644 libstdc++-v3/include/std/debugging
> >>  create mode 100644 libstdc++-v3/src/c++26/debugging.cc
> >>  create mode 100644
> libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint.cc
> >>  create mode 100644
> libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc
> >>  create mode 100644
> libstdc++-v3/testsuite/19_diagnostics/debugging/is_debugger_present.cc
> >>
> >> diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
> >> index 77bbaf1beaa..3f1331ff36f 100644
> >> --- a/libstdc++-v3/config.h.in
> >> +++ b/libstdc++-v3/config.h.in
> >> @@ -70,6 +70,9 @@
> >>  /* Define to 1 if you have the `cosl' function. */
> >>  #undef HAVE_COSL
> >>
> >> +/* Define to 1 if you have the  header file. */
> >> +#undef HAVE_DEBUGAPI_H
> >> +
> >>  /* Define to 1 if you have the declaration of `strnlen', and to 0 if
> you
> >> don't. */
> >>  #undef HAVE_DECL_STRNLEN
> >> @@ -439,6 +442,9 @@
> >>  /* Define to 1 if you have the  header file. */
> >>  #undef HAVE_SYS_PARAM_H
> >>
> >> +/* Define to 1 if you have the  header file. */
> >> +#undef HAVE_SYS_PTRACE_H
> >> +
> >>  /* Define to 1 if you have the  header file. */
> >>  #undef HAVE_SYS_RESOURCE_H
> >>
> >> @@ -850,6 +856,9 @@
> >>  /* Define if nl_langinfo_l should be used for std::text_encoding. */
> >>  #undef _GLIBCXX_USE_NL_LANGINFO_L
> >>
> >> +/* Define if /proc/self/status should be used for . */
> >> +#undef _GLIBCXX_USE_PROC_SELF_STATUS
> >> +
> >>  /* Define if pthreads_num_processors_np is available in . */
> >>  #undef _GLIBCXX_USE_PTHREADS_NUM_PROCESSORS_NP
> >>
> >> diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
> >> index 819a1d82876..8143df91c38 100755
> >> --- a/libstdc++-v3/configure
> >> +++ b/libstdc++-v3/configure
> >> @@ -54700,6 +54700,28 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
> >>
> >>
> >>
> >> +# For std::is_debugger_present
> >> +case "$target_os" in
> >> +  linux*)
> >> +
> >> +$as_echo "#define _GLIBCXX_USE_PROC_SELF_STATUS 1" >>confdefs.h
> >> +
> >> +;;
> >> +esac
> >> +for ac_header in sys/ptrace.h debugapi.h
> >> +do :
> >> +  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
> >> +ac_fn_c_check_header_mon

Re: [PATCH] libgcobol: Use strchr instead of index

[Jakub Jelinek]

On Fri, Apr 11, 2025 at 11:29:41AM +0200, Rainer Orth wrote:
> valconf.cc doesn't compile on Solaris:
> 
> cobol/valconv.cc: In function ‘bool __gg__string_to_numeric_edited(char*, 
> char*, int, int, const char*)’:
> cobol/valconv.cc:856:40: error: ‘index’ was not declared in this scope; did 
> you mean ‘Rindex’?
>   856 | const char *decimal_location = index(dest, 
> __gg__decimal_point);  |^
>  |Rindex
> 
> On Solaris, it's only declared in .  While one could get that
> included, it's way easier to just use strchr as is already the case in
> other instances.
> 
> Bootstrapped without regressions on amd64-pc-solaris2.11,
> sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.
> 
> Ok for trunk?
> 
>   Rainer
> 
> -- 
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
> 
> 
> 2025-04-08  Rainer Orth  
> 
>   libgcobol:
>   * valconv.cc (__gg__string_to_numeric_edited): Use strchr instead
>   of index.

Ok.

Jakub

[PATCH] libgcobol: Use strchr instead of index

[Rainer Orth]

valconf.cc doesn't compile on Solaris:

cobol/valconv.cc: In function ‘bool __gg__string_to_numeric_edited(char*, 
char*, int, int, const char*)’:
cobol/valconv.cc:856:40: error: ‘index’ was not declared in this scope; did you 
mean ‘Rindex’?
  856 | const char *decimal_location = index(dest, 
__gg__decimal_point);  |^
 |Rindex

On Solaris, it's only declared in .  While one could get that
included, it's way easier to just use strchr as is already the case in
other instances.

Bootstrapped without regressions on amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.

Ok for trunk?

Rainer

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


2025-04-08  Rainer Orth  

libgcobol:
* valconv.cc (__gg__string_to_numeric_edited): Use strchr instead
of index.

# HG changeset patch
# Parent  be296f4eb243c38e35fea662a602703491faa67a
libgcobol: Use strchr instead of index

diff --git a/libgcobol/valconv.cc b/libgcobol/valconv.cc
--- a/libgcobol/valconv.cc
+++ b/libgcobol/valconv.cc
@@ -853,14 +853,14 @@ got_float:
 }
   else
 {
-const char *decimal_location = index(dest, __gg__decimal_point);
+const char *decimal_location = strchr(dest, __gg__decimal_point);
 if( !decimal_location )
   {
-  decimal_location = index(dest, ascii_v);
+  decimal_location = strchr(dest, ascii_v);
   }
 if( !decimal_location )
   {
-  decimal_location = index(dest, ascii_V);
+  decimal_location = strchr(dest, ascii_V);
   }
 if( !decimal_location )
   {

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Andreas Schwab]

On Apr 11 2025, Rainer Orth wrote:

> All users of symbols.h fail to compile on Solaris:
>
> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope:
> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1365:13: error: ‘NAME_MAX’ 
> was not declared in this scope
>  1365 |   char name[NAME_MAX];
>   | ^~~~
>
> NAME_MAX being undefined is allowed by POSIX.1, actually: it's listed
> for  under "Pathname Variable Values":

It doesn't look like this member is accociated with file names at all.

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

Re: [PATCH] libgcobol: Check for struct tm tm_zone

[Andreas Schwab]

On Apr 11 2025, Rainer Orth wrote:

> This patch uses Autoconf's AC_STRUCT_TIMEZONE to determine its presence
> and guard the use accordingly.

You cannot use AC_STRUCT_TIMEZONE because it requires a link test (which
is forbidden in a target module, see PR119550).

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

Re: [PATCH] cobol: Heed ASM_COMMENT_START

[Richard Biener]

On Fri, Apr 11, 2025 at 10:57 AM Rainer Orth
 wrote:
>
> When building COBOL on Solaris/sparcv9 with the native assembler, many
> tests FAIL to assemble at -O0 like this:
>
> FAIL: cobol.dg/data1.cob   -O0  (test for excess errors)
> Excess errors:
> /usr/ccs/bin/as: "/var/tmp//ccUduuqd.s", line 302: error: invalid character 
> (0x50)
> /usr/ccs/bin/as: "/var/tmp//ccUduuqd.s", line 302: error: unknown opcode 
> "PERFORM"
> /usr/ccs/bin/as: "/var/tmp//ccUduuqd.s", line 302: error: statement syntax
>
> The problem is that genapi.cc hardcodes # as assembler comment
> character, which isn't valid in general.
>
> Instead, this patch uses ASM_COMMENT_START.
>
> Bootstrapped without regressions on sparcv9-sun-solaris2.11,
> amd64-pc-solaris2.11, and x86_64-pc-linux-gnu.
>
> Ok for trunk?

OK.

> Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>
> 2025-04-08  Rainer Orth  
>
> gcc/cobol:
> * genapi.cc: Include target.h.
> (section_label): Use ASM_COMMENT_START.
> (paragraph_label): Likewise.
> (parser_perform): Likewise.
> (internal_perform_through): Likewise.
> (hijack_for_development): Likewise.
>

Re: [PATCH] cobol: Avoid conflict with OVERFLOW in system headers [PR119217]

[Richard Biener]

On Fri, Apr 11, 2025 at 11:03 AM Rainer Orth
 wrote:
>
> parse.h causes the COBOL build to break on Solaris:
>
> cobol/parse.h:356:5: error: expected identifier before numeric constant
>   356 | OVERFLOW = 305,/* OVERFLOW  */
>   | ^~~~
>
> The problem is that  has
>
> #define OVERFLOW3
>
> To avoid the conflict, this patch renames OVERFLOW to OVERFLOW_kw,
> following existing praxis.
>
> I wonder if such a * -> *_kw rename should be done globally instead on a
> case-by-case basis?
>
> Btw., token_names.h has a comment claiming
>
> // generated by ./token_names.h.gen ../../build/gcc/cobol/parse.h
>
> but there's no token_names.h.gen anywhere in the tree, so I've updated
> the file manually.
>
> Bootstrapped without regressions on amd64-pc-solaris2.11,
> sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.
>
> Ok for trunk?

OK.

> Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>
> 2025-04-08  Rainer Orth  
>
> gcc/cobol:
> PR cobol/119217
> * parse.y: Rename OVERFLOW to OVERFLOW_kw.
> * scan.l: Likewise.
> * token_names.h: Regenerate.
>

Re: [PATCH] aarch64: Fix CFA offsets in non-initial stack probes [PR119610]

[Richard Biener]

On Fri, Apr 11, 2025 at 11:10 AM Richard Sandiford
 wrote:
>
> Richard Biener  writes:
> > On Thu, Apr 10, 2025 at 10:10 PM Richard Sandiford
> >  wrote:
> >>
> >> PR119610 is about incorrect CFI output for a stack probe when that
> >> probe is not the initial allocation.  The main aarch64 stack probe
> >> function, aarch64_allocate_and_probe_stack_space, implicitly assumed
> >> that the incoming stack pointer pointed to the top of the frame,
> >> and thus held the CFA.
> >>
> >> aarch64_save_callee_saves and aarch64_restore_callee_saves use a
> >> parameter called bytes_below_sp to track how far the stack pointer
> >> is above the base of the static frame.  This patch does the same
> >> thing for aarch64_allocate_and_probe_stack_space.
> >>
> >> Also, I noticed that the SVE path was attaching the first CFA note
> >> to the wrong instruction: it was attaching the note to the calculation
> >> of the stack size, rather than to the r11<-sp copy.
> >>
> >> Bootstrapped & regression-tested on aarch64-linux-gnu.  I'll push on
> >> Monday if there are no comments before then.  I'd appreciate a second
> >> pair of eyes though, since this is a sensitive area.
> >
> > Do you happen to know if the backports to older branches you provided for
> > the change that triggered this issue (in particular to GCC 7) are also 
> > affected?
>
> GCC 7 and GCC 8 should be ok.  The bug relies on stack protection being
> enabled (-fstack-protector-strong for the testcase in the PR, but just
> -fstack-protector for others) and that was added in GCC 9.

Hmm, I see -fstack-protector[-strong] working with GCC 7 on aarch64.
Specifically
the testcase produces for foo():

.text
.align  2
.global _Z3foov
.type   _Z3foov, %function
_Z3foov:
.LFB0:
.cfi_startproc
stp x29, x30, [sp, -16]!
.cfi_def_cfa_offset 16
.cfi_offset 29, -16
.cfi_offset 30, -8
add x29, sp, 0
.cfi_def_cfa_register 29
sub sp, sp, #16
sub sp, sp, #524288
adrpx0, __stack_chk_guard
add x0, x0, :lo12:__stack_chk_guard
ldr x1, [x0]
str x1, [x29, -8]
mov x1,0
adrpx0, ptr
add x0, x0, :lo12:ptr
sub x1, x29, #524288
sub x1, x1, #8
str x1, [x0]
mov x0, 4
bl  __cxa_allocate_exception
mov x3, x0
mov w0, 1
str w0, [x3]
adrpx0, _ZTIi
add x0, x0, :lo12:_ZTIi
mov x2, 0
mov x1, x0
mov x0, x3
bl  __cxa_throw
.cfi_endproc
.LFE0:
.size   _Z3foov, .-_Z3foov


> > The testcase from the PR does not fail in the reported way for me, but I 
> > guess
> > that very much depends on "details".
>
> Oh, even on trunk?  Does adding:
>
>   volatile int unused[N] = {};
>
> to main for various N change things?

I didn't try on trunk.

Richard.

>
> Thanks,
> Richard

Re: [PATCH] cobol: Initialize regmatch_t portably [PR119217]

[Jakub Jelinek]

On Fri, Apr 11, 2025 at 10:50:25AM +0200, Rainer Orth wrote:
> 2025-04-08  Rainer Orth  
> 
>   gcc/cobol:
>   PR cobol/119217
>   * dts.h (csub_match): Initialize rm_so, rm_eo fields explicitly.
> 

> # HG changeset patch
> # Parent  6f227ddea0046a0164509bdb8069e96184304054
> cobol: Initialize regmatch_t portably [PR119217]
> 
> diff --git a/gcc/cobol/dts.h b/gcc/cobol/dts.h
> --- a/gcc/cobol/dts.h
> +++ b/gcc/cobol/dts.h
> @@ -33,7 +33,8 @@ namespace dts {
>: input(input)
>, first(NULL), second(NULL), matched(false)
>  {
> -  static regmatch_t empty = { -1, -1 };
> +  static regmatch_t empty;
> +  empty.rm_so = empty.rm_eo = -1;

Why not static regmatch_t empty = { .rm_so = -1, .rm_eo = -1 };
?
While the FE needs to be valid C++14, the library is GNU++17 (compiled
by the just built GCC and not built with -pedantic*, so can use GCC
extensions or features from C++20 that are known to be implemented there).

Ah, I see dts.h include from the FE.  So that would need to be
#ifndef IN_GCC_FRONTEND
  static const regmatch_t empty = { .rm_so = -1, .rm_eo = -1 };
#else
  regmatch_t empty = {};
  empty.rm_so = empty.rm_eo = -1;
#endif
I don't see the point of makint it static if it needs to be modified
at runtime.
Though, maybe one would get better code generation even without
the static keyword in the first case.

>regmatch_t& self(*this);
>self = empty;
>  }


Jakub

Re: [PATCH] cobol: Avoid conflict with timespec_t in system headers [PR119217]

[Richard Biener]

On Fri, Apr 11, 2025 at 11:11 AM Rainer Orth
 wrote:
>
> util.cc doesn't compile on Solaris:
>
> /vol/gcc/src/hg/master/local/gcc/cobol/util.cc:2135:7: error: using 
> typedef-name ‘timespec_t’ after ‘class’
>  2135 | class timespec_t {
>   |   ^~
>
> This happens because  declares timespec_t itself.  In fact,
> POSIX.1 reserves every *_t identifier, so this is benign.
>
> To avoid the problem, this patch renames the cobol timespec_t to
> cbl_timespec.
>
> Bootstrapped without regressions on amd64-pc-solaris2.11,
> sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.
>
> Ok for trunk?

OK.

Richard.

>
> Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>
> 2025-04-08  Rainer Orth  
>
> gcc/cobol:
> PR cobol/119217
> * util.cc (class timespec_t): Rename to cbl_timespec.
>

RE: [PATCH v2] libstdc++: Implement C++26 features (P2546R5)

[Maciej Cencora]

Hi,

unless I missed it, updates of std and std.compat modules are missing.

Regards,
Maciej

Re: [PATCH v2] libstdc++: Implement C++26 features (P2546R5)

[Jonathan Wakely]

On Fri, 11 Apr 2025 at 10:31, Tomasz Kaminski  wrote:
>
>
>
> On Fri, Apr 11, 2025 at 10:13 AM Jonathan Wakely  wrote:
>>
>> On Fri, 11 Apr 2025 at 08:00, Tomasz Kaminski  wrote:
>> >
>> >
>> >
>> > On Thu, Apr 10, 2025 at 6:53 PM Jonathan Wakely  wrote:
>> >>
>> >> It would be good to provide a macOS definition of is_debugger_present as
>> >> per https://developer.apple.com/library/archive/qa/qa1361/_index.html
>> >> but that isn't included in this change.
>> >>
>> >> libstdc++-v3/ChangeLog:
>> >>
>> >> * config.h.in: Regenerate.
>> >> * configure: Regenerate.
>> >> * configure.ac: Check for facilities needed by .
>> >> * include/Makefile.am: Add new header.
>> >> * include/Makefile.in: Regenerate.
>> >> * include/bits/version.def (debugging): Add.
>> >> * include/bits/version.h: Regenerate.
>> >> * src/c++26/Makefile.am: Add new file.
>> >> * src/c++26/Makefile.in: Regenerate.
>> >> * include/std/debugging: New file.
>> >> * src/c++26/debugging.cc: New file.
>> >> * testsuite/19_diagnostics/debugging/breakpoint.cc: New test.
>> >> * testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc:
>> >> New test.
>> >> * testsuite/19_diagnostics/debugging/is_debugger_present.cc: New
>> >> test.
>> >> ---
>> >>
>> >> I sent v1 of this patch in June last year:
>> >> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653293.html
>> >> My comments about testing with GDB still apply.
>> >>
>> >> Compared to v1, this adds a void __gnu_cxx::attach_debugger(bool)
>> >> function that could be called by debuggers to announce that they are
>> >> attaching and detaching. It also adds a systemtap probe point to
>> >> std::breakpoint().
>> >>
>> >> Tested x86_64-linux.
>> >>
>> >> N.B. this only adds new symbols to the libstdc++exp.a archive, not to
>> >> libstdc++.so so it's not a risky change at this stage.
>> >>
>> >>  libstdc++-v3/config.h.in  |   9 +
>> >>  libstdc++-v3/configure|  22 +++
>> >>  libstdc++-v3/configure.ac |   9 +
>> >>  libstdc++-v3/include/Makefile.am  |   1 +
>> >>  libstdc++-v3/include/Makefile.in  |   1 +
>> >>  libstdc++-v3/include/bits/version.def |   8 +
>> >>  libstdc++-v3/include/bits/version.h   |  10 ++
>> >>  libstdc++-v3/include/std/debugging|  77 
>> >>  libstdc++-v3/src/c++26/Makefile.am|   4 +-
>> >>  libstdc++-v3/src/c++26/Makefile.in|   7 +-
>> >>  libstdc++-v3/src/c++26/debugging.cc   | 165 ++
>> >>  .../19_diagnostics/debugging/breakpoint.cc|  13 ++
>> >>  .../debugging/breakpoint_if_debugging.cc  |  13 ++
>> >>  .../debugging/is_debugger_present.cc  |  14 ++
>> >>  14 files changed, 350 insertions(+), 3 deletions(-)
>> >>  create mode 100644 libstdc++-v3/include/std/debugging
>> >>  create mode 100644 libstdc++-v3/src/c++26/debugging.cc
>> >>  create mode 100644 
>> >> libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint.cc
>> >>  create mode 100644 
>> >> libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc
>> >>  create mode 100644 
>> >> libstdc++-v3/testsuite/19_diagnostics/debugging/is_debugger_present.cc
>> >>
>> >> diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
>> >> index 77bbaf1beaa..3f1331ff36f 100644
>> >> --- a/libstdc++-v3/config.h.in
>> >> +++ b/libstdc++-v3/config.h.in
>> >> @@ -70,6 +70,9 @@
>> >>  /* Define to 1 if you have the `cosl' function. */
>> >>  #undef HAVE_COSL
>> >>
>> >> +/* Define to 1 if you have the  header file. */
>> >> +#undef HAVE_DEBUGAPI_H
>> >> +
>> >>  /* Define to 1 if you have the declaration of `strnlen', and to 0 if you
>> >> don't. */
>> >>  #undef HAVE_DECL_STRNLEN
>> >> @@ -439,6 +442,9 @@
>> >>  /* Define to 1 if you have the  header file. */
>> >>  #undef HAVE_SYS_PARAM_H
>> >>
>> >> +/* Define to 1 if you have the  header file. */
>> >> +#undef HAVE_SYS_PTRACE_H
>> >> +
>> >>  /* Define to 1 if you have the  header file. */
>> >>  #undef HAVE_SYS_RESOURCE_H
>> >>
>> >> @@ -850,6 +856,9 @@
>> >>  /* Define if nl_langinfo_l should be used for std::text_encoding. */
>> >>  #undef _GLIBCXX_USE_NL_LANGINFO_L
>> >>
>> >> +/* Define if /proc/self/status should be used for . */
>> >> +#undef _GLIBCXX_USE_PROC_SELF_STATUS
>> >> +
>> >>  /* Define if pthreads_num_processors_np is available in . */
>> >>  #undef _GLIBCXX_USE_PTHREADS_NUM_PROCESSORS_NP
>> >>
>> >> diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
>> >> index 819a1d82876..8143df91c38 100755
>> >> --- a/libstdc++-v3/configure
>> >> +++ b/libstdc++-v3/configure
>> >> @@ -54700,6 +54700,28 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
>> >>
>> >>
>> >>
>> >> +# For std::is_debugger_present
>> >> +case "$target_os" in
>> >> +  linux*)
>> >> +
>> >> +$as_echo "#define _GLIBCXX_USE_PROC_SELF_STATUS 1" >>confdefs.h
>>

Re: [PATCH v2] libstdc++: Implement C++26 features (P2546R5)

[Jonathan Wakely]

On Thu, 10 Apr 2025 at 17:52, Jonathan Wakely  wrote:
>
> It would be good to provide a macOS definition of is_debugger_present as
> per https://developer.apple.com/library/archive/qa/qa1361/_index.html
> but that isn't included in this change.
>
> libstdc++-v3/ChangeLog:
>
> * config.h.in: Regenerate.
> * configure: Regenerate.
> * configure.ac: Check for facilities needed by .
> * include/Makefile.am: Add new header.
> * include/Makefile.in: Regenerate.
> * include/bits/version.def (debugging): Add.
> * include/bits/version.h: Regenerate.
> * src/c++26/Makefile.am: Add new file.
> * src/c++26/Makefile.in: Regenerate.
> * include/std/debugging: New file.
> * src/c++26/debugging.cc: New file.
> * testsuite/19_diagnostics/debugging/breakpoint.cc: New test.
> * testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc:
> New test.
> * testsuite/19_diagnostics/debugging/is_debugger_present.cc: New
> test.
> ---
>
> I sent v1 of this patch in June last year:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653293.html
> My comments about testing with GDB still apply.
>
> Compared to v1, this adds a void __gnu_cxx::attach_debugger(bool)
> function that could be called by debuggers to announce that they are
> attaching and detaching. It also adds a systemtap probe point to
> std::breakpoint().
>
> Tested x86_64-linux.
>
> N.B. this only adds new symbols to the libstdc++exp.a archive, not to
> libstdc++.so so it's not a risky change at this stage.
>
>  libstdc++-v3/config.h.in  |   9 +
>  libstdc++-v3/configure|  22 +++
>  libstdc++-v3/configure.ac |   9 +
>  libstdc++-v3/include/Makefile.am  |   1 +
>  libstdc++-v3/include/Makefile.in  |   1 +
>  libstdc++-v3/include/bits/version.def |   8 +
>  libstdc++-v3/include/bits/version.h   |  10 ++
>  libstdc++-v3/include/std/debugging|  77 
>  libstdc++-v3/src/c++26/Makefile.am|   4 +-
>  libstdc++-v3/src/c++26/Makefile.in|   7 +-
>  libstdc++-v3/src/c++26/debugging.cc   | 165 ++
>  .../19_diagnostics/debugging/breakpoint.cc|  13 ++
>  .../debugging/breakpoint_if_debugging.cc  |  13 ++
>  .../debugging/is_debugger_present.cc  |  14 ++
>  14 files changed, 350 insertions(+), 3 deletions(-)
>  create mode 100644 libstdc++-v3/include/std/debugging
>  create mode 100644 libstdc++-v3/src/c++26/debugging.cc
>  create mode 100644 
> libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint.cc
>  create mode 100644 
> libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc
>  create mode 100644 
> libstdc++-v3/testsuite/19_diagnostics/debugging/is_debugger_present.cc
>
> diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
> index 77bbaf1beaa..3f1331ff36f 100644
> --- a/libstdc++-v3/config.h.in
> +++ b/libstdc++-v3/config.h.in
> @@ -70,6 +70,9 @@
>  /* Define to 1 if you have the `cosl' function. */
>  #undef HAVE_COSL
>
> +/* Define to 1 if you have the  header file. */
> +#undef HAVE_DEBUGAPI_H
> +
>  /* Define to 1 if you have the declaration of `strnlen', and to 0 if you
> don't. */
>  #undef HAVE_DECL_STRNLEN
> @@ -439,6 +442,9 @@
>  /* Define to 1 if you have the  header file. */
>  #undef HAVE_SYS_PARAM_H
>
> +/* Define to 1 if you have the  header file. */
> +#undef HAVE_SYS_PTRACE_H
> +
>  /* Define to 1 if you have the  header file. */
>  #undef HAVE_SYS_RESOURCE_H
>
> @@ -850,6 +856,9 @@
>  /* Define if nl_langinfo_l should be used for std::text_encoding. */
>  #undef _GLIBCXX_USE_NL_LANGINFO_L
>
> +/* Define if /proc/self/status should be used for . */
> +#undef _GLIBCXX_USE_PROC_SELF_STATUS
> +
>  /* Define if pthreads_num_processors_np is available in . */
>  #undef _GLIBCXX_USE_PTHREADS_NUM_PROCESSORS_NP
>
> diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
> index 819a1d82876..8143df91c38 100755
> --- a/libstdc++-v3/configure
> +++ b/libstdc++-v3/configure
> @@ -54700,6 +54700,28 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
>
>
>
> +# For std::is_debugger_present
> +case "$target_os" in
> +  linux*)
> +
> +$as_echo "#define _GLIBCXX_USE_PROC_SELF_STATUS 1" >>confdefs.h
> +
> +;;
> +esac
> +for ac_header in sys/ptrace.h debugapi.h
> +do :
> +  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
> +ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" 
> "$ac_includes_default"
> +if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
> +  cat >>confdefs.h <<_ACEOF
> +#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
> +_ACEOF
> +
> +fi
> +
> +done
> +
> +
>  # Define documentation rules conditionally.
>
>  # See if makeinfo has been installed and is modern enough
> diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
> index a6c01b29e94..83adb46454e 100644
> --

Re: [PATCH] aarch64: Fix CFA offsets in non-initial stack probes [PR119610]

[Richard Sandiford]

Richard Biener  writes:
> On Fri, Apr 11, 2025 at 11:10 AM Richard Sandiford
>  wrote:
>>
>> Richard Biener  writes:
>> > On Thu, Apr 10, 2025 at 10:10 PM Richard Sandiford
>> >  wrote:
>> >>
>> >> PR119610 is about incorrect CFI output for a stack probe when that
>> >> probe is not the initial allocation.  The main aarch64 stack probe
>> >> function, aarch64_allocate_and_probe_stack_space, implicitly assumed
>> >> that the incoming stack pointer pointed to the top of the frame,
>> >> and thus held the CFA.
>> >>
>> >> aarch64_save_callee_saves and aarch64_restore_callee_saves use a
>> >> parameter called bytes_below_sp to track how far the stack pointer
>> >> is above the base of the static frame.  This patch does the same
>> >> thing for aarch64_allocate_and_probe_stack_space.
>> >>
>> >> Also, I noticed that the SVE path was attaching the first CFA note
>> >> to the wrong instruction: it was attaching the note to the calculation
>> >> of the stack size, rather than to the r11<-sp copy.
>> >>
>> >> Bootstrapped & regression-tested on aarch64-linux-gnu.  I'll push on
>> >> Monday if there are no comments before then.  I'd appreciate a second
>> >> pair of eyes though, since this is a sensitive area.
>> >
>> > Do you happen to know if the backports to older branches you provided for
>> > the change that triggered this issue (in particular to GCC 7) are also 
>> > affected?
>>
>> GCC 7 and GCC 8 should be ok.  The bug relies on stack protection being
>> enabled (-fstack-protector-strong for the testcase in the PR, but just
>> -fstack-protector for others) and that was added in GCC 9.
>
> Hmm, I see -fstack-protector[-strong] working with GCC 7 on aarch64.

I think it's just being silently accepted as a nop.  At least:

> Specifically
> the testcase produces for foo():
>
> .text
> .align  2
> .global _Z3foov
> .type   _Z3foov, %function
> _Z3foov:
> .LFB0:
> .cfi_startproc
> stp x29, x30, [sp, -16]!
> .cfi_def_cfa_offset 16
> .cfi_offset 29, -16
> .cfi_offset 30, -8
> add x29, sp, 0
> .cfi_def_cfa_register 29
> sub sp, sp, #16
> sub sp, sp, #524288

...the function isn't probing the stack here.  It ought to be doing
something like the code that Alex quoted in the PR.  Compare the
GCC 8 and GCC 9 output in https://godbolt.org/z/cWbsG3eGb .

Thanks,
Richard

> adrpx0, __stack_chk_guard
> add x0, x0, :lo12:__stack_chk_guard
> ldr x1, [x0]
> str x1, [x29, -8]
> mov x1,0
> adrpx0, ptr
> add x0, x0, :lo12:ptr
> sub x1, x29, #524288
> sub x1, x1, #8
> str x1, [x0]
> mov x0, 4
> bl  __cxa_allocate_exception
> mov x3, x0
> mov w0, 1
> str w0, [x3]
> adrpx0, _ZTIi
> add x0, x0, :lo12:_ZTIi
> mov x2, 0
> mov x1, x0
> mov x0, x3
> bl  __cxa_throw
> .cfi_endproc
> .LFE0:
> .size   _Z3foov, .-_Z3foov

Re: [PATCH] aarch64: Fix CFA offsets in non-initial stack probes [PR119610]

[Richard Biener]

On Fri, Apr 11, 2025 at 12:18 PM Richard Sandiford
 wrote:
>
> Richard Biener  writes:
> > On Fri, Apr 11, 2025 at 11:10 AM Richard Sandiford
> >  wrote:
> >>
> >> Richard Biener  writes:
> >> > On Thu, Apr 10, 2025 at 10:10 PM Richard Sandiford
> >> >  wrote:
> >> >>
> >> >> PR119610 is about incorrect CFI output for a stack probe when that
> >> >> probe is not the initial allocation.  The main aarch64 stack probe
> >> >> function, aarch64_allocate_and_probe_stack_space, implicitly assumed
> >> >> that the incoming stack pointer pointed to the top of the frame,
> >> >> and thus held the CFA.
> >> >>
> >> >> aarch64_save_callee_saves and aarch64_restore_callee_saves use a
> >> >> parameter called bytes_below_sp to track how far the stack pointer
> >> >> is above the base of the static frame.  This patch does the same
> >> >> thing for aarch64_allocate_and_probe_stack_space.
> >> >>
> >> >> Also, I noticed that the SVE path was attaching the first CFA note
> >> >> to the wrong instruction: it was attaching the note to the calculation
> >> >> of the stack size, rather than to the r11<-sp copy.
> >> >>
> >> >> Bootstrapped & regression-tested on aarch64-linux-gnu.  I'll push on
> >> >> Monday if there are no comments before then.  I'd appreciate a second
> >> >> pair of eyes though, since this is a sensitive area.
> >> >
> >> > Do you happen to know if the backports to older branches you provided for
> >> > the change that triggered this issue (in particular to GCC 7) are also 
> >> > affected?
> >>
> >> GCC 7 and GCC 8 should be ok.  The bug relies on stack protection being
> >> enabled (-fstack-protector-strong for the testcase in the PR, but just
> >> -fstack-protector for others) and that was added in GCC 9.
> >
> > Hmm, I see -fstack-protector[-strong] working with GCC 7 on aarch64.
>
> I think it's just being silently accepted as a nop.  At least:
>
> > Specifically
> > the testcase produces for foo():
> >
> > .text
> > .align  2
> > .global _Z3foov
> > .type   _Z3foov, %function
> > _Z3foov:
> > .LFB0:
> > .cfi_startproc
> > stp x29, x30, [sp, -16]!
> > .cfi_def_cfa_offset 16
> > .cfi_offset 29, -16
> > .cfi_offset 30, -8
> > add x29, sp, 0
> > .cfi_def_cfa_register 29
> > sub sp, sp, #16
> > sub sp, sp, #524288
>
> ...the function isn't probing the stack here.  It ought to be doing
> something like the code that Alex quoted in the PR.  Compare the
> GCC 8 and GCC 9 output in https://godbolt.org/z/cWbsG3eGb .

Yes, I thought that's the -fstack-clash-protection support being sub-par
(not enforced for VLA allocations).  So I wrongly assumed this is
about -fstack-protector (the __stack_chk_guard thing?)

> Thanks,
> Richard
>
> > adrpx0, __stack_chk_guard
> > add x0, x0, :lo12:__stack_chk_guard
> > ldr x1, [x0]
> > str x1, [x29, -8]
> > mov x1,0
> > adrpx0, ptr
> > add x0, x0, :lo12:ptr
> > sub x1, x29, #524288
> > sub x1, x1, #8
> > str x1, [x0]
> > mov x0, 4
> > bl  __cxa_allocate_exception
> > mov x3, x0
> > mov w0, 1
> > str w0, [x3]
> > adrpx0, _ZTIi
> > add x0, x0, :lo12:_ZTIi
> > mov x2, 0
> > mov x1, x0
> > mov x0, x3
> > bl  __cxa_throw
> > .cfi_endproc
> > .LFE0:
> > .size   _Z3foov, .-_Z3foov

Re: [PATCH] aarch64: Fix CFA offsets in non-initial stack probes [PR119610]

[Richard Sandiford]

Richard Sandiford  writes:
> Richard Biener  writes:
>> On Fri, Apr 11, 2025 at 11:10 AM Richard Sandiford
>>  wrote:
>>>
>>> Richard Biener  writes:
>>> > On Thu, Apr 10, 2025 at 10:10 PM Richard Sandiford
>>> >  wrote:
>>> >>
>>> >> PR119610 is about incorrect CFI output for a stack probe when that
>>> >> probe is not the initial allocation.  The main aarch64 stack probe
>>> >> function, aarch64_allocate_and_probe_stack_space, implicitly assumed
>>> >> that the incoming stack pointer pointed to the top of the frame,
>>> >> and thus held the CFA.
>>> >>
>>> >> aarch64_save_callee_saves and aarch64_restore_callee_saves use a
>>> >> parameter called bytes_below_sp to track how far the stack pointer
>>> >> is above the base of the static frame.  This patch does the same
>>> >> thing for aarch64_allocate_and_probe_stack_space.
>>> >>
>>> >> Also, I noticed that the SVE path was attaching the first CFA note
>>> >> to the wrong instruction: it was attaching the note to the calculation
>>> >> of the stack size, rather than to the r11<-sp copy.
>>> >>
>>> >> Bootstrapped & regression-tested on aarch64-linux-gnu.  I'll push on
>>> >> Monday if there are no comments before then.  I'd appreciate a second
>>> >> pair of eyes though, since this is a sensitive area.
>>> >
>>> > Do you happen to know if the backports to older branches you provided for
>>> > the change that triggered this issue (in particular to GCC 7) are also 
>>> > affected?
>>>
>>> GCC 7 and GCC 8 should be ok.  The bug relies on stack protection being
>>> enabled (-fstack-protector-strong for the testcase in the PR, but just
>>> -fstack-protector for others) and that was added in GCC 9.
>>
>> Hmm, I see -fstack-protector[-strong] working with GCC 7 on aarch64.
>
> I think it's just being silently accepted as a nop.  At least:
>
>> Specifically
>> the testcase produces for foo():
>>
>> .text
>> .align  2
>> .global _Z3foov
>> .type   _Z3foov, %function
>> _Z3foov:
>> .LFB0:
>> .cfi_startproc
>> stp x29, x30, [sp, -16]!
>> .cfi_def_cfa_offset 16
>> .cfi_offset 29, -16
>> .cfi_offset 30, -8
>> add x29, sp, 0
>> .cfi_def_cfa_register 29
>> sub sp, sp, #16
>> sub sp, sp, #524288
>
> ...the function isn't probing the stack here.  It ought to be doing
> something like the code that Alex quoted in the PR.  Compare the
> GCC 8 and GCC 9 output in https://godbolt.org/z/cWbsG3eGb .

Gah, Alex pointed out off-list that I'd once again got the options
the wrong way around: -fstack-clash-protection is the thing that
was added in GCC 9.

I find these option names really confusing :-(

Richard

[PATCH] libgomp: Update SVE test

[Tejas Belagod]

Fix udr-sve.c target test that to check for the correct results based on the
OpenMP clauses used.  The test was first written with a misunderstood
functionality of the reduction clause.

Tested with aarch64-linux-gnu. OK for trunk?

libgomp/ChangeLog:

* testsuite/libgomp.c-target/aarch64/udr-sve.c: Fix test.
---
 .../libgomp.c-target/aarch64/udr-sve.c| 58 +++
 1 file changed, 47 insertions(+), 11 deletions(-)

diff --git a/libgomp/testsuite/libgomp.c-target/aarch64/udr-sve.c 
b/libgomp/testsuite/libgomp.c-target/aarch64/udr-sve.c
index 03d93cc44b2..02e02dc04b6 100644
--- a/libgomp/testsuite/libgomp.c-target/aarch64/udr-sve.c
+++ b/libgomp/testsuite/libgomp.c-target/aarch64/udr-sve.c
@@ -9,8 +9,8 @@
 void __attribute__ ((noipa))
 parallel_reduction ()
 {
-  int a[8] = {1 ,1, 1, 1, 1, 1, 1, 1};
-  int b[8] = {0 ,0, 0, 0, 0, 0, 0, 0};
+  int a[8] = {1, 1, 1, 1, 1, 1, 1, 1};
+  int b[8] = {0, 0, 0, 0, 0, 0, 0, 0};
   svint32_t va = svld1_s32 (svptrue_b32 (), b);
   int i = 0;
   int64_t res;
@@ -30,8 +30,8 @@ parallel_reduction ()
 void __attribute__ ((noipa))
 for_reduction ()
 {
-  int a[8] = {1 ,1, 1, 1, 1, 1, 1, 1};
-  int b[8] = {0 ,0, 0, 0, 0, 0, 0, 0};
+  int a[8] = {1, 1, 1, 1, 1, 1, 1, 1};
+  int b[8] = {0, 0, 0, 0, 0, 0, 0, 0};
   svint32_t va = svld1_s32 (svptrue_b32 (), b);
   int j;
   int64_t res;
@@ -58,13 +58,13 @@ simd_reduction ()
   for (j = 0; j < 8; j++)
 a[j] = 1;
 
-  #pragma omp simd reduction (+:va, i)
+  #pragma omp simd reduction (+:va)
   for (j = 0; j < 16; j++)
-va = svld1_s32 (svptrue_b32 (), a);
+va += svld1_s32 (svptrue_b32 (), a);
 
   res = svaddv_s32 (svptrue_b32 (), va);
 
-  if (res != 8)
+  if (res != 128)
 __builtin_abort ();
 }
 
@@ -72,22 +72,57 @@ void __attribute__ ((noipa))
 inscan_reduction_incl ()
 {
   svint32_t va = svindex_s32 (0, 0);
+  int a[8] = {1, 1, 1, 1, 1, 1, 1, 1};
+  int b[64] = { 0 };
   int j;
   int64_t res = 0;
 
-  #pragma omp parallel
-  #pragma omp for reduction (inscan,+:va) firstprivate (res) lastprivate (res)
+  #pragma omp parallel for reduction (inscan, +:va)
   for (j = 0; j < 8; j++)
 {
-  va = svindex_s32 (1, 0);
+  va += svld1_s32 (svptrue_b32 (), a);
   #pragma omp scan inclusive (va)
-  res += svaddv_s32 (svptrue_b32 (), va);
+  svst1_s32 (svptrue_b32 (), b + j * 8, va);
+}
+
+  res = svaddv_s32 (svptrue_b32 (), va);
+
+  if (res != 64)
+__builtin_abort ();
+
+  for (j = 0; j < 64; j+=8)
+if (b[j] != (j / 8 + 1))
+  __builtin_abort ();
+}
+
+void __attribute__ ((noipa))
+inscan_reduction_excl ()
+{
+  svint32_t va = svindex_s32 (0, 0);
+  int a[8] = {1, 1, 1, 1, 1, 1, 1, 1};
+  int b[64] = { 0 };
+  int j;
+  int64_t res = 0;
+
+  #pragma omp parallel for reduction (inscan, +:va)
+  for (j = 0; j < 8; j++)
+{
+  svst1_s32 (svptrue_b32 (), b + j * 8, va);
+  #pragma omp scan exclusive (va)
+  va += svld1_s32 (svptrue_b32 (), a);
 }
 
+  res = svaddv_s32 (svptrue_b32 (), va);
+
   if (res != 64)
 __builtin_abort ();
+
+  for (j = 0; j < 64; j+=8)
+if (b[j] != j / 8)
+  __builtin_abort ();
 }
 
+
 int
 main ()
 {
@@ -95,4 +130,5 @@ main ()
   for_reduction ();
   simd_reduction ();
   inscan_reduction_incl ();
+  inscan_reduction_excl ();
 }
-- 
2.25.1

Re: [PATCH v2] testcase: Add testcase for shrink wrapping of vector::push_back [PR118502]

[Richard Sandiford]

Andrew Pinski  writes:
> On Sun, Mar 9, 2025 at 1:35 PM Andrew Pinski  wrote:
>>
>> LLVM folks noticed that GCC was shrink wrapping the call to 
>> vector::push_back.
>> So I thought it was a good idea to commit a testcase to make sure GCC does 
>> not regress
>> in this area unknowning.
>>
>> Note the shrink wrapping started with r15-1619-g3b9b8d6cfdf593.
>> Note this enables the testcase for x86_64 (!ia32), powerpc, aarch64 and 
>> riscv which I tested
>> via godbolt to see the shrink wrapping occurs. Also tested the testcase for 
>> both
>> x86_64-linux-gnu and aarch64-linux-gnu to make sure I got the target selects 
>> correct.
>
> Ping?

OK, thanks.

Richard

>
>>
>> Changes since v1:
>> * v2: Fix some comments typos that was mentioned in the bug report.
>>
>> PR rtl-optimization/118502
>>
>> gcc/testsuite/ChangeLog:
>>
>> * g++.dg/opt/shrink-wrapping-vector-1.C: New test.
>>
>> Signed-off-by: Andrew Pinski 
>> ---
>>  .../g++.dg/opt/shrink-wrapping-vector-1.C   | 17 +
>>  1 file changed, 17 insertions(+)
>>  create mode 100644 gcc/testsuite/g++.dg/opt/shrink-wrapping-vector-1.C
>>
>> diff --git a/gcc/testsuite/g++.dg/opt/shrink-wrapping-vector-1.C 
>> b/gcc/testsuite/g++.dg/opt/shrink-wrapping-vector-1.C
>> new file mode 100644
>> index 000..8b1ad53fa80
>> --- /dev/null
>> +++ b/gcc/testsuite/g++.dg/opt/shrink-wrapping-vector-1.C
>> @@ -0,0 +1,17 @@
>> +// { dg-do compile { target { { { i?86-*-* x86_64-*-* } && { ! ia32 } } || 
>> { powerpc*-*-* aarch64*-*-* riscv*-*-* }  } } }
>> +// { dg-options "-O2  -fdump-rtl-pro_and_epilogue"  }
>> +// { dg-skip-if "requires hosted libstdc++ for vector" { ! hostedlib } }
>> +
>> +// PR rtl-optimization/118502
>> +
>> +// The shrink-wrapping should happen around the slow path of 
>> vector::push_back,
>> +// The fast path is just checking if there is enough space and doing a few 
>> stores.
>> +// We want to verify that shrink wrapping always happens.
>> +
>> +#include 
>> +
>> +void push_back(std::vector& xs, unsigned char x) {
>> +xs.push_back(x);
>> +}
>> +
>> +/* { dg-final { scan-rtl-dump "Performing shrink-wrapping" 
>> "pro_and_epilogue" } } */
>> --
>> 2.43.0
>>

Re: [PATCH] aarch64: Fix CFA offsets in non-initial stack probes [PR119610]

[Richard Biener]

On Fri, Apr 11, 2025 at 12:26 PM Richard Sandiford
 wrote:
>
> Richard Sandiford  writes:
> > Richard Biener  writes:
> >> On Fri, Apr 11, 2025 at 11:10 AM Richard Sandiford
> >>  wrote:
> >>>
> >>> Richard Biener  writes:
> >>> > On Thu, Apr 10, 2025 at 10:10 PM Richard Sandiford
> >>> >  wrote:
> >>> >>
> >>> >> PR119610 is about incorrect CFI output for a stack probe when that
> >>> >> probe is not the initial allocation.  The main aarch64 stack probe
> >>> >> function, aarch64_allocate_and_probe_stack_space, implicitly assumed
> >>> >> that the incoming stack pointer pointed to the top of the frame,
> >>> >> and thus held the CFA.
> >>> >>
> >>> >> aarch64_save_callee_saves and aarch64_restore_callee_saves use a
> >>> >> parameter called bytes_below_sp to track how far the stack pointer
> >>> >> is above the base of the static frame.  This patch does the same
> >>> >> thing for aarch64_allocate_and_probe_stack_space.
> >>> >>
> >>> >> Also, I noticed that the SVE path was attaching the first CFA note
> >>> >> to the wrong instruction: it was attaching the note to the calculation
> >>> >> of the stack size, rather than to the r11<-sp copy.
> >>> >>
> >>> >> Bootstrapped & regression-tested on aarch64-linux-gnu.  I'll push on
> >>> >> Monday if there are no comments before then.  I'd appreciate a second
> >>> >> pair of eyes though, since this is a sensitive area.
> >>> >
> >>> > Do you happen to know if the backports to older branches you provided 
> >>> > for
> >>> > the change that triggered this issue (in particular to GCC 7) are also 
> >>> > affected?
> >>>
> >>> GCC 7 and GCC 8 should be ok.  The bug relies on stack protection being
> >>> enabled (-fstack-protector-strong for the testcase in the PR, but just
> >>> -fstack-protector for others) and that was added in GCC 9.
> >>
> >> Hmm, I see -fstack-protector[-strong] working with GCC 7 on aarch64.
> >
> > I think it's just being silently accepted as a nop.  At least:
> >
> >> Specifically
> >> the testcase produces for foo():
> >>
> >> .text
> >> .align  2
> >> .global _Z3foov
> >> .type   _Z3foov, %function
> >> _Z3foov:
> >> .LFB0:
> >> .cfi_startproc
> >> stp x29, x30, [sp, -16]!
> >> .cfi_def_cfa_offset 16
> >> .cfi_offset 29, -16
> >> .cfi_offset 30, -8
> >> add x29, sp, 0
> >> .cfi_def_cfa_register 29
> >> sub sp, sp, #16
> >> sub sp, sp, #524288
> >
> > ...the function isn't probing the stack here.  It ought to be doing
> > something like the code that Alex quoted in the PR.  Compare the
> > GCC 8 and GCC 9 output in https://godbolt.org/z/cWbsG3eGb .
>
> Gah, Alex pointed out off-list that I'd once again got the options
> the wrong way around: -fstack-clash-protection is the thing that
> was added in GCC 9.
>
> I find these option names really confusing :-(

True.  Note we backported rough -fstack-clash-protection to GCC 7,
but middle-end only (attached for reference).

Richard.

>
> Richard
Index: gcc/common.opt
===
--- gcc/common.opt	(revision 244266)
+++ gcc/common.opt	(working copy)
@@ -2295,6 +2299,10 @@ fstack-check
 Common Alias(fstack-check=, specific, no)
 Insert stack checking code into the program.  Same as -fstack-check=specific.
 
+fstack-clash-protection
+Common Report Var(flag_stack_clash_protection)
+Insert probes per page for dynamically allocated stack space
+
 fstack-limit
 Common Var(common_deferred_options) Defer
 
Index: gcc/explow.c
===
--- gcc/explow.c	(revision 244266)
+++ gcc/explow.c	(working copy)
@@ -1277,6 +1277,8 @@ get_dynamic_stack_size (rtx *psize, unsi
   *psize = size;
 }
 
+#define PROBE_INTERVAL (1 << STACK_CHECK_PROBE_INTERVAL_EXP)
+
 /* Return an rtx representing the address of an area of memory dynamically
pushed on the stack.
 
@@ -1305,6 +1307,8 @@ allocate_dynamic_stack_space (rtx size,
   HOST_WIDE_INT stack_usage_size = -1;
   rtx_code_label *final_label;
   rtx final_target, target;
+  rtx loop_lab, end_lab, skip_lab, last_size, before_skip;
+  int probe_pass = 0;
 
   /* If we're asking for zero bytes, it doesn't matter what we point
  to since we can't dereference it.  But return a reasonable
@@ -1440,6 +1444,30 @@ allocate_dynamic_stack_space (rtx size,
   /* Don't let anti_adjust_stack emit notes.  */
   suppress_reg_args_size = true;
 
+  if (flag_stack_clash_protection)
+{
+#ifndef STACK_GROWS_DOWNWARD
+  sorry("-fstack-clash-protection is incompatible with upward growing stack");
+#endif
+  size = copy_to_mode_reg (Pmode, convert_to_mode (Pmode, size, 1));
+  loop_lab = gen_label_rtx ();
+  end_lab = gen_label_rtx ();
+  skip_lab = gen_label_rtx ();
+  /* We insert 'target = virtual_stack_dynamic_rtx' here, but target
+	 is changed later, so that insn can be constructed only later.  */
+  before_skip = 

Re: [PATCH] libstdc++: Use constexpr-if for std::basic_string::_S_copy_chars

[Jonathan Wakely]

On 11/04/25 09:49 +0200, Tomasz Kaminski wrote:

On Thu, Apr 10, 2025 at 6:29 PM Jonathan Wakely  wrote:


For C++11 and later we can remvoe four overloads of _S_copy_chars and
use constexpr-if in the generic _S_copy_chars. This simplifies overload
resolution for _S_copy_chars, and also means that we optimize for other
iterators such as std::vector::iterator.

We still need all the _S_copy_chars overloads to be part of the explicit
instantiation definition, so make them depend on the macro that is
defined by src/c++11/string-inst.cc for that purpose.

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h (_S_copy_chars): Replace overloads
with constexpr-if and extend optimization to all contiguous
iterators.
* src/c++11/string-inst.cc: Extend comment.
---

Tested x86_64-linux.


LGTM with one clarification question.



 libstdc++-v3/include/bits/basic_string.h | 31 ++--
 libstdc++-v3/src/c++11/string-inst.cc|  3 ++-
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/include/bits/basic_string.h
b/libstdc++-v3/include/bits/basic_string.h
index 886e7e6b19e..067c7915c76 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -468,6 +468,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
  traits_type::assign(__d, __n, __c);
   }

+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wc++17-extensions"
   // _S_copy_chars is a separate template to permit specialization
   // to optimize for the common case of pointers as iterators.
   template
@@ -475,31 +477,44 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 static void
 _S_copy_chars(_CharT* __p, _Iterator __k1, _Iterator __k2)
 {
+#if __cplusplus >= 201103L
+ using _IterBase = decltype(std::__niter_base(__k1));
+ if constexpr (__or_,
+ is_same<_IterBase, const _CharT*>>::value)
+   _S_copy(__p, std::__niter_base(__k1), __k2 - __k1);
+#if __cpp_lib_concepts
+ else if constexpr (contiguous_iterator<_Iterator>
+  && is_same_v,
_CharT>)
+   {
+ const auto __d = __k2 - __k1;
+ (void) (__k1 + __d); // See P3349R1
+ _S_copy(__p, std::to_address(__k1),
static_cast(__d));
+   }
+#endif
+ else
+#endif
  for (; __k1 != __k2; ++__k1, (void)++__p)
traits_type::assign(*__p, *__k1); // These types are off.
}
+#pragma GCC diagnostic pop

-  _GLIBCXX20_CONSTEXPR
+#if __cplusplus < 201103L || defined
_GLIBCXX_DEFINING_STRING_INSTANTIATIONS
   static void
-  _S_copy_chars(_CharT* __p, iterator __k1, iterator __k2)
_GLIBCXX_NOEXCEPT


The  `_GLIBCXX_DEFINING_STRING_INSTANTIATIONS` seem to be used for
c++11/string-inst.cc, in
which case the noexcept was meaningful.


Is it?


The macro is not used in
c++17/string-inst.cc file, so noexcept


The src/c++17/string-inst.cc file only instantiates a handful of
member functions, and none of them uses _S_copy_chars. So I don't
think it matters for src/c++17/string-inst.cc at all.


would be part of the function signature, so I do not think we change
emitted symbols. Is this the reason
why did you remove it?


I removed it because those overloads of _S_copy_chars are only visible
in the header for C++98, where _GLIBCXX_NOEXCEPT expands to nothing.

You're correct that in src/c++11/string-inst.cc those overloads are
instantiated for C++11 (using -std=gnu++11), where it would expand to
'noexcept'. But I don't think it's meaningful whether it's present or
not.

In C++11 the noexcept isn't part of the type, and it never affects the
mangled name even in C++17. For these _S_copy_chars overloads, the
compiler can easily see that they don't throw, as they only call
std::char_traits::assign or std::char_traits::copy (or the
wchar_t equivalents) and those are noexcept. So for the explicit
instantiation definitions, the compiler knows they can't throw, and so
it never needs to use a noexcept landing pad to terminate if an
exception happens. So noexcept on the definition does nothing. Those
functions can't throw, and we don't need (or want) extra code emitted
to enforce the noexcept by terminating.

So the noexcept is only meaningful at the call site, so that callers
can see that those functions don't throw (and don't need their own
exception handling code). The call sites in string-inst.cc should be
able to see that they don't throw (they're compiled with -O2, and I
checked on x86_64 and there are no calls to _S_copy_chars left in the
assembly code). The call sites in user code can only see those
overloads for C++98, where _GLIBCXX_NOEXCEPT expands to nothing.

So I don't think the 'noexcept' is ever meaningful.



+  _S_copy_chars(_CharT* __p, iterator __k1, iterator __k2)
   { _S_copy_chars(__p, __k1.base(), __k2.base()); }

-  _GLIBCXX20_CONSTEXPR
   static void
   _S_copy_chars(_Ch

PowerPC patch ping^2

[Jakub Jelinek]

On Wed, Apr 02, 2025 at 03:32:31PM +0200, Jakub Jelinek wrote:
> I'd like to ping the following PowerPC patches:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679312.html
> rs6000: Ignore OPTION_MASK_SAVE_TOC_INDIRECT differences in inlining 
> decisions [PR119327]
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2025-March/676989.html
> target: Adjust gcc.target/powerpc/pr103515.c test [PR117207]

Thanks.

Jakub

[committed] d: Merge upstream dmd 1b34fea478, phobos 40ffbb364

[Iain Buclaw]

Hi,

This patch merges the D front-end compiler with upstream dmd 1b34fea478,
and the standard runtime library with upstream phobos 40ffbb364.

Synchronizing the recent bug fixes targeted for v2.111.1.

D front-end changes:

- Import latest fixes from dmd v2.111.1-rc.1.

Phobos changes:

- Import latest fixes from phobos v2.111.1-rc.1.
- Restore compatibility with older Linux platforms where
  `getrandom' is unavailable.

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

Regards,
Iain.

---
gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd 1b34fea478.

libphobos/ChangeLog:

* src/MERGE: Merge upstream phobos 40ffbb364.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Call DRUNTIME_OS_FEATURES.
* libdruntime/Makefile.am (AM_DFLAGS): Add OS_DFLAGS.
* libdruntime/Makefile.in: Regenerate.
* m4/druntime/os.m4 (DRUNTIME_OS_FEATURES): Define.
* src/Makefile.am: Add OS_DFLAGS.
* src/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
* testsuite/testsuite_flags.in: Add OS_DFLAGS.
---
 gcc/d/dmd/MERGE   |  2 +-
 gcc/d/dmd/globals.h   |  1 +
 gcc/d/dmd/lexer.d |  4 +-
 gcc/d/dmd/location.d  | 23 ---
 gcc/d/dmd/typesem.d   | 16 -
 gcc/testsuite/gdc.test/compilable/test21179.d | 11 
 .../fail_compilation/fail_pretty_errors.d | 18 ++---
 libphobos/Makefile.in |  1 +
 libphobos/configure   | 53 ++-
 libphobos/configure.ac|  1 +
 libphobos/libdruntime/Makefile.am |  3 +-
 libphobos/libdruntime/Makefile.in |  4 +-
 libphobos/m4/druntime/os.m4   | 27 
 libphobos/src/MERGE   |  2 +-
 libphobos/src/Makefile.am |  3 +-
 libphobos/src/Makefile.in |  4 +-
 libphobos/src/std/format/write.d  | 11 +++-
 libphobos/src/std/random.d| 66 ---
 libphobos/testsuite/Makefile.in   |  1 +
 libphobos/testsuite/testsuite_flags.in|  2 +-
 20 files changed, 210 insertions(+), 43 deletions(-)
 create mode 100644 gcc/testsuite/gdc.test/compilable/test21179.d

diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index a05a50eefb8..ee5eb853284 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-51816cd01deee5cc1d7d2c6e1e24788ec655b73e
+1b34fea4788136b54ec77c6ed9678754d109fc79
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/globals.h b/gcc/d/dmd/globals.h
index 59952a2c105..62a575e322e 100644
--- a/gcc/d/dmd/globals.h
+++ b/gcc/d/dmd/globals.h
@@ -421,6 +421,7 @@ struct SourceLoc
 uint32_t line;
 uint32_t column;
 uint32_t fileOffset;
+DString fileContent;
 };
 
 struct Loc
diff --git a/gcc/d/dmd/lexer.d b/gcc/d/dmd/lexer.d
index 63313ac2edd..ed9f7f1ce77 100644
--- a/gcc/d/dmd/lexer.d
+++ b/gcc/d/dmd/lexer.d
@@ -132,7 +132,7 @@ class Lexer
 // debug printf("Lexer::Lexer(%p)\n", base);
 // debug printf("lexer.filename = %s\n", filename);
 token = Token.init;
-this.baseLoc = newBaseLoc(filename, endoffset);
+this.baseLoc = newBaseLoc(filename, base[0 .. endoffset]);
 this.linnum = 1;
 this.base = base;
 this.end = base + endoffset;
@@ -224,7 +224,7 @@ class Lexer
 inTokenStringConstant = 0;
 lastDocLine = 0;
 
-baseLoc = newBaseLoc("#defines", slice.length);
+baseLoc = newBaseLoc("#defines", slice);
 scanloc = baseLoc.getLoc(0);
 }
 
diff --git a/gcc/d/dmd/location.d b/gcc/d/dmd/location.d
index 54b3fb6e0ae..393ffb8a92d 100644
--- a/gcc/d/dmd/location.d
+++ b/gcc/d/dmd/location.d
@@ -64,7 +64,7 @@ nothrow:
 extern (C++) static Loc singleFilename(const char* filename)
 {
 Loc result;
-locFileTable ~= new BaseLoc(filename.toDString, locIndex, 0, [0]);
+locFileTable ~= new BaseLoc(filename.toDString, null, locIndex, 0, 
[0]);
 result.index = locIndex++;
 return result;
 }
@@ -235,16 +235,20 @@ struct SourceLoc
 uint column; /// column number (starts at 1)
 uint fileOffset; /// byte index into file
 
+/// Index `fileOffset` into this to to obtain source code context of this 
location
+const(char)[] fileContent;
+
 // aliases for backwards compatibility
 alias linnum = line;
 alias charnum = column;
 
-this(const(char)[] filename, uint line, uint column, uint fileOffset = 0) 
nothrow @nogc pure @safe
+this(const(char)[] filename, uint line, uint column, uint fileOffset = 0, 
const(char)[] fileContent = null) nothrow @nogc pure @safe
 {
 this.fil

[PATCH] libstdc++: Define __cpp_lib_containers_ranges in appropariate headers [PR111055]

[Tomasz Kamiński]

This is final piece of P1206R7, adding a feature test macros,
as range constructors and member operations are now implemented for
all containers and adaptors.

For consistency with the proposal, all new container operations and
helpers are now defined if __glibcxx_containers_ranges, instead
of __glibcxx_containers_ranges.

PR libstdc++/111055

libstdc++-v3/ChangeLog:

* include/bits/version.def: Define containers_ranges feature test
macro.
* include/bits/version.h: Regenerate.
* include/bits/ranges_base.h (__detail::__container_compatible_range)
(__detail::__range_to_alloc_type, __detail::__range_mapped_type)
(__detail::__range_key_type): Define if __glibcxx_containers_ranges.
* include/bits/basic_string.h: Replace __glibcxx_ranges_to_container 
with
__glibcxx_containers_ranges.
* include/bits/cow_string.h: Likewise.
* include/bits/deque.tcc: Likewise.
* include/bits/forward_list.h: Likewise.
* include/bits/stl_bvector.h: Likewise.
* include/bits/stl_deque.h: Likewise.
* include/bits/stl_list.h: Likewise.
* include/bits/stl_map.h: Likewise.
* include/bits/stl_multimap.h: Likewise.
* include/bits/stl_multiset.h: Likewise.
* include/bits/stl_queue.h: Likewise.
* include/bits/stl_set.h: Likewise.
* include/bits/stl_stack.h: Likewise.
* include/bits/stl_vector.h: Likewise.
* include/bits/unordered_map.h: Likewise.
* include/bits/unordered_set.h: Likewise.
* include/bits/vector.tcc: Likewise.
* include/debug/deque: Likewise.
* include/debug/forward_list: Likewise.
* include/debug/list: Likewise.
* include/debug/map.h: Likewise.
* include/debug/multimap.h: Likewise.
* include/debug/multiset.h: Likewise.
* include/debug/set.h: Likewise.
* include/debug/unordered_map: Likewise.
* include/debug/unordered_set: Likewise.
* include/debug/vector: Likewise.
* include/std/deque: Provide __cpp_lib_containers_ranges.
* include/std/forward_list: Likewise.
* include/std/list: Likewise.
* include/std/map: Likewise.
* include/std/queue: Likewise.
* include/std/set: Likewise.
* include/std/stack: Likewise.
* include/std/string: Likewise.
* include/std/unordered_map: Likewise.
* include/std/unordered_set: Likewise.
* include/std/vector: Likewise.
* testsuite/21_strings/basic_string/cons/from_range.cc: Test for value
__cpp_lib_containers_ranges.
* testsuite/23_containers/deque/cons/from_range.cc: Likewise.
* testsuite/23_containers/forward_list/cons/from_range.cc: Likewise.
* testsuite/23_containers/list/cons/from_range.cc: Likewise.
* testsuite/23_containers/map/cons/from_range.cc: Likewise.
* testsuite/23_containers/multimap/cons/from_range.cc: Likewise.
* testsuite/23_containers/multiset/cons/from_range.cc: Likewise.
* testsuite/23_containers/priority_queue/cons_from_range.cc: Likewise.
* testsuite/23_containers/queue/cons_from_range.cc: Likewise.
* testsuite/23_containers/set/cons/from_range.cc: Likewise.
* testsuite/23_containers/stack/cons_from_range.cc: Likewise.
* testsuite/23_containers/unordered_map/cons/from_range.cc: Likewise.
* testsuite/23_containers/unordered_multimap/cons/from_range.cc: 
Likewise.
* testsuite/23_containers/unordered_multiset/cons/from_range.cc: 
Likewise.
* testsuite/23_containers/unordered_set/cons/from_range.cc: Likewise.
* testsuite/23_containers/vector/bool/cons/from_range.cc: Likewise.
* testsuite/23_containers/vector/cons/from_range.cc: Likewise.
---
Tested on x86_64-linux. OK for trunk?

 libstdc++-v3/include/bits/basic_string.h  | 16 +++
 libstdc++-v3/include/bits/cow_string.h| 10 +-
 libstdc++-v3/include/bits/deque.tcc   |  4 ++--
 libstdc++-v3/include/bits/forward_list.h  | 20 +--
 libstdc++-v3/include/bits/ranges_base.h   |  4 +++-
 libstdc++-v3/include/bits/stl_bvector.h   |  8 
 libstdc++-v3/include/bits/stl_deque.h | 12 +--
 libstdc++-v3/include/bits/stl_list.h  | 12 +--
 libstdc++-v3/include/bits/stl_map.h   |  8 
 libstdc++-v3/include/bits/stl_multimap.h  |  8 
 libstdc++-v3/include/bits/stl_multiset.h  |  8 
 libstdc++-v3/include/bits/stl_queue.h | 14 ++---
 libstdc++-v3/include/bits/stl_set.h   |  8 
 libstdc++-v3/include/bits/stl_stack.h |  8 
 libstdc++-v3/include/bits/stl_vector.h| 16 +++
 libstdc++-v3/include/bits/unordered_map.h | 14 ++---
 libstdc++-v3/include/bits/unordered_set.h | 14 ++---
 libstdc++-v3/include/bits/vector.tcc

Re: [PATCH] libstdc++: Use constexpr-if for std::basic_string::_S_copy_chars

[Tomasz Kaminski]

On Fri, Apr 11, 2025 at 12:52 PM Jonathan Wakely  wrote:

> On 11/04/25 09:49 +0200, Tomasz Kaminski wrote:
> >On Thu, Apr 10, 2025 at 6:29 PM Jonathan Wakely 
> wrote:
> >
> >> For C++11 and later we can remvoe four overloads of _S_copy_chars and
> >> use constexpr-if in the generic _S_copy_chars. This simplifies overload
> >> resolution for _S_copy_chars, and also means that we optimize for other
> >> iterators such as std::vector::iterator.
> >>
> >> We still need all the _S_copy_chars overloads to be part of the explicit
> >> instantiation definition, so make them depend on the macro that is
> >> defined by src/c++11/string-inst.cc for that purpose.
> >>
> >> libstdc++-v3/ChangeLog:
> >>
> >> * include/bits/basic_string.h (_S_copy_chars): Replace overloads
> >> with constexpr-if and extend optimization to all contiguous
> >> iterators.
> >> * src/c++11/string-inst.cc: Extend comment.
> >> ---
> >>
> >> Tested x86_64-linux.
> >>
> >LGTM with one clarification question.
> >
> >>
> >>  libstdc++-v3/include/bits/basic_string.h | 31 ++--
> >>  libstdc++-v3/src/c++11/string-inst.cc|  3 ++-
> >>  2 files changed, 25 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/libstdc++-v3/include/bits/basic_string.h
> >> b/libstdc++-v3/include/bits/basic_string.h
> >> index 886e7e6b19e..067c7915c76 100644
> >> --- a/libstdc++-v3/include/bits/basic_string.h
> >> +++ b/libstdc++-v3/include/bits/basic_string.h
> >> @@ -468,6 +468,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> >>   traits_type::assign(__d, __n, __c);
> >>}
> >>
> >> +#pragma GCC diagnostic push
> >> +#pragma GCC diagnostic ignored "-Wc++17-extensions"
> >>// _S_copy_chars is a separate template to permit specialization
> >>// to optimize for the common case of pointers as iterators.
> >>template
> >> @@ -475,31 +477,44 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> >>  static void
> >>  _S_copy_chars(_CharT* __p, _Iterator __k1, _Iterator __k2)
> >>  {
> >> +#if __cplusplus >= 201103L
> >> + using _IterBase = decltype(std::__niter_base(__k1));
> >> + if constexpr (__or_,
> >> + is_same<_IterBase, const _CharT*>>::value)
> >> +   _S_copy(__p, std::__niter_base(__k1), __k2 - __k1);
> >> +#if __cpp_lib_concepts
> >> + else if constexpr (contiguous_iterator<_Iterator>
> >> +  && is_same_v,
> >> _CharT>)
> >> +   {
> >> + const auto __d = __k2 - __k1;
> >> + (void) (__k1 + __d); // See P3349R1
> >> + _S_copy(__p, std::to_address(__k1),
> >> static_cast(__d));
> >> +   }
> >> +#endif
> >> + else
> >> +#endif
> >>   for (; __k1 != __k2; ++__k1, (void)++__p)
> >> traits_type::assign(*__p, *__k1); // These types are off.
> >> }
> >> +#pragma GCC diagnostic pop
> >>
> >> -  _GLIBCXX20_CONSTEXPR
> >> +#if __cplusplus < 201103L || defined
> >> _GLIBCXX_DEFINING_STRING_INSTANTIATIONS
> >>static void
> >> -  _S_copy_chars(_CharT* __p, iterator __k1, iterator __k2)
> >> _GLIBCXX_NOEXCEPT
> >>
> >The  `_GLIBCXX_DEFINING_STRING_INSTANTIATIONS` seem to be used for
> >c++11/string-inst.cc, in
> >which case the noexcept was meaningful.
>
> Is it?
>
I meant in a sense that `_GLIBCXX_NOEXCEPT` expanded to something. Nothing
beyond that.

>
> >The macro is not used in
> >c++17/string-inst.cc file, so noexcept
>
> The src/c++17/string-inst.cc file only instantiates a handful of
> member functions, and none of them uses _S_copy_chars. So I don't
> think it matters for src/c++17/string-inst.cc at all.
>
> >would be part of the function signature, so I do not think we change
> >emitted symbols. Is this the reason
> >why did you remove it?
>
> I removed it because those overloads of _S_copy_chars are only visible
> in the header for C++98, where _GLIBCXX_NOEXCEPT expands to nothing.
>
> You're correct that in src/c++11/string-inst.cc those overloads are
> instantiated for C++11 (using -std=gnu++11), where it would expand to
> 'noexcept'. But I don't think it's meaningful whether it's present or
> not.
>
> In C++11 the noexcept isn't part of the type, and it never affects the
> mangled name even in C++17. For these _S_copy_chars overloads, the
> compiler can easily see that they don't throw, as they only call
> std::char_traits::assign or std::char_traits::copy (or the
> wchar_t equivalents) and those are noexcept. So for the explicit
> instantiation definitions, the compiler knows they can't throw, and so
> it never needs to use a noexcept landing pad to terminate if an
> exception happens. So noexcept on the definition does nothing. Those
> functions can't throw, and we don't need (or want) extra code emitted
> to enforce the noexcept by terminating.
>
> So the noexcept is only meaningful at the call site, so that callers
> can see that those functions don't throw (and don't need their own
> ex

[PATCH] libstdc++: Implement formatter for ranges and range_formatter [PR109162]

[Tomasz Kamiński]

This patch implements formatter specialization for input_ranges
and range_formatter class form P2286R8, as adjusted by P2585R1.
The formatter for pair/tuple is not yet provided (making map unusable).

To indicate partial support we define __glibcxx_format_ranges macro
value 1, without defining __cpp_lib_format_ranges.

This introduces an new _M_format_range member to internal __formatter_str,
that formats range as _CharT as string, according the to the format spec.
This function transform any contiguous range into basic_string_view direclty,
by computing size if necessary. Otherwise, for ranges for which size can be
computed (forward_range or sized_range) we use a stack buffer, if they are
sufficiently small. Finally, we create a basic_string<_CharT> from the range,
and format it content.

In case when padding is specified, this is handled by firstly formatting
the content of the range to the temporary string object. However, this can be
only implemented if the iterator of the basic_format_context is internal
type-erased iterator used by implementation. Otherwise a new 
basic_format_context
would need to be created, which would require rebinding of handles stored in
the arguments: note that format spec for element type could retrive any format
argument from format context, visit and and user handle to format it.
As basic_format_context provide no user-facing constructor, the user are not 
able
to cosntructor object of that type with arbitrally iterators.

The signatures of the user-facing parse and format method of the provided
formatters deviate from the standard by constraining types of params:
* _CharT is constrained __formatter::__char
* basic_format_parse_context<_CharT> for parse argument
* basic_format_context<_Out, _CharT> for format second argument
The standard specifies last three of above as unconstrained types. This types
are later passed to possibly user-provided formatter specializations, that are
required via formattable concept to only accept above types.

Finally, the formatter specialization is implemented
without using specialization of range-default-formatter exposition only
template as base class, while providing same functionality.

PR libstdc++/109162

libstdc++-v3/ChangeLog:

* include/std/format (__format::__has_debug_format)
(__format::__Stackbuf_size): Define.
(__format::_Separators): Define additional constants.
(__format::_Spec::_M_parse_fill_and_align): Define overload accepting
list of excluded characters for fill, and forward existing overload.
(__formatter_str::_M_format_range): Define.
(__format::_Buf_sink) Use __Stackbuf_size for size of array.
(__format::__is_map_formattable, std::range_formatter)
(std::formatter<_Rg, _CharT>): Define.
* src/c++23/std.cc.in (std::format_kind, std::range_format)
(std::range_formatter): Export.
* testsuite/std/format/formatter/lwg3944.cc: Guarded tests with
__glibcxx_format_ranges.
* testsuite/std/format/formatter/requirements.cc: Adjusted for standard
behavior.
* testsuite/23_containers/vector/bool/format.cc: Test vector 
formatting.
* testsuite/std/format/ranges/format_kind.cc: New test.
* testsuite/std/format/ranges/formatter.cc: New test.
* testsuite/std/format/ranges/sequence.cc: New test.
* testsuite/std/format/ranges/string.cc: New test.
---
Tested on x86_64-linux. I am looking for suggestion for the text of 
error messages in range_formatter::parse method.

 libstdc++-v3/include/std/format   | 513 --
 libstdc++-v3/src/c++23/std.cc.in  |   6 +
 .../23_containers/vector/bool/format.cc   |   6 +
 .../testsuite/std/format/formatter/lwg3944.cc |   4 +-
 .../std/format/formatter/requirements.cc  |  14 +-
 .../std/format/ranges/format_kind.cc  |  94 
 .../testsuite/std/format/ranges/formatter.cc  | 145 +
 .../testsuite/std/format/ranges/sequence.cc   | 184 +++
 .../testsuite/std/format/ranges/string.cc | 223 
 9 files changed, 1123 insertions(+), 66 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/format/ranges/format_kind.cc
 create mode 100644 libstdc++-v3/testsuite/std/format/ranges/formatter.cc
 create mode 100644 libstdc++-v3/testsuite/std/format/ranges/sequence.cc
 create mode 100644 libstdc++-v3/testsuite/std/format/ranges/string.cc

diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
index 23f00970840..d33a9837255 100644
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -56,7 +56,7 @@
 #include   // input_range, range_reference_t
 #include   // subrange
 #include  // ranges::copy
-#include  // back_insert_iterator
+#include  // back_insert_iterator, counted_iterator
 #include  // __is_pair
 #include   // __is_scalar_value, _Utf_view, etc.
 #include   // tuple_size_v
@@ -97,6 +97,10 @@ namespace __format
 #defi

Re: [PATCH] libgomp: Update SVE tests

[Tejas Belagod]

On 4/10/25 5:29 PM, Jakub Jelinek wrote:

On Thu, Apr 10, 2025 at 05:13:12PM +0530, Tejas Belagod wrote:

Thanks for the explanation.  I looked into why some of the tests may have
failed - my flawed understanding of the reduction clause was why I didn't
have the += in the loops - it might have passed for me as I probably hit the
exact omp_get_num_threads () number required for the final += reductions to
trigger from the declare clause.  As Richard said, the += in the loops ought
to fix the tests. I'm still analysing inscan_reduction_incl () to fix it
properly.


For scan think about
   scan_a = 0;
#pragma omp parallel for reduction(inscan, +:scan_a)
   for (int i = 0; i < N; i++)
 {
   simd_scan[i] = scan_a;
   #pragma omp scan exclusive(scan_a)
   scan_a += a[i];
 }
and
   scan_a = 0;
#pragma omp parallel reduction(inscan, +:scan_a)
   for (int i = 0; i < N; i++)
 {
   scan_a += a[i];
   #pragma omp scan inclusive(scan_a)
   simd_scan[i] = scan_a;
 }
The directives arrange for the parallel version to compute the
same thing as the serial loops without the directives (at least
say for unsigned types, for signed or floating point it can
reassociate the additions (or whatever the reduction operation is).


Thanks for the explanations. It's easier to write tests when I think 
about it this way - it is less confusing.



OpenMP effectively breaks those halves of the loop bodies apart and
does magic in between.


So the magic in the middle is about applying the reduction upto the 
required iteration (across threads etc) when it is then read in the 
other part of the loop?


Thanks,
Tejas.

Re: [PATCH] libstdc++: Define __cpp_lib_containers_ranges in appropariate headers [PR111055]

[Jonathan Wakely]

Spelling of "appropriate" in the summary line.

On 11/04/25 13:18 +0200, Tomasz Kamiński wrote:

This is final piece of P1206R7, adding a feature test macros,
as range constructors and member operations are now implemented for
all containers and adaptors.

For consistency with the proposal, all new container operations and
helpers are now defined if __glibcxx_containers_ranges, instead
of __glibcxx_containers_ranges.


The second one should be __glibcxx_ranges_to_container, right?



PR libstdc++/111055

libstdc++-v3/ChangeLog:

* include/bits/version.def: Define containers_ranges feature test
macro.


This should be:

* include/bits/version.def (containers_ranges): Define.


* include/bits/version.h: Regenerate.
* include/bits/ranges_base.h (__detail::__container_compatible_range)
(__detail::__range_to_alloc_type, __detail::__range_mapped_type)
(__detail::__range_key_type): Define if __glibcxx_containers_ranges.


This reads to me like they're being defined for the first time, so
maybe "Depend on __glibcxx_containers_ranges instead of
__glibcxx_ranges_to_container".


* include/bits/basic_string.h: Replace __glibcxx_ranges_to_container 
with
__glibcxx_containers_ranges.
* include/bits/cow_string.h: Likewise.
* include/bits/deque.tcc: Likewise.
* include/bits/forward_list.h: Likewise.
* include/bits/stl_bvector.h: Likewise.
* include/bits/stl_deque.h: Likewise.
* include/bits/stl_list.h: Likewise.
* include/bits/stl_map.h: Likewise.
* include/bits/stl_multimap.h: Likewise.
* include/bits/stl_multiset.h: Likewise.
* include/bits/stl_queue.h: Likewise.
* include/bits/stl_set.h: Likewise.
* include/bits/stl_stack.h: Likewise.
* include/bits/stl_vector.h: Likewise.
* include/bits/unordered_map.h: Likewise.
* include/bits/unordered_set.h: Likewise.
* include/bits/vector.tcc: Likewise.
* include/debug/deque: Likewise.
* include/debug/forward_list: Likewise.
* include/debug/list: Likewise.
* include/debug/map.h: Likewise.
* include/debug/multimap.h: Likewise.
* include/debug/multiset.h: Likewise.
* include/debug/set.h: Likewise.
* include/debug/unordered_map: Likewise.
* include/debug/unordered_set: Likewise.
* include/debug/vector: Likewise.
* include/std/deque: Provide __cpp_lib_containers_ranges.
* include/std/forward_list: Likewise.
* include/std/list: Likewise.
* include/std/map: Likewise.
* include/std/queue: Likewise.
* include/std/set: Likewise.
* include/std/stack: Likewise.
* include/std/string: Likewise.
* include/std/unordered_map: Likewise.
* include/std/unordered_set: Likewise.
* include/std/vector: Likewise.
* testsuite/21_strings/basic_string/cons/from_range.cc: Test for value
__cpp_lib_containers_ranges.
* testsuite/23_containers/deque/cons/from_range.cc: Likewise.
* testsuite/23_containers/forward_list/cons/from_range.cc: Likewise.
* testsuite/23_containers/list/cons/from_range.cc: Likewise.
* testsuite/23_containers/map/cons/from_range.cc: Likewise.
* testsuite/23_containers/multimap/cons/from_range.cc: Likewise.
* testsuite/23_containers/multiset/cons/from_range.cc: Likewise.
* testsuite/23_containers/priority_queue/cons_from_range.cc: Likewise.
* testsuite/23_containers/queue/cons_from_range.cc: Likewise.
* testsuite/23_containers/set/cons/from_range.cc: Likewise.
* testsuite/23_containers/stack/cons_from_range.cc: Likewise.
* testsuite/23_containers/unordered_map/cons/from_range.cc: Likewise.
* testsuite/23_containers/unordered_multimap/cons/from_range.cc: 
Likewise.
* testsuite/23_containers/unordered_multiset/cons/from_range.cc: 
Likewise.
* testsuite/23_containers/unordered_set/cons/from_range.cc: Likewise.
* testsuite/23_containers/vector/bool/cons/from_range.cc: Likewise.
* testsuite/23_containers/vector/cons/from_range.cc: Likewise.
---
Tested on x86_64-linux. OK for trunk?


OK with the tweaks to the commit message above, thanks!

[PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Rainer Orth]

All users of symbols.h fail to compile on Solaris:

/vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope:
/vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1365:13: error: ‘NAME_MAX’ was 
not declared in this scope
 1365 |   char name[NAME_MAX];
  | ^~~~

NAME_MAX being undefined is allowed by POSIX.1, actually: it's listed
for  under "Pathname Variable Values":

A definition of one of the symbolic constants in the following list
shall be omitted from the  header on specific implementations
where the corresponding value is equal to or greater than the stated
minimum, but where the value can vary depending on the file to which it
is applied. The actual value supported for a specific pathname shall be
provided by the pathconf() function.

As a hack, this patch provides a fallback definition to allow the build
to finish.

Bootstrapped without regressions on amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.

Ok for trunk?

Rainer

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


2025-04-08  Rainer Orth  

gcc/cobol:
PR cobol/119217
* symbols.h (NAME_MAX): Define fallback.

# HG changeset patch
# Parent  7f248bc0accd0f82ac110149e93de68c8b769625
cobol: Allow for undefined NAME_MAX [PR119217]

diff --git a/gcc/cobol/symbols.h b/gcc/cobol/symbols.h
--- a/gcc/cobol/symbols.h
+++ b/gcc/cobol/symbols.h
@@ -46,6 +46,11 @@
 #include 
 #include 
 
+// NAME_MAX may be undefined when it can vary by file.
+#ifndef NAME_MAX
+#define NAME_MAX 255
+#endif
+
 #define PICTURE_MAX 64
 
 extern const char *numed_message;

Re: [PATCH] libstdc++: Define __cpp_lib_containers_ranges in appropariate headers [PR111055]

[Tomasz Kaminski]

On Fri, Apr 11, 2025 at 1:38 PM Jonathan Wakely  wrote:

>
> Spelling of "appropriate" in the summary line.
>
> On 11/04/25 13:18 +0200, Tomasz Kamiński wrote:
> >This is final piece of P1206R7, adding a feature test macros,
> >as range constructors and member operations are now implemented for
> >all containers and adaptors.
> >
> >For consistency with the proposal, all new container operations and
> >helpers are now defined if __glibcxx_containers_ranges, instead
> >of __glibcxx_containers_ranges.
>
> The second one should be __glibcxx_ranges_to_container, right?
>
Yes, I will fix that with the rest of the message.

>
> >
> >   PR libstdc++/111055
> >
> >libstdc++-v3/ChangeLog:
> >
> >   * include/bits/version.def: Define containers_ranges feature test
> >   macro.
>
> This should be:
>
> * include/bits/version.def (containers_ranges): Define.
>
> >   * include/bits/version.h: Regenerate.
> >   * include/bits/ranges_base.h
> (__detail::__container_compatible_range)
> >   (__detail::__range_to_alloc_type, __detail::__range_mapped_type)
> >   (__detail::__range_key_type): Define if
> __glibcxx_containers_ranges.
>
> This reads to me like they're being defined for the first time, so
> maybe "Depend on __glibcxx_containers_ranges instead of
> __glibcxx_ranges_to_container".
>
> >   * include/bits/basic_string.h: Replace
> __glibcxx_ranges_to_container with
> >   __glibcxx_containers_ranges.
> >   * include/bits/cow_string.h: Likewise.
> >   * include/bits/deque.tcc: Likewise.
> >   * include/bits/forward_list.h: Likewise.
> >   * include/bits/stl_bvector.h: Likewise.
> >   * include/bits/stl_deque.h: Likewise.
> >   * include/bits/stl_list.h: Likewise.
> >   * include/bits/stl_map.h: Likewise.
> >   * include/bits/stl_multimap.h: Likewise.
> >   * include/bits/stl_multiset.h: Likewise.
> >   * include/bits/stl_queue.h: Likewise.
> >   * include/bits/stl_set.h: Likewise.
> >   * include/bits/stl_stack.h: Likewise.
> >   * include/bits/stl_vector.h: Likewise.
> >   * include/bits/unordered_map.h: Likewise.
> >   * include/bits/unordered_set.h: Likewise.
> >   * include/bits/vector.tcc: Likewise.
> >   * include/debug/deque: Likewise.
> >   * include/debug/forward_list: Likewise.
> >   * include/debug/list: Likewise.
> >   * include/debug/map.h: Likewise.
> >   * include/debug/multimap.h: Likewise.
> >   * include/debug/multiset.h: Likewise.
> >   * include/debug/set.h: Likewise.
> >   * include/debug/unordered_map: Likewise.
> >   * include/debug/unordered_set: Likewise.
> >   * include/debug/vector: Likewise.
> >   * include/std/deque: Provide __cpp_lib_containers_ranges.
> >   * include/std/forward_list: Likewise.
> >   * include/std/list: Likewise.
> >   * include/std/map: Likewise.
> >   * include/std/queue: Likewise.
> >   * include/std/set: Likewise.
> >   * include/std/stack: Likewise.
> >   * include/std/string: Likewise.
> >   * include/std/unordered_map: Likewise.
> >   * include/std/unordered_set: Likewise.
> >   * include/std/vector: Likewise.
> >   * testsuite/21_strings/basic_string/cons/from_range.cc: Test for
> value
> >   __cpp_lib_containers_ranges.
> >   * testsuite/23_containers/deque/cons/from_range.cc: Likewise.
> >   * testsuite/23_containers/forward_list/cons/from_range.cc:
> Likewise.
> >   * testsuite/23_containers/list/cons/from_range.cc: Likewise.
> >   * testsuite/23_containers/map/cons/from_range.cc: Likewise.
> >   * testsuite/23_containers/multimap/cons/from_range.cc: Likewise.
> >   * testsuite/23_containers/multiset/cons/from_range.cc: Likewise.
> >   * testsuite/23_containers/priority_queue/cons_from_range.cc:
> Likewise.
> >   * testsuite/23_containers/queue/cons_from_range.cc: Likewise.
> >   * testsuite/23_containers/set/cons/from_range.cc: Likewise.
> >   * testsuite/23_containers/stack/cons_from_range.cc: Likewise.
> >   * testsuite/23_containers/unordered_map/cons/from_range.cc:
> Likewise.
> >   * testsuite/23_containers/unordered_multimap/cons/from_range.cc:
> Likewise.
> >   * testsuite/23_containers/unordered_multiset/cons/from_range.cc:
> Likewise.
> >   * testsuite/23_containers/unordered_set/cons/from_range.cc:
> Likewise.
> >   * testsuite/23_containers/vector/bool/cons/from_range.cc: Likewise.
> >   * testsuite/23_containers/vector/cons/from_range.cc: Likewise.
> >---
> >Tested on x86_64-linux. OK for trunk?
>
> OK with the tweaks to the commit message above, thanks!
>
>

[PATCH]RISCV :Added MIPS P8700 Subtarget

[Umesh Kalappa]

This is the first patch from the two-patch series, where configured gcc for 
P8700 micro architecture  in the first patch and 
Tested with dejagnu riscv.exp tests for --mtune=mips-p8700.
 
P8700 is a high-performance processor from MIPS by extending RISCV. The 
following changes enable P8700 processor for RISCV.

 * config/riscv/riscv-cores.def(RISCV_TUNE):Added mips-p8700 tune.
 * config/riscv/riscv-opts.h(riscv_microarchitecture_type):Likewise
 * config/riscv/riscv.cc(riscv_tune_param):Added insns costs p8700 tune.
 * config/riscv/riscv.md:Added p8700 tune for insn attribute.
 * config/riscv/mips-p8700.md:New File for mips-p8700 pipeline
   description
---
 gcc/config/riscv/mips-p8700.md   | 139 +++
 gcc/config/riscv/riscv-cores.def |   1 +
 gcc/config/riscv/riscv-opts.h|   3 +-
 gcc/config/riscv/riscv.cc|  22 +
 gcc/config/riscv/riscv.md|   3 +-
 5 files changed, 166 insertions(+), 2 deletions(-)  create mode 100644 
gcc/config/riscv/mips-p8700.md

diff --git a/gcc/config/riscv/mips-p8700.md b/gcc/config/riscv/mips-p8700.md 
new file mode 100644 index 000..11d0b1ca793
--- /dev/null
+++ b/gcc/config/riscv/mips-p8700.md
@@ -0,0 +1,139 @@
+;; DFA-based pipeline description for MIPS P8700.
+;;
+;; Copyright (C) 2025 Free Software Foundation, Inc.
+;;
+;; This file is part of GCC.
+;;
+;; GCC is free software; you can redistribute it and/or modify it ;; 
+under the terms of the GNU General Public License as published ;; by 
+the Free Software Foundation; either version 3, or (at your ;; option) 
+any later version.
+
+;; GCC is distributed in the hope that it will be useful, but WITHOUT 
+;; ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 
+;; or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public ;; 
+License for more details.
+
+;; You should have received a copy of the GNU General Public License ;; 
+along with GCC; see the file COPYING3.  If not see ;; 
+.
+
+(define_automaton "mips_p8700_agen_alq_pipe, mips_p8700_mdu_pipe, 
+mips_p8700_fpu_pipe")
+
+;; The address generation queue (AGQ) has AL2, CTISTD and LDSTA pipes 
+(define_cpu_unit "mips_p8700_agq, mips_p8700_al2, mips_p8700_ctistd, 
mips_p8700_lsu"
+"mips_p8700_agen_alq_pipe")
+
+(define_cpu_unit "mips_p8700_gpmul, mips_p8700_gpdiv" 
+"mips_p8700_mdu_pipe")
+
+;; The arithmetic-logic-unit queue (ALQ) has ALU pipe (define_cpu_unit 
+"mips_p8700_alq, mips_p8700_alu" "mips_p8700_agen_alq_pipe")
+
+;; The floating-point-unit queue (FPQ) has short and long pipes 
+(define_cpu_unit "mips_p8700_fpu_short, mips_p8700_fpu_long" 
+"mips_p8700_fpu_pipe")
+
+;; Long FPU pipeline.
+(define_cpu_unit "mips_p8700_fpu_apu" "mips_p8700_fpu_pipe")
+
+(define_reservation "mips_p8700_agq_al2" "mips_p8700_agq, 
+mips_p8700_al2") (define_reservation "mips_p8700_agq_ctistd" 
+"mips_p8700_agq, mips_p8700_ctistd") (define_reservation 
+"mips_p8700_agq_lsu" "mips_p8700_agq, mips_p8700_lsu") 
+(define_reservation "mips_p8700_alq_alu" "mips_p8700_alq, 
+mips_p8700_alu")
+
+;;
+;; FPU pipe
+;;
+
+(define_insn_reservation "mips_p8700_fpu_fadd" 4
+  (and (eq_attr "tune" "mips_p8700")
+   (eq_attr "type" "fadd"))
+  "mips_p8700_fpu_long, mips_p8700_fpu_apu")
+
+(define_insn_reservation "mips_p8700_fpu_fabs" 2
+  (and (eq_attr "tune" "mips_p8700")
+   (eq_attr "type" "fcmp,fmove"))
+  "mips_p8700_fpu_short, mips_p8700_fpu_apu")
+
+(define_insn_reservation "mips_p8700_fpu_fload" 8
+  (and (eq_attr "tune" "mips_p8700")
+   (eq_attr "type" "fpload"))
+  "mips_p8700_agq_lsu")
+
+(define_insn_reservation "mips_p8700_fpu_fstore" 1
+  (and (eq_attr "tune" "mips_p8700")
+   (eq_attr "type" "fpstore"))
+  "mips_p8700_agq_lsu")
+
+(define_insn_reservation "mips_p8700_fpu_fmadd" 8
+  (and (eq_attr "tune" "mips_p8700")
+   (eq_attr "type" "fmadd"))
+  "mips_p8700_fpu_long, mips_p8700_fpu_apu")
+
+(define_insn_reservation "mips_p8700_fpu_fmul" 5
+  (and (eq_attr "tune" "mips_p8700")
+   (eq_attr "type" "fmul"))
+  "mips_p8700_fpu_long, mips_p8700_fpu_apu")
+
+(define_insn_reservation "mips_p8700_fpu_div" 17
+  (and (eq_attr "tune" "mips_p8700")
+   (eq_attr "type" "fdiv,fsqrt"))
+  "mips_p8700_fpu_long, mips_p8700_fpu_apu*17")
+
+(define_insn_reservation "mips_p8700_fpu_fcvt" 4
+  (and (eq_attr "tune" "mips_p8700")
+   (eq_attr "type" "fcvt,fcvt_i2f,fcvt_f2i"))
+  "mips_p8700_fpu_long, mips_p8700_fpu_apu")
+
+(define_insn_reservation "mips_p8700_fpu_fmtc" 7
+  (and (eq_attr "tune" "mips_p8700")
+   (eq_attr "type" "mtc"))
+  "mips_p8700_agq_lsu")
+
+(define_insn_reservation "mips_p8700_fpu_fmfc" 7
+  (and (eq_attr "tune" "mips_p8700")
+   (eq_attr "type" "mfc"))
+  "mips_p8700_agq_lsu")
+
+;;
+;; Integer pipe
+;;
+
+(define_insn_reservation "mips_p8700_int_load" 4
+  (and (eq_attr "tune" "mips_p8700")
+   (eq_attr "type" "load"))
+  "mips_p8700_agq_lsu")
+
+(define_insn_reservation "mips_p8700_

Re: [PATCH] libstdc++: Use constexpr-if for std::basic_string::_S_copy_chars

[Jonathan Wakely]

On Fri, 11 Apr 2025 at 12:21, Tomasz Kaminski  wrote:
>
>
>
> On Fri, Apr 11, 2025 at 12:52 PM Jonathan Wakely  wrote:
>>
>> On 11/04/25 09:49 +0200, Tomasz Kaminski wrote:
>> >On Thu, Apr 10, 2025 at 6:29 PM Jonathan Wakely  wrote:
>> >
>> >> For C++11 and later we can remvoe four overloads of _S_copy_chars and
>> >> use constexpr-if in the generic _S_copy_chars. This simplifies overload
>> >> resolution for _S_copy_chars, and also means that we optimize for other
>> >> iterators such as std::vector::iterator.
>> >>
>> >> We still need all the _S_copy_chars overloads to be part of the explicit
>> >> instantiation definition, so make them depend on the macro that is
>> >> defined by src/c++11/string-inst.cc for that purpose.
>> >>
>> >> libstdc++-v3/ChangeLog:
>> >>
>> >> * include/bits/basic_string.h (_S_copy_chars): Replace overloads
>> >> with constexpr-if and extend optimization to all contiguous
>> >> iterators.
>> >> * src/c++11/string-inst.cc: Extend comment.
>> >> ---
>> >>
>> >> Tested x86_64-linux.
>> >>
>> >LGTM with one clarification question.
>> >
>> >>
>> >>  libstdc++-v3/include/bits/basic_string.h | 31 ++--
>> >>  libstdc++-v3/src/c++11/string-inst.cc|  3 ++-
>> >>  2 files changed, 25 insertions(+), 9 deletions(-)
>> >>
>> >> diff --git a/libstdc++-v3/include/bits/basic_string.h
>> >> b/libstdc++-v3/include/bits/basic_string.h
>> >> index 886e7e6b19e..067c7915c76 100644
>> >> --- a/libstdc++-v3/include/bits/basic_string.h
>> >> +++ b/libstdc++-v3/include/bits/basic_string.h
>> >> @@ -468,6 +468,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>> >>   traits_type::assign(__d, __n, __c);
>> >>}
>> >>
>> >> +#pragma GCC diagnostic push
>> >> +#pragma GCC diagnostic ignored "-Wc++17-extensions"
>> >>// _S_copy_chars is a separate template to permit specialization
>> >>// to optimize for the common case of pointers as iterators.
>> >>template
>> >> @@ -475,31 +477,44 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>> >>  static void
>> >>  _S_copy_chars(_CharT* __p, _Iterator __k1, _Iterator __k2)
>> >>  {
>> >> +#if __cplusplus >= 201103L
>> >> + using _IterBase = decltype(std::__niter_base(__k1));
>> >> + if constexpr (__or_,
>> >> + is_same<_IterBase, const _CharT*>>::value)
>> >> +   _S_copy(__p, std::__niter_base(__k1), __k2 - __k1);
>> >> +#if __cpp_lib_concepts
>> >> + else if constexpr (contiguous_iterator<_Iterator>
>> >> +  && is_same_v,
>> >> _CharT>)
>> >> +   {
>> >> + const auto __d = __k2 - __k1;
>> >> + (void) (__k1 + __d); // See P3349R1
>> >> + _S_copy(__p, std::to_address(__k1),
>> >> static_cast(__d));
>> >> +   }
>> >> +#endif
>> >> + else
>> >> +#endif
>> >>   for (; __k1 != __k2; ++__k1, (void)++__p)
>> >> traits_type::assign(*__p, *__k1); // These types are off.
>> >> }
>> >> +#pragma GCC diagnostic pop
>> >>
>> >> -  _GLIBCXX20_CONSTEXPR
>> >> +#if __cplusplus < 201103L || defined
>> >> _GLIBCXX_DEFINING_STRING_INSTANTIATIONS
>> >>static void
>> >> -  _S_copy_chars(_CharT* __p, iterator __k1, iterator __k2)
>> >> _GLIBCXX_NOEXCEPT
>> >>
>> >The  `_GLIBCXX_DEFINING_STRING_INSTANTIATIONS` seem to be used for
>> >c++11/string-inst.cc, in
>> >which case the noexcept was meaningful.
>>
>> Is it?
>
> I meant in a sense that `_GLIBCXX_NOEXCEPT` expanded to something. Nothing 
> beyond that.

Ah OK :-)

Yes, it is a difference in the tokens compiled in string-inst.cc, but
I don't think it matters.

>>
>>
>> >The macro is not used in
>> >c++17/string-inst.cc file, so noexcept
>>
>> The src/c++17/string-inst.cc file only instantiates a handful of
>> member functions, and none of them uses _S_copy_chars. So I don't
>> think it matters for src/c++17/string-inst.cc at all.
>>
>> >would be part of the function signature, so I do not think we change
>> >emitted symbols. Is this the reason
>> >why did you remove it?
>>
>> I removed it because those overloads of _S_copy_chars are only visible
>> in the header for C++98, where _GLIBCXX_NOEXCEPT expands to nothing.
>>
>> You're correct that in src/c++11/string-inst.cc those overloads are
>> instantiated for C++11 (using -std=gnu++11), where it would expand to
>> 'noexcept'. But I don't think it's meaningful whether it's present or
>> not.
>>
>> In C++11 the noexcept isn't part of the type, and it never affects the
>> mangled name even in C++17. For these _S_copy_chars overloads, the
>> compiler can easily see that they don't throw, as they only call
>> std::char_traits::assign or std::char_traits::copy (or the
>> wchar_t equivalents) and those are noexcept. So for the explicit
>> instantiation definitions, the compiler knows they can't throw, and so
>> it never needs to use a noexcept landing pad to terminate if an
>> exception happens. So noexcept on the def

Re: [PATCH] libgcobol: Check for struct tm tm_zone

[Rainer Orth]

Hi Andreas,

> On Apr 11 2025, Rainer Orth wrote:
>
>> This patch uses Autoconf's AC_STRUCT_TIMEZONE to determine its presence
>> and guard the use accordingly.
>
> You cannot use AC_STRUCT_TIMEZONE because it requires a link test (which
> is forbidden in a target module, see PR119550).

drats.  Must have taken this from libstdc++ shortly before it was
replaced.

I suspect a simple

AC_CHECK_MEMBER([struct tm.tm_zone],,[#include ])

does the trick.

Thanks for the hint.

Rainer

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

Re: [PATCH] cobol: Avoid conflict with OVERFLOW in system headers [PR119217]

[Simon Sobisch]

Shouldn't that be

--- a/gcc/cobol/parse.y
+++ b/gcc/cobol/parse.y
@@ -337,7 +337,7 @@
 %token  INVALID
 %token  NUMBER NEGATIVE
 %token  NUMSTR"numeric literal"
-%token  OVERFLOW
+%token  OVERFLOW_kw "OVERFLOW"
 %token   COMPUTATIONAL


? Otherwise bison syntax messages will use OVERFLOW_kw instead of the 
"real" name - if this _kw is done with other tokens in parse.y I think 
it should similarly specify the token "message identifier".


Simon

Re: [PATCH] libstdc++: Fix atomic CAS hang with C++11 [PR114865]

[Jonathan Wakely]

On Fri, 11 Apr 2025 at 08:23, Tomasz Kaminski  wrote:
>
>
>
> On Thu, Apr 10, 2025 at 6:27 PM Jonathan Wakely  wrote:
>>
>> The std::atomic constructor clears padding bits so that compare_exchange
>> will not fail due to differences in padding bits. But we can only do
>> that for C++14 and later, because in C++11 a constexpr constructor must
>> have an empty body. However, the code in compare_exchange_strong assumes
>> that padding is always cleared, and so it fails in C++11 due to non-zero
>> padding.
>>
>> Since we can't clear the padding in C++11 mode, we shouldn't assume it's
>> been cleared when in C++11 mode. This fixes the reported bug. However,
>> the fix fails to handle the case where the std::atomic is constructed in
>> C++11 code (and so doesn't zero padding) but the CAS happens in C++14
>> code (and so assumes padding has been zeroed). We might need to use the
>> same loop as atomic_ref::compare_exchange_strong to properly fix this
>> bug for that case.
>>
>> Although the mixed C++11 / C++14 case isn't fixed, this is still an
>> incremental improvement. It fixes the pure-C++11 case and doesn't
>> preclude a more comprehensive fix later.
>
> Wouldn't alternative comprehensive fix be equivalent to doing just:
> diff --git a/libstdc++-v3/include/std/atomic b/libstdc++-v3/include/std/atomic
> index 9b1aca0fc09..238cf739161 100644
> --- a/libstdc++-v3/include/std/atomic
> +++ b/libstdc++-v3/include/std/atomic
> @@ -345,7 +345,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>compare_exchange_weak(_Tp& __e, _Tp __i, memory_order __s,
> memory_order __f) noexcept
>{
> -   return __atomic_impl::__compare_exchange(_M_i, __e, __i, true,
> +   return __atomic_impl::__compare_exchange<(__cplusplus < 
> 201402L)>(_M_i, __e, __i, true,
>  __s, __f);

If the std::atomic constructor happens in a translation unit compiled
as C++11 but the call to compare_exchange_weak happens in a
translation unit compiled as C++14, then padding won't be cleared, but
this will call __compare_exchange which expects padding to have
been cleared.


>}
>
> @@ -353,7 +353,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>compare_exchange_weak(_Tp& __e, _Tp __i, memory_order __s,
> memory_order __f) volatile noexcept
>{
> -   return __atomic_impl::__compare_exchange(_M_i, __e, __i, true,
> +   return __atomic_impl::__compare_exchange<(__cplusplus < 
> 201402L)>(_M_i, __e, __i, true,
>  __s, __f);
>}
>
> @@ -373,7 +373,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>compare_exchange_strong(_Tp& __e, _Tp __i, memory_order __s,
>   memory_order __f) noexcept
>{
> -   return __atomic_impl::__compare_exchange(_M_i, __e, __i, false,
> +   return __atomic_impl::__compare_exchange<(__cplusplus < 
> 201402L)>(_M_i, __e, __i, false,
>  __s, __f);
>}
>
> @@ -381,7 +381,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>compare_exchange_strong(_Tp& __e, _Tp __i, memory_order __s,
>   memory_order __f) volatile noexcept
>{
> -   return __atomic_impl::__compare_exchange(_M_i, __e, __i, false,
> +   return __atomic_impl::__compare_exchange<(__cplusplus < 
> 201402L)>(_M_i, __e, __i, false,
>  __s, __f);
>}
>
>>
>> libstdc++-v3/ChangeLog:
>>
>> PR libstdc++/114865
>> * include/bits/atomic_base.h (__maybe_has_padding): Return false
>> for C++11.
>> * include/std/atomic (atomic::atomic(T)): Add comment.
>> * testsuite/29_atomics/atomic/114865.cc: New test.
>> ---
>>
>> Tested x86_64-linux.
>>
>>  libstdc++-v3/include/bits/atomic_base.h   |  4 +-
>>  libstdc++-v3/include/std/atomic   |  2 +
>>  .../testsuite/29_atomics/atomic/114865.cc | 49 +++
>>  3 files changed, 54 insertions(+), 1 deletion(-)
>>  create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/114865.cc
>>
>> diff --git a/libstdc++-v3/include/bits/atomic_base.h 
>> b/libstdc++-v3/include/bits/atomic_base.h
>> index 92d1269493f..19fc7a77c1b 100644
>> --- a/libstdc++-v3/include/bits/atomic_base.h
>> +++ b/libstdc++-v3/include/bits/atomic_base.h
>> @@ -954,7 +954,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>constexpr bool
>>__maybe_has_padding()
>>{
>> -#if ! __has_builtin(__builtin_clear_padding)
>> +   // We cannot clear padding in the constructor for C++11,
>> +   // so return false here to disable all code for zeroing padding.
>> +#if __cplusplus < 201402L || ! __has_builtin(__builtin_clear_padding)
>> return false;
>>  #elif __has_builtin(__has_unique_object_representations)
>> return !__has_unique_object_representations(_Tp)
>> diff --git a/libstdc++-v3/include/std/atomic 
>> b/libstdc

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Simon Sobisch]

> You're right: seems to be all about COBOL function names.  No idea
what value is appropriate/required here, though.

if this is about COBOL internal function names: ISO says and GnuCOBOL
therefore defines

/* Maximum length of COBOL words */
#define COB_MAX_WORDLEN 63


Note that _externalized_ words (like function names) _can_ be longer
(that limit is implementor-defined).


If that is about the names of the functions generated by gcobol - you
could have a look at the externalized symbols of libgcobol.



For both 2 + 3 I think 255 is much more than enough, 127 is likely also
enough...


Kind regards,
Simon

Re: [PATCH] cobol: Avoid conflict with OVERFLOW in system headers [PR119217]

[Rainer Orth]

Hi Simon,

> Shouldn't that be
>
> --- a/gcc/cobol/parse.y
> +++ b/gcc/cobol/parse.y
> @@ -337,7 +337,7 @@
>  %token  INVALID
>  %token  NUMBER NEGATIVE
>  %token  NUMSTR"numeric literal"
> -%token  OVERFLOW
> +%token  OVERFLOW_kw "OVERFLOW"
>  %token   COMPUTATIONAL
>
>
> ? Otherwise bison syntax messages will use OVERFLOW_kw instead of the
> "real" name - if this _kw is done with other tokens in parse.y I think it
> should similarly specify the token "message identifier".

you're right.  I guess it would really be best to consistently use the
*_kw form so all tokens are treated the same.

Thanks.
Rainer

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

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Richard Biener]

On Fri, Apr 11, 2025 at 2:14 PM Rainer Orth  
wrote:
>
> Andreas Schwab  writes:
>
> > On Apr 11 2025, Rainer Orth wrote:
> >
> >> All users of symbols.h fail to compile on Solaris:
> >>
> >> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope:
> >> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1365:13: error: 
> >> ‘NAME_MAX’ was not declared in this scope
> >>  1365 |   char name[NAME_MAX];
> >>   | ^~~~
> >>
> >> NAME_MAX being undefined is allowed by POSIX.1, actually: it's listed
> >> for  under "Pathname Variable Values":
> >
> > It doesn't look like this member is accociated with file names at all.
>
> You're right: seems to be all about COBOL function names.  No idea what
> value is appropriate/required here, though.

It seems 'name' is never set!?  Renaming it yields only

../../src/gcc/gcc/cobol/symbols.cc:496:59: error: ‘const struct
cbl_function_t’ has no member named ‘name’; did you mean ‘namex’?
  496 | return strcmp(k->elem.function.name, e->elem.function.name);
  |   ^~~~
  |   namex
../../src/gcc/gcc/cobol/symbols.cc: In function ‘size_t
symbols_dump(size_t, bool)’:
../../src/gcc/gcc/cobol/symbols.cc:1088:50: error: ‘struct
cbl_function_t’ has no member named ‘name’; did you mean ‘namex’?
 1088 | "Function", e->elem.function.name);
  |  ^~~~
  |  namex

the last is

case SymFunction:
  s = xasprintf("%4zu %-15s %s", e->program,
"Function", e->elem.function.name);

Huh.

Richard.

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

ping on fixes for cobol.1 + gcobc

[Simon Sobisch]

with GCC 15.1 in sight... ping on


gcobc wrapper fixes and additions:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680218.html

(note: obviously it would be good if -Wall [1] would work (the "global" 
PR for -Wall was postponed to GCC16, so possibly add to gcobol as 
intermediate?), then the special handling for it can be dropped;

just recognized: -v (verbose) also does not work for gcobol.


cobol.1 fix:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680557.html


Kind regards,
Simon


[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119329

Re: [PATCH] dwarf2out: Decrease dw_loc_descr_node and dw_attr_struct struct sizes [PR119711]

[Richard Biener]

On Thu, 10 Apr 2025, Jakub Jelinek wrote:

> Hi!
> 
> As noted by Richi on a large testcase, there are unnecessary paddings
> in some heavily used dwarf2out.{h,cc} structures on 64-bit hosts.
> 
> struct dw_val_node {
> enum dw_val_class  val_class;/* 0 4 */
> 
> /* XXX 4 bytes hole, try to pack */
> 
> struct addr_table_entry *  val_entry;/* 8 8 */
> union dw_val_struct_union  v;/*1616 */
> 
> /* size: 32, cachelines: 1, members: 3 */
> /* sum members: 28, holes: 1, sum holes: 4 */
> /* last cacheline: 32 bytes */
> };
> struct dw_loc_descr_node {
> dw_loc_descr_ref   dw_loc_next;  /* 0 8 */
> enum dwarf_location_atom   dw_loc_opc:8; /* 8: 0  4 */
> unsigned int   dtprel:1; /* 8: 8  4 */
> unsigned int   frame_offset_rel:1;   /* 8: 9  4 */
> 
> /* XXX 22 bits hole, try to pack */
> 
> intdw_loc_addr;  /*12 4 */
> struct dw_val_node dw_loc_oprnd1;/*1632 */
> struct dw_val_node dw_loc_oprnd2;/*4832 */
> 
> /* size: 80, cachelines: 2, members: 7 */
> /* sum members: 76 */
> /* sum bitfield members: 10 bits, bit holes: 1, sum bit holes: 22 
> bits */
> /* last cacheline: 16 bytes */
> };
> struct dw_attr_struct {
> enum dwarf_attribute   dw_attr;  /* 0 4 */
> 
> /* XXX 4 bytes hole, try to pack */
> 
> struct dw_val_node dw_attr_val;  /* 832 */
> 
> /* size: 40, cachelines: 1, members: 2 */
> /* sum members: 36, holes: 1, sum holes: 4 */
> /* last cacheline: 40 bytes */
> };
> 
> The following patch is an (not very clean admittedly) attempt to decrease
> size of dw_loc_descr_node from 80 bytes to 72 and (more importantly)
> dw_attr_struct from 40 bytes to 32 by moving the dw_attr member from
> dw_attr_struct into dw_attr_val's padding and similarly move
> dw_loc_opc/dtprel/frame_offset_rel members into dw_loc_oprnd1 padding
> and dw_loc_addr into dw_loc_oprnd2 padding.
> All we need to ensure is that nothing tries to copy whole dw_val_node
> structs unless it is copied as part of whole dw_loc_descr_node or
> dw_attr_struct copy.
> 
> To verify that wasn't the case, I've temporarily added a deleted copy ctor
> to dw_val_node and then looked at all the errors/warnings caused by that,
> and those were just from memcpy/memmove or structure assignments of whole
> dw_loc_descr_node/dw_attr_struct.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux.
> Ok for stage1?

LGTM.

I agree it's not the prettiest thing, and possibly fragile
with respect to copying.  But I don't have a better solution
(for dw_attr I suggested packed/aligned on IRC, but that would not
work for the dw_loc_descr_node case).  So let's go with well-placed
comments indicating the situation.

I also noted that the struct addr_table_entry * GTY(()) val_entry; is
only used with -gsplit-dwarf and that we might want to find another
(temporary) home for it.

Thanks,
Richard.

> 2025-04-10  Jakub Jelinek  
> 
>   PR debug/119711
>   * dwarf2out.h (struct dw_val_node): Add u member.
>   (struct dw_loc_descr_node): Remove dw_loc_opc, dtprel,
>   frame_offset_rel and dw_loc_addr members.
>   (dw_loc_opc, dw_loc_dtprel, dw_loc_frame_offset_rel, dw_loc_addr):
>   Define.
>   (struct dw_attr_struct): Remove dw_attr member.
>   (dw_attr): Define.
>   * dwarf2out.cc (loc_descr_equal_p_1): Use dw_loc_dtprel instead of
>   dtprel.
>   (output_loc_operands, new_addr_loc_descr, loc_checksum,
>   loc_checksum_ordered): Likewise.
>   (resolve_args_picking_1): Use dw_loc_frame_offset_rel instead of
>   frame_offset_rel.
>   (loc_list_from_tree_1): Likewise.
>   (resolve_addr_in_expr): Use dw_loc_dtprel instead of dtprel.
>   (copy_deref_exprloc): Copy val_class, val_entry and v members
>   instead of whole dw_loc_oprnd1 and dw_loc_oprnd2.
>   (optimize_string_length): Copy val_class, val_entry and v members
>   instead of whole dw_attr_val.
>   (hash_loc_operands): Use dw_loc_dtprel instead of dtprel.
>   (compare_loc_operands, compare_locs): Likewise.
> 
> --- gcc/dwarf2out.h.jj2025-04-08 14:08:51.82269 +0200
> +++ gcc/dwarf2out.h   2025-04-10 19:07:32.535018798 +0200
> @@ -276,6 +276,25 @@ typedef struct GTY(()) dw_loc_list_struc
>  
>  struct GTY(()) dw_val_node {
>enum dw_val_class val_class;
> +  /* On 64-bit host, there are 4 bytes of padding between val_class
> + and val_entry.  Reuse the padding for other content of
> + dw_loc_descr_node and dw_attr_struct.  */
> +  union dw_val_node_parent
> +{
> +  struct dw_val_loc_descr_node
> + {
> +   ENUM_

[committed] libstdc++: Add fast_float patch to LOCAL_PATCHES

[Jonathan Wakely]

libstdc++-v3/ChangeLog:

* src/c++17/fast_float/LOCAL_PATCHES: Update.
---

Pushed to trunk.

 libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES 
b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
index 71495d6728b..28d86fd4d70 100644
--- a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
+++ b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
@@ -1,2 +1,3 @@
 r12-6647
 r12-6648
+r15-9382
-- 
2.49.0

[PATCH v3] libstdc++: Implement C++26 features (P2546R5)

[Jonathan Wakely]

This includes the P2810R4 (is_debugger_present is_replaceable) changes,
allowing std::is_debugger_present to be replaced by the program.

It would be good to provide a macOS definition of is_debugger_present as
per https://developer.apple.com/library/archive/qa/qa1361/_index.html
but that isn't included in this change.

libstdc++-v3/ChangeLog:

* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Check for facilities needed by .
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/version.def (debugging): Add.
* include/bits/version.h: Regenerate.
* src/c++26/Makefile.am: Add new file.
* src/c++26/Makefile.in: Regenerate.
* include/std/debugging: New file.
* src/c++26/debugging.cc: New file.
* testsuite/19_diagnostics/debugging/breakpoint.cc: New test.
* testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc:
New test.
* testsuite/19_diagnostics/debugging/is_debugger_present.cc: New
test.
* testsuite/19_diagnostics/debugging/is_debugger_present-2.cc:
New test.
---

This v3 patch uses #elif for the SYS_PTRACE_H group, as suggested by
Tomasz, adds more systemtap probes, and fixes the known debuggers checks
to match LLDB properly and to match gdbserver. Tested with gdb,
gdbserver, and lldb on Fedora 41.

This is experimental, so whether we keep the attach_debugger(bool)
function is undecided. It might be that GDB will end up using a
different approach, maybe based on the probe points. It would be nice if
GDB would break at the top of std::breakpoint() and not on the asm later
in the function. Ideally it would even break in the user code where
std::breakpoint() is called, and not show the std::breakpoint()
internals at all. But we can't easily experiment with any of that in GDB
until there's something working on libstdc++.

Tested x86_64-linux.

 libstdc++-v3/config.h.in  |   9 +
 libstdc++-v3/configure|  22 +++
 libstdc++-v3/configure.ac |   9 +
 libstdc++-v3/include/Makefile.am  |   1 +
 libstdc++-v3/include/Makefile.in  |   1 +
 libstdc++-v3/include/bits/version.def |   8 +
 libstdc++-v3/include/bits/version.h   |  10 +
 libstdc++-v3/include/std/debugging|  77 
 libstdc++-v3/src/c++26/Makefile.am|   4 +-
 libstdc++-v3/src/c++26/Makefile.in|   7 +-
 libstdc++-v3/src/c++26/debugging.cc   | 172 ++
 .../19_diagnostics/debugging/breakpoint.cc|  13 ++
 .../debugging/breakpoint_if_debugging.cc  |  13 ++
 .../debugging/is_debugger_present-2.cc|  19 ++
 .../debugging/is_debugger_present.cc  |  14 ++
 15 files changed, 376 insertions(+), 3 deletions(-)
 create mode 100644 libstdc++-v3/include/std/debugging
 create mode 100644 libstdc++-v3/src/c++26/debugging.cc
 create mode 100644 
libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint.cc
 create mode 100644 
libstdc++-v3/testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc
 create mode 100644 
libstdc++-v3/testsuite/19_diagnostics/debugging/is_debugger_present-2.cc
 create mode 100644 
libstdc++-v3/testsuite/19_diagnostics/debugging/is_debugger_present.cc

diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
index 77bbaf1beaa..3f1331ff36f 100644
--- a/libstdc++-v3/config.h.in
+++ b/libstdc++-v3/config.h.in
@@ -70,6 +70,9 @@
 /* Define to 1 if you have the `cosl' function. */
 #undef HAVE_COSL
 
+/* Define to 1 if you have the  header file. */
+#undef HAVE_DEBUGAPI_H
+
 /* Define to 1 if you have the declaration of `strnlen', and to 0 if you
don't. */
 #undef HAVE_DECL_STRNLEN
@@ -439,6 +442,9 @@
 /* Define to 1 if you have the  header file. */
 #undef HAVE_SYS_PARAM_H
 
+/* Define to 1 if you have the  header file. */
+#undef HAVE_SYS_PTRACE_H
+
 /* Define to 1 if you have the  header file. */
 #undef HAVE_SYS_RESOURCE_H
 
@@ -850,6 +856,9 @@
 /* Define if nl_langinfo_l should be used for std::text_encoding. */
 #undef _GLIBCXX_USE_NL_LANGINFO_L
 
+/* Define if /proc/self/status should be used for . */
+#undef _GLIBCXX_USE_PROC_SELF_STATUS
+
 /* Define if pthreads_num_processors_np is available in . */
 #undef _GLIBCXX_USE_PTHREADS_NUM_PROCESSORS_NP
 
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 819a1d82876..8143df91c38 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -54700,6 +54700,28 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 
 
+# For std::is_debugger_present
+case "$target_os" in
+  linux*)
+
+$as_echo "#define _GLIBCXX_USE_PROC_SELF_STATUS 1" >>confdefs.h
+
+;;
+esac
+for ac_header in sys/ptrace.h debugapi.h
+do :
+  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
+ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" 
"$ac_includes_default"
+if eval test \"x\$"$as_ac_

[PATCH] libstdc++: Document thread-safety for COW std::string [PR21334]

[Jonathan Wakely]

The gcc4-compatible copy-on-write std::string does not conform to the
C++11 requirements on data race avoidance in standard containers.
Specifically, calling non-const member functions such as begin() and
data() needs to do the "copy on write" operation and so is most
definitely a modification of the object. As such, those non-const
members must not be called concurrently with any other uses of the
string object.

libstdc++-v3/ChangeLog:

PR libstdc++/21334
* doc/xml/manual/using.xml: Document that container data race
avoidance rules do not apply to COW std::string.
* doc/html/*: Regenerate.
---
 libstdc++-v3/doc/html/manual/using_concurrency.html | 10 ++
 libstdc++-v3/doc/xml/manual/using.xml   | 12 
 2 files changed, 22 insertions(+)

diff --git a/libstdc++-v3/doc/html/manual/using_concurrency.html 
b/libstdc++-v3/doc/html/manual/using_concurrency.html
index d21f1588494..d570d3a2b84 100644
--- a/libstdc++-v3/doc/html/manual/using_concurrency.html
+++ b/libstdc++-v3/doc/html/manual/using_concurrency.html
@@ -126,6 +126,16 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
  the container the iterator refers to (for example incrementing a
  list iterator must access the pointers between nodes, which are part
  of the container and so conflict with other accesses to the 
container).
+  
+The Copy-On-Write std::string 
implementation
+used before GCC 5 (and with
+_GLIBCXX_USE_CXX11_ABI=0)
+is not a standard container and does not conform to the data race
+avoidance rules described above. For the Copy-On-Write
+std::string, non-const member functions 
such as
+begin() are considered to be modifying 
accesses
+and so must not be used concurrently with any other accesses to the
+same object.
   Programs which follow the rules above will not encounter data
  races in library code, even when using library types which share
  state between distinct objects.  In the example below the
diff --git a/libstdc++-v3/doc/xml/manual/using.xml 
b/libstdc++-v3/doc/xml/manual/using.xml
index 7ca3a3f4b4c..bf92c495f6d 100644
--- a/libstdc++-v3/doc/xml/manual/using.xml
+++ b/libstdc++-v3/doc/xml/manual/using.xml
@@ -2069,6 +2069,18 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
  of the container and so conflict with other accesses to the 
container).
   
 
+  
+The Copy-On-Write std::string implementation
+used before GCC 5 (and with
+_GLIBCXX_USE_CXX11_ABI=0)
+is not a standard container and does not conform to the data race
+avoidance rules described above. For the Copy-On-Write
+std::string, non-const member functions such as
+begin() are considered to be modifying accesses
+and so must not be used concurrently with any other accesses to the
+same object.
+  
+
   Programs which follow the rules above will not encounter data
  races in library code, even when using library types which share
  state between distinct objects.  In the example below the
-- 
2.49.0

Re: .ACCESS_WITH_SIZE and pointer ranges

[Qing Zhao]

> On Apr 10, 2025, at 11:12, Martin Uecker  wrote:
> 
> Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
>> On 2025-04-10 10:50, Andrew MacLeod wrote:
>>> Its not clear to me exactly what is being asked, but I think the 
>>> suggestion is that pointer references are being replaced with a builtin 
>>> function called .ACCESS_WITH_SIZE ?and I presume that builtin 
>>> function has some parameters that give you relevant range information of 
>>> some sort?
>> 
>> Added, not replaced, but yes, that's essentially it.
>> 
>>> range-ops is setup to pull range information from builtin functions 
>>> already in gimple-range-op.cc:: 
>>> gimple_range_op_handler::maybe_builtin_call ().  We'd just need to write 
>>> a handler for this new one.  You can pull information from 2 operands 
>>> under normal circumstances, but exceptions can be made.I'd need a 
>>> description of what it looks like and how that translates to range info.
>> 
>> That's perfect!  It's probably redundant for cases where we end up with 
>> both .ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't remember if 
>> that's the only place where .ACCESS_WITH_SIZE is generated today.  Qing, 
>> could you please work with Andrew on this?
> 
> BTW, what I would find very interesting is inserting such information
> at the points where arrays decay to pointer.

Is the following the example?

  1 #include 
  2
  3 void foo (int arr[]) {
  4   // Inside the function, arr is treated as a pointer
  5   arr[6] = 10;
  6 }
  7
  8 int my_array[5] = {10, 20, 30, 40, 50};
  9   
 10 int main() {
 11   my_array[6] = 6;
 12   int *ptr = my_array; // Array decays to pointer here
 13   ptr[7] = 7;
 14   foo (my_array);
 15   16   return 0;
 17 }

When I use the latest gcc to compile the above with -Warray-bounds:

[]$ gcc -O2 -Warray-bounds t.c
t.c: In function ‘main’:
t.c:13:6: warning: array subscript 7 is outside array bounds of ‘int[5]’ 
[-Warray-bounds=]
   13 |   ptr[7] = 7;
  |   ~~~^~~
t.c:8:5: note: at offset 28 into object ‘my_array’ of size 20
8 | int my_array[5] = {10, 20, 30, 40, 50};
  | ^~~~
In function ‘foo’,
inlined from ‘main’ at t.c:14:3:
t.c:5:10: warning: array subscript 6 is outside array bounds of ‘int[5]’ 
[-Warray-bounds=]
5 |   arr[6] = 10;
  |   ~~~^~~~
t.c: In function ‘main’:
t.c:8:5: note: at offset 24 into object ‘my_array’ of size 20
8 | int my_array[5] = {10, 20, 30, 40, 50};
  | ^~~~

Looks like that even after the array decay to pointer, the bound information is 
still carried
for the decayed pointer somehow (I guess that vrp did this?)

thanks.

Qing

> 
> Martin

[committed] [RISC-V] Fix testsuite fallout from recent changes

[Jeff Law]

Recent changes have started triggering:


Tests that now fail, but worked before (3 tests):

unix/-march=rv64gc_zba_zbb_zbs_zicond: gcc: 
gcc.target/riscv/rvv/base/pr115068-run.c (test for excess errors)
unix/-march=rv64gc_zba_zbb_zbs_zicond: gcc: 
gcc.target/riscv/rvv/base/pr115068.c (test for excess errors)
unix/-march=rv64gc_zba_zbb_zbs_zicond: gcc: 
gcc.target/riscv/rvv/base/vwaddsub-1.c (test for excess errors)


We're emitting a pedantic diagnostic on the #include_next.  This just 
turns off the pedantic warnings.


Pushing as obvious.

Jeffcommit 992be16d83814694d6dbce448f9b5cb47ba4c8d4
Author: Jeff Law 
Date:   Fri Apr 11 08:28:22 2025 -0600

[committed] [RISC-V] Fix testsuite fallout from recent changes

Recent changes have started triggering:

> Tests that now fail, but worked before (3 tests):
>
> unix/-march=rv64gc_zba_zbb_zbs_zicond: gcc: 
gcc.target/riscv/rvv/base/pr115068-run.c (test for excess errors)
> unix/-march=rv64gc_zba_zbb_zbs_zicond: gcc: 
gcc.target/riscv/rvv/base/pr115068.c (test for excess errors)
> unix/-march=rv64gc_zba_zbb_zbs_zicond: gcc: 
gcc.target/riscv/rvv/base/vwaddsub-1.c (test for excess errors)

We're emitting a pedantic diagnostic on the #include_next.  This just turns 
off the pedantic warnings.

Pushing as obvious.

gcc/testsuite
* gcc.target/riscv/rvv/base/pr115068-run.c: Turn off pedantic 
diagnostics.
* gcc.target/riscv/rvv/base/pr115068.c: Likewise.
* gcc.target/riscv/rvv/base/vwaddsub-1.c: Likewise.

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr115068-run.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr115068-run.c
index d552eb568f6..e9e41f7db87 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr115068-run.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr115068-run.c
@@ -1,6 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target riscv_v_ok } */
 /* { dg-add-options riscv_v } */
-/* { dg-additional-options "-std=gnu99" } */
+/* { dg-additional-options "-std=gnu99 -Wno-pedantic" } */
 
 #include "pr115068.c"
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr115068.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr115068.c
index 8144d29b837..ce9a3892a70 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr115068.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr115068.c
@@ -1,6 +1,6 @@
 /* { dg-do compile { target { ! riscv_abi_e } } } */
 /* { dg-add-options riscv_v } */
-/* { dg-additional-options "-std=gnu99" } */
+/* { dg-additional-options "-std=gnu99 -Wno-pedantic" } */
 
 #include 
 #include "riscv_vector.h"
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/vwaddsub-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/vwaddsub-1.c
index c0ca9fcbf90..43be202ebe9 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/vwaddsub-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/vwaddsub-1.c
@@ -1,6 +1,6 @@
 /* { dg-do compile { target { { ! riscv_abi_e } && rv64 } } } */
 /* { dg-add-options riscv_v } */
-/* { dg-additional-options "-std=gnu99 -O3 -fno-schedule-insns 
-fno-schedule-insns2" } */
+/* { dg-additional-options "-std=gnu99 -O3 -fno-schedule-insns 
-fno-schedule-insns2 -Wno-pedantic" } */
 
 #include 
 #include "riscv_vector.h"

Re: .ACCESS_WITH_SIZE and pointer ranges

[Qing Zhao]

> On Apr 10, 2025, at 10:55, Siddhesh Poyarekar  wrote:
> 
> On 2025-04-10 10:50, Andrew MacLeod wrote:
>> Its not clear to me exactly what is being asked, but I think the suggestion 
>> is that pointer references are being replaced with a builtin function called 
>> .ACCESS_WITH_SIZE ?and I presume that builtin function has some 
>> parameters that give you relevant range information of some sort?
> 
> Added, not replaced, but yes, that's essentially it.
> 
>> range-ops is setup to pull range information from builtin functions already 
>> in gimple-range-op.cc:: gimple_range_op_handler::maybe_builtin_call ().  
>> We'd just need to write a handler for this new one.  You can pull 
>> information from 2 operands under normal circumstances, but exceptions can 
>> be made.I'd need a description of what it looks like and how that 
>> translates to range info.
> 
> That's perfect!  It's probably redundant for cases where we end up with both 
> .ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't remember if that's the 
> only place where .ACCESS_WITH_SIZE is generated today.


.ACCESS_WITH_SIZE was defined as following:


.ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, CLASS_OF_SIZE,
 TYPE_OF_SIZE, ACCESS_MODE))
which returns the REF_TO_OBJ same as the 1st argument;

In the above call to .ACCESS_WITH_SIZE:

   1st argument REF_TO_OBJ: The reference to the object;
   2nd argument REF_TO_SIZE: The reference to the size of the object,
   3rd argument CLASS_OF_SIZE: The size referenced by the REF_TO_SIZE represents
 0: the number of bytes.
 1: the number of the elements of the object type;
   4th argument TYPE_OF_SIZE: A constant 0 with its TYPE being the same as the 
TYPE
of the object referenced by REF_TO_SIZE
   5th argument ACCESS_MODE:
-1: Unknown access semantics
 0: none
 1: read_only
 2: write_only
 3: read_write
   6th argument: A constant 0 with the pointer TYPE to the original flexible
 array type.

C FE generates calls to .ACCESS_WITH_SIZE;
Expand phase converts the call to .ACCESS_WITH_SIZE back to the first argument.

All tree phases before Expand can utilize the size information carried by the 
call to .ACCESS_WITH_SIZE.

Currently, every reference to a flexible array member field with counted_by 
attribute will be replaced by:

   (*.ACCESS_WITH_SIZE (REF, COUNTED_BY_REF, 1, (TYPE_OF_SIZE)0, -1,
(TYPE_OF_ARRAY *)0))

For example:

struct annotated {
  size_t count;
  char array[] __attribute__((counted_by (count)));
} *obj;

Given

obj->array

It will be converted to:

  _2 = &obj->array;
  _3 = &obj->count;
  (* .ACCESS_WITH_SIZE (_2, _3, 1, 0, -1, 0B));

Currently, two phases utilized the size information from .ACCESS_WITH_SIZE:

1. Bound sanitizer (c-family/c-ubsan.cc)
2. _bdos (tree-object-size.cc)


> Qing, could you please work with Andrew on this?

Sure!

Andrew, Please see the above brief introduction of .ACCESS_WITH_SIZE. let me 
know if you need more details.

Thanks a lot for your help.

Qing
> 
> Thanks,
> Sid

[pushed] c++: avoid ARM -Wunused-value [PR114970]

[Jason Merrill]

Tested by me on x86_64-pc-linux-gnu and Sam James on
armv7a-unknown-linux-gnueabihf, applying to trunk.

-- 8< --

Because of the __builtin_is_constant_evaluated, maybe_constant_init in
expand_default_init fails, so the constexpr constructor isn't folded until
cp_fold, which then calls cp_build_init_expr_for_ctor, which builds a
COMPOUND_EXPR in case the enclosing expression is relying on the ARM
behavior of returning 'this'.

As in other places, avoid -Wunused-value on artificial COMPOUND_EXPR.

PR c++/114970

gcc/cp/ChangeLog:

* cp-gimplify.cc (cp_build_init_expr_for_ctor): Suppress warnings on
return_this COMPOUND_EXPR.

gcc/testsuite/ChangeLog:

* g++.dg/opt/is_constant_evaluated4.C: New test.
---
 gcc/cp/cp-gimplify.cc |  7 +--
 .../g++.dg/opt/is_constant_evaluated4.C   | 20 +++
 2 files changed, 25 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/opt/is_constant_evaluated4.C

diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index 550cea29dd2..f5625ab0daa 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -1199,8 +1199,11 @@ cp_build_init_expr_for_ctor (tree call, tree init)
   tree s = build_fold_indirect_ref_loc (loc, a);
   init = cp_build_init_expr (s, init);
   if (return_this)
-init = build2_loc (loc, COMPOUND_EXPR, TREE_TYPE (call), init,
-   fold_convert_loc (loc, TREE_TYPE (call), a));
+{
+  init = build2_loc (loc, COMPOUND_EXPR, TREE_TYPE (call), init,
+fold_convert_loc (loc, TREE_TYPE (call), a));
+  suppress_warning (init);
+}
   return init;
 }
 
diff --git a/gcc/testsuite/g++.dg/opt/is_constant_evaluated4.C 
b/gcc/testsuite/g++.dg/opt/is_constant_evaluated4.C
new file mode 100644
index 000..9650004ced1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/opt/is_constant_evaluated4.C
@@ -0,0 +1,20 @@
+// PR c++/114970
+// { dg-do compile { target c++17 } }
+// { dg-additional-options "-O -Wunused-value" }
+
+struct sv
+{
+  const char* str;
+  unsigned len;
+
+  constexpr sv(const char *p): str(p), len(0)
+  {
+if (__builtin_is_constant_evaluated ()) { len = 42; }
+  }
+};
+
+int main()
+{
+  sv s ("foo");
+  return s.len;
+}

base-commit: 44478b69d70ff0095a1fd06392e380827de4688a
-- 
2.49.0

Re: .ACCESS_WITH_SIZE and pointer ranges

[Andrew MacLeod]

On 4/11/25 10:05, Qing Zhao wrote:



On Apr 10, 2025, at 10:55, Siddhesh Poyarekar  wrote:

On 2025-04-10 10:50, Andrew MacLeod wrote:

Its not clear to me exactly what is being asked, but I think the suggestion is 
that pointer references are being replaced with a builtin function called 
.ACCESS_WITH_SIZE ?and I presume that builtin function has some parameters 
that give you relevant range information of some sort?

Added, not replaced, but yes, that's essentially it.


range-ops is setup to pull range information from builtin functions already in 
gimple-range-op.cc:: gimple_range_op_handler::maybe_builtin_call ().  We'd just 
need to write a handler for this new one.  You can pull information from 2 
operands under normal circumstances, but exceptions can be made.I'd need a 
description of what it looks like and how that translates to range info.

That's perfect!  It's probably redundant for cases where we end up with both 
.ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't remember if that's the 
only place where .ACCESS_WITH_SIZE is generated today.


.ACCESS_WITH_SIZE was defined as following:


.ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, CLASS_OF_SIZE,
  TYPE_OF_SIZE, ACCESS_MODE))
which returns the REF_TO_OBJ same as the 1st argument;

In the above call to .ACCESS_WITH_SIZE:

1st argument REF_TO_OBJ: The reference to the object;
2nd argument REF_TO_SIZE: The reference to the size of the object,
3rd argument CLASS_OF_SIZE: The size referenced by the REF_TO_SIZE 
represents
  0: the number of bytes.
  1: the number of the elements of the object type;
4th argument TYPE_OF_SIZE: A constant 0 with its TYPE being the same as the 
TYPE
 of the object referenced by REF_TO_SIZE
5th argument ACCESS_MODE:
 -1: Unknown access semantics
  0: none
  1: read_only
  2: write_only
  3: read_write
6th argument: A constant 0 with the pointer TYPE to the original flexible
  array type.

C FE generates calls to .ACCESS_WITH_SIZE;
Expand phase converts the call to .ACCESS_WITH_SIZE back to the first argument.

All tree phases before Expand can utilize the size information carried by the 
call to .ACCESS_WITH_SIZE.

Currently, every reference to a flexible array member field with counted_by 
attribute will be replaced by:

(*.ACCESS_WITH_SIZE (REF, COUNTED_BY_REF, 1, (TYPE_OF_SIZE)0, -1,
 (TYPE_OF_ARRAY *)0))

For example:

struct annotated {
   size_t count;
   char array[] __attribute__((counted_by (count)));
} *obj;

Given

obj->array

It will be converted to:

   _2 = &obj->array;
   _3 = &obj->count;
   (* .ACCESS_WITH_SIZE (_2, _3, 1, 0, -1, 0B));

Currently, two phases utilized the size information from .ACCESS_WITH_SIZE:

1. Bound sanitizer (c-family/c-ubsan.cc)
2. _bdos (tree-object-size.cc)



Qing, could you please work with Andrew on this?

Sure!

Andrew, Please see the above brief introduction of .ACCESS_WITH_SIZE. let me 
know if you need more details.

THere isn't much practical ranger can do with this information yet.. our 
prange implementation has not yet been enhanced to track points to 
information, but there are plans to enhance it to track that as well as  
the information carried buy the current "pointer-query" code that the 
warnings utilize.  When we get to that point, we would be able to use 
the information here to construct a useful pointer reference...


But that wont be for a while.

I will hold onto this and use it when we are enhancing the prange 
class.  I can't give you a date yet tho :-P


Andrew

Re: .ACCESS_WITH_SIZE and pointer ranges

[Martin Uecker]

Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod:
> On 4/11/25 10:27, Qing Zhao wrote:
> > 
> > > On Apr 10, 2025, at 11:12, Martin Uecker  wrote:
> > > 
> > > Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
> > > > On 2025-04-10 10:50, Andrew MacLeod wrote:
> > > > > Its not clear to me exactly what is being asked, but I think the
> > > > > suggestion is that pointer references are being replaced with a 
> > > > > builtin
> > > > > function called .ACCESS_WITH_SIZE ?and I presume that builtin
> > > > > function has some parameters that give you relevant range information 
> > > > > of
> > > > > some sort?
> > > > Added, not replaced, but yes, that's essentially it.
> > > > 
> > > > > range-ops is setup to pull range information from builtin functions
> > > > > already in gimple-range-op.cc::
> > > > > gimple_range_op_handler::maybe_builtin_call ().  We'd just need to 
> > > > > write
> > > > > a handler for this new one.  You can pull information from 2 operands
> > > > > under normal circumstances, but exceptions can be made.I'd need a
> > > > > description of what it looks like and how that translates to range 
> > > > > info.
> > > > That's perfect!  It's probably redundant for cases where we end up with
> > > > both .ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't remember if
> > > > that's the only place where .ACCESS_WITH_SIZE is generated today.  Qing,
> > > > could you please work with Andrew on this?
> > > BTW, what I would find very interesting is inserting such information
> > > at the points where arrays decay to pointer.
> > Is the following the example?
> > 
> >1 #include 
> >2
> >3 void foo (int arr[]) {
> >4   // Inside the function, arr is treated as a pointer
> >5   arr[6] = 10;
> >6 }
> >7
> >8 int my_array[5] = {10, 20, 30, 40, 50};
> >9
> >   10 int main() {
> >   11   my_array[6] = 6;
> >   12   int *ptr = my_array; // Array decays to pointer here
> >   13   ptr[7] = 7;
> >   14   foo (my_array);
> >   15   16   return 0;
> >   17 }
> > 
> > When I use the latest gcc to compile the above with -Warray-bounds:
> > 
> > []$ gcc -O2 -Warray-bounds t.c
> > t.c: In function ‘main’:
> > t.c:13:6: warning: array subscript 7 is outside array bounds of ‘int[5]’ 
> > [-Warray-bounds=]
> > 13 |   ptr[7] = 7;
> >|   ~~~^~~
> > t.c:8:5: note: at offset 28 into object ‘my_array’ of size 20
> >  8 | int my_array[5] = {10, 20, 30, 40, 50};
> >| ^~~~
> > In function ‘foo’,
> >  inlined from ‘main’ at t.c:14:3:
> > t.c:5:10: warning: array subscript 6 is outside array bounds of ‘int[5]’ 
> > [-Warray-bounds=]
> >  5 |   arr[6] = 10;
> >|   ~~~^~~~
> > t.c: In function ‘main’:
> > t.c:8:5: note: at offset 24 into object ‘my_array’ of size 20
> >  8 | int my_array[5] = {10, 20, 30, 40, 50};
> >| ^~~~
> > 
> > Looks like that even after the array decay to pointer, the bound 
> > information is still carried
> > for the decayed pointer somehow (I guess that vrp did this?)
> 
> No, the behaviour in these warnings is from something else. Although 
> some range info from VRP is used, most of this is tracked by the 
> pointer_query (pointer-query.cc) mechanism that was written a number of 
> years ago before ranger was completed.  It attempts to do its own custom 
> tracking of pointers and what they point to and the size of things they 
> access.
> 
> There are issues with that code, and the goal is to replace it with 
> rangers prange.  Alas there is enhancement work to prange for that to 
> happen as it doesnt currently track and points to info. That would then 
> be followed by converting the warning code to then use ranger/VRP instead.
> 
>   Any any adjustments to ranger for this are unlikely to affect anything 
> until that work is done, and I do not think anyone is equipped to 
> attempt to update the existing pointer-query code.
> 
> Unfortunately :-(

Examples I have in mind for the .ACCESS_WITH_SIZE are the
following two:

struct foo {

char arr[3];
int b;
};
 
void f(struct foo x)
{
char *ptr = x.arr;
ptr[4] = 10;
}

void g(char (*arr)[4])
{
char *ptr = *arr;
ptr[4] = 1;
}


Martin

Re: [PATCH] libstdc++: Fix atomic CAS hang with C++11 [PR114865]

[Tomasz Kaminski]

On Fri, Apr 11, 2025 at 2:25 PM Jonathan Wakely  wrote:

> On Fri, 11 Apr 2025 at 08:23, Tomasz Kaminski  wrote:
> >
> >
> >
> > On Thu, Apr 10, 2025 at 6:27 PM Jonathan Wakely 
> wrote:
> >>
> >> The std::atomic constructor clears padding bits so that compare_exchange
> >> will not fail due to differences in padding bits. But we can only do
> >> that for C++14 and later, because in C++11 a constexpr constructor must
> >> have an empty body. However, the code in compare_exchange_strong assumes
> >> that padding is always cleared, and so it fails in C++11 due to non-zero
> >> padding.
> >>
> >> Since we can't clear the padding in C++11 mode, we shouldn't assume it's
> >> been cleared when in C++11 mode. This fixes the reported bug. However,
> >> the fix fails to handle the case where the std::atomic is constructed in
> >> C++11 code (and so doesn't zero padding) but the CAS happens in C++14
> >> code (and so assumes padding has been zeroed). We might need to use the
> >> same loop as atomic_ref::compare_exchange_strong to properly fix this
> >> bug for that case.
> >>
> >> Although the mixed C++11 / C++14 case isn't fixed, this is still an
> >> incremental improvement. It fixes the pure-C++11 case and doesn't
> >> preclude a more comprehensive fix later.
> >
> > Wouldn't alternative comprehensive fix be equivalent to doing just:
> > diff --git a/libstdc++-v3/include/std/atomic
> b/libstdc++-v3/include/std/atomic
> > index 9b1aca0fc09..238cf739161 100644
> > --- a/libstdc++-v3/include/std/atomic
> > +++ b/libstdc++-v3/include/std/atomic
> > @@ -345,7 +345,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >compare_exchange_weak(_Tp& __e, _Tp __i, memory_order __s,
> > memory_order __f) noexcept
> >{
> > -   return __atomic_impl::__compare_exchange(_M_i, __e, __i, true,
> > +   return __atomic_impl::__compare_exchange<(__cplusplus <
> 201402L)>(_M_i, __e, __i, true,
> >  __s, __f);
>
> If the std::atomic constructor happens in a translation unit compiled
> as C++11 but the call to compare_exchange_weak happens in a
> translation unit compiled as C++14, then padding won't be cleared, but
> this will call __compare_exchange which expects padding to have
> been cleared.
>
I see. This seems to be the same drawback as in case of the current fix,
however
my suggestion guarantees that padding bits are ignored/cleared in program
compiled only in C++11 mode. As I understand the suggested change, make a
comparison exchange
prone to fail due padding bits.


>
>
> >}
> >
> > @@ -353,7 +353,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >compare_exchange_weak(_Tp& __e, _Tp __i, memory_order __s,
> > memory_order __f) volatile noexcept
> >{
> > -   return __atomic_impl::__compare_exchange(_M_i, __e, __i, true,
> > +   return __atomic_impl::__compare_exchange<(__cplusplus <
> 201402L)>(_M_i, __e, __i, true,
> >  __s, __f);
> >}
> >
> > @@ -373,7 +373,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >compare_exchange_strong(_Tp& __e, _Tp __i, memory_order __s,
> >   memory_order __f) noexcept
> >{
> > -   return __atomic_impl::__compare_exchange(_M_i, __e, __i, false,
> > +   return __atomic_impl::__compare_exchange<(__cplusplus <
> 201402L)>(_M_i, __e, __i, false,
> >  __s, __f);
> >}
> >
> > @@ -381,7 +381,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >compare_exchange_strong(_Tp& __e, _Tp __i, memory_order __s,
> >   memory_order __f) volatile noexcept
> >{
> > -   return __atomic_impl::__compare_exchange(_M_i, __e, __i, false,
> > +   return __atomic_impl::__compare_exchange<(__cplusplus <
> 201402L)>(_M_i, __e, __i, false,
> >  __s, __f);
> >}
> >
> >>
> >> libstdc++-v3/ChangeLog:
> >>
> >> PR libstdc++/114865
> >> * include/bits/atomic_base.h (__maybe_has_padding): Return false
> >> for C++11.
> >> * include/std/atomic (atomic::atomic(T)): Add comment.
> >> * testsuite/29_atomics/atomic/114865.cc: New test.
> >> ---
> >>
> >> Tested x86_64-linux.
> >>
> >>  libstdc++-v3/include/bits/atomic_base.h   |  4 +-
> >>  libstdc++-v3/include/std/atomic   |  2 +
> >>  .../testsuite/29_atomics/atomic/114865.cc | 49 +++
> >>  3 files changed, 54 insertions(+), 1 deletion(-)
> >>  create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/114865.cc
> >>
> >> diff --git a/libstdc++-v3/include/bits/atomic_base.h
> b/libstdc++-v3/include/bits/atomic_base.h
> >> index 92d1269493f..19fc7a77c1b 100644
> >> --- a/libstdc++-v3/include/bits/atomic_base.h
> >> +++ b/libstdc++-v3/include/bits/atomic_base.h
> >> @@ -954,7 +954,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >>

Re: [committed] modula2: Fix a comment typo

[Gaius Mulley]

Jakub Jelinek  writes:

> Hi!
>
> During make gcc.pot I've noticed among tons of other warnings (e.g. because
> can't appears in non-C/C++ style comment and so gettext considers it
> unterminated) a warning where the lack of " looked unintentional.
>
> Committed to trunk as obvious.
>
> 2025-04-09  Jakub Jelinek  
>
>   * gm2-compiler/M2MetaError.def: Fix comment typo, range" -> "range2".
>
> --- gcc/m2/gm2-compiler/M2MetaError.def.jj2025-04-08 14:08:52.102270018 
> +0200
> +++ gcc/m2/gm2-compiler/M2MetaError.def   2025-04-09 18:43:35.032144612 
> +0200
> @@ -109,7 +109,8 @@ FROM NameKey IMPORT Name ;
>  describe the symbol.  If ordinary text is copied then it is not quoted.
>  
> The color strings are: "filename", "quote", "error", "warning", "note",
> -  "locus", "insert", "delete", "type", "range1", 
> range2".
> +  "locus", "insert", "delete", "type", "range1",
> +  "range2".
>  *)
>  
>  (*
>
>   Jakub

Hi Jakub,

many thanks, lgtm.  Thanks for the info on unbalanced quotes, I'll
explore adding options into cc1gm2 to detect unbalanced quotes within
the m2 comments and strings

regards,
Gaius

Re: .ACCESS_WITH_SIZE and pointer ranges

[Qing Zhao]

> On Apr 11, 2025, at 10:42, Andrew MacLeod  wrote:
> 
> 
> On 4/11/25 10:27, Qing Zhao wrote:
>> 
>>> On Apr 10, 2025, at 11:12, Martin Uecker  wrote:
>>> 
>>> Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
 On 2025-04-10 10:50, Andrew MacLeod wrote:
> Its not clear to me exactly what is being asked, but I think the
> suggestion is that pointer references are being replaced with a builtin
> function called .ACCESS_WITH_SIZE ?and I presume that builtin
> function has some parameters that give you relevant range information of
> some sort?
 Added, not replaced, but yes, that's essentially it.
 
> range-ops is setup to pull range information from builtin functions
> already in gimple-range-op.cc::
> gimple_range_op_handler::maybe_builtin_call ().  We'd just need to write
> a handler for this new one.  You can pull information from 2 operands
> under normal circumstances, but exceptions can be made.I'd need a
> description of what it looks like and how that translates to range info.
 That's perfect!  It's probably redundant for cases where we end up with
 both .ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't remember if
 that's the only place where .ACCESS_WITH_SIZE is generated today.  Qing,
 could you please work with Andrew on this?
>>> BTW, what I would find very interesting is inserting such information
>>> at the points where arrays decay to pointer.
>> Is the following the example?
>> 
>>   1 #include 
>>   2
>>   3 void foo (int arr[]) {
>>   4   // Inside the function, arr is treated as a pointer
>>   5   arr[6] = 10;
>>   6 }
>>   7
>>   8 int my_array[5] = {10, 20, 30, 40, 50};
>>   9
>>  10 int main() {
>>  11   my_array[6] = 6;
>>  12   int *ptr = my_array; // Array decays to pointer here
>>  13   ptr[7] = 7;
>>  14   foo (my_array);
>>  15   16   return 0;
>>  17 }
>> 
>> When I use the latest gcc to compile the above with -Warray-bounds:
>> 
>> []$ gcc -O2 -Warray-bounds t.c
>> t.c: In function ‘main’:
>> t.c:13:6: warning: array subscript 7 is outside array bounds of ‘int[5]’ 
>> [-Warray-bounds=]
>>13 |   ptr[7] = 7;
>>   |   ~~~^~~
>> t.c:8:5: note: at offset 28 into object ‘my_array’ of size 20
>> 8 | int my_array[5] = {10, 20, 30, 40, 50};
>>   | ^~~~
>> In function ‘foo’,
>> inlined from ‘main’ at t.c:14:3:
>> t.c:5:10: warning: array subscript 6 is outside array bounds of ‘int[5]’ 
>> [-Warray-bounds=]
>> 5 |   arr[6] = 10;
>>   |   ~~~^~~~
>> t.c: In function ‘main’:
>> t.c:8:5: note: at offset 24 into object ‘my_array’ of size 20
>> 8 | int my_array[5] = {10, 20, 30, 40, 50};
>>   | ^~~~
>> 
>> Looks like that even after the array decay to pointer, the bound information 
>> is still carried
>> for the decayed pointer somehow (I guess that vrp did this?)
> 
Just tried to disable tree-vrp by adding -fno-tree-vrp, all the above warnings 
disappeared. 

[]$ gcc -O2 -Warray-bounds -fno-tree-vrp t.c
[]$ 
Looks like tree-vrp tracks the bound information for this testing case. 

> No, the behaviour in these warnings is from something else. Although some 
> range info from VRP is used, most of this is tracked by the pointer_query 
> (pointer-query.cc) mechanism that was written a number of years ago before 
> ranger was completed.  It attempts to do its own custom tracking of pointers 
> and what they point to and the size of things they access.

What’s the relationship between pointer_query and VRP? Is pointer_query part of 
VRP? Disable VRP also disable pointer_query?

thanks.

Qing
> 
> There are issues with that code, and the goal is to replace it with rangers 
> prange.  Alas there is enhancement work to prange for that to happen as it 
> doesnt currently track and points to info. That would then be followed by 
> converting the warning code to then use ranger/VRP instead.
> 
>  Any any adjustments to ranger for this are unlikely to affect anything until 
> that work is done, and I do not think anyone is equipped to attempt to update 
> the existing pointer-query code.
> 
> Unfortunately :-(
> 
> Andrew
> 
> 

Re: [PATCH v3] libstdc++: Implement C++26 features (P2546R5)

[Jonathan Wakely]

On Fri, 11 Apr 2025 at 14:47, Jonathan Wakely  wrote:
>
> This includes the P2810R4 (is_debugger_present is_replaceable) changes,
> allowing std::is_debugger_present to be replaced by the program.
>
> It would be good to provide a macOS definition of is_debugger_present as
> per https://developer.apple.com/library/archive/qa/qa1361/_index.html
> but that isn't included in this change.
>
> libstdc++-v3/ChangeLog:
>
> * config.h.in: Regenerate.
> * configure: Regenerate.
> * configure.ac: Check for facilities needed by .
> * include/Makefile.am: Add new header.
> * include/Makefile.in: Regenerate.
> * include/bits/version.def (debugging): Add.
> * include/bits/version.h: Regenerate.
> * src/c++26/Makefile.am: Add new file.
> * src/c++26/Makefile.in: Regenerate.
> * include/std/debugging: New file.
> * src/c++26/debugging.cc: New file.
> * testsuite/19_diagnostics/debugging/breakpoint.cc: New test.
> * testsuite/19_diagnostics/debugging/breakpoint_if_debugging.cc:
> New test.
> * testsuite/19_diagnostics/debugging/is_debugger_present.cc: New
> test.
> * testsuite/19_diagnostics/debugging/is_debugger_present-2.cc:
> New test.
> ---
>
> This v3 patch uses #elif for the SYS_PTRACE_H group, as suggested by
> Tomasz, adds more systemtap probes, and fixes the known debuggers checks
> to match LLDB properly and to match gdbserver. Tested with gdb,
> gdbserver, and lldb on Fedora 41.

Oh, and I also added a test that replaces std::is_debugger_present()
with a program-defined function and verifies that it's called instead
of the one in libstdc++exp.a.

[PATCH] Fix PR target/119673

[Eric Botcazou]

Hi,

this applies the same magic to config/i386/gthr-win32.h that was applied to 
gthr-posix.h (https://gcc.gnu.org/cgit/gcc/commit/?id=6a4d1c374eed17) for the 
sake of C++ modules (thanks to Andrew for the pointer!).

Built for {i686,x86_64}-w64-mingw32, OK for the mainline?


2025-04-11 Eric Botcazou  

libgcc/
PR target/119673
* config/i386/gthr-win32.h (__GTHREAD_ALWAYS_INLINE): New macro.
(__GTHREAD_INLINE): Likewise.
(__GTHR_W32_InterlockedCompareExchange): Delete.
(__gthread_active_p): Mark as __GTHREAD_INLINE instead of
static inline.
(__gthread_create): Likewise.
(__gthread_join): Likewise.
(__gthread_self): Likewise.
(__gthread_detach): Likewise.
(__gthread_equal): Likewise.
(__gthread_yield): Likewise.
(__gthread_once): Likewise.
(__gthread_key_create): Likewise.
(__gthread_key_delete): Likewise.
(__gthread_getspecific): Likewise.
(__gthread_setspecific): Likewise.
(__gthread_mutex_init_function): Likewise.
(__gthread_mutex_destroy): Likewise.
(__gthread_mutex_lock): Likewise.
(__gthread_mutex_trylock): Likewise.
(__gthread_mutex_timedlock): Likewise.
(__gthread_mutex_unlock): Likewise.
(__gthread_recursive_mutex_trylock): Likewise.
(__gthread_cond_init_function): Likewise.
(__gthread_cond_broadcast): Likewise.
(__gthread_cond_signal): Likewise.
(__gthread_cond_wait): Likewise.
(__gthread_cond_timedwait): Likewise.
(__GTHREAD_WIN32_INLINE): Likewise.
(__GTHREAD_WIN32_COND_INLINE): Likewise.
(__gthread_recursive_mutex_init_function): Likewise.
(__gthread_recursive_mutex_destroy): Likewise.
(__gthread_recursive_mutex_lock): Likewise.
(__gthread_recursive_mutex_unlock): Likewise.
(__gthread_cond_destroy): Likewise.
(__gthread_cond_wait_recursive): Likewise.

-- 
Eric Botcazoudiff --git a/libgcc/config/i386/gthr-win32.h b/libgcc/config/i386/gthr-win32.h
index 98e11b42e5c..34988d4c3df 100644
--- a/libgcc/config/i386/gthr-win32.h
+++ b/libgcc/config/i386/gthr-win32.h
@@ -71,6 +71,21 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #error Timed lock primitives are not supported on Windows targets
 #endif
 
+#ifdef __has_attribute
+# if __has_attribute(__always_inline__)
+#  define __GTHREAD_ALWAYS_INLINE __attribute__((__always_inline__))
+# endif
+#endif
+#ifndef __GTHREAD_ALWAYS_INLINE
+# define __GTHREAD_ALWAYS_INLINE
+#endif
+
+#ifdef __cplusplus
+# define __GTHREAD_INLINE inline __GTHREAD_ALWAYS_INLINE
+#else
+# define __GTHREAD_INLINE static inline
+#endif
+
 /* Make sure CONST_CAST2 (origin in system.h) is declared.  */
 #ifndef CONST_CAST2
 #ifdef __cplusplus
@@ -398,11 +413,7 @@ extern int _CRT_MT;
 extern int __mingwthr_key_dtor (unsigned long, void (*) (void *));
 #endif /* _WIN32 && !__CYGWIN__ */
 
-/* __GTHR_W32_InterlockedCompareExchange is left over from win95,
-   which did not support InterlockedCompareExchange. */
-#define __GTHR_W32_InterlockedCompareExchange InterlockedCompareExchange
-
-static inline int
+__GTHREAD_INLINE int
 __gthread_active_p (void)
 {
 #ifdef MINGW32_SUPPORTS_MT_EH
@@ -438,20 +449,20 @@ extern int __gthr_win32_cond_timedwait (__gthread_cond_t *, __gthread_mutex_t *,
 	const __gthread_time_t *);
 #endif
 
-static inline int
+__GTHREAD_INLINE int
 __gthread_create (__gthread_t *__thr, void *(*__func) (void*),
 		  void *__args)
 {
   return __gthr_win32_create (__thr, __func, __args);
 }
 
-static inline int
+__GTHREAD_INLINE int
 __gthread_join (__gthread_t __thr, void **__value_ptr)
 {
   return __gthr_win32_join (__thr, __value_ptr);
 }
 
-static inline __gthread_t
+__GTHREAD_INLINE __gthread_t
 __gthread_self (void)
 {
   return __gthr_win32_self ();
@@ -463,25 +474,25 @@ __gthread_self (void)
Only stubs are exposed to avoid polluting the C++ namespace with
Win32 API definitions.  */
 
-static inline int
+__GTHREAD_INLINE int
 __gthread_detach (__gthread_t __thr)
 {
   return __gthr_win32_detach (__thr);
 }
 
-static inline int
+__GTHREAD_INLINE int
 __gthread_equal (__gthread_t __thr1, __gthread_t __thr2)
 {
   return __gthr_win32_equal (__thr1, __thr2);
 }
 
-static inline int
+__GTHREAD_INLINE int
 __gthread_yield (void)
 {
   return __gthr_win32_yield ();
 }
 
-static inline int
+__GTHREAD_INLINE int
 __gthread_once (__gthread_once_t *__once, void (*__func) (void))
 {
   if (__gthread_active_p ())
@@ -490,43 +501,43 @@ __gthread_once (__gthread_once_t *__once, void (*__func) (void))
 return -1;
 }
 
-static inline int
+__GTHREAD_INLINE int
 __gthread_key_create (__gthread_key_t *__key, void (*__dtor) (void *))
 {
   return __gthr_win32_key_create (__key, __dtor);
 }
 
-static inline int
+__GTHREAD_INLINE int
 __gthread_key_delete (__gthread_key_t __key)
 {
   return __gthr_win32_key_delete (__key);
 }
 
-static inline void 

[PHASE1 PATCH] Use optimize free lists for alloc_pages

[Andi Kleen]

Right now ggc has a single free list for multiple sizes. In some cases
the list can get mixed by orders and then the allocator may spend a lot
of time walking the free list to find the right sizes.

This patch splits the free list into multiple free lists by order
which allows O(1) access in most cases.

It also has a fallback list for sizes not in the free lists
(that seems to be needed for now)

For the PR119387 test case it gives a significant speedup,
both with and without debug information.

Potential drawback might be some more fragmentation in the memory
map, so there is a risk that very large compilations may run into
the vma limit on Linux, or have slightly less coverage with
large pages.

For the PR119387 test case which have extra memory overhead with -ggdb:

  ../obj-fast/gcc/cc1plus-allocpage -std=gnu++20 -O2 pr119387.cc -quiet
ran 1.04 ± 0.01 times faster than ../obj-fast/gcc/cc1plus -std=gnu++20 -O2 
pr119387.cc  -quiet
2.63 ± 0.01 times faster than ../obj-fast/gcc/cc1plus-allocpage 
-std=gnu++20 -O2 pr119387.cc  -quiet -ggdb
2.78 ± 0.01 times faster than ../obj-fast/gcc/cc1plus -std=gnu++20 -O2 
pr119387.cc  -quiet -ggdb

It might also help for other test cases creating a lot of garbage.

gcc/ChangeLog:

PR middle-end/114563
PR c++/119387
* ggc-page.cc (struct free_list): New structure.
(struct page_entry): Point to free_list.
(find_free_list): New function.
(find_free_list_order): Dito.
(alloc_page): Use specific free_list.
(release_pages): Dito.
(do_release_pages): Dito.
(init_ggc): Dito.
(ggc_print_statistics): Print overflow stat.
(ggc_pch_read): Use specific free list.
---
 gcc/ggc-page.cc | 110 
 1 file changed, 92 insertions(+), 18 deletions(-)

diff --git a/gcc/ggc-page.cc b/gcc/ggc-page.cc
index 971b4334b7c2..0f674c0d6d7c 100644
--- a/gcc/ggc-page.cc
+++ b/gcc/ggc-page.cc
@@ -234,6 +234,8 @@ static struct
 }
 inverse_table[NUM_ORDERS];
 
+struct free_list;
+
 /* A page_entry records the status of an allocation page.  This
structure is dynamically sized to fit the bitmap in_use_p.  */
 struct page_entry
@@ -251,6 +253,9 @@ struct page_entry
  of the host system page size.)  */
   size_t bytes;
 
+  /* Free list of this page size.  */
+  struct free_list *free_list;
+
   /* The address at which the memory is allocated.  */
   char *page;
 
@@ -368,6 +373,15 @@ struct free_object
 };
 #endif
 
+constexpr int num_free_list = 8;
+
+/* A free_list for pages with BYTES size.  */
+struct free_list
+{
+  size_t bytes;
+  page_entry *free_pages;
+};
+
 /* The rest of the global variables.  */
 static struct ggc_globals
 {
@@ -412,8 +426,8 @@ static struct ggc_globals
   int dev_zero_fd;
 #endif
 
-  /* A cache of free system pages.  */
-  page_entry *free_pages;
+  /* A cache of free system pages. Entry 0 is fallback.  */
+  struct free_list free_lists[num_free_list];
 
 #ifdef USING_MALLOC_PAGE_GROUPS
   page_group *page_groups;
@@ -488,6 +502,9 @@ static struct ggc_globals
 
 /* The overhead for each of the allocation orders.  */
 unsigned long long total_overhead_per_order[NUM_ORDERS];
+
+/* Number of fallbacks.  */
+unsigned long long fallback;
   } stats;
 } G;
 
@@ -754,6 +771,42 @@ clear_page_group_in_use (page_group *group, char *page)
 }
 #endif
 
+/* Find a free list for ENTRY_SIZE.  */
+
+static inline struct free_list *
+find_free_list (size_t entry_size)
+{
+  int i;
+  for (i = 1; i < num_free_list; i++)
+{
+  if (G.free_lists[i].bytes == entry_size)
+   return &G.free_lists[i];
+  if (G.free_lists[i].bytes == 0)
+   {
+ G.free_lists[i].bytes = entry_size;
+ return &G.free_lists[i];
+   }
+}
+  /* Fallback. Does this happen?  */
+  if (GATHER_STATISTICS)
+G.stats.fallback++;
+  return &G.free_lists[0];
+}
+
+/* Fast lookup of free_list by order.  */
+
+static struct free_list *cache_free_list[NUM_ORDERS];
+
+/* Faster way to find a free list by ORDER for BYTES.  */
+
+static inline struct free_list *
+find_free_list_order (unsigned order, size_t bytes)
+{
+  if (cache_free_list[order] == NULL)
+cache_free_list[order] = find_free_list (bytes);
+  return cache_free_list[order];
+}
+
 /* Allocate a new page for allocating objects of size 2^ORDER,
and return an entry for it.  The entry is not added to the
appropriate page_table list.  */
@@ -770,6 +823,7 @@ alloc_page (unsigned order)
 #ifdef USING_MALLOC_PAGE_GROUPS
   page_group *group;
 #endif
+  struct free_list *free_list;
 
   num_objects = OBJECTS_PER_PAGE (order);
   bitmap_size = BITMAP_SIZE (num_objects + 1);
@@ -782,8 +836,10 @@ alloc_page (unsigned order)
   entry = NULL;
   page = NULL;
 
+  free_list = find_free_list_order (order, entry_size);
+
   /* Check the list of free pages for one we can use.  */
-  for (pp = &G.free_pages, p = *pp; p; pp = &p->next, p = *pp)
+  f

[PATCH] Add diffsummary.py to contrib

[Andi Kleen]

This adds an automatic downloader for the latest test results from
the mailing list archive and supports diffing test_summary to it.
Useful if you don't want to run your own baseline.

contrib/ChangeLog:

* diffsummary.py: New file.
---
 contrib/diffsummary.py | 104 +
 1 file changed, 104 insertions(+)
 create mode 100755 contrib/diffsummary.py

diff --git a/contrib/diffsummary.py b/contrib/diffsummary.py
new file mode 100755
index ..0a666707272e
--- /dev/null
+++ b/contrib/diffsummary.py
@@ -0,0 +1,104 @@
+#!/usr/bin/env python3
+# Show or diff test_summary output to latest posted test result for a platform
+# test_summary -t | diffsummary.py (compare test result from current build to 
last posted)
+# diffsummary.py --show (only show last posted)
+from urllib.request import urlopen
+from urllib.error import URLError
+from html.parser import HTMLParser
+import time
+import re
+import argparse
+import platform
+import tempfile
+import os
+import sys
+
+baseurl = "https://gcc.gnu.org/pipermail/gcc-testresults/";
+
+ap = argparse.ArgumentParser(description="Diff stdin to latest posted test 
result and set exit code to result")
+ap.add_argument("--branch", default="experimental",
+help="Branch to match (regex substring match)")
+ap.add_argument("--arch", default=platform.machine() + ".*" + 
platform.system().lower(),
+help="architecture to match (regex substring match)")
+ap.add_argument("--retrytime", default=1, type=int,
+help="time to wait before fetching next page (fractional 
seconds)")
+ap.add_argument("--show", help="Show last test result, but do not diff", 
action="store_true", default=False)
+ap.add_argument("--url", help="Show URLs downloaded", action="store_true")
+ap.add_argument("--diff", help="Diff program to use (default diff)", 
default="diff")
+ap.add_argument("--diff-args", help="Diff arguments to use (default -u)", 
default="-u")
+ap.add_argument("--skip", type=int, default=0, help="Skip first N posted test 
results")
+args = ap.parse_args()
+
+class ParseMonths(HTMLParser):
+def __init__(self):
+super().__init__()
+self.months = []
+def handle_starttag(self, tag, attrs):
+if tag == "a" and "thread.html" in attrs[0][1]:
+self.months.append(attrs[0][1])
+
+class ParseThread(HTMLParser):
+def __init__(self):
+super().__init__()
+self.link = None
+self.target = []
+def handle_starttag(self, tag, attrs):
+if (tag == "a"
+and attrs[0][1][0].isdigit()
+and attrs[0][1].endswith(".html")):
+self.link = attrs[0][1]
+else:
+self.link = None
+def handle_data(self, data):
+if (self.link
+and re.search(args.branch, data)
+and re.search(args.arch, data)):
+self.target.append(thread.link)
+
+class ParseArticle(HTMLParser):
+def __init__(self):
+super().__init__()
+self.contents = None
+self.pre = False
+self.data = None
+def handle_starttag(self, tag, attrs):
+self.pre = tag == "pre"
+def handle_data(self, data):
+if self.pre and not self.data:
+self.data = data
+
+def my_urlopen(url):
+if args.url:
+print(url)
+return urlopen(url)
+
+with my_urlopen(baseurl) as index:
+months = ParseMonths()
+months.feed(index.read().decode('utf-8'))
+if len(months.months) == 0:
+sys.exit("no months found")
+for month in months.months:
+with my_urlopen(baseurl + month) as m:
+thread = ParseThread()
+thread.feed(m.read().decode('utf-8'))
+if thread.target:
+if args.skip > len(thread.target):
+args.skip -= len(thread.target)
+continue
+url = (baseurl + month).replace("thread.html", thread.target[-1 - 
args.skip])
+with my_urlopen(url) as t:
+article = ParseArticle()
+article.feed(t.read().decode('utf-8'))
+if args.show:
+print(article.data)
+break
+with tempfile.NamedTemporaryFile(delete=False) as tf:
+tf.write(article.data.encode('utf-8'))
+tf.close()
+cmd = f"{args.diff} {args.diff_args} - {tf.name}"
+print(cmd)
+ret = os.system(cmd)
+os.unlink(tf.name)
+sys.exit(ret)
+break
+time.sleep(args.retrytime)
-- 
2.49.0

Re: [PATCH V2] RISC-V: Add support for Zalasr extension

[Andrea Parri]

On Thu, Apr 10, 2025 at 02:48:36PM -0700, Edwin Lu wrote:
> [1] https://github.com/riscv/riscv-zalasr
> 
> Add minimal support for the zalasr (load-acquire/store-release)
> extension
> 
> Currently there is no toggle to opt into the abi-breaking note 3
> mappings in the PSABI doc so support for that has been omitted from this
> patch.
> 
> gcc/ChangeLog:
> 
>   * common/config/riscv/riscv-common.cc: Recognize zalasr.
>   * config/riscv/riscv.opt: Ditto.
>   * config/riscv/sync-rvwmo.md: Add check for zalasr.
>   * config/riscv/sync-ztso.md: Ditto
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/riscv/amo/a-rvwmo-fence.c: Disable zalasr from
> march if exists.
>   * gcc.target/riscv/amo/a-rvwmo-load-acquire.c: Ditto.
>   * gcc.target/riscv/amo/a-rvwmo-load-relaxed.c: Ditto.
>   * gcc.target/riscv/amo/a-rvwmo-load-seq-cst.c: Ditto.
>   * gcc.target/riscv/amo/a-rvwmo-store-compat-seq-cst.c: Ditto.
>   * gcc.target/riscv/amo/a-rvwmo-store-relaxed.c: Ditto.
>   * gcc.target/riscv/amo/a-rvwmo-store-release.c: Ditto.
>   * gcc.target/riscv/amo/a-ztso-fence.c: Ditto.
>   * gcc.target/riscv/amo/a-ztso-load-acquire.c:
>   * gcc.target/riscv/amo/a-ztso-load-relaxed.c: Ditto.
>   * gcc.target/riscv/amo/a-ztso-load-seq-cst.c: Ditto.
>   * gcc.target/riscv/amo/a-ztso-store-compat-seq-cst.c: Ditto.
>   * gcc.target/riscv/amo/a-ztso-store-relaxed.c: Ditto.
>   * gcc.target/riscv/amo/a-ztso-store-release.c: Ditto.
>   * gcc.target/riscv/amo/zaamo-ztso-amo-add-int.c: Ditto.
>   * gcc.target/riscv/amo/zabha-ztso-amo-add-char.c: Ditto.
>   * gcc.target/riscv/amo/zabha-ztso-amo-add-short.c: Ditto.
>   * gcc.target/riscv/amo/zacas-ztso-compare-exchange-char-seq-cst.c: 
> Ditto.
>   * gcc.target/riscv/amo/zacas-ztso-compare-exchange-char.c:
> Ditto.
>   * 
> gcc.target/riscv/amo/zacas-ztso-compare-exchange-compatability-mapping-no-fence.c:
>  Ditto.
>   * 
> gcc.target/riscv/amo/zacas-ztso-compare-exchange-compatability-mapping.cc: 
> Ditto.
>   * gcc.target/riscv/amo/zacas-ztso-compare-exchange-int-seq-cst.c: Ditto.
>   * gcc.target/riscv/amo/zacas-ztso-compare-exchange-int.c: Ditto.
>   * gcc.target/riscv/amo/zacas-ztso-compare-exchange-short-seq-cst.c: 
> Ditto.
>   * gcc.target/riscv/amo/zacas-ztso-compare-exchange-short.c:
> Ditto.
>   * gcc.target/riscv/amo/zalrsc-ztso-amo-add-int.c: Ditto.
>   * 
> gcc.target/riscv/amo/zalrsc-ztso-compare-exchange-int-acquire-release.c: 
> Ditto.
>   * gcc.target/riscv/amo/zalrsc-ztso-compare-exchange-int-acquire.c: 
> Ditto.
>   * gcc.target/riscv/amo/zalrsc-ztso-compare-exchange-int-consume.c: 
> Ditto.
>   * gcc.target/riscv/amo/zalrsc-ztso-compare-exchange-int-relaxed.c: 
> Ditto.
>   * gcc.target/riscv/amo/zalrsc-ztso-compare-exchange-int-release.c: 
> Ditto.
>   * 
> gcc.target/riscv/amo/zalrsc-ztso-compare-exchange-int-seq-cst-relaxed.c: 
> Ditto.
>   * gcc.target/riscv/amo/zalrsc-ztso-compare-exchange-int-seq-cst.c: 
> Ditto.
>   * gcc.target/riscv/amo/zalrsc-ztso-subword-amo-add-char-acq-rel.c: 
> Ditto.
>   * gcc.target/riscv/amo/zalrsc-ztso-subword-amo-add-char-acquire.c: 
> Ditto.
>   * gcc.target/riscv/amo/zalrsc-ztso-subword-amo-add-char-relaxed.c: 
> Ditto.
>   * gcc.target/riscv/amo/zalrsc-ztso-subword-amo-add-char-release.c: 
> Ditto.
>   * gcc.target/riscv/amo/zalrsc-ztso-subword-amo-add-char-seq-cst.c: 
> Ditto.
>   * lib/target-supports.exp: Add zalasr checks.
>   * gcc.target/riscv/amo/zalasr-rvwmo-load-acquire.c: New test.
>   * gcc.target/riscv/amo/zalasr-rvwmo-load-relaxed.c: New test.
>   * gcc.target/riscv/amo/zalasr-rvwmo-load-seq-cst.c: New test.
>   * gcc.target/riscv/amo/zalasr-rvwmo-store-compat-seq-cst.c: New test.
>   * gcc.target/riscv/amo/zalasr-rvwmo-store-relaxed.c: New test.
>   * gcc.target/riscv/amo/zalasr-rvwmo-store-release.c: New test.
>   * gcc.target/riscv/amo/zalasr-ztso-load-acquire.c: New test.
>   * gcc.target/riscv/amo/zalasr-ztso-load-relaxed.c: New test.
>   * gcc.target/riscv/amo/zalasr-ztso-load-seq-cst.c: New test.
>   * gcc.target/riscv/amo/zalasr-ztso-store-compat-seq-cst.c: New test.
>   * gcc.target/riscv/amo/zalasr-ztso-store-relaxed.c: New test.
>   * gcc.target/riscv/amo/zalasr-ztso-store-release.c: New test.
> 
> Signed-off-by: Edwin Lu 
> ---
> v2: fix ztso mappings
> - Removed .aq annotation on load acquire
> - Removed .rl annotation on store release

LGTM,

Reviewed-by: Andrea Parri 

  Andrea

Re: .ACCESS_WITH_SIZE and pointer ranges

[Andrew MacLeod]

On 4/11/25 11:36, Qing Zhao wrote:



On Apr 11, 2025, at 10:42, Andrew MacLeod  wrote:


On 4/11/25 10:27, Qing Zhao wrote:

On Apr 10, 2025, at 11:12, Martin Uecker  wrote:

Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:

On 2025-04-10 10:50, Andrew MacLeod wrote:

Its not clear to me exactly what is being asked, but I think the
suggestion is that pointer references are being replaced with a builtin
function called .ACCESS_WITH_SIZE ?and I presume that builtin
function has some parameters that give you relevant range information of
some sort?

Added, not replaced, but yes, that's essentially it.


range-ops is setup to pull range information from builtin functions
already in gimple-range-op.cc::
gimple_range_op_handler::maybe_builtin_call ().  We'd just need to write
a handler for this new one.  You can pull information from 2 operands
under normal circumstances, but exceptions can be made.I'd need a
description of what it looks like and how that translates to range info.

That's perfect!  It's probably redundant for cases where we end up with
both .ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't remember if
that's the only place where .ACCESS_WITH_SIZE is generated today.  Qing,
could you please work with Andrew on this?

BTW, what I would find very interesting is inserting such information
at the points where arrays decay to pointer.

Is the following the example?

   1 #include 
   2
   3 void foo (int arr[]) {
   4   // Inside the function, arr is treated as a pointer
   5   arr[6] = 10;
   6 }
   7
   8 int my_array[5] = {10, 20, 30, 40, 50};
   9
  10 int main() {
  11   my_array[6] = 6;
  12   int *ptr = my_array; // Array decays to pointer here
  13   ptr[7] = 7;
  14   foo (my_array);
  15   16   return 0;
  17 }

When I use the latest gcc to compile the above with -Warray-bounds:

[]$ gcc -O2 -Warray-bounds t.c
t.c: In function ‘main’:
t.c:13:6: warning: array subscript 7 is outside array bounds of ‘int[5]’ 
[-Warray-bounds=]
13 |   ptr[7] = 7;
   |   ~~~^~~
t.c:8:5: note: at offset 28 into object ‘my_array’ of size 20
 8 | int my_array[5] = {10, 20, 30, 40, 50};
   | ^~~~
In function ‘foo’,
 inlined from ‘main’ at t.c:14:3:
t.c:5:10: warning: array subscript 6 is outside array bounds of ‘int[5]’ 
[-Warray-bounds=]
 5 |   arr[6] = 10;
   |   ~~~^~~~
t.c: In function ‘main’:
t.c:8:5: note: at offset 24 into object ‘my_array’ of size 20
 8 | int my_array[5] = {10, 20, 30, 40, 50};
   | ^~~~

Looks like that even after the array decay to pointer, the bound information is 
still carried
for the decayed pointer somehow (I guess that vrp did this?)

Just tried to disable tree-vrp by adding -fno-tree-vrp, all the above warnings 
disappeared.

[]$ gcc -O2 -Warray-bounds -fno-tree-vrp t.c
[]$
Looks like tree-vrp tracks the bound information for this testing case.


tree vrp for pointers mostly tracks non-nullness, although it does 
provide some range tweaks  THe VRP pass itself does some points to , but 
that info never escapes the VRP passes.  It






No, the behaviour in these warnings is from something else. Although some range 
info from VRP is used, most of this is tracked by the pointer_query 
(pointer-query.cc) mechanism that was written a number of years ago before 
ranger was completed.  It attempts to do its own custom tracking of pointers 
and what they point to and the size of things they access.

What’s the relationship between pointer_query and VRP? Is pointer_query part of 
VRP? Disable VRP also disable pointer_query?

the pointer_query work is standalone and hacked on top of VRP ranges..  
It attempts to track points-to and bounds information for memory refs so 
it can be used to warn about potential issues.    It then combines this 
information with queries into VRP to determine access ranges and 
compares them to what it thinks is valid..   It then makes some 
decisions that depend on range patterns that were true when it was 
written .  For instance, if a range terminates with +INF, it usually 
assumes VRP doesnt know anything about the range, and so therefore 
elects not to warn because no range info is useful.


When  ranger was turned on, we started producing more precise ranges. 
Although there are many cases where we still don't really know anything 
useful about the range, those patterns changed... ie, perhaps the range 
is now [3, +INF - 4] .. so pointer-query code  decides  "This range does 
not extend to +INF, so it must be good range info, and this access  
might be out of bounds, so I better warn".


That is one of the reasons why  turning VRP off makes some warning go 
away, because without range into , most ranges will be [-INF, +INF] and 
therefore the warning code doesnt trigger because it matches the pattern 
of "the range doesn't tell us anything useful"


That being said, no one currently working on GCC really understands the 
intricacies of this interaction.. The code

Re: .ACCESS_WITH_SIZE and pointer ranges

[Qing Zhao]

> On Apr 11, 2025, at 10:53, Martin Uecker  wrote:
> 
> Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod:
>> On 4/11/25 10:27, Qing Zhao wrote:
>>> 
 On Apr 10, 2025, at 11:12, Martin Uecker  wrote:
 
 Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
> On 2025-04-10 10:50, Andrew MacLeod wrote:
>> Its not clear to me exactly what is being asked, but I think the
>> suggestion is that pointer references are being replaced with a builtin
>> function called .ACCESS_WITH_SIZE ?and I presume that builtin
>> function has some parameters that give you relevant range information of
>> some sort?
> Added, not replaced, but yes, that's essentially it.
> 
>> range-ops is setup to pull range information from builtin functions
>> already in gimple-range-op.cc::
>> gimple_range_op_handler::maybe_builtin_call ().  We'd just need to write
>> a handler for this new one.  You can pull information from 2 operands
>> under normal circumstances, but exceptions can be made.I'd need a
>> description of what it looks like and how that translates to range info.
> That's perfect!  It's probably redundant for cases where we end up with
> both .ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't remember if
> that's the only place where .ACCESS_WITH_SIZE is generated today.  Qing,
> could you please work with Andrew on this?
 BTW, what I would find very interesting is inserting such information
 at the points where arrays decay to pointer.
>>> Is the following the example?
>>> 
>>>   1 #include 
>>>   2
>>>   3 void foo (int arr[]) {
>>>   4   // Inside the function, arr is treated as a pointer
>>>   5   arr[6] = 10;
>>>   6 }
>>>   7
>>>   8 int my_array[5] = {10, 20, 30, 40, 50};
>>>   9
>>>  10 int main() {
>>>  11   my_array[6] = 6;
>>>  12   int *ptr = my_array; // Array decays to pointer here
>>>  13   ptr[7] = 7;
>>>  14   foo (my_array);
>>>  15   16   return 0;
>>>  17 }
>>> 
>>> When I use the latest gcc to compile the above with -Warray-bounds:
>>> 
>>> []$ gcc -O2 -Warray-bounds t.c
>>> t.c: In function ‘main’:
>>> t.c:13:6: warning: array subscript 7 is outside array bounds of ‘int[5]’ 
>>> [-Warray-bounds=]
>>>13 |   ptr[7] = 7;
>>>   |   ~~~^~~
>>> t.c:8:5: note: at offset 28 into object ‘my_array’ of size 20
>>> 8 | int my_array[5] = {10, 20, 30, 40, 50};
>>>   | ^~~~
>>> In function ‘foo’,
>>> inlined from ‘main’ at t.c:14:3:
>>> t.c:5:10: warning: array subscript 6 is outside array bounds of ‘int[5]’ 
>>> [-Warray-bounds=]
>>> 5 |   arr[6] = 10;
>>>   |   ~~~^~~~
>>> t.c: In function ‘main’:
>>> t.c:8:5: note: at offset 24 into object ‘my_array’ of size 20
>>> 8 | int my_array[5] = {10, 20, 30, 40, 50};
>>>   | ^~~~
>>> 
>>> Looks like that even after the array decay to pointer, the bound 
>>> information is still carried
>>> for the decayed pointer somehow (I guess that vrp did this?)
>> 
>> No, the behaviour in these warnings is from something else. Although 
>> some range info from VRP is used, most of this is tracked by the 
>> pointer_query (pointer-query.cc) mechanism that was written a number of 
>> years ago before ranger was completed.  It attempts to do its own custom 
>> tracking of pointers and what they point to and the size of things they 
>> access.
>> 
>> There are issues with that code, and the goal is to replace it with 
>> rangers prange.  Alas there is enhancement work to prange for that to 
>> happen as it doesnt currently track and points to info. That would then 
>> be followed by converting the warning code to then use ranger/VRP instead.
>> 
>>  Any any adjustments to ranger for this are unlikely to affect anything 
>> until that work is done, and I do not think anyone is equipped to 
>> attempt to update the existing pointer-query code.
>> 
>> Unfortunately :-(
> 
> Examples I have in mind for the .ACCESS_WITH_SIZE are the
> following two:
> 
> struct foo {
> 
>char arr[3];
>int b;
> };
> 
> void f(struct foo x)
> {
>char *ptr = x.arr;
>ptr[4] = 10;
> }

The above is an example about decaying a field array of a structure to a 
pointer. 

Yes, usually tracking and keeping the bound info for a field is harder than a 
regular variable,
However, I think it’s still possible to improve compiler analysis to do this 
since the original bound
info is in the code. 

> 
> void g(char (*arr)[4])
> {
>char *ptr = *arr;
>ptr[4] = 1;
> }
> 

The above example is about decaying a formal parameter array to a pointer. 
I think that since the bound information is in the code too, the current 
compiler analysis should be
able to be improved to catch such case. 

For the above two cases, the current compiler analysis is not able to propagate 
the bound information,
But since the bound info already in the code, it’s possible to improve the 
current compiler analysis to 
propagate such informat

Re: .ACCESS_WITH_SIZE and pointer ranges

[Martin Uecker]

Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao:
> 
> > On Apr 11, 2025, at 10:53, Martin Uecker  wrote:
> > 
> > Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod:
> > > On 4/11/25 10:27, Qing Zhao wrote:
> > > > 
> > > > > On Apr 10, 2025, at 11:12, Martin Uecker  wrote:
> > > > > 
> > > > > Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh 
> > > > > Poyarekar:
> > > > > > On 2025-04-10 10:50, Andrew MacLeod wrote:
> > > > > > > Its not clear to me exactly what is being asked, but I think the
> > > > > > > suggestion is that pointer references are being replaced with a 
> > > > > > > builtin
> > > > > > > function called .ACCESS_WITH_SIZE ?and I presume that builtin
> > > > > > > function has some parameters that give you relevant range 
> > > > > > > information of
> > > > > > > some sort?
> > > > > > Added, not replaced, but yes, that's essentially it.
> > > > > > 
> > > > > > > range-ops is setup to pull range information from builtin 
> > > > > > > functions
> > > > > > > already in gimple-range-op.cc::
> > > > > > > gimple_range_op_handler::maybe_builtin_call ().  We'd just need 
> > > > > > > to write
> > > > > > > a handler for this new one.  You can pull information from 2 
> > > > > > > operands
> > > > > > > under normal circumstances, but exceptions can be made.I'd 
> > > > > > > need a
> > > > > > > description of what it looks like and how that translates to 
> > > > > > > range info.
> > > > > > That's perfect!  It's probably redundant for cases where we end up 
> > > > > > with
> > > > > > both .ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't 
> > > > > > remember if
> > > > > > that's the only place where .ACCESS_WITH_SIZE is generated today.  
> > > > > > Qing,
> > > > > > could you please work with Andrew on this?
> > > > > BTW, what I would find very interesting is inserting such information
> > > > > at the points where arrays decay to pointer.
> > > > Is the following the example?
> > > > 
> > > >   1 #include 
> > > >   2
> > > >   3 void foo (int arr[]) {
> > > >   4   // Inside the function, arr is treated as a pointer
> > > >   5   arr[6] = 10;
> > > >   6 }
> > > >   7
> > > >   8 int my_array[5] = {10, 20, 30, 40, 50};
> > > >   9
> > > >  10 int main() {
> > > >  11   my_array[6] = 6;
> > > >  12   int *ptr = my_array; // Array decays to pointer here
> > > >  13   ptr[7] = 7;
> > > >  14   foo (my_array);
> > > >  15   16   return 0;
> > > >  17 }
> > > > 
> > > > When I use the latest gcc to compile the above with -Warray-bounds:
> > > > 
> > > > []$ gcc -O2 -Warray-bounds t.c
> > > > t.c: In function ‘main’:
> > > > t.c:13:6: warning: array subscript 7 is outside array bounds of 
> > > > ‘int[5]’ [-Warray-bounds=]
> > > >13 |   ptr[7] = 7;
> > > >   |   ~~~^~~
> > > > t.c:8:5: note: at offset 28 into object ‘my_array’ of size 20
> > > > 8 | int my_array[5] = {10, 20, 30, 40, 50};
> > > >   | ^~~~
> > > > In function ‘foo’,
> > > > inlined from ‘main’ at t.c:14:3:
> > > > t.c:5:10: warning: array subscript 6 is outside array bounds of 
> > > > ‘int[5]’ [-Warray-bounds=]
> > > > 5 |   arr[6] = 10;
> > > >   |   ~~~^~~~
> > > > t.c: In function ‘main’:
> > > > t.c:8:5: note: at offset 24 into object ‘my_array’ of size 20
> > > > 8 | int my_array[5] = {10, 20, 30, 40, 50};
> > > >   | ^~~~
> > > > 
> > > > Looks like that even after the array decay to pointer, the bound 
> > > > information is still carried
> > > > for the decayed pointer somehow (I guess that vrp did this?)
> > > 
> > > No, the behaviour in these warnings is from something else. Although 
> > > some range info from VRP is used, most of this is tracked by the 
> > > pointer_query (pointer-query.cc) mechanism that was written a number of 
> > > years ago before ranger was completed.  It attempts to do its own custom 
> > > tracking of pointers and what they point to and the size of things they 
> > > access.
> > > 
> > > There are issues with that code, and the goal is to replace it with 
> > > rangers prange.  Alas there is enhancement work to prange for that to 
> > > happen as it doesnt currently track and points to info. That would then 
> > > be followed by converting the warning code to then use ranger/VRP instead.
> > > 
> > >  Any any adjustments to ranger for this are unlikely to affect anything 
> > > until that work is done, and I do not think anyone is equipped to 
> > > attempt to update the existing pointer-query code.
> > > 
> > > Unfortunately :-(
> > 
> > Examples I have in mind for the .ACCESS_WITH_SIZE are the
> > following two:
> > 
> > struct foo {
> > 
> >char arr[3];
> >int b;
> > };
> > 
> > void f(struct foo x)
> > {
> >char *ptr = x.arr;
> >ptr[4] = 10;
> > }
> 
> The above is an example about decaying a field array of a structure to a 
> pointer. 
> 
> Yes, usually tracking and keeping the bound info for a field is harder than a 
> regular variable,
> However, I 

[patch, Fortran] Fix PR 119669

[Thomas Koenig]

Hello world,

the attached patch fixes an ICE by setting the typespec of a dummy
argument from a global function if known. plus setting the correct flag.
This also removes the corresponding assert.  I'm not quite sure that the
code with the subroutine attribute can be reached, but I thought better
safe than sorry.

Most of the patch is actually reformatting due to the 80-column-rule.
(Do we really want to keep that for gfortran?)

Regression-tested. OK for trunk?

Best regards

Thomas

Fix ICE in compare_parameter.

gcc/fortran/ChangeLog:

PR fortran/119669
* interface.cc (compare_parameter): Error when mismatch between
formal argument as subroutine and function.  If the dummy
argument is a known function, set its typespec.

gcc/testsuite/ChangeLog:

PR fortran/119669
* gfortran.dg/interface_59.f90: New test.
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index 6258a41cb59..8c4b3b62e5b 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -2534,16 +2534,33 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
 		  gfc_find_symbol (actual_name, gsym->ns, 0, &global_asym);
 		  if (global_asym != NULL)
 		{
-		  gcc_assert (formal->attr.function);
-		  if (!gfc_compare_types (&global_asym->ts, &formal->ts))
+		  if (formal->attr.subroutine)
 			{
-			  gfc_error ("Type mismatch at %L passing global "
- "function %qs declared at %L (%s/%s)",
- &actual->where, actual_name, &gsym->where,
- gfc_typename (&global_asym->ts),
- gfc_dummy_typename (&formal->ts));
+			  gfc_error ("Mismatch between subroutine and and "
+ "function at %L", &actual->where);
 			  return false;
 			}
+		  else if (formal->attr.function)
+			{
+			  if (!gfc_compare_types (&global_asym->ts,
+		  &formal->ts))
+			{
+			  gfc_error ("Type mismatch at %L passing global "
+	 "function %qs declared at %L (%s/%s)",
+	 &actual->where, actual_name,
+	 &gsym->where,
+	 gfc_typename (&global_asym->ts),
+	 gfc_dummy_typename (&formal->ts));
+			  return false;
+			}
+			}
+		  else
+			{
+			  /* The global symbol is a function.  Set the formal
+			 argument acordingly.  */
+			  formal->attr.function = 1;
+			  formal->ts = global_asym->ts;
+			}
 		}
 		}
 	}
diff --git a/gcc/testsuite/gfortran.dg/interface_59.f90 b/gcc/testsuite/gfortran.dg/interface_59.f90
new file mode 100644
index 000..c9ccd67f1a1
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/interface_59.f90
@@ -0,0 +1,15 @@
+! { dg-do compile }
+! PR fortran/119669 - this used to generate an ICE.
+
+program a
+  implicit real(a-h,o-z)
+  external abstract_caller, caller, func
+!  real func
+  call abstract_caller (caller, func, 1.5)
+  call abstract_caller (caller, func, 1.5)
+end program a
+
+function func (x)
+  real func, x
+  func = x * x - 1.
+end

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

[Rainer Orth]

Andreas Schwab  writes:

> On Apr 11 2025, Rainer Orth wrote:
>
>> All users of symbols.h fail to compile on Solaris:
>>
>> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope:
>> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1365:13: error: ‘NAME_MAX’ 
>> was not declared in this scope
>>  1365 |   char name[NAME_MAX];
>>   | ^~~~
>>
>> NAME_MAX being undefined is allowed by POSIX.1, actually: it's listed
>> for  under "Pathname Variable Values":
>
> It doesn't look like this member is accociated with file names at all.

You're right: seems to be all about COBOL function names.  No idea what
value is appropriate/required here, though.

Rainer

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

Re: [PATCH] testsuite: arm: rename arm_v8_1_lob_ok into arm_v8_1_lob_hw

[Christophe Lyon]

Hi!

On Thu, 10 Apr 2025 at 19:13, Richard Earnshaw (lists)
 wrote:
>
> On 10/04/2025 14:55, Christophe Lyon wrote:
> > All arm effective-targets using check_runtime use the "_hw" or
> > "_multilib" suffix, so rename arm_v8_1_lob_ok into arm_v8_1_lob_hw for
> > consistency.
> >
> > gcc/testsuite/ChangeLog
> >
> >   * lib/target-supports.exp: Rename arm_v8_1_lob_ok into
> >   arm_v8_1_lob_hw.
> >   * gcc.target/arm/lob1.c: Likewise.
> >   * gcc.target/arm/lob6.c: Likewise.
>
> Since you're changing that, would you mind making the name arm_v8_1m_lob_hw?  
> Although LOB is specific to
> Armv8.1-m, it's not very obvious if you're not familiar with the many 
> architecture extensions.
>
> OK with that change.
>

Good point.
Your remark made me notice that the callers of arm_v8_1m_lob_hw were
also "v8_1", so I renamed them as attached.

Thanks,

Christophe

> R.
>
> > ---
> >  gcc/testsuite/gcc.target/arm/lob1.c   | 2 +-
> >  gcc/testsuite/gcc.target/arm/lob6.c   | 2 +-
> >  gcc/testsuite/lib/target-supports.exp | 6 +++---
> >  3 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/lob1.c 
> > b/gcc/testsuite/gcc.target/arm/lob1.c
> > index c8ce653a5c3..b97dafa3512 100644
> > --- a/gcc/testsuite/gcc.target/arm/lob1.c
> > +++ b/gcc/testsuite/gcc.target/arm/lob1.c
> > @@ -1,7 +1,7 @@
> >  /* Check that GCC generates Armv8.1-M low over head loop instructions
> > for some simple loops.  */
> >  /* { dg-do run } */
> > -/* { dg-require-effective-target arm_v8_1_lob_ok } */
> > +/* { dg-require-effective-target arm_v8_1_lob_hw } */
> >  /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
> > "-mcpu=*" } } */
> >  /* { dg-options "-march=armv8.1-m.main -mthumb -O3 --save-temps" } */
> >  #include 
> > diff --git a/gcc/testsuite/gcc.target/arm/lob6.c 
> > b/gcc/testsuite/gcc.target/arm/lob6.c
> > index 4fe116e2c2b..cef9d93ee4d 100644
> > --- a/gcc/testsuite/gcc.target/arm/lob6.c
> > +++ b/gcc/testsuite/gcc.target/arm/lob6.c
> > @@ -1,7 +1,7 @@
> >  /* Check that GCC generates Armv8.1-M low over head loop instructions
> > with some less trivial loops and the result is correct.  */
> >  /* { dg-do run } */
> > -/* { dg-require-effective-target arm_v8_1_lob_ok } */
> > +/* { dg-require-effective-target arm_v8_1_lob_hw } */
> >  /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
> > "-mcpu=*" } } */
> >  /* { dg-options "-march=armv8.1-m.main -mthumb -O3 --save-temps" } */
> >  #include 
> > diff --git a/gcc/testsuite/lib/target-supports.exp 
> > b/gcc/testsuite/lib/target-supports.exp
> > index bc4361d6092..d8e28db45de 100644
> > --- a/gcc/testsuite/lib/target-supports.exp
> > +++ b/gcc/testsuite/lib/target-supports.exp
> > @@ -13562,7 +13562,7 @@ proc 
> > check_effective_target_arm_v8_3a_bkey_directive { } {
> >  # Return 1 if the target supports executing the Armv8.1-M Mainline Low
> >  # Overhead Loop, 0 otherwise.  The test is valid for ARM.
> >
> > -proc check_effective_target_arm_v8_1_lob_ok { } {
> > +proc check_effective_target_arm_v8_1_lob_hw { } {
> >  if { ![check_effective_target_arm_cortex_m] } {
> >   return 0;
> >  } else {
> > @@ -13588,7 +13588,7 @@ proc check_effective_target_arm_v8_1_lob_ok { } {
> >
> >  proc check_effective_target_arm_thumb2_no_arm_v8_1_lob { } {
> >  if { [check_effective_target_arm_thumb2]
> > -  && ![check_effective_target_arm_v8_1_lob_ok] } {
> > +  && ![check_effective_target_arm_v8_1_lob_hw] } {
> >   return 1
> >  }
> >  return 0
> > @@ -13600,7 +13600,7 @@ proc 
> > check_effective_target_arm_thumb2_no_arm_v8_1_lob { } {
> >
> >  proc check_effective_target_arm_thumb2_ok_no_arm_v8_1_lob { } {
> >  if { [check_effective_target_arm_thumb2_ok]
> > -  && ![check_effective_target_arm_v8_1_lob_ok] } {
> > +  && ![check_effective_target_arm_v8_1_lob_hw] } {
> >   return 1
> >  }
> >  return 0
>
commit 1059695c96da8a53806109f97d1dce455a252496
Author: Christophe Lyon 
Date:   Thu Apr 10 13:39:23 2025 +

testsuite: arm: rename arm_v8_1_lob_ok into arm_v8_1m_lob_hw

All arm effective-targets using check_runtime use the "_hw" or
"_multilib" suffix, so rename arm_v8_1_lob_ok into arm_v8_1m_lob_hw
for consistency.

Since "lob" applies only to M-profile, replace v8_1 with v8_1m in
arm_v8_1_lob_ok, arm_thumb2_no_arm_v8_1_lob and
arm_thumb2_ok_no_arm_v8_1_lob.

gcc/testsuite/ChangeLog

* lib/target-supports.exp: Rename arm_v8_1_lob_ok into
arm_v8_1m_lob_hw.
Rename arm_thumb2_no_arm_v8_1_lob into
arm_thumb2_no_arm_v8_1m_lob.
Rename arm_thumb2_ok_no_arm_v8_1_lob into
arm_thumb2_ok_no_arm_v8_1m_lob.
* gcc.target/arm/lob1.c: Likewise.
* gcc.target/arm/lob6.c: Likewise.
* gcc.target/arm/ivopts.c: Likewise.
* gcc.target/arm/unsigned-extend-2.c: Likewise.

diff

Re: .ACCESS_WITH_SIZE and pointer ranges

[Andrew MacLeod]

On 4/11/25 10:27, Qing Zhao wrote:



On Apr 10, 2025, at 11:12, Martin Uecker  wrote:

Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:

On 2025-04-10 10:50, Andrew MacLeod wrote:

Its not clear to me exactly what is being asked, but I think the
suggestion is that pointer references are being replaced with a builtin
function called .ACCESS_WITH_SIZE ?and I presume that builtin
function has some parameters that give you relevant range information of
some sort?

Added, not replaced, but yes, that's essentially it.


range-ops is setup to pull range information from builtin functions
already in gimple-range-op.cc::
gimple_range_op_handler::maybe_builtin_call ().  We'd just need to write
a handler for this new one.  You can pull information from 2 operands
under normal circumstances, but exceptions can be made.I'd need a
description of what it looks like and how that translates to range info.

That's perfect!  It's probably redundant for cases where we end up with
both .ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't remember if
that's the only place where .ACCESS_WITH_SIZE is generated today.  Qing,
could you please work with Andrew on this?

BTW, what I would find very interesting is inserting such information
at the points where arrays decay to pointer.

Is the following the example?

   1 #include 
   2
   3 void foo (int arr[]) {
   4   // Inside the function, arr is treated as a pointer
   5   arr[6] = 10;
   6 }
   7
   8 int my_array[5] = {10, 20, 30, 40, 50};
   9
  10 int main() {
  11   my_array[6] = 6;
  12   int *ptr = my_array; // Array decays to pointer here
  13   ptr[7] = 7;
  14   foo (my_array);
  15   16   return 0;
  17 }

When I use the latest gcc to compile the above with -Warray-bounds:

[]$ gcc -O2 -Warray-bounds t.c
t.c: In function ‘main’:
t.c:13:6: warning: array subscript 7 is outside array bounds of ‘int[5]’ 
[-Warray-bounds=]
13 |   ptr[7] = 7;
   |   ~~~^~~
t.c:8:5: note: at offset 28 into object ‘my_array’ of size 20
 8 | int my_array[5] = {10, 20, 30, 40, 50};
   | ^~~~
In function ‘foo’,
 inlined from ‘main’ at t.c:14:3:
t.c:5:10: warning: array subscript 6 is outside array bounds of ‘int[5]’ 
[-Warray-bounds=]
 5 |   arr[6] = 10;
   |   ~~~^~~~
t.c: In function ‘main’:
t.c:8:5: note: at offset 24 into object ‘my_array’ of size 20
 8 | int my_array[5] = {10, 20, 30, 40, 50};
   | ^~~~

Looks like that even after the array decay to pointer, the bound information is 
still carried
for the decayed pointer somehow (I guess that vrp did this?)


No, the behaviour in these warnings is from something else. Although 
some range info from VRP is used, most of this is tracked by the 
pointer_query (pointer-query.cc) mechanism that was written a number of 
years ago before ranger was completed.  It attempts to do its own custom 
tracking of pointers and what they point to and the size of things they 
access.


There are issues with that code, and the goal is to replace it with 
rangers prange.  Alas there is enhancement work to prange for that to 
happen as it doesnt currently track and points to info. That would then 
be followed by converting the warning code to then use ranger/VRP instead.


 Any any adjustments to ranger for this are unlikely to affect anything 
until that work is done, and I do not think anyone is equipped to 
attempt to update the existing pointer-query code.


Unfortunately :-(

Andrew

[PATCH] testsuite: arm: Fix unsigned-extend-2.c [PR116445]

[Christophe Lyon]

The test was designed to pass with thumb2, but code generation changed
with the introduction of Low Overhead Loops, so the test can fail if
one overrides the flags when running the testsuite.

In addition, useless subtract / extension instructions require -O2 to
remove them (-O is not sufficient), so replace -O with -O2 in
dg-options.

arm_thumb2_ok_no_arm_v8_1m_lob does not do what the test needs (it can
fail because some flags conflict, rather than because lob are
supported, and we do not need to check runtime support in this test
anyway), so the patch reverts back to arm_thumb2_ok.

Finally, replace the scan-assembler directives with
check-function-bodies, checking both types of code generation (with
and without LOL).  Depending on architecture version, the two insns
and r0, r1, r0, lsr #1
andsr3, r3, #255
can be swapped, so accept both orders.

gcc/testsuite/ChangeLog:

PR target/116445
* gcc.target/arm/unsigned-extend-2.c: Fix dg directives.
---
 .../gcc.target/arm/unsigned-extend-2.c| 33 +++
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/unsigned-extend-2.c 
b/gcc/testsuite/gcc.target/arm/unsigned-extend-2.c
index 41ee994c1ec..d9f95a14277 100644
--- a/gcc/testsuite/gcc.target/arm/unsigned-extend-2.c
+++ b/gcc/testsuite/gcc.target/arm/unsigned-extend-2.c
@@ -1,6 +1,31 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target arm_thumb2_ok_no_arm_v8_1m_lob } */
-/* { dg-options "-O" } */
+/* { dg-require-effective-target arm_thumb2_ok } */
+/* { dg-options "-O2 -mthumb" } */
+/* { dg-final { check-function-bodies "**" "" } } */
+
+/*
+** foo:
+** movs(r[0-9]+), #8
+** (
+** subs\1, \1, #1
+** ands\1, \1, #255
+** and r0, r1, r0, lsr #1
+** bne .L[0-9]+
+** bx  lr
+** |
+** subs\1, \1, #1
+** and r0, r1, r0, lsr #1
+** ands\1, \1, #255
+** bne .L[0-9]+
+** bx  lr
+** |
+** push{lr}
+** dls lr, \1
+** and r0, r1, r0, lsr #1
+** le  lr, .L[0-9]+
+** pop {pc}
+** )
+*/
 
 unsigned short foo (unsigned short x, unsigned short c)
 {
@@ -12,7 +37,3 @@ unsigned short foo (unsigned short x, unsigned short c)
 }
   return x;
 }
-
-/* { dg-final { scan-assembler "ands" } } */
-/* { dg-final { scan-assembler-not "uxtb" } } */
-/* { dg-final { scan-assembler-not "cmp" } } */
-- 
2.34.1

Re: [PATCH] LRA: Backport PR115568 and PR119689 to release branches

[Vladimir Makarov]

On 4/11/25 2:29 AM, Uros Bizjak wrote:

Hello!

I would like to backport PR115568 and PR119689 to release branches.

Author: Richard Biener 
Date:   Wed Apr 9 14:36:19 2025 +0200

rtl-optimization/119689 - compare-debug failure with LRA

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

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

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

(cherry picked from commit 07de7717a22b1503760e9b79dfbe22a0f428)

Author: Vladimir N. Makarov 
Date:   Wed Feb 5 14:23:23 2025 -0500

[PR115568][LRA]: Use more strict output reload check in rematerialization

  In this PR case LRA rematerialized a value from inheritance insn
instead of output reload one.  This resulted in considering a
rematerilization candidate value available when it was actually
not.  As a consequence an insn after rematerliazation used the
unexpected value and this use resulted in fp exception.  The patch
fixes this bug.

gcc/ChangeLog:

PR rtl-optimization/115568
* lra-remat.cc (create_cands): Check that output reload insn is
adjacent to given insn.  Update a comment.

gcc/testsuite/ChangeLog:

PR rtl-optimization/115568
* gcc.target/i386/pr115568.c: New.

OK for branches?

Yes, but only when the both patches are committed as mine patch had a 
flaw and Richard's patch fixed this flaw.


Thank you, Uros.

Re: .ACCESS_WITH_SIZE and pointer ranges

[Qing Zhao]

> On Apr 11, 2025, at 12:20, Martin Uecker  wrote:
> 
> Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao:
>> 
>>> On Apr 11, 2025, at 10:53, Martin Uecker  wrote:
>>> 
>>> Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod:
 On 4/11/25 10:27, Qing Zhao wrote:
> 
>> On Apr 10, 2025, at 11:12, Martin Uecker  wrote:
>> 
>> Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
>>> On 2025-04-10 10:50, Andrew MacLeod wrote:
 Its not clear to me exactly what is being asked, but I think the
 suggestion is that pointer references are being replaced with a builtin
 function called .ACCESS_WITH_SIZE ?and I presume that builtin
 function has some parameters that give you relevant range information 
 of
 some sort?
>>> Added, not replaced, but yes, that's essentially it.
>>> 
 range-ops is setup to pull range information from builtin functions
 already in gimple-range-op.cc::
 gimple_range_op_handler::maybe_builtin_call ().  We'd just need to 
 write
 a handler for this new one.  You can pull information from 2 operands
 under normal circumstances, but exceptions can be made.I'd need a
 description of what it looks like and how that translates to range 
 info.
>>> That's perfect!  It's probably redundant for cases where we end up with
>>> both .ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't remember if
>>> that's the only place where .ACCESS_WITH_SIZE is generated today.  Qing,
>>> could you please work with Andrew on this?
>> BTW, what I would find very interesting is inserting such information
>> at the points where arrays decay to pointer.
> Is the following the example?
> 
>  1 #include 
>  2
>  3 void foo (int arr[]) {
>  4   // Inside the function, arr is treated as a pointer
>  5   arr[6] = 10;
>  6 }
>  7
>  8 int my_array[5] = {10, 20, 30, 40, 50};
>  9
> 10 int main() {
> 11   my_array[6] = 6;
> 12   int *ptr = my_array; // Array decays to pointer here
> 13   ptr[7] = 7;
> 14   foo (my_array);
> 15   16   return 0;
> 17 }
> 
> When I use the latest gcc to compile the above with -Warray-bounds:
> 
> []$ gcc -O2 -Warray-bounds t.c
> t.c: In function ‘main’:
> t.c:13:6: warning: array subscript 7 is outside array bounds of ‘int[5]’ 
> [-Warray-bounds=]
>   13 |   ptr[7] = 7;
>  |   ~~~^~~
> t.c:8:5: note: at offset 28 into object ‘my_array’ of size 20
>8 | int my_array[5] = {10, 20, 30, 40, 50};
>  | ^~~~
> In function ‘foo’,
>inlined from ‘main’ at t.c:14:3:
> t.c:5:10: warning: array subscript 6 is outside array bounds of ‘int[5]’ 
> [-Warray-bounds=]
>5 |   arr[6] = 10;
>  |   ~~~^~~~
> t.c: In function ‘main’:
> t.c:8:5: note: at offset 24 into object ‘my_array’ of size 20
>8 | int my_array[5] = {10, 20, 30, 40, 50};
>  | ^~~~
> 
> Looks like that even after the array decay to pointer, the bound 
> information is still carried
> for the decayed pointer somehow (I guess that vrp did this?)
 
 No, the behaviour in these warnings is from something else. Although 
 some range info from VRP is used, most of this is tracked by the 
 pointer_query (pointer-query.cc) mechanism that was written a number of 
 years ago before ranger was completed.  It attempts to do its own custom 
 tracking of pointers and what they point to and the size of things they 
 access.
 
 There are issues with that code, and the goal is to replace it with 
 rangers prange.  Alas there is enhancement work to prange for that to 
 happen as it doesnt currently track and points to info. That would then 
 be followed by converting the warning code to then use ranger/VRP instead.
 
 Any any adjustments to ranger for this are unlikely to affect anything 
 until that work is done, and I do not think anyone is equipped to 
 attempt to update the existing pointer-query code.
 
 Unfortunately :-(
>>> 
>>> Examples I have in mind for the .ACCESS_WITH_SIZE are the
>>> following two:
>>> 
>>> struct foo {
>>> 
>>>   char arr[3];
>>>   int b;
>>> };
>>> 
>>> void f(struct foo x)
>>> {
>>>   char *ptr = x.arr;
>>>   ptr[4] = 10;
>>> }
>> 
>> The above is an example about decaying a field array of a structure to a 
>> pointer. 
>> 
>> Yes, usually tracking and keeping the bound info for a field is harder than 
>> a regular variable,
>> However, I think it’s still possible to improve compiler analysis to do this 
>> since the original bound
>> info is in the code. 
>> 
>>> 
>>> void g(char (*arr)[4])
>>> {
>>>   char *ptr = *arr;
>>>   ptr[4] = 1;
>>> }
>>> 
>> 
>> The above example is about decaying a formal parameter array to a pointer.

Re: [patch, Fortran] Fix PR 119669

[Harald Anlauf]

Hi Thomas!

Am 11.04.25 um 17:50 schrieb Thomas Koenig:

Hello world,

the attached patch fixes an ICE by setting the typespec of a dummy
argument from a global function if known. plus setting the correct flag.
This also removes the corresponding assert.  I'm not quite sure that the
code with the subroutine attribute can be reached, but I thought better
safe than sorry.


Agreed.


Most of the patch is actually reformatting due to the 80-column-rule.
(Do we really want to keep that for gfortran?)


Yes, please.


Regression-tested. OK for trunk?


There is a duplicate "and and" here:

+ gfc_error ("Mismatch between subroutine and and "
+"function at %L", &actual->where);

OK with this fixed.

Thanks for the patch!

Harald


Best regards

 Thomas

Fix ICE in compare_parameter.

gcc/fortran/ChangeLog:

 PR fortran/119669
 * interface.cc (compare_parameter): Error when mismatch between
 formal argument as subroutine and function.  If the dummy
 argument is a known function, set its typespec.

gcc/testsuite/ChangeLog:

 PR fortran/119669
 * gfortran.dg/interface_59.f90: New test.

Re: .ACCESS_WITH_SIZE and pointer ranges

[Martin Uecker]

Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao:
> 
> > On Apr 11, 2025, at 12:20, Martin Uecker  wrote:
> > 
> > Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao:
> > > 
> > > > On Apr 11, 2025, at 10:53, Martin Uecker  wrote:
> > > > 
> > > > Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod:
> > > > > On 4/11/25 10:27, Qing Zhao wrote:
> > > > > > 
> > > > > > > On Apr 10, 2025, at 11:12, Martin Uecker  wrote:
> > > > > > > 
> > > > > > > Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh 
> > > > > > > Poyarekar:
> > > > > > > > On 2025-04-10 10:50, Andrew MacLeod wrote:
> > > > > > > > > Its not clear to me exactly what is being asked, but I think 
> > > > > > > > > the
> > > > > > > > > suggestion is that pointer references are being replaced with 
> > > > > > > > > a builtin
> > > > > > > > > function called .ACCESS_WITH_SIZE ?and I presume that 
> > > > > > > > > builtin
> > > > > > > > > function has some parameters that give you relevant range 
> > > > > > > > > information of
> > > > > > > > > some sort?
> > > > > > > > Added, not replaced, but yes, that's essentially it.
> > > > > > > > 
> > > > > > > > > range-ops is setup to pull range information from builtin 
> > > > > > > > > functions
> > > > > > > > > already in gimple-range-op.cc::
> > > > > > > > > gimple_range_op_handler::maybe_builtin_call ().  We'd just 
> > > > > > > > > need to write
> > > > > > > > > a handler for this new one.  You can pull information from 2 
> > > > > > > > > operands
> > > > > > > > > under normal circumstances, but exceptions can be made.
> > > > > > > > > I'd need a
> > > > > > > > > description of what it looks like and how that translates to 
> > > > > > > > > range info.
> > > > > > > > That's perfect!  It's probably redundant for cases where we end 
> > > > > > > > up with
> > > > > > > > both .ACCESS_WITH_SIZE and a __bos/__bdos call, but I don't 
> > > > > > > > remember if
> > > > > > > > that's the only place where .ACCESS_WITH_SIZE is generated 
> > > > > > > > today.  Qing,
> > > > > > > > could you please work with Andrew on this?
> > > > > > > BTW, what I would find very interesting is inserting such 
> > > > > > > information
> > > > > > > at the points where arrays decay to pointer.
> > > > > > Is the following the example?
> > > > > > 
> > > > > >  1 #include 
> > > > > >  2
> > > > > >  3 void foo (int arr[]) {
> > > > > >  4   // Inside the function, arr is treated as a pointer
> > > > > >  5   arr[6] = 10;
> > > > > >  6 }
> > > > > >  7
> > > > > >  8 int my_array[5] = {10, 20, 30, 40, 50};
> > > > > >  9
> > > > > > 10 int main() {
> > > > > > 11   my_array[6] = 6;
> > > > > > 12   int *ptr = my_array; // Array decays to pointer here
> > > > > > 13   ptr[7] = 7;
> > > > > > 14   foo (my_array);
> > > > > > 15   16   return 0;
> > > > > > 17 }
> > > > > > 
> > > > > > When I use the latest gcc to compile the above with -Warray-bounds:
> > > > > > 
> > > > > > []$ gcc -O2 -Warray-bounds t.c
> > > > > > t.c: In function ‘main’:
> > > > > > t.c:13:6: warning: array subscript 7 is outside array bounds of 
> > > > > > ‘int[5]’ [-Warray-bounds=]
> > > > > >   13 |   ptr[7] = 7;
> > > > > >  |   ~~~^~~
> > > > > > t.c:8:5: note: at offset 28 into object ‘my_array’ of size 20
> > > > > >8 | int my_array[5] = {10, 20, 30, 40, 50};
> > > > > >  | ^~~~
> > > > > > In function ‘foo’,
> > > > > >inlined from ‘main’ at t.c:14:3:
> > > > > > t.c:5:10: warning: array subscript 6 is outside array bounds of 
> > > > > > ‘int[5]’ [-Warray-bounds=]
> > > > > >5 |   arr[6] = 10;
> > > > > >  |   ~~~^~~~
> > > > > > t.c: In function ‘main’:
> > > > > > t.c:8:5: note: at offset 24 into object ‘my_array’ of size 20
> > > > > >8 | int my_array[5] = {10, 20, 30, 40, 50};
> > > > > >  | ^~~~
> > > > > > 
> > > > > > Looks like that even after the array decay to pointer, the bound 
> > > > > > information is still carried
> > > > > > for the decayed pointer somehow (I guess that vrp did this?)
> > > > > 
> > > > > No, the behaviour in these warnings is from something else. Although 
> > > > > some range info from VRP is used, most of this is tracked by the 
> > > > > pointer_query (pointer-query.cc) mechanism that was written a number 
> > > > > of 
> > > > > years ago before ranger was completed.  It attempts to do its own 
> > > > > custom 
> > > > > tracking of pointers and what they point to and the size of things 
> > > > > they 
> > > > > access.
> > > > > 
> > > > > There are issues with that code, and the goal is to replace it with 
> > > > > rangers prange.  Alas there is enhancement work to prange for that to 
> > > > > happen as it doesnt currently track and points to info. That would 
> > > > > then 
> > > > > be followed by converting the warning code to then use ranger/VRP 
> > > > > instead.
> > > > > 
> > > > > Any any adjustments to ranger for this are unlikely to affect 
> > > > > anything 

Re: [PATCH] libstdc++: Fix atomic CAS hang with C++11 [PR114865]

[Jonathan Wakely]

On Fri, 11 Apr 2025 at 15:14, Tomasz Kaminski  wrote:
>
>
>
> On Fri, Apr 11, 2025 at 2:25 PM Jonathan Wakely  wrote:
>>
>> On Fri, 11 Apr 2025 at 08:23, Tomasz Kaminski  wrote:
>> >
>> >
>> >
>> > On Thu, Apr 10, 2025 at 6:27 PM Jonathan Wakely  wrote:
>> >>
>> >> The std::atomic constructor clears padding bits so that compare_exchange
>> >> will not fail due to differences in padding bits. But we can only do
>> >> that for C++14 and later, because in C++11 a constexpr constructor must
>> >> have an empty body. However, the code in compare_exchange_strong assumes
>> >> that padding is always cleared, and so it fails in C++11 due to non-zero
>> >> padding.
>> >>
>> >> Since we can't clear the padding in C++11 mode, we shouldn't assume it's
>> >> been cleared when in C++11 mode. This fixes the reported bug. However,
>> >> the fix fails to handle the case where the std::atomic is constructed in
>> >> C++11 code (and so doesn't zero padding) but the CAS happens in C++14
>> >> code (and so assumes padding has been zeroed). We might need to use the
>> >> same loop as atomic_ref::compare_exchange_strong to properly fix this
>> >> bug for that case.
>> >>
>> >> Although the mixed C++11 / C++14 case isn't fixed, this is still an
>> >> incremental improvement. It fixes the pure-C++11 case and doesn't
>> >> preclude a more comprehensive fix later.
>> >
>> > Wouldn't alternative comprehensive fix be equivalent to doing just:
>> > diff --git a/libstdc++-v3/include/std/atomic 
>> > b/libstdc++-v3/include/std/atomic
>> > index 9b1aca0fc09..238cf739161 100644
>> > --- a/libstdc++-v3/include/std/atomic
>> > +++ b/libstdc++-v3/include/std/atomic
>> > @@ -345,7 +345,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> >compare_exchange_weak(_Tp& __e, _Tp __i, memory_order __s,
>> > memory_order __f) noexcept
>> >{
>> > -   return __atomic_impl::__compare_exchange(_M_i, __e, __i, true,
>> > +   return __atomic_impl::__compare_exchange<(__cplusplus < 
>> > 201402L)>(_M_i, __e, __i, true,
>> >  __s, __f);
>>
>> If the std::atomic constructor happens in a translation unit compiled
>> as C++11 but the call to compare_exchange_weak happens in a
>> translation unit compiled as C++14, then padding won't be cleared, but
>> this will call __compare_exchange which expects padding to have
>> been cleared.
>
> I see. This seems to be the same drawback as in case of the current fix, 
> however

Yes.

> my suggestion guarantees that padding bits are ignored/cleared in program
> compiled only in C++11 mode. As I understand the suggested change, make a 
> comparison exchange
> prone to fail due padding bits.

Yes, that's true. We would reliably ignore padding bits for C++11 too.
OK, I'll experiment with that next week.

Re: .ACCESS_WITH_SIZE and pointer ranges

[Siddhesh Poyarekar]

On 2025-04-11 13:37, Martin Uecker wrote:

My understanding is that such issue with the implicit data flow dependency 
information missing is only for the
counted_by attribute, not for the other TYPE which already have the bound 
information there.



The dependency issue is only for the size, but for
other types the size information is often not
preserved, so then not available later.
.ACCESS_WITH_SIZE would solve this.


Yes, I think we had this conversation before, that .ACCESS_WITH_SIZE 
could for example even preserve size information across functions with 
__access__ attribute that were inlined.


Sid

[PATCH] [testsuite] [ppc] compile [PR112822] with -mvsx

[Alexandre Oliva]

g++.dg/pr112822.C uses altivec vectors explicitly, but it expects this
feature to be enabled by default on targets that recognize the
attribute, which is not a given on older ppc cpus, where the compiler
recommends recompiling with -mvsx.

Since it's just a compilation test, we don't seem to need to test for
e.g. assembler support.

Regstrapped on powerpc64le-linux-gnu.  Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf.  Ok to install?


for  gcc/testsuite/ChangeLog

PR tree-optimization/112822
* g++.dg/pr112822.C: Compile with -mvsx on ppc.
---
 gcc/testsuite/g++.dg/pr112822.C |2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/testsuite/g++.dg/pr112822.C b/gcc/testsuite/g++.dg/pr112822.C
index a8557522467d7..9ec5707eb4c4d 100644
--- a/gcc/testsuite/g++.dg/pr112822.C
+++ b/gcc/testsuite/g++.dg/pr112822.C
@@ -1,6 +1,8 @@
 /* PR tree-optimization/112822 */
 /* { dg-do compile { target c++17 } } */
 /* { dg-options "-w -O2" } */
+/* Required for altivec double vectors.  */
+/* { dg-additional-options "-mvsx" { target powerpc*-*-* } } */
 
 /* Verify we do not ICE on the following noisy creduced test case.  */
 

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

[PATCH] [testsuite] [ppc] require float128 available for copysign

[Alexandre Oliva]

The rs6000.md copysign3 expander requires the mode to satisfy
FLOAT128_IEEE_P, so requiring float128 on ppc for ifn_copysign
effective target is hopefully a close-enough approximation.

gcc.dg/fold-copysign-1.c and gcc.dg/pr55152-2.c fail on ppc-elf
without this.

Regstrapped on powerpc64le-linux-gnu.  Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf.  Ok to install?


for  gcc/testsuite/ChangeLog

* lib/target-supports.exp (check_effective_target_ifn_copysign):
Require float128 on ppc.
---
 gcc/testsuite/lib/target-supports.exp |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index ee4138aa69714..1c64472bbc241 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -8379,7 +8379,8 @@ proc check_effective_target_ifn_copysign { } {
  && [is-effective-target sse])
 || ([istarget loongarch*-*-*]
 && [check_effective_target_hard_float])
-|| [istarget powerpc*-*-*]
+|| ([istarget powerpc*-*-*]
+&& [check_ppc_float128_sw_available])
 || [istarget alpha*-*-*]
 || [istarget aarch64*-*-*]
 || [is-effective-target arm_neon]

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

[PATCH] [testsuite] [ppc] ipa-sra-19.c: pass -Wno-psabi on powerpc-*-elf as well

[Alexandre Oliva]

Like other ppc targets, powerpc-*-elf needs -Wno-psabi to compile
gcc.dg/ipa/ipa-sra-19.c without an undesired warning about vector
argument passing.

Regstrapped on powerpc64le-linux-gnu.  Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.dg/ipa/ipa-sra-19.c: Add -Wno-psabi on ppc-elf too.
---
 gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c 
b/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c
index c34c89eeacad7..39874addfdb0f 100644
--- a/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c
+++ b/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2"  } */
 /* { dg-additional-options "-msse2" { target ia32 } } */
-/* { dg-additional-options "-Wno-psabi" { target powerpc-ibm-aix* 
powerpc-wrs-vxworks* } } */
+/* { dg-additional-options "-Wno-psabi" { target powerpc-ibm-aix* 
powerpc-wrs-vxworks* powerpc-*-elf } } */
 
 typedef int __attribute__((__vector_size__(16))) vectype;
 

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

[PATCH] [testsuite] [ppc] add -mfloat128 to __ieee128-using bfp tests

[Alexandre Oliva]

Some ppc bfp tests use __ieee128 without ensuring it's available.
Require ppc_ieee128_ok, add -mfloat128 to get the type defined,
and tolerate the warning that this option may trigger.

Regstrapped on powerpc64le-linux-gnu.  Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/bfp/scalar-extract-sig-5.c: Require
ppc_ieee128_ok, add -mfloat128, tolerate its warning.
* gcc.target/powerpc/bfp/scalar-insert-exp-11.c: Likewise.
* gcc.target/powerpc/bfp/scalar-insert-exp-8.c: Likewise.
* gcc.target/powerpc/bfp/scalar-test-data-class-11.c: Likewise.
* gcc.target/powerpc/bfp/scalar-test-neg-5.c: Likewise.
---
 .../gcc.target/powerpc/bfp/scalar-extract-exp-5.c  |4 +++-
 .../gcc.target/powerpc/bfp/scalar-extract-sig-5.c  |4 +++-
 .../gcc.target/powerpc/bfp/scalar-insert-exp-11.c  |4 +++-
 .../gcc.target/powerpc/bfp/scalar-insert-exp-8.c   |4 +++-
 .../powerpc/bfp/scalar-test-data-class-11.c|4 +++-
 .../gcc.target/powerpc/bfp/scalar-test-neg-5.c |4 +++-
 6 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-5.c 
b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-5.c
index 672aac7ed373a..b3aca034cc0c9 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-5.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-5.c
@@ -1,7 +1,9 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -mvsx" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mvsx -mfloat128" } */
 /* { dg-require-effective-target ilp32 } */
+/* { dg-require-effective-target ppc_ieee128_ok } */
 /* { dg-require-effective-target powerpc_vsx } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test only runs on 32-bit configurations, where a compiler error
should be issued because this builtin is not available on
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-5.c 
b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-5.c
index 5b6d763a26f5c..97b2b7e9a642a 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-5.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-5.c
@@ -1,7 +1,9 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -mvsx" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mvsx -mfloat128" } */
 /* { dg-require-effective-target ilp32 } */
+/* { dg-require-effective-target ppc_ieee128_ok } */
 /* { dg-require-effective-target powerpc_vsx } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test only runs on 32-bit configurations, producing a compiler
error because the builtin requires 64 bits.  */
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-11.c 
b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-11.c
index 3a0529ed9a1b2..3a556740516f7 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-11.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-11.c
@@ -1,7 +1,9 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -mvsx" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mvsx -mfloat128" } */
 /* { dg-require-effective-target ilp32 } */
+/* { dg-require-effective-target ppc_ieee128_ok } */
 /* { dg-require-effective-target powerpc_vsx } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test only runs on 32-bit configurations, where a compiler error
should be issued because this builtin is not available on
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-8.c 
b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-8.c
index d9984c7678f3c..9427f89d18f24 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-8.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-8.c
@@ -1,7 +1,9 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
-/* { dg-options "-mdejagnu-cpu=power9 -mvsx" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mvsx -mfloat128" } */
 /* { dg-require-effective-target ilp32 } */
+/* { dg-require-effective-target ppc_ieee128_ok } */
 /* { dg-require-effective-target powerpc_vsx } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test only runs on 32-bit configurations, where a compiler error
should be issued because this builtin is not available on
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-11.c 
b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-11.c
index 8da98569de8a9..132058304cdd7 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-11.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-11.c
@@ -1,6 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
-/* { dg-options "-mdejagnu-cp

[PATCH] [testsuite] [ppc] xfail pr52451.c on ppc [PR58684]

[Alexandre Oliva]

Like pr91323.c, pr52451.c fails on all powerpc variants (except where
already skipped), because it uses fcmpu even when qNaNs should flag FP
exceptions.

Regstrapped on powerpc64le-linux-gnu.  Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf.  Ok to install?


for  gcc/testsuite/ChangeLog

PR target/58684
* gcc.dg/torture/pr52451.c: Expect execution fail on
powerpc*-*-*.
---
 gcc/testsuite/gcc.dg/torture/pr52451.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/torture/pr52451.c 
b/gcc/testsuite/gcc.dg/torture/pr52451.c
index aa19c1bc39a59..c611aeeb53f8c 100644
--- a/gcc/testsuite/gcc.dg/torture/pr52451.c
+++ b/gcc/testsuite/gcc.dg/torture/pr52451.c
@@ -1,4 +1,5 @@
-/* { dg-do run } */
+/* { dg-do run { xfail powerpc*-*-* } } */
+/* remove the xfail for powerpc when pr58684 is fixed */
 /* { dg-add-options ieee } */
 /* { dg-require-effective-target fenv_exceptions_long_double } */
 /* { dg-skip-if "fenv" { powerpc-ibm-aix* } } */

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

[PATCH] [testsuite] [ppc] newlib sets FE_VXSOFT on raise FE_INVALID

[Alexandre Oliva]

The implementation of the fe*except primitives in newlib sets the
FE_VXSOFT bit when raising FE_INVALID, and the test doesn't expect
that.  Skip it: the tested builtin expansions are for glibc only
anyway.

Regstrapped on powerpc64le-linux-gnu.  Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/builtin-feclearexcept-feraiseexcept-2.c:
Skip on newlib/ppc.
---
 .../builtin-feclearexcept-feraiseexcept-2.c|1 +
 1 file changed, 1 insertion(+)

diff --git 
a/gcc/testsuite/gcc.target/powerpc/builtin-feclearexcept-feraiseexcept-2.c 
b/gcc/testsuite/gcc.target/powerpc/builtin-feclearexcept-feraiseexcept-2.c
index 28c2a00ec5203..b9260a123d779 100644
--- a/gcc/testsuite/gcc.target/powerpc/builtin-feclearexcept-feraiseexcept-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/builtin-feclearexcept-feraiseexcept-2.c
@@ -1,6 +1,7 @@
 /* { dg-do run } */
 /* { dg-require-effective-target fenv_exceptions } */
 /* { dg-options "-lm -fno-builtin" } */
+/* { dg-skip-if "raise FE_INVALID sets FE_VXSOFT on newlib" { powerpc*-*-e* } 
} */
 
 /* This testcase ensures that the builtins are correctly expanded and match the
expected result.

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

[PATCH] [testsuite] [ppc] disable -mpowerpc64 for various ilp32 asm-out checks

[Alexandre Oliva]

Multiple tests on ilp32 get TARGET_POWERPC64 enabled by -mdejagnu-cpu
options, but the results they expect are only attained without
enabling it, so disable it explicitly.

Regstrapped on powerpc64le-linux-gnu.  Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-2.c:
Compile with -mno-powerpc64 on ilp32.
* gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-2.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-5.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/builtins-1.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-extract-char.p8.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-extract-char.p9.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p8.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p8.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-extract-int.p7.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-extract-int.p8.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-extract-int.p9.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-extract-longlong.p7.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-extract-longlong.p8.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-extract-short.p7.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-extract-short.p8.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-insert-char-p9.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-insert-float-p8.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-insert-float-p9.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-insert-int-p9.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fold-vec-insert-short-p9.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fusion-p10-2logical.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fusion-p10-ldcmpi.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/fusion-p10-logadd.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/loop_align.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/ppc-target-4.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/pr79251.p7.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/pr79251.p8.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/pr79251.p9.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/pr96933-2.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/vsu/vec-xl-len-13.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/vsu/vec-xst-len-13.c:
Likewise.
* gcc/testsuite/gcc.target/powerpc/vsx-builtin-7.c: Likewise.
---
 .../gcc.target/powerpc/bfp/scalar-extract-sig-2.c  |2 +-
 .../gcc.target/powerpc/bfp/scalar-insert-exp-2.c   |2 +-
 .../gcc.target/powerpc/bfp/scalar-insert-exp-5.c   |2 +-
 gcc/testsuite/gcc.target/powerpc/builtins-1.c  |2 ++
 .../gcc.target/powerpc/fold-vec-extract-char.p8.c  |3 ++-
 .../gcc.target/powerpc/fold-vec-extract-char.p9.c  |1 +
 .../powerpc/fold-vec-extract-double.p7.c   |1 +
 .../powerpc/fold-vec-extract-double.p8.c   |1 +
 .../gcc.target/powerpc/fold-vec-extract-float.p7.c |1 +
 .../gcc.target/powerpc/fold-vec-extract-float.p8.c |1 +
 .../gcc.target/powerpc/fold-vec-extract-int.p7.c   |1 +
 .../gcc.target/powerpc/fold-vec-extract-int.p8.c   |1 +
 .../gcc.target/powerpc/fold-vec-extract-int.p9.c   |1 +
 .../powerpc/fold-vec-extract-longlong.p7.c |1 +
 .../powerpc/fold-vec-extract-longlong.p8.c |1 +
 .../gcc.target/powerpc/fold-vec-extract-short.p7.c |1 +
 .../gcc.target/powerpc/fold-vec-extract-short.p8.c |1 +
 .../gcc.target/powerpc/fold-vec-insert-char-p9.c   |1 +
 .../gcc.target/powerpc/fold-vec-insert-float-p8.c  |1 +
 .../gcc.target/powerpc/fold-vec-insert-float-p9.c  |1 +
 .../gcc.target/powerpc/fold-vec-insert-int-p9.c|1 +
 .../gcc.target/powerpc/fold-vec-insert-short-p9.c  |1 +
 .../gcc.target/powerpc/fusion-p10-2logical.c   |1 +
 .../gcc.target/powerpc/fusion-p10-ldcmpi.c |1 +
 .../gcc.target/powerpc/fusion-p10-logadd.c |1 +
 gcc/testsuite/gcc.target/powerpc/loop_align.c  |5 +
 gcc/testsuite/gcc.target/powerpc/ppc-target-4.c|3 +++
 gcc/testsuite/gcc.target/powerpc/pr79251.p7.c  |1 +
 gcc/testsuite/gcc.target/powerpc/pr79251.p8.c  |1 +
 gcc/testsuite/gcc.target/powerpc/pr792

[PATCH] [testsuite] [ppc] block-cmp-8 should require powerpc64

[Alexandre Oliva]

gcc.target/powerpc/block-cmp-8.c is an execution test on ilp32.  It
tests for support for the 64-bit ISA in the compiler, but not for the
ability to execute powerpc64 instructions, so the test fails on 32-bit
hardware.  Require powerpc64 instead.

Regstrapped on powerpc64le-linux-gnu.  Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/block-cmp-8.c: Require powerpc64
instruction execution support.
---
 gcc/testsuite/gcc.target/powerpc/block-cmp-8.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/block-cmp-8.c 
b/gcc/testsuite/gcc.target/powerpc/block-cmp-8.c
index 22a48c8fadfc1..0f353338a 100644
--- a/gcc/testsuite/gcc.target/powerpc/block-cmp-8.c
+++ b/gcc/testsuite/gcc.target/powerpc/block-cmp-8.c
@@ -1,6 +1,6 @@
 /* { dg-do run { target ilp32 } } */
 /* { dg-options "-O2 -mpowerpc64" } */
-/* { dg-require-effective-target has_arch_ppc64 } */
+/* { dg-require-effective-target powerpc64 } */
 /* { dg-timeout-factor 2 } */
 
 /* Verify memcmp on m32 mpowerpc64 */

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

Re: .ACCESS_WITH_SIZE and pointer ranges

[Martin Uecker]

Am Freitag, dem 11.04.2025 um 13:55 -0400 schrieb Siddhesh Poyarekar:
> On 2025-04-11 13:37, Martin Uecker wrote:
> > > My understanding is that such issue with the implicit data flow 
> > > dependency information missing is only for the
> > > counted_by attribute, not for the other TYPE which already have the bound 
> > > information there.
> > > 
> > 
> > The dependency issue is only for the size, but for
> > other types the size information is often not
> > preserved, so then not available later.
> > .ACCESS_WITH_SIZE would solve this.
> 
> Yes, I think we had this conversation before, that .ACCESS_WITH_SIZE 
> could for example even preserve size information across functions with 
> __access__ attribute that were inlined.

Also in other cases the size information of an array type
is not preserved too long in the middle end, when it is not 
explicitely used. Something such as .ACCESS_WITH_SIZE is 
needed to preserve it.

Martin

> 
> Sid

[PATCH] [testsuite] [ppc] add -mfloat128 to pr67808.c

[Alexandre Oliva]

gcc.target/powerpc/pr67808.c in some cases expects both 128-bit long
double types to be defined, but -mlong-double-128 doesn't guarantee
that without -mfloat128 on targets that would get the IEEE128 type as
long double.  Add -mfloat128 to ensure the desired IBM 128-bit
floating-point type is available as expected.

Regstrapped on powerpc64le-linux-gnu.  Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/pr67808.c: Add -mfloat128, and tolerate
its warning.
---
 gcc/testsuite/gcc.target/powerpc/pr67808.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr67808.c 
b/gcc/testsuite/gcc.target/powerpc/pr67808.c
index 4ddadb7194611..a86574141d0c9 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr67808.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr67808.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-skip-if "" { powerpc*-*-darwin* } } */
-/* { dg-options "-O1 -mvsx -mdejagnu-cpu=power7 -mlong-double-128" } */
+/* { dg-options "-O1 -mvsx -mdejagnu-cpu=power7 -mfloat128 -mlong-double-128" 
} */
 /* { dg-require-effective-target powerpc_vsx } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* PR 67808: LRA ICEs on simple double to long double conversion test case */
 
@@ -9,7 +10,7 @@
 /* If long double is IEEE 128-bit, we need to use the __ibm128 type instead of
long double.  We can't use __ibm128 on systems that don't support IEEE
128-bit floating point, because the type is not enabled on those
-   systems.  */
+   systems.  Without -mfloat128, the __ibm128 type may be undefined.  */
 #define LDOUBLE __ibm128
 
 #elif defined(__LONG_DOUBLE_IBM128__)

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

[PATCH] [testsuite] [ppc] add -mdejagnu-cpu=power7 to pr17381.c

[Alexandre Oliva]

Below power7, it seems to be more profitable to compress the
floating-point constants and use an additional fp register move to
"extend" it.  Only at power7 and above do we keep the constants
separate and load them, getting to the expected 'fmr' count.

Regstrapped on powerpc64le-linux-gnu.  Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/pr17381.c: Compile for power7.  Justify.
---
 gcc/testsuite/gcc.target/powerpc/pr17381.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr17381.c 
b/gcc/testsuite/gcc.target/powerpc/pr17381.c
index e6222c130af1f..b137c687776ec 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr17381.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr17381.c
@@ -1,6 +1,8 @@
 /* PR target/17381 - Unnecessary register move for float extend */
 /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-mdejagnu-cpu=power7 -O2" } */
+/* Up to power6, we compress the floating-point constant 1.0 and share it with
+   1.0f, but the float_extend comes out as a second fmr.  */
 
 double d;
 float test1(float fParm)

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

[PATCH] [testsuite] [ppc] add -maltivec to pr111380-2.c

[Alexandre Oliva]

gcc.target/powerpc/pr111380-2.c requires altivec to be enabled to hit
the expected option mismatch and inline error, so enable it after
checking for compiler support.

Regstrapped on powerpc64le-linux-gnu.  Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/pr111380-2.c: Add -maltivec, require it.
---
 gcc/testsuite/gcc.target/powerpc/pr111380-2.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr111380-2.c 
b/gcc/testsuite/gcc.target/powerpc/pr111380-2.c
index 7b363940643b0..bf7cb3a5c8bff 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr111380-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr111380-2.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target vect_int } */
-/* { dg-options "-O2 -mno-vsx" } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-O2 -mno-vsx -maltivec" } */
 
 /* Verify it emits error message on inlining even without LTO.  */
 

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

[PATCH] [testsuite] [ppc] require ifunc for target_clones test

[Alexandre Oliva]

gcc.target/powerpc/power11-3.c uses target_clones, that depends on
ifunc.  Require ifunc support.

Regstrapped on powerpc64le-linux-gnu.  Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/power11-3.c: Require ifunc support.
---
 gcc/testsuite/gcc.target/powerpc/power11-3.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.target/powerpc/power11-3.c 
b/gcc/testsuite/gcc.target/powerpc/power11-3.c
index fa1aedd04299d..56bf881859831 100644
--- a/gcc/testsuite/gcc.target/powerpc/power11-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/power11-3.c
@@ -1,5 +1,6 @@
 /* { dg-do compile }  */
 /* { dg-options "-mdejagnu-cpu=power8 -O2" }  */
+/* { dg-require-ifunc "" } */
 
 /* Check if we can set the power11 target via a target_clones attribute.  */
 

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!

[PATCH] [testsuite] [ppc] add -mno-strict-align to pr111449-1.c

[Alexandre Oliva]

gcc.target/powerpc/pr111449-1.c's expected results only come about
without strict alignment, so disable it explicitly.

Regstrapped on powerpc64le-linux-gnu.  Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/pr111449-1.c: Add -mno-strict-align.
---
 gcc/testsuite/gcc.target/powerpc/pr111449-1.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr111449-1.c 
b/gcc/testsuite/gcc.target/powerpc/pr111449-1.c
index e65794c7ae767..1a81befa9689b 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr111449-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr111449-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-mdejagnu-cpu=power8 -mvsx -O2" } */
+/* { dg-options "-mdejagnu-cpu=power8 -mvsx -O2 -mno-strict-align" } */
 /* { dg-require-effective-target powerpc_vsx } */
 
 /* Ensure vector mode is used for 16-byte by pieces equality compare.  */

-- 
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!