[Developers] g++ warning: operation on *bla* may be undefined

Steve White steve.white at aei.mpg.de
Fri Oct 27 04:19:46 CDT 2006


Hi,

I have never used __attribute__ at all.  It is a Gnu extension.

Here is a discussion where it's pointed out that  __attribute__((unused)) 
and __attribute__((used)) are not negations of one another (when used for
function declarations anyway), and could both be used. 
	http://www.ussg.iu.edu/hypermail/linux/kernel/0410.1/1797.html

So I wrote a little program (attached), and tried it on five compilers
	g++ icpc xlC pgCC pathCC 
My notes are below.

The upshot is:
* only icpc complains of unused parameters with normal warnings on.  

* __attribute__ didn't break anything else

* __attribute__((unused)) works with icpc to turn the normal warning off

Judging from this sample, we are only "fixing" one compiler, with all
of these efforts.

Perhaps it would be best to get rid of all this extra code, and tell
icpc not to complain about unused parameters.


Who can take __attribute__((unused))
====================================
g++ -Wall
	OK
icpc -Wall
	OK
xlC -qflag=i:i	(the default)
	With
		-qinfo, 
	it complains attribute "unused" is ignored and int a is not used
	(which means it recognizes __attribute__ but not "unused")

pgCC -Minform=inform (-Minfo -Mneginfo)
	OK
pathCC -Wall
	OK 

Who complains about a plain, unused parameter?
==============================================
g++ -Wall -pedantic -ansi
	does not complain. To make it complain, must specify
		-Wunused-parameter

icpc -Wall 
	complains

pgCC -Minfo=all
	does not complain

pathCC -Wall 
	does not complain
	(even with -Wunused-parameter, does not complain (broken))

xlC -qflag=i:i
	does not complain.  To make it complain, specify -qinfo 


On 26.10.06, Erik Schnetter wrote:
> Nothing special happens.  This attribute just means that this  
> variable is expected to be potentially unused, so that there should  
> be no warnings about it.  As far as I know, this is meant for auto- 
> generated code or similar situations where variables which are left  
> unused are not a programmer's oversight.
> 
> There is also an __attribute__((used)), which specifies that this  
> variables is actually used, even if it "looks unused" in the source  
> code.  This is useful for transforming the produced assembler code  
> later on.
> 
> -erik
> 
> On Oct 26, 2006, at 16:42:09, Tom Goodale wrote:
> 
> >Interesting.  What happens when you do use an __attribute__ 
> >((unused)) variable ?
> >
> >Tom
> >
> >On Thu, 26 Oct 2006, Erik Schnetter wrote:
> >
> >>gcc has __attribute__((unused)) to mark variables that are  
> >>intentionally unused.  This suppresses this warning.  Other  
> >>compilers may have similar ways for annotating variables.
> >>
> >>I have implemented a bit of generic infrastructure to declare  
> >>variables, which makes it easier to experiment with these things.   
> >>I have also implemented autodetecting whether __attribute__ 
> >>((unused)) is supported, so that it is used when present, and an  
> >>old-style mechanism is used otherwise. A similar thing is done for  
> >>Fortran code.
> >>
> >>The changes are straightforward, but touch quite a number of  
> >>files.  I would need to isolate them from other changes, and then  
> >>they need to be tested thoroughly.  I can do the first part if you  
> >>are interested.
> >>
> >>We discussed this before, and then the consensus was that using  
> >>__attribute__((unused)) was not worth the effort because the  
> >>existing mechanisms were sufficient.  Maybe this has changed with  
> >>gcc 4 having become too clever.
> >>
> >>-erik
> >>
> >>On Oct 26, 2006, at 15:50:38, Steve White wrote:
> >>
> >>>Hi again.
> >>>Unfortunately, Portland Group's C++ compiler (which I hadn't tried
> >>>in my tests) now warns:
> >>>
> >>>     variable "parameter_name" was set but never used
> >>>for every CCTK parameter.  I don't think it was warning about the
> >>>old code.
> >>>It seems that one can't please everybody.
> >>>On 20.10.06, Steve White wrote:
> >>>>Hi,
> >>>>This is concerned with g++ warnings like:
> >>>>
> >>>>	Preprocessing arrangements/Carpet/Carpet/src/Timing.cc
> >>>>	Compiling arrangements/Carpet/Carpet/src/Timing.cc
> >>>>	configs/chain_gcc_carpet/build/Carpet/Timing.cc:
> >>>>		In function ‘void Carpet::InitTimingVariables(const 
> >>>>		cGH*)’:
> >>>>	configs/chain_gcc_carpet/build/Carpet/Timing.cc:120:
> >>>>		warning: operation on ‘cctki_use’ may be undefined
> >>>>The culprit was in generated bindings code meant to get rid of  
> >>>>warnings
> >>>>about unused variables corresponding to Cactus parameters  
> >>>>included in
> >>>>code by the DECLARE_CCTK_PARAMETERS macro.
> >>>>Typically, a struct was defined to hold copies of the macros, then
> >>>>such very interesting constructs would appear.
> >>>>
> >>>> const void *PRIVATE_CACTUS_STRUCT_use = ( \
> >>>>   PRIVATE_CACTUS_STRUCT_use = &cctk_run_title, \
> >>>>   PRIVATE_CACTUS_STRUCT_use = &*PRIVATE_CACTUS_STRUCT_use \
> >>>> )
> >>>>This code replaces that with a do-nothing enum declaration
> >>>> enum {
> >>>>   dummy_cctk_run_title = sizeof( cctk_run_title )
> >>>>   //,etc.
> >>>> };
> >>>>The nature of all the entities involved is here much clearer,  
> >>>>both to
> >>>>compilers and to me.
> >>>>Like the existing solution, this permits the user to proceed to  
> >>>>make more
> >>>>declarations after the DECLARE_CCTK_PARAMETERS macro (simply  
> >>>>putting a list
> >>>>of variable assignments after the declaration would not have  
> >>>>that property).
> >>>>See also the patches list posting of the same name, and PR 2070
> >>>>http://www.cactuscode.org/cactus_cgi-bin/gnatsweb.pl?cmd=view% 
> >>>>20audit-trail&database=cactus&pr=2070
> >>>>for a patch.
> >>>>It has been tested on Gnu 4x, Intel 9x, IBM XL
> >>>>Cheers!

-- 
Steve White : Programmer
Max-Planck-Institut für Gravitationsphysik      Albert-Einstein-Institut
Am Mühlenberg 1, D-14476 Golm, Germany                  +49-331-567-7625
-------------- next part --------------

static void
plain_unused( int a );
static void
attribute_unused( int a );

int
main()
{
	int a = 1;

	plain_unused( a );
	attribute_unused( a );
	
	return 0;
}

void
plain_unused( int a )
{	
}

void
attribute_unused( int __attribute__((unused)) a )
{	
}


More information about the Developers mailing list