In article <3tud69$cg7@onramp.arc.nasa.gov>,
Hugh LaMaster <lamaster@george.arc.nasa.gov> wrote:
>A few weeks ago, Ron Guilmette posted an "amusing" example
>of a bug in a common compiler, wondering what the reaction
>would be.  He anticipated, of course, that the reaction
>would be restrained, rather than outrage.  Of course, he
>was right.  After all, it was "only" a compiler bug, and
>one which was "only" a problem involving the scope of variables.

The compiler bug is indeed serious IMHO.  There were enough problems
with 2.6 compilers that I have _never_ used them for any production
work.  I had lot's of problems with the 2.6 series every time I used it.

>Which all tends to confirm my pre-existing prejudice:
>Many people don't know whether or not their answers
>are actually correct, and, often enough, don't care
>either, as long as any problem is "merely" a software
>bug.

I disagree.  Most of the hacker type people I talk to told me to use
gcc-2.5.8 rather than _any_ gcc 2.6.X compiler.  I was informed that
2.6.X introduced problems and bugs into lots of code that required
careful coding to fix, i.e.  the problems were noted immediately and
well publicized but there were problems finding them in the compiler.
In the case of 486 type code there was no real performance hit using the
older compiler so there was no UNSOLVABLE problem, simply use the
compiler.

A bad chip is a TAD different.  Case 1 is that you paid money for it,
case 2 being not too many non-techno-wizard type people like to rip open
their computers and rip out $500 cpu chips and replace them.

In both cases we have _determined_ an incorrect answer.  It's just the
software answer is easier to correct.

>Back when the Intel Pentium bug furor hit, I posed the
>question in several of these same groups regarding how
>people knew they were getting correct answers.  The
>reactions were not comforting then, as, indeed, the
>reactions to this bug are not comforting, either.
>Once again, I am impressed by how easily people brush
>off the question of how they know the output from
>their programs is correct.

This is really the crux of the issue.  Often times you don't.  Whenever
I write a financial report for example I always strain the data thru
cross-checks in the code, and generally run an abort if the cross-checks
don't jive.  Very useful to maintain data integrity and catch stupid
logic errors.  The difference is that with a _compiler_ bug some
relatively simple code additions can help you find and _ELIMINATE_ an
incorrect result rather quickly, by re-coding or using a different
compiler.  If the bug is in the hardware the task of eliminating the
problem is expotentially more severe.

I know of several arithmetic "bugs" in the Unibol RPG compiler for
example that were detected with cross-checks.  At that point you can be
assured that at least _one_ of your answers is wrong, and proceed from
there to identify the problem and code around it.  I consider the 'bug'
to be serious, but easy to work around.

I always compile my code with lots of different compilers when it comes
to 'C' because I have so many to choose from, since SCO comes with rcc
(AT&T) cc (MS) and I use gcc also.

Hell you can _never_ be 100% certian of a result in extremely complex
operations.  The best you can do is regressive tests, and cross checks.
I surely wouldn't trust doing a 100x100 matrix division with real numbers
by _hand_ to check my machines results :)!

>
>"Garbage In, Gospel Out."
>--
>  Hugh LaMaster, M/S 233-18,    Email:       Please send ASCII documents to:
>  NASA Ames Research Center     Internet:    lamaster@ames.arc.nasa.gov

Of course then again, If we were all boosting spaceships into orbit rather
than showing a businessman his bottom line, I'm sure the accuracy of the
output could get a little more important.  Heck, If I'm off 10 grand on
the P&L it may only cost someone their job, not their life.  Gaining a proper
perspective of the problem is also very important.
--
Keith Smith <keith@ksmith.com>                  Free Usenet News/Newsfeeds
Digital Designs                                   (910) 423-4216/7389/7391
PO Box 85                                                   V.34/V.34/V.32
Hope Mills, NC 28348-0085  ... Somewhere in the Styx of North Carolina ...

A few weeks ago, Ron Guilmette posted an "amusing" example
of a bug in a common compiler, wondering what the reaction
would be.  He anticipated, of course, that the reaction
would be restrained, rather than outrage.  Of course, he
was right.  After all, it was "only" a compiler bug, and
one which was "only" a problem involving the scope of variables.

Which all tends to confirm my pre-existing prejudice:
Many people don't know whether or not their answers
are actually correct, and, often enough, don't care
either, as long as any problem is "merely" a software
bug.

Back when the Intel Pentium bug furor hit, I posed the
question in several of these same groups regarding how
people knew they were getting correct answers.  The
reactions were not comforting then, as, indeed, the
reactions to this bug are not comforting, either.
Once again, I am impressed by how easily people brush
off the question of how they know the output from
their programs is correct.

