Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56939
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: LLVM and Forth |
| Date | 2017-04-09 14:53 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2017Apr9.165301@mips.complang.tuwien.ac.at> (permalink) |
| References | (5 earlier) <NNSdnXwvutwb-H_FnZ2dnUU7-XXNnZ2d@supernews.com> <2017Apr3.190545@mips.complang.tuwien.ac.at> <a-SdnVgDEexEVH7FnZ2dnUU7-RHNnZ2d@supernews.com> <2017Apr5.170145@mips.complang.tuwien.ac.at> <s4wFA.637264$3a3.286206@fx43.am4> |
Spiros Bousbouras <spibou@gmail.com> writes:
>On Wed, 05 Apr 2017 15:01:45 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>
>> Translating Forth into traditional C (that compiles as intended by PCC
>> and early versions of GCC) is indeed not difficult; after all,
>> traditional C and Forth are semantically close to each other. Take a
>> look at Gforth or forth2c to get an idea on how to do it.
>>
>> The resulting code is, of course, full of undefined behaviour, like
>> most of the other C code around; and in this case I think it's
>> impossible to get rid of the undefined behaviour without losing
>> functionality and performance, and even if you are willing to pay that
>> price, it requires significantly more effort, and in the end, you will
>> probably still have some undefined behaviour somewhere.
>
>Here we need to make a distinction : I will term "weak undefined behaviour"
>(WUB) C code which is not defined according to the C standard and "strong
>undefined behaviour" (SUB) C code which is not defined according to
>*anything* where "anything" could mean some standard which enhances the C
>standard (like POSIX) and also relevant documentation of the compiler or
>libraries one uses or whatever. Our main conern here is predictable behaviour
>of the code so I believe the deciding concept is SUB rather than WUB.
I don't think that this distinction helps in this discussion, because
1) Different people consider different things to be "not defined
according to *anything*". E.g., assembly language and most Forth
programmers consider signed integer overflow to have a pretty
natural definition (wraparound aka modulo arithmetics), some more
mathematically-inclined people think they deserve nasal demons.
2) Nasal demon fans want license to produce nasal demons for every
undefined behaviour. E.g., in the general case both gcc and
Clang/LLVM generate code for 2s-complement arithmetic with
wraparound for signed integer addition, subtraction, and
multiplication, so you might classify it as WUB. Nasal demon fans
still want to keep signed integer overflow undefined even in those
compilers so that they make use of it for "optimizations".
3) People aware of the evils of nasal demons don't want them anywhere,
no matter what undefined behaviour there is. E.g., for an
out-of-bounds array read, I expect either an unspecified, but
stable value, or a segmentation violation/general protection fault;
that's not fully defined, but it excludes nasal demons. E.g., I
don't expect it to turn a counted loop into an endless loop (and
this is actually a nasal demon "optimization" that occurs in
practice).
>In any
>case , if code has SUB then I cannot imagine on what basis one may think it
>works and it will reliably continue to do so in the future : even if it
>passes testing , then that's by coincidence. So if a code exhibits SUB then
>it's buggy and it needs to be fixed.
Of course that depends on what you consider SUB. Anyway, here's an
example.
int d[16];
int SATD (void)
{
int satd = 0, dd, k;
for (dd=d[k=0]; k<16; dd=d[++k]) {
satd += (dd < 0 ? -dd : dd);
}
return satd;
}
If there is some other global data defined earlier and later in the
program, then d[16] is a mapped (i.e., readable) memory location. And
if it is an unmapped memory location, you get a SIGSEGV, not some
nasal demon.
>> 3) Complete correctness proofs of programs are outside the competence
>> of nearly all programmers (and pretty pointless, because they would
>> prove only the correctness wrt the specification, which itself may be
>> buggy).
>>
>> Now, to write a C program that is guaranteed to never exercise
>> undefined behaviour requires competences on the level 3.
>
>Not in the slightest. Consider the following piece of C code :
>
> int is_leap_year(unsigned int year) {
> return 1 ;
> }
>
>It's trivial to see that this is defined but , judging from the function's
>name , it's almost certainly buggy. A complete correctness proof is many
>orders of magnitude harder than simply ensuring defined behaviour.
I don't think it is trivial to see that this is defined. I once
<2015May1.155805@mips.complang.tuwien.ac.at> wrote:
|It seems to me that
|
| if ((size_t)(dest-src) < len)
|
|is a more efficient way to test whether dest is inside [src, src+len).
|
|Of course, since this code contains more than three tokens, it is
|likely to contain undefined behaviour
That was mostly in jest, but a post or two later, someone explained
that yes, this code is undefined. So while I do not see anything
undefined about the code you posted, just let the language lawyers at
it, and they will point it out.
In any case, in your example it is trivial to see that it does not
satisfy the requirement that is implied by the name, so even if it
really is trivial to see that it is defined, it only shows that both
correctness and definedness are trivial to determine for trivial
programs.
>> So you will find undefined behaviours in the cases exercized by normal
>> users, but you will tend not to find undefined behaviour in those
>> cases exercized by an attacker; it's as difficult as finding the all
>> the vulnerabilities in the first place. E.g., in the OpenSSH case, if
>> you thought about the vulnerability, you would fix it right away,
>> rather than writing a test case that exploited it, and waiting for the
>> sanitizer to report that freed memory was accessed (if the sanitizer
>> actually does check that), and then fixing it.
>
>The best write-up I could find on the vulnerability is at
>https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-2016-0777-cve-2016-0778.txt .
>
>The crucial bug occurred much earlier than compiler optimisations eliminating
>code which wrote 0's on some memory. From the previous link
>
> - "out_start == out_last" (lines 205-206): no data was ever written to
> out_buf (and both out_start and out_last are still equal to 0) because
> no data was ever sent to the server after roaming_reply() was called,
> but the client sends (leaks) the entire uninitialized out_buf to the
> server (line 214), as if out_buf_size bytes of data were available.
>
>This would still be a bug (albeit a less serious one) even if the memory had
>been zeroed because it sends bogus information to the server. An analogous
>bug would be sending over the network unencrypted data which should have been
>encrypted. In both cases , to see the bugs one needs to think on the level of
>what the application wants and does not want to do , not on the low level
>details of the programming language. Some low level detail may accidentally
>eliminate some bug caused by a high level thinking oversight but this is
>entirely random so it could just as well make it worse.
>
>Another bug was with not handling correctly C arithmetic (see the page).
>Finally the not zeroing of memory happened because (from the link)
>
> Unfortunately, an optimizing compiler may remove this
> memset() or bzero() call, because the buffer is written to, but never
> again read from (an optimization known as Dead Store Elimination).
>
>so it's not due to undefined behaviour.
But actually the bug resulted in reading from the buffer. So the
assumption by the compiler that the buffer is never again read from is
wrong, and applying dead-store elimination to this memset() is wrong;
in other words, the compiler is buggy.
But of course the GCC maintainers don't accept this as a bug: They say
that reading from the buffer after the free() is undefined behaviour,
therefore does not happen, and therefore they are in their rights to
conjure up nasal demons and "optimize" the memset()/bzero() away. And
this is not an issue that could turn out one way or the other, this
memset()/bzero() is there exactly for mitigating information leaks,
such as the one that is the main reason of the CVE.
It is telling that you do not understand how the nasal-demon
interpretation of C allowed the compiler to "optimize" the
memset()/bzero() away. So much for Andrew Haley's claim that it is
"not difficult" to write "well-defined" C, and your defense of that
stance.
>I couldn't tell you off the top of my head but I'm sure you could get the
>answer on comp.lang.c very quickly. Looking at the big picture , it could
>be that C is not a suitable back-end for Forth after all even if you got
>lucky for a number of years and your code (which presumably was exhibiting
>SUB) worked as intended.
I think that nasal-demon C is not a suitable language for anything.
> Note that this may turn out to be an opportunity for
>Forth : it may be that Forth itself is a more suitable back-end than C for other
>programming languages
Yes.
>A
>*constructive* thing to do (as opposed to complaining) would be to describe
>what guarantees with regard to C pointer comparisons on top of the C standard
>would be needed to do what you want to do. Then you could ask on comp.lang.c
>or some compiler mailing list whether these additional guarantees can be
>offered by using some appropriate flag and if not how easy would be to implement
>them as an extension.
If you think that's a promising approach, go ahead. My experience is
that they always tell you to go to the C standards committee.
>Undefined behaviour is an unfortunate side effect of 3 factors :
>
>1. The desire to allow implementors optimisations.
>2. Inability to reconcile previous (i.e. before the standard) existing practices
> therefore any attempt to define the behaviour more narrowly would unfairly
> privilege some implementations (or architectures) over others.
>3. The desire to not make the standard too large.
That was all fine and dandy in the good old days of PCC and early GCC,
but in recent years the compiler maintainers went insane and use them
as justification for miscompiling (they call it "optimizing") as many
programs as possible, with some exceptions, in particular, standard
benchmarks. Paying customers are probably also not treated as badly
as the rest of us; hmm, so nasal demons may be part of the business
models.
> But noone *likes* undefined behaviour , it is just a trade off.
The GCC and Clang compiler maintainers love it. For them reason 2 and
3 don't apply, yet with every release they miscompile more and more
cases that are undefined in the standard for reasons 2 and 3; e.g.,
signed integer overflow.
>If
>programmers get convinced to avoid undefined behaviour then this ultimately
>will make code more predictable not less.
So you love nasal demons, too.
Many programmers are convinced. But because there is actually no good
way to write code without undefined behaviour, we will get programs by
convinced programmers that have fewer undefined behaviours, but it
will still be there; and the next release of the compiler breaks some
code, the convinced programmers get busy fixing it, and the next
release breaks some more code. Bottom line: slightly faster
benchmarks, more programs that break, and more work for the C
programmers without any benefit.
Of course, if you are a programmer from a paying customer, you may be
able to exert enough pressure that they don't break your program. Or
if you are a programmer from a company that distributes binaries only,
you just use a compiler version that works, and don't downgrade to
newer versions. It's free software that's written by volunteers that
is hit the hardest by nasal demons. That is probably in line with the
sponsors of Clang/LLVM, but for GCC, I doubt it.
>But then there are always some
>stubborn ones like yourself or
>http://www.open-chess.org/viewtopic.php?f=5&t=2519 where Robert Hyatt
>insists that SUB should still do what he wants just because it did in the past.
So you think that using strcpy to do an overlapping backwards copy is
SUB, i.e., "not defined according to *anything*". Interesting.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 06:36 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-01 14:57 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 11:55 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-02 15:24 +0000
Re: LLVM and Forth rickman <gnuarm@gmail.com> - 2017-04-01 11:21 -0400
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 11:57 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-02 04:02 -0500
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-02 06:35 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-02 14:41 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 01:09 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-03 05:32 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 13:52 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 07:59 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 16:08 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 12:22 -0500
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-03 20:10 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 22:19 -0700
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 16:12 +0200
Re: LLVM and Forth Walter Banks <walter@bytecraft.com> - 2017-04-05 17:27 -0400
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 14:29 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 03:17 -0500
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 05:04 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 12:55 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 10:08 -0500
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 17:05 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-04 11:29 -0500
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 19:11 +0200
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-04 21:29 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-05 15:01 +0000
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-05 18:42 +0100
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 04:01 -0500
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 18:48 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-06 18:42 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-07 04:02 -0500
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 21:18 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 22:43 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 20:54 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-09 14:53 +0000
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 00:38 +0000
Re: LLVM and Forth James Kuyper <jameskuyper@verizon.net> - 2017-04-09 22:46 -0400
Re: LLVM and Forth Robert Wessel <robertwessel2@yahoo.com> - 2017-04-09 22:27 -0500
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 12:36 +0000
Re: LLVM and Forth Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-10 14:09 +0100
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 13:07 +0000
Re: LLVM and Forth Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-10 16:18 +0100
Re: LLVM and Forth "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-10 11:51 -0400
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-12 21:32 +0000
Re: LLVM and Forth "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-12 18:29 -0400
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-12 15:29 -0700
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-13 02:55 +0200
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-10 18:38 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-10 11:54 -0500
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-10 10:17 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 17:02 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 10:03 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 03:25 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-04 11:24 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 04:55 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-04 12:28 +0000
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-04 16:16 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 15:38 +0200
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 16:06 +0200
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 17:57 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-05 00:44 -0400
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 00:00 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 08:47 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-05 11:04 -0500
Re: LLVM and Forth john <anon@example.com> - 2017-04-05 18:04 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-05 13:04 -0700
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-05 18:20 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 20:14 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 12:33 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 10:49 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 18:55 +0100
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 20:41 +0000
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 21:47 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 21:56 +0100
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 23:59 -0400
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-06 17:10 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-07 03:33 -0400
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 22:48 +0000
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-09 15:06 -0400
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 22:45 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-09 14:27 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-09 21:26 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-09 13:35 -0400
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-09 14:07 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 12:16 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 20:27 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 05:24 -0400
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 03:26 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-06 04:05 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 06:50 -0500
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 05:23 -0400
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 04:44 -0500
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 10:57 +0100
Re: LLVM and Forth peter.m.falth@gmail.com - 2017-04-05 05:29 -0700
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-14 02:04 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 14:03 +0200
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 00:44 +0000
Re: LLVM and Forth alex@rivadpm.com - 2017-04-16 05:53 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 15:43 +0000
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 22:27 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-18 02:45 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-18 18:26 +0100
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 19:51 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 19:08 +0100
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 20:42 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 20:29 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 20:48 +0100
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-21 11:49 +0000
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-03 20:39 -0400
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-02 21:15 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-02 15:18 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 13:07 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 09:45 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 22:52 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 15:25 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 09:35 +0100
Re: LLVM and Forth antispam@math.uni.wroc.pl - 2017-04-06 01:36 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 22:00 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 09:52 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-06 20:15 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-03 05:20 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 17:11 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 17:43 +0100
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 10:53 -0700
csiph-web