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

Reply via email to