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: 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.


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