On 10/15/12 17:06:28, Joseph S. Myers wrote: > 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.)
Back when we began to develop GUPC, it was recommended that we introduce the UPC capability as a language dialect, similar to Objective C. That is the approach that we have taken. > 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. I agree that there is no de facto reason that cc1upc is built other than the fact we use a similar approach to Objective C. However, I think that re-working this aspect of how GUPC is implemented will require a fair amount of time/effort. If we can find a way to make that happen in the GCC 4.8 time frame, or if other GCC contributors are willing to help on this, then perhaps such a change is feasible. - Gary
