[Bug tree-optimization/93518] missing warning on a possible overflow by sprintf %s with an allocated argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93518 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |tree-optimization Severity|normal |enhancement Ever confirmed|0 |1 Last reconfirmed||2021-12-23 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug middle-end/92943] missing -Wformat-overflow with an allocated buffer with non-constant size in known range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92943 Andrew Pinski changed: What|Removed |Added Known to fail||10.3.0 Known to work||11.1.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-12-23 --- Comment #1 from Andrew Pinski --- This seems fixed in GCC 11+: : In function 'h': :23:26: warning: '%i' directive writing 5 bytes into a region of size 4 [-Wformat-overflow=] 23 | __builtin_sprintf (p, "%i", 12345); // overflow not detected | ^~ :23:3: note: '__builtin_sprintf' output 6 bytes into a destination of size 4 23 | __builtin_sprintf (p, "%i", 12345); // overflow not detected | ^~
[Bug tree-optimization/83349] Missed optimization in math expression: aggressive optimization with std::pow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83349 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|middle-end |tree-optimization
[Bug middle-end/46597] configure -enable-checking=... -enable-build-with-cxx and bootstrap is g++ 3.3 hit minor problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46597 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Andrew Pinski --- You cannot build GCC 11+ without C++11 support so this is a won't fix at this point.
[Bug tree-optimization/58817] optimize alloca with constant size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58817 Andrew Pinski changed: What|Removed |Added CC||sdmike9r at liargroup dot com --- Comment #5 from Andrew Pinski --- *** Bug 89889 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/89889] worse code compared to clang with alloca()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89889 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Andrew Pinski --- Dup of bug 58817. *** This bug has been marked as a duplicate of bug 58817 ***
[Bug tree-optimization/58817] optimize alloca with constant size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58817 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-12-23 Status|UNCONFIRMED |NEW --- Comment #4 from Andrew Pinski --- Confirmed, we handle the VLA case since GCC 4.7.0. alloca has not been handled yet.
[Bug tree-optimization/81445] Dynamic stack allocation not optimized into static allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81445 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #7 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/81445] Dynamic stack allocation not optimized into static allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81445 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|middle-end |tree-optimization
[Bug middle-end/60762] [ASAN] -fsanitize=address fails with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60762 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Andrew Pinski --- Works for me in GCC 4.9.0 even (on https://godbolt.org/). Since there is no way to reproduce this closing as works for me.
[Bug middle-end/77422] -fdata-sections should put each constant in its own section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77422 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Andrew Pinski --- Won't fix as explained. Also LTO fixes this way too.
[Bug middle-end/59394] Unused code generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59394 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- If I use -Wl,--gc-sections -ffunction-sections, then all of the unused (non-static) functions are removed. Also -flto is able to optimize it too.
[Bug tree-optimization/95118] [10 Regression] gcc-10 and master -O3 -fopt-info-vec causes gcc to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95118 Andrew Pinski changed: What|Removed |Added CC||ch3root at openwall dot com --- Comment #10 from Andrew Pinski --- *** Bug 71533 has been marked as a duplicate of this bug. ***
[Bug middle-end/71533] -fdump-tree-fre1 hangs while printing an unnormal long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71533 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Even though PR 95118 is newer, the problem is exactly the same, real_to_decimal_for_mode has problems with denormals and that bug report has been closed as fixed with a reference to a patch which fixes it. So marking this bug is a dup of bug 95118. *** This bug has been marked as a duplicate of bug 95118 ***
[Bug middle-end/58101] Wrong out-of-bounds warning under -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58101
--- Comment #6 from Andrew Pinski ---
Further reduced:
int a [1];
void foo (int n)
{
if (n <= 1) return;
int i = 1;
a [i] = a [i - 1];
}
This is one of these false positives warning where we should maybe not warn but
instead just change the code to be a trap.
Note in the original testcase, GCC is able to remove the loop and just change
it to one statement. That is part of the reason for the warning even.
clang does not warn about the above because they only warn for the literal a[1]
case.
[Bug middle-end/14505] __builtin_constant_p(__func__) is not true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14505
Andrew Pinski changed:
What|Removed |Added
Severity|minor |enhancement
--- Comment #8 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #6)
> Try:
> int
> foo ()
> {
> static int a;
> static const int b = 3;
> static const char c[3] = "ab";
> static const char *d = "cd";
> static const char *const e = "ef";
> return 1 * __builtin_constant_p ()
> + 2 * __builtin_constant_p ()
> + 4 *__builtin_constant_p (c)
> + 8 * __builtin_constant_p (c[0])
> + 16 *__builtin_constant_p (d)
> + 32 * __builtin_constant_p (d[0])
> + 64 *__builtin_constant_p (e)
> + 128 * __builtin_constant_p (e[0]);
> }
What we get now is dependent on the optimization level and if it is C or C++
mode and even what version of the compiler (GCC 8+ has stablized it seems
though).
GCC 8+:
-O0 -O1+
c 0 232 (8+32+64+128)
c++ 64 232
GCC 6/7:
c 0 168 (8+32+128)
c++ 64 232
GCC 4.5-5.x:
c/c++ 0 168
GCC ???-4.4.x:
c 0 200 (128+64+8)
c++ 0 136 (128+8)
4.1.2:
c 0 64
c++ 0 128
clang:
c 192 232
c++11+ 200 232
c++98 192 232
192 = 128+64; 200 = 128+64+8
[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |4.6.0 Resolution|--- |FIXED --- Comment #26 from Andrew Pinski --- Fixed as mentioned.
[Bug middle-end/39275] -funroll-loop fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39275 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |4.5.3 Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Fixed a long time ago, I have no idea what by though.
[Bug target/103750] [i386] GCC schedules KMOV instructions that destroys performance in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103750
--- Comment #16 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:1a7ce8570997eb1596c803443d20687b43fa2e47
commit r12-6103-g1a7ce8570997eb1596c803443d20687b43fa2e47
Author: liuhongt
Date: Wed Dec 22 16:48:54 2021 +0800
Combine vpcmpuw + zero_extend to vpcmpuw.
vcmp{ps,ph,pd} and vpcmp{,u}{b,w,d,q} implicitly clear the upper bits
of dest.
gcc/ChangeLog:
PR target/103750
* config/i386/sse.md
(*_cmp3_zero_extend):
New pre_reload define_insn_and_split.
(*_cmp3_zero_extend):
Ditto.
(*_ucmp3_zero_extend):
Ditto.
(*_ucmp3_zero_extend):
Ditto.
(*_cmp3_zero_extend_2):
Ditto.
(*_cmp3_zero_extend_2):
Ditto.
(*_ucmp3_zero_extend_2):
Ditto.
(*_ucmp3_zero_extend_2):
Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/i386/avx512bw-pr103750-1.c: New test.
* gcc.target/i386/avx512bw-pr103750-2.c: New test.
* gcc.target/i386/avx512f-pr103750-1.c: New test.
* gcc.target/i386/avx512f-pr103750-2.c: New test.
* gcc.target/i386/avx512fp16-pr103750-1.c: New test.
* gcc.target/i386/avx512fp16-pr103750-2.c: New test.
[Bug middle-end/68378] Return value optimization does not fire iff in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68378 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/27896] lower-gimple produces extra goto for once return functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27896 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2008-12-07 00:46:46 |2021-12-22 Severity|normal |enhancement
[Bug middle-end/101913] -Wstrict-overflow -O3 false alarm on tzdb localtime.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101913 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #4 from Andrew Pinski --- Looks to be fixed on the trunk.
[Bug tree-optimization/94930] Failure to optimize out subvsi in expansion of __builtin_memcmp with 1 as the operand with -ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94930 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-12-23 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623 --- Comment #13 from Arseny Solokha --- (In reply to Kewen Lin from comment #12) > Could you double check? If it still failed, could you share your > configuration? % powerpc-e300c3-linux-gnu-gcc-12.0.0 -v Using built-in specs. COLLECT_GCC=powerpc-e300c3-linux-gnu-gcc-12.0.0 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-e300c3-linux-gnu/12.0.0/lto-wrapper Target: powerpc-e300c3-linux-gnu Configured with: /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_p20211219/work/gcc-12-20211219/configure --host=x86_64-pc-linux-gnu --target=powerpc-e300c3-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/powerpc-e300c3-linux-gnu/gcc-bin/12.0.0 --includedir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/12.0.0/include --datadir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/12.0.0 --mandir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/12.0.0/man --infodir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/12.0.0/info --with-gxx-include-dir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/12.0.0/include/g++-v12 --with-python-dir=/share/gcc-data/powerpc-e300c3-linux-gnu/12.0.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --disable-libunwind-exceptions --enable-checking=yes --disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-poison-system-directories --with-sysroot=/usr/powerpc-e300c3-linux-gnu --disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --enable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --enable-lto --with-isl --disable-isl-version-check --disable-libsanitizer --enable-default-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20211219 (experimental) (GCC)
[Bug c/48110] "fast" and "g" should be aliases of "Ofast" and "Og" inside optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48110 Bug 48110 depends on bug 53776, which changed state. Bug 53776 Summary: pragma optimize does not support Os https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53776 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug ipa/53776] pragma optimize does not support Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53776 Andrew Pinski changed: What|Removed |Added Known to work||5.1.0, 8.1.0 Target Milestone|--- |8.0 Component|middle-end |ipa Known to fail||4.9.4 Status|NEW |RESOLVED Resolution|--- |FIXED CC||marxin at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- Fixed in GCC 8 so closing.
[Bug sanitizer/84250] Symbol collision when using both Address and Undefined Behavior sanitizers (-fsanitize=address,undefined)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84250
chefmax at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #12 from chefmax at gcc dot gnu.org ---
> If you're not planning to get back to this then I think it'd be good to
> unassign. I don't know whom we would reassign this to at this point.
Ok, I'm unassigning this now because I can't guarantee prompt reaction/updates.
Meanwhile, I found the reason why option 1) was reverted (explained by Jakub):
https://gcc.gnu.org/pipermail/gcc-patches/2018-July/501921.html
> the 1) variant is actually not a good idea, it will not work properly anyway
> if you link one library with -fsanitize=undefined and another library
> with -fsanitize=address, the right solution is to make the two libraries
> coexist sanely
If we want to follow this way, we may need to introduce something like
libsanitizer_common.so but this may also require pushing some patches in LLVM
upstream.
And just in case, let me post the variant 2) fix here, just to have a
reference:
diff --git a/libsanitizer/sanitizer_common/sanitizer_file.cpp
b/libsanitizer/sanitizer_common/sanitizer_file.cpp
index 5492560df91..c7013166ef6 100644
--- a/libsanitizer/sanitizer_common/sanitizer_file.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_file.cpp
@@ -27,7 +27,8 @@ void CatastrophicErrorWrite(const char *buffer, uptr length)
{
}
StaticSpinMutex report_file_mu;
-ReportFile report_file = {_file_mu, kStderrFd, "", "", 0};
+SANITIZER_INTERFACE_ATTRIBUTE ReportFile report_file = {_file_mu,
+kStderrFd, "", "", 0};
void RawWrite(const char *buffer) {
report_file.Write(buffer, internal_strlen(buffer));
diff --git a/libsanitizer/sanitizer_common/sanitizer_file.h
b/libsanitizer/sanitizer_common/sanitizer_file.h
index 3d7916171c1..0ce1f417030 100644
--- a/libsanitizer/sanitizer_common/sanitizer_file.h
+++ b/libsanitizer/sanitizer_common/sanitizer_file.h
@@ -47,7 +47,7 @@ struct ReportFile {
private:
void ReopenIfNecessary();
};
-extern ReportFile report_file;
+extern SANITIZER_INTERFACE_ATTRIBUTE ReportFile report_file;
enum FileAccessMode {
RdOnly,
diff --git a/libsanitizer/ubsan/ubsan_init.cpp
b/libsanitizer/ubsan/ubsan_init.cpp
index 9931d85bf40..042026fee8d 100644
--- a/libsanitizer/ubsan/ubsan_init.cpp
+++ b/libsanitizer/ubsan/ubsan_init.cpp
@@ -43,7 +43,13 @@ static void CommonStandaloneInit() {
CacheBinaryName();
InitializeFlags();
__sanitizer::InitializePlatformEarly();
- __sanitizer_set_report_path(common_flags()->log_path);
+
+ // GCC-specific: in case of both ASan/UBSan runtimes are present,
+ // ASan or application itself may have aleady defined report path.
+ // Do not override it when initializing UBSan.
+ if (!__sanitizer_get_report_path()) {
+__sanitizer_set_report_path(common_flags()->log_path);
+ }
AndroidLogInit();
InitializeCoverage(common_flags()->coverage, common_flags()->coverage_dir);
CommonInit();
[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623 --- Comment #12 from Kewen Lin --- (In reply to Arseny Solokha from comment #11) > Unfortunately, I still have exactly the same ICE on this testcase w/ 12.0.0 > alpha20211219 snapshot: > > % powerpc-e300c3-linux-gnu-gcc-12.0.0 -mcpu=401 tt.c Interesting, I can see this has been fixed as tested locally. My trunk is based on g:29309f6e29d0912eececa1bac29b249440469107. Could you double check? If it still failed, could you share your configuration?
[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 Known to fail||9.4.0 Known to work||10.1.0 --- Comment #27 from Andrew Pinski --- Fixed in GCC 10 by r10-5360 which turns on loop distrubtion at -O2 instead of -O3.
[Bug middle-end/90427] missing "sign flipping" optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90427 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/43883] missed optimization of constant __int128_t modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43883 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #8 from Andrew Pinski --- Note LLVM produces: mov rdx, rsi mov rax, rdi mov rcx, rsi shr rcx, 63 add rcx, rdi adc rsi, 0 and rcx, -2 sub rax, rcx sbb rdx, rsi
[Bug middle-end/43883] missed optimization of constant __int128_t modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43883 --- Comment #7 from Andrew Pinski --- 4.7 produces: shr rsi, 63 mov rax, rdi xor edi, edi add rax, rsi xor r10d, r10d mov r9, rax mov rdx, r10 and r9d, 1 mov rax, r9 sub rax, rsi sbb rdx, rdi ret 4.9: mov rcx, rsi sar rcx, 63 xor rdi, rcx mov rdx, rcx mov rax, rdi sub rax, rcx and eax, 1 xor rax, rcx sub rax, rcx sbb rdx, rcx ret 7.1.0-7.3.0, 8.1.0-8.2.0 decides not to inline it: sub rsp, 8 .cfi_def_cfa_offset 16 mov edx, 2 xor ecx, ecx call__modti3 add rsp, 8 .cfi_def_cfa_offset 8 ret And then we are back to the 4.9 code gen for 7.4, 8.3 and 9.x 10.x produces: mov r10, rsi mov r8, rdi sar r10, 63 xor r8, r10 mov rdx, r10 mov rax, r8 sub rax, r10 and eax, 1 xor rax, r10 sub rax, r10 sbb rdx, r10 ret GCC 11 and trunk is back to the 4.9 code gen
[Bug tree-optimization/101253] Optimize i % C1 == C0 || i % C1*C2 == C0 to i % C1 == C0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101253 Andrew Pinski changed: What|Removed |Added Component|middle-end |tree-optimization Severity|normal |enhancement
[Bug fortran/103471] [9/10/11/12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103471
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
An error is being queued in symbol.c(gfc_set_default_type), but
error reporting has been disabled for some reason. Changing
gfc_error() to gfc_error_now() restores emitting the error
message, but is this correct!
diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index 179f6029ca3..43691710120 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -303,11 +303,11 @@ gfc_set_default_type (gfc_symbol *sym, int error_flag,
gfc_namespace *ns)
{
const char *guessed = lookup_symbol_fuzzy (sym->name, sym);
if (guessed)
- gfc_error ("Symbol %qs at %L has no IMPLICIT type"
+ gfc_error_now ("Symbol %qs at %L has no IMPLICIT type"
"; did you mean %qs?",
sym->name, >declared_at, guessed);
else
- gfc_error ("Symbol %qs at %L has no IMPLICIT type",
+ gfc_error_now ("Symbol %qs at %L has no IMPLICIT type",
sym->name, >declared_at);
sym->attr.untyped = 1; /* Ensure we only give an error once. */
}
[Bug target/103808] [12 Regression] '-fcompare-debug' failure (length) w/ -O2 -ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103808
--- Comment #3 from Andrew Pinski ---
I think this is a latent bug exposed by my match.pd patch (r12-5392).
In GCC 11.2.0 we had:
y_18 = iftmp.0_10 > a_14 ? 2 : 0;
While on the trunk we have:
y_18 = prephitmp_29 * 2;
But doing this:
void
foo (__int128 x, int y)
{
for (;;)
{
__int128 a, b;
x |= !!y;
a = x + 1;
b = y ? ++y : ++x;
y = a < b;
asm("":"+r"(y));
if (x >> 2)
y *= 2;
if (y == b)
__builtin_unreachable ();
}
}
Which causes the IR to be the same out of 11 and 12, does not produce compare
debug in 11 but does in 12.
[Bug fortran/103506] [10/11/12 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- Created attachment 52048 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52048=edit don't assert() if errors have already occurred. If errors have already been emitted, it is possible that the namespaces are FUBAR. So don't assert().
[Bug target/103808] [12 Regression] '-fcompare-debug' failure (length) w/ -O2 -ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103808 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||needs-bisection Last reconfirmed||2021-12-22 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug target/103808] [12 Regression] '-fcompare-debug' failure (length) w/ -O2 -ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103808 Andrew Pinski changed: What|Removed |Added Component|middle-end |target --- Comment #1 from Andrew Pinski --- t233.gk.c.327r.mach is where the difference shows up so the bug is inside ix86_reorg somewhere.
[Bug fortran/103779] ICE in gfc_convert_chartype, at fortran/intrinsic.c:5400
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103779 --- Comment #1 from kargl at gcc dot gnu.org --- Created attachment 52047 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52047=edit remove an assert() that causes an ICE in the face of invalid code The attach patch removes an assert() and now has the function 'return false' if sym == NULL. Invalid code can cause this condition. See the bug report.
[Bug fortran/103779] ICE in gfc_convert_chartype, at fortran/intrinsic.c:5400
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103779 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Priority|P3 |P4 Ever confirmed|0 |1 CC||kargl at gcc dot gnu.org Last reconfirmed||2021-12-22
[Bug fortran/103796] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9446 since r8-6395-gf8862a1b2afad9d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103796 --- Comment #4 from kargl at gcc dot gnu.org --- Comment on attachment 52046 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52046 New diff This replaces the first diff, which was prematurely created.
[Bug fortran/103796] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9446 since r8-6395-gf8862a1b2afad9d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103796 --- Comment #3 from kargl at gcc dot gnu.org --- Created attachment 52046 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52046=edit New diff
[Bug middle-end/103813] [11/12 Regression] Crash in decompose, at wide-int.h:984 fold-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103813
--- Comment #3 from Andrew Pinski ---
Another testcase:
struct a {
char b;
char c[];
} ;
struct a d;
int main() {
return d.c[0x4000] || d.c[1];
}
In GCC 10 (and before) fold would produce:
return ((unsigned char) BIT_FIELD_REF [(void *)], 8, 16> &
255) != 0;
Which is a bit interesting because the d.c[0x4000] part is left off.
[Bug middle-end/103813] [11/12 Regression] Crash in decompose, at wide-int.h:984 fold-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103813 Andrew Pinski changed: What|Removed |Added Known to fail||11.1.0 Status|UNCONFIRMED |NEW Known to work||10.3.0 Last reconfirmed||2021-12-22 Summary|Crash in decompose, at |[11/12 Regression] Crash in |wide-int.h:984 fold-const |decompose, at ||wide-int.h:984 fold-const Ever confirmed|0 |1 Target Milestone|--- |11.3 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug middle-end/103813] Crash in decompose, at wide-int.h:984 fold-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103813
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Component|c |middle-end
--- Comment #1 from Andrew Pinski ---
The code is undefined for sure.
here is reduced testcase which has less invalidness to it:
struct a {
int b;
int c[];
} ;
struct a d;
int main() {
d.c[0x1000] || d.c[1];
}
[Bug c/103813] New: Crash in decompose, at wide-int.h:984 fold-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103813
Bug ID: 103813
Summary: Crash in decompose, at wide-int.h:984 fold-const
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: k.even-mendoza at imperial dot ac.uk
Target Milestone: ---
The following code crashed GCC 11 and 12, with -O1, -O2, -O3 and -Os but -O0
works just fine.
struct a d;
struct a {
int b;
int c[]
} main() {
d.c[268435456] || d.c[1];
}
I tested it with GCC 11.1.0 Ubuntu 20.04 and GCC 12.0.0 20211216 (experimental)
Ubuntu 18. I can see other bugs open but none related to fold-const.
With that trace:
fuzzer-file-159198.c:6:3: internal compiler error: in decompose, at
wide-int.h:984
6 | d.c[268435456] || d.c[1];
| ^
0x6f4748 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
.././../gcc-source/gcc/wide-int.h:984
0x6fbea1 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
.././../gcc-source/gcc/tree.h:3555
0x6fbea1 wide_int_ref_storage::wide_int_ref_storage > >(generic_wide_int > const&,
unsigned int)
.././../gcc-source/gcc/wide-int.h:1034
0x6fbea1 generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
.././../gcc-source/gcc/wide-int.h:790
0x6fbea1 unsigned long
wi::extract_uhwi >
>(generic_wide_int > const&, unsigned int,
unsigned int)
.././../gcc-source/gcc/wide-int.h:3212
0x6fbea1 unextend
.././../gcc-source/gcc/fold-const.c:6110
0xb991ed fold_truth_andor_1
.././../gcc-source/gcc/fold-const.c:6461
0xb9a4bd fold_truth_andor
.././../gcc-source/gcc/fold-const.c:9687
0xb7aaf4 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
.././../gcc-source/gcc/fold-const.c:12036
0xb82629 fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
.././../gcc-source/gcc/fold-const.c:13781
0x9358b2 c_fully_fold_internal
.././../gcc-source/gcc/c/c-fold.c:545
0x936089 c_fully_fold(tree_node*, bool, bool*, bool)
.././../gcc-source/gcc/c/c-fold.c:125
0x8d00ec c_process_expr_stmt(unsigned int, tree_node*)
.././../gcc-source/gcc/c/c-typeck.c:11320
0x8d03cd c_finish_expr_stmt(unsigned int, tree_node*)
.././../gcc-source/gcc/c/c-typeck.c:11365
0x90409f c_parser_statement_after_labels
.././../gcc-source/gcc/c/c-parser.c:6261
0x9067ac c_parser_compound_statement_nostart
.././../gcc-source/gcc/c/c-parser.c:5798
0x927f75 c_parser_compound_statement
.././../gcc-source/gcc/c/c-parser.c:5607
0x929b2a c_parser_declaration_or_fndef
.././../gcc-source/gcc/c/c-parser.c:2544
0x932583 c_parser_external_declaration
.././../gcc-source/gcc/c/c-parser.c:1779
0x933093 c_parser_translation_unit
.././../gcc-source/gcc/c/c-parser.c:1652
Please submit a full bug report,
[Bug driver/81371] Too many C++ templates output in build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81371 --- Comment #7 from Jonny Grant --- It would be nice to have a way to print the original std::string name, but depends if it is really worth all the trouble to have an the non expanded template name as alternative... It would make error messages clearer. That way, the symbol could stay the same, but the linker could show the alternative..
[Bug c/103812] New: -fcond-mismatch could use a testcase that covers its documented behavior better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103812 Bug ID: 103812 Summary: -fcond-mismatch could use a testcase that covers its documented behavior better Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org CC: jsm28 at gcc dot gnu.org Target Milestone: --- Continuing my current re-read of the GCC docs (from bug 103810), I came across the -fcond-mismatch option, the docs for which say: "Allow conditional expressions with mismatched types in the second and third arguments. The value of such an expression is void. This option is not supported for C++." https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options However, the only place where I can find this option tested in the testsuite is in gcc/testsuite/gcc.dg/pch/valid-6.c, which doesn't contain any conditional expressions, it just includes a header (which doesn't contain any conditional expressions either), and defines a variable. Having a testcase that actually tests the feature being documented would be helpful for people looking to understand what its intended behavior is. (cc-ing last person to write a ChangeLog entry mentioning the option that I could find)
[Bug c++/103811] New: [c++20] ICE when a lambda is used as a template argument of another lambda's function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103811
Bug ID: 103811
Summary: [c++20] ICE when a lambda is used as a template
argument of another lambda's function parameter
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iamsupermouse at mail dot ru
Target Milestone: ---
Following code causes an ICE (segfault):
template struct A {};
int main() {[](A<[]{}>){};}
Tested on https://godbolt.org/ , GCC trunk 12.0.0 20211222.
The same thing happens if I move the nested lambda to A's default argument:
template struct A {};
int main() {[](A<>){};}
MSVC also ICEs on the second snippet, but not on the first.
[Bug c/103810] New: -fallow-parameterless-variadic-functions flag could use a testcase that covers its documentation better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103810 Bug ID: 103810 Summary: -fallow-parameterless-variadic-functions flag could use a testcase that covers its documentation better Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org CC: gingold at adacore dot com Target Milestone: --- So, I'm giving the GCC docs another read-through, and the -fallow-parameterless-variadic-functions docs say: "Accept variadic functions without named parameters. Although it is possible to define such a function, this is not very useful as it is not possible to read the arguments. This is only supported for C as this construct is allowed by C++." However, looking in the testsuite for where this flag is actually tested, I only find gcc/testsuite/gcc.dg/va-arg-5.c which only has a single declaration of the kind allowed by the flag. If the docs are correct that it is possible to define such a function, and not just declare it, shouldn't there be a test for a function definition to go with the declaration? Also, what are you supposed to do with such a declaration/definition after you have it, if you can't read the arguments? You can still call it even if you can't read the arguments, can't you? Shouldn't the testcase test calling it, too, then? (cc-ing person who added the option)
[Bug middle-end/103808] [12 Regression] '-fcompare-debug' failure (length) w/ -O2 -ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103808 Andrew Pinski changed: What|Removed |Added Component|debug |middle-end Target Milestone|--- |12.0 Keywords||ice-on-valid-code, ||wrong-debug
[Bug c++/103700] Incomplete type not causing constraints to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103700 --- Comment #5 from Andrew Pinski --- (In reply to Patrick Palka from comment #4) > Hmm, can't we just check COMPLETE_TYPE_P in pointer_int_sum directly? Patch > to that effect posted at > https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587300.html. Yes that will work too. I was just quickly looking into how to fix it when I write that comment really.
[Bug fortran/103796] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9446 since r8-6395-gf8862a1b2afad9d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103796 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- Created attachment 52045 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52045=edit Check FORM TEAM The requirements on parsing of FORM TEAM are not checked. The attached patch checks TEAM_NUMBER and TEAM. The optional form-team-spec-list is currently not implemented in gfortran. Add a PSA to recruit new contributors.
[Bug c++/103809] spurious reporting of structure redefinition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103809
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-12-22
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Known to fail||10.3.0, 11.2.0, 12.0, 9.4.0
Keywords||rejects-valid
--- Comment #1 from Jonathan Wakely ---
Confirmed, not a regression.
template concept Byte = sizeof(T) == 1;
template concept NotByte = sizeof(T) != 1;
namespace priv
{
template
struct Struct {};
}
template
struct priv::Struct {};
template
struct priv::Struct {};
103809.C:14:14: error: redefinition of 'struct priv::Struct'
14 | struct priv::Struct {};
| ^
103809.C:11:14: note: previous definition of 'struct priv::Struct'
11 | struct priv::Struct {};
| ^
[Bug tree-optimization/103797] Clang vectorized LightPixel while GCC does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797 --- Comment #11 from Jan Hubicka --- Aha, I did not noticed that we need special patterns (I extecpted this is problem to solve in machine independent code). So I guess we have 1) SLP should vectorize the 3 accesses with -ffast-math to only one vector operation (as opposed to one vector+one scalar it does now) 2) we could adddivv2sf3 pattern which initializes the elt 4 of the operand2 to 1.0f to avoid funny results 3) we need to figure out why SLP vectorization is not even considered in the original testcase (which I do not seem to be able to dig out with reasonable effort in a way that it preserves original properties - to be vectorized by clang and not vectorized by gcc)
[Bug fortran/103795] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:8325 since r7-1821-g20d0bfcefd6caf09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103795 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- Created attachment 52044 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52044=edit check STAT= and TEAM= image-selector-specs The attached patch checks the image-selector-specs for STAT= and TEAM=. Note, neither NOTIFY= nor TEAM_NUMBER= image-selector-specs are supported by gfortran.
[Bug tree-optimization/103797] Clang vectorized LightPixel while GCC does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- At least on your short testcase clang doesn't use divps either. We do support mulv2sf3, addv2sf3 etc. but not divv2sf3 I bet because with TARGET_MMX_WITH_SSE it would divide by zero in the 3rd and 4th elts, but perhaps we could insert 1.0f, 1.0f into those elements of the divisor before using divps? Another question is if we could teach SLP to vectorize even factors not power of 2, say loads/stores could be done (and with e.g. AVX512 almost everything) could be done with masked loads/stores, most arithmetics could be done normally and we'd just need to watch what values we'll get in the extra elts and make sure it doesn't generate exceptions etc.
[Bug driver/93645] Support Clang 12 --ld-path=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645 --- Comment #13 from Fangrui Song --- (In reply to Martin Liška from comment #12) > (In reply to Fangrui Song from comment #11) > > (In reply to Martin Liška from comment #10) > > > I replied here: > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573823.html > > > > There are people wanting to use mold > > https://www.reddit.com/r/rust/comments/rhcnzt/ > > mold_a_modern_linker_10_release/ > > I agree that's unfortunate. Note I'm having a patch that adds -fuse-ld=mold: > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=759cdbb29dbe8fc80ba5c1f113a015cafe9eb69c > > I can try suggesting that to the community for GCC 12 (and maybe backport > that). > Are you interested? I think it may be useful to simply allow -fuse-ld=word (`word` cannot include a separator). If that may be troublesome, having -fuse-ld=mold in GCC 12 is still nice. --ld-path is occasionally useful, but I can accept that GCC declines it. > Note the linker is very interesting, but it lacks LTO support.. Right...
[Bug fortran/103776] ICE in gfc_compare_string, at fortran/arith.c:1118
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103776 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- Fixed for gcc-12. Thanks for the report!
[Bug fortran/103778] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103778 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:ff0ad4b5e16b8828a6147ae2d5fec8068ef0778e commit r12-6101-gff0ad4b5e16b8828a6147ae2d5fec8068ef0778e Author: Harald Anlauf Date: Mon Dec 20 22:12:33 2021 +0100 Fortran: BOZ literal constants are not interoperable gcc/fortran/ChangeLog: PR fortran/103778 * check.c (is_c_interoperable): A BOZ literal constant is not interoperable. gcc/testsuite/ChangeLog: PR fortran/103778 * gfortran.dg/illegal_boz_arg_3.f90: New test.
[Bug fortran/103776] ICE in gfc_compare_string, at fortran/arith.c:1118
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103776 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:5474092c9afbd76cbd457facce3757d8d2fad07b commit r12-6100-g5474092c9afbd76cbd457facce3757d8d2fad07b Author: Harald Anlauf Date: Mon Dec 20 22:01:05 2021 +0100 Fortran: CASE selector expressions must be scalar gcc/fortran/ChangeLog: PR fortran/103776 * match.c (match_case_selector): Reject expressions in CASE selector which are not scalar. gcc/testsuite/ChangeLog: PR fortran/103776 * gfortran.dg/select_10.f90: New test.
[Bug libstdc++/55713] std::tuple incorrectly is convertible to "ElementType" when it is an empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713 Bug 55713 depends on bug 93711, which changed state. Bug 93711 Summary: [9 Regression] ICE: [[no_unique_address] when constructing via template helper https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93711 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/93711] [9 Regression] ICE: [[no_unique_address] when constructing via template helper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93711 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jason Merrill --- Fixed in 10.2 and later.
[Bug c++/52830] ICE: "canonical types differ for identical types ..." when attempting SFINAE with member type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830 Jason Merrill changed: What|Removed |Added Known to work||12.0 CC||jason at gcc dot gnu.org --- Comment #14 from Jason Merrill --- This seems to be fixed on trunk.
[Bug c++/103809] New: spurious reporting of structure redefinition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103809
Bug ID: 103809
Summary: spurious reporting of structure redefinition
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: florin at iucha dot net
Target Milestone: ---
Consider the following program:
/*/
#include
namespace priv
{
template
struct Struct {};
}
#ifdef SHOW_BUG
template
struct priv::Struct {};
// This way results in:
// :19:14: error: redefinition of 'struct priv::Struct'
// 19 | struct priv::Struct {};
// | ^
template
struct priv::Struct {};
#else
namespace priv
{
template
struct Struct {};
template
struct Struct {};
}
#endif
int main() {}
/*/
Compiling with "g++ -std=c++20 -DSHOW_BUG" results in
:19:14: error: redefinition of 'struct priv::Struct'
19 | struct priv::Struct {};
| ^
:12:14: note: previous definition of 'struct priv::Struct'
12 | struct priv::Struct {};
| ^~~~
ASM generation compiler returned: 1
:19:14: error: redefinition of 'struct priv::Struct'
19 | struct priv::Struct {};
| ^
:12:14: note: previous definition of 'struct priv::Struct'
12 | struct priv::Struct {};
| ^~~~
Compiling without SHOW_BUG results in no error.
(Bug found by my colleague, Ramon Sibello).
[Bug c++/103700] Incomplete type not causing constraints to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103700 --- Comment #4 from Patrick Palka --- (In reply to Andrew Pinski from comment #3) > I think the right patch is to check to see if the pointed to type is > complete in pointer_int_sum before calling size_in_bytes_loc. But there is > no function call that is common between the C and C++ front-ends to check > that. Hmm, can't we just check COMPLETE_TYPE_P in pointer_int_sum directly? Patch to that effect posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587300.html.
[Bug debug/103808] New: [12 Regression] '-fcompare-debug' failure (length) w/ -O2 -ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103808
Bug ID: 103808
Summary: [12 Regression] '-fcompare-debug' failure (length) w/
-O2 -ftrapv
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc 12.0.0 20211219 snapshot (g:fcbf94a5be9e0c1ecad92da773a6632b86b7f70a) fails
-fcompare-debug check when compiling the following testcase w/ -O2 -ftrapv:
void
foo (__int128 x, int y)
{
for (;;)
{
__int128 a, b;
x |= !!y;
a = x + 1;
b = y ? ++y : ++x;
y = a < b;
if (x >> 2)
y *= 2;
if (y == b)
__builtin_unreachable ();
}
}
% x86_64-unknown-linux-gnu-gcc-12.0.0 -O2 -fcompare-debug -ftrapv -c ddz9adk2.c
x86_64-unknown-linux-gnu-gcc-12.0.0: error: ddz9adk2.c: '-fcompare-debug'
failure (length)
--- ddz9adk2.c.gkd 2021-12-23 00:04:28.297518259 +0700
+++ ddz9adk2.gk.c.gkd 2021-12-23 00:04:28.387512439 +0700
@@ -6,11 +6,11 @@
(note # 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note # 0 0 NOTE_INSN_DELETED)
(note # 0 0 NOTE_INSN_DELETED)
-(insn/f:TI # 0 0 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [ S8 A8])
+(insn/f:TI # 0 0 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp [ x+8 ])) [ S8
A8])
(reg:DI 42 r14)) "ddz9adk2.c":3:1# {*pushdi2_rex64}
(expr_list:REG_DEAD (reg:DI 42 r14)
(nil)))
-(insn/f:TI # 0 0 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [ S8 A8])
+(insn/f:TI # 0 0 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp [ x+8 ])) [ S8
A8])
(reg:DI 41 r13)) "ddz9adk2.c":3:1# {*pushdi2_rex64}
(expr_list:REG_DEAD (reg:DI 41 r13)
(nil)))
@@ -18,7 +18,7 @@
(reg:DI 4 si [123])) "ddz9adk2.c":3:1# {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 4 si [123])
(nil)))
-(insn/f:TI # 0 0 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [ S8 A8])
+(insn/f:TI # 0 0 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp [ x+8 ])) [ S8
A8])
(reg:DI 40 r12)) "ddz9adk2.c":3:1# {*pushdi2_rex64}
(expr_list:REG_DEAD (reg:DI 40 r12)
(nil)))
@@ -26,11 +26,11 @@
(reg:DI 5 di [122])) "ddz9adk2.c":3:1# {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 5 di [122])
(nil)))
-(insn/f:TI # 0 0 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [ S8 A8])
+(insn/f:TI # 0 0 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp [ x+8 ])) [ S8
A8])
(reg:DI 6 bp)) "ddz9adk2.c":3:1# {*pushdi2_rex64}
(expr_list:REG_DEAD (reg:DI 6 bp)
(nil)))
-(insn/f:TI # 0 0 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [ S8 A8])
+(insn/f:TI # 0 0 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp [ x+8 ])) [ S8
A8])
(reg:DI 3 bx)) "ddz9adk2.c":3:1# {*pushdi2_rex64}
(expr_list:REG_DEAD (reg:DI 3 bx)
(nil)))
[Bug c++/103700] Incomplete type not causing constraints to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103700 Patrick Palka changed: What|Removed |Added Last reconfirmed||2021-12-22 Target Milestone|--- |11.3 CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug tree-optimization/91384] [9/10/11/12 Regression] Compare with negation is not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
--- Comment #14 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #13)
> LLVM is able to produce the neg/branch combo now while GCC is not.
One more testcase:
void foo (void);
void bar (void);
int g(int, int);
int
test (int a)
{
int r;
if (r = -a)
foo ();
else
bar ();
return g(a,r);
}
CUT
LLVM is able to move the -a past the if statement still.
So it is not as simple as a single usage either for LLVM.
[Bug tree-optimization/91384] [9/10/11/12 Regression] Compare with negation is not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |tree-optimization
--- Comment #13 from Andrew Pinski ---
So looking at what other compilers do here.
ICC and MSVC do what GCC did in GCC 4.1.2.
LLVM does similar to what GCC does now except they also push the -a to below
the if statement.
If we have:
void foo (int);
void bar (void);
int g(int, int);
int
test (int a)
{
int r;
if (r = -a)
foo (r);
else
bar ();
return r;
}
- CUT
LLVM is able to produce the neg/branch combo now while GCC is not.
[Bug middle-end/57955] [9/10/11/12 Regression] Uniquization of constants reduces alignment of initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955
--- Comment #24 from Andrew Pinski ---
Just to summarize this bug as far as I read it, please correct me if I am
wrong; note I am not proposing a change, just trying to summarize the back and
forth since it is not obvious right away of what the problem was.
This was the testcase:
void foo(void)
{
int x[8] __attribute__((aligned(128))) = { 1, 1, 1, 1, 1, 1, 1, 1 };
bar (x);
}
Before the gimplification change the initializer {1,} was promoted to a
static const and given an alignment of 128; due to this part of the code:
if (align > DECL_ALIGN (new_tree))
{
DECL_ALIGN (new_tree) = align;
DECL_USER_ALIGN (new_tree) = 1;
}
But now it just uses DATA_ALIGNMENT (the code should be using
TARGET_CONSTANT_ALIGNMENT but does not right now, that was a proposal).
rs6000_constant_alignment (TARGET_CONSTANT_ALIGNMENT) only aligns strings csts
to word (32 or 64) aligned. rs6000_data_alignment (DATA_ALIGNMENT) only aligns
vectors to 128 and char arrays to word (32 or 64) align.
[Bug libstdc++/103805] Inconsistent exception specifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103805 --- Comment #6 from Martin Reinecke --- Ouch. That reminds me when Redhat(?) did the same many years ago and caused no end of confusion. Anyway, sorry for the noise!
[Bug libstdc++/103805] Inconsistent exception specifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103805 Jonathan Wakely changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #5 from Jonathan Wakely --- Debian must have backported some changes, but not the fix for this bug. I don't know why they don't call it 11.2.1, that's what the snapshot numbering is for.
[Bug libstdc++/103805] Inconsistent exception specifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103805 --- Comment #4 from Martin Reinecke --- Sorry if I specified the wrong version. My local (Debian unstable) g++ reports martin@marvin:~/codes/ducc$ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 11.2.0-12' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-RMIFfM/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-RMIFfM/gcc-11-11.2.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.2.0 (Debian 11.2.0-12) Not sure how I got the libstdc++ 11.2.1 then, maybe some Debian packaging issue. Anyway I"m very glad that this is already fixed!
[Bug c++/103807] Unable to make template class instance with default parameter of lambda::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103807 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/103797] Clang vectorized LightPixel while GCC does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797 --- Comment #9 from hubicka at kam dot mff.cuni.cz --- > recip pass happens after vectorization > I don't know/understand why though. Yep, I suppose we want to either special case this in vectorizer or make it earlier... I also wonder why the code is vectorized for pairs of values and third one is computed separately and why we don't use vectors of length 4...
[Bug libstdc++/103805] Inconsistent exception specifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103805 Jonathan Wakely changed: What|Removed |Added Version|11.2.0 |11.2.1 --- Comment #3 from Jonathan Wakely --- (In reply to Martin Reinecke from comment #0) > It seems that some functions in the libstdc++ header files shipped with g++ > 11.2.0 have inconsistent exception specification fora few functions. This is wrong, the problem was never in the 11.2.0 release. You must be using an 11.2.1 snapshot, and it's already been fixed in the 11.2.1 snapshots since early November.
[Bug libstdc++/103805] Inconsistent exception specifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103805 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- And r11-9264
[Bug tree-optimization/103797] Clang vectorized LightPixel while GCC does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797 --- Comment #8 from Andrew Pinski --- (In reply to Jan Hubicka from comment #7) > Having this however I do not see slp analyzing the divide in the original > code at all. recip pass happens after vectorization I don't know/understand why though.
[Bug c++/103807] Unable to make template class instance with default parameter of lambda::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103807 Andrew Pinski changed: What|Removed |Added Depends on||97700 --- Comment #1 from Andrew Pinski --- Very similar to PR 97700 if not a dup of that bug. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97700 [Bug 97700] Bogus error when a class containing a function pointer is used as a non-type template parameter
[Bug c++/103807] New: Unable to make template class instance with default parameter of lambda::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103807
Bug ID: 103807
Summary: Unable to make template class instance with default
parameter of lambda::function
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
Below code:
```
template
struct A {};
int main() {
[[maybe_unused]] A x;
}
```
is accepted by Clang and MSVC.
But GCC prints the error:
```
error: class template argument deduction failed:
5 | [[maybe_unused]] A x;
|^
:5:24: error: no matching function for call to 'A()'
```
Demo: https://gcc.godbolt.org/z/4azGT5fso
[Bug libstdc++/103805] Inconsistent exception specifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103805 Andrew Pinski changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- Fixed on the trunk with r12-4963
[Bug c++/103806] internal compiler error: in vague_linkage_p, at cp/decl2.c:2192 for pdp11-aout target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103806 --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc/2018-July/226847.html
[Bug tree-optimization/103797] Clang vectorized LightPixel while GCC does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7 from Jan Hubicka ---
OK, here is completely fake testcase that does similar operaitons:
#include
struct test {float x; float y; float z;} test;
float f;
void
t()
{
float x = test.x;
float y = test.y;
float z = test.z;
x = x * f;
y = y * f;
z = z * f;
x = sqrt (x);
y = sqrt (y);
z = sqrt (z);
x = x / f;
y = y / f;
z = z / f;
test.x=x;
test.y=y;
test.z=z;
}
We seem to fail to vectorize it with:
t.c:20:9: missed: op not supported by target.
t.c:17:5: missed: not vectorized: relevant stmt not supported: x_15 = x_24 /
f.0_1;
clang seems to use divps happilly, so I am not sure why it is not supported.
Even more funny is that with -Ofast it is compiled into multiplication by
reciprocal:
t:
.LFB0:
.cfi_startproc
movss f(%rip), %xmm4
movss .LC0(%rip), %xmm2
movss test(%rip), %xmm0
movss test+4(%rip), %xmm3
divss %xmm4, %xmm2
movss test+8(%rip), %xmm1
mulss %xmm4, %xmm0
mulss %xmm4, %xmm3
mulss %xmm4, %xmm1
sqrtss %xmm0, %xmm0
sqrtss %xmm3, %xmm3
sqrtss %xmm1, %xmm1
mulss %xmm2, %xmm0
mulss %xmm2, %xmm3
mulss %xmm2, %xmm1
unpcklps%xmm3, %xmm0
movlps %xmm0, test(%rip)
movss %xmm1, test+8(%rip)
ret
and rewriting it that way by hand:
#include
struct test {float x; float y; float z;} test;
float f;
void
t()
{
float x = test.x;
float y = test.y;
float z = test.z;
float m = 1/f;
x = x * f;
y = y * f;
z = z * f;
x = sqrt (x);
y = sqrt (y);
z = sqrt (z);
x = x * m;
y = y * m;
z = z * m;
test.x=x;
test.y=y;
test.z=z;
}
gets the expected result:
t:
.LFB0:
.cfi_startproc
movss f(%rip), %xmm0
movqtest(%rip), %xmm1
movaps %xmm0, %xmm2
shufps $0xe0, %xmm2, %xmm2
mulps %xmm1, %xmm2
movss .LC0(%rip), %xmm1
divss %xmm0, %xmm1
mulss test+8(%rip), %xmm0
sqrtps %xmm2, %xmm2
sqrtss %xmm0, %xmm0
movaps %xmm1, %xmm3
shufps $0xe0, %xmm3, %xmm3
mulss %xmm0, %xmm1
mulps %xmm3, %xmm2
movss %xmm1, test+8(%rip)
movlps %xmm2, test(%rip)
ret
.cfi_endproc
Having this however I do not see slp analyzing the divide in the original code
at all.
[Bug middle-end/93902] conversion from 64-bit long or unsigned long to double prevents simple optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93902
--- Comment #3 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #2)
> foo3 is more complex because x86 does not have an unsigned long 64bit to
> double so it has to do some more complex.
But the point is that GCC shouldn't do the conversion at all. It just needs to
notice that the converted value cannot be NaN. The tests can currently be
simplified as follows:
void foo5 (unsigned int a)
{
double b = a;
if (b != b)
bar ();
}
void foo6 (unsigned long a)
{
double b = a;
if (b != b)
bar ();
}
For foo5, one just gets a "ret", i.e. everything has been optimized. For foo6,
GCC does the conversion to double, then the comparison. However, the test b !=
b is always false unless b is NaN; but since b comes from an integer, it cannot
be NaN, i.e. foo6 is equivalent to
void foo7 (unsigned long a)
{
double b = a;
if (0)
bar ();
}
which is fully optimized.
Note that here, foo6 is fully optimized if -ffinite-math-only is provided (but
foo3 still isn't).
Perhaps what is missing is NaN tracking (which would be much simpler than VRP
on floating-point values).
[Bug c++/102050] Nonempty list-initialization rejects constructor with defaulted std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102050 Patrick Palka changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #3 from Patrick Palka --- *** Bug 60437 has been marked as a duplicate of this bug. ***
[Bug c++/60437] [C++11] Bogus "error: no matching function for call to 'X::X()'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60437 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org --- Comment #6 from Patrick Palka --- Fixed with r12-3555. *** This bug has been marked as a duplicate of bug 102050 ***
[Bug c++/103806] internal compiler error: in vague_linkage_p, at cp/decl2.c:2192 for pdp11-aout target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103806 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-12-22 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Please provide a pre-processes source file (-E option).
[Bug target/103804] ICE: 'global_options' are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103804 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-12-22 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Martin Liška --- Mine.
[Bug libfortran/53962] Tab handling with formatted stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53962 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #3 from Francois-Xavier Coudert --- I'm wondering. I've been reading Fortran 2008: > 10.8.1.1 T, TL, and TR editing > The left tab limit acts file positioning by the T and TL edit descriptors. > Immediately prior to nonchild data transfer (9.6.4.8.2), the left tab limit > becomes defined as the character position of the current record or the current > position of the stream file. If, during data transfer, the file is positioned > to another record, the left tab limit becomes defined as character position > one of that record. Doesn't that mean that for stream file, the left tab limit becomes defined as the current position at the end of "Kilroy was here", and the next position needs to be counted from that position? Probably my reading is wrong, but I'm not sure why. Intel definitely agrees with the bug report, says the output should be the same in both cases.
[Bug libstdc++/103801] Link tests are not allowed after GCC_NO_EXECUTABLES. for pdp11-aout target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103801 --- Comment #4 from cqwrteur --- (In reply to cqwrteur from comment #3) > (In reply to Andrew Pinski from comment #1) > > Did you build newlib along side GCC? Or did you do the two steps of building > > GCC with C only and then newlib and then GCC with C++ support? > > I suggest removing pdp11 target support if it is so buggy. remove the entire backend from GCC.
[Bug libstdc++/103801] Link tests are not allowed after GCC_NO_EXECUTABLES. for pdp11-aout target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103801 --- Comment #3 from cqwrteur --- (In reply to Andrew Pinski from comment #1) > Did you build newlib along side GCC? Or did you do the two steps of building > GCC with C only and then newlib and then GCC with C++ support? I suggest removing pdp11 target support if it is so buggy.
[Bug libstdc++/103801] Link tests are not allowed after GCC_NO_EXECUTABLES. for pdp11-aout target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103801 --- Comment #2 from cqwrteur --- (In reply to Andrew Pinski from comment #1) > Did you build newlib along side GCC? Or did you do the two steps of building > GCC with C only and then newlib and then GCC with C++ support? I tried newlib, newlib said it does not support pdp11-aout target anymore.
[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #19 from Segher Boessenkool ---
(In reply to luoxhu from comment #17)
> And what do you mean"This is not canonical form on RTL, and it's not a
> useful form either" in c#7, please? Not understanding the point...
On Gimple it is canonical to convert (a)|(b&~c) to ((a^b))^b), because
all Gimple cares about is number of operations (and it counts unary operations
as well, so this is three instead of four ops).
For RTL we do not have such a simple-minded rule.
> --- a/gcc/simplify-rtx.c
> +++ b/gcc/simplify-rtx.c
> @@ -3405,7 +3405,6 @@ simplify_context::simplify_binary_operation_1
> (rtx_code code,
> machines, and also has shorter instruction path length. */
>if (GET_CODE (op0) == AND
> && GET_CODE (XEXP (op0, 0)) == XOR
> - && CONST_INT_P (XEXP (op0, 1))
> && rtx_equal_p (XEXP (XEXP (op0, 0), 0), trueop1))
> {
> rtx a = trueop1;
> @@ -3419,7 +3418,6 @@ simplify_context::simplify_binary_operation_1
> (rtx_code code,
>/* Similarly, (xor (and (xor A B) C) B) as (ior (and A C) (and B ~C))
> */
>else if (GET_CODE (op0) == AND
> && GET_CODE (XEXP (op0, 0)) == XOR
> - && CONST_INT_P (XEXP (op0, 1))
> && rtx_equal_p (XEXP (XEXP (op0, 0), 1), trueop1))
> {
> rtx a = XEXP (XEXP (op0, 0), 0);
It needs *some* test on it. It certainly cannot have side effects for
example. CONST_INT_P || REG_P should catch all useful cases?
[Bug tree-optimization/103797] Clang vectorized LightPixel while GCC does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797 --- Comment #6 from Martin Liška --- You may try exporting GIMPLE IL that can be consumed with -fgimple.
[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323 --- Comment #18 from Segher Boessenkool --- (In reply to luoxhu from comment #16) > > +2016-11-09 Segher Boessenkool > > + > > + * simplify-rtx.c (simplify_binary_operation_1): Simplify > > + (xor (and (xor A B) C) B) to (ior (and A C) (and B ~C)) and > > + (xor (and (xor A B) C) A) to (ior (and A ~C) (and B C)) if C > > + is a const_int. > > > Is it a MUST that C be const here? It could be extended to C a reg as well, I think.
[Bug c++/103806] New: internal compiler error: in vague_linkage_p, at cp/decl2.c:2192 for pdp11-aout target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103806 Bug ID: 103806 Summary: internal compiler error: in vague_linkage_p, at cp/decl2.c:2192 for pdp11-aout target Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Created attachment 52043 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52043=edit error message
[Bug libstdc++/103805] New: Inconsistent exception specifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103805 Bug ID: 103805 Summary: Inconsistent exception specifications Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mar...@mpa-garching.mpg.de Target Milestone: --- I'm not really sure how to report this one properly, so please let me know if crucial information is missing! It seems that some functions in the libstdc++ header files shipped with g++ 11.2.0 have inconsistent exception specification fora few functions. g++ itself doesn't seem to care, but clang++-13 is unhappy, providing the error message: clang-13 -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DPKGNAME=ducc0 -DPKGVERSION=0.22.0 -I. -I./src/ -I/home/martin/.local/lib/python3.9/site-packages/pybind11/include -I/home/martin/.local/lib/python3.9/site-packages/pybind11/include -I/usr/include/python3.9 -c python/ducc.cc -o build/temp.linux-x86_64-3.9/python/ducc.o -std=c++17 -fvisibility=hidden -g0 -ffast-math -O3 -march=native -Wfatal-errors -Wfloat-conversion -W -Wall -Wstrict-aliasing -Wwrite-strings -Wredundant-decls -Woverloaded-virtual -Wcast-qual -Wcast-align -Wpointer-arith -pthread In file included from python/ducc.cc:12: In file included from ./python/fft_pymod.cc:41: In file included from /home/martin/.local/lib/python3.9/site-packages/pybind11/include/pybind11/stl.h:21: /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/valarray:1215:5: fatal error: exception specification in declaration does not match previous declaration begin(valarray<_Tp>& __va) noexcept ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/range_access.h:107:31: note: previous declaration is here template _Tp* begin(valarray<_Tp>&); ^ At first glance, clang seems to be perfectly right in complaining about this, but I'm not sure how much libstdc++ is supposed to be interoperable with other compilers. Anyway, if the C++ standard mandates that all declarations have the same exception specification and g++ just doesn't enforce this at the moment, it might still be good to update the headers to be more future-proof.
[Bug tree-optimization/103797] Clang vectorized LightPixel while GCC does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797 --- Comment #5 from hubicka at kam dot mff.cuni.cz --- Created attachment 52042 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52042=edit b.slp1
[Bug tree-optimization/103797] Clang vectorized LightPixel while GCC does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797
--- Comment #4 from hubicka at kam dot mff.cuni.cz ---
> -E and remove not needed code.
>
> > The
> > declaratoins are quite convoluted, but the function is well isolated and
> > easy to inspect from full one...
>
> Do we speak about:
> https://github.com/mozilla/gecko-dev/blob/bd25b1ca76dd5d323ffc69557f6cf759ba76ba23/gfx/2d/FilterNodeSoftware.cpp#L3670-L3691
> ?
Yes.
>
> It should be possible creating a synthetical test that does the same (and
> lives
> in a loop, right?).
Well, I tried that for a while and got bit lost (either code got
vectorized by both gcc and clang or by neither). There are more issues
where we have over 50% regression wrt clang build at gfx code, so I
think I will first try to reproduce those locally and perf them to see
if there is more pattern here.
The releavant code is:
uint32_t mozilla::gfx::{anonymous}::SpecularLightingSoftware::LightPixel
(struct SpecularLightingSoftware * const this, const struct Point3D & aNormal,
const struct Point3D & aVectorToLight, uint32_t aColor)
{
[local count: 118111600]:
_48 = MEM[(const struct BasePoint3D
*)aVectorToLight_25(D)].D.75826.D.75829.z;
_49 = _48 + 1.0e+0;
_50 = MEM[(const struct BasePoint3D
*)aVectorToLight_25(D)].D.75826.D.75829.y;
_51 = _50 + 0.0;
_52 = MEM[(const struct BasePoint3D
*)aVectorToLight_25(D)].D.75826.D.75829.x;
_53 = _52 + 0.0;
_80 = _53 * _53;
_82 = _51 * _51;
_83 = _80 + _82;
_85 = _49 * _49;
_86 = _83 + _85;
if (_86 u>= 0.0)
goto ; [99.95%]
else
goto ; [0.05%]
[local count: 118052545]:
_87 = .SQRT (_86);
goto ; [100.00%]
[local count: 59055]:
_29 = __builtin_sqrtf (_86);
[local count: 118111600]:
# _30 = PHI <_29(4), _87(3)>
_88 = _53 / _30;
_89 = _51 / _30;
_90 = _49 / _30;
_41 = MEM[(const struct BasePoint3D *)aNormal_26(D)].D.75826.D.75829.x;
_39 = _41 * _88;
_37 = MEM[(const struct BasePoint3D *)aNormal_26(D)].D.75826.D.75829.y;
_33 = _37 * _89;
_27 = _33 + _39;
_45 = MEM[(const struct BasePoint3D *)aNormal_26(D)].D.75826.D.75829.z;
_46 = _45 * _90;
_47 = _27 + _46;
if (_47 >= 0.0)
goto ; [59.00%]
else
goto ; [41.00%]
With -Ofast it gets bit more streamlined:
[local count: 118111600]:
_48 = MEM[(const struct BasePoint3D
*)aVectorToLight_25(D)].D.75826.D.75829.z;
_49 = _48 + 1.0e+0;
_50 = MEM[(const struct BasePoint3D
*)aVectorToLight_25(D)].D.75826.D.75829.y;
_51 = MEM[(const struct BasePoint3D
*)aVectorToLight_25(D)].D.75826.D.75829.x;
powmult_78 = _51 * _51;
powmult_80 = _50 * _50;
_81 = powmult_78 + powmult_80;
powmult_83 = _49 * _49;
_84 = _81 + powmult_83;
_85 = __builtin_sqrtf (_84);
_86 = _51 / _85;
_87 = _50 / _85;
_88 = _49 / _85;
_41 = MEM[(const struct BasePoint3D *)aNormal_26(D)].D.75826.D.75829.x;
_39 = _41 * _86;
_37 = MEM[(const struct BasePoint3D *)aNormal_26(D)].D.75826.D.75829.y;
_33 = _37 * _87;
_27 = _33 + _39;
_45 = MEM[(const struct BasePoint3D *)aNormal_26(D)].D.75826.D.75829.z;
_46 = _45 * _88;
_47 = _27 + _46;
if (_47 >= 0.0)
goto ; [59.00%]
else
goto ; [41.00%]
But I do not quite see in the slp dump why this is not considered for
vectorization.
I attach the dump.
Honza
