https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115419
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115419
Bug ID: 115419
Summary: [avr] IEEE double round-to-nearest should go to even
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307
Georg-Johann Lay changed:
What|Removed |Added
Priority|P4 |P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115317
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115317
Bug ID: 115317
Summary: [avr] isinf should return -1 for -Inf
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307
--- Comment #5 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #1)
> The issue is that we probably fold isinff early. On x86 I see already in
> .original:
>
> return !(ABS_EXPR u<=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115311
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307
--- Comment #4 from Georg-Johann Lay ---
The isinf part is fixied in v14.2+, but there is also isnan etc. which don't
currently habe an optabs entry, so defining a failing expander won't work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115311
Bug ID: 115311
Summary: -fno-builtin-xxx allowing anything for xxx
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307
Bug ID: 115307
Summary: [avr] Don't expand isinf() like a built-in
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114981
Bug ID: 114981
Summary: [avr] Improve powi implementation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
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|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114975
Bug ID: 114975
Summary: [AVR] Using popcounthi2 for 8-bit values despit
popcountqi2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114794
Bug ID: 114794
Summary: [avr] Speed up udivmodqi4
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
Bug ID: 114779
Summary: __builtin_constant_p does not work in inline functions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114752
Bug ID: 114752
Summary: AVR: internal compiler error. Unknown mode:
const_double:DF
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: minor
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
Bug ID: 114252
Summary: Introducing bswapsi reduces code performance
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114243
Bug ID: 114243
Summary: -fsplit-wide-types bloats code by more than 50%
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114208
Bug ID: 114208
Summary: DSE deletes a store that is not dead
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114191
Bug ID: 114191
Summary: Flags "Warning" and "Target" don't mix well in
target.opt files
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114132
Bug ID: 114132
Summary: [avr] Code sets up a frame pointer without need
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114111
Bug ID: 114111
Summary: [avr] Expensive code instead of conditional branch.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114100
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |14.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114100
Bug ID: 114100
Summary: [avr] Inefficient indirect addressing on Reduced Tiny
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113974
Bug ID: 113974
Summary: Attribute common ignored
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113927
Bug ID: 113927
Summary: [avr-tiny] Sets up a stack-frame even for trivial code
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113824
Bug ID: 113824
Summary: AVR: ATA5795 in wrong multilib set
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113601
Bug ID: 113601
Summary: avr: Wrong SRAM start for ATmega3208 and ATmega3209
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113481
Bug ID: 113481
Summary: avr: internal compiler error in decompose, at
rtl.h:2298
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113480
Bug ID: 113480
Summary: avr: internal compiler error: in add_dwarf_attr, at
dwarf2out.cc:4503
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113399
Bug ID: 113399
Summary: -ffold-mem-offsets should not be a target option
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113387
Bug ID: 113387
Summary: __attribute__ does not mix with [[gnu:]]
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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
1 - 100 of 234 matches
Mail list logo
