Re: Gforth and gcc "progress"

Anton Ertl <anton@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Andrew Haley <andrew29@xxxxxxxxxxxxxxxxxxxxxxx> writes:
Anton Ertl <anton@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Andrew Haley <andrew29@xxxxxxxxxxxxxxxxxxxxxxx> writes:
What does it mean to jump out of a statement expression, anyway?
...
If you need help, here's a hint: What does it mean to call longjmp()
or exit() in an expression; that can occur even in an ANSI C program,
no?

exit() and longjmp() return void, so it doesn't make any sense to use
them in a non-void context.

To be pedantic, exit() and longjmp() don't return.

Oh, for goodness' sake! Let's move on.

The core issue here is that many of the gcc extensions never were
properly defined, so the corner cases don't work correctly.

The case mentioned above is where the meaning of the extension is
pretty straightforward, and the non-working comes from a bug in the
compiler (I guess it does not reset the stack depth before performing
the jump). But of course with ANSI C blinders on you only see a
non-conforming program, and a compiler that therefore has the right
not to work.

What we need in order not to have these kinds of arguments is a
language that conforms to ISO C + a bunch of well-defined extensions.
If the extension in question had been well-defined, the kind of
arguments you've had would not have been possible.

So if ANSI C was well-defined, it would be impossible for us to argue
what it means to call longjmp() or exit() in an expression, right?

Given sufficient bloody-mindedness it's possible to argue about
anything, as you amply demonstrate.

In any case, if you want a tighter specification of the extension, you
could commission such a spec.

I really would like to have a sensible discussion about how to fix
some of the problems you're having with gcc.

So do you have any ideas how they could be fixed?

That depends on the specific problem. Some things, for exmaple
register allocation, are very hard, and in any case are being actively
worked on. Other things might be easier.

What would be interesting to me is a to know the most important gcc
deficiencies from the point of view of GForth and your estimate of how
significant these deficiencies are. There might well be some push-back
from gcc developers, with the claim that GForth "isn't
representative". But I'm not convinced of that, as I suspect that some
of the problems you've seen might have an impact on other code bases.
There is more to the world than SPECint.

I used to write bug reports for gcc. But the reaction to PR25285
convinced me that this is a waste of time.

Well, I agree that Andrew Pinski's Comment #3 seems to be very
unhelpful. However, it's not just a matter of writing bug reports,
but of finding a gcc maintainer who understands the problem and is
motivated to work on it.

Andrew.
.

Relevant Pages