Re: Pascal front-end integration
Joseph S. Myers wrote: > Patches need testing - but presumably GPC patches are already tested (and > bootstrap isn't required for non-C-front-end changes). > > Patches need testcases in the testsuite if possible - but GPC already > seems to have a thorough testsuite, though I don't know if every patch > gets a test or tests added there if possible. Usually we write tests for each change now. (In the past it was different, so not all aspects of the compiler are covered by the testsuite yet, but new changes should be.) In addition, we add bug reports we receive and interesting cases we stumble upon ... > Patches need documentation to be updated if applicable - but GPC already > has documentation which I presume is being kept up to date. Almost the same situation -- the documentation itself is not complete, but for new features we add at least minimal documentation (while slowly trying to fill the existing gaps). Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
Re: Pascal front-end integration
Some random notes. Mark Mitchell wrote: > Personally, I'm not necessarily convinced that adding Pascal to > GCC is a good idea. I like Pascal just fine, but because every new > language adds to the load on everyone. (In my ideal world, we'd > have stable enough interfaces that it was easy to maintain front > ends separately from the rest of the compiler, but, though I've > been extolling that vision for years, I've made little progress in > realizing it...) I think I'd like the idea. Then the backend would be used almost like a library. Of course, I understand that the interface and dependencies will be bigger than of most other libraries, and changes between versions might also be more significant. And it will be versions beyond what gpc currently supports, so changes in gpc will be necessary anyway. But if it's a realistic plan (which I can't judge), it might be a useful long-term goal for gpc as well. (And I'm not too impatient about it.) One advantage I see of not integrating is to decouple release dates and feature sets -- in particular for frontends that are changing sigificantly WRT syntax and features, as gpc still is. (E.g., if a user wants to get the latest gpc features, but the latest backend version has some serious bug on his platform, now he can just use the previous backend version; with an integrated front-end this is no option, and he has to wait for a new backend release in order to use the existing frontend features. Of course, assuming a normal user who doesn't want to use a CVS snapshot, which may contain the bugfix earlier, for production work.) Ed Smith-Rowland wrote: > I, for one, am more likely to play with a gpascal that bootstraps > with mainline than to try to build one with, perhaps unusual, > dependencies and some different version of gcc. Except for the gcc version, the other dependencies will not necessarily change by integration (e.g., bison version). > My understandng is that gpc uses flex/bison in a p2c - a pascal to C > translator. I would like to know why folks think hand written > parsers are better. My guess is that they are easier to maintain > and that they support more lookahead. We don't use p2c. The gpc compiler is written in C, only the runtime support is (mostly) written in Pascal. The compiler uses flex and bison in C, as usual. Bison now supports GLR parsing which, effectively, allows for unbounded look-ahead. In our experience, the main advantages of a parser generator are (a) more readable grammar, (b) automatic computation of look-aheads, (c) when adding new syntax rules, one sees easier when they contain nonobvious conflicts. Currently bison works well for gpc, and I don't see a reason to rewrite a thing that works. Maybe other languages favour hand-written parsers, but Pascal doesn't AFAICT. Marcin Dalecki wrote: > If you have only USCDII in mind yes. But not if you look after any > of the usable, aka Delfi, implementation of it. You always have to > have runtime libraries. GPC already supports several standards and dialects and is quite usable (and used :-) already, and the runtime library exists. Neither UCSD nor Delphi are my favourite examples of useful dialects, BTW (sparing stronger words for reasons of good taste). But if you think of Delphi-like GUI class libraries and stuff like that (which some people are currently developing), I think they should remain separate projects anyway and not be part of gpc (whether or not gpc in turn will be integrated in gcc). > Hugh? I see the argument that another front-end will exercise more > of the back-end, since chances are that it will trigger code paths > in it which other languages don't use. > > However I can hardly see any Pascal language feature/construct, > which wouldn't be already covered by the C++ or Java ABI. How hard did you look actually? Andrew Pinski already mentioned non-local gotos and nested functions. In addition, there are things like SET_TYPEs (which AFAIK only Chill used besides Pascal), schema types (which are implemented not quite the same as C++ templates), subrange types, case (switch) ranges and perhaps some more. Anyway, experience has shown that gpc has already found some backend bugs. Some were fixed in gcc-3.4 thanks to Waldek Hebisch, some more are still on our list. I can't judge whether gpc integration does more good or bad from your POV in general, and as I wrote I have some reservations from my POV as well. But this one is not a valid point anyway. Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
Re: Pascal front-end integration
Joseph S. Myers wrote: > On Thu, 3 Mar 2005, Waldek Hebisch wrote: > > > 1) With current GPC I can work out a new feature and test it using old > > backend. Such feature relatively quickly can go out in a development > > snapshot which is usable by ordinary users (the development snapshot > > uses old, tested backend which shields users form most bugs outside > > the front end). At the same time I can work on adapting GPC to newer > > backend. All that when _I_ have time. > > > > Staged development introduces deadlines and delays, which are very > > disruptive for me (it seems that other peope can handle schedules > > much better than I can). And these people are definitely not me, BTW. ;-) > > 3) AFAIU dropping support for multiple backends is considered as a > > pre-condition to inclusion of GPC into GCC. GPC release wold be > > part of GCC release. People trying GPC snapshots would automatically > > get backend snapshot. I am affraid that for Pascal that means > > 6-8 months extra delay between including a feature in GPC and first > > bug reports (and consequently more effort for bug fixing). > > The way to avoid this is for front ends to have internal datastructures > decoupled from those of the rest of GCC and to have a small piece of code > that does the conversion (like the Ada front end's gigi), then just > maintain multiple versions of that small piece of code. This seems to > work well for Ada. Well, I haven't looked closely at the Ada code. Perhaps it's an option for gpc, but I'd imagine it would be a significant initial effort at least (converting the current code which works rather closely with backend data structures). If you or Jim want to take this effort, then let's discuss the details first before you start something on your own. We (Waldek and I) currently have some open issues where we consider to (or did already) add private tree codes, and I suppose they should be handled by this intermediate layer then as well. But other than that, I can't really tell whether or not that's a good way to go for gpc ... Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
Re: Pascal front-end integration
Waldek Hebisch wrote: > > > 3) AFAIU dropping support for multiple backends is considered as a > > > pre-condition to inclusion of GPC into GCC. GPC release wold be > > > part of GCC release. People trying GPC snapshots would automatically > > > get backend snapshot. I am affraid that for Pascal that means > > > 6-8 months extra delay between including a feature in GPC and first > > > bug reports (and consequently more effort for bug fixing). > > > > The way to avoid this is for front ends to have internal datastructures > > decoupled from those of the rest of GCC and to have a small piece of code > > that does the conversion (like the Ada front end's gigi), then just > > maintain multiple versions of that small piece of code. This seems to > > work well for Ada. > > GPC uses backend data structure when possible. I see no reason to > duplicate backend functionality (Ada front is written in Ada, so they > _had to_ duplicate a lot of infrastructure). I see. That makes a difference I didn't know about. So what's practical for Add might not be for us. (Unless we'd rewrite gpc in Pascal. But that's a huge effort I don't really want to think about, with small benefits.) > We can hide (and are doing > that now) most differences in macros. > > But there are few tricky questions: I old backends want us to call a > function is it OK to always call a wrapper (empty for new backend)? > > Or an actual sample (the most nasty case I have found): > > case FLOAT_EXPR: > #ifndef GCC_3_4 > case FFS_EXPR: > #endif > > here we have moderatly sized switch and moving the case constant > to backend dependent part would move the whole switch, hence the > function containing the switch. Is it acceptable to have something > like: > >case FLOAT_EXPR: >CASE_FFS_EXPR > > with `CASE_FFS_EXPR' expanding to nothing for new backend. BTW, I suppose we can just remove this case as we don't use FFS_EXPR anyway. (This code was originally copied from the C frontend, without checking whether we need it all.) But the general question remains, as there are probably other similar cases. Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
Re: Pascal front-end integration
> I also don't recommend trying to keep compatibility before 4.0; working > with 4.0 would suffice to keep the new GPC developments usable with a GCC > release and the differences between 4.0 and earlier compilers are > sufficiently large that the saving from not trying to be compatible with > earlier versions would be substantial. In general, compatibility with the > most recent release series should suffice; if the 4.0 series is > insufficiently stable, effort would better be devoted to improving it than > to keeping compatibility with older and less-maintained series. I'm not only talking of genuine backend bugs (though, of course, there may be some that are not exercised by other backends, as there have been in various 3.x versions), but also of frontend bugs that are not exercised with older backends. And of course, the new code to adapt gpc to 4.x needs to be tested and fixed as well. So to make it short, for my own productive work I'm not going to use gpc with a backend that hasn't been tested with gpc for at least several months. Therefore, I'm not going to do my own frontend work on such a version, as I want to be able to try it immediately. So if you think dropping older backends is the only way to support 4.x, a fork would be inevitable. But I'm not convinced this is really necessary. Waldek Hebisch wrote: > James A. Morrison wrote: > > I beleive function-at-a-time goes back to gcc 3.0. Creating function trees > > then passes off to an expand function within the pascal front-end would > > probably work with most gcc backends. The cgraph stuff is a bit more of > > an issue. I think cgraph appeared in gcc 3.4. > > > > AFAIK 4.0 is the first back-end which can handle the whole function > as a tree. All earlier versions had a tree walker in the front-end > which did tree to RTL conversion. Since such tree walker is not > needed in 4.0 I think that GPC should not support function-at-a-time > for 3.x. Agreed, this would just be unnecessary extra work. So IMHO the best thing for a smooth transition would be to add 4.x support as far as we can, with conditionals, so everyone can test it and we can drop earlier backend as soon as (safely) possible. Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
Re: Pascal front-end integration
Joseph S. Myers wrote: > > So IMHO the best thing for a smooth transition would be to add 4.x > > support as far as we can, with conditionals, so everyone can test it > > and we can drop earlier backend as soon as (safely) possible. > > If you can make such conditionals work, then fine. I'm just doubtful of > how clean the result will be given the extent of the changes to the > front-end interface with tree-ssa, I guess we'll just have to see. Waldek has looked into these changes already more than I have, and if Jim is willing to help in this course, perhaps we can get some preliminary results soon ... Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
Environment variable to turn off carets
This is a copy of the suggestion I made in http://lists.gnu.org/archive/html/bug-standards/2015-01/msg1.html Karl Berry suggested I ask for your views first. Various programs (including gcc and bison) support caret error messages, and recent versions have it activated by default. Caret output is a useful feature in many cases, but sometimes it's not helpful. E.g. when your editor parses the line/column numbers from the output and automatically jumps to this position, additional caret output is not needed, and indeed rather wastes space in the list of output messages. For other users, caret output just wastes screen-space, e.g.: http://stackoverflow.com/questions/19341149/turning-off-error-message-caret-in-gcc-4-8 Sure, you can turn off carets with command-line options such as "-fno-diagnostics-show-caret" (gcc) or "-fno-caret" (bison). But before you do that, you need a version check, since older versions don't understand these options and would fail. Also, the options differ between tools as shown for gcc and bison. At some time, the next tool, perhaps flex, will get carets and you need yet another option and version check, etc. ... Now, suppose your build runs from a Makefile (which contains various gcc, bison, etc. invocations), and you want to use the Makefile from an arbitrary context (e.g. plain command line where you want carets, and from the editor where you don't). Now, you have to pass some variable to the Makefile to tell it whether to do those version checks and pass the respective options to gcc, bison, etc. And you need to do this in every relevant Makefile. This all gets a bit cumbersome ... So let me suggest an alternative: If all programs that support caret output would recognize a common environment variable (say "NO_CARET_OUTPUT"), all of the above complications would disappear: - No version checks are required, since older versions simple ignore the variable. - One doesn't even have to know which programs (gcc, bison, maybe flex etc.) support carets if they use a common variable. - The Makefiles don't have do to anything since environment variables are automatically propagated. Only the editor, i.e. the instance that actually knows that carets are not useful there, needs to set the variable once. (So not only DRY, but also SOC, to drop some TLAs. ;) Does this seem reasonable? Regards, Frank
