Re: [PATCH] RISC-V: Using O2 instead of O1 in testsuites when using -fdump-ext_dce

[Jeff Law]

On 3/3/25 2:59 AM, Liao Shihua wrote:

The pass ext-dce is only activated at O2 and above. Using O2 instead of O1
in testsuites when using -fdump-ext_dce.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/core_list_init.c: Using -O2 instead of -O1.
* gcc.target/riscv/pr111384.c: Ditto.

Here's what I'm committing.  Again, thanks for raising this issue!

Jeff


commit 316eaca17ee11f575fc72e139e8cc3f9f5ccb067
Author: Jeff Law 
Date:   Wed Mar 5 22:24:05 2025 -0700

Improve coverage of ext-dce tests in risc-v testsuite

Inspired by Liao Shihua, this adjusts two tests in the RISC-V testsuite
to get more coverage.  Drop the -O1 argument and replace it with -fext-dce.
That way the test gets run across the full set of flags.  We just need to
make sure to skip -O0.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/core_list_init.c: Use -fext-dce rather than
-O1.  Skip for -O0.
* gcc.target/riscv/pr111384.c: Ditto.

diff --git a/gcc/testsuite/gcc.target/riscv/core_list_init.c 
b/gcc/testsuite/gcc.target/riscv/core_list_init.c
index 2f36dae85aa..eec3a817d80 100644
--- a/gcc/testsuite/gcc.target/riscv/core_list_init.c
+++ b/gcc/testsuite/gcc.target/riscv/core_list_init.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
-/* { dg-options "-O1 -fdump-rtl-ext_dce" } */
+/* { dg-options "-fext-dce -fdump-rtl-ext_dce" } */
 /* { dg-final { scan-rtl-dump {Successfully transformed} "ext_dce" } } */
+/* { dg-skip-if "" { *-*-* } { "-O0"} } */
 
 unsigned short
 core_list_init (int size, short seed) {
diff --git a/gcc/testsuite/gcc.target/riscv/pr111384.c 
b/gcc/testsuite/gcc.target/riscv/pr111384.c
index a4e77d4aeb6..bcf33eb 100644
--- a/gcc/testsuite/gcc.target/riscv/pr111384.c
+++ b/gcc/testsuite/gcc.target/riscv/pr111384.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
-/* { dg-options "-O1 -fdump-rtl-ext_dce" } */
+/* { dg-options "-fext-dce -fdump-rtl-ext_dce" } */
 /* { dg-final { scan-rtl-dump {Successfully transformed} "ext_dce" } } */
+/* { dg-skip-if "" { *-*-* } { "-O0"} } */
 
 void
 foo(unsigned int src, unsigned short *dst1, unsigned short *dst2)

Re: [PATCH] RISC-V: Adjust LMUL when using maximum SEW [PR117955].

[Jin Ma]

On Wed, 05 Mar 2025 12:17:24 +0100, "Robin Dapp" wrote:
> Hi Jin,
> 
> > I apologize for the delayed response. I spent quite a bit of time trying to 
> > reproduce
> > the case, and given the passage of time, it wasn't easy to refine the 
> > testing.
> > Fortunately, you can see the results here.
> >
> > https://godbolt.org/z/Mc8veW7oT
> >
> > Using GCC version 14.2.0 should allow you to replicate the issue. If all 
> > goes as
> > expected, you will encounter a "Segmentation fault (core dumped)."
> > By disassembling the binary, you'll notice the presence of "vsetvli 
> > zero,zero,e32,m4,ta,ma",
> > which is where the problem lies, just as I mentioned previously.
> 
> Thanks for the full example, this is helpful but it still required some more 
> digging on my side.
> 
> I realize now how you came to your conclusion and why you wrote the test that 
> way.
> 
> In QEMU there is a segfault (but no illegal instruction) on
>   vloxei16.v  v8,(t2),v8.
> I'm not really sure why yet because vtype and vl are OK.  Most likely we 
> corrupted something before.
> 
> On the BPI, however, the more useful information is a SIGILL on
>   vfmv.s.fv12,fa5.
> 
> That's because we do
>   vsetvli zero,zero,e16,m4,ta,ma
>   ...
>   vsetvli zero,zero,e8,m2,ta,ma
>   ...
>   vsetvli zero,zero,e32,m4,ta,ma
> 
> The last vsetvl changes the SEW without adjusting LMUL, so changing SEW/LMUL 
> and VLMAX which is not allowed for vsetvl zero, zero, ...
> Subsequently, VILL is set and we SIGILL on the next vector instruction.
> 
> So I'd say QEMU should emit a SIGILL here.  I'm preparing a QEMU patch for 
> that.
> 
> With your patch the last vsetvl becomes
>   vsetvli zero,a5,e32,m4,ta,ma
> When setting a new VL it is permitted to change SEW/LMUL even though it's not 
> desirable as we don't need to change VL.
> 
> With my patch the vsetvl becomes
>   vsetvli zero,zero,e32,m8,ta,ma
> which doesn't change SEW/LMUL or VL and I think that's what we want.
> 
> As summary: Before your patch we only changed SEW which caused a 
> VLMAX-changing 
> vsetvl, your patch works around that by adjusting the ratio without touching 
> LMUL.  But that still leaves us with PR117955 where the ratio is "correct" 
> but 
> invalid.
> 
> Given all this, I think the only way to fix this is to re-use/copy the vsetvl 
> information from either prev or next (as in my patch).
> 
> I'm going to change bug-10.c into a run test, add the test you last provided 
> as 
> a run test as well as well as your reduced test from PR117955.

LGTM :)

Best regards,
Jin Ma

> -- 
> Regards
>  Robin

Re: [PATCH] i386: Correct mask width for bf8->fp16 intrin on 256/512 bit

[Hongtao Liu]

