[Bug fortran/116875] Internal compiler error: in make_decl_rtl, at varasm.cc:1443

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2024-09-28
 Status|UNCONFIRMED |NEW
  Known to fail||15.0, 7.5.0
 Ever confirmed|0   |1

--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed.  It is an old bug that affects all gfortran versions since at
least gcc-7.

The issue is triggered by the BLOCK construct.  The dump-tree suggests that
a decl for S1_POINTER is lost or not generated.

I think I've seen at least one other PR with the same pattern.

[Bug c++/116876] New: GCC accepts invalid call to overloaded function template

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 116876
   Summary: GCC accepts invalid call to overloaded function
template
   Product: gcc
   Version: 15.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 invalid program is accepted by gcc and msvc but rejected by
clang. 

```
#include 
#include 
template< class T > void f( T& t ){} ;
template< class T > void f( const T&& ) {};
int main()
{
int i = 0;
f(i); //clang:nope, gcc:ok, msvc:ok
} 
```
Demo: https://godbolt.org/z/4K7ErvWjh

Related thread:
https://stackoverflow.com/questions/79034394/function-template-overloading-when-called-with-reference-type-rejected-by-clang

[Bug ada/116877] New: Unable to build libada for baremetal ARM processor

[dldudley at gmail dot com via Gcc-bugs]

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

Bug ID: 116877
   Summary: Unable to build libada for baremetal ARM processor
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dldudley at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Attempting to build a baremetal ADA compiler for the ARM processor family.

Compiler builds successfully if I use the option --disable-libada and skip the
library build, however compiler will not work successfully without the library
built.

Since this is targeting a baremetal system (there is no planned OS for this
device, other than newlib), there is no included file system (and therefore
include files that include file functions).
When building the library, it fails when attempting to access "dirent.h" and
other functions that refer to file systems.
Is there a patch or option available to allow the ada library to build without
access to file functions?

[Bug c++/116876] GCC accepts invalid call to overloaded function template when neither is at least as specialized as the other

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

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

--- Comment #1 from Andrew Pinski  ---
EDG also accepts it. So maybe this is a clang issue.

[Bug c++/116876] GCC accepts invalid call to overloaded function template when neither is at least as specialized as the other

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

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

--- Comment #3 from Andrew Pinski  ---
EDG, GCC and MSVC all use the reference function rather const rvalue reference
function.

if we change the const rvalue reference to just an rvalue reference, then clang
accepts it:
> template< class T > void f( T&& ) { puts("rvalue-reference"); };


So are you sure this is not a clang issue?

[Bug c++/116876] GCC accepts invalid call to overloaded function template when neither is at least as specialized as the other

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

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

--- Comment #2 from Andrew Pinski  ---
https://developercommunity.visualstudio.com/t/MSVC-accepts-invalid-call-to-overloaded/10755162

