[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r18040 - in trunk/subversion: libsvn_delta libsvn_fs_fs libsvn_ra_dav libsvn_ra_svn libsvn_repos libsvn_subr libsvn_wc svn tests/libsvn_delta

From: Daniel Rall <dlr_at_collab.net>
Date: 2006-01-18 21:56:29 CET

On Tue, 17 Jan 2006, Peter N. Lundblad wrote:

> On Tue, 17 Jan 2006, Philip Martin wrote:
>
> > definitely defeats valgrind which can detect such uses if they get
> > tested.
> >
> > It's possible to stop gcc reporting these warnings with
> > '-Wno-uninitialized' although that will also stop the warnings that
> > are not 'false alarms'. It's possible to change the optimiser with
> > '-fno-unit-at-a-time' but that might reduce the optimisation. I don't
> > know if we can tell the optimiser about the non-NULL return of
> > svn_error_create, but I think not.
> >
> > Maybe we are stuck with these initialisations, but it does make me a
> ...
>
> As I indicated in another mail, I think disabling this warning is the
> solution. Having valgrind indicate uninitialized data is much more
> valuable than relying on this unreliable GCC warning (even though valgrind
> is not used as much as it should). The worst thing is having to
> initialize "out parameters" to an arbitrary value before calling a
> function.
>
> And, since this is most often a false alarm, the natural reaction after
> some time will be to just add an initializer, possibly missing a real
> error.

I reverted r18040 in r18161. Based on your feedback, I propose the
following patch to our build system to account for GCC's
idiosyncrasies WRT Subversion's source code.

[[[
Disable GCC 4.0.1's inconsistent "uninitialized" warnings, which
otherwise cause build failures when using its '-Wall -Werror' flags.
A follow-up to the r18040/r18161 commit/revert.

* Makefile.in
  (CFLAGS): Append "configure" substitution OVERRIDE_CFLAGS after
   EXTRA_CFLAGS.

* configure.in
  (OVERRIDE_CFLAGS): Add new substitution used when the compiler (CC)
   is gcc, tacking "-Wno-uninitialized" onto the end of the
   compilation flags. This additional substitution is necessary
   because GCC 4.0.1 takes argument ordering of such flags into
   consideration, and the flags may need to be positioned after
   EXTRA_CFLAGS to take affect.

Suggested by: philip
              lundblad
]]]

Index: Makefile.in
===================================================================
--- Makefile.in (revision 18161)
+++ Makefile.in (working copy)
@@ -127,7 +127,7 @@
 MKDIR = @MKDIR@
 
 # The EXTRA_ parameters can be used to pass extra flags at 'make' time.
-CFLAGS = @CFLAGS@ $(EXTRA_CFLAGS)
+CFLAGS = @CFLAGS@ $(EXTRA_CFLAGS) @OVERRIDE_CFLAGS@
 ### A few of the CFLAGS (e.g. -Wmissing-prototypes, -Wstrict-prototypes,
 ### -Wmissing-declarations) are not valid for C++, and should be somehow
 ### suppressed (but they may come from httpd or APR).
Index: configure.in
===================================================================
--- configure.in (revision 18162)
+++ configure.in (working copy)
@@ -694,6 +694,19 @@
 
 # ==== Miscellaneous bits ====================================================
 
+if test "$CC" = "gcc" ; then
+ # Turn off compilation warning known to cause problems with
+ # Subversion's source and GCC 4.0.1.
+ if echo "$CFLAGS" | grep -v '\-Wno-uninitialized' > /dev/null; then
+ dnl We use OVERRIDE_CFLAGS instead of vanilla CFLAGS (positioned
+ dnl after $(EXTRA_CFLAGS) in Makefile.in), because argument
+ dnl ordering matters to GCC, and our supplied flags must take
+ dnl precedence.
+ OVERRIDE_CFLAGS='-Wno-uninitialized'
+ AC_SUBST(OVERRIDE_CFLAGS)
+ fi
+fi
+
 dnl Since this is used only on Unix-y systems, define the path separator as '/'
 AC_DEFINE_UNQUOTED(SVN_PATH_LOCAL_SEPARATOR, '/',
         [Defined to be the path separator used on your local filesystem])

  • application/pgp-signature attachment: stored
Received on Thu Jan 19 00:25:05 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.