This is the mail archive of the 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] missing protoypes in dummy-conditions.c

On 2005-01-31, at 17:04, Joseph S. Myers wrote:

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.

ACK. Understood. The intentions where not obvious.

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

Well the reality is that I'm already about 2/3 through compiling with
BUILD_CC=c++ CC=cc ../configure. There are in esp. quite a lot
of enumeration type mismatches the C++ compiler is catching right on out there in
the code base. Some of them seem at least to indicate meaning overload at some
places, which may turn out to be serious. However I will report more as I get through
(And as my time will permitt, since, I'm actually in the process of moving places
right now...)

3. Some indication of what the C++ compiler said was wrong within the
terms of the C++ standard would be helpful.

It was mourning about incomplete type definitions.

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.

Well actually I would highly welcome it if the GCC would structure it's huge
code base by some subdirectories. Not too many but some would greatly help.
For example the libcpp dir is a step in the right direction IMHO.

5. The struct c_test has a fixed definition

struct c_test
  const char *expr;
  int value;

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.

Yes this would be propably the ideal solution.

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