https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116521
Bug ID: 116521
Summary: missing optimization: xtensa tail-call
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116467
--- Comment #2 from rsaxvc at gmail dot com ---
I had wondered about that too but hadn't been able to find anything about it.
User ccrause on esp32.com knew where it was though. From
https://www.cadence.com/content/dam/cadence-www/global/en_US/do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116467
Bug ID: 116467
Summary: missed optimization: zero-extension duplicated on
xtensa
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111933
rsaxvc at gmail dot com changed:
What|Removed |Added
CC||rsaxvc at gmail dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116356
Bug ID: 116356
Summary: signed overflow warning has misplaced line number
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116198
--- Comment #3 from rsaxvc at gmail dot com ---
Thanks, that makes sense. I didn't realize that any code in a header would need
to be able to compile as any language including that header, so we'll need to
fix LVGL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116198
Bug ID: 116198
Summary: Wdeprecated-enum-enum-conversion triggers inside
extern "C"
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53938
--- Comment #6 from rsaxvc at gmail dot com ---
This also impacts Cortex-M0 & M23 on GCC13.2.0, just with the new extension
instructions.
Oddly, when loading a volatile u8 or u16 on Cortex-M3/4/7 does not generate
extra zero extension instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113432
Bug ID: 113432
Summary: missing optimization: GCC UXTB zero-extends result of
LDRB from volatile variables
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106484
--- Comment #5 from rsaxvc at gmail dot com ---
Related ticket requested with Clang:
https://github.com/llvm/llvm-project/issues/63731
latest umulh() function is a little shorter:
static uint64_t umulh(uint64_t a, uint64_t b)
{
const uint32_t a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106484
--- Comment #4 from rsaxvc at gmail dot com ---
Benchmarking shows the speedup to be highly variable depending on CPU core as
well as __aeabi_uldivmod() implementation, and somewhat on numerator.
The best __aeabi_uldivmod()s I've seen do use 32b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106484
--- Comment #3 from rsaxvc at gmail dot com ---
> 32-bit division by constant relies on a 32x32->64 bit multiply.
I believe only the upper half of the bits are required for the product to
represent the integer component of the quotient. This mak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106484
rsaxvc at gmail dot com changed:
What|Removed |Added
CC||rsaxvc at gmail dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106484
Bug ID: 106484
Summary: Failure to optimize uint64_t/constant division on
ARM32
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
14 matches
Mail list logo
