[Bug c++/114997] ICE with -std=c++20: unexpected expression ‘static_cast('\"')’ of kind static_cast_expr

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
Reduced testcase:
```
typedef int vv __attribute__((__vector_size__(sizeof(int;
constexpr vv ff(int code) { return vv{code}; }
template  struct h {
typedef _Tp type;
};
template  void f() {
using ut = h::type;
constexpr auto c = ff(static_cast('\\'));
}
```

Results for 13.2.1 20240507 [releases/gcc-13 r13-8735-g44d84db11a] (GCC) testsuite on powerpc64-unknown-linux-gnu

[Bill Seurer (POWER9 BE) via Gcc-testresults]

git commit g:44d84db11ab724c34a8b1f8c0e06da1cc78439a2
gcc-descr r13-8735-g44d84db11ab724

power9 BE
Linux 6.7.12-powerpc64 ppc64
GNU Make 4.3

DejaGnu:
DejaGnu version 1.6.3
Expect version  5.45.4
Tcl version 8.6

64-bit

LAST_UPDATED: Thu May  9 04:31:25 UTC 2024 (revision r13-8735-g44d84db11a)

Native configuration is powerpc64-unknown-linux-gnu

=== g++ tests ===


Running target unix/-m32
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors)

=== g++ Summary for unix/-m32 ===

# of expected passes226092
# of unexpected failures2
# of expected failures  1929
# of unsupported tests  10895

Running target unix/-m64

=== g++ Summary for unix/-m64 ===

# of expected passes235036
# of expected failures  1937
# of unsupported tests  11083

=== g++ Summary ===

# of expected passes461128
# of unexpected failures2
# of expected failures  3866
# of unsupported tests  21978
/home/gccbuild/build/nightly/build-gcc-13/gcc/xg++  version 13.2.1 20240507 
[releases/gcc-13 r13-8735-g44d84db11a] (GCC) 

=== gcc tests ===


Running target unix/-m32
XPASS: gcc.dg/guality/example.c   -O0  execution test
XPASS: gcc.dg/guality/example.c   -O1  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/example.c  -Og -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O0  execution test
XPASS: gcc.dg/guality/guality.c   -O1  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O2  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/guality.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/guality.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -Os  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c  -Og -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/inline-params.c   -O2  -DPREVENT_OPTIMIZATION  execution 
test
XPASS: gcc.dg/guality/inline-params.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/inline-params.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/inline-params.c   -O3 -g  -DPREVENT_OPTIMIZATION  
execution test
XPASS: gcc.dg/guality/inline-params.c   -Os  -DPREVENT_OPTIMIZATION  execution 
test
XPASS: gcc.dg/guality/ipa-sra-1.c   -O0  line 15 k == 3
XPASS: gcc.dg/guality/ipa-sra-1.c   -O1  -DPREVENT_OPTIMIZATION  line 15 k == 3
XPASS: gcc.dg/guality/ipa-sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 15 k == 3
FAIL: gcc.dg/guality/loop-1.c   -O2  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 18 y == 
2
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg1 == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg2 == 2
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg3 == 3
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg4 == 4
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg5 == 5
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg6 == 6
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg7 == 30
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg1 == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg2 == 2
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 

Re: [PATCH] rs6000: Enable overlapped by-pieces operations

[Kewen.Lin]

Hi,

on 2024/5/8 14:47, HAO CHEN GUI wrote:
> Hi,
>   This patch enables overlapped by-piece operations. On rs6000, default
> move/set/clear ratio is 2. So the overlap is only enabled with compare
> by-pieces.

Thanks for enabling this, did you evaluate if it can help some benchmark?

> 
>   Bootstrapped and tested on powerpc64-linux BE and LE with no
> regressions. Is it OK for the trunk?
> 
> Thanks
> Gui Haochen
> 
> ChangeLog
> rs6000: Enable overlapped by-pieces operations
> 
> This patch enables overlapped by-piece operations by defining
> TARGET_OVERLAP_OP_BY_PIECES_P to true.  On rs6000, default move/set/clear
> ratio is 2.  So the overlap is only enabled with compare by-pieces.
> 
> gcc/
>   * config/rs6000/rs6000.cc (TARGET_OVERLAP_OP_BY_PIECES_P): Define.
> 
> gcc/testsuite/
>   * gcc.target/powerpc/block-cmp-9.c: New.
> 
> 
> patch.diff
> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> index 6b9a40fcc66..2b5f5cf1d86 100644
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -1774,6 +1774,9 @@ static const scoped_attribute_specs *const 
> rs6000_attribute_table[] =
>  #undef TARGET_CONST_ANCHOR
>  #define TARGET_CONST_ANCHOR 0x8000
> 
> +#undef TARGET_OVERLAP_OP_BY_PIECES_P
> +#define TARGET_OVERLAP_OP_BY_PIECES_P hook_bool_void_true
> +
>  
> 
>  /* Processor table.  */
> diff --git a/gcc/testsuite/gcc.target/powerpc/block-cmp-9.c 
> b/gcc/testsuite/gcc.target/powerpc/block-cmp-9.c
> new file mode 100644
> index 000..b5f51affbb7
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/block-cmp-9.c
> @@ -0,0 +1,11 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power8" } */

Why does it need power8 forced here?

BR,
Kewen

> +/* { dg-final { scan-assembler-not {\ml[hb]z\M} } } */
> +
> +/* Test if by-piece overlap compare is enabled and following case is
> +   implemented by two overlap word loads and compares.  */
> +
> +int foo (const char* s1, const char* s2)
> +{
> +  return __builtin_memcmp (s1, s2, 7) == 0;
> +}

Results for 13.2.1 20240507 [releases/gcc-13 r13-8735-g44d84db11a] (GCC) testsuite on powerpc64le-unknown-linux-gnu

[Bill Seurer (POWER9 IEEE128) via Gcc-testresults]

git commit g:44d84db11ab724c34a8b1f8c0e06da1cc78439a2
gcc-descr r13-8735-g44d84db11ab724

power9 IEEE128
Linux 6.9.0-0.rc6.52.fc41.ppc64le ppc64le
GNU Make 4.4.1

DejaGnu:
DejaGnu version 1.6.3
Expect version  5.45.4
Tcl version 8.6

64-bit

LAST_UPDATED: Thu May  9 04:33:11 UTC 2024 (revision r13-8735-g44d84db11a)

Native configuration is powerpc64le-unknown-linux-gnu

=== gcc tests ===


Running target unix
FAIL: gcc.dg/analyzer/data-model-4.c (test for excess errors)
FAIL: gcc.dg/analyzer/torture/conftest-1.c   -O0  (test for excess errors)
FAIL: gcc.dg/analyzer/torture/conftest-1.c   -O1  (test for excess errors)
FAIL: gcc.dg/analyzer/torture/conftest-1.c   -O2  (test for excess errors)
FAIL: gcc.dg/analyzer/torture/conftest-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (test for excess errors)
FAIL: gcc.dg/analyzer/torture/conftest-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.dg/analyzer/torture/conftest-1.c   -Os  (test for excess errors)
XPASS: gcc.dg/Wtrampolines.c standard descriptors (test for warnings, line 29)
FAIL: gcc.dg/torture/float128-cmp-invalid.c   -O0  execution test
FAIL: gcc.dg/torture/float128-cmp-invalid.c   -O1  execution test
FAIL: gcc.dg/torture/float128-cmp-invalid.c   -O2  execution test
FAIL: gcc.dg/torture/float128-cmp-invalid.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  execution test
FAIL: gcc.dg/torture/float128-cmp-invalid.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/float128-cmp-invalid.c   -O3 -g  execution test
FAIL: gcc.dg/torture/float128-cmp-invalid.c   -Os  execution test
FAIL: gcc.dg/torture/pr52451.c   -O0  execution test
FAIL: gcc.dg/torture/pr52451.c   -O1  execution test
FAIL: gcc.dg/torture/pr52451.c   -O2  execution test
FAIL: gcc.dg/torture/pr52451.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  execution test
FAIL: gcc.dg/torture/pr52451.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/pr52451.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr52451.c   -Os  execution test
FAIL: gcc.dg/torture/pr91323.c   -O0  execution test
FAIL: gcc.dg/torture/pr91323.c   -O1  execution test
FAIL: gcc.dg/torture/pr91323.c   -O2  execution test
FAIL: gcc.dg/torture/pr91323.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  execution test
FAIL: gcc.dg/torture/pr91323.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/pr91323.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr91323.c   -Os  execution test
XPASS: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized "return 28;"
FAIL: gcc.target/powerpc/pr105334.c (test for excess errors)
FAIL: gcc.target/powerpc/rlwimi-2.c scan-assembler-times (?n)^s+[a-z] 20217
FAIL: gcc.target/powerpc/rs6000-fpint.c scan-assembler-not stfiwx
XPASS: gcc.target/powerpc/ppc-fortran/ieee128-math.f90   -O  (test for excess 
errors)

=== gcc Summary ===

# of expected passes165992
# of unexpected failures31
# of unexpected successes   3
# of expected failures  1481
# of unsupported tests  2974
/home/gccbuild/build/nightly/build-gcc-13/gcc/xgcc  version 13.2.1 20240507 
[releases/gcc-13 r13-8735-g44d84db11a] (GCC) 

=== gfortran tests ===


Running target unix
XPASS: gfortran.dg/default_format_2.f90   -O0  execution test
XPASS: gfortran.dg/default_format_2.f90   -O1  execution test
XPASS: gfortran.dg/default_format_2.f90   -O2  execution test
XPASS: gfortran.dg/default_format_2.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
XPASS: gfortran.dg/default_format_2.f90   -O3 -g  execution test
XPASS: gfortran.dg/default_format_2.f90   -Os  execution test
XPASS: gfortran.dg/default_format_denormal_2.f90   -O0  execution test
XPASS: gfortran.dg/default_format_denormal_2.f90   -O1  execution test
XPASS: gfortran.dg/default_format_denormal_2.f90   -O2  execution test
XPASS: gfortran.dg/default_format_denormal_2.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
XPASS: gfortran.dg/default_format_denormal_2.f90   -O3 -g  execution test
XPASS: gfortran.dg/default_format_denormal_2.f90   -Os  execution test
XPASS: gfortran.dg/large_real_kind_form_io_2.f90   -O0  execution test
XPASS: gfortran.dg/large_real_kind_form_io_2.f90   -O1  execution test
XPASS: gfortran.dg/large_real_kind_form_io_2.f90   -O2  execution test
XPASS: gfortran.dg/large_real_kind_form_io_2.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
XPASS: gfortran.dg/large_real_kind_form_io_2.f90   -O3 -g  execution test
XPASS: gfortran.dg/large_real_kind_form_io_2.f90   -Os  execution test

=== gfortran Summary ===

# of expected passes68266
# of unexpected successes   18
# of expected failures

Re: [PATCH 2/4] fortran: Teach get_real_kind_from_node for Power 128 fp modes [PR112993]g

[Kewen.Lin]

Hi,

on 2024/5/9 06:01, Steve Kargl wrote:
> On Wed, May 08, 2024 at 01:27:53PM +0800, Kewen.Lin wrote:
>>
>> Previously effective target fortran_real_c_float128 never
>> passes on Power regardless of the default 128 long double
>> is ibmlongdouble or ieeelongdouble.  It's due to that TF
>> mode is always used for kind 16 real, which has precision
>> 127, while the node float128_type_node for c_float128 has
>> 128 type precision, get_real_kind_from_node can't find a
>> matching as it only checks gfc_real_kinds[i].mode_precision
>> and type precision.
>>
>> With changing TFmode/IFmode/KFmode to have the same mode
>> precision 128, now fortran_real_c_float12 can pass with
>> ieeelongdouble enabled by default and test cases guarded
>> with it get tested accordingly.  But with ibmlongdouble
>> enabled by default, since TFmode has precision 128 which
>> is the same as type precision 128 of float128_type_node,
>> get_real_kind_from_node considers kind for TFmode matches
>> float128_type_node, but it's wrong as at this time point
>> TFmode is with ibm extended format.  So this patch is to
>> teach get_real_kind_from_node to check one more field which
>> can be differentiable from the underlying real format, it
>> can avoid the unexpected matching when there more than one
>> modes have the same precision.
>>
>> Bootstrapped and regress-tested on:
>>   - powerpc64-linux-gnu P8/P9 (with ibm128 by default)
>>   - powerpc64le-linux-gnu P9/P10 (with ibm128 by default)
>>   - powerpc64le-linux-gnu P9 (with ieee128 by default)
>>
>> BR,
>> Kewen
>> -
>>  PR target/112993
>>

> OK from the fortran point of view.
> Thanks.

> 
> First, I have no issue with Mikael's OK for committing the
> patch. 

Thanks to both!

> 
> That said, Fortran has the concept of model numbers, which
> are set in arith.c.  Does this change give the expected 
> value for ibm128?  For example, with "REAL(16) X", one
> has "DIGITS(X) = 113", which is the precision on the 
> of the underlying IEEE754 binary128 type.
> 

With some testings locally, I noticed that currently DIGITS has
been already correct even without this change.  For "REAL(16) X",
with -mabi=ibmlongdouble it's long double with ibm128 format and
its DIGITS(X) is 106, while with -mabi=ieeelongdouble it's long
double with ieee128 format and its DIGITS(X) is 113.

BR,
Kewen

Re: [PATCH] [ranger] Force buffer alignment in Value_Range [PR114912]

[Aldy Hernandez]

Pushed to trunk to unblock sparc.


On Fri, May 3, 2024 at 4:24 PM Aldy Hernandez  wrote:
>
> Ahh, that is indeed cleaner, and there's no longer a need to assert
> the sizeof of individual ranges.
>
> It looks like a default constructor is needed for the buffer now, but
> only for the default constructor of Value_Range.
>
> I have verified that the individual range constructors are not called
> on initialization to Value_Range, which was the original point of the
> patch.  I have also run our performance suite, and there are no
> changes to VRP or overall.
>
> I would appreciate a review from someone more C++ savvy than me :).
>
> OK for trunk?
>
> On Fri, May 3, 2024 at 11:32 AM Andrew Pinski  wrote:
> >
> > On Fri, May 3, 2024 at 2:24 AM Aldy Hernandez  wrote:
> > >
> > > Sparc requires strict alignment and is choking on the byte vector in
> > > Value_Range.  Is this the right approach, or is there a more canonical
> > > way of forcing alignment?
> >
> > I think the suggestion was to change over to use an union and use the
> > types directly in the union (anonymous unions and unions containing
> > non-PODs are part of C++11).
> > That is:
> > union {
> >   int_range_max int_range;
> >   frange fload_range;
> >   unsupported_range un_range;
> > };
> > ...
> > m_vrange = new (_range) int_range_max ();
> > ...
> >
> > Also the canonical way of forcing alignment in C++ is to use aliagnas
> > as my patch in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
> > did.
> > Also I suspect the alignment is not word alignment but rather the
> > alignment of HOST_WIDE_INT which is not always the same as the
> > alignment of the pointer but bigger and that is why it is failing on
> > sparc (32bit rather than 64bit).
> >
> > Thanks,
> > Andrew Pinski
> >
> > >
> > > If this is correct, OK for trunk?
> > >
> > > gcc/ChangeLog:
> > >
> > > * value-range.h (class Value_Range): Use a union.
> > > ---
> > >  gcc/value-range.h | 24 +++-
> > >  1 file changed, 15 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/gcc/value-range.h b/gcc/value-range.h
> > > index 934eec9e386..31af7888018 100644
> > > --- a/gcc/value-range.h
> > > +++ b/gcc/value-range.h
> > > @@ -740,9 +740,14 @@ private:
> > >void init (const vrange &);
> > >
> > >vrange *m_vrange;
> > > -  // The buffer must be at least the size of the largest range.
> > > -  static_assert (sizeof (int_range_max) > sizeof (frange), "");
> > > -  char m_buffer[sizeof (int_range_max)];
> > > +  union {
> > > +// The buffer must be at least the size of the largest range, and
> > > +// be aligned on a word boundary for strict alignment targets
> > > +// such as sparc.
> > > +static_assert (sizeof (int_range_max) > sizeof (frange), "");
> > > +char m_buffer[sizeof (int_range_max)];
> > > +void *align;
> > > +  } u;
> > >  };
> > >
> > >  // The default constructor is uninitialized and must be initialized
> > > @@ -816,11 +821,11 @@ Value_Range::init (tree type)
> > >gcc_checking_assert (TYPE_P (type));
> > >
> > >if (irange::supports_p (type))
> > > -m_vrange = new (_buffer) int_range_max ();
> > > +m_vrange = new (_buffer) int_range_max ();
> > >else if (frange::supports_p (type))
> > > -m_vrange = new (_buffer) frange ();
> > > +m_vrange = new (_buffer) frange ();
> > >else
> > > -m_vrange = new (_buffer) unsupported_range ();
> > > +m_vrange = new (_buffer) unsupported_range ();
> > >  }
> > >
> > >  // Initialize object with a copy of R.
> > > @@ -829,11 +834,12 @@ inline void
> > >  Value_Range::init (const vrange )
> > >  {
> > >if (is_a  (r))
> > > -m_vrange = new (_buffer) int_range_max (as_a  (r));
> > > +m_vrange = new (_buffer) int_range_max (as_a  (r));
> > >else if (is_a  (r))
> > > -m_vrange = new (_buffer) frange (as_a  (r));
> > > +m_vrange = new (_buffer) frange (as_a  (r));
> > >else
> > > -m_vrange = new (_buffer) unsupported_range (as_a 
> > >  (r));
> > > +m_vrange
> > > +  = new (_buffer) unsupported_range (as_a  
> > > (r));
> > >  }
> > >
> > >  // Assignment operator.  Copying incompatible types is allowed.  That
> > > --
> > > 2.44.0
> > >
> >

[gcc r15-336] [ranger] Force buffer alignment in Value_Range [PR114912]

[Aldy Hernandez via Gcc-cvs]

https://gcc.gnu.org/g:d7ff8ae5313bea755f5960786b33a7b151e7b663

commit r15-336-gd7ff8ae5313bea755f5960786b33a7b151e7b663
Author: Aldy Hernandez 
Date:   Fri May 3 11:17:32 2024 +0200

[ranger] Force buffer alignment in Value_Range [PR114912]

gcc/ChangeLog:

PR tree-optimization/114912
* value-range.h (class Value_Range): Use a union.

Diff:
---
 gcc/value-range.h | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/gcc/value-range.h b/gcc/value-range.h
index 6e24874c0a25..44cdbd717f4c 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -800,10 +800,14 @@ private:
   void init (const vrange &);
 
   vrange *m_vrange;
-  // The buffer must be at least the size of the largest range.
-  static_assert (sizeof (int_range_max) > sizeof (frange), "");
-  static_assert (sizeof (int_range_max) > sizeof (prange), "");
-  char m_buffer[sizeof (int_range_max)];
+  union buffer_type {
+int_range_max ints;
+frange floats;
+unsupported_range unsupported;
+prange pointers;
+buffer_type () { }
+~buffer_type () { }
+  } m_buffer;
 };
 
 // The default constructor is uninitialized and must be initialized
@@ -811,6 +815,7 @@ private:
 
 inline
 Value_Range::Value_Range ()
+  : m_buffer ()
 {
   m_vrange = NULL;
 }
@@ -877,13 +882,13 @@ Value_Range::init (tree type)
   gcc_checking_assert (TYPE_P (type));
 
   if (irange::supports_p (type))
-m_vrange = new (_buffer) int_range_max ();
+m_vrange = new (_buffer.ints) int_range_max ();
   else if (prange::supports_p (type))
-m_vrange = new (_buffer) prange ();
+m_vrange = new (_buffer.pointers) prange ();
   else if (frange::supports_p (type))
-m_vrange = new (_buffer) frange ();
+m_vrange = new (_buffer.floats) frange ();
   else
-m_vrange = new (_buffer) unsupported_range ();
+m_vrange = new (_buffer.unsupported) unsupported_range ();
 }
 
 // Initialize object with a copy of R.
@@ -892,13 +897,14 @@ inline void
 Value_Range::init (const vrange )
 {
   if (is_a  (r))
-m_vrange = new (_buffer) int_range_max (as_a  (r));
+m_vrange = new (_buffer.ints) int_range_max (as_a  (r));
   else if (is_a  (r))
-m_vrange = new (_buffer) prange (as_a  (r));
+m_vrange = new (_buffer.pointers) prange (as_a  (r));
   else if (is_a  (r))
-m_vrange = new (_buffer) frange (as_a  (r));
+m_vrange = new (_buffer.floats) frange (as_a  (r));
   else
-m_vrange = new (_buffer) unsupported_range (as_a  
(r));
+m_vrange = new (_buffer.unsupported)
+  unsupported_range (as_a  (r));
 }
 
 // Assignment operator.  Copying incompatible types is allowed.  That

[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Aldy Hernandez :

https://gcc.gnu.org/g:d7ff8ae5313bea755f5960786b33a7b151e7b663

commit r15-336-gd7ff8ae5313bea755f5960786b33a7b151e7b663
Author: Aldy Hernandez 
Date:   Fri May 3 11:17:32 2024 +0200

[ranger] Force buffer alignment in Value_Range [PR114912]

gcc/ChangeLog:

PR tree-optimization/114912
* value-range.h (class Value_Range): Use a union.

[gcc r15-335] [prange] Reword dispatch error message

[Aldy Hernandez via Gcc-cvs]

https://gcc.gnu.org/g:be3df704ce7de417682d57bc3e819dfcf0fdd501

commit r15-335-gbe3df704ce7de417682d57bc3e819dfcf0fdd501
Author: Aldy Hernandez 
Date:   Wed May 8 22:50:22 2024 +0200

[prange] Reword dispatch error message

After reading the ICE for the PR, it's obvious the error message is
rather cryptic.  This makes it less so.

gcc/ChangeLog:

* range-op.cc (range_op_handler::discriminator_fail): Reword error
message.

Diff:
---
 gcc/range-op.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 245385fe4876..e00136479a6d 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -197,7 +197,8 @@ range_op_handler::discriminator_fail (const vrange ,
   gcc_checking_assert (r1.m_discriminator < sizeof (name) - 1);
   gcc_checking_assert (r2.m_discriminator < sizeof (name) - 1);
   gcc_checking_assert (r3.m_discriminator < sizeof (name) - 1);
-  fprintf (stderr, "DISCRIMINATOR FAIL.  Dispatch > RO_%c%c%c <\n",
+  fprintf (stderr,
+  "Unsupported operand combination in dispatch: RO_%c%c%c\n",
   name[r1.m_discriminator],
   name[r2.m_discriminator],
   name[r3.m_discriminator]);

[COMMITTED] [prange] Reword dispatch error message [PR114985]

[Aldy Hernandez]

After reading the ICE for the PR, it's obvious the error message is
rather cryptic.  This makes it less so.

gcc/ChangeLog:

* range-op.cc (range_op_handler::discriminator_fail): Reword error
message.
---
 gcc/range-op.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 65f3843227d..a134af68141 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -207,7 +207,8 @@ range_op_handler::discriminator_fail (const vrange ,
   gcc_checking_assert (r1.m_discriminator < sizeof (name) - 1);
   gcc_checking_assert (r2.m_discriminator < sizeof (name) - 1);
   gcc_checking_assert (r3.m_discriminator < sizeof (name) - 1);
-  fprintf (stderr, "DISCRIMINATOR FAIL.  Dispatch > RO_%c%c%c <\n",
+  fprintf (stderr,
+  "Unsupported operand combination in dispatch: RO_%c%c%c\n",
   name[r1.m_discriminator],
   name[r2.m_discriminator],
   name[r3.m_discriminator]);
-- 
2.45.0

Re: [PATCH] i386: Fix some intrinsics without alignment requirements.

[Hongtao Liu]

On Wed, May 8, 2024 at 10:13 AM Hu, Lin1  wrote:
>
> Hi all,
>
> This patch aims to fix some intrinsics without alignment requirement, but
> raised runtime error's problem.
>
> Bootstrapped and tested on x86_64-linux-gnu, OK for trunk?
Ok.
>
> BRs,
> Lin
>
> gcc/ChangeLog:
>
> PR target/84508
> * config/i386/emmintrin.h
> (_mm_load_sd): Remove alignment requirement.
> (_mm_store_sd): Ditto.
> (_mm_loadh_pd): Ditto.
> (_mm_loadl_pd): Ditto.
> (_mm_storel_pd): Add alignment requirement.
> * config/i386/xmmintrin.h
> (_mm_loadh_pi): Remove alignment requirement.
> (_mm_loadl_pi): Ditto.
> (_mm_load_ss): Ditto.
> (_mm_store_ss): Ditto.
>
> gcc/testsuite/ChangeLog:
>
> PR target/84508
> * gcc.target/i386/pr84508-1.c: New test.
> * gcc.target/i386/pr84508-2.c: Ditto.
> ---
>  gcc/config/i386/emmintrin.h   | 11 ++-
>  gcc/config/i386/xmmintrin.h   |  9 +
>  gcc/testsuite/gcc.target/i386/pr84508-1.c | 11 +++
>  gcc/testsuite/gcc.target/i386/pr84508-2.c | 11 +++
>  4 files changed, 33 insertions(+), 9 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr84508-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr84508-2.c
>
> diff --git a/gcc/config/i386/emmintrin.h b/gcc/config/i386/emmintrin.h
> index 915a5234c38..d7fc1af9687 100644
> --- a/gcc/config/i386/emmintrin.h
> +++ b/gcc/config/i386/emmintrin.h
> @@ -56,6 +56,7 @@ typedef double __m128d __attribute__ ((__vector_size__ 
> (16), __may_alias__));
>  /* Unaligned version of the same types.  */
>  typedef long long __m128i_u __attribute__ ((__vector_size__ (16), 
> __may_alias__, __aligned__ (1)));
>  typedef double __m128d_u __attribute__ ((__vector_size__ (16), 
> __may_alias__, __aligned__ (1)));
> +typedef double double_u __attribute__ ((__may_alias__, __aligned__ (1)));
>
>  /* Create a selector for use with the SHUFPD instruction.  */
>  #define _MM_SHUFFLE2(fp1,fp0) \
> @@ -145,7 +146,7 @@ _mm_load1_pd (double const *__P)
>  extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__, 
> __artificial__))
>  _mm_load_sd (double const *__P)
>  {
> -  return _mm_set_sd (*__P);
> +  return __extension__ (__m128d){ *(double_u *)__P, 0.0 };
>  }
>
>  extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__, 
> __artificial__))
> @@ -180,7 +181,7 @@ _mm_storeu_pd (double *__P, __m128d __A)
>  extern __inline void __attribute__((__gnu_inline__, __always_inline__, 
> __artificial__))
>  _mm_store_sd (double *__P, __m128d __A)
>  {
> -  *__P = ((__v2df)__A)[0];
> +  *(double_u *)__P = ((__v2df)__A)[0] ;
>  }
>
>  extern __inline double __attribute__((__gnu_inline__, __always_inline__, 
> __artificial__))
> @@ -192,7 +193,7 @@ _mm_cvtsd_f64 (__m128d __A)
>  extern __inline void __attribute__((__gnu_inline__, __always_inline__, 
> __artificial__))
>  _mm_storel_pd (double *__P, __m128d __A)
>  {
> -  _mm_store_sd (__P, __A);
> +  *__P = ((__v2df)__A)[0];
>  }
>
>  /* Stores the upper DPFP value.  */
> @@ -973,13 +974,13 @@ _mm_unpacklo_pd (__m128d __A, __m128d __B)
>  extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__, 
> __artificial__))
>  _mm_loadh_pd (__m128d __A, double const *__B)
>  {
> -  return (__m128d)__builtin_ia32_loadhpd ((__v2df)__A, __B);
> +  return __extension__ (__m128d) { ((__v2df)__A)[0], *(double_u*)__B };
>  }
>
>  extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__, 
> __artificial__))
>  _mm_loadl_pd (__m128d __A, double const *__B)
>  {
> -  return (__m128d)__builtin_ia32_loadlpd ((__v2df)__A, __B);
> +  return __extension__ (__m128d) { *(double_u*)__B, ((__v2df)__A)[1] };
>  }
>
>  extern __inline int __attribute__((__gnu_inline__, __always_inline__, 
> __artificial__))
> diff --git a/gcc/config/i386/xmmintrin.h b/gcc/config/i386/xmmintrin.h
> index 71b9955b843..9e20f262839 100644
> --- a/gcc/config/i386/xmmintrin.h
> +++ b/gcc/config/i386/xmmintrin.h
> @@ -73,6 +73,7 @@ typedef float __m128 __attribute__ ((__vector_size__ (16), 
> __may_alias__));
>
>  /* Unaligned version of the same type.  */
>  typedef float __m128_u __attribute__ ((__vector_size__ (16), __may_alias__, 
> __aligned__ (1)));
> +typedef float float_u __attribute__ ((__may_alias__, __aligned__ (1)));
>
>  /* Internal data types for implementing the intrinsics.  */
>  typedef float __v4sf __attribute__ ((__vector_size__ (16)));
> @@ -774,7 +775,7 @@ _mm_unpacklo_ps (__m128 __A, __m128 __B)
>  /* Sets the upper two SPFP values with 64-bits of data loaded from P;
> the lower two values are passed through from A.  */
>  extern __inline __m128 __attribute__((__gnu_inline__, __always_inline__, 
> __artificial__))
> -_mm_loadh_pi (__m128 __A, __m64 const *__P)
> +_mm_loadh_pi (__m128 __A, __m64_u const *__P)
>  {
>return (__m128) __builtin_ia32_loadhps ((__v4sf)__A, (const __v2sf *)__P);
>  }
> @@ -803,7 

