[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2011-09-04 Thread leopardboy2 at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804

leopardboy2 at yahoo dot com changed:

   What|Removed |Added

 CC||leopardboy2 at yahoo dot
   ||com

--- Comment #27 from leopardboy2 at yahoo dot com 2011-09-04 18:02:22 UTC ---
I had the same failure on GCC 4.6 ( 4.6 branch as of 9/03/2011)  cross building
for m68k.   I added the proposed patch from above and rebuilt GCC and it fixed
it...

Can this fix get put into the 4.6 branch also?


[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2011-07-26 Thread tg at mirbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804

--- Comment #26 from Thorsten Glaser tg at mirbsd dot org 2011-07-26 20:16:22 
UTC ---
Both gcc-4.4 and gcc-4.6 with that patch applied compile memtest.i properly.


[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2011-07-01 Thread tg at mirbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804

--- Comment #25 from Thorsten Glaser tg at mirbsd dot org 2011-07-01 19:36:06 
UTC ---
Applied the diff from svn r172920 to the Debian gcc-4.6 source package as well;
let’s see whether this works.


[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2011-04-28 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|4.5.3   |4.5.4

--- Comment #24 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-28 
14:51:53 UTC ---
GCC 4.5.3 is being released, adjusting target milestone.


[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2011-02-27 Thread mikpe at it dot uu.se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804

Mikael Pettersson mikpe at it dot uu.se changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #21 from Mikael Pettersson mikpe at it dot uu.se 2011-02-27 
09:34:08 UTC ---
*** Bug 47909 has been marked as a duplicate of this bug. ***


[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2010-12-16 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|4.5.2   |4.5.3

--- Comment #20 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-16 
13:03:46 UTC ---
GCC 4.5.2 is being released, adjusting target milestone.


[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2010-10-23 Thread tg at mirbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804

--- Comment #19 from Thorsten Glaser tg at mirbsd dot org 2010-10-23 17:43:59 
UTC ---
I could build gcc-4.4 on Debian with it, and the patch has been included
into the package since. No testsuite runs with it, though – I will do it
on real hardware whose usage I have been offered, but this will take a
while longer. Just so you know.


[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2010-10-18 Thread tg at mirbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804

Thorsten Glaser tg at mirbsd dot org changed:

   What|Removed |Added

 CC||tg at mirbsd dot org

--- Comment #18 from Thorsten Glaser tg at mirbsd dot org 2010-10-18 16:14:04 
UTC ---
I just added your patch (Attachment #20541) to my Debian source package
gcc-4.4_4.4.5-3+m68k.1 – Finn Thain says it fixes that problem for him,
and it does occur in compiling the debugging libstdc++ after bootstrap,
so I will be able to report success (I hope) soonish. Except genattrtab
takes 3.5 hours in 4.4 instead of less than half an hour in 4.3… so, it
will be some days.


[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2010-07-31 Thread rguenth at gcc dot gnu dot org


--- Comment #17 from rguenth at gcc dot gnu dot org  2010-07-31 09:29 
---
GCC 4.5.1 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.5.1   |4.5.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804



[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2010-05-19 Thread rguenth at gcc dot gnu dot org


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804



[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2010-05-10 Thread rsandifo at gcc dot gnu dot org


--- Comment #16 from rsandifo at gcc dot gnu dot org  2010-05-10 19:49 
---
Thanks Andreas.  I don't have access to m68k-elfy targets these days, so could
someone test it just to be sure?  I'll commit if everything goes OK.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rsandifo at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-10 19:49:34
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804



[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2010-05-03 Thread rdsandiford at googlemail dot com


--- Comment #13 from rdsandiford at googlemail dot com  2010-05-03 09:53 
---
Subject: Re:  [4.5/4.6 regression] ICE in reload_cse_simplify_operands

mkuvyrkov at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org writes:
 --- Comment #10 from mkuvyrkov at gcc dot gnu dot org  2010-04-23 10:20 
 ---
 The problem seems to be in Richard's patch
 (http://article.gmane.org/gmane.comp.gcc.patches/130602) checked in r120961.

 All and all, it seems that revision 120961 should be reverted to enable 'T'
 constraint for (flag_pic  !TARGET_PCREL).

 The 's' constraint is defined as
 ==
   case 's':
 if (CONST_INT_P (op)
 || (GET_CODE (op) == CONST_DOUBLE
  GET_MODE (op) == VOIDmode))
   break;
   case 'i':
 if (CONSTANT_P (op))
   win = 1;
 break;
 ==

 So, unless I'm missing something, the statement
 ... 's' doesn't accept anything if flag_pic
 is just wrong.

I meant flag_pic  !TARGET_PCREL, since only the !TARGET_PCREL case
matters for 'T'.  And that was right at the time that I wrote it.
The interesting definition of 's' isn't the one you quote, but the one
in reload:

  case 's':
if (CONST_INT_P (operand)
|| (GET_CODE (operand) == CONST_DOUBLE
 GET_MODE (operand) == VOIDmode))
  break;
  case 'i':
if (CONSTANT_P (operand)
 (! flag_pic || LEGITIMATE_PIC_OPERAND_P (operand)))
  win = 1;
break;

That is, 's' operands have to satisfy LEGITIMATE_PIC_OPERAND_P when
generating PIC.  I'm not sure which version you were quoting, but if it
was constrain_operands, that's a special case.  constrain_operands can
rely on the predicates to check for legitimate PIC operands, so there's
no need to repeat the check there.

At the time I committed the patch, LEGITIMATE_PIC_OPERAND_P was
defined as follows:

#define LEGITIMATE_PIC_OPERAND_P(X) \
  (!symbolic_operand (X, VOIDmode)  \
   || (TARGET_PCREL  REG_STRICT_P))

Thus no symbolic constant was a legitimate PIC operand for
flag_pic  !TARGET_PCREL.  Thus nothing satisfied 's' when
flag_pic  !TARGET_PCREL.

The 'T' constraint is defined as follows:

  satisifies(T) == satisifies(s)  !TARGET_PCREL

so it followed that nothing should match 'T' when flag_pic.

So the patch was correct at the time it was committed.  Please
understand that reverting it is the wrong thing to do.  It would
reintroduce the original bug: that constraints _must not_ match
something that the associated predicates do not.  Only the other
way is allowed: predicates can allow things that the constraints
don't, within certain limits.

For example, let's say you have an insn that matches:

(define_insn subsi3
  [(set (match_operand:SI 0 nonimmediate_operand =mda,m,d,a)
(minus:SI (match_operand:SI 1 general_operand 0,0,0,0)
  (match_operand:SI 2 general_src_operand
I,dT,mSrT,mSrs)))]
  
  @
   subq%.l %2, %0
   sub%.l %2,%0
   sub%.l %2,%0
   sub%.l %2,%0
  [(set_attr type aluq_l,alu_l,alu_l,alu_l)
   (set_attr opy 2)])

And let's suppose that operand 2 is a register that is equal to:

  (symbol_ref x)

If 'T' allows any CONST, SYMBOL_REF or LABEL_REF when flag_pic 
!TARGET_PCREL (as in your suggested patch), reload could quite happily
establish that operand 2 is (symbol_ref x), see that it matches 'T',
and use it.  This will then lead to an unrecognisable insn, because
although the constant matches the 'T' constraint, it doesn't match
general_src_operand.

Instead, the bug is that the 'T' constraint wasn't updated by the TLS
support at the same time as LEGITIMATE_PIC_OPERAND_P was.  An easy thing
to miss, of course.  I think the correct patch is the one I'm about
to attach.

Richard


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804



[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2010-05-03 Thread rsandifo at gcc dot gnu dot org


--- Comment #14 from rsandifo at gcc dot gnu dot org  2010-05-03 09:55 
---
Created an attachment (id=20541)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20541action=view)
proposed patch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804



[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2010-05-03 Thread schwab at linux-m68k dot org


--- Comment #15 from schwab at linux-m68k dot org  2010-05-03 20:17 ---
The patch is ok, please check it in.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804



[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2010-05-02 Thread mkuvyrkov at gcc dot gnu dot org


--- Comment #11 from mkuvyrkov at gcc dot gnu dot org  2010-05-02 18:02 
---
Created an attachment (id=20536)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20536action=view)
Revert previous patch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804



[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

2010-05-02 Thread mkuvyrkov at gcc dot gnu dot org


--- Comment #12 from mkuvyrkov at gcc dot gnu dot org  2010-05-02 18:03 
---
Ping.

Richard S.,
Andreas,

Any comment on the above analysis?

AFAICT, the T constraint should accept operands if flag_pic 
!TARGET_PCREL.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804