> From: Denis Chertykov <[EMAIL PROTECTED]>
>> - possibly something like: ?
>>
>> (define_insn "*addhi3"
>> [(set (match_operand:HI 0 ...)
>>(plus:HI (match_operand:HI 1 ...)
>> (match_operand:HI 2 ...)))
>> (set (reg ZCMP_FLAGS)
>>(compare:HI (plus:HI (m
Hi!
For
typedef float v4sf __attribute__((vector_size(16)));
void foo(v4sf *a, v4sf *b, v4sf *c)
{
*a = *b + *c;
}
we no longer (since 4.0) synthesize v2sf (aka sse) operations
for f.i. -march=athlon (not that we were too successful at this
in 3.4 - we generated horrible code instead).
Hi!
On mainline we now use loop versioning and peeling for alignment
for the following loop (-march=pentium4):
void foo3(float * __restrict__ a, float * __restrict__ b,
float * __restrict__ c)
{
int i;
for (i=0; i<4; ++i)
a[i] = b[i] + c[i];
}
which resu
On Mon, 21 Mar 2005 13:45:19 +0100 (CET), Richard Guenther
<[EMAIL PROTECTED]> wrote:
> Hi!
>
> On mainline we now use loop versioning and peeling for alignment
> for the following loop (-march=pentium4):
>
> void foo3(float * __restrict__ a, float * __restrict__ b,
> float * __restrict
Hi!
I'd like to specify (for vectorization) the alignment of the
target of a pointer. I.e. I have a vector of floats that I
know is suitable aligned and that get's passed to a function
like
typedef afloatp;
void foo(afloatp __restrict__ a, afloatp __restrict__ b,
afloatp __restric
On Mon, 21 Mar 2005, Richard Guenther wrote:
> I'd like to specify (for vectorization) the alignment of the
> target of a pointer. I.e. I have a vector of floats that I
> know is suitable aligned and that get's passed to a function
> like
>
> typedef afloatp;
>
> void foo(afloatp __restrict_
> Hi!
>
> On mainline we now use loop versioning and peeling for alignment
> for the following loop (-march=pentium4):
>
we don't yet use loop-versioning in the vectorizer in mainline (we do in
autovect). we do apply peeling.
> void foo3(float * __restrict__ a, float * __restrict__ b,
>
> On Mon, 21 Mar 2005 13:45:19 +0100 (CET), Richard Guenther
> <[EMAIL PROTECTED]> wrote:
> ...
>
> Uh, and with -funroll-loops we seem to be lost completely, as we
> produce peeling/loops for a eight times four rolling loop! Where is
> the information about the loop counter gone??
>
the thin
On Mon, 21 Mar 2005, Dorit Naishlos wrote:
>
>
>
>
> > On Mon, 21 Mar 2005 13:45:19 +0100 (CET), Richard Guenther
> > <[EMAIL PROTECTED]> wrote:
> > ...
> >
> > Uh, and with -funroll-loops we seem to be lost completely, as we
> > produce peeling/loops for a eight times four rolling loop! Where is
Hello!
typedef float v4sf __attribute__((vector_size(16)));
void foo(v4sf *a, v4sf *b, v4sf *c)
{
*a = *b + *c;
}
we no longer (since 4.0) synthesize v2sf (aka sse) operations
for f.i. -march=athlon (not that we were too successful at this
in 3.4 - we generated horrible code instead). Inste
On Mon, 21 Mar 2005, Uros Bizjak wrote:
> Hello!
>
> >typedef float v4sf __attribute__((vector_size(16)));
> >void foo(v4sf *a, v4sf *b, v4sf *c)
> >{
> >*a = *b + *c;
> >}
> >
> >we no longer (since 4.0) synthesize v2sf (aka sse) operations
> >for f.i. -march=athlon (not that we were too
Hi!
Bootstrap of autovect-branch fails on i686 with
stage1/xgcc -Bstage1/
-B/home/rguenth/ix86/gcc-autovect-210305/i686-pc-linux-gnu/bin/ -c -O2
-g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wo
> From: Andrew Haley
>
> Kaveh R. Ghazi writes:
> > After I upgraded to expect-5.43, I noticed that I'm getting extra
> > java failures on the 3.3 branch on x86_64-unknown-linux-gnu. Other
> > gcc branches do not have problems.
> >
> > http://gcc.gnu.org/ml/gcc-testresults/2005-03
On Mar 21, 2005, at 02:54, Nick Burrett wrote:
This seems to be a reoccurance of PR5677.
I'm sorry, but I can't see any way this is related, could you elaborate?
for Aligned_Word'Alignment use
- Integer'Min (2, Standard'Maximum_Alignment);
+ Integer'Min (4, Standard'Maximum_Alignment);
Richard Guenther wrote:
Oh, so we used to expand to 3dnow? I see with gcc 3.4 produced:
foo:
pushl %ebp
movl%esp, %ebp
pushl %ebx
subl$84, %esp
movl12(%ebp), %eax
movl16(%ebp), %edx
[...]
movq-64(%ebp), %mm0
movl%e
On Sun, Mar 20, 2005 at 04:29:01PM -0800, Richard Henderson wrote:
> The easiest way is to do this in the linker instead of the compiler.
> See the xstormy16 port and how it handles R_XSTORMY16_FPTR16. This
> has the distinct advantage that you do not commit to the creation of
> an indirect jump
Geert Bosch wrote:
On Mar 21, 2005, at 02:54, Nick Burrett wrote:
This seems to be a reoccurance of PR5677.
I'm sorry, but I can't see any way this is related, could you elaborate?
Sorry, I completely misread the PR. It is not related.
for Aligned_Word'Alignment use
- Integer'Min (2, Stan
On Mar 21, 2005, at 11:02, Nick Burrett wrote:
OK, but if I don't apply the patch, GNAT complains that the alignment
should be 4, not 2 and compiling ceases.
Yes, this is related to PR 17701 as Arno pointed out to me in a private
message.
Indeed, the patch you used works around this failure and c
Richard Henderson <[EMAIL PROTECTED]> writes:
> On Sun, Mar 20, 2005 at 01:59:44PM +0300, Denis Chertykov wrote:
> > The reload will generate addhi3 and reload will have a problem with
> > two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad
> > surprise for reload. :( As I remember.
>
Paul Schlie <[EMAIL PROTECTED]> writes:
> > From: Denis Chertykov <[EMAIL PROTECTED]>
> >> - possibly something like: ?
> >>
> >> (define_insn "*addhi3"
> >> [(set (match_operand:HI 0 ...)
> >>(plus:HI (match_operand:HI 1 ...)
> >> (match_operand:HI 2 ...)))
> >>
Marek Michalkiewicz <[EMAIL PROTECTED]> writes:
> On Sun, Mar 20, 2005 at 04:29:01PM -0800, Richard Henderson wrote:
>
> > The easiest way is to do this in the linker instead of the compiler.
> > See the xstormy16 port and how it handles R_XSTORMY16_FPTR16. This
> > has the distinct advantage th
> From: Marek Michalkiewicz <[EMAIL PROTECTED]>
>> On Sun, Mar 20, 2005 at 04:29:01PM -0800, Richard Henderson wrote:
>> The easiest way is to do this in the linker instead of the compiler.
>> See the xstormy16 port and how it handles R_XSTORMY16_FPTR16. This
>> has the distinct advantage that
On Fri, 2005-03-18 at 18:25 +0100, Zdenek Dvorak wrote:
> Hello,
>
> > Which appears to walk down the array and try and choose better IV sets.
> > Since it walks down the IV array, which is in SSA_NAME_VERSION order.
> > Thus two loops which are equivalent in all ways except that they use
> > diff
> From: Denis Chertykov <[EMAIL PROTECTED]>
>> Paul Schlie <[EMAIL PROTECTED]> writes:
>> ...
>> (Observing that I'm basically suggesting treating the cc-status register
>> like any other hard register, who's value would need to be saved/restored
>> around any corrupting operation if it's value h
I have checked in the patch to clean up after GCC's change to version
number handling. This should address all reported issues with build,
installation, etc. Per Ian's suggestion, I am doing a multilib-ful
build with a relative $(srcdir), which may expose more problems, which
will be addressed i
Esteemed GCC developers:
I am writing to request the that the sparc -mflat option be retained in
GCC 4.0.
The reason this particular register model is important to me is that I
use GCC on the microSPARC-IIep (actually, a SoC variant produced by
Infineon called the "copernicus") to build firmwar
On Mar 19, 2005, at 7:23 AM, Bernd Schmidt wrote:
I'm updating the copyrights in the Blackfin port, and I noticed
that there appear to be two versions of the wording that allows
more-or-less unlimited use of libgcc files. One can be found e.g.
in config/arm/crtn.asm:
As a special exceptio
I notice that libobjc have a different exception than all of the other
ones
which have an exception to the GPL. Is there is a reason behind this?
The different between the libobjc exception and the one in
libgcc/libstdc++ is that
the exception only takes into account when all sources were compi
Hi,
First off, Mark, if you think this stuff is too late for 4.0, I'll
postpone this to 4.1. Please note that all we have to do is add a few
lines to config.gcc as far as printing the "obsolete" message is
concerned.
Below, I propose to obsolete the following three architectures for GCC
4.0 and
On Mar 21, 2005, at 3:05 PM, Andrew Pinski wrote:
I notice that libobjc have a different exception than all of the
other ones
which have an exception to the GPL. Is there is a reason behind this?
The different between the libobjc exception and the one in libgcc/
libstdc++ is that
the exception
So I've been looking at using REAL_TYPE to represent decimal floating
point values internally (to implement the C extensions for decimal
floating point.) I believe David and yourself had some discussions on
this some short time back.
Anyway, I've now had a chance to play with this a bit, but no
Hi,
I see that the implementation of LANG_HOOKS_GET_CALLEE_FNDECL in Java
always returns NULL (at least for the time being).
static tree
java_get_callee_fndecl (tree call_expr)
{
tree method, table, element, atable_methods;
HOST_WIDE_INT index;
/* FIXME: This is disabled because we end up
gcc.c-torture/execute/2403-1.c tripped over this on an internal
(16 bit) port doing SImode subtract. The comments for expand_binop()
explicitly state that you can't rely on the target being set:
If TARGET is nonzero, the value
is generated there, if it is convenient to do so.
but we s
Jon Grimm wrote:
So I've been looking at using REAL_TYPE to represent decimal floating
point values internally (to implement the C extensions for decimal
floating point.) I believe David and yourself had some discussions on
this some short time back.
FWIW, I'd rather see you stick with REAL_TYPE
Mark Mitchell wrote:
What I would hope would work would be modifying real.c to (a) directly
suport the decimal format for storage, and (b) update the emulation of
floating-point operations to work correctly on the decimal format. I
definitely agree that translating into the binary format is lik
Robert Dewar wrote:
Mark Mitchell wrote:
What I would hope would work would be modifying real.c to (a) directly
suport the decimal format for storage, and (b) update the emulation of
floating-point operations to work correctly on the decimal format. I
definitely agree that translating into the
Mark Mitchell wrote:
I would expect that some decimal floating point values are not precisely
representable in the binary format.
OK, I agree that decimal floating-point needs its own format. But still
you can store the decimal mantissa and decimal exponent in binary format
without any problem, an
Robert Dewar wrote:
Mark Mitchell wrote:
I would expect that some decimal floating point values are not
precisely representable in the binary format.
OK, I agree that decimal floating-point needs its own format. But still
you can store the decimal mantissa and decimal exponent in binary format
wi
Certainly I am doing something wrong, but if not... anyone else
seeing this?
/Volumes/mrs3/net/gcc-darwin/./gcc/xgcc -B/Volumes/mrs3/net/gcc-
darwin/./gcc/ -B/Volumes/mrs3/Packages/gcc-20050128/powerpc-apple-
darwin8.0.0/bin/ -B/Volumes/mrs3/Packages/gcc-20050128/powerpc-apple-
darwin8.0.0/l
On Mar 21, 2005, at 10:10 PM, Mike Stump wrote:
Certainly I am doing something wrong, but if not... anyone else
seeing this?
You want to change the following "#if" in that file, to include
__ppc64__:
#if defined (__PPC__) || defined (__ppc__)
Thanks,
Andrew Pinski
Who helped with the first port
Hi DJ,
On Mon, 21 Mar 2005, DJ Delorie wrote:
> 2005-03-21 DJ Delorie <[EMAIL PROTECTED]>
>
> * optabs.c (expand_binop): Make sure the first subword's result
> gets stored.
This is OK for mainline, provided that you bootstrap and regression
test it somewhere. Thanks. You're quite
Kazu Hirata wrote:
Hi,
First off, Mark, if you think this stuff is too late for 4.0, I'll
postpone this to 4.1. Please note that all we have to do is add a few
lines to config.gcc as far as printing the "obsolete" message is
concerned.
I think that if you get no objections to your message within a
Mike Stump wrote:
The canonical form can be found in gcc/libgcc2.c:
[...] (The General Public License restrictions
do apply in other respects; for example, they cover modification of
the file, and distribution when not linked into a combine
executable.)
(Been wondering about this for a while...) P
I tried building glibc-2.3.4 for m68k-unknown-linux-gnu with gcc-4.0-20050305,
and the compiler fell over in iconv/skeleton.c:
In file included from iso-2022-cn-ext.c:657:
../iconv/skeleton.c: In function 'gconv':
../iconv/skeleton.c:801: internal compiler error: output_operand: invalid
expression
John Marshall <[EMAIL PROTECTED]> writes:
> Mike Stump wrote:
>> The canonical form can be found in gcc/libgcc2.c:
>>
>> [...] (The General Public License restrictions
>> do apply in other respects; for example, they cover modification of
>> the file, and distribution when not linked into a combin
I've merged the gcc_update --silent changes, and Andreas' quoting fix,
from mainline to the 3.4 and 4.0 branches.
zw
hi,
i like to know whether gcc can generate vfp instructions..
main()
{
float a=88.88,b=99.99,c=0;
c=a+b;
printf("%f",c);
}
i used the following option to compile the above program
arm-elf-gcc -mfp=2 -S new.c
but it produces the new.s file without any special kind of (vfp instructions)
inst
47 matches
Mail list logo
