Re: RFC: Merge the GUPC branch into the GCC 4.8 trunk (patch 0 of 16)

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Mon, 15 Oct 2012, Gary Funck wrote:

> Various UPC language related checks and operations
> are called in the "C" front-end and middle-end.
> To insure that these operations are defined,
> when linked with the other language front-ends
> and compilers, these functions are stub-ed,
> in a fashion similar to Objective C:

Is there a reason you chose this approach rather than the -fcilkplus 
approach of enabling an extension in the C front end given a command-line 
option?  (If you don't want to support e.g. the ObjC / UPC combination, 
you can always give an error in such cases.)  In general I think such 
conditionals are preferable to linking in stub variants of functions - and 
I'm sure people doing all-languages LTO bootstraps will appreciate not 
having to do link-time optimization of the language-independent parts of 
the compiler yet more times because of yet another binary like cc1, 
cc1plus, ... that links in much the same code.  The functions you stub out 
would then all start with assertions that they are only ever called in UPC 
mode - or if they are meant to be called in C mode but do nothing in that 
case, with appropriate checks that return early for C (if needed).

-- 
Joseph S. Myers
joseph@codesourcery.com