This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Eric Botcazou wrote:
> > 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?
> The whole discussion is biased because GPC is not integrated in the FSF tree. 
> How can we be sure that the front-end is not abusing the middle-end?
Let me repeat part of prevous mail:
> 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).

Now, I have a question: is backend supposed to handle VAR_DECL with
no location and no RTL ?

If backend should handle such VAR_DECL-s then I am telling you that
such declaration can get from the frontend to `uninitialized_vars_warning'
and `uninitialized_vars_warning' needs to be fixed. 

So, please tell me if passing such VAR_DECL to the backend is an abuse ? 

Clear yes or no statement would be much more helpfull then "You have to
wait, we are at stage 3".

                              Waldek Hebisch 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]