[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 #339 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #335)
> (In reply to Kazumoto Kojima from comment #334)
> > Created attachment 59216 [details]
> > a patch to fix ICE in c#331
> > 
> > The patch preallocates R0 for those Sid memory patterns so as to shorten the
> > live range of R0.  Tested target libgcc and libstdc++v3 build and c
> > testsuilte only.
> 
> Thanks a lot. I'll give it a try.
> 
> FWIW, the backend has improved quite a lot over the past weeks. The
> Dreamcast people reported good results as well!

I can confirm that the patch from comment #334 fixes the problem and the build
of WebKit now proceeds much further than it used to in the past for a long
time.

I have not observed any more issues with register spilling, but it seems that I
have uncovered a miscompilation bug which leads to the generation of invalid
assembler:

/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_JavaScriptCore
-DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1 -DGETTEXT_PACKAGE=\"WebKitGTK-4.1\"
-DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED -DJavaScriptCore_EXPORTS
-DPAS_BMALLOC=1 -DSTATICALLY_LINKED_WITH_WTF
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/JavaScriptCore/Headers
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/API
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/assembler
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/b3
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/b3/air
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/bindings
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/builtins
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/bytecode
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/bytecompiler
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/dfg
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/disassembler
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/disassembler/ARM64
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/disassembler/zydis/Zydis
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/domjit
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/ftl
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/fuzzilli
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/heap
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/debugger
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/inspector
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/inspector/agents
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/inspector/augmentable
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/inspector/remote
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/interpreter
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/jit
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/llint
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/parser
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/profiler
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/runtime
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/tools
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/wasm
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/wasm/js
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/yarr
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/JavaScriptCore/DerivedSources
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/JavaScriptCore/DerivedSources/inspector
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/JavaScriptCore/DerivedSources/runtime
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/JavaScriptCore/DerivedSources/yarr
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/API/glib
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/JavaScriptCoreGLib/DerivedSources
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/JavaScriptCoreGLib/DerivedSources/jsc
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gt

[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 #340 from John Paul Adrian Glaubitz  ---
The compressed preprocessed source is larger than usual and the complete
archive exceeds the maximum file limit for Bugzilla, so I have uploaded the
preprocessed source for comment #339 here:

> http://people.debian.org/~glaubitz/pr-55212-339.tgz

[Bug target/116878] New: [15 regression] libcall emitted unnecessarily for __popcountdi2

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

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

Bug ID: 116878
   Summary: [15 regression] libcall emitted unnecessarily for
__popcountdi2
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Hit this with an `allmodconfig` of linux-6.6.52 (aware of the controversy there
in general).

When building the following w/ `-O2 -fsanitize-coverage=trace-cmp`, it looks
lik we get an inefficient(?) libcall to _popcountdi2:
```
int s_jquota_fmt;
void seq_printf();
void ext4_init_fs_contextext4_show_options() {
  char *fmtname = "";
  switch (s_jquota_fmt) {
  case 1:
fmtname = "vfsold";
break;
  case 2:
fmtname = "vfsv0";
break;
  case 4:
fmtname = "vfsv1";
  }
  seq_printf(fmtname);
}
```

See https://godbolt.org/z/TjTMW345h. With 14, we don't emit the libcall, and
Clang doesn't either (but needs -fno-jump-tables as well as the kernel
originally built with).

--

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

[Bug target/116878] [15 regression] libcall emitted unnecessarily for __popcountdi2

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

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

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

[Bug tree-optimization/116879] New: ICE on valid code at -O2 with "-ftree-vectorize -fallow-store-data-races -fno-tree-ch -ftree-loop-distribution" on x86_64-linux-gnu: verify_ssa failed

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

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

Bug ID: 116879
   Summary: ICE on valid code at -O2 with "-ftree-vectorize
-fallow-store-data-races -fno-tree-ch
-ftree-loop-distribution" on x86_64-linux-gnu:
verify_ssa failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

Compiler Explorer: https://godbolt.org/z/xjrGMhMqM

[658] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240928 (experimental) (GCC) 
[659] % 
[659] % gcctk -O2 small.c; ./a.out
[660] % 
[660] % gcctk -O2 -ftree-vectorize -fallow-store-data-races -fno-tree-ch
-ftree-loop-distribution small.c
small.c: In function ‘main’:
small.c:3:5: error: definition in block 4 does not dominate use in block 8
3 | int main() {
  | ^~~~
for SSA_NAME: .MEM_12 in statement:
.MEM_3 = PHI <.MEM_12(8)>
PHI argument
.MEM_12
for PHI node
.MEM_3 = PHI <.MEM_12(8)>
during GIMPLE pass: vect
small.c:3:5: internal compiler error: verify_ssa failed
0x25e55a5 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:517
0x1452a3e verify_ssa(bool, bool)
../../gcc-trunk/gcc/tree-ssa.cc:1203
0x107e515 execute_function_todo
../../gcc-trunk/gcc/passes.cc:2108
0x107edbe execute_todo
../../gcc-trunk/gcc/passes.cc:2155
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.
[661] % 
[661] % cat small.c
static int b;
int *a, c, *d = &c;
int main() {
  int e = 0;
  for (; e < 8; e = (char)(e + 1)) {
int *f = &b, g[8], h = 0;
for (; h < 8; h++)
  g[h] = 0;
--*f != (*d = g[0] || a);
  }
  return 0;
}

[Bug middle-end/116878] [15 regression] libcall emitted unnecessarily for __popcountdi2

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug tree-optimization/116879] [14/15 Regression] ICE on valid code at -O2 with "-ftree-vectorize -fallow-store-data-races -fno-tree-ch -ftree-loop-distribution" on x86_64-linux-gnu: verify_ssa failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||13.1.0, 13.3.0
 Ever confirmed|0   |1
   Last reconfirmed||2024-09-28
 Status|UNCONFIRMED |NEW
  Known to fail||14.1.0
   Target Milestone|--- |14.3
Version|unknown |15.0
Summary|ICE on valid code at -O2|[14/15 Regression] ICE on
   |with "-ftree-vectorize  |valid code at -O2 with
   |-fallow-store-data-races|"-ftree-vectorize
   |-fno-tree-ch|-fallow-store-data-races
   |-ftree-loop-distribution"   |-fno-tree-ch
   |on x86_64-linux-gnu:|-ftree-loop-distribution"
   |verify_ssa failed   |on x86_64-linux-gnu:
   ||verify_ssa failed
   Keywords||ice-checking

--- Comment #1 from Andrew Pinski  ---
Confirmed. Fails in GCC 14.x too with -fchecking.

[Bug c++/116880] New: [15 Regression] too early coroutine destruction of co_await on nix-2.24.8

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

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

Bug ID: 116880
   Summary: [15 Regression] too early coroutine destruction of
co_await on nix-2.24.8
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Initially observed the failure as a SIGSEGV on a nix-2.24.8 testsuite. The test
runs on gcc-14 and fails on gcc-15 from r15-3941-g2531f014fb2364.

I think I managed to convert it to a build failure that complains about use of
a destroyed object:

// $ substitution-goal.cc
#include 

struct promise_type;
using handle_type = std::coroutine_handle;

struct Co {
handle_type handle;
using promise_type = ::promise_type;

explicit Co(handle_type handle) : handle(handle) {}

bool await_ready() { return false; }
std::coroutine_handle<> await_suspend(handle_type handle);
void await_resume() {}
};

struct Done {};

struct promise_type {
Co get_return_object();

std::suspend_always initial_suspend() { return {}; };
std::suspend_always final_suspend() noexcept { return {}; };
void return_value(Done) {}
void return_value(Co&&);
void unhandled_exception() { throw; };
Co&& await_transform(Co&& co) { return static_cast(co); }
};

Co tryToRun();

Co init()
{
co_await tryToRun();
co_return Done{};
}

Good gcc-14:

$ g++-14 -o bug.o -c substitution-goal.cc -std=c++2a -Werror=dangling-pointer
-Wall

Bad gcc-15:

$ g++-15 -o bug.o -c substitution-goal.cc -std=c++2a -Werror=dangling-pointer
-Wall
substitution-goal.cc: In function 'void init(_Z4initv.Frame*)':
substitution-goal.cc:36:23: error: using a dangling pointer to an unnamed
temporary [-Werror=dangling-pointer=]
   36 | co_await tryToRun();
  |   ^
substitution-goal.cc:36:22: note: unnamed temporary defined here
   36 | co_await tryToRun();
  |  ^~
cc1plus: some warnings being treated as errors

$ g++-15 -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-15.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-15.0.0/libexec/gcc/x86_64-unknown-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gcc-15.0.0
--with-gmp-include=/<>/gmp-6.3.0-dev/include
--with-gmp-lib=/<>/gmp-6.3.0/lib
--with-mpfr-include=/<>/mpfr-4.2.1-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.1/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-2.40-36-dev/include
--with-build-sysroot=/
--with-gxx-include-dir=/<>/gcc-15.0.0/include/c++/15.0.0/
--program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<>/isl-0.20 --disable-bootstrap
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0  (experimental) (GCC)

[Bug c/116881] New: Add __builtin_elementwise_*

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

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

Bug ID: 116881
   Summary: Add __builtin_elementwise_*
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

clang added a few __builtin_elementwise_* and __builtin_reduction_* and GCC
could implement some (but not all of these).

These are useful for generic vectors and should be lowered if the target does
NOT support them.

[Bug c++/116882] New: gcc-14 ICE with coroutines

[jeanmichael.celerier at gmail dot com via Gcc-bugs]

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

Bug ID: 116882
   Summary: gcc-14 ICE with coroutines
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeanmichael.celerier at gmail dot com
  Target Milestone: ---

Will try to reproduce - here is in the meantime a CI job:
https://github.com/celtera/avendish/actions/runs/11086764898/job/30804702919#step:7:1168
 

internal compiler error: in coro_promise_type_found_p, at
cp/coroutines.cc:460
  342 |   co_yield r;
  |   ^~~~
0x72cb50 coro_promise_type_found_p
../../src/gcc/cp/coroutines.cc:460
0xf47f16 finish_co_yield_expr(unsigned int, tree_node*)
../../src/gcc/cp/coroutines.cc:1238
0x10ed246 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:21674
0x10fba57 tsubst_stmt
../../src/gcc/cp/pt.cc:19485
0x10fdb27 tsubst_stmt
../../src/gcc/cp/pt.cc:18445
0x10fc7de tsubst_stmt
../../src/gcc/cp/pt.cc:18413
0x10fc7de tsubst_stmt
../../src/gcc/cp/pt.cc:18427
0x10fd34a tsubst_stmt
../../src/gcc/cp/pt.cc:18697
0x10fc783 tsubst_stmt
../../src/gcc/cp/pt.cc:18801
0x10fa7a2 tsubst_stmt
../../src/gcc/cp/pt.cc:18413
0x10fa7a2 instantiate_body
../../src/gcc/cp/pt.cc:27091
0x10fb645 instantiate_decl(tree_node*, bool, bool)
../../src/gcc/cp/pt.cc:27376
0x11207fb instantiate_pending_templates(int)
../../src/gcc/cp/pt.cc:27452
0xfbedb7 c_parse_final_cleanups()
../../src/gcc/cp/decl2.cc:5156
0x1211668 c_common_parse_file()
../../src/gcc/c-family/c-opts.cc:1329

[Bug sanitizer/116863] TSAN segfault in __sanitizer::CombinedAllocator::Allocate

[jpeng_xy at 163 dot com via Gcc-bugs]

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

--- Comment #2 from jiang peng  ---
(In reply to Andrew Pinski from comment #1)
> Can you report this upstream to LLVM (libsanitizer upstream is LLVM) since I
> suspect you will hit it with tsan with LLVM too?

I am grateful for your attention to this matter.I've reported the issue to LLVM
(https://github.com/llvm/llvm-project/issues/109742), but there's no response
yet.

[Bug ipa/113291] [14/15 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172

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

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

--- Comment #13 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jan Hubicka
:

https://gcc.gnu.org/g:2532944e3588cf69bce019eaf03de9c63b78568f

commit r13-9061-g2532944e3588cf69bce019eaf03de9c63b78568f
Author: Jan Hubicka 
Date:   Tue May 14 12:58:56 2024 +0200

Reduce recursive inlining of always_inline functions

this patch tames down inliner on (mutiply) self-recursive always_inline
functions.
While we already have caps on recursive inlning, the testcase combines
early inliner
and late inliner to get very wide recursive inlining tree.  The basic idea
is to
ignore DISREGARD_INLINE_LIMITS when deciding on inlining self recursive
functions
(so we cut on function being large) and clear the flag once it is detected.

I did not include the testcase since it still produces a lot of code and
would
slow down testing.  It also outputs many inlining failed messages that is
not
very nice, but it is hard to detect self recursin cycles in full generality
when indirect calls and other tricks may happen.

gcc/ChangeLog:

PR ipa/113291

* ipa-inline.cc (enum can_inline_edge_by_limits_flags): New enum.
(can_inline_edge_by_limits_p): Take flags instead of multiple
bools; add flag
for forcing inlinie limits.
(can_early_inline_edge_p): Update.
(want_inline_self_recursive_call_p): Update; use FORCE_LIMITS mode.
(check_callers): Update.
(update_caller_keys): Update.
(update_callee_keys): Update.
(recursive_inlining): Update.
(add_new_edges_to_heap): Update.
(speculation_useful_p): Update.
(inline_small_functions): Clear DECL_DISREGARD_INLINE_LIMITS on
self recursion.
(flatten_function): Update.
(inline_to_all_callers_1): Update.

(cherry picked from commit 1ec49897253e093e1ef6261eb104ac0c111bac83)

[Bug c++/116880] [15 Regression] too early coroutine destruction of co_await on nix-2.24.8

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

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

Iain Sandoe  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=116506
   Target Milestone|--- |15.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-09-28

--- Comment #2 from Iain Sandoe  ---
I think it's more likely related to 116506 than 102217 - but let's see when we
analyse more.

[Bug c++/116880] [15 Regression] too early coroutine destruction of co_await on nix-2.24.8

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #1 from Iain Sandoe  ---
thanks for the report 
however - the revision mentioned seems to be a change in documentation?

It is possibly related to PR116506 (to be confirmed)
- is it possible to attach the original (executable) test case?

[Bug c++/116882] gcc-14 ICE with coroutines

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-09-28
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
waiting for a reproduciable case.

[Bug c/116881] Add __builtin_elementwise_* and __builtin_reduction_*

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/116882] gcc-14 ICE with coroutines

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #2 from Arsen Arsenović  ---
probably fixed on trunk from a quick skim (but a preprocessed source would help
narrow down)

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

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

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

--- Comment #337 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #334)
> Created attachment 59216 [details]
> a patch to fix ICE in c#331
> 
> The patch preallocates R0 for those Sid memory patterns so as to shorten the
> live range of R0.  Tested target libgcc and libstdc++v3 build and c
> testsuilte only.

I guess at some points the mem loads will start to fail, too?  Hypothetically
we will need to do this for every insn that has the R0 restriction?

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

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

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

--- Comment #338 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #337)
> (In reply to Kazumoto Kojima from comment #334)
> > Created attachment 59216 [details]
> > a patch to fix ICE in c#331
> > 
> > The patch preallocates R0 for those Sid memory patterns so as to shorten the
> > live range of R0.  Tested target libgcc and libstdc++v3 build and c
> > testsuilte only.
> 
> I guess at some points the mem loads will start to fail, too? 
> Hypothetically we will need to do this for every insn that has the R0
> restriction?

Yes, I added movsf_ie_load_mem_index because I think that it will fail at some
high R0 pressure situation. 
I have no idea for other cases, though.  In any case, it may prove the need for
the R0 specific pass.

[Bug target/116839] %fs:(%reg32) is used as memory operand for x32

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-14 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:25cb153f93bb9ff3543ba8e31bbe7be4f6168aa4

commit r14-10716-g25cb153f93bb9ff3543ba8e31bbe7be4f6168aa4
Author: H.J. Lu 
Date:   Wed Sep 25 16:39:04 2024 +0800

x86: Don't use address override with segment regsiter

Address override only applies to the (reg32) part in the thread address
fs:(reg32).  Don't rewrite thread address like

(set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 98 [ __gmpfr_emax.0_1 ])
(mem/c:SI (plus:SI (plus:SI (unspec:SI [
(const_int 0 [0])
] UNSPEC_TP)
(reg:SI 107))
(const:SI (unspec:SI [
(symbol_ref:SI ("previous_emax") [flags 0x1a]
)
] UNSPEC_DTPOFF))) [1 previous_emax+0 S4 A32])))

if address override is used to avoid the invalid memory operand like

cmpl%fs:previous_emax@dtpoff(%eax), %r12d

gcc/

PR target/116839
* config/i386/i386.cc (ix86_rewrite_tls_address_1): Make it
static.  Return if TLS address is thread register plus an integer
register.

gcc/testsuite/

PR target/116839
* gcc.target/i386/pr116839.c: New file.

Signed-off-by: H.J. Lu 
(cherry picked from commit c79cc30862d7255ca15884aa956d1ccfa279d86a)

[Bug tree-optimization/116874] phiprop should handle more than just `*a`

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

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

--- Comment #2 from Richard Biener  ---
Note the desire of PHI-prop is to expose bare decls that then can be re-written
into SSA (for std::min/max).  So these cases were out-of-scope and I'm not sure
how useful the transform is - it would basically undo commoning of loads
thru sinking.  It _might_ enable SRA of the associated structures.

[Bug tree-optimization/116842] [15 Regression] ICE definition in block follows the use since r15-3734

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

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

--- Comment #5 from Richard Biener  ---
It's another case of "invariant" masked scheduling.  Not sure why the
workaround in SLP scheduling triggers here, investigating.

[Bug target/116839] %fs:(%reg32) is used as memory operand for x32

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-12 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:2e66eb7e7eae82bcd6675e79eabbdd6decfa9fe5

commit r12-10731-g2e66eb7e7eae82bcd6675e79eabbdd6decfa9fe5
Author: H.J. Lu 
Date:   Wed Sep 25 16:39:04 2024 +0800

x86: Don't use address override with segment regsiter

Address override only applies to the (reg32) part in the thread address
fs:(reg32).  Don't rewrite thread address like

(set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 98 [ __gmpfr_emax.0_1 ])
(mem/c:SI (plus:SI (plus:SI (unspec:SI [
(const_int 0 [0])
] UNSPEC_TP)
(reg:SI 107))
(const:SI (unspec:SI [
(symbol_ref:SI ("previous_emax") [flags 0x1a]
)
] UNSPEC_DTPOFF))) [1 previous_emax+0 S4 A32])))

if address override is used to avoid the invalid memory operand like

cmpl%fs:previous_emax@dtpoff(%eax), %r12d

gcc/

PR target/116839
* config/i386/i386.cc (ix86_rewrite_tls_address_1): Make it
static.  Return if TLS address is thread register plus an integer
register.

gcc/testsuite/

PR target/116839
* gcc.target/i386/pr116839.c: New file.

Signed-off-by: H.J. Lu 
(cherry picked from commit c79cc30862d7255ca15884aa956d1ccfa279d86a)

[Bug tree-optimization/116873] esra does not remove unused store sometimes

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

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

--- Comment #1 from Richard Biener  ---
SRA only removes aggregate copies if it totally scalarizes.

[Bug target/116839] %fs:(%reg32) is used as memory operand for x32

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-13 branch has been updated by H.J. Lu :

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

commit r13-9060-gbf5d8d44f7a8f90a2ebfe3f28689bc3d86e185fb
Author: H.J. Lu 
Date:   Wed Sep 25 16:39:04 2024 +0800

x86: Don't use address override with segment regsiter

Address override only applies to the (reg32) part in the thread address
fs:(reg32).  Don't rewrite thread address like

(set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 98 [ __gmpfr_emax.0_1 ])
(mem/c:SI (plus:SI (plus:SI (unspec:SI [
(const_int 0 [0])
] UNSPEC_TP)
(reg:SI 107))
(const:SI (unspec:SI [
(symbol_ref:SI ("previous_emax") [flags 0x1a]
)
] UNSPEC_DTPOFF))) [1 previous_emax+0 S4 A32])))

