Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #1740 > unrolled thread

Alternative C compilers on x86_64 Linux?

Back to article view | Back to comp.compilers

Contents

  Alternative C compilers on x86_64 Linux? arnold@skeeve.com (Aharon Robbins) - 2016-09-02 03:01 +0000
    Re: Alternative C compilers on x86_64 Linux? jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-05 00:20 +0200
      Re: Alternative C compilers on x86_64 Linux? alexfrunews@gmail.com - 2016-09-05 17:26 -0700
        Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-09 12:31 +0100
          Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-09 16:06 +0000
          Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux? Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2016-09-10 00:38 +0200
    Re: Alternative C compilers on x86_64 Linux? Nemo <nemo@invalid.invalid> - 2016-09-04 18:32 -0400
    Re: Alternative C compilers on x86_64 Linux? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-04 23:48 +0000
    Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-05 13:19 +0100
      Re: Alternative C compilers on x86_64 Linux? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-06 02:15 +0000
        Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-06 21:35 +0100
          Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux? George Neuner <gneuner2@comcast.net> - 2016-09-08 11:58 -0400
            Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-08 22:54 +0000
              Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux? George Neuner <gneuner2@comcast.net> - 2016-09-09 00:51 -0400
                Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-09 06:05 +0000
                  Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux? George Neuner <gneuner2@comcast.net> - 2016-09-09 14:02 -0400
                    Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-09 19:57 +0000
        Re: duplicate cases, was Alternative C compilers on x86_64 Linux? Andy Walker <anw@cuboid.co.uk> - 2016-09-07 17:01 +0100
    Re: Alternative C compilers on x86_64 Linux? Florian Weimer <fw@deneb.enyo.de> - 2016-09-05 20:06 +0200
    Re: Alternative C compilers on x86_64 Linux? alexfrunews@gmail.com - 2016-09-05 17:22 -0700
      Re: Alternative C compilers on x86_64 Linux? Kaz Kylheku <221-501-9011@kylheku.com> - 2016-09-06 02:18 +0000
    Re: Alternative C compilers on x86_64 Linux? rockbrentwood@gmail.com - 2016-09-07 17:00 -0700
    Re: Alternative C compilers on x86_64 Linux? arnold@skeeve.com (Aharon Robbins) - 2016-09-12 18:42 +0000
      Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-12 22:37 +0100
        Re: Alternative C compilers on x86_64 Linux? arnold@skeeve.com (Aharon Robbins) - 2016-09-13 17:35 +0000
          Re: Alternative C compilers on x86_64 Linux? arnold@skeeve.com (Aharon Robbins) - 2016-09-14 18:14 +0000
    Re: Alternative C compilers on x86_64 Linux? rugxulo@gmail.com - 2016-09-26 15:29 -0700
      Re: Alternative C compilers on x86_64 Linux? arnold@skeeve.com (Aharon Robbins) - 2016-09-27 05:40 +0000
        Re: Alternative C compilers on x86_64 Linux? rugxulo@gmail.com - 2016-09-27 16:36 -0700
          Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-28 18:16 +0100
            Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-29 14:03 +0100
              Re: Alternative C compilers on x86_64 Linux? George Neuner <gneuner2@comcast.net> - 2016-09-29 22:57 -0400
              Re: Alternative C compilers on x86_64 Linux? Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2016-09-30 05:03 +0200
                Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-30 12:00 +0100
                  Re: Alternative C compilers on x86_64 Linux? Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2016-09-30 20:15 +0200
                    Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-10-01 22:17 +0100
              Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-09-30 12:28 +0100
                Re: Alternative C compilers on x86_64 Linux? BartC <bc@freeuk.com> - 2016-10-17 22:49 +0100
          Re: Alternative C compilers on x86_64 Linux? George Neuner <gneuner2@comcast.net> - 2016-09-28 21:24 -0400
        Re: Alternative C compilers on x86_64 Linux? George Neuner <gneuner2@comcast.net> - 2016-09-28 01:01 -0400
          Re: Alternative C compilers on x86_64 Linux? arnold@skeeve.com (Aharon Robbins) - 2016-09-29 02:55 +0000
        Re: Alternative C compilers on x86_64 Linux? arnold@skeeve.com - 2016-09-29 05:30 -0600
          Re: Alternative C compilers on x86_64 Linux? arnold@skeeve.com (Aharon Robbins) - 2016-09-30 10:13 +0000

