[Bug target/115123] [15 Regression] RISCV vector scan-assembler failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115123 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |15.0
[Bug tree-optimization/115120] Bad interaction between ivcanon and early break vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115120 --- Comment #2 from Richard Biener --- That said, looking into IVOPTs and making it detect vector IVs would be nice as well.
[Bug tree-optimization/115120] Bad interaction between ivcanon and early break vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115120 Richard Biener changed: What|Removed |Added Blocks||53947 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-17 --- Comment #1 from Richard Biener --- Note this isn't really because of IVCANON but because the IV is live. IVCANON adds a downward counting IV historically to enable RTL doloop transforms. One could argue this should nowadays be IVOPTs job (in the past IVOPTs was done on RTL). So what's really the issue is that IVOPTs does a bad job (I don't really think it even tries) to replace one vector IV with another. We could try to change IVCANON to avoid creating a canonical downward counting IV if one already exists (I don't think it even avoids that case) and also avoid creating a downward counting IV with step -1 when a upward counting IV with step 1 already controls the exit and verify IVOPTs turns it into a downward counting one when profitable. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/115114] aggregate initialization with parens fails when there is a base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115114 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-05-17 --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651935.html
[Bug target/115028] [15 regression] gcc.target/i386/pr101950-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028 kong lingling changed: What|Removed |Added CC||lingling.kong7 at gmail dot com --- Comment #7 from kong lingling --- Just mention and tag commit 9dbff9c05520a74e6cd337578f27b56c941f64f3 also causes another case FAIL. FAIL: gcc.target/i386/apx-ndd-tls-1b.c scan-assembler-times addq[ \t]+%r[a-z0-9]+, a@gottpoff\\(%rip\\), %r[a-z0-9]+ 1
[Bug libstdc++/115126] New: TU-local entity exposures in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115126
Bug ID: 115126
Summary: TU-local entity exposures in libstdc++
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason at gcc dot gnu.org
Target Milestone: ---
I tried compiling this alternate minimal version of module std:
export module std;
extern "C++" {
#include
}
and got a bunch of errors about exposures ([basic.link]/14) , most of which I
think are correct and need to be fixed in the library.
Most are complaining about the __gthread functions which are declared 'static
inline'; uses of these in standard library headers already violate the ODR.
I also see:
/home/jason/s/gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/shared_mutex:216:5:
error: ‘void std::__shared_mutex_pthread::unlock()’ references internal linkage
entity ‘int std::__glibcxx_rwlock_unlock(pthread_rwlock_t*)’
which seems like the same pattern as the __gthread functions. I would think
all of the above would be fixed by changing 'static inline' to just 'inline'.
/home/jason/s/gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/future:1516:7:
error: ‘template virtual
std::shared_ptr >
std::__future_base::_Task_state<_Fn, _Alloc, _Res(_Args ...)>::_M_reset()’
references internal linkage entity ‘template std::shared_ptr >
std::__create_task_state(_Fn&&, const _Alloc&)’
This looks like a typo; when __create_task_state was added in r196695, the
ChangeLog referred to it as a member of __future_base (for which declaring it
static would make sense), but it's actually a namespace-scope function.
Presumably it always should have been inline instead of static, if it isn't
going to be a member.
In file included from
/home/jason/s/gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/memory:78:
/home/jason/s/gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/unique_ptr.h:1161:27:
error: ‘template constexpr const bool
std::__is_unique_ptr >’ references internal linkage
entity ‘template constexpr const bool std::__is_unique_ptr<_Tp>’
This last one seems like a compiler bug; the partial specialization is also
TU-local, so this shouldn't be an error. Though the 'static' seems unnecessary
here as well.
[Bug target/115115] [12/13/14/15 Regression] highway-1.0.7 wrong _mm_cvttps_epi32() constant fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115115 --- Comment #7 from Sergei Trofimovich --- Filed https://github.com/google/highway/issues/2183 on `highway` upstream side.
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||uecker at gcc dot gnu.org Last reconfirmed||2024-05-16 Ever confirmed|0 |1 --- Comment #1 from Joseph S. Myers --- Adding Martin as an issue related to redefinitions of tagged types.
[Bug c/105863] RFE: C23 #embed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863 --- Comment #9 from Joseph S. Myers --- The most straightforward and most important case to optimize is the one where the #embed expansion lies entirely inside a single character array initializer (possibly with some integer constants before or after it in the initializer - whether coming from the prefix and suffix parameters to #embed or otherwise) - in which case the initializer can be converted internally to a STRING_CST. Cases that aren't within a character array initializer like that are harder to optimize (might require additional internal representation beyond the front end), and probably also less important to optimize initially.
[Bug c++/115125] [-Wstringop-overflow=] with O2/O3 - false positive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115125 --- Comment #1 from Nikolai Ivanenko --- Forgot to mention that the the code commented out in main compiles without warnings.
[Bug c++/115125] New: [-Wstringop-overflow=] with O2/O3 - false positive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115125
Bug ID: 115125
Summary: [-Wstringop-overflow=] with O2/O3 - false positive?
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oknenavin at outlook dot com
Target Milestone: ---
$ g++ --version
g++.exe (Rev2, Built by MSYS2 project) 14.1.0
test.cxx:
template
inline char peek(II i, II e) { return i != e ? *i : '\xFF'; }
template
inline char next(II& i, II e) { return peek(++i, e); }
#define READ() *f = c, c = next(i, e), ++f;
#define NEXT() { if (f == l) return -1; READ() }
template
inline int consume(char* f, const char* l, II& i, II e)
{
char c = peek(i, e);
if (c == '"') {
; READ()
if (c == '-') NEXT()
if (c == 'i') {
NEXT() if (c != 'n')return 0;
NEXT() if (c != 'f')return 0;
}
else if (c == 'n') {
NEXT() if (c != 'a')return 0;
NEXT() if (c != 'n')return 0;
}
elsereturn 0;
NEXT() if (c != '"')return 0;
NEXT()
}
return f != l ? (*f = '\0', 1) : -1;
}
int main(int argc, char* argv[]) {
char bf[3];
consume(bf, bf + 3, argv[0], argv[0] + 16);
//char* in = argv[0];
//consume(bf, bf + 3, in, in + 16);
}
$ g++ -c -O2 test.cxx
In function 'int consume(char*, const char*, II&, II) [with II = char*]',
inlined from 'int main(int, char**)' at test.cxx:33:12:
test.cxx:6:19: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
6 | #define READ() *f = c, c = next(i, e), ++f;
|~~~^~~
test.cxx:7:41: note: in expansion of macro 'READ'
7 | #define NEXT() { if (f == l) return -1; READ() }
| ^~~~
test.cxx:25:17: note: in expansion of macro 'NEXT'
25 | NEXT() if (c != '"')return 0;
| ^~~~
test.cxx: In function 'int main(int, char**)':
test.cxx:32:10: note: at offset [1, 3] into destination object 'bf' of size
3
32 | char bf[3];
| ^~
test.cxx:32:10: note: at offset [2, 3] into destination object 'bf' of size
3
test.cxx:32:10: note: at offset [1, 3] into destination object 'bf' of size
3
test.cxx:32:10: note: at offset [2, 3] into destination object 'bf' of size
3
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #33 from Segher Boessenkool --- (In reply to Aldy Hernandez from comment #29) > A minor rant, but why can't all this be set up automatically in the compile > farm machines? We have everything installed with the default for whatever distor (or similar for non-Linux) is used. There are newer tools etc. in /opt/cfarm/ sometimes. On https://gcc.gnu.org/install/ there are installation instructions, for configuring and buiding GCC, generic as well as per-configuration stuff. There is nothing specific about the cfarm here. There is some info about Solaris, in the GCC documentation. > Keeping track of minor nuances of each architecture is > distracting. They should all be set up, whether by setting default paths in > /etc/profile or whatever, or by having the relevant patches in GCC's source > base, such that they work with src/configure && make. A lovely utopian worldview, if you subscribe to the "everything should always be the same" worldview, anyway.
[Bug target/115123] [15 Regression] RISCV vector scan-assembler failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115123 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-16 CC||law at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jeffrey A. Law --- I'm pretty sure it's the change in sink heuristics. I backed that out yesterday as a check. So, yes, testcases need adjustment.
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107 --- Comment #8 from Natalie Perlin --- anl...@gcc.gnu.org - Thank you, this is a great observation! I will need to change the way the spack-stack is built with gnu/14.1.0
[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 Jakub Jelinek changed: What|Removed |Added CC||rl.alt.accnt at gmail dot com --- Comment #5 from Jakub Jelinek --- *** Bug 115124 has been marked as a duplicate of this bug. ***
[Bug libstdc++/115124] Typo: `++this` instead of `++*this`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115124 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 115119 ***
[Bug libstdc++/115124] New: Typo: `++this` instead of `++*this`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115124
Bug ID: 115124
Summary: Typo: `++this` instead of `++*this`
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rl.alt.accnt at gmail dot com
Target Milestone: ---
The `bits/unicode.h` header contains this code (on trunk currently around line
800):
```
constexpr _Iterator
operator++(int)
{
auto __tmp = *this;
++this;
return __tmp;
}
```
I presume this was supposed to be `++*this`, not `++this`.
[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 #7 from Tamar Christina --- Yeah, it's most likely an alignment issue, especially as there's no code changes. We run our benchmarking with different flags so it may be why we don't see it. the loop seems misaligned, you can try increasing the alignment guarantee to check. e.f. -falign-loops=5. But ultimately, I think it's just bad luck. We don't align loops and labels if they require too much padding instructions.
[Bug target/115123] New: [15 Regression] RISCV vector scan-assembler failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115123 Bug ID: 115123 Summary: [15 Regression] RISCV vector scan-assembler failures Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: patrick at rivosinc dot com Target Milestone: --- Postcommit issue: https://github.com/patrick-rivos/gcc-postcommit-ci/issues/937 Commit range: https://github.com/gcc-mirror/gcc/compare/43fb827f259e6fdea39bc4021950c810be769d58...1a05332bbac98a4c002bef3fb45a3ad9d56b3a71 These look like they might be brittle testcases that need to be changed. pr114352-3.c: https://godbolt.org/z/KrGMqboMo FAIL: gcc.target/riscv/rvv/base/pr114352-3.c check-function-bodies test_1 FAIL: gcc.target/riscv/rvv/base/pr114352-3.c check-function-bodies test_4 FAIL: gcc.target/riscv/rvv/vsetvl/avl_multiple-7.c -O2 scan-assembler add\\s+\\s*[a-x0-9]+,\\s*[a-x0-9]+,\\s*[a-x0-9]+\\s+ble\\s+[a-x0-9]+,\\s*zero,\\.L[0-9]+\\s+vsetvli\\s+zero,\\s*[a-x0-9]+,\\s*e8,\\s*mf8,\\s*t[au],\\s*m[au] FAIL: gcc.target/riscv/rvv/vsetvl/avl_multiple-7.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler add\\s+\\s*[a-x0-9]+,\\s*[a-x0-9]+,\\s*[a-x0-9]+\\s+ble\\s+[a-x0-9]+,\\s*zero,\\.L[0-9]+\\s+vsetvli\\s+zero,\\s*[a-x0-9]+,\\s*e8,\\s*mf8,\\s*t[au],\\s*m[au] FAIL: gcc.target/riscv/rvv/vsetvl/avl_multiple-7.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler add\\s+\\s*[a-x0-9]+,\\s*[a-x0-9]+,\\s*[a-x0-9]+\\s+ble\\s+[a-x0-9]+,\\s*zero,\\.L[0-9]+\\s+vsetvli\\s+zero,\\s*[a-x0-9]+,\\s*e8,\\s*mf8,\\s*t[au],\\s*m[au] FAIL: gcc.target/riscv/rvv/vsetvl/avl_multiple-8.c -O2 scan-assembler add\\s+\\s*[a-x0-9]+,\\s*[a-x0-9]+,\\s*[a-x0-9]+\\s+ble\\s+[a-x0-9]+,\\s*zero,\\.L[0-9]+\\s+vsetvli\\s+zero,\\s*[a-x0-9]+,\\s*e8,\\s*mf8,\\s*t[au],\\s*m[au] FAIL: gcc.target/riscv/rvv/vsetvl/avl_multiple-8.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler add\\s+\\s*[a-x0-9]+,\\s*[a-x0-9]+,\\s*[a-x0-9]+\\s+ble\\s+[a-x0-9]+,\\s*zero,\\.L[0-9]+\\s+vsetvli\\s+zero,\\s*[a-x0-9]+,\\s*e8,\\s*mf8,\\s*t[au],\\s*m[au] FAIL: gcc.target/riscv/rvv/vsetvl/avl_multiple-8.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler add\\s+\\s*[a-x0-9]+,\\s*[a-x0-9]+,\\s*[a-x0-9]+\\s+ble\\s+[a-x0-9]+,\\s*zero,\\.L[0-9]+\\s+vsetvli\\s+zero,\\s*[a-x0-9]+,\\s*e8,\\s*mf8,\\s*t[au],\\s*m[au] FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-66.c -O2 scan-assembler-times add\\s+\\s*[a-x0-9]+,\\s*[a-x0-9]+,\\s*[a-x0-9]+\\s+ble\\s+[a-x0-9]+,\\s*zero,\\.L[0-9]+\\s+ 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-66.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler-times add\\s+\\s*[a-x0-9]+,\\s*[a-x0-9]+,\\s*[a-x0-9]+\\s+ble\\s+[a-x0-9]+,\\s*zero,\\.L[0-9]+\\s+ 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-66.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler-times add\\s+\\s*[a-x0-9]+,\\s*[a-x0-9]+,\\s*[a-x0-9]+\\s+ble\\s+[a-x0-9]+,\\s*zero,\\.L[0-9]+\\s+ 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-82.c -O2 scan-assembler-times vsetivli 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-82.c -O2 scan-assembler-times vsetvli\\s+[a-x0-9]+,\\s*zero,\\s*e32,\\s*mf2,\\s*t[au],\\s*m[au] 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-82.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler-times vsetivli 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-82.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler-times vsetvli\\s+[a-x0-9]+,\\s*zero,\\s*e32,\\s*mf2,\\s*t[au],\\s*m[au] 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-82.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler-times vsetivli 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-82.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler-times vsetvli\\s+[a-x0-9]+,\\s*zero,\\s*e32,\\s*mf2,\\s*t[au],\\s*m[au] 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-83.c -O2 scan-assembler-times vsetivli 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-83.c -O2 scan-assembler-times vsetvli\\s+[a-x0-9]+,\\s*zero,\\s*e32,\\s*mf2,\\s*t[au],\\s*m[au] 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-83.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler-times vsetivli 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-83.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler-times vsetvli\\s+[a-x0-9]+,\\s*zero,\\s*e32,\\s*mf2,\\s*t[au],\\s*m[au] 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-83.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler-times vsetivli 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-83.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler-times vsetvli\\s+[a-x0-9]+,\\s*zero,\\s*e32,\\s*mf2,\\s*t[au],\\s*m[au] 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-86.c -O2 scan-as
[Bug target/114412] [14/15 Regression] 7% slowdown of 436.cactusADM on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114412 --- Comment #5 from Tamar Christina --- (In reply to Filip Kastl from comment #4) > (In reply to Tamar Christina from comment #3) > > Hi Filip, > > > > Do you generate these runs with counters based PGO or compiler > > instrumentation? > > > > Just so I know before I start trying to reproduce them. > > Hi Tamar, > > By counters you mean some sort of hardware counters? I didn't know there > were multiple ways to do PGO with GCC. > > I think that the answer to your question is "compiler instrumentation". I > just do -fprofile-generate, run the instrumented binary and then > -fprofile-use. Yeah, with some elbow grease the perf record method works too, but it's not very accurate on Armv8. I'll try to reproduce and bisect these over the weekend!
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Natalie Perlin from comment #6)
> (In reply to anlauf from comment #3)
> > The traceback is essentially identical to that in pr114467.
> >
> > Can you please try the 14-release like the other reporter, or the upcoming
> > 13.3 release next week?
>
> Thank you for the comment. Yes, this indeed looks similar to pr114467.
> I did try to use gnu/14.1.0 + openmpi/4.1.6, but was not able to build a
> software stack needed for building the model that produced the original
> error.
>
> The issue with the gnu/14.1.0 compiler was that it produced an error where
> the gnu/13.2.0 had only a warning. The error with the gnu/14.1.0 compiler
> was as shown below, and is related to -Wimplicit-function-declaration.
> Could it be that a certain compiler flag helps to avoid such an error?..
>
>
> And yes, I'd gladly try the upcoming v13.3 release next week!
>
>
> ===
> /scratch2/NCEPDEV/stmp1/role.epic/spack-stack/spack-stack-1.6.0_gnu14/spack/
> lib/spack/env/gcc/gcc -DHAVE_CONFIG_H -I. -I.
> -I../../../src/libjasper/include/jasper -I../../../src/libjasper/include -g
> -O2 -MT jas_getopt.lo -MD -MP -MF .deps/jas_getopt.Tpo -c jas_getopt.c -o
> jas_getopt.o
> jas_getopt.c: In function 'jas_getopt':
> jas_getopt.c:129:49: error: implicit declaration of function 'jas_eprintf';
> did you mean 'vsnprintf'? [-Wimplicit-function-declaration]
> 129 | jas_eprintf("unknown
> long option %s\n", s);
> | ^~~
> | vsnprintf
> make[4]: *** [Makefile:349: jas_getopt.lo] Error 1
> =
This looks like the header file jas_debug.h is not found or not included.
(On my Linux system it is /usr/include/jasper/jas_debug.h).
[Bug libstdc++/115122] New: Incorrect detection of C99 support when cross-compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115122 Bug ID: 115122 Summary: Incorrect detection of C99 support when cross-compiling Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: tomas.kalibera at gmail dot com Target Milestone: --- Created attachment 58219 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58219&action=edit docker file that reproduces the problem (libstdc++ doesn't use C99 complex functions which are available) When cross-compiling a native toolchain, configuration of libstdc++ incorrectly concludes that there is no C99 support (which then triggers Bug 115117). I've ran into this when building a native toolchain (to run on Windows, produce code for Windows) on a Linux machine. Configure in libstdc++ builds a test program as follows: x86_64-w64-mingw32-c++ -L/opt/gcc-mingw/native/x86_64-w64-mingw32/lib -L/opt/gcc-mingw/native/mingw/lib -isystem /opt/gcc-mingw/native/x86_64-w64-mingw32/include -isystem /opt/gcc-mingw/native/mingw/include -o conftest.exe -g -O2 -std=c++11 -fno-exceptions conftest.cpp -lm >&5 so, it tries to build the configure test using the cross-compiler, including the "-std=c++11" argument but not including "-nostdinc++". That way, C99 functions would appear not available, and the test would fail. I've attached a docker file that reproduces the problem. It ends by showing that "c++config.h" ends up with undefined _GLIBCXX11_USE_C99_COMPLEX and also copies the corresponding lines from the config.log of libstdc++. The docker file also builds a cross-compiler (to cross-compile the native compiler), so one can see that in the cross-compilation, the configure tests run as /build/gcc/build-x86_64/./gcc/xgcc -shared-libgcc -B/build/gcc/build-x86_64/./gcc -nostdinc++ -L/build/gcc/build-x86_64/x86_64-w64-mingw32/libstdc++-v3/src -L/build/gcc/build-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/build/gcc/build-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/opt/gcc-mingw/x86_64-w64-mingw32/lib -L/opt/gcc-mingw/mingw/lib -isystem /opt/gcc-mingw/x86_64-w64-mingw32/include -isystem /opt/gcc-mingw/mingw/include -B/opt/gcc-mingw/x86_64-w64-mingw32/bin/ -B/opt/gcc-mingw/x86_64-w64-mingw32/lib/ -isystem /opt/gcc-mingw/x86_64-w64-mingw32/include -isystem /opt/gcc-mingw/x86_64-w64-mingw32/sys-include-o conftest.exe -g -O2 -std=c++11 -fno-exceptions conftest.cpp -lm >&5 and succeeds. Note, it uses "-nostdinc++".
[Bug c++/115121] ++this is accepted in uninstantiated template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115121 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Last reconfirmed||2024-05-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115121 --- Comment #4 from Jonathan Wakely --- I've opened PR 115121 for the accepts-invalid compiler bug.
[Bug c++/115121] New: ++this is accepted in uninstantiated template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115121
Bug ID: 115121
Summary: ++this is accepted in uninstantiated template
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
template
struct iter
{
void operator++(int) {
auto tmp = *this;
++this;
return tmp;
}
};
This has a typo, it should be ++*this
I assume this compiles because `this` is dependent, but we could reject it
earlier. Incrementing `this` is never valid, it doesn't matter how the template
is instantiated.
[Bug tree-optimization/115120] New: Bad interaction between ivcanon and early break vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115120
Bug ID: 115120
Summary: Bad interaction between ivcanon and early break
vectorization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
Consider the following testcase on aarch64:
int arr[1024];
int *f()
{
int i;
for (i = 0; i < 1024; i++)
if (arr[i] == 42)
break;
return arr + i;
}
compiled with -O3 we get the following vector loop body:
.L2:
cmp x2, x1
beq .L9
.L6:
ldr q31, [x1]
add x1, x1, 16
mov v27.16b, v29.16b
mov v28.16b, v30.16b
cmeqv31.4s, v31.4s, v26.4s
add v29.4s, v29.4s, v24.4s
add v30.4s, v30.4s, v25.4s
umaxp v31.4s, v31.4s, v31.4s
fmovx3, d31
cbz x3, .L2
it's somewhat surprising that there are two vector adds, looking at the
optimized dump:
[local count: 1063004408]:
# vect_vec_iv_.6_28 = PHI <_29(10), { 0, 1, 2, 3 }(2)>
# vect_vec_iv_.7_33 = PHI <_34(10), { 1024, 1023, 1022, 1021 }(2)>
# ivtmp.18_19 = PHI
_34 = vect_vec_iv_.7_33 + { 4294967292, 4294967292, 4294967292, 4294967292 };
_29 = vect_vec_iv_.6_28 + { 4, 4, 4, 4 };
_25 = (void *) ivtmp.18_19;
vect__1.10_39 = MEM [(int *)_25];
mask_patt_9.11_41 = vect__1.10_39 == { 42, 42, 42, 42 };
if (mask_patt_9.11_41 != { 0, 0, 0, 0 })
goto ; [5.50%]
else
goto ; [94.50%]
we can see that there are two IV updates that got vectorized. It turns out
that
one of these comes from the ivcanon pass. If I add -fno-tree-loop-ivcanon we
instead get the following vector loop body:
.L2:
cmp x2, x1
beq .L9
.L6:
ldr q31, [x1]
add x1, x1, 16
mov v29.16b, v30.16b
add v30.4s, v30.4s, v27.4s
cmeqv31.4s, v31.4s, v28.4s
umaxp v31.4s, v31.4s, v31.4s
fmovx3, d31
cbz x3, .L2
which is much cleaner. Looking at the tree dumps, the ivcanon pass makes the
following transformation:
--- cddce2.tree 2024-05-16 13:49:10.426703350 +
+++ ivcanon.tree2024-05-16 13:49:17.678874925 +
@@ -4,6 +4,8 @@
int i;
int _1;
int * _8;
+ unsigned int ivtmp_11;
+ unsigned int ivtmp_12;
long unsigned int _13;
long unsigned int _15;
long unsigned int prephitmp_16;
@@ -12,6 +14,7 @@
[local count: 1063004408]:
# i_10 = PHI
+ # ivtmp_12 = PHI
_1 = arr[i_10];
if (_1 == 42)
goto ; [5.50%]
@@ -20,7 +23,8 @@
[local count: 1004539166]:
i_7 = i_10 + 1;
- if (i_7 != 1024)
+ ivtmp_11 = ivtmp_12 - 1;
+ if (ivtmp_11 != 0)
goto ; [98.93%]
else
goto ; [1.07%]
i.e. it introduces the backwards-counting IV. It seems in the general case
without vectorization ivopts then cleans this up and ensures we only have a
single IV.
In the vectorized case it seems this problem only shows up with early break
vectorization. Looking at a simple reduction, such as:
int a[1024];
int g()
{
int sum = 0;
for (int i = 0; i < 1024; i++)
sum += a[i];
return sum;
}
although we still have the backwards-counting IV in ifcvt:
[local count: 1063004408]:
# sum_9 = PHI
# i_11 = PHI
# ivtmp_8 = PHI
_1 = a[i_11];
sum_5 = _1 + sum_9;
i_6 = i_11 + 1;
ivtmp_7 = ivtmp_8 - 1;
if (ivtmp_7 != 0)
goto ; [98.99%]
else
goto ; [1.01%]
we end up with only scalar IVs after vectorization, and the backwards scalar IV
ends up getting deleted by dce6:
Deleting : ivtmp_7 = ivtmp_8 - 1;
I'm not sure what the right solution is but we should avoid having duplicated
IVs with early break vectorization.
[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jonathan Wakely --- It fails to compile if that member function is instantiated (which libstdc++ itself never does). /home/jwakely/gcc/15/include/c++/15.0.0/bits/unicode.h:805:11: error: increment of read-only location '(std::__unicode::__v15_1_0::_Grapheme_cluster_view >::_Iterator*)this' 805 | ++this; | ^~ /home/jwakely/gcc/15/include/c++/15.0.0/bits/unicode.h:805:11: error: lvalue required as increment operand But ++this could be rejected without treating it as a dependent expression. Anyway, I'll fix the library typo.
[Bug sanitizer/87875] Address sanitizer doen't work with nested functions with enabled stack-use-after-return check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87875 --- Comment #15 from Sebastien Bardeau --- I confirm that my duplicate bug report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110157 faces this issue in Fortran code; to my viewpoint it is not so useless to fix it. Anyway for the time being I can use again the sanitizer thanks to ASAN_OPTIONS='detect_stack_use_after_return=false'. Thanks.
[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-16 --- Comment #2 from Jonathan Wakely --- Which would be ++*this ++this shouldn't even compile.
[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 --- Comment #1 from Andrew Pinski --- No ++this is correct. We want to increment the iterator and not the what the iterator points too here.
[Bug c++/114850] co_await a async function which result type is std::unique_ptr<...> or shared_ptr in a initializer list causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114850 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Patrick Palka --- (In reply to Jeremy Pewterschmidt from comment #3) > This issue is no longer reproducible in GCC 14. > Should I mark this as `RESOLVED` ? Yes, the ICE disappeared after r14-8437-g44868e7298de50, so I reckon this is a dup of 109227. *** This bug has been marked as a duplicate of bug 109227 ***
[Bug c++/109227] coroutines: ICE in tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.cc:11067
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227 Patrick Palka changed: What|Removed |Added CC||jeremypewterschmidt at gmail dot c ||om --- Comment #9 from Patrick Palka --- *** Bug 114850 has been marked as a duplicate of this bug. ***
[Bug libstdc++/115119] New: Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119
Bug ID: 115119
Summary: Typo in
_Grapheme_cluster_view::_Iterator::operator++(int)
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: davidfromonline at gmail dot com
Target Milestone: ---
The following code in unicode.h:
```c++
constexpr _Iterator
operator++(int)
{
auto __tmp = *this;
++this;
return __tmp;
}
```
Should instead be:
```c++
constexpr _Iterator
operator++(int)
{
auto __tmp = *this;
++*this;
return __tmp;
}
```
(`++*this` instead of `++this`).
[Bug c++/114850] co_await a async function which result type is std::unique_ptr<...> or shared_ptr in a initializer list causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114850 --- Comment #3 from Jeremy Pewterschmidt --- This issue is no longer reproducible in GCC 14. Should I mark this as `RESOLVED` ?
[Bug target/115118] [15 Regression] 5-13% slowdown of 470.lbm on zen4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115118 Filip Kastl changed: What|Removed |Added Version|14.0|15.0 Target Milestone|--- |15.0
[Bug target/115118] New: [15 Regression] 5-13% slowdown of 470.lbm on zen4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115118 Bug ID: 115118 Summary: [15 Regression] 5-13% slowdown of 470.lbm on zen4 Product: gcc Version: 14.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: x86_64-linux Target: x86_64-linux As seen here https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=992.240.0 there is a 13% (only 5% on another machine where i replicated this) slowdown of the 470.lbm SPEC 2006 benchmark between commits r15-311-gf6ce85502eb2e4 r15-334-gbaf1a677955a4d This happens on Zen4 CPUs. I haven't seen the regression anywhere else. The compilation options are -Ofast -march=native -flto Here is also a graph with GCC 14 plotted to show that this is a 15 regression: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.3=1017.240.0&plot.4=992.240.0&; 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 middle-end/115091] Support value speculation in frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115091 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov --- (In reply to andi from comment #2) > > That said, I heard CPUs have prefetchers that recognize this kind of list > > walking. I wonder why they wouldn't then also be able to speculate the > > load value like you say. > > These are on the L2 or L3 level, not L1. This is about hiding L1 > latencies, which normally doesn't have a prefetcher. Richard is correct in the sense that Apple M1 CPUs do that. Intel is not holding the IPC crown these days ;)
[Bug target/113950] PowerPC, ICE with -O1 or higher compiling __builtin_vsx_splat_2di test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950 --- Comment #9 from Shivam Gupta --- Good explanation 👍 On Thu, 16 May 2024 at 7:32 PM, jeevitha at gcc dot gnu.org via Gcc-bugs < gcc-bugs@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950 > > Jeevitha changed: > >What|Removed |Added > > > Resolution|--- |FIXED > Status|ASSIGNED|RESOLVED > > --- Comment #8 from Jeevitha --- > Fixed, and all backports are done.
[Bug middle-end/96564] [11/12/13/14/15 Regression] New maybe use of uninitialized variable warning since r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564
--- Comment #19 from Aldy Hernandez ---
(In reply to Richard Biener from comment #17)
> Handling pointer-vs-pointer in ptrs_compare_unequal isn't enough since we
> have
>
> # PT = nonlocal null
> unsigned int * x_7(D) = x;
> ...
> # PT = null { D.2785 }
> a_9 = malloc (_2);
> if (a_9 == 0B)
> goto ; [0.04%]
> else
> goto ; [99.96%]
>
>[local count: 429496]:
> goto ; [100.00%]
>
>[local count: 1073312328]:
> if (x_7(D) != a_9)
>
> so querying points-to only has to consider both pointers being NULL. Now,
> I'm not sure how prange handles the above and whether or how it integrates
> knowledge from flow-insensitive points-to analysis.
prange currently does nothing different than what irange did. It's a first
step in providing points-to and propagating the information through the CFG
like we do for integer ranges. Or more precisely, prange is meant to be
nothing more than a pair of integer end points (not unlimited like
int_range_max), plus a value/mask pair.
>
> Aldy might know.
>
> I'm testing a patch enhancing ptrs_compare_unequal right now, also filling
> in a missing bit in points-to info.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #32 from Aldy Hernandez --- (In reply to r...@cebitec.uni-bielefeld.de from comment #31) > > --- Comment #29 from Aldy Hernandez --- > [...] > > Ok, what's the minimum configuration I need to build here? > > > > srcdir/configure --build=sparc-sun-solaris2.11 > > > > srcdir/configure --build=sparc-sun-solaris2.11 --without-gnu-as > > --without-gnu-ld > > > > ?? > > srcdir/configure --build=sparcv9-sun-solaris2.11 --without-gnu-as > --with-as=/usr/bin/as --without-gnu-ld --with-ld=/usr/bin/ld OK, I'll add this to my notes. Thanks. BTW, the above seems like it would be a perfect thing to put in /etc/motd :). > > should do the trick. > > Preferably prepend /usr/gnu/bin to PATH. > > > I really don't care how it builds, I just want the bare minimum so I can > > bootstrap and run tests. > > > > A minor rant, but why can't all this be set up automatically in the compile > > farm machines? Keeping track of minor nuances of each architecture is > > distracting. They should all be set up, whether by setting default paths in > > Agreed, but you always run into stuff like this when leaving Linux (like > AIX, HP-UX, or macOS). PATHs won't help much for reasons explained in > install.texi. > > > /etc/profile or whatever, or by having the relevant patches in GCC's source > > base, such that they work with src/configure && make. > > But what should be the default: GNU or native tools? You have choices > here and need to decide what you need/want. No one can do this for you. My guess would be to use gnu tools if available, cause those would be "guaranteed" to work correctly to build gcc? > > > I know this isn't your fault, but if more cfarm boxes where set up to go > > with > > no surprises, I'd add more boxen to my testing harness. > > Well, I *did* set up the Solaris cfarm systems, actually ;-) I see your > point, but things are not that simple unfortunately. And GCC's > configure doesn't need to cater to users of the cfarm only... > > Some of the issues (like the need for --build) have been caused by > upstream (like the config.guess maintainers that refuse to listen to > reason ;-). I thought about improving the --with-as/ld situation; maybe > something can be done there. Thanks for the explanation.
[Bug libstdc++/115117] New: std::exp(Inf) result invalid with --disable-c99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115117
Bug ID: 115117
Summary: std::exp(Inf) result invalid with --disable-c99
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tomas.kalibera at gmail dot com
Target Milestone: ---
Created attachment 58218
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58218&action=edit
Example program ("im(e^inf):" should be 0, but is not with --disable-c99)
When the C++ library is built without C99 support (e.g. via passing
--disable-c99 to configure of gcc), the result of complex std::exp(Inf) is
incorrect, the imaginary part is NaN, but it should be zero.
It seems this is caused by this code in "complex", which doesn't handle special
cases:
// 26.2.8/3 exp(__z): Returns the complex base e exponential of x
template
inline complex<_Tp>
__complex_exp(const complex<_Tp>& __z)
{ return std::polar<_Tp>(exp(__z.real()), __z.imag()); }
that calls into:
template
inline complex<_Tp>
polar(const _Tp& __rho, const _Tp& __theta)
{
__glibcxx_assert( __rho >= 0 );
return complex<_Tp>(__rho * cos(__theta), __rho * sin(__theta));
}
where __rho is Inf, so the imaginary part becomes Inf * 0.
For example, the glibc implementation handles this special case explicitly as
follows (./math/s_cexp_template.c):
else if (__glibc_likely (rcls == FP_INFINITE))
{
/* Real part is infinite. */
if (__glibc_likely (icls >= FP_ZERO))
{
/* Imaginary part is finite. */
FLOAT value = signbit (__real__ x) ? 0 : M_HUGE_VAL;
if (icls == FP_ZERO)
{
/* Imaginary part is 0.0. */
__real__ retval = value;
__imag__ retval = __imag__ x;
}
I've this problem happen via _GLIBCXX11_USE_C99_COMPLEX being disabled by
accident, which still has to be investigated, but --disable-c99 reproduces it.
Example program from Andrew Johnson is attached.
I can reproduce the problem on Windows and Linux (on Windows I get nan, on
Linux I get -nan).
[Bug target/113950] PowerPC, ICE with -O1 or higher compiling __builtin_vsx_splat_2di test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950 Jeevitha changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jeevitha --- Fixed, and all backports are done.
[Bug target/113950] PowerPC, ICE with -O1 or higher compiling __builtin_vsx_splat_2di test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950 --- Comment #7 from Jeevitha --- In GCC 11, we encountered a different issue that didn't result in an ICE. The following is the error message in GCC 11: error: too few arguments to function '__builtin_vsx_splat_2di' 11 | vsll_result = __builtin_vsx_splat_2di (sll_arg1); // ISSUE The error indicated a shortage of arguments for the built-in function. It expects two arguments because the function prototype is different in GCC 11 compared to GCC 12, 13, and 14. I have found that the commit responsible for changing the function prototype was made by Bill Schmidt (commit hash: d08236359eb22918ba067489edcec02857109d09). In this commit, he introduced new built-in functionality, where the function prototype is sourced from rs6000-builtin-new.def, which includes the following declaration: const vsll __builtin_vsx_splat_2di (signed long long); Prior to this commit ie, in gcc11, the function prototype was sourced from rs6000-builtin.def and included two arguments: /* 2 argument VSX builtins. */ BU_VSX_2 (SPLAT_2DI, "splat_2di", CONST, vsx_splat_v2di) These changes are controlled by the setting new_builtins_are_live. Bill made this change in his commit by adjusting this setting. Due to the above prototype changes, we are not backporting to GCC 11.
[Bug tree-optimization/113787] [12/13/14 Regression] Wrong code at -O with ipa-modref on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787 Jan Hubicka changed: What|Removed |Added Summary|[12/13/14/15 Regression]|[12/13/14 Regression] Wrong |Wrong code at -O with |code at -O with ipa-modref |ipa-modref on aarch64 |on aarch64 --- Comment #22 from Jan Hubicka --- Fixed on trunk so far
[Bug tree-optimization/113787] [12/13/14/15 Regression] Wrong code at -O with ipa-modref on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787 --- Comment #21 from GCC Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:96d53252aefcbc2fe419c4c3b4bcd3fc03d4d187 commit r15-581-g96d53252aefcbc2fe419c4c3b4bcd3fc03d4d187 Author: Jan Hubicka Date: Thu May 16 15:33:55 2024 +0200 Fix points_to_local_or_readonly_memory_p wrt TARGET_MEM_REF TARGET_MEM_REF can be used to offset constant base into a memory object (to produce lea instruction). This confuses points_to_local_or_readonly_memory_p which treats the constant address as a base of the access. Bootstrapped/regtsted x86_64-linux, comitted. Honza gcc/ChangeLog: PR ipa/113787 * ipa-fnsummary.cc (points_to_local_or_readonly_memory_p): Do not look into TARGET_MEM_REFS with constant opreand 0. gcc/testsuite/ChangeLog: * gcc.c-torture/execute/pr113787.c: New test.
[Bug other/30920] Incorrect splaying that not assures the caching property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30920 Andrew Pinski changed: What|Removed |Added Keywords||compile-time-hog --- Comment #4 from Andrew Pinski --- I suspect one reason why this has not mattered that much is spray tree has not been in the top area when folks profile the compiler these days. Not that we should improve here, just improving here is not going to make any dent for most code.
[Bug other/30920] Incorrect splaying that not assures the caching property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30920
Anton Lorenzen changed:
What|Removed |Added
CC||anton.lorenzen at ed dot ac.uk
--- Comment #3 from Anton Lorenzen ---
Bumping this bug since it still applies: The splay tree implementations in
`typed-splay-tree.h` as well as `libiberty/splay-tree.c` and
`libgomp/splay-tree.c` do not implement the original algorithm of Sleater and
Tarjan. In contrast, the implementations in `splay-tree-utils.tcc` and
`bitmap.cc` seem to be correct.
It is unclear what (amortized) efficiency bounds apply to the incorrect
implementations. However, it seems likely that they should perform worse than
the textbook algorithm and they are mentioned in
https://gcc.gnu.org/wiki/Speedup_areas (although this could also be due the use
of function pointers for comparison, which in particular makes integer keys
much slower than necessary). While Ian Blanes comments earlier in this thread
that the previous implementation was even slower due to its recursive nature,
the correct implementations mentioned above are not recursive and should show
improved performance over the incorrect ones.
We re-discovered this bug after Gabriel Scherer pointed us to a Master Thesis
attempting to prove the former implementations above correct ("Formal
Verification of Pointer-Based Splay Trees in Iris"). It is unclear whether the
author of this thesis was aware that these implementations do not implement the
textbook algorithm. In contrast, we could prove the textbook implementation
correct
(https://www.microsoft.com/en-us/research/uploads/prod/2023/07/fiptree-tr-v4.pdf,
accepted at PLDI'24). I would be happy to contribute a patch replacing the
incorrect implementation by a correct one if there is demand for that.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #29 from Aldy Hernandez --- [...] > Ok, what's the minimum configuration I need to build here? > > srcdir/configure --build=sparc-sun-solaris2.11 > > srcdir/configure --build=sparc-sun-solaris2.11 --without-gnu-as > --without-gnu-ld > > ?? srcdir/configure --build=sparcv9-sun-solaris2.11 --without-gnu-as --with-as=/usr/bin/as --without-gnu-ld --with-ld=/usr/bin/ld should do the trick. Preferably prepend /usr/gnu/bin to PATH. > I really don't care how it builds, I just want the bare minimum so I can > bootstrap and run tests. > > A minor rant, but why can't all this be set up automatically in the compile > farm machines? Keeping track of minor nuances of each architecture is > distracting. They should all be set up, whether by setting default paths in Agreed, but you always run into stuff like this when leaving Linux (like AIX, HP-UX, or macOS). PATHs won't help much for reasons explained in install.texi. > /etc/profile or whatever, or by having the relevant patches in GCC's source > base, such that they work with src/configure && make. But what should be the default: GNU or native tools? You have choices here and need to decide what you need/want. No one can do this for you. > I know this isn't your fault, but if more cfarm boxes where set up to go with > no surprises, I'd add more boxen to my testing harness. Well, I *did* set up the Solaris cfarm systems, actually ;-) I see your point, but things are not that simple unfortunately. And GCC's configure doesn't need to cater to users of the cfarm only... Some of the issues (like the need for --build) have been caused by upstream (like the config.guess maintainers that refuse to listen to reason ;-). I thought about improving the --with-as/ld situation; maybe something can be done there.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #30 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #29) > > > gmake[3]: Leaving directory '/home/aldyh/bld/clean' > > > Comparing stages 2 and 3 > > > Bootstrap comparison failure! > > > gcc/tree-vect-stmts.o differs > > > > I'm not seeing this myself. > > Dunno. It could be the particular revision was broken?? Interestingly, I just did the following with latest trunk, and sparc bootstrapped and is running tests: configure && make -j128 && make check -j128 -k No --with-something-rather or path tweaks or --build=blah. *shrugs*
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #29 from Aldy Hernandez --- (In reply to r...@cebitec.uni-bielefeld.de from comment #28) > > --- Comment #27 from Aldy Hernandez --- > > This is in cfarm216.cfarm.et: > > > > aldyh@s11-sparc:~/bld/clean$ hostname > > s11-sparc.cfarm > > aldyh@s11-sparc:~/bld/clean$ uname -a > > SunOS s11-sparc.cfarm 5.11 11.4.68.164.2 sun4v sparc sun4v logical-domain > > aldyh@s11-sparc:~/bld/clean$ ~/src/clean/configure && gmake -j80 && gmake > > check > > -k -j80 > > You need to be careful that the assembler and linker actually used match > gcc's idea thereof: > > https://gcc.gnu.org/install/specific.html#x-x-solaris2 > > Best specify all of --build sparcv9-sun-solaris2.11 (if you're > bootstrapping with a 64-bit-default gcc/g++) and > > --with-as=/usr/gnu/bin/as (or /opt/cfarm/binutils-latest-64/bin/as) > --with-gnu-as > > (/usr/bin/as works too, but you need to specify both the path and > --without-gnu-as) > > --with-ld=/usr/bin/ld > --without-gnu-ld > > Having two different assemblers and linkers (Solaris and GNU) available > can lead to confusion if you rely on PATH alone. Ok, what's the minimum configuration I need to build here? srcdir/configure --build=sparc-sun-solaris2.11 srcdir/configure --build=sparc-sun-solaris2.11 --without-gnu-as --without-gnu-ld ?? I really don't care how it builds, I just want the bare minimum so I can bootstrap and run tests. A minor rant, but why can't all this be set up automatically in the compile farm machines? Keeping track of minor nuances of each architecture is distracting. They should all be set up, whether by setting default paths in /etc/profile or whatever, or by having the relevant patches in GCC's source base, such that they work with src/configure && make. I know this isn't your fault, but if more cfarm boxes where set up to go with no surprises, I'd add more boxen to my testing harness. > > > gmake[3]: Leaving directory '/home/aldyh/bld/clean' > > Comparing stages 2 and 3 > > Bootstrap comparison failure! > > gcc/tree-vect-stmts.o differs > > I'm not seeing this myself. Dunno. It could be the particular revision was broken??
[Bug tree-optimization/61818] unused code fails to be removed after dom1, thread updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61818 Bug 61818 depends on bug 13962, which changed state. Bug 13962 Summary: [tree-ssa] make "fold" use alias information to optimize pointer comparisons https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/113164] [missed optimization] struct fields should not alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113164 Bug 113164 depends on bug 13962, which changed state. Bug 13962 Summary: [tree-ssa] make "fold" use alias information to optimize pointer comparisons https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/13962] [tree-ssa] make "fold" use alias information to optimize pointer comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Richard Biener --- I'm closing this as fixed now. The feature is there, improvements can be made I guess but first get testcases that are not handled (combine with prange info is one item).
[Bug middle-end/65686] [5/6/7 regression] inconsistent warning maybe-uninitialized: warn about 'unsigned', not warn about 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65686 Bug 65686 depends on bug 13962, which changed state. Bug 13962 Summary: [tree-ssa] make "fold" use alias information to optimize pointer comparisons https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 13962, which changed state. Bug 13962 Summary: [tree-ssa] make "fold" use alias information to optimize pointer comparisons https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/96564] [11/12/13/14/15 Regression] New maybe use of uninitialized variable warning since r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564 --- Comment #18 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f3e5f4c58591f5dacdd14a65ec47bbe310df02a0 commit r15-580-gf3e5f4c58591f5dacdd14a65ec47bbe310df02a0 Author: Richard Biener Date: Mon Mar 11 11:17:32 2024 +0100 tree-optimization/13962 - handle ptr-ptr compares in ptrs_compare_unequal Now that we handle pt.null conservatively we can implement the missing tracking of constant pool entries (aka STRING_CST) and handle ptr-ptr compares using points-to info in ptrs_compare_unequal. PR tree-optimization/13962 PR tree-optimization/96564 * tree-ssa-alias.h (pt_solution::const_pool): New flag. * tree-ssa-alias.cc (ptrs_compare_unequal): Handle pointer-pointer compares. (dump_points_to_solution): Dump the const_pool flag, fix guard of flag dumping. * gimple-pretty-print.cc (pp_points_to_solution): Likewise. * tree-ssa-structalias.cc (find_what_var_points_to): Set the const_pool flag for STRING. (pt_solution_ior_into): Handle the const_pool flag. (ipa_escaped_pt): Initialize it. * gcc.dg/tree-ssa/alias-39.c: New testcase. * g++.dg/vect/pr68145.cc: Use -fno-tree-pta to avoid UB to manifest in transforms no longer vectorizing this testcase for an ICE.
[Bug tree-optimization/13962] [tree-ssa] make "fold" use alias information to optimize pointer comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962 --- Comment #16 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f3e5f4c58591f5dacdd14a65ec47bbe310df02a0 commit r15-580-gf3e5f4c58591f5dacdd14a65ec47bbe310df02a0 Author: Richard Biener Date: Mon Mar 11 11:17:32 2024 +0100 tree-optimization/13962 - handle ptr-ptr compares in ptrs_compare_unequal Now that we handle pt.null conservatively we can implement the missing tracking of constant pool entries (aka STRING_CST) and handle ptr-ptr compares using points-to info in ptrs_compare_unequal. PR tree-optimization/13962 PR tree-optimization/96564 * tree-ssa-alias.h (pt_solution::const_pool): New flag. * tree-ssa-alias.cc (ptrs_compare_unequal): Handle pointer-pointer compares. (dump_points_to_solution): Dump the const_pool flag, fix guard of flag dumping. * gimple-pretty-print.cc (pp_points_to_solution): Likewise. * tree-ssa-structalias.cc (find_what_var_points_to): Set the const_pool flag for STRING. (pt_solution_ior_into): Handle the const_pool flag. (ipa_escaped_pt): Initialize it. * gcc.dg/tree-ssa/alias-39.c: New testcase. * g++.dg/vect/pr68145.cc: Use -fno-tree-pta to avoid UB to manifest in transforms no longer vectorizing this testcase for an ICE.
[Bug tree-optimization/113583] Main loop in 519.lbm not vectorized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583 --- Comment #19 from Richard Biener --- (In reply to Robin Dapp from comment #18) [...] > Regarding the mentioned element-wise costing how should we proceed here? > I'm going to remove the hunk in question, run SPEC2017 on x86 and post a > patch in order to get some data and basis for discussion. Yeah, I think this hunk was put in as a stopgap solution.
Practical Coding on IBM's Quantum Computers - 4-Week Workshop (Asynchronous)
Four-Week Workshop.With a focus on practical quantum algorithms.Hands-On Experience with Qiskit and IBM Quantum SystemsOne Month Asynchronous Workshop delivered on Canvas, featuring more than 200 participants from 80 top universities and companies. Featured Events: IBM's Quantum Computer Programming: Hands-On Workshop (Asynchronous) | VENUE NAME DEFAULT VAL | 2024-05-18T08:00:00Z https://www.eventbrite.com Unsubscribe: https://www.eventbrite.co.uk/organizations/missive/activity/unsubscribe/?p=ABIdvVuaLv7zakaUXlc6Bzn3xliRhYl7RIUq0GWQaqdZDCCBMVmq6Uwi35havuWY1I8jewyRkTorjY4ESXRbBV8vZG_F3Sk89SI68bHug-k9ZvpvcxscUWMEMpTay_3cIlDq5f5DrcV1v3T3tQifOtccwb9eJufyEyFjoswvvapqryWWtpCB4NgqajSFgvjN15Nx6tFlDZI44_GCUH2M4Cj4P2NIztoDOtKbbY3xNhFCguslesFXZ_Bzu244LX7A-oz5CNe3IGQl&c=28454879&co=77311038
[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
--- Comment #20 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:d4dee347b3fe1982bab26485ff31cd039c9df010
commit r15-577-gd4dee347b3fe1982bab26485ff31cd039c9df010
Author: Pan Li
Date: Wed May 15 10:14:06 2024 +0800
Vect: Support new IFN SAT_ADD for unsigned vector int
For vectorize, we leverage the existing vect pattern recog to find
the pattern similar to scalar and let the vectorizer to perform
the rest part for standard name usadd3 in vector mode.
The riscv vector backend have insn "Vector Single-Width Saturating
Add and Subtract" which can be leveraged when expand the usadd3
in vector mode. For example:
void vec_sat_add_u64 (uint64_t *out, uint64_t *x, uint64_t *y, unsigned n)
{
unsigned i;
for (i = 0; i < n; i++)
out[i] = (x[i] + y[i]) | (- (uint64_t)((uint64_t)(x[i] + y[i]) <
x[i]));
}
Before this patch:
void vec_sat_add_u64 (uint64_t *out, uint64_t *x, uint64_t *y, unsigned n)
{
...
_80 = .SELECT_VL (ivtmp_78, POLY_INT_CST [2, 2]);
ivtmp_58 = _80 * 8;
vect__4.7_61 = .MASK_LEN_LOAD (vectp_x.5_59, 64B, { -1, ... }, _80, 0);
vect__6.10_65 = .MASK_LEN_LOAD (vectp_y.8_63, 64B, { -1, ... }, _80, 0);
vect__7.11_66 = vect__4.7_61 + vect__6.10_65;
mask__8.12_67 = vect__4.7_61 > vect__7.11_66;
vect__12.15_72 = .VCOND_MASK (mask__8.12_67, { 18446744073709551615,
... }, vect__7.11_66);
.MASK_LEN_STORE (vectp_out.16_74, 64B, { -1, ... }, _80, 0,
vect__12.15_72);
vectp_x.5_60 = vectp_x.5_59 + ivtmp_58;
vectp_y.8_64 = vectp_y.8_63 + ivtmp_58;
vectp_out.16_75 = vectp_out.16_74 + ivtmp_58;
ivtmp_79 = ivtmp_78 - _80;
...
}
After this patch:
void vec_sat_add_u64 (uint64_t *out, uint64_t *x, uint64_t *y, unsigned n)
{
...
_62 = .SELECT_VL (ivtmp_60, POLY_INT_CST [2, 2]);
ivtmp_46 = _62 * 8;
vect__4.7_49 = .MASK_LEN_LOAD (vectp_x.5_47, 64B, { -1, ... }, _62, 0);
vect__6.10_53 = .MASK_LEN_LOAD (vectp_y.8_51, 64B, { -1, ... }, _62, 0);
vect__12.11_54 = .SAT_ADD (vect__4.7_49, vect__6.10_53);
.MASK_LEN_STORE (vectp_out.12_56, 64B, { -1, ... }, _62, 0,
vect__12.11_54);
...
}
The below test suites are passed for this patch.
* The riscv fully regression tests.
* The x86 bootstrap tests.
* The x86 fully regression tests.
PR target/51492
PR target/112600
gcc/ChangeLog:
* tree-vect-patterns.cc (gimple_unsigned_integer_sat_add): New
func decl generated by match.pd match.
(vect_recog_sat_add_pattern): New func impl to recog the pattern
for unsigned SAT_ADD.
Signed-off-by: Pan Li
[Bug middle-end/112600] Failed to optimize saturating addition using __builtin_add_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112600
--- Comment #7 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:d4dee347b3fe1982bab26485ff31cd039c9df010
commit r15-577-gd4dee347b3fe1982bab26485ff31cd039c9df010
Author: Pan Li
Date: Wed May 15 10:14:06 2024 +0800
Vect: Support new IFN SAT_ADD for unsigned vector int
For vectorize, we leverage the existing vect pattern recog to find
the pattern similar to scalar and let the vectorizer to perform
the rest part for standard name usadd3 in vector mode.
The riscv vector backend have insn "Vector Single-Width Saturating
Add and Subtract" which can be leveraged when expand the usadd3
in vector mode. For example:
void vec_sat_add_u64 (uint64_t *out, uint64_t *x, uint64_t *y, unsigned n)
{
unsigned i;
for (i = 0; i < n; i++)
out[i] = (x[i] + y[i]) | (- (uint64_t)((uint64_t)(x[i] + y[i]) <
x[i]));
}
Before this patch:
void vec_sat_add_u64 (uint64_t *out, uint64_t *x, uint64_t *y, unsigned n)
{
...
_80 = .SELECT_VL (ivtmp_78, POLY_INT_CST [2, 2]);
ivtmp_58 = _80 * 8;
vect__4.7_61 = .MASK_LEN_LOAD (vectp_x.5_59, 64B, { -1, ... }, _80, 0);
vect__6.10_65 = .MASK_LEN_LOAD (vectp_y.8_63, 64B, { -1, ... }, _80, 0);
vect__7.11_66 = vect__4.7_61 + vect__6.10_65;
mask__8.12_67 = vect__4.7_61 > vect__7.11_66;
vect__12.15_72 = .VCOND_MASK (mask__8.12_67, { 18446744073709551615,
... }, vect__7.11_66);
.MASK_LEN_STORE (vectp_out.16_74, 64B, { -1, ... }, _80, 0,
vect__12.15_72);
vectp_x.5_60 = vectp_x.5_59 + ivtmp_58;
vectp_y.8_64 = vectp_y.8_63 + ivtmp_58;
vectp_out.16_75 = vectp_out.16_74 + ivtmp_58;
ivtmp_79 = ivtmp_78 - _80;
...
}
After this patch:
void vec_sat_add_u64 (uint64_t *out, uint64_t *x, uint64_t *y, unsigned n)
{
...
_62 = .SELECT_VL (ivtmp_60, POLY_INT_CST [2, 2]);
ivtmp_46 = _62 * 8;
vect__4.7_49 = .MASK_LEN_LOAD (vectp_x.5_47, 64B, { -1, ... }, _62, 0);
vect__6.10_53 = .MASK_LEN_LOAD (vectp_y.8_51, 64B, { -1, ... }, _62, 0);
vect__12.11_54 = .SAT_ADD (vect__4.7_49, vect__6.10_53);
.MASK_LEN_STORE (vectp_out.12_56, 64B, { -1, ... }, _62, 0,
vect__12.11_54);
...
}
The below test suites are passed for this patch.
* The riscv fully regression tests.
* The x86 bootstrap tests.
* The x86 fully regression tests.
PR target/51492
PR target/112600
gcc/ChangeLog:
* tree-vect-patterns.cc (gimple_unsigned_integer_sat_add): New
func decl generated by match.pd match.
(vect_recog_sat_add_pattern): New func impl to recog the pattern
for unsigned SAT_ADD.
Signed-off-by: Pan Li
[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
--- Comment #19 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:52b0536710ff3f3ace72ab00ce9ef6c630cd1183
commit r15-576-g52b0536710ff3f3ace72ab00ce9ef6c630cd1183
Author: Pan Li
Date: Wed May 15 10:14:05 2024 +0800
Internal-fn: Support new IFN SAT_ADD for unsigned scalar int
This patch would like to add the middle-end presentation for the
saturation add. Aka set the result of add to the max when overflow.
It will take the pattern similar as below.
SAT_ADD (x, y) => (x + y) | (-(TYPE)((TYPE)(x + y) < x))
Take uint8_t as example, we will have:
* SAT_ADD (1, 254) => 255.
* SAT_ADD (1, 255) => 255.
* SAT_ADD (2, 255) => 255.
* SAT_ADD (255, 255) => 255.
Given below example for the unsigned scalar integer uint64_t:
uint64_t sat_add_u64 (uint64_t x, uint64_t y)
{
return (x + y) | (- (uint64_t)((uint64_t)(x + y) < x));
}
Before this patch:
uint64_t sat_add_uint64_t (uint64_t x, uint64_t y)
{
long unsigned int _1;
_Bool _2;
long unsigned int _3;
long unsigned int _4;
uint64_t _7;
long unsigned int _10;
__complex__ long unsigned int _11;
;; basic block 2, loop depth 0
;;pred: ENTRY
_11 = .ADD_OVERFLOW (x_5(D), y_6(D));
_1 = REALPART_EXPR <_11>;
_10 = IMAGPART_EXPR <_11>;
_2 = _10 != 0;
_3 = (long unsigned int) _2;
_4 = -_3;
_7 = _1 | _4;
return _7;
;;succ: EXIT
}
After this patch:
uint64_t sat_add_uint64_t (uint64_t x, uint64_t y)
{
uint64_t _7;
;; basic block 2, loop depth 0
;;pred: ENTRY
_7 = .SAT_ADD (x_5(D), y_6(D)); [tail call]
return _7;
;;succ: EXIT
}
The below tests are passed for this patch:
1. The riscv fully regression tests.
3. The x86 bootstrap tests.
4. The x86 fully regression tests.
PR target/51492
PR target/112600
gcc/ChangeLog:
* internal-fn.cc (commutative_binary_fn_p): Add type IFN_SAT_ADD
to the return true switch case(s).
* internal-fn.def (SAT_ADD): Add new signed optab SAT_ADD.
* match.pd: Add unsigned SAT_ADD match(es).
* optabs.def (OPTAB_NL): Remove fixed-point limitation for
us/ssadd.
* tree-ssa-math-opts.cc (gimple_unsigned_integer_sat_add): New
extern func decl generated in match.pd match.
(match_saturation_arith): New func impl to match the saturation
arith.
(math_opts_dom_walker::after_dom_children): Try match saturation
arith when IOR expr.
Signed-off-by: Pan Li
[Bug middle-end/112600] Failed to optimize saturating addition using __builtin_add_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112600
--- Comment #6 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:52b0536710ff3f3ace72ab00ce9ef6c630cd1183
commit r15-576-g52b0536710ff3f3ace72ab00ce9ef6c630cd1183
Author: Pan Li
Date: Wed May 15 10:14:05 2024 +0800
Internal-fn: Support new IFN SAT_ADD for unsigned scalar int
This patch would like to add the middle-end presentation for the
saturation add. Aka set the result of add to the max when overflow.
It will take the pattern similar as below.
SAT_ADD (x, y) => (x + y) | (-(TYPE)((TYPE)(x + y) < x))
Take uint8_t as example, we will have:
* SAT_ADD (1, 254) => 255.
* SAT_ADD (1, 255) => 255.
* SAT_ADD (2, 255) => 255.
* SAT_ADD (255, 255) => 255.
Given below example for the unsigned scalar integer uint64_t:
uint64_t sat_add_u64 (uint64_t x, uint64_t y)
{
return (x + y) | (- (uint64_t)((uint64_t)(x + y) < x));
}
Before this patch:
uint64_t sat_add_uint64_t (uint64_t x, uint64_t y)
{
long unsigned int _1;
_Bool _2;
long unsigned int _3;
long unsigned int _4;
uint64_t _7;
long unsigned int _10;
__complex__ long unsigned int _11;
;; basic block 2, loop depth 0
;;pred: ENTRY
_11 = .ADD_OVERFLOW (x_5(D), y_6(D));
_1 = REALPART_EXPR <_11>;
_10 = IMAGPART_EXPR <_11>;
_2 = _10 != 0;
_3 = (long unsigned int) _2;
_4 = -_3;
_7 = _1 | _4;
return _7;
;;succ: EXIT
}
After this patch:
uint64_t sat_add_uint64_t (uint64_t x, uint64_t y)
{
uint64_t _7;
;; basic block 2, loop depth 0
;;pred: ENTRY
_7 = .SAT_ADD (x_5(D), y_6(D)); [tail call]
return _7;
;;succ: EXIT
}
The below tests are passed for this patch:
1. The riscv fully regression tests.
3. The x86 bootstrap tests.
4. The x86 fully regression tests.
PR target/51492
PR target/112600
gcc/ChangeLog:
* internal-fn.cc (commutative_binary_fn_p): Add type IFN_SAT_ADD
to the return true switch case(s).
* internal-fn.def (SAT_ADD): Add new signed optab SAT_ADD.
* match.pd: Add unsigned SAT_ADD match(es).
* optabs.def (OPTAB_NL): Remove fixed-point limitation for
us/ssadd.
* tree-ssa-math-opts.cc (gimple_unsigned_integer_sat_add): New
extern func decl generated in match.pd match.
(match_saturation_arith): New func impl to match the saturation
arith.
(math_opts_dom_walker::after_dom_children): Try match saturation
arith when IOR expr.
Signed-off-by: Pan Li
[Bug ada/115106] [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_rehash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106 Iain Sandoe changed: What|Removed |Added Build|i386-pc-solaris2.11 |i386-pc-solaris2.11, ||i686-darwin Host|i386-pc-solaris2.11 |i386-pc-solaris2.11, ||i686-darwin Target|i386-pc-solaris2.11 |i386-pc-solaris2.11, ||i686-darwin --- Comment #4 from Iain Sandoe --- likewise, x86_64 seems unaffected on the same OS versions (even on the same h/w).
[Bug libstdc++/115099] compilation error: format thread::id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115099 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #1 from Jiang An --- I guess we shouldn't include in . There should be far more simple ways to obtain thread::id's text representation.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #27 from Aldy Hernandez --- > This is in cfarm216.cfarm.et: > > aldyh@s11-sparc:~/bld/clean$ hostname > s11-sparc.cfarm > aldyh@s11-sparc:~/bld/clean$ uname -a > SunOS s11-sparc.cfarm 5.11 11.4.68.164.2 sun4v sparc sun4v logical-domain > aldyh@s11-sparc:~/bld/clean$ ~/src/clean/configure && gmake -j80 && gmake > check > -k -j80 You need to be careful that the assembler and linker actually used match gcc's idea thereof: https://gcc.gnu.org/install/specific.html#x-x-solaris2 Best specify all of --build sparcv9-sun-solaris2.11 (if you're bootstrapping with a 64-bit-default gcc/g++) and --with-as=/usr/gnu/bin/as (or /opt/cfarm/binutils-latest-64/bin/as) --with-gnu-as (/usr/bin/as works too, but you need to specify both the path and --without-gnu-as) --with-ld=/usr/bin/ld --without-gnu-ld Having two different assemblers and linkers (Solaris and GNU) available can lead to confusion if you rely on PATH alone. > gmake[3]: Leaving directory '/home/aldyh/bld/clean' > Comparing stages 2 and 3 > Bootstrap comparison failure! > gcc/tree-vect-stmts.o differs I'm not seeing this myself.
[Bug ada/115106] [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_rehash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #3 from Iain Sandoe --- *** Bug 115113 has been marked as a duplicate of this bug. ***
[Bug ada/115113] [15 Regression] Ada bootstrap fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115113 Iain Sandoe changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Iain Sandoe --- Rainer's bisect was quicker than mine! *** This bug has been marked as a duplicate of bug 115106 ***
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #27 from Aldy Hernandez --- (In reply to r...@cebitec.uni-bielefeld.de from comment #26) > > --- Comment #25 from Aldy Hernandez --- > > prange has been enabled again, after testing on x86-64 and ppc64le linux. > > Aarch has no space to run tests on the compile farm, and sparc bootstrap was > > already broken. > > Huh? Current trunk bootstraps just fine on Solaris/SPARC without any > patches. What issue do you see? > > Besides, there *is* a Solaris/SPARC system in the cfarm (cfarm216), so > you can try for yourself. commit 5609d77e683944439fae38323ecabc44a1eb4671 (HEAD -> clean) Author: Christoph Müllner Date: Wed May 15 01:34:54 2024 +0200 RISC-V: Test cbo.zero expansion for rv32 We had an issue when expanding via cmo-zero for RV32. This was fixed upstream, but we don't have a RV32 test. Therefore, this patch introduces such a test. gcc/testsuite/ChangeLog: * gcc.target/riscv/cmo-zicboz-zic64-1.c: Fix for rv32. Signed-off-by: Christoph Müllner This is in cfarm216.cfarm.et: aldyh@s11-sparc:~/bld/clean$ hostname s11-sparc.cfarm aldyh@s11-sparc:~/bld/clean$ uname -a SunOS s11-sparc.cfarm 5.11 11.4.68.164.2 sun4v sparc sun4v logical-domain aldyh@s11-sparc:~/bld/clean$ ~/src/clean/configure && gmake -j80 && gmake check -k -j80 ... ... gmake[2]: Entering directory '/home/aldyh/bld/clean' gmake[3]: Entering directory '/home/aldyh/bld/clean' rm -f stage_current gmake[3]: Leaving directory '/home/aldyh/bld/clean' Comparing stages 2 and 3 Bootstrap comparison failure! gcc/tree-vect-stmts.o differs gmake[2]: *** [Makefile:26649: compare] Error 1 gmake[2]: Leaving directory '/home/aldyh/bld/clean' gmake[1]: *** [Makefile:26629: stage3-bubble] Error 2 gmake[1]: Leaving directory '/home/aldyh/bld/clean' gmake: *** [Makefile:1099: all] Error 2 aldyh@s11-sparc:~/bld/clean$
[Bug middle-end/96564] [11/12/13/14/15 Regression] New maybe use of uninitialized variable warning since r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2020-08-11 00:00:00 |2024-5-16
CC||aldyh at gcc dot gnu.org
--- Comment #17 from Richard Biener ---
Handling pointer-vs-pointer in ptrs_compare_unequal isn't enough since we have
# PT = nonlocal null
unsigned int * x_7(D) = x;
...
# PT = null { D.2785 }
a_9 = malloc (_2);
if (a_9 == 0B)
goto ; [0.04%]
else
goto ; [99.96%]
[local count: 429496]:
goto ; [100.00%]
[local count: 1073312328]:
if (x_7(D) != a_9)
so querying points-to only has to consider both pointers being NULL. Now,
I'm not sure how prange handles the above and whether or how it integrates
knowledge from flow-insensitive points-to analysis.
Aldy might know.
I'm testing a patch enhancing ptrs_compare_unequal right now, also filling
in a missing bit in points-to info.
[Bug driver/80182] accidently invoked `gcc -lm -o file.c` which deletes file.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80182 --- Comment #8 from Peter Damianov --- This might arguably actually be a BFD linker problem. Both lld and mold don't have the problem for the example. Gold also has the same issue.
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
--- Comment #6 from Francois-Xavier Coudert ---
So the var_decl in question is fpstate.0:
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1035003f0 precision:8 min max
pointer_to_this >
BLK
size
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1036c4b28
domain
DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1036c4a80 precision:64 min max >
pointer_to_this >
addressable used ignored BLK s.f90:10:17 size
unit-size
align:8 warn_if_not_align:0 context >
And if I look at the tree dump, it seems the variable is indeed not created
correctly:
__attribute__((fn spec (". w ")))
void my_sub (struct __class_my_mod_My_type_t & restrict obs)
{
try
{
_gfortran_ieee_procedure_entry ((void *) &fpstate.0);
see the missing declaration for fpstate.0. But it is created by
gfc_create_var(), like so many other local variables in the front-end, so I
have no idea why it's disappearing.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #25 from Aldy Hernandez --- > prange has been enabled again, after testing on x86-64 and ppc64le linux. > Aarch has no space to run tests on the compile farm, and sparc bootstrap was > already broken. Huh? Current trunk bootstraps just fine on Solaris/SPARC without any patches. What issue do you see? Besides, there *is* a Solaris/SPARC system in the cfarm (cfarm216), so you can try for yourself.
[Bug lto/114655] [12 Regression] -flto=4 at link time does not override -flto=auto from compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114655 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||12.3.1 Resolution|--- |FIXED Known to fail||12.3.0 --- Comment #6 from Richard Biener --- Fixed.
[Bug web/115105] Document "Reimplement GNU threads library on native Windows" change on GCC 13 changes list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115105 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED URL||https://gcc.gnu.org/piperma ||il/gcc-cvs-wwwdocs/2024/010 ||474.html --- Comment #2 from Eric Botcazou --- .
[Bug tree-optimization/114231] [12 Regression] ICE when building libjxl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114231 Richard Biener changed: What|Removed |Added Known to fail||12.3.0 Status|ASSIGNED|RESOLVED Known to work||12.3.1 Resolution|--- |FIXED --- Comment #18 from Richard Biener --- Should be fixed now.
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
--- Comment #5 from Francois-Xavier Coudert ---
The only thing IEEE_ARITHMETIC does here is call _gfortran_ieee_procedure_entry
/ _gfortran_ieee_procedure_exit to save and restore the floating-point state.
The middle-end code that errors out is this:
/* ??? If this is a local variable, and it has not been seen in any
outer BIND_EXPR, then it's probably the result of a duplicate
declaration, for which we've already issued an error. It would
be really nice if the front end wouldn't leak these at all.
Currently the only known culprit is C++ destructors, as seen
in g++.old-deja/g++.jason/binding.C.
Another possible culpit are size expressions for variably modified
types which are lost in the FE or not gimplified correctly. */
if (VAR_P (decl)
&& !DECL_SEEN_IN_BIND_EXPR_P (decl)
&& !TREE_STATIC (decl) && !DECL_EXTERNAL (decl)
&& decl_function_context (decl) == current_function_decl)
{
gcc_assert (seen_error ());
return GS_ERROR;
}
I don't have a debug build available right now, so I don't know which variable
is causing the issue or why. But it seems like a very weird interplay between
IEEE and DT (which are normally completely orthogonal), so maybe we're just
catching it "by chance" and the bug is preexisting (but silent).
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #25 from Aldy Hernandez --- prange has been enabled again, after testing on x86-64 and ppc64le linux. Aarch has no space to run tests on the compile farm, and sparc bootstrap was already broken. The problem in this PR can be triggered by commenting the two new operand_check_p conditionals: diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc index 09cab761822..76548f31853 100644 --- a/gcc/ipa-cp.cc +++ b/gcc/ipa-cp.cc @@ -1744,7 +1744,7 @@ ipa_value_range_from_jfunc (vrange &vr, pointer type to hold the result instead of a boolean type. Avoid trapping in the sanity check in fold_range until this is fixed. */ - || !handler.operand_check_p (vr_type, srcvr.type (), op_vr.type ()) + /*|| !handler.operand_check_p (vr_type, srcvr.type (), op_vr.type ())*/ || !handler.fold_range (op_res, vr_type, srcvr, op_vr)) op_res.set_varying (vr_type); @@ -2556,9 +2556,11 @@ propagate_vr_across_jump_function (cgraph_edge *cs, ipa_jump_func *jfunc, pointer type to hold the result instead of a boolean type. Avoid trapping in the sanity check in fold_range until this is fixed. */ + /* || !handler.operand_check_p (operand_type, src_lats->m_value_range.m_vr.type (), op_vr.type ()) + */ || !handler.fold_range (op_res, operand_type, src_lats->m_value_range.m_vr, op_vr)) op_res.set_varying (param_type); You can reproduce on x86-64 as well as ppc64le, and the problem can be seen with and without prange support enabled.
[Bug middle-end/115110] [15 regression] several failures after r15-512-g9b7cad5884f21c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115110 Andrew Carlotti changed: What|Removed |Added CC||acarlotti at gcc dot gnu.org --- Comment #6 from Andrew Carlotti --- I'm seeing a bootstrap failure on aarch64-none-linux-gnu as well, bisected to this commit. The error, in Stage 2, is: In file included from ../../src/gcc/system.h:726, from ../../src/gcc/tree-affine.cc:21: In member function 'long int* widest_int_storage::write_val(unsigned int) [with int N = 131072]', inlined from 'typename wi::binary_traits::result_type wi::sext(const T&, unsigned int) [with T = generic_wide_int >]' at ../../src/gcc/wide-int.h:2582:28, inlined from 'poly_int::type> wi::sext(const poly_int&, unsigned int) [with unsigned int N = 2; Ca = generic_wide_int >]' at ../../src/gcc/poly-int.h:746:5, inlined from 'poly_widest_int wide_int_ext_for_comb(const poly_widest_int&, tree)' at ../../src/gcc/tree-affine.cc:49:46: ../../src/gcc/../include/libiberty.h:370:38: error: 'void free(void*)' called on a pointer to an unallocated object '13450750900837400303' [-Werror=free-nonheap-object] 370 | #define XDELETEVEC(P) free ((void*) (P)) | ~^ ../../src/gcc/wide-int.h:1630:5: note: in expansion of macro 'XDELETEVEC' 1630 | XDELETEVEC (u.valp); | ^~ ../../src/gcc/../include/libiberty.h:370:38: error: 'void free(void*)' called on a pointer to an unallocated object '13450750900837400303' [-Werror=free-nonheap-object] 370 | #define XDELETEVEC(P) free ((void*) (P)) | ~^ ../../src/gcc/wide-int.h:1630:5: note: in expansion of macro 'XDELETEVEC' 1630 | XDELETEVEC (u.valp); | ^~ Our regression testing also shows the test failures reported in the first comment for powerpc64.
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070 --- Comment #4 from Sebastien Bardeau --- Thanks for the hints. It seems to me that an intent(out) class without component initialization values is probably out of the standard (unpredictable results). So on my side the work-around I choose is to provide an initialization value.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #24 from GCC Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:b8e3574e68310f68116f157a35d5650600d13718 commit r15-574-gb8e3574e68310f68116f157a35d5650600d13718 Author: Aldy Hernandez Date: Thu May 16 09:47:56 2024 +0200 Cleanup prange sanity checks. The pointers_handled_p() code was a temporary sanity check, and not even a good one, since we have a cleaner way of checking type mismatches with operand_check_p. This patch removes all the code, and adds an explicit type check for relational operators, which are the main problem in PR114985. Adding this check makes it clear where the type mismatch is happening in IPA, even without prange. I've added code to skip the range folding if the types don't match what the operator expects. In order to reproduce the latent bug, just remove the operand_check_p calls. Tested on x86-64 and ppc64le with and without prange support. gcc/ChangeLog: PR tree-optimization/114985 * gimple-range-op.cc: Remove pointers_handled_p. * ipa-cp.cc (ipa_value_range_from_jfunc): Skip range folding if operands don't match. (propagate_vr_across_jump_function): Same. * range-op-mixed.h: Remove pointers_handled_p and tweak operand_check_p. * range-op-ptr.cc (range_operator::pointers_handled_p): Remove. (pointer_plus_operator::pointers_handled_p): Remove. (class operator_pointer_diff): Remove pointers_handled_p. (operator_pointer_diff::pointers_handled_p): Remove. (operator_identity::pointers_handled_p): Remove. (operator_cst::pointers_handled_p): Remove. (operator_cast::pointers_handled_p): Remove. (operator_min::pointers_handled_p): Remove. (operator_max::pointers_handled_p): Remove. (operator_addr_expr::pointers_handled_p): Remove. (operator_bitwise_and::pointers_handled_p): Remove. (operator_bitwise_or::pointers_handled_p): Remove. (operator_equal::pointers_handled_p): Remove. (operator_not_equal::pointers_handled_p): Remove. (operator_lt::pointers_handled_p): Remove. (operator_le::pointers_handled_p): Remove. (operator_gt::pointers_handled_p): Remove. (operator_ge::pointers_handled_p): Remove. * range-op.cc (TRAP_ON_UNHANDLED_POINTER_OPERATORS): Remove. (range_op_handler::lhs_op1_relation): Remove pointers_handled_p checks. (range_op_handler::lhs_op2_relation): Same. (range_op_handler::op1_op2_relation): Same. * range-op.h: Remove RO_* declarations.
[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #23 from GCC Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:f6bed6d3fcc13880ffa786b6c616e2306efe2bf3 commit r15-573-gf6bed6d3fcc13880ffa786b6c616e2306efe2bf3 Author: Aldy Hernandez Date: Thu May 16 09:22:55 2024 +0200 Use a boolean type when folding conditionals in simplify_using_ranges. In adding some traps for PR114985 I noticed that the conditional folding code in simplify_using_ranges was using the wrong type. This cleans up the oversight. gcc/ChangeLog: PR tree-optimization/114985 * vr-values.cc (simplify_using_ranges::fold_cond_with_ops): Use boolean type when folding conditionals.
[Bug tree-optimization/114027] [11/12 Regression] miscompile at `-O3 -fno-vect-cost-model -msse4.2`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027 --- Comment #22 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:2d650c041d37a3df2bec46a67e42f9976d7fd2bf commit r12-10451-g2d650c041d37a3df2bec46a67e42f9976d7fd2bf Author: Richard Biener Date: Tue Mar 26 09:46:06 2024 +0100 tree-optimization/114027 - fix testcase The following fixes out-of-bounds read in the testcase. PR tree-optimization/114027 * gcc.dg/vect/pr114027.c: Fix iteration count. (cherry picked from commit 4470611e20f3217ee81647b01fda65b6a62229aa)
[Bug tree-optimization/114375] [11/12 Regression] Wrong vectorization of permuted mask load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114375 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:c1b21855e131bb818aedc953f403812b494917fc commit r12-10449-gc1b21855e131bb818aedc953f403812b494917fc Author: Richard Biener Date: Mon Mar 18 12:39:03 2024 +0100 tree-optimization/114375 - disallow SLP discovery of permuted mask loads We cannot currently handle permutations of mask loads in code generation or permute optimization. But we simply drop any permutation on the floor, so the following instead rejects the SLP build rather than producing wrong-code. I've also made sure to reject them in vectorizable_load for completeness. PR tree-optimization/114375 * tree-vect-slp.cc (vect_build_slp_tree_2): Compute the load permutation for masked loads but reject it when any such is necessary. * tree-vect-stmts.cc (vectorizable_load): Reject masked VMAT_ELEMENTWISE and VMAT_STRIDED_SLP as those are not supported. * gcc.dg/vect/vect-pr114375.c: New testcase. (cherry picked from commit 4f2a35a76cca503749c696e7772d2e8eadc77ba5)
[Bug tree-optimization/114231] [12 Regression] ICE when building libjxl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114231 --- Comment #17 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:a7b1d814da0aa2e7331c56180264a8b786012971 commit r12-10448-ga7b1d814da0aa2e7331c56180264a8b786012971 Author: Richard Biener Date: Tue Mar 5 10:55:56 2024 +0100 tree-optimization/114231 - use patterns for BB SLP discovery root stmts The following makes sure to use recognized patterns when vectorizing roots during BB SLP discovery. We need to apply those late since during root discovery we've not yet done pattern recognition. All parts of the vectorizer assume patterns get used, for the testcase we mix this up when doing live lane computation. PR tree-optimization/114231 * tree-vect-slp.cc (vect_analyze_slp): Lookup patterns when processing a BB SLP root. * gcc.dg/vect/pr114231.c: New testcase. (cherry picked from commit 04fffbaa87997ac893a9aa68b674c938ba3ecddb)
[Bug tree-optimization/114027] [11/12 Regression] miscompile at `-O3 -fno-vect-cost-model -msse4.2`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027 --- Comment #21 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:6661a7c098a46eff4afc98b55c89e3a71d63d674 commit r12-10450-g6661a7c098a46eff4afc98b55c89e3a71d63d674 Author: Richard Biener Date: Thu Feb 22 10:50:12 2024 +0100 tree-optimization/114027 - conditional reduction chain When we classify a conditional reduction chain as CONST_COND_REDUCTION we fail to verify all involved conditionals have the same constant. That's a quite unlikely situation so the following simply disables such classification when there's more than one reduction statement. PR tree-optimization/114027 * tree-vect-loop.cc (vecctorizable_reduction): Use optimized condition reduction classification only for single-element chains. * gcc.dg/vect/pr114027.c: New testcase. (cherry picked from commit 549f251f055e3a0b0084189a3012c4f15d635e75)
[Bug target/114734] [11/12 regression] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl since r8-6047-g65dd1346027bb5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #21 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:46b2e98983ebc62440c43217f2b3bbe72f8b0191 commit r12-10447-g46b2e98983ebc62440c43217f2b3bbe72f8b0191 Author: Richard Biener Date: Fri Apr 26 15:47:13 2024 +0200 middle-end/114734 - wrong code with expand_call_mem_ref When expand_call_mem_ref looks at the definition of the address argument to eventually expand a &TARGET_MEM_REF argument together with a masked load it fails to honor constraints imposed by SSA coalescing decisions. The following fixes this. PR middle-end/114734 * internal-fn.cc (expand_call_mem_ref): Use get_gimple_for_ssa_name to get at the def stmt of the address argument to honor SSA coalescing constraints. (cherry picked from commit 20ebcaf826c91ddaf2aac35417ec1e5e6d31ad50)
[Bug lto/114655] [12 Regression] -flto=4 at link time does not override -flto=auto from compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114655 --- Comment #5 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:42a0393655d8e4662ba001c3759cf00b639eddb9 commit r12-10446-g42a0393655d8e4662ba001c3759cf00b639eddb9 Author: Richard Biener Date: Tue Apr 9 14:25:57 2024 +0200 lto/114655 - -flto=4 at link time doesn't override -flto=auto at compile time The following adjusts -flto option processing in lto-wrapper to have link-time -flto override any compile time setting. PR lto/114655 * lto-wrapper.cc (merge_flto_options): Add force argument. (merge_and_complain): Do not force here. (run_gcc): But here to make the link-time -flto option override any compile-time one. (cherry picked from commit 32fb04adae90a0ea68e64e8fc3cb04b613b2e9f3)
[Bug gcov-profile/114715] Gcov allocates branches to wrong row for nested switches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114715 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:56415e39029012aa3675d3b4b71fb248cf43049e commit r12-10445-g56415e39029012aa3675d3b4b71fb248cf43049e Author: Richard Biener Date: Mon Apr 15 11:09:17 2024 +0200 gcov-profile/114715 - missing coverage for switch The following avoids missing coverage for the line of a switch statement which happens when gimplification emits a BIND_EXPR wrapping the switch as that prevents us from setting locations on the containing statements via annotate_all_with_location. Instead set the location of the GIMPLE switch directly. PR gcov-profile/114715 * gimplify.cc (gimplify_switch_expr): Set the location of the GIMPLE switch. * gcc.misc-tests/gcov-24.c: New testcase. (cherry picked from commit 5a3cc62dbb45185dd1ca32caec80d57a320ec5a0)
[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Tom de Vries ---
> (In reply to Rainer Orth from comment #10)
[...]
>> I wonder how best to handle this: just skip the test on sparc*-sun-solaris2*
>> && !gas? Theoretically, there could be other targets with similar issues.
>
> This looks like test-case issue, so re-closing the PR.
True, but it's often way simpler to discuss testcase issues in the
original PR rather than open new PRs for every single issue with a
testcase (and there's already been the comment character one here).
> How about:
> ...
> -/* { dg-final { scan-assembler {\.byte\t0xb\t[^\n\r]* Define macro strx} } }
> */
> +/* { dg-final { scan-assembler {\.byte\t0xb\t[^\n\r]* Define macro
> strx|\.byte\t0x1\t[^\n\r]* Define macro}
> ...
> ?
Seems like an option, too (and would work on other affected targets
should they appear). Tested on sparc-sun-solaris2.11 with as and gas.
Btw., I wonder which of the targets currently skipped with "split DWARF
unsupported" are instances of this problem, too: Solaris doesn't support
-gsplit-dwarf, still the test PASSes on Solaris/SPARC with gas and
Solaris/x86 with either assembler.
[Bug target/111501] RISC-V: non-optimal casting when shifting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111501 Christoph Müllner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Christoph Müllner --- Closing this, as it has been fixed on master.
[Bug ada/115113] [15 Regression] Ada bootstrap fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115113 Eric Botcazou changed: What|Removed |Added Summary|[15 Regression] Ada |[15 Regression] Ada |bootstrap fails for |bootstrap fails |i686-darwin.| Last reconfirmed||2024-05-16 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Eric Botcazou --- See also PR ada/115106.
[Bug target/115115] [12/13/14/15 Regression] highway-1.0.7 wrong _mm_cvttps_epi32() constant fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115115 --- Comment #6 from Andrew Pinski --- It depends on if you consider a float to int conversion or not. For (long long)float . The value if the float was out of range is unspecified so returning one value or another is both valid. So the question is it corresponding to float to integer conversion in c or exactly what the instruction does. The later has implications across the board.
[Bug ada/115106] [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_rehash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-05-16 CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- > The reghunt identified > > commit 9b7cad5884f21cc5783075be0043777448db3fab > Author: Jan Hubicka > Date: Wed May 15 14:14:27 2024 +0200 > > Avoid pointer compares on TYPE_MAIN_VARIANT in TBAA Thanks for tracking this down! > FWIW, none of amd64-pc-solaris2.11, i686-pc-linux-gnu, and > x86_64-pc-linux-gnu show the failure. See PR ada/115113 though.
[Bug target/109093] csmith: a February runtime bug ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093 --- Comment #27 from Richard Biener --- *** Bug 109087 has been marked as a duplicate of this bug. ***
[Bug target/109087] [13/14/15 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109087 Richard Biener changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #22 from Richard Biener --- The missed DSE should be fixed, I'm not sure if the bogus .DEFERRED_INIT expansion was? Anyway, closing as that issue is discussed in PR109093. *** This bug has been marked as a duplicate of bug 109093 ***
[Bug target/115115] [12/13/14/15 Regression] highway-1.0.7 wrong _mm_cvttps_epi32() constant fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115115 --- Comment #5 from Sergei Trofimovich --- (In reply to Andrew Pinski from comment #2) > So from a point of view of float to int conversion, both are valid for out > of range values. Looking at CVTTPS2DQ instruction from https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html "Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4": """ Description ... When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (8000H) is returned. """ It feels like 2^63 is an exact value and no truncation should happen. Thus 0x8000 seems to be the correct value. Why 0x7fff would be a reasonable outcome as well? Is it because `_mm_cvttps_epi32()` semantics are not a 1-to-1 to CVTTPS2DQ instruction? Trying to understand the detail as I'm not yet sure if I should file a `highway` bug to be compatible with gcc's expectations. The exact test is at https://github.com/google/highway/blob/b7cff55896e36e6080909d35ef6fb3d0986b4cfa/hwy/tests/convert_test.cc#L1202
[Bug tree-optimization/113787] [12/13/14/15 Regression] Wrong code at -O with ipa-modref on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787 --- Comment #20 from Alex Coplan --- I'd just like to ping this serious wrong code bug. It's unfortunate that this wasn't addressed for the 14.1 release.
[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED|RESOLVED
--- Comment #11 from Tom de Vries ---
(In reply to Rainer Orth from comment #10)
> The new test currently FAILs on Solaris/SPARC with the native as:
>
> FAIL: gcc.dg/pr115066.c scan-assembler .bytet0xbt# Define macro
> strx
>
> The relevant snippet of pr115066.s is
>
> .section".debug_macro.dwo",#exclude,#progbits
> .LLdebug_macro0:
> .uahalf 0x4 ! DWARF macro version number
> .byte 0x2 ! Flags: 32-bit, lineptr present
> .uaword .LLskeleton_debug_line0
> .byte 0x1 ! Define macro
>
> while when using gas, I have
>
> .section.debug_macro.dwo,"e",@progbits
> .LLdebug_macro0:
> .uahalf 0x4 ! DWARF macro version number
> .byte 0x2 ! Flags: 32-bit, lineptr present
> .uaword .LLskeleton_debug_line0
> .byte 0xb ! Define macro strx
>
> AFAICS from dwarf2out.cc (output_macinfo_op), the requirements for using
> DW_MACRO_define_strx are (among others)
> !DWARF2_INDIRECT_STRING_SUPPORT_MISSING_ON_TARGET && SECTION_MERGE.
>
> However, with the native assembler, SHF_MERGE doesn't work (as emits
> something
> ld cannot link).
>
> I wonder how best to handle this: just skip the test on sparc*-sun-solaris2*
> && !gas? Theoretically, there could be other targets with similar issues.
This looks like test-case issue, so re-closing the PR.
How about:
...
-/* { dg-final { scan-assembler {\.byte\t0xb\t[^\n\r]* Define macro strx} } }
*/
+/* { dg-final { scan-assembler {\.byte\t0xb\t[^\n\r]* Define macro
strx|\.byte\t0x1\t[^\n\r]* Define macro}
...
?
[Bug tree-optimization/114774] Missed DSE in simple code due to interleaving stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114774 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |15.0 Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed for GCC 15.
