Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #53464 > unrolled thread
| Started by | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| First post | 2014-11-26 21:54 +0100 |
| Last post | 2014-12-19 02:34 +0100 |
| Articles | 20 on this page of 177 — 31 participants |
Back to article view | Back to comp.lang.c
the language Rosario193 <Rosario@invalid.invalid> - 2014-11-26 21:54 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-26 21:56 +0100
Re: the language John Bode <jfbode1029@gmail.com> - 2014-11-26 13:45 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 11:52 +0100
Re: the language "Bill Cunningham" <nospam@nspam.invalid> - 2014-12-01 23:25 -0500
Re: the language "Bill Cunningham" <nospam@nspam.invalid> - 2014-12-02 00:56 -0500
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-04 14:52 +0100
Re: the language "Osmium" <r124c4u102@comcast.net> - 2014-12-04 08:07 -0600
Re: the language Geoff <geoff@invalid.invalid> - 2014-12-04 10:20 -0800
Re: the language Mark Storkamp <mstorkamp@yahoo.com> - 2014-11-26 15:11 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:16 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:18 +0100
Re: the language John Bode <jfbode1029@gmail.com> - 2014-11-26 13:12 -0800
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-11-27 00:37 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-11-27 01:13 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-11-26 22:45 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-27 07:41 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-27 08:12 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-27 01:43 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 11:56 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-28 09:08 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 20:58 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-28 19:22 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-02 02:59 +0100
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-02 02:53 +0000
Re: the language Les Cargill <lcargill99@comcast.com> - 2014-12-01 21:25 -0600
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-02 06:22 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-27 08:37 +0000
Re: the language Reinhardt Behm <rbehm@hushmail.com> - 2014-11-27 16:44 +0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-27 15:35 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-11-27 11:58 -0500
Re: the language jt@toerring.de (Jens Thoms Toerring) - 2014-11-27 22:44 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 09:52 +0100
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 12:53 -0800
Re: the language Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-11-28 10:07 +0100
Re: the language Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-11-28 14:57 +0100
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 13:09 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:01 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-28 14:46 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 13:16 -0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-28 22:09 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:40 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 14:42 -0800
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:22 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-28 23:09 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 16:14 -0800
Re: the language BartC <bc@freeuk.com> - 2014-11-29 01:42 +0000
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-11-29 01:42 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-29 04:03 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-01 00:55 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-02 05:42 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-11-28 19:25 -0500
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:21 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-01 14:02 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-05 10:18 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-07 08:25 +0000
Re: the language Öö Tiib <ootiib@hot.ee> - 2014-12-07 10:44 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-07 19:17 +0000
Re: the language Öö Tiib <ootiib@hot.ee> - 2014-12-07 15:48 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 05:45 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-08 03:27 -0800
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-08 06:00 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 06:17 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-08 03:37 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 12:53 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 04:21 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-16 12:43 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 14:46 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 00:23 +0000
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-17 07:01 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 07:22 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-17 11:56 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-17 05:43 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:30 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:41 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 14:34 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 02:15 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-17 22:31 -0500
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 17:19 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 07:52 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 17:21 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:15 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 01:20 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 07:48 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 07:40 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 12:54 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 09:54 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 15:19 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 11:00 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 16:13 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 11:27 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 16:45 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 13:48 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 19:10 +0000
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-12-19 21:17 -0600
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-12-19 21:32 -0600
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 16:49 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 17:00 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 13:57 -0500
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-19 14:31 -0800
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 20:29 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 20:36 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-17 07:18 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 15:45 +0000
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-17 16:50 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-17 17:24 +0000
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-18 02:07 -0600
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 12:04 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-18 08:06 -0500
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-18 08:30 -0500
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-19 00:11 -0500
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-19 07:00 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-19 08:43 -0800
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-19 23:29 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 00:37 -0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-20 08:45 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-20 09:45 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-20 03:17 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-18 06:09 -0800
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 14:30 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 14:23 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-18 08:18 -0800
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-20 12:22 -0500
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-20 13:36 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 11:43 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 11:37 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-20 20:10 +0000
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-21 15:02 -0600
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-21 22:02 +0000
Re: the language Stephen Sprunk <stephen@sprunk.org> - 2014-12-21 23:49 -0600
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-21 17:45 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-18 10:29 -0800
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-20 05:29 -0600
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-20 11:32 -0800
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-21 15:23 -0600
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-22 23:39 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-20 20:22 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-18 10:24 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:36 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-19 09:24 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 17:53 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-20 11:48 -0800
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-19 02:20 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 08:31 +0000
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-19 09:31 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 10:10 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-19 07:08 -0800
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-20 06:39 +0000
Re: the language John Forkosh <forkosh@panix.com> - 2014-12-20 07:32 +0000
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-04 17:02 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-04 12:40 -0500
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-04 18:02 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 09:47 -0500
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-05 15:14 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2015-01-05 08:42 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-06 00:14 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 13:19 -0500
Re: the language Richard Damon <Richard@Damon-Family.org> - 2015-01-04 15:59 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2015-01-04 14:30 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-04 15:44 -0800
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 13:36 -0500
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:07 +0100
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-02 23:16 +0100
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-03 02:23 -0800
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-03 15:55 +0100
Re: the language Nobody <nobody@nowhere.invalid> - 2014-12-03 15:42 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-04 04:49 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-04 09:07 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-04 10:08 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-04 11:49 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-05 12:32 +0100
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-04 22:17 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:17 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:12 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 23:15 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 23:50 +0100
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-19 02:34 +0100
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2014-12-18 14:23 +0000 |
| Message-ID | <5492e2da.407609@news.xs4all.nl> |
| In reply to | #54940 |
Richard Damon <Richard@Damon-Family.org> wrote: > On 12/18/14, 7:04 AM, Richard Bos wrote: > > Robert Wessel <robertwessel2@yahoo.com> wrote: > > > >> In fact there's a lively discussion going on about compilers doing > >> just that. Mike Stump (who's a GCC developer) has been arguing here > >> in c.l.c that compiler *are* allowed to make assumptions based on what > >> is technically undefined behavior when optimizing code. A number of > >> other folks are unhappy with that. > > > > They may be unhappy with that, but I can't see what arguments they can > > bring against it. Undefined behaviour is _undefined_, so if an optimiser > > wants to make use of it, it's free to do so. > > Just because the C standard says something is undefined, doesn't mean > that the compiler is free to do anything in that case. There may be a > second document defining that condition, and if the compiler claims > compliance to that document, it should follow that too. A very common > case is POSIX, which defines a number of things that would be undefined > in plain C. > > It isn't that far of a reach to say that if a compiler claims that it > generates code for processor X, that this means that if the manufacturer > of that processor defines the behavior of a certain operation that C > leaves as undefined, then that definition would apply to the C program > apparently doing that operation. Certainly, but optimisers tend to work _for_ that processor definition, not against it. Or rather, they tend to (in fact, are intended to) take advantage of operations that the processor definition defines, which aren't so defined in other circumstances. Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-18 08:18 -0800 |
| Message-ID | <lnwq5pc4nr.fsf@nuthaus.mib.org> |
| In reply to | #54940 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 12/18/14, 7:04 AM, Richard Bos wrote:
>> Robert Wessel <robertwessel2@yahoo.com> wrote:
>>
>>> In fact there's a lively discussion going on about compilers doing
>>> just that. Mike Stump (who's a GCC developer) has been arguing here
>>> in c.l.c that compiler *are* allowed to make assumptions based on what
>>> is technically undefined behavior when optimizing code. A number of
>>> other folks are unhappy with that.
>>
>> They may be unhappy with that, but I can't see what arguments they can
>> bring against it. Undefined behaviour is _undefined_, so if an optimiser
>> wants to make use of it, it's free to do so.
>
> Just because the C standard says something is undefined, doesn't mean
> that the compiler is free to do anything in that case.
That's *exactly* what it means, unless ...
> There may be a
> second document defining that condition, and if the compiler claims
> compliance to that document, it should follow that too. A very common
> case is POSIX, which defines a number of things that would be undefined
> in plain C.
Right.
> It isn't that far of a reach to say that if a compiler claims that it
> generates code for processor X, that this means that if the manufacturer
> of that processor defines the behavior of a certain operation that C
> leaves as undefined, then that definition would apply to the C program
> apparently doing that operation.
I disagree. The manufacturer of a processor might define the behavior
of the MUL instruction on overflow, for example. That has no direct
bearing on the behavior of C's "*" operator. An expression like `x * 4`
might not even use the MUL instruction. If you want to rely on the
behavior of the MUL instruction, write assembly code (or use a compiler
feature that lets you impose guarantees beyond those provided by the C
standard).
> To be fair, GCC isn't a "conforming" compiler out of the box, you need
> to use certain options to put it into conforming mode. Similarly, they
> provide options to make the code "conform" to the processor specifications.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2014-12-20 12:22 -0500 |
| Message-ID | <ifilw.1128836$yK.904633@fx14.iad> |
| In reply to | #54930 |
On 12/18/14, 7:04 AM, Richard Bos wrote: > Robert Wessel <robertwessel2@yahoo.com> wrote: > >> In fact there's a lively discussion going on about compilers doing >> just that. Mike Stump (who's a GCC developer) has been arguing here >> in c.l.c that compiler *are* allowed to make assumptions based on what >> is technically undefined behavior when optimizing code. A number of >> other folks are unhappy with that. > > They may be unhappy with that, but I can't see what arguments they can > bring against it. Undefined behaviour is _undefined_, so if an optimiser > wants to make use of it, it's free to do so. > > Richard > The C standard NEVER says something like "if you do X then the results are totally undefined", it only says that "if you do X then the results are undefined by this standard". The standard can't grant permission to act against the defined behavior of another standard that has been accepted by the compiler. The architecture documents of a machine will often document what the behavior of operations that the C standard leaves undefined, and in fact the reason the standard left them undefined was that, at least at the time the standard was being created, different machines were defining that behavior in wildly different ways, in some case beyond what would make reasonable implementation defined behavior. The question comes, having targeted code to a particular processor, has the implementation taken on the definition of those behaviors from the processor architecture document or not? I don't have a problem with the compiler having a mode where it ignores these definition and optimizes based on ignoring them, and fully using just C's definition of undefined behavior (like fast floating point optimizations can ignore some of the IEEE floating point requirements). While I would prefer that "conforming" mode be the default, I understand that there are "market pressures" that might make some non-conformance a default, these options need to be well described in the section on using the compiler in a conforming manner, and changes to this section prominently noted, and not just buried in a long list of optional settings and voluminous change logs. I would also contend that the implementer is being genuinely and deliberately unhelpful here. At the point where the compiler has determined that it can omit a section of code, it also knows that the programmer has done something questionable, and appears to be depending on undefined behavior, so it should at least, by default, issue a warning here (and perhaps then do the optimization). In some ways this behavior is worse than a compiler that on detection of a syntax error just prints the message "You have a syntax error in the program, I reject it, Good Bye" (with no identification of where it detected the error). This behavior is FULLY conforming to the standard, but is being unhelpful, but in this case it is being obvious about being unhelpful instead of being sneaky about it.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-12-20 13:36 -0500 |
| Message-ID | <m74fij$csc$1@dont-email.me> |
| In reply to | #55154 |
On 12/20/2014 12:22 PM, Richard Damon wrote: > On 12/18/14, 7:04 AM, Richard Bos wrote: >> Robert Wessel <robertwessel2@yahoo.com> wrote: >> >>> In fact there's a lively discussion going on about compilers doing >>> just that. Mike Stump (who's a GCC developer) has been arguing here >>> in c.l.c that compiler *are* allowed to make assumptions based on what >>> is technically undefined behavior when optimizing code. A number of >>> other folks are unhappy with that. >> >> They may be unhappy with that, but I can't see what arguments they can >> bring against it. Undefined behaviour is _undefined_, so if an optimiser >> wants to make use of it, it's free to do so. >> >> Richard >> > > The C standard NEVER says something like "if you do X then the results > are totally undefined", it only says that "if you do X then the results > are undefined by this standard". The standard can't grant permission to > act against the defined behavior of another standard that has been > accepted by the compiler. > > The architecture documents of a machine will often document what the > behavior of operations that the C standard leaves undefined, and in fact > the reason the standard left them undefined was that, at least at the > time the standard was being created, different machines were defining > that behavior in wildly different ways, in some case beyond what would > make reasonable implementation defined behavior. The C standard defines the behavior of C language constructs; the machine's architecture documents document the behavior of machine language instructions. It's a mistake, and one that's fundamental to this whole line of argument, to equate the two. Just because a machine has a shift operation that could be used to implement a C shift-expression, doesn't mean that a conforming implementation of C targeting that machine is required to use that particular instruction. The undefined consequences that could occur when misusing a C shift instruction are not, therefore, constrained to be the same as they would be if that machine instruction were used. It might seem perverse to produce any other result - until you consider optimizations. A shift expression could be optimized completely out of the generated code, or it could be combined with another expression, and the combination might be replaced by a different set of instructions that is better for some reason. As long as the alternative instructions have behavior that matches the standard's requirements, when it imposes some, it doesn't matter what the alternative code does when the behavior is undefined. > The question comes, having targeted code to a particular processor, has > the implementation taken on the definition of those behaviors from the > processor architecture document or not? It's not required to honor any particular mapping from C code to machine instructions, as long as the mapping it actually uses produces the same behavior when the behavior is defined. When the behavior is undefined, there are no restrictions on the generated code of any kind. > I don't have a problem with the compiler having a mode where it ignores > these definition and optimizes based on ignoring them, and fully using > just C's definition of undefined behavior (like fast floating point > optimizations can ignore some of the IEEE floating point requirements). > > While I would prefer that "conforming" mode be the default, I understand > that there are "market pressures" that might make some non-conformance a > default, these options need to be well described in the section on using > the compiler in a conforming manner, and changes to this section > prominently noted, and not just buried in a long list of optional > settings and voluminous change logs. It's possible for a compiler to conform fully to the C standard, and generate machine code that conforms fully to the specifications of the relevant documents, but have the generated machine code NOT be the same as that which you naively expect. If so, the behavior need not conform to any assumptions you made based upon that unjustified expectation. > I would also contend that the implementer is being genuinely and > deliberately unhelpful here. That depends entirely upon whether or not the optimization that produces unexpected results when the behavior is undefined, has corresponding benefits when the behavior is defined. If it does have such benefits, such as increased speed, then it's being helpful, not unhelpful. > ... At the point where the compiler has > determined that it can omit a section of code, it also knows that the > programmer has done something questionable, and appears to be depending > on undefined behavior, so it should at least, by default, issue a > warning here (and perhaps then do the optimization). It should only do so if the questionable nature of the code is clear; oftentimes, it is not, as least not from the point of view of the compiler. It's often easier for a human to notice that some code is questionable, than it is for the compiler. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-20 11:43 -0800 |
| Message-ID | <lnh9wq9kec.fsf@nuthaus.mib.org> |
| In reply to | #55157 |
James Kuyper <jameskuyper@verizon.net> writes:
[...]
> It's not required to honor any particular mapping from C code to machine
> instructions, as long as the mapping it actually uses produces the same
> behavior when the behavior is defined. When the behavior is undefined,
> there are no restrictions on the generated code of any kind.
And if such a particular mapping were required, there would have to be a
document specifying it. I've never seen or heard of a document
requiring "+" to be mapped to ADD, ADDL, ADDU, ADDF, etc., depending on
the types of the operands. Such a document would have to exist for
every language/CPU pair; Ada has different semantics than C, for
example, and you'd need different requirements for Ada's "+" than for
C's "+".
(The instruction mnemonics are illustrative, not necessarily real.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-20 11:37 -0800 |
| Message-ID | <lnlhm29koo.fsf@nuthaus.mib.org> |
| In reply to | #55154 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 12/18/14, 7:04 AM, Richard Bos wrote:
>> Robert Wessel <robertwessel2@yahoo.com> wrote:
>>> In fact there's a lively discussion going on about compilers doing
>>> just that. Mike Stump (who's a GCC developer) has been arguing here
>>> in c.l.c that compiler *are* allowed to make assumptions based on what
>>> is technically undefined behavior when optimizing code. A number of
>>> other folks are unhappy with that.
>>
>> They may be unhappy with that, but I can't see what arguments they can
>> bring against it. Undefined behaviour is _undefined_, so if an optimiser
>> wants to make use of it, it's free to do so.
>
> The C standard NEVER says something like "if you do X then the results
> are totally undefined", it only says that "if you do X then the results
> are undefined by this standard". The standard can't grant permission to
> act against the defined behavior of another standard that has been
> accepted by the compiler.
True. For example, a C implementation that claims conformance to POSIX
cannot have CHAR_BIT != 8.
> The architecture documents of a machine will often document what the
> behavior of operations that the C standard leaves undefined, and in fact
> the reason the standard left them undefined was that, at least at the
> time the standard was being created, different machines were defining
> that behavior in wildly different ways, in some case beyond what would
> make reasonable implementation defined behavior.
Presumably an Intel processor manual, for example, will define the
behavior of the ADD instruction for all possible operand values, with no
undefined or unspecified cases. I do not believe that that imposes any
requirements on the behavior of a C compiler.
Can you cite an architecture document that places requirements on the
behavior of a C "+" operator with two operands of type int, beyond the
requirements imposed by the C standard? Any statements about the
semantics of any particular CPU instruction, or that use the phrase
"integer addition" without reference to any programming language, do not
count.
Do architecuture documents impose requirements on the behavior of "+"
for *all* languages? Ada? Python? Or is C singled out?
Suppose a CPU document says that 32-bit signed ADD performs the usual
2's-complement wraparound on overflow. Suppose a C compiler generates
code for "+" that traps on overflow. That would not violate any
requirement of the C standard. Do you claim that it would violate some
other requirement? Please be specific.
> The question comes, having targeted code to a particular processor, has
> the implementation taken on the definition of those behaviors from the
> processor architecture document or not?
Not.
Of course it can translate "+" to ADD as long as the semantics of ADD
satisfy the semantics of "+", but I'm aware of no requirement to do so
in all cases. I'm certain there's no such requirement in the C
standard; I don't believe there's any such requirement elsewhere (though
I understand that you wish there were).
If you want assembly language, you know where to find it.
[...]
> I would also contend that the implementer is being genuinely and
> deliberately unhelpful here. At the point where the compiler has
> determined that it can omit a section of code, it also knows that the
> programmer has done something questionable, and appears to be depending
> on undefined behavior, so it should at least, by default, issue a
> warning here (and perhaps then do the optimization).
It would be easier to discuss that point if you could provide a concrete
example of a compiler failing to issue a helpful warning when it
performs a potentially disruptive optimization. An example using gcc
would be easiest for me to deal with. I'm skeptical that compiler
implementers are *deliberately* unhelpful, but I'm willing to be
convinced.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-12-20 20:10 +0000 |
| Message-ID | <m74l42$tf9$1@speranza.aioe.org> |
| In reply to | #55161 |
Keith Thompson <kst-u@mib.org> wrote: (snip) > It would be easier to discuss that point if you could provide a concrete > example of a compiler failing to issue a helpful warning when it > performs a potentially disruptive optimization. An example using gcc > would be easiest for me to deal with. I'm skeptical that compiler > implementers are *deliberately* unhelpful, but I'm willing to be > convinced. There were some gcc examples some time ago, but I don't remember them well enough to comment on them. Maybe not deliberately, but close enough to confuse programmers. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2014-12-21 15:02 -0600 |
| Message-ID | <f0ce9adkg4val4bj6anbrqm3972gg0t2g0@4ax.com> |
| In reply to | #55161 |
On Sat, 20 Dec 2014 11:37:43 -0800, Keith Thompson <kst-u@mib.org>
wrote:
>Richard Damon <Richard@Damon-Family.org> writes:
>[...]
>> I would also contend that the implementer is being genuinely and
>> deliberately unhelpful here. At the point where the compiler has
>> determined that it can omit a section of code, it also knows that the
>> programmer has done something questionable, and appears to be depending
>> on undefined behavior, so it should at least, by default, issue a
>> warning here (and perhaps then do the optimization).
>
>It would be easier to discuss that point if you could provide a concrete
>example of a compiler failing to issue a helpful warning when it
>performs a potentially disruptive optimization. An example using gcc
>would be easiest for me to deal with. I'm skeptical that compiler
>implementers are *deliberately* unhelpful, but I'm willing to be
>convinced.
The Linux kernel NULL pointer thing is an interesting example.
Basically something like the following was in the kernel:
x somefunction(sometype *p)
{
...
t = p->a;
...
if (p)
someotherfunction(p);
...
}
GCC optimized the test out, and someotherfunction() ended up called
with a NULL pointer. The justification was that the assignment would
fault if p was NULL, rendering the test superfluous. Which was not
actually true in the Linux kernel, where page zero is actually mapped.
It's unclear to me exactly what the test for a NULL pointer the
compiler was using here. Consider if sometype contained "char b[n];".
Would this have assumed the fault if the assignment were "t =
a->b[4200000];"? On many Linux system that would be a reference into
the text of your program, and eminently readable (on Windows you could
substitute 132000).
The resolution was something of a standoff - the kernel guys fixed
their code to work around that optimization, the GCC guys added a
compiler option to suppress the assumption that a NULL pointer
dereference causes a trap.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-12-21 22:02 +0000 |
| Message-ID | <20141221135927.223@kylheku.com> |
| In reply to | #55233 |
On 2014-12-21, Robert Wessel <robertwessel2@yahoo.com> wrote:
> On Sat, 20 Dec 2014 11:37:43 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
>
>>Richard Damon <Richard@Damon-Family.org> writes:
>>[...]
>>> I would also contend that the implementer is being genuinely and
>>> deliberately unhelpful here. At the point where the compiler has
>>> determined that it can omit a section of code, it also knows that the
>>> programmer has done something questionable, and appears to be depending
>>> on undefined behavior, so it should at least, by default, issue a
>>> warning here (and perhaps then do the optimization).
>>
>>It would be easier to discuss that point if you could provide a concrete
>>example of a compiler failing to issue a helpful warning when it
>>performs a potentially disruptive optimization. An example using gcc
>>would be easiest for me to deal with. I'm skeptical that compiler
>>implementers are *deliberately* unhelpful, but I'm willing to be
>>convinced.
>
>
> The Linux kernel NULL pointer thing is an interesting example.
> Basically something like the following was in the kernel:
>
> x somefunction(sometype *p)
> {
> ...
> t = p->a;
> ...
> if (p)
> someotherfunction(p);
> ...
> }
>
> GCC optimized the test out, and someotherfunction() ended up called
> with a NULL pointer. The justification was that the assignment would
> fault if p was NULL, rendering the test superfluous. Which was not
> actually true in the Linux kernel, where page zero is actually mapped.
Where? Maybe on some no-MMU-architecture ports of Linux?
Page zero is not mapped in the Linux kernel, and null pointer dereferences
give rise to an "oops", where they are clearly identified as such.
Why that assignment might not fault is that p->a is offset far enough
from zero that it's beyond the unmapped page.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-12-21 23:49 -0600 |
| Message-ID | <m78bdf$197$1@dont-email.me> |
| In reply to | #55237 |
On 21-Dec-14 16:02, Kaz Kylheku wrote:
> On 2014-12-21, Robert Wessel <robertwessel2@yahoo.com> wrote:
>> The Linux kernel NULL pointer thing is an interesting example.
>> Basically something like the following was in the kernel:
>>
>> x somefunction(sometype *p)
>> {
>> ...
>> t = p->a;
>> ...
>> if (p)
>> someotherfunction(p);
>> ...
>> }
>>
>> GCC optimized the test out, and someotherfunction() ended up
>> called with a NULL pointer. The justification was that the
>> assignment would fault if p was NULL, rendering the test
>> superfluous. Which was not actually true in the Linux kernel,
>> where page zero is actually mapped.
>
> Where? Maybe on some no-MMU-architecture ports of Linux?
>
> Page zero is not mapped in the Linux kernel, and null pointer
> dereferences give rise to an "oops", where they are clearly
> identified as such.
There's no special code for page zero.
Remember that kernel code executes in the caller's context*; rather than
reset the page tables on entry and again on exit, the kernel gets mapped
into each process's address space, typically in the top (or negative)
half, but marked unreadable. When kernel code is executing, that
security check is bypassed, otherwise the kernel wouldn't be able to
read its own data--or even its own code!
This security check is what generates a "segmentation violation" when
user code dereferences a null pointer. However, when kernel code does
the same, that security check is bypassed, so it happily reads the data
at that address and continues on--but the GCC folks didn't take that
into account when they added the above optimization.
Not that GCC was technically wrong since this is clearly UB, but GCC's
release process requires compiling a working Linux kernel (among other
things), which puts them on the hook for making all Linux's uses of UB
work _as Linux expects them to_.
(* Aside from oddballs like RedHat's 4GB+4GB kernel, typically used for
large database servers before x86-64 came out, which actually _did_ have
to reset the page tables on every entry and every exit.)
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2014-12-21 17:45 +0000 |
| Message-ID | <549705cd.693437@news.xs4all.nl> |
| In reply to | #55154 |
Richard Damon <Richard@Damon-Family.org> wrote: > On 12/18/14, 7:04 AM, Richard Bos wrote: > > Robert Wessel <robertwessel2@yahoo.com> wrote: > > > >> In fact there's a lively discussion going on about compilers doing > >> just that. Mike Stump (who's a GCC developer) has been arguing here > >> in c.l.c that compiler *are* allowed to make assumptions based on what > >> is technically undefined behavior when optimizing code. A number of > >> other folks are unhappy with that. > > > > They may be unhappy with that, but I can't see what arguments they can > > bring against it. Undefined behaviour is _undefined_, so if an optimiser > > wants to make use of it, it's free to do so. > > The C standard NEVER says something like "if you do X then the results > are totally undefined", it only says that "if you do X then the results > are undefined by this standard". The standard can't grant permission to > act against the defined behavior of another standard that has been > accepted by the compiler. And as I wrote elsewhere in this thread, if that other standard either defines certain things to happen a specific way, or defines certain things _not_ to happen in any specific way, a compiler targeting _that_ system is free to do things that way, and a compiler targeting another system is just as free to do them that system's way - and they'll both be optimised for _their_ systems. > I don't have a problem with the compiler having a mode where it ignores > these definition and optimizes based on ignoring them, and fully using > just C's definition of undefined behavior (like fast floating point > optimizations can ignore some of the IEEE floating point requirements). That misses the point. It's more likely that a compiler will fully use _that system's_ facilities for optimisation, rather than ignoring them and creating an inferiorly optimised program. Keeping UB and allowing this allows for superior optimisation on unusual, historical, and more importantly, future and as yet unforseen platforms. Insisting that a compiler is not allowed to do this implies locking the C language firmly into MicroGNU, which is a Bad Thing. > I would also contend that the implementer is being genuinely and > deliberately unhelpful here. At the point where the compiler has > determined that it can omit a section of code, it also knows that the > programmer has done something questionable, and appears to be depending > on undefined behavior, so it should at least, by default, issue a > warning here (and perhaps then do the optimization). That depends on warning levels, which are compiler-specific and not specified by the Standard. The programmer may _want_ to have his code optimised (ab-)using different hacks on different systems, because that's what the different users on those systems expect. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2014-12-18 10:29 -0800 |
| Message-ID | <kfnzjak6cck.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #54910 |
Robert Wessel <robertwessel2@yahoo.com> writes: > In fact there's a lively discussion going on about compilers doing > just that. Sorry, maybe I missed something - where is this discussion going on? > Mike Stump (who's a GCC developer) has been arguing here in c.l.c > that compiler *are* allowed to make assumptions based on what is > technically undefined behavior when optimizing code. In comp.lang.c? I don't remember seeing any such postings. Do you have some reference you can give?
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2014-12-20 05:29 -0600 |
| Message-ID | <4ola9a1ic6sohnb7po4inibfu3g3fqtn3a@4ax.com> |
| In reply to | #54984 |
On Thu, 18 Dec 2014 10:29:15 -0800, Tim Rentsch <txr@alumni.caltech.edu> wrote: >Robert Wessel <robertwessel2@yahoo.com> writes: > >> In fact there's a lively discussion going on about compilers doing >> just that. > >Sorry, maybe I missed something - where is this discussion going >on? > >> Mike Stump (who's a GCC developer) has been arguing here in c.l.c >> that compiler *are* allowed to make assumptions based on what is >> technically undefined behavior when optimizing code. > >In comp.lang.c? I don't remember seeing any such postings. Do >you have some reference you can give? It comes and goes, and there's been a lot of it recently (and not just here). There were a couple of rather lively threads recently, either here or on comp.lang.c++. Unfortunately they've dropped off the end of what my news reader retains, and searching through the Google archive is just too painful. The gist was one side arguing that GCC's recent increases in taking "anything may happen for undefined behavior" too literally was breaking large numbers of programs, the response was "those programs are broken anyway (and who cares if they were producing correct results before)". Both sides are partially right, but the (quite glib) dismissal of the developer's issues by the compiler side was more than a bit distressing (which was basically "write better code without undefined behavior, even it took ten people a week to figure out that the behavior was actually undefined, you shouldn't have done that, and we don't owe you any warnings either"). On the flip side, a program containing undefined behavior *is* incorrect, but the breadth of those areas in C is pretty large, and clearly larger than many of us thought until the recent innovations in optimization. I fear that if the present trend continues we may see a significant reduction in the usefulness of C and C++. What happens if (practically) avoiding undefined behavior becomes so complex that almost no one can actually do it? An alternative may be to significantly tighten up many of the undefined areas, although there are some darn big holes.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2014-12-20 11:32 -0800 |
| Message-ID | <kfnoaqy3ymx.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #55135 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Thu, 18 Dec 2014 10:29:15 -0800, Tim Rentsch > <txr@alumni.caltech.edu> wrote: > >>Robert Wessel <robertwessel2@yahoo.com> writes: >> >>> In fact there's a lively discussion going on about compilers doing >>> just that. >> >> Sorry, maybe I missed something - where is this discussion going >> on? >> >>> Mike Stump (who's a GCC developer) has been arguing here in c.l.c >>> that compiler *are* allowed to make assumptions based on what is >>> technically undefined behavior when optimizing code. >> >> In comp.lang.c? I don't remember seeing any such postings. Do >> you have some reference you can give? > > It comes and goes, and there's been a lot of it recently (and not > just here). There were a couple of rather lively threads > recently, either here or on comp.lang.c++. I see. Probably that other group then, which I look at less regularly than comp.lang.c. > The gist was one side arguing that GCC's recent increases in > taking "anything may happen for undefined behavior" too literally > was breaking large numbers of programs, the response was "those > programs are broken anyway (and who cares if they were producing > correct results before)". [snip elaboration] Yes, I understand the issue, and it is an important one. I was just wondering about where I could find the originating discussion.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2014-12-21 15:23 -0600 |
| Message-ID | <uide9alajrfjhg544nfptmumjc812j09nc@4ax.com> |
| In reply to | #55160 |
On Sat, 20 Dec 2014 11:32:54 -0800, Tim Rentsch <txr@alumni.caltech.edu> wrote: >Robert Wessel <robertwessel2@yahoo.com> writes: > >> On Thu, 18 Dec 2014 10:29:15 -0800, Tim Rentsch >> <txr@alumni.caltech.edu> wrote: >> >>>Robert Wessel <robertwessel2@yahoo.com> writes: >>> >>>> In fact there's a lively discussion going on about compilers doing >>>> just that. >>> >>> Sorry, maybe I missed something - where is this discussion going >>> on? >>> >>>> Mike Stump (who's a GCC developer) has been arguing here in c.l.c >>>> that compiler *are* allowed to make assumptions based on what is >>>> technically undefined behavior when optimizing code. >>> >>> In comp.lang.c? I don't remember seeing any such postings. Do >>> you have some reference you can give? >> >> It comes and goes, and there's been a lot of it recently (and not >> just here). There were a couple of rather lively threads >> recently, either here or on comp.lang.c++. > >I see. Probably that other group then, which I look at >less regularly than comp.lang.c. > > >> The gist was one side arguing that GCC's recent increases in >> taking "anything may happen for undefined behavior" too literally >> was breaking large numbers of programs, the response was "those >> programs are broken anyway (and who cares if they were producing >> correct results before)". [snip elaboration] > >Yes, I understand the issue, and it is an important >one. I was just wondering about where I could find >the originating discussion. The thread I was thinking of was actually in comp.arch, titled "If it were easy", and ran August through November. As usual, this topic is the result of thread drift. And with 850+ posts, I hope you have some free time. Semi-worthless Google Groups link: https://groups.google.com/forum/?hl=en#!topic/comp.arch/7Gn_kD4MoPg%5B1-25-false%5D
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2014-12-22 23:39 -0800 |
| Message-ID | <kfn7fxivmpv.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #55236 |
Robert Wessel <robertwessel2@yahoo.com> writes: > The thread I was thinking of was actually in comp.arch, titled "If > it were easy", and ran August through November. As usual, this > topic is the result of thread drift. And with 850+ posts, I hope > you have some free time. That's the information I was looking for (and thank you for the warning).
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-12-20 20:22 +0000 |
| Message-ID | <m74lql$v4i$1@speranza.aioe.org> |
| In reply to | #55135 |
Robert Wessel <robertwessel2@yahoo.com> wrote: > On Thu, 18 Dec 2014 10:29:15 -0800, Tim Rentsch (snip) >>In comp.lang.c? I don't remember seeing any such postings. Do >>you have some reference you can give? > It comes and goes, and there's been a lot of it recently (and not just > here). There were a couple of rather lively threads recently, either > here or on comp.lang.c++. Unfortunately they've dropped off the end > of what my news reader retains, and searching through the Google > archive is just too painful. > The gist was one side arguing that GCC's recent increases in taking > "anything may happen for undefined behavior" too literally was > breaking large numbers of programs, the response was "those programs > are broken anyway (and who cares if they were producing correct > results before)". Programmers make some assumptions on what UB might produce. For example, as I don't have any real examples, shifting by greater than or equal to the data width is undefined. It might seem obvious to the programmer that means that the result of the shift is undefined, and that if the result is independent of the shift result, that one doesn't need to worry about the UB. Programmers are probably more careful with array bounds, but even there, a fair amount of hardware isn't bothered by fetch from out of bounds. (Real mode x86, for example.) And even in the case of hardware that is, one expects either the wrong (there is no right) value, or a trap/interrupt. In the latter case, one knows to fix it, in the former one can often ignore it. But now compilers cause a variety of more surprising events. > Both sides are partially right, but the (quite glib) dismissal of the > developer's issues by the compiler side was more than a bit > distressing (which was basically "write better code without undefined > behavior, even it took ten people a week to figure out that the > behavior was actually undefined, you shouldn't have done that, and we > don't owe you any warnings either"). For very small programs, one can hope to have an understanding of the program as a whole. For larger programs, one tries to understand the parts, and assume that they will work together in the appropriate way. > On the flip side, a program containing undefined behavior *is* > incorrect, but the breadth of those areas in C is pretty large, and > clearly larger than many of us thought until the recent innovations in > optimization. > I fear that if the present trend continues we may see a significant > reduction in the usefulness of C and C++. What happens if > (practically) avoiding undefined behavior becomes so complex that > almost no one can actually do it? An alternative may be to > significantly tighten up many of the undefined areas, although there > are some darn big holes. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2014-12-18 10:24 -0800 |
| Message-ID | <kfn4mss7r45.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #54852 |
Richard Heathfield <invalid@see.sig.invalid> writes: > Tim Rentsch wrote: > >> JohnF <john@please.see.sig.for.email.com> writes: >> >>> Tim Rentsch <txr@alumni.caltech.edu> wrote: >>>> Richard Heathfield <invalid@see.sig.invalid> writes: >>>>> <<snip>> >>>>> A language in which every possible construct is either >>>>> well-defined or illegal makes it very difficult for programmers >>>>> to add kinds of functionality unanticipated by the language >>>>> designers. >>>> >>>> I have a suspicion that we are getting close to a philosophical >>>> question <<snip>> >>> >>> I'd just say RH's remark is plain wrong. [snip elaboration] >> >> To be fair, I wouldn't say either that his comment is right or >> wrong, because I don't know how to assign a meaning to it that >> agrees with his. It's like he is saying "A language in which >> every possible construct is either forta-magnus or cetcil makes >> it very difficult for programmers to add kinds of melnics >> unanticipated by the language designers." I don't know what he >> means by the words he is using (as he is using them), so it's not >> possible to evaluate whether the underlying proposition is true >> or false, or indeed if it is even sensible to ask whether it is >> true or false. >> >> On the other hand, he refuses to be pinned down about what he >> does mean, so further discussion seems rather pointless. > > I've tried as best I can to explain what I mean, but English lacks > the precision of C. > > Let me try again. Who knows? It might even help. > > Definitions of terms: [which I reformatted slightly] > > illegal: code that violates a constraint or a syntax rule; > > legal: not illegal; > > undefined behaviour: see the C definition; > > unspecified behaviour: see the C definition; > > implementation-defined behaviour: see the C definition; > > locale-specific behaviour: see the C definition; > > well-defined behaviour: behaviour (of legal code) that is not > undefined, unspecified, implementation-defined, or > locale-specific; > > bad undefined behaviour: undefined behaviour that arises through > ignorance or wilfulness; > > good undefined behaviour: undefined behaviour that allows a > programmer to solve a problem that could not be solved > effectively without it. > > It is my contention that 'good undefined behaviour' can exist, and > that a programming language that prevents this is a hindrance to > the solving of some real-world problems. I gave an example > upthread (poking values into specific memory locations). > > That's the whole thing. > > Does it help at all? Just a couple short comments. One, the "good" and "bad" categories of undefined behavior are not mutually exclusive. Also, the "willfulness" part of "bad" undefined behavior means any "good" undefined behavior will also be "bad" undefined behavior, unless the developer exploiting the undefined behavior did so unintentionally. I expect this is not what you want. Probably more significantly, I don't see any useful way to distinguish between "good" undefined behavior and "bad" undefined behavior, since which applies depends on what the developer in question is (or is not) thinking. (I have some other questions or comments about what counts as undefined behavior, but I will leave those for later.) Two, I think you've punted on the big issue, which is how much (or what kinds of) capability is (are) needed to satisfy the predicate criterion. For example, suppose the phrase "solving a real-world problem" includes "doing anything the underlying computer system can do, including things that make this running program behave not according the language specification." That brings the question into the realm of the Barber Paradox, or the "can $DEITY make a rock so heavy he cannot lift it?" conundrum. Or, possibly, makes the hypothetical vacuously true. So for the question to be meaningful, there needs to be a definition of what level of capabilities must be achievable, and free of any kind of circularity, internal inconsistency, or infinite regress.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-18 18:36 +0000 |
| Message-ID | <l9Fkw.185713$ot.91664@fx13.am4> |
| In reply to | #54983 |
Tim Rentsch wrote: <snip> > > Just a couple short comments. > > One, the "good" and "bad" categories of undefined behavior are > not mutually exclusive. I agree entirely. > Also, the "willfulness" part of "bad" > undefined behavior means any "good" undefined behavior will > also be "bad" undefined behavior, unless the developer exploiting > the undefined behavior did so unintentionally. If you accept s/unless/if/ then I'd agree. (By 'wilfulness', I don't mean merely 'invoking UB intentionally', but 'invoking UB intentionally, despite knowing that a perfectly adequate non-undefined construct exists which meets all the requirements'. That is, bloodymindedness.) > I expect this is > not what you want. Probably more significantly, I don't see any > useful way to distinguish between "good" undefined behavior and > "bad" undefined behavior, And that's the problem. The same safeguards that stop people from doing stupid things can all too often stop them from doing clever things as well. <snip> > Two, I think you've punted on the big issue, which is how much > (or what kinds of) capability is (are) needed to satisfy the > predicate criterion. I'm sorry you think that. I'm not sure that I agree, and (alas) I lack the time right now to do any more than acknowledge your response. If I can get back to it before the whole debate goes stale, I will, but I may not be able to. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2014-12-19 09:24 -0800 |
| Message-ID | <kfna92j5z90.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #54986 |
Richard Heathfield <invalid@see.sig.invalid> writes: > Tim Rentsch wrote: > [snip] > >> Two, I think you've punted on the big issue, which is how much >> (or what kinds of) capability is (are) needed to satisfy the >> predicate criterion. > > I'm sorry you think that. I'm not sure that I agree, and (alas) I > lack the time right now to do any more than acknowledge your > response. If I can get back to it before the whole debate goes > stale, I will, but I may not be able to. I await your further comments with great anticipation.
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web