[Bug other/18910] ice with -O2 / works fine with -O0.

[Bug other/18910] ice with -O2 / works fine with -O0.

[pluto at pld-linux dot org]

------- Additional Comments From pluto at pld-linux dot org  2004-12-09 20:08 -------
Created an attachment (id=7716)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7716&action=view)
testcase


-- 


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

[Bug other/18910] New: ice with -O2 / works fine with -O0.

[pluto at pld-linux dot org]

# gcc tst-tls4modb.i -c -O2 
tst-tls4modb.c: In function 'test1': 
tst-tls4modb.c:50: error: unrecognizable insn: 
(insn:HI 89 46 82 3 (set (reg/f:SI 68 [ D.6399 ]) 
        (const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x1a] <var_decl 
0xb7c7fef4 foo>) 
                (const_int 32 [0x20])))) -1 (nil) 
    (expr_list:REG_EQUAL (const:SI (plus:SI (symbol_ref:SI ("foo") [flags 
0x1a] <var_decl 0xb7c7fef4 foo>) 
                (const_int 32 [0x20]))) 
        (nil))) 
tst-tls4modb.c:50: internal compiler error: in extract_insn, at recog.c:2020

-- 
           Summary: ice with -O2 / works fine with -O0.
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pluto at pld-linux dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: pentium3-pld-linux
  GCC host triplet: pentium3-pld-linux
GCC target triplet: pentium3-pld-linux


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

[Bug target/18910] [4.0 Regression] ice with -O2 / works fine with -O0.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-09 20:27 -------
Reduced testcase:
static __thread void *foo [2];
void
test1 (void)
{
  unsigned int s;

  for (s = 0; s < 2; ++s)
      foo [s] = &foo[s];
}

: Search converges between 2004-11-24-161001-trunk (#655) and 2004-11-25-014001-trunk 
(#656).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|other                       |target
     Ever Confirmed|                            |1
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|0000-00-00 00:00:00         |2004-12-09 20:27:12
               date|                            |
            Summary|ice with -O2 / works fine   |[4.0 Regression] ice with -
                   |with -O0.                   |O2 / works fine with -O0.
   Target Milestone|---                         |4.0.0


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

[Bug target/18910] [4.0 Regression] ice with -O2 / works fine with -O0.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-09 20:36 -------
Here is another reduced testcase which shows it is an earlier regression than what the dates are:
static __thread void *foo [2];
test1 ()
{
  void * * ivtmp12;

  ivtmp12 = &foo[0];
L0:;
  *ivtmp12 = ivtmp12;
  ivtmp12++;
  if (&foo[2] != ivtmp12) goto L0;
}

: Search converges between 2004-10-17-014001-trunk (#594) and 2004-10-17-161001-trunk 
(#595).

-- 


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

[Bug target/18910] [4.0 Regression] ice with -O2 / works fine with -O0.

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-09 20:38 -------
(In reply to comment #3)
> Here is another reduced testcase which shows it is an earlier regression than what the dates are:
I should note that my testcase also fails at -O0.

-- 


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 11:18 -------
Backtrace from amd64 (Prescott) at -O0

#0  fancy_abort (file=0x95711e "../../mainline/gcc/recog.c", line=2020,
    function=0x957139 "extract_insn") at diagnostic.c:556
#1  0x0000000000766d08 in _fatal_insn (msgid=0x95e5fb "unrecognizable insn:",
    insn=0x2a95895cd0, file=0x95711e "../../mainline/gcc/recog.c", line=2020,
    function=0x957139 "extract_insn") at rtl-error.c:120
#2  0x0000000000766d45 in _fatal_insn_not_found (insn=0x2a95895cd0,
    file=0x95711e "../../mainline/gcc/recog.c", line=2020,
    function=0x957139 "extract_insn") at rtl-error.c:128
#3  0x000000000072d290 in extract_insn (insn=0x2a95895cd0) at recog.c:2020
#4  0x0000000000737b58 in scan_one_insn (insn=0x2a95895cd0, pass=0) at
regclass.c:1048
#5  0x0000000000738225 in regclass (f=0x2a959ee3c0, nregs=66, dump=0x0)
    at regclass.c:1253
#6  0x000000000079ef0c in rest_of_handle_old_regalloc () at passes.c:491
#7  0x00000000007a0dc6 in rest_of_compilation () at passes.c:1718

t.c: In function 'test1':
t.c:11: error: unrecognizable insn:
(insn 21 19 22 2 (set (reg/f:DI 58 [ D.1469 ])
        (const:DI (plus:DI (symbol_ref:DI ("foo") [flags 0x22] <var_decl
0x2a9598f540 foo>)
                (const_int 16 [0x10])))) -1 (nil)
    (nil))


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|pentium3-pld-linux          |
   GCC host triplet|pentium3-pld-linux          |
 GCC target triplet|pentium3-pld-linux          |
            Summary|[4.0 Regression] ice with - |[4.0 Regression]
                   |O2 / works fine with -O0.   |unrecognisable insn in
                   |                            |regclass on x86/amd64


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 11:35 -------
Not the same but maybe related:

1   static __thread void *foo [2];
2                                                                              
       
3   test1 ()
4   {
5     void **D, **ivtmp12;
6   L0:;
7     D = &foo[2];
8     if (D != ivtmp12) goto L0;
9   }

$ ./cc1 f.c
 test1
 
f.c: In function 'test1':
f.c:9: error: impossible constraint in 'asm'

What asm...?


-- 


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 11:44 -------
Minimal test case:
$ cat t.c
static __thread void *foo[2];
test1 ()
{
  void **ivtmp12;
  while (&foo[1] != ivtmp12);
}

$ ../cc1 t.c -fdump-rtl-expand-details
 test1
 
t.c: In function 'test1':
t.c:6: error: unrecognizable insn:
(insn 9 7 10 1 (set (reg/f:DI 58 [ D.1471 ])
        (const:DI (plus:DI (symbol_ref:DI ("foo") [flags 0x22] <var_decl
0x2a9598f540 foo>)
                (const_int 8 [0x8])))) -1 (nil)
    (nil))
t.c:6: internal compiler error: in extract_insn, at recog.c:2020


Removing __thread makes the ICE go away.  It definitely looks related to
the error from comment #6, the insn that causes the ICE is precisely the
statement that is rejected when I feed the gimplified test case to the
compiler:

;; D.1471 = &foo[1]
(insn 9 7 0 (set (reg:DI 58 [ D.1471 ])
        (const:DI (plus:DI (symbol_ref:DI ("foo") [flags 0x22] <var_decl
0x2a9598f540 foo>)
                (const_int 8 [0x8])))) -1 (nil)
    (nil))


-- 


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 11:47 -------
Without __thread, insn 9 is almost identical except for the flags (this is
with -m32 fwiw):

 ;; D.1123 = &foo[1]
 (insn 9 7 0 (set (reg:SI 58 [ D.1123 ])
-        (const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x2] <var_decl
0x2a95962620 foo>)
+        (const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x22] <var_decl
0x2a95962620 foo>)
                 (const_int 4 [0x4])))) -1 (nil)
     (nil))


