Re: A request for md5 hashs to be published

2008-06-05 Thread Joe Buck
On Fri, Jun 06, 2008 at 01:03:19AM +, Dennis Clarke wrote: > Can the md5 sum hash for the various release files be published at the > main GCC release pages ? > If we look at http://gcc.gnu.org/gcc-4.2/ there is no md5 sum there > and while I can find that data at a mirror thus : > > ftp://ftp

Re: [whopr] Design/implementation alternatives for the driver and WPA

2008-06-05 Thread Ian Lance Taylor
Chris Lattner <[EMAIL PROTECTED]> writes: > On Jun 5, 2008, at 2:03 PM, Ian Lance Taylor wrote: > >> Nick Kledzik <[EMAIL PROTECTED]> writes: >> How does the linker tell LTO that a symbol may be inlined, but must also be externally visible? >>> The linker just tells LTO which symbols mus

A request for md5 hashs to be published

2008-06-05 Thread Dennis Clarke
A small request. Can the md5 sum hash for the various release files be published at the main GCC release pages ? If we look at http://gcc.gnu.org/gcc-4.2/ there is no md5 sum there and while I can find that data at a mirror thus : ftp://ftp.mirrorservice.org/sites/sources.redhat.com/pub/gcc/relea

Re: extend gthr-posix.h with rwlock

2008-06-05 Thread Luke Dalessandro
David Edelsohn wrote: Luke Dalessandro writes: Luke> Thank you, this was indeed the problem. I added the needed stubbs in Luke> gthr-single.h and it now compiles fine. Unfortunately there seems to be Luke> something wrong with my installation of ld as linking fails with a large Luke> number

Re: [lto] Streaming out language-specific DECL/TYPEs

2008-06-05 Thread Daniel Berlin
On Thu, Jun 5, 2008 at 5:57 AM, Jan Hubicka <[EMAIL PROTECTED]> wrote: >> Jan Hubicka wrote: >> >> >Sure if it works, we should be lowering the types during gimplification >> >so we don't need to store all this in memory... >> >But C++ FE still use its local data later in stuff like thunks, but we

Re: extend gthr-posix.h with rwlock

2008-06-05 Thread David Edelsohn
> Luke Dalessandro writes: Luke> Thank you, this was indeed the problem. I added the needed stubbs in Luke> gthr-single.h and it now compiles fine. Unfortunately there seems to be Luke> something wrong with my installation of ld as linking fails with a large Luke> number of errors of the fo

gcc-4.3-20080605 is now available

2008-06-05 Thread gccadmin
Snapshot gcc-4.3-20080605 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080605/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: extend gthr-posix.h with rwlock

2008-06-05 Thread Luke Dalessandro
David Edelsohn wrote: Luke Dalessandro writes: Luke> My problem is that unwind-dw2-fde.c seems to be compiled multiple times during Luke> a gcc build, and sometimes my additions are found but other times they are Luke> not. I am rebuilding again (AIX 5.1), and I'll post more information for

Re: [whopr] Design/implementation alternatives for the driver and WPA

2008-06-05 Thread Chris Lattner
On Jun 5, 2008, at 2:03 PM, Ian Lance Taylor wrote: Nick Kledzik <[EMAIL PROTECTED]> writes: How does the linker tell LTO that a symbol may be inlined, but must also be externally visible? The linker just tells LTO which symbols must remain. The LTO engine is free to inline anything that wo

Re: How to build on AMD64/Debian under x86 32bits chroot?

2008-06-05 Thread Matthias Klose
Basile STARYNKEVITCH writes: > Hello All > > As (I imagine) many developers I have a 64 bits machine - running Debian > (Sid) Linux AMD64. > > I want to test my MELT branch on x86 (32 bits). So I set up (using > debootstrap) a x86 32 bits Debian/Lenny chroot-ed system (in /debian32) > which ha

Re: [whopr] Design/implementation alternatives for the driver and WPA

2008-06-05 Thread Ian Lance Taylor
Nick Kledzik <[EMAIL PROTECTED]> writes: >> How does the linker tell LTO that a symbol may be inlined, but must >> also be externally visible? > The linker just tells LTO which symbols must remain. The LTO engine > is free to inline anything that would improve codegen, with the > exception > that

Re: Question about modifying gcc

2008-06-05 Thread Joe Buck
On Thu, Jun 05, 2008 at 12:55:17PM -0700, [EMAIL PROTECTED] wrote: > I am attempting to modify the compiler to instrument function calls and > returns. The end result that i am trying to achieve is to send the > address of every called function to a memory mapped file prior to the > call and after

Question about modifying gcc

2008-06-05 Thread dreese
Could you please direct me to someone who would be willing and able to answer a few questions about some of the internal workings of the gcc compiler. I am attempting to modify the compiler to instrument function calls and returns. The end result that i am trying to achieve is to send the addr

Re: [whopr] Design/implementation alternatives for the driver and WPA