"Garbage In, Gospel Out."


--
  Hugh LaMaster, M/S 233-18,    Email:       Please send ASCII documents to:
  NASA Ames Research Center     Internet:    lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035-1000  Or:          lamaster@george.arc.nasa.gov
  Phone:  415/604-1056          Disclaimer:  Unofficial, personal *opinion*.

lamaster@george.arc.nasa.gov (Hugh LaMaster) writes:

> A few weeks ago, Ron Guilmette posted an "amusing" example
> of a bug in a common compiler, wondering what the reaction
> would be.  He anticipated, of course, that the reaction
> would be restrained, rather than outrage.  Of course, he
> was right.  After all, it was "only" a compiler bug, and
> one which was "only" a problem involving the scope of variables.

Perhaps a ray of hope...

I immediately checked my compiler against this code.
It failed.  I fixed it.  _I added the code to my test suite_.
(all you other compiler writers did too, right?  %^)

>  "Garbage In, Gospel Out."

Since this posting came out of a computer, does that mean...
:-)

Cliff

--
Cliff Click                  Compiler Research Scientist
Cambridge Research Office,   Hewlett-Packard Laboratories
One Main Street, 10th Floor, Cambridge, MA 02142
(617) 225-4915  Work         (617) 225-4930  Fax
cliffc@hpl.hp.com            http://bellona.cs.rice.edu/MSCP/cliff.html

In article <3su65u$mnn@sunsystem5.informatik.tu-muenchen.de>, paysan@informatik.tu-muenchen.de (Bernd Paysan) writes:
> And as this seems to be an ambiguous condition in the C standard, berhaps
> the GNU C developer decided to change the behavior on every minor release.
> 2.7.0 gives 0.9 again. What will 2.8.x give :-)?
>
> I've heard that before #pragma was standardized for C++ the cccp did funny
> things each time it encountered a #pragma (it is implementation defined in
> C, and cccp started a game or so - perfectly legal, but relly strange).
>

That was a long time ago, the code is still there, but is now commented out:


#if 0
/* This was a fun hack, but #pragma seems to start to be useful.
   By failing to recognize it, we pass it through unchanged to cc1.  */

/*
 * the behavior of the #pragma directive is implementation defined.
 * this implementation defines it as follows.
 */

static int
do_pragma ()
{
  close (0);
  if (open ("/dev/tty", O_RDONLY, 0666) != 0)
    goto nope;
  close (1);
  if (open ("/dev/tty", O_WRONLY, 0666) != 1)
    goto nope;
  execl ("/usr/games/hack", "#pragma", 0);
  execl ("/usr/games/rogue", "#pragma", 0);
  execl ("/usr/new/emacs", "-f", "hanoi", "9", "-kill", 0);
  execl ("/usr/local/emacs", "-f", "hanoi", "9", "-kill", 0);
nope:
  fatal ("You are in a maze of twisty compiler features, all different");
}
#endif

In <DArJHI.1Dz@byron.net4.io.org> acli@byron.net4.io.org (Ambrose Li) writes:

>In article <xz93fh2oa75.fsf@euler>, Dirk Kussin <dirk@euler> wrote:
>>gcc 2.6.2 Linux 1.2.10: 0.800000
>     ^^^^^
>Strange. My gcc (2.5.8) on Linux 1.2.0 gives me a 0.9.
                  ^^^^^
What's so strange?  2.6.2 != 2.5.8

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@mail.cern.ch
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

In article <danpop.804335483@rscernix>, Dan.Pop@mail.cern.ch (Dan Pop) writes:
>
>In <DArJHI.1Dz@byron.net4.io.org> acli@byron.net4.io.org (Ambrose Li) writes:
>
>>In article <xz93fh2oa75.fsf@euler>, Dirk Kussin <dirk@euler> wrote:
>>>gcc 2.6.2 Linux 1.2.10: 0.800000
>>     ^^^^^
>>Strange. My gcc (2.5.8) on Linux 1.2.0 gives me a 0.9.
>                  ^^^^^
>What's so strange?  2.6.2 != 2.5.8

And as this seems to be an ambiguous condition in the C standard, berhaps
the GNU C developer decided to change the behavior on every minor release.
2.7.0 gives 0.9 again. What will 2.8.x give :-)?

I've heard that before #pragma was standardized for C++ the cccp did funny
things each time it encountered a #pragma (it is implementation defined in
C, and cccp started a game or so - perfectly legal, but relly strange).

