[Bug go/113143] Remove usage of ucontext.h

[ian at airs dot com via Gcc-bugs]

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

--- Comment #12 from Ian Lance Taylor  ---
libgo/runtime/runtime.h:

#if defined(__x86_64__) && defined(__linux__) && !defined(__CET__)
...
#else
#define __go_context_t  ucontext_t
#define __go_getcontext(c)  getcontext(c)
#define __go_setcontext(c)  setcontext(c)
#define __go_makecontext(c, fn, sp, size) \
((c)->uc_stack.ss_sp = sp, (c)->uc_stack.ss_size = size, makecontext(c,
fn, 0))
#endif


libgo/runtime/proc.c:

various calls to __go_getcontext, __go_setcontext, and __go_makecontext.

[Bug tree-optimization/113176] `(n / 4) ? n / 4 : 0` is not optimized to just `n /4`

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

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

--- Comment #1 from Andrew Pinski  ---
I should note the non-constant case is already handled:
```
int unopt(int n, int c) {
if (n / c)
return n / c;
else
return 0;
}
```
It is just the constant case that has issues.

[Bug tree-optimization/113176] New: `(n / 4) ? n / 4 : 0` is not optimized to just `n /4`

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

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

Bug ID: 113176
   Summary: `(n / 4) ? n / 4 : 0` is not optimized to just `n /4`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int unopt(int n) {
if (n / 4)
return n / 4;
else
return 0;
}

int unopt1(int n) {
return (n / 4) ? n / 4 : 0;
}

int opt(int n) {
return n / 4;
}
```

I would have expected unopt be transformed into opt but currently it is not.

This is because GCC decides to transform `(n / 4) != 0` into `(unsigned int) n
+ 3 > 6`.

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #11 from Steve Kargl  ---
On Fri, Dec 29, 2023 at 08:34:38PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
> 
> --- Comment #10 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #0)
> > Created attachment 56949 [details]
> > patch with implementation
> 
> Not a review, just a comment:
> 
> diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
> index 87fefe46cfd..4e546ddb8fa 100644
> --- a/gcc/fortran/simplify.cc
> +++ b/gcc/fortran/simplify.cc
> @@ -30,6 +30,14 @@ along with GCC; see the file COPYING3.  If not see
>  #include "constructor.h"
>  #include "version.h"   /* For version_string.  */
> 
> +/* MPFR 4.2.0 introduced half-cycle trigonometric functions, e.g., sinpi(x).
> +   Introduce a macro so older versions of the MPFR can still be used.  */
> +
> +#ifdef MPFR_HALF_CYCLE
> +#undef MPFR_HALF_CYCLE
> +#endif
> +#define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR > 3 && MPFR_VERSION_MINOR > 1)
> +
>  /* Prototypes.  */
> 
> 
> This does not look right, as it would exclude e.g. all mpfr-[5-9].[01]
> How about:
> 
> #define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR * 100 + MPFR_VERSION_MINOR >= 402)
> 

Indeed, it looks like I'm skipping all .0 and .1 minor releases.
I'll adopt your suggestion, and include it in an updated patch.

[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)

[gcc at octaforge dot org via Gcc-bugs]

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

--- Comment #6 from Daniel Kolesa  ---
If it helps, I have reduced the patches to just the two that strictly necessary
for stage 1 build (I can't get rid of those, sorry, that would be asking for
the impossible), which are:

https://github.com/chimera-linux/cports/blob/master/experimental/gcc/patches/clang-tree-vect.patch
https://github.com/chimera-linux/cports/blob/master/experimental/gcc/patches/clang17.patch

and reproduced the exact same segfault on the same files with the exact same
backtrace.

Therefore, I can safely conclude that the patches are 100% irrelevant to the
problem at hand, as the two remaining ones are merely small build fixes.

--

libtool: compile:  /builddir/gcc-13.2.1_git20231014/build/./gcc/xgcc
-shared-libgcc -B/builddir/gcc-13.2.1_git20231014/build/./gcc -nostdinc++
-L/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/src
-L/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/src/.libs
-L/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/libsupc++/.libs
-B/usr/powerpc64le-chimera-linux-musl/bin/
-B/usr/powerpc64le-chimera-linux-musl/lib/ -isystem
/usr/powerpc64le-chimera-linux-musl/include -isystem
/usr/powerpc64le-chimera-linux-musl/sys-include -fno-checking
-I/builddir/gcc-13.2.1_git20231014/libstdc++-v3/../libgcc
-I/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/include/powerpc64le-chimera-linux-musl
-I/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/include
-I/builddir/gcc-13.2.1_git20231014/libstdc++-v3/libsupc++ -std=gnu++17
-nostdinc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=floating_from_chars.lo
-fimplicit-templates -fstack-clash-protection -mtune=power9 -O2
-ffile-prefix-map=/builddir/gcc-13.2.1_git20231014=. -g2 -D_GNU_SOURCE -c
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/floating_from_chars.cc 
-fPIC -DPIC -D_GLIBCXX_SHARED -o floating_from_chars.o
during RTL pass: combine
In file included from
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/floating_from_chars.cc:86:
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/fast_float/fast_float.h:
In function '{anonymous}::fast_float::adjusted_mantissa
{anonymous}::fast_float::digit_comp(parsed_number_string&, adjusted_mantissa)
[with T = float]':
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/fast_float/fast_float.h:2850:1:
internal compiler error: Segmentation fault
 2850 | }
  | ^
0x1279a323 crash_signal(int)
/builddir/gcc-13.2.1_git20231014/gcc/toplev.cc:314


cc1plus:

/builddir/gcc-13.2.1_git20231014/build/./gcc/cc1plus -quiet -nostdinc++
-nostdinc++ -v -I /builddir/gcc-13.2.1_git20231014/libstdc++-v3/../libgcc -I
/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/include/powerpc64le-chimera-linux-musl
-I
/builddir/gcc-13.2.1_git20231014/build/powerpc64le-chimera-linux-musl/libstdc++-v3/include
-I /builddir/gcc-13.2.1_git20231014/libstdc++-v3/libsupc++ -iprefix
/builddir/gcc-13.2.1_git20231014/build/gcc/../lib/gcc/powerpc64le-chimera-linux-musl/13.2.1/
-isystem /builddir/gcc-13.2.1_git20231014/build/./gcc/include -isystem
/builddir/gcc-13.2.1_git20231014/build/./gcc/include-fixed -D_GNU_SOURCE -D
_GLIBCXX_SHARED -D _GNU_SOURCE -D PIC -D _GLIBCXX_SHARED -isystem
/usr/powerpc64le-chimera-linux-musl/include -isystem
/usr/powerpc64le-chimera-linux-musl/sys-include
/builddir/gcc-13.2.1_git20231014/libstdc++-v3/src/c++17/floating_from_chars.cc
-msecure-plt -quiet -dumpbase floating_from_chars.cc -dumpbase-ext .cc
-mtune=power9 -mabi=elfv2 -g2 -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual
-Wabi=2 -std=gnu++17 -version -fno-checking -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=floating_from_chars.lo
-fimplicit-templates -fstack-clash-protection
-ffile-prefix-map=/builddir/gcc-13.2.1_git20231014=. -fPIC -o /tmp/ccLDfChm.s

backtrace:

* thread #1, name = 'cc1plus', stop reason = signal SIGSEGV: address not mapped
to object (fault address: 0x10062)
frame #0: 0x115b750c cc1plus`recog_114(x1=0x3fffe897a5a0,
insn=0x3fffe8979b00, pnum_clobbers=0x3fffda0c) at rs6000.md:8019:7
   8016li %0,%1
   8017mf%1 %0
   8018mt%0 %1
