Re: [PATCH] Correct thinko (DECL_RTL to DECL_RTL_SET_P) in function.c

[Waldek Hebisch <hebisch at math dot uni dot wroc dot pl>]

Joseph S. Myers wrote:
> A commitment to merge GPC into tree-ssa (and so make it part of GCC 3.5),
> with the testcase to be included when GPC is merged in, might help here.
> 
> (This is presuming that GPC would not be accepted onto mainline at this
> stage, even disabled by default, or that it isn't ready to go in GCC
> mainline CVS.)
> 

I am not prepared to make a concrete proposal here.

But the basic facts are:

GPC works with 2.8.1, 2.95.3, 3.2.x, and 3.3.x backends. The compiler
proper builds with 3.4 and compiled a hello world, but is unusable 
due to broken command line handling. With 3.3.x we have a regression:
Pascal preprocessor used to have the same predefined symbols as 
C preprocessor. With 3.3.x C predefines are handled differently and
currently not seen by GPC preprocessor. Predefines are needed to 
bootstrap on Dos, Cygwin, Mingw32 and some proprietary Unices. Also
user code may depend on them. We have a workaround, but we can not call
3.3.x based versions stable before that is properly resolved. If 
tree-ssa allows as to use the same interface as 3.4 it may follow
quickly.

We have a single source tree using conditional and macros to hide backend
differences. To build GPC needs a backend patch. 3.3.x patch is about
1000 lines of unified diff. The size of diff is somewhat inflated as it
puts GPC specific code in conditional sections. The biggest part of 
the diff is a change to set handling. AFAIK it was written by Peter
Gerwinski and was scheduled for inclusion in GCC 3.0 -- at the moment
I was unable to find any trace of that patch on GCC mailing lists. 
It is impossible to give any timeframe for GPC integration without 
deciding about this patch -- if the set patch is rejected then GPC
runtime would need substantial rewrite. Such rewrite will take 
months at least. 
There is about dozen smaller patches -- mostly what I consider 
bug fixes, but some may be controversial. 

My feeling was that all of the patches are proper for consideration
in 3.4. They are small localised changes each trying to resolve single
problem. IMHO if a patch fixes bug in GCC the it should be applied, if 
not GPC need to be fixed. To decide I need feedback from GCC developers.

Even set patch, while not a bugfix in strict sense:
-- implements what was deemed proper handling for sets
-- is carefull to be backward compatible
-- changes parts unused by "standard" frontends
so is within the spirit of stage 3.

Concerning GPC integration: IMHO if we are not ready to _start_
integration now, we will never be ready. The big problem is to 
fit GPC into GCC developement model. I am not yet ready to 
submit a concrete proposal -- at the moment I am trying to resolve
technical problems as the first step.

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl