Hi Kugan,
On 12/01/16 06:22, kugan wrote:
When promote_function_mode and promote_ssa_mode changes the sign differently,
following is the cause for the problem in PR67714.
_8 = fn1D.5055 ();
f_13 = _8;
function returns -15 and in _8 it is sign extended. In the second statement, we say that the value is SUBREG_PROMOTED and promoted sign in unsigned which is wrong. When the value in _8 had come other ways than function call it would be
correct (as it would be zero extended). Attached patch checks that and uses the correct promoted sign in this case.
The problem with the approach is, when you the following piece of code, we can
still fail. But, I dont think I will ever happen. Any thoughts?
_8 = fn1D.5055 ();
_9 = _8
f_13 = _9;
This is similar to PR65932 where sign change in PROMOTE_MODE causes problem for
parameter. But need a different fix there.
Regression tested on arm-none-linux-gnu with no new regression. I also
bootstrapped regression tested (on an earlier version of trunk) for
x86_64-none-linux-gnu with no new regressions. If this OK, I will do a full
testing again. Comments?
Thanks,
Kugan
gcc/ChangeLog:
2016-01-12 Kugan Vivekanandarajah <kug...@linaro.org>
* expr.c (expand_expr_real_1): Fix promoted sign in SUBREG_PRMOTED
for SSA_NAME when rhs has a value returned from function call.
Thanks for working on this.
I'll leave to other to comment on this part as I'm not overly familiar with
that area but...
gcc/testsuite/ChangeLog:
2016-01-12 Kugan Vivekanandarajah <kug...@linaro.org>
* gcc.target/arm/pr67714.c: New test.
This test doesn't contain any arm-specific code so can you please put it in
gcc.c-torture/execute/
Thanks,
Kyrill