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?
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.
Joseph S. Myers