Re: type based aliasing again

[craig@jcb-sc.com]

[back to gcc list, where it belongs, not in private email]

>> >  However, this change is one that can affect the correctness of the users
>> > code.
>> 
>> No.  It is correct to say "this change is one that can expose the
>> incorrectness of the user's code".
>
>This statement implies that the code, as written, has *always*
>been incorrect.

Exactly.

>I believe this is a false premise.  Standards change.

Not in this respect, apparently.  Nobody has, to my knowledge, proposed
that -traditional imply -fno-alias-analysis, which suggests K&R I
indeed, as has been reported, left this behavior undefined.

>As such, it
>would probably be valid to say, "using this compiler on that code
>is incorrect", but to say that the code is, itself, incorrect is
>as improper as saying, "The GCC 2.95.1 C compiler does not compile my
>K&R C program correctly, therefore, GCC C is incorrect".

No, not in this case.  Not even if the behavior was implementation-
defined, and GCC changed its definition (and, of course, documented
the change).

>And, in fact, that appears to be the response given to the Linux
>kernel developers: "Continue to use GCC 2.7.2 if you are not
>willing to change your code to conform to the new standard, and
>if you are unwilling to set the proper switch".

I doubt you have quoted any email from a GCC developer *precisely*,
particularly in regard to the word "new" in "new standard".

Remove "new", and the statement seems pretty correct (perhaps also
change "switch" to "switches").

The resulting statement is not equivalent to the other quote
you made up.

>It might make for less heat and flame if everybody in this discussion
>simply acknowledged that neither the source, nor the compiler is to
>blame: both the compiler and the source code are correct, it is simply
>the action of mixing incompatible pieces that is inadvisable.

Again, not correct in this case....

>Which, I believe, is what RMS was trying to suggest earlier in his
>gentle reminder of "traditional GCC mailing list" nomenclature.

No, he wasn't.  The only suggestions on the table involve issuing
warnings when code can easily be determined to *appear* to have this
bug, and making -fno-alias-analysis (which works *around* the bug)
the default for some, or perhaps all, optimization levels.

(Well, there are *my* suggestions, which were rather unique.)

But the bug is in the user code being compiled, not in GCC.  Period.
There's *no* credible disagreement on that.

>> The *developer* of the *code* already got fair warning, or else is a
>> dunce who shouldn't be allowed anywhere near a computer, especially
>> not as a programmer.  Only people who understand, or at least accept,
>> the fact that re-compiling their code can legitimately change the apparent
>> behavior of their code should be allowed to represent themselves
>> as programmers in languages requiring compilation (or even interpretation).
>
>With the caveat (of course) that behaviour should not change so long
>as the code conforms to the standard that the compiler purportedly
>conforms to, right?

Incorrect.  See "implementation-defined".  When you change implementations,
which can include switching to a new version, you can change behaviors.

If you want your code to behave the same way no matter when or how
you compile it, see Java.  And even that won't completely fit
that description, IMUO.  (`U' == `Uninformed', regarding Java
specifically.  Of course, I believe I'm plenty informed about
the relevant issues, such that the issues of how Java itself
attempts to meet the "write once, run many" promise, as interpreted
by some programmers anyway, are irrelevant to my analysis.  It's
about as likely as a perpetual-motion machine -- does a physicist
really need to see the details of such a machine to make a good
guess as to the veracity of the claim?)

>As far as I can tell, GCC 2.95.1 has enough other bugs, bugs where it
>does *not* correctly compile, that I consider this discussion somewhat
>a waste of time . . .

Hallelujah.  I think maybe you're the only other person to say that
besides me.  I've been saying it for months now.  (I have this vague
recollection of having had this point echoed by maybe one other person
as well, but am not sure.)

>The simple rule is:
>
>Don't use GCC C 2.95.1 on code that does not conform to the
>C standard that GCC C 2.95.1 follows (+ GCC extensions
>of course).  Unless you bring that code into
>conformance, first, of course.

Right.  That's what the docs for GCC already say, or at least
should say, or at least imply, especially vis-a-vis warnings
about using -fno-alias-analysis.

>'Course, documentation clarifying the changes is necesary, from
>release to release.  But that documentation, if correct and complete,
>plus warnings where and if appropriate, should be considered sufficient.

Yup.

