[PATCH] Fix *two* AVR backend bugs (PR19293 + PR19329)

[Bernardo Innocenti]

Paul Schlie wrote:
> re: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01631.html
> 
>>Bernardo Innocenti wrote:
>>Not sure if they can be called regressions, as no one could test with an
>>older version of GCC.  Both are quite critical: PR19293 is an ICE, PR19329
>>is wrong-code, both with valid trivial input.
> 
> 
> As a result of newly applied optimizations in 4.0, GCC now occasionally
> generates shift by 0 which exposed a latent bug in avr's back-end, therefore
> arguably a regression from previous behavior.

The shift by 0 slips through also in 3.4.2/3.4.3 as reported
in PR19329.  I never saw out of range shifts in 3.4, so this
may be a 4.0 regression.


>>PR19293 and PR19329 can both be closed by applying the following
>>combined patch (Marek, please review it again).
> 
> Arguably, the PR referenced above associated with the middle-end now
> occasionally generating a shift 0 as a result of newly applied optimizations
> should remain open, as it shouldn't; although likely re-classified.
> 
> With respect to the combined patches (assuming I've merged them as
> intended), it seems that sometimes the default behavior for out-of range
> shifts is to either return 0, or do nothing? Would guess that the default
> behavior should be at least consistent across all of the shift variant's,
> as well as be consistent with the variable operand based shift operand
> behavior. (minimally, likely doing nothing for out-of-range shifts, as
> generating code to implement an undefined behavior may not be necessarily
> prudent?)

I agree.  For all shift patterns, we should consistently:

 - return the input operand unchanged for shifts by 0;
 - do the right thing for shifts between 1 and N-1;
 - return 0 for out-of-range shifts;

I will prepare an updated patch.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/