Re: Running ranlib after installation - okay or not?
On Thu, 1 Sep 2005, Peter O'Gorman wrote: > Another alternative would be to set RANLIB=: before configure if your > system does not need to ranlib anything. Thanks for the nice hint - this is what the FreeBSD Ports Collection now uses for the lang/gcc34 to lang/gcc41 ports. ;-) On Fri, 2 Sep 2005, Peter O'Gorman wrote: > Doesn't matter, the solution I applied to GNU libtool cvs last night is > probably most appropriate, i.e. chmod 644 before ranlib. I guess I'll look > at gcc cvs over the weekend to figure out where that would go in your tree. Cool, thanks! Gerald
S/390 Bootstrap failure due to fixup_eh_region_note
Hello Richard,
s390 and s390x can't bootstrap with the following patch, because the new
assertion
introduced with the fixup_eh_region_note function is triggered.
http://gcc.gnu.org/ml/gcc-cvs/2005-08/msg01022.html
2005-08-31 Richard Henderson <[EMAIL PROTECTED]>
PR rtl-opt/23601
* reload1.c (reload): Set MEM_NOTRAP_P in spill slots.
(fixup_eh_region_note): New.
(reload_as_needed): Call it.
(fixup_abnormal_edges): Allow all throwing insns to be deleted;
don't call find_many_sub_basic_blocks; call verify_flow_info.
* function.c (assign_stack_local_1): Set MEM_NOTRAP_P.
(keep_stack_depressed): Likewise.
(assign_stack_temp_for_type): Likewise; use adjust_address_nv.
Before reload we have the following insn containing two MEMs which may
trigger a trap:
(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])) 52 {*movsi_esa}
(insn_list:REG_DEP_TRUE 29 (nil))
(expr_list:REG_DEAD (reg:SI 55)
(expr_list:REG_DEAD (reg:SI 56)
(expr_list:REG_DEAD (reg/v/f:SI 47 [ env ])
(expr_list:REG_EH_REGION (const_int 2 [0x2])
(nil))
Reload adds a new insn reloading one of the MEMs resulting in two insns
which may trap:
(insn 75 29 31 5 (set (reg:SI 2 %r2)
(mem/f:SI (plus:SI (plus:SI (reg:SI 2 %r2 [55])
(reg:SI 1 %r1 [56]))
(const_int 4092 [0xffc])) [0 S4 A32])) -1 (nil)
(expr_list:REG_EH_REGION (const_int 2 [0x2])
(nil)))
(insn 31 75 49 5 (set (mem/s/j:SI (plus:SI (reg/v/f:SI 12 %r12 [orig:47 env ]
[47])
(const_int 4 [0x4])) [0 .ex+0 S4 A32])
(reg:SI 2 %r2)) 52 {*movsi_esa} (insn_list:REG_DEP_TRUE 29 (nil))
(expr_list:REG_DEAD (reg:SI 2 %r2 [55])
(expr_list:REG_DEAD (reg:SI 1 %r1 [56])
(expr_list:REG_DEAD (reg/v/f:SI 12 %r12 [orig:47 env ] [47])
(expr_list:REG_EH_REGION (const_int 2 [0x2])
(nil))
Hence the trap_count in fixup_eh_region_note is set to 2 which triggers the
assertion
at the end of that function. So it seems the assertion is too strict here.
The problem occurs when libjava/jni.cc is compiled. If you need a testcase I
will try
to reduce the huge preprocessed file as far as possible.
Bye,
-Andreas-
Re: Incorrect use of anti-dependency to order instructions in the DFA scheduler
Hi all, In the end I modified TARGET_SCHED_ADJUST_COST to increase the cost of anti-dependencies between a jump and another instruction, to prevent them from being scheduled in the same cycle. This fix works well. It still allows other independent instructions to be scheduled into the same VLIW packet as a branch, allowing effective schedules to be generated. Thanks for your help. dan. ** Ian Lance Taylor wrote: Daniel Towner <[EMAIL PROTECTED]> writes: I maintain a port for a 16-bit VLIW machine, and I have encountered a problem with the DFA instruction scheduler. Consider the following two instructions: BNE someLabel STW R5,(R3) 0 // Mem[R3] := R5 The second instruction will only be executed if the branch isn't taken. However, when I switch on the DFA scheduler, the memory store is scheduled in the same cycle as the branch, using VLIW: BNE someLabel\STW R5,R3(0) which obviously changes the meaning of the code, as the store is now always performed, whereas previously it was conditional. I believe that this incorrect schedule is caused because an anti-dependence is used to enforce the ordering of the two instructions, and a VLIW machine allows anti-dependent instructions to be scheduled in the same cycle. I have attached the RTL code showing this anti-dependency below. You unfortunately can't rely on the DFA scheduler to do proper VLIW instruction bundling. The scheduler thinks that every instruction runs separately. It doesn't understand the notion of two or more instructions running in parallel. The scheduler also doesn't understand that in a typical VLIW machine every instruction slot must be occupied by an instruction, even if only a NOP. You generally have to do actual instruction bundling in a separate machine dependent pass which tracks dependencies when deciding whether to bundle instructions. This is slightly awkward when bundling instructions with a branch instruction at the start of a bundle. In the output of the scheduler, the instructions which follow the branch are expected to be executed after the branch. One technique to get around this (other than doing a lot of rescheduling in the bundling pass) is to use define_delay to pretend that branch instructions have a delay slot. The delay slot filling pass will then find instructions whose dependencies permit them to be bundled with a branch instruction. Your bundling pass will then find them in the right place to bundle them--i.e., just after the branch instruction. Ian -- Daniel Towner picoChip Designs Ltd, Riverside Buildings, 108, Walcot Street, BATH, BA1 5BG [EMAIL PROTECTED] +44 (0) 7786 702589
Re: S/390 Bootstrap failure due to fixup_eh_region_note
On Sep 5, 2005, at 8:27 AM, Andreas Krebbel wrote: Hello Richard, s390 and s390x can't bootstrap with the following patch, because the new assertion introduced with the fixup_eh_region_note function is triggered. Note this is recorded as PR 23711. Thanks, Andrew Pinski
libssp missing from CVS
Hello! libssp subdir is present in cvs (checked on savannah) but cvs -q upd does not get it. Is it a cvs-server failure or something on my side? Thanks, Peter -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: libssp missing from CVS
On Sep 5, 2005, at 11:35 AM, Peter S. Mazinger wrote: Hello! libssp subdir is present in cvs (checked on savannah) but cvs -q upd does not get it. Is it a cvs-server failure or something on my side? You want to update with "cvs -q up -d -P", -d is required to get the new directories. -- Pinski
Re: libssp missing from CVS
On Mon, 5 Sep 2005, Andrew Pinski wrote: > > On Sep 5, 2005, at 11:35 AM, Peter S. Mazinger wrote: > > > Hello! > > > > libssp subdir is present in cvs (checked on savannah) but cvs -q upd > > does > > not get it. Is it a cvs-server failure or something on my side? > > You want to update with "cvs -q up -d -P", -d is required to get the new > directories. I had update -dP in .cvsrc, but it seems it is not interpreted, I'll try it on the commandline, thx Peter -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: libssp missing from CVS
On Monday 05 September 2005 17:35, Peter S. Mazinger wrote: > Hello! > > libssp subdir is present in cvs (checked on savannah) but cvs -q upd does > not get it. Is it a cvs-server failure or something on my side? cvs upd -d -P ? Or better yet: contrib/gcc_update Gr. Steven
Re: RFC ping: Make regname use validate_change
in http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01489.html I've described a problem where regrename renamed a general register creating an insn which does not satisfy the insn predicate anymore. I agree that regrename shouldn't make such replacements. Constraints are important to drive reload, and sometimes you need an insn predicate on top to verify that the operands of the insn agree. (Until recently insn predicates were also needed to handle rare special cases that could not be expressed in constraints because we ran out of distinct letters. ) Creating single-register classes is not a panacea, as it not only can lead to exponential growth of the number of patterns, but also changes REGNO_REG_CLASS, makes you rewrite all your secondary / tertiary reload code, and it marks every single register as likely spilled, thus pessimizing register allocation. As a compromise I've suggested to just call the insn predicate. This will still call all the "TARGET_FOO" predicates. These are basically static predicates that won't change once a set of options have been chosen. We are only interested in the insn predicates which vary in value depending on the instruction under consideration. I think the best balance between performance impact and sanity of the description language can be archived by having one of the gen* programs check if the predicate mentions insn and/or some of the operands, and/or an attribute that depends on the insn. On the other hand, the "TARGET_FOO" predicates tend to be cheap. If we have genattrtab generate a function to tell us if the insn predicate matters, that function will likely cost more than evaluating a simple predicate. A saving seems only plausible if we use a lookup table instead, i.e. avoid a change of control flow. So, on balance, I think that calling the insn predicate (if it set) is probably the best solution.
Question on vrp_meet in tree-vrp.c
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 result?
Question on vrp_meet in tree-vrp.c
[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?
Re: Question on vrp_meet in tree-vrp.c
On Monday 05 September 2005 23:26, Richard Kenner wrote: > 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 > result? I would hope VR_VARYING...? Gr. Steven
Possible bug in tree-vrp.c:vrp_visit_phi_node
Suppose lhs_vr is [64,64] and vr_result is ~[0,0]. It would seem that the code near the end of this function will malfunction. Shouldn't the test be that both lhs_vr *and* vr_result are VR_RANGE? This is causing an ACATS failure in c45651a and possibly others.
More on vrp_meet
Why doesn't it use fold-const.c:merge_ranges instead of having a subset of that code?
Re: S/390 Bootstrap failure due to fixup_eh_region_note
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. r~
glibc or newlib for mips-elf?
hi, Would you tell me which I should select to port for the new target? The new target is like mips-elf. But I was told that glibc doesn't support mips-elf well. Is it right? Thanks for your help. Eric
DCE eliminating valid statement for ACATS c34007p
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.
Re: glibc or newlib for mips-elf?
On Tue, Sep 06, 2005 at 09:48:18AM +0800, Eric Fisher wrote: > hi, > > Would you tell me which I should select to port for the new target? > The new target is like mips-elf. But I was told that glibc doesn't > support mips-elf well. Is it right? Glibc is a C library for (mostly) GNU/Linux targets. If you aren't running a hosted kernel on your board port, then you should probably be using newlib instead. -- Daniel Jacobowitz CodeSourcery, LLC
glibc or newlib for mips-elf?
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. Eric
Re: S/390 Bootstrap failure due to fixup_eh_region_note
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.
Actually it looks like the tree EH lowering is not marking something
right as we get one BBs.
The reduced testcase is:
extern "Java" {
namespace java {
namespace lang {
class Class;
class Throwable;
}
}
}
typedef class java::lang::Class* jclass;
typedef class java::lang::Throwable* jthrowable;
typedef struct _Jv_JNIEnv JNIEnv;
struct _Jv_JNIEnv {
jthrowable ex;
};
class java::lang::Throwable {
static ::java::lang::Class class$;
};
void f(void);
void g (JNIEnv *env)
{
try {
f();
}
catch (jthrowable t) {
env->ex = t;
}
}
but we only get one BB containing the env->ex = t:
:;
D.1724 = (struct Throwable * *) <<>>;
env->ex = *(D.1724 - 4B);
Which is just wrong.
-- Pinski
var_args for rs6000 backend
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. 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? Any one could clarify it for me. Thanks in advance! Best Regards Yao Qi Bejing Institute of Technology _ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Re: S/390 Bootstrap failure due to fixup_eh_region_note
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.
pr 22207: Spurious 'might be used uninitialized' warnings
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. Thanks, Brian
Re: Question on vrp_meet in tree-vrp.c
[EMAIL PROTECTED] (Richard Kenner) writes: > [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, but this may require more thinking to ensure all the cases are correct. So, probably not something that will be done for 4.1. -- Thanks, Jim http://www.csclub.uwaterloo.ca/~ja2morri/ http://phython.blogspot.com http://open.nit.ca/wiki/?page=jim
A questions about NaN and Infinity in GCC
I am work on a floating points test according to IEEE754 and IEEE754 specifies
that seven invalid arithmetic operations shall deliver a NaN unless they are
trapped:
sqrt(Negative), 0*Infinity, 0.0/0.0, Infinity/Infinity, REMAINDER(Anything,0.0),
REMAINDER(Infinity, Anything), Infinity - Infinity.
I write a small case to verify part of this, and I list the source code here for
your reference,
1 #include
2
3 int main()
4 {
5 /* INF - INF => NaN. */
6 if ((__builtin_inf() - __builtin_inf()) != __builtin_nan(""))
7 printf("error 1\n");
8 /* 0 * INF => NaN. */
9 if ((0*__builtin_inf()) != __builtin_nan(""))
10 printf("error 2\n");
11 /* INF/INF => NaN. */
12 if ((__builtin_inf()/__builtin_inf()) != __builtin_nan(""))
13 printf("error 3\n");
14 /* INF + INF => INF. */
15 if ((__builtin_inf() + __builtin_inf()) != __builtin_inf())
16 printf("error 4\n");
17 if (0.0/0.0 != __builtin_nan(""))
18 printf("error 5\n");
19
20 return 0;
21 }
And I compile it like this:
[qiyao@ qiyao]$ gcc -o nan-3 nan-3.c
And run it,
[qiyao@ qiyao]$ ./nan-3
error 1
error 2
error 3
error 5
It seems that the result do not obey IEEE754. I am not so sure about it, Anyone
could confirm or deny this? Thanks in advance!
--
Regards, Yao
Yao Qi
Re: Question on vrp_meet in tree-vrp.c
Richard Kenner wrote on 06/09/2005 00:27:51:
> 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?
That can be tricky. Consider the following:
[-2147483648, -10] and [10, 2147483647]
You would like to get (assuming 32 bit signed integer)
~[-9,9] rather than [-2147483648, 2147483647].
When working with ranges, you may want to work with sorted
lists of ranges rather than with a simple range (this is what we
have been doing for years).
By using sorted lists of ranges, your example becomes:
(1) [1,1] ; [32,32]
And the complement list:
(2) ~ { [MIN,0] ; [2, 31] ; [33, MAX] }
When you convert these to a single range, you can choose the
best approximation:
(3) superset of the normal list (1):
[1,32] (as you proposed).
(4) Biggest subset of the complement list (2):
~[MIN,0]
(or maybe [33,MAX], or [2,31] depending on cost).
A heuristic cost function can be used to choose among alternatives.
The simplest heuristics is to find the representation that enlarges
the represented set as less as possible . Other things to consider
may be the presence of zero and other interesting values, or
range's mean (to be as close as possible to the original list of
ranges).
Michael
Re: A questions about NaN and Infinity in GCC
Yao Qi wrote on 06/09/2005 08:48:16:
> I am work on a floating points test according to IEEE754 and IEEE754
specifies
> that seven invalid arithmetic operations shall deliver a NaN unless they
are
> trapped:
> sqrt(Negative), 0*Infinity, 0.0/0.0, Infinity/Infinity,
REMAINDER(Anything,0.0),
> REMAINDER(Infinity, Anything), Infinity - Infinity.
>
> I write a small case to verify part of this, and I list the source code
here for
> your reference,
>1 #include
>2
>3 int main()
>4 {
>5 /* INF - INF => NaN. */
>6 if ((__builtin_inf() - __builtin_inf()) != __builtin_nan(""))
>7 printf("error 1\n");
>8 /* 0 * INF => NaN. */
[removed similar stuff]
> And run it,
> [qiyao@ qiyao]$ ./nan-3
> error 1
> error 2
> error 3
> error 5
>
> It seems that the result do not obey IEEE754. I am not so sure about it,
Anyone
> could confirm or deny this? Thanks in advance!
You missed one part of IEEE754. NaN is never equal to any value, including
itself.
You can test for NaN by doing the following (seemingly) absurd test:
3 int main()
4 {
5 double res;
5 /* INF - INF => NaN. */
6 res=__builtin_inf() - __builtin_inf();
7 if (res == res)
8 printf("error 1\n"); /* A NaN is always different from
itself*/
You can also use isnan(__buiting_inf()-__builtin_inf())
Michael
