This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] missing protoypes in dummy-conditions.c
On Mon, 31 Jan 2005, Marcin Dalecki wrote:
> Hmm... Because those are precisely the headers which are included by the
> code consuming the entities defined there. So I'm about 100% sure that
> your objections are not valid. They are not congruent with the comment
> found there anyway. And finally I came across it by trying to compile
> the whole by a "shoddy non standard compliant C compiler". Well the non
> standard compliant C compiler was simply well a C++ compiler...
1. The code that runs on the build system is fragile because of both
ordering constraints (which were the original reason dummy-conditions.c
exists) and because of headers that are used in two different contexts,
both in the back end and in the build programs.
2. Support for building with a C++ compiler may not be complete, although
some has been added. Problems with such support that don't arise with C
compilers aren't really bugs in the sense of being appropriate to fix
during Stage 3 unless the fix is extremely clearly clean, simple, safe and
3. Some indication of what the C++ compiler said was wrong within the
terms of the C++ standard would be helpful.
4. Fragility in the build programs could usefully be addressed by
incrementally separating those parts of source files and headers genuinely
needed for both build and host from those only relevant for host.
5. The struct c_test has a fixed definition
const char *expr;
which does not depend on other things in gensupport.h. Accordingly, I'd
suggest splitting it out to its own header (e.g. insn-conditions.h) which
could also declare insn_elision_unavailable, insn_conditions and
n_insn_conditions; this header need only include <stddef.h> to get a
definition of size_t, not any other headers.
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
email@example.com (personal mail)
firstname.lastname@example.org (CodeSourcery mail)
email@example.com (Bugzilla assignments and CCs)