[Bug middle-end/114912] [15 regression] SIGBUS in wi::copy<> on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #6 from Andrew Pinski --- I might see if I can figure out a patch for some to try later tonight.
[Bug middle-end/114912] [15 regression] SIGBUS in wi::copy<> on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #5 from Andrew Pinski --- I see the issue then. char m_buffer[sizeof (int_range_max)]; Needs _Align to get the alignment correct.
[Bug middle-end/114912] [15 regression] SIGBUS in wi::copy<> on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #4 from Rainer Orth --- Created attachment 58081 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58081=edit preprocessed input
[Bug middle-end/114912] [15 regression] SIGBUS in wi::copy<> on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #3 from Rainer Orth --- (In reply to Aldy Hernandez from comment #1) > Since this happens while building libgcc during stage1, perhaps this can be > reproduced with a cross? Would it be possible to get the preprocessed file > that's failing? I doubt this can be seen in a cross: running the compilation under truss reveals the SIGBUS as 2834: Incurred fault #5, FLTACCESS %pc = 0x00723E58 2834: siginfo: SIGBUS BUS_ADRALN addr=0xFFBFC954 2834: Received signal #10, SIGBUS [caught] 2834: siginfo: SIGBUS BUS_ADRALN addr=0xFFBFC954 i.e. an unaligned access. While SPARC is a strict-alignment target, x86 cares little if any about alignment at all. > You could try /var/gcc/reghunt/sigbus-range/288807/./gcc/xgcc -save-temps > [blah blah], and attach the libgcc2.i file that gets generated. Sure, please find _muldi3.i attached. cc1 invocation is cc1 -fpreprocessed _muldi3.i -quiet -dumpbase _muldi3.c -dumpbase-ext .c -mcpu=v9 -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fbuilding-libgcc -fno-stack-protector -fPIC -fvisibility=hidden -o _muldi3.s
[Bug c/114873] Incorrect warning generated for [*] array when in atomic or typeof type specifier for a parameter declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114873 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #6 from Martin Uecker --- Supporting this seems better than forcing the user to work around by providing an incorrect size such as (0, 0).
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 --- Comment #23 from GCC Commits --- The releases/gcc-13 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:0ae9252f7b52151209b36d8a1cefc49f1b23fa46 commit r13-8673-g0ae9252f7b52151209b36d8a1cefc49f1b23fa46 Author: Will Schmidt Date: Fri Apr 12 14:55:16 2024 -0500 rs6000: Add OPTION_MASK_POWER8 [PR101865] The bug in PR101865 is the _ARCH_PWR8 predefine macro is conditional upon TARGET_DIRECT_MOVE, which can be false for some -mcpu=power8 compiles if the -mno-altivec or -mno-vsx options are used. The solution here is to create a new OPTION_MASK_POWER8 mask that is true for -mcpu=power8, regardless of Altivec or VSX enablement. Unfortunately, the only way to create an OPTION_MASK_* mask is to create a new option, which we have done here, but marked it as WarnRemoved since we do not want users using it. For stage1, we will look into how we can create ISA mask flags for use in the compiler without the need for explicit options. 2024-04-12 Will Schmidt Peter Bergner gcc/ PR target/101865 * config/rs6000/rs6000-builtin.cc (rs6000_builtin_is_supported): Use TARGET_POWER8. * config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Use OPTION_MASK_POWER8. * config/rs6000/rs6000-cpus.def (POWERPC_MASKS): Add OPTION_MASK_POWER8. (ISA_2_7_MASKS_SERVER): Likewise. * config/rs6000/rs6000.cc (rs6000_option_override_internal): Update comment. Use OPTION_MASK_POWER8 and TARGET_POWER8. * config/rs6000/rs6000.h (TARGET_SYNC_HI_QI): Use TARGET_POWER8. * config/rs6000/rs6000.md (define_attr "isa"): Add p8. (define_attr "enabled"): Handle it. (define_insn "prefetch"): Use TARGET_POWER8. * config/rs6000/rs6000.opt (mpower8-internal): New. gcc/testsuite/ PR target/101865 * gcc.target/powerpc/predefine-p7-novsx.c: New test. * gcc.target/powerpc/predefine-p8-noaltivec-novsx.c: New test. * gcc.target/powerpc/predefine-p8-noaltivec.c: New test. * gcc.target/powerpc/predefine-p8-novsx.c: New test. * gcc.target/powerpc/predefine-p8-pragma-vsx.c: New test. * gcc.target/powerpc/predefine-p9-novsx.c: New test. (cherry picked from commit aa57af93ba22865be747f926e4e5f219e7f8758a)
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 --- Comment #22 from GCC Commits --- The releases/gcc-13 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:d42105742841e73ca867b6da0c5ca6ad4d86fed6 commit r13-8672-gd42105742841e73ca867b6da0c5ca6ad4d86fed6 Author: Peter Bergner Date: Tue Apr 9 15:24:39 2024 -0500 rs6000: Replace OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR [PR101865] This is a cleanup patch in preparation to fixing the real bug in PR101865. TARGET_DIRECT_MOVE is redundant with TARGET_P8_VECTOR, so alias it to that. Also replace all usages of OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR and delete the now dead mask. 2024-04-09 Peter Bergner gcc/ PR target/101865 * config/rs6000/rs6000.h (TARGET_DIRECT_MOVE): Define. * config/rs6000/rs6000.cc (rs6000_option_override_internal): Replace OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR. Delete redundant OPTION_MASK_DIRECT_MOVE usage. Delete TARGET_DIRECT_MOVE dead code. (rs6000_opt_masks): Neuter the "direct-move" option. * config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Replace OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR. Delete useless comment. * config/rs6000/rs6000-cpus.def (ISA_2_7_MASKS_SERVER): Delete OPTION_MASK_DIRECT_MOVE. (OTHER_P8_VECTOR_MASKS): Likewise. (POWERPC_MASKS): Likewise. * config/rs6000/rs6000.opt (mdirect-move): Remove Mask and Var. (cherry picked from commit 7924e352523b37155ed9d76dc426701de9d11a22)
[Bug regression/111709] [13/14/15 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709 --- Comment #13 from matoro --- Current state of this has expanded to more of the math tests. FAIL: math/test-double-fma FAIL: math/test-double-j0 FAIL: math/test-double-j1 FAIL: math/test-double-ldouble-fma FAIL: math/test-double-log FAIL: math/test-float32x-float64-fma FAIL: math/test-float32x-fma FAIL: math/test-float32x-j0 FAIL: math/test-float32x-j1 FAIL: math/test-float32x-log FAIL: math/test-float64-fma FAIL: math/test-float64-j0 FAIL: math/test-float64-j1 FAIL: math/test-float64-log FAIL: math/test-ldouble-fma FAIL: math/test-ldouble-j0 FAIL: math/test-ldouble-j1 FAIL: math/test-ldouble-log
[Bug target/101345] wrong code at -O1 with vector modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101345 Peter Bergner changed: What|Removed |Added Depends on||101129 --- Comment #4 from Peter Bergner --- (In reply to Jeevitha from comment #3) > The commit that resolved the incorrect code was > ad5f8ac1d2f2dc92d43663243b52f9e9eb3cf7c0, where Bill disabled the swap for > mult with subreg. This addressed the issue. Ok, so that was the fix for PR101129. Thanks for tracking that down Jeevitha! Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129 [Bug 101129] [11/12 Regression] wrong code at -O1 since r11-5839
[Bug c++/114917] [modules] Explicit specialisations in export namespace not permitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114917 Nathaniel Shead changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-05-02 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org
[Bug c++/114917] New: [modules] Explicit specialisations in export namespace not permitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114917
Bug ID: 114917
Summary: [modules] Explicit specialisations in export namespace
not permitted
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nshead at gcc dot gnu.org
Target Milestone: ---
Since r15-84-g79420dd3441458 we now incorrectly reject the following modules
example:
export module M;
export namespace ns {
template void foo() {}
template <> void foo() {}
}
Relatedly, we also incorrectly accept (and have since at least GCC 4.1):
extern "C++" namespace ns {
struct Incomplete;
Incomplete bar;
}
for similar reasons: the contents of the namespace are still considered be an
"unbraced" context of the extern "C++" and so bar is implicitly considered to
be declared extern. See also [dcl.link] p8.
[Bug c++/105224] [modules] g++.dg/modules/virt-2_a.C: inline key methods: c++ modules and arm aapcs clash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105224 Nathaniel Shead changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |15.0 CC||nshead at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #4 from Nathaniel Shead --- The generic C++ ABI now ignores key function determination for classes attached to named modules. As far as I can see the AAPCS has no wording to the contrary, so this issue should now be resolved for GCC 15.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 105224, which changed state. Bug 105224 Summary: [modules] g++.dg/modules/virt-2_a.C: inline key methods: c++ modules and arm aapcs clash https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105224 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/105224] [modules] g++.dg/modules/virt-2_a.C: inline key methods: c++ modules and arm aapcs clash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105224
--- Comment #3 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:ad30265ccfb211fca35789df2d1404cc12302219
commit r15-98-gad30265ccfb211fca35789df2d1404cc12302219
Author: Nathaniel Shead
Date: Tue Apr 16 22:50:26 2024 +1000
c++: Implement modules ABI for vtable emissions
This patch implements the changes described in
https://github.com/itanium-cxx-abi/cxx-abi/pull/171.
One restriction that is lifted in the ABI that hasn't been updated here
is that the ABI no longer requires unique vtables to be emitted with
vague linkage. I haven't changed this behaviour for this patch, but in
the future we could look into changing the relevant target hook
('class_data_always_comdat') to default to 'false'. But the current
behaviour is more forgiving to changes in key function identification.
Since the ABI for vtables attached to named modules no longer depends on
key methods, this also resolves the issue described in PR c++/105224.
PR c++/105224
gcc/cp/ChangeLog:
* class.cc (finish_struct_1): Also push classes attached to a
module into the 'keyed_classes' list.
* decl.cc (record_key_method_defined): Don't push classes
attached to a named module into the 'keyed_classes' list.
* module.cc (trees_in::read_class_def): Likewise.
* decl2.cc (import_export_class): Uniquely emit vtables for
non-template classes attached to a named module.
(vtables_uniquely_emitted): New function.
(import_export_decl): Update comments. Update with knowledge
about new kinds of uniquely emitted vtables.
gcc/testsuite/ChangeLog:
* g++.dg/modules/virt-2_a.C: Update linkage requirements.
* g++.dg/modules/virt-2_b.C: Likewise.
* g++.dg/modules/virt-2_c.C: Likewise.
* g++.dg/modules/virt-4_a.C: New test.
* g++.dg/modules/virt-4_b.C: New test.
Signed-off-by: Nathaniel Shead
Reviewed-by: Jason Merrill
[Bug target/114916] New: [14/15] RISC-V rv64gcv_zvl256b: miscompile at -O3 with -mrvv-vector-bits=zvl -fwhole-program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114916
Bug ID: 114916
Summary: [14/15] RISC-V rv64gcv_zvl256b: miscompile at -O3 with
-mrvv-vector-bits=zvl -fwhole-program
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at rivosinc dot com
Target Milestone: ---
Testcase:
long long c;
int d = 1;
char f[18];
short g[18];
unsigned long long h[18][18][18];
char a[324];
long b[18];
short *i = g;
unsigned long long (*j)[18][18] = h;
void k(long long *l, int p) { *l ^= p; }
int main() {
for (long m = 0; m < 18; ++m)
f[m] = 3;
for (int m = 0; m < 18; m += d )
for (short n = 0; n < 18; n += 3) {
a[m * 8 + n] = j[m][m][0] ? i[n] : 0;
b[n] = f[n] ? -i[m] : 0;
}
for (long n = 0; n < 8; ++n)
k(, a[n]);
__builtin_printf("%ld\n", b[15]);
}
Commands:
> /scratch/tc-testing/tc-apr-29/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gcv_zvl256b -flto -fno-strict-aliasing -O3 -mrvv-vector-bits=zvl
> red.c -o red.out
> QEMU_CPU=rv64,vlen=256,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
> /scratch/tc-testing/tc-apr-29/build-rv64gcv/bin/qemu-riscv64 red.out
-771
> /scratch/tc-testing/tc-apr-29/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> red.c -fno-strict-aliasing -o red.out
> QEMU_CPU=rv64,vlen=256,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
> /scratch/tc-testing/tc-apr-29/build-rv64gcv/bin/qemu-riscv64 red.out
0
i and g are never written to.
[Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746 --- Comment #7 from Vincent Lefèvre --- BTW, in /usr/include/math.h from the GNU libc 2.37: # define M_PI 3.14159265358979323846 /* pi */ i.e. M_PI is defined with 21 digits in base 10, which corresponds to about 70 digits in base 2, thus with the apparent intent to be accurate in extended precision (64 digits).
[Bug middle-end/114913] "verify_gimple failed" due to addition of two constexpr strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913 --- Comment #5 from Andrew Pinski --- (In reply to Jorg Brown from comment #4) > Also odd is that the above code (including a()) works fine on gcc 10.1 > through 13.2. As seen https://godbolt.org/z/z3qnosG37 This is not really odd since it does fail with those compilers with -fchecking (which is the default for the GCC trunk development). It also works with the trunk (in this case) with -fno-checking . Basically GCC has some internal checks to make sure things internally are consistent but they are failing in this case and you can turn them off/on at compile time.
[Bug c++/114915] Constrained auto deduction in specialized template scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114915 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-01 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug middle-end/114913] "verify_gimple failed" due to addition of two constexpr strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913
--- Comment #4 from Jorg Brown ---
Oddly, if I move the reference to HelloWorld into a separate routine, it works
(you can comment out a() and ba() returns what it should, on gcc 15.0)
struct strt {
const char *ptr =
char data = '\0';
constexpr strt() {}
constexpr strt(const strt &__str) {}
};
constexpr strt f() { return {}; }
constexpr strt HelloWorld = f();
// This works fine...
const strt () { return HelloWorld; }
const char *ba() { return b().ptr; }
// This causes the verify_gimple failure, on gcc 15
const char *a() { return HelloWorld.ptr; }
= - = - = - = - = - = - =
Also odd is that the above code (including a()) works fine on gcc 10.1 through
13.2. As seen https://godbolt.org/z/z3qnosG37
[Bug target/112959] install.tex needs updates on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959 Gerald Pfeifer changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |gerald at pfeifer dot com Status|NEW |ASSIGNED
[Bug c++/114915] New: Constrained auto deduction in specialized template scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114915
Bug ID: 114915
Summary: Constrained auto deduction in specialized template
scope
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sska1377 at gmail dot com
Target Milestone: ---
Here is a simple code that uses constrained auto deduction in a template
specialization scope. By removing the specialization, the code compiles
successfully. However, with the specialization, the code fails to compile, even
though both cases should be equivalent.
Code:
template
concept TheConcept = __is_same(T, int);
template
void f() {
TheConcept auto x = 1;
}
/* Here is the problematic function,
by removing the specialization below, everything works */
template<>
void f() {
TheConcept auto x = 1;
}
int main() {
f();
return 0;
}
Command: $ g++ report.cpp -std=c++20 -Wall -Wextra -save-temps
Expected: Compilation success
Actual:
report.cpp: In function ‘void f() [with T = int]’:
report.cpp:11:23: error: deduced initializer does not satisfy placeholder
constraints
11 | TheConcept auto x = 1;
| ^
report.cpp:11:23: note: constraints not satisfied
report.cpp:2:9: required for the satisfaction of ‘TheConcept, >]>’ [with auto [requires
::TheConcept<, >] = auto [requires ::TheConcept<, >]]
report.cpp:2:22: note: ‘auto [requires ::TheConcept<, >]’ is not
the same as ‘int’
2 | concept TheConcept = __is_same(T, int);
| ^
FAIL
More info:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--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
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20240417 (GCC)
--- Comment #1 from Seyed Sajad Kahani ---
A possible fix:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650391.html
[Bug target/114910] can't build a c6x cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910 --- Comment #3 from Andrew Pinski --- LVL labels comes from the debugging info when it comes to variable tracking. This looks like it has always been broken ...
[Bug target/112959] install.tex needs updates on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:ff98aab108a6a4e50a831e7cfc011c2131f8d19c commit r15-96-gff98aab108a6a4e50a831e7cfc011c2131f8d19c Author: Gerald Pfeifer Date: Thu May 2 00:45:52 2024 +0200 doc: Describe limitations re Ada, D, and Go on FreeBSD gcc: PR target/69374 PR target/112959 * doc/install.texi (Specific) <*-*-freebsd*>: The Ada and D run-time libraries are broken on i386 which also can affect 64-bit builds. Go is broken.
[Bug target/69374] install.texi is bit-rotten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374 --- Comment #10 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:ff98aab108a6a4e50a831e7cfc011c2131f8d19c commit r15-96-gff98aab108a6a4e50a831e7cfc011c2131f8d19c Author: Gerald Pfeifer Date: Thu May 2 00:45:52 2024 +0200 doc: Describe limitations re Ada, D, and Go on FreeBSD gcc: PR target/69374 PR target/112959 * doc/install.texi (Specific) <*-*-freebsd*>: The Ada and D run-time libraries are broken on i386 which also can affect 64-bit builds. Go is broken.
[Bug target/114910] can't build a c6x cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910 --- Comment #2 from Andrew Pinski --- C6x Linux support was removed in 2021: https://lore.kernel.org/linux-arm-kernel/20210120124812.2800027-1-a...@kernel.org/T/ So maybe it is time to remove it from GCC too.
[Bug middle-end/114912] [15 regression] SIGBUS in wi::copy<> on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #2 from Andrew Pinski --- What compiler version are you starting with? It could be that compiler is miscompiling stage 1 here; especially when it comes to C++ usage is becoming more and more.
[Bug middle-end/114912] [15 regression] SIGBUS in wi::copy<> on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 --- Comment #1 from Aldy Hernandez --- Since this happens while building libgcc during stage1, perhaps this can be reproduced with a cross? Would it be possible to get the preprocessed file that's failing? You could try /var/gcc/reghunt/sigbus-range/288807/./gcc/xgcc -save-temps [blah blah], and attach the libgcc2.i file that gets generated.
[Bug c++/83912] [constexpr] struct with a pointer to one of its members, returned by a function, is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83912 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94470 --- Comment #5 from Andrew Pinski --- Most likely a dup of bug 94470 ...
[Bug middle-end/114913] "verify_gimple failed" due to addition of two constexpr strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913
--- Comment #3 from Andrew Pinski ---
here is a C++11 testcase:
```
struct strt {
char *_M_dataplus;
char _M_local_buf=0;
constexpr strt()
: _M_dataplus(&_M_local_buf) {}
constexpr strt(const strt &__str)
: _M_dataplus(&_M_local_buf) {}
};
constexpr strt
f() {
return {};
}
constexpr strt HelloWorld = f();
const char *a() { return HelloWorld._M_dataplus; }
```
it was rejected before GCC 10 with the following error message:
```
:13:31: error: 'strt{(&.strt::_M_local_buf), '\000'}' is not
a constant expression
13 | constexpr strt HelloWorld = f();
| ^
```
Maybe that will give an hint where the issue is ...
[Bug middle-end/114913] "verify_gimple failed" due to addition of two constexpr strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913
Andrew Pinski changed:
What|Removed |Added
Known to fail||13.2.0
--- Comment #2 from Andrew Pinski ---
Reduced testcase:
```
struct strt {
char *_M_dataplus;
char _M_local_buf[1];
constexpr strt() noexcept : _M_dataplus(_M_local_buf) {}
constexpr strt(const strt &__str) : _M_dataplus(_M_local_buf) {}
};
constexpr strt f() {
return {};
}
constexpr strt HelloWorld = f();
const char *a() { return HelloWorld._M_dataplus; }
```
[Bug c++/113141] [13 Regression] ICE on conversion to reference in aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113141 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Patrick Palka --- Fixed for 13.3/14.
[Bug c++/113141] [13 Regression] ICE on conversion to reference in aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113141 --- Comment #11 from GCC Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c70abea054fe0021b7b2c2e07996afaadc17a07b commit r13-8670-gc70abea054fe0021b7b2c2e07996afaadc17a07b Author: Patrick Palka Date: Wed May 1 18:16:08 2024 -0400 c++: problematic assert in reference_binding [PR113141] r14-9946 / r14-9947 fixed this PR properly for GCC 14. For GCC 13, let's just remove the problematic assert. PR c++/113141 gcc/cp/ChangeLog: * call.cc (reference_binding): Remove badness criteria sanity check in the recursive case. gcc/testsuite/ChangeLog: * g++.dg/conversion/ref12.C: New test. * g++.dg/cpp0x/initlist-ref1.C: new test.
[Bug analyzer/114914] New: False positive with -Wanalyzer-out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114914 Bug ID: 114914 Summary: False positive with -Wanalyzer-out-of-bounds Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: udo at hypervisor dot org Target Milestone: --- Created attachment 58079 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58079=edit Test case For the attached test case, the analyzer incorrectly flags an array overflow as follows: test.c:7:9: note: valid subscripts for ‘c’ are ‘[0]’ to ‘[1]’ The analyzer doesn't grok that v is in range 253...254 in the else-branch of x() and therefore n is in range 0...1 when f() is called. Reproducer: https://godbolt.org/z/fnxxns13x The false positive occurs with gcc-14.1.0-RC-20240430. The latest release (gcc-13.2) sees nothing wrong with this code. I would therefore consider this a regression.
[Bug middle-end/114913] "verify_gimple failed" due to addition of two constexpr strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-01 Ever confirmed|0 |1
[Bug middle-end/114913] "verify_gimple failed" due to addition of two constexpr strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913 --- Comment #1 from Andrew Pinski --- Reducing, note this ICEs only with checking enable and not release checking ...
[Bug c++/114913] New: "verify_gimple failed" due to addition of two constexpr strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913
Bug ID: 114913
Summary: "verify_gimple failed" due to addition of two
constexpr strings
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jorg.brown at gmail dot com
Target Milestone: ---
Source:
#include
constexpr std::string Hello = "Hello, ", World = "World.";
constexpr std::string HelloWorld = Hello + World;
int main() { printf("%s\n", HelloWorld.c_str()); }
= - = - = - = - = - = - = - = - = - = - = - = - = - = - = - =
Version:
g++
(Compiler-Explorer-Build-gcc-610415bb7ddc5626ec301ca20833e78696978601-binutils-2.40)
15.0.0 20240501 (experimental)
Copyright (C) 2024 Free Software Foundation, Inc.
ASM generation compiler returned: 0
g++
(Compiler-Explorer-Build-gcc-610415bb7ddc5626ec301ca20833e78696978601-binutils-2.40)
15.0.0 20240501 (experimental)
Copyright (C) 2024 Free Software Foundation, Inc.
= - = - = - = - = - = - = - = - = - = - = - = - = - = - = - =
As seen at https://godbolt.org/z/hd1TbM61Y , I got:
: In function 'int main()':
:8:50: error: constant not recomputed when 'ADDR_EXPR' changed
8 | int main() { printf("%s\n", HelloWorld.c_str()); }
| ^
_3 = _M_local_buf;
during GIMPLE pass: einline
:8:50: internal compiler error: verify_gimple failed
0x267adac internal_error(char const*, ...)
???:0
0x13e317e verify_gimple_in_cfg(function*, bool, bool)
???:0
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.
Compiler returned: 1
= - = - = - = - = - = - = - = - = - = - = - = - = - = - = - =
I don't have access to the gcc executable causing this problem, and
-freport-bug doesn't work from godbolt, so I can't give you the preprocessed
input.
[Bug c++/114911] Anonymous unions can cause ICE when the name of their type escapes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114911 Andrew Pinski changed: What|Removed |Added Known to fail||4.7.1 Keywords|ice-checking| --- Comment #1 from Andrew Pinski --- Not changing `::a` to be a full definition: int T::*b = ::a; or auto b = ::a; Gives an ICE all the way back to GCC 4.7.
[Bug c++/56427] [C++11] template template parameter template parameter pack that depends on another parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56427 Bug 56427 depends on bug 114377, which changed state. Bug 114377 Summary: [13 Regression] GCC crashes on an example of CTAD for alias templates https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114377 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/114377] [13 Regression] GCC crashes on an example of CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114377 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jason Merrill --- Fixed for 13.3/14.
[Bug c++/114377] [13 Regression] GCC crashes on an example of CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114377 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:60e1e13f458f1fcfb05a30ace57fa682461e2732 commit r13-8669-g60e1e13f458f1fcfb05a30ace57fa682461e2732 Author: centurion Date: Wed Mar 27 18:36:37 2024 + c++: alias CTAD and template template parm [PR114377] To match all the other places that pull a _TEMPLATE_PARM out of a _DECL (get_template_parm_index, etc.). This change is too small to be legally significant for copyright. PR c++/114377 gcc/cp/ChangeLog: * pt.cc (find_template_parameter_info::found): Use TREE_TYPE for TEMPLATE_DECL instead of DECL_INITIAL. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/class-deduction-alias19.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit 801e82acd6b4f0cf863529875947e394899ea7b9)
[Bug c++/114562] [11/12/13 Regression] ICE when trying to bind rvalue reference to lvalue with comma operator and forwarding reference to pointer since r10-7410
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114562 --- Comment #3 from GCC Commits --- The releases/gcc-13 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7bc362ea61e5bf552356aa862beb7845fe50a47c commit r13-8668-g7bc362ea61e5bf552356aa862beb7845fe50a47c Author: Jason Merrill Date: Tue Apr 2 10:52:28 2024 -0400 c++: binding reference to comma expr [PR114561] We represent a reference binding where the referent type is more qualified by a ck_ref_bind around a ck_qual. We performed the ck_qual and then tried to undo it with STRIP_NOPS, but that doesn't work if the conversion is buried in COMPOUND_EXPR. So instead let's avoid performing that fake conversion in the first place. PR c++/114561 PR c++/114562 gcc/cp/ChangeLog: * call.cc (convert_like_internal): Avoid adding qualification conversion in direct reference binding. gcc/testsuite/ChangeLog: * g++.dg/conversion/ref10.C: New test. * g++.dg/conversion/ref11.C: New test. (cherry picked from commit 5d7e9a35024f065b25f61747859c7cb7a770c92b)
[Bug c++/114561] [11/12/13 Regression] Comma operator with forwarding reference to pointer raises invalid lvalue required error since r10-7410
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7bc362ea61e5bf552356aa862beb7845fe50a47c commit r13-8668-g7bc362ea61e5bf552356aa862beb7845fe50a47c Author: Jason Merrill Date: Tue Apr 2 10:52:28 2024 -0400 c++: binding reference to comma expr [PR114561] We represent a reference binding where the referent type is more qualified by a ck_ref_bind around a ck_qual. We performed the ck_qual and then tried to undo it with STRIP_NOPS, but that doesn't work if the conversion is buried in COMPOUND_EXPR. So instead let's avoid performing that fake conversion in the first place. PR c++/114561 PR c++/114562 gcc/cp/ChangeLog: * call.cc (convert_like_internal): Avoid adding qualification conversion in direct reference binding. gcc/testsuite/ChangeLog: * g++.dg/conversion/ref10.C: New test. * g++.dg/conversion/ref11.C: New test. (cherry picked from commit 5d7e9a35024f065b25f61747859c7cb7a770c92b)
[Bug libstdc++/100667] [11/12/13 Regression] std::tuple cannot be constructed from A&&, if A not defined (only forward declared)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667 --- Comment #14 from GCC Commits --- The releases/gcc-13 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:19821ce86afa0f4ce0d2312b16864c809e605be9 commit r13-8667-g19821ce86afa0f4ce0d2312b16864c809e605be9 Author: Jason Merrill Date: Wed Mar 27 16:14:01 2024 -0400 c++: __is_constructible ref binding [PR100667] The requirement that a type argument be complete is excessive in the case of direct reference binding to the same type, which does not rely on any properties of the type. This is LWG 2939. PR c++/100667 gcc/cp/ChangeLog: * semantics.cc (same_type_ref_bind_p): New. (finish_trait_expr): Use it. gcc/testsuite/ChangeLog: * g++.dg/ext/is_constructible8.C: New test. (cherry picked from commit 8bb3ef3f6e335e8794590fb712a2661d11d21973)
[Bug middle-end/114912] [15 regression] SIGBUS in wi::copy<> on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 Rainer Orth changed: What|Removed |Added Target Milestone|--- |15.0
[Bug middle-end/114912] New: [15 regression] SIGBUS in wi::copy<> on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912 Bug ID: 114912 Summary: [15 regression] SIGBUS in wi::copy<> on SPARC Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: aldyh at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 Between 20240430 (0b2735e0797fee9b4ec5cd74f22afe0483f888dd) and 20240501 (c3bc2787b8beb7aae67fdf2a7f7271a9a4edca7c), Solaris/SPARC bootstrap began to fail with a SIGBUS in cc1 compiling stage 1 libgcc. E.g. /var/gcc/reghunt/sigbus-range/288807/./gcc/xgcc -B/var/gcc/reghunt/sigbus-range/288807/./gcc/ -B/usr/local/sparc-sun-solaris2.11/bin/ -B/usr/local/sparc-sun-solaris2.11/lib/ -isystem /usr/local/sparc-sun-solaris2.11/include -isystem /usr/local/sparc-sun-solaris2.11/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -I. -I. -I../.././gcc -I/var/gcc/reghunt/master/libgcc -I/var/gcc/reghunt/master/libgcc/. -I/var/gcc/reghunt/master/libgcc/../gcc -I/var/gcc/reghunt/master/libgcc/../include -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /var/gcc/reghunt/master/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS during GIMPLE pass: evrp /var/gcc/reghunt/master/libgcc/libgcc2.c: In function ‘__muldi3’: /var/gcc/reghunt/master/libgcc/libgcc2.c:538:1: internal compiler error: Bus Error 538 | } | ^ 0xf26783 crash_signal /var/gcc/reghunt/master/gcc/toplev.cc:319 0x723e58 void wi::copy > >(wide_int_storage&, generic_wide_int > const&) /var/gcc/reghunt/master/gcc/wide-int.h:2191 0x723e58 wide_int_storage& wide_int_storage::operator=(wi::hwi_with_prec const&) /var/gcc/reghunt/master/gcc/wide-int.h:1247 0x723e58 generic_wide_int& generic_wide_int::operator=(wi::hwi_with_prec const&) /var/gcc/reghunt/master/gcc/wide-int.h:1002 0x723e58 irange_bitmask::set_unknown(unsigned int) /var/gcc/reghunt/master/gcc/value-range.h:163 0x723e58 irange::set_varying(tree_node*) /var/gcc/reghunt/master/gcc/value-range.h:1067 0x13680db gimple_range_global(vrange&, tree_node*, function*) /var/gcc/reghunt/master/gcc/value-query.cc:419 0x136954f global_range_query::range_of_expr(vrange&, tree_node*, gimple*) /var/gcc/reghunt/master/gcc/value-query.cc:436 0x1ad000b fur_stmt::get_operand(vrange&, tree_node*) /var/gcc/reghunt/master/gcc/gimple-range-fold.cc:162 0x1ad5edb fold_using_range::range_of_range_op(vrange&, gimple_range_op_handler&, fur_source&) /var/gcc/reghunt/master/gcc/gimple-range-fold.cc:673 0x1ad831f fold_using_range::fold_stmt(vrange&, gimple*, fur_source&, tree_node*) /var/gcc/reghunt/master/gcc/gimple-range-fold.cc:604 0x1ad8927 fold_range(vrange&, gimple*, range_query*) /var/gcc/reghunt/master/gcc/gimple-range-fold.cc:324 0x1ac8727 ranger_cache::get_global_range(vrange&, tree_node*, bool&) /var/gcc/reghunt/master/gcc/gimple-range-cache.cc:1054 0x1abefaf gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*) /var/gcc/reghunt/master/gcc/gimple-range.cc:323 0x1367d2f range_query::value_of_stmt(gimple*, tree_node*) /var/gcc/reghunt/master/gcc/value-query.cc:133 0x1315c3f rvrp_folder::value_of_stmt(gimple*, tree_node*) /var/gcc/reghunt/master/gcc/tree-vrp.cc:1001 0x11ab12f substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) /var/gcc/reghunt/master/gcc/tree-ssa-propagate.cc:820 0x1a4df83 dom_walker::walk(basic_block_def*) /var/gcc/reghunt/master/gcc/domwalk.cc:311 0x11a9d07 substitute_and_fold_engine::substitute_and_fold(basic_block_def*) /var/gcc/reghunt/master/gcc/tree-ssa-propagate.cc:999 0x13132f7 execute_ranger_vrp(function*, bool, bool) /var/gcc/reghunt/master/gcc/tree-vrp.cc:1066 A reghunt identified commit c60b3e211c555706cdc2dc8bfcdd540152cff350 Author: Aldy Hernandez Date: Tue Apr 30 19:39:00 2024 +0200 Reduce startup costs for Value_Range. as the culprit.
[Bug c++/114911] New: Anonymous unions can cause ICE when the name of their type escapes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114911
Bug ID: 114911
Summary: Anonymous unions can cause ICE when the name of their
type escapes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-checking, ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
void g();
template
struct Capture;
template
struct Capture {
friend void g() {
::a;
}
};
struct X;
void f() {
union {
int a = sizeof(Capture);
};
g();
}
```
GCC ICEs with:
```
: In instantiation of 'void g()':
:19:6: required from here
19 | g();
| ~^~
:9:9: internal compiler error: tree check: expected class 'type', have
'declaration' (function_decl) in build_offset_type, at tree.cc:7718
9 | ::a;
| ^
0x267adac internal_error(char const*, ...)
???:0
0x966cd9 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0xd20f91 build_x_unary_op(unsigned int, tree_code, cp_expr, tree_node*, int)
???:0
0xc95413 instantiate_decl(tree_node*, bool, bool)
???:0
0xcbeb3b instantiate_pending_templates(int)
???:0
0xb59819 c_parse_final_cleanups()
???:0
0xdb2668 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libgcc/114907] __trunchfbf2 should be renamed to __extendhfbf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Neither of the modes is a subset or superset of the other, so truncate vs. extend makes no sense. The choice was arbitrary.
[Bug tree-optimization/114908] fails to optimize avx2 in-register permute written with std::experimental::simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908
Andrew Pinski changed:
What|Removed |Added
Component|target |tree-optimization
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-05-01
--- Comment #1 from Andrew Pinski ---
__r = { 0, 0, 0, 0 };
__builtin_memcpy (&__r, , 24);
__r.2_4 = __r;
_5 = VIEW_CONVERT_EXPR<_Rp>(__r.2_4);
That is a fancy way of doing a PERM like:
_5 = VEC_PERM_EXPR <{ 0, 0, 0, 0 }, data_1(D), { 4, 5, 6, 0 }>;
And then it does:
MEM[(struct _Head_base *) +
32B]._M_head_impl._M_data.D.184855._M_data = _5;
MEM [(struct simd *)&__r] = 0;
__builtin_memcpy ( [(void *)&__r + 8B], [(const
struct simd &) + 32]._M_data, 24);
SR.136_19 = MEM[(struct simd *)&__r];
__r ={v} {CLOBBER(eos)};
MEM[(struct simd *)] = SR.136_19;
Which is another fancy way of doing a PERM like:
SR.136_19 = VEC_PERM_EXPR <{ 0, 0, 0, 0 }, _5, { 0, 4, 5, 6 }>;
[Bug target/114908] fails to optimize avx2 in-register permute written with std::experimental::simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug c++/114904] Bogus Warning [-Wreturn-type] in function with do-while loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114904 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Invalid as mentioned by submitter.
[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642 Andrew Pinski changed: What|Removed |Added CC||oleg at smolsky dot net --- Comment #20 from Andrew Pinski --- *** Bug 114909 has been marked as a duplicate of this bug. ***
[Bug c++/114909] False positive diagnostic from -Wdangling-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114909 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=110358 Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- See discussion in PR 110358, PR 114220, PR 110213, and PR 109642 (and more). *** This bug has been marked as a duplicate of bug 109642 ***
[Bug c++/114909] False positive diagnostic from -Wdangling-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114909 --- Comment #2 from Oleg Smolsky --- It seems like an unreasonable stretch to connect a `string` temporary to the returned `Json` reference. The types are not related and so that guess looks overly aggressive... The surgical workaround should work, thanks! I hope it does not generate a Clang warning. Let me check that :)
[Bug target/114910] can't build a c6x cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910 --- Comment #1 from Andrew Pinski --- The only thing hardcfr.c uses special is __builtin_return_address and __builtin_trap otherwise it is just normal C code ...
[Bug libgcc/114907] __trunchfbf2 should be renamed to __extendhfbf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 --- Comment #5 from H.J. Lu --- (In reply to H.J. Lu from comment #4) > (In reply to H.J. Lu from comment #3) > > convert_mode_scalar has > > > > if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode)) > > /* Conversion between decimal float and binary float, same size. */ > > tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab; > > > > Since for HF->BF, DECIMAL_FLOAT_MODE_P (from_mode) is false, tab is > > sext_optab > > and __trunchfbf2 should be renamed to __extendhfbf2. > > Since BFmode range is bigger than HFmode, __trunchfbf2 should be used. Opp, __extendhfbf2 is correct.
[Bug libgcc/114907] __trunchfbf2 should be renamed to __extendhfbf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 --- Comment #4 from H.J. Lu --- (In reply to H.J. Lu from comment #3) > convert_mode_scalar has > > if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode)) > /* Conversion between decimal float and binary float, same size. */ > tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab; > > Since for HF->BF, DECIMAL_FLOAT_MODE_P (from_mode) is false, tab is > sext_optab > and __trunchfbf2 should be renamed to __extendhfbf2. Since BFmode range is bigger than HFmode, __trunchfbf2 should be used.
[Bug c++/114909] False positive diagnostic from -Wdangling-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114909 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- fn1 returns a reference and takes a temporary as an argument; we can't prove that it doesn't return a reference to the temporary, so we warn. Please add [[gnu::no_dangling]] to fn1 to suppress the warning.
[Bug libstdc++/114891] Unconditional use of std::is_pointer_interconvertible_base_of_v in makes the header unusable with Clang 18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.2
[Bug libstdc++/114891] Unconditional use of std::is_pointer_interconvertible_base_of_v in makes the header unusable with Clang 18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891 --- Comment #3 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1fbe1a50d86df11f434351cf62461a32747f9710 commit r15-92-g1fbe1a50d86df11f434351cf62461a32747f9710 Author: Jonathan Wakely Date: Tue Apr 30 09:48:00 2024 +0100 libstdc++: Guard uses of is_pointer_interconvertible_v [PR114891] This type trait isn't supported by Clang 18. It's only used in static assertions, so they can just be omitted if the trait isn't available. libstdc++-v3/ChangeLog: PR libstdc++/114891 * include/std/generator: Check feature test macro before using is_pointer_interconvertible_v.
[Bug target/114910] New: can't build a c6x cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910 Bug ID: 114910 Summary: can't build a c6x cross compiler Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dkm at gcc dot gnu.org Target Milestone: --- Hello, I'm building a c6x cross compiler using crosstool-ng (with newlib). Configured with: configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu --target=tic6x-elf --prefix=/root/crosstool-scratch/tic6x-elf --exec_prefix=/root/crosstool-scratch/tic6x-elf --with-local-prefix=/root/crosstool-scratch/tic6x-elf/tic6x-elf --with-headers=/root/crosstool-scratch/tic6x-elf/tic6x-elf/include --with-newlib --enable-threads=no --disable-shared --with-pkgversion=crosstool-NG 1.26.0.72_810021d --enable-__cxa_atexit --disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp --disable-libquadmath --disable-libquadmath-support --with-gmp=/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/buildtools --with-mpfr=/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/buildtools --with-mpc=/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/buildtools --with-isl=/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/buildtools --enable-lto --enable-target-optspace --disable-nls --enable-multiarch --enable-languages=c,c++ The failing command: /mnt/dkm/git/crosstool-ng/.build/tic6x-elf/build/build-cc-gcc-final/./gcc/xgcc -B/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/build/build-cc-gcc-final/./gcc/ -B/root/crosstool-scratch/tic6x-elf/tic6x-elf/bin/ -B/root/crosstool-scratch/tic6x-elf/tic6x-elf/lib/ -isystem /root/crosstool-scratch/tic6x-elf/tic6x-elf/include -isystem /root/crosstool-scratch/tic6x-elf/tic6x-elf/sys-include-g -O2 -idirafter /root/crosstool-scratch/tic6x-elf/tic6x-elf/include -g -Os -mbig-endian -O2 -g -O2 -idirafter /root/crosstool-scratch/tic6x-elf/tic6x-elf/include -g -Os -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -msdata=none -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -msdata=none -I. -I. -I../../.././gcc -I/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc -I/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/. -I/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/../gcc -I/mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o hardcfr.o -MT hardcfr.o -MD -MP -MF hardcfr.dep -c /mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/hardcfr.c -fvisibility=hidden -DHIDE_EXPORTS -save-temps --verbose-asm hardcfr.s: Assembler messages: hardcfr.s:164: Error: label not at start of execute packet hardcfr.s:335: Error: label not at start of execute packet hardcfr.s:340: Error: label not at start of execute packet hardcfr.s:357: Error: label not at start of execute packet hardcfr.s:381: Error: label not at start of execute packet with corresponding assembly: 161 │ .loc 1 165 3 is_stmt 0 162 │ callp .s2 (consume_seq), B3 ;# 163 │ .LVL9: 164 │ || stw .d1t1 A7, *A4 ;# cfg_it__lsm.31, *cfg_it_8(D) 165 │ ;# /mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/hardcfr.c:167: return true; 166 │ .loc 1 167 9 335 │ || add .l1x12, B15, A4 ;#,, 336 │ ;# /mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/hardcfr.c:287: consume_seq (_it); 337 │ .loc 1 287 4 338 │ callp .s2 (consume_seq), B3 ;# 339 │ .LVL15: 340 │ || add .l1x12, B15, A4 ;#,, 341 │ .L14: 342 │ .LBE66: 343 │ .loc 1 274 35 is_stmt 1 discriminator 2 344 │ .LVL16: 345 │ b .s1 .L12;# 346 │ || add .d1 A10, 1, A10 ;# i,, i 347 │ nop 5 ;# 348 │ ;; jump to .L12 occurs ;# 349 │ .LVL17: 350 │ .L13: 351 │ .LBB67: 352 │ .loc 1 292 4 353 │ ;# /mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/hardcfr.c:292:if (!check_seq (visited, _it)) 354 │ .loc 1 292 9 is_stmt 0 355 │ callp .s2 (check_seq), B3 ;# 356 │ .LVL18: 357 │ || add .l2 12, B15, B4 ;#,, 358 │ || mv .d1 A15, A4 ;# visited, 359 │ ;# /mnt/dkm/git/crosstool-ng/.build/tic6x-elf/src/gcc/libgcc/hardcfr.c:292:if (!check_seq (visited, _it)) 360 │ .loc 1 292 7 discriminator 1 361 │ extu.s1 A4, 24, 24, A0 ;# tmp129, _1 362 │ [A0]b .s1 .L15;# 363 │ nop 5 ;# 364 │ ;; condjump to .L15 occurs ;# 365 │ .LVL19: 366 │ .L16: 367 │ .loc 1 293 6 is_stmt 1 368 │ .LBB64: 369 │ .LBB65: 370 │ .loc 1 262 3 371 │ callp .s2 (abort), B3 ;# 372
[Bug c++/114909] New: False positive diagnostic from -Wdangling-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114909
Bug ID: 114909
Summary: False positive diagnostic from -Wdangling-reference
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oleg at smolsky dot net
Target Milestone: ---
struct string {
string(const char *);
};
struct Json {
int size() const;
};
const Json (const Json , const string );
int Test1(const Json )
{
// warning: possibly dangling reference to a temporary
[-Wdangling-reference]
const Json = fn1(arg, "something");
return jv.size();
}
const Json (const Json );
int Test2(const Json )
{
// all good
const Json = fn2(arg);
return jv.size();
}
[Bug target/114908] New: fails to optimize avx2 in-register permute written with std::experimental::simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908
Bug ID: 114908
Summary: fails to optimize avx2 in-register permute written
with std::experimental::simd
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lee.imple at gmail dot com
Target Milestone: ---
I am trying to write simd code with std::experimental::simd.
Here is the same function written in both std::experimental::simd and GNU
vector extension versions (available online at https://godbolt.org/z/dc169rY3o
).
The purpose is to permute the register from [w, x, y, z] into [0, w, x, y].
```c++
#include
#include
namespace stdx = std::experimental;
using data_t = std::uint64_t;
constexpr std::size_t data_size = 4;
template
using simd_of = std::experimental::simd>;
using simd_t = simd_of;
template
constexpr simd_of zero = {};
// stdx version
simd_t permute_simd(simd_t data) {
auto [carry, _] = split(data);
return concat(zero<1>, carry);
}
typedef data_t vector_t [[gnu::vector_size(data_size * sizeof(data_t))]];
constexpr vector_t zero_v = {0};
// gnu vector extension version
vector_t permute_vector(vector_t data) {
return __builtin_shufflevector(data, zero_v, 4, 0, 1, 2);
}
```
The code is compiled with the options `-O3 -march=x86-64-v3 -std=c++20`.
Although they should have the same functionality, generated assembly (by GCC)
is so different.
```asm
permute_simd(std::experimental::parallelism_v2::simd >):
pushq %rbp
vpxor %xmm1, %xmm1, %xmm1
movq %rsp, %rbp
andq $-32, %rsp
subq $8, %rsp
vmovdqa %ymm0, -120(%rsp)
vmovdqa %ymm1, -56(%rsp)
movq -104(%rsp), %rax
vmovdqa %xmm0, -56(%rsp)
movq -48(%rsp), %rdx
movq $0, -88(%rsp)
movq %rax, -40(%rsp)
movq -56(%rsp), %rax
vmovdqa -56(%rsp), %ymm2
vmovq %rax, %xmm0
vmovdqa %ymm2, -24(%rsp)
movq -8(%rsp), %rax
vpinsrq $1, %rdx, %xmm0, %xmm0
vmovdqu %xmm0, -80(%rsp)
movq %rax, -64(%rsp)
vmovdqa -88(%rsp), %ymm0
leave
ret
permute_vector(unsigned long __vector(4)):
vpxor %xmm1, %xmm1, %xmm1
vpermq $144, %ymm0, %ymm0
vpblendd $3, %ymm1, %ymm0, %ymm0
ret
```
However, Clang can optimize `permute_simd` into the same assembly as
`permute_vector`, so I think, instead of a bug in the std::experimental::simd,
it is a missed optimization in GCC.
```asm
permute_simd(std::experimental::parallelism_v2::simd >): #
@permute_simd(std::experimental::parallelism_v2::simd >)
vpermpd $144, %ymm0, %ymm0 # ymm0 = ymm0[0,0,1,2]
vxorps %xmm1, %xmm1, %xmm1
vblendps$3, %ymm1, %ymm0, %ymm0 # ymm0 =
ymm1[0,1],ymm0[2,3,4,5,6,7]
retq
permute_vector(unsigned long __vector(4)):#
@permute_vector(unsigned long __vector(4))
vpermpd $144, %ymm0, %ymm0 # ymm0 = ymm0[0,0,1,2]
vxorps %xmm1, %xmm1, %xmm1
vblendps$3, %ymm1, %ymm0, %ymm0 # ymm0 =
ymm1[0,1],ymm0[2,3,4,5,6,7]
retq
```
[Bug c++/113706] c-c++-common/pr103798-2.c FAILs as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Jason Merrill --- Should be fixed now.
[Bug c++/113706] c-c++-common/pr103798-2.c FAILs as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706 --- Comment #12 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:c3bc2787b8beb7aae67fdf2a7f7271a9a4edca7c commit r15-91-gc3bc2787b8beb7aae67fdf2a7f7271a9a4edca7c Author: Jason Merrill Date: Mon Feb 12 18:24:00 2024 -0500 c++: const void* memchr [PR113706] The C++ standard specifies that the functions have const and non-const overloads, unlike C's single function with const argument and non-const return. Many systems don't actually implement this, but only add an overload with non-const argument, so both end up having non-const return. Solaris does what the standard says, but we were penalizing it by not recognizing the const overload as the built-in memchr. PR c++/113706 gcc/cp/ChangeLog: * decl.cc (decls_match): Handle memchr return type being const-qualified. gcc/testsuite/ChangeLog: * g++.dg/opt/const-builtin1.C: New test. * c-c++-common/pr103798-2.c: Remove xfail.
[Bug libgcc/114907] __trunchfbf2 should be renamed to __extendhfbf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 H.J. Lu changed: What|Removed |Added Summary|Missing __extendhfbf2 in|__trunchfbf2 should be |libgcc |renamed to __extendhfbf2 --- Comment #3 from H.J. Lu --- convert_mode_scalar has if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode)) /* Conversion between decimal float and binary float, same size. */ tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab; Since for HF->BF, DECIMAL_FLOAT_MODE_P (from_mode) is false, tab is sext_optab and __trunchfbf2 should be renamed to __extendhfbf2.
[Bug c++/88323] implement C++20 language features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323 --- Comment #3 from Jason Merrill --- I think the goal should be to declare C++20 support no longer experimental in GCC 15, but I probably wouldn't change the default dialect just yet.
[Bug libgcc/114907] Missing __extendhfbf2 in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907
--- Comment #2 from H.J. Lu ---
[hjl@gnu-cfl-3 pr114907]$ cat foo.c
__bf16
foo (_Float16 x)
{
return x;
}
[hjl@gnu-cfl-3 pr114907]$ make CC=gcc
gcc -O2 -S foo.c
[hjl@gnu-cfl-3 pr114907]$ cat foo.s
.file "foo.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
call__extendhfbf2
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.globl __extendhfbf2
.ident "GCC: (GNU) 14.0.1 20240411 (Red Hat 14.0.1-0)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-3 pr114907]$
[Bug libgcc/114907] Missing __extendhfbf2 in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-05-01 Status|UNCONFIRMED |NEW
[Bug libgcc/114907] Missing __extendhfbf2 in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 --- Comment #1 from H.J. Lu --- There is __trunchfbf2. Why does GCC generate __extendhfbf2?
[Bug target/69374] install.texi is bit-rotten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374 --- Comment #9 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:0695aba3e987f4bb06c95f29ff90a8a3234e1507 commit r15-90-g0695aba3e987f4bb06c95f29ff90a8a3234e1507 Author: Gerald Pfeifer Date: Wed May 1 16:23:08 2024 +0200 doc: FreeBSD no longer has a GNU toolchain in base gcc: PR target/69374 PR target/112959 * doc/install.texi (Specific) <*-*-freebsd*>: No longer refer to GCC or binutils in base. Recommend bootstrap using binutils.
[Bug target/112959] install.tex needs updates on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959 --- Comment #3 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:0695aba3e987f4bb06c95f29ff90a8a3234e1507 commit r15-90-g0695aba3e987f4bb06c95f29ff90a8a3234e1507 Author: Gerald Pfeifer Date: Wed May 1 16:23:08 2024 +0200 doc: FreeBSD no longer has a GNU toolchain in base gcc: PR target/69374 PR target/112959 * doc/install.texi (Specific) <*-*-freebsd*>: No longer refer to GCC or binutils in base. Recommend bootstrap using binutils.
[Bug c++/114904] Bogus Warning [-Wreturn-type] in function with do-while loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114904 --- Comment #1 from Albi --- This "bug" can be closed and deleted. I am an idiot and i am sorry. 'continue' does not jump to the start of the loop, but to the next loop-condition-check, so in a do-while loop, it actually jumps to the bottom. Man, after 20 years of c++ !!!
[Bug libgcc/114907] New: Missing __extendhfbf2 in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907
Bug ID: 114907
Summary: Missing __extendhfbf2 in libgcc
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
Target Milestone: ---
Target: x86-64
>From https://sourceware.org/bugzilla/show_bug.cgi?id=31685
$ cat x.cc
#include
#include
#include
#include
#define SIZE 8
typedef _Float16 T;
//typedef volatile float T;
void fp16tobf16(_Float16 * f) {
__bf16 * b = reinterpret_cast<__bf16*>(f);
for(int i=0; i a{};
std::fill(a.begin(), a.end(), (_Float16) 1.7653432432424324);
fp16tobf16(a.data());
__bf16 * b = reinterpret_cast<__bf16*>(a.data());
std::cout << "\n";
for(int i=0; i
[Bug ada/112958] [12/13/14/15 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 --- Comment #6 from Gerald Pfeifer --- FreeBSD i386 is on it's way out: FreeBSD 14 is the last series supporting it; FreeBSD 15 is dropping support for it. Can we disable libgnat (or GNAT) support during configure time?
[Bug target/114906] New: aarch64 locally_streaming ICE in aarch64_expand_prologue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114906
Bug ID: 114906
Summary: aarch64 locally_streaming ICE in
aarch64_expand_prologue
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
Bug (testcase + ICE) below.
I believe this is because:
1) We save `r20` below `VG_REGNUM` in `aarch64_layout_frame` (and above the
point that `bytes_below_hard_fp` describes).
2) Despite that save of `r20` causing us to also set
`frame.wb_push_candidate1`, because we have a poly-int sized frame (due to the
-O0 in this case, but I don't think has to be -O0) we still end up in the
"General case" in `aarch64_layout_frame`.
3) Hence we end up with `initial_adjust` non zero, `sve_callee_adjust`
non-zero, and the `VG_REGNUM` not pointing to the same place as
`bytes_below_hard_fp` because there is that r20 saved in between.
My initial guess would be that we should simply change the assertion that
failed to check that VG_REGNUM is *greater than or equal to* `bytes_below_sp`.
To be honest I'm not entirely sure what this assertion is there for so would
not like to actually make that suggestion. The commit message of ad4df8cd080c
seems to say the assertion is there to ensure that the allocation of VG_REGNUM
is not folded into the initial_allocation, but I don't 100% follow what's going
on.
vshcmd: > cat ../streaming-prologues.c
[[arm::locally_streaming]] void
with_callee_saved_regs (__SVBool_t x)
{
asm ("" : : : "r20");
}
testing [14:47:20] $
vshcmd: > ${install_dir}/aarch64-none-linux-gnu-gcc \
vshcmd: > ../streaming-prologues.c \
vshcmd: > -fdiagnostics-plain-output -O0 -fstack-clash-protection \
vshcmd: > -march=armv9-a+sme -mtune=generic -moverride=tune=none \
vshcmd: > -S -o prologues-with-streaming-1.s
> > > > during RTL pass: late_pro_and_epilogue
> > > >
> > > >
> > > >
> > > >
../streaming-prologues.c: In function ‘with_callee_saved_regs’:
../streaming-prologues.c:5:1: internal compiler error: in
aarch64_expand_prologue, at config/aarch64/aarch64.cc:9705
0x142e3af aarch64_expand_prologue()
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/config/aarch64/aarch64.cc:9701
0x1a7eee7 gen_prologue()
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/config/aarch64/aarch64.md:1008
0x140219f target_gen_prologue
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/config/aarch64/aarch64.md:8121
0xb8d242 make_prologue_seq
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/function.cc:5818
0xb8d3aa thread_prologue_and_epilogue_insns()
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/function.cc:6053
0xb8dc4e rest_of_handle_thread_prologue_and_epilogue
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/function.cc:6567
0xb8dcbf execute
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/function.cc:6692
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/114324] [13/14/15 Regression] AVX2 vectorisation performance regression with gfortran 13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114324 --- Comment #5 from mjr19 at cam dot ac.uk --- Note that bug 114767 also turns out to be a case in which the inability to alternate neg and nop along a vector leads to poor performance with some operations on the complex type. That optimisation improvement request also discusses that the ability to alternate add and nop could be beneficial. Ifort can alternate neg and nop, at least in the simple case of complex(kind(1d0)) :: c(*) do i=1,n c(i)=conjg(c(i)) enddo Helped by aggressive default unrolling, it ends up being almost four times faster than gfortran-14 on the machine I tested it on. On asking gfortran-14 to unroll, the difference is reduced to about a factor of two.
[Bug target/101345] wrong code at -O1 with vector modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101345
--- Comment #3 from Jeevitha ---
> Jeevitha, can you please do a git bisect from the two commits above to
> identify the commit that fixes this for posterity sake? Thanks.
The commit that resolved the incorrect code was
ad5f8ac1d2f2dc92d43663243b52f9e9eb3cf7c0, where Bill disabled the swap for mult
with subreg. This addressed the issue.
The reason behind this change is as follows:
The input for the swap pass is,
insn 23 set r144, vec_concat(r152,r160)
insn 26 set r162, r237*(r144+0)
insn 27 set r163, (r144+8)*r236
insn 29 set r166, r236*(r144+0)
insn 30 set r167, subreg(r236*(r144+0),8)
Output from swap pass is,
insn 23 set r144, vec_concat(r160,r152)
insn 26 set r162, r237*(r144+8)
insn 27 set r163, (r144+0)*r236
insn 29 set r166, r236*(r144+8)
insn 30 set r167, subreg(r236*(r144+8),0)
In the provided sample code, multiplication operations are performed. Here, the
SUBREG_BYTE changes in pseudo 144 are correct. However, the change from 8 to 0
in the SUBREG_BYTE of MULT(r236,r144) is incorrect. This alteration leads to
treating it as a low-part multiply ie, similar to insn 29, whereas it should
actually a high-part multiply. Therefore, Bill stopped the swap for mult with
subreg case, which resolves this issue.
To provide clear reference, here is the RTL for insn 30 in failure case:
(insn 30 29 31 2 (set (reg:DI 167)
(subreg:DI (mult:TI (zero_extend:TI (reg:DI 236))
- (zero_extend:TI (subreg:DI (reg:V2DI 144) 0))) 8))
"test1.c":13:5 166 {umuldi3_highpart_le} //input from swap pass
+ (zero_extend:TI (subreg:DI (reg:V2DI 144) 8))) 0))
"test1.c":13:5 166
{umuldi3_highpart_le} //output from swap pass
[Bug target/114905] New: aarch64 locally_streaming function ICE in dwarf2cfi due to mismatched CFA instructions in prologue/epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114905
Bug ID: 114905
Summary: aarch64 locally_streaming function ICE in dwarf2cfi
due to mismatched CFA instructions in
prologue/epilogue
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
Bug observed (testcase + ICE) is below. I believe this happens because we use
`aarch64_add_sp` to adjust the stack pointer when `maybe_ne (sve_callee_saves,
0)` in `aarch64_expand_epilogue`. This marks the adjustment as adjusting the
CFA. However in `aarch64_expand_prologue` we might have set the CFA to the
frame pointer (instead of the stack pointer) if `frame_pointer_needed &&
frame_size.is_constant()`.
Hence when both these conditions are held we have a CFA adjust note that
affects a different register to the current CFA register.
vshcmd: > cat streaming-prologues.c
[[arm::locally_streaming,arm::streaming_compatible]] void
no_gprs_saved_very_streaming (__SVBool_t x)
{
asm ("");
}
gnu-work [13:47:36] $
vshcmd: > ${install_dir}/aarch64-none-linux-gnu-gcc \
vshcmd: > streaming-prologues.c \
vshcmd: > -fdiagnostics-plain-output -O -fomit-frame-pointer
-fstack-clash-protection\
vshcmd: > -march=armv9-a+sme -mtune=generic -moverride=tune=none \
vshcmd: > -fdump-rtl-all-all \
vshcmd: > -S -o locally_streaming_1_scp.s
gnu-work [13:47:38] $ > > > > > during RTL pass: dwarf2
dump file: locally_streaming_1_scp.c.356r.dwarf2
streaming-prologues.c: In function ‘no_gprs_saved_very_streaming’:
streaming-prologues.c:5:1: internal compiler error: in
dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.cc:1339
0xa540bd dwarf2out_frame_debug_adjust_cfa
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/dwarf2cfi.cc:1339
0xa540bd dwarf2out_frame_debug
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/dwarf2cfi.cc:2277
0xa540bd scan_insn_after
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/dwarf2cfi.cc:2726
0xa557e0 scan_trace
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/dwarf2cfi.cc:2893
0xa562cf create_cfi_notes
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/dwarf2cfi.cc:2938
0xa562cf execute_dwarf2_frame
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/dwarf2cfi.cc:3309
0xa562cf execute
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/dwarf2cfi.cc:3797
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/114904] New: Bogus Warning [-Wreturn-type] in function with do-while loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114904
Bug ID: 114904
Summary: Bogus Warning [-Wreturn-type] in function with
do-while loop
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: albrecht.guendel at web dot de
Target Milestone: ---
Hi,
from GCC 8.1 onwards using >=C++14, i get hit with
> warning: control reaches end of non-void function [-Wreturn-type]
in the following code:
auto test()
{
do
{
volatile int a = 0;
if (a)
continue;
return 1;
} while(0);
}
or use https://godbolt.org/z/PxE95vqe6
This code uses a do-while construct to conditionally repeat code above the
continue-statement, but always returns within the loop.
The bogus warning occurs as soon as loop-control-flow is added. However the
'continue' would never leave the loop.
The warning can be fixed with __builtin_unreachable(); below the while(0). or
by using goto instead of loop control-flow. However this should not be
necessary.
Clang shows the same behavior.
[Bug c++/88323] implement C++20 language features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323 --- Comment #2 from Jonathan Wakely --- Only after the atomic wait/notify refactoring patches have landed.
[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE --- "dmalcolm at gcc dot gnu.org" writes: > --- Comment #11 from David Malcolm --- > Thanks. I've been working on this on cfarm216; I have a messy set of patches > with this improvement to g++.sum with analyzer.exp so far: > > # of expected passes 11395 -> 12015 > # of unexpected failures 684 ->64 > # of unexpected successes 4 -> 0 > # of expected failures 443 -> 447 > # of unsupported tests50 > > However I'm don't have access to my regular workstation/testing box until late > tomorrow, so I'm holding off on posting until I've cleaned them up and put > them > through my usual testing regime. That's excellent news, thanks for the update.
[Bug c++/88323] implement C++20 language features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #1 from Romain Geissler --- Hi, With C++20 core feature being almost fully implemented (besides modules, but it seems modules are quite a beast and other compilers seem to also partially implement it for now), and with C++20 library feature also in a very advanced state (Jon even marked #88322 as implemented, though some bug/improvement tickets have been opened afterwards), and considering that gcc 15 will be released in 2025 leaving one year to polish the last C++20 issues, would it make sense to switch the default C++ dialect to C++20 for GCC 15 ?
DeepLearn 2024: early registration May 8
*To be removed from our mailing list, please respond to this message with UNSUBSCRIBE in the subject line* -- ** 11th INTERNATIONAL SCHOOL ON DEEP LEARNING (and the Future of Artificial Intelligence) DeepLearn 2024 Porto – Maia, Portugal July 15-19, 2024 https://deeplearn.irdta.eu/2024/ ** Co-organized by: University of Maia Institute for Research Development, Training and Advice – IRDTA Brussels/London ** Early registration: May 8, 2024 ** SCOPE: DeepLearn 2024 will be a research training event with a global scope aiming at updating participants on the most recent advances in the critical and fast developing area of deep learning. Previous events were held in Bilbao, Genova, Warsaw, Las Palmas de Gran Canaria, Guimarães, Las Palmas de Gran Canaria, Luleå, Bournemouth, Bari and Las Palmas de Gran Canaria. Deep learning is a branch of artificial intelligence covering a spectrum of current frontier research and industrial innovation that provides more efficient algorithms to deal with large-scale data in a huge variety of environments: computer vision, neurosciences, speech recognition, language processing, human-computer interaction, drug discovery, health informatics, medical image analysis, recommender systems, advertising, fraud detection, robotics, games, finance, biotechnology, physics experiments, biometrics, communications, climate sciences, geographic information systems, signal processing, genomics, materials design, video technology, social systems, etc. etc. The field is also raising a number of relevant questions about robustness of the algorithms, explainability, transparency, and important ethical concerns at the frontier of current knowledge that deserve careful multidisciplinary discussion. Most deep learning subareas will be displayed, and main challenges identified through 16 four-hour and a half courses, 2 keynote lectures, 1 round table and a few hackathon-type competitions among students, which will tackle the most active and promising topics. Renowned academics and industry pioneers will lecture and share their views with the audience. The organizers are convinced that outstanding speakers will attract the brightest and most motivated students. Face to face interaction and networking will be main ingredients of the event. It will be also possible to fully participate in vivo remotely. ADDRESSED TO: Graduate students, postgraduate students and industry practitioners will be typical profiles of participants. However, there are no formal pre-requisites for attendance in terms of academic degrees, so people less or more advanced in their career will be welcome as well. Since there will be a variety of levels, specific knowledge background may be assumed for some of the courses. Overall, DeepLearn 2024 is addressed to students, researchers and practitioners who want to keep themselves updated about recent developments and future trends. All will surely find it fruitful to listen to and discuss with major researchers, industry leaders and innovators. VENUE: DeepLearn 2024 will take place in Porto, the second largest city in Portugal, recognized by UNESCO in 1996 as a World Heritage Site. The venue will be: University of Maia Avenida Carlos de Oliveira Campos - Castlo da Maia 4475-690 Maia Porto, Portugal https://www.umaia.pt/en STRUCTURE: 3 courses will run in parallel during the whole event. Participants will be able to freely choose the courses they wish to attend as well as to move from one to another. All lectures will be videorecorded. Participants will be able to watch them again for 45 days after the event. An open session will give participants the opportunity to present their own work in progress in 5 minutes. Also companies will be able to present their technical developments for 10 minutes. This year’s edition of the school will schedule hands-on activities including mini-hackathons, where participants will work in teams to tackle several machine learning challenges. Full live online participation will be possible. The organizers highlight, however, the importance of face to face interaction and networking in this kind of research training event. KEYNOTE SPEAKERS: Jiawei Han (University of Illinois Urbana-Champaign), How Can Large Language Models Contribute to Effective Text Mining? Katia Sycara (Carnegie Mellon University), Effective Multi Agent Teaming PROFESSORS AND COURSES: Luca Benini (Swiss Federal Institute of Technology Zurich), [intermediate/advanced] Open Hardware Platforms for Edge Machine Learning Gustau Camps-Valls (University of València), [intermediate] AI for Earth, Climate, and Sustainability Nitesh Chawla (University of Notre Dame), [introductory/intermediate]
[Bug target/69374] install.texi is bit-rotten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374 --- Comment #8 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:81f7965e63028c1289ae3b1836750da74b01bc4a commit r15-89-g81f7965e63028c1289ae3b1836750da74b01bc4a Author: Gerald Pfeifer Date: Wed May 1 11:18:19 2024 +0200 doc: Remove old details on libunwind for ia64-*-hpux* gcc: PR target/69374 * doc/install.texi (Specific) : Remove details on libunwind for GCC 3.4 and earlier.
[Bug c++/114903] New: constraint of CTAD alias deduction guide is evaluated on a wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114903
Bug ID: 114903
Summary: constraint of CTAD alias deduction guide is evaluated
on a wrong type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hokein.wu at gmail dot com
Target Milestone: ---
See the following example of nested templates:
```
#include
template
struct Key {
Key(int);
};
class Forward {};
template
constexpr bool C =
std::is_same(); // changing `Forward` to `double` will make the
following static_assert passed.
template
struct Outer {
template
struct Foo {
Foo(U);
U u;
};
template
requires(C)
Foo(V) -> Foo;
};
template
struct T {
template
struct T2 {
template
using AFoo = Outer::template Foo;
};
};
T::T2::AFoo a{1.0}; // the explict deduction guide should be
choosen, Foo
static_assert(std::is_same::Foo>()); // expect
to be true!
```
The constraint `C` in the alias deduction guide should be true, as it is
evaluated on type `Forward`, but gcc seems to evaluate it on `double`.
[Bug c++/114868] [modules] func declared in GMF and exported via using-decl in module partition is not actually exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114868
Nathaniel Shead changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot
gnu.org
CC||nshead at gcc dot gnu.org
Target Milestone|--- |14.2
Last reconfirmed||2024-05-01
Status|UNCONFIRMED |ASSIGNED
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=114683
--- Comment #2 from Nathaniel Shead ---
Fixed for GCC 15 so far. Non-functions don't always work, which is largely
tracked in PR c++/114683. We also might not correctly differentiate unscoped
enums from using enum declarations for this purpose, but it's hard to tell
before PR114683 is fixed.
For instance:
// using_enum_a.cpp
module;
namespace foo {
enum class a { x, y, z };
}
export module M:a;
namespace bar {
export using enum foo::a;
}
// using_enum_b.cpp
export module M;
export import :a;
// using_enum_c.cpp
import M;
int main() {
auto x = bar::x;
}
[Bug c++/114868] [modules] func declared in GMF and exported via using-decl in module partition is not actually exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114868 --- Comment #1 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:0d0215b10dbbe39d655ceda4af283f288ec7680c commit r15-85-g0d0215b10dbbe39d655ceda4af283f288ec7680c Author: Nathaniel Shead Date: Tue Apr 9 21:49:58 2024 +1000 c++: Propagate using decls from partitions [PR114868] The modules code currently neglects to set OVL_USING_P on the dependency created for a using-decl, which causes it not to remember that the OVL_EXPORT_P flag had been set on it when emitted from the primary interface unit. This patch ensures that it occurs. PR c++/114868 gcc/cp/ChangeLog: * module.cc (depset::hash::add_binding_entity): Propagate OVL_USING_P for using-declarations. gcc/testsuite/ChangeLog: * g++.dg/modules/using-15_a.C: New test. * g++.dg/modules/using-15_b.C: New test. * g++.dg/modules/using-15_c.C: New test. Signed-off-by: Nathaniel Shead
[Bug target/114860] [14/15 regression] [aarch64] 511.povray regresses by ~5.5% with -O3 -flto -march=native -mcpu=neoverse-v2 since r14-10014-ga2f4be3dae04fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114860 --- Comment #3 from Tamar Christina --- I cannot reproduce this even recompiling libc.