-- 


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 11:52 -------
The fail dates from comment #3 probably refer to this change

2004-10-17  Andrew Pinski  <pinskia@physics.uc.edu>
                                                                                
        * c-typeck.c (default_function_array_conversion): Always create
        &a[0] for array types.
        (build_unary_op): Do not fold &a[x] into a + x.

which was reverted again on the same day.  Can someone try with the reghunter
to see if it failed before October 17 also?



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.0.0
      Known to work|                            |3.3.4


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 12:04 -------
GCC 3.3.5 (SUSE 9.2) produces this RTL for the ICEing statement:

(insn 11 10 12 (nil) (set (reg:DI 61)
        (symbol_ref:DI ("foo"))) -1 (nil)
    (nil))
                                                                               
                                                  
(insn 12 11 13 (nil) (parallel [
            (set (reg:DI 60)
                (plus:DI (reg:DI 61)
                    (const_int 8 [0x8])))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil)
    (nil))



-- 


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 14:14 -------
Note the date for C++ is different:
: Search converges between 2004-08-30-trunk (#529) and 2004-08-31-trunk (#530).

-- 


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 14:18 -------
(In reply to comment #9)
> The fail dates from comment #3 probably refer to this change
> 
> 2004-10-17  Andrew Pinski  <pinskia@physics.uc.edu>
>                                                                                 
>         * c-typeck.c (default_function_array_conversion): Always create
>         &a[0] for array types.
>         (build_unary_op): Do not fold &a[x] into a + x.
> 
> which was reverted again on the same day.  Can someone try with the reghunter
> to see if it failed before October 17 also?

What this tells me it is a latent bug in x86/x86_64 back-end as my change should not change what RTL 
is produced as it is the back-end's job to reject addressing modes.

-- 


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-12 21:24 -------
(In reply to comment #12)
> (In reply to comment #9)
> > The fail dates from comment #3 probably refer to this change 
> What this tells me it is a latent bug in x86/x86_64 back-end as my change should not change what 
> RTL  is produced as it is the back-end's job to reject addressing modes.

One more thing, the recent change which caused this was fold combining &a + 8 into &a[2] so again 
this is a latent bug in the target.

-- 


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-12-13 08:33 -------
If it's a target bug, let's pester Honza with it :-)

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jh at suse dot cz


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 23:35 -------
*** Bug 19000 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl at lucon dot org


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2004-12-15 20:08 -------
Something is very strange:

[hjl@gnu-10 thread]$ cat do.c
extern __thread void *foo [];
void
test1 (void)
{
  int s;
  for (s = 0; s < 2; ++s)
    {
      foo [s] = &foo[s];
    }
}
[hjl@gnu-10 thread]$ /export/build/gnu/gcc/build-i686-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-i686-linux/gcc/ -O -S do.c
do.c: In function \uffff\uffff\ufffftest1\uffff\uffff\uffff:
do.c:10: error: unrecognizable insn:
(insn 53 21 46 0 (set (reg/f:SI 67 [ D.1151 ])
        (const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x58] <var_decl
0xb7d5e828 foo>)
                (const_int 8 [0x8])))) -1 (nil)
    (expr_list:REG_EQUAL (const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x58]
<var_decl 0xb7d5e828 foo>)
                (const_int 8 [0x8])))
        (nil)))
