Ah, weekend time... (01)
> Mark Crispin <mrc@CAC.Washington.EDU> writes:
>
> > This doesn't make sense. In the statement:
> > d.HI = r ? w10mask : w10zero;
> > r is register int and d is register dw10_t. Presumably the complaint
> > is about d, because that's the only thing that approaches being an
> > "array declared register". But then there is no reason that:
> > if (r) {
> > d.HI = w10mask;
> > } else {
> > d.HI = w10zero;
> > should work.
>
> It makes sense since the latter isn't processed the same way. The bug
> is caused by "optimization in the gimplifier" according to the
> compiler support person and looking at that code, is due to trying to
> get the address of the lvalue in the first expression. (02)
Hmm. The only way that "makes sense" makes sense is in the sense of
"this is how the compiler code was written, so it makes sense that the
code is doing the wrong thing". (03)
> I can't say anything about this since I don't know how that compiler
> might be different. I can say however (again, according to the
> compiler support person) that the SGI compiler rejects the code, but
> the Sun compiler accepts it. (04)
Oh, fun game! I can play, too. Clearly the fact that most of us are
working in buildings formerly owned by SGI indicates that SGI products
should not be taken seriously. Did I win? Let's find out by asking
Mr/Ms Compiler Support Person! (05)
> > This is Ken's decision, not mine. I'm just another user of his
> > excellent product.
>
> I second that; especially the comment about his product being
> excellent. (06)
Sucking up will take you a long way :-) (07)
> > IMHO, the f*cking compiler writers should fix their compiler rather
> > than tell people to change code that compiles everyplace else to
> > accomodate their compiler. Perhaps with a few massages to their
> > noggins with a ball-peen hammer to the repeated tune of "Thou shalt
> > NOT break compatibility with deployed code" and "Thou art NOT the (08)
Yeah, we used to worry about that a lot. Flags to allow backward
compatibility, warnings if not, but breaking? No. (09)
The KLH10 code was expressedly meant to be as portable as possible and
make as few assumptions as possible about compiler features. The fact
that this construct has worked for over 14 years on many different
platforms is why MRC and I are a little worked up about the sudden
breakage. (010)
> > Obscure Specification Nits Enforcement Police".
>
> I read through that specific part of the spec earlier. I won't claim
> to understand all implications of what it says, but have a look at:
>
> <http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf>
>
> page 98 (page 110 in the PDF), section 6.7.1, storage-class
> specifiers. Register pretty much is implementation-dependent anyway
> and may be treated as auto, which is probably what happens in the
> example above. (011)
I think this is a subtle linguistic misinterpretation of the intent of
"register", which was to serve as a HINT that this (otherwise "auto")
variable should be given priority for optimizations -- the only thing
that was implementation-dependent is whether or not the compiler
actually put them in machine "registers" (which might not even exist
on some machines). You're also not supposed to take the address of a
"register" variable (and if the compiler tries to do that for you,
it's broken). (012)
I wrote a C compiler and was on X3J11 for a while, so I have some
confidence in this interpretation. This confidence may be misplaced
as it's certainly possible that over time the standards language was
re-worked in a way that induced some people to think differently, but
I'd still have expected better from GCC people. Maybe. (013)
> For what it's worth, I have requested that this issue be logged as a
> bug report against GCC with the FSF. (014)
Thanks! Really appreciate your dogged pursuit of this. (015)
> > Nonetheless, for your (NLS Restoration Project) needs, I'd say just
> > modify the code as you need and be done with the issue. The whole
> > benefit of open source is that you shouldn't have to beg someone to
> > change something for you. You can make the change yourself.
>
> And that's really Jonathan's call. I am just trying to help out. (016)
I agree with MRC. Go ahead and patch it appropriately and get on with
things. (017)
We can incorporate the patch into our master copies along with our own
choice comments, which (again thanks to open source) will be visible
to anyone for as long as the bug exists... (018)
--Ken (019)
_________________________________________________________________
Message Archives: http://chm.cim3.net/forum/nls-technical/
Shared Files: http://chm.cim3.net/file/work/project/nls-restore/
Community Portal: http://www.computerhistory.org/
To Post: mailto:nls-technical@chm.cim3.net
Community Wiki: http://chm.cim3.net/cgi-bin/wiki.pl?NLS_Restoration (020)
|