Hi Jin Gu Kang,
> I made a patch for llvm-gcc about 2 weeks ago.
> But no one reviewed my patch.
> Reason of patch was following.
> >> struct T {
> >> struct T (*p)(void);
> >> } t;
the recent LLVM type system changes broke llvm-gcc in several ways, this is just
one of them. All such problems are fixed in dragonegg by not converting
"T"
when converting "T*" if this might cause recursion problems, and
instead
turning it into i8*. Clang does something similar. Any comprehensive solution
to the problems introduced by the type system changes necessary will result in
"T*" sometimes not being converted into a pointer to the LLVM type
that T
converts to, but a pointer to some other type.
Unfortunately I think llvm-gcc assumes in a bunch of places that a
"T*"
is always turned into a pointer to ConvertType(T). Dragonegg does not suffer
from this problem due to a bunch of work I did on it over the last year or so.
So what to do about llvm-gcc? Your patch doesn't solve the fundamental
issue,
just one special case. I think the best approach is to port the dragonegg
fix (the current approach is not quite correct, but good enough for C/C++),
and then fix up fallout. However there might be a lot of fallout. If so,
I'm
not interested enough in llvm-gcc to spend much time on it. Remember that the
llvm-gcc compiler is deprecated, in fact it is dead. So there is a chance that
llvm-gcc is just going to stay unfixed.
Depending on a dead compiler is going to cause you more and more trouble as time
goes on. In the long run you would probably do better to port dragonegg to ARM.
Ciao, Duncan.
