Richard Sandiford [mailto:rdsandif...@googlemail.com] wrote:
From http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01480.html,
the patch defines HARD_REGNO_CALLER_SAVE_MODE to return
proper mode for i386.
For MIPS, we may have:
Ex:
#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS,
Hi All,
From testing, I found out that the whole width of a MIPS
integer/floating-point register
is saved and restored around a call. This may hurt the performance.
Ex:
fu@debian6:/disk/fu/dev/test$ cat add2.c
void test2(float);
float test(float a, float b)
{
test2(a*b);
return a;
}
Where does mips link.h come from? I didn't see it in AOSP
Bionic C library.
--
H.J.
It's from development/ndk/platforms/android-9/arch-mips/include/link.h from
AOSP checkout.
Regards,
Chao-ying
Richard Sandiford wrote:
Index: gcc/config/mips/gnu-user.h
===
--- gcc/config/mips/gnu-user.h (revision 186580)
+++ gcc/config/mips/gnu-user.h (working copy)
@@ -45,8 +45,10 @@
/* A standard GNU/Linux mapping.
Hi Maxim, Richard,
I built cross-toolchains for 3 different targets as follows.
1. mips-linux-gnu
2. mips-linux-gnu --enable-targets=all
3. mips64-linux-gnu
These targets are affected by this MIPS Android patch.
Then, I checked the output from gcc -dumpspecs before and after applying
the
Maxim Kuvyrkov wrote:
For now, two MIPS changes in gnu-user.h and
unwind-dw2-fde-dip.c can be posted for comment.
(I didn't tested this patch, though.)
You need to test your patches before posting them for review.
Below are a couple of comments on your current version.
I can
Maxim Kuvyrkov wrote:
I encourage you to submit the MIPS Android patches to
gcc-patches@. And, as long as your changes preserve the
status quo of mips-*-* being big-endian by default and
mipsel-*-* being little-endian by default, there should be no
major obstacles to merge those in.
Andrew Pinski wrote:
On Mon, Apr 2, 2012 at 1:55 PM, Fu, Chao-Ying f...@mips.com wrote:
It basically sets the MIPS target to little-endian MIPS32
for mips-linux-android.
That seems broken because mips-*-* is big-endian and mipsel-*-* is
little-endian. Is any way of fixing that before
Andrew Pinski wrote:
The point is mips*-*-* is big endian and mipsel*-*-* is little endian.
And doing adding a target which says mips-linux-android which is
little-endian is just backwards. Is there anyway to fix the target
triplet to be mipsel-linux-android including inside the official
Richard Sandiford wrote:
Sent: Monday, April 02, 2012 11:45 AM
To: Maxim Kuvyrkov
Cc: Richard Earnshaw; Jan Hubicka; gcc@gcc.gnu.org
Subject: Re: [GCC Steering Committee] Android sub-port reviewer
Maxim Kuvyrkov ma...@codesourcery.com writes:
On 29/03/2012, at 5:38 PM, Maxim Kuvyrkov
Liu [pro...@gmail.com] wrote:
OK, I get.
But, sorry, my mips64dspr2 patch has be done...
Should I summit it?
I just wonder what version of the MIPS64 DSP/DSPr2 spec that you implemented.
Do you have a target CPU that has these MIPS64 DSP/DSPr2 instructions? My
concern is that the latest
Richard Sandiford [rdsandif...@googlemail.com] wrote:
This pattern maps directly to __builtin_mips_prepend, which is defined
to take and return an SI type, so :SI is the correct choice here.
I agree it might be nice to have a function that operates on 64-bit
values for 64-bit targets though.
I identified the libstdc++ failure as a problem when building gcc:
configure:16321: /tmp/build-ndk/gcc-4.7.0/./gcc/xgcc
-shared-libgcc -B/tmp/build-ndk/gcc-4.7.0/./gcc -nostdinc++
-L/tmp/build-ndk/gcc-4.7.0/arm-linux-androideabi/libstdc++-v3/
src
Chung-Lin Tang wrote:
I analyzed this testcase regression a while earlier; the
direct cause of
this is due to mips_order_regs_for_local_alloc(), which now serves as
MIPS' ADJUST_REG_ALLOC_ORDER macro.
The mips_order_regs_for_local_alloc() function seems to be written for
the old
Mingjie Xing wrote:
2011/2/18 Fu, Chao-Ying f...@mips.com:
I think your analysis is correct. We should just delete
mips_order_regs_for_local_alloc()
in mips.c and delete ADJUST_REG_ALLOC_ORDER in mips.h.
Then, 3 accumulators can be used in dspr2-MULT.c and
dspr2-MULTU.c now. Thanks
Hi,
G++ could not split restore_gp.
Please check this test (from #line 15017 configure of
gcc/libstdc++-v3/).
# cat foo.cpp
struct S { ~S(); };
void bar();
void foo()
{
S s;
bar();
}
# ~/dev/gcc45/build/gcc/cc1plus -quiet foo.cpp -o foo.s -mno-shared -mplt
-mabicalls -G0
foo.cpp: In
Sean D'Epagnier wrote:
I think I found a generic problem for fixed point constant folding.
In fold-const.c:11872 gcc tries to apply:
/* Transform (x c) c into x (-1c), or transform (x
c) c
into x ((unsigned)-1 c) for unsigned types. */
I attached a simple patch
Janis Johnson wrote:
I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix
suffixes in decimal float literal constants for c/33466. While I'm at
it I'm fixing suffixes for fixed-point literal constants.
Currently for
fixed-point GCC accepts any ordering of the letters in
Janis Johnson wrote:
On Wed, 2009-02-11 at 10:42 -0800, Fu, Chao-Ying wrote:
Janis Johnson wrote:
I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix
suffixes in decimal float literal constants for c/33466. While I'm at
it I'm fixing suffixes for fixed-point
Manuel López-Ibáñez wrote:
On 05/09/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Summary
===
We are closing in on Stage 3, previously announced for
September 10th.
At this point, I'm not aware of any reason to delay that date. Are
there any Stage 2 patches that people don't
Revital1 Eres wrote:
I get the following error running trunk r127993 with
--enable-checking=assert on ppc64:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall
-Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute
]
Sent: Sunday, August 26, 2007 6:28 AM
To: gcc@gcc.gnu.org; Fu, Chao-Ying
Subject: Bootstrap failure with --enable-checking=all,rtl
I get a bootstrap error on Linux/x86-64 with current svn:
/abuild/aj/gcc/./prev-gcc/xgcc -B/abuild/aj/gcc/./prev-gcc/
-B/opt/gcc/4.3-devel/x86_64-suse-linux-gnu/bin
FX Coudert wrote:
My automated nightly build failed to bootstrap this evening on i386-
pc-linux-gnu. This is for trunk rev. 127311, and the error is:
/home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/xgcc -B/home/
fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/ -B/home/fx/
Hi,
I got one test that failed by using the mainline GCC
on the target of mipsisa32r2-elf.
The handling of stack pointer or frame pointer may be broken.
Thanks!
Ex:
# mipsisa32r2-elf-gcc -o bug126 -Tidt32.ld bug126.c
# mipsisa32r2-elf-run bug126
mips-core: 4 byte read to unmapped address 0x4
Bernd Schmidt wrote:
I attached a diff file for 14 files of the new structures
and documents. You and other maintainers are welcome to
check it. Thanks a lot!
Note: 14 files are =
genmodes.c mode-classes.def machmode.def machmode.h tree.def tree.h
tree.c rtl.def rtl.h rtl.c
Bernd Schmidt wrote:
+ACCUM_MODE (HA, 2, 8, 7); /* s8.7 */
+ACCUM_MODE (SA, 4, 16, 15); /* s16.15 */
+ACCUM_MODE (DA, 8, 32, 31); /* s32.31 */
+ACCUM_MODE (TA, 16, 64, 63); /* s64.63 */
Lots of predefined types and modes in this patch. What
about targets
with other requirements
Hi,
As Mark requested, we propose a merge plan for the fixed-point branch
as follows.
1. Merge in machine modes to support signed and unsigned
fract and accum modes. Handle scalar and vector modes.
2. Merge in fixed-value.h and fixed-value.c to handle fixed-point values.
3. Merge in TREE
Mark Mitchell wrote:
I attached a diff file for 14 files of the new structures
and documents. You and other maintainers are welcome to
check it. Thanks a lot!
Thank you for posting this.
Things about which I am clueless:
What is the difference between a _Fract type and an
-Original Message-
From: Mark Mitchell [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 31, 2007 9:05 AM
To: Joseph S. Myers
Cc: Fu, Chao-Ying; Richard Henderson; GCC
Subject: Re: Fixed-point branch?
Joseph S. Myers wrote:
I haven't examined it. When the branch maintainers
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Dave Korn
Sent: Friday, May 11, 2007 11:32 AM
To: 'Paul Brook'; gcc@gcc.gnu.org
Cc: 'Mohamed Shafi'; 'Andrew Haley'
Subject: RE: Updating an operand in RTL for a builtin function
On 11 May 2007
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
H. J. Lu
Sent: Wednesday, April 25, 2007 2:02 PM
To: Steve Ellcey
Cc: [EMAIL PROTECTED]; gcc@gcc.gnu.org
Subject: Re: Problem with patch for PR tree-optimization/29789
On Wed, Apr 25, 2007 at
Hi Richard,
After tracing GCC 4.x to see why MADD is not generated for MIPS32,
I found out the main issue is that the pattern adddi3
is not available for MIPS32. Because the missing
of adddi3, GCC 4.x needs to split 64-bit addition to 4 separate
RTL insns. This leads to that the combining
Hello,
I think there is a bug in mips_pass_by_reference when the mips abi
is EABI to pass TImode parameters.
The following code is from the mainline GCC mips.c.
-
mips_pass_by_reference (CUMULATIVE_ARGS *cum ATTRIBUTE_UNUSED,
enum machine_mode mode, tree type,
Hello All,
We are working on a project to add fixed-point arithmetic support to GCC.
A GCC project description page is available here
http://gcc.gnu.org/wiki/FixedPointArithmetic
and we will create a GCC branch in the near future. If you have
any suggestions or comments, please respond.
Thanks
34 matches
Mail list logo
