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

Thu Oct 26 10:49:57 CDT 2006

If I remember correctly, gcc suppresses warnings about var being  
unused when you add the no-op expression

	int x = sizeof(var);

to the source code.  Other compilers suppress warnings when you add  
the no-op expression

	int * y = & var + 1;

to the source code.  If you want to suppress warnings for all  
compilers, combine both approaches:

	int x = sizeof(var);
	int * y = & var + 1;

Thus, both compilers will see that var is used in some way.

-erik

On Oct 26, 2006, at 17:40:23, Steve White wrote:

> No comprendo.
>
> On 26.10.06, Erik Schnetter wrote:
>> Idea: Try
>>
>> 	sizeof var + whatever-term-works-for-the-other-compilers,
>>
>> this way each compiler sees the variable used.
>>
>> -erik
>>
>> On Oct 26, 2006, at 17:09:40, Steve White wrote:
>>
>>> Well, the mechanism I put in works for gcc...
>>> It seems the pgCC doesn't consider sizeof( var ) to be a "use" of  
>>> var.
>>> I'm looking at an alternative.
>>>
>>> On 26.10.06, 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
>>>>
>>>>
>>>> -- 
>>>> 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.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>> Developers at cactuscode.org
>>>> http://www.cactuscode.org/mailman/listinfo/developers
>>>
>>>
>>> -- 
>>> 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.
>>
>>
>>
>
>
>
>> _______________________________________________
>> Developers mailing list
>> Developers at cactuscode.org
>> http://www.cactuscode.org/mailman/listinfo/developers
>
>
> -- 
> 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/ee8db274/attachment.bin 

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

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