> From: "E. Weddington" <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>> After having the chance to experiment a little, it would seem most ideal in
>> the short term to enable GCC to add an explicit target specific attribute to
>> the effective implied __FUNCTION__ declaration; in AVR's case for examp
Paul Schlie wrote:
After having the chance to experiment a little, it would seem most ideal in
the short term to enable GCC to add an explicit target specific attribute to
the effective implied __FUNCTION__ declaration; in AVR's case for example:
#define ROM __attribute__((__progmem__)) /* an avr
> Bernardo Innocenti wrote:
>> Joseph S. Myers wrote:
>>> On Wed, 2 Mar 2005, Bernardo Innocenti wrote:
>>> To move strings into program memory, there's a macro like this:
>>>
>>> #define PSTR(s) ({ static const char __c[] PROGMEM = (s); &__c[0]; })
>>>
>>> But this wouldn't work because __func__ d
Joseph S. Myers wrote:
On Wed, 2 Mar 2005, Bernardo Innocenti wrote:
To move strings into program memory, there's a macro like this:
#define PSTR(s) ({ static const char __c[] PROGMEM = (s); &__c[0]; })
But this wouldn't work because __func__ does not work like
a string literal:
#define TRACEMSG(ms
> From: "E. Weddington" <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>> More specifically, there seem to be two predominant motivating reasons
>> why it may be desired to attach a target specified attributes to compiler
>> generated static constant objects:
>>
>> 1 - To enable their identification so
Paul Schlie wrote:
More specifically, there seem to be two predominant motivating reasons
why it may be desired to attach a target specified attributes to compiler
generated static constant objects:
1 - To enable their identification so that their compile/link time storage
location/type may be i
> From: "Joseph S. Myers" <[EMAIL PROTECTED]>
>> - and used following the above referenced ""Attribute Syntax", as
>> either a variable, or function parameter declaration/implementation:
>>
>> int ROM x = 3;
>>
>> int foo (int ROM y)
>>
>> where the parameter's attribute is
On Tue, 1 Mar 2005, Paul Schlie wrote:
> - an attribute may be defined, such as:
>
> #define ROM __attribute__("ROM");
>
> - and used following the above referenced ""Attribute Syntax", as
> either a variable, or function parameter declaration/implementation:
>
> int ROM x = 3
> From: "Joseph S. Myers" <[EMAIL PROTECTED]>
>> On Tue, 1 Mar 2005, Paul Schlie wrote:
>> Might it be possible to alternatively add an attribute symbol hook so that a
>> target may easily define an arbitrary target specific named attribute which
>> may be utilized without having to patch the parse
On Tue, 1 Mar 2005, Paul Schlie wrote:
> Might it be possible to alternatively add an attribute symbol hook so that a
> target may easily define an arbitrary target specific named attribute which
> may be utilized without having to patch the parser, etc. to do so?
>
> Thereby one could easily def
> Joseph S. Myers writes:
> How about calling decl_attributes from fname_decl so a target
> insert_attributes hook can add attributes to __func__? Would that suffice
> to solve your problem?
Might it be possible to alternatively add an attribute symbol hook so that a
target may easily define an a
On Wed, 2 Mar 2005, Bernardo Innocenti wrote:
> To move strings into program memory, there's a macro like this:
>
> #define PSTR(s) ({ static const char __c[] PROGMEM = (s); &__c[0]; })
>
>
> But this wouldn't work because __func__ does not work like
> a string literal:
>
> #define TRACEMSG(ms
Giovanni Bajo wrote:
Mike Hearn <[EMAIL PROTECTED]> wrote:
In your __FUNCTION__ case, we are basically in the latter group. __FUNCTION__
is a well-documented extension in C90 (it's part of C99 in some form now), and
it was never documented to be a macro. The fact that was named like a macro and
wo
On Mon, Feb 28, 2005 at 09:24:20AM -0500, Robert Dewar wrote:
> Not quite, Marc is suggesting that -pedantic be the default if I read
> the above statement correctly.
Yep.
Except it's probably too late for that, and there is stuff in -pedantic
that is downright obnoxious (because every C compiler
Giovanni Bajo wrote:
Marc Espie <[EMAIL PROTECTED]> wrote:
Personally, I would even say that it would be *great* if gcc would
start warning if you use any extension, unless you explicitly disable
those warnings... (except for __extension__ in header files, and then
I've stumbled upon situations wh
Mike Hearn <[EMAIL PROTECTED]> wrote:
> As recent releases have broken more and more code, I would like to
> understand what GCCs policy on source compatibility is. Sometimes the
> code was buggy, in this particular case GCC simply decided to pull an
> extension it has offered for years. Is it doc
Marc Espie <[EMAIL PROTECTED]> wrote:
> Personally, I would even say that it would be *great* if gcc would
> start warning if you use any extension, unless you explicitly disable
> those warnings... (except for __extension__ in header files, and then
> I've stumbled upon situations where it hurts
On Feb 27, 2005, at 12:56 PM, Mike Hearn wrote:
Are these compatibility patches available in discrete diff form
anywhere?
No.
The branch's name is apple-ppc-branch, and changes are marked
as APPLE LOCAL.
On Sun, 2005-02-27 at 08:21 -0800, Dale Johannesen wrote:
> Current patches of this nature include the inclusion of strict-
> aliasing in -O2, writable strings, and casts as lvalues, and I'm sure
> there are others. (So if you really want any of those, you can pick
> it up from Apple's branch:) I
On Feb 27, 2005, at 6:32 AM, Joseph S. Myers wrote:
And in that case we did consider users: although the concatenation of
__FUNCTION__ wasn't documented, it emitted a deprecation warning in the
3.0, 3.1/3.2 and 3.3 release series before being removed in 3.4.
But, you'll agree that this is an except
On Feb 26, 2005, at 11:40 PM, Eric Botcazou wrote:
Then
somebody notices the breakage and complains about it, and sometimes
even
writes a patch to undo the breakage (typically an Apple employee,
because
Apple is legitimately concerned about backwards compatibility).
Yes. Often what happens is
Joseph S. Myers wrote:
And in that case we did consider users: although the concatenation of
__FUNCTION__ wasn't documented, it emitted a deprecation warning in the
3.0, 3.1/3.2 and 3.3 release series before being removed in 3.4.
Fair enough. I think it is useful to include documentation in a cle
On Sun, 27 Feb 2005, Robert Dewar wrote:
> Joseph S. Myers wrote:
>
> > In the case mentioned of __FUNCTION__ concatenation, (a) __FUNCTION__ was
> > always documented as a variable, so concatentation of it was always
> > undocumented and so liable to removal at any time
>
> Yes, that's a legall
Joseph S. Myers wrote:
In the case mentioned of __FUNCTION__ concatenation, (a) __FUNCTION__ was
always documented as a variable, so concatentation of it was always
undocumented and so liable to removal at any time
Yes, that's a legally sustainable position, just as it would be sustainable
to mak
Long term, gcc extensions mean a given piece of code will only be
compilable by gcc. If the extension is succesful enough, it may
even be adopted by other compilers, such as Intel CC. Happened
in the past.
Personally, I tend to not like gcc extensions. Especially the silent
variety. Now that the C
On Sun, 27 Feb 2005, Eric Botcazou wrote:
> > In cases where breaking sources lets you achieve greater performance or
> > efficiency, please do make the change but offer a switch to disable it and
> > let the old code still compile. This way we it seems everybody can be
> > happy.
>
> My impressi
Eric Botcazou wrote:
Generally speaking, this occurs as follows: a patch happens to break an
extension because GCC has (had?) so many extensions that it is nearly
impossible to foresee all the side-effects a patch will have on them. Then
somebody notices the breakage and complains about it, and
> I understand removing it simplified GCC. That is good. Unfortunately by
> saving work for yourselves you made much more work for many other
> people. I see from Google that Andrew Morton simply used old compilers
> when faced with this problem before.
That's indeed unfortunate and has already be
Hello,
I have just finished fixing up a piece of code dating from around 2001
which was quite badly broken by the incompatible change of __FUNCTION__ to
no longer operate as a preprocessor constant.
Unfortunately this codebase is riddled with constructs like
fatal_error(__FUNCTION__": foo");
29 matches
Mail list logo