2008-06-05 Thread Nick Kledzik
On Jun 5, 2008, at 10:43 AM, Ian Lance Taylor wrote: Chris Lattner <[EMAIL PROTECTED]> writes: LLVM LTO handles this by marking symbols "internal" (aka static, aka not TREE_PUBLIC, whatever) when the symbol is not visible outside the LTO scope. This allows the optimizers to go crazy and hack

Re: extend gthr-posix.h with rwlock

2008-06-05 Thread David Edelsohn
> Luke Dalessandro writes: Luke> My problem is that unwind-dw2-fde.c seems to be compiled multiple times during Luke> a gcc build, and sometimes my additions are found but other times they are Luke> not. I am rebuilding again (AIX 5.1), and I'll post more information for Luke> anyone that

extend gthr-posix.h with rwlock

2008-06-05 Thread Luke Dalessandro
We have code that fails to scale do to the object_mutex lock in unwind-dw2-fde.c. This mutex protects two lists local to the file. The primary list is used in "read-mostly" mode, with the secondary list used rarely when writing needs to happen. I am trying to change this locking scheme to use

Re: Development process for i386 machine descriptions

2008-06-05 Thread Uros Bizjak
Hello! 1.) The processor_costs structure seems very limited, but seem very easily to "fill in" but are these costs supposed to be best or worst case? For instance, many instructions with different sized operands vary in latency. Instruction costs are further refined in config/i386.c, ix86_rt

Re: [whopr] Design/implementation alternatives for the driver and WPA

2008-06-05 Thread Ian Lance Taylor
Chris Lattner <[EMAIL PROTECTED]> writes: > LLVM LTO handles this by marking symbols "internal" (aka static, aka > not TREE_PUBLIC, whatever) when the symbol is not visible outside the > LTO scope. This allows the optimizers to go crazy and hack away at > the symbols, but only when safe. How doe

Re: [whopr] plugin interface design

2008-06-05 Thread Ian Lance Taylor
Chris Lattner <[EMAIL PROTECTED]> writes: > On Jun 5, 2008, at 6:51 AM, Ian Lance Taylor wrote: > >> Chris Lattner <[EMAIL PROTECTED]> writes: >> >>> I don't know how closely your plans follow this model. If you think >>> this approach is reasonable, you really do need to reflect things >>> like

Re: Question regarding C++ frontend

2008-06-05 Thread Peter Collingbourne
On Sat, May 03, 2008 at 08:29:25AM -0400, Doug Gregor wrote: > INNERMOST_TEMPLATE_ARGS can be used to get at the "innermost" TREE_VEC > of template arguments for a class template specialzation such as > foo::bar. CLASSTYPE_USE_TEMPLATE != 0 tells you whether a > RECORD_TYPE is actually a template

Re: [whopr] Design/implementation alternatives for the driver and WPA

2008-06-05 Thread Chris Lattner
On Jun 5, 2008, at 6:59 AM, Ian Lance Taylor wrote: "Rafael Espindola" <[EMAIL PROTECTED]> writes: Interesting. The use of lto_codegen_add_must_preserve_symbol is kind of the opposite of what I had understood. What do you do in this case: a.o: IL file that contains a reference to "f" b.o:

Re: [whopr] plugin interface design

2008-06-05 Thread Chris Lattner
On Jun 5, 2008, at 6:51 AM, Ian Lance Taylor wrote: Chris Lattner <[EMAIL PROTECTED]> writes: I don't know how closely your plans follow this model. If you think this approach is reasonable, you really do need to reflect things like symbol versions in your IR somehow. This compiler must

Re: RFC: Extend x86-64 psABI for 256bit AVX register

2008-06-05 Thread H.J. Lu
On Thu, Jun 5, 2008 at 8:15 AM, Jan Hubicka <[EMAIL PROTECTED]> wrote: >> >> 1. Extend the register save area to put upper 128bit at the end. >> Pros: >> Aligned access. >> Save stack space if 256bit registers are used. >> Cons >> Split access. Require more split access beyond 256bi

Re: RFC: Extend x86-64 psABI for 256bit AVX register

