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

Reply via email to