PATCH: Fix two-phase lookup for "operator new"
Andrew Pinski
pinskia@physics.uc.edu
Tue Apr 11 23:07:00 GMT 2006
>
>
> This patch fixes a two-phase name lookup problem with calls to new.
> In particular, the choice of function to call for "new T" should be
> resolved at parse time, if T is not a dependent type. We were
> incorrectly deferring that to template instantiation time.
>
> To make this tidy, I eliminated the after-the-fact processing where we
> tried to poke at the CALL_EXPR generated by lowering the
> new-expression, and, instead, arrange that build_new_method_call tell
> us what function it decided to call, since it knows the answer.
>
> While fixing this, I took the opportunity to eliminate a (small) waste
> of memory; build_new created a NEW_EXPR, just to pass it to
> build_new_1, which promptly took it apart again. I also changed a
> diagnostics to refer to "incomplete" types rather than "undefined"
> types, since the former has a well-defined meaning, and the latter is
> ambiguous; it could mean either a type that has not been declared, or
> an incomplete type.
>
> Tested on x86_64-unknown-linux-gnu, applied to mainline. (AFAIK, this
> is not a regression, so I am not planning to backport it to 4.1. If
> it is a regression, then we'll want to backport only the essential
> bits of the patch.)
This only fixes operator new, correct? PR 21802 shows that this is a
problem with any kind of operator and not just operator new. Just
something to keep in mind for the future if you missed that bug before.
-- Pinski
More information about the Gcc-patches
mailing list