Problem 469

Can you please specify which kind of warnings you refer to ?
As far as I know this is the first time we hear of this (nobody ever reported
to us!), and according to our records compilation of the G4 code on gcc-3.2
flows rather smootly. Are you using a different set of compilation options ?
(in G4 the default is "-Wall -ansi -pedantic", essentially the same as CLHEP,
 G4 specific ones are also: -DGNU_GCC -DG4USE_STD_NAMESPACE, subject to
 removal in future relases, but currently necessary).

/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:
In member function `void G4Allocator<Type>::FreeSingle(Type*) [with Type = G4Run]':
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Run.hh:95:
instantiated from here
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:159:
warning: invalid offsetof from non-POD type `class G4AllocatorUnit<G4Run>'; use
pointer to member instead
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:
In member function `void G4Allocator<Type>::FreeSingle(Type*) [with Type =
G4PrimaryParticle]':
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4PrimaryParticle.hh:196:
  instantiated from here
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:159:
warning: invalid offsetof from non-POD type `class
G4AllocatorUnit<G4PrimaryParticle>'; use pointer to member instead
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:
In member function `void G4Allocator<Type>::FreeSingle(Type*) [with Type =
G4PrimaryVertex]':
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4PrimaryVertex.hh:147:
  instantiated from here
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:159:
warning: invalid offsetof from non-POD type `class
G4AllocatorUnit<G4PrimaryVertex>'; use pointer to member instead
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:
In member function `void G4Allocator<Type>::FreeSingle(Type*) [with Type =
G4HCofThisEvent]':
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4HCofThisEvent.hh:98:
  instantiated from here
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:159:
warning: invalid offsetof from non-POD type `class
G4AllocatorUnit<G4HCofThisEvent>'; use pointer to member instead
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:
In member function `void G4Allocator<Type>::FreeSingle(Type*) [with Type =
G4DCofThisEvent]':
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4DCofThisEvent.hh:99:
  instantiated from here
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:159:
warning: invalid offsetof from non-POD type `class
G4AllocatorUnit<G4DCofThisEvent>'; use pointer to member instead
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:
In member function `void G4Allocator<Type>::FreeSingle(Type*) [with Type =
G4TrajectoryContainer]':
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4TrajectoryContainer.hh:88:
  instantiated from here
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:159:
warning: invalid offsetof from non-POD type `class
G4AllocatorUnit<G4TrajectoryContainer>'; use pointer to member instead
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:
In member function `void G4Allocator<Type>::FreeSingle(Type*) [with Type =
G4Event]':
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Event.hh:162:
 instantiated from here
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:159:
warning: invalid offsetof from non-POD type `class G4AllocatorUnit<G4Event>';
use pointer to member instead
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:
In member function `void G4Allocator<Type>::FreeSingle(Type*) [with Type =
G4ElectronOccupancy]':
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4ElectronOccupancy.hh:116:
  instantiated from here
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:159:
warning: invalid offsetof from non-POD type `class
G4AllocatorUnit<G4ElectronOccupancy>'; use pointer to member instead
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:
In member function `void G4Allocator<Type>::FreeSingle(Type*) [with Type =
G4DynamicParticle]':
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4DynamicParticle.icc:51:
  instantiated from here
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:159:
warning: invalid offsetof from non-POD type `class
G4AllocatorUnit<G4DynamicParticle>'; use pointer to member instead
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:
In member function `void G4Allocator<Type>::FreeSingle(Type*) [with Type =
G4Track]':
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Track.icc:42:
 instantiated from here
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:159:
warning: invalid offsetof from non-POD type `class G4AllocatorUnit<G4Track>';
use pointer to member instead
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:
In member function `void G4Allocator<Type>::FreeSingle(Type*) [with Type =
G4CountedObject<G4VTouchable>]':
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4ReferenceCountedHandle.hh:206:
  instantiated from `static void G4CountedObject<X>::operator delete(void*)
[with X = G4VTouchable]'
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4ReferenceCountedHandle.hh:194:
  instantiated from `void G4CountedObject<X>::Release() [with X = G4VTouchable]'
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4ReferenceCountedHandle.hh:232:
  instantiated from `void
G4ReferenceCountedHandle<X>::G4ReferenceCountedHandle() [with X = G4VTouchable]'
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4StepPoint.hh:73:
  instantiated from here
/afs/cern.ch/sw/geant4/releases/share/geant4.5.0.ref02/include/G4Allocator.hh:159:
warning: invalid offsetof from non-POD type `class
G4AllocatorUnit<G4CountedObject<G4VTouchable> >'; use pointer to member instead

Please, add -DGNU_GCC in your setup.

The warning-related compiler options we use are: "-ansi -pedantic -W -Wall
-Wno-non-virtual-dtor -Wno-long-long -Wwrite-strings -Wpointer-arith
-Woverloaded-virtual".  Of those you should definitely add at least "-W".
-DGNU_GCC helps, but you should make this automatic.  If the code really needs
to know the compiler, it's easy enough to find out with preprocess defines (e.g.
GCC defines __GNUC__).

> The warning-related compiler options we use are: "-ansi -pedantic -W -Wall
> -Wno-non-virtual-dtor -Wno-long-long -Wwrite-strings -Wpointer-arith
> -Woverloaded-virtual".  Of those you should definitely add at least "-W".

Thanks Lassi. We'll try to gradually introduce more strict warning options.
However, for what concerns Geant4, this should also happen in sync with the
standard warning level used in CLHEP, and this is what we're currently
matching to.

> -DGNU_GCC helps, but you should make this automatic.  If the code really
> needs to know the compiler, it's easy enough to find out with preprocess
> defines (e.g. GCC defines __GNUC__).

Yes right, as I said before this and G4USE_STD_NAMESPACE will be fixed in
a future release this year once the few existing wrappers for ISO/non-ISO
portability will be fully removed.

The reason I reported the problem is that Geant4 (and by implication CLHEP)
should have the best quality of all LHC software.  It's impossible for us
experiments to build high-quality software on a shaky foundation, and thus
quality expectations on the base components (including Geant4) are the highest.
 I would encourage you to push *much* harder to get CLHEP in a good shape if
that is the bottleneck for enabling stricter warnings.

I perfectly agree with you, although you may recognize that it's rather
difficult for us to follow any possible combination of warnings options
or users' conventions on any new/old versions of different compilers,
and easily move hundred thousands lines of code.... What we can do, and
actually always did since the beginning of the Geant4 project is to
find what we think is the right balance and propose migrations/
corrections of the code and setup when indeed necessary.
Having clarified that, even by adding the options you suggest,
excluding trivial forced warnings for unused variables/parameters, a
relatively small number of cases are spotted (which may also mean that
the code foundation is not that shaky after all...), so I may conclude
that such additions you propose and the related migration of the code
can be achieved in a rather short time scale.
I believe that the additional (and necessary) G4 specific options I
suggested to you should resolve most of the warnings you were mainly
concerned about.

My experience is different.  If you are vigilant about warnings -- consistently
use strictest warnings you find in each supported compiler and ask developers
not to introduce new code with warnings -- you are generally well off.  The
continuous effort is small but the pay-off is huge.  This requires you to be
proactive.  I would agree that suddenly getting rid of warnings if you never
paid attention to them might be a large task.  You shouldn't have that problem
to begin with :-)

May be opinable, of course, but in G4 we've been always vigilant about warnings.
As for applying the strictest warning options, I do not completely agree.
My experience tells that not always compilers (especially g++ in all its
different releases and subreleases) correctly report about mistakes in the code
and in some cases are also misleading and confusing to developers...
but please, let's move this offline if there's anything else to discuss. Thanks.