[PATCH] asan: Don't instrument .ABNORMAL_DISPATCHER [PR114743]

[Jakub Jelinek]

Hi!

.ABNORMAL_DISPATCHER is currently the only internal function with
ECF_NORETURN, and asan likes to instrument ECF_NORETURN calls by adding
some builtin call before them, which breaks the .ABNORMAL_DISPATCHER
discovery added in gsi_safe_*.

The following patch fixes asan not to instrument .ABNORMAL_DISPATCHER
calls, like it doesn't instrument a couple of specific builtin calls
as well.

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

2024-04-17  Jakub Jelinek  

PR sanitizer/114743
* asan.cc (maybe_instrument_call): Don't instrument calls to
.ABNORMAL_DISPATCHER.

* gcc.dg/asan/pr112709-2.c (freddy): New function from
gcc.dg/ubsan/pr112709-2.c version of the test.

--- gcc/asan.cc.jj  2024-04-11 11:12:03.756191961 +0200
+++ gcc/asan.cc 2024-04-16 17:32:14.304098386 +0200
@@ -3030,6 +3030,9 @@ maybe_instrument_call (gimple_stmt_itera
  break;
}
}
+  if (gimple_call_internal_p (stmt, IFN_ABNORMAL_DISPATCHER))
+   /* Don't instrument this.  */
+   return false;
   /* If a function does not return, then we must handle clearing up the
 shadow stack accordingly.  For ASAN we can simply set the entire stack
 to "valid" for accesses by setting the shadow space to 0 and all
--- gcc/testsuite/gcc.dg/asan/pr112709-2.c.jj   2024-03-13 09:18:58.000925135 
+0100
+++ gcc/testsuite/gcc.dg/asan/pr112709-2.c  2024-04-16 17:34:26.084301656 
+0200
@@ -48,3 +48,15 @@ l3:
   if (x < 4)
 goto *q[x & 3];
 }
+
+void
+freddy (int x, int *y, struct S *p)
+{
+  bar (*p);
+  ++p;
+  if (x == 25)
+x = foo (2);
+  else if (x == 42)
+x = foo (foo (3));
+  *y = bar (*p);
+}

Jakub

Re: [PATCH] asan: Don't instrument .ABNORMAL_DISPATCHER [PR114743]

[Richard Biener]

On Wed, 17 Apr 2024, Jakub Jelinek wrote:

> Hi!
> 
> .ABNORMAL_DISPATCHER is currently the only internal function with
> ECF_NORETURN, and asan likes to instrument ECF_NORETURN calls by adding
> some builtin call before them, which breaks the .ABNORMAL_DISPATCHER
> discovery added in gsi_safe_*.
> 
> The following patch fixes asan not to instrument .ABNORMAL_DISPATCHER
> calls, like it doesn't instrument a couple of specific builtin calls
> as well.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK

> 2024-04-17  Jakub Jelinek  
> 
>   PR sanitizer/114743
>   * asan.cc (maybe_instrument_call): Don't instrument calls to
>   .ABNORMAL_DISPATCHER.
> 
>   * gcc.dg/asan/pr112709-2.c (freddy): New function from
>   gcc.dg/ubsan/pr112709-2.c version of the test.
> 
> --- gcc/asan.cc.jj2024-04-11 11:12:03.756191961 +0200
> +++ gcc/asan.cc   2024-04-16 17:32:14.304098386 +0200
> @@ -3030,6 +3030,9 @@ maybe_instrument_call (gimple_stmt_itera
> break;
>   }
>   }
> +  if (gimple_call_internal_p (stmt, IFN_ABNORMAL_DISPATCHER))
> + /* Don't instrument this.  */
> + return false;
>/* If a function does not return, then we must handle clearing up the
>shadow stack accordingly.  For ASAN we can simply set the entire stack
>to "valid" for accesses by setting the shadow space to 0 and all
> --- gcc/testsuite/gcc.dg/asan/pr112709-2.c.jj 2024-03-13 09:18:58.000925135 
> +0100
> +++ gcc/testsuite/gcc.dg/asan/pr112709-2.c2024-04-16 17:34:26.084301656 
> +0200
> @@ -48,3 +48,15 @@ l3:
>if (x < 4)
>  goto *q[x & 3];
>  }
> +
> +void
> +freddy (int x, int *y, struct S *p)
> +{
> +  bar (*p);
> +  ++p;
> +  if (x == 25)
> +x = foo (2);
> +  else if (x == 42)
> +x = foo (foo (3));
> +  *y = bar (*p);
> +}
> 
>   Jakub
> 
> 

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

[PATCH] c++: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

[Jakub Jelinek]

Hi!

When expand_or_defer_fn is called at_eof time, it calls import_export_decl
and then maybe_clone_body, which uses DECL_ONE_ONLY and comdat name in a
couple of places to try to optimize cdtors which are known to have the
same body by making the complete cdtor an alias to base cdtor (and in
that case also uses *[CD]5* as comdat group name instead of the normal
comdat group names specific to each mangled name).
Now, this optimization depends on DECL_ONE_ONLY and DECL_INTERFACE_KNOWN,
maybe_clone_body and can_alias_cdtor use:
  if (DECL_ONE_ONLY (fn))
cgraph_node::get_create (clone)->set_comdat_group (cxx_comdat_group 
(clone));
...
  bool can_alias = can_alias_cdtor (fn);
...
  /* Tell cgraph if both ctors or both dtors are known to have
 the same body.  */
  if (can_alias
  && fns[0]
  && idx == 1
  && cgraph_node::get_create (fns[0])->create_same_body_alias
   (clone, fns[0]))
{
  alias = true;
  if (DECL_ONE_ONLY (fns[0]))
{
  /* For comdat base and complete cdtors put them
 into the same, *[CD]5* comdat group instead of
 *[CD][12]*.  */
  comdat_group = cdtor_comdat_group (fns[1], fns[0]);
  cgraph_node::get_create (fns[0])->set_comdat_group (comdat_group);
  if (symtab_node::get (clone)->same_comdat_group)
symtab_node::get (clone)->remove_from_same_comdat_group ();
  symtab_node::get (clone)->add_to_same_comdat_group
(symtab_node::get (fns[0]));
}
}
and
  /* Don't use aliases for weak/linkonce definitions unless we can put both
 symbols in the same COMDAT group.  */
  return (DECL_INTERFACE_KNOWN (fn)
  && (SUPPORTS_ONE_ONLY || !DECL_WEAK (fn))
  && (!DECL_ONE_ONLY (fn)
  || (HAVE_COMDAT_GROUP && DECL_WEAK (fn;
The following testcase regressed with Marek's r14-5979 change,
when pr113208_0.C is compiled where the ctor is marked constexpr,
we no longer perform this optimization, where
_ZN6vectorI12QualityValueEC2ERKS1_ was emitted in the
_ZN6vectorI12QualityValueEC5ERKS1_ comdat group and
_ZN6vectorI12QualityValueEC1ERKS1_ was made an alias to it,
instead we emit _ZN6vectorI12QualityValueEC2ERKS1_ in
_ZN6vectorI12QualityValueEC2ERKS1_ comdat group and the same
content _ZN6vectorI12QualityValueEC1ERKS1_ as separate symbol in
_ZN6vectorI12QualityValueEC1ERKS1_ comdat group.
Now, the linker seems to somehow cope with that, eventhough it
probably keeps both copies of the ctor, but seems LTO can't cope
with that and Honza doesn't know what it should do in that case
(linker decides that the prevailing symbol is
_ZN6vectorI12QualityValueEC2ERKS1_ (from the
_ZN6vectorI12QualityValueEC2ERKS1_ comdat group) and
_ZN6vectorI12QualityValueEC1ERKS1_ alias (from the other TU,
from _ZN6vectorI12QualityValueEC5ERKS1_ comdat group)).

Note, the case where some constructor is marked constexpr in one
TU and not in another one happens pretty often in libstdc++ when
one mixes -std= flags used to compile different compilation units.

The reason the optimization doesn't trigger when the constructor is
constexpr is that expand_or_defer_fn is called in that case much earlier
than when it is not constexpr; in the former case it is called when we
try to constant evaluate that constructor.  But DECL_INTERFACE_KNOWN
is false in that case and comdat_linkage hasn't been called either
(I think it is desirable, because comdat group is stored in the cgraph
node and am not sure it is a good idea to create cgraph nodes for
something that might not be needed later on at all), so maybe_clone_body
clones the bodies, but doesn't make them as aliases.

The following patch is an attempt to redo this optimization when
import_export_decl is called at_eof time on the base/complete cdtor
(or deleting dtor).  It will not do anything if maybe_clone_body
hasn't been called uyet (the TREE_ASM_WRITTEN check on the
DECL_MAYBE_IN_CHARGE_CDTOR_P), or when one or both of the base/complete
cdtors have been lowered already, or when maybe_clone_body called
maybe_thunk_body and it was successful.  Otherwise retries the
can_alias_cdtor check and makes the complete cdtor alias to the
base cdtor with adjustments to the comdat group.

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

2024-04-17  Jakub Jelinek  

PR lto/113208
* cp-tree.h (maybe_optimize_cdtor): Declare.
* decl2.cc (import_export_decl): Call it for cloned cdtors.
* optimize.cc (maybe_optimize_cdtor): New function.

* g++.dg/lto/pr113208_0.C: New test.
* g++.dg/lto/pr113208_1.C: New file.
* g++.dg/lto/pr113208.h: New file.

--- gcc/cp/cp-tree.h.jj 2024-04-16 17:18:37.286279533 +0200
+++ gcc/cp/cp-tree.h2024-04-16 17:45:01.685635709 +0200
@@ -7447,6 +7447,7 @@ extern bool handle_module_option (unsign
 /* In optimize.cc */
 extern tree clone_attrs  

Re: [PATCH, rs6000] Fix test case bcd4.c

[Kewen.Lin]

Hi,

on 2024/4/17 13:12, HAO CHEN GUI wrote:
> Hi,
>   This patch fixes loss of return statement in maxbcd of bcd-4.c. Without
> return statement, it returns an invalid bcd number and make the test
> noneffective. The patch also enables test to run on Power9 and Big Endian,
> as all bcd instructions are supported from Power9.
> 
>   Bootstrapped and tested on powerpc64-linux BE and LE with no
> regressions. Is it OK for the trunk?

OK with two nits below tweaked, thanks!

> 
> Thanks
> Gui Haochen
> 
> 
> ChangeLog
> rs6000: Fix bcd test case
> 
> gcc/testsuite/
>   * gcc.target/powerpc/bcd-4.c: Enable the case to be tested on Power9.
>   Enable the case to be run on big endian.  Fix function maxbcd and
>   other misc. problems.
> 
> 
> patch.diff
> diff --git a/gcc/testsuite/gcc.target/powerpc/bcd-4.c 
> b/gcc/testsuite/gcc.target/powerpc/bcd-4.c
> index 2c8554dfe82..8c0bac2720f 100644
> --- a/gcc/testsuite/gcc.target/powerpc/bcd-4.c
> +++ b/gcc/testsuite/gcc.target/powerpc/bcd-4.c
> @@ -1,7 +1,7 @@
>  /* { dg-do run } */
>  /* { dg-require-effective-target int128 } */
> -/* { dg-require-effective-target power10_hw } */
> -/* { dg-options "-mdejagnu-cpu=power10 -O2 -save-temps" } */
> +/* { dg-require-effective-target p9vector_hw } */
> +/* { dg-options "-mdejagnu-cpu=power9 -O2 -save-temps" } */
>  /* { dg-final { scan-assembler-times {\mbcdadd\M} 7 } } */
>  /* { dg-final { scan-assembler-times {\mbcdsub\M} 18 } } */
>  /* { dg-final { scan-assembler-times {\mbcds\M} 2 } } */
> @@ -44,10 +44,20 @@ vector unsigned char maxbcd(unsigned int sign)
>vector unsigned char result;
>int i;
> 
> +#ifdef _BIG_ENDIAN
> +  for (i = 0; i < 15; i++)
> +#else
>for (i = 15; i > 0; i--)
> +#endif
>  result[i] = 0x99;
> 
> -  result[0] = sign << 4 | 0x9;
> +#ifdef _BIG_ENDIAN

Nit: I'd prefer __BIG_ENDIAN__, although both work in most cases,
RS6000_CPU_CPP_ENDIAN_BUILTINS in netbsd.h doesn't define _BIG_ENDIAN.

So could you do a global replacement with __BIG_ENDIAN__?

> +  result[15] = 0x90 | sign;
> +#else
> +  result[0] = 0x90 | sign;
> +#endif
> +
> +  return result;
>  }
> 
>  vector unsigned char num2bcd(long int a, int encoding)
> @@ -70,9 +80,17 @@ vector unsigned char num2bcd(long int a, int encoding)
> 
>hi = a % 10;   // 1st digit
>a = a / 10;
> +#ifdef _BIG_ENDIAN
> +  result[15] = hi << 4| sign;
> +#else
>result[0] = hi << 4| sign;
> +#endif
> 
> +#ifdef _BIG_ENDIAN
> +  for (i = 14; i >= 0; i--)
> +#else
>for (i = 1; i < 16; i++)
> +#endif
>  {
>low = a % 10;
>a = a / 10;
> @@ -117,7 +135,11 @@ int main ()
>  }
> 
>/* result should be positive */
> +#ifdef _BIG_ENDIAN
> +  if ((result[15] & 0xF) != BCD_POS0)
> +#else
>if ((result[0] & 0xF) != BCD_POS0)
> +#endif
>  #if DEBUG
>printf("ERROR: __builtin_bcdadd sign of result is %d.  Does not match "
>"expected_result = %d\n",
> @@ -150,7 +172,11 @@ int main ()
>  }
> 
>/* Result should be positive, alternate encoding.  */
> +#ifdef _BIG_ENDIAN
> +  if ((result[15] & 0xF) != BCD_POS1)
> +#else
>if ((result[0] & 0xF) != BCD_POS1)
> +#endif
>  #if DEBUG
>  printf("ERROR: __builtin_bcdadd sign of result is %d.  Does not "
>  "match expected_result = %d\n",
> @@ -183,7 +209,11 @@ int main ()
>  }
> 
>/* result should be negative */
> +#ifdef _BIG_ENDIAN
> +  if ((result[15] & 0xF) != BCD_NEG)
> +#else
>if ((result[0] & 0xF) != BCD_NEG)
> +#endif
>  #if DEBUG
>  printf("ERROR: __builtin_bcdadd sign, neg of result is %d.  Does not "
>  "match expected_result = %d\n",
> @@ -217,7 +247,11 @@ int main ()
>  }
> 
>/* result should be positive, alt encoding */

Nit: This comment is inconsistent with the below check, may be:

/* result should be negative.  */

BR,
Kewen

> +#ifdef _BIG_ENDIAN
> +  if ((result[15] & 0xF) != BCD_NEG)
> +#else
>if ((result[0] & 0xF) != BCD_NEG)
> +#endif
>  #if DEBUG
>  printf("ERROR: __builtin_bcdadd sign, of result is %d.  Does not match "
>  "expected_result = %d\n",
> @@ -250,7 +284,11 @@ int main ()
>  }
> 
>/* result should be positive */
> +#ifdef _BIG_ENDIAN
> +  if ((result[15] & 0xF) != BCD_POS1)
> +#else
>if ((result[0] & 0xF) != BCD_POS1)
> +#endif
>  #if DEBUG
>  printf("ERROR: __builtin_bcdsub sign, result is %d.  Does not match "
>  "expected_result = %d\n",
> @@ -283,7 +321,7 @@ int main ()
>  abort();
>  #endif
> 
> -  a = maxbcd(BCD_NEG);
> +  a = maxbcd(BCD_POS0);
>b = maxbcd(BCD_NEG);
> 
>if (__builtin_bcdsub_ofl (a, b, 0) == 0)
> @@ -462,8 +500,12 @@ int main ()
>  }
> 
>/* result should be positive */
> +#ifdef _BIG_ENDIAN
> +  if ((result[15] & 0xF) != BCD_POS0)
> +#else
>if ((result[0] & 0xF) != BCD_POS0)
> -#if 0
> +#endif
> +#if DEBUG
>  printf("ERROR: __builtin_bcdmul10 sign, result is %d.  Does not match "
>  "expected_result = %d\n",
>  result[0] & 0xF, BCD_POS1);
> @@ -492,7 +534,1

[PATCH] libstdc++: Avoid ill-formed types on ARM

[Matthias Kretz]

Tested on arm-linux-gnueabihf, powerpc64le-linux-gnu, and aarch64-linux-gnu.

OK for trunk and backports?

- 8< --

This resolves failing tests in check-simd.

Signed-off-by: Matthias Kretz 

libstdc++-v3/ChangeLog:

PR libstdc++/114750
* include/experimental/bits/simd_builtin.h
(_SimdImplBuiltin::_S_load, _S_store): Fall back to copying
scalars if the memory type cannot be vectorized for the target.
---
 libstdc++-v3/include/experimental/bits/simd_builtin.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


--
──
 Dr. Matthias Kretz   https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
 stdₓ::simd
──diff --git a/libstdc++-v3/include/experimental/bits/simd_builtin.h b/libstdc++-v3/include/experimental/bits/simd_builtin.h
index 28227a5d97f..af0c4886108 100644
--- a/libstdc++-v3/include/experimental/bits/simd_builtin.h
+++ b/libstdc++-v3/include/experimental/bits/simd_builtin.h
@@ -1464,7 +1464,7 @@ _S_broadcast(_Tp __x) noexcept
 		   [&](auto __i) constexpr {
 		 return static_cast<_Tp>(__i < _Np ? __mem[__i] : 0);
 		   });
-	else if constexpr (sizeof(_Up) > 8)
+	else if constexpr (sizeof(_Up) > 8 or __vectorized_sizeof<_Up>() <= sizeof(_Up))
 	  return __generate_vector<_Tp, _SimdMember<_Tp>::_S_full_size>(
 		   [&](auto __i) constexpr _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA {
 		 return static_cast<_Tp>(__i < _Np ? __mem[__i] : 0);
@@ -1536,7 +1536,7 @@ _S_masked_load(_SimdWrapper<_Tp, _Np> __merge, _MaskMember<_Tp> __k,
 	for (size_t __i = 0; __i < _Np; ++__i)
 	  __mem[__i] = __v[__i];
 	  }
-	else if constexpr (sizeof(_Up) > 8)
+	else if constexpr (sizeof(_Up) > 8 or __vectorized_sizeof<_Up>() <= sizeof(_Up))
 	  __execute_n_times<_Np>([&](auto __i) constexpr _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA {
 	__mem[__i] = __v[__i];
 	  });


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] build: Check for cargo when building rust language

[Rainer Orth]

Andrew Pinski  writes:

> On Mon, Apr 8, 2024 at 9:39 AM  wrote:
>>
>> From: Pierre-Emmanuel Patry 
>>
>> Hello,
>>
>> The rust frontend requires cargo to build some of it's components,
>> it's presence was not checked during configuration.
>
> WHY did this go in right before the release of GCC 14?
> I don't get why this is considered temporary and it goes in right
> before a release.
> That seems broken to me.

two more questions about this:

Right now, the new cargo configure test disable rust on all of my
targets (Solaris, Linux, Darwin) which didn't have it installed.  Before
(as recent as last Friday), I could successfully build and test
crab1/rust on all of them without cargo in sight.  So I wonder if the
patch isn't premature.

Besides, while there are packaged versions of cargo for Solaris 11.4 and
Linux, Darwin hasn't anything (not checked Homebrew or similar yet).
What's worse, rustup only supports macOS 10.12 and up, while I'm still
regularly testing 10.7 and 10.11.  I don't really feel like building
rust from source here (if it works at all).  This hasn't been an issue
for any other languages that require additional tools for bootstrapping
(like Ada or D): there are versions of GNAT around that still support
those old Darwin releases, and I could use the C++ version of GDC in GCC
11.

At the very least, the Rust situation needs to be documented clearly.

Rainer

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

[PATCH] libstdc++: Add include guard to simd-internal header

[Matthias Kretz]

This never showed up as an issue because it's an internal header and 
implicitly guarded by bits/simd.h.

OK for trunk? Any reason to backport?

- 8< --

Signed-off-by: Matthias Kretz 

libstdc++-v3/ChangeLog:

* include/experimental/bits/numeric_traits.h: Add include guard.
---
 libstdc++-v3/include/experimental/bits/numeric_traits.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/libstdc++-v3/include/experimental/bits/numeric_traits.h b/
libstdc++-v3/include/experimental/bits/numeric_traits.h
index b195de7c3db..8717f684d96 100644
--- a/libstdc++-v3/include/experimental/bits/numeric_traits.h
+++ b/libstdc++-v3/include/experimental/bits/numeric_traits.h
@@ -22,6 +22,9 @@
 // see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 // .
 
+#ifndef _GLIBCXX_EXPERIMENTAL_BITS_NUMERIC_TRAITS_H
+#define _GLIBCXX_EXPERIMENTAL_BITS_NUMERIC_TRAITS_H
+
 #include 
 
 namespace std {
@@ -565,3 +568,4 @@ struct __has_iec559_behavior<__signaling_NaN, long 
double>
 #endif // __FINITE_MATH_ONLY__
 
 } // namespace std
+#endif  // _GLIBCXX_EXPERIMENTAL_BITS_NUMERIC_TRAITS_H
-- 
──
 Dr. Matthias Kretz   https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
 stdₓ::simd
──



signature.asc
Description: This is a digitally signed message part.

Re: GCN: Enable effective-target 'vect_long_long'

[Andrew Stubbs]

On 16/04/2024 20:01, Thomas Schwinge wrote:

Hi!

OK to push the attached "GCN: Enable effective-target 'vect_long_long'"?
(Or is that not what you'd expect to see for GCN?  I haven't checked the
actual back end code...)


I think if there are still missing int64 vector operations then they're 
exceptions, not the rule.


The patch looks good to me.

Andrew

Re: [PATCH] libstdc++: Avoid ill-formed types on ARM

[Jonathan Wakely]

On Wed, 17 Apr 2024 at 08:58, Matthias Kretz  wrote:
>
> Tested on arm-linux-gnueabihf, powerpc64le-linux-gnu, and aarch64-linux-gnu.
>
> OK for trunk and backports?

OK, thanks.


>
> - 8< --
>
> This resolves failing tests in check-simd.
>
> Signed-off-by: Matthias Kretz 
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/114750
> * include/experimental/bits/simd_builtin.h
> (_SimdImplBuiltin::_S_load, _S_store): Fall back to copying
> scalars if the memory type cannot be vectorized for the target.
> ---
>  libstdc++-v3/include/experimental/bits/simd_builtin.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
>
> --
> ──
>  Dr. Matthias Kretz   https://mattkretz.github.io
>  GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
>  stdₓ::simd
> ──

Re: [PATCH] libstdc++: Add include guard to simd-internal header

[Jonathan Wakely]

On Wed, 17 Apr 2024 at 09:17, Matthias Kretz  wrote:
>
> This never showed up as an issue because it's an internal header and
> implicitly guarded by bits/simd.h.
>
> OK for trunk? Any reason to backport?

OK for trunk, I think it's worth backporting too.


>
> - 8< --
>
> Signed-off-by: Matthias Kretz 
>
> libstdc++-v3/ChangeLog:
>
> * include/experimental/bits/numeric_traits.h: Add include guard.
> ---
>  libstdc++-v3/include/experimental/bits/numeric_traits.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libstdc++-v3/include/experimental/bits/numeric_traits.h b/
> libstdc++-v3/include/experimental/bits/numeric_traits.h
> index b195de7c3db..8717f684d96 100644
> --- a/libstdc++-v3/include/experimental/bits/numeric_traits.h
> +++ b/libstdc++-v3/include/experimental/bits/numeric_traits.h
> @@ -22,6 +22,9 @@
>  // see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
>  // .
>
> +#ifndef _GLIBCXX_EXPERIMENTAL_BITS_NUMERIC_TRAITS_H
> +#define _GLIBCXX_EXPERIMENTAL_BITS_NUMERIC_TRAITS_H
> +
>  #include 
>
>  namespace std {
> @@ -565,3 +568,4 @@ struct __has_iec559_behavior<__signaling_NaN, long
> double>
>  #endif // __FINITE_MATH_ONLY__
>
>  } // namespace std
> +#endif  // _GLIBCXX_EXPERIMENTAL_BITS_NUMERIC_TRAITS_H
> --
> ──
>  Dr. Matthias Kretz   https://mattkretz.github.io
>  GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
>  stdₓ::simd
> ──
>

[patch,avr,applied] PR114752 - Fix ICE on inline asm const 64-bit float operand

[Georg-Johann Lay]

Applied as obvious

Johann

--

AVR: target/114752 - Fix ICE on inline asm const 64-bit float operand

gcc/
PR target/114752
* config/avr/avr.cc (avr_print_operand) [CONST_DOUBLE_P]: 
Handle DFmode.


diff --git a/gcc/config/avr/avr.cc b/gcc/config/avr/avr.cc
index 4a5a921107b..510e4cea19f 100644
--- a/gcc/config/avr/avr.cc
+++ b/gcc/config/avr/avr.cc
@@ -3932,11 +3932,20 @@ avr_print_operand (FILE *file, rtx x, int code)
 }
   else if (CONST_DOUBLE_P (x))
 {
-  long val;
-  if (GET_MODE (x) != SFmode)
+  if (GET_MODE (x) == SFmode)
+   {
+ long val;
+ REAL_VALUE_TO_TARGET_SINGLE (*CONST_DOUBLE_REAL_VALUE (x), val);
+ fprintf (file, "0x%lx", val);
+   }
+  else if (GET_MODE (x) == DFmode)
+   {
+ long l[2];
+ REAL_VALUE_TO_TARGET_DOUBLE (*CONST_DOUBLE_REAL_VALUE (x), l);
+ fprintf (file, "0x%lx%08lx", l[1] & 0x, l[0] & 
0x);

+   }
+  else
fatal_insn ("internal compiler error.  Unknown mode:", x);
-  REAL_VALUE_TO_TARGET_SINGLE (*CONST_DOUBLE_REAL_VALUE (x), val);
-  fprintf (file, "0x%lx", val);
 }
   else if (GET_CODE (x) == CONST_STRING)
 fputs (XSTR (x, 0), file);

Re: [PATCH] c++: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

[Jan Hubicka]

> Hi!
Hello,
> The reason the optimization doesn't trigger when the constructor is
> constexpr is that expand_or_defer_fn is called in that case much earlier
> than when it is not constexpr; in the former case it is called when we
> try to constant evaluate that constructor.  But DECL_INTERFACE_KNOWN
> is false in that case and comdat_linkage hasn't been called either
> (I think it is desirable, because comdat group is stored in the cgraph
> node and am not sure it is a good idea to create cgraph nodes for
> something that might not be needed later on at all), so maybe_clone_body
> clones the bodies, but doesn't make them as aliases.

Thanks for working this out! Creating cgraph node with no body is
harmless as it will be removed later.  
> 
> The following patch is an attempt to redo this optimization when
> import_export_decl is called at_eof time on the base/complete cdtor
> (or deleting dtor).  It will not do anything if maybe_clone_body
> hasn't been called uyet (the TREE_ASM_WRITTEN check on the
> DECL_MAYBE_IN_CHARGE_CDTOR_P), or when one or both of the base/complete
> cdtors have been lowered already, or when maybe_clone_body called
> maybe_thunk_body and it was successful.  Otherwise retries the
> can_alias_cdtor check and makes the complete cdtor alias to the
> base cdtor with adjustments to the comdat group.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2024-04-17  Jakub Jelinek  
> 
>   PR lto/113208
>   * cp-tree.h (maybe_optimize_cdtor): Declare.
>   * decl2.cc (import_export_decl): Call it for cloned cdtors.
>   * optimize.cc (maybe_optimize_cdtor): New function.
> 
>   * g++.dg/lto/pr113208_0.C: New test.
>   * g++.dg/lto/pr113208_1.C: New file.
>   * g++.dg/lto/pr113208.h: New file.
> 
> --- gcc/cp/cp-tree.h.jj   2024-04-16 17:18:37.286279533 +0200
> +++ gcc/cp/cp-tree.h  2024-04-16 17:45:01.685635709 +0200
> @@ -7447,6 +7447,7 @@ extern bool handle_module_option (unsign
>  /* In optimize.cc */
>  extern tree clone_attrs  (tree);
>  extern bool maybe_clone_body (tree);
> +extern void maybe_optimize_cdtor (tree);
>  
>  /* In parser.cc */
>  extern tree cp_convert_range_for (tree, tree, tree, cp_decomp *, bool,
> --- gcc/cp/decl2.cc.jj2024-04-16 17:18:37.287279519 +0200
> +++ gcc/cp/decl2.cc   2024-04-16 17:45:01.686635695 +0200
> @@ -3568,6 +3568,9 @@ import_export_decl (tree decl)
>  }
>  
>DECL_INTERFACE_KNOWN (decl) = 1;
> +
> +  if (DECL_CLONED_FUNCTION_P (decl))
> +maybe_optimize_cdtor (decl);
>  }
>  
>  /* Return an expression that performs the destruction of DECL, which
> --- gcc/cp/optimize.cc.jj 2024-04-16 17:18:37.374278327 +0200
> +++ gcc/cp/optimize.cc2024-04-16 21:35:53.597188774 +0200
> @@ -723,3 +723,58 @@ maybe_clone_body (tree fn)
>/* We don't need to process the original function any further.  */
>return 1;
>  }
> +
> +/* If maybe_clone_body is called while the cdtor is still tentative,
> +   DECL_ONE_ONLY will be false and so will be can_alias_cdtor (fn).
> +   In that case we wouldn't try to optimize using an alias and instead
> +   would emit separate base and complete cdtor.  The following function
> +   attempts to still optimize that case when we import_export_decl
> +   is called first time on one of the clones.  */
> +
> +void
> +maybe_optimize_cdtor (tree orig_decl)
> +{
> +  tree fns[3];
> +  tree fn = DECL_CLONED_FUNCTION (orig_decl);
> +  gcc_checking_assert (DECL_MAYBE_IN_CHARGE_CDTOR_P (fn));
> +  if (DECL_INTERFACE_KNOWN (fn)
> +  || !TREE_ASM_WRITTEN (fn)
> +  || !DECL_ONE_ONLY (orig_decl)
> +  || symtab->global_info_ready)
> +return;
> +
> +  populate_clone_array (fn, fns);
> +
> +  if (!fns[0] || !fns[1])
> +return;
> +  for (int i = 2 - !fns[2]; i >= 0; --i)
> +if (fns[i] != orig_decl && DECL_INTERFACE_KNOWN (fns[i]))
> +  return;
> +  DECL_INTERFACE_KNOWN (fn) = 1;
> +  comdat_linkage (fn);
> +  if (!can_alias_cdtor (fn))
> +return;
> +  /* For comdat base and complete cdtors put them into the same,
> + *[CD]5* comdat group instead of *[CD][12]*.  */
> +  auto n0 = cgraph_node::get_create (fns[0]);
> +  auto n1 = cgraph_node::get_create (fns[1]);
> +  auto n2 = fns[2] ? cgraph_node::get_create (fns[1]) : NULL;
> +  if (n0->lowered || n1->lowered || (n2 && n2->lowered))
> +return;
> +  import_export_decl (fns[0]);
> +  n1->definition = false;
> +  if (!n0->create_same_body_alias (fns[1], fns[0]))
> +return;
> +
> +  tree comdat_group = cdtor_comdat_group (fns[1], fns[0]);
> +  n1 = cgraph_node::get (fns[1]);
> +  n0->set_comdat_group (comdat_group);
> +  if (n1->same_comdat_group)
> +n1->remove_from_same_comdat_group ();
> +  n1->add_to_same_comdat_group (n0);
> +  if (fns[2])
> +n2->add_to_same_comdat_group (n0);
> +  import_export_decl (fns[1]);

So this is handling the case where symbol was already inserted into one
comdat group and later w

Re: [PATCH V3] rs6000: Don't ICE when compiling the __builtin_vsx_splat_2di built-in [PR113950]

[jeevitha]

Hi,

On 18/03/24 7:00 am, Kewen.Lin wrote:

>> The bogus vsx_splat_ code goes all the way back to GCC 8, so we
>> should backport this fix.  Segher and Ke Wen, can we get an approval
>> to backport this to all the open release branches (GCC 13, 12, 11)?
>> Thanks.
> 
> Sure, okay for backporting this to all active branches, thanks!
> 

I need clarification regarding the backporting of PR113950 to GCC 12.

We encountered an issue while resolving merge conflicts in GCC 12. The 
problem lies in extra deletions in the diff due to cherry-picking. Now,
we're unsure about the best approach for handling the backport.

To provide context, I have included the relevant diff snippet below,

diff --cc gcc/config/rs6000/vsx.md
index c45794fb9ed,f135fa079bd..000
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@@ -4562,8 -4666,8 +4562,8 @@@
rtx op1 = operands[1];
if (MEM_P (op1))
  operands[1] = rs6000_force_indexed_or_indirect_mem (op1);
-   else if (!REG_P (op1))
- op1 = force_reg (mode, op1);
+   else
 -operands[1] = force_reg (mode, op1);
++operands[1] = force_reg (mode, op1);
  })

