[Bug c/115502] [15 regression] ICE when building Valgrind with -std=c23 (comptypes_same_p, at c/c-typeck.cc:1227) since r15-934-gd2cfe8a73b3c41

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

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

Sam James  changed:

   What|Removed |Added

 Depends on||114930

--- Comment #6 from Sam James  ---
Ah, thanks!


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114930
[Bug 114930] [14/15 regression] ICE in fld_incomplete_type_of when building
libwebp with -std=c23 -flto

[Bug c/115502] [15 regression] ICE when building Valgrind with -std=c23 (comptypes_same_p, at c/c-typeck.cc:1227) since r15-934-gd2cfe8a73b3c41

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

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

--- Comment #5 from uecker at gcc dot gnu.org ---

Ah right, thank you!  This I where the front end checking was added. Makes
sense now. So I think this is a dup of PR114930, but not detected by the FE.

[Bug c/115502] [15 regression] ICE when building Valgrind with -std=c23 (comptypes_same_p, at c/c-typeck.cc:1227) since r15-934-gd2cfe8a73b3c41

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

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

--- Comment #4 from Sam James  ---
It bisected to that commit.

[Bug c/115502] [15 regression] ICE when building Valgrind with -std=c23 (comptypes_same_p, at c/c-typeck.cc:1227) since r15-934-gd2cfe8a73b3c41

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

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

--- Comment #3 from uecker at gcc dot gnu.org ---

How is this commit related?

This seems more likely to be the same issue as PR114930.

[Bug c/115502] [15 regression] ICE when building Valgrind with -std=c23 (comptypes_same_p, at c/c-typeck.cc:1227) since r15-934-gd2cfe8a73b3c41

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

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

Sam James  changed:

   What|Removed |Added

Summary|[15 regression] ICE when|[15 regression] ICE when
   |building Valgrind with  |building Valgrind with
   |-std=c23 (comptypes_same_p, |-std=c23 (comptypes_same_p,
   |at c/c-typeck.cc:1227)  |at c/c-typeck.cc:1227)
   ||since
   ||r15-934-gd2cfe8a73b3c41
 CC||uecker at gcc dot gnu.org

--- Comment #2 from Sam James  ---
r15-934-gd2cfe8a73b3c41

[Bug target/111376] missed optimization of one bit test on MIPS32r1

[lis8215 at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Siarhei Volkau  ---
Highly likely it's because of data dependency, and not direct cost of shift
operations on LoongArch, although can't find information to prove that.
So, I guess it still might get performance benefit in cases where scheduler can
put some instruction(s) between SLL and BGEZ.

Since you have access to hardware you can  measure performace of two variants:
1) SLL+BGEZ
2) SLL+NOT+BGEZ
if their performance is equal then I'm correct and scheduling automaton for
GS464 seems have to be fixed.

>From my side I can confirm that SLL+BGEZ is faster than LUI+AND+BEQ on Ingenic
XBurst 1 cores.

Re: [PATCH 06/52] m2: Replace uses of {FLOAT, {, LONG_}DOUBLE}_TYPE_SIZE

[Gaius Mulley]

"Kewen.Lin"  writes:

