This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Use of build_binary_op


On Tue, Sep 24, 2002 at 07:01:35PM -0400, Daniel Berlin wrote:
> 
> On Tuesday, September 24, 2002, at 06:20  PM, Paul Brook wrote:
> 
> >I notice you've started using build_binary_op inside tree-ssa-pre.c,
> >specifically in and around calculate_increment.
> >
> Yup.
> 
> >This causes me problems with the Fortran 95 frontend because 
> >build_binary_op
> >is a c-specific function,
> Not quite.
> It exists in the ada frontend as well.
> 
Yes, but it is redefined for following Ada's semantics (in ada/utils2.c), 
as well as C++ redefines it (in cp/typeck.c).

> >and the F95 frontend doesn't currently contain an
> >implementation of this. A straight copy/paste of the C implementation 
> >isn't
> >possible because this pulls in lots of other c-specific code.
> 
> >Is it really necessary to use build_bunary_op, or are you just using 
> >it as
> >shorthand for build(code, type, op1, op1) ?
> I could do it that way, if you like.
> 
> > If this is the case I'd like to
> >request that a language independat function be used for this purpose. 
> >If
> >not how much of the functionality of build_binary_op do I need to
> >implement?
> >
> I'll use build, don't worry about it.
> 
I think we'll need an interface for building GIMPLE trees instead of using generic
functions as build or build1 ...

Sebastian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]