[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719 --- Comment #14 from Jonathan Wakely --- I have a patch to remove indirections in std::array which I'll commit for GCC 13.
[Bug c++/105067] New: ICE: in operator[], at vec.h:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105067
Bug ID: 105067
Summary: ICE: in operator[], at vec.h:889
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
12 Regression
template
template
concept C = requires { typename T::type; };
template class S {};
S s;
https://godbolt.org/z/YjazY4ajv
[Bug target/105068] New: ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints: ssse3_pshufbv16qi3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105068
Bug ID: 105068
Summary: ICE: in extract_constrain_insn, at recog.cc:2692 (insn
does not satisfy its constraints: ssse3_pshufbv16qi3)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 52690
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52690&action=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -Og -fsanitize=thread -fstack-protector-all
-mavx512vl testcase.c
testcase.c: In function 'foo0':
testcase.c:44:1: error: insn does not satisfy its constraints:
44 | }
| ^
(insn 244 243 140 2 (set (reg:V16QI 44 xmm8 [142])
(unspec:V16QI [
(reg:V16QI 20 xmm0 [orig:82 c.0_1 ] [82])
(reg:V16QI 52 xmm16 [210])
] UNSPEC_PSHUFB)) "testcase.c":25:11 7140 {ssse3_pshufbv16qi3}
(nil))
during RTL pass: pro_and_epilogue
testcase.c:44:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2692
0x76c594 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x76c61a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:118
0x75b3fc extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2692
0x12ea69b copyprop_hardreg_forward_1
/repo/gcc-trunk/gcc/regcprop.cc:826
0x12eb8d1 copyprop_hardreg_forward_bb_without_debug_insn(basic_block_def*)
/repo/gcc-trunk/gcc/regcprop.cc:1220
0x1355fd7 prepare_shrink_wrap
/repo/gcc-trunk/gcc/shrink-wrap.cc:451
0x1355fd7 try_shrink_wrapping(edge_def**, rtx_insn*)
/repo/gcc-trunk/gcc/shrink-wrap.cc:674
0x101840b thread_prologue_and_epilogue_insns()
/repo/gcc-trunk/gcc/function.cc:6047
0x1018ce2 rest_of_handle_thread_prologue_and_epilogue
/repo/gcc-trunk/gcc/function.cc:6532
0x1018ce2 execute
/repo/gcc-trunk/gcc/function.cc:6608
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7835-20220327001633-gd2906412ada-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-7835-20220327001633-gd2906412ada-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220327 (experimental) (GCC)
[Bug c++/105064] requires crashes gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064 --- Comment #2 from Janez Zemva --- Yeah, I tried to make a minimal crash example for you, but it compiled perfectly. Anyway, you know about the crash, you know about my repository and I am no hurry for a fix, as this is my pet-project. And this is a special bug, gcc SEGFAULTs are of special interest to you, I imagine.
[Bug c++/105064] requires crashes gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064 --- Comment #3 from Jonathan Wakely --- Read it again, because you've misunderstood. It doesn't say we need a minimal example, that's not essential. But it clearly says to provide the code HERE, not via URL. And to include the output of gcc -v.
[Bug c++/105064] requires crashes gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064 --- Comment #4 from Jonathan Wakely --- And segfaults are not special, it's a bug like many others.
[Bug c++/103291] [11/12 Regression] #pragma gcc visibility is lost for external decls declared inside a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103291 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug pch/91440] Precompiled headers don't work with ASLR on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91440 R Copley changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from R Copley --- Fixed with PR71934. Precompiled headers are now relocatable. Thanks! https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71934
[Bug c/105069] New: [12 regression] sh-elf internal compiler errors and test failures with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069
Bug ID: 105069
Summary: [12 regression] sh-elf internal compiler errors and
test failures with -Os
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jscott at posteo dot net
Target Milestone: ---
Hi,
This seems to be a regression as compared to GCC 11. When building a bare-metal
compiler for sh-elf (Newlib or an ISO C standard library is not required), GCC
aborts with an internal compiler error:
gcc.c-torture/compile/pr104327.c:13:1: internal compiler error:
‘global_options’ are modified in local context
13 | {
| ^
There are numerous test suite failures that this causes:
gcc.c-torture/compile/pr104327.c (no special flags needed, since -Os is set via
an attribute)
and for the following, building with -Os is necessary:
gcc.c-torture/compile/pr58332.c
gcc.c-torture/compile/pr81360.c
gcc.c-torture/compile/pr84425.c
Here is a one-line reproducer:
cat bar.c
[[gnu::optimize("Os")]] int main(void) {}
$ sh-elf-gcc bar.c
bar.c:1:1: internal compiler error: ‘global_options’ are modified in local
context
1 | [[gnu::optimize("Os")]] int main(void) {}
| ^
0x7f231098a7fc __libc_start_main
../csu/libc-start.c:332
This occurs using the latest Git master on an x86_64 Debian Bullseye GNU/Linux
system. I'm not sure that this issue lies in the C frontend, so please reassign
wherever appropriate.
I discovered this issue running the test suite to upgrade the Debian gcc-sh-elf
package.
[Bug target/105069] [12 regression] sh-elf internal compiler errors and test failures with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Component|c |target Target Milestone|--- |12.0
[Bug target/105069] [12 regression] sh-elf internal compiler errors and test failures with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069
--- Comment #1 from John Scott ---
Here is a backtrace:
bar.c:2:1: internal compiler error: ‘global_options’ are modified in local
context
2 | [[gnu::optimize("Os")]] int main(void) {}
| ^
0xe71b6b cl_optimization_compare(gcc_options*, gcc_options*)
/tmp/build/gcc/options-save.cc:13029
0xa077ac handle_optimize_attribute
/tmp/gcc/gcc/c-family/c-attribs.cc:5567
0x9056f2 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/tmp/gcc/gcc/attribs.cc:867
0x9229bc start_function(c_declspecs*, c_declarator*, tree_node*)
/tmp/gcc/gcc/c/c-decl.cc:9516
0x984a0e c_parser_declaration_or_fndef
/tmp/gcc/gcc/c/c-parser.cc:2445
0x98db33 c_parser_external_declaration
/tmp/gcc/gcc/c/c-parser.cc:1779
0x98e57b c_parser_translation_unit
/tmp/gcc/gcc/c/c-parser.cc:1652
0x98e57b c_parse_file()
/tmp/gcc/gcc/c/c-parser.cc:23357
0x9eef8d c_common_parse_file()
/tmp/gcc/gcc/c-family/c-opts.cc:1240
[Bug debug/105070] New: Missing debug info for switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105070
Bug ID: 105070
Summary: Missing debug info for switch statement
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: liyd2021 at gmail dot com
Target Milestone: ---
Affected versions: gcc 11.1.0, since gcc 9
(terminal) $ gcc-9 -v
Using built-in specs.
COLLECT_GCC=gcc-9
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.4.0-1ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--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-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 --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --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-9-yTrUTS/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04)
Debugging the following program will directly hit "return 1" instead of the
"switch (x)" in this specific case.
Did not observe this problem on other switch-cases.
(terminal) $ cat a.c && gcc -g -OO a.c
extern void abort(void);
int foo(int x) {
switch (x) {
case 1:
case 3:
case 5:
return 1;
default:
return 0;
}
}
int main() {
int i, r;
for (i = 0; i < 6; i++) {
r = foo(i);
if(i == 1 || i == 3 || i == 5){
if(r == 0){
abort();
}
}
}
return 0;
}
(terminal) $ gdb a.out
(gdb) b foo
Breakpoint 1 at 0x4011b3: file a.c, line 8.
(gdb) r
Breakpoint 1, foo (x=1) at a.c:8
8 return 1;
(gdb) c
Continuing.
Breakpoint 1, foo (x=3) at a.c:8
8 return 1;
(gdb) c
Continuing.
Breakpoint 1, foo (x=5) at a.c:8
8 return 1;
This bug seemed to be missing debug_line.
(terminal) $ readelf --debug-dump=decodedline a.out
Contents of the .debug_line section:
CU: a.c:
File LineStarting addressViewStmt
a.c 30x401185 x
a.c 80x4011b3 x <-- line 4 is missing
a.c 100x4011ba x
a.c 120x4011bf x
a.c 140x4011c1 x
[Bug tree-optimization/104987] [12 Regression] Recent change causing vrp13.c regressions on several targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104987 Jeffrey A. Law changed: What|Removed |Added Target|iq2000-elf, v850e-elf |iq2000-elf Priority|P3 |P4 --- Comment #8 from Jeffrey A. Law --- V850 simulator fix has been posted to the binutils list. I've never really hacked the iq2000, but from the looks of things I think it's mis-compiling mulsi3 in libgcc. In particular, I don't think it's handling delay slots properly for the bbi instruction. reorg has tagged it as a nullified-if-false branch, but it appears that we're using the wrong form at assembly time and the instruction in the delay slot always executes. So P4 as this appears to be an iq2000 specific issue.
[Bug c++/102071] [10/11/12 Regression] crash when combining -faligned-new=N with array cookie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102071 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/101886] [11/12 Regression][concepts] ICE with auto as template argument since r11-7011-g6e0a231a4aa2407b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101886 --- Comment #2 from Jason Merrill --- This use of 'auto' was not accepted into C++20, so fixing this bug in the vestigial Concepts TS implementation is a low priority.
[Bug c++/105064] requires crashes gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064
--- Comment #5 from Janez Zemva ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--enable-multilib --enable-plugin --enable-shared --enable-threads=posix
--disable-libssp --disable-libstdcxx-pch --disable-werror
--with-build-config=bootstrap-lto --enable-link-serialization=1
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)
I think the bug has something to do with two classes having the same friend:
class A
{
// friend
};
class B
{
// friend
};
c++ is becoming very complex and these crashes are a warning sign. So, you mean
I'd have to create an archive and place it here as an attachment? What if it
was 1GB in size?
[Bug c++/105064] requires crashes gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064 --- Comment #6 from Janez Zemva --- Also, there are several workarounds around this bug, but I'll keep my repository in a crashing state, until you find time to produce a minimal test case.
[Bug c++/105064] requires crashes gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064 --- Comment #7 from Janez Zemva --- Also, I'd like to add, that you can mount a github repository with FUSE, so providing an URL is almost the same as providing an archive. https://github.com/taterbase/git-mount
[Bug c++/105064] requires crashes gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064 --- Comment #8 from Janez Zemva --- I can reproduce the bug in my rpi4b: $ g++ -std=c++20 -Ofast loopdemo.cpp -o l In file included from loopdemo.cpp:3: loop.hpp:169:55: internal compiler error: Segmentation fault 169 | requires(std::is_same_v); | ^ 0x7f98a33217 __libc_start_main ../csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/10/lto-wrapper Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=aarch64-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-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.1 20210110 (Debian 10.2.1-6)
[Bug target/105068] ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints: ssse3_pshufbv16qi3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105068 --- Comment #1 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:08e69332881f8d28ce8b559ffba1900ae5c0d5ee commit r12-7837-g08e69332881f8d28ce8b559ffba1900ae5c0d5ee Author: H.J. Lu Date: Sun Mar 27 11:07:39 2022 -0700 x86: Use Yw constraint on *ssse3_pshufbv8qi3 Since AVX512VL and AVX512BW are required for AVX512 VPSHUFB, replace the "Yv" register constraint with the "Yw" register constraint. gcc/ PR target/105068 * config/i386/sse.md (*ssse3_pshufbv8qi3): Replace "Yv" with "Yw". gcc/testsuite/ PR target/105068 * gcc.target/i386/pr105068.c: New test.
[Bug c++/105064] requires crashes gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064
--- Comment #9 from Janez Zemva ---
Anyway, I've grown bored, so here's the minimal test case:
#include
class task
{
friend void suspend_to(auto const tp) noexcept
requires(std::is_same_v);
};
class loop
{
friend void suspend_to(auto const tp) noexcept
requires(std::is_same_v);
};
void suspend_to(auto const tp) noexcept
requires(std::is_same_v)
{
}
$ g++ -std=c++20 -Ofast tmp.cpp -o t
tmp.cpp:12:55: internal compiler error: Segmentation fault
12 | requires(std::is_same_v);
| ^
0xe4c988 internal_error(char const*, ...)
???:0
0xf778a4 duplicate_decls(tree_node*, tree_node*, bool, bool)
???:0
0xf82c3b pushdecl_namespace_level(tree_node*, bool)
???:0
0x10ecbfe push_template_decl(tree_node*, bool)
???:0
0x159b601 do_friend(tree_node*, tree_node*, tree_node*, tree_node*,
overload_flags, bool)
???:0
0x1001717 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
???:0
0x105cc75 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
???:0
0x14e7873 c_parse_file()
???:0
0x14c9d9e c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/102419] [11/12 Regression][concepts] return-type-requirement of "Y" does not check that T::type actually exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102419
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Summary|[11/12 |[11/12
|Regression][concepts] |Regression][concepts]
|[regression]|return-type-requirement of
|return-type-requirement of |"Y" does
|"Y" does |not check that T::type
|not check that T::type |actually exists
|actually exists |
--- Comment #6 from Jason Merrill ---
Concept satisfaction was very deliberately designed in committee discussion to
work differently from void_t, based on the normalized form rather than the
concept-id as written. So this example is well-formed:
template concept is_void = same_as(Tz, void);
template concept void_or_same = is_void || same_as;
template void f() requires void_or_same;
int main() { f(); } // OK
It definitely is an inconsistency with non-concept template-ids, but that's the
design.
C++20 national body comment CA104
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2103r0.html#CA104) is
about one situation where we do need to substitute directly into the arguments,
but it is a single exception to the rule.
In the discussion of CA104 I suggested that we might want to reconsider this
design (on 2019-11-08, if you want to look up the reflector message), and make
my example above ill-formed, but we ended up making an exception instead.
The behavior change you are seeing is from properly implementing
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1452r2.html and not a
bug.
[Bug c++/102419] [11/12 Regression][concepts] return-type-requirement of "Y" does not check that T::type actually exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102419 Jason Merrill changed: What|Removed |Added Priority|P2 |P4
[Bug fortran/102043] [9/10/11/12 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #35 from Mikael Morin --- A little status update. I have pushed the latest patch attached to this PR a little further, but not far enough to reduce the number of testsuite regressions to 0. I plan to submit it for gcc-13, but it won’t make it for gcc-12. (In reply to Richard Biener from comment #33) > With > a single dimension there's not much value in using ARRAY_REF over > pointer arithmetic and dereference. I have tried to fix this PR using pointer arithmetic too. But there are so many places in the frontend where we expect to have an array type when dereferencing a descriptor pointer, that it’s not as simple as it seems and I finally convinced myself that the patch attached to this PR was the best way to go. For gcc-12, is there a way to add a middle-end workaround using annotations on descriptor types (a lang flag or something) ?
[Bug fortran/50549] should detect different type parameters in structure constructors (r178939)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50549 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-March/057710.html
[Bug c++/105064] [10/11/12 Regression] requires crashes gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064 Jonathan Wakely changed: What|Removed |Added Known to work||9.4.0 Status|WAITING |NEW Known to fail||10.3.1, 11.2.1, 12.0 CC||jason at gcc dot gnu.org Summary|requires crashes gcc|[10/11/12 Regression] ||requires crashes gcc Keywords||ice-on-valid-code --- Comment #10 from Jonathan Wakely --- Thank you. Confirmed as a regression, starting with r10-6220 c++: Fix ICE with constrained friend (PR93400). Here, the problem was that tsubst_friend_function was modifying the CONSTRAINT_INFO for the friend template to have the constraints for one instantiation, which fell down when we went to adjust it for another instantiation. Fixed by deferring substitution of trailing requirements until we try to check declaration matching. PR c++/93400 - ICE with constrained friend. * constraint.cc (maybe_substitute_reqs_for): New. * decl.c (function_requirements_equivalent_p): Call it. * pt.c (tsubst_friend_function): Only substitute TEMPLATE_PARMS_CONSTRAINTS. (tsubst_template_parms): Copy constraints.
[Bug c++/105071] New: Incorrect code with -Os and complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105071
Bug ID: 105071
Summary: Incorrect code with -Os and complex
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dlong at cadence dot com
Target Milestone: ---
Created attachment 52691
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52691&action=edit
.ii file for test case
64-bit Intel, RedHat Enterprise Linux 7.4
$ cat foo.cc
#include
#include
using namespace std;
void broken(complex x)
{
complex x2=x*x;
complex x3=x2*x;
complex x4=x3*x;
complex x5=x4*x;
complex d=1.0+2.0/x+4.0/x2+8.0/x3+16.0/x4+32.0/x5;
fprintf(stderr, "%e%+ej\n", real(d), imag(d));
}
int main(int argc, char **argv) {
broken(complex(1.0, 0.00e+00));
return 0;
}
$ g++-9 -Wall -o foo foo.cc && ./foo # correct
6.30e+01+0.00e+00j
$ g++-9 -Wall -O2 -o foo foo.cc && ./foo # also correct
6.30e+01+0.00e+00j
$ g++-9 -Wall -Os -o foo foo.cc && ./foo # wrong
1.00e+00+0.00e+00j
If the +32.0/x5 at the end of the computation of d is
omitted, then -Os also gives the correct result.
$ g++-9 -v
Using built-in specs.
COLLECT_GCC=g++-9
COLLECT_LTO_WRAPPER=/grid/common/pkgsData/gcc-v9.3.0p3/Linux/RHEL7.0-2017-x86_64/libexec/gcc/x86_64-redhat-linux/9.3.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: /tmp/gcc-v9.3.0p3/gcc.source/configure
--prefix=/grid/common/pkgsData/gcc-v9.3.0p3/Linux/RHEL7.0-2017-x86_64
--with-pkgversion=Cadence --disable-libgcj --enable-threads=posix
--enable-shared --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--with-linker-hash-style=gnu --enable-languages=c,c++,fortran --disable-nls
--enable-gnu-unique-object --enable-bootstrap --enable-plugin
--enable-initfini-array --enable-linker-build-id --enable-gnu-indirect-function
--enable-install-libiberty
--with-ld=/grid/common/pkgsData/gcc-v9.3.0p3/Linux/RHEL7.0-2017-x86_64/bin/ld
--with-as=/grid/common/pkgsData/gcc-v9.3.0p3/Linux/RHEL7.0-2017-x86_64/bin/as
--build=x86_64-redhat-linux --host=x86_64-redhat-linux --with-tune=generic
--enable-multiarch
Thread model: posix
gcc version 9.3.0 (Cadence)
[Bug middle-end/105071] [9 Regression] Incorrect code with -Os and complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105071 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5 Known to work||10.1.0, 8.1.0, 8.5.0 Keywords||wrong-code Summary|Incorrect code with -Os and |[9 Regression] Incorrect |complex |code with -Os and ||complex Component|c++ |middle-end Known to fail||9.1.0, 9.3.0, 9.4.0
[Bug target/99754] [sse2] new _mm_loadu_si16 and _mm_loadu_si32 implemented incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99754 --- Comment #7 from Hongtao.liu --- > > But that's unrelated to correctness; this bug can be closed unless we're > keeping it open until it's fixed in the GCC11 current stable series. Let me do the backporting.
[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #15 from Hongtao.liu ---
Clang's implementation:
1681static __inline__ __m128 __DEFAULT_FN_ATTRS
1682_mm_load_ss(const float *__p)
1683{
1684 struct __mm_load_ss_struct {
1685float __u;
1686 } __attribute__((__packed__, __may_alias__));
1687 float __u = ((const struct __mm_load_ss_struct*)__p)->__u;
1688 return __extension__ (__m128){ __u, 0, 0, 0 };
1689}
Guess we can do similar things, will handle it in GCC13.
[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 --- Comment #16 from Andrew Pinski --- >According to Intel ( > https://software.intel.com/sites/landingpage/IntrinsicsGuide), there are no > alignment requirements for _mm_load_sd, _mm_store_sd and _mm_loaddup_pd. For > example, from _mm_load_sd: I disagree with saying there is no alignment requirement. The alignment requirement comes from the type of the argument (double const*). So either the intrinsics definition needs to be changed to be correct or GCC is correct. Pointers themselves have an alignment requirement not just at the time of the load/store of them.
[Bug target/104915] Miss optimization for vec_setv8hi_0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104915 --- Comment #1 from Hongtao.liu --- As described in PR105066, pinsrw mem should be better than movzx + vmovd.
[Bug target/105066] GCC thinks pinsrw xmm, mem, 0 requires SSE4.1, not SSE2? _mm_loadu_si16 bounces through integer reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105066
--- Comment #1 from Hongtao.liu ---
pinsrw is under sse2 for both reg and mem operands, but not for pextrw which
requires sse4.1 for memory operands.
10593(define_insn "vec_set_0"
10594 [(set (match_operand:V8_128 0 "register_operand"
10595 "=v,v,v,x,x,Yr,*x,x,x,x,v,v")
10596(vec_merge:V8_128
10597 (vec_duplicate:V8_128
10598(match_operand: 2 "nonimmediate_operand"
10599 " r,m,v,r,m,Yr,*x,r,m,x,r,m"))
10600 (match_operand:V8_128 1 "reg_or_0_operand"
10601 " C,C,v,0,0,0 ,0 ,x,x,x,v,v")
10602 (const_int 1)))]
10603 "TARGET_SSE2"
10604 "@
10605 vmovw\t{%k2, %0|%0, %k2}
10606 vmovw\t{%2, %0|%0, %2}
10607 vmovsh\t{%2, %1, %0|%0, %1, %2}
10608 pinsrw\t{$0, %k2, %0|%0, %k2, 0}
10609 pinsrw\t{$0, %2, %0|%0, %2, 0}
10610 pblendw\t{$1, %2, %0|%0, %2, 1}
10611 pblendw\t{$1, %2, %0|%0, %2, 1}
10612 vpinsrw\t{$0, %k2, %1, %0|%0, %1, %k2, 0}
10613 vpinsrw\t{$0, %2, %1, %0|%0, %1, %2, 0}
10614 vpblendw\t{$1, %2, %1, %0|%0, %1, %2, 1}
10615 vpinsrw\t{$0, %k2, %1, %0|%0, %1, %k2, 0}
10616 vpinsrw\t{$0, %2, %1, %0|%0, %1, %2, 0}"
10617 [(set (attr "isa")
10618(cond [(eq_attr "alternative" "0,1,2")
10619 (const_string "avx512fp16")
10620 (eq_attr "alternative" "3")
10621 (const_string "noavx")
10622 (eq_attr "alternative" "4,5,6")
10623 (const_string "sse4_noavx")
alternative 4 doesn't require sse4.
and for performance pinsw mem > vmovd reg > pinsrw reg
and yes, it's sub-optimization for below.
pmovzxbq(void*): # -O3 -msse4.1 -mtune=haswell
pxor%xmm0, %xmm0 # 1 uop
pinsrw $0, (%rdi), %xmm0 # 2 uops, one for shuffle port
pmovzxbq%xmm0, %xmm0 # 1 uop for the same shuffle port
ret
[Bug target/99754] [sse2] new _mm_loadu_si16 and _mm_loadu_si32 implemented incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99754
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:85568e505c3b06708ec0fb21d1ab4f78e0c66896
commit r11-9699-g85568e505c3b06708ec0fb21d1ab4f78e0c66896
Author: Jakub Jelinek
Date: Mon Mar 14 10:44:38 2022 +0100
i386: Fix up _mm_loadu_si{16,32} [PR99754]
These intrinsics are supposed to do an unaligned may_alias load
of a 16-bit or 32-bit value and store it as the first element of
a 128-bit integer vector, with all other elements cleared.
The current _mm_storeu_* implementation implements that correctly, uses
__*_u types to do the store and extracts the first element of a vector into
it.
But _mm_loadu_si{16,32} gets it all wrong. It performs an aligned
non-may_alias load and because _mm_set_epi{16,32} has the args reversed,
it also inserts it into the last vector element instead of first.
The following patch fixes that.
Note, while the Intrinsics guide for _mm_loadu_si32 says SSE2,
for _mm_loadu_si16 it says strangely SSE. But the intrinsics
returns __m128i, which is only defined in emmintrin.h, and
_mm_set_epi16 is also only SSE2 and later in emmintrin.h.
Even clang defines it in emmintrin.h and ends up with inlining
failure when calling _mm_loadu_si16 from sse,no-sse2 function.
So, isn't that a bug in the intrinsic guide instead?
2022-03-14 Jakub Jelinek
PR target/99754
* config/i386/emmintrin.h (_mm_loadu_si32): Put loaded value into
first rather than last element of the vector, use __m32_u to do
a really unaligned load, use just 0 instead of (int)0.
(_mm_loadu_si16): Put loaded value into first rather than last
element of the vector, use __m16_u to do a really unaligned load,
use just 0 instead of (short)0.
* gcc.target/i386/pr99754-1.c: New test.
* gcc.target/i386/pr99754-2.c: New test.
[Bug target/99754] [sse2] new _mm_loadu_si16 and _mm_loadu_si32 implemented incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99754 --- Comment #9 from Hongtao.liu --- (In reply to Hongtao.liu from comment #7) > > > > But that's unrelated to correctness; this bug can be closed unless we're > > keeping it open until it's fixed in the GCC11 current stable series. > > Let me do the backporting. Fixed in GCC 11.3
[Bug target/105034] [10/11/12 regression]Suboptimal codegen for min/max with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105034
--- Comment #2 from Hongyu Wang ---
For -O2 stv doesn't do such transform
Computing gain for chain #1...
Instruction gain 8 for 7: {r84:SI=smax(r85:SI,0);clobber flags:CC;}
REG_DEAD r85:SI
REG_UNUSED flags:CC
Instruction conversion gain: 8
Registers conversion cost: 12
Total gain: -4
Since sse->integer reg move cost is 6 for generic cost.
Buf for -Os the cost is 3 so it is consider to be profitable.
Computing gain for chain #1...
Instruction gain 8 for 7: {r84:SI=smax(r85:SI,0);clobber flags:CC;}
REG_DEAD r85:SI
REG_UNUSED flags:CC
Instruction conversion gain: 8
Registers conversion cost: 6
Total gain: 2
FWIW, the solution would be either adjust the ix86_size cost, or blocks out
optimize_size in the stv gate.
[Bug target/105072] New: Miss optimization for pmovzxbq.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105072
Bug ID: 105072
Summary: Miss optimization for pmovzxbq.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
This is quoted from PR105066:
It's also essential that these loads fold efficiently into memory source
operands for PMOVZX; pmovzxbq is one of the major use-cases for a 16-bit load.
That may be a separate bug, IDK
https://godbolt.org/z/3a9T55n3q shows _mm_cvtepu8_epi32(_mm_loadu_si32(p)) does
fold a 32-bit memory source operand nicely to pmovzxbd (%rdi), %xmm0 which can
micro-fuse into a single uop on Intel CPUs (for the 128-bit destination
version, not YMM), but disaster with 16-bit loads:
__m128i pmovzxbq(void *p){
return _mm_cvtepu8_epi64(_mm_loadu_si16(p));
}
pmovzxbq(void*): # -O3 -msse4.1 -mtune=haswell
pxor%xmm0, %xmm0 # 1 uop
pinsrw $0, (%rdi), %xmm0 # 2 uops, one for shuffle port
pmovzxbq%xmm0, %xmm0 # 1 uop for the same shuffle port
ret
(_mm_cvtepu8_epi64 requires SSE4.1 so there's no interaction with the
-mno-sse4.1 implementation of the load.)
[Bug target/105066] GCC thinks pinsrw xmm, mem, 0 requires SSE4.1, not SSE2? _mm_loadu_si16 bounces through integer reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105066 --- Comment #2 from Hongtao.liu --- > That may be a separate bug, IDK > Open PR105072 for it.
[Bug target/105073] New: [meta bug]Patch pending for GCC13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105073 Bug ID: 105073 Summary: [meta bug]Patch pending for GCC13. Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: crazylht at gmail dot com Target Milestone: --- This metabug is used to track all the patches which have been written during Stage 3 of GCC 12 but do not qualify for that stage, and are waiting for Stage 1 of GCC 13 to be applied. Please, do not attach patches to this bug. Open a new bug report, and mark it as "blocking" this metabug (this metabug will "depend" on the new bug report).
[Bug target/104610] memcmp () == 0 can be optimized better for avx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104610 --- Comment #15 from Hongtao.liu --- Could someone help to mark this blocks PR105073, the patch is ready and waiting for GCC13.
[Bug target/104610] memcmp () == 0 can be optimized better for avx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104610 Hongtao.liu changed: What|Removed |Added Attachment #52495|0 |1 is obsolete|| --- Comment #16 from Hongtao.liu --- Created attachment 52692 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52692&action=edit Patch pending for GCC13
[Bug tree-optimization/105056] [12 Regression] runtime error: load of value 3132799674, which is not a valid value for type 'ref_step_type' since r12-7795-g85b4d881327e31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105056 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Richard Biener --- Agree with RS_ANY, note the value is always initialized, just the dumping is done before initializing in filter_suitable_components. It would be most appropriate to avoid reading it in the early dumping but initializing to RS_ANY should be OK (and not confusing in the early dumping). Mine.
[Bug tree-optimization/105053] [11 Regression] Wrong loop count for scalar code from vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105053 Richard Biener changed: What|Removed |Added Version|12.0|11.2.0 Summary|Wrong loop count for scalar |[11 Regression] Wrong loop |code from vectorizer|count for scalar code from ||vectorizer Known to fail||11.2.0 Target Milestone|--- |11.3 Priority|P3 |P2
[Bug tree-optimization/104964] Wrong *** buffer overflow detected ***: terminated - acl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Siddhesh Poyarekar changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |WONTFIX
--- Comment #15 from Siddhesh Poyarekar ---
(In reply to Jakub Jelinek from comment #14)
> Thus I'd say fix up acl instead.
OK, closing this as WONTFIX then. __bos/__bdos has limited support for zero
sized arrays; they are not recognized as flex arrays when in nested structs.
Fixing up the struct to one with a proper flex array (i.e. without a dimension
size, which also will need another member preceding it) should make this work
correctly. Something like:
struct __string_ext
{
char pad;
char s_str[];
};
[Bug fortran/102043] [9/10/11/12 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #36 from rguenther at suse dot de --- On Sun, 27 Mar 2022, mikael at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 > > --- Comment #35 from Mikael Morin --- > A little status update. > > I have pushed the latest patch attached to this PR a little further, but not > far enough to reduce the number of testsuite regressions to 0. > > I plan to submit it for gcc-13, but it won’t make it for gcc-12. > > (In reply to Richard Biener from comment #33) > > With > > a single dimension there's not much value in using ARRAY_REF over > > pointer arithmetic and dereference. > > I have tried to fix this PR using pointer arithmetic too. > But there are so many places in the frontend where we expect to have an array > type when dereferencing a descriptor pointer, that it’s not as simple as it > seems and I finally convinced myself that the patch attached to this PR was > the > best way to go. OK. > For gcc-12, is there a way to add a middle-end workaround using annotations on > descriptor types (a lang flag or something) ? I will think of what options we have to work around this in the middle-end (maybe with help of the frontend during gimplification).
[Bug target/102957] [riscv64] ICE on bogus -march value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102957 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Kito Cheng : https://gcc.gnu.org/g:40e9979cf531e6a1ca1db8804c80e40e0e71de4c commit r11-9700-g40e9979cf531e6a1ca1db8804c80e40e0e71de4c Author: Kito Cheng Date: Mon Nov 8 22:45:49 2021 +0800 [PR/target 102957] Allow Z*-ext extension with only 2 char. We was assume the Z* extension should be more than 2 char, so we put an assertion there, but it should just an error or warning rather than an assertion, however RISC-V has add `Zk` extension, which just 2 char, so actually, we should just allow that. gcc/ChangeLog PR target/102957 * common/config/riscv/riscv-common.c (multi_letter_subset_rank): Remove assertion for Z*-ext. gcc/testsuite/ChangeLog * gcc.target/riscv/pr102957.c: New. (cherry picked from commit abe562bb01479ea2c8952ad98714f3225527aa7e)
[Bug target/102957] [riscv64] ICE on bogus -march value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102957 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Kito Cheng --- Backported to GCC 11.
