Compilation with Geant4.5.0.ref02 spits out an unacceptable level of warnings with GCC 3.2. Please clean up the entire code. Please start using strict GCC warning options yourself so that this bug does not need to be reported continuously -- I have reported it at least three times now. It is impossible to see any real warnings in our own code because of the noise from G4.
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.
