If one writes a bit of code like this:
int foo( void )
{
register int x asm( "Rn" );
asm volatile ( "INSN_A %0 \n\t" : "=r" (x) );
bar();
asm volatile ( "INSN_B %0,%0 \n\t" : "=r" (x) : "0" (x) );
return x;
}
and Rn is a register not saved over function calls, then gcc does not save it
b
Please see the whole E-mail Please send a GCC for
windows. Language:Chinese or English. I'm a Chinese student,now I'm
studing C++.I want a GCC(For Windows,Chinese),but my English isn't very
good,and I can't find GCC. So,please send me a GCC,for tomorrow of th
The test fails with a link error, as 'round' and 'rint' are only C99.
Fixed thusly, tested on SPARC/Solaris 8, applied on the mainline as obvious.
2011-10-13 Eric Botcazou
* gcc.dg/builtins-67.c: Guard iround and irint with HAVE_C99_RUNTIME.
--
Eric Botcazou
Index: gcc.dg/builtins
On 10/13/2011 12:26 AM, Zoltán Kócsi wrote:
> So I don't know if it is a bug (i.e. the compiler is supposed to protect local
> reg vars) or just misleading/omitted information in the info page?
It's the documentation that could perhaps be improved.
Local register variables are not protected from
Hi
I would like to share some plans about improving the situation with
vector alignment tracking. First of all, I would like to start with a
well-known bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50716.
There are several aspects of the problem:
1) We would like to avoid the quiet segmentati
Artem Shinkarov writes:
>
> 1) Currently in C we cannot provide information that an array is
> aligned to a certain number. The problem is hidden in the fact, that
Have you considered doing it the other way round: when an optimization
needs something to be aligned, make the declaration aligned?
On Thu, Oct 13, 2011 at 4:54 PM, Andi Kleen wrote:
> Artem Shinkarov writes:
>>
>> 1) Currently in C we cannot provide information that an array is
>> aligned to a certain number. The problem is hidden in the fact, that
>
> Have you considered doing it the other way round: when an optimization
>
> Or I am missing someting?
I often see the x86 vectorizer with -mtune=generic generate a lot of
complicated code just to adjust for potential misalignment.
My thought was just if the alias oracle knows what the original
declaration is, and it's available for changes (e.g. LTO), it would be
like
On Thu, Oct 13, 2011 at 06:57:47PM +0200, Andi Kleen wrote:
> > Or I am missing someting?
>
> I often see the x86 vectorizer with -mtune=generic generate a lot of
> complicated code just to adjust for potential misalignment.
>
> My thought was just if the alias oracle knows what the original
> de
From: Richard Henderson
Date: Wed, 12 Oct 2011 17:49:19 -0700
> There's a code sample 7-1 that illustrates a 16x16 multiply:
>
> fmul8sux16 %f0, %f1, %f2
> fmul8ulx16 %f0, %f1, %f3
> fpadd16%f2, %f3, %f4
Be wary of code examples that don't even assemble (even numbered
floa
From: David Miller
Date: Thu, 13 Oct 2011 14:26:36 -0400 (EDT)
> product = src1 * src2;
>
> scaled = (product & 0x0000) >> 8;
> if (product & 0x80)
> scaled++;
In fact, all of the partitioned multiply instructions scale the result
by 8 bits with rounding towa
On 10/13/2011 11:26 AM, David Miller wrote:
> Therefore, I think this "16 x 16 multiply" operation isn't the kind
> you think it is, and it's therefore not appropriate to use this in the
> compiler for vector multiplies.
Ah, I see the magic word in the docs now: "fixed point".
I.e. class MODE_ACCU
From: Richard Henderson
Date: Wed, 12 Oct 2011 17:49:19 -0700
> The comment for fpmerge_vis is not correct.
> I believe that the operation is representable with
>
> (vec_select:V8QI
> (vec_concat:V8QI
> (match_operand:V4QI 1 ...)
> (match_operand:V4QI 2 ...)
> (parallel [
>
On 10/13/2011 12:55 PM, David Miller wrote:
> -(define_insn "_vis"
> +(define_insn ""
Missing a "3" on the end. Otherwise these look ok.
> Unfortunately, that would involve some ABI changes for the VIS
> builtins. I'm trending towards considering just changing things
> anyways since the VIS int
From: Richard Henderson
Date: Thu, 13 Oct 2011 13:06:19 -0700
> On 10/13/2011 12:55 PM, David Miller wrote:
>> -(define_insn "_vis"
>> +(define_insn ""
>
> Missing a "3" on the end. Otherwise these look ok.
Thanks for finding that.
>> Unfortunately, that would involve some ABI changes for the
> Unfortunately, that would involve some ABI changes for the VIS
> builtins. I'm trending towards considering just changing things
> anyways since the VIS intrinsics were next to unusable beforehand.
Could you elaborate? The calling conventions for vectors (like for the other
classes) shouldn't
Snapshot gcc-4.5-20111013 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20111013/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
From: Eric Botcazou
Date: Fri, 14 Oct 2011 00:41:42 +0200
>> Unfortunately, that would involve some ABI changes for the VIS
>> builtins. I'm trending towards considering just changing things
>> anyways since the VIS intrinsics were next to unusable beforehand.
>
> Could you elaborate? The call
"Iyer, Balaji V" writes:
> This email is in reference to the "default_elf_asm_named_section"
> function in the varasm.c file.
>
> This function is defined like this:
>
> void
> default_elf_asm_named_section (const char *name, unsigned int flags,
>tree decl
"花儿对我笑" <870523...@qq.com> writes:
> Please see the whole E-mail Please send a GCC
> for windows. Language:Chinese or English. I'm a Chinese student,now
> I'm studing C++.I want a GCC(For Windows,Chinese),but my English isn't very
> good,and I can't find GCC
2011/10/14 Ian Lance Taylor :
> "花儿对我笑" <870523...@qq.com> writes:
>
>> Please see the whole E-mail Please send a GCC
>> for windows. Language:Chinese or English. I'm a Chinese student,now
>> I'm studing C++.I want a GCC(For Windows,Chinese),but my English isn
> Right and as Richard said I can munge the modes during expansion of
> existing builtins when needed.
OK, but you precisely shouldn't need to do it since the type is fixed.
--
Eric Botcazou
22 matches
Mail list logo
