This is the mail archive of the 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: [FORTRAN PATCH] Reduce gfc_match_strings usage (part 2)

Hi Tobias,

On Sun, March 11, 2007 9:02 am, Tobias Schlüter wrote:
> As an aside to all the discussion about the implementation strategy for
> the matchers, I'd like to point out that standard Fortran has a .xor.
> operator, which is called .neqv..  Unless you intend to give .xor. a
> different precedence, its implementation should be trivial (unless I
> underestimate the difficulties a collision with a user-defined operator
> could bring), so I'm wondering what kind of difficulties are you seeing?

Exactly, the implementation should be almost trivial with ".xor." being
treated as a synonym for ".neqv.".  The major difficulty I envisaged was
in the parser.  Depending upon the applicable standard, ".xor." should
either be recognized as an intrinsic silently, be matched as an intrinsic
and issue a diagnostic warning or not be recognized and fall through to
being treated as a general identifier (without type checking etc...)

Unfortunately, the current structure of "gfc_match_strings" in addition to
being inefficient, doesn't easily allow conditional keyword matching. 
With the proposed scheme, supporting ".xor." might be as simple as
something like:

  case 'x':
    if (gfc_next_char () == 'o'
        && gfc_next_char () == 'r'
        && gfc_next_char () == '.')
        /* Matched ".xor.".  */
        if (gfc_notify_std (GFC_STD_GNU, "...") == SUCCESS)
            *result = INTRINSIC_NEQV;
            return MATCH_YES;

Or alternatively, we could add a new INTRINSIC_XOR, to allow error
messages and modules to display ".xor." instead or ".neqv.", and treat
it as a synonym for INTRINSIC_NEQV everywhere.

Whilst in theory, it is possible to add a wrapper around the current
gfc_match_strings, remembering the state before, checking whether it
returns INTRINSIC_XOR, and then deciding to either restrore
gfc_current_locus and return MATCH_NO, or accept the ".xor." and transform
it in INTRINSIC_NEQV, this overhead would make the current implementation
even less efficient, and inserts more code to the common/critical path.
As confirmed by FX, gfc_match_strings is already the hotest function in
the gfortran front-end.


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