Re: [PATCH] missing protoypes in dummy-conditions.c

[Marcin Dalecki <martin at dalecki dot de>]

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
> correct.

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.