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
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
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:
> >
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
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
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
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
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 > >]':
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
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
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
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];
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
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.
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
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
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
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++
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
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++
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
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
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
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);
38 matches
Mail list logo
