[Bug other/101711] Error when gcc cross compile libvtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101711 --- Comment #1 from bootmgr at 163 dot com --- Created attachment 51234 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51234=edit config.log
[Bug other/101711] New: Error when gcc cross compile libvtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101711 Bug ID: 101711 Summary: Error when gcc cross compile libvtv Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bootmgr at 163 dot com Target Milestone: --- Created attachment 51233 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51233=edit output
[Bug c++/101710] Sometimes constexpr cannot be used as constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101710 steve02081504 changed: What|Removed |Added Attachment #51231|0 |1 is obsolete|| --- Comment #1 from steve02081504 --- Created attachment 51232 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51232=edit .ii file & .s file & output
[Bug c++/101710] New: Sometimes constexpr cannot be used as constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101710 Bug ID: 101710 Summary: Sometimes constexpr cannot be used as constexpr Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: steve_green at qq dot com Target Milestone: --- Created attachment 51231 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51231=edit .ii file & .s file & output I want to make a minimal reproduction of this ICE, but it seems I can't So allow me to post a link to the project, sorry You can try to compile this file https://github.com/ELC-lang/ELC/blob/master/parts/header_file/test/forICE.cpp In MSVC, the compilation of this file will stop due to some ICE, but it is different from ICEs that GCC have The problem with GCC is that all "error: expected primary-expression before ‘X’ token" can be compiled in MSVC
[Bug libstdc++/101709] [12 Regression] Yesterday's patch on std::filesystem breaks windows target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101709 Andrew Pinski changed: What|Removed |Added Summary|Yesterday's patch on|[12 Regression] Yesterday's |std::filesystem breaks |patch on std::filesystem |windows target |breaks windows target Target Milestone|--- |12.0 Keywords||build
[Bug tree-optimization/101708] Suboptimal codegen when clearing struct fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101708 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-08-01 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed, what is happening in the reset1 is the GIMPLE store merging pass is able to do the merging while in the other cases it does not.
[Bug tree-optimization/101708] Suboptimal codegen when clearing struct fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101708 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/96496] Conversion to enum with underlying type bool produces wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96496
--- Comment #3 from Andrew Pinski ---
Confirmed (again with a compile time test):
enum E : bool { One, Two };
constexpr int f1 (int x) { return (E) x; }
static_assert(f1(6), "");
static_assert(f1(7), "");
[Bug c++/95004] using the wrong pointer to member for base classes with two bases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95004
Andrew Pinski changed:
What|Removed |Added
Summary|Static array of base|using the wrong pointer to
|classes member pointers |member for base classes
||with two bases
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-08-01
Known to fail||6.4.0
--- Comment #2 from Andrew Pinski ---
Confirmed. To show it is not a problem with templates and just pointer to
members and not using aliases either.
Take:
struct base {
int value1;
};
struct base0 {
int value;
};
struct derived: base0, base {
typedef int derived::* pointer_type ;
static constexpr pointer_type m = ::value;
static constexpr pointer_type m1 = ::value1;
};
static_assert(derived::m == ::value,"");
static_assert(derived::m != ::value1,"");
static_assert(derived::m1 != ::value,"");
static_assert(derived::m1 == ::value1,"");
Basically the conversion from "int derived::*" to "int *base::" (or "int
*base0") is going wrong.
[Bug libstdc++/101709] New: Yesterday's patch on std::filesystem breaks windows target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101709 Bug ID: 101709 Summary: Yesterday's patch on std::filesystem breaks windows target Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Created attachment 51230 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51230=edit error message Since yesterday's patch https://github.com/gcc-mirror/gcc/commit/3dbd4d94bf380f3efa8bba9b203ce7d4c8f47fbb#diff-ba6ba5a2bddd4d1cf66ef3699e6111d9c6aa1cf0192c97e6d59a048b4a851b91 ec is removed, so the code cannot compile targetting windows anymore
[Bug rtl-optimization/101708] New: Suboptimal codegen when clearing struct fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101708
Bug ID: 101708
Summary: Suboptimal codegen when clearing struct fields
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cafxx+gcc.gnu.org at strayorange dot com
Target Milestone: ---
GCC trunk (as well as 11.2) currently seem to be performing suboptimal codegen
in reset2 and reset3, that in theory should yield the same (or very similar to
the) result of reset1:
struct example {
unsigned a;
unsigned char b;
unsigned c:1;
unsigned d:2;
unsigned char f;
unsigned char g;
unsigned e;
};
void reset1(struct example *e) {
e->b = 0,
e->d = 0,
e->e = 0,
e->f = 0,
e->g = 0;
}
void reset2(struct example *e) {
*e = (struct example) {
.a = e->a,
.c = e->c
};
}
void reset3(struct example *e) {
struct example tmp = {
.a = e->a,
.c = e->c
};
*e = tmp;
}
compiled with -O2 -Wall yields:
reset1:
and QWORD PTR [rdi+4], 63744
ret
reset2:
movzx eax, BYTE PTR [rdi+5]
mov edx, DWORD PTR [rdi]
mov DWORD PTR [rdi+8], 0
mov QWORD PTR [rdi], 0
and eax, 1
mov DWORD PTR [rdi], edx
mov BYTE PTR [rdi+5], al
ret
reset3:
mov QWORD PTR [rsp-8], 0
mov eax, DWORD PTR [rdi]
mov DWORD PTR [rsp-12], eax
movzx eax, BYTE PTR [rdi+5]
and eax, 1
mov BYTE PTR [rsp-7], al
mov rax, QWORD PTR [rsp-12]
mov QWORD PTR [rdi], rax
mov eax, DWORD PTR [rsp-4]
mov DWORD PTR [rdi+8], eax
ret
Godbolt link: https://godbolt.org/z/asr57TWqq
Bug reported at the request of @gnutools:
https://twitter.com/gnutools/status/1421525698515251207
I tentatively selected rtl-optimization as the component, but I'm not familiar
at all with the internals of GCC: feel free to update as needed.
[Bug c++/99804] cannot convert bit field enum to its own type in a template member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99804 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-07-31 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=95009 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/87547] G++ reports bad type names for bit-field members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87547 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Andrew Pinski --- Fixed so closing as such.
[Bug c++/78908] [6/7 Regression] template instantiation with bit-field type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78908 Andrew Pinski changed: What|Removed |Added CC||gnubugzilla@martin-kaesberg ||er.de --- Comment #12 from Andrew Pinski --- *** Bug 71586 has been marked as a duplicate of this bug. ***
[Bug c++/71586] type confusion when bitfields are accessed from templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71586 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Keywords||rejects-valid Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 78908. *** This bug has been marked as a duplicate of bug 78908 ***
[Bug c++/16582] Wrong diagnostic when using "[1]" as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16582 --- Comment #4 from Andrew Pinski --- C++11/C++14/C++98 gives: :8:13: error: template argument 2 is invalid 8 | X x3; // ERROR | ^ While C++17 gives: :8:8: error: '& p[0]' is not a valid template argument of type 'char*' because 'p[0]' is not a variable 8 | X x3; // ERROR |^ And C++20 accepts the code. Note clang accepts the code for C++17 and C++20.
[Bug c++/49931] valid code rejected (named operator)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49931 Andrew Pinski changed: What|Removed |Added Known to fail||7.5.0, 8.2.0 Known to work||8.3.0 Target Milestone|--- |8.3 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Fixed in GCC 8.3+. 8 branch fix: r8-8705 trunk fix: r9-4161
[Bug c++/86825] g++.old-deja/g++.pt/ptrmem10.C test fails on windows targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86825 --- Comment #2 from Andrew Pinski --- I think this is testsuite issue as -fms-extensions is enabled by default on mingw.
[Bug c++/79832] [C++14/17] result of subscripting non lvalue array should be xvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79832 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |9.0 Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- DR1213 was fixed in GCC 9+ by the following two revisions: r9-595 r9-711 And the two testcases here work for GCC 9+ so closing as fixed.
[Bug bootstrap/84257] Extremely slow compilation from gcc source code under macOS 10.13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84257 --- Comment #9 from Iain Sandoe --- (In reply to Eric Gallager from comment #8) > the MacPorts project applies the following patch to work around this issue: > https://github.com/macports/macports-ports/commit/ > 0641e588e989b7b3e5049ca79e354339ccb403ca Well, that disables the use of DYLD_LIBRARY_PATH, but does not provide a replacement (i.e. it's a workaround only). --- I have patches that resolve this by using @rpath for libraries on macOS versions that support it - and switch off the use of DYLD_LIBRARY_PATH there (which isn't acted on). This solution also restores the ability to test the compiler without first installing it. The patches are on trial branches (they are needed on the arm64 port) - and AFAIK the build problems with a couple of packages were resolved. It remains to tidy them up for application / posting as needed.
[Bug c++/85415] internal compiler error: in finish_member_declaration, at cp/semantics.c:2984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85415 --- Comment #2 from Andrew Pinski --- Seems fixed in GCC 9+.
[Bug c++/79802] Conflicting declaration with function pointers/types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79802 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |8.0 Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Fixed in GCC 8+.
[Bug c++/61245] #pragma GCC ivdep is ignored with call inside the test of a for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61245 Andrew Pinski changed: What|Removed |Added CC||fwinter at jlab dot org --- Comment #6 from Andrew Pinski --- *** Bug 79047 has been marked as a duplicate of this bug. ***
[Bug c++/79047] loop annotation ignored in templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79047 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 61245. *** This bug has been marked as a duplicate of bug 61245 ***
[Bug bootstrap/84257] Extremely slow compilation from gcc source code under macOS 10.13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84257 --- Comment #8 from Eric Gallager --- the MacPorts project applies the following patch to work around this issue: https://github.com/macports/macports-ports/commit/0641e588e989b7b3e5049ca79e354339ccb403ca
[Bug c++/83796] [7 Regression] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83796 Andrew Pinski changed: What|Removed |Added CC||pravasimeet999 at yahoo dot com --- Comment #9 from Andrew Pinski --- *** Bug 70939 has been marked as a duplicate of this bug. ***
[Bug c++/70939] creating object of abstract class allowed in all versions of g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70939 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 83796, Fixed in GCC 8+. *** This bug has been marked as a duplicate of bug 83796 ***
[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372 Andrew Pinski changed: What|Removed |Added CC||kaballo86 at hotmail dot com --- Comment #18 from Andrew Pinski --- *** Bug 61736 has been marked as a duplicate of this bug. ***
[Bug c++/61736] Conditional expression yields wrong value category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61736 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 64372. Fixed in GCC 10+. *** This bug has been marked as a duplicate of bug 64372 ***
[Bug c++/64519] variadic template as the first argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64519 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- .
[Bug c++/64519] variadic template as the first argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64519 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.4 --- Comment #1 from Andrew Pinski --- Fixed in GCC 8.4, 9.3 and 10+.
[Bug c++/77437] recipe for target 'cp/cp-array-notation.o' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77437 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Andrew Pinski --- The log message just says: Makefile:1058: recipe for target 'cp/cp-array-notation.o' failed but no other error message which means I suspecting it was a HW issue. Also nobody else ran into this issue so I highly doubt it was a bug in GCC.
[Bug c++/82336] [6 Regression] GCC requires but does not emit defaulted constructors in certain cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82336 Andrew Pinski changed: What|Removed |Added CC||steveire at gmail dot com --- Comment #10 from Andrew Pinski --- *** Bug 70636 has been marked as a duplicate of this bug. ***
[Bug c++/70636] Link failure when C++ brace initialization is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70636 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 82336 which is fixed in GCC 7+ *** This bug has been marked as a duplicate of bug 82336 ***
[Bug c++/65615] gcc says abstract class even though it isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65615 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #1 from Andrew Pinski --- Fixed in GCC 7+. I suspect by r7-3590 .
[Bug c++/53878] [C++11] Abstract class constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53878 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Fixed in GCC 7+. I suspect by r7-3590 . pr66443-cxx14-3.C testcase looks like this case.
[Bug c++/64615] Access level check error: g++ thinks the non default ctor is protected while its public
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64615 --- Comment #3 from Andrew Pinski --- clang rejects this code with a similar error message as gcc.
[Bug c++/64615] Access level check error: g++ thinks the non default ctor is protected while its public
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64615 Andrew Pinski changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever confirmed|1 |0
[Bug c++/67332] [C++11] g++ rejects expansion of multiple parameter packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67332
--- Comment #1 from Andrew Pinski ---
clang rejects it:
:9:5: error: no matching function for call to 'foo'
foo (Typelist(), Typelist(), 2.5, 1);
^~~
:5:6: note: candidate template ignored: deduced packs of different
lengths for parameter 'InvokableArgs' ( vs. <>)
void foo (Typelist, Typelist, InvokableArgs&&...,
Rest&&...) { }
^
[Bug c++/67397] GCC incorrectly accepts non-type template parameter pack expansion of a parameter pack declared in the same template-parameter-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67397 --- Comment #2 from Andrew Pinski --- ICC 2021.3.0 rejects it. MSVC 19.14+, clang trunk and GCC trunk all accept it
[Bug c++/67397] GCC incorrectly accepts non-type template parameter pack expansion of a parameter pack declared in the same template-parameter-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67397 Andrew Pinski changed: What|Removed |Added URL|http://stackoverflow.com/q/ | |31954078/801438 | --- Comment #1 from Andrew Pinski --- http://stackoverflow.com/q/31954078/801438
[Bug c++/53878] [C++11] Abstract class constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53878 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #2 from Andrew Pinski --- Fixed in GCC 7+. I suspect by r7-3590 .
[Bug target/101697] [11/12 regression] ICE compiling uClibc-ng for h8300-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697 --- Comment #1 from Mikael Pettersson --- The ICE in gcc-11 started with: [f16897cb4b1468374d63b1a6b12d8b7be845874a] H8 cc0 conversion It changed from "unrecognizable insn" to "could not split insn" in gcc-12 with: [549d7f4310f6f8c2c64efcb6f3efcee99c9d9f4f] Fix split conditions in H8/300 port
[Bug c++/64587] [C++11] Wrong number of template arguments when template template parameter is template alias.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64587 --- Comment #2 from Andrew Pinski --- Hmm, this code starts to be accepted in GCC 7.
[Bug c++/54706] -fsyntax-only suppresses a compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54706 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |6.0 Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Fixed in GCC 6+, most likely by r6-1401 which changed slightly how -fsyntax-only is handled.
[Bug c++/101707] New: deduction of template argument fails via base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101707
Bug ID: 101707
Summary: deduction of template argument fails via base class
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: baber.nwz at gmail dot com
Target Milestone: ---
The following program fails to compile with GCC 11.2 but compiles with clang
(from version 12 to 3), MSVC (2015, 2017, 2019) and ICC:
template
struct S {};
struct A : S {};
struct B : S {};
struct C : A, B, S {};
template class TPL>
void f(TPL& a)
{
}
void g()
{
A a;
B b;
C c;
f(a); // OK
f(b); // OK
f(c); // ERROR
}
The compiler gives the following output:
source>: In function 'void g()':
:21:14: error: no matching function for call to 'f(C&)'
21 | f(c);
| ~^~~
:9:6: note: candidate: 'template class TPL>
void f(TPL&)'
9 | void f(TPL& a)
| ^
:9:6: note: template argument deduction/substitution failed:
:21:14: note: 'TPL' is an ambiguous base class of 'C'
21 | f(c);
| ~^~~
With the supplied template parameter (double), the base class is definitely not
ambiguous.
https://godbolt.org/z/EKn16o46a
[Bug c++/53566] void template parameters are accepted if they result from substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53566 Andrew Pinski changed: What|Removed |Added Keywords||accepts-invalid --- Comment #1 from Andrew Pinski --- clang accepts this code too.
[Bug c++/59389] [C++11] bogus error: call of overloaded ‘Foo()’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59389 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-07-31 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug c++/59509] template function definition. redefinition error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59509 --- Comment #3 from Andrew Pinski --- I should say this is fixed in GCC 9.4 and 10+.
[Bug c++/93211] equivalence of dependent function calls doesn't check if the call is eligible for ADL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93211 Andrew Pinski changed: What|Removed |Added CC||ich at az2000 dot de --- Comment #3 from Andrew Pinski --- *** Bug 59509 has been marked as a duplicate of this bug. ***
[Bug c++/59509] template function definition. redefinition error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59509 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.4 Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Keywords||rejects-valid --- Comment #2 from Andrew Pinski --- Dup of bug 93211. *** This bug has been marked as a duplicate of bug 93211 ***
[Bug c++/95009] [9/10/11/12 Regression] decltype of increment or decrement bitfield expressions are wrong and causes assembler errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95009 --- Comment #2 from Andrew Pinski --- There is most likely a missing unlowered_expr_type somewhere in the decltype handling.
[Bug c++/95009] [9/10/11/12 Regression] decltype of increment or decrement bitfield expressions are wrong and causes assembler errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95009 Andrew Pinski changed: What|Removed |Added Keywords||assemble-failure, ||ice-checking, ||ice-on-valid-code Target Milestone|--- |9.5 Known to fail||12.0, 4.8.1 Known to work||4.7.1 Last reconfirmed||2021-07-31 Summary|decltype of increment or|[9/10/11/12 Regression] |decrement bitfield |decltype of increment or |expressions are wrong and |decrement bitfield |causes assembler errors.|expressions are wrong and ||causes assembler errors. Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug ada/70867] [9/10/11/12 regression] access discriminant in return aggregate wrongly detected as dangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70867 simon at pushface dot org changed: What|Removed |Added CC||simon at pushface dot org --- Comment #14 from simon at pushface dot org --- (In reply to Nicolas Boulenguez from comment #0) > Hello. > With GCC-6 (Debian 6.0.1-2) 6.0.1 20160423 (prerelease), > compiling the following package with "gcc-6 -c p.adb" fails: > p.adb:4:20: access discriminant in return aggregate would be a dangling > reference > The code compiles > - if the "generic" line is removed > - or if ".all" is inserted between "Position" and ".Item'Access" > I am not sure whether returning this reference is allowed by the Ada > Reference Manual, > but the semantics of "generic" and ".all" should certainly not affect the > answer. GCC 11.1.0, x86_64-apple-darwin on macOS 11.6 (Big Sur): This compiles without error, and the example below executes correctly. with P; with Ada.Text_IO; procedure P_Test is package Q is new P; R : aliased Q.R := (Item => 42); T : Q.T := Q.F (R'Access); begin Ada.Text_IO.Put_Line (T.D.all'Image); end P_Test;
[Bug c++/82467] name mangling error when using constrained and specialized template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82467 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-07-31 Keywords||assemble-failure Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/85292] multiple definitions of a default argument emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85292 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed.
[Bug c++/78908] [6/7 Regression] template instantiation with bit-field type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78908 --- Comment #11 from Andrew Pinski --- *** Bug 78943 has been marked as a duplicate of this bug. ***
[Bug c++/78943] Generated assembler fails with symbol is already defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78943
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #2 from Andrew Pinski ---
Yes this is a dup of bug 78908.
struct x {
unsigned ai : 7;
};
...
template void operator<<(ba, bb) {}
class bc {};
...
x const
...
bc h;
h << bg.ai;
*** This bug has been marked as a duplicate of bug 78908 ***
[Bug tree-optimization/101706] New: bool0^bool1^1 -> bool0 == bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101706
Bug ID: 101706
Summary: bool0^bool1^1 -> bool0 == bool1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
void fa(bool , bool , bool )
{
c= a==b;
}
void fb(bool , bool , bool )
{
int t = (a^b);
c= (t^1);
}
I don't know how often this shows up but I am putting this here for
completeness.
[Bug c++/101704] "Already defined" error in case of many concept conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101704 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Keywords||assemble-failure, ||ice-on-valid-code See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98163 Status|UNCONFIRMED |NEW Last reconfirmed||2021-07-31 --- Comment #1 from Andrew Pinski --- Note 11 will also ICE the same way as the trunk if you either configure with checking turned on or if you use -fchecking . Might be related to PR 98163.
[Bug tree-optimization/101705] Missed optimization opportunity when copying lots of bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101705 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-07-31 Status|UNCONFIRMED |ASSIGNED Keywords||missed-optimization Ever confirmed|0 |1 Component|c |tree-optimization Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- Mine but for GCC 13. There are other bugs which say the same thing too.
[Bug target/100182] [8/9/10/11/12 Regression] Miscompilation of atomic_float/1.cc and atomic_float/wait_notify.cc on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #37 from H.J. Lu ---
I still see 32-bit test hang at random on Skylake server:
(gdb) bt
#0 0xf7fc655d in __kernel_vsyscall ()
#1 0xf7bac46b in syscall () from /lib/libc.so.6
#2 0x0804995d in std::__detail::__platform_wait (
__addr=0x804d680 , __val=3)
at
/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/32/libstdc++-v3/include/bits/atomic_wait.h:104
#3 0x08049e3a in std::__detail::__waiter_pool::_M_do_wait (__old=3,
__addr=0x804d680 , this=)
at
/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/32/libstdc++-v3/include/bits/atomic_wait.h:261
#4 std::__detail::__waiter
>::_M_do_wait_v(unsigned
int const*, std::remove_volatile::type,
std::memory_order)::{lambda()#1}>(unsigned int,
std::__atomic_impl::wait(unsigned int const*,
std::remove_volatile::type, std::memory_order)::{lambda()#1})
(__vfn=...,
__old=42, this=)
at
/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/32/libstdc++-v3/include/bits/atomic_wait.h:400
#5 std::__atomic_wait_address_v(unsigned int const*,
std::remove_volatile::type,
std::memory_order)::{lambda()#1}>(unsigned int const*, unsigned int,
std::__atomic_impl::wa--Type for more, q to quit, c to continue without
paging--
it(unsigned int const*, std::remove_volatile::type,
std::memory_order)::{lambda()#1}) (__addr=0xffeb402c, __old=42, __vfn=...)
at
/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/32/libstdc++-v3/include/bits/atomic_wait.h:430
#6 0x08049ef2 in std::__atomic_impl::wait (
__m=std::memory_order::seq_cst, __old=,
__ptr=)
at
/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/32/libstdc++-v3/include/bits/atomic_base.h:1018
#7 std::__atomic_ref::wait (
__m=std::memory_order::seq_cst, __old=, this=0xffeb4034)
at
/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/32/libstdc++-v3/include/bits/atomic_base.h:1570
#8 test (va=0, vb=42)
at
/export/gnu/import/git/gcc-test-master-intel64-native/src-master/libstdc++-v3/testsuite/29_atomics/atomic_ref/wait_notify.cc:44
#9 0x0804926b in main ()
at
/export/gnu/import/git/gcc-test-master-intel64-native/src-master/libstdc++-v3/testsuite/29_atomics/atomic_ref/wait_notify.cc:54
(gdb)
GCC was configured with
--with-arch=native --with-cpu=native --prefix=/usr/12.0.0 --enable-clocale=gnu
--with-system-zlib --enable-shared --enable-cet --with-demangler-in-ld
--enable-libmpx --with-multilib-list=m32,m64,mx32 --with-fpmath=sse
It happens about once a few weeks.
[Bug d/101692] Referenses in Slist are not counted by GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101692 --- Comment #6 from Eugene Zhiganov --- ... and there is another "interesting" observation... In one one of the programs there is a StageMachine instance, that catches SIGTERM and SIGINT and there is 'honest' reference to that instance in main(), but... * if compliled with -Os optimization flag, something absolutely unimaginable happens - this instance is destroyed by GC and what is interesting, this happens every time I run the program and it happens always after ~6 seconds after the start * if complied without -Os, everything is Ok. wonders will never cease, -Os is doing something very 'special'
[Bug fortran/77693] ICE in rtl_for_decl_init, at dwarf2out.c:17378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77693 --- Comment #6 from anlauf at gcc dot gnu.org --- I believe this is actually invalid code. One cannot initialize the pointer using the data statement as in the given example. A valid variant (which is accepted and works as expected) is: program p complex, pointer :: a real :: z complex, target :: b = (1.,2.) data a /b/ z = a print *, z end The closest text I can find in F2018 is: 8.4(2): If null-init appears, the initial association status of the object is disassociated. If initial-data-target appears, the object is initially associated with the target. 7.5.4.6(4): If initial-data-target appears for a data pointer component, that component in any object of the type is initially associated with the target or becomes associated with the target as specified in 19.5.2.3. 19.5.2.3 Events that cause pointers to become associated An ice-on-invalid remains, though.
[Bug d/101692] Program crushes at unpredictable moment of time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101692
--- Comment #5 from Eugene Zhiganov ---
Eventually I used following workaround:
RxSm[] rxMachines;
auto rxPool = new RestRoom();
for (int k = 0; k < nConnections; k++) {
auto sm = new RxSm(rxPool);
rxMachines ~= sm;
sm.run();
}
This rxMachines array is just for the purpose of holding references,
since references in linked list are not counted at all by GC.
Now everything works fine, no mystical crashes any more :)
(...and I am beginning to dislike GC even more than before)
But the question remained.
Not counting references in Slist - is that by design?
[Bug d/101692] Program crushes at unpredictable moment of time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101692 --- Comment #4 from Eugene Zhiganov --- investigation continues... -- 'RX-98' deregistered 107 (esrc.Io) !!! esrc.EventSource.~this() : esrc.Io (owner RX-97) this @ 0x7f845328b680<<< note addr !!! esrc.EventSource.~this() : esrc.Timer (owner RX-97) this @ 0x7f845328b6c0 ___!!!___edsm.StageMachine.~this(): RX-97 destroyed... ecap.EventQueue.wait, n = 1, event @ 7FFDBCE6712C, event source @ 0x7f845328b680 <<< // this address is invalid, object already destroyed by GC Segmentation fault -- 'RX-97' is a state machine instance. RX machines are kept in a pool. Slist is used as a stack/pool. RX machines put themselves into the pool upon entering some state. And it seems that since insertFront() method of Slist is not an implicit assignment operator, D's GC does not count reference in a list as a... reference. Oops. Does it mean, it's impossible to store references in lists only?
[Bug c++/96636] ICE in build_value_init_noctor, at cp/init.c:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96636 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:af76342b444948ab262b276cdf083c2d2e0cebbb commit r12-2653-gaf76342b444948ab262b276cdf083c2d2e0cebbb Author: Jason Merrill Date: Fri Jul 30 16:49:03 2021 -0400 c++: ICE on anon struct with base [PR96636] pinski pointed out that my recent change to reject anonymous structs with bases was relevant to this PR. But we still ICEd after giving that error; this fixes the ICE. PR c++/96636 gcc/cp/ChangeLog: * decl.c (fixup_anonymous_aggr): Clear TYPE_NEEDS_CONSTRUCTING after error. gcc/testsuite/ChangeLog: * g++.dg/ext/anon-struct9.C: New test.
[Bug c/101705] Missed optimization opportunity when copying lots of bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101705 --- Comment #2 from Jan Engelhardt --- Created attachment 51229 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51229=edit testcase, 2.c
[Bug c/101705] Missed optimization opportunity when copying lots of bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101705 --- Comment #1 from Jan Engelhardt --- Created attachment 51228 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51228=edit testcase, 1.c
[Bug c/101705] New: Missed optimization opportunity when copying lots of bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101705 Bug ID: 101705 Summary: Missed optimization opportunity when copying lots of bitfields Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jengelh at inai dot de Target Milestone: --- Using gcc-11.1.1 [revision 62bbb113ae68a7e724255e17143520735bcb9ec9], I observe that gcc is able to recognize and combine lots of "structb->member = structa->member" assignments into SIMD instructions. However, this only works as long as "member" has exactly 8*n bits. It would appear gcc is not smart enough to consider smaller entities (if and when they add up to multiples of 8 or 64). Observed [On x86_64] »gcc -O3 -c 1.c; gcc -O3 -c 2.c »objdump -d 1.o 0: f3 0f 6f 3e movdqu (%rsi),%xmm7 ... »objdump -d 2.o 0: 0f b6 16movzbl (%rsi),%edx 3: 0f b6 07movzbl (%rdi),%eax 6: 83 e2 01and$0x1,%edx 9: 83 e0 feand$0xfffe,%eax c: 09 d0 or %edx,%eax e: 88 07 mov%al,(%rdi) 10: 0f b6 16movzbl (%rsi),%edx 13: 83 e0 fdand$0xfffd,%eax 16: 83 e2 02and$0x2,%edx 19: 09 d0 or %edx,%eax 1b: 88 07 mov%al,(%rdi) ... Expected Emit some movdqu/movups even for 2.c. Other info == gcc version 11.1.1 20210625 [revision 62bbb113ae68a7e724255e17143520735bcb9ec9] (SUSE Linux) & gcc version 7.5.0 (SUSE Linux)
[Bug target/97281] Mark -march=x86-64-v[234] binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97281 H.J. Lu changed: What|Removed |Added Target Milestone|--- |11.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from H.J. Lu --- Fixed by r11-5634: commit 54967b02c192f893e0f23481c865dd8abcb74018 Author: H.J. Lu Date: Mon Nov 9 09:29:23 2020 -0800 x86: Add -mneeded for GNU_PROPERTY_X86_ISA_1_V[234] marker
[Bug ada/97541] Ada failed to bootstrap: Error: file table slot 1 is already occupied by a different file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97541 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Host|https://sourceware.org/bugz | |illa/show_bug.cgi?id=26778 | See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=26778 Resolution|--- |MOVED --- Comment #8 from H.J. Lu --- Moved.
[Bug target/99941] m_ALDERLAKE is missing from m_CORE_AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99941 H.J. Lu changed: What|Removed |Added Target Milestone|--- |11.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from H.J. Lu --- Fixed by r11-8125: commit f2be08339b77d3495e210d6b5d9cea927f437720 Author: Cui,Lili Date: Mon Apr 12 09:59:25 2021 +0800 Change march=alderlake ISA list and add m_ALDERLAKE to m_CORE_AVX2
Compilation of rust-demangle.c fails on MinGW
The version of rust-demangle.c included with Binutils 2.37 doesn't compile with MinGW: mingw32-gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -I. -I../../binutils-2.37/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE ../../binutils-2.37/libiberty/rust-demangle.c -o rust-demangle.o ../../binutils-2.37/libiberty/rust-demangle.c:84:3: error: unknown type name 'uint' 84 | uint recursion; | ^~~~ ../../binutils-2.37/libiberty/rust-demangle.c: In function 'demangle_path': ../../binutils-2.37/libiberty/rust-demangle.c:87:37: error: 'uint' undeclared (first use in this function); did you mean 'int'? 87 | #define RUST_NO_RECURSION_LIMIT ((uint) -1) | ^~~~ ../../binutils-2.37/libiberty/rust-demangle.c:686:25: note: in expansion of macro 'RUST_NO_RECURSION_LIMIT' 686 | if (rdm->recursion != RUST_NO_RECURSION_LIMIT) | ^~~ ../../binutils-2.37/libiberty/rust-demangle.c:87:37: note: each undeclared identifier is reported only once for each function it appears in 87 | #define RUST_NO_RECURSION_LIMIT ((uint) -1) | ^~~~ ../../binutils-2.37/libiberty/rust-demangle.c:686:25: note: in expansion of macro 'RUST_NO_RECURSION_LIMIT' 686 | if (rdm->recursion != RUST_NO_RECURSION_LIMIT) | ^~~ ../../binutils-2.37/libiberty/rust-demangle.c: In function 'rust_demangle_callback': ../../binutils-2.37/libiberty/rust-demangle.c:87:37: error: 'uint' undeclared (first use in this function); did you mean 'int'? 87 | #define RUST_NO_RECURSION_LIMIT ((uint) -1) | ^~~~ ../../binutils-2.37/libiberty/rust-demangle.c:1347:55: note: in expansion of macro 'RUST_NO_RECURSION_LIMIT' 1347 | rdm.recursion = (options & DMGL_NO_RECURSE_LIMIT) ? RUST_NO_RECURSION_LIMIT : 0; | ^~~ This is because the data type 'uint' is not defined in the MinGW headers. I used uint32_t instead, and it compiled OK.
[Bug tree-optimization/101667] GNAT bug detected in op1_range in range-op.cc during GIMPLE pass evrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101667 --- Comment #4 from denkpadje at gmail dot com --- It seems to work on 11.2 so bug can be closed.
[Bug d/101692] Program crushes at unpredictable moment of time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101692 --- Comment #3 from Eugene Zhiganov --- I have reorginized my data - now references to EventSource class and it's derivatives (timers, sockets, signals) are stored in explicitly named data members of other classes. That did not help, still crashes. Then I added destructor for EventSource class to see, if it is called or not. And it is... sample output of a program... - 'RX-0 @ IDLE' got 'M1' from 'CLIENT-2' rx.RxSm.rxIdleM1 : fd = 12 'RX-0' registered 12 (esrc.Io) !!! esrc.EventSource.~this() : esrc.ClientSocket // call of the destructor !!! esrc.EventSource.~this() : esrc.Timer// call of the destructor 'RX-0 @ IDLE' got 'M0' from 'SELF' 'RX-0' enabled 12 (esrc.Io, oneshot) ecap.EventQueue.wait, n = 1, event @ 7FFE506B486C ecap.EventQueue.wait, n = 1, event @ 7FFE506B486C, event source @ 7FB726991F40 Segmentation fault (core dumped) So now I understand, why the crash is happening - an object reference, obtained from epoll_wait() is invalid, because the object was already removed by GC. But I do not understand, why GC destructs these objects...
[Bug target/94780] [8/9 Regression] ICE in walk_body at gcc/tree-nested.c:713 since r6-3632-gf6f69fb09c5f81df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:79184d8c57d377a242610543a2cbe4f154924be7 commit r9-9655-g79184d8c57d377a242610543a2cbe4f154924be7 Author: Xi Ruoyao Date: Fri Jul 30 23:44:14 2021 +0800 mips: Fix up mips_atomic_assign_expand_fenv [PR94780] Commit message shamelessly copied from 1777beb6b129 by jakub: This function, because it is sometimes called even outside of function bodies, uses create_tmp_var_raw rather than create_tmp_var. But in order for that to work, when first referenced, the VAR_DECLs need to appear in a TARGET_EXPR so that during gimplification the var gets the right DECL_CONTEXT and is added to local decls. gcc/ PR target/94780 * config/mips/mips.c (mips_atomic_assign_expand_fenv): Use TARGET_EXPR instead of MODIFY_EXPR. (cherry picked from commit 2065654435e3d97676366f82b939bc9273382dbe)
[Bug c++/101704] New: "Already defined" error in case of many concept conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101704
Bug ID: 101704
Summary: "Already defined" error in case of many concept
conversion operators
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
Example code:
```
template class C;
template > concept x = true;
#include
struct S {
operator x> auto() { return 42; }
operator x> auto() { return '+'; }
operator x> auto() { return 44LL; }
operator x> auto() { return 45.5; }
operator x> auto() { return 46.5f; }
operator x> auto() { return 47L; }
operator x> auto() { return 48ULL; }
operator x> auto() { return 49U; }
};
int main() {
S s;
std::cout << (int)s << "\n";
std::cout << (char)s << "\n";
std::cout << (long long)s << "\n";
std::cout << (double)s << "\n";
std::cout << (float)s << "\n";
std::cout << (long)s << "\n";
std::cout << (unsigned long long)s << "\n";
std::cout << (unsigned)s << "\n";
}
```
GCC 11 prints:
```
/tmp/ccfcrhcg.s: Assembler messages:
/tmp/ccfcrhcg.s:33: Error: symbol `_ZN1ScvDaEv' is already defined
/tmp/ccfcrhcg.s:55: Error: symbol `_ZN1ScvDaEv' is already defined
/tmp/ccfcrhcg.s:77: Error: symbol `_ZN1ScvDaEv' is already defined
/tmp/ccfcrhcg.s:101: Error: symbol `_ZN1ScvDaEv' is already defined
/tmp/ccfcrhcg.s:123: Error: symbol `_ZN1ScvDaEv' is already defined
/tmp/ccfcrhcg.s:145: Error: symbol `_ZN1ScvDaEv' is already defined
/tmp/ccfcrhcg.s:167: Error: symbol `_ZN1ScvDaEv' is already defined
Execution build compiler returned: 1
```
GCC (truck) crashes on this example:
```
:29:1: internal compiler error: symtab_node::verify failed
0x1dabd49 internal_error(char const*, ...)
???:0
0xb68322 symtab_node::verify_symtab_nodes()
???:0
0xb844cf symbol_table::finalize_compilation_unit()
???:0
```
https://gcc.godbolt.org/z/KP8Wqhz96
[Bug middle-end/78103] Failure to optimize with __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #23 from Jakub Jelinek --- Fixed for GCC 12+.
[Bug d/101692] Program crushes at unpredictable moment of time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101692 --- Comment #2 from Eugene Zhiganov --- I've attached full source, just in case. And I think, I began to understand, what is wrong with it. In brief: it looks like GC deallocates objects, which it should not deallocate, because it does not take into account for references, which are stored in associative arrays.
[Bug middle-end/78103] Failure to optimize with __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103 --- Comment #22 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:91425e2adecd00091d7443104ecb367686e88663 commit r12-2649-g91425e2adecd00091d7443104ecb367686e88663 Author: Jakub Jelinek Date: Sat Jul 31 09:19:32 2021 +0200 i386: Improve extensions of __builtin_clz and constant - __builtin_clz for -mno-lzcnt [PR78103] This patch improves emitted code for the non-TARGET_LZCNT case. As __builtin_clz* is UB on 0 argument and for !TARGET_LZCNT CLZ_VALUE_DEFINED_AT_ZERO is 0, it is UB even at RTL time and so we can take advantage of that and assume the result will be 0 to 31 or 0 to 63. Given that, sign or zero extension of that result are the same and are actually already performed by bsrl or xorl instructions. And constant - __builtin_clz* can be simplified into bsr + constant - bitmask. For TARGET_LZCNT, a lot of this is already fine as is (e.g. the sign or zero extensions), and other optimizations are IMHO not possible (if we have lzcnt, we've lost information on whether it is UB at zero or not and so can't transform it into bsr even when that is 1-2 insns shorter). The changes on the 3 testcases between unpatched and patched gcc are for -m64: pr78103-1.s: bsrq%rdi, %rax - xorq$63, %rax - cltq + xorl$63, %eax ... bsrq%rdi, %rax - xorq$63, %rax - cltq + xorl$63, %eax ... bsrl%edi, %eax xorl$31, %eax - cltq ... bsrl%edi, %eax xorl$31, %eax - cltq pr78103-2.s: bsrl%edi, %edi - movl$32, %eax - xorl$31, %edi - subl%edi, %eax + leal1(%rdi), %eax ... - bsrl%edi, %edi - movl$31, %eax - xorl$31, %edi - subl%edi, %eax + bsrl%edi, %eax ... bsrq%rdi, %rdi - movl$64, %eax - xorq$63, %rdi - subl%edi, %eax + leal1(%rdi), %eax ... - bsrq%rdi, %rdi - movl$63, %eax - xorq$63, %rdi - subl%edi, %eax + bsrq%rdi, %rax pr78103-3.s: bsrl%edi, %edi - movl$32, %eax - xorl$31, %edi - movslq %edi, %rdi - subq%rdi, %rax + leaq1(%rdi), %rax ... - bsrl%edi, %edi - movl$31, %eax - xorl$31, %edi - movslq %edi, %rdi - subq%rdi, %rax + bsrl%edi, %eax ... bsrq%rdi, %rdi - movl$64, %eax - xorq$63, %rdi - movslq %edi, %rdi - subq%rdi, %rax + leaq1(%rdi), %rax ... - bsrq%rdi, %rdi - movl$63, %eax - xorq$63, %rdi - movslq %edi, %rdi - subq%rdi, %rax + bsrq%rdi, %rax Most of the changes are done with combine splitters, but for *bsr_rex64_2 and *bsr_2 I had to use define_insn_and_split, because as mentioned in the PR the combiner unfortunately doesn't create LOG_LINKS in between the two insns created by combine splitter, so it can't be combined further with following instructions. 2021-07-31 Jakub Jelinek PR target/78103 * config/i386/i386.md (bsr_rex64_1, bsr_1, bsr_zext_1): New define_insn patterns. (*bsr_rex64_2, *bsr_2): New define_insn_and_split patterns. Add combine splitters for constant - clz. (clz2): Use a temporary pseudo for bsr result. * gcc.target/i386/pr78103-1.c: New test. * gcc.target/i386/pr78103-2.c: New test. * gcc.target/i386/pr78103-3.c: New test.
[Bug d/101692] Program crushes at unpredictable moment of time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101692 --- Comment #1 from Eugene Zhiganov --- Created attachment 51227 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51227=edit references to objects in associative arrays
[Bug tree-optimization/101703] New: (bool0 + bool1) & 1 and (bool0 + bool1) == 1 can be optimized to bool0 ^ bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101703
Bug ID: 101703
Summary: (bool0 + bool1) & 1 and (bool0 + bool1) == 1 can be
optimized to bool0 ^ bool1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
bool f(bool a, bool b)
{
int t = a;
int t1 = b;
return (t + t1) & 1;
}
bool fa(bool a, bool b)
{
int t = a;
int t1 = b;
return (t + t1)==1;
}
bool fb(bool a, bool b)
{
return a!=b;
}
bool fc(bool a, bool b)
{
return a^b;
}
These three should produce the same code gen. Right now fb and fc do but f and
fa needs to handled.
the for fa, == 1 can be converted into & 1 as the range is [0,2]:
# RANGE [0, 2] NONZERO 3
_1 = t_3 + t1_5;
_6 = _1 == 1;
and only 1 can be if & 1 is true. And the rest just follows through.