>> Now, what *users* expect is a whole 'nother can of worms.  If users
>> need fair warning that a program might not work because they use a
>> different compiler on it, then that warning must come from the
>> developers of that *program*, not the compiler.
>
>I tend to disagree, here.  When the standard changes, the reasonable
>response is to provide errors or warnings when code (that was correct
>for the previous versions of the standard) is encountered in a compiler
>that conforms to a new standard.  Break that code, bend it, what
>ever, so long as some kind of warning or error is issued.
>
>Unless by "user" you mean somebody other than the person who uses
>the compiler . . . ?

"Use" is overloaded to the point of ambiguity here.

Simple example: I write program jcb-sing, distribute it in source form
as C source jcb-sing.c and Makefile.  The latter causes "gcc -O2 jcb-sing.c"
to be invoked by default.

Now, as the *programmer*, it is *my* responsibility to get the C code
and the Makefile right.

But, what some people have been saying here is that GCC must conform
to the expectations of *users*, by which they mean that any random
person who downloads my package and types "make" is a *user* of GCC
who has no expertise or other ability to know that jcb-sing.c actually
is buggy and thus requires -fno-alias-analysis to be specified to
compile to working form.

That's simply wrong.  It is still *my* responsibility to fix jcb-sing.c
*as well as* Makefile to do the right thing, vis-a-vis new versions
of GCC that might be installed.

Now, if I decide I'll support only GCC 2.7.2 or 2.8.1, fine, then
I can document that, or try "gcc -V 2.8.1 -O2 jcb-sing.c" in the
Makefile (not that I am really suggesting that), or whatever.

But it's *my* responsibility as a vendor of a free-software tool
to make it work for any conforming C compiler support GNU CC extensions
that compiles my code without error.  The aliasing bugs in the code
are *my* bugs, not examples of GCC compiling it erroneously.

It is not in any way the responsibility of the GCC development team
to make sure I don't have to actively maintain *my* software just
so users will magically get the right overall behavior.  Achieving
that is, frankly, a pipe dream, and every engineer worth his salt
understands why: because, without agreed-upon specifications as to
how components will behave and what their tolerances will be,
there's no way to engineer large, complicated systems made out of
components built by different people at different times and continually
enhanced and fixed *without* encountering such problems.