--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/

In article <3su65u$mnn@sunsystem5.informatik.tu-muenchen.de>,
paysan@informatik.tu-muenchen.de (Bernd Paysan) writes:
<snip>
|> And as this seems to be an ambiguous condition in the C standard, berhaps

What ambiguity are you talking about? This thread did not concern itself with
ambiguities in the C standard: merely with a compiler bug.

Cheers
Tanmoy
--
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87544-0285,USA H:#3,802,9 St,NM87545
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]

My test:

gcc 2.6.3 SunOS 4.1.3:  0.800000
gcc 2.6.3 SunOS 5.4:    0.800000
gcc 2.6.2 Linux 1.2.10: 0.800000

--
Dirk Kussin                            dirk@uni-paderborn.de
Fachbereich 17 Mathematik-Informatik   Raum D2.201
Universit   t-GH Paderborn               Tel. (+49) (5251) 60-3067
D-33095 Paderborn ----------------------------------------------

Mark (mal@infinet.com) wrote:
: : : double d = 0.9;
: : : int
: : : main ()
: : : {
: : :     double d = 0.8;
: : :     {
: : :         extern double d;
: : :         printf ("%f\n", d);
: : :         return 0;
: : :     }
: : : }
: : : This program *should* print 0.900000, and with most compilers, it does.
: : : But when compiled with one particular popular free C compiler, this
: : : program will print 0.800000.

Let me see if I have this straight.  You're not reporting a problem
with computation, but a problem with scoping variables with
identical names.  Right?

Leonard N. Zubkoff (lnz@dandelion.com) wrote:
: In article <3s2las$1br@hustle.rahul.net> "Ronald F. Guilmette" <rfg@rahul.net> writes:

:   [program deleted]

:   This program *should* print 0.900000, and with most compilers, it does.
:   But when compiled with one particular popular free C compiler, this
:   program will print 0.800000.  Obviously this divergence is orders of
:   magnitude more serious than the inaccuracy with the Pentium ever was.
:   I thus anticipate the outcry over this problem to be orders of magnitude
:   more shrill than was the outcry over the Pentium flaw (and I will of
:   course be deeply disappointed if such an outrcy doesn't materalize :-).

   I think the point here is that Intel make huge amounts of money from
   selling Pentiums, as you say this compiler is entirely free.
   You pays you money and get what you pay for.

   or in the case of intel NOT!


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dave Holden Phys. Dept. | Email: phd85@potter.cc.keele.ac.uk
keele university.       |        PGP key on request.
keele. staffs. England. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In article <3s46bi$3qe@devel.dvstsol.demon.co.uk>, nick@dvstsol.demon.co.uk (Nick Gorham) writes:
[slice]
|> Perhaps I am missing the point, but whats the above bit of silly code
|> to do with floating point errors. The simple way to fix this "compilor bug"
|> is not to write code like this ;-). Perhaps someone will tell otherwise.

Ah!  The dreaded "Don't *DO* that!" answer.

Jonathan (And why not?) Allan
--
*  Nobody except me has any stake in this opinion, and *
*  if I'm playing Devils Advocate, even *I* don't.     *
*  Email to kpa@mill2.millcomm.com won't bounce.       *
* It won't be answered either until I get my hardware fixed. *

Nick Gorham (nick@dvstsol.demon.co.uk) wrote:
: : -------------------------------------------------------------------------
: : double d = 0.9;
: :
: : int
: : main ()
: : {
: :     double d = 0.8;
: :     {
: :         extern double d;
: :
: :         printf ("%f\n", d);
: :         return 0;
: :     }
: : }
: : -------------------------------------------------------------------------

: Perhaps I am missing the point, but whats the above bit of silly code
: to do with floating point errors. The simple way to fix this "compilor bug"
: is not to write code like this ;-). Perhaps someone will tell otherwise.

I tend to agree with Nick on this one, it's a pathological
case no one would ever encounter (without getting fired! :))

Is the code above even legal ANSI C? "extern" refers to something
outside of the current scope, and both d's are outside the inner
block's scope, so wouldn't this be an implementation defined area?
Where's a language lawyer that knows the standard well enough to
comment on this? Isn't this another a[i++] = ++i + i++ + ++i++; type
issue?

Scott