I'm seeking your advice on how to proceed with the backport. Do you
think the above change is acceptable, or should we also backport Segher's
commit e0e3ce634818b83965b87512938490df4d57f81d, which caused the conflict?.
There was no regression with both of these changes.

Jeevitha.

[PING^1][PATCH v2] rs6000: Fix issue in specifying PTImode as an attribute [PR106895]

[jeevitha]

Ping!

I've incorporated all the suggested changes. Please review.

Thanks & Regards
Jeevitha

On 21/03/24 6:21 pm, jeevitha wrote:
> Hi All,
> 
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
> 
> PTImode assists in generating even/odd register pairs on 128 bits. When the 
> user 
> specifies PTImode as an attribute, it breaks because there is no internal 
> type 
> to handle this mode. To address this, we have created a tree node with dummy 
> type
> to handle PTImode. We are not documenting this dummy type since users are not
> allowed to use this type externally.
> 
> 2024-03-21  Jeevitha Palanisamy  
> 
> gcc/
>   PR target/110411
>   * config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add
>   RS6000_BTI_INTPTI.
>   * config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Add node
>   for PTImode type.
> 
> gcc/testsuite/
>   PR target/106895
>   * gcc.target/powerpc/pr106895.c: New testcase.
> 
> diff --git a/gcc/config/rs6000/rs6000-builtin.cc 
> b/gcc/config/rs6000/rs6000-builtin.cc
> index 6698274031b..f553c72779e 100644
> --- a/gcc/config/rs6000/rs6000-builtin.cc
> +++ b/gcc/config/rs6000/rs6000-builtin.cc
> @@ -756,6 +756,15 @@ rs6000_init_builtins (void)
>else
>  ieee128_float_type_node = NULL_TREE;
>  
> +  /* PTImode to get even/odd register pairs.  */
> +  intPTI_type_internal_node = make_node(INTEGER_TYPE);
> +  TYPE_PRECISION (intPTI_type_internal_node) = GET_MODE_BITSIZE (PTImode);
> +  layout_type (intPTI_type_internal_node);
> +  SET_TYPE_MODE (intPTI_type_internal_node, PTImode);
> +  t = build_qualified_type (intPTI_type_internal_node, TYPE_QUAL_CONST);
> +  lang_hooks.types.register_builtin_type (intPTI_type_internal_node,
> +   "__dummypti");
> +
>/* Vector pair and vector quad support.  */
>vector_pair_type_node = make_node (OPAQUE_TYPE);
>SET_TYPE_MODE (vector_pair_type_node, OOmode);
> diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
> index 68bc45d65ba..b6078077b20 100644
> --- a/gcc/config/rs6000/rs6000.h
> +++ b/gcc/config/rs6000/rs6000.h
> @@ -2302,6 +2302,7 @@ enum rs6000_builtin_type_index
>RS6000_BTI_ptr_vector_quad,
>RS6000_BTI_ptr_long_long,
>RS6000_BTI_ptr_long_long_unsigned,
> +  RS6000_BTI_INTPTI,
>RS6000_BTI_MAX
>  };
>  
> @@ -2346,6 +2347,7 @@ enum rs6000_builtin_type_index
>  #define uintDI_type_internal_node 
> (rs6000_builtin_types[RS6000_BTI_UINTDI])
>  #define intTI_type_internal_node  
> (rs6000_builtin_types[RS6000_BTI_INTTI])
>  #define uintTI_type_internal_node 
> (rs6000_builtin_types[RS6000_BTI_UINTTI])
> +#define intPTI_type_internal_node 
> (rs6000_builtin_types[RS6000_BTI_INTPTI])
>  #define float_type_internal_node  
> (rs6000_builtin_types[RS6000_BTI_float])
>  #define double_type_internal_node 
> (rs6000_builtin_types[RS6000_BTI_double])
>  #define long_double_type_internal_node
> (rs6000_builtin_types[RS6000_BTI_long_double])
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106895.c 
> b/gcc/testsuite/gcc.target/powerpc/pr106895.c
> new file mode 100644
> index 000..56547b7fa9d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106895.c
> @@ -0,0 +1,15 @@
> +/* PR target/106895 */
> +/* { dg-require-effective-target int128 } */
> +/* { dg-options "-O2" } */
> +
> +/* Verify the following generates even/odd register pairs.  */
> +
> +typedef __int128 pti __attribute__((mode(PTI)));
> +
> +void
> +set128 (pti val, pti *mem)
> +{
> +asm("stq %1,%0" : "=m"(*mem) : "r"(val));
> +}
> +
> +/* { dg-final { scan-assembler "stq \[123\]?\[02468\]" } } */
> 
> 

[PING^3][PATCH] rs6000: load high and low part of 128bit vector independently [PR110040]

[jeevitha]

Ping!

please review.

Thanks & Regards
Jeevitha

On 26/03/24 10:23 am, jeevitha wrote:
> Ping!
> 
> please review.
> 
> Thanks & Regards
> Jeevitha
> 
> 
> On 26/02/24 11:13 am, jeevitha wrote:
>> Hi All,
>>
>> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>>
>> PR110040 exposes an issue concerning moves from vector registers to GPRs.
>> There are two moves, one for upper 64 bits and the other for the lower
>> 64 bits.  In the problematic test case, we are only interested in storing
>> the lower 64 bits.  However, the instruction for copying the upper 64 bits
>> is still emitted and is dead code.  This patch adds a splitter that splits
>> apart the two move instructions so that DCE can remove the dead code after
>> splitting.
>>
>> 2024-02-26  Jeevitha Palanisamy  
>>
>> gcc/
>>  PR target/110040
>>  * config/rs6000/vsx.md (split pattern for V1TI to DI move): Defined.
>>
>> gcc/testsuite/
>>  PR target/110040
>>  * gcc.target/powerpc/pr110040-1.c: New testcase.
>>  * gcc.target/powerpc/pr110040-2.c: New testcase.
>>
>>
>> diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
>> index 6111cc90eb7..78457f8fb14 100644
>> --- a/gcc/config/rs6000/vsx.md
>> +++ b/gcc/config/rs6000/vsx.md
>> @@ -6706,3 +6706,19 @@
>>"vmsumcud %0,%1,%2,%3"
>>[(set_attr "type" "veccomplex")]
>>  )
>> +
>> +(define_split
>> +  [(set (match_operand:V1TI 0 "int_reg_operand")
>> +   (match_operand:V1TI 1 "vsx_register_operand"))]
>> +  "reload_completed
>> +   && TARGET_DIRECT_MOVE_64BIT"
>> +   [(pc)]
>> +{
>> +  rtx op0 = gen_rtx_REG (DImode, REGNO (operands[0]));
>> +  rtx op1 = gen_rtx_REG (V2DImode, REGNO (operands[1]));
>> +  rtx op2 = gen_rtx_REG (DImode, REGNO (operands[0]) + 1);
>> +  rtx op3 = gen_rtx_REG (V2DImode, REGNO (operands[1]));
>> +  emit_insn (gen_vsx_extract_v2di (op0, op1, GEN_INT (0)));
>> +  emit_insn (gen_vsx_extract_v2di (op2, op3, GEN_INT (1)));
>> +  DONE;
>> +})
>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr110040-1.c 
>> b/gcc/testsuite/gcc.target/powerpc/pr110040-1.c
>> new file mode 100644
>> index 000..fb3bd254636
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/pr110040-1.c
>> @@ -0,0 +1,14 @@
>> +/* PR target/110040 */
>> +/* { dg-do compile } */
>> +/* { dg-require-effective-target powerpc_p9vector_ok } */
>> +/* { dg-options "-O2 -mdejagnu-cpu=power9" } */
>> +/* { dg-final { scan-assembler-not {\mmfvsrd\M} } } */
>> +
>> +#include 
>> +
>> +void
>> +foo (signed long *dst, vector signed __int128 src)
>> +{
>> +  *dst = (signed long) src[0];
>> +}
>> +
>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr110040-2.c 
>> b/gcc/testsuite/gcc.target/powerpc/pr110040-2.c
>> new file mode 100644
>> index 000..f3aa22be4e8
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/pr110040-2.c
>> @@ -0,0 +1,13 @@
>> +/* PR target/110040 */
>> +/* { dg-do compile } */
>> +/* { dg-require-effective-target power10_ok } */
>> +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
>> +/* { dg-final { scan-assembler-not {\mmfvsrd\M} } } */
>> +
>> +#include 
>> +
>> +void
>> +foo (signed int *dst, vector signed __int128 src)
>> +{
>> +  __builtin_vec_xst_trunc (src, 0, dst);
>> +}
>>
>>

[PATCH] tree-optimization/114749 - reset partial vector decision for no-SLP retry

[Richard Biener]

The following makes sure to reset LOOP_VINFO_USING_PARTIAL_VECTORS_P
to its default of false when re-trying without SLP as otherwise
analysis may run into bogus asserts.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

PR tree-optimization/114749
* tree-vect-loop.cc (vect_analyze_loop_2): Reset
LOOP_VINFO_USING_PARTIAL_VECTORS_P when re-trying without SLP.
---
 gcc/tree-vect-loop.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 431b3e9492c..a6cf0a5546c 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -3400,6 +3400,7 @@ again:
   LOOP_VINFO_VERSIONING_THRESHOLD (loop_vinfo) = 0;
   LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
 = saved_can_use_partial_vectors_p;
+  LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo) = false;
 
   goto start_over;
 }
-- 
2.35.3

Re: [PATCH V3] rs6000: Don't ICE when compiling the __builtin_vsx_splat_2di built-in [PR113950]

[Kewen.Lin]

Hi,

on 2024/4/17 17:05, jeevitha wrote:
> Hi,
> 
> On 18/03/24 7:00 am, Kewen.Lin wrote:
> 
>>> The bogus vsx_splat_ code goes all the way back to GCC 8, so we
>>> should backport this fix.  Segher and Ke Wen, can we get an approval
>>> to backport this to all the open release branches (GCC 13, 12, 11)?
>>> Thanks.
>>
>> Sure, okay for backporting this to all active branches, thanks!
>>
> 
> I need clarification regarding the backporting of PR113950 to GCC 12.
> 
> We encountered an issue while resolving merge conflicts in GCC 12. The 
> problem lies in extra deletions in the diff due to cherry-picking. Now,
> we're unsure about the best approach for handling the backport.
> 
> To provide context, I have included the relevant diff snippet below,
> 
> diff --cc gcc/config/rs6000/vsx.md
> index c45794fb9ed,f135fa079bd..000
> --- a/gcc/config/rs6000/vsx.md
> +++ b/gcc/config/rs6000/vsx.md
> @@@ -4562,8 -4666,8 +4562,8 @@@
> rtx op1 = operands[1];
> if (MEM_P (op1))
>   operands[1] = rs6000_force_indexed_or_indirect_mem (op1);
> -   else if (!REG_P (op1))
> - op1 = force_reg (mode, op1);
> +   else
>  -operands[1] = force_reg (mode, op1);
> ++operands[1] = force_reg (mode, op1);
>   })
> 
> I'm seeking your advice on how to proceed with the backport. Do you
> think the above change is acceptable, or should we also backport Segher's
> commit e0e3ce634818b83965b87512938490df4d57f81d, which caused the conflict?.

