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

[Erik Schnetter]

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
>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers


-- 
Erik Schnetter <schnetter at cct.lsu.edu>

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20061026/26427930/attachment.bin