In article <3sbm5j$vuq@locutus.rchland.ibm.com> xzz0529@honker.rchland.ibm.com (Jonathan Allan) writes:

   In article <3s46bi$3qe@devel.dvstsol.demon.co.uk>, nick@dvstsol.demon.co.uk (Nick Gorham) writes:
   [slice]
   |> Perhaps I am missing the point, but whats the above bit of silly code
   |> to do with floating point errors. The simple way to fix this "compilor bug"
   |> is not to write code like this ;-). Perhaps someone will tell otherwise.

   Ah!  The dreaded "Don't *DO* that!" answer.

Nick Gorham <nick@dvstsol.demon.co.uk> wrote:
> The simple way to fix this "compilor bug" is not to write code like
> this.

Jonathan Allan <xzz0529@honker.rchland.ibm.com> replied:
> Ah!  The dreaded "Don't *DO* that!" answer.

Exactly.  The C standard is bad enough, with "undefined" in so places,
without perfectly legal constructs being unusable too.  There's no point
in having a standard if a compiler writer can just say, "well, no
sensible programmer would ever do this, so I won't bother implementing
it".

--
Gareth Rees

In article <3scr34$smm@fg70.rz.uni-karlsruhe.de> ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:

[snip]
>>Jonathan Allan <xzz0529@honker.rchland.ibm.com> replied:
>>> Ah!  The dreaded "Don't *DO* that!" answer.

>>Exactly.  The C standard is bad enough, with "undefined" in so places,
>>without perfectly legal constructs being unusable too.

>It's legal, but it's far from good style; there is no use for this kind
>of games with scopes, unless you WANT to be unclear.

I fully agree!  I simply do not see the what all the fuss is about.  Yes it is
a bug, but IMO a very minor bug because this is extremely poor style, and
unless you are into writing poorly styled code, you should never see this.

>Could you have told with certainty, and without looking at the C
>standard, what this particular piece of code (even with the forgotten
><stdio.h>) was supposed to have done?  If so, I congratulate you on
>your kills in arcane corners of the C standard.

Especially as a person coming into maintain this code. This code *could* make
it impossible to determine which variable 'd' the original developer
*intended* on using in the printf, *regardless* of whether this is
standardized or not.

To 'borrow' the phrase from Nike, I would say 'Just *don't* do it'.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
R. Abdella

abdella@egertp.ericsson.se
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The opinions expressed here do not belong to any person, organization,
entity, or element - other than myself... (of course)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In article <GDR11.95Jun22230445@stint.cl.cam.ac.uk>,
Gareth Rees <gdr11@cl.cam.ac.uk> wrote:
>Exactly.  The C standard is bad enough, with "undefined" in so places,
>without perfectly legal constructs being unusable too.  There's no point
>in having a standard if a compiler writer can just say, "well, no
>sensible programmer would ever do this, so I won't bother implementing
>it".

Interestingly, I had a visit from Bill McKeeman lately.  He probably doesn't
read this newsgroup at all.  He's a compiler writer from way back, first
from the academic world, now works for DEC in a research capacity.  And he's
working on heavy-duty compiler testers.  One of the things he mentioned
in the course of our conversation was a C compiler where   if (1.2)   behaves
as if the thing in parentheses were zero, because the writers never
thought anybody would use a non-integer in that context.

In comp.arch, gdr11@cl.cam.ac.uk (Gareth Rees) wrote:
>Nick Gorham <nick@dvstsol.demon.co.uk> wrote:
>> The simple way to fix this "compilor bug" is not to write code like
>> this.

>Jonathan Allan <xzz0529@honker.rchland.ibm.com> replied:
>> Ah!  The dreaded "Don't *DO* that!" answer.

>Exactly.  The C standard is bad enough, with "undefined" in so places,
>without perfectly legal constructs being unusable too.

It's legal, but it's far from good style; there is no use for this kind
of games with scopes, unless you WANT to be unclear.

Could you have told with certainty, and without looking at the C
standard, what this particular piece of code (even with the forgotten
<stdio.h>) was supposed to have done?  If so, I congratulate you on
your kills in arcane corners of the C standard.

>There's no point
>in having a standard if a compiler writer can just say, "well, no
>sensible programmer would ever do this, so I won't bother implementing
>it".

Well, yes, I agree that this bug should be fixed.

However, it's a sad fact of life that compilers have bugs.  These bugs are
discovered over time, and then fixed.  Why do you think nobody discovered
this particular bug before?  Because nobody in their right mind would write
code like that.

If you program in C, you have to program defensively to avoid the numerous
instances of undefined behaviour, or risk the consequences.
--
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.

In article <3sc4a8$46d@redstone.interpath.net>, softbase@mercury.interpath.net (Scott McMahan - Softbase Systems) writes:
[Ron Guilmette:]
>>>double d = 0.9;
>>>int main () {
>>>    double d = 0.8;
>>>    {
>>>        extern double d;
>>>        printf ("%f\n", d);
>>>        return 0;
>>>    }
>>>}

