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 jos...@codesourcery.com
