This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR61762, reads from string constants
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 11 Jul 2014 10:11:34 +0200
- Subject: Re: [PATCH] Fix PR61762, reads from string constants
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1407101710260 dot 5753 at zhemvz dot fhfr dot qr> <20140710152843 dot GM31640 at tucnak dot redhat dot com> <alpine dot LSU dot 2 dot 11 dot 1407110955150 dot 5753 at zhemvz dot fhfr dot qr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Jul 11, 2014 at 10:00:01AM +0200, Richard Biener wrote:
> I started with adding an optional arg to native_encode_expr but then
> figured that all the current workers return failure if the entire
> expr doesn't fit within 'len'. But what I want is a native_encode_expr
That is because the functions were written for VIEW_CONVERT_EXPR folding
where it is expected that both the types are the same size, and it doesn't
make sense to spend too much time on large stuff that doesn't fit into
the fold_view_convert_expr's fixed size buffer. Now, for your case
the sizes aren't the same and thus partial data is just fine, because
what native_interpret_expr will do is small fixed size.
So I don't see a problem with not returning NULL and instead handling the
partial store into buffer if you ask for it through optional argument
(doing it always would be fine for fold_view_convert_expr assuming nobody
feeds us different sized argument vs. VCE type, but e.g.
tree-loop-distribution.c certainly appreciates if we return NULL for large
things, because if it had just partial buffer, it would not be able to
verify what it is looking for).
Jakub