Bug 32004 - [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
Summary: [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' whil...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.3.0
: P1 normal
Target Milestone: 4.1.3
Assignee: Not yet assigned to anyone
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: ice-on-valid-code, ra
: 25216 (view as bug list)
Depends on: 19398
Blocks: 32647 23224
  Show dependency treegraph
 
Reported: 2007-05-20 00:31 UTC by H.J. Lu
Modified: 2007-07-17 03:18 UTC (History)
8 users (show)

See Also:
Host:
Target: i686-pc-linux-gnu
Build:
Known to work: 3.4.6 4.1.3 4.2.1 4.3.0
Known to fail: 4.1.2 4.2.0
Last reconfirmed: 2007-07-06 12:18:13


Attachments
patch under testing (2.40 KB, patch)
2007-07-04 08:16 UTC, Paolo Bonzini
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2007-05-20 00:31:19 UTC
This patch

http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00129.html

causes gcc.target/i386/pr21291.c on ia32. Richard, can you take a look? Thanks.
Comment 1 H.J. Lu 2007-05-20 00:34:34 UTC
It fails with

[hjl@gnu-27 gcc]$ ./xgcc -B./ /tmp/pr21291.c -S -O -m32
/tmp/pr21291.c: In function âbng_ia32_mult_sub_digitâ:
/tmp/pr21291.c:23: error: can't find a register in class âGENERAL_REGSâ while reloading âasmâ
/tmp/pr21291.c:23: error: âasmâ operand has impossible constraints
[hjl@gnu-27 gcc]$
Comment 2 Andrew Pinski 2007-05-20 01:13:04 UTC
I already looked at it, forwprop is not fully to blame, it is doing the only thing it knows, it optimizes the values correctly.  This is a pure RA issue as we now run out of registers as we do asm(); if (a != b) instead of doing c = a-b; asm(); if (c) which means we need one more register and the RA does not for some unknown reason spill a and b across the asm.  I don't know if we can call this a regression really, the register allocator has always been this dumb.
Comment 3 H.J. Lu 2007-05-20 01:25:52 UTC
The original fix for the testcase, PR 21291, is in tree-outof-ssa.c. The forwprop
change seems to make the tree-outof-ssa.c fix ineffective.
Comment 4 Richard Biener 2007-05-20 11:20:47 UTC
The out-of-ssa patch was clearly a hack to make this testcase work.  But a real
fix involves ra and reload, none of which is in the list I like to work on ;)
But maybe Micha can try to see if this is related to PR19398 as Uros hints.
See also PR25216 where this testcase fails with -fPIC.  Oh, and it still
passes with -fomit-frame-pointer.
Comment 5 Richard Biener 2007-05-20 11:52:11 UTC
As to comment #2, while we need one more register for the comparison, a and b
are available in the argument frame, so there's no reason to "spill" them, we
just need to reload them into one of the many free registers _after_ the asm().
Instead of leaving us with

(insn 12 15 13 2 /home/richard/src/dataflow-branch/gcc/testsuite/gcc.target/i386/pr21291.c:27 (set (reg:CCZ 17 flags)
        (compare:CCZ (mem/c/i:SI (plus:SI (reg/f:SI 16 argp)
                    (const_int 4 [0x4])) [0 alen+0 S4 A32])
            (mem/c/i:SI (plus:SI (reg/f:SI 6 bp)                    (const_int 20 [0x14])) [0 blen+0 S4 A32]))) 2 {*cmpsi_1_insn} (nil))

which is not matching *cmpsi_1_insn predicates (the above is from greg dump).
Comment 6 H.J. Lu 2007-05-20 21:40:11 UTC
forwprop changes


<bb 2>:
  alen_4 = alen_2(D) - blen_3(D);
  out_5 = 0;
  __asm__("":"=r" a_9, "=r" b_10, "=mr" blen_11, "=mr" out_12, "=&r" tmp_13:"mr"
 d_6(D), "0" a_7(D), "1" b_8(D), "2" blen_3(D), "3" 0:"edx", "eax");
  if (alen_4 == 0)
    goto <bb 3> (<L0>);
  else
    goto <bb 4> (<L1>);

to

<bb 2>:
  out_5 = 0;
  __asm__("":"=r" a_9, "=r" b_10, "=mr" blen_11, "=mr" out_12, "=&r" tmp_13:"mr"
 d_6(D), "0" a_7(D), "1" b_8(D), "2" blen_3(D), "3" 0:"edx", "eax");
  if (alen_2(D) == blen_3(D))
    goto <bb 3> (<L0>);
  else
    goto <bb 4> (<L1>);

If it can use blen_11 instead of blen_3(D), it may compile. If forwprop can't
deal some asm stmts very well, it should skip those asm stmts.
Comment 7 Andrew Pinski 2007-05-20 21:50:41 UTC
> If it can use blen_11 instead of blen_3(D), it may compile. If forwprop can't
> deal some asm stmts very well, it should skip those asm stmts.

It cannot use blen_11 instead of blen_3 because the asm will have changed the value.  forwprop does not even see the asm at all (how would it unless it looked for all SSAnames that had blen in them which is hard to do in the first place?).  What forwprop is doing is legal but creates a little extra register pressure which in turn causes GCC's register allocator to go, I don't know what the fuck to do because I am a stupid register allocator.
Comment 8 Andrew Pinski 2007-05-20 21:51:52 UTC
There is almost nothing that can be done on the tree level to fix up this register allocator issue.
Comment 9 Michael Matz 2007-05-21 07:45:51 UTC
Richard, the problem isn't the compare or where to store the live values
alen and blen (FYI, the store looks invalid, because reload will not
immediately stop when it sees an invalid asm insn, but instead just patch it
out, but it will leave the operands in a funny state, hence the compare insn
looks incorrect).

The problem is the asm instruction itself, and it's actually
the exact same bug as pr21291 , which was worked around by the outof-ssa
change to coalesce both operand, which doesn't work anymore due to the
change in forwprop.  This could have happened also by some other random
transformation, so forwprop isn't at fault.

To recap, the problem goes like this:

You start with 
  int inout, orig;
  orig = inout;
  asm ("": "+mr" (inout));
  use (orig);

which is transformed very early to use explicit output and match operands
(this in fact is the source of all evil, as far as reloads capabilities
are concerned):

  asm ("": "=mr" (inout) : "0" (inout));

Now SSA form properly assigns a new SSA name for the output operand in the
asm to inout, and some other transformation can now make use of the original
SSA name of inout (in this case it's forwprop), so we have:

  asm ("": "=mr" (inout_2) : "0" (inout_1));
  use (inout_1);

Clearly inout_2 and inout_1 can't be coalesced easily anymore, as they
represent two separate values, so they will get different pseudo registers
during expansion.  Pseudos are okay, as we indeed would accept registers
at all in the constraint.  But still from there everything goes downhill:

Both operands need to match per the constraints, but use different pseudo
registers, so they don't match.  The only solution (for reload) is to register
a reload for these operands.  But reloads can only be satisfied by hardregs,
not by memory, so we need a register for this reload, just because we
are presented with non-matching operands.

So, even though we allow memory for this operand, no memory can be used
for it, because both operand parts don't match.  That together with the
other necessary registers will get us over the total limit of 6 available
registers in the end.

So it's a symptom of reload not being able to use memory for reloads
(secondary reloads don't come into play here), a long standing problem.

Alternatively it's also a symptom of both operands not coming into reload as
matching (in which case the pseudo could go to memory just fine, as the
alternative allows it, and no reload would be necessary).

Extending reload to make use of memory for some reloads, where allowed,
might be nice, but is unrealistic in its gory detail (even the secondary mem
support doesn't really help here).

So I think the only feasible fix or work-around is to present reload
with matching operands, where required.  Strictly it's required only
if the alternative allows registers and memory and both operands are different
pseudo regs, all other cases can be handled by reload equally well.

That might still be done in tree form (what the old outof-ssa hack still tries
but can't really work), or in RTL form shortly before reload.
Comment 10 Uroš Bizjak 2007-05-21 08:33:48 UTC
> Extending reload to make use of memory for some reloads, where allowed,
> might be nice, but is unrealistic in its gory detail (even the secondary mem
> support doesn't really help here).

Should we XFAIL this test?
Comment 11 Paolo Bonzini 2007-05-21 08:48:52 UTC
Micha, do you mean transforming (while expanding to RTL)

  asm ("": "=mr" (inout_2) : "0" (inout_1));

to

  inout_2 = inout_1;
  asm ("": "=mr" (inout_2) : "0" (inout_2));

?

That shouldn't be too hard.
Comment 12 Michael Matz 2007-05-21 09:03:21 UTC
Exactly.  If during expansion or at some other time before reload, doesn't
matter that much.  Of course there's a remote possibility that some RTL
passes between expand and reload would do the copy propagation to counter
that transformation.  As inout_2 would have two writes this would require
some data flow analysis in the RTL phase to determine that this copy-prop
is valid.  There's hope that this isn't done, so that nobody would destroy
that work-around again :)
Comment 13 Paolo Bonzini 2007-05-21 09:32:08 UTC
So we'd just be replacing a weak workaround with a stronger (but not definitive) workaround. :-(
Comment 14 Michael Matz 2007-05-21 09:35:37 UTC
Yes.  The place where I would think the work-around to become definitive is
exactly before regclass.  Between it and reload nothing interesting happens
transformation wise.
Comment 15 paolo.bonzini@lu.unisi.ch 2007-05-21 09:41:37 UTC
Subject: Re:  [4.3 regression] : gcc.target/i386/pr21291.c

matz at gcc dot gnu dot org wrote:
> ------- Comment #14 from matz at gcc dot gnu dot org  2007-05-21 09:35 -------
> Yes.  The place where I would think the work-around to become definitive is
> exactly before regclass.  Between it and reload nothing interesting happens
> transformation wise.

I was thinking of the same.  Also, if the patch included adding a 
"cfun->have_asm_statement" flag set during RTL expansion, it would 
probably cost little to do it in an entirely new pass before regclass.

Paolo
Comment 16 H.J. Lu 2007-05-21 15:33:44 UTC
Gcc 4.1/4.2/4.3 will fail and gcc 3.4 has no problem:

---
typedef unsigned long bngdigit;
typedef bngdigit *bng;
typedef unsigned int bngcarry;
typedef unsigned long bngsize;

bngdigit
bng_ia32_mult_sub_digit (bng a, bngsize alen, bng b, bngsize blen, bngdigit d)
{
  bngdigit out, tmp;
  bngcarry carry;
  bngdigit a11;
  int x = blen;

  out = 0;
  asm (""
       : "+r" (a), "+r" (b), "+mr" (blen), "+mr" (out), "=&r" (tmp)
       : "mr" (d)
       : "eax", "edx");
  if (alen == blen)
    {
      a11 = out;
      goto t;
    }

  if (x == 0)
    goto t;

  a11 = 1;
 t:
  return a11;
}
---
Comment 17 Paolo Bonzini 2007-07-04 07:11:28 UTC
I'm working on this, but don't hold your breath (hence not assigning to myself).
Comment 18 Paolo Bonzini 2007-07-04 07:12:05 UTC
*** Bug 25216 has been marked as a duplicate of this bug. ***
Comment 19 Paolo Bonzini 2007-07-04 08:16:22 UTC
Created attachment 13843 [details]
patch under testing


QED (Quite Easily Done :-)
Comment 20 Paolo Bonzini 2007-07-04 13:54:37 UTC
The attached patch makes PR30311 resurface; this seems like a minor problem because that code is dubious, and can be worked around by not doing the transformation when the modes mismatch.
Comment 21 Bernhard Kauer 2007-07-04 21:50:59 UTC
This simple testcase triggers the bug, too. Unfortunatelly I didnot test the patch yet.

--
inline void g(int b)
{
  register int reg __asm__ ("eax") = 0;
  asm volatile ("nop" : "+r"(reg), "+r"(b));
}

void f(int a)
{
  a /= 1000;
  g(a);
}
Comment 22 Paolo Bonzini 2007-07-05 20:11:31 UTC
The patch does not fix this one, which also works in 3.3 and fails in 4.1.  I'm not sure it's 100% the same bug.  Still, I committed the patch to fix the testcase from PR21291.
Comment 23 Paolo Bonzini 2007-07-06 12:08:10 UTC
In particular, this one could be rewritten to

inline void g(int b)
{
  register int reg = 0;
  asm volatile ("nop" : "+a"(reg), "+r"(b));
}

void f(int a)
{
  a /= 1000;
  g(a);
}

but the one in PR21291 could not.
Comment 24 Paolo Bonzini 2007-07-06 12:18:13 UTC
Also, the testcase from comment #21 is not a regression: if we do the inlining manually, it fails in 3.3 too.  The failing testcase is:

void f(int a)
{
  register int reg asm ("eax") = 0;
  a /= 1000;
  asm volatile ("nop" : "+r"(reg), "+r"(a));
}

So I'm opening a new PR.
Comment 25 Paolo Bonzini 2007-07-06 15:10:21 UTC
Subject: Bug 32004

Author: bonzini
Date: Fri Jul  6 15:10:10 2007
New Revision: 126418

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126418
Log:
2007-07-06  Paolo Bonzini  <bonzini@gnu.org>

	PR middle-end/32004
	* function.c (match_asm_constraints_1, rest_of_match_asm_constraints,
	pass_match_asm_constraints): New.
	* passes.c (init_optimization_passes): Add new pass.
	* stmt.c (expand_asm_operands): Set cfun->has_asm_statement.
	* function.h (struct function): Add has_asm_statement bit.
	(current_function_has_asm_statement): New.
	* tree-pass.h (pass_match_asm_constraints): New.


Modified:
    branches/gcc-4_2-branch/gcc/ChangeLog
    branches/gcc-4_2-branch/gcc/function.c
    branches/gcc-4_2-branch/gcc/function.h
    branches/gcc-4_2-branch/gcc/passes.c
    branches/gcc-4_2-branch/gcc/stmt.c
    branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/pr21291.c
    branches/gcc-4_2-branch/gcc/tree-pass.h

Comment 26 Paolo Bonzini 2007-07-06 15:13:06 UTC
Subject: Bug 32004

Author: bonzini
Date: Fri Jul  6 15:12:55 2007
New Revision: 126419

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126419
Log:
2007-07-06  Paolo Bonzini  <bonzini@gnu.org>

	PR middle-end/32004
	* function.c (match_asm_constraints_1, rest_of_match_asm_constraints,
	pass_match_asm_constraints): New.
	* passes.c (init_optimization_passes): Add new pass.
	* stmt.c (expand_asm_operands): Set cfun->has_asm_statement.
	* function.h (struct function): Add has_asm_statement bit.
	(current_function_has_asm_statement): New.
	* tree-pass.h (pass_match_asm_constraints): New.


Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/acinclude.m4
    branches/gcc-4_1-branch/gcc/aclocal.m4
    branches/gcc-4_1-branch/gcc/function.c
    branches/gcc-4_1-branch/gcc/function.h
    branches/gcc-4_1-branch/gcc/passes.c
    branches/gcc-4_1-branch/gcc/stmt.c
    branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/pr21291.c
    branches/gcc-4_1-branch/gcc/tree-pass.h

Comment 27 Paolo Bonzini 2007-07-06 15:13:36 UTC
fixed.
Comment 28 Uroš Bizjak 2007-07-08 10:29:22 UTC
This patch breaks gcc.dg/torture/pr20314-1.c and gcc.dg/torture/pr20314-2.c tests for i386 [1] and x86_64 [2] targets on 4.1 branch:

/home/uros/gcc-svn/branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr20314-
1.c: In function 'f3':
/home/uros/gcc-svn/branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr20314-
1.c:29: internal compiler error: in update_equiv_regs, at local-alloc.c:1117
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

[1]: http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00314.html
[2]: http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00315.html
Comment 29 Uroš Bizjak 2007-07-08 10:32:23 UTC
(In reply to comment #28)
> This patch breaks gcc.dg/torture/pr20314-1.c and gcc.dg/torture/pr20314-2.c
> tests for i386 [1] and x86_64 [2] targets on 4.1 branch:

Also on 4.2 branch [1].

[1]: http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00316.html
Comment 30 Paolo Bonzini 2007-07-09 15:37:49 UTC
Subject: Bug 32004

Author: bonzini
Date: Mon Jul  9 15:37:32 2007
New Revision: 126487

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126487
Log:
2007-07-09  Paolo Bonzini  <bonzini@gnu.org>

	PR middle-end/32004
	* function.c (rest_of_match_asm_constraints): Pass PROP_REG_INFO.

Modified:
    branches/gcc-4_2-branch/gcc/ChangeLog
    branches/gcc-4_2-branch/gcc/function.c

Comment 31 Paolo Bonzini 2007-07-09 15:38:15 UTC
Subject: Bug 32004

Author: bonzini
Date: Mon Jul  9 15:37:56 2007
New Revision: 126488

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126488
Log:
2007-07-09  Paolo Bonzini  <bonzini@gnu.org>

        PR middle-end/32004
        * function.c (rest_of_match_asm_constraints): Pass PROP_REG_INFO.

Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/function.c

Comment 32 Paolo Bonzini 2007-07-09 15:38:21 UTC
additional fix committed.
Comment 33 Kazumoto Kojima 2007-07-12 01:11:12 UTC
It seems that the patch 126418 causes an ICE for gcc.dg/asm-4.c
and the patch 126487 breaks gcc.c-torture/compile/20000804-1.c
on 4.2 for SH.  Both failures happen only with -O0.  It looks
ia64 testresults show similar errors:

http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00309.html
http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00446.html

on 4.2.
Comment 34 paolo.bonzini@lu.unisi.ch 2007-07-12 19:01:08 UTC
Subject: Re:  [4.1/4.2/4.3 regression] : can't find
 a register in class 'GENERAL_REGS' while reloading 'asm'

kkojima at gcc dot gnu dot org wrote:
> ------- Comment #33 from kkojima at gcc dot gnu dot org  2007-07-12 01:11 -------
> It seems that the patch 126418 causes an ICE for gcc.dg/asm-4.c
> and the patch 126487 breaks gcc.c-torture/compile/20000804-1.c
> on 4.2 for SH.  Both failures happen only with -O0.  It looks
> ia64 testresults show similar errors:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00309.html
> http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00446.html
> 
> on 4.2.

I'll take a look, and revert the patches on 4.1, tomorrow.

Thanks,

Paolo
Comment 35 Paolo Bonzini 2007-07-13 09:28:29 UTC
Subject: Bug 32004

Author: bonzini
Date: Fri Jul 13 09:28:16 2007
New Revision: 126616

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126616
Log:
2007-07-13  Paolo Bonzini  <bonzini@gnu.org>

	Revert these patches:

	2007-07-09  Paolo Bonzini  <bonzini@gnu.org>

        PR middle-end/32004
        * function.c (rest_of_match_asm_constraints): Pass PROP_REG_INFO.

	2007-07-06  Paolo Bonzini  <bonzini@gnu.org>

	PR middle-end/32004
	* function.c (match_asm_constraints_1, rest_of_match_asm_constraints,
	pass_match_asm_constraints): New.
	* passes.c (init_optimization_passes): Add new pass.
	* stmt.c (expand_asm_operands): Set cfun->has_asm_statement.
	* function.h (struct function): Add has_asm_statement bit.
	(current_function_has_asm_statement): New.
	* tree-pass.h (pass_match_asm_constraints): New.


Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/function.c
    branches/gcc-4_1-branch/gcc/function.h
    branches/gcc-4_1-branch/gcc/passes.c
    branches/gcc-4_1-branch/gcc/stmt.c
    branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/pr21291.c
    branches/gcc-4_1-branch/gcc/tree-pass.h

Comment 36 paolo.bonzini@lu.unisi.ch 2007-07-13 09:57:25 UTC
Subject: Re:  [4.1/4.2/4.3 regression] : can't find
 a register in class 'GENERAL_REGS' while reloading 'asm'

kkojima at gcc dot gnu dot org wrote:
> ------- Comment #33 from kkojima at gcc dot gnu dot org  2007-07-12 01:11 -------
> It seems that the patch 126418 causes an ICE for gcc.dg/asm-4.c
> and the patch 126487 breaks gcc.c-torture/compile/20000804-1.c
> on 4.2 for SH.  Both failures happen only with -O0.  It looks
> ia64 testresults show similar errors:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00309.html
> http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00446.html

The former is easy and I have a patch.  I don't understand the latter 
instead, it looks like (on sh at least) reload is not able to make a 
valid address and it might be a latent bug.  Could anybody look at it?

Paolo
Comment 37 Rob 2007-07-17 03:10:56 UTC
We might want to test "-mfixed-range=REGISTER-RANGE" while we are checking that this bug is completely fixed.
Comment 38 Andrew Pinski 2007-07-17 03:18:50 UTC
(In reply to comment #37)
> We might want to test "-mfixed-range=REGISTER-RANGE" while we are checking that
> this bug is completely fixed.

That option does not exist for x86. 
Comment 39 Paolo Bonzini 2007-07-18 09:02:48 UTC
Subject: Bug 32004

Author: bonzini
Date: Wed Jul 18 09:02:38 2007
New Revision: 126715

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126715
Log:
2007-07-18  Paolo Bonzini  <bonzini@gnu.org>

	Revert:

	2007-07-09  Paolo Bonzini  <bonzini@gnu.org>

	PR middle-end/32004
	* function.c (rest_of_match_asm_constraints): Pass PROP_REG_INFO.

	2007-07-06  Paolo Bonzini  <bonzini@gnu.org>

	PR middle-end/32004
	* function.c (match_asm_constraints_1, rest_of_match_asm_constraints,
	pass_match_asm_constraints): New.
	* passes.c (init_optimization_passes): Add new pass.
	* stmt.c (expand_asm_operands): Set cfun->has_asm_statement.
	* function.h (struct function): Add has_asm_statement bit.
	(current_function_has_asm_statement): New.
	* tree-pass.h (pass_match_asm_constraints): New.


Modified:
    branches/bonzini-4_2-branch-pr32004-reverted/gcc/ChangeLog
    branches/bonzini-4_2-branch-pr32004-reverted/gcc/function.c
    branches/bonzini-4_2-branch-pr32004-reverted/gcc/function.h
    branches/bonzini-4_2-branch-pr32004-reverted/gcc/passes.c
    branches/bonzini-4_2-branch-pr32004-reverted/gcc/stmt.c
    branches/bonzini-4_2-branch-pr32004-reverted/gcc/testsuite/gcc.target/i386/pr21291.c
    branches/bonzini-4_2-branch-pr32004-reverted/gcc/tree-pass.h

Comment 40 Mark Mitchell 2007-07-19 03:25:43 UTC
Subject: Bug 32004

Author: mmitchel
Date: Thu Jul 19 03:25:32 2007
New Revision: 126740

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126740
Log:
	Revert:

	2007-07-09  Paolo Bonzini  <bonzini@gnu.org>

	PR middle-end/32004
	* function.c (rest_of_match_asm_constraints): Pass PROP_REG_INFO.

	2007-07-06  Paolo Bonzini  <bonzini@gnu.org>

	PR middle-end/32004
	* function.c (match_asm_constraints_1, rest_of_match_asm_constraints,
	pass_match_asm_constraints): New.
	* passes.c (init_optimization_passes): Add new pass.
	* stmt.c (expand_asm_operands): Set cfun->has_asm_statement.
	* function.h (struct function): Add has_asm_statement bit.
	(current_function_has_asm_statement): New.
	* tree-pass.h (pass_match_asm_constraints): New.

Modified:
    branches/gcc-4_2-branch/gcc/ChangeLog
    branches/gcc-4_2-branch/gcc/function.c
    branches/gcc-4_2-branch/gcc/function.h
    branches/gcc-4_2-branch/gcc/passes.c
    branches/gcc-4_2-branch/gcc/stmt.c
    branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/pr21291.c
    branches/gcc-4_2-branch/gcc/tree-pass.h