On Mon, 15 Oct 2012, Gary Funck wrote: > 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.
Recommended where? I think that approach has been a bad idea for a long time and the approach of building into cc1, as taken by the cilkplus patches, is better (and that really most objc/ code should be like c-family/, built once and linked into both cc1 and cc1plus, though in its present state that's much harder to achieve). > 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 I'd expect it to be a fairly straightforward rework (as would making ObjC a mode of cc1, if ObjC++ didn't exist). -- Joseph S. Myers jos...@codesourcery.com
