[RFC]: Add support for pragma pointer_size

Tristan Gingold gingold@adacore.com
Thu Mar 8 13:49:00 GMT 2012


On Mar 7, 2012, at 7:42 PM, Joseph S. Myers wrote:

> On Wed, 7 Mar 2012, Tristan Gingold wrote:
> 
>> On Mar 6, 2012, at 6:34 PM, Joseph S. Myers wrote:
>> 
>>> On Tue, 6 Mar 2012, Tristan Gingold wrote:
>>> 
>>>> The patch is simple: the C front-end will now calls c_build_pointer_type 
>>>> (instead of build_pointer_type), which in turn calls 
>>>> build_pointer_type_for_mode using the right mode.
>>> 
>>> There seem to be quite a lot of build_pointer_type calls in the C front 
>>> end (and in c-common.c) that you haven't changed.  Could you explain the 
>>> rule for when a call should or should not be changed, and how it applies 
>>> to all these calls?
>> 
>> The global approach is to have the same effect as a default 
>> __attribute__((mode(SI/DImode))) on pointers declared by users so that 
>> layouts match.  That's why only grokdeclarator is changed.
>> 
>> There might be bugs with this approach (e.g. it looks like 
>> c-common.c:handle_noreturn_attribute doesn't preserve the mode of the 
>> pointer to function), but my understanding is that they also correspond 
>> to bugs of __attribute__((mode ())) applied to pointer.  The later one 
>> isn't well tested and one advantage of the VMS port is that it will test 
>> it much more (as there are many pragma pointer_size in VMS headers).
> 
> So those places would need to change to use build_pointer_type_for_mode as 
> is done for composite types in c-typeck.c:composite_type, for example?

Yes.

> I think the patch at least needs a (VMS-specific?) testcase that tests the 
> new pragma (presuming the testsuite can be run for VMS targets) even if 
> some cases can't be tested until they are fixed.

Argh, that's an issue.  We don't run the gcc test suite natively on VMS
because there is no port of Dejagnu (if ever doable) to VMS.  We haven't tried
to test a cross-compiler (and running the executable on the VMS host) because
an early attempt for another test suite pointed out slowness and reliability
issues.  VMS machines could be considered as slow from today's standard POV.
I haven't found a method to run only the compile tests and skip the executing one.
Is it possible to do that with the gcc test suite ?  That's would be very
useful to test cross compilers.

But I am not worried about the tests of '#pragma pointer_size' per see, as there
are very present in system headers and thus simply building a cross-compiler
(and much more certainly if Ada is enabled) would thoroughly test it.  So I think
this patch is test by building the compiler (not now but as soon as I add the
builtin macros that protect this pragma in VMS headers).

For testing front-end handling of mixed sized pointers, I think we can fallback
to the mode __attribute__ and enabling these tests on platforms that support it
(mips64/linux, s390x).

Is this approach ok to you ?

Tristan.



More information about the Gcc-patches mailing list