On 7/13/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
Yes, but IIRC that was only for addressable things, not for registers.
Changing DECL_COMPLEX_GIMPLE_REG_P to DECL_GIMPLE_REG_P
and adding support for it for vector types has fixed this problem. In
fact now I can get vec_extract and vec_set (
PJ has posted a news pick on Groklaw about a new patent which, afar as I can
tell, claims the algorithm that Tege has contributed to expmed.c:expand_divmod
in 1994 (r7598)
http://www.freshpatents.com/Method-and-apparatus-for-efficient-software-based-integer-division-dt20060504ptan20060095494.php
On Thu, Jul 13, 2006 at 09:41:45PM -0300, Rafael Espíndola wrote:
> The attached patch moves the basic installation of the compiler
> drivers from gcc/*/Make-lang.in to gcc/Makefile.in. The Make-lang.in
> has only to inform the driver's name.
>
> Additional setup like setting the c++ -> g++ links
On Jul 14, 2006, at 9:41 AM, Rafael Espíndola wrote:
The attached patch moves the basic installation of the compiler
drivers from gcc/*/Make-lang.in to gcc/Makefile.in. The Make-lang.in
has only to inform the driver's name.
Additional setup like setting the c++ -> g++ links remains in the
Ma
The attached patch moves the basic installation of the compiler
drivers from gcc/*/Make-lang.in to gcc/Makefile.in. The Make-lang.in
has only to inform the driver's name.
Additional setup like setting the c++ -> g++ links remains in the Make-lang.in
Ok for trunk when stage1 starts?
:ADDPATCH bu
caro lettore
Dopo l'esito dei vincitori dei mondiali di calcio germania 2006
volete sapere chi sono i campioni mondiali per stragi?
se ti interessa visita il sito: http://www.elcicala.com
il tuo indirizzo e stato preso da elenchi pubblici e s
Snapshot gcc-4.0-20060713 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060713/
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
Seongbae Park wrote:
The above code looks incorrect, for various reasons,
not the least of which is that you're assuming CIE/FDE are fixed-length.
This is a trivial thing I will add later.
There are various factors that affect FDE/CIE
depending on PIC/non-PIC, C or C++, 32bit/64bit, etc -
s
On Thu, Jul 13, 2006 at 11:21:04AM -0700, Seongbae Park wrote:
> The above code looks incorrect, for various reasons,
> not the least of which is that you're assuming CIE/FDE are fixed-length.
> There are various factors that affect FDE/CIE
> depending on PIC/non-PIC, C or C++, 32bit/64bit, etc -
>
On 7/13/06, jacob navia <[EMAIL PROTECTED]> wrote:
Daniel Jacobowitz wrote:
>On Thu, Jul 13, 2006 at 05:06:25PM +0200, jacob navia wrote:
>
>
>>>So, what happens when _Unwind_Find_registered_FDE is called? Does it
>>>find the EH data you have registered?
>>>
>>>
>>>
>>>
>>>
>>Yes but then it st
On Jul 13, 2006, at 8:48 AM, jacob navia wrote:
1) I generate exactly the same code now as gcc:
You don't want to generate exactly the same code as gcc, unless it is
exactly the same case; you want to generate the correct code.
Divide and concur.
Do simple things work? For example, do:
r
my understanding of the x86_64 ABI is that the following structure
should be passed in registers:
struct data {
unsigned int x;
unsigned int y;
unsigned long z;
};
but when I compile:
#include
struct data {
unsigned int x : 32;
unsigned int y : 32;
"Rodney M. Bates" <[EMAIL PROTECTED]> writes:
> When executing in foo, the frame pointer will point to a fixed spot in the
> activation record of foo. On i386, the FP is %ebx and it points to the
> dynamic link field. From there, loc is at displacement -4. Code in the
> body of foo will referen
I wrote [for two classes S with visibility == hidden ]
> | > | We can have two distinct
> | > | classes named S, and no one can tell. Each bit of code will see one
> | > | definition of S.
Jason Merrill <[EMAIL PROTECTED]> writes:
> | I think that Joe's point is that IF you have two classes nam
I found gcc 4.1.1 (and 4.2) can not optimize this simple code well.
void foo(int *a)
{
int i;
for (i = 0; i < 100; i++)
a[0] += a[1];
}
If I compile this code with -O2, instructions to load from a[1] and
store to a[0] are both inside a loop.
Is this a know issue?
Paolo Bonzini wrote on 07/13/06 11:55:
> But if you say this is dangerous, yes, I agree that the best thing to do
> is to treat VECTOR_TYPEs like COMPLEX_TYPEs and use
> DECL_COMPLEX_GIMPLE_REG_P. Does COMPOSITE_TYPE_P, and
> DECL_COMPOSITE_GIMPLE_REG_P sound good as names?
>
Yes, I think that s
Diego Novillo wrote:
Andrew Pinski wrote on 07/13/06 08:37:
#define vector __attribute__((vector_size(16) ))
vector float f(vector float t, vector t1)
{
return t/t1;
}
-- Pinski
That definitely seems wrong. We shouldn't be considering vector types
to be GIMPLE register types if we are go
jacob navia writes:
> Andrew Haley wrote:
>
> >I suspect that the gcc unwinder is relying on __dl_iterate_phdr to
> >scan the loaded libraries and isn't using the region that you have
> >registered.
> >
> >But this is odd, becasue when I look at _Unwind_Find_FDE in
> >unwind-dw2-fde-glibc.
Daniel Jacobowitz wrote:
On Thu, Jul 13, 2006 at 05:06:25PM +0200, jacob navia wrote:
So, what happens when _Unwind_Find_registered_FDE is called? Does it
find the EH data you have registered?
Yes but then it stops there instead of going upwards and finding the catch!
It is as my
Mike Stump wrote:
On Jul 9, 2006, at 10:52 PM, Vladimir 'Yu' Stepanov wrote:
I would like to offer one expansion for C/C++.
Did you just reinvent downcasting in C++? If so, C++ already has that
feature!? As for C, C, I'd claim C already has that feature[1], you
merely have to put in a #def
Manuel López-Ibáñez wrote:
> Hi Daniel,
>
> The Wcoercion porject page is currently up at
> http://gcc.gnu.org/wiki/Wcoercion and it is vandalised. Yet, I cannot
> revert or change it. Could you do something about this please? Taking
> it down for a few days would be better than current situation.
On Thu, Jul 13, 2006 at 05:10:19PM +0200, jacob navia wrote:
> Mmmm "report this problem to the LSB".
>
> Maybe you have someone there I could reach?
> An email address?
>
> There is no "feedback" or "bugs" button in their page.
Try http://www.freestandards.org/en/LSB -> lsb-discuss mailing list
On Thu, Jul 13, 2006 at 05:06:25PM +0200, jacob navia wrote:
> >So, what happens when _Unwind_Find_registered_FDE is called? Does it
> >find the EH data you have registered?
> >
> >
> >
> Yes but then it stops there instead of going upwards and finding the catch!
> It is as my insertion left the
Daniel Jacobowitz wrote:
On Thu, Jul 13, 2006 at 04:46:19PM +0200, jacob navia wrote:
In the Linux Standard specs in
http://www.freestandards.org/spec/booksets/LSB-Core-generic/LSB-Core-generic/ehframechpt.html
it is written in the specification of the FDE (Frame Description Entry)
the foll
http://earth.google.com/download-earth.html
On 7/13/06, DebianTux23 <[EMAIL PROTECTED]> wrote:
http://earth.google.com/download-earth.html
On 07 Jul 2006 10:11:01 -0700, Ian Lance Taylor < [EMAIL PROTECTED]> wrote:
> "Rodney M. Bates" < [EMAIL PROTECTED]> writes:
>
> > The following example
Andrew Haley wrote:
The way you do not reply to mails replying to your questions doesn't
encourage people to help you. Please try harder to answer.
I did answer last time but directly to the poster that replied, and
forgot to CC the list.
Excuse me for that.
I suspect that the gcc unwin
jacob navia writes:
> Hi
>
> Context:
>
> I am writing a JIT and need to register the frame information about
> the generated program within the context of a larger C++ program
> compiled with g++. Stack layout is like this:
>
> catch established by C++
> JITTED code ge
On Thu, Jul 13, 2006 at 04:46:19PM +0200, jacob navia wrote:
> In the Linux Standard specs in
> http://www.freestandards.org/spec/booksets/LSB-Core-generic/LSB-Core-generic/ehframechpt.html
> it is written in the specification of the FDE (Frame Description Entry)
> the following:
I suggest you re
Hi
Context:
I am writing a JIT and need to register the frame information about
the generated program within the context of a larger C++ program
compiled with g++. Stack layout is like this:
catch established by C++
JITTED code generated dynamically
JITTED code
JITTE
Hi
Bug in the specs or bug in the code?
I do not know, but one of this is wrong:
In the Linux Standard specs in
http://www.freestandards.org/spec/booksets/LSB-Core-generic/LSB-Core-generic/ehframechpt.html
it is written in the specification of the FDE (Frame Description Entry)
the following:
On Jul 13, 2006, at 10:06 PM, Diego Novillo wrote:
That definitely seems wrong. We shouldn't be considering vector types
to be GIMPLE register types if we are going to be chunking them out
with
BIT_FIELD_REF. The verifier ought to check that.
I am thinking about cleaning this up by using
Andrew Pinski wrote on 07/13/06 08:37:
> #define vector __attribute__((vector_size(16) ))
>
> vector float f(vector float t, vector t1)
> {
> return t/t1;
> }
>
> -- Pinski
>
That definitely seems wrong. We shouldn't be considering vector types
to be GIMPLE register types if we are going to b
On Jul 13, 2006, at 9:32 PM, Diego Novillo wrote:
Got a test case where we produce BIT_FIELD_REF in
either
side of the assignment?
Well a simple one like for the RHS on PPC-linux-gnu with -maltivec
(and -O1):
#define vector __attribute__((vector_size(16) ))
vector float f(vector float
Andrew Pinski wrote on 07/13/06 03:27:
> I don't see anything in either tree.def or tree-ssa.texi which would
> cause the orginal non-gimplified tree to be invalid. So my question
> is should we document that BIT_FIELD_REF on the lhs for a SSA_NAME
> invalid gimple?
>
SSA_NAMEs should not be val
Jason Merrill <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| >> Joe Buck wrote:
| > Now, this being a conscious decision for ODR violation, it would
| > probably need to be documented because then we may have
| >typeinfo1 != typeinfo2
| > and yet
| > !typeinfo1.before(typeinfo2)
Ian Lance Taylor wrote:
"Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> writes:
Current syntax C/C++:
load_ptr = typeof(load_ptr)(((char *)init_ptr) - \
offsetof(typeof(init_ptr), field);
The offered syntax:
&load_ptr->field = init_ptr;
Interesting idea, but C/C++ p
Hi Daniel,
The Wcoercion porject page is currently up at
http://gcc.gnu.org/wiki/Wcoercion and it is vandalised. Yet, I cannot
revert or change it. Could you do something about this please? Taking
it down for a few days would be better than current situation.
Cheers,
Manuel.
On 12/07/06, Danie
PS http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02150.html added the
ability for having BIT_FIELD_REF on the LHS.
Yes, but IIRC that was only for addressable things, not for registers.
As Steven said, handling it would be a mess like it was for RTL SSA.
So, you Do Not Want this for registers
On 7/13/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 7/13/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> So I started to try to fold *(type*)(&vector_type_var) into
> BIT_FIELD_REF but I ran into a bug where the SSA messes
> itself up.
> This works for the right hand side just fine as
> BI
On 7/13/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
So I started to try to fold *(type*)(&vector_type_var) into
BIT_FIELD_REF but I ran into a bug where the SSA messes
itself up.
This works for the right hand side just fine as
BIT_FIELD_REF is easyly valid gimple. When the
BIT_FIELD_REF is on
So I started to try to fold *(type*)(&vector_type_var) into
BIT_FIELD_REF but I ran into a bug where the SSA messes
itself up.
This works for the right hand side just fine as
BIT_FIELD_REF is easyly valid gimple. When the
BIT_FIELD_REF is on the left hand side, it turns out that we produce:
BIT_
41 matches
Mail list logo