On Wed, Mar 5, 2025 at 3:23 PM Haochen Jiang  wrote:
>
> Hi all,
>
> For bf8 -> pf16 convert, when dst is 256 bit, the mask should be
> 16 bit since 16*16=256, not the 8 bit in the current intrin. In
> 512 bit intrin, the mask bit is also halved. This patch will fix
> both of them.
>
> Ok for trunk?
Ok.
>
> Thx,
> Haochen
>
> gcc/ChangeLog:
>
> * config/i386/avx10_2-512convertintrin.h
> (_mm512_mask_cvtbf8_ph): Correct mask width.
> (_mm512_maskz_cvtbf8_ph): Ditto.
> * config/i386/avx10_2convertintrin.h
> (_mm256_mask_cvtbf8_ph): Ditto.
> (_mm256_maskz_cvtbf8_ph): Ditto.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/avx10_2-512-convert-1.c: Change function call.
> * gcc.target/i386/avx10_2-convert-1.c: Ditto.
> ---
>  gcc/config/i386/avx10_2-512convertintrin.h| 4 ++--
>  gcc/config/i386/avx10_2convertintrin.h| 4 ++--
>  gcc/testsuite/gcc.target/i386/avx10_2-512-convert-1.c | 4 ++--
>  gcc/testsuite/gcc.target/i386/avx10_2-convert-1.c | 4 ++--
>  4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/gcc/config/i386/avx10_2-512convertintrin.h 
> b/gcc/config/i386/avx10_2-512convertintrin.h
> index 1079e0a2bda..a44481e0b4e 100644
> --- a/gcc/config/i386/avx10_2-512convertintrin.h
> +++ b/gcc/config/i386/avx10_2-512convertintrin.h
> @@ -550,7 +550,7 @@ _mm512_cvtbf8_ph (__m256i __A)
>
>  extern __inline __m512h
>  __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> -_mm512_mask_cvtbf8_ph (__m512h __S, __mmask16 __U, __m256i __A)
> +_mm512_mask_cvtbf8_ph (__m512h __S, __mmask32 __U, __m256i __A)
>  {
>return (__m512h) _mm512_castsi512_ph ((__m512i) _mm512_mask_slli_epi16 (
>  (__m512i) __S, __U, (__m512i) _mm512_cvtepi8_epi16 (__A), 8));
> @@ -558,7 +558,7 @@ _mm512_mask_cvtbf8_ph (__m512h __S, __mmask16 __U, 
> __m256i __A)
>
>  extern __inline __m512h
>  __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> -_mm512_maskz_cvtbf8_ph (__mmask16 __U, __m256i __A)
> +_mm512_maskz_cvtbf8_ph (__mmask32 __U, __m256i __A)
>  {
>return (__m512h) _mm512_castsi512_ph ((__m512i) _mm512_slli_epi16 (
>  (__m512i) _mm512_maskz_cvtepi8_epi16 (__U, __A), 8));
> diff --git a/gcc/config/i386/avx10_2convertintrin.h 
> b/gcc/config/i386/avx10_2convertintrin.h
> index 3fc51b17435..7c9c238a3b4 100644
> --- a/gcc/config/i386/avx10_2convertintrin.h
> +++ b/gcc/config/i386/avx10_2convertintrin.h
> @@ -1004,7 +1004,7 @@ _mm256_cvtbf8_ph (__m128i __A)
>
>  extern __inline __m256h
>  __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> -_mm256_mask_cvtbf8_ph (__m256h __S, __mmask8 __U, __m128i __A)
> +_mm256_mask_cvtbf8_ph (__m256h __S, __mmask16 __U, __m128i __A)
>  {
>return (__m256h) _mm256_castsi256_ph ((__m256i) _mm256_mask_slli_epi16 (
>  (__m256i) __S, __U, (__m256i) _mm256_cvtepi8_epi16 (__A), 8));
> @@ -1012,7 +1012,7 @@ _mm256_mask_cvtbf8_ph (__m256h __S, __mmask8 __U, 
> __m128i __A)
>
>  extern __inline __m256h
>  __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> -_mm256_maskz_cvtbf8_ph (__mmask8 __U, __m128i __A)
> +_mm256_maskz_cvtbf8_ph (__mmask16 __U, __m128i __A)
>  {
>return (__m256h) _mm256_castsi256_ph ((__m256i) _mm256_slli_epi16 (
>  (__m256i) _mm256_maskz_cvtepi8_epi16 (__U, __A), 8));
> diff --git a/gcc/testsuite/gcc.target/i386/avx10_2-512-convert-1.c 
> b/gcc/testsuite/gcc.target/i386/avx10_2-512-convert-1.c
> index bda74b5776b..c1e44efdb2f 100644
> --- a/gcc/testsuite/gcc.target/i386/avx10_2-512-convert-1.c
> +++ b/gcc/testsuite/gcc.target/i386/avx10_2-512-convert-1.c
> @@ -183,6 +183,6 @@ void extern
>  avx10_2_512_cvtbf8_fp16_test (void)
>  {
>y = _mm512_cvtbf8_ph (z1);
> -  y = _mm512_mask_cvtbf8_ph (z, m16, z1);
> -  y = _mm512_maskz_cvtbf8_ph (m16, z1);
> +  y = _mm512_mask_cvtbf8_ph (z, m32, z1);
> +  y = _mm512_maskz_cvtbf8_ph (m32, z1);
>  }
> diff --git a/gcc/testsuite/gcc.target/i386/avx10_2-convert-1.c 
> b/gcc/testsuite/gcc.target/i386/avx10_2-convert-1.c
> index 57b5fce7fb6..729496f7173 100644
> --- a/gcc/testsuite/gcc.target/i386/avx10_2-convert-1.c
> +++ b/gcc/testsuite/gcc.target/i386/avx10_2-convert-1.c
> @@ -289,6 +289,6 @@ avx10_2_cvtbf8_fp16_test (void)
>y = _mm_maskz_cvtbf8_ph (m8, z3);
>
>y2 = _mm256_cvtbf8_ph (z3);
> -  y2 = _mm256_mask_cvtbf8_ph (z2, m8, z3);
> -  y2 = _mm256_maskz_cvtbf8_ph (m8, z3);
> +  y2 = _mm256_mask_cvtbf8_ph (z2, m16, z3);
> +  y2 = _mm256_maskz_cvtbf8_ph (m16, z3);
>  }
> --
> 2.31.1
>


-- 
BR,
Hongtao

[PATCH v1] RISC-V: Tweak asm check for test case multiple_rgroup_zbb.c

[pan2 . li]

From: Pan Li 

The changes to vsetvl pass since 14 result in the asm check failure,
update the asm check to meet the newest behavior.

The below test suites are passed for this patch.
* The rv64gcv fully regression test.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_zbb.c: Tweak
the asm check for vsetvl.

Signed-off-by: Pan Li 
---
 .../riscv/rvv/autovec/partial/multiple_rgroup_zbb.c  | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git 
a/gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_zbb.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_zbb.c
index a851229daac..a6d4b77ccd7 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_zbb.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_zbb.c
@@ -20,4 +20,7 @@ test (uint16_t *__restrict f, uint32_t *__restrict d, 
uint64_t *__restrict e,
 }
 }
 
-/* { dg-final { scan-assembler-times 
"vsetvli\tzero,\s*\[a-z0-9\]+,\s*e16,\s*m1,\s*ta,\s*ma" 4 } } */
+/* { dg-final { scan-assembler-times 
"vsetvli\tzero,\s*\[a-z0-9\]+,\s*e16,\s*m\[1248\],\s*ta,\s*ma" 1 } } */
+/* { dg-final { scan-assembler-times 
"vsetvli\tzero,\s*\[a-z0-9\]+,\s*e32,\s*m\[1248\],\s*ta,\s*ma" 1 } } */
+/* { dg-final { scan-assembler-times 
"vsetvli\tzero,\s*\[a-z0-9\]+,\s*e64,\s*m\[1248\],\s*ta,\s*ma" 1 } } */
+/* { dg-final { scan-assembler-times 
"vsetivli\tzero,\s*\[0-9\]+,\s*e64,\s*m\[1248\],\s*ta,\s*ma" 1 } } */
-- 
2.43.0

Re: Re: [PATCH v2] c++: Check invalid use of constrained auto with trailing return type [PR100589]

[Da Xie]

* Patrick Palka  [2025-03-05 11:15:06]:

> On Tue, 4 Mar 2025, Patrick Palka wrote:
> 
> > On Sun, 2 Mar 2025, Da Xie wrote:
> > 
> > > Add check for constrained auto type specifier in function declaration or
> > > function type declaration with trailing return type. Issue error if such
> > > usage is detected.
> > > 
> > > Test file renamed, and added a new test for type declaration.
> > > 
> > > Successfully bootstrapped and regretested on x86_64-pc-linux-gnu:
> > > Added 6 passed and 4 unsupported tests.
> > > 
> > >   PR c++/100589
> > > 
> > > gcc/cp/ChangeLog:
> > > 
> > >   * decl.cc (grokdeclarator): Issue an error for a declarator with
> > >   constrained auto type specifier and trailing return types. Include
> > >   function names if available.
> > > 
> > > gcc/testsuite/ChangeLog:
> > > 
> > >   * g++.dg/cpp2a/concepts-pr100589.C: New test.
> > 
> > LGTM, thanks!  Jason, shall I push this to trunk?
> 
> Pushed as r15-7834-g7439febd94368f.
> 
Many thanks! I'm a GCC newbie, and this reviewing process has taught me a lot.
> > 
> > > 
> > > Signed-off-by: Da Xie 
> > > ---
> > >  gcc/cp/decl.cc | 13 +
> > >  gcc/testsuite/g++.dg/cpp2a/concepts-pr100589.C |  9 +
> > >  2 files changed, 22 insertions(+)
> > >  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-pr100589.C
> > > 
> > > diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
> > > index 9ca8c6c4481..337ee65752e 100644
> > > --- a/gcc/cp/decl.cc
> > > +++ b/gcc/cp/decl.cc
> > > @@ -14037,6 +14037,19 @@ grokdeclarator (const cp_declarator *declarator,
> > >   "invalid use of %");
> > >   return error_mark_node;
> > > }
> > > + else if (is_constrained_auto (type))
> > > +   {
> > > + if (funcdecl_p)
> > > +   error_at (typespec_loc,
> > > + "%qs function with trailing return type "
> > > + "has constrained % type specifier "
> > > + "rather than plain %",
> > > + name);
> > > + else
> > > +   error_at (typespec_loc,
> > > + "invalid use of constrained % type");
> > > + return error_mark_node;
> > > +   }
> > >   tree tmpl = CLASS_PLACEHOLDER_TEMPLATE (auto_node);
> > >   if (!tmpl)
> > > if (tree late_auto = type_uses_auto (late_return_type))
> > > diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-pr100589.C 
> > > b/gcc/testsuite/g++.dg/cpp2a/concepts-pr100589.C
> > > new file mode 100644
> > > index 000..0c60d31f29b
> > > --- /dev/null
> > > +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-pr100589.C
> > > @@ -0,0 +1,9 @@
> > > +// PR c++/100589
> > > +// { dg-do compile { target c++20 } }
> > > +
> > > +template
> > > +concept false_concept = false;
> > > +
> > > +false_concept auto f() -> int; // { dg-error "'f' .* trailing return 
> > > type.* constrained 'auto'" }
> > 
> > I can replace the use of .* with \[^\r\n\]* before pushing.
> > 
> > > +
> > > +using type = false_concept auto() -> int; // { dg-error "invalid use of 
> > > constrained 'auto' type"}
> 
> N.B. I added a missing space between the " and } that caused this
> dircetive to get ignored.
> 
Sorry for the misses. I fixed and checked it locally, and the test
passed.
> > > -- 
> > > 2.34.1
> > > 
> > > 
> > 

[PATCH v4] get source line for diagnostic from preprocessed file [PR preprocessor/79106]

[Bader, Lucas]

We found one more issue with the patch in our internal compile cluster. When 
using "-fdirectives-only", linemarkers do not always start at the beginning of 
a line.
This version of the patch (last submission 
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675450.html) fixes this 
by skipping
blanks before parsing the linemarker. Also rebased to latest trunk.

Best
Lucas

--

Within a compile cluster, only the preprocessed output of GCC is transferred
to remote nodes for compilation. When GCC produces advanced diagnostics
(with -fdiagnostics-show-caret), e.g. prints out the affected source
line and fixit hints, it attempts to read the source file again, even when
compiling a preprocessed file (-fpreprocessed). This leads to wrong
diagnostics when building with a compile cluster, or, more generally,
when changing or deleting the original source file.

This change alters GCC to read from the preprocessed file instead by
calculating the corresponding source line. This behavior is consistent
with clang.

The patch implements this efficiently by using a cache for
linemarkers that are already seen and a memoization of lines
that have already been requested.

gcc/c-family/ChangeLog:

PR preprocessor/79106
* c-opts.cc (c_common_handle_option): Pass -fpreprocessed
option value to global diagnostic configuration.

gcc/ChangeLog:

PR preprocessor/79106
* diagnostic-show-locus.cc (get_source_line_maybe_preprocessed): Read
line from source or preprocessed file based on -fpreprocessed value.
(layout::calculate_x_offset_display): Use new function.
(source_line::source_line): Use new function.
(layout_printer::print_line): Use new function.
* diagnostic.cc (diagnostic_context::initialize): Initialize new
members.
* diagnostic.h: Add new members for reading source lines from
preprocessed files.
* input.cc (file_cache_slot::evict): Also empty linemarker
cache.
(file_cache_slot::create): Initialize new linemarker cache.
(file_cache_slot::file_cache_slot): Initialize new linemarker
cache.
(file_cache_slot::~file_cache_slot): Delete linemarker cache.
(file_cache_slot::linemarker_cache::add_linemarker_unique): New
function for adding linemarkers to the linemarker cache.
(file_cache_slot::linemarker_cache::add_result_line): Memoize
single result of get_source_line_preprocessed.
(file_cache_slot::linemarker_cache::get_result_line): Retrieve
memoized result of get_source_line_preprocessed.
(is_linemarker_for_file): New function for testing a line for
a linemarker.
(file_cache::get_source_line_preprocessed): New function for
reading lines from preprocessed sources.
(test_parsing_linemarker): New test case.
(test_linemarker_cache): New test case.
(test_reading_source_line_preprocessed): New test case.
(input_cc_tests): Add new test cases.
* input.h (class file_cache): Add new member function.
* opts-global.cc (read_cmdline_options): Pass input filename to global
diagnostic context.

gcc/testsuite/ChangeLog:

PR preprocessor/79106
* g++.dg/lookup/missing-std-include-11.C: Adapt to new behavior.

Signed-off-by: Lucas Bader 
---
 gcc/c-family/c-opts.cc|   1 +
 gcc/diagnostic-show-locus.cc  |  25 +-
 gcc/diagnostic.cc |   2 +
 gcc/diagnostic.h  |   6 +
 gcc/input.cc  | 696 ++
 gcc/input.h   |   2 +
 gcc/opts-global.cc|   4 +
 .../g++.dg/lookup/missing-std-include-11.C|   2 +-
 8 files changed, 733 insertions(+), 5 deletions(-)

diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index d43b3aef102..40c38ae9318 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -534,6 +534,7 @@ c_common_handle_option (size_t scode, const char *arg, 
HOST_WIDE_INT value,
 
 case OPT_fpreprocessed:
   cpp_opts->preprocessed = value;
+  global_dc->m_is_preprocessed = value;
   break;
 
 case OPT_fdebug_cpp:
diff --git a/gcc/diagnostic-show-locus.cc b/gcc/diagnostic-show-locus.cc
index 898efe74acf..f08d325bfcf 100644
--- a/gcc/diagnostic-show-locus.cc
+++ b/gcc/diagnostic-show-locus.cc
@@ -1768,6 +1768,20 @@ layout::calculate_linenum_width ()
   m_linenum_width = MAX (m_linenum_width, m_options.min_margin_width - 1);
 }
 
+/* Get the source line depending on the global context, i.e. whether we are
+   compiling a preprocessed file or not.  */
+static char_span
+get_source_line_maybe_preprocessed (file_cache &fc, const char *filename,
+   int line_num)
+{
+  if (global_d

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

[Richard Biener]

On Wed, Mar 5, 2025 at 12:46 PM Richard Biener
 wrote:
>
> On Wed, Mar 5, 2025 at 11:43 AM Richard Biener
>  wrote:
> >
> > On Tue, Mar 4, 2025 at 7:18 PM James K. Lowden  
> > wrote:
> > >
> > > On Tue, 4 Mar 2025 00:08:16 +0100
> > > Jakub Jelinek  wrote:
> > >
> > > > On Mon, Mar 03, 2025 at 05:21:38PM -0500, James K. Lowden wrote:
> > > > > However IMO, the incantation:
> > > > >
> > > > > make install DESTDIR=/foo
> > > > >
> > > > > is invalid.  The compiler's library search path is fixed when the
> > > > > compiler is built, based on configure options.  Installing into an
> > > > > arbitrary directory cannot work; there is no opportunity then to
> > > > > alter the gcobol binary.
> > > >
> > > > This is how most distros install stuff for their packaging systems,
> > > > make install DESTDIR=/some/directory
> > > > and then everything under /some/directory
> > > > is packaged into the package.
> > > > GCC is generally relocatable, the compiler driver should find the
> > > > compiler and library/include directories etc. relative to where the
> > > > driver resides in the filesystem.
> > >
> > > Thank you for taking the time to explain that, Jakub.  I stand
> > > corrected, and I believe you'll find that DESTDIR works as intended
> > > using the current cobol-patched branch.  It works here for me.
> > >
> > > Somehow, despite reading the automake documentation over and over
> > > these last several days while we struggled to bring the libgcobol
> > > build process into the 20th [sic] century, I didn't put 2 + 2 together.
> > > Looking at it now, I see that by using automake we get DESTDIR for free,
> > > provided (as we do) that we use libtool for installation.
> > >
> > > In short, despite not trying to support DESTDIR, we do anyway, by happy
> > > accident.  And we are now better informed.
> >
> > Thanks.  Checking cobol-patched again I see
> >
> > obj2> make install DESTDIR=/home/rguenther/install/gcc-cobol
> > ...
> > libtool: install: /usr/bin/install -c .libs/libgcobol.so.1.0.0T
> > /usr/local/lib64/../lib64/libgcobol.so.1.0.0
> > /usr/bin/install: cannot create regular file
> > '/usr/local/lib64/../lib64/libgcobol.so.1.0.0': Permission denied
> > make[2]: *** [Makefile:956: install] Error 1
> > make[2]: Leaving directory 
> > '/home/rguenther/obj2/x86_64-pc-linux-gnu/libgcobol'
> > make[1]: *** [Makefile:18349: install-target-libgcobol] Error 2
> > make[1]: Leaving directory '/home/rguenther/obj2'
> > make: *** [Makefile:2671: install] Error 2
> >
> > so a DESTDIR install isn't quite working yet.
> >
> > install: libgcobol$(libsuffix).la
> > $(LIBTOOL) --mode=install $(INSTALL) $^ $(libdir)/../lib64
> >
> > the usual way would be to have automake/libtool generate the install rule by
> > only doing
> >
> > toolexeclib_LTLIBRARIES = libgcobol.la
> >
> > you have
> >
> > lib_LTLIBRARIES = libgcobol.la
> >
> > so simply removing the install: rule might work (there's toolexeeclib vs. 
> > lib,
> > this might or might not mean --enable-version-specific-runtime-libs will
> > break).

... aaand it fails: (../gcc-cobol/configure --enable-languages=cobol
--disable-bootstrap --enable-checking=release
--enable-version-specific-runtime-libs)

> make install DESTDIR=/home/rguenther/install/gcc-cobol
...
libtool: install: error: cannot install `libgcobol.la' to a directory
not ending in /usr/local/lib64/../lib64
make[3]: *** [Makefile:512: install-toolexeclibLTLIBRARIES] Error 1
make[3]: Leaving directory '/home/rguenther/obj2/x86_64-pc-linux-gnu/libgcobol'
make[2]: *** [Makefile:825: install-am] Error 2
make[2]: Leaving directory '/home/rguenther/obj2/x86_64-pc-linux-gnu/libgcobol'
make[1]: *** [Makefile:18349: install-target-libgcobol] Error 2
make[1]: Leaving directory '/home/rguenther/obj2'
make: *** [Makefile:2671: install] Error 2

see how others (like libatomic) handle --enable-version-specific-runtime-libs
in their configure.ac.  That later adjusts toolexeclibdir - you also seem to
miss using GCC_WITH_TOOLEXECLIBDIR in libgcobol/configure.ac.

I really always go by copy&pasting from working examples ... there's to
many specialities in how GCC does things :/

Richard.

> >
> > [time passes]
> >
> > So dropping the install rule makes make install succeed but there's no
> > libgcobol installed.  I have the wrong automake on the test machine so
> > can't quickly check what happens when using toolexeclib_LTLIBRARIES
>
> So I now checked and using toolexeclib_LTLIBRARIES = libgcobol.la works:
>
> > find install/gcc-cobol/ -name libgcobol*
> install/gcc-cobol/usr/local/lib64/libgcobol.la
> install/gcc-cobol/usr/local/lib64/libgcobol.so.1
> install/gcc-cobol/usr/local/lib64/libgcobol.a
> install/gcc-cobol/usr/local/lib64/libgcobol.so.1.0.0
> install/gcc-cobol/usr/local/lib64/libgcobol.so
>
> and the installed compiler behaves as intended.  I can trick -m32 to "work"
> by using the generic gcc diriver:
>
> > ./install/gcc-cobol/usr/local/bin/gcc -x cobol t.cob -m32 -c
>
> but I think this is a less 

[PATCH] RISC-V: Imply C from Zca whenever possible [PR119122]

[Yuriy Kolerov]

GCC must imply C extension from Zca extension when it's
possible. It's necessary for achieving compatibility
between different march strings which in fact may be
the same.

E.g., if rv32ic multilib configuration is presented in
GCC, then GCC will not choose this configuration for
linking if -march=rv32i_zca is passed.

Here is a more practical example. From RISC-V
Instruction Set Manual:

Therefore common ISA strings can be updated as follows
to include the relevant Zc extensions, for example:
- RV32IMC becomes RV32IM_Zce
- RV32IMCF becomes RV32IMF_Zce

With current implication rules this will not work well
if rv32imc configuration is presented and a user
passes -march=rv32im_zce. This is how we can check
this with a simple empty test.c source file:

$ riscv64-unknown-elf-gcc -march=rv32ic -mabi=ilp32 -mriscv-attribute -S test.c
$ grep "attribute arch" test.s
.attribute arch, "rv32i2p1_c2p0_zca1p0"
$ riscv64-unknown-elf-gcc -march=rv32i_zce -mabi=ilp32 -mriscv-attribute -S 
test.c
$ grep "attribute arch" test.s
.attribute arch, 
"rv32i2p1_zicsr2p0_zca1p0_zcb1p0_zce1p0_zcmp1p0_zcmt1p0"

According to current GCC these march strings are
incompatible: the first one contains c2p0 and the
second on doesn't.

To introduce such implication rule we need to carefully
cover all possible combinations with these extensions:
zca, zcf, zcd, F and D.

According to the same manual:

As C defines the same instructions as Zca, Zcf and
Zcd, the rule is that:
- C always implies Zca
- C+F implies Zcf (RV32 only)
- C+D implies Zcd

Here is a full list of cases:

1. rv32i_zca implies C.
2. rv32if_zca_zcf implies C.
3. rv32ifd_zca_zcf_zcd implies C.
4. rv64i_zca implies C.
5. rv64ifd_zca_zcd implies C.

PR target/119122

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc: add a rule for
Zca to C implication.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/arch-25.c: Fix dg-error expectation.
* gcc.target/riscv/attribute-c-1.c: New test.
* gcc.target/riscv/attribute-c-2.c: New test.
* gcc.target/riscv/attribute-c-3.c: New test.
* gcc.target/riscv/attribute-c-4.c: New test.
* gcc.target/riscv/attribute-c-5.c: New test.
* gcc.target/riscv/attribute-c-6.c: New test.
* gcc.target/riscv/attribute-c-7.c: New test.
* gcc.target/riscv/attribute-c-8.c: New test.
* gcc.target/riscv/attribute-zce-1.c: Update Zce tests.
* gcc.target/riscv/attribute-zce-2.c: Likewise.
* gcc.target/riscv/attribute-zce-3.c: Likewise
* gcc.target/riscv/attribute-zce-4.c: Likewise.

Signed-off-by: Yuriy Kolerov 
---
 gcc/common/config/riscv/riscv-common.cc   | 31 +++
 gcc/testsuite/gcc.target/riscv/arch-25.c  |  2 +-
 .../gcc.target/riscv/attribute-c-1.c  |  6 
 .../gcc.target/riscv/attribute-c-2.c  |  6 
 .../gcc.target/riscv/attribute-c-3.c  |  6 
 .../gcc.target/riscv/attribute-c-4.c  |  6 
 .../gcc.target/riscv/attribute-c-5.c  |  6 
 .../gcc.target/riscv/attribute-c-6.c  |  6 
 .../gcc.target/riscv/attribute-c-7.c  |  6 
 .../gcc.target/riscv/attribute-c-8.c  |  6 
 .../gcc.target/riscv/attribute-zce-1.c|  2 +-
 .../gcc.target/riscv/attribute-zce-2.c|  2 +-
 .../gcc.target/riscv/attribute-zce-3.c|  2 +-
 .../gcc.target/riscv/attribute-zce-4.c|  2 +-
 14 files changed, 84 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-c-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-c-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-c-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-c-4.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-c-5.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-c-6.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-c-7.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/attribute-c-8.c

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index b34409adf39..15df22d5377 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -218,6 +218,37 @@ static const riscv_implied_info_t riscv_implied_info[] =
{
  return subset_list->xlen () == 32 && subset_list->lookup ("f");
}},
+  {"zca", "c",
+   [] (const riscv_subset_list *subset_list) -> bool
+   {
+ /* For RV32 Zca implies C for one of these combinations of
+   extensions: Zca, F_Zca_Zcf and FD_Zca_Zcf_Zcd.  */
+ if (subset_list->xlen () == 32)
+   {
+if (subset_list->lookup ("d"))
+  return subset_list->lookup ("zcf") && subset_list->lookup ("zcd");
+
+if (subset_list->lookup ("f"))
+  return subset_list->lookup ("zcf");
+
+return true;
+   }
+
+

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

[Richard Biener]

On Wed, Mar 5, 2025 at 11:43 AM Richard Biener
 wrote:
>
> On Tue, Mar 4, 2025 at 7:18 PM James K. Lowden  
> wrote:
> >
> > On Tue, 4 Mar 2025 00:08:16 +0100
> > Jakub Jelinek  wrote:
> >
> > > On Mon, Mar 03, 2025 at 05:21:38PM -0500, James K. Lowden wrote:
> > > > However IMO, the incantation:
> > > >
> > > > make install DESTDIR=/foo
> > > >
> > > > is invalid.  The compiler's library search path is fixed when the
> > > > compiler is built, based on configure options.  Installing into an
> > > > arbitrary directory cannot work; there is no opportunity then to
> > > > alter the gcobol binary.
> > >
> > > This is how most distros install stuff for their packaging systems,
> > > make install DESTDIR=/some/directory
> > > and then everything under /some/directory
> > > is packaged into the package.
> > > GCC is generally relocatable, the compiler driver should find the
> > > compiler and library/include directories etc. relative to where the
> > > driver resides in the filesystem.
> >
> > Thank you for taking the time to explain that, Jakub.  I stand
> > corrected, and I believe you'll find that DESTDIR works as intended
> > using the current cobol-patched branch.  It works here for me.
> >
> > Somehow, despite reading the automake documentation over and over
> > these last several days while we struggled to bring the libgcobol
> > build process into the 20th [sic] century, I didn't put 2 + 2 together.
> > Looking at it now, I see that by using automake we get DESTDIR for free,
> > provided (as we do) that we use libtool for installation.
> >
> > In short, despite not trying to support DESTDIR, we do anyway, by happy
> > accident.  And we are now better informed.
>
> Thanks.  Checking cobol-patched again I see
>
> obj2> make install DESTDIR=/home/rguenther/install/gcc-cobol
> ...
> libtool: install: /usr/bin/install -c .libs/libgcobol.so.1.0.0T
> /usr/local/lib64/../lib64/libgcobol.so.1.0.0
> /usr/bin/install: cannot create regular file
> '/usr/local/lib64/../lib64/libgcobol.so.1.0.0': Permission denied
> make[2]: *** [Makefile:956: install] Error 1
> make[2]: Leaving directory 
> '/home/rguenther/obj2/x86_64-pc-linux-gnu/libgcobol'
> make[1]: *** [Makefile:18349: install-target-libgcobol] Error 2
> make[1]: Leaving directory '/home/rguenther/obj2'
> make: *** [Makefile:2671: install] Error 2
>
> so a DESTDIR install isn't quite working yet.
>
> install: libgcobol$(libsuffix).la
> $(LIBTOOL) --mode=install $(INSTALL) $^ $(libdir)/../lib64
>
> the usual way would be to have automake/libtool generate the install rule by
> only doing
>
> toolexeclib_LTLIBRARIES = libgcobol.la
>
> you have
>
> lib_LTLIBRARIES = libgcobol.la
>
> so simply removing the install: rule might work (there's toolexeeclib vs. lib,
> this might or might not mean --enable-version-specific-runtime-libs will
> break).
>
> [time passes]
>
> So dropping the install rule makes make install succeed but there's no
> libgcobol installed.  I have the wrong automake on the test machine so
> can't quickly check what happens when using toolexeclib_LTLIBRARIES

So I now checked and using toolexeclib_LTLIBRARIES = libgcobol.la works:

> find install/gcc-cobol/ -name libgcobol*
install/gcc-cobol/usr/local/lib64/libgcobol.la
install/gcc-cobol/usr/local/lib64/libgcobol.so.1
install/gcc-cobol/usr/local/lib64/libgcobol.a
install/gcc-cobol/usr/local/lib64/libgcobol.so.1.0.0
install/gcc-cobol/usr/local/lib64/libgcobol.so

and the installed compiler behaves as intended.  I can trick -m32 to "work"
by using the generic gcc diriver:

> ./install/gcc-cobol/usr/local/bin/gcc -x cobol t.cob -m32 -c

but I think this is a less important issue.

Richard.


> >
> > Regards,
> >
> > --jkl

Re: [PATCH][stage1] tree-optimization/119103 - missed overwidening detection for shift

[Richard Biener]

On Tue, 4 Mar 2025, Richard Sandiford wrote:

> Richard Biener  writes:
> > When vectorizing a shift of u16 data by an amount that's known to
> > be less than 16 we currently fail to emit a vector u16 shift.  The
> > first reason is that the promotion of the shift amount is hoisted
> > only by PRE and that cannot preserve range info, the second reason
> > is that pattern detection doesn't use range info when computing
> > the precision required for an operation.
> >
> > The following addresses the first issue by making LIM hoist all
> > expressions for the pass that runs right before PRE and the
> > second issue by querying ranges for the shift amount.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> >
> > PR tree-optimization/119103
> > * tree-ssa-loop-im.cc (in_loop_pipeline): Globalize.
> > (compute_invariantness): Override costing when we run
> > right before PRE and PRE is enabled.
> > (pass_lim::execute): Adjust.
> > * tree-vect-patterns.cc (vect_determine_precisions_from_users):
> > For variable shift amounts use range information.
> >
> > * gcc.target/i386/pr119103.c: New testcase.
> 
> Nice!
> 
> > [...]
> > diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
> > index 4f0a7ea162b..09408359cf2 100644
> > --- a/gcc/tree-vect-patterns.cc
> > +++ b/gcc/tree-vect-patterns.cc
> > @@ -6544,10 +6544,19 @@ vect_determine_precisions_from_users (stmt_vec_info 
> > stmt_info, gassign *stmt)
> >  case RSHIFT_EXPR:
> >{
> > tree shift = gimple_assign_rhs2 (stmt);
> > -   if (TREE_CODE (shift) != INTEGER_CST
> > -   || !wi::ltu_p (wi::to_widest (shift), precision))
> > +   unsigned int const_shift;
> > +   wide_int min_shift, max_shift;
> > +   if (TREE_CODE (shift) == SSA_NAME
> > +   && vect_get_range_info (shift, &min_shift, &max_shift)
> > +   && wi::ge_p (min_shift, 0, TYPE_SIGN (TREE_TYPE (shift)))
> > +   && wi::lt_p (max_shift, TYPE_PRECISION (type),
> > +TYPE_SIGN (TREE_TYPE (shift
> > + const_shift = max_shift.to_uhwi ();
> 
> Don't we need to use min_shift rather than max_shift for LSHIFT_EXPR's:
> 
>   /* We need CONST_SHIFT fewer bits of the input.  */
>   min_input_precision = (MAX (operation_precision, const_shift)
>  - const_shift);
> 
> ?  If so, I guess that means replacing const_shift with a minimum and
> a maximum.

Right - fixed as below.

Richard.

>From 41db126ca782410c69480b9d305c240b5e9166b2 Mon Sep 17 00:00:00 2001
From: Richard Biener 
Date: Tue, 4 Mar 2025 10:34:39 +0100
Subject: [PATCH] tree-optimization/119103 - missed overwidening detection for
 shift
To: gcc-patches@gcc.gnu.org

When vectorizing a shift of u16 data by an amount that's known to
be less than 16 we currently fail to emit a vector u16 shift.  The
first reason is that the promotion of the shift amount is hoisted
only by PRE and that cannot preserve range info, the second reason
is that pattern detection doesn't use range info when computing
the precision required for an operation.

The following addresses the first issue by making LIM hoist all
expressions for the pass that runs right before PRE and the
second issue by querying ranges for the shift amount.

PR tree-optimization/119103
* tree-ssa-loop-im.cc (in_loop_pipeline): Globalize.
(compute_invariantness): Override costing when we run
right before PRE and PRE is enabled.
(pass_lim::execute): Adjust.
* tree-vect-patterns.cc (vect_determine_precisions_from_users):
For variable shift amounts use range information.

* gcc.target/i386/pr119103.c: New testcase.
---
 gcc/testsuite/gcc.target/i386/pr119103.c | 13 
 gcc/tree-ssa-loop-im.cc  | 10 +++--
 gcc/tree-vect-patterns.cc| 26 +---
 3 files changed, 40 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr119103.c

diff --git a/gcc/testsuite/gcc.target/i386/pr119103.c 
b/gcc/testsuite/gcc.target/i386/pr119103.c
new file mode 100644
index 000..57210dc3bbe
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr119103.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mavx2" } */
+
+void lshift(unsigned short *x, unsigned char amount)
+{
+  if (amount > 15)
+__builtin_unreachable();
+
+  for (int i = 0; i < 16; i++)
+x[i] <<= amount;
+}
+
+/* { dg-final { scan-assembler "vpsllw" } } */
diff --git a/gcc/tree-ssa-loop-im.cc b/gcc/tree-ssa-loop-im.cc
index 225964c6215..a3ca5af3e3e 100644
--- a/gcc/tree-ssa-loop-im.cc
+++ b/gcc/tree-ssa-loop-im.cc
@@ -143,6 +143,8 @@ public:
   different modes.  */
 };
 
+static bool in_loop_pipeline;
+
 /* We use six bits per loop in the ref->dep_loop bitmap to record
the dep_kind x dep_state combinations.  */
 
@@ -1239,7 +1241,11 @@ compute_invariantness (basic_block bb)
   lim_data->c

Re: [Fortran, Patch, PR104684, v1] Fix gimple error when pointer assigning alloc array.

[Andre Vehreschild]

Hi Harald,

thanks for the review. Committed as gcc-15-7826-g705ae582d51.

The fix for pr107143 may be something similar. I am having a harder time getting
a testcase correct, then fixing the gimplification fault (that's fixed, but the
test is fouling me).

Thanks again,
Andre

On Tue, 4 Mar 2025 22:58:37 +0100
Harald Anlauf  wrote:

> Hi Andre,
>
> Am 04.03.25 um 17:11 schrieb Andre Vehreschild:
> > Hi all,
> >
> > attached patch fixes a gimplification fault when a pointer assignment to an
> > allocatable array is done. The tree type is different, because of that flag
> > in the lang_specific structure. View-converting the type fixes the issue.
> >
> > Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
>
> this LGTM.
>
> I am wondering if this kind of fix also helps with pr107143,
> where pointer remapping is used, but your code is not reached
> in that situation.
>
> Thanks for the patch!
>
> Harald
>
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>


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

[pushed] MAINTAINERS: Add myself to write after approval

[Tomasz Kaminski]

Pushed to the trunk.
commit 2653d988e92bc9d70a3ac674d1b819610858e00a
Author: Tomasz Kamiński 
Date:   Wed Mar 5 10:33:23 2025 +0100

MAINTAINERS: Add myself to write after approval

ChangeLog:

* MAINTAINERS: Add myself.

diff --git a/MAINTAINERS b/MAINTAINERS
index 193cd802a07..84c0a6b892b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -570,6 +570,7 @@ Teresa Johnson  tejohnson   

 Kean Johnston   -   
 Phillip Jordan  pmj 
 Tim Josling timjosling  
+Tomasz Kamiński tkaminsk
 Victor Kaplanskyvictork 
 Evgeny Karpov   -   
 Filip Kastl pheeck  

[PATCH v2] c++: Don't replace INDIRECT_REFs by a const capture proxy too eagerly [PR117504]

[Simon Martin]

Hi Jason,

On Tue Mar 4, 2025 at 11:47 PM CET, Jason Merrill wrote:
> On 2/14/25 12:08 PM, Simon Martin wrote:
>> We have been miscompiling the following valid code since GCC8, and
>> r8-3497-g281e6c1d8f1b4c
>> 
>> === cut here ===
>> struct span {
>>span (const int (&__first)[1]) : _M_ptr (__first) {}
>>int operator[] (long __i) { return _M_ptr[__i]; }
>>const int *_M_ptr;
>> };
>> void foo () {
>>constexpr int a_vec[]{1};
>>auto vec{[&a_vec]() -> span { return a_vec; }()};
>> }
>> === cut here ===
>> 
>> The problem is that perform_implicit_conversion_flags (via
>> mark_rvalue_use) replaces "a_vec" in the return statement by a
>> CONSTRUCTOR representing a_vec's constant value, and then takes its
>> address when invoking span's constructor. So we end up with an instance
>> that points to garbage instead of a_vec's storage.
>> 
>> I've tried many things to somehow recover from this replacement, but I
>> actually think we should not do it when converting to a class type: we
>> have no idea whether the conversion will involve a constructor taking an
>> address or reference. So we should assume it's the case, and call
>> mark_lvalue_use, not mark_rvalue_use (I might very weel be overseeing
>> things, and feedback is more than welcome).
>
> Yeah, those mark_*_use calls seem misplaced, they should be called 
> instead by the code that actually does the conversion.
>
> What if we replace all of them here with just mark_exp_read?  Or nothing?
Thanks for the suggestions; simply removing those calls actually works. This
is what the attached updated patch does.

Successfully tested on x86_64-pc-linux-gnu. OK for trunk? And if so, OK for
branches after 2-3 weeks since it's a wrong code bug?

Simon

From cbb1fae22ff259b75f4304b1b0e6d6f84216b3d9 Mon Sep 17 00:00:00 2001
From: Simon Martin 
Date: Wed, 5 Mar 2025 12:42:37 +0100
Subject: [PATCH] c++: Don't replace INDIRECT_REFs by a const capture proxy too
 eagerly [PR117504]

We have been miscompiling the following valid code since GCC8, and
r8-3497-g281e6c1d8f1b4c

=== cut here ===
struct span {
  span (const int (&__first)[1]) : _M_ptr (__first) {}
  int operator[] (long __i) { return _M_ptr[__i]; }
  const int *_M_ptr;
};
void foo () {
  constexpr int a_vec[]{1};
  auto vec{[&a_vec]() -> span { return a_vec; }()};
}
=== cut here ===

The problem is that perform_implicit_conversion_flags (via
mark_rvalue_use) replaces "a_vec" in the return statement by a
CONSTRUCTOR representing a_vec's constant value, and then takes its
address when invoking span's constructor. So we end up with an instance
that points to garbage instead of a_vec's storage.

As per Jason's suggestion, this patch simply removes the calls to
mark_*_use from perform_implicit_conversion_flags, which fixes the PR.

Successfully tested on x86_64-pc-linux-gnu.

PR c++/117504

gcc/cp/ChangeLog:

* call.cc (perform_implicit_conversion_flags): Don't call
mark_{l,r}value_use.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/constexpr-117504.C: New test.
* g++.dg/cpp2a/constexpr-117504a.C: New test.

---
 gcc/cp/call.cc|  5 --
 gcc/testsuite/g++.dg/cpp2a/constexpr-117504.C | 60 +++
 .../g++.dg/cpp2a/constexpr-117504a.C  | 12 
 3 files changed, 72 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-117504.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-117504a.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index f7b4cccb1c7..c1c8987ec8b 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -13971,11 +13971,6 @@ perform_implicit_conversion_flags (tree type, tree 
expr,
   conversion *conv;
   location_t loc = cp_expr_loc_or_input_loc (expr);
 
-  if (TYPE_REF_P (type))
-expr = mark_lvalue_use (expr);
-  else
-expr = mark_rvalue_use (expr);
-
   if (error_operand_p (expr))
 return error_mark_node;
 
diff --git a/gcc/testsuite/g++.dg/cpp2a/constexpr-117504.C 
b/gcc/testsuite/g++.dg/cpp2a/constexpr-117504.C
new file mode 100644
index 000..290d3dfd61e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/constexpr-117504.C
@@ -0,0 +1,60 @@
+// PR c++/117504 - Initial report
+// { dg-do "run" { target c++20 } }
+
+struct span {
+  span (const int (&__first)[1]) : _M_ptr (__first) {}
+  int operator[] (long __i) { return _M_ptr[__i]; }
+  const int *_M_ptr;
+};
+
+constexpr int a_global_vec[]{1};
+span myFunctor() {
+  return a_global_vec;
+}
+
+int main() {
+  constexpr int a_vec[]{1};
+
+  //
+  // This PR's case, that used to be miscompiled.
+  //
+  auto lambda_1 = [&a_vec] () -> span { return a_vec; };
+  auto vec_1 { lambda_1 () };
+  if (vec_1[0] != 1)
+__builtin_abort ();
+
+  // Variant that used to be miscompiled as well.
+  auto lambda_2 = [&] () -> span { return a_vec; };
+  auto vec_2 { lambda_2 () };
+  if (vec_2[0] != 1)
+__builtin_abort ();
+
+  //
+  // Related cases that worked already.
+  //
+  auto lambda_3 = [&a_vec] () /* 

[PATCH] arm: testsuite: improve guard checks for arm_neon.h

[Richard Earnshaw]

The header file arm_neon.h provides the Advanced SIMD intrinsics that
are available on armv7 or later A & R profile cores.  However, they
are not compatible with M-profile and we also need to ensure that the
FP instructions are enabled (with -mfloat-abi=softfp/hard).  That
leads to some complicated checking as arm_neon.h includes stdint.h
and, at least on linux, that can require that the appropriate ABI
bits/ headers are also installed.

This patch adds a new check to target-supports.exp to establish the
minimal set of option overrides needed to enable use of this header in
a test.

gcc/testsuite:
* lib/target-supports.exp
(check_effective_target_arm_neon_h_ok_nocache): New function.
(check_effective_target_arm_neon_h_ok): Likewise.
(add_options_for_arm_neon_h): Likewise.
(check_effective_target_arm_libc_fp_abi_ok_nocache): Allow any
Arm target, not just arm32.
* gcc.target/arm/attr-neon-builtin-fail.c: Use it.
* gcc.target/arm/attr-neon-builtin-fail2.c: Likewise.
* gcc.target/arm/attr-neon-fp16.c: Likewise.
* gcc.target/arm/attr-neon2.c: Likewise.
---

I'm going to wait 24 hrs before committing this as I'd like to see the
results of the CI first.

R.

 .../gcc.target/arm/attr-neon-builtin-fail.c   |  6 +--
 .../gcc.target/arm/attr-neon-builtin-fail2.c  |  5 +-
 gcc/testsuite/gcc.target/arm/attr-neon-fp16.c |  4 +-
 gcc/testsuite/gcc.target/arm/attr-neon2.c |  5 +-
 gcc/testsuite/lib/target-supports.exp | 53 ++-
 5 files changed, 60 insertions(+), 13 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c 
b/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c
index fb6e0b9cd66..645d708f005 100644
--- a/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c
+++ b/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c
@@ -1,9 +1,8 @@
 /* Check that calling a neon builtin from a function compiled with vfp fails.  
*/
 /* { dg-do compile } */
-/* { dg-require-effective-target arm_fp_ok } */
-/* { dg-require-effective-target arm_neon_ok } */
+/* { dg-require-effective-target arm_neon_h_ok } */
 /* { dg-options "-O2" } */
-/* { dg-add-options arm_fp } */
+/* { dg-add-options arm_neon_h } */
 
 #include 
 
@@ -15,4 +14,3 @@ foo (uint8x16_t *p)
 }
 
 /* { dg-error "inlining failed in call to 'always_inline'" "" { target *-*-* } 
0 } */
-
diff --git a/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c 
b/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c
index 9cb5a2ebb90..ed0c4634b77 100644
--- a/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c
+++ b/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c
@@ -1,8 +1,8 @@
 /* Check that calling a neon builtin from a function compiled with vfp fails.  
*/
 /* { dg-do compile } */
-/* { dg-require-effective-target arm_vfp_ok } */
+/* { dg-require-effective-target arm_neon_h_ok } */
 /* { dg-options "-O2" } */
-/* { dg-add-options arm_vfp } */
+/* { dg-add-options arm_neon_h } */
 
 extern __simd64_int8_t a, b;
 
@@ -13,4 +13,3 @@ foo (__simd128_int16_t *p)
   *p = (__simd128_int16_t)__builtin_neon_vaddlsv8qi (a, b); /* { dg-error "You 
must enable NEON instructions .*" } */
 
 }
-
diff --git a/gcc/testsuite/gcc.target/arm/attr-neon-fp16.c 
b/gcc/testsuite/gcc.target/arm/attr-neon-fp16.c
index d7b75645bc4..a5982604f9e 100644
--- a/gcc/testsuite/gcc.target/arm/attr-neon-fp16.c
+++ b/gcc/testsuite/gcc.target/arm/attr-neon-fp16.c
@@ -1,8 +1,8 @@
 /* { dg-do compile } */
 /* { dg-skip-if "-mpure-code supports M-profile only and without Neon" { *-*-* 
} { "-mpure-code" } } */
-/* { dg-require-effective-target arm_fp_ok } */
+/* { dg-require-effective-target arm_neon_h_ok } */
 /* { dg-options "-mfp16-format=ieee" } */
-/* { dg-add-options arm_fp } */
+/* { dg-add-options arm_neon_h } */
 
 #include "arm_neon.h"
 
diff --git a/gcc/testsuite/gcc.target/arm/attr-neon2.c 
b/gcc/testsuite/gcc.target/arm/attr-neon2.c
index a7a72dac379..c0f7667c2dc 100644
--- a/gcc/testsuite/gcc.target/arm/attr-neon2.c
+++ b/gcc/testsuite/gcc.target/arm/attr-neon2.c
@@ -1,8 +1,7 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target arm_neon_ok } */
-/* { dg-require-effective-target arm_fp_ok } */
+/* { dg-require-effective-target arm_neon_h_ok } */
 /* { dg-options "-Ofast" } */
-/* { dg-add-options arm_fp } */
+/* { dg-add-options arm_neon_h } */
 
 /* Reset fpu to a value compatible with the next pragmas.  */
 #pragma GCC target ("fpu=vfp")
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index d02d1fa9bec..ca0bd1bc8a2 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5127,7 +5127,7 @@ proc add_options_for_arm_fp { flags } {
 proc check_effective_target_arm_libc_fp_abi_ok_nocache { } {
 global et_arm_libc_fp_abi_flags
 set et_arm_libc_fp_abi_flags ""
-if { [check_effective_target_arm32] } {
+if { [istarget arm*-*-*] } {
foreach f

RE: [1/3 PATCH]AArch64: add support for partial modes to last extractions [PR118464]

[Tamar Christina]

> -Original Message-
> From: Richard Sandiford 
> Sent: Monday, March 3, 2025 11:53 AM
> To: Tamar Christina 
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org
> Subject: Re: [1/3 PATCH]AArch64: add support for partial modes to last
> extractions [PR118464]
> 
> Tamar Christina  writes:
> > Hi All,
> >
> > The last extraction instructions work full both full and partial SVE 
> > vectors,
> > however we currrently only define them for FULL vectors.
> >
> > Early break code for VLA now however requires partial vector support, which
> > relies on extract_last support.
> >
> > I have not added any new testcases as they overlap with the existing Early
> > break tests which now fail without this.
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu,
> > arm-none-linux-gnueabihf, x86_64-pc-linux-gnu
> > -m32, -m64 and no issues.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> >
> > PR tree-optimization/118464
> > PR tree-optimization/116855
> > * config/aarch64/aarch64-sve.md (@extract__,
> > @fold_extract__,
> > @aarch64_fold_extract_vector__): Change SVE_FULL to
> > SVE_ALL/
> >
> > ---
> >
> > diff --git a/gcc/config/aarch64/aarch64-sve.md b/gcc/config/aarch64/aarch64-
> sve.md
> > index
> e975286a01904bec0b283b7ba4afde6f0fd60bf1..6c0be3c1a51449274720175b
> 5e6e7d7535928de6 100644
> > --- a/gcc/config/aarch64/aarch64-sve.md
> > +++ b/gcc/config/aarch64/aarch64-sve.md
> > @@ -3107,7 +3107,7 @@ (define_insn "@extract__"
> >[(set (match_operand: 0 "register_operand")
> > (unspec:
> >   [(match_operand: 1 "register_operand")
> > -  (match_operand:SVE_FULL 2 "register_operand")]
> > +  (match_operand:SVE_ALL 2 "register_operand")]
> >   LAST))]
> >"TARGET_SVE"
> >{@ [ cons: =0 , 1   , 2  ]
> 
> It looks like this will use (say):
> 
>   lasta b, pg, z.b
> 
> for VNx4QI, is that right?  I don't think that's safe, since the .b form
> treats all bits of the pg input as significant, whereas only one in every
> four bits of pg is defined for VNx4BI (the predicate associated with VNx4QI).
> 
> I think converting these patterns to partial vectors means operating
> on containers rather than elements.  E.g. the VNx4QI case should use
> .s rather than .b.  That should just be a case of changing vwcore to
> vccore and Vetype to Vctype, but I haven't looked too deeply.

Ah I see, so for partial types, the values are not expected to be packed in the 
lower
part of the vector, but instead are "padded"? That explains some of the other 
patterns
I was confused about.

Any ideas how to test these? It's hard to control what modes the vectorizer 
picks..

Thanks,
Tamar

> 
> Thanks,
> Richard
> 
> > @@ -8899,7 +8899,7 @@ (define_insn "@fold_extract__"
> > (unspec:
> >   [(match_operand: 1 "register_operand")
> >(match_operand: 2 "register_operand")
> > -  (match_operand:SVE_FULL 3 "register_operand")]
> > +  (match_operand:SVE_ALL 3 "register_operand")]
> >   CLAST))]
> >"TARGET_SVE"
> >{@ [ cons: =0 , 1 , 2   , 3  ]
> > @@ -8909,11 +8909,11 @@ (define_insn "@fold_extract__"
> >  )
> >
> >  (define_insn "@aarch64_fold_extract_vector__"
> > -  [(set (match_operand:SVE_FULL 0 "register_operand")
> > -   (unspec:SVE_FULL
> > - [(match_operand:SVE_FULL 1 "register_operand")
> > +  [(set (match_operand:SVE_ALL 0 "register_operand")
> > +   (unspec:SVE_ALL
> > + [(match_operand:SVE_ALL 1 "register_operand")
> >(match_operand: 2 "register_operand")
> > -  (match_operand:SVE_FULL 3 "register_operand")]
> > +  (match_operand:SVE_ALL 3 "register_operand")]
> >   CLAST))]
> >"TARGET_SVE"
> >{@ [ cons: =0 , 1 , 2   , 3  ]

Re: [PATCH] value-range: Fix up irange::union_bitmask [PR118953]

[Aldy Hernandez]

Jakub Jelinek  writes:

> Hi!
>
> The following testcase is miscompiled during evrp.
> Before vrp, we have (from ccp):
>   # RANGE [irange] long long unsigned int [0, +INF] MASK 0xc000 
> VALUE 0x2d
>   _3 = _2 + 18446744073708503085;
> ...
>   # RANGE [irange] long long unsigned int [0, +INF] MASK 0xc000 
> VALUE 0x59
>   _6 = (long long unsigned int) _5;
>   # RANGE [irange] int [-INF, +INF] MASK 0xc000 VALUE 0x34
>   _7 = k_11 + -1048524;
>   switch (_7)  [33.33%], case 8:  [33.33%], case 24:  
> [33.33%], case 32:  [33.33%]>
> ...
>   # RANGE [irange] long long unsigned int [0, +INF] MASK 0xc07d 
> VALUE 0x0
>   # i_20 = PHI <_3(4), 0(3), _6(2)>
> and evrp is now trying to figure out range for i_20 in range_of_phi.
>
> All the ranges and MASK/VALUE pairs above are correct for the testcase,
> k_11 and _2 based on it is a result of multiplication by a constant with low
> 14 bits cleared and then some numbers are added to it.
>
> There is an obvious missed optimization for which I've filed PR119039,
> simplify_switch_using_ranges could see that all the labels but default
> are unreachable because the controlling expression has
> MASK 0xc000 VALUE 0x34 and none of 8, 24 and 32 satisfy that.
>
> Anyway, during range_of_phi for i_20, we process the PHI arguments
> in order.  For the _3(4) case, we figure out that it is reachable
> through the case 24: case 32: labels only of the switch and that
> 0x34 - 0x2d is 7, so derive
> [irange] long long unsigned int [17, 17][25, 25] MASK 0xc000 
> VALUE 0x2d
> (the MASK/VALUE just got inherited from the _3 earlier range).
> Now (not suprisingly because those labels aren't actually reachable),
> that range is inconsistent, 0x2d is 45, so there is conflict between the
> values and the irange_bitmask.
> value-range.{h,cc} code differentiates between actually stored
> irange_bitmask, which is that MASK 0xc000 VALUE 0x2d, and
> semantic bitmask, which is what get_bitmask returns.  That is
>   // The mask inherent in the range is calculated on-demand.  For
>   // example, [0,255] does not have known bits set by default.  This
>   // saves us considerable time, because setting it at creation incurs
>   // a large penalty for irange::set.  At the time of writing there
>   // was a 5% slowdown in VRP if we kept the mask precisely up to date
>   // at all times.  Instead, we default to -1 and set it when
>   // explicitly requested.  However, this function will always return
>   // the correct mask.
>   //
>   // This also means that the mask may have a finer granularity than
>   // the range and thus contradict it.  Think of the mask as an
>   // enhancement to the range.  For example:
>   //
>   // [3, 1000] MASK 0xfffe VALUE 0x0
>   //
>   // 3 is in the range endpoints, but is excluded per the known 0 bits
>   // in the mask.
>   //
>   // See also the note in irange_bitmask::intersect.
>   irange_bitmask bm
> = get_bitmask_from_range (type (), lower_bound (), upper_bound ());
>   if (!m_bitmask.unknown_p ())
> bm.intersect (m_bitmask);
> Now, get_bitmask_from_range here is MASK 0x1f VALUE 0x0 and it intersects
> that with that MASK 0xc000 VALUE 0x2d.
> Which triggers the ugly special case in irange_bitmask::intersect:
>   // If we have two known bits that are incompatible, the resulting
>   // bit is undefined.  It is unclear whether we should set the entire
>   // range to UNDEFINED, or just a subset of it.  For now, set the
>   // entire bitmask to unknown (VARYING).
>   if (wi::bit_and (~(m_mask | src.m_mask),
>m_value ^ src.m_value) != 0)
> {
>   unsigned prec = m_mask.get_precision ();
>   m_mask = wi::minus_one (prec);
>   m_value = wi::zero (prec);
> }
> so the semantic bitmask is actually MASK 0x VALUE 0x0.
>
> Next, range_of_phi attempts to union it with the 0(3) PHI argument,
> and during irange::union_ first adds the [0,0] to the subranges, so
> [irange] long long unsigned int [0, 0][17, 17][25, 25] MASK 
> 0xc000 VALUE 0x2d
> and then goes on to irange::union_bitmask which does
>   if (m_bitmask == r.m_bitmask)
> return false;
>   irange_bitmask bm = get_bitmask ();
>   irange_bitmask save = bm;
>   bm.union_ (r.get_bitmask ());
>   if (save == bm)
> return false;
>   m_bitmask = bm;
>   if (save == get_bitmask ())
> return false;
> m_bitmask MASK 0xc000 VALUE 0x2d isn't the same as
> r.m_bitmask MASK 0x0 VALUE 0x0, so we compute the semantic bitmask
> (but note, not from the original range before union, but the modified one,
> dunno if that isn't a problem as well), which is still the VARYING/unknown_p
> one, union_ that with MASK 0x0 VALUE 0x0 and get still
> MASK 0x VALUE 0x0, so don't update anything, the semantic
> bitmask didn't change, so we are fine (not!, see later).
>
> Except then we try to union with the third PHI argument.  And, because the
> edge to 

Re: [1/3 PATCH]AArch64: add support for partial modes to last extractions [PR118464]

[Richard Sandiford]

Tamar Christina  writes:
>> > diff --git a/gcc/config/aarch64/aarch64-sve.md 
>> > b/gcc/config/aarch64/aarch64-
>> sve.md
>> > index
>> e975286a01904bec0b283b7ba4afde6f0fd60bf1..6c0be3c1a51449274720175b
>> 5e6e7d7535928de6 100644
>> > --- a/gcc/config/aarch64/aarch64-sve.md
>> > +++ b/gcc/config/aarch64/aarch64-sve.md
>> > @@ -3107,7 +3107,7 @@ (define_insn "@extract__"
>> >[(set (match_operand: 0 "register_operand")
>> >(unspec:
>> >  [(match_operand: 1 "register_operand")
>> > - (match_operand:SVE_FULL 2 "register_operand")]
>> > + (match_operand:SVE_ALL 2 "register_operand")]
>> >  LAST))]
>> >"TARGET_SVE"
>> >{@ [ cons: =0 , 1   , 2  ]
>> 
>> It looks like this will use (say):
>> 
>>   lasta b, pg, z.b
>> 
>> for VNx4QI, is that right?  I don't think that's safe, since the .b form
>> treats all bits of the pg input as significant, whereas only one in every
>> four bits of pg is defined for VNx4BI (the predicate associated with VNx4QI).
>> 
>> I think converting these patterns to partial vectors means operating
>> on containers rather than elements.  E.g. the VNx4QI case should use
>> .s rather than .b.  That should just be a case of changing vwcore to
>> vccore and Vetype to Vctype, but I haven't looked too deeply.
>
> Ah I see, so for partial types, the values are not expected to be packed in 
> the lower
> part of the vector, but instead are "padded"?

Right.

> That explains some of the other patterns
> I was confused about.
>
> Any ideas how to test these? It's hard to control what modes the vectorizer 
> picks..

Yeah, agreed.  I think it'd be difficult to trigger it reliably from the
vectoriser given its current limited use of the ifns.

A gimple frontend test might work though, with a predicate/mask
generated from (say) 16-bit elements, then bitcast to a predicate/mask
for 32-bit elements and used as an input to an explicit ifn on 32-bit
elements.  If the 16-bit predicate contains 0, 1 for some even-aligned
pair, after the last 1, 0 aligned pair, then the code would likely have
picked the wrong element.

Thanks,
Richard

>
> Thanks,
> Tamar
>
>> 
>> Thanks,
>> Richard
>> 
>> > @@ -8899,7 +8899,7 @@ (define_insn "@fold_extract__"
>> >(unspec:
>> >  [(match_operand: 1 "register_operand")
>> >   (match_operand: 2 "register_operand")
>> > - (match_operand:SVE_FULL 3 "register_operand")]
>> > + (match_operand:SVE_ALL 3 "register_operand")]
>> >  CLAST))]
>> >"TARGET_SVE"
>> >{@ [ cons: =0 , 1 , 2   , 3  ]
>> > @@ -8909,11 +8909,11 @@ (define_insn "@fold_extract__"
>> >  )
>> >
>> >  (define_insn "@aarch64_fold_extract_vector__"
>> > -  [(set (match_operand:SVE_FULL 0 "register_operand")
>> > -  (unspec:SVE_FULL
>> > -[(match_operand:SVE_FULL 1 "register_operand")
>> > +  [(set (match_operand:SVE_ALL 0 "register_operand")
>> > +  (unspec:SVE_ALL
>> > +[(match_operand:SVE_ALL 1 "register_operand")
>> >   (match_operand: 2 "register_operand")
>> > - (match_operand:SVE_FULL 3 "register_operand")]
>> > + (match_operand:SVE_ALL 3 "register_operand")]
>> >  CLAST))]
>> >"TARGET_SVE"
>> >{@ [ cons: =0 , 1 , 2   , 3  ]

[PATCH] libstdc++: Fix subrange conversion to pair-like [PR119121]

[Tomasz Kamiński]

Fix regression introduced by r14-8710-g65b4cba9d6a9ff

PR libstdc++/119121

libstdc++-v3/ChangeLog:

* include/bits/ranges_util.h (__detail::__pair_like_convertible_from):
Use `_Tp` in `is_reference_v` check
* testsuite/std/ranges/subrange/tuple_like.cc: New tests for
pair-like conversion
---
Testing x86_64. OK for master and 14?

 libstdc++-v3/include/bits/ranges_util.h   |  2 +-
 .../std/ranges/subrange/tuple_like.cc | 29 +++
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/bits/ranges_util.h 
b/libstdc++-v3/include/bits/ranges_util.h
index 2f56b727e55..51024ecbebe 100644
--- a/libstdc++-v3/include/bits/ranges_util.h
+++ b/libstdc++-v3/include/bits/ranges_util.h
@@ -244,7 +244,7 @@ namespace ranges
 
 template
   concept __pair_like_convertible_from
-   = !range<_Tp> && !is_reference_v<_Vp> && __pair_like<_Tp>
+   = !range<_Tp> && !is_reference_v<_Tp> && __pair_like<_Tp>
&& constructible_from<_Tp, _Up, _Vp>
&& __convertible_to_non_slicing<_Up, tuple_element_t<0, _Tp>>
&& convertible_to<_Vp, tuple_element_t<1, _Tp>>;
diff --git a/libstdc++-v3/testsuite/std/ranges/subrange/tuple_like.cc 
b/libstdc++-v3/testsuite/std/ranges/subrange/tuple_like.cc
index 6d05eb3ef7d..80fe618642a 100644
--- a/libstdc++-v3/testsuite/std/ranges/subrange/tuple_like.cc
+++ b/libstdc++-v3/testsuite/std/ranges/subrange/tuple_like.cc
@@ -18,6 +18,8 @@
 // { dg-do compile { target c++20 } }
 
 #include 
+#include 
+#include 
 
 using S1 = std::ranges::subrange;
 using S2 = std::ranges::subrange;
@@ -49,3 +51,30 @@ static_assert( std::same_as(s2)), 
void*> );
 const S2 c2;
 static_assert( std::same_as(c2)), long*> );
 static_assert( std::same_as(c2)), void*> );
+
+std::pair p1 = s1;
+std::pair p2 = s2;
+std::tuple t1 = s1;
+std::tuple t2 = s2;
+
+std::pair const& p3 = s1;
+std::tuple&& t3 = s1;
+
+std::pair p4 = s1;
+std::tuple t4 = s1;
+
+static_assert( !std::convertible_to, 
std::pair> );
+static_assert( !std::convertible_to, 
std::tuple> );
+
+static_assert( !std::convertible_to, 
std::pair> );
+static_assert( !std::convertible_to, 
std::tuple> );
+
+struct B {};
+struct D : B {};
+
+std::ranges::subrange sd;
+std::pair p5 = sd;
+std::tuple t5 = sd;
+
+static_assert( !std::convertible_to, std::pair> );
+static_assert( !std::convertible_to, std::tuple> );
-- 
2.48.1

Re: [PATCH] RISC-V: Adjust LMUL when using maximum SEW [PR117955].

[Robin Dapp]

Hi Jin,

I apologize for the delayed response. I spent quite a bit of time trying to 
reproduce

the case, and given the passage of time, it wasn't easy to refine the testing.
Fortunately, you can see the results here.

https://godbolt.org/z/Mc8veW7oT

Using GCC version 14.2.0 should allow you to replicate the issue. If all goes as
expected, you will encounter a "Segmentation fault (core dumped)."
By disassembling the binary, you'll notice the presence of "vsetvli 
zero,zero,e32,m4,ta,ma",

which is where the problem lies, just as I mentioned previously.


Thanks for the full example, this is helpful but it still required some more 
digging on my side.


I realize now how you came to your conclusion and why you wrote the test that 
way.


In QEMU there is a segfault (but no illegal instruction) on
 vloxei16.v  v8,(t2),v8.
I'm not really sure why yet because vtype and vl are OK.  Most likely we 
corrupted something before.


On the BPI, however, the more useful information is a SIGILL on
 vfmv.s.fv12,fa5.

That's because we do
vsetvli zero,zero,e16,m4,ta,ma
...
vsetvli zero,zero,e8,m2,ta,ma
...
vsetvli zero,zero,e32,m4,ta,ma

The last vsetvl changes the SEW without adjusting LMUL, so changing SEW/LMUL 
and VLMAX which is not allowed for vsetvl zero, zero, ...

Subsequently, VILL is set and we SIGILL on the next vector instruction.

So I'd say QEMU should emit a SIGILL here.  I'm preparing a QEMU patch for 
that.


With your patch the last vsetvl becomes
vsetvli zero,a5,e32,m4,ta,ma
When setting a new VL it is permitted to change SEW/LMUL even though it's not 
desirable as we don't need to change VL.


With my patch the vsetvl becomes
vsetvli zero,zero,e32,m8,ta,ma
which doesn't change SEW/LMUL or VL and I think that's what we want.

As summary: Before your patch we only changed SEW which caused a VLMAX-changing 
vsetvl, your patch works around that by adjusting the ratio without touching 
LMUL.  But that still leaves us with PR117955 where the ratio is "correct" but 
invalid.


Given all this, I think the only way to fix this is to re-use/copy the vsetvl 
information from either prev or next (as in my patch).


I'm going to change bug-10.c into a run test, add the test you last provided as 
a run test as well as well as your reduced test from PR117955.


--
Regards
Robin

Re: [PATCH][v2] PR rtl-optimization/119046: Don't mark PARALLEL RTXes with floating-point mode as trapping

[Richard Biener]

On Tue, Mar 4, 2025 at 10:01 PM Richard Sandiford
 wrote:
>
> Kyrylo Tkachov  writes:
> > Hi all,
> >
> > In this testcase late-combine was failing to merge:
> > dup v31.4s, v31.s[3]
> > fmla v30.4s, v31.4s, v29.4s
> > into the lane-wise fmla form.
> > This is because late-combine checks may_trap_p under the hood on the dup 
> > insn.
> > This ended up returning true for the insn:
> > (set (reg:V4SF 152 [ _32 ])
> >   (vec_duplicate:V4SF (vec_select:SF (reg:V4SF 111 [ rhs_panel.8_31 ])
> >   (parallel:V4SF [
> >   (const_int 3 [0x3])]
> >
> > Although mem_trap_p correctly reasoned that vec_duplicate and vec_select of
> > floating-point modes can't trap, it assumed that the V4SF parallel can trap.
> > The correct behaviour is to recurse into vector inside the PARALLEL and 
> > check
> > the sub-expression. This patch adjusts may_trap_p_1 to do just that.
> > With this check the above insn is not deemed to be trapping and is 
> > propagated
> > into the FMLA giving:
> > fmla vD.4s, vA.4s, vB.s[3]
> >
> > Bootstrapped and tested on aarch64-none-linux-gnu.
> > Apparently this also fixes a regression in
> > gcc.target/aarch64/vmul_element_cost.c that I observed.
> >
> > Signed-off-by: Kyrylo Tkachov 
> >
> > gcc/
> >
> >   PR rtl-optimization/119046
> >   * rtlanal.cc (may_trap_p_1): Don't mark FP-mode PARALLELs as trapping.
> >
> > gcc/testsuite/
> >
> >   PR rtl-optimization/119046
> >   * gcc.target/aarch64/pr119046.c: New test.
> >
> > From 39fa1be73e8fed7fc673329e1854ba41587623c4 Mon Sep 17 00:00:00 2001
> > From: Kyrylo Tkachov 
> > Date: Thu, 27 Feb 2025 09:00:25 -0800
> > Subject: [PATCH] PR rtl-optimization/119046: Don't mark PARALLEL RTXes with
> >  floating-point mode as trapping
> >
> > In this testcase late-combine was failing to merge:
> > dup v31.4s, v31.s[3]
> > fmlav30.4s, v31.4s, v29.4s
> > into the lane-wise fmla form.
> > This is because late-combine checks may_trap_p under the hood on the dup 
> > insn.
> > This ended up returning true for the insn:
> > (set (reg:V4SF 152 [ _32 ])
> > (vec_duplicate:V4SF (vec_select:SF (reg:V4SF 111 [ rhs_panel.8_31 ])
> > (parallel:V4SF [
> > (const_int 3 [0x3])]
> >
> > Although mem_trap_p correctly reasoned that vec_duplicate and vec_select of
> > floating-point modes can't trap, it assumed that the V4SF parallel can trap.
> > The correct behaviour is to recurse into vector inside the PARALLEL and 
> > check
> > the sub-expression.  This patch adjusts may_trap_p_1 to do just that.
> > With this check the above insn is not deemed to be trapping and is 
> > propagated
> > into the FMLA giving:
> > fmlavD.4s, vA.4s, vB.s[3]
> >
> > Bootstrapped and tested on aarch64-none-linux-gnu.
> > Apparently this also fixes a regression in
> > gcc.target/aarch64/vmul_element_cost.c that I observed.
> >
> > Signed-off-by: Kyrylo Tkachov 
> >
> > gcc/
> >
> >   PR rtl-optimization/119046
> >   * rtlanal.cc (may_trap_p_1): Don't mark FP-mode PARALLELs as trapping.
>
> I don't object to this, if someone else agrees that it's the right fix.
> But the mode on the parallel looks iffy to me, in that the data is not
> floating-point data.  VOIDmode would probably be more accurate and
> seems to be what x86 uses.

I agree that looks iffy, the fix is still OK IMO - we shouldn't decide
that a parallel
traps based on its mode (which has no meaning - it's not even documented to
have a mode).

Richard.

>
> Thanks,
> Richard
>
> >
> > gcc/testsuite/
> >
> >   PR rtl-optimization/119046
> >   * gcc.target/aarch64/pr119046.c: New test.
> > ---
> >  gcc/rtlanal.cc  |  1 +
> >  gcc/testsuite/gcc.target/aarch64/pr119046.c | 16 
> >  2 files changed, 17 insertions(+)
> >  create mode 100644 gcc/testsuite/gcc.target/aarch64/pr119046.c
> >
> > diff --git a/gcc/rtlanal.cc b/gcc/rtlanal.cc
> > index 8caffafdaa4..7ad67afb9fe 100644
> > --- a/gcc/rtlanal.cc
> > +++ b/gcc/rtlanal.cc
> > @@ -3252,6 +3252,7 @@ may_trap_p_1 (const_rtx x, unsigned flags)
> >   return true;
> >break;
> >
> > +case PARALLEL:
> >  case NEG:
> >  case ABS:
> >  case SUBREG:
> > diff --git a/gcc/testsuite/gcc.target/aarch64/pr119046.c 
> > b/gcc/testsuite/gcc.target/aarch64/pr119046.c
> > new file mode 100644
> > index 000..aa5fa7c848c
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/aarch64/pr119046.c
> > @@ -0,0 +1,16 @@
> > +/* { dg-do compile } */
> > +/* { dg-additional-options "-O2" } */
> > +
> > +#include 
> > +
> > +float32x4_t madd_helper_1(float32x4_t a, float32x4_t b, float32x4_t d)
> > +{
> > +  float32x4_t t = a;
> > +  t = vfmaq_f32 (t, vdupq_n_f32(vgetq_lane_f32 (b, 1)), d);
> > +  t = vfmaq_f32 (t, vdupq_n_f32(vgetq_lane_f32 (b, 1)), d);
> > +  return t;
> > +}
> > +
> > +/* { dg-final { scan-assembler-not {\tdup\tv[0-9]+\.4s, v[0-9]+.s\[1\]\n} 
> > } } */
> > +/* {

Re: [PATCH][v2] PR rtl-optimization/119046: Don't mark PARALLEL RTXes with floating-point mode as trapping

[Kyrylo Tkachov]

> On 5 Mar 2025, at 11:14, Richard Biener  wrote:
> 
> On Tue, Mar 4, 2025 at 10:01 PM Richard Sandiford
>  wrote:
>> 
>> Kyrylo Tkachov  writes:
>>> Hi all,
>>> 
>>> In this testcase late-combine was failing to merge:
>>> dup v31.4s, v31.s[3]
>>> fmla v30.4s, v31.4s, v29.4s
>>> into the lane-wise fmla form.
>>> This is because late-combine checks may_trap_p under the hood on the dup 
>>> insn.
>>> This ended up returning true for the insn:
>>> (set (reg:V4SF 152 [ _32 ])
>>>  (vec_duplicate:V4SF (vec_select:SF (reg:V4SF 111 [ rhs_panel.8_31 ])
>>>  (parallel:V4SF [
>>>  (const_int 3 [0x3])]
>>> 
>>> Although mem_trap_p correctly reasoned that vec_duplicate and vec_select of
>>> floating-point modes can't trap, it assumed that the V4SF parallel can trap.
>>> The correct behaviour is to recurse into vector inside the PARALLEL and 
>>> check
>>> the sub-expression. This patch adjusts may_trap_p_1 to do just that.
>>> With this check the above insn is not deemed to be trapping and is 
>>> propagated
>>> into the FMLA giving:
>>> fmla vD.4s, vA.4s, vB.s[3]
>>> 
>>> Bootstrapped and tested on aarch64-none-linux-gnu.
>>> Apparently this also fixes a regression in
>>> gcc.target/aarch64/vmul_element_cost.c that I observed.
>>> 
>>> Signed-off-by: Kyrylo Tkachov 
>>> 
>>> gcc/
>>> 
>>>  PR rtl-optimization/119046
>>>  * rtlanal.cc (may_trap_p_1): Don't mark FP-mode PARALLELs as trapping.
>>> 
>>> gcc/testsuite/
>>> 
>>>  PR rtl-optimization/119046
>>>  * gcc.target/aarch64/pr119046.c: New test.
>>> 
>>> From 39fa1be73e8fed7fc673329e1854ba41587623c4 Mon Sep 17 00:00:00 2001
>>> From: Kyrylo Tkachov 
>>> Date: Thu, 27 Feb 2025 09:00:25 -0800
>>> Subject: [PATCH] PR rtl-optimization/119046: Don't mark PARALLEL RTXes with
>>> floating-point mode as trapping
>>> 
>>> In this testcase late-combine was failing to merge:
>>>dup v31.4s, v31.s[3]
>>>fmlav30.4s, v31.4s, v29.4s
>>> into the lane-wise fmla form.
>>> This is because late-combine checks may_trap_p under the hood on the dup 
>>> insn.
>>> This ended up returning true for the insn:
>>> (set (reg:V4SF 152 [ _32 ])
>>>(vec_duplicate:V4SF (vec_select:SF (reg:V4SF 111 [ rhs_panel.8_31 ])
>>>(parallel:V4SF [
>>>(const_int 3 [0x3])]
>>> 
>>> Although mem_trap_p correctly reasoned that vec_duplicate and vec_select of
>>> floating-point modes can't trap, it assumed that the V4SF parallel can trap.
>>> The correct behaviour is to recurse into vector inside the PARALLEL and 
>>> check
>>> the sub-expression.  This patch adjusts may_trap_p_1 to do just that.
>>> With this check the above insn is not deemed to be trapping and is 
>>> propagated
>>> into the FMLA giving:
>>>fmlavD.4s, vA.4s, vB.s[3]
>>> 
>>> Bootstrapped and tested on aarch64-none-linux-gnu.
>>> Apparently this also fixes a regression in
>>> gcc.target/aarch64/vmul_element_cost.c that I observed.
>>> 
>>> Signed-off-by: Kyrylo Tkachov 
>>> 
>>> gcc/
>>> 
>>>  PR rtl-optimization/119046
>>>  * rtlanal.cc (may_trap_p_1): Don't mark FP-mode PARALLELs as trapping.
>> 
>> I don't object to this, if someone else agrees that it's the right fix.
>> But the mode on the parallel looks iffy to me, in that the data is not
>> floating-point data.  VOIDmode would probably be more accurate and
>> seems to be what x86 uses.
> 
> I agree that looks iffy, the fix is still OK IMO - we shouldn't decide
> that a parallel
> traps based on its mode (which has no meaning - it's not even documented to
> have a mode).

Thanks, I’ve tracked down where the V4SF PARALLEL is being created and I’ll 
post a separate patch to fix it after some testing.
Kyrill


> 
> Richard.
> 
>> 
>> Thanks,
>> Richard
>> 
>>> 
>>> gcc/testsuite/
>>> 
>>>  PR rtl-optimization/119046
>>>  * gcc.target/aarch64/pr119046.c: New test.
>>> ---
>>> gcc/rtlanal.cc  |  1 +
>>> gcc/testsuite/gcc.target/aarch64/pr119046.c | 16 
>>> 2 files changed, 17 insertions(+)
>>> create mode 100644 gcc/testsuite/gcc.target/aarch64/pr119046.c
>>> 
>>> diff --git a/gcc/rtlanal.cc b/gcc/rtlanal.cc
>>> index 8caffafdaa4..7ad67afb9fe 100644
>>> --- a/gcc/rtlanal.cc
>>> +++ b/gcc/rtlanal.cc
>>> @@ -3252,6 +3252,7 @@ may_trap_p_1 (const_rtx x, unsigned flags)
>>>  return true;
>>>   break;
>>> 
>>> +case PARALLEL:
>>> case NEG:
>>> case ABS:
>>> case SUBREG:
>>> diff --git a/gcc/testsuite/gcc.target/aarch64/pr119046.c 
>>> b/gcc/testsuite/gcc.target/aarch64/pr119046.c
>>> new file mode 100644
>>> index 000..aa5fa7c848c
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/aarch64/pr119046.c
>>> @@ -0,0 +1,16 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-additional-options "-O2" } */
>>> +
>>> +#include 
>>> +
>>> +float32x4_t madd_helper_1(float32x4_t a, float32x4_t b, float32x4_t d)
>>> +{
>>> +  float32x4_t t = a;
>>> +  t = vfmaq_f32 (t, vdupq_n_f32(vg

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

[Nathaniel Shead]

Ping for this fix for a P1 issue.

On Sun, Feb 09, 2025 at 10:38:24PM +1100, Nathaniel Shead wrote:
> On Sun, Feb 09, 2025 at 01:16:00AM +1100, Nathaniel Shead wrote:
> > Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap + regtest
> > passes?
> > 
> > -- >8 --
> > 
> > There are two issues with no-linkage decls (e.g. explicit type aliases)
> > in unnamed namespaces that this patch fixes.
> > 
> > Firstly, we don't currently handle exporting no-linkage decls in unnamed
> > namespaces.  This should be ill-formed in [module.export], since having
> > an exported declaration within a namespace-definition makes the
> > namespace definition exported (p2), but an unnamed namespace has
> > internal linkage thus violating p3.
> > 
> > Secondly, by the standard it appears to be possible to emit unnamed
> > namespaces from named modules in certain scenarios.  This patch makes
> > the adjustments needed to ensure we don't error in this case.
> > 
> 
> One thing to note with this is that it means that the following sample:
> 
>   export module M;
>   namespace {
> struct Internal {};
> using Alias = Internal;
>   }
> 
> will still error: 
> 
> test.cpp:4:9: error: ‘using {anonymous}::Alias = struct 
> {anonymous}::Internal’ exposes TU-local entity ‘struct {anonymous}::Internal’
> 4 |   using Alias = Internal;
>   | ^
> test.cpp:3:10: note: ‘struct {anonymous}::Internal’ declared with internal 
> linkage
> 3 |   struct Internal {};
>   |  ^~~~
> 
> https://eel.is/c++draft/basic.link#17 is the relevant paragraph here,
> but I'm not 100% sure what it says about this example; I suppose that
> given Alias isn't really an entity maybe this should be OK?  But either
> way we definitely don't want to emit this alias.
> 
> Maybe the correct approach here is to mark an explicit type alias
> TU-local iff the type it refers to is itself TU-local?  So something
> like this on top of this patch:
> 
> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> index 21251f98a35..7aa7f93df57 100644
> --- a/gcc/cp/module.cc
> +++ b/gcc/cp/module.cc
> @@ -13331,6 +13331,8 @@ bool
>  depset::hash::is_tu_local_entity (tree decl, bool explain/*=false*/)
>  {
>gcc_checking_assert (DECL_P (decl));
> +  location_t loc = DECL_SOURCE_LOCATION (decl);
> +  tree type = TREE_TYPE (decl);
> 
>/* Only types, functions, variables, and template (specialisations)
>   can be TU-local.  */
> @@ -13340,15 +13342,22 @@ depset::hash::is_tu_local_entity (tree decl, bool 
> explain/*=false*/)
>&& TREE_CODE (decl) != TEMPLATE_DECL)
>  return false;
> 
> -  /* An explicit type alias is not an entity, and so is never TU-local.
> - Neither are the built-in declarations of 'int' and such.  */
> +  /* An explicit type alias is not an entity, but rather inherits
> + whether it's TU-local from the type that it aliases.
> + The built-in declarations of 'int' and such are never TU-local.  */
>if (TREE_CODE (decl) == TYPE_DECL
>&& !DECL_SELF_REFERENCE_P (decl)
>&& !DECL_IMPLICIT_TYPEDEF_P (decl))
> -return false;
> -
> -  location_t loc = DECL_SOURCE_LOCATION (decl);
> -  tree type = TREE_TYPE (decl);
> +{
> +  if (tree orig = DECL_ORIGINAL_TYPE (decl))
> +{
> +  if (explain)
> +inform (loc, "%qD is an alias of TU-local type %qT", decl, orig);
> +  return is_tu_local_entity (TYPE_NAME (orig), explain);
> +}
> +  else
> +return false;
> +}
> 
>/* Check specializations first for slightly better explanations.  */
>int use_tpl = -1;
> 
> Thoughts?
> 
> > PR c++/118799
> > 
> > gcc/cp/ChangeLog:
> > 
> > * module.cc (depset::hash::is_tu_local_entity): Only types,
> > functions, variables, and template (specialisations) can be
> > TU-local.
> > (module_state::write_namespaces): Allow unnamed namespaces in
> > named modules.
> > (check_module_decl_linkage): Error for all exported declarations
> > in an unnamed namespace.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/modules/export-6.C: Adjust error message, add check for
> > no-linkage decls in namespace.
> > * g++.dg/modules/internal-4_b.C: Allow exposing a namespace with
> > internal linkage.
> > * g++.dg/modules/using-30_a.C: New test.
> > * g++.dg/modules/using-30_b.C: New test.
> > * g++.dg/modules/using-30_c.C: New test.
> > 
> > Signed-off-by: Nathaniel Shead 
> > ---
> >  gcc/cp/module.cc| 35 -
> >  gcc/testsuite/g++.dg/modules/export-6.C | 33 ++-
> >  gcc/testsuite/g++.dg/modules/internal-4_b.C |  4 +--
> >  gcc/testsuite/g++.dg/modules/using-30_a.C   |  9 ++
> >  gcc/testsuite/g++.dg/modules/using-30_b.C   |  6 
> >  gcc/testsuite/g++.dg/modules/using-30_c.C   | 13 
> >  6 files changed, 77 insertions(+), 23 deletions(-)
> >  create mode 100644 gcc/testsuite/g++.dg/modules/using-30_a.C
>

Re: [PATCH 3/3] c++/modules: Handle exposures of TU-local types in uninstantiated member templates

[Nathaniel Shead]

Ping for this; was there any changes that you wanted me to make here?

On Sat, Feb 08, 2025 at 11:32:28PM +1100, Nathaniel Shead wrote:
> On Fri, Feb 07, 2025 at 11:11:21AM -0500, Jason Merrill wrote:
> > On 2/7/25 9:28 AM, Nathaniel Shead wrote:
> > > On Fri, Feb 07, 2025 at 08:14:23AM -0500, Jason Merrill wrote:
> > > > On 1/31/25 8:46 AM, Nathaniel Shead wrote:
> > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > > > > 
> > > > > Happy to remove the custom inform for lambdas, but I felt that the
> > > > > original message (which suggests that defining it within a class 
> > > > > should
> > > > > make it OK) was unhelpful here.
> > > > > 
> > > > > Similarly the 'is_exposure_of_member_type' function is not necessary 
> > > > > to
> > > > > fix the bug, and is just for slightly nicer diagnostics.
> > > > > 
> > > > > -- >8 --
> > > > > 
> > > > > Previously, 'is_tu_local_entity' wouldn't detect the exposure of the 
> > > > > (in
> > > > > practice) TU-local lambda in the following example, unless 
> > > > > instantiated:
> > > > > 
> > > > > struct S {
> > > > >   template 
> > > > >   static inline decltype([]{}) x = {};
> > > > > };
> > > > > 
> > > > > This is for two reasons.  Firstly, when traversing the TYPE_FIELDS of 
> > > > > S
> > > > > we only see the TEMPLATE_DECL, and never end up building a dependency 
> > > > > on
> > > > > its DECL_TEMPLATE_RESULT (due to not being instantiated).  This patch
> > > > > fixes this by stripping any templates before checking for unnamed 
> > > > > types.
> > > > > 
> > > > > The second reason is that we currently assume all class-scope entities
> > > > > are not TU-local.  Despite this being unambiguous in the standard, 
> > > > > this
> > > > > is not actually true in our implementation just yet, due to issues 
> > > > > with
> > > > > mangling lambdas in some circumstances.  Allowing these lambdas to be
> > > > > exported can cause issues in importers with apparently conflicting
> > > > > declarations, so this patch treats them as TU-local as well.
> > > > > 
> > > > > After these changes, we now get double diagnostics from the two ways
> > > > > that we can see the above lambda being exposed, via 'S' (through
> > > > > TYPE_FIELDS) or via 'S::x'.  To workaround this we hide diagnostics 
> > > > > from
> > > > > the first case, so we only get errors from 'S::x' which will be closer
> > > > > to the point the offending lambda is declared.
> > > > > 
> > > > > gcc/cp/ChangeLog:
> > > > > 
> > > > >   * module.cc (trees_out::type_node): Adjust assertion.
> > > > >   (depset::hash::is_tu_local_entity): Handle unnamed template
> > > > >   types, treat lambdas specially.
> > > > >   (is_exposure_of_member_type): New function.
> > > > >   (depset::hash::add_dependency): Use it.
> > > > >   (depset::hash::finalize_dependencies): Likewise.
> > > > > 
> > > > > gcc/testsuite/ChangeLog:
> > > > > 
> > > > >   * g++.dg/modules/internal-10.C: New test.
> > > > > 
> > > > > Signed-off-by: Nathaniel Shead 
> > > > > ---
> > > > >gcc/cp/module.cc   | 67 
> > > > > ++
> > > > >gcc/testsuite/g++.dg/modules/internal-10.C | 25 
> > > > >2 files changed, 81 insertions(+), 11 deletions(-)
> > > > >create mode 100644 gcc/testsuite/g++.dg/modules/internal-10.C
> > > > > 
> > > > > diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> > > > > index c89834c1abd..59b7270f4a5 100644
> > > > > --- a/gcc/cp/module.cc
> > > > > +++ b/gcc/cp/module.cc
> > > > > @@ -9261,7 +9261,9 @@ trees_out::type_node (tree type)
> > > > >   /* We'll have either visited this type or have newly discovered
> > > > >  that it's TU-local; either way we won't need to visit it 
> > > > > again.  */
> > > > > - gcc_checking_assert (TREE_VISITED (type) || has_tu_local_dep 
> > > > > (name));
> > > > > + gcc_checking_assert (TREE_VISITED (type)
> > > > > +  || has_tu_local_dep (TYPE_NAME (type))
> > > > > +  || has_tu_local_dep (TYPE_TI_TEMPLATE 
> > > > > (type)));
> > > > 
> > > > Why doesn't the template having a TU-local dep imply that the TYPE_NAME
> > > > does?
> > > 
> > > I may not have written this the most clearly; the type doesn't
> > > necessarily even have a template, but if it's not visited and its
> > > TYPE_NAME hasn't had a TU-local dep made then we must instead have seen
> > > a TYPE_TI_TEMPLATE that does have a TU-local dep.
> > 
> > My question is why has_tu_local_dep (name) can be false while
> > has_tu_local_dep (tmpl) is true.
> 
> In this case it's an early exit thing; when walking the TYPE_NAME, we
> find that it's a TEMPLATE_DECL_RESULT in 'trees_out::decl_node', and
> walk the TI_TEMPLATE of that decl there.
> 
> When walking this TEMPLATE_DECL we end up calling 'add_dependency' on
> it, which creates the depset and adds it to the worklist.  This doesn't
> add the TYPE_DECL in this pass

Re: [PATCH v3 2/5] c++/modules: Ignore TU-local entities where necessary

[Nathaniel Shead]

Ping for this.  Or should this cleanup wait till GCC16?

On Wed, Feb 12, 2025 at 12:49:03AM +1100, Nathaniel Shead wrote:
> On Mon, Jan 27, 2025 at 10:20:05AM -0500, Patrick Palka wrote:
> > [snip]
> >
> > > @@ -18486,6 +18562,12 @@ dependent_operand_p (tree t)
> > >  {
> > >while (TREE_CODE (t) == IMPLICIT_CONV_EXPR)
> > >  t = TREE_OPERAND (t, 0);
> > > +
> > > +  /* If we contain a TU_LOCAL_ENTITY assume we're non-dependent; we'll 
> > > error
> > > + later when instantiating.  */
> > > +  if (expr_contains_tu_local_entity (t))
> > > +return false;
> > 
> > I think it'd be more robust and cheaper (avoiding a separate tree walk)
> > to teach the general constexpr/dependence predicates about
> > TU_LOCAL_ENTITY instead of handling it only here.
> > 
> > > +
> > >++processing_template_decl;
> > >bool r = (potential_constant_expression (t)
> > >   ? value_dependent_expression_p (t)
> > > @@ -20255,6 +20337,9 @@ tsubst_expr (tree t, tree args, tsubst_flags_t 
> > > complain, tree in_decl)
> > >   else
> > > object = NULL_TREE;
> > >  
> > > + if (function_contains_tu_local_entity (templ))
> > > +   RETURN (error_mark_node);
> > > +
> > >   tree tid = lookup_template_function (templ, targs);
> > >   protected_set_expr_location (tid, EXPR_LOCATION (t));
> > >  
> > > @@ -20947,6 +21032,9 @@ tsubst_expr (tree t, tree args, tsubst_flags_t 
> > > complain, tree in_decl)
> > > qualified_p = true;
> > > }
> > >  
> > > + if (function_contains_tu_local_entity (function))
> > > +   RETURN (error_mark_node);
> > 
> > Similarly, maybe it'd suffice to check this more generally in the
> > OVERLOAD case of tsubst_expr?
> > 
> 
> So I'd completely missed the idea of handling it in the OVERLOAD case;
> doing this also fixes the issues I'd been having trying to handle it in
> potential_constant_expression.  I think this should be a lot cleaner
> now.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> 
> -- >8 --
> 
> Subject: [PATCH] c++: Handle TU_LOCAL_ENTITY in tsubst_expr and
>  potential_constant_expression
> 
> This cleans up the TU_LOCAL_ENTITY handling to avoid unnecessary
> tree walks and make the logic more robust.
> 
> gcc/cp/ChangeLog:
> 
>   * constexpr.cc (potential_constant_expression_1): Handle
>   TU_LOCAL_ENTITY.
>   * pt.cc (expr_contains_tu_local_entity): Remove.
>   (function_contains_tu_local_entity): Remove.
>   (dependent_operand_p): Remove special handling for
>   TU_LOCAL_ENTITY.
>   (tsubst_expr): Handle TU_LOCAL_ENTITY when tsubsting OVERLOADs;
>   remove now-unnecessary extra handling.
>   (type_dependent_expression_p): Handle TU_LOCAL_ENTITY.
> 
> Signed-off-by: Nathaniel Shead 
> ---
>  gcc/cp/constexpr.cc |  5 +++
>  gcc/cp/pt.cc| 80 -
>  2 files changed, 19 insertions(+), 66 deletions(-)
> 
> diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
> index f142dd32bc8..b36705fd4ce 100644
> --- a/gcc/cp/constexpr.cc
> +++ b/gcc/cp/constexpr.cc
> @@ -10825,6 +10825,11 @@ potential_constant_expression_1 (tree t, bool 
> want_rval, bool strict, bool now,
>  case CO_RETURN_EXPR:
>return false;
>  
> +/* Assume a TU-local entity is not constant, we'll error later when
> +   instantiating.  */
> +case TU_LOCAL_ENTITY:
> +  return false;
> +
>  case NONTYPE_ARGUMENT_PACK:
>{
>   tree args = ARGUMENT_PACK_ARGS (t);
> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> index f857b3f1180..966050a6608 100644
> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -9935,61 +9935,6 @@ complain_about_tu_local_entity (tree e)
>inform (TU_LOCAL_ENTITY_LOCATION (e), "declared here");
>  }
>  
> -/* Checks if T contains a TU-local entity.  */
> -
> -static bool
> -expr_contains_tu_local_entity (tree t)
> -{
> -  if (!modules_p ())
> -return false;
> -
> -  auto walker = [](tree *tp, int *walk_subtrees, void *) -> tree
> -{
> -  if (TREE_CODE (*tp) == TU_LOCAL_ENTITY)
> - return *tp;
> -  if (!EXPR_P (*tp))
> - *walk_subtrees = false;
> -  return NULL_TREE;
> -};
> -  return cp_walk_tree (&t, walker, nullptr, nullptr);
> -}
> -
> -/* Errors and returns TRUE if X is a function that contains a TU-local
> -   entity in its overload set.  */
> -
> -static bool
> -function_contains_tu_local_entity (tree x)
> -{
> -  if (!modules_p ())
> -return false;
> -
> -  if (!x || x == error_mark_node)
> -return false;
> -
> -  if (TREE_CODE (x) == OFFSET_REF
> -  || TREE_CODE (x) == COMPONENT_REF)
> -x = TREE_OPERAND (x, 1);
> -  x = MAYBE_BASELINK_FUNCTIONS (x);
> -  if (TREE_CODE (x) == TEMPLATE_ID_EXPR)
> -x = TREE_OPERAND (x, 0);
> -
> -  if (OVL_P (x))
> -for (tree ovl : lkp_range (x))
> -  if (TREE_CODE (ovl) == TU_LOCAL_ENTITY)
> - {
> -   x = ovl;
> -   break;
> - }
> -
> -  if (TREE_CODE (x) == TU_LOCAL_ENTITY)
> -{
> -  complain_about_tu_local_entity (x);
>

Re: [PATCH 2/4] c++/modules: Track module purview for deferred instantiations [PR114630]

[Nathaniel Shead]

On Wed, Feb 26, 2025 at 10:29:59AM -0500, Jason Merrill wrote:
> On 2/21/25 6:05 AM, Nathaniel Shead wrote:
> > After seeing PR c++/118964 I'm coming back around to this [1] patch
> > series, since it appears that this can cause errors on otherwise valid
> > code by instantiations coming into module purview that reference
> > TU-local entities.
> > 
> > [1]: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650324.html
> > 
> > We'd previously discussed that the best way to solve this in general
> > would be to perform all deferred instantiations at the end of the GMF to
> > ensure that they would not leak into the module purview.  I still
> > tentatively agree that this would be the "nicer" way to go (though I've
> > since come across https://eel.is/c++draft/temp.point#7 and wonder if
> > this may not be strictly conforming according to the current wording?).
> 
> Hmm, interesting point.
> 
> > I've not yet managed to implement this however, and even if I had, at
> > this stage it would definitely not be appropriate for GCC15; would the
> > approach described below be appropriate for GCC15 as a stop-gap to
> > reduce these issues?
> 
> As I suggested earlier in this discussion, it seems to me that the
> purviewness of an implicit instantiation shouldn't matter, they should all
> be treated as discardable.
> 

So looking further I believe that currently they are not, in that
implicit instantiations themselves are only ever emitted if they are
reached from elsewhere (regardless of their purviewness), so the issues
are mostly just with deferred explicit instantiations etc.  However...

> Could we instead set DECL_MODULE_PURVIEW_P as appropriate when we see an
> explicit instantiation and use that + DECL_EXPLICIT_INSTANTIATION to
> recompute module_kind?
> 
> Or go with this patch but only look at the saved module_kind if
> DECL_EXPLICIT_INSTANTIATION, but that seems a bit of a waste of space. Might
> be safer at this point, though.
> 

Part of the issue is handling things that are "implicit instantiations"
that we don't track were as such; the obvious case here is friend decls,
which get instantiated with the current purviewness but might only have
been instantiated due to a deferred implicit instantiation, and for
which we remove any evidence that they were created due to an implicit
instantiation.

So maybe looking at the problem from that side would also work, but I'm
not sure exactly how best to do that just yet.

> > Another approach would be to maybe lower the error to a permerror, so
> > that users that 'know better' could compile such modules anyway (at risk
> > of various link errors and ODR issues), though I would also need to
> > adjust the streaming logic to handle this better.  Thoughts?
> 
> This also sounds desirable.  With a warning flag so it can be disabled for
> certain deliberate cases like the gthr stuff.
> 
> Jason
> 

OK, I'll try and took a look if I get a chance (unfortunately life has
interrupted me again for the time being...).  I'm not sure that this
would work for the gthr case though (since the error occurs at the point
of use not at the point of declaration); for that we would probably need
some kind of attribute I guess?

> > On Wed, May 01, 2024 at 08:00:22PM +1000, Nathaniel Shead wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > > 
> > > -- >8 --
> > > 
> > > When calling instantiate_pending_templates at end of parsing, any new
> > > functions that are instantiated from this point have their module
> > > purview set based on the current value of module_kind.
> > > 
> > > This is unideal, however, as the modules code will then treat these
> > > instantiations as reachable and cause large swathes of the GMF to be
> > > emitted into the module CMI, despite no code in the actual module
> > > purview referencing it.
> > > 
> > > This patch fixes this by also remembering the value of module_kind when
> > > the instantiation was deferred, and restoring it when doing this
> > > deferred instantiation.  That way newly instantiated declarations
> > > appropriately get a DECL_MODULE_PURVIEW_P appropriate for where the
> > > instantiation was required, meaning that GMF entities won't be counted
> > > as reachable unless referenced by an actually reachable entity.
> > > 
> > > Note that purviewness and attachment etc. is generally only determined
> > > by the base template: this is purely for determining whether a
> > > specialisation was declared in the module purview and hence whether it
> > > should be streamed out.  See the comment on 'set_instantiating_module'.
> > > 
> > >   PR c++/114630
> > >   PR c++/114795
> > > 
> > > gcc/cp/ChangeLog:
> > > 
> > >   * cp-tree.h (struct tinst_level): Add field for tracking
> > >   module_kind.
> > >   * pt.cc (push_tinst_level_loc): Cache module_kind in new_level.
> > >   (reopen_tinst_level): Restore module_kind from level.
> > >   (instantiate_pending_templates): Save and restore module_kind so
> > >   it is

[pushed] c++: coroutines and return in registers [PR118874]

[Jason Merrill]

Tested x86_64-pc-linux-gnu, applying to trunk.

-- 8< --

Because coroutines insert a call to the resumer between the initialization
of the return value and the actual return to the caller, we need to
duplicate the work of gimplify_return_expr for the !aggregate_value_p case.

PR c++/117364
PR c++/118874

gcc/cp/ChangeLog:

* coroutines.cc (cp_coroutine_transform::build_ramp_function): For
!aggregate_value_p return force return value into a local temp.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/torture/pr118874.C: New test.

Co-authored-by: Jakub Jelinek 
---
 gcc/cp/coroutines.cc  | 18 +-
 .../g++.dg/coroutines/torture/pr118874.C  | 33 +++
 2 files changed, 50 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/coroutines/torture/pr118874.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index d3c7ff3bd72..b92d09fa4ea 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -5161,6 +5161,7 @@ cp_coroutine_transform::build_ramp_function ()
 
   /* Used for return objects in the RESULT slot.  */
   tree ret_val_dtor = NULL_TREE;
+  tree retval = NULL_TREE;
 
   /* [dcl.fct.def.coroutine] / 7
  The expression promise.get_return_object() is used to initialize the
@@ -5189,6 +5190,21 @@ cp_coroutine_transform::build_ramp_function ()
   /* Check for bad things.  */
   if (!r || r == error_mark_node)
return false;
+  if (!aggregate_value_p (fn_return_type, orig_fn_decl)
+ && TREE_CODE (r) == INIT_EXPR)
+   {
+ /* If fn_return_type doesn't need to be returned in memory, normally
+gimplify_return_expr redirects the INIT_EXPR to a temporary.  But
+r isn't wrapped in the RETURN_EXPR, so we need to do the
+redirection here as well.  See PR118874.  */
+ tree temp = create_temporary_var (fn_return_type);
+ add_decl_expr (temp);
+ retval = copy_node (r);
+ TREE_OPERAND (r, 0) = temp;
+ TREE_OPERAND (retval, 1) = temp;
+   }
+  else
+   retval = DECL_RESULT (orig_fn_decl);
 }
 
   finish_expr_stmt (r);
@@ -5215,7 +5231,7 @@ cp_coroutine_transform::build_ramp_function ()
   /* The ramp is done, we just need the return statement, which we build from
  the return object we constructed before we called the actor.  */
 
-  r = void_ramp_p ? NULL_TREE : DECL_RESULT (orig_fn_decl);
+  r = retval;
 
   /* The reminder of finish_return_expr ().  */
   r = build_stmt (loc, RETURN_EXPR, r);
diff --git a/gcc/testsuite/g++.dg/coroutines/torture/pr118874.C 
b/gcc/testsuite/g++.dg/coroutines/torture/pr118874.C
new file mode 100644
index 000..925d56ae2ea
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/torture/pr118874.C
@@ -0,0 +1,33 @@
+// PR c++/118874
+// { dg-do compile }
+// { dg-additional-options "-std=c++20" }
+
+#include 
+
+struct B {
+  bool await_ready () const noexcept;
+  void await_suspend (std::coroutine_handle<> h) const noexcept;
+  void await_resume () const noexcept;
+};
+
+struct C {
+  struct promise_type {
+const char *value;
+std::suspend_never initial_suspend ();
+std::suspend_always final_suspend () noexcept;
+void return_value (const char *v);
+void unhandled_exception ();
+C get_return_object () { return C{this}; }
+  };
+  promise_type *p;
+  explicit C (promise_type *p) : p(p) {}
+  const char *get ();
+};
+
+C
+bar (bool x)
+{
+  if (x)
+co_await B{};
+  co_return "foobar";
+}

base-commit: 556e25f0e9abc720c940994bd9a1491062933d49
-- 
2.48.1

[committed][GCC 14] aarch64: Check for invalid use arrays in ldp_fusion [PR118320]

[Alex Coplan]

This is a backport of Richard's fix for PR118320 to GCC 14 (squashed
together with my follow-up tweak of the dump message).  Pushed to
releases/gcc-14 after testing on aarch64-linux-gnu.

Thanks,
Alex

-- >8 --

As Andrew says in the bugzilla comments, this PR is about a case where
we tried to fuse two stores of x0, one in which x0 was defined and one
in which it was undefined.  merge_access_arrays failed on the conflict,
but the failure wasn't caught.

Normally the hazard detection code would fail if the instructions
had incompatible uses.  However, an undefined use doesn't impose
many restrictions on movements.  I think this is likely to be the
only case where hazard detection isn't enough.

As Andrew notes in bugzilla, it might be possible to allow uses
of defined and undefined values to be merged to the defined value.
But that sounds dangerous in the general case, as an rtl-ssa-level
decision.  We might run the risk of turning conditional UB into
unconditional UB.  And LLVM proves that the definition of "undef"
isn't simple.

This is a backport of
r15-7282-gf559ac896942ffe0e2315d0a4d8b8b517a16d607.

gcc/
PR rtl-optimization/118320
* config/aarch64/aarch64-ldp-fusion.cc (ldp_bb_info::fuse_pair):
Commonize the merge of input_uses and return early if it
fails.

gcc/testsuite/
PR rtl-optimization/118320
* g++.dg/torture/pr118320.C: New test.
diff --git a/gcc/config/aarch64/aarch64-ldp-fusion.cc 
b/gcc/config/aarch64/aarch64-ldp-fusion.cc
index f32d30d54c5..1791ca5563c 100644
--- a/gcc/config/aarch64/aarch64-ldp-fusion.cc
+++ b/gcc/config/aarch64/aarch64-ldp-fusion.cc
@@ -1784,6 +1784,24 @@ ldp_bb_info::fuse_pair (bool load_p,
   input_uses[i] = remove_note_accesses (attempt, input_uses[i]);
 }
 
+  // Get the uses that the pair instruction would have, and punt if
+  // the unpaired instructions use different definitions of the same
+  // register.  That would normally be caught as a side-effect of
+  // hazard detection below, but this check also deals with cases
+  // in which one use is undefined and the other isn't.
+  auto new_uses = merge_access_arrays (attempt,
+  drop_memory_access (input_uses[0]),
+  drop_memory_access (input_uses[1]));
+  if (!new_uses.is_valid ())
+{
+  if (dump_file)
+   fprintf (dump_file,
+"  rejecting pair: i%d and i%d use different definiitions of"
+" the same register\n",
+insns[0]->uid (), insns[1]->uid ());
+  return false;
+}
+
   // Edge case: if the first insn is a writeback load and the
   // second insn is a non-writeback load which transfers into the base
   // register, then we should drop the writeback altogether as the
@@ -1911,10 +1929,7 @@ ldp_bb_info::fuse_pair (bool load_p,
   input_defs[1]);
   gcc_assert (pair_change->new_defs.is_valid ());
 
-  pair_change->new_uses
-   = merge_access_arrays (attempt,
-  drop_memory_access (input_uses[0]),
-  drop_memory_access (input_uses[1]));
+  pair_change->new_uses = new_uses;
   gcc_assert (pair_change->new_uses.is_valid ());
   set_pair_pat (pair_change);
 }
@@ -1936,9 +1951,7 @@ ldp_bb_info::fuse_pair (bool load_p,
case Action::CHANGE:
{
  set_pair_pat (change);
- change->new_uses = merge_access_arrays (attempt,
- input_uses[0],
- input_uses[1]);
+ change->new_uses = new_uses;
  auto d1 = drop_memory_access (input_defs[0]);
  auto d2 = drop_memory_access (input_defs[1]);
  change->new_defs = merge_access_arrays (attempt, d1, d2);
@@ -1970,9 +1983,7 @@ ldp_bb_info::fuse_pair (bool load_p,
  auto new_insn = crtl->ssa->create_insn (attempt, INSN, pair_pat);
  change = make_change (new_insn);
  change->move_range = move_range;
- change->new_uses = merge_access_arrays (attempt,
- input_uses[0],
- input_uses[1]);
+ change->new_uses = new_uses;
  gcc_assert (change->new_uses.is_valid ());
 
  auto d1 = drop_memory_access (input_defs[0]);
diff --git a/gcc/testsuite/g++.dg/torture/pr118320.C 
b/gcc/testsuite/g++.dg/torture/pr118320.C
new file mode 100644
index 000..228d79860b5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr118320.C
@@ -0,0 +1,15 @@
+// { dg-additional-options "-fno-tree-sra" } */
+
+struct T{
+  long f[2];
+};
+void f1(int);
+void g(T&);
+void f1()
+{
+  T a;
+  a.~T(); // To force the clobber
+  a.f[1] = 1;
+  T b = a;
+  g(b);
+}

Re: [PATCH v2] c++: Check invalid use of constrained auto with trailing return type [PR100589]

[Patrick Palka]

On Tue, 4 Mar 2025, Patrick Palka wrote:

> On Sun, 2 Mar 2025, Da Xie wrote:
> 
> > Add check for constrained auto type specifier in function declaration or
> > function type declaration with trailing return type. Issue error if such
> > usage is detected.
> > 
> > Test file renamed, and added a new test for type declaration.
> > 
> > Successfully bootstrapped and regretested on x86_64-pc-linux-gnu:
> > Added 6 passed and 4 unsupported tests.
> > 
> > PR c++/100589
> > 
> > gcc/cp/ChangeLog:
> > 
> > * decl.cc (grokdeclarator): Issue an error for a declarator with
> > constrained auto type specifier and trailing return types. Include
> > function names if available.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/cpp2a/concepts-pr100589.C: New test.
> 
> LGTM, thanks!  Jason, shall I push this to trunk?

Pushed as r15-7834-g7439febd94368f.

> 
> > 
> > Signed-off-by: Da Xie 
> > ---
> >  gcc/cp/decl.cc | 13 +
> >  gcc/testsuite/g++.dg/cpp2a/concepts-pr100589.C |  9 +
> >  2 files changed, 22 insertions(+)
> >  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-pr100589.C
> > 
> > diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
> > index 9ca8c6c4481..337ee65752e 100644
> > --- a/gcc/cp/decl.cc
> > +++ b/gcc/cp/decl.cc
> > @@ -14037,6 +14037,19 @@ grokdeclarator (const cp_declarator *declarator,
> > "invalid use of %");
> > return error_mark_node;
> >   }
> > +   else if (is_constrained_auto (type))
> > + {
> > +   if (funcdecl_p)
> > + error_at (typespec_loc,
> > +   "%qs function with trailing return type "
> > +   "has constrained % type specifier "
> > +   "rather than plain %",
> > +   name);
> > +   else
> > + error_at (typespec_loc,
> > +   "invalid use of constrained % type");
> > +   return error_mark_node;
> > + }
> > tree tmpl = CLASS_PLACEHOLDER_TEMPLATE (auto_node);
> > if (!tmpl)
> >   if (tree late_auto = type_uses_auto (late_return_type))
> > diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-pr100589.C 
> > b/gcc/testsuite/g++.dg/cpp2a/concepts-pr100589.C
> > new file mode 100644
> > index 000..0c60d31f29b
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-pr100589.C
> > @@ -0,0 +1,9 @@
> > +// PR c++/100589
> > +// { dg-do compile { target c++20 } }
> > +
> > +template
> > +concept false_concept = false;
> > +
> > +false_concept auto f() -> int; // { dg-error "'f' .* trailing return 
> > type.* constrained 'auto'" }
> 
> I can replace the use of .* with \[^\r\n\]* before pushing.
> 
> > +
> > +using type = false_concept auto() -> int; // { dg-error "invalid use of 
> > constrained 'auto' type"}

N.B. I added a missing space between the " and } that caused this
dircetive to get ignored.

> > -- 
> > 2.34.1
> > 
> > 
> 

Re: [PATCH] arm: Fix signedness of some vld1q intrinsic parameters for ARM NEON

[Richard Earnshaw (lists)]

On 20/02/2025 14:09, Hannes Braun wrote:
> vld1q_s8_x3, vld1q_s16_x3, vld1q_s8_x4 and vld1q_s16_x4 were expecting
> pointers to unsigned integers. These parameters should be pointers to
> signed integers.
> 
> gcc/ChangeLog:
> 
>   * config/arm/arm_neon.h (vld1q_s8_x3): Use int8_t instead of
>   uint16_t.
>   (vld1q_s16_x3): Use int16_t instead of uint16_t.
>   (vld1q_s8_x4): Likewise.
>   (vld1q_s16_x4): Likewise.

I've added the PR reference, as Christophe suggested and also added 
-Wpointer-sign to gcc.target/arm/simd/vld1q_base_xN_1.c.  Pushed to master.

Thanks for the patch.

R.

> 
> Signed-off-by: Hannes Braun 
> ---
>  gcc/config/arm/arm_neon.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
> index 5b1c55c8d9f..578ada88fa6 100644
> --- a/gcc/config/arm/arm_neon.h
> +++ b/gcc/config/arm/arm_neon.h
> @@ -10854,7 +10854,7 @@ vld1q_s64_x2 (const int64_t * __a)
>  
>  __extension__ extern __inline int8x16x3_t
>  __attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
> -vld1q_s8_x3 (const uint8_t * __a)
> +vld1q_s8_x3 (const int8_t * __a)
>  {
>union { int8x16x3_t __i; __builtin_neon_ci __o; } __rv;
>__rv.__o = __builtin_neon_vld1q_x3v16qi ((const __builtin_neon_qi *) __a);
> @@ -10863,7 +10863,7 @@ vld1q_s8_x3 (const uint8_t * __a)
>  
>  __extension__ extern __inline int16x8x3_t
>  __attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
> -vld1q_s16_x3 (const uint16_t * __a)
> +vld1q_s16_x3 (const int16_t * __a)
>  {
>union { int16x8x3_t __i; __builtin_neon_ci __o; } __rv;
>__rv.__o = __builtin_neon_vld1q_x3v8hi ((const __builtin_neon_hi *) __a);
> @@ -10890,7 +10890,7 @@ vld1q_s64_x3 (const int64_t * __a)
>  
>  __extension__ extern __inline int8x16x4_t
>  __attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
> -vld1q_s8_x4 (const uint8_t * __a)
> +vld1q_s8_x4 (const int8_t * __a)
>  {
>union { int8x16x4_t __i; __builtin_neon_xi __o; } __rv;
>__rv.__o = __builtin_neon_vld1q_x4v16qi ((const __builtin_neon_qi *) __a);
> @@ -10899,7 +10899,7 @@ vld1q_s8_x4 (const uint8_t * __a)
>  
>  __extension__ extern __inline int16x8x4_t
>  __attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
> -vld1q_s16_x4 (const uint16_t * __a)
> +vld1q_s16_x4 (const int16_t * __a)
>  {
>union { int16x8x4_t __i; __builtin_neon_xi __o; } __rv;
>__rv.__o = __builtin_neon_vld1q_x4v8hi ((const __builtin_neon_hi *) __a);

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

[Robert Dubner]

> -Original Message-
> From: Jakub Jelinek 
> Sent: Wednesday, March 5, 2025 10:58
> To: Robert Dubner 
> Cc: Richard Biener ; James K. Lowden
> ; gcc-patches@gcc.gnu.org
> Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
> 
> On Wed, Mar 05, 2025 at 09:47:45AM -0600, Robert Dubner wrote:
> > > -Original Message-
> > > From: Jakub Jelinek 
> > > Sent: Wednesday, March 5, 2025 08:35
> > > To: Richard Biener 
> > > Cc: James K. Lowden ;
> > > gcc-patches@gcc.gnu.org
> > > Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
> > >
> > > On Wed, Mar 05, 2025 at 12:46:48PM +0100, Richard Biener wrote:
> > > > and the installed compiler behaves as intended.  I can trick -m32
> > > > to
> > > "work"
> > > > by using the generic gcc diriver:
> > > >
> > > > > ./install/gcc-cobol/usr/local/bin/gcc -x cobol t.cob -m32 -c
> > > >
> > > > but I think this is a less important issue.
> > >
> > > Agreed, it should be the compiler, i.e. cobol1, that diagnoses this
> > rather
> > > than the driver.
> >
> > I actually tried to do that, by looking for "case OPT_m32". in
> cobol1.cc.
> 
> No, you don't want to base the error on anything like that.
> E.g. for Solaris gcc defaults to -m32 and -m64 needs to be used.
> The error should be on missing features required for COBOL emitted after
> option processing during FE initialization.
> 
> The test for missing __int128 or missing IEEE quad support is
>   if (!targetm.scalar_mode_supported_p (TImode) || !float128_type_node)
> sorry ("COBOL not supported in this configuration"); or so.
> 
>   Jakub

I will give that a shot.  You said something like that earlier, but I
didn't understand the context.  I think I understand it better, now.

Re: [PATCH] libstdc++: fix possible undefined std::timespec in module std

[Jonathan Wakely]

On 17/01/25 00:01 +0800, yxj-github-437 wrote:

I notice std::timespec and std::timespec_get are used in preprocessor
condition _GLIBCXX_HAVE_TIMESPEC_GET. So in module std, it should be
the same.

libstdc++-v3:
* src/c++23/std-clib.cc.in: move std::timespec in preprocessor
condition _GLIBCXX_HAVE_TIMESPEC_GET


Thanks for the patch, it looks correct so I'll push it.

This patch is also small enough that we don't need a copyright
assignment, and as with r15-7180-g3469d0f6eaa625 I will use
yxj-github-437 as the Git commit author.

For future patches to libstdc++, please CC the libstdc++ mailing list
as well as the gcc-patches list. Otherwise, I might not see the patch
to review it.

Thanks again.


---
libstdc++-v3/src/c++23/std-clib.cc.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/src/c++23/std-clib.cc.in 
b/libstdc++-v3/src/c++23/std-clib.cc.in
index 6809ad229d7..10fc03e7ce0 100644
--- a/libstdc++-v3/src/c++23/std-clib.cc.in
+++ b/libstdc++-v3/src/c++23/std-clib.cc.in
@@ -585,9 +585,9 @@ export C_LIB_NAMESPACE
  using std::strftime;
  using std::time;
  using std::time_t;
-  using std::timespec;
  using std::tm;
#ifdef _GLIBCXX_HAVE_TIMESPEC_GET
+  using std::timespec;
  using std::timespec_get;
#endif
}
--
2.43.0

Re: [PATCH] aarch64: Improve immediate generation by using SUB instruction [PR114528]

[Richard Sandiford]

Thanks for the patch and sorry for the slow review.

Eikansh Gupta  writes:
> Many of the constants which are generated using 3 `mov` instruction can be
> generated using `mov` plus `sub` instruction. The patch uses following method
> to add the mentioned functionality. If a constant `val` can not be generated
> using 1 or 2 `mov`, then find `val1` such that `(val + val1)` can be generated
> in 1 `mov`. Generate a `sub` instruction to get the original value.
>
> Consider the function:
>
> long f1 (void)
> {
>   return 0x0001 - 0x00123000;
> }
>
> GCC output:
> f1():
>   mov x0, -12289
>   movkx0, 0xffef, lsl 16
>   movkx0, 0xfffe, lsl 32
>   ret
>
> New output:
> f1():
>   mov x0, -4294967297
>   sub x0, x0, #1060864
>   ret
>
> This patch is for GCC 16.
>
> gcc/ChangeLog:
>
>   * config/aarch64/aarch64.cc
>   (aarch64_internal_mov_immediate): Add implementation to generate
>   an immediate using mov plus sub instruction.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/aarch64/pr114528.c: New test.
>
> Signed-off-by: Eikansh Gupta 
> ---
>  gcc/config/aarch64/aarch64.cc   | 44 -
>  gcc/testsuite/gcc.target/aarch64/pr114528.c | 53 +
>  2 files changed, 95 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/pr114528.c
>
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index fe76730b0a7..9076086d92f 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -4604,13 +4604,53 @@ aarch64_internal_mov_immediate (rtx dest, rtx imm, 
> bool generate,
> }
>  }
>  
> +  /* Try a mov plus sub to generate the immediate in 2 instructions. */
> +  /* Check number of instructions required to generate the immediate. */
> +  num_insns = 1;
> +  mask = 0x;
> +  val2 = one_match > zero_match ? ~val : val;
> +  i = (val2 & mask) != 0 ? 0 : (val2 & (mask << 16)) != 0 ? 16 : 32;
> +
> +  for (i += 16; i < 64; i += 16)
> +{
> +  if ((val2 & (mask << i)) == 0)
> + continue;
> +  num_insns ++;
> +}
> +
> +  /* Generate mov plus sub if mov plus movk can't be generated.
> + Find val3 such that aarch64_move_imm (val + val3) == 1. */
> +  if (num_insns > 2)
> +{
> +  for (i = 1; i < 4096; i++)
> + {
> +   if (aarch64_move_imm (val + i, mode))
> + {
> +   val3 = i;
> +   break;
> + }
> +   if (aarch64_move_imm (val + (i << 12), mode))
> + {
> +   val3 = (i << 12);
> +   break;
> + }
> + }
> +  if (i < 4096)
> + {
> +   if (generate)
> + {
> +   emit_insn (gen_rtx_SET (dest, GEN_INT (val + val3)));
> +   emit_insn (gen_adddi3 (dest, dest, GEN_INT (-val3)));
> + }
> +   return 2;
> + }
> +}
> +

This is a nice sequence to generate.  But iterating over 4096 values
seems too much.

Since the sequence tries to make the first instruction is a single move,
I think we can classify the cases based on what kind of immediate we want
to move.  The description below focuses on the LSL 12 case, since that's
what the testcases cover, but the principle would be the same for
unshifted immediates:

(1) a 64-bit logical immediate with a repeat of 32 bits or fewer.
In this case, the aim is to find an immediate in which bits 0-31
match bits 32-63, and in particular in which bits 12-23 match bits
44-55 (since those are the ones directly affected by the subtraction).

(2) an immediate in which bits 12-23 are zeros.  This promotes the use
of MOVZ for the move.

(3) an immediate in which bits 12-23 are ones.  This promotes the use
of MOVN for the move, and is also needed for 64-bit logical immediates
with no repeat (see f12 below).

We can achieve these targets "from above" by moving something and then
subtracting, as the patch does.  But we can also achieve them "from below"
by moving something and then adding.  I think it would be good to do
both as part of the same patch, to prove that the code is general enough
to handle it.

This would give something like:

  if (num_insns > 2)
{
  auto current = (val & 0xfff000);
  for (auto target : { (val >> 32) & 0xfff000,
   (unsigned HOST_WIDE_INT) 0,
   (unsigned HOST_WIDE_INT) 0xfff000 })
if (current != target)
  {
if (target < current)
  target += 0x100;
for (auto i : { current - target, current - target + 0x100 })
  if (aarch64_move_imm (val - i, mode))
{
  if (generate)
{
  emit_insn (gen_rtx_SET (dest, GEN_INT (val - i)));
  emit_insn (gen_adddi3 (dest, dest, GEN_INT (i)));
}
  return 2;
}
  }
}

for the LSL 12 

Re: [PATCH] RISC-V: Using O2 instead of O1 in testsuites when using -fdump-ext_dce

[Jeff Law]

On 3/3/25 2:59 AM, Liao Shihua wrote:

The pass ext-dce is only activated at O2 and above. Using O2 instead of O1
in testsuites when using -fdump-ext_dce.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/core_list_init.c: Using -O2 instead of -O1.
* gcc.target/riscv/pr111384.c: Ditto.

---
  gcc/testsuite/gcc.target/riscv/core_list_init.c | 2 +-
  gcc/testsuite/gcc.target/riscv/pr111384.c   | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
THanks.  I think we're better off changing the -O1 to -fext-dce, then 
adding a dg-skip-if to skip the test entirely at -O0.


That gives us better test coverage since we iterate over various 
optimization options in gcc.target/riscv.


Something like this is what I'm planning to install instead:

diff --git a/gcc/testsuite/gcc.target/riscv/core_list_init.c 
b/gcc/testsuite/gcc.target/riscv/core_list_init.c
index 2f36dae85aa..eec3a817d80 100644
--- a/gcc/testsuite/gcc.target/riscv/core_list_init.c
+++ b/gcc/testsuite/gcc.target/riscv/core_list_init.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
-/* { dg-options "-O1 -fdump-rtl-ext_dce" } */
+/* { dg-options "-fext-dce -fdump-rtl-ext_dce" } */
 /* { dg-final { scan-rtl-dump {Successfully transformed} "ext_dce" } } */
+/* { dg-skip-if "" { *-*-* } { "-O0"} } */
 
 unsigned short
 core_list_init (int size, short seed) {
diff --git a/gcc/testsuite/gcc.target/riscv/pr111384.c 
b/gcc/testsuite/gcc.target/riscv/pr111384.c
index a4e77d4aeb6..bcf33eb 100644
--- a/gcc/testsuite/gcc.target/riscv/pr111384.c
+++ b/gcc/testsuite/gcc.target/riscv/pr111384.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
-/* { dg-options "-O1 -fdump-rtl-ext_dce" } */
+/* { dg-options "-fext-dce -fdump-rtl-ext_dce" } */
 /* { dg-final { scan-rtl-dump {Successfully transformed} "ext_dce" } } */
+/* { dg-skip-if "" { *-*-* } { "-O0"} } */
 
 void
 foo(unsigned int src, unsigned short *dst1, unsigned short *dst2)

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

[Jerry D]

On 3/5/25 6:34 AM, Andre Vehreschild wrote:

Hi all,

attached patch fixes a gimplification error when a pointer remapping on derived
type's components with deferred arrays is made. The issue boiled down to the
dependency analysis being to loose. It saw a dependency as soon as both sides
of the => had a derived type, independent of the actual derived types used. The
patch therefore extends the dependency analysis to compare also the derived
types (symbols).

This fixes the PR, but not really the problem, because when say a
obj(i)%arr(2:5) => obj(i)%arr(1:4) is done we run into the same issue. I don't
have a solution for that error. It might  be needed to prevent generating the
parm.NN variable for the lhs, because that is mostly useless there. (Or I don't
understand (yet) how to use it).

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

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


This looks simple enough. OK. One minor nit in git log


"Enhance dependency checking for data pointers to check for same derived
type and not only for a type being a derived type.  This prevent
generation of a descriptor for a function call, that is unsuitable in
forall's pointer assignment."

s/prevent/prevents/

-- Jerry

[PATCH v2] c++: ICE with operator new[] in constexpr [PR118775]

[Marek Polacek]

On Tue, Mar 04, 2025 at 05:34:10PM -0500, Jason Merrill wrote:
> On 2/11/25 6:24 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > -- >8 --
> > Here we ICE since r11-7740 because we no longer say that (long)&a
> > (where a is a global var) is non_constant_p.  So VERIFY_CONSTANT
> > does not return and we crash on tree_to_uhwi.  We should check
> > tree_fits_uhwi_p before calling tree_to_uhwi.
> > 
> > PR c++/118775
> > 
> > gcc/cp/ChangeLog:
> > 
> > * constexpr.cc (cxx_eval_call_expression): Check tree_fits_uhwi_p.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/cpp2a/constexpr-new24.C: New test.
> > * g++.dg/cpp2a/constexpr-new25.C: New test.
> > ---
> >   gcc/cp/constexpr.cc  |  7 +
> >   gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C | 25 ++
> >   gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C | 27 
> >   3 files changed, 59 insertions(+)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C
> >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C
> > 
> > diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
> > index f142dd32bc8..f8f9a9df1a2 100644
> > --- a/gcc/cp/constexpr.cc
> > +++ b/gcc/cp/constexpr.cc
> > @@ -2909,6 +2909,13 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, 
> > tree t,
> >   gcc_assert (arg0);
> >   if (new_op_p)
> > {
> > + if (!tree_fits_uhwi_p (arg0))
> > +   {
> > + if (!ctx->quiet)
> > +   error_at (loc, "cannot allocate array: size too large");
> 
> "too large" seems misleading in this case, where it just isn't a
> compile-time constant.

Fair, how about "size not constant"?
 
> Why didn't the VERIFY_CONSTANT just above already reject this?

This is about *non_constant_p.  Since r11-7740 cxx_eval_constant_expression
returns early less often:

@@ -6656,7 +6656,8 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,

if (TREE_CODE (t) == CONVERT_EXPR
&& ARITHMETIC_TYPE_P (type)
-   && INDIRECT_TYPE_P (TREE_TYPE (op)))
+   && INDIRECT_TYPE_P (TREE_TYPE (op))
+   && ctx->manifestly_const_eval)
  {
if (!ctx->quiet)
  error_at (loc,

and in constexpr-new25.C it doesn't signal that the expression is non-constant.
Before r11-7740 we wouldn't get past the VERIFY_CONSTANT here:

  tree arg = CALL_EXPR_ARG (t, i);
  arg = cxx_eval_constant_expression (ctx, arg, vc_prvalue,
  non_constant_p, overflow_p);
  /* Deleting a non-constant pointer has a better error message
 below.  */
  if (new_op_p || i != 0)
VERIFY_CONSTANT (arg);

but now we do since *non_constant_p is false and reduced_constant_expression_p
is fine with (long unsigned int) &a.

-- >8 --
Here we ICE since r11-7740 because we no longer say that (long)&a
(where a is a global var) is non_constant_p.  So VERIFY_CONSTANT
does not return and we crash on tree_to_uhwi.  We should check
tree_fits_uhwi_p before calling tree_to_uhwi.

PR c++/118775

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_call_expression): Check tree_fits_uhwi_p.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/constexpr-new24.C: New test.
* g++.dg/cpp2a/constexpr-new25.C: New test.
---
 gcc/cp/constexpr.cc  |  7 +
 gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C | 25 ++
 gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C | 27 
 3 files changed, 59 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index aa2fa44613a..728cf3b249c 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -2928,6 +2928,13 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree 
t,
  gcc_assert (arg0);
  if (new_op_p)
{
+ if (!tree_fits_uhwi_p (arg0))
+   {
+ if (!ctx->quiet)
+   error_at (loc, "cannot allocate array: size not constant");
+ *non_constant_p = true;
+ return t;
+   }
  tree type = build_array_type_nelts (char_type_node,
  tree_to_uhwi (arg0));
  tree var = build_decl (loc, VAR_DECL,
diff --git a/gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C 
b/gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C
new file mode 100644
index 000..ee62f18922c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C
@@ -0,0 +1,25 @@
+// PR c++/118775
+// { dg-do compile { target c++20 } }
+
+int a;
+
+constexpr char *
+f1 ()
+{
+  constexpr auto p = new char[(long int) &a]; // { dg-error "size not 
constant" }
+  return p;
+}
+
+constexpr char *
+f2 ()

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

[Robert Dubner]

> -Original Message-
> From: Jakub Jelinek 
> Sent: Wednesday, March 5, 2025 10:58
> To: Robert Dubner 
> Cc: Richard Biener ; James K. Lowden
> ; gcc-patches@gcc.gnu.org
> Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
> 
> On Wed, Mar 05, 2025 at 09:47:45AM -0600, Robert Dubner wrote:
> > > -Original Message-
> > > From: Jakub Jelinek 
> > > Sent: Wednesday, March 5, 2025 08:35
> > > To: Richard Biener 
> > > Cc: James K. Lowden ;
> > > gcc-patches@gcc.gnu.org
> > > Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
> > >
> > > On Wed, Mar 05, 2025 at 12:46:48PM +0100, Richard Biener wrote:
> > > > and the installed compiler behaves as intended.  I can trick -m32
> > > > to
> > > "work"
> > > > by using the generic gcc diriver:
> > > >
> > > > > ./install/gcc-cobol/usr/local/bin/gcc -x cobol t.cob -m32 -c
> > > >
> > > > but I think this is a less important issue.
> > >
> > > Agreed, it should be the compiler, i.e. cobol1, that diagnoses this
> > rather
> > > than the driver.
> >
> > I actually tried to do that, by looking for "case OPT_m32". in
> cobol1.cc.
> 
> No, you don't want to base the error on anything like that.
> E.g. for Solaris gcc defaults to -m32 and -m64 needs to be used.
> The error should be on missing features required for COBOL emitted after
> option processing during FE initialization.
> 
> The test for missing __int128 or missing IEEE quad support is
>   if (!targetm.scalar_mode_supported_p (TImode) || !float128_type_node)
> sorry ("COBOL not supported in this configuration"); or so.
> 
>   Jakub

Jakub, that seems to have done it.  Thanks very much, and I am sorry it
took me a little while to get here.

Bob Dubner

Ping [PATCH 0/2] v2 Add prime path coverage to gcc/gcov

[Jørgen Kvalsvik]

Ping.

On 2/21/25 19:15, Jørgen Kvalsvik wrote:

Ping

On 2/12/25 16:30, Jørgen Kvalsvik wrote:

I have applied fixes for everything in the last review, plus some GNU
style fixes that I had missed previously. We have tested and used a
build with this applied for 3-4 months now and haven't run into any
issues.

Jørgen Kvalsvik (2):
   gcov: branch, conds, calls in function summaries
   Add prime path coverage to gcc/gcov

  gcc/Makefile.in    |    6 +-
  gcc/builtins.cc    |    2 +-
  gcc/collect2.cc    |    6 +-
  gcc/common.opt |   16 +
  gcc/doc/gcov.texi  |  187 +++
  gcc/doc/invoke.texi    |   36 +
  gcc/gcc.cc |    4 +-
  gcc/gcov-counter.def   |    3 +
  gcc/gcov-io.h  |    3 +
  gcc/gcov.cc    |  535 +-
  gcc/ipa-inline.cc  |    2 +-
  gcc/passes.cc  |    4 +-
  gcc/path-coverage.cc   |  776 +
  gcc/prime-paths.cc | 2052 
  gcc/profile.cc |    6 +-
  gcc/selftest-run-tests.cc  |    1 +
  gcc/selftest.h |    1 +
  gcc/testsuite/g++.dg/gcov/gcov-22.C    |  170 ++
  gcc/testsuite/g++.dg/gcov/gcov-23-1.h  |    9 +
  gcc/testsuite/g++.dg/gcov/gcov-23-2.h  |    9 +
  gcc/testsuite/g++.dg/gcov/gcov-23.C    |   30 +
  gcc/testsuite/gcc.misc-tests/gcov-29.c |  869 ++
  gcc/testsuite/gcc.misc-tests/gcov-30.c |  869 ++
  gcc/testsuite/gcc.misc-tests/gcov-31.c |   35 +
  gcc/testsuite/gcc.misc-tests/gcov-32.c |   24 +
  gcc/testsuite/gcc.misc-tests/gcov-33.c |   27 +
  gcc/testsuite/gcc.misc-tests/gcov-34.c |   29 +
  gcc/testsuite/lib/gcov.exp |  118 +-
  gcc/tree-profile.cc    |   11 +-
  29 files changed, 5818 insertions(+), 22 deletions(-)
  create mode 100644 gcc/path-coverage.cc
  create mode 100644 gcc/prime-paths.cc
  create mode 100644 gcc/testsuite/g++.dg/gcov/gcov-22.C
  create mode 100644 gcc/testsuite/g++.dg/gcov/gcov-23-1.h
  create mode 100644 gcc/testsuite/g++.dg/gcov/gcov-23-2.h
  create mode 100644 gcc/testsuite/g++.dg/gcov/gcov-23.C
  create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-29.c
  create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-30.c
  create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-31.c
  create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-32.c
  create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-33.c
  create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-34.c

Ping [PATCH] Record, report basic blocks of conditional exprs

[Jørgen Kvalsvik]

Ping.

On 2/12/25 19:00, Jørgen Kvalsvik wrote:

Ping.

On 1/31/25 10:35, Jørgen Kvalsvik wrote:

Record basic blocks that make up a conditional expression with
-fcondition-coverage and report when using the gcov -w/--verbose flag.
This makes the report more accurate when basic blocks are included as
there may be blocks in-between the actual Boolean expressions, e.g. when
there a term is the result of a function call. This helps understanding
the report as gcc uses the CFG, and not source code, to figure out
MC/DC, which is somewhat lost in gcov. While it does not make a
tremendous difference for the gcov report directly, it opens up for more
analysis and clearer reporting.

This change includes deleting the GCOV_TAG_COND_* macros as the .gcno
records are now dynamic in length.

Here is an example with, comparing two programs:

int main() {
   int a = 1;
   int b = 0;

   if (a && b)
 printf ("Success!\n");
   else
 printf ("Failure!\n");
}

int f(int);
int g(int);
int main() {
   int a = 1;
   int b = 0;

   if (f (a) && g (b))
 printf ("Success!\n");
   else
 printf ("Failure!\n");
}

And the corresponding reports:
$ gcov -tagw p1 p2
 1:    3:int main() {
 1:    4:  int a = 1;
 1:    5:  int b = 0;
 -:    6:
 1:    7:  if (a && b)
 1:    7-block 2 (BB 2)
condition outcomes covered 1/4
BBs 2 3
condition  0 not covered (true false)
condition  1 not covered (true)
 1:    7-block 3 (BB 3)
 #:    8:    printf ("Success!\n");
 %:    8-block 4 (BB 4)
 -:    9:  else
 1:   10:    printf ("Failure!\n");
 1:   10-block 5 (BB 5)
 -:   11:}

 #:    6:int main() {
 #:    7:  int a = 1;
 #:    8:  int b = 0;
 -:    9:
 #:   10:  if (f (a) && g (b))
 %:   10-block 2 (BB 2)
condition outcomes covered 0/4
BBs 3 5
condition  0 not covered (true false)
condition  1 not covered (true false)
 %:   10-block 4 (BB 4)
 #:   11:    printf ("Success!\n");
 %:   11-block 6 (BB 6)
 -:   12:  else
 #:   13:    printf ("Failure!\n");
 %:   13-block 7 (BB 7)
 -:   14:}

gcc/ChangeLog:

* doc/gcov.texi: Add example.
 * gcov-dump.cc (tag_conditions): Print basic blocks, not length.
* gcov-io.h (GCOV_TAG_CONDS_LENGTH): Delete.
(GCOV_TAG_CONDS_NUM): Likewise.
* gcov.cc (output_intermediate_json_line): Output basic blocks.
(read_graph_file): Read basic blocks.
(output_conditions): Output basic blocks.
* profile.cc (branch_prob): Write basic blocks for conditions.
---
  gcc/doc/gcov.texi | 32 
  gcc/gcov-dump.cc  | 12 +++-
  gcc/gcov-io.h |  2 --
  gcc/gcov.cc   | 20 +++-
  gcc/profile.cc    | 11 +--
  5 files changed, 67 insertions(+), 10 deletions(-)

diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index dda279fbff3..268e9e553f3 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -423,6 +423,7 @@ Each @var{condition} has the following form:
    "covered": 2,
    "not_covered_false": [],
    "not_covered_true": [0, 1],
+  "basic_blocks": [2, 3]
  @}
  @end smallexample
@@ -989,6 +990,37 @@ condition  1 not covered (true)
  -:   12:@}
  @end smallexample
+With @option{-w}, each condition will also print the basic blocks that
+make up the decision.
+
+@smallexample
+$ gcov -t -m -g -a -w tmp
+    -:    0:Source:tmp.c
+    -:    0:Graph:tmp.gcno
+    -:    0:Data:tmp.gcda
+    -:    0:Runs:1
+    -:    1:#include 
+    -:    2:
+    1:    3:int main()
+    -:    4:@{
+    1:    5:  int a = 1;
+    1:    6:  int b = 0;
+    -:    7:
+    1:    7:  if (a && b)
+    1:    7-block 2 (BB 2)
+condition outcomes covered 1/4
+BBs 2 3
+condition  0 not covered (true false)
+condition  1 not covered (true)
+    1:    7-block 3 (BB 3)
+    #:    8:    printf ("Success!\n");
+    %:    8-block 4 (BB 4)
+    -:    9:  else
+    1:   10:    printf ("Failure!\n");
+    1:   10-block 5 (BB 5)
+    -:   12:@}
+@end smallexample
+
  The execution counts are cumulative.  If the example program were
  executed again without removing the @file{.gcda} file, the count for 
the

  number of times each line in the source was executed would be added to
diff --git a/gcc/gcov-dump.cc b/gcc/gcov-dump.cc
index cc7f8a9ebfb..642e58c22bf 100644
--- a/gcc/gcov-dump.cc
+++ b/gcc/gcov-dump.cc
@@ -396,23 +396,25 @@ tag_arcs (const char *filename ATTRIBUTE_UNUSED,
  /* Print number of conditions (not outcomes, i.e. if (x && y) is 2, 
not 4).  */

  static void
-tag_conditions (const char *filename, unsigned /* tag */, int length,
+tag_conditions (const char *filename, unsigned /* tag */, int /* 
length */,

  unsigned depth)
  {
-  unsigned n_conditions = GCOV_TAG_CONDS_NUM (length);
+  unsigned n_conditions = gcov_read_unsigned ();
    printf (" %u 

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

[Richard Biener]

On Tue, Mar 4, 2025 at 7:18 PM James K. Lowden  wrote:
>
> On Tue, 4 Mar 2025 00:08:16 +0100
> Jakub Jelinek  wrote:
>
> > On Mon, Mar 03, 2025 at 05:21:38PM -0500, James K. Lowden wrote:
> > > However IMO, the incantation:
> > >
> > > make install DESTDIR=/foo
> > >
> > > is invalid.  The compiler's library search path is fixed when the
> > > compiler is built, based on configure options.  Installing into an
> > > arbitrary directory cannot work; there is no opportunity then to
> > > alter the gcobol binary.
> >
> > This is how most distros install stuff for their packaging systems,
> > make install DESTDIR=/some/directory
> > and then everything under /some/directory
> > is packaged into the package.
> > GCC is generally relocatable, the compiler driver should find the
> > compiler and library/include directories etc. relative to where the
> > driver resides in the filesystem.
>
> Thank you for taking the time to explain that, Jakub.  I stand
> corrected, and I believe you'll find that DESTDIR works as intended
> using the current cobol-patched branch.  It works here for me.
>
> Somehow, despite reading the automake documentation over and over
> these last several days while we struggled to bring the libgcobol
> build process into the 20th [sic] century, I didn't put 2 + 2 together.
> Looking at it now, I see that by using automake we get DESTDIR for free,
> provided (as we do) that we use libtool for installation.
>
> In short, despite not trying to support DESTDIR, we do anyway, by happy
> accident.  And we are now better informed.

Thanks.  Checking cobol-patched again I see

obj2> make install DESTDIR=/home/rguenther/install/gcc-cobol
...
libtool: install: /usr/bin/install -c .libs/libgcobol.so.1.0.0T
/usr/local/lib64/../lib64/libgcobol.so.1.0.0
/usr/bin/install: cannot create regular file
'/usr/local/lib64/../lib64/libgcobol.so.1.0.0': Permission denied
make[2]: *** [Makefile:956: install] Error 1
make[2]: Leaving directory '/home/rguenther/obj2/x86_64-pc-linux-gnu/libgcobol'
make[1]: *** [Makefile:18349: install-target-libgcobol] Error 2
make[1]: Leaving directory '/home/rguenther/obj2'
make: *** [Makefile:2671: install] Error 2

so a DESTDIR install isn't quite working yet.

install: libgcobol$(libsuffix).la
$(LIBTOOL) --mode=install $(INSTALL) $^ $(libdir)/../lib64

the usual way would be to have automake/libtool generate the install rule by
only doing

toolexeclib_LTLIBRARIES = libgcobol.la

you have

lib_LTLIBRARIES = libgcobol.la

so simply removing the install: rule might work (there's toolexeeclib vs. lib,
this might or might not mean --enable-version-specific-runtime-libs will
break).

[time passes]

So dropping the install rule makes make install succeed but there's no
libgcobol installed.  I have the wrong automake on the test machine so
can't quickly check what happens when using toolexeclib_LTLIBRARIES

>
> Regards,
>
> --jkl

[PATCH] libstdc++: use if consteval in stable_sort

[Giuseppe D'Angelo]

Hi,

I'm attaching a very small cleanup for constexpr std::stable_sort, using 
`if consteval` instead of `__is_constant_evaluated` within a C++26 feature.


Thanks,
--
Giuseppe D'Angelo
From d81ed6c0e5eb8b4bce831217bafdf71c183b1ffa Mon Sep 17 00:00:00 2001
From: Giuseppe D'Angelo 
Date: Wed, 5 Mar 2025 14:34:41 +0100
Subject: [PATCH] libstdc++: use if consteval in stable_sort

This is a C++ >= 26 codepath for supporting constexpr stable_sort, so we
know that we have if consteval available; it just needs protection with
the feature-testing macro. Also merge the return in the same statement.
Amends r15-7708-gff43f9853d3b10.

libstdc++-v3/ChangeLog:

	* include/bits/stl_algo.h (__stable_sort): Use if consteval
	instead of is_constant_evaluated.

Signed-off-by: Giuseppe D'Angelo 
---
 libstdc++-v3/include/bits/stl_algo.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libstdc++-v3/include/bits/stl_algo.h b/libstdc++-v3/include/bits/stl_algo.h
index 41b4d0853b7..c3fea76014c 100644
--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -4987,11 +4987,11 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
 	return;
 
 #if _GLIBCXX_HOSTED
-  if (__is_constant_evaluated())
-	{
-	  std::__inplace_stable_sort(__first, __last, __comp);
-	  return;
-	}
+# if __glibcxx_constexpr_algorithms >= 202306L // >= C++26
+  if consteval {
+	return std::__inplace_stable_sort(__first, __last, __comp);
+  }
+# endif
 
   typedef _Temporary_buffer<_RandomAccessIterator, _ValueType> _TmpBuf;
   // __stable_sort_adaptive sorts the range in two halves,
-- 
2.34.1



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Richard Biener]

On Wed, Mar 5, 2025 at 4:47 PM Robert Dubner  wrote:
>
> > -Original Message-
> > From: Jakub Jelinek 
> > Sent: Wednesday, March 5, 2025 08:35
> > To: Richard Biener 
> > Cc: James K. Lowden ; gcc-patches@gcc.gnu.org
> > Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
> >
> > On Wed, Mar 05, 2025 at 12:46:48PM +0100, Richard Biener wrote:
> > > and the installed compiler behaves as intended.  I can trick -m32 to
> > "work"
> > > by using the generic gcc diriver:
> > >
> > > > ./install/gcc-cobol/usr/local/bin/gcc -x cobol t.cob -m32 -c
> > >
> > > but I think this is a less important issue.
> >
> > Agreed, it should be the compiler, i.e. cobol1, that diagnoses this
> rather
> > than the driver.
>
> I actually tried to do that, by looking for "case OPT_m32". in cobol1.cc.
>
> I learned that OPT_m32 wasn't being delivered to
> "cobol_langhook_handle_option()"
>
> I made a quick attempt at making "m32" a COBOL switch, so that it would be
> sent.  But all I managed to do was create compilation errors, so I gave
> up.
>
> Any advice will land on grateful ears.

As I suggested I'd see if __int128 is supported instead and sorry () when not,
diagnosing that __int128 is required to compile Cobol.

Richard.

>
> >
> >   Jakub
>

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

[Robert Dubner]

> -Original Message-
> From: Jakub Jelinek 
> Sent: Wednesday, March 5, 2025 08:35
> To: Richard Biener 
> Cc: James K. Lowden ; gcc-patches@gcc.gnu.org
> Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
> 
> On Wed, Mar 05, 2025 at 12:46:48PM +0100, Richard Biener wrote:
> > and the installed compiler behaves as intended.  I can trick -m32 to
> "work"
> > by using the generic gcc diriver:
> >
> > > ./install/gcc-cobol/usr/local/bin/gcc -x cobol t.cob -m32 -c
> >
> > but I think this is a less important issue.
> 
> Agreed, it should be the compiler, i.e. cobol1, that diagnoses this
rather
> than the driver.

I actually tried to do that, by looking for "case OPT_m32". in cobol1.cc.

I learned that OPT_m32 wasn't being delivered to
"cobol_langhook_handle_option()"

I made a quick attempt at making "m32" a COBOL switch, so that it would be
sent.  But all I managed to do was create compilation errors, so I gave
up.

Any advice will land on grateful ears.

> 
>   Jakub

[PATCH v2] c++: disable -Wnonnull in unevaluated context [PR115580]

[Marek Polacek]

On Tue, Mar 04, 2025 at 04:41:05PM -0500, Jason Merrill wrote:
> On 3/4/25 3:26 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > -- >8 --
> > This PR complains that we issue a -Wnonnull even in a decltype.
> > Since we can't use cp_unevaluated_operand in c-common.cc, this
> 
> Would it make sense to check c_inhibit_evaluation_warnings instead?

Yes, I think that would be better, thanks.

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

-- >8 --
This PR complains that we issue a -Wnonnull even in a decltype.
This fix disables even -Wformat and -Wrestrict.  I think that's fine.

PR c++/115580

gcc/c-family/ChangeLog:

* c-common.cc (check_function_arguments): Return early if
c_inhibit_evaluation_warnings.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wnonnull16.C: New test.
---
 gcc/c-family/c-common.cc   |  3 +++
 gcc/testsuite/g++.dg/warn/Wnonnull16.C | 16 
 2 files changed, 19 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wnonnull16.C

diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 49508fe9ee6..587d76461e9 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -6261,6 +6261,9 @@ check_function_arguments (location_t loc, const_tree 
fndecl, const_tree fntype,
 {
   bool warned_p = false;
 
+  if (c_inhibit_evaluation_warnings)
+return warned_p;
+
   /* Check for null being passed in a pointer argument that must be
  non-null.  In C++, this includes the this pointer.  We also need
  to do this if format checking is enabled.  */
diff --git a/gcc/testsuite/g++.dg/warn/Wnonnull16.C 
b/gcc/testsuite/g++.dg/warn/Wnonnull16.C
new file mode 100644
index 000..8740f351ac7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wnonnull16.C
@@ -0,0 +1,16 @@
+// PR c++/115580
+// { dg-do compile { target c++11 } }
+
+class WithMember {
+public:
+  int foo();
+};
+
+decltype(((WithMember*)nullptr)->foo()) footype; // { dg-bogus "pointer is 
null" }
+
+int f(void*) __attribute__((nonnull));
+
+void g()
+{
+  [[maybe_unused]] decltype(f(nullptr)) b; // { dg-bogus "non-null" }
+}

base-commit: ff505948631713d8c62523005059b10e25343617
-- 
2.48.1

Re: [PATCH] libstdc++: Implement P0849R8 auto(x) library changes

[Patrick Palka]

On Thu, 24 Oct 2024, Jonathan Wakely wrote:

> On Wed, 9 Oct 2024 at 14:02, Patrick Palka  wrote:
> >
> > On Mon, 7 Oct 2024, Patrick Palka wrote:
> >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk only?
> > > This doesn't seem worth backporting since there should be no
> > > behavior change.
> > >
> > > -- >8 --
> > >
> > > This implements the library changes in P0849R8 "auto(x): decay-copy
> > > in the language" which consist of replacing most uses of the
> > > exposition-only function decay-copy with auto(x) throughout the library
> > > wording.
> > >
> > > Note the main difference between the two is that decay-copy materializes
> > > its argument whereas auto(x) doesn't, and so the latter is a no-op when
> > > its argument is a prvalue.  Effectively the former could introduce an
> > > unnecessary move constructor call in some contexts.  In C++20 and earlier
> > > we could emulate auto(x) with decay_t(x).
> >
> > I should note this patch is treating this paper as a DR against C++20,
> > which should be fine since there should be no behavior change in
> > practice (especially in light of LWG 3724 which constrains decay-copy
> > to make it SFINAE-friendly).
> 
> Yes, that seems fine.
> 
> OK for trunk, thanks.

Thanks for the review.  I never pushed this patch because I had a
last-minute concern about the new macro _GLIBCXX_AUTO_CAST potentially
introducing mangling changes between C++20 / 23 if it's used directly
in a function signature (it's not currently, but in the future it
might), that I never got around to raising.

I was thinking about "hardening" the macro by defining it in terms of
the __decay built-in trait if it's available?  That way, if it's
used in a function signature then any attempts at mangling the function
will result in an error due to built-in traits not being mangleable.

Is this something we care about?  If not, shall we push this for GCC 15
or wait until stage 1?  Seems rather safe, and affects only C++20 code.

> 
> 
> >
> > >
> > > After this paper the only remaining uses of decay-copy in the library
> > > are in the specification of some range adaptors.  In our implementation
> > > of those range adaptors I believe decay-copy is already implied which
> > > is why we don't mirror the wording and use __decay_copy explicitly.  So
> > > since it's apparently no longer needed this patch goes ahead and removes
> > > __decay_copy.
> > >
> > > libstdc++-v3/ChangeLog:
> > >
> > >   * c++config (_GLIBCXX_AUTO_CAST): Define.
> > >   * include/bits/iterator_concepts.h (_Decay_copy, __decay_copy):
> > >   Remove.
> > >   (__member_begin, __adl_begin): Use _GLIBCXX_AUTO_CAST instead of
> > >   __decay_copy as per P0849R8.
> > >   * include/bits/ranges_base.h (_Begin): Likewise.
> > >   (__member_end, __adl_end, _End): Likewise.
> > >   (__member_rbegin, __adl_rbegin, _RBegin): Likewise.
> > >   (__member_rend, __adl_rend, _Rend): Likewise.
> > >   (__member_size, __adl_size, _Size): Likewise.
> > >   (_Data): Likewise.
> > > ---
> > >  libstdc++-v3/include/bits/c++config   |  6 +++
> > >  libstdc++-v3/include/bits/iterator_concepts.h | 13 +-
> > >  libstdc++-v3/include/bits/ranges_base.h   | 40 +--
> > >  3 files changed, 28 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/libstdc++-v3/include/bits/c++config 
> > > b/libstdc++-v3/include/bits/c++config
> > > index 29d795f687c..fdbf90e28fc 100644
> > > --- a/libstdc++-v3/include/bits/c++config
> > > +++ b/libstdc++-v3/include/bits/c++config
> > > @@ -265,6 +265,12 @@
> > >  #define _GLIBCXX_NOEXCEPT_QUAL
> > >  #endif
> > >
> > > +#if __cpp_auto_cast
> > > +# define _GLIBCXX_AUTO_CAST(X) auto(X)
> > > +#else
> > > +# define _GLIBCXX_AUTO_CAST(X) ::std::__decay_t(X)
> > > +#endif
> > > +
> > >  // Macro for extern template, ie controlling template linkage via use
> > >  // of extern keyword on template declaration. As documented in the g++
> > >  // manual, it inhibits all implicit instantiations and is used
> > > diff --git a/libstdc++-v3/include/bits/iterator_concepts.h 
> > > b/libstdc++-v3/include/bits/iterator_concepts.h
> > > index 490a362cdf1..0fcfed56737 100644
> > > --- a/libstdc++-v3/include/bits/iterator_concepts.h
> > > +++ b/libstdc++-v3/include/bits/iterator_concepts.h
> > > @@ -1003,19 +1003,10 @@ namespace ranges
> > >{
> > >  using std::__detail::__class_or_enum;
> > >
> > > -struct _Decay_copy final
> > > -{
> > > -  template
> > > - constexpr decay_t<_Tp>
> > > - operator()(_Tp&& __t) const
> > > - noexcept(is_nothrow_convertible_v<_Tp, decay_t<_Tp>>)
> > > - { return std::forward<_Tp>(__t); }
> > > -} inline constexpr __decay_copy{};
> > > -
> > >  template
> > >concept __member_begin = requires(_Tp& __t)
> > >   {
> > > -   { __decay_copy(__t.begin()) } -> input_or_output_iterator;
> > > +   { _GLIBCXX_AUTO_CAST(__t.begin()) } -> input_or_output_iterator;
> > >

[PATCH] debug/101533 - ICE with variant typedef DIE generation

[Richard Biener]

There's a sanity check in gen_type_die_with_usage that trips
unnecessarily for a case where the relevant DIE has already been
generated successfully in other ways.  The following keys the
existing TREE_ASM_WRITTEN check on the correct object, honoring
this and does nothing instead of ICEing for the testcase at hand.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

OK?

Thanks,
Richard.

PR debug/101533
* dwarf2out.cc (gen_type_die_with_usage): When we have
output the typedef already do nothing for a typedef variant.
Do not set TREE_ASM_WRITTEN on the type itself, recursion
on the name should do this.

* g++.dg/debug/pr101533.C: New testcase.
---
 gcc/dwarf2out.cc  |  6 ++
 gcc/testsuite/g++.dg/debug/pr101533.C | 11 +++
 2 files changed, 13 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/debug/pr101533.C

diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index ed7d9402200..d4c51554e3e 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -26419,10 +26419,10 @@ gen_type_die_with_usage (tree type, dw_die_ref 
context_die,
  for the parent typedef which TYPE is a type of.  */
   if (typedef_variant_p (type))
 {
-  if (TREE_ASM_WRITTEN (type))
+  tree name = TYPE_NAME (type);
+  if (TREE_ASM_WRITTEN (name))
return;
 
-  tree name = TYPE_NAME (type);
   tree origin = decl_ultimate_origin (name);
   if (origin != NULL && origin != name)
{
@@ -26436,8 +26436,6 @@ gen_type_die_with_usage (tree type, dw_die_ref 
context_die,
   /* Give typedefs the right scope.  */
   context_die = scope_die_for (type, context_die);
 
-  TREE_ASM_WRITTEN (type) = 1;
-
   gen_decl_die (name, NULL, NULL, context_die);
   return;
 }
diff --git a/gcc/testsuite/g++.dg/debug/pr101533.C 
b/gcc/testsuite/g++.dg/debug/pr101533.C
new file mode 100644
index 000..fc1e2e742a1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/debug/pr101533.C
@@ -0,0 +1,11 @@
+// { dg-do compile }
+// { dg-options "-g" }
+
+template  class T
+{
+  typedef struct {} a __attribute__((aligned));
+};
+void f ()
+{
+  T();
+}
-- 
2.43.0

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

[Jakub Jelinek]

On Wed, Mar 05, 2025 at 09:47:45AM -0600, Robert Dubner wrote:
> > -Original Message-
> > From: Jakub Jelinek 
> > Sent: Wednesday, March 5, 2025 08:35
> > To: Richard Biener 
> > Cc: James K. Lowden ; gcc-patches@gcc.gnu.org
> > Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
> > 
> > On Wed, Mar 05, 2025 at 12:46:48PM +0100, Richard Biener wrote:
> > > and the installed compiler behaves as intended.  I can trick -m32 to
> > "work"
> > > by using the generic gcc diriver:
> > >
> > > > ./install/gcc-cobol/usr/local/bin/gcc -x cobol t.cob -m32 -c
> > >
> > > but I think this is a less important issue.
> > 
> > Agreed, it should be the compiler, i.e. cobol1, that diagnoses this
> rather
> > than the driver.
> 
> I actually tried to do that, by looking for "case OPT_m32". in cobol1.cc.

No, you don't want to base the error on anything like that.
E.g. for Solaris gcc defaults to -m32 and -m64 needs to be used.
The error should be on missing features required for COBOL
emitted after option processing during FE initialization.

The test for missing __int128 or missing IEEE quad support is
  if (!targetm.scalar_mode_supported_p (TImode) || !float128_type_node)
sorry ("COBOL not supported in this configuration");
or so.

Jakub

Re: [PATCH] libstdc++: Implement P0849R8 auto(x) library changes

[Patrick Palka]

On Wed, 5 Mar 2025, Patrick Palka wrote:

> On Thu, 24 Oct 2024, Jonathan Wakely wrote:
> 
> > On Wed, 9 Oct 2024 at 14:02, Patrick Palka  wrote:
> > >
> > > On Mon, 7 Oct 2024, Patrick Palka wrote:
> > >
> > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk only?
> > > > This doesn't seem worth backporting since there should be no
> > > > behavior change.
> > > >
> > > > -- >8 --
> > > >
> > > > This implements the library changes in P0849R8 "auto(x): decay-copy
> > > > in the language" which consist of replacing most uses of the
> > > > exposition-only function decay-copy with auto(x) throughout the library
> > > > wording.
> > > >
> > > > Note the main difference between the two is that decay-copy materializes
> > > > its argument whereas auto(x) doesn't, and so the latter is a no-op when
> > > > its argument is a prvalue.  Effectively the former could introduce an
> > > > unnecessary move constructor call in some contexts.  In C++20 and 
> > > > earlier
> > > > we could emulate auto(x) with decay_t(x).
> > >
> > > I should note this patch is treating this paper as a DR against C++20,
> > > which should be fine since there should be no behavior change in
> > > practice (especially in light of LWG 3724 which constrains decay-copy
> > > to make it SFINAE-friendly).
> > 
> > Yes, that seems fine.
> > 
> > OK for trunk, thanks.
> 
> Thanks for the review.  I never pushed this patch because I had a
> last-minute concern about the new macro _GLIBCXX_AUTO_CAST potentially
> introducing mangling changes between C++20 / 23 if it's used directly
> in a function signature (it's not currently, but in the future it
> might), that I never got around to raising.
> 
> I was thinking about "hardening" the macro by defining it in terms of
> the __decay built-in trait if it's available?  That way, if it's
> used in a function signature then any attempts at mangling the function
> will result in an error due to built-in traits not being mangleable.

Alternatively we could unconditionally define it as

  ::std::__decay_t(X)

even in C++23 mode, which should always be equivalent to auto(X)?

> 
> Is this something we care about?  If not, shall we push this for GCC 15
> or wait until stage 1?  Seems rather safe, and affects only C++20 code.
> 
> > 
> > 
> > >
> > > >
> > > > After this paper the only remaining uses of decay-copy in the library
> > > > are in the specification of some range adaptors.  In our implementation
> > > > of those range adaptors I believe decay-copy is already implied which
> > > > is why we don't mirror the wording and use __decay_copy explicitly.  So
> > > > since it's apparently no longer needed this patch goes ahead and removes
> > > > __decay_copy.
> > > >
> > > > libstdc++-v3/ChangeLog:
> > > >
> > > >   * c++config (_GLIBCXX_AUTO_CAST): Define.
> > > >   * include/bits/iterator_concepts.h (_Decay_copy, __decay_copy):
> > > >   Remove.
> > > >   (__member_begin, __adl_begin): Use _GLIBCXX_AUTO_CAST instead of
> > > >   __decay_copy as per P0849R8.
> > > >   * include/bits/ranges_base.h (_Begin): Likewise.
> > > >   (__member_end, __adl_end, _End): Likewise.
> > > >   (__member_rbegin, __adl_rbegin, _RBegin): Likewise.
> > > >   (__member_rend, __adl_rend, _Rend): Likewise.
> > > >   (__member_size, __adl_size, _Size): Likewise.
> > > >   (_Data): Likewise.
> > > > ---
> > > >  libstdc++-v3/include/bits/c++config   |  6 +++
> > > >  libstdc++-v3/include/bits/iterator_concepts.h | 13 +-
> > > >  libstdc++-v3/include/bits/ranges_base.h   | 40 +--
> > > >  3 files changed, 28 insertions(+), 31 deletions(-)
> > > >
> > > > diff --git a/libstdc++-v3/include/bits/c++config 
> > > > b/libstdc++-v3/include/bits/c++config
> > > > index 29d795f687c..fdbf90e28fc 100644
> > > > --- a/libstdc++-v3/include/bits/c++config
> > > > +++ b/libstdc++-v3/include/bits/c++config
> > > > @@ -265,6 +265,12 @@
> > > >  #define _GLIBCXX_NOEXCEPT_QUAL
> > > >  #endif
> > > >
> > > > +#if __cpp_auto_cast
> > > > +# define _GLIBCXX_AUTO_CAST(X) auto(X)
> > > > +#else
> > > > +# define _GLIBCXX_AUTO_CAST(X) ::std::__decay_t(X)
> > > > +#endif
> > > > +
> > > >  // Macro for extern template, ie controlling template linkage via use
> > > >  // of extern keyword on template declaration. As documented in the g++
> > > >  // manual, it inhibits all implicit instantiations and is used
> > > > diff --git a/libstdc++-v3/include/bits/iterator_concepts.h 
> > > > b/libstdc++-v3/include/bits/iterator_concepts.h
> > > > index 490a362cdf1..0fcfed56737 100644
> > > > --- a/libstdc++-v3/include/bits/iterator_concepts.h
> > > > +++ b/libstdc++-v3/include/bits/iterator_concepts.h
> > > > @@ -1003,19 +1003,10 @@ namespace ranges
> > > >{
> > > >  using std::__detail::__class_or_enum;
> > > >
> > > > -struct _Decay_copy final
> > > > -{
> > > > -  template
> > > > - constexpr decay_t<_Tp>
> > > > - operator()(_Tp&& __t) const
> > 

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

[Robert Dubner]

> -Original Message-
> From: Richard Biener 
> Sent: Wednesday, March 5, 2025 10:50
> To: Robert Dubner 
> Cc: Jakub Jelinek ; James K. Lowden
> ; gcc-patches@gcc.gnu.org
> Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
>
> On Wed, Mar 5, 2025 at 4:47 PM Robert Dubner  wrote:
> >
> > > -Original Message-
> > > From: Jakub Jelinek 
> > > Sent: Wednesday, March 5, 2025 08:35
> > > To: Richard Biener 
> > > Cc: James K. Lowden ;
> > > gcc-patches@gcc.gnu.org
> > > Subject: Re: The COBOL front end, version 3, now in 14 easy pieces
> > >
> > > On Wed, Mar 05, 2025 at 12:46:48PM +0100, Richard Biener wrote:
> > > > and the installed compiler behaves as intended.  I can trick -m32
> > > > to
> > > "work"
> > > > by using the generic gcc diriver:
> > > >
> > > > > ./install/gcc-cobol/usr/local/bin/gcc -x cobol t.cob -m32 -c
> > > >
> > > > but I think this is a less important issue.
> > >
> > > Agreed, it should be the compiler, i.e. cobol1, that diagnoses this
> > rather
> > > than the driver.
> >
> > I actually tried to do that, by looking for "case OPT_m32". in
> cobol1.cc.
> >
> > I learned that OPT_m32 wasn't being delivered to
> > "cobol_langhook_handle_option()"
> >
> > I made a quick attempt at making "m32" a COBOL switch, so that it
> > would be sent.  But all I managed to do was create compilation errors,
> > so I gave up.
> >
> > Any advice will land on grateful ears.
>
> As I suggested I'd see if __int128 is supported instead and sorry () when
> not, diagnosing that __int128 is required to compile Cobol.
>

At the present time, I am noticing OPT_m32 in the driver with this code in 
gcobolspec.cc:

#ifdef __x86_64__
  case OPT_m32:
error ( "unrecognized command-line option %<-%s%>; "
"(32-bit executables cannot be generated)", "m32");
break;
#endif

The #ifdef is needed because when compiling on an aarch64, OPT_m32 isn't 
defined.

I did that to more-or-less match what I saw when I put an absurd "-m47" on a 
gcc command line.

The question here is that I need OPT_m32 to be delivered to 
cobol_langhook_handle_option(), so I could do the test there.  I made a 
casual attempt at that, and quickly gave up when I couldn't make it work.

Somewhere there is an incantation that will cause OPT_m32 to be delivered to 
cobol_langhook_handle_option().  I just didn't dig deeply into where, or 
how.  I'll do that now, but a pointer would be appreciated.

> Richard.
>
> >
> > >
> > >   Jakub
> >

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

[Jakub Jelinek]

On Wed, Mar 05, 2025 at 12:46:48PM +0100, Richard Biener wrote:
> and the installed compiler behaves as intended.  I can trick -m32 to "work"
> by using the generic gcc diriver:
> 
> > ./install/gcc-cobol/usr/local/bin/gcc -x cobol t.cob -m32 -c
> 
> but I think this is a less important issue.

Agreed, it should be the compiler, i.e. cobol1, that diagnoses this rather
than the driver.

Jakub

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

[Patrick Palka]

On Tue, 4 Mar 2025, Jason Merrill wrote:

> On 3/4/25 2:49 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk/14?
> > 
> > -- >8 --
> > 
> > In the three-parameter version of satisfy_declaration_constraints, when
> > 't' isn't the most general template, then 't' won't correspond with
> > 'args' after we augment the latter via add_outermost_template_args, and
> > so the instantiation context that we push via push_tinst_level isn't
> > quite correct: 'args' is a complete set of template arguments, but 't'
> > is not necessarily the most general template.  This manifests as
> > misleading diagnostic context lines when issuing a hard error (or a
> > constraint recursion error) that occurred during satisfaction, e.g. for
> > the below testcase without this patch we emit:
> >In substitution of '... void A::f() [with U = int]'
> > and with this patch we emit:
> >In substitution of '... void A::f() [with U = char; T = int]'.
> > 
> > This patch fixes this by always passing the most general template to
> > push_tinst_level.
> 
> That soungs good, but getting it by passing it back from
> get_normalized_constraints_from_decl seems confusing; I'd think we should
> calculate it in parallel to changing args to correspond to that template.

Hmm, won't that mean duplicating the template adjustment logic in
get_normalized_constraints_from_decl, which seems undesirable?  The
function has many callers, some of which are for satisfaction where
targs are involved, and the rest are for subsumption where no targs are
involved, so I don't see a clean way of refactoring the code to avoid
duplication of the template adjustment logic.  Right now the targ
adjustment logic is unfortunately duplicated across both overloads
of satisfy_declaration_constraints and it seems undesirable to add
more duplication.

Maybe one way to reduce the duplication would be to go the other way and
move the targ adjustment logic to get_normalized_constraints_from_decl
as well (so that it has two out-parameters, 'gen_d' and 'gen_args').
The proposed patch then would be an incremental step towards that.

> 
> > PR c++/99214
> > 
> > gcc/cp/ChangeLog:
> > 
> > * constraint.cc (get_normalized_constraints_from_decl): New
> > out-parameter GEN_D.
> > (satisfy_declaration_constraints): Use it to pass the most
> > general version of T to push_tinst_level.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/concepts/diagnostic20.C: New test.
> > ---
> >   gcc/cp/constraint.cc | 15 +++
> >   gcc/testsuite/g++.dg/concepts/diagnostic20.C | 15 +++
> >   2 files changed, 26 insertions(+), 4 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic20.C
> > 
> > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> > index a9caba8e2cc..f688a99c5fd 100644
> > --- a/gcc/cp/constraint.cc
> > +++ b/gcc/cp/constraint.cc
> > @@ -648,10 +648,13 @@ get_normalized_constraints_from_info (tree ci, tree
> > in_decl, bool diag = false)
> > return t;
> >   }
> >   -/* Returns the normalized constraints for the declaration D.  */
> > +/* Returns the normalized constraints for the declaration D.
> > +   If GEN_D is non-NULL, sets *GEN_D to the most general version
> > +   of D that ultimately owns its constraints.  */
> > static tree
> > -get_normalized_constraints_from_decl (tree d, bool diag = false)
> > +get_normalized_constraints_from_decl (tree d, bool diag = false,
> > + tree *gen_d = nullptr)
> >   {
> > tree tmpl;
> > tree decl;
> > @@ -716,6 +719,8 @@ get_normalized_constraints_from_decl (tree d, bool diag
> > = false)
> >   tmpl = most_general_template (tmpl);
> >   d = tmpl ? tmpl : decl;
> > +  if (gen_d)
> > +*gen_d = d;
> >   /* If we're not diagnosing errors, use cached constraints, if any.  */
> > if (!diag)
> > @@ -2730,9 +2735,11 @@ satisfy_declaration_constraints (tree t, tree args,
> > sat_info info)
> >   return boolean_true_node;
> >   tree result = boolean_true_node;
> > -  if (tree norm = get_normalized_constraints_from_decl (t, info.noisy ()))
> > +  tree gen_t;
> > +  if (tree norm = get_normalized_constraints_from_decl (t, info.noisy (),
> > +   &gen_t))
> >   {
> > -  if (!push_tinst_level (t, args))
> > +  if (!push_tinst_level (gen_t, args))
> > return result;
> > tree pattern = DECL_TEMPLATE_RESULT (t);
> > push_to_top_level ();
> > diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic20.C
> > b/gcc/testsuite/g++.dg/concepts/diagnostic20.C
> > new file mode 100644
> > index 000..b8d586e9a21
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/concepts/diagnostic20.C
> > @@ -0,0 +1,15 @@
> > +// PR c++/99214
> > +// { dg-do compile { target c++20 } }
> > +
> > +template 
> > +struct A {
> > +  template  static void f() requires ([] { re

Re: [PATCH] libstdc++: use if consteval in stable_sort

[Jonathan Wakely]

On Wed, 5 Mar 2025 at 13:44, Giuseppe D'Angelo wrote:
>
> Hi,
>
> I'm attaching a very small cleanup for constexpr std::stable_sort, using
> `if consteval` instead of `__is_constant_evaluated` within a C++26 feature.

OK for trunk, thanks.

You can drop the Signed-off-by from the commit message now if you
like, because you added yourself to the DCO section of MAINTAINERS.
Listing yourself in that section means the DCO sign-off is implied for
every commit.

[PATCH] PR rtl-optimization/119046: aarch64: Fix PARALLEL mode for vec_perm DUP expansion

[Kyrylo Tkachov]

Hi all,

The PARALLEL created in aarch64_evpc_dup is used to hold the lane number.
It is not appropriate for it to have a vector mode.
Other such uses use VOIDmode.
Do this here as well.
This avoids the risk of generic code treating the PARALLEL as trapping when it
has floating-point mode.

Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to trunk.
Thanks,
Kyrill

Signed-off-by: Kyrylo Tkachov 

PR rtl-optimization/119046
* config/aarch64/aarch64.cc (aarch64_evpc_dup): Use VOIDmode for
PARALLEL.



0001-PR-rtl-optimization-119046-aarch64-Fix-PARALLEL-mode.patch
Description: 0001-PR-rtl-optimization-119046-aarch64-Fix-PARALLEL-mode.patch

Re: [PATCH v2] RISC-V: Adjust LMUL when using maximum SEW [PR117955].

[Jeff Law]

On 3/5/25 7:39 AM, Robin Dapp wrote:

Hi,

when merging two vsetvls that both only demand "SEW >= ..." we
use their maximum SEW and keep the LMUL.  That may lead to invalid
vector configurations like
  e64, mf4.
As we make sure that the SEW requirements overlap we can use the SEW
and LMUL of the configuration with the larger SEW.

Ma Jin already touched this merge rule some weeks ago and fixed the
ratio calculation (r15-6873).  Calculating the ratio from an invalid
SEW/LMUL combination lead to an overflow in the ratio variable, though.
I'd argue the proper fix is to update SEW and LMUL, keeping the ratio
as before.  This "breaks" bug-10.c but its check only checked for a
workaround anyway so I turned it into a run test.

For V2, Ma Jin helped minify the PR's test and provided a larger test
case for bug-10.

Regtested on rv64gcv_zvl512b.

Regards
Robin

 PR target/117955

gcc/ChangeLog:

 * config/riscv/riscv-vsetvl.cc: Use LMUL/ratio from vsetvl with
 larger SEW.

gcc/testsuite/ChangeLog:

 * gcc.target/riscv/rvv/base/bug-10.c: Convert to run test.
 * gcc.target/riscv/rvv/base/bug-10-2.c: New test.
 * gcc.target/riscv/rvv/base/pr117955.c: New test.

OK
jeff

Re: [PATCH 2/2] libstdc++: Some concat_view bugfixes [PR115215, PR115218, LWG 4082]

[Patrick Palka]

On Mon, 17 Feb 2025, Patrick Palka wrote:

> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> 
> -- >8 --
> 
> - Use __builtin_unreachable to suppress a false-positive "control
>   reaches end of non-void function" warning in the recursive lambda
>   (which the existing tests failed to notice since test01 wasn't
>   being called at runtime)
> - Relax the constraints on views::concat in the single-argument case
>   as per PR115215
> - Add an input_range requirement to that same case as per LWG 4082
> - In the const-converting constructor of concat_view's iterator,
>   don't require the first iterator to be default constructible
> 
>   PR libstdc++/115215
>   PR libstdc++/115218
> 
> libstdc++-v3/ChangeLog:
> 
>   * include/std/ranges
>   (concat_view::iterator::_S_invoke_with_runtime_index): Use
>   __builtin_unreachable in recursive lambda to certify it always
>   exits via 'return'.
>   (concat_view::iterator::iterator): In the const-converting
>   constructor, direct initialize _M_it.
>   (views::_Concat::operator()): Adjust constraints in the
>   single-argument case as per LWG 4082.
>   * testsuite/std/ranges/concat/1.cc (test01): Call it at runtime
>   too.
>   (test04): New test.
> ---
>  libstdc++-v3/include/std/ranges   | 28 +--
>  libstdc++-v3/testsuite/std/ranges/concat/1.cc | 16 +++
>  2 files changed, 30 insertions(+), 14 deletions(-)
> 
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index 22e0c9cae44..a56dae43625 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -9919,6 +9919,7 @@ namespace ranges
>   return __f.template operator()<_Idx>();
> if constexpr (_Idx + 1 < sizeof...(_Vs))
>   return __self.template operator()<_Idx + 1>();
> +   __builtin_unreachable();
>   }.template operator()<0>();
>}
>  
> @@ -9940,12 +9941,12 @@ namespace ranges
>  constexpr
>  iterator(iterator __it)
>requires _Const && (convertible_to, iterator_t _Vs>> && ...)
> -: _M_parent(__it._M_parent)
> -{
> -  _M_invoke_with_runtime_index([this, &__it]() {
> - _M_it.template emplace<_Idx>(std::get<_Idx>(std::move(__it._M_it)));
> -  });
> -}
> +: _M_parent(__it._M_parent),
> +  _M_it(_S_invoke_with_runtime_index([this, &__it]() {
> +   return __base_iter(in_place_index<_Idx>,
> +  std::get<_Idx>(std::move(__it._M_it)));
> + }, __it._M_it.index()))
> +{ }
>  
>  constexpr decltype(auto)
>  operator*() const
> @@ -10179,16 +10180,15 @@ namespace ranges
>  
>  struct _Concat
>  {
> -  template
> - requires __detail::__can_concat_view<_Ts...>
> +  template<__detail::__can_concat_view... _Ts>

As pointed out by Tomasz, this change is incorrect and unnecessary.
The former checks __can_concat_view<_Ts...> whereas the latter checks
(__can_concat_view && ...).  Here's v2 with this change reverted:

-- >8 --

Subject: [PATCH v2] libstdc++: Some concat_view bugfixes [PR115215, PR115218, 
LWG
 4082]

- Use __builtin_unreachable to suppress a false-positive "control
  reaches end of non-void function" warning in the recursive lambda
  (which the existing tests failed to notice since test01 wasn't
  being called at runtime)
- Relax the constraints on views::concat in the single-argument case
  as per PR115215
- Add an input_range requirement to that same case as per LWG 4082
- In the const-converting constructor of concat_view's iterator,
  don't require the first iterator to be default constructible

PR libstdc++/115215
PR libstdc++/115218

libstdc++-v3/ChangeLog:

* include/std/ranges
(concat_view::iterator::_S_invoke_with_runtime_index): Use
__builtin_unreachable in recursive lambda to certify it always
exits via 'return'.
(concat_view::iterator::iterator): In the const-converting
constructor, direct initialize _M_it.
(views::_Concat::operator()): Adjust constraints in the
single-argument case as per LWG 4082.
* testsuite/std/ranges/concat/1.cc (test01): Call it at runtime
too.
(test04): New test.
---
 libstdc++-v3/include/std/ranges   | 25 ++-
 libstdc++-v3/testsuite/std/ranges/concat/1.cc | 16 
 2 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 6c65722b687..2228ab8c5ee 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -9919,6 +9919,7 @@ namespace ranges
return __f.template operator()<_Idx>();
  if constexpr (_Idx + 1 < sizeof...(_Vs))
return __self.template operator()<_Idx + 1>();
+ __builtin_unreachable();
}.template operator()<0>();
   }
 
@@ -9940,12 +9941,12 @@ namespace rang

Re: [PATCH] go/119098 - bump libgo version for GCC 15 release

[Richard Biener]

On Tue, 4 Mar 2025, Ian Lance Taylor wrote:

> On Tue, Mar 4, 2025 at 2:12 AM Richard Biener  wrote:
> 
> > As PR119098 shows the gccgo driver uses the install path compiled
> > into the shared libgo and thus updating that but not the driver
> > will cause the driver to fail to find other tools like cgo.
> >
> > Thus bump the SONAME for GCC 15 as well, as we've done for each
> > release in the past.
> >
> > I think libgo changes go through another "upstream", so Ian, can you
> > please take care of this?
> >
> 
> Thanks, committed.
> 
> I'll try to fix the underlying issue.

Thanks - during a quick inspection we wondered if gccgo could simply
set the GOROOT (or how it was called) environment if not set which would
override the built-in path.

I was also wondering whether/how relocating a GCC install works for
GO with the compiled-in libexecdir.

Richard.

> Ian
> 

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

[Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

[Andre Vehreschild]

Hi all,

attached patch fixes a gimplification error when a pointer remapping on derived
type's components with deferred arrays is made. The issue boiled down to the
dependency analysis being to loose. It saw a dependency as soon as both sides
of the => had a derived type, independent of the actual derived types used. The
patch therefore extends the dependency analysis to compare also the derived
types (symbols).

This fixes the PR, but not really the problem, because when say a
obj(i)%arr(2:5) => obj(i)%arr(1:4) is done we run into the same issue. I don't
have a solution for that error. It might  be needed to prevent generating the
parm.NN variable for the lhs, because that is mostly useless there. (Or I don't
understand (yet) how to use it).

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

Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From ab201d8001cd14bb1c3cf7cd99a34b927af1f32e Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Wed, 5 Mar 2025 15:18:48 +0100
Subject: [PATCH] Fortran: Fix gimplification error for pointer remapping in
 forall [PR107143]

Enhance dependency checking for data pointers to check for same derived
type and not only for a type being a derived type.  This prevent
generation of a descriptor for a function call, that is unsuitable in
forall's pointer assignment.

	PR fortran/107143

gcc/fortran/ChangeLog:

	* dependency.cc (check_data_pointer_types): Do not just compare
	for derived type, but for same derived type.

gcc/testsuite/ChangeLog:

	* gfortran.dg/forall_20.f90: New test.
---
 gcc/fortran/dependency.cc   |  3 +-
 gcc/testsuite/gfortran.dg/forall_20.f90 | 40 +
 2 files changed, 42 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/forall_20.f90

diff --git a/gcc/fortran/dependency.cc b/gcc/fortran/dependency.cc
index 6b3affa6057..38eb114711b 100644
--- a/gcc/fortran/dependency.cc
+++ b/gcc/fortran/dependency.cc
@@ -1250,7 +1250,8 @@ check_data_pointer_types (gfc_expr *expr1, gfc_expr *expr2)
   sym2 = expr2->symtree->n.sym;

   /* Keep it simple for now.  */
-  if (sym1->ts.type == BT_DERIVED && sym2->ts.type == BT_DERIVED)
+  if (sym1->ts.type == BT_DERIVED && sym2->ts.type == BT_DERIVED
+  && sym1->ts.u.derived == sym2->ts.u.derived)
 return false;

   if (sym1->attr.pointer)
diff --git a/gcc/testsuite/gfortran.dg/forall_20.f90 b/gcc/testsuite/gfortran.dg/forall_20.f90
new file mode 100644
index 000..63392bd6aad
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/forall_20.f90
@@ -0,0 +1,40 @@
+!{ dg-do run }
+!
+! Check pointer aliasing is done w/o temp.
+! Contributed by Arseny Solokha  
+
+program pr107143
+  type ta
+ integer, POINTER :: ip(:)
+  end type ta
+
+  type tb
+ integer, POINTER :: ip(:,:)
+  end type tb
+
+  integer, parameter :: cnt = 3
+  type(ta) :: a(cnt)
+  type(tb) :: b(cnt)
+  integer, target :: arr(8) = [1,2,3,4,5,6,7,8]
+
+  do i = 1, cnt
+allocate(a(i)%ip(8), SOURCE=arr * i)
+  end do
+  call s5(b, a, 2, 4)
+
+  do i = 1, cnt
+if (any(a(i)%ip /= arr * i)) stop i
+  end do
+
+contains
+
+subroutine s5(y,z,n1,n2)
+
+  type(tb) :: y(:)
+  type(ta), TARGET :: z(:)
+
+  forall (i=1:cnt)
+y(i)%ip(1:n1,1:n2) => z(i)%ip
+  end forall
+end subroutine s5
+end program
--
2.48.1

[PATCH v2] RISC-V: Adjust LMUL when using maximum SEW [PR117955].

[Robin Dapp]

Hi,

when merging two vsetvls that both only demand "SEW >= ..." we
use their maximum SEW and keep the LMUL.  That may lead to invalid
vector configurations like
 e64, mf4.
As we make sure that the SEW requirements overlap we can use the SEW
and LMUL of the configuration with the larger SEW.

Ma Jin already touched this merge rule some weeks ago and fixed the
ratio calculation (r15-6873).  Calculating the ratio from an invalid
SEW/LMUL combination lead to an overflow in the ratio variable, though.
I'd argue the proper fix is to update SEW and LMUL, keeping the ratio
as before.  This "breaks" bug-10.c but its check only checked for a
workaround anyway so I turned it into a run test.

For V2, Ma Jin helped minify the PR's test and provided a larger test
case for bug-10.

Regtested on rv64gcv_zvl512b.

Regards
Robin

PR target/117955

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc: Use LMUL/ratio from vsetvl with
larger SEW.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/bug-10.c: Convert to run test.
* gcc.target/riscv/rvv/base/bug-10-2.c: New test.
* gcc.target/riscv/rvv/base/pr117955.c: New test.
---
gcc/config/riscv/riscv-vsetvl.cc  |  8 +-
.../gcc.target/riscv/rvv/base/bug-10-2.c  | 92 +++
.../gcc.target/riscv/rvv/base/bug-10.c| 32 ++-
.../gcc.target/riscv/rvv/base/pr117955.c  | 26 ++
4 files changed, 152 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/bug-10-2.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr117955.c

diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index 82284624a24..f0165f7b8c8 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -1729,9 +1729,11 @@ private:
  }
  inline void use_max_sew (vsetvl_info &prev, const vsetvl_info &next)
  {
-int max_sew = MAX (prev.get_sew (), next.get_sew ());
-prev.set_sew (max_sew);
-prev.set_ratio (calculate_ratio (prev.get_sew (), prev.get_vlmul ()));
+bool prev_sew_larger = prev.get_sew () >= next.get_sew ();
+const vsetvl_info from = prev_sew_larger ? prev : next;
+prev.set_sew (from.get_sew ());
+prev.set_vlmul (from.get_vlmul ());
+prev.set_ratio (from.get_ratio ());
use_min_of_max_sew (prev, next);
  }
  inline void use_next_sew_lmul (vsetvl_info &prev, const vsetvl_info &next)
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/bug-10-2.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/bug-10-2.c
new file mode 100644
index 000..a7d3b3ccf66
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/bug-10-2.c
@@ -0,0 +1,92 @@
+/* { dg-do run { target { rv64 } } } */
+/* { dg-require-effective-target rv64 } */
+/* { dg-require-effective-target riscv_v } */
+/* { dg-options " -march=rv64gcv_zvfh -mabi=lp64d -O2" } */
+
+#include 
+
+int8_t a[1];
+uint16_t b[1];
+float c[1], n[1];
+uint16_t d[1];
+uint8_t e[1];
+uint16_t f[1];
+_Float16 g[1], k[1], m[1], p[1];
+uint16_t i[1];
+int8_t j[1];
+uint8_t o[1];
+uint32_t l[1];
+uint16_t q[1];
+uint32_t r[1];
+uint32_t s[1];
+int16_t t[1];
+int main()
+{
+  int u = 25;
+  int8_t *v = a;
+  uint32_t *w;
+  uint16_t *aa = b;
+  float *ab = c, *as = n;
+  uint32_t *ad;
+  uint16_t *ah = f;
+  _Float16 *ai = g, *aj = k, *an = m, *au = p;
+  int32_t *ak;
+  int16_t *al;
+  uint16_t *am = i;
+  int8_t *ao = j;
+  uint8_t *ap = o;
+  uint32_t *aq = l;
+  uint16_t *ar = q;
+  uint32_t *at = r;
+  uint32_t *av = s;
+  int32_t *ax;
+  int16_t *ay = t;
+  for (size_t az; u; u -= az)
+  {
+az = __riscv_vsetvl_e32m8(u);
+vint8m2_t ba = __riscv_vle8_v_i8m2(v, az);
+vbool4_t bb = __riscv_vmseq_vx_i8m2_b4(ba, 1, az);
+vuint16m4_t bc = __riscv_vsll_vx_u16m4(__riscv_vid_v_u16m4(az), 2, az);
+vuint32m8_t bd = __riscv_vsll_vx_u32m8(__riscv_vid_v_u32m8(az), 1, az);
+vuint32m8_t be = __riscv_vluxei16_v_u32m8_m(bb, w, bc, az);
+vuint16m4_t bf;
+__riscv_vsuxei16_v_u32m8_m(bb, aq, bf, be, az);
+vuint8m2_t bg = __riscv_vsll_vx_u8m2(__riscv_vid_v_u8m2(az), 1, az);
+vuint16m4_t bh = __riscv_vloxei8_v_u16m4(aa, bg, az);
+vfloat16m4_t bi;
+vuint16m4_t bj = __riscv_vsll_vx_u16m4(__riscv_vid_v_u16m4(az), 1, az);
+vint16m4_t bk = __riscv_vloxei32_v_i16m4_m(bb, al, bd, az);
+__riscv_vsse16_v_u16m4(ar, 2, bh, az);
+vuint16m4_t bl = __riscv_vloxei16_v_u16m4(d, bj, az);
+vfloat16m4_t bm = __riscv_vle16_v_f16m4(ai, az);
+vuint16m4_t bn = __riscv_vlse16_v_u16m4(ah, 2, az);
+vint32m8_t bo = __riscv_vle32_v_i32m8_m(bb, ak, az);
+vfloat16m1_t bp = __riscv_vle16_v_f16m1(aj, az);
+vuint16m4_t bq = __riscv_vrgatherei16_vv_u16m4(bl, bn, az);
+__riscv_vse16_v_u16m4(am, bq, az);
+vfloat16m1_t br = __riscv_vfredusum_vs_f16m4_f16m1_m(bb, bm, bp, az);
+vuint8m2_t bs;
+vuint32m8_t bt;
+__riscv_vse16_v_f16m1(an, br, az);
+vfloat32m8_t bu = __riscv_vloxei8_v_f32m8(ab, bs, az);
+__riscv_v

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

[Simon Martin]

Hi Jason,

On Wed Mar 5, 2025 at 12:03 AM CET, Jason Merrill wrote:
> On 2/18/25 5:12 AM, Simon Martin wrote:
>> We've been rejecting this valid code since r8-4571:
>> 
>> === cut here ===
>> void foo (float);
>> int main () {
>>constexpr float x = 0;
>>(void) [&] () {
>>  foo (x);
>>  (void) [] () {
>>foo (x);
>>  };
>>};
>> }
>> === cut here ===
>> 
>> The problem is that when processing X in the inner lambda,
>> process_outer_var_ref errors out even though it does find the capture

>> from the enclosing lambda.
>> 
>> This patch changes process_outer_var_ref to accept and return the outer
>> proxy if it finds any.
>> 
>> Successfully tested on x86_64-pc-linux-gnu.
>> 
>>  PR c++/110584
>> 
>> gcc/cp/ChangeLog:
>> 
>>  * semantics.cc (process_outer_var_ref): Use capture from
>>  enclosing lambda, if any.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>>  * g++.dg/cpp0x/lambda/lambda-nested10.C: New test.
>> 
>> ---
>>   gcc/cp/semantics.cc   |  4 ++
>>   .../g++.dg/cpp0x/lambda/lambda-nested10.C | 46 +++
>>   2 files changed, 50 insertions(+)
>>   create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested10.C
>> 
>> diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
>> index 7c7d3e3c432..7bbc82f7dc1 100644
>> --- a/gcc/cp/semantics.cc
>> +++ b/gcc/cp/semantics.cc
>> @@ -4598,6 +4598,10 @@ process_outer_var_ref (tree decl, tsubst_flags_t 
>> complain, bool odr_use)
>> if (!odr_use && context == containing_function)
>>   decl = add_default_capture (lambda_stack,
>>  /*id=*/DECL_NAME (decl), initializer);
>> +  /* When doing lambda capture, if we found a capture in an enclosing 
>> lambda,
>> + we can use it.  */
>> +  else if (!odr_use && is_capture_proxy (decl))
>> +return decl;
>
> What makes this OK is not that it's a capture, but that the captured 
> variable is constant, so it should have satisfied this branch:
>
>>   /* Only an odr-use of an outer automatic variable causes an
>> 
>>  error, and a constant variable can decay to a prvalue   
>> 
>>  constant without odr-use.  So don't complain yet.  */
>>   else if (!odr_use && decl_constant_var_p (decl))
>> return decl;
>
> is_constant_capture_proxy might be useful here.  And/or a new 
> strip_normal_capture function (that I'm surprised doesn't exist yet).
Yeah, that makes a lot of sense, thanks. This is what the attached updated
patch does, successfully tested on x86_64-pc-linux-gnu. OK for trunk?

Simon

From d9e83d2c9dc6fae4a15d47e694fbe689e8a413c1 Mon Sep 17 00:00:00 2001
From: Simon Martin 
Date: Mon, 17 Feb 2025 18:53:22 +0100
Subject: [PATCH] c++: Look through capture proxy from outer lambda instead of
 erroring out [PR110584]

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

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

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

This patch makes sure that process_outer_var_ref properly looks through
normal capture proxies, if any.

Successfully tested on x86_64-pc-linux-gnu.

PR c++/110584

gcc/cp/ChangeLog:

* cp-tree.h (strip_normal_capture_proxy): Declare.
* lambda.cc (strip_normal_capture_proxy): New function to look
through normal capture proxies.
(build_capture_proxy): Use it.
* semantics.cc (process_outer_var_ref): Likewise.

gcc/testsuite/ChangeLog:

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

---
 gcc/cp/cp-tree.h  |  1 +
 gcc/cp/lambda.cc  | 14 +-
 gcc/cp/semantics.cc   |  6 +--
 .../g++.dg/cpp0x/lambda/lambda-nested10.C | 46 +++
 4 files changed, 61 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested10.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 583d0496364..b1f1b21ade2 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -8114,6 +8114,7 @@ extern void insert_capture_proxy  (tree);
 extern void insert_pending_capture_proxies (void);
 extern bool is_capture_proxy   (tree);
 extern bool is_normal_capture_proxy (tree);
+extern tree strip_normal_capture_proxy (tree);
 extern bool is_constant_capture_proxy   (tree);
 extern void register_capture_members   (tree);
 extern tree lambda_expr_this_capture(tree, int);
diff --git a/gcc/cp/lambda.cc b/gcc/cp/lambda.cc
index da075b98805..ed70bb0ba8e 100644
--- a/gcc/cp/lambda.cc
+++ b/gcc/cp/lambda.cc
@@ -295,6 +295,17 @@ is_no

Re: [PATCH 2/2] libstdc++: Some concat_view bugfixes [PR115215, PR115218, LWG 4082]

[Jonathan Wakely]

On Wed, 5 Mar 2025 at 15:37, Patrick Palkawrote:
>
> On Mon, 17 Feb 2025, Patrick Palka wrote:
>
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > -- >8 --
> >
> > - Use __builtin_unreachable to suppress a false-positive "control
> >   reaches end of non-void function" warning in the recursive lambda
> >   (which the existing tests failed to notice since test01 wasn't
> >   being called at runtime)
> > - Relax the constraints on views::concat in the single-argument case
> >   as per PR115215
> > - Add an input_range requirement to that same case as per LWG 4082
> > - In the const-converting constructor of concat_view's iterator,
> >   don't require the first iterator to be default constructible
> >
> >   PR libstdc++/115215
> >   PR libstdc++/115218
> >
> > libstdc++-v3/ChangeLog:
> >
> >   * include/std/ranges
> >   (concat_view::iterator::_S_invoke_with_runtime_index): Use
> >   __builtin_unreachable in recursive lambda to certify it always
> >   exits via 'return'.
> >   (concat_view::iterator::iterator): In the const-converting
> >   constructor, direct initialize _M_it.
> >   (views::_Concat::operator()): Adjust constraints in the
> >   single-argument case as per LWG 4082.
> >   * testsuite/std/ranges/concat/1.cc (test01): Call it at runtime
> >   too.
> >   (test04): New test.
> > ---
> >  libstdc++-v3/include/std/ranges   | 28 +--
> >  libstdc++-v3/testsuite/std/ranges/concat/1.cc | 16 +++
> >  2 files changed, 30 insertions(+), 14 deletions(-)
> >
> > diff --git a/libstdc++-v3/include/std/ranges 
> > b/libstdc++-v3/include/std/ranges
> > index 22e0c9cae44..a56dae43625 100644
> > --- a/libstdc++-v3/include/std/ranges
> > +++ b/libstdc++-v3/include/std/ranges
> > @@ -9919,6 +9919,7 @@ namespace ranges
> >   return __f.template operator()<_Idx>();
> > if constexpr (_Idx + 1 < sizeof...(_Vs))
> >   return __self.template operator()<_Idx + 1>();
> > +   __builtin_unreachable();
> >   }.template operator()<0>();
> >}
> >
> > @@ -9940,12 +9941,12 @@ namespace ranges
> >  constexpr
> >  iterator(iterator __it)
> >requires _Const && (convertible_to, iterator_t > _Vs>> && ...)
> > -: _M_parent(__it._M_parent)
> > -{
> > -  _M_invoke_with_runtime_index([this, &__it]() {
> > - _M_it.template emplace<_Idx>(std::get<_Idx>(std::move(__it._M_it)));
> > -  });
> > -}
> > +: _M_parent(__it._M_parent),
> > +  _M_it(_S_invoke_with_runtime_index([this, &__it]() {
> > +   return __base_iter(in_place_index<_Idx>,
> > +  std::get<_Idx>(std::move(__it._M_it)));
> > + }, __it._M_it.index()))
> > +{ }
> >
> >  constexpr decltype(auto)
> >  operator*() const
> > @@ -10179,16 +10180,15 @@ namespace ranges
> >
> >  struct _Concat
> >  {
> > -  template
> > - requires __detail::__can_concat_view<_Ts...>
> > +  template<__detail::__can_concat_view... _Ts>
>
> As pointed out by Tomasz, this change is incorrect and unnecessary.
> The former checks __can_concat_view<_Ts...> whereas the latter checks
> (__can_concat_view && ...).  Here's v2 with this change reverted:

I was just looking at that exact line and scratching my head.

Patch v2 is OK for trunk, thanks.

>
> -- >8 --
>
> Subject: [PATCH v2] libstdc++: Some concat_view bugfixes [PR115215, PR115218, 
> LWG
>  4082]
>
> - Use __builtin_unreachable to suppress a false-positive "control
>   reaches end of non-void function" warning in the recursive lambda
>   (which the existing tests failed to notice since test01 wasn't
>   being called at runtime)
> - Relax the constraints on views::concat in the single-argument case
>   as per PR115215
> - Add an input_range requirement to that same case as per LWG 4082
> - In the const-converting constructor of concat_view's iterator,
>   don't require the first iterator to be default constructible
>
> PR libstdc++/115215
> PR libstdc++/115218
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges
> (concat_view::iterator::_S_invoke_with_runtime_index): Use
> __builtin_unreachable in recursive lambda to certify it always
> exits via 'return'.
> (concat_view::iterator::iterator): In the const-converting
> constructor, direct initialize _M_it.
> (views::_Concat::operator()): Adjust constraints in the
> single-argument case as per LWG 4082.
> * testsuite/std/ranges/concat/1.cc (test01): Call it at runtime
> too.
> (test04): New test.
> ---
>  libstdc++-v3/include/std/ranges   | 25 ++-
>  libstdc++-v3/testsuite/std/ranges/concat/1.cc | 16 
>  2 files changed, 29 insertions(+), 12 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index 6c65722b687..2228ab8c5ee 100644
> --- a/libstdc++-v3/in

Re: [PATCH] rx: avoid adding setpsw for rx_cmpstrn when len is const

[Jeff Law]

On 2/18/25 11:12 AM, Keith Packard wrote:

We can avoid the setpsw instructions when len is a known constant.
When len is zero, the insn result is zero. When len is non-zero,
the scmpu instructions will set the flags correctly.
Were you able to actually trigger cases where operands[3] is a 
CONST_INT?  Again, it's not entirely clear if that can actually happen 
given the operand predicates on the cmpstrnsi expander.


Jeff

Re: [PATCH] libstdc++: Implement P3138R5 views::cache_latest

[Jonathan Wakely]

On Fri, 14 Feb 2025 at 05:12, Patrick Palka wrote:
>
> On Thu, 13 Feb 2025, Jonathan Wakely wrote:
>
> > On Tue, 11 Feb 2025 at 05:59, Patrick Palka  wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> > >
> > > -- >8 --
> > >
> > > libstdc++-v3/ChangeLog:
> > >
> > > * include/bits/version.def (ranges_cache_latest): Define.
> > > * include/bits/version.h: Regenerate.
> > > * include/std/ranges (cache_latest_view): Define for C++26.
> > > (cache_latest_view::_Iterator): Likewise.
> > > (cache_latest_view::_Sentinel): Likewise.
> > > (views::__detail::__can_cache_latest): Likewise.
> > > (views::_CacheLatest, views::cache_latest): Likewise.
> > > * testsuite/std/ranges/adaptors/cache_latest/1.cc: New test.
> >
> > The test is missing from the patch.
>
> Whoops, below is the complete patch.

OK for trunk, thanks.

>
> >
> > > ---
> > >  libstdc++-v3/include/bits/version.def |   8 ++
> > >  libstdc++-v3/include/bits/version.h   |  10 ++
> > >  libstdc++-v3/include/std/ranges   | 189 ++
> > >  3 files changed, 207 insertions(+)
> > >
> > > diff --git a/libstdc++-v3/include/bits/version.def 
> > > b/libstdc++-v3/include/bits/version.def
> > > index 002e560dc0d..6fb5db2e1fc 100644
> > > --- a/libstdc++-v3/include/bits/version.def
> > > +++ b/libstdc++-v3/include/bits/version.def
> > > @@ -1837,6 +1837,14 @@ ftms = {
> > >};
> > >  };
> > >
> > > +ftms = {
> > > +  name = ranges_cache_latest;
> > > +  values = {
> > > +v = 202411;
> > > +cxxmin = 26;
> > > +  };
> > > +};
> > > +
> > >  ftms = {
> > >name = ranges_concat;
> > >values = {
> > > diff --git a/libstdc++-v3/include/bits/version.h 
> > > b/libstdc++-v3/include/bits/version.h
> > > index 70de189b1e0..db61a396c45 100644
> > > --- a/libstdc++-v3/include/bits/version.h
> > > +++ b/libstdc++-v3/include/bits/version.h
> > > @@ -2035,6 +2035,16 @@
> > >  #endif /* !defined(__cpp_lib_is_virtual_base_of) && 
> > > defined(__glibcxx_want_is_virtual_base_of) */
> > >  #undef __glibcxx_want_is_virtual_base_of
> > >
> > > +#if !defined(__cpp_lib_ranges_cache_latest)
> > > +# if (__cplusplus >  202302L)
> > > +#  define __glibcxx_ranges_cache_latest 202411L
> > > +#  if defined(__glibcxx_want_all) || 
> > > defined(__glibcxx_want_ranges_cache_latest)
> > > +#   define __cpp_lib_ranges_cache_latest 202411L
> > > +#  endif
> > > +# endif
> > > +#endif /* !defined(__cpp_lib_ranges_cache_latest) && 
> > > defined(__glibcxx_want_ranges_cache_latest) */
> > > +#undef __glibcxx_want_ranges_cache_latest
> > > +
> > >  #if !defined(__cpp_lib_ranges_concat)
> > >  # if (__cplusplus >  202302L)
> > >  #  define __glibcxx_ranges_concat 202403L
> > > diff --git a/libstdc++-v3/include/std/ranges 
> > > b/libstdc++-v3/include/std/ranges
> > > index 5c795a90fbc..db9a00be264 100644
> > > --- a/libstdc++-v3/include/std/ranges
> > > +++ b/libstdc++-v3/include/std/ranges
> > > @@ -58,6 +58,7 @@
> > >  #define __glibcxx_want_ranges_as_const
> > >  #define __glibcxx_want_ranges_as_rvalue
> > >  #define __glibcxx_want_ranges_cartesian_product
> > > +#define __glibcxx_want_ranges_cache_latest
> > >  #define __glibcxx_want_ranges_concat
> > >  #define __glibcxx_want_ranges_chunk
> > >  #define __glibcxx_want_ranges_chunk_by
> > > @@ -1534,6 +1535,8 @@ namespace views::__adaptor
> > > this->_M_payload._M_apply(_Optional_func{__f}, __i);
> > > return this->_M_get();
> > >   }
> > > +
> > > +   using _Optional_base<_Tp>::_M_reset;
>
> I also forgot to mention this change in the ChangeLog.
>
> > >};
> > >
> > >  template
> > > @@ -10203,6 +10206,192 @@ namespace ranges
> > >  } // namespace ranges
> > >  #endif // __cpp_lib_ranges_concat
> > >
> > > +#if __cpp_lib_ranges_cache_latest // C++ >= 26
> > > +namespace ranges
> > > +{
> > > +  template
> > > +requires view<_Vp>
> > > +  class cache_latest_view : public view_interface>
> > > +  {
> > > +_Vp _M_base = _Vp();
> > > +
> > > +using __cache_t = 
> > > conditional_t>,
> > > +   add_pointer_t>,
> > > +   range_reference_t<_Vp>>;
> >
> > __conditional_t is cheaper to instantiate than conditional_t, so when
> > it doesn't affect the mangled name of a public symbol we should prefer
> > __conditional_t.
>
> Ack, fixed below.
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/version.def (ranges_cache_latest): Define.
> * include/bits/version.h: Regenerate.
> * include/std/ranges (__detail::__non_propagating_cache::_M_reset):
> Export from base class _Optional_base.
> (cache_latest_view): Define for C++26.
> (cache_latest_view::_Iterator): Likewise.
> (cache_latest_view::_Sentinel): Likewise.
> (views::__detail::__can_cache_latest): Likewise.
> (views::_CacheLatest, views::cache_latest): Likewise.
>

Re: [PATCH] arm: Handle fixed PIC register in require_pic_register (PR target/115485)

[Richard Earnshaw (lists)]

On 04/03/2025 11:01, Christophe Lyon wrote:
> Commit r9-4307-g89d7557202d25a forgot to accept a fixed PIC register
> when extending the assert in require_pic_register.
> 
> arm_pic_register can be set explicitly by the user
> (e.g. -mpic-register=r9) or implicitly as the default value with
> -fpic/-fPIC/-fPIE and -mno-pic-data-is-text-relative -mlong-calls, and
> we want to use/accept it when recording cfun->machine->pic_reg as used
> to be the case.
> 
> Tested on arm-none-linux-gnueabihf and arm-none-eabi with several sets
> of options, covering all M-profile architecture versions.
> 
>   PR target/115485
>   gcc/
>   * config/arm/arm.cc (require_pic_register): Fix typos in
>   comment. Handle fixed arm_pic_register.
> 
>   gcc/testsuite/
>   * g++.target/arm/pr115485.C: New test.

OK, along with any needed backports.

R.

> ---
>  gcc/config/arm/arm.cc   |  5 +++--
>  gcc/testsuite/g++.target/arm/pr115485.C | 16 
>  2 files changed, 19 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/g++.target/arm/pr115485.C
> 
> diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
> index 00499a26bae..670f487bcce 100644
> --- a/gcc/config/arm/arm.cc
> +++ b/gcc/config/arm/arm.cc
> @@ -8086,8 +8086,8 @@ legitimate_pic_operand_p (rtx x)
>  
>  /* Record that the current function needs a PIC register.  If PIC_REG is 
> null,
> a new pseudo is allocated as PIC register, otherwise PIC_REG is used.  In
> -   both case cfun->machine->pic_reg is initialized if we have not already 
> done
> -   so.  COMPUTE_NOW decide whether and where to set the PIC register.  If 
> true,
> +   both cases cfun->machine->pic_reg is initialized if we have not already 
> done
> +   so.  COMPUTE_NOW decides whether and where to set the PIC register.  If 
> true,
> PIC register is reloaded in the current position of the instruction stream
> irregardless of whether it was loaded before.  Otherwise, it is only 
> loaded
> if not already done so (crtl->uses_pic_offset_table is null).  Note that
> @@ -8107,6 +8107,7 @@ require_pic_register (rtx pic_reg, bool compute_now)
>if (!crtl->uses_pic_offset_table || compute_now)
>  {
>gcc_assert (can_create_pseudo_p ()
> +   || (arm_pic_register != INVALID_REGNUM)
> || (pic_reg != NULL_RTX
> && REG_P (pic_reg)
> && GET_MODE (pic_reg) == Pmode));
> diff --git a/gcc/testsuite/g++.target/arm/pr115485.C 
> b/gcc/testsuite/g++.target/arm/pr115485.C
> new file mode 100644
> index 000..491b48c726a
> --- /dev/null
> +++ b/gcc/testsuite/g++.target/arm/pr115485.C
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */
> +/* { dg-options "-fPIE -mno-pic-data-is-text-relative -mlong-calls 
> -ffunction-sections" } */
> +
> +struct c1 {
> +  virtual void func1() = 0;
> +};
> +struct  c2 {
> +  virtual ~c2() {}
> +};
> +struct c3 : c2, c1 {
> +  void func1() override;
> +  void func3();
> +};
> +void c3::func1() {
> +  func3();
> +}

Re: [PATCH v2] c++: ICE with operator new[] in constexpr [PR118775]

[Jason Merrill]

On 3/5/25 4:00 PM, Marek Polacek wrote:

On Wed, Mar 05, 2025 at 03:31:59PM -0500, Jason Merrill wrote:

On 3/5/25 12:09 PM, Marek Polacek wrote:

On Tue, Mar 04, 2025 at 05:34:10PM -0500, Jason Merrill wrote:

On 2/11/25 6:24 PM, Marek Polacek wrote:

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

-- >8 --
Here we ICE since r11-7740 because we no longer say that (long)&a
(where a is a global var) is non_constant_p.  So VERIFY_CONSTANT
does not return and we crash on tree_to_uhwi.  We should check
tree_fits_uhwi_p before calling tree_to_uhwi.

PR c++/118775

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_call_expression): Check tree_fits_uhwi_p.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/constexpr-new24.C: New test.
* g++.dg/cpp2a/constexpr-new25.C: New test.
---
gcc/cp/constexpr.cc  |  7 +
gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C | 25 ++
gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C | 27 
3 files changed, 59 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C
create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index f142dd32bc8..f8f9a9df1a2 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -2909,6 +2909,13 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree 
t,
  gcc_assert (arg0);
  if (new_op_p)
{
+ if (!tree_fits_uhwi_p (arg0))
+   {
+ if (!ctx->quiet)
+   error_at (loc, "cannot allocate array: size too large");


"too large" seems misleading in this case, where it just isn't a
compile-time constant.


Fair, how about "size not constant"?

Why didn't the VERIFY_CONSTANT just above already reject this?


This is about *non_constant_p.  Since r11-7740 cxx_eval_constant_expression
returns early less often:

@@ -6656,7 +6656,8 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,

  if (TREE_CODE (t) == CONVERT_EXPR
  && ARITHMETIC_TYPE_P (type)
-   && INDIRECT_TYPE_P (TREE_TYPE (op)))
+   && INDIRECT_TYPE_P (TREE_TYPE (op))
+   && ctx->manifestly_const_eval)


Aha.  I think this should check ctx->strict instead of
ctx->manifestly_const_eval.


In the r11-7740 patch Jakub mentioned he had tried that, but it regressed
some tests.  I've tried to see if that is still the case and it is; at
least
g++.dg/cpp1y/constexpr-shift1.C
g++.dg/cpp1y/constexpr-82304.C
g++.dg/cpp0x/constexpr-ex1.C
FAIL with ctx->strict.


This seems to be because maybe_constant_init_1 wrongly chooses 
non-strict mode for static constexpr variables.  After correcting that, 
only constexpr-new3.C fails, which seems to be a latent bug that we can 
otherwise see by moving v7 into a function.



Also, while using ctx->strict fixes constexpr-new25.C, it doesn't fix
the constexpr-new24.C crash.


Why?

Jason

Re: [PATCH htdocs] bugs: Link to all 'Porting to' docs in 'Common problems when upgrading ...'

[Sam James]

Gerald Pfeifer  writes:

> On Wed, 12 Feb 2025, Sam James wrote:
>> Suggested by Andrew Pinski. I think it makes sense to have it in here 
>> even if perhaps a bit verbose, because we really try to tell bug 
>> reporters to read the page properly.
>
> Makes sense.
>
>> This could also be a table.
>
> I'm not sure how a table would look like? (Genuinely, if you feel it'd be 
> better happy to have a look.)

I wasn't sure if maybe a "long bulletpoint list" was an antipattern, and
then wondered about maybe "version/changes/porting to" as columns, but
on reflection, it's overkill and let's not worry about it.

>
>> +GCC maintains a 'Porting to' resource for new versions of the compiler:
>
> How about skipping "of the compiler" (not the least since it's a set of 
> compilers ;-) and then something like
>
>   "...new version: GCC 15 | GCC 14 | GCC 13 | ..."
>
> (or with commas or something along these lines)?

ACK.

>
>> +  https://gcc.gnu.org/gcc-15/porting_to.html";>GCC 15
>
> Can you please make all these links relative, such as 
> ../gcc-15/porting_to.html ?


ACK.

>
> Fine with these changes. 
>
> Can you please also enhance the documentation for our release managers?
> Probably branching.html (over releasing HTML since some distros give new 
> GCC versions a spin before the first release in the series).

Will do -- thank you for the helpful comments and the quick review!

>
> Thank you,
> Gerald

thanks,
sam

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

[Harald Anlauf]

Hi Andre,

Jerry already OK'ed your patch, but:

Am 05.03.25 um 15:34 schrieb Andre Vehreschild:

This fixes the PR, but not really the problem, because when say a
obj(i)%arr(2:5) => obj(i)%arr(1:4) is done we run into the same issue. I don't
have a solution for that error. It might  be needed to prevent generating the
parm.NN variable for the lhs, because that is mostly useless there. (Or I don't
understand (yet) how to use it).


can you explain where you do see an issue here?

A pointer assignment in the way you describe seems perfectly legal
Fortran and works here.

If we are missing anything, would you please open a PR with more
details?

Thanks,
Harald

Re: [PATCH v2] c++: Don't replace INDIRECT_REFs by a const capture proxy too eagerly [PR117504]

[Jason Merrill]

On 3/5/25 6:58 AM, Simon Martin wrote:

Hi Jason,

On Tue Mar 4, 2025 at 11:47 PM CET, Jason Merrill wrote:

On 2/14/25 12:08 PM, Simon Martin wrote:

We have been miscompiling the following valid code since GCC8, and
r8-3497-g281e6c1d8f1b4c

=== cut here ===
struct span {
span (const int (&__first)[1]) : _M_ptr (__first) {}
int operator[] (long __i) { return _M_ptr[__i]; }
const int *_M_ptr;
};
void foo () {
constexpr int a_vec[]{1};
auto vec{[&a_vec]() -> span { return a_vec; }()};
}
=== cut here ===

The problem is that perform_implicit_conversion_flags (via
mark_rvalue_use) replaces "a_vec" in the return statement by a
CONSTRUCTOR representing a_vec's constant value, and then takes its
address when invoking span's constructor. So we end up with an instance
that points to garbage instead of a_vec's storage.

I've tried many things to somehow recover from this replacement, but I
actually think we should not do it when converting to a class type: we
have no idea whether the conversion will involve a constructor taking an
address or reference. So we should assume it's the case, and call
mark_lvalue_use, not mark_rvalue_use (I might very weel be overseeing
things, and feedback is more than welcome).


Yeah, those mark_*_use calls seem misplaced, they should be called
instead by the code that actually does the conversion.

What if we replace all of them here with just mark_exp_read?  Or nothing?

Thanks for the suggestions; simply removing those calls actually works. This
is what the attached updated patch does.

Successfully tested on x86_64-pc-linux-gnu. OK for trunk? And if so, OK for
branches after 2-3 weeks since it's a wrong code bug?


OK, yes.

Jason

Re: [PATCH v2] c++: disable -Wnonnull in unevaluated context [PR115580]

[Jason Merrill]

On 3/5/25 10:50 AM, Marek Polacek wrote:

On Tue, Mar 04, 2025 at 04:41:05PM -0500, Jason Merrill wrote:

On 3/4/25 3:26 PM, Marek Polacek wrote:

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

-- >8 --
This PR complains that we issue a -Wnonnull even in a decltype.
Since we can't use cp_unevaluated_operand in c-common.cc, this


Would it make sense to check c_inhibit_evaluation_warnings instead?


Yes, I think that would be better, thanks.

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


OK by me.


-- >8 --
This PR complains that we issue a -Wnonnull even in a decltype.
This fix disables even -Wformat and -Wrestrict.  I think that's fine.

PR c++/115580

gcc/c-family/ChangeLog:

* c-common.cc (check_function_arguments): Return early if
c_inhibit_evaluation_warnings.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wnonnull16.C: New test.
---
  gcc/c-family/c-common.cc   |  3 +++
  gcc/testsuite/g++.dg/warn/Wnonnull16.C | 16 
  2 files changed, 19 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wnonnull16.C

diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 49508fe9ee6..587d76461e9 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -6261,6 +6261,9 @@ check_function_arguments (location_t loc, const_tree 
fndecl, const_tree fntype,
  {
bool warned_p = false;
  
+  if (c_inhibit_evaluation_warnings)

+return warned_p;
+
/* Check for null being passed in a pointer argument that must be
   non-null.  In C++, this includes the this pointer.  We also need
   to do this if format checking is enabled.  */
diff --git a/gcc/testsuite/g++.dg/warn/Wnonnull16.C 
b/gcc/testsuite/g++.dg/warn/Wnonnull16.C
new file mode 100644
index 000..8740f351ac7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wnonnull16.C
@@ -0,0 +1,16 @@
+// PR c++/115580
+// { dg-do compile { target c++11 } }
+
+class WithMember {
+public:
+  int foo();
+};
+
+decltype(((WithMember*)nullptr)->foo()) footype; // { dg-bogus "pointer is 
null" }
+
+int f(void*) __attribute__((nonnull));
+
+void g()
+{
+  [[maybe_unused]] decltype(f(nullptr)) b; // { dg-bogus "non-null" }
+}

base-commit: ff505948631713d8c62523005059b10e25343617

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

[Jason Merrill]

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

Hi Jason,

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

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

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

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

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



from the enclosing lambda.

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

Successfully tested on x86_64-pc-linux-gnu.

PR c++/110584

gcc/cp/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

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

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


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


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


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

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



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


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

Jason

Re: [PATCH v2] c++: ICE with operator new[] in constexpr [PR118775]

[Jason Merrill]

On 3/5/25 12:09 PM, Marek Polacek wrote:

On Tue, Mar 04, 2025 at 05:34:10PM -0500, Jason Merrill wrote:

On 2/11/25 6:24 PM, Marek Polacek wrote:

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

-- >8 --
Here we ICE since r11-7740 because we no longer say that (long)&a
(where a is a global var) is non_constant_p.  So VERIFY_CONSTANT
does not return and we crash on tree_to_uhwi.  We should check
tree_fits_uhwi_p before calling tree_to_uhwi.

PR c++/118775

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_call_expression): Check tree_fits_uhwi_p.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/constexpr-new24.C: New test.
* g++.dg/cpp2a/constexpr-new25.C: New test.
---
   gcc/cp/constexpr.cc  |  7 +
   gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C | 25 ++
   gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C | 27 
   3 files changed, 59 insertions(+)
   create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C
   create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index f142dd32bc8..f8f9a9df1a2 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -2909,6 +2909,13 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree 
t,
  gcc_assert (arg0);
  if (new_op_p)
{
+ if (!tree_fits_uhwi_p (arg0))
+   {
+ if (!ctx->quiet)
+   error_at (loc, "cannot allocate array: size too large");


"too large" seems misleading in this case, where it just isn't a
compile-time constant.


Fair, how about "size not constant"?
  

Why didn't the VERIFY_CONSTANT just above already reject this?


This is about *non_constant_p.  Since r11-7740 cxx_eval_constant_expression
returns early less often:

@@ -6656,7 +6656,8 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,

 if (TREE_CODE (t) == CONVERT_EXPR
 && ARITHMETIC_TYPE_P (type)
-   && INDIRECT_TYPE_P (TREE_TYPE (op)))
+   && INDIRECT_TYPE_P (TREE_TYPE (op))
+   && ctx->manifestly_const_eval)


Aha.  I think this should check ctx->strict instead of
ctx->manifestly_const_eval.

Jason

Re: [PATCH] libstdc++: Fix subrange conversion to pair-like [PR119121]

[Jonathan Wakely]

On Wed, 5 Mar 2025 at 11:06, Tomasz Kamiński wrote:
>
> Fix regression introduced by r14-8710-g65b4cba9d6a9ff
>
> PR libstdc++/119121
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_util.h (__detail::__pair_like_convertible_from):
> Use `_Tp` in `is_reference_v` check
> * testsuite/std/ranges/subrange/tuple_like.cc: New tests for
> pair-like conversion
> ---
> Testing x86_64. OK for master and 14?

OK for both if testing passes.

Thanks, and congrats on your first libstdc++ contribution!

If you want to you can add:
Reviewed-by: Jonathan Wakely 
to the end of the git commit message (using git commit --amend) to
record who reviewed and/or approved it. There's no GCC policy about
doing this, it's entirely optional.


>
>  libstdc++-v3/include/bits/ranges_util.h   |  2 +-
>  .../std/ranges/subrange/tuple_like.cc | 29 +++
>  2 files changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/include/bits/ranges_util.h 
> b/libstdc++-v3/include/bits/ranges_util.h
> index 2f56b727e55..51024ecbebe 100644
> --- a/libstdc++-v3/include/bits/ranges_util.h
> +++ b/libstdc++-v3/include/bits/ranges_util.h
> @@ -244,7 +244,7 @@ namespace ranges
>
>  template
>concept __pair_like_convertible_from
> -   = !range<_Tp> && !is_reference_v<_Vp> && __pair_like<_Tp>
> +   = !range<_Tp> && !is_reference_v<_Tp> && __pair_like<_Tp>
> && constructible_from<_Tp, _Up, _Vp>
> && __convertible_to_non_slicing<_Up, tuple_element_t<0, _Tp>>
> && convertible_to<_Vp, tuple_element_t<1, _Tp>>;
> diff --git a/libstdc++-v3/testsuite/std/ranges/subrange/tuple_like.cc 
> b/libstdc++-v3/testsuite/std/ranges/subrange/tuple_like.cc
> index 6d05eb3ef7d..80fe618642a 100644
> --- a/libstdc++-v3/testsuite/std/ranges/subrange/tuple_like.cc
> +++ b/libstdc++-v3/testsuite/std/ranges/subrange/tuple_like.cc
> @@ -18,6 +18,8 @@
>  // { dg-do compile { target c++20 } }
>
>  #include 
> +#include 
> +#include 
>
>  using S1 = std::ranges::subrange;
>  using S2 = std::ranges::subrange;
> @@ -49,3 +51,30 @@ static_assert( std::same_as(s2)), 
> void*> );
>  const S2 c2;
>  static_assert( std::same_as(c2)), long*> );
>  static_assert( std::same_as(c2)), void*> );
> +
> +std::pair p1 = s1;
> +std::pair p2 = s2;
> +std::tuple t1 = s1;
> +std::tuple t2 = s2;
> +
> +std::pair const& p3 = s1;
> +std::tuple&& t3 = s1;
> +
> +std::pair p4 = s1;
> +std::tuple t4 = s1;
> +
> +static_assert( !std::convertible_to, 
> std::pair> );
> +static_assert( !std::convertible_to, 
> std::tuple> );
> +
> +static_assert( !std::convertible_to, 
> std::pair> );
> +static_assert( !std::convertible_to, 
> std::tuple> );
> +
> +struct B {};
> +struct D : B {};
> +
> +std::ranges::subrange sd;
> +std::pair p5 = sd;
> +std::tuple t5 = sd;
> +
> +static_assert( !std::convertible_to, std::pair B*>> );
> +static_assert( !std::convertible_to, 
> std::tuple> );
> --
> 2.48.1
>

Re: [PATCH v2] c++: ICE with operator new[] in constexpr [PR118775]

[Marek Polacek]

On Wed, Mar 05, 2025 at 03:31:59PM -0500, Jason Merrill wrote:
> On 3/5/25 12:09 PM, Marek Polacek wrote:
> > On Tue, Mar 04, 2025 at 05:34:10PM -0500, Jason Merrill wrote:
> > > On 2/11/25 6:24 PM, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > > 
> > > > -- >8 --
> > > > Here we ICE since r11-7740 because we no longer say that (long)&a
> > > > (where a is a global var) is non_constant_p.  So VERIFY_CONSTANT
> > > > does not return and we crash on tree_to_uhwi.  We should check
> > > > tree_fits_uhwi_p before calling tree_to_uhwi.
> > > > 
> > > > PR c++/118775
> > > > 
> > > > gcc/cp/ChangeLog:
> > > > 
> > > > * constexpr.cc (cxx_eval_call_expression): Check 
> > > > tree_fits_uhwi_p.
> > > > 
> > > > gcc/testsuite/ChangeLog:
> > > > 
> > > > * g++.dg/cpp2a/constexpr-new24.C: New test.
> > > > * g++.dg/cpp2a/constexpr-new25.C: New test.
> > > > ---
> > > >gcc/cp/constexpr.cc  |  7 +
> > > >gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C | 25 ++
> > > >gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C | 27 
> > > > 
> > > >3 files changed, 59 insertions(+)
> > > >create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C
> > > >create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C
> > > > 
> > > > diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
> > > > index f142dd32bc8..f8f9a9df1a2 100644
> > > > --- a/gcc/cp/constexpr.cc
> > > > +++ b/gcc/cp/constexpr.cc
> > > > @@ -2909,6 +2909,13 @@ cxx_eval_call_expression (const constexpr_ctx 
> > > > *ctx, tree t,
> > > >   gcc_assert (arg0);
> > > >   if (new_op_p)
> > > > {
> > > > + if (!tree_fits_uhwi_p (arg0))
> > > > +   {
> > > > + if (!ctx->quiet)
> > > > +   error_at (loc, "cannot allocate array: size too 
> > > > large");
> > > 
> > > "too large" seems misleading in this case, where it just isn't a
> > > compile-time constant.
> > 
> > Fair, how about "size not constant"?
> > > Why didn't the VERIFY_CONSTANT just above already reject this?
> > 
> > This is about *non_constant_p.  Since r11-7740 cxx_eval_constant_expression
> > returns early less often:
> > 
> > @@ -6656,7 +6656,8 @@ cxx_eval_constant_expression (const constexpr_ctx 
> > *ctx, tree t,
> > 
> >  if (TREE_CODE (t) == CONVERT_EXPR
> >  && ARITHMETIC_TYPE_P (type)
> > -   && INDIRECT_TYPE_P (TREE_TYPE (op)))
> > +   && INDIRECT_TYPE_P (TREE_TYPE (op))
> > +   && ctx->manifestly_const_eval)
> 
> Aha.  I think this should check ctx->strict instead of
> ctx->manifestly_const_eval.

In the r11-7740 patch Jakub mentioned he had tried that, but it regressed
some tests.  I've tried to see if that is still the case and it is; at
least
g++.dg/cpp1y/constexpr-shift1.C
g++.dg/cpp1y/constexpr-82304.C
g++.dg/cpp0x/constexpr-ex1.C
FAIL with ctx->strict.

Also, while using ctx->strict fixes constexpr-new25.C, it doesn't fix
the constexpr-new24.C crash.

Marek

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

[Jason Merrill]

On 3/5/25 10:13 AM, Patrick Palka wrote:

On Tue, 4 Mar 2025, Jason Merrill wrote:


On 3/4/25 2:49 PM, Patrick Palka wrote:

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

-- >8 --

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

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


That soungs good, but getting it by passing it back from
get_normalized_constraints_from_decl seems confusing; I'd think we should
calculate it in parallel to changing args to correspond to that template.


Hmm, won't that mean duplicating the template adjustment logic in
get_normalized_constraints_from_decl, which seems undesirable?  The
function has many callers, some of which are for satisfaction where
targs are involved, and the rest are for subsumption where no targs are
involved, so I don't see a clean way of refactoring the code to avoid
duplication of the template adjustment logic.  Right now the targ
adjustment logic is unfortunately duplicated across both overloads
of satisfy_declaration_constraints and it seems undesirable to add
more duplication.


Fair enough.  Incidentally, I wonder why the two-parm overload doesn't 
call the three-parm overload?



Maybe one way to reduce the duplication would be to go the other way and
move the targ adjustment logic to get_normalized_constraints_from_decl
as well (so that it has two out-parameters, 'gen_d' and 'gen_args').
The proposed patch then would be an incremental step towards that.


That makes sense, passing back something suitable for 
add_outermost_template_args.



PR c++/99214

gcc/cp/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index a9caba8e2cc..f688a99c5fd 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -648,10 +648,13 @@ get_normalized_constraints_from_info (tree ci, tree
in_decl, bool diag = false)
 return t;
   }
   -/* Returns the normalized constraints for the declaration D.  */
+/* Returns the normalized constraints for the declaration D.
+   If GEN_D is non-NULL, sets *GEN_D to the most general version
+   of D that ultimately owns its constraints.  */
 static tree
-get_normalized_constraints_from_decl (tree d, bool diag = false)
+get_normalized_constraints_from_decl (tree d, bool diag = false,
+ tree *gen_d = nullptr)
   {
 tree tmpl;
 tree decl;
@@ -716,6 +719,8 @@ get_normalized_constraints_from_decl (tree d, bool diag
= false)
   tmpl = most_general_template (tmpl);
   d = tmpl ? tmpl : decl;
+  if (gen_d)
+*gen_d = d;
   /* If we're not diagnosing errors, use cached constraints, if any.  */
 if (!diag)
@@ -2730,9 +2735,11 @@ satisfy_declaration_constraints (tree t, tree args,
sat_info info)
   return boolean_true_node;
   tree result = boolean_true_node;
-  if (tree norm = get_normalized_constraints_from_decl (t, info.noisy ()))
+  tree gen_t;
+  if (tree norm = get_normalized_constraints_from_decl (t, info.noisy (),
+   &gen_t))
   {
-  if (!push_tinst_level (t, args))
+  if (!push_tinst_level (gen_t, args))
return result;
 tree pattern = DECL_TEMPLATE_RESULT (t);
 push_to_top_level ();
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic20.C
b/gcc/testsuite/g++.dg/concepts/diagnostic20.C
new file mode 100644
index 000..b8d586e9a21
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic20.C
@@ -0,0 +1,15 @@
+// PR c++/99214
+// { dg-do compile { target c++20 } }
+
+template 
+struct A {
+  template  static void f() requires ([] { return U::fail; }());
// { dg-error "fail" }
+  template  static void f();
+};
+
+in

[COMMITTED] Regenerate fortran/lang.opt.urls

[Mark Wielaard]

fortran added a new -Wexternal-argument-mismatch option, but the
lang.opt.urls file wasn't regenerated.

Fixes: 21ca9153ebe5 ("C prototypes for external arguments; add warning for 
mismatch.")

gcc/fortran/ChangeLog:

* lang.opt.urls: Regenerated.
---
 gcc/fortran/lang.opt.urls | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/fortran/lang.opt.urls b/gcc/fortran/lang.opt.urls
index 00991602eea6..4972ff8b7b9b 100644
--- a/gcc/fortran/lang.opt.urls
+++ b/gcc/fortran/lang.opt.urls
@@ -97,6 +97,9 @@ 
LangUrlSuffix_Fortran(gfortran/Error-and-Warning-Options.html#index-Wconversion-
 Wdo-subscript
 
LangUrlSuffix_Fortran(gfortran/Error-and-Warning-Options.html#index-Wdo-subscript)
 
+Wexternal-argument-mismatch
+LangUrlSuffix_Fortran(gfortran/Error-and-Warning-Options.html#index-Wexternal-argument-mismatch)
+
 Wextra
 UrlSuffix(gcc/Warning-Options.html#index-Wextra) 
LangUrlSuffix_D(gdc/Warnings.html#index-Wextra) 
LangUrlSuffix_Fortran(gfortran/Error-and-Warning-Options.html#index-Wextra)
 
-- 
2.48.1

Re: [PATCH] c++: Apply/diagnose attributes when instatiating ARRAY/POINTER/REFERENCE_TYPE [PR118787]

[Mark Wielaard]

Hi Jakub,

On Tue, Feb 11, 2025 at 07:04:31PM +0100, Jakub Jelinek wrote:
> The following testcase IMO in violation of the P2552R3 paper doesn't
> pedwarn on alignas applying to dependent types or alignas with dependent
> argument.
> 
> tsubst was just ignoring TYPE_ATTRIBUTES.
> 
> The following patch fixes it for the POINTER/REFERENCE_TYPE and
> ARRAY_TYPE cases, but perhaps we need to do the same also for other
> types (INTEGER_TYPE/REAL_TYPE and the like).  I guess I'll need to
> construct more testcases.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2025-02-11  Jakub Jelinek  
> 
>   PR c++/118787
>   * pt.cc (tsubst) : Use return t; only if it doesn't
>   have any TYPE_ATTRIBUTES.  Call apply_late_template_attributes.
>   : Likewise.  Formatting fix.
> 
>   * g++.dg/cpp0x/alignas22.C: New test.

This seems to have broken the gcc-fedora-mingw build:
https://builder.sourceware.org/buildbot/#/builders/262/builds/11014

In file included from 
/home/builder/shared/bb2-1/worker/gcc-fedora-mingw/gcc-build/x86_64-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:4230,
 from 
/home/builder/shared/bb2-1/worker/gcc-fedora-mingw/gcc-build/x86_64-w64-mingw32/libstdc++-v3/include/string:56,
 from 
/home/builder/shared/bb2-1/worker/gcc-fedora-mingw/gcc-build/x86_64-w64-mingw32/libstdc++-v3/include/bits/locale_classes.h:42,
 from 
/home/builder/shared/bb2-1/worker/gcc-fedora-mingw/gcc-build/x86_64-w64-mingw32/libstdc++-v3/include/codecvt:42,
 from ../../../../../gcc/libstdc++-v3/src/c++11/codecvt.cc:25:
/home/builder/shared/bb2-1/worker/gcc-fedora-mingw/gcc-build/x86_64-w64-mingw32/libstdc++-v3/include/ext/string_conversions.h:
 In substitution of 'template _String 
__gnu_cxx::__to_xstring(int (*)(_CharT*, std::size_t, const _CharT*, char*), 
std::size_t, const _CharT*, ...) [with _String = 
std::__cxx11::basic_string; _CharT = char]':
/home/builder/shared/bb2-1/worker/gcc-fedora-mingw/gcc-build/x86_64-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:4483:43:
   required from here
 4483 | return __gnu_cxx::__to_xstring(&std::vsnprintf, __n,
  |~~~^~
 4484 |"%f", __val);
  |
/home/builder/shared/bb2-1/worker/gcc-fedora-mingw/gcc-build/x86_64-w64-mingw32/libstdc++-v3/include/ext/string_conversions.h:103:5:
 internal compiler error: in apply_late_template_attributes, at cp/pt.cc:12403
  103 | __to_xstring(int (*__convf) (_CharT*, std::size_t, const _CharT*,
  | ^~~~
0x2529c91 internal_error(char const*, ...)
  ../../gcc/gcc/diagnostic-global-context.cc:517
0x715e09 fancy_abort(char const*, int, char const*)
 ../../gcc/gcc/diagnostic.cc:1722
0x4a4034 apply_late_template_attributes
 ../../gcc/gcc/cp/pt.cc:12403
0x95be8d tsubst(tree_node*, tree_node*, int, tree_node*)
 ../../gcc/gcc/cp/pt.cc:16951
0x9741c4 tsubst_arg_types
 ../../gcc/gcc/cp/pt.cc:16022
0x9740e9 tsubst_arg_types
 ../../gcc/gcc/cp/pt.cc:15999
0x9740e9 tsubst_arg_types
 ../../gcc/gcc/cp/pt.cc:16058
0x9740e9 tsubst_arg_types
 ../../gcc/gcc/cp/pt.cc:15999
0x9740e9 tsubst_arg_types
 ../../gcc/gcc/cp/pt.cc:16058
0x9740e9 tsubst_arg_types
 ../../gcc/gcc/cp/pt.cc:15999
0x9740e9 tsubst_arg_types
 ../../gcc/gcc/cp/pt.cc:16058
0x974561 tsubst_arg_types
 ../../gcc/gcc/cp/pt.cc:15999
0x974561 tsubst_function_type
 ../../gcc/gcc/cp/pt.cc:16176
0x95bd6a tsubst(tree_node*, tree_node*, int, tree_node*)
 ../../gcc/gcc/cp/pt.cc:17009
0x95afd7 tsubst(tree_node*, tree_node*, int, tree_node*)
 ../../gcc/gcc/cp/pt.cc:16521
0x9741c4 tsubst_arg_types
 ../../gcc/gcc/cp/pt.cc:16022
0x974561 tsubst_arg_types
 ../../gcc/gcc/cp/pt.cc:15999
0x974561 tsubst_function_type
 ../../gcc/gcc/cp/pt.cc:16176
0x95bd6a tsubst(tree_node*, tree_node*, int, tree_node*)
 ../../gcc/gcc/cp/pt.cc:17009
0x96a866 tsubst_function_decl
 ../../gcc/gcc/cp/pt.cc:14834
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
make[5]: *** [Makefile:883: codecvt.lo] Error 1

> --- gcc/cp/pt.cc.jj   2025-02-07 17:03:13.560227281 +0100
> +++ gcc/cp/pt.cc  2025-02-10 17:17:47.65131 +0100
> @@ -16854,7 +16854,9 @@ tsubst (tree t, tree args, tsubst_flags_
>  case POINTER_TYPE:
>  case REFERENCE_TYPE:
>{
> - if (type == TREE_TYPE (t) && TREE_CODE (type) != METHOD_TYPE)
> + if (type == TREE_TYPE (t)
> + && TREE_CODE (type) != METHOD_TYPE
> + && TYPE_ATTRIBUTES (t) == NULL_TREE)
> return t;
>  
>   /* [temp.deduct]
> @@ -16924,9 +16926,9 @@ tsubst (tree t, tree a

[committed] libstdc++: Move new functions to separate files [PR119110]

[Jonathan Wakely]

The new test functions I added in r15-7765-g3866ca796d5281 are causing
those tests to FAIL on Solaris and arm-thumb due to the linker
complaining about undefined functions.  The new test functions are not
called, so it shouldn't matter that they call undefined member
functions, but it does.

Move those functions to separate { dg-do compile } files so the linker
isn't used and won't complain.

libstdc++-v3/ChangeLog:

PR libstdc++/119110
* testsuite/25_algorithms/move/constrained.cc: Move test06
function to ...
* testsuite/25_algorithms/move/105609.cc: New test.
* testsuite/25_algorithms/move_backward/constrained.cc: Move
test04 function to ...
* testsuite/25_algorithms/move_backward/105609.cc: New test.
---

Tested x86_64-linux. Pushed to trunk.

 .../testsuite/25_algorithms/move/105609.cc| 33 +++
 .../25_algorithms/move/constrained.cc | 29 
 .../25_algorithms/move_backward/105609.cc | 33 +++
 .../move_backward/constrained.cc  | 29 
 4 files changed, 66 insertions(+), 58 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/25_algorithms/move/105609.cc
 create mode 100644 libstdc++-v3/testsuite/25_algorithms/move_backward/105609.cc

diff --git a/libstdc++-v3/testsuite/25_algorithms/move/105609.cc 
b/libstdc++-v3/testsuite/25_algorithms/move/105609.cc
new file mode 100644
index 000..810451987c9
--- /dev/null
+++ b/libstdc++-v3/testsuite/25_algorithms/move/105609.cc
@@ -0,0 +1,33 @@
+// { dg-do compile { target c++20 } }
+
+// PR libstdc++/105609
+// ranges::move should use ranges::iter_move instead of std::move
+
+#include 
+
+namespace pr105609
+{
+  struct I {
+using value_type = int;
+using difference_type = std::ptrdiff_t;
+int operator*() const;
+I& operator++();
+I operator++(int);
+I& operator--();
+I operator--(int);
+bool operator==(I) const;
+friend int& iter_move(const I&);
+  };
+}
+
+void
+test(pr105609::I i)
+{
+  struct O {
+O(int&) { }
+O(int&&) = delete;
+  };
+
+  O* o = nullptr;
+  std::ranges::move(i, i, o);
+}
diff --git a/libstdc++-v3/testsuite/25_algorithms/move/constrained.cc 
b/libstdc++-v3/testsuite/25_algorithms/move/constrained.cc
index e2b45b070ef..587b2f3728b 100644
--- a/libstdc++-v3/testsuite/25_algorithms/move/constrained.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/move/constrained.cc
@@ -204,35 +204,6 @@ test05()
   VERIFY( ranges::equal(v, (int[]){1,2,3,0}) );
 }
 
-namespace pr105609
-{
-  struct I {
-using value_type = int;
-using difference_type = std::ptrdiff_t;
-int operator*() const;
-I& operator++();
-I operator++(int);
-I& operator--();
-I operator--(int);
-bool operator==(I) const;
-friend int& iter_move(const I&);
-  };
-}
-
-void
-test06(pr105609::I i)
-{
-  // PR libstdc++/105609
-  // ranges::move should use ranges::iter_move instead of std::move
-  struct O {
-O(int&) { }
-O(int&&) = delete;
-  };
-
-  O* o = nullptr;
-  std::ranges::move(i, i, o);
-}
-
 int
 main()
 {
diff --git a/libstdc++-v3/testsuite/25_algorithms/move_backward/105609.cc 
b/libstdc++-v3/testsuite/25_algorithms/move_backward/105609.cc
new file mode 100644
index 000..a4fb8d846bd
--- /dev/null
+++ b/libstdc++-v3/testsuite/25_algorithms/move_backward/105609.cc
@@ -0,0 +1,33 @@
+// { dg-do compile { target c++20 } }
+
+// PR libstdc++/105609
+// ranges::move should use ranges::iter_move instead of std::move
+
+#include 
+
+namespace pr105609
+{
+  struct I {
+using value_type = int;
+using difference_type = std::ptrdiff_t;
+int operator*() const;
+I& operator++();
+I operator++(int);
+I& operator--();
+I operator--(int);
+bool operator==(I) const;
+friend int& iter_move(const I&);
+  };
+}
+
+void
+test(pr105609::I i)
+{
+  struct O {
+O(int&) { }
+O(int&&) = delete;
+  };
+
+  O* o = nullptr;
+  std::ranges::move_backward(i, i, o);
+}
diff --git a/libstdc++-v3/testsuite/25_algorithms/move_backward/constrained.cc 
b/libstdc++-v3/testsuite/25_algorithms/move_backward/constrained.cc
index 4d94d386dd0..8f6fd455b4b 100644
--- a/libstdc++-v3/testsuite/25_algorithms/move_backward/constrained.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/move_backward/constrained.cc
@@ -160,35 +160,6 @@ test03()
   return ok;
 }
 
-namespace pr105609
-{
-  struct I {
-using value_type = int;
-using difference_type = std::ptrdiff_t;
-int operator*() const;
-I& operator++();
-I operator++(int);
-I& operator--();
-I operator--(int);
-bool operator==(I) const;
-friend int& iter_move(const I&);
-  };
-}
-
-void
-test04(pr105609::I i)
-{
-  // PR libstdc++/105609
-  // ranges::move should use ranges::iter_move instead of std::move
-  struct O {
-O(int&) { }
-O(int&&) = delete;
-  };
-
-  O* o = nullptr;
-  std::ranges::move_backward(i, i, o);
-}
-
 int
 main()
 {
-- 
2.48.1

[committed] libstdc++: Make enumerate_view::iterator::operator- noexcept

[Jonathan Wakely]

Implement LWG 3912, approved in Varna, June 2023.

libstdc++-v3/ChangeLog:

* include/std/ranges (enumerate_view::_Iterator::operator-):
Add noexcept, as per LWG 3912.
* testsuite/std/ranges/adaptors/enumerate/1.cc: Check iterator
difference is noexcept.
---

Tested x86_64-linux. Pushed to trunk.

 libstdc++-v3/include/std/ranges   |  2 +-
 .../testsuite/std/ranges/adaptors/enumerate/1.cc  | 11 +++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 6790fcf7af1..e21f5284b46 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -9176,7 +9176,7 @@ namespace views::__adaptor
 { return auto(__x) -= __y; }
 
 friend constexpr difference_type
-operator-(const _Iterator& __x, const _Iterator& __y)
+operator-(const _Iterator& __x, const _Iterator& __y) noexcept
 { return __x._M_pos - __y._M_pos; }
 
 friend constexpr auto
diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/enumerate/1.cc 
b/libstdc++-v3/testsuite/std/ranges/adaptors/enumerate/1.cc
index c33aa9ff51e..19aa98284d0 100644
--- a/libstdc++-v3/testsuite/std/ranges/adaptors/enumerate/1.cc
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/enumerate/1.cc
@@ -91,6 +91,17 @@ test02()
 }
 }
 
+void
+test_lwg3912()
+{
+  int x[] = {1, 2, 3};
+  test_input_range rx (x);
+  auto v = rx | views::enumerate;
+  auto iter = std::ranges::begin(v);
+  // LWG 3912. enumerate_view::iterator::operator- should be noexcept
+  static_assert( noexcept(iter - iter) );
+}
+
 int
 main()
 {
-- 
2.48.1

Re: Allow to build libgccjit with a soname bound to the GCC major version

[David Malcolm]

On Sat, 2025-02-08 at 10:33 +0100, Matthias Klose wrote:
> When configuring GCC with --program-suffix=-$(BASE_VERSION) to allow 
> installation multiple GCC versions in parallel, the executable of the
> driver (gcc-$(BASE_VERSION)) gets recorded in the libgccjit.so.0 
> library.  Assuming, that you only install the libgccjit.so.0 library 
> from the newest GCC, you have a libgccjit installed, which always
> calls 
> back to the newest installed version of GCC.  I'm not saying that the
> ABI is changing, but I'd like to see the libgccjit calling out to the
> corresponding compiler, and therefore installing a libgccjit with a 
> soname that matches the GCC major version.
> 
> The downside is having to rebuild packages built against libgccjit
> with 
> each major GCC version, but looking at the reverse dependencies, at 
> least for package builds, only emacs is using libgccjit.
> 
> My plan to use this feature is to build a libgccjit0 using the
> default 
> GCC (e.g. gcc-14), and a libgccjit15, when building a newer GCC. When
> changing the GCC default to 15, building a libgccjit0 from gcc-15,
> and a 
> libgccjit14 from gcc-14.
> 
> When configuring without --enable-versioned-jit, the behavior is
> unchanged.
> 
> Ok for the trunk?

Thanks; LGTM.

Dave

[PATCH htdocs] bugs: Link to all 'Porting to' docs in 'Common problems when upgrading ...'

[Sam James]

Suggested by Andrew Pinski. I think it makes sense to have it in here even
if perhaps a bit verbose, because we really try to tell bug reporters to
read the page properly.
---
This takes into account Gerald's comments, hopefully faithfully.

Gerald, let me know if I misinterpreted anything or need to do any followups.

Pushed.

 htdocs/branching.html  |  3 +++
 htdocs/bugs/index.html | 14 ++
 2 files changed, 17 insertions(+)

diff --git a/htdocs/branching.html b/htdocs/branching.html
index 23ff92e8..7010ae5a 100644
--- a/htdocs/branching.html
+++ b/htdocs/branching.html
@@ -55,6 +55,9 @@ the newly created release branch.
 Update the toplevel index.html page to show the new active
 release branch, the current release series, and active development
 (mainline).  Update the version and development stage for mainline.
+
+Update the list of versions in the bugs.html page for
+'Porting to'.
 
 
 
diff --git a/htdocs/bugs/index.html b/htdocs/bugs/index.html
index d6556b26..c4907c38 100644
--- a/htdocs/bugs/index.html
+++ b/htdocs/bugs/index.html
@@ -627,6 +627,20 @@ changed the parser rules so that <:: works 
as expected.
 
 Common problems when upgrading the compiler
 
+
+GCC maintains a 'Porting to' resource for new versions:
+GCC 15 | GCC 14 |
+GCC 13 | GCC 12 |
+GCC 11 | GCC 10 |
+GCC 9 | GCC 8 |
+GCC 7 | GCC 6 |
+GCC 5 | GCC 4.9 |
+GCC 4.8 | GCC 4.7 |
+
+GCC 4.6 | GCC 4.4 |
+GCC 4.3.
+
+
 ABI changes
 
 The C++ application binary interface (ABI) consists of two

base-commit: fc16e0b334c252286ad9935d5cc044c0308ee0f9
-- 
2.48.1

[PATCH htdocs 1/2] gcc-4.8/porting_to: update link to archive of Fedora rebuild

[Sam James]

---
Pushed.

 htdocs/gcc-4.8/porting_to.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/gcc-4.8/porting_to.html b/htdocs/gcc-4.8/porting_to.html
index 9ed0d06b..c7e188ef 100644
--- a/htdocs/gcc-4.8/porting_to.html
+++ b/htdocs/gcc-4.8/porting_to.html
@@ -231,7 +231,7 @@ error: stray ‘,’ at end of member declaration
 
 
 Jakub Jelinek,
- https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html";>Results
 of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
+ https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/ZY7P42I3C7VDCDCIZY762HBI5DYZ3GTW";>Results
 of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
 
 
 
-- 
2.48.1

[PATCH htdocs 2/2] gcc-8/porting_to: link to Fedora mass rebuild post

[Sam James]

As is done for other releases.
---
Pushed.

 htdocs/gcc-8/porting_to.html | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/htdocs/gcc-8/porting_to.html b/htdocs/gcc-8/porting_to.html
index d24ea347..1d16a29e 100644
--- a/htdocs/gcc-8/porting_to.html
+++ b/htdocs/gcc-8/porting_to.html
@@ -232,9 +232,11 @@ In member function 'bool B::f() const':
   
 
  
-
+
+
+Marek Polacek https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/FL4RYJ2NDEFT5CFB5JXI4OCL7VY5QCWJ";>Fedora
 mass rebuild 2018 on x86_64
+
 
 
 
-- 
2.48.1