Assignee: unassigned at gcc dot gnu.org
Reporter: rsaxvc at gmail dot com
Target Milestone: ---
On GCC 12.2.0, -O2 -Wall -Wextra, the following code:
#include
__attribute__ ((noinline)) uint32_t callee(uint32_t x, uint16_t y){
return x + y
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/
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsaxvc at gmail dot com
Target Milestone: ---
On GCC 12.2.0, -O2 -Wall -Wextra, the following code:
#include
__attribute__ ((noinline)) uint32_t callee(uint32_t x, uint16_t y
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
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rsaxvc at gmail dot com
Target Milestone: ---
The following snippet is from a now deleted stack-overflow question. When
compiled with G++ 14.1 on a 64-bit target, "g++ main.cpp -o test
-Wstrict-overflow=5 -Werro
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.
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rsaxvc at gmail dot com
Target Milestone: ---
deprecated-enum-enum-conversion warnings apply to C code compiled by G++,
should they? I'm assuming if this code would not tr
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 exten
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsaxvc at gmail dot com
Target Milestone: ---
GCC for ARM 13.2.0(-Os, -mthumb) is missing a minor optimization when loading
from a sub-word sized volatile global
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
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 d
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
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
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsaxvc at gmail dot com
Target Milestone: ---
Target: arm
The following test function compiles into a call to __aeabi_uldivmod, even
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55584
Bug #: 55584
Summary: __sync_fetch_and_* friends do not issue warnings when
CPU does not support them natively
Classification: Unclassified
Product: gcc
Version: 4.7.2
15 matches
Mail list logo
