RFC: Merge the GUPC branch into the GCC 4.8 trunk (patch 0 of 16)
Joseph S. Myers
joseph@codesourcery.com
Mon Oct 15 17:17:00 GMT 2012
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
More information about the Gcc-patches
mailing list