From: "Joseph S. Myers" <[EMAIL PROTECTED]>
on "GNUC". Sometimes the solaris headers try to be gcc-aware. Is there
a
GNUC appearing in solaris11's /usr/include/iso/math_c99.h header? And
that
begs the question, why do these fix hacks have this GNUC bypass in the
first
place?
Because I gav
[EMAIL PROTECTED] stack-2]$ cat x.i
float essef(float) __attribute__((sseregparm));
extern float f;
void test(void)
{
f = essef(f);
}
[EMAIL PROTECTED] stack-2]$ /usr/gcc-4.3/bin/gcc -m32 -mno-sse -S x.i
x.i: In function 'test':
x.i:5: error: Calling 'float(float)' with attribute sseregparm witho
Snapshot gcc-4.1-20080204 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080204/
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, 4 Feb 2008, Kaveh R. Ghazi wrote:
> on "GNUC". Sometimes the solaris headers try to be gcc-aware. Is there a
> GNUC appearing in solaris11's /usr/include/iso/math_c99.h header? And that
> begs the question, why do these fix hacks have this GNUC bypass in the first
> place?
Because I ga
From: "Andreas Tobler" <[EMAIL PROTECTED]>
Hi Kaveh,
[...]
Hm, there is no iso/math_c99.h and I guess the reason is here:
From the /usr/include/iso/math_c99.h
#pragma ident "@(#)math_c99.h 1.1207/01/21 SMI"
From the fixincl.x:
tSCC zSolaris_Math_1Select0[] =
"@\\(#\\)math_c99.h[ \t]
On 04/02/2008, Christian Joensson <[EMAIL PROTECTED]> wrote:
> > >
> > > Thanks for the logs, I don't have any way to test on that platform
> > > unfortunately, but it seems that the symlinks for the new shared_ptr
> > > headers are missing. I think that would happen if you hadn't done a
> > > cle
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> > To invoke this instruction from the source level, a compiler builtin
> > is provided.
> > Since C syntax doesn't provide functions with two results, this builtin
> > refers
> > to them via pointers:__super_ld32( int* x, int *y, int *a)
>
> I did some
Hi Kaveh,
Kaveh R. GHAZI wrote:
I've never had access to solaris 11, and my earlier access to solaris 10
(where these tests worked) is gone, would you please tell me why these
tests fail?
Which of the if clauses in c99-math.h is aborting and which of the
solaris_math_* fixincludes are successf
We have the need to generate code that initializes
certain variables and runtime-related values with
expressions that can't be evaluated statically
at compile-time. One method to do this, would be
to create an __attribute__ ((constructor)) function
that contains statements which initialize the
val
Hi guys,
I'm noticing that the c99-math tests are getting execute failures on
solaris2.11 for gcc-4.2.3 amd mainline. (I don't know about 4.1.x.).
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00197.html
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg01460.html
I've never had access to sol
> On Mon, Feb 04, 2008 at 12:24:33PM +0100, Jan Hubicka wrote:
> > >
> > > -malign-double is (was?) indeed a performance improvement for
> > > numerical applications on 32bits. But DImode is still not 8 bytes aligned
> > > there (which makes a next-gen 32bit ABI for 64bit x86 difficult there,
> >
On 03 February 2008 23:43, Ben Elliston wrote:
>> That decimal number is the index number of the post in the list archive.
>> You can get the mailer daemon to re-send you a copy of the original post by
>> sending a blank email to "gcc-get.DECIMALNUMBER" at gcc dot gnu dot
>> org.
>
> Will the m
On Mon, Feb 04, 2008 at 12:24:33PM +0100, Jan Hubicka wrote:
> >
> > -malign-double is (was?) indeed a performance improvement for
> > numerical applications on 32bits. But DImode is still not 8 bytes aligned
> > there (which makes a next-gen 32bit ABI for 64bit x86 difficult there,
> > if you wa
Following the old discussions at
http://gcc.gnu.org/ml/gcc/2007-04/msg00096.html
and http://gcc.gnu.org/ml/gcc/2007-04/msg00096.html
I'd like to get the ball rolling and start implementing a
unified flattened memory access operation for 4.4. Following
my earlier proposal and keeping in mind
2008/1/28, Christian Joensson <[EMAIL PROTECTED]>:
> 2008/1/26, Jonathan Wakely <[EMAIL PROTECTED]>:
> > On 22/01/2008, Christian Joensson wrote:
> > > 2008/1/21, Jonathan Wakely
> > > > My first guess would be that you've somehow got the C++0x and TR1
> > > > versions of boost_sp_shared_count.h mi
To invoke this instruction from the source level, a compiler builtin
is provided.
Since C syntax doesn't provide functions with two results, this builtin refers
to them via pointers:__super_ld32( int* x, int *y, int *a)
I did something similar in a private port by folding the builtin to
lon
>
> -malign-double is (was?) indeed a performance improvement for
> numerical applications on 32bits. But DImode is still not 8 bytes aligned
> there (which makes a next-gen 32bit ABI for 64bit x86 difficult there,
> if you want to retain DImode/DFmode 8 byte alignment and re-use the
> kernel 32b
On Feb 4, 2008 12:06 PM, Jan Hubicka <[EMAIL PROTECTED]> wrote:
>
> > On Feb 4, 2008 4:11 AM, H.J. Lu <[EMAIL PROTECTED]> wrote:
> > > DImode is aligned at 8 byte in i386. Since 32bit doesn't have
> > > 64bit register, can we align DImode at 4byte instead of 8
> > > for i386? It shouldn't have any
> On Feb 4, 2008 4:11 AM, H.J. Lu <[EMAIL PROTECTED]> wrote:
> > DImode is aligned at 8 byte in i386. Since 32bit doesn't have
> > 64bit register, can we align DImode at 4byte instead of 8
> > for i386? It shouldn't have any negative impact on performance.
>
> I don't think DImode is aligned at 8
Hi,
I am implementing a gcc backend for a target architecture which
contains assembly isntructions writing two result registers.
I have a difficulty implementing builtins for such instructions efficiently.
For example, the "super-load" instruction has a formsuper_ld32 rA
-> rX, rY.
This op
On Feb 4, 2008 4:11 AM, H.J. Lu <[EMAIL PROTECTED]> wrote:
> DImode is aligned at 8 byte in i386. Since 32bit doesn't have
> 64bit register, can we align DImode at 4byte instead of 8
> for i386? It shouldn't have any negative impact on performance.
I don't think DImode is aligned at 8 bytes on i38
21 matches
Mail list logo
