User account creation filtered due to spam.

Bug 26883 - ICE when assigning memory attribute to class with simple constructor
Summary: ICE when assigning memory attribute to class with simple constructor
Status: RESOLVED DUPLICATE of bug 44643
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.0.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2006-03-27 07:31 UTC by Ned Konz
Modified: 2011-06-16 17:24 UTC (History)
3 users (show)

See Also:
Host:
Target: avr-unknown-none
Build:
Known to work:
Known to fail: 4.0.2
Last reconfirmed: 2006-04-30 04:23:30


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ned Konz 2006-03-27 07:31:46 UTC
The following (perhaps questionable) code causes an ICE in in set_mem_attributes_minus_bitpos, at emit-rtl.c:1539

compile command line:
avr-g++ -mmcu=atmega128 -c -o romproblems.o romproblems.cpp

program:

#define PROGMEM __attribute__((__progmem__))

struct ROMVar1
{
    int const val;
    ROMVar1(int const& init) : val(init) { }
};

ROMVar1 PROGMEM rv1b(123);
Comment 1 Richard Biener 2006-03-27 08:09:40 UTC
We ICE in

      if (base && DECL_P (base)
          && TREE_READONLY (base)
          && (TREE_STATIC (base) || DECL_EXTERNAL (base)))
        {
          tree base_type = TREE_TYPE (base);
          gcc_assert (!(base_type && TYPE_NEEDS_CONSTRUCTING (base_type))
                      || DECL_ARTIFICIAL (base));
          MEM_READONLY_P (ref) = 1;

Now, it is indeed questionable to put a non-POD into ro memory.  So I think
this is INVALID - but let's see what others think.
Comment 2 Andrew Pinski 2006-03-27 08:12:48 UTC
(In reply to comment #1)
> We ICE in
> Now, it is indeed questionable to put a non-POD into ro memory.  So I think
> this is INVALID - but let's see what others think.

The target should have rejected progmem and not placed const on the decl.
Comment 3 Georg-Johann Lay 2011-06-16 17:24:03 UTC
This is similar to PR44643. avr backend now rejects such code with an error instead of trying to set TREE_READONLY when not appropriate.

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