[Bug c++/99076] New: Unclear error message when trailing angle bracket is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99076 Bug ID: 99076 Summary: Unclear error message when trailing angle bracket is missing Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bugzi...@poradnik-webmastera.com Target Milestone: --- [code] #include #include template< typename Key, typename T, typename Compare = std::less, typename Allocator = std::allocator> > using SecureMemMap = std::map>; [/code] When this is compiled using g++, it gives following error message: [out] :9:53: error: template argument 4 is invalid 9 | using SecureMemMap = std::map>; | [/out] Above message is not very helpful, it is hard to tell what is wrong here. clang++ does better job here. Please improve g++ message in a similar way: [out] :9:87: error: expected '>' using SecureMemMap = std::map>; ^ :9:30: note: to match this '<' using SecureMemMap = std::map>; ^ [/out]
[Bug target/105731] superfluous second operation before conditional branch -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105731 Kio changed: What|Removed |Added Version|10.3.1 |11.2.1 --- Comment #6 from Kio --- i just came across the test on godbolt again and found they added gcc 11.2.1. compiled code no change. so i updated gcc version for the ticket.
[Bug target/106827] New: operator++ doesn't work for enum -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827 Bug ID: 106827 Summary: operator++ doesn't work for enum -O2 -mcpu=cortex-m0plus Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bugzi...@little-bat.de Target Milestone: --- Created attachment 53536 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53536&action=edit the example on godbolt.org gcc "optimizes" away prefix and postfix operator++ for enums. see https://godbolt.org/z/1E65Ej7aE --> three loops, only version 3 works (presumably).
[Bug target/106827] operator++ doesn't work for enum -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827 --- Comment #1 from Kio --- updated link at godbolt: https://godbolt.org/z/5sf7cr9c3
[Bug target/106827] operator++ doesn't work for enum -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827 --- Comment #4 from Kio --- (In reply to Richard Earnshaw from comment #2) > Please put testcases in the bug report, godbolt links are not stable. test case was also attached as a file with the bug report.
[Bug target/106827] operator++ doesn't work for enum -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827
--- Comment #7 from Kio ---
(In reply to Andreas Schwab from comment #5)
> The operator++ function is expected to modify the argument in place, and
> needs to take a reference to it.
Yes, that's my error! after modifying the operators to:
Foo operator++(Foo& n,int) { Foo v=n; n=Foo(int(n)+1); return v; }
Foo& operator++(Foo& n){ return n=Foo(int(n)+1); }
then the compiled code is as expected.
Obviously arg#1 must be a reference, because the argument must be modified.
Actually i think this code should not compile or at least produce a warning (i
compile with almost all warnings on, but that went silent). When passing a
value the operator can't do what is expected.
[Bug c++/105731] New: superfluous second operation before conditional branch -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105731 Bug ID: 105731 Summary: superfluous second operation before conditional branch -O2 -mcpu=cortex-m0plus Product: gcc Version: og10 (devel/omp/gcc-10) Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bugzi...@little-bat.de Target Milestone: --- gcc 10.3.1 misses an easy oportunity for optimization: Instruction: if ((bits<<=1)>=0) goto p3; generated code: strhr7, [r0, #4] lslsr3, r2, #1 lslsr2, r2, #1 bpl .L8 i believe the 2nd "lsls" is superfluous. It would save me 3MHz if it wasn't there. :-) full example: https://godbolt.org/z/xocbvjn5x
[Bug c++/118808] operator new allocates wrong size for object of a template class with two variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118808 Kio changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Kio --- sorry to say this, but the problem is with cmake which behaved (probably as documented) but not as i assumed. an option set in a subdirectory didn't make it into the main project. the issue raised here very likely was a false alert.
[Bug c++/118808] operator new allocates wrong size for object of a template class with two variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118808 --- Comment #1 from Kio --- line 82826
[Bug c++/118808] New: operator new allocates wrong size for object of a template class with two variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118808
Bug ID: 118808
Summary: operator new allocates wrong size for object of a
template class with two variants
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@little-bat.de
Target Milestone: ---
Created attachment 60433
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60433&action=edit
gcc version, invocation and .ii file
compiling with arm-none-eabi for cortex-m0plus
compiling for release with -O3 is faulty.
compiling for debug with -Og is correct.
when allocating an object of a template class, which has two separate
definitions for two variants A and B separated by std::enable_if, where variant
B is based on variant A, operator new() only allocates the size for variant A
when instantiating an object of variant B.
the correct constructor is called which overwrites the end of the allocated
memory thus corrupting the heap.
in this example:
virtual base class Canvas
template class Pixmap;
// variant A without attributes:
template
class Pixmap> : public
Canvas {...}
// variant B with attributes is based on variant A without attributes:
template
class Pixmap> final :
public Pixmap {...}
the invocation is in line 8286 of the .ii file
[Bug c++/107466] New: [12 Regression] invalid -Wnarrowing error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466 Bug ID: 107466 Summary: [12 Regression] invalid -Wnarrowing error Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: littlefox+gcc-bugzi...@lf-net.org Target Milestone: --- Created attachment 53797 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53797&action=edit Code triggering the error Hi, the attached code (and Godbolt[1]) fails in gcc 12+ with an -Wnarrowing error in a stdlibc++ template instantiated with an uint16_t and apparently trying to work with a 2^31: /opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/random.tcc:545:9: error: narrowing conversion of '2147483563' from 'unsigned int' to 'short unsigned int' [-Wnarrowing] 545 | __lcg(__value == 0u ? default_seed : __value); The code works fine in 11.3 and clang (14) and since it also works in clang using libstdc++ 12.2, this error is probably in gcc itself and not in libstdc++. Tested this on my machine (debian testing), where it broke after a some system updates where installed - including a gcc update. Then tested this in Godbolt to check compiler versions and other configurations and asked in libera.chat/#c++ for others to verify if my code makes sense - which it seems to do. Best, Mara [1] Godbolt link: https://godbolt.org/z/sj18Mv5j9
[Bug c++/107466] [12/13 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466 --- Comment #3 from Mara Sophie Grosch --- Standard explicitly allows using unsigned short though: https://en.cppreference.com/w/cpp/numeric/random/subtract_with_carry_engine
