This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [rfc] atomic memory operation builtins
On Sat, 10 Apr 2005, Gabriel Dos Reis wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
>
> | (I've actually suggested that if the C/C++ front ends were shared, we
> | might allow overload resolution in C as well, for these kinds of
> | builtins, although of course the front end would forbid overloaded
> | declarations by users. I realize that's not happenning any time soon.)
>
> Recent patches I've seen seems to suggest active move away from that
> idea...
Rather, they suggest that we don't obstruct cleanups for the sake of
vaporware of uncertain merit; only for changes that are genuinely in the
pipeline for the very near future. Don't obstruct cleanup X or do Y for
the sake of hypothetical future change Z if X is useful now or Y is
useless without Z. If Z is ever found to be useful - and if a particular
approach to Z is proposed and agreed as desirable - then this may be so
far in the future that the internals and datastructures have changed
completely and so X and Y have both become irrelevant to Z. In the cases
in point, although commonality of datastructures and interfaces between
front ends may be of use independent of merging, even that is entirely
hypothetical at present, and changes to improve commonality are trivial
are when there are genuine immediate uses for such changes seen.
More useful changes which would be of their own use but also facilitate
any future changes towards sharing of code (and attempting such changes in
any way other that through strictly minimal incremental convergence would
be a very bad idea in terms of compatibility) include improving testsuite
coverage to 100% of the code of both front ends and improving the
precision of definition of GNU language extensions and aligning the front
end implementations with that definition (including aligning the C++ front
end implementations of features which are in C99 but are extensions in C++
with a properly defined concept of how that extension can best fit into a
C++ context); you might also consider working with WG14 and WG21 to
improve the alignment of concepts in the relevant standards as it is
manifestly desirable for concepts in the implementation to align with
concepts in the standards and if code is to be shared this conflicts with
the way the concepts in the standards have been diverging for twenty
years. These have value in their own right in terms of improving
front-end reliability and quality, do not presuppose some future large
project but would in the case of testcases be prerequisite for its
reviewability, and do not obstruct cleanups that make sense in the context
of the compiler we have now.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
jsm@polyomino.org.uk (personal mail)
joseph@codesourcery.com (CodeSourcery mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)