This is now in bugzilla as:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28871
-benjamin
When I run bootstrap and "make check", I check the -m64 option
(only). Check gcc-testresults.
Currently, the results don't look very good. Maybe I'm doing
something wrong.
Brad
Brad,
Why don't you try a normal multi-lib build without any
extra flags. At the moment, considering how much noise is on
the testsuite results on Darwin due to this linker warnings, I
don't think its really helpful to bother exploring corner cases
of building gcc trunk with unique flags. Make s
On Aug 28, 2006, at 6:57 AM, Kenneth Zadeck wrote:
This posting is a progress report of my task of encoding and decoding
the GIMPLE stream into LTO. Included in this posting is a patch that
encodes functions and dumps the result to files.
Interesting email. One question: how big are the fil
On Aug 28, 2006, at 12:10 PM, Jack Howarth wrote:
Why don't you try a normal multi-lib build without any
extra flags.
What extra flags? The configure command is
../configure --prefix=/pkgs/gcc-mainline --with-gmp=/opt/local/ --
with-mpfr=/opt/local/
which is totally generic (one need
Chris Lattner wrote:
> On Aug 28, 2006, at 6:57 AM, Kenneth Zadeck wrote:
>
>> This posting is a progress report of my task of encoding and decoding
>> the GIMPLE stream into LTO. Included in this posting is a patch that
>> encodes functions and dumps the result to files.
>
> Interesting email.
Richard Kenner wrote:
> I disagree. Testing is not, and should never be, a substitute for analysis.
>
> A patch is proposed because we have a reason to believe it's correct. Then
> we test to increase our confidence that it is, indeed, correct. But both
> parts are essential for any patch.
>
Brad,
I was confusing your use of -mcpu=970 in the make check with the
build flags...sorry. You might stop using that flag for now until
you get a baseline of how many additional failures seen in -m64
compared to -m32 are not due to the linker warnings (after you
apply the TImode patch). I'll l
On Aug 27, 2006, at 7:24 AM, Jack Howarth wrote:
Can one of you remind me who we need to lobby at Apple
In the gcc project, contributions are generally speaking, made by an
individual. Geoff operates a regression tester, probably the one
you're thinking of. In the past, he has considered
Mike,
Do you know if regress is used for anything other than building
and checking gcc? Also is it a dual G5 by any chance? I ask because
it is unclear if regress is doing a 'make -k -j 2 check' or not?
Might that not increase the rate of testing on regress? I haven't
tried that myself because I
On Aug 28, 2006, at 10:36 AM, Kenneth Zadeck wrote:
I actually do not think that it is productive to spend that much time
measuring this until we first assure ourselves that we are getting all
of the information output correctly. That 60mb number will change
a lot
(both up and down) as we get
On Aug 28, 2006, at 1:20 PM, Jack Howarth wrote:
Might that not increase the rate of testing on regress?
Sorry, nope.
On 8/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
...
I have not received reports about bugs in the offending code when
compiled with other compilers.
I do know at least one another compiler that does this,
and at least one significant project (which is actually quite a bit
larger than Py
Mike,
Well then alternatively, might not 'make -j 2' increase
the rate at which gcc is built on regress? Or doesn't Darwin
support parallel builds? If we can't speed up the testing
then we could at least speed up the build process to free
up time for -m64. After all, we are already building -m6
On Aug 28, 2006, at 3:32 PM, Jack Howarth wrote:
Well then alternatively, might not 'make -j 2' increase the rate at
which gcc is built on regress?
Yes, we know about -j2. When I said, sorry, nope, I meant to convey
the idea that in fact that adding a -j2 won't speed it up.
Or doesn't Da
Mike,
Now I totally confused. Are you saying that '-j 2' only speeds up
testing but not builds? In one sentence you say it won't speed things up
and in the next you say of course it speeds things up. Which is it?
Jack
On Aug 28, 2006, at 3:32 PM, Jack Howarth wrote:
On Aug 28, 2006, at 3:57 PM, Jack Howarth wrote:
> If we can't speed up the testing
? -j2 makes testing go faster as well.
Sigh, I misstated that one. My comment in that case was about the
general case. I meant to say that -j2 is as applicable to testing as
it is to buil
Mike,
Okay. How about this. Have regress set to at least do
a -m64 make check once a week. At least that would show
some interest in the status of gcc at 64-bit. It is baffling
to most people how we can make any progress on such issues
if the status isn't sampled at least once every blue moon.
On Aug 28, 2006, at 5:08 PM, Jack Howarth wrote:
Okay. How about this. Have regress set to at least do a -m64 make
check once a week.
I think it is a G4, so testing G5 code-gen might have to wait until
the G5 emulator is done. :-)
Can you contribute G5 results once a week?
At least that
Kenneth Zadeck wrote:
This posting is a progress report of my task of encoding and decoding
the GIMPLE stream into LTO. Included in this posting is a patch that
encodes functions and dumps the result to files.
I have only a limited understanding of GIMPLE and LTO, but here are my
comments r
Mike,
Sure. I am actually doing a build right now to demonstrate the
baseline we have for c, c++, and fortran with just the TImode patch
and the prune.exp patches I use. Hmm, regress is a G4...surely you
can find a G5 laying around Apple to replace it with since PowerPC
is so passe there (grin).
Michael Eager wrote:
> Kenneth Zadeck wrote:
>> This posting is a progress report of my task of encoding and decoding
>> the GIMPLE stream into LTO. Included in this posting is a patch that
>> encodes functions and dumps the result to files.
>
> I have only a limited understanding of GIMPLE and
22 matches
Mail list logo
