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

Thu Oct 26 11:36:27 CDT 2006

Pardon me,

Why are we reverting?

It works on all compilers I know of.
I just get warnings on pgCC...I'm not even sure they weren't there before.

On 26.10.06, Tom Goodale wrote:
> 
> 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
> >
> >
> >

> _______________________________________________
> 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] g++ warning: operation on *bla* may be undefined

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