Paolo Bonzini <[EMAIL PROTECTED]> writes:
>>> In case of cris, the predicate goes into general_operand, which does
>>>
>>> if (CONSTANT_P (op))
>>> return ((GET_MODE (op) == VOIDmode || GET_MODE (op) == mode
>>> || mode == VOIDmode)
>>> && (! flag_pic || LEGITIMATE_PI
> As H-P says, the predicates on move expanders are generally ignored.
> emit_move_insn & subroutines deliberately don't check them.
It's even worse; force_reg is effectively hardcoding movXX's operand 1
to be a general_operand. (But my point was that force_reg does use
LEGITIMATE_CONSTANT_P thr
Hi All,
I am building a new gcc front-end based on the treelang example.
I recently updated my gcc local SVN repository.
When I compile my front-end I get the following errors:
../../svn/gcc/laurent/lex.l:6:8: error: attempt to use poisoned
"USE_MAPPED_LOCATION"
../../svn/gcc/laurent/lex.l:26:8: er
Adam Nemet wrote:
Maxim Kuvyrkov writes:
I'm not 100% sure about current state of things, considering recent
merge of sel-sched, but before that it was:
set_priorities() -> priority() -> dep_cost() -> recog_memoized().
I don't think that was the case for all insns even before the patch. The
> Date: Sat, 06 Sep 2008 15:14:46 +0200
> From: Paolo Bonzini <[EMAIL PROTECTED]>
> >> H-P can check for the problematic case inside his LEGITIMATE_CONSTANT_P
> >> (*), or add a move expander for it.
> >
> > I think you're mixing up CRIS and rs6000, the latter which
> > generated something it had
> "Laurent" == Lemaitre Laurent-R29173 <[EMAIL PROTECTED]> writes:
Laurent> Is-there a good (wiki) place where I can get some info on how
Laurent> to fix my issue with USE_MAPPED_LOCATION?
USE_MAPPED_LOCATION was removed. Only mapped locations remain.
So, you can fix your issue by removing t
> Only with a LEGITIMATE_CONSTANT_P catching it...
Of course.
> So, can we agree on some or all of:
>
> 1. This (PR37363/PR36182) and PR36090 (in both ports) and
>whatever other port will be affected should be solved by a
>stricter LEGITIMATE_CONSTANT_P check, and where
>canonicaliz
> Date: Sun, 07 Sep 2008 17:48:17 +0200
> From: Paolo Bonzini <[EMAIL PROTECTED]>
> > 3. Change the default of LEGITIMATE_CONSTANT_P to a helper
> >function, maybe trivial_constant_expression_p above.
>
> Agreed, but I don't see t_c_e_p in GCC sources
Of course not, as it's a *proposed* new
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> would in some cases be accurate.) I think using an unspec in rs6000
>> would solve some of the port-specific issues. In particular, I don't
>> think 36090 would have happened with an unspec representation.
>
> I agree. So your plan would be to change
On Sun, Sep 7, 2008 at 1:58 PM, Richard Sandiford
<[EMAIL PROTECTED]> wrote:
>> I agree. So your plan would be to change rs6000 to an unspec, and drop
>> the problematic hunk in simplify-rtx.c? That would be okay with me, but
>> it's not a small change for rs6000.
>
> Yeah, this is very much my p
"David Edelsohn" <[EMAIL PROTECTED]> writes:
> On Sun, Sep 7, 2008 at 1:58 PM, Richard Sandiford
> <[EMAIL PROTECTED]> wrote:
>>> I agree. So your plan would be to change rs6000 to an unspec, and drop
>>> the problematic hunk in simplify-rtx.c? That would be okay with me, but
>>> it's not a small
Hello All,
I have a wish: that each (middle-end) pass [those in gcc/tree-passes.h]
would have a small documentation describing it (in particular which
representations, TREE, SSA, CFG, etc... are valid after the pass). A
simple wiki page (describing each pass) would be more than enough for
me.
> When I tried mainline bootstrap on sparc-sun-solaris2.11 as of 20080903
> (rev 139939), I get a configure failure in stage2 libgcc:
>
> checking for suffix of object files... configure: error: in
> `/vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/sparc-sun-solaris2.11/libgcc':
> configure: error: canno
13 matches
Mail list logo