[Bug tree-optimization/114965] [13 Regression] wrong code generated for Emacs/Gnulib strftime (regression from 13.2)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:44d84db11ab724c34a8b1f8c0e06da1cc78439a2

commit r13-8735-g44d84db11ab724c34a8b1f8c0e06da1cc78439a2
Author: Jakub Jelinek 
Date:   Wed May 8 10:17:32 2024 +0200

reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]

The optimize_range_tests_to_bit_test optimization normally emits a range
test first:
  if (entry_test_needed)
{
  tem = build_range_check (loc, optype, unshare_expr (exp),
   false, lowi, high);
  if (tem == NULL_TREE || is_gimple_val (tem))
continue;
}
so during the bit test we already know that exp is in the [lowi, high]
range, but skips it if we have range info which tells us this isn't
necessary.
Also, normally it emits shifts by exp - lowi counter, but has an
optimization to use just exp counter if the mask isn't a more expensive
constant in that case and lowi is > 0 and high is smaller than prec.

The following testcase is miscompiled because the two abnormal cases
are triggered.  The range of exp is [43, 43][48, 48][95, 95], so we on
64-bit arch decide we don't need the entry test, because 95 - 43 < 64.
And we also decide to use just exp as counter, because the range test
tests just for exp == 43 || exp == 48, so high is smaller than 64 too.
Because 95 is in the exp range, we can't do that, we'd either need to
do a range test first, i.e.
if (exp - 43U <= 48U - 43U) if ((1UL << exp) & mask1))
or need to subtract lowi from the shift counter, i.e.
if ((1UL << (exp - 43)) & mask2)
but can't do both unless r.upper_bound () is < prec.

The following patch ensures that.

2024-05-08  Jakub Jelinek  

PR tree-optimization/114965
* tree-ssa-reassoc.cc (optimize_range_tests_to_bit_test): Don't try
to
optimize away exp - lowi subtraction from shift count unless entry
test is emitted or unless r.upper_bound () is smaller than prec.

* gcc.c-torture/execute/pr114965.c: New test.

(cherry picked from commit 9adec2d91e62a479474ae79df5b455fd4b8463ba)

[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:cad27df08915ead8db3c7d512cfcc1866e7ece69

commit r13-8734-gcad27df08915ead8db3c7d512cfcc1866e7ece69
Author: Jakub Jelinek 
Date:   Tue May 7 21:30:21 2024 +0200

expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

The HF and BF modes have the same size/precision and neither is
a subset nor superset of the other.
So, using either __extendhfbf2 or __trunchfbf2 is weird.
The expansion apparently emits __extendhfbf2, but on the libgcc side
we apparently have __trunchfbf2 implemented.

I think it is easier to switch to using what is available rather than
adding new entrypoints to libgcc, even alias, because this is backportable.

2024-05-07  Jakub Jelinek  

PR middle-end/114907
* expr.cc (convert_mode_scalar): Use trunc_optab rather than
sext_optab for HF->BF conversions.
* optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise.

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

(cherry picked from commit 28ee13db2e9d995bd3728c4ff3a3545e24b39cd2)

[gcc r13-8734] expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

[Jakub Jelinek via Gcc-cvs]

https://gcc.gnu.org/g:cad27df08915ead8db3c7d512cfcc1866e7ece69

commit r13-8734-gcad27df08915ead8db3c7d512cfcc1866e7ece69
Author: Jakub Jelinek 
Date:   Tue May 7 21:30:21 2024 +0200

expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

The HF and BF modes have the same size/precision and neither is
a subset nor superset of the other.
So, using either __extendhfbf2 or __trunchfbf2 is weird.
The expansion apparently emits __extendhfbf2, but on the libgcc side
we apparently have __trunchfbf2 implemented.

I think it is easier to switch to using what is available rather than
adding new entrypoints to libgcc, even alias, because this is backportable.

2024-05-07  Jakub Jelinek  

PR middle-end/114907
* expr.cc (convert_mode_scalar): Use trunc_optab rather than
sext_optab for HF->BF conversions.
* optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise.

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

(cherry picked from commit 28ee13db2e9d995bd3728c4ff3a3545e24b39cd2)

Diff:
---
 gcc/expr.cc | 12 ++--
 gcc/optabs-libfuncs.cc  |  4 +++-
 gcc/testsuite/gcc.dg/pr114907.c | 27 +++
 3 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 5dac06fa94b5..705d5b34eed6 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -351,8 +351,16 @@ convert_mode_scalar (rtx to, rtx from, int unsignedp)
  && REAL_MODE_FORMAT (from_mode) == _half_format));
 
   if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode))
-   /* Conversion between decimal float and binary float, same size.  */
-   tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;
+   {
+ if (REAL_MODE_FORMAT (to_mode) == _bfloat_half_format
+ && REAL_MODE_FORMAT (from_mode) == _half_format)
+   /* libgcc implements just __trunchfbf2, not __extendhfbf2.  */
+   tab = trunc_optab;
+ else
+   /* Conversion between decimal float and binary float, same
+  size.  */
+   tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;
+   }
   else if (GET_MODE_PRECISION (from_mode) < GET_MODE_PRECISION (to_mode))
tab = sext_optab;
   else
