[Bug middle-end/114070] [12/13/13 regression] ICE when building git-2.43.2 with -mcpu=niagara4 -fno-vect-cost-model

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
 Target||sparc
   Target Milestone|--- |12.4

--- Comment #2 from Richard Biener  ---
  /* For vector typed comparisons emit code to generate the desired
 all-ones or all-zeros mask.  */
  if (VECTOR_TYPE_P (ops->type))
{
  tree ifexp = build2 (ops->code, ops->type, arg0, arg1);
  if (VECTOR_BOOLEAN_TYPE_P (ops->type)
  && expand_vec_cmp_expr_p (TREE_TYPE (arg0), ops->type, ops->code))
return expand_vec_cmp_expr (ops->type, ifexp, target);
  else
gcc_unreachable ();

that means we end up with a non-boolean vector "flag".  Possibly a middle-end
issue indeed.

[Bug rtl-optimization/114070] [12/13/13 regression] ICE when building git-2.43.2 with -mcpu=niagara4 -fno-vect-cost-model

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

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

--- Comment #1 from Sam James  ---
I'll reduce.

[Bug rtl-optimization/114070] New: [12/13/13 regression] ICE when building git-2.43.2 with -mcpu=niagara4 -fno-vect-cost-model

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

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

Bug ID: 114070
   Summary: [12/13/13 regression] ICE when building git-2.43.2
with -mcpu=niagara4 -fno-vect-cost-model
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57506=edit
merge-tree.i.xz

I'm not sure if this is an rtl-optimization bug or a target bug.

```
sparc64-unknown-linux-gnu-gcc -o builtin/merge-tree.o -c -MF
builtin/.depend/merge-tree.o.d -MQ builtin/merge-tree.o -MMD -MP-O3
-mcpu=niagara4 -pipe -fno-semantic-interposition -fno-vect-cost-model
-U_FORTIFY_SOURCE -fno-hardened -I. -DHAVE_SYSINFO -DGIT_HOST_CPU="\"sparc64\""
-DUSE_LIBPCRE2 -DHAVE_ALLOCA_H  -DUSE_CURL_FOR_IMAP_SEND -DSUPPORTS_SIMPLE_IPC
-DSHA1_BLK -DSHA256_BLK  -DHAVE_PATHS_H -DHAVE_DEV_TTY -DHAVE_CLOCK_GETTIME
-DHAVE_CLOCK_MONOTONIC -DHAVE_SYNC_FILE_RANGE -DHAVE_GETDELIM
'-DPROCFS_EXECUTABLE_PATH="/proc/self/exe"' -DFREAD_READS_DIRECTORIES
-DNO_STRLCPY -DSHELL_PATH='"/bin/sh"'  builtin/merge-tree.c
during RTL pass: expand
builtin/merge-tree.c: In function ‘threeway_callback’:
builtin/merge-tree.c:327:12: internal compiler error: in do_store_flag, at
expr.cc:13547
  327 | static int threeway_callback(int n UNUSED, unsigned long mask,
  |^
rm -f xdiff/lib.a && sparc64-unknown-linux-gnu-ar rcs xdiff/lib.a
xdiff/xdiffi.o xdiff/xemit.o xdiff/xhistogram.o xdiff/xmerge.o
xdiff/xpatience.o xdiff/xprepare.o xdiff/xutils.o
0x172aa17 do_store_flag
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/expr.cc:13547
0x172b103 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/expr.cc:10684
0x173c15f expand_expr_real_gassign(gassign*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/expr.cc:11096
0x1736923 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/expr.cc:11277
0x19093af expand_normal(tree_node*)
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/expr.h:322
0x19093af expand_vec_cond_optab_fn
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/internal-fn.cc:3081
0x191dae3 expand_internal_call(internal_fn, gcall*)
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/internal-fn.cc:4913
0x191dae3 expand_internal_call(gcall*)
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/internal-fn.cc:4921
0x154ae5b expand_call_stmt
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cfgexpand.cc:2771
0x154ae5b expand_gimple_stmt_1
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cfgexpand.cc:3932
0x154ae5b expand_gimple_stmt
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cfgexpand.cc:4077
0x1554c5f expand_gimple_basic_block
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cfgexpand.cc:6133
0x15578df execute
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cfgexpand.cc:6872
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.
```

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-unknown-linux-gnu/14/lto-wrapper
Target: sparc64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0./work/gcc-14.0./configure
--host=sparc64-unknown-linux-gnu --build=sparc64-unknown-linux-gnu
--prefix=/usr --bindir=/usr/sparc64-unknown-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/sparc64-unknown-linux-gnu/14/include
--datadir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/14
--mandir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/14/man
--infodir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/sparc64-unknown-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/sparc64-unknown-linux-gnu/14/python
--enable-languages=c,c++,fortran --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 14.0. p,
commit e54a7fbca63053b5753fd9ba543c27ef392d3084' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit 

[Bug target/114069] New: Type punning RISC-V vectors causes ICE at -O1

[zingaburga+gcc at hotmail dot com via Gcc-bugs]

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

Bug ID: 114069
   Summary: Type punning RISC-V vectors causes ICE at -O1
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zingaburga+gcc at hotmail dot com
  Target Milestone: ---

Type punning a RISC-V vector causes ICE under RV64 GCC 13.x/trunk:
https://godbolt.org/z/sajcb3T7z

Seems to work with -O0 instead of -O1, on GCC 13.x


Code:

#include 

vbool8_t f(vuint8m1_t s) {
// unavailable in GCC 13, available in trunk
//return __riscv_vreinterpret_v_u8m1_b8(s);

// causes ICE in GCC 13 + trunk
return *reinterpret_cast();

// this seems to work without issue
vuint8mf8_t f = __riscv_vlmul_trunc_v_u8m1_u8mf8(s);
return *reinterpret_cast();
}


Compiler options: -march=rv64gcv -O1


Output:

during RTL pass: expand
: In function 'vbool8_t f(vuint8m1_t)':
:8:47: internal compiler error: in convert_move, at expr.cc:219
8 | return *reinterpret_cast();
  |   ^
0x7fb7d5029e3f __libc_start_main
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
Compiler returned: 1

[Bug tree-optimization/114068] [14 regression] ICE when building darktable-4.6.1 (error: PHI node with wrong VUSE on edge from BB 25)

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed||2024-02-23
   Target Milestone|--- |14.0

--- Comment #5 from Richard Biener  ---
Confirmed.  Waiting for reduced testcase.

[Bug tree-optimization/114061] GCC fails vectorization when using __builtin_prefetch

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
I think we could try to "vectorize" them by only updating the address (the
builtin doesn't specify a size) when that evolves in the scalar loop, updating
the step with the chosen VF.

Dependence shouldn't be a concern here.

The main issue is a representational - how to handle this in data-ref and
dependence analysis (or whether to just "skip" them in the vectorizer).

[Bug target/114057] [14 Regression] 435.gromacs fails verification on with -Ofast -march=znver4 and PGO

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

--- Comment #3 from Richard Biener  ---
If it is a FP rounding issue then my guess would be the extra reduc_scal_*
patterns in the x86 backend to do more BB reduction vectorization.

I guess it doesn't miscompare with -O3 or -O3 -fno-signed-zeros
-fno-trapping-math -ffinite-math-only -ffp-contract=fast?

[Bug tree-optimization/114068] [14 regression] ICE when building darktable-4.6.1 (error: PHI node with wrong VUSE on edge from BB 25)

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

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

--- Comment #4 from Andrew Pinski  ---
`-std=c++20 -O3 -mavx` is enough to reproduce the ICE.

[Bug tree-optimization/114068] [14 regression] ICE when building darktable-4.6.1 (error: PHI node with wrong VUSE on edge from BB 25)

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Sam James from comment #2)
> Note that this is the second time we've seen the weird "double crash" w/
> x86_64_fallback_frame_state when unwinding, see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114048#c3 too.

See PR 66874 for that ... I think.

[Bug tree-optimization/114068] [14 regression] ICE when building darktable-4.6.1 (error: PHI node with wrong VUSE on edge from BB 25)

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

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

--- Comment #2 from Sam James  ---
Note that this is the second time we've seen the weird "double crash" w/
x86_64_fallback_frame_state when unwinding, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114048#c3 too.

[Bug tree-optimization/114068] [14 regression] ICE when building darktable-4.6.1 (error: PHI node with wrong VUSE on edge from BB 25)

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

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

--- Comment #1 from Sam James  ---
Reducing now...

[Bug tree-optimization/114068] New: [14 regression] ICE when building darktable-4.6.1 (error: PHI node with wrong VUSE on edge from BB 25)

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

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

Bug ID: 114068
   Summary: [14 regression] ICE when building darktable-4.6.1
(error: PHI node with wrong VUSE on edge from BB 25)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57505=edit
RawImage.cpp.ii.xz

Initially reported downstream in Gentoo by tdr.

```
# /usr/bin/x86_64-pc-linux-gnu-g++ -DGDK_DISABLE_DEPRECATED
-DGTK_DISABLE_DEPRECATED -DGTK_DISABLE_SINGLE_INCLUDES -DNDEBUG -D_RELEASE
-D_XOPEN_SOURCE=700
-I/var/tmp/portage/media-gfx/darktable-4.6.1/work/darktable-4.6.1_build/lib64/darktable/rawspeed/src/librawspeed/common
-I/var/tmp/portage/media-gfx/darktable-4.6.1/work/darktable-4.6.1/src/external/rawspeed/src/librawspeed/common
-I/var/tmp/portage/media-gfx/darktable-4.6.1/work/darktable-4.6.1_build/lib64/darktable/rawspeed/src
-I/var/tmp/portage/media-gfx/darktable-4.6.1/work/darktable-4.6.1/src/external/rawspeed/src/librawspeed/common/..
-isystem
/var/tmp/portage/media-gfx/darktable-4.6.1/work/darktable-4.6.1/src/external/rawspeed/src/external
 -march=native -O3 -pipe -mavx -msse3 -Wall -Wformat -Wformat-security -Wshadow
-Wtype-limits -Wvla -Wmaybe-uninitialized -Wno-unknown-pragmas
-Wno-error=varargs -Wno-format-truncation -Wno-error=address-of-packed-member
-w -Wall -Wextra -Wcast-qual -Wextra -Wextra-semi -Wformat=2 -Wpointer-arith
-Wvla -Wmissing-format-attribute -Wsuggest-attribute=format
-Wno-unused-parameter -Wno-maybe-uninitialized -Wno-stringop-overflow
-Wno-array-bounds -Wstack-usage=4096 -Wframe-larger-than=4096
-Wlarger-than=32768  -O3 -std=c++20 -fPIC -fvisibility=hidden
-fvisibility-inlines-hidden   -march=native -g3 -ggdb3 -fopenmp -MD -MT
lib64/darktable/rawspeed/src/librawspeed/common/CMakeFiles/rawspeed_common.dir/RawImage.cpp.o
-MF
lib64/darktable/rawspeed/src/librawspeed/common/CMakeFiles/rawspeed_common.dir/RawImage.cpp.o.d
-o
lib64/darktable/rawspeed/src/librawspeed/common/CMakeFiles/rawspeed_common.dir/RawImage.cpp.o
-c
/var/tmp/portage/media-gfx/darktable-4.6.1/work/darktable-4.6.1/src/external/rawspeed/src/librawspeed/common/RawImage.cpp
 
/var/tmp/portage/media-gfx/darktable-4.6.1/work/darktable-4.6.1/src/external/rawspeed/src/librawspeed/common/RawImage.cpp:
In member function ‘void
rawspeed::RawImageData::clearArea(rawspeed::iRectangle2D)’:
/var/tmp/portage/media-gfx/darktable-4.6.1/work/darktable-4.6.1/src/external/rawspeed/src/librawspeed/common/RawImage.cpp:325:6:
error: PHI node with wrong VUSE on edge from BB 25
  325 | void RawImageData::clearArea(iRectangle2D area) {
  |  ^~~~
.MEM_201 = PHI <.MEM_162(25)>
expected .MEM_155
during GIMPLE pass: vect
/var/tmp/portage/media-gfx/darktable-4.6.1/work/darktable-4.6.1/src/external/rawspeed/src/librawspeed/common/RawImage.cpp:325:6:
internal compiler error: verify_ssa failed
0x562cb4452725 verify_ssa(bool, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240218/gcc-14-20240218/gcc/tree-ssa.cc:1203

/var/tmp/portage/media-gfx/darktable-4.6.1/work/darktable-4.6.1/src/external/rawspeed/src/librawspeed/common/RawImage.cpp:325:6:
internal compiler error: Segmentation fault
0x562cb4155596 crash_signal
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240218/gcc-14-20240218/gcc/toplev.cc:317
0x7fa03922e07f ???
   
/var/tmp/portage/sys-libs/glibc-2.38-r11/work/glibc-2.38/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x562cb5a2f12f x86_64_fallback_frame_state
./md-unwind-support.h:63
0x562cb5a2f12f uw_frame_state_for
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240218/gcc-14-20240218/libgcc/unwind-dw2.c:1013
0x562cb5a300e5 _Unwind_Backtrace
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240218/gcc-14-20240218/libgcc/unwind.inc:303
0x562cb56fe80b backtrace_full
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240218/gcc-14-20240218/libbacktrace/backtrace.c:127
0x562cb562138b diagnostic_context::action_after_output(diagnostic_t)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240218/gcc-14-20240218/gcc/diagnostic.cc:781
0x562cb55feb6b diagnostic_action_after_output(diagnostic_context*,
diagnostic_t)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240218/gcc-14-20240218/gcc/diagnostic.h:1002
0x562cb55feb6b diagnostic_context::report_diagnostic(diagnostic_info*)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240218/gcc-14-20240218/gcc/diagnostic.cc:1633
0x562cb55fefb0 diagnostic_impl
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240218/gcc-14-20240218/gcc/diagnostic.cc:1767
0x562cb55ff2b9 internal_error(char const*, ...)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240218/gcc-14-20240218/gcc/diagnostic.cc:2225
0x562cb4452725 verify_ssa(bool, bool)
   

[Bug other/109668] 'python' vs. 'python3'

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Kito Cheng :

https://gcc.gnu.org/g:23f5da91ccb4927562ea4d1c245639bfd4a0088b

commit r14-9144-g23f5da91ccb4927562ea4d1c245639bfd4a0088b
Author: Palmer Dabbelt 
Date:   Fri Feb 9 08:53:24 2024 -0800

RISC-V: Point our Python scripts at python3

This builds for me, and I frequently have python-is-python3 type
packages installed so I think I've been implicitly testing it for a
while.  Looks like Kito's tested similar configurations, and the
bugzilla indicates we should be moving over.

gcc/ChangeLog:

PR other/109668
* config/riscv/arch-canonicalize: Move to python3
* config/riscv/multilib-generator: Likewise

[Bug c++/114067] GCC gives wrong diagnostic in the definition of a static data member of same class type

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #2 from Andrew Pinski  ---

Actually A at that point is incomplete type.

Note MSVC gives really bad diagnostic for:
```
struct A{
int x;
static constexpr const A a{1};
};
```
says undefined type A rather than incomplete type.

Anyways GCC's check for incomplete type happens before the other checks.
Plus GCC allows it with -fpermissive 

[Bug c++/114067] GCC gives wrong diagnostic in the definition of a static data member of same class type

[jlame646 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Jason Liam  ---
That is, even if the type of `a` was complete the program would've been
ill-formed. So saying only that `A` is incomplete is the problem doesn't seem
right.

[Bug target/107270] [11/12/13/14 Regression] return for structure is not as good as before

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Richard Earnshaw from comment #2)
> But this is just BFI, so it's a costing issue.

Fixing that still leaves us with:
Trying 8 -> 15:
8: zero_extract(r100:DI,0x20,0)=r107:SI#0
  REG_DEAD r107:SI
   15: x0:DI=r100:DI&0x|r108:SI#0<<0x20
  REG_DEAD r108:SI
  REG_DEAD r100:DI
Failed to match this instruction:
(set (reg/i:DI 0 x0)
(ior:DI (ashift:DI (subreg:DI (reg:SI 108) 0)
(const_int 32 [0x20]))
(zero_extend:DI (reg:SI 107

Which is a BFI but there is no pattern to match that.
I will submit my rtx_cost patch still but for now I am not going to add another
pattern

[Bug c++/114067] New: GCC gives wrong diagnostic in the definition of a static data member of same class type

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 114067
   Summary: GCC gives wrong diagnostic in the definition of a
static data member of same class type
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlame646 at gmail dot com
  Target Milestone: ---

The following program produces wrong diagnostic with gcc and clang:

```
struct A{
int x;
static const A a{1};
};
```
GCC says `in-class initialization of static data member 'const A A::a' of
incomplete type`.

While the actual problem is not that `A` is incomplete but that it is not an
integral or enumeration type. 

Only msvc gives correct diagnostic saying:

```
 error C2864: 'A::a': a static data member with an in-class initializer must
have non-volatile const integral type or be specified as 'inline'
```

So I think gcc should say something similar to msvc instead of saying that `A`
being incomplete is the problem.

[Bug target/113950] PowerPC, ICE with -O1 or higher compiling __builtin_vsx_splat_2di test case

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

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jeevitha at gcc dot 
gnu.org
 CC||dje at gcc dot gnu.org,
   ||linkw at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #2 from Peter Bergner  ---
Jeevitha is looking into this for us.

[Bug target/107270] [11/12/13/14 Regression] return for structure is not as good as before

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Keywords|needs-bisection |

--- Comment #3 from Andrew Pinski  ---
Working on a patch which adds aarch64_bfi_rtx_p to catch all of these manual
BFI patterns.

[Bug target/101737] SH4 -Os causes internal compiler error when building pixman

[pietro.gcc at sociotechnical dot xyz via Gcc-bugs]

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

pietro  changed:

   What|Removed |Added

 CC||pietro.gcc at sociotechnical 
dot x
   ||yz

--- Comment #4 from pietro  ---
Using the sh4-linux cross compiler from debian unstable:

$ sh4-linux-gnu-gcc-14 -v
Using built-in specs.
COLLECT_GCC=sh4-linux-gnu-gcc-14
COLLECT_LTO_WRAPPER=/usr/libexec/gcc-cross/sh4-linux-gnu/14/lto-wrapper
Target: sh4-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 14-20240201-3'
--with-bugurl=file:///usr/share/doc/gcc-14/README.Bugs
--enable-languages=c,ada,c++,fortran,objc,obj-c++,rust --prefix=/usr
--with-gcc-major-version-only --program-suffix=-14 --enable-shared
--enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace
--enable-gnu-unique-object --disable-libsanitizer --disable-libquadmath
--disable-libquadmath-support --enable-plugin --with-system-zlib
--enable-multiarch --disable-werror --with-cpu=sh4
--with-multilib-list=m4,m4-nofpu --enable-checking=yes
--build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=sh4-linux-gnu
--program-prefix=sh4-linux-gnu- --includedir=/usr/sh4-linux-gnu/include
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240131 (experimental) [master r14-8680-g2f14c0dbb78]
(Debian 14-20240201-3)

I'm able to reproduce the issue with the attached test source file:

# sh4-linux-gnu-gcc-14 -c -Os test.c
during RTL pass: split1
pixman-fast-path.c: In function
'fast_composite_scaled_nearest__565_cover_OVER':
pixman-fast-path.c:1201: internal compiler error: Segmentation fault
0xde6a7b crash_signal
../../src/gcc/toplev.cc:317
0x11ed95c sh_is_nott_insn(rtx_insn const*)
../../src/gcc/config/sh/sh.cc:11770
0x16f82df gen_split_13(rtx_insn*, rtx_def**)
../../src/gcc/config/sh/sh.md:951
0x946e5b try_split(rtx_def*, rtx_insn*, int)
../../src/gcc/emit-rtl.cc:3941
0xd3223f split_insn
../../src/gcc/recog.cc:3405
0xd37a97 split_all_insns()
../../src/gcc/recog.cc:3509
0xd37b8b execute
../../src/gcc/recog.cc:4433

But I'm not able to reproduce using the code from comment #2. I used creduce to
get a simple test case:

$ cat test2.c
int a;
void b() {
  int c;
  short *d = (short *)b;
  while (--c) {
int e = a, f, g;
while ((e -= 4) >= 0) {
  f += g;
  d++;
}
if (e & 2)
  f += g;
if (e & 1)
  *d = f;
  }
}

$ sh4-linux-gnu-gcc-14 -c -Os test2.c
during RTL pass: split1
test2.c: In function 'b':
test2.c:16:1: internal compiler error: Segmentation fault
   16 | }
  | ^
0xde6a7b crash_signal
../../src/gcc/toplev.cc:317
0x11ed95c sh_is_nott_insn(rtx_insn const*)
../../src/gcc/config/sh/sh.cc:11770
0x16f82df gen_split_13(rtx_insn*, rtx_def**)
../../src/gcc/config/sh/sh.md:951
0x946e5b try_split(rtx_def*, rtx_insn*, int)
../../src/gcc/emit-rtl.cc:3941
0xd3223f split_insn
../../src/gcc/recog.cc:3405
0xd37a97 split_all_insns()
../../src/gcc/recog.cc:3509
0xd37b8b execute
../../src/gcc/recog.cc:4433

[Bug c++/59465] [11/12/13/14 Regression] g++ allows direct-initialization of an array of class type from another array in a mem-initializer

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug rtl-optimization/91161] [11/12/13/14 Regression] ICE in begin_move_insn, at sched-ebb.c:175

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #14 from H.J. Lu  ---
(In reply to Andrew Pinski from comment #13)
> I looked into the IR between GCC 12 and GCC 13 (with the added attributes),
> before sched2 there is no difference. So it would good to see what change
> "fixes" this again.

The bug went latent by r13-2726.

[Bug modula2/113749] [14 Regression] m2 enabled build times out on i686-gnu (GNU Hurd)

[samuel.thibault--- via Gcc-bugs]

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

--- Comment #3 from Samuel Thibault  ---
I don't think it is a regression. We noticed it only recently in Debian only
because the configuration files got bogus. See for instance

https://buildd.debian.org/status/fetch.php?pkg=gcc-13=hurd-i386=13.2.0-10=1705711375=

which fails the same:

m2/boot-bin/mc --olang=c++ --h-file-prefix=G -I../../src/gcc/m2/gm2-libs
-I../../src/gcc/m2/gm2-compiler -I../../src/gcc/m2/gm2-libiberty -I
E: Build killed with signal TERM after 180 minutes of inactivity

And we can trace it back to this commit in debian:

commit ac0e3d134553e01c04b6a1b7f9c855fcb747dd6f
Author: Matthias Klose 
Date:   Tue Oct 8 10:34:25 2019 +0200

  * Disable gm2 on hurd-i386, mc hangs there (Samuel Thibault). Closes:
#940600.

That being said, it'd still be good to fix it, sure :)

[Bug c++/104111] [DR2589] Concept evaluation depends on context where it was first checked

[webrown.cpp at gmail dot com via Gcc-bugs]

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

--- Comment #10 from W E Brown  ---
(In reply to Eric Estievenart from comment #9)

Sorry, but I find neither "weirdness" nor "spooky"-ness in the comment #9 code
as shown.  Rather, I believe it to be simply an example of a program that the
C++ standard would describe as "ill-formed, no diagnostic required."

A common, yet incorrect expectation that template instantiation somehow mirrors
function call semantics seems to me to lie at the heart of the
misunderstanding.  Hypothetically, if the above program were to be well-formed,
the compiler would need to instantiate the member template twice *with
identical template arguments* in order to obtain the expected two different
outcomes.  However, I recall no specification, in the C++ standard, that
requires such (relatively expensive!) duplication of compiler effort:  once a
template has been instantiated, the compiler seems fully entitled, say, to
cache the result of that instantiation and reuse that outcome as may be needed
during the remainder of that TU's compilation.

Put another way, defining the same function in two different ways (one
instantiation as deleted, one not) seems to be a form of ODR violation.

Perhaps the OP is also a manifestation of a similar misunderstanding; I've not
checked.  If so, I would respectfully recommend this PR be closed as invalid.

[Bug modula2/114026] incorrect location during for loop type check

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

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

Rainer Orth  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED
 CC||ro at gcc dot gnu.org

--- Comment #5 from Rainer Orth  ---
Two of the new tests FAIL on 32 and 64-bit Solaris/SPARC:

+FAIL: gm2/extensions/run/pass/callingc10.mod execution,  -O 
+FAIL: gm2/extensions/run/pass/callingc10.mod execution,  -O -g 
+FAIL: gm2/extensions/run/pass/callingc10.mod execution,  -O3
-fomit-frame-point
er 
+FAIL: gm2/extensions/run/pass/callingc10.mod execution,  -O3
-fomit-frame-point
er -finline-functions 
+FAIL: gm2/extensions/run/pass/callingc10.mod execution,  -Os 
+FAIL: gm2/extensions/run/pass/callingc10.mod execution,  -g 
+FAIL: gm2/extensions/run/pass/callingc11.mod execution,  -O 
+FAIL: gm2/extensions/run/pass/callingc11.mod execution,  -O -g 
+FAIL: gm2/extensions/run/pass/callingc11.mod execution,  -O3
-fomit-frame-pointer 
+FAIL: gm2/extensions/run/pass/callingc11.mod execution,  -O3
-fomit-frame-pointer -finline-functions 
+FAIL: gm2/extensions/run/pass/callingc11.mod execution,  -Os 
+FAIL: gm2/extensions/run/pass/callingc11.mod execution,  -g 

The failure mode is the same for both:

parameter is hello and length 0
executed
/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/gm2/callingc10.x0 with
result fail

[Bug c++/114066] Allow classes with constructors in anonymous struct

[redorav at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Emilio López  ---
Hi Andrew, 

Thanks for the fast reply, I understand that some things are outside the spec,
but it'd be a great addition, if possible. The simplified test case you made
would definitely repro the error message I get, I was just trying to illustrate
the real use case it would be useful for.

Thanks

[Bug c++/114066] Allow classes with constructors in anonymous struct

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

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

--- Comment #2 from Andrew Pinski  ---
>anonymous structs
Which are a GNU extension to begin with ...

[Bug c++/114066] Allow classes with constructors in anonymous struct

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

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

--- Comment #1 from Andrew Pinski  ---
Simplified/corrected testcase:
```
struct swizzle4
{
swizzle4& operator = (const swizzle4& other);
};

struct
float4x4
{
struct {
 swizzle4 _m00_m10_m20_m30;
};
};
```

[Bug c++/114066] Allow classes with constructors in anonymous struct

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug rtl-optimization/91161] [11/12/13/14 Regression] ICE in begin_move_insn, at sched-ebb.c:175

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #13 from Andrew Pinski  ---
I looked into the IR between GCC 12 and GCC 13 (with the added attributes),
before sched2 there is no difference. So it would good to see what change
"fixes" this again.

[Bug c++/114066] New: Allow classes with constructors in anonymous struct

[redorav at gmail dot com via Gcc-bugs]

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

Bug ID: 114066
   Summary: Allow classes with constructors in anonymous struct
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redorav at gmail dot com
  Target Milestone: ---

Hi,

I am aware that the standard does not mandate allowing members with
constructors in anonymous structs and in this case GCC does not support it, but
I would like to request the feature. I am also aware of 86001 which looks
similar (but is a question) and 77314, which requests support for POD types.
However I'm looking for the full thing.

My use case is a math library, hlsl++, where in AVX mode I alias a single m256
with two m128 members. This is so that I can support matrix swizzles. The
internal structure of float4x4 looks conceptually like this (simplified):

template
struct swizzle4
{
swizzle& operator = (const swizzle& other) // Do swizzle things

m128 s;
};

float4x4
{
union
{
m256 vec;
struct
{
 swizzle4<0, 1, 2, 3> _m00_m10_m20_m30;
 swizzle4<0, 1, 2, 3> _m01_m11_m21_m31;
};
};
};

The swizzles are meant to be able to manipulate the data via rows (e.g. setting
a transformation matrix). If there is a better way to do this I don't really
know how, and so far this has been succesful in other compilers and seems like
a nice way to do it. If it was possible to support it in the same way unions
support it it'd be a nice addition.

Thanks

[Bug rtl-optimization/91161] [11/12/13/14 Regression] ICE in begin_move_insn, at sched-ebb.c:175

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

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Martin Liška from comment #8)
> Btw. one can't see it on master after r10--g7313607478c11e94.

But if you do:
```
[[gnu::noinline, noreturn]]
void
ni ()
```

You can reproduce it except it is no longe reproducible in GCC 13+ though.

[Bug target/85640] [11/12/13/14 Regression] code size regression vs 7.x

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

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

--- Comment #14 from Andrew Pinski  ---
Seems like it has been improved again for GCC 12.

[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #24 from Patrick O'Neill  ---
Resolved

[Bug c++/113083] [14 Regression][arm] ICE in fold_convert_loc, at fold-const.cc:2602 since r14-5979-g99d114c15523e0

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

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

--- Comment #7 from Jakub Jelinek  ---
As in:
2024-02-22  Jakub Jelinek  

PR c++/113083
* cp-gimplify.cc (cp_fold): For targetm.cxx.cdtor_returns_this ()
wrap r into a COMPOUND_EXPR and return folded CALL_EXPR_ARG (x, 0).

* g++.dg/cpp0x/constexpr-113083.C: New test.

--- gcc/cp/cp-gimplify.cc.jj2024-02-22 21:45:09.663430066 +0100
+++ gcc/cp/cp-gimplify.cc   2024-02-22 22:30:23.481428242 +0100
@@ -3412,9 +3412,15 @@ cp_fold (tree x, fold_flags_t flags)
if (DECL_CONSTRUCTOR_P (callee))
  {
loc = EXPR_LOCATION (x);
-   tree s = build_fold_indirect_ref_loc (loc,
- CALL_EXPR_ARG (x, 0));
+   tree a = CALL_EXPR_ARG (x, 0);
+   bool return_this = targetm.cxx.cdtor_returns_this ();
+   if (return_this)
+ a = cp_save_expr (a);
+   tree s = build_fold_indirect_ref_loc (loc, a);
r = cp_build_init_expr (s, r);
+   if (return_this)
+ r = build2_loc (loc, COMPOUND_EXPR, TREE_TYPE (x), r,
+ fold_convert_loc (loc, TREE_TYPE (x), a));
  }
x = r;
break;
--- gcc/testsuite/g++.dg/cpp0x/constexpr-113083.C.jj2024-01-13
00:05:00.077372302 +0100
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-113083.C   2024-02-22
22:20:20.622618992 +0100
@@ -0,0 +1,16 @@
+// PR c++/113083
+// { dg-do compile { target c++11 } }
+// { dg-options "-Os" }
+
+struct A { constexpr A (); };
+
+void
+foo ()
+{
+  A b;
+}
+
+constexpr
+A::A ()
+{
+}

[Bug target/113001] [14 Regression] RISCV Zicond ICE: in extract_insn, at recog.cc:2812 with -O2 rv64gcv_zicond

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Last reconfirmed||2024-02-22
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug c++/113083] [14 Regression][arm] ICE in fold_convert_loc, at fold-const.cc:2602 since r14-5979-g99d114c15523e0

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

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

--- Comment #6 from Jakub Jelinek  ---
What about:
2024-02-22  Jakub Jelinek  

PR c++/113083
* cp-gimplify.cc (cp_fold): For targetm.cxx.cdtor_returns_this ()
wrap r into a COMPOUND_EXPR and return folded CALL_EXPR_ARG (x, 0).

* g++.dg/cpp0x/constexpr-113083.C: New test.

--- gcc/cp/cp-gimplify.cc.jj2024-02-22 21:45:09.663430066 +0100
+++ gcc/cp/cp-gimplify.cc   2024-02-22 22:16:41.816591451 +0100
@@ -3415,6 +3415,10 @@ cp_fold (tree x, fold_flags_t flags)
tree s = build_fold_indirect_ref_loc (loc,
  CALL_EXPR_ARG (x, 0));
r = cp_build_init_expr (s, r);
+   if (targetm.cxx.cdtor_returns_this ())
+ r = build2 (COMPOUND_EXPR, TREE_TYPE (x), r,
+ fold_convert (TREE_TYPE (x),
+   CALL_EXPR_ARG (x, 0)));
  }
x = r;
break;
--- gcc/testsuite/g++.dg/cpp0x/constexpr-113083.C.jj2024-01-13
00:05:00.077372302 +0100
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-113083.C   2024-02-22
22:20:20.622618992 +0100
@@ -0,0 +1,16 @@
+// PR c++/113083
+// { dg-do compile { target c++11 } }
+// { dg-options "-Os" }
+
+struct A { constexpr A (); };
+
+void
+foo ()
+{
+  A b;
+}
+
+constexpr
+A::A ()
+{
+}

Though, perhaps we need cp_save_expr in that case to make sure if there were
side-effects in CALL_EXPR (x, 0) that we wouldn't evaluate them twice.

[Bug modula2/113749] [14 Regression] m2 enabled build times out on i686-gnu (GNU Hurd)

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

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

Gaius Mulley  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-22
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #2 from Gaius Mulley  ---
Confirmed.

[Bug tree-optimization/109804] [11/12 Regression] internal compiler error in gimple-ssa-warn-access.cc

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||13.2.1
Summary|[11/12/13 Regression]   |[11/12 Regression] internal
   |internal compiler error in  |compiler error in
   |gimple-ssa-warn-access.cc   |gimple-ssa-warn-access.cc

--- Comment #15 from Andrew Pinski  ---
Fixed for GCC 13.3.0 also.

[Bug tree-optimization/109804] [11/12/13 Regression] internal compiler error in gimple-ssa-warn-access.cc

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

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

--- Comment #14 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Andrew Pinski
:

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

commit r13-8354-ga15427e75f2521ed5e467e3c5cb8446586bbdabb
Author: Andrew Pinski 
Date:   Wed Feb 21 20:12:21 2024 -0800

warn-access: Fix handling of unnamed types [PR109804]

This looks like an oversight of handling DEMANGLE_COMPONENT_UNNAMED_TYPE.
DEMANGLE_COMPONENT_UNNAMED_TYPE only has the u.s_number.number set while
the code expected newc.u.s_binary.left would be valid.
So this treats DEMANGLE_COMPONENT_UNNAMED_TYPE like we treat function
paramaters
(DEMANGLE_COMPONENT_FUNCTION_PARAM) and template paramaters
(DEMANGLE_COMPONENT_TEMPLATE_PARAM).

Note the code in the demangler does this when it sets
DEMANGLE_COMPONENT_UNNAMED_TYPE:
  ret->type = DEMANGLE_COMPONENT_UNNAMED_TYPE;
  ret->u.s_number.number = num;

Committed as obvious after bootstrap/test on x86_64-linux-gnu

PR tree-optimization/109804

gcc/ChangeLog:

* gimple-ssa-warn-access.cc (new_delete_mismatch_p): Handle
DEMANGLE_COMPONENT_UNNAMED_TYPE.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wmismatched-new-delete-8.C: New test.

Signed-off-by: Andrew Pinski 
(cherry picked from commit 1076ffda6ce5e6d5fc9577deaf8233e549e5787a)

[Bug c/114058] ICE: _BitInt + asan: tree check: expected ssa_name, have view_convert_expr in has_zero_uses, at ssa-iterators.h:389

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-22
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug target/109499] Unnecessary zeroing in SVE loops

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-02-22
 CC||pinskia at gcc dot gnu.org

--- Comment #5 from Andrew Pinski  ---
Confirmed.

[Bug target/109498] SVE support for ctz

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||14.0
  Known to fail||13.2.0

--- Comment #1 from Andrew Pinski  ---
Looks to be fixed on the trunk for GCC 14.

[Bug ada/114065] New: gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

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

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

Bug ID: 114065
   Summary: gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64
fails on 32bit archs
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

trying to build with time_t64 on 32bit archs fails with:

g-socket.adb:2860:26: error: value not in range of type "time_t" defined at
g-sothco.ads:47
g-socket.adb:2860:26: error: static expression fails Constraint_Check
g-socket.adb:2862:26: error: value not in range of type "time_t" defined at
g-sothco.ads:47
g-socket.adb:2862:26: error: static expression fails Constraint_Check
make[8]: *** [../gcc-interface/Makefile:301: g-socket.o] Error 1
make[8]: Leaving directory '/<>/build/gcc/ada/rts'

this can be fixed with

--- a/gcc/ada/libgnat/s-parame.ads
+++ b/gcc/ada/libgnat/s-parame.ads
@@ -102,7 +102,7 @@
-- Characteristics of time_t type --


-   time_t_bits : constant := Long_Integer'Size;
+   time_t_bits : constant := Long_Long_Integer'Size;
--  Number of bits in type time_t

--

however that's not the correct fix. Is there any way to fix this in a better
way?

Plust, this uncovered a bootstrap error on hppa-linux See PR114062

[Bug target/114064] New: [meta-bug] Use SVE instructions more for Advanced. SIMD

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

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

Bug ID: 114064
   Summary: [meta-bug] Use SVE instructions more for Advanced.
SIMD
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: meta-bug, missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Just a meta bug to record where we could use SVE instructions for the Advanced.
SIMD modes more.

[Bug target/114063] Use IFN_CHECK_RAW_PTRS/IFN_CHECK_WAR_PTRS for Advanced. SIMD

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-02-22
 CC||pinskia at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

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

There is definitely more of these use SVE instructions to improve Advanced SIMD
autovect loops too. (I filed a few already too).

[Bug target/114063] New: Use IFN_CHECK_RAW_PTRS/IFN_CHECK_WAR_PTRS for Advanced. SIMD

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

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

Bug ID: 114063
   Summary: Use IFN_CHECK_RAW_PTRS/IFN_CHECK_WAR_PTRS for
Advanced. SIMD
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*

The following example:

void fn (short *a, short *b, short *c, int n)
{
for (int i = 0; i < n; i += 2)
{
short b0 = b[i + 0];
short b1 = b[i + 1];
a[i + 0] = b0 + 2;
a[i + 1] = b1 + 3;
}
}

when compiled with -O3 -march=armv9-a

will generate an alias check using whilewr which is the corresponding
instruction for doing alias checks using CHECK_WAR_PTRS.

But when compiling for a known CPU, such as -mcpu=neoveser-v2 the vectorizer
chooses to use Adv. SIMD for the main loop, and so the check for supporting
IFN_CHECK_WAR_PTRS fails as we only support SVE modes.

Since all that really matters is the element size, I believe we can still use
IFN_CHECK_WAR_PTRS for Adv. SIMD using the SVE instruction if SVE is allowed.

That is, we should implement the pattern for Advanced SIMD modes as well gated
on TARGET_SVE.

[Bug rtl-optimization/114062] "GNAT BUG DETECTED" 13.2.0 (hppa-linux-gnu) in remove, at alloc-pool.h:437

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||hppa-linux-gnu

--- Comment #1 from Andrew Pinski  ---
>during RTL pass: reload

:)

[Bug ada/114062] New: "GNAT BUG DETECTED" 13.2.0 (hppa-linux-gnu) in remove, at alloc-pool.h:437

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

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

Bug ID: 114062
   Summary: "GNAT BUG DETECTED" 13.2.0 (hppa-linux-gnu) in remove,
at alloc-pool.h:437
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

/<>/build/./prev-gcc/xgcc -B/<>/build/./prev-gcc/
-B/usr/hppa-linux-gnu/bin/ -B/usr/hppa-linux-gnu/bin/
-B/usr/hppa-linux-gnu/lib/ -isystem /usr/hppa-linux-gnu/include -isystem
/usr/hppa-linux-gnu/sys-include -isystem /<>/build/sys-include  
-fchecking=1 -c -g -O2 -fchecking=1 -mdisable-indexing -gnatpg  -W -Wall
-nostdinc -I- -I. -Iada/generated -Iada -I../../src/gcc/ada -Iada/libgnat
-I../../src/gcc/ada/libgnat -Iada/gcc-interface
-I../../src/gcc/ada/gcc-interface ../../src/gcc/ada/switch-c.adb -o
ada/switch-c.o
mkdir -p ada/
/<>/build/./prev-gcc/xgcc -B/<>/build/./prev-gcc/
-B/usr/hppa-linux-gnu/bin/ -B/usr/hppa-linux-gnu/bin/
-B/usr/hppa-linux-gnu/lib/ -isystem /usr/hppa-linux-gnu/include -isystem
/usr/hppa-linux-gnu/sys-include -isystem /<>/build/sys-include  
-fchecking=1 -c -g -O2 -fchecking=1 -mdisable-indexing -gnatpg  -W -Wall
-nostdinc -I- -I. -Iada/generated -Iada -I../../src/gcc/ada -Iada/libgnat
-I../../src/gcc/ada/libgnat -Iada/gcc-interface
-I../../src/gcc/ada/gcc-interface ../../src/gcc/ada/switch.adb -o ada/switch.o
during RTL pass: reload
+===GNAT BUG DETECTED==+
| 13.2.0 (hppa-linux-gnu) in remove, at alloc-pool.h:437   |
| Error detected around ../../src/gcc/ada/switch-c.adb:1642:8  |
| Compiling ../../src/gcc/ada/switch-c.adb |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

../../src/gcc/ada/gcc-interface/system.ads
../../src/gcc/ada/switch-c.adb
../../src/gcc/ada/switch-c.ads
../../src/gcc/ada/switch.ads
ada/generated/gnatvsn.ads
../../src/gcc/ada/types.ads
../../src/gcc/ada/libgnat/ada.ads
../../src/gcc/ada/libgnat/a-unccon.ads
../../src/gcc/ada/libgnat/a-uncdea.ads
../../src/gcc/ada/libgnat/s-string.ads
../../src/gcc/ada/debug.ads
../../src/gcc/ada/lib.ads
../../src/gcc/ada/alloc.ads
../../src/gcc/ada/namet.ads
../../src/gcc/ada/hostparm.ads
../../src/gcc/ada/table.ads
ada/gnat.ads
../../src/gcc/ada/libgnat/g-htable.ads
../../src/gcc/ada/libgnat/s-htable.ads
../../src/gcc/ada/osint.ads
../../src/gcc/ada/libgnat/s-os_lib.ads
../../src/gcc/ada/libgnat/s-stoele.ads
../../src/gcc/ada/opt.ads
../../src/gcc/ada/libgnat/s-wchcon.ads
../../src/gcc/ada/stylesw.ads
../../src/gcc/ada/targparm.ads
../../src/gcc/ada/rident.ads
ada/s-rident.ads
../../src/gcc/ada/ttypes.ads
../../src/gcc/ada/set_targ.ads
../../src/gcc/ada/stand.ads
../../src/gcc/ada/validsw.ads
../../src/gcc/ada/warnsw.ads
../../src/gcc/ada/libgnat/s-exctab.ads
../../src/gcc/ada/libgnat/s-stalib.ads
../../src/gcc/ada/libgnat/s-unstyp.ads
../../src/gcc/ada/libgnat/s-conca2.ads
../../src/gcc/ada/libgnat/s-secsta.ads
../../src/gcc/ada/libgnat/s-parame.ads

raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:414
make[5]: *** [../../src/gcc/ada/gcc-interface/Make-lang.in:165: ada/switch-c.o]
Error 1

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=gcc-13=hppa=13.2.0-16=1708622992=0

Has something to do with -D_TIME_BITS=64 setting.

[Bug c/114058] ICE: _BitInt + asan: tree check: expected ssa_name, have view_convert_expr in has_zero_uses, at ssa-iterators.h:389

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Better testcase which doesn't need special options, just -O2 -fsanitize=address
will do:
_BitInt(129)
foo (void)
{
  _BitInt(129) *p;
  {
_BitInt(129) r = 42;
p = 
  }
  return *p;
}

void
bar (void)
{
  _BitInt(129) *p;
  {
_BitInt(129) r = 42;
p = 
  }
  *p = 0;
}

With s/129/127/g, we get:
  r_5 = .ASAN_POISON (); [tail call]
  return r_5;
and
  r_5 = .ASAN_POISON ();
  .ASAN_POISON_USE (r_5); [tail call]
and sanopt turns that into:
  _6 = (unsigned long) 
  _7 = _6 >> 3;
  _8 = _7 + 2147450880;
  _9 = (signed char *) _8;
  MEM[(short int *)_9] = -1800;
  __builtin___asan_report_load16 ();
  return r_5(D);
and
  _6 = (unsigned long) 
  _7 = _6 >> 3;
  _8 = _7 + 2147450880;
  _9 = (signed char *) _8;
  MEM[(short int *)_9] = -1800;
  __builtin___asan_report_store16 ();

Currently bitint lowering for large/huge _BitInt rewrites this such that the
lhs of .ASAN_POISON () is typically a VIEW_CONVERT_EXPR of a VAR_DECL and ditto
for the .ASAN_POISON_USE arguments, that is something sanopt can't handle.
But we can't also easily just poison the underlying variable at .ASAN_POISON ()
call,
because the var can be reused later and we wouldn't know where to unpoison it.
We want the use after scope accesses reported by asan.
Perhaps turn the .ASAN_POISON call into .ASAN_POISON setting some other
SSA_NAME (say limb_type), replace .ASAN_POISON_USE argument with that new
SSA_NAME, keep the associated underlying VAR_DECL uninitialized and arrange the
other SSA_NAME to be somehow used whenever using the original SSA_NAME (say,
instead of actually reading from the VAR_DECL's limbs, read from the other
var).

[Bug tree-optimization/114061] GCC fails vectorization when using __builtin_prefetch

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

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

--- Comment #4 from Tamar Christina  ---
(In reply to Andrew Pinski from comment #3)
> Confirmed.
> 
> Though maybe we should drop them in the vectorized version of the loop. HW
> prefetchers usually do a decent job and sometimes (maybe most) SW hinted
> prefetches interfere with the HW prefetchers.

definitely agree that I'm not sure how useful they are, but some customers
definitely seem to want them.

[Bug libfortran/105456] Child I/O does not propage iostat

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

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

--- Comment #4 from Jerry DeLisle  ---
Created attachment 57504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57504=edit
Proposed partial patch

Proposed patch for the original test case with a READ function.

[Bug tree-optimization/114061] GCC fails vectorization when using __builtin_prefetch

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement

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

Though maybe we should drop them in the vectorized version of the loop. HW
prefetchers usually do a decent job and sometimes (maybe most) SW hinted
prefetches interfere with the HW prefetchers.

[Bug tree-optimization/114061] GCC fails vectorization when using __builtin_prefetch

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

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

--- Comment #2 from Tamar Christina  ---
(In reply to Andrew Pinski from comment #1)
> I thought there was already one recorded about this.

I could only find https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103938 about an
ICE when prefetching a vector address.

[Bug tree-optimization/114061] GCC fails vectorization when using __builtin_prefetch

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

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

--- Comment #1 from Andrew Pinski  ---
I thought there was already one recorded about this.

[Bug target/114060] asm constraints getting GOT address for ARM/FDPIC look wrong

[bugdal at aerifal dot cx via Gcc-bugs]

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

--- Comment #2 from Rich Felker  ---
How could there be such a contract? In order to call any other function, the
GOT address of the callee needs to be loaded, replacing the caller's value,
which must be spilled and reloaded if it's needed again -- but if it's not
needed again, it makes sense to just discard it.

On SH (and AFAIK FRV, the original FDPIC), GCC happily discards the FDPIC/GOT
register when it won't be used again.

Maybe as an implementation detail GCC is not doing that on ARM right now, but
if not, that's probably a big missed optimization and not something libgcc
unwinder code should be relying on.

[Bug tree-optimization/114061] New: GCC fails vectorization when using __builtin_prefetch

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

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

Bug ID: 114061
   Summary: GCC fails vectorization when using __builtin_prefetch
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---

The following example:

void foo(double * restrict a, double * restrict b, int n){
  int i;
  for(i=0; i

[Bug libgcc/114060] asm constraints getting GOT address for ARM/FDPIC look wrong

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

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

--- Comment #1 from Andrew Pinski  ---
https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt

>as there is no contract that this register permanently hold the GOT address 
>for the executing code

So I am reading the GCC code, it looks like it is though.

[Bug target/113257] -march=native or -mcpu=native are ineffective, but -march=native -mcpu=native works on arm64 M2 Ultra

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

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

--- Comment #5 from Tamar Christina  ---
(In reply to Sam James from comment #3)
> (In reply to Richard Earnshaw from comment #2)
> I'm missing why the combination then works though?

So we've made several changes here over time.

-mcpu=native does attempt to find the core id to know what it is, but since
GCC-12 we also enable extensions that don't have a requirement on an
architecture.

So for instance on an SVE capable core we would enable it, but we of course
can't enable a tuning model.

But between GCC 13 and GCC 14 many things have changes.  It looks like GCC-14
works as expected:

> ./install/bin/gcc -xc -S -o - - -march=native < /dev/null
.arch
armv8-a+flagm+dotprod+rdma+lse+crc+aes+sha3+fp16fml+rcpc+i8mm+bf16+sb+ssbs+pauth
.file   ""
.text
.ident  "GCC: (GNU) 14.0.1 20240129 (experimental)"
   
   
 .section   
.note.GNU-stack,"",@progbits

> ./install/bin/gcc -xc -S -o - - -mcpu=native < /dev/null
.arch
armv8-a+flagm+dotprod+rdma+lse+crc+aes+sha3+fp16fml+rcpc+i8mm+bf16+sb+ssbs+pauth
.file   ""
.text
.ident  "GCC: (GNU) 14.0.1 20240129 (experimental)"
   
   
 .section   
.note.GNU-stack,"",@progbits

> ./install/bin/gcc -xc -S -o - - -mcpu=native -march=native < /dev/null
.arch
armv8-a+flagm+dotprod+rdma+lse+crc+aes+sha3+fp16fml+rcpc+i8mm+bf16+sb+ssbs+pauth
.file   ""
.text
.ident  "GCC: (GNU) 14.0.1 20240129 (experimental)"
   
   
 .section   
.note.GNU-stack,"",@progbits

So first question is, can you confirm it does for GCC-14 for you too?

In the meantime I'll try GCC-13

[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #28 from Jakub Jelinek  ---
Fixed.

[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)

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

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

--- Comment #27 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:37127ed975e09813eaa2d1cf1062055fce45dd16

commit r14-9139-g37127ed975e09813eaa2d1cf1062055fce45dd16
Author: Jakub Jelinek 
Date:   Thu Feb 22 19:32:02 2024 +0100

c: Handle scoped attributes in __has*attribute and scoped attribute parsing
changes in -std=c11 etc. modes [PR114007]

We aren't able to parse __has_attribute (vendor::attr) (and
__has_c_attribute
and __has_cpp_attribute) in strict C < C23 modes.  While in -std=gnu* modes
or in -std=c23 there is CPP_SCOPE token, in -std=c* (except for -std=c23)
there are is just a pair of CPP_COLON tokens.
The c-lex.cc hunk adds support for that.

That leads to a question if we should return 1 or 0 from
__has_attribute (gnu::unused) or not, because while
[[gnu::unused]] is parsed fine in -std=gnu*/-std=c23 modes (sure, with
pedwarn for < C23), we do not parse it at all in -std=c* (except for
-std=c23), we only parse [[__extension__ gnu::unused]] there.  While
the __extension__ in there helps to avoid the pedwarn, I think it is
better to be consistent between GNU and strict C < C23 modes and
parse [[gnu::unused]] too; on the other side, I think parsing
[[__extension__ gnu : : unused]] is too weird and undesirable.

So, the following patch adds a flag during preprocessing at the point
where we normally create CPP_SCOPE tokens out of 2 consecutive colons
on the first CPP_COLON to mark the consecutive case (as we are tight
on the bits, I've reused the PURE_ZERO flag, which is used just by the
C++ FE and only ever set (both C and C++) on CPP_NUMBER tokens, this
new flag has the same value and is only ever used on CPP_COLON tokens)
and instead of checking loose_scope_p argument (i.e. whether it is
[[__extension__ ...]] or not), it just parses CPP_SCOPE or CPP_COLON
with CLONE_SCOPE flag followed by another CPP_COLON the same.
The latter will never appear in >= C23 or -std=gnu* modes, though
guarding its use say with flag_iso && !flag_isoc23 && doesn't really
work because the __extension__ case temporarily clears flag_iso flag.

This makes the -std=c11 etc. behavior more similar to -std=gnu11 or
-std=c23, the only difference I'm aware of are the
 #define JOIN2(A, B) A##B
 [[vendor JOIN2(:,:) attr]]
 [[__extension__ vendor JOIN2(:,:) attr]]
cases, which are accepted in the latter modes, but results in error
in -std=c11; but the error is during preprocessing that :: doesn't
form a valid preprocessing token, which is true, so just don't do that if
you try to have __STRICT_ANSI__ && __STDC_VERSION__ <= 201710L
compatibility.

2024-02-22  Jakub Jelinek  

PR c/114007
gcc/
* doc/extend.texi: (__extension__): Remove comments about scope
tokens vs. two colons.
gcc/c-family/
* c-lex.cc (c_common_has_attribute): Parse 2 CPP_COLONs with
the first one with COLON_SCOPE flag the same as CPP_SCOPE.
gcc/c/
* c-parser.cc (c_parser_std_attribute): Remove loose_scope_p
argument.
Instead of checking it, parse 2 CPP_COLONs with the first one with
COLON_SCOPE flag the same as CPP_SCOPE.
(c_parser_std_attribute_list): Remove loose_scope_p argument, don't
pass it to c_parser_std_attribute.
(c_parser_std_attribute_specifier): Adjust
c_parser_std_attribute_list
caller.
gcc/testsuite/
* gcc.dg/c23-attr-syntax-6.c: Adjust testcase for :: being valid
even in -std=c11 even without __extension__ and : : etc. not being
valid anymore even with __extension__.
* gcc.dg/c23-attr-syntax-7.c: Likewise.
* gcc.dg/c23-attr-syntax-8.c: New test.
libcpp/
* include/cpplib.h (COLON_SCOPE): Define to PURE_ZERO.
* lex.cc (_cpp_lex_direct): When lexing CPP_COLON with another
colon after it, if !CPP_OPTION (pfile, scope) set COLON_SCOPE
flag on the first CPP_COLON token.

[Bug libgcc/114060] New: asm constraints getting GOT address for ARM/FDPIC look wrong

[bugdal at aerifal dot cx via Gcc-bugs]

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

Bug ID: 114060
   Summary: asm constraints getting GOT address for ARM/FDPIC look
wrong
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

Reading the code added for unwind-pe.h for FDPIC, I came across the ARM
implementation that uses FDPIC_REGNUM as an input constraint to __asm to get
the GOT register value. As I understand it, this is not correct, as there is no
contract that this register permanently hold the GOT address for the executing
code; it's just a hidden argument register for making function calls, which the
callee can throw away if it does not need to access the GOT or any global data,
or spill and reload.

To reliably get the GOT register, I think you need to make an actual external
call to an asm function that movs the GOT register to the return-value register
and returns.

[Bug target/114057] [14 Regression] 435.gromacs fails verification on with -Ofast -march=znver4 and PGO

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

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

--- Comment #2 from Filip Kastl  ---
Hm, seems like g:eb619490b01baa2f actually doesn't miscompare. My bad.

[Bug target/114057] [14 Regression] 435.gromacs fails verification on with -Ofast -march=znver4 and PGO

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

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

--- Comment #1 from Filip Kastl  ---
The oldest commit with this miscomparison i found so far is g:eb619490b01baa2f.
The most recent commit without the miscomparison i found so far is
g:405096f908e1ceb0.

[Bug rtl-optimization/114054] ICE: in reduce_to_bit_field_precision, at expr.cc:12658 with -Og -fwhole-program -fno-tree-ccp -fprofile-use -fno-tree-copy-prop and _BitInt()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-02-22
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 57503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57503=edit
gcc14-pr114054.patch

Untested fix.

[Bug c/114042] diagnostics about __builtin_stdc_bit_ceil() mentions __builtin_clzg()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 57502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57502=edit
gcc14-pr114042.patch

Actually it isn't that bad.

[Bug tree-optimization/109804] [11/12/13 Regression] internal compiler error in gimple-ssa-warn-access.cc

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail|14.0|
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
   |internal compiler error in  |internal compiler error in
   |gimple-ssa-warn-access.cc   |gimple-ssa-warn-access.cc
  Known to work||14.0

--- Comment #13 from Andrew Pinski  ---
Fixed on the trunk so far.

[Bug tree-optimization/109804] [11/12/13/14 Regression] internal compiler error in gimple-ssa-warn-access.cc

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

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

--- Comment #12 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:1076ffda6ce5e6d5fc9577deaf8233e549e5787a

commit r14-9138-g1076ffda6ce5e6d5fc9577deaf8233e549e5787a
Author: Andrew Pinski 
Date:   Wed Feb 21 20:12:21 2024 -0800

warn-access: Fix handling of unnamed types [PR109804]

This looks like an oversight of handling DEMANGLE_COMPONENT_UNNAMED_TYPE.
DEMANGLE_COMPONENT_UNNAMED_TYPE only has the u.s_number.number set while
the code expected newc.u.s_binary.left would be valid.
So this treats DEMANGLE_COMPONENT_UNNAMED_TYPE like we treat function
paramaters
(DEMANGLE_COMPONENT_FUNCTION_PARAM) and template paramaters
(DEMANGLE_COMPONENT_TEMPLATE_PARAM).

Note the code in the demangler does this when it sets
DEMANGLE_COMPONENT_UNNAMED_TYPE:
  ret->type = DEMANGLE_COMPONENT_UNNAMED_TYPE;
  ret->u.s_number.number = num;

Committed as obvious after bootstrap/test on x86_64-linux-gnu

PR tree-optimization/109804

gcc/ChangeLog:

* gimple-ssa-warn-access.cc (new_delete_mismatch_p): Handle
DEMANGLE_COMPONENT_UNNAMED_TYPE.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wmismatched-new-delete-8.C: New test.

Signed-off-by: Andrew Pinski 

[Bug c++/104111] [DR2589] Concept evaluation depends on context where it was first checked

[steve+gcc at tecwec dot eu via Gcc-bugs]

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

Eric Estievenart  changed:

   What|Removed |Added

 CC||steve+gcc at tecwec dot eu

--- Comment #9 from Eric Estievenart  ---
By the way, the following code exhibits another related weirdness, without
access control being involved:
```
#include 
struct Op
{
void operator()( auto x ) const = delete; // want only explicit
customization in scope
};

struct S {};
static_assert( !std::invocable );
template<> void Op::operator()( S ) const {}  // now Op is invocable on S
static_assert( std::invocable );   // so should not fail ! but...
```
(https://godbolt.org/z/Wa6rxeMvP)

Commenting the first assert makes the second suddenly pass...

Quantum physicist would say "spooky action at a distance" ;-)
Hope this helps,
Best.

[Bug tree-optimization/111770] predicated loads inactive lane values not modelled

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

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

--- Comment #6 from Joseph S. Myers  ---
X + 0. -> X is invalid for FP with signed zero or signaling NaN, and also gets
the wrong quantum exponent for decimal FP unless the zero has the maximum
possible quantum exponent (which is not what you get from all bits of the
representation zero, which is a zero with the minimum possible quantum
exponent, or from converting integer 0 to DFP, which has quantum exponent 0).

(If you add -0. (with maximum quantum exponent, in the DFP case) instead of
+0., that does produce X for X not a signaling NaN - except in FE_DOWNWARD
mode. Whereas adding +0. is only correct in FE_DOWNWARD mode, since 0. - 0. has
positive sign in all other modes.)

[Bug rtl-optimization/114044] ICE: in expand_fn_using_insn, at internal-fn.cc:208 with _BitInt() and -O -fno-tree-dce

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

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

--- Comment #3 from Jakub Jelinek  ---
Smaller testcase:
void
foo (void)
{
  unsigned _BitInt(256) a = 3;
  __builtin_clzg (a);
}

The thing is that in this testcase bitint lowering doesn't even know it should
do anything.
The whole behavior of the pass is keyed on there being any SSA_NAMEs for
middle/large/huge BITINT_TYPE with some extra exceptions (it looks at virtual
SSA_NAMEs to see if there isn't a memory store of a middle+ _BitInt INTEGER_CST
and for scalar floating point SSA_NAMEs if they aren't computed from conversion
from middle+ _BitInt INTEGER_CSTs), and even if the pass for some other reason
triggers in the function,
it will not look at statements which don't have any large+ _BitInt SSA_NAMEs,
or are large+ _BitInt INTEGER_CST store or FLOAT_EXPR from large+ _BitInt
INTEGER_CST or the overflow ifns with _Complex large+ _BitInt result.
We really don't want to lower those ifns like
.CLZ/.CTZ/.CLRSB/.POPCOUNT/.PARITY/.FFS
with INTEGER_CST operands, or after all even say .ADD_OVERFLOW (0, 1) where
just operands are large/huge _BitInt but say _Complex int result, those are all
expected to be folded instead.
Now, if s/^void/int;s/__builtin/return &/' above, we fold it in
gimple_fold_stmt_to_constant_1:
#0  wi::clz (x=...) at ../../gcc/wide-int.cc:2164
#1  0x008a9d9b in fold_const_call_ss (result=0x7fffc4e0,
fn=CFN_CLZ, arg=..., precision=32, arg_type=) at
../../gcc/fold-const-call.cc:1029
#2  0x008aa9a5 in fold_const_call_1 (fn=CFN_CLZ, type=, arg=) at
../../gcc/fold-const-call.cc:1254
#3  0x008ab4d6 in fold_const_call (fn=CFN_CLZ, type=, arg=) at
../../gcc/fold-const-call.cc:1385
#4  0x0189d6e0 in gimple_resimplify1 (seq=0x0, res_op=0x7fffc980,
valueize=0xf42f7d ) at
../../gcc/gimple-match-exports.cc:925
#5  0x0189b419 in gimple_match_op::resimplify (this=0x7fffc980,
seq=0x0, valueize=0xf42f7d ) at
../../gcc/gimple-match-exports.cc:111
#6  0x0189d5b3 in gimple_simplify (stmt=,
res_op=0x7fffc980, seq=0x0, valueize=0xf42f7d , 
top_valueize=0xf42f41 ) at
../../gcc/gimple-match-exports.cc:898
#7  0x0090986a in gimple_fold_stmt_to_constant_1 (stmt=, valueize=0xf42f41 , gvalueize=0xf42f7d
)
at ../../gcc/gimple-fold.cc:7551
#8  0x00f4308a in ccp_fold (stmt=) at
../../gcc/tree-ssa-ccp.cc:1290
#9  0x00f48d1b in evaluate_stmt (stmt=) at
../../gcc/tree-ssa-ccp.cc:2228
or with extra -fno-tree-ccp in:
#0  wi::clz (x=...) at ../../gcc/wide-int.cc:2164
#1  0x008a9d9b in fold_const_call_ss (result=0x7fffceb0,
fn=CFN_CLZ, arg=..., precision=32, arg_type=) at
../../gcc/fold-const-call.cc:1029
#2  0x008aa9a5 in fold_const_call_1 (fn=CFN_CLZ, type=, arg=) at
../../gcc/fold-const-call.cc:1254
#3  0x008ab4d6 in fold_const_call (fn=CFN_CLZ, type=, arg=) at
../../gcc/fold-const-call.cc:1385
#4  0x0189d6e0 in gimple_resimplify1 (seq=0x7fffd278,
res_op=0x7fffd200, valueize=0xf811c3 ) at
../../gcc/gimple-match-exports.cc:925
#5  0x0189b419 in gimple_match_op::resimplify (this=0x7fffd200,
seq=0x7fffd278, valueize=0xf811c3 ) at
../../gcc/gimple-match-exports.cc:111
#6  0x0189d5b3 in gimple_simplify (stmt=,
res_op=0x7fffd200, seq=0x7fffd278, valueize=0xf811c3
, 
top_valueize=0xf811c3 ) at
../../gcc/gimple-match-exports.cc:898
#7  0x009060dd in fold_stmt_1 (gsi=0x7fffd630, inplace=false,
valueize=0xf811c3 ) at ../../gcc/gimple-fold.cc:6359
#8  0x00906833 in fold_stmt (gsi=0x7fffd630, valueize=0xf811c3
) at ../../gcc/gimple-fold.cc:6525
or with extra -fno-tree-ccp -fno-tree-forwprop in:
#0  wi::clz (x=...) at ../../gcc/wide-int.cc:2164
#1  0x008a9d9b in fold_const_call_ss (result=0x7fffcd50,
fn=CFN_CLZ, arg=..., precision=32, arg_type=) at
../../gcc/fold-const-call.cc:1029
#2  0x008aa9a5 in fold_const_call_1 (fn=CFN_CLZ, type=, arg=) at
../../gcc/fold-const-call.cc:1254
#3  0x008ab4d6 in fold_const_call (fn=CFN_CLZ, type=, arg=) at
../../gcc/fold-const-call.cc:1385
#4  0x0189d6e0 in gimple_resimplify1 (seq=0x0, res_op=0x7fffd1f0,
valueize=0x906784 ) at
../../gcc/gimple-match-exports.cc:925
#5  0x0189b419 in gimple_match_op::resimplify (this=0x7fffd1f0,
seq=0x0, valueize=0x906784 ) at
../../gcc/gimple-match-exports.cc:111
#6  0x0189d5b3 in gimple_simplify (stmt=,
res_op=0x7fffd1f0, seq=0x0, valueize=0x906784
, 
top_valueize=0x106aeba ) at
../../gcc/gimple-match-exports.cc:898
#7  0x0090986a in gimple_fold_stmt_to_constant_1 (stmt=, valueize=0x106aeba , 
gvalueize=0x906784 ) at
../../gcc/gimple-fold.cc:7551
#8  0x0106502d in visit_stmt (stmt=,
backedges_varying_p=false) at ../../gcc/tree-ssa-sccvn.cc:6419
etc.
But somehow none of that triggers if the internal fn doesn't have lhs, we just
rely on DCE and DCE can be disabled.
Dunno, shall we just ignore those during expansion if they don't have 

[Bug target/114059] New: ICE in extract_insn, at recog.cc:2812 | sme2 vs -fsanitize=address -mtrack-speculation -fharden-control-flow-redundancy

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

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

Bug ID: 114059
   Summary: ICE in extract_insn, at recog.cc:2812 | sme2 vs
-fsanitize=address -mtrack-speculation
-fharden-control-flow-redundancy
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---

Compiling reduced testcase gcc.target/aarch64/sme/sibcall_9.c results in ICE,
since sme2 was introduced in r14-6175-g3b58b2205ffdce.

$ cat sibcall_9.c
#pragma GCC target "+sme2"
void caller_preserves() __arm_inout("za") {}


$ aarch64-linux-gnu-gcc sibcall_9.c -fsanitize=address -mtrack-speculation
-fharden-control-flow-redundancy
sibcall_9.c: In function ‘caller_preserves’:
sibcall_9.c:2:44: error: unrecognizable insn:
2 | void caller_preserves() __arm_inout("za") {}
  |^
(jump_insn 156 155 157 (set (pc)
(if_then_else (ne (reg:DI 16 x16)
(const_int 0 [0]))
(label_ref 160)
(pc))) -1
 (int_list:REG_BR_PROB 1073204964 (nil))
 -> 160)
during RTL pass: split5
sibcall_9.c:2:44: internal compiler error: in extract_insn, at recog.cc:2812
0x16f34de _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/mjires/git/GCC/master/gcc/rtl-error.cc:108
0x16f351f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/mjires/git/GCC/master/gcc/rtl-error.cc:116
0x16a4044 extract_insn(rtx_insn*)
/home/mjires/git/GCC/master/gcc/recog.cc:2812
0x16a3d03 extract_insn_cached(rtx_insn*)
/home/mjires/git/GCC/master/gcc/recog.cc:2701
0x1203628 cleanup_subreg_operands(rtx_insn*)
/home/mjires/git/GCC/master/gcc/final.cc:3053
0x16a581d split_insn
/home/mjires/git/GCC/master/gcc/recog.cc:3441
0x16a5b01 split_all_insns_noflow()
/home/mjires/git/GCC/master/gcc/recog.cc:3567
0x16a7b40 execute
/home/mjires/git/GCC/master/gcc/recog.cc:4641
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/aarch64-linux-gnu/14.0.1/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=aarch64-linux-gnu
--disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib
--disable-libsanitizer --enable-checking : (reconfigured)
/home/mjires/git/GCC/master/configure --prefix=/home/mjires/built/master
--target=aarch64-linux-gnu --disable-bootstrap --enable-languages=c,c++,fortran
--disable-multilib --disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240222 (experimental) (GCC)

[Bug c/114058] New: ICE: _BitInt + asan: tree check: expected ssa_name, have view_convert_expr in has_zero_uses, at ssa-iterators.h:389

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

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

Bug ID: 114058
   Summary: ICE: _BitInt + asan: tree check: expected ssa_name,
have view_convert_expr in has_zero_uses, at
ssa-iterators.h:389
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at gcc dot gnu.org
CC: jakub at redhat dot com
  Target Milestone: ---

Compiling reduced testcase gcc.dg/torture/bitint-35.c results in ICE, since
_BitInt was introduced in r14-3751-g8c984a1c3693df.

$ cat bitint-35.c
_BitInt(129) foo() {
  _BitInt(129) r;
  
}


$ gcc bitint-35.c -fsanitize=address -Og -fno-tree-dce
during GIMPLE pass: sanopt
bitint-35.c: In function ‘foo’:
bitint-35.c:1:14: internal compiler error: tree check: expected ssa_name, have
view_convert_expr in has_zero_uses, at ssa-iterators.h:389
1 | _BitInt(129) foo() {
  |  ^~~
0x1ac77e1 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/mjires/git/GCC/master/gcc/tree.cc:8955
0xd2f6f5 tree_check(tree_node const*, char const*, int, char const*, tree_code)
/home/mjires/git/GCC/master/gcc/tree.h:3900
0xfa0dfd has_zero_uses(tree_node const*)
/home/mjires/git/GCC/master/gcc/ssa-iterators.h:389
0x1714f27 asan_expand_poison_ifn(gimple_stmt_iterator*, bool*,
hash_map, tree_node*> >&)
/home/mjires/git/GCC/master/gcc/asan.cc:4104
0x172b021 execute
/home/mjires/git/GCC/master/gcc/sanopt.cc:1382
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --disable-bootstrap
--enable-languages=c,c++,fortran,lto --disable-multilib --disable-libsanitizer
--enable-checking : (reconfigured) /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --disable-bootstrap
--enable-languages=c,c++,fortran,lto --disable-multilib --disable-libsanitizer
--enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240222 (experimental) (GCC)

[Bug c++/59465] [11/12/13/14 Regression] g++ allows direct-initialization of an array of class type from another array in a mem-initializer

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

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

--- Comment #6 from Marek Polacek  ---
Started to be accepted with r0-110915-ga034826198b771:
https://gcc.gnu.org/pipermail/gcc-patches/2011-August/320236.html
which was supposed to be a cleanup, not a deliberate change to start accepting
the code.

[Bug target/114057] New: [14 Regression] 435.gromacs fails verification on with -Ofast -march=znver4 and PGO

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

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

Bug ID: 114057
   Summary: [14 Regression] 435.gromacs fails verification on with
-Ofast -march=znver4 and PGO
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: needs-bisection, wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pheeck at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Compiling the 2006 CPU benchmark 435.gromacs on an AMD Zen4 CPU with -Ofast
-march=native and PGO using the current trunk GCC and running the benchmark
results in the following miscomparison:

 0002:  3.07684e+02
3.11606e+02
  ^

According to https://www.spec.org/cpu2006/Docs/435.gromacs.html
> The gromacs.out results shouldn't differ by more than 1.25% from the 
> reference values
And this difference is ~1.27%.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/113441] [14 Regression] Fail to fold the last element with multiple loop since g:2efe3a7de0107618397264017fb045f237764cc7

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

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

Tamar Christina  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|[14 Regression] Fail to |[14 Regression] Fail to
   |fold the last element with  |fold the last element with
   |multiple loop   |multiple loop since
   ||g:2efe3a7de0107618397264017
   ||fb045f237764cc7
   Last reconfirmed||2024-02-22
 Status|UNCONFIRMED |NEW
   Keywords|needs-bisection |

--- Comment #26 from Tamar Christina  ---
(In reply to Richard Biener from comment #18)
> (In reply to Tamar Christina from comment #17)
> > Ok, bisected to
> > 
> > g:2efe3a7de0107618397264017fb045f237764cc7 is the first bad commit
> > commit 2efe3a7de0107618397264017fb045f237764cc7
> > Author: Hao Liu 
> > Date:   Wed Dec 6 14:52:19 2023 +0800
> > 
> > tree-optimization/112774: extend the SCEV CHREC tree with a nonwrapping
> > flag
> > 
> > Before this commit we were unable to analyse the stride of the access.
> > After this niters seems to estimate the loop trip count at 4 and after that
> > the logs diverge enormously.
> 
> Hum, but that's backward and would match to what I said in comment#2 - we
> should get better code with that.
> 

Ok, so I've dug more into this today.  It's definitely this commit that's
causing it.  The reason is we no longer consider masked gather/scatters.

Before this commit we the gather pattern would trigger:

tresg.i:3:275: note:   gather/scatter pattern: detected: a[_2] = b.3_3;
   
   
 tresg.i:3:275: note:   gather_scatter pattern
recognized: .SCATTER_STORE ((sizetype) , _2, 4, b.3_3);   

and the use of the masked scatter is what's causing the epilogue to not be
required and why it generates better code.  It's not the loads.

The issue is that vect_analyze_data_refs only considers gather/scatters IF DR
analysis fails, which it did before:

tresg.c:31:29: missed:  failed: evolution of offset is not affine.
base_address:
offset from base address:
constant offset from base address:
step:
base alignment: 0
base misalignment: 0
offset alignment: 0
step alignment: 0
base_object: array1
Access function 0: {{m_112 * 2, +, 24}_3, +, 2}_4
Access function 1: 0
Creating dr for array1[0][_8]

this now succeeds after the quoted commit:

success.
base_address: 
offset from base address: (ssizetype) ((sizetype) (m_111 * 2) * 2)
constant offset from base address: 0
step: 4
base alignment: 8
base misalignment: 0
offset alignment: 4
step alignment: 4
base_object: array1
Access function 0: {{m_112 * 2, +, 24}_3, +, 2}_4
Access function 1: 0
Creating dr for array1[0][_8]

so we never enter

  /* Check that analysis of the data-ref succeeded.  */
  if (!DR_BASE_ADDRESS (dr) || !DR_OFFSET (dr) || !DR_INIT (dr)
  || !DR_STEP (dr))
{

and without the IFN scatters it tries deinterleaving scalar stores to scatters:

tresg.c:29:22: note:   Detected single element interleaving array1[0][_8] step
4
tresg.c:29:22: note:   Detected single element interleaving array1[1][_8] step
4
tresg.c:29:22: note:   Detected single element interleaving array1[2][_8] step
4
tresg.c:29:22: note:   Detected single element interleaving array1[3][_8] step
4
tresg.c:29:22: note:   Detected single element interleaving array1[0][_1] step
4
tresg.c:29:22: note:   Detected single element interleaving array1[1][_1] step
4
tresg.c:29:22: note:   Detected single element interleaving array1[2][_1] step
4
tresg.c:29:22: note:   Detected single element interleaving array1[3][_1] step
4
tresg.c:29:22: missed:   not consecutive access array2[_4][_8] = _70;
tresg.c:29:22: note:   using strided accesses
tresg.c:29:22: missed:   not consecutive access array2[_4][_1] = _68;
tresg.c:29:22: note:   using strided accesses

...

tresg.c:29:22: note:   using gather/scatter for strided/grouped access, scale =
2

but without the SCATTER_STORE IFN it never tries masking the scatter, so we
lose MASK_SCATTER_STORE and hence we generate worse code because the whole loop
can no longer be predicated

However trying to force it generates an ICE so I guess it's not that simple.

[Bug c++/113970] [14 Regression] pch/system-{1,2}.C fails on darwin after r14-8987-gdd9d14f7d53

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

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

--- Comment #4 from Iain Sandoe  ---
Created attachment 57501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57501=edit
without PCH

As Andrew says, the differences are in the debug info (it might even only be in
the order of the debug info - hard to tell from a quick comparison).

[Bug c++/113970] [14 Regression] pch/system-{1,2}.C fails on darwin after r14-8987-gdd9d14f7d53

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

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

--- Comment #3 from Iain Sandoe  ---
Created attachment 57500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57500=edit
with PCH

[Bug ipa/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP

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

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

--- Comment #18 from Aldy Hernandez  ---
(In reply to rguent...@suse.de from comment #17)
> On Wed, 21 Feb 2024, aldyh at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
> > 
> > --- Comment #8 from Aldy Hernandez  ---
> > (In reply to Richard Biener from comment #5)
> > > (In reply to Martin Jambor from comment #4)
> > > > The right place where to free stuff in lattices post-IPA would be in
> > > > ipa_node_params::~ipa_node_params() where we should iterate over 
> > > > lattices
> > > > and deinitialize them or perhaps destruct the array because since
> > > > ipcp_vr_lattice directly contains Value_Range which AFAIU directly 
> > > > contains
> > > > int_range_max which has a virtual destructor... does not look like a POD
> > > > anymore.  This has escaped me when I was looking at the IPA-VR changes 
> > > > but
> > > > hopefully it should not be too difficult to deal with.
> > > 
> > > OK, that might work for the IPA side.
> > > 
> > > It's quite unusual to introduce a virtual DTOR in the middle of the class
> > > hierarchy though.  Grepping I do see quite some direct uses of 'irange'
> > > and also 'vrange' which do not have the DTOR visible but 'irange' already
> > > exposes and uses 'maybe_resize'.  I think those should only be introduced
> > > in the class exposing the virtual DTOR (but why virtual?!).
> > > 
> > > Would be nice to have a picture of the range class hierarchies with
> > > pointers on which types to use in which circumstances ...
> > 
> > For reference, you should always use the most base class you can.  If
> > you can get the work done with the vrange API, use that.  If you're
> > dealing with an integer, use irange.  The int_range<> derived class
> > should only be used for defining a variable, so:
> > 
> > int_range<123> foobar; // Defined with storage.
> > 
> > if (is_a )
> > {
> >   irange  = as_a  (foobar);
> >   ...
> > }
> > 
> > // Use an irange reference here, not an int_range reference.
> > void somefunc (const irange )
> > {
> > }
> > 
> > Also, the reason irange does not have a destructor is because it has
> > no storage.  Only int_range<> has storage associated with it, so it is
> > the only one able to see if the range grew:
> 
> But when I do
> 
>  irange *r = new int_range<>;
>  delete r;
> 
> then it will fail to release memory?  Are virtual DTORs not exactly
> invented for this, when you delete on a reference/pointer to a base
> class but the object is really a derived one?

There is no memory to release above, as int_range<> does not grow by default. 
Only int_range_max can grow, and it's meant to live on the stack by design. 
That was the whole point:

typedef int_range<3, /*RESIZABLE=*/true> int_range_max;

I suppose if you specifically wanted to shoot yourself in the foot, you could
do:

irange *r = new int_range<5, true>;

...and that would fail to release memory, but why would you do that?  If you're
allocating a lot of ranges, we have the vrange_allocator written specifically
for that, which is a lot less memory intensive.  It's what we use in the cache.

If ranges are anywhere but the stack, they should go through the allocator
which will squish down things appropriately, as iranges are very big.  The
ipa_vr class also uses the allocator in order to keep the memory footprint
down.

I guess it wouldn't hurt to have a virtual destructor in irange or even vrange
for future proofing, but it's not needed right now.  I don't have any strong
opinions, unless there's a performance penalty.

[Bug target/114017] RISC-V: wrong __riscv_v_intrinsic predefined macro value (14.x)

[maksim.shabunin at gmail dot com via Gcc-bugs]

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

Maksim Shabunin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Maksim Shabunin  ---
Verified with version riscv64-unknown-linux-gnu-g++ (g7d8585c0c0e) 14.0.1
20240222 (experimental) (branch master).

[Bug target/107270] [11/12/13/14 Regression] return for structure is not as good as before

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

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

Richard Earnshaw  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Richard Earnshaw  ---
Successfully matched this instruction:
(set (reg/i:DI 0 x0)
(ior:DI (and:DI (reg/v:DI 92 [ b ])
(const_int 4294967295 [0x]))
(ashift:DI (subreg:DI (reg:SI 100) 0)
(const_int 32 [0x20]
rejecting combination of insns 10 and 15
original costs 4 + 4 = 8
replacement cost 12

But this is just BFI, so it's a costing issue.

[Bug c++/59465] [11/12/13/14 Regression] g++ allows direct-initialization of an array of class type from another array in a mem-initializer

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

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

--- Comment #5 from Marek Polacek  ---
We accept the test because we do

  else if (type_build_ctor_call (type)
   || (init && CLASS_TYPE_P (strip_array_types (type
{
  if (TREE_CODE (type) == ARRAY_TYPE)
{
  if (init == NULL_TREE
  || same_type_ignoring_top_level_qualifiers_p (type,
TREE_TYPE (init)))
{
  if (TYPE_DOMAIN (type) && TYPE_MAX_VALUE (TYPE_DOMAIN (type)))
{
  /* Initialize the array only if it's not a flexible
 array member (i.e., if it has an upper bound).  */
  init = build_vec_init_expr (type, init, tf_warning_or_error);
  init = cp_build_init_expr (decl, init);
  finish_expr_stmt (init);

which results in something like

((struct O *) this)->a = <<< Unknown tree: vec_init_expr
  D.2843
  VIEW_CONVERT_EXPR(data) >>>

[Bug target/111076] RISC-V: segmentation fault during RTL pass: shorten (debug build)

[maksim.shabunin at gmail dot com via Gcc-bugs]

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

Maksim Shabunin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Maksim Shabunin  ---
Verified with version riscv64-unknown-linux-gnu-g++ (g128d9cc0599) 13.2.1
20240220 (branch releases/gcc-13).

[Bug target/112375] [14 Regression] vget_set_lane_1.c fails

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:7d8585c0c0e5934780281abdee256ae6553e56e8

commit r14-9137-g7d8585c0c0e5934780281abdee256ae6553e56e8
Author: Tamar Christina 
Date:   Thu Feb 22 15:32:08 2024 +

AArch64: update vget_set_lane_1.c test output

In the vget_set_lane_1.c test the following entries now generate a zip1
instead of an INS

BUILD_TEST (float32x2_t, float32x2_t, , , f32, 1, 0)
BUILD_TEST (int32x2_t,   int32x2_t,   , , s32, 1, 0)
BUILD_TEST (uint32x2_t,  uint32x2_t,  , , u32, 1, 0)

This is because the non-Q variant for indices 0 and 1 are just shuffling
values.
There is no perf difference between INS SIMD to SIMD and ZIP on Arm uArches
but
preferring the INS alternative has a drawback on all uArches as ZIP being a
three
operand instruction can be used to tie the result to the return register
whereas
INS would require an fmov.

As such just update the test file for now.

gcc/testsuite/ChangeLog:

PR target/112375
* gcc.target/aarch64/vget_set_lane_1.c: Update test output.

[Bug analyzer/105898] RFE: -fanalyzer should complain about overlapping args to memcpy and mempcpy

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

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

--- Comment #4 from David Malcolm  ---
I implemented this a different way, for memcpy, in r14-3556-g034d99e81484fb (by
special-casing it).

We don't yet check mempcpy, wmemcpy, or wmempcp; keeping bug open to handle
those.

[Bug modula2/114055] poor error message generated during when checking the BY constant expression type

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Gaius Mulley  ---
Closing now the patch has been applied.

[Bug modula2/114055] poor error message generated during when checking the BY constant expression type

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r14-9136-gc1667b1ef538e4da10cf83bdf1ae62d7bdd96128
Author: Gaius Mulley 
Date:   Thu Feb 22 15:02:19 2024 +

PR modula2/114055 improve error message when checking the BY constant

The fix marks a constant created during the default BY clause of the
FOR loop as internal.  The type checker will always return true if
checking against an internal const.

gcc/m2/ChangeLog:

PR modula2/114055
* gm2-compiler/M2Check.mod (Import): IsConstLitInternal and
IsConstLit.
(isInternal): New procedure function.
(doCheck): Test for isInternal in either operand and early
return true.
* gm2-compiler/M2Quads.mod (PushOne): Rewrite with extra
parameter internal.
(BuildPseudoBy): Add TRUE parameter to PushOne call.
(BuildIncProcedure): Add FALSE parameter to PushOne call.
(BuildDecProcedure): Add FALSE parameter to PushOne call.
* gm2-compiler/M2Range.mod (ForLoopBeginTypeCompatible):
Uncomment code and tidy up error string.
* gm2-compiler/SymbolTable.def (PutConstLitInternal):
New procedure.
(IsConstLitInternal): New procedure function.
* gm2-compiler/SymbolTable.mod (PutConstLitInternal):
New procedure.
(IsConstLitInternal): New procedure function.
(SymConstLit): New field IsInternal.
(CreateConstLit): Initialize IsInternal to FALSE.

gcc/testsuite/ChangeLog:

PR modula2/114055
* gm2/pim/fail/forloopby.mod: New test.
* gm2/pim/pass/forloopby2.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug target/100799] Stackoverflow in optimized code on PPC

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

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

--- Comment #26 from Jakub Jelinek  ---
(In reply to Peter Bergner from comment #25)
> CCing Mike and David for possible comments about the possible workarounds
> mentioned in Comment 23 and Comment 24.

Doing the workaround on the caller side is impossible, this is for calls from
C/C++ to Fortran code, directly or indirectly called and there is nothing the
compiler could use to guess that it actually calls Fortran code with hidden
Fortran character arguments.
But I still think the workaround is possible on the callee side.
Sure, if the DECL_HIDDEN_STRING_LENGTH argument(s) is(are) used in the
function, then there is no easy way but expect the parameter save area (ok,
sure, it could just load from the assumed parameter location and don't assume
the rest is there, nor allow storing to the slots it loaded them from).
But that is actually not what BLAS etc. suffers from.
If you have something like
subroutine foo (a, b, c, d, e, f, g, h)
  character a
  integer b, c, d, e, f, g, h
  call bar (a, b, c, d, e, f, g, h)
end subroutine foo
then the DECL_HIDDEN_STRING_LENGTH argument isn't used at all, on the callee
side the user said that one should treat it as if the length of a is 1, so
whatever the caller passes is unimportant and when passing to further calls it
will just use 1:
void foo (character(kind=1)[1:1] & restrict a, integer(kind=4) & restrict b,
integer(kind=4) & restrict c, integer(kind=4) & restrict d, integer(kind=4) &
restrict e, integer(kind=4) & restrict f, integer(kind=4) & restrict g,
integer(kind=4) & restrict h, integer(kind=8) _a)
{
   :
  bar (a_2(D), b_3(D), c_4(D), d_5(D), e_6(D), f_7(D), g_8(D), h_9(D), 1);
  return;

}
It would seem that the _a argument is useless, but as explained in PR90329 that
is because in Fortran you can call foo ("foo", 1, 2, 3, 4, 5, 6, 7) without
interfaces etc.
and the first argument could be character, character(len=1), character(len=3)
or character(len=*) etc.  And only in the last case the argument is actually
needed, in other cases it is ignored.

So, the workaround could be for the case of unused DECL_HIDDEN_STRING_LENGTH
arguments at the end of PARM_DECLs don't try to load those at all and don't
assume there is parameter save area unless the non-DECL_HIDDEN_STRING_LENGTH or
used DECL_HIDDEN_STRING_LENGTH arguments actually require it.

[Bug middle-end/114048] [14 Regression] ICE when building libowfat-0.33 since r14-8929

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug middle-end/114048] [14 Regression] ICE when building libowfat-0.33 since r14-8929

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:92c40297991f51e7fa942f29517bc4398fce33f9

commit r14-9135-g92c40297991f51e7fa942f29517bc4398fce33f9
Author: Richard Biener 
Date:   Thu Feb 22 14:22:29 2024 +0100

tree-optimization/114048 - ICE in copy_reference_ops_from_ref

The following adds another omission to the assert verifying we're
not running into spurious off == -1.

PR tree-optimization/114048
* tree-ssa-sccvn.cc (copy_reference_ops_from_ref): MEM_REF
can also produce -1 off.

* gcc.dg/torture/pr114048.c: New testcase.

[Bug preprocessor/105608] [11/12/13/14 Regression] ICE: in linemap_add with a really long defined macro on the command line r11-338-g2a0225e47868fbfc

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

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

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

https://gcc.gnu.org/g:0e438772e788244236045d75cd2be895e2ab4e08

commit r13-8353-g0e438772e788244236045d75cd2be895e2ab4e08
Author: Lewis Hyatt 
Date:   Thu Feb 22 07:50:10 2024 -0500

testsuite: Remove test that should not have been backported [PR105608]

This test (backported as part of r13-8257, from r14-8465) was not meant to
be backported, since it fails on some platforms without other GCC 14
patches
that will not be backported. Remove it from the 13 branch.

gcc/testsuite/ChangeLog:

PR preprocessor/105608
* g++.dg/pch/line-map-3.C: Removed.
* g++.dg/pch/line-map-3.Hs: Removed.

[Bug c++/59465] [11/12/13/14 Regression] g++ allows direct-initialization of an array of class type from another array in a mem-initializer

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
>From bug 114053:

struct I {
const bool b;

};
struct O {
I a[2];  
static I const data[2];
O() : a(data){}
} ; 

I const O::data[2] = {true, false};

[Bug target/100799] Stackoverflow in optimized code on PPC

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org

--- Comment #25 from Peter Bergner  ---
CCing Mike and David for possible comments about the possible workarounds
mentioned in Comment 23 and Comment 24.

[Bug tree-optimization/114040] wrong code with __builtin_sub_overflow_p() and _BitInt() at -O2 and above

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 57499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57499=edit
gcc14-pr114040.patch

So far only smoke tested patch.

[Bug tree-optimization/114052] [11/12/13/14 Regression] Wrong code at -O2 for well-defined infinite loop

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #7 from Jan Hubicka  ---
> I see it doesn't do anything if mark_dfs_back_edges returns false, so it
> will claim the function is finite even when it calls a non-finite function?
> So I assume this is local analysis only and call edges will be handled
> elsewhere?

Yes, the side effects flags are transitively closed in callgraph at the
IPA propagation stage.
> 
> I found another similar compute, fill_always_executed_in in LIM
> (that considers all non-PURE calls as eventually looping, relying
> solely on gimple_has_side_effects here).
There are stmts with side effects that are always finite.
There is stmt_may_terminate_bb_p and stmt_may_terminate_function_p
which does more careful checking (and most of it should be unified I
guess).

I also had patches (never pushed) to track whether given callgraph edge
is always executed.  This is useful, for example, to bypass inliner
heuristics bounds on stack frame size.  It is also useful for profile
propagation.

So having this analysis factored out would be useful here, too.
> 
> In the end I want to have this on a stmt granularity (stmts before
> calls are OK, stmts after not).
Yep, if you have info whether BB is always executed, you still need to
walk its statements.
> 
> I guess greedily walking loop blocks along edges or walking in RPO oder
> and tracking whether there's no possible exit on the way to X would be
> the way to go.

That is what I would do. Maybe it would be nice to see though loops
known to be finite, so I guess if you check that it contains no stmts
that can terminate execution, then one can consider them safe

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #128 from John Paul Adrian Glaubitz  ---
Created attachment 57498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57498=edit
Build log including preprocessed source for building gcc-14 (20240221) natively
with LRA

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #127 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #126)
> I'm retesting a native build with LRA enabled by default now and report back.
> 
> If that works, I will try to build and boot a kernel.

OK, that fails with:

../../../src/libgcc/libgcc2.c: In function '__addvsi3':
../../../src/libgcc/libgcc2.c:84:1: error: unable to generate reloads for:
   84 | }
  | ^
(call_insn 29 28 30 4 (parallel [
(call (mem:SI (symbol_ref:SI ("abort") [flags 0x41] ) [0 __builtin_abort S4 A32])
(const_int 0 [0]))
(use (reg:SI 154 fpscr0))
(use (reg:SI 12 r12))
(clobber (reg:SI 146 pr))
(clobber (reg:SI 176))
]) "../../../src/libgcc/libgcc2.c":81:5 228 {call_pcrel}
 (expr_list:REG_DEAD (reg:SI 154 fpscr0)
(expr_list:REG_CALL_DECL (symbol_ref:SI ("abort") [flags 0x41]
)
(expr_list:REG_NORETURN (const_int 0 [0])
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)
(nil))
during RTL pass: reload

Attaching the full build log which also contains the intermediate source.

[Bug tree-optimization/114052] [11/12/13/14 Regression] Wrong code at -O2 for well-defined infinite loop

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

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

--- Comment #6 from Richard Biener  ---
(In reply to Jan Hubicka from comment #5)
> So if I understand it right, you want to determine the property that if the
> loop header is executed then BB containing undefined behavior at that
> iteration will be executed, too.
> 
> modref tracks if function will always return and if it can not determine it,
> it will set the side_effect flag. So you can check for that in modref
> summary.
> It uses finite_function_p which was originally done for pure/const detection
> and  is implemented by looking at loop nest if all loops are known to be
> finite and also by checking for irreducible loops.

I see it doesn't do anything if mark_dfs_back_edges returns false, so it
will claim the function is finite even when it calls a non-finite function?
So I assume this is local analysis only and call edges will be handled
elsewhere?

I found another similar compute, fill_always_executed_in in LIM
(that considers all non-PURE calls as eventually looping, relying
solely on gimple_has_side_effects here).

In the end I want to have this on a stmt granularity (stmts before
calls are OK, stmts after not).

I guess greedily walking loop blocks along edges or walking in RPO oder
and tracking whether there's no possible exit on the way to X would be
the way to go.

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

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

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

--- Comment #5 from Iain Sandoe  ---
The manual currently says:
-I dir
-iquote dir
-isystem dir
-idirafter dir

Add the directory dir to the list of directories to be searched for header
files dur- ing preprocessing. If dir begins with ‘=’ or $SYSROOT, then the ‘=’
or $SYSROOT is replaced by the sysroot prefix; see --sysroot and -isysroot.

Directories specified with -iquote apply only to the quote form of the
directive, #include "file".

>>> Directories specified with -I, -isystem, or -idirafter apply to lookup for 
>>> both the #include "file" and #include  directives. <<<

You can specify any number or combination of these options on the command line
to search for header files in several directories. The lookup order is as
follows:
1. Forthequoteformoftheincludedirective,thedirectoryofthecurrentfile is
searched first.
2. For the quote form of the include directive, the directories specified by
-iquote options are searched in left-to-right order, as they appear on the
command line.
3. Directories specified with -I options are scanned in left-to-right order.
4. Directories specified with -isystem options are scanned in left-to-right
order.
5. Standard system directories are scanned.
6. Directories specified with -idirafter options are scanned in left-to-right 

The highlighted bit seems to say we should be searching for either "" or <> ..
I wonder if something is being confused by the user framework path (-F .)

[Bug tree-optimization/114052] [11/12/13/14 Regression] Wrong code at -O2 for well-defined infinite loop

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

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

--- Comment #5 from Jan Hubicka  ---
So if I understand it right, you want to determine the property that if the
loop header is executed then BB containing undefined behavior at that iteration
will be executed, too.

modref tracks if function will always return and if it can not determine it, it
will set the side_effect flag. So you can check for that in modref summary.
It uses finite_function_p which was originally done for pure/const detection
and  is implemented by looking at loop nest if all loops are known to be finite
and also by checking for irreducible loops.

In your setup you probably also want to check for volatile asms that are also
possibly infinite. In mod-ref we get around by considering them to be
side-effects anyway.


There is also determine_unlikely_bbs which is trying to set profile_count to
zero to as many basic blocks as possible by propagating from basic blocks
containing undefined behaviour or cold noreturn call backward & forward.

The backward walk can be used to determine the property hat executing header
implies UB.  It stops on all loops though. In this case it would be nice to
walk through loops known to be finite...