tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: netbsd-11 gcc bug



>> I'd say this should be filed as a bug with the gcc people; if they
>> can't/won't fix it, NetBSD should roll back to a previous gcc and/or
>> drop gcc as the system compiler, as then it'd be clearly unsuitable.

(I perhaps should have added "as the self-hosting compiler for
NetBSD".)

> It is not about gcc or clang, it is about the C standard, which is
> created by an open comittee and you are welcome to send defect
> reports and/or ask for clarifictaions.

Which is fair - but compilers do not have to take advantage of all the
leeway the standard gives them.  "Undefined behaviour" can, after all,
include "exactly what the code author intended".

> The compiler using all strength the standard gives it is just a
> logical consequence of the user asking it to optimize.

Then, for the sake of being useful, it needs a setting that is "do most
optimizations, but don't make such unreasonable inferences about
formally-undefined behaviour".

Perhaps the gcc people are able-and-willing to do that.  But, if not, I
still maintain that it is thereby unsuitable for the use case of
building NetBSD.

The standard is an attempt to satisfy everyone; the result is a
compromise, and gives too much leeway for some use cases and not enough
for others - repeated, of course, for each point on which there is
potential leeway.  If &p->member is undefined behaviour when p is nil,
the correct thing for a *useful* compiler to do is not to simply assume
p is non-nil, at least not unless specifically told to; it is to test
for nil and take some suitable action - indirect through it, call a
(possibly invocation-dependent) routine, *something* better than
silently propagating the inference.  Especially in the presence of an
explicit test for nil later!

> But fixing the code to avoid "undefined behaviour" is the proper
> solution and fits NetBSD's clean code mission well.

Well, none of this is my call to make.  But I still think it excessive
for the compiler to cause formally-undefined behaviour to elide
explicit tests, especially when told to run freestanding.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index