On Tue, 2006-08-22 at 16:33 -0400, Carlos O'Donell wrote:
> Has the 'make html' target been fixed? I would like to enable this
> target so that html support doesn't bitrot.
No sorry. I didn't know it was broken. I see that it only works when
configuring with --with-gjdoc. If there is already a bug
I'm starting a bootstrap timing comparison to find if this is a red
herring. I'll get the results next morning.
Hm, nope:
$ gcc_test --base-gcc-branch=HEAD:r116077 --peak-gcc-branch=HEAD:r116080
...
Bootstrapping base compiler took 13999 secs
...
Bootstrapping peak compiler took 13993 secs
I'm pleased to note that there's been a noticeable decrease in open
regressions relative to my previous report. The total number of
regressions has fallen from 160 to 140 and the number of P1s has falled
from 29 to 21.
In an effort to move us closer to the goal of 100 regressions to create
t
> Jan Hubicka <[EMAIL PROTECTED]> writes:
>
> >> On Mon, Aug 21, 2006 at 05:25:09PM -0400, Andrew Pinski wrote:
> >> > >
> >> > > On Aug 21, 2006, at 11:59 AM, Andreas Jaeger wrote:
> >> > > > Trunk fails to build for me with:
> >> > >
> >> > > Maybe related (from http://gcc.gnu.org/regtest/HEAD
Richard Kenner wrote:
> I found the test case. As I suspected, it was on Sparc (the test case failed
> for a different reason on Mips) and was indeed a case where there were two
> function calls in the same parameter list of an outer call (though not the
> same function). It was an Ada test case
On Tue, Aug 15, 2006 at 01:18:55AM +0200, Mark Wielaard wrote:
> GNU Classpath 0.92 was released last week. It contains a lot of new
> standard library classes and bug fixes. See
> http://savannah.gnu.org/forum/forum.php?forum_id=4573
> And the list of fixed bugs:
> http://gcc.gnu.org/bugzilla/bugl
>
> I hate to even bring this up, but... should things like:
>
>int m[1 << 27] = {0};
>
> be put in .bss? I'm tempted to say no, if you want that, you have to
> remove {0}.
Yes if -fzero-initialized-in-bss is on which it is by default since at least
3.4.0.
-- Pinski
On Tuesday 22 August 2006 20:14, Mike Stump wrote:
> I hate to even bring this up, but... should things like:
>
>int m[1 << 27] = {0};
>
> be put in .bss? I'm tempted to say no, if you want that, you have to
> remove {0}.
What makes you say this?
Given that C requires global variables with
On Tue, Aug 22, 2006 at 12:14:24PM -0700, Mike Stump wrote:
> I hate to even bring this up, but... should things like:
>
> int m[1 << 27] = {0};
>
> be put in .bss? I'm tempted to say no, if you want that, you have to
> remove {0}.
Does this answer your question?
`-fno-zero-initialized-i
> And you did not add that test case, why? Now there is a possible fix
> for a pretty ugly regression, and we can only *guess* why something is
> done the way it is???
I found the test case. As I suspected, it was on Sparc (the test case failed
for a different reason on Mips) and was indeed a ca
I hate to even bring this up, but... should things like:
int m[1 << 27] = {0};
be put in .bss? I'm tempted to say no, if you want that, you have to
remove {0}.
Jan Hubicka <[EMAIL PROTECTED]> writes:
>> On Mon, Aug 21, 2006 at 05:25:09PM -0400, Andrew Pinski wrote:
>> > >
>> > > On Aug 21, 2006, at 11:59 AM, Andreas Jaeger wrote:
>> > > > Trunk fails to build for me with:
>> > >
>> > > Maybe related (from http://gcc.gnu.org/regtest/HEAD/):
>> > >
>> >
Diego Novillo wrote:
Benjamin Kosnik wrote on 08/22/06 07:56:
Hey y'all. I'm just getting back from vacation and as I re-build my
testing baselines, I've noticed a huge compilation time regression.
This happened sometime post Aug 1, 2006. Anybody else notice?
Yes, something did happen after Au
> And you did not add that test case, why? Now there is a possible fix
> for a pretty ugly regression, and we can only *guess* why something is
> done the way it is???
As I said earlier, this came in as part of a merge of one tree to another
back in 1999, not as a separate patch, so you'd have to
On 8/22/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> So, my question is: is it really necessary to mark this location as
> having its address taken? Yes, the address of the slot is passed to a
> function, however I can't imagine any instances where the function
> retaining that address after
Benjamin Kosnik wrote on 08/22/06 07:56:
> Hey y'all. I'm just getting back from vacation and as I re-build my
> testing baselines, I've noticed a huge compilation time regression.
> This happened sometime post Aug 1, 2006. Anybody else notice?
>
Yes, something did happen after Aug11. The SPEC te
On Tue, 2006-08-22 13:56:28 +0200, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
> Hey y'all. I'm just getting back from vacation and as I re-build my
> testing baselines, I've noticed a huge compilation time regression.
> This happened sometime post Aug 1, 2006. Anybody else notice?
I did. But I adm
Richard Guenther wrote:
>> OK, thanks. If you have any suggestions on other approaches to
>> verifying this, I'd certainly appreciate it.
> Other than testing on more targets, no. Does it fix PR25505? In
> this case it would be a fix for a regression and maybe rth can have a
> look at the pat
Laurynas Biveinis wrote:
> Hi all,
>
> (Daniel, now that SoC is over, I guess this is the last my email with
> CC: to you, unless you prefer otherwise :)
Hey, just cause SoC is over doesn't mean i'm not happy to answer your
questions to the degree I can, so please, keep cc'ing me.
>
> I'd like
Hey y'all. I'm just getting back from vacation and as I re-build my
testing baselines, I've noticed a huge compilation time regression.
This happened sometime post Aug 1, 2006. Anybody else notice?
Some of this was also measured more formally on the CSiBE website:
http://www.csibe.org/ctx-full.ph
Hi all,
(Daniel, now that SoC is over, I guess this is the last my email with
CC: to you, unless you prefer otherwise :)
I'd like to get your feedback about design of frontend-specific type
tag infrastructure in gengtype.
First of all, how things are done currently in WIP version:
1) A big enum
On 8/22/06, Josh Conner <[EMAIL PROTECTED]> wrote:
Richard Kenner wrote:
>> I did investigate the case you described, where two function parameters
>> are calls to the same function returning a structure. The front-end
>> generates temporaries to handle this, and so the middle-end-generated
>>
22 matches
Mail list logo
