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: ICE: malformed code gives ICE for &(C::m)

Mike Stump <> writes:

| On Monday, August 5, 2002, at 04:04 PM, Gabriel Dos Reis wrote:
| > Mike Stump <> writes:
| >
| > | Ping...
| > |
| > |
| >
| > Hi,
| >
| > I crossed the ICE you're fixing and I'm wondering if it wouldn't be
| > better to fix it at the point of construction of &(C::m) since that
| > already is invalid if m is member function.
| [ blink ] Do you realize that this is code called out of the parser for 
| & at build time?

For sure.  Is there anything that indicates the contrary?

Upon seeing &(C::m), the parser calls finish_unary_op_expr() which in
turns calls build_x_unary_op().  My point is that since &(C::m) is
invalid construct when m is a member function, build_x_unary_op()
shouldn't have left out something that will end up being nonsensical.
Therefore my thought is this: build_x_unary_op() should

  (1) issue a diagnostic for &(C::m) if m is member-function and
       (a) either return error_mark_node, or
       (b) try to build a sensical representation (DTRT)

  (2) build a pointer-to-non-member is m is data member.

That I think is much robust than trying to recover the situtation only
very late at initialization time.  I don't think that means I didn't
realize that is code called out of the parser for & at build time.

-- Gaby


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