if address override is used to avoid the invalid memory operand like

cmpl%fs:previous_emax@dtpoff(%eax), %r12d

gcc/

PR target/116839
* config/i386/i386.cc (ix86_rewrite_tls_address_1): Make it
static.  Return if TLS address is thread register plus an integer
register.

gcc/testsuite/

PR target/116839
* gcc.target/i386/pr116839.c: New file.

Signed-off-by: H.J. Lu 
(cherry picked from commit c79cc30862d7255ca15884aa956d1ccfa279d86a)

[Bug tree-optimization/116842] [15 Regression] ICE definition in block follows the use since r15-3734

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Mine then.

[Bug target/116839] %fs:(%reg32) is used as memory operand for x32

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Fixed for GCC 15, 14.3, 13.4 and 12.5.

[Bug c++/116872] gcc accepts unnormalized identifiers

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
MICRO SIGN is not listed in the charts of characters that differ from their
normalized forms: https://www.unicode.org/charts/normalization/

Running:
const micro = '\u00B5';
console.log(micro === micro.normalize('NFC'));
at e.g.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize
shows that \u00B5 does not change when normalized using NFC.

So I think we can close this.

[Bug rtl-optimization/116875] New: Internal compiler error: in make_decl_rtl, at varasm.cc:1443

[chilikin.k at gmail dot com via Gcc-bugs]

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

