[Bug middle-end/57586] ICE when expanding volatile asm using unaligned pointer

2013-06-13 Thread amodra at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586

Alan Modra  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
 CC||amodra at gmail dot com
  Component|target  |middle-end
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com
   Severity|major   |normal

[Bug middle-end/57586] ICE when expanding volatile asm using unaligned pointer

2013-09-24 Thread amodra at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586

--- Comment #6 from Alan Modra  ---
Author: amodra
Date: Tue Sep 24 11:32:28 2013
New Revision: 202866

URL: http://gcc.gnu.org/viewcvs?rev=202866&root=gcc&view=rev
Log:
PR middle-end/57134
PR middle-end/57586
* stmt.c (expand_asm_operands): Call expand_expr with
EXPAND_MEMORY for output operands that disallow regs.  Don't
use EXPAND_WRITE on inout operands.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/stmt.c

[Bug middle-end/57586] ICE when expanding volatile asm using unaligned pointer

2013-09-24 Thread amodra at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #7 from Alan Modra  ---
Fixed

[Bug middle-end/57586] ICE when expanding volatile asm using unaligned pointer

2013-09-29 Thread bernd.edlinger at hotmail dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #8 from Bernd Edlinger  ---
(In reply to Alan Modra from comment #7)
> Fixed

Sorry, this change does not look right,
because you should not use EXPAND_NORMAL for
an output parameter, even if it is no inout.

[Bug middle-end/57586] ICE when expanding volatile asm using unaligned pointer

2013-09-30 Thread amodra at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586

--- Comment #9 from Alan Modra  ---
Once upon a time I understood this code quite well, but it's been a while since
I looked at it in detail, and I'd forgotten that inout gets split to separate
input and output operands if a register is allowed.

So the code isn't wrong, but there was no need to do anything special for
inout.  I'll commit a cleanup as obvious.