>Is the code above even legal ANSI C? "extern" refers to something
>outside of the current scope, and both d's are outside the inner
>block's scope, so wouldn't this be an implementation defined area?
>Where's a language lawyer that knows the standard well enough to comment
>on this? Isn't this another a[i++] = ++i + i++ + ++i++; type issue?

Unfortunately it is legal ISO (ANSI) C.  Now, I am inclined to agree with
part of your point, it *ought* to be another a[i++] = ++i + i++ + ++i++;
type issue.  However, the committee even did some work in Technical
Corrigendum 1 to reword part of the section on linkages of identifiers,
fixing some other programs that the standard unintentionally broke,
while making this program still come out with its same old meaning.
So I don't think they're likely to even consider making it illegal.
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer

In article <3sbnd5$g0@oclc.org>, Steve Driscoll <sdriscol@oclc.org> wrote:
>Mark (mal@infinet.com) wrote:
>: : : double d = 0.9;
>: : : int
>: : : main ()
>: : : {
>: : :     double d = 0.8;
>: : :     {
>: : :         extern double d;
>: : :         printf ("%f\n", d);
>: : :         return 0;
>: : :     }
>: : : }
>: : : This program *should* print 0.900000, and with most compilers, it does.
>: : : But when compiled with one particular popular free C compiler, this
>: : : program will print 0.800000.
>
>Let me see if I have this straight.  You're not reporting a problem
>with computation, but a problem with scoping variables with
>identical names.  Right?

True, but does that make a difference?

The generated results are wrong, regardless of the nature and/or cause
of the problem.

Would it make you feel any better to know that _your_ Space Shuttle flight
had crashed due to a ``scoping problem'' rather than due to a ``computation
problem''?

P.S.  Please note that the bug has now reported as being present in SEVERAL
different compilers.

P.P.S.  I made a mistake in predicting that the bug would still be present
the the next release of the particular compiler in which I first discovered
it.  I apologize for any undue angst I may have created thereby.
--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
---- finger: rfg@rahul.net ----------------- Suites and Bullet-Proof Shoes -

Ronald F. Guilmette (rfg@rahul.net) wrote:
: -------------------------------------------------------------------------
: double d = 0.9;
:
: int
: main ()
: {
:     double d = 0.8;
:     {
:         extern double d;
:
:         printf ("%f\n", d);
:         return 0;
:     }
: }
: -------------------------------------------------------------------------

Supose instead one had written:

double d = 0.9;

int
main ()
{
    double d = 0.8;
    {
        extern int d;

        return 0;
    }
}

In article <DAM6Mo.A3G@ukpsshp1.serigate.philips.nl>,
baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:
<snip>
|> Supose instead one had written:
|>
|> double d = 0.9;
|>
|> int
|> main ()
|> {
|>     double d = 0.8;
|>     {
|>         extern int d;
|>
|>         return 0;
|>     }
|> }
|>
|> From the discussions on this the inner and outer 'd's are the same thing,
so
|> this code is incorrect. My question is this an error for which the
compiler
|> is expected to produce a diagnostic - or is it like normal external
linkage
|> missmatches where the compiler is not expected to produce a diagnostic
(though
|> the linker might)?

The only _constraint_ (i.e. requirement of diagnostic) is that all
declarations in the same scope and in the same name space specify compatible
types. (i.e. this is the only one I could find: this is in 6.5). Any other
incompatible declaration of the same object leads to undefined behaviour, I
think (6.1.2.6). So, your program does not need a diagnostic, I believe, even
if double d = 0.8 is removed (but I would hate a compiler which did not warn
me of it under those conditions).

I may be wrong about this one.

Cheers
Tanmoy
--
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87544-0285,USA H:#3,802,9 St,NM87545
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]

Ron, there is a big difference in the two cases.

The compiler (gcc ?) is free whereas people were paying for
pentium. Secondly people were incensed with Intel
because it was trying to cover up the bug and told too
many lies about it.

- Kalyan

