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
Keywords|missed-opti
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 Georg-Joha
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
Status|UNCONFIRMED
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 to a
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&action=edit
C test case from gcc.target/avr/torture
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 G
: 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 appl
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 cl_target_
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 -ftree-loop-distribut
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 -fno-builtin-
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.
I
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 ca
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 th
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
originall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112830
--- Comment #15 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #13)
> The master branch has been updated by Richard Biener :
>
> https://gcc.gnu.org/g:68d32d02035fc081384ec6d6fd275e49ffa5d016
>
> commit r14-6182-g68d32d0203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112866
--- Comment #1 from Georg-Johann Lay ---
Occurs with all versions that support address-spaces (v4.7 and up).
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Suppose we want to define an array of pointers to some address-space, like in:
#define FSTR(X) ((const __flash char[]) { X })
const __flash char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112830
--- Comment #9 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #8)
> Is there a valid testcase that has __memx as the destination? Or is there
> an address space with similar constraints that allows non-const accesses?
No.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112830
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Keywords|
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Compile the following C test case with avr-gcc -S:
typedef __SIZE_TYPE__ size_t;
void copy_n (void *vdst, const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772
Bug 86772 depends on bug 86776, which changed state.
Bug 86776 Summary: Avr port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86776
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86776
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53372
Georg-Johann Lay changed:
What|Removed |Added
Keywords||addr-space
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50755
--- Comment #5 from Georg-Johann Lay ---
(In reply to Roger Sayle from comment #4)
> This appears to be fixed on mainline.
At least the test case passes on newer versions. For a definite answer you'd
have to bisect / find the patch that solved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639
--- Comment #6 from Georg-Johann Lay ---
May I ask, are you working on getting libstdc++ to work for avr?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639
--- Comment #4 from Georg-Johann Lay ---
(In reply to Jonathan Wakely from comment #3)
> Which versions of avr-libc are supported with gcc?
The versions are only very loosely coupled. Anything from AVR-LibC v1.8 on (or
maybe even older) should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639
--- Comment #2 from Georg-Johann Lay ---
(In reply to Jonathan Wakely from comment #0)
> The in avr-libc does things like this:
>
> extern double acos(double __x) __ATTR_CONST__;
> #define acosf acos/**< The alias for acos().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093
--- Comment #4 from Georg-Johann Lay ---
(In reply to Vladimir Makarov from comment #3)
> I propose to avoid the above RTL code by switching off subreg3
> pass (or -fsplit-wide-types) for AVR by default as it was for gcc-8.
Thanks for looking i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093
--- Comment #2 from Georg-Johann Lay ---
Meanwhile (2023-08-22) the generated code from above got worse once again and
even pops a frame:
long add (long aa, long bb, long cc)
{
if (cc < 0)
return aa - cc;
return aa + bb;
}
> av
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 105523, which changed state.
Bug 105523 Summary: Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109910
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2023-08-04
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53935
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96055
Georg-Johann Lay changed:
What|Removed |Added
Known to work||12.1.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #34 from Georg-Johann Lay ---
@Senthil: Can this PR be closed? Or will it be backported?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110220
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110217
--- Comment #4 from Georg-Johann Lay ---
At least CLI / SBI won't glitch at O0, same for ATOMIC_BLOCK.
For SBI et al. you are right, they rely on insn combine. The right approach
would have been compiler built-ins or API using inline asm. But t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110217
--- Comment #3 from Georg-Johann Lay ---
At least CLI / SBI won't glitch at O0, same for ATOMIC_BLOCK.
For SBI et al. you are right, they rely on insn combine. The right approach
would have been compiler built-ins or API using inline asm. But t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110217
Georg-Johann Lay changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Geor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110220
Georg-Johann Lay changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #17 from Georg-Johann Lay ---
Created attachment 55318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55318&action=edit
Reduced patch for v8 (handles only CLOBBERs, hence should be good enough for
AVR).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #16 from Georg-Johann Lay ---
Created attachment 55317
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55317&action=edit
Backport to v13 of Jeff's patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093
Georg-Johann Lay changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109650
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109650
Georg-Johann Lay changed:
What|Removed |Added
CC|saaadhu at gcc dot gnu.org |
--- Comment #13 from Georg-J
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
So here is a C test case:
long add (long aa, long bb, long cc)
{
if (cc < 0)
return aa - cc;
return aa +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #13 from Georg-Johann Lay ---
(In reply to Ulrich Weigand from comment #12)
> I think your root cause analysis is correct. In this part of code:
>
> if (success)
> delete_insn (insn);
> c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110088
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110088
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Keywords|
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
The register allocator might generate code that moves a value from a d-reg to
an l-reg, and then performs operation like PLUS, IOR, AND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
--- Comment #18 from Georg-Johann Lay ---
(In reply to Francois-Xavier Coudert from comment #11)
> As far as I can say, the targets with this problem are: avr, bfin, h8300,
> picochip and sh (for some subtargets of sh).
>
> On avr, bfin, h8300 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27663
--- Comment #11 from Georg-Johann Lay ---
(In reply to Georg-Johann Lay from comment #10)
> bswap recognition appears to have improved since then [...]
Closed thusly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27663
Georg-Johann Lay changed:
What|Removed |Added
Known to work||14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #11 from Georg-Johann Lay ---
Created attachment 55217
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55217&action=edit
Proposed patch for postreload.cc to record clobbers of next insn + test case.
This patch solves the proble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #10 from Georg-Johann Lay ---
Created attachment 55189
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55189&action=edit
Proposed patch for postreload.cc so analysis is not bypassing "next" insn.
(In reply to Georg-Johann Lay f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #9 from Georg-Johann Lay ---
The bug works as follows:
postreload.cc::reload_cse_move2add() loops over all insns, and at some point it
encounters
(insn 44 14 15 2 (set (reg/f:HI 14 r14 [58])
(reg/v/f:HI 16 r16 [orig:51 self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
Georg-Johann Lay changed:
What|Removed |Added
Status|ASSIGNED|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
Georg-Johann Lay changed:
What|Removed |Added
Assignee|gjl at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99435
Georg-Johann Lay changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009
--- Comment #1 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #0)
> unsigned
> f1 (int v)
> {
> [...]
> int b_5;
>
> b_5 = v>>(sizeof(v)*8 - 1);
Does it depend on -fwrapv maybe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Georg-Johann Lay changed:
What|Removed |Added
Summary|[AVR] Miscompilation and|[postreload] Uses content
201 - 300 of 1998 matches
Mail list logo
