[Patch] PR 61692 - Fix for inline asm ICE

[Patch] PR 61692 - Fix for inline asm ICE

[David Wohlferd]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

I'm not sure which maintainer to cc for inline asm stuff?

I have a release on file with the FSF, but don't have SVN write access.

Problem:
extract_insn() in recog.c will ICE if (noperands > MAX_RECOG_OPERANDS).  
Normally this isn't a problem since expand_asm_operands() in cfgexpand.c 
catches and reports a proper error for this condition.  However, 
expand_asm_operands() only checks (ninputs + noutputs) instead of 
(ninputs + noutputs + nlabels), so you can get the ICE when using "asm 
goto."  See the bugzilla entry for sample code.

ChangeLog:
2014-07-27  David Wohlferd  <dw@LimeGreenSocks.com>

         PR target/61692
         * cfgexpand.c (expand_asm_operands): Count all inline asm 
parameters.

dw

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: cfgexpand.c.patch --]
[-- Type: text/x-patch; name="cfgexpand.c.patch", Size: 409 bytes --]

Index: cfgexpand.c
===================================================================
--- cfgexpand.c	(revision 212900)
+++ cfgexpand.c	(working copy)
@@ -2554,7 +2554,7 @@
     }
 
   ninputs += ninout;
-  if (ninputs + noutputs > MAX_RECOG_OPERANDS)
+  if (ninputs + noutputs + nlabels > MAX_RECOG_OPERANDS)
     {
       error ("more than %d operands in %<asm%>", MAX_RECOG_OPERANDS);
       return;

Re: [Patch] PR 61692 - Fix for inline asm ICE

[Jeff Law]

On 07/27/14 01:26, David Wohlferd wrote:
> I'm not sure which maintainer to cc for inline asm stuff?
>
> I have a release on file with the FSF, but don't have SVN write access.
>
> Problem:
> extract_insn() in recog.c will ICE if (noperands > MAX_RECOG_OPERANDS).
> Normally this isn't a problem since expand_asm_operands() in cfgexpand.c
> catches and reports a proper error for this condition.  However,
> expand_asm_operands() only checks (ninputs + noutputs) instead of
> (ninputs + noutputs + nlabels), so you can get the ICE when using "asm
> goto."  See the bugzilla entry for sample code.
>
> ChangeLog:
> 2014-07-27  David Wohlferd  <dw@LimeGreenSocks.com>
>
>          PR target/61692
>          * cfgexpand.c (expand_asm_operands): Count all inline asm
> parameters.
You should also include 'nclobbers'.

jeff

Re: [Patch] PR 61692 - Fix for inline asm ICE

[David Wohlferd]

On 7/28/2014 12:42 PM, Jeff Law wrote:
> On 07/27/14 01:26, David Wohlferd wrote:
>> I'm not sure which maintainer to cc for inline asm stuff?
>>
>> I have a release on file with the FSF, but don't have SVN write access.
>>
>> Problem:
>> extract_insn() in recog.c will ICE if (noperands > MAX_RECOG_OPERANDS).
>> Normally this isn't a problem since expand_asm_operands() in cfgexpand.c
>> catches and reports a proper error for this condition.  However,
>> expand_asm_operands() only checks (ninputs + noutputs) instead of
>> (ninputs + noutputs + nlabels), so you can get the ICE when using "asm
>> goto."  See the bugzilla entry for sample code.
>>
>> ChangeLog:
>> 2014-07-27  David Wohlferd  <dw@LimeGreenSocks.com>
>>
>>          PR target/61692
>>          * cfgexpand.c (expand_asm_operands): Count all inline asm
>> parameters.
> You should also include 'nclobbers'.

Reading thru asm_noperands (which is what extract_insn uses to count 
operands), I would have thought you were right.  But while making this 
fail with nLabels was easy, I wasn't able to get this to ICE at all 
using clobbers (30 labels + 11 clobbers still didn't ICE).

And I'm reluctant to propose that change unless I can see it fail.

dw

Re: [Patch] PR 61692 - Fix for inline asm ICE

[Jeff Law]

On 07/28/14 16:39, David Wohlferd wrote:
>
> On 7/28/2014 12:42 PM, Jeff Law wrote:
>> On 07/27/14 01:26, David Wohlferd wrote:
>>> I'm not sure which maintainer to cc for inline asm stuff?
>>>
>>> I have a release on file with the FSF, but don't have SVN write access.
>>>
>>> Problem:
>>> extract_insn() in recog.c will ICE if (noperands > MAX_RECOG_OPERANDS).
>>> Normally this isn't a problem since expand_asm_operands() in cfgexpand.c
>>> catches and reports a proper error for this condition.  However,
>>> expand_asm_operands() only checks (ninputs + noutputs) instead of
>>> (ninputs + noutputs + nlabels), so you can get the ICE when using "asm
>>> goto."  See the bugzilla entry for sample code.
>>>
>>> ChangeLog:
>>> 2014-07-27  David Wohlferd  <dw@LimeGreenSocks.com>
>>>
>>>          PR target/61692
>>>          * cfgexpand.c (expand_asm_operands): Count all inline asm
>>> parameters.
>> You should also include 'nclobbers'.
>
> Reading thru asm_noperands (which is what extract_insn uses to count
> operands), I would have thought you were right.  But while making this
> fail with nLabels was easy, I wasn't able to get this to ICE at all
> using clobbers (30 labels + 11 clobbers still didn't ICE).
>
> And I'm reluctant to propose that change unless I can see it fail.
I understand, but I'm still quite confident it's the right thing to do. 
  Running that 30 label + 11 clobber testcase under valgrind might show 
the problem, if you can stand waiting that long...


Also, please include the testcase you had nlabels part.

Jeff

Re: [Patch] PR 61692 - Fix for inline asm ICE

[David Wohlferd]

On 7/30/2014 9:58 PM, Jeff Law wrote:
> On 07/28/14 16:39, David Wohlferd wrote:
>>
>> On 7/28/2014 12:42 PM, Jeff Law wrote:
>>> On 07/27/14 01:26, David Wohlferd wrote:
>>>> I'm not sure which maintainer to cc for inline asm stuff?
>>>>
>>>> I have a release on file with the FSF, but don't have SVN write 
>>>> access.
>>>>
>>>> Problem:
>>>> extract_insn() in recog.c will ICE if (noperands > 
>>>> MAX_RECOG_OPERANDS).
>>>> Normally this isn't a problem since expand_asm_operands() in 
>>>> cfgexpand.c
>>>> catches and reports a proper error for this condition. However,
>>>> expand_asm_operands() only checks (ninputs + noutputs) instead of
>>>> (ninputs + noutputs + nlabels), so you can get the ICE when using "asm
>>>> goto."  See the bugzilla entry for sample code.
>>>>
>>>> ChangeLog:
>>>> 2014-07-27  David Wohlferd  <dw@LimeGreenSocks.com>
>>>>
>>>>          PR target/61692
>>>>          * cfgexpand.c (expand_asm_operands): Count all inline asm
>>>> parameters.
>>> You should also include 'nclobbers'.
>>
>> Reading thru asm_noperands (which is what extract_insn uses to count
>> operands), I would have thought you were right.  But while making this
>> fail with nLabels was easy, I wasn't able to get this to ICE at all
>> using clobbers (30 labels + 11 clobbers still didn't ICE).
>>
>> And I'm reluctant to propose that change unless I can see it fail.
> I understand, but I'm still quite confident it's the right thing to 
> do.  Running that 30 label + 11 clobber testcase under valgrind might 
> show the problem, if you can stand waiting that long...

I'd love to.  Unfortunately, my platform doesn't support valgrind.

> Also, please include the testcase you had nlabels part.

I have created the testcase for the 31 labels problem.  However, not so 
much for the nclobbers part.  And if I'm going to patch both, I should 
have testcases for both.

I also worry about potentially breaking existing code.  While the 31 
labels thing I proposed won't break existing code (it would have been 
ICE-ing), adding nclobbers to the count of parameters could do so.

When Jeff Law says that something is so about gcc, I tend to believe 
that it is so.  But, unless I can see an example of the actual problem 
here, I have no idea how to create a test case for it.  So I spent the 
last several hours hunting for it.

If valgrind was going to show the problem, presumably we were expecting 
some type of array overrun.  And there are a LOT of places that do 
foo[MAX_RECOG_OPERANDS].  Absent valgrind, I resorted to using printfs 
sprinkled throughout the code to check indices. However, despite my best 
efforts, I was unable to see any out of range accesses, gcc_asserts, 
segment faults or any other indications of a problem.  All the places I 
tried seem to treat clobbers separately.  That doesn't prove anything: I 
could easily have missed something.  But I did make a sincere effort.

Given how confident you are that there's a problem, could you point out 
a place+condition I should focus on?  That way I can create the 
additional test case, satisfy my curiosity, and sleep soundly at night 
knowing I haven't (unnecessarily) broken people's code.

Thanks,
dw

Re: [Patch] PR 61692 - Fix for inline asm ICE

[Jeff Law]

On 08/01/14 02:07, David Wohlferd wrote:
>
> I'd love to.  Unfortunately, my platform doesn't support valgrind.
Ah.

>
>> Also, please include the testcase you had nlabels part.
>
> I have created the testcase for the 31 labels problem.  However, not so
> much for the nclobbers part.  And if I'm going to patch both, I should
> have testcases for both.
Tell you what, pass along what you've got and I'll run it under valgrind 
here.  I'm quite confident both need to be changed -- though it is 
possible nothing will trigger with the nclobbers stuff if it is indeed 
handled separately throughout the guts of GCC.


Jeff

Re: [Patch] PR 61692 - Fix for inline asm ICE

[David Wohlferd]

I sent you the file you requested (off list), but never heard back from 
you about the valgrind results.

In an effort to move this along, I installed ubuntu under virtualbox and 
did a build of gcc.  When running the output of this build with 
valgrind, I saw a number of memory *leaks* reported, but no overruns, 
despite having maxed out the operands + clobbers in a variety of ways.

I have only tested this on x86, and only with inline asm, but I have had 
no luck (using code inspection, sprinkling printfs, and now valgrind) 
locating the error you are expecting to see.  Without knowing what is 
making you "quite confident" there is a problem, I don't know what else 
to try.  Suggestions?

Theoretically I could add the nclobbers in "just in case." But unlike 
adding nlabels, adding nclobbers here will almost certainly break 
someone's code.  I'm not prepared to do that unless there is a clear 
problem to be fixed, and I'm just not seeing it.

If you are also out of ideas, I can re-send the patch for the original 
ninputs + noutputs + nlabels problem (along with the testcase you 
requested), and we can at least fix the known ICE.

dw

On 8/1/2014 11:29 AM, Jeff Law wrote:
> On 08/01/14 02:07, David Wohlferd wrote:
>>
>> I'd love to.  Unfortunately, my platform doesn't support valgrind.
> Ah.
>
>>
>>> Also, please include the testcase you had nlabels part.
>>
>> I have created the testcase for the 31 labels problem.  However, not so
>> much for the nclobbers part.  And if I'm going to patch both, I should
>> have testcases for both.
> Tell you what, pass along what you've got and I'll run it under 
> valgrind here.  I'm quite confident both need to be changed -- though 
> it is possible nothing will trigger with the nclobbers stuff if it is 
> indeed handled separately throughout the guts of GCC.
>
>
> Jeff
>

Re: [Patch] PR 61692 - Fix for inline asm ICE

[Jeff Law]

On 09/14/14 02:13, David Wohlferd wrote:
> I sent you the file you requested (off list), but never heard back from
> you about the valgrind results.
Just haven't got back to it yet...  There's always more to get done on 
any given day than I have the time for, so I have to prioritize and some 
things get put on the back burner until I can get back to them.

>
> In an effort to move this along, I installed ubuntu under virtualbox and
> did a build of gcc.  When running the output of this build with
> valgrind, I saw a number of memory *leaks* reported, but no overruns,
> despite having maxed out the operands + clobbers in a variety of ways.
OK.  Something else must be in play here.  Clobbers can be somewhat 
special in that they may not always been an operand in the usual sense. 
  ie, often they'll just be attached to the insn as an explicit blob of 
RTL, that's the only thing I can think of that would be preventing us 
from losing here.

>
> If you are also out of ideas, I can re-send the patch for the original
> ninputs + noutputs + nlabels problem (along with the testcase you
> requested), and we can at least fix the known ICE.
Let's go with your original inputs + outputs + labels change and punt 
the clobbers stuff for now.

jeff

Re: [Patch] PR 61692 - Fix for inline asm ICE

[David Wohlferd]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

On 9/15/2014 2:51 PM, Jeff Law wrote:
> Let's go with your original inputs + outputs + labels change and punt 
> the clobbers stuff for now.
>
> jeff

I have also added the test code you requested.

I have a release on file with the FSF, but don't have SVN write access.

Problem:
extract_insn() in recog.c will ICE if (noperands > MAX_RECOG_OPERANDS).  
Normally this isn't a problem since expand_asm_operands() in cfgexpand.c 
catches and reports a proper error for this condition.  However, 
expand_asm_operands() only checks (ninputs + noutputs) instead of 
(ninputs + noutputs + nlabels), so you can get the ICE when using "asm 
goto."

ChangeLog:
2014-11-15  David Wohlferd <dw@LimeGreenSocks.com>

         PR target/61692
         * cfgexpand.c (expand_asm_operands): Count all inline asm params.
         * testsuite/gcc.dg/pr61692.c: New test.

dw

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: two.patch --]
[-- Type: text/x-patch; name="two.patch", Size: 7616 bytes --]

Index: gcc/cfgexpand.c
===================================================================
--- gcc/cfgexpand.c	(revision 217623)
+++ gcc/cfgexpand.c	(working copy)
@@ -2589,7 +2589,7 @@
     }
 
   ninputs += ninout;
-  if (ninputs + noutputs > MAX_RECOG_OPERANDS)
+  if (ninputs + noutputs + nlabels > MAX_RECOG_OPERANDS)
     {
       error ("more than %d operands in %<asm%>", MAX_RECOG_OPERANDS);
       return;
Index: gcc/testsuite/gcc.dg/pr61692.c
===================================================================
--- gcc/testsuite/gcc.dg/pr61692.c	(revision 0)
+++ gcc/testsuite/gcc.dg/pr61692.c	(working copy)
@@ -0,0 +1,173 @@
+/*  PR 61692  */
+
+/* Check for ice when exceededing the max #
+   of parameters to inline asm. */
+
+int Labels()
+{
+    label01: label02: label03: label04: label05:
+    label06: label07: label08: label09: label10:
+    label11: label12: label13: label14: label15:
+    label16: label17: label18: label19: label20:
+    label21: label22: label23: label24: label25:
+    label26: label27: label28: label29: label30:
+    label31:
+
+    __asm__ goto ("" /* Works. */
+        : /* no outputs */ 
+        : /* no inputs */ 
+        : /* no clobbers */
+        : label01, label02, label03, label04, label05, 
+          label06, label07, label08, label09, label10, 
+          label11, label12, label13, label14, label15, 
+          label16, label17, label18, label19, label20, 
+          label21, label22, label23, label24, label25, 
+          label26, label27, label28, label29, label30);
+
+    __asm__ goto ("" /* { dg-error "more than 30 operands" } */
+        : /* no outputs */ 
+        : /* no inputs */ 
+        : /* no clobbers */
+        : label01, label02, label03, label04, label05, 
+          label06, label07, label08, label09, label10, 
+          label11, label12, label13, label14, label15, 
+          label16, label17, label18, label19, label20, 
+          label21, label22, label23, label24, label25, 
+          label26, label27, label28, label29, label30, 
+          label31);
+
+    return 0;
+}
+
+int Labels_and_Inputs()
+{
+    int b01, b02, b03, b04, b05, b06, b07, b08, b09, b10;
+    int b11, b12, b13, b14, b15, b16, b17, b18, b19, b20;
+    int b21, b22, b23, b24, b25, b26, b27, b28, b29, b30;
+    int b31;
+
+    label01: label02: label03: label04: label05:
+    label06: label07: label08: label09: label10:
+    label11: label12: label13: label14: label15:
+    label16: label17: label18: label19: label20:
+    label21: label22: label23: label24: label25:
+    label26: label27: label28: label29: label30:
+    label31:
+
+    b01 = b02 = b03 = b04 = b05 = b06 = b07 = b08 = b09 = b10 = 0;
+    b11 = b12 = b13 = b14 = b15 = b16 = b17 = b18 = b19 = b20 = 0;
+    b21 = b22 = b23 = b24 = b25 = b26 = b27 = b28 = b29 = b30 = 0;
+    b31 = 0;
+
+    __asm__ goto ("" /* Works. */
+      : /* no outputs */
+      : "m" (b01), "m" (b02), "m" (b03), "m" (b04), "m" (b05), 
+        "m" (b06), "m" (b07), "m" (b08), "m" (b09), "m" (b10), 
+        "m" (b11), "m" (b12), "m" (b13), "m" (b14), "m" (b15),
+        "m" (b16), "m" (b17), "m" (b18), "m" (b19), "m" (b20), 
+        "m" (b21), "m" (b22), "m" (b23), "m" (b24), "m" (b25),
+        "m" (b26), "m" (b27), "m" (b28), "m" (b29)
+      : /* no clobbers */
+      : label01);
+
+    __asm__ goto ("" /* { dg-error "more than 30 operands" } */
+      : /* no outputs */
+      : "m" (b01), "m" (b02), "m" (b03), "m" (b04), "m" (b05), 
+        "m" (b06), "m" (b07), "m" (b08), "m" (b09), "m" (b10), 
+        "m" (b11), "m" (b12), "m" (b13), "m" (b14), "m" (b15),
+        "m" (b16), "m" (b17), "m" (b18), "m" (b19), "m" (b20), 
+        "m" (b21), "m" (b22), "m" (b23), "m" (b24), "m" (b25),
+        "m" (b26), "m" (b27), "m" (b28), "m" (b29), "m" (b30)
+      : /* no clobbers */
+      : label01);
+
+      return 0;
+}
+
+int Outputs()
+{
+    int b01, b02, b03, b04, b05, b06, b07, b08, b09, b10;
+    int b11, b12, b13, b14, b15, b16, b17, b18, b19, b20;
+    int b21, b22, b23, b24, b25, b26, b27, b28, b29, b30;
+    int b31;
+
+    /* Outputs. */
+    __asm__ volatile ("" /* Works. */
+         : "=m" (b01),  "=m" (b02),  "=m" (b03),  "=m" (b04), "=m" (b05),
+           "=m" (b06),  "=m" (b07),  "=m" (b08),  "=m" (b09), "=m" (b10),
+           "=m" (b11),  "=m" (b12),  "=m" (b13),  "=m" (b14), "=m" (b15),
+           "=m" (b16),  "=m" (b17),  "=m" (b18),  "=m" (b19), "=m" (b20), 
+           "=m" (b21),  "=m" (b22),  "=m" (b23),  "=m" (b24), "=m" (b25),
+           "=m" (b26),  "=m" (b27),  "=m" (b28),  "=m" (b29), "=m" (b30));
+
+    __asm__ volatile ("" /* { dg-error "more than 30 operands" } */
+         : "=m" (b01),  "=m" (b02),  "=m" (b03),  "=m" (b04), "=m" (b05),
+           "=m" (b06),  "=m" (b07),  "=m" (b08),  "=m" (b09), "=m" (b10),
+           "=m" (b11),  "=m" (b12),  "=m" (b13),  "=m" (b14), "=m" (b15),
+           "=m" (b16),  "=m" (b17),  "=m" (b18),  "=m" (b19), "=m" (b20), 
+           "=m" (b21),  "=m" (b22),  "=m" (b23),  "=m" (b24), "=m" (b25),
+           "=m" (b26),  "=m" (b27),  "=m" (b28),  "=m" (b29), "=m" (b30),
+           "=m" (b31));
+
+    return 0;
+}
+
+int Inputs()
+{
+    int b01, b02, b03, b04, b05, b06, b07, b08, b09, b10;
+    int b11, b12, b13, b14, b15, b16, b17, b18, b19, b20;
+    int b21, b22, b23, b24, b25, b26, b27, b28, b29, b30;
+    int b31;
+
+    b01 = b02 = b03 = b04 = b05 = b06 = b07 = b08 = b09 = b10 = 0;
+    b11 = b12 = b13 = b14 = b15 = b16 = b17 = b18 = b19 = b20 = 0;
+    b21 = b22 = b23 = b24 = b25 = b26 = b27 = b28 = b29 = b30 = 0;
+    b31 = 0;
+
+    __asm__ volatile ("" /* Works. */
+      : /* no outputs */
+      : "m" (b01), "m" (b02), "m" (b03), "m" (b04), "m" (b05), 
+        "m" (b06), "m" (b07), "m" (b08), "m" (b09), "m" (b10), 
+        "m" (b11), "m" (b12), "m" (b13), "m" (b14), "m" (b15),
+        "m" (b16), "m" (b17), "m" (b18), "m" (b19), "m" (b20), 
+        "m" (b21), "m" (b22), "m" (b23), "m" (b24), "m" (b25),
+        "m" (b26), "m" (b27), "m" (b28), "m" (b29), "m" (b30));
+
+    __asm__ volatile ("" /* { dg-error "more than 30 operands" } */
+      : /* no outputs */
+      : "m" (b01), "m" (b02), "m" (b03), "m" (b04), "m" (b05), 
+        "m" (b06), "m" (b07), "m" (b08), "m" (b09), "m" (b10), 
+        "m" (b11), "m" (b12), "m" (b13), "m" (b14), "m" (b15),
+        "m" (b16), "m" (b17), "m" (b18), "m" (b19), "m" (b20), 
+        "m" (b21), "m" (b22), "m" (b23), "m" (b24), "m" (b25),
+        "m" (b26), "m" (b27), "m" (b28), "m" (b29), "m" (b30),
+        "m" (b31));
+
+    return 0;
+}
+
+int Input_Output()
+{
+    int b01, b02, b03, b04, b05, b06, b07, b08, b09, b10;
+    int b11, b12, b13, b14, b15, b16, b17, b18, b19, b20;
+    int b21, b22, b23, b24, b25, b26, b27, b28, b29, b30;
+    int b31;
+
+    b01 = b02 = b03 = b04 = b05 = b06 = b07 = b08 = b09 = b10 = 0;
+    b11 = b12 = b13 = b14 = b15 = b16 = b17 = b18 = b19 = b20 = 0;
+    b21 = b22 = b23 = b24 = b25 = b26 = b27 = b28 = b29 = b30 = 0;
+    b31 = 0;
+
+    __asm__ volatile ("" /* Works. */
+         : "+m" (b01),  "+m" (b02),  "+m" (b03),  "+m" (b04), "+m" (b05),
+           "+m" (b06),  "+m" (b07),  "+m" (b08),  "+m" (b09), "+m" (b10),
+           "+m" (b11),  "+m" (b12),  "+m" (b13),  "+m" (b14), "+m" (b15));
+
+    __asm__ volatile ("" /* { dg-error "more than 30 operands" } */
+         : "+m" (b01),  "+m" (b02),  "+m" (b03),  "+m" (b04), "+m" (b05),
+           "+m" (b06),  "+m" (b07),  "+m" (b08),  "+m" (b09), "+m" (b10),
+           "+m" (b11),  "+m" (b12),  "+m" (b13),  "+m" (b14), "+m" (b15),
+           "+m" (b16));
+
+    return 0;
+}

Re: [Patch] PR 61692 - Fix for inline asm ICE

[David Wohlferd]

Ping?

dw

On 11/15/2014 7:59 PM, David Wohlferd wrote:
> On 9/15/2014 2:51 PM, Jeff Law wrote:
>> Let's go with your original inputs + outputs + labels change and punt 
>> the clobbers stuff for now.
>>
>> jeff
>
> I have also added the test code you requested.
>
> I have a release on file with the FSF, but don't have SVN write access.
>
> Problem:
> extract_insn() in recog.c will ICE if (noperands > 
> MAX_RECOG_OPERANDS).  Normally this isn't a problem since 
> expand_asm_operands() in cfgexpand.c catches and reports a proper 
> error for this condition.  However, expand_asm_operands() only checks 
> (ninputs + noutputs) instead of (ninputs + noutputs + nlabels), so you 
> can get the ICE when using "asm goto."
>
> ChangeLog:
> 2014-11-15  David Wohlferd <dw@LimeGreenSocks.com>
>
>         PR target/61692
>         * cfgexpand.c (expand_asm_operands): Count all inline asm params.
>         * testsuite/gcc.dg/pr61692.c: New test.
>
> dw

Re: [Patch] PR 61692 - Fix for inline asm ICE

[Jeff Law]

On 11/15/14 20:59, David Wohlferd wrote:
> On 9/15/2014 2:51 PM, Jeff Law wrote:
>> Let's go with your original inputs + outputs + labels change and punt
>> the clobbers stuff for now.
>>
>> jeff
>
> I have also added the test code you requested.
>
> I have a release on file with the FSF, but don't have SVN write access.
>
> Problem:
> extract_insn() in recog.c will ICE if (noperands > MAX_RECOG_OPERANDS).
> Normally this isn't a problem since expand_asm_operands() in cfgexpand.c
> catches and reports a proper error for this condition.  However,
> expand_asm_operands() only checks (ninputs + noutputs) instead of
> (ninputs + noutputs + nlabels), so you can get the ICE when using "asm
> goto."
>
> ChangeLog:
> 2014-11-15  David Wohlferd <dw@LimeGreenSocks.com>
>
>          PR target/61692
>          * cfgexpand.c (expand_asm_operands): Count all inline asm params.
>          * testsuite/gcc.dg/pr61692.c: New test.
Thanks.  I put the testsuite ChangeLog entry in the right place and 
added a dg-do directive to the testcase to ensure we just try to compile it.

Thanks for your patience, things got rather busy and obviously I'm still 
working through my personal backlog of patches from folks.

Jeff