avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] gcc4.6 vs avr-libc-1.6.8?


From: dpc
Subject: Re: [avr-libc-dev] gcc4.6 vs avr-libc-1.6.8?
Date: Wed, 23 Jun 2010 09:21:10 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (darwin)

dpc <address@hidden> writes:

> Joerg Wunsch <address@hidden> writes:
>
>> As Weddington, Eric wrote:
>>
>>> I would actually suggest using GCC 4.4.3. It's gotten more testing
>>> than the bleeding edge.
>>
>> Nevertheless, wouldn't an ICE be worth a (GCC) bug report anyway?
>
> this is gcc 44643
>
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44643

jsm28 commented in the bug:

> This is a bug in the AVR back end; if it marks a decl readonly it must
> also adjust the type of the decl.  The problem code is probably in
> avr_insert_attributes.

i think the code jsm28 is referring to in avr_insert_attributes is:

      /* ??? This seems sketchy.  Why can't the user declare the
         thing const in the first place?  */
      TREE_READONLY (node) = 1;

i did a little futzing w/ the type of the decl via TREE_TYPE(node) and
was able to avoid the ice but the comment got me thinking this was
probably not the best thing (plus i had actual work to get back to :-).

anyway, if i go back to libc/stdlib/dtostre.c and change the
str_[nan|inf] decls to be 'const char' (and update s's decl) there's no
more ICE (although, as eric noted gcc trunk is not the recommended
environment and a nicer error message from gcc would be nice).

would a patch like this be ok?

Attachment: foo.patch
Description: Text Data

\p
---
It is always the best policy to tell the truth, unless, of course, you
are an exceptionally good liar. - Jerome K. Jerome

reply via email to

[Prev in Thread] Current Thread [Next in Thread]