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