This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Extension compatibility policy

From: "E. Weddington" <ericw at evcohs dot com>
To: Paul Schlie <schlie at comcast dot net>
Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Giovanni Bajo <giovannibajo at libero dot it>,Mike Hearn <mike at navi dot cx>, gcc at gcc dot gnu dot org
Date: Wed, 02 Mar 2005 09:26:40 -0700
Subject: Re: Extension compatibility policy
References: <BE4B4078.94F8%schlie@comcast.net>

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 influenced by the target.

2 - To enable their identification so that their run-time access method may
   be influenced by the target. (Likely due to their storage location/type)

I know that you are doing this for the AVR target.

You are under the assumption that it is acceptable to attach attributes to static constant objects to put data in Program Space for the AVR target.

As Joseph pointed out to you in bug #20258,
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258>
implementing DTR 18037 is the best way to go about this.

You consistently do not check with the official AVR maintainers (Denis Chertykov and Marek Michalkiewicz), or on the avr-gcc-list <http://savannah.nongnu.org/mail/?group=avr> to see if any of this will fly with the rest of the AVR community.

Eric

Follow-Ups:
- Re: Extension compatibility policy
  - From: Paul Schlie

References:
- Re: Extension compatibility policy
  - From: Paul Schlie

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]