Re: [RFC]: Add support for pragma pointer_size

2012-03-14 Thread Tristan Gingold

On Mar 13, 2012, at 9:57 PM, Gary Funck wrote:

 On 03/06/12 14:09:23, 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.
 [...]
 
 Joining this discussion a bit late ... I have a few questions.
 This change impacts the GUPC branch, mainly because UPC introduces
 pointers that are generally larger than conventional C pointers,
 and thus some changes were needed in the build pointer area,
 and that logic needed to be adjusted to work with this patch.
 
 Here is the new c_build_pointer_type.  It a static function
 constrained to be called from within the c-decl.c file wehre
 it resides.
 
 static tree
 c_build_pointer_type (tree to_type)
 {
  addr_space_t as = to_type == error_mark_node? ADDR_SPACE_GENERIC
  : TYPE_ADDR_SPACE (to_type);
  enum machine_mode pointer_mode;
 
  if (as != ADDR_SPACE_GENERIC || c_default_pointer_mode == VOIDmode)
pointer_mode = targetm.addr_space.pointer_mode (as);
  else
pointer_mode = c_default_pointer_mode;
  return build_pointer_type_for_mode (to_type, pointer_mode, false);
 }
 
 Here is the old build_pointer_type() in tree.c.  It is external/public
 and is called from various places.
 
 tree
 build_pointer_type (tree to_type)
 {
  addr_space_t as = to_type == error_mark_node? ADDR_SPACE_GENERIC
  : TYPE_ADDR_SPACE (to_type);
  enum machine_mode pointer_mode = targetm.addr_space.pointer_mode (as);
  return build_pointer_type_for_mode (to_type, pointer_mode, false);
 }
 
 c_build_pointer_type () introduces c_default_pointer_mode
 and uses it as long as:
   as == ADDR_SPACE_GENERIC  c_default_pointer_mode != VOIDmode
 but build_pointer_type will not use c_default_pointer_mode.
 
 My first question is: are there still contexts where build_pointer_type()
 is called to compile C statements/expressions for cases not
 covered by the calls within c-decl.c?

Yes.  In the discussion, Joseph Myers has pointed them.
Some of them are bugs (but should be replaced by build_pointer_type_for_mode),
others aren't incorrect (e.g. for built-in functions).

Currently c_build_pointer_type is called for user declared pointer types.

  I ask, because we tried
 moving our checks for UPC pointer-to-shared types from
 build_pointer_type() into only c_build_pointer_type() and
 ran into calls to build_pointer_type() that still passed
 in UPC pointer-to-shared typed objects.  What this may
 indicate is that there are situations where the new
 c_default_pointer_mode may need to be applied when
 build_pointer_type() is called.  I don't recall off-hand
 when these situations came up, but it might be easy enough
 to put some assertions in build_pointer_type() and then
 run the C test suite and see what turns up.

I think we should discuss these cases.  From my current understanding, these
direct calls that affect you are currently bugs.

Once I completed the VMS patch submission, I would add some tests to check
the handling of pointer modes.

 Thus, I wonder if it might not be best to generalize
 build_pointer_type() instead of introducing c_build_pointer_type()
 and dealing with any C specific checks (somehow) there?

I am almost sure that this is not correct.  build_pointer_type is part of the
middle end, where the 'pragma pointer_size' doesn't apply and the ptr_mode
should be used.

Tristan.



Re: [RFC]: Add support for pragma pointer_size

2012-03-13 Thread Gary Funck
On 03/06/12 14:09:23, 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.
[...]

Joining this discussion a bit late ... I have a few questions.
This change impacts the GUPC branch, mainly because UPC introduces
pointers that are generally larger than conventional C pointers,
and thus some changes were needed in the build pointer area,
and that logic needed to be adjusted to work with this patch.

Here is the new c_build_pointer_type.  It a static function
constrained to be called from within the c-decl.c file wehre
it resides.

static tree
c_build_pointer_type (tree to_type)
{
  addr_space_t as = to_type == error_mark_node? ADDR_SPACE_GENERIC
  : TYPE_ADDR_SPACE (to_type);
  enum machine_mode pointer_mode;

  if (as != ADDR_SPACE_GENERIC || c_default_pointer_mode == VOIDmode)
pointer_mode = targetm.addr_space.pointer_mode (as);
  else
pointer_mode = c_default_pointer_mode;
  return build_pointer_type_for_mode (to_type, pointer_mode, false);
}

Here is the old build_pointer_type() in tree.c.  It is external/public
and is called from various places.

tree
build_pointer_type (tree to_type)
{
  addr_space_t as = to_type == error_mark_node? ADDR_SPACE_GENERIC
  : TYPE_ADDR_SPACE (to_type);
  enum machine_mode pointer_mode = targetm.addr_space.pointer_mode (as);
  return build_pointer_type_for_mode (to_type, pointer_mode, false);
}

c_build_pointer_type () introduces c_default_pointer_mode
and uses it as long as:
   as == ADDR_SPACE_GENERIC  c_default_pointer_mode != VOIDmode
but build_pointer_type will not use c_default_pointer_mode.

My first question is: are there still contexts where build_pointer_type()
is called to compile C statements/expressions for cases not
covered by the calls within c-decl.c?  I ask, because we tried
moving our checks for UPC pointer-to-shared types from
build_pointer_type() into only c_build_pointer_type() and
ran into calls to build_pointer_type() that still passed
in UPC pointer-to-shared typed objects.  What this may
indicate is that there are situations where the new
c_default_pointer_mode may need to be applied when
build_pointer_type() is called.  I don't recall off-hand
when these situations came up, but it might be easy enough
to put some assertions in build_pointer_type() and then
run the C test suite and see what turns up.