Bug ID: 116875
   Summary: Internal compiler error: in make_decl_rtl, at
varasm.cc:1443
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chilikin.k at gmail dot com
  Target Milestone: ---

Created attachment 59217
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59217&action=edit
test.f90

With gfortran 14.1.0:

$ cat test.f90 

MODULE M1
  IMPLICIT NONE

  ABSTRACT INTERFACE
SUBROUTINE S1()
END SUBROUTINE
  END INTERFACE

END MODULE
$ cat test2.f90 

MODULE M2
  USE M1

CONTAINS

  SUBROUTINE CALL_S1(S1_POINTER)
PROCEDURE(S1), POINTER :: S1_POINTER
CALL S1_POINTER()
  END SUBROUTINE

  SUBROUTINE S2()
BLOCK
  PROCEDURE(S1), POINTER :: S1_POINTER
  CALL CALL_S1(S1_POINTER)
END BLOCK
  END SUBROUTINE

END MODULE
$ gfortran -c test.f90
$ gfortran -c test2.f90
during RTL pass: expand
test2.f90:15:30:

   15 |   CALL CALL_S1(S1_POINTER)
  |  ^
internal compiler error: in make_decl_rtl, at varasm.cc:1443
0x7f257a0ab249 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f257a0ab304 __libc_start_main_impl
../csu/libc-start.c:360
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/116875] Internal compiler error: in make_decl_rtl, at varasm.cc:1443