> Hi Gaius,
>
>>>  static tree
>>>  build_m2_short_real_node (void)
>>>  {
>>> -  tree c;
>>> -
>>> -  /* Define `REAL'.  */
>>> -
>>> -  c = make_node (REAL_TYPE);
>>> -  TYPE_PRECISION (c) = FLOAT_TYPE_SIZE;
>>> -  layout_type (c);
>>> -  return c;
>>> +  /* Define `SHORTREAL'.  */
>>> +  layout_type (float_type_node);
>> 
>> It looks that float_type_node, double_type_node, float128_type_node and
>> long_double_type_node have been called with layout_type when they are
>> being initialized in function build_common_tree_nodes, maybe we can just
>> assert their TYPE_SIZE.
>
> I just noticed that latest trunk still has {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE
> in gcc/m2 and realized that my comment above was misleading, sorry about that.
> It meant TYPE_SIZE (float_type_node) etc. instead of 
> {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE,
> as this patch series would like to get rid of 
> {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE.
>
> I adjusted them as below patch, does this look good to you?

Hi Kewen,

ah yes indeed, lgtm,

regards,
Gaius

>
> BR,
> Kewen
> -
>
> [PATCH] m2: Remove uses of {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE
>
> Joseph pointed out "floating types should have their mode,
> not a poorly defined precision value" in the discussion[1],
> as he and Richi suggested, the existing macros
> {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE will be replaced with a
> hook mode_for_floating_type.  To be prepared for that, this
> patch is to remove uses of {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE
> in m2.  Currently they are used for assertion and can be
> replaced with TYPE_SIZE check on the corresponding type node,
> since we dropped the call to layout_type which would early
> return once TYPE_SIZE is set and this assertion ensures it's
> safe to drop that call.
>
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651209.html
>
> gcc/m2/ChangeLog:
>
>   * gm2-gcc/m2type.cc (build_m2_short_real_node): Adjust assertion with
>   TYPE_SIZE check.
>   (build_m2_real_node): Likewise.
>   (build_m2_long_real_node): Add assertion with TYPE_SIZE check.
> ---
>  gcc/m2/gm2-gcc/m2type.cc | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/m2/gm2-gcc/m2type.cc b/gcc/m2/gm2-gcc/m2type.cc
> index 5773a5cbd19..7ed184518cb 100644
> --- a/gcc/m2/gm2-gcc/m2type.cc
> +++ b/gcc/m2/gm2-gcc/m2type.cc
> @@ -1416,7 +1416,7 @@ static tree
>  build_m2_short_real_node (void)
>  {
>/* Define `SHORTREAL'.  */
> -  ASSERT_CONDITION (TYPE_PRECISION (float_type_node) == FLOAT_TYPE_SIZE);
> +  ASSERT_CONDITION (TYPE_SIZE (float_type_node));
>return float_type_node;
>  }
>
> @@ -1424,7 +1424,7 @@ static tree
>  build_m2_real_node (void)
>  {
>/* Define `REAL'.  */
> -  ASSERT_CONDITION (TYPE_PRECISION (double_type_node) == DOUBLE_TYPE_SIZE);
> +  ASSERT_CONDITION (TYPE_SIZE (double_type_node));
>return double_type_node;
>  }
>
> @@ -1432,12 +1432,13 @@ static tree
>  build_m2_long_real_node (void)
>  {
>tree longreal;
> -
> +
>/* Define `LONGREAL'.  */
>if (M2Options_GetIEEELongDouble ())
>  longreal = float128_type_node;
>else
>  longreal = long_double_type_node;
> +  ASSERT_CONDITION (TYPE_SIZE (longreal));
>return longreal;
>  }
>
> --
> 2.43.0

[Bug c++/115501] [13/14/15 Regression] ICE: in build_call_a with dynamic_cast after invalid definition of __cxxabiv1::__dynamic_cast

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Andrew Pinski  ---
Most likely r13-3299-gd6a488f243acfa .

[Bug c++/115501] [13/14/15 Regression] ICE: in build_call_a with dynamic_cast after invalid definition of __cxxabiv1::__dynamic_cast

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Confirmed. The ICE started in GCC 13.

Before it was accepted.

[Bug c++/115501] [13/14/15 Regression] ICE: in build_call_a with dynamic_cast after invalid definition of __cxxabiv1::__dynamic_cast

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-15
   Target Milestone|--- |13.4
Summary|ICE: in build_call_a, at|[13/14/15 Regression] ICE:
   |cp/call.cc:370  |in build_call_a with
   ||dynamic_cast after invalid
   ||definition of
   ||__cxxabiv1::__dynamic_cast
   Keywords||needs-bisection
  Known to fail||13.1.0

--- Comment #2 from Andrew Pinski  ---
Confirmed. The ICE started in GCC 13.

[Bug c++/115501] ICE: in build_call_a, at cp/call.cc:370

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
struct s{virtual void f();};
struct s1 : s{};
namespace __cxxabiv1
{
  extern "C" void __dynamic_cast();
}
void diagnostic_information_impl(s const *se)
{
  dynamic_cast(se);
}
```

Re: [PATCH v1] RISC-V: Refine the SAT_ARITH test help header files [NFC]

[钟居哲]

LGTM



juzhe.zh...@rivai.ai
 
From: pan2.li
Date: 2024-06-15 10:44
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Refine the SAT_ARITH test help header files [NFC]
From: Pan Li 
 
Separate the vector part code to one standalone header file,  which
is independent with the scalar part.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-1.c: Leverage
the new header file for vector part.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-4.c: Ditto.
* gcc.target/riscv/sat_arith.h: Move vector part out.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h: New test.
 
Signed-off-by: Pan Li 
---
.../riscv/rvv/autovec/binop/vec_sat_arith.h   | 59 +++
.../riscv/rvv/autovec/binop/vec_sat_u_add-1.c |  2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_add-2.c |  2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_add-3.c |  2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_add-4.c |  2 +-
.../rvv/autovec/binop/vec_sat_u_add-run-1.c   |  2 +-
.../rvv/autovec/binop/vec_sat_u_add-run-2.c   |  2 +-
.../rvv/autovec/binop/vec_sat_u_add-run-3.c   |  2 +-
.../rvv/autovec/binop/vec_sat_u_add-run-4.c   |  2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_sub-1.c |  2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_sub-2.c |  2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_sub-3.c |  2 +-
.../riscv/rvv/autovec/binop/vec_sat_u_sub-4.c |  2 +-
.../rvv/autovec/binop/vec_sat_u_sub-run-1.c   |  2 +-
.../rvv/autovec/binop/vec_sat_u_sub-run-2.c   |  2 +-
.../rvv/autovec/binop/vec_sat_u_sub-run-3.c   |  2 +-
.../rvv/autovec/binop/vec_sat_u_sub-run-4.c   |  2 +-
gcc/testsuite/gcc.target/riscv/sat_arith.h| 57 ++
18 files changed, 80 insertions(+), 68 deletions(-)
create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h
 
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h
new file mode 100644
index 000..450f0fbbc72
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h
@@ -0,0 +1,59 @@
+#ifndef HAVE_VEC_SAT_ARITH
+#define HAVE_VEC_SAT_ARITH
+
+#include 
+
+/**/
+/* Saturation Add (unsigned and signed)   
*/
+/**/
+#define DEF_VEC_SAT_U_ADD_FMT_1(T)   \
+void __attribute__((noinline))   \
+vec_sat_u_add_##T##_fmt_1 (T *out, T *op_1, T *op_2, unsigned limit) \
+{\
+  unsigned i;\
+  for (i = 0; i < limit; i++)\
+{\
+  T x = op_1[i]; \
+  T y = op_2[i]; \
+  out[i] = (x + y) | (-(T)((T)(x + y) < x)); \
+}\
+}
+
+#define RUN_VEC_SAT_U_ADD_FMT_1(T, out, op_1, op_2, N) \
+  vec_sat_u_add_##T##_fmt_1(out, op_1, op_2, N)
+
+/**/
+/* Saturation Sub (Unsigned and Signed)   
*/
+/**/
+#define DEF_VEC_SAT_U_SUB_FMT_1(T)   \
+void __attribute__((noinline))   \
+vec_sat_u_sub_##T##_fmt_1 (T *out, T *op_1, T *op_2, unsigned limit) \
+{\
+  unsigned i;\
+  for (i = 0; i < limit; i++)\
+{

[Bug c/115502] [15 regression] ICE when building Valgrind with -std=c23 (comptypes_same_p, at c/c-typeck.cc:1227)

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

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

--- Comment #1 from Sam James  ---
```
typedef struct _OSet OSet;
typedef OSet AvlTree;
void vgPlain_OSetGen_Lookup(const OSet *);
struct _OSet {};
void vgPlain_OSetGen_Lookup(const AvlTree *);
```

[Bug c/115502] New: [15 regression] ICE when building Valgrind with -std=c23 (comptypes_same_p, at c/c-typeck.cc:1227)

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

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

Bug ID: 115502
   Summary: [15 regression] ICE when building Valgrind with
-std=c23 (comptypes_same_p, at c/c-typeck.cc:1227)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58436
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58436=edit
libcoregrind_amd64_linux_a-m_oset.i.xz

```
$ gcc -c libcoregrind_amd64_linux_a-m_oset.i -std=c23
m_oset.c:340:1: internal compiler error: in comptypes_same_p, at
c/c-typeck.cc:1227
0x5556e69b42c6 comptypes_same_p(tree_node*, tree_node*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c/c-typeck.cc:1227
0x5556e5d63467 composite_type_internal(tree_node*, tree_node*,
composite_cache*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c/c-typeck.cc:519
0x5556e5d6278a composite_type_internal(tree_node*, tree_node*,
composite_cache*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c/c-typeck.cc:439
0x5556e74e9484 composite_type_internal(tree_node*, tree_node*,
composite_cache*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c/c-typeck.cc:736
0x5556e7c0f60b composite_type(tree_node*, tree_node*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c/c-typeck.cc:754
0x5556e7c0c2b4 merge_decls
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c/c-decl.cc:2798
0x5556e7c0c2b4 duplicate_decls
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c/c-decl.cc:3185
0x5556e7424539 pushdecl(tree_node*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c/c-decl.cc:3374
0x5556e7be27d6 start_function(c_declspecs*, c_declarator*, tree_node*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c/c-decl.cc:10753
0x5556e7bdd88d c_parser_declaration_or_fndef
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c/c-parser.cc:2919
0x5556e7bdd1af c_parser_external_declaration
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c/c-parser.cc:2053
0x5556e7bd9fba c_parser_translation_unit
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c/c-parser.cc:1907
0x5556e7bd9fba c_parse_file()
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c/c-parser.cc:27303
0x5556e7bcec24 c_common_parse_file()
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c-family/c-opts.cc:1322
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
```

```
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
15.0. p, commit c8bf41759fe849050fcb5c5105483c9db6b15da2'
--with-gcc-major-version-only --enable-libstdcxx-time --enable-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --disable-cet
--disable-systemtap --enable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --with-isl --disable-isl-version-check
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --disable-fixincludes --with-build-config='bootstrap-O3
bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240614 (experimental)
1bb2535c7cb279e6aab731e79080d8486dd50cce (Gentoo Hardened 15.0. p, commit
c8bf41759fe849050fcb5c5105483c9db6b15da2)
```

[Bug c/115501] New: ICE: in build_call_a, at cp/call.cc:370

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 115501
   Summary: ICE: in build_call_a, at cp/call.cc:370
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---
Target: x86_64

***
The compiler produces an internal error when compiling the provided code with
the specified options. 
The issue can also be reproduced on Compiler Explorer.

***
OS and Platform:
# uname -a
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/root/gdbtest/gcc/gcc-15/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /root/gdbtest/gcc/obj/../gcc/configure
--prefix=/root/gdbtest/gcc/gcc-15 --enable-languages=c,c++,fortran,go
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240509 (experimental) (GCC) 
***
Program:
# 2.ii

namespace std
{
  class exception
  {
virtual ~exception() throw();
  };
}
namespace std __attribute__((__visibility__("default")))
{
  template , typename
_Alloc = allocator<_CharT>>
  class basic_string;
  typedef basic_string string;
}
namespace boost
{
  class exception
  {
  };
}
namespace __cxxabiv1
{
  extern "C" void *__dynamic_cast(const void *__src_ptr, const
__class_type_info *__src_type, const __class_type_info *__dst_type, ptrdiff_t
__src2dst);
  inline std::string diagnostic_information_impl(boost::exception const *be,
std::exception const *se, bool with_what)
  {
if (!be)
  be = dynamic_cast(se);
  }
}

***
Command Lines:
# g++ 2.ii  -std=c++17 -O2 -Wall -Wextra -pedantic -Wshadow -Wnon-virtual-dtor
-Wold-style-cast -Wcast-align -Woverloaded-virtual -Wconversion
-Wsign-conversion -Wmisleading-indentation -Wduplicated-cond
-Wduplicated-branches -Wlogical-op -Wnull-dereference -Wuseless-cast
-Wdouble-promotion -Wformat=2 -Wnoexcept -fstack-protector-strong
-D_GLIBCXX_ASSERTIONS -fvisibility=hidden -fvisibility-inlines-hidden -o -c 2.o
2.ii:10:49: error: ‘char_traits’ does not name a type
   10 |   template ,
typename _Alloc = allocator<_CharT>>
  | ^~~
2.ii:10:60: error: expected ‘>’ before ‘<’ token
   10 |   template ,
typename _Alloc = allocator<_CharT>>
  |^
2.ii:12:28: error: template argument 2 is invalid
   12 |   typedef basic_string string;
  |^
2.ii:22:64: error: ‘__class_type_info’ does not name a type
   22 |   extern "C" void *__dynamic_cast(const void *__src_ptr, const
__class_type_info *__src_type, const __class_type_info *__dst_type, ptrdiff_t
__src2dst);
  |   
^
2.ii:22:101: error: ‘__class_type_info’ does not name a type
   22 |   extern "C" void *__dynamic_cast(const void *__src_ptr, const
__class_type_info *__src_type, const __class_type_info *__dst_type, ptrdiff_t
__src2dst);
  |
^
2.ii:22:132: error: ‘ptrdiff_t’ has not been declared
   22 |   extern "C" void *__dynamic_cast(const void *__src_ptr, const
__class_type_info *__src_type, const __class_type_info *__dst_type, ptrdiff_t
__src2dst);
  |
   ^
: error: conflicting declaration of C function ‘void*
__cxxabiv1::__dynamic_cast(const void*, const __class_type_info*, const
__class_type_info*, long int)’
2.ii:22:20: note: previous declaration ‘void* __cxxabiv1::__dynamic_cast(const
void*, const int*, const int*, int)’
   22 |   extern "C" void *__dynamic_cast(const void *__src_ptr, const
__class_type_info *__src_type, const __class_type_info *__dst_type, ptrdiff_t
__src2dst);
  |^~
2.ii: In function ‘std::string __cxxabiv1::diagnostic_information_impl(const
boost::exception*, const std::exception*, bool)’:
2.ii:26:53: internal compiler error: in build_call_a, at cp/call.cc:370
   26 |   be = dynamic_cast(se);
  | ^
0x7958c9 build_call_a(tree_node*, int, tree_node**)

[Bug target/115500] RISC-V: Performance regression on 1bit test

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

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

--- Comment #3 from YunQiang Su  ---
(In reply to Andrew Pinski from comment #2)
> The big question is non zbs riscv arch matter any more?

I have no idea. This is the Debian's porterbox, so I guess it meets the
requirement of Debian's RV64 port baseline.

[Bug target/115500] RISC-V: Performance regression on 1bit test

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

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

--- Comment #2 from Andrew Pinski  ---
The big question is non zbs riscv arch matter any more?

[Bug target/115500] RISC-V: Performance regression on 1bit test

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

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

--- Comment #1 from YunQiang Su  ---
Talks about MIPS here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376

[Bug target/115500] New: RISC-V: Performance regression on 1bit test

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

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

Bug ID: 115500
   Summary: RISC-V: Performance regression on 1bit test
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: syq at gcc dot gnu.org
  Target Milestone: ---

```x.c
#include 

int f32(int);

int main() {
for(int i=0; i<1e9; i++) {
f32(i);
}
}
```

```f32.c
int f32(int x) {
if (x & 0x8)
return 100;
return 1000;
}
```

I test it on 
isa : rv64imafdc_zicntr_zicsr_zifencei_zihpm
mmu : sv39
uarch   : sifive,bullet0
mvendorid   : 0x489
marchid : 0x8007
mimpid  : 0x20181004
hart isa: rv64imafdc_zicntr_zicsr_zifencei_zihpm

With GCC12, the time cost is
   real0m7.140s
   user0m7.134s
   sys 0m0.005s

With GCC13, the time cost is
   real0m9.298s
   user0m9.291s
   sys 0m0.005s


The problem is about
   0:   814dsrlia0,a0,0x13
   2:   8905andia0,a0,1
   4:   e501bneza0,c <.L3>
vs 
   0:   02c51793sllia5,a0,0x2c
   4:   0007c563bltza5,e <.L3>

Results for 15.0.0 20240614 (experimental) [master r15-1347-ge5e341243bf] (GCC) testsuite on x86_64-pc-linux-gnu

[haochenj--- via Gcc-testresults]

ot; * 2" 1
FAIL: gcc.dg/vect/slp-perm-9.c -flto -ffat-lto-objects  scan-tree-dump-times 
vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-perm-9.c scan-tree-dump-times vect "vectorizing stmts 
using SLP" 1
XPASS: gcc.dg/vect/vect-reduc-in-order-1.c -flto -ffat-lto-objects execution 
test
XPASS: gcc.dg/vect/vect-reduc-in-order-1.c execution test
XPASS: gcc.dg/vect/vect-reduc-in-order-2.c -flto -ffat-lto-objects execution 
test
XPASS: gcc.dg/vect/vect-reduc-in-order-2.c execution test
XPASS: gcc.dg/vect/vect-reduc-in-order-3.c -flto -ffat-lto-objects execution 
test
XPASS: gcc.dg/vect/vect-reduc-in-order-3.c execution test
XPASS: gcc.dg/vect/vect-reduc-in-order-4.c -flto -ffat-lto-objects execution 
test
XPASS: gcc.dg/vect/vect-reduc-in-order-4.c execution test
FAIL: gcc.target/i386/avx512bw-vmovdqu16-1.c scan-assembler-times 
(?:vmovdqu16|vextracti128)[ t]+[^{\\n]*%ymm[0-9]+[^\\n]*)(?:\\n|[ 
t]+#) 1
FAIL: gcc.target/i386/avx512bw-vmovdqu16-1.c scan-assembler-times 
(?:vmovdqu16|vinserti128)[ t]+[^{\\n]*)[^\\n]*%ymm[0-9]+(?:\\n|[ 
t]+#) 1
FAIL: gcc.target/i386/avx512dq-pr88465.c scan-assembler-times kxnorb[ \\t] 1
FAIL: gcc.target/i386/avx512f-pr88465.c scan-assembler-times kxnorw[ \\t] 1
FAIL: gcc.target/i386/avx512fp16-13.c scan-assembler-times vmovdqu16[ 
t]*[^,]*,[^{\\n]*%xmm[0-9] 1
FAIL: gcc.target/i386/avx512fp16-13.c scan-assembler-times vmovdqu16[ 
t]*[^,]*,[^{\\n]*%ymm[0-9] 1
FAIL: gcc.target/i386/avx512fp16-13.c scan-assembler-times vmovdqu16[ 
t]*[^{\\n]*%xmm[0-9], *[^,]* 1
FAIL: gcc.target/i386/avx512fp16-13.c scan-assembler-times vmovdqu16[ 
t]*[^{\\n]*%ymm[0-9], *[^,]* 1
XPASS: gcc.target/i386/bitwise_mask_op-3.c scan-assembler-times kmovb[\\t ] 4
XPASS: gcc.target/i386/bitwise_mask_op-3.c scan-assembler-times korb[\\t ] 1
XPASS: gcc.target/i386/bitwise_mask_op-3.c scan-assembler-times kxorb[\\t ] 1
FAIL: gcc.target/i386/minmax-10.c scan-assembler-not cmp
FAIL: gcc.target/i386/minmax-10.c scan-assembler-times test 6
FAIL: gcc.target/i386/pieces-memset-11.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-14.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-2.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-20.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-23.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-29.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-30.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-33.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-34.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-37.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-44.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-5.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pr31985.c scan-assembler-times movl 4
FAIL: gcc.target/i386/pr95483-5.c scan-assembler-times 
(?:vmovdqu8|vextracti128)[ t]+[^{\\n]*%ymm[0-9]+[^\\n]*)(?:\\n|[ 
t]+#) 1
FAIL: gcc.target/i386/pr95483-5.c scan-assembler-times 
(?:vmovdqu8|vinserti128)[ t]+[^{\\n]*)[^\\n]*%ymm[0-9]+(?:\\n|[ 
t]+#) 1
FAIL: gcc.target/i386/pr95483-6.c scan-assembler-times (?:vinserti128|vmovdqu)[ 
t]+[^{\\n]*)[^\\n]*%ymm[0-9]+(?:\\n|[ t]+#) 2
FAIL: gcc.target/i386/pr97873-1.c scan-assembler pabsq
FAIL: gcc.target/i386/vect-double-2.c scan-tree-dump-times vect "Vectorized 
loops: 1" 1
FAIL: gcc.target/i386/vect-shiftv4qi.c scan-assembler-times psrlw 5
FAIL: gcc.target/i386/vect-strided-3.c scan-assembler-times movq 4
FAIL: gcc.target/i386/xorsign.c scan-tree-dump-times vect "vectorized 2 loops" 1

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

# of expected passes198421
# of unexpected failures159
# of unexpected successes   30
# of expected failures  1551
# of unsupported tests  4098

=== gcc Summary ===

# of expected passes403214
# of unexpected failures318
# of unexpected successes   50
# of expected failures  3096
# of unsupported tests  7408
/export/home/haochenj/src/gcc-regression/bld/gcc/xgcc  version 15.0.0 20240614 
(experimental) [master r15-1347-ge5e341243bf] (GCC) 

=== gfortran tests ===


Running target unix

=== gfortran Summary for unix ===

# of expected passes70552
# of expected failures  273
# of unsupported tests  65

Running target unix/-m32

=== gfortran Summary for unix/-m32 ===

# of expected passes70206
# of expected failures  275
# of unsupp

[Bug target/111376] missed optimization of one bit test on MIPS32r1

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

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

YunQiang Su  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #11 from YunQiang Su  ---
For -Os, let's track it with this one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115473

[Bug target/111376] missed optimization of one bit test on MIPS32r1

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

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

--- Comment #10 from YunQiang Su  ---
I have some performance test.

sll+bgez is some slower than lui+and+beqz.
On Loongson 3A4000, it is about 10%.

So this "optimization" makes sense only for -Os.

[Bug target/115485] CASEServer.cpp:203:1: internal compiler error: in require_pic_register, at config/arm/arm.c:7855

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

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

--- Comment #7 from Andrew Pinski  ---
Created attachment 58435
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58435=edit
single file

[Bug target/115485] CASEServer.cpp:203:1: internal compiler error: in require_pic_register, at config/arm/arm.c:7855

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

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

--- Comment #6 from Andrew Pinski  ---
  if (!crtl->uses_pic_offset_table || compute_now)
{
  gcc_assert (can_create_pseudo_p ()
  || (pic_reg != NULL_RTX
  && REG_P (pic_reg)
  && GET_MODE (pic_reg) == Pmode));


It has to do with these 2 options:
>  -msingle-pic-base -mpic-register=r9

[Bug tree-optimization/115499] Missed optimization: Fold (a ^ (b || c)) && c to (a ^ 1) && c

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-15

--- Comment #1 from Andrew Pinski  ---
What happens is fold simplifies `(b || c)` into `!!b | !!c` too early. 

In fn1 jump threading and ifcombine (and phiopt) together provides:
  if (m.2_2 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  _11 = _1 != 1;
  _12 = c_9(D) != 0;
  _6 = _11 & _12;
  goto ; [100.00%]

   [local count: 536870912]:
  _3 = c_9(D) != 0;
  _13 = _1 != 1;
  _14 = _3 & _13;

   [local count: 1073741824]:
  # iftmp.0_5 = PHI <_14(4), _6(3)>
...

And then see that iftmp.0_5 is the same on both branches and removes the whole
branch.

In the other cases we have:
```
  _1 = (int) a_8(D);
  _2 = b_9(D) != 0;
  _3 = c_10(D) != 0;
  _4 = _2 | _3;
  _5 = (int) _4;
  _14 = _1 != _5;
  _15 = _3 & _14;
  _6 = (long long unsigned int) _15;
```
Or simplier: ((cast)((b != 0) | (c != 0)) != a) & (c != 0)

Or c & ((cast)(b | c) != a) which can be just folded into c & (1 != a).


So maybe something like:

(simplify
 (bit_and:c @0
  (cmp:c (convert (bit_ior:c @0 @1)) @2)
 (bit_and @0 (cmp { build_one_cst (TREE_TYPE (@2)); } @2)))


We also don't handle even simplier:
```
bool f(bool a, bool b, int d, int e)
{
  a = e != 0;
  return a & ((int)a != d);
}

bool f1(bool a, bool b, int d, int e)
{
  a = e != 0;
  return a & (1 != d);
}
```

Nor (clang/LLVM does not handle this one either):
```
bool f(bool a, bool b, int d, int e)
{
  return a & ((int)(a|b) != d);
}

bool f1(bool a, bool b, int d, int e)
{
  return a & (1 != d);
}
```

It can get even more complex if `(a|b)` is a much more complex expression.

Maybe this requires some pass to do this rather than a simple match and
simplify pattern.

[PATCH v1] RISC-V: Refine the SAT_ARITH test help header files [NFC]

[pan2 . li]

From: Pan Li 

Separate the vector part code to one standalone header file,  which
is independent with the scalar part.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-1.c: Leverage
the new header file for vector part.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-run-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-4.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub-run-4.c: Ditto.
* gcc.target/riscv/sat_arith.h: Move vector part out.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h: New test.

Signed-off-by: Pan Li 
---
 .../riscv/rvv/autovec/binop/vec_sat_arith.h   | 59 +++
 .../riscv/rvv/autovec/binop/vec_sat_u_add-1.c |  2 +-
 .../riscv/rvv/autovec/binop/vec_sat_u_add-2.c |  2 +-
 .../riscv/rvv/autovec/binop/vec_sat_u_add-3.c |  2 +-
 .../riscv/rvv/autovec/binop/vec_sat_u_add-4.c |  2 +-
 .../rvv/autovec/binop/vec_sat_u_add-run-1.c   |  2 +-
 .../rvv/autovec/binop/vec_sat_u_add-run-2.c   |  2 +-
 .../rvv/autovec/binop/vec_sat_u_add-run-3.c   |  2 +-
 .../rvv/autovec/binop/vec_sat_u_add-run-4.c   |  2 +-
 .../riscv/rvv/autovec/binop/vec_sat_u_sub-1.c |  2 +-
 .../riscv/rvv/autovec/binop/vec_sat_u_sub-2.c |  2 +-
 .../riscv/rvv/autovec/binop/vec_sat_u_sub-3.c |  2 +-
 .../riscv/rvv/autovec/binop/vec_sat_u_sub-4.c |  2 +-
 .../rvv/autovec/binop/vec_sat_u_sub-run-1.c   |  2 +-
 .../rvv/autovec/binop/vec_sat_u_sub-run-2.c   |  2 +-
 .../rvv/autovec/binop/vec_sat_u_sub-run-3.c   |  2 +-
 .../rvv/autovec/binop/vec_sat_u_sub-run-4.c   |  2 +-
 gcc/testsuite/gcc.target/riscv/sat_arith.h| 57 ++
 18 files changed, 80 insertions(+), 68 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h
new file mode 100644
index 000..450f0fbbc72
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vec_sat_arith.h
@@ -0,0 +1,59 @@
+#ifndef HAVE_VEC_SAT_ARITH
+#define HAVE_VEC_SAT_ARITH
+
+#include 
+
+/**/
+/* Saturation Add (unsigned and signed)   
*/
+/**/
+#define DEF_VEC_SAT_U_ADD_FMT_1(T)   \
+void __attribute__((noinline))   \
+vec_sat_u_add_##T##_fmt_1 (T *out, T *op_1, T *op_2, unsigned limit) \
+{\
+  unsigned i;\
+  for (i = 0; i < limit; i++)\
+{\
+  T x = op_1[i]; \
+  T y = op_2[i]; \
+  out[i] = (x + y) | (-(T)((T)(x + y) < x)); \
+}\
+}
+
+#define RUN_VEC_SAT_U_ADD_FMT_1(T, out, op_1, op_2, N) \
+  vec_sat_u_add_##T##_fmt_1(out, op_1, op_2, N)
+
+/**/
+/* Saturation Sub (Unsigned and Signed)   
*/
+/**/
+#define DEF_VEC_SAT_U_SUB_FMT_1(T)   \
+void __attribute__((noinline))   \
+vec_sat_u_sub_##T##_fmt_1 (T *out, T *op_1, T *op_2, unsigned limit) \
+{\
+  unsigned i;\
+  for (i = 0; i < limit; i++)\
+{\
+  T x = op_1[i];

[Bug c++/115499] New: Missed optimization: Fold (a ^ (b || c)) && c to (a ^ 1) && c

[zhiwuyazhe154 at gmail dot com via Gcc-bugs]

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

Bug ID: 115499
   Summary: Missed optimization: Fold (a ^ (b || c)) && c to (a ^
1) && c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhiwuyazhe154 at gmail dot com
  Target Milestone: ---

godbolt example: https://godbolt.org/z/bjPnrTP7o

Code example: 
```
#include 
unsigned long long int m, n;
void fn1(short a, unsigned long long int b, short c) {
n = (a ^ (m || c)) && c;
}

void fn2(short a, unsigned long long int b, short c) {
b = m;
n = (a ^ (b || c)) && c;
}

void fn3(short a, unsigned long long int b, short c) {
n = (a ^ (b || c)) && c;
}
```

In fact, these three functions are equivalent((a ^ 1) && c), but the processing
of the global variable m or the input parameter b by fn2 and fn3 leads to the
lack of arithmetic optimization.

[Bug c++/94162] ICE [neg] bad return type in defaulted <=>

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

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #16 from Sam James  ---
.

[Bug tree-optimization/114430] [11/12/13/14/15 regression] False positive for -Wformat-overflow

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-03-22
 Ever confirmed|0   |1
  Component|c   |tree-optimization
   Keywords||diagnostic

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
Summary|False positive for -Wformat |[11/12/13/14/15 regression]
   ||False positive for
   ||-Wformat-overflow

--- Comment #1 from Richard Biener  ---
Confirmed.  This is because we end up with

   [local count: 268435458]:
  __builtin_strcpy (, );
  __builtin_strcpy (,   [(void *) +
12B]);
  __builtin_strcpy (,   [(void *) +
24B]); [tail call]
  return;

First of all the laddress pass decomposes the [i_3].Name address.
Disabling that has FRE after cunroll replace [i_15].Name with
the above form.  That's because of how gimple_fold_stmt_to_constant_1
handles valueization of such ref.

This in the end confuses the diagnostic machinery.

Results for 15.0.0 20240614 (experimental) [master revision gcc-15-1347-ge5e341243bf] (GCC) testsuite on aarch64-unknown-linux-gnu

[ci_notify--- via Gcc-testresults]

9]+.b, z[0-9]+.bn 2
FAIL: gcc.target/aarch64/sve/var_stride_2.c scan-assembler-times 
tubfiztx[0-9]+, x2, 10, 16n 1
FAIL: gcc.target/aarch64/sve/var_stride_2.c scan-assembler-times 
tubfiztx[0-9]+, x3, 10, 16n 1
FAIL: gcc.target/aarch64/sve/var_stride_4.c scan-assembler-times 
tsbfiztx[0-9]+, x2, 10, 32n 1
FAIL: gcc.target/aarch64/sve/var_stride_4.c scan-assembler-times 
tsbfiztx[0-9]+, x3, 10, 32n 1

=== gcc Summary ===

# of expected passes340546
# of unexpected failures91
# of unexpected successes   2
# of expected failures  1761
# of unsupported tests  4195
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/aarch64-linux-gnu-gcc
  version 15.0.0 20240614 (experimental) [master revision 
gcc-15-1347-ge5e341243bf] (GCC) 

Host   is x86_64-pc-linux-gnu

=== gfortran tests ===


Running target qemu
FAIL: gfortran.dg/matmul_15.f90   -O  execution test

=== gfortran Summary ===

# of expected passes69643
# of unexpected failures1
# of expected failures  263
# of unsupported tests  156
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/aarch64-linux-gnu-gfortran
  version 15.0.0 20240614 (experimental) [master revision 
gcc-15-1347-ge5e341243bf] (GCC) 

Host   is x86_64-pc-linux-gnu

=== g++ tests ===


Running target qemu
FAIL: g++.dg/modules/xtreme-header-1_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-1_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-1_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-tr1_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-tr1_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-tr1_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/tsan/pthread_cond_clockwait.C   -O0  execution test
FAIL: g++.dg/tsan/pthread_cond_clockwait.C   -O2  execution test

=== g++ Summary ===

# of expected passes416188
# of unexpected failures17
# of expected failures  3002
# of unsupported tests  12568
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/aarch64-linux-gnu-g++
  version 15.0.0 20240614 (experimental) [master revision 
gcc-15-1347-ge5e341243bf] (GCC) 

Host   is x86_64-pc-linux-gnu

=== objc tests ===


Running target qemu

=== objc Summary ===

# of expected passes2846
# of unsupported tests  70
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/aarch64-linux-gnu-gcc
  version 15.0.0 20240614 (experimental) [master revision 
gcc-15-1347-ge5e341243bf] (GCC) 


Compiler version: 15.0.0 20240614 (experimental) [master revision 
gcc-15-1347-ge5e341243bf] (GCC) 
Platform: aarch64-unknown-linux-gnu
configure flags: SHELL=/bin/bash 
--with-mpc=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu
 
--with-mpfr=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu
 
--with-gmp=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu
 --with-gnu-as --with-gnu-ld --disable-libmudflap --enable-lto --enable-shared 
--without-included-gettext --enable-nls --with-system-zlib 
--disable-sjlj-exceptions --enable-gnu-unique-object --enable-linker-build-id 
--disable-libstdcxx-pch --enable-c99 --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-long-long --with-cloog=no --with-ppl=no 
--with-isl=no --disable-multilib --enable-fix-cortex-a53-835769 
--enable-fix-cortex-a53-843419 --with-arch=armv8-a --enable-threads=posix 
--enable-multiarch --enable-libstdcxx-time=yes --enable-gnu-indirect-function 
--with-sysroot=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/aarch64-linux-gnu/libc
 --enable-checking=yes --disable-bootstrap --enable-languages=default 
--prefix=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu
 --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu 
--target=aarch64-linux-gnu

Re: [PATCH] rs6000, altivec-2-runnable.c update the require-effective-target

[Segher Boessenkool]

Hi!

On Fri, Jun 14, 2024 at 11:37:46AM -0700, Carl Love wrote:
>  /* { dg-do run } */
> -/* { dg-options "-mvsx" } */
> -/* { dg-additional-options "-mdejagnu-cpu=power8" { target { ! has_arch_pwr8 
> } } } */
> -/* { dg-require-effective-target powerpc_vsx } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power8" } */
> +/* { dg-require-effective-target p8vector_hw } */

I have no idea why the original didn't do -O2 already, heh.  So this is
only an improvement, right!  I won't complain at all unless it fails :-)


Segher

[Bug tree-optimization/114253] [11/12/13/14/15 regression] False positive maybe-uninitialized with std::optional and ternary

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

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

Sam James  changed:

   What|Removed |Added

Summary|False positive  |[11/12/13/14/15 regression]
   |maybe-uninitialized with|False positive
   |std::optional and ternary   |maybe-uninitialized with
   ||std::optional and ternary

--- Comment #6 from Sam James  ---
I don't see it with 12/13 with -O1 per original but flakiness is expected with
these...

Anyway, I get it consistently with -O2.

[Bug c/115496] RFE: new warning to detect suspicious multiline string literals

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=99131

--- Comment #7 from Eric Gallager  ---
Semi-related: bug 99131 (for the case of missing commas)

[Bug tree-optimization/112296] __builtin_constant_p is always false for an argument with possible side-effects

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

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

Sam James  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=44

--- Comment #16 from Sam James  ---
Analyzer doesn't yet do C++ but PR44 too for diagnosing.

[Bug tree-optimization/108860] [12/13/14/15 regression] New (since gcc 12) false positive null-dereference in vector.resize

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

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

Sam James  changed:

   What|Removed |Added

Summary|New (since gcc 12) false|[12/13/14/15 regression]
   |positive null-dereference   |New (since gcc 12) false
   |in vector.resize|positive null-dereference
   ||in vector.resize

--- Comment #2 from Sam James  ---
10/11 are fine

[Bug tree-optimization/108467] false positive -Wmaybe-uninitialized warning at -O1 or higher

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---
For 14/15, it seems gone with -O2, but I see it with -Og.

[Bug middle-end/115498] Missing warning for comparing distinct (char*) pointers in much complex code path

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-15
   Severity|normal  |enhancement
 Ever confirmed|0   |1
  Component|c   |middle-end
 Blocks||87403
Summary|Missing warning for |Missing warning for
   |comparing distinct (char*)  |comparing distinct (char*)
   |pointers|pointers in much complex
   ||code path

--- Comment #1 from Andrew Pinski  ---
Confirmed. This warning can't be done in the front-end. It might become as
useless as strict aliasing and strict overflows were ...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug c/115498] New: Missing warning for comparing distinct (char*) pointers

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

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

Bug ID: 115498
   Summary: Missing warning for comparing distinct (char*)
pointers
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

This is from an intermediate bad reduction in another PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115137#c5

```
enum { a } b;
int d, e;
static void f(char *g, char *h) {
for (; g < h; g++) /* Comparison of two distinct & disjoint pointers */
if (b)
++d;
}
int main() { f("somepage.html", "" + e); }
```

We don't warn on comparing these distinct pointers.

I suppose it might be hard to do this in general without some aliasing
sanitizer, but for constant pool references, it should be okay?

[Bug target/115485] CASEServer.cpp:203:1: internal compiler error: in require_pic_register, at config/arm/arm.c:7855

[gang.peng at aclsemi dot com via Gcc-bugs]

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

--- Comment #5 from Gang Peng  ---
(In reply to Andrew Pinski from comment #4)
> >GNU Arm Embedded Toolchain 10.3-2021.10
> 
> I looked into the official releases of GCC 10.3.0 and arm.c:7855 does not
> correspond to a place where an assert happens. You should file this bug with
> the folks who recieved the binary release from since they have modified the
> sources.
> 
> Also GCC 10.x is no longer supported so can you try a newer version of GCC?
> Like GCC 14.1.0 or 13.3.0?

Dear Mr. Pinski,

Thank you very much for you kindly reply.

I have donwload the GNU Arm Embedded Toolchain 10.3-2021.10 from here:
https://developer.arm.com/-/media/Files/downloads/gnu-rm/10.3-2021.10/gcc-arm-none-eabi-10.3-2021.10-aarch64-linux.tar.bz2?rev=b748c39178c043b4915b04645d7774d8=9E173D105DC6E0D452EB3A813BF28AAB

So I need report this issue to arm developer?

And I have try the latest GNU Arm Embedded Toolchain 13.2 Rel:
https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-aarch64-arm-none-eabi.tar.xz?rev=17baf091942042768d55c9a304610954=06E4C2BB7EBE7C70EA4EA51ABF9AAE2D


ubuntu240:~/build_code$
/home/gang.peng/arm-none-eabi_v13.2/bin/arm-none-eabi-g++ --version
arm-none-eabi-g++ (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.1
20231009
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The result is same:
ubuntu240:~/build_code$
/home/gang.peng/arm-none-eabi_v13.2/bin/arm-none-eabi-g++ -MMD -MF
libSecureChannel.CASEServer.cpp.o.d -Wconversion -O3 -g -fno-common
-ffunction-sections -fdata-sections -fno-exceptions -fno-unwind-tables
-fno-asynchronous-unwind-tables -Wall -Werror  -Wextra -Wshadow
-Wunreachable-code -Wvla -Wformat -Wformat-nonliteral -Wformat-security
-Wno-deprecated-declarations -Wno-missing-field-initializers
-Wno-unknown-warning-option -Wno-unused-parameter -Wno-cast-function-type
-Wno-psabi -Wno-maybe-uninitialized -fdiagnostics-color -fno-strict-aliasing
-std=gnu++17 -fno-rtti -Wnon-virtual-dtor -DCHIP_PROJECT=1
-DCHIP_HAVE_CONFIG_H=1 -DCFG_MBEDTLS=0 -DCFG_MBEDTLS_ACCELERATOR=1
-DMBEDTLS_CONFIG_FILE=\"tfm_mbedcrypto_config_profile_medium.h\"
-DCRYPTO_HW_ACCELERATOR -DLWIP_IPV6=1 -DLWIP_IPV6_ND=1 -DLWIP_IPV6_SCOPES=1
-DLWIP_PBUF_FROM_CUSTOM_POOLS=0 -DLWIP_IPV6_ROUTE_TABLE_SUPPORT=1
-DCHIP_DEVICE_LAYER_NONE=0 -DCHIP_SYSTEM_CONFIG_USE_ZEPHYR_NET_IF=0
-DCHIP_SYSTEM_CONFIG_USE_BSD_IFADDRS=0
-DCHIP_SYSTEM_CONFIG_USE_ZEPHYR_SOCKET_EXTENSIONS=0
-DCHIP_SYSTEM_CONFIG_USE_LWIP=1 -DCHIP_SYSTEM_CONFIG_USE_SOCKETS=0
-DCHIP_SYSTEM_CONFIG_USE_NETWORK_FRAMEWORK=0
-DCHIP_ADDRESS_RESOLVE_IMPL_INCLUDE_HEADER=\
-fPIE -msingle-pic-base -mpic-register=r9 -fomit-frame-pointer
-mno-pic-data-is-text-relative -mthumb -mlong-calls -mcpu=cortex-m33+nodsp
-mfpu=fpv5-sp-d16 -mfloat-abi=hard -mcmse --specs=nosys.specs
--specs=nano.specs -nostdlib  -fno-use-cxa-atexit -Wno-conversion -Wno-error
-Wno-sign-compare -Wno-unused-function -Wno-unused-but-set-variable
-Wno-unused-variable  -Wno-literal-suffix  -fno-builtin-printf
-fno-builtin-sprintf -fno-builtin-snprintf 
-DCHIP_MINMDNS_USE_EPHEMERAL_UNICAST_PORT=0 -DCHIP_MINMDNS_HIGH_VERBOSITY=0
-DCHIP_MINMDNS_DEFAULT_POLICY=1 -Iinclude -Iinclude/include -Iinclude/port
-Iinclude/lib -c CASEServer.cpp -o libSecureChannel.CASEServer.cpp.o
CASEServer.cpp: In member function 'virtual CHIP_ERROR
chip::CASEServer::_ZThn8_N4chip10CASEServer17OnMessageReceivedEPNS_9Messaging15ExchangeContextERKNS_13PayloadHeaderEONS_6System18PacketBufferHandleE(chip::Messaging::ExchangeContext*,
const chip::PayloadHeader&, chip::System::PacketBufferHandle&&)':
CASEServer.cpp:203:1: internal compiler error: in require_pic_register, at
config/arm/arm.cc:8023
  203 | } // namespace chip
  | ^
0x7f495dd8e082 __libc_start_main
../csu/libc-start.c:308
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.

Thanks a lot!

BRs
Gang Peng

[Bug tree-optimization/96447] [11/12 regression] False positive -Wstringop-overflow with -O3 due to loop unrolling

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
Summary|False positive  |[11/12 regression] False
   |-Wstringop-overflow with|positive
   |-O3 due to loop unrolling   |-Wstringop-overflow with
   ||-O3 due to loop unrolling

--- Comment #3 from Sam James  ---
10 was the first bad version and 13+ are fixed.

[Bug middle-end/106661] [11/12 regression] possible uninitialized variable usage in store_bit_field_1

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |13.0

--- Comment #2 from Andrew Pinski  ---
Fixed then.

[Bug tree-optimization/115125] [-Wstringop-overflow=] with O2/O3 - false positive?

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

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

--- Comment #4 from Sam James  ---
I see -Warray-bounds with 12/13/14/15. I don't see -Wstringop-overflow at all
here.

[Bug middle-end/106661] [11/12 regression] possible uninitialized variable usage in store_bit_field_1

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

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

Sam James  changed:

   What|Removed |Added

Summary|possible uninitialized  |[11/12 regression] possible
   |variable usage in   |uninitialized variable
   |store_bit_field_1   |usage in store_bit_field_1
 CC||tnfchris at gcc dot gnu.org

--- Comment #1 from Sam James  ---
Fixed by r13-2258-g368dbb23c5efaf. At a glance (not checking properly), it may
have been introduced by r8-5461-g2d7b38df8e50a2. I don't think the fix was
backported.

[Bug tree-optimization/115492] [15 Regression] wrong code at -O2/O3 since r15-204-g7c469a9fc78550

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

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

Sam James  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=100923

--- Comment #4 from Sam James  ---
r15-204-g7c469a9fc78550

[Bug tree-optimization/115484] [13/14/15 regression] if-to-switch prevents AVX vectorization

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |13.4

[Bug tree-optimization/115484] [13/14/15 regression] if-to-switch prevents AVX vectorization

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Sam James from comment #2)
> GCC 8 vectorises it: https://godbolt.org/z/Y8Pvxsh5c.

The if-to-switch was not until GCC 11: r11-5605-g03eb09292ef228.
What made GCC 9 fail was the conversion from bool to int though:
/app/example.c:2:5: missed:   not vectorized: relevant stmt not supported:
patt_29 = (int) patt_30;

But that worked in GCC 8. Though that was fixed in GCC 11.

If you replace `c|=` with:
```
c |=  (*s == ',' | *s == '|' | *s == '!' | *s == '*');
```

GCC 11+ is able to vectorize it again. But the original testcase fails now due
to if-to-switch .

[Bug tree-optimization/115484] [13/14/15 regression] if-to-switch prevents AVX vectorization

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

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

--- Comment #4 from Sam James  ---
Not only does 8 vectorise it, but so does GCC 11, GCC 12. So, 9/10/13/14/15 are
broken.

[Bug tree-optimization/115484] [13/14/15 regression] if-to-switch prevents AVX vectorization

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

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

Sam James  changed:

   What|Removed |Added

Summary|[11/12/13/14/15 regression] |[13/14/15 regression]
   |if-to-switch prevents AVX   |if-to-switch prevents AVX
   |vectorization   |vectorization

--- Comment #3 from Sam James  ---
(In reply to Sam James from comment #2)
> GCC 8 vectorises it: https://godbolt.org/z/Y8Pvxsh5c.

Not only does 8 vectorise it, but so does GCC 11, GCC 12. So, 9/13/14/15 are
broken.

[Bug tree-optimization/115484] [11/12/13/14/15 regression] if-to-switch prevents AVX vectorization

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

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

Sam James  changed:

   What|Removed |Added

Summary|if-to-switch prevents AVX   |[11/12/13/14/15 regression]
   |vectorization   |if-to-switch prevents AVX
   ||vectorization

--- Comment #2 from Sam James  ---
GCC 8 vectorises it: https://godbolt.org/z/Y8Pvxsh5c.

[Bug c/115489] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:589

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #2 from Sam James  ---
Pretty sure you're right, as my checking 10+11 don't fail.

[Bug c/115489] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:589

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||pinskia at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Keywords||ice-checking
   Last reconfirmed||2024-06-15

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
static int *g_161;
int f(int);
void func_64(int l_724) {
  l_724 &=  f (g_161);
}
static int g_161;
```

I suspect this started with r12-3278-g823685221de986 but since it does not ICE
with release checking I am not 100% there.

Results for 15.0.0 20240614 (experimental) [remotes/origin/master r15-1347-ge5e341243bf] (GCC) testsuite on pru-unknown-elf

[The GnuPru BuildBot via Gcc-testresults]

c.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: gcc.dg/tree-ssa/if-to-switch-10.c scan-tree-dump iftoswitch "Condition 
chain with [^\\n\\r]* BBs transformed into a switch statement."
FAIL: gcc.dg/tree-ssa/if-to-switch-3.c scan-tree-dump iftoswitch "Condition 
chain with [^\\n\\r]* BBs transformed into a switch statement."
FAIL: gcc.dg/tree-ssa/if-to-switch-9.c scan-tree-dump iftoswitch "Condition 
chain with [^\\n\\r]* BBs transformed into a switch statement."
FAIL: gcc.dg/tree-ssa/pr103281-1.c scan-tree-dump-not optimized "foo "
FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread2 "Jumps 
threaded: 9"
FAIL: gcc.dg/tree-ssa/update-threading.c scan-tree-dump-times optimized 
"Invalid sum" 0
FAIL: outputs-22 exe savetmp namedb-2: outputs.ld1_args
FAIL: outputs-23 exe savetmp named2-2: outputs.ld1_args
FAIL: outputs-24 exe savetmp named2-3: outputs.ld1_args
FAIL: outputs-25 exe savetmp named2-4: outputs.ld1_args
FAIL: outputs-294 lto sing unnamed-3: a.ld1_args
FAIL: outputs-294 lto sing unnamed-3: a.ld_args

=== gcc Summary ===

# of expected passes133545
# of unexpected failures62
# of unexpected successes   2
# of expected failures  871
# of unresolved testcases   1
# of unsupported tests  4694
/home/dinux/projects/pru/testbot-workspace/pru-gcc-build/gcc/xgcc  version 
15.0.0 20240614 (experimental) [remotes/origin/master r15-1347-ge5e341243bf] 
(GCC) 

Host   is x86_64-pc-linux-gnu

=== g++ tests ===


Running target pru-sim
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c  -std=c++14  2 blank 
line(s) in output
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c  -std=c++14  expected 
multiline pattern lines 49-64
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c  -std=c++14 (test for 
excess errors)
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c  -std=c++17  2 blank 
line(s) in output
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c  -std=c++17  expected 
multiline pattern lines 49-64
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c  -std=c++17 (test for 
excess errors)
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c  -std=c++20  2 blank 
line(s) in output
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c  -std=c++20  expected 
multiline pattern lines 49-64
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c  -std=c++20 (test for 
excess errors)
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c  -std=c++98  2 blank 
line(s) in output
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c  -std=c++98  expected 
multiline pattern lines 49-64
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c  -std=c++98 (test for 
excess errors)
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c  -std=c++14  2 blank 
line(s) in output
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c  -std=c++14  expected 
multiline pattern lines 19-34
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c  -std=c++14 (test for 
excess errors)
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c  -std=c++17  2 blank 
line(s) in output
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c  -std=c++17  expected 
multiline pattern lines 19-34
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c  -std=c++17 (test for 
excess errors)
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c  -std=c++20  2 blank 
line(s) in output
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c  -std=c++20  expected 
multiline pattern lines 19-34
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c  -std=c++20 (test for 
excess errors)
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c  -std=c++98  2 blank 
line(s) in output
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c  -std=c++98  expected 
multiline pattern lines 19-34
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-8.c  -std=c++98 (test for 
excess errors)
FAIL: c-c++-common/pr103798-2.c  -std=gnu++14  scan-assembler-not memchr
FAIL: c-c++-common/pr103798-2.c  -std=gnu++17  scan-assembler-not memchr
FAIL: c-c++-common/pr103798-2.c  -std=gnu++20  scan-assembler-not memchr
FAIL: c-c++-common/pr103798-2.c  -std=gnu++98  scan-assembler-not memchr
FAIL: c-c++-common/pr103798-3.c  -std=gnu++14  scan-assembler-not memchr
FAIL: c-c++-common/pr103798-3.c  -std=gnu++17  scan-assembler-not memchr
FAIL: c-c++-common/pr103798-3.c  -std=gnu++20  scan-assembler-not memchr
FAIL: c-c++-common/pr103798-3.c  -std=gnu++98  scan-assembler-not memchr
FAIL: c-c++-common/pr103798-4.c  -std=gnu++14  scan-assembler-not memchr
FAIL: c-c++-common/pr103798-4.c  -std=gnu++17  scan-assembler-not memchr
FAIL: c-c++-common/pr103798-4.c  -std=gnu++20  scan-assembler-not memchr
FAIL: c-c++-common/pr103798-4.c

[gcc(refs/users/meissner/heads/work168-bugs)] Update ChangeLog.*

[Michael Meissner via Gcc-cvs]

https://gcc.gnu.org/g:15e46f9dd299d97162ccffc79a43653021689ac2

commit 15e46f9dd299d97162ccffc79a43653021689ac2
Author: Michael Meissner 
Date:   Fri Jun 14 20:31:13 2024 -0400

Update ChangeLog.*

Diff:
---
 gcc/ChangeLog.bugs | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/gcc/ChangeLog.bugs b/gcc/ChangeLog.bugs
index bdd67eed1ab2..5e33b15d5b7e 100644
--- a/gcc/ChangeLog.bugs
+++ b/gcc/ChangeLog.bugs
@@ -1,3 +1,25 @@
+ Branch work168-bugs, patch #401 
+
+Disable IEEE 128 on little endian 32-bit systems.
+
+2024-06-14  Michael Meissner  
+
+gcc/
+
+   * config/rs6000/rs6000.cc (rs6000_option_override_internal): Do not
+   allow IEEE 128-bit on little endian 32-bit systems.
+
+ Branch work168-bugs, patch #400 
+
+Little endian PowerPC without VSX cannot support IEEE 128-bit.
+
+2024-06-14  Michael Meissner  
+
+libgfortran/
+
+   * kinds-override.h: Do not enable IEEE 128-bit floating point support on
+   little endian PowerPC that does not have VSX support.
+
  Branch work168-bugs, patch #11 from work168 branch 

 
 Add -mcpu=future tuning support.

[gcc(refs/users/meissner/heads/work168-bugs)] Disable IEEE 128 on little endian 32-bit systems.

[Michael Meissner via Gcc-cvs]

https://gcc.gnu.org/g:3ea2d4cac5c925398e9379e05fccb21b8266cda7

commit 3ea2d4cac5c925398e9379e05fccb21b8266cda7
Author: Michael Meissner 
Date:   Fri Jun 14 20:29:47 2024 -0400

Disable IEEE 128 on little endian 32-bit systems.

2024-06-14  Michael Meissner  

gcc/

* config/rs6000/rs6000.cc (rs6000_option_override_internal): Do not
allow IEEE 128-bit on little endian 32-bit systems.

Diff:
---
 gcc/config/rs6000/rs6000.cc | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index c5c4191127e4..ea36e651b446 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -4146,7 +4146,8 @@ rs6000_option_override_internal (bool global_init_p)
  the keyword as well as the type.  */
   TARGET_FLOAT128_TYPE = TARGET_FLOAT128_ENABLE_TYPE && TARGET_VSX;
 
-  /* IEEE 128-bit floating point requires VSX support.  */
+  /* IEEE 128-bit floating point requires VSX support.  Disable IEEE 128-bit on
+ legacy 32-bit LE systems.  */
   if (TARGET_FLOAT128_KEYWORD)
 {
   if (!TARGET_VSX)
@@ -4154,6 +4155,16 @@ rs6000_option_override_internal (bool global_init_p)
  if ((rs6000_isa_flags_explicit & OPTION_MASK_FLOAT128_KEYWORD) != 0)
error ("%qs requires VSX support", "-mfloat128");
 
+ TARGET_FLOAT128_TYPE = 0;
+ rs6000_isa_flags &= ~(OPTION_MASK_FLOAT128_KEYWORD
+   | OPTION_MASK_FLOAT128_HW);
+   }
+  else if (!TARGET_POWERPC64 && !BYTES_BIG_ENDIAN)
+   {
+ if ((rs6000_isa_flags_explicit & OPTION_MASK_FLOAT128_KEYWORD) != 0)
+   error ("%qs requires 64-bit support on little endian systems",
+  "-mfloat128");
+
  TARGET_FLOAT128_TYPE = 0;
  rs6000_isa_flags &= ~(OPTION_MASK_FLOAT128_KEYWORD
| OPTION_MASK_FLOAT128_HW);

[PATCH] rs6000, altivec-2-runnable.c update the require-effective-target

[Carl Love]

GCC maintainers:

Per the additional feedback after patch: 

  commit c892525813c94b018464d5a4edc17f79186606b7
  Author: Carl Love 
  Date:   Tue Jun 11 14:01:16 2024 -0400

  rs6000, altivec-2-runnable.c should be a runnable test

  The test case has "dg-do compile" set not "dg-do run" for a runnable
  test.  This patch changes the dg-do command argument to run.

  gcc/testsuite/ChangeLog:gcc/testsuite/ChangeLog:
  * gcc.target/powerpc/altivec-2-runnable.c: Change dg-do
  argument to run.

was approved and committed, I have updated the dg-require-effective-target
and dg-options as requested so the test will compile with -O2 on a 
machine that has a minimum support of Power 8 vector hardware.

The patch has been tested on Power 10 with no regression failures.

Please let me know if this patch is acceptable for mainline.  Thanks.

Carl 

--

rs6000, altivec-2-runnable.c update the require-effective-target

The test requires a minimum of Power8 vector HW and a compile level
of -O2.

gcc/testsuite/ChangeLog:gcc/testsuite/ChangeLog:
* gcc.target/powerpc/altivec-2-runnable.c: Change the
require-effective-target for the test.
---
 gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c 
b/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
index 17b23eb9d50..04c7d1ac70e 100644
--- a/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
+++ b/gcc/testsuite/gcc.target/powerpc/altivec-2-runnable.c
@@ -1,7 +1,6 @@
 /* { dg-do run } */
-/* { dg-options "-mvsx" } */
-/* { dg-additional-options "-mdejagnu-cpu=power8" { target { ! has_arch_pwr8 } 
} } */
-/* { dg-require-effective-target powerpc_vsx } */
+/* { dg-options "-O2 -mdejagnu-cpu=power8" } */
+/* { dg-require-effective-target p8vector_hw } */
 
 #include 
 
-- 
2.45.0

Results for 15.0.0 20240614 (experimental) [remotes/origin/HEAD r15-1343-g2830b0b8655] (GCC) testsuite on powerpc64le-unknown-linux-gnu

[Bill Seurer (POWER9) via Gcc-testresults]

-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 a.j == 14
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 32 a[0] == 4
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 32 a[1] == 14
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 43 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 43 a.j == 14
FAIL: gcc.dg/guality/sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 21 a.j == 14
FAIL: gcc.dg/guality/sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 32 a[0] == 4
FAIL: gcc.dg/guality/sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 32 a[1] == 14
FAIL: gcc.dg/guality/sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 43 a.i == 4
FAIL: gcc.dg/guality/sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 43 a.j == 14
FAIL: gcc.dg/guality/vla-1.c   -O2  -DPREVENT_OPTIMIZATION  line 17 sizeof (a) 
== 6
FAIL: gcc.dg/guality/vla-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 17 sizeof (a) == 6
FAIL: gcc.dg/guality/vla-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 17 sizeof (a) == 6
FAIL: gcc.dg/guality/vla-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 17 sizeof 
(a) == 6
FAIL: gcc.dg/guality/vla-1.c   -Os  -DPREVENT_OPTIMIZATION  line 17 sizeof (a) 
== 6
FAIL: gcc.dg/guality/vla-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 25 sizeof (a) == 6 * sizeof 
(int)
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
XPASS: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized "return 28;"
FAIL: gcc.dg/tree-ssa/update-threading.c scan-tree-dump-times optimized 
"Invalid sum" 0
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-slp-12.c scan-tree-dump-times vect 
"vectorizing stmts using SLP" 3
FAIL: gcc.dg/vect/vect-117.c -flto -ffat-lto-objects  scan-tree-dump-not 
optimized "Invalid sum"
FAIL: gcc.dg/vect/vect-117.c scan-tree-dump-not optimized "Invalid sum"
FAIL: gcc.target/powerpc/rlwimi-2.c scan-assembler-times (?n)^s+[a-z] 20217
XPASS: gcc.target/powerpc/ppc-fortran/ieee128-math.f90   -O  (test for excess 
errors)

=== gcc Summary ===

# of expected passes180382
# of unexpected failures107
# of unexpected successes   20
# of expected failures  1617
# of unsupported tests  4277
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc  version 15.0.0 20240614 
(experimental) [remotes/origin/HEAD r15-1343-g2830b0b8655] (GCC) 

=== gfortran tests ===


Running target unix
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
FAIL: gfortran.dg/ieee/comparisons_3.F90   -O0  execution test
FAIL: gfortran.dg/ieee/comparisons_3.F90   -O1  execution test
FAIL: gfortran.dg/ieee/comparisons_3.F90   -O2  execution test
FAIL: gfortran.dg/ieee/comparisons_3.F90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/ieee/comparisons_3.F90   -O3 -g  execution test
FAIL: gfortran.dg/ieee/comparisons_3.F90   -Os  execution test
FAIL: gfortran.dg/ieee/large_2.f90   -O0  execution test
FAIL: gfortran.dg/ieee/large_2.f90   -O1  execution test
FAIL: gfortran.dg/ieee/large_2.f90   -O2  execution test
FAIL: gfortran.dg/ieee/large_2.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/ieee/large_2.f90   -O3 -g  execution test
FAIL: gfortran.dg/ieee/large_2.f90   -Os  execution test

=== gfortran Summary ===

# of expected passes70283
# of unexpected failures12
# of unexpected successes   6
# of expected failures  285
# of unsupported tests  17

Results for 15.0.0 20240614 (experimental) [remotes/origin/HEAD r15-1347-ge5e341243b] (GCC) testsuite on powerpc64le-unknown-linux-gnu

[Bill Seurer (POWER8) via Gcc-testresults]

-partition=none  -DPREVENT_OPTIMIZATION line 16 y == 2
FAIL: gcc.dg/guality/pr68860-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 y == 2
FAIL: gcc.dg/guality/pr68860-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 y == 
2
FAIL: gcc.dg/guality/pr68860-1.c   -Os  -DPREVENT_OPTIMIZATION  line 16 y == 2
FAIL: gcc.dg/guality/pr68860-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 16 y == 2
FAIL: gcc.dg/guality/pr68860-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 16 y == 
2
FAIL: gcc.dg/guality/sra-1.c   -O2  -DPREVENT_OPTIMIZATION  line 43 a.j == 14
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 43 a.j == 14
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 a.j == 14
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 32 a[0] == 4
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 32 a[1] == 14
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 43 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 43 a.j == 14
FAIL: gcc.dg/guality/sra-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 43 a.j == 14
FAIL: gcc.dg/guality/sra-1.c   -Os  -DPREVENT_OPTIMIZATION  line 43 a.j == 14
FAIL: gcc.dg/guality/sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 21 a.j == 14
FAIL: gcc.dg/guality/sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 32 a[0] == 4
FAIL: gcc.dg/guality/sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 32 a[1] == 14
FAIL: gcc.dg/guality/sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 43 a.i == 4
FAIL: gcc.dg/guality/sra-1.c  -Og -DPREVENT_OPTIMIZATION  line 43 a.j == 14
FAIL: gcc.dg/guality/vla-1.c   -O2  -DPREVENT_OPTIMIZATION  line 17 sizeof (a) 
== 6
FAIL: gcc.dg/guality/vla-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION line 17 sizeof (a) == 6
FAIL: gcc.dg/guality/vla-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 17 sizeof (a) == 6
FAIL: gcc.dg/guality/vla-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  line 17 sizeof 
(a) == 6
FAIL: gcc.dg/guality/vla-1.c   -Os  -DPREVENT_OPTIMIZATION  line 17 sizeof (a) 
== 6
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
XPASS: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized "return 28;"
FAIL: gcc.dg/tree-ssa/update-threading.c scan-tree-dump-times optimized 
"Invalid sum" 0
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-slp-12.c scan-tree-dump-times vect 
"vectorizing stmts using SLP" 3
FAIL: gcc.dg/vect/vect-117.c -flto -ffat-lto-objects  scan-tree-dump-not 
optimized "Invalid sum"
FAIL: gcc.dg/vect/vect-117.c scan-tree-dump-not optimized "Invalid sum"
FAIL: gcc.target/powerpc/rlwimi-2.c scan-assembler-times (?n)^s+[a-z] 20217
XPASS: gcc.target/powerpc/ppc-fortran/ieee128-math.f90   -O  (test for excess 
errors)

=== gcc Summary ===

# of expected passes179351
# of unexpected failures126
# of unexpected successes   13
# of expected failures  1600
# of unsupported tests  5065
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc  version 15.0.0 20240614 
(experimental) [remotes/origin/HEAD r15-1347-ge5e341243b] (GCC) 

=== gfortran tests ===


Running target unix
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
FAIL: gfortran.dg/ieee/comparisons_3.F90   -O0  execution test
FAIL: gfortran.dg/ieee/comparisons_3.F90   -O1  execution test
FAIL: gfortran.dg/ieee/comparisons_3.F90   -O2  execution test
FAIL: gfortran.dg/ieee/comparisons_3.F90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loop

Re: [PATCH] rs6000: Compute rop_hash_save_offset for non-Altivec compiles [PR115389]

[Peter Bergner]

On 6/13/24 10:26 PM, Peter Bergner wrote:
> On 6/13/24 9:26 PM, Kewen.Lin wrote:
 I understand this is just copied from the if arm, but if I read this 
 right, it can be
 simplified as:
>>>
>>> Ok, I'll retest with that simplification.
> 
> So I retested a normal powerpc64le-linux build (ie, we default to Power8
> with Altivec) and it bootstrapped and regtested with no regressions.
> I then attempted a --with-cpu=power5 build to test the non-altivec path,
> but both the unpatched and patched builds died building libgfortran with
> the following error: "error: ‘_Float128’ is not supported on this target".
> I believe that is related to PR113652.  I'll kick off the build again,
> this time disabling Fortran and seeing if the build completes.

My bad for calling the --with-cpu=power5 bootstrap build on ELFv2 a "bug".
It's not, since ELFv2 mandates a cpu with at least ISA 2.07 (eg. Power8)
support and some of the libgfortran code was written assuming that, so what
I was trying to do was really not supported (ie, luser error).

That said, the --with-cpu=power5 build without fortran did bootstrap and
regtest with no regressions, so the build did test that code path and
exposed no problems.



>>> That's what I expected too! :-)  However, I was surprised to learn that 
>>> -mno-altivec
>>> does *not* disable TARGET_ALTIVEC_ABI.  I had to explicitly use the -mabi= 
>>> option to
>>> expose the bug.
>>
>> oh, it's surprising, I learn something today! :) I guess it's not 
>> intentional but just no
>> one noticed it, as it seems nonsense to have altivec ABI extension but not 
>> using any altivec
>> features.

Currently, TARGET_ALTIVEC_ABI is defined as:

  #define TARGET_ALTIVEC_ABI rs6000_altivec_abi

Would it make sense to redine it to:

  #define TARGET_ALTIVEC_ABI (TARGET_ALTIVEC && rs6000_altivec_abi)

...or add some code in rs6000 option handling to disable rs6000_altivec_abi
when TARGET_ALTIVEC is false?  or do we care enough to even change it? :-)

Peter

[Bug c++/115053] gcc crashed without back trace

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-15
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords|ice-on-invalid-code |ice-on-valid-code

--- Comment #4 from Andrew Pinski  ---
#3  0x00b3f34b in dump_aggr_type (t=0x779b89d8, flags=1,
pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:794
#4  0x00b46f23 in dump_scope (scope=, flags=, pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:249
#5  0x00b3f74a in dump_aggr_type (t=, flags=4096,
pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:825
#6  0x00b4604f in dump_template_argument_list (args=0x779b9ac0,
flags=4096, pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:325
#7  0x00b47133 in dump_template_parms (info=,
primary=, flags=, pp=0x3302820
) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:2111
#8  0x00b46326 in dump_parameters (parmtypes=0x779be640, flags=0,
pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/tree.h:3633
#9  0x00b3f61c in dump_aggr_type (t=0x779b89d8, flags=1,
pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:849
#10 0x00b46f23 in dump_scope (scope=, flags=, pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:249
#11 0x00b3f74a in dump_aggr_type (t=, flags=4096,
pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:825
#12 0x00b4604f in dump_template_argument_list (args=0x779b9ac0,
flags=4096, pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:325
#13 0x00b47133 in dump_template_parms (info=,
primary=, flags=, pp=0x3302820
) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:2111
#14 0x00b46326 in dump_parameters (parmtypes=0x779be640, flags=0,
pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/tree.h:3633
#15 0x00b3f61c in dump_aggr_type (t=0x779b89d8, flags=1,
pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:849
#16 0x00b46f23 in dump_scope (scope=, flags=, pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:249
#17 0x00b3f74a in dump_aggr_type (t=, flags=4096,
pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:825
#18 0x00b4604f in dump_template_argument_list (args=0x779b9ac0,
flags=4096, pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:325
#19 0x00b47133 in dump_template_parms (info=,
primary=, flags=, pp=0x3302820
) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:2111
#20 0x00b46326 in dump_parameters (parmtypes=0x779be640, flags=0,
pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/tree.h:3633
#21 0x00b3f61c in dump_aggr_type (t=0x779b89d8, flags=1,
pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:849
#22 0x00b46f23 in dump_scope (scope=, flags=, pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:249
#23 0x00b3f74a in dump_aggr_type (t=, flags=4096,
pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:825
#24 0x00b4604f in dump_template_argument_list (args=0x779b9ac0,
flags=4096, pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:325
#25 0x00b47133 in dump_template_parms (info=,
primary=, flags=, pp=0x3302820
) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:2111
#26 0x00b46326 in dump_parameters (parmtypes=0x779be640, flags=0,
pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/tree.h:3633
#27 0x00b3f61c in dump_aggr_type (t=0x779b89d8, flags=1,
pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:849
#28 0x00b46f23 in dump_scope (scope=, flags=, pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:249
#29 0x00b3f74a in dump_aggr_type (t=, flags=4096,
pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:825
#30 0x00b4604f in dump_template_argument_list (args=0x779b9ac0,
flags=4096, pp=0x3302820 ) at
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/error.cc:325


Confirmed. Looks like it is going in an infinite loop.

Note you also get an ICE if you don't supply -quiet when invoking cc1plus due
to cc1plus dumping the function name.

[Bug c++/115053] gcc crashed without back trace

[rungecc at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Chromo Runge  ---
(In reply to Marek Polacek from comment #1)
> Can't reproduce:
> 
> $ time ./cc1plus -quiet 115053.C -std=c++20
> 
> real  0m0.016s
> user  0m0.010s
> sys   0m0.006s
> 
> same with gcc 14 and 13.

It seems that this happens with flag `-g`, see attachment, reproduced in my
local gcc.

[Bug tree-optimization/115492] [15 Regression] wrong code at -O2/O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||alias

--- Comment #3 from Andrew Pinski  ---
Note I am thinking it was one of the recent aliasing patches from richi which
causes this because adding -fno-strict-aliasing allows the testcase to pass.

[Bug c++/115053] gcc crashed without back trace

[rungecc at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Chromo Runge  ---
Created attachment 58434
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58434=edit
local crash

[Bug tree-optimization/115492] [15 Regression] wrong code at -O2/O3

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #2 from Sam James  ---
I'll bisect. I have a few guesses...

Re: [PATCH] LoongArch: Use bstrins for "value & (-1u << const)"

[YunQiang Su]

Xi Ruoyao  于2024年6月9日周日 21:50写道：
>
> A move/bstrins pair is as fast as a (addi.w|lu12i.w|lu32i.d|lu52i.d)/and
> pair, and twice fast as a srli/slli pair.  When the src reg and the dst

Just want to know that why not adjust the RTX cost of bstrins vs srli/slli?
It may benefit more cases.

> reg happens to be the same, the move instruction can be optimized away.
>

[Bug fortran/115491] Internal compiler error: in resolve_typebound_procedure, at fortran/resolve.cc:14913

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-06-15
 Status|UNCONFIRMED |WAITING

--- Comment #3 from Andrew Pinski  ---
You can use something like delta to reduce the sources.
https://github.com/dsw/delta

I usually use that instead of something like cvise
(https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
https://github.com/marxin/cvise) because it just does it based on the text file
rather than based on C/C++ tokens (and expressions); basically delta can handle
Fortran code too.

[Bug tree-optimization/115492] [15 Regression] wrong code at -O2/O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-14
Summary|[15 Regression] wrong code  |[15 Regression] wrong code
   |at -O2/O3 when compiled |at -O2/O3
   |with -fPIC  |
   Keywords||needs-bisection
 Ever confirmed|0   |1
   Target Milestone|--- |15.0

--- Comment #1 from Andrew Pinski  ---
Confirmed. -fPIC is just forces f to not to be inlined.
Here is a testcase which fails at -O2 but passes at -O0/-O1:
```
int a = 2, b=0, *c = , *d = , e=0;
[[gnu::noipa]]
void f(int) {}
[[gnu::noinline]]
int h(int *k) {
  int ***j;
  if (b) {
*j =  // Note the unintialized j is used here
 // but since it is conditional and b is always zero, there should
no
 // effect otherwise.
***j;
  }
  f(*k);
  *d = e;
  return *k;
}
int main() { if (h(c)) __builtin_abort(); }
```

[Bug rtl-optimization/115495] [15 Regression] ICE in smallest_mode_for_size, at stor-layout.cc:356 during combine on RISC-V rv64gcv_zvl256b at -O3

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

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

--- Comment #2 from Andrew Pinski  ---
Note in most cases `(subreg:DI (reg:V16HI 139 [ vect_cst__21 ]) 0) (const_int
16 [0x10])` would normally be a `vec_select` so I am shock that it is using a
subreg here ...

[Bug rtl-optimization/115495] [15 Regression] ICE in smallest_mode_for_size, at stor-layout.cc:356 during combine on RISC-V rv64gcv_zvl256b at -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-14

--- Comment #1 from Andrew Pinski  ---
Trying 25 -> 26:
   25: r150:DI=r139:V16HI#0 0>>0x10
   26: r151:DI=zero_extend(r150:DI#0)

That is these 2 instructions:
```
(insn 25 24 26 2 (set (reg:DI 150)
(lshiftrt:DI (subreg:DI (reg:V16HI 139 [ vect_cst__21 ]) 0)
(const_int 16 [0x10]))) "/app/example.c":5:14 299 {lshrdi3}
 (nil))
(insn 26 25 34 2 (set (reg:DI 151)
(zero_extend:DI (subreg:HI (reg:DI 150) 0))) "/app/example.c":5:14 121
{*zero_extendhidi2}
 (expr_list:REG_DEAD (reg:DI 150)
(nil)))
```
The above rtl looks good as far as I know. It looks like
get_best_extraction_insn is using V16HI there though which is where it goes
wrong.

Confirmed.

This comes from the expanision of:
;; MEM  [(short int *)] = vect_cst__21;

Which looks different for GCC 14.1.0 and much simplier.

[Bug rtl-optimization/115495] [15 Regression] ICE in smallest_mode_for_size, at stor-layout.cc:356 during combine on RISC-V rv64gcv_zvl256b at -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 CC||pinskia at gcc dot gnu.org
  Component|middle-end  |rtl-optimization

[Bug target/115393] MIPS: implement _BitInt of C23

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ABI
   Severity|normal  |enhancement
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-14
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
.

[Bug target/115485] CASEServer.cpp:203:1: internal compiler error: in require_pic_register, at config/arm/arm.c:7855

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

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

--- Comment #4 from Andrew Pinski  ---
>GNU Arm Embedded Toolchain 10.3-2021.10

I looked into the official releases of GCC 10.3.0 and arm.c:7855 does not
correspond to a place where an assert happens. You should file this bug with
the folks who recieved the binary release from since they have modified the
sources.

Also GCC 10.x is no longer supported so can you try a newer version of GCC?
Like GCC 14.1.0 or 13.3.0?

Results for 15.0.0 20240614 (experimental) [master r15-1343-g2830b0b8655] (GCC) testsuite on s390x-ibm-linux-gnu default

[stefansf--- via Gcc-testresults]

.target/s390/nobp-table-jump-inline-z10.c scan-assembler 
section\\t.s390_indirect_jump
FAIL: gcc.target/s390/nobp-table-jump-inline-z10.c scan-assembler-times exrl 1
FAIL: gcc.target/s390/nobp-table-jump-inline-z900.c scan-assembler 
section\\t.s390_indirect_jump
FAIL: gcc.target/s390/nobp-table-jump-inline-z900.c scan-assembler-times 
\\tex\\t 1
FAIL: gcc.target/s390/nobp-table-jump-z10.c scan-assembler 
section\\t.s390_indirect_jump
FAIL: gcc.target/s390/nobp-table-jump-z10.c scan-assembler-times exrl 1
FAIL: gcc.target/s390/nobp-table-jump-z900.c scan-assembler 
section\\t.s390_indirect_jump
FAIL: gcc.target/s390/nobp-table-jump-z900.c scan-assembler-times ex\\t 1
FAIL: gcc.target/s390/risbg-ll-1.c scan-assembler 
f42:\\n\\tsllg\\t%r2,%r2,63\\n\\tsrag\\t%r2,%r2,63\\n\\tllgcr\\t%r2,%r2
FAIL: gcc.target/s390/vector/align-1.c scan-assembler-times 
vl\\t%v[0-9]*,[0-9]*(%r[0-9]*),3\\n 1
FAIL: gcc.target/s390/vector/align-1.c scan-assembler-times 
vst\\t%v[0-9]*,[0-9]*(%r[0-9]*),3\\n 1
FAIL: gcc.target/s390/vector/vec-abi-vararg-1.c scan-assembler 
ld\\t%v[0-9]*,368(%r15)
FAIL: gcc.target/s390/vector/vec-abi-vararg-1.c scan-assembler 
ld\\t%v[0-9]*,392(%r15)
FAIL: gcc.target/s390/vector/vec-abi-vararg-1.c scan-assembler 
vl\\t%v[0-9]*,352(%r15)
FAIL: gcc.target/s390/vector/vec-abi-vararg-1.c scan-assembler 
vl\\t%v[0-9]*,376(%r15)

=== gcc Summary for unix/-m64 ===

# of expected passes181807
# of unexpected failures177
# of unexpected successes   17
# of expected failures  1466
# of unsupported tests  4339

=== gcc Summary ===

# of expected passes360528
# of unexpected failures359
# of unexpected successes   31
# of expected failures  2933
# of unsupported tests  9296
-default/gcc/xgcc  version 15.0.0 20240614 (experimental) [master 
r15-1343-g2830b0b8655] (GCC) 

=== gdc tests ===


Running target unix/-m31
FAIL: gdc.dg/attr_module.d(test for warnings, line 12)
FAIL: gdc.dg/attr_module.d(test for warnings, line 18)
FAIL: gdc.dg/attr_module.d(test for warnings, line 24)
FAIL: gdc.dg/attr_module.d(test for warnings, line 36)
FAIL: gdc.dg/attr_module.d   (test for excess errors)
FAIL: gdc.dg/gdc231.d   (test for excess errors)
FAIL: gdc.dg/gdc253a.d   (test for excess errors)
FAIL: gdc.dg/gdc27.d   (test for excess errors)
FAIL: gdc.dg/pr108050.d   (test for excess errors)
FAIL: gdc.test/compilable/test16348.d   output-exists test16348.s
FAIL: gdc.test/compilable/test17541.d   output-exists test17541.s
FAIL: gdc.test/fail_compilation/diag4479.d   output-exists-not diag4479.o
FAIL: gdc.test/fail_compilation/fail11453a.d   output-exists-not fail11453a.o
FAIL: gdc.test/fail_compilation/fail11453b.d   output-exists-not fail11453b.o
FAIL: gdc.test/fail_compilation/fail18938.d   output-exists-not fail18938.o
FAIL: gdc.test/fail_compilation/fail19911b.d   output-exists-not fail19911b.o
FAIL: gdc.test/fail_compilation/fail23109.d   output-exists-not fail23109.o
FAIL: gdc.test/fail_compilation/ice10598.d   output-exists-not ice10598.o
FAIL: gdc.test/fail_compilation/ice11136.d   output-exists-not ice11136.o
FAIL: gdc.test/fail_compilation/ice14116.d   output-exists-not ice14116.o
FAIL: gdc.test/fail_compilation/no_Throwable.d   output-exists-not 
no_Throwable.o
FAIL: gdc.test/fail_compilation/no_TypeInfo.d   output-exists-not no_TypeInfo.o
FAIL: gdc.test/fail_compilation/verifyhookexist.d   output-exists-not 
verifyhookexist.o
FAIL: gdc.test/runnable/test34.d   execution test
FAIL: gdc.test/runnable/test34.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/test42.d   execution test
FAIL: gdc.test/runnable/test42.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/xtest46.d   execution test
FAIL: gdc.test/runnable/xtest46.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/xtest46_gc.d   execution test
FAIL: gdc.test/runnable/xtest46_gc.d -shared-libphobos   execution test
UNRESOLVED: gdc.test/runnable_cxx/cpp_stdlib.d   compilation failed to produce 
executable
UNRESOLVED: gdc.test/runnable_cxx/cpp_stdlib.d -shared-libphobos   compilation 
failed to produce executable
FAIL: gdc.test/runnable_cxx/cppa.d   execution test
FAIL: gdc.test/runnable_cxx/cppa.d -g   execution test
FAIL: gdc.test/runnable_cxx/cppa.d -g -shared-libphobos   execution test
FAIL: gdc.test/runnable_cxx/cppa.d -shared-libphobos   execution test
UNRESOLVED: gdc.test/runnable_cxx/externmangle.d   compilation failed to 
produce executable
UNRESOLVED: gdc.test/runnable_cxx/externmangle.d -shared-libphobos   
compilation failed to produce executable

=== gdc Summary for unix/-m31 ===

# of expected passes12464
# of unexpected failures35
# of unresolved testcases   4
# of unsupported tests  759

Running target unix/-m64
FAIL: gdc.dg/attr_module.d(test for warnings, line 12)
FAIL: gdc.dg/att

gcc-13-20240614 is now available

[GCC Administrator via Gcc]

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

This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-13 revision 24dbdd20dcbd4c560f852cce51aa0754464476f5

You'll find:

 gcc-13-20240614.tar.xz   Complete GCC

  SHA256=f46dbd52e17884a0dee91c1bd4bdca8bb993a1e88066e98093c6bc7fac1ecdd2
  SHA1=f7014ca559392cb9ef30739538f9c75c41c4a031

Diffs from 13-20240607 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-13
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.

Re: [PATCH v7] Match: Support more form for scalar unsigned SAT_ADD

[Maciej W. Rozycki]

On Fri, 14 Jun 2024, Richard Biener wrote:

> > I hope you'll find this all useful.  As it happens I don't need to verify
> > my needs with a RISC-V target anymore, so I'm leaving it all up to you now
> > as I need to switch back to Alpha, which has been my actual objective, and
> > these rebuilds have taken a lot of my attention already.
> 
> I'm including
> 
> @@ -2148,15 +2148,17 @@ get_group_load_store_type (vec_info *vinfo,
> stmt_vec_info stmt_info,
> ...
>   if (!nunits.is_constant ()
>   || !LOOP_VINFO_VECT_FACTOR (loop_vinfo).is_constant ()
> - || ((cremain = remain.to_constant (), true)
> + || (((cremain = group_size * cvf - gap % cnunits), true)
>   && ((cpart_size = (1 << ceil_log2 (cremain))) != 
> cnunits)
> 
> in a patch I'm testing that should eventually fix the above bogus diagnostic.

 Thank you.  I can see your fix went in with e575b5c56137 and I can 
confirm that with:



applied (and its patched-autoconf artefacts removed) `riscv64-linux-gnu' 
target now succesfully builds for me as at 1bb2535c7cb2.

  Maciej

Regressions on native/master at commit r15-1347 vs commit r15-1342 on Linux/x86_64

[Haochen Jiang via Gcc-regression]

Regressions on master at commit r15-1347 vs commit r15-1342 on Linux/x86_64
New failures:

New passes:
FAIL: libgomp.c/../libgomp.c-c++-common/for-11.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/for-6.c execution test

Re: [PATCH v1] libstdc++: Optimize removal from unique assoc containers [PR112934]

[Barnabás Pőcze]

2024. május 18., szombat 3:01 keltezéssel, Barnabás Pőcze 
 írta:

> Hi
>
>
> 2024. március 13., szerda 12:43 keltezéssel, Jonathan Wakely 
>  írta:
>
> > On Mon, 11 Mar 2024 at 23:36, Barnabás Pőcze  wrote:
> > >
> > > Previously, calling erase(key) on both std::map and std::set
> > > would execute that same code that std::multi{map,set} would.
> > > However, doing that is unnecessary because std::{map,set}
> > > guarantee that all elements are unique.
> > >
> > > It is reasonable to expect that erase(key) is equivalent
> > > or better than:
> > >
> > >   auto it = m.find(key);
> > >   if (it != m.end())
> > > m.erase(it);
> > >
> > > However, this was not the case. Fix that by adding a new
> > > function _Rb_tree<>::_M_erase_unique() that is essentially
> > > equivalent to the above snippet, and use this from both
> > > std::map and std::set.
> >
> > Hi, this change looks reasonable, thanks for the patch. Please note
> > that GCC is currently in "stage 3" of its dev process so this change
> > would have to wait until after GCC 14 branches from trunk, due in a
> > few weeks.
>
> As far as I can see GCC 14 has been released, so I pulled and ran the test 
> suite
> again:
>
>   make check-target-libstdc++-v3 
> RUNTESTFLAGS="conformance.exp=23_containers/*"
>
> and it reported no failures. Is there anything else I should do?

Anything else I should do here? I apologize if the window for new changes
has not opened yet, I don't know how that is done in gcc.


Regards,
Barnabás Pőcze


>
>
> Regards,
> Barnabás Pőcze
>
> >
> > I assume you ran the testsuite with no regressions. Do you have
> > benchmarks to show this making a difference?
> >
> >
> > >
> > > libstdc++-v3/ChangeLog:
> > >
> > > PR libstdc++/112934
> > > * include/bits/stl_tree.h (_Rb_tree<>::_M_erase_unique): Add.
> > > * include/bits/stl_map.h (map<>::erase): Use _M_erase_unique.
> > > * include/bits/stl_set.h (set<>::erase): Likewise.
> > > ---
> > >  libstdc++-v3/include/bits/stl_map.h  |  2 +-
> > >  libstdc++-v3/include/bits/stl_set.h  |  2 +-
> > >  libstdc++-v3/include/bits/stl_tree.h | 17 +
> > >  3 files changed, 19 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libstdc++-v3/include/bits/stl_map.h 
> > > b/libstdc++-v3/include/bits/stl_map.h
> > > index ad58a631af5..229643b77fd 100644
> > > --- a/libstdc++-v3/include/bits/stl_map.h
> > > +++ b/libstdc++-v3/include/bits/stl_map.h
> > > @@ -1115,7 +1115,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> > > */
> > >size_type
> > >erase(const key_type& __x)
> > > -  { return _M_t.erase(__x); }
> > > +  { return _M_t._M_erase_unique(__x); }
> > >
> > >  #if __cplusplus >= 201103L
> > >// _GLIBCXX_RESOLVE_LIB_DEFECTS
> > > diff --git a/libstdc++-v3/include/bits/stl_set.h 
> > > b/libstdc++-v3/include/bits/stl_set.h
> > > index c0eb4dbf65f..51a1717ec62 100644
> > > --- a/libstdc++-v3/include/bits/stl_set.h
> > > +++ b/libstdc++-v3/include/bits/stl_set.h
> > > @@ -684,7 +684,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> > > */
> > >size_type
> > >erase(const key_type& __x)
> > > -  { return _M_t.erase(__x); }
> > > +  { return _M_t._M_erase_unique(__x); }
> > >
> > >  #if __cplusplus >= 201103L
> > >// _GLIBCXX_RESOLVE_LIB_DEFECTS
> > > diff --git a/libstdc++-v3/include/bits/stl_tree.h 
> > > b/libstdc++-v3/include/bits/stl_tree.h
> > > index 6f470f04f6a..9e80d449c7e 100644
> > > --- a/libstdc++-v3/include/bits/stl_tree.h
> > > +++ b/libstdc++-v3/include/bits/stl_tree.h
> > > @@ -1225,6 +1225,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > >size_type
> > >erase(const key_type& __x);
> > >
> > > +  size_type
> > > +  _M_erase_unique(const key_type& __x);
> > > +
> > >  #if __cplusplus >= 201103L
> > >// _GLIBCXX_RESOLVE_LIB_DEFECTS
> > >// DR 130. Associative erase should return an iterator.
> > > @@ -2518,6 +2521,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > >return __old_size - size();
> > >  }
> > >
> > > +  template > > +  typename _Compare, typename _Alloc>
> > > +typename _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, 
> > > _Alloc>::size_type
> > > +_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
> > > +_M_erase_unique(const _Key& __x)
> > > +{
> > > +  iterator __it = find(__x);
> > > +  if (__it == end())
> > > +   return 0;
> > > +
> > > +  _M_erase_aux(__it);
> > > +  return 1;
> > > +}
> > > +
> > >template > >typename _Compare, typename _Alloc>
> > >  typename _Rb_tree<_Key, _Val, _KeyOfValue,
> > > --
> > > 2.44.0
> > >
> > >
> >

[Bug libstdc++/115497] [15 Regression] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |15.0
   Last reconfirmed||2024-06-14
 Status|RESOLVED|NEW
Summary|__is_pointer doesn't|[15 Regression]
   |compile with clang since|__is_pointer doesn't
   |014879ea4c86b3b8ab6b61a1226 |compile with clang since
   |ee5b31e816c8b   |014879ea4c86b3b8ab6b61a1226
   ||ee5b31e816c8b
 Resolution|INVALID |---

--- Comment #7 from Andrew Pinski  ---
Note I think we should workaround this.

I only posted the clang issue because clang was acting inconsistent in its
handling and should be more consistent in there; not that libstdc++ should not
workaround the issue.

[Bug fortran/115491] Internal compiler error: in resolve_typebound_procedure, at fortran/resolve.cc:14913

[heinzell at ucar dot edu via Gcc-bugs]

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

--- Comment #2 from Dom Heinzeller  ---
(In reply to kargls from comment #1)
> (In reply to Dom Heinzeller from comment #0)
> > I am working on a fairly complicated modeling code used by the U.S. Naval
> > Research Lab and I am hitting internal compiler errors that prevent us from
> > using gcc. I tested versions 10 through 14 (14.1.0), all with the same
> > results. It's going to be complicated to resolve, since I cannot share the
> > code, but hopefully we can find a way to address the problem.
> 
> It seems you'll need to do some old fashion debugging for us.
> Compile your code.  With the problematic file that causes the ICE,
> you'll need to start commenting out chunks.  Hopefully, you
> can isolate a small example, which can then be posted here.

Thanks! That is what I started early today, and I do indeed have an update. I
can get the code to compile if I change the location of Fortran "use"
statements. Basically, it looks like this in the failing code:

module abc
...
end module abc

submodule (abc) def
contains
  module procedure xyz
use some_overloaded_procedure ! an interface for several type-bound
procedures
...
  end module procedure xyz
end submodule def

This code, however, works:

module abc
...
end module abc

submodule (abc) def
  use some_overloaded_procedure ! an interface for several type-bound
procedures
contains
  module procedure xyz
...
  end module procedure xyz
end submodule def

Results for 15.0.0 20240614 (experimental) [master r15-1347-ge5e341243bf] (GCC) testsuite on i686-pc-linux-gnu

[haochenj via Gcc-testresults]

86/vect-strided-3.c scan-assembler-times movq 4
FAIL: gcc.target/i386/vect-strided-4.c scan-assembler-times movhps 2
FAIL: gcc.target/i386/vect-strided-4.c scan-assembler-times movq 2
FAIL: gcc.target/i386/xorsign.c scan-tree-dump-times vect "vectorized 2 loops" 1

=== gcc Summary ===

# of expected passes197033
# of unexpected failures236
# of unexpected successes   27
# of expected failures  1501
# of unresolved testcases   114
# of unsupported tests  4218
/home/haochenj/src/gcc-regression/bld/gcc/xgcc  version 15.0.0 20240614 
(experimental) [master r15-1347-ge5e341243bf] (GCC) 

=== gfortran tests ===


Running target unix
UNRESOLVED: gfortran.dg/weak-1.f90   -O 
UNRESOLVED: gfortran.dg/weak-2.f90   -O 
UNRESOLVED: gfortran.dg/weak-3.f90   -O 

    === gfortran Summary ===

# of expected passes70188
# of expected failures  275
# of unresolved testcases   3
# of unsupported tests  233
/home/haochenj/src/gcc-regression/bld/gcc/gfortran  version 15.0.0 20240614 
(experimental) [master r15-1347-ge5e341243bf] (GCC) 

=== g++ tests ===


Running target unix
UNRESOLVED: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++14
UNRESOLVED: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++17
UNRESOLVED: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++20
UNRESOLVED: g++.dg/debug/dwarf2/inline-var-1.C  -std=gnu++98
UNRESOLVED: g++.dg/debug/dwarf2/inline-var-2.C  -std=gnu++14
UNRESOLVED: g++.dg/debug/dwarf2/inline-var-2.C  -std=gnu++17
UNRESOLVED: g++.dg/debug/dwarf2/inline-var-2.C  -std=gnu++20
UNRESOLVED: g++.dg/debug/dwarf2/inline-var-2.C  -std=gnu++98
UNRESOLVED: g++.dg/debug/dwarf2/inline-var-3.C  -std=gnu++14
UNRESOLVED: g++.dg/debug/dwarf2/inline-var-3.C  -std=gnu++17
UNRESOLVED: g++.dg/debug/dwarf2/inline-var-3.C  -std=gnu++20
UNRESOLVED: g++.dg/debug/dwarf2/inline-var-3.C  -std=gnu++98
UNRESOLVED: c-c++-common/Waddress-5.c  -std=gnu++14
UNRESOLVED: c-c++-common/Waddress-5.c  -std=gnu++17
UNRESOLVED: c-c++-common/Waddress-5.c  -std=gnu++20
UNRESOLVED: c-c++-common/Waddress-5.c  -std=gnu++98
UNRESOLVED: g++.dg/abi/anon2.C  -std=c++14
UNRESOLVED: g++.dg/abi/anon2.C  -std=c++17
UNRESOLVED: g++.dg/abi/anon2.C  -std=c++20
UNRESOLVED: g++.dg/abi/anon2.C  -std=c++98
UNRESOLVED: g++.dg/abi/anon3.C  -std=c++14
UNRESOLVED: g++.dg/abi/anon3.C  -std=c++17
UNRESOLVED: g++.dg/abi/anon3.C  -std=c++20
UNRESOLVED: g++.dg/abi/anon3.C  -std=c++98
UNRESOLVED: g++.dg/abi/mangle40.C  -std=gnu++14
UNRESOLVED: g++.dg/abi/mangle40.C  -std=gnu++17
UNRESOLVED: g++.dg/abi/mangle40.C  -std=gnu++20
UNRESOLVED: g++.dg/abi/mangle40.C  -std=gnu++98
UNRESOLVED: g++.dg/abi/rtti3.C  -std=c++14
UNRESOLVED: g++.dg/abi/rtti3.C  -std=c++17
UNRESOLVED: g++.dg/abi/rtti3.C  -std=c++20
UNRESOLVED: g++.dg/abi/rtti3.C  -std=c++98
UNRESOLVED: g++.dg/abi/thunk3.C  -std=c++14
UNRESOLVED: g++.dg/abi/thunk3.C  -std=c++17
UNRESOLVED: g++.dg/abi/thunk3.C  -std=c++20
UNRESOLVED: g++.dg/abi/thunk3.C  -std=c++98
UNRESOLVED: g++.dg/abi/thunk4.C  -std=c++14
UNRESOLVED: g++.dg/abi/thunk4.C  -std=c++17
UNRESOLVED: g++.dg/abi/thunk4.C  -std=c++20
UNRESOLVED: g++.dg/abi/thunk4.C  -std=c++98
UNRESOLVED: g++.dg/abi/thunk5.C  -std=c++14
UNRESOLVED: g++.dg/abi/thunk5.C  -std=c++17
UNRESOLVED: g++.dg/abi/thunk5.C  -std=c++20
UNRESOLVED: g++.dg/abi/thunk5.C  -std=c++98
UNRESOLVED: g++.dg/cpp0x/lambda/lambda-mangle.C  -std=gnu++14
UNRESOLVED: g++.dg/cpp0x/lambda/lambda-mangle.C  -std=gnu++17
UNRESOLVED: g++.dg/cpp0x/lambda/lambda-mangle.C  -std=gnu++20
UNRESOLVED: g++.dg/cpp0x/lambda/lambda-mangle.C  -std=gnu++98
UNRESOLVED: g++.dg/cpp0x/lambda/lambda-mangle6.C  -std=gnu++14
UNRESOLVED: g++.dg/cpp0x/lambda/lambda-mangle6.C  -std=gnu++17
UNRESOLVED: g++.dg/cpp0x/lambda/lambda-mangle6.C  -std=gnu++20
UNRESOLVED: g++.dg/cpp0x/lambda/lambda-mangle6.C  -std=gnu++98
UNRESOLVED: g++.dg/cpp0x/pr84497.C  -std=c++14
UNRESOLVED: g++.dg/cpp0x/pr84497.C  -std=c++17
UNRESOLVED: g++.dg/cpp0x/pr84497.C  -std=c++20
UNRESOLVED: g++.dg/cpp0x/pr84497.C  -std=c++98
UNRESOLVED: g++.dg/cpp1z/decomp41.C  -std=gnu++14
UNRESOLVED: g++.dg/cpp1z/decomp41.C  -std=gnu++17
UNRESOLVED: g++.dg/cpp1z/decomp41.C  -std=gnu++20
UNRESOLVED: g++.dg/cpp1z/decomp41.C  -std=gnu++98
UNRESOLVED: g++.dg/cpp1z/inline-var1.C  -std=gnu++14
UNRESOLVED: g++.dg/cpp1z/inline-var1.C  -std=gnu++17
UNRESOLVED: g++.dg/cpp1z/inline-var1.C  -std=gnu++20
UNRESOLVED: g++.dg/cpp1z/inline-var1.C  -std=gnu++98
UNRESOLVED: g++.dg/cpp2a/lambda-mangle.C  -std=gnu++14
UNRESOLVED: g++.dg/cpp2a/lambda-mangle.C  -std=gnu++17
UNRESOLVED: g++.dg/cpp2a/lambda-mangle.C  -std=gnu++20
UNRESOLVED: g++.dg/cpp2a/lambda-mangle.C  -std=gnu++98
UNRESOLVED: g++.dg/eh/ia64-2.C  -std=gnu++14
UNRESOLVED: g++.dg/eh/ia64-2.C  -std=gnu++17
UNRESOLVED: g++.dg/eh/ia64-2.C  -std=gnu++20
UNRESOLVED: g++.dg/eh/ia64-2.C  -std=gnu++98
UNRESOLVED: g++.dg/eh/weak1.C  -std=gnu++14
UNRESOLVED: g++.dg/eh/weak1.C  -std=gnu++17
UNRESOLVED: g++.d

[PATCH] riscv: Allocate enough space to strcpy() string

[Christoph Müllner]

I triggered an ICE on Ubuntu 24.04 when compiling code that uses
function attributes. Looking into the sources shows that we have
a systematic issue in the attribute handling code:
* we determine the length with strlen() (excluding the terminating null)
* we allocate a buffer with this length
* we copy the original string using strcpy() (incl. the terminating null)

To quote the man page of strcpy():
"The programmer is responsible for allocating a  destination  buffer
large  enough,  that  is, strlen(src)  + 1."

The ICE looks like this:

*** buffer overflow detected ***: terminated
xtheadmempair_bench.c:14:1: internal compiler error: Aborted
   14 | {
  | ^
0xaf3b99 crash_signal
/home/ubuntu/src/gcc/scaleff/gcc/toplev.cc:319
0xe5b957 strcpy
/usr/include/riscv64-linux-gnu/bits/string_fortified.h:79
0xe5b957 riscv_process_target_attr
/home/ubuntu/src/gcc/scaleff/gcc/config/riscv/riscv-target-attr.cc:339
0xe5baaf riscv_process_target_attr
/home/ubuntu/src/gcc/scaleff/gcc/config/riscv/riscv-target-attr.cc:314
0xe5bc5f riscv_option_valid_attribute_p(tree_node*, tree_node*, tree_node*, int)
/home/ubuntu/src/gcc/scaleff/gcc/config/riscv/riscv-target-attr.cc:389
0x6a31e5 handle_target_attribute
/home/ubuntu/src/gcc/scaleff/gcc/c-family/c-attribs.cc:5915
0x5d3a07 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/home/ubuntu/src/gcc/scaleff/gcc/attribs.cc:900
0x5db403 c_decl_attributes
/home/ubuntu/src/gcc/scaleff/gcc/c/c-decl.cc:5501
0x5e8965 start_function(c_declspecs*, c_declarator*, tree_node*)
/home/ubuntu/src/gcc/scaleff/gcc/c/c-decl.cc:10562
0x6318ed c_parser_declaration_or_fndef
/home/ubuntu/src/gcc/scaleff/gcc/c/c-parser.cc:2914
0x63a8ad c_parser_external_declaration
/home/ubuntu/src/gcc/scaleff/gcc/c/c-parser.cc:2048
0x63b219 c_parser_translation_unit
/home/ubuntu/src/gcc/scaleff/gcc/c/c-parser.cc:1902
0x63b219 c_parse_file()
/home/ubuntu/src/gcc/scaleff/gcc/c/c-parser.cc:27277
0x68fec5 c_common_parse_file()
/home/ubuntu/src/gcc/scaleff/gcc/c-family/c-opts.cc:1311
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.

gcc/ChangeLog:

* config/riscv/riscv-target-attr.cc 
(riscv_target_attr_parser::parse_arch):
Fix allocation size of buffer.
(riscv_process_one_target_attr): Likewise.
(riscv_process_target_attr): Likewise.

Signed-off-by: Christoph Müllner 
---
 gcc/config/riscv/riscv-target-attr.cc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/config/riscv/riscv-target-attr.cc 
b/gcc/config/riscv/riscv-target-attr.cc
index 1a73d69bf50..19eb7b06d54 100644
--- a/gcc/config/riscv/riscv-target-attr.cc
+++ b/gcc/config/riscv/riscv-target-attr.cc
@@ -109,7 +109,7 @@ riscv_target_attr_parser::parse_arch (const char *str)
 {
   /* Parsing the extension list like "+[,+]*".  */
   size_t len = strlen (str);
-  std::unique_ptr buf (new char[len]);
+  std::unique_ptr buf (new char[len+1]);
   char *str_to_check = buf.get ();
   strcpy (str_to_check, str);
   const char *token = strtok_r (str_to_check, ",", _to_check);
@@ -247,7 +247,7 @@ riscv_process_one_target_attr (char *arg_str,
   return false;
 }
 
-  std::unique_ptr buf (new char[len]);
+  std::unique_ptr buf (new char[len+1]);
   char *str_to_check = buf.get();
   strcpy (str_to_check, arg_str);
 
@@ -334,7 +334,7 @@ riscv_process_target_attr (tree fndecl, tree args, 
location_t loc,
   return false;
 }
 
-  std::unique_ptr buf (new char[len]);
+  std::unique_ptr buf (new char[len+1]);
   char *str_to_check = buf.get ();
   strcpy (str_to_check, TREE_STRING_POINTER (args));
 
-- 
2.45.1

[Bug libstdc++/115497] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Mital Ashok from comment #4)
> Forcing it to be an expression in the first place does let it compile:
> 
> template
>   struct is_pointer : ts(__is_pointer(_Tp))> {};

Ah nice, we can do that

[Bug libstdc++/115497] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

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

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

--- Comment #5 from Jonathan Wakely  ---
I suppose we can just include  at the top of
, we could even make that conditional on __clang__

[Bug libstdc++/115497] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

[mital at mitalashok dot co.uk via Gcc-bugs]

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

Mital Ashok  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Mital Ashok  ---
It appears that Clang is parsing it as a broken function type, but it should
then retry parsing as an expression.

Forcing it to be an expression in the first place does let it compile:

template
  struct is_pointer : ts(__is_pointer(_Tp))> {};

Results for 15.0.0 20240614 (experimental) [master r15-1347-ge5e341243bf] (GCC) testsuite on x86_64-pc-linux-gnu

[haochenj--- via Gcc-testresults]

ot; * 2" 1
FAIL: gcc.dg/vect/slp-perm-9.c -flto -ffat-lto-objects  scan-tree-dump-times 
vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-perm-9.c scan-tree-dump-times vect "vectorizing stmts 
using SLP" 1
XPASS: gcc.dg/vect/vect-reduc-in-order-1.c -flto -ffat-lto-objects execution 
test
XPASS: gcc.dg/vect/vect-reduc-in-order-1.c execution test
XPASS: gcc.dg/vect/vect-reduc-in-order-2.c -flto -ffat-lto-objects execution 
test
XPASS: gcc.dg/vect/vect-reduc-in-order-2.c execution test
XPASS: gcc.dg/vect/vect-reduc-in-order-3.c -flto -ffat-lto-objects execution 
test
XPASS: gcc.dg/vect/vect-reduc-in-order-3.c execution test
XPASS: gcc.dg/vect/vect-reduc-in-order-4.c -flto -ffat-lto-objects execution 
test
XPASS: gcc.dg/vect/vect-reduc-in-order-4.c execution test
FAIL: gcc.target/i386/avx512bw-vmovdqu16-1.c scan-assembler-times 
(?:vmovdqu16|vextracti128)[ t]+[^{\\n]*%ymm[0-9]+[^\\n]*)(?:\\n|[ 
t]+#) 1
FAIL: gcc.target/i386/avx512bw-vmovdqu16-1.c scan-assembler-times 
(?:vmovdqu16|vinserti128)[ t]+[^{\\n]*)[^\\n]*%ymm[0-9]+(?:\\n|[ 
t]+#) 1
FAIL: gcc.target/i386/avx512dq-pr88465.c scan-assembler-times kxnorb[ \\t] 1
FAIL: gcc.target/i386/avx512f-pr88465.c scan-assembler-times kxnorw[ \\t] 1
FAIL: gcc.target/i386/avx512fp16-13.c scan-assembler-times vmovdqu16[ 
t]*[^,]*,[^{\\n]*%xmm[0-9] 1
FAIL: gcc.target/i386/avx512fp16-13.c scan-assembler-times vmovdqu16[ 
t]*[^,]*,[^{\\n]*%ymm[0-9] 1
FAIL: gcc.target/i386/avx512fp16-13.c scan-assembler-times vmovdqu16[ 
t]*[^{\\n]*%xmm[0-9], *[^,]* 1
FAIL: gcc.target/i386/avx512fp16-13.c scan-assembler-times vmovdqu16[ 
t]*[^{\\n]*%ymm[0-9], *[^,]* 1
XPASS: gcc.target/i386/bitwise_mask_op-3.c scan-assembler-times kmovb[\\t ] 4
XPASS: gcc.target/i386/bitwise_mask_op-3.c scan-assembler-times korb[\\t ] 1
XPASS: gcc.target/i386/bitwise_mask_op-3.c scan-assembler-times kxorb[\\t ] 1
FAIL: gcc.target/i386/minmax-10.c scan-assembler-not cmp
FAIL: gcc.target/i386/minmax-10.c scan-assembler-times test 6
FAIL: gcc.target/i386/pieces-memset-11.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-14.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-2.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-20.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-23.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-29.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-30.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-33.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-34.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-37.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-44.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-5.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pr31985.c scan-assembler-times movl 4
FAIL: gcc.target/i386/pr95483-5.c scan-assembler-times 
(?:vmovdqu8|vextracti128)[ t]+[^{\\n]*%ymm[0-9]+[^\\n]*)(?:\\n|[ 
t]+#) 1
FAIL: gcc.target/i386/pr95483-5.c scan-assembler-times 
(?:vmovdqu8|vinserti128)[ t]+[^{\\n]*)[^\\n]*%ymm[0-9]+(?:\\n|[ 
t]+#) 1
FAIL: gcc.target/i386/pr95483-6.c scan-assembler-times (?:vinserti128|vmovdqu)[ 
t]+[^{\\n]*)[^\\n]*%ymm[0-9]+(?:\\n|[ t]+#) 2
FAIL: gcc.target/i386/pr97873-1.c scan-assembler pabsq
FAIL: gcc.target/i386/vect-double-2.c scan-tree-dump-times vect "Vectorized 
loops: 1" 1
FAIL: gcc.target/i386/vect-shiftv4qi.c scan-assembler-times psrlw 5
FAIL: gcc.target/i386/vect-strided-3.c scan-assembler-times movq 4
FAIL: gcc.target/i386/xorsign.c scan-tree-dump-times vect "vectorized 2 loops" 1

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

# of expected passes198421
# of unexpected failures159
# of unexpected successes   30
# of expected failures  1551
# of unsupported tests  4098

=== gcc Summary ===

# of expected passes403214
# of unexpected failures318
# of unexpected successes   50
# of expected failures  3096
# of unsupported tests  7408
/export/home/haochenj/src/gcc-regression/bld/gcc/xgcc  version 15.0.0 20240614 
(experimental) [master r15-1347-ge5e341243bf] (GCC) 

=== gfortran tests ===


Running target unix

=== gfortran Summary for unix ===

# of expected passes70552
# of expected failures  273
# of unsupported tests  65

Running target unix/-m32

=== gfortran Summary for unix/-m32 ===

# of expected passes70206
# of expected failures  275
# of unsupp

Regressions on master at commit r15-1347 vs commit r15-1342 on Linux/x86_64

[Haochen Jiang via Gcc-regression]

Regressions on master at commit r15-1347 vs commit r15-1342 on Linux/x86_64
New failures:
FAIL: 30_threads/async/async.cc  -std=gnu++17 execution test

New passes:

Re: [PATCH v26 03/13] libstdc++: Optimize std::is_pointer compilation performance

[Andrew Pinski]

On Thu, Jun 13, 2024 at 5:32 AM Jonathan Wakely  wrote:
>
> On 11/05/24 02:01 -0700, Ken Matsui wrote:
> >This patch optimizes the compilation performance of std::is_pointer
> >by dispatching to the new __is_pointer built-in trait.
> >
> >libstdc++-v3/ChangeLog:
> >
> >   * include/bits/cpp_type_traits.h (__is_pointer): Use
> >   __is_pointer built-in trait.  Optimize its implementation.
> >   * include/std/type_traits (is_pointer): Likewise.
> >   (is_pointer_v): Likewise.
> >
> >Co-authored-by: Jonathan Wakely 
> >Signed-off-by: Ken Matsui 
> >---
> > libstdc++-v3/include/bits/cpp_type_traits.h | 31 ++-
> > libstdc++-v3/include/std/type_traits| 44 +
> > 2 files changed, 66 insertions(+), 9 deletions(-)
> >
> >diff --git a/libstdc++-v3/include/bits/cpp_type_traits.h 
> >b/libstdc++-v3/include/bits/cpp_type_traits.h
> >index 59f1a1875eb..210a9ea00da 100644
> >--- a/libstdc++-v3/include/bits/cpp_type_traits.h
> >+++ b/libstdc++-v3/include/bits/cpp_type_traits.h
> >@@ -363,6 +363,13 @@ __INT_N(__GLIBCXX_TYPE_INT_N_3)
> >   //
> >   // Pointer types
> >   //
> >+#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_pointer)
> >+  template
> >+struct __is_pointer : __truth_type<_IsPtr>
>
> I was worried that reusing __is_pointer this way would cause a problem
> with Clang, because it has an __is_pointer built-in and the code above
> causes a warning:
>
> isp.cc:2:12: warning: keyword '__is_pointer' will be made available as an 
> identifier for the remainder of the translation unit [-Wkeyword-compat]
>  2 | struct __is_pointer
>|^
>
> I thought this warning meant it was only available as an identifier.
> But in fact it becomes available as both an identifier and as the
> built-in.
>
> This is what I tested:
>
> template
> struct __is_pointer
> {
>enum { value = IsPtr };
> };
> static_assert( __is_pointer::value, "" );
>
> template
> struct is_pointer
> {
>static constexpr bool value = __is_pointer(T);
> };
> static_assert( is_pointer::value, "" );
>
> So the is_pointer template can still use the built-in even though the
> name '__is_pointer' has been declared as an identifier.
>
> So Clang matches GCC and it works fine. Good!

Actually clang does not work the same as GCC in the end; it is much
more inconsistent in what it allows.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497 (and
https://github.com/llvm/llvm-project/issues/95598). Where sometimes
the usage works as a trait after the use of it as an identifier and
sometimes it fails.

Thanks,
Andrew Pinski

>
> >+{
> >+  enum { __value = _IsPtr };
> >+};
> >+#else
> >   template
> > struct __is_pointer
> > {
> >@@ -377,6 +384,28 @@ __INT_N(__GLIBCXX_TYPE_INT_N_3)
> >   typedef __true_type __type;
> > };
> >
> >+  template
> >+struct __is_pointer<_Tp* const>
>
> None of the other traits in bits/cpp_type_traits.h is true for
> cv-qualified types, so these partial specializations make __is_pointer
> the odd one out. Are they necessary?
>
> >+{
> >+  enum { __value = 1 };
> >+  typedef __true_type __type;
> >+};
> >+
> >+  template
> >+struct __is_pointer<_Tp* volatile>
> >+{
> >+  enum { __value = 1 };
> >+  typedef __true_type __type;
> >+};
> >+
> >+  template
> >+struct __is_pointer<_Tp* const volatile>
> >+{
> >+  enum { __value = 1 };
> >+  typedef __true_type __type;
> >+};
> >+#endif
> >+
> >   //
> >   // An arithmetic type is an integer type or a floating point type
> >   //
> >@@ -387,7 +416,7 @@ __INT_N(__GLIBCXX_TYPE_INT_N_3)
> >
> >   //
> >   // A scalar type is an arithmetic type or a pointer type
> >-  //
> >+  //
> >   template
> > struct __is_scalar
> > : public __traitor<__is_arithmetic<_Tp>, __is_pointer<_Tp> >
> >diff --git a/libstdc++-v3/include/std/type_traits 
> >b/libstdc++-v3/include/std/type_traits
> >index 748fa186881..ea013b4b7bc 100644
> >--- a/libstdc++-v3/include/std/type_traits
> >+++ b/libstdc++-v3/include/std/type_traits
> >@@ -542,19 +542,33 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > : public true_type { };
> > #endif
> >
> >-  template
> >-struct __is_pointer_helper
> >+  /// is_pointer
> >+#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_pointer)
> >+  template
> >+struct is_pointer
> >+: public __bool_constant<__is_pointer(_Tp)>
> >+{ };
> >+#else
> >+  template
> >+struct is_pointer
> > : public false_type { };
> >
> >   template
> >-struct __is_pointer_helper<_Tp*>
> >+struct is_pointer<_Tp*>
> > : public true_type { };
> >
> >-  /// is_pointer
> >   template
> >-struct is_pointer
> >-: public __is_pointer_helper<__remove_cv_t<_Tp>>::type
> >-{ };
> >+struct is_pointer<_Tp* const>
> >+: public true_type { };
> >+
> >+  template
> >+struct is_pointer<_Tp* volatile>
> >+: public true_type { };
> >+
> >+  template
> >+struct is_pointer<_Tp* const volatile>
> >+: public true_type { };
> 

[Bug libstdc++/115497] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/llvm/llv
   ||m-project/issues/95598

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> clang does not complain about the use of __is_pointer for variable template
> t but does for the base class of is_pointer.

Filed that as https://github.com/llvm/llvm-project/issues/95598

[Bug c/115496] RFE: new warning to detect suspicious multiline string literals

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

--- Comment #6 from Andi Kleen  ---
Yes a # check would need to be target dependent.

Re: [Patch, fortran] PR59104

[Harald Anlauf]

Hi Paul,

this looks good to me and is OK for mainline.  When it has survived a
week or two, backporting at least to 14-branch (ideally before 14.2
release) would be a good thing!

Regarding the following excerpt of the testcase:

+! Commented out lines give implicit type warnings with gfortran and nagfor
+!character(len = len (d)) :: line4 (len (line3))
+character(len = len (line3)) :: line4 (len (line3))
+!character(len = size(len4, 1)) :: line5

I guess the last commented line should have referred to size(line4, 1),
right?  The lexical distance of len4 and line4 can be small after
long coding...

The first commented line gives no warning here, but is simply
inconsistent with a test later on, since len (d) < len (line3).
What exactly was the issue?

***

A minor nit: while you were fixing whitespace issues in the source,
you missed an indent with spaces here:

@@ -857,12 +873,26 @@ gfc_defer_symbol_init (gfc_symbol * sym)
   /* Find the first dummy arg seen after us, or the first
non-dummy arg.
  This is a circular list, so don't go past the head.  */
   while (p != head
- && (!p->attr.dummy || p->dummy_order > sym->dummy_order))
+ && (!p->attr.dummy || decl_order (p, sym)))
 {

At least on my side there is no tab...
(It is fine in a similar code later on.)

***

Finally a big thanks for the patch!

Harald


Am 13.06.24 um 23:43 schrieb Paul Richard Thomas:

Hi Both,

Thanks for the highly constructive comments. I think that I have
incorporated them fully in the attached.

OK for mainline and ...?

Paul


On Mon, 10 Jun 2024 at 08:19, Andre Vehreschild  wrote:


Hi Paul,

while looking at your patch I see calls to gfc_add_init_cleanup (...,
back),
while the function signature is gfc_add_init_cleanup (..., bool front).
This
slightly confuses me. I would at least expect to see
gfc_add_init_cleanup(...,
!back) calls. Just to get the semantics right.

Then I wonder why not doing:

diff --git a/gcc/fortran/dependency.cc b/gcc/fortran/dependency.cc
index bafe8cbc5bc..97ace8c778e 100644
--- a/gcc/fortran/dependency.cc
+++ b/gcc/fortran/dependency.cc
@@ -2497,3 +2497,63 @@ gfc_omp_expr_prefix_same (gfc_expr *lexpr, gfc_expr
*rexpr)
return true;
  }
+
+
+/* gfc_function_dependency returns true for non-dummy symbols with
dependencies
+   on an old-fashioned function result (ie. proc_name =
proc_name->result).
+   This is used to ensure that initialization code appears after the
function
+   result is treated and that any mutual dependencies between these
symbols are
+   respected.  */
+
+static bool
+dependency_fcn (gfc_expr *e, gfc_symbol *sym,
+int *f ATTRIBUTE_UNUSED)
+{
+  return (e && e->expr_type == EXPR_VARIABLE
+  && e->symtree
+  && e->symtree->n.sym == sym);
+}

Instead of the multiple if-statements?

+
+bool
+gfc_function_dependency (gfc_symbol *sym, gfc_symbol *proc_name)
+{
+  bool front = false;
+
+  if (proc_name && proc_name->attr.function
+  && proc_name == proc_name->result
+  && !(sym->attr.dummy || sym->attr.result))
+{
+  if (sym->as && sym->as->type == AS_EXPLICIT)
+   {
+ for (int dim = 0; dim < sym->as->rank; dim++)
+   {
+ if (sym->as->lower[dim]
+ && sym->as->lower[dim]->expr_type != EXPR_CONSTANT)
+   front = gfc_traverse_expr (sym->as->lower[dim], proc_name,
+  dependency_fcn, 0);
+ if (front)
+   break;
+ if (sym->as->upper[dim]
+ && sym->as->upper[dim]->expr_type != EXPR_CONSTANT)
+   front = gfc_traverse_expr (sym->as->upper[dim], proc_name,
+  dependency_fcn, 0);
+ if (front)
+   break;
+   }
+   }
+
+  if (sym->ts.type == BT_CHARACTER
+ && sym->ts.u.cl && sym->ts.u.cl->length
+ && sym->ts.u.cl->length->expr_type != EXPR_CONSTANT)
+   front = gfc_traverse_expr (sym->ts.u.cl->length, proc_name,
+  dependency_fcn, 0);

This can overwrite a previous front == true, right? Is this intended?

+}
+  return front;
+ }

The rest - besides the front-back confusion - looks fine to me. Thanks for
the
patch.

Regards,
 Andre

On Sun, 9 Jun 2024 07:14:39 +0100
Paul Richard Thomas  wrote:


Hi All,

The attached fixes a problem that, judging by the comments, has been

looked

at periodically over the last ten years but just looked to be too
fiendishly complicated to fix. This is not in small part because of the
confusing ordering of dummies in the tlink chain and the unintuitive
placement of all deferred initializations to the front of the init chain

in

the wrapped block.

The result of the existing ordering is that the initialization code for
non-dummy variables that depends on the function result occurs before any
initialization code for the function result itself. The fix 

[Bug c/115496] RFE: new warning to detect suspicious multiline string literals

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||87403
   Severity|normal  |enhancement


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug c/115496] RFE: new warning to detect suspicious multiline string literals

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

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

--- Comment #5 from Andrew Pinski  ---
# can also start a number in aarch64 and arm assembly and not a comment.

So NO `#` is not universally starts a comment.

[Bug libstdc++/115497] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

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

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

--- Comment #2 from Andrew Pinski  ---
Ok, clang behavior is an odd one here:
```
template
  struct __is_pointer {};

template
inline bool t = __is_pointer(_Tp);

template
struct ts{};

template
  struct is_pointer : ts<__is_pointer(_Tp)> {};

int tt = t;
```

clang does not complain about the use of __is_pointer for variable template t
but does for the base class of is_pointer.

[Bug c/115496] RFE: new warning to detect suspicious multiline string literals

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

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

--- Comment #4 from David Malcolm  ---
A possible input to the logic could be: be more paranoid about strings that
will be used by inline asm.

(In reply to Andi Kleen from comment #3)
> When writing inline assembler an alternative to \n is to use ; as separator
> 
> e.g.
> 
> asm("movl $1,%eax ; "
> "movl %eax,%ebx")
> 
> there can be also comment mistake here like
> 
> 
> asm("movl $1,%eax # comment ;"
> "movl %eax,%ebx"); 
>  
> This incorrectly drops the second instruction. The \n warning wouldn't
> handle that case, it would need knowledge about # comments.

Yeah.  However we've traditionally avoided looking within the body of the
inline assembler.

I wonder if the use of '#' and ';' in asm sufficiently standardized to be
checkable (or if this way lies madness)

[Bug libstdc++/115497] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

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

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654499.html

[Bug c/115496] RFE: new warning to detect suspicious multiline string literals

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

--- Comment #3 from Andi Kleen  ---
When writing inline assembler an alternative to \n is to use ; as separator

e.g.

asm("movl $1,%eax ; "
"movl %eax,%ebx")

there can be also comment mistake here like


asm("movl $1,%eax # comment ;"
"movl %eax,%ebx"); 

This incorrectly drops the second instruction. The \n warning wouldn't handle
that case, it would need knowledge about # comments.

I've hit that problem in some real code. Always preferred to write ; over \n
because it looks less ugly.

[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
(In reply to Kewen Lin from comment #9)
> Since it's a breakage during stage2, it's concluded that some built stage1
> stuffs behave unexpectedly.  You probably can try to run regression testing
> just with stage1 compiler to see if there is any regression exposed.
> 
> If without any luck, then you probably have to isolate into one or several
> object files, since you have "objects" for "good" and "bad" stage1 compiler,
> you can be able to isolate some in between further. Once you get some
> isolated, you can probably get some hints it's a bug in LLVM source or gcc.

Thanks. This sounds like a good idea. I will try to identify the object files
that differ.

> It seems you are using gcc 13.2.1 as version field shows, you can also try
> some previous versions like gcc 12 and gcc 11 to see if they work and it's
> regressed.

I have tried all GCC versions down to GCC 9 now but it still reproduces.

Before testing your first suggestion, I will perform a test on SUSE Linux
Enterprise 15 which ships with GCC 7 as the default C/C++ compiler.

Results for 15.0.0 20240614 (experimental) [master r15-1331-g4b1f486fefb] (GCC) testsuite on x86_64-pc-linux-gnu

[haochenj--- via Gcc-testresults]

-assembler-times and|test 20
FAIL: gcc.dg/tree-ssa/slsr-31.c scan-tree-dump-times optimized " * 2" 1
FAIL: gcc.dg/vect/slp-perm-9.c -flto -ffat-lto-objects  scan-tree-dump-times 
vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-perm-9.c scan-tree-dump-times vect "vectorizing stmts 
using SLP" 1
XPASS: gcc.dg/vect/vect-reduc-in-order-1.c -flto -ffat-lto-objects execution 
test
XPASS: gcc.dg/vect/vect-reduc-in-order-1.c execution test
XPASS: gcc.dg/vect/vect-reduc-in-order-2.c -flto -ffat-lto-objects execution 
test
XPASS: gcc.dg/vect/vect-reduc-in-order-2.c execution test
XPASS: gcc.dg/vect/vect-reduc-in-order-3.c -flto -ffat-lto-objects execution 
test
XPASS: gcc.dg/vect/vect-reduc-in-order-3.c execution test
XPASS: gcc.dg/vect/vect-reduc-in-order-4.c -flto -ffat-lto-objects execution 
test
XPASS: gcc.dg/vect/vect-reduc-in-order-4.c execution test
FAIL: gcc.target/i386/avx512bw-vmovdqu16-1.c scan-assembler-times 
(?:vmovdqu16|vextracti128)[ t]+[^{\\n]*%ymm[0-9]+[^\\n]*)(?:\\n|[ 
t]+#) 1
FAIL: gcc.target/i386/avx512bw-vmovdqu16-1.c scan-assembler-times 
(?:vmovdqu16|vinserti128)[ t]+[^{\\n]*)[^\\n]*%ymm[0-9]+(?:\\n|[ 
t]+#) 1
FAIL: gcc.target/i386/avx512dq-pr88465.c scan-assembler-times kxnorb[ \\t] 1
FAIL: gcc.target/i386/avx512f-pr88465.c scan-assembler-times kxnorw[ \\t] 1
FAIL: gcc.target/i386/avx512fp16-13.c scan-assembler-times vmovdqu16[ 
t]*[^,]*,[^{\\n]*%xmm[0-9] 1
FAIL: gcc.target/i386/avx512fp16-13.c scan-assembler-times vmovdqu16[ 
t]*[^,]*,[^{\\n]*%ymm[0-9] 1
FAIL: gcc.target/i386/avx512fp16-13.c scan-assembler-times vmovdqu16[ 
t]*[^{\\n]*%xmm[0-9], *[^,]* 1
FAIL: gcc.target/i386/avx512fp16-13.c scan-assembler-times vmovdqu16[ 
t]*[^{\\n]*%ymm[0-9], *[^,]* 1
XPASS: gcc.target/i386/bitwise_mask_op-3.c scan-assembler-times kmovb[\\t ] 4
XPASS: gcc.target/i386/bitwise_mask_op-3.c scan-assembler-times korb[\\t ] 1
XPASS: gcc.target/i386/bitwise_mask_op-3.c scan-assembler-times kxorb[\\t ] 1
FAIL: gcc.target/i386/minmax-10.c scan-assembler-not cmp
FAIL: gcc.target/i386/minmax-10.c scan-assembler-times test 6
FAIL: gcc.target/i386/pieces-memset-11.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-14.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-2.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-20.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-23.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-29.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-30.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-33.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-34.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-37.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 2
FAIL: gcc.target/i386/pieces-memset-44.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pieces-memset-5.c scan-assembler-times vmovdqu[ 
t]+[^\\n]*%ymm 1
FAIL: gcc.target/i386/pr31985.c scan-assembler-times movl 4
FAIL: gcc.target/i386/pr95483-5.c scan-assembler-times 
(?:vmovdqu8|vextracti128)[ t]+[^{\\n]*%ymm[0-9]+[^\\n]*)(?:\\n|[ 
t]+#) 1
FAIL: gcc.target/i386/pr95483-5.c scan-assembler-times 
(?:vmovdqu8|vinserti128)[ t]+[^{\\n]*)[^\\n]*%ymm[0-9]+(?:\\n|[ 
t]+#) 1
FAIL: gcc.target/i386/pr95483-6.c scan-assembler-times (?:vinserti128|vmovdqu)[ 
t]+[^{\\n]*)[^\\n]*%ymm[0-9]+(?:\\n|[ t]+#) 2
FAIL: gcc.target/i386/pr97873-1.c scan-assembler pabsq
FAIL: gcc.target/i386/vect-double-2.c scan-tree-dump-times vect "Vectorized 
loops: 1" 1
FAIL: gcc.target/i386/vect-shiftv4qi.c scan-assembler-times psrlw 5
FAIL: gcc.target/i386/vect-strided-3.c scan-assembler-times movq 4
FAIL: gcc.target/i386/xorsign.c scan-tree-dump-times vect "vectorized 2 loops" 1

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

# of expected passes198421
# of unexpected failures159
# of unexpected successes   30
# of expected failures  1551
# of unsupported tests  4098

=== gcc Summary ===

# of expected passes403213
# of unexpected failures319
# of unexpected successes   50
# of expected failures  3096
# of unsupported tests  7408
/export/home/haochenj/src/gcc-regression/bld/gcc/xgcc  version 15.0.0 20240614 
(experimental) [master r15-1331-g4b1f486fefb] (GCC) 

=== gfortran tests ===


Running target unix

=== gfortran Summary for unix ===

# of expected passes70552
# of expected failures  273
# of unsupported tests  65

Running target unix/-m32

=== gfortran Summary for unix

[Bug c/115496] RFE: new warning to detect suspicious multline string literals

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

--- Comment #2 from Andi Kleen  ---
It would need some heuristic that if the line nearly fills a standard line
length (how defined) don't trigger it. Otherwise people breaking the string due
to line length restrictions might trigger it incorrectly.

[Bug c/115496] RFE: new warning to detect suspicious multline string literals

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

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

--- Comment #1 from David Malcolm  ---
gcc's diagnostic-show-locus.cc has lots of examples of such literals (in the
selftests)

[Bug libstdc++/115497] New: __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

[mital at mitalashok dot co.uk via Gcc-bugs]

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

Bug ID: 115497
   Summary: __is_pointer doesn't compile with clang since
014879ea4c86b3b8ab6b61a1226ee5b31e816c8b
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mital at mitalashok dot co.uk
  Target Milestone: ---

In libstdc++-v3/include/bits/cpp_type_traits.h, `__is_pointer` is both used as
a unary type trait and the name of a template struct. After it is a struct
template's name, Clang no longer parses it as a builtin and `inline constexpr
bool is_pointer_v = __is_pointer(_Tp);` in libstdc++-v3/include/std/type_traits
fails to compile.

This only happens if cpp_type_traits.h is included before type_traits, which
unfortunately happens with this program: https://godbolt.org/z/afbvK

#include 

(Please advise if you think this is a Clang bug, how libstdc++ expects these
type trait names to be parsed)