"Yao qi" <[EMAIL PROTECTED]> writes:
>5672 tree
>5673 rs6000_gimplify_va_arg (tree valist, tree type, tree *pre_p,
> tree *post_p)
>5674 {
> ...
>5733 if (dump_file)
>5734 {
>5735 fprintf (dump_file, "TARGET_HARD_FLOAT =
> %d\n",TARGET_HARD_FLOAT);
>
I don't know where the DFP arguments are passed. If they are passed
in the floating point registers, then is the fix as simple as handling
the new modes like SFmode and DFmode in rs6000_gimplify_va_arg?
Yes, new modes has been added correspondingly.
>
> However, I am not sure about the follo
> BTW, I am concerned about the value of TARGET_HARD_FLOAT and TARGET_FPRS,
> I think both of them is 1 here, because I built GCC natively on POWER, but
> when I trace
> it , I found it skips this condation statement as if ARGET_HARD_FLOAT is 0,
> I do not know
> why.
>
> I have searched TARGET
I often find it necessary to add debugging prints to these functions
to show where parameters are found in registers and/or on the stack,
and what kind of thing va_arg returns. These prints most conveniently
take the form of
if (dump_file)
fprintf (dump_file, ...);
to appe
"Yao qi" <[EMAIL PROTECTED]> writes:
> I am working on GCC dfp branch for *only* one month. Three new data types
> are added into GCC for the consideration of precision. These three new
> data types works well in argument passing and value return, but can not
> deal with variable argument passin
Thank you very much for the suggestion. But are there any more details about
them and libgcc. I read the internals but find few information. I will be very
appreciated.
Best Regards.
Eric
From: Ian Lance Taylor
To: "Yao Qi qi" <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org
Subject: Re: var_args for rs6000 backend
Date: 07 Sep 2005 09:14:49 -0700
"Yao Qi qi" <[EMAIL PROTECTED]> writes:
It might help if you give a brief overview of what you are trying to
do (maybe you already have, an
On Friday 09 September 2005 02:51, Eric Fisher wrote:
> Hello,
>
> Can anyone give me some suggestions about floating point implemention.
> My new target doesn't have floating point register. But must I implement
> the floating point operantion? Libgcc always fails on _floatdifi.o. But how
> can I
Hello,
Can anyone give me some suggestions about floating point implemention.
My new target doesn't have floating point register. But must I implement
the floating point operantion? Libgcc always fails on _floatdifi.o. But how
can I implement them?
Thanks a lot!
Eric.
Yes, the eABI is a modification of the System V ABI. IIRC (but it has
been several years since I worked on PowerPC), the differences between
eABI and System V were:
1) eABI used r2 as a secondary small data pointer (System V used just
r13), and r0 was used for data centered around location 0;
2)
From: "Meissner, Michael" <[EMAIL PROTECTED]>
To: "Yao Qi qi" <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org
Subject: RE: var_args for rs6000 backend
Date: Wed, 7 Sep 2005 13:11:50 -0400
There was also a PowerPC NT ABI at one point, but since Windows NT on
PowerPC was stillborn, it was removed.
My poin
Snapshot gcc-4.0-20050908 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050908/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050908
You'll
On Sep 8, 2005, at 4:36 PM, Ed Smith-Rowland wrote:
Should Objective-C++ be mentioned in the 4.1 changes?
Yes. We welcome your patch!
All,
I was looking at the 4.1 changes in
http://gcc.gnu.org/gcc-4.1/changes.html
and noticed that no mention was made of recent Objective-C++ work in
mainline.
This after I bootstrapped on MacOSX 10.3.9 with
--enable-languages=c,c++,java,objc,obj-c++,f95,treelang
I haven't played around with
DJ Delorie wrote:
>>Since August 21st, when I sent my last status report, we've reduce the
>>number of bugs targeted at 4.1 from 271 to 250; about a bug a day.
>
>
> On the gcc home page, we have a (now obsolete) link to the latest
> status.
...
> We're also missing the status link for the 4.
Ok, I -think- I've found one problem.
Identifying the processor as an SB1 may be producing a
confused result.
Both binutils and glibc's configure scripts will see
it as a mips32, because it does not start off with
mips64 in the name.
However, GCC's configure scripts expands the name to
mipsisa64
I was asked yesterday whether making performance improvements during
Stage 3 is appropriate, so I'll attempt to clarify this point.
Such patches are definitely appropriate, provided that they're targeted
at regressions/bugs, and not attempts to sneak in new features. For
example, if the scheduler
Here's the web link to all of the patches needed by
the Linux From Scratch group.
http://documents.jg555.com/cross-lfs/mips64-64/materials/patches.html
I'm doing a build from the binutils, gcc and glibc
from CVS, for an initial run. Results so far:
Binutils patches cleanly, using the patch on fi
Jonathan Day <[EMAIL PROTECTED]> writes:
> I -think- I need a chisel, as well, though. On
> producing the bootstrap GCC cross-compiler, trying to
> compile with it produces the error that it can't find
> crti.o, crtn.o or crt1.o. IIRC, these are produced
> when compiling GCC, but the GCC in CVS do
FYI, this fixes both PR ada/23141 and ada/23142.
Laurent
On Thu, 2005-09-08 at 10:27 -0400, Diego Novillo wrote:
> On 09/05/05 17:39, Richard Kenner wrote:
>
> >Shouldn't the test be that both lhs_vr *and* vr_result are VR_RANGE?
> >
> >
> Yes, good catch. If that fixes your testcase, please
> Olivier Hainque writes:
Olivier> Can GCC 4.X be used to generate code running properly on a MPC5554
Olivier> processor ?
The base PowerPC Book-E UISA generated by GCC should work on the
MPC5554. I am not sure about the difference between the 5554 e200 core
and the 8540 e500 core.
Jonathan Day wrote:
Crosstool, for example, only supports 32-bit MIPS -
and even then the build matrix is a pretty shade of
red for the most part.
[ The build matrix: http://kegel.com/crosstool/current/buildlogs/ ]
There are quite a few combinations that build for 32-bit mips with crosstool,
On Thursday, September 8, 2005, at 09:46 AM, Janis Johnson wrote:
In the hopes that it will help the discussion I ran regression hunts on
the two test cases. The first test:
struct foo {
friend class bar;
void screw (bar&);
};
is rejected starting with this 4.0 patch:
http://gc
On Wed, Sep 07, 2005 at 09:55:29PM +0200, Richard B. Kreckel wrote:
> On 7 Sep 2005, Gabriel Dos Reis wrote:
> > Mike Stump <[EMAIL PROTECTED]> writes:
> > | I'll echo the generalized request that we try and avoid tightenings
> > | on other than x.y.0 releases.
> >
> > I hear you. In this specific
--- Kai Ruottu <[EMAIL PROTECTED]> wrote:
> So, Jonathan, if you need to get a knife (glibc)
for
>producing your own hammer (gcc), just ask someone to
>give that knife and produce your own hammer first
with
>that borrowed knife. And then produce your own knife
>using your self-made hammer and late
Hello,
Can GCC 4.X be used to generate code running properly on a MPC5554
processor ?
>From the current sources, it seems to me that the closest explicitly
supported CPU is the 8540, but I'm a bit unclear if code for the
latter would be fully compatible for the former, or if other variants
would
On 09/07/05 16:18, Jeffrey A Law wrote:
Are you getting something different?
We'd probably trigger a problem if
lhs_vr = [0, max]
vr_result = ~[max, max]
in that case, the code at the end of vrp_visit_phi_node would
erroneously set VR_RESULT to ~[-INF, max], which I can see causing
On 09/08/05 10:49, Richard Kenner wrote:
I saw email from Jeff yesterday asking
for more details, though. I was travelling yesterday, but will try to
get back to that message tomorrow.
Hmm, I missed that. Will check the archives.
Yes, good catch. If that fixes your testcase, please apply the fix.
You are referring to this, right?
Will do. Yes, precisely that. I saw email from Jeff yesterday asking
for more details, though. I was travelling yesterday, but will try to
get back to that message tomorrow.
On 09/05/05 17:39, Richard Kenner wrote:
Shouldn't the test be that both lhs_vr *and* vr_result are VR_RANGE?
Yes, good catch. If that fixes your testcase, please apply the fix.
You are referring to this, right?
--- tree-vrp.c 7 Sep 2005 20:35:19 - 2.54
+++ tree-vrp.c 8 Sep 2
On 09/05/05 17:56, Richard Kenner wrote:
Why doesn't it use fold-const.c:merge_ranges instead of having a subset
of that code?
Oversight, most likely. vrp_meet has only recently started growing.
Though the only case that you could factor is when both are VR_RANGEs.
> > Even when using precompiled headers, .pch files can get pretty big,
> > and they must still be loaded,
>
> They do? Odd, on my platform, we only mmap them. If one
> doesn't touch them (and nothing else near them), they aren't
> loaded for me.
>
> > which takes time.
>
> mmap is fairly qu
Hi,
I'm trying to get the symbol type from a .map file generated by the makefile.
Actually, in the makefile, the option of my gcc are :
$(XCC) -L$(INSTALL_DIR)/lib -Ttarget.ld -o $@ $^ $(LDFLAGS)
-Wl,-Map,[EMAIL PROTECTED]
Thus it builds a .map file where we can find the symbol table, b
33 matches
Mail list logo
