2013/12/18 Tobias Burnus <bur...@net-b.de>: > Janus Weil wrote: >> >> here is a follow-up to my recent patch for PR59493, doing some cleanup >> related to the generation of vtab symbols: >> 1) Since the function gfc_find_intrinsic_vtab, contrary to its name, >> handles not only intrinsic but also derived types, I removed the >> latter functionality, and instead introduced a new function >> gfc_find_vtab, which handles arbitrary types and simply decides >> whether to call the corresponding function for intrinsic or derived >> vtabs. >> 2) Basically all calls to gfc_find_intrinsic_vtab are replaced by >> gfc_find_vtab. This often simplifies the logic and saves additional IF >> clauses to distinguish between intrinsic and derived types. >> 3) As a consequence, gfc_find_intrinsic_vtab is made static and loses >> the gfc_ prefix. >> >> All of this results in the code being shorter, clearer and more >> error-prone. The patch is regtested on x86_64-unknown-linux-gnu. Ok >> for trunk? > > I assume you mean "less error prone".
I guess I meant either "less error-prone" or "more error-proof", and somehow picked the wrong combination ;) > Looks good to me. Thanks for the cleanup! Thanks, committed as r206101. Btw, I also thought about the possibility of replacing all calls to gfc_find_derived_vtab by gfc_find_vtab, but I need to check if that is reasonable/helpful in all cases. Cheers, Janus