In article <3s7503$nmh@silver.jba.co.uk>,
Jonathan de Boyne Pollard <JdeBP%utopium@jba.co.uk> wrote:
:Ronald F. Guilmette (rfg@rahul.net) wrote:
:: -------------------------------------------------------------------------
:: double d = 0.9;
::
:: int
:: main ()
:: {
::     double d = 0.8;
::     {
::         extern double d;
::
::         printf ("%f\n", d);
::         return 0;
::     }
:: }
:: -------------------------------------------------------------------------
::
:: This program *should* print 0.900000, and with most compilers, it does.
:
:Actually, the program as given doesn't compile.  But inserting the implied
:inclusion of <stdio.h> fixes that.  (-:  So just for the record, some more
:interesting results.
:
:Borland C++ 2.0 for OS/2         : 0.900000
:IBM VisualAge C++ 3.00 for OS/2  : 0.900000
:MetaWare High C++ 3.31a for OS/2 : 0.900000
:Watcom C++ 10.0b on OS/2         : 0.800000
:EMX C++ 0.9a on OS/2             : 0.900000
:
:: But when compiled with one particular popular free C compiler, this
:: program will print 0.800000.
:
:Free ?  I think that the people at Watcom will beg to differ with you.  (-:

gcc 2.6.3 on IRIX 5.2 gets it wrong, unfortunately.  It's still my
favorite free compiler tho :)

--
---
Tim Hollebeek                   'There will be a better sig when I have time'

: : -------------------------------------------------------------------------
: : double d = 0.9;
: :
: : int
: : main ()
: : {
: :     double d = 0.8;
: :     {
: :         extern double d;
: :
: :         printf ("%f\n", d);
: :         return 0;
: :     }
: : }
: : -------------------------------------------------------------------------

: : This program *should* print 0.900000, and with most compilers, it does.
: : But when compiled with one particular popular free C compiler, this
: : program will print 0.800000.

Borland 4.0 C++ Compiler, on a 486dx40 system, got 0.900000 etc for results.

--
--------------------------------------------------------------------------
| Mark Lynch      | I'm sure about most of what I think I know about.    |
| mal@infinet.com | My Opinions are my own - Most of the time, sometimes |
--------------------------------------------------------------------------

As we all now know, early versions of the Pentium chip could, in rare cases,
produce floating point errors way down in the seventh or eighth digit after
some particular floating-point calculations.

Rightly or wrongly, people engaged in performing intensely numerical compu-
tations were horrified by this news, and promptly demanded refunds, which
led in turn to large numbers of people who were engaged in intensely
amusement-oriented computations to promptly demand refunds also.

At the time, I remarked that I believed that the incident had been somewhat
overblown, from the point of view of computations involved anyway.  (The
questions regarding Intel's relationship with, and responsibility to its
customers were another matter however.)

Anyway, I'm looking forward to the reaction of the numerical computing
community to the following short C program, and to the divergent results
obtained when compiling this program with different _compilers_.

-------------------------------------------------------------------------
double d = 0.9;

int
main ()
{
    double d = 0.8;
    {
        extern double d;

        printf ("%f\n", d);
        return 0;
    }
}
-------------------------------------------------------------------------

This program *should* print 0.900000, and with most compilers, it does.
But when compiled with one particular popular free C compiler, this
program will print 0.800000.  Obviously this divergence is orders of
magnitude more serious than the inaccuracy with the Pentium ever was.
I thus anticipate the outcry over this problem to be orders of magnitude
more shrill than was the outcry over the Pentium flaw (and I will of
course be deeply disappointed if such an outrcy doesn't materalize :-).

As we all know, the flawed Pentuim chips were on the market, and in end-
user's hands for several months prior to anyone even noticing the subtle
floating-point flaw.  For reference, the flaw in the compiler in question,
has been present since at least July of '94 (i.e. almost a full year)
and nobody seems to have noticed or complained (or asked for a refund :-).

(One final aside... Perhaps as interesting as the length of time this has
gone unnoticed is the fact that now that the compiler bug in question _is_
known, it isn't even considered important enough to fix for the next release.)

P.S.  I certainly don't mean to pick on free software here.  In fact I
love free software, and I use it all the time.  I've seen many a bug in
commercial compilers which were, in my opinion, every bit as serious as
this one.  Send mail if you want copes of some of the compiler bugs I've
found.

P.P.S.  If anyone out there still has a ``broken'' Pentium and wants to
sell it, I'll give you top dollar for it.  Seriously.  I could use a faster
machine right about now.
--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
---- finger: rfg@rahul.net ----------------- Suites and Bullet-Proof Shoes -

Ronald F. Guilmette (rfg@rahul.net) wrote:
: Anyway, I'm looking forward to the reaction of the numerical computing
: community to the following short C program, and to the divergent results
: obtained when compiling this program with different _compilers_.

: -------------------------------------------------------------------------
: double d = 0.9;
:
: int
: main ()
: {
:     double d = 0.8;
:     {
:         extern double d;
:
:         printf ("%f\n", d);
:         return 0;
:     }
: }
: -------------------------------------------------------------------------

: This program *should* print 0.900000, and with most compilers, it does.
: But when compiled with one particular popular free C compiler, this
: program will print 0.800000.

I got the following results:

vendor K&R C compiler            0.800000
vendor ISO C compiler            0.900000
a free ISO C compiler            0.800000

for extras, I added the required # include <stdio.h> and got the following
for C++

a free C++ compiler              0.900000
a commercial C++ compiler        0.900000

It looks like you found a bug in not only your ISO C compiler, but also
mine !

I'll leave the benefits of name overuse ...

: -- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
: ---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
: ---- finger: rfg@rahul.net ----------------- Suites and Bullet-Proof Shoes -

Nice one, Ron. Please keep trying.

Regards

David C Binderman MSc BSc       dbinder@bnr.co.uk         +44 1628 794 887
Object Oriented Design & Analysis with C++ since 1988
                      Code policeman, language lawyer and Purify advocate

Ronald F. Guilmette (rfg@rahul.net) wrote:
: As we all now know, early versions of the Pentium chip could, in rare cases,
: produce floating point errors way down in the seventh or eighth digit after
: some particular floating-point calculations.

[ stuff removed ]

: Rightly or wrongly, people engaged in performing intensely numerical compu-
: tations were horrified by this news, and promptly demanded refunds, which
: led in turn to large numbers of people who were engaged in intensely
: amusement-oriented computations to promptly demand refunds also.

: Anyway, I'm looking forward to the reaction of the numerical computing
: community to the following short C program, and to the divergent results
: obtained when compiling this program with different _compilers_.

: -------------------------------------------------------------------------
: double d = 0.9;
:
: int
: main ()
: {
:     double d = 0.8;
:     {
:         extern double d;
:
:         printf ("%f\n", d);
:         return 0;
:     }
: }
: -------------------------------------------------------------------------

Perhaps I am missing the point, but whats the above bit of silly code
to do with floating point errors. The simple way to fix this "compilor bug"
is not to write code like this ;-). Perhaps someone will tell otherwise.

Nick Gorham - nick@dvstsol.demon.co.uk

In comp.std.c, "Ronald F. Guilmette" <rfg@rahul.net> wrote:

[and crossposted to hell and back, too]

[...]

>Anyway, I'm looking forward to the reaction of the numerical computing
>community to the following short C program, and to the divergent results
>obtained when compiling this program with different _compilers_.

Your program violates the ANSI C standard by invoking undefined behaviour;
therefore, I suppose the reaction will be somewhat muted.

>double d = 0.9;
>
>int
>main ()
>{
>    double d = 0.8;
>    {
>        extern double d;
>
>        printf ("%f\n", d);
>        return 0;
>    }
>}

>This program *should* print 0.900000, and with most compilers, it does.

This may be the case. However, wether it prints 0.900000, 0.800000,
42 or "segmentation violation, core dumped" is purely a matter
of implementation.
--
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.

Ronald F. Guilmette (rfg@rahul.net) wrote:

[snipped out his personal history]


: -------------------------------------------------------------------------
: double d = 0.9;
:
: int
: main ()
: {
:     double d = 0.8;
:     {
:         extern double d;
:
:         printf ("%f\n", d);
:         return 0;
:     }
: }
: -------------------------------------------------------------------------

: This program *should* print 0.900000, and with most compilers, it does.

Maybe I'm missing the point here... but it seems to me that the program
*should* print 0.8 -- since the "d" defined outside the block is initialized
to 0.8.  I don't have any books with me, but is "extern" *required* to
scope outside of the function? (I thought it just had to scope outside
the current block).



                        Ron Collins

-----
The views expressed here are mine alone, and do not reflect any practice
or policy of the Hughes Aircraft Company.

Ron Collins
Hughes Aircraft Company
Advanced Depot Systems
bldg M20  m/s P20
Tucson, Az  85706
   ----

"Ronald F. Guilmette" <rfg@rahul.net> writes:

>...  Obviously this divergence is orders of
>magnitude more serious than the inaccuracy with the Pentium ever was.
>I thus anticipate the outcry over this problem to be orders of magnitude
>more shrill than was the outcry over the Pentium flaw (and I will of
>course be deeply disappointed if such an outrcy doesn't materalize :-).

There's a subtle difference here (even ignoring the fact that by
definition, free software gives users their full money's worth every
time) -- software can be changed much easier than hardware, and can
even be replaced completely.  If people could replace the CPU in their
computer as easily as they can replace a compiler by one from another
vendor, I'm sure there wouldn't have been such an outcry over the
Pentium too.

Besides, unlike the Pentium bug, this compiler bug is very hard to
bump into, and very easy to avoid.
--
 Amos Shapir  Net: amos@nsof.co.il
Paper: nSOF Parallel Software, Ltd.
       Givat-Hashlosha 48800, Israel
Tel: +972 3 9388551   Fax: +972 3 9388552        GEO: 34 55 15 E / 32 05 52 N

Followup set to comp.lang.c: comp.std.c omitted from the huge list of groups
because it has already been discussed there.

In article <3s4h92$hpf@hacgate2.hac.com>, collins@thor.tu.hac.com (Ron
Collins) writes:
<snip>
|> : double d = 0.9;
|> :
|> : int
|> : main ()
|> : {
|> :     double d = 0.8;
|> :     {
|> :         extern double d;
|> :
|> :         printf ("%f\n", d);
|> :         return 0;
|> :     }
|> : }
|> : -------------------------------------------------------------------------
|>
|> : This program *should* print 0.900000, and with most compilers, it does.
|>
|> Maybe I'm missing the point here... but it seems to me that the program
|> *should* print 0.8 -- since the "d" defined outside the block is
initialized
|> to 0.8.  I don't have any books with me, but is "extern" *required* to
|> scope outside of the function? (I thought it just had to scope outside
|> the current block).

The code should print 0.9 because the d relevant to the printf is the
declaration that says `extern double d;'. When the compiler meets a
definition that specifies extern, it asks if a previous declaration is
visible. (In this case, the answer is yes: the `double d = 0.8;' is visible at
that moment.) If a declaration is visible, it next asks if that declaration
has internal or external linkage. (In this case, the answer is no: that
declaration is block scope declaration that does not specify extern: so it is
a declaration of an object with no linkage). If it has external or internal
linkage, the new declaration specifies the same linkage; otherwise it
specifies external linkage. (So this d has external linkage). The file scope
`double d = 0.9;' does not specify static: at file scope absence of static is
the same as specifying extern. Following the logic mentioned above, this d
also has external linkage.

Now every declaration of a variable with no linkage specifies a unique
object: different from all others during its lifetime. All external
declarations of the same name specify the same object. All internal
declarations (none here) of teh same name _in a given translation unit_
(roughly source file) specify the same object. So, in this case the d being
printed is the same as the d being initialized to 0.9; not the  d being
initialized to 0.8.

(The details of the rules for interpretation of extern has been changed by
the Technical Corrigendum: I described the new rules. For this code, it
does not matter anyway.)

Cheers
Tanmoy
--
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87544-0285,USA H:#3,802,9 St,NM87545
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]

Ronald F. Guilmette (rfg@rahul.net) wrote:
: -------------------------------------------------------------------------
: double d = 0.9;
:
: int
: main ()
: {
:     double d = 0.8;
:     {
:         extern double d;
:
:         printf ("%f\n", d);
:         return 0;
:     }
: }
: -------------------------------------------------------------------------
:
: This program *should* print 0.900000, and with most compilers, it does.

Actually, the program as given doesn't compile.  But inserting the implied
inclusion of <stdio.h> fixes that.  (-:  So just for the record, some more
interesting results.

Borland C++ 2.0 for OS/2         : 0.900000
IBM VisualAge C++ 3.00 for OS/2  : 0.900000
MetaWare High C++ 3.31a for OS/2 : 0.900000
Watcom C++ 10.0b on OS/2         : 0.800000
EMX C++ 0.9a on OS/2             : 0.900000

: But when compiled with one particular popular free C compiler, this
: program will print 0.800000.

Free ?  I think that the people at Watcom will beg to differ with you.  (-:

In article <3s2las$1br@hustle.rahul.net> "Ronald F. Guilmette" <rfg@rahul.net> writes:

  [program deleted]

  This program *should* print 0.900000, and with most compilers, it does.
  But when compiled with one particular popular free C compiler, this
  program will print 0.800000.  Obviously this divergence is orders of
  magnitude more serious than the inaccuracy with the Pentium ever was.
  I thus anticipate the outcry over this problem to be orders of magnitude
  more shrill than was the outcry over the Pentium flaw (and I will of
  course be deeply disappointed if such an outrcy doesn't materalize :-).

Considering that GCC 2.7.0 was released a couple of days ago and does not
suffer from this flaw, I doubt there will be that much outcry.  Would that
Intel could have corrected my Pentium so quickly...

  Leonard