2008-06-05 Thread H.J. Lu
On Thu, Jun 5, 2008 at 7:49 AM, Richard Guenther <[EMAIL PROTECTED]> wrote: > On Thu, Jun 5, 2008 at 4:31 PM, H.J. Lu <[EMAIL PROTECTED]> wrote: >> Hi, >> >> x86-64 psABI defines >> >> typedef struct >> { >> unsigned int gp_offset; >> unsigned int fp_offset; >> void *overflow_arg_area; >> void

Re: [whopr] Design/implementation alternatives for the driver and WPA

2008-06-05 Thread Diego Novillo
On Thu, Jun 5, 2008 at 11:09, Jan Hubicka <[EMAIL PROTECTED]> wrote: > I think one problem is that both repackaging and cherry picking as > described is very centric about application on inlining. No, that's simply the main application for the initial implementation. Any other summary-based tran

Re: RFC: Extend x86-64 psABI for 256bit AVX register

2008-06-05 Thread Jan Hubicka
> > 1. Extend the register save area to put upper 128bit at the end. > Pros: > Aligned access. > Save stack space if 256bit registers are used. > Cons > Split access. Require more split access beyond 256bit. > > 2. Extend the register save area to put full 265bit YMMs at the end.

Re: [whopr] Design/implementation alternatives for the driver and WPA

2008-06-05 Thread Jan Hubicka
Hi, I am jumping in somewhat late, as yesterday I was on meetings without internet access. (and I probably will be offline again tomorrow) I think that in basic terms we all mostly agree (we want to implement optimization scheme that does not get everything into memory, we want to parallelize the

Re: RFC: Extend x86-64 psABI for 256bit AVX register

2008-06-05 Thread Richard Guenther
On Thu, Jun 5, 2008 at 4:31 PM, H.J. Lu <[EMAIL PROTECTED]> wrote: > Hi, > > x86-64 psABI defines > > typedef struct > { > unsigned int gp_offset; > unsigned int fp_offset; > void *overflow_arg_area; > void *reg_save_area; > } va_list[1]; > > for variable argument list. "va_list" is used to acc

RFC: Extend x86-64 psABI for 256bit AVX register

2008-06-05 Thread H.J. Lu
Hi, x86-64 psABI defines typedef struct { unsigned int gp_offset; unsigned int fp_offset; void *overflow_arg_area; void *reg_save_area; } va_list[1]; for variable argument list. "va_list" is used to access variable argument list: void bar (const char *format, va_list ap) { if (va_arg

Re: [whopr] Design/implementation alternatives for the driver and WPA

2008-06-05 Thread Ian Lance Taylor
"Rafael Espindola" <[EMAIL PROTECTED]> writes: > Interesting. The use of lto_codegen_add_must_preserve_symbol is kind > of the opposite of what I had understood. What do you do in this case: > > a.o: IL file that contains a reference to "f" > b.o: IL file that has a weak def of "f" > > There is no

Re: [whopr] plugin interface design

2008-06-05 Thread Ian Lance Taylor
Chris Lattner <[EMAIL PROTECTED]> writes: > I don't know how closely your plans follow this model. If you think > this approach is reasonable, you really do need to reflect things like > symbol versions in your IR somehow. This compiler must know about > versions, and when it does, it is easy to

Re: How to build on AMD64/Debian under x86 32bits chroot?

2008-06-05 Thread Richard Guenther
On Thu, Jun 5, 2008 at 3:14 PM, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: > Hello All > > As (I imagine) many developers I have a 64 bits machine - running Debian > (Sid) Linux AMD64. > > I want to test my MELT branch on x86 (32 bits). So I set up (using > debootstrap) a x86 32 bits Debian/Le

Re: How to build on AMD64/Debian under x86 32bits chroot?

2008-06-05 Thread Andrew Haley
Basile STARYNKEVITCH wrote: > Hello All > > As (I imagine) many developers I have a 64 bits machine - running Debian > (Sid) Linux AMD64. > > I want to test my MELT branch on x86 (32 bits). So I set up (using > debootstrap) a x86 32 bits Debian/Lenny chroot-ed system (in /debian32) > which has mo

How to build on AMD64/Debian under x86 32bits chroot?

2008-06-05 Thread Basile STARYNKEVITCH
Hello All As (I imagine) many developers I have a 64 bits machine - running Debian (Sid) Linux AMD64. I want to test my MELT branch on x86 (32 bits). So I set up (using debootstrap) a x86 32 bits Debian/Lenny chroot-ed system (in /debian32) which has most of the *-dev packages installed. I

Re: [lto] Streaming out language-specific DECL/TYPEs

2008-06-05 Thread Jan Hubicka
> Jan Hubicka wrote: > > >Sure if it works, we should be lowering the types during gimplification > >so we don't need to store all this in memory... > >But C++ FE still use its local data later in stuff like thunks, but we > >will need to cgraphize them anyway. > > I agree. The only use of langu

Re: Is this a typo in setup_incoming_varargs_64?

2008-06-05 Thread Jan Hubicka
> Hi, > > setup_incoming_varargs_64 in i386.c has > > /* Compute address to jump to : > label - 5*eax + nnamed_sse_arguments*5 */ > > The comments don't match the code. Shout the comments be > > /* Compute address to jump to : > label - 4*eax + nnamed_sse_arguments

Re: [whopr] Design/implementation alternatives for the driver and WPA

2008-06-05 Thread Rafael Espindola
>> In ELF you have to think about symbol overriding. Let's say you link >> a.o b.o c.o. a.o has a reference to symbol S. b.o has a strong >> definition. c.o has a weak definition. a.o and c.o have LTO >> information, b.o does not. ELF requires that a.o call the symbol from >> b.o, not the sym

Dream of being healthier?

2008-06-05 Thread wrenchn
Bring more pleasure to your xlife! http://pdo.