diff --git a/gcc/optabs-libfuncs.cc b/gcc/optabs-libfuncs.cc
index f1abe6916d34..4eb98be794b7 100644
--- a/gcc/optabs-libfuncs.cc
+++ b/gcc/optabs-libfuncs.cc
@@ -589,7 +589,9 @@ gen_trunc_conv_libfunc (convert_optab tab,
   if (GET_MODE_CLASS (float_tmode) != GET_MODE_CLASS (float_fmode))
 gen_interclass_conv_libfunc (tab, opname, float_tmode, float_fmode);
 
-  if (GET_MODE_PRECISION (float_fmode) <= GET_MODE_PRECISION (float_tmode))
+  if (GET_MODE_PRECISION (float_fmode) <= GET_MODE_PRECISION (float_tmode)
+  && (REAL_MODE_FORMAT (float_tmode) != _bfloat_half_format
+ || REAL_MODE_FORMAT (float_fmode) != _half_format))
 return;
 
   if (GET_MODE_CLASS (float_tmode) == GET_MODE_CLASS (float_fmode))
diff --git a/gcc/testsuite/gcc.dg/pr114907.c b/gcc/testsuite/gcc.dg/pr114907.c
new file mode 100644
index ..628746e1f8c1
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr114907.c
@@ -0,0 +1,27 @@
+/* PR middle-end/114907 */
+/* { dg-do run } */
+/* { dg-options "" } */
+/* { dg-add-options float16 } */
+/* { dg-require-effective-target float16_runtime } */
+/* { dg-add-options bfloat16 } */
+/* { dg-require-effective-target bfloat16_runtime } */
+
+__attribute__((noipa)) _Float16
+foo (__bf16 x)
+{
+  return (_Float16) x;
+}
+
+__attribute__((noipa)) __bf16
+bar (_Float16 x)
+{
+  return (__bf16) x;
+}
+
+int
+main ()
+{
+  if (foo (11.125bf16) != 11.125f16
+  || bar (11.125f16) != 11.125bf16)
+__builtin_abort ();
+}

[gcc r13-8733] tree-inline: Remove .ASAN_MARK calls when inlining functions into no_sanitize callers [PR114956]

[Jakub Jelinek via Gcc-cvs]

https://gcc.gnu.org/g:d1ec7bc9cb0639a212422710ba647dc1aaea6eaa

commit r13-8733-gd1ec7bc9cb0639a212422710ba647dc1aaea6eaa
Author: Jakub Jelinek 
Date:   Tue May 7 21:29:14 2024 +0200

tree-inline: Remove .ASAN_MARK calls when inlining functions into 
no_sanitize callers [PR114956]

In r9-5742 we've started allowing to inline always_inline functions into
functions which have disabled e.g. address sanitization even when the
always_inline function is implicitly from command line options sanitized.

This mostly works fine because most of the asan instrumentation is done only
late after ipa, but as the following testcase the .ASAN_MARK ifn calls
gimplifier adds can result in ICEs.

Fixed by dropping those during inlining, similarly to how we drop
.TSAN_FUNC_EXIT calls.

2024-05-07  Jakub Jelinek  

PR sanitizer/114956
* tree-inline.cc: Include asan.h.
(copy_bb): Remove also .ASAN_MARK calls if id->dst_fn has 
asan/hwasan
sanitization disabled.

* gcc.dg/asan/pr114956.c: New test.

(cherry picked from commit d4e25cf4f7c1f51a8824cc62bbb85a81a41b829a)

Diff:
---
 gcc/testsuite/gcc.dg/asan/pr114956.c | 26 ++
 gcc/tree-inline.cc   | 28 +---
 2 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/asan/pr114956.c 
b/gcc/testsuite/gcc.dg/asan/pr114956.c
new file mode 100644
index ..fb87d514f255
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asan/pr114956.c
@@ -0,0 +1,26 @@
+/* PR sanitizer/114956 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fsanitize=address,null" } */
+
+int **a;
+void qux (int *);
+
+__attribute__((always_inline)) static inline int *
+foo (void)
+{
+  int b[1];
+  qux (b);
+  return a[1];
+}
+
+__attribute__((no_sanitize_address)) void
+bar (void)
+{
+  *a = foo ();
+}
+
+void
+baz (void)
+{
+  bar ();
+}
diff --git a/gcc/tree-inline.cc b/gcc/tree-inline.cc
index 72a80c0c74da..73d5a9fadef3 100644
--- a/gcc/tree-inline.cc
+++ b/gcc/tree-inline.cc
@@ -65,6 +65,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "symbol-summary.h"
 #include "symtab-thunks.h"
 #include "symtab-clones.h"
+#include "asan.h"
 
 /* I'm not real happy about this, but we need to handle gimple and
non-gimple trees.  */
@@ -2198,13 +2199,26 @@ copy_bb (copy_body_data *id, basic_block bb,
}
  else if (call_stmt
   && id->call_stmt
-  && gimple_call_internal_p (stmt)
-  && gimple_call_internal_fn (stmt) == IFN_TSAN_FUNC_EXIT)
-   {
- /* Drop TSAN_FUNC_EXIT () internal calls during inlining.  */
- gsi_remove (_gsi, false);
- continue;
-   }
+  && gimple_call_internal_p (stmt))
+   switch (gimple_call_internal_fn (stmt))
+ {
+ case IFN_TSAN_FUNC_EXIT:
+   /* Drop .TSAN_FUNC_EXIT () internal calls during inlining.  */
+   gsi_remove (_gsi, false);
+   continue;
+ case IFN_ASAN_MARK:
+   /* Drop .ASAN_MARK internal calls during inlining into
+  no_sanitize functions.  */
+   if (!sanitize_flags_p (SANITIZE_ADDRESS, id->dst_fn)
+   && !sanitize_flags_p (SANITIZE_HWADDRESS, id->dst_fn))
+ {
+   gsi_remove (_gsi, false);
+   continue;
+ }
+   break;
+ default:
+   break;
+ }
 
  /* Statements produced by inlining can be unfolded, especially
 when we constant propagated some operands.  We can't fold

[Bug sanitizer/114956] [11/12/13 Regression] Segmentation fault with -fsanitize=address -fsanitize=null -O2 when attribute no_sanitize_address is enabled since r9-5742

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:d1ec7bc9cb0639a212422710ba647dc1aaea6eaa

commit r13-8733-gd1ec7bc9cb0639a212422710ba647dc1aaea6eaa
Author: Jakub Jelinek 
Date:   Tue May 7 21:29:14 2024 +0200

tree-inline: Remove .ASAN_MARK calls when inlining functions into
no_sanitize callers [PR114956]

In r9-5742 we've started allowing to inline always_inline functions into
functions which have disabled e.g. address sanitization even when the
always_inline function is implicitly from command line options sanitized.

This mostly works fine because most of the asan instrumentation is done
only
late after ipa, but as the following testcase the .ASAN_MARK ifn calls
gimplifier adds can result in ICEs.

Fixed by dropping those during inlining, similarly to how we drop
.TSAN_FUNC_EXIT calls.

2024-05-07  Jakub Jelinek  

PR sanitizer/114956
* tree-inline.cc: Include asan.h.
(copy_bb): Remove also .ASAN_MARK calls if id->dst_fn has
asan/hwasan
sanitization disabled.

* gcc.dg/asan/pr114956.c: New test.

(cherry picked from commit d4e25cf4f7c1f51a8824cc62bbb85a81a41b829a)

[gcc r13-8735] reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]

[Jakub Jelinek via Gcc-cvs]

https://gcc.gnu.org/g:44d84db11ab724c34a8b1f8c0e06da1cc78439a2

commit r13-8735-g44d84db11ab724c34a8b1f8c0e06da1cc78439a2
Author: Jakub Jelinek 
Date:   Wed May 8 10:17:32 2024 +0200

reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]

The optimize_range_tests_to_bit_test optimization normally emits a range
test first:
  if (entry_test_needed)
{
  tem = build_range_check (loc, optype, unshare_expr (exp),
   false, lowi, high);
  if (tem == NULL_TREE || is_gimple_val (tem))
continue;
}
so during the bit test we already know that exp is in the [lowi, high]
range, but skips it if we have range info which tells us this isn't
necessary.
Also, normally it emits shifts by exp - lowi counter, but has an
optimization to use just exp counter if the mask isn't a more expensive
constant in that case and lowi is > 0 and high is smaller than prec.

The following testcase is miscompiled because the two abnormal cases
are triggered.  The range of exp is [43, 43][48, 48][95, 95], so we on
64-bit arch decide we don't need the entry test, because 95 - 43 < 64.
And we also decide to use just exp as counter, because the range test
tests just for exp == 43 || exp == 48, so high is smaller than 64 too.
Because 95 is in the exp range, we can't do that, we'd either need to
do a range test first, i.e.
if (exp - 43U <= 48U - 43U) if ((1UL << exp) & mask1))
or need to subtract lowi from the shift counter, i.e.
if ((1UL << (exp - 43)) & mask2)
but can't do both unless r.upper_bound () is < prec.

The following patch ensures that.

2024-05-08  Jakub Jelinek  

PR tree-optimization/114965
* tree-ssa-reassoc.cc (optimize_range_tests_to_bit_test): Don't try 
to
optimize away exp - lowi subtraction from shift count unless entry
test is emitted or unless r.upper_bound () is smaller than prec.

* gcc.c-torture/execute/pr114965.c: New test.

(cherry picked from commit 9adec2d91e62a479474ae79df5b455fd4b8463ba)

Diff:
---
 gcc/testsuite/gcc.c-torture/execute/pr114965.c | 30 ++
 gcc/tree-ssa-reassoc.cc|  3 ++-
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.c-torture/execute/pr114965.c 
b/gcc/testsuite/gcc.c-torture/execute/pr114965.c
new file mode 100644
index ..89d68e187015
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr114965.c
@@ -0,0 +1,30 @@
+/* PR tree-optimization/114965 */
+
+static void
+foo (const char *x)
+{
+
+  char a = '0';
+  while (1)
+{
+  switch (*x)
+   {
+   case '_':
+   case '+':
+ a = *x;
+ x++;
+ continue;
+   default:
+ break;
+   }
+  break;
+}
+  if (a == '0' || a == '+')
+__builtin_abort ();
+}
+
+int
+main ()
+{
+  foo ("_");
+}
diff --git a/gcc/tree-ssa-reassoc.cc b/gcc/tree-ssa-reassoc.cc
index c5020465c2b3..d8f5471951af 100644
--- a/gcc/tree-ssa-reassoc.cc
+++ b/gcc/tree-ssa-reassoc.cc
@@ -3411,7 +3411,8 @@ optimize_range_tests_to_bit_test (enum tree_code opcode, 
int first, int length,
 We can avoid then subtraction of the minimum value, but the
 mask constant could be perhaps more expensive.  */
  if (compare_tree_int (lowi, 0) > 0
- && compare_tree_int (high, prec) < 0)
+ && compare_tree_int (high, prec) < 0
+ && (entry_test_needed || wi::ltu_p (r.upper_bound (), prec)))
{
  int cost_diff;
  HOST_WIDE_INT m = tree_to_uhwi (lowi);

[gcc r13-8732] gimple-ssa-sprintf: Use [0, 1] range for %lc with (wint_t) 0 argument [PR114876]

[Jakub Jelinek via Gcc-cvs]

https://gcc.gnu.org/g:e07df053031e109c50387c92d689950de1d193ab

commit r13-8732-ge07df053031e109c50387c92d689950de1d193ab
Author: Jakub Jelinek 
Date:   Tue Apr 30 11:22:32 2024 +0200

gimple-ssa-sprintf: Use [0, 1] range for %lc with (wint_t) 0 argument 
[PR114876]

Seems when Martin S. implemented this, he coded there strict reading
of the standard, which said that %lc with (wint_t) 0 argument is handled
as wchar_t[2] temp = { arg, 0 }; %ls with temp arg and so shouldn't print
any values.  But, most of the libc implementations actually handled that
case like %c with '\0' argument, adding a single NUL character, the only
known exception is musl.
Recently, C23 changed this in response to GB-141 and POSIX in
https://austingroupbugs.net/view.php?id=1647
so that it should have the same behavior as %c with '\0'.

Because there is implementation divergence, the following patch uses
a range rather than hardcoding it to all 1s (i.e. the %c behavior),
though the likely case is still 1 (forward looking plus most of
implementations).
The res.knownrange = true; assignment removed is redundant due to
the same assignment done unconditionally before the if statement,
rest is formatting fixes.

I don't think the min >= 0 && min < 128 case is right either, I'd think
it should be min >= 0 && max < 128, otherwise it is just some possible
inputs are (maybe) ASCII and there can be others, but this code is a total
mess anyway, with the min, max, likely (somewhere in [min, max]?) and then
unlikely possibly larger than max, dunno, perhaps for at least some chars
in the ASCII range the likely case could be for the ascii case; so perhaps
just the one_2_one_ascii shouldn't set max to 1 and mayfail should be true
for max >= 128.  Anyway, didn't feel I should touch that right now.

2024-04-30  Jakub Jelinek  

PR tree-optimization/114876
* gimple-ssa-sprintf.cc (format_character): For min == 0 && max == 
0,
set max, likely and unlikely members to 1 rather than 0.  Remove
useless res.knownrange = true;.  Formatting fixes.

* gcc.dg/pr114876.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected
diagnostics.

(cherry picked from commit 6c6b70f07208ca14ba783933988c04c6fc2fff42)

Diff:
---
 gcc/gimple-ssa-sprintf.cc  | 20 +++--
 gcc/testsuite/gcc.dg/pr114876.c| 34 ++
 .../gcc.dg/tree-ssa/builtin-sprintf-warn-1.c   | 12 
 3 files changed, 51 insertions(+), 15 deletions(-)

diff --git a/gcc/gimple-ssa-sprintf.cc b/gcc/gimple-ssa-sprintf.cc
index 18975708d2c2..e02977f0ac39 100644
--- a/gcc/gimple-ssa-sprintf.cc
+++ b/gcc/gimple-ssa-sprintf.cc
@@ -2170,8 +2170,7 @@ format_character (const directive , tree arg, 
pointer_query _qry)
 
   res.knownrange = true;
 
-  if (dir.specifier == 'C'
-  || dir.modifier == FMT_LEN_l)
+  if (dir.specifier == 'C' || dir.modifier == FMT_LEN_l)
 {
   /* A wide character can result in as few as zero bytes.  */
   res.range.min = 0;
@@ -2182,10 +2181,13 @@ format_character (const directive , tree arg, 
pointer_query _qry)
{
  if (min == 0 && max == 0)
{
- /* The NUL wide character results in no bytes.  */
- res.range.max = 0;
- res.range.likely = 0;
- res.range.unlikely = 0;
+ /* In strict reading of older ISO C or POSIX, this required
+no characters to be emitted.  ISO C23 changes that, so
+does POSIX, to match what has been implemented in most of the
+implementations, namely emitting a single NUL character.
+Let's use 0 for minimum and 1 for all the other values.  */
+ res.range.max = 1;
+ res.range.likely = res.range.unlikely = 1;
}
  else if (min >= 0 && min < 128)
{
@@ -2193,11 +2195,12 @@ format_character (const directive , tree arg, 
pointer_query _qry)
 is not a 1-to-1 mapping to the source character set or
 if the source set is not ASCII.  */
  bool one_2_one_ascii
-   = (target_to_host_charmap[0] == 1 && target_to_host ('a') == 
97);
+   = (target_to_host_charmap[0] == 1
+  && target_to_host ('a') == 97);
 
  /* A wide character in the ASCII range most likely results
 in a single byte, and only unlikely in up to MB_LEN_MAX.  */
- res.range.max = one_2_one_ascii ? 1 : target_mb_len_max ();;
+ res.range.max = one_2_one_ascii ? 1 : target_mb_len_max ();
  res.range.likely = 1;
  res.range.unlikely = target_mb_len_max ();
  res.mayfail = !one_2_one_ascii;
@@ -2228,7 +2231,6 @@ format_character (const 

[gcc r13-8731] c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284]

[Jakub Jelinek via Gcc-cvs]

https://gcc.gnu.org/g:6f1b3f9c97e17aa717ae61bc70afa27adcb7ef44

commit r13-8731-g6f1b3f9c97e17aa717ae61bc70afa27adcb7ef44
Author: Jakub Jelinek 
Date:   Thu Apr 25 20:45:04 2024 +0200

c++: Fix constexpr evaluation of parameters passed by invisible reference 
[PR111284]

My r9-6136 changes to make a copy of constexpr function bodies before
genericization modifies it broke the constant evaluation of non-POD
arguments passed by value.
In the callers such arguments are passed as reference to usually a
TARGET_EXPR, but on the callee side until genericization they are just
direct uses of a PARM_DECL with some class type.
In cxx_bind_parameters_in_call I've used convert_from_reference to
pretend it is passed by value and then cxx_eval_constant_expression
is called there and evaluates that as an rvalue, followed by
adjust_temp_type if the types don't match exactly (e.g. const Foo
argument and passing to it reference to Foo TARGET_EXPR).

The reason this doesn't work is that when the TARGET_EXPR in the caller
is constant initialized, this for it is the address of the TARGET_EXPR_SLOT,
but if the code later on pretends the PARM_DECL is just initialized to the
rvalue of the constant evaluation of the TARGET_EXPR, it is as if there
is a bitwise copy of the TARGET_EXPR to the callee, so this in the callee
is then address of the PARM_DECL in the callee.

The following patch attempts to fix that by constexpr evaluation of such
arguments in the caller as an lvalue instead of rvalue, and on the callee
side when seeing such a PARM_DECL, if we want an lvalue, lookup the value
(lvalue) saved in ctx->globals (if any), and if wanting an rvalue,
recursing with vc_prvalue on the looked up value (because it is there
as an lvalue, nor rvalue).

adjust_temp_type doesn't work for lvalues of non-scalarish types, for
such types it relies on changing the type of a CONSTRUCTOR, but on the
other side we know what we pass to the argument is addressable, so
the patch on type mismatch takes address of the argument value, casts
to reference to the desired type and dereferences it.

2024-04-25  Jakub Jelinek  

PR c++/111284
* constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with
TREE_ADDRESSABLE types use vc_glvalue rather than vc_prvalue for
cxx_eval_constant_expression and if it doesn't have the same
type as it should, cast the reference type to reference to type
before convert_from_reference and instead of adjust_temp_type
take address of the arg, cast to reference to type and then
convert_from_reference.
(cxx_eval_constant_expression) : For lval case
on parameters with TREE_ADDRESSABLE types lookup result in
ctx->globals if possible.  Otherwise if lookup in ctx->globals
was successful for parameter with TREE_ADDRESSABLE type,
recurse with vc_prvalue on the returned value.

* g++.dg/cpp1z/constexpr-111284.C: New test.

(cherry picked from commit f541757ba4632e204169dd08a5f10c782199af42)

Diff:
---
 gcc/cp/constexpr.cc   | 44 +--
 gcc/testsuite/g++.dg/cpp1z/constexpr-111284.C | 19 
 2 files changed, 53 insertions(+), 10 deletions(-)

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 216b98122007..acb5496085bb 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -1800,13 +1800,18 @@ cxx_bind_parameters_in_call (const constexpr_ctx *ctx, 
tree t, tree fun,
  x = build_address (x);
}
   if (TREE_ADDRESSABLE (type))
-   /* Undo convert_for_arg_passing work here.  */
-   x = convert_from_reference (x);
-  /* Normally we would strip a TARGET_EXPR in an initialization context
-such as this, but here we do the elision differently: we keep the
-TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
-  arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
- non_constant_p, overflow_p);
+   {
+ /* Undo convert_for_arg_passing work here.  */
+ x = convert_from_reference (x);
+ arg = cxx_eval_constant_expression (ctx, x, vc_glvalue,
+ non_constant_p, overflow_p);
+   }
+  else
+   /* Normally we would strip a TARGET_EXPR in an initialization context
+  such as this, but here we do the elision differently: we keep the
+  TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
+   arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
+   non_constant_p, overflow_p);
   /* Don't VERIFY_CONSTANT here.  */
   if (*non_constant_p && ctx->quiet)
break;
@@ -1818,7 +1823,16 @@ 

[Bug tree-optimization/114876] [11/12/13 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:e07df053031e109c50387c92d689950de1d193ab

commit r13-8732-ge07df053031e109c50387c92d689950de1d193ab
Author: Jakub Jelinek 
Date:   Tue Apr 30 11:22:32 2024 +0200

gimple-ssa-sprintf: Use [0, 1] range for %lc with (wint_t) 0 argument
[PR114876]

Seems when Martin S. implemented this, he coded there strict reading
of the standard, which said that %lc with (wint_t) 0 argument is handled
as wchar_t[2] temp = { arg, 0 }; %ls with temp arg and so shouldn't print
any values.  But, most of the libc implementations actually handled that
case like %c with '\0' argument, adding a single NUL character, the only
known exception is musl.
Recently, C23 changed this in response to GB-141 and POSIX in
https://austingroupbugs.net/view.php?id=1647
so that it should have the same behavior as %c with '\0'.

Because there is implementation divergence, the following patch uses
a range rather than hardcoding it to all 1s (i.e. the %c behavior),
though the likely case is still 1 (forward looking plus most of
implementations).
The res.knownrange = true; assignment removed is redundant due to
the same assignment done unconditionally before the if statement,
rest is formatting fixes.

I don't think the min >= 0 && min < 128 case is right either, I'd think
it should be min >= 0 && max < 128, otherwise it is just some possible
inputs are (maybe) ASCII and there can be others, but this code is a total
mess anyway, with the min, max, likely (somewhere in [min, max]?) and then
unlikely possibly larger than max, dunno, perhaps for at least some chars
in the ASCII range the likely case could be for the ascii case; so perhaps
just the one_2_one_ascii shouldn't set max to 1 and mayfail should be true
for max >= 128.  Anyway, didn't feel I should touch that right now.

2024-04-30  Jakub Jelinek  

PR tree-optimization/114876
* gimple-ssa-sprintf.cc (format_character): For min == 0 && max ==
0,
set max, likely and unlikely members to 1 rather than 0.  Remove
useless res.knownrange = true;.  Formatting fixes.

* gcc.dg/pr114876.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected
diagnostics.

(cherry picked from commit 6c6b70f07208ca14ba783933988c04c6fc2fff42)

[gcc r13-8730] openmp: Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_? to tree-nested decl copy [PR114825]

[Jakub Jelinek via Gcc-cvs]

https://gcc.gnu.org/g:6d30cfc3fc88976151d0d10e73e10111ccb71ee0

commit r13-8730-g6d30cfc3fc88976151d0d10e73e10111ccb71ee0
Author: Jakub Jelinek 
Date:   Thu Apr 25 20:09:35 2024 +0200

openmp: Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_? to tree-nested decl 
copy [PR114825]

tree-nested.cc creates in 2 spots artificial VAR_DECLs, one of them is used
both for debug info and OpenMP/OpenACC lowering purposes, the other solely 
for
OpenMP/OpenACC lowering purposes.
When the decls are used in OpenMP/OpenACC lowering, the OMP langhooks 
(mostly
Fortran, C just a little and C++ doesn't have nested functions) then inspect
the flags on the vars and based on that decide how to lower the 
corresponding
clauses.

Unfortunately we weren't copying DECL_LANG_SPECIFIC and DECL_LANG_FLAG_?, so
the langhooks made decisions on the default flags on those instead.
As the original decl isn't necessarily a VAR_DECL, could be e.g. PARM_DECL,
using copy_node wouldn't work properly, so this patch just copies those
flags in addition to other flags it was copying already.  And I've removed
code duplication by introducing a helper function which does copying common
to both uses.

2024-04-25  Jakub Jelinek  

PR fortran/114825
* tree-nested.cc (get_debug_decl): New function.
(get_nonlocal_debug_decl): Use it.
(get_local_debug_decl): Likewise.

* gfortran.dg/gomp/pr114825.f90: New test.

(cherry picked from commit 14d48516e588ad2b35e2007b3970bdcb1b3f145c)

Diff:
---
 gcc/testsuite/gfortran.dg/gomp/pr114825.f90 | 16 
 gcc/tree-nested.cc  | 61 -
 2 files changed, 49 insertions(+), 28 deletions(-)

diff --git a/gcc/testsuite/gfortran.dg/gomp/pr114825.f90 
b/gcc/testsuite/gfortran.dg/gomp/pr114825.f90
new file mode 100644
index ..b635476af61e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/pr114825.f90
@@ -0,0 +1,16 @@
+! PR fortran/114825
+
+subroutine pr114825(b)
+  type t
+real, allocatable :: m(:)
+  end type t
+  type(t), allocatable, target :: b(:)
+  type(t), pointer :: d
+  !$omp parallel private(d)
+  d => b(1)
+  !$omp end parallel
+contains
+  subroutine sub
+d => b(1)
+  end subroutine sub
+end subroutine pr114825
diff --git a/gcc/tree-nested.cc b/gcc/tree-nested.cc
index 1418e1f7f562..0f44b3dc735e 100644
--- a/gcc/tree-nested.cc
+++ b/gcc/tree-nested.cc
@@ -1039,6 +1039,37 @@ get_frame_field (struct nesting_info *info, tree 
target_context,
 
 static void note_nonlocal_vla_type (struct nesting_info *info, tree type);
 
+/* Helper for get_nonlocal_debug_decl and get_local_debug_decl.  */
+
+static tree
+get_debug_decl (tree decl)
+{
+  tree new_decl
+= build_decl (DECL_SOURCE_LOCATION (decl),
+ VAR_DECL, DECL_NAME (decl), TREE_TYPE (decl));
+  DECL_ARTIFICIAL (new_decl) = DECL_ARTIFICIAL (decl);
+  DECL_IGNORED_P (new_decl) = DECL_IGNORED_P (decl);
+  TREE_THIS_VOLATILE (new_decl) = TREE_THIS_VOLATILE (decl);
+  TREE_SIDE_EFFECTS (new_decl) = TREE_SIDE_EFFECTS (decl);
+  TREE_READONLY (new_decl) = TREE_READONLY (decl);
+  TREE_ADDRESSABLE (new_decl) = TREE_ADDRESSABLE (decl);
+  DECL_SEEN_IN_BIND_EXPR_P (new_decl) = 1;
+  if ((TREE_CODE (decl) == PARM_DECL
+   || TREE_CODE (decl) == RESULT_DECL
+   || VAR_P (decl))
+  && DECL_BY_REFERENCE (decl))
+DECL_BY_REFERENCE (new_decl) = 1;
+  /* Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_* for OpenMP langhook
+ purposes.  */
+  DECL_LANG_SPECIFIC (new_decl) = DECL_LANG_SPECIFIC (decl);
+#define COPY_DLF(n) DECL_LANG_FLAG_##n (new_decl) = DECL_LANG_FLAG_##n (decl)
+  COPY_DLF (0); COPY_DLF (1); COPY_DLF (2); COPY_DLF (3);
+  COPY_DLF (4); COPY_DLF (5); COPY_DLF (6); COPY_DLF (7);
+  COPY_DLF (8);
+#undef COPY_DLF
+  return new_decl;
+}
+
 /* A subroutine of convert_nonlocal_reference_op.  Create a local variable
in the nested function with DECL_VALUE_EXPR set to reference the true
variable in the parent function.  This is used both for debug info
@@ -1086,21 +1117,8 @@ get_nonlocal_debug_decl (struct nesting_info *info, tree 
decl)
 x = build_simple_mem_ref_notrap (x);
 
   /* ??? We should be remapping types as well, surely.  */
-  new_decl = build_decl (DECL_SOURCE_LOCATION (decl),
-VAR_DECL, DECL_NAME (decl), TREE_TYPE (decl));
+  new_decl = get_debug_decl (decl);
   DECL_CONTEXT (new_decl) = info->context;
-  DECL_ARTIFICIAL (new_decl) = DECL_ARTIFICIAL (decl);
-  DECL_IGNORED_P (new_decl) = DECL_IGNORED_P (decl);
-  TREE_THIS_VOLATILE (new_decl) = TREE_THIS_VOLATILE (decl);
-  TREE_SIDE_EFFECTS (new_decl) = TREE_SIDE_EFFECTS (decl);
-  TREE_READONLY (new_decl) = TREE_READONLY (decl);
-  TREE_ADDRESSABLE (new_decl) = TREE_ADDRESSABLE (decl);
-  DECL_SEEN_IN_BIND_EXPR_P (new_decl) = 1;
-  if ((TREE_CODE (decl) == PARM_DECL
-   || TREE_CODE (decl) == RESULT_DECL
-   || 

[Bug c++/111284] [11/12/13 Regression] Some passing-by-value parameters are mishandled since GCC 9, affecting libstdc++'s constexpr std::string

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:6f1b3f9c97e17aa717ae61bc70afa27adcb7ef44

commit r13-8731-g6f1b3f9c97e17aa717ae61bc70afa27adcb7ef44
Author: Jakub Jelinek 
Date:   Thu Apr 25 20:45:04 2024 +0200

c++: Fix constexpr evaluation of parameters passed by invisible reference
[PR111284]

My r9-6136 changes to make a copy of constexpr function bodies before
genericization modifies it broke the constant evaluation of non-POD
arguments passed by value.
In the callers such arguments are passed as reference to usually a
TARGET_EXPR, but on the callee side until genericization they are just
direct uses of a PARM_DECL with some class type.
In cxx_bind_parameters_in_call I've used convert_from_reference to
pretend it is passed by value and then cxx_eval_constant_expression
is called there and evaluates that as an rvalue, followed by
adjust_temp_type if the types don't match exactly (e.g. const Foo
argument and passing to it reference to Foo TARGET_EXPR).

The reason this doesn't work is that when the TARGET_EXPR in the caller
is constant initialized, this for it is the address of the
TARGET_EXPR_SLOT,
but if the code later on pretends the PARM_DECL is just initialized to the
rvalue of the constant evaluation of the TARGET_EXPR, it is as if there
is a bitwise copy of the TARGET_EXPR to the callee, so this in the callee
is then address of the PARM_DECL in the callee.

The following patch attempts to fix that by constexpr evaluation of such
arguments in the caller as an lvalue instead of rvalue, and on the callee
side when seeing such a PARM_DECL, if we want an lvalue, lookup the value
(lvalue) saved in ctx->globals (if any), and if wanting an rvalue,
recursing with vc_prvalue on the looked up value (because it is there
as an lvalue, nor rvalue).

adjust_temp_type doesn't work for lvalues of non-scalarish types, for
such types it relies on changing the type of a CONSTRUCTOR, but on the
other side we know what we pass to the argument is addressable, so
the patch on type mismatch takes address of the argument value, casts
to reference to the desired type and dereferences it.

2024-04-25  Jakub Jelinek  

PR c++/111284
* constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with
TREE_ADDRESSABLE types use vc_glvalue rather than vc_prvalue for
cxx_eval_constant_expression and if it doesn't have the same
type as it should, cast the reference type to reference to type
before convert_from_reference and instead of adjust_temp_type
take address of the arg, cast to reference to type and then
convert_from_reference.
(cxx_eval_constant_expression) : For lval case
on parameters with TREE_ADDRESSABLE types lookup result in
ctx->globals if possible.  Otherwise if lookup in ctx->globals
was successful for parameter with TREE_ADDRESSABLE type,
recurse with vc_prvalue on the returned value.

* g++.dg/cpp1z/constexpr-111284.C: New test.

(cherry picked from commit f541757ba4632e204169dd08a5f10c782199af42)

[Bug fortran/114825] [11/12/13 Regression] Compiler error using gfortran and OpenMP since r5-1190

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:6d30cfc3fc88976151d0d10e73e10111ccb71ee0

commit r13-8730-g6d30cfc3fc88976151d0d10e73e10111ccb71ee0
Author: Jakub Jelinek 
Date:   Thu Apr 25 20:09:35 2024 +0200

openmp: Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_? to tree-nested decl
copy [PR114825]

tree-nested.cc creates in 2 spots artificial VAR_DECLs, one of them is used
both for debug info and OpenMP/OpenACC lowering purposes, the other solely
for
OpenMP/OpenACC lowering purposes.
When the decls are used in OpenMP/OpenACC lowering, the OMP langhooks
(mostly
Fortran, C just a little and C++ doesn't have nested functions) then
inspect
the flags on the vars and based on that decide how to lower the
corresponding
clauses.

Unfortunately we weren't copying DECL_LANG_SPECIFIC and DECL_LANG_FLAG_?,
so
the langhooks made decisions on the default flags on those instead.
As the original decl isn't necessarily a VAR_DECL, could be e.g. PARM_DECL,
using copy_node wouldn't work properly, so this patch just copies those
flags in addition to other flags it was copying already.  And I've removed
code duplication by introducing a helper function which does copying common
to both uses.

2024-04-25  Jakub Jelinek  

PR fortran/114825
* tree-nested.cc (get_debug_decl): New function.
(get_nonlocal_debug_decl): Use it.
(get_local_debug_decl): Likewise.

* gfortran.dg/gomp/pr114825.f90: New test.

(cherry picked from commit 14d48516e588ad2b35e2007b3970bdcb1b3f145c)

[gcc r13-8729] libstdc++: Workaround kernel-headers on s390x-linux

[Jakub Jelinek via Libstdc++-cvs]

https://gcc.gnu.org/g:f1b1d515aa5836844cdb45e8bb2b941784f78fd2

commit r13-8729-gf1b1d515aa5836844cdb45e8bb2b941784f78fd2
Author: Jakub Jelinek 
Date:   Mon Apr 22 18:00:06 2024 +0200

libstdc++: Workaround kernel-headers on s390x-linux

We see
FAIL: 17_intro/headers/c++1998/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/headers/c++2011/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/headers/c++2014/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/headers/c++2017/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/headers/c++2020/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/names.cc  -std=gnu++17 (test for excess errors)
on s390x-linux.
The first 5 are due to kernel-headers not using uglified attribute names,
where  contains
__attribute__((packed, aligned(4)))
I've filed a downstream bugreport for this in
https://bugzilla.redhat.com/show_bug.cgi?id=2276084
(not really sure where to report kernel-headers issues upstream), while the
last one is due to  from glibc containing:
  #ifdef __USE_MISC
  # define __ctx(fld) fld
  #else
  # define __ctx(fld) __ ## fld
  #endif
  ...
  typedef union
{
  double  __ctx(d);
  float   __ctx(f);
} fpreg_t;
and g++ predefining -D_GNU_SOURCE which implies define __USE_MISC.

The following patch adds a workaround for this on the libstdc++ testsuite
side.

2024-04-22  Jakub Jelinek  

* testsuite/17_intro/names.cc (d, f): Undefine on s390*-linux*.
* testsuite/17_intro/headers/c++1998/all_attributes.cc (packed): 
Don't
define on s390.
* testsuite/17_intro/headers/c++2011/all_attributes.cc (packed):
Likewise.
* testsuite/17_intro/headers/c++2014/all_attributes.cc (packed):
Likewise.
* testsuite/17_intro/headers/c++2017/all_attributes.cc (packed):
Likewise.
* testsuite/17_intro/headers/c++2020/all_attributes.cc (packed):
Likewise.

(cherry picked from commit cf5f7791056b3ed993bc8024be767a86157514a9)

Diff:
---
 libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc | 4 
 libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc | 4 
 libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc | 4 
 libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc | 4 
 libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc | 4 
 libstdc++-v3/testsuite/17_intro/names.cc  | 6 ++
 6 files changed, 26 insertions(+)

diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc 
b/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
index 74268b6a482f..658063bd0a4e 100644
--- a/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
@@ -29,7 +29,11 @@
 # define noreturn 1
 # define visibility 1
 #endif
+#ifndef __s390__
+// kernel-headers  uses __attribute__((packed,aligned(4))) on
+// S390.
 #define packed 1
+#endif
 #define pure 1
 // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
 #ifndef __arm__
diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc 
b/libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc
index 5d0c5fe81776..f1bcc1fbbc81 100644
--- a/libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc
@@ -29,7 +29,11 @@
 # define visibility 1
 #endif
 #define no_unique_address 1
+#ifndef __s390__
+// kernel-headers  uses __attribute__((packed,aligned(4))) on
+// S390.
 #define packed 1
+#endif
 #define pure 1
 // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
 #ifndef __arm__
diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc 
b/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc
index 3cac2190ec77..48e7ef64afbe 100644
--- a/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc
@@ -29,7 +29,11 @@
 # define visibility 1
 #endif
 #define no_unique_address 1
+#ifndef __s390__
+// kernel-headers  uses __attribute__((packed,aligned(4))) on
+// S390.
 #define packed 1
+#endif
 #define pure 1
 // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
 #ifndef __arm__
diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc 
b/libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc
index f607532aa90d..03e4e23c6865 100644
--- a/libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc
@@ -28,7 +28,11 @@
 # define visibility 1
 #endif
 

Results for 14.1.1 20240507 [releases/gcc-14 r14-10185-g7e8fae89f35] (GCC) testsuite on i686-pc-linux-gnu

[haochenj--- via Gcc-testresults]

LAST_UPDATED: Thu May  9 03:09:04 UTC 2024 (revision r14-10185-g7e8fae89f35)

Native configuration is i686-pc-linux-gnu

=== gcc tests ===


Running target unix
FAIL: gcc.dg/pr96573.c scan-tree-dump optimized 
"__builtin_bswap|VEC_PERM_EXPR[^\\n\\r]*7, 6, 5, 4, 3, 2, 1, 0"
XPASS: gcc.dg/guality/example.c   -O0  execution test
XPASS: gcc.dg/guality/example.c   -O1  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/example.c  -Og -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O0  execution test
XPASS: gcc.dg/guality/guality.c   -O1  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O2  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/guality.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/guality.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -Os  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c  -Og -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/inline-params.c   -O2  -DPREVENT_OPTIMIZATION  execution 
test
XPASS: gcc.dg/guality/inline-params.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/inline-params.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/inline-params.c   -O3 -g  -DPREVENT_OPTIMIZATION  
execution test
XPASS: gcc.dg/guality/inline-params.c   -Os  -DPREVENT_OPTIMIZATION  execution 
test
FAIL: gcc.dg/guality/loop-1.c   -O2  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg1 == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg2 == 2
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg3 == 3
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg4 == 4
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg5 == 5
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg6 == 6
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg7 == 30
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg1 == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg2 == 2
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg3 == 3
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg4 == 4
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg5 == 5
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg6 == 6
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg7 == 30
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 arg1 
== 1
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 arg2 
== 2
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 arg3 
== 3
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 arg4 
== 4
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 arg5 
== 5
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 arg6 
== 6
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 arg7 
== 30
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 18 arg1 
== 1
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 18 arg2 
== 2
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 18 arg3 
== 3
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  

Results for 15.0.0 20240507 (experimental) [master r15-334-gbaf1a677955] (GCC) testsuite on i686-pc-linux-gnu

[haochenj--- via Gcc-testresults]

LAST_UPDATED: Thu May  9 03:00:42 UTC 2024 (revision r15-334-gbaf1a677955)

Native configuration is i686-pc-linux-gnu

=== gcc tests ===


Running target unix
FAIL: gcc.dg/pr96573.c scan-tree-dump optimized 
"__builtin_bswap|VEC_PERM_EXPR[^\\n\\r]*7, 6, 5, 4, 3, 2, 1, 0"
XPASS: gcc.dg/guality/example.c   -O0  execution test
XPASS: gcc.dg/guality/example.c   -O1  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/example.c  -Og -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O0  execution test
XPASS: gcc.dg/guality/guality.c   -O1  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O2  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/guality.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/guality.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -Os  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c  -Og -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/inline-params.c   -O2  -DPREVENT_OPTIMIZATION  execution 
test
XPASS: gcc.dg/guality/inline-params.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/inline-params.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/inline-params.c   -O3 -g  -DPREVENT_OPTIMIZATION  
execution test
XPASS: gcc.dg/guality/inline-params.c   -Os  -DPREVENT_OPTIMIZATION  execution 
test
FAIL: gcc.dg/guality/loop-1.c   -O2  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg1 == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg2 == 2
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg3 == 3
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg4 == 4
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg5 == 5
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg6 == 6
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg7 == 30
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg1 == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg2 == 2
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg3 == 3
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg4 == 4
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg5 == 5
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg6 == 6
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg7 == 30
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 arg1 
== 1
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 arg2 
== 2
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 arg3 
== 3
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 arg4 
== 4
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 arg5 
== 5
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 arg6 
== 6
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 arg7 
== 30
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 18 arg1 
== 1
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 18 arg2 
== 2
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 18 arg3 
== 3
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  

Results for 13.2.1 20240507 [releases/gcc-13 r13-8728-g929b0fffe4d] (GCC) testsuite on i686-pc-linux-gnu

[haochenj--- via Gcc-testresults]

LAST_UPDATED: Thu May  9 03:09:00 UTC 2024 (revision r13-8728-g929b0fffe4d)

Native configuration is i686-pc-linux-gnu

=== gcc tests ===


Running target unix
FAIL: gcc.dg/analyzer/data-model-4.c (test for excess errors)
FAIL: gcc.dg/analyzer/torture/conftest-1.c   -O0  (test for excess errors)
FAIL: gcc.dg/analyzer/torture/conftest-1.c   -O1  (test for excess errors)
FAIL: gcc.dg/analyzer/torture/conftest-1.c   -O2  (test for excess errors)
FAIL: gcc.dg/analyzer/torture/conftest-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (test for excess errors)
FAIL: gcc.dg/analyzer/torture/conftest-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.dg/analyzer/torture/conftest-1.c   -Os  (test for excess errors)
FAIL: gcc.dg/pr96573.c scan-tree-dump optimized 
"__builtin_bswap|VEC_PERM_EXPR[^\\n\\r]*7, 6, 5, 4, 3, 2, 1, 0"
FAIL: c-c++-common/goacc/kernels-loop-g.c (test for excess errors)
XPASS: gcc.dg/guality/example.c   -O0  execution test
XPASS: gcc.dg/guality/example.c   -O1  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/example.c  -Og -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O0  execution test
XPASS: gcc.dg/guality/guality.c   -O1  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O2  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/guality.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/guality.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -Os  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c  -Og -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/inline-params.c   -O2  -DPREVENT_OPTIMIZATION  execution 
test
XPASS: gcc.dg/guality/inline-params.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/inline-params.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/inline-params.c   -O3 -g  -DPREVENT_OPTIMIZATION  
execution test
XPASS: gcc.dg/guality/inline-params.c   -Os  -DPREVENT_OPTIMIZATION  execution 
test
XPASS: gcc.dg/guality/ipa-sra-1.c   -O0  line 15 k == 3
XPASS: gcc.dg/guality/ipa-sra-1.c   -O1  -DPREVENT_OPTIMIZATION  line 15 k == 3
XPASS: gcc.dg/guality/ipa-sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 15 k == 3
FAIL: gcc.dg/guality/loop-1.c   -O2  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg1 == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg2 == 2
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg3 == 3
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg4 == 4
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg5 == 5
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg6 == 6
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 arg7 == 30
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg1 == 1
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg2 == 2
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg3 == 3
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg4 == 4
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg5 == 5
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg6 == 6
FAIL: gcc.dg/guality/pr36728-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 arg7 == 30
FAIL: gcc.dg/guality/pr36728-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  

unsubscribe

[Anna Ceguerra via Gcc]

unsubscribe

On 7/5/2024, 8:34 pm, "gcc-announce on behalf of Richard Biener via 
gcc-announce" mailto:sydney.edu...@gcc.gnu.org> on behalf of gcc-annou...@gcc.gnu.org 
> wrote:


The GCC developers are proud to announce a new major GCC release, 14.1.


The C frontend when targeting standards newer than C89 now considers
many non-standard constructs as errors that were previously only
warnings. See 
https://url.au.m.mimecastprotect.com/s/xBuMCyojxQT6Lw3ByIZmuDt?domain=gcc.gnu.org
 

for more details. C23 _BitInt Bit-precise integer types are now
supported, for now only on IA-32, x86-64 and AArch64.


The C++ frontend now implements several C++26 features, some
missing C++23 bits and defect report resolutions. Diagnostics involving
C++ templates now quote source from the instantiation context.


The libstdc++exp.a library now includes all symbols for the
Filesystem TS and the experimental symbols for the C++23
std::stacktrace class, so -lstdc++exp can be used instead of
-lstdc++fs. The libstdc++_libbacktrace.a library is not longer
installed. Improved experimental support for C++20, C++23, and C++26.
Updated parallel algorithms that are compatible with oneTBB.


GCC now implements the Clang extensions __has_feature and __has_extension
for the C family language frontends.


The Fortran frontend now accepts -std=f2023 in preparation of support
of Fortran 2023.


GCC now has a new -fhardened flag to enable security hardening features
available on the target platform.


OpenMP and OpenACC offloading is made easier by no longer requiring
explicit passing of -lm or -lgfortran to the offload device linker.
The AMD GCN offload target gained support for select RDNA2 and RDNA3
graphics cards.


The vectorizer can now vectorize loops which contain alternate exits
such as via break statements and can now target RISC-V with a comparable
feature set than other main architectures. The #pragma GCC novector pragma
can be used to disable vectorization of annotated loops.


GCC's Static Analyzer has been greatly improved, still mainly targeting
C code.


The AArch64 target supports new hardware features like SME and SME2 and
can now handle GCCs function multiversioning.


The IA-32/x86-64 target can now target AVX10.1 and APX supporting CPUs
and can target recent and future announced CPU families.


The LoongArch port got support for vector ISA extensions and the
Ada and D frontends.


The RISC-V port now enables SLP and loop vectorization when the vector
extension is enabled and supports vector intrinsics as of the RVV 1.0
specification.


Some code that compiled successfully with older GCC versions might require
source changes, see 
https://url.au.m.mimecastprotect.com/s/JkG2CzvkyVC84ZzjmIX2a1P?domain=gcc.gnu.org
 

 for
details.


See


https://url.au.m.mimecastprotect.com/s/WcBPCANpgjCrEX5D1u9OyTA?domain=gcc.gnu.org
 



for more information about changes in GCC 14.1.


This release is available from the WWW and FTP servers listed here:


https://url.au.m.mimecastprotect.com/s/JCH_CBNqjlCP8rNLltjzNZz?domain=sourceware.org
 

https://url.au.m.mimecastprotect.com/s/bBUoCD1vlpTj3zZ8OFl0cma?domain=gcc.gnu.org
 



The release is in the gcc-14.1.0/ subdirectory.


If you encounter difficulties using GCC 14.1, please do not contact me
directly. Instead, please visit 
https://url.au.m.mimecastprotect.com/s/BNM8CE8wmrt1p2jZ6HQ30eS?domain=gcc.gnu.org
 

 for information about
getting help.


Driving a leading free software project such as GCC would not be possible
without support from its many contributors.
Not only its developers, but especially its regular testers and users which
contribute to its high quality. The list of individuals
is too large to thank individually!

[Bug testsuite/115001] [14/15 Regression] pr109062.c fails on hybrid Intel CPU

[xry111 at gcc dot gnu.org via Gcc-bugs]

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

Xi Ruoyao  changed:

   What|Removed |Added

Summary|pr109062.c fails on hybrid  |[14/15 Regression]
   |Intel CPU   |pr109062.c fails on hybrid
   ||Intel CPU
   Target Milestone|--- |14.2

[Bug testsuite/115001] New: pr109062.c fails on hybrid Intel CPU

[xry111 at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 115001
   Summary: pr109062.c fails on hybrid Intel CPU
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

Since r14-4571 GOMP_SPINCOUNT defaults to 1 on hybrid Intel CPUs, but
pr109062.c is not updated for the change.

[Bug c++/115000] Confusing 'cannot convert to 'int' in initialization' error message

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
I suspect all of the see also bugs here are the same issue, I described my try
of fixing that in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113#c8 .

[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #10 from chenglulu  ---
(In reply to Xi Ruoyao from comment #9)
> (In reply to chenglulu from comment #8)
> 
> > diff --git a/gcc/config/loongarch/loongarch-def.cc
> > b/gcc/config/loongarch/loongarch-def.cc
> > index e8c129ce643..f27284cb20a 100644
> > --- a/gcc/config/loongarch/loongarch-def.cc
> > +++ b/gcc/config/loongarch/loongarch-def.cc
> > @@ -111,11 +111,7 @@ loongarch_rtx_cost_data::loongarch_rtx_cost_data ()
> >   tune targets (i.e. -mtune=native while PRID does not correspond to
> >   any known "-mtune" type).  */
> >  array_tune loongarch_cpu_rtx_cost_data =
> > -  array_tune ()
> > -.set (CPU_LA664,
> > - loongarch_rtx_cost_data ()
> > -   .movcf2gr_ (COSTS_N_INSNS (1))
> > -   .movgr2cf_ (COSTS_N_INSNS (1)));
> > +  array_tune ();
> 
> But why?  Isn't movcf2gr and movgr2cf one-cycle on LA664?

I think this is weird too. I'm still testing other situations, and I'll find
out the reason after the testing is completed.

[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317

[xry111 at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Xi Ruoyao  ---
(In reply to chenglulu from comment #8)

> diff --git a/gcc/config/loongarch/loongarch-def.cc
> b/gcc/config/loongarch/loongarch-def.cc
> index e8c129ce643..f27284cb20a 100644
> --- a/gcc/config/loongarch/loongarch-def.cc
> +++ b/gcc/config/loongarch/loongarch-def.cc
> @@ -111,11 +111,7 @@ loongarch_rtx_cost_data::loongarch_rtx_cost_data ()
>   tune targets (i.e. -mtune=native while PRID does not correspond to
>   any known "-mtune" type).  */
>  array_tune loongarch_cpu_rtx_cost_data =
> -  array_tune ()
> -.set (CPU_LA664,
> - loongarch_rtx_cost_data ()
> -   .movcf2gr_ (COSTS_N_INSNS (1))
> -   .movgr2cf_ (COSTS_N_INSNS (1)));
> +  array_tune ();

But why?  Isn't movcf2gr and movgr2cf one-cycle on LA664?

[Bug c++/115000] Confusing 'cannot convert to 'int' in initialization' error message

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
Reduced:
```
template
concept bool c = false;

template
struct ts{};
struct S {};
S s;
ts t33{s};
```

[Bug c++/115000] Confusing 'cannot convert to 'int' in initialization' error message

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-05-09
   Keywords||error-recovery
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed. There is another issue like this. Basically the C++ front-end uses
int as a valid type after an error.

RE: [pushed][PR114810][LRA]: Recognize alternatives with lack of available registers for insn and demote them.

[Li, Pan2]

CC more RISC-V port people for awareness.

Pan

From: Li, Pan2 
Sent: Thursday, May 9, 2024 11:25 AM
To: Vladimir Makarov ; gcc-patches@gcc.gnu.org
Subject: RE: [pushed][PR114810][LRA]: Recognize alternatives with lack of 
available registers for insn and demote them.

Hi Vladimir,

Looks this patch results in some ICE in the rvv.exp of RISC-V backend, feel 
free to ping me if more information is needed for reproducing.

   = Summary of gcc testsuite =
| # of unexpected case / # of unique unexpected case
|  gcc |  g++ | gfortran |
rv64gcv/  lp64d/ medlow | 1061 /69 |0 / 0 |  - |
make: *** [Makefile:1096: report-gcc-newlib] Error 1

Just pick one imm_loop_invariant-10.c as below.

/home/pli/gcc/111/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/imm_loop_invariant-10.c:20:1:
 error: unrecognizable insn:
(insn 265 0 0 (parallel [
(set (reg:RVVMF8QI 309 [239])
(unspec:RVVMF8QI [
(reg:SI 0 zero)
] UNSPEC_VUNDEF))
(clobber (scratch:SI))
]) -1
 (nil))
during RTL pass: reload
…. gcc/testsuite/gcc.target/riscv/rvv/vsetvl/imm_loop_invariant-10.c:20:1: 
internal compiler error: in extract_insn, at recog.cc:2812
0xa9d309 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
../.././gcc/gcc/rtl-error.cc:108
0xa9d32b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../.././gcc/gcc/rtl-error.cc:116
0xa9bc07 extract_insn(rtx_insn*)
../.././gcc/gcc/recog.cc:2812
0x10e5ad2 ira_remove_insn_scratches(rtx_insn*, bool, _IO_FILE*, rtx_def* 
(*)(rtx_def*))
../.././gcc/gcc/ira.cc:5381
0x112868f remove_insn_scratches
../.././gcc/gcc/lra.cc:2154
0x112868f lra_emit_move(rtx_def*, rtx_def*)
../.././gcc/gcc/lra.cc:513
0x1136883 match_reload
../.././gcc/gcc/lra-constraints.cc:1184
0x1142ae4 curr_insn_transform
../.././gcc/gcc/lra-constraints.cc:4778
0x11443cb lra_constraints(bool)
../.././gcc/gcc/lra-constraints.cc:5481
0x112b192 lra(_IO_FILE*, int)
../.././gcc/gcc/lra.cc:2442
0x10e0e7f do_reload
../.././gcc/gcc/ira.cc:5973
0x10e0e7f execute
../.././gcc/gcc/ira.cc:6161

Pan

From: Vladimir Makarov mailto:vmaka...@redhat.com>>
Sent: Thursday, May 9, 2024 12:40 AM
To: gcc-patches@gcc.gnu.org
Subject: [pushed][PR114810][LRA]: Recognize alternatives with lack of available 
registers for insn and demote them.


The following patch is a fix for PR114810 from LRA side.

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

The patch was successfully bootstrapped and tested on x86_64, aarch64, ppc64le.

[Bug c++/115000] New: Confusing 'cannot convert to 'int' in initialization' error message

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 115000
   Summary: Confusing 'cannot convert to 'int' in initialization'
error message
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Consider the following:

#include 

struct S {
  S() = default;
  S(S&&) = default;
};

S s;
std::ranges::single_view r{s};

https://godbolt.org/z/65nvdaTfP

GCC reports constraints not satisfied which is correct, however, there is more:

:9:31: error: cannot convert 'S' to 'int' in initialization
9 | std::ranges::single_view r{s};
  |   ^
  |   |
  |   S

This is confusing since there is nothing to do with 'int'.

RE: [pushed][PR114810][LRA]: Recognize alternatives with lack of available registers for insn and demote them.

[Li, Pan2]

Hi Vladimir,

Looks this patch results in some ICE in the rvv.exp of RISC-V backend, feel 
free to ping me if more information is needed for reproducing.

   = Summary of gcc testsuite =
| # of unexpected case / # of unique unexpected case
|  gcc |  g++ | gfortran |
rv64gcv/  lp64d/ medlow | 1061 /69 |0 / 0 |  - |
make: *** [Makefile:1096: report-gcc-newlib] Error 1

Just pick one imm_loop_invariant-10.c as below.

/home/pli/gcc/111/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/imm_loop_invariant-10.c:20:1:
 error: unrecognizable insn:
(insn 265 0 0 (parallel [
(set (reg:RVVMF8QI 309 [239])
(unspec:RVVMF8QI [
(reg:SI 0 zero)
] UNSPEC_VUNDEF))
(clobber (scratch:SI))
]) -1
 (nil))
during RTL pass: reload
…. gcc/testsuite/gcc.target/riscv/rvv/vsetvl/imm_loop_invariant-10.c:20:1: 
internal compiler error: in extract_insn, at recog.cc:2812
0xa9d309 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
../.././gcc/gcc/rtl-error.cc:108
0xa9d32b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../.././gcc/gcc/rtl-error.cc:116
0xa9bc07 extract_insn(rtx_insn*)
../.././gcc/gcc/recog.cc:2812
0x10e5ad2 ira_remove_insn_scratches(rtx_insn*, bool, _IO_FILE*, rtx_def* 
(*)(rtx_def*))
../.././gcc/gcc/ira.cc:5381
0x112868f remove_insn_scratches
../.././gcc/gcc/lra.cc:2154
0x112868f lra_emit_move(rtx_def*, rtx_def*)
../.././gcc/gcc/lra.cc:513
0x1136883 match_reload
../.././gcc/gcc/lra-constraints.cc:1184
0x1142ae4 curr_insn_transform
../.././gcc/gcc/lra-constraints.cc:4778
0x11443cb lra_constraints(bool)
../.././gcc/gcc/lra-constraints.cc:5481
0x112b192 lra(_IO_FILE*, int)
../.././gcc/gcc/lra.cc:2442
0x10e0e7f do_reload
../.././gcc/gcc/ira.cc:5973
0x10e0e7f execute
../.././gcc/gcc/ira.cc:6161

Pan

From: Vladimir Makarov 
Sent: Thursday, May 9, 2024 12:40 AM
To: gcc-patches@gcc.gnu.org
Subject: [pushed][PR114810][LRA]: Recognize alternatives with lack of available 
registers for insn and demote them.


The following patch is a fix for PR114810 from LRA side.

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

The patch was successfully bootstrapped and tested on x86_64, aarch64, ppc64le.

[Bug target/113652] [14/15 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450

[bergner at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #25 from Peter Bergner  ---
(In reply to Michael Meissner from comment #23)
> 3) Only build the IEEE 128-bit libgcc bits if the user configured the
> compiler with --with-cpu=power7, --with-cpu=power8, --with-cpu=power9,
> --with-cpu=power10 (and in the future --with-cpu=power11 or
> --with-cpu=future).  This could be code that if __VSX__ is not defined, the
> libgcc support functions won't get built.  We would then remove the -mvsx
> option from the library support functions.

I think this is the solution we want, meaning if the target we're building
supports VSX, then we'll build the IEEE128 bits, otherwise, we won't build
them.  I think that is the only sane answer.

I also believe that if the user specifies a -mcpu= option (either implicitly or
explicitly) that doesn't support VSX (eg, power4, or 7450, etc.) and they also
explicitly use -mvsx, then we should emit an error message saying the -mcpu=
option doesn't support using -mvsx at the same time.  Ditto for -maltivec,
-mmma, etc.  We should not be silently enabling instruction support over and
above their -mcpu= selection just because its needed for VSX/Altivec/MMA/etc.
support.  Currently we don't emit an error and instead silently enable
generating instructions not supported by their -mcpu= option.

[PATCH v1] RISC-V: Make full-vec-move1.c test robust for optimization

[pan2 . li]

From: Pan Li 

During investigate the support of early break autovec, we notice
the test full-vec-move1.c will be optimized to 'return 0;' in main
function body.  Because somehow the value of V type is compiler
time constant,  and then the second loop will be considered as
assert (true).

Thus,  the ccp4 pass will eliminate these stmt and just return 0.

typedef int16_t V __attribute__((vector_size (128)));

int main ()
{
  V v;
  for (int i = 0; i < sizeof (v) / sizeof (v[0]); i++)
(v)[i] = i;

  V res = v;
  for (int i = 0; i < sizeof (v) / sizeof (v[0]); i++)
assert (res[i] == i); // will be optimized to assert (true)
}

This patch would like to introduce a extern function to use the res[i]
that get rid of the ccp4 optimization.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/vls-vlmax/full-vec-move1.c:
Introduce extern func use to get rid of ccp4 optimization.

Signed-off-by: Pan Li 
---
 .../gcc.target/riscv/rvv/autovec/vls-vlmax/full-vec-move1.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git 
a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/full-vec-move1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/full-vec-move1.c
index d73bad4af6f..fae2ae91572 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/full-vec-move1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/full-vec-move1.c
@@ -2,11 +2,12 @@
 /* { dg-additional-options "-std=c99 -O3 -march=rv64gcv_zvl128b -mabi=lp64d 
-fno-vect-cost-model -mrvv-vector-bits=zvl" } */
 
 #include 
-#include 
 
 /* This would cause us to emit a vl1r.v for VNx4HImode even when
the hardware vector size vl > 64.  */
 
+extern int16_t test_element (int16_t);
+
 typedef int16_t V __attribute__((vector_size (128)));
 
 int main ()
@@ -14,9 +15,10 @@ int main ()
   V v;
   for (int i = 0; i < sizeof (v) / sizeof (v[0]); i++)
 (v)[i] = i;
+
   V res = v;
   for (int i = 0; i < sizeof (v) / sizeof (v[0]); i++)
-assert (res[i] == i);
+test_element (res[i]);
 }
 
 /* { dg-final { scan-assembler-not {vl[1248]r.v} } }  */
-- 
2.34.1

[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #8 from chenglulu  ---
(In reply to Chen Chen from comment #0)
> We tested Loongarch64 CPU Loongson 3A6000 with "LA664" architecture in Linux
> operating system AOSC OS 11.4.0 (default gcc version is 13.2.0). And we
> found the 548.exchange2_r benchmark from SPEC 2017 INTrate suite suffered
> significant regressions from 14% to 28% with various compiling options.
> 
> The rate-1 results are following:
> 
/* snip */
> 
> after snapshot 20240317 score 18-23.1% lower with parameters "-g -Ofast
> -march=la664":   
> 13.2.0:"-march=la664" flag is not supported
> 20240317:  11.5 (227s)
> 20240324:  8.84 (296s)
> 20240430:  9.43 (278s)
> 14.1.0:9.42 (278s)
> 
/* snip */
> 
> 
> after snapshot 20240317 score 26.3-26.6% lower with parameters "-g -Ofast
> -march=la464":   
> 13.2.0:8.76 (299s)
> 20240317:  12.8 (205s)
> 20240324:  9.39 (279s)
> 20240430:  9.43 (278s)
> 14.1.0:9.43 (278s)
> 
> 

> 20240317:  11.5 (227s) -march=la664
> 20240317:  12.8 (205s) -march=la464
I looked for the reason for the gap between the above two results. The
performance regression is caused by r14-6814. If the following modifications
are made, the scores of -march=la664 and -march464 will be the same.

diff --git a/gcc/config/loongarch/loongarch-def.cc
b/gcc/config/loongarch/loongarch-def.cc
index e8c129ce643..f27284cb20a 100644
--- a/gcc/config/loongarch/loongarch-def.cc
+++ b/gcc/config/loongarch/loongarch-def.cc
@@ -111,11 +111,7 @@ loongarch_rtx_cost_data::loongarch_rtx_cost_data ()
  tune targets (i.e. -mtune=native while PRID does not correspond to
  any known "-mtune" type).  */
 array_tune loongarch_cpu_rtx_cost_data =
-  array_tune ()
-.set (CPU_LA664,
- loongarch_rtx_cost_data ()
-   .movcf2gr_ (COSTS_N_INSNS (1))
-   .movgr2cf_ (COSTS_N_INSNS (1)));
+  array_tune ();

[gcc r15-334] i386: fix ix86_hardreg_mov_ok with lra_in_progress

[Kong Lingling via Gcc-cvs]

https://gcc.gnu.org/g:baf1a677955a4dcfffe8d93966900af96600d642

commit r15-334-gbaf1a677955a4dcfffe8d93966900af96600d642
Author: konglin1 
Date:   Thu May 9 09:48:56 2024 +0800

i386: fix ix86_hardreg_mov_ok with lra_in_progress

Originally eliminate_regs_in_insnit will transform
(parallel [
  (set (reg:QI 130)
(plus:QI (subreg:QI (reg:DI 19 frame) 0)
  (const_int 96)))
  (clobber (reg:CC 17 flag))]) {*addqi_1}
to
(set (reg:QI 130)
 (subreg:QI (reg:DI 19 frame) 0)) {*movqi_internal}
when verify_changes.

But with No Flags add, it transforms
(set (reg:QI 5 di)
  (plus:QI (subreg:QI (reg:DI 19 frame) 0)
   (const_int 96))) {*addqi_1_nf}
to
(set (reg:QI 5 di)
 (subreg:QI (reg:DI 19 frame) 0)) {*addqi_1_nf}.
there is no extra clobbers at the end, and
its dest reg just is a hardreg. For ix86_hardreg_mov_ok,
it returns false. So it fails to update insn and causes
the ICE when transform to movqi_internal.

But actually it is ok and safe for ix86_hardreg_mov_ok
when lra_in_progress.

And tested the spec2017, the performance was not affected.

gcc/ChangeLog:

* config/i386/i386.cc (ix86_hardreg_mov_ok): Relax
hard reg mov restriction when lra in progress.

Diff:
---
 gcc/config/i386/i386.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index c2df4ab91ee9..54c6c445bf14 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -20355,7 +20355,8 @@ ix86_hardreg_mov_ok (rtx dst, rtx src)
   ? standard_sse_constant_p (src, GET_MODE (dst))
   : x86_64_immediate_operand (src, GET_MODE (dst)))
   && ix86_class_likely_spilled_p (REGNO_REG_CLASS (REGNO (dst)))
-  && !reload_completed)
+  && !reload_completed
+  && !lra_in_progress)
 return false;
   return true;
 }

[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
The following patterns could be improved/removed while doing this:
```
 /* (A - B) == 0 ? (A - B) : (B - A)same as (B - A) */
 /* (A - B) != 0 ? (A - B) : (B - A)same as (A - B) */
 /* (A - B) >=/> 0 ? (A - B) : (B - A)same as abs (A - B) */
 /* (A - B) <=/< 0 ? (A - B) : (B - A)same as -abs (A - B) */

```

Need to look if we need to improve ctz_table_index match.

[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||113265

--- Comment #4 from Andrew Pinski  ---
`X / -X is -1.` is PR 113265

```
int f(int a, int b, int x)
{
  x = a - b;
  int y = -x;
  return (x >= y ? x : y);
}
```
MAX -> ABS

```
int f(int a, int b, int x)
{
  x = a - b;
  int y = -x;
  return (x >= y ? y : x);
}
```
MIN -> -ABS

```
unsigned f(unsigned a, unsigned b, unsigned X, unsigned Y)
{
  X = a - b;
  unsigned t = -X;
return (X + 1) > Y ? t : 1;
}
```
// `(X + 1) > Y ? -X : 1` -> `X >= Y ? -X : 1` (unsigned)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113265
[Bug 113265] [11/12/13/14/15 Regression] Missed optimization for redundancy
computation elimination may be due to constant propagation about 0 too late

Results for 15.0.0 20240507 (experimental) [remotes/origin/master r15-333-gce51e6727c9] (GCC) testsuite on pru-unknown-elf

[The GnuPru BuildBot via Gcc-testresults]

LAST_UPDATED: Thu May  9 00:00:11 UTC 2024 (revision r15-333-gce51e6727c9)

Target is pru-unknown-elf
Host   is x86_64-pc-linux-gnu

=== gcc tests ===


Running target pru-sim
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c (test for excess errors)
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c 2 blank line(s) in output
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c expected multiline 
pattern lines 49-64
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c (test for excess errors)
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c 2 blank line(s) in output
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c expected multiline 
pattern lines 19-34
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-10.c (test for excess errors)
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-10.c 2 blank line(s) in output
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-10.c expected multiline pattern 
lines 13-28
FAIL: c-c++-common/pr103798-2.c  -Wc++-compat   scan-assembler-not memchr
FAIL: c-c++-common/pr103798-3.c  -Wc++-compat   scan-assembler-not memchr
FAIL: c-c++-common/pr103798-4.c  -Wc++-compat   scan-assembler-not memchr
FAIL: gcc.dg/20141029-1.c scan-rtl-dump-times final "mem/v(/.)*:HI" 4
XPASS: gcc.dg/attr-alloc_size-11.c missing range info for short (test for 
warnings, line 51)
XPASS: gcc.dg/attr-alloc_size-11.c missing range info for signed char (test for 
warnings, line 50)
FAIL: gcc.dg/c23-nullptr-1.c (test for excess errors)
UNRESOLVED: gcc.dg/c23-nullptr-1.c compilation failed to produce executable
FAIL: gcc.dg/gnu23-tag-composite-1.c  (test for errors, line 43)
FAIL: gcc.dg/gnu23-tag-composite-1.c (test for excess errors)
FAIL: gcc.dg/loop-9.c scan-rtl-dump loop2_invariant "Decided"
FAIL: gcc.dg/loop-9.c scan-rtl-dump loop2_invariant "without introducing a new 
temporary register"
FAIL: gcc.dg/pr110279-1.c scan-tree-dump-times widening_mul "Generated FMA" 3
FAIL: gcc.dg/pr23623.c scan-rtl-dump-times final "mem/v(/.)*:SI" 12
FAIL: gcc.dg/pr71478.c (internal compiler error: in lra_split_hard_reg_for, at 
lra-assigns.cc:1868)
FAIL: gcc.dg/pr71478.c (test for excess errors)
FAIL: gcc.dg/pr82929-2.c scan-tree-dump-times store-merging "Merging 
successful" 1
FAIL: gcc.dg/pr82929.c scan-tree-dump-times store-merging "Merging successful" 1
FAIL: gcc.dg/pr84877.c execution test
FAIL: gcc.dg/store_merging_1.c scan-tree-dump-times store-merging "Merging 
successful" 2
FAIL: gcc.dg/store_merging_10.c scan-tree-dump-times store-merging "Merging 
successful" 2
FAIL: gcc.dg/store_merging_11.c scan-tree-dump-times store-merging "Merging 
successful" 2
FAIL: gcc.dg/store_merging_13.c scan-tree-dump-times store-merging "Merging 
successful" 13
FAIL: gcc.dg/store_merging_14.c scan-tree-dump-times store-merging "Merging 
successful" 9
FAIL: gcc.dg/store_merging_15.c scan-tree-dump-times store-merging "Merging 
successful" 2
FAIL: gcc.dg/store_merging_2.c scan-tree-dump-times store-merging "Merging 
successful" 2
FAIL: gcc.dg/store_merging_20.c scan-tree-dump-times store-merging "Merging 
successful" 3
FAIL: gcc.dg/store_merging_21.c scan-tree-dump-times store-merging "Merging 
successful" 4
FAIL: gcc.dg/store_merging_22.c scan-tree-dump-times store-merging "Merging 
successful" 1
FAIL: gcc.dg/store_merging_22.c scan-tree-dump-times store-merging "New 
sequence of 1 stores to replace old one of 3 stores" 1
FAIL: gcc.dg/store_merging_26.c scan-tree-dump store-merging "New sequence of 1 
stores to replace old one of 2 stores"
FAIL: gcc.dg/store_merging_27.c scan-tree-dump store-merging "New sequence of 
[12] stores to replace old one of 3 stores"
FAIL: gcc.dg/store_merging_28.c scan-tree-dump-times store-merging "New 
sequence of [24] stores to replace old one of 6 stores" 1
FAIL: gcc.dg/store_merging_29.c scan-tree-dump store-merging "New sequence of 3 
stores to replace old one of 6 stores"
FAIL: gcc.dg/store_merging_4.c scan-tree-dump-times store-merging "Merging 
successful" 2
FAIL: gcc.dg/store_merging_5.c scan-tree-dump-times store-merging "MEM 
 [.*]" 1
FAIL: gcc.dg/store_merging_5.c scan-tree-dump-times store-merging "Merging 
successful" 1
FAIL: gcc.dg/store_merging_7.c scan-tree-dump-times store-merging "Merging 
successful" 1
FAIL: gcc.dg/store_merging_8.c scan-tree-dump-times store-merging "Merging 
successful" 2
FAIL: gcc.dg/store_merging_9.c scan-tree-dump-times store-merging "Merging 
successful" 2
WARNING: gcc.dg/torture/pr112305.c   -O0  execution test program timed out.
FAIL: gcc.dg/torture/pr112305.c   -O0  execution test
FAIL: gcc.dg/tree-ssa/dump-6.c scan-tree-dump store-merging "MEM  
[(char *)] = "
FAIL: gcc.dg/tree-ssa/dump-6.c scan-tree-dump store-merging "MEM  
[(char *)] = "
FAIL: gcc.dg/tree-ssa/dump-6.c scan-tree-dump store-merging "MEM  [(char *)] = "
FAIL: gcc.dg/tree-ssa/if-to-switch-1.c scan-tree-dump iftoswitch "Condition 
chain with [^\\n\\r]* BBs transformed into a switch statement."
FAIL: 

Results for 13.2.1 20240507 [releases/gcc-13 r13-8728-g929b0fffe4] (GCC) testsuite on powerpc64le-unknown-linux-gnu

[Bill Seurer (POWER8) via Gcc-testresults]

git commit g:929b0fffe4d3d836e07e5a398a8e176e65f8b2c2
gcc-descr r13-8728-g929b0fffe4d3d8

power8
Linux 5.4.0-177-generic ppc64le
GNU Make 4.2.1

DejaGnu:
DejaGnu version 1.6.2
Expect version  5.45.4
Tcl version 8.6

64-bit

LAST_UPDATED: Wed May  8 22:40:11 UTC 2024 (revision r13-8728-g929b0fffe4)

Native configuration is powerpc64le-unknown-linux-gnu

=== gcc tests ===


Running target unix
XPASS: gcc.dg/Wtrampolines.c standard descriptors (test for warnings, line 29)
XPASS: gcc.dg/guality/example.c   -O0  execution test
XPASS: gcc.dg/guality/example.c   -O1  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/example.c  -Og -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O0  execution test
XPASS: gcc.dg/guality/guality.c   -O1  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O2  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/guality.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c  -Og -DPREVENT_OPTIMIZATION  execution test
FAIL: gcc.dg/guality/inline-params-2.c   -O2  -DPREVENT_OPTIMIZATION  execution 
test
FAIL: gcc.dg/guality/inline-params-2.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
FAIL: gcc.dg/guality/inline-params-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION execution test
FAIL: gcc.dg/guality/inline-params-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  
execution test
FAIL: gcc.dg/guality/inline-params-2.c   -Os  -DPREVENT_OPTIMIZATION  execution 
test
XPASS: gcc.dg/guality/ipa-sra-1.c   -O0  line 15 k == 3
XPASS: gcc.dg/guality/ipa-sra-1.c   -O1  -DPREVENT_OPTIMIZATION  line 15 k == 3
XPASS: gcc.dg/guality/ipa-sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 15 k == 3
FAIL: gcc.dg/guality/loop-1.c   -O2  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 18 y == 
2
FAIL: gcc.dg/guality/pr36728-3.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 y == 2
FAIL: gcc.dg/guality/pr36728-3.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 y == 
2
FAIL: gcc.dg/guality/pr41353-1.c  -Og -DPREVENT_OPTIMIZATION  line 28 i == 37
FAIL: gcc.dg/guality/pr41353-1.c  -Og -DPREVENT_OPTIMIZATION  line 28 i1 == 2 * 
37
FAIL: gcc.dg/guality/pr41353-1.c  -Og -DPREVENT_OPTIMIZATION  line 28 i2 == 3 * 
37
XPASS: gcc.dg/guality/pr41353-1.c  -Og -DPREVENT_OPTIMIZATION  line 28 j == 28 
+ 37
FAIL: gcc.dg/guality/pr41447-1.c   -O2  -DPREVENT_OPTIMIZATION  execution test
FAIL: gcc.dg/guality/pr41447-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
FAIL: gcc.dg/guality/pr41447-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION execution test
FAIL: gcc.dg/guality/pr41447-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution 
test
FAIL: gcc.dg/guality/pr41447-1.c   -Os  -DPREVENT_OPTIMIZATION  execution test
FAIL: gcc.dg/guality/pr41616-1.c   -O2  -DPREVENT_OPTIMIZATION  execution test
FAIL: gcc.dg/guality/pr41616-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
FAIL: gcc.dg/guality/pr41616-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION execution test
FAIL: gcc.dg/guality/pr41616-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution 
test
FAIL: gcc.dg/guality/pr54200.c   -O1  -DPREVENT_OPTIMIZATION  line 20 z == 3
FAIL: gcc.dg/guality/pr54200.c   -O2  -DPREVENT_OPTIMIZATION  line 20 z == 3
FAIL: gcc.dg/guality/pr54200.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 20 z == 3
FAIL: gcc.dg/guality/pr54200.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 20 z == 3
FAIL: gcc.dg/guality/pr54200.c   -Os  -DPREVENT_OPTIMIZATION  line 20 z == 3
FAIL: gcc.dg/guality/pr54519-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 20 y == 25
FAIL: gcc.dg/guality/pr54519-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 20 z == 6
FAIL: gcc.dg/guality/pr54519-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 23 y 

[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Another one:
> ```
> int f(int a, int b, int x)
> {
>   x = a - b;
>   int y = -x;
>   return (x >= 0 ? x : 0) + (x <= 0 ? y : 0);
> }
> ```
> 
> This should be detected as `abs` (just like if the assignment to x is
> removed.

```
int f(int a, int b, int x)
{
  x = a - b;
  int y = -x;
  return (x >= 0 ? x : 0) + (y >= 0 ? y : 0);
}
```

[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|`a - b == b - a` -> `a ==   |A few missing optimizations
   |b`  |due to `a - b` and `b - a`
   ||not being detected as
   ||negatives of each other

--- Comment #2 from Andrew Pinski  ---
Another one:
```
int f(int a, int b, int x)
{
  x = a - b;
  int y = -x;
  return (x >= 0 ? x : 0) + (x <= 0 ? y : 0);
}
```

This should be detected as `abs` (just like if the assignment to x is
removed.

[Bug tree-optimization/114999] `a - b == b - a` -> `a == b`

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2024-05-09

--- Comment #1 from Andrew Pinski  ---
I have an idea on how to fix this.

[Bug tree-optimization/114999] New: `a - b == b - a` -> `a == b`

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 114999
   Summary: `a - b == b - a` -> `a == b`
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int f(int a, int b, int c)
{
c = a - b;
int d = -c;
int t =  c == d;
int t1 = c == 0;
return t == t1;
}
```

This is not able to optimize to 1 as we don't detect that `a - b` and `b - a`
are negative of each other.

```
(for cmp (eq ne)
 (simplify
  (cmp:c @0 (negate @0))
```

needs to be improved.

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> This is the pattern I added for the plus case:
> ```
> (for cnd (cond vec_cond)
> ...
>  /* (a != CST1) ? (a + CST2) : 0 -> (a + CST2) iff CST1 == -CST2 */
>  (simplify
>   (cnd (ne @0 uniform_integer_cst_p@1)
>(plus@3 @0 uniform_integer_cst_p@2)
>integer_zerop)
>   (if (wi::to_wide (uniform_integer_cst_p (@1))
>== -wi::to_wide (uniform_integer_cst_p (@2)))
>@3))
> )
> ```

Thinking about this slightly more, we should be able to handle (which LLVM does
not currently handles):
```
int optb(int v, int b) {
  // b = 8;
if (v != -b)
return v + b;
else
return 0;
}
```

too. Which means this is similar to PR 113265. So I should fix PR 113265 first
and then add the pattern for this case.

Results for 15.0.0 20240507 (experimental) [master revision gcc-15-333-gce51e6727c9] (GCC) testsuite on arm-unknown-linux-gnueabihf

[ci_notify--- via Gcc-testresults]

# From 
https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-arm-build/1386/:
LAST_UPDATED: 2024-05-08T22:39:47+00:00 (master revision 
gcc-15-333-gce51e6727c9) arm-linux-gnueabihf

Target is arm-unknown-linux-gnueabihf
Host   is arm-unknown-linux-gnueabihf

=== libatomic tests ===


Running target qemu

=== libatomic Summary ===

# of expected passes44
# of unsupported tests  5
Host   is arm-unknown-linux-gnueabihf

=== libgomp tests ===


Running target qemu
XPASS: libgomp.c/alloc-pinned-1.c execution test
XPASS: libgomp.c/alloc-pinned-2.c execution test

=== libgomp Summary ===

# of expected passes16097
# of unexpected successes   2
# of expected failures  284
# of unsupported tests  705
Host   is arm-unknown-linux-gnueabihf

=== libitm tests ===


Running target qemu

=== libitm Summary ===

# of expected passes44
# of expected failures  3
# of unsupported tests  1
Host   is arm-unknown-linux-gnueabihf

=== libstdc++ tests ===


Running target qemu
FAIL: 19_diagnostics/stacktrace/current.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/current.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/entry.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/entry.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc  -std=gnu++26 execution test
FAIL: 30_threads/async/async.cc  -std=gnu++17 execution test
FAIL: ext/rope/pthread7-rope.cc  -std=gnu++17 execution test

=== libstdc++ Summary ===

# of expected passes17323
# of unexpected failures10
# of expected failures  126
# of unsupported tests  780
Host   is x86_64-pc-linux-gnu

=== gcc tests ===


Running target qemu
FAIL: c-c++-common/asan/alloca_instruments_all_paddings.c   -O0  execution test
FAIL: c-c++-common/asan/alloca_instruments_all_paddings.c   -O1  execution test
FAIL: c-c++-common/asan/alloca_instruments_all_paddings.c   -O2  execution test
FAIL: c-c++-common/asan/alloca_instruments_all_paddings.c   -O2 -flto 
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: c-c++-common/asan/alloca_instruments_all_paddings.c   -O2 -flto 
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: c-c++-common/asan/alloca_instruments_all_paddings.c   -O3 
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  
execution test
FAIL: c-c++-common/asan/alloca_instruments_all_paddings.c   -O3 -g  execution 
test
FAIL: c-c++-common/asan/alloca_instruments_all_paddings.c   -Os  execution test
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O0  execution test
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O1  execution test
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O2  execution test
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O2 -flto 
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O2 -flto 
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O3 -g  execution test
FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -Os  execution test
FAIL: c-c++-common/asan/alloca_safe_access.c   -O0  execution test
FAIL: c-c++-common/asan/alloca_safe_access.c   -O1  execution test
FAIL: c-c++-common/asan/alloca_safe_access.c   -O2  execution test
FAIL: c-c++-common/asan/alloca_safe_access.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  execution test
FAIL: c-c++-common/asan/alloca_safe_access.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/asan/alloca_safe_access.c   -O3 -g  execution test
FAIL: c-c++-common/asan/alloca_safe_access.c   -Os  execution test
FAIL: c-c++-common/asan/asan-interface-1.c   -O0  execution test
FAIL: c-c++-common/asan/asan-interface-1.c   -O1  execution test
FAIL: c-c++-common/asan/asan-interface-1.c   -O2  execution test
FAIL: c-c++-common/asan/asan-interface-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  execution test
FAIL: c-c++-common/asan/asan-interface-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/asan/asan-interface-1.c   -O3 -g  execution test
FAIL: c-c++-common/asan/asan-interface-1.c   -Os  execution test
FAIL: c-c++-common/asan/asan-stack-small.c   -O0  execution test
FAIL: c-c++-common/asan/asan-stack-small.c   -O1  execution test
FAIL: 

[Bug target/114988] RISC-V: ICE in intrinsic __riscv_vfwsub_wf_f32mf2

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #2 from JuzheZhong  ---
Li Pan is going to work on it.

Hi, kito and Jeff.

Can this fix backport to GCC-14 ?

Re: Re: [PATCH 2/4] df: Add DF_LIVE_SUBREG problem

[钟居哲]

Thanks Dim.

We noticed there is regression in aarch64 CI.
We will fix it with following your comments and regression in aarch64 CI.



juzhe.zh...@rivai.ai
 
From: Dimitar Dimitrov
Date: 2024-05-08 23:57
To: 陈硕
CC: 丁乐华; gcc-patches; 钟居哲; 夏晋; vmakarov; richard.sandiford
Subject: Re: [PATCH 2/4] df: Add DF_LIVE_SUBREG problem
On Wed, May 08, 2024 at 11:34:48AM +0800, 陈硕 wrote:
> Hi Dimitar
> 
> 
> I send a patch just now, modifies accordingly
> 
> 
> some comments:
> 
> 
> Nit: Should have two spaces after the dot, per GNU coding style. 
> I'd suggest
> to run the contrib/check_GNU_style.py script on your patches.
> Do you mean "star" by "dot", i.e. "/*" should be "/* "?
 
No, I was referring to the following paragraph from
https://www.gnu.org/prep/standards/standards.html :
   "Please put two spaces after the end of a sentence in your comments, ..."
 
To fix, simply add a second space after the dot, e.g.:
  -   Like DF_LR, but include tracking subreg liveness. Currently used to 
provide
  +   Like DF_LR, but include tracking subreg liveness.  Currently used to 
provide
 
 
For reference, here is the output from the style checker:
  $ git show | ./contrib/check_GNU_style.py -
  === ERROR type #4: dot, space, space, new sentence (24 error(s)) ===
  ...
  gcc/df-problems.cc:1350:52:   Like DF_LR, but include tracking subreg 
liveness.█Currently used to provide
 
> 
> 
> These names seem a bit too short for global variables. Perhaps tuck
> them in a namespace?
> 
> Also, since these must remain empty, shouldn't they be declared as const?
> 
> namespace df {
>  const bitmap_head empty_bitmap;
>  const subregs_live empty_live;
> }
> 
> 
> 
> May be better if "namespace df" contains all DF related code? as a minor 
> modification, I add a prefix "df_" to the variables.
> Meanwhile, const seems inapropriate here, since it's returned as normal 
> pointer rather than const pointer in some funtions, 
> 
> change to const would break this return value type check, and a const_cast 
> would make the const meanlingless.
> 
> 
> more details see in the patch
 
Thanks for considering my suggestion.
 
Regards,
Dimitar
> 
> 
> regards
> Shuo
> 
> 
> 
 

gcc-11-20240508 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20240508 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20240508/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 16e27b6d03756bf1fae22607fa93107787a7b9cb

You'll find:

 gcc-11-20240508.tar.xz   Complete GCC

  SHA256=02fad9f4e0ade453bfbe1bb2f6c9f8fa223459c03ee0b606f1bc00f2d9ed1691
  SHA1=61afd70431cb5ea57efa543bae117f984bc0fb9a

Diffs from 11-20240501 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[seurer at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from seurer at gcc dot gnu.org ---
I tried that and with it trunk did finish building.  I am running a test of
that now.

Results for 11.4.1 20240507 [releases/gcc-11 revision 6c00c3245e:92af7454c6:16e27b6d03756bf1fae22607fa93107787a7b9cb] (GCC) testsuite on powerpc64le-unknown-linux-gnu

[Bill Seurer (POWER8) via Gcc-testresults]

git commit g:16e27b6d03756bf1fae22607fa93107787a7b9cb
gcc-descr r11-11421-g16e27b6d03756b

power8
Linux 5.4.0-177-generic ppc64le
GNU Make 4.2.1

DejaGnu:
DejaGnu version 1.6.2
Expect version  5.45.4
Tcl version 8.6

64-bit

LAST_UPDATED: Wed May  8 20:58:39 UTC 2024 (revision 
6c00c3245e:92af7454c6:16e27b6d03756bf1fae22607fa93107787a7b9cb)

Native configuration is powerpc64le-unknown-linux-gnu

=== gcc tests ===


Running target unix
FAIL: c-c++-common/attr-retain-6.c  -Wc++-compat   (test for warnings, line 21)
FAIL: c-c++-common/attr-retain-6.c  -Wc++-compat   scan-assembler 
__libc_freeres_fn,"ax"
FAIL: c-c++-common/attr-retain-7.c  -Wc++-compat   (test for warnings, line 6)
FAIL: c-c++-common/attr-retain-7.c  -Wc++-compat   scan-assembler 
.data.foo,"awR"
FAIL: c-c++-common/attr-retain-8.c  -Wc++-compat   (test for warnings, line 5)
FAIL: c-c++-common/attr-retain-8.c  -Wc++-compat   scan-assembler .data.foo,"aw"
XPASS: gcc.dg/Wtrampolines.c standard descriptors (test for warnings, line 29)
XPASS: gcc.dg/graphite/pr69728.c scan-tree-dump graphite "loop nest optimized"
XPASS: gcc.dg/guality/example.c   -O0  execution test
XPASS: gcc.dg/guality/example.c   -O1  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/example.c  -Og -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O0  execution test
XPASS: gcc.dg/guality/guality.c   -O1  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O2  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/guality.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c  -Og -DPREVENT_OPTIMIZATION  execution test
FAIL: gcc.dg/guality/inline-params-2.c   -O2  -DPREVENT_OPTIMIZATION  execution 
test
FAIL: gcc.dg/guality/inline-params-2.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
FAIL: gcc.dg/guality/inline-params-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION execution test
FAIL: gcc.dg/guality/inline-params-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  
execution test
FAIL: gcc.dg/guality/inline-params-2.c   -Os  -DPREVENT_OPTIMIZATION  execution 
test
FAIL: gcc.dg/guality/loop-1.c   -O2  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/loop-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 20 i == 1
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 18 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 18 y == 
2
FAIL: gcc.dg/guality/pr36728-3.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 y == 2
FAIL: gcc.dg/guality/pr36728-3.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 y == 
2
XPASS: gcc.dg/guality/pr41353-1.c   -O0  line 28 j == 28 + 37
FAIL: gcc.dg/guality/pr41353-1.c  -Og -DPREVENT_OPTIMIZATION  line 28 i == 37
FAIL: gcc.dg/guality/pr41353-1.c  -Og -DPREVENT_OPTIMIZATION  line 28 i1 == 2 * 
37
FAIL: gcc.dg/guality/pr41353-1.c  -Og -DPREVENT_OPTIMIZATION  line 28 i2 == 3 * 
37
XPASS: gcc.dg/guality/pr41353-1.c  -Og -DPREVENT_OPTIMIZATION  line 28 j == 28 
+ 37
FAIL: gcc.dg/guality/pr41447-1.c   -O2  -DPREVENT_OPTIMIZATION  execution test
FAIL: gcc.dg/guality/pr41447-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
FAIL: gcc.dg/guality/pr41447-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution 
test
FAIL: gcc.dg/guality/pr41447-1.c   -Os  -DPREVENT_OPTIMIZATION  execution test
FAIL: gcc.dg/guality/pr41616-1.c   -O2  -DPREVENT_OPTIMIZATION  execution test
FAIL: gcc.dg/guality/pr41616-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
FAIL: gcc.dg/guality/pr41616-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION execution test
FAIL: gcc.dg/guality/pr41616-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution 
test
FAIL: gcc.dg/guality/pr43051-1.c   -O1  -DPREVENT_OPTIMIZATION  line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O1  -DPREVENT_OPTIMIZATION  line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O2  -DPREVENT_OPTIMIZATION  line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O2  -DPREVENT_OPTIMIZATION  line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 35 v == 1
FAIL: 

[Bug c++/114994] [14/15 Regression] fmtlib named argument compiler error introduced in g++-14.1

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #5 from Patrick Palka  ---
A bit more reduced, demostrating it's not specific to UDLs:

struct udl_arg {
  udl_arg operator=(int);
};

void g(udl_arg&&);

template
void h() {
  udl_arg x;
  g(x=42);
}

int main() {
  h();
}

Re: [PATCH 1/2] RISC-V: Add tests for cpymemsi expansion

[Jeff Law]

On 5/7/24 11:52 PM, Christoph Müllner wrote:

cpymemsi expansion was available for RISC-V since the initial port.
However, there are not tests to detect regression.
This patch adds such tests.

Three of the tests target the expansion requirements (known length and
alignment). One test reuses an existing memcpy test from the by-pieces
framework (gcc/testsuite/gcc.dg/torture/inline-mem-cpy-1.c).

gcc/testsuite/ChangeLog:

* gcc.target/riscv/cpymemsi-1.c: New test.
* gcc.target/riscv/cpymemsi-2.c: New test.
* gcc.target/riscv/cpymemsi-3.c: New test.
* gcc.target/riscv/cpymemsi.c: New test.

OK
jeff

Re: [PATCH gcc-13-backport] RISCV: Add -m(no)-omit-leaf-frame-pointer support.

[Jeff Law]

On 5/8/24 11:32 AM, Palmer Dabbelt wrote:

From: Yanzhang Wang 

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_save_reg_p): Save ra for leaf
when enabling -mno-omit-leaf-frame-pointer
(riscv_option_override): Override omit-frame-pointer.
(riscv_frame_pointer_required): Save s0 for non-leaf function
(TARGET_FRAME_POINTER_REQUIRED): Override defination
* config/riscv/riscv.opt: Add option support.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/omit-frame-pointer-1.c: New test.
* gcc.target/riscv/omit-frame-pointer-2.c: New test.
* gcc.target/riscv/omit-frame-pointer-3.c: New test.
* gcc.target/riscv/omit-frame-pointer-4.c: New test.
* gcc.target/riscv/omit-frame-pointer-test.c: New test.

Signed-off-by: Yanzhang Wang 
(cherry picked from commit 39663298b5934831a0125e12f113ebd83248c3be)
---
I haven't tested this (just an all-gcc build), but I figured I'd just
send it now as it's kind of a grey area for backports: the flag itself
is a new feature, but it also fixes a compatibility issue with the psABI
-- which itself is a grey area, as the psABI change was a retrofit and is
marked as optional.  I'd test it before pushing it, but this is one of
those things where I'm not really sure what the backporting rules
indicate we should do.

There's more discussion on this LKML thread:
https://lore.kernel.org/linux-riscv/527dd4d8-f1e5-4581-b1e3-aa315fea8...@sifive.com/T/#mf15ccc659b7b8b838b88959fbea460210875eb9c

That also has a much smaller fix, but having the whole argument seems
like a nicer user interface to me -- then users who really want
compatibility with the psABI's section on frame records can just ask for
it directly (via the odd spelling `-fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer`, but too late to change that).

Thoughts on this for 13?

Given its target specific, I think we have a lot more leeway here.

I think there was a followup in the space.  defa8681d951




We'd probably also want it all the way back to 11, but I assume that's
going to be the same discussion.

Yea.

You might explicitly run it by Jakub.  But I'm certainly OK with this 
being backported.


jeff

Re: Re: [PATCH 4/4] lra: Apply DF_LIVE_SUBREG data

[钟居哲]

Thanks Vlad.

I noticed there is devel/subreg-coalesce branch.

We are working on supporting subreg coalesce in IRA/LRA base on the latest 
version of subreg DF patch.

And we will send the followup patches.

Thanks.


juzhe.zh...@rivai.ai
 
From: Vladimir Makarov
Date: 2024-05-09 00:29
To: Lehua Ding
CC: richard.sandiford; juzhe.zhong; gcc-patches
Subject: Re: [PATCH 4/4] lra: Apply DF_LIVE_SUBREG data
 
On 5/7/24 23:01, Lehua Ding wrote:
> Hi Vladimir,
>
> I'll send V3 patchs based on these comments. Note that these four 
> patches only support subreg liveness tracking and apply to IRA and LRA 
> pass. Therefore, no performance changes are expected before we support 
> subreg coalesce. There will be new patches later to complete the 
> subreg coalesce functionality. Support for subreg coalesce requires 
> support for subreg copy i.e. modifying the logic for conflict detection.
>
>
Thank you for your clarification that the current batch of patches does 
not change the performance.  I hope the next batch of patches will be 
added to devel/subreg-coalesce branch too for their easier evaluation.
 
 
 

[Bug c++/114992] [13/14/15 Regression] ICE during IPA pass: targetclone in add_to_same_comdat_group with calling a target clone with a lamdba in a comdat function

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE during IPA pass:|[13/14/15 Regression] ICE
   |targetclone in  |during IPA pass:
   |add_to_same_comdat_group,   |targetclone in
   |at symtab.cc:492|add_to_same_comdat_group
   ||with calling a target clone
   ||with a lamdba in a comdat
   ||function
   Keywords||ice-on-valid-code
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |13.3
   Last reconfirmed||2024-05-08

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
template  void helper_func(Callable) {}
template 
__attribute__((target_clones("avx2", "default")))
void handler(Callable) {}
struct cl {
  inline int func();
};
inline int cl::func()
{
helper_func([](int) {});
handler([this]() {});
}
cl f;
int g = f.func();
```

[Bug c++/114997] ICE with -std=c++20: unexpected expression ‘static_cast('\"')’ of kind static_cast_expr

[clopez at igalia dot com via Gcc-bugs]

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

--- Comment #2 from Carlos Alberto Lopez Perez  ---
On WebKit we finally work-arounded the problem by replacing `constexpr` with
`const` at commit
https://github.com/WebKit/WebKit/commit/1ee00a2309c03ed119e8591022ba14f936440d71

Re: [PATCH 2/4] fortran: Teach get_real_kind_from_node for Power 128 fp modes [PR112993]g

[Steve Kargl]

On Wed, May 08, 2024 at 01:27:53PM +0800, Kewen.Lin wrote:
> 
> Previously effective target fortran_real_c_float128 never
> passes on Power regardless of the default 128 long double
> is ibmlongdouble or ieeelongdouble.  It's due to that TF
> mode is always used for kind 16 real, which has precision
> 127, while the node float128_type_node for c_float128 has
> 128 type precision, get_real_kind_from_node can't find a
> matching as it only checks gfc_real_kinds[i].mode_precision
> and type precision.
> 
> With changing TFmode/IFmode/KFmode to have the same mode
> precision 128, now fortran_real_c_float12 can pass with
> ieeelongdouble enabled by default and test cases guarded
> with it get tested accordingly.  But with ibmlongdouble
> enabled by default, since TFmode has precision 128 which
> is the same as type precision 128 of float128_type_node,
> get_real_kind_from_node considers kind for TFmode matches
> float128_type_node, but it's wrong as at this time point
> TFmode is with ibm extended format.  So this patch is to
> teach get_real_kind_from_node to check one more field which
> can be differentiable from the underlying real format, it
> can avoid the unexpected matching when there more than one
> modes have the same precision.
> 
> Bootstrapped and regress-tested on:
>   - powerpc64-linux-gnu P8/P9 (with ibm128 by default)
>   - powerpc64le-linux-gnu P9/P10 (with ibm128 by default)
>   - powerpc64le-linux-gnu P9 (with ieee128 by default)
> 
> BR,
> Kewen
> -
>   PR target/112993
> 

First, I have no issue with Mikael's OK for committing the
patch. 

That said, Fortran has the concept of model numbers, which
are set in arith.c.  Does this change give the expected 
value for ibm128?  For example, with "REAL(16) X", one
has "DIGITS(X) = 113", which is the precision on the 
of the underlying IEEE754 binary128 type.

-- 
Steve

[Bug tree-optimization/114995] C++23 Assume keyword not being used for vectorization

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com,
   ||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
The above examples just show misunderstanding what __builtin_assume_aligned is
and what it is not.  You need to use the result of the built-in function in the
accesses to be able to use the alignment information, if you just try to
compare __builtin_assume_aligned (x, 32) == x, it will just fold as always
true.  The design of the builtin is to attach the alignment information to the
result of the builtin function only.

CCing Aldy/Andrew for whether prange can or could be taught to handle the
assume cases with uintptr_t and bitwise and + comparison.

[Bug c++/114994] [14/15 Regression] fmtlib named argument compiler error introduced in g++-14.1

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|fmtlib named argument   |[14/15 Regression] fmtlib
   |compiler error introduced   |named argument compiler
   |in g++-14.1 |error introduced in
   ||g++-14.1
   Target Milestone|--- |14.2
 Ever confirmed|0   |1
   Keywords|needs-reduction |rejects-valid
   Last reconfirmed||2024-05-08
 Status|UNCONFIRMED |NEW

--- Comment #4 from Andrew Pinski  ---
Reduced testcase:
```
typedef decltype(sizeof(1)) size_t;
struct udl_arg {
  const char *str;
  template  auto operator=(T &) const -> int {}
};
constexpr auto operator""_a(const char *s, size_t) -> udl_arg
{
  return {""};
}
template  void h(T &&);
template
int test(int a)
{
h("t"_a="t");
}
auto t = test<1>(1);

[Bug tree-optimization/114998] New: ICE on valid code at -O3 with "-fno-inline -fno-tree-dce -fno-ipa-cp" on x86_64-linux-gnu: Segmentation fault

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 114998
   Summary: ICE on valid code at -O3 with "-fno-inline
-fno-tree-dce -fno-ipa-cp" on x86_64-linux-gnu:
Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It reproduces for 14.1 and trunk, but not 13.2 and earlier. 

Compiler Explorer: https://godbolt.org/z/7xjf7EWGs

[865] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240507 (experimental) (GCC)
[866] %
[866] % gcctk -O3 -fno-inline -fno-tree-dce -fno-ipa-cp small.c
during GIMPLE pass: ldist
small.c: In function ‘main’:
small.c:4:5: internal compiler error: Segmentation fault
4 | int main() {
  | ^~~~
0x1175773 crash_signal
../../gcc-trunk/gcc/toplev.cc:319
0x7f4aef65008f ???
   
/build/glibc-e2p3jK/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x140bb04 vec::quick_push(tree_node* const&)
../../gcc-trunk/gcc/vec.h:1043
0x140bb04 tree_node** vec_safe_push(vec*&, tree_node* const&)
../../gcc-trunk/gcc/vec.h:835
0x140bb04 release_ssa_name_fn(function*, tree_node*)
../../gcc-trunk/gcc/tree-ssanames.cc:619
0x1249bba release_ssa_name(tree_node*)
../../gcc-trunk/gcc/tree-ssanames.h:124
0x1249bba remove_phi_node(gimple_stmt_iterator*, bool)
../../gcc-trunk/gcc/tree-phinodes.cc:457
0x11bc34e gimple_merge_blocks
../../gcc-trunk/gcc/tree-cfg.cc:2175
0xbf0b63 merge_blocks(basic_block_def*, basic_block_def*)
../../gcc-trunk/gcc/cfghooks.cc:820
0x11cbc29 cleanup_tree_cfg_bb
../../gcc-trunk/gcc/tree-cfgcleanup.cc:791
0x11cd564 cleanup_tree_cfg_noloop
../../gcc-trunk/gcc/tree-cfgcleanup.cc:1122
0x11cd564 cleanup_tree_cfg(unsigned int)
../../gcc-trunk/gcc/tree-cfgcleanup.cc:1205
0x102c29c execute_function_todo
../../gcc-trunk/gcc/passes.cc:2058
0x102cb4e execute_todo
../../gcc-trunk/gcc/passes.cc:2143
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
[867] %
[867] % cat small.c
short a, d;
int b, c, f, g, h, i, j[2], o;
void s(char r) {}
int main() {
  int l, m, k, n;
  if (b) {
char p;
for (; p >= 0; p--) {
  int e[] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0, 0,
 1, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0, 0, 1,
 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0};
  if (j[p]) {
int q[1];
i = o;
o = q[h];
if (g)
  n = d;
m = 4;
for (; m; m--) {
  if (l)
k |= c;
  if (a)
break;
}
  }
  s(n);
  f |= b;
}
  }
  return 0;
}

Results for 15.0.0 20240507 (experimental) [master revision gcc-15-333-gce51e6727c9] (GCC) testsuite on arm-unknown-eabi

[ci_notify--- via Gcc-testresults]

# From 
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m3_eabi-build/399/:
LAST_UPDATED: 2024-05-08T20:56:11+00:00 (master revision 
gcc-15-333-gce51e6727c9) arm-eabi 
{-mthumb/-march=armv7-m/-mtune=cortex-m3/-mfloat-abi=softfp/-mfpu=auto}

Target is arm-unknown-eabi
Host   is arm-unknown-eabi

=== libstdc++ tests ===


Running target 
qemu/-mthumb/-march=armv7-m/-mtune=cortex-m3/-mfloat-abi=softfp/-mfpu=auto
FAIL: 19_diagnostics/stacktrace/current.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/current.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/entry.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/entry.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/output.cc  -std=gnu++26 execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc  -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/stacktrace.cc  -std=gnu++26 execution test
FAIL: 22_locale/ctype/scan/wchar_t/1.cc  -std=gnu++17 execution test
FAIL: 27_io/basic_filebuf/underflow/wchar_t/11603.cc  -std=gnu++17 execution 
test
FAIL: 27_io/basic_fstream/53984.cc  -std=gnu++17 execution test
FAIL: 27_io/print/2.cc  -std=gnu++23 (test for excess errors)
UNRESOLVED: 27_io/print/2.cc  -std=gnu++23 compilation failed to produce 
executable
FAIL: 27_io/print/2.cc  -std=gnu++26 (test for excess errors)
UNRESOLVED: 27_io/print/2.cc  -std=gnu++26 compilation failed to produce 
executable
FAIL: 29_atomics/atomic_float/compare_exchange_padding.cc  -std=gnu++20 (test 
for excess errors)
UNRESOLVED: 29_atomics/atomic_float/compare_exchange_padding.cc  -std=gnu++20 
compilation failed to produce executable
FAIL: 29_atomics/atomic_float/compare_exchange_padding.cc  -std=gnu++26 (test 
for excess errors)
UNRESOLVED: 29_atomics/atomic_float/compare_exchange_padding.cc  -std=gnu++26 
compilation failed to produce executable
FAIL: experimental/simd/pr109261_constexpr_simd.cc -mfpu=neon 
-mfloat-abi=softfp -march=armv7-a -ffast-math -O2 -Wno-psabi (test for excess 
errors)
XPASS: ext/stdio_filebuf/char/10063-2.cc  -std=gnu++17 execution test
XPASS: ext/stdio_filebuf/char/10063-3.cc  -std=gnu++17 execution test

=== libstdc++ Summary ===

# of expected passes15948
# of unexpected failures16
# of unexpected successes   2
# of expected failures  131
# of unresolved testcases   4
# of unsupported tests  1025
Host   is x86_64-pc-linux-gnu

=== gcc tests ===


Running target 
qemu/-mthumb/-march=armv7-m/-mtune=cortex-m3/-mfloat-abi=softfp/-mfpu=auto
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c (test for excess errors)
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c 2 blank line(s) in output
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c expected multiline 
pattern lines 49-64
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c (test for excess errors)
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c 2 blank line(s) in output
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c expected multiline 
pattern lines 19-34
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-10.c (test for excess errors)
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-10.c 2 blank line(s) in output
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-10.c expected multiline pattern 
lines 13-28
FAIL: gcc.dg/auto-init-uninit-17.c unconditional (test for warnings, line 14)
FAIL: gcc.dg/fold-copysign-1.c scan-tree-dump-times cddce1 "= -" 1
FAIL: gcc.dg/fold-copysign-1.c scan-tree-dump-times cddce1 "= ABS_EXPR" 2
FAIL: gcc.dg/pr110279-1.c scan-tree-dump-times widening_mul "Generated FMA" 3
FAIL: gcc.dg/pr55152-2.c scan-tree-dump-times optimized "ABS_EXPR" 2
FAIL: gcc.dg/uninit-17.c unconditional (test for warnings, line 14)
FAIL: gcc.dg/ipa/ipa-icf-38.c scan-ltrans-tree-dump-not optimized "Function bar"
FAIL: gcc.dg/ipa/ipa-icf-38.c scan-wpa-ipa-dump icf "Equal symbols: 1"
FAIL: gcc.dg/ipa/ipa-icf-38.c scan-wpa-ipa-dump icf "Semantic equality 
hit:foo/[0-9+]+->bar/[0-9+]+"
FAIL: gcc.dg/plugin/must-tail-call-1.c -fplugin=./must_tail_call_plugin.so 
(internal compiler error: in df_refs_verify, at df-scan.cc:4019)
FAIL: gcc.dg/plugin/must-tail-call-1.c -fplugin=./must_tail_call_plugin.so 
(test for excess errors)
FAIL: gcc.dg/torture/arm-fp16-int-convert-alt.c   -O0  execution test
FAIL: gcc.dg/torture/arm-fp16-int-convert-alt.c   -O1  execution test
FAIL: gcc.dg/torture/arm-fp16-int-convert-alt.c   -O2  execution test
FAIL: gcc.dg/torture/arm-fp16-int-convert-alt.c   -O2 -flto 
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: gcc.dg/torture/arm-fp16-int-convert-alt.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/arm-fp16-int-convert-alt.c   -O3 -g  execution test
FAIL: gcc.dg/torture/arm-fp16-int-convert-alt.c   -Os  execution test
FAIL: gcc.dg/torture/arm-fp16-ops-3.c   -O0  execution 

[Bug c++/114997] ICE with -std=c++20: unexpected expression ‘static_cast('\"')’ of kind static_cast_expr

[clopez at igalia dot com via Gcc-bugs]

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

--- Comment #1 from Carlos Alberto Lopez Perez  ---
The original cpp file that causes the issue can be found here:
https://raw.githubusercontent.com/WebKit/WebKit/4855c7a1dc4214523c0b3d0c430215456ed7a0a9/Source/JavaScriptCore/runtime/JSONObject.cpp

just for reference, the md5hash of the file is

$ md5sum Source/JavaScriptCore/runtime/JSONObject.cpp
a4799453f1b2b3c0e2bec60a095c962d  Source/JavaScriptCore/runtime/JSONObject.cpp

[Bug c++/114997] New: ICE with -std=c++20: unexpected expression ‘static_cast('\"')’ of kind static_cast_expr

[clopez at igalia dot com via Gcc-bugs]

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

Bug ID: 114997
   Summary: ICE with -std=c++20: unexpected expression
‘static_cast('\"')’ of kind
static_cast_expr
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clopez at igalia dot com
  Target Milestone: ---

Created attachment 58137
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58137=edit
preprocessed file from JSONObject.cpp to reproduce the problem

On the WebKit project recently this commit landed:
https://github.com/WebKit/WebKit/commit/4855c7a1dc4214523c0b3d0c430215456ed7a0a9

It caused GCC-12 to fail with an ICE.

./Source/JavaScriptCore/runtime/JSONObject.cpp: In lambda function:
./Source/JavaScriptCore/runtime/JSONObject.cpp:1124:89: internal compiler
error: unexpected expression ‘static_cast('\"')’ of kind
static_cast_expr
 1124 | constexpr auto quoteMask =
WTF::splatBulk(static_cast('"'));
  |
^
0x7ffb005ff1c9 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7ffb005ff284 __libc_start_main_impl
../csu/libc-start.c:360
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

I checked that it fails with the last released version of GCC 12 (12.3.0) both
from Yocto
when cross-building for ARM64 as well as the GCC 12.3.0 shipped in
Debian/testing.

On Debian I tested with gcc-13 and with it builds fine.

I'm attaching the .ii file to reproduce the problem (compressed with xz as it
is quite big)

To reproduce it, download the .ii file and simple execute this command:


  g++-12 -O3 --std=c++20 -c JSONObject.ii


Not sure if useful information, but the original compiler command had the
following switches enabled

g++-12 -DBUILDING_JavaScriptCore -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DBUILDING_WPE__=1 -DBWRAP_EXECUTABLE=\"/usr/bin/bwrap\"
-DDBUS_PROXY_EXECUTABLE=\"/usr/bin/xdg-dbus-proxy\" -DGETTEXT_PACKAGE=\"WPE\"
-DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED -DPAS_BMALLOC=1
-DPKGLIBDIR=\"/usr/local/lib/wpe-webkit-2.0\" -DSTATICALLY_LINKED_WITH_WTF
-DSTATICALLY_LINKED_WITH_bmalloc
[...-I/long/list/of/includes/excluded/for/clarity...]
-fdiagnostics-color=always -Wextra -Wall  -fmax-errors=20 -Wno-odr
-Wno-stringop-overread -Wno-stringop-overflow -Wno-nonnull -Wno-array-bounds
-Wno-expansion-to-defined -Wno-noexcept-type -Wno-psabi
-Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef -Wpointer-arith
-Wmissing-format-attribute -Wformat-security -Wcast-align
-Wno-tautological-compare -fno-strict-aliasing -fno-exceptions -fno-rtti
-ffunction-sections -fdata-sections -O3 -DNDEBUG -fPIC -fvisibility=hidden
-fvisibility-inlines-hidden -ffp-contract=off -std=c++20 -c
Source/JavaScriptCore/runtime/JSONObject.cpp

Re: [Patch, fortran] PR84006 [11/12/13/14/15 Regression] ICE in storage_size() with CLASS entity

[Harald Anlauf]

Hi Paul,

this looks mostly good, but the new testcase transfer_class_4.f90
does exhibit a problem with your patch.  Run it with valgrind,
or with -fcheck=bounds, or with -fsanitize=address, or add the
following around the final transfer:

print *, storage_size (star_a), storage_size (chr_a), size (chr_a), len 
(chr_a)

  chr_a = transfer (star_a, chr_a)
print *, storage_size (star_a), storage_size (chr_a), size (chr_a), len 
(chr_a)

print *, ">", chr_a, "<"

This prints for me:

  40  40   2   5$
  40  40   4   5$
 >abcdefghij^@^@^@^@^@^@^@^@^@^@<$

So since the physical representation of chr_a is sufficient
to hold star_a (F2023:16.9.212), no reallocation with a wrong
calculated size should happen.  (Intel and NAG get this right.)

Can you check again?

Thanks,
Harald


Am 08.05.24 um 17:01 schrieb Paul Richard Thomas:

This fix is straightforward and described by the ChangeLog. Jose Rui
Faustino de Sousa posted the same fix for the ICE on the fortran list
slightly more than three years ago. Thinking that he had commit rights, I
deferred but, regrettably, the patch was never applied. The attached patch
also fixes storage_size and transfer for unlimited polymorphic arguments
with character payloads.

OK for mainline and backporting after a reasonable interval?

Paul

Fortran: Unlimited polymorphic intrinsic function arguments [PR84006]

2024-05-08  Paul Thomas  

gcc/fortran
PR fortran/84006
PR fortran/100027
PR fortran/98534
* trans-expr.cc (gfc_resize_class_size_with_len): Use the fold
even if a block is not available in which to fix the result.
(trans_class_assignment): Enable correct assignment of
character expressions to unlimited polymorphic variables using
lhs _len field and rse string_length.
* trans-intrinsic.cc (gfc_conv_intrinsic_storage_size): Extract
the class expression so that the unlimited polymorphic class
expression can be used in gfc_resize_class_size_with_len to
obtain the storage size for character payloads. Guard the use
of GFC_DECL_SAVED_DESCRIPTOR by testing for DECL_LANG_SPECIFIC
to prevent the ICE. Also, invert the order to use the class
expression extracted from the argument.
(gfc_conv_intrinsic_transfer): In same way as 'storage_size',
use the _len field to obtaining the correct length for arg 1.

gcc/testsuite/
PR fortran/84006
PR fortran/100027
* gfortran.dg/storage_size_7.f90: New test.

PR fortran/98534
* gfortran.dg/transfer_class_4.f90: New test.

[Bug tree-optimization/114995] C++23 Assume keyword not being used for vectorization

[pratikc at live dot co.uk via Gcc-bugs]

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

--- Comment #6 from Pratik Chowdhury  ---
> [[assume((uintptr_t(x_array) & (32-1)) == 0)]];

The Parans in the & have definitely given someone sleepless nights LOL. I
myself was saved by the warnings.

> Right now we don't always prop back what information we get from the assume 
> attributes.
Maybe with the recent prange addition, it can for pointers ...

Aah

Guess we will switch to assume in the future.


I tried [something else just about now](https://gcc.godbolt.org/z/d8aPjzMhq)

I think its a bit wrong. Clang seems to be able to handle it.

Is this syntax even valid?

```cpp
   
if(reinterpret_cast<::std::uintptr_t>(__builtin_assume_aligned((void*)(mul_array),
32)) != reinterpret_cast<::std::uintptr_t>(mul_array))
{
__builtin_unreachable();
}
   
if(reinterpret_cast<::std::uintptr_t>(__builtin_assume_aligned((void*)(add_array),
32)) != reinterpret_cast<::std::uintptr_t>(add_array))
{
__builtin_unreachable();
}
   
if(reinterpret_cast<::std::uintptr_t>(__builtin_assume_aligned((void*)(x_array),
32)) != reinterpret_cast<::std::uintptr_t>(x_array))
{
__builtin_unreachable();
}
```

I have my doubts on the previous one

But this should ideally be valid

```cpp
   
if((reinterpret_cast<::std::uintptr_t>(__builtin_assume_aligned((void*)(mul_array),
32)) & (32-1)) != 0)
{
__builtin_unreachable();
}
   
if((reinterpret_cast<::std::uintptr_t>(__builtin_assume_aligned((void*)(add_array),
32)) & (32-1)) != 0)
{
__builtin_unreachable();
}
   
if((reinterpret_cast<::std::uintptr_t>(__builtin_assume_aligned((void*)(x_array),
32)) & (32-1)) != 0)
{
__builtin_unreachable();
}
```

But either of them are unable to change the Load Stores from Unaligned to
Aligned.

Maybe victims of aggressive Dead Code elimination here? GCC intrinsics believe
that there can be no case its false and the code is deleted for the same?
Because __builtin_assume_aligned should always be a multiple of 32 in the above
cases.

Or __builtin_assume_aligned does not support usage like this in GCC and in
Clang it does? And due to that difference, we have a difference in behavior.

Its pretty interesting either way.

[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Aldy Hernandez  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> > --- Comment #13 from Aldy Hernandez  ---
> > BTW, I'm waiting for a review, or at least a nod from a C++ savvy person 
> > here:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650634.html
> 
> I can give the patch a whirl, thanks.

I've attached a rebased patch against current mainline.  Let me know if it
works on your end, and I'll commit.

> 
> I had Andrew's patch in my tree to avoid the issue.  Unfortunately,
> Solaris/SPARC bootstrap is broken again due to PR ipa/114985.

I have provided a patch for that PR as well, but the IPA folk need to say if
this is the correct approach.

[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #15 from Aldy Hernandez  ---
Created attachment 58136
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58136=edit
proposed patch in testing

[Bug tree-optimization/114995] C++23 Assume keyword not being used for vectorization

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=109045

--- Comment #5 from Andrew Pinski  ---
Right now we don't always prop back what information we get from the assume
attributes.
Maybe with the recent prange addition, it can for pointers ...

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Aldy Hernandez  ---
I wonder if something like this would work.

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index 5781f50..ea8a685 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -1730,6 +1730,8 @@ ipa_value_range_from_jfunc (vrange ,
}
   else
{
+ if (TREE_CODE_CLASS (operation) == tcc_comparison)
+   vr_type = boolean_type_node;
  Value_Range op_res (vr_type);
  Value_Range res (vr_type);
  tree op = ipa_get_jf_pass_through_operand (jfunc);

[Bug tree-optimization/114995] C++23 Assume keyword not being used for vectorization

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
Oh  this is the more correct syntax:
[[assume((uintptr_t(x_array) & (32-1)) == 0)]];
[[assume((uintptr_t(mul_array) & (32-1)) == 0)]];
[[assume((uintptr_t(add_array) & (32-1)) == 0)]];

[Bug rtl-optimization/114996] New: [15 Regression] [RISC-V] 2->2 combination no longer occurring

[law at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 114996
   Summary: [15 Regression] [RISC-V] 2->2 combination no longer
occurring
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

So this test has started failing on RISC-V after re-introduction of the change
to avoid 2->2 combinations when i2 is unchanged:

/* { dg-do compile } */
/* { dg-require-effective-target rv64 } */
/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" "-Os" "-Oz" } } */
/* { dg-options "-march=rv64gc_zba" } */

typedef unsigned int uint32_t;
typedef unsigned long uint64_t;

void foo(uint32_t a, uint64_t *b_ptr, uint64_t b, uint64_t *c_ptr, uint64_t c)
{
  uint64_t x = a;
  *b_ptr = b + x;
  *c_ptr = c + x;
}

/* { dg-final { scan-assembler-not "\\szext.w\\s" } } */


[ That's heavily reduced and twiddled a bit from a hot loop in xz IIRC. ]

The key thing to note about the test is we have a zero extension of a 32 bit
value to 64 bits.  The resulting 64 bit value is used in *two* subsequent
instructions.

As we start combine this looks like:

(insn 10 7 11 2 (set (reg/v:DI 136 [ x ])
(zero_extend:DI (subreg/s/u:SI (reg/v:DI 137 [ a ]) 0))) "j.c":11:12
458 {*zero_extendsidi2_bitmanip}
 (expr_list:REG_DEAD (reg/v:DI 137 [ a ])
(nil)))
(insn 11 10 12 2 (set (reg:DI 142 [ _1 ])
(plus:DI (reg/v:DI 136 [ x ])
(reg/v:DI 139 [ b ]))) "j.c":12:14 5 {adddi3}
 (expr_list:REG_DEAD (reg/v:DI 139 [ b ])
(nil)))
(insn 12 11 13 2 (set (mem:DI (reg/v/f:DI 138 [ b_ptr ]) [1 *b_ptr_7(D)+0 S8
A64])
(reg:DI 142 [ _1 ])) "j.c":12:10 268 {*movdi_64bit}
 (expr_list:REG_DEAD (reg:DI 142 [ _1 ])
(expr_list:REG_DEAD (reg/v/f:DI 138 [ b_ptr ])
(nil
(insn 13 12 14 2 (set (reg:DI 143 [ _2 ])
(plus:DI (reg/v:DI 136 [ x ])
(reg/v:DI 141 [ c ]))) "j.c":13:14 5 {adddi3}
 (expr_list:REG_DEAD (reg/v:DI 141 [ c ])
(expr_list:REG_DEAD (reg/v:DI 136 [ x ])
(nil
(insn 14 13 0 2 (set (mem:DI (reg/v/f:DI 140 [ c_ptr ]) [1 *c_ptr_10(D)+0 S8
A64])
(reg:DI 143 [ _2 ])) "j.c":13:10 268 {*movdi_64bit}
 (expr_list:REG_DEAD (reg:DI 143 [ _2 ])
(expr_list:REG_DEAD (reg/v/f:DI 140 [ c_ptr ])
(nil


Without the problematical combine change we would first combine 10->11 as a
2->2 combination.  Insn 10 would remain unchanged, but insn 11 would
incorporate the zero extension (RISC-V as an instruction for this).

After combining 10->11 (reg:DI 136) will have a single use enabling a 2->1
combination 10->13.

With the problematical combiner change the 10->11 combination fails because i2
hasn't changed and the 10->13 combination fails as well.  The net result is we
have an unnecessary zero extension in that loop.  Proper code for that testcase
is:
add.uw  a2,a0,a2
sd  a2,0(a1)
add.uw  a0,a0,a4
sd  a0,0(a3)

With that combiner change instead we're getting:

zext.w  a0,a0
add a2,a0,a2
sd  a2,0(a1)
add a0,a0,a4
sd  a0,0(a3)

[Bug tree-optimization/114995] C++23 Assume keyword not being used for vectorization

[pratikc at live dot co.uk via Gcc-bugs]

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

--- Comment #3 from Pratik Chowdhury  ---
Yeah definitely.

My bad.

Sorry.

@Andrew Pinski [however even that change does not seem to change the results
for GCC with Aligned Loads not being used](https://gcc.godbolt.org/z/9WbMbePc1)

Added the more corrected 2 Power Trick function at the very end 

Any other mistake I could have made?

[Bug tree-optimization/114995] C++23 Assume keyword not being used for vectorization

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
I suspect the syntax you want instead is:
[[assume(uintptr_t(x_array) & (32-1) == 0]];

Becuase __builtin_assume_aligned takes a pointer and returns a pointer that has
the assumed alignment

[Bug tree-optimization/114995] C++23 Assume keyword not being used for vectorization

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 58135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58135=edit
testcase

[Bug c++/114994] fmtlib named argument compiler error introduced in g++-14.1

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
Trying my hand at reducing this slightly.

Re: [PATCH] [RFC] Add function filtering to gcov

[Jan Hubicka]

> > 
> > For JSON output I suppose there's a way to "grep" without the line oriented
> > issue?  I suppose we could make the JSON more hierarchical by adding
> > an outer function object?
> 
> Absolutely, yes, this is much less useful for JSON. The filtering works,
> which may be occasionally handy for very large files, but jq and other query
> engines already work filter quite well. For me, the problem is actually
> working with JSON and mapping it back to the source.
> 
> > 
> > That said, I think this is a useful feature and thus OK for trunk if there 
> > are
> > no other comments in about a week if you also update the gcov documentation.
> 
> Thanks! I was actually surprised at how much I liked this feature once I
> started playing with it, and it made the edit, build, run, gcov -t cycle
> quite effective at exploring the program. For path coverage, filtering also
> becomes mandatory - the number of paths grows *very* quickly, and different
> levels of verbosity is useful too. Being able to focus on the function(s)
> you care about makes a huge difference.
> 
> I won't merge the patch in its current state - I will make a pass or two
> over it, add some documentation, and resubmit the patch, but not make large
> design changes unless someone objects. I won't merge that patch until it has
> been reviewed again, of course.

I also think it is useful feature to be able to restrict gcov to
selected functions.
Concerning path coverage profiling, this is something that can be
potentially also useful for optimization.  I.e. search for "Effecient
path profiling" by Ball and Larus on scholar.  One obvious thing to do
is to perform tail duplicaiton on code path that shows corelated
branches, but there are quite few other things to do with such
infrastructure (there are over 900 references to that at scholar and
some of them may be practically relevant).

Honza
> 
> Thanks,
> Jørgen
> 
> > 
> > Thanks,
> > Richard.
> > 
> > > ---
> > >   gcc/gcov.cc| 101 +++--
> > >   gcc/testsuite/g++.dg/gcov/gcov-19.C|  35 +
> > >   gcc/testsuite/g++.dg/gcov/gcov-20.C|  38 ++
> > >   gcc/testsuite/gcc.misc-tests/gcov-24.c |  20 +
> > >   gcc/testsuite/gcc.misc-tests/gcov-25.c |  23 ++
> > >   gcc/testsuite/gcc.misc-tests/gcov-26.c |  23 ++
> > >   gcc/testsuite/gcc.misc-tests/gcov-27.c |  22 ++
> > >   gcc/testsuite/lib/gcov.exp |  53 -
> > >   8 files changed, 306 insertions(+), 9 deletions(-)
> > >   create mode 100644 gcc/testsuite/g++.dg/gcov/gcov-19.C
> > >   create mode 100644 gcc/testsuite/g++.dg/gcov/gcov-20.C
> > >   create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-24.c
> > >   create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-25.c
> > >   create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-26.c
> > >   create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-27.c
> > > 
> > > diff --git a/gcc/gcov.cc b/gcc/gcov.cc
> > > index fad704eb7c9..e53765de00a 100644
> > > --- a/gcc/gcov.cc
> > > +++ b/gcc/gcov.cc
> > > @@ -46,6 +46,7 @@ along with Gcov; see the file COPYING3.  If not see
> > >   #include "color-macros.h"
> > >   #include "pretty-print.h"
> > >   #include "json.h"
> > > +#include "xregex.h"
> > > 
> > >   #include 
> > >   #include 
> > > @@ -643,6 +644,43 @@ static int flag_counts = 0;
> > >   /* Return code of the tool invocation.  */
> > >   static int return_code = 0;
> > > 
> > > +/* "Keep policy" when adding functions to the global function table.  
> > > This will
> > > +   be set to false when --include is used, otherwise every function 
> > > should be
> > > +   added to the table.  Used for --include/exclude.  */
> > > +static bool default_keep = true;
> > > +
> > > +/* A 'function filter', a filter and action for determining if a function
> > > +   should be included in the output or not.  Used for --include/--exclude
> > > +   filtering.  */
> > > +struct fnfilter
> > > +{
> > > +  /* The (extended) compiled regex for this filter.  */
> > > +  regex_t regex;
> > > +
> > > +  /* The action when this filter (regex) matches - if true, the function 
> > > should
> > > + be kept, otherwise discarded.  */
> > > +  bool keep;
> > > +
> > > +  /* Compile the regex EXPR, or exit if pattern is malformed.  */
> > > +  void compile (const char *expr)
> > > +  {
> > > +int err = regcomp (, expr, REG_NOSUB | REG_EXTENDED);
> > > +if (err)
> > > +  {
> > > +   size_t len = regerror (err, , nullptr, 0);
> > > +   char *msg = XNEWVEC (char, len);
> > > +   regerror (err, , msg, len);
> > > +   fprintf (stderr, "Bad regular expression: %s\n", msg);
> > > +   free (msg);
> > > +   exit (EXIT_FAILURE);
> > > +}
> > > +  }
> > > +};
> > > +
> > > +/* A collection of filter functions for including/exclude functions in 
> > > the
> > > +   output.  This is empty unless --include/--exclude is used.  */
> > > +static vector filters;
> > > +
> > >   /* Forward 

[Bug tree-optimization/114995] New: C++23 Assume keyword not being used for vectorization

[pratikc at live dot co.uk via Gcc-bugs]

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

Bug ID: 114995
   Summary: C++23 Assume keyword not being used for vectorization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pratikc at live dot co.uk
  Target Milestone: ---

I would like to share a [simple example](https://gcc.godbolt.org/z/dbTsb3YMG)

In this, as can be seen in the _second function_

1. GCC is able to take advantage of builtin_unreachable (because removing it
would change the line count)
2. GCC is able to take advantage of __builtin_assume_aligned. (Aligned Loads
and Stores)

Both of these seem fair

However, in the _first function_:-

1. [Assume
Keyword](https://en.cppreference.com/w/cpp/language/attributes/assume) is used
2. Unaligned Load Store is generated by GCC
3. Modulo operation advantage is not taken by GCC.  
   Clang seems to be taking advantage of the same though.  

It seems that thanks to the assume keyword there is scope for further
optimization gains.

The following syntax also seems to work in Clang

```cpp
[[assume(__builtin_assume_aligned(x_array, 32))]];
[[assume(__builtin_assume_aligned(mul_array, 32))]];
[[assume(__builtin_assume_aligned(add_array, 32))]];
```

Why I wanted to use the assume keyword?

1. There is scope for increased const correctness
2. Looks nicer

```cpp
/// @note This prototype works
void MulAddLoop(const float*  const __restrict mul_array,
const float*const  __restrict add_array, const ::std::size_t
size,
float* const __restrict x_array) {
```

PS:-

1. This is my first time filing a GCC Issue Report (I wouldn't really call this
a bug)  
2. I hope I linked to the correct component as I am not as well versed as I
hope I could be with the internals of GCC.

[committed] [RISC-V] Provide splitting guidance to combine to faciliate shNadd.uw generation

[Jeff Law]

This fixes a minor code quality issue I found while comparing GCC and 
LLVM.  Essentially we want to do a bit of re-association to generate 
shNadd.uw instructions.


Combine does the right thing and finds all the necessary instructions, 
reassociates the operands, combines constants, etc.  Where is fails is 
finding a good split point.  The backend can trivially provide guidance 
on how to split via a define_split pattern.


This has survived both Ventana's internal CI system (rv64gcb) as well as 
my own (rv64gc, rv32gcv).


I'll wait for the external CI system to give the all-clear before pushing.



jeff

diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index ad3ad758959..d76a72d30e0 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -184,6 +184,23 @@ (define_insn "*slliuw"
   [(set_attr "type" "bitmanip")
(set_attr "mode" "DI")])
 
+;; Combine will reassociate the operands in the most useful way here.  We
+;; just have to give it guidance on where to split the result to facilitate
+;; shNadd.uw generation.
+(define_split
+  [(set (match_operand:DI 0 "register_operand")
+   (plus:DI (plus:DI (and:DI (ashift:DI (match_operand:DI 1 
"register_operand")
+(match_operand:QI 2 
"imm123_operand"))
+ (match_operand 3 
"consecutive_bits32_operand"))
+ (match_operand:DI 4 "register_operand"))
+(match_operand 5 "immediate_operand")))]
+  "TARGET_64BIT && TARGET_ZBA"
+  [(set (match_dup 0)
+   (plus:DI (and:DI (ashift:DI (match_dup 1) (match_dup 2))
+(match_dup 3))
+(match_dup 4)))
+   (set (match_dup 0) (plus:DI (match_dup 0) (match_dup 5)))])
+
 ;; ZBB extension.
 
 (define_expand "clzdi2"
diff --git a/gcc/testsuite/gcc.target/riscv/zba-shadduw.c 
b/gcc/testsuite/gcc.target/riscv/zba-shadduw.c
new file mode 100644
index 000..5b77447e681
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/zba-shadduw.c
@@ -0,0 +1,35 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -march=rv64gc_zba -mabi=lp64" } */
+
+typedef struct simple_bitmap_def
+{
+  unsigned char *popcount;
+  unsigned int n_bits;
+  unsigned int size;
+  unsigned long elms[1];
+} *sbitmap;
+typedef const struct simple_bitmap_def *const_sbitmap;
+
+typedef unsigned long *sbitmap_ptr;
+typedef const unsigned long *const_sbitmap_ptr;
+static unsigned long sbitmap_elt_popcount (unsigned long);
+
+void
+sbitmap_a_or_b (sbitmap dst, const_sbitmap a, const_sbitmap b)
+{
+  unsigned int i, n = dst->size;
+  sbitmap_ptr dstp = dst->elms;
+  const_sbitmap_ptr ap = a->elms;
+  const_sbitmap_ptr bp = b->elms;
+  unsigned char has_popcount = dst->popcount != ((void *) 0);
+
+  for (i = 0; i < n; i++)
+{
+  const unsigned long tmp = *ap++ | *bp++;
+  *dstp++ = tmp;
+}
+}
+
+
+/* { dg-final { scan-assembler "sh3add.uw" } } */
+/* { dg-final { scan-assembler-not {\mslli.uw} } } */

[Bug c++/114994] fmtlib named argument compiler error introduced in g++-14.1

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
Note lambdas is not need can happen in any template function:
```
#include 

#define FMT_HEADER_ONLY

#include 
using namespace fmt::literals;

template
auto test(int a)
{
return fmt::format("{foo} {bar}", "foo"_a="foo", "bar"_a="bar");
}
auto t = test<1>(1);
```

[Bug c++/114994] fmtlib named argument compiler error introduced in g++-14.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||needs-reduction
 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Looks like it started with r14-4111:

commit 6e92a6a2a72d3b7a5e1b29042d8a6a43fe1085aa
Author: Patrick Palka 
Date:   Mon Sep 18 14:47:52 2023 -0400

c++: non-dependent assignment checking [PR63198, PR18474]

[gcc r15-333] [PATCH v1 1/1] RISC-V: Nan-box the result of movbf on soft-bf16

[Jeff Law via Gcc-cvs]

https://gcc.gnu.org/g:ce51e6727c9d69bbab0e766c449e60fd41f5f2f9

commit r15-333-gce51e6727c9d69bbab0e766c449e60fd41f5f2f9
Author: Xiao Zeng 
Date:   Wed May 8 14:00:58 2024 -0600

[PATCH v1 1/1] RISC-V: Nan-box the result of movbf on soft-bf16

1 This patch implements the Nan-box of bf16.

2 Please refer to the Nan-box implementation of hf16 in:



3 The discussion about Nan-box can be found on the website:



4 Below test are passed for this patch
* The riscv fully regression test.

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_legitimize_move): Expand movbf
with Nan-boxing value.
* config/riscv/riscv.md (*movbf_softfloat_boxing): New pattern.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/_Bfloat16-nanboxing.c: New test.

Diff:
---
 gcc/config/riscv/riscv.cc  | 52 --
 gcc/config/riscv/riscv.md  | 12 -
 .../gcc.target/riscv/_Bfloat16-nanboxing.c | 38 
 3 files changed, 77 insertions(+), 25 deletions(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 633b55f9707a..2eac67b0ce0a 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -3130,35 +3130,39 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)
 }
 
   /* In order to fit NaN boxing, expand
- (set FP_REG (reg:HF src))
+ (set FP_REG (reg:HF/BF src))
  to
  (set (reg:SI/DI mask) (const_int -65536)
- (set (reg:SI/DI temp) (zero_extend:SI/DI (subreg:HI (reg:HF src) 0)))
+ (set (reg:SI/DI temp) (zero_extend:SI/DI (subreg:HI (reg:HF/BF src) 0)))
  (set (reg:SI/DI temp) (ior:SI/DI (reg:SI/DI mask) (reg:SI/DI temp)))
- (set (reg:HF dest) (unspec:HF [ (reg:SI/DI temp) ] UNSPEC_FMV_SFP16_X))
+ (set (reg:HF/BF dest) (unspec:HF/BF[ (reg:SI/DI temp) ]
+   UNSPEC_FMV_SFP16_X/UNSPEC_FMV_SBF16_X))
  */
 
- if (TARGET_HARD_FLOAT
- && !TARGET_ZFHMIN && mode == HFmode
- && REG_P (dest) && FP_REG_P (REGNO (dest))
- && REG_P (src) && !FP_REG_P (REGNO (src))
- && can_create_pseudo_p ())
-   {
- rtx mask = force_reg (word_mode, gen_int_mode (-65536, word_mode));
- rtx temp = gen_reg_rtx (word_mode);
- emit_insn (gen_extend_insn (temp,
-simplify_gen_subreg (HImode, src, mode, 0),
-word_mode, HImode, 1));
- if (word_mode == SImode)
-   emit_insn (gen_iorsi3 (temp, mask, temp));
- else
-   emit_insn (gen_iordi3 (temp, mask, temp));
-
- riscv_emit_move (dest, gen_rtx_UNSPEC (HFmode, gen_rtvec (1, temp),
-   UNSPEC_FMV_SFP16_X));
-
- return true;
-   }
+  if (TARGET_HARD_FLOAT
+  && ((!TARGET_ZFHMIN && mode == HFmode)
+ || (!TARGET_ZFBFMIN && mode == BFmode))
+  && REG_P (dest) && FP_REG_P (REGNO (dest))
+  && REG_P (src) && !FP_REG_P (REGNO (src))
+  && can_create_pseudo_p ())
+{
+  rtx mask = force_reg (word_mode, gen_int_mode (-65536, word_mode));
+  rtx temp = gen_reg_rtx (word_mode);
+  emit_insn (gen_extend_insn (temp,
+ simplify_gen_subreg (HImode, src, mode, 0),
+ word_mode, HImode, 1));
+  if (word_mode == SImode)
+   emit_insn (gen_iorsi3 (temp, mask, temp));
+  else
+   emit_insn (gen_iordi3 (temp, mask, temp));
+
+  riscv_emit_move (dest,
+  gen_rtx_UNSPEC (mode, gen_rtvec (1, temp),
+  mode == HFmode ? UNSPEC_FMV_SFP16_X
+ : UNSPEC_FMV_SBF16_X));
+
+  return true;
+}
 
   /* We need to deal with constants that would be legitimate
  immediate_operands but aren't legitimate move_operands.  */
diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 620a1b3bd32f..4d6de9925572 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -86,8 +86,9 @@
   ;; String unspecs
   UNSPEC_STRLEN
 
-  ;; Workaround for HFmode without hardware extension
+  ;; Workaround for HFmode and BFmode without hardware extension
   UNSPEC_FMV_SFP16_X
+  UNSPEC_FMV_SBF16_X
 
   ;; XTheadFmv moves
   UNSPEC_XTHEADFMV
@@ -1926,6 +1927,15 @@
   [(set_attr "type" "fmove")
(set_attr "mode" "SF")])
 
+(define_insn "*movbf_softfloat_boxing"
+  [(set (match_operand:BF 0 "register_operand"   "=f")
+   (unspec:BF [(match_operand:X 1 "register_operand" " r")]
+UNSPEC_FMV_SBF16_X))]
+  "!TARGET_ZFBFMIN"
+  "fmv.w.x\t%0,%1"
+  [(set_attr "type" "fmove")
+   (set_attr "mode" "SF")])
+
 ;;
 ;;  
 ;;
diff 

Re: [PATCH v1 1/1] RISC-V: Nan-box the result of movbf on soft-bf16

[Jeff Law]

On 5/7/24 6:38 PM, Xiao Zeng wrote:

1 This patch implements the Nan-box of bf16.

2 Please refer to the Nan-box implementation of hf16 in:


3 The discussion about Nan-box can be found on the website:


4 Below test are passed for this patch
 * The riscv fully regression test.

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_legitimize_move): Expand movbf
with Nan-boxing value.
* config/riscv/riscv.md (*movbf_softfloat_boxing): New pattern.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/_Bfloat16-nanboxing.c: New test.
---
  gcc/config/riscv/riscv.cc | 51 ++-
  gcc/config/riscv/riscv.md | 12 -
  .../gcc.target/riscv/_Bfloat16-nanboxing.c| 38 ++
  3 files changed, 76 insertions(+), 25 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/riscv/_Bfloat16-nanboxing.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 545e68566dc..be2cb245733 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -3120,35 +3120,38 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)


  
- if (TARGET_HARD_FLOAT

- && !TARGET_ZFHMIN && mode == HFmode
- && REG_P (dest) && FP_REG_P (REGNO (dest))
- && REG_P (src) && !FP_REG_P (REGNO (src))
- && can_create_pseudo_p ())

[ ... ]


+  if (TARGET_HARD_FLOAT
+  && ((!TARGET_ZFHMIN && mode == HFmode)
+ || (!TARGET_ZFBFMIN && mode == BFmode))
+  && REG_P (dest) && FP_REG_P (REGNO (dest)) && REG_P (src)
+  && !FP_REG_P (REGNO (src)) && can_create_pseudo_p ())


So there's a bit of gratutious rewriting going on here.  I realize you 
were fixing formatting problems (thanks!), but I don't see a need to 
rewriting the tests starting with REG_P.  I put those back in their 
original form with the whitespace fixes.


I'll push the fixed version momentarily.

Thanks again!

jeff

Re: [PATCH] [RFC] Add function filtering to gcov

[Jørgen Kvalsvik]

On 5/8/24 15:29, Richard Biener wrote:

On Fri, Mar 29, 2024 at 8:02 PM Jørgen Kvalsvik  wrote:


This is a prototype for --include/--exclude flags, and I would like a
review of both the approach and architecture, and the implementation,
plus feedback on the feature itself. I did not update the manuals or
carefully extend --help, in case the interface itself needs some
revision before it can be merged.

---

Add the --include and --exclude flags to gcov to control what functions
to report on. This is meant to make gcov more practical as an when
writing test suites or performing other coverage experiments, which
tends to focus on a few functions at the time. This really shines in
combination with the -t/--stdout flag. With support for more expansive
metrics in gcov like modified condition/decision coverage (MC/DC) and
path coverage, output quickly gets overwhelming without filtering.

The approach is quite simple: filters are egrep regexes and are
evaluated left-to-right, and the last filter "wins", that is, if a
function matches an --include and a subsequent --exclude, it should not
be included in the output. The output machinery is already interacting
with the function table, which makes the json output work as expected,
and only minor changes are needed to suppress the filtered-out
functions.

Demo: math.c

 int mul (int a, int b) {
 return a * b;
 }

 int sub (int a, int b) {
 return a - b;
 }

 int sum (int a, int b) {
 return a + b;
 }

Plain matches:

$ gcov -t math --include=sum
 -:0:Source:filter.c
 -:0:Graph:filter.gcno
 -:0:Data:-
 -:0:Runs:0
 #:9:int sum (int a, int b) {
 #:   10:return a + b;

$ gcov -t math --include=mul
 -:0:Source:filter.c
 -:0:Graph:filter.gcno
 -:0:Data:-
 -:0:Runs:0
 #:1:int mul (int a, int b) {
 #:2:return a * b;

Regex match:

$ gcov -t math --include=su
 -:0:Source:filter.c
 -:0:Graph:filter.gcno
 -:0:Data:-
 -:0:Runs:0
 #:5:int sub (int a, int b) {
 #:6:return a - b;
 -:7:}
 #:9:int sum (int a, int b) {
 #:   10:return a + b;

And similar for exclude:

$ gcov -t math --exclude=sum
 -:0:Source:filter.c
 -:0:Graph:filter.gcno
 -:0:Data:-
 -:0:Runs:0
 #:1:int mul (int a, int b) {
 #:2:return a * b;
 -:3:}
 #:5:int sub (int a, int b) {
 #:6:return a - b;

And json, for good measure:

$ gcov -t math --include=sum --json | jq ".files[].lines[]"
{
   "line_number": 9,
   "function_name": "sum",
   "count": 0,
   "unexecuted_block": true,
   "block_ids": [],
   "branches": [],
   "calls": []
}
{
   "line_number": 10,
   "function_name": "sum",
   "count": 0,
   "unexecuted_block": true,
   "block_ids": [
 2
   ],
   "branches": [],
   "calls": []
}

Note that the last function gets "clipped" when lines are associated to
functions, which means the closing brace is dropped from the report. I
hope this can be fixed, but considering it is not really a part of the
function body, the gcov report is "complete".

Matching generally work well for mangled names, as the mangled names
also have the base symbol name in it. A possible extension to the
filtering commands would be to mix it with demangling to more nicely
being able to filter specific overloads, without manually having to
mangle the interesting symbols. The g++.dg/gcov/gcov-20.C test tests the
matching of a mangled name.

The dejagnu testing function verify-calls is somewhat minimal, but does
the job well enough.

Why not just use grep? grep is not really sufficient, as grep is very
line oriented, and the reports that benefit the most from filtering
often span multiple lines, unpredictably.


For JSON output I suppose there's a way to "grep" without the line oriented
issue?  I suppose we could make the JSON more hierarchical by adding
an outer function object?


Absolutely, yes, this is much less useful for JSON. The filtering works, 
which may be occasionally handy for very large files, but jq and other 
query engines already work filter quite well. For me, the problem is 
actually working with JSON and mapping it back to the source.




That said, I think this is a useful feature and thus OK for trunk if there are
no other comments in about a week if you also update the gcov documentation.


Thanks! I was actually surprised at how much I liked this feature once I 
started playing with it, and it made the edit, build, run, gcov -t cycle 
quite effective at exploring the program. For path coverage, filtering 
also becomes mandatory - the number of paths grows *very* quickly, and 
different levels of verbosity is useful too. Being able to focus on the 
function(s) you care about makes a huge difference.

[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #28 from Jakub Jelinek  ---
(In reply to Dmitrii Pasechnik from comment #26)
> We have megabytes of code calling libraries where setjmp/longjmp is used,
> in github.com/sagemath/sage/ (most of it in Cython).
> 
> It looks like a huge hassle to put volatiles there. 
> Looks like we would need ways to disable particular optimisations which lead
> to these sorts of errors:-(

You mean turn off all optimizations then?  -O0.
Even that doesn't guarantee it will work if some such variables are declared
with register keyword.

It isn't just POSIX which says this, e.g. C99 also says:
"All accessible objects have values, and all other components of the abstract
machine
have state, as of the time the longjmp function was called, except that the
values of
objects of automatic storage duration that are local to the function containing
the
invocation of the corresponding setjmp macro that do not have
volatile-qualified type
and have been changed between the setjmp invocation and longjmp call are
indeterminate."
C89 said pretty much the same.

[Linaro-TCWG-CI] gcc-15-95-ga12cae97390: FAIL: 3 regressions on arm

[ci_notify--- via Gcc-regression]

Dear contributor, our automatic CI has detected problems related to your 
patch(es).  Please find some details below.  If you have any questions, please 
follow up on linaro-toolch...@lists.linaro.org mailing list, Libera's 
#linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the 
usual project channel.

We appreciate that it might be difficult to find the necessary logs or 
reproduce the issue locally. If you can't get what you need from our CI within 
minutes, let us know and we will be happy to help.

We track this report status in https://linaro.atlassian.net/browse/GNU-1218 , 
please let us know if you are looking at the problem and/or when you have a fix.

In  master-arm after:

  | commit gcc-15-95-ga12cae97390
  | Author: Jason Merrill 
  | Date:   Tue Dec 12 18:07:28 2023 -0500
  | 
  | c++: drop in-charge for dtors without vbases
  | 
  | Constructors and destructors use the in-charge parameter to decide 
whether
  | they're responsible for recursing into virtual bases.  Historically all
  | destructors had this parameter in order to also distinguish the deleting
  | destructor.  But r151673 in GCC 4.5 changed the deleting destructor to 
just
  | call the complete destructor and then operator delete, making the 
in-charge
  | ... 16 lines of the commit log omitted.

FAIL: 3 regressions

regressions.sum:
=== gdb tests ===

Running gdb:gdb.cp/m-static.exp ...
FAIL: gdb.cp/m-static.exp: simple object instance, print destructor
FAIL: gdb.cp/m-static.exp: simple object instance, print quoted destructor
FAIL: gdb.cp/m-static.exp: simple object instance, ptype destructor


You can find the failure logs in *.log.1.xz files in
 - 
https://ci.linaro.org/job/tcwg_gnu_native_check_gdb--master-arm-build/1223/artifact/artifacts/00-sumfiles/
The full lists of regressions and progressions as well as configure and make 
commands are in
 - 
https://ci.linaro.org/job/tcwg_gnu_native_check_gdb--master-arm-build/1223/artifact/artifacts/notify/
The list of [ignored] baseline and flaky failures are in
 - 
https://ci.linaro.org/job/tcwg_gnu_native_check_gdb--master-arm-build/1223/artifact/artifacts/sumfiles/xfails.xfail

The configuration of this build is:
CI config tcwg_gnu_native_check_gdb master-arm

-8<--8<--8<--
The information below can be used to reproduce a debug environment:

Current build   : 
https://ci.linaro.org/job/tcwg_gnu_native_check_gdb--master-arm-build/1223/artifact/artifacts
Reference build : 
https://ci.linaro.org/job/tcwg_gnu_native_check_gdb--master-arm-build/1222/artifact/artifacts

Reproduce last good and first bad builds: 
https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sha1/a12cae973900f118436ef85c1197e91bf0428280/tcwg_gnu_native_check_gdb/master-arm/reproduction_instructions.txt

Full commit : 
https://github.com/gcc-mirror/gcc/commit/a12cae973900f118436ef85c1197e91bf0428280

List of configurations that regressed due to this commit :
* tcwg_gnu_native_check_gdb
** master-arm
*** FAIL: 3 regressions
*** 
https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sha1/a12cae973900f118436ef85c1197e91bf0428280/tcwg_gnu_native_check_gdb/master-arm/details.txt
*** 
https://ci.linaro.org/job/tcwg_gnu_native_check_gdb--master-arm-build/1223/artifact/artifacts

[Bug c++/114994] New: fmtlib named argument compiler error introduced in g++-14.1

[andrew.corrigan at gmail dot com via Gcc-bugs]

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

Bug ID: 114994
   Summary: fmtlib named argument compiler error introduced in
g++-14.1
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.corrigan at gmail dot com
  Target Milestone: ---

Demo: https://godbolt.org/z/oachhYKcT

First reported to https://github.com/fmtlib/fmt/issues/3953.  The fmtlib author
believes the error below is a compiler bug.  Using fmtlib's named arguments
inside a generic lambda stopped working as of g++-14.1.  The reproducer below
compiles on every other compiler I've tried (earlier versions of g++, clang++,
intel, and msvc)


```
#include 

#define FMT_HEADER_ONLY

#include 
using namespace fmt::literals;

int main()
{
auto test = [&](auto a)
{
return fmt::format("{foo} {bar}", "foo"_a="foo", "bar"_a="bar");
};

std::cout << test(1) << std::endl;

return 0;
}
```

Error:
```
:12:50: error: cannot bind non-const lvalue reference of type
'fmt::v10::detail::named_arg&' to an rvalue of type
'fmt::v10::detail::named_arg'
   12 | return fmt::format("{foo} {bar}", "foo"_a="foo",
"bar"_a="bar");
  |   ~~~^~
```

Changing `auto a` to `int a` works around the error.

Thank you!

[gcc r15-332] [RISC-V][V2] Fix incorrect if-then-else nesting of Zbs usage in constant synthesis

[Jeff Law via Gcc-cvs]

https://gcc.gnu.org/g:1c234097487927a4388ddcc690b63597bb3a90dc

commit r15-332-g1c234097487927a4388ddcc690b63597bb3a90dc
Author: Jeff Law 
Date:   Wed May 8 13:44:00 2024 -0600

[RISC-V][V2] Fix incorrect if-then-else nesting of Zbs usage in constant 
synthesis

Reposting without the patch that ignores whitespace.  The CI system doesn't
like including both patches, that'll generate a failure to apply and none of
the tests actually get run.

So I managed to goof the if-then-else level of the bseti bits last week.  
They
were supposed to be a last ditch effort to improve the result, but ended up
inside a conditional where they don't really belong.  I almost always use 
Zba,
Zbb and Zbs together, so it slipped by.

So it's NFC if you always test with Zbb and Zbs enabled together.  But if 
you
enabled Zbs without Zbb you'd see a failure to use bseti.

gcc/
* config/riscv/riscv.cc (riscv_build_integer_1): Fix incorrect
if-then-else nesting of Zbs code.

Diff:
---
 gcc/config/riscv/riscv.cc | 81 ---
 1 file changed, 41 insertions(+), 40 deletions(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 62207b6b2273..633b55f9707a 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -878,50 +878,51 @@ riscv_build_integer_1 (struct riscv_integer_op 
codes[RISCV_MAX_INTEGER_OPS],
  codes[1].use_uw = false;
  cost = 2;
}
-  /* Final cases, particularly focused on bseti.  */
-  else if (cost > 2 && TARGET_ZBS)
-   {
- int i = 0;
+}
 
- /* First handle any bits set by LUI.  Be careful of the
-SImode sign bit!.  */
- if (value & 0x7800)
-   {
- alt_codes[i].code = (i == 0 ? UNKNOWN : IOR);
- alt_codes[i].value = value & 0x7800;
- alt_codes[i].use_uw = false;
- value &= ~0x7800;
- i++;
-   }
+  /* Final cases, particularly focused on bseti.  */
+  if (cost > 2 && TARGET_ZBS)
+{
+  int i = 0;
 
- /* Next, any bits we can handle with addi.  */
- if (value & 0x7ff)
-   {
- alt_codes[i].code = (i == 0 ? UNKNOWN : PLUS);
- alt_codes[i].value = value & 0x7ff;
- alt_codes[i].use_uw = false;
- value &= ~0x7ff;
- i++;
-   }
+  /* First handle any bits set by LUI.  Be careful of the
+SImode sign bit!.  */
+  if (value & 0x7800)
+   {
+ alt_codes[i].code = (i == 0 ? UNKNOWN : IOR);
+ alt_codes[i].value = value & 0x7800;
+ alt_codes[i].use_uw = false;
+ value &= ~0x7800;
+  i++;
+   }
 
- /* And any residuals with bseti.  */
- while (i < cost && value)
-   {
- HOST_WIDE_INT bit = ctz_hwi (value);
- alt_codes[i].code = (i == 0 ? UNKNOWN : IOR);
- alt_codes[i].value = 1UL << bit;
- alt_codes[i].use_uw = false;
- value &= ~(1ULL << bit);
- i++;
-   }
+  /* Next, any bits we can handle with addi.  */
+  if (value & 0x7ff)
+   {
+ alt_codes[i].code = (i == 0 ? UNKNOWN : PLUS);
+ alt_codes[i].value = value & 0x7ff;
+ alt_codes[i].use_uw = false;
+ value &= ~0x7ff;
+ i++;
+   }
 
- /* If LUI+ADDI+BSETI resulted in a more efficient
-sequence, then use it.  */
- if (i < cost)
-   {
- memcpy (codes, alt_codes, sizeof (alt_codes));
- cost = i;
-   }
+  /* And any residuals with bseti.  */
+  while (i < cost && value)
+   {
+ HOST_WIDE_INT bit = ctz_hwi (value);
+ alt_codes[i].code = (i == 0 ? UNKNOWN : IOR);
+ alt_codes[i].value = 1UL << bit;
+ alt_codes[i].use_uw = false;
+ value &= ~(1ULL << bit);
+ i++;
+   }
+
+  /* If LUI+ADDI+BSETI resulted in a more efficient
+sequence, then use it.  */
+  if (i < cost)
+   {
+ memcpy (codes, alt_codes, sizeof (alt_codes));
+ cost = i;
}
 }

Re: Ping [PATCH/RFC] target, hooks: Allow a target to trap on unreachable [PR109267].

[Andrew Pinski]

On Wed, May 8, 2024 at 12:37 PM Iain Sandoe  wrote:
>
> Hi Folks,
>
> I’d like to land a viable solution to this issue if possible, (it is a show-
> stopper for the aarch64-darwin development branch).
>
> > On 9 Apr 2024, at 14:55, Iain Sandoe  wrote:
> >
> > So far, tested lightly on aarch64-darwin; if this is acceptable then
> > it will be possible to back out of the ad hoc fixes used on x86 and
> > powerpc darwin.
> > Comments welcome, thanks,
>
> @Andrew - you were also (at one stage) talking about some ideas about
> how to handle this is in the middle end.
> Is that something you are likely to have time to do?
> Would it still be reasonable to have a target hook to control the behaviour.
> (the implementation below allows one to make the effect per TU)

I won't be able to implement the idea until July at earliest though.

Thanks,
Andrew

>
>
> > Iain
> >
> > --- 8< ---
> >
> >
> > In the PR cited case a target linker cannot handle enpty FDEs,
> > arguably this is a linker bug - but in some cases we might still
> > wish to work around it.
> >
> > In the case of Darwin, the ABI does not allow two global symbols
> > to have the same address, so that emitting empty functions has
> > potential (almost guarantee) to break ABI.
> >
> > This patch allows a target to ask that __builtin_unreachable is
> > expanded in the same way as __builtin_trap (either to a trap
> > instruction or to abort() if there is no such insn).
> >
> > This means that the middle end's use of unreachability for
> > optimisation should not be altered.
> >
> > __builtin_unreachble is currently expanded to a barrier and
> > __builtin_trap is expanded to a trap insn + a barrier so that it
> > seems we should not be unduly affecting RTL optimisations.
> >
> > For Darwin, we enable this by default, but allow it to be disabled
> > per TU using -mno-unreachable-traps.
> >
> >   PR middle-end/109267
> >
> > gcc/ChangeLog:
> >
> >   * builtins.cc (expand_builtin_unreachable): Allow for
> >   a target to expand this as a trap.
> >   * config/darwin-protos.h (darwin_unreachable_traps_p): New.
> >   * config/darwin.cc (darwin_unreachable_traps_p): New.
> >   * config/darwin.h (TARGET_UNREACHABLE_SHOULD_TRAP): New.
> >   * config/darwin.opt (munreachable-traps): New.
> >   * doc/invoke.texi: Document -munreachable-traps.
> >   * doc/tm.texi: Regenerate.
> >   * doc/tm.texi.in: Document TARGET_UNREACHABLE_SHOULD_TRAP.
> >   * target.def (TARGET_UNREACHABLE_SHOULD_TRAP): New hook.
> >
> > Signed-off-by: Iain Sandoe 
> > ---
> > gcc/builtins.cc|  7 +++
> > gcc/config/darwin-protos.h |  1 +
> > gcc/config/darwin.cc   |  7 +++
> > gcc/config/darwin.h|  4 
> > gcc/config/darwin.opt  |  4 
> > gcc/doc/invoke.texi|  7 ++-
> > gcc/doc/tm.texi|  5 +
> > gcc/doc/tm.texi.in |  2 ++
> > gcc/target.def | 10 ++
> > 9 files changed, 46 insertions(+), 1 deletion(-)
> >
> > diff --git a/gcc/builtins.cc b/gcc/builtins.cc
> > index f8d94c4b435..13f321b6be6 100644
> > --- a/gcc/builtins.cc
> > +++ b/gcc/builtins.cc
> > @@ -5929,6 +5929,13 @@ expand_builtin_trap (void)
> > static void
> > expand_builtin_unreachable (void)
> > {
> > +  /* If the target wants a trap in place of the fall-through, use that.  */
> > +  if (targetm.unreachable_should_trap ())
> > +{
> > +  expand_builtin_trap ();
> > +  return;
> > +}
> > +
> >   /* Use gimple_build_builtin_unreachable or builtin_decl_unreachable
> >  to avoid this.  */
> >   gcc_checking_assert (!sanitize_flags_p (SANITIZE_UNREACHABLE));
> > diff --git a/gcc/config/darwin-protos.h b/gcc/config/darwin-protos.h
> > index b67e05264e1..48a32b2ccc2 100644
> > --- a/gcc/config/darwin-protos.h
> > +++ b/gcc/config/darwin-protos.h
> > @@ -124,6 +124,7 @@ extern void darwin_enter_string_into_cfstring_table 
> > (tree);
> > extern void darwin_asm_output_anchor (rtx symbol);
> > extern bool darwin_use_anchors_for_symbol_p (const_rtx symbol);
> > extern bool darwin_kextabi_p (void);
> > +extern bool darwin_unreachable_traps_p (void);
> > extern void darwin_override_options (void);
> > extern void darwin_patch_builtins (void);
> > extern void darwin_rename_builtins (void);
> > diff --git a/gcc/config/darwin.cc b/gcc/config/darwin.cc
> > index dcfccb4952a..018547d09c6 100644
> > --- a/gcc/config/darwin.cc
> > +++ b/gcc/config/darwin.cc
> > @@ -3339,6 +3339,13 @@ darwin_kextabi_p (void) {
> >   return flag_apple_kext;
> > }
> >
> > +/* True, iff we want to map __builtin_unreachable to a trap.  */
> > +
> > +bool
> > +darwin_unreachable_traps_p (void) {
> > +  return darwin_unreachable_traps;
> > +}
> > +
> > void
> > darwin_override_options (void)
> > {
> > diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
> > index d335ffe7345..17f41cf30ef 100644
> > --- a/gcc/config/darwin.h
> > +++ b/gcc/config/darwin.h
> > @@ -1225,6 +1225,10 @@ void add_framework_path (char *);
> > 

Re: FE C++ requirement

[Jakub Jelinek via Gcc]

On Tue, May 07, 2024 at 04:40:55PM -0400, James K. Lowden wrote:
> /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not
> found (required by build-O2/gcc/cobol1

The cc1/cc1plus/f951/... binaries are normally linked with
-static-libstdc++ -static-libgcc in second and later stages (first
stage is linked against the host libstdc++, so not a problem, but
even that stage is often linked with it).
See e.g. --with-static-standard-libraries configure option in toplevel
configury.

Perhaps you don't link cobol1 with the correct make variables
as other FEs are linked?

I think it is $(LDFLAGS) that is needed:
grep ^LDFLAGS *gcc/Makefile
gcc/Makefile:LDFLAGS = -static-libstdc++ -static-libgcc  
prev-gcc/Makefile:LDFLAGS = -static-libstdc++ -static-libgcc  
stage1-gcc/Makefile:LDFLAGS = -static-libstdc++ -static-libgcc  
but better follow what other FEs do in Make-lang.in
E.g. the linking of the FE binaries need to be specially chained for
--enable-link-serialization
or
--enable-link-serialization=N
such that only N binaries are linked together, etc.
c++.serial = cc1plus$(exeext)
...
cc1plus$(exeext): $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(CODYLIB) 
$(LIBDEPS) $(c++.prev)
@$(call LINK_PROGRESS,$(INDEX.c++),start)
+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
  $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(CODYLIB) \
$(LIBS) $(BACKENDLIBS)
@$(call LINK_PROGRESS,$(INDEX.c++),end)
does that (the lang.serial line, $(lang.prev) dependency, the
LINK_PROGRESS.lang calls, using $(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) ...
$(BACKEND) $(BACKENDLIBS) $(LIBS) too.

Jakub

Results for 12.3.1 20240507 [remotes/origin/releases/gcc-12 r12-10433-g58d11bfc27] (GCC) testsuite on powerpc64-unknown-linux-gnu

[Bill Seurer (POWER9 BE) via Gcc-testresults]

git commit g:58d11bfc27d5412619c0919738158a4c05cca2cf
gcc-descr r12-10433-g58d11bfc27d541

power9 BE
Linux 6.7.12-powerpc64 ppc64
GNU Make 4.3

DejaGnu:
DejaGnu version 1.6.3
Expect version  5.45.4
Tcl version 8.6

64-bit

LAST_UPDATED: Wed May  8 18:35:36 UTC 2024 (revision r12-10433-g58d11bfc27)

Native configuration is powerpc64-unknown-linux-gnu

=== g++ tests ===


Running target unix/-m32

=== g++ Summary for unix/-m32 ===

# of expected passes219482
# of expected failures  1922
# of unsupported tests  10357

Running target unix/-m64

=== g++ Summary for unix/-m64 ===

# of expected passes228227
# of expected failures  1930
# of unsupported tests  10541

=== g++ Summary ===

# of expected passes447709
# of expected failures  3852
# of unsupported tests  20898
/home/gccbuild/build/nightly/build-gcc-12/gcc/xg++  version 12.3.1 20240507 
[remotes/origin/releases/gcc-12 r12-10433-g58d11bfc27] (GCC) 

=== gcc tests ===


Running target unix/-m32
XPASS: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26)
FAIL: gcc.dg/torture/pr52451.c   -O0  execution test
FAIL: gcc.dg/torture/pr52451.c   -O1  execution test
FAIL: gcc.dg/torture/pr52451.c   -O2  execution test
FAIL: gcc.dg/torture/pr52451.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr52451.c   -Os  execution test
FAIL: gcc.dg/torture/pr52451.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  execution test
FAIL: gcc.dg/torture/pr52451.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/pr91323.c   -O0  execution test
FAIL: gcc.dg/torture/pr91323.c   -O1  execution test
FAIL: gcc.dg/torture/pr91323.c   -O2  execution test
FAIL: gcc.dg/torture/pr91323.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr91323.c   -Os  execution test
FAIL: gcc.dg/torture/pr91323.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  execution test
FAIL: gcc.dg/torture/pr91323.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
XPASS: gcc.dg/vect/slp-24-big-array.c -flto -ffat-lto-objects  
scan-tree-dump-times vect "vectorized 1 loops" 1
XPASS: gcc.dg/vect/slp-24-big-array.c -flto -ffat-lto-objects  
scan-tree-dump-times vect "vectorizing stmts using SLP" 2
XPASS: gcc.dg/vect/slp-24-big-array.c scan-tree-dump-times vect "vectorized 1 
loops" 1
XPASS: gcc.dg/vect/slp-24-big-array.c scan-tree-dump-times vect "vectorizing 
stmts using SLP" 2
XPASS: gcc.dg/vect/slp-24.c -flto -ffat-lto-objects  scan-tree-dump-times vect 
"vectorized 1 loops" 1
XPASS: gcc.dg/vect/slp-24.c -flto -ffat-lto-objects  scan-tree-dump-times vect 
"vectorizing stmts using SLP" 2
XPASS: gcc.dg/vect/slp-24.c scan-tree-dump-times vect "vectorized 1 loops" 1
XPASS: gcc.dg/vect/slp-24.c scan-tree-dump-times vect "vectorizing stmts using 
SLP" 2
FAIL: gcc.target/powerpc/bfp/scalar-test-data-class-12.c (test for excess 
errors)
UNRESOLVED: gcc.target/powerpc/bfp/scalar-test-data-class-12.c compilation 
failed to produce executable
FAIL: gcc.target/powerpc/bfp/scalar-test-data-class-14.c (test for excess 
errors)
UNRESOLVED: gcc.target/powerpc/bfp/scalar-test-data-class-14.c compilation 
failed to produce executable
FAIL: gcc.target/powerpc/bfp/scalar-test-data-class-15.c (test for excess 
errors)
UNRESOLVED: gcc.target/powerpc/bfp/scalar-test-data-class-15.c compilation 
failed to produce executable
FAIL: gcc.target/powerpc/bfp/scalar-test-neg-8.c (test for excess errors)
UNRESOLVED: gcc.target/powerpc/bfp/scalar-test-neg-8.c compilation failed to 
produce executable
FAIL: gcc.target/powerpc/bfp/vec-test-data-class-9.c (test for excess errors)
UNRESOLVED: gcc.target/powerpc/bfp/vec-test-data-class-9.c compilation failed 
to produce executable
FAIL: gcc.target/powerpc/fold-vec-extract-char.p7.c scan-assembler-times 
maddiM 9
FAIL: gcc.target/powerpc/fold-vec-extract-double.p7.c scan-assembler-times 
maddiM|maddM 3
FAIL: gcc.target/powerpc/fold-vec-extract-float.p7.c scan-assembler-times 
maddiM|maddM 3
FAIL: gcc.target/powerpc/fold-vec-extract-float.p8.c scan-assembler-times 
maddiM 2
FAIL: gcc.target/powerpc/fold-vec-extract-int.p7.c scan-assembler-times 
maddiM|maddM 12
FAIL: gcc.target/powerpc/fold-vec-extract-int.p8.c scan-assembler-times 
maddiM 9
FAIL: gcc.target/powerpc/fold-vec-extract-short.p7.c scan-assembler-times 
maddiM|maddM 12
FAIL: gcc.target/powerpc/fold-vec-extract-short.p8.c scan-assembler-times 
maddiM 9
FAIL: gcc.target/powerpc/pr101384-2.c scan-assembler-times mvspltis[whb] 
[^nr]*,-1M 9
FAIL: gcc.target/powerpc/rs6000-fpint.c scan-assembler-not stfiwx
XPASS: gcc.target/powerpc/ppc-fortran/ieee128-math.f90   -O  (test for excess 
errors)

=== gcc Summary for unix/-m32 ===

# of 

Results for 15.0.0 20240507 (experimental) [master r15-308-gc9dd853680b12d] (GCC) testsuite on m68k-unknown-linux-gnu

[Andreas Schwab]

]*, 4, 0, 0);" 1
FAIL: c-c++-common/gomp/atomic-28.c  -std=c++20  scan-tree-dump-times ompexp 
".ATOMIC_COMPARE_EXCHANGE ([^\\n\\r]*, 4, 5, 5);" 1
FAIL: c-c++-common/gomp/atomic-28.c  -std=c++20  scan-tree-dump-times ompexp 
".ATOMIC_COMPARE_EXCHANGE ([^\\n\\r]*, 4, 4, 2);" 1
FAIL: c-c++-common/gomp/atomic-28.c  -std=c++20  scan-tree-dump-times ompexp 
".ATOMIC_COMPARE_EXCHANGE ([^\\n\\r]*, 260, 5, 0);" 1
FAIL: c-c++-common/gomp/atomic-28.c  -std=c++20  scan-tree-dump-times ompexp 
".ATOMIC_COMPARE_EXCHANGE ([^\\n\\r]*, 4, 0, 0);" 1
FAIL: c-c++-common/gomp/atomic-3.c  -std=gnu++98  scan-tree-dump-times ompexp 
"xyzzy, 4" 1
FAIL: c-c++-common/gomp/atomic-3.c  -std=gnu++14  scan-tree-dump-times ompexp 
"xyzzy, 4" 1
FAIL: c-c++-common/gomp/atomic-3.c  -std=gnu++17  scan-tree-dump-times ompexp 
"xyzzy, 4" 1
FAIL: c-c++-common/gomp/atomic-3.c  -std=gnu++20  scan-tree-dump-times ompexp 
"xyzzy, 4" 1
FAIL: c-c++-common/gomp/atomic-9.c  -std=gnu++98  scan-tree-dump-times ompexp 
"__atomic_fetch_add" 1
FAIL: c-c++-common/gomp/atomic-9.c  -std=gnu++14  scan-tree-dump-times ompexp 
"__atomic_fetch_add" 1
FAIL: c-c++-common/gomp/atomic-9.c  -std=gnu++17  scan-tree-dump-times ompexp 
"__atomic_fetch_add" 1
FAIL: c-c++-common/gomp/atomic-9.c  -std=gnu++20  scan-tree-dump-times ompexp 
"__atomic_fetch_add" 1

=== g++ Summary ===

# of expected passes248371
# of unexpected failures113
# of expected failures  2602
# of unsupported tests  11590
/daten/aranym/gcc/gcc-20240508/Build/gcc/xg++  version 15.0.0 20240507 
(experimental) [master r15-308-gc9dd853680b12d] (GCC) 

Host   is x86_64-suse-linux-gnu

=== gcc tests ===


Running target aranym
FAIL: gcc.c-torture/execute/pr97073.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O0  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O1  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O2  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O3 -g  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -Os  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/debug/btf/btf-bitfields-1.c scan-assembler-times [\\t 
]0x1340[\\t ]+[^\\n]*btm_offset 1
FAIL: gcc.dg/Warray-bounds-48-novec.c (test for excess errors)
FAIL: gcc.dg/Wcomplain-wrong-lang-1.c  at line 2 (test for warnings, line )
FAIL: gcc.dg/Wcomplain-wrong-lang-1.c (test for excess errors)
FAIL: gcc.dg/Wcomplain-wrong-lang-2.c  at line 2 (test for warnings, line )
FAIL: gcc.dg/Wcomplain-wrong-lang-2.c (test for excess errors)
FAIL: gcc.dg/Werror-13.c  at line 5 (test for errors, line )
FAIL: gcc.dg/Werror-13.c  at line 6 (test for errors, line )
FAIL: gcc.dg/Werror-13.c  at line 7 (test for errors, line )
FAIL: gcc.dg/Werror-13.c  at line 8 (test for errors, line )
FAIL: gcc.dg/Werror-13.c (test for excess errors)
FAIL: gcc.dg/builtin-object-size-20.c scan-tree-dump-not optimized "fail"
FAIL: gcc.dg/ifcvt-4.c scan-rtl-dump ce1 "2 true changes made"
FAIL: gcc.dg/loop-9.c scan-rtl-dump loop2_invariant "Decided"
FAIL: gcc.dg/loop-9.c scan-rtl-dump loop2_invariant "without introducing a new 
temporary register"
FAIL: gcc.dg/memcmp-3.c (test for excess errors)
UNRESOLVED: gcc.dg/memcmp-3.c scan-tree-dump-not optimized "abort"
FAIL: gcc.dg/pr110279-1.c scan-tree-dump-times widening_mul "Generated FMA" 3
FAIL: gcc.dg/pr46647.c scan-tree-dump-not optimized "memset"
FAIL: gcc.dg/pr84877.c execution test
FAIL: gcc.dg/pr87954.c scan-tree-dump-times optimized " *w? 
|WIDEN_MULT_PLUS_EXPR" 1
FAIL: gcc.dg/pr91172.c  at line 3 (test for warnings, line )
FAIL: gcc.dg/pr91172.c (test for excess errors)
UNRESOLVED: gcc.dg/superblock.c scan-rtl-dump-times sched2 "ADVANCING TO" 2
FAIL: c-c++-common/auto-init-7.c  -Wc++-compat   scan-tree-dump gimple "temp4 = 
.DEFERRED_INIT ((8|5), 2, &"temp4""
FAIL: c-c++-common/auto-init-8.c  -Wc++-compat   scan-tree-dump gimple "temp4 = 
.DEFERRED_INIT ((8|5), 1, &"temp4""
FAIL: c-c++-common/pr51628-3.c  -Wc++-compat   at line 16 (test for warnings, 
line 15)
FAIL: c-c++-common/pr51628-3.c  -Wc++-compat   at line 24 (test for warnings, 
line 23)
FAIL: c-c++-common/pr51628-3.c  -Wc++-compat   at line 27 (test for warnings, 
line 26)
FAIL: c-c++-common/pr51628-3.c  -Wc++-compat   at line 30 (test for warnings, 
line 

Ping [PATCH/RFC] target, hooks: Allow a target to trap on unreachable [PR109267].

[Iain Sandoe]

Hi Folks,

I’d like to land a viable solution to this issue if possible, (it is a show-
stopper for the aarch64-darwin development branch).

> On 9 Apr 2024, at 14:55, Iain Sandoe  wrote:
> 
> So far, tested lightly on aarch64-darwin; if this is acceptable then
> it will be possible to back out of the ad hoc fixes used on x86 and
> powerpc darwin.
> Comments welcome, thanks,

@Andrew - you were also (at one stage) talking about some ideas about
how to handle this is in the middle end.
Is that something you are likely to have time to do?
Would it still be reasonable to have a target hook to control the behaviour.
(the implementation below allows one to make the effect per TU)


> Iain
> 
> --- 8< ---
> 
> 
> In the PR cited case a target linker cannot handle enpty FDEs,
> arguably this is a linker bug - but in some cases we might still
> wish to work around it.
> 
> In the case of Darwin, the ABI does not allow two global symbols
> to have the same address, so that emitting empty functions has
> potential (almost guarantee) to break ABI.
> 
> This patch allows a target to ask that __builtin_unreachable is
> expanded in the same way as __builtin_trap (either to a trap
> instruction or to abort() if there is no such insn).
> 
> This means that the middle end's use of unreachability for
> optimisation should not be altered.
> 
> __builtin_unreachble is currently expanded to a barrier and
> __builtin_trap is expanded to a trap insn + a barrier so that it
> seems we should not be unduly affecting RTL optimisations.
> 
> For Darwin, we enable this by default, but allow it to be disabled
> per TU using -mno-unreachable-traps.
> 
>   PR middle-end/109267
> 
> gcc/ChangeLog:
> 
>   * builtins.cc (expand_builtin_unreachable): Allow for
>   a target to expand this as a trap.
>   * config/darwin-protos.h (darwin_unreachable_traps_p): New.
>   * config/darwin.cc (darwin_unreachable_traps_p): New.
>   * config/darwin.h (TARGET_UNREACHABLE_SHOULD_TRAP): New.
>   * config/darwin.opt (munreachable-traps): New.
>   * doc/invoke.texi: Document -munreachable-traps.
>   * doc/tm.texi: Regenerate.
>   * doc/tm.texi.in: Document TARGET_UNREACHABLE_SHOULD_TRAP.
>   * target.def (TARGET_UNREACHABLE_SHOULD_TRAP): New hook.
> 
> Signed-off-by: Iain Sandoe 
> ---
> gcc/builtins.cc|  7 +++
> gcc/config/darwin-protos.h |  1 +
> gcc/config/darwin.cc   |  7 +++
> gcc/config/darwin.h|  4 
> gcc/config/darwin.opt  |  4 
> gcc/doc/invoke.texi|  7 ++-
> gcc/doc/tm.texi|  5 +
> gcc/doc/tm.texi.in |  2 ++
> gcc/target.def | 10 ++
> 9 files changed, 46 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/builtins.cc b/gcc/builtins.cc
> index f8d94c4b435..13f321b6be6 100644
> --- a/gcc/builtins.cc
> +++ b/gcc/builtins.cc
> @@ -5929,6 +5929,13 @@ expand_builtin_trap (void)
> static void
> expand_builtin_unreachable (void)
> {
> +  /* If the target wants a trap in place of the fall-through, use that.  */
> +  if (targetm.unreachable_should_trap ())
> +{
> +  expand_builtin_trap ();
> +  return;
> +}
> +
>   /* Use gimple_build_builtin_unreachable or builtin_decl_unreachable
>  to avoid this.  */
>   gcc_checking_assert (!sanitize_flags_p (SANITIZE_UNREACHABLE));
> diff --git a/gcc/config/darwin-protos.h b/gcc/config/darwin-protos.h
> index b67e05264e1..48a32b2ccc2 100644
> --- a/gcc/config/darwin-protos.h
> +++ b/gcc/config/darwin-protos.h
> @@ -124,6 +124,7 @@ extern void darwin_enter_string_into_cfstring_table 
> (tree);
> extern void darwin_asm_output_anchor (rtx symbol);
> extern bool darwin_use_anchors_for_symbol_p (const_rtx symbol);
> extern bool darwin_kextabi_p (void);
> +extern bool darwin_unreachable_traps_p (void);
> extern void darwin_override_options (void);
> extern void darwin_patch_builtins (void);
> extern void darwin_rename_builtins (void);
> diff --git a/gcc/config/darwin.cc b/gcc/config/darwin.cc
> index dcfccb4952a..018547d09c6 100644
> --- a/gcc/config/darwin.cc
> +++ b/gcc/config/darwin.cc
> @@ -3339,6 +3339,13 @@ darwin_kextabi_p (void) {
>   return flag_apple_kext;
> }
> 
> +/* True, iff we want to map __builtin_unreachable to a trap.  */
> +
> +bool
> +darwin_unreachable_traps_p (void) {
> +  return darwin_unreachable_traps;
> +}
> +
> void
> darwin_override_options (void)
> {
> diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
> index d335ffe7345..17f41cf30ef 100644
> --- a/gcc/config/darwin.h
> +++ b/gcc/config/darwin.h
> @@ -1225,6 +1225,10 @@ void add_framework_path (char *);
> #define TARGET_N_FORMAT_TYPES 1
> #define TARGET_FORMAT_TYPES darwin_additional_format_types
> 
> +/* We want __builtin_unreachable to be expanded as a trap instruction.  */
> +#undef TARGET_UNREACHABLE_SHOULD_TRAP
> +#define TARGET_UNREACHABLE_SHOULD_TRAP darwin_unreachable_traps_p
> +
> #ifndef USED_FOR_TARGET
> extern void darwin_driver_init (unsigned int *,struct 

[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=56512
 Resolution|--- |INVALID

--- Comment #27 from Andrew Pinski  ---
https://pubs.opengroup.org/onlinepubs/7908799/xsh/longjmp.html


The requirement of using volatile has been there a long time before your code
was written ...