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