This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] tree-ssa fixes
- From: Jeff Law <law at porcupine dot slc dot redhat dot com>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 19 Sep 2002 11:40:16 -0600
- Subject: Re: [tree-ssa] tree-ssa fixes
- Reply-to: law at redhat dot com
In message <20020919014338.GC21342@tornado.toronto.redhat.com>, Diego Novillo w
rites:
>On Wed, 18 Sep 2002, Jeff Law wrote:
>
>>
>> Whee.
>>
>> We were goofing the dataflow information for a couple cases.
>>
>> For indirect calls, we didn't create any uses for the variable holding
>> the target function's address. Ouch.
>>
>Damn. I knew I was forgetting something when I removed this code
>a few days ago. Remember that you mentioned that it was odd that
>we were finding V_USEs for function names? At the time I thought
>"isn't that silly". So, I removed it.
>
>But the real trick was actually not creating references for
>FUNCTION_DECLs (that fix went in earlier today). Oh, well.
>Thanks for adding it back in.
I'll be checking it in in a moment.
>> * tree-dfa.c (find_refs_in_stmt): Search for references in the
>> size expression for a VAR_DECL.
>> (find_refs_in_stmt): Search for references in the call address
>> of a CALL_EXPR.
>> (find_refs_in_stmt): Handle SAVE_EXPRs.
>>
>Ouch. SAVE_EXPRs should be welcomed with a call to abort(). The
>simplifier is supposed to remove them. Also, in trying to see
>where we are getting these SAVE_EXPRs, I applied your patch and
>got an abort when compiling this program:
The case I was looking at the size of the array was determined from
an argument rather than a variable -- the code certainly hadn't been
through a thorough test, it was mostly so that y'all could comment.
Clearly we need to do something about it though.
jeff