Re: GCC warnings for unused global variables

Re: GCC warnings for unused global variables

[Bonzini]

> This is still the case; it's easy to suppress the warning by adding an
> appropriate attribute, or by use of 'volatile' (at least, I hope
> 'volatile' works, if not it can be fixed).

Is it possible to suppress the warning in -Wall for GCC 3.3, and put in the release
notes that it will become part of -Wall in GCC 3.4?  I cannot believe (whatever wide
the use is) that an obvious optimization of removing unused statics cannot be done
because of rcsid tags only, and adding "volatile" is a solution too: to me, Geoff's
language lawyering is as convincing as Richard's back-end operation lawyering.

So my proposal is:

1) check into GCC 3.3 a patch not to show this warning unless -W (or how is it called
now) is given.  Kean promised it, didn't he?  Maybe it is better to make it very very
little invasive by not adding -Wunused-static-variables, and delaying it to after GCC
3.3 is released?

2) check into the release notes that the warning will be moved to -Wall in GCC 3.4.  So
mankind is warned with at least a year of advance, and let's face that the fix is (more
or less) as simple as grep -rl "^static.*const.*rcsid" | perl -i -pe '!$replaced_yet &&
s/^static.*const(.*rcsid)/volatile$1/ && ($replaced_yet = 1)'.

3) if necessary, check into mainline (and maybe branch after GCC 3.3 is released?) a
patch not to show this warning for volatile variables.

Paolo

Re: GCC warnings for unused global variables