(Even *with* agreed-upon specifications, it's incredibly hard.)

And, in case anyone was wondering: `biff', that program that tells
you when you've got mail, *vastly* exceeds the threshold set by
my use of the phrase "large, complicated" by the engineering standards
with which I'm passingly familiar.  I.e. I'm not just talking
about million-line applications -- pretty much any piece of software
used on a network-connected computer today meets that definition.

>Right.  Agreed.  Totally.  If a programmer believes that "Patterns"
>or "Methodologies" or "Software Engineering Principles" are
>"silver bullets" (or some other disparaging term that implies
>such things are ivory tower abstractions that "have no place
>in the real world") they should not be using the C language.
>
>Heck, they shouldn't be allowed anywhere near powered machinery
>of any sort what so ever.

One could at least argue they shouldn't be programming (for others
anyway) at all, but I used to say stuff like that, and, looking back,
I realize that...well, come to think of it, I shouldn't have been
programming for other people at all!  But how else to learn?  ;-)

>C requires a huge amount of discipline to use correctly, and well.

Perhaps.  Anyone who agrees with that should pause and consider
this: C++ is to C what the space shuttle is to a paper airplane.
(Okay, I'm exaggerating...a *bit*.  ;-)

>Ditto.  As far as I can remember, the aliasing rules are *NEW*, so

No, they just weren't so widely exploited by compilers.

>I can live with warnings changing.  I find it irritating to have
>to deal with silent change or breakage when it would have been
>possible to warn me about it.

I think everyone agrees with that.

>I believe that if you clarified the discussion by indicating that
>you acknowledge that the compiler user's code is *correct*, but
>pointed out that it is not correct and valid behaviour to compile
>*that* code with *this* compiler, you'd be able to resolve this.

No, I was specifying something decidedly, if only "just barely",
different: that a programmer maintaining code with this alias
bug is *the* one responsible for either *fixing* the code, *or*
taking responsibility for specifying exactly what compiler(s)
users should use that he believes do *not* happen to expose the
bugs in his code.

E.g. Linux developers have told users to use 2.7.2 or whatever
to compile Linux because of known bugs in *their code*, on the
theory (which I assume has yet to be unproved) that 2.7.2 doesn't
happen to expose those bugs.  But they've been told there is
*potential* for those bugs to be exposed, just latently (i.e. the
bad code could be running in those Linux kernels today, but just has
never been triggered, or happens to produce correct results anyway).

(I don't know offhand, and so don't want to discuss, whether these
were bugs that were easy to avoid by reading the docs, 'cause I
think they weren't...though I think they were easy to avoid by writing
to the ISO C, or an earlier, standard, i.e. I think the bug had
to do with relying on *very*-GCC-specific extensions.)

>Short and Sweet: "Evolve, or get rm'ed!" :-)

I've been thinking today about how this is really a black-box vs.
white-box problem, in the context of the larger issue of engineering.

When building a system out of components, treating each component
as a black box is a simplifying assumption.  I.e. taking each
component on its own *published* terms, and not relying on observed
or internal behavior, actually makes the job of putting together
the whole system *easier*, because the specification for the *published*
behavior of a black box is almost *always* simpler than that for
the behavior of that same box treated as a white box.  (In this
case, the complexity of GCC far exceeds that of ISO C itself,
from the point of view of a programmer writing ISO C code.  So
as soon as that programmer strays outside ISO C into GCC-specific
behavior, the complexity of the task he's undertaking goes *way*
up, even if he sees a modest reduction in the complexity of the
*code* he writes.)

Another way to simplify, or reduce the risks of failure, is to
minimize the combination of the number of components and their
complexity vis-a-vis the system.  (That last phrase means, essentially,
if you depend on only a few published aspects of a black box,
then the fact that it's incredibly complicated internally doesn't
add to the complexity of *your* effort nearly as much as if you use
a component only half as *internally* complex, but use it as a *white*
box, since, in the latter case, you are exposing all that complexity
to your entire project.)

So, the things a good engineer would do when designing, say,
my jcb-sing program include (in *roughly* descending order of
importance, but definitely not completely partitioned that way):

  -  Minimize the number of components.

  -  Rely as much as possible on only the published, black-box behavior
     of components.

  -  Choose components with the simplest *needed* severable behaviors.
     (E.g. since GCC's __asm__ facility is severable from its other
     C constructs, programmers who avoid it need not take it into
     account vis-a-vis this particular item...but see the next!)

  -  Choose components with the simplest *white-box* (internal)
     behaviors.

To the extent this is well-done, the project can tolerate replacement
and upgrade of components, as well as debugging of problems, since
there's more of an opportunity to find a smoking gun in terms of
which component (or connecting tissue, itself a component) is failing.

Going back to my jcb-sing example, among the components I include in
it, or rely upon when using it, are:

  -  A GNU C compiler

  -  A chunk of C code

  -  The ISO C standard

  -  A Makefile

  -  A `make' program

  -  Some shell scripts within the Makefile

  -  A shell

  -  An operating system

  -  Documentation

You get the idea, lots of stuff.

If I allow bugs in my code on the grounds that I can make GCC "cope"
using an option, then I increase the "whiteness", or translucency,
of the GNU C compiler component.  Right there, that increases complexity.
So, replacing GCC with a much earlier, or much later, version
can break things, if that version doesn't support that option.

But, moreso, leaving my code in a buggy state increases *its*
complexity as well, since that code is not ISO C, which means
anyone working on it besides me (in the sense that I, too,
am a "component" of the system and thus might be replaced or
upgraded ;-) has *more* complexity to deal with, because just
knowing ISO C, an off-the-shelf component, is not enough to
understand the code.

If it's important for me to freeze the behavior of my code, I can
ship it as assembler instead of C, which makes some for some
simplification at the expense of some component replacement (OS,
architecture, etc.), or in addition to C, which increases
complexity due to providing two versions and whatever logic
is used to select between them.

Or, I could write my code in Perl, or UNIX `sh', and avoid all
sorts of C-related problems.  That simplifies in some way,
but can add complexity in others (e.g. interpreted languages
rarely have as good static analyzers available for them as
compiled languages -- witness how many more "obvious" typos and
thinkos are found CVS'ed into GCC's configury -- shell-script/Makefile
combinations -- compared to its C code, taking into account
the relative sizes).  In particular, using `sh' might make
it *harder* for me to spot a problem that'll show up only
on some *other* system's `sh', whereas GCC actually can help
find such problems before they happen (e.g. uninitialized-variable
detection has this effect).

Now, if that explains my overall thinking clearly enough, perhaps
you can see why I positively *discourage*, and don't mind GCC
*itself* discouraging, programmers viewing GCC as a white box
rather than a black box.

Yes, the advantages of always having source can be leveraged
such that *every* component we used can be treated in white-box
fashion when we put components together into larger ones.

But, the lessons of engineering include, to me, that even when
one *can* treat components as white boxes, one should *not* do
so, if one wishes to engineer a solid overall product.

(Of course, for unit and system testing, it is entirely reasonable
to strategize and prepare tests based on white-box analyses of
the components.  This is something the proprietary software
industry can *never* offer its users, of course, who can legally
go no farther than gray-box testing, where they *guess* at how
the proprietary components are probably implemented, and try
to break it at the guessed-at seams.  Of course, gray-box testing
is a good idea for free software as well.)

So, when I hear people say "GCC should default to -fno-alias-analysis",
I *basically* hear them as if they're complaining about code that
either isn't important enough to have been engineered in the first
place, or isn't actively maintained but is still actively used *and*
recompiled, despite awareness that it is no longer maintained.  (Even
a user just using a downloaded source package has a responsibility to
check back at the FTP site on occasion for upgrades/fixes/etc.  Again,
if that user doesn't do that, he's not on the engineering level, so
we shouldn't worry much about how to make his hacker life comfy at
the expense of meeting the needs for engineers to have a simpler GCC.)

In both cases, I tend to think "why should we increase GCC's complexity
to address cases that either don't matter or are time-bombs waiting
to explode anyway?"

Yes, I can see *some* rays of light shining through those dark views of
the request for features, but that *is* the fundamental template
through which I now, as a more experienced software developer,
view these requests.  (I.e. there are some cases I can imagine
where accommodating these sorts of requests make sense.  As the
sole developer of g77, it was easy for me to make those decisions;
it's obviously vastly harder here in GCC-land, so it's not unreasonable
to declare that these issues will no longer be discussed, and that
GCC is no longer to be assumed a warning generator, since that'd
be a simplifying assumption consistent with the core engineering
function of GCC.)

Because remember: when you ask for a black-box product to adopt
behaviors that are white-box-like (which includes many compiler
warnings, especially these), you ask for an *increase* in the
complexity visible to end users, who *will* see those behaviors
as if they were black-box-like, and in the *internal* complexity
as well.

The increase in complexity users perceive as black-box like
can contribute to unnecessary increases in the complexity
of their projects, since one of the component's apparent
black-box behavior has now gotten more complex.

Even if you ignore that increase, the increase in internal,
white-box complexity works against *everyone* who uses that
component (GCC, in this case) in their project, *regardless*
of whether they can or will make use of that new behavior.
(That's the fourth item in my list of things to minimize,
above.)

That's why, given all the heat and light over this issue,
I'm not convinced that even the proposed *warning* is a good
idea -- because the added complexity in GCC causes *everybody*
who uses GCC to suffer an automatic increase in the risks
of success of *their* project, because it increases the likelihood
of GCC failing them as a component.

(As I said earlier, an example of a mitigating factor here is
the capture of more code that many users test against GCC using
its default options, e.g. because they gain confidence that
warning-free code isn't hitting this "awful new GCC behavior",
even if it is, or because they applaud our adding the warning
by fixing their broken code.  That extra testing can contribute
to reducing the bugginess of GCC.  It's even possible it'll
contribute to an effort, in fixing bugs the extra testing finds,
to *simplify* GCC in a way that it otherwise wouldn't have been.
Note how *unlikely* each of these positives is likely to be,
compared to the previous...but they *are* possible, and not
to be totally dismissed.)

Now, to people who say "forget all the engineering BS, I just
want to get real work done", I say, fine, you don't want to
do engineering?  Then be happy with the fact that some version
of GCC happened to compile your code so it worked at a given
moment.

And when it stops working, you, as someone who doesn't care
about engineering, can only say "oh well", and either fix it,
or just put up with it, or hire somebody who'll fix it.

The central hypocrisy of much of this thread (*not* jstevens here,
I must stress!) is that some people want to insist that GCC behave
*as if* it is perfectly engineered -- works the same way all
the time in any project in which its used, despite being upgraded,
enhanced, and fixed -- but *refuse* to acknowledge, or recognize,
the responsibility *we*, as GCC *developers*, have to exercise
some engineering methodologies to make GCC actually *work*.

In short: if you care about engineering, you don't mindlessly complain
about GCC not issuing warnings (though you might complain on other,
more legitimate, grounds, related to engineering), you might not
even complain if GCC didn't *have* a -fno-alias-analysis option,
but you *certainly* don't complain that it defaults to -falias-analysis.
(Not as a *user* of GCC, that is; GCC *developers* have their
own agendas, of course, as it is their job to set the parameters
of the box they're building.  So David Edelsohn saying "let's change
the default" is okay in lots of ways that Linus Torvalds saying it
is not.  The latter is merely a request, which can be legitimately
hand-waved aside as not pertaining sufficiently to the core mission of GCC
to even discuss, users not having the *responsibility* to set the
parameters of the GCC "box".  The former could reflect an opinion
that, in this case, increasing the complexity of the GCC box could,
in the long run, lead to more testing.  That's why developers should
*listen* to users, but not always *accommodate* them, if they
intend to build something that works.)

If you *don't* care about engineering, then you have no business
complaining that GCC should accommodate broken code either, since
that code is either *hacked* (and thus will always need fixing as
components change around it) or *engineered* (in which case it *must*
be fixed).

(If there's a category of programming other than "hacking" or "engineering",
other than the obvious one -- "incompetent" -- I'm sorry to not
be able to think of it right now and factor that into those opinions.)

>> So I can see why a few people might think even a warning is likely
>> to constitute just another new minefield for GCC developers to
>> have to march through in another year or two.
>
>That one I don't get.  How can a warning of incorrect code become
>a "minefield"?

When people treat GCC not issuing the exact same warnings given
the exact same code from one version to next as yet another case
of GCC "breaking" their code -- since it'll require them to
go "fix" their code, or turn off the warning, just like the
current situation does.

Simply put: give 'em an inch, and they'll take a mile.  (As the
*current* discussion already proves, I think, vis-a-vis earlier
discussions over the years.)

So we someday change how alias analysis works, turning on more
optimizations.  Let's say that has two effects: some previously
legit warnings stop being issued, and some previously unwarned-about
constructs start being "miscompiled" -- i.e. exposed as the bugs
they always have been -- due to adding new optimizations that
the bulk of users require as *default* (for -O1) to get any
decent performance on some popular new machine (which could even
be a Pentium IV, in theory anyway).

Does anyone really think users *then* will accept the resulting
lack of warnings about bugs in their code any more than they'll
accept the present situation?

Yet that scenario is not only likely, it's two inches short a mile
into inevitable, especially the latter part of it.  (The former
would happen if we re-designed the compiler in certain areas, I
assume, which we might not do in the process of adding the new
optimization.)

If we don't want to impose that kind of minefield on the GCC developers
of tomorrow, the quickest, and perhaps kindest, way to do that is to
let the horse die by the side of the road -- by not providing any
option at this time.

(Maybe *the* kindest is to shoot the horse -- i.e. remove any and
all support for -fno-alias-analysis in GCC 3, 2.96, or even 2.95.2.
Take the screaming for a few months, after which people who don't
simply crawl away recover from the shock of having to fix their
code and simply do it...learning the hard way to *never* write
code like that again.)

>As for avoiding the issue by adding warnings: I agree.  You will not
>avoid this issue by adding warnings.  But you can, I trust, see
>how the warnings are necesary?

No, warnings are never necessary for a compiler to emit, unless
that is required by the pertinent standards and specifications.

GCC emitting warnings is a quality-of-implementation issue, and
thus should *only* be done when the advantages of issuing the
warnings *greatly* overwhelms the disadvantages of added complexity
to GCC to support the warnings.

>I may inherit a body of code that I do not *know* is
>non-conformant . . . I would appreciate it if the compiler, when run
>on that code, informed me that the code was non-conformant.  That way,
>I could either: 1) Not use that compiler.  2) Actually read the docs :-),
>find the necesary switches, and set them.  3) Modify the code to be
>conformant.

