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
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.
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.
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 ge
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
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:
> > Fo
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
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 vi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66511
Wilhelm M changed:
What|Removed |Added
CC||klaus.doldinger64@googlemai
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 (th
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 I
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.
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.
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/l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #8 from Wilhelm M ---
Yes. Looks like the patch does its job.
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
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
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(
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 &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54816
Wilhelm M changed:
What|Removed |Added
CC||klaus.doldinger64@googlemai
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.
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;
}
}
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];
v
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
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.
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
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.
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
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
++
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
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
++
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
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`.
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 G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #3 from Wilhelm M ---
This bug is still in version 13.0.0
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
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
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);
++
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 = &x;
}
: 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.
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92495
--- Comment #4 from Wilhelm M ---
Agreed.
But omitting should not trigger ICE.
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
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
++
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<=>(c
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;
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
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 c
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.
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 ...
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83484
klaus.doldinger64 at googlemail dot com changed:
What|Removed |Added
CC
52 matches
Mail list logo