do.c:10: internal compiler error: in extract_insn, at recog.c:2020
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
[hjl@gnu-10 thread]$ cat do.c extern __thread void *foo [];
void
test1 (void)
{
  int s;
  for (s = 0; s < 2U; ++s)
    {
      foo [s] = &foo[s];
    }
}
[hjl@gnu-10 thread]$ /export/build/gnu/gcc/build-i686-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-i686-linux/gcc/ -O -S do.c

"2U" vs. "2" makes a big difference here.


-- 


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[aj at gcc dot gnu dot org]

------- Additional Comments From aj at gcc dot gnu dot org  2004-12-17 08:01 -------
*** Bug 19029 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aj at gcc dot gnu dot org


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[gschafer at zip dot com dot au]

------- Additional Comments From gschafer at zip dot com dot au  2005-01-01 01:18 -------
I've just hit this while trying to build Glibc with current GCC trunk. It's a
showstopper.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gschafer at zip dot com dot
                   |                            |au


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[aj at gcc dot gnu dot org]

------- Additional Comments From aj at gcc dot gnu dot org  2005-01-01 06:36 -------
Raise priority since this hits glibc. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P1


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2005-01-01 22:16 -------
I believe that the regression is caused by

http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg01166.html

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu dot org


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2005-01-01 22:21 -------
This is the original thread which leads to this regession:

http://gcc.gnu.org/ml/gcc/2004-11/threads.html#00839

-- 


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-01 22:33 -------
(In reply to comment #21)
> This is the original thread which leads to this regession:
> 
> http://gcc.gnu.org/ml/gcc/2004-11/threads.html#00839

If you notice this works on all other targets other than x86/x86_64 which means that it is a latent bug 
in the x86 back-end.

-- 


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[jh at suse dot cz]

------- Additional Comments From jh at suse dot cz  2005-01-01 23:52 -------
Subject: Re:  [4.0 Regression] unrecognisable insn in regclass on x86/amd64

> 
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-01 22:33 -------
> (In reply to comment #21)
> > This is the original thread which leads to this regession:
> > 
> > http://gcc.gnu.org/ml/gcc/2004-11/threads.html#00839
> 
> If you notice this works on all other targets other than x86/x86_64 which means that it is a latent bug 
> in the x86 back-end.
the problem seems to be loop optimizer taking the 
        (const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x58] <var_decl 0xb7d5e828 foo>) (const_int 8 [0x8]))
construct from REG_EQUAL note and throwing it into emit_move_insn
without any care.

I don't think emit_move_insn is required to deal with arbitary constant
operand like this, so it seems to me that correct (and safe) way is to
prevent loop from this idea...  I am testing attached patch.  But we
might also teach move expander to decompose the CONST and legitimize it
as we do for usual variable references...

Honza

Index: loop.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/loop.c,v
retrieving revision 1.518
diff -c -3 -p -r1.518 loop.c
*** loop.c	18 Dec 2004 07:55:35 -0000	1.518
--- loop.c	1 Jan 2005 23:47:22 -0000
*************** scan_loop (struct loop *loop, int flags)
*** 1149,1160 ****
  		 Otherwise, only use the REG_EQUAL contents if a REG_RETVAL
  		 note is present.  */
  	      temp = find_reg_note (p, REG_EQUIV, NULL_RTX);
