[Bug fortran/99145] gfortran LOOP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145 --- Comment #4 from Vittorio Zecca --- (In reply to Jerry DeLisle from comment #3) > Initially it is creating the very large string in the frontend passes and > then via resolution and translation phases, and finally into the middle-end > and back end phases where it I am guessing the optimizers are realizing the > simplifications. > > It is a known that some of these special cases are not recognized in the > front end and immediately reduced. In this case it is creating a literal > constant that big. Normally a program would be attempting to use the > parameter in more than one place in which case it is literally substituted > in. > > Should we mark this as invalid? Yes, please.
[Bug fortran/99147] Sanitizer detects heap-use-after-free in gfc_add_flavor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99147 --- Comment #5 from Vittorio Zecca --- I ran the testsuite against the proposed fix and it was successful, no sanitizer errors in symbol.c. Only remaining error as in bug 99148.
[Bug c/99134] S390x: pfpo instructions are not used for dfp[128|64|32] to/from long double conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99134 --- Comment #1 from CVS Commits --- The master branch has been updated by Ilya Leoshkevich : https://gcc.gnu.org/g:b6e446cb58183557a5a5d87dc866aae9613544f8 commit r11-7310-gb6e446cb58183557a5a5d87dc866aae9613544f8 Author: Ilya Leoshkevich Date: Wed Feb 17 14:40:03 2021 +0100 IBM Z: Fix long double <-> DFP conversions When switching the s390 backend to store long doubles in vector registers, the patterns for long double <-> DFP conversions were forgotten. This did not cause observable problems so far, because libdfp calls are emitted instead of pfpo. However, when building libdfp itself, this leads to infinite recursion. gcc/ChangeLog: PR target/99134 * config/s390/vector.md (trunctf2_vr): New pattern. (trunctf2): Likewise. (trunctdtf2_vr): Likewise. (trunctdtf2): Likewise. (extendtf2_vr): Likewise. (extendtf2): Likewise. (extendtftd2_vr): Likewise. (extendtftd2): Likewise. gcc/testsuite/ChangeLog: PR target/99134 * gcc.target/s390/vector/long-double-from-decimal128.c: New test. * gcc.target/s390/vector/long-double-from-decimal32.c: New test. * gcc.target/s390/vector/long-double-from-decimal64.c: New test. * gcc.target/s390/vector/long-double-to-decimal128.c: New test. * gcc.target/s390/vector/long-double-to-decimal32.c: New test. * gcc.target/s390/vector/long-double-to-decimal64.c: New test.
[Bug debug/99178] New: Emit .debug_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178 Bug ID: 99178 Summary: Emit .debug_names Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- DWARF 5 includes a new index section, .debug_names. GCC should emit this with -gdwarf-5
[Bug testsuite/99173] new test case c-c++-common/attr-retain-5.c added in r11-7284 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99173 --- Comment #2 from H.J. Lu --- Created attachment 50228 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50228=edit A patch Try this.
[Bug tree-optimization/98512] [11 Regression] “#pragma GCC diagnostic ignored” ineffective in conjunction with alias attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98512 Martin Sebor changed: What|Removed |Added Target Milestone|11.0|12.0 --- Comment #6 from Martin Sebor --- The fix has been deferred to GCC 12: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565551.html
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Martin Sebor changed: What|Removed |Added Target Milestone|11.0|12.0 --- Comment #32 from Martin Sebor --- The solution in https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html has been deferred to GCC 12: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565551.html
[Bug middle-end/87489] [8/9/10/11 Regression] Spurious -Wnonnull warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489
--- Comment #16 from Martin Sebor ---
The test case in
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565564.html shows that
running the -Wnonnull pass later, after FRE, allows the warning to detect the
bug in the following test case:
class b {
public:
long c();
};
class B {
public:
B() : f() {}
b *f;
};
long d, e;
class g : B {
public:
void h() {
long a = f->c(); <<< -Wnonnull
d = e = a;
}
};
class j {
j();
g i;
};
j::j() { i.h(); }
My response
(https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565590.html) is copied
below:
> Thanks. Yes, the warning would be useful here since the f pointer
> in the call to f->c() is null when i.h() is called from j's ctor.
> The FRE3 pass clearly exposes this :
>
> void j::j (struct j * const this)
> {
>long int _9;
>
> [local count: 1073741824]:
>MEM[(struct B *)this_3(D)] ={v} {CLOBBER};
>MEM[(struct B *)this_3(D)].f = 0B;
>_9 = b::c (0B);
>...
>
> Because the warning runs early (after CCP2), the null pointer is
> not detected. To see it the warning code would have to work quite
> hard to figure out that the two assignments below refer to the same
> location (it would essentially have to do what FRE does):
>
>MEM[(struct B *)this_3(D)].f = 0B;
>_7 = MEM[(struct b * *)_1];
>_9 = b::c (_7);
>
> It's probably too late to make this change for GCC 11 as Jeff has
> already decided that it should be deferred until GCC 12, and even
> then there's a concern that doing so might cause false positives.
> I think it's worth revisiting the idea in GCC 12 to see if
> the concern is founded. Let me make a note of it in the bug.
[Bug c++/99176] [8/9/10/11 Regression] GCC rejects const_cast of null pointer in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99176 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- I'll take a look.
[Bug c++/99176] [8/9/10/11 Regression] GCC rejects const_cast of null pointer in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99176 Marek Polacek changed: What|Removed |Added Summary|GCC rejects const_cast of |[8/9/10/11 Regression] GCC |null pointer in constant|rejects const_cast of null |expressions |pointer in constant ||expressions Last reconfirmed||2021-02-19 Status|UNCONFIRMED |NEW Priority|P3 |P2 Keywords||rejects-valid Target Milestone|--- |9.4 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Thanks for the report. Started with r238909.
[Bug testsuite/99177] New: FAIL: g++.dg/modules/adl-1 -std=c++17 link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99177 Bug ID: 99177 Summary: FAIL: g++.dg/modules/adl-1 -std=c++17 link Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ -B/test/gnu/gcc/objdir/gcc/testsuite/g++/../../ adl-1_a.s adl-1_b.s adl-1_c.s -fdiagnostics-plain-output -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++17 -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -lm -o ./adl-1.exe /usr/ccs/bin/ld: Unsatisfied symbols: _ZGIW5interEv (first referenced in /var/tmp//ccoDSegQ.o) (data) _ZGIW6workerEv (first referenced in /var/tmp//ccovdX7c.o) (data) collect2: error: ld returned 1 exit status compiler exited with status 1 output is: /usr/ccs/bin/ld: Unsatisfied symbols: _ZGIW5interEv (first referenced in /var/tmp//ccoDSegQ.o) (data) _ZGIW6workerEv (first referenced in /var/tmp//ccovdX7c.o) (data) collect2: error: ld returned 1 exit status FAIL: g++.dg/modules/adl-1 -std=c++17 link UNRESOLVED: g++.dg/modules/adl-1 -std=c++17 execute
[Bug c++/99176] New: GCC rejects const_cast of null pointer in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99176 Bug ID: 99176 Summary: GCC rejects const_cast of null pointer in constant expressions Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: richard-gccbugzilla at metafoo dot co.uk Target Milestone: --- GCC rejects: constexpr const int *p = nullptr; constexpr int *q = const_cast(p); saying: :2:20: error: conversion of 'const int*' null pointer to 'int*' is not a constant expression 2 | constexpr int *q = const_cast(p); |^~~ I don't think any such rule exists, and other compilers accept. This only appears to affect const_casts of null pointers; non-null pointer const casts seem to work OK. Perhaps GCC thinks that this is a reinterpret_cast / cast from void* or something like that? It looks like this regressed between GCC 6 and GCC 7.
[Bug testsuite/99175] New: FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99175 Bug ID: 99175 Summary: FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line ) Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ -B/test/gnu/gcc/objdir/gcc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C -fdiagnostics-plain-output -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++17 -pedantic-errors -Wno-long-long -fmodules-ts -fmodule-mapper=|this-will-not-work -S -o bad-mapper-1.s cc1plus: error trying to exec 'this-will-not-work': execvp: No such file or directory /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C: error: failed mapper handshake communication error:Broken pipe /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C:2:1: error: unknown Compiled Module Interface: communication error:Broken pipe In module imported at /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C:2:1: unique1.bob: error: failed to read compiled module: Unknown CMI mapping unique1.bob: note: imports must be built before being imported unique1.bob: fatal error: returning to the gate for a mechanical issue compilation terminated. compiler exited with status 1 output is: cc1plus: error trying to exec 'this-will-not-work': execvp: No such file or directory /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C: error: failed mapper handshake communication error:Broken pipe /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C:2:1: error: unknown Compiled Module Interface: communication error:Broken pipe In module imported at /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C:2:1: unique1.bob: error: failed to read compiled module: Unknown CMI mapping unique1.bob: note: imports must be built before being imported unique1.bob: fatal error: returning to the gate for a mechanical issue compilation terminated. FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line ) FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for excess errors) Excess errors: cc1plus: error trying to exec 'this-will-not-work': execvp: No such file or directory /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C: error: failed mapper handshake communication error:Broken pipe /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-1.C:2:1: error: unknown Compiled Module Interface: communication error:Broken pipe
[Bug testsuite/99173] new test case c-c++-common/attr-retain-5.c added in r11-7284 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99173 --- Comment #1 from seurer at gcc dot gnu.org --- There are actually a bunch more. Here's the full list: FAIL: c-c++-common/attr-retain-5.c -Wc++-compat (test for excess errors) FAIL: c-c++-common/attr-retain-5.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/attr-retain-5.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/attr-retain-5.c -std=gnu++2a (test for excess errors) FAIL: c-c++-common/attr-retain-5.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/attr-retain-6.c -Wc++-compat (test for excess errors) FAIL: c-c++-common/attr-retain-6.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/attr-retain-6.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/attr-retain-6.c -std=gnu++2a (test for excess errors) FAIL: c-c++-common/attr-retain-6.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/attr-retain-7.c -Wc++-compat (test for excess errors) FAIL: c-c++-common/attr-retain-7.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/attr-retain-7.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/attr-retain-7.c -std=gnu++2a (test for excess errors) FAIL: c-c++-common/attr-retain-7.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/attr-retain-8.c -Wc++-compat (test for excess errors) FAIL: c-c++-common/attr-retain-8.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/attr-retain-8.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/attr-retain-8.c -std=gnu++2a (test for excess errors) FAIL: c-c++-common/attr-retain-8.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/attr-retain-9.c -Wc++-compat (test for excess errors) FAIL: c-c++-common/attr-retain-9.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/attr-retain-9.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/attr-retain-9.c -std=gnu++2a (test for excess errors) FAIL: c-c++-common/attr-retain-9.c -std=gnu++98 (test for excess errors)
[Bug c++/99153] [11 Regression] ICE: depset::hash::make_dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99153
--- Comment #2 from Nathan Sidwell ---
// B_a.ii
template
struct pair
{
inline void Frob ();
};
// B_b.ii
import "./B_a.ii"
template
inline void pair<_T1>::Frob()
{ }
./cc1plus -quiet -std=c++20 -fmodule-header -fpreprocessed B_a.ii && ./cc1plus
-quiet -std=c++20 -fmodule-header -fpreprocessed B_b.ii
B_b.ii:1: internal compiler error: in make_dependency, at cp/module.cc:12523
1 | import "./B_a.ii" [[__translated]];
|
0xcd61da depset::hash::make_dependency(tree_node*, depset::entity_kind)
../../../src/gcc/cp/module.cc:12523
0xcd7f54 depset::hash::add_class_entities(vec*)
../../../src/gcc/cp/module.cc:12942
0xce60bb module_state::write(elf_out*, cpp_reader*)
../../../src/gcc/cp/module.cc:17604
The module flags on the TEMPLATE_DECL do not match those of the
DECL_TEMPLATE_RESULT.
[Bug c++/99174] New: [modules] ICE with recursive inclusion of header-unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99174 Bug ID: 99174 Summary: [modules] ICE with recursive inclusion of header-unit Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- self-inclusion considered dangerous // 1_b.ii import "./1_b.ii"; ./cc1plus -quiet -std=c++20 -fmodule-header 1_b.ii 1_b.ii:1:1: internal compiler error: in read_preprocessor, at cp/module.cc:17891 1 | import "./1_b.ii"; | ^~ 0xce6da8 module_state::read_preprocessor(bool) ../../../src/gcc/cp/module.cc:17891 0xceb5db preprocess_module(module_state*, unsigned int, bool, bool, bool, cpp_reader*) ../../../src/gcc/cp/module.cc:19446 0xc73707 module_token_filter::resume(int, int, tree_node*, unsigned int) ../../../src/gcc/cp/lex.c:520 0xc71c69 module_token_lang(int, int, tree_node*, unsigned int, unsigned long) ../../../src/gcc/cp/lex.c:557 0xd26638 cp_lexer_new_main ../../../src/gcc/cp/parser.c:658 0xd90362 c_parse_file() ../../../src/gcc/cp/parser.c:45168 0xf5194e c_common_parse_file() ../../../src/gcc/c-family/c-opts.c:1218
[Bug testsuite/99173] New: new test case c-c++-common/attr-retain-5.c added in r11-7284 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99173 Bug ID: 99173 Summary: new test case c-c++-common/attr-retain-5.c added in r11-7284 fails Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:6347f4a0904fce17eedf5c071be6f3c118680290, r11-7284 make -k check-gcc RUNTESTFLAGS="dg.exp=c-c++-common/attr-retain-5.c" FAIL: c-c++-common/attr-retain-5.c -Wc++-compat (test for excess errors) FAIL: c-c++-common/attr-retain-5.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/attr-retain-5.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/attr-retain-5.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/attr-retain-5.c -std=gnu++2a (test for excess errors) # of unexpected failures1 # of unexpected failures4 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/attr-retain-5.c -fdiagnostics-plain-output -Wc++-compat -Wall -O2 -ffat-lto-objects -fno-ident -S -o attr-retain-5.s /home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/attr-retain-5.c:23:1: warning: 'retain' attribute ignored [-Wattributes] FAIL: c-c++-common/attr-retain-5.c -Wc++-compat (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/attr-retain-5.c:23:1: warning: 'retain' attribute ignored [-Wattributes]
[Bug c/99156] __builtin_expect affects the interpretation of its first operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99156 --- Comment #2 from zhan3299 at purdue dot edu --- (In reply to Martin Liška from comment #1) > Yes, I can confirm the issue. Thanks for the report. Many thanks for your prompt reply. Additionally, I have to give credit to Richard Smith for finding the root cause.
[Bug c++/98741] [modules] ICE/SIGSEGV reading compiled module cluster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98741 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Nathan Sidwell --- 14886cbe300 2021-02-19 | c++: Incorrect module-number ordering [PR 98741]
[Bug c++/98741] [modules] ICE/SIGSEGV reading compiled module cluster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98741 --- Comment #2 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:14886cbe300c144a4390245d0515cdf28fc5f68f commit r11-7307-g14886cbe300c144a4390245d0515cdf28fc5f68f Author: Nathan Sidwell Date: Fri Feb 19 13:10:27 2021 -0800 c++: Incorrect module-number ordering [PR 98741] One of the very strong invariants in modules is that module numbers are allocated such that (other than the current TU), all imports have lesser module numbers, and also that the binding vector is only appended to with increasing module numbers. This broke down when module-directives became a thing and the preprocessing became entirely decoupled from parsing. We'd load header units and their macros (but not symbols of course) during preprocessing. Then we'd load named modules during parsing. This could lead to the situation where a header unit appearing after a named import had a lower module number than the import. Consequently, if they both bound the same identifier, the binding vector would be misorderd and bad things happen. This patch restores a pending import queue I previously had, but in simpler form (hurrah). During preprocessing we queue all module-directives and when we meet one for a header unit we do the minimal loading for all of the queue, so they get appropriate numbering. Then we load the preprocessor state for the header unit. PR c++/98741 gcc/cp/ * module.cc (pending_imports): New. (declare_module): Adjust test condition. (name_pending_imports): New. (preprocess_module): Reimplement using pending_imports. (preprocessed_module): Move name-getting to name_pending_imports. * name-lookup.c (append_imported_binding_slot): Assert module ordering is increasing. gcc/testsuite/ * g++.dg/modules/pr98741_a.H: New. * g++.dg/modules/pr98741_b.H: New. * g++.dg/modules/pr98741_c.C: New. * g++.dg/modules/pr98741_d.C: New.
[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169 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 #5 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-February/055741.html
[Bug libstdc++/99172] New: Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 Bug ID: 99172 Summary: Build failure with slibtool and vtv Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-user at riseup dot net Target Milestone: --- Created attachment 50227 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50227=edit Full build log. When building gcc with slibtool (https://dev.midipix.org/cross/slibtool) the build will fail in the libstdc++.la make target in libstdc++-v3/src. /usr/x86_64-pc-linux-gnu/bin/ld: cannot find -lvtv This doesn't occur with GNU libtool because it silently filters out the invalid -lvtv while slibtool does not. I attached a full build log. Also see this gentoo issue. https://bugs.gentoo.org/767706 To build gcc with slibtool: export MAKE='make LIBTOOL=rdlibtool' Unfortunately gcc doesn't respect the value of the MAKEFLAGS environment variable.
[Bug fortran/98686] Namelist group objects shall be defined before appearing in namelist for -std=f2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98686 --- Comment #6 from CVS Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:dfa2f821c18b7e926b5f5d6e394a0c915937db5e commit r11-7306-gdfa2f821c18b7e926b5f5d6e394a0c915937db5e Author: Jerry DeLisle Date: Fri Feb 19 12:47:54 2021 -0800 fortran: Object types should be declared before use in NAMELIST. gcc/fortran/ChangeLog: PR fortran/98686 * match.c (gfc_match_namelist): If BT_UNKNOWN, check for IMPLICIT NONE and and issue an error, otherwise set the type to its IMPLICIT type so that any subsequent use of objects will will confirm their types. gcc/testsuite/ChangeLog: PR fortran/98686 * gfortran.dg/namelist_4.f90: Modify. * gfortran.dg/namelist_98.f90: New test.
[Bug fortran/99171] New: [10 Regression] Optional procedure call inside Open MP parallel loop produces Segmentation Fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99171 Bug ID: 99171 Summary: [10 Regression] Optional procedure call inside Open MP parallel loop produces Segmentation Fault Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: am41119 at hotmail dot com Target Milestone: --- Created attachment 50226 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50226=edit Output of using -save-temps during compilation When calling a passed optional procedure inside an Open MP parallel loop (even with OMP_NUM_THREADS=1) the address of the optional procedure is no longer set to the actual passed procedure. Because the address of the optional procedure is no longer correct we get a Segmentation Fault when calling it. The below program works on GCC9 and below. main.f90: --- program gcc10_omp_optional_bug implicit none call function_calling_optionals(print_something) call function_calling_optionals_in_omp(print_something) contains subroutine optional_function_template() implicit none end subroutine subroutine print_something() implicit none print *, "Printing Something" end subroutine print_something subroutine function_calling_optionals(optional_function) implicit none procedure(optional_function_template), optional :: optional_function print *, "When optional function is called without Open MP directive:" if (present(optional_function)) then call optional_function() end if end subroutine function_calling_optionals subroutine function_calling_optionals_in_omp(optional_function) implicit none procedure(optional_function_template), optional :: optional_function print *, "When optional function is called inside Open MP directive:" !$omp parallel if (present(optional_function)) then call optional_function() end if !$omp end parallel end subroutine function_calling_optionals_in_omp end program gcc10_omp_optional_bug - gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.2.0-5ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --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 --enable-libphobos-checking=release --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-10-WJNXnb/gcc-10-10.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-WJNXnb/gcc-10-10.2.0/debian/tmp-gcn/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 Supported LTO compression algorithms: zlib zstd gcc version 10.2.0 (Ubuntu 10.2.0-5ubuntu1~20.04) Compile Command: gfortran main.f90 -fopenmp -o main Execution output: When optional function is called without Open MP directive: Printing Something When optional function is called inside Open MP directive: Program received signal SIGILL: Illegal instruction. Program received signal SIGILL: Illegal instruction. Program received signal SIGILL: Illegal instruction. Backtrace for this error: Program received signal SIGILL: Illegal instruction. Backtrace for this error: Backtrace for this error: Backtrace for this error: Program received signal SIGILL: Illegal instruction. Backtrace for this error: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Program received signal SIGILL: Illegal instruction. Backtrace for this error: Program received signal SIGILL: Illegal instruction. Backtrace for this error: #0 0x7f9e60dd1d01 in ??? #0 0x7f9e60dd1d01 in ??? #0 0x7f9e60dd1d01 in ??? #1 0x7f9e60dd0ed5 in ??? #2 0x7f9e60bc320f in ??? #3 0x7f9e5e993e27 in ??? Illegal instruction (core dumped)
[Bug target/97366] [8/9/10/11 Regression] Redundant load with SSE/AVX vector intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97366 --- Comment #8 from Vladimir Makarov --- I've tried different approaches to fix it. The best patch I have now is in the attachment. Unfortunately, the best patch results in two new failures on ppc64 (other patches are even worse): gcc.target/powerpc/dform-3.c scan-assembler-not mfvsrd gcc.target/powerpc/dform-3.c scan-assembler-not mfvsrld I'll think more how to avoid these 2 failures. If I succeed, I'll submit a patch. But there is probability that the PR will not be fixed at all.
[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #4 from anlauf at gcc dot gnu.org ---
The following code in trans-expr.c was added by Thomas, so adding him in CC:
else if (add_clobber && expr->ref == NULL)
{
tree clobber;
tree var;
/* FIXME: This fails if var is passed by reference, see PR
41453. */
var = expr->symtree->n.sym->backend_decl;
clobber = build_clobber (TREE_TYPE (var));
gfc_add_modify (>pre, var, clobber);
}
[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 seurer at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #15 from seurer at gcc dot gnu.org --- It still fails on gcc 10, though
[Bug target/97366] [8/9/10/11 Regression] Redundant load with SSE/AVX vector intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97366 --- Comment #7 from Vladimir Makarov --- Created attachment 50225 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50225=edit A candidate patch
[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169
--- Comment #3 from anlauf at gcc dot gnu.org ---
A conservative solution simply disables the clobber:
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 103cb31c664..ce7bfaa89e8 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6082,6 +6084,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
/* FIXME - PR 87395 and PR 41453 */
&& e->symtree->n.sym->attr.save == SAVE_NONE
&& !e->symtree->n.sym->attr.associate_var
+ && !e->symtree->n.sym->attr.allocatable
&& e->ts.type != BT_CHARACTER && e->ts.type !=
BT_DERIVED
&& e->ts.type != BT_CLASS && !sym->attr.elemental;
This should result only in a missed optimization.
Is there a way to get sth. like:
*i = {CLOBBER};
so that we do not clobber the pointer but the pointer to?
[Bug c++/99170] [modules] ICE in get_merge_kind with std::string NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99170 --- Comment #1 from Rémi Galan Alfonso --- Created attachment 50224 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50224=edit preprocessed file ... And with the correct preprocessed file this time, apologies for my mistake.
[Bug c++/99170] New: [modules] ICE in get_merge_kind with std::string NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99170
Bug ID: 99170
Summary: [modules] ICE in get_merge_kind with std::string NSDMI
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: remi.galanalfonso at gmail dot com
Target Milestone: ---
Created attachment 50223
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50223=edit
preprocessed file
Hello, I ran into the following ICE when testing modules a bit, it doesn't look
like any currently open module bug (reproduced here with a recent trunk, commit
f86e187e12d).
The reproducer is as follows:
$ cat test_modules.cpp
export module test;
import ;
export class A {
std::string str{"ayyy"};
};
The header unit was compiled with the following:
$ g++ -std=c++20 -fmodules-ts -x c++-system-header string
And the command line used and result are the following (along with -v for
information):
$ g++ -v -save-temps -std=c++20 -fmodules-ts -c test_modules.cpp
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/remi/Projects/gcc/build-install
--disable-multilib : (reconfigured) ./configure
--prefix=/home/remi/Projects/gcc/build-install --disable-multilib :
(reconfigured) ./configure --prefix=/home/remi/Projects/gcc/build-install
--disable-multilib CC=gcc-9 CXX=g++-9 --enable-languages=c,c++,fortran,lto,objc
--no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210219 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-fmodules-ts' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/home/remi/Projects/gcc/build-install/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1plus
-E -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE test_modules.cpp
-mtune=generic -march=x86-64 -std=c++20 -fmodules-ts -fpch-preprocess -o
test_modules.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/home/remi/Projects/gcc/build-install/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/remi/Projects/gcc/build-install/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0
/home/remi/Projects/gcc/build-install/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/x86_64-pc-linux-gnu
/home/remi/Projects/gcc/build-install/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward
/home/remi/Projects/gcc/build-install/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include
/usr/local/include
/home/remi/Projects/gcc/build-install/include
/home/remi/Projects/gcc/build-install/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-fmodules-ts' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/home/remi/Projects/gcc/build-install/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1plus
-fpreprocessed test_modules.ii -quiet -dumpbase test_modules.cpp -dumpbase-ext
.cpp -mtune=generic -march=x86-64 -std=c++20 -version -fmodules-ts -o
test_modules.s
GNU C++20 (GCC) version 11.0.0 20210219 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20210218 (experimental), GMP version
6.2.1, MPFR version 4.1.0, MPC version 1.2.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++20 (GCC) version 11.0.0 20210219 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20210218 (experimental), GMP version
6.2.1, MPFR version 4.1.0, MPC version 1.2.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 8e9853a7486525ef35ca23365b38ea4d
test_modules.cpp:1:9: internal compiler error: in get_merge_kind, at
cp/module.cc:10158
1 | export module test;
| ^~
0x699387 trees_out::get_merge_kind(tree_node*, depset*)
../.././gcc/cp/module.cc:10158
0xa13f63 trees_out::decl_value(tree_node*, depset*)
../.././gcc/cp/module.cc:7618
0xa14ebb trees_out::decl_node(tree_node*, walk_kind)
../.././gcc/cp/module.cc:8613
0xa15eb2 trees_out::tree_node(tree_node*)
../.././gcc/cp/module.cc:9168
0xa1b813 module_state::write_pendings(elf_out*, vec,
depset::hash&, unsigned int, unsigned int*)
../.././gcc/cp/module.cc:15403
0xa1d050 module_state::write(elf_out*, cpp_reader*)
../.././gcc/cp/module.cc:17748
0xa1d71c finish_module_processing(cpp_reader*)
../.././gcc/cp/module.cc:19787
0x9b170b c_parse_final_cleanups()
../.././gcc/cp/decl2.c:5175
Please submit a full bug report,
with preprocessed source if appropriat
[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169
--- Comment #2 from anlauf at gcc dot gnu.org ---
Note/workaround: the {CLOBBER} disappears if the argument to set_i is declared
INOUT instead of OUT.
[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to work||8.4.1
Priority|P3 |P4
Summary|Segfault when passing |[9/10/11 Regression]
|allocatable scalar into |Segfault when passing
|intent(out) dummy argument |allocatable scalar into
||intent(out) dummy argument
Ever confirmed|0 |1
Target Milestone|--- |9.4
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Known to fail||10.2.1, 11.0, 9.3.1
Last reconfirmed||2021-02-19
CC||anlauf at gcc dot gnu.org
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
The tree dump shows that since at least 9.3.1 we clobber the pointer:
integer(kind=4) * i;
...
i = (integer(kind=4) *) __builtin_malloc (4);
...
i = {CLOBBER};
set_i (i);
[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 Peter Bergner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Peter Bergner --- (In reply to seurer from comment #13) > Thanks, that did fix it on trunk. Marking as fixed then. Thanks Vlad!
[Bug fortran/99147] Sanitizer detects heap-use-after-free in gfc_add_flavor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99147 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:af027826292351218785f893d1c42fe28ae3ed9f commit r11-7303-gaf027826292351218785f893d1c42fe28ae3ed9f Author: Harald Anlauf Date: Fri Feb 19 20:21:27 2021 +0100 PR fortran/99147 - Sanitizer detects heap-use-after-free in gfc_add_flavor Reverse order of conditions to avoid invalid read. gcc/fortran/ChangeLog: * symbol.c (gfc_add_flavor): Reverse order of conditions.
[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172 --- Comment #29 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:3599ecb6a0145a428def5314d2d67d2e5a88f3c4 commit r11-7301-g3599ecb6a0145a428def5314d2d67d2e5a88f3c4 Author: Martin Sebor Date: Fri Feb 19 11:06:06 2021 -0700 PR c/97172 - ICE: tree code 'ssa_name' is not supported in LTO streams gcc/ChangeLog: PR c/97172 * attribs.c (init_attr_rdwr_indices): Guard vblist use. (attr_access::free_lang_data): Remove a spurious test. gcc/testsuite/ChangeLog: PR c/97172 * gcc.dg/pr97172.c: Add test cases.
[Bug tree-optimization/99159] missing -Wnonull on member access through null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99159
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC||msebor at gcc dot gnu.org
Severity|normal |enhancement
Last reconfirmed||2021-02-19
Summary|Confusing -Warray-bounds|missing -Wnonull on member
|warning |access through null
Ever confirmed|0 |1
Blocks||95507
--- Comment #2 from Martin Sebor ---
To expand on what Andrew said in comment #1: The code in test2() is undefined
because it dereferences a null pointer. It's diagnosed by -Warray-bounds and
(with it disabled) by -Wstringop-overread, both of which expect objects to be
allocated at valid addresses.
-Wnonnull would arguably be a better warning to issue for this case but it
doesn't have the same logic as the other two. In addition, and by the time
-Wnonnull runs, the null pointer has already been replaced by the non-null
address of the member:
void test2 ()
{
struct s2 * p;
struct s2 * pb.0_2;
struct s1 * _3;
:
pb.0_2 = pb;
_3 = _2->y;
__builtin_memcpy (_3, 4B, 12);
return;
}
Issuing -Wnonull here would mean either running the warning earlier (which runs
the risk of issuing more false positives) or also assuming that objects don't
live at constant addresses.
The code test1() is "conditionally undefined" (it's defined when f is zero) and
isn't diagnosed only because -Wnonnull doesn't handle conditionals (PHI nodes).
A simple test case that shows the limitation is:
void f (void)
{
char *q = 0;
__builtin_puts (q); // -Wnonnull
}
void g (char *p)
{
char *q = *p ? p : 0;
__builtin_puts (q); // -Wnonnull
}
I can confirm this as an enhancement request for -Wnonull to diagnose both
problem(s). That should automatically disable any subsequent warnings for the
same bug.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507
[Bug 95507] [meta-bug] bogus/missing -Wnonnull
[Bug c++/99166] [modules] Unable to determine where CMI is being found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99166 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Nathan Sidwell --- bfe83ae38e8 2021-02-19 | c++: Inform of CMI reads [PR 99166]
[Bug fortran/99169] New: Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169 Bug ID: 99169 Summary: Segfault when passing allocatable scalar into intent(out) dummy argument Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- Created attachment 50222 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50222=edit Minimal working example I've encountered a problem when passing an allocatable (and alread allocated) scalar as an actual argument to a procedure with an intent(out) (but not allocatable) dummy argument. The attached code illustrates the problem. Compiling with gfortran 10.2.0 at optimization level -O1 or -O2 leads to a segmentation fault at runtime. The segfault arises when the dummy is assigned within set_i(). This problem does not arise at optimization level -O0, and the program performs as expected (outputting '5' to the terminal). The problem also seems to disappear when set_i() is a CONTAINed procedure in the main program, rather than a module procedure. cheers, Rich
[Bug fortran/98890] ICE on reference to module function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98890 --- Comment #6 from Jerry DeLisle --- I should have noted in the above case, if we remove the parens on line 5, k = f1 is rejected.
[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210 Jozef Lawrynowicz changed: What|Removed |Added Resolution|--- |WONTFIX Status|REOPENED|RESOLVED --- Comment #10 from Jozef Lawrynowicz --- I think its best to close this as WONTFIX. GCC will only erroneously enable SHF_GNU_RETAIN support if a Binutils version between: > commit 99fabbc9739a87ba3433e66792e93b773896790e > Author: Jozef Lawrynowicz > Date: Wed Nov 18 11:51:13 2020 + > >Support SHF_GNU_RETAIN ELF section flag and > commit ff4bc37d77a0ca7286883a477adcb3aa145fc782 > Author: Cary Coutant > Date: Mon Dec 14 15:46:47 2020 -0800 > > Keep input SHF_GNU_RETAIN sections and strip output SHF_GNU_RETAIN for > GNU/FreBSD ELFOSABIs. is being used. There's no Binutils release in this range.
[Bug fortran/99146] ICE in gfc_find_specific_dtio_proc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99146 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- FIXED on mainline (GCC 11). Thanks for the report!
[Bug fortran/99010] [11 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2322 since r11-7054-ge3f9f80bfa9e58a9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99010 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tobias Burnus --- FIXED. Thanks for the report!
[Bug fortran/99010] [11 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2322 since r11-7054-ge3f9f80bfa9e58a9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99010 --- Comment #2 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:f86e187e12db14ad1cced26b9f8aafb06498e208 commit r11-7299-gf86e187e12db14ad1cced26b9f8aafb06498e208 Author: Tobias Burnus Date: Fri Feb 19 18:07:26 2021 +0100 Fortran: Fix coarray handling for gfc_dep_resolver [PR99010] Check failed if identical = false was requested or for -fcoarray=single if an array ref was for a coindexed scalar. gcc/fortran/ChangeLog: PR fortran/99010 * dependency.c (gfc_dep_resolver): Fix coarray handling. gcc/testsuite/ChangeLog: PR fortran/99010 * gfortran.dg/coarray/array_temporary-1.f90: New test.
[Bug fortran/99146] ICE in gfc_find_specific_dtio_proc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99146 --- Comment #1 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:72d91d6cd41f2987339a98c2c64f70b3850f4e0b commit r11-7298-g72d91d6cd41f2987339a98c2c64f70b3850f4e0b Author: Tobias Burnus Date: Fri Feb 19 18:05:31 2021 +0100 Fortran: Fix DTIO with type ICE [PR99146] gcc/fortran/ChangeLog: PR fortran/99146 * interface.c: gcc/testsuite/ChangeLog: PR fortran/99146 * gfortran.dg/dtio_36.f90: New test.
[Bug web/98875] DWARF5 as default causes perf probe to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875 --- Comment #5 from Mark Wielaard --- https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565587.html
[Bug tree-optimization/91191] vrp and boolean arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191 --- Comment #8 from Andrew Macleod --- (In reply to Jeffrey A. Law from comment #7) > If you're V_C_E-ing to a narrower type, you just ignore the bits outside the > target type, it's a lot like a narrowing subreg in the RTL world. > > I don't know what the semantics are for the widening case. ISTM that it's > not really helpful there. > But isn't that the case here? _6 = VIEW_CONVERT_EXPR(b_4(D)); if (_6 > 1) goto ; [INV] else goto ; [INV] we are widening the single bit BOOL into an 8 bit unsigned char... so we need to decide if the other bits are always 0 or what
[Bug c/99168] inconsistent behavior on -O0 and -O2 with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168 --- Comment #1 from zhan3299 at purdue dot edu --- If we resolved the conflicts on "aligned", it would behave normally. I feel like the ASAN is confused by the "aligned" somehow. Should it have thrown some warnings?
[Bug fortran/98890] ICE on reference to module function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98890 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- (In reply to Tobias Burnus from comment #4) > Related issue but without an ICE: > >contains > integer function f1() > !f2 = 1 ! gives an error as expected > j = f2! accepted; cast of function addr to integer(kind=4) > f1 = 1! ↑ ifort: 'already been used as an external function name' > end function > integer function f2() > f2=1 > end function >end A variation with a question: program p1 implicit none integer j, k j = 99 k = f1() print *, j, k contains integer function f1() !f2 = 1 j = f2 ! Should this be warned or rejected? print *, j f1 = 1 ! This should not be rejected end function integer function f2() f2=1 end function end
[Bug c/99168] New: inconsistent behavior on -O0 and -O2 with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168
Bug ID: 99168
Summary: inconsistent behavior on -O0 and -O2 with ASAN on
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
I am not sure whether the following problem is caused by ASAN or O2.
Following code has different behaviors between "-fsanitize=address -O0" and
"-fsanitize=address -O2"
It affects my local 7.5.0, 10.2.0, and 11.0.0 on godbolt.
O0 (succ): https://godbolt.org/z/zMKP6K
O1 (succ): https://godbolt.org/z/Yf3oP7
O2 (fail): https://godbolt.org/z/erahvc
O3 (fail): https://godbolt.org/z/7zaqaf
Os (fail): https://godbolt.org/z/38e6xc
-
$ cat test.c
#include
struct my_struct {
unsigned long volatile x;
} __attribute__((aligned(128)));
static int k[5][6] = {};
static struct my_struct s1 = {0UL};
static struct my_struct s2 __attribute__((aligned(32))) = {0UL};
int main() {
int i, j;
for (i = 0; i < 5; i++) {
for (j = 0; j < 6; j++) {
printf("%d\n", k[i][j]);
}
}
printf("%lu\n", s1.x);
printf("%lu\n", s2.x);
return 0;
}
$ gcc test.c -Wall -fsanitize=address -O0 -o g0.out
# no any warning or error
$ gcc test.c -Wall -fsanitize=address -O2 -o g2.out
# no any warning or error
$ ./g0.out
... # normal output
$ ./g2.out
=
==26165==ERROR: AddressSanitizer: global-buffer-overflow on address
0x55a5cf268184 at pc 0x55a5cf267201 bp 0x7ffd23b80f60 sp 0x7ffd23b80f50
READ of size 4 at 0x55a5cf268184 thread T0
#0 0x55a5cf267200 in main
(/root/docker_share/csmith/gcc_self_10/g2.out+0x1200)
#1 0x7efea78c10b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#2 0x55a5cf26726d in _start
(/root/docker_share/csmith/gcc_self_10/g2.out+0x126d)
0x55a5cf268184 is located 4 bytes inside of global variable 'k' defined in
'test.c:7:12' (0x55a5cf268180) of size 120
0x55a5cf268184 is located 4 bytes to the right of global variable 's2' defined
in 'test.c:11:25' (0x55a5cf268100) of size 128
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/docker_share/csmith/gcc_self_10/g2.out+0x1200) in main
Shadow bytes around the buggy address:
0x0ab539e44fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab539e44ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab539e45000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab539e45010: 04 f9 f9 f9 f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9
0x0ab539e45020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ab539e45030:[f9]f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 f9
0x0ab539e45040: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab539e45050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab539e45060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab539e45070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab539e45080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
Shadow gap: cc
[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 --- Comment #13 from seurer at gcc dot gnu.org --- Thanks, that did fix it on trunk.
[Bug translation/99167] typo in params.opt: accesse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99167 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Liška --- Fixed.
[Bug translation/99167] typo in params.opt: accesse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99167 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:c8d13835638ff82f3ba7bfb0a5c2f597851dfb5a commit r11-7297-gc8d13835638ff82f3ba7bfb0a5c2f597851dfb5a Author: Martin Liska Date: Fri Feb 19 17:29:23 2021 +0100 Fix typo in param description. gcc/ChangeLog: PR translation/99167 * params.opt: Fix typo.
[Bug translation/99167] typo in params.opt: accesse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99167 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-02-19 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- I'll fix it.
[Bug fortran/99145] gfortran LOOP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145 --- Comment #3 from Jerry DeLisle --- Initially it is creating the very large string in the frontend passes and then via resolution and translation phases, and finally into the middle-end and back end phases where it I am guessing the optimizers are realizing the simplifications. It is a known that some of these special cases are not recognized in the front end and immediately reduced. In this case it is creating a literal constant that big. Normally a program would be attempting to use the parameter in more than one place in which case it is literally substituted in. Should we mark this as invalid?
[Bug translation/99167] New: typo in params.opt: accesse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99167 Bug ID: 99167 Summary: typo in params.opt: accesse Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- > Maximum number of accesse stored in each modref reference. Should be 'accesses'.
[Bug fortran/98890] ICE on reference to module function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98890 --- Comment #4 from Tobias Burnus --- Related issue but without an ICE: contains integer function f1() !f2 = 1 ! gives an error as expected j = f2! accepted; cast of function addr to integer(kind=4) f1 = 1! ↑ ifort: 'already been used as an external function name' end function integer function f2() f2=1 end function end
[Bug libgcc/99157] [ARM] libgcc -mcmse check always fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157
--- Comment #3 from Hau Hsu ---
Here are some more info.
This check determines whether macro __ARM_FEATURE_CMSE is set to 3,
and affects CMSE support for function cmse_check_address_range():
void *
__attribute__ ((warn_unused_result))
cmse_check_address_range (void *p, size_t size, int flags)
{
...
#if __ARM_FEATURE_CMSE & 2
case CMSE_MPU_NONSECURE:
permb = cmse_TTA (pb);
perme = singleCheck ? permb : cmse_TTA (pe);
break;
case CMSE_MPU_UNPRIV | CMSE_MPU_NONSECURE:
permb = cmse_TTAT (pb);
perme = singleCheck ? permb : cmse_TTAT (pe);
break;
#endif
...
}
Since the check always fail, CMSE support for all multilibs are disabled.
The objdump results of v8-m.main libgcc for gcc-arm-none-eabi-7-2018-q2-update
and gcc-arm-none-eabi-10-2020-q4-major are attached.
[Bug web/98875] DWARF5 as default causes perf probe to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mark at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-19 Component|debug |web --- Comment #4 from Mark Wielaard --- (In reply to Paul Clarke from comment #3) > The IBM Advance Toolchain supports SLES 15, where the latest version of > libdw is 0.168. We'll work around the issue by reverting the commit for the > version of GCC included with the Advance Toolchain. Yes, that is probably reasonable when targetting a distro that is so old that it doesn't have any tooling to support DWARF5. Still you might want to request that the perf tool be fixed to simply skip the DWARF5 data instead of going into an infinite loop. That bug could trigger for any DWARF that old perf/libdw doesn't know about and it really should just skip it. The fix for that really is just a oneliner. > I didn't see any update to the GCC documentation regarding the disruptive > nature of the change causing the problem other than "[DWARF] Version 5 > requires GDB 8.0 or higher". > > Should there be something about libdw as well? Anything else? You are right. I'll submit an update for the GCC 11 Release Notes to document things.
[Bug libgcc/99157] [ARM] libgcc -mcmse check always fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157 --- Comment #2 from Hau Hsu --- Created attachment 50221 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50221=edit libgcc objdump result for gcc-7 and gcc-10
[Bug fortran/99147] Sanitizer detects heap-use-after-free in gfc_add_flavor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99147 --- Comment #3 from Vittorio Zecca --- I changed symbol.c as per your suggestion and now the address sanitized gfortran compiles fine. Now I am going to check it against the testsuite. Results tomorow.
[Bug tree-optimization/99165] ICE in verify_dominators, at dominance.c:1184 since r11-7205-g95d94b52ea847833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99165 Martin Liška changed: What|Removed |Added Summary|[11 Regression] ICE in |ICE in verify_dominators, |verify_dominators, at |at dominance.c:1184 since |dominance.c:1184 since |r11-7205-g95d94b52ea847833 |r11-7205-g95d94b52ea847833 | --- Comment #2 from Martin Liška --- (In reply to Jakub Jelinek from comment #1) > Is that really a regression given you need an option that didn't exist > before? No, sorry.
[Bug tree-optimization/99165] [11 Regression] ICE in verify_dominators, at dominance.c:1184 since r11-7205-g95d94b52ea847833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99165 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Is that really a regression given you need an option that didn't exist before?
[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98389 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The demangler does the right, although confusing thing. Because the Itanium ABI says that g is __float128: ::= f # float ::= d # double ::= e # long double, __float80 ::= g # __float128
[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98389 --- Comment #3 from Jonathan Wakely --- (In reply to seurer from comment #0) > 3 incompatible symbols > 0 > _ZSt8to_charsPcS_g > std::to_chars(char*, char*, __float128) It took me a while to realise that these symbols are not __float128, they're __ibm128, but the demangler turns 'g' into __float128. Is that still the case for the latest version of the demangler? Because that's very confusing. The actual __float128 type mangles as '__u9__ieee128' not 'g', so if I define "std::to_chars(char*, char*, __float128)" in my code, it doesn't get mangled as shown above.
[Bug c/99156] __builtin_expect affects the interpretation of its first operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99156 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-02-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Yes, I can confirm the issue. Thanks for the report.
[Bug c/99137] ICE in gimplify_scan_omp_clauses, at gimplify.c:9833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99137 --- Comment #5 from Tobias Burnus --- Iff it is decided that it is invalid code, the following patch rejects it: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565576.html (I forgot to reload the PR before posting.)
[Bug c++/98967] warning to spot recursive include graph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98967 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org --- Comment #2 from Nathan Sidwell --- discussing with clang guys, Richard wondered whether we'd make this the default (eventually?). to do that, would require a smarter implementation that explicitly pushed and popped the line table (or an appropriate action with include translate). That'd also make it work for #import and #pragma once.
[Bug go/99164] gccgo internal compiler error: alias receiver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99164 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Ian Lance Taylor --- Thanks. This is already fixed by https://golang.org/cl/291991.
[Bug tree-optimization/98357] Bounds check not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98357 Andrew Macleod changed: What|Removed |Added CC||aldyh at redhat dot com, ||amacleod at redhat dot com --- Comment #3 from Andrew Macleod --- We should be able to handle this in GCC 12 . The WIP relation support in ranger currently is showing: : _1 = i_6(D) < len_7(D); _2 = i_6(D) >= j_8(D); _3 = _1 & _2; if (_3 != 0) goto ; [INV] else goto ; [INV] === BB 3 len_7(D)size_t [1, +INF] j_8(D) size_t VARYING Relational : (i_6(D) >= j_8(D)) Relational : (i_6(D) < len_7(D)) : if (len_7(D) > j_8(D)) goto ; [INV] else goto ; [INV] So once I get the transitive queries of relations working, we should be able to recognize len_7 > i_6 >= j_8 and then the condition will fold trivially eliminating the call to exit().
[Bug c++/99166] New: [modules] Unable to determine where CMI is being found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99166 Bug ID: 99166 Summary: [modules] Unable to determine where CMI is being found Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- If a CMI file is not found one gets a diagnostic saying where it was looking. For include translation -flang-info-include-translate and friends are there to inform. But there is no information when the compiler reads a found CMI, which can be confusing to build system debugging. Add -flang-info-module-cmi and friends in a similar vein to the include-translate informs
[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98389 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug tree-optimization/99165] [11 Regression] ICE in verify_dominators, at dominance.c:1184 since r11-7205-g95d94b52ea847833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99165 Martin Liška changed: What|Removed |Added Target Milestone|--- |11.0 Known to work||10.2.0 Last reconfirmed||2021-02-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to fail||11.0 Priority|P3 |P1
[Bug tree-optimization/99165] New: [11 Regression] ICE in verify_dominators, at dominance.c:1184 since r11-7205-g95d94b52ea847833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99165
Bug ID: 99165
Summary: [11 Regression] ICE in verify_dominators, at
dominance.c:1184 since r11-7205-g95d94b52ea847833
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat new.C
struct A {
A() : i() {}
int i;
} *ap2 = new A[3];
$ g++ new.C --param=max-stores-to-track=2 -O2 -fnon-call-exceptions
struct A {
A() : i() {}
int i;
} *ap2 = new A[3];
new.C: In function ‘(static initializers for new.C)’:
new.C:4:18: error: dominator of 10 status unknown
4 | } *ap2 = new A[3];
| ^
new.C:4:18: error: dominator of 11 status unknown
new.C:4:18: error: dominator of 12 should be 11, not 5
during GIMPLE pass: store-merging
new.C:4:18: internal compiler error: in verify_dominators, at dominance.c:1184
0x76f16a verify_dominators(cdi_direction)
/home/marxin/Programming/gcc/gcc/dominance.c:1184
0xd3ab17 checking_verify_dominators
/home/marxin/Programming/gcc/gcc/dominance.h:76
0xd3ab17 calculate_dominance_info(cdi_direction)
/home/marxin/Programming/gcc/gcc/dominance.c:746
0x1393f5d verify_ssa(bool, bool)
/home/marxin/Programming/gcc/gcc/tree-ssa.c:1108
0x10851c8 execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:2049
0x10857ec do_per_function
/home/marxin/Programming/gcc/gcc/passes.c:1687
0x10857ec execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/99163] Odd error message when using `main` with -pedantic-errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99163 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-19 Keywords||diagnostic Ever confirmed|0 |1 Severity|normal |minor --- Comment #1 from Jonathan Wakely --- Yes, the diagnostic could be more accurate.
[Bug c++/99162] problem when compile with O2 or O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99162 --- Comment #2 from Jonathan Wakely --- (In reply to Zhang Haibin from comment #0) > $ g++ --version > g++ (GCC) 4.9.2 This compiler is ancient and we're not interested in bug reports for it. If you use a modern compiler you can use -fsanitize=undefined to find bugs like this integer overflow problem.
[Bug go/99164] New: gccgo internal compiler error: alias receiver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99164
Bug ID: 99164
Summary: gccgo internal compiler error: alias receiver
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: zoltan.halassy at gmail dot com
CC: cmang at google dot com
Target Milestone: ---
gccgo 10.2.1 cannot handle the case when a package defines a method using a
type alias. This is not a problem for `gc`.
Minimal testcase:
$ cat repro.go
package repro
type S struct{}
type TA = S
// SomeMethod is defined using a type alias
func (TA) SomeMethod() {}
$ cat main.go
package main
import "repro"
func main() {
repro.S{}.SomeMethod()
}
gccgo can create repro.o without showing any errors, but causes an internal
compiler error when trying to build main:
Output of the first command:
$ gccgo -v -save-temps -Wall -Wextra -c repro.go
Using built-in specs.
COLLECT_GCC=gccgo
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6+build1'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --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-10-H1Aw7q/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-H1Aw7q/gcc-10-10.2.1/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6+build1)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-c' '-o' 'repro.o'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/10/go1 repro.go -quiet -dumpbase repro.go
-mtune=generic -march=x86-64 -auxbase-strip repro.o -Wall -Wextra -version
-L/usr/lib/gcc/x86_64-linux-gnu/10
-L/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/10/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/10/../../.. -o repro.s
GNU Go (Debian 10.2.1-6+build1) version 10.2.1 20210110 (x86_64-linux-gnu)
compiled by GNU C version 10.2.1 20210110, GMP version 6.2.1, MPFR
version 4.1.0, MPC version 1.2.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Go (Debian 10.2.1-6+build1) version 10.2.1 20210110 (x86_64-linux-gnu)
compiled by GNU C version 10.2.1 20210110, GMP version 6.2.1, MPFR
version 4.1.0, MPC version 1.2.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-c' '-o' 'repro.o'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
as -v --64 -o repro.o repro.s
GNU assembler version 2.35.1 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.35.1
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/10/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/10/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-c' '-o' 'repro.o'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
The command above succeeds (status 0), and creates repro.o but the next command
fails:
$ gccgo -v -save-temps -Wall -Wextra -o main repro.o main.go
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6+build1'
[Bug c++/99162] problem when compile with O2 or O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99162 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Signed integer overflow is undefined behavior. Abs of most negative signed integer is undefined because there is no way to represent the positive value so it causes an overflow.
[Bug c++/99153] [11 Regression] ICE: tree check: expected binding_vector, have overload in maybe_record_mergeable_decl, at cp/name-lookup.c:3562
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99153 --- Comment #1 from Nathan Sidwell --- I think this is a duplicate of 99071, which hadn't been done when Mattias tested. However, I am getting a different ICE: devvm1702:235>./xg++ -B./ -nostdinc++ -I../x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I../x86_64-pc-linux-gnu/libstdc++-v3/include -I../../..//src/libstdc++-v3/libsupc++ -I../../../src/libstdc++-v3/include/backward -I../../../src/libstdc++-v3/testsuite/util -std=c++20 -fmodules-ts -x c++-system-header iostream devvm1702:236>./xg++ -B./ -nostdinc++ -I../x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I../x86_64-pc-linux-gnu/libstdc++-v3/include -I../../..//src/libstdc++-v3/libsupc++ -I../../../src/libstdc++-v3/include/backward -I../../../src/libstdc++-v3/testsuite/util -std=c++20 -fmodules-ts -x c++-system-header utility devvm1702:237>./xg++ -B./ -nostdinc++ -I../x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I../x86_64-pc-linux-gnu/libstdc++-v3/include -I../../..//src/libstdc++-v3/libsupc++ -I../../../src/libstdc++-v3/include/backward -I../../../src/libstdc++-v3/testsuite/util -std=c++20 -fmodules-ts -x c++-system-header algorithm ../x86_64-pc-linux-gnu/libstdc++-v3/include/algorithm: internal compiler error: in make_dependency, at cp/module.cc:12514 0xd06a9a depset::hash::make_dependency(tree_node*, depset::entity_kind) ../../../src/gcc/cp/module.cc:12514 0xd07ae1 depset::hash::add_dependency(tree_node*, depset::entity_kind) ../../../src/gcc/cp/module.cc:12712 0xcf24e0 trees_out::decl_node(tree_node*, walk_kind) ../../../src/gcc/cp/module.cc:8605 0xcf4a73 trees_out::tree_node(tree_node*) ../../../src/gcc/cp/module.cc:9168 0xce2700 trees_out::vec_chained_decls(tree_node*) ../../../src/gcc/cp/module.cc:4981 0xd02052 trees_out::write_class_def(tree_node*) ../../../src/gcc/cp/module.cc:11737 which does appear to be new.
[Bug ipa/99122] [10/11 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #22 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:1a2a7096e5e20d736c6138179470b21aa5a74864 commit r11-7296-g1a2a7096e5e20d736c6138179470b21aa5a74864 Author: Richard Biener Date: Fri Feb 19 09:38:52 2021 +0100 middle-end/99122 - more VLA inlining fixes This avoids declaring a function with VLA arguments or return values as inlineable. IPA CP still ICEs, so the testcase has that disabled. 2021-02-19 Richard Biener PR middle-end/99122 * tree-inline.c (inline_forbidden_p): Do not inline functions with VLA arguments or return value. * gcc.dg/pr99122-3.c: New testcase.
[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210 --- Comment #9 from Jozef Lawrynowicz --- I believe this PR only relates to the fact that GCC support for SHF_GNU_RETAIN was available before GOLD supported that section flag. My proposed patch was to turn off GCC support for SHF_GNU_RETAIN if an unsupported GOLD is detected. I think at this point, the GOLD functionality was only broken for such a narrow period of time in development (not corresponding to a concrete version of Binutils), there's no point adding a configure test to try and catch that now. (In reply to Jakub Jelinek from comment #8) > Isn't this problem gone with > r11-7284-g6347f4a0904fce17eedf5c071be6f3c118680290 ? > I mean, attribute used now means what it used to mean before, and retain > attribute is not used in whatever is emitted into .init_array section at > least in existing code. Yes, one might use it in user code, but the answer > can be don't do it then. And yes, since none of the libraries using the "used" attribute will implicitly create SHF_GNU_RETAIN sections any more, even if you used the Binutils version with broken GOLD, it won't cause any problems.
[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726 --- Comment #8 from avieira at gcc dot gnu.org --- Also at some point we should figure out why the vectorizer is generating this much code for this example, where I think it should be able to optimized it to: a = 22; b &= c;
[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
--- Comment #7 from avieira at gcc dot gnu.org ---
I'm looking at this and I have a feeling there is a disconnect on how some
passes define VECTOR_CST and how the expand pass handles it.
So the problem here seems to lie with the V4SImode VECTOR_CST at expand time:
{ POLY_INT_CST [24, 16], POLY_INT_CST [25, 16], POLY_INT_CST [26, 16],
POLY_INT_CST [27, 16] }
The problem seems to be that const_vector_from_tree only adds the first
VECTOR_CST_NPATTERNS * VECTOR_CST_NELTS_PER_PATTERN and this has:
VECTOR_CST_NPATTERNS: 1
VECTOR_CST_NELTS_PER_PATTERN: 3
The mode however dictates 4 elements (constant-sized V4SImode). So
rtx_vector_builder::build adds the first three and then tries to derive the
fourth (even though it is right there), at this point it fails as it uses
wi::sub and that doesn't seem to work for POLY_INT's.
This is where I started investigating how it should work. I looked at cases of
actual patterns involving POLY_INT's, like:
{ POLY_INT_CST [8, 8], POLY_INT_CST [9, 8], POLY_INT_CST [10, 8], ... }
These have a VLA mode, so because there is no constant element number
rtx_vector_builder::build uses the 'encoded_nelts' which are again the
VECTOR_CST_NPATTERNS * VECTOR_CST_NELTS_PER_PATTERN elements and never needs to
derive a step.
I also looked at how a VECTOR_CST with N random integers is built and there it
seems VECTOR_CST_NPATTERNS * VECTOR_CST_NELTS_PER_PATTERN describe the full
length of the VECTOR_CST.
At this point I don't know whether the construction of the VECTOR_CST is wrong,
or whether the building is, I just know there seems to be a disconnect.
There are a variety of things that we could do:
1) Change how the VECTOR_CST is being created so that VECTOR_CST_NPATTERNS *
VECTOR_CST_NELTS_PER_PATTERN == GET_MODE_NUNITS (m_mode).is_constant ()
for constant sized modes.
2) Change const_vector_from_tree to check whether a POLY_INT VECTOR_CST has a
constant sized mode, construct the RTVEC_ELT itself and use
rtx_vector_builder::build(rtvec v)
3) Teach rtx_vector_builder::step and apply_step how to deal with POLY_INT's
Out of all 2 is my favourite. Though we should aim to look at 1 too. Because I
have seen a big descrepancy in how these VECTOR_CST's are formed, I've also
seen:
{1, 1, 1, 1, 1, 1, 1, 1} being described using:
VECTOR_CST_NPATTERNS: 1
VECTOR_CST_NELTS_PER_PATTERN: 3
Which is unnecessary... {1, ...} would have sufficed with both NPATTERNS and
NELTS_PER_PATTERN set to 1 for instance, or make it so they multiply to 8.
Unless we want this flexibility?
[Bug c++/99163] New: Odd error message when using `main` with -pedantic-errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99163
Bug ID: 99163
Summary: Odd error message when using `main` with
-pedantic-errors
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int main()
{
main();
}
With -pedantic-errors, this results in this error message:
error: ISO C++ forbids taking address of function ‘::main’ [-Wpedantic]
As far as I am aware, function calls can be done without the function type
decaying to a function pointer type, so this isn't even pedantically accurate.
I believe GCC instead should give an error message alike to "error: ISO C++
forbids usage of main within a program" or something similar, instead of the
currently at least somewhat confusing error message (which had me convinced for
a few minutes that C++ implicitly decayed function types to function pointer
types before calling them until I checked the standard).
[Bug c++/99162] New: problem when compile with O2 or O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99162
Bug ID: 99162
Summary: problem when compile with O2 or O3
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haibin-zhang at 263 dot net
Target Milestone: ---
$ g++ --version
g++ (GCC) 4.9.2
Copyright (C) 2014 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 a.C
#include
#include
void f(int n) {
unsigned int u = abs(n);
while(true) {
if(u < 10) {
printf("u = %u\n", u);
break;
}
printf("u = %u\n", u);
u /= 10;
}
}
main() {
f(0x8000);
}
02 or 03 can not work
$ g++ a.C -O2
$ ./a.out
u = 2147483648
O1 no problem
$ g++ a.C -O1
$ ./a.out
u = 2147483648
u = 214748364
u = 21474836
u = 2147483
u = 214748
u = 21474
u = 2147
u = 214
u = 21
u = 2
[Bug target/98998] [11 Regression] ICE in change_address_1, at emit-rtl.c:2275 since r11-3427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98998 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Should be fixed now.
[Bug target/98998] [11 Regression] ICE in change_address_1, at emit-rtl.c:2275 since r11-3427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98998 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1a132c4d7cdb22cbab85b8596418daa2c3157812 commit r11-7295-g1a132c4d7cdb22cbab85b8596418daa2c3157812 Author: Jakub Jelinek Date: Fri Feb 19 13:05:47 2021 +0100 arm: Fix ICE with -fstack-protector -mpure-code [PR98998] The vla15.C testcase ICEs with -mcpu=cortex-m1 -mpure-code -fstack-protector -mthumb as what force_const_mem returns (a SYMBOL_REF) is not a valid memory address. Previously the code was moving the address of the force_const_mem into a register rather than the content of that MEM, so that instruction must have been supported and loading from a MEM with a single REG base ought to be valid too. 2021-02-19 Jakub Jelinek PR target/98998 * config/arm/arm.md (*stack_protect_combined_set_insn, *stack_protect_combined_test_insn): If force_const_mem result is not valid general operand, force its address into the destination register first. * gcc.target/arm/pure-code/pr98998.c: New test.
[Bug c++/99158] Better error message when missing #include and using placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99158 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|[Enhancement] Better error |Better error message when |message when missing|missing #include and |#include and using |using placement new |placement new | Ever confirmed|0 |1 Last reconfirmed||2021-02-19 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- Confirmed. We should offer a fix-it hint as we do for other missing headers.
[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Isn't this problem gone with r11-7284-g6347f4a0904fce17eedf5c071be6f3c118680290 ? I mean, attribute used now means what it used to mean before, and retain attribute is not used in whatever is emitted into .init_array section at least in existing code. Yes, one might use it in user code, but the answer can be don't do it then.
[Bug ipa/99034] [9/10 Regression] error: EH landing pad label is not first in a sequence of labels in bb 6during GIMPLE pass: einline since r9-6254-gf86624d85f937e03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99034 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression] error: |[9/10 Regression] error: EH |EH landing pad label|landing pad label is |is not first in a sequence |not first in a sequence of |of labels in bb 6during |labels in bb 6during GIMPLE |GIMPLE pass: einline since |pass: einline since |r9-6254-gf86624d85f937e03 |r9-6254-gf86624d85f937e03 --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug ipa/99034] [9/10/11 Regression] error: EH landing pad label is not first in a sequence of labels in bb 6during GIMPLE pass: einline since r9-6254-gf86624d85f937e03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99034 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:37bde2f87267908a93c07856317a28827f8284f7 commit r11-7294-g37bde2f87267908a93c07856317a28827f8284f7 Author: Jakub Jelinek Date: Fri Feb 19 12:14:39 2021 +0100 tree-cfg: Fix up gimple_merge_blocks FORCED_LABEL handling [PR99034] The verifiers require that DECL_NONLOCAL or EH_LANDING_PAD_NR labels are always the first label if there is more than one label. When merging blocks, we don't honor that though. On the following testcase, we try to merge blocks: [count: 0]: : S::~S (); and [count: 0]: : resx 1 where is landing pad and is FORCED_LABEL. And the code puts the FORCED_LABEL before the landing pad label, violating the verification requirements. The following patch fixes it by moving the FORCED_LABEL after the DECL_NONLOCAL or EH_LANDING_PAD_NR label if it is the first label. 2021-02-19 Jakub Jelinek PR ipa/99034 * tree-cfg.c (gimple_merge_blocks): If bb a starts with eh landing pad or non-local label, put FORCED_LABELs from bb b after that label rather than before it. * g++.dg/opt/pr99034.C: New test.
[Bug libstdc++/97549] [11 Regression] include/pstl rebase breaking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97549
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
After rpm -e tbb-devel , I can reproduce.
The following fixes it for me.
In GCC 10, parallel_backend.h just included parallel_backend_{serial,tbb}.h and
did nothing beyond that, and parallel_backend_tbb.h provided directly
namespace __pstl { namespace __par_backend { ... } }
and defined everything in there, while parallel_backend_serial.h did:
namespace __pstl { namespace __serial { ... } } and had this
namespace __pstl { namespace __par_backend { using namespace __pstl::__serial;
} }
at the end.
in GCC 11, parallel_backend.h does:
namespace __pstl { namespace __par_backend = __serial_backend; }
after including parallel_backend_serial.h or
namespace __pstl { namespace __par_backend = __tbb_backend; }
after including parallel_backend_tbb.h. The latter then has:
namespace __pstl { namespace __tbb_backend { ... } }
and no using etc. at the end, while parallel_backend_serial.h changed to:
namespace __pstl { namespace __serial_backend { ... } }
but has this leftover block from the GCC 10 times. Even changing that
using namespace __pstl::__serial;
to
using namespace __pstl::__serial_backend;
doesn't work, as it clashes with
namespace __pstl { namespace __par_backend = __serial_backend; }
in parallel_backend.h.
2021-02-19 Jakub Jelinek
* include/pstl/parallel_backend_serial.h: Remove
__pstl::__par_backend.
--- libstdc++-v3/include/pstl/parallel_backend_serial.h.jj 2020-10-21
19:33:24.059872401 +0200
+++ libstdc++-v3/include/pstl/parallel_backend_serial.h 2021-02-19
11:59:56.414645219 +0100
@@ -127,12 +127,4 @@ __parallel_invoke(_ExecutionPolicy&&, _F
} // namespace __serial_backend
} // namespace __pstl
-namespace __pstl
-{
-namespace __par_backend
-{
-using namespace __pstl::__serial;
-}
-} // namespace __pstl
-
#endif /* _PSTL_PARALLEL_BACKEND_SERIAL_H */
[Bug ipa/99122] [10/11 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #21 from rguenther at suse dot de --- On Fri, 19 Feb 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 > > --- Comment #20 from Jakub Jelinek --- > I think you don't want variably_modified_type_p, that returns true even for > pointers to VLAs (and references etc., perhaps many times indirectly). Ah, indeed. But then you want !poly_int_tree_p to not disallow SVE vector types.
[Bug ipa/99122] [10/11 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #20 from Jakub Jelinek --- I think you don't want variably_modified_type_p, that returns true even for pointers to VLAs (and references etc., perhaps many times indirectly). I think those should be fine, they are used fairly often unlike variable length structures, and so we'd run into issues before.
[Bug ipa/99122] [10/11 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #19 from Martin Jambor ---
(In reply to Richard Biener from comment #17)
> there's variably_modified_type_p (you can pass NULL_TREE for the fndecl)
> which is more to the point. Otherwise it looks reasonable. Does IPA CP
> do things like IPA SRA and split aggregates?
No, it does not split them, the only SRAish thing it does is simple
removal of unused register-type parameters.
> I wonder in which cases IPA CP would derive "constants" for
> aggregates, so why are aggregate parameters even tracked?
I am not sure I understand the question. The testcase in comment #12
attempts to pass a simple double constant to what is actually a VLA
structure, causing an ICE on undefined behavior input, which is the
main thing I want to avoid.
But I have just realized that if we now insist that we know all types
anyway - I have run the whole C testsuite and did not find any K
testcase where IPA-CP would consider a parameter for propagation when
not knowing its type - we can do something better and only propagate
when we know that force_value_to_type would not resort to building a
zero constructor.
This will allow to still propagate ("aggregate") constants within VLAs
like if there was one in b.n in the testcase (and the caller was
somewhat saner).
> I am testing the following for the inline issue for the last testcase,
> leaving the IPA CP one to you.
Sure, thanks.
[Bug target/99161] New: Suboptimal SVE code for ld4/st4 MLA code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99161
Bug ID: 99161
Summary: Suboptimal SVE code for ld4/st4 MLA code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
void ld_st_4 (char *x)
{
for (int i = 0; i < 4096; i += 4)
{
char r = x[i];
char g = x[i + 1];
char b = x[i + 2];
char a = x[i + 3];
char smoosh = (r + g + b) * a;
x[i] = r - smoosh;
x[i+1] = g + smoosh;
x[i+2] = b - smoosh;
x[i+3] = a + smoosh;
}
}
with -O3 (no SVE) gives a nice loop on aarch64:
ld_st_4(char*):
add x1, x0, 4096
.L2:
ld4 {v0.16b - v3.16b}, [x0]
add v4.16b, v0.16b, v1.16b
add v4.16b, v4.16b, v2.16b
mul v4.16b, v4.16b, v3.16b
sub v16.16b, v0.16b, v4.16b
add v17.16b, v4.16b, v1.16b
sub v18.16b, v2.16b, v4.16b
add v19.16b, v4.16b, v3.16b
st4 {v16.16b - v19.16b}, [x0], 64
cmp x1, x0
bne .L2
ret
with -O3 -march=armv8.2-a+sve we get:
ld_st_4(char*):
mov x1, 0
mov w2, 1024
ptrue p0.b, all
whilelo p1.b, wzr, w2
.L2:
ld4b{z0.b - z3.b}, p1/z, [x0]
add z4.b, z1.b, z0.b
add z4.b, z4.b, z2.b
movprfx z16, z0
mls z16.b, p0/m, z4.b, z3.b
movprfx z17, z1
mla z17.b, p0/m, z4.b, z3.b
movprfx z18, z2
mls z18.b, p0/m, z4.b, z3.b
movprfx z19, z3
mla z19.b, p0/m, z4.b, z3.b
st4b{z16.b - z19.b}, p1, [x0]
incbx1
incbx0, all, mul #4
whilelo p1.b, w1, w2
b.any .L2
ret
There's a few things that could be improved here:
* Use x0 for limit
* Use a single predicate (avoid multiple incb instructions)
* factor in the cost of movprfx somehow (i.e. the destructive semantics of the
MLA/MLS), and prefer to use mul and add/sub
A better SVE loop would look a lot like Neon:
ld_st_4(char*):
add x1, x0, 4096
ptrue p0.b, all
.L2:
ld4b{z0.b - z3.b}, p0/z, [x0]
add z4.b, z1.b, z0.b
add z4.b, z4.b, z2.b
mul z4.b, p0/m, z4.b, z3.b
sub z16.b, z0.b, z4.b
add z17.b, z4.b, z1.b
sub z18.b, z2.b, z4.b
add z19.b, z4.b, z3.b
st4b{z16.b - z19.b}, p0, [x0]
incbx0, all, mul #4
cmp x1, x0
bne .L2
ret
[Bug fortran/99111] [10/11 Regression] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7336
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99111 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Tobias Burnus --- FIXED on mainline (GCC 11) and on the GCC 10 branch. Thanks for the report!
[Bug c++/99160] New: A wrong accessible check when using a using-declaration that introduces the names of type and function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99160
Bug ID: 99160
Summary: A wrong accessible check when using a
using-declaration that introduces the names of type
and function
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xmh970252187 at gmail dot com
Target Milestone: ---
cpp
#include
struct A{
struct C{
using type = int;
};
void C(){} //#1 if comment out this function definition, GCC will compile
// this example
};
struct B:private A{
using A::C;
};
int main(){
B::C::type c; //#2
}
For this example, GCC will report an error, which says "'struct A::C' is
inaccessible within this context". The result of this example is
https://godbolt.org/z/ddfrPM. If we comment out `void C(){}`, GCC will compile
the example.
According to [namespace.udecl]#19.
> A synonym created by a using-declaration has the usual accessibility for a
> member-declaration.
That means the name `C` is accessible in the nested-name-specifier at #2(the
name would be found in the scope of `B` in which the using-declaration will
create the synonym name for that name, the created name has the same
accessibility as the member-declaration)
Clang can compile this example even if we do not comment out the function
definition at #1
[Bug libgcc/99157] [ARM] libgcc -mcmse check always fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157 kratenko changed: What|Removed |Added CC||gcc-bugzilla at garstig dot org --- Comment #1 from kratenko --- Some cross links to this issue: Original stackoverflow question: https://stackoverflow.com/q/66240436/1358283 Question to arm embedded toolchain: https://answers.launchpad.net/gcc-arm-embedded/+question/695596
[Bug fortran/99111] [10/11 Regression] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7336
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99111 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:0f225e57427fd8ca1cdc63b6c2f3001493987474 commit r10-9375-g0f225e57427fd8ca1cdc63b6c2f3001493987474 Author: Tobias Burnus Date: Tue Feb 16 14:17:35 2021 +0100 Fortran: Reject DT as fmt in I/O statments [PR99111] gcc/fortran/ChangeLog: PR fortran/99111 * io.c (resolve_tag_format): Reject BT_DERIVED/CLASS/VOID as (array-valued) FORMAT tag. gcc/testsuite/ChangeLog: PR fortran/99111 * gfortran.dg/fmt_nonchar_1.f90: New test. * gfortran.dg/fmt_nonchar_2.f90: New test. (cherry picked from commit ebf9b6c13f0847ddcc22e540a5fcdbf644e85a9c)
