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

[Erik Schnetter]

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