[chilikin.k at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Kirill Chilikin  ---
Created attachment 59218
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59218&action=edit
test2.f90

[Bug c++/116872] gcc accepts unnormalized identifiers

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
And
00B5  ; XID_Start # L&   MICRO SIGN
and
00B5  ; XID_Continue # L&   MICRO SIGN
so it should be accepted both at the start and elsewhere in identifiers.

[Bug tree-optimization/116842] [15 Regression] ICE definition in block follows the use since r15-3734

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

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

--- Comment #6 from Richard Biener  ---
The issue is that we have a load we hoist as invariant and that in turn
uses hoist_defs_of_uses which moves in-loop stmts to the preheader.  Those
stmts have UIDs since they have stmt_vec_infos but the hoisting does not
preserve their order which later confuses vect_stmt_dominates_stmt_p.

I have a patch that preserves that order.

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

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

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

--- Comment #336 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #335)

> FWIW, the backend has improved quite a lot over the past weeks. The
> Dreamcast people reported good results as well!

As for the Dreamcast people, they are back to sqrt(1) compared to non-LRA with
current compiler.  So far no real benefits.  They'd benefit from different
things like fixed FSCA register issue and FIPR instruction support.

However, the good thing is that some of the LRA issues have been resolved which
allows them to at least build & run with LRA enabled.  That is a step forward!

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

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

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

--- Comment #341 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #338)
> (In reply to Oleg Endo from comment #337)
> > (In reply to Kazumoto Kojima from comment #334)
> > > Created attachment 59216 [details]
> > > a patch to fix ICE in c#331
> > > 
> > > The patch preallocates R0 for those Sid memory patterns so as to shorten 
> > > the
> > > live range of R0.  Tested target libgcc and libstdc++v3 build and c
> > > testsuilte only.
> > 
> > I guess at some points the mem loads will start to fail, too? 
> > Hypothetically we will need to do this for every insn that has the R0
> > restriction?
> 
> Yes, I added movsf_ie_load_mem_index because I think that it will fail at
> some high R0 pressure situation. 

I've added your patch to the pile in
https://github.com/olegendo/gcc/commits/devel/sh-lra/


> I have no idea for other cases, though.  In any case, it may prove the need
> for the R0 specific pass.

Do you have any idea how that might work?  The only thing I can think of right
now is to remove R0 from list of allocatable registers and add an RTL pass
before RA which will insert "pseudo -> R0" before R0 constrained insns and "R0
-> pseudo" after constrained insns.  I think this should be almost
bullet-proof, but at the expense of potentially losing one register (R0).

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

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

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

--- Comment #345 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #341)
> Do you have any idea how that might work?  The only thing I can think of
> right now is to remove R0 from list of allocatable registers and add an RTL
> pass before RA which will insert "pseudo -> R0" before R0 constrained insns
> and "R0 -> pseudo" after constrained insns.  I think this should be almost
> bullet-proof, but at the expense of potentially losing one register (R0).

No, I don't have any specific idea, though I was envisioning the approach what
you suggested.

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

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

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

--- Comment #342 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #339)
> /home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/
> JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-f2e18ffc-36.cpp
> (...)
> {standard input}: Assembler messages:
> {standard input}:6139: Error: syntax error in @(disp,[Rn, gbr, pc])
> {standard input}:6139: Error: invalid operands for opcode
> {standard input}:54249: Error: syntax error in @(disp,[Rn, gbr, pc])
> {standard input}:54249: Error: invalid operands for opcode
> {standard input}:59575: Error: syntax error in @(disp,[Rn, gbr, pc])
> {standard input}:59575: Error: invalid operands for opcode
> {standard input}:61031: Error: syntax error in @(disp,[Rn, gbr, pc])
> {standard input}:61031: Error: invalid operands for opcode
> 

I was able to reproduce it sh-elf copmiler by compiling the attached .ii file
with the following options:

sh-elf-gcc -c -m4 -ml -matomic-model=soft-gusa -Wextra -Wall -pipe
-fmax-errors=20 -Wno-odr -Wno-stringop-overread -Wno-stringop-overflow
-Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type
-Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef
-Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align
-Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
-g1 -O2 fstack-protector-strong -fPIE -Wformat -Werror=format-security
-fno-strict-aliasing -fno-exceptions -fno-rtti -fcoroutines -ffunction-sections
-fdata-sections -fPIC -fvisibility=hidden -ffp-contract=off -std=c++23
-save-temps -dp test.ii


The problematic insn is:
fldsfr1,fpul! 1297  [c=4 l=2]  movsi_ie/21
mov.b   @(5,fpul),r0! 517   [c=2 l=2]  *movqi/8  <<


now that looks like quite some adventurous register usage.

This should actually be rejected by the 'sh_legitimate_address_p' function.  I
guess that a check is missing somewhere in the code that does the
transformation?

[Bug target/116883] Compile cpp code with rv32imafc_zve32f failed

[fanghuaqi at vip dot qq.com via Gcc-bugs]

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

--- Comment #1 from Huaqi  ---
but when I compile it by adding _zvl64b using command line


riscv64-unknown-elf-gcc -march=rv32imafc_zve32f_zvl64b -mabi=ilp32f -c tmp.cpp  


it will not report any error

[Bug target/116883] New: Compile cpp code with rv32imafc_zve32f failed

[fanghuaqi at vip dot qq.com via Gcc-bugs]

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

Bug ID: 116883
   Summary: Compile cpp code with rv32imafc_zve32f failed
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fanghuaqi at vip dot qq.com
  Target Milestone: ---

Test code can be found in https://godbolt.org/z/fWWMbTMod

As below

cat tmp.cpp

#include 

int main()
{
unsigned long arraya[128], arrayb[128], arrayc[128];
for (int i; i < 128; i++) 
{
arraya[i] = arrayb[i] + arrayc[i];
}
return 0;
}

riscv64-unknown-elf-gcc -march=rv32imafc_zve32f -mabi=ilp32f -c tmp.cpp

It will report error like this 

/opt/compiler-explorer/riscv32/gcc-trunk-20240928/riscv32-unknown-linux-gnu/lib/gcc/riscv32-unknown-linux-gnu/15.0.0/include/riscv_vector.h:40:25:
error: ambiguating new declaration of 'vint64m4_t __riscv_vle64(vbool16_t,
const long long int*, unsigned int)'
   40 | #pragma riscv intrinsic "vector"
  | ^~~~
/opt/compiler-explorer/riscv32/gcc-trunk-20240928/riscv32-unknown-linux-gnu/lib/gcc/riscv32-unknown-linux-gnu/15.0.0/include/riscv_vector.h:40:25:
note: old declaration 'vint64m1_t __riscv_vle64(vbool64_t, const long long
int*, unsigned int)'
/opt/compiler-explorer/riscv32/gcc-trunk-20240928/riscv32-unknown-linux-gnu/lib/gcc/riscv32-unknown-linux-gnu/15.0.0/include/riscv_vector.h:40:25:
error: ambiguating new declaration of 'vuint64m4_t __riscv_vle64(vbool16_t,
const long long unsigned int*, unsigned int)'
/opt/compiler-explorer/riscv32/gcc-trunk-20240928/riscv32-unknown-linux-gnu/lib/gcc/riscv32-unknown-linux-gnu/15.0.0/include/riscv_vector.h:40:25:
note: old declaration 'vuint64m1_t __riscv_vle64(vbool64_t, const long long
unsigned int*, unsigned int)'


