[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 #13 from YunQiang Su  ---
I try to insert 
li  $3, 500
li  $5, 500
between SLL/BGEZ  and LUI+AND/BNE.

The later is still some faster on Loongson 3A4000.

I notice something like this in 74K's software manual:

The 74K core’s ALU is pipelined. Some ALU instructions complete the operation
and bypass the results in this cycle. These instructions are referred to as
single-cycle ops and they include all logical instructions (AND, ANDI, OR, ORI,
XOR, XORI, LUI), some shift instructions (SLL sa<=8, SRL 31<=sa<=25), and some
arithmetic instructions (ADD rt=0, ADDU rt=0, SLT, SLTI, SLTU, SLTIU, SEH, SEB,
ZEH, ZEB). In addition, add instructions (ADD, ADDU, ADDI, ADDIU) complete the
operation and bypass results to the ALU pipe in this cycle.


I guess it means that if sa>8, SLL may be some slow.
On Loongson 3A4000, the value seems to be 20/21. It may means that we should be
care about for 64bit.

Can you have a test on XBurst 1?

[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 #8 from Gang Peng  ---
(In reply to Andrew Pinski from comment #6)
>   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

Dear Mr. Pinski,

Thank you very much for you kindly reply.
Yes, I need these compile option:
CFLAGS += -fPIE
CFLAGS += -msingle-pic-base
CFLAGS += -mpic-register=r9
CFLAGS += -fomit-frame-pointer
CFLAGS += -mno-pic-data-is-text-relative
CFLAGS += -mthumb
CFLAGS += -mlong-calls 

When we remove the -mlong-calls option, it can compile OK, but we need the
-mlong-calls option to compile.

Thanks &
BRs

Gang Peng

[Bug libcc1/105695] GCC 10.3.1 (20220519) build failure with GCC 12

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

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #4 from Sam James  ---
GCC 10 is EOL.

Downstream, we did:
```
if ! tc_version_is_at_least 11 && [[ $(gcc-major-version) -ge 12 ]] ;
then
# https://gcc.gnu.org/PR105695
# bug #849359
export ac_cv_std_swap_in_utility=no
fi
```

[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.

[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);
}
```

[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&action=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>

[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&action=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.

[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 (&item, &WWPersons);
  __builtin_strcpy (&item, &MEM  [(void *)&WWPersons +
12B]);
  __builtin_strcpy (&item, &MEM  [(void *)&WWPersons +
24B]); [tail call]
  return;

First of all the laddress pass decomposes the &WWPersons[i_3].Name address.
Disabling that has FRE after cunroll replace &WWPersons[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.

[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&hash=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&hash=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.

[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&action=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...

[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 = &a, *d = &a, e=0;
[[gnu::noipa]]
void f(int) {}
[[gnu::noinline]]
int h(int *k) {
  int ***j;
  if (b) {
*j = &k; // 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 *)&a] = 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?

[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

[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))> {};

[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.

[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.

[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)

[Bug c/115496] New: 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

Bug ID: 115496
   Summary: RFE: new warning to detect suspicious multline string
literals
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

I find I often forget to add trailing newlines when composing multiline string
literals in C/C++.

For example:

const char *str
  = ("this is the first line\n"
 "this is the second line"
 "this is the third line\n");

where the supposed "second line" is missing a trailing "\n" and thus the string
is actually:

this is the first line
this is the second linethis is the third line

For a more insidious example, consider:
  https://fobes.dev/general/2024/02/29/inline-assembly-dangers.html

where the code had this string literal:

   asm volatile(
"# Clear bss area"
"la   $2, _fbss"
"la   $3, _end"
"1:"
"sltu   $1, $2, $3"
"beq   $1, $0, 2f"
"nop"
"sq   $0, ($2)"
"addiu   $2, $2, 16"
"j   1b"
"nop"
"2:"
"   \n"
"# Save first argument  \n"
"la $2, %0 \n"
"sw $4, ($2)\n"
"   \n"
"# SetupThread  \n"
"la $4, _gp \n"
"la $5, _stack  \n"
"la $6, _stack_size \n"
"la $7, %1  \n"
"la $8, ExitThread  \n"
"move   $gp, $4 \n"
"addiu  $3, $0, 60  \n"
"syscall\n"
"move   $sp, $2 \n"
"   \n"
"# Jump to _main\n"
"j  %2   \n"
: /* No outputs. */
: "R"(args_start), "R"(args), "Csy"(_main));

Note that some lines have trailing "\n", but others don't, so that this is
actually:

"# Clear bss areala   $2, _fbssla   $3, _end1:sltu   $1, $2, $3beq  
$1, $0, 2fnopsq   $0, ($2)[...snip...]"
"   \n"
"# Save first argument  \n"
"la $2, %0 \n"
"sw $4, ($2)\n"
"   \n"
[...snip...]

and thus the "comment to end of line" in the assembler was treating much more
that one might expect from a casual reading of the C source.

Proposal: a new warning that detects suspicious line continuations in multiline
strings.  I'm not sure precisely what the heuristics should be, but something
like:

- the string literal is on multiple source lines
- at least some of the lines have terminating "\n" characters
- some of the lines don't have terminating "\n" characters (warn for these) -
but probably don't worry about the final line
- probably some other heuristics

Perhaps: "-Wsuspicious-multiline-string-literal" or somesuch?

[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #6 from Andrew Pinski  ---
hmm,  I think I see what is happening.

So we start with:
  # RANGE [irange] unsigned char [0, 1] MASK 0x1 VALUE 0x0
  _4 = (unsigned charD.20) iftmp.2_8;
  # RANGE [irange] unsigned char [254, +INF] MASK 0x1 VALUE 0xfe
  _5 = ~_4;

  if (_5 != _14)
goto ; [66.00%]
  else
goto ; [34.00%]

bb5:
  # RANGE [irange] unsigned char [0, 1] MASK 0x1 VALUE 0x0
  _17 = ~_14;
  # RANGE [irange] unsigned char [0, 1] MASK 0x1 VALUE 0x0
  _18 = _4 | _17;

...

bb6:
...
  _15 = ~_14;
  _7 = _4 | _15;


So PRE is consolidating _17 and _15 as being the same and using _17 as the
leader.
And when it realizes _4 is 1 on the bb6 and goes to do the simplify, does 1 |
_17 but gets simplified to 1 but `~_14` range in bb6 is not [0,1].

So the issue is PRE is not removing the range from _17 before doing the
simplification while consolidating the two ssa names.

Richi,
  can you look into this further? match is doing exactly what it is being asked
of it but it looks like PRE is messing up due to conditional ranges.

[Bug c/105863] RFE: C23 #embed

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

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

--- Comment #15 from Jakub Jelinek  ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654740.html

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

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 115495
   Summary: [15 Regression] ICE in smallest_mode_for_size, at
stor-layout.cc:356 during combine on RISC-V
rv64gcv_zvl256b at -O3
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
extern short a[];
short b;
int main() {
  for (char c = 0; c < 18; c += 1)
a[c + 0] = b;
}

Backtrace:
> /scratch/tc-testing/tc-jun-14/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv_zvl256b -O3 red.c -o red.out
during RTL pass: combine
./red.c: In function 'main':
./red.c:6:1: internal compiler error: in smallest_mode_for_size, at
stor-layout.cc:356
6 | }
  | ^
0x134a8f7 smallest_mode_for_size(poly_int<2u, unsigned long>, mode_class)
../../../gcc/gcc/stor-layout.cc:356
0x11fa32a smallest_int_mode_for_size(poly_int<2u, unsigned long>)
../../../gcc/gcc/machmode.h:916
0x11fa32a get_best_extraction_insn
../../../gcc/gcc/optabs-query.cc:208
0x25f7d54 make_extraction
../../../gcc/gcc/combine.cc:7779
0x25f903f make_compound_operation_int
../../../gcc/gcc/combine.cc:8186
0x25fa07f make_compound_operation(rtx_def*, rtx_code)
../../../gcc/gcc/combine.cc:8471
0x25fddce simplify_set
../../../gcc/gcc/combine.cc:6975
0x25fddce combine_simplify_rtx
../../../gcc/gcc/combine.cc:6374
0x260006f subst
../../../gcc/gcc/combine.cc:5630
0x2604101 try_combine
../../../gcc/gcc/combine.cc:3312
0x2609351 combine_instructions
../../../gcc/gcc/combine.cc:1264
0x2609351 rest_of_handle_combine
../../../gcc/gcc/combine.cc:15127
0x2609351 execute
../../../gcc/gcc/combine.cc:15171
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.

Godbolt: https://godbolt.org/z/zTf5nWz48

Found via fuzzer.

The fuzzer first detected this on 2024-06-07 and many times since so it was
likely caused by a patch committed a day or two before 2024-06-07.

[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Hmm. disabling:
> 
> /* x | C -> C if we know that x & ~C == 0.  */
> (simplify
>  (bit_ior SSA_NAME@0 INTEGER_CST@1)
>  (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
>   && wi::bit_and_not (get_nonzero_bits (@0), wi::to_wide (@1)) == 0)
>   @1))
> 
> Fixes it.
> 
> So this was caused/exposed by r14-3485-g6df8dcec7196e4 .
> 
> Note that above pattern is hitting during PRE. I have to double check to
> make sure that is correct.

The match pattern is correct what we get through PRE is:
_17 | 1
Where _17's range is [0,1]
so obvious this is just 1.

So either what pre is sending off to match-and-simplify is wrong or the way pre
uses match-and-simplify is wrong. What the match does is correct for what it is
given..

[Bug c/108753] '-Wduplicated-cond' doesn't diagnose duplicated subexpressions

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

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

--- Comment #2 from Marek Polacek  ---
Making this work should hopefully be fairly easy: add a tree walk on the
operands of || and && and compare them to the previous condition?

[Bug c/67819] -Wduplicated-cond should take macros into account

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

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

--- Comment #8 from Marek Polacek  ---
-Wduplicated-branches has the same problem, see
.

[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #4 from Andrew Pinski  ---
Hmm. disabling:

/* x | C -> C if we know that x & ~C == 0.  */
(simplify
 (bit_ior SSA_NAME@0 INTEGER_CST@1)
 (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
  && wi::bit_and_not (get_nonzero_bits (@0), wi::to_wide (@1)) == 0)
  @1))

Fixes it.

So this was caused/exposed by r14-3485-g6df8dcec7196e4 .

Note that above pattern is hitting during PRE. I have to double check to make
sure that is correct.

[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-14
Summary|[15 regression] [RISC-V]|[15 regression] [RISC-V]
   |ICE in  |ICE in
   |lra_split_hard_reg_for, at  |lra_split_hard_reg_for, at
   |lra-assigns.cc:1868 unable  |lra-assigns.cc:1868 unable
   |to find a register to spill |to find a register to spill
   ||since
   ||r15-518-g99b1daae18c095

[Bug tree-optimization/115385] Peeling for gaps can be optimized more or needs to peel more than one iteration

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #5 from Sam James  ---
r15-1309-ge575b5c56137b1 should fix that...

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

[kargls at comcast dot net via Gcc-bugs]

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

kargls at comcast dot net changed:

   What|Removed |Added

 CC||kargls at comcast dot net

--- Comment #1 from kargls at comcast dot net ---
(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.

[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-14
 Ever confirmed|0   |1
   Target Milestone|--- |14.2
 Status|UNCONFIRMED |NEW
Summary|wrong code at -O{2,3} with  |[14/15 Regression] wrong
   |"-fno-ssa-phiopt" on|code at -O{2,3} on
   |x86_64-linux-gnu|x86_64-linux-gnu

--- Comment #3 from Andrew Pinski  ---
.

[Bug tree-optimization/115494] wrong code at -O{2,3} with "-fno-ssa-phiopt" on x86_64-linux-gnu

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

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

--- Comment #2 from Andrew Pinski  ---
Note changing main to f and you get the failure even without `-fno-ssa-phiopt`.

[Bug tree-optimization/115494] wrong code at -O{2,3} with "-fno-ssa-phiopt" on x86_64-linux-gnu

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 58433
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58433&action=edit
Testcase that uses abort

[Bug target/115419] [avr] IEEE double round-to-nearest should go to even

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

--- Comment #2 from Georg-Johann Lay  ---
Fixed on master.

[Bug target/115419] [avr] IEEE double round-to-nearest should go to even

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Georg-Johann Lay :

https://gcc.gnu.org/g:2830b0b8655f0d1a62b416af8ade31f5b96f0ffb

commit r15-1343-g2830b0b8655f0d1a62b416af8ade31f5b96f0ffb
Author: Georg-Johann Lay 
Date:   Fri Jun 14 18:24:13 2024 +0200

AVR: target/115419 - Tie breaks are rounded-to-even.

libgcc/config/avr/libf7/
PR target/115419
* libf7.c (f7_get_double): Round tie breaks to even LSB.

[Bug tree-optimization/115494] New: wrong code at -O{2,3} with "-fno-ssa-phiopt" on x86_64-linux-gnu (the generated code hangs)

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

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

Bug ID: 115494
   Summary: wrong code at -O{2,3} with "-fno-ssa-phiopt" on
x86_64-linux-gnu (the generated code hangs)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression as it doesn't reproduce with 13.* and
earlier. 

Compiler Explorer: https://godbolt.org/z/889EdEeE9

[627] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240614 (experimental) (GCC) 
[628] % 
[628] % gcctk -O2 small.c; ./a.out; echo $?
0
[629] % gcctk -O2 -fno-ssa-phiopt small.c; ./a.out; echo $?
1
[630] % cat small.c
unsigned char a;
int b = 1, c, d;
int main() {
  char e;
  c = b - c;
  a = ~(c || a);
  e = -(b ^ a);
  d = e && b;
  a = ~(b & a);
  if (a < 2)
return 1;
  return 0;
}

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

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

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

--- Comment #15 from Jonathan Wakely  ---
No, this only helps for mingw-g++. Only the change from comment 7 has been
committed. As noted in comment 9, the incorrect macro definition for clang
still causes problems.  We either need to work around that like in the first
bit of comment 9, or clang needs a change.

[Bug testsuite/115443] aarch64: Test gcc.dg/vect/pr99102.c FAIL

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

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

--- Comment #2 from Marek Polacek  ---
This was with GCC 14 but I bet trunk behaves the same.

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

[martin at martin dot st via Gcc-bugs]

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

--- Comment #14 from Martin Storsjö  ---
(In reply to GCC Commits from comment #13)
> The master branch has been updated by Jonathan Wakely :
> 
> https://gcc.gnu.org/g:6af8d8e618ed27dae3432c96484de4360bd893ab
> 
> commit r15-1342-g6af8d8e618ed27dae3432c96484de4360bd893ab
> Author: Jonathan Wakely 
> Date:   Tue Jun 11 15:52:30 2024 +0100
> 
> libstdc++: Make std::type_info::operator== always_inline for C++23
> [PR110572]

Is this enough to fix the issue with Clang, or should I still look into making
Clang predefine __GXX_TYPEINFO_EQUALITY_INLINE=0 for mingw targets? (Even if it
works, it's admittedly not very pretty to rely on "#if !FOO" for an undefined
FOO.)

[Bug tree-optimization/115385] Peeling for gaps can be optimized more or needs to peel more than one iteration

[carlos.seo at linaro dot org via Gcc-bugs]

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

Carlos Eduardo Seo  changed:

   What|Removed |Added

 CC||carlos.seo at linaro dot org

--- Comment #4 from Carlos Eduardo Seo  ---
This patch seems to be breaking aarch64:

# 00:20:58
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/gcc/hwint.h:266:17:
error: ‘remain.poly_int<2, long unsigned int>::coeffs[0]’ may be used
uninitialized [-Werror=maybe-uninitialized]
# 00:20:58
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/gcc/poly-int.h:557:7:
error: ‘remain.poly_int<2, long unsigned int>::coeffs[1]’ may be used
uninitialized [-Werror=maybe-uninitialized]
# 00:21:48 make[3]: *** [Makefile:1199: tree-vect-stmts.o] Error 1
# 00:21:48 make[2]: *** [Makefile:5100: all-stage2-gcc] Error 2
# 00:21:48 make[1]: *** [Makefile:25572: stage2-bubble] Error 2
# 00:21:48 make: *** [Makefile:1103: all] Error 2

[Bug c/115488] __has_include with empty filename

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug libstdc++/115481] HAVE_* for long double math functions wrong for avrlibc (target AVR)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to dv from comment #2)
> Will do (currently testing a patch that includes the fix
> for 111639).

Great, thank you!