[Bug tree-optimization/116768] [12/13/14/15 regression] Strict aliasing breaks autovectorization with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116768
--- Comment #3 from Andrew Pinski ---
Here is a testcase which does NOT need -mavx to fail and fails on aarch64 too:
```
#define numwords 2
typedef struct {
unsigned words[numwords];
} Child;
typedef struct {
Child child;
} Parent;
Parent my_or(Parent x, const Parent *y) {
const Child *y_child = &y->child;
for (int i = 0; i < numwords; i++) {
x.child.words[i] |= y_child->words[i];
}
return x;
}
int main() {
Parent bs[4];
__builtin_memset(bs, 0, sizeof(bs));
bs[0].child.words[0] = 1;
for (int i = 1; i <= 3; i++) {
bs[i] = my_or(bs[i], &bs[i - 1]);
}
return bs[2].child.words[0];
}
```
[Bug tree-optimization/116768] [12/13/14/15 regression] Strict aliasing breaks autovectorization with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116768 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-09-18 Known to fail||12.1.0 Known to work||11.4.0 Keywords||needs-bisection Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |12.5 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/116770] Diagnostic 'explicit qualification in declaration of' could be clearer when explicit namespace qualifier matches the open namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116770 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=64267 --- Comment #4 from Andrew Pinski --- (In reply to Marek Polacek from comment #3) > (In reply to Andrew Pinski from comment #2) > > DR482 > > We have bug 64267 for that. Right I was just looking that up :).
[Bug c++/116769] Instantiation of defaulted default constructor with non default constructible NDSMIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116769 --- Comment #1 from Andrew Pinski --- MSVC (and EDG) return true for is_default_constructible_v> . Which is different from clang. So in summary we have the following 3 behaviors: * accepts the code and is_default_constructible_v> value is true: EDG/MSVC * accepts the code and is_default_constructible_v> value is false: GCC * rejects the code due to the default constructor being invalid.
[Bug c/116767] C const function pointer no code generated (or optimized out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116767 --- Comment #8 from Andreas Schwab --- That feature probably existed since the beginning, as a comment the glibc sources from 1994 in misc/sys/cdefs.h suggests. /* In GCC versions before 2.5, the `volatile' and `const' keywords have special meanings when applied to functions. In versions 2.5 and 2.6, the `__attribute__' syntax used below does not work properly. */
[Bug c++/116769] Instantiation of defaulted default constructor with non default constructible NDSMIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116769
--- Comment #4 from Giuseppe D'Angelo ---
Hi, thanks for investigating.
That divergence is a bit worrying, I can't quite understand what's going on.
Also, all compilers seem to accept this variation, which one would naively
assume "equivalent" to the previous testcase:
struct NDC { NDC(int); };
template
struct Wrap
{
Wrap() : t() {}
Wrap(const T &t) : t(t) {}
T t;
};
static_assert(std::is_default_constructible_v>);
[Bug middle-end/44032] internals documentation is not legally safe to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44032 --- Comment #12 from Eric Gallager --- I'm hearing this came up at Cauldron this year... I wasn't there, so could somebody who was summarize in this bug report for us?
[Bug libstdc++/116755] format and print functions prepend extra minus sign for min value of chrono duration type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116755 --- Comment #12 from Jonathan Wakely --- And I'm not saying *you* should use unsigned types, I'm saying std::format should cast it to unsigned.
[Bug libstdc++/116754] libstdc++ std::ranges::copy performance issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116754 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-09-18 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |13.4 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug middle-end/116772] [15 regression] SIGFPE (branch optimised out) in eigen-3.4.0 testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116772 --- Comment #5 from Andrew Pinski --- The easiest fix is to add: && !generic_expr_could_trap_p (@3) There but I am not sure if that will always work even though generic_expr_could_trap_p is recusive.
[Bug tree-optimization/116773] New: [meta-bug] TSVC missed optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116773 Bug ID: 116773 Summary: [meta-bug] TSVC missed optimizations Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: meta-bug, missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Just a meta bug recording all of the TSVC related missed optimizations in one place.
[Bug tree-optimization/116766] Missed loop vectorization case with gather/scatter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116766 --- Comment #1 from Andrew Pinski --- I thought I had saw this one before ...
[Bug middle-end/116772] [15 regression] SIGFPE (branch optimised out) in eigen-3.4.0 testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116772 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Andrew Pinski --- It is this pattern: a != 0 ? a * b : 0 -> a * b as we don't check if b could trap. match and generic and cond_expr don't always get along it seems.
[Bug middle-end/116772] [15 regression] SIGFPE (branch optimised out) in eigen-3.4.0 testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116772 --- Comment #4 from Andrew Pinski --- if (TREE_SIDE_EFFECTS (_p0)) goto next_after_fail964; if (TREE_SIDE_EFFECTS (_p1)) goto next_after_fail964; if (TREE_SIDE_EFFECTS (_p2)) goto next_after_fail964; We check for SIDE_EFFECTS so that works correctly but trap is counted as a side effect here. Double blah.
[Bug middle-end/116772] [15 regression] SIGFPE (branch optimised out) in eigen-3.4.0 testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116772 --- Comment #6 from Andrew Pinski --- Created attachment 59143 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59143&action=edit Better reduced testcase Here is a better reduced testcase. The problem only shows up with these 2 patterns because in: a != 0 ? a * b : 0 a != 0 ? a & b : 0 b is only conditionaly used.
[Bug middle-end/116772] [15 regression] SIGFPE (branch optimised out) in eigen-3.4.0 testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116772 --- Comment #7 from Andrew Pinski --- I am wondering if genmatch should generate the call to generic_expr_could_trap_p rather than adding it to the pattern because there could be more issues like this learking around.
[Bug tree-optimization/116352] [15 regression] ICE when building opencv-4.9.0 (error: definition in block 208 does not dominate use in block 188) since r15-2820-gab18785840d7b8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116352 --- Comment #15 from Sam James --- Note that the original still fails on trunk.
[Bug libstdc++/51452] [DR 2116] is_nothrow_.*constructible bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452 --- Comment #21 from Marek Polacek --- Sigh, the DR 2116 in the title confused me...
[Bug libstdc++/116755] format and print functions prepend extra minus sign for min value of chrono duration type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116755
--- Comment #11 from Jonathan Wakely ---
(In reply to Zartaj Majeed from comment #9)
> Won't I have to separately add units to +d2.count()?
No, I'm saying that the operator<< for duration should use +d.count() instead
of d.count(), because that promotes signed char to int.
> I didn't think to try unsigned types because I'm working with system_clock
> that I believe requires signed Rep - but the following doesn't compile for me
>
> auto d3 = duration_cast>>(d1);
> println("d3 duration_cast unsigned value {}", d3);
>
> test.cpp:14:10: required from here
>14 | println("d3 duration_cast unsigned value {}", d3);
> | ~~~^~
> /usr/include/c++/14/bits/chrono_io.h:1610:44: error: no matching function
> for call to ‘abs(const std::chrono::duration&)’
> 1610 | return _M_f._M_format(chrono::abs(__d), __fc, __d <
> __d.zero());
> | ~~~^
That was Bug 115668 and is already fixed. You're using a very outdated
development snapshot: 14.0.1 20240412
Please upgrade your compiler.
[Bug c++/116741] ICE with invalid cast from void* in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116741 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- I suppose I shouldn't backport error-recovery fixes. Closing.
[Bug c++/116770] Diagnostic 'explicit qualification in declaration of' could be clearer when explicit namespace qualifier matches the open namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116770 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2024-09-18 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- EDG accepts it without any diagnostic.
[Bug tree-optimization/116768] [12/13/14/15 regression] Strict aliasing breaks autovectorization with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116768 --- Comment #5 from Andrew Pinski --- (In reply to Alisa Sireneva from comment #4) > With the new reproducer, this doesn't work on 11.4 Oh right I must have missed that when I moved over to the new testcase.
[Bug c++/116771] New: Missing suggestion on mispelled class name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116771
Bug ID: 116771
Summary: Missing suggestion on mispelled class name
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: easyhack
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
I made this typo in C++:
class layout_printer
{
void print_newline ();
};
void
layout_pirnter::print_newline ()
{
}
and noticed that we don't yet issue a suggestion for the missppelled class
name:
:7:1: error: 'layout_pirnter' has not been declared
7 | layout_pirnter::print_newline ()
| ^~
Compiler returned: 1
whereas clang does:
:7:1: error: use of undeclared identifier 'layout_pirnter'; did you
mean 'layout_printer'?
7 | layout_pirnter::print_newline ()
| ^~
| layout_printer
:1:7: note: 'layout_printer' declared here
1 | class layout_printer
| ^
:7:1: error: use of undeclared identifier 'layout_pirnter'; did you
mean 'layout_printer'?
7 | layout_pirnter::print_newline ()
| ^~
| layout_printer
:1:7: note: 'layout_printer' declared here
1 | class layout_printer
| ^
2 errors generated.
Compiler returned: 1
See https://godbolt.org/z/q968ePqq9
I'm not sure why clang emits two errors, but that's for them to fix.
In the meantime, we should provide a suggestion for the misspelling.
[Bug c++/116771] Missing suggestion on mispelled class name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116771 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-09-18 Severity|normal |enhancement Keywords||diagnostic Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/116770] New: Diagnostic 'explicit qualification in declaration of' could be clearer when explicit namespace qualifier matches the open namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116770
Bug ID: 116770
Summary: Diagnostic 'explicit qualification in declaration of'
could be clearer when explicit namespace qualifier
matches the open namespace
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cjdb.ns at gmail dot com
Target Milestone: ---
```
namespace foo {
void f();
}
namespace foo {
void foo::f() {}
}
```
gives this diagnostic
```
error: explicit qualification in declaration of 'void foo::f()'
6 | void foo::f() {}
|^~~
```
While technically accurate, the diagnostic could go a bit further and diagnose
that the author might have meant to define `foo::f`. Would it be possible to
add a note please?
```
error: explicit qualification in declaration of 'void foo::f()'
6 | void foo::f() {}
|^~~
note: this 'void foo::f()` was found inside a 'namespace foo' block; did you
mean 'void f()`?
```
Alternatively, Clang diagnoses this as a warning instead of an error; perhaps
GCC could match this, either in text or in functionality.
```
warning: extra qualification on member 'f' [-Wextra-qualification]
6 | void foo::f() {}
| ^
```
[Bug tree-optimization/116768] [12/13/14/15 regression] Strict aliasing breaks autovectorization with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116768 --- Comment #1 from Andrew Pinski --- -fno-vect-cost-model hides it
[Bug c/116767] C const function pointer no code generated (or optimized out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116767 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Andrew Pinski --- And with -pedantic-errors we get: ``` :6:21: error: ISO C forbids qualified function types [-Wpedantic] 6 | static const MyFunc my_func; | ^~~ ``` So there is nothing to fix here. As the extension is very well documented (though only again since GCC 14 due to it being mistakely removed, see PR 107942 for details on that one) and this extension has existed since at least 2.95.3 (most likely earlier before attributes were around).
[Bug c++/102051] [coroutines] ICE in gimplify_var_or_parm_decl, at gimplify.c:2848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102051 Torben Hohn changed: What|Removed |Added CC||torbenh at gmx dot de --- Comment #10 from Torben Hohn --- Created attachment 59140 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59140&action=edit backport to 14.2 I think i backported the fix to gcc-14.2 Please review thoroughly, as i dont exactly know much about gcc. This is my second time in 10 years of looking a bit into it. With this patch applied i could compile capnproto and the tests ran through.
[Bug c++/116772] New: [15 regression] SIGFPE (branch optimised out) in eigen-3.4.0 testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116772
Bug ID: 116772
Summary: [15 regression] SIGFPE (branch optimised out) in
eigen-3.4.0 testsuite
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Forwarding a report from Paul Zander in Gentoo:
"""
While running the eigen-3.4.0 test suite in gentoo, a few tests fail with
"signal SIGFPE, Arithmetic exception" under gcc-15.
> Program received signal SIGFPE, Arithmetic exception.
> 0x9dda in Eigen::internal::gemm_pack_lhs Eigen::internal::const_blas_data_mapper, 4, 2, double
> __vector(4), 0, false, false>::operator()(double*,
> Eigen::internal::const_blas_data_mapper const&, long, long,
> long, long) (blockA=blockA@entry=0x7fffcb40, lhs=...,
> depth=depth@entry=3,
> rows=rows@entry=3, stride=stride@entry=0, offset=offset@entry=0,
> this=) at
> /var/tmp/paludis/dev-cpp-eigen-3.4.0-r3/work/eigen-3.4.0/Eigen/src/Core/products/GeneralBlockPanelKernel.h:2121
> 2121 const Index peeled_mc0 = Pack2>=PacketSize ? peeled_mc_quarter
> (gdb) x/i $pc
> => 0x9dda
> <_ZN5Eigen8internal13gemm_pack_lhsIdlNS0_22const_blas_data_mapperIdlLi0EEELi4ELi2EDv4_dLi0ELb0ELb0EEclEPdRKS3_+154>:
> idiv %r13
The failure occurs in
> const Index peeled_mc0 = Pack2>=PacketSize ? peeled_mc_quarter
>: Pack2>1 && last_lhs_progress ?
> (rows/last_lhs_progress)*last_lhs_progress : 0;
https://gitlab.com/libeigen/eigen/-/blob/3.4/Eigen/src/Core/products/GeneralBlockPanelKernel.h?ref_type=heads#L2121-2122
A simple reproducer is https://godbolt.org/z/a5hzzK377
> #include
> template
> Index round(Index a,Index b){
> return b!=0 ? a/b*b :0;
> }
>
> int main() {
> std::cout << round(3L, 1L) << '\n';
> std::cout << round(3L, 0L) << '\n';
> return 0;
> }
Looking at assembler code gcc-15 reduces the ternary operation to "a/b*b",
which then fails for b == 0.
"""
[Bug c++/116772] [15 regression] SIGFPE (branch optimised out) in eigen-3.4.0 testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116772 --- Comment #1 from Sam James --- Created attachment 59142 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59142&action=edit test.cxx
[Bug middle-end/116772] [15 regression] SIGFPE (branch optimised out) in eigen-3.4.0 testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116772 Marek Polacek changed: What|Removed |Added Last reconfirmed||2024-09-18 Target Milestone|--- |15.0 Priority|P3 |P1 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org, ||pinskia at gcc dot gnu.org Component|c++ |middle-end Status|UNCONFIRMED |NEW --- Comment #2 from Marek Polacek --- Started with r15-307: commit e472527c7b45d23e8dfd0fb767a6e663b4bc136e Author: Andrew Pinski Date: Tue Apr 30 14:45:26 2024 -0700 MATCH: Add some more value_replacement simplifications (a != 0 ? expr : 0) to match
[Bug middle-end/44032] internals documentation is not legally safe to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44032 --- Comment #13 from Sam James --- (In reply to Eric Gallager from comment #12) It didn't this year. It was just a possible topic but we went in another direction.
[Bug libstdc++/51452] [DR 2116] is_nothrow_.*constructible bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452 Marek Polacek changed: What|Removed |Added Status|SUSPENDED |NEW CC||mpolacek at gcc dot gnu.org --- Comment #19 from Marek Polacek --- Unsuspending; DR 2116 is C++17.
[Bug middle-end/116753] [13/14/15 Regression] GCC trunk (-O3) can't fold a loop into a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116753
--- Comment #3 from dcci ---
Slightly easier example that still fails (no nested loop):
```
long patatino() {
long x = 0;
while (x < 10) {
if (x % 2 == 0) {
x += 2;
} else {
x += 1;
}
// Dead
if ((x > 20) && (x % 5 == 0)) {
x -= 5;
}
// Dead
if ((x < -5) && (x % 3 == 0)) {
x += 3;
}
}
return x;
}
```
I am not an expert of GCC implementation but I would imagine some sort of range
analysis being able to find that the two conditions are dead and remove them
before unrolling. FWIW, LLVM seems to get this case right.
[Bug c/116767] C const function pointer no code generated (or optimized out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116767 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I bet const on the function type is treated as __attribute__((const)) on it, because the latter uses TREE_READONLY on the FUNCTION_TYPE. Of course, the function really is const in the testcase, so optimizing the call away is just fine, but bet if you change it such that it has side-effects it would be miscompiled.
[Bug c++/116666] [15 Regression] firefox does not compile since r15-2331
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 Sam James changed: What|Removed |Added See Also||https://phabricator.service ||s.mozilla.com/D222067 --- Comment #9 from Sam James --- (In reply to Sam James from comment #8) They ended up (thank you!) handling it in https://phabricator.services.mozilla.com/D222067.
[Bug tree-optimization/116768] New: Strict aliasing breaks autovectorization with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116768
Bug ID: 116768
Summary: Strict aliasing breaks autovectorization with -O3
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: imachug at gmail dot com
Target Milestone: ---
This returns 0 (wrong) with strict aliasing enabled and 1 (correct) with strict
aliasing disabled. Looks like a bug to me (no casts, sanitizers are silent, the
example is a minimization of an std::bitset-based reproducer). -O3 -mavx is
required to trigger the bug.
I believe this is a bug in TBAA, because defining Parent to Child or replacing
`y_child->` with `y->child.` fixes the miscompilation. A quick check with
Godbolt shows the code is reduced to 'return 0' by the last tree pass, so I'm
tentatively labeling this tree-optimization.
This can be reproduced starting with 11.2 up to trunk.
https://godbolt.org/z/1v16bPdfv
```
typedef struct {
unsigned long words[2];
} Child;
typedef struct {
Child child;
} Parent;
Parent my_or(Parent x, const Parent *y) {
const Child *y_child = &y->child;
for (int i = 0; i < 2; i++) {
x.child.words[i] |= y_child->words[i];
}
return x;
}
int main() {
Parent bs[4];
__builtin_memset(bs, 0, sizeof(bs));
bs[0].child.words[0] = 1;
for (int i = 1; i <= 3; i++) {
bs[i] = my_or(bs[i], &bs[i - 1]);
}
return bs[2].child.words[0];
}
```
Here's -v for my local compiler if you find it useful.
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/14.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++,rust
--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 14.2.1 20240805 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mavx' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a-'
/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/cc1 -E -quiet -v test.c -mavx
-mtune=generic -march=x86-64 -O3 -fpch-preprocess -o a-test.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mavx' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a-'
/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/cc1 -fpreprocessed a-test.i -quiet
-dumpdir a- -dumpbase test.c -dumpbase-ext .c -mavx -mtune=generic
-march=x86-64 -O3 -version -o a-test.s
GNU C17 (GCC) version 14.2.1 20240805 (x86_64-pc-linux-gnu)
compiled by GNU C version 14.2.1 20240805, GMP version 6.3.0, MPFR
version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: faa3163d33b78b77071c76eebeab3034
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mavx' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a-'
as -v --64 -o a-test.o a-test.s
GNU assembler version 2.43.0 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.43.0
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mavx' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a.'
/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/collect2 -plugin
/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/lto-wrapper
-plugin-opt=-fresolution=a.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr
[Bug c++/116769] New: Instantiation of defaulted default constructor with non default constructible NDSMIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116769
Bug ID: 116769
Summary: Instantiation of defaulted default constructor with
non default constructible NDSMIs
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hi,
Consider this testcase:
#include
struct NDC { NDC(int); };
template
struct Wrap
{
Wrap() = default;
Wrap(const T &t) : t(t) {}
T t = T();
};
static_assert(!std::is_default_constructible_v>);
GCC accepts this, while Clang / MSVC reject:
https://gcc.godbolt.org/z/njh6Tvj19
Is this supposed to be ill-formed instead? Wrap's default constructor is going
to be defined (and NOT deleted, https://eel.is/c++draft/class.default.ctor#2.5
should not apply here), and that should cause the =T() initialization for the
member to fail to compile.
[Bug c++/116666] [15 Regression] firefox does not compile since r15-2331
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 --- Comment #10 from Jakub Jelinek --- "__builtin_shufflevector instead of __builtin_shuffle for better code generation" is certainly not true. Both of the builtins are different and they have their pros and cons. For the swgl code if it has been written with __builtin_shufflevector in mind, it can result in better code, sure, or if one uses something that can't be expressed by __builtin_shuffle. On the other side, __builtin_shuffle allows non-constant permutations, something __builtin_shufflevector doesn't allow.
[Bug c/116767] C const function pointer no code generated (or optimized out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116767 --- Comment #4 from Martin Uecker --- You are right about both. It gets miscompiled also with side effects and if you are remove the forward declaration, you get: :10:21: warning: initialization makes '__attribute__((const))' qualified function pointer from unqualified [-Wdiscarded-qualifiers] 10 | const MyFunc* g_f = my_func;
[Bug c++/116714] [14/15 Regression] Inconsistent lambda type inference in function template instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116714
--- Comment #8 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:82c2acd0bc4411524a8248fcdce219927d921a71
commit r15-3694-g82c2acd0bc4411524a8248fcdce219927d921a71
Author: Patrick Palka
Date: Wed Sep 18 13:50:43 2024 -0400
c++: alias of decltype(lambda) is opaque [PR116714, PR107390]
Here for
using type = decltype([]{});
static_assert(is_same_v);
we strip the alias ahead of time during template argument coercion
which effectively transforms the template-id into
is_same_v
which is wrong because later substitution into the template-id will
produce two new lambdas with distinct types and cause is_same_v to
return false.
This demonstrates that such aliases should be considered opaque (a
notion that we recently introduced in r15-2331-g523836716137d0).
(An alternative solution might be to consider memoizing lambda-expr
substitution rather than always producing a new lambda, but this is
much simpler.)
PR c++/116714
PR c++/107390
gcc/cp/ChangeLog:
* pt.cc (dependent_opaque_alias_p): Also return true for a
decltype(lambda) alias.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval18.C: New test.
Reviewed-by: Jason Merrill
[Bug c++/107390] template-nested lambda type uniqueness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107390
--- Comment #2 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:82c2acd0bc4411524a8248fcdce219927d921a71
commit r15-3694-g82c2acd0bc4411524a8248fcdce219927d921a71
Author: Patrick Palka
Date: Wed Sep 18 13:50:43 2024 -0400
c++: alias of decltype(lambda) is opaque [PR116714, PR107390]
Here for
using type = decltype([]{});
static_assert(is_same_v);
we strip the alias ahead of time during template argument coercion
which effectively transforms the template-id into
is_same_v
which is wrong because later substitution into the template-id will
produce two new lambdas with distinct types and cause is_same_v to
return false.
This demonstrates that such aliases should be considered opaque (a
notion that we recently introduced in r15-2331-g523836716137d0).
(An alternative solution might be to consider memoizing lambda-expr
substitution rather than always producing a new lambda, but this is
much simpler.)
PR c++/116714
PR c++/107390
gcc/cp/ChangeLog:
* pt.cc (dependent_opaque_alias_p): Also return true for a
decltype(lambda) alias.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval18.C: New test.
Reviewed-by: Jason Merrill
[Bug c++/107430] [meta-bug] lambda in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430 Bug 107430 depends on bug 116714, which changed state. Bug 116714 Summary: [14/15 Regression] Inconsistent lambda type inference in function template instance https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116714 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/116714] [14/15 Regression] Inconsistent lambda type inference in function template instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116714 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|14.3|15.0 --- Comment #9 from Patrick Palka --- Fixed for GCC 15, unfortunately the fix can't be backported to the 14 branch due to a depending on r15-2331 which is too risky to backport.
[Bug c++/107430] [meta-bug] lambda in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430 Bug 107430 depends on bug 107390, which changed state. Bug 107390 Summary: template-nested lambda type uniqueness https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107390 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/116765] [12/13/14/15 regression] gcc generate wrong code with -O3 -march=skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116765 Sam James changed: What|Removed |Added Summary|gcc generate wrong code |[12/13/14/15 regression] |with -O3 -march=skylake |gcc generate wrong code ||with -O3 -march=skylake Known to work||4.9.0 --- Comment #2 from Sam James --- 4.9.1 seems to be the first bad version on godbolt w/ -O3 -fno-vect-cost-model -ftree-vectorize -mavx
[Bug c++/107390] template-nested lambda type uniqueness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107390 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |15.0 Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- Fixed for GCC 15.
[Bug libstdc++/116755] format and print functions prepend extra minus sign for min value of chrono duration type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116755
--- Comment #10 from Zartaj Majeed ---
Just tried unsigned duration with system_clock - I guess the requirement for
signed Rep is for the default duration - could this have any legitimate use? Or
should there be a warning?
auto t1 = time_point>{};
println("t1 value {}", t1);
t1 value 1970-01-01 00:00:00
-
This gives the same compile error as before
auto d4 = duration{};
println("d4 value {}", d4);
[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Namniav changed:
What|Removed |Added
CC||namniav at gmail dot com
--- Comment #34 from Namniav ---
I'd like to provide a more subtle example:
#include
#include
int main() {
int a = -1;
int b = -1;
uintptr_t ia = (uintptr_t)&a;
uintptr_t ib = (uintptr_t)(&b + 1);
if (ia == ib) {
*(int*)(ia == ib ? ia : ib) = 42;
printf("%d\n", a);
}
return 0;
}
It prints -1 compiled by gcc -O1 (https://godbolt.org/z/ecf4Kjc16).
[Bug tree-optimization/116352] [15 regression] ICE when building opencv-4.9.0 (error: definition in block 208 does not dominate use in block 188) since r15-2820-gab18785840d7b8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116352 Andrew Pinski changed: What|Removed |Added Keywords|needs-bisection |needs-reduction --- Comment #16 from Andrew Pinski --- rereducing then ...
[Bug target/116774] New: ICE bootstrapping on cfarm92 (a riscv64 machine)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116774 Bug ID: 116774 Summary: ICE bootstrapping on cfarm92 (a riscv64 machine) Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org Target Milestone: --- Host: riscv64-unknown-linux-gnu Target: riscv64-unknown-linux-gnu Build: riscv64-unknown-linux-gnu No special arguments to configure, building with 2 make jobs, and I got this ICE: g++ -std=c++11 -fno-PIE -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -fno-PIE -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libcody -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace -o insn-emit-5.o -MT insn-emit-5.o -MMD -MP -MF ./.deps/insn-emit-5.TPo insn-emit-5.cc during RTL pass: jump insn-emit-5.cc: In function ‘rtx_def* gen_pred_indexed_ustorervvm4x2bfrvvm2qi(rtx, rtx, rtx, rtx, rtx, rtx)’: insn-emit-5.cc:65168:1: internal compiler error: Segmentation fault 65168 | } | ^ 0x3f3b33a77b __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x3f3b33a827 __libc_start_main_impl ./csu/libc-start.c:392 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. make[3]: *** [Makefile:1194: insn-emit-5.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod gcov.pod lto-dump.pod make[3]: Leaving directory '/home/egallager/gcc/AAA_cfarm92.build/gcc' make[2]: *** [Makefile:5053: all-stage1-gcc] Error 2 make[2]: Leaving directory '/home/egallager/gcc/AAA_cfarm92.build' make[1]: *** [Makefile:25986: stage1-bubble] Error 2 make[1]: Leaving directory '/home/egallager/gcc/AAA_cfarm92.build' make: *** [Makefile:1099: all] Error 2
[Bug rtl-optimization/116774] ICE bootstrapping on cfarm92 (a riscv64 machine)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116774 Andrew Pinski changed: What|Removed |Added Component|target |rtl-optimization Status|UNCONFIRMED |WAITING Keywords||ice-on-valid-code Ever confirmed|0 |1 Last reconfirmed||2024-09-19 --- Comment #1 from Andrew Pinski --- > See for instructions. This is with the host compiler so this might not be something which we could help with.
[Bug rtl-optimization/116774] ICE bootstrapping on cfarm92 (a riscv64 machine)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116774 --- Comment #2 from Eric Gallager --- well, I mean, it *ought* to be possible to bootstrap with GCC 11 as the host compiler, right? The "transition to C++14" thread on the mailing lists was just talking about raising the requirement for the host compiler to GCC 5, which is still significantly older than GCC 11...
[Bug rtl-optimization/116774] ICE bootstrapping on cfarm92 (a riscv64 machine)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116774 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #3 from Sam James --- The problem is that it's riscv (so 11 is prehistoric in that context) and it's also a huge generated file. tbh, I suspect if you re-run the failing command, it might even succeed. The riscv boards often aren't very stable..
[Bug tree-optimization/91322] [10 regression] g++.dg/lto/alias-4_0.C test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #18 from Sam James --- (In reply to Jan Hubicka from comment #17) > So this turned out to be disabled ODR based TBAA for this struct since on > ARM the builtin va_list type has same structure. > I fixed the fialure by adjusting the structure and next stage1 we can make > ODR TBAA to not give up in this case. Did we ever come back to this?
[Bug rtl-optimization/116774] ICE bootstrapping on cfarm92 (a riscv64 machine)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116774 --- Comment #4 from Sam James --- The difference is "code we might massage to make it compile" vs "no idea why the host compiler is ICEing", i.e. language support vs bugginess.
[Bug tree-optimization/116765] [12/13/14/15 regression] gcc generate wrong code with -O3 -march=skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116765 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #3 from Hongtao Liu --- So -mavx2 is sufficient to reprodcue the issue. There're cross-iteration dependence for the inner loop ok[i][j] = ok[i][j] | ok[i + 1][j] | ok[i][j - 1]; loop vectorizer shouldn't use 256-bit for vectorization(128-bit is fine since std::bitset<105> takes 128-bit, it's slp inside the loop)
[Bug tree-optimization/116765] [12/13/14/15 regression] gcc generate wrong code with -O3 -march=skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116765 Sam James changed: What|Removed |Added Last reconfirmed||2024-09-19 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug rtl-optimization/116774] ICE bootstrapping on cfarm92 (a riscv64 machine)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116774 --- Comment #5 from Eric Gallager --- (In reply to Sam James from comment #3) > The problem is that it's riscv (so 11 is prehistoric in that context) and > it's also a huge generated file. > > tbh, I suspect if you re-run the failing command, it might even succeed. The > riscv boards often aren't very stable.. Hm, indeed, I'm trying it without the `-j2` this time, and it seems to be getting past that spot... maybe it was hitting some sort of resource limit due to the parallelism?
[Bug rtl-optimization/116774] ICE bootstrapping on cfarm92 (a riscv64 machine)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116774 --- Comment #6 from Sam James --- If I had to bet, it's overheating.
[Bug c/87588] gcc does not warn about unused variable which references to itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87588 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #5 from Martin Uecker --- 115027 seems to be a duplicate if I am not mistaken and here is a patch: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115027
[Bug tree-optimization/116573] [15 Regression] Recent SLP work appears to generate significantly worse code on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116573 --- Comment #9 from Richard Biener --- So with the patch I see tons of "regressions" (https://github.com/ewlu/gcc-precommit-ci/issues/2248#issuecomment-2355417578) like for example for gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-1.c we go from .L6: mv a4,a3 bleua3,a5,.L5 csrra4,vlenb .L5: vsetvli zero,a4,e8,m1,ta,ma vle8.v v1,0(a1) vle8.v v2,0(a2) vsetvli a6,zero,e8,m1,ta,ma vsaddu.vv v1,v1,v2 vsetvli zero,a4,e8,m1,ta,ma vse8.v v1,0(a0) add a1,a1,a5 add a2,a2,a5 add a0,a0,a5 mv a4,a3 sub a3,a3,a5 bgtua4,a5,.L6 to .L5: vsetvli a5,a3,e8,m1,ta,ma vle8.v v1,0(a1) vle8.v v2,0(a2) vsaddu.vv v1,v1,v2 vse8.v v1,0(a0) add a1,a1,a5 add a2,a2,a5 add a0,a0,a5 sub a3,a3,a5 bne a3,zero,.L5 so we're now using .SELECT_VL where we didn't before. Unfortunately all the regressing testcases are compile-only :/ I think the new variant is OK, we're accessing all uchar8_t data only, I don't know why we rejected the use of .SELECT_VL for this earlier. I do not feel like checking all of the 900 additional FAILs that appear in the CI though.
[Bug testsuite/116757] New: check_effective_target_fileio uses deprecated function resulting in UNSUPPORTED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116757
Bug ID: 116757
Summary: check_effective_target_fileio uses deprecated function
resulting in UNSUPPORTED
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
Tests like gcc.c-torture/execute/fprintf-2.c have a
dg-requires-effective-target on fileio but with "recent" glibc the test
# Check to see that file I/O functions are available.
proc check_effective_target_fileio { } {
return [check_no_compiler_messages fileio_available executable {
#include
int main() {
char *n = tmpnam (NULL);
FILE *f = fopen (n, "w");
fclose (f);
remove (n);
return 0;
} } ""]
}
results in
Executing on host: /home/rguenther/obj-riscv-g/gcc/xgcc
-B/home/rguenther/obj-riscv-g/gcc/ fileio_available24825.c -march=rv64gcv
-fdiagnostics-plain-output -Wno-complain-wrong-lang -lm -o
fileio_available24825.exe(timeout = 300)
spawn -ignore SIGHUP /home/rguenther/obj-riscv-g/gcc/xgcc
-B/home/rguenther/obj-riscv-g/gcc/ fileio_available24825.c -march=rv64gcv
-fdiagnostics-plain-output -Wno-complain-wrong-lang -lm -o
fileio_available24825.exe
/usr/bin/riscv64-suse-linux-ld: /tmp/ccU8OtI9.o: in function `main':
fileio_available24825.c:(.text+0xa): warning: the use of `tmpnam' is dangerous,
better use `mkstemp'
UNSUPPORTED: gcc.c-torture/execute/fprintf-2.c -O0
this particular test uses gcc_tmpnam which could be modernized along the
effective target but cross-checking other users would be necessary. I'm
not sure we can prune this specific message from the test and still get
using tests pass.
[Bug tree-optimization/116573] [15 Regression] Recent SLP work appears to generate significantly worse code on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116573 --- Comment #10 from JuzheZhong --- (In reply to Richard Biener from comment #9) > So with the patch I see tons of "regressions" > (https://github.com/ewlu/gcc-precommit-ci/issues/2248#issuecomment- > 2355417578) like for example for > gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-1.c we go from > > .L6: > mv a4,a3 > bleua3,a5,.L5 > csrra4,vlenb > .L5: > vsetvli zero,a4,e8,m1,ta,ma > vle8.v v1,0(a1) > vle8.v v2,0(a2) > vsetvli a6,zero,e8,m1,ta,ma > vsaddu.vv v1,v1,v2 > vsetvli zero,a4,e8,m1,ta,ma > vse8.v v1,0(a0) > add a1,a1,a5 > add a2,a2,a5 > add a0,a0,a5 > mv a4,a3 > sub a3,a3,a5 > bgtua4,a5,.L6 > > to > > .L5: > vsetvli a5,a3,e8,m1,ta,ma > vle8.v v1,0(a1) > vle8.v v2,0(a2) > vsaddu.vv v1,v1,v2 > vse8.v v1,0(a0) > add a1,a1,a5 > add a2,a2,a5 > add a0,a0,a5 > sub a3,a3,a5 > bne a3,zero,.L5 > > so we're now using .SELECT_VL where we didn't before. Unfortunately all the > regressing testcases are compile-only :/ I think the new variant is OK, > we're accessing all uchar8_t data only, I don't know why we rejected the use > of .SELECT_VL for this earlier. > > I do not feel like checking all of the 900 additional FAILs that appear in > the CI though. Thanks Richard. I think your SELECT_VL is good to go. The RISC-V testcases FAILs can leave them to RISC-V folks to fix them.
[Bug tree-optimization/116573] [15 Regression] Recent SLP work appears to generate significantly worse code on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116573 --- Comment #11 from Richard Biener --- Created attachment 59135 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59135&action=edit patch I tested This is the patch for the CI with the observed issue.
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #29 from Arnaud Charlet --- Hi Nicolas, Reviewing v10 (and v11), I have the following comments left: For patch 1/8, the change in a-calcon.ads is still too intrusive (incompatible types used), we want to keep the interface (spec) unchanged, and perform any needed conversion in the body before calling System.C_Time.xxx, otherwise this defeats the purpose of keeping these functions in the first place. In s-c_time.adb, please fix the indentation in In_Duration: return Dur_Covers_Tv_Sec or else T.tv_sec < Maybe_Sec or else (T.tv_sec = Maybe_Sec and then T.tv_usec <= Usec); We're testing the patches internally at AdaCore to confirm that there are no unforeseen issue on this delicate patch, but looks like we are converging, thank you for your patience here !
[Bug target/116738] Constant folding of _mm_min_ss and _mm_max_ss is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738 --- Comment #14 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #13) > Though, unsure about why ieee is used in the name of some of the patterns, > my copy of IEEE says that minNum and maxNum should return the non-NaN > operand if one is NaN and other is not, and unspecified which one is > returned when both are 0s of any sign or both are NaNs. > The VMINSS etc. definition clearly is src1 < src2 ? src1 : src2 and that can > be represented in RTL as (if_then_else (unge (match_operand 1) > (match_operand 2)) (match_dup 2) (match_dup 1)) or so, no need for UNSPEC. > Or am I missing something? Please note that in the test the insn is generated from the intrinsic, which has documented behaviour wrt zeros and NaNs [1]. The testcase expects this behaviour and this is why we should emit UNSPEC. We can still emit smin/smax RTX if NaNs and signed zeros can be ignored. The ieee in the name is mainly due to historical reasons... [1] https://www.felixcloutier.com/x86/minss
[Bug tree-optimization/116766] New: Missed loop vectorization case with gather/scatter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116766
Bug ID: 116766
Summary: Missed loop vectorization case with gather/scatter
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dusan.stojko...@rt-rk.com
Target Milestone: ---
Created attachment 59138
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59138&action=edit
A dump file of vect pass with details enabled
Hello this report is about a loop which GCC doesn't vectorize.
This is the loop in question:
void
foo(int *in, int *out1, int *out2, int n)
{
for (int i = 0; i < n; i+=2)
{
out1[i/2] = in[i];
out2[i/2] = in[i+1];
}
}
GCC isn't able to vectorize this example:
ARM: https://godbolt.org/z/Eq7vs7ssx
RISC-V: https://godbolt.org/z/Y1sr4cr8K
Clang vectorizes this loop for ARM as well as RISC-V:
ARM: https://godbolt.org/z/YvaMqTz1h
RISC-V: https://godbolt.org/z/x1MxGc7Gx
In the vect optimization pass there are two misses regarding array indexing:
analyze_innermost: t.c:6:19: missed: failed: evolution of base is not affine.
analyze_innermost: t.c:7:19: missed: failed: evolution of base is not affine.
There are also these misses:
t.c:6:23: missed: possible alias involving gather/scatter between *_3 and *_7
t.c:4:23: missed: bad data dependence.
t.c:6:23: missed: possible alias involving gather/scatter between *_3 and *_7
t.c:4:23: missed: bad data dependence.
t.c:6:23: missed: possible alias involving gather/scatter between *_3 and *_7
t.c:4:23: missed: bad data dependence.
t.c:6:23: missed: possible alias involving gather/scatter between *_3 and *_7
t.c:4:23: missed: bad data dependence.
t.c:6:23: missed: possible alias involving gather/scatter between *_3 and *_7
t.c:4:23: missed: bad data dependence.
t.c:6:23: missed: possible alias involving gather/scatter between *_3 and *_7
t.c:4:23: missed: bad data dependence.
t.c:6:23: missed: possible alias involving gather/scatter between *_3 and *_7
t.c:4:23: missed: bad data dependence.
t.c:6:23: missed: possible alias involving gather/scatter between *_3 and *_7
t.c:4:23: missed: bad data dependence.
t.c:6:23: missed: possible alias involving gather/scatter between *_3 and *_7
t.c:4:23: missed: bad data dependence.
t.c:4:23: missed: couldn't vectorize loop
void foo (int * in, int * out1, int * out2, int n)
{
int i;
long unsigned int _1;
long unsigned int _2;
int * _3;
int _4;
long unsigned int _5;
long unsigned int _6;
int * _7;
int _8;
sizetype _9;
sizetype _10;
int * _11;
int * _12;
int _13;
[local count: 118111600]:
if (n_17(D) > 0)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 105119324]:
[local count: 955630224]:
# i_26 = PHI
_1 = (long unsigned int) i_26;
_2 = _1 * 4;
_3 = in_18(D) + _2;
_4 = i_26 >> 1;
_5 = (long unsigned int) _4;
_6 = _5 * 4;
_7 = out1_19(D) + _6;
_8 = *_3;
*_7 = _8;
_9 = _1 + 1;
_10 = _9 * 4;
_11 = in_18(D) + _10;
_12 = out2_21(D) + _6;
_13 = *_11;
*_12 = _13;
i_23 = i_26 + 2;
if (n_17(D) > i_23)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 850510900]:
goto ; [100.00%]
[local count: 105119324]:
[local count: 118111600]:
return;
}
[Bug tree-optimization/116585] [12/13/14/15 Regression] SSA corruption with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116585 --- Comment #3 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:1d0cb3b5fca69b81e69cfdb4aea0eebc1ac04750 commit r15-3680-g1d0cb3b5fca69b81e69cfdb4aea0eebc1ac04750 Author: Richard Biener Date: Wed Sep 18 09:52:55 2024 +0200 tree-optimization/116585 - SSA corruption with split_constant_offset split_constant_offset when looking through SSA defs can end up picking SSA leafs that are subject to abnormal coalescing. This can lead to downstream consumers to insert code based on the result (like from dataref analysis) in places that violate constraints for abnormal coalescing. It's best to not expand defs whose operands are subject to abnormal coalescing - and not either do something when a subexpression has operands like that already. PR tree-optimization/116585 * tree-data-ref.cc (split_constant_offset_1): When either operand is subject to abnormal coalescing do no further processing. * gcc.dg/torture/pr116585.c: New testcase.
[Bug tree-optimization/116585] [12/13/14 Regression] SSA corruption with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116585 Richard Biener changed: What|Removed |Added Known to work||15.0 Priority|P3 |P2 Summary|[12/13/14/15 Regression]|[12/13/14 Regression] SSA |SSA corruption with -O3 |corruption with -O3 --- Comment #4 from Richard Biener --- Fixed on trunk sofar.
[Bug libstdc++/116755] format and print functions prepend extra minus sign for min value of chrono duration type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116755
--- Comment #5 from Jonathan Wakely ---
6s is currently required by the standard. std::println("{}", d2) formats the
duration as if by writing to an ostream, so is equivalent to std::cout << d2
int8_t is signed char, and writing a signed char to an ostream casts to char.
This is the subject of
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3154r1.html which has
not been approved by the committee yet.
The result from {fmt} is more useful, but is not what the standard requires.
[Bug tree-optimization/105816] SLP vectorize permutes from different groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105816 Richard Biener changed: What|Removed |Added Last reconfirmed|2022-06-02 00:00:00 |2024-9-18 Keywords||missed-optimization --- Comment #2 from Richard Biener --- Re-confirmed. With AVX2 we build the RHS from scalars instead of splitting the node for the testcase in the description.
[Bug libstdc++/116755] format and print functions prepend extra minus sign for min value of chrono duration type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116755 --- Comment #6 from Jonathan Wakely --- It's also the subject of https://cplusplus.github.io/LWG/issue4118 Even if we change the behaviour of duration you'll still get silly output for duration.
[Bug target/116763] New: 14-19% slowdown of 436.cactusADM on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116763 Bug ID: 116763 Summary: 14-19% slowdown of 436.cactusADM on aarch64 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: missed-optimization, needs-bisection Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: aarch64-gnu-linux Target: aarch64-gnu-linux As seen here https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=586.100.0 (-Ofast -march=native PGO -flto) https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=578.100.0 (-Ofast -march=native PGO) there was a 14-19% exec time slowdown of the 436.cactusADM SPEC 2006 benchmark between commits r15-3500-g1914ca8791ce4e r15-3520-g1a1f818c60636f when run on an aarch64 machine (Ampere Altra - Neoverse N1). I don't think is a regression against GCC 14. However, GCC 12 and 13 produce faster code than the current trunk GCC. See the graphs here: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.6=755.100.0&plot.7=868.100.0&plot.8=1032.100.0&plot.9=586.100.0 (-Ofast -march=native PGO -flto) https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.6=761.100.0&plot.7=874.100.0&plot.8=1066.100.0&plot.9=578.100.0 (-Ofast -march=native PGO) Btw the fact that GCC 14 is also slow is reported as pr114412. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug target/116763] 14-19% slowdown of 436.cactusADM on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116763 Filip Kastl changed: What|Removed |Added Target Milestone|--- |15.0
[Bug c/66918] Disable "inline function declared but never defined" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918 Hime Haieto changed: What|Removed |Added CC||himehaieto at gmail dot com --- Comment #13 from Hime Haieto --- For specific functions, annotating them with __attribute__((unused)) (pre-c++17) or [[maybe_unused]] (c++17 and beyond) removes this warning with clang but not g++. For all functions, using -Wno-unused works for both clang and g++, at least going back as far as g++ 12.2.0. The diagnostic disparity with the unused attribute not working for g++ is what needs to be fixed. See PR116729 for the related report for c code.
[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #42 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #41)
> I still can't reproduce it even with a 14.2.0 worktree nested under the main
> repo dir.
>
> What does this show when run in the build dir?
>
> grep -w VPATH
> x86_64-pc-linux-gnu/{.,32}/libstdc++-v3/src/libbacktrace/Makefile
apinski@xeond:~/src/tt1/gcc/worktrees/14.2.0/tt1/tt1$ grep -w VPATH
x86_64-pc-linux-gnu/{.,32}/libstdc++-v3/src/libbacktrace/Makefile
x86_64-pc-linux-gnu/./libstdc++-v3/src/libbacktrace/Makefile:VPATH =
/home/apinski/src/tt1/gcc/worktrees/14.2.0/libstdc++-v3/src/libbacktrace
x86_64-pc-linux-gnu/32/libstdc++-v3/src/libbacktrace/Makefile:VPATH =
/home/apinski/src/tt1/gcc/worktrees/14.2.0/libstdc++-v3/src/libbacktrace
[Bug c/116764] New: SIGSEGV in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116764
Bug ID: 116764
Summary: SIGSEGV in C
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yunboni at smail dot nju.edu.cn
Target Milestone: ---
Created attachment 59137
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59137&action=edit
The preprocessed file
When I compiled this code with `gcc case.c -o case` and run `./case`, it gave
SIGSEGV.
```c
#include
int *a;
int d;
int b() {
for (int c = 0;;)
a[c] = d;
return 1;
}
int64_t e() {
int32_t f[b()];
return f[0];
}
int main() {
e();
return 0;
}
```
My gcc version is:
Using built-in specs.
COLLECT_GCC=/home/yunbo/eval/compilers/gcc_latest/bin/gcc
COLLECT_LTO_WRAPPER=/home/yunbo/eval/compilers/gcc_latest/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/yunbo/eval/compilers/gcc_latest
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240912 (experimental) (GCC)
[Bug target/116738] Constant folding of _mm_min_ss and _mm_max_ss is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738 --- Comment #15 from Jakub Jelinek --- (In reply to Uroš Bizjak from comment #14) > (In reply to Jakub Jelinek from comment #13) > > Though, unsure about why ieee is used in the name of some of the patterns, > > my copy of IEEE says that minNum and maxNum should return the non-NaN > > operand if one is NaN and other is not, and unspecified which one is > > returned when both are 0s of any sign or both are NaNs. > > The VMINSS etc. definition clearly is src1 < src2 ? src1 : src2 and that can > > be represented in RTL as (if_then_else (unge (match_operand 1) > > (match_operand 2)) (match_dup 2) (match_dup 1)) or so, no need for UNSPEC. > > Or am I missing something? > Please note that in the test the insn is generated from the intrinsic, which > has documented behaviour wrt zeros and NaNs [1]. The testcase expects this > behaviour and this is why we should emit UNSPEC. We can still emit smin/smax > RTX if NaNs and signed zeros can be ignored. What I meant is that the above mentioned IF_THEN_ELSE could represent exactly the behavior the insn has (i.e. use src2 for unordered or equal or greater, no exceptions for qNaN) and has the advantage of being constant foldable if both operands are constants. Both for the scalar and vector cases.
[Bug target/116738] Constant folding of _mm_min_ss and _mm_max_ss is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738 --- Comment #16 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #12) > I think the problem is the mixing of four different substitutions in a > single pattern, > in particular round_saeonly and round_saeonly_scalar and mask and > mask_scalar. > is from the second, > and > from the first and and > from the third and from the > fourth. > I think it only should use 2 substs, likely mask_scalar and > round_saeonly_scalar, like the previous pattern. And if something needs to > be added to those two subst attributes (likely to ensure the right extra > arguments are passed to the gen* routine), it should be added. Yeah, after confirming that UNSPEC works for the testcase, I copypasted from similar pattern, and after some tires I lost my will to hunt down the remaining causes of duplicate definitions.
[Bug c++/116722] [12/13/14/15 Regression] ICE with constexpr template constructor and floating point value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116722 Simon Martin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |simartin at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Simon Martin --- Working on this one.
[Bug tree-optimization/116758] [15 Regression] 25-40% binary size increase and up to 177% compile time increase for SPEC CPU wrf with Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116758 --- Comment #3 from Richard Biener --- Note Zen3 also seems to be affected (maybe that allows the revision range to be constrained more). It possibly sounds like we generate more (vectorized) epilogues maybe.
[Bug target/116759] New: [15 Regression] 5% exec time slowdown of 538.imagick_r on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116759 Bug ID: 116759 Summary: [15 Regression] 5% exec time slowdown of 538.imagick_r on aarch64 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: needs-bisection Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: aarch64-gnu-linux Target: aarch64-gnu-linux As seen here https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=583.507.0 there was a 5% execution time regression of the 2017 SPEC CPU 538.imagick_r benchmark when compiled with -Ofast -march=native PGO on aarch64. This happened between commits r15-3244-g3178786c88761e r15-3390-g539fcaae67c888 The machine on which this was measured is Ampere Altra - Neoverse N1. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug target/116759] [15 Regression] 5% exec time slowdown of 538.imagick_r on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116759 Filip Kastl changed: What|Removed |Added Target Milestone|--- |15.0
[Bug tree-optimization/116258] PAREN_EXPR lowering for vectors is bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116258 --- Comment #10 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Biener : https://gcc.gnu.org/g:198b13e248e7adfea2d28c4e66ac9f5006b8f825 commit r14-10679-g198b13e248e7adfea2d28c4e66ac9f5006b8f825 Author: Richard Biener Date: Thu Aug 8 09:35:42 2024 +0200 tree-optimization/116258 - fix i386 testcase With -march=cascadelake we use vpermilps instead of shufps. PR tree-optimization/116258 * gcc.target/i386/pr116258.c: Also allow vpermilps. (cherry picked from commit 5aa4cd913e48cfce3ca0ab58cf6f80f55dbb0f58)
[Bug middle-end/115641] [12/13/14 Regression] GCC crashes on function has const attribute since r10-3830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115641 --- Comment #7 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Biener : https://gcc.gnu.org/g:98dc0471d5409701ae700cd7aba8716fdc500401 commit r14-10677-g98dc0471d5409701ae700cd7aba8716fdc500401 Author: Richard Biener Date: Thu Jul 18 13:35:33 2024 +0200 middle-end/115641 - invalid address construction fold_truth_andor_1 via make_bit_field_ref builds an address of a CALL_EXPR which isn't valid GENERIC and later causes an ICE. The following simply avoids the folding for f ().a != 1 || f ().b != 2 as it is a premature optimization anyway. The alternative would have been to build a TARGET_EXPR around the call. To get this far f () has to be const as otherwise the two calls are not semantically equivalent for the optimization. PR middle-end/115641 * fold-const.cc (decode_field_reference): If the inner reference isn't something we can take the address of, fail. * gcc.dg/torture/pr115641.c: New testcase. (cherry picked from commit 3670c70c561656a19f6bff36dd229f18120af127)
[Bug c/116764] SIGSEGV in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116764 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Huh? a is a null pointer so writing to it will cause this behavior.
[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730 --- Comment #43 from Hime Haieto --- 1) Yes, I had been building within a git worktree, repodir/worktrees/<14.2_worktree>/build/votocon/. 2) The bad links I got looked nuts, like so: ../../../libbacktrace/../../../libbacktrace/../../../libbacktrace/atomic.c
[Bug c++/116416] Missing optimization: compile time evaluation of prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116416 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-09-18 Ever confirmed|0 |1 CC||jason at gcc dot gnu.org
[Bug tree-optimization/116765] gcc generate wrong code with -O3 -march=skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116765 --- Comment #1 from xiaohuba2021 --- godbolt link: https://godbolt.org/z/4vTjcdhv5
[Bug tree-optimization/116765] New: gcc generate wrong code with -O3 -march=skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116765
Bug ID: 116765
Summary: gcc generate wrong code with -O3 -march=skylake
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: xiaohuba2021 at 163 dot com
Target Milestone: ---
The following code is miscompiled with -O3 -march=skylake:
```
#include
#include
const int N = 105;
std::bitset ok[N][N];
int n = 5;
int main() {
ok[2][2].set(2);
for (int i = n; i; i--)
for (int j = i; j <= n; j++) {
ok[i][j] = ok[i][j] | ok[i + 1][j] | ok[i][j - 1];
}
std::cout << ok[2][5][2] << '\n';
return 0;
}
```
It outputs 0, however (obviously) the correct answer should be 1.
Turning off O3 or march=skylake gives the right output.
gcc version:
```
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20240918/configure
--prefix=/opt/compiler-explorer/gcc-build/staging
--enable-libstdcxx-backtrace=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d,rust,m2 --enable-ld=yes
--enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc-38b5a568f8738c16baa978a62a9e983a85b4c6f0-binutils-2.42
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240918 (experimental)
(Compiler-Explorer-Build-gcc-38b5a568f8738c16baa978a62a9e983a85b4c6f0-binutils-2.42)
```
[Bug libstdc++/116755] format and print functions prepend extra minus sign for min value of chrono duration type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116755
--- Comment #9 from Zartaj Majeed ---
Won't I have to separately add units to +d2.count()?
I didn't think to try unsigned types because I'm working with system_clock that
I believe requires signed Rep - but the following doesn't compile for me
auto d3 = duration_cast>>(d1);
println("d3 duration_cast unsigned value {}", d3);
test.cpp:14:10: required from here
14 | println("d3 duration_cast unsigned value {}", d3);
| ~~~^~
/usr/include/c++/14/bits/chrono_io.h:1610:44: error: no matching function for
call to ‘abs(const std::chrono::duration&)’
1610 | return _M_f._M_format(chrono::abs(__d), __fc, __d <
__d.zero());
| ~~~^
[Bug c/116767] C const function pointer no code generated (or optimized out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116767
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2 from Martin Uecker ---
I agree the behavior is not ideal.
Simplified some more:
typedef void MyFunc(void);
// the forward decl. suppresses the warning one would otherwise get
static const MyFunc my_func;
static void my_func() { }
#if 1
const MyFunc* g_f = my_func;
#else
MyFunc* g_f = my_func;
#endif
int main(int argc, char* argv[])
{
g_f();
}
https://godbolt.org/z/rcodcqWPn
[Bug target/112109] Missing riscv vectorized strcmp (and other) expanders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112109 --- Comment #6 from Robin Dapp --- Should we close this? I think all of the routines are in or are we missing something still? What's IMHO still a TODO is to honor TARGET_MAX_LMUL for some of the builtins that came first. memcpy for example always uses LMUL8 regardless of TARGET_MAX_LMUL while some others honor it. That should be consistent at least, no matter how the discussion about LMUL continues.
[Bug tree-optimization/116258] PAREN_EXPR lowering for vectors is bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116258 --- Comment #9 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Biener : https://gcc.gnu.org/g:05db1bea8c1d61d8d9cdb8ede5e305766869d136 commit r14-10678-g05db1bea8c1d61d8d9cdb8ede5e305766869d136 Author: Richard Biener Date: Wed Aug 7 13:54:53 2024 +0200 tree-optimization/116258 - do not lower PAREN_EXPR of vectors The following avoids lowering of PAREN_EXPR of vectors as unsupported to scalars. Instead PAREN_EXPR is like a plain move or a VIEW_CONVERT. PR tree-optimization/116258 * tree-vect-generic.cc (expand_vector_operations_1): Do not lower PAREN_EXPR. * gcc.target/i386/pr116258.c: New testcase. (cherry picked from commit 5b97d1a2102dca57918947d7e40a6ca68871)
[Bug target/116274] [14 Regression] x86: poor code generation with 16 byte function arguments and addition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116274 --- Comment #11 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Biener : https://gcc.gnu.org/g:d5d4f3bae5a9478dc2189e53da933175a6d7b197 commit r14-10681-gd5d4f3bae5a9478dc2189e53da933175a6d7b197 Author: Richard Biener Date: Thu Aug 8 11:36:43 2024 +0200 tree-optimization/116274 - overzealous SLP vectorization The following tries to address that the vectorizer fails to have precise knowledge of argument and return calling conventions and views some accesses as loads and stores that are not. This is mainly important when doing basic-block vectorization as otherwise loop indexing would force such arguments to memory. On x86 the reduction in the number of apparent loads and stores often dominates cost analysis so the following tries to mitigate this aggressively by adjusting only the scalar load and store cost, reducing them to the cost of a simple scalar statement, but not touching the vector access cost which would be much harder to estimate. Thereby we error on the side of not performing basic-block vectorization. PR tree-optimization/116274 * tree-vect-slp.cc (vect_bb_slp_scalar_cost): Cost scalar loads and stores as simple scalar stmts when they access a non-global, not address-taken variable that doesn't have BLKmode assigned. * gcc.target/i386/pr116274-2.c: New testcase. (cherry picked from commit b8ea13ebf1211714503fd72f25c04376483bfa53)
[Bug tree-optimization/116380] [13/14 regression] ICE on valid code at -O3 with "-fno-tree-scev-cprop" on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116380 --- Comment #7 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Biener : https://gcc.gnu.org/g:8f8a7e1f1904e389e736c0265b4f515f3ce13659 commit r14-10682-g8f8a7e1f1904e389e736c0265b4f515f3ce13659 Author: Richard Biener Date: Wed Aug 21 13:56:40 2024 +0200 tree-optimization/116380 - bogus SSA update with loop distribution When updating LC PHIs after copying loops we have to handle defs defined outside of the loop appropriately (by not setting them to NULL ...). This mimics how we handle this in the SSA updating code of the vectorizer. PR tree-optimization/116380 * tree-loop-distribution.cc (copy_loop_before): Handle out-of-loop defs appropriately. * gcc.dg/torture/pr116380.c: New testcase. (cherry picked from commit af0d2d95a5f767d92bd64f959679fb4612247b0b)
[Bug middle-end/116259] __builtin_assoc_barrier with VLA type ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116259 --- Comment #3 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Biener : https://gcc.gnu.org/g:090926ba817bee6de7ee210efeea5d43d5335868 commit r14-10680-g090926ba817bee6de7ee210efeea5d43d5335868 Author: Andrew Pinski Date: Wed Aug 7 09:36:38 2024 -0700 aarch64/testsuite: Add testcases for recently fixed PRs The commit for PR 116258, added a x86_64 specific testcase, I thought it would be a good idea to add an aarch64 testcase too. And since it also fixed VLA vectors too so add a SVE testcase. Pushed as obvious after a test for aarch64-linux-gnu. PR middle-end/116258 PR middle-end/116259 gcc/testsuite/ChangeLog: * gcc.target/aarch64/pr116258.c: New test. * gcc.target/aarch64/sve/pr116259-1.c: New test. Signed-off-by: Andrew Pinski (cherry picked from commit 2c6174402ea315ecf618cfcba741e8cb18bc5282)
[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #41 from Jonathan Wakely ---
I still can't reproduce it even with a 14.2.0 worktree nested under the main
repo dir.
What does this show when run in the build dir?
grep -w VPATH x86_64-pc-linux-gnu/{.,32}/libstdc++-v3/src/libbacktrace/Makefile
[Bug tree-optimization/115426] ICE: in execute_todo, at passes.cc:2138
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115426
--- Comment #6 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:5b264a4b95b8f27c3c73892892d5c2030d3c8ea7
commit r14-10685-g5b264a4b95b8f27c3c73892892d5c2030d3c8ea7
Author: Richard Biener
Date: Tue Jun 11 13:11:08 2024 +0200
middle-end/115426 - wrong gimplification of "rm" asm output operand
When the operand is gimplified to an extract of a register or a
register we have to disallow memory as we otherwise fail to
gimplify it properly. Instead of
__asm__("" : "=rm" __imag );
we want
__asm__("" : "=rm" D.2772);
_1 = REALPART_EXPR ;
r = COMPLEX_EXPR <_1, D.2772>;
otherwise SSA rewrite will fail and generate wrong code with 'r'
left bare in the asm output.
PR middle-end/115426
* gimplify.cc (gimplify_asm_expr): Handle "rm" output
constraint gimplified to a register (operation).
* gcc.dg/pr115426.c: New testcase.
(cherry picked from commit a4bbdec2be1c9f8fb49276b8a54ee86024ceac17)
