On Fri, 28 Aug 2015, Christophe Lyon wrote: > On 28 August 2015 at 09:48, Richard Biener <rguent...@suse.de> wrote: > > On Fri, 28 Aug 2015, Christophe Lyon wrote: > > > >> On 27 August 2015 at 17:43, Alan Lawrence <alan.lawre...@arm.com> wrote: > >> > Martin Jambor wrote: > >> >> > >> >> First, I would be much > >> >> happier if you added a proper comment to scalarize_elem function which > >> >> you forgot completely. The name is not very descriptive and it has > >> >> quite few parameters too. > >> >> > >> >> Second, this patch should also fix PR 67283. It would be great if you > >> >> could verify that and add it to the changelog when committing if that > >> >> is indeed the case. > >> > > >> > Thanks for pointing both of those out. I've added a comment to > >> > scalarize_elem, > >> > deleted the bogus comment in the new test, and yes I can confirm that > >> > the patch > >> > fixes PR 67283 on x86_64, and also AArch64 if > >> > --param sra-max-scalarization-size-Ospeed is passed. (I've not added any > >> > testcase specifically taken from that PR, however.) > >> > > >> > Pushed as r277265. > >> > >> Actually, is r227265. > >> > >> Since since commit I've noticed that > >> g++.dg/torture/pr64312.C > >> fails at -O1 in my config, saying "virtual memory exhaustion" (arm* > >> targets) > >> I run my validations under ulimit -v 10GB, which seems already large > >> enough. > >> > >> Do we consider this a bug? > > > > Sure we do. You have to investigate this (I guess we run into some > > endless looping/recursing that eats memory somewhere). > > > > I asked because I assumed that Alan saw it pass in his configuration.
Well, it should still be investigated - whether you caused it or not ;) It's a bug. Richard.
