[PATCH] Fix var-tracking ICE introduced in poly_int conversion (PR debug/84252)

Jeff Law law@redhat.com
Thu Feb 8 23:27:00 GMT 2018


On 02/07/2018 03:43 PM, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned in the PR, the vt_get_decl_and_offset function verifies
> incoming PARALLEL is usable for tracking, but if it fails, we retry
> vt_get_decl_and_offset on DECL_RTL and there we check only that a memory
> isn't larger than 16 bytes (to make sure it doesn't have more than 16
> parts), but if DECL_RTL is a REG e.g. with OImode as in the testcase on
> aarch64, we just go on.  For the OImode argument passed in V4SImode v0
> and V4SImode v1 parts we are lucky and used to get away with it, as it only
> had 2 parts (and only dwarf2out threw it away as we can't really do vector
> debug info well right now), but generally if vt_get_decl_and_offset doesn't
> check the PARALLEL incoming, it is better to punt right away, we don't know
> if all PARALLEL operands are REGs, have REG_ATTRS, the same underlying decl
> and usable offsets, which we all rely on and only vt_get_decl_and_offset
> verifies.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux and Richard S. tested
> it on aarch64-linux, ok for trunk?
> 
> 2018-02-07  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR debug/84252
> 	* var-tracking.c (vt_add_function_parameter): Punt for non-onepart
> 	PARALLEL incoming that failed vt_get_decl_and_offset check.
> 
> 	* gcc.target/aarch64/pr84252.c: New test.
OK.  And that's about all my brain can handle today.  I'm fried.
jeff



More information about the Gcc-patches mailing list