On Mon April 25 2005 20:52, Zack Weinberg wrote: > Bruce Lilly <[EMAIL PROTECTED]> writes: > > > Earlier versions of gcc retain static character strings in object > > files which can be used for identification via ident (RCS) or what > > (SCCS). Gcc 4.0.0 removes them above optimization level 1. > > The first observation I'd like to make is that we (the GCC developers, > collectively) don't really understand the need for this. We don't put > $Id$ strings in our own source code, never mind the object files. The > attitude is that the version number of the program as a whole suffices > to figure out which release branch to go looking for the bug in.
That depends on the specifics of the project. For one particular project, which is a library rather than a program, there are about 250 source files. Several are gperf source files generated from some data by awk scripts. So in order to "go looking for the bug", I may need to know which version of an awk script is used, with which version of awk/gawk/mawk/nawk/oawk, what version of gperf is used and with which arguments, and the specific version of data used. Moreover, as the project is open source, I need to be able to determine if some extensions or other modifications are involved. Because the project is a library, that library might have been built by a different person at a different time using a different set of tools from who/what/when for some application program that uses that library. So "the version number of the program as a whole" really says nothing, at least in this case. Other applications of identification strings include copyright information, which in many cases is required to be retained by licensing terms. > Therefore, I hesitate to give you any sort of advice, because as long > as there's no one on the GCC team who understands why this needs to > work, people are going to continue to break it. By analogy with unreferenced static functions, I think gcc should at least provide some warning to the programmer that a static constant string is unreferenced. IMO, that is all that should happen; it should be up to the programmer to either elide unused cruft or to retain content which has some use that the compiler is not able to discern. At the moment, gcc 4.0.0 acts more like a programmer's nanny, removing content with not so much as a warning to the programmer. That has two undesirable effects: 1. it runs counter to the principle of least surprise; if a programmer includes a static constant string, he expects it to be there. 2. it provides no incentive to clean up unused cruft, leading to clutter in code which results in high maintenance costs. > I do have three suggestions for you: > > 1) The current way to tell the compiler not to throw away > apparently-unused data is __attribute__((used)), like this: > > static const char __attribute__((used)) rcs_sccs_id[] = > "$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string1\\ $"; OK, thanks to all who pointed that out. > You can hide this behind a macro so it doesn't interfere with other > compilers. Maybe; that remains to be seen. > 2) #ident currently does something useful if and only if the back-end > defines what to do with it. However, we could define a sensible > default, e.g. converting it to a global string declaration like the > one above. I'd be happy to take a patch that made that change. > > However, the purpose of -fno-ident is to make #ident do nothing; > we're not going to change that. I'm a little confused why you even > bring it up. The idea is to produce identification strings in a portable and dependable manner. Some mechanisms are non-portable, others are not dependable (due to different behavior with different options); some are neither portable nor dependable. > 3) #sccs does nothing because no one has ever told me what it was > supposed to do, or even what its argument syntax was. From what > you write, it's functionally identical to #ident; I'd be happy to > take a patch that made #sccs an alias for #ident. That's what it looks like; but as noted, it's also non-portable, so truly supporting it (as opposed to claiming it as a GNU extension and then ignoring it) doesn't help for new code intended to be portable, although it might improve compatibility for reuse of old code (e.g. on AT&T 3B1s, which used #sccs extensively in header files, IIRC).
