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
I've merged the gcc_update --silent changes, and Andreas' quoting fix,
from mainline to the 3.4 and 4.0 branches.
zw
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 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
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
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
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
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
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
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
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:
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:
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
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
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
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
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
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
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
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
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
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
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
> 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
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: 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
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
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 ...)))
> >>
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.
>
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
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 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
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 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);
> 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
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
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
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, 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
> 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
> 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, 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!
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 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!
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
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).
> 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
47 matches
Mail list logo
