[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

2017-12-13 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

2017-12-13 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #45 from Eric Botcazou --- Author: ebotcazou Date: Wed Dec 13 23:16:56 2017 New Revision: 255616 URL: https://gcc.gnu.org/viewcvs?rev=255616&root=gcc&view=rev Log: PR middle-end/78468 * emit-rtl.c (init_emit): Remove

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

2017-11-21 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 Eric Botcazou changed: What|Removed |Added Status|REOPENED|ASSIGNED Assignee|unassigned a

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

2017-09-06 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #43 from Wilco --- Author: wilco Date: Wed Sep 6 16:34:54 2017 New Revision: 251811 URL: https://gcc.gnu.org/viewcvs?rev=251811&root=gcc&view=rev Log: PR78468 - add alloca alignment test Add an alignment test to check that aligned

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

2017-09-06 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #42 from Wilco --- (In reply to Eric Botcazou from comment #41) > > If you cannot guarantee the alignment of the pointers to STACK_BOUNDARY then > > STACK_BOUNDARY is incorrect. > > No, it is correct as per the definition: > > -- M

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

2017-09-06 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #41 from Eric Botcazou --- > If you cannot guarantee the alignment of the pointers to STACK_BOUNDARY then > STACK_BOUNDARY is incorrect. No, it is correct as per the definition: -- Macro: STACK_BOUNDARY Define this macro to th

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

2017-09-06 Thread wdijkstr at arm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #40 from Wilco --- (In reply to Eric Botcazou from comment #39) > > The existing alloca code relies on STACK_BOUNDARY being set correctly. Has > > the value been fixed already for the OS variants mentioned? If stack > > alignment can'

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

2017-09-06 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #39 from Eric Botcazou --- > The existing alloca code relies on STACK_BOUNDARY being set correctly. Has > the value been fixed already for the OS variants mentioned? If stack > alignment can't be guaranteed by OS/runtime/prolog, STACK

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

2017-09-06 Thread wdijkstr at arm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 Wilco changed: What|Removed |Added CC||wdijkstr at arm dot com --- Comment #38 from Wil

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

2017-09-06 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 Rainer Orth changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed|2016-11-25 00: