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>]

Eric Botcazou wrote:
> > Below is simple program that makes GPC crash. The crash is when making RTL
> > for array `a1' (triggered by the DECL_RTL macro). IMHO GPC uses much more
> > compilcated array declararions then other front ends (the code below is
> > simple, but GPC have to be prepared for more complex cases), so probably it
> > is not possible to reproduce the problem with other front end.
> >
> > { Compile using -W flag. }
> > program String;
> >
> > function MemCompCase (const s1; Size: SizeType): Boolean;
> > var
> >   i: Integer;
> >   a1: array [1 .. Size] of Char absolute s1;
> > begin
> >   MemCompCase := True
> > end;
> > begin
> > end.
> >
> > The error message is:
> >  MemCompCase
> > string3.i: In function `MemCompCase':
> > string3.i:8: internal compiler error: in make_decl_rtl, at varasm.c:797
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> 
> Yes, I didn't manage to reproduce it with an equivalent C testcase. I presume 
> the 'absolute' stuff is necessary to make it crash?
> 

Yes. In fact even simple variable (not necessary array) make the compiler
crash. In detail, absolute variable is essentialy alias to given memory
location. It needs no RTL since Pascal frontend replaces all references
to such variables by references to memory. So, inside functions (procedures)
such variables look like ordinary automatic variables but are never
passed to `expand_decl'. `make_decl_rtl' is right not allocting memory
for them -- the essence of absolute variable is that backend shall not
allocate memory for them. The place affected by the patch is one of 
few places in the backend which force variables to have a location
(there is also problem with setjmp, which also wants all variables in
defined locations).

You may ask if Pascal really needs a declaration for absolute variable.
IMHO it needs -- Pascal passes program in small chunks to the backend.
So Pascal frontend can not catch many errors and depends on the backend
to report them, which in turn needs declarations. 

AFAIKS Ada (and to some degree Fortran) resolves such problems inside
front end and passes to the backend only correct low-level translation
of the source. And IMHO C languages have no analogous construct.

> > 3) IMHO the patch is appropriate for gcc-3.3 -- it fixes real problem
> > for GPC and the chance of breaking something is very low. However if
> > inclusion in gcc-3.3 is against the policy that is fine.
> 
> The patch looks reasonable to me, but without a testcase for the FSF 
> testsuite it has nearly zero chance to go in 3.3.x.
> 
> > I developed the patch a year ago and as I wrote it is currently distributed
> > with GPC (so in full install Pascal uses patched backend and other front
> > ends use original backend). My objective here is to be able to build GPC
> > with unpatched backend, and that probably will happen only with 3.4.
> 
> We are in stage3 for GCC 3.4, so a testcase could be required there too.
> 
> Mark, what do you think about the patch?
> 

My understanding of the policy was: "We want the testcase, so the problem
will not come back" and that testcase may be ommited if there is reasonable
argument that the testcase is not possible. And above I tried to give 
such argument.

What you write sound like: "We will not fix non-observable bugs". I agree
that such policy make sense for released version, but how do you expect
get rid of bugs in developement version if you refuse to fix bugs? 

By the way, I recently found other few places where I think that the GCC
code is incorrect. Shall I not report them since the code is either
unused (by "standard" frontends) or behaviour while incorrect is 
harmless ?

> > By the way, the patch applies to 3.4 snapshots. I bootstraped both
> > gcc-3.3.2 and gcc-3.4-20031015 (ada build in gcc-3.4-20031029 failed
> > for me) on i386 and run the testsuite. I saw no new regressions (compared
> > to unpatched build).
> 
> Fine.
> 
> -- 
> Eric Botcazou
> 

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