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)
