[PATCH 03/34] rs6000: Add the rest of the [altivec] stanza to the builtins file

Bill Schmidt wschmidt@linux.ibm.com
Tue Aug 10 13:49:28 GMT 2021

On 8/10/21 8:40 AM, Segher Boessenkool wrote:
> On Tue, Aug 10, 2021 at 08:02:24AM -0500, Bill Schmidt wrote:
>> The whole point is that this data type is only used for interfaces, as
>> shown in the example code.  Nobody wants to define const void as
>> anything.  The const serves only as a contract that the pointed-to
>> object, no matter what it is cast to, will not be modified.
> So it is just documentation, nothing to do with overloading?  Any cast
> (implicit as well!) will give new qualifiers, not just a new type.  So I
> still do not see the point here.
> I'll just read it as "void *" :-)

Largely documentational, yes.  The overloads must be defined with "const 
unsigned char *" and so forth.  It would be unexpected to define the 
built-in that this maps to as "void *" rather than "const void *".  
Normally passing a "const unsigned char *" to a function requiring a 
"const void *" can be done implicitly with no cast at all, and so this 
is what people expect to see.  "Under the covers" we can of course cast 
in any way that we see fit, but specifying "const void *" really 
reinforces what people should understand is going on.

If it makes you feel better to read it as "void *", I say go for it. 
:-)  I think most people will be less confused with "const" present in 
the signature in both the built-in definition and the overload 
definition, not just in one of them.


> Segher

More information about the Gcc-patches mailing list