[Bug c/100575] ICE: in expand_stack_alignment, at cfgexpand.c:6385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100575 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-05-13 --- Comment #1 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570269.html
[Bug other/100585] Osx 10.7 Lion Make failed : uninitialized cost member, many errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100585 --- Comment #1 from bug-reports.delphin at laposte dot net --- Created attachment 50807 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50807=edit my-configure.log Lion v. 11.1.0
[Bug c++/100588] New: Destroying delete shouldn't be called if constructor throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100588
Bug ID: 100588
Summary: Destroying delete shouldn't be called if constructor
throws
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richardpku at gmail dot com
Target Milestone: ---
Consider this program:
#include
#include
class A {
public:
A() { throw 42; }
~A() { puts("A::~A"); }
void operator delete(void* p) {
puts("regular delete invoked");
::operator delete(p);
}
void operator delete(A* p, std::destroying_delete_t) {
puts("destroying delete invoked");
p->~A();
::operator delete(p);
}
};
int main() {
try {
new A;
} catch (int) {
}
}
Output compiled with GCC:
destroying delete invoked
A::~A
Output compiled with Clang:
regular delete invoked
I believe clang has the correct behavior.
A destroying delete function is expected to invoke the destructor explicitly.
As a result, the current GCC implementation would indirectly invoke the
destructor on an instance that wasn't successfully constructed, which obviously
isn't the intended behavior.
It is even worse if class A has a base class, in which case the destructor of
the base class is called twice if an exception is thrown in A's constructor.
[Bug sanitizer/100439] stack overflow running ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439 --- Comment #7 from Florin Iucha --- Created attachment 50809 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50809=edit crosstool-ng configuration file
[Bug target/100419] Arm: arm_mve.h generates warning when compiled with -Wsystem-headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100419 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by SRINATH PARVATHANENI : https://gcc.gnu.org/g:788f9c8e0c271bcd38049e1c87cda087f449f655 commit r10-9822-g788f9c8e0c271bcd38049e1c87cda087f449f655 Author: Srinath Parvathaneni Date: Tue May 11 10:43:11 2021 +0100 arm: Remove duplicate definitions from arm_mve.h (pr100419). This patch removes several duplicated intrinsic definitions from arm_mve.h mentioned in PR100419 and also fixes the wrong arguments in few of intrinsics polymorphic variants. gcc/ChangeLog: 2021-05-04 Srinath Parvathaneni PR target/100419 * config/arm/arm_mve.h (__arm_vstrwq_scatter_offset): Fix wrong arguments. (__arm_vcmpneq): Remove duplicate definition. (__arm_vstrwq_scatter_offset_p): Likewise. (__arm_vmaxq_x): Likewise. (__arm_vmlsdavaq): Likewise. (__arm_vmlsdavaxq): Likewise. (__arm_vmlsdavq_p): Likewise. (__arm_vmlsdavxq_p): Likewise. (__arm_vrmlaldavhaq): Likewise. (__arm_vstrbq_p): Likewise. (__arm_vstrbq_scatter_offset): Likewise. (__arm_vstrbq_scatter_offset_p): Likewise. (__arm_vstrdq_scatter_offset): Likewise. (__arm_vstrdq_scatter_offset_p): Likewise. (__arm_vstrdq_scatter_shifted_offset): Likewise. (__arm_vstrdq_scatter_shifted_offset_p): Likewise. Co-authored-by: Joe Ramsay (cherry picked from commit 9b905ba9ebba8d2cc805c26351225e7f74c02333)
[Bug target/100419] Arm: arm_mve.h generates warning when compiled with -Wsystem-headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100419 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by SRINATH PARVATHANENI : https://gcc.gnu.org/g:ac5bab25cfd99dd530c8c83992d81e2c88e543d0 commit r11-8409-gac5bab25cfd99dd530c8c83992d81e2c88e543d0 Author: Srinath Parvathaneni Date: Tue May 11 10:43:11 2021 +0100 arm: Remove duplicate definitions from arm_mve.h (pr100419). This patch removes several duplicated intrinsic definitions from arm_mve.h mentioned in PR100419 and also fixes the wrong arguments in few of intrinsics polymorphic variants. gcc/ChangeLog: 2021-05-04 Srinath Parvathaneni PR target/100419 * config/arm/arm_mve.h (__arm_vstrwq_scatter_offset): Fix wrong arguments. (__arm_vcmpneq): Remove duplicate definition. (__arm_vstrwq_scatter_offset_p): Likewise. (__arm_vmaxq_x): Likewise. (__arm_vmlsdavaq): Likewise. (__arm_vmlsdavaxq): Likewise. (__arm_vmlsdavq_p): Likewise. (__arm_vmlsdavxq_p): Likewise. (__arm_vrmlaldavhaq): Likewise. (__arm_vstrbq_p): Likewise. (__arm_vstrbq_scatter_offset): Likewise. (__arm_vstrbq_scatter_offset_p): Likewise. (__arm_vstrdq_scatter_offset): Likewise. (__arm_vstrdq_scatter_offset_p): Likewise. (__arm_vstrdq_scatter_shifted_offset): Likewise. (__arm_vstrdq_scatter_shifted_offset_p): Likewise. Co-authored-by: Joe Ramsay (cherry picked from commit 9b905ba9ebba8d2cc805c26351225e7f74c02333)
[Bug sanitizer/100439] stack overflow running ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439 --- Comment #6 from Florin Iucha --- With the test file above, and this Makefile: --8< --8< --8< --8< --8< --8< --8< --8< --8< --8< --8< --8< ALL: bin/test_hello .PHONY: clean CXX=/opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ CXXFLAGS=-m64 -g -std=c++20 -fsanitize=undefined -fno-omit-frame-pointer LDFLAGS=-Wl,-rpath -Wl,/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib -Wl,-dynamic-linker /opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/ld-linux-x86-64.so.2 -fsanitize=undefined GOOGLE_TEST_PATH=googletest/googletest GOOGLE_TEST_OBJECTS=obj/gtest.o obj/gtest_main.o obj/gtest-port.o obj/gtest-filepath.o obj/gtest-death-test.o obj/gtest-test-part.o obj/gtest-printers.o obj/test_hello.o: test_hello.cpp $(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include -c $< obj/gtest.o: $(GOOGLE_TEST_PATH)/src/gtest.cc $(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include -I$(GOOGLE_TEST_PATH) -c $< obj/gtest%.o: $(GOOGLE_TEST_PATH)/src/gtest%.cc $(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include -I$(GOOGLE_TEST_PATH) -c $< bin/test_hello: obj/test_hello.o $(GOOGLE_TEST_OBJECTS) $(CXX) -o $@ $(LDFLAGS) $^ -lpthread clean: $(RM) bin/test_hello obj/*.o --8< --8< --8< --8< --8< --8< --8< --8< --8< --8< --8< --8< Cloning google test: $ git clone https://github.com/google/googletest (The HEAD now is at f5e592d8ee5ffb1d9af5be7f715ce3576b8bf9c4) Building: $ make /opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20 -fsanitize=undefined -fno-omit-frame-pointer -o obj/test_hello.o -Igoogletest/googletest/include -c test_hello.cpp /opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20 -fsanitize=undefined -fno-omit-frame-pointer -o obj/gtest.o -Igoogletest/googletest/include -Igoogletest/googletest -c googletest/googletest/src/gtest.cc /opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20 -fsanitize=undefined -fno-omit-frame-pointer -o obj/gtest_main.o -Igoogletest/googletest/include -Igoogletest/googletest -c googletest/googletest/src/gtest_main.cc /opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20 -fsanitize=undefined -fno-omit-frame-pointer -o obj/gtest-port.o -Igoogletest/googletest/include -Igoogletest/googletest -c googletest/googletest/src/gtest-port.cc /opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20 -fsanitize=undefined -fno-omit-frame-pointer -o obj/gtest-filepath.o -Igoogletest/googletest/include -Igoogletest/googletest -c googletest/googletest/src/gtest-filepath.cc /opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20 -fsanitize=undefined -fno-omit-frame-pointer -o obj/gtest-death-test.o -Igoogletest/googletest/include -Igoogletest/googletest -c googletest/googletest/src/gtest-death-test.cc /opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20 -fsanitize=undefined -fno-omit-frame-pointer -o obj/gtest-test-part.o -Igoogletest/googletest/include -Igoogletest/googletest -c googletest/googletest/src/gtest-test-part.cc /opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -m64 -g -std=c++20 -fsanitize=undefined -fno-omit-frame-pointer -o obj/gtest-printers.o -Igoogletest/googletest/include -Igoogletest/googletest -c googletest/googletest/src/gtest-printers.cc /opt/tng-gcc11-glibc-linux5.4/bin/x86_64-tng-linux-gnu-g++ -o bin/test_hello -Wl,-rpath -Wl,/opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib -Wl,-dynamic-linker /opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/ld-linux-x86-64.so.2 -fsanitize=undefined obj/test_hello.o obj/gtest.o obj/gtest_main.o obj/gtest-port.o obj/gtest-filepath.o obj/gtest-death-test.o obj/gtest-test-part.o obj/gtest-printers.o -lpthread Running: $ ./bin/test_hello zsh: segmentation fault (core dumped) ./bin/test_hello Debugging: (gdb) b __dynamic_cast Breakpoint 1 at 0x4095c0 (gdb) ignore 1 3 Will ignore next 3 crossings of breakpoint 1. (gdb) run ... Breakpoint 1, 0x77ea92fd in __dynamic_cast () from /opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6 (gdb) bt #0 0x77ea92fd in __dynamic_cast () from /opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libstdc++.so.6 #1 0x7736be36 in ?? () from /opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1 #2 0x7736ae7a in ?? () from /opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1 #3 0x7736b3b2 in __ubsan_handle_dynamic_type_cache_miss () from /opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/sysroot/lib/libubsan.so.1 #4 0x0045fdaa in std::type_info::operator== (this=0x77f97068 , __arg=...) at /opt/tng-gcc11-glibc-linux5.4/x86_64-tng-linux-gnu/include/c++/11.1.1/typeinfo:122 #5 0x77eab007 in
[Bug other/100585] Osx 10.7 Lion Make failed : uninitialized cost member, many errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100585 --- Comment #2 from bug-reports.delphin at laposte dot net --- Created attachment 50808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50808=edit my-make.log Lion v. 11.1.0
[Bug target/100563] [10/11 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:ecfb8658c04114d87e1000f9924d6c373df0e7fd commit r11-8408-gecfb8658c04114d87e1000f9924d6c373df0e7fd Author: Richard Earnshaw Date: Thu May 13 11:42:58 2021 +0100 arm: correctly handle inequality comparisons against max constants [PR100563] Normally we expect the gimple optimizers to fold away comparisons that are always true, but at some lower optimization levels this is not always the case, so the back-end has to be able to generate correct code in these cases. In this example, we have a comparison of the form (unsigned long long) op <= ~0ULL which, of course is always true. Normally, in the arm back-end we handle these expansions where the immediate cannot be handled directly by adding 1 to the constant and then adjusting the comparison operator: (unsigned long long) op < CONST + 1 but we cannot do that when the constant is already the largest value. Fortunately, we observe that the comparisons we need to handle this way are either always true or always false, so instead of forming a comparison against the maximum value, we can replace it with a comparison against the minimum value (which just happens to also be a constant we can handle. So op1 <= ~0ULL -> op1 >= 0U op1 > ~0ULL -> op1 < 0U op1 <= LONG_LONG_INT_MAX -> op1 >= (-LONG_LONG_INT_MAX - 1) op1 > LONG_LONG_INT_MAX -> op1 < (-LONG_LONG_INT_MAX - 1) gcc: PR target/100563 * config/arm/arm.c (arm_canonicalize_comparison): Correctly canonicalize DImode inequality comparisons against the maximum integral value. gcc/testsuite: * gcc.dg/pr100563.c: New test.
[Bug libstdc++/100587] std::ranges::empty_view is not a view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100587 gcc-bugs at marehr dot dialup.fu-berlin.de changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Sorry for the noise
[Bug tree-optimization/100453] [12 Regression] wrong code at -O1 and above since r12-434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453 --- Comment #4 from Martin Jambor --- I proposed a patch to address this on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570267.html
[Bug target/100563] [10/11 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:1d1a690b4dfa224228151fed4bed47c7fe412e0b commit r10-9821-g1d1a690b4dfa224228151fed4bed47c7fe412e0b Author: Richard Earnshaw Date: Thu May 13 11:42:58 2021 +0100 arm: correctly handle inequality comparisons against max constants [PR100563] Normally we expect the gimple optimizers to fold away comparisons that are always true, but at some lower optimization levels this is not always the case, so the back-end has to be able to generate correct code in these cases. In this example, we have a comparison of the form (unsigned long long) op <= ~0ULL which, of course is always true. Normally, in the arm back-end we handle these expansions where the immediate cannot be handled directly by adding 1 to the constant and then adjusting the comparison operator: (unsigned long long) op < CONST + 1 but we cannot do that when the constant is already the largest value. Fortunately, we observe that the comparisons we need to handle this way are either always true or always false, so instead of forming a comparison against the maximum value, we can replace it with a comparison against the minimum value (which just happens to also be a constant we can handle. So op1 <= ~0ULL -> op1 >= 0U op1 > ~0ULL -> op1 < 0U op1 <= LONG_LONG_INT_MAX -> op1 >= (-LONG_LONG_INT_MAX - 1) op1 > LONG_LONG_INT_MAX -> op1 < (-LONG_LONG_INT_MAX - 1) gcc: PR target/100563 * config/arm/arm.c (arm_canonicalize_comparison): Correctly canonicalize DImode inequality comparisons against the maximum integral value. gcc/testsuite: * gcc.dg/pr100563.c: New test.
[Bug target/100563] [10/11 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563 Richard Earnshaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Earnshaw --- Fixed on all branches
[Bug c++/100588] Destroying delete shouldn't be called if constructor throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100588 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-13
[Bug ada/100559] build failure of 32-bit Ada runtime after local modification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559 --- Comment #17 from Petr Sumbera --- (In reply to Petr Sumbera from comment #16) > (In reply to r...@cebitec.uni-bielefeld.de from comment #15) > > I'd seen that change before in solaris-userland, but never understood > > the point. Those directories are only used inside the build trees. > > Ok. I will see if we can remove it for GCC 11. I think it was done because of packaging. So that SPARC and Intel would have more similar paths (in one manifest file). But it can be overcome. I will try to avoid the patch file.
[Bug other/99933] gcc/brig/brigfrontend/brig-function.cc: 4 * possible performance problem ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99933 Martin Liška changed: What|Removed |Added Resolution|--- |WONTFIX Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Liška --- HSA is gone.
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 99933, which changed state. Bug 99933 Summary: gcc/brig/brigfrontend/brig-function.cc: 4 * possible performance problem ? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99933 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX
[Bug sanitizer/100439] stack overflow running ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439 --- Comment #5 from Florin Iucha --- It is a "CMake object library" - not a static library. I will prepare a more self-contained test case shortly.
[Bug driver/100586] New: g++: error: unrecognized command-line option ‘-fump-tree-original’; did you mean ‘-fdump-d-original’?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100586 Bug ID: 100586 Summary: g++: error: unrecognized command-line option ‘-fump-tree-original’; did you mean ‘-fdump-d-original’? Product: gcc Version: 11.1.1 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- If you add the option -fump-tree-original (N.B. missing the 'd') then the fix-it is nonsense: g++: error: unrecognized command-line option ‘-fump-tree-original’; did you mean ‘-fdump-d-original’? It seems to have inserted the 'd' at the right place but then also replaced 'tree' with 'd'.
[Bug c++/86385] calling wrong constructors?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86385
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2018-07-03 00:00:00 |2021-5-13
--- Comment #3 from Jonathan Wakely ---
It's not calling the wrong constructor, GCC is just making a trivial copy of
the object (without using any constructor) for the second operand of the ?:
expression. That is never constructed using a constructor, but it is destroyed,
which causes the double free.
;; Function main (main, funcdef_no=14, decl_uid=2419, cgraph_uid=15,
symbol_order=14) (executed once)
int main ()
{
struct A D.2421;
struct A D.2423;
void * _8;
[local count: 1073741824]:
D.2421 ={v} {CLOBBER};
_8 = operator new (4);
MEM[(int *)_8] = 42;
D.2421.a = _8;
__builtin_printf ("C %p\n", );
D.2423 = D.2421;
A::~A ();
D.2423 ={v} {CLOBBER};
A::~A ();
D.2421 ={v} {CLOBBER};
return 0;
}
[Bug tree-optimization/100487] A possible divide by zero bug in jump_table_cluster::emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100487 Martin Liška changed: What|Removed |Added Resolution|--- |INVALID Status|ASSIGNED|RESOLVED --- Comment #2 from Martin Liška --- While get_range can return 0, it can't be zero in ::emit function. At the place we already know that a non-trivial range is expanded.
[Bug target/100563] [10/11 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:efd471a980662f113dad8de0c0ef8593d0d38419 commit r12-772-gefd471a980662f113dad8de0c0ef8593d0d38419 Author: Richard Earnshaw Date: Thu May 13 14:52:05 2021 +0100 testsuite: suppress cast warnings in pr100563.c [PR100563] Fix a warning when building on machines that don't have 32-bit pointers gcc/testsuite: PR target/100563 * gcc.dg/pr100563.c (dg-options): Add -wno-pointer-to-int-cast.
[Bug c++/100589] New: function with trailing return type must specify return type 'auto' instead of 'concept auto'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100589 Bug ID: 100589 Summary: function with trailing return type must specify return type 'auto' instead of 'concept auto' Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: stanislaw.w.morawski at gmail dot com Target Milestone: --- https://godbolt.org/z/jnahsxrnq Behaviour: Concept is being ignored when used with auto keyword preceding function with trailing return type. Expected Behaviour: Syntax error: improper use of concept.
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d80aeff0bf2f455e9099def756f612bfbcd2cb0d
commit r12-773-gd80aeff0bf2f455e9099def756f612bfbcd2cb0d
Author: Jakub Jelinek
Date: Thu May 13 16:53:48 2021 +0200
openmp: Add testcases to verify OpenMP 5.0 2.14 and OpenMP 5.1 2.17 rules
[PR99928]
In preparation of PR99928 patch review, I've prepared testcases with
clauses
that need more interesting handling on combined/composite constructs,
in particular firstprivate, lastprivate, firstprivate+lastprivate, linear
(explicit on non-iv, explicit on simd iv, implicit on simd iv, implicit on
simd iv declared in the construct), reduction (scalars, array sections of
array variables, array sections with pointer bases) and in_reduction.
OpenMP 5.0 had the wording broken for reduction, the intended rule to use
map(tofrom:) on target when combined with it was bound only on inscan
modifier
presence which makes no sense, as then inscan may not be used, this has
been fixed in 5.1 and I'm just assuming 5.1 wording for that.
There are various cases where e.g. from historical or optimization reasons
GCC slightly deviates from the rules, but in most cases it is something
that shouldn't be really observable, e.g. whether
#pragma omp parallel for firstprivate(x)
is handled as
#pragma omp parallel shared(x)
#pragma omp for firstprivate(x)
or
#pragma omp parallel firstprivate(x)
#pragma omp for
shouldn't be possible to distinguish in user code. I've added FIXMEs
in the testcases about that, but maybe we just should keep it as is
(alternative would be to do it in standard compliant way and transform
into whatever we like after gimplification (e.g. early during omplower)).
Some cases we for historical reasons implement even with clauses on
constructs which in the standard don't accept them that way and then
handling those magically in omp lowering/expansion, in particular e.g.
#pragma omp parallel for firstprivate(x) lastprivate(x)
we treat as
#pragma omp parallel firstprivate(x) lastprivate(x)
#pragma omp for
even when lastprivate is not valid on parallel. Maybe one day we
could change that if we make sure we don't regress generated code quality.
I've also found a bug in OpenMP 5.0/5.1,
#pragma omp parallel sections firstprivate(x) lastprivate(x)
incorrectly says that it should be handled as
#pragma omp parallel firstprivate(x)
#pragma omp sections lastprivate(x)
which when written that way results in error; filed as
https://github.com/OpenMP/spec/issues/2758
to be fixed in OpenMP 5.2. GCC handles it the way it used to do
and users expect, so nothing to fix on the GCC side.
Also, we don't support yet in_reduction clause on target construct,
which means the -11.c testcase can't include any tests about in_reduction
handling on all the composite constructs that include target.
The work found two kinds of bugs on the GCC side, one is the known thing
that we implement still the 4.5 behavior and don't mark for
lastprivate/linear/reduction the list item as map(tofrom:) as mentioned
in PR99928. These cases are xfailed in the tests.
And another one is with r21 and r28 in -{8,9,10}.c tests - we don't add
reduction clause on teams for
#pragma omp {target ,}teams distribute simd reduction(+:r)
even when the spec says that teams shouldn't receive reduction only
when combined with loop construct.
In
make check-gcc check-g++ RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
gomp.exp=pr99928*'
testing this shows:
# of expected passes 5648
# of expected failures872
and with Tobias' patch applied:
# of expected passes 5648
# of unexpected successes 384
# of expected failures488
2021-05-13 Jakub Jelinek
PR middle-end/99928
* c-c++-common/gomp/pr99928-1.c: New test.
* c-c++-common/gomp/pr99928-2.c: New test.
* c-c++-common/gomp/pr99928-3.c: New test.
* c-c++-common/gomp/pr99928-4.c: New test.
* c-c++-common/gomp/pr99928-5.c: New test.
* c-c++-common/gomp/pr99928-6.c: New test.
* c-c++-common/gomp/pr99928-7.c: New test.
* c-c++-common/gomp/pr99928-8.c: New test.
* c-c++-common/gomp/pr99928-9.c: New test.
* c-c++-common/gomp/pr99928-10.c: New test.
* c-c++-common/gomp/pr99928-11.c: New test.
[Bug other/100585] New: Osx 10.7 Lion Make failed : uninitialized cost member, many errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100585 Bug ID: 100585 Summary: Osx 10.7 Lion Make failed : uninitialized cost member, many errors Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bug-reports.delphin at laposte dot net Target Milestone: --- Created attachment 50806 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50806=edit Config.log Lion v. 11.1.0 Osx : 10.7.x Lion (last version) Computer : Mac mini Intel core 2 duo Compiler used : gcc 4.9.x (last) built. Bug and steps : - configure seems to be OK, but - make fails, with many errors of the same kind it seems - unable to compile. Remark : gcc compiled up to the 10.2.x version. Same configuration parameters. Enclosed (if correctly uploaded) : - config.log - my-configure.log : issued by configure - my-make.log : issued make.
[Bug tree-optimization/100453] [12 Regression] wrong code at -O1 and above since r12-434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453 --- Comment #5 from Eric Botcazou --- > I proposed a patch to address this on the mailing list: > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570267.html Thanks!
[Bug libstdc++/100587] New: std::range::empty_view is not a view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100587 Bug ID: 100587 Summary: std::range::empty_view is not a view Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de Target Milestone: --- The following snippet does not compile: ```c++ #include static_assert(std::ranges::view); ``` https://godbolt.org/z/3qanzdrb5 The standard says that https://eel.is/c++draft/range.empty#overview-1: > empty_view produces a view of no elements of a particular type. empty_view is defined as inheriting from view_interface, the std::ranges::view expects an inheritance from view_base per default. Furthermore, https://eel.is/c++draft/ranges.syn does not specify > template > inline constexpr bool enable_view> = true; So I guess the standard is inconsistent here.
[Bug target/100419] Arm: arm_mve.h generates warning when compiled with -Wsystem-headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100419 SRINATH PARVATHANENI changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from SRINATH PARVATHANENI --- Committed to Trunk, gcc-11 and gcc-10.
[Bug c/100550] [11/12 Regression] ICE: in fold_convert_loc with function call VLA argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100550 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:957c437363f139313b2c0b2c93ca985df1d98ad2 commit r12-774-g957c437363f139313b2c0b2c93ca985df1d98ad2 Author: Martin Sebor Date: Thu May 13 10:38:09 2021 -0600 PR c/100550 - ICE: in fold_convert_loc with function call VLA argument gcc/c/ChangeLog: PR c/100550 * c-decl.c (get_parm_array_spec): Avoid erroneous VLA bounds. gcc/testsuite/ChangeLog: PR c/100550 * gcc.dg/Wvla-parameter-9.c: New test.
[Bug middle-end/100504] ICE with bad argument to target_clones attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100504 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:9feb5822b713c6a12cb290ba0406ba2362d4c09c commit r12-777-g9feb5822b713c6a12cb290ba0406ba2362d4c09c Author: Martin Liska Date: Thu May 13 13:59:59 2021 +0200 attributes: target_clone expects a string argument PR middle-end/100504 gcc/c-family/ChangeLog: * c-attribs.c (handle_target_clones_attribute): Expect a string argument to target_clone argument. gcc/testsuite/ChangeLog: * gcc.target/i386/pr100504.c: New test.
[Bug middle-end/100504] ICE with bad argument to target_clones attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100504 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Liška --- Fixed on master, not planning any backport.
[Bug rtl-optimization/100590] New: ICE: verify_flow_info failed (error: too many outgoing branch edges from bb 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100590 Bug ID: 100590 Summary: ICE: verify_flow_info failed (error: too many outgoing branch edges from bb 2) Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gcc-12.0.0-alpha20210509 snapshot (g:5e0236d3b0e0d7ad98bcee36128433fa755b5558) and gcc 11.1 ICE when compiling testsuite/gcc.dg/torture/pr100398.c w/ -O1 -fno-dce: % gcc-12.0.0 -O1 -fno-dce -c gcc/testsuite/gcc.dg/torture/pr100398.c gcc/testsuite/gcc.dg/torture/pr100398.c: In function 'test5_limit': gcc/testsuite/gcc.dg/torture/pr100398.c:13:1: error: too many outgoing branch edges from bb 2 13 | } | ^ during RTL pass: cprop_hardreg gcc/testsuite/gcc.dg/torture/pr100398.c:13:1: internal compiler error: verify_flow_info failed 0x9706d3 verify_flow_info() /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210509/work/gcc-12-20210509/gcc/cfghooks.c:269 0xd2d29a execute_function_todo /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210509/work/gcc-12-20210509/gcc/passes.c:2054 0xd2dc8b execute_todo /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210509/work/gcc-12-20210509/gcc/passes.c:2096 It can be a duplicate of PR98619.
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 --- Comment #8 from Jakub Jelinek --- (In reply to Tobias Burnus from comment #7) > Created attachment 50810 [details] > Fortran version of the C testcases (see comment 7 for notes) > > Fortran conversion of the C/C++ testcases of comment 7 / > r12-773-gd80aeff0bf2f455e9099def756f612bfbcd2cb0d > > Currently fails to compile due to those issues: > * 'taskloop' not yet implemented > * 'loop' not yet implemented > * 'parallel master' not supported > * 'reduction(+:r00[1:2])' not supported (also not with '[...]' replaced by > '(...)') I believe in Fortran those ought to be normal base language array sections, so reduction(+:r00(2:3)) or so. E.g. 5.0 says in [296:11] "The list items that appear in a reduction clause may include array sections." and [46:6-7] says: "Fortran has built-in support for array sections although some restrictions apply to their use, as enumerated in the following section." and later there are restrictions. If we don't handle array sections in reduction, that would be missing item from 4.0 -> 4.5 support I think; do we handle array sections on map/to/from at least?
[Bug c/100550] [11/12 Regression] ICE: in fold_convert_loc with function call VLA argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100550 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Martin Sebor --- Fixed on trunk and 11.2.
[Bug rtl-optimization/100590] [11/12 Regression] ICE: verify_flow_info failed (error: too many outgoing branch edges from bb 2) since r11-5002-ge3b3b59683c1e7d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100590 Martin Liška changed: What|Removed |Added Summary|ICE: verify_flow_info |[11/12 Regression] ICE: |failed (error: too many |verify_flow_info failed |outgoing branch edges from |(error: too many outgoing |bb 2) |branch edges from bb 2) ||since ||r11-5002-ge3b3b59683c1e7d3 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-13 --- Comment #1 from Martin Liška --- Started with r11-5002-ge3b3b59683c1e7d3.
[Bug libstdc++/100444] std::random_device isn't random on AMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100444 --- Comment #12 from Edward Cree --- A datum: booting with 'nordrand' on the kernel command line does not affect this, the test program still prints 4294967295. (Yet '/proc/cpuinfo' no longer mentions rdrand or rdseed in flags. Stdlib must be looking at cpuid directly rather than using anything the kernel can mediate?)
[Bug tree-optimization/100578] [12 Regression] ICE Segmentation fault during GIMPLE pass: fre (under -g -O2/O3/Os)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100578 Aldy Hernandez changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Aldy Hernandez --- The definition for_4 has been removed by the time we examine this: b_9 = _3 | _4; *** This bug has been marked as a duplicate of bug 100512 ***
[Bug tree-optimization/100512] [12 Regression] ICE during GIMPLE pass: cddce in mark_operand_necessary, at tree-ssa-dce.c:173 (under -O2 to -Os) since r12-623-g1416a1434c43de0b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100512 --- Comment #5 from Aldy Hernandez --- *** Bug 100578 has been marked as a duplicate of this bug. ***
[Bug sanitizer/100591] New: -fsanitize=undefined fails to detect undefined floating to integer conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100591
Bug ID: 100591
Summary: -fsanitize=undefined fails to detect undefined
floating to integer conversion
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: sch...@linux-m68k.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
$ cat undef.c
#include
volatile double d = 0.0/0.0;
int
main (void)
{
printf ("%d\n", (int) d);
}
$ gcc -fsanitize=undefined undef.c
$ ./a.out
-2147483648
[Bug other/100585] Osx 10.7 Lion Make failed : uninitialized const member, many errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100585 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 100246. *** This bug has been marked as a duplicate of bug 100246 ***
[Bug bootstrap/100246] [11/12 Regression] GCC will not bootstrap with clang 3.4/3.5 [xcode 5/6, Darwin 12/13]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246 Andrew Pinski changed: What|Removed |Added CC||bug-reports.delphin@laposte ||.net --- Comment #7 from Andrew Pinski --- *** Bug 100585 has been marked as a duplicate of this bug. ***
[Bug c/100550] [11/12 Regression] ICE: in fold_convert_loc with function call VLA argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100550 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:4415051422690e6eda2ff6644b4f35432fcd7707 commit r11-8410-g4415051422690e6eda2ff6644b4f35432fcd7707 Author: Martin Sebor Date: Thu May 13 10:45:32 2021 -0600 PR c/100550 - ICE: in fold_convert_loc with function call VLA argument gcc/c/ChangeLog: PR c/100550 * c-decl.c (get_parm_array_spec): Avoid erroneous VLA bounds. gcc/testsuite/ChangeLog: PR c/100550 * gcc.dg/Wvla-parameter-9.c: New test.
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 --- Comment #7 from Tobias Burnus --- Created attachment 50810 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50810=edit Fortran version of the C testcases (see comment 7 for notes) Fortran conversion of the C/C++ testcases of comment 7 / r12-773-gd80aeff0bf2f455e9099def756f612bfbcd2cb0d Currently fails to compile due to those issues: * 'taskloop' not yet implemented * 'loop' not yet implemented * 'parallel master' not supported * 'reduction(+:r00[1:2])' not supported (also not with '[...]' replaced by '(...)')
[Bug tree-optimization/100453] [12 Regression] wrong code at -O1 and above since r12-434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Jambor --- Fixed on trunk. Miscompilation has only been observed there so hopefully that is enough.
[Bug c/100483] Extend -fno-semantic-interposition to global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483 --- Comment #1 from Fangrui Song --- Another request is a new option: -fno-semantic-interposition-function. With this option, we only assume functions cannot be interposed. -fno-semantic-interposition assumes both functions and variables cannot be interposed.
[Bug c++/100594] New: Lambdas in unevaluated contexts interact oddly with alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100594
Bug ID: 100594
Summary: Lambdas in unevaluated contexts interact oddly with
alias templates
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: brycelelbach at gmail dot com
Target Milestone: ---
This code:
```
template struct identity {};
template
using A = decltype([] () constexpr { return int{}; }());
template
using B = identity>;
```
Is incorrectly rejected by GCC in C++20 mode:
```
:7:23: error: template argument 1 is invalid
7 | using B = identity>;
| ^~
ASM generation compiler returned: 1
:7:23: error: template argument 1 is invalid
7 | using B = identity>;
| ^~
Execution build compiler returned: 1
```
https://godbolt.org/z/hGjfvjGzc
For context, I ran into this while writing this code:
https://godbolt.org/z/36xz8zGMd
I discussed this with Ville and Jason via email:
Ville wrote:
> Specifically looks like there's an interaction with an alias template
> here, because
>
> decltype([] () constexpr { return int{}; }())* oink;
> static_assert(std::is_same_v);
>
> is just fine according to GCC.
Jason wrote:
> Yeah, how (unevaluated) lambdas should interact with alias templates is
> unclear, connected to various existing alias template issues around exactly
> how transparent (or not) they are.
>
> You could work around this with a class template or variable template
> that forces the lambda instantiation to be delayed until we have a full
> set of template arguments.
[Bug tree-optimization/100453] [12 Regression] wrong code at -O1 and above since r12-434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:ca9bb74a5f856ccdceb4797f18b0a4ac8f49d069 commit r12-782-gca9bb74a5f856ccdceb4797f18b0a4ac8f49d069 Author: Martin Jambor Date: Thu May 13 23:26:32 2021 +0200 tree-sra: Avoid refreshing into const base decls (PR 100453) When SRA transforms an assignment where the RHS is an aggregate decl that it creates replacements for, the (least efficient) fallback method of dealing with them is to store all the replacements back into the original decl and then let the original assignment takes itc sourse. That of course should not need to be done for TREE_READONLY bases which cannot change contents. The SRA code handled this situation in one of two necessary places but only for DECL_IN_CONSTANT_POOL const decls, this patch modifies both to check TREE_READONLY. gcc/ChangeLog: 2021-05-12 Martin Jambor PR tree-optimization/100453 * tree-sra.c (sra_modify_assign): All const base accesses do not need refreshing, not just those from decl_pool. (sra_modify_assign): Do not refresh into a const base decl. gcc/testsuite/ChangeLog: 2021-05-12 Martin Jambor PR tree-optimization/100453 * gcc.dg/tree-ssa/pr100453.c: New test.
[Bug tree-optimization/100574] [11/12 Regression] ICE: in size_remaining, at builtins.c:413 with -O3 -ftracer -fno-tree-dominator-opts -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100574 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:5380e3c137b2bb63acd789cd09d01a4edc0a01c3 commit r12-784-g5380e3c137b2bb63acd789cd09d01a4edc0a01c3 Author: Martin Sebor Date: Thu May 13 16:20:45 2021 -0600 PR middle-end/100574 - ICE in size_remaining, at builtins.c gcc/ChangeLog: PR middle-end/100574 * builtins.c (access_ref::get_ref): Improve detection of PHIs with all null arguments.
[Bug c++/100594] Lambdas in unevaluated contexts interact oddly with alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100594 Jason Merrill changed: What|Removed |Added Last reconfirmed||2021-05-14 CC||jason at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug c++/99032] GCC accepts attributes on friend declarations (not definitions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99032 --- Comment #3 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:149061188c7c6ddf27663c8c00b7574fc8d0fd23 commit r12-786-g149061188c7c6ddf27663c8c00b7574fc8d0fd23 Author: Marek Polacek Date: Thu Apr 29 21:38:14 2021 -0400 c++: Check attributes on friend declarations [PR99032] This patch implements [dcl.attr.grammar]/5: "If an attribute-specifier-seq appertains to a friend declaration ([class.friend]), that declaration shall be a definition." This restriction applies to C++11-style attributes as well as GNU attributes with the exception that we allow GNU attributes that require a type, such as vector_size to continue accepting code as in attrib63.C. There are various forms of friend declarations, we have friend templates, C++11 extended friend declarations, and so on. In some cases we already ignore the attribute and warn that it was ignored. But certain cases weren't diagnosed, and with this patch we'll give a hard error. I tried hard not to emit both a warning and error and I think it worked out. Jason provided the cp_parser_decl_specifier_seq hunk to detect using standard attributes in the middle of decl-specifiers, which is invalid. Co-authored-by: Jason Merrill gcc/cp/ChangeLog: PR c++/99032 * cp-tree.h (any_non_type_attribute_p): Declare. * decl.c (grokdeclarator): Diagnose when an attribute appertains to a friend declaration that is not a definition. * decl2.c (any_non_type_attribute_p): New. * parser.c (cp_parser_decl_specifier_seq): Diagnose standard attributes in the middle of decl-specifiers. (cp_parser_elaborated_type_specifier): Diagnose when an attribute appertains to a friend declaration that is not a definition. (cp_parser_member_declaration): Likewise. gcc/testsuite/ChangeLog: PR c++/99032 * g++.dg/cpp0x/friend7.C: New test. * g++.dg/cpp0x/gen-attrs-4.C: Add dg-error. * g++.dg/cpp0x/gen-attrs-39-1.C: Likewise. * g++.dg/cpp0x/gen-attrs-74.C: New test. * g++.dg/ext/attrib63.C: New test.
[Bug middle-end/98583] missing -Wuninitialized reading from a second VLA in its own block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98583 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Martin Sebor --- Fixed in GCC 12.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 98583, which changed state. Bug 98583 Summary: missing -Wuninitialized reading from a second VLA in its own block https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98583 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 93100, which changed state. Bug 93100 Summary: gcc -fsanitize=address inhibits -Wuninitialized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93100 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/100574] [11 Regression] ICE: in size_remaining, at builtins.c:413 with -O3 -ftracer -fno-tree-dominator-opts -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100574 Martin Sebor changed: What|Removed |Added Summary|[11/12 Regression] ICE: in |[11 Regression] ICE: in |size_remaining, at |size_remaining, at |builtins.c:413 with -O3 |builtins.c:413 with -O3 |-ftracer|-ftracer |-fno-tree-dominator-opts|-fno-tree-dominator-opts |-fno-tree-fre |-fno-tree-fre Known to fail|12.0| --- Comment #3 from Martin Sebor --- Fixed on trunk.
[Bug middle-end/93100] gcc -fsanitize=address inhibits -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93100 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Martin Sebor --- Fixed in GCC 12.
[Bug c/100593] New: [ELF] -fno-pic: Use GOT to take address of an external default visibility function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
Bug ID: 100593
Summary: [ELF] -fno-pic: Use GOT to take address of an external
default visibility function
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Most ELF targets use an absolute relocation (e.g. R_X86_64_32) to take the
address of a default visibility non-definition function declaration.
The absolute relocation can cause a canonical PLT entry (st_shndx=0,
st_value!=0; The term is a parlance within a few LLD developers, but not
broadly adopted).
If the defining DSO is linked with Bsymbolic-functions (or -Bsymbolic), the
addresses taken within the DSO and outside of the DSO will be different.
Since C++ requires uniqueness of the address, this violates the language
standard.
Outside of the GNU ELF world, many dynamic linking implementations have shifted
to a direct binding and non-interposition by default world.
We have rants from people complaining about shared object performance.
(e.g.
https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=rcus...@mail.gmail.com/
"Re: Very slow clang kernel config .."
https://www.facebook.com/dan.colascione/posts/10107358290728348 "Python is 1.3x
faster when compiled in a way that re-examines shitty technical decisions from
the 1990s.")
I believe ld -Bsymbolic-functions can materialize most of the savings other
implementations provide, without introducing complex things to ELF.
However, since -Bsymbolic-functions doesn't play well with -fno-pic's canonical
PLT entries, we should fix -fno-pic.
Converting a direct access to a GOT access for a function symbol cannot be in a
performance critical path,
so let's just do it.
Static linking is happy, too - the linker can either optimize out the GOT
(x86-64 GOTPCRELX, PPC64 TOC) or prefill the GOT entry with
a constant.
Once -fno-pic has the sane behavior (GOT by default), more and more shared
objects can be optionally built with -Bsymbolic-functions -
if they don't intend to support interposition, while still being compatible
with -fno-pic executables.
How effective is -Bsymbolic-functions? As a data point, my x86_64 Linux kernel
defconfig build with -Bsymbolic-functions linked Clang is 15% faster.
(83% JUMP_SLOT relocations are eliminated!)
% cat a.c
extern void fun();
void *get() { return (void*)fun; }
% gcc -fno-pic -S a.c -O2 -o -
get:
.LFB0:
.cfi_startproc
movl$fun, %eax
ret
% aarch64-linux-gnu-gcc -fno-pic -S a.c -O2 -o -
...
adrpx0, fun
add x0, x0, :lo12:fun
# good, ppc64 elfv2 always uses TOC
% powerpc64le-linux-gnu-gcc -fno-pic -S a.c -O2 -o -
...
addis 3,2,.LC0@toc@ha
ld 3,.LC0@toc@l(3)
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 --- Comment #4 from sandra at gcc dot gnu.org --- OK, there are two flavors of failures being diagnosed by the test case. The first flavor involves the lower bounds of an array passed into a bind(c) procedure being set to zero in the callee when the test case thinks they should be inherited from the array in the caller. I'm still trying to grok what the standard actually says about these cases. The second flavor looks like the same bug as PR93308, involving the lower bounds of an array passed to a bind(c) procedure appearing to be correct in the callee, but set to zero in the caller after return.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #61 from abebeos at lazaridis dot com --- Now, the headline would be: "Physik FU-Berlin, Microchip, Google, RedHat, IBM and more to Support Abuse, Discrimination and even 'IT-fascism' via/on GCC/GNU/FSF Project-Resources". See, nobody cares, until a valid(!) headline gets some visibility. But for now I'll stop here, as I don't want to open/activate accounts in order to publish. And in the end, I would analyze GCC/GNU/FSF weaknesses and threads without getting payed. Just one last thing: John Paul Adrian Glaubitz, you have attacked my professional reputation in public, saying more or less that I claimed the bounty without having done any work for it. But the indisputable fact is that any person that declares "assessment, validation, integration and general reuse of existent results" as "copying" should simply stay away from OSS software. And persons which abuse their (position of) power to brute-force violate voting procedures (or to not intervene), are just some (more or less worse) form of IT-fascists. People like you should be kicked out immediately from OSS projects. Well, at least in a perfect world. Cu around, clowns.
[Bug middle-end/98583] missing -Wuninitialized reading from a second VLA in its own block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98583 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:2efe245bb88bf4574e322ef7e6d2df83d9e13237 commit r12-783-g2efe245bb88bf4574e322ef7e6d2df83d9e13237 Author: Martin Sebor Date: Thu May 13 16:05:50 2021 -0600 Avoid -Wuninitialized false negatives with sanitization and VLAs. Resolves: PR tree-optimization/93100 - gcc -fsanitize=address inhibits -Wuninitialized PR middle-end/98583 - missing -Wuninitialized reading from a second VLA in its own block gcc/ChangeLog: PR tree-optimization/93100 PR middle-end/98583 * tree-ssa-uninit.c (check_defs): Exclude intrinsic functions that don't modify referenced objects. gcc/testsuite/ChangeLog: PR tree-optimization/93100 PR middle-end/98583 * g++.dg/warn/uninit-pr93100.C: New test. * gcc.dg/uninit-pr93100.c: New test. * gcc.dg/uninit-pr98583.c: New test.
[Bug middle-end/93100] gcc -fsanitize=address inhibits -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93100 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:2efe245bb88bf4574e322ef7e6d2df83d9e13237 commit r12-783-g2efe245bb88bf4574e322ef7e6d2df83d9e13237 Author: Martin Sebor Date: Thu May 13 16:05:50 2021 -0600 Avoid -Wuninitialized false negatives with sanitization and VLAs. Resolves: PR tree-optimization/93100 - gcc -fsanitize=address inhibits -Wuninitialized PR middle-end/98583 - missing -Wuninitialized reading from a second VLA in its own block gcc/ChangeLog: PR tree-optimization/93100 PR middle-end/98583 * tree-ssa-uninit.c (check_defs): Exclude intrinsic functions that don't modify referenced objects. gcc/testsuite/ChangeLog: PR tree-optimization/93100 PR middle-end/98583 * g++.dg/warn/uninit-pr93100.C: New test. * gcc.dg/uninit-pr93100.c: New test. * gcc.dg/uninit-pr98583.c: New test.
[Bug c++/100592] New: Bogus "qualifiers cannot be applied" error with reference type produced by dependent alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100592
Bug ID: 100592
Summary: Bogus "qualifiers cannot be applied" error with
reference type produced by dependent alias template
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
template
struct meta {
template
using if_c = T;
};
template<>
struct meta {
template
using if_c = U;
};
template
using if_c = typename meta::template if_c;
template
inline constexpr bool b = false;
template
using foo = if_c, int, T>;
template
struct type {};
template
using test = type const&>;
template
test f();
void g() {
f();
}
GCC rejects:
: In function 'void g()':
:32:12: error: no matching function for call to 'f()'
32 | f();
| ~~~^~
:29:9: note: candidate: 'template test f()'
29 | test f();
| ^
:29:9: note: template argument deduction/substitution failed:
: In substitution of 'template using test = type >::if_c&> [with T = int&]':
:29:9: required by substitution of 'template test f()
[with T = int&]'
:32:12: required from here
:26:7: error: 'const' qualifiers cannot be applied to
'meta::if_c' {aka 'int&'}
26 | using test = type const&>;
| ^~~~
[Bug c++/99032] GCC accepts attributes on friend declarations (not definitions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99032 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed in GCC 12.
[Bug c/100595] New: ICE: output_operand: invalid expression as operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100595
Bug ID: 100595
Summary: ICE: output_operand: invalid expression as operand
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.eZIsobWkq2-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210514 (experimental) [master revision
:e5c3c8afa:f3b1516d9dfd969d7cc1ca6f26dec13478a1c458] (GCC)
$ cat mutant.c
typedef __UINTPTR_TYPE__ uintptr_t;
test2() {
static uintptr_t a = & + ((char *)& - (char *)&);
l1:
l2:
return a;
}
$ gcc-trunk mutant.c
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | test2() {
| ^
mutant.c: In function ‘test2’:
mutant.c:3:24: warning: initialization of ‘uintptr_t’ {aka ‘long unsigned int’}
from ‘void *’ makes integer from pointer without a cast [-Wint-conversion]
3 | static uintptr_t a = & + ((char *)& - (char *)&);
|^~
mutant.c: At top level:
mutant.c:7:1: internal compiler error: output_operand: invalid expression as
operand
7 | }
| ^
0xb7f867 output_operand_lossage(char const*, ...)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/final.c:3238
0xb80341 output_addr_const(_IO_FILE*, rtx_def*)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/final.c:3835
0xb80123 output_addr_const(_IO_FILE*, rtx_def*)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/final.c:3810
0x1240c82 assemble_integer_with_op(char const*, rtx_def*)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/varasm.c:2866
0x1240ce1 default_assemble_integer(rtx_def*, unsigned int, int)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/varasm.c:2882
0x1240d60 assemble_integer(rtx_def*, unsigned int, unsigned int, int)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/varasm.c:2898
0x1247cc8 output_constant
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/varasm.c:5267
0x1249f74 output_constant
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/varasm.c:5172
0x1249f74 assemble_variable_contents
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/varasm.c:2235
0x1253cfc assemble_variable(tree_node*, int, int, int)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/varasm.c:2414
0x1256dc9 varpool_node::assemble_decl()
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/varpool.c:595
0xa80549 output_in_order
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/cgraphunit.c:2135
0xa80549 symbol_table::compile()
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/cgraphunit.c:2353
0xa8365b symbol_table::compile()
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/cgraphunit.c:2269
0xa8365b symbol_table::finalize_compilation_unit()
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/cgraphunit.c:2537
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug go/100537] Bootstrap-O3 and bootstrap-debug fail on 32-bit ARM after gcc-12-657-ga076632e274a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537 --- Comment #14 from Jiu Fu Guo --- Update/correct info: If bootstrap-O3, the message is "error: method 'foo' is ambiguous". It is "error: type has no method 'foo'".
[Bug tree-optimization/100578] [12 Regression] ICE Segmentation fault during GIMPLE pass: fre (under -g -O2/O3/Os)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100578 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-13 Status|UNCONFIRMED |NEW CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r12-623-g1416a1434c43de0b.
[Bug testsuite/100569] [12 regression] gcc.dg/atomic/c11-atomic-exec-2.c has lto warnings after r12-742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100569 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug testsuite/100569] [12 regression] gcc.dg/atomic/c11-atomic-exec-2.c has lto warnings after r12-742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100569 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:810afb0b5fbb9da1e0e51ee9607f275f14c17459 commit r12-762-g810afb0b5fbb9da1e0e51ee9607f275f14c17459 Author: Martin Liska Date: Thu May 13 09:23:30 2021 +0200 testsuite: prune new LTO warning libgomp/ChangeLog: PR testsuite/100569 * testsuite/libgomp.c/omp-nested-3.c: Prune new LTO warning. * testsuite/libgomp.c/pr46032-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/data-clauses-kernels-ipa-pta.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/data-clauses-parallel-ipa-pta.c: Likewise. gcc/testsuite/ChangeLog: PR testsuite/100569 * gcc.dg/atomic/c11-atomic-exec-2.c: Prune new LTO warning. * gcc.dg/torture/pr94947-1.c: Likewise.
[Bug target/100581] [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-731-gb1f7fd8a2a5558da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100581 Alex Coplan changed: What|Removed |Added CC||acoplan at gcc dot gnu.org --- Comment #1 from Alex Coplan --- Is it valid to create a vector type with total size less than the element size? Shouldn't this be rejected?
[Bug c++/100580] [10/11/12 Regression] ICE with -fdump-passes since r10-6837-g2473c81cb2d4627f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100580
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-05-13
Summary|ICE with -fdump-passes |[10/11/12 Regression] ICE
||with -fdump-passes since
||r10-6837-g2473c81cb2d4627f
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||jakub at gcc dot gnu.org,
||marxin at gcc dot gnu.org
--- Comment #1 from Martin Liška ---
Reduced test-case:
$ cat pr100580.c
int pthread_key_create;
static __typeof(pthread_key_create) __gthrw___pthread_key_create
__attribute__((__weakref__("")));
started with r10-6837-g2473c81cb2d4627f.
[Bug target/100581] [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-731-gb1f7fd8a2a5558da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100581 Uroš Bizjak changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Version|11.0|12.0 Last reconfirmed||2021-05-13 Target Milestone|--- |12.0 CC|ubizjak at gmail dot com | Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Uroš Bizjak --- I have a patch - thanks for the testcase, I'll add it to the patch.
[Bug fortran/93308] bind(c) subroutine changes lower bound of array argument in caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93308 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- This bug also affects pointer arrays passed as an argument corresponding to a non-pointer assumed-shape dummy. It's also independent of whether the called bind(c) function is implemented in Fortran or C. PR94331 is at least a partial duplicate of this bug.
[Bug go/100537] Bootstrap-O3 and bootstrap-debug fail on 32-bit ARM after gcc-12-657-ga076632e274a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537 --- Comment #15 from Jiu Fu Guo --- (In reply to Jiu Fu Guo from comment #9) > Yes, > > diff --git a/gcc/go/go-gcc.cc b/gcc/go/go-gcc.cc > index 5d9dbb5d068..32637a44af1 100644 > --- a/gcc/go/go-gcc.cc > +++ b/gcc/go/go-gcc.cc > @@ -1680,6 +1680,7 @@ Gcc_backend::address_expression(Bexpression* bexpr, > Location location) >if (expr == error_mark_node) > return this->error_expression(); > > + TREE_ADDRESSABLE(expr) = 1; >tree ret = build_fold_addr_expr_loc(location.gcc_location(), expr); >return this->make_expression(ret); > } > > Could pass bootstrap. So, this patch would pass bootstrap and regtest.
[Bug testsuite/100569] [12 regression] gcc.dg/atomic/c11-atomic-exec-2.c has lto warnings after r12-742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100569 --- Comment #5 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:c3e02c2e442e6b0c298dbe769e0e3b120b5201b2 commit r12-766-gc3e02c2e442e6b0c298dbe769e0e3b120b5201b2 Author: Eric Botcazou Date: Thu May 13 09:32:50 2021 +0200 Prune another new LTO warning gcc/testsuite/ PR testsuite/100569 * gnat.dg/lto21.adb: Prune new LTO warning.
[Bug target/100581] New: [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-731-gb1f7fd8a2a5558da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100581
Bug ID: 100581
Summary: [12 Regression] ICE in extract_insn, at recog.c:2770
since r12-731-gb1f7fd8a2a5558da
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: ubizjak at gmail dot com
Target Milestone: ---
Host: x86_64-linux-gnu
The following fails:
$ cat ice.C
typedef float __attribute__((__vector_size__(8))) v64f32;
v64f32 af, bf, ff_a, ff_b;
v64f32 f() { return ff_a > ff_b ? af : bf; }
$ g++ ice.C -c -mxop
ice.C: In function ‘v64f32 f()’:
ice.C:3:44: error: unrecognizable insn:
3 | v64f32 f() { return ff_a > ff_b ? af : bf; }
|^
(insn 10 9 13 2 (set (reg:V2SF 86 [ _7 ])
(if_then_else:V2SF (reg:V2SF 86 [ _7 ])
(reg:V2SF 84 [ af.2_4 ])
(reg:V2SF 85 [ bf.3_5 ]))) "ice.C":3:40 -1
(nil))
during RTL pass: vregs
ice.C:3:44: internal compiler error: in extract_insn, at recog.c:2770
0x7fd7bb _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:108
0x7fd7dd _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:116
0x7fb9b1 extract_insn(rtx_insn*)
/home/marxin/Programming/gcc/gcc/recog.c:2770
0xe62989 instantiate_virtual_regs_in_insn
/home/marxin/Programming/gcc/gcc/function.c:1609
0xe62989 instantiate_virtual_regs
/home/marxin/Programming/gcc/gcc/function.c:1983
0xe62989 execute
/home/marxin/Programming/gcc/gcc/function.c:2032
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/100551] [11/12 Regression] Passing return value of intrinsic to class(*) dummy argument can cause segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100551
--- Comment #4 from anlauf at gcc dot gnu.org ---
Playing with the testcase show that the patch in comment#3 is incomplete.
Next try:
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index cce18d094a6..3de53009970 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -5826,7 +5826,9 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
_array);
}
else if (UNLIMITED_POLY (fsym) && e->ts.type != BT_CLASS
- && gfc_expr_attr (e).flavor != FL_PROCEDURE)
+ && e->ts.type != BT_PROCEDURE
+ && (gfc_expr_attr (e).flavor != FL_PROCEDURE
+ || (gfc_expr_attr (e).proc != PROC_UNKNOWN)))
{
/* The intrinsic type needs to be converted to a temporary
CLASS object for the unlimited polymorphic formal. */
This makes the following case work again:
program p
implicit none
integer :: result
result = 1
result = test ((result)) ! works
if (result /= 1) stop 1
result = test (int (result)) ! issue 1
write(*,*) result
result = test (f (result)) ! issue 2
write(*,*) result
contains
integer function test(x)
class(*), intent(in) :: x
select type (x)
type is (integer)
test = x
class default
test = -1
end select
end function test
integer function f(x)
integer, intent(in) :: x
f = 2*x
end function f
end program
[Bug c/100576] [11/12 Regression] ICE at -O1 and above: in decompose, at wide-int.h:984 since r11-2928-gd14c547abd484d35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100576 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-05-13 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Summary|ICE at -O1 and above: in|[11/12 Regression] ICE at |decompose, at |-O1 and above: in |wide-int.h:984 |decompose, at ||wide-int.h:984 since ||r11-2928-gd14c547abd484d35 --- Comment #1 from Martin Liška --- Started with r11-2928-gd14c547abd484d35.
[Bug ada/100559] Solaris SPARC GCC 11.1 Ada build: i-cexten.ads:278:28: modulus exceeds limit (2 ** 64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559 Eric Botcazou changed: What|Removed |Added Status|NEW |WAITING --- Comment #11 from Eric Botcazou --- Can you post the contents of $(srcdir)/gcc/config/sparc/t-sol2 in your setup?
[Bug target/100572] arm: Assemble failures with MVE vcreateq intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100572 Alex Coplan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Alex Coplan --- Closing as this is not a GCC bug, it's a GAS bug.
[Bug tree-optimization/98856] [11/12 Regression] botan AES-128/XTS is slower by ~17% since r11-6649-g285fa338b06b804e72997c4d876ecf08a9c083af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #40 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:829c4bea06600ea4201462f91ce6d76ca21fdb35
commit r12-769-g829c4bea06600ea4201462f91ce6d76ca21fdb35
Author: Jakub Jelinek
Date: Thu May 13 12:14:14 2021 +0200
ix86: Support V{2, 4}DImode arithmetic right shifts for SSE2+ [PR98856]
As mentioned in the PR, we don't support arithmetic right V2DImode or
V4DImode on x86 without -mavx512vl or -mxop. The ISAs indeed don't have
{,v}psraq instructions until AVX512VL, but we actually can emulate it quite
easily.
One case is arithmetic >> 63, we can just emit {,v}pxor; {,v}pcmpgt for
that for SSE4.2+, or for SSE2 psrad $31; pshufd $0xf5.
Then arithmetic >> by constant > 32, that can be done with {,v}psrad $31
and {,v}psrad $(cst-32) and two operand permutation,
arithmetic >> 32 can be done as {,v}psrad $31 and permutation of that
and the original operand. Arithmetic >> by constant < 32 can be done
as {,v}psrad $cst and {,v}psrlq $cst and two operand permutation.
And arithmetic >> by variable scalar amount can be done as
arithmetic >> 63, logical >> by the amount, << by (64 - amount of the
>> 63 result; note that the vector << 64 result in 0) and oring together.
I had to improve the permutation generation so that it actually handles
the needed permutations (or handles them better).
2021-05-13 Jakub Jelinek
PR tree-optimization/98856
* config/i386/i386.c (ix86_shift_rotate_cost): Add CODE argument.
Expect V2DI and V4DI arithmetic right shifts to be emulated.
(ix86_rtx_costs, ix86_add_stmt_cost): Adjust ix86_shift_rotate_cost
caller.
* config/i386/i386-expand.c (expand_vec_perm_2perm_interleave,
expand_vec_perm_2perm_pblendv): New functions.
(ix86_expand_vec_perm_const_1): Use them.
* config/i386/sse.md (ashr3): Rename to ...
(ashr3): ... this.
(ashr3): New define_expand with VI248_AVX512BW iterator.
(ashrv4di3): New define_expand.
(ashrv2di3): Change condition to TARGET_SSE2, handle !TARGET_XOP
and !TARGET_AVX512VL expansion.
* gcc.target/i386/sse2-psraq-1.c: New test.
* gcc.target/i386/sse4_2-psraq-1.c: New test.
* gcc.target/i386/avx-psraq-1.c: New test.
* gcc.target/i386/avx2-psraq-1.c: New test.
* gcc.target/i386/avx-pr82370.c: Adjust expected number of vpsrad
instructions.
* gcc.target/i386/avx2-pr82370.c: Likewise.
* gcc.target/i386/avx512f-pr82370.c: Likewise.
* gcc.target/i386/avx512bw-pr82370.c: Likewise.
* gcc.dg/torture/vshuf-4.inc: Add two further permutations.
* gcc.dg/torture/vshuf-8.inc: Likewise.
[Bug target/100563] [10/11/12 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:a451598b2c02e1ca3c62fea272d73a9f31922252 commit r12-770-ga451598b2c02e1ca3c62fea272d73a9f31922252 Author: Richard Earnshaw Date: Thu May 13 11:42:58 2021 +0100 arm: correctly handle inequality comparisons against max constants [PR100563] Normally we expect the gimple optimizers to fold away comparisons that are always true, but at some lower optimization levels this is not always the case, so the back-end has to be able to generate correct code in these cases. In this example, we have a comparison of the form (unsigned long long) op <= ~0ULL which, of course is always true. Normally, in the arm back-end we handle these expansions where the immediate cannot be handled directly by adding 1 to the constant and then adjusting the comparison operator: (unsigned long long) op < CONST + 1 but we cannot do that when the constant is already the largest value. Fortunately, we observe that the comparisons we need to handle this way are either always true or always false, so instead of forming a comparison against the maximum value, we can replace it with a comparison against the minimum value (which just happens to also be a constant we can handle. So op1 <= ~0ULL -> op1 >= 0U op1 > ~0ULL -> op1 < 0U op1 <= LONG_LONG_INT_MAX -> op1 >= (-LONG_LONG_INT_MAX - 1) op1 > LONG_LONG_INT_MAX -> op1 < (-LONG_LONG_INT_MAX - 1) gcc: PR target/100563 * config/arm/arm.c (arm_canonicalize_comparison): Correctly canonicalize DImode inequality comparisons against the maximum integral value. gcc/testsuite: * gcc.dg/pr100563.c: New test.
[Bug target/100563] [10/11 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563 Richard Earnshaw changed: What|Removed |Added Summary|[10/11/12 Regression] arm: |[10/11 Regression] arm: ICE |ICE in |in arm_gen_dicompare_reg, |arm_gen_dicompare_reg, at |at config/arm/arm.c:15976 |config/arm/arm.c:15976 | --- Comment #5 from Richard Earnshaw --- Fixed on trunk so far.
[Bug target/100581] [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-731-gb1f7fd8a2a5558da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100581 --- Comment #3 from Uroš Bizjak --- (In reply to Alex Coplan from comment #1) > Is it valid to create a vector type with total size less than the element > size? Shouldn't this be rejected? No, the generated code is: vmovq ff_b(%rip), %xmm0 vmovq ff_a(%rip), %xmm1 vmovq bf(%rip), %xmm2 vcmpltps%xmm1, %xmm0, %xmm1 vmovq af(%rip), %xmm0 vpcmov %xmm1, %xmm2, %xmm0, %xmm0 ret Using vmovq ensures that zero is loaded to the top two elements of xmm reg.
[Bug target/100581] [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-731-gb1f7fd8a2a5558da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100581 --- Comment #4 from Alex Coplan --- When describing the vector_size attribute, https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html says: > Only sizes that are positive power-of-two multiples of the base type size are > currently allowed. Is the documentation out of date?
[Bug ada/100559] build failure of 32-bit Ada runtime after local modification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559 --- Comment #14 from Petr Sumbera --- (In reply to Eric Botcazou from comment #13) > > $ cat gcc-11.1.0/gcc/config/sparc/t-sol2 > > MULTILIB_OPTIONS = m32/m64 > > MULTILIB_DIRNAMES = 32 sparcv9 > > MULTILIB_MATCHES = > > MULTILIB_OSDIRNAMES = . sparcv9 > > So you have a local modification after all, here is the pristine file: > > eric@fomalhaut:~/tmp/gcc-11.1.0> cat gcc/config/sparc/t-sol2 > MULTILIB_OPTIONS = m32/m64 > MULTILIB_DIRNAMES = sparcv8plus sparcv9 > MULTILIB_MATCHES = > MULTILIB_OSDIRNAMES = . sparcv9 > > You need to do s/sparcv8plus/32/ on $(srcdir)/gcc/ada/Makefile.rtl as well. Thank you very much! I'm trying it now. I don't know the history of the change: https://github.com/oracle/solaris-userland/blob/master/components/gcc10/patches/001-multilib-sparc.patch It has following comment: # We want sparc/i386 to match locations for their 32 bit support when building # multilib. For now use the more generic /32. This has not been filed # upstream. I wonder whether it makes sense to have it in upstream?
[Bug ada/100559] build failure of 32-bit Ada runtime after local modification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559 --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #14 from Petr Sumbera --- [...] > It has following comment: > > # We want sparc/i386 to match locations for their 32 bit support when > building > # multilib. For now use the more generic /32. This has not been filed > # upstream. > > I wonder whether it makes sense to have it in upstream? I'd seen that change before in solaris-userland, but never understood the point. Those directories are only used inside the build trees.
[Bug ada/100559] build failure of 32-bit Ada runtime after local modification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559 --- Comment #16 from Petr Sumbera --- (In reply to r...@cebitec.uni-bielefeld.de from comment #15) > > --- Comment #14 from Petr Sumbera --- > [...] > > It has following comment: > > > > # We want sparc/i386 to match locations for their 32 bit support when > > building > > # multilib. For now use the more generic /32. This has not been filed > > # upstream. > > > > I wonder whether it makes sense to have it in upstream? > > I'd seen that change before in solaris-userland, but never understood > the point. Those directories are only used inside the build trees. Ok. I will see if we can remove it for GCC 11.
[Bug target/100581] [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-731-gb1f7fd8a2a5558da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100581 --- Comment #6 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:f1693741cb2b2db519bb82155a3c0880fd820ea3 commit r12-768-gf1693741cb2b2db519bb82155a3c0880fd820ea3 Author: Uros Bizjak Date: Thu May 13 11:09:53 2021 +0200 i386: Fix up V2SFmode vcond* with -mxop [PR100581] ix86_expand_sse_movcc has special TARGET_XOP handling and the recent addition of support of v*cond* patterns for V2SFmode results in ICEs because the expected pattern doesn't exist. We can handle it using 128-bit vpcmov (if we ignore the upper 64 bits like we ignore in other TARGET_MMX_WITH_SSE support). 2021-05-13 Uroš Bizjak gcc/ PR target/100581 * config/i386/i386-expand.c (ix86_expand_sse_movcc): Force mode sizes < 16 to a register when constructing vpcmov pattern. * config/i386/mmx.md (*xop_pcmov_): Use MMXMODE124 mode. gcc/testsuite/ PR target/100581 * g++.target/i386/pr100581.C: New test.
[Bug target/100581] [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-731-gb1f7fd8a2a5558da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100581 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Uroš Bizjak --- Fixed.
[Bug target/98218] [TARGET_MMX_WITH_SSE] Implement 64bit vector compares (AVX512 masked compares missing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218 --- Comment #16 from Uroš Bizjak --- (In reply to David Binderman from comment #15) > Bug first appears sometime between git hash 21dfb22920ce32fc, > dated yesterday and git hash 097fde5e7514e909, dated today. Fixed by PR100581.
[Bug ada/100559] Solaris SPARC GCC 11.1 Ada build: i-cexten.ads:278:28: modulus exceeds limit (2 ** 64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559 --- Comment #12 from Petr Sumbera --- (In reply to Eric Botcazou from comment #11) > Can you post the contents of $(srcdir)/gcc/config/sparc/t-sol2 in your setup? $ cat gcc-11.1.0/gcc/config/sparc/t-sol2 MULTILIB_OPTIONS = m32/m64 MULTILIB_DIRNAMES = 32 sparcv9 MULTILIB_MATCHES = MULTILIB_OSDIRNAMES = . sparcv9
[Bug target/100581] [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-731-gb1f7fd8a2a5558da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100581 --- Comment #5 from Alex Coplan --- Agh, I just remembered that the size is in bytes rather than bits, sorry for the noise.
[Bug ada/100559] build failure of 32-bit Ada runtime after local modification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559 Eric Botcazou changed: What|Removed |Added Build||sparcv9-sun-solaris2.* Target||sparcv9-sun-solaris2.* Resolution|--- |INVALID Status|WAITING |RESOLVED Host||sparcv9-sun-solaris2.* Summary|Solaris SPARC GCC 11.1 Ada |build failure of 32-bit Ada |build: i-cexten.ads:278:28: |runtime after local |modulus exceeds limit (2 ** |modification |64) | --- Comment #13 from Eric Botcazou --- > $ cat gcc-11.1.0/gcc/config/sparc/t-sol2 > MULTILIB_OPTIONS = m32/m64 > MULTILIB_DIRNAMES = 32 sparcv9 > MULTILIB_MATCHES = > MULTILIB_OSDIRNAMES = . sparcv9 So you have a local modification after all, here is the pristine file: eric@fomalhaut:~/tmp/gcc-11.1.0> cat gcc/config/sparc/t-sol2 MULTILIB_OPTIONS = m32/m64 MULTILIB_DIRNAMES = sparcv8plus sparcv9 MULTILIB_MATCHES = MULTILIB_OSDIRNAMES = . sparcv9 You need to do s/sparcv8plus/32/ on $(srcdir)/gcc/ada/Makefile.rtl as well.
[Bug middle-end/100582] New: vectorize failed to generate VEC_COND_EXPR for v32qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100582
Bug ID: 100582
Summary: vectorize failed to generate VEC_COND_EXPR for v32qi
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
https://godbolt.org/z/nfdsGPTxj
cat test.c
v32qi
f2 (v32qi x, v32qi a, v32qi b)
{
v32qi e;
for (int i = 0; i != 32; i++)
e[i] = x[i] ? a[i] : b[i];
return e;
}
clang can generate vplendvb, gcc doesn't vectorize it.
also clang can generate clean vplendvb for f1.
v32qi
f1 (v32qi x, v32qi a, v32qi b)
{
v32qi e;
for (int i = 0; i != 32; i++)
e[i] = x[i] & -128 ? a[i] : b[i];
return e;
}
[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100582 --- Comment #1 from Hongtao.liu --- Also for short, not optimal for int.
[Bug target/100572] arm: Assemble failures with MVE vcreateq intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100572 --- Comment #1 from Alex Coplan --- Hmm, it looks like binutils might be wrong here.
[Bug libstdc++/100583] New: [modules] ICE when importing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100583
Bug ID: 100583
Summary: [modules] ICE when importing
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andreemalcher at gmail dot com
Target Milestone: ---
$ g++ --version
g++ (Ubuntu 11.1.0-1ubuntu1~18.04.1) 11.1.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat span.cpp
import ;
void foo() { std::span s; }
$ g++ -fmodules-ts -std=c++20 -c -x c++-system-header span
$ g++ -fmodules-ts -std=c++20 -c span.cpp
In module /usr/include/c++/11/span, imported at span.cpp:1:
/usr/include/c++/11/span: In instantiation of ‘class std::span’:
span.cpp:4:29: required from here
/usr/include/c++/11/span:155:9: internal compiler error: Segmentation fault
155 | span(_It __first, size_type __count)
| ^~~~
0x1702697 internal_error(char const*, ...)
???:0
0x7bfc52 instantiate_class_template(tree_node*)
???:0
0x7f17ab complete_type(tree_node*)
???:0
0x6af20b start_decl_1(tree_node*, bool)
???:0
0x6c1e0f start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
???:0
0x7888ee c_parse_file()
???:0
0x85988d 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 for instructions.
Even if import is replaced with #include , the sheer presence of
span.gcm leads to an ICE when compiled with -fmodules-ts. The solution is to
use the include and remove the gcm file altogether.But this means that there is
no way of importing as a module.
[Bug c++/100584] New: [modules] ICE when using import ; with std::jthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100584
Bug ID: 100584
Summary: [modules] ICE when using import ; with
std::jthread
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andreemalcher at gmail dot com
Target Milestone: ---
$ cat thread.cpp
import ; // Compiles & runs fine with include or if order if swapped
with next line
#include
int main() {
std::jthread t{[]{}}; // Compiles & runs fine with std::thread
}
$ g++ -fmodules-ts -std=c++20 -c -x c++-system-header iostream$ g++
-fmodules-ts -std=c++20 -o prog thread.cpp -pthread
during IPA pass: visibility
thread.cpp:6:1: internal compiler error: in function_and_variable_visibility,
at ipa-visibility.c:712
6 | }
| ^
0x1702697 internal_error(char const*, ...)
???:0
0x64082b fancy_abort(char const*, int, char const*)
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
If you replace std::jthread with std::thread (optionally, with corresponding
join()), it compiles just fine.
Also, the order of import vs. include seems to matter (see comment in code).
Same ICE for import ;, for example, but not for import ;.
Haven't tried others.