I prefer the former, which is the least modification, for release branches
let's introduce as few changes as possible, and the amendment on the conflict
is minor and straightforward.

BR,
Kewen

> There was no regression with both of these changes.
> 
> Jeevitha.
> 

[PATCH] testsuite, rs6000: Fix builtins-6-p9-runnable.c for BE [PR114744]

[Kewen.Lin]

Hi,

Test case builtins-6-p9-runnable.c doesn't work well on BE
due to two problems:
  - When applying vec_xl_len onto data_128 and data_u128
with length 8, it expects to load 128[01] from
the memory, but unfortunately assigning 128[01] to
a {vector} {u,}int128 type variable, the value isn't
guaranteed to be at the beginning of storage (in the
low part of memory), which means the loaded value can
be unexpected (as shown on BE).  So this patch is to
introduce getU128 which can ensure the given value
shows up as expected and also update some dumping code
for debugging.
  - When applying vec_xl_len_r with length 16, on BE it's
just like the normal vector load, so the expected data
should not be reversed from the original.

Tested well on both powerpc64{,le}-linux-gnu, I'm going to
push this soon.

BR,
Kewen
-
PR testsuite/114744

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/builtins-6-p9-runnable.c: Adjust for BE by fixing
data_{u,}128, their uses and vec_uc_expected1, also adjust some formats.
---
 .../powerpc/builtins-6-p9-runnable.c  | 119 ++
 1 file changed, 64 insertions(+), 55 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-6-p9-runnable.c 
b/gcc/testsuite/gcc.target/powerpc/builtins-6-p9-runnable.c
index 20fdd3bb4ec..36101c2b861 100644
--- a/gcc/testsuite/gcc.target/powerpc/builtins-6-p9-runnable.c
+++ b/gcc/testsuite/gcc.target/powerpc/builtins-6-p9-runnable.c
@@ -337,6 +337,30 @@ void print_f (vector float vec_expected,
 }
 #endif

