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

[Steve White]

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