gcc 4.0 build status
> Output from running srcdir/config.guess. Do not send that file itself, just > the one-line output from running it. i686-pc-linux-gnu > The output of gcc -v for your newly installed gcc. This tells us which > version of GCC you built and the options you passed to configure. Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr Thread model: posix gcc version 4.0.0 > Whether you enabled all languages or a subset of them. If you used a full > distribution then this information is part of the configure options in the > output of gcc -v, but if you downloaded the âcoreâ compiler plus > additional front ends then it isn't apparent which ones you built unless you > tell us about it. all (AFAIK) > If the build was for GNU/Linux, also include: > The distribution name and version (e.g., Red Hat 7.1 or Debian 2.2.3); this > information should be available from /etc/issue. Welcome to SuSE Linux 9.2 (i586) - Kernel \r (\l). > The version of the Linux kernel, available from uname --version or uname -a. Linux marty 2.6.8-24.14-default #1 Tue Mar 29 09:27:43 UTC 2005 i686 i686 i386 GNU/Linux > The version of glibc you used; for RPM-based systems like Red Hat, Mandrake, > and SuSE type rpm -q glibc to get the glibc version, and on systems like > Debian and Progeny use dpkg -l libc6. glibc-2.3.3-118
gcc 4.0.0 optimization vs. id strings (RCS, SCCS, etc.)
Hi,
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. Global strings
are retained, of course, but that may lead to namespace collisions.
#ident doesn't work on some architectures, and functionality can't
be determined at preprocessor time. #sccs doesn't work at all. The
bottom line is that identification which worked with earlier versions
of gcc is broken under 4.0.0. See attached C source code example.
/* the following works with SCCS (what) and RCS et al (ident) with gcc 3.x and
earlier
string symbol is local (static) to object file and does not clash
with symbols similarly defined in other files in the same package
or in library archives used with a package
gcc 4.0.0 with optimization level 2 or greater elides the symbol and string,
breaking identification; -fkeep-static-consts is ineffective with
optimization turned on
*/
static const char rcs_sccs_id[] =
"$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string1\\ $";
/* the following works with gcc 4.0.0, but leaves a globally-visible symbol in
object files where it can clash with other symbols in a package or in an
object file in a library archive
*/
const char idtest_c_rcs_sccs_id2[] =
"$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string2\\ $";
/* gross hack as a workaround for gcc 4.0.0 issue; ID string
symbol is static, but this won't work for a file with no
externally-visible executable functions (e.g. a version file)
*/
static const char idtest_c_rcs_sccs_id3[] =
"$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string3\\ $";
void some_function(void); /* prototype to shut gcc TF up */
void some_function(void) {
const char *unused = idtest_c_rcs_sccs_id3; /* workaround for gcc 4.0.0 issue */
/* ... */ /* real code goes here */
}
/* the following doesn't work on all architectures, and is non-standard
there is no way to test whether it will work at preprocessing time (so that
one of the other methods might be used)
if -fno-ident is specified, it is ineffective even if supported on an
architecture
*/
#ident "$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string4 $"
/* the following doesn't work at all with gcc; it's also non-standard
*/
#sccs "$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string5 $"
New gcc 4.0.0 warnings seem spurious
Demonstration code:
--
#define AAA 0x1U
#define BBB 0x2U
struct foo {
unsigned int bar:8;
};
struct foo foos[] = {
{ ~(AAA) },
{ ~(BBB) },
{ ~(AAA|BBB) },
{ ~(AAA&BBB) }
};
--
compiling with gcc 3.x produced no warnings, as expected (no problems as
all values fit easily within the defined structure's bit field).
gcc 4.0.0 produces:
gcctest.c:9: warning: large integer implicitly truncated to unsigned type
gcctest.c:10: warning: large integer implicitly truncated to unsigned type
gcctest.c:11: warning: large integer implicitly truncated to unsigned type
gcctest.c:12: warning: large integer implicitly truncated to unsigned type
Re: gcc 4.0.0 optimization vs. id strings (RCS, SCCS, etc.)
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).
Re: New gcc 4.0.0 warnings seem spurious
On Tue April 26 2005 11:10, Joseph S. Myers wrote:
> On Tue, 26 Apr 2005, Bruce Lilly wrote:
>
> > Demonstration code:
> > --
> > #define AAA 0x1U
> > #define BBB 0x2U
> >
> > struct foo {
> > unsigned int bar:8;
> > };
> >
> > struct foo foos[] = {
> > { ~(AAA) },
> > { ~(BBB) },
> > { ~(AAA|BBB) },
> > { ~(AAA&BBB) }
> > };
> > --
> >
> > compiling with gcc 3.x produced no warnings, as expected (no problems as
> > all values fit easily within the defined structure's bit field).
>
> I don't see why you think the warnings are spurious. ~(AAA), for example,
> is 4294967294,
No, in this context it is 254 (an 8-bit unsigned field with the LSB clear).
> which being greater than 255 certainly does not fit within
> the type unsigned:8.
But 254 is certainly < 255. The 'U' in the constant simply means unsigned;
if it had been specified as "LU" you might have a point. But it wasn't.
> Previous GCC versions had a long-known bug whereby
> they did not diagnose this; that bug has been fixed in GCC 4.
Looks more like several bugs were introduced; consider:
#if 0
#define AAA 0x1U
#define BBB 0x2U
#else
static const unsigned char AAA = 0x1U;
static const unsigned char BBB = 0x2U;
#endif
struct foo {
unsigned int bar:8;
};
struct foo foos[] = {
{ ~(AAA) },
{ ~(BBB) },
{ ~(AAA|BBB) },
{ ~(AAA&BBB) }
};
gcc 4.0.0 reports:
gcctest.c:14: error: initializer element is not constant
gcctest.c:14: error: (near initialization for 'foos[0].bar')
gcctest.c:15: error: initializer element is not constant
gcctest.c:15: error: (near initialization for 'foos[1].bar')
gcctest.c:16: error: initializer element is not constant
gcctest.c:16: error: (near initialization for 'foos[2].bar')
gcctest.c:17: error: initializer element is not constant
gcctest.c:17: error: (near initialization for 'foos[3].bar')
Now it's claiming that two *explicitly declared* const values aren't
constant!
