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 ph
, April 20, 2007 8:05 AM
> To: Stephens, Nigel
> Cc: Fu, Chao-Ying; gcc@gcc.gnu.org; Thekkath, Radhika
> Subject: Re: [MIPS] MADD issue
>
>
> Nigel Stephens <[EMAIL PROTECTED]> writes:
> > OK, so maybe as the person who removed adddi3 from the MIPS
> backend, and
>
> -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 a
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 loc
Mingjie Xing wrote:
> 2011/2/18 Fu, Chao-Ying :
> > 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
>
>
> 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
> -L/tmp/build-ndk/gcc-4.7.0/arm
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 fun
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 letter
"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/33
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 & (-1< c) >> c
> into x & ((unsigned)-1 >> c) for unsigned types. */
>
> I attached a simple patch whic
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
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
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 writes:
> > On 29/03/2012, at 5:38 PM, Maxim Kuvyrkov wrote:
> >
> >> I v
Andrew Pinski wrote:
> On Mon, Apr 2, 2012 at 1:55 PM, Fu, Chao-Ying 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 fi
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
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.
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;
}
fu@
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,
> -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 2
> -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 h
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 a
Hi,
For those who are interested in looking at all changes
for the fixed-point branch, I created a diff file of
147 files. This diff file doesn't have changes requested
by Mark.
Because the diff file is large, I compressed it and
posted it to the GCC wiki page (20070608gcc.diff.gz).
http://
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 st
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 r
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
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 at
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/
]
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
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-DHAV
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
30 matches
Mail list logo
