[Bug c/20258] New: error generated for storage class specified for function parameter

[Bug c/20258] New: error generated for storage class specified for function parameter

[schlie at comcast dot net]

Which may not be litterally a bug, but would like to restrict the functions parameter in this way.

Is this possible? (as given the below code example, wan't to be able to identify data stored in
program read-only program ROM as being "static const", which they are, and corespondingly
identify parameters to functions similarly restricted to "static const" data which actually needs
to be accessed via a different load instruction on the avr, do to it's harvard memory architecture.

simple example desired code:

int foo (static const char * s, char v)   /* where s is desired to be restricted to a (static const *) */
{
  return s[v];
}

int main (void)
{
  volatile char v;
  
  static const char s[] = "some string"; /* as s[] is stored in program memory */
  
  return foo (s, v);
}

Where idealy then if GCC can preserve the (static const *) attributes then even such references
within functions should be able to be idententifed during rtl/template matching for code generation
hopefully enabling (static const *) to be dereferenced with differnt load instructions than (const *)?

-- 
           Summary: error generated for storage class specified for function
                    parameter
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: schlie at comcast dot net
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ppc-apple-darwin7.8
  GCC host triplet: ppc-apple-darwin7.8
GCC target triplet: avr-unknown-none


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258

[Bug c/20258] error generated for storage class specified for function parameter

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-01 03:10 -------
No static is wrong here, period, what you need is an attribute which tells the back-end that these are 
are pointers to ROM and such.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258

[Bug c/20258] error generated for storage class specified for function parameter

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-03-01 03:43 -------
Subject: Re:  error generated for storage class specified for
 function parameter

> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-01
> No static is wrong here, period, what you need is an attribute which tells
> the back-end that these are pointers to ROM and such.

Yes I understand. However it seems somewhat ironic that "static const"
already does just that, as it specifies the storage class and access
restrictions used to determine exactly the data stored in ROM; as such
it seems less invasive to consider allowing it to be optionally accepted
as a more restrictive parameter type specifier, rather than alternatively
requiring the introduction of a nearly redundant non-standard storage type
specifier in it's place, seemingly requiring modifications to much of GCC's
internals, from the parser down through to the code generator to be made
aware of this new attribute; unless I misunderstand the extent of the
surgery likely required?

(might the optional acceptance of a static storage class attribute for
 parameters be worth considering, given the apparent lack of less invasive
 alternatives?)





-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258

[Bug c/20258] error generated for storage class specified for function parameter

[neil at daikokuya dot co dot uk]

------- Additional Comments From neil at daikokuya dot co dot uk  2005-03-01 12:39 -------
Subject: Re:  error generated for storage class specified for function parameter

schlie at comcast dot net wrote:-

> Yes I understand. However it seems somewhat ironic that "static const"
> already does just that, as it specifies the storage class and access

What if it were the pointer that was like this?  You need a type
qualifier, not a storage class.

Neil.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258

[Bug c/20258] error generated for storage class specified for function parameter

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-03-01 15:20 -------
Subject: Re:  error generated for storage class specified for
 function parameter

> - Additional Comments From neil at daikokuya dot co dot uk  2005-03-01
>> Yes I understand. However it seems somewhat ironic that "static const"
>> already does just that, as it specifies the storage class and access
> 
> What if it were the pointer that was like this?  You need a type
> qualifier, not a storage class.

- unless I misunderstand the question, the only way a pointer itself would
  be stored in ROM were if it were itself a static const value, and in turn
  would itself need to be referenced by a (static const *), where once
  referenced, (i.e. the pointer's value is now in a non-static variable) so
  it itself never be further qualified (I think)?




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258

[Bug c/20258] error generated for storage class specified for function parameter

[joseph at codesourcery dot com]

------- Additional Comments From joseph at codesourcery dot com  2005-03-01 16:56 -------
Subject: Re:  error generated for storage class specified for
 function parameter

On Tue, 1 Mar 2005, schlie at comcast dot net wrote:

> - unless I misunderstand the question, the only way a pointer itself would
>   be stored in ROM were if it were itself a static const value, and in turn
>   would itself need to be referenced by a (static const *), where once
>   referenced, (i.e. the pointer's value is now in a non-static variable) so
>   it itself never be further qualified (I think)?

Just as you can have "char *" and "char *const" and "const char *" and 
"const char *const", you can have "ROM pointer to ROM" and "ROM pointer to 
RAM" and "RAM pointer to ROM" and "RAM pointer to RAM", and similarly with 
more levels of indirection.

If you want to handle address spaces properly, look at DTR 18037 (or the 
final TR once the subclause numbering has been agreed with ISO).  There is 
no bug here, although making GCC handle multiple address spaces properly 
in the manner described in DTR 18037 might be useful for some targets.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258

[Bug c/20258] error generated for storage class specified for function parameter

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-03-01 21:41 -------
Subject: Re:  error generated for storage class specified for
 function parameter

> --- Additional Comments From joseph at codesourcery dot com  2005-03-01
> Subject: error generated for storage class specified for function parameter
>              
>> On Tue, 1 Mar 2005, schlie at comcast dot net wrote:
>> - unless I misunderstand the question, the only way a pointer itself would
>>   be stored in ROM were if it were itself a static const value, and in turn
>>   would itself need to be referenced by a (static const *), where once
>>   referenced, (i.e. the pointer's value is now in a non-static variable) so
>>   it itself never be further qualified (I think)?
> 
> Just as you can have "char *" and "char *const" and "const char *" and
> "const char *const", you can have "ROM pointer to ROM" and "ROM pointer to
> RAM" and "RAM pointer to ROM" and "RAM pointer to RAM", and similarly with
> more levels of indirection.
> 
> If you want to handle address spaces properly, look at DTR 18037 (or the
> final TR once the subclause numbering has been agreed with ISO).  There is
> no bug here, although making GCC handle multiple address spaces properly
> in the manner described in DTR 18037 might be useful for some targets.

Thank you for the reference, and do also agree there's no "bug" in the
present implementation. However do observe that although the present use of
of a storage-class specifier in the context of a parameter type-qualifier is
not supported by the present standard; it may be worthy of consideration as
a sensible optionally enabled extension; as the use of the combination
"static const" in this context seems fully consistent with the specification
of an otherwise explicit ROM address-space-qualifier, as it is just this
combination which is typically used to identify values which may be stored
as ROM'ed data.

Therefore seems reasonable to consider compatibly optionally extending the
use of "static const" as an implied read-only address-space qualifier, as it
would not introduce any ambiguities because it's present use in this context
is not supported (and seems easier to initially enable, than DTR18037 is).

Might you be willing to consider a patch enabling this option use?

---

As an aside, with respect to the various permutations of static const *,
etc. It seems that by simply designating the combination "static const" as
an optional legal type qualifier within contexts not otherwise supporting
the designation of a storage-class specifier, GCC can be relatively easily
enabled to support an implied primitive ROM address-space which is distinct
from the remaining default address space (being implied by everything not
"static const").

For example, with respect to the optional extension of "static const" as
a function parameter's qualifier, since parameters are passed in RAM, ROM
(i.e. "static const") values may only be passed by reference by definition,
which eliminates I believe much of it's potential complexity. For example:

int foo (int * static const x);

Is physically impossible, as parameters are implied to be variable,
therefore must be passed in RAM, therefore must not in ROM. However as you
note, with the exception of this restriction, any subsequent hierarchy of
qualifiers would be valid, although some of likely limited practical use.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258

[Bug c/20258] error generated for storage class specified for function parameter

[joseph at codesourcery dot com]

------- Additional Comments From joseph at codesourcery dot com  2005-03-01 22:30 -------
Subject: Re:  error generated for storage class specified for
 function parameter

On Tue, 1 Mar 2005, schlie at comcast dot net wrote:

> not supported by the present standard; it may be worthy of consideration as
> a sensible optionally enabled extension; as the use of the combination
> "static const" in this context seems fully consistent with the specification

It seems like an extension that would not be sensible at all.  Type 2 TRs 
are for experimental features and should be considered as "if you want to 
do this, it would be a good idea to do it this way; you might find issues 
through implementation experience which lead to the TR being improved and 
the subject matter eventually becoming less experimental".  So given 
there's a DTR on this subject, if you want to implement address spaces you 
should follow the TR and so assist future standardisation rather than 
implementing some random other extension to do the same thing.  We 
shouldn't go implementing our own new extension to do something there's a 
standard way to do.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258

[Bug c/20258] error generated for storage class specified for function parameter

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-03-01 22:43 -------
Subject: Re:  error generated for storage class specified for
 function parameter

> -- Additional Comments From joseph at codesourcery dot com  2005-03-01
> Subject: error generated for storage class specified for function parameter
> 
>> On Tue, 1 Mar 2005, schlie at comcast dot net wrote:
>> not supported by the present standard; it may be worthy of consideration as
>> a sensible optionally enabled extension; as the use of the combination
>> "static const" in this context seems fully consistent with the specification
> 
> It seems like an extension that would not be sensible at all.  Type 2 TRs
> are for experimental features and should be considered as "if you want to
> do this, it would be a good idea to do it this way; you might find issues
> through implementation experience which lead to the TR being improved and
> the subject matter eventually becoming less experimental".  So given
> there's a DTR on this subject, if you want to implement address spaces you
> should follow the TR and so assist future standardisation rather than
> implementing some random other extension to do the same thing.  We
> shouldn't go implementing our own new extension to do something there's a
> standard way to do.

Understood. Are you aware of any existing efforts to extend GCC in this way;
or likely need to start from scratch? (any warnings/recommendations?)




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258

[Bug c/20258] error generated for storage class specified for function parameter

[joseph at codesourcery dot com]

------- Additional Comments From joseph at codesourcery dot com  2005-03-01 22:59 -------
Subject: Re:  error generated for storage class specified for
 function parameter

On Tue, 1 Mar 2005, schlie at comcast dot net wrote:

> Understood. Are you aware of any existing efforts to extend GCC in this way;
> or likely need to start from scratch? (any warnings/recommendations?)

I am not aware of any existing effort to implement any part of DTR 18037.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258