All ARM compiler builds failing

Richard Earnshaw rearnsha@arm.com
Tue Feb 25 12:44:00 GMT 2003


> > 
> > Both native and cross building of all ARM configurations has been broken 
> > since this patch was installed:
> > 
> > Thu Feb 20 21:41:19 CET 2003  Jan Hubicka  <jh@suse.cz>
> > 
> >         * toplev.c (flag_sched2_use_superblocks, flag_sched2_use_traces): 
> > New
> >         global variables.
> >         (lang_independent_options):  Add -fsched2-use-superblocks
> >         -fsced2-use-traces.
> >         (rest_of_compilation): Deal with it.
> >         * invoke.texi (-fsched2-use-traces, fsched2-use-superblocks):  
> > Declare.
> >         * flags.h (flag_sched2_use_superblocks, flag_sched2_use_traces):
> >         Declare.
> >         * rtl.h (reg_to_stack):  Update prototype.
> >         * reg-stack.c (reg_to_stack): Return when something has changed;
> >         update liveness when executing after superblock scheduling.
> > 
> >         * combine.c (simplify_shift_const):  Simplify few special cases
> >         into constants.
> > 
> > See http://gcc.gnu.org/ml/gcc/2003-02/msg01521.html for some analysis.
> > 
> > Is there any prospect of a fix soon, or should we consider reverting this?
> 
> Sorry, somehow I assumed that this is already fixed by the
> unit-at-a-once patch.  Yesterday I noticed that it is indepdnent issue
> I've been trying to look into this last night.  I think Richard is most
> familiar with the conditional execution.  To me it looks like we need to
> recompute liveness entirely in case we want to have it exact for
> scheduling then.  It would be possible to re-arrange things so the
> dulpication happends before flow2 pass at small cost of code quiality.
> We can do that only for the condition executaion targets, or we can do
> that for all of them.  What is the preferred sollution?
> 
> Assumming that the conditional bits are only done by ifcvt and nothing
> else, the attached patch will likely help.  It fixed the testcase I
> have.  Can you please try to bootstrap it?
> 
> I apologize for the delay.

I'm now getting an error from this change when building the Thumb 
libraries :

2003-02-23  Kazu Hirata  <kazu@cs.umass.edu>

        * gcse.c (cprop_jump): Use the REG_EQUAL note if available.

Since the insn is

(insn 44 43 45 2 0x402db39c (set (reg:SI 64)
        (reg:SI 0 r0)) 205 {*thumb_movsi_insn} (nil)
    (insn_list:REG_RETVAL 41 (expr_list:REG_EQUAL (expr_list 
(symbol_ref:SI ("__eqdf2"))
                (expr_list (reg:DF 59)
                    (expr_list (reg/v:DF 50 [ invalue ])
                        (nil))))
            (nil))))

Note, I'm not immediately convinced that the above is valid, but this is 
where it blows up, since we end up looking for side-effects on an 
expr_list and running off the end (side_effects_p doesn't know how to walk 
a null-terminated expr_list)>

R.

cc1 -fpreprocessed ecvtbuf.i -quiet -dumpbase ecvtbuf.c -mthumb -mthumb 
-auxbase ecvtbuf -g -g -O2 -O2 -O2 -O2 -O2 -version -fno-builtin -o 
ecvtbuf.s


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecvtbuf.i.gz
Type: application/x-gzip
Size: 6047 bytes
Desc: ecvtbuf.i.gz
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20030225/d66cc0b6/attachment.bin>


More information about the Gcc mailing list