The throw-everything-into-a-single-program mentality led to Emacs
and GCC, as well as most Microsoft products.  I used to support
it as well, but am thoroughly disenchanted with it at this point
(though I have *plenty* of understanding as to why it was a
better approach back in the '70s and '80s than it is today, so
please don't think I'm saying Emacs and GCC were necessarily bad
designs as products...as I type this in using Emacs.)

I.e. what you, as a programmer, should be using to find bugs
in your code are programs that have the *sole* purposes of
finding static, and dynamic, bugs, respectively.

The task of compiling a program (or, say, a version of it "decorated"
with code that finds dynamic bugs) into a high-performance
representation should be done by another, separate, program,
with, itself, *no* responsibility whatsoever to diagnose
bugs in the code being compiled.

Among other things, it should be obvious that the factors
influencing the evolution of each of these separated programs are
vastly different, with pretty much the sole exception of
the language in which the user's pogram is written.  That
imples differing release schedules, different maintenance
teams, even different languages appropriate to the implementation.
All of which would benefit end users (e.g. we would already
have released this new alias warning as a new version of the
static diagnostic program *months* ago, if not earlier).

Think about it this way: if we removed every diagnostic capability
of GCC to completely separate programs, one that did static
analysis and one that added dynamic-analysis code (in the same
language) for compilation by GCC, then GCC itself would probably
be *significantly* simpler, or at least somewhat simpler.

