Re: S/390 Bootstrap failure due to fixup_eh_region_note
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]) >>> (mem/f:SI (plus:SI (plus:SI (reg:SI 55) >>> (reg:SI 56)) >>> (const_int 4092 [0xffc])) [0 S4 A32])) >> >> Guh. >> >> Well, I suppose this is no different from a fp arith insn with a >> pre-reload memory input that gets reloaded into a register. I >> suppose there's no invariant that I can enforce. >> >> If you look at the version of fixup_abnormal_edges before my patch >> you'll see a bit that calls find_many_sub_blocks; re-add that hunk >> and remove the assert in fixup_eh_region_note, then re-test. > > Well find_many_sub_blocks will not find new BBs as the EH_REGION is an > external throw and not internal throw. > I think the following patch should fix the problem without any effects. > It just adds the check to make sure that we have internal throw when > checking > the trap_count. > > Andreas, could you check this patch? > > Richard, what do you think about this patch? > > It fixes jni.ii for me. > > -- Pinski > > > Index: reload1.c > === > RCS file: /cvs/gcc/gcc/gcc/reload1.c,v > retrieving revision 1.481 > diff -u -p -r1.481 reload1.c > --- reload1.c 1 Sep 2005 23:35:18 - 1.481 > +++ reload1.c 6 Sep 2005 03:31:48 - > @@ -3769,6 +3769,7 @@ fixup_eh_region_note (rtx insn, rtx prev >rtx note = find_reg_note (insn, REG_EH_REGION, NULL_RTX); >unsigned int trap_count; >rtx i; > + int internal_throw = can_throw_internal (insn); > >if (note == NULL) > return; > @@ -3805,7 +3806,7 @@ fixup_eh_region_note (rtx insn, rtx prev > > Fixing all that is not in the cards for gcc 4.2, so for the nonce we > allow all eh insns to evaporate. */ > - gcc_assert (trap_count <= 1); > + gcc_assert (!internal_throw || trap_count <= 1); > } > > /* Reload pseudo-registers into hard regs around each insn as needed. Won't this break a disabled checking build since internal_throw will become unused? -- Thanks, Jim http://www.csclub.uwaterloo.ca/~ja2morri/ http://phython.blogspot.com http://open.nit.ca/wiki/?page=jim
Successfull build of gcc-4.0.1 on hppa2.0w-hp-hpux11.00
-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/bin/ld --enable-threads=single --disable-shared - --disable-nls --with-gmp=/appl/shared/gnu/HP-UX/hppa2.0w-hp-hpux11.00 - --with-mpfr=/appl/shared/gnu/HP-UX/hppa2.0w-hp-hpux11.00 - --enable-languages=c,c++,f95,java,objc binutils: binutils-2.16.1 Build system: HP-UX c3600-1 B.11.00 A 9000/785 unknown unknown HP-UX cc for building: gcc -mpa-risc-2-0 gcc (GCC) 4.0.1 Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. as for building: GNU assembler 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of \`hppa2.0w-hp-hpux11.00'. ld for building: 92453-07 linker command s800.sgs ld PA64 B.11.43 REL 050124 /usr/ccs/bin/ld: Usage: /usr/ccs/bin/ld [options] [flags] files /usr/ccs/bin/ld: 92453-07 linker linker ld B.11.43 050125 testresults: http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00298.html - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDHUUv3s6elE6CYeURAumqAKCCIQ8Ar0aIt99o9kePRD8+jHN5JQCePRPS SRuqsmxVy6XzQupPZbPty7E= =4ceg -END PGP SIGNATURE-
Successfull build of gcc-4.0.1 on mips-sgi-irix6.5
-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/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/ld - --disable-shared --enable-threads=single --enable-haifa --disable-nls - --disable-libmudflap --with-gmp=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5 - --with-mpfr=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5 - --enable-languages=c,ada,c++,objc binutils: binutils-2.16.1 Build system: IRIX64 octane-3 6.5 10070055 IP30 mips unknown Irix cc for building: gcc gcc (GCC) 4.0.1 Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. as for building: GNU assembler 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of \`mips-sgi-irix6.5'. ld for building: GNU ld version 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. testresults: http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00299.html - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDHUWI3s6elE6CYeURAmANAJ9hMJNYDLyHFKduzDKS+gzoSlt1dACgkefN 4/ZRc8LU3P7aklNLnfODPIw= =ghfN -END PGP SIGNATURE-
Question about simplify_rtx ()
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 with INSNs and SETs? Will a generalized function called simplify_insn () that uses simplify_rtx () be accepted? Thanks, Leehod.
Re: Question about simplify_rtx ()
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 () that uses simplify_rtx () be accepted? I am no authority, but I think so. Paolo
Re: DCE eliminating valid statement for ACATS c34007p
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 = 1; > # VUSE ; > VIEW_CONVERT_EXPR(*D.861).l = 3; > > There last two statements are confusing to me. First of all, why isn't > the *D.861 in SSA form? But more importantly, those statements are > modifying memory, but there's no V_MAY_DEF operand. Why not? > > I'm stepping through update_ssa_operands but can't figure out exactly > where it's supposed to be written here. 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"? Richard.
Re: DCE eliminating valid statement for ACATS c34007p
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 = 1; > # VUSE ; > VIEW_CONVERT_EXPR(*D.861).l = 3; 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 course the gimplifier could do this transformation. Richard.
Re: Question on vrp_meet in tree-vrp.c
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 contain zero. But wouldn't [1,32] be a better > result? yes, [1, 32] is included in [MIN_type, MAX_type] - [0,0] and thus it is more precise.
Re: S/390 Bootstrap failure due to fixup_eh_region_note
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
Re: DCE eliminating valid statement for ACATS c34007p
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"?
A couple of hours after sending my email, I figured out what happened.
The reason why D.861 was not in SSA form was that it was TREE_ADDRESSABLE
and everything else was due to that.
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.
If I put code in the language-specific gimplifier to do:
/* 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 needs to know the variable is
addressable at this point. This duplicates code in
internal_get_tmp_var, which is unfortunate. */
else if (TREE_CODE_CLASS (TREE_CODE (op)) != tcc_reference
&& TREE_CODE_CLASS (TREE_CODE (op)) != tcc_declaration
&& TREE_CODE_CLASS (TREE_CODE (op)) != tcc_constant)
{
tree new_var = create_tmp_var (TREE_TYPE (op), "A");
tree mod = build (MODIFY_EXPR, TREE_TYPE (op), new_var, op);
TREE_ADDRESSABLE (new_var) = 1;
if (TREE_CODE (TREE_TYPE (op)) == COMPLEX_TYPE)
DECL_COMPLEX_GIMPLE_REG_P (new_var) = 1;
if (EXPR_HAS_LOCATION (op))
SET_EXPR_LOCUS (mod, EXPR_LOCUS (op));
gimplify_and_add (mod, pre_p);
TREE_OPERAND (expr, 0) = new_var;
recompute_tree_invarant_for_addr_expr (expr);
return GS_ALL_DONE;
}
it all works. Whether this should be here or in gimplify.c is a matter
mostly of philosphy. I don't care for the duplication of code in
internal_get_tmp_var from a maintainability point of view and that argues for
adding an "addressable" parameter to the routine and calling it that way from
gimplify_addr_expr. The counter argument is that this tree is only made by
Ada, so it should be done within the Ada front end. 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 handled by the
gimplifier.
It would also be good to put an assert into the gimplifier that detects the
case where one of its variable is suddenly marked addressable since that
meant it produced invalid gimple earlier, but since we have no flag to denote
such, I don't think we can do it now.
Are there are feelings about where this code should go? My preference
is gimplify.c, but if there are strong feelings the other way, I'm OK
with leaving it where it is now.
Re: DCE eliminating valid statement for ACATS c34007p
> # 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 course the gimplifier could do this transformation. This falls out of general-purpose code in the front-end and I think you're right that the gimplifier could (and should) do this transformation.
Re: DCE eliminating valid statement for ACATS c34007p
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 > handled by the gimplifier. I don't think we ever defined "valid GENERIC" that way. If we had done that, the C and C++ front ends wouldn't have had to be converted to make them produce valid GENERIC. So IMHO your code should just be Ada specific. Gr. Steven
Store-copyprop not very bright
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 apparently it doesn't. So, Diego, is this a real bug
in store-copyprop or am I expecting too much of your pass here?
Gr.
Steven
Re: DCE eliminating valid statement for ACATS c34007p
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 definition can answer the question of whether or not something is valid. If we had done that, the C and C++ front ends wouldn't have had to be converted to make them produce valid GENERIC. I'm talking about *expressions* and I think you're talking about statements.
Re: DCE eliminating valid statement for ACATS c34007p
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 what is and is not valid GENERIC. At > least the proposed definition can answer the question of whether or not > something is valid. 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 ... Richard.
Re: DCE eliminating valid statement for ACATS c34007p
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*? The problem is that | > we have no document that says what is and is not valid GENERIC. At | > least the proposed definition can answer the question of whether or not | > something is valid. | | 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 ... And the potential "bugs in the gimplifier" are precisely the reasons why that definition isn't helfpul. Why in this case, Kenner's problem isn't one of those potential "bugs in the gimplifier"? -- Gaby
Re: DCE eliminating valid statement for ACATS c34007p
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 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 definition can answer the question of whether or > | > not something is valid. > | > | 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 ... > > And the potential "bugs in the gimplifier" are precisely the reasons > why that definition isn't helfpul. Why in this case, Kenner's problem > isn't one of those potential "bugs in the gimplifier"? 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 you have it: a well known problem in the Ada front end, not a bug in the gimplifier. Gr. Steven
Re: Store-copyprop not very bright
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
Re: DCE eliminating valid statement for ACATS c34007p
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 determine whether it's not valid GENERIC or whether the gimplifier has a bug? Using a tautology as the definition isn't helpful in that process.
Re: DCE eliminating valid statement for ACATS c34007p
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 you have it: a well known problem in the Ada front end, not a bug in the gimplifier. No, I meant "well known" as in "we've discussed it here before". There's certainly no problem with an ADDR_EXPR of a COMPOUND_EXPR conceptually. In C form, & (some_function (), foobar) makes perfect sense and is equivalent to (some_function (), &foobar). Indeed the case that was discussed on the list was an ADDR_EXPR of a CONSTRUCTOR. Here, the case is an ADDR_EXPR of a COMPOUND_EXPR whose result is a SAVE_EXPR. 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.
Re: DCE eliminating valid statement for ACATS c34007p
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 needs to know the variable is
> addressable at this point. This duplicates code in
> internal_get_tmp_var, which is unfortunate. */
> else if (TREE_CODE_CLASS (TREE_CODE (op)) != tcc_reference
>&& TREE_CODE_CLASS (TREE_CODE (op)) != tcc_declaration
>&& TREE_CODE_CLASS (TREE_CODE (op)) != tcc_constant)
> {
> tree new_var = create_tmp_var (TREE_TYPE (op), "A");
> tree mod = build (MODIFY_EXPR, TREE_TYPE (op), new_var, op);
>
> TREE_ADDRESSABLE (new_var) = 1;
> if (TREE_CODE (TREE_TYPE (op)) == COMPLEX_TYPE)
> DECL_COMPLEX_GIMPLE_REG_P (new_var) = 1;
>
> if (EXPR_HAS_LOCATION (op))
> SET_EXPR_LOCUS (mod, EXPR_LOCUS (op));
>
> gimplify_and_add (mod, pre_p);
> TREE_OPERAND (expr, 0) = new_var;
> recompute_tree_invarant_for_addr_expr (expr);
> return GS_ALL_DONE;
> }
Can't you use get_initialized_tmp_var, then?
--
Giovanni Bajo
Re: DCE eliminating valid statement for ACATS c34007p
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. | > | > | > | > 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 definition can answer the question of whether or | > | > not something is valid. | > | | > | 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 ... | > | > And the potential "bugs in the gimplifier" are precisely the reasons | > why that definition isn't helfpul. Why in this case, Kenner's problem | > isn't one of those potential "bugs in the gimplifier"? | | Because it doesn't make sense to take the address of a COMPOUND_EXPR | for example? that precisely is the sort of things that need be put in the definition what is a a valid GENERIC, as opposed to the the definition offered in the message I was replying to. | 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." but you forgot the other half of his message which triggers the discussion. -- Gaby
Re: DCE eliminating valid statement for ACATS c34007p
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.
Re: DCE eliminating valid statement for ACATS c34007p
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 sense on something that is addressable, and a COMPOUND_EXPR is not addressable, even if, as in your example, the language semantics explain how the & is to be interpreted. IMHO for GENERIC we should only allow ADDR_EXPRs to appear on addressable things (i.e. addressable symbols). Gr. Steven
Re: DCE eliminating valid statement for ACATS c34007p
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 "addressable". Clearly a STRING_CST is, but is an INTEGER_CST? 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 has all the logic already to do that, so why shouldn't it? 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 expressable trees is the job of the front end and for others is the job of the gimplifier? Why not just be consistent and say it's the gimplifier's job to do all of them?
Re: DCE eliminating valid statement for ACATS c34007p
> 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 has all > the logic already to do that, so why shouldn't it? > > 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 expressable trees is the job of the front > end and for others is the job of the gimplifier? Why not just be > consistent and say it's the gimplifier's job to do all of them? But only where the semantics are well defined. I can think of several different possible semantics for talking the address of arbitrary things. Consider "foo(&(a+b), &(a+b))" Is it ok to pass the same address for both arguments? Should the location pointed to be modifiable or readonly? IMHO it's best to make things like this explicit. That way there's no disagreement over which language defined semantics we should be using. Paul
Re: DCE eliminating valid statement for ACATS c34007p
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. IMHO it's best to make things like this explicit. That way there's no disagreement over which language defined semantics we should be using. What about case like taking an ADDR_EXPR of a COMPONENT_REF where the field is a bitfield? Trying to over-specify things can get quite complex as well.
Re: DCE eliminating valid statement for ACATS c34007p
[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 expressable trees is the job of the front end and for | others is the job of the gimplifier? Why not just be consistent and say it's | the gimplifier's job to do all of them? I tend to agree with Kenner's point. However, we must also ensure that some language s[ecific constructs -- temporary lifetime, etc -- are properly dealt with front-ends so that (1) we don't "bloat" the gimplifier; (2) updates to the gimplifier are language-neutral. -- Gaby
Re: DCE eliminating valid statement for ACATS c34007p
> 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. We've seen many times before, often with the ADA frontend, that "don't care" is often not what the language frontend really wants. Different people have different ideas about exactly which subset of semantics are required, and which are allowed to be changed. > IMHO it's best to make things like this explicit. That way there's no > disagreement over which language defined semantics we should be using. > > What about case like taking an ADDR_EXPR of a COMPONENT_REF where the > field is a bitfield? Trying to over-specify things can get quite complex > as well. That's my point. We shouldn't be trying to support this sort of language specific weirdness in generic code. Unless you have bit-addressable memory/pointers and arbitrary bit-sized types, taking the address of a bitfield makes no sense. It's up to the frontend to transform it into something sane. Paul
Re: S/390 Bootstrap failure due to fixup_eh_region_note
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~
Re: DCE eliminating valid statement for ACATS c34007p
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 code in > internal_get_tmp_var from a maintainability point of view ... Well, since you essentially shouldn't have used ought but create_tmp_var, that point is moot. r~
Re: DCE eliminating valid statement for ACATS c34007p
>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 where is that flag cleared when TREE_ADDRESSABLE is set? I can't find anything that ever clears it? Well, since you essentially shouldn't have used ought but create_tmp_var, that point is moot. No, there's still the location stuff, which does still seem relevant.
Re: glibc or newlib for mips-elf?
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 mips-elf, but rather mips-linux-gnu. For that target, glibc or uclibc is appropriate. (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.) Ian
Re: var_args for rs6000 backend
"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 ,rs6000_va_start > ,rs6000_gimplify_va_arg . > > I could not know what they do just by source code. Could anybody > tell me the relationship among these routines? I think it is > important for me to understand the mechnism of GCC backend. Any > comments or advice are highly appreciate. These are partially documented in gcc/doc/tm.texi. Unfortunately the documentation is not particularly good. These functions are all oriented around C stdarg.h functions. In brief, setup_incoming_varargs is called for a function which takes a variable number of arguments, and does any required preparation statements. build_builtin_va_list builds the va_list data type. va_start is called to implement the va_start macro. gimplify_va_arg is called to implement the va_arg macro. > I do not know what is the precondation if I want to do it? May I need > to know the architecture of PowerPC and ABI for it? You do indeed need to know the PowerPC ABIs to understand what these routines are doing and why. Ian
RE: var_args for rs6000 backend
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] On Behalf Of Ian Lance Taylor Sent: Tuesday, September 06, 2005 2:06 PM To: Yao qi Cc: gcc@gcc.gnu.org Subject: Re: var_args for rs6000 backend "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 ,rs6000_va_start > ,rs6000_gimplify_va_arg . > > I could not know what they do just by source code. Could anybody > tell me the relationship among these routines? I think it is > important for me to understand the mechnism of GCC backend. Any > comments or advice are highly appreciate. These are partially documented in gcc/doc/tm.texi. Unfortunately the documentation is not particularly good. These functions are all oriented around C stdarg.h functions. In brief, setup_incoming_varargs is called for a function which takes a variable number of arguments, and does any required preparation statements. build_builtin_va_list builds the va_list data type. va_start is called to implement the va_start macro. gimplify_va_arg is called to implement the va_arg macro. > I do not know what is the precondation if I want to do it? May I need > to know the architecture of PowerPC and ABI for it? You do indeed need to know the PowerPC ABIs to understand what these routines are doing and why. Ian
linking on Solaris
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
Re: DCE eliminating valid statement for ACATS c34007p
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 already have been set by the front end for all variables. The gimplifier never sets TREE_ADDRESSABLE on existing variables. r~
Re: DCE eliminating valid statement for ACATS c34007p
The gimplifier never sets TREE_ADDRESSABLE on existing variables. It certainly calls mark_addressable in various places, so I don't follow.
Re: glibc or newlib for mips-elf?
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 mipsel-linux-gnu targeted cross compiler. Different toolchains for user and kernel code are not necessary. David Daney.
Re: DCE eliminating valid statement for ACATS c34007p
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 preceeding statements. At least for variables whose type satisfies is_gimple_reg_type. r~
Re: DCE eliminating valid statement for ACATS c34007p
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 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?
existing functionality questions
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 a) {...}
In this example, foo can obviously access private_var but bar cannot. When
examining function arguments, what is the accepted practice for finding
out what members the function may access in the structure.
Thanks in advance,
Mike Tegtmeyer
Re: DCE eliminating valid statement for ACATS c34007p
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-generated got to do with it? r~
Re: DCE eliminating valid statement for ACATS c34007p
> 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-generated, then we know it was assumed to not be addressable, but I guess you're right: setting *any* variable that would potentially have already been used in gimple as an operand to be addressable is a potential bug. I'm wondering why verify_ssa doesn't detect this. After all, it means we have an operand that's not a gimple reg.
Re: DCE eliminating valid statement for ACATS c34007p
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 needed, and so the TREE_ADDRESSABLE bit is reliable incoming to the gimplifier. r~
Re: DCE eliminating valid statement for ACATS c34007p
> 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_addressable when needed, and so the TREE_ADDRESSABLE bit is reliable incoming to the gimplifier. Right, but there are a few cases where the gimplifier calls it itself and I suspect you're right that each are suspect.
Re: pr 22207: Spurious 'might be used uninitialized' warnings
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 STL > headers, but only at -O2 and above. This makes building with "-Wall > -Werror" impossible without having to disable some warnings. > > The problem occurs with gcc 3.4.4 and is a regression from 3.3.3, which > worked fine. The PR includes a testcase that reproduces it under Cygwin > but not Linux, so it very well may be something that is > Cygwin-specific. If you need any further information please let me > know. I took a look at this PR. I don't see any immediate fix. The exception handling code is introducing branches in which the values are used without being initialized. Since this doesn't happen for GNU/Linux, I would guess that this is related to the setjmp/longjmp exceptions which are used on Cygwin. But I don't know for sure. Since this test case works in the current sources, and since it is only a warning which can be turned off using -Wno-uninitialized, I'm not going to look at it further. Sorry. Ian
gcc-3.4-20050906 is now available
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 find: gcc-3.4-20050906.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20050906.tar.bz2 C front end and core compiler gcc-ada-3.4-20050906.tar.bz2 Ada front end and runtime gcc-g++-3.4-20050906.tar.bz2 C++ front end and runtime gcc-g77-3.4-20050906.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20050906.tar.bz2 Java front end and runtime gcc-objc-3.4-20050906.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20050906.tar.bz2The GCC testsuite Diffs from 3.4-20050830 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Language Changes in Bug-fix Releases?
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.
Re: existing functionality questions
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_member would be a useful routine to set a breakpoint on and watch how it does it as well. If that doesn't answer your question, I predict there exists another question which you'd love to ask us, but haven't, try asking that one instead (I call this the real question).
Re: Language Changes in Bug-fix Releases?
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 tightenings | on other than x.y.0 releases. I hear you. In this specific case, it worths remembering people that the issue is not just an accept-invalid that was turned into reject-invalid, but wrong-code generation (in the sense that wrong-code was being genereted for *valid* program) that was fixed. C++ appears to be part of that small class of languages where an accept-invalid can hide a wrong-code -- Gaby
glibc or newlib for mips-elf?
>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 ISA. We need to port binutils and gcc and also library. Thanks again. Eric
Re: glibc or newlib for mips-elf?
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 for an elf based operating system. What about the mips port made you decide that you wanted to use that as a guideline? -eric
Re: glibc or newlib for mips-elf?
> 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 familiar with mips. Also, the binutils was ported just use mips-elf as start. I hope it is all right with gcc and glibc. :-) Regards. Eric
Re: Extending functionality of -frepo
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 instantiate items as determined by the database. It is a known waste of compile time to not so instantiate such things, as we know they will be instantiated. So, the entire concept doesn't make much sense to me, unless you only are only interested in the speedup from those units that don't use any definitions. Now, if we know that no definition is needed in a file, having it disappear the definitions is enticing, but after you benchmark it against pch, I suspect you'll wonder why you bothered. 1. Code in foo.cpp normally compiles without including big_header.h (from bar.tpp). This makes it impossible for foo.cpp to become inadvertently dependant on the code from big_header.h. One can already reap this benefit by the #ifdef/-D during compilation, so I don't see any benefit. 2. Compilation of foo.cpp and every source file that includes bar.h is much faster since the implementation of bar.tpp is not seen by the compiler. Likewise. 3. Definitions for the bar class template and the big_header are only compiled by collect2 during template instantiations. If bar is commonly used in the code, compilation times would be significantly reduced. Reduced when compared to pch? With pch, all the common things are instantiated once, and only once for the entire project build. I suspect compilation time would not be reduced. One thing that might be interesting would be to have -frepo take an argument that names a file that is the database for the application, so that the decisions can be made up front and eliminate the need to recompile. This improves the 1st compile time and doesn't alter the incremental time.
Question regarding compiling a toolchain for a Broadcom SB1
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 attempting to build a cross-compiler (with a host of a Pentium 4 also running Linux). I've run through the various FAQs, HOWTOs and automated scripts, but they either don't do the combination I want or they won't work with the combination I want. A query on the MIPS mailing list produced a depressing result - one reply, saying they weren't sure it could even be done. The various Linux distros for MIPS architectures were not a whole lot better - the most recent were 32-bit and even those weren't that recent. The newest MIPS64 binary of GCC I could find was back in the 2.95 era. My question is simple enough - has anyone built a toolchain for a MIPS64-Linux-GNU target? I noticed someone posting recently that they'd conquered this problem for MIPS64 under the IRIX OS, so I'm guessing it must be possible under Linux. 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. Jonathan Day __ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/
Re: Question regarding compiling a toolchain for a Broadcom SB1
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. That said, for building from source I'd try Dan Kegel's crosstool script. That's what most people use. If you're still having problems let me know - perhaps it's something obvious. -eric
Re: Language Changes in Bug-fix Releases?
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, so someone figured out it was an issue for him/her. Furthermore, your customers represent only a fraction of the GNU C++ community which is very diverse -- that is not meant to diminish their importance, but it worths keeping in mind the community is diverse. -- Gaby
Re: Language Changes in Bug-fix Releases?
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.
Re: Language Changes in Bug-fix Releases?
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 them feels slightly more real. Yes, but someone else was silently failing, I'd rather know my code was crap up front. -eric
RE: var_args for rs6000 backend
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 need to study the AIX ABI
as well as the System V/eabi ABIs, and possibly other ABIs that are now
used).
First, thanks for you suggestions.
Yes, I found there are at least *three* ABIs in gcc/config/rs6000/rs6000.c,
205 /* ABI enumeration available for subtarget to use. */
206 enum rs6000_abi rs6000_current_abi;
And in gcc/config/rs6000/rs6000.h, I found the defination,
1223 /* Enumeration to give which calling sequence to use. */
1224 enum rs6000_abi {
1225 ABI_NONE,
1226 ABI_AIX, /* IBM's AIX */
1227 ABI_V4, /* System V.4/eabi */
1228 ABI_DARWIN/* Apple's Darwin (OS X kernel) */
1229 };
I just have to concentrate on ABI_V4 if I work on gcc develoment on
powerpc-linux, am I right ?
I have traced cc1 and found DEFAULT_ABI in setup_incoming_varargs() is
ABI_V4.
Best Regards
Yao Qi
Bejing Institute of Technology
_
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
Re: var_args for rs6000 backend
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 Technology Centre
some seemingly redundant register uses in nios gcc compiled assembly code
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(1072693248)
addir5, r5, %lo(1072693248)
mov r16, r2
mov r17, r3
callatan
mov r5, r3
mov r4, r2
mov r6, zero
movhi r7, %hiadj(1074790400)
addir7, r7, %lo(1074790400)
call__muldf3
mov r10, r2
mov r5, r17
mov r6, r10
mov r7, r3
mov r4, r16
In .c.26.flow2 file,
(call_insn 23 19 28 0 0x0 (parallel [
(set (reg:DF 2 r2)
(call (mem:QI (symbol_ref:SI ("atan")) [0 S1 A8])
(const_int 0 [0x0])))
(clobber (reg:SI 31 ra))
]) 44 {*call_value} (insn_list 21 (nil))
(expr_list:REG_DEAD (reg:DF 4 r4)
(expr_list:REG_UNUSED (reg:SI 31 ra)
(nil)))
(expr_list (use (reg:DF 4 r4))
(nil)))
.
(call_insn/u 31 30 36 0 0x0 (parallel [
(set (reg:DF 2 r2)
(call (mem:QI (symbol_ref:SI ("__muldf3")) [0 S1 A8])
(const_int 0 [0x0])))
(clobber (reg:SI 31 ra))
]) 44 {*call_value} (insn_list 27 (insn_list 29 (nil)))
(expr_list:REG_DEAD (reg:DF 4 r4)
(expr_list:REG_DEAD (reg:DF 6 r6)
(expr_list:REG_UNUSED (reg:SI 31 ra)
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil)
(expr_list (use (reg:DF 6 r6))
(expr_list (use (reg:DF 4 r4))
(nil
>From the RTL we can see that these two calls don't use r5, but why
here both assembly codes and rtl have some codes with r5, like
movhi r5, %hiadj(1072693248)
addir5, r5, %lo(1072693248)(move 32-bit constant into
register)
and
mov r5, r3
In nios2, r2 and r3 are for return value. r4, r5, r6, r7 are for
registre auruments
Does the following rtl implicitly indicate that r5 is used?
(expr_list (use (reg:DF 6 r6))
(expr_list (use (reg:DF 4 r4))
Thanks.
Regards,
Haibin
Re: some seemingly redundant register uses in nios gcc compiled assembly code
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 showed--then (use (reg:DF 4 r4)) does indeed indicate a case of r5. It indicates a use of all registers from 4 up to but not including register number 4 + HARD_REGNO_NREGS (4, DFmode) Ian
