This is the mail archive of the gcc@gcc.gnu.org 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: Question on variable_size and function-at-a-time


    > We were actually just having that discussion locally. But it's tricky
    > because it's stor-layout that puts in the SAVE_EXPRs, not the front end.
    > Indeed the Ada part of the code does make explicit temporaries here.

    How invasive would it be to make stor-layout not do that?  Push the
    responsibility back onto the front ends where it belongs?

Well, it's not at all clear where it "belongs" because the issues are
tricky.  A major issue is whether a front end has the capability to define
a variable that wasn't in the user code and put it in the proper scope.
The Ada front end can do this, but what about the others, such as C?

Then you have the debugging issue.  Suppose you have:

	int x;
	int arr[x+5];

The idea would be that the C front end would do essentially what the
Ada front end does and make some new variable and convert this to
something like:

	int x;
	const int arr_UB0 = x+5;
	int arr[arr_UB];

But now the debugging information will present the upper bound of arr
as "arr_UB0", which is not meaningful to the user, instead of "x + 5",
which is.

I think it's clear that the SAVE_EXPRs here should come out, but it's
not totally clear to me exactly at which level this should happen.


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