On Mon, Nov 6, 2017 at 5:47 AM, Jeff Law wrote:
> On 11/03/2017 02:44 AM, Uros Bizjak wrote:
>> Hello!
>>
>> -ENOCHANGELOG
> Arggh. Downside of doing all the work on one machine, but mail
> elsewhere. Attached with ChangeLog this time :-)
>
>>
>> diff --git a/gcc/testsuite/gcc.c-torture/execute/
On 11/03/2017 02:44 AM, Uros Bizjak wrote:
> Hello!
>
> -ENOCHANGELOG
Arggh. Downside of doing all the work on one machine, but mail
elsewhere. Attached with ChangeLog this time :-)
>
> diff --git a/gcc/testsuite/gcc.c-torture/execute/pr82788.c
> b/gcc/testsuite/gcc.c-torture/execute/pr82788.c
Hello!
-ENOCHANGELOG
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr82788.c
b/gcc/testsuite/gcc.c-torture/execute/pr82788.c
new file mode 100644
index 000..ceaa25f
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr82788.c
@@ -0,0 +1,2 @@
+
+int main() { int a[1442]; return 0;}
Yo
The x86 backend defines a PROBE_INTERVAL which is supposed to be used by
the -fstack-check= mechanisms.
Some stack-clash code was using PROBE_INTERVAL rather than querying the
PARAM system for the right value. If the former is larger than the
latter and we allocate a large stack, then the