It works in gcc 13.3.0, clang 19.1.0 and clang truck(20), but failed in gcc
14.1.0/14.2.0/truck(15)

Thanks

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

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

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

--- Comment #343 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #342)
> (In reply to John Paul Adrian Glaubitz from comment #339)
> > /home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/
> > JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-f2e18ffc-36.cpp
> > (...)
> > {standard input}: Assembler messages:
> > {standard input}:6139: Error: syntax error in @(disp,[Rn, gbr, pc])
> > {standard input}:6139: Error: invalid operands for opcode
> > {standard input}:54249: Error: syntax error in @(disp,[Rn, gbr, pc])
> > {standard input}:54249: Error: invalid operands for opcode
> > {standard input}:59575: Error: syntax error in @(disp,[Rn, gbr, pc])
> > {standard input}:59575: Error: invalid operands for opcode
> > {standard input}:61031: Error: syntax error in @(disp,[Rn, gbr, pc])
> > {standard input}:61031: Error: invalid operands for opcode
> > 
> 
> I was able to reproduce it sh-elf copmiler by compiling the attached .ii
> file with the following options:
> 
> sh-elf-gcc -c -m4 -ml -matomic-model=soft-gusa -Wextra -Wall -pipe
> -fmax-errors=20 -Wno-odr -Wno-stringop-overread -Wno-stringop-overflow
> -Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type
> -Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef
> -Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align
> -Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
> -g1 -O2 fstack-protector-strong -fPIE -Wformat -Werror=format-security
> -fno-strict-aliasing -fno-exceptions -fno-rtti -fcoroutines
> -ffunction-sections -fdata-sections -fPIC -fvisibility=hidden
> -ffp-contract=off -std=c++23 -save-temps -dp test.ii
> 
> 
> The problematic insn is:
>   fldsfr1,fpul! 1297  [c=4 l=2]  movsi_ie/21
>   mov.b   @(5,fpul),r0! 517   [c=2 l=2]  *movqi/8  <<
> 
> 
> now that looks like quite some adventurous register usage.
> 
> This should actually be rejected by the 'sh_legitimate_address_p' function. 
> I guess that a check is missing somewhere in the code that does the
> transformation?

Yes. The wrong instruction

mov.b   @(5,fpul),r0! 517   [c=2 l=2]  *movqi/8

is generated with *movqi insn which is defined by

(define_insn "*mov"
  [(set (match_operand:QIHI 0 "general_movdst_operand"
  "=r,r,r,Sid,^zr,Ssd,r,  Sdd,z,  r,l")
(match_operand:QIHI 1 "general_movsrc_operand"
   "Q,r,i,^zr,Sid,r,  Ssd,z,  Sdd,l,r"))]
  "TARGET_SH1
   && (arith_reg_operand (operands[0], mode)
   || arith_reg_operand (operands[1], mode))"

and the 8-th alternative is an Sdd memory load.  general_mov{dst,src}_operand
predicates check the memory displacement expression.  They only check the
address register with REG_P, though.

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

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

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

--- Comment #344 from Kazumoto Kojima  ---
Created attachment 59219
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59219&action=edit
a patch for c#339

This adds checks if the address register of the memory displacement is general
or pseudo.  Tested target libgcc and libstdc++v3 build and c testsuilte.

[Bug c++/116876] GCC accepts invalid call to overloaded function template when neither is at least as specialized as the other

[jlame646 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Jason Liam  ---
> So are you sure this is not a clang issue?

Yes, because [temp.deduct.partial#9.1] make the second overload not to be
atleast as specialized as the first and then [temp.deduct.partial#9.2] make the
first template not to be atleast as specialized as the second. So neither
overloads are at least as specialized than the other and hence also **neither
of them more specialized**.

This was explained in the thread link I posted in the original bug:
https://stackoverflow.com/a/79034540/12002570

Now coming to the example you gave where we have changed the second overload to
`f(T&&)`, this starts working because then the [temp.deduct.partial#9.2] will
no longer apply and we will get on of the overloads more specialized than the
other.