Bug 113480 - avr: internal compiler error: in add_dwarf_attr, at dwarf2out.cc:4503
Summary: avr: internal compiler error: in add_dwarf_attr, at dwarf2out.cc:4503
Status: RESOLVED DUPLICATE of bug 100530
Alias: None
Product: gcc
Classification: Unclassified
Component: debug (show other bugs)
Version: 14.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-checking, ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2024-01-18 13:35 UTC by Georg-Johann Lay
Modified: 2024-01-18 17:57 UTC (History)
0 users

See Also:
Host:
Target: avr
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Georg-Johann Lay 2024-01-18 13:35:02 UTC
This is a relatively new ICE that I see on the avr target.

Compliled with "version 14.0.1 20240118 (experimental) (avr)"

$ avr-gcc pr83801.c -g -O3 -std=gnu99 -mmcu=atmega128

/* { dg-options { "-std=gnu99" } } */
/* { dg-do run { target { ! avr_tiny } } } */

__attribute((noinline,noclone))
char to_ascii (unsigned i)
{
    static const char __flash code_tab[] = "0123456789";
    return code_tab[i];
}

int main()
{
  if (to_ascii (2) != '2')
    __builtin_abort();

  return 0;
}

I am not sure if it's related to address-spaces, but there are fails that don't have ASes like gcc.target/avr/torture/pr109907-2.c (but that has __int24 though).

Target: avr
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls --with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared --with-fixed-point=no  --with-long-double=64 --enable-languages=c,c++
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240118 (experimental) (GCC)
Comment 1 Georg-Johann Lay 2024-01-18 13:41:09 UTC
The ICE actially goes away when I remove the __flash from the test case posted in comment #0.
Comment 2 Richard Biener 2024-01-18 13:45:30 UTC
This is the assert looking we don't add duplicate attrs, only enabled with -fchecking.  Does it fail with GCC 13 as well (if you add -fchecking)?
Comment 3 Georg-Johann Lay 2024-01-18 13:56:59 UTC
(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.
Comment 4 Richard Biener 2024-01-18 14:23:49 UTC
So it's not clear to when it's a regression (the checking was added with GCC 8).  There might be a duplicate for this bug.
Comment 5 Andrew Pinski 2024-01-18 14:47:57 UTC
Most likely a dup of bug 100530.
Comment 6 Andrew Pinski 2024-01-18 17:57:28 UTC
Yes it is a dup of bug 100530.

*** This bug has been marked as a duplicate of bug 100530 ***