Fix PR debug/59350

Eric Botcazou ebotcazou@adacore.com
Mon Jan 6 11:40:00 GMT 2014


This is the ICE on the checking assertion for ONEPART_VALUEs at the beginning 
of vt_expand_var_loc_chain.  The assertion looks a bit overzealous to me: it 
triggers here because we don't record a SET in add_stores, but only because we 
don't preserve the source: the source is a zero-extension of something and 
cselib manages to record an equivalence between the value of this something 
and the truncation of the value of the source(!) by the mere virtue of the 
existence of the source (see cselib.c:2013 and below).  Not sure why we would 
need to preserve it if we don't use it, but that's very likely simpler.

Tested on x86_64-suse-linux, applied on the mainline as obvious.


2014-01-06  Eric Botcazou  <ebotcazou@adacore.com>

	PR debug/59350
	PR debug/59510
	* var-tracking.c (add_stores): Preserve the value of the source even if
	we don't record the store.


2014-01-06  Eric Botcazou  <ebotcazou@adacore.com>

	* gcc.dg/pr59350-2.c: New test.
	* g++.dg/pr59510.C: Likewise.


-- 
Eric Botcazou
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr59350.diff
Type: text/x-patch
Size: 1499 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20140106/daac6874/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr59350-2.c
Type: text/x-csrc
Size: 353 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20140106/daac6874/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr59510.C
Type: text/x-c++src
Size: 2110 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20140106/daac6874/attachment-0002.bin>


More information about the Gcc-patches mailing list