On 29/9/06 1:40 am, "H. J. Lu" <[EMAIL PROTECTED]> wrote:
> You are asking for impossible:
If the compiler emitted accesses via the GOT for weak symbols then there
wouldn't be a problem. The compiler doesn't know the final link address
though, so it'd have to be conservative. Perhaps it's not wor
rs6000 and Sparc ports seem to use a peephole2 to get the ldd or lfq
instructions (respectively), but it looks like there's no reason for
the register allocater to allocate registers together. The peephole2
just picks up loads to adjacent memory locations if the allocater
happens to choose adjace
Kazu Hirata wrote:
Hi Mark,
I don't believe there is a GCC 4.3 project page to merge the work that
you folks did on CALL_EXPRs and TYPE_ARG_TYPEs. Would one of you
please create a Wiki page for that?
What would you suggest me to do for missing bits? Specifically, most
backends with the e
Hi Mark,
I don't believe there is a GCC 4.3 project page to merge the work that
you folks did on CALL_EXPRs and TYPE_ARG_TYPEs. Would one of you please
create a Wiki page for that?
What would you suggest me to do for missing bits? Specifically, most backends
with the exception of x86 are
Hans-Peter Nilsson wrote:
I think that front ends should be allowed to omits zeros for
initializers for variables with static storage duration, but not other
initializers, independent of what C99 says.
I think we "read past each other". I was just countering what
(I read as) your statement th
> The only trouble you'll probably run into is with fields whose offset
> from the start of a structure is variable.
Exactly. That's the reason it's defined the way it is. There is no way
to synthesize that field from any other in the FIELD_DECL in the most
general case: it is unique informati
On Thu, 28 Sep 2006, Mark Mitchell wrote:
> Hans-Peter Nilsson wrote:
> > On Mon, 18 Sep 2006, Mark Mitchell wrote:
> >
> >> Andrew Pinski wrote:
> >>> The documention on VECTOR_CST is not clear if we can have missing
> >>> elements in that the remaining elements are zero. Right we produce such
>
Jan Hubicka wrote:
I intended to write the overview in a way to express that some work will
be needed.
Thank you for the detailed explanation. I think your plans all sound
reasonable. I would definitely encourage you to start preparing patches
and submitting them for review -- and hounding
Hans-Peter Nilsson wrote:
On Mon, 18 Sep 2006, Mark Mitchell wrote:
Andrew Pinski wrote:
The documention on VECTOR_CST is not clear if we can have missing
elements in that the remaining elements are zero. Right we produce such
VECTOR_CST for things like:
#define vector __attribute__((vector_s
On Thu, Sep 28, 2006 at 03:33:05PM +0100, Keir Fraser wrote:
>
> > Compile and link the attached C program as follows. I used gcc-4.1.1 and
> > binutils-2.17, but gcc >= 4.0.0 and binutils >= 2.16 probably suffice.
> >
> > # gcc -fpic -o test.o -c test.c
> > # ld -Ttext 1 -o test test.o
Sandra Loosemore wrote:
Mark Mitchell wrote:
I don't believe there is a GCC 4.3 project page to merge the work that
you folks did on CALL_EXPRs and TYPE_ARG_TYPEs. Would one of you
please create a Wiki page for that?
There are already a bunch of notes about this on the LTO page:
http://gc
Mark Mitchell wrote:
I don't believe there is a GCC 4.3 project page to merge the work that
you folks did on CALL_EXPRs and TYPE_ARG_TYPEs. Would one of you please
create a Wiki page for that?
There are already a bunch of notes about this on the LTO page:
http://gcc.gnu.org/wiki/LinkTimeOp
Kazu, Sandra --
I don't believe there is a GCC 4.3 project page to merge the work that
you folks did on CALL_EXPRs and TYPE_ARG_TYPEs. Would one of you please
create a Wiki page for that?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Razya Ladelsky wrote:
Except for new optimizations, IPCP (currently on mainline) should also be
transformed to SSA.
IPCP in SSA code exists on IPA branch, and will be submitted to GCC4.3
after IPA branch
is committed and some testsuite regressions failing with
IPCP+versioning+inlining are fix
Snapshot gcc-4.0-20060928 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060928/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Chris Lattner wrote:
Also, because of GCC's internal representation of integers, you have
to be careful that you have enough bits; for example, you need 72 bits
to represent things in a 64-bit address space.
Actually, just 67, right? Does GCC support structures whose size is
greater than 2^
Mark Mitchell wrote:
Are
you going through the stor_layout.c:place_field routines when creating
structure types? If so, I wouldn't; here, you know where stuff is
supposed to go, so I would just put it there, and set DECL_FIELD_OFFSET,
etc., accordingly.
No, I'm not using the fancy stor_lay
On Sep 28, 2006, at 1:58 PM, Mark Mitchell wrote:
Chris Lattner wrote:
An alternative design, which would save a field, is just to keep
the offset of a field, in bits, from the start of the structure.
Yes, that would also work. But, in many cases, you need the byte
offset, so there's a
Chris Lattner wrote:
An alternative design, which would save a field, is just to keep the
offset of a field, in bits, from the start of the structure.
Yes, that would also work. But, in many cases, you need the byte
offset, so there's a time/space tradeoff. Also, because of GCC's
internal
On Thu, 2006-09-28 at 13:26 +0200, Jan Beulich wrote:
> While I'm not certain whether gcc is able to split one function's code
> between different sections
Yes. See the -freorder-blocks-and-partition option, which can move code
to hot/cold sections.
> However, when frame unwind information is g
On Sep 28, 2006, at 1:43 PM, Mark Mitchell wrote:
Sandra Loosemore wrote:
I've been having a heck of a time figuring out how to translate
the offsets for struct fields from the DWARF encoding back to
GCC's internal encoding for the LTO project.
Yes, that's a nasty bit.
I think the DECL_FI
Sandra Loosemore wrote:
I've been having a heck of a time figuring out how to translate the
offsets for struct fields from the DWARF encoding back to GCC's internal
encoding for the LTO project.
Yes, that's a nasty bit.
I think the DECL_FIELD_OFFSET/DECL_FIELD_BIT_OFFSET stuff is, quite
sim
On Sep 28, 2006, at 4:26 AM, Jan Beulich wrote:
While I'm not certain whether gcc is able to split one function's
code between different sections
Kinda, sorta... Hot-cold partitioning (-freorder-blocks-and-
partition) does this. If one exposed a FE language construct to so
tag code, then
On Thu, Sep 28, 2006 at 12:01:01PM -0700, H. J. Lu wrote:
> On Thu, Sep 28, 2006 at 01:34:31PM -0500, Menezes, Evandro wrote:
> > HJ,
> >
> > I think that it's great that all the de facto changes adopted for i386
> > would be put in an extension or appendix to its psABI.
> >
> > However, I lean
On 28 September 2006 20:01, H. J. Lu wrote:
> On Thu, Sep 28, 2006 at 01:34:31PM -0500, Menezes, Evandro wrote:
>> HJ,
>>
>> I think that it's great that all the de facto changes adopted for i386
>> would be put in an extension or appendix to its psABI.
>>
>> However, I lean towards an open dis
On Thu, Sep 28, 2006 at 01:34:31PM -0500, Menezes, Evandro wrote:
> HJ,
>
> I think that it's great that all the de facto changes adopted for i386 would
> be put in an extension or appendix to its psABI.
>
> However, I lean towards an open discussion list. If necessary, I'd be glad
> to inves
Tzi-cker Chiueh wrote:
We have considered the bound instruction in the CASH project. But
we found that bound instruction is slower than the six normal
instructions it is meant to replace for range checking. For example, the
bound instruction on a 1.1 GHz PIII machine requires 7-8 clock cycles
whi
HJ,
I think that it's great that all the de facto changes adopted for i386 would be
put in an extension or appendix to its psABI.
However, I lean towards an open discussion list. If necessary, I'd be glad to
investigate hosting this list at http://www.x86-64.org, even though this
discussion
On Sep 27, 2006, at 7:04 PM, Sandra Loosemore wrote:
I've been having a heck of a time figuring out how to translate the
offsets for struct fields from the DWARF encoding back to GCC's
internal encoding for the LTO project. I've got a handle on the
DWARF encoding and how to do the necessa
On Thu, 28 Sep 2006, Joe Buck wrote:
> Is this supposed to be for gcc/binutils, or is it supposed to be
> processor-independent? And why a closed list? Please don't go
> down the path of re-creating what we rebelled against when we started
> egcs. Also, if there's a need to crosspost a message
On Thu, Sep 28, 2006 at 09:54:10AM -0700, Joe Buck wrote:
> On Thu, Sep 28, 2006 at 07:11:25AM -0700, H. J. Lu wrote:
> > On Thu, Sep 28, 2006 at 02:53:30PM +0100, Christoph Hellwig wrote:
> > > On Wed, Sep 27, 2006 at 03:32:45PM -0700, H. J. Lu wrote:
> > > > I created a Google group to discuss ge
On Thu, Sep 28, 2006 at 12:52:18PM -0400, Tzi-cker Chiueh wrote:
> We have considered the bound instruction in the CASH project. But
> we found that bound instruction is slower than the six normal
> instructions it is meant to replace for range checking. For example, the
> bound instruction on a 1.
On Thu, 28 Sep 2006, Tzi-cker Chiueh wrote:
We have considered the bound instruction in the CASH project. But
we found that bound instruction is slower than the six normal
instructions it is meant to replace for range checking. For example, the
bound instruction on a 1.1 GHz PIII machine require
On Thu, Sep 28, 2006 at 07:11:25AM -0700, H. J. Lu wrote:
> On Thu, Sep 28, 2006 at 02:53:30PM +0100, Christoph Hellwig wrote:
> > On Wed, Sep 27, 2006 at 03:32:45PM -0700, H. J. Lu wrote:
> > > I created a Google group to discuss generic ABI:
> > >
> > > http://groups.google.com/group/generic-abi
We have considered the bound instruction in the CASH project. But
we found that bound instruction is slower than the six normal
instructions it is meant to replace for range checking. For example, the
bound instruction on a 1.1 GHz PIII machine requires 7-8 clock cycles
while the 6 equivalent inst
You write you needs 6 assembly instructions to check a pointer on x86,
I am using the "bound" ia32 instruction (1 byte opcode 0x62, invalid in ia64)
to check the stack pointer for few years now in Gujin (http://gujin.org)
without
problem.
I am doing this kind of thing to guard against stack
I looked at the splay tree code in revision 106584.
It doesn't appear to actually be doing a top down
splay.
It is performing a top down partition of the tree but
without the splay step. This should cause some cases
to perform quite badly.
I'm pretty sure my original patch does the top down
spl
> Compile and link the attached C program as follows. I used gcc-4.1.1 and
> binutils-2.17, but gcc >= 4.0.0 and binutils >= 2.16 probably suffice.
>
> # gcc -fpic -o test.o -c test.c
> # ld -Ttext 1 -o test test.o
>
> Disassembly of the result trivially shows that the address of weak
>>> "H. J. Lu" <[EMAIL PROTECTED]> 28.09.06 15:24 >>>
>On Thu, Sep 28, 2006 at 10:45:38AM +0100, Jan Beulich wrote:
>>
>> 2) Why does the linker silently resolve the (32-bit PC-relative)
>> relocation targeting an undefined weak symbol, yielding at
>> run-time a non-zero address? While I can see t
On 28/9/06 14:24, "H. J. Lu" <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 28, 2006 at 10:45:38AM +0100, Jan Beulich wrote:
>>
>> 2) Why does the linker silently resolve the (32-bit PC-relative)
>> relocation targeting an undefined weak symbol, yielding at
>> run-time a non-zero address? While I can s
Andrew Pinski wrote on 09/28/06 10:11:
> On Thu, 2006-09-28 at 10:09 -0400, Diego Novillo wrote:
>> Some of the labels in TV_* timers are fairly long and mess up the column
>> display. Would it be a problem for anyone if I changed them during the
>> next stage1?
>
> Why not instead increase the c
On Thu, Sep 28, 2006 at 02:53:30PM +0100, Christoph Hellwig wrote:
> On Wed, Sep 27, 2006 at 03:32:45PM -0700, H. J. Lu wrote:
> > I created a Google group to discuss generic ABI:
> >
> > http://groups.google.com/group/generic-abi
> >
> > It is by membership only. Let me know if you are intereste
On Thu, 2006-09-28 at 10:09 -0400, Diego Novillo wrote:
> Some of the labels in TV_* timers are fairly long and mess up the column
> display. Would it be a problem for anyone if I changed them during the
> next stage1?
Why not instead increase the column size?
-- Pinski
Some of the labels in TV_* timers are fairly long and mess up the column
display. Would it be a problem for anyone if I changed them during the
next stage1?
It's only a cosmetic change, but I can see it affecting people's scripts.
Thanks.
On Wed, Sep 27, 2006 at 03:32:45PM -0700, H. J. Lu wrote:
> I created a Google group to discuss generic ABI:
>
> http://groups.google.com/group/generic-abi
>
> It is by membership only. Let me know if you are interested.
What's this supposed to be? Reinventing the doomed iBCS2?
On Thu, Sep 28, 2006 at 10:45:38AM +0100, Jan Beulich wrote:
>
> 2) Why does the linker silently resolve the (32-bit PC-relative)
> relocation targeting an undefined weak symbol, yielding at
> run-time a non-zero address? While I can see the point of
Do you have a testcase? I can't reproduce it.
On Thu, Sep 28, 2006 at 01:26:00PM +0200, Jan Beulich wrote:
> To cover all cases, it would basically appear to be necessary to
> add a referral op to the set of DW_CFA_* ops, which would
> indicate that the frame state at the given point is to be derived
> by assuming the location counter would in
Diego Novillo wrote:
Roberto COSTA wrote on 09/28/06 05:51:
If time allows me, I'd like to try to see what happens if COND_EXPRs are
kept throughout the GIMPLE passes (I confess I'm curious). Logically, I
see them as richer constructs (they carry more information than the
equivalent control-
Roberto COSTA wrote on 09/28/06 05:51:
> If time allows me, I'd like to try to see what happens if COND_EXPRs are
> kept throughout the GIMPLE passes (I confess I'm curious). Logically, I
> see them as richer constructs (they carry more information than the
> equivalent control-flow code), like
>On Sep 27, 2006, at 11:58 AM, Come Lonfils wrote:
>> I'm beginning a end study thesis on "mix" c++ end objective-c in gcc.
>> I know there is already objective-c++ but I need all information I
>> can have on the subject. What is already done and what is not (and
>> why)?
>
>Objective-C++ is a
Hello,
> Sebastian Pop <[EMAIL PROTECTED]> wrote on 26/09/2006 21:24:18:
>
> > It is probably better to include the loop indexes in the example, and
> > modify the syntax of the scev for making it more explicit, like:
> >
> > @smallexample
> > for1 i
> > for2 j
> > *((int
While I'm not certain whether gcc is able to split one function's code
between different sections (if for nothing else, this might help reduce
TLB pressure by moving code unlikely to be executed not just out of
the main function body), by way of inline assembly the Linux kernel
certainly does in ma
On 9/28/06, Roberto COSTA <[EMAIL PROTECTED]> wrote:
I understand there may be additional occasions (currently unexploited)
to generated COND_EXPRs, but why precisely do you expect unlowered
COND_EXPRs be potentially harmful?
They inhibit some control flow optimizations such as jump threading.
"Erich Plondke" <[EMAIL PROTECTED]> wrote on 27/09/2006 18:17:55:
thanks for the detailed explanation,
> Indeed, in your paper (grin) "Multi-platform Auto-vectorization" you
>
> define the functionality of realign load in terms of mis - the
> misalignment
> of the address (i.e., a
Paolo Bonzini wrote:
Yes. This is also true for a few other expressions. IIRC, the
gimplifier expands MAX_EXPR into control flow, even though it is legal
gimple.
In fact it did this, but later it was removed from the gimplifier
because it generated worse code.
The usual reason for this
Jack Twilley wrote:
Kai Ruottu wrote:
Jack Twilley wrote:
I am trying to build gcc on a FreeBSD 6.1-STABLE system. If there's
more information I can give you, please ask.
What was the GCC version tried? The new gcc-4.1.1 seems to require
the '--disable-shared'
for instance with ARM, other
In building Xen we observed a build problem when using binutils 2.15
that wasn't visible for those of us using newer binutils versions.
However, I believe that we should have seen this in all cases.
Xen gets compiled with -fPIC, and we recently added a global visibility
pragma to avoid the cost of
Sebastian Pop <[EMAIL PROTECTED]> wrote on 26/09/2006 21:24:18:
> It is probably better to include the loop indexes in the example, and
> modify the syntax of the scev for making it more explicit, like:
>
> @smallexample
> for1 i
> for2 j
> *((int *)p + i + j) = a[i][j];
Yes. This is also true for a few other expressions. IIRC, the
gimplifier expands MAX_EXPR into control flow, even though it is legal
gimple.
In fact it did this, but later it was removed from the gimplifier
because it generated worse code.
The usual reason for this type of thing is that
59 matches
Mail list logo
