https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100962
--- Comment #3 from mojo at world3 dot net ---
Apologies, I noticed I had -Og on. Tried with -O3 and it optimised the struct
away. With -O2 it uses the Z register with displacement, reading data from
flash.
So it seems that only -Og produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100962
--- Comment #2 from mojo at world3 dot net ---
avr-gcc-11.1.0-x64-windows>bin\avr-gcc -Og -xc -Wall -mmcu=atxmega64a1u test.c
avr-gcc-11.1.0-x64-windows>bin\avr-objdump -h -S a.out > list.s
Still producing code like this
2de
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mojo at world3 dot net
Target Milestone: ---
Example code here: https://godbolt.org/z/1hnPoGdTd
In this code a const __flash struct holds some data used to initialize
peripherals. Line 59
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79269
--- Comment #2 from mojo at world3 dot net ---
Thanks. __builtin_object_size() works well at runtime and solves me immediate
need, which spurred me to suggest this enhancement.
After giving it some thought I agree with you, I can't see any easy
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mojo at world3 dot net
Target Milestone: ---
As per the C99 standard, GCC treats structs with flexible arrays as if the
array had a size of 0. GCC offers an extension to allow such structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63760
--- Comment #4 from mojo at world3 dot net ---
I agree, a separate __funcP__is the best option.
Assignee: unassigned at gcc dot gnu.org
Reporter: mojo at world3 dot net
The C99 __func__ magic variable is defined as:
static const char __func__[] = function-name;
On architectures such as AVR where there is a distinction between program
memory and RAM this definition is not ideal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63760
--- Comment #2 from mojo at world3 dot net ---
On platforms with this kind of architecture the default is to place everything
in RAM, unless you specifically state otherwise.
With Harvard style architectures different instructions are used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54888
--- Comment #3 from mojo at world3 dot net 2012-10-22 12:40:57 UTC ---
(In reply to comment #2)
And I actually don't understand teh issue: Optimizing for size does not
require
to produce slow code. The code may run fast.
-O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54888
Bug #: 54888
Summary: GCC with -Os is faster than -O3 on some AVR code
Classification: Unclassified
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54888
--- Comment #1 from mojo at world3 dot net 2012-10-10 14:51:26 UTC ---
Created attachment 28412
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28412
Compiler output with -O3
11 matches
Mail list logo