-> 8019lwz%U1%X1 %0,%1
   8020stw%U0%X0 %1,%0"
   8021   [(set_attr_alternative "type"
   8022  [(const_string "cr_logical")
(lldb) bt
* thread #1, name = 'cc1plus', stop reason = signal SIGSEGV: address not mapped
to object (fault address: 0x10062)
  * frame #0: 0x115b750c cc1plus`recog_114(x1=0x3fffe897a5a0,
insn=0x3fffe8979b00, pnum_clobbers=0x3fffda0c) at rs6000.md:8019:7
frame #1: 0x1154aa50 cc1plus`recog_126(x1=0x3fffe897a5a0,

[Bug target/113175] New: [14 Regression] MMIX: testsuite/std/ranges/iota/max_size_type.cc 5x times slower

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

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

Bug ID: 113175
   Summary: [14 Regression] MMIX:
testsuite/std/ranges/iota/max_size_type.cc 5x times
slower
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: mmix-knuth-mmixware

(Perhaps a "[13 Regression]" as well - haven't checked.)

I ran the testsuite for mmix-knuth-mmixware (a 64-bit newlib cross) and found
that testsuite/std/ranges/iota/max_size_type.cc times out, despite the
timeout-factor increased by a factor 4 (from 360 seconds to 1440 seconds) in
r12-2799-ge9b639c4b53221.

For a tree at r12-2797-g307e0d40367996 running this test takes 11:43.61 (mm:ss)
wall-clock time and now at r14-6859-gd1eacedc6d9b it takes 58:45.78 (on one and
the same host and same session within the same hour; no host-side changes and
the test itself apparently hasn't changed significantly).

I haven't checked whether this affects other targets, but if so, a 5x
performance regression should have been picked up by other testers, thus I'm
starting with "target" until firther investigated.

[Bug target/113070] [14 regression] [AArch64] [PGO/LTO] Miscompilation of go compiler

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #3 from Andreas Schwab  ---
*** Bug 113173 has been marked as a duplicate of this bug. ***

[Bug go/113173] [14 Regression] libgo fails to build on aarch64-linux-gnu

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andreas Schwab  ---
dup

*** This bug has been marked as a duplicate of bug 113070 ***

[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Daniel Kolesa from comment #4)
> I don't think builds with completely unchanged source are going to work, as
> the compiler won't even reach this point then (at very least several of them
> are necessary for stage 1 to build at all)

Then there is not much we can support here.

[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)

[gcc at octaforge dot org via Gcc-bugs]

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

--- Comment #4 from Daniel Kolesa  ---
I don't think builds with completely unchanged source are going to work, as the
compiler won't even reach this point then (at very least several of them are
necessary for stage 1 to build at all)

[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)

[gcc at octaforge dot org via Gcc-bugs]

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

--- Comment #3 from Daniel Kolesa  ---
this is the preprocessed source: https://0x0.st/HEt7.ii

It's generated with the following command line:
/builddir/gcc-13.2.1_git20231014/build/./prev-gcc/xg++
-B/builddir/gcc-13.2.1_git20231014/build/./prev-gcc/
-B/usr/powerpc64le-chimera-linux-musl/bin/ -nostdinc++
-B/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/src/.libs
-B/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/libsupc++/.libs

-I/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/include/powerpc64le-chimera-linux-musl

-I/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/include
 -I/builddir/gcc-13.2.1_git20231014/libstdc++-v3/libsupc++
-L/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/src/.libs
-L/builddir/gcc-13.2.1_git20231014/build/prev-powerpc64le-chimera-linux-musl/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c   -g -O2 -fno-checking -fno-tree-ter -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I/builddir/gcc-13.2.1_git20231014/gcc -I/builddir/gcc-13.2.1_git20231014/gcc/.
-I/builddir/gcc-13.2.1_git20231014/gcc/../include 
-I/builddir/gcc-13.2.1_git20231014/gcc/../libcpp/include
-I/builddir/gcc-13.2.1_git20231014/gcc/../libcody -Iyes/include -Iyes/include
-Iyes/include  -I/builddir/gcc-13.2.1_git20231014/gcc/../libdecnumber
-I/builddir/gcc-13.2.1_git20231014/gcc/../libdecnumber/dpd -I../libdecnumber
-I/builddir/gcc-13.2.1_git20231014/gcc/../libbacktrace   -o modulo-sched.o -MT
modulo-sched.o -MMD -MP -MF ./.deps/modulo-sched.TPo
/builddir/gcc-13.2.1_git20231014/gcc/modulo-sched.cc

The command line is taken from the failing log. Yes, it could be an LLVM bug.
It's hard to say whether it is though.

[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Host||powerpc64el-linux-musl
   ||(clang/libc++ as host)
  Build||powerpc64el-linux-musl
   ||(clang/libc++ as build)
 Target||powerpc64el-linux-musl

--- Comment #2 from Andrew Pinski  ---
Also if stage1 gcc is crashing, it might be a bug in clang/LLVM too. Now GCC
can and does workaround host compilers but there needs to be a lot more
information here and not just linking to other sources.

First start with non-changed sources and try again. If also you cannot try with
non-changed sources, this is not the right place for this kind of bug report.

[Bug bootstrap/113174] gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-12-29

--- Comment #1 from Andrew Pinski  ---
Please read https://gcc.gnu.org/bugs/ first.

[Bug bootstrap/113174] New: gcc fails to bootstrap on pp64le with clang-based host environment (internal compiler error)

[gcc at octaforge dot org via Gcc-bugs]

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

Bug ID: 113174
   Summary: gcc fails to bootstrap on pp64le with clang-based host
environment (internal compiler error)
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at octaforge dot org
  Target Milestone: ---

Attempting to bootstrap GCC on Chimera Linux (https://chimera-linux.org) which
uses LLVM/Clang as its system compiler and runtime fails, presumably inside the
stage 1 compiler, with an internal compiler error.

Backtrace from cc1plus, full build logs (gcc-build.log is the original build
run, gcc-build2.log is after resumption), as well as the -dap output for the
affected file is available here: https://ftp.octaforge.org/q66/random/gcc-out/

Packaging and patches available here:
https://github.com/chimera-linux/cports/tree/master/experimental/gcc In
particular, configure arguments are listed at
https://github.com/chimera-linux/cports/blob/master/experimental/gcc/template.py#L11
and at
https://github.com/chimera-linux/cports/blob/master/experimental/gcc/template.py#L123
, for ppc64le. Apologies for the potentially verbose script. The patches are
almost entirely taken from Alpine Linux (which supports ppc64le and seemingly
builds fine) outside of my patches that enforce defaulting to compiler-rt
runtime instead of libgcc (libclang_rt.builtins + libunwind) and libc++ in
place of libstdc++ to match the system toolchain (as otherwise gcc would
generate incompatible binaries in this environment). I believe those should not
affect this ICE (as this happens during object file generation), or at least I
have no idea of the mechanism if they do.

Observations:

1) passing -fno-tree-ter will prevent most of the crashes (and it was passed
during the build above, mistakenly as I had not intended to pass it) but it
eventually crashes anyway (it just does so later; I have verified that the
backtraces are identical, so regardless of -fno-tree-ter the same issue is
triggered)
2) the insn-recog.cc differs quite a bit for gcc-prev and gcc (diff:
https://0x0.st/HEt-.diff), the function that segfaults in the backtrace notably
is changed; I'm not entirely sure why
3) I'm not sure if this is just the stage 1 compiler crashing or if subsequent
stages are affected; to me from the output it looks like this is still stage 1,
however I tried all sorts of combinations of flags (including STAGE1_TFLAGS)
without success
4) I tested other targets (x86_64 and aarch64) which work fine. The issue
appears to be isolated to rs6000, and quite possibly ppc64le only, as it
appears to deal with VSX. However, I had not been able to test this on ppc64
big endian yet.

Please let me know if any other information is needed from me. I believe a
preprocessed source file is probably not helpful as the issue only reproduces
with a particular compiler build for a pretty random set of inputs.

I was hoping to figure this out by myself, however I am not familiar enough
with GCC's design and internals to make a good sense of this. Apologies if the
information is incomplete or if this is an issue with my configuration in some
way.

[Bug middle-end/113172] [14 Regression] ice in move_early_exit_stmts

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

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

--- Comment #2 from Tamar Christina  ---
Patch submitted

[Bug middle-end/113163] [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420

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

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

--- Comment #10 from Tamar Christina  ---
Patch submitted

[Bug tree-optimization/113144] [14 regression] ICE when building dpkg-1.21.15 in verify_dominators (error: dominator of 9 should be 48, not 12)

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

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

--- Comment #8 from Tamar Christina  ---
Patch submitted

[Bug tree-optimization/113136] [14 regression] ICE when building Perl

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

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

--- Comment #9 from Tamar Christina  ---
Patch submitted

[Bug tree-optimization/113137] [14 regression] Failed bootstrap with -O3 -march=znver2

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

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

--- Comment #13 from Tamar Christina  ---
Patch submitted

[Bug c++/83181] [C++17] Invalid deduction guide accepted

[eddiejnolan at gmail dot com via Gcc-bugs]

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

Eddie Nolan  changed:

   What|Removed |Added

 CC||eddiejnolan at gmail dot com

--- Comment #3 from Eddie Nolan  ---
Here's another example:

template 
struct foo {};

template
foo(T&&) -> foo;

Clang says:

:5:1: error: deduction guide template contains a template parameter
that cannot be deduced
5 | foo(T&&) -> foo;
  | ^
:4:31: note: non-deducible template parameter 'U'
4 | template
  |   ^

But GCC accepts it.

[Bug middle-end/113172] [14 Regression] ice in move_early_exit_stmts

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

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

Tamar Christina  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-29
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=113137

--- Comment #1 from Tamar Christina  ---
Thanks for the report, fixed by patch for #113137 and now correctly vectorizes

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

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

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #0)
> Created attachment 56949 [details]
> patch with implementation

Not a review, just a comment:

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index 87fefe46cfd..4e546ddb8fa 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -30,6 +30,14 @@ along with GCC; see the file COPYING3.  If not see
 #include "constructor.h"
 #include "version.h"   /* For version_string.  */

+/* MPFR 4.2.0 introduced half-cycle trigonometric functions, e.g., sinpi(x).
+   Introduce a macro so older versions of the MPFR can still be used.  */
+
+#ifdef MPFR_HALF_CYCLE
+#undef MPFR_HALF_CYCLE
+#endif
+#define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR > 3 && MPFR_VERSION_MINOR > 1)
+
 /* Prototypes.  */


This does not look right, as it would exclude e.g. all mpfr-[5-9].[01]
How about:

#define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR * 100 + MPFR_VERSION_MINOR >= 402)

[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |14.0

--- Comment #23 from anlauf at gcc dot gnu.org ---
The issue should be fixed in gcc-14, and the changed behavior of -save-temps
documented.

[Bug go/113173] New: [14 Regression] libgo fails to build on aarch64-linux-gnu

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

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

Bug ID: 113173
   Summary: [14 Regression] libgo fails to build on
aarch64-linux-gnu
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with trunk 20231229 on aarch64-linux-gnu, last successful build from
20231214

[...]
libtool: compile:  /<>/build/./gcc/gccgo
-B/<>/build/./gcc/ -B/usr/aarch64-linux-gnu/bin/
-B/usr/aarch64-linux-gnu/lib/ -isystem /usr/aarch64-linux-gnu/include -isystem
/usr/aarch64-linux-gnu/sys-include -isystem /<>/build/sys-include
-O2 -g -I . -c -fgo-pkgpath=internal/goarch
../../../src/libgo/go/internal/goarch/goarch.go zgoarch.go  -fPIC -o
internal/.libs/goarch.o
zgoarch.go:7:3: error: redefinition of ''
7 |   _BigEndian = false
  |   ^
zgoarch.go:6:3: note: previous definition of '' was here
6 |   _ArchFamily = ARM64
  |   ^
zgoarch.go:8:3: error: redefinition of ''
8 |   _DefaultPhysPageSize = 65536
  |   ^
zgoarch.go:6:3: note: previous definition of '' was here
6 |   _ArchFamily = ARM64
  |   ^
zgoarch.go:9:3: error: redefinition of ''
9 |   _Int64Align = 8
  |   ^
zgoarch.go:6:3: note: previous definition of '' was here
6 |   _ArchFamily = ARM64
  |   ^
zgoarch.go:10:3: error: redefinition of ''
   10 |   _MinFrameSize = 8
  |   ^
zgoarch.go:6:3: note: previous definition of '' was here
6 |   _ArchFamily = ARM64
  |   ^
zgoarch.go:11:3: error: redefinition of ''
   11 |   _PCQuantum = 4
  |   ^
zgoarch.go:6:3: note: previous definition of '' was here
6 |   _ArchFamily = ARM64
  |   ^
zgoarch.go:12:3: error: redefinition of ''
   12 |   _StackAlign = 16
  |   ^
zgoarch.go:6:3: note: previous definition of '' was here
6 |   _ArchFamily = ARM64
  |   ^
../../../src/libgo/go/internal/goarch/goarch.go:8:21: error: expected type
8 | type ArchFamilyType int
  | ^
zgoarch.go:6:17: error: constant refers to itself
6 |   _ArchFamily = ARM64
  | ^
make[6]: *** [Makefile:3059: internal/goarch.lo] Error 1
make[6]: Leaving directory '/<>/build/aarch64-linux-gnu/libgo'
make[5]: *** [Makefile:2358: all-recursive] Error 1

complete build log at
https://launchpad.net/~doko/+archive/ubuntu/toolchain/+build/27596519/+files/buildlog_ubuntu-noble-arm64.gcc-14_14-20231229-0ubuntu1_BUILDING.txt.gz

[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions

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

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Current patch is incomplete as it fails to scalarize.
It seems I need to remember how to register the new
intrinsic subprograms in trans-intrinsics.cc.

[Bug middle-end/113172] [14 Regression] ice in move_early_exit_stmts

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
  Component|c   |middle-end
   Keywords||ice-on-valid-code
   Target Milestone|--- |14.0
Summary|ice in  |[14 Regression] ice in
   |move_early_exit_stmts   |move_early_exit_stmts

[Bug c/113172] New: ice in move_early_exit_stmts

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113172
   Summary: ice in move_early_exit_stmts
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

int tswchp_2;
short cpy_buf[8];
void ts_endcmd() {
  int i = 0;
  for (; i < 8 && i < tswchp_2; i++)
cpy_buf[i] = i;
}

compiled by recent gcc trunk, does this:

cvise $ ~/gcc/results/bin/gcc -c -O3  bug994.c
cvise $ ~/gcc/results/bin/gcc -c -O3 -march=znver3 bug994.c
during GIMPLE pass: vect
bug994.c: In function ‘ts_endcmd’:
bug994.c:3:6: internal compiler error: Segmentation fault
3 | void ts_endcmd() {
  |  ^
0xeeade9 crash_signal(int)
../../trunk.20210101/gcc/toplev.cc:316
0x11a8e63 gsi_prev(gimple_stmt_iterator*)
../../trunk.20210101/gcc/gimple-iterator.h:236
0x11a8e63 move_early_exit_stmts(_loop_vec_info*)
../../trunk.20210101/gcc/tree-vect-loop.cc:11807

[Bug testsuite/113167] [14 Regression] gcc.dg/tree-ssa/gen-vect-26.c started failing many targets after recent change

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

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

--- Comment #7 from Jeffrey A. Law  ---
So far that's the only fallout I've seen on the embedded targets.

The qemu emulated natives aren't running as I've got some kind of network
problem here and the workers are going offline after a few hours causing those
builds to fail.

[Bug target/110625] [14 Regression][AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #25 from Tamar Christina  ---
(In reply to Hao Liu from comment #0)
> This problem causes a performance regression in SPEC2017 538.imagick.  For
> the following simple case (modified from pr96208):
> 
> typedef struct {
> unsigned short m1, m2, m3, m4;
> } the_struct_t;
> typedef struct {
> double m1, m2, m3, m4, m5;
> } the_struct2_t;
> 
> double bar1 (the_struct2_t*);
> 
> double foo (double* k, unsigned int n, the_struct_t* the_struct) {
> unsigned int u;
> the_struct2_t result;
> for (u=0; u < n; u++, k--) {
> result.m1 += (*k)*the_struct[u].m1;
> result.m2 += (*k)*the_struct[u].m2;
> result.m3 += (*k)*the_struct[u].m3;
> result.m4 += (*k)*the_struct[u].m4;
> }
> return bar1 ();
> }
> 

In the context of this report the regression should be fixed, however we still
don't vectorize this loop.  We ran this and other cases comparing scalar and
vector versions of this loop and it looks like specifically Neoverse N2 does
much better using the scalar version here.  So it looks like the cost model is
doing the right thing here for the current codegen of the function.

Note that the vector version:

ldr q31, [x3], 16
ldr q29, [x4], -16
rev64   v31.8h, v31.8h
uxtlv30.4s, v31.4h
uxtl2   v31.4s, v31.8h
sxtlv27.2d, v30.2s
sxtlv28.2d, v31.2s
sxtl2   v30.2d, v30.4s
sxtl2   v31.2d, v31.4s
scvtf   v27.2d, v27.2d
scvtf   v28.2d, v28.2d
scvtf   v30.2d, v30.2d
scvtf   v31.2d, v31.2d
fmlav26.2d, v27.2d, v29.d[1]
fmlav24.2d, v30.2d, v29.d[1]
fmlav23.2d, v28.2d, v29.d[0]
fmlav25.2d, v31.2d, v29.d[0]

Is still pretty inefficient due to all the extends.  If we generate better code
here this may tip the scale back to vector.  But for now, the patch should fix
the regression.

[Bug target/110625] [14 Regression][AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

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

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

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

https://gcc.gnu.org/g:984bdeaa39b6417b11736b2c167ef82119e272dc

commit r14-6865-g984bdeaa39b6417b11736b2c167ef82119e272dc
Author: Tamar Christina 
Date:   Fri Dec 29 15:58:29 2023 +

AArch64: Update costing for vector conversions [PR110625]

In gimple the operation

short _8;
double _9;
_9 = (double) _8;

denotes two operations on AArch64.  First we have to widen from short to
long and then convert this integer to a double.

Currently however we only count the widen/truncate operations:

(double) _5 6 times vec_promote_demote costs 12 in body
(double) _5 12 times vec_promote_demote costs 24 in body

but not the actual conversion operation, which needs an additional 12
instructions in the attached testcase.   Without this the attached testcase
ends
up incorrectly thinking that it's beneficial to vectorize the loop at a
very
high VF = 8 (4x unrolled).

Because we can't change the mid-end to account for this the costing code in
the
backend now keeps track of whether the previous operation was a
promotion/demotion and ajdusts the expected number of instructions to:

1. If it's the first FLOAT_EXPR and the precision of the lhs and rhs are
   different, double it, since we need to convert and promote.
2. If it's the previous operation was a demonition/promotion then reduce
the
   cost of the current operation by the amount we added extra in the last.

with the patch we get:

(double) _5 6 times vec_promote_demote costs 24 in body
(double) _5 12 times vec_promote_demote costs 36 in body

which correctly accounts for 30 operations.

This fixes the 16% regression in imagick in SPECCPU 2017 reported on
Neoverse N2
and using the new generic Armv9-a cost model.

gcc/ChangeLog:

PR target/110625
* config/aarch64/aarch64.cc (aarch64_vector_costs::add_stmt_cost):
Adjust throughput and latency calculations for vector conversions.
(class aarch64_vector_costs): Add m_num_last_promote_demote.

gcc/testsuite/ChangeLog:

PR target/110625
* gcc.target/aarch64/pr110625_4.c: New test.
* gcc.target/aarch64/sve/unpack_fcvt_signed_1.c: Add
--param aarch64-sve-compare-costs=0.
* gcc.target/aarch64/sve/unpack_fcvt_unsigned_1.c: Likewise

[Bug middle-end/113163] [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #9 from Tamar Christina  ---
*** Bug 113169 has been marked as a duplicate of this bug. ***

[Bug target/113169] [14 Regression] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420 on amdgcn-amdhsa

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

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

Tamar Christina  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Tamar Christina  ---
Thanks, dup of #113163 patch already submitted waiting review.

*** This bug has been marked as a duplicate of bug 113163 ***

[Bug target/113171] Unneeded zero extend after widening load with SVE

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #1 from Tamar Christina  ---
Whoops, missed the add in between

[Bug target/113171] New: Unneeded zero extend after widening load with SVE

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

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

Bug ID: 113171
   Summary: Unneeded zero extend after widening load with SVE
   Product: gcc
   Version: 13.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 testcase

#include 

void __attribute__ ((noinline, noclone))
unpack_double_int_plus9 (double *d, uint32_t *s, int size)
{
  for (int i = 0; i < size; i++)
d[i] = (double) (s[i] + 9);
}

compiled with

-march=armv8-a+sve -O2 -ftree-vectorize

generates:

.L3:
ld1wz31.d, p7/z, [x1, x3, lsl 2]
add z31.s, z31.s, #9
uxtwz31.d, p6/m, z31.d
scvtf   z31.d, p6/m, z31.d
st1dz31.d, p7, [x0, x3, lsl 3]
incdx3
whilelo p7.d, w3, w2
b.any   .L3

which looks like the zero extend is unneeded.

[Bug fortran/113165] Code containing more than one type declaration for a variable results in confusing error messages from compiler

[xecej4 at outlook dot com via Gcc-bugs]

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

--- Comment #3 from mecej4  ---
Thanks for the prompt response and the rapid fix.

[Bug tree-optimization/113137] [14 regression] Failed bootstrap with -O3 -march=znver2

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

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

--- Comment #12 from Tamar Christina  ---
ok, x86_64 bootstrap and regtest with -O3 and --enable-checking=yes,rtl,extra
now passes.

aarch64 hit a small issue in libgcc that I'm not sure I should be allowing or
not. will investigate and either fix or disable and post patches.

[Bug c++/113170] ICE: Segfault (template template parameter, alias template, default template argument)

[iamkirkezz at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Kirkezz  ---
I was experimenting with the template template parameters, and ICE occured.

[Bug c++/113170] New: ICE: Segfault (template template parameter, alias template, default value)

[iamkirkezz at gmail dot com via Gcc-bugs]

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

Bug ID: 113170
   Summary: ICE: Segfault (template template parameter, alias
template, default value)
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamkirkezz at gmail dot com
  Target Milestone: ---

Created attachment 56964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56964=edit
g++ main.cpp -v output

| gcc version: 13.2.1 20230801
| system type: x86_64-pc-linux-gnu
| gcc options:
"""
/build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
"""
| the complete command line: g++ main.cpp
| gcc output (for the full `g++ -v` output, see the attachment):
"""
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
"""
| source file (https://godbolt.org/z/cKTGrn1sP):
"""
template typename TT>
struct S;
template typename TT = S>
struct SSS {};
template typename TT = SSS>
struct S {};
template typename TT = S, typename T = int>
using SS = S;
int main() {
SS ss;
}
"""

[Bug tree-optimization/113137] [14 regression] Failed bootstrap with -O3 -march=znver2

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

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

--- Comment #11 from Tamar Christina  ---
Created attachment 56963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56963=edit
maintain-lcssa-peeled.patch

patch undergoing testing for both this and PR113136

[Bug target/113169] [14 Regression] ICE in in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420 on amdgcn-amdhsa

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

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

--- Comment #1 from Matthias Klose  ---
last known successful build was 20231214

[Bug target/113169] New: [14 Regression] ICE in in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420 on amdgcn-amdhsa

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

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

Bug ID: 113169
   Summary: [14 Regression] ICE in in vect_peel_nonlinear_iv_init,
at tree-vect-loop.cc:9420 on amdgcn-amdhsa
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with trunk 20231229 on amdgcn-amdhsa. the offload compiler itself is built
with trunk 20231229.


$ cat l64a.i
char _l64a_buf[1];
void _l64a_r() {
  char *ptr;
  int i;
  long tmp;
  ptr = _l64a_buf;
  i = 0;
  for (; i < 6; ++i) {
if (tmp == 0)
  break;
*ptr++ = tmp >>= 6;
  }
}

 build-gcn/gcc/xgcc -Bbuild-gcn/gcc/ -c -march=gfx900 -O2 -fno-builtin l64a.i
during GIMPLE pass: vect
l64a.i: In function '_l64a_r':
l64a.i:2:6: internal compiler error: in vect_peel_nonlinear_iv_init, at
tree-vect-loop.cc:9420
2 | void _l64a_r() {
  |  ^~~
0x70fa53 vect_peel_nonlinear_iv_init(gimple**, tree_node*, tree_node*,
tree_node*, vect_induction_op_type)
../../src-gcn/gcc/tree-vect-loop.cc:9420
0xf9b415 vect_update_ivs_after_vectorizer
../../src-gcn/gcc/tree-vect-loop-manip.cc:2267
0xf9b415 vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**,
tree_node**, tree_node**, int, bool, bool, tree_node**)
../../src-gcn/gcc/tree-vect-loop-manip.cc:3399
0xf8bd42 vect_transform_loop(_loop_vec_info*, gimple*)
../../src-gcn/gcc/tree-vect-loop.cc:11911
0xfc9b9b vect_transform_loops
../../src-gcn/gcc/tree-vectorizer.cc:1006
0xfca21d try_vectorize_loop_1
../../src-gcn/gcc/tree-vectorizer.cc:1152
0xfca21d try_vectorize_loop
../../src-gcn/gcc/tree-vectorizer.cc:1182
0xfca6b4 execute
../../src-gcn/gcc/tree-vectorizer.cc:1298
Please submit a full bug report, with preprocessed source (by using
-freport-bug).

[Bug tree-optimization/113091] Over-estimate SLP vector-to-scalar cost for non-live pattern statement

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

--- Comment #8 from Feng Xue  ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641547.html

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |13.3

[Bug other/113168] ABOUT-NLS seems way out of date

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
I think ABOUT-NLS is vendored in from gettext; if you run `gettextize` it will
replace the content of the file with a simple link to
.
See for example:
https://github.com/cooljeanius/gcc/commit/d9661641f89ee1baae768a006ef2d7b1f2db15f7

[Bug target/113133] [14 Regression] ICE: SIGSEGV in mark_label_nuses(rtx_def*) (emit-rtl.cc:3896) with -O -fno-tree-ter -mavx512f -march=barcelona

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #10 from Uroš Bizjak  ---
Fixed by a partial revert of
r14-4499-gc1eef66baa8dde706d7ea6921648e6016dc7c93d.

[Bug target/113133] [14 Regression] ICE: SIGSEGV in mark_label_nuses(rtx_def*) (emit-rtl.cc:3896) with -O -fno-tree-ter -mavx512f -march=barcelona

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r14-6862-g1e7f9abb892443719c82bb17910caa8fb5eeec15
Author: Uros Bizjak 
Date:   Fri Dec 29 09:47:43 2023 +0100

i386: Fix TARGET_USE_VECTOR_FP_CONVERTS SF->DF float_extend splitter
[PR113133]

The post-reload splitter currently allows xmm16+ registers with
TARGET_EVEX512.
The splitter changes SFmode of the output operand to V4SFmode, but the
vector
mode is currently unsupported in xmm16+ without TARGET_AVX512VL.
lowpart_subreg
returns NULL_RTX in this case and the compilation fails with invalid RTX.

The patch removes support for x/ymm16+ registers with TARGET_EVEX512.  The
support should be restored once ix86_hard_regno_mode_ok is fixed to allow
16-byte modes in x/ymm16+ with TARGET_EVEX512.

PR target/113133

gcc/ChangeLog:

* config/i386/i386.md
(TARGET_USE_VECTOR_FP_CONVERTS SF->DF float_extend splitter):
Do not handle xmm16+ with TARGET_EVEX512.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr113133-1.c: New test.
* gcc.target/i386/pr113133-2.c: New test.

[Bug testsuite/113167] [14 Regression] gcc.dg/tree-ssa/gen-vect-26.c started failing many targets after recent change

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #6 from Tamar Christina  ---
Thanks for the fix.

I suspect they'll be other target tests that fail in similar ways as well as a
side effect of abort loops being vectorizable now.

[Bug target/113133] [14 Regression] ICE: SIGSEGV in mark_label_nuses(rtx_def*) (emit-rtl.cc:3896) with -O -fno-tree-ter -mavx512f -march=barcelona

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Uroš Bizjak  ---
(In reply to Haochen Jiang from comment #6)
> Aha, I see what happened. x/ymm16+ are usable for AVX512F w/o AVX512VL and
> that is why I added that to allow them.
> 
> Let me find a way to see if we can fix this.

It looks to me that ix86_hard_regno_mode_ok should be fixed to allow x/ymm16+
also with EVEX512. Currently we have:

  /* TODO check for QI/HI scalars.  */
  /* AVX512VL allows sse regs16+ for 128/256 bit modes.  */
  if (TARGET_AVX512VL
  && (VALID_AVX256_REG_OR_OI_MODE (mode)
  || VALID_AVX512VL_128_REG_MODE (mode)))
return true;

so the compiler is unable to change some of the modes of the xmm16 to 128-bit
mode using lowpart_subreg, e.g. DFmode to V4SFmode.

Please also note that your original patch missed to add TARGET_EVEX512 to the
splitter that handles float_truncate with TARGET_USE_VECTOR_FP_CONVERTS.

I propose to proceed with the minimal fix from Comment #3 as a hotfix to
unbreak the testcase in this PR. The real, but more involved fix is to fix
ix86_hard_regno_mode_ok, which I'll leave to you.