This is the mail archive of the gcc-patches@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: [PATCH] Fix PR52977


On 4/26/12 9:35 AM, Diego Novillo wrote:
On Thu, Apr 26, 2012 at 06:43, Dodji Seketeli<dodji@seketeli.org> wrote:

I guess it's also worth noting one limitation of PPHs that is, if I
believe the wiki:

    In essence, the only headers that can be pre-parsed are those that
    produce the same result when they are compiled in isolation or as
    part of another translation unit. So, header files that are affected
    by pre-processor symbols defined before inclusion are not going to
    be considered (e.g., stddef.h).

[1]: http://gcc.gnu.org/wiki/pph#Scope_and_limitations

How hard would it be to drop that limitation?

It's an explicit non-goal, actually. If you relax this requirements, you might as well re-parse the header file. The work needed to make flexible PPH images will rob you of most/all the performance you were looking for.

Expanding a bit on this point.


One of the goals of PPH is to act as a bridge towards C++ modules, which is currently being discussed for inclusion in the next C++ standard.

While it is uncertain what modules will look like, we want to use this experience to inform the committee on the different tradeoffs and issues we found. We will publishing something shortly, and discussing it at the Prague meeting.

I a future world with modules (if it comes to be), files acting as modules will need to have exactly one meaning, regardless of where they are imported from or what was imported before them (think Java/Go/Python modules).


Diego.



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