From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,148d39ae0d22411d X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-02 02:37:16 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeed.berkeley.edu!news-hog.berkeley.edu!ucberkeley!enews.sgi.com!news.xtra.co.nz!not-for-mail From: "AG" Newsgroups: comp.lang.ada References: <3BB08F9C.BFB01047@raytheon.com> <3BB10D52.4D455DBA@raytheon.com> <3BB60733.4A80708A@avercom.net> <3BB64B13.81AFFB4D@acm.org> <5ee5b646.0109300510.71255128@posting.google.com> Subject: Re: Pragma Volatile X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Tue, 2 Oct 2001 21:38:54 +1200 NNTP-Posting-Host: 210.55.178.60 X-Complaints-To: newsadmin@xtra.co.nz X-Trace: news.xtra.co.nz 1002015435 210.55.178.60 (Tue, 02 Oct 2001 21:37:15 NZST) NNTP-Posting-Date: Tue, 02 Oct 2001 21:37:15 NZST Organization: Xtra Xref: archiver1.google.com comp.lang.ada:13608 Date: 2001-10-02T21:38:54+12:00 List-Id: "Robert Dewar" wrote in message news:5ee5b646.0109300510.71255128@posting.google.com... > > I often find people making this kind of assumption, and > in the case of reads I saw one awful bug caused by this: > > > type R is array (natural range <>) of Boolean; > pragma Pack (R); > > Register : R (1 .. 32); > for Register'Address use ... > > ... > > B := Register (3); > > one compiler generated a word load, and extracted bit 3. > another compiler generated a byte load, and extracted bit 3 from the > byte. > > Both code sequences are perfectly valid, and just as > efficient as one another. But the hardware had been > build to require word loads, and byte loads were don't > care and put the hardware into some obscure state. > Isn't it true that a compiler that puts it's target machine into some obscure state can't be called perfectly valid? After all, it is the job of the compiler to either produce a valid code or reject what isn't possible. Can you really call a code sequence (generated by a compiler with no control by the programmer) "perfectly valid" if it sends the target machine from here to "some obscure state"? > But of course the real bug is in the implicit assumption > in the code. Well, that may be a bug in the assumptions in the code, but it also looks like a compiler bug in so far that it accepted and (mis)implemented those assumptions.