! 	      if (temp)
  		src = XEXP (temp, 0), move_insn = 1;
  	      else
  		{
  		  temp = find_reg_note (p, REG_EQUAL, NULL_RTX);
! 		  if (temp && CONSTANT_P (XEXP (temp, 0)))
  		    src = XEXP (temp, 0), move_insn = 1;
  		  if (temp && find_reg_note (p, REG_RETVAL, NULL_RTX))
  		    {
--- 1149,1161 ----
  		 Otherwise, only use the REG_EQUAL contents if a REG_RETVAL
  		 note is present.  */
  	      temp = find_reg_note (p, REG_EQUIV, NULL_RTX);
! 	      if (temp && general_operand (XEXP (temp, 0), VOIDmode))
  		src = XEXP (temp, 0), move_insn = 1;
  	      else
  		{
  		  temp = find_reg_note (p, REG_EQUAL, NULL_RTX);
! 		  if (temp && CONSTANT_P (XEXP (temp, 0))
! 		      && LEGITIMATE_CONSTANT_P (XEXP (temp, 0)))
  		    src = XEXP (temp, 0), move_insn = 1;
  		  if (temp && find_reg_note (p, REG_RETVAL, NULL_RTX))
  		    {


-- 


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[jh at suse dot cz]

------- Additional Comments From jh at suse dot cz  2005-01-02 00:14 -------
Subject: Re:  [4.0 Regression] unrecognisable insn in regclass on x86/amd64

> 
> ------- Additional Comments From jh at suse dot cz  2005-01-01 23:52 -------
> Subject: Re:  [4.0 Regression] unrecognisable insn in regclass on x86/amd64
> 
> > 
> > ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-01 22:33 -------
> > (In reply to comment #21)
> > > This is the original thread which leads to this regession:
> > > 
> > > http://gcc.gnu.org/ml/gcc/2004-11/threads.html#00839
> > 
> > If you notice this works on all other targets other than x86/x86_64 which means that it is a latent bug 
> > in the x86 back-end.
> the problem seems to be loop optimizer taking the 
>         (const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x58] <var_decl 0xb7d5e828 foo>) (const_int 8 [0x8]))
> construct from REG_EQUAL note and throwing it into emit_move_insn
> without any care.
> 
> I don't think emit_move_insn is required to deal with arbitary constant
> operand like this, so it seems to me that correct (and safe) way is to
> prevent loop from this idea...  I am testing attached patch.  But we
> might also teach move expander to decompose the CONST and legitimize it
> as we do for usual variable references...

Hmm, actually I now recall that last time we went across similar problem
(cse constructing crazy CONST expression later used by loop same sick
way) we decided to restrict cse to construct sane CONSTs and producing
offsetted reference to TLS seems to be quite sane, so perhaps fixing it
other way around is better.  Here is the patch I am testing ;)

Index: config/i386/i386.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.766
diff -c -3 -p -r1.766 i386.c
*** config/i386/i386.c	28 Dec 2004 05:26:23 -0000	1.766
--- config/i386/i386.c	2 Jan 2005 00:11:53 -0000
*************** ix86_expand_move (enum machine_mode mode
*** 7472,7478 ****
    op0 = operands[0];
    op1 = operands[1];
  
!   model = GET_CODE (op1) == SYMBOL_REF ? SYMBOL_REF_TLS_MODEL (op1) : 0;
    if (model)
      {
        op1 = legitimize_tls_address (op1, model, true);
--- 7472,7484 ----
    op0 = operands[0];
    op1 = operands[1];
  
!   if (GET_CODE (op1) == CONST && GET_CODE (XEXP (op1, 0)) == PLUS
!       && GET_CODE (XEXP (XEXP (op1, 0), 0)) == SYMBOL_REF)
!     model = SYMBOL_REF_TLS_MODEL (XEXP (XEXP (op1, 0), 0));
!   else if (GET_CODE (op1) == SYMBOL_REF)
!     model = SYMBOL_REF_TLS_MODEL (op1);
!   else
!     model = 0;
    if (model)
      {
        op1 = legitimize_tls_address (op1, model, true);


-- 


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-02 16:04 -------
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00034.html>.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-05 20:29 -------
Subject: Bug 18910

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rth@gcc.gnu.org	2005-01-05 20:29:06

Modified files:
	gcc            : ChangeLog 
	gcc/config/i386: i386.c 
Added files:
	gcc/testsuite/gcc.dg/tls: opt-8.c 

Log message:
	PR target/18910
	* config/i386/i386.c (ix86_expand_move): Handle tls symbols
	with an offset.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7039&r2=2.7040
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.768&r2=1.769
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tls/opt-8.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-01-05 20:31 -------
Fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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