On 3/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
As for the current problem, I think a 3% hit is pretty big. I didn't
find subcodes that ugly, so I guess I'm inclined to go with subcodes,
and avoid the hit.
We know that one still mostly unaddressed problem that tree-ssa left
us with, is po
Google is now accepting student applications for Google Summer of Code
2007. Students who wish to apply for a gcc project should do so now.
The deadline is March 24.
Here is a guide for student applicants:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-we
Nicholas Nethercote wrote:
> As for what is best to do, I don't know. But I do know that complexity
> is bad, and that GCC is very complex. You are absolutely right about
> there being hard limits. There are trade-offs required. Whether the
> current and ongoing trade-offs are the right ones i
Joe Buck wrote:
Agreed; -O0 could in principle be sped up; the important thing is making
sure that it happens. In this case, adding a pass that computes SSA
information that is used only for uninitialized variable warnings costs
time; it could be compensated for by finding other speedups, but t
On Mar 19, 2007, at 3:41 PM, Gabriel Dos Reis wrote:
yeah, the trouble is that we don't seem to agree on what is good for
long-term
Sure we do, unless you want a slower compiler that doesn't track the
ANSI C++ standard.
> -Original Message-
> From: Andrew Pinski [mailto:[EMAIL PROTECTED]
> Sent: 19 March 2007 00:47
> To: Alexander Lamaison
> Cc: gcc@gcc.gnu.org
> Subject: Re: Pointer addition/subtraction tree node
>
> On 3/18/07, Alexander Lamaison <[EMAIL PROTECTED]> wrote:
> > As part of adding a new pa
On Mon, 19 Mar 2007, Doug Gregor wrote:
But what is the solution? We can complain about performance all we
want (and we all love to do this), but without a plan to fix it we're
just wasting effort. Shall we reject every patch that causes a slow
down? Hold up releases if they are slower than thei
Hi,
I recently filed a bug against 4.2:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
The bug does not appear to be in 4.1.2 or mainline. Is it something
that could be fixed for 4.2.0?
Is this a good place to ask this question? (er... the previous question :)
Thanks,
Charles J. Tabony
"Doug Gregor" <[EMAIL PROTECTED]> writes:
| On 19 Mar 2007 19:12:35 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > similar justifications for yet another small% of slowdown have been
| > given routinely for over 5 years now. small% build up; and when they
| > build up, they don't not to b
On 3/19/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
On 19 Mar 2007 19:12:35 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> similar justifications for yet another small% of slowdown have been
> given routinely for over 5 years now. small% build up; and when they
> build up, they don't not to
On 19 Mar 2007 19:12:35 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
similar justifications for yet another small% of slowdown have been
given routinely for over 5 years now. small% build up; and when they
build up, they don't not to be convincing ;-)
But what is the solution? We can com
Hi. I am looking for someone to mentor me on this project for the GNU
Scientific Library. I have already tried asking Brian Gough (forwarded
below), and he suggested that someone from the gcc team might be able
to mentor me, presumably under the auspices of GNU or something like
that.
I hope ther
"Doug Gregor" <[EMAIL PROTECTED]> writes:
[...]
| and optimize than yesterday's. No, I don't want my compiler to be 5%
| slower, but I'll give up 5% for better standards conformance and
| improved code generation.
similar justifications for yet another small% of slowdown have been
given routinel
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
[...]
| I'm sorry to ask such a (probably naive) question, but do someone have a
| precise idea of the performance strengths and weaknesses of GCC and of other
| opensource compilers (like LLVM, Open64, TinyCC, ...) or even compiler for
| different
On 3/19/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
GCC has also been getting improved functionality, better
optimizations, and better language support. Some of these improvements
are going to cost us at compile time, because better optimizations can
require more time, and today's languages requir
On 3/19/07, Nicholas Nethercote <[EMAIL PROTECTED]> wrote:
As an interested outsider: GCC's compile-time speed has been gradually
decreasing for a while now. It seems to be acknowledged as an undesirable
thing, but not much has happened to change it. AIUI, this is largely
because it's very dif
Snapshot gcc-4.1-20070319 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070319/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Mon, Mar 19, 2007 at 03:32:19PM -0400, David Edelsohn wrote:
> > Joe Buck writes:
>
> Joe> What worries me is that we can't afford to make -O0 run significantly
> Joe> slower than it does now. Cycle speeds are no longer increasing, we have
> Joe> to be very careful about slowing things dow
Le Mon, Mar 19, 2007 at 05:41:08PM -0500, Gabriel Dos Reis écrivait/wrote:
> Nicholas Nethercote <[EMAIL PROTECTED]> writes:
>
> | On Mon, 19 Mar 2007, Doug Gregor wrote:
> |
> | >> > It's going to have a big performance impact. To extract a 9-bit value,
> | >> > the compiler will need to do a lo
What should I do if I want a list of all file-scope variables inside
my own pass ?
The file_scope variable is local to c-decl.c . Is there a reason why
the scope holding variables are local to c-decl.c ?
-
Karthik
Eric Lemings wrote:
test.cpp: In function 'int main()':
test02.cpp:6: error: could not convert 's.S::v' to 'bool'
test02.cpp:6: error: in arguument to unary !
As per my gcc-bugs message. I suggest this untested patch.
--
Jim Wilson, GNU Tools Support, http://www.specifi
On Monday 19 March 2007 23:00:09 Eric Lemings wrote:
> Hi,
>
> The following code compiles fine in GCC 4.1.
>
> enum E { e };
> struct S {
> E v:5;
> };
> S s;
> int main() { if (!s.v) return 0; }
>
> In 4.2 (20070307), it gives the following error:
>
> t
Florian Weimer writes:
> Is there a convenient switch to make GCC bootstrap on Debian/amd64
> without patching the build infrastructure? Apparently, GCC tries to
> build 32-bit variants of all libraries (using -m32), but the new
> compiler uses the 64-bit libc instead of the 32-bit libc, hence
> b
Nicholas Nethercote <[EMAIL PROTECTED]> writes:
| On Mon, 19 Mar 2007, Doug Gregor wrote:
|
| >> > It's going to have a big performance impact. To extract a 9-bit value,
| >> > the compiler will need to do a lot of masking every time it accesses
| >> > the TREE_CODE.
| >>
| > So, about 16% slower
On Mon, 2007-03-19 at 18:45 +, Manuel López-Ibáñez wrote:
> On 19/03/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> > On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote:
> > > Perhaps this ought to be looked at again with some seriousness.
> >
> > I think this is an idea whose t
Joe Buck writes:
>This brings up a point: the build procedure doesn't work by default on
>Debian-like amd64 distros, because they lack 32-bit support (which is
>present on Red Hat/Fedora/SuSE/etc distros). Ideally this would be
>detected when configuring.
The Debian-like AMD64 system I'm using ha
On Mon, 19 Mar 2007, Doug Gregor wrote:
> It's going to have a big performance impact. To extract a 9-bit value,
> the compiler will need to do a lot of masking every time it accesses
> the TREE_CODE.
So, about 16% slower with --enable-checking, 5% slower with
--disable-checking.
Subcodes mi
Hi,
The following code compiles fine in GCC 4.1.
enum E { e };
struct S {
E v:5;
};
S s;
int main() { if (!s.v) return 0; }
In 4.2 (20070307), it gives the following error:
test.cpp: In function 'int main()':
test02.cpp:6: error:
Except when travelling backwards in time and replying to a post that hasn't
been written yet!
cheers,
DaveK
--
Can't think of a witty .sigline today
On 19 March 2007 20:21, Mike Stump wrote:
> Never top post.
>
> On Mar 19, 2007, at 3:13 AM, Markus Franke wrote:
>
>> Just anot
Florian Weimer wrote:
* Andrew Pinski:
Actually it brings up an even more important thing, distros that don't
include a 32bit user land is really just broken.
Are they? I haven't run into problems yet.
(And pretty please, I misread the documentation. It does *not* state
that amd64 is not
On Sun, Mar 18, 2007 at 09:07:32AM -0700, Andrew Pinski wrote:
> On 3/18/07, Victor Kaplansky <[EMAIL PROTECTED]> wrote:
> >
> >I have obtained the same error on my ppc64 yellow dog linux:
>
> >collect2: ld terminated with signal 11 [Segmentation fault]
> >
> >> I get the following error on PPC wh
Never top post.
On Mar 19, 2007, at 3:13 AM, Markus Franke wrote:
Just another issue. Everything is working fine if using "-O1", "-
O2" or
"-O3".
Maybe this helps.
Regards,
Markus
Markus Franke wrote:
* Andrew Pinski:
> Actually it brings up an even more important thing, distros that don't
> include a 32bit user land is really just broken.
Are they? I haven't run into problems yet.
(And pretty please, I misread the documentation. It does *not* state
that amd64 is not a multilib target. Sor
Dave Korn wrote:
In particular, I really don't understand what a RELOAD_FOR_INPUT_ADDRESS
means when all the operands are regs, or why there should be three reloads for
the same operand when it's just a clobber scratch. Is there something special
about how reload handles clobber and match_scra
Florian Weimer wrote:
* Steven Bosscher:
On 3/18/07, Florian Weimer <[EMAIL PROTECTED]> wrote:
I don't need the 32-bit libraries, so disabling their compilation
would be fine. --enable-targets at configure time might do the trick,
but I don't know what arguments are accepted.
Would --disable
> Joe Buck writes:
Joe> What worries me is that we can't afford to make -O0 run significantly
Joe> slower than it does now. Cycle speeds are no longer increasing, we have
Joe> to be very careful about slowing things down.
Adding more passes does not necessarily slow down the compiler
Richard Sandiford wrote:
That isn't unconditionally true, is it? reload1.c:gen_reload
uses gen_move_insn, which is just a start_sequence/end_sequence
wrapper for emit_move_insn_1, which in turn calls the move expanders.
Yes, you are right. I over simplified. We can use gen_move_insn when
we
On Mon, Mar 19, 2007 at 02:34:22PM -0400, Daniel Jacobowitz wrote:
> On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote:
> > Perhaps this ought to be looked at again with some seriousness.
>
> I think this is an idea whose time has either come, or will shortly.
> GCC's -O0 is much more
Manuel López-Ibáñez wrote on 03/19/07 14:45:
> Is building this early SSA form something that can be tackled by a
> newbie developer with almost zero middle-end knowledge within the time
> frame of the Summer of Code?
Yes, it should not be too hard. See tree_lowering_passes.
You may also want t
On 19/03/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote:
> Perhaps this ought to be looked at again with some seriousness.
I think this is an idea whose time has either come, or will shortly.
GCC's -O0 is much more extreme than tha
On Mon, Mar 19, 2007 at 06:05:05PM +, Andrew Haley wrote:
> Will that work? Unless there's some more configury I don't
> understand, they'll still end up with libraries in /lib64 rather than
> /lib.
It does work. You have to do a bit more fiddling if you want to use
'make install' into a sys
On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote:
> Perhaps this ought to be looked at again with some seriousness.
I think this is an idea whose time has either come, or will shortly.
GCC's -O0 is much more extreme than that of other compilers I've used.
--
Daniel Jacobowitz
CodeS
Code of the form
int[10] a;
int* p = a; int* q = a;
int i = 3;
p = q + i;
is transformed into
int * D.900;
unsigned int D.899;
unsigned int i.0;
:
i = 3;
p = &a;
q = &a;
i.0 = (unsigned int) i;
D.89
Joe Buck writes:
> On Mon, Mar 19, 2007 at 10:35:15AM -0700, Andrew Pinski wrote:
> > On 3/19/07, Joe Buck <[EMAIL PROTECTED]> wrote:
> > >This brings up a point: the build procedure doesn't work by default on
> > >Debian-like amd64 distros, because they lack 32-bit support (which is
> > >pres
Dave Korn wrote:
> Also, it's not actually a hard reg, it's in fact a memory-mapped peripheral.
> This means that I need to specify secondary reloads (can't be loaded directly
> from memory as I have no mem->mem move insn, needs to go via a gpr) and that
> implies that the register has to exist
On Mon, Mar 19, 2007 at 10:35:15AM -0700, Andrew Pinski wrote:
> On 3/19/07, Joe Buck <[EMAIL PROTECTED]> wrote:
> >This brings up a point: the build procedure doesn't work by default on
> >Debian-like amd64 distros, because they lack 32-bit support (which is
> >present on Red Hat/Fedora/SuSE/etc d
On Mon, 2007-03-19 at 10:33 -0700, Joe Buck wrote:
> On Mon, Mar 19, 2007 at 09:27:25AM -0400, Diego Novillo wrote:
> > Manuel López-Ibáñez wrote on 03/17/07 14:28:
> >
> > > This is the project proposal that I am planning to submit to Google
> > > Summer of Code 2007. It is based on previous work
On 19 March 2007 17:03, Ulrich Weigand wrote:
> Dave Korn wrote:
>
>> (define_insn "mulsi3"
>> [(set (match_operand:SI 0 "register_operand" "=d")
>> (mult:SI (match_operand:SI 2 "register_operand" "r")
>> (match_operand:SI 1 "register_operand" "a")))
>>(clobber (mat
On 3/19/07, Joe Buck <[EMAIL PROTECTED]> wrote:
This brings up a point: the build procedure doesn't work by default on
Debian-like amd64 distros, because they lack 32-bit support (which is
present on Red Hat/Fedora/SuSE/etc distros). Ideally this would be
detected when configuring.
Actually it
On Mon, Mar 19, 2007 at 09:27:25AM -0400, Diego Novillo wrote:
> Manuel López-Ibáñez wrote on 03/17/07 14:28:
>
> > This is the project proposal that I am planning to submit to Google
> > Summer of Code 2007. It is based on previous work of Jeffrey Laws,
> > Diego Novillo and others. I hope someon
On Mon, Mar 19, 2007 at 08:52:26AM +0100, Andreas Jaeger wrote:
> Florian Weimer <[EMAIL PROTECTED]> writes:
>
> > * Steven Bosscher:
> >
> >> On 3/18/07, Florian Weimer <[EMAIL PROTECTED]> wrote:
> >>> I don't need the 32-bit libraries, so disabling their compilation
> >>> would be fine. --enable
Dave Korn wrote:
> (define_insn "mulsi3"
> [(set (match_operand:SI 0 "register_operand" "=d")
> (mult:SI (match_operand:SI 2 "register_operand" "r")
> (match_operand:SI 1 "register_operand" "a")))
>(clobber (match_scratch:SI 3 "b"))]
You should be using "=b" to desi
Richard Guenther writes:
>
> It's indeed broken to look through VIEW_CONVERT_EXPRs here. The patch looks
> obviously correct.
OK, thanks. Forwarding to gcc-patches.
Andrew.
On 3/19/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
This happens because we have a VIEW_CONVERT EXPR(double->long) that is
used in a conditional. VRP tries to register an edge assertion for
this expression:
unit size
align 64
On Mar 19, 2007, at 05:44, François-Xavier Coudert wrote:
I have the three following questions, probably best directed to
middle-end experts and Ada maintainers:
* How can I know the longest float type? My first patch uses the
long_double_type_node unconditionally, but it surely isn't a generic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
This happens because we have a VIEW_CONVERT EXPR(double->long) that is
used in a conditional. VRP tries to register an edge assertion for
this expression:
unit size
align 64 symtab 0 alias set -1 canonical type 0x2dfee3c0 pr
Yes, that's right that without good analysis part it is semi-useless.
Actually, it can even make life harder since instead of one dataset
you now have to try many ;) ...
We did some preliminary analysis of the compiler optimizations for programs
with multiple datasets in our HiPEAC'07 paper using
On 3/19/07, Grigori Fursin <[EMAIL PROTECTED]> wrote:
Hi all,
In case someone is interested, we are developing a set of inputs
(MiDataSets) for the MiBench benchmark. Iterative optimization
is now a popular technique to obtain performance or code size improvements
over the default settings in a
On 3/19/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/19/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
> I went ahead and implemented this, to see what the real impact would
> be. The following patch frees up TREE_LANG_FLAG_5, and uses that extra
> bit for the tree code.
>
> On tramp3d, memory
Steven Bosscher wrote on 03/19/07 10:14:
> IMHO this is still the better solution than the subcodes idea.
Agreed. If the performance hit is not too large, getting a wider tree
code is much simpler to maintain.
> So, about 16% slower with --enable-checking, 5% slower with
> --disable-checking.
That's about an order of magnitude more than I'd expect and is very strange.
To a very close approximation, the speed of integer code on modern machine
is affected only by the number of cache misses. Why should th
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> François-Xavier Coudert
> Sent: Monday, March 19, 2007 5:54 AM
> To: GCC Development
> Subject: Has insn-attrtab.c been growing in size recently?
>
> Hi all,
>
> A bootstrap attempt of GCC mainline on
On 3/19/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
I went ahead and implemented this, to see what the real impact would
be. The following patch frees up TREE_LANG_FLAG_5, and uses that extra
bit for the tree code.
On tramp3d, memory usage remains the same (obviously), and the
performance results
On 19/03/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Manuel López-Ibáñez wrote on 03/17/07 14:28:
> This is the project proposal that I am planning to submit to Google
> Summer of Code 2007. It is based on previous work of Jeffrey Laws,
> Diego Novillo and others. I hope someone will find it in
On 3/12/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> It's going to have a big performance impact. To extract a 9-bit value,
> the compiler will need to do a lot of masking every time it accesses
> the TREE_CODE.
"a lot masking" means at most two additional instructions, one if we
put it in th
Manuel López-Ibáñez wrote on 03/17/07 14:28:
> This is the project proposal that I am planning to submit to Google
> Summer of Code 2007. It is based on previous work of Jeffrey Laws,
> Diego Novillo and others. I hope someone will find it interesting and
Yes, I can act as a mentor.
I'm particul
On 19/03/07, Robert Dewar <[EMAIL PROTECTED]> wrote:
Jeffrey Law wrote:
> The one technical bit we never tacked was unoptimized compilation; I
> goof'd at one time and thought we went ahead and build the SSA graph
> even when not optimizing which is incorrect. I don't think fixing this
> should
Jeffrey Law wrote:
The one technical bit we never tacked was unoptimized compilation; I
goof'd at one time and thought we went ahead and build the SSA graph
even when not optimizing which is incorrect. I don't think fixing this
should be a requirement for improving the current situation with
-W
On Mon, Mar 19, 2007 at 05:25:37AM -0700, Karthikeyan M wrote:
> Thanks for the information.
> So, if I want to debug a bug in the cc1 code that causes target
> library build to fail -
> should I just use the cc1 that is generated in /gcc/ ?
Yes.
--
Daniel Jacobowitz
CodeSourcery
Thanks for the information.
So, if I want to debug a bug in the cc1 code that causes target
library build to fail -
should I just use the cc1 that is generated in /gcc/ ?
Is there a better way of doing this, without going through a make that
builds some components successfully (cc1) and fails fo
Morning all,
I'm not entirely familiar with the format and meaning of all the terms used
in the reload pass dump files, I was wondering if someone could comment on
whether this seems sane or not:
mul.c: In function `try_mulsi3':
mul.c:5: error: unable to find a register to spill in class
Hi all,
In case someone is interested, we are developing a set of inputs
(MiDataSets) for the MiBench benchmark. Iterative optimization
is now a popular technique to obtain performance or code size improvements
over the default settings in a compiler. However, in most
of the research projects,
Hi all,
A bootstrap attempt of GCC mainline on a i386-unknown-netbsdelf2.0.2 with:
Memory: 378M Act, 264M Inact, 3520K Wired, 4664K Exec, 633M File, 151M Free
Swap: 129M Total, 129M Free
failed due to a compilation error in stage1:
cc1: out of memory allocating 138677280 bytes after a total
Hi all,
I'm working on implementing a correct Fortran rounding (rounding to
nearest-integer, with half integer values rounded to the integer of
maximum absolute value) in the Fortran front-end, following
ada/trans.c (convert_with_check) and
http://gcc.gnu.org/ml/fortran/2005-04/msg00139.html
The
Here is my full resume:
http://www.sworde.com/resume2.doc
Please forward this work experience & skills summary
to your Database & software development, MIS/IT/Software Department for review.
--
Resume of Steve Snow
-
75 matches
Mail list logo