+typedef union
+{
+  vector __int128_t i1;
+  __int128_t i2;
+  vector __uint128_t u1;
+  __uint128_t u2;
+  struct
+  {
+long long d1;
+long long d2;
+  };
+} U128;
+
+/* For a given long long VALUE, ensure it's stored from the beginning
+   of {u,}int128 memory storage (the low address), it avoids to load
+   unexpected data without the whole vector length.  */
+
+static inline void
+getU128 (U128 *pu, unsigned long long value)
+{
+  pu->d1 = value;
+  pu->d2 = 0;
+}
+
 int main() {
   int i, j;
   size_t len;
@@ -835,21 +859,24 @@ int main() {
 #endif
 }

+  U128 u_temp;
   /* vec_xl_len() tests */
   for (i = 0; i < 100; i++)
 {
-  data_c[i] = i;
-  data_uc[i] = i+1;
-  data_ssi[i] = i+10;
-  data_usi[i] = i+11;
-  data_si[i] = i+100;
-  data_ui[i] = i+101;
-  data_sll[i] = i+1000;
-  data_ull[i] = i+1001;
-  data_f[i] = i+10.0;
-  data_d[i] = i+100.0;
-  data_128[i] = i + 1280;
-  data_u128[i] = i + 1281;
+   data_c[i] = i;
+   data_uc[i] = i + 1;
+   data_ssi[i] = i + 10;
+   data_usi[i] = i + 11;
+   data_si[i] = i + 100;
+   data_ui[i] = i + 101;
+   data_sll[i] = i + 1000;
+   data_ull[i] = i + 1001;
+   data_f[i] = i + 10.0;
+   data_d[i] = i + 100.0;
+   getU128 (&u_temp, i + 1280);
+   data_128[i] = u_temp.i2;
+   getU128 (&u_temp, i + 1281);
+   data_u128[i] = u_temp.u2;
 }

   len = 16;
@@ -1160,34 +1187,38 @@ int main() {
 #endif
 }

-  vec_s128_expected1 = (vector __int128_t){1280};
+  getU128 (&u_temp, 1280);
+  vec_s128_expected1 = u_temp.i1;
   vec_s128_result1 = vec_xl_len (data_128, len);

   if (vec_s128_expected1[0] != vec_s128_result1[0])
 {
 #ifdef DEBUG
-   printf("Error: vec_xl_len(), len = %d, vec_s128_result1[0] = %lld %llu; 
",
- len, vec_s128_result1[0] >> 64,
- vec_s128_result1[0] & (__int128_t)0x);
-   printf("vec_s128_expected1[0] = %lld %llu\n",
- vec_s128_expected1[0] >> 64,
- vec_s128_expected1[0] & (__int128_t)0x);
+  U128 u1, u2;
+  u1.i1 = vec_s128_result1;
+  u2.i1 = vec_s128_expected1;
+  printf ("Error: vec_xl_len(), len = %d,"
+ "vec_s128_result1[0] = %llx %llx; ",
+ len, u1.d1, u1.d2);
+  printf ("vec_s128_expected1[0] = %llx %llx\n", u2.d1, u2.d2);
 #else
abort ();
 #endif
 }

   vec_u128_result1 = vec_xl_len (data_u128, len);
-  vec_u128_expected1 = (vector __uint128_t){1281};
+  getU128 (&u_temp, 1281);
+  vec_u128_expected1 = u_temp.u1;
   if (vec_u128_expected1[0] != vec_u128_result1[0])
 #ifdef DEBUG
 {
-   printf("Error: vec_xl_len(), len = %d, vec_u128_result1[0] = %lld; ",
- len, vec_u128_result1[0] >> 64,
- vec_u128_result1[0] & (__int128_t)0x);
-   printf("vec_u128_expected1[0] = %lld\n",
- vec_u128_expected1[0] >> 64,
- vec_u128_expected1[0] & (__int128_t)0x);
+  U128 u1, u2;
+  u1.u1 = vec_u128_result1;
+  u2.u1 = vec_u128_expected1;
+  printf ("Error: vec_xl_len(), len = %d,"
+ "vec_u128_result1[0] = %llx %llx; ",
+ len, u1.d1, u1.d2);
+  printf ("vec_u128_expected1[0] = %llx %llx\n", u2.d1, u2.d2);
 }
 #else
 abort ();
@@ -1421,8 

[PATCH] DOCUMENTATION_ROOT_URL vs. release branches [PR114738]

[Jakub Jelinek]

Hi!

Starting with GCC 14 we have the nice URLification of the options printed
in diagnostics, say for in
test.c:4:23: warning: format ‘%d’ expects argument of type ‘int’, but argument 
2 has type ‘long int’ [-Wformat=]
the -Wformat= is underlined in some terminals and hovering on it shows
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat
link.

This works nicely on the GCC trunk, where the online documentation is
regenerated every day from a cron job and more importantly, people rarely
use the trunk snapshots for too long, so it is unlikely that further changes
in the documentation will make too many links stale, because users will
simply regularly update to newer snapshots.

I think it doesn't work properly on release branches though.
Some users only use the relased versions (i.e. MAJOR.MINOR.0) from tarballs
but can use them for a couple of years, others use snapshots from the
release branches, but again they could be in use for months or years and
the above mentioned online docs which represent just the GCC trunk might
diverge significantly.

Now, for the relases we always publish also online docs for the release,
which unlike the trunk online docs will not change further, under
e.g.
https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Wformat
or
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Warning-Options.html#index-Wformat
etc.

So, I think at least for the MAJOR.MINOR.0 releases we want to use
URLs like above rather than the trunk ones and we can use the same process
of updating *.opt.urls as well for that.

For the snapshots from release branches, we don't have such docs.
One option (implemented in the patch below for the URL printing side) is
point to the MAJOR.MINOR.0 docs even for MAJOR.MINOR.1 snapshots.
Most of the links will work fine, for options newly added on the release
branches (rare thing but still happens) can have until the next release
no URLs for them and get them with the next point release.
The question is what to do about make regenerate-opt-urls for the release
branch snapshots.  Either just document that users shouldn't
make regenerate-opt-urls on release branches (and filter out *.opt.urls
changes from their commits), add make regenerate-opt-urls task be RM
responsibility before making first release candidate from a branch and
adjust the autoregen CI to know about that.  Or add a separate goal
which instead of relying on make html created files would download
copy of the html files from the last release from web (kind of web
mirroring the https://gcc.gnu.org/onlinedocs/gcc-14.1.0/ subtree locally)
and doing regenerate-opt-urls on top of that?  But how to catch the
point when first release candidate is made and we want to update to
what will be the URLs once the release is made (but will be stale URLs
for a week or so)?

Another option would be to add to cron daily regeneration of the online
docs for the release branches.  I don't think that is a good idea though,
because as I wrote earlier, not all users update to the latest snapshot
frequently, so there can be users that use gcc 13.1.1 20230525 for months
or years, and other users which use gcc 13.1.1 20230615 for years etc.

Another question is what is most sensible for users who want to override
the default root and use the --with-documentation-root-url= configure
option.  Do we expect them to grab the whole onlinedocs tree or for release
branches at least include gcc-14.1.0/ subdirectory under the root?
If so, the patch below deals with that.  Or should we just change the
default documentation root url, so if user doesn't specify
--with-documentation-root-url= and we are on a release branch, default that
to https://gcc.gnu.org/onlinedocs/gcc-14.1.0/ or
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/ etc. and don't add any infix in
get_option_url/make_doc_url, but when people supply their own, let them
point to the root of the tree which contains the right docs?
Then such changes would go into gcc/configure.ac, some case based on
"$gcc_version", from that decide if it is a release branch or trunk.

2024-04-17  Jakub Jelinek  

PR other/114738
* opts.cc (get_option_url): On release branches append
gcc-MAJOR.MINOR.0/ after DOCUMENTATION_ROOT_URL.
* gcc-urlifier.cc (gcc_urlifier::make_doc_url): Likewise.

--- gcc/opts.cc.jj  2024-01-05 08:35:13.600828652 +0100
+++ gcc/opts.cc 2024-04-17 12:03:10.961525141 +0200
@@ -3761,7 +3761,19 @@ get_option_url (const diagnostic_context
 {
   label_text url_suffix = get_option_url_suffix (option_index, lang_mask);
   if (url_suffix.get ())
-   return concat (DOCUMENTATION_ROOT_URL, url_suffix.get (), nullptr);
+   {
+ char infix[32];
+ /* On release branches, append to DOCUMENTATION_ROOT_URL the
+subdirectory with documentation of the latest release made
+from the branch.  */
+ if (BUILDING_GCC_MINOR != 0 && BUILDING_GCC_PATCHLEVEL <= 1U)
+   s

[PATCH] Support {CEIL, FLOOR, ROUND}_{DIV, MOD}_EXPR and EXACT_DIV_EXPR in GIMPLE FE

[Richard Biener]

The following adds support for the various division and modulo operators
to the GIMPLE frontend via __{CEIL,FLOOR,ROUND}_{DIV,MOD} and
__EXACT_DIV operators.

Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for stage1.

Richard.

gcc/c/
* gimple-parser.cc (c_parser_gimple_binary_expression):
Parse __{CEIL,FLOOR,ROUND}_{DIV,MOD} and __EXACT_DIV.

gcc/testsuite/
* gcc.dg/gimplefe-53.c: New testcase.
---
 gcc/c/gimple-parser.cc | 35 ++
 gcc/testsuite/gcc.dg/gimplefe-53.c | 16 ++
 2 files changed, 51 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/gimplefe-53.c

diff --git a/gcc/c/gimple-parser.cc b/gcc/c/gimple-parser.cc
index 2dac41a335a..d156d83cd37 100644
--- a/gcc/c/gimple-parser.cc
+++ b/gcc/c/gimple-parser.cc
@@ -1055,6 +1055,41 @@ c_parser_gimple_binary_expression (gimple_parser 
&parser, tree ret_type)
code = LTGT_EXPR;
break;
  }
+   else if (strcmp (IDENTIFIER_POINTER (id), "__FLOOR_DIV") == 0)
+ {
+   code = FLOOR_DIV_EXPR;
+   break;
+ }
+   else if (strcmp (IDENTIFIER_POINTER (id), "__ROUND_DIV") == 0)
+ {
+   code = ROUND_DIV_EXPR;
+   break;
+ }
+   else if (strcmp (IDENTIFIER_POINTER (id), "__EXACT_DIV") == 0)
+ {
+   code = EXACT_DIV_EXPR;
+   break;
+ }
+   else if (strcmp (IDENTIFIER_POINTER (id), "__CEIL_DIV") == 0)
+ {
+   code = CEIL_DIV_EXPR;
+   break;
+ }
+   else if (strcmp (IDENTIFIER_POINTER (id), "__FLOOR_MOD") == 0)
+ {
+   code = FLOOR_MOD_EXPR;
+   break;
+ }
+   else if (strcmp (IDENTIFIER_POINTER (id), "__ROUND_MOD") == 0)
+ {
+   code = ROUND_MOD_EXPR;
+   break;
+ }
+   else if (strcmp (IDENTIFIER_POINTER (id), "__CEIL_MOD") == 0)
+ {
+   code = CEIL_MOD_EXPR;
+   break;
+ }
   }
   /* Fallthru.  */
 default:
diff --git a/gcc/testsuite/gcc.dg/gimplefe-53.c 
b/gcc/testsuite/gcc.dg/gimplefe-53.c
new file mode 100644
index 000..926c77c74d4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/gimplefe-53.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-fgimple" } */
+
+int __GIMPLE
+foo (int a, int b)
+{
+  int tem;
+  tem = a __EXACT_DIV b;
+  tem = tem __CEIL_DIV b;
+  tem = tem __FLOOR_DIV b;
+  tem = tem __ROUND_DIV b;
+  tem = tem __FLOOR_MOD b;
+  tem = tem __CEIL_MOD b;
+  tem = tem __ROUND_MOD b;
+  return tem;
+}
-- 
2.35.3

Re: [PATCH] c++: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

[Jakub Jelinek]

On Wed, Apr 17, 2024 at 11:04:26AM +0200, Jan Hubicka wrote:
> > The reason the optimization doesn't trigger when the constructor is
> > constexpr is that expand_or_defer_fn is called in that case much earlier
> > than when it is not constexpr; in the former case it is called when we
> > try to constant evaluate that constructor.  But DECL_INTERFACE_KNOWN
> > is false in that case and comdat_linkage hasn't been called either
> > (I think it is desirable, because comdat group is stored in the cgraph
> > node and am not sure it is a good idea to create cgraph nodes for
> > something that might not be needed later on at all), so maybe_clone_body
> > clones the bodies, but doesn't make them as aliases.
> 
> Thanks for working this out! Creating cgraph node with no body is
> harmless as it will be removed later.  

That is actually for functions with bodies, maybe_clone_body creates the
bodies for those, but still when it happens early, the cdtors have
tentative_decl_linkage linkage, which in many cases means DECL_EXTERNAL,
DECL_NOT_REALLY_EXTERN (C++ FE special thing), DECL_DEFER_OUTPUT etc.

> > +  tree comdat_group = cdtor_comdat_group (fns[1], fns[0]);
> > +  n1 = cgraph_node::get (fns[1]);
> > +  n0->set_comdat_group (comdat_group);
> > +  if (n1->same_comdat_group)
> > +n1->remove_from_same_comdat_group ();
> > +  n1->add_to_same_comdat_group (n0);
> > +  if (fns[2])
> > +n2->add_to_same_comdat_group (n0);
> > +  import_export_decl (fns[1]);
> 
> So this is handling the case where symbol was already inserted into one
> comdat group and later we need to move it into the C5 group?  As long as
> we move everythingf rom old comdat group, this should be fine.

The above is pretty much an adjusted copy of what maybe_clone_body does,
except it doesn't call cgraph_node::get{,_create} all the time and uses
import_export_decl rather than expand_or_defer_fn{,_1}.

> > +  /* Remove the body now that it is an alias.  */
> > +  DECL_SAVED_TREE (fns[1]) = NULL_TREE;
> Maybe using release_function_body since it also knows how to remove
> DECL_STRUCT_FUNCTION that exists at this stage?

Guess I could try that, clearing of DECL_SAVED_TREE was what was done
in maybe_clone_body too.

> I was thinking how to solve the problem on cgrpah side.  We definitely
> have long lasting bug where aliases are handled incorrectly for which I
> made WIP patch (but probably would like to hold it after release branch is
> created).  When foo has alias bar and foo is praviled then the alias
> target is prevailed too.  This is what causes the ICE about cross comdat
> section alias.  However fixing this is not enough as I do not think we
> can handle incremental linking correctly (as discussed briefly on IRC
> technically we should keep both sections but that would require two
> symbols of same name in single .o file).
> 
> With the aliasing fixed we turn the other symbol into static but keep
> alias, so we end up with one comdat group having the non-aliased
> constructor and second comdat group (C5) exporting only the alias, which
> is not quite reight either.

I've tried to see what actually happens during linking without LTO, so compiled
pr113208_0.C with -O1 -fkeep-inline-functions -std=c++20 with vanilla trunk
(so it has those 2 separate comdats, one for C2 and one for C1), though I've
changed the
void m(k);
line to
__attribute__((noipa)) void m(k) {}
in the testcase, then compiled
pr113208_1.C with -O2 -fkeep-inline-functions -std=c++20 -fno-omit-frame-pointer
so that one can clearly differentiate from where the implementation was
picked and finally added
template  struct _Vector_base {
  int g() const;
  _Vector_base(int, int);
};

struct QualityValue;
template <>
_Vector_base::_Vector_base(int, int) {}
template <>
int _Vector_base::g() const { return 0; }
int main () {}
If I link this, I see _ZN6vectorI12QualityValueEC2ERKS1_ and
_ZN6vectorI12QualityValueEC1ERKS1_ as separate functions with the
omitted frame pointer bodies, so clearly the pr113208_0.C versions prevailed
in both cases.  It is unclear why that isn't the case for LTO.

Jakub

Re: [PATCH] DOCUMENTATION_ROOT_URL vs. release branches [PR114738]

[Richard Biener]

On Wed, Apr 17, 2024 at 1:17 PM Jakub Jelinek  wrote:
>
> Hi!
>
> Starting with GCC 14 we have the nice URLification of the options printed
> in diagnostics, say for in
> test.c:4:23: warning: format ‘%d’ expects argument of type ‘int’, but 
> argument 2 has type ‘long int’ [-Wformat=]
> the -Wformat= is underlined in some terminals and hovering on it shows
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat
> link.
>
> This works nicely on the GCC trunk, where the online documentation is
> regenerated every day from a cron job and more importantly, people rarely
> use the trunk snapshots for too long, so it is unlikely that further changes
> in the documentation will make too many links stale, because users will
> simply regularly update to newer snapshots.
>
> I think it doesn't work properly on release branches though.
> Some users only use the relased versions (i.e. MAJOR.MINOR.0) from tarballs
> but can use them for a couple of years, others use snapshots from the
> release branches, but again they could be in use for months or years and
> the above mentioned online docs which represent just the GCC trunk might
> diverge significantly.
>
> Now, for the relases we always publish also online docs for the release,
> which unlike the trunk online docs will not change further, under
> e.g.
> https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Wformat
> or
> https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Warning-Options.html#index-Wformat
> etc.
>
> So, I think at least for the MAJOR.MINOR.0 releases we want to use
> URLs like above rather than the trunk ones and we can use the same process
> of updating *.opt.urls as well for that.
>
> For the snapshots from release branches, we don't have such docs.
> One option (implemented in the patch below for the URL printing side) is
> point to the MAJOR.MINOR.0 docs even for MAJOR.MINOR.1 snapshots.
> Most of the links will work fine, for options newly added on the release
> branches (rare thing but still happens) can have until the next release
> no URLs for them and get them with the next point release.
> The question is what to do about make regenerate-opt-urls for the release
> branch snapshots.  Either just document that users shouldn't
> make regenerate-opt-urls on release branches (and filter out *.opt.urls
> changes from their commits), add make regenerate-opt-urls task be RM
> responsibility before making first release candidate from a branch and
> adjust the autoregen CI to know about that.  Or add a separate goal
> which instead of relying on make html created files would download
> copy of the html files from the last release from web (kind of web
> mirroring the https://gcc.gnu.org/onlinedocs/gcc-14.1.0/ subtree locally)
> and doing regenerate-opt-urls on top of that?  But how to catch the
> point when first release candidate is made and we want to update to
> what will be the URLs once the release is made (but will be stale URLs
> for a week or so)?
>
> Another option would be to add to cron daily regeneration of the online
> docs for the release branches.  I don't think that is a good idea though,
> because as I wrote earlier, not all users update to the latest snapshot
> frequently, so there can be users that use gcc 13.1.1 20230525 for months
> or years, and other users which use gcc 13.1.1 20230615 for years etc.
>
> Another question is what is most sensible for users who want to override
> the default root and use the --with-documentation-root-url= configure
> option.  Do we expect them to grab the whole onlinedocs tree or for release
> branches at least include gcc-14.1.0/ subdirectory under the root?
> If so, the patch below deals with that.  Or should we just change the
> default documentation root url, so if user doesn't specify
> --with-documentation-root-url= and we are on a release branch, default that
> to https://gcc.gnu.org/onlinedocs/gcc-14.1.0/ or
> https://gcc.gnu.org/onlinedocs/gcc-14.2.0/ etc. and don't add any infix in
> get_option_url/make_doc_url, but when people supply their own, let them
> point to the root of the tree which contains the right docs?
> Then such changes would go into gcc/configure.ac, some case based on
> "$gcc_version", from that decide if it is a release branch or trunk.

I think this patch is sensible and an improvement over the current situation.
I guess we'll have to see how things evolve on the branch and adapt.

So, OK.

Thanks,
Richard.

> 2024-04-17  Jakub Jelinek  
>
> PR other/114738
> * opts.cc (get_option_url): On release branches append
> gcc-MAJOR.MINOR.0/ after DOCUMENTATION_ROOT_URL.
> * gcc-urlifier.cc (gcc_urlifier::make_doc_url): Likewise.
>
> --- gcc/opts.cc.jj  2024-01-05 08:35:13.600828652 +0100
> +++ gcc/opts.cc 2024-04-17 12:03:10.961525141 +0200
> @@ -3761,7 +3761,19 @@ get_option_url (const diagnostic_context
>  {
>label_text url_suffix = get_option_url_suffix (option_index, 
> lang_mask);
>   

Re: [PATCH] c++: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

[Jan Hubicka]

> 
> I've tried to see what actually happens during linking without LTO, so 
> compiled
> pr113208_0.C with -O1 -fkeep-inline-functions -std=c++20 with vanilla trunk
> (so it has those 2 separate comdats, one for C2 and one for C1), though I've
> changed the
> void m(k);
> line to
> __attribute__((noipa)) void m(k) {}
> in the testcase, then compiled
> pr113208_1.C with -O2 -fkeep-inline-functions -std=c++20 
> -fno-omit-frame-pointer
> so that one can clearly differentiate from where the implementation was
> picked and finally added
> template  struct _Vector_base {
>   int g() const;
>   _Vector_base(int, int);
> };
> 
> struct QualityValue;
> template <>
> _Vector_base::_Vector_base(int, int) {}
> template <>
> int _Vector_base::g() const { return 0; }
> int main () {}
> If I link this, I see _ZN6vectorI12QualityValueEC2ERKS1_ and
> _ZN6vectorI12QualityValueEC1ERKS1_ as separate functions with the
> omitted frame pointer bodies, so clearly the pr113208_0.C versions prevailed
> in both cases.  It is unclear why that isn't the case for LTO.

I think it is because of -fkeep-inline-functions which makes the first
object file to define both symbols, while with LTO we optimize out one
of them.  

So to reproduce same behaviour with non-LTO we would probably need use
-O1 and arrange the contructor to be unilinable instead of using
-fkeep-inline-functions.

Honza

Re: Request for testing on non-Linux targets; remove special casing of /usr/lib and /lib from the driver

[Rainer Orth]

Hi Andrew,

>   The driver currently will remove "/lib" and "/usr/lib" from the library
> path that gets passed to the linker because it considers them as paths that
> the linker will already known to search. But this is not true for newer
> linkers, mold and lld for an example don't have a default search path.
> This patch removes the special casing to fix FreeBSD building where lld is
> used by default and also fix riscv-linux-gnu when used in combination with
> mold.
> I have tested it on x86_64-linux-gnu and it works there but since the code
> in the driver has been around since 1992, I request some folks to test it
> on AIX, Mac OS (Darwin) and solaris where the ld is not GNU bfd ld as I
> don't have access to those targets currently.

actually, you do: all of those are availble inside the cfarm.

I've also tested the patch on i386-pc-solaris2.11 and
sparc-sun-solaris2.11 with the native ld: no regressions in either case.

>From what I can see, the handling of -Y P,* in gcc/config/sol2.h
(LINK_ARCH{32,64}_SPEC_BASE) can go as well.  I'll test this, but this
is almost certainly GCC 15 material.

Rainer

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

[PATCH] libcpp: Regenerate aclocal.m4 and configure [PR 114748]

[Christophe Lyon]

As discussed in the PR, aclocal.m4 and configure were incorrectly
regenerated at some point.

2024-04-17  Christophe Lyon  

PR preprocessor/114748
libcpp/
* aclocal.m4: Regenerate.
* configure: Regenerate.
---
 libcpp/aclocal.m4 | 1 +
 libcpp/configure  | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/libcpp/aclocal.m4 b/libcpp/aclocal.m4
index 4fc81709622..4d898ea2c97 100644
--- a/libcpp/aclocal.m4
+++ b/libcpp/aclocal.m4
@@ -26,6 +26,7 @@ m4_include([../config/lib-ld.m4])
 m4_include([../config/lib-link.m4])
 m4_include([../config/lib-prefix.m4])
 m4_include([../config/nls.m4])
+m4_include([../config/override.m4])
 m4_include([../config/po.m4])
 m4_include([../config/progtest.m4])
 m4_include([../config/warnings.m4])
diff --git a/libcpp/configure b/libcpp/configure
index 8a38c0546e3..32d6aaa3069 100755
--- a/libcpp/configure
+++ b/libcpp/configure
@@ -2670,6 +2670,9 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 
 
+
+
+
 ac_aux_dir=
 for ac_dir in "$srcdir" "$srcdir/.." "$srcdir/../.."; do
   if test -f "$ac_dir/install-sh"; then
-- 
2.34.1

Re: [PATCH] libcpp: Regenerate aclocal.m4 and configure [PR 114748]

[Jakub Jelinek]

On Wed, Apr 17, 2024 at 02:01:55PM +, Christophe Lyon wrote:
> As discussed in the PR, aclocal.m4 and configure were incorrectly
> regenerated at some point.
> 
> 2024-04-17  Christophe Lyon  
> 
>   PR preprocessor/114748
>   libcpp/
>   * aclocal.m4: Regenerate.
>   * configure: Regenerate.

Ok, thanks.

Jakub

Re: [PATCH] c++: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

[Jakub Jelinek]

On Wed, Apr 17, 2024 at 03:26:53PM +0200, Jan Hubicka wrote:
> > 
> > I've tried to see what actually happens during linking without LTO, so 
> > compiled
> > pr113208_0.C with -O1 -fkeep-inline-functions -std=c++20 with vanilla trunk
> > (so it has those 2 separate comdats, one for C2 and one for C1), though I've
> > changed the
> > void m(k);
> > line to
> > __attribute__((noipa)) void m(k) {}
> > in the testcase, then compiled
> > pr113208_1.C with -O2 -fkeep-inline-functions -std=c++20 
> > -fno-omit-frame-pointer
> > so that one can clearly differentiate from where the implementation was
> > picked and finally added
> > template  struct _Vector_base {
> >   int g() const;
> >   _Vector_base(int, int);
> > };
> > 
> > struct QualityValue;
> > template <>
> > _Vector_base::_Vector_base(int, int) {}
> > template <>
> > int _Vector_base::g() const { return 0; }
> > int main () {}
> > If I link this, I see _ZN6vectorI12QualityValueEC2ERKS1_ and
> > _ZN6vectorI12QualityValueEC1ERKS1_ as separate functions with the
> > omitted frame pointer bodies, so clearly the pr113208_0.C versions prevailed
> > in both cases.  It is unclear why that isn't the case for LTO.
> 
> I think it is because of -fkeep-inline-functions which makes the first
> object file to define both symbols, while with LTO we optimize out one
> of them.  
> 
> So to reproduce same behaviour with non-LTO we would probably need use
> -O1 and arrange the contructor to be unilinable instead of using
> -fkeep-inline-functions.

Ah, you're right.
If I compile (the one line modified) pr113208_0.C with
-O -fno-early-inlining -fdisable-ipa-inline -std=c++20
it does have just _ZN6vectorI12QualityValueEC2ERKS1_ in 
_ZN6vectorI12QualityValueEC2ERKS1_
comdat and no _ZN6vectorI12QualityValueEC1ERKS1_
and pr113208_1.C with -O -fno-early-inlining -fdisable-ipa-inline -std=c++20 
-fno-omit-frame-pointer
and link that together with the above mentioned third *.C file, I see
0040112a <_ZN6vectorI12QualityValueEC2ERKS1_>:
  40112a:   53  push   %rbx
  40112b:   48 89 fbmov%rdi,%rbx
  40112e:   48 89 f7mov%rsi,%rdi
  401131:   e8 9c 00 00 00  call   4011d2 
<_ZNK12_Vector_baseI12QualityValueE1gEv>
  401136:   89 c2   mov%eax,%edx
  401138:   be 01 00 00 00  mov$0x1,%esi
  40113d:   48 89 dfmov%rbx,%rdi
  401140:   e8 7b 00 00 00  call   4011c0 
<_ZN12_Vector_baseI12QualityValueEC1Eii>
  401145:   5b  pop%rbx
  401146:   c3  ret
i.e. the C2 prevailing from pr113208_0.s where it is the only symbol, and
00401196 <_ZN6vectorI12QualityValueEC1ERKS1_>:
  401196:   55  push   %rbp
  401197:   48 89 e5mov%rsp,%rbp
  40119a:   53  push   %rbx
  40119b:   48 83 ec 08 sub$0x8,%rsp
  40119f:   48 89 fbmov%rdi,%rbx
  4011a2:   48 89 f7mov%rsi,%rdi
  4011a5:   e8 28 00 00 00  call   4011d2 
<_ZNK12_Vector_baseI12QualityValueE1gEv>
  4011aa:   89 c2   mov%eax,%edx
  4011ac:   be 01 00 00 00  mov$0x1,%esi
  4011b1:   48 89 dfmov%rbx,%rdi
  4011b4:   e8 07 00 00 00  call   4011c0 
<_ZN12_Vector_baseI12QualityValueEC1Eii>
  4011b9:   48 8b 5d f8 mov-0x8(%rbp),%rbx
  4011bd:   c9  leave  
  4011be:   c3  ret
which is the C1 alias originally aliased to C2 in C5 comdat.
So, that would match linker behavior where it sees C1 -> C2 alias prevails,
but a different version of C2 prevails, so let's either make C1 a non-alias
or alias to a non-exported symbol or something like that.
Though, I admit I have no idea what we do with comdat's during LTO, perhaps
doing what I said above could break stuff if linker after seeing the LTO
resulting objects decides on prevailing symbols differently.

Jakub

Re: Request for testing on non-Linux targets; remove special casing of /usr/lib and /lib from the driver

[Iain Sandoe]

Hi Andrew,

> On 17 Apr 2024, at 14:59, Rainer Orth  wrote:

>>  The driver currently will remove "/lib" and "/usr/lib" from the library
>> path that gets passed to the linker because it considers them as paths that
>> the linker will already known to search. But this is not true for newer
>> linkers, mold and lld for an example don't have a default search path.
>> This patch removes the special casing to fix FreeBSD building where lld is
>> used by default and also fix riscv-linux-gnu when used in combination with
>> mold.
>> I have tested it on x86_64-linux-gnu and it works there but since the code
>> in the driver has been around since 1992, I request some folks to test it
>> on AIX, Mac OS (Darwin) and solaris where the ld is not GNU bfd ld as I
>> don't have access to those targets currently.
> 
> actually, you do: all of those are availble inside the cfarm.
> 
> I've also tested the patch on i386-pc-solaris2.11 and
> sparc-sun-solaris2.11 with the native ld: no regressions in either case.

I tested so far on x86_64 darwin, but the behaviour of collect2 is the same
for all arches.  Actually, I do not see any difference in behaviour when looking
at the -Wl,-v output (it seems that somehow those paths are not currently
pruned for Darwin; if I add -L /lib to the command line on a GCC build without
this patch it is passed through despite that it’s non-existent).  However, 
that’s
a separate bug, perhaps.

So - as far as this patch is concerned it seems OK for Darwin,
Iain

Re: [PATCH] c++: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

[Jan Hubicka]

> 
> Ah, you're right.
> If I compile (the one line modified) pr113208_0.C with
> -O -fno-early-inlining -fdisable-ipa-inline -std=c++20
> it does have just _ZN6vectorI12QualityValueEC2ERKS1_ in 
> _ZN6vectorI12QualityValueEC2ERKS1_
> comdat and no _ZN6vectorI12QualityValueEC1ERKS1_
> and pr113208_1.C with -O -fno-early-inlining -fdisable-ipa-inline -std=c++20 
> -fno-omit-frame-pointer
> and link that together with the above mentioned third *.C file, I see
> 0040112a <_ZN6vectorI12QualityValueEC2ERKS1_>:
>   40112a:   53  push   %rbx
>   40112b:   48 89 fbmov%rdi,%rbx
>   40112e:   48 89 f7mov%rsi,%rdi
>   401131:   e8 9c 00 00 00  call   4011d2 
> <_ZNK12_Vector_baseI12QualityValueE1gEv>
>   401136:   89 c2   mov%eax,%edx
>   401138:   be 01 00 00 00  mov$0x1,%esi
>   40113d:   48 89 dfmov%rbx,%rdi
>   401140:   e8 7b 00 00 00  call   4011c0 
> <_ZN12_Vector_baseI12QualityValueEC1Eii>
>   401145:   5b  pop%rbx
>   401146:   c3  ret
> i.e. the C2 prevailing from pr113208_0.s where it is the only symbol, and
> 00401196 <_ZN6vectorI12QualityValueEC1ERKS1_>:
>   401196:   55  push   %rbp
>   401197:   48 89 e5mov%rsp,%rbp
>   40119a:   53  push   %rbx
>   40119b:   48 83 ec 08 sub$0x8,%rsp
>   40119f:   48 89 fbmov%rdi,%rbx
>   4011a2:   48 89 f7mov%rsi,%rdi
>   4011a5:   e8 28 00 00 00  call   4011d2 
> <_ZNK12_Vector_baseI12QualityValueE1gEv>
>   4011aa:   89 c2   mov%eax,%edx
>   4011ac:   be 01 00 00 00  mov$0x1,%esi
>   4011b1:   48 89 dfmov%rbx,%rdi
>   4011b4:   e8 07 00 00 00  call   4011c0 
> <_ZN12_Vector_baseI12QualityValueEC1Eii>
>   4011b9:   48 8b 5d f8 mov-0x8(%rbp),%rbx
>   4011bd:   c9  leave  
>   4011be:   c3  ret
> which is the C1 alias originally aliased to C2 in C5 comdat.
> So, that would match linker behavior where it sees C1 -> C2 alias prevails,
> but a different version of C2 prevails, so let's either make C1 a non-alias
> or alias to a non-exported symbol or something like that.

Yep, I think the linker simply handles the C2 symbol as weak symbol and
after it decides to keep both comdat section (C2 and C5) the C5's weak
symbol is prevailed by C2.

I wrote patch doing the same with LTO - we need to handle alias
references specially and do not update them according to the resolution
info and then look for prevailed symbols which have aliases and turn
them to static symbols.  

I think for most scenarios this is OK, but I am not sure about
incremental linking (both LTO and non-LTO). What seems wrong is that we
produce C5 comdat that is not exporting what it should and thus breaking
the invariant that in valid code all comdats of same name are
semantically equivalent.  Perhaps it makes no difference since this
scenario is pretty special and we know that the functions are
semantically equivalent and their addresses are never compared for
equality (at least I failed to produce some useful testcase).

Honza

Re: [PATCH] c++: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

[Jakub Jelinek]

On Wed, Apr 17, 2024 at 04:34:07PM +0200, Jan Hubicka wrote:
> I think for most scenarios this is OK, but I am not sure about
> incremental linking (both LTO and non-LTO). What seems wrong is that we
> produce C5 comdat that is not exporting what it should and thus breaking
> the invariant that in valid code all comdats of same name are
> semantically equivalent.

Yeah, exactly.  That is what I'm worried about too.

>  Perhaps it makes no difference since this
> scenario is pretty special and we know that the functions are
> semantically equivalent and their addresses are never compared for
> equality (at least I failed to produce some useful testcase).

Yes, I think one can't take address of a constructor/destructor and compare
that for equality; I guess the destructor address can be stored in vtables,
but code manually reading stuff from vtables and assuming pointer equality
is almost certainly not valid.

Jakub

Re: [PATCH] build: Check for cargo when building rust language

[Arthur Cohen]

Hi Rainer!

On 4/17/24 10:13, Rainer Orth wrote:

Andrew Pinski  writes:


On Mon, Apr 8, 2024 at 9:39 AM  wrote:


From: Pierre-Emmanuel Patry 

Hello,

The rust frontend requires cargo to build some of it's components,
it's presence was not checked during configuration.


WHY did this go in right before the release of GCC 14?
I don't get why this is considered temporary and it goes in right
before a release.
That seems broken to me.


two more questions about this:

Right now, the new cargo configure test disable rust on all of my
targets (Solaris, Linux, Darwin) which didn't have it installed.  Before
(as recent as last Friday), I could successfully build and test
crab1/rust on all of them without cargo in sight.  So I wonder if the
patch isn't premature.


We already have components depending on Rust libraries in our 
development repository, so this patch is important to ensure errors are 
emitted early during the configure phase rather than later at build 
time. I don't think this is premature, considering that your targets 
would fail to build the Rust frontend next time we upstream commits, 
which should happen this week or early next week.



Besides, while there are packaged versions of cargo for Solaris 11.4 and
Linux, Darwin hasn't anything (not checked Homebrew or similar yet).
What's worse, rustup only supports macOS 10.12 and up, while I'm still
regularly testing 10.7 and 10.11.  I don't really feel like building
rust from source here (if it works at all).  This hasn't been an issue
for any other languages that require additional tools for bootstrapping
(like Ada or D): there are versions of GNAT around that still support
those old Darwin releases, and I could use the C++ version of GDC in GCC
11.


Sorry, I'm not too familiar with the Rust situation on macOS. I am 
reading that starting from Rust version 1.74, the minimum macOS version 
required is indeed 10.12, released in 2016 I believe?


We currently depend on Rust version 1.72, so you should be able to 
install it on macOS 10.11. Maybe with rustup? You can try something like 
the following:


curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y 
--default-toolchain=1.72.0;


which is the default installation method for Rustup, with version 1.72 
of the language specified. I'm not able to test this, sorry, but I'm 
very interested in knowing if it works. I think you can also install 
Rust using Homebrew, but again I am not able to test this and apologize.


The goal is to reduce that Rust version further soon anyway - we are 
going to target Rust version 1.49, released 3 years ago, as that is the 
version that gccrs aims to compile. This will bring us closer to 
compiling our dependencies with our own frontend.



At the very least, the Rust situation needs to be documented clearly.


I'd love to work on this - what sort of documentation do you have in 
mind? Do you mean something like the online GCC documentation or an 
in-tree file? Let me know what you'd like me to add and I'll be happy to 
do so.




Rainer



Kindly,

Arthur

Re: [PATCH 1/3] bpf: support more instructions to match CO-RE relocations

[Jose E. Marchesi]

Hi Cupertino.
OK for master.
Thanks!

> BPF supports multiple instructions to be CO-RE relocatable regardless of
> the position of the immediate field in the encoding.
> In particular, not only the MOV instruction allows a CO-RE
> relocation of its immediate operand, but the LD and ST instructions can
> have a CO-RE relocation happening to their offset immediate operand,
> even though those operands are encoded in different encoding bits.
> This patch moves matching from a more traditional matching of the
> UNSPEC_CORE_RELOC pattern within a define_insn to a match within the
> constraints of both immediates and address operands from more generic
> mov define_insn rule.
>
> gcc/Changelog:
>   * config/bpf/bpf-protos.h (bpf_add_core_reloc): Renamed function
>   to bpf_output_move.
>   * config/bpf/bpf.cc (bpf_legitimate_address_p): Allow
>   UNSPEC_CORE_RELOC to match an address.
>   (bpf_insn_cost): Make UNSPEC_CORE_RELOC immediate moves
>   expensive to prioritize loads and stores.
>   (TARGET_INSN_COST): Add hook.
>   (bpf_output_move): Wrapper to call bpf_output_core_reloc.
>   (bpf_print_operand): Add support to print immediate operands
>   specified with the UNSPEC_CORE_RELOC.
>   (bpf_print_operand_address): Likewise, but to support
>   UNSPEC_CORE_RELOC in addresses.
>   (bpf_init_builtins): Flag BPF_BUILTIN_CORE_RELOC as NOTHROW.
>   * config/bpf/bpf.md: Wrap patterns for MOV, LD and ST
>   instruction with bpf_output_move call.
>   (mov_reloc_core): Remove now spurious define_insn.
>   * config/bpf/constraints.md: Added "c" and "C" constraints to
>   match immediates represented with UNSPEC_CORE_RELOC.
>   * config/bpf/core-builtins.cc (bpf_add_core_reloc): Remove
>   (bpf_output_core_reloc): Add function to create the CO-RE
>   relocations based on new matching rules.
>   * config/bpf/core-builtins.h (bpf_output_core_reloc): Add
>   prototype.
>   * config/bpf/predicates.md (core_imm_operand) Add predicate.
>   (mov_src_operand): Add match for core_imm_operand.
>
> gcc/testsuite/ChangeLog:
>   * gcc.target/bpf/btfext-funcinfo.c: Updated to changes.
>   * gcc.target/bpf/core-builtin-fieldinfo-const-elimination.c:
>   Likewise.
>   * gcc.target/bpf/core-builtin-fieldinfo-existence-1.c: Likewise.
>   * gcc.target/bpf/core-builtin-fieldinfo-lshift-1-be.c: Likewise.
>   * gcc.target/bpf/core-builtin-fieldinfo-lshift-1-le.c: Likewise.
>   * gcc.target/bpf/core-builtin-fieldinfo-lshift-2.c: Likewise.
>   * gcc.target/bpf/core-builtin-fieldinfo-offset-1.c: Likewise.
>   * gcc.target/bpf/core-builtin-fieldinfo-rshift-1.c: Likewise.
>   * gcc.target/bpf/core-builtin-fieldinfo-rshift-2.c: Likewise.
>   * gcc.target/bpf/core-builtin-fieldinfo-sign-1.c: Likewise.
>   * gcc.target/bpf/core-builtin-fieldinfo-sign-2.c: Likewise.
>   * gcc.target/bpf/core-builtin-fieldinfo-size-1.c: Likewise.
> ---
>  gcc/config/bpf/bpf-protos.h   |  2 +-
>  gcc/config/bpf/bpf.cc | 54 +-
>  gcc/config/bpf/bpf.md | 56 ++-
>  gcc/config/bpf/constraints.md | 20 ++
>  gcc/config/bpf/core-builtins.cc   | 71 ++-
>  gcc/config/bpf/core-builtins.h|  2 +
>  gcc/config/bpf/predicates.md  |  7 +-
>  .../gcc.target/bpf/btfext-funcinfo.c  |  2 -
>  ...core-builtin-fieldinfo-const-elimination.c |  2 +-
>  .../bpf/core-builtin-fieldinfo-existence-1.c  |  2 +-
>  .../bpf/core-builtin-fieldinfo-lshift-1-be.c  |  8 +--
>  .../bpf/core-builtin-fieldinfo-lshift-1-le.c  |  8 +--
>  .../bpf/core-builtin-fieldinfo-lshift-2.c |  6 +-
>  .../bpf/core-builtin-fieldinfo-offset-1.c | 12 ++--
>  .../bpf/core-builtin-fieldinfo-rshift-1.c |  8 +--
>  .../bpf/core-builtin-fieldinfo-rshift-2.c |  4 +-
>  .../bpf/core-builtin-fieldinfo-sign-1.c   |  4 +-
>  .../bpf/core-builtin-fieldinfo-sign-2.c   |  4 +-
>  .../bpf/core-builtin-fieldinfo-size-1.c   |  8 +--
>  19 files changed, 189 insertions(+), 91 deletions(-)
>
> diff --git a/gcc/config/bpf/bpf-protos.h b/gcc/config/bpf/bpf-protos.h
> index ac0c2f4038f..b4866d34209 100644
> --- a/gcc/config/bpf/bpf-protos.h
> +++ b/gcc/config/bpf/bpf-protos.h
> @@ -30,7 +30,7 @@ extern void bpf_print_operand_address (FILE *, rtx);
>  extern void bpf_expand_prologue (void);
>  extern void bpf_expand_epilogue (void);
>  extern void bpf_expand_cbranch (machine_mode, rtx *);
> -const char *bpf_add_core_reloc (rtx *operands, const char *templ);
> +const char *bpf_output_move (rtx *operands, const char *templ);
>  
>  class gimple_opt_pass;
>  gimple_opt_pass *make_pass_lower_bpf_core (gcc::context *ctxt);
> diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
> index fb60770c170..d9141dd625a 100644
> --- a/gcc/config/bpf/bpf.cc
> +++ b/gcc/config/bpf/bpf.cc
> @@ -584,6 +584

Re: [PATCH v2 1/2] c++: Standardise errors for module_may_redeclare

[Patrick Palka]

On Mon, 15 Apr 2024, Nathaniel Shead wrote:

> I took another look at this patch and have split it into two, one (this
> one) to standardise the error messages used and prepare
> 'module_may_redeclare' for use with temploid friends, and another
> followup patch to actually handle them correctly.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?

LGTM

> 
> -- >8 --
> 
> Currently different places calling 'module_may_redeclare' all emit very
> similar but slightly different error messages, and handle different
> kinds of declarations differently.  This patch makes the function
> perform its own error messages so that they're all in one place, and
> prepares it for use with temploid friends (PR c++/114275).
> 
> gcc/cp/ChangeLog:
> 
>   * cp-tree.h (module_may_redeclare): Add default parameter.
>   * decl.cc (duplicate_decls): Don't emit errors for failed
>   module_may_redeclare.
>   (xref_tag): Likewise.
>   (start_enum): Likewise.
>   * semantics.cc (begin_class_definition): Likewise.
>   * module.cc (module_may_redeclare): Clean up logic. Emit error
>   messages on failure.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/modules/enum-12.C: Update error message.
>   * g++.dg/modules/friend-5_b.C: Likewise.
>   * g++.dg/modules/shadow-1_b.C: Likewise.
> 
> Signed-off-by: Nathaniel Shead 
> ---
>  gcc/cp/cp-tree.h  |   2 +-
>  gcc/cp/decl.cc|  28 +
>  gcc/cp/module.cc  | 120 ++
>  gcc/cp/semantics.cc   |   6 +-
>  gcc/testsuite/g++.dg/modules/enum-12.C|   2 +-
>  gcc/testsuite/g++.dg/modules/friend-5_b.C |   2 +-
>  gcc/testsuite/g++.dg/modules/shadow-1_b.C |   5 +-
>  7 files changed, 89 insertions(+), 76 deletions(-)
> 
> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> index 1dbb577a38d..faa7a0052a5 100644
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -7401,7 +7401,7 @@ inline bool module_exporting_p ()
>  
>  extern module_state *get_module (tree name, module_state *parent = NULL,
>bool partition = false);
> -extern bool module_may_redeclare (tree decl);
> +extern bool module_may_redeclare (tree olddecl, tree newdecl = NULL);
>  
>  extern bool module_global_init_needed ();
>  extern bool module_determine_import_inits ();
> diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
> index 65ab64885ff..aa66da4829d 100644
> --- a/gcc/cp/decl.cc
> +++ b/gcc/cp/decl.cc
> @@ -2279,18 +2279,8 @@ duplicate_decls (tree newdecl, tree olddecl, bool 
> hiding, bool was_hidden)
>&& TREE_CODE (olddecl) != NAMESPACE_DECL
>&& !hiding)
>  {
> -  if (!module_may_redeclare (olddecl))
> - {
> -   if (DECL_ARTIFICIAL (olddecl))
> - error ("declaration %qD conflicts with builtin", newdecl);
> -   else
> - {
> -   error ("declaration %qD conflicts with import", newdecl);
> -   inform (olddecl_loc, "import declared %q#D here", olddecl);
> - }
> -
> -   return error_mark_node;
> - }
> +  if (!module_may_redeclare (olddecl, newdecl))
> + return error_mark_node;
>  
>tree not_tmpl = STRIP_TEMPLATE (olddecl);
>if (DECL_LANG_SPECIFIC (not_tmpl)
> @@ -16620,12 +16610,7 @@ xref_tag (enum tag_types tag_code, tree name,
>   {
> tree decl = TYPE_NAME (t);
> if (!module_may_redeclare (decl))
> - {
> -   auto_diagnostic_group d;
> -   error ("cannot declare %qD in a different module", decl);
> -   inform (DECL_SOURCE_LOCATION (decl), "previously declared here");
> -   return error_mark_node;
> - }
> + return error_mark_node;
>  
> tree not_tmpl = STRIP_TEMPLATE (decl);
> if (DECL_LANG_SPECIFIC (not_tmpl)
> @@ -16973,12 +16958,7 @@ start_enum (tree name, tree enumtype, tree 
> underlying_type,
>   {
> tree decl = TYPE_NAME (enumtype);
> if (!module_may_redeclare (decl))
> - {
> -   auto_diagnostic_group d;
> -   error ("cannot declare %qD in different module", decl);
> -   inform (DECL_SOURCE_LOCATION (decl), "previously declared here");
> -   enumtype = error_mark_node;
> - }
> + enumtype = error_mark_node;
> else
>   set_instantiating_module (decl);
>   }
> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> index 001430a4a8f..e2d2910ae48 100644
> --- a/gcc/cp/module.cc
> +++ b/gcc/cp/module.cc
> @@ -18992,11 +18992,15 @@ get_importing_module (tree decl, bool flexible)
>return module->mod;
>  }
>  
> -/* Is it permissible to redeclare DECL.  */
> +/* Is it permissible to redeclare OLDDECL with NEWDECL.
> +
> +   If NEWDECL is NULL, assumes that OLDDECL will be redeclared using
> +   the current scope's module and attachment.  */
>  
>  bool
> -module_may_redeclare (tree decl)
> +module_may_redeclare (tree olddecl, tree newdecl)
>  

Re: [PATCH 3/3] bpf: add line_info support to BTF.ext section.

[Jose E. Marchesi]

Hi Cuper.
Thanks for the patch.

> This patch adds line_info debug information support to .BTF.ext
> sections.
> Line info information is used by the BPF verifier to improve error
> reporting and give more precise source core referenced errors.
>
> gcc/Changelog:
>   * config/bpf/bpf-protos.h (bpf_output_call): Change prototype.
>   * config/bpf/bpf.cc (bpf_output_call): Change to adapt operands
>   and return
>   the instruction template instead of emmidiatelly emit asm and
>   not allow proper final expected execution flow.
>   (bpf_output_line_info): Add function to introduce line info
>   entries in respective structures
>   (bpf_asm_out_unwind_emit): Add function as hook to
>   TARGET_ASM_UNWIND_EMIT. This hook is called before any
>   instruction is emitted.

Is it actually necessary to emit a label (plus .BTF.ext entry) for every
instruction?

>   * config/bpf/bpf.md: Change calls to bpf_output_call.
>   * config/bpf/btfext-out.cc (struct btf_ext_lineinfo): Add fields
>   to struct.
>   (bpf_create_lineinfo, btf_add_line_info_for): Add support
>   function to insert line_info data in respective structures.
>   (output_btfext_line_info): Function to emit line_info data in
>   .BTF.ext section.
>   (btf_ext_output): Call output_btfext_line_info.
>   * config/bpf/btfext-out.h: Add prototype for
>   btf_add_line_info_for.
> ---
>  gcc/config/bpf/bpf-protos.h   |   2 +-
>  gcc/config/bpf/bpf.cc | 103 ++---
>  gcc/config/bpf/bpf.md |   4 +-
>  gcc/config/bpf/btfext-out.cc  | 108 +-
>  gcc/config/bpf/btfext-out.h   |   4 +
>  .../gcc.target/bpf/btfext-funcinfo.c  |   3 +-
>  6 files changed, 203 insertions(+), 21 deletions(-)
>
> diff --git a/gcc/config/bpf/bpf-protos.h b/gcc/config/bpf/bpf-protos.h
> index b4866d34209..ddaca50af69 100644
> --- a/gcc/config/bpf/bpf-protos.h
> +++ b/gcc/config/bpf/bpf-protos.h
> @@ -23,7 +23,7 @@ along with GCC; see the file COPYING3.  If not see
>  /* Routines implemented in bpf.cc.  */
>  
>  extern HOST_WIDE_INT bpf_initial_elimination_offset (int, int);
> -extern const char *bpf_output_call (rtx);
> +extern const char *bpf_output_call (const char *templ, rtx *, int 
> target_index);
>  extern void bpf_target_macros (cpp_reader *);
>  extern void bpf_print_operand (FILE *, rtx, int);
>  extern void bpf_print_operand_address (FILE *, rtx);
> diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
> index d9141dd625a..f1a8eb8d62c 100644
> --- a/gcc/config/bpf/bpf.cc
> +++ b/gcc/config/bpf/bpf.cc
> @@ -754,14 +754,12 @@ bpf_output_destructor (rtx symbol, int priority 
> ATTRIBUTE_UNUSED)
> bpf.md.  */
>  
>  const char *
> -bpf_output_call (rtx target)
> +bpf_output_call (const char *templ, rtx *operands, int target_index)
>  {
> -  rtx xops[1];
> -
> +  rtx target = operands[target_index];
>switch (GET_CODE (target))
>  {
>  case CONST_INT:
> -  output_asm_insn ("call\t%0", &target);
>break;
>  case SYMBOL_REF:
>{
> @@ -774,26 +772,20 @@ bpf_output_call (rtx target)
> {
>   tree attr_args = TREE_VALUE (attr);
>  
> - xops[0] = GEN_INT (TREE_INT_CST_LOW (TREE_VALUE (attr_args)));
> - output_asm_insn ("call\t%0", xops);
> -   }
> - else
> -   output_asm_insn ("call\t%0", &target);
> + operands[target_index] = GEN_INT (TREE_INT_CST_LOW (TREE_VALUE 
> (attr_args)));
>  
> +   }
>   break;
>}
>  default:
> -  if (TARGET_XBPF)
> - output_asm_insn ("call\t%0", &target);
> -  else
> +  if (!TARGET_XBPF)
>   {
> error ("indirect call in function, which are not supported by eBPF");
> -   output_asm_insn ("call 0", NULL);
> +   operands[target_index] = GEN_INT (0);
>   }
>break;
>  }
> -
> -  return "";
> +  return templ;
>  }
>  
>  const char *
> @@ -1144,6 +1136,87 @@ bpf_debug_unwind_info ()
>  #undef TARGET_DEBUG_UNWIND_INFO
>  #define TARGET_DEBUG_UNWIND_INFO bpf_debug_unwind_info
>  
> +/* Create a BTF.ext line_info entry.  */
> +
> +static void
> +bpf_output_line_info (FILE *asm_out_file, rtx_insn *insn)
> +{
> +  static unsigned int line_info_label = 1;
> +  static tree cfun_decl = NULL_TREE;
> +  static bool func_start_added = false;
> +  const char *label = NULL;
> +  unsigned int loc = 0;
> +  const char *filename = NULL;
> +  unsigned int line = 0;
> +  unsigned int column = 0;
> +
> +  if(!btf_debuginfo_p ())
> +return;

I think it would be better to put this guard in bpf_asm_out_unwind_emit
instead of bpf_output_line_info.

> +
> +  gcc_assert (insn != NULL_RTX);
> +
> +  if (current_function_decl != cfun_decl
> +  && GET_CODE (insn) == NOTE)
> +{
> +  label = current_function_func_begin_label;
> +  loc = DECL_SOURCE_LOCATION (current_function_decl);
> +  filename = LOCAT

Re: [PATCH] wwwdocs: Add note to changes.html for __has_{feature,extension}

[Marek Polacek]

On Mon, Apr 15, 2024 at 11:13:27AM +0100, Alex Coplan wrote:
> On 04/04/2024 11:00, Alex Coplan wrote:
> > Hi,
> > 
> > This adds a note to the GCC 14 release notes mentioning support for
> > __has_{feature,extension} (PR60512).
> > 
> > OK to commit?
> 
> Ping.  Is this changes.html patch OK?  I guess it needs a review from C++
> maintainers since it adds to the C++ section.
> 
> > 
> > Thanks,
> > Alex
> 
> > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> > index 9fd224c1..facead8d 100644
> > --- a/htdocs/gcc-14/changes.html
> > +++ b/htdocs/gcc-14/changes.html
> > @@ -242,6 +242,12 @@ a work-in-progress.
> >constinit and optimized dynamic initialization
> >  
> >
> > +  The Clang language extensions __has_feature and
> > +__has_extension have been implemented in GCC.  These
> > +are available from C, C++, and Objective-C(++).

Since the extension is for the whole c-family, not just C++, I think it
belongs to a "C family" section.  See e.g. 
.

Marek

Re: [PATCH 3/3] bpf: add line_info support to BTF.ext section.

[Cupertino Miranda]

Jose E. Marchesi writes:

> Hi Cuper.
> Thanks for the patch.
>
>> This patch adds line_info debug information support to .BTF.ext
>> sections.
>> Line info information is used by the BPF verifier to improve error
>> reporting and give more precise source core referenced errors.
>>
>> gcc/Changelog:
>>  * config/bpf/bpf-protos.h (bpf_output_call): Change prototype.
>>  * config/bpf/bpf.cc (bpf_output_call): Change to adapt operands
>>  and return
>>  the instruction template instead of emmidiatelly emit asm and
>>  not allow proper final expected execution flow.
>>  (bpf_output_line_info): Add function to introduce line info
>>  entries in respective structures
>>  (bpf_asm_out_unwind_emit): Add function as hook to
>>  TARGET_ASM_UNWIND_EMIT. This hook is called before any
>>  instruction is emitted.
>
> Is it actually necessary to emit a label (plus .BTF.ext entry) for every
> instruction?
Maybe BPF would be Ok (not complaining of missing line_info) with just a
single entry per function pointing to the entry instruction. That
is not what clang does. Don't know if it emits any labels either.

It is probably possible to add some logic to compute the offset from the
function label and emit with an offset to the instruction location.
In case of inline assembly we could add a symbol after, and restart
offset computation.
It will need to add code to compute the instruction encoding size, and
increment function label offset each time we emit an instruction.

Still, my personal preference is to create those labels to properly
compute instruction location then some rather intricate solution that
would lead to future complications.
I know BPF is not like all the other targets, but I am thinking of
assembly/linker relaxation.

WDYT ?

>>  * config/bpf/bpf.md: Change calls to bpf_output_call.
>>  * config/bpf/btfext-out.cc (struct btf_ext_lineinfo): Add fields
>>  to struct.
>>  (bpf_create_lineinfo, btf_add_line_info_for): Add support
>>  function to insert line_info data in respective structures.
>>  (output_btfext_line_info): Function to emit line_info data in
>>  .BTF.ext section.
>>  (btf_ext_output): Call output_btfext_line_info.
>>  * config/bpf/btfext-out.h: Add prototype for
>>  btf_add_line_info_for.
>> ---
>>  gcc/config/bpf/bpf-protos.h   |   2 +-
>>  gcc/config/bpf/bpf.cc | 103 ++---
>>  gcc/config/bpf/bpf.md |   4 +-
>>  gcc/config/bpf/btfext-out.cc  | 108 +-
>>  gcc/config/bpf/btfext-out.h   |   4 +
>>  .../gcc.target/bpf/btfext-funcinfo.c  |   3 +-
>>  6 files changed, 203 insertions(+), 21 deletions(-)
>>
>> diff --git a/gcc/config/bpf/bpf-protos.h b/gcc/config/bpf/bpf-protos.h
>> index b4866d34209..ddaca50af69 100644
>> --- a/gcc/config/bpf/bpf-protos.h
>> +++ b/gcc/config/bpf/bpf-protos.h
>> @@ -23,7 +23,7 @@ along with GCC; see the file COPYING3.  If not see
>>  /* Routines implemented in bpf.cc.  */
>>
>>  extern HOST_WIDE_INT bpf_initial_elimination_offset (int, int);
>> -extern const char *bpf_output_call (rtx);
>> +extern const char *bpf_output_call (const char *templ, rtx *, int 
>> target_index);
>>  extern void bpf_target_macros (cpp_reader *);
>>  extern void bpf_print_operand (FILE *, rtx, int);
>>  extern void bpf_print_operand_address (FILE *, rtx);
>> diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
>> index d9141dd625a..f1a8eb8d62c 100644
>> --- a/gcc/config/bpf/bpf.cc
>> +++ b/gcc/config/bpf/bpf.cc
>> @@ -754,14 +754,12 @@ bpf_output_destructor (rtx symbol, int priority 
>> ATTRIBUTE_UNUSED)
>> bpf.md.  */
>>
>>  const char *
>> -bpf_output_call (rtx target)
>> +bpf_output_call (const char *templ, rtx *operands, int target_index)
>>  {
>> -  rtx xops[1];
>> -
>> +  rtx target = operands[target_index];
>>switch (GET_CODE (target))
>>  {
>>  case CONST_INT:
>> -  output_asm_insn ("call\t%0", &target);
>>break;
>>  case SYMBOL_REF:
>>{
>> @@ -774,26 +772,20 @@ bpf_output_call (rtx target)
>>{
>>  tree attr_args = TREE_VALUE (attr);
>>
>> -xops[0] = GEN_INT (TREE_INT_CST_LOW (TREE_VALUE (attr_args)));
>> -output_asm_insn ("call\t%0", xops);
>> -  }
>> -else
>> -  output_asm_insn ("call\t%0", &target);
>> +operands[target_index] = GEN_INT (TREE_INT_CST_LOW (TREE_VALUE 
>> (attr_args)));
>>
>> +  }
>>  break;
>>}
>>  default:
>> -  if (TARGET_XBPF)
>> -output_asm_insn ("call\t%0", &target);
>> -  else
>> +  if (!TARGET_XBPF)
>>  {
>>error ("indirect call in function, which are not supported by eBPF");
>> -  output_asm_insn ("call 0", NULL);
>> +  operands[target_index] = GEN_INT (0);
>>  }
>>break;
>>  }
>> -
>> -  return "";
>> +  return templ;
>>  }
>>
>>  const char *
>> @@ -1144,6 +1136,87 @@ bpf_debug_un

[committed] libstdc++: Implement "Printing blank lines with println" for C++23

[Jonathan Wakely]

Tested x86_64-linux and x86_64-freebsd. Pushed to trunk.

-- >8 --

This was recently approved for C++26 at the Tokyo meeting. As suggested
by Stephan T. Lavavej, I'm defining it as an extension for C++23 mode
(when std::print and std::prinln were first added) rather than as a new
C++26 feature. Both MSVC and libc++ have agreed to do this too.

libstdc++-v3/ChangeLog:

* include/std/ostream (println(ostream&)): Define new overload.
* include/std/print (println(FILE*), println()): Likewise.
* testsuite/27_io/basic_ostream/print/2.cc: New test.
* testsuite/27_io/print/1.cc: Remove unused header.
* testsuite/27_io/print/3.cc: New test.
---
 libstdc++-v3/include/std/ostream  | 12 +
 libstdc++-v3/include/std/print| 14 +
 .../testsuite/27_io/basic_ostream/print/2.cc  | 47 
 libstdc++-v3/testsuite/27_io/print/1.cc   |  1 -
 libstdc++-v3/testsuite/27_io/print/3.cc   | 53 +++
 5 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/testsuite/27_io/basic_ostream/print/2.cc
 create mode 100644 libstdc++-v3/testsuite/27_io/print/3.cc

diff --git a/libstdc++-v3/include/std/ostream b/libstdc++-v3/include/std/ostream
index a136399ad0b..8a21758d0a3 100644
--- a/libstdc++-v3/include/std/ostream
+++ b/libstdc++-v3/include/std/ostream
@@ -995,6 +995,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   std::print(__os, "{}\n",
 std::format(__fmt, std::forward<_Args>(__args)...));
 }
+
+  // Defined for C++26, supported as an extension to C++23.
+  inline void println(ostream& __os)
+  {
+#if defined(_WIN32) && !defined(__CYGWIN__)
+if constexpr (__unicode::__literal_encoding_is_utf8())
+  std::vprint_unicode(__os, "\n", std::make_format_args());
+else
+#endif
+  __os.put('\n');
+  }
+
 #endif // __cpp_lib_print
 
 #endif // C++11
diff --git a/libstdc++-v3/include/std/print b/libstdc++-v3/include/std/print
index d44033469de..0c259d04de3 100644
--- a/libstdc++-v3/include/std/print
+++ b/libstdc++-v3/include/std/print
@@ -136,6 +136,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   vprint_nonunicode(string_view __fmt, format_args __args)
   { std::vprint_nonunicode(stdout, __fmt, __args); }
 
+  // Defined for C++26, supported as an extension to C++23.
+  inline void println(FILE* __stream)
+  {
+#if defined(_WIN32) && !defined(__CYGWIN__)
+if constexpr (__unicode::__literal_encoding_is_utf8())
+  std::vprint_unicode(__stream, "\n", std::make_format_args());
+else
+#endif
+  if (std::putc('\n', __stream) == EOF)
+   __throw_system_error(EIO);
+  }
+
+  inline void println() { std::println(stdout); }
+
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 #endif // __cpp_lib_print
diff --git a/libstdc++-v3/testsuite/27_io/basic_ostream/print/2.cc 
b/libstdc++-v3/testsuite/27_io/basic_ostream/print/2.cc
new file mode 100644
index 000..5d1e3efdbf7
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/basic_ostream/print/2.cc
@@ -0,0 +1,47 @@
+// { dg-additional-options "-lstdc++exp" { target { *-*-mingw* } } }
+// { dg-do run { target c++23 } }
+// { dg-require-fileio "" }
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void
+test_println_blank_ostream()
+{
+  char buf[4];
+  std::spanstream os(buf);
+  std::println(os);
+  std::string_view txt(os.span());
+  VERIFY( txt == "\n" );
+}
+
+void
+test_errors()
+{
+  // Failure to generate output is reported by setting badbit.
+  std::stringstream in(std::ios::in);
+  std::println(in); // No exception here.
+  VERIFY(in.bad());
+#ifdef __cpp_exceptions
+  in.clear();
+  in.exceptions(std::ios::badbit);
+  try
+  {
+std::println(in); // Should throw now.
+VERIFY(false);
+  }
+  catch (const std::ios::failure&)
+  {
+  }
+#endif
+}
+
+int main()
+{
+  test_println_blank_ostream();
+  test_errors();
+}
diff --git a/libstdc++-v3/testsuite/27_io/print/1.cc 
b/libstdc++-v3/testsuite/27_io/print/1.cc
index d570f7938be..f6585d9880a 100644
--- a/libstdc++-v3/testsuite/27_io/print/1.cc
+++ b/libstdc++-v3/testsuite/27_io/print/1.cc
@@ -4,7 +4,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/libstdc++-v3/testsuite/27_io/print/3.cc 
b/libstdc++-v3/testsuite/27_io/print/3.cc
new file mode 100644
index 000..ffcf7337ce5
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/print/3.cc
@@ -0,0 +1,53 @@
+// { dg-additional-options "-lstdc++exp" { target { *-*-mingw* } } }
+// { dg-do run { target c++23 } }
+// { dg-require-fileio "" }
+
+#include 
+#include 
+#include 
+#include 
+
+void
+test_println_blank()
+{
+  std::print("1");
+  std::println();
+  std::println("2");
+  // { dg-output "1\n2" }
+}
+
+void
+test_println_blank_file()
+{
+  __gnu_test::scoped_file f;
+  FILE* strm = std::fopen(f.path.string().c_str(), "w");
+  VERIFY( strm );
+  std::println(strm);
+  std::fclose(strm);
+
+  std::ifstream in(f.path);
+  std::string txt(std::istreambuf_iterator

[Patch, fortran] PR114739 [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458

[Paul Richard Thomas]

This ICE was caused by my patch r14-9489-g3fd46d859cda10. However, the ICE
hid a wrong error going back to at least 6.4.1 20180703. The patch fixes
both and exposed incorrect error messages in existing tests in gfortran.dg.
The fix for these was to add 'IMPLICIT NONE' in call cases so that there
really is no implicit type.

Regtests OK - I will commit in 24 hours time, if there are no objections
and will backport in a couple of weeks.

Paul

Fortran: Fix ICE in gfc_match_varspec and error messages [PR114739]

2024-04-17  Paul Thomas  

gcc/fortran
PR fortran/114739
* primary.cc (gfc_match_varspec): Check for default type before
checking for derived types with the right component name.

gcc/testsuite/
PR fortran/114739
* gfortran.dg/pr114739.f90: New test.
* gfortran.dg/derived_comp_array_ref_8.f90: Add 'implicit none'
for consistency with expected error message.
* gfortran.dg/nullify_4.f90: ditto
* gfortran.dg/pointer_init_6.f90: ditto
* gfortran.dg/pr107397.f90: ditto
* gfortran.dg/pr88138.f90: ditto
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 5dd6875a4a6..3c64fa73dfa 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -2236,6 +2236,15 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, bool sub_flag,
   match mm;
   old_loc = gfc_current_locus;
   mm = gfc_match_name (name);
+
+  /* Check to see if this is default complex.  */
+  if (sym->ts.type == BT_UNKNOWN && tgt_expr == NULL
+	  && gfc_get_default_type (sym->name, sym->ns)->type != BT_UNKNOWN)
+	{
+	  gfc_set_default_type (sym, 0, sym->ns);
+	  primary->ts = sym->ts;
+	}
+
   /* This is a usable inquiry reference, if the symbol is already known
 	 to have a type or no derived types with a component of this name
 	 can be found.  If this was an inquiry reference with the same name
diff --git a/gcc/testsuite/gfortran.dg/derived_comp_array_ref_8.f90 b/gcc/testsuite/gfortran.dg/derived_comp_array_ref_8.f90
index 739f4adfb78..22dfdc668a6 100644
--- a/gcc/testsuite/gfortran.dg/derived_comp_array_ref_8.f90
+++ b/gcc/testsuite/gfortran.dg/derived_comp_array_ref_8.f90
@@ -2,6 +2,7 @@
 !
 ! PR fortran/52325
 !
+implicit none
 real :: f
 cc%a = 5 ! { dg-error "Symbol 'cc' at .1. has no IMPLICIT type" }
 f%a = 5  ! { dg-error "Unexpected '%' for nonderived-type variable 'f' at" }
diff --git a/gcc/testsuite/gfortran.dg/nullify_4.f90 b/gcc/testsuite/gfortran.dg/nullify_4.f90
index 0fd5056ee07..240110fabf8 100644
--- a/gcc/testsuite/gfortran.dg/nullify_4.f90
+++ b/gcc/testsuite/gfortran.dg/nullify_4.f90
@@ -3,6 +3,7 @@
 !
 ! Check error recovery; was crashing before.
 !
+implicit none
 real, pointer :: ptr
 nullify(ptr, mesh%coarser) ! { dg-error "Symbol 'mesh' at .1. has no IMPLICIT type" }
 end
diff --git a/gcc/testsuite/gfortran.dg/pointer_init_6.f90 b/gcc/testsuite/gfortran.dg/pointer_init_6.f90
index 3abad4ae179..477626e66bb 100644
--- a/gcc/testsuite/gfortran.dg/pointer_init_6.f90
+++ b/gcc/testsuite/gfortran.dg/pointer_init_6.f90
@@ -21,7 +21,7 @@ end module m1


 module m2
-
+ implicit none
  type :: t
procedure(s), pointer, nopass :: ppc
  end type
diff --git a/gcc/testsuite/gfortran.dg/pr107397.f90 b/gcc/testsuite/gfortran.dg/pr107397.f90
index fd59bf16007..f77b4b00d00 100644
--- a/gcc/testsuite/gfortran.dg/pr107397.f90
+++ b/gcc/testsuite/gfortran.dg/pr107397.f90
@@ -1,6 +1,7 @@
 !{ dg-do compile }
 !
 program p
+  implicit none
   type t
 real :: a = 1.0
   end type
diff --git a/gcc/testsuite/gfortran.dg/pr114739.f90 b/gcc/testsuite/gfortran.dg/pr114739.f90
new file mode 100644
index 000..eb82cb3f65b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr114739.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! The fix here was triggered by an ICE prior to r14-9489-g3fd46d859cda10
+! Before that gfortran gave an incorrect "no implicit type" error for all
+! three statements.
+program main
+  implicit complex(z)
+  implicit character(c)
+  z2%re = 1.
+  z2%im = 2.
+  print *, z2, c%kind
+end
diff --git a/gcc/testsuite/gfortran.dg/pr88138.f90 b/gcc/testsuite/gfortran.dg/pr88138.f90
index c4019a6ca2e..f1130cf2bab 100644
--- a/gcc/testsuite/gfortran.dg/pr88138.f90
+++ b/gcc/testsuite/gfortran.dg/pr88138.f90
@@ -1,5 +1,6 @@
 ! { dg-do compile }
 program p
+   implicit none
type t
   character :: c = 'c'
end type

Re: [PATCH] libcpp: Regenerate aclocal.m4 and configure [PR 114748]

[Eric Gallager]

On Wed, Apr 17, 2024 at 10:03 AM Christophe Lyon
 wrote:
>
> As discussed in the PR, aclocal.m4 and configure were incorrectly
> regenerated at some point.
>
> 2024-04-17  Christophe Lyon  
>
> PR preprocessor/114748
> libcpp/
> * aclocal.m4: Regenerate.
> * configure: Regenerate.
> ---
>  libcpp/aclocal.m4 | 1 +
>  libcpp/configure  | 3 +++
>  2 files changed, 4 insertions(+)
>
> diff --git a/libcpp/aclocal.m4 b/libcpp/aclocal.m4
> index 4fc81709622..4d898ea2c97 100644
> --- a/libcpp/aclocal.m4
> +++ b/libcpp/aclocal.m4
> @@ -26,6 +26,7 @@ m4_include([../config/lib-ld.m4])
>  m4_include([../config/lib-link.m4])
>  m4_include([../config/lib-prefix.m4])
>  m4_include([../config/nls.m4])
> +m4_include([../config/override.m4])
>  m4_include([../config/po.m4])
>  m4_include([../config/progtest.m4])
>  m4_include([../config/warnings.m4])
> diff --git a/libcpp/configure b/libcpp/configure
> index 8a38c0546e3..32d6aaa3069 100755
> --- a/libcpp/configure
> +++ b/libcpp/configure
> @@ -2670,6 +2670,9 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
>
>
>
> +
> +
> +

So, this is kind of a minor style nitpick, but personally, it kind of
bothers me when autotools goes and inserts a bunch of unnecessary
blank newlines in the generated output scripts. Does anyone else think
it'd be worth it to scatter around some of m4's "dnl" comments in the
configure.ac scripts, to get autoconf to eat the unnecessary newlines?
Just an idea,
Eric Gallager

>  ac_aux_dir=
>  for ac_dir in "$srcdir" "$srcdir/.." "$srcdir/../.."; do
>if test -f "$ac_dir/install-sh"; then
> --
> 2.34.1
>

Re: [PATCH] libcpp: Regenerate aclocal.m4 and configure [PR 114748]

[Jakub Jelinek]

On Wed, Apr 17, 2024 at 01:16:43PM -0400, Eric Gallager wrote:
> > --- a/libcpp/configure
> > +++ b/libcpp/configure
> > @@ -2670,6 +2670,9 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
> >
> >
> >
> > +
> > +
> > +
> 
> So, this is kind of a minor style nitpick, but personally, it kind of
> bothers me when autotools goes and inserts a bunch of unnecessary
> blank newlines in the generated output scripts. Does anyone else think
> it'd be worth it to scatter around some of m4's "dnl" comments in the
> configure.ac scripts, to get autoconf to eat the unnecessary newlines?

In stage1 maybe, but certainly not in stage4.

Jakub

Re: [PATCH 3/3] bpf: add line_info support to BTF.ext section.

[Jose E. Marchesi]

> Jose E. Marchesi writes:
>
>> Hi Cuper.
>> Thanks for the patch.
>>
>>> This patch adds line_info debug information support to .BTF.ext
>>> sections.
>>> Line info information is used by the BPF verifier to improve error
>>> reporting and give more precise source core referenced errors.
>>>
>>> gcc/Changelog:
>>> * config/bpf/bpf-protos.h (bpf_output_call): Change prototype.
>>> * config/bpf/bpf.cc (bpf_output_call): Change to adapt operands
>>> and return
>>> the instruction template instead of emmidiatelly emit asm and
>>> not allow proper final expected execution flow.
>>> (bpf_output_line_info): Add function to introduce line info
>>> entries in respective structures
>>> (bpf_asm_out_unwind_emit): Add function as hook to
>>> TARGET_ASM_UNWIND_EMIT. This hook is called before any
>>> instruction is emitted.
>>
>> Is it actually necessary to emit a label (plus .BTF.ext entry) for every
>> instruction?
> Maybe BPF would be Ok (not complaining of missing line_info) with just a
> single entry per function pointing to the entry instruction. That
> is not what clang does. Don't know if it emits any labels either.
>
> It is probably possible to add some logic to compute the offset from
> the function label and emit with an offset to the instruction
> location.  In case of inline assembly we could add a symbol after, and
> restart offset computation.  It will need to add code to compute the
> instruction encoding size, and increment function label offset each
> time we emit an instruction.
>
> Still, my personal preference is to create those labels to properly
> compute instruction location then some rather intricate solution that
> would lead to future complications.  I know BPF is not like all the
> other targets, but I am thinking of assembly/linker relaxation.
>
> WDYT ?

What I meant is: if it is not required to emit a line_info entry for
_every_ BPF instruction, but only for the instructions that "change" the
current location, then we better do so?

Then, regarding the labels, I assume their purpose is to get the
assembler to fill in the `insn_off' field of the bpf_line_info in the
.BTF.ext section:

struct bpf_line_info {
__u32   insn_off; /* [0, insn_cnt - 1] */
__u32   file_name_off; /* offset to string table for the filename */
__u32   line_off; /* offset to string table for the source line */
__u32   line_col; /* line number and column number */
};

Which makes sense, since "instruction offset" is really the business of
the assembler, not the compiler.  I agree with you making it the
compiler's business would be overcomplicated, given inline assembly and
variable-sized BPF instructions...

So, what about moving the task of creating these line_info entries
entirely to the assembler?  GCC already knows how to emit .file and .loc
directives to track location info in DWARF.

The BPF assembler could then process these and create entries in
.BTF.ext for line_info, all the fields above: insn_off, file_name_off,
line_off and line_col.

>>> * config/bpf/bpf.md: Change calls to bpf_output_call.
>>> * config/bpf/btfext-out.cc (struct btf_ext_lineinfo): Add fields
>>> to struct.
>>> (bpf_create_lineinfo, btf_add_line_info_for): Add support
>>> function to insert line_info data in respective structures.
>>> (output_btfext_line_info): Function to emit line_info data in
>>> .BTF.ext section.
>>> (btf_ext_output): Call output_btfext_line_info.
>>> * config/bpf/btfext-out.h: Add prototype for
>>> btf_add_line_info_for.
>>> ---
>>>  gcc/config/bpf/bpf-protos.h   |   2 +-
>>>  gcc/config/bpf/bpf.cc | 103 ++---
>>>  gcc/config/bpf/bpf.md |   4 +-
>>>  gcc/config/bpf/btfext-out.cc  | 108 +-
>>>  gcc/config/bpf/btfext-out.h   |   4 +
>>>  .../gcc.target/bpf/btfext-funcinfo.c  |   3 +-
>>>  6 files changed, 203 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/gcc/config/bpf/bpf-protos.h b/gcc/config/bpf/bpf-protos.h
>>> index b4866d34209..ddaca50af69 100644
>>> --- a/gcc/config/bpf/bpf-protos.h
>>> +++ b/gcc/config/bpf/bpf-protos.h
>>> @@ -23,7 +23,7 @@ along with GCC; see the file COPYING3.  If not see
>>>  /* Routines implemented in bpf.cc.  */
>>>
>>>  extern HOST_WIDE_INT bpf_initial_elimination_offset (int, int);
>>> -extern const char *bpf_output_call (rtx);
>>> +extern const char *bpf_output_call (const char *templ, rtx *, int 
>>> target_index);
>>>  extern void bpf_target_macros (cpp_reader *);
>>>  extern void bpf_print_operand (FILE *, rtx, int);
>>>  extern void bpf_print_operand_address (FILE *, rtx);
>>> diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
>>> index d9141dd625a..f1a8eb8d62c 100644
>>> --- a/gcc/config/bpf/bpf.cc
>>> +++ b/gcc/config/bpf/bpf.cc
>>> @@ -754,14 +754,12 @@ bpf_output_destructor (rtx symbol, int priority 
>>> ATTRIBUTE_U

Re: [PATCH 3/3] bpf: add line_info support to BTF.ext section.

[Jose E. Marchesi]

>> Jose E. Marchesi writes:
>>
>>> Hi Cuper.
>>> Thanks for the patch.
>>>
 This patch adds line_info debug information support to .BTF.ext
 sections.
 Line info information is used by the BPF verifier to improve error
 reporting and give more precise source core referenced errors.

 gcc/Changelog:
* config/bpf/bpf-protos.h (bpf_output_call): Change prototype.
* config/bpf/bpf.cc (bpf_output_call): Change to adapt operands
and return
the instruction template instead of emmidiatelly emit asm and
not allow proper final expected execution flow.
(bpf_output_line_info): Add function to introduce line info
entries in respective structures
(bpf_asm_out_unwind_emit): Add function as hook to
TARGET_ASM_UNWIND_EMIT. This hook is called before any
instruction is emitted.
>>>
>>> Is it actually necessary to emit a label (plus .BTF.ext entry) for every
>>> instruction?
>> Maybe BPF would be Ok (not complaining of missing line_info) with just a
>> single entry per function pointing to the entry instruction. That
>> is not what clang does. Don't know if it emits any labels either.
>>
>> It is probably possible to add some logic to compute the offset from
>> the function label and emit with an offset to the instruction
>> location.  In case of inline assembly we could add a symbol after, and
>> restart offset computation.  It will need to add code to compute the
>> instruction encoding size, and increment function label offset each
>> time we emit an instruction.
>>
>> Still, my personal preference is to create those labels to properly
>> compute instruction location then some rather intricate solution that
>> would lead to future complications.  I know BPF is not like all the
>> other targets, but I am thinking of assembly/linker relaxation.
>>
>> WDYT ?
>
> What I meant is: if it is not required to emit a line_info entry for
> _every_ BPF instruction, but only for the instructions that "change" the
> current location, then we better do so?
>
> Then, regarding the labels, I assume their purpose is to get the
> assembler to fill in the `insn_off' field of the bpf_line_info in the
> .BTF.ext section:
>
> struct bpf_line_info {
> __u32   insn_off; /* [0, insn_cnt - 1] */
> __u32   file_name_off; /* offset to string table for the filename */
> __u32   line_off; /* offset to string table for the source line */
> __u32   line_col; /* line number and column number */
> };
>
> Which makes sense, since "instruction offset" is really the business of
> the assembler, not the compiler.  I agree with you making it the
> compiler's business would be overcomplicated, given inline assembly and
> variable-sized BPF instructions...
>
> So, what about moving the task of creating these line_info entries
> entirely to the assembler?  GCC already knows how to emit .file and .loc
> directives to track location info in DWARF.
>
> The BPF assembler could then process these and create entries in
> .BTF.ext for line_info, all the fields above: insn_off, file_name_off,
> line_off and line_col.

Regarding file_name_off, hopefully it will be possible to make the
assembler to simply expand the string table in .BTF (with the strings
read from .file directives) without having to understand/redo the whole
BTF section...

* config/bpf/bpf.md: Change calls to bpf_output_call.
* config/bpf/btfext-out.cc (struct btf_ext_lineinfo): Add fields
to struct.
(bpf_create_lineinfo, btf_add_line_info_for): Add support
function to insert line_info data in respective structures.
(output_btfext_line_info): Function to emit line_info data in
.BTF.ext section.
(btf_ext_output): Call output_btfext_line_info.
* config/bpf/btfext-out.h: Add prototype for
btf_add_line_info_for.
 ---
  gcc/config/bpf/bpf-protos.h   |   2 +-
  gcc/config/bpf/bpf.cc | 103 ++---
  gcc/config/bpf/bpf.md |   4 +-
  gcc/config/bpf/btfext-out.cc  | 108 +-
  gcc/config/bpf/btfext-out.h   |   4 +
  .../gcc.target/bpf/btfext-funcinfo.c  |   3 +-
  6 files changed, 203 insertions(+), 21 deletions(-)

 diff --git a/gcc/config/bpf/bpf-protos.h b/gcc/config/bpf/bpf-protos.h
 index b4866d34209..ddaca50af69 100644
 --- a/gcc/config/bpf/bpf-protos.h
 +++ b/gcc/config/bpf/bpf-protos.h
 @@ -23,7 +23,7 @@ along with GCC; see the file COPYING3.  If not see
  /* Routines implemented in bpf.cc.  */

  extern HOST_WIDE_INT bpf_initial_elimination_offset (int, int);
 -extern const char *bpf_output_call (rtx);
 +extern const char *bpf_output_call (const char *templ, rtx *, int 
 target_index);
  extern void bpf_target_macros (cpp_reader *);
  extern void bpf_print_operand (FILE *, 

Re: [PATCH v2 2/2] c++/modules: Fix instantiation of imported temploid friends [PR114275]

[Patrick Palka]

On Mon, 15 Apr 2024, Nathaniel Shead wrote:

> I'm not a huge fan of always streaming 'imported_temploid_friends' for
> all decls, but I don't think it adds much performance cost over adding a
> new flag to categorise decls that might be marked as such.

IIUC this value is going to be almost always null which is encoded as a
single 0 byte, which should be fast to stream.  But I wonder how much
larger  gets?  Can we get away with streaming this value
only for TEMPLATE_DECLs?

> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> 
> -- >8 --
> 
> This patch fixes a number of issues with the handling of temploid friend
> declarations.
> 
> The primary issue is that instantiations of friend declarations should
> attach the declaration to the same module as the befriending class, by
> [module.unit] p7.1 and [temp.friend] p2; this could be a different
> module from the current TU, and so needs special handling.

Nice, your approach seems consistent with Nathan's comments in the past
about this issue:

https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603288.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611215.htmlw

> 
> The other main issue here is that we can't assume that just because name
> lookup didn't find a definition for a hidden template class, it doesn't
> mean that it doesn't exist: it could be a non-exported entity that we've
> nevertheless streamed in from an imported module.  We need to ensure
> that when instantiating friend classes that we return the same TYPE_DECL
> that we got from our imports, otherwise we will get later issues with
> 'duplicate_decls' (rightfully) complaining that they're different.
> 
> This doesn't appear necessary for functions due to the existing name
> lookup handling already finding these hidden declarations.

It does seem like a weird inconsistency that tsubst_friend_class needs
this workaround but not tsubst_friend_function.

I wonder if we can relax duplicate_decls to treat an instantiated
template friend class as a redeclaration instead of complaining,
mirroring its behavior for functions, which in turn would let us get rid
of the name lookup in tsubst_friend_class and eliminate the need for
lookup_imported_hidden_friend?  This may be too speculative/risky of
a refactoring at this stage though, and your approach has the nice
advantage of changing only modules code paths.

In any case I hope we can fix this issue for GCC 14!  LGTM overall.

> 
>   PR c++/105320
>   PR c++/114275
> 
> gcc/cp/ChangeLog:
> 
>   * cp-tree.h (propagate_defining_module): Declare.
>   (lookup_imported_hidden_friend): Declare.
>   * decl.cc (duplicate_decls): Also check if hidden declarations
>   can be redeclared in this module.
>   * module.cc (imported_temploid_friends): New map.
>   (init_modules): Initialize it.
>   (trees_out::decl_value): Write it.
>   (trees_in::decl_value): Read it.
>   (get_originating_module_decl): Follow the owning decl for an
>   imported temploid friend.
>   (propagate_defining_module): New function.
>   * name-lookup.cc (lookup_imported_hidden_friend): New function.
>   * pt.cc (tsubst_friend_function): Propagate defining module for
>   new friend functions.
>   (tsubst_friend_class): Lookup imported hidden friends. Check
>   for valid redeclaration. Propagate defining module for new
>   friend classes.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/modules/tpl-friend-10_a.C: New test.
>   * g++.dg/modules/tpl-friend-10_b.C: New test.
>   * g++.dg/modules/tpl-friend-10_c.C: New test.
>   * g++.dg/modules/tpl-friend-11_a.C: New test.
>   * g++.dg/modules/tpl-friend-11_b.C: New test.
>   * g++.dg/modules/tpl-friend-12_a.C: New test.
>   * g++.dg/modules/tpl-friend-12_b.C: New test.
>   * g++.dg/modules/tpl-friend-12_c.C: New test.
>   * g++.dg/modules/tpl-friend-12_d.C: New test.
>   * g++.dg/modules/tpl-friend-12_e.C: New test.
>   * g++.dg/modules/tpl-friend-12_f.C: New test.
>   * g++.dg/modules/tpl-friend-13_a.C: New test.
>   * g++.dg/modules/tpl-friend-13_b.C: New test.
>   * g++.dg/modules/tpl-friend-13_c.C: New test.
>   * g++.dg/modules/tpl-friend-13_d.C: New test.
>   * g++.dg/modules/tpl-friend-13_e.C: New test.
>   * g++.dg/modules/tpl-friend-9.C: New test.
> 
> Signed-off-by: Nathaniel Shead 
> ---
>  gcc/cp/cp-tree.h  |  2 +
>  gcc/cp/decl.cc| 36 +++--
>  gcc/cp/module.cc  | 52 +++
>  gcc/cp/name-lookup.cc | 42 +++
>  gcc/cp/pt.cc  | 19 +++
>  .../g++.dg/modules/tpl-friend-10_a.C  | 15 ++
>  .../g++.dg/modules/tpl-friend-10_b.C  |  5 ++
>  .../g++.dg/modules/tpl-friend-10_c.C  |  7 +++
>  .../g++.dg/modules/tpl-friend-11_a.C  | 14 +
>  .../g++.dg/mod

[PATCH] libstdc++: Fix std::ranges::iota is not included in numeric [PR108760]

[Michael Levine (BLOOMBERG/ 919 3RD A)]

This patch fixes GCC Bug 108760:  
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760

Before this patch, using std::ranges::iota required including  when 
it should have been sufficient to only include .

When the patch is applied, the following code will compile:  
https://godbolt.org/z/33EPeqd1b

I added a test case for this change as well.

I built my local version of gcc using the following configuration:  $ 
../gcc/configure --disable-bootstrap --prefix="$(pwd)/_pfx/" 
--enable-languages=c,c++,lto

and I tested my changes by running:  $ make check-c++ -jN -k

I ran this on the following OS:

Virtualization: wsl
Operating System: Ubuntu 20.04.6 LTS
Kernel: Linux 5.15.146.1-microsoft-standard-WSL2
Architecture: x86-64




108760.patch
Description: Binary data

Re: [PATCH] [testsuite] [i386] work around fails with --enable-frame-pointer

[Uros Bizjak]

On Tue, Apr 16, 2024 at 5:51 AM Alexandre Oliva  wrote:
>
>
> A few x86 tests get unexpected insn counts if the toolchain is
> configured with --enable-frame-pointer.  Add explicit
> -fomit-frame-pointer so that the expected insn sequences are output.
>
> Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?
>
>
> for  gcc/testsuite/ChangeLog
>
> * gcc.target/i386/pr107261.c: Add -fomit-frame-pointer.
> * gcc.target/i386/pr69482-1.c: Likewise.
> * gcc.target/i386/pr69482-2.c: Likewise.

OK.

Thanks,
Uros.

> ---
>  gcc/testsuite/gcc.target/i386/pr107261.c  |2 +-
>  gcc/testsuite/gcc.target/i386/pr69482-1.c |2 +-
>  gcc/testsuite/gcc.target/i386/pr69482-2.c |2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/i386/pr107261.c 
> b/gcc/testsuite/gcc.target/i386/pr107261.c
> index eb1d232fbfc4b..b422af9cbf9a2 100644
> --- a/gcc/testsuite/gcc.target/i386/pr107261.c
> +++ b/gcc/testsuite/gcc.target/i386/pr107261.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O2 -msse2" } */
> +/* { dg-options "-O2 -msse2 -fomit-frame-pointer" } */
>
>  typedef __bf16 v4bf __attribute__ ((vector_size (8)));
>  typedef __bf16 v2bf __attribute__ ((vector_size (4)));
> diff --git a/gcc/testsuite/gcc.target/i386/pr69482-1.c 
> b/gcc/testsuite/gcc.target/i386/pr69482-1.c
> index 99bb6ad5a377b..7ef0e71b17c8e 100644
> --- a/gcc/testsuite/gcc.target/i386/pr69482-1.c
> +++ b/gcc/testsuite/gcc.target/i386/pr69482-1.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O3 -fno-stack-protector" } */
> +/* { dg-options "-O3 -fno-stack-protector -fomit-frame-pointer" } */
>
>  static inline void memset_s(void* s, int n) {
>volatile unsigned char * p = s;
> diff --git a/gcc/testsuite/gcc.target/i386/pr69482-2.c 
> b/gcc/testsuite/gcc.target/i386/pr69482-2.c
> index 58e89a7933364..6aabe4fb39399 100644
> --- a/gcc/testsuite/gcc.target/i386/pr69482-2.c
> +++ b/gcc/testsuite/gcc.target/i386/pr69482-2.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O2" } */
> +/* { dg-options "-O2 -fomit-frame-pointer" } */
>
>  void bar ()
>  {
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: [PATCH] [testsuite] [i386] add -msse2 to tests that require it

[Uros Bizjak]

On Tue, Apr 16, 2024 at 5:52 AM Alexandre Oliva  wrote:
>
>
> Without -msse2, an i586-targeting toolchain fails bf16_short_warn.c
> because neither type __m128bh nor intrinsic _mm_cvtneps_pbh get
> declared.
>
> Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?
>
>
> for  gcc/testsuite/ChangeLog
>
> * gcc.target/i386/bf16_short_warn.c: Add -msse2.

OK.

Thanks,
Uros.

> ---
>  gcc/testsuite/gcc.target/i386/bf16_short_warn.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.target/i386/bf16_short_warn.c 
> b/gcc/testsuite/gcc.target/i386/bf16_short_warn.c
> index 3e47a815200c2..2e05624bc26f6 100644
> --- a/gcc/testsuite/gcc.target/i386/bf16_short_warn.c
> +++ b/gcc/testsuite/gcc.target/i386/bf16_short_warn.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O2" } */
> +/* { dg-options "-O2 -msse2" } */
>
>  #include
>  typedef struct {
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH v2] bpf: remove huge memory waste with string allocation.

[Cupertino Miranda]

The BPF backend was allocating an unnecessarily large string when
constructing CO-RE relocations for enum types.

gcc/ChangeLog:
* config/bpf/core-builtins.cc (process_enum_value): Correct
string allocation.
---
 gcc/config/bpf/core-builtins.cc | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/gcc/config/bpf/core-builtins.cc b/gcc/config/bpf/core-builtins.cc
index e03e986e2c1..beb039ea6e0 100644
--- a/gcc/config/bpf/core-builtins.cc
+++ b/gcc/config/bpf/core-builtins.cc
@@ -870,12 +870,14 @@ process_enum_value (struct cr_builtins *data)
   unsigned int index = 0;
   for (tree l = TYPE_VALUES (type); l; l = TREE_CHAIN (l))
{
+ gcc_assert (index < (1 << 16));
  if (TREE_VALUE (l) == expr)
{
- char *tmp = (char *) ggc_alloc_atomic ((index / 10) + 1);
- sprintf (tmp, "%d", index);
- ret.str = (const char *) tmp;
-
+ /* Index can only be a value up to 2^16.  Should always fit
+in 6 chars.  */
+ char tmp[6];
+ sprintf (tmp, "%u", index);
+ ret.str = CONST_CAST (char *, ggc_strdup(tmp));
  break;
}
  index++;
-- 
2.30.2

Re: [PATCH v2] bpf: remove huge memory waste with string allocation.

[David Faust]

On 4/17/24 11:44, Cupertino Miranda wrote:
> The BPF backend was allocating an unnecessarily large string when
> constructing CO-RE relocations for enum types.
> 
> gcc/ChangeLog:
>   * config/bpf/core-builtins.cc (process_enum_value): Correct
>   string allocation.
> ---
>  gcc/config/bpf/core-builtins.cc | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/config/bpf/core-builtins.cc b/gcc/config/bpf/core-builtins.cc
> index e03e986e2c1..beb039ea6e0 100644
> --- a/gcc/config/bpf/core-builtins.cc
> +++ b/gcc/config/bpf/core-builtins.cc
> @@ -870,12 +870,14 @@ process_enum_value (struct cr_builtins *data)
>unsigned int index = 0;
>for (tree l = TYPE_VALUES (type); l; l = TREE_CHAIN (l))
>   {
> +   gcc_assert (index < (1 << 16));

Since the index here is computed from the TREE node and not BTF, is it
somehow already enforced that this code won't be run if the enum can't
be represented in BTF? 

If not, I don't think the assert is a good idea. The TREE node could be
an enum too large for BTF, but not too large for gcc.  So the assert
will cause an ICE for something that is a representation limit (in BTF
and by extension .BTF.ext i.e. CO-RE) rather than a compiler bug.
IMO an error or warning makes more sense here, something like:

  if (index >= (1 << 16))
{
  bpf_error ("enumerator in CO-RE relocation cannot be represented");
  break;
}

WDYT?

> if (TREE_VALUE (l) == expr)
>   {
> -   char *tmp = (char *) ggc_alloc_atomic ((index / 10) + 1);
> -   sprintf (tmp, "%d", index);
> -   ret.str = (const char *) tmp;
> -
> +   /* Index can only be a value up to 2^16.  Should always fit
> +  in 6 chars.  */
> +   char tmp[6];
> +   sprintf (tmp, "%u", index);
> +   ret.str = CONST_CAST (char *, ggc_strdup(tmp));
> break;
>   }
> index++;

[PATCH 1/2] Driver: Add new -truncate option

[Peter Damianov]

This commit adds a new option to the driver that truncates one file after
linking.

Tested likeso:

$ gcc hello.c -c
$ du -h hello.o
4.0K  hello.o
$ gcc hello.o -truncate hello
$ ./a.out
Hello world
$ du -h hello.o
$ 0   hello.o

$ gcc hello.o -truncate
gcc: error: missing filename after '-truncate'

The motivation for adding this is PR110710. It is used by lto-wrapper to
truncate files in a shell-independent manner.

Signed-off-by: Peter Damianov 
---
 gcc/common.opt |  5 +
 gcc/gcc.cc | 13 +
 2 files changed, 18 insertions(+)

diff --git a/gcc/common.opt b/gcc/common.opt
index ad348844775..3ede2fa8552 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -422,6 +422,11 @@ Display target specific command line options (including 
assembler and linker opt
 -time
 Driver Alias(time)
 
+;; Truncate the file specified after linking.
+;; This option is used by lto-wrapper to reduce the peak disk when linking with
+;; many .LTRANS units.
+Driver Separate Undocumented MissingArgError(missing filename after %qs)
+
 -verbose
 Driver Alias(v)
 
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 728332b8153..00017964295 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -2138,6 +2138,10 @@ static int have_E = 0;
 /* Pointer to output file name passed in with -o. */
 static const char *output_file = 0;
 
+/* Pointer to input file name passed in with -truncate.
+   This file should be truncated after linking. */
+static const char *totruncate_file = 0;
+
 /* This is the list of suffixes and codes (%g/%u/%U/%j) and the associated
temp file.  If the HOST_BIT_BUCKET is used for %j, no entry is made for
it here.  */
@@ -4607,6 +4611,10 @@ driver_handle_option (struct gcc_options *opts,
   save_switch ("-o", 1, &arg, validated, true);
   return true;
 
+case OPT_truncate:
+  totruncate_file = arg;
+  break;
+
 case OPT_pie:
 #ifdef ENABLE_DEFAULT_PIE
   /* -pie is turned on by default.  */
@@ -9273,6 +9281,11 @@ driver::maybe_run_linker (const char *argv0) const
   option).  */
error ("%s: linker input file not found: %m", outfiles[i]);
}
+
+  if (totruncate_file != NULL && linker_was_run && !seen_error ())
+/* Truncate file specified by -truncate.
+   Used by lto-wrapper to reduce temporary disk-space usage. */
+truncate(totruncate_file, 0);
 }
 
 /* The end of "main".  */
-- 
2.39.2

[PATCH 2/2] lto-wrapper: Truncate files using -truncate driver option [PR110710]

[Peter Damianov]

This commit changes the Makefiles generated by lto-wrapper to no longer use
the "mv" and "touch" shell commands. These don't exist on Windows, so when the
Makefile attempts to call them, it results in errors like:
The system cannot find the file specified.

This problem only manifested when calling gcc from cmd.exe, and having no
sh.exe present on the PATH. The Windows port of GNU Make searches the PATH for
an sh.exe, and uses it if present.

I have tested this in environments with and without sh.exe on the PATH and
confirmed it works as expected.

Signed-off-by: Peter Damianov 
---
 gcc/lto-wrapper.cc | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/gcc/lto-wrapper.cc b/gcc/lto-wrapper.cc
index 02579951569..a36a59e6fb8 100644
--- a/gcc/lto-wrapper.cc
+++ b/gcc/lto-wrapper.cc
@@ -2023,14 +2023,12 @@ cont:
  fprintf (mstream, "%s:\n\t@%s ", output_name, new_argv[0]);
  for (j = 1; new_argv[j] != NULL; ++j)
fprintf (mstream, " '%s'", new_argv[j]);
- fprintf (mstream, "\n");
  /* If we are not preserving the ltrans input files then
 truncate them as soon as we have processed it.  This
 reduces temporary disk-space usage.  */
  if (! save_temps)
-   fprintf (mstream, "\t@-touch -r \"%s\" \"%s.tem\" > /dev/null "
-"2>&1 && mv \"%s.tem\" \"%s\"\n",
-input_name, input_name, input_name, input_name); 
+   fprintf (mstream, " '-truncate' '%s'", input_name);
+ fprintf (mstream, "\n");
}
  else
{
-- 
2.39.2

Re: [PATCH 1/2] Driver: Add new -truncate option

[Andrew Pinski]

On Wed, Apr 17, 2024 at 5:57 PM Peter Damianov  wrote:
>
> This commit adds a new option to the driver that truncates one file after
> linking.
>
> Tested likeso:
>
> $ gcc hello.c -c
> $ du -h hello.o
> 4.0K  hello.o
> $ gcc hello.o -truncate hello
> $ ./a.out
> Hello world
> $ du -h hello.o
> $ 0   hello.o
>
> $ gcc hello.o -truncate
> gcc: error: missing filename after '-truncate'
>
> The motivation for adding this is PR110710. It is used by lto-wrapper to
> truncate files in a shell-independent manner.

I wonder if we should document this option or not. On one hand it is
only supposed to be used by lto but on the other hand, someone could
use it on accident from the command line and we would get a bug report
saying the file passed to it is now 0.

Thanks,
Andrew Pinski

>
> Signed-off-by: Peter Damianov 
> ---
>  gcc/common.opt |  5 +
>  gcc/gcc.cc | 13 +
>  2 files changed, 18 insertions(+)
>
> diff --git a/gcc/common.opt b/gcc/common.opt
> index ad348844775..3ede2fa8552 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -422,6 +422,11 @@ Display target specific command line options (including 
> assembler and linker opt
>  -time
>  Driver Alias(time)
>
> +;; Truncate the file specified after linking.
> +;; This option is used by lto-wrapper to reduce the peak disk when linking 
> with
> +;; many .LTRANS units.
> +Driver Separate Undocumented MissingArgError(missing filename after %qs)
> +
>  -verbose
>  Driver Alias(v)
>
> diff --git a/gcc/gcc.cc b/gcc/gcc.cc
> index 728332b8153..00017964295 100644
> --- a/gcc/gcc.cc
> +++ b/gcc/gcc.cc
> @@ -2138,6 +2138,10 @@ static int have_E = 0;
>  /* Pointer to output file name passed in with -o. */
>  static const char *output_file = 0;
>
> +/* Pointer to input file name passed in with -truncate.
> +   This file should be truncated after linking. */
> +static const char *totruncate_file = 0;
> +
>  /* This is the list of suffixes and codes (%g/%u/%U/%j) and the associated
> temp file.  If the HOST_BIT_BUCKET is used for %j, no entry is made for
> it here.  */
> @@ -4607,6 +4611,10 @@ driver_handle_option (struct gcc_options *opts,
>save_switch ("-o", 1, &arg, validated, true);
>return true;
>
> +case OPT_truncate:
> +  totruncate_file = arg;
> +  break;
> +
>  case OPT_pie:
>  #ifdef ENABLE_DEFAULT_PIE
>/* -pie is turned on by default.  */
> @@ -9273,6 +9281,11 @@ driver::maybe_run_linker (const char *argv0) const
>option).  */
> error ("%s: linker input file not found: %m", outfiles[i]);
> }
> +
> +  if (totruncate_file != NULL && linker_was_run && !seen_error ())
> +/* Truncate file specified by -truncate.
> +   Used by lto-wrapper to reduce temporary disk-space usage. */
> +truncate(totruncate_file, 0);
>  }
>
>  /* The end of "main".  */
> --
> 2.39.2
>

RE: [PATCH v2] DSE: Bugfix ICE after allow vector type in get_stored_val

[Li, Pan2]

Kindly ping^ for this ice fix.

Pan

-Original Message-
From: Li, Pan2 
Sent: Saturday, April 6, 2024 8:02 PM
To: Li, Pan2 ; Jeff Law ; Robin Dapp 
; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com; 
Wang, Yanzhang ; Liu, Hongtao 
Subject: RE: [PATCH v2] DSE: Bugfix ICE after allow vector type in 
get_stored_val

Kindly ping for this ice.

Pan

-Original Message-
From: Li, Pan2  
Sent: Saturday, March 23, 2024 1:45 PM
To: Jeff Law ; Robin Dapp ; 
gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com; 
Wang, Yanzhang ; Liu, Hongtao 
Subject: RE: [PATCH v2] DSE: Bugfix ICE after allow vector type in 
get_stored_val

Thanks Jeff for comments.

> As Richi noted using validate_subreg here isn't great.  Does it work to 
> factor out this code from extract_low_bits
>
>>   if (!int_mode_for_mode (src_mode).exists (&src_int_mode)
>>   || !int_mode_for_mode (mode).exists (&int_mode))
>> return NULL_RTX;
>> 
>>   if (!targetm.modes_tieable_p (src_int_mode, src_mode))
>> return NULL_RTX;
>>   if (!targetm.modes_tieable_p (int_mode, mode))
>> return NULL_RTX;

> And use that in the condition (and in extract_low_bits rather than 
> duplicating the code)?

It can solve the ICE but will forbid all vector modes goes gen_lowpart.
Actually only the vector mode size is less than reg nature size will trigger 
the ICE.
Thus, how about just add one more condition before goes to gen_lowpart as below?

Feel free to correct me if any misunderstandings. 😉!

diff --git a/gcc/dse.cc b/gcc/dse.cc
index edc7a1dfecf..258d2ccc299 100644
--- a/gcc/dse.cc
+++ b/gcc/dse.cc
@@ -1946,7 +1946,9 @@ get_stored_val (store_info *store_info, machine_mode 
read_mode,
 copy_rtx (store_info->const_rhs));
   else if (VECTOR_MODE_P (read_mode) && VECTOR_MODE_P (store_mode)
 && known_le (GET_MODE_BITSIZE (read_mode), GET_MODE_BITSIZE (store_mode))
-&& targetm.modes_tieable_p (read_mode, store_mode))
+&& targetm.modes_tieable_p (read_mode, store_mode)
+/* It's invalid in validate_subreg if read_mode size is < reg natural.  */
+&& known_ge (GET_MODE_SIZE (read_mode), REGMODE_NATURAL_SIZE (read_mode)))
 read_reg = gen_lowpart (read_mode, copy_rtx (store_info->rhs));
   else
 read_reg = extract_low_bits (read_mode, store_mode,

Pan

-Original Message-
From: Jeff Law  
Sent: Saturday, March 23, 2024 2:54 AM
To: Li, Pan2 ; Robin Dapp ; 
gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com; 
Wang, Yanzhang ; Liu, Hongtao 
Subject: Re: [PATCH v2] DSE: Bugfix ICE after allow vector type in 
get_stored_val



On 3/4/24 11:22 PM, Li, Pan2 wrote:
> Thanks Jeff for comments.
> 
>> But in the case of a vector modes, we can usually reinterpret the
>> underlying bits in whatever mode we want and do any of the usual
>> operations on those bits.
> 
> Yes, I think that is why we can allow vector mode in get_stored_val if my 
> understanding is correct.
> And then the different modes will return by gen_low_part. Unfortunately, 
> there are some modes
>   (less than a vector bit size like V2SF, V2QI for vlen=128) are considered 
> as invalid by validate_subreg,
> and return NULL_RTX result in the final ICE.
That doesn't make a lot of sense to me.  Even for vlen=128 I would have 
expected that we can still use a subreg to access low bits.  After all 
we might have had a V16QI vector and done a reduction of some sort 
storing the result in the first element and we have to be able to 
extract that result and move it around.

I'm not real keen on a target workaround.  While extremely safe, I 
wouldn't be surprised if other ports could trigger the ICE and we'd end 
up patching up multiple targets for what is, IMHO, a more generic issue.

As Richi noted using validate_subreg here isn't great.  Does it work to 
factor out this code from extract_low_bits:


>   if (!int_mode_for_mode (src_mode).exists (&src_int_mode)
>   || !int_mode_for_mode (mode).exists (&int_mode))
> return NULL_RTX;
> 
>   if (!targetm.modes_tieable_p (src_int_mode, src_mode))
> return NULL_RTX;
>   if (!targetm.modes_tieable_p (int_mode, mode))
> return NULL_RTX;

And use that in the condition (and in extract_low_bits rather than 
duplicating the code)?

jeff

ps.  No need to apologize for the pings.  This completely fell off my radar.

[PATCH, rs6000] Use bcdsub. instead of bcdadd. for bcd invalid number checking

[HAO CHEN GUI]

Hi,
  This patch replace bcdadd. with bcdsub. for bcd invalid number checking.
bcdadd on two same numbers might cause overflow which also set
overflow/invalid bit so that we can't distinguish it's invalid or overflow.
The bcdsub doesn't have the problem as subtracting on two same number never
causes overflow.

  Bootstrapped and tested on powerpc64-linux BE and LE with no
regressions. Is it OK for the trunk?

Thanks
Gui Haochen

ChangeLog
rs6000: Use bcdsub. instead of bcdadd. for bcd invalid number checking

bcdadd. might causes overflow which also set the overflow/invalid bit.
bcdsub. doesn't have the issue when do subtracting on two same bcd number.

gcc/
* config/rs6000/altivec.md (*bcdinvalid_): Replace bcdadd
with bcdsub.
(bcdinvalid_): Likewise.

gcc/testsuite/
* gcc.target/powerpc/bcd-4.c: Adjust the number of bcdadd and
bcdsub.

patch.diff
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 4d4c94ff0a0..bb20441c096 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -4586,18 +4586,18 @@ (define_insn "*bcdinvalid_"
   [(set (reg:CCFP CR6_REGNO)
(compare:CCFP
 (unspec:V2DF [(match_operand:VBCD 1 "register_operand" "v")]
- UNSPEC_BCDADD)
+ UNSPEC_BCDSUB)
 (match_operand:V2DF 2 "zero_constant" "j")))
(clobber (match_scratch:VBCD 0 "=v"))]
   "TARGET_P8_VECTOR"
-  "bcdadd. %0,%1,%1,0"
+  "bcdsub. %0,%1,%1,0"
   [(set_attr "type" "vecsimple")])

 (define_expand "bcdinvalid_"
   [(parallel [(set (reg:CCFP CR6_REGNO)
   (compare:CCFP
(unspec:V2DF [(match_operand:VBCD 1 "register_operand")]
-UNSPEC_BCDADD)
+UNSPEC_BCDSUB)
(match_dup 2)))
  (clobber (match_scratch:VBCD 3))])
(set (match_operand:SI 0 "register_operand")
diff --git a/gcc/testsuite/gcc.target/powerpc/bcd-4.c 
b/gcc/testsuite/gcc.target/powerpc/bcd-4.c
index 2c7041c4d32..6d2c59ef792 100644
--- a/gcc/testsuite/gcc.target/powerpc/bcd-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/bcd-4.c
@@ -2,8 +2,8 @@
 /* { dg-require-effective-target int128 } */
 /* { dg-require-effective-target p9vector_hw } */
 /* { dg-options "-mdejagnu-cpu=power9 -O2 -save-temps" } */
-/* { dg-final { scan-assembler-times {\mbcdadd\M} 7 } } */
-/* { dg-final { scan-assembler-times {\mbcdsub\M} 18 } } */
+/* { dg-final { scan-assembler-times {\mbcdadd\M} 5 } } */
+/* { dg-final { scan-assembler-times {\mbcdsub\M} 20 } } */
 /* { dg-final { scan-assembler-times {\mbcds\M} 2 } } */
 /* { dg-final { scan-assembler-times {\mdenbcdq\M} 1 } } */

Re: [PATCH 1/2] Driver: Add new -truncate option

[Peter0x44]

On 2024-04-17 17:56, Peter Damianov wrote:
This commit adds a new option to the driver that truncates one file 
after

linking.

Tested likeso:

$ gcc hello.c -c
$ du -h hello.o
4.0K  hello.o
$ gcc hello.o -truncate hello
$ ./a.out
Hello world
$ du -h hello.o
$ 0   hello.o

$ gcc hello.o -truncate
gcc: error: missing filename after '-truncate'

The motivation for adding this is PR110710. It is used by lto-wrapper 
to

truncate files in a shell-independent manner.

Signed-off-by: Peter Damianov 
---
 gcc/common.opt |  5 +
 gcc/gcc.cc | 13 +
 2 files changed, 18 insertions(+)

diff --git a/gcc/common.opt b/gcc/common.opt
index ad348844775..3ede2fa8552 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -422,6 +422,11 @@ Display target specific command line options 
(including assembler and linker opt

 -time
 Driver Alias(time)

+;; Truncate the file specified after linking.
+;; This option is used by lto-wrapper to reduce the peak disk when 
linking with

+;; many .LTRANS units.
+Driver Separate Undocumented MissingArgError(missing filename after 
%qs)

+
 -verbose
 Driver Alias(v)

diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 728332b8153..00017964295 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -2138,6 +2138,10 @@ static int have_E = 0;
 /* Pointer to output file name passed in with -o. */
 static const char *output_file = 0;

+/* Pointer to input file name passed in with -truncate.
+   This file should be truncated after linking. */
+static const char *totruncate_file = 0;
+
 /* This is the list of suffixes and codes (%g/%u/%U/%j) and the 
associated
temp file.  If the HOST_BIT_BUCKET is used for %j, no entry is made 
for

it here.  */
@@ -4607,6 +4611,10 @@ driver_handle_option (struct gcc_options *opts,
   save_switch ("-o", 1, &arg, validated, true);
   return true;

+case OPT_truncate:
+  totruncate_file = arg;
+  break;
+
 case OPT_pie:
 #ifdef ENABLE_DEFAULT_PIE
   /* -pie is turned on by default.  */
@@ -9273,6 +9281,11 @@ driver::maybe_run_linker (const char *argv0) 
const

   option).  */
error ("%s: linker input file not found: %m", outfiles[i]);
}
+
+  if (totruncate_file != NULL && linker_was_run && !seen_error ())
+/* Truncate file specified by -truncate.
+   Used by lto-wrapper to reduce temporary disk-space usage. */
+truncate(totruncate_file, 0);
On second thought, doing the truncation in driver::maybe_run_linker() 
seems wrong.

driver::final_actions seems like the better place to put this code.
Will resubmit.

 }

 /* The end of "main".  */

Re: [PATCH, rs6000] Use bcdsub. instead of bcdadd. for bcd invalid number checking

[Kewen.Lin]

Hi,

on 2024/4/18 10:01, HAO CHEN GUI wrote:
> Hi,
>   This patch replace bcdadd. with bcdsub. for bcd invalid number checking.
> bcdadd on two same numbers might cause overflow which also set
> overflow/invalid bit so that we can't distinguish it's invalid or overflow.
> The bcdsub doesn't have the problem as subtracting on two same number never
> causes overflow.
> 
>   Bootstrapped and tested on powerpc64-linux BE and LE with no
> regressions. Is it OK for the trunk?

Considering that this issue affects some basic functionality of bcd bifs
and the fix itself is simple and very safe, OK for trunk, thanks for fixing!

BR,
Kewen

> 
> Thanks
> Gui Haochen
> 
> ChangeLog
> rs6000: Use bcdsub. instead of bcdadd. for bcd invalid number checking
> 
> bcdadd. might causes overflow which also set the overflow/invalid bit.
> bcdsub. doesn't have the issue when do subtracting on two same bcd number.
> 
> gcc/
>   * config/rs6000/altivec.md (*bcdinvalid_): Replace bcdadd
>   with bcdsub.
>   (bcdinvalid_): Likewise.
> 
> gcc/testsuite/
>   * gcc.target/powerpc/bcd-4.c: Adjust the number of bcdadd and
>   bcdsub.
> 
> patch.diff
> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> index 4d4c94ff0a0..bb20441c096 100644
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -4586,18 +4586,18 @@ (define_insn "*bcdinvalid_"
>[(set (reg:CCFP CR6_REGNO)
>   (compare:CCFP
>(unspec:V2DF [(match_operand:VBCD 1 "register_operand" "v")]
> -   UNSPEC_BCDADD)
> +   UNSPEC_BCDSUB)
>(match_operand:V2DF 2 "zero_constant" "j")))
> (clobber (match_scratch:VBCD 0 "=v"))]
>"TARGET_P8_VECTOR"
> -  "bcdadd. %0,%1,%1,0"
> +  "bcdsub. %0,%1,%1,0"
>[(set_attr "type" "vecsimple")])
> 
>  (define_expand "bcdinvalid_"
>[(parallel [(set (reg:CCFP CR6_REGNO)
>  (compare:CCFP
>   (unspec:V2DF [(match_operand:VBCD 1 "register_operand")]
> -  UNSPEC_BCDADD)
> +  UNSPEC_BCDSUB)
>   (match_dup 2)))
> (clobber (match_scratch:VBCD 3))])
> (set (match_operand:SI 0 "register_operand")
> diff --git a/gcc/testsuite/gcc.target/powerpc/bcd-4.c 
> b/gcc/testsuite/gcc.target/powerpc/bcd-4.c
> index 2c7041c4d32..6d2c59ef792 100644
> --- a/gcc/testsuite/gcc.target/powerpc/bcd-4.c
> +++ b/gcc/testsuite/gcc.target/powerpc/bcd-4.c
> @@ -2,8 +2,8 @@
>  /* { dg-require-effective-target int128 } */
>  /* { dg-require-effective-target p9vector_hw } */
>  /* { dg-options "-mdejagnu-cpu=power9 -O2 -save-temps" } */
> -/* { dg-final { scan-assembler-times {\mbcdadd\M} 7 } } */
> -/* { dg-final { scan-assembler-times {\mbcdsub\M} 18 } } */
> +/* { dg-final { scan-assembler-times {\mbcdadd\M} 5 } } */
> +/* { dg-final { scan-assembler-times {\mbcdsub\M} 20 } } */
>  /* { dg-final { scan-assembler-times {\mbcds\M} 2 } } */
>  /* { dg-final { scan-assembler-times {\mdenbcdq\M} 1 } } */
> 

[PATCH] Fix link on gcc-13/changes.html

[Andrew Pinski]

Just fixes the link to the manual for the new -nostdlib++ option.

Signed-off-by: Andrew Pinski 
---
 htdocs/gcc-13/changes.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 6930bd58..4384c329 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -369,7 +369,7 @@ You may also want to check out our
   The https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/C_002b_002b-Dialect-Options.html#index-Wpessimizing-move";>-Wpessimizing-move
 and https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/C_002b_002b-Dialect-Options.html#index-Wredundant-move";>-Wredundant-move
 warnings have been extended to warn in more contexts.
-  The https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Link_Options.html#index-nostdlib_002b_002b";>-nostdlib++
+  The https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Link-Options.html#index-nostdlib_002b_002b";>-nostdlib++
 option has been added, to enable linking with g++
 without implicitly linking in the C++ standard library.
 
-- 
2.43.0

[PATCH v2 1/2] Driver: Add new -truncate option

[Peter Damianov]

This commit adds a new option to the driver that truncates one file after
linking.

Tested likeso:

$ gcc hello.c -c
$ du -h hello.o
4.0K  hello.o
$ gcc hello.o -truncate hello
$ ./a.out
Hello world
$ du -h hello.o
$ 0   hello.o

$ gcc hello.o -truncate
gcc: error: missing filename after '-truncate'

The motivation for adding this is PR110710. It is used by lto-wrapper to
truncate files in a shell-independent manner.

Signed-off-by: Peter Damianov 
---
v2: moved truncation to driver::final_actions
v2: moved handling of OPT_truncate to be in alphabetic order

 gcc/common.opt |  6 ++
 gcc/gcc.cc | 13 +
 2 files changed, 19 insertions(+)

diff --git a/gcc/common.opt b/gcc/common.opt
index ad348844775..40cab3cb36a 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -422,6 +422,12 @@ Display target specific command line options (including 
assembler and linker opt
 -time
 Driver Alias(time)
 
+;; Truncate the file specified after linking.
+;; This option is used by lto-wrapper to reduce the peak disk-usage when
+;; linking with many .LTRANS units.
+truncate
+Driver Separate Undocumented MissingArgError(missing filename after %qs)
+
 -verbose
 Driver Alias(v)
 
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 728332b8153..b4169bbd3be 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -2138,6 +2138,10 @@ static int have_E = 0;
 /* Pointer to output file name passed in with -o. */
 static const char *output_file = 0;
 
+/* Pointer to input file name passed in with -truncate.
+   This file should be truncated after linking. */
+static const char *totruncate_file = 0;
+
 /* This is the list of suffixes and codes (%g/%u/%U/%j) and the associated
temp file.  If the HOST_BIT_BUCKET is used for %j, no entry is made for
it here.  */
@@ -4538,6 +4542,10 @@ driver_handle_option (struct gcc_options *opts,
   do_save = false;
   break;
 
+case OPT_truncate:
+  totruncate_file = arg;
+  break;
+
 case OPT:
   /* "-###"
 This is similar to -v except that there is no execution
@@ -9286,6 +9294,11 @@ driver::final_actions () const
 delete_failure_queue ();
   delete_temp_files ();
 
+  if (totruncate_file != NULL && !seen_error ())
+/* Truncate file specified by -truncate.
+   Used by lto-wrapper to reduce temporary disk-space usage. */
+truncate(totruncate_file, 0);
+
   if (print_help_list)
 {
   printf (("\nFor bug reporting instructions, please see:\n"));
-- 
2.39.2

[PATCH v2 2/2] lto-wrapper: Truncate files using -truncate driver option [PR110710]

[Peter Damianov]

This commit changes the Makefiles generated by lto-wrapper to no longer use
the "mv" and "touch" shell commands. These don't exist on Windows, so when the
Makefile attempts to call them, it results in errors like:
The system cannot find the file specified.

This problem only manifested when calling gcc from cmd.exe, and having no
sh.exe present on the PATH. The Windows port of GNU Make searches the PATH for
an sh.exe, and uses it if present.

I have tested this in environments with and without sh.exe on the PATH and
confirmed it works as expected.

Signed-off-by: Peter Damianov 
---
 gcc/lto-wrapper.cc | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/gcc/lto-wrapper.cc b/gcc/lto-wrapper.cc
index 02579951569..a36a59e6fb8 100644
--- a/gcc/lto-wrapper.cc
+++ b/gcc/lto-wrapper.cc
@@ -2023,14 +2023,12 @@ cont:
  fprintf (mstream, "%s:\n\t@%s ", output_name, new_argv[0]);
  for (j = 1; new_argv[j] != NULL; ++j)
fprintf (mstream, " '%s'", new_argv[j]);
- fprintf (mstream, "\n");
  /* If we are not preserving the ltrans input files then
 truncate them as soon as we have processed it.  This
 reduces temporary disk-space usage.  */
  if (! save_temps)
-   fprintf (mstream, "\t@-touch -r \"%s\" \"%s.tem\" > /dev/null "
-"2>&1 && mv \"%s.tem\" \"%s\"\n",
-input_name, input_name, input_name, input_name); 
+   fprintf (mstream, " '-truncate' '%s'", input_name);
+ fprintf (mstream, "\n");
}
  else
{
-- 
2.39.2

Re: [PATCH v2 1/2] Driver: Add new -truncate option

[Richard Biener]

On Thu, Apr 18, 2024 at 6:12 AM Peter Damianov  wrote:
>
> This commit adds a new option to the driver that truncates one file after
> linking.
>
> Tested likeso:
>
> $ gcc hello.c -c
> $ du -h hello.o
> 4.0K  hello.o
> $ gcc hello.o -truncate hello
> $ ./a.out
> Hello world
> $ du -h hello.o
> $ 0   hello.o

I suppose it should have been

$ gcc hello.o -truncate hello.o

in the example.

> $ gcc hello.o -truncate
> gcc: error: missing filename after '-truncate'
>
> The motivation for adding this is PR110710. It is used by lto-wrapper to
> truncate files in a shell-independent manner.

This looks good to me.

Thanks,
Richard.

> Signed-off-by: Peter Damianov 
> ---
> v2: moved truncation to driver::final_actions
> v2: moved handling of OPT_truncate to be in alphabetic order
>
>  gcc/common.opt |  6 ++
>  gcc/gcc.cc | 13 +
>  2 files changed, 19 insertions(+)
>
> diff --git a/gcc/common.opt b/gcc/common.opt
> index ad348844775..40cab3cb36a 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -422,6 +422,12 @@ Display target specific command line options (including 
> assembler and linker opt
>  -time
>  Driver Alias(time)
>
> +;; Truncate the file specified after linking.
> +;; This option is used by lto-wrapper to reduce the peak disk-usage when
> +;; linking with many .LTRANS units.
> +truncate
> +Driver Separate Undocumented MissingArgError(missing filename after %qs)
> +
>  -verbose
>  Driver Alias(v)
>
> diff --git a/gcc/gcc.cc b/gcc/gcc.cc
> index 728332b8153..b4169bbd3be 100644
> --- a/gcc/gcc.cc
> +++ b/gcc/gcc.cc
> @@ -2138,6 +2138,10 @@ static int have_E = 0;
>  /* Pointer to output file name passed in with -o. */
>  static const char *output_file = 0;
>
> +/* Pointer to input file name passed in with -truncate.
> +   This file should be truncated after linking. */
> +static const char *totruncate_file = 0;
> +
>  /* This is the list of suffixes and codes (%g/%u/%U/%j) and the associated
> temp file.  If the HOST_BIT_BUCKET is used for %j, no entry is made for
> it here.  */
> @@ -4538,6 +4542,10 @@ driver_handle_option (struct gcc_options *opts,
>do_save = false;
>break;
>
> +case OPT_truncate:
> +  totruncate_file = arg;
> +  break;
> +
>  case OPT:
>/* "-###"
>  This is similar to -v except that there is no execution
> @@ -9286,6 +9294,11 @@ driver::final_actions () const
>  delete_failure_queue ();
>delete_temp_files ();
>
> +  if (totruncate_file != NULL && !seen_error ())
> +/* Truncate file specified by -truncate.
> +   Used by lto-wrapper to reduce temporary disk-space usage. */
> +truncate(totruncate_file, 0);
> +
>if (print_help_list)
>  {
>printf (("\nFor bug reporting instructions, please see:\n"));
> --
> 2.39.2
>

Re: [PATCH v2 2/2] lto-wrapper: Truncate files using -truncate driver option [PR110710]

[Richard Biener]

On Thu, Apr 18, 2024 at 6:12 AM Peter Damianov  wrote:
>
> This commit changes the Makefiles generated by lto-wrapper to no longer use
> the "mv" and "touch" shell commands. These don't exist on Windows, so when the
> Makefile attempts to call them, it results in errors like:
> The system cannot find the file specified.
>
> This problem only manifested when calling gcc from cmd.exe, and having no
> sh.exe present on the PATH. The Windows port of GNU Make searches the PATH for
> an sh.exe, and uses it if present.
>
> I have tested this in environments with and without sh.exe on the PATH and
> confirmed it works as expected.

OK.

Thanks,
Richard.

> Signed-off-by: Peter Damianov 
> ---
>  gcc/lto-wrapper.cc | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/lto-wrapper.cc b/gcc/lto-wrapper.cc
> index 02579951569..a36a59e6fb8 100644
> --- a/gcc/lto-wrapper.cc
> +++ b/gcc/lto-wrapper.cc
> @@ -2023,14 +2023,12 @@ cont:
>   fprintf (mstream, "%s:\n\t@%s ", output_name, new_argv[0]);
>   for (j = 1; new_argv[j] != NULL; ++j)
> fprintf (mstream, " '%s'", new_argv[j]);
> - fprintf (mstream, "\n");
>   /* If we are not preserving the ltrans input files then
>  truncate them as soon as we have processed it.  This
>  reduces temporary disk-space usage.  */
>   if (! save_temps)
> -   fprintf (mstream, "\t@-touch -r \"%s\" \"%s.tem\" > /dev/null 
> "
> -"2>&1 && mv \"%s.tem\" \"%s\"\n",
> -input_name, input_name, input_name, input_name);
> +   fprintf (mstream, " '-truncate' '%s'", input_name);
> + fprintf (mstream, "\n");
> }
>   else
> {
> --
> 2.39.2
>