On Fri, Sep 12, 2014 at 04:42:25PM -0700, Mike Stump wrote:
> curious, when I run atomic.exp=stdatom\*.c:
>
> gcc.dg/atomic/atomic.exp completed in 30 seconds.
>
> atomic.exp=c\*.c takes 522 seconds with 3, 2, 5 and 4 being the worst
> offenders.
That's the
@if [ -z "$(filter-out --ta
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote:
> Here is my latest version of the patch.
I did a timing test:
Before:
real0m57.198s
user1m24.736s
sys 0m19.816s
after:
real0m28.224s
user1m27.823s
sys 0m22.374s
This is a -j70 run on a 64 core power7 of check-objc, I
On Fri, Sep 12, 2014 at 10:16:12AM +0200, Richard Biener wrote:
> On Fri, Sep 12, 2014 at 7:40 AM, Jan Hubicka wrote:
> > Hi,
> > I went through excercise of running LTO bootstrap with ODR verification on.
> > There are some typename clashes
> > I guess we want to fix. I wonder what approach is
> So, I’d love to see the numbers for 5 and 20 to double check that 10 is the
> right number to pick. This sort of refinement is trivial post checkin.
So, some timings with the patch, I think this is great.
Doing the testing you suggest, changing the variable doesn't influence things
much (at
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote:
> Here is my latest version of the patch.
>
> With this patch I get identical test_summary output on make -k check
> (completely serial testing) and make -j48 -k check from toplevel directory.
>
> Major changes since last version:
> 1) I've chang
On Fri, Sep 12, 2014 at 04:36:05PM +, VandeVondele Joost wrote:
>
>
> >> Regtested on x86_64-linux, ok for trunk?
> >
> >Oh, forgot to say, PR56408 isn't fixed by this patch, but given the
> >higher granularity (10 tests instead of 1) we don't happen to trigger it
> >right now.
>
> which me
>> Regtested on x86_64-linux, ok for trunk?
>
>Oh, forgot to say, PR56408 isn't fixed by this patch, but given the
>higher granularity (10 tests instead of 1) we don't happen to trigger it
>right now.
which means that any commit to that dir could trigger it, right ?
On Fri, Sep 12, 2014 at 06:32:41PM +0200, Jakub Jelinek wrote:
> Regtested on x86_64-linux, ok for trunk?
Oh, forgot to say, PR56408 isn't fixed by this patch, but given the
higher granularity (10 tests instead of 1) we don't happen to trigger it
right now.
Jakub
On Fri, Sep 12, 2014 at 09:47:00AM +, VandeVondele Joost wrote:
> Obviously, if Jakub's patch can be made to work around the testsuite
> special cases, I believe it should be superior. If not, the attached
> patch is working as far as I can tell, and provides a significant
> improvement over
Hi Maxim,
Many thanks for your leadership and hard work administering this.
I would be interested in reading about the results of the projects and
evaluations. Please student (and mentors), could you provide some
details?
Maxim, would it be possible to add this year projects to
https://gcc.gnu.o
On Friday 12 September 2014 12:14 PM, Jan Hubicka wrote:
I am trying to access the virtual table.
My pass is hooked after pass_ipa_pta.
Consider Class A which contains virtual function.
An object created as :
A a;
is translated in GIMPLE as
struct A a;
From variable "a" we can get it
On 12/09/14 09:47 +, VandeVondele Joost wrote:
a newer patch (v8) I'll send soon
attached with updated changelog. Compared to the previously posted v6, only the
libstdc++-v3/testsuite/Makefile.am has been refined to split a little more the
e*/* pattern, and two quickly running goal have
> a newer patch (v8) I'll send soon
attached with updated changelog. Compared to the previously posted v6, only the
libstdc++-v3/testsuite/Makefile.am has been refined to split a little more the
e*/* pattern, and two quickly running goal have been merged, in addition to
fixing the pre-exisiting
On Fri, Sep 12, 2014 at 7:40 AM, Jan Hubicka wrote:
> Hi,
> I went through excercise of running LTO bootstrap with ODR verification on.
> There are some typename clashes
> I guess we want to fix. I wonder what approach is preferred, do we want to
> introduce anonymous
> namespaces for those?
On Thu, Sep 11, 2014 at 10:17 PM, Jeff Prothero wrote:
>
> Hi, I'm having trouble based on available docs like
> https://gcc.gnu.org/onlinedocs/gccint/LTO.html
> in understanding just what the gcc LTO framework is
> intended to be architecturally capable of.
>
> As a concrete motivating exampl
15 matches
Mail list logo
