Hi all,
On Wednesday 30 November 2005 00:59, Ben Elliston wrote:
> On Mon, Nov 28, 2005 at 05:18:29PM -0800, Joe Buck wrote:
>
> > But the big problem is the non-freeness of SPEC; ideally there would
> > be a benchmark that ...
> >
> > ... everyone can download and run
> > ... is reasonably fast
On Tuesday 29 November 2005 20:05, Chris Lattner wrote:
> I'm not working on it, go ahead and try. I assume this is with
> mainline, not the apple branch?
Yes. The referred patch hasn't be merged in the apple branch yet.
> I have the other problem you ran into and several other other minor
> ones
On Mon, Nov 28, 2005 at 05:18:29PM -0800, Joe Buck wrote:
> But the big problem is the non-freeness of SPEC; ideally there would
> be a benchmark that ...
>
> ... everyone can download and run
> ... is reasonably fast
> ... is non-trivial
There is Openbench, whose URL I added to the GCC benchmar
On Mon, Nov 28, 2005 at 04:38:58PM -0800, Mark Mitchell wrote:
> As a strawman, perhaps we could add a small integer program (bzip?)
> and a small floating-point program to the testsuite, and have
> DejaGNU print out the number of iterations of each that run in 10
> seconds.
Similarly, perhaps we
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > The resason here is that, after we complained that A is incomplete
| > (therefore cannot be used as return type in the function definition),
| > cp/decl.c:check_function_type() changes the return type to void, thus
| > giv
On Tue, 29 Nov 2005, Hans-Peter Nilsson wrote:
> On Mon, 28 Nov 2005, Mark Mitchell wrote:
> > So, we're considering doing what it takes to get ieeelib.c into GCC, or,
> > perhaps, borrowing some of its ideas for fp-bit.c.
>
> Very nice! Don't forget the few posts with bug-fixes over the
> years
On Tue, 29 Nov 2005, Daniel Berlin wrote:
> On Tue, 2005-11-29 at 22:08 +0100, Richard Guenther wrote:
> > The patch below teaches points-to analysis about restrict qualifiers
> > of incoming parameters. It is modeled after the special handling
> > of malloc result type pointers, namely creating
On Mon, 28 Nov 2005, Mark Mitchell wrote:
> So, we're considering doing what it takes to get ieeelib.c into GCC, or,
> perhaps, borrowing some of its ideas for fp-bit.c.
Very nice! Don't forget the few posts with bug-fixes over the
years from someone or other. (Yes, actually posted here on a
gcc
On Tue, Nov 29, 2005 at 11:29:17PM +0100, Paolo Bonzini wrote:
>
> >Well, I've been talking about doing this for so long that I feel I must
> >take this as a challenge... I will give it a shot.
>
> All that I've done so far is to look at config.gcc and shudder at what a
> mess it would be to sep
Snapshot gcc-3.4-20051129 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20051129/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Well, I've been talking about doing this for so long that I feel I must
take this as a challenge... I will give it a shot.
All that I've done so far is to look at config.gcc and shudder at what a
mess it would be to separate libgcc. But really it is not necessary,
and one could keep #includ
Jakub Jelinek wrote:
If we use MIN (tree_low_cst (TYPE_SIZE (type), 0), BIGGEST_ALIGNMENT)
here, I'm afraid that would be much bigger ABI incompatibility.
Currently, say
typedef char __attribute__((vector_size (64))) v64qi;
is 64 bytes aligned on most arches, even when BIGGEST_ALIGNMENT is m
On Tue, 29 Nov 2005, Mike Stump wrote:
> > What field order looks better to you? I'm agnostic, except I'd
> > like to keep one and the same field delimiter except for the
> > result, and it's *slightly* easier to keep it as "," (as in the
> > original csibe output).
>
> 4.1-sparc-r104567/my-perf-s
I found that the patch 99839:99840 introduces some function lowering
and in doing so breaks the LLVM patch. A patch for trunk version 99839
is in http://www.las.ic.unicamp.br/~espindola/gcc-llvm-trunk-99839.patch.bz2.
Chris, are you working on this or should I give it a try?
Rafael
On Tue, 2005-11-29 at 22:08 +0100, Richard Guenther wrote:
> The patch below teaches points-to analysis about restrict qualifiers
> of incoming parameters. It is modeled after the special handling
> of malloc result type pointers, namely creating fake variables we
> point to and thus trigger creat
On Tue, 2005-11-29 at 13:01 -0800, Richard Henderson wrote:
> On Tue, Nov 29, 2005 at 12:42:36PM -0800, Mark Mitchell wrote:
> > RTH is listed as the author of a lot of those bits, so perhaps he knows
> > more?
>
> The glibc bits handle ieee quad format, whereas I don't believe
> that Torbajorn's
On Tue, Nov 29, 2005 at 01:01:23PM -0800, Richard Henderson wrote:
> On Tue, Nov 29, 2005 at 12:42:36PM -0800, Mark Mitchell wrote:
> > RTH is listed as the author of a lot of those bits, so perhaps he knows
> > more?
>
> The glibc bits handle ieee quad format, whereas I don't believe
> that Torba
Richard Henderson wrote:
> The glibc bits handle ieee quad format, whereas I don't believe
> that Torbajorn's does. I don't recall if Torbajorn's code allows
> for emulation of all rounding modes or exception bits.
I believe it does not.
> But I suspect that Torbajorn's code compiles down small
The patch below teaches points-to analysis about restrict qualifiers
of incoming parameters. It is modeled after the special handling
of malloc result type pointers, namely creating fake variables we
point to and thus trigger creation of NMTs. Unfortunately it doesn't
exactly work, as for the te
On Tue, Nov 29, 2005 at 12:42:36PM -0800, Mark Mitchell wrote:
> RTH is listed as the author of a lot of those bits, so perhaps he knows
> more?
The glibc bits handle ieee quad format, whereas I don't believe
that Torbajorn's does. I don't recall if Torbajorn's code allows
for emulation of all ro
On Nov 29, 2005, at 12:27 PM, Hans-Peter Nilsson wrote:
Ah, ok, good. I'd eject the ,previous to the filename, and reorder
slightly, but, certainly that is trivial to do.
Um, (typo?) not a filename, but a line from the file with raw
results, alternatively the baseline input. The "previous"
id
Gabriel Dos Reis wrote:
> The resason here is that, after we complained that A is incomplete
> (therefore cannot be used as return type in the function definition),
> cp/decl.c:check_function_type() changes the return type to void, thus
> giving misleading diagnostic later.
That's the bug. It s
Hi,
I'm looking at PR C++/25156 for which I have a fix (not the
incomplete one posted in the audit trail). Everyting goes well,
except it makes the testcase g++.dg/expr/return1.C fail for excess
error
return1.C:8: error: return-statement with a value, in function returning
'void'
/
Anthony Green wrote:
> I did some benchmarking a year or two ago with Torbjorn's library and
> found good results as well. However, there was pushback on merging this
> in from the GCC hackers I spoke with because they saw glibc's FP
> emulation library as an even better solution, and implied the
On Nov 29, 2005, at 11:51 AM, Laurent GUERBY wrote:
On Mon, 2005-11-28 at 17:55 -0800, Mike Stump wrote:
My feeling is that we should have such a suite. I'd favor a micro
style, where we are measuring clock cycles (on machines that can
expose them x86/v9), [...]
A while ago I looked at rdtsc
On Mon, 2005-11-28 at 18:05 -0800, Mark Mitchell wrote:
> That message contains an IEEE floating-point emulation library, like
> fp-bit.c. Howeve, the performance is considerably better; Joseph
> measured against fp-bit.c with a modern compiler, and ieeelib.c is about
> 10-15% better than the curr
On Tue, 29 Nov 2005, Mike Stump wrote:
> On Nov 28, 2005, at 8:41 PM, Hans-Peter Nilsson wrote:
> > runtime,-O1,zlib-1.1.4:minigzip,previous 0.32
>
> Ah, ok, good. I'd eject the ,previous to the filename, and reorder
> slightly, but, certainly that is trivial to do.
Um, (typo?) not a filename, b
On Nov 28, 2005, at 8:41 PM, Hans-Peter Nilsson wrote:
runtime,-O1,zlib-1.1.4:minigzip,previous 0.32
Ah, ok, good. I'd eject the ,previous to the filename, and reorder
slightly, but, certainly that is trivial to do.
Can't be compared with each other
I suspect we're in agreement, though
On Mon, 2005-11-28 at 17:55 -0800, Mike Stump wrote:
> My feeling is that we should have such a suite. I'd favor a micro
> style, where we are measuring clock cycles (on machines that can
> expose them x86/v9), [...]
A while ago I looked at rdtsc on x86-linux, but I couldn't find a way,
other
On Tue, Nov 29, 2005 at 11:41:24AM -0800, Mark Mitchell wrote:
> Richard Henderson wrote:
>
> > I'd been hoping that someone would move libgcc to toplevel, and
> > perhaps rearrange fp emulation after that.
>
> I'd really like to see libgcc move too; is anyone actively working on
> that? (We're
Richard Henderson wrote:
> I'd been hoping that someone would move libgcc to toplevel, and
> perhaps rearrange fp emulation after that.
I'd really like to see libgcc move too; is anyone actively working on
that? (We're not...)
So, I'm afraid we're going to end up going in the other order, unle
On Mon, Nov 28, 2005 at 06:05:34PM -0800, Mark Mitchell wrote:
> That message contains an IEEE floating-point emulation library, like
> fp-bit.c. Howeve, the performance is considerably better; Joseph
> measured against fp-bit.c with a modern compiler, and ieeelib.c is about
> 10-15% better than t
The new apple branch appers to work in gnu/linux/x86. An update of
Chirs' patch to the new version of the branch is available at
gcc-llvm-apple-local-200502-branch-107672.patch.bz2.
It compiles xgcc but this in turn fails to compile crtbegin.o:
plus_expr 0xb7b89aa0
type
sizes-gim
On Mon, Nov 28, 2005 at 08:20:31PM -0800, Jim Wilson wrote:
> There isn't enough ia64 maintainer bandwidth to provide detailed
> comments on testsuite results on old machines with old tools versions.
Sorry I don't have anything newer. I think the results are about as good
as what I saw before (
On Mon, Nov 28, 2005 at 06:23:27PM -0800, Mark Mitchell wrote:
> Joe Buck wrote:
>
> > Well, the problem is that you're raising a legal technicality, and legal
> > technicalities are up to the FSF. Maybe they'll have no problem,
> > especially if Swox AB basically is Torbjorn. If there is a prob
On Mon, 28 Nov 2005, Joe Buck wrote:
On Mon, 28 Nov 2005, Mark Mitchell wrote:
We're collectively putting a lot of energy into performance
improvements in GCC. Sometimes, a performance gain from one patch gets
undone by another patch -- which is itself often doing something else
beneficial.
On Tue, Nov 29, 2005 at 01:44:44PM +, Joern RENNECKE wrote:
> No, it wasn't. The change was supposed to affect structures only.
> As I understand the documentation ,the expected behaviour would be to
> limit the alignment
> to BIGGEST_ALIGNMENT, unless the user has specified a larger alignmen
Jakub Jelinek wrote:
I have looked just at one failure, but maybe all of them are the same thing.
typedef char __attribute__((vector_size (16))) v16qi;
int i = __alignof__ (v16qi);
with GCC 4.0 sets i to 8 (s390{,x} have BIGGEST_ALIGNMENT 64), but
GCC 4.1 sets i to 16.
The changes that created
On Tuesday 29 November 2005 02:47, Andrew Pinski wrote:
> Of course this patch does not include the new files so nobody can help you
> :).
Oops.
Updated
> -- Pinski
Thanks,
Rafael
pgpZDHVHItA32.pgp
Description: PGP signature
In his original message, Torbjorn indicated that Swox AB (the company of
which he is CEO) donated the code, and the old copyright file had an
entry for Torbjorn, though not Swox AB.
Well, the problem is that you're raising a legal technicality, and legal
technicalities are up to the FSF. Mayb
40 matches
Mail list logo
