On Thu, 18 Oct 2012, Gary Funck wrote: > GUPC (then called GCC/UPC) dates back to the GCC 2.7 and GCC 2.95 days. > The GCC 2.7 based implementation was a prototype, and the GCC 2.95 version > was a first attempt to implement a UPC compiler that fits within the GCC > build framework. At the time, we had discussions with Mark Mitchell, > Mike Stump and perhaps others regarding the best method for introducing > a UPC compiler into GCC. The consensus recommendation at the time was to > implement GCC/UPC as a language dialect, similar to Objective-C. > Thus, much of the initial work was patterned after ObjC; it used > stubs and built a distinct front-end, so that is what we did.
GCC coding style has moved on a long way since then, and GCC generally has been moving away from conditional compilation, from #if to if conditions, from conditionally building something in to making the choice when the compiler is run. I don't think ObjC as a separate front end is a good idea now, and don't think UPC should be added that way. I also still don't think making UPC into a mode of the C front end should be more than a day or two's work. > My main issue with entertaining large re-structuring of GUPC > at the moment is that I would like to see if we can introduce > GUPC into GCC 4.8. As you point out, there are a lot of If the concern is 4.8, I'd think the priority should be the changes to the language and target independent code - changes to handle whatever additions UPC may make to GENERIC / GIMPLE - which will need middle-end maintainer review and which are probably the highest-risk part of the changes. > Also, specifying the flavor of PTS representation on the UPC > compiler command line (for example) is a departure from the > current method of configuring and invoking GUPC. There is a As noted above, use of #if is no longer generally good practice in GCC. Even "if (macro)", which might turn into "if (0)", is better than #if - at least it means all the code does get checked by the compiler, whichever configuration is built - but command-line options are certainly better. > JSM: Adding $(C_STUB_OBJS) uses to random language makefiles is very > JSM: suspicious. stub-objc.o isn't needed by non-C-family front ends. Nor > JSM: should stub-upc.o be - although I think the whole approach of using stub > JSM: functions like that is wrong, as discussed. > > I'm not fond of stubs or adding extra files to other front-ends, > but those changes seemed necessary at the time to get things to link. "seemed necessary at the time to get things to link" isn't sufficient reason. You'd need to state what symbols, used in what files, were undefined. But then the solution won't be to link in a stub file - it will be to link in real code, unconditionally. Whatever additions you make to GENERIC / GIMPLE for UPC should be handled entirely by language-independent code - that is, code that is always linked in, for all languages, to handle those GENERIC / GIMPLE features (even if most front ends don't generate those features), rather than code only linked in for particular front ends. > JSM: The language-independent > JSM: compiler should be using language-independent interfaces to process > JSM: language-independent internal representations; if there are additions to > JSM: the language-independent IR to handle UPC, then the relevant code to > JSM: handle them should be built in unconditionally. > > We followed the Objective C approach for better/worse. ObjC does not require stubs to be linked into non-C-family front ends. Whatever code exists in the language-independent compiler to handle GIMPLE from the ObjC front end gets linked into all compilers without any need to link in any stubs. > The few additional tree nodes needed for UPC are defined > in a language dependent tree definition file. The UPC-specific Whatever those get gimplified to needs to be language-independent (that is, handled after gimplification entirely by language-independent parts of the compiler). -- Joseph S. Myers jos...@codesourcery.com