The result?  *Products* which *use* GCC to compile code would
become simpler and thus more reliable.  (Yes, they'd use those
other tools as well, but in different timeframes, so to speak;
the user installing jcb-sing, for example, would see an instance
of the project that includes only reliance on GCC, not on
those analysis tools.  At that level, the simplicity of GCC
would lead to a more robust product.  And discussions like this
would *naturally* be resolved *much* more quickly into where to
assign responsibilities for the various issues.)

I.e. GCC would become a smaller, much blacker, box.  (Perhaps having
no command-line options like -O and such whatever.)  Two or more
other small, black boxes would appear, one using static analysis
to detect problems, another decorating the code to use dynamic
analysis (i.e. a filter to be inserted prior to running GCC itself).

Each being simpler and more-well-defined in purpose and interface,
the task of maintaining, releasing, even documenting the lot would
be somewhat reduced, and using each component in isolation, which
we often do during development at a conceptual level (e.g. "compiling"
when we know we just want warnings/errors; or shipping a script
that compiles code, when we know we *don't* want those being
dealt with, at least not at that particular step), would reduce
the complexity of a *huge* number of free-software projects.

I don't happen to think this particular division of labor is
the *ideal* one -- I have a much-finer-grained system in mind,
actually, because I see other pressing needs to address.  So it's
just an example of what can be accomplished...

