[Bug rtl-optimization/105988] [10/11/12/13 Regression] ICE in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1064 since r6-4873-gebedc9a3414d8422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105988 rdapp at gcc dot gnu.org changed: What|Removed |Added Target|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu s390 --- Comment #6 from rdapp at gcc dot gnu.org --- We are also seeing this on s390 as well as several other problems with -fmodulo-sched. Is this pass here to stay or is it safe to ignore all issues/FAILs with it because it's going away anyway? Regards Robin
[Bug target/106532] riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106532 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.0 --- Comment #8 from Andrew Pinski --- Fixed for GCC 13 r13-1970-gffe4f55aa1bb18cc2793a4335450f34c33c9d01c If someone wants to backport it for GCC 12. Be my guest.
[Bug target/106532] riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106532 --- Comment #7 from Andrew Pinski --- So this has been broken since ZBS support was added in r12-4658-g4e1e0d79ecbe87 . Removing TARGET_64BIT from the check in splittable_const_int_operand fixes this testcase but I have not done any more testing.
[Bug target/106532] riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106532
--- Comment #6 from Andrew Pinski ---
Oh why oh why:
/* Check whether the constant can be loaded in a single
instruction with zbs extensions. */
if (TARGET_64BIT && TARGET_ZBS && SINGLE_BIT_MASK_OPERAND (INTVAL (op)))
return false;
But:
if (TARGET_ZBS && SINGLE_BIT_MASK_OPERAND (value))
{
/* Simply BSETI. */
codes[0].code = UNKNOWN;
codes[0].value = value;
/* RISC-V sign-extends all 32bit values that live in a 32bit
register. To avoid paradoxes, we thus need to use the
sign-extended (negative) representation (-1 << 31) for the
value, if we want to build (1 << 31) in SImode. This will
then expand to an LUI instruction. */
if (mode == SImode && value == (HOST_WIDE_INT_1U << 31))
codes[0].value = (HOST_WIDE_INT_M1U << 31);
return 1;
}
[Bug target/106532] riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106532
--- Comment #5 from Andrew Pinski ---
Even more reduced (this is why uninitialized variable was needed to form the
2048 :) ):
int g (void)
{
return 2048;
}
[Bug target/106532] riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106532
--- Comment #4 from Andrew Pinski ---
Shorter testcase (uninitialized variable is required for the reduced testcase;
I don't know why yet):
int g (long B_e)
{
long A_e;
if (A_e != 2047)
A_e -= 1023;
return A_e + 1;
}
[Bug target/106531] -march=rv32iabmc should also enable zba, zbb, zbc, zbs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106531 --- Comment #3 from Andrew Waterman --- The lengthy-ISA-name problem will be addressed to a great extent by the forthcoming introduction of ISA profiles. Although I agree the status quo is ugly and overly verbose, I recommend against introducing GCC-specific syntax for shortening ISA strings, since it'll quickly become legacy.
[Bug target/106531] -march=rv32iabmc should also enable zba, zbb, zbc, zbs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106531 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Waterman from comment #1) > It turns out there is no such thing as the B extension; it was a working > name for a draft proposal a few years ago but wasn't (and presumably won't > be) ratified. The correct behavior is to reject B but accept zba, zbb, zbc, > and zbs. -march=rv32imac_zba_zbb_zbc_zbs works but that is just so bad. Really b should just mean all 4 really; it should be a meta ISA extension :). There is so much no documentation on what ISA names; that I had to just guess.
[Bug target/106532] riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106532 --- Comment #3 from Andrew Pinski --- Note with a non-modified sources fails with -O2 -march=rv32imac_zba_zbb_zbc_zbs
[Bug target/106531] -march=rv32iabmc should also enable zba, zbb, zbc, zbs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106531 Andrew Waterman changed: What|Removed |Added CC||andrew at sifive dot com --- Comment #1 from Andrew Waterman --- It turns out there is no such thing as the B extension; it was a working name for a draft proposal a few years ago but wasn't (and presumably won't be) ratified. The correct behavior is to reject B but accept zba, zbb, zbc, and zbs.
[Bug target/106532] riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106532 --- Comment #2 from Andrew Pinski --- Created attachment 53414 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53414=edit testcase from -freport-bug
[Bug target/106532] riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106532 Andrew Pinski changed: What|Removed |Added Severity|normal |blocker Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- Mine, will debug in a few minutes.
[Bug target/106532] New: riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106532 Bug ID: 106532 Summary: riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: riscv32-*-elf Error message: ../../../src/libgcc/soft-fp/muldf3.c: In function ‘__muldf3’: ../../../src/libgcc/soft-fp/muldf3.c:51:1: error: unrecognizable insn: 51 | } | ^ (insn 430 429 431 29 (set (reg:SI 332) (const_int 2048 [0x800])) "../../../src/libgcc/soft-fp/muldf3.c":46:3 -1 (expr_list:REG_EQUAL (const_int 2048 [0x800]) (nil))) during RTL pass: vregs ../../../src/libgcc/soft-fp/muldf3.c:51:1: internal compiler error: in extract_insn, at recog.cc:2791 # If this is the top-level multilib, build all the other
[Bug target/106531] New: -march=rv32iabmc should also enable zba, zbb, zbc, zbs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106531 Bug ID: 106531 Summary: -march=rv32iabmc should also enable zba, zbb, zbc, zbs Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: pinskia at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: riscv While doing some development, I Noticed that -march=rv32iabmc does not work (binutils as fails but that is a different issue) and the zba, zbb, zbc, and zbs extensions are not enabled like I think they should be. I am filing this bug to remind me to submit the patch for this.
[Bug target/106529] existence of sincos is assumed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106529 --- Comment #5 from Thomas Klausner --- For context, I stumbled over this because meson misdetects sincos on NetBSD. https://github.com/mesonbuild/meson/issues/10641
[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780 --- Comment #6 from Marek Polacek --- The warning warns about dubious uses of std::move, so in the noMove case we won't warn at all since there's no std::move. In the withMove case, in C++20, we issue: warning: moving a local object in a return statement prevents copy elision for template Dest withMove(); and: warning: redundant move in return statement for template Dest withMove(); In C++17, we issue one (wrong) warning, as originally reported. With my patch, we won't issue any warnings, because I'm not sure if we can say that in *any* instantiation of withMove the std::move is wrong. Am I mistaken? Thanks for your comments and sorry if I'm still not getting your point.
[Bug target/106530] RISCV documentation for -march= is very lacking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106530 --- Comment #1 from Andrew Pinski --- Compare this to how aarch64 documentation is expands on what -march= options are valid: https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#aarch64-feature-modifiers (plus I find long names much easier to understand than just letters too but that is a RISC-V issue overall when it comes to naming their extensions and maybe should be brought up to the specifications working group).
[Bug target/106530] New: RISCV documentation for -march= is very lacking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106530 Bug ID: 106530 Summary: RISCV documentation for -march= is very lacking Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: riscv*-*-* The current documentation for -march= does not specify what extensions are valid or really anything. It just shows examples. The documentation should say what each letter corresponds to and maybe even point to the specifications link. E.g. what does 'rv32iabmc' mean?
[Bug target/106529] existence of sincos is assumed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106529
--- Comment #4 from Thomas Klausner ---
Well, I can one-up that one:
int sincos();
int main() {
return sincos();
}
gives:
sincos.c:1:5: warning: conflicting types for built-in function ‘sincos’;
expected ‘void(double, double *, double *)’ [-Wbuiltin-declaration-mismatch]
1 | int sincos();
| ^~
sincos.c:1:1: note: ‘sincos’ is declared in header ‘’
+++ |+#include
1 | int sincos();
ld: /tmp//ccO3U7pd.o: in function `main':
sincos.c:(.text+0xa): undefined reference to `sincos'
a) there is no conflict since there is no builtin or otherwise sincos()
function
b) it is not declared in math.h
the linker warning is correct though :)
[Bug c/106529] existence of sincos is assumed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106529 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic --- Comment #3 from Jonathan Wakely --- Those warnings just match a predefined list of names and suggest the right header. If 'sincos' is not found, it says to include , there's no check for which OS you're on or whether math.h has been included already. It's much simpler than that. Yes, sometimes including isn't the solution, but it does say "or provide a declaration of sincos" so it's not wrong.
[Bug c/106529] existence of sincos is assumed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106529 --- Comment #2 from Thomas Klausner --- Created attachment 53413 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53413=edit .s file from save-temps
[Bug c/106529] existence of sincos is assumed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106529 --- Comment #1 from Thomas Klausner --- Created attachment 53412 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53412=edit .i file from save-temps
[Bug c/106529] New: existence of sincos is assumed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106529
Bug ID: 106529
Summary: existence of sincos is assumed
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tk at giga dot or.at
Target Milestone: ---
Host: NetBSD/amd64
Target: NetBSD/amd64
Build: NetBSD/amd64
Created attachment 53411
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53411=edit
second example
NetBSD does not provide sincos (perhaps it should).
gcc 12.1.0 reports warnings that make no sense here.
Example program 1:
# cat >> sincos.c
int main() {
return sincos();
}
# gcc -o sincos sincos.c
sincos.c: In function ‘main’:
sincos.c:2:8: warning: implicit declaration of function ‘sincos’
[-Wimplicit-function-declaration]
2 | return sincos();
|^~
sincos.c:1:1: note: include ‘’ or provide a declaration of ‘sincos’
+++ |+#include
1 | int main() {
sincos.c:2:8: warning: incompatible implicit declaration of built-in function
‘sincos’ [-Wbuiltin-declaration-mismatch]
2 | return sincos();
|^~
sincos.c:2:8: note: include ‘’ or provide a declaration of ‘sincos’
sincos.c:2:8: error: too few arguments to function ‘sincos’
I agree that in general it is helpful to include math.h for sincos(), but not
on NetBSD, where sincos() is not provided by libc.
Even more confusing, the warning comes even when math.h is already included -
example 2:
# cat > sincos.c
#include
int main() {
return sincos();
}
# gcc -o sincos sincos.c
sincos.c: In function ‘main’:
sincos.c:3:8: warning: implicit declaration of function ‘sincos’
[-Wimplicit-function-declaration]
3 | return sincos();
|^~
sincos.c:2:1: note: include ‘’ or provide a declaration of ‘sincos’
1 | #include
+++ |+#include
2 | int main() {
sincos.c:3:8: warning: incompatible implicit declaration of built-in function
‘sincos’ [-Wbuiltin-declaration-mismatch]
3 | return sincos();
|^~
sincos.c:3:8: note: include ‘’ or provide a declaration of ‘sincos’
sincos.c:3:8: error: too few arguments to function ‘sincos’
Environment details:
# gcc -v
Using built-in specs.
COLLECT_GCC=/usr/pkg/gcc12/bin/gcc
COLLECT_LTO_WRAPPER=/usr/pkg/gcc12/libexec/gcc/x86_64--netbsd/12.1.0/lto-wrapper
Target: x86_64--netbsd
Configured with: ../gcc-12.1.0/configure --disable-libstdcxx-pch --enable-nls
--with-libiconv-prefix=/usr --enable-__cxa_atexit
--with-gxx-include-dir=/usr/pkg/gcc12/include/c++/ --disable-libssp
--enable-languages='c obj-c++ objc fortran c++' --enable-shared
--enable-long-long --with-local-prefix=/usr/pkg/gcc12 --enable-threads=posix
--with-boot-ldflags='-static-libstdc++ -static-libgcc -Wl,-R/usr/pkg/lib
-Wl,-zrelro -Wl,-znow ' --without-zstd --with-arch=nocona --with-tune=nocona
--with-fpmath=sse --with-system-zlib --with-gnu-ld --with-ld=/usr/bin/ld
--with-gnu-as --with-as=/usr/bin/as --prefix=/usr/pkg/gcc12
--build=x86_64--netbsd --host=x86_64--netbsd --infodir=/usr/pkg/gcc12/info
--mandir=/usr/pkg/gcc12/man
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC)
Running on NetBSD-9.99.99/amd64.
Savetemps:
/usr/pkg/gcc12/bin/gcc -v -save-temps sincos.c -o sincos
Using built-in specs.
COLLECT_GCC=/usr/pkg/gcc12/bin/gcc
COLLECT_LTO_WRAPPER=/usr/pkg/gcc12/libexec/gcc/x86_64--netbsd/12.1.0/lto-wrapper
Target: x86_64--netbsd
Configured with: ../gcc-12.1.0/configure --disable-libstdcxx-pch --enable-nls
--with-libiconv-prefix=/usr --enable-__cxa_atexit
--with-gxx-include-dir=/usr/pkg/gcc12/include/c++/ --disable-libssp
--enable-languages='c obj-c++ objc fortran c++' --enable-shared
--enable-long-long --with-local-prefix=/usr/pkg/gcc12 --enable-threads=posix
--with-boot-ldflags='-static-libstdc++ -static-libgcc -Wl,-R/usr/pkg/lib
-Wl,-zrelro -Wl,-znow ' --without-zstd --with-arch=nocona --with-tune=nocona
--with-fpmath=sse --with-system-zlib --with-gnu-ld --with-ld=/usr/bin/ld
--with-gnu-as --with-as=/usr/bin/as --prefix=/usr/pkg/gcc12
--build=x86_64--netbsd --host=x86_64--netbsd --infodir=/usr/pkg/gcc12/info
--mandir=/usr/pkg/gcc12/man
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sincos' '-mtune=nocona'
'-march=nocona'
/usr/pkg/gcc12/libexec/gcc/x86_64--netbsd/12.1.0/cc1 -E -quiet -v sincos.c
-mtune=nocona -march=nocona -fpch-preprocess -o sincos.i
ignoring nonexistent directory
"/usr/pkg/gcc12/lib/gcc/x86_64--netbsd/12.1.0/../../../../x86_64--netbsd/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/pkg/gcc12/lib/gcc/x86_64--netbsd/12.1.0/include
/usr/pkg/gcc12/include
/usr/pkg/gcc12/lib/gcc/x86_64--netbsd/12.1.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sincos'
[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780 --- Comment #5 from S. Davis Herring --- Perhaps I'm misunderstanding something, but your example (as well as compiling the original example with -std=c++20, which produces the same warning but now calls Dest(Dest&&) in the noMove case) means that the warning is correct in C++20 mode (but not in C++17). If that's the case, why suppress the warning in formerly dependent contexts regardless of language version?
[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780
--- Comment #4 from Marek Polacek ---
(In reply to S. Davis Herring from comment #3)
> Does this need to be language-version-dependent, given
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1825r0.html (in
> C++20) and
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2266r3.html (in
> C++23)?
So far I couldn't find a testcase where we either
1) say that a std::move is pessimizing while it's only redundant, or
2) don't say that a std::move is redundant when it is, under the new rules.
I don't think we fully implement p2266r3 yet, maybe once we do, the warning
will have to be adjusted.
For instance, this
struct S1 { S1(); S1(S1 &&); };
struct S2 : S1 {};
S1
f (S2 s)
{
return std::move(s);
}
with -std=c++20 will warn about a redundant move in the return statement. In
C++17 it will not compile because the deleted S1(const S1&) is used.
[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780 --- Comment #3 from S. Davis Herring --- Does this need to be language-version-dependent, given https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1825r0.html (in C++20) and https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2266r3.html (in C++23)?
[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780 --- Comment #2 from Marek Polacek --- I've posted a patch for this: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599342.html Sorry it's taken so long.
[Bug libstdc++/65230] pretty-print inconsistent output for similar objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #7 from Jonathan Wakely ---
(In reply to Ulrich Drepper from comment #3)
> Again, more uniform and I'd say it should be encouraged to use std::get
> instead of .first / .second because it's compatible with std::tuple.
Which makes sense given the even-closer alignment between them in C++23 due to
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2165r4.pdf
(In reply to Ulrich Drepper from comment #5)
> Or should the std::pair output even be
>
> p1 = std::pair = {[0] = 0, [1] = 0}
>
> ??
Yes, I think that's better.
[Bug tree-optimization/106514] [12/13 Regression] ranger slowness in path query
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106514 --- Comment #3 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:8e34d92ef29a175b84cc7f5185db43656ae762bb commit r13-1965-g8e34d92ef29a175b84cc7f5185db43656ae762bb Author: Andrew MacLeod Date: Thu Aug 4 12:22:59 2022 -0400 Loop over intersected bitmaps. compute_ranges_in_block loops over the import list and then checks the same bit in exports. It is nmore efficent to loop over the intersection of the 2 bitmaps. PR tree-optimization/106514 * gimple-range-path.cc (path_range_query::compute_ranges_in_block): Use EXECUTE_IF_AND_IN_BITMAP to loop over 2 bitmaps.
[Bug target/47949] Missed optimization for -Os using xchg instead of mov.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47949 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com Status|NEW |RESOLVED Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #6 from Roger Sayle --- This suggestion has now been implemented on mainline (when using -Oz).
[Bug c/106528] New: Double semi-colon causes -Wmisleading-identation to not emit warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106528
Bug ID: 106528
Summary: Double semi-colon causes -Wmisleading-identation to
not emit warning
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: baker.dylan.c at gmail dot com
Target Milestone: ---
A double semi-colon will cause the misleading-indentation warning to miss that
a second indented statement is not part by the condiational block.
#include
int main(void) {
if (1)
printf("%s", "true);;
return 0;
return 1;
Removing the extranious semi-colon from the printf() call will correct the
problem and gcc will emit a warning as expected.
I've tested with 11.3.1 and 12.1.0, and with clang 14, which has the same
behavior. This was noticed through a macro that adds a semi-colon in the macro
definition, and then has a semi-colon following the call to the macro.
[Bug libstdc++/65230] pretty-print inconsistent output for similar objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #6 from Ulrich Drepper ---
Created attachment 53410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53410=edit
consistent pretty printing of contains
How about this patch?
I used the attached test case. With the current code 'info locals' at the end
of the function prints:
t1 = empty std::tuple
t2 = std::tuple containing = {[0] = 0}
t3 = std::tuple containing = {[0] = 0, [1] = 0}
v1 = std::vector of length 0, capacity 0
v2 = std::vector of length 1, capacity 1 = {0}
v3 = std::vector of length 2, capacity 2 = {0, 0}
va1 = std::vector of length 0, capacity 0
va2 = std::vector of length 1, capacity 1 = {0}
va3 = std::vector of length 2, capacity 2 = {0, 0}
a1 = {_M_elems = {}}
a2 = {_M_elems = {0}}
a3 = {_M_elems = {0, 0}}
p1 = {first = 0, second = 0}
b1 = std::bitset
b2 = std::bitset
b3 = std::bitset
b4 = std::bitset = {[0] = 1}
b5 = std::bitset = {[70] = 1}
With the patch it prints:
t1 = std::tuple<> = {}
t2 = std::tuple = {[0] = 0}
t3 = std::tuple = {[0] = 0, [1] = 0}
v1 = std::vector of length 0, capacity 0 = {}
v2 = std::vector of length 1, capacity 1 = {0}
v3 = std::vector of length 2, capacity 2 = {0, 0}
va1 = std::vector > of length 0, capacity 0 = {}
va2 = std::vector > of length 1, capacity 1 = {0}
va3 = std::vector > of length 2, capacity 2 = {0, 0}
a1 = std::array = {}
a2 = std::array = {0}
a3 = std::array = {0, 0}
p1 = std::pair = {[0] = 0, [1] = 0}
b1 = std::bitset<0> = {}
b2 = std::bitset<1> = {}
b3 = std::bitset<2> = {}
b4 = std::bitset<2> = {[0] = 1}
b5 = std::bitset<72> = {[70] = 1}
This is quite a change from before but I think quite consistent. NB: also
tested with _GLIBXX_DEBUG.
There is one point I'm not sure about: should the std::vector printer
explicitly show the length (capacity is no question)? This is the one
remaining inconsistency. The tuple printer does not explicitly list the number
of elements. On the other hand, to avoid making the output too long the
std::vector printer does not show the indeces and therefore the number of
elements cannot be see right away. So, maybe leave it as is?
BTW: notice that I added a pretty printer for std::array and I also added code
to recognize a standard allocator template argument to std::vector (which in
this case is not shown).
[Bug tree-optimization/106457] array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
--- Comment #6 from qinzhao at gcc dot gnu.org ---
the following patch fixed the issue:
[opc@qinzhao-aarch64-ol8 gcc]$ git diff tree.cc
diff --git a/gcc/tree.cc b/gcc/tree.cc
index fed1434d141d..d04ac121765a 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -12779,7 +12779,7 @@ array_at_struct_end_p (tree ref)
&& TREE_CODE (DECL_SIZE_UNIT (ref)) == INTEGER_CST)
{
/* If the object itself is the array it is not at struct end. */
- if (DECL_P (ref_to_array))
+ if (TREE_CODE (TREE_TYPE (ref)) == ARRAY_TYPE)
return false;
/* Check whether the array domain covers all of the available
[Bug middle-end/106519] [13 Regression] internal compiler error: in gimple_phi_arg, at gimple.h:4594 by r13-1950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106519 Tamar Christina changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Tamar Christina --- (In reply to Martin Liška from comment #7) > Is it fixed now? Yes, should be, tested the x86 -m32 failures but the other arches should be the same.
[Bug middle-end/106519] [13 Regression] internal compiler error: in gimple_phi_arg, at gimple.h:4594 by r13-1950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106519 --- Comment #7 from Martin Liška --- Is it fixed now?
[Bug c/106526] array-bounds warning on constant pointer dereferencing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106526 --- Comment #3 from Lars Wrenger --- The array-bounds warning itself is nice. In most cases, it is good if the compiler can find invalid memory accesses. However, the wording of the warning is confusing. Strictly speaking, we are not accessing an array (even if *x == x[0]).
[Bug middle-end/106519] [13 Regression] internal compiler error: in gimple_phi_arg, at gimple.h:4594 by r13-1950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106519 --- Comment #6 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:c832ec4c3ec4853ad89ff3b0dbf6e9454e75e8cc commit r13-1963-gc832ec4c3ec4853ad89ff3b0dbf6e9454e75e8cc Author: Tamar Christina Date: Thu Aug 4 16:35:31 2022 +0100 middle-end: Fix phi-ssa assertion triggers. [PR106519] For the diamond PHI form in tree_ssa_phiopt_worker we need to extract edge e2 sooner. This changes it so we extract it at the same time we determine we have a diamond shape. gcc/ChangeLog: PR middle-end/106519 * tree-ssa-phiopt.cc (tree_ssa_phiopt_worker): Check final phi edge for diamond shapes. gcc/testsuite/ChangeLog: PR middle-end/106519 * gcc.dg/pr106519.c: New test.
[Bug middle-end/105762] [12/13 Regression] -Warray-bounds false positives for integer-to-pointer casts since r12-2132-ga110855667782dac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105762 Andrew Pinski changed: What|Removed |Added CC||wrenger at sra dot uni-hannover.de --- Comment #3 from Andrew Pinski --- *** Bug 106526 has been marked as a duplicate of this bug. ***
[Bug c/106526] array-bounds warning on constant pointer dereferencing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106526 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- This is a deliberate change, dup of bug 105762. If the address is a valid address, you can also pass --param=min-pagesize=0 to say that all addresses are valid (see PR 99578). *** This bug has been marked as a duplicate of bug 105762 ***
[Bug rtl-optimization/105988] [10/11/12/13 Regression] ICE in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1064 since r6-4873-gebedc9a3414d8422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105988 Andrew Pinski changed: What|Removed |Added CC||rdapp at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- *** Bug 106527 has been marked as a duplicate of this bug. ***
[Bug middle-end/106527] ICE with modulo scheduling dump (-fdump-rtl-sms)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106527 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 105988. *** This bug has been marked as a duplicate of bug 105988 ***
[Bug middle-end/106527] New: ICE with modulo scheduling dump (-fdump-rtl-sms)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106527 Bug ID: 106527 Summary: ICE with modulo scheduling dump (-fdump-rtl-sms) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rdapp at gcc dot gnu.org CC: zhroma at gcc dot gnu.org Target Milestone: --- Host: s390 Target: s390 Hi, on s390 we are observing more and more problems with -fmodulo-sched. I initially tried debugging an -fcompare-debug failure with -fmodulo-sched but we already ICE when just dumping via `-fdump-rtl-sms`. The problem occurs when compiling the test case gcc.dg/sms-compare-debug-1.c with gcc -O2 -fmodulo-sched sms-compare-debug-1.c -fdump-rtl-sms: sms-compare-debug-1.c:36:1: internal compiler error: in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1064 36 | } | ^ 0x2694499 linemap_ordinary_map_lookup ../../libcpp/line-map.cc:1064 0x2694ef7 linemap_macro_loc_to_exp_point ../../libcpp/line-map.cc:1561 0x266a5c5 expand_location_1 ../../gcc/input.cc:243 0x266c54d expand_location(unsigned int) ../../gcc/input.cc:956 0x1513ecb insn_location(rtx_insn const*) ../../gcc/emit-rtl.cc:6558 0x24cb523 dump_insn_location ../../gcc/modulo-sched.cc:1250 0x24cb523 dump_insn_location ../../gcc/modulo-sched.cc:1246 0x24cf5d7 sms_schedule ../../gcc/modulo-sched.cc:1418 0x24d267f execute ../../gcc/modulo-sched.cc:3358 I didn't manage to simplify the test case further. It works fine on x86. The ICE does not seem to occur with GCC 11, therefore I can bisect the issue if it's of any help. Given the several other problems we're having with modulo scheduling I figured it's better to ask for general guidance here first. Regards Robin
[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700 Artem S. Tashkinov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #11 from Artem S. Tashkinov --- This is an issue with Wine. Closing as invalid.
[Bug c++/67906] Missing warning about std::move without effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #11 from Marek Polacek ---
I'm going to add a testcase that ensures that we don't warn for
struct X {
X() { }
X(const X&) { }
X(const X&&) { }
};
const X x;
const X y = std::move(x);
but otherwise I don't see any useful extension to our std::move warnings.
[Bug middle-end/106519] [13 Regression] internal compiler error: in gimple_phi_arg, at gimple.h:4594 by r13-1950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106519 Andreas Schwab changed: What|Removed |Added Keywords||build, ice-on-valid-code --- Comment #5 from Andreas Schwab --- This also breaks the build for m68k: during GIMPLE pass: phiopt xfgnulib.c: In function '__truncxfdf2': xfgnulib.c:451:1: internal compiler error: in gimple_phi_arg, at gimple.h:4594 451 | __truncxfdf2 (long double ld) | ^~~~ make[2]: *** [../../../libgcc/shared-object.mk:14: xfgnulib.o] Error 1
[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
John David Anglin changed:
What|Removed |Added
Component|target |tree-optimization
--- Comment #8 from John David Anglin ---
This bug was introduced in the following commit:
dave@atlas:~/gnu/gcc/gcc$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[2b8453c401b699ed93c085d0413ab4b5030bcdb8] Enable auto-vectorization at O2 with
very-cheap cost model.
dave@atlas:~/gnu/gcc/gcc$ git log
commit 2b8453c401b699ed93c085d0413ab4b5030bcdb8 (HEAD)
Author: liuhongt
Date: Mon Sep 6 13:48:49 2021 +0800
Enable auto-vectorization at O2 with very-cheap cost model.
gcc/ChangeLog:
* common.opt (ftree-vectorize): Add Var(flag_tree_vectorize).
* doc/invoke.texi (Options That Control Optimization): Update
documents.
* opts.c (default_options_table): Enable auto-vectorization at
O2 with very-cheap cost model.
(finish_options): Use cheap cost model for
explicit -ftree{,-loop}-vectorize.
gcc/testsuite/ChangeLog:
* c-c++-common/Wstringop-overflow-2.c: Adjust testcase.
* g++.dg/tree-ssa/pr81408.C: Ditto.
* g++.dg/warn/Wuninitialized-13.C: Ditto.
* gcc.dg/Warray-bounds-51.c: Ditto.
* gcc.dg/Warray-parameter-3.c: Ditto.
dave@atlas:~/gnu/gcc/gcc$ git bisect bad
2b8453c401b699ed93c085d0413ab4b5030bcdb8 is the first bad commit
commit 2b8453c401b699ed93c085d0413ab4b5030bcdb8
Author: liuhongt
Date: Mon Sep 6 13:48:49 2021 +0800
Enable auto-vectorization at O2 with very-cheap cost model.
gcc/ChangeLog:
* common.opt (ftree-vectorize): Add Var(flag_tree_vectorize).
* doc/invoke.texi (Options That Control Optimization): Update
documents.
* opts.c (default_options_table): Enable auto-vectorization at
O2 with very-cheap cost model.
(finish_options): Use cheap cost model for
explicit -ftree{,-loop}-vectorize.
gcc/testsuite/ChangeLog:
* c-c++-common/Wstringop-overflow-2.c: Adjust testcase.
* g++.dg/tree-ssa/pr81408.C: Ditto.
* g++.dg/warn/Wuninitialized-13.C: Ditto.
* gcc.dg/Warray-bounds-51.c: Ditto.
* gcc.dg/Warray-parameter-3.c: Ditto.
* gcc.dg/Wstringop-overflow-14.c: Ditto.
* gcc.dg/Wstringop-overflow-21.c: Ditto.
* gcc.dg/Wstringop-overflow-68.c: Ditto.
* gcc.dg/Wstringop-overflow-76.c: Ditto.
* gcc.dg/gomp/pr46032-2.c: Ditto.
* gcc.dg/gomp/pr46032-3.c: Ditto.
* gcc.dg/gomp/simd-2.c: Ditto.
* gcc.dg/gomp/simd-3.c: Ditto.
* gcc.dg/graphite/fuse-1.c: Ditto.
* gcc.dg/pr67089-6.c: Ditto.
* gcc.dg/pr82929-2.c: Ditto.
* gcc.dg/pr82929.c: Ditto.
* gcc.dg/store_merging_1.c: Ditto.
* gcc.dg/store_merging_11.c: Ditto.
* gcc.dg/store_merging_13.c: Ditto.
* gcc.dg/store_merging_15.c: Ditto.
* gcc.dg/store_merging_16.c: Ditto.
* gcc.dg/store_merging_19.c: Ditto.
* gcc.dg/store_merging_24.c: Ditto.
* gcc.dg/store_merging_25.c: Ditto.
* gcc.dg/store_merging_28.c: Ditto.
* gcc.dg/store_merging_30.c: Ditto.
* gcc.dg/store_merging_5.c: Ditto.
* gcc.dg/store_merging_7.c: Ditto.
* gcc.dg/store_merging_8.c: Ditto.
* gcc.dg/strlenopt-85.c: Ditto.
* gcc.dg/tree-ssa/dump-6.c: Ditto.
* gcc.dg/tree-ssa/pr19210-1.c: Ditto.
* gcc.dg/tree-ssa/pr47059.c: Ditto.
* gcc.dg/tree-ssa/pr86017.c: Ditto.
* gcc.dg/tree-ssa/pr91482.c: Ditto.
* gcc.dg/tree-ssa/predcom-1.c: Ditto.
* gcc.dg/tree-ssa/predcom-dse-3.c: Ditto.
* gcc.dg/tree-ssa/prefetch-3.c: Ditto.
* gcc.dg/tree-ssa/prefetch-6.c: Ditto.
* gcc.dg/tree-ssa/prefetch-8.c: Ditto.
* gcc.dg/tree-ssa/prefetch-9.c: Ditto.
* gcc.dg/tree-ssa/ssa-dse-18.c: Ditto.
* gcc.dg/tree-ssa/ssa-dse-19.c: Ditto.
* gcc.dg/uninit-40.c: Ditto.
* gcc.dg/unroll-7.c: Ditto.
* gcc.misc-tests/help.exp: Ditto.
* gcc.target/i386/avx512vpopcntdqvl-vpopcntd-1.c: Ditto.
* gcc.target/i386/pr34012.c: Ditto.
* gcc.target/i386/pr49781-1.c: Ditto.
* gcc.target/i386/pr95798-1.c: Ditto.
* gcc.target/i386/pr95798-2.c: Ditto.
* gfortran.dg/pr77498.f: Ditto.
gcc/common.opt | 2 +-
gcc/doc/invoke.texi | 8
gcc/opts.c | 16
[Bug tree-optimization/106243] Failure to optimize (0 - x) & 1 on gimple level (including vector types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106243 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Sam Feifer : https://gcc.gnu.org/g:39579ba8de9d91eafcc4943259b154a9e66538f1 commit r13-1962-g39579ba8de9d91eafcc4943259b154a9e66538f1 Author: Sam Feifer Date: Wed Aug 3 10:31:03 2022 -0400 match.pd: Add bitwise and pattern [PR106243] This patch adds a new optimization to match.pd. The pattern, -x & 1, now gets simplified to x & 1, reducing the number of instructions produced. This patch also adds tests for the optimization rule. Bootstrapped/regtested on x86_64-pc-linux-gnu. PR tree-optimization/106243 gcc/ChangeLog: * match.pd (-x & 1): New simplification. gcc/testsuite/ChangeLog: * gcc.dg/pr106243-1.c: New test. * gcc.dg/pr106243.c: New test.
[Bug libstdc++/103187] std::counting_semaphore::try_acquire_for does not unblock during wait duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103187 Jonathan Wakely changed: What|Removed |Added Target Milestone|11.4|11.3 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > The relevant commit seems to be g:aeaea265cea3a2b2e772af7825351a4ceef29aac > but that *should* only be an optimization to use futexes when available. Ah no, because the HAVE_PLATFORM_WAIT macro was being set, but too late to affect the value of the __platform_wait_uses_type variable template, it meant that _S_wait_addr always returned &_M_w._M_ver and did a futex wait on that, but the semaphore release() was doing a futex wake on &_M_counter instead. > The > fact it times out without that change suggests the non-futex code has a bug, > and it's probably still there on trunk. I think it's fixed by the above commit, which is in GCC 11.3 and later.
[Bug c/106526] array-bounds warning on constant pointer dereferencing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106526 --- Comment #1 from Lars Wrenger --- Same on C++: https://godbolt.org/z/7do3zhavf
[Bug c/106526] New: array-bounds warning on constant pointer dereferencing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106526
Bug ID: 106526
Summary: array-bounds warning on constant pointer dereferencing
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: wrenger at sra dot uni-hannover.de
Target Milestone: ---
On optimization levels 2 and 3 the GCC frontend emits false array-bounds
warnings when dereferencing constant pointers.
# Example
CFLAGS: -O2 -Wall -Werror
```
int main(void) {
int ebda = *((int*)(0x40e));
return ebda;
}
```
The following error only occurs on GCC 12.1 and newer.
```
: In function 'main':
:2:16: error: array subscript 0 is outside array bounds of 'int[0]'
[-Werror=array-bounds]
2 | int ebda = *((int*)(0x40e));
|^~~~
cc1: all warnings being treated as errors
```
> See: https://godbolt.org/z/Kff744P58
[Bug target/106525] New: s390: Inefficient branchless conditionals for unsigned long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106525 Bug ID: 106525 Summary: s390: Inefficient branchless conditionals for unsigned long long Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jens.seifert at de dot ibm.com Target Milestone: --- Created attachment 53409 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53409=edit source code 1) -(a > b) clgr%r2,%r3 lhi %r2,0 alcr%r2,%r2 sllg%r2,%r2,63 srag%r2,%r2,63 Last 2 could be merged to LCDFR. But optimal is: slgrk %r2,%r3,%r2 slbgr %r2,%r2 lgfr %r2,%r2 Note: lgfr is not required => 2 instructions only. 2) -(a <= b) slgr%r3,%r2 lhi %r2,0 alcr%r2,%r2 sllg%r2,%r2,63 srag%r2,%r2,63 Last 2 could be merged to LCDFR. But optimal is: clgr %r2,%r3 slbgr %r2,%r2 lgfr%r2,%r2 Note: lgfr is not required => 2 instructions only. 3) unsigned 64-bit compare for qsort (a > b) - (a < b) clgr%r2,%r3 lhi %r1,0 alcr%r1,%r1 clgr%r3,%r2 lhi %r2,0 alcr%r2,%r2 srk %r2,%r1,%r2 lgfr%r2,%r2 Optimal: slgrk %r1,%r2,%r3 slgrk 0,%r3,%r2 slbgr %r2,%r3 slbgr %r1,%r2 lgfr %r2,%r1 Note: lgfr not required => 4 instructions only
[Bug lto/106328] Build doesn't respect -j N flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- I've got a patch candidate..
[Bug tree-optimization/106521] [13 Regression] ICE at -O1 with "-floop-unroll-and-jam --param unroll-jam-min-percent=0": verify_ssa failed since r13-1450-gd2a898666609452e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106521 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:d8552eaddc40b72461158e56b5db8709f2eb21ed commit r13-1961-gd8552eaddc40b72461158e56b5db8709f2eb21ed Author: Richard Biener Date: Thu Aug 4 11:55:15 2022 +0200 tree-optimization/106521 - unroll-and-jam LC SSA rewrite The LC SSA rewrite performs SSA verification at start but the VN run performed on the unrolled-and-jammed body can leave us with invalid SSA form until CFG cleanup is run. So make sure we do that before rewriting into LC SSA. PR tree-optimization/106521 * gimple-loop-jam.cc (tree_loop_unroll_and_jam): Perform CFG cleanup manually before rewriting into LC SSA. * gcc.dg/torture/pr106521.c: New testcase.
[Bug tree-optimization/106521] [13 Regression] ICE at -O1 with "-floop-unroll-and-jam --param unroll-jam-min-percent=0": verify_ssa failed since r13-1450-gd2a898666609452e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106521 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug libstdc++/106183] std::atomic::wait might fail to be unblocked by notify_one/all on platforms without platform_wait()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183 Jonathan Wakely changed: What|Removed |Added Assignee|rodgertq at gcc dot gnu.org|redi at gcc dot gnu.org --- Comment #6 from Jonathan Wakely --- Should be fixed on trunk now.
[Bug libstdc++/106183] std::atomic::wait might fail to be unblocked by notify_one/all on platforms without platform_wait()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:af98cb88eb4be6a1668ddf966e975149bf8610b1 commit r13-1957-gaf98cb88eb4be6a1668ddf966e975149bf8610b1 Author: Jonathan Wakely Date: Thu Jul 28 16:15:58 2022 +0100 libstdc++: Unblock atomic wait on non-futex platforms [PR106183] When using a mutex and condition variable, the notifying thread needs to increment _M_ver while holding the mutex lock, and the waiting thread needs to re-check after locking the mutex. This avoids a missed notification as described in the PR. By moving the increment of _M_ver to the base _M_notify we can make the use of the mutex local to the use of the condition variable, and simplify the code a little. We can use a relaxed store because the mutex already provides sequential consistency. Also we don't need to check whether __addr == &_M_ver because we know that's always true for platforms that use a condition variable, and so we also know that we always need to use notify_all() not notify_one(). Reviewed-by: Thomas Rodgers libstdc++-v3/ChangeLog: PR libstdc++/106183 * include/bits/atomic_wait.h (__waiter_pool_base::_M_notify): Move increment of _M_ver here. [!_GLIBCXX_HAVE_PLATFORM_WAIT]: Lock mutex around increment. Use relaxed memory order and always notify all waiters. (__waiter_base::_M_do_wait) [!_GLIBCXX_HAVE_PLATFORM_WAIT]: Check value again after locking mutex. (__waiter_base::_M_notify): Remove increment of _M_ver.
[Bug libstdc++/65230] pretty-print inconsistent output for similar objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #5 from Ulrich Drepper ---
Or should the std::pair output even be
p1 = std::pair = {[0] = 0, [1] = 0}
??
[Bug libstdc++/65230] pretty-print inconsistent output for similar objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #4 from Ulrich Drepper ---
Ugh, this one is a pasto:
v1 = std::vector of length 0, capacity 0 = { }
instead of
v1 = std::vector of length 0, capacity 0
[Bug libstdc++/65230] pretty-print inconsistent output for similar objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
--- Comment #3 from Ulrich Drepper ---
Actually, I think for the std::pair definition I'd like to see
p1 = {[0] = 0, [1] = 0}
instead of
p1 = {first = 0, second = 0}
Again, more uniform and I'd say it should be encouraged to use std::get instead
of .first / .second because it's compatible with std::tuple.
[Bug libstdc++/65230] pretty-print inconsistent output for similar objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230
Ulrich Drepper changed:
What|Removed |Added
CC||drepper.fsp+rhbz at gmail dot
com
--- Comment #2 from Ulrich Drepper ---
Let's go through the details. I like the idea of a common format but there
also
shouldn't be any information lost.
Here's some test code, similar to what Martin has:
#include
#include
#include
#include
#include
int main()
{
std::tuple<> t1;
std::tuple t2;
std::tuple t3;
std::vector v1;
std::vector v2 { 0 };
std::vector v3 { 0, 0 };
std::array a1;
std::array a2 { 0 };
std::array a3 { 0, 0 };
std::pair p1;
std::bitset<0> b1;
std::bitset<1> b2("0");
std::bitset<2> b3("00");
return 0;
}
The output as of gcc-12.1.1 (and gdb-12.1, what a coincidence) is:
(gdb) info locals
t1 = empty std::tuple
t2 = std::tuple containing = {[0] = 0}
t3 = std::tuple containing = {[0] = 0, [1] = 0}
v1 = std::vector of length 0, capacity 0
v2 = std::vector of length 1, capacity 1 = {0}
v3 = std::vector of length 2, capacity 2 = {0, 0}
a1 = {_M_elems = {}}
a2 = {_M_elems = {0}}
a3 = {_M_elems = {0, 0}}
p1 = {first = 0, second = 0}
b1 = std::bitset
b2 = std::bitset
b3 = std::bitset
This is just my opinion, but I would like to see the following output (NB, this
already uses the tuple pretty printer change I committed):
(gdb) info locals
t1 = std::tuple<> = { }
t2 = std::tuple = {[0] = 0}
t3 = std::tuple = {[0] = 0, [1] = 0}
v1 = std::vector of length 0, capacity 0
v2 = std::vector of length 1, capacity 1 = {0}
v3 = std::vector of length 2, capacity 2 = {0, 0}
a1 = std::array = { }
a2 = std::array = {0}
a3 = std::array = {0, 0}
p1 = {first = 0, second = 0}
b1 = std::bitset<0> = { }
b2 = std::bitset<1> = {0}
b3 = std::bitset<2> = {0, 0}
This means several changes but it corrects the rather ad-hoc nature of the
current output to be more uniform.
[Bug tree-optimization/106523] [10/11/12/13 Regression] forwprop miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106523 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-08-04 Target Milestone|--- |10.5 Summary|forwprop miscompile |[10/11/12/13 Regression] ||forwprop miscompile Known to fail||10.1.0, 12.1.0 Keywords||wrong-code Ever confirmed|0 |1 Priority|P3 |P2 Status|UNCONFIRMED |NEW Known to work||4.8.5 --- Comment #1 from Richard Biener --- Confirmed.
[Bug target/106524] [12/13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106524 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.2
[Bug target/106524] New: [12/13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106524
Bug ID: 106524
Summary: [12/13 Regression] ICE in extract_insn, at
recog.cc:2791 (error: unrecognizable insn)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
gcc 13.0.0 20220731 snapshot (g:525a1a73a5a563c829a5f76858fe122c9b39f254) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/aarch64/sve/vcond_4_zero.c, w/ -march=armv8-a+sve -O2
-fno-move-loop-invariants:
void
test__zero (int *restrict dest, int *restrict src, float *a, int count)
{
int i;
for (i = 0; i < count; ++i)
dest[i] = !__builtin_isunordered (a[i], 0) ? src[i] : 0;
}
% aarch64-linux-gnu-gcc-13.0.0 -march=armv8-a+sve -O2 -fno-move-loop-invariants
-c ezv9mlin.c
ezv9mlin.c: In function 'test__zero':
ezv9mlin.c:8:1: error: unrecognizable insn:
8 | }
| ^
(insn 58 23 59 4 (set (reg:VNx4BI 122)
(unspec:VNx4BI [
(reg:VNx4BI 97 [ loop_mask_46 ])
(const_int 0 [0])
(reg:VNx4SF 98 [ vect__4.10 ])
(const_vector:VNx4SF repeat [
(const_double:SF 0.0 [0x0.0p+0])
])
] UNSPEC_COND_FCMUO)) -1
(expr_list:REG_DEAD (reg:VNx4SF 98 [ vect__4.10 ])
(nil)))
during RTL pass: sched1
ezv9mlin.c:8:1: internal compiler error: in extract_insn, at recog.cc:2791
0x75b3e6 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220731/work/gcc-13-20220731/gcc/rtl-error.cc:108
0x75b404 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220731/work/gcc-13-20220731/gcc/rtl-error.cc:116
0x759d4d extract_insn(rtx_insn*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220731/work/gcc-13-20220731/gcc/recog.cc:2791
0xd2ddcf scan_one_insn
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220731/work/gcc-13-20220731/gcc/ira-costs.cc:1464
0xd2ddcf process_bb_for_costs
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220731/work/gcc-13-20220731/gcc/ira-costs.cc:1632
0xd2f4b7 find_costs_and_classes
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220731/work/gcc-13-20220731/gcc/ira-costs.cc:1739
0xd2fafa ira_set_pseudo_classes(bool, _IO_FILE*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220731/work/gcc-13-20220731/gcc/ira-costs.cc:2293
0x1b66137 alloc_global_sched_pressure_data
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220731/work/gcc-13-20220731/gcc/haifa-sched.cc:7201
0x1b66137 sched_init()
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220731/work/gcc-13-20220731/gcc/haifa-sched.cc:7356
0x1b678ca haifa_sched_init()
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220731/work/gcc-13-20220731/gcc/haifa-sched.cc:7368
0xec7bba schedule_insns()
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220731/work/gcc-13-20220731/gcc/sched-rgn.cc:3510
0xec832c schedule_insns()
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220731/work/gcc-13-20220731/gcc/sched-rgn.cc:3504
0xec832c rest_of_handle_sched
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220731/work/gcc-13-20220731/gcc/sched-rgn.cc:3722
0xec832c execute
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220731/work/gcc-13-20220731/gcc/sched-rgn.cc:3832
[Bug tree-optimization/106523] New: forwprop miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106523
Bug ID: 106523
Summary: forwprop miscompile
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kristerw at gcc dot gnu.org
Target Milestone: ---
The function f7 from testsuite/c-c++-common/rotate-2.c is miscompiled by
forwprop. This can be seen by running the function as
__attribute__((noinline)) unsigned char
f7 (unsigned char x, unsigned int y)
{
unsigned int t = x;
return (t << y) | (t >> ((-y) & 7));
}
int
main (void)
{
volatile unsigned char x = 152;
volatile unsigned int y = 19;
if (f7(x, y) != 4)
__builtin_abort ();
return 0;
}
This fails at -O1 and higher optimization levels.
What is happening here is that forwprop1 has optimized the function
to
_10 = x_7(D) r<< y_9(D);
return _10;
[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069 --- Comment #32 from Xionghu Luo (luoxhu at gcc dot gnu.org) --- Thanks for all the information! It inspires to me that "native RTL should be endian-independent". So both big-endian and little-endian platform should generate same (vec_select (vec_concat (R0 R1) [0 4 1 5])) for altivec_vmrghw, then combine pass could do correct "nested vec_select" optimization, the endian check are left to ASM generation at last, that's the benefit for removing the UNSPECS. My culprit patch did change the LE representation, sorry for the stupid mistake... Attached the fix patch. If it is reasonable, I will continue refine it and send to maillist.
[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069 --- Comment #31 from Xionghu Luo (luoxhu at gcc dot gnu.org) --- Created attachment 53408 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53408=edit 0001-rs6000-Fix-incorrect-RTL-for-Power-LE-when-removing-
[Bug rtl-optimization/106518] Exchange/swap aware register allocation (generate xchg in reload)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106518 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka --- We have xchg patterns in i386.md and corresponding peephole. I used to play with this long time ago and it was not giving any of performance benefits becuase xchg at that time was not well optimized in CPUs. With regstack the main problem is that RTL after reg-stack is inconsistent since we have no way to explicitly express push/pop operations that renumber the registers. Some years ago I made patch for that https://gcc.gnu.org/pipermail/gcc-patches/1999-November/021921.html Even if you make representation correct register allocation for stack based CPU is quite different from normal registr allocation. These days I would more like to see x87 to silently die.
[Bug tree-optimization/106521] [13 Regression] ICE at -O1 with "-floop-unroll-and-jam --param unroll-jam-min-percent=0": verify_ssa failed since r13-1450-gd2a898666609452e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106521 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug middle-end/106519] [13 Regression] internal compiler error: in gimple_phi_arg, at gimple.h:4594 by r13-1950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106519 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |13.0
[Bug rtl-optimization/106518] Exchange/swap aware register allocation (generate xchg in reload)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106518 Richard Biener changed: What|Removed |Added Keywords||missed-optimization, ra --- Comment #1 from Richard Biener --- one could try to recog (parallel (set (reg A) (reg B)) (set (reg B) (reg A))) ? But yes, having a standard name for this would be nice.
[Bug testsuite/106515] [13 regression] gcc.dg/debug/btf/btf-int-1.c fails after r13-1937-g5df04a7aa837a1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106515 Richard Biener changed: What|Removed |Added Keywords||testsuite-fail Target Milestone|--- |13.0
[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069 --- Comment #30 from Richard Earnshaw --- (In reply to rsand...@gcc.gnu.org from comment #29) > (In reply to Segher Boessenkool from comment #28) > > (In reply to rsand...@gcc.gnu.org from comment #25) > > > - On big-endian targets, vector loads and stores are assumed to put the > > > first memory element at the most significant end of the vector register. > > > > I agree with everything here, except calling this "most significant". That > > just makes no sense for vectors. It is element 0, but that is not more > > significant than any other element :-) Vectors aren't integers. > Ah, yeah, I should have said “most significant end of the vector register > if the vector register is viewed as a single integer” (which is an important > difference). The point here was that: > > (a) by default, TI subregs of V4SI registers are assumed to be nops > (and vice versa) > > (b) consequently, TImode loads are assumed to perform the same operation > as V4SI loads > > So endianness assumptions for single integers carry over to like-sized > vector modes. On big-endian, the first element of the V4SI is assumed > to line up with the top 32 bits of a 128-bit integer. > > Although it's possible to force subregs not to be nops (via > targetm.can_change_mode_class), that only really affects changes > to specific hard register classes. The generic rules still apply > to the layout of pseudos. It's not just about when the vector is viewed as an integer. There's also the case when a vector of NxM is viewed as N/2xM*2 or vice versa, or even for other powers of two. We've tended to call the lane ordering 'little-endian' if the lower numbered lane is in the least significant bits of a wider element size, and 'big-endian' if it's in the most significant bits.
[Bug tree-optimization/106511] [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511 Richard Biener changed: What|Removed |Added Blocks||24639 Target Milestone|--- |13.0 Keywords||diagnostic Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069 --- Comment #29 from rsandifo at gcc dot gnu.org --- (In reply to Segher Boessenkool from comment #28) > (In reply to rsand...@gcc.gnu.org from comment #25) > > - On big-endian targets, vector loads and stores are assumed to put the > > first memory element at the most significant end of the vector register. > > I agree with everything here, except calling this "most significant". That > just makes no sense for vectors. It is element 0, but that is not more > significant than any other element :-) Vectors aren't integers. Ah, yeah, I should have said “most significant end of the vector register if the vector register is viewed as a single integer” (which is an important difference). The point here was that: (a) by default, TI subregs of V4SI registers are assumed to be nops (and vice versa) (b) consequently, TImode loads are assumed to perform the same operation as V4SI loads So endianness assumptions for single integers carry over to like-sized vector modes. On big-endian, the first element of the V4SI is assumed to line up with the top 32 bits of a 128-bit integer. Although it's possible to force subregs not to be nops (via targetm.can_change_mode_class), that only really affects changes to specific hard register classes. The generic rules still apply to the layout of pseudos.
[Bug tree-optimization/106506] [13 Regression] g++.dg/opt/pr94589-2.C FAILS after enabling floats in VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106506 Richard Biener changed: What|Removed |Added Keywords||missed-optimization, xfail Summary|g++.dg/opt/pr94589-2.C |[13 Regression] |FAILS after enabling floats |g++.dg/opt/pr94589-2.C |in VRP |FAILS after enabling floats ||in VRP Version|12.0|13.0 Target Milestone|--- |13.0
[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888 --- Comment #4 from Kewen Lin --- (In reply to Segher Boessenkool from comment #3) > Your second option isn't correct: all these nops should be consecutive. Your > option 1 is fine :-) Good point! It's lucky that I chose option 1. :)
[Bug middle-end/106519] [13 Regression] internal compiler error: in gimple_phi_arg, at gimple.h:4594 by r13-1950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106519 --- Comment #4 from Martin Liška --- *** Bug 106522 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/106522] [13 Regression] ICE in gimple_phi_arg, at gimple.h:4594 since r13-1950-g9bb19e143cfe8863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106522 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 106519 ***
[Bug middle-end/106519] [13 Regression] internal compiler error: in gimple_phi_arg, at gimple.h:4594 by r13-1950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106519 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- > On x86-64, r13-1950 caused Please update to the last version of git gcc-descr git alias.
[Bug tree-optimization/106522] [13 Regression] ICE in gimple_phi_arg, at gimple.h:4594 since r13-1950-g9bb19e143cfe8863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106522 Martin Liška changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/106522] [13 Regression] ICE in gimple_phi_arg, at gimple.h:4594 since r13-1950-g9bb19e143cfe8863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106522 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-08-04
[Bug tree-optimization/106522] New: [13 Regression] ICE in gimple_phi_arg, at gimple.h:4594 since r13-1950-g9bb19e143cfe8863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106522
Bug ID: 106522
Summary: [13 Regression] ICE in gimple_phi_arg, at
gimple.h:4594 since r13-1950-g9bb19e143cfe8863
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: tamar.christina at arm dot com
Target Milestone: ---
The following crashes:
$ cat ice.c
int bytestart, bytemem_0_0, modlookup_l_p;
void
modlookup_l() {
long j;
while (modlookup_l_p)
while (bytestart && j && bytemem_0_0)
j = j + 1;
}
$ gcc ice.c -O1 -fno-tree-forwprop -c
during GIMPLE pass: phiopt
ice.c: In function ‘modlookup_l’:
ice.c:4:1: internal compiler error: in gimple_phi_arg, at gimple.h:4594
4 | modlookup_l() {
| ^~~
0x7d2a04 gimple_phi_arg
/home/marxin/Programming/gcc/gcc/gimple.h:4594
0x7d2a04 gimple_phi_arg_def
/home/marxin/Programming/gcc/gcc/gimple.h:4639
0x7d3d1f gimple_phi_arg_def
/home/marxin/Programming/gcc/gcc/tree-ssa-phiopt.cc:337
0x7d3d1f tree_ssa_phiopt_worker
/home/marxin/Programming/gcc/gcc/tree-ssa-phiopt.cc:314
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/106521] [13 Regression] ICE at -O1 with "-floop-unroll-and-jam --param unroll-jam-min-percent=0": verify_ssa failed since r13-1450-gd2a898666609452e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106521 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-08-04 Version|unknown |13.0 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Summary|ICE at -O1 with |[13 Regression] ICE at -O1 |"-floop-unroll-and-jam |with "-floop-unroll-and-jam |--param |--param |unroll-jam-min-percent=0": |unroll-jam-min-percent=0": |verify_ssa failed |verify_ssa failed since ||r13-1450-gd2a89809452e Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |13.0 --- Comment #1 from Martin Liška --- Started with r13-1450-gd2a89809452e.
[Bug middle-end/106492] [OpenMP] ICE in #pragma omp for simd and bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106492 Tobias Burnus changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Tobias Burnus --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599308.html
[Bug c++/106502] Three calls to __attribute__((const)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106502 --- Comment #7 from Jonathan Wakely --- The way I found the bug might be, but the bug itself is nothing to do with that.
[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106516
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
CC||linkw at gcc dot gnu.org
Last reconfirmed||2022-08-04
Status|UNCONFIRMED |NEW
--- Comment #2 from Kewen Lin ---
Confirmed, this is a test issue, power10 and up specific.
The difference comes from the function thud, it aims to test the pattern works
for vector type. Power10 starts to support the insn vmodsw for vector integer
mod.
So it gets:
vector(4) int thud (vector(4) int x, vector(4) int y)
_1 = x_3(D) % y_4(D);
_2 = _1 == { 0, 0, 0, 0 };
instead of
[local count: 1073741824]:
_7 = BIT_FIELD_REF ;
_8 = BIT_FIELD_REF ;
_9 = _7 % _8;
_10 = BIT_FIELD_REF ;
_11 = BIT_FIELD_REF ;
_12 = _10 % _11;
_13 = BIT_FIELD_REF ;
_14 = BIT_FIELD_REF ;
_15 = _13 % _14;
_16 = BIT_FIELD_REF ;
_17 = BIT_FIELD_REF ;
_18 = _16 % _17;
_1 = {_9, _12, _15, _18};
_2 = _1 == { 0, 0, 0, 0 };
We can adjust the test case to expect 6 times "%" on target power10_ok
specially, but I wonder if we also find this fail on some other targets which
supports vector mod, if so, one overall complete guard would be better.
