[Bug c++/109718] New: Dependency generation for header-units and modules not possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109718
Bug ID: 109718
Summary: Dependency generation for header-units and modules not
possible
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
To generate make-dependencies I use the following command line:
g++ -c -MD -MG -std=c++23 -fconcepts -fmodules-ts test.cc
where test.cc is:
-
import ;
int main() {
}
-
It gives the error:
cc1plus: error: '-MG' may only be used with '-M' or '-MM'
Removing -MG gives also an error, because the precompiled header does not yet
exist:
/usr/local/include/c++/14.0.0/iostream: error: failed to read compiled module:
No such file or directory
/usr/local/include/c++/14.0.0/iostream: note: compiled module file is
'gcm.cache/./usr/local/include/c++/14.0.0/iostream.gcm'
/usr/local/include/c++/14.0.0/iostream: note: imports must be built before
being imported
/usr/local/include/c++/14.0.0/iostream: fatal error: returning to the gate for
a mechanical issue
So, it looks that there is no possiblity to create a valid dependency file with
gcc.
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523 --- Comment #27 from Wilhelm M --- > I don't know if every embedded developer feels the same way. (Georg-Johann > could chime in with his opinion.) Indeed, limiting the warning on volatile-qualified ptr would help.
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523 --- Comment #26 from Wilhelm M --- As you can see in my opening bug report, there is no nullptr reference nor dereferencing a pointer with value 0.
[Bug c++/107622] Missing optimization of switch-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622 --- Comment #12 from Wilhelm M --- (In reply to Wilhelm M from comment #11) > Without an underlying type but with -fshort-enums the underlying type should > be as small as possible. In this case this should be a uint8_t. But in this > case we get a 16-bit value for mState. This is a clear violation of > -fshort-enums. That (my previous comment) was clear nonsense. enum class has always underlying type int if not specified according to the standard.
[Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532 --- Comment #5 from Wilhelm M --- (In reply to Andrew Pinski from comment #4) > (In reply to Wilhelm M from comment #3) > > Isn't this a case where the as-if rule kicks in? > > What rule is that? Scopped enums are different from unscopped ones here > specifically as defined in the C++ standard. Ok, I see the point as the C++ standard nails down the type to int disallowing any as-if optimization. So in general a scoped-enum inside a class (nested type) maybe always a bad idea, because it prevents optimization. And when specifying the underlying type, the -fstrict-enums can't be applied because all values of the underlying type are possible.
[Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532 --- Comment #3 from Wilhelm M --- (In reply to Andrew Pinski from comment #2) > (In reply to Andrew Pinski from comment #1) > > That is because a scopped enum has an underlying type of int if not > > supplied. > > > > From [dcl.enum]/5: > > For a scoped enumeration type, the underlying type is int if it is not > > explicitly specified. > > I should say this is from the C++ standard there. > -fshort-enums does not change the language, only ABI. Isn't this a case where the as-if rule kicks in?
[Bug c++/109532] New: -fshort-enums does not pick smallest underlying type for scoped enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532
Bug ID: 109532
Summary: -fshort-enums does not pick smallest underlying type
for scoped enum
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
In the follwoing code, the best code with 8-bit underlying for the enum-type is
only optimized for unscoped enum.
The scoped enum always produces a 16-bit enum underlying type.
Compile with: -Os -mmcu=atmega328 -fshort-enums
(note: equivalent C code (unscoped enums) produces optimal code with
-fshort-enums)
#include
#include
volatile uint8_t o;
struct FSM {
//enum class State : uint8_t {A, B, C, D};// <2> 8bit enum
//enum State {A, B, C, D};// <3> 8bit enum with
-fshort-enums
enum class State {A, B, C, D};// <1> 16bit enum with
-fshort-enums
static void f() __attribute__((noinline)) {
switch(mState) {
case State::A:
o = 10;
break;
case State::B:
o = 11;
break;
case State::C:
o = 12;
break;
case State::D:
o = 13;
break;
}
}
private:
inline static State mState{State::A};
};
int main() {
while(true) {
FSM::f();
}
}
[Bug c++/107622] Missing optimization of switch-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622 --- Comment #11 from Wilhelm M --- Without an underlying type but with -fshort-enums the underlying type should be as small as possible. In this case this should be a uint8_t. But in this case we get a 16-bit value for mState. This is a clear violation of -fshort-enums.
[Bug target/66511] [avr] whole-byte shifts not optimized away for uint64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66511 Wilhelm M changed: What|Removed |Added CC||klaus.doldinger64@googlemai ||l.com --- Comment #5 from Wilhelm M --- (In reply to Roger Sayle from comment #4) > Created attachment 54871 [details] > proposed patch > > Proposed patch, using a peephole2 in avr-dimode.md to inline calls to > __lshrdi3 that require only a single instruction or two (due to truncation). > For truncations to char, this is smaller and faster, and for truncations to > unsigned short this is the same size, but faster. The drawback is that > performing this late (in peephole2) doesn't eliminate the stack frame > prolog/epilog. Thoughts? Looks good to me. Many thanks!
[Bug target/54816] [avr] shift is better than widening mul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54816 --- Comment #3 from Wilhelm M --- (In reply to Roger Sayle from comment #2) > The original problem looks to be fixed on mainline. Can you confirm this > Wilhelm? If so we can close this PR. > > With -Os -mmcu=atmega8, we currently generate (the desired): > wmul: lsl r22 > lsl r22 > lsl r22 > muls r22,r24 > movw r24,r0 > clr __zero_reg__ > ret Yes, this seems to be fixed in mainline.
[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 --- Comment #16 from Wilhelm M --- (In reply to Roger Sayle from comment #14) > My apologies for the delay/issues. My bootstrap and regression testing of > this patch (on x86_64-pc-linux-gnu) revealed an issue or two (including the > reported ICE). My plan was to fix/resolve all these before posting a > concrete submission to gcc-patches. We all appreciate your great effort in this case! Please don't hesitate to send here some patches to test with. I'll be happy to test your patches!
[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 --- Comment #15 from Wilhelm M --- Just checked actual gcc 13.0.1 without the patch: then no ICE accurs.
[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 --- Comment #13 from Wilhelm M --- Yes, the ICE is with the patch. I'm pretty sure that this does not happen without the patch, but I will that check again.
[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 --- Comment #11 from Wilhelm M --- After testing some more code, I got this ICE: /home/lmeier/Projekte/wmucpp/boards/rcfoc/gimbal_sbus_01.cc: In static member function 'static void GlobalFsm::ratePeriodic() [with BusDevs =BusDevs > >]': /home/lmeier/Projekte/wmucpp/boards/rcfoc/gimbal_sbus_01.cc:426:5: error: unrecognizable insn: 426 | } | ^ (insn 1584 1583 25 3 (set (concatn:HI [ (reg:QI 800) (reg:QI 801 [+1 ]) ]) (reg:HI 826)) "../../include0/external/sbus/sbus.h":226:69 -1 (nil)) during RTL pass: subreg1 /home/lmeier/Projekte/wmucpp/boards/rcfoc/gimbal_sbus_01.cc:426:5: internal compiler error: in extract_insn, at recog.cc:2791 0x79f2cb _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc/rtl-error.cc:108 0x79f2e7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc/rtl-error.cc:116 0x79dc77 extract_insn(rtx_insn*) ../../gcc/recog.cc:2791 0x1a43d91 decompose_multiword_subregs ../../gcc/lower-subreg.cc:1651 0x1a447ca execute ../../gcc/lower-subreg.cc:1790 Please submit a full bug report, with preprocessed source (by using -freport-bug).
[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 --- Comment #8 from Wilhelm M --- Yes. Looks like the patch does its job.
[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #6 from Wilhelm M ---
The following "solution"
constexpr uint16_t mul(const uint8_t a, const uint16_t b) {
const auto aa = std::bit_cast>(b);
return aa[1] * a;
}
or
constexpr uint16_t mul(const uint8_t a, const uint16_t b) {
uint8_t aa[2];
std::memcpy(aa, , 2);
return aa[1] * a;
}
gives optimal result ;-)
[Bug target/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 --- Comment #3 from Wilhelm M --- Sorry, I forgot to mention the flags: -Os -mmcu=atmega328 Maybe CompilerExplorer ist also usefull: https://godbolt.org/z/zsq6PT1xb
[Bug target/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #1 from Wilhelm M ---
Inetristingly changing the function to
uint16_t mul(const uint8_t a, const uint16_t b) {
return static_cast((b >> 8) + 1) * a ;
}
produces optimal
mul(unsigned char, unsigned int):
subi r23,lo8(-(1))
mul r23,r24
movw r24,r0
clr __zero_reg__
ret
[Bug c++/109476] New: Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
Bug ID: 109476
Summary: Missing optimization for 8bit/8bit multiplication /
regression
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
For avr-gcc > 4.6.4 the follwing function
uint16_t mul(const uint8_t a, const uint16_t b) {
return static_cast((b >> 8) + 0) * a ;
}
produces suboptimal
mul(unsigned char, unsigned int):
mov r18,r23
ldi r19,0
mov r20,r24
mul r20,r18
movw r24,r0
mul r20,r19
add r25,r0
clr __zero_reg__
ret
whereas avr-gcc 4.6.4 produces optimal
mul(unsigned char, unsigned int):
mul r23,r24
movw r24,r0
clr r1
ret
[Bug target/54816] [avr] shift is better than widening mul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54816
Wilhelm M changed:
What|Removed |Added
CC||klaus.doldinger64@googlemai
||l.com
--- Comment #1 from Wilhelm M ---
The following code has the same problem:
#include
#include
uint16_t b;
uint8_t a;
template
B Mul(const A a, const B b) {
static constexpr uint8_t shift = (sizeof(B) - sizeof(A)) * 8;
return static_cast(b >> shift) * a ;
}
int main() {
return Mul(a, b);
}
with 4.6.4. it produces:
main:
lds r24,a
lds r25,b+1
mul r25,r24
movw r24,r0
clr r1
ret
with actual 12.2 it produces missing optimization:
main:
lds r24,b+1
ldi r25,0
lds r18,a
movw r20,r24
mul r18,r20
movw r24,r0
mul r18,r21
add r25,r0
clr __zero_reg__
ret
Interistingly the follwing code produces optimal code also with 12.2:
template
B MulX(const A a, const B b) {
static const uint8_t shift = (sizeof(B) - sizeof(A)) * 8;
return static_cast((b >> shift) + 1) * a ;
}
[Bug middle-end/108778] Missing optimization with direct register access instead of structure mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108778 --- Comment #3 from Wilhelm M --- This problem is not reproducible with avr-gcc 4.5.4. But from avr-gcc 4.6.4. the problem exists.
[Bug target/108778] Missing optimization with direct register access instead of structure mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108778
--- Comment #2 from Wilhelm M ---
Or even simpler:
#include
#include
static uint16_t g;
int main() {
for(uint8_t i = 0; i < 20; i++) {
++g;
//VPORTA_DIR; // suppresses optimization
VPORTA.DIR;
}
}
[Bug target/108778] Missing optimization with direct register access instead of structure mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108778
--- Comment #1 from Wilhelm M ---
This is a simpler example:
#include
#include
typedef struct Cpu { // this is missing in avr headers
volatile uint8_t reserved_0_3[4];
volatile uint8_t ccp;
volatile uint8_t reserved_5_a[6];
volatile uint8_t rampz;
volatile uint8_t reserved_c;
volatile uint16_t sp;
volatile uint8_t sreg;
} Cpu_t;
#define CPU (*(Cpu_t*) 0x0030)
static uint16_t g;
static void func(void) {
for(uint8_t i = 0; i < 20; i++) {
++g;
//SREG; // prohibits optimization
CPU.sreg;
}
}
int main() {
func();
}
[Bug c++/108778] New: Missing optimization with direct register access instead of structure mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108778
Bug ID: 108778
Summary: Missing optimization with direct register access
instead of structure mapping
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
The following example uses two functional identical ways to save the SREG of a
AVR µC, in this case an avr128da32.
To access the SREG two different ways are used: one directly via the SREG macro
and one via a structure mapping (the Cpu_t structure is actually not included
in the avr headers,
so a definition of the Cpu_t structure is given here).
If the SREG macro way is used the optimization regarding the variable g is
missed (see assembler code below).
Using the structure mapping the load / store of g is correctly optimized out of
the loop.
In the SREG macro case unfortunately not!
#include
#include
#include
#include
#define ACCESS_ONCE(x) (*(volatile typeof(x)*)&(x))
typedef struct Cpu { // this is missing in avr headers
volatile uint8_t r0;
volatile uint8_t r1;
volatile uint8_t r2;
volatile uint8_t r3;
volatile uint8_t ccp;
volatile uint8_t r5;
volatile uint8_t r6;
volatile uint8_t r7;
volatile uint8_t r8;
volatile uint8_t r9;
volatile uint8_t ra;
volatile uint8_t rampz;
volatile uint8_t rc;
volatile uint16_t sp;
volatile uint8_t sreg;
} Cpu_t;
#define CPU (*(Cpu_t *) 0x0030)
static uint8_t flag;
static uint16_t counter;
static uint16_t g;
static inline uint16_t count() {
const uint8_t save = CPU.sreg;
//const uint8_t save = SREG; // suppresses optimization
asm volatile("cli" : : :);
const uint16_t t = ACCESS_ONCE(counter);
//SREG = save; // suppresses optimization
CPU.sreg = save;
return t;
}
static void func(void) {
for(uint8_t i = 0; i < 20; i++) {
g += count();
if (ACCESS_ONCE(flag)) {
ACCESS_ONCE(flag) = 1;
}
}
}
ISR(USART0_RXC_vect) {
_MemoryBarrier();
counter += 1;
if (counter >= 100) {
flag = 1;
}
}
int main() {
func();
}
the generated assembly should be:
main:
lds r24,g; g_lsm.16, g
lds r25,g+1 ; g_lsm.16, g
ldi r18,lo8(20) ; ivtmp_7,
ldi r19,lo8(1) ; tmp56,
.L5:
in r22,__SREG__ ; save, MEM[(struct Cpu_t *)48B].sreg
cli
lds r20,counter ; t, MEM[(volatile uint16_t *)]
lds r21,counter+1; t, MEM[(volatile uint16_t *)]
out __SREG__,r22 ; MEM[(struct Cpu_t *)48B].sreg, save
add r24,r20 ; g_lsm.16, t
adc r25,r21 ; g_lsm.16, t
lds r20,flag ; _6, MEM[(volatile uint8_t *)]
cpse r20,__zero_reg__; _6
sts flag,r19 ; MEM[(volatile uint8_t *)], tmp56
.L4:
subi r18,lo8(-(-1)) ; ivtmp_7,
cpse r18,__zero_reg__; ivtmp_7,
rjmp .L5 ;
sts g,r24; g, g_lsm.16
sts g+1,r25 ; g, g_lsm.16
ldi r24,0;
ldi r25,0;
ret
but using SREG it gets:
main:
ldi r24,lo8(20) ; ivtmp_12,
ldi r25,lo8(1) ; tmp59,
.L5:
in r18,__SREG__ ; save, MEM[(volatile uint8_t *)63B]
cli
lds r20,counter ; t, MEM[(volatile uint16_t *)]
lds r21,counter+1; t, MEM[(volatile uint16_t *)]
out __SREG__,r18 ; MEM[(struct Cpu_t *)48B].sreg, save
lds r18,g; g, g
lds r19,g+1 ; g, g
add r18,r20 ; tmp53, t
adc r19,r21 ; , t
sts g,r18; g, tmp53
sts g+1,r19 ; g, tmp53
lds r18,flag ; _6, MEM[(volatile uint8_t *)]
cpse r18,__zero_reg__; _6
sts flag,r25 ; MEM[(volatile uint8_t *)], tmp59
.L4:
subi r24,lo8(-(-1)) ; ivtmp_12,
cpse r24,__zero_reg__; ivtmp_12,
rjmp .L5 ;
ldi r24,0;
ldi r25,0;
ret
[Bug middle-end/108712] Missing optimization with memory-barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108712
--- Comment #1 from Wilhelm M ---
And using
__asm__ __volatile__ ("" : : : "memory");
there is no optimization at all.
[Bug c/108712] New: Missing optimization with memory-barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108712
Bug ID: 108712
Summary: Missing optimization with memory-barrier
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
In the following example the increments of `g` could be optimized to a `g+=20`
equivalent.
But avr-gcc hoists the load of `g` outside the loop but the stores remain
inside the loop.
That produces unneccessary overhead.
(I know that the idionatic solution would be to volatile-qualify the variable
`flag`
make a volatile-access like std::experimental::volatile_load()` or
`ACCESS_ONCE()` (linux kernel).
https://godbolt.org/z/1b6xG5YP4
#include
#include
//#include // do not include that stub: wrong sig_atomic_t
typedef signed char sig_atomic_t; // __SIG_ATOMIC_TYPE__
#include
static sig_atomic_t flag;
static uint8_t g;
void func(void) {
for(uint8_t i = 0; i < 20; i++) {
__asm__ __volatile__ ("" : "+m" (flag));
++g;
if (flag) {
flag = 0;
}
__asm__ __volatile__ ("" : "+m" (flag));
}
}
ISR(USART_RXC_vect) {
__asm__ __volatile__ ("" : "+m" (flag));
flag = 1;
}
[Bug c++/107622] Missing optimization of switch-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622 --- Comment #6 from Wilhelm M --- (In reply to Richard Biener from comment #5) > Did you try -fstrict-enums? Yes, that doesn't change anything.
[Bug c++/107622] Missing optimization of switch-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622
--- Comment #4 from Wilhelm M ---
In the following class the static data member is accessible via explicit
template instantiation from the outside. So the compiler cannot reason that the
value is in [0,2]. But this does not hold for the function g(): here mState2 is
definitely not accessible from outside. But here the std::unreachable() is
still neccessary. here the optimization is missing.
struct FSM {
enum class State : uint8_t {A, B, C};
static void f() {
switch(mState) {
case State::A:
o = 10;
break;
case State::B:
o = 11;
break;
case State::C:
o = 12;
break;
default:
//std::unreachable();
break;
}
}
static void g() {
static State mState2{State::A}; // not accessible from outside
switch(mState2) {
case State::A:
o = 10;
break;
case State::B:
o = 11;
break;
case State::C:
o = 12;
break;
default:
//std::unreachable();
break;
}
}
private:
inline static State mState{State::A}; // still modifyable via explicit
template instantiation
};
[Bug c++/107622] Missing optimization of switch-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622 --- Comment #3 from Wilhelm M --- (In reply to Andrew Pinski from comment #1) > > In the following example the default-case > > Yes it can. You can pass a 0xf to that function and still have well defined > behavior. Oh yes, thank you for the hint!
[Bug c++/107622] New: Missing optimization of switch-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622
Bug ID: 107622
Summary: Missing optimization of switch-statement
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
In the following example the default-case could not be reached. Therefore
introducing std::unreachable() should be useless. But the compiler produces
slightly better code with std::unreachable() as it removes one (unneccessary)
comparison (tested for x86 and avr targets).
volatile uint8_t o;
enum class State : uint8_t {A, B, C};
void g(const State s) {
switch(s) {
case State::A:
o = 10;
break;
case State::B:
o = 11;
break;
case State::C:
o = 12;
break;
default:
//std::unreachable(); // __builtin_unreachable();
break;
}
}
[Bug c++/106997] Use coroutines on avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106997 --- Comment #2 from Wilhelm M --- I would consider this a missed optimization rather than a bug, because the standard says, that an implementation can avoid heap allocation if: - the lifetime of the coroutine is strictly within the lifetime of the caller - the size of coroutine state can be determined at compile time The case I tested falls within the above statement.
[Bug c++/106997] New: Use coroutines on avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106997 Bug ID: 106997 Summary: Use coroutines on avr-gcc Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: klaus.doldinger64 at googlemail dot com Target Milestone: --- I tried to use coroutines with avr-gcc (13.0.0) for the AVR target. I managed to include the coroutine-header and to write a very simple generator using the example from cppreference. It compiles well, but then I get undefined symbols: 1) new and delete operator-functions 2) f(f()::f().Frame*) Therefore two question arise here: a) is it possible to use coroutines without head-allocation? E.g. define some global storage for the state of the coroutine? b) if a) can be fullfilled, what is 2) supposed to do?
[Bug c++/105774] Bogus overflow in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105774 --- Comment #1 from Wilhelm M --- To make it more clear make the type of x *signed char`.
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #4 from Wilhelm M ---
The strange thing is, that it depends on how the assignment is written:
#include
int main() {
GPIOR0 = 0x01; // no warning
(*(volatile uint8_t *)(0x001C)) = 0x01; // warning
}
The cpp replaces the GPIOR0 access to essentially the same line as the
following line, where the warning occures.
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523 --- Comment #3 from Wilhelm M --- This bug is still in version 13.0.0
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523 --- Comment #2 from Wilhelm M --- Setting --param=min-pagesize=0 on the commandline does the trick. But I think this should be set generally for avr target
[Bug c++/105523] New: Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Bug ID: 105523
Summary: Wrong warning array subscript [0] is outside array
bounds
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
The following code produces the above mentined wrong warning:
#include
int main() {
const auto ptr2 = reinterpret_cast(0x0030);
*ptr2 = 0xd8;
}
Up to avr-g++-11.3.1 there was no warning in above code.
[Bug libstdc++/93121] std::bit_cast missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121
--- Comment #12 from Wilhelm M ---
The following does not work:
# include
# include
# include
# include
# include
using to_t = std::array;
int main() {
constexpr std::byte from1[4]{};
constexpr auto v1 = std::bit_cast(from1);
return v1[0];
}
gives:
/usr/local/include/c++/11.0.0/bit: In function 'int main()':
/home/lmeier/Projekte/wmucpp/host/test88.cc:11:50: in 'constexpr' expansion
of 'std::bit_cast, std::byte [4]>(from1)'
/usr/local/include/c++/11.0.0/bit:60:33: sorry, unimplemented:
'__builtin_bit_cast' cannot be constant evaluated because the argument cannot
be encoded
60 | return __builtin_bit_cast(_To, __from);
| ^~~
[Bug c++/93389] New: Failure to detect UB in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93389
Bug ID: 93389
Summary: Failure to detect UB in constexpr context
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
The following test as IIFE should be detected as UB, but it isn't:
constexpr auto test3 = []{
int* p{};
{
int x{};
p =
}
return *p; // should be UB, but isn't detected
}(); // IIFE
int main() {}
[Bug c++/93121] New: std::bit_cast missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121 Bug ID: 93121 Summary: std::bit_cast missing Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: klaus.doldinger64 at googlemail dot com Target Milestone: --- Until now, no std::bit_cast is available in gcc-trunk w/ c++2a.
[Bug c++/92495] spaceship operator requires public member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92495 --- Comment #6 from Wilhelm M --- That meens, all NNTP of class type have to have all-public data members?
[Bug c++/92495] spaceship operator requires public member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92495 --- Comment #4 from Wilhelm M --- Agreed. But omitting should not trigger ICE.
[Bug c++/92732] New: Bit-field with std::byte as member type cannot be initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92732
Bug ID: 92732
Summary: Bit-field with std::byte as member type cannot be
initialized
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
Since C++20 bit-field initializer are possible.
There seems to be a bug with std::byte an bit-fields.
struct Test {
std::byte a : 2 = std::byte{0}; // NOK
uint8_t b : 2 = 0; // OK
};
Compiling this with
g++ (GCC) 10.0.0 20191128 (experimental)
yields:
test93.cc:20:28: error: cannot convert 'std::byte' to 'unsigned char:2' in
initialization
20 | std::byte a : 2 = std::byte{0}; // NOK
|^~~
||
|std::byte
[Bug c++/92496] New: spaceship operator without include produces ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92496
Bug ID: 92496
Summary: spaceship operator without include produces
ICE
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
Omitting the include in the below example produces ICE
#include // omitting trigger ICE
template
struct A {};
struct B {
inline constexpr auto operator<=>(const B& rhs) const = default;
//private:
int value; // why must this member be public?
};
int main() {
A t;
}
test93.cc: In member function 'constexpr auto B::operator<=>(const B&) const':
test93.cc:7:27: internal compiler error: tree check: expected class 'type',
have 'exceptional' (error_mark) in is_cat, at cp/method.c:999
7 | inline constexpr auto operator<=>(const B& rhs) const = default;
| ^~~~
0x784e45 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9735
0x63398b tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3396
0x63398b is_cat
../../gcc/cp/method.c:999
0x8dd5ab cat_tag_for
../../gcc/cp/method.c:1011
0x8dd5ab common_comparison_type
../../gcc/cp/method.c:1166
0x8dd5ab build_comparison_op
../../gcc/cp/method.c:1341
0x8ddf19 synthesize_method(tree_node*)
../../gcc/cp/method.c:1501
0x82d6b2 check_bases_and_members
../../gcc/cp/class.c:5909
0x82e5d3 finish_struct_1(tree_node*)
../../gcc/cp/class.c:7113
0x8300f4 finish_struct(tree_node*, tree_node*)
../../gcc/cp/class.c:7399
0x90ea44 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23666
0x910981 cp_parser_class_specifier
../../gcc/cp/parser.c:23965
0x910981 cp_parser_type_specifier
../../gcc/cp/parser.c:17566
0x911956 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14239
0x912371 cp_parser_simple_declaration
../../gcc/cp/parser.c:13502
0x9394ca cp_parser_declaration
../../gcc/cp/parser.c:13322
0x939b42 cp_parser_translation_unit
../../gcc/cp/parser.c:4721
0x939b42 c_parse_file()
../../gcc/cp/parser.c:42925
0xa3ce4b c_common_parse_file()
../../gcc/c-family/c-opts.c:1185
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make: *** [: test93.o] Fehler 1
[Bug c++/92495] New: spaceship operator requires public member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92495
Bug ID: 92495
Summary: spaceship operator requires public member
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
The below example only compiles with public member:
#include // omitting trigger ICE
template
struct A {};
struct B {
inline constexpr auto operator<=>(const B& rhs) const = default;
//private:
int value; // why must this member be public?
};
int main() {
A t;
}
[Bug c++/83730] Unnecessary generation of guard variables with -fno-threadsafe-statics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83730
--- Comment #6 from Wilhelm M ---
This is still true for local statics as shown below:
// Test für guard variable
struct A {
inline A(int v = 0) {} // without user-defined ctors, guards are omitted
int m1() const {
return m;
}
private:
int m = 0;
};
//namespace { // without anon-ns guards, are generated
template
struct X {
static int foo() {
static T m; // even as local-static and -fno-threadsafe-statics,
guards are generated
return m.m1();
}
//inline static T m;
};
//}
int main() {
return X::foo();
}
[Bug c++/83730] Unnecessary generation of guard variables with -fno-threadsafe-statics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83730
--- Comment #5 from Wilhelm M ---
Only for completeness: if you write the following, no guards are produced:
struct A {
A() = default; // if commented out, no guards are allocated
void foo() {}
};
template
struct B {
static void foo() {
mTop.foo();
}
inline static T mTop{};
};
int main() {
B::foo();
}
So the c++14 an c++17 variants produce the same guards if
default-initialization is used. But produce no guards if value-initialization
ist used or the defaulted ctor is removed. Thats strange ...
[Bug c++/83730] Unnecessary generation of guard variables with -fno-threadsafe-statics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83730
Wilhelm M changed:
What|Removed |Added
Keywords|wrong-code |
--- Comment #4 from Wilhelm M ---
If you change the example as below, you still get guards.
struct A {
A() = default;
void foo() {}
};
template
struct B {
static void foo() {
mTop.foo();
}
static T mTop;
};
template T B::mTop; // change
int main() {
B::foo();
}
[Bug c++/83730] Unnecessary generation of guard variables with -fno-threadsafe-statics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83730 --- Comment #2 from Wilhelm M --- Additionally: if one only uses a global variable of type A, no guards are creates at all. But this should be conceptually equivalent to the above use case.
[Bug c++/83730] Unnecessary generation of guard variables with -fno-threadsafe-statics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83730 --- Comment #1 from Wilhelm M --- If the defaulted ctor is commented out, the guards aren't generated. Still is even stranger ...
[Bug c++/83730] New: Unnecessary generation of guard variables with -fno-threadsafe-statics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83730
Bug ID: 83730
Summary: Unnecessary generation of guard variables with
-fno-threadsafe-statics
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
Compiling the following example using -fno-threadsafe-statics and -Os still
generates the guard-variables for the member mTop. This is unnecessary and
occupies 8 Bytes on an avr target.
struct A {
A() = default; // if commented out, no guards are allocated
void foo() {}
};
template
struct B {
static void foo() {
mTop.foo();
}
inline static T mTop;
};
int main() {
B::foo();
}
[Bug c++/83484] constexpr not evaluated at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83484
klaus.doldinger64 at googlemail dot com changed:
What|Removed |Added
CC||klaus.doldinger64@googlemai
||l.com
--- Comment #3 from klaus.doldinger64 at googlemail dot com ---
Here ist a simplified version of a MCVE:
template
struct X {
static constexpr int x = 0;
static constexpr int y = 1;
};
template<>
constexpr int X<1>::x = 2; // should be ok, but gives duplicate initialization
error
template<>
constexpr int X<1>::y; // should be ill-formed (constexpr must be initialized),
but gives undefined reference
int main() {
return X<1>::x + X<1>::y;
}
