Re: Alternative C compilers on x86_64 Linux?

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

          From comp.compilers

Related articles
[4 earlier articles]
Re: Alternative C compilers on x86_64 Linux? bc@freeuk.com (BartC) (2016-09-05)
Re: Alternative C compilers on x86_64 Linux? fw@deneb.enyo.de (Florian Weimer) (2016-09-05)
Re: Alternative C compilers on x86_64 Linux? alexfrunews@gmail.com (2016-09-05)
Re: Alternative C compilers on x86_64 Linux? alexfrunews@gmail.com (2016-09-05)
Re: Alternative C compilers on x86_64 Linux? 221-501-9011@kylheku.com (Kaz Kylheku) (2016-09-06)
Re: Alternative C compilers on x86_64 Linux? 221-501-9011@kylheku.com (Kaz Kylheku) (2016-09-06)
Re: Alternative C compilers on x86_64 Linux? bc@freeuk.com (BartC) (2016-09-06)
Re: Alternative C compilers on x86_64 Linux? rockbrentwood@gmail.com (2016-09-07)
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linu gneuner2@comcast.net (George Neuner) (2016-09-08)
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linu 221-501-9011@kylheku.com (Kaz Kylheku) (2016-09-08)
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linu gneuner2@comcast.net (George Neuner) (2016-09-09)
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linu 221-501-9011@kylheku.com (Kaz Kylheku) (2016-09-09)
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linu gneuner2@comcast.net (George Neuner) (2016-09-09)
[22 later articles]
| List of all articles for this month |
From: BartC <bc@freeuk.com>
Newsgroups: comp.compilers
Date: Tue, 6 Sep 2016 21:35:30 +0100
Organization: A noiseless patient Spider
References: 16-09-001 16-09-005 16-09-009
Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="87943"; mail-complaints-to="abuse@iecc.com"
Keywords: C, optimize, errors
Posted-Date: 08 Sep 2016 11:11:44 EDT

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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.