Liu Haibin <[EMAIL PROTECTED]> writes:
> Does the following rtl implicitly indicate that r5 is used?
>
> (expr_list (use (reg:DF 6 r6))
> (expr_list (use (reg:DF 4 r4))
If DFmode requires two registers on your machine--which does appear to
be the case based on the assembly code which you
Hi,
I compiled the following code using nios gcc -da -O3 (gcc version 3.3.3)
#include
#define PI (4*atan(1))
double rad2deg(double rad)
{
return (180.0 * rad / (PI));
}
In .s file, it has some codes like this
mov r4, zero
movhi r5, %hiadj(107269324
On Wed, Sep 07, 2005 at 11:14:28AM +0800, Yao Qi qi wrote:
> I just have to concentrate on ABI_V4 if I work on gcc develoment on
> powerpc-linux, am I right ?
Yes, and take care not to break code for the other ABIs. :-)
Incidentally, powerpc64-linux is ABI_AIX.
--
Alan Modra
IBM OzLabs - Linux
From: "Meissner, Michael" <[EMAIL PROTECTED]>
To: "Yao qi" <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org
Subject: RE: var_args for rs6000 backend
Date: Tue, 6 Sep 2005 14:13:56 -0400
And note Yao qi, that there are different ABIs on the rs6000, each of
which has different conventions (ie, you will ne
On Sep 6, 2005, at 6:44 PM, Mike Stump wrote:
On Sep 6, 2005, at 6:16 PM, Gabriel Dos Reis wrote:
wrong-code generation that was fixed.
Customers validate their app and are `happy' with the code
generation, so this appears to not be a real an issue. Failure to
compile their app to the
On Sep 6, 2005, at 6:16 PM, Gabriel Dos Reis wrote:
wrong-code generation that was fixed.
Customers validate their app and are `happy' with the code
generation, so this appears to not be a real an issue. Failure to
compile their app to them feels slightly more real.
Mike Stump <[EMAIL PROTECTED]> writes:
| On Sep 6, 2005, at 6:16 PM, Gabriel Dos Reis wrote:
| > wrong-code generation that was fixed.
|
| Customers validate their app and are `happy' with the code
| generation, so this appears to not be a real an issue.
I think we did have an open PR for that,
I would prefer a recipe to build the toolchain myself
from source, but if you happen to know of a site with
binaries for the SB1 under Linux, I wouldn't be
horribly opposed.
For the latter I'd try broadcom, they've been pretty good about
shipping tools that are known to work on the board. Tha
Hi,
I am trying to compile a toolchain for a Broadcom SB1
processor in big-endian mode with a host Operating
System of Linux. (The SB1 is a MIPS64, but there is
also a specific SB1 target.) So far, I'm running into
error after error when attempting to build either
directly on the board or attempti
On Sep 5, 2005, at 12:09 AM, Noe Aljaz ITICMN wrote:
2. Define macro NO_TEMPLATE_INSTANTIATION during normal compilation
and
un-define it when g++ is called by collect2,
and making this accessible via some new compiler option (e.g. -
frepo2)?
Why would this be good?
Normal compiles instan
> For a port then yes *-elf is easier to start, especially if you're
> planning on going for an elf based operating system.
>
> What about the mips port made you decide that you wanted to use that
> as a guideline?
>
> -eric
Firstly, there're some similar between them. Secondly, we're some fami
Exactly to say, the target is neither mips-elf nor mips-linux-gnu.
I just
use mips-elf as the start. It's a new target with little endian and
own ISA.
We need to port binutils and gcc and also library.
For a port then yes *-elf is easier to start, especially if you're
planning on going f
>If you are running the Linux kernel, then your target is not mips-elf,
>but rather mips-linux-gnu. For that target, glibc or uclibc is
>appropriate.
Exactly to say, the target is neither mips-elf nor mips-linux-gnu. I just
use mips-elf as the start. It's a new target with little endian and own
Mike Stump <[EMAIL PROTECTED]> writes:
| On Sep 2, 2005, at 2:30 PM, Richard B. Kreckel wrote:
| > This lead to developer irritation because people expect that what
| > compiled with GCC x.y.z should still compile with GCC x.y.z+1.
|
| I'll echo the generalized request that we try and avoid tight
On Sep 6, 2005, at 12:04 PM, Michael Tegtmeyer wrote:
I am trying to find out what the existing method of determining
whether or not something (function for example) can access a field
of a structure.
M-x grep access cp/*.[ch] will show you the existing methods of
access control. lookup_m
On Sep 2, 2005, at 2:30 PM, Richard B. Kreckel wrote:
This lead to developer irritation because people expect that what
compiled with GCC x.y.z should still compile with GCC x.y.z+1.
I'll echo the generalized request that we try and avoid tightenings
on other than x.y.0 releases.
Snapshot gcc-3.4-20050906 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050906/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050906
You'll
Brian Dessent <[EMAIL PROTECTED]> writes:
> I hope it's not bad etiquette to ping a PR but I would greatly
> appreciate it if someone could take a quick look at PR 22207 which has
> gone for several months with no replies.
>
> The problem involves bogus "might be used uninitialized" warnings in S
> I'm wondering why verify_ssa doesn't detect this.
It does. See for instance pr 15740, which had generated an ICE.
But what I don't understand is why it didn't ICE in my case.
That we don't constantly see problems is indicitive that the
front-ends are good about using mark_
On Tue, Sep 06, 2005 at 03:37:26PM -0400, Richard Kenner wrote:
> I'm wondering why verify_ssa doesn't detect this.
It does. See for instance pr 15740, which had generated an ICE.
That we don't constantly see problems is indicitive that the
front-ends are good about using mark_addressable when
> Yeah, that's what I realized in working on this problem. Is it worth
> adding a flag to show that this is a gimple-generated variable so we
> can have an assert that we're not trying to mark it as addressable?
What has gimple-generated got to do with it?
Well, if it's gimple-ge
On Tue, Sep 06, 2005 at 03:07:35PM -0400, Richard Kenner wrote:
> Yeah, that's what I realized in working on this problem. Is it worth adding
> a flag to show that this is a gimple-generated variable so we can have
> an assert that we're not trying to mark it as addressable?
What has gimple-gener
Hello,
I am trying to find out what the existing method of determining whether
or not something (function for example) can access a field of a structure.
For example:
class A {
public:
int pub_var;
void foo(/*implicit this* */) {...}
private:
int private_var;
};
void bar(A
If part way through gimplification you mark a variable as addressable,
then you invalidate the gimplification of preceeding statements. At
least for variables whose type satisfies is_gimple_reg_type.
Yeah, that's what I realized in working on this problem. Is it worth adding
a fla
On Tue, Sep 06, 2005 at 02:41:14PM -0400, Richard Kenner wrote:
> It certainly calls mark_addressable in various places, so I don't follow.
Then these are bugs waiting to happen.
If part way through gimplification you mark a variable as addressable,
then you invalidate the gimplification of prece
Ian Lance Taylor wrote:
(You may want to use the mips-elf target to build the Linux kernel
itself; I'm not sure. But when building applications to run on top of
the kernel, mips-linux-gnu is the correct target to use.)
I successfully build both user space and kernel code with the same
mipse
The gimplifier never sets TREE_ADDRESSABLE on existing variables.
It certainly calls mark_addressable in various places, so I don't follow.
On Tue, Sep 06, 2005 at 01:45:22PM -0400, Richard Kenner wrote:
> Thanks. I was just copying that code without full understanding
> of what it was doing. But where is that flag cleared when TREE_ADDRESSABLE
> is set? I can't find anything that ever clears it?
Because TREE_ADDRESSABLE should alr
Currently we use ld as a linker on Solaris.
Is there a gcc linker and is this preferable to using ld?
Thanks for any input?
Ivan
And note Yao qi, that there are different ABIs on the rs6000, each of
which has different conventions (ie, you will need to study the AIX ABI
as well as the System V/eabi ABIs, and possibly other ABIs that are now
used).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
"Yao qi" <[EMAIL PROTECTED]> writes:
> I am working on variable arguments on rs6000 backend and I have
> browsed gcc/config/rs6000/rs6000.c for several times, I found
> there are some functions relavtive to this issue, they are
> setup_incoming_varargs, rs6000_build_builtin_va_list ,rs60
Eric Fisher <[EMAIL PROTECTED]> writes:
> Thanks for your suggestion.
> I think I need to port glibc. Because the new board is going to run
> linux kernel. But I'm still not sure if glibc will support the new
> target well. Thanks.
If you are running the Linux kernel, then your target is not mip
>if (TREE_CODE (TREE_TYPE (op)) == COMPLEX_TYPE)
> DECL_COMPLEX_GIMPLE_REG_P (new_var) = 1;
You should not have set this; you're taking the address of
the variable after all.
Thanks. I was just copying that code without full understanding
of what it was doing. But w
On Tue, Sep 06, 2005 at 08:04:29AM -0400, Richard Kenner wrote:
> if (TREE_CODE (TREE_TYPE (op)) == COMPLEX_TYPE)
> DECL_COMPLEX_GIMPLE_REG_P (new_var) = 1;
You should not have set this; you're taking the address of
the variable after all.
> I don't care for the duplication of c
On Tue, Sep 06, 2005 at 03:13:40AM -0400, James A. Morrison wrote:
> Won't this break a disabled checking build since internal_throw will become
> unused?
No, because it won't. Look at what gcc_assert expands to when it's
disabled.
r~
> But only where the semantics are well defined. I can think of several
> different possible semantics for talking the address of arbitrary
> things.
>
> The counter-argument is that it can used when the semantics need *not* be
> well-defined, in other words, where you're saying you do
[EMAIL PROTECTED] (Richard Kenner) writes:
| The whole point of the gimplifier is to avoid making too many restrictions on
| what are valid trees: it's GIMPLE where we want to make those restrictions.
| It seems very duplicative to me to say that the process of creating
| temporaries for certain e
But only where the semantics are well defined. I can think of several
different possible semantics for talking the address of arbitrary
things.
The counter-argument is that it can used when the semantics need *not* be
well-defined, in other words, where you're saying you don't care.
> But secondly, why make that restriction at all? Suppose I have a function
> to which a language semantics requires passing by reference. Now suppose
> the operand is "a + b". Why not just make an ADDR_EXPR of the PLUS_EXPR?
>
> Sure, the front end *could* make a temporary, but the gimplifier h
Hmm, odd that such a rule wouldn't exist.
Not at all odd! We have almost no rules *whatsoever* on what's allowed
in each operand of a GENERIC tree. That's the problem here.
To me it seems an ADDR_EXPR only makes sense on something that is
addressable,
First of all, define "addres
On Tuesday 06 September 2005 15:37, Richard Kenner wrote:
> What would be your proposal as to which nodes it's valid to have as
> operands of an ADDR_EXPR? We certainly never even thought of such a rule
> before.
Hmm, odd that such a rule wouldn't exist. To me it seems an ADDR_EXPR
only makes se
Can't you use get_initialized_tmp_var, then?
No, and that's the whole point! You need to set TREE_ADDRESSABLE on
the variable *before* gimplifying the MODIFY_EXPR.
Steven Bosscher <[EMAIL PROTECTED]> writes:
| On Tuesday 06 September 2005 15:05, Gabriel Dos Reis wrote:
| > Richard Guenther <[EMAIL PROTECTED]> writes:
| > | On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
| > | > I don't think we ever defined "valid GENERIC" that way.
| > | >
| > | >
Richard Kenner <[EMAIL PROTECTED]> wrote:
> /* Otherwise, if we are taking the address of something that is
> neither a refence, declaration, or constant, make a variable for the
operand
> here and then take its address. If we don't do it this way, we may
> confuse the gimplifier because it
Because it doesn't make sense to take the address of a COMPOUND_EXPR
for example? As Kenner puts it himself:
"This turned out to be the "well known" problem that the Ada
front end is making an ADDR_EXPR of odd things, in this case
a COMPOUND_EXPR."
So there
The only useful definition is that valid GENERIC is what the
gimplifier can turn into valid GIMPLE, which is much more well-defined
;) Modulo bugs in the gimplifier of course ...
But that's the whole problem! If you have a tree that the gimplifier
can't correctly process, how do you d
On Sep 6, 2005, at 8:21 AM, Steven Bosscher wrote:
Hi,
Consider this little snippet:
int x;
int
foo (int a)
{
x = a;
return x + 3;
}
Likewise for:
int
foo (int a, int *x)
{
*x = a;
return *x + 3;
}
-- Pinski
On Tuesday 06 September 2005 15:05, Gabriel Dos Reis wrote:
> Richard Guenther <[EMAIL PROTECTED]> writes:
> | On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
> | > I don't think we ever defined "valid GENERIC" that way.
> | >
> | > About a year ago, when we tried to define it, that's what
Richard Guenther <[EMAIL PROTECTED]> writes:
| On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
| > I don't think we ever defined "valid GENERIC" that way.
| >
| > About a year ago, when we tried to define it, that's what we came up
| > with. If that isn't the definition, then what *is*?
On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
> I don't think we ever defined "valid GENERIC" that way.
>
> About a year ago, when we tried to define it, that's what we came up
> with. If that isn't the definition, then what *is*? The problem is that
> we have no document that says wh
I don't think we ever defined "valid GENERIC" that way.
About a year ago, when we tried to define it, that's what we came up
with. If that isn't the definition, then what *is*? The problem is that
we have no document that says what is and is not valid GENERIC. At
least the proposed defini
Hi,
Consider this little snippet:
int x;
int
foo (int a)
{
x = a;
return x + 3;
}
With -fno-tree-dominator-opts, we do not optimize away the load
from x in "x + 3". I would have expected store-copyprop to do
this, but
On Tuesday 06 September 2005 14:04, Richard Kenner wrote:
> On the
> other hand, we define "valid GENERIC" to be those trees that were generated
> by the compiler immediately before the tree-ssa conversion and trees of the
> above form were generated then. So they are valid GENERIC and ought to be
> # VUSE ;
> VIEW_CONVERT_EXPR(*D.861).b = 1;
Why are we using a VIEW_CONVERT_EXPR here btw? I'd say
D.862 = (struct c34007p__T7b *) D.860;
D.862->b = 1;
would be a lot more middle-end friendly and maybe not exposing the
problem you are seeing? Of co
You want to look at tree-ssa-operands.c:get_expr_operands() and see where
things go wrong. Also for D.861 not in SSA form, there might be a missing
call to mark_vars_to_rename and/or update_ssa somewhere. At which point
in the pass flow does the above happen? Is it ever "correct"
On Sep 6, 2005, at 3:13 AM, James A. Morrison wrote:
Won't this break a disabled checking build since internal_throw will
become
unused?
Yes but this was more of a RFC rather than submitting a patch.
-- Pinski
Richard Kenner wrote:
> [Sorry for the missing line in my last message.]
>
> I'm watching it deal with
>
> # small_1 = PHI <32(0), 1(1)>
>
> vrp_meet is called with [32, 32] and [1,1].
>
> It determines that the ranges don't intersect and then comes up with
> ~[0,0] since neither co
On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Here's a fragment of the SSA dump for a shortened version of that
> test.
>
>
> D.860_8 = __gnat_malloc (20);
> # D.861_10 = V_MUST_DEF ;
> D.861 = (struct c34007p__designated *) D.860_8;
> # VUSE ;
> VIEW_CONVERT_EXPR(*D.861).b
On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Here's a fragment of the SSA dump for a shortened version of that
> test.
>
>
> D.860_8 = __gnat_malloc (20);
> # D.861_10 = V_MUST_DEF ;
> D.861 = (struct c34007p__designated *) D.860_8;
> # VUSE ;
> VIEW_CONVERT_EXPR(*D.861).b
You showed me that it might be dangerous to replace rtx on the LHS
of a SET using simplify_replace_rtx ().
simplify_rtx () seems safer, is there a good reason why it doesn't
work with INSNs and SETs?
Because it works with expressions. :-)
Will a generalized function called simplify_insn () th
Hello,
In the discussion:
"Question about merging two instructions"
http://gcc.gnu.org/ml/gcc/2005-08/msg00563.html
You showed me that it might be dangerous to replace rtx on the LHS
of a SET using simplify_replace_rtx ().
simplify_rtx () seems safer, is there a good reason why it doesn't
work wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.0.1
Platform: mips-sgi-irix6.5
configure flags:
- --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install
- --with-gnu-as
- --with-as=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/as
- --with-gnu-ld
- --with-ld=/SCRATCH
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Compiler version: 4.0.1
Platform: hppa2.0w-hp-hpux11.00
configure flags:
- --prefix=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install
- --with-gnu-as
- --with-as=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install/bin/as
- --with-ld=/usr/ccs/bi
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Sep 5, 2005, at 6:39 PM, Richard Henderson wrote:
>
>> On Mon, Sep 05, 2005 at 02:27:54PM +0200, Andreas Krebbel wrote:
>>> (insn 31 29 49 5 (set (mem/s/j:SI (plus:SI (reg/v/f:SI 47 [ env ])
>>> (const_int 4 [0x4])) [0 .ex+0 S4 A32])
64 matches
Mail list logo