...by thinking out from inside the box.  ;-)

Also, there are political downsides to a finer-grained architecture,
as long-time followers of the GCC lists might recall: RTL supported
as an input language for a "separate" back end comes to mind as
a political issue, highlighting some such downsides.

>If GCC simply and silently generates invalid code, that is
>unacceptable (unless the compiler writers can show that detecting
>such errors and issuing warnings is not feasible).

Right.  Ensuring GCC is very unlikely to do that is *supposed* to
be Priority 1 of all of us working on it.  This alias-warning
issue is, comparatively, way down the list.

[...not really written to me per se, but:...]
>You say: "I don't read the docs!"?
>
>To bad for you, then.

Well, strictly speaking, I, too, am bad about reading docs.  I simply
tend to learn faster when first looking at sample code.  E.g. I
put up my own web page by "borrowing" egcs.cygnus.com's .html files --
well, their formatting, but I used the content to learn some things.
Only after I had a working familiarity with HTML did I finally
buy a couple of books, read one of them cover to cover, etc.

And I hardly ever bother reading books on computer architectures
or assembly code anymore, because I can learn it just by reading
the output of GCC on the machine.

But I try to *never* hold anyone else responsible for mistakes
I make by failing to read the documentation.  Especially since I'm
such a supporter of *anyone* who attempts to write documentation,
I want *them* to feel *wanted*!

(Still, I'm fond of failsafe procedures that cause systems
to not enter modes requiring documented expertise to use safely
as soon as they can detect their operation by someone who
has not read the documentation.  GCC doesn't need that for
end users; install scripts intended for use by end users,
and which invoke GCC, probably do, but that's not a GCC problem.)

        tq vm, (burley)