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
