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

[Tom Goodale]

Ok, this is getting silly.  As I said before, the easiest solution looks 
like to revert to the previous system, which works for everything except 
the latest g++, and then add the attribute stuff for that using Erik's 
detection mechanism to see if it's available.  We know that both these 
approaches work where they are valid so wouldn't need to experiment any 
more and come up with yet another in the long line of kludges.

Tom

On Thu, 26 Oct 2006, Erik Schnetter wrote:

> 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
>
>
>