[David O'Brien]

On Fri, May 02, 2003 at 01:42:30PM +0200, Bonzini wrote:
> mankind is warned with at least a year of advance, and let's face that
> the fix is (more or less) as simple as
> grep -rl "^static.*const.*rcsid" | perl -i -pe '!$replaced_yet && s/^static.*const(.*rcsid)/volatile$1/ && ($replaced_yet = 1)'.

You've never worked on a large corporate source base have you?  Just
making the source change is only 1/2 the battle.  Getting the review
board (or release engineer, or what ever) approval for wide sweeping
changes can be quite difficult.
 
-- 
-- David  (obrien@FreeBSD.org)

Re: GCC warnings for unused global variables

[Laurent Guerby]

On Fri, 2003-05-02 at 18:34, David O'Brien wrote:
> On Fri, May 02, 2003 at 01:42:30PM +0200, Bonzini wrote:
> > mankind is warned with at least a year of advance, and let's face that
> > the fix is (more or less) as simple as
> > grep -rl "^static.*const.*rcsid" | perl -i -pe '!$replaced_yet && s/^static.*const(.*rcsid)/volatile$1/ && ($replaced_yet = 1)'.
> 
> You've never worked on a large corporate source base have you?  Just
> making the source change is only 1/2 the battle.  Getting the review
> board (or release engineer, or what ever) approval for wide sweeping
> changes can be quite difficult.

I assume such a body will also disallow compiler change, 
so you won't be hit by the new warning :).

Seriously, someone in your organisation made the decision
to be -Wall warning free, such a decision imply that new
warnings related changes are an accepted maintenance cost
when upgrading compilers.

-- 
Laurent Guerby <guerby@acm.org>

Re: GCC warnings for unused global variables

[David O'Brien]

On Fri, May 02, 2003 at 08:44:51PM +0200, Laurent Guerby wrote:
> On Fri, 2003-05-02 at 18:34, David O'Brien wrote:
> > On Fri, May 02, 2003 at 01:42:30PM +0200, Bonzini wrote:
> > > mankind is warned with at least a year of advance, and let's face that
> > > the fix is (more or less) as simple as
> > > grep -rl "^static.*const.*rcsid" | perl -i -pe '!$replaced_yet && s/^static.*const(.*rcsid)/volatile$1/ && ($replaced_yet = 1)'.
> > 
> > You've never worked on a large corporate source base have you?  Just
> > making the source change is only 1/2 the battle.  Getting the review
> > board (or release engineer, or what ever) approval for wide sweeping
> > changes can be quite difficult.
> 
> I assume such a body will also disallow compiler change, 
> so you won't be hit by the new warning :).

When porting to a new CPU, one has no choice about using an older
compiler.

I just got off the phone with another very, very large ISV with Linux
products.  They are also feeling mucho pain jumping from 3.2.2 -> 3.3 due
to things that were warnings are now errors.  GCC 3.2 had no warning that
such things would be depreciated like this.  *sigh*

-- 
-- David  (obrien@FreeBSD.org)

Re: GCC warnings for unused global variables

[David O'Brien]

On Fri, May 02, 2003 at 08:44:51PM +0200, Laurent Guerby wrote:
> I assume such a body will also disallow compiler change, 
> so you won't be hit by the new warning :).

I also forgot to mention the GCC policy of abandoning a release branch
soon after the .0 release.  Software vendors have to chase the GCC
releases to get bug fixed.  If it weren't for FUBARED -mcpu=pentium4 on
3.2 and porting to AMD64, FreeBSD would hold off the 3.2.2 -> 3.3
upgrade.

-- 
-- David  (obrien@FreeBSD.org)

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

"David O'Brien" <obrien@FreeBSD.org> writes:

| On Fri, May 02, 2003 at 08:44:51PM +0200, Laurent Guerby wrote:
| > I assume such a body will also disallow compiler change, 
| > so you won't be hit by the new warning :).
| 
| I also forgot to mention the GCC policy of abandoning a release branch
| soon after the .0 release.  Software vendors have to chase the GCC
| releases to get bug fixed.

I cannot let this one pass: We got *four* dot releases from
3.1-branch;  the last three were named 3.2.1, 3.2.2, 3.2.3.   They all
were bug fix releases.  Please don't spread misinformation. 

-- Gaby

Re: GCC warnings for unused global variables

[Neil Booth]

Gabriel Dos Reis wrote:-

> "David O'Brien" <obrien@FreeBSD.org> writes:
> 
> | On Fri, May 02, 2003 at 08:44:51PM +0200, Laurent Guerby wrote:
> | > I assume such a body will also disallow compiler change, 
> | > so you won't be hit by the new warning :).
> | 
> | I also forgot to mention the GCC policy of abandoning a release branch
> | soon after the .0 release.  Software vendors have to chase the GCC
> | releases to get bug fixed.
> 
> I cannot let this one pass: We got *four* dot releases from
> 3.1-branch;  the last three were named 3.2.1, 3.2.2, 3.2.3.   They all
> were bug fix releases.  Please don't spread misinformation. 

And same number from 3.0.x.

Neil.

Re: GCC warnings for unused global variables

[Bonzini]

> > the fix is (more or less) as simple as
> > grep -rl "^static.*const.*rcsid" | perl -i -pe '!$replaced_yet &&
s/^static.*const(.*rcsid)/volatile$1/ && ($replaced_yet = 1)'.
>
> You've never worked on a large corporate source base have you?  Just
> making the source change is only 1/2 the battle.  Getting the review
> board (or release engineer, or what ever) approval for wide sweeping
> changes can be quite difficult.

Yes, that was the "more or less" part :-)

In GCC I see that Zack did not have much problems getting approved for changes that
touched every *.c file for example.  Of course I wouldn't get approval for such a
change in FreeBSD, but somebody will nevertheless and people have an year for that.

Paolo

Re: GCC warnings for unused global variables

[Bonzini]

> | I also forgot to mention the GCC policy of abandoning a release branch
> | soon after the .0 release.  Software vendors have to chase the GCC
> | releases to get bug fixed.
> 
> I cannot let this one pass: We got *four* dot releases from
> 3.1-branch;  the last three were named 3.2.1, 3.2.2, 3.2.3.   They all
> were bug fix releases.  Please don't spread misinformation. 

I think he was referring to abandoning the 3.2 branch after 3.3.0 is released.

Paolo

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

"Bonzini" <bonzini@gnu.org> writes:

| > | I also forgot to mention the GCC policy of abandoning a release branch
| > | soon after the .0 release.  Software vendors have to chase the GCC
| > | releases to get bug fixed.
| > 
| > I cannot let this one pass: We got *four* dot releases from
| > 3.1-branch;  the last three were named 3.2.1, 3.2.2, 3.2.3.   They all
| > were bug fix releases.  Please don't spread misinformation. 
| 
| I think he was referring to abandoning the 3.2 branch after 3.3.0 is
| released. 

OK, then I will explain why I closed the branch before 3.3.0 is released.

Until last week we had threee active branches, with clearly not enough
resources to track them all at the same time.  At that point, it was
felt that maintaining  3.2 branch active was wasting resources.


Several times before 3.2.3 went out, I mentioned the fact that I will
propose to close gcc-3_2-branch after the release.  Nobody expressed
disagreements, that for a long time.  I find it a bit strange to
complain now after the fact whereas there  was plenty opportunities to
raise concerns before.

If people feel that they have strong interests in some things, I believe
they should act so as to make them happen.  

-- Gaby

Re: GCC warnings for unused global variables

[David O'Brien]

On Sun, May 04, 2003 at 10:38:10AM +0200, Gabriel Dos Reis wrote:
> Several times before 3.2.3 went out, I mentioned the fact that I will
> propose to close gcc-3_2-branch after the release.  Nobody expressed
> disagreements, that for a long time.  I find it a bit strange to
> complain now after the fact whereas there  was plenty opportunities to
> raise concerns before.

*sigh*
have you not seen my comments on this practice for the past many years???
(other BSD's have said the same thing)
This is not a new thing with 3.2, and you should not take it as laying
blame on you specifically WRT 3.2.

-- 
-- David  (obrien@FreeBSD.org)

Re: GCC warnings for unused global variables

[Bernd Jendrissek]

On Fri, May 02, 2003 at 09:34:55AM -0700, David O'Brien wrote:
> On Fri, May 02, 2003 at 01:42:30PM +0200, Bonzini wrote:
> > mankind is warned with at least a year of advance, and let's face that
> > the fix is (more or less) as simple as
> > grep -rl "^static.*const.*rcsid" | perl -i -pe '!$replaced_yet && s/^static.*const(.*rcsid)/volatile$1/ && ($replaced_yet = 1)'.
> 
> You've never worked on a large corporate source base have you?  Just
> making the source change is only 1/2 the battle.  Getting the review
> board (or release engineer, or what ever) approval for wide sweeping
> changes can be quite difficult.

And getting approval to use a different compiler is easy?

If the legacy code is too "precious" to touch, then just continue to use
gcc-1.42.

Really, I just want my cake and eat it.  I'd like to have -Wunused-static-foo
to find all my dead data, but I *don't* want it hidden among 100's of rcsid
instances.  It would be nice if you could fix (yes I consider static const
char *rcsid = "$foo$" to be a [hairsplitting] bug) your code so that I can
fix mine.

Re: GCC warnings for unused global variables

[David O'Brien]

On Mon, May 05, 2003 at 01:26:31PM +0200, Bernd Jendrissek wrote:
> On Fri, May 02, 2003 at 09:34:55AM -0700, David O'Brien wrote:
> > On Fri, May 02, 2003 at 01:42:30PM +0200, Bonzini wrote:
> > > mankind is warned with at least a year of advance, and let's face that
> > > the fix is (more or less) as simple as
> > > grep -rl "^static.*const.*rcsid" | perl -i -pe '!$replaced_yet && s/^static.*const(.*rcsid)/volatile$1/ && ($replaced_yet = 1)'.
> > 
> > You've never worked on a large corporate source base have you?  Just
> > making the source change is only 1/2 the battle.  Getting the review
> > board (or release engineer, or what ever) approval for wide sweeping
> > changes can be quite difficult.
> 
> And getting approval to use a different compiler is easy?

It is when you haven't any choice.
 
> If the legacy code is too "precious" to touch, then just continue to use
> gcc-1.42.

Sorry gcc 1.42 does not generate AMD64 code.

-- 
-- David  (obrien@FreeBSD.org)

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

"David O'Brien" <obrien@FreeBSD.org> writes:

| On Sun, May 04, 2003 at 10:38:10AM +0200, Gabriel Dos Reis wrote:
| > Several times before 3.2.3 went out, I mentioned the fact that I will
| > propose to close gcc-3_2-branch after the release.  Nobody expressed
| > disagreements, that for a long time.  I find it a bit strange to
| > complain now after the fact whereas there  was plenty opportunities to
| > raise concerns before.
| 
| *sigh*
| have you not seen my comments on this practice for the past many years???

Mind you, it is already a time-consuming task to follow GCC; if you
have anything specific about GCC project process you think people
should read, please write it here.  If you already did, then I would
be pleased to read it (in case I missed it) if you can provide
specific links. 

-- Gaby

Re: GCC warnings for unused global variables

[Robert Dewar]

I agree with Mike Stump, volatile in practice is well enough defined to be
very useful, and it makes no sense to make blanket statements that it is
too fuzzy to be useful.

Re: GCC warnings for unused global variables

[Paul Koning]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

 Joe> On Fri, May 09, 2003 at 10:29:39AM +0200, Gabriel Dos Reis
 Joe> wrote:
 >> Telling users that something has no well-defined semantics is part
 >> of educating users about what is practically portable.  It is not
 >> frightening them.

 Joe> Gaby, I disagree.  You *are* likely to frighten users.

Absolutely.

Speaking as a user -- an implementer of embedded systems, which use
"volatile" for device drivers, for SMP, and for multi-threaded code in
general, I was thoroughly shocked by the claim that "volatile" cannot
be used to write reliable code.  That statement had no connection
whatsoever with any of my experience of 15 years of embedded C
programming.

I interpreted it as a warning that gcc may make drastic changes in its
implementation of "volatile" (for example, optimizing away references
on the grounds that the compiler believes it knows they have no side
effects) in the future -- and that any complaints would be answered by
"you've been warned".  Such a notion is completely unacceptable.

If that's not the message you intended to convey, I believe a
clarification is called for, because yes indeed, you did frighten
users.

	paul

Re: GCC warnings for unused global variables

[Joe Buck]

On Fri, May 09, 2003 at 10:29:39AM +0200, Gabriel Dos Reis wrote:
> Telling users that something has no well-defined semantics is
> part of educating users about what is practically portable.  It is not
> frightening them.

Gaby, I disagree.  You *are* likely to frighten users.  volatile is a
needed feature, and your claim of "no well-defined semantics" is not accurate.
It is correct to claim that there are *aspects* of volatile where the
semantics are not well-defined, but there are other aspects that are
quite clear; specifically that the compiler cannot eliminate any reads
and writes that occur in the abstract machine.  Precisely because of
the fact that volatile is designed to support access to the declared object
that cannot be "seen" by the compiler, the "as-if" rule cannot be used
to justify transformations.

There are many codes that rely on this feature, and for a GCC maintainer
to suggest that GCC might break such codes is scary.  Embedded systems
programmers rely on this stuff.

In cases where there is doubt, GCC should (as it does now) err on the
side of doing no optimizations.

> My point is that volatile is so fuzzy that different people have
> different expectations of what it should do and any attempt of
> clafirication would not meet expectations of some people, would break
> some software written with another set of expectations in mind (if you
> look at the archive, you'll notice that everytime one touches
> volatile, it follows large (violent) debates); so probably
> the least bad thing to do is to do nothing.

EXACTLY.
 

Re: GCC warnings for unused global variables

[Mike Stump]

On Friday, May 9, 2003, at 01:11 AM, Gabriel Dos Reis wrote:
> Mike Stump <mrs@apple.com> writes:
>
> | On Friday, May 2, 2003, at 07:56 AM, Gabriel Dos Reis wrote:
> | > They can be optimized out if the program cannot tell the 
> difference.
> |
> | Disagree.  I think the above is probably either confusing, or wrong.
> | We can better well what you mean if you tell us if, in:
> |
> | Given:
> |
> | extern volatile int i;
> | int main() {
> | 	i = 1;
> | 	i = 2;
> | }
> |
> | can the program tell the difference?
>
> Obviously, with no information about the definition of "i", the
> compiler does not have any information necessary to infer that the
> optimization is legit.  Where is the problem?

I can change it to:

volatile int i __attribute__((section, "iocontrol_5"));

void foo() {
	i = 1;
	i = 2;
}

or just:

volatile int i;

void foo() {
	i = 1;
	i = 2;
}

if you think that changes anything.

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

Mike Stump <mrs@apple.com> writes:

| On Friday, May 2, 2003, at 09:43 AM, Gabriel Dos Reis wrote:
| > I think you got my messages wrong.
| 
| No, we understand what you are saying, we just disagree with it.

Certainly, there are obviously disagreement but it not true that you
understood what I said.  You posted an example that has nothing to do
with the point of disagreement.

[...]

| Our job should be to educate users as to what is practically portable,

Telling users that something has no well-defined semantics is
part of educating users about what is practically portable.  It is not
frightening them.  It is not scaring them.  However telling them that
volatile is well defined is far from being true.  If it were that
well-defined, there would not be so much discussions about it, either 
on GCC lists for years, at committee meetings, with proposals to
clarify it, etc. 

[...]

| I'm much rather you propose wording to add to the gcc manual that
| states exactly what you think volatile should mean, we can then debate
| it and agree and put it in, or disagree and try and have you adopt our
| view.

My point is that volatile is so fuzzy that different people have
different expectations of what it should do and any attempt of
clafirication would not meet expectations of some people, would break
some software written with another set of expectations in mind (if you
look at the archive, you'll notice that everytime one touches
volatile, it follows large (violent) debates); so probably
the least bad thing to do is to do nothing.

-- Gaby

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

Mike Stump <mrs@apple.com> writes:

| On Friday, May 2, 2003, at 07:56 AM, Gabriel Dos Reis wrote:
| > They can be optimized out if the program cannot tell the difference.
| 
| Disagree.  I think the above is probably either confusing, or wrong.
| We can better well what you mean if you tell us if, in:
| 
| Given:
| 
| extern volatile int i;
| int main() {
| 	i = 1;
| 	i = 2;
| }
| 
| can the program tell the difference?

Obviously, with no information about the definition of "i", the
compiler does not have any information necessary to infer that the
optimization is legit.  Where is the problem?

-- Gaby

Re: GCC warnings for unused global variables

[Paul Koning]

>>>>> "Mike" == Mike Stump <mrs@apple.com> writes:

 Mike> On Friday, May 2, 2003, at 09:43 AM, Gabriel Dos Reis wrote:

 >> What I was saying, as already written in another message, is that
 >> volatile is not a reliable feature to use to write robust code
 >> with reproducible or predictable behaviour.

 Mike> I'd say that volatile is a useful productive and reliable
 Mike> feature of C and C++ compilers and has been for a long time,
 Mike> and that those that don't understand what it is and does,
 Mike> shouldn't work on volatile in the compilers, nor should they
 Mike> write code that uses volatile.  I think we should refrain from
 Mike> frightening users or implementors that want to learn about
 Mike> volatile.  I think statements like the above can frighten naive
 Mike> users, and this is bad.

 Mike> Our job should be to educate users as to what is practically
 Mike> portable, what works, what it means, and to fix any
 Mike> deficiencies in any language standards that can promise more
 Mike> and don't.  We can document in our manual what we think it
 Mike> should mean, if there are grey areas not perfectly clear in the
 Mike> language standard.

 Mike> I don't see the point in scaring users wrt volatile.  I don't
 Mike> see the use in it.

 Mike> I'm much rather you propose wording to add to the gcc manual
 Mike> that states exactly what you think volatile should mean, we can
 Mike> then debate it and agree and put it in, or disagree and try and
 Mike> have you adopt our view.

I agree 100%.

     paul

Re: GCC warnings for unused global variables

[Mike Stump]

On Friday, May 2, 2003, at 07:56 AM, Gabriel Dos Reis wrote:
> They can be optimized out if the program cannot tell the difference.

Disagree.  I think the above is probably either confusing, or wrong.  
We can better well what you mean if you tell us if, in:

Given:

extern volatile int i;
int main() {
	i = 1;
	i = 2;
}

can the program tell the difference?  If you say no, then I think your 
statement is wrong, otherwise, if you mean if and only if and not just 
if above, then I think your statement is confusing.

Re: GCC warnings for unused global variables

[Mike Stump]

On Friday, May 2, 2003, at 09:43 AM, Gabriel Dos Reis wrote:
> I think you got my messages wrong.

No, we understand what you are saying, we just disagree with it.

> What I was saying, as already written in another message, is that
> volatile is not a reliable feature to use to write robust code with
> reproducible or predictable behaviour.

I'd say that volatile is a useful productive and reliable feature of C 
and C++ compilers and has been for a long time, and that those that 
don't understand what it is and does, shouldn't work on volatile in the 
compilers, nor should they write code that uses volatile.  I think we 
should refrain from frightening users or implementors that want to 
learn about volatile.  I think statements like the above can frighten 
naive users, and this is bad.

Our job should be to educate users as to what is practically portable, 
what works, what it means, and to fix any deficiencies in any language 
standards that can promise more and don't.  We can document in our 
manual what we think it should mean, if there are grey areas not 
perfectly clear in the language standard.

I don't see the point in scaring users wrt volatile.  I don't see the 
use in it.

I'm much rather you propose wording to add to the gcc manual that 
states exactly what you think volatile should mean, we can then debate 
it and agree and put it in, or disagree and try and have you adopt our 
view.

Re: GCC warnings for unused global variables

[Mike Stump]

On Thursday, May 8, 2003, at 12:42 PM, David O'Brien wrote:
> One has to be very proactive to have this.  I've done contract work
> updating people's old source bases with their custom hacks to recent
> releases.  They certainly weren't this proactive.

Hum, if all else fails:

min=MAXINT
for i in all versions do;
	v=`cvs update -p -r$i file.c | diff - file.c | wc -l`
	if [ v < min ];
		save_v=$i;
		min=v
	fi
done
echo $save_v

I know, gross, but, when all else has failed...

Re: GCC warnings for unused global variables

[David O'Brien]

On Thu, May 08, 2003 at 12:36:00PM -0700, Mike Stump wrote:
> >I hate to say it, but *HATE* that GCC source file have no way of 
> >knowing
> >which rev they are.  It has been a problem more than once.
> 
> They do, just type cvs status file.c.  :-(  If you want source to know 
> what version it is, why not have a flag -DVERSION="\"`grep $file 
> CVS/Entries`\"" in the .o.c rule?
> 
> If you want files under two (or more) different cvs systems, just 
> create scripts that link CVS to CVS-name_of_tree through out the whole 
> hierarchy?  Simple, easy to do, works like a charm.  I've done stuff 
> like this before, it it works really spiffy.
> 
> push gcc
> cvs status file.c
> [ info on what version in the gcc tree file.c came from ]
> push freebsd
> cvs status file.c
> ] info on what version in the freebsd tree file.c came from ]

One has to be very proactive to have this.  I've done contract work
updating people's old source bases with their custom hacks to recent
releases.  They certainly weren't this proactive.

Re: GCC warnings for unused global variables

[Mike Stump]

On Friday, May 2, 2003, at 08:54 AM, David O'Brien wrote:
> On Thu, May 01, 2003 at 11:42:57AM -0700, Richard Henderson wrote:
>> On Thu, May 01, 2003 at 10:54:44AM -0700, Kean Johnston wrote:
>>> I am frankly surprised you don't see that and are fighting
>>> so hard for this to stay in -Wall.
>>
>> Perhaps a personal bias.  I've always *hated* rcsid tags.
>
> I hate to say it, but *HATE* that GCC source file have no way of 
> knowing
> which rev they are.  It has been a problem more than once.

They do, just type cvs status file.c.  :-(  If you want source to know 
what version it is, why not have a flag -DVERSION="\"`grep $file 
CVS/Entries`\"" in the .o.c rule?

If you want files under two (or more) different cvs systems, just 
create scripts that link CVS to CVS-name_of_tree through out the whole 
hierarchy?  Simple, easy to do, works like a charm.  I've done stuff 
like this before, it it works really spiffy.

push gcc
cvs status file.c
[ info on what version in the gcc tree file.c came from ]
push freebsd
cvs status file.c
] info on what version in the freebsd tree file.c came from ]

Re: GCC warnings for unused global variables

[Bernd Jendrissek]

On Fri, May 02, 2003 at 09:42:23AM -0700, Joe Buck wrote:
> On Fri, May 02, 2003 at 06:00:30PM +0200, Gabriel Dos Reis wrote:
> > | Because, since the object is volatile, it may affect the program in
> > | ways unknown to the compiler.
> > 
> > This is my favorite peeve against the definition of "volatile".
> > Does an alpha ray fired from Centauri count as a "way unknown to the
> > compiler"?
> 
> This is a much better example than you thought it was.  The answer is
> "yes".  Alpha particles are a major source of soft errors; they can
> spontaneously change the value that is stored in RAM.  Duplicated
> reads can't be eliminated because they might miss the change caused
> by the alpha particle.  A memory test might be written in C with
> a big volatile array, and one of the things it would be looking for
> is effects caused by alpha particles.

Thanks!  I hadn't thought of this kind of "unknown to the compiler" effect
until now.  What I was missing was that the "unknown effect" needn't
necessarily be deterministic, IOW just because the compiler can *prove*
that a variable isn't deterministically accessible doesn't mean that no
"unknown" accesses happen.  So now I'm convinced that in

void foo(void)
{
	int volatile bar = 42;
	int baz;
	baz = bar - bar;
}

there is no guarantee that baz == 0.  And that GCC may not play smarty-pants
even here.

Hmm, I seem to recall a similar thread last year or so...

http://gcc.gnu.org/ml/gcc/1998-06/msg00098.html (Hmm, no, too old.)

Here we go: [PATCH] C undefined behavior fix

http://gcc.gnu.org/ml/gcc/2002-01/msg00808.html is part of
http://gcc.gnu.org/ml/gcc/2002-01/msg00031.html

> (Of course, an alpha particle can't make it through the atmosphere,
> so you'll need to pick some other particle or photon type).

But IIRC alpha particles do (or did) come out of weird isotopes in the
ceramic casing around DRAM chips.

bernd

Re: GCC warnings for unused global variables

[Geoff Keating]

> X-Original-To: geoffk@foam.wonderslug.com
> From: "Kean Johnston" <jkj@sco.com>
> Cc: <gdr@integrable-solutions.net>, <fjh@cs.mu.OZ.AU>, <jbuck@synopsys.com>,
>    <espie@quatramaran.ens.fr>, <gcc@gcc.gnu.org>
> Date: Fri, 2 May 2003 21:27:00 -0700
> Organization: The SCO Group
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
> Importance: Normal
> X-OriginalArrivalTime: 03 May 2003 04:37:15.0533 (UTC) FILETIME=[AC1DA3D0:01C3112D]
> X-MIME-Autoconverted: from quoted-printable to 8bit by desire.geoffk.org id h434cdn13707
> 
> > It's implementation-defined what is an 'access'.
> > 
> > It looks like it's useful to define initialization as an 'access', for
> > exactly this case: rcsid, or in general magic code that looks at
> > object files.  So, let's do that.
> Careful.
> 
> If you mark initialization as access, and that makes the warnings go
> away, we'd lose some considerable value to the warning. Just because
> this rcsid is such a PITA, doesn't mean it shouldbe be warned about
> if that's what the user wants, but since its initialized, if that makes
> the warning go away that's bad. Same for any other variable that's
> initialzied but not used (in static scope of course).

This would only be for volatile initialized static variables, not the
general case.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: GCC warnings for unused global variables

[Robert Dewar]

> The guide to compiler writers for Volatile is pretty explicit in the
> annotated RM (which is freely available):

Just for the record the annotated RM has no official status whatever

Re: GCC warnings for unused global variables

[Robert Dewar]

> I hate to say it, but *HATE* that GCC source file have no way of knowing
> which rev they are.  It has been a problem more than once.

I must say I agree. We always had the version as part of the source for
GNAT, and have removed it for consistency with the gcc tree, and it is
a pain in the neck that this is no longer present :-(

RE: GCC warnings for unused global variables

[Kean Johnston]

> It's implementation-defined what is an 'access'.
> 
> It looks like it's useful to define initialization as an 'access', for
> exactly this case: rcsid, or in general magic code that looks at
> object files.  So, let's do that.
Careful.

If you mark initialization as access, and that makes the warnings go
away, we'd lose some considerable value to the warning. Just because
this rcsid is such a PITA, doesn't mean it shouldbe be warned about
if that's what the user wants, but since its initialized, if that makes
the warning go away that's bad. Same for any other variable that's
initialzied but not used (in static scope of course).

Kean

Re: GCC warnings for unused global variables

[Geoff Keating]

> Date: Fri, 2 May 2003 13:12:35 -0700
> From: Richard Henderson <rth@redhat.com>

> On Fri, May 02, 2003 at 11:45:10AM -0400, Paul Jarc wrote:
> > If volatile is used, then the compiler cannot know whether accesses
> > and side effects are needed.  (This is exactly what is expressed by
> > volatile.)  Do you agree or disagree?
> 
> Agree.
> 
> However, I do not agree that "existance" is either an access
> or a side effect.

It's implementation-defined what is an 'access'.

It looks like it's useful to define initialization as an 'access', for
exactly this case: rcsid, or in general magic code that looks at
object files.  So, let's do that.

I will create a patch...

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: GCC warnings for unused global variables

[tm_gccmail]

On Fri, 2 May 2003 tm_gccmail@mail.kloo.net wrote:

> On Fri, 2 May 2003, Richard Henderson wrote:
> 
> > On Fri, May 02, 2003 at 08:38:44AM -0700, Kean Johnston wrote:
> > > I don't know if such code exists, but it wouldn't surprise me terribly
> > > if some smart bloke somewhere has organised, through link editor
> > > trickery or other object-file manipulation, that code like:
> > > 
> > > static volatile int foo;
> > > 
> > > void doit (void)
> > > {
> > >   foo = 1;
> > >   foo = 2;
> > > }
> > > 
> > > actually orchestrates that because the symbol is marked as volatile,
> > > whether static or not, that it is mapped to some I/O port or special
> > > memory location or any number of possible things, and that the mere act
> > > of assigning a value to it writes data to the port.
> > 
> > I suppose it's not impossible, however, that it's one of the
> > least straightforward ways to accomplish this.  If I were going
> > to have the link-editor place foo on some I/O port, then I'd
> > declare it "extern", not "static".
> > 
> > > I belive that THAT
> > > kind of trickery was the intent behind volatile.
> > 
> > We'll have to disagree then.  No one's come up with anything
> > convincing so far.
> > 
> > 
> > r~
> 
> We used a global volatile int for flags between the two SH2 processors on
> a Sega 32x game system. So there are legitimate reasons.
> 
> Toshi

Actually, I thought of two more:

2. Flag between mainline and interrupt code in a stand-alone ROM
application.

3. Flag between threads in a threaded application.

Toshi

Re: GCC warnings for unused global variables

[Richard Henderson]

On Fri, May 02, 2003 at 02:19:19PM -0700, tm_gccmail@mail.kloo.net wrote:
> We used a global volatile int for flags between the two SH2 processors on
> a Sega 32x game system. So there are legitimate reasons.

Did you reference that variable by name?  Yes.  So that's
outside the topic under dispute.


r~

Re: GCC warnings for unused global variables

[Toon Moene]

Gabriel Dos Reis wrote:

> I already quoted Linus on volatile, here is something from someone who
> has designed and implemented languages, operating systems and
> simulators:
> 
>   [...] However, I never had strong feeelings about volatile and see
>   no reason to improve on the ANSI C committee's decisions in this area.
>      
>          B. Stroustrup, in D&E

Oh, that's nothing.  For many a year, the draft Fortran 2000 Standard 
already contains a "definition" of VOLATILE - or, as the editor of the 
Standard likes to put it "a standard spelling for indicating 
non-standard behaviour".  Not suprisingly, I caught a subgroup last J3 
meeting discussing something that suspiciously looked like "sequence 
points" because without them, volatile has little meaning.

That's for a language that has been successful without sequence points 
(or volatile) for half a century.

And no, that's not because no operating systems have ever been written 
in it.  Good ol' Fortran 66 had a splendid way of preventing accesses to 
memory being "optimized away":

       COMMON /AAP/ MEM
       ...
       FOO = MEM
       CALL DUMSUB
       FOO = MEM
       ...
       END

As whatever DUMSUB does to MEM is outside the scope of the "processor" 
(compiler/runtime/cpu in Fortran Standardese) this effectively causes 
the MEM access to be performed twice.

[ and don't complain about the cost of a subroutine call - in comparison
   with memory access times that's negligible ]

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

Re: GCC warnings for unused global variables

[tm_gccmail]

On Fri, 2 May 2003, Richard Henderson wrote:

> On Fri, May 02, 2003 at 08:38:44AM -0700, Kean Johnston wrote:
> > I don't know if such code exists, but it wouldn't surprise me terribly
> > if some smart bloke somewhere has organised, through link editor
> > trickery or other object-file manipulation, that code like:
> > 
> > static volatile int foo;
> > 
> > void doit (void)
> > {
> >   foo = 1;
> >   foo = 2;
> > }
> > 
> > actually orchestrates that because the symbol is marked as volatile,
> > whether static or not, that it is mapped to some I/O port or special
> > memory location or any number of possible things, and that the mere act
> > of assigning a value to it writes data to the port.
> 
> I suppose it's not impossible, however, that it's one of the
> least straightforward ways to accomplish this.  If I were going
> to have the link-editor place foo on some I/O port, then I'd
> declare it "extern", not "static".
> 
> > I belive that THAT
> > kind of trickery was the intent behind volatile.
> 
> We'll have to disagree then.  No one's come up with anything
> convincing so far.
> 
> 
> r~

We used a global volatile int for flags between the two SH2 processors on
a Sega 32x game system. So there are legitimate reasons.

Toshi

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

<tm_gccmail@mail.kloo.net> writes:

| On 2 May 2003, Gabriel Dos Reis wrote:
| 
| > Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
| > 
| > | On 02-May-2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| > | > prj@po.cwru.edu (Paul Jarc) writes:
| > | > 
| > | > | Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| > | > | > Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
| > | > | >| I don't think the committee ever intended to allow implementations
| > | > | >| to optimize away volatile variables,
| > | > | >
| > | > | > Why not?  The C standard clearly says:
| > | > | >
| > | > | >        [#3] In the abstract machine, all expressions are  evaluated
| > | > | >        as  specified  by  the  semantics.  An actual implementation
| > | > | >        need not evaluate part of an expression  if  it  can  deduce
| > | > | >        that  its  value is not used and that no needed side effects
| > | >                                                  ^^^^^^^^^
| > | > | >        are produced (including any caused by calling a function  or
| > | > | >        accessing a volatile object).
| >                ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
| > 
| > | > | 
| > | > | Accessing a volatile object includes writing, and writing includes
| > | > | initializing.  So the initialization cannot be optimized out.
| > | > 
| > | > Why? the last part of the paragraph quoted above does specifically
| > | > permit that optimization where applicable.
| > | 
| > | In the case of accesses to volatile objects, it is never applicable.
| > 
| > Even when the standard writes it?  Hugh. 
| 
| Seemingly meaningless read/writes from/to volatile variables usually have

The discussion was not about "seemingly meaningless read/writes".
Please to not confuse the matter further.

-- Gaby

Re: GCC warnings for unused global variables

[tm_gccmail]

On 2 May 2003, Gabriel Dos Reis wrote:

> Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
> 
> | On 02-May-2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> | > prj@po.cwru.edu (Paul Jarc) writes:
> | > 
> | > | Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> | > | > Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
> | > | >| I don't think the committee ever intended to allow implementations
> | > | >| to optimize away volatile variables,
> | > | >
> | > | > Why not?  The C standard clearly says:
> | > | >
> | > | >        [#3] In the abstract machine, all expressions are  evaluated
> | > | >        as  specified  by  the  semantics.  An actual implementation
> | > | >        need not evaluate part of an expression  if  it  can  deduce
> | > | >        that  its  value is not used and that no needed side effects
> | >                                                  ^^^^^^^^^
> | > | >        are produced (including any caused by calling a function  or
> | > | >        accessing a volatile object).
>                ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> 
> | > | 
> | > | Accessing a volatile object includes writing, and writing includes
> | > | initializing.  So the initialization cannot be optimized out.
> | > 
> | > Why? the last part of the paragraph quoted above does specifically
> | > permit that optimization where applicable.
> | 
> | In the case of accesses to volatile objects, it is never applicable.
> 
> Even when the standard writes it?  Hugh. 

Seemingly meaningless read/writes from/to volatile variables usually have
a programmer-intended side effect.

On the SH series, the interrupt controller requires a write to reset
level-triggered interrupts. We don't care about the value of the write; it
just needs a write to a certain address. So we do:

	*clear_trigger = 0;

On the SH, we need three reads in the reset code to initialize the SDRAM
burst mode. The value read doesn't matter; we just need to trigger reads
on the hardware bus. So we do:

	c = *magic_pointer1;
	c = *magic_pointer2;
	c = *magic_pointer3;

When we fill a serial FIFO with data, we do:

	for (i=0; i<4; i++)
		*data_reg = *c++;

I do not want this optimized to:

	*data_reg = c[3];

Do not touch the happy fun volatile values, or all the hardware drivers in
the world will break, including the ones in Linux, FreeBSD, NetBSD,
OpenBSD, QNX, VxWorks, RTEMS, etc.

Toshi

Re: GCC warnings for unused global variables

[Richard Henderson]

On Fri, May 02, 2003 at 11:45:10AM -0400, Paul Jarc wrote:
> If volatile is used, then the compiler cannot know whether accesses
> and side effects are needed.  (This is exactly what is expressed by
> volatile.)  Do you agree or disagree?

Agree.

However, I do not agree that "existance" is either an access
or a side effect.



r~

Re: GCC warnings for unused global variables

[Richard Henderson]

On Fri, May 02, 2003 at 08:38:44AM -0700, Kean Johnston wrote:
> I don't know if such code exists, but it wouldn't surprise me terribly
> if some smart bloke somewhere has organised, through link editor
> trickery or other object-file manipulation, that code like:
> 
> static volatile int foo;
> 
> void doit (void)
> {
>   foo = 1;
>   foo = 2;
> }
> 
> actually orchestrates that because the symbol is marked as volatile,
> whether static or not, that it is mapped to some I/O port or special
> memory location or any number of possible things, and that the mere act
> of assigning a value to it writes data to the port.

I suppose it's not impossible, however, that it's one of the
least straightforward ways to accomplish this.  If I were going
to have the link-editor place foo on some I/O port, then I'd
declare it "extern", not "static".

> I belive that THAT
> kind of trickery was the intent behind volatile.

We'll have to disagree then.  No one's come up with anything
convincing so far.


r~

Re: GCC warnings for unused global variables

[Laurent Guerby]

On Fri, 2003-05-02 at 19:08, Joel Sherrill wrote:
> Hopefully Dr. Dewar is out there listening because he could comment
> on the requirements of the Ada LRM for pragma volatile.  My
> understanding
> is that the requirements for the feature and expected behavior is
> very much the same.

Volatile for Ada is defined in terms of external effects for
memory read and write. So it works for alpha particle detection
but do not apply to static unread variables being kept
in the object file. 

For this very platform (object code format) specific purpose a pragma
Export with a compiler defined convention (In_Object_But_Not_In_Memory
:) is probably the way to do it in the Ada RM spirit.

The guide to compiler writers for Volatile is pretty explicit in the
annotated RM (which is freely available):

<<
20    {external effect (volatile/atomic objects) [partial]} The external
effect of a program (see 1.1.3) is defined to include each read and update of
a volatile or atomic object. The implementation shall not generate any memory
reads or updates of atomic or volatile objects other than those specified by
the program.

    20.a  Discussion: The presumption is that volatile or atomic objects might
          reside in an ``active'' part of the address space where each read
          has a potential side-effect, and at the very least might deliver a
          different value.

    20.b  The rule above and the definition of external effect are intended to
          prevent (at least) the following incorrect optimizations, where V is
          a volatile variable:

    20.c  X:= V; Y:=V; cannot be allowed to be translated as Y:=V; X:=V;

    20.d  Deleting redundant loads: X:= V; X:= V; shall read the value of V
          from memory twice.

    20.e  Deleting redundant stores: V:= X; V:= X; shall write into V twice.

    20.f  Extra stores: V:= X+Y; should not translate to something like V:= X;
          V:= V+Y;

    20.g  Extra loads: X:= V; Y:= X+Z; X:=X+B; should not translate to
          something like Y:= V+Z; X:= V+B;

    20.h  Reordering of loads from volatile variables: X:= V1; Y:= V2;
          (whether or not V1 = V2) should not translate to Y:= V2; X:= V1;

    20.i  Reordering of stores to volatile variables: V1:= X; V2:= X; should
          not translate to V2:=X; V1:= X;
>>

If a Volatile variable is not read, the compiler is free to remove
it entirely. For Volatile constant, there's a specific rule: 

<<
13    If a pragma Volatile, Volatile_Components, Atomic, or Atomic_Components
applies to a stand-alone constant object, then a pragma Import shall also
apply to it.

    13.a  Ramification: Hence, no initialization expression is allowed for
          such a constant. Note that a constant that is atomic or volatile
          because of its type is allowed.

    13.b  Reason: Stand-alone constants that are explicitly specified as
          Atomic or Volatile only make sense if they are being manipulated
          outside the Ada program. From the Ada perspective the object is
          read-only. Nevertheless, if imported and atomic or volatile, the
          implementation should presume it might be altered externally. For an
          imported stand-alone constant that is not atomic or volatile, the
          implementation can assume that it will not be altered.
>>


-- 
Laurent Guerby <guerby@acm.org>

Re: GCC warnings for unused global variables

[DJ Delorie]

> A memory test might be written in C with a big volatile array, and
> one of the things it would be looking for is effects caused by alpha
> particles.

There is no "might".  One of my friends did this in school.  They were
testing radiation-hardened ram chips.  I don't recall what programming
language they were using, though.

Re: GCC warnings for unused global variables

[Joe Buck]

On Fri, May 02, 2003 at 07:10:35PM +0200, Gabriel Dos Reis wrote:
> | Gaby, surely you know that the reason that volatile is in the language
> 
> I certainly know what kinds of problems it was supposed to solve.  My
> claim is what get specified in the standard does address those sorts of
> problems in any reliable way. No just because some semantics was
> specified for "volatile" means that it effectively addresses the
> original problems.  And I think that opinion is also held by
> people with respected experience on drivers and OSes area.  

If we take the view that the standard is the only contract between
the compiler writers and the users, then the semantics defined for
volatile will be found lacking.  In such cases, we will need to go
further, so that, as far as possible, the problems that volatile
was intended to handle get handled by GCC.  Because the resulting "spec" is
so fuzzy, I'm afraid that this is going to be an iterative process.

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.com> writes:

| > I'm trying to say that "volatile" is not a *reliable* feature to use
| > to write robust code with reproducible behaviour.
| > 
| > | static volatile int foo;
| > | 
| > | void test (void)
| > | {
| > | 	foo = 1;
| > | 	foo = 1;
| > | }
| > | 
| > | Does your statement mean that you believe the compiler is allowed to
| > | optimize this into:
| > | void test (void)
| > | {
| > | 	foo = 1;
| > | }
| > | ?
|  
| On Fri, May 02, 2003 at 05:18:02PM +0200, Gabriel Dos Reis wrote:
| > If it can determine that does nto change the behaviour of whole
| > program, yes, it is permitted to do so.
| 
| Gaby, surely you know that the reason that volatile is in the language

I certainly know what kinds of problems it was supposed to solve.  My
claim is what get specified in the standard does address those sorts of
problems in any reliable way. No just because some semantics was
specified for "volatile" means that it effectively addresses the
original problems.  And I think that opinion is also held by
people with respected experience on drivers and OSes area.  

I already quoted Linus on volatile, here is something from someone who
has designed and implemented languages, operating systems and
simulators:

  [...] However, I never had strong feeelings about volatile and see
  no reason to improve on the ANSI C committee's decisions in this area.
     
         B. Stroustrup, in D&E
 

| is to allow C to be used to write code that interacts with hardware,
| or with other invisible software that the compiler can't see.  If you
| can find language in the standard that suggests that one of the writes
| to foo can be legally eliminated, it's defect report time.

This is not the first discussion about the semantics of volatile --
and this certainly won't be the last one.  I do not believe, volatile
could be repaired in any way satisfactory for people.  

-- Gaby

Re: GCC warnings for unused global variables

[Joel Sherrill]

Joe Buck wrote:
> 
> On Fri, May 02, 2003 at 06:00:30PM +0200, Gabriel Dos Reis wrote:
> > | Because, since the object is volatile, it may affect the program in
> > | ways unknown to the compiler.
> >
> > This is my favorite peeve against the definition of "volatile".
> > Does an alpha ray fired from Centauri count as a "way unknown to the
> > compiler"?
> 
> This is a much better example than you thought it was.  The answer is
> "yes".  Alpha particles are a major source of soft errors; they can
> spontaneously change the value that is stored in RAM.  Duplicated
> reads can't be eliminated because they might miss the change caused
> by the alpha particle.  A memory test might be written in C with
> a big volatile array, and one of the things it would be looking for
> is effects caused by alpha particles.
> 
> (Of course, an alpha particle can't make it through the atmosphere,
> so you'll need to pick some other particle or photon type).

GCC is used for space based applications so the argument and example
still applies.

Another simple case is an octet wide HW register in which the least
significant bit mirrors the open/closed state of a piece of hardware
like a door.  It could reflect someone breaking a light beam when
walking into a store.  Either way, the compiler knows nothing about
when the value will change.

I am fully in favor of gcc (or any other compiler) optimizing memory
references away when a variable is not volatile.  But if a variable
is declared volatile, references to it MUST be honored by the compiler.

Anyone who has written a device driver in C expects the same behavior.

Hopefully Dr. Dewar is out there listening because he could comment
on the requirements of the Ada LRM for pragma volatile.  My
understanding
is that the requirements for the feature and expected behavior is
very much the same.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: GCC warnings for unused global variables

[Phil Edwards]

On Fri, May 02, 2003 at 09:51:34AM -0700, Bruce Korb wrote:
> Gabriel Dos Reis wrote:
> 
> > [stuff]
> 
> [other stuff]

Isn't there some more productive discussion we could all be having?

A -Wsomething patch has been proposed.  Why not talk about actual concrete
code?  (I'm way behind in the gcc-patches list.)

Tangentially related:

I went 'round the cubicles and made some informal queries here.  The typical
reaction I got was a "wtf?" look.

My users tell me that if -Wall starts bitching at them about their rcsid
strings, which have been there with no problems for years -- in one humorous
case, the code is older than its current maintainer -- they will drop GCC
like a hot potato.

They're fine with putting it in -Wextra/-W, because that typically isn't
used "by default" on a project here, and when they add -W by hand, they can
add appropriate -Wno-* options at the same time.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

Marc Espie <espie@nerim.net> writes:


[...]

| However, I care deeply about current practices, preferably best.
| 
| There are good projects that use -Wall -Werror.

Sure, we do think that -Wall -Werror is good pratice, since we use it
even with our own code source (i.e. GCC itself) and GCC it a good
project (tm). 

I think the key issue this:  -Wall gets changed every time with good or
bad motives.  What that switch should do ought to be precisely defined
or else you'll find yourself conducting the same conversation in the
near future.  This has nothing to do with being language lawyer or not.  

Good sofwtare practice also include using only relatively well
understood tools.  In this case, you can not tell me that the meaning
ot "-Wall" is clear cut.  If you don't set that issue, my bet is that
in a not too distant future you'll reopen the same debate.

-- Gaby

Re: GCC warnings for unused global variables

[Bruce Korb]

Gabriel Dos Reis wrote:

> I think you got my messages wrong.
> 
> What I was saying, as already written in another message, is that
> volatile is not a reliable feature to use to write robust code with
> reproducible or predictable behaviour.

I understood perfectly.  My argument is that even if it is possible
that some other random compiler would choose to eliminate a static volatile,
I seems completely clear that it would not be in the best interests of
simplifying the programming task.  Of all possible choices of what to
do with:

   static volatile char rcsid[] = "xxx";

neither removing it or even warning about it are good choices.

Re: GCC warnings for unused global variables

[Phil Edwards]

On Fri, May 02, 2003 at 09:42:23AM -0700, Joe Buck wrote:
> On Fri, May 02, 2003 at 06:00:30PM +0200, Gabriel Dos Reis wrote:
> > | Because, since the object is volatile, it may affect the program in
> > | ways unknown to the compiler.
> > 
> > This is my favorite peeve against the definition of "volatile".
> > Does an alpha ray fired from Centauri count as a "way unknown to the
> > compiler"?
> 
> This is a much better example than you thought it was.  The answer is
> "yes".  Alpha particles are a major source of soft errors; they can
> spontaneously change the value that is stored in RAM.  Duplicated
> reads can't be eliminated because they might miss the change caused
> by the alpha particle.  A memory test might be written in C with
> a big volatile array, and one of the things it would be looking for
> is effects caused by alpha particles.
> 
> (Of course, an alpha particle can't make it through the atmosphere,
> so you'll need to pick some other particle or photon type).

Or put the platform outside the atmosphere.  These kinds of errors are
a headache for some of my colleagues.  Yes, they happen.  Yes, they use
volatile.

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

Bruce Korb <bkorb@veritas.com> writes:

[...]

| unusual interpretation of the wording.   REMEMBER:  you are trying
| to help programmers accomplish their task.  You are not trying to
| cause grief just because the law of the C language left a hole
| allowing you to whack 'em.

I think you got my messages wrong.  

What I was saying, as already written in another message, is that
volatile is not a reliable feature to use to write robust code with
reproducible or predictable behaviour.

-- Gaby

Re: GCC warnings for unused global variables

[Joe Buck]

On Fri, May 02, 2003 at 06:00:30PM +0200, Gabriel Dos Reis wrote:
> | Because, since the object is volatile, it may affect the program in
> | ways unknown to the compiler.
> 
> This is my favorite peeve against the definition of "volatile".
> Does an alpha ray fired from Centauri count as a "way unknown to the
> compiler"?

This is a much better example than you thought it was.  The answer is
"yes".  Alpha particles are a major source of soft errors; they can
spontaneously change the value that is stored in RAM.  Duplicated
reads can't be eliminated because they might miss the change caused
by the alpha particle.  A memory test might be written in C with
a big volatile array, and one of the things it would be looking for
is effects caused by alpha particles.

(Of course, an alpha particle can't make it through the atmosphere,
so you'll need to pick some other particle or photon type).

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

| On 02-May-2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| > prj@po.cwru.edu (Paul Jarc) writes:
| > 
| > | Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| > | > Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
| > | >| I don't think the committee ever intended to allow implementations
| > | >| to optimize away volatile variables,
| > | >
| > | > Why not?  The C standard clearly says:
| > | >
| > | >        [#3] In the abstract machine, all expressions are  evaluated
| > | >        as  specified  by  the  semantics.  An actual implementation
| > | >        need not evaluate part of an expression  if  it  can  deduce
| > | >        that  its  value is not used and that no needed side effects
| >                                                  ^^^^^^^^^
| > | >        are produced (including any caused by calling a function  or
| > | >        accessing a volatile object).
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

| > | 
| > | Accessing a volatile object includes writing, and writing includes
| > | initializing.  So the initialization cannot be optimized out.
| > 
| > Why? the last part of the paragraph quoted above does specifically
| > permit that optimization where applicable.
| 
| In the case of accesses to volatile objects, it is never applicable.

Even when the standard writes it?  Hugh. 

| I think you are misinterpreting the intent of the parenthetical
| phrase in the quote above.

I'm not misinterpretating.  And that the phrase is in parenthesis does
not diminush its value: It still is normative.

-- Gaby

Re: GCC warnings for unused global variables

[Marc Espie]

On Fri, May 02, 2003 at 02:43:53PM +0200, Gabriel Dos Reis wrote:
> Marc Espie <espie@quatramaran.ens.fr> writes:
> 
> | In article <20030430083713.GU4016@paradies.suse.de> you write:
> | >* Alexander Kabaev (ak03@gte.com) [20030429 22:57]:
> | >
> | >> #ifndef lint
> | >> static const char rcsid[] =
> | >>   "$Id: src/dir/file.c 1.12 1999/08/27 23:45:12 me Exp$";
> | >> #endif /* not lint */
> | >
> | >Why not just use __attribute__((__unused__))?
> | >
> | >Philipp
> | 
> | Because it's a gcc extension, so writing portable code that
> | uses it will require some more machinery, hence more clutter.
> 
> You cannot argue at the same time for portable code and having or not
> having diagnostics, which are by definition, implementation defined.
> At the very point you start elaborating about diagnostics, you
> accept implementation defined semantics and constructs, hence "writing
> portable code" cannot be the decisive argument.  It ought to be
> something else. 

Let's drop the `standardese cap' for a minute.

I don't care at all about how the standard phrases it, how it is
implementation dependent.

However, I care deeply about current practices, preferably best.

There are good projects that use -Wall -Werror.   Each warning you add to
-Wall can cause grief. Some warnings are perfectly justified. For instance,
deprecated constructs should warn.

But some warnings occur naturally in a project. Would you add -Wshadow to
the default set of warnings in -Wall ?   See, this is exactly the same.
For years now, people have embedded identifying strings in code using
static const char *, and now, you are actually breaking this construct.

Yes, this is implementation-dependent. So what ?
You will cause people to drop -Wall -Werror, or to fix a lot of lines of
code that are not even wrong in the first place. See, the point is that
those lines are perfectly correct in the first place.

> FWIW, I'm not convinced by the "it is a regression" argument, that is
> streching the notion of "regression".  If we want to take that route,
> then we should stop fixing bugs in the compilers because fixing bugs
> means removing (or adding) something that was (or weren't) there before.

No, this is a regression. There is a measure called `quality of
implementation'.  In a software engineering setting, warning against a
perfectly natural, usual idiom of the language is a regression in the
quality of the diagnostics.  It will let big projects that use -Wall
-Werror fail (and cause time lost fixing that regression, because you know
quite well that any significant project will have a *BIG* Makefile
infrastructure, part of it legacy, and that finding the correct
Makefile/shell/m4/whatever fragment that generates the actuall -Wall
-Werror can be hell to find). 

Now, if you were to emit that diagnostic in
every case, except for `const char *', I wouldn't care.

And, I'm sorry Gaby, but be assured that whatever rational explanations 
for that warning you can find as language lawyer count as exactly 
ZERO, ZILCH, NADA in some programming circles I know (specifically,
the people who don't have any interest in how the C language is designed,
but just want a compiler that works).  Believe me, I'm talking from
personal experience (and this case is completely plain cut compared to some
of the less valid complaints I've heard).

Specifically, to reiterate, because this is a valid construct. And because
it is very simple to put machinery that WON'T warn in that specific case.
Because it is very simple to dissociate that warning from -Wall. And
because that construct did use to work JUST FINE up until the previous
release.

Re: GCC warnings for unused global variables

[David O'Brien]

On Fri, May 02, 2003 at 12:14:15PM -0400, Daniel Jacobowitz wrote:
> On Fri, May 02, 2003 at 09:00:48AM -0700, David O'Brien wrote:
> > On Wed, Apr 30, 2003 at 05:21:07PM -0700, Richard Henderson wrote:
> > > On Wed, Apr 30, 2003 at 07:47:30PM -0400, Alexander Kabaev wrote:
> > > > Anyway, my question was about boatload of
> > > > third-party software, which normally should not be modified locally.
> > > > const static rcsid's are very common.
> > > 
> > > Then you'll have to ignore the warning.
> > 
> > Ah yes, the position of the GNU toolchain developers whose code isn't
> > even near warns clean...
> > 
> > As someone with a source base that is (well was until GCC 3.3) warns
> > clean I can tell you adding things willy nilly to -Wall is a problem.  If
> > GCC and Binutils were -Wall -Werror clean, maybe the GCC developers
> > thinking this thread isn't an issue would have a different opinion.
> 
> Have you noticed perhaps that the majority of GCC HEAD _is_ -Wall
> -Werror clean?

I will when it is released.  Nothing released so far has been.
 
-- 
-- David  (obrien@FreeBSD.org)

Re: GCC warnings for unused global variables

[Joe Buck]

> I'm trying to say that "volatile" is not a *reliable* feature to use
> to write robust code with reproducible behaviour.
> 
> | static volatile int foo;
> | 
> | void test (void)
> | {
> | 	foo = 1;
> | 	foo = 1;
> | }
> | 
> | Does your statement mean that you believe the compiler is allowed to
> | optimize this into:
> | void test (void)
> | {
> | 	foo = 1;
> | }
> | ?
 
On Fri, May 02, 2003 at 05:18:02PM +0200, Gabriel Dos Reis wrote:
> If it can determine that does nto change the behaviour of whole
> program, yes, it is permitted to do so.

Gaby, surely you know that the reason that volatile is in the language
is to allow C to be used to write code that interacts with hardware,
or with other invisible software that the compiler can't see.  If you
can find language in the standard that suggests that one of the writes
to foo can be legally eliminated, it's defect report time.
 
> | The answer clearly *must* be NO, otherwise you've just defined
> | volatile into total uselessness.
> 
> I've not defined anything, it has been all there.

See above.

Re: GCC warnings for unused global variables

[Paul Jarc]

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>| Because, since the object is volatile, it may affect the program in
>| ways unknown to the compiler.

To expand: volatile is a way for the programmer to express "I am
intentionally doing something with this variable that you cannot
detect".  E.g., the linker may be told to do something special with
it.  I may not be able to set up that external interaction portably,
but I can use volatile to portably express that the interaction is
going to be set up.

> This is my favorite peeve against the definition of "volatile".
> Does an alpha ray fired from Centauri count as a "way unknown to the
> compiler"?  From the C definition, there is nothing that preclude that.
> Then, the compiler can pretend that ways unknown to it affected the
> behaviour which is why you're seeing what you're seeing.

I'm not sure what you mean.

>| If volatile is used, then the compiler cannot know whether accesses
>| and side effects are needed.  (This is exactly what is expressed by
>| volatile.)  Do you agree or disagree?
>
> Change "cannot" to "may not" and I agree.

In what sort of case would the compiler be able to know?  A concrete
example would be helpful.

Ignoring the standard's precise wording for the moment, it seems clear
that your opinion conflicts with the standard's intent.  Do you agree
or disagree?

Back to the pragmatic argument: volatile would be a clean way to
silence this warning and preserve the id variable, assuming gcc
behaves that way.  So there is a concrete motivation for that
behavior, even though it may not be useful to everyone.  (E.g., some
of us don't use id variables.)  What motivation is there for the
optimization?  Who would find it useful?


paul

Re: GCC warnings for unused global variables

[Bruce Korb]

It seems to me that an important goal of software tools is to facilitate
writing software.  Writing software is hard enough without extra impediments.
Is this warning accomplishing that goal?  Well, what are the costs and benefits?

Cost: hundreds of thousands (millions?) of existing source modules will either
      have to change, ignore this warning, not be compilable by current GCC,
      or loose the benefit of -Wall.

Benefit: sloppily patched programs will be marked as having squandered tens,
      hundreds or even thousands of bytes of memory that apparently might
      get optimized away anyway (assuming it isn't marked 'volatile').

I really think that pretty much clarifies what is more important.
Nevertheless, it is still possible to set -Wall and then suppress
specific warnings, right?  So why such a big deal?


WRT volatile:

> | Accessing a volatile object includes writing, and writing includes
> | initializing.  So the initialization cannot be optimized out.
> 
> Why? the last part of the paragraph quoted above does specifically
> permit that optimization where applicable.

Here's the main deal:  you'll violate a reasonable interpretation
that will make life hard for programmers just because of a, well,
unusual interpretation of the wording.   REMEMBER:  you are trying
to help programmers accomplish their task.  You are not trying to
cause grief just because the law of the C language left a hole
allowing you to whack 'em.

Re: GCC warnings for unused global variables

[Daniel Jacobowitz]

On Fri, May 02, 2003 at 09:00:48AM -0700, David O'Brien wrote:
> On Wed, Apr 30, 2003 at 05:21:07PM -0700, Richard Henderson wrote:
> > On Wed, Apr 30, 2003 at 07:47:30PM -0400, Alexander Kabaev wrote:
> > > Anyway, my question was about boatload of
> > > third-party software, which normally should not be modified locally.
> > > const static rcsid's are very common.
> > 
> > Then you'll have to ignore the warning.
> 
> Ah yes, the position of the GNU toolchain developers whose code isn't
> even near warns clean...
> 
> As someone with a source base that is (well was until GCC 3.3) warns
> clean I can tell you adding things willy nilly to -Wall is a problem.  If
> GCC and Binutils were -Wall -Werror clean, maybe the GCC developers
> thinking this thread isn't an issue would have a different opinion.

Have you noticed perhaps that the majority of GCC HEAD _is_ -Wall
-Werror clean?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GCC warnings for unused global variables

[Fergus Henderson]

On 02-May-2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
> 
> | Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> | > Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
> | >| I don't think the committee ever intended to allow implementations
> | >| to optimize away volatile variables,
> | >
> | > Why not?  The C standard clearly says:
> | >
> | >        [#3] In the abstract machine, all expressions are  evaluated
> | >        as  specified  by  the  semantics.  An actual implementation
> | >        need not evaluate part of an expression  if  it  can  deduce
> | >        that  its  value is not used and that no needed side effects
>                                                  ^^^^^^^^^
> | >        are produced (including any caused by calling a function  or
> | >        accessing a volatile object).
> | 
> | Accessing a volatile object includes writing, and writing includes
> | initializing.  So the initialization cannot be optimized out.
> 
> Why? the last part of the paragraph quoted above does specifically
> permit that optimization where applicable.

In the case of accesses to volatile objects, it is never applicable.

I think you are misinterpreting the intent of the parenthetical
phrase in the quote above.  I think the mention of volatile there was
added specifically to remind the reader that the optimization is not
permitted if the expression accesses a volatile object.  You seem to be
(mis)interpreting it as allowing the optimization provided that the side
effect was not "needed", while ignoring the fact that the compiler can
never determine that such a side effect is not needed.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: GCC warnings for unused global variables

[David O'Brien]

On Wed, Apr 30, 2003 at 05:21:07PM -0700, Richard Henderson wrote:
> On Wed, Apr 30, 2003 at 07:47:30PM -0400, Alexander Kabaev wrote:
> > Anyway, my question was about boatload of
> > third-party software, which normally should not be modified locally.
> > const static rcsid's are very common.
> 
> Then you'll have to ignore the warning.

Ah yes, the position of the GNU toolchain developers whose code isn't
even near warns clean...

As someone with a source base that is (well was until GCC 3.3) warns
clean I can tell you adding things willy nilly to -Wall is a problem.  If
GCC and Binutils were -Wall -Werror clean, maybe the GCC developers
thinking this thread isn't an issue would have a different opinion.
 
-- 
-- David  (obrien@FreeBSD.org)

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

prj@po.cwru.edu (Paul Jarc) writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| > prj@po.cwru.edu (Paul Jarc) writes:
| >| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| >|> Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
| >|>        [#3] In the abstract machine, all expressions are  evaluated
| >|>        as  specified  by  the  semantics.  An actual implementation
| >|>        need not evaluate part of an expression  if  it  can  deduce
| >|>        that  its  value is not used and that no needed side effects
| >                                                ^^^^^^^^^
| >|>        are produced (including any caused by calling a function  or
| >|>        accessing a volatile object).
| >|
| >| Accessing a volatile object includes writing, and writing includes
| >| initializing.  So the initialization cannot be optimized out.
| >
| > Why?
| 
| Because, since the object is volatile, it may affect the program in
| ways unknown to the compiler.

This is my favorite peeve against the definition of "volatile".
Does an alpha ray fired from Centauri count as a "way unknown to the
compiler"?  From the C definition, there is nothing that preclude that.  
Then, the compiler can pretend that ways unknown to it affected the
behaviour which is why you're seeing what you're seeing.   

No, I'm not proposing that as an imlementation for GCC.  However, it
is quite a valid interpretation, which shows why the meaning of
"volatile" is fuzzy. 

| > When we request the compiler to optimize a program we are requesting
| > it to transform the program into another one with equivalent
| > semantics, according to some "optmization criteria" (space or speed or
| > whatever).  The compiler has no notion of useful.
| 
| The compiler writers do.

certainly, but the compiler writers' notion of "useful" does not
always match that of all users -- which, in a sense, is why this
thread initially started.

| >| If the programmer marked the variable as volatile, it seems
| >| extremely likely that the variable will be used somehow, and removing
| >| it would cause some sort of breakage.
| >
| > Well, if the side effect is needed then the compiler won't remove
| > it.
| 
| I agree with that precise wording, but note that this is different
| from "if the compiler knows that the side effect is needed, then the
| compiler win't remove it".
| 
| If volatile is used, then the compiler cannot know whether accesses
| and side effects are needed.  (This is exactly what is expressed by
| volatile.)  Do you agree or disagree?

Change "cannot" to "may not" and I agree.

| If the compiler does not know whether accesses and side effects are
| needed, then it must not optimize then away.  Do you agree or
| disagree?

I agree.

-- Gaby

Re: GCC warnings for unused global variables

[David O'Brien]

On Thu, May 01, 2003 at 11:42:57AM -0700, Richard Henderson wrote:
> On Thu, May 01, 2003 at 10:54:44AM -0700, Kean Johnston wrote:
> > I am frankly surprised you don't see that and are fighting
> > so hard for this to stay in -Wall.
> 
> Perhaps a personal bias.  I've always *hated* rcsid tags.

I hate to say it, but *HATE* that GCC source file have no way of knowing
which rev they are.  It has been a problem more than once.
 
-- 
-- David  (obrien@FreeBSD.org)

RE: GCC warnings for unused global variables

[Kean Johnston]

> Well, if the side effect is needed then the compiler won't remove it.
But how can the compiler possibly determine that? The compiler is just
phase 1 of a multi-phase process to create a functioning executable.
I don't know if such code exists, but it wouldn't surprise me terribly
if some smart bloke somewhere has organised, through link editor
trickery
or other object-file manipulation, that code like:

static volatile int foo;

void doit (void)
{
  foo = 1;
  foo = 2;
}

actually orchestrates that because the symbol is marked as volatile,
whether static or not, that it is mapped to some I/O port or special
memory location or any number of possible things, and that the mere act
of assigning a value to it writes data to the port. I belive that THAT
kind of trickery was the intent behind volatile. I don't have the 
standard in front of me but I do have access to one of the committee
members and he confirms that that was indeed the intent, that volatile
should indicate to the compiler an entity that has side effects beyond
the ability for *ANY* compiler to detect.

It is critical to remember when discussing these things that gcc isnt
the final arbitrator of what constitutes valid code. There are other
standards, beyond simple language semantic standards, that it has to
interact with.

Kean

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

Paul Koning <pkoning@equallogic.com> writes:

| >>>>> "Gabriel" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
|  Gabriel> Paul Koning <pkoning@equallogic.com> writes:
|  >> I can't tell if you're trying to say something that goes directly
|  >> against the intent of volatile or not, so let's talk about an
|  >> example:
| 
|  Gabriel> I'm trying to say that "volatile" is not a *reliable*
|  Gabriel> feature to use to write robust code with reproducible
|  Gabriel> behaviour.
| 
| I don't understand.
| 
| "volatile" exists in order to be able to write device drivers and
| multiprocessor applications that are robust and have reproducible
| behavior.  That's how it has always been used; that's why it exists.
| 
| Now you seem to be saying that such code is just lucky when it works.
| Why?

I gave the reasons in previous messages.  In the past, I also gave the
reasons on comp.std.c.

The key point boils down to the fact that the semantics of "volatile"
is not well-defined.  And I think I've already demonstrated that point.

[...]

| On the other hand, if you mean "it doesn't currently but at some point
| in the future gcc will start doing this because it thinks it can make

Yes, that is what I meant.

| that determination" then at that point every OS and SMP application
| will break.

Not every.  Only those that relied on (mis)fortune.

And the following quote is from someone known to have spent a certain
amount of his time on writing OSes:

   In short, "volatile" is a bad feature. It's not well-defined, and
   whatever the compiler does you can't really complain. In my opinion,
   any code that depends on volatile is almost certainly buggy as the
   standard stands now (the only case I really personally approve of is
   a "clock tick counter" kind of use)

               Linus

-- Gaby

Re: GCC warnings for unused global variables

[Paul Jarc]

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>|> Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
>|>        [#3] In the abstract machine, all expressions are  evaluated
>|>        as  specified  by  the  semantics.  An actual implementation
>|>        need not evaluate part of an expression  if  it  can  deduce
>|>        that  its  value is not used and that no needed side effects
>                                                ^^^^^^^^^
>|>        are produced (including any caused by calling a function  or
>|>        accessing a volatile object).
>|
>| Accessing a volatile object includes writing, and writing includes
>| initializing.  So the initialization cannot be optimized out.
>
> Why?

Because, since the object is volatile, it may affect the program in
ways unknown to the compiler.

> When we request the compiler to optimize a program we are requesting
> it to transform the program into another one with equivalent
> semantics, according to some "optmization criteria" (space or speed or
> whatever).  The compiler has no notion of useful.

The compiler writers do.

>| If the programmer marked the variable as volatile, it seems
>| extremely likely that the variable will be used somehow, and removing
>| it would cause some sort of breakage.
>
> Well, if the side effect is needed then the compiler won't remove
> it.

I agree with that precise wording, but note that this is different
from "if the compiler knows that the side effect is needed, then the
compiler win't remove it".

If volatile is used, then the compiler cannot know whether accesses
and side effects are needed.  (This is exactly what is expressed by
volatile.)  Do you agree or disagree?

If the compiler does not know whether accesses and side effects are
needed, then it must not optimize then away.  Do you agree or
disagree?


paul

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

prj@po.cwru.edu (Paul Jarc) writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| > Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
| >| I don't think the committee ever intended to allow implementations
| >| to optimize away volatile variables,
| >
| > Why not?  The C standard clearly says:
| >
| >        [#3] In the abstract machine, all expressions are  evaluated
| >        as  specified  by  the  semantics.  An actual implementation
| >        need not evaluate part of an expression  if  it  can  deduce
| >        that  its  value is not used and that no needed side effects
                                                 ^^^^^^^^^
| >        are produced (including any caused by calling a function  or
| >        accessing a volatile object).
| 
| Accessing a volatile object includes writing, and writing includes
| initializing.  So the initialization cannot be optimized out.

Why? the last part of the paragraph quoted above does specifically
permit that optimization where applicable.

| Ignoring for the moment the question of what's allowed, what useful
| purpose would be served by optimizing away a static volatile variable,
| anyway? 

Now, we're leaving the C definition land to enter the land of
second-guessing what may or may not be useful.  That land is far less
"friendly" than "C definition" land.

When we request the compiler to optimize a program we are requesting
it to transform the program into another one with equivalent
semantics, according to some "optmization criteria" (space or speed or
whatever).  The compiler has no notion of useful.  So I think the
formulation of the question is not appropriate.

| If the programmer marked the variable as volatile, it seems
| extremely likely that the variable will be used somehow, and removing
| it would cause some sort of breakage.

Well, if the side effect is needed then the compiler won't remove it.
If it is not needed then removing it cannot not possibly make any
difference, any breakage.  Or else, there was an unfounded expectation. 

-- Gaby

Re: GCC warnings for unused global variables

[Paul Koning]

>>>>> "Gabriel" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

 Gabriel> Paul Koning <pkoning@equallogic.com> writes:
 >> I can't tell if you're trying to say something that goes directly
 >> against the intent of volatile or not, so let's talk about an
 >> example:

 Gabriel> I'm trying to say that "volatile" is not a *reliable*
 Gabriel> feature to use to write robust code with reproducible
 Gabriel> behaviour.

I don't understand.

"volatile" exists in order to be able to write device drivers and
multiprocessor applications that are robust and have reproducible
behavior.  That's how it has always been used; that's why it exists.

Now you seem to be saying that such code is just lucky when it works.
Why?

 >> static volatile int foo;
 >> 
 >> void test (void) { foo = 1; foo = 1; }
 >> 
 >> Does your statement mean that you believe the compiler is allowed
 >> to optimize this into: void test (void) { foo = 1; } ?

 Gabriel> If it can determine that does nto change the behaviour of
 Gabriel> whole program, yes, it is permitted to do so.

That doesn't really help.  Do you think that the compiler IS able to
determine this and therefore make that change?

Fergus and others pointed out that the compiler cannot possibly make
that determination because by definition volatile variables are
allowed to have side effects that the compiler is unaware of.  

So if what you mean is "yes, if the compiler could tell, it would be
allowed to, but the compiler can by definition never tell, so it
actually is not allowed to" then we are in agreement.

On the other hand, if you mean "it doesn't currently but at some point
in the future gcc will start doing this because it thinks it can make
that determination" then at that point every OS and SMP application
will break.

     paul

Re: GCC warnings for unused global variables

[Paul Jarc]

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> Paul Koning <pkoning@equallogic.com> writes:
> | static volatile int foo;
> |
> | void test (void)
> | {
> | 	foo = 1;
> | 	foo = 1;
> | }
> |
> | Does your statement mean that you believe the compiler is allowed to
> | optimize this into:
> | void test (void)
> | {
> | 	foo = 1;
> | }
> | ?
>
> If it can determine that does nto change the behaviour of whole
> program, yes, it is permitted to do so.

Right.  But the whole point of volatile is that it expresses to the
compiler "something is going on here that you don't know about".
Therefore, the compiler can never determine that this optimization
would not change the behavior of the program.


paul

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

Paul Koning <pkoning@equallogic.com> writes:

| >>>>> "Gabriel" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
|  Gabriel> Fergus Henderson <fjh@cs.mu.OZ.AU> writes: [...]
| 
|  >> > C++98 1.9/1:
|  >> > 
|  >> > The semantic descriptions in this International Standard define
|  >> a > parameterized nondeterministic abstract machine. This
|  >> International > Standard places no requirement on the structure of
|  >> conforming > implementa-tions. In particular, they need not copy
|  >> or emulate the > structure of the abstract machine. Rather,
|  >> conform-ing > implementations are required to emulate (only) the
|  >> observable > behavior of the abstract machine as explained
|  >> below.5)
|  >> >
|  >> > There is nothing there that prevents the compiler to apply the
|  >> "as-if" > rule to to volatile objects.  The only thinr that is
|  >> required is to > emulate the observable behavuour".  The
|  >> implementation is free to > implement whatever it likes as far as
|  >> the observable behaviour is > preserved.
|  >> 
|  >> But reads and writes to volatile variables are defined to be *part
|  >> of* "the observable behaviour" (C++98 1.9 paragraph 6).  So they
|  >> can't be optimized away under the as-if rule.
| 
|  Gabriel> They can be optimized out if the program cannot tell the
|  Gabriel> difference.
| 
| I can't tell if you're trying to say something that goes directly
| against the intent of volatile or not, so let's talk about an example:

I'm trying to say that "volatile" is not a *reliable* feature to use
to write robust code with reproducible behaviour.

| static volatile int foo;
| 
| void test (void)
| {
| 	foo = 1;
| 	foo = 1;
| }
| 
| Does your statement mean that you believe the compiler is allowed to
| optimize this into:
| void test (void)
| {
| 	foo = 1;
| }
| ?

If it can determine that does nto change the behaviour of whole
program, yes, it is permitted to do so.

| The answer clearly *must* be NO, otherwise you've just defined
| volatile into total uselessness.

I've not defined anything, it has been all there.

-- Gaby

Re: GCC warnings for unused global variables

[Paul Koning]

>>>>> "Gabriel" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

 Gabriel> Fergus Henderson <fjh@cs.mu.OZ.AU> writes: [...]

 >> > C++98 1.9/1:
 >> > 
 >> > The semantic descriptions in this International Standard define
 >> a > parameterized nondeterministic abstract machine. This
 >> International > Standard places no requirement on the structure of
 >> conforming > implementa-tions. In particular, they need not copy
 >> or emulate the > structure of the abstract machine. Rather,
 >> conform-ing > implementations are required to emulate (only) the
 >> observable > behavior of the abstract machine as explained
 >> below.5)
 >> >
 >> > There is nothing there that prevents the compiler to apply the
 >> "as-if" > rule to to volatile objects.  The only thinr that is
 >> required is to > emulate the observable behavuour".  The
 >> implementation is free to > implement whatever it likes as far as
 >> the observable behaviour is > preserved.
 >> 
 >> But reads and writes to volatile variables are defined to be *part
 >> of* "the observable behaviour" (C++98 1.9 paragraph 6).  So they
 >> can't be optimized away under the as-if rule.

 Gabriel> They can be optimized out if the program cannot tell the
 Gabriel> difference.

I can't tell if you're trying to say something that goes directly
against the intent of volatile or not, so let's talk about an example:

static volatile int foo;

void test (void)
{
	foo = 1;
	foo = 1;
}

Does your statement mean that you believe the compiler is allowed to
optimize this into:
void test (void)
{
	foo = 1;
}
?

The answer clearly *must* be NO, otherwise you've just defined
volatile into total uselessness.

	 paul

Re: GCC warnings for unused global variables

[Paul Jarc]

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
>| I don't think the committee ever intended to allow implementations
>| to optimize away volatile variables,
>
> Why not?  The C standard clearly says:
>
>        [#3] In the abstract machine, all expressions are  evaluated
>        as  specified  by  the  semantics.  An actual implementation
>        need not evaluate part of an expression  if  it  can  deduce
>        that  its  value is not used and that no needed side effects
>        are produced (including any caused by calling a function  or
>        accessing a volatile object).

Accessing a volatile object includes writing, and writing includes
initializing.  So the initialization cannot be optimized out.

Ignoring for the moment the question of what's allowed, what useful
purpose would be served by optimizing away a static volatile variable,
anyway?  If the programmer marked the variable as volatile, it seems
extremely likely that the variable will be used somehow, and removing
it would cause some sort of breakage.  So it seems like a bad idea to
do that, regardless of whether the standard permits it.  Certainly it
can happen that the variable really is entirely unused despite being
volatile, but gcc can't know when that is the case.


paul

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

[...]

| > C++98 1.9/1:
| > 
| >   The semantic descriptions in this International Standard define a
| >   parameterized nondeterministic abstract machine. This International
| >   Standard places no requirement on the structure of conforming
| >   implementa-tions. In particular, they need not copy or emulate the
| >   structure of the abstract machine. Rather, conform-ing
| >   implementations are required to emulate (only) the observable
| >   behavior of the abstract machine as explained below.5)
| >
| > There is nothing there that prevents the compiler to apply the "as-if"
| > rule to to volatile objects.  The only thinr that is required is to
| > emulate the observable behavuour".  The implementation is free to
| > implement whatever it likes  as far as the observable behaviour is
| > preserved.
| 
| But reads and writes to volatile variables are defined to be *part of*
| "the observable behaviour" (C++98 1.9 paragraph 6).  So they can't be
| optimized away under the as-if rule.

They can be optimized out if the program cannot tell the difference.

[...]

| ignored the intent of volatile.  I don't think the committee ever
| intended to allow implementations to optimize away volatile variables,

Why not?  The C standard clearly says:

       [#3] In the abstract machine, all expressions are  evaluated
       as  specified  by  the  semantics.  An actual implementation
       need not evaluate part of an expression  if  it  can  deduce
       that  its  value is not used and that no needed side effects
       are produced (including any caused by calling a function  or
       accessing a volatile object).

That is clear.

| and so the lack of clear wording in the current standard explicitly
| prohibiting this may be just oversight.

or not.  See above.

-- Gaby

Re: GCC warnings for unused global variables

[Fergus Henderson]

On 02-May-2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
> | The "as-if" rule (C99 5.1.2.3, C++98 1.9) only applies to non-volatile
> | objects.
> 
> I disagree.  See below.
> 
> | The part of C and C++ standards which defines the "as-if"
> | rule specifically requires implementations to not optimize away accesses
> | to volatile variables (C99 5.1.2.3, C++98 1.9 paragraphs 1 and 7), and
> 
> C++98 1.9/1:
> 
>   The semantic descriptions in this International Standard define a
>   parameterized nondeterministic abstract machine. This International
>   Standard places no requirement on the structure of conforming
>   implementa-tions. In particular, they need not copy or emulate the
>   structure of the abstract machine. Rather, conform-ing
>   implementations are required to emulate (only) the observable
>   behavior of the abstract machine as explained below.5)
>
> There is nothing there that prevents the compiler to apply the "as-if"
> rule to to volatile objects.  The only thinr that is required is to
> emulate the observable behavuour".  The implementation is free to
> implement whatever it likes  as far as the observable behaviour is
> preserved.

But reads and writes to volatile variables are defined to be *part of*
"the observable behaviour" (C++98 1.9 paragraph 6).  So they can't be
optimized away under the as-if rule.

Initialization of a volatile is a write to a volatile variable, so it
is part of the "observable behaviour", and all variables with static
storage get initialized (even if it is just zero-initialization).
Hence the compiler is not allowed to optimize away any volatile variable
with static storage duration.

If you want to take a very weasely interpretation, then you could say that
although _reads and writes_ to volatile variables are part of the observable
behaviour (and hence cannot be optimize away by the "as-if" rule),
the _presence_ of volatile variables is not.  However, this argument would
only work for volatile variables which are not initialized, e.g.
volatiles with automatic storage duration which are declared with
no initializer and which are never read or written.  Furthermore, I
think that this would be an overly legalistic interpretation which
ignored the intent of volatile.  I don't think the committee ever
intended to allow implementations to optimize away volatile variables,
and so the lack of clear wording in the current standard explicitly
prohibiting this may be just oversight.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

RE: GCC warnings for unused global variables

[Kean Johnston]

> FWIW, I'm not convinced by the "it is a regression" argument, that is
> streching the notion of "regression".  If we want to take that route,
> then we should stop fixing bugs in the compilers because fixing bugs
> means removing (or adding) something that was (or weren't) 
> there before.
Nah I think you're misinterpreting why folks think this is a regression.
Consider this. You have a tree that today compiles cleanly with -Wall
-Werror. You upgrade your gcc and now just about *every single file*
in the tree causes an error, with no way of turning off the warning
that's causing the new breakage (without also turning off other stuff
that's useful).

This is not a regression because the option is wrong or whats its
telling
you about is handled incorrectly or anything like that. It is a
regression
because of the 30 years of history that preceed the warning, using an
extremely common practice. If a new warning message tickles, say, 100
warnings across a tree, of even 1000, if they're particularly valuable
warning messages, then you need to clean your code up. But this
particular
warning can (and will) affect several very very large trees and just
about
every single .c file in them, and the warning doesn't even buy you much
at all. So you have a static string, or a static int or two that are
no longer used because the hacker that removed the code that uses them
didn't clean up propperly. Big deal. Leaving those things there doesn't
break any code and I seriously doubt it even bloats code by more than
a few bytes here and there (unless you have huge unused structures). So
from an actual diagnostic point of view, this is almost a pedantic
option.
If you are on a bug hunting expedition and want to clean your tree
squeeky clean, you should have the option of asking for this. I just
don't think it should be on by default.

Kean

Re: GCC warnings for unused global variables

[Paul Koning]

>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:

 Richard> On Thu, May 01, 2003 at 08:47:03PM -0700, Geoff Keating
 Richard> wrote:
 >> The C standard says:
 >> 
 >> > An object that has volatile-qualified type may be modified in
 >> ways > unknown to the implementation or have other unknown side
 >> effects.
 >> 
 >> That sounds exactly like a description of the case here: the
 >> 'unknown side effect' is that what(1) reads the string.

 Richard> We don't care about side effects to the object if we never
 Richard> access it.  You're reading that *way* too far afield.

 >> For instance, at program startup (in this case) the abstract
 >> machine says the string contains a particular value, and how can
 >> it do that if it is optimized away?

 Richard> Ok, I'll play your game.  By the as-if rule, it *does* have
 Richard> that value.  Any time the program cares to check that'll be
 Richard> true.

But the purpose of "volatile" is to make it true not just for the
program, but also for things outside the program.

	 paul

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

| On 01-May-2003, Richard Henderson <rth@redhat.com> wrote:
| > On Thu, May 01, 2003 at 08:47:03PM -0700, Geoff Keating wrote:
| > > For instance, at program startup (in this case) the abstract machine
| > > says the string contains a particular value, and how can it do that if
| > > it is optimized away?
| > 
| > Ok, I'll play your game.  By the as-if rule, it *does*
| > have that value.  Any time the program cares to check
| > that'll be true.
| 
| The "as-if" rule (C99 5.1.2.3, C++98 1.9) only applies to non-volatile
| objects.

I disagree.  See below.

| The part of C and C++ standards which defines the "as-if"
| rule specifically requires implementations to not optimize away accesses
| to volatile variables (C99 5.1.2.3, C++98 1.9 paragraphs 1 and 7), and

C++98 1.9/1:

  The semantic descriptions in this International Standard define a
  parameterized nondeterministic abstract machine. This International
  Standard places no requirement on the structure of conforming
  implementa-tions. In particular, they need not copy or emulate the
  structure of the abstract machine. Rather, conform-ing
  implementations are required to emulate (only) the observable
  behavior of the abstract machine as explained below.5)

There is nothing there that prevents the compiler to apply the "as-if"
rule to to volatile objects.  The only thinr that is required is to
emulate the observable behavuour".  The implementation is free to
implement whatever it likes  as far as the observable behaviour is
preserved.  The note 5) specifically says:

  This provision is sometimes called the  as-if  rule, because an
  *implementation is free to disregard any requirement of this
  International Standard as long as the result is as if the
  requirement had been obeyed, as far as can be determined from the
  observable behavior of the program*. For instance, an actual
  implementation need not evaluate part of an expression if it can
  deduce that its value is not used and that no side effects affecting
  the observable behavior of the program are produced.
 

-- Gaby

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.com> writes:

| On Thu, May 01, 2003 at 07:05:08AM -0400, Robert Dewar wrote:
| > > And warning on perfectly legal, innocuous constructs makes
| > > absolutely no sense to me.
| > 
| > Well all warnings apply to legal constructs, or they would be errors!
| 
| > As to innocuous, the reason why something is NOT an error is that you
| > can't tell whether it is innocous or not, so warnings almost always
| > generate some false positives (or they would not be warnings!)
| 
| Correct, but in this case, we've broken a 20-year-old convention.
| "Broken", that is, because we've carefully designed -Wall so that
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
| we can expect that high-quality software development processes can
| produce their code with -Wall -Werror.

I disagree with that statement, because right now we don't have
clearly defined and accepted semantics for "-Wall", which partly
explains why we keep discussing what -Wall should do or not do.

-- Gaby

Re: GCC warnings for unused global variables

[Gabriel Dos Reis]

Marc Espie <espie@quatramaran.ens.fr> writes:

| In article <20030430083713.GU4016@paradies.suse.de> you write:
| >* Alexander Kabaev (ak03@gte.com) [20030429 22:57]:
| >
| >> #ifndef lint
| >> static const char rcsid[] =
| >>   "$Id: src/dir/file.c 1.12 1999/08/27 23:45:12 me Exp$";
| >> #endif /* not lint */
| >
| >Why not just use __attribute__((__unused__))?
| >
| >Philipp
| 
| Because it's a gcc extension, so writing portable code that
| uses it will require some more machinery, hence more clutter.

You cannot argue at the same time for portable code and having or not
having diagnostics, which are by definition, implementation defined.
At the very point you start elaborating about diagnostics, you
accept implementation defined semantics and constructs, hence "writing
portable code" cannot be the decisive argument.  It ought to be
something else. 

FWIW, I'm not convinced by the "it is a regression" argument, that is
streching the notion of "regression".  If we want to take that route,
then we should stop fixing bugs in the compilers because fixing bugs
means removing (or adding) something that was (or weren't) there before.

-- Gaby

Re: GCC warnings for unused global variables

[Fergus Henderson]

On 01-May-2003, Richard Henderson <rth@redhat.com> wrote:
> On Thu, May 01, 2003 at 08:47:03PM -0700, Geoff Keating wrote:
> > For instance, at program startup (in this case) the abstract machine
> > says the string contains a particular value, and how can it do that if
> > it is optimized away?
> 
> Ok, I'll play your game.  By the as-if rule, it *does*
> have that value.  Any time the program cares to check
> that'll be true.

The "as-if" rule (C99 5.1.2.3, C++98 1.9) only applies to non-volatile
objects.  The part of C and C++ standards which defines the "as-if"
rule specifically requires implementations to not optimize away accesses
to volatile variables (C99 5.1.2.3, C++98 1.9 paragraphs 1 and 7), and
to ensure that "At sequence points, volatile objects are stable in the
sense that previous evaluations/accesses are complete..." (C99 5.1.2.3
paragraph 5, C++98 1.9 paragraph 11).

In general the wording of the C and C++ standards about the semantics of
volatile is pretty vague (e.g. what constitutes "access" to a volatile
object is implementation-defined) and so there may perhaps be room for a
weasely interpretation which allows what you seem to want.  But performing
such an optimization would be a clear violation of the intent and spirit
of these standards with respect to volatile.  The purpose of volatile is
to precisely to suppress optimizations like these, and any implementation
which optimizes away volatile variables is at best greatly lacking in
quality-of-implementation, if not in outright violation of the standard.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: GCC warnings for unused global variables

[Geoff Keating]

> Date: Thu, 1 May 2003 21:11:32 -0700
> From: Richard Henderson <rth@redhat.com>

> On Thu, May 01, 2003 at 08:47:03PM -0700, Geoff Keating wrote:
> > The C standard says:
> > 
> > > An object that has volatile-qualified type may be modified in ways
> > > unknown to the implementation or have other unknown side effects.
> > 
> > That sounds exactly like a description of the case here: the 'unknown
> > side effect' is that what(1) reads the string.
> 
> We don't care about side effects to the object if we never
> access it.  You're reading that *way* too far afield.

The sentence refers to side-effects of the object, not of
modifications to the object.

... language lawyering, 5 cents :-)

> > For instance, at program startup (in this case) the abstract machine
> > says the string contains a particular value, and how can it do that if
> > it is optimized away?
> 
> Ok, I'll play your game.  By the as-if rule, it *does*
> have that value.  Any time the program cares to check
> that'll be true.

That's true of all variables, 'volatile' or not.  They have to have
the correct value every time the program checks.  The difference that
volatile makes is that (in some loosely-defined way) they have to have
the correct value even when the program's not looking, because
something else might be.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: GCC warnings for unused global variables

[Richard Henderson]

On Fri, May 02, 2003 at 02:21:30PM +1000, Gareth Pearce wrote:
> inline assembly?

Bears no relation to ISO C rules, which are the ones
being discussed.


r~

Re: GCC warnings for unused global variables

[Gareth Pearce]

> Ok, I'll play your game.  By the as-if rule, it *does*
> have that value.  Any time the program cares to check
> that'll be true.

inline assembly?

Gareth

RE: GCC warnings for unused global variables

[Kean Johnston]

> > For instance, at program startup (in this case) the abstract machine
> > says the string contains a particular value, and how can it 
> do that if
> > it is optimized away?
> 
> Ok, I'll play your game.  By the as-if rule, it *does*
> have that value.  Any time the program cares to check
> that'll be true.

Heh :) I must admit that was quite funny. Not sure if the humour was
intended (I suspect it was) but funny nonetheless.

Kean

Re: GCC warnings for unused global variables

[Richard Henderson]

On Thu, May 01, 2003 at 08:47:03PM -0700, Geoff Keating wrote:
> The C standard says:
> 
> > An object that has volatile-qualified type may be modified in ways
> > unknown to the implementation or have other unknown side effects.
> 
> That sounds exactly like a description of the case here: the 'unknown
> side effect' is that what(1) reads the string.

We don't care about side effects to the object if we never
access it.  You're reading that *way* too far afield.

> For instance, at program startup (in this case) the abstract machine
> says the string contains a particular value, and how can it do that if
> it is optimized away?

Ok, I'll play your game.  By the as-if rule, it *does*
have that value.  Any time the program cares to check
that'll be true.


r~

Re: GCC warnings for unused global variables

[Geoff Keating]

> Date: Thu, 1 May 2003 19:43:42 -0700
> From: Richard Henderson <rth@redhat.com>

> On Thu, May 01, 2003 at 11:05:18AM -0700, Geoff Keating wrote:
> > This is still the case; it's easy to suppress the warning by adding an
> > appropriate attribute, or by use of 'volatile' (at least, I hope
> > 'volatile' works, if not it can be fixed).
> 
> Why in the world would "volatile" affect this in any way?

The C standard says:

> An object that has volatile-qualified type may be modified in ways
> unknown to the implementation or have other unknown side effects.

That sounds exactly like a description of the case here: the 'unknown
side effect' is that what(1) reads the string.

Then later it says:

> at every sequence point the value last stored in the
> object shall agree with that prescribed by the abstract machine,

For instance, at program startup (in this case) the abstract machine
says the string contains a particular value, and how can it do that if
it is optimized away?

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: GCC warnings for unused global variables

[Richard Henderson]

On Thu, May 01, 2003 at 11:05:18AM -0700, Geoff Keating wrote:
> This is still the case; it's easy to suppress the warning by adding an
> appropriate attribute, or by use of 'volatile' (at least, I hope
> 'volatile' works, if not it can be fixed).

Why in the world would "volatile" affect this in any way?


r~

Re: GCC warnings for unused global variables

[Zack Weinberg]

Neil Booth <neil@daikokuya.co.uk> writes:

>> #define __RCSID(str) _Pragma("GCC ident " #str)
>
> Um, no, string concat doesn't and won't happen in #pragma.
>
> _Pragma takes a single literal.

Oh, right.  Well, that makes it only marginally more work:

#define __RCSID(str) __XRCSID(GCC ident str)
#define __XRCSID(str) _Pragma(#str)

zw

Re: GCC warnings for unused global variables

[Neil Booth]

Zack Weinberg wrote:-

> > That lets us neatly handle multiple object formats easily while still
> > using features like placing the strings in non-loaded sections when
> > using ELF.  ("Why waste the RAM?"  8-)  It also means that we can apply
> > (have applied!) __attribute__((__unused__)) nearly everywhere fairly
> > easily.
> 
> Hmm.  I could give you #pragma GCC ident (semantically identical to
> #ident) which would let you do
> 
> #define __RCSID(str) _Pragma("GCC ident " #str)

Um, no, string concat doesn't and won't happen in #pragma.

_Pragma takes a single literal.

Neil.

Re: GCC warnings for unused global variables

[Richard Henderson]

On Thu, May 01, 2003 at 10:54:44AM -0700, Kean Johnston wrote:
> I am frankly surprised you don't see that and are fighting
> so hard for this to stay in -Wall.

Perhaps a personal bias.  I've always *hated* rcsid tags.


r~

Re: GCC warnings for unused global variables

[Joe Buck]

On Thu, May 01, 2003 at 11:42:57AM -0700, Richard Henderson wrote:
> On Thu, May 01, 2003 at 10:54:44AM -0700, Kean Johnston wrote:
> > I am frankly surprised you don't see that and are fighting
> > so hard for this to stay in -Wall.
> 
> Perhaps a personal bias.  I've always *hated* rcsid tags.

Would you be willing to accept Kean's solution (split the warning)?
 

Re: GCC warnings for unused global variables

[Zack Weinberg]

cgd@broadcom.com writes:

> FYI, some of "the BSD folks" have already made substantial changes
> w.r.t. these markings, e.g. in NetBSD we do:
>
> #include <sys/cdefs.h>
> ...
> __COPYRIGHT(
> "@(#) Copyright (c) 1989, 1993\n\
>         The Regents of the University of California.  All rights reserved.\n");
> ...
> __RCSID("$NetBSD: cat.c,v 1.35 2002/09/13 18:07:52 thorpej Exp $");
> ...
>
> That lets us neatly handle multiple object formats easily while still
> using features like placing the strings in non-loaded sections when
> using ELF.  ("Why waste the RAM?"  8-)  It also means that we can apply
> (have applied!) __attribute__((__unused__)) nearly everywhere fairly
> easily.

Hmm.  I could give you #pragma GCC ident (semantically identical to
#ident) which would let you do

#define __RCSID(str) _Pragma("GCC ident " #str)

The strings would all be put neatly into the .comment section, and I
believe we can guarantee no warnings ever.  (_Pragma being a C99
feature, it would normally be warned about under -std=c89, but the
general suppression of warnings for code in system headers should
suffice to shut it up.)

zw

Re: GCC warnings for unused global variables

[Joe Buck]

> > I should add that this has already found mistakes, both within gcc
> > itself and in the linux kernel, where some static variable was left
> > stranded when the bit of code it had been associated with was removed,
> > but the variable forgotten.
> > 
> > That is exactly the sort of thing I expect this feature to find.
 
On Thu, May 01, 2003 at 10:54:44AM -0700, Kean Johnston wrote:
> Then by all means, let a user on a bug hunting mechanism turn on
> -Wall -Wunused-static-variables. It helps those users and doesn't
> hinder others. Having it part of -Wall just breaks so much its
> hardly worth it.

I think that Kean's suggestion is the best settlement of this issue.
Kean, would you be willing to contribute a patch to implement this idea?

Re: GCC warnings for unused global variables

[Geoff Keating]

Joe Buck <jbuck@synopsys.com> writes:

> On Thu, May 01, 2003 at 07:05:08AM -0400, Robert Dewar wrote:
> > > And warning on perfectly legal, innocuous constructs makes
> > > absolutely no sense to me.
> > 
> > Well all warnings apply to legal constructs, or they would be errors!
> 
> > As to innocuous, the reason why something is NOT an error is that you
> > can't tell whether it is innocous or not, so warnings almost always
> > generate some false positives (or they would not be warnings!)
> 
> Correct, but in this case, we've broken a 20-year-old convention.
> "Broken", that is, because we've carefully designed -Wall so that
> we can expect that high-quality software development processes can
> produce their code with -Wall -Werror.

This is still the case; it's easy to suppress the warning by adding an
appropriate attribute, or by use of 'volatile' (at least, I hope
'volatile' works, if not it can be fixed).

> > In this case, it is not clear what you are suggesting, to remove all
> > warnings in this situation would certainly remove some very useful
> > warnings. 
> 
> The suggestion should be clear: we have, in effect, introduced a regression.
> We should not be warning for unused constant strings, precisely because
> the existence of such strings is part of the de-facto standard SCCS/RCS
> coding convention.

It is not, and has never been, the case that -Wall is a flag that
always produces the same set of warnings on the same source code.
Those who want to use -Wall and want to have no warnings have to
realise that they will need to change their code with each new
compiler release as the compiler is enhanced to detect new
questionable constructs.  Such new warnings are not regressions, they
are progressions.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

RE: GCC warnings for unused global variables

[Kean Johnston]

> I think that Kean's suggestion is the best settlement of this issue.
> Kean, would you be willing to contribute a patch to implement 
> this idea?
Gladly. I'll work on it after lunch.

Kean

Re: GCC warnings for unused global variables

[Joe Buck]

On Thu, May 01, 2003 at 11:05:18AM -0700, Geoff Keating wrote:
> It is not, and has never been, the case that -Wall is a flag that
> always produces the same set of warnings on the same source code.
> Those who want to use -Wall and want to have no warnings have to
> realise that they will need to change their code with each new
> compiler release as the compiler is enhanced to detect new
> questionable constructs.  Such new warnings are not regressions, they
> are progressions.

While I agree with you in general, I do not in this specific case.

RE: GCC warnings for unused global variables

[Kean Johnston]

> I should add that this has already found mistakes, both within gcc
> itself and in the linux kernel, where some static variable was left
> stranded when the bit of code it had been associated with was removed,
> but the variable forgotten.
> 
> That is exactly the sort of thing I expect this feature to find.

Then by all means, let a user on a bug hunting mechanism turn on
-Wall -Wunused-static-variables. It helps those users and doesn't
hinder others. Having it part of -Wall just breaks so much its
hardly worth it.

The man page says "These are all of the options which pertain to usage
that we recommend avoiding and that we believe is easy to avoid,
even in conjunction with macros". Due to the 30-year history of
MUCH source code compiled with gcc, this warning falls very far
short of the "easy to avoid" statement. As someone pointed out,
the entire FreeBSD, NetBSD, OpenBSD, SVR3.2, SVR4.2, SVR5 source
trees, which is a *HUGE* amount of code, would all be affected
by this. I am frankly surprised you don't see that and are fighting
so hard for this to stay in -Wall.

Kean

Re: GCC warnings for unused global variables

[cgd]

At Thu, 1 May 2003 17:24:20 +0000 (UTC), "Joe Buck" wrote:
> (I believe you are, in effect, asking the BSD folks to change
> *every single file* in their operating system, or else live with vast
> numbers of warnings), but it's better still not to require any change.

I agree that forcing people to change their code would be a real
bummer.  (IMO, the put-zero-initialized-data-in-bss was a
similarly-losing change.  8-)

FYI, some of "the BSD folks" have already made substantial changes
w.r.t. these markings, e.g. in NetBSD we do:

#include <sys/cdefs.h>
...
__COPYRIGHT(
"@(#) Copyright (c) 1989, 1993\n\
        The Regents of the University of California.  All rights reserved.\n");
...
__RCSID("$NetBSD: cat.c,v 1.35 2002/09/13 18:07:52 thorpej Exp $");
...

That lets us neatly handle multiple object formats easily while still
using features like placing the strings in non-loaded sections when
using ELF.  ("Why waste the RAM?"  8-)  It also means that we can apply
(have applied!) __attribute__((__unused__)) nearly everywhere fairly
easily.



chris

Re: GCC warnings for unused global variables

[Richard Henderson]

On Thu, May 01, 2003 at 09:47:57AM -0700, Richard Henderson wrote:
> This would be considered a feature for any other variable...

I should add that this has already found mistakes, both within gcc
itself and in the linux kernel, where some static variable was left
stranded when the bit of code it had been associated with was removed,
but the variable forgotten.

That is exactly the sort of thing I expect this feature to find.


r~

Re: GCC warnings for unused global variables

[Joe Buck]

On Thu, May 01, 2003 at 09:47:57AM -0700, Richard Henderson wrote:
> On Thu, May 01, 2003 at 09:38:13AM -0700, Joe Buck wrote:
> > > Then you'll have to ignore the warning.
> > 
> > Then we should take OUT the bleeping warning.  It wasn't there before.
> > It is a regression.
> 
> It is not a regression.  I said "ignore" because he also said
> "he couldn't modify the source".  The REAL way to get rid of 
> the warning is to mark the thing __attribute__((unused)).
> 
> Or even better, __attribute__((used)).  If he fails to do this,
> then at some point GCC will stop emitting that variable to the
> object file entirely, precisely because it isn't used.

Neither will suffice, because neither are C.  You're forgetting that GCC
is not the only C compiler in the world.  As for your last point, we
would then need to add some flag to prevent GCC from suppressing the
emission of unused static objects.  It would be more acceptable to ask
people to add a new flag than to ask them to change all of their old
code bases (I believe you are, in effect, asking the BSD folks to change
*every single file* in their operating system, or else live with vast
numbers of warnings), but it's better still not to require any change.
 
> This would be considered a feature for any other variable,
> and I can't stomach making bletcherous special cases for a 
> variable named "rcsid".

I agree that there should be no special cases based on variable names.
-- 
Q. What's more of a headache than a bug in a compiler.
A. Bugs in six compilers.  -- Mark Johnson

Re: GCC warnings for unused global variables

[Nathan Sidwell]

Kean Johnston wrote:

>>Or even better, __attribute__((used)).  If he fails to do this,
>>then at some point GCC will stop emitting that variable to the
>>object file entirely, precisely because it isn't used.
> 
> THAT would be blatantly wrong. It means the compiler assumes it
> knows more about how things may be used than the human who wrote
> them does. Just because the source module doesn't use a variable,
> *EVEN IF ITS MARKED static* does NOT mean it is unused by other
> things, for example, object file analysys tools like "what".
then is should be volatile
	static const volatile rcsid[] = "my file";

not that this helps dusty decks ...

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

RE: GCC warnings for unused global variables

[Kean Johnston]

> It is not a regression.  I said "ignore" because he also said
> "he couldn't modify the source".  The REAL way to get rid of 
> the warning is to mark the thing __attribute__((unused)).
I agree with Joe. It *IS* a regression. The notion of embedding
object markers (such as rcsid and sccsid do) is a critical one
for large project (like UNIX). It has been around for an AWEFULLY
long time, and I can see little or no value to the warning being
in -Wall. Code can be otherwise perfectly clean, ANSI-compliant
and well engineered, and with this change the warning count, or
error count if -Werror is also used, sky-rocket.

If it was a warning that those developers that WANT it can turn
on, but not be turned on with -Wall, that would be fine, but it
really does break things. IMHO, "break things that previously
worked" == "regression". I have a huge source tree that compiles
cleanly with -Wall -Werror now, and almost the entire tree,
totalling a little over 300 000 files, would break with this warning.

> Or even better, __attribute__((used)).  If he fails to do this,
> then at some point GCC will stop emitting that variable to the
> object file entirely, precisely because it isn't used.
THAT would be blatantly wrong. It means the compiler assumes it
knows more about how things may be used than the human who wrote
them does. Just because the source module doesn't use a variable,
*EVEN IF ITS MARKED static* does NOT mean it is unused by other
things, for example, object file analysys tools like "what".

Kean

Re: GCC warnings for unused global variables

[Richard Henderson]

On Thu, May 01, 2003 at 09:38:13AM -0700, Joe Buck wrote:
> > Then you'll have to ignore the warning.
> 
> Then we should take OUT the bleeping warning.  It wasn't there before.
> It is a regression.

It is not a regression.  I said "ignore" because he also said
"he couldn't modify the source".  The REAL way to get rid of 
the warning is to mark the thing __attribute__((unused)).

Or even better, __attribute__((used)).  If he fails to do this,
then at some point GCC will stop emitting that variable to the
object file entirely, precisely because it isn't used.

This would be considered a feature for any other variable,
and I can't stomach making bletcherous special cases for a 
variable named "rcsid".


r~

Re: GCC warnings for unused global variables

[Joe Buck]

On Wed, Apr 30, 2003 at 05:21:07PM -0700, Richard Henderson wrote:
> >          Copyright (c) 1989, 1993, 1994
> >         termcap.c       8.1 (Berkeley) 6/4/93
> >         strftime.c      7.38
> >         localtime.c     7.57
> >         asctime.c       7.7
> >         rec_seq.c       8.3 (Berkeley) 7/14/94
> >         key_call.c      1.25    94/04/24 SMI
> > 
> > Does #ident allow that?
> 
> Yes.  For ELF this normally winds up in the .comment section.
> Of course, this section is removed by strip, so it won't
> *necessarily* be there, but ...

Then it won't do.  It is a 20-year-old convention to do this, PRECISELY
so that binaries can be stripped but still tracked.
 
> > const static rcsid's are very common.
> 
> Then you'll have to ignore the warning.

Then we should take OUT the bleeping warning.  It wasn't there before.
It is a regression.

Re: GCC warnings for unused global variables

[Joe Buck]

On Thu, May 01, 2003 at 07:05:08AM -0400, Robert Dewar wrote:
> > And warning on perfectly legal, innocuous constructs makes
> > absolutely no sense to me.
> 
> Well all warnings apply to legal constructs, or they would be errors!

> As to innocuous, the reason why something is NOT an error is that you
> can't tell whether it is innocous or not, so warnings almost always
> generate some false positives (or they would not be warnings!)

Correct, but in this case, we've broken a 20-year-old convention.
"Broken", that is, because we've carefully designed -Wall so that
we can expect that high-quality software development processes can
produce their code with -Wall -Werror.
 
> In this case, it is not clear what you are suggesting, to remove all
> warnings in this situation would certainly remove some very useful
> warnings. 

The suggestion should be clear: we have, in effect, introduced a regression.
We should not be warning for unused constant strings, precisely because
the existence of such strings is part of the de-facto standard SCCS/RCS
coding convention.

Re: GCC warnings for unused global variables

[Robert Dewar]

> And warning on perfectly legal, innocuous constructs makes
> absolutely no sense to me.

Well all warnings apply to legal constructs, or they would be errors!

As to innocuous, the reason why something is NOT an error is that you
can't tell whether it is innocous or not, so warnings almost always
generate some false positives (or they would not be warnings!)

In this case, it is not clear what you are suggesting, to remove all
warnings in this situation would certainly remove some very useful
warnings. 

Re: GCC warnings for unused global variables

[Marc Espie]

In article <20030430083713.GU4016@paradies.suse.de> you write:
>* Alexander Kabaev (ak03@gte.com) [20030429 22:57]:
>
>> #ifndef lint
>> static const char rcsid[] =
>>   "$Id: src/dir/file.c 1.12 1999/08/27 23:45:12 me Exp$";
>> #endif /* not lint */
>
>Why not just use __attribute__((__unused__))?
>
>Philipp

Because it's a gcc extension, so writing portable code that
uses it will require some more machinery, hence more clutter.

Also, this kind of thing is pervasive in older code.

And warning on perfectly legal, innocuous constructs makes
absolutely no sense to me.

Using static char * variables (lately, const char *) to embed
version strings in files has been current practice over the last
twenty years or so. Why break it now ?

Re: GCC warnings for unused global variables

[Richard Henderson]

On Wed, Apr 30, 2003 at 07:47:30PM -0400, Alexander Kabaev wrote:
> % what `which ls`
> /bin/ls:
>          Copyright (c) 1989, 1993, 1994
>         termcap.c       8.1 (Berkeley) 6/4/93
>         strftime.c      7.38
>         localtime.c     7.57
>         asctime.c       7.7
>         rec_seq.c       8.3 (Berkeley) 7/14/94
>         key_call.c      1.25    94/04/24 SMI
> 
> Does #ident allow that?

Yes.  For ELF this normally winds up in the .comment section.
Of course, this section is removed by strip, so it won't
*necessarily* be there, but ...

> Anyway, my question was about boatload of
> third-party software, which normally should not be modified locally.
> const static rcsid's are very common.

Then you'll have to ignore the warning.


r~

Re: GCC warnings for unused global variables

[Philipp Thomas]

* Alexander Kabaev (ak03@gte.com) [20030429 22:57]:

> #ifndef lint
> static const char rcsid[] =
>   "$Id: src/dir/file.c 1.12 1999/08/27 23:45:12 me Exp$";
> #endif /* not lint */

Why not just use __attribute__((__unused__))?

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nuremberg, Germany

GCC warnings for unused global variables

[Alexander Kabaev]

  I noticed that GCC 3.3 differs slightly from GCC 3.2 in regards of
unused static variable warning emission. GCC 3.2 used to ignore
unused static constant variables in both C and C++ frontends before, now
it only does that for C++. Unfortunately, this means that the
following common C code snippet now generates a warning: 

#ifndef lint
static const char rcsid[] =
  "$Id: src/dir/file.c 1.12 1999/08/27 23:45:12 me Exp$";
#endif /* not lint */

 I wonder if the old behavior can be restored or a new -W flag can be
introduced to disable unused warning for such variables? The flag should
pretty trivial to implement.

-- 
Alexander Kabaev