This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Patch for Bug No-8081
- From: "Sitikant Sahu, Noida" <sitikants at noida dot hcltech dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 8 Sep 2003 12:35:30 +0530
- Subject: RE: Patch for Bug No-8081
Zack Wrote:
>> Hello,
>> I've proposed a Patch for GCC bug no 8081 and uploaded in the required
page.
>> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8081>
> The patch reviewers do not watch the bug database for attached
> patches. It's good that you did what you did, but you should also
>have sent the patch to <gcc-patches@gcc.gnu.org> with change log and
explanation.
Sorry about that. I assumed that bugzilla would automatically
mail gcc-patches if the attachement is a patch.
> Now, looking at your patch, I do not believe it is correct.
> Allocating space in the callee means that it will get deallocated
> immediately, when the callee returns, and may then be trashed by
> further stack operations in the caller. It's true that the caller
> failed to provide space because the return value is not used,
> but that
> may not be the only way to get a null target at this point, and you
> would then have turned an ICE into a silent miscompilation.
The space is allocated in the caller. The expand_call () is being
processed for the caller. The values within the returned block can be
accessed if we write something like
func ().val[i]
Am I missing something, if thats not the case ?
> The patch also appears to have broken the case where the target *was*
> provided by the caller - you allocate dynamic space anyway.
I believe the control never flows through this patch if that is
the case. (i.e. if target is provided by the caller.)
> The proper fix for the bug is to allocate space in the caller, for a
> function returning a variable-sized object like this, even if that
> space isn't going to get used.
That is exactly what patch tries to do. I think the comment in
the beginning is not clear enough to convey this. May be I should
write:
/* There was an assumption here that for variable-sized objects,
we must be called with a target specified. The assumption is
not valid when we call a nested function returning an
variable size object, not used after this call.
So we must allocate return value dynamically. */
Please let me know if that clarifies.
Thanks a lot for reviewing the patch.
Best Regards,
Sitikant Sahu.