https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118554
--- Comment #2 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #1)
> That already is handled by the inline keyword.
> so `__asm inline("" : "+r" (var));`
But that's /only/ for inlining, where a "minimal" size is assumed -- what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56479
Georg-Johann Lay changed:
What|Removed |Added
Summary|Register allocator can't|[lra][avr] Register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117546
--- Comment #16 from Georg-Johann Lay ---
Ok. Thanks for the pointer (though int32plus should be enough).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118591
--- Comment #3 from Georg-Johann Lay ---
Created attachment 60238
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60238&action=edit
C99 test case that fails on ordinary AVRs (not avrtiny)
This test case fails on ordinary AVRs like -mmcu=at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118591
--- Comment #2 from Georg-Johann Lay ---
(In reply to Georg-Johann Lay from comment #1)
> Created attachment 60230 [details]
> reduced C99 test case
In that test case:
__attribute__((noipa))
void func2 (long a, long b)
{
static unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118591
Bug ID: 118591
Summary: [lra][avr] Wrong code with -mlra in pr43879-3.c
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #17 from Georg-Johann Lay ---
(In reply to GCC Commits from comment #16)
> AVR: PR118012 - Try to work around sick code from match.pd.
The patch above just tries to work around PR118012 / PR118360. It is by no
means a proper fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118360
--- Comment #5 from Georg-Johann Lay ---
(In reply to GCC Commits from comment #4)
> AVR: PR118012 - Try to work around sick code from match.pd.
The patch above just tries to work around PR118012 / PR118360. It is by no
means a proper fix,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118591
--- Comment #1 from Georg-Johann Lay ---
Created attachment 60230
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60230&action=edit
reduced C99 test case
Here is a reduced test case that fails with -mlra -mmcu=attiny40 for any
optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117546
--- Comment #14 from Georg-Johann Lay ---
(In reply to GCC Commits from comment #12)
> * gcc.dg/torture/pr117546.c: New test.
That test fails on AVR. Does it assume that int is a 32-bit type or what?
Unfortunately the test is just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #19 from Georg-Johann Lay ---
(In reply to Segher Boessenkool from comment #18)
> A single insn (always 4 bytes) is too much?!?
Maybe a small test case might help to show the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118360
--- Comment #3 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #2)
> Zeroone*b could be expanded also as zeroone?b:0.
Though that's only half of the story and would
x = zeroone ? b : 0;
c ^= x;
instead of
if (zeroone & 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118329
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|15.0|14.3
--- Comment #14 from Georg-Joha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118329
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118591
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118806
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118878
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118878
Bug ID: 118878
Summary: [ice][avr] internal compiler error: in avr_out_plus_1,
at config/avr/avr.cc:8801
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118878
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118880
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2025-02-15
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118889
Bug ID: 118889
Summary: attribute "common" ignored with -fdata-sections
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118880
Georg-Johann Lay changed:
What|Removed |Added
Keywords|documentation, needs-source |missed-optimization
Resoluti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
Georg-Johann Lay changed:
What|Removed |Added
CC||ul...@t-online.de
--- Comment #7 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
--- Comment #8 from Georg-Johann Lay ---
See https://sourceware.org/bugzilla/show_bug.cgi?id=32704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118880
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118889
--- Comment #2 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #1)
> I think variables with 'static' linkage cannot be 'common'?
Shouldn't they go into .lcomm, i.e. lcomm_section?
What I am trying to achieve is to implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
--- Comment #9 from Georg-Johann Lay ---
What can be used as a kind of work-around (and may be even better than the code
with improved Binutils as proposed above), is to hide the value of 0 from the
compiler:
volatile uint8_t var;
__attribute(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #21 from Georg-Johann Lay ---
Back then, the patch has been reopened so it won't be forgotten for
backporting.
https://gcc.gnu.org/pipermail/gcc/2024-February/243300.html
As is seems, no backport will happen?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118889
--- Comment #4 from Georg-Johann Lay ---
(In reply to rguent...@suse.de from comment #3)
> On Mon, 17 Feb 2025, gjl at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118889
> > --- Comment #2 from Georg-Johann Lay ---
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118889
--- Comment #5 from Georg-Johann Lay ---
...the respective part of varasm.cc reads:
get_variable_section (tree decl, bool prefer_noswitch_p)
{
...
if (ADDR_SPACE_GENERIC_P (as)
&& !DECL_THREAD_LOCAL_P (decl)
&& !DECL_NOINIT_P (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119077
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2025-03-02
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119086
Bug ID: 119086
Summary: __builtin_constant_p is missing opportunities
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119086
--- Comment #3 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #2)
> See pr 26724 and others.
>
> *** This bug has been marked as a duplicate of bug 26724 ***
Thanks for the pointer. Would you explain how that can be used for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119077
--- Comment #6 from Georg-Johann Lay ---
Still 2 issues:
* Your are configuring the compiler in a way not supported by GCC (see my note
above).
* Pre-processed files are still missing. You can get the i files with
-save-temps -g3.
With -g3, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119077
--- Comment #7 from Georg-Johann Lay ---
...I can reproduce it with the following test case and v13:
#include
extern void __builtin_avr_delay_cycles (uint32_t);
#include
int main(void)
{
_delay_ms(100);
}
So the likely cause is that A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119225
--- Comment #1 from Georg-Johann Lay ---
This is a texinfo bug that has been fixed.
Please leave the anchors where they are, they are correct and external links
rely on them.
See also https://lists.gnu.org/archive/html/help-texinfo/2024-03/msg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119225
--- Comment #2 from Georg-Johann Lay ---
This is the texinfo commit that fixed the issue:
https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=f536711c6286a974798affb366d1ba0cc72fa16e
501 - 538 of 538 matches
Mail list logo