Thus, I wonder if it might not be best to generalize
build_pointer_type() instead of introducing c_build_pointer_type()
and dealing with any C specific checks (somehow) there?

Thanks,
- Gary


Re: [RFC]: Add support for pragma pointer_size

2012-03-09 Thread Tristan Gingold

On Mar 8, 2012, at 7:10 PM, Mike Stump wrote:

 On Mar 8, 2012, at 5:49 AM, Tristan Gingold wrote:
 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.
 
 dejagnu slices through this type of testing just fine.  dejagnu is also adept 
 at handling reliability issues, its history is littered with unreliability 
 and it is usually fairly easy to work around any unreliability.  Selecting 
 targets that happen to be in a `working' state, powercycling them, as needed, 
 noticing when things go wrong, retrying things a few times, as sometimes, 
 something doesn't just work and so on.  Also, the cross testing can come in 
 many flavors, you can use a simulator (if you have one) and do cross and test 
 on simulator.  You can do this, without the simulator and just fail all the 
 execute tests, you can do canadian cross controlling host to native host 
 testing.  As for speed, well, it is all about latency and reliability, the 
 lower the latency and the higher the reliability, the faster the testing, 
 but, it is, what it is.  The modern testsuite might be 8 hour range or more, 
 but overnight testing is better than no testing.  If you hide it behind a git 
 send hook and stage everything through git and then push out from git as the 
 testsuite passes...  you should be able to achieve a nice work-flow.
 
 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 ?
 
 If you configure a cross compiler and do a make check, you'll just get a fast 
 fail on all the execute tests.  If you just look for regressions, you'll 
 notice this works just fine.  Sit back, don't worry about the execution 
 failures.  When you wire up sim, just say the simulator is /bin/false or 
 /bin/true (set_board_info sim /bin/false)
 
 Feel free to email me directly if you need additional pointers.  It is fairly 
 easy to setup, though, daunting, one has never done it before.

Thank you Mike for details.

I think I will investigate the cross compiler path first.

Tristan.



Re: [RFC]: Add support for pragma pointer_size

2012-03-09 Thread Tristan Gingold

On Mar 8, 2012, at 4:18 PM, Joseph S. Myers wrote:

 On Thu, 8 Mar 2012, Tristan Gingold wrote:
 
 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.
 
 Thanks for the explanation.  I advise solving the unreliability issues for 
 cross-testing to VMS (and living with the slowness), so that you can run 
 the testsuite, but the patch is OK as-is.

Thank you for your comments.
No C regressions on x86_64-darwin after full bootstrap.
Now committed.

Tristan.



Re: [RFC]: Add support for pragma pointer_size

2012-03-08 Thread Tristan Gingold

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.



Re: [RFC]: Add support for pragma pointer_size

2012-03-08 Thread Joseph S. Myers
On Thu, 8 Mar 2012, Tristan Gingold wrote:

 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.

Thanks for the explanation.  I advise solving the unreliability issues for 
cross-testing to VMS (and living with the slowness), so that you can run 
the testsuite, but the patch is OK as-is.

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [RFC]: Add support for pragma pointer_size

2012-03-08 Thread Richard Henderson
On 03/08/12 05:49, Tristan Gingold wrote:
 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.

Set the simulator to be /bin/true.


r~


Re: [RFC]: Add support for pragma pointer_size

2012-03-08 Thread Mike Stump
On Mar 8, 2012, at 5:49 AM, Tristan Gingold wrote:
 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.

dejagnu slices through this type of testing just fine.  dejagnu is also adept 
at handling reliability issues, its history is littered with unreliability and 
it is usually fairly easy to work around any unreliability.  Selecting targets 
that happen to be in a `working' state, powercycling them, as needed, noticing 
when things go wrong, retrying things a few times, as sometimes, something 
doesn't just work and so on.  Also, the cross testing can come in many flavors, 
you can use a simulator (if you have one) and do cross and test on simulator.  
You can do this, without the simulator and just fail all the execute tests, you 
can do canadian cross controlling host to native host testing.  As for speed, 
well, it is all about latency and reliability, the lower the latency and the 
higher the reliability, the faster the testing, but, it is, what it is.  The 
modern testsuite might be 8 hour range or more, but overnight testing is better 
than no testing.  If you hide it behind a git send hook and stage everything 
through git and then push out from git as the testsuite passes...  you should 
be able to achieve a nice work-flow.

  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 ?

If you configure a cross compiler and do a make check, you'll just get a fast 
fail on all the execute tests.  If you just look for regressions, you'll notice 
this works just fine.  Sit back, don't worry about the execution failures.  
When you wire up sim, just say the simulator is /bin/false or /bin/true 
(set_board_info sim /bin/false)

Feel free to email me directly if you need additional pointers.  It is fairly 
easy to setup, though, daunting, one has never done it before.


Re: [RFC]: Add support for pragma pointer_size

2012-03-07 Thread Tristan Gingold

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).

I haven't tried to exactly follow the DEC-C rules, because:
- they aren't formally written
- the current behavior of the front and middle end is already correct

I agree that it is possible to concoct tests (e.g. using sizeof) that will 
return different results between gcc and DEC-C, but my purpose is to be 
reasonable compatible, not fully compatible.  There are some features (such as 
supporting VAX float) that I don't plan to implement :-)

Tristan.



Re: [RFC]: Add support for pragma pointer_size

2012-03-07 Thread Joseph S. Myers
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


Re: [RFC]: Add support for pragma pointer_size

2012-03-06 Thread Joseph S. Myers
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?

-- 
Joseph S. Myers
jos...@codesourcery.com