Page 1 of 3  [1] 2 3  Next page →

#1740 — Alternative C compilers on x86_64 Linux?

Hi.

Can I get recommendations for other (free) C compilers besides GCC and CLANG?
I've been using the revived PCC for gawk development since it's faster
than GCC, but recently it's developed a bug where it won't compile the
current (valid) code.

LCC seems to be 32 bit only and requires very manual configuration.

TinyCC is blindingly fast, and can compile gawk, but is broken in that
it won't diagnose duplicate case statements inside switch. The developers
don't consider this a problem. So I refuse to use it.

In short, I'm looking for a faster compiler that actually works.

Thanks,

Arnold
--
Aharon (Arnold) Robbins 		arnold AT skeeve DOT com

[toc] | [next] | [standalone]

#1741

Le 02/09/2016 ` 05:01, Aharon Robbins a icrit :
 > Hi.
 >
 > Can I get recommendations for other (free) C compilers besides GCC
and CLANG?
 > I've been using the revived PCC for gawk development since it's faster
 > than GCC, but recently it's developed a bug where it won't compile the
 > current (valid) code.
 >
 > LCC seems to be 32 bit only and requires very manual configuration.
 >
 > TinyCC is blindingly fast, and can compile gawk, but is broken in that
 > it won't diagnose duplicate case statements inside switch. The developers
 > don't consider this a problem. So I refuse to use it.
 >
 > In short, I'm looking for a faster compiler that actually works.
 >
 > Thanks,
 >
 > Arnold

Hi Arnold

lcc-win, a 64 bit version of lcc, runs under linux but I have never
tried to make it a real compiler system since there are no customers.

Nobody buys compilers in linux, so, either you use gcc or clang, or you
just write your own. As you write above you want it "free". That is why
I have never developed under linux, since I do not like to work for
free.  Why should I?

I understand the developers of TinyCC.

Why should they care? If you write duplicate switch cases its not their
fault, its yours.

It would take me several weeks of work to get lcc-win running.

It is very fast. It produces much better code than the original lcc, and
generates 64 bit code. That time would be just to get it running using
gas (the gnu assembler) and the gnu linker.

Other thing (also a derivative of lcc) that I have developed under linux
is a JIT. It will compile a source file into a buffer, and after
compiling it will jump into the generated code and execute it in the fly.

I developed that because I had a customer that wanted a linux version.

Why there are no other compilers besides gnu/clang?

Because, as you said, everybody assumes that no compensation will be
given to the guy/team that develops them.

Then linux is stuck with a single compiler that is very slow.

The intel compiler, the best compiler for the x86 environment runs under
linux. But that costs more than 700 dollars if memory serves.

You get what you pay for.

[toc] | [prev] | [next] | [standalone]

#1747

On Sunday, September 4, 2016 at 3:56:56 PM UTC-7, jacobnavia wrote:
> Why should they care? If you write duplicate switch cases its not their
> fault, its yours.

It is a constraint violation, and a trivial one, that the compiler
must identify and report instead of silently producing code that is
broken or appears to work by chance.

Alex

[toc] | [prev] | [next] | [standalone]

#1758 — Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux?

On 06/09/2016 01:26, alexfrunews@gmail.com wrote:
> On Sunday, September 4, 2016 at 3:56:56 PM UTC-7, jacobnavia wrote:
>> Why should they care? If you write duplicate switch cases its not their
>> fault, its yours.
>
> It is a constraint violation, and a trivial one, that the compiler
> must identify and report instead of silently producing code that is
> broken or appears to work by chance.

This is C. There are already plenty of things that it lets through that
are probably errors, and which are likely to crash the program.

For example, take a pointer to an array of ints, P. You'd normally
access an int by dereferencing P then applying the index: (*P)[i].

But if, by mistake, you index first then dereference: *(P[i]), then this
still compiles. But is likely to go wrong badly.

By contrast, an inadvertent duplicate case label is a 'soft' error; the
program just won't give the expected results. It's not going to read or
write all over memory it shouldn't, or at least not as directly as will
happen if the compiler blatantly allows pointers (to single targets) and
arrays to be interchanged.

--
Bartc

[toc] | [prev] | [next] | [standalone]

#1759 — Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux?

On 2016-09-09, BartC <bc@freeuk.com> wrote:
> On 06/09/2016 01:26, alexfrunews@gmail.com wrote:
>> On Sunday, September 4, 2016 at 3:56:56 PM UTC-7, jacobnavia wrote:
>>> Why should they care? If you write duplicate switch cases its not their
>>> fault, its yours.
>>
>> It is a constraint violation, and a trivial one, that the compiler
>> must identify and report instead of silently producing code that is
>> broken or appears to work by chance.
>
> This is C. There are already plenty of things that it lets through that
> are probably errors, and which are likely to crash the program.

That's true. The major real-world consequence of not producing
an ISO-C required diagnostic is that the code will fail to compile
on compilers other than the one with which it was developed.

Though you may have some dead code in a switch statement, and that could
be a bug, on the other hand, you test the code.  It's not a bug if there
is no external test case which reproduces an issue.

And that brings us to Aharon's original point about looking for
a compiler that can be used for *development*.  A compiler used for
development should have excellent diagnostics, which helps make the code
cleanly portable to other compilers.

> By contrast, an inadvertent duplicate case label is a 'soft' error; the
> program just won't give the expected results.

Or, as I argue about, there might in fact be no bug: the correct fix
might in fact be just to remove the duplicate label and all the code
under it.

Some ISO C required diagnostics do help uncover real errors, which
helps, in spite of the C language having lots of pitfalls and holes.

Imagine if you could assign any scalar type to any other without needing
a cast, and with no diagnostic: double x = "abc", and so on.
Or call functions without any parameter checking.

The type checking in C does a lot for improving the reliability of C
programs, even though it falls far short of repairing all the holes
and pitfalls.

[toc] | [prev] | [next] | [standalone]

#1763 — Re: diagnosing C errors, was Alternative C compilers on x86_64 Linux?

BartC schrieb:

> For example, take a pointer to an array of ints, P. You'd normally
> access an int by dereferencing P then applying the index: (*P)[i].
>
> But if, by mistake, you index first then dereference: *(P[i]), then this
> still compiles. But is likely to go wrong badly.

AFAIR (according to K&R) p[i] is equivalent to *(p+i), only a different
syntax for the same semantics. In contrast to C++ the C language doesn't
include arrays as special types, proper usage is up to the coder.

> By contrast, an inadvertent duplicate case label is a 'soft' error; the
> program just won't give the expected results. It's not going to read or
> write all over memory it shouldn't, or at least not as directly as will
> happen if the compiler blatantly allows pointers (to single targets) and
> arrays to be interchanged.

A C switch statement can be translated in various ways, depending on
the sparseness of the values and other conditions. A good compiler
choses the most efficient model for every single statement. At least
the linker should bark on duplicate compiler-generated labels.


Some more thoughts:

I'd think that everybody in this thread should specify the C standard
he relies on. There is a broad range from K&R to C99, or whatever is
the current Ansi standard. But I guess none of the contributors ever
spent the money and time to read a standard, where many "undefined"
and "compiler specific" cases are described in detail. It's a bad idea
to rely on the (mis)behaviour of some specific compiler, in a
discussion about the semantics of the C language.


In former times it was common practice to use multiple C compilers, one
for good diagnostics, one for good debugging features, and one for most
efficient executable code. At that time the Watcom compiler was said to
be the most reliable compiler, dunno about todays version (Open Watcom).

The old Microsoft compilers were poor in diagnostics and efficiency,
every official sample program contained more than 50 bugs and flaws,
which were found by the Borland (BC...) compiler after removing excess
(almost wrong) type casts. But it's not the compiler to blame, instead
it's the coder that disallows the compiler to perform essential checks,
and disables or ignores compiler warnings. It's bad practice to force
the compiler to accept some code, with the poor excuse "else it doesn't
do what I want". Who wants better diagnostics should consider to use C++
instead of C, and make use of the improved syntax to let the compiler
perform more checks.

Even newer MS compilers tend to follow their own language definition,
not any Ansi standard. Other compilers, like gcc, allow to specify the
standard to apply, eventually to enable/disable compiler specific
extensions of the language. Any statement about compiler specific
behaviour is meaningless without the specification of the compiler and
option settings.

DoDi

[toc] | [prev] | [next] | [standalone]

#1742

On 01/09/2016 23:01, Aharon Robbins wrote:
> Hi.
>
> Can I get recommendations for other (free) C compilers besides GCC and CLANG?

Intel and Oracle both have free (but not open-source) compilers.

N.

[toc] | [prev] | [next] | [standalone]

#1743

On 2016-09-02, Aharon Robbins <arnold@skeeve.com> wrote:
> Can I get recommendations for other (free) C compilers besides GCC and CLANG?
> I've been using the revived PCC for gawk development since it's faster
> than GCC, but recently it's developed a bug where it won't compile the
> current (valid) code.

Hi Aharon,

One idea is to treat C++ as a C dialect; then the GCC and Clang
C++ compilers are an option.

You can't use C features that aren't in C++ and vice versa.
Except those that you can hide behind a macro that is conditionally
defined for C and C++. I do this with casts, which is useful:

#ifdef __cplusplus
#define strip_qual(TYPE, EXPR) (const_cast<TYPE>(EXPR))
#define convert(TYPE, EXPR) (static_cast<TYPE>(EXPR))
#define coerce(TYPE, EXPR) (reinterpret_cast<TYPE>(EXPR))
#else
#define strip_qual(TYPE, EXPR) ((TYPE) (EXPR))
#define convert(TYPE, EXPR) ((TYPE) (EXPR))
#define coerce(TYPE, EXPR) ((TYPE) (EXPR))
#endif

The code compiles as C, but if treated as C++, it benefits
from these more constrained, safer casts.

[toc] | [prev] | [next] | [standalone]

#1744

On 02/09/2016 04:01, Aharon Robbins wrote:

> TinyCC is blindingly fast, and can compile gawk, but is broken in that
> it won't diagnose duplicate case statements inside switch. The developers
> don't consider this a problem. So I refuse to use it.
>
> In short, I'm looking for a faster compiler that actually works.

I'm quite impressed with Tiny CC. I'd considered it a toy compiler that
could only compile a small subset of the language until I actually tried it.

And yes, on my Win64 version, it does seem to ignore duplicate 'case'
labels.

But TCC does have problem with compiling switch statements; although the
code it generates isn't that great anyway, that for switches is slower.

I suspect it just compiles switch as an if-else chain. Which might
explain why duplicate case labels are ignored if that conversion is done
at at early stage.

(Because a duplicate condition in an if-else chain is fine. For a
jump-table of course, a duplicate label is ambiguous so can't be allowed.)

--
Bartc

[toc] | [prev] | [next] | [standalone]

#1748

On 2016-09-05, BartC <bc@freeuk.com> wrote:
> On 02/09/2016 04:01, Aharon Robbins wrote:
>
>> TinyCC is blindingly fast, and can compile gawk, but is broken in that
>> it won't diagnose duplicate case statements inside switch. The developers
>> don't consider this a problem. So I refuse to use it.
>>
>> In short, I'm looking for a faster compiler that actually works.
>
> I'm quite impressed with Tiny CC. I'd considered it a toy compiler that
> could only compile a small subset of the language until I actually tried it.
>
> And yes, on my Win64 version, it does seem to ignore duplicate 'case'
> labels.
>
> But TCC does have problem with compiling switch statements; although the
> code it generates isn't that great anyway, that for switches is slower.
>
> I suspect it just compiles switch as an if-else chain. Which might
> explain why duplicate case labels are ignored if that conversion is done
> at at early stage.
>
> (Because a duplicate condition in an if-else chain is fine. For a
> jump-table of course, a duplicate label is ambiguous so can't be allowed.)

A duplicate condition in an if-else chain is unreachable code, which is
probably a bug.

   if (foo) {
     ...
   } else if (foo) {
     /* unreachable */
   } else if (bar) {
     ...
   }

Duplicate cases are a constraint violation in ISO C, requiring a
diagnostic.

A duplicate label can also be just as "fine". Look, you can build a jump
table, and then just fill it without caring about duplicates:

  case 42:
  ...
  case 42:

No problem: just write to jumptable[42] twice, letting it the most
recently established address overrule the previous one.

Duplicate case label code can still be reachable, making the bugs
potentially more interesting:

  case 42: // suppose this is used
    ...
    break;
  case 19:
    ...
    /* fallthrough */
  case 42: // this isn't used, but fallthrough makes it reachable

--
TXR Programming Lanuage: http://nongnu.org/txr
Music DIY Mailing List:  http://www.kylheku.com/diy
ADA MP-1 Mailing List:   http://www.kylheku.com/mp1

[toc] | [prev] | [next] | [standalone]

#1751

On 06/09/2016 03:15, Kaz Kylheku wrote:
> On 2016-09-05, BartC <bc@freeuk.com> wrote:

>> I suspect [TCC] just compiles switch as an if-else chain. Which might
>> explain why duplicate case labels are ignored if that conversion is done
>> at at early stage.
>>
>> (Because a duplicate condition in an if-else chain is fine. For a
>> jump-table of course, a duplicate label is ambiguous so can't be allowed.)
>
> A duplicate condition in an if-else chain is unreachable code, which is
> probably a bug.
>
>    if (foo) {
>      ...
>    } else if (foo) {
>      /* unreachable */
>    } else if (bar) {
>      ...
>    }

It's not necessarily unreachable. For example:

  if (foo()) { ...}
  elsif if (foo()) { ... }

foo() could return false the first time and true the second time.

In general detecting duplication conditions for if-else can involve
comparing expressions of arbitrary complexity, and it can be harder to
determine if they will always yield the same value.

(Unreachable code can also be made reachable by inserting a label with a
goto from elsewhere.)

> Duplicate cases are a constraint violation in ISO C, requiring a
> diagnostic.

> A duplicate label can also be just as "fine". Look, you can build a jump
> table, and then just fill it without caring about duplicates:
>
>   case 42:
>   ...
>   case 42:
>
> No problem: just write to jumptable[42] twice, letting it the most
> recently established address overrule the previous one.

Some duplicate cases might be fine:

  case 10: case 10:

as they both end up at the same place (and the 10s can be hidden behind
different macros or enums). But an error is still reported.

> Duplicate case label code can still be reachable, making the bugs
> potentially more interesting:
>
>   case 42: // suppose this is used
>     ...
>     break;
>   case 19:
>     ...
>     /* fallthrough */
>   case 42: // this isn't used, but fallthrough makes it reachable

That's another way for duplicate cases to be meaningful, except that you
can't control which of the case 42s is put into the jump table. Unless
(in this case) you only use the first, so writing to jumptable[42] once
not twice.

But the sensible thing for switch is to report all duplicates (with a
possible concession when labels are at the same location, although that
could mask an error).

--
Bartc

[toc] | [prev] | [next] | [standalone]

#1754 — Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux?

On Tue, 6 Sep 2016 21:35:30 +0100, BartC <bc@freeuk.com> wrote:

>On 06/09/2016 03:15, Kaz Kylheku wrote:
>
>> A duplicate condition in an if-else chain is unreachable code, which is
>> probably a bug.
>>
>>    if (foo) {
>>      ...
>>    } else if (foo) {
>>      /* unreachable */
>>    } else if (bar) {
>>      ...
>>    }
>
>It's not necessarily unreachable. For example:
>
>  if (foo()) { ...}
>  elsif if (foo()) { ... }
>
>foo() could return false the first time and true the second time.

In such cases foo doesn't need to be function - it only needs to be a
[moral equivalent of a C] volatile to exhibit strange behavior.

Writing an IF chain with multiple identical tests probably should be a
style warning in and of itself.


>In general detecting duplication conditions for if-else can involve
>comparing expressions of arbitrary complexity, and it can be harder to
>determine if they will always yield the same value.

Yes.  It's infeasible in most circumstances.

George

[toc] | [prev] | [next] | [standalone]

#1755 — Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux?

On 2016-09-08, George Neuner <gneuner2@comcast.net> wrote:
> On Tue, 6 Sep 2016 21:35:30 +0100, BartC <bc@freeuk.com> wrote:
>
>>On 06/09/2016 03:15, Kaz Kylheku wrote:
>>
>>> A duplicate condition in an if-else chain is unreachable code, which is
>>> probably a bug.
>>>
>>>    if (foo) {
>>>      ...
>>>    } else if (foo) {
>>>      /* unreachable */
>>>    } else if (bar) {
>>>      ...
>>>    }
>>
>>It's not necessarily unreachable. For example:
>>
>>  if (foo()) { ...}
>>  elsif if (foo()) { ... }
>>
>>foo() could return false the first time and true the second time.
>
> In such cases foo doesn't need to be function - it only needs to be a
> [moral equivalent of a C] volatile to exhibit strange behavior.

Two occurrences of an impure expression aren't the same condition.

If a compiler wants to rearrange the code so that the result of such
an expression is to appear in multiple places (where in the original
source language, the corresponding expression appears just once), it
must introduce a temporary variable to hold the result, and propagate
the variable. Otherwise the multiple evaluations will lead to
unpleasant surprised.

   ;; poor: copies of code fragment (foo) literally proliferated

  (let ((code-fragment '(foo))
        (temp (gensym)))
    `(cond (,code-fragment ...)
           (,code-fragment ...) ;; not same; potentially reachable!
             ...)))

  ;; correct:

  (let ((code-fragment '(foo))
        (temp (gensym)))
    `(let ((,temp ,code-fragment)) ;; eval code fragment to temporary
       (cond (,temp ...) ;; proliferate temporary
             (,temp ...) ;; unreachable!
             ...)))

Anyway, this was originally about translating C switch statements, where
the conditions are pure expressions, being integer constants. "else if
(foo()) ..." is an unlikely translation of a standard C switch case.

[toc] | [prev] | [next] | [standalone]

#1756 — Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux?

On Thu, 8 Sep 2016 22:54:13 +0000 (UTC), Kaz Kylheku <221-501-9011@kylheku.com> wrote:

>On 2016-09-08, George Neuner <gneuner2@comcast.net> wrote:
>> On Tue, 6 Sep 2016 21:35:30 +0100, BartC <bc@freeuk.com> wrote:
>>
>>>On 06/09/2016 03:15, Kaz Kylheku wrote:
>>>
>>>> A duplicate condition in an if-else chain is unreachable code, which is
>>>> probably a bug.
>>>>
>>>>    if (foo) {
>>>>      ...
>>>>    } else if (foo) {
>>>>      /* unreachable */
>>>>    } else if (bar) {
>>>>      ...
>>>>    }
>>>
>>>It's not necessarily unreachable. For example:
>>>
>>>  if (foo()) { ...}
>>>  elsif if (foo()) { ... }
>>>
>>>foo() could return false the first time and true the second time.
>>
>> In such cases foo doesn't need to be function - it only needs to be a
>> [moral equivalent of a C] volatile to exhibit strange behavior.
>
>Two occurrences of an impure expression aren't the same condition.

That certainly is true ... for some definition ... but in the examples
given by Bart and me, the compiler has no basis to distinguish the
occurrences.


>If a compiler wants to rearrange the code so that the result of such
>an expression is to appear in multiple places (where in the original
>source language, the corresponding expression appears just once), it
>must introduce a temporary variable to hold the result, and propagate
>the variable. Otherwise the multiple evaluations will lead to
>unpleasant surprised.
>
>   ;; poor: copies of code fragment (foo) literally proliferated
>
>  (let ((code-fragment '(foo))
>        (temp (gensym)))
>    `(cond (,code-fragment ...)
>           (,code-fragment ...) ;; not same; potentially reachable!
>             ...)))
>
>  ;; correct:
>
>  (let ((code-fragment '(foo))
>        (temp (gensym)))
>    `(let ((,temp ,code-fragment)) ;; eval code fragment to temporary
>       (cond (,temp ...) ;; proliferate temporary
>             (,temp ...) ;; unreachable!
>             ...)))
>

Also true, but irrelevent.  The compiler can't assume semantics not in
evidence.   It's job is to faithfully translate the source as written
... not the source with better hygiene, and not the source as the
compiler thinks the programmer maybe intended.

Leaving aside for the moment what is legal in a C switch, if I tell
the compiler to call foo() multiple times, I expect it to do that.


>Anyway, this was originally about translating C switch statements, where
>the conditions are pure expressions, being integer constants. "else if
>(foo()) ..." is an unlikely translation of a standard C switch case.

But like any good Usenet discussion, it (d)evolved into something more
general.

Not every language with a CASE like construct has C's limitations on
specifying the alternatives.  Lisp certainly doesn't.   And it is
perfectly reasonable to implement the construct using an IF chain.

In fact, many (non-Lisp) compilers do implement CASE like constructs
using chained IF performing a binary search when the set of
alternatives is either sparse enough or large enough to make using a
dispatch table unweildy (or mostly empty).

George

[toc] | [prev] | [next] | [standalone]

#1757 — Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux?

On 2016-09-09, George Neuner <gneuner2@comcast.net> wrote:
> But like any good Usenet discussion, it (d)evolved into something more
> general.
>
> Not every language with a CASE like construct has C's limitations on
> specifying the alternatives.  Lisp certainly doesn't.

Yes, it does, in fact. The labels in Lisp case are literals that are
embedded in the CASE syntax itself, and not evaluated. They are
compared to the input value using EQL equality. Duplicate cases
are a bug, which is not required to be diagnosed.

CLISP:

[1]> (case 'a (a 1) (a 2))  ;; (a 2) unreachable
1
[2]> (compile nil (lambda () (case 'a (a 1) (a 2))))
WARNING: Duplicate CASE label A : (CASE 'A (A 1) (A 2))
#<COMPILED-FUNCTION NIL> ;
1 ;
NIL

> In fact, many (non-Lisp) compilers do implement CASE like constructs
> using chained IF performing a binary search when the set of
> alternatives is either sparse enough or large enough to make using a
> dispatch table unweildy (or mostly empty).

Still, duplicates which are static literals should be diagnosed,
even if computed labels are allowed that can produce duplicates
at run time, and that isn't diagnosed.

   case value of
     computed():
       ...
     computed(): # at compile time, we trust this is different
       ...
     3:
       ...
     3: # obviously clashing, diagnose damn thing!
   endcase

[toc] | [prev] | [next] | [standalone]

#1760 — Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux?

On Fri, 9 Sep 2016 06:05:44 +0000 (UTC), Kaz Kylheku
<221-501-9011@kylheku.com> wrote:

>On 2016-09-09, George Neuner <gneuner2@comcast.net> wrote:
>> But like any good Usenet discussion, it (d)evolved into something more
>> general.
>>
>> Not every language with a CASE like construct has C's limitations on
>> specifying the alternatives.  Lisp certainly doesn't.
>
>Yes, it does, in fact. The labels in Lisp case are literals that are
>embedded in the CASE syntax itself, and not evaluated. They are
>compared to the input value using EQL equality. Duplicate cases
>are a bug, which is not required to be diagnosed.

Lisp does not restrict CASE "labels" to integers like C.  They can be
any of [at least] symbols, characters, integers or booleans.

And unlike C where booleans and characters are subsets of integer, in
Lisp they are discrete types.  Additionally symbols are a reference
type - a pointer to a structure.

So no!  Lisp does not have C's limitations.

George
[Lisp does restrict case labels to literals, so if two of them
are the same, that's a bug. -John]

[toc] | [prev] | [next] | [standalone]

#1761 — Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux?

On 2016-09-09, George Neuner <gneuner2@comcast.net> wrote:
> On Fri, 9 Sep 2016 06:05:44 +0000 (UTC), Kaz Kylheku
><221-501-9011@kylheku.com> wrote:
>
>>On 2016-09-09, George Neuner <gneuner2@comcast.net> wrote:
>>> But like any good Usenet discussion, it (d)evolved into something more
>>> general.
>>>
>>> Not every language with a CASE like construct has C's limitations on
>>> specifying the alternatives.  Lisp certainly doesn't.
>>
>>Yes, it does, in fact. The labels in Lisp case are literals that are
>>embedded in the CASE syntax itself, and not evaluated. They are
>>compared to the input value using EQL equality. Duplicate cases
>>are a bug, which is not required to be diagnosed.
>
> Lisp does not restrict CASE "labels" to integers like C.  They can be
> any of [at least] symbols, characters, integers or booleans.
> And unlike C where booleans and characters are subsets of integer, in
> Lisp they are discrete types.  Additionally symbols are a reference
> type - a pointer to a structure.

At the low level it's fairly similar because EQL compares most of
those types as machine words, with the exception of integers
(two distinct bignum objects denoting the same integer are EQL).

If none of the case labels are bignums (case's usual case), then EQ can
be used, and then boils down to a switch on machine words.

All the same tricks can be used: jump table, tree-search.

[toc] | [prev] | [next] | [standalone]

#1752 — Re: duplicate cases, was Alternative C compilers on x86_64 Linux?

On 06/09/16 03:15, Kaz Kylheku wrote:
> A duplicate condition in an if-else chain is unreachable code, which is
> probably a bug.

	I note the "probably", but there are several ways this can happen
legitimately:

  -- Language translation.  Suppose we start with [in some other language]
something like
	IF letter = 'q' THEN ...
	  ELIF letter IN ['a', 'e', 'i', 'o', 'u'] THEN ...
	  ELIF letter IN ['a' : 'z'] THEN ...
	FI
and this gets turned automatically into either an "if-else" chain or a
bunch of cases in C, where 'q' and the vowels are tested twice.

  -- Similar things can happen via macro expansion.  What the coder sees
is often only loosely related to what later stages of compilation see!

  -- Debugging.  Eg, you don't want to deal with 'q' now, there are other
bugs you want to catch first.  So you write
	if (letter == 'q') { error (19); }
	else if ...
in front of the code, and the "old" case 'q' is now unreachable.

	Of course, deciding what constructs deserve warnings is a very
difficult problem in general, perhaps esp in languages like C where the
"coder" is often an automaton rather than a human.

--
Andy Walker,
Nottingham.

[toc] | [prev] | [next] | [standalone]

#1745

* Aharon Robbins:

> Can I get recommendations for other (free) C compilers besides GCC and
> CLANG?

Earliers versions of the golang toolchain contained a C compiler
(derived from the Plan 9 toolchain) which was ported to various
platforms supported by Go at the time.

[toc] | [prev] | [next] | [standalone]

#1746

On Sunday, September 4, 2016 at 12:02:33 PM UTC-7, Aharon Robbins wrote:
> Can I get recommendations for other (free) C compilers besides GCC and CLANG?
> I've been using the revived PCC for gawk development since it's faster
> than GCC, but recently it's developed a bug where it won't compile the
> current (valid) code.
>
> LCC seems to be 32 bit only and requires very manual configuration.
>
> TinyCC is blindingly fast, and can compile gawk, but is broken in that
> it won't diagnose duplicate case statements inside switch. The developers
> don't consider this a problem. So I refuse to use it.
>
> In short, I'm looking for a faster compiler that actually works.

What is preventing you from doing most of development using, say, that
same TinyCC and then, when you think you're done with the round of
changes (bugfixes, improvements, new features) recompiling the coded
with gcc or clang and rerunning the tests to make sure there are no
issues (warnings, real bugs) missed because of the limitations of the
fast compiler? Given the nature of C, I think, it's always beneficial
to try your code with different compilers (and on different platforms)
to uncover portability and other problems.

I'm not recommending my Smaller C compiler because it's more limited
than TinyCC, although it does check for duplicate cases, but there are
a few others you might want to try out (all Windows only, AFAIK):

Pelles C
Digital Mars
Visual C++ Express

Alex

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.compilers

csiph-web