https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115065
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P5
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115065
--- Comment #1 from Georg-Johann Lay ---
IIUC, this is just about the timing of a branch, which in the general != 0 is
currently taken (takes 2 ticks), but it's better to only take it in the
non-common (= 0) case? So that the common case falls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|10.5|12.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115084
--- Comment #3 from Georg-Johann Lay ---
I don't see what the avr backend can do about it; it's rather a middle-end
thing. And the middle-end would have to know that there is a 24-bit integral
mode in the backend and that its division is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114981
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114975
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|15.0|14.2
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114975
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114981
--- Comment #1 from Georg-Johann Lay ---
(In reply to Georg-Johann Lay from comment #0)
> ... due to PR11093 ...
PR110093
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
powif() and powi() can be improved in functionality
* __powisf2 is in open coded C, which bloats due to PR11093 or PR114243 or
similar register allocation flaws.
* __powidf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114835
--- Comment #3 from Georg-Johann Lay ---
(In reply to Wolfgang Hospital from comment #0)
> When establishing the "popcount" of an uint8_t, I've seen GCC to widen the
> value to "half int" and use __popcountqi2 twice.
This is a different issue,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114835
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
C test case
typedef __UINT8_TYPE__ uint8_t;
uint8_t use_pop (uint8_t x)
{
return __builtin_popcount (x);
}
compiles with
$ avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606
--- Comment #36 from Georg-Johann Lay ---
Installed a work-around for v14.2+, v13.3+ and v12.4+
The work-around can be reverted once a proper fix like PR92932 is available.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114794
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114794
Georg-Johann Lay changed:
What|Removed |Added
Keywords||missed-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
udivmodqi4 is slower than it could be.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
Georg-Johann Lay changed:
What|Removed |Added
Keywords||documentation
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #9 from Georg-Johann Lay ---
When this PR won't be fixed, then maybe at least the documentation could
clarify how to port macros to inline functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #6 from Georg-Johann Lay ---
Recognizing more __builtin_constant_p situations is a good thing, IMO.
It would allow to transition from macros to inline functions in such
situations, for example in inline asm that has extra opcodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #4 from Georg-Johann Lay ---
As far as I understand, & SFR has no side effects.
But when it is used as argument to an (inline) function, then it does have side
effects?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #2 from Georg-Johann Lay ---
Notice that when is used directly in __builtin_constant_p without an
inline function, then the code works as expected:
int main (void)
{
if (__builtin_constant_p (& SFR))
__asm (".warning
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Take the following C test case with a special function register (SFR)
definition at a constant address:
#define SFR (*(volatile int*) 0x100)
static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114752
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |13.3
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114752
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P5
Keywords|
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Inline asm does not accept 64-bit float constants:
void func (void)
{
__asm ("; %0" :: "EF" (1.0L));
}
foo.c: In fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #14 from Georg-Johann Lay ---
The code in the example is not a perfect bswap, it needs additional shuffling
of bytes. The tree passes must know that bswap is not a perfect fit. There
must be *some* criterion that depends on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #12 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #10)
> I think the target controls the "libcall" ABI that's used for calls to
> libgcc,
You have a pointer how to do it or an example? IIRC I looked into it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #9 from Georg-Johann Lay ---
...and I don't see why a register allocator would or should fix flaws from tree
optimizers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #8 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #7)
> Note I do understand what you are saying, just the middle-end in detecting
> and using __builtin_bswap32 does what it does everywhere else - it checks
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #5 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #4)
> So bswap on a value is just register shuffling, right?
The point is that there is no need for bswap in the first place, just have a
look at the code that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #3 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #1)
> but somehow we end up doing a libcall?
It's not a libcall in the GCC sense, for the compiler it's just an ordinary
insn. The backend then prints this as a
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Created attachment 57628
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57628=edit
GNU-C test case
typedef __UINT8_TYPE__ uint8_t;
typedef __UINT32_TYP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81473
--- Comment #4 from Georg-Johann Lay ---
This was fixed long ago.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114243
--- Comment #1 from Georg-Johann Lay ---
May be related to PR110093. As Vladimir noted in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093#c5
the problem is that data flow analysis cannot cope with the subregs generated
from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
--- Comment #24 from Georg-Johann Lay ---
(In reply to Georg-Johann Lay from comment #23)
> As it appears, this bug is not fixed completely. For the -mmcu=avrtiny
> architecture, there is still bloat for even the smallest test cases like:
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Created attachment 57616
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57616=edit
pi-sigma.c: C99 test case
Compile the attached test case with:
$ avr-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114208
--- Comment #5 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #4)
> Did it ever work?
No. I allowed -mfuse-add=3 to reproduce this PR because there seems to be a
problem with DSE, and for the case that someone is going to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114191
--- Comment #3 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #1)
> How did you specify 'Target'?
Like:
Wmisspelled-isr
Target Warning C C++ Var(avr_warn_misspelled_isr) Init(1)
Warn if the ISR is misspelled, ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114191
--- Comment #2 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #1)
> Wmisspelled-isr
> Target C C++ Var(avr_warn_misspelled_isr) Init(1)
> Warn if the ISR is misspelled, ...
>
> should eventually work?
With that, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114208
--- Comment #3 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #1)
> I wonder if this is related to r14-6674-g4759383245ac97 .
Seems unrelated: When I reverse-apply r14-6674 then the issue does not go away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114208
--- Comment #2 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #1)
> I wonder if this is related to r14-6674-g4759383245ac97 .
Not unlikely. PR112525 tries to eliminate dead stores for arguments that are
passed. It seems
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Created attachment 57594
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57594=edit
Reduced C test case
$ avr-gcc -mmcu=attiny40 bug-dse.c -S -Os -dp -mfuse-add=3 -f
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
In an .opt file, a backend can define target-specific diagnostic options, for
example gcc/config/avr/avr.opt h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114100
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114132
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114132
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |14.0
Priority|P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
$ avr-gcc -S -Os -mmcu=attiny40
of
void funcab_c (long x, char c) {
}
sets up a frame-pointer without need.
Arguments x and c occupy all of the argument registers R25
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Created attachment 57541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57541=edit
addcc.c: C test case
Compile the code with avr-gcc -S -Os -dp:
int add_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114100
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |14.0
Priority|P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
The Reduced Tiny core does not support indirect addressing with offset, which
basically means that every indirect memory access with a size of more than one
byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97276
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2024-02-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113974
--- Comment #3 from Georg-Johann Lay ---
Then the documentation should make that clear that with -fno-data-sections the
object goes in COMM, but with -fdata-sections it does not and the attribute
"common" is ignored.
Better still, the compiler
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
__attribute__((common,used))
static int cc;
when this code is compiled with -S -fdata-sections then cc is not put into
.lcomm (and is not .local .comm either):
.section.bss.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
--- Comment #1 from Georg-Johann Lay ---
What's the LRA way to do LEGITIMIZE_RELOAD_ADDRESS?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113927
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Code like
char func (char c)
{
return c;
}
compiles as expected to
func:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |13.3
--- Comment #37 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Georg-Johann Lay changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113824
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113824
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
This device is currently filed in avr5, where according to
https://github.com/avrdudes/avr-libc/issues/874#issuecomment-1933051758 is
should be in avr4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944
--- Comment #3 from Georg-Johann Lay ---
See also the GCC v14 Release Notes:
https://gcc.gnu.org/gcc-14/changes.html#avr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113601
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113601
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Priority|P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
ATmega3208/9 have SRAM from 0x3000 to 0x3fff, which is 4KiB.
The hardware description in avr-mcus.def uses a start at 0x3800, which is not
correct. This leads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113481
--- Comment #6 from Georg-Johann Lay ---
This is as simple as it gets:
void Afun5 (__uint24 num)
{
__asm volatile ("" :: "r" (num));
}
void func (void)
{
Afun5 (0xcc);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113481
--- Comment #5 from Georg-Johann Lay ---
Here is a somewhat reduced test:
/* { dg-do run } */
/* { dg-options "-g -O2" } */
typedef __UINT8_TYPE__ uint8_t;
typedef __uint24 uint24_t;
#define BBB 23
#define INC 1
#define VAL 0xcc
uint8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113481
--- Comment #4 from Georg-Johann Lay ---
What's strange is that it only occurs with -g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113481
--- Comment #2 from Georg-Johann Lay ---
It does not occur with avr-gcc-v13 -fchecking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113480
--- Comment #3 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #2)
> Does it fail with GCC 13 as well (if you add -fchecking)?
Yes. And it goes away without -g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113481
Georg-Johann Lay changed:
What|Removed |Added
Summary|avr: internal compiler |[14 Regession] avr:
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Created attachment 57139
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57139=edit
C test case from gcc.target/avr/torture
I see this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113480
--- Comment #1 from Georg-Johann Lay ---
The ICE actially goes away when I remove the __flash from the test case posted
in comment #0.
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
This is a relatively new ICE that I see on the avr target.
Compliled with "version 14.0.1 20240118 (experimental) (avr)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56442
--- Comment #4 from Georg-Johann Lay ---
Maybe this is similar to PR101188.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113156
--- Comment #17 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #11)
> The patch is semi-correct
Would you detail on this? What parts for a complete fix are (still) missing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107201
--- Comment #6 from Georg-Johann Lay ---
As a work around, one can use an adjusted device-specs file with the
avrlibc_devicelib removed. The spec looks like this:
*avrlibc_devicelib:
%{!nodevicelib:-lavr128da32}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107201
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113156
Georg-Johann Lay changed:
What|Removed |Added
Keywords||opt-attribute
--- Comment #15 from
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
For some reason, -ffold-mem-offsets is a target option and displayed with
--help=target, which it shold not.
> grep -A3 mem-off common.opt
ffold-mem-offsets
Target Bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
The following compiles fine
[[gnu::used]] __attribute__((used)) int x;
while
__attribute__((used)) [[gnu::used]] int x;
bar.c:1:1: warning: 'used' attribute does not apply to types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113156
--- Comment #10 from Georg-Johann Lay ---
-mdouble and -mlong-double are more complicated than other options because they
depend on each other in way that (to my knowledge) cannot be described by
option properties. For example, in
-mdouble=64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113156
--- Comment #8 from Georg-Johann Lay ---
Is there as comprehensible explanation when option property "Save" is needed?
The internals just state
> Build the cl_target_option structure to hold a copy of the option,
> add the functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112952
--- Comment #6 from Georg-Johann Lay ---
Also fixed on the v12 branch for v12.4+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112952
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P5
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102725
--- Comment #12 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #1)
> You need -fno-tree-loop-distribution -fno-tree-loop-distribute-patterns to
> turn it off. There is another older bug about this for memcpy.
This is also a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
--- Comment #7 from Georg-Johann Lay ---
(In reply to Andreas Schwab from comment #6)
> That's what -fno-tree-loop-distribute-patterns is for.
So you know the GCC sources and can draw that conclusion.
The documentation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
--- Comment #5 from Georg-Johann Lay ---
(In reply to Andreas Schwab from comment #4)
> -fno-builtin-strlen has a different purpose.
So then -fno-builtin should also not work? GCC documentation of -fno-builtin is
the same like for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
--- Comment #3 from Georg-Johann Lay ---
(In reply to Mikael Pettersson from comment #2)
> Does -fno-tree-loop-distribute-patterns work? That's been the go-to for
> disabling similar loop-to-call transformations people have been objecting to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
--- Comment #1 from Georg-Johann Lay ---
-fno-builtin works, but that seems too much. -fno-builtin-strlen should switch
it off IMO.
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Compile with -S -Os -fno-builtin-strlen -fno-optimize-strlen
typedef __SIZE_TYPE__ size_t;
size_t strlen (const char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606
--- Comment #28 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #25)
> I wonder if it would be possible to set the appropriate address-space when
> parsing the "progmem" attribute in the target?
No, that's not possible. You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112952
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Known to fail|
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606
--- Comment #24 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #22)
> Should be fixed on trunk. Confirmation would be nice (checked x86 only).
Tested with: gcc version 14.0.0 20231210 (experimental) (GCC)
Still fails for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944
Georg-Johann Lay changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |gjl at gcc dot gnu.org
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Devices from the AVR64* and AVR128* families (from avrxmega2 and avrxmega4)
see a 32 KiB portion of their program memory in the RAM address space.
Which 32 KiB segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606
--- Comment #23 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #22)
> Should be fixed on trunk. Confirmation would be nice (checked x86 only).
For AVR, this does not fix the attribute progmem case (for which it was
1 - 100 of 1848 matches
Mail list logo
