Saral
ITR
The easier way to filing IT returns
Your wait for Income Tax Returns Software is over. Stop. Look no further.
Saral ITR from Relyon will help you file the Income Tax Returns. Saral ITR,
the Software to manage all ITR Forms is just released.
Available online and free to file ITR 1, 2 & 3
Paolo Bonzini wrote:
2) selection operations on vectors, kind of (v1 <= v2 ? v3 : v4). These
can be written for example like this:
cmpleps xmm1, xmm2 ; xmm1 = xmm1 <= xmm2 ? all-ones : 0
andnps xmm4, xmm1 ; xmm4 = xmm1 <= xmm2 ? 0 : xmm4
andps xmm1, xmm3 ; xmm1 = xmm1 <
Mark Mitchell wrote:
One option is for the user to use intrinsics. It's been claimed that
results in worse code. There doesn't seem any obvious reason for that,
but, if true, we should try to fix it; we don't want to penalize people
who are using the intrinsics. So, let's assume using intrinsi
Paolo Bonzini wrote:
I'm not sure that it is *so* useful for a user to have access to it,
except for specialized cases:
As there's other means, it may not be that useful but for sure it's
extremely convenient.
2) selection operations on vectors, kind of (v1 <= v2 ? v3 : v4). These
can be wri
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> 1) neg, abs and copysign operations on vectors. These we can make
> available via builtins (for - of course you don't need it); we already
> support them in many back-ends.
Here is my point of view. People using the vector extensions are
already writi
On Friday 24 August 2007, Ian Lance Taylor wrote:
> Paolo Bonzini <[EMAIL PROTECTED]> writes:
> > 1) neg, abs and copysign operations on vectors. These we can make
> > available via builtins (for - of course you don't need it); we already
> > support them in many back-ends.
>
> Here is my point of
On Aug 24, 2007, at 8:02 AM, Ian Lance Taylor wrote:
Permitting this extension continues the preexisting behaviour, and it
helps programmers and helps existing code. Who does it hurt to permit
this extension? Who does it help to forbid this extension?
Aren't builtins the designated way to ac
Chris Lattner <[EMAIL PROTECTED]> writes:
> On Aug 24, 2007, at 8:02 AM, Ian Lance Taylor wrote:
> > Permitting this extension continues the preexisting behaviour, and it
> > helps programmers and helps existing code. Who does it hurt to permit
> > this extension? Who does it help to forbid this
Paul Brook wrote:
> On Friday 24 August 2007, Ian Lance Taylor wrote:
>> Paolo Bonzini <[EMAIL PROTECTED]> writes:
>>> 1) neg, abs and copysign operations on vectors. These we can make
>>> available via builtins (for - of course you don't need it); we already
>>> support them in many back-ends.
>>
On Aug 24, 2007, at 8:37 AM, Ian Lance Taylor wrote:
Chris Lattner <[EMAIL PROTECTED]> writes:
On Aug 24, 2007, at 8:02 AM, Ian Lance Taylor wrote:
Permitting this extension continues the preexisting behaviour,
and it
helps programmers and helps existing code. Who does it hurt to
permit
On 8/24/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Let "a" and "b" be floating-point operands of type F, where F is a
> floating-point type. Let N be the number of bytes in F. Then, "a | b"
> is defined as:
Yes that makes sense, not. Since most of the time, you have a mask
and that is what
Andrew Pinski wrote:
> On 8/24/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Let "a" and "b" be floating-point operands of type F, where F is a
>> floating-point type. Let N be the number of bytes in F. Then, "a | b"
>> is defined as:
>
> Yes that makes sense, not.
I'm not following. Are y
On 24 August 2007 17:04, Andrew Pinski wrote:
> On 8/24/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Let "a" and "b" be floating-point operands of type F, where F is a
>> floating-point type. Let N be the number of bytes in F. Then, "a | b"
>> is defined as:
>
> Yes that makes sense, not. S
> > I'm partly worried about cross-platform compatibility, and what this
> > imples for other SIMD targets.
>
> Yes. Here's a proposed definition:
I agree this is the only sane definition.
I probably wasn't clear: My main concern is that if we do support this
extension the internals should be
Paul Brook wrote:
> I probably wasn't clear: My main concern is that if we do support this
> extension the internals should be implemented and documented in such a way
> that target maintainers (i.e. me) can figure out how to make it work on their
> favourite target. We should not just quietly
Brian Sidebotham wrote:
Brian Sidebotham wrote:
../../gcc/gcc/tree.c: In function "build_string":
../../gcc/gcc/tree.c:1197: internal compiler error: in
iterative_hash_expr, at tree.c:4189
Please submit a full bug report,
with preprocessed source if appropriate.
I have placed the pre-processe
If there is a reason to put in that obstacle--e.g., because we
are implementing a language standard and the language standard forbids
it--then fine. But citing a PowerPC specific standard to forbid code
appropriate for the x86 does not count as a sufficient reason in my
book.
The code I want to
Jie Zhang wrote:
On 8/10/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Are there any folks out there who have projects for Stage 1 or Stage 2
that they are having trouble getting reviewed? Any comments
re. timing for Stage 3?
I have many bfin port patches which have not been merged into
upstre
On Fri, Aug 24, 2007 at 02:34:27PM -0400, Ross Ridge wrote:
> Mark Mitchell
> >Let's assume that the recent change is what we want, i.e., that the
> >answer to (1) is "No, these operations should not be part of the vector
> >extensions because they are not valid scalar extensions."
>
> I don't
Mark Mitchell
>Let's assume that the recent change is what we want, i.e., that the
>answer to (1) is "No, these operations should not be part of the vector
>extensions because they are not valid scalar extensions."
I don't think we should assume that. If we were to we'd also have
to change vec
> Ed S Peschko writes:
Ed> which would be fine if the AIX linker works, but I'm getting segmentation
Ed> faults when compiling perl out of the box, using the gcc-4.1.0 compiler
Ed> provided.. I'm wondering if its the compiler, the linker, or both...
You have not provided information f
Snapshot gcc-4.3-20070824 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070824/
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/trunk
22 matches
Mail list logo
