On Sun, 22 Apr 2007, Andrew Pinski wrote:
> On 4/22/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > I think it was just by accident that the libfuncs would fit in
> > phi_node+3 operand slot. Also I think extra_order_size_table needs to
> > be relooked at after my phi_node and the gimple_stmt pa
On Sun, 2007-04-22 at 17:32 -0700, Mark Mitchell wrote:
> Steve Ellcey wrote:
> >> It came up in a few side conversations. As I understand it, RMS has
> >> decreed that the -On optimizations shall be architecture independent.
> >> That said, there are "generic" optimizations which really only appl
Hi there
I'd like to offer to help with Gnu Fortran development. Please would
you let me know in what areas volunteer help is needed, and I can
then tell you which areas fit in with my expertise. I like working on
apple macs, and I think I know them fairly well, but also have a
couple of
> (In fact, there's nothing inherent in even using the same algorithms on
> all processors; I can well imagine that the best register allocation
> algorithms for x86 and Itanium might be entirely different. I'm in no
> way trying to encourage an entire set of per-achitecture optimization
> passes;
Richard Earnshaw wrote:
> I think it would be nicer if this could be done in a MI way by examining
> certain target properties. For example, the generic framework might say
> something like: 'if there's more than N gp registers, enable opt_foo at
> -O2 or above'.
Yes, I agree; wherever that tech
tree_io
.o
+===GNAT BUG DETECTED==+
| 4.3.0 20070423 (experimental) (i686-pc-cygwin) GCC error:|
| in set_curr_insn_source_location, at cfglayout.c:284 |
| Error detected around /usr/local/src/trunk/gcc/gcc/ada
Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -fno-common -gnatpg -gnata -I- -I../rts -I. -I/usr/loc
al/src/trunk/gcc/gcc/ada /usr/local/src/trunk/gcc/gcc/ada/tree_io.adb -o tree_io
.o
+===GNAT BUG DETECTED==+
| 4.3.0 20070423 (experi
I've promised to make more thorough and accurate comparison of
df-branch and mainline on last merge point to the branch. The
df-branch compiler does not include sunday's Steven's patch which uses
a separate obstack for df bitmaps. It does not change code but it can
speedup the df-branch compile
On 4/23/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
...
To improve the scores I'd recommend to pay attention to big
degradation in SPEC score:
9% perlbmk degradation on Pentium4
3% fma3d degradation on Core2
3% eon and art degradation on Itanium
3% gap and wupwise degradation on PPC64.
V
Jim Wilson wrote:
> Kenneth Hoste wrote:
> > I'm not sure what 'tests' mean here... Are test cases being extracted
> > from the SPEC CPU2006 sources? Or are you refering to the validity tests
> > of the SPEC framework itself (to check whether the output generated by
> > some binary conforms with t
Tim Prince wrote:
[EMAIL PROTECTED] wrote:
Where is gstdint.h ? Does it acctually exist ?
libdecnumber seems to use it.
decimal32|64|128.h's include decNumber.h which includes deccontext.h
which includes gstdint.h
When you configure libdecnumber (e.g. by running top-level gcc
configure), g
On 4/23/07, Seongbae Park <[EMAIL PROTECTED]> wrote:
As for the perlbmk slowdown on P4.
my initial guess is that it might be due to cross-jumping or block ordering
- those are things I noticed the dataflow branch generates slightly
different code
than mainline.
I didn't try to narrow down where
On Sun, Apr 22, 2007 at 04:39:23PM -0700, Joe Buck wrote:
>
> On Sun, 2007-04-22 at 14:44 +0200, Richard Guenther wrote:
> > > At work we use -O3 since it gives 5% performance gain against -O2.
> > > profile-feedback has many flags and there is no overview of it in the
> > > doc IIRC. Who will use
On Mon, 23 Apr 2007, Mark Mitchell wrote:
> I'm certainly not trying to suggest that we run SPEC on every
> architecture, and then make -O2 be the set of optimization options that
> happens to do best there, however bizarre.
Why not? Is your objection because SPEC doesn't reflect real-world apps
On Mon, 23 Apr 2007, Mark Mitchell wrote:
> > I'm certainly not trying to suggest that we run SPEC on every
> > architecture, and then make -O2 be the set of optimization options that
> > happens to do best there, however bizarre.
On Mon, Apr 23, 2007 at 01:21:20PM -0400, Kaveh R. GHAZI wrote:
>
Kaveh R. GHAZI wrote:
> On Mon, 23 Apr 2007, Mark Mitchell wrote:
>
>> I'm certainly not trying to suggest that we run SPEC on every
>> architecture, and then make -O2 be the set of optimization options that
>> happens to do best there, however bizarre.
>
> Why not? Is your objection because SPE
"H. J. Lu" <[EMAIL PROTECTED]> wrote on 23/04/2007 01:34:39:
> On Mon, Apr 23, 2007 at 12:55:26AM +0300, Dorit Nuzman wrote:
> > "H. J. Lu" <[EMAIL PROTECTED]> wrote on 23/04/2007 00:29:16:
> >
> > > On Sun, Apr 22, 2007 at 11:14:20PM +0300, Dorit Nuzman wrote:
> > > > "H. J. Lu" <[EMAIL PROTECTED
Mark Mitchell wrote on 04/23/07 13:56:
> So, I think there's a middle ground between "exactly the same passes on
> all targets" and "use Acovea for every CPU to pick what -O2 means".
> Using Acovea to reveal some of the suprising, but beneficial results,
> seems like a fine idea, though.
I'm hopi
Citeren "Kaveh R. GHAZI" <[EMAIL PROTECTED]>:
On Mon, 23 Apr 2007, Mark Mitchell wrote:
I'm certainly not trying to suggest that we run SPEC on every
architecture, and then make -O2 be the set of optimization options that
happens to do best there, however bizarre.
Why not? Is your objection
On 23 April 2007 19:07, Diego Novillo wrote:
> Mark Mitchell wrote on 04/23/07 13:56:
>
>> So, I think there's a middle ground between "exactly the same passes on
>> all targets" and "use Acovea for every CPU to pick what -O2 means".
>> Using Acovea to reveal some of the suprising, but beneficial
Vladimir Makarov wrote:
I've promised to make more thorough and accurate comparison of
df-branch and mainline on last merge point to the branch. The
df-branch compiler does not include sunday's Steven's patch which uses
a separate obstack for df bitmaps. It does not change code but it can
spe
Citeren Diego Novillo <[EMAIL PROTECTED]>:
Mark Mitchell wrote on 04/23/07 13:56:
So, I think there's a middle ground between "exactly the same passes on
all targets" and "use Acovea for every CPU to pick what -O2 means".
Using Acovea to reveal some of the suprising, but beneficial results,
se
Dave Korn wrote on 04/23/07 14:26:
> Has any of the Acovea research demonstrated whether there actually is any
> such thing as a "good default set of flags in all cases"? If the results
Not Acovea itself. The research I'm talking about involves a compiler
whose pipeline can be modified and re
Citeren Dave Korn <[EMAIL PROTECTED]>:
On 23 April 2007 19:07, Diego Novillo wrote:
Mark Mitchell wrote on 04/23/07 13:56:
So, I think there's a middle ground between "exactly the same passes on
all targets" and "use Acovea for every CPU to pick what -O2 means".
Using Acovea to reveal some o
Citeren Diego Novillo <[EMAIL PROTECTED]>:
Dave Korn wrote on 04/23/07 14:26:
Has any of the Acovea research demonstrated whether there actually is any
such thing as a "good default set of flags in all cases"? If the results
Not Acovea itself. The research I'm talking about involves a co
[EMAIL PROTECTED] wrote on 04/23/07 14:37:
> Currently, the -On flags set/unset 60 flags, which yields 2^60 conbinations.
> If you also kind the passes not controlled by a flag, but decided upon
> depending on the optimization level, that adds another, virtual flag
> (i.e. using -O1, -O2, -O3
On Mon, Apr 23, 2007 at 09:05:05PM +0300, Dorit Nuzman wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> wrote on 23/04/2007 01:34:39:
>
> > On Mon, Apr 23, 2007 at 12:55:26AM +0300, Dorit Nuzman wrote:
> > > "H. J. Lu" <[EMAIL PROTECTED]> wrote on 23/04/2007 00:29:16:
> > >
> > > > On Sun, Apr 22, 2007 at
[EMAIL PROTECTED] wrote on 04/23/07 14:40:
> Any references?
Yes, at the last HiPEAC conference Grigori Fursin presented their
interactive compilation interface, which could be used for this.
http://gcc-ici.sourceforge.net/
Ben Elliston had also experimented with a framework to allow GCC to
chan
On Mon, 2007-04-23 at 10:56 -0700, Mark Mitchell wrote:
> Kaveh R. GHAZI wrote:
> > On Mon, 23 Apr 2007, Mark Mitchell wrote:
> >
> >> I'm certainly not trying to suggest that we run SPEC on every
> >> architecture, and then make -O2 be the set of optimization options that
> >> happens to do best
On 23 Apr 2007, at 20:43, Diego Novillo wrote:
[EMAIL PROTECTED] wrote on 04/23/07 14:37:
Currently, the -On flags set/unset 60 flags, which yields 2^60 conbinations.
If you also kind the passes not controlled by a flag, but decided upon
depending on the optimization level, that adds another, vi
On Mon, Apr 23, 2007 at 09:49:04AM -0700, Steve Ellcey wrote:
> Jim Wilson wrote:
>
> > Kenneth Hoste wrote:
> > > I'm not sure what 'tests' mean here... Are test cases being extracted
> > > from the SPEC CPU2006 sources? Or are you refering to the validity tests
> > > of the SPEC framework itself
> This is a know problem until the Ada people fix their frontend.
Could you elaborate? What's known problem exactly?
> I suppose the upfront notice was not sent.
Indeed, and the timing is quite unfortunate since the Ada compiler was
independently broken yesterday too and is moreover plagued by
On Fri, Apr 20, 2007 at 01:07:14PM -0400, Aldy Hernandez wrote:
> + /* There can be 3 types of unary operations:
> +
> + SYM =<== GSS_ASSIGN_UNARY_REG
> + SYM = SYM2 <== GSS_ASSIGN_UNARY_MEM
Um, ssa_name = ssa_name isn't a memory
> +/* A seq
I am working on the cegcc project (http://cegcc.sourceforge.net), which
bundles a bunch of the GNU development tools to produce a
cross-development environment for ARM devices running Windows CE. The
development hosts supported are Linux and Cygwin.
Gcov normally puts the files where it writes pro
> > +/* A sequences of gimple statements. */
> > +#define GS_SEQP_FIRST(S) (S)->first
> > +#define GS_SEQP_LAST(S)(S)->last
> > +#define GS_SEQ_FIRST(S)(S).first
> > +#define GS_SEQ_LAST(S) (S).last
>
> Why do you have both of these?
Most places in the gimpl
I presume that this:
-I../../trunk/gcc/../libdecnumber/bid -I../libdecnumber
../../trunk/gcc/gimplify.c -o gimplify.o
../../trunk/gcc/gimplify.c: In function 'create_tmp_var_name':
../../trunk/gcc/gimplify.c:431: internal compiler error: in
set_curr_insn_source_location, at cfglayout.c:28
On 4/23/07, Paul Richard Thomas <[EMAIL PROTECTED]> wrote:
on x86_ia64/fc5 is not a coincidence?
More over, there were a lot of targets by this patch because they
would call insn_locators_initialize when generating the thunks (x86
did not because it uses text based thunks and not RTL based thun
"H. J. Lu" <[EMAIL PROTECTED]> wrote on 23/04/2007 21:56:37:
...
> > > > > > so this looks like a vec_unpacku_hi_v4si (or _lo?), i.e. what
is
> > now
> > > > > > modeled as follows in sse.md:
> > > > > >
> > > > > > (define_expand "vec_unpacku_hi_v4si"
> > > > > > [(match_operand:V2DI 0 "registe
On Mon, Apr 23, 2007 at 04:30:40PM -0400, Aldy Hernandez wrote:
> I figured
> it'd be better than doing GS_SEQP_FIRST(&non_pointer), but I can if you
> prefer.
I think I would, though without the "P".
r~
J.C. Pizarro wrote:
Your idea with JavaScript, CSS, XSLT, .. is very good! :)
Thanks you - but ideas are cheap. Turned a vague idea into
something useful is a different matter
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Since the change listed below, bootstrap on powerpc is broken when you
configure for both powerpc-linux and powerpc64-linux:
2007-04-04 Jakub Jelinek <[EMAIL PROTECTED]>
* libgomp.h (gomp_cpu_affinity, gomp_cpu_affinity_len): New extern
decls.
The error I get is:
../../../../s
Snapshot gcc-4.1-20070423 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070423/
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
Hi
I am wondering how gcc handles producing debug information for
automatic variables that do not reside inthe stack.For example when
say register allocation decides to assign a particular register to a
variable or say it decides that the value is a constant. Can some
one point me to the rele
, %xmm2
pmovsxbw%xmm0, %xmm1
punpckhbw %xmm10, %xmm9
punpckhbw %xmm7, %xmm6
punpckhbw %xmm4, %xmm3
punpckhbw %xmm2, %xmm0
movdqa %xmm11, y(%rip)
movdqa %xmm9, y+16(%rip)
movdqa %xmm8, y+32(%rip)
movdqa %xmm6, y+48(%rip)
movdqa %xmm5, y+64(%rip)
movdqa %xmm3, y+80(%rip)
movdqa %xmm1, y+96(%rip)
movdqa %xmm0, y+112(%rip)
ret
.size foo, .-foo
.ident "GCC: (GNU) 4.3.0 20070423 (experimental) [trunk revision
124056]"
.section.note.GNU-stack,"",@progbits
> > I figured
> > it'd be better than doing GS_SEQP_FIRST(&non_pointer), but I can if you
> > prefer.
>
> I think I would, though without the "P".
Ok, everything fixed, except I haven't added the sequence iterators yet.
I am committing the patch below to the gimple-tuples-branch.
Thanks again.
> On 4/23/07, Paul Richard Thomas <[EMAIL PROTECTED]> wrote:
> >on x86_ia64/fc5 is not a coincidence?
>
> More over, there were a lot of targets by this patch because they
> would call insn_locators_initialize when generating the thunks (x86
> did not because it uses text based thunks and not RTL
It happens! It also meant that I got to bed early:)
Thanks
Paul
On 4/24/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> On 4/23/07, Paul Richard Thomas <[EMAIL PROTECTED]> wrote:
> >on x86_ia64/fc5 is not a coincidence?
>
> More over, there were a lot of targets by this patch because they
> would
[EMAIL PROTECTED] wrote:
Tim Prince wrote:
[EMAIL PROTECTED] wrote:
Where is gstdint.h ? Does it acctually exist ?
libdecnumber seems to use it.
decimal32|64|128.h's include decNumber.h which includes deccontext.h
which includes gstdint.h
When you configure libdecnumber (e.g. by running to
Hi!
Sorry about the (possibly off) question: would this apply also to
GMP/MPFR, if not, wouldn't it make sense?
Philippe
François-Xavier Coudert wrote:
>
> Hi all,
>
> Attached is a first draft of a patch to add a -fstatic-libgfortran
> option. This new option is recognized by the driver and
49 matches
Mail list logo
