This was probably fixed by this patch:

2008-01-22  Manuel Lopez-Ibanez  <manu@gcc.gnu.org>

	PR 32102
	* doc/invoke.texi (-Wall): -Wall enables -Wstrict-overflow=1.
	* flags.h (warn_strict_aliasing): Remove.
	(warn_strict_overflow): Remove.
	* opts.c (warn_strict_aliasing): Remove.
	(warn_strict_overflow): Remove.
	* c-opts.c (c_common_handle_option): -Wall only sets
	-Wstrict-aliasing or -Wstrict-overflow if they are uninitialized.
	(c_common_post_options): Give default values to -Wstrict-aliasing
	and -Wstrict-overflow if they are uninitialized.
	* common.opt (Wstrict-aliasing): Specify Var and Init.
	(Wstrict-overflow): Likewise.

I don't think this is a bug.
We have -Wno-strict-aliasing -Wall, so we turn back on the warning via the -Wall option.

Even -Wall should not warn for strict-aliasing issues as we also see -Fno-strict-aliasing (wrong caps?);  also we have another -Wno-strict-aliasing
after -Wall.

Btw, a testcase would be nice.

This is not a regression ...

I changed -Fno-strict-aliasing to -fno-strict-aliasing and the warning disappeared.

But shouldn't -Wno-strict-aliasing suppress the warning?

Well, yes.  Which is why a testcase would be nice (like preprocessed source of
one file you see this error).

(In reply to comment #6)
> But shouldn't -Wno-strict-aliasing suppress the warning?

Yes if you actually have -Wno-strict-aliasing after -Wall.

Christoph, we need a testcase to be able to reproduce the bug, otherwise, we cannot fix it.

(In reply to comment #8)
> (In reply to comment #6)
> > But shouldn't -Wno-strict-aliasing suppress the warning?
> 
> Yes if you actually have -Wno-strict-aliasing after -Wall.

Andrew, note that this is not longer true in 4.2.3 and 4.3. -Wall won't override -Wno-strict-aliasing and it won't override -Wstrict-aliasing=2 (and the same for -Wstrict-overflow variants)

I believe we're running into this in Nautilus and GCC 4.3.x (confirmed on both Ubuntu Intrepid Ibex/8.10's 4.3 toolchain and Arch Linux's toolchain [unsure of the micro-version]). If anyone wants to walk me through the steps of what you need to diagnose this bug, that would be very helpful. We're currently considering just working around it entirely with -fno-strict-aliasing, but if this bug can be fixed upstream, all the better. Thanks.

GNOME Bug: http://bugzilla.gnome.org/show_bug.cgi?id=528081

We are still waiting for a testcase, which would be the preprocessed source of
the file triggering the warning.  You'll get preprocessed source by appending
'-save-temps' to the gcc commandline and the preprocessed file will be named
$SOURCE.i.

Created attachment 15569 [details]
preprocessor output (gzipped)

With "gcc (Ubuntu 4.3.0-3ubuntu4) 4.3.1 20080430 (prerelease)". This is what I got from gcc -E fm-directory-view.c (huge list of includes omitted for sanity). I couldn't quite get -save-temps working (it only output a 75 byte file, which can't possibly be right). 

Anyways, the specific problem is coming from a macro "EEL_ASSIGN_MUST_OVERRIDE_SIGNAL", which is defined as "#define EEL_ASSIGN_MUST_OVERRIDE_SIGNAL(class_pointer, prefix, signal)
* (void (**)(void)) & (class_pointer)->signal = prefix##_unimplemented_##signal". Fails to build with "-Wall -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Werror -Wno-strict-aliasing -Wno-pointer-sign"

I can include the original C file if it's needed as well. Hope this helps.

This doesn't lookk like the strict-aliasing warning though, but

gcc-4.3 -S t.i -o /dev/null -Wall -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Werror -Wno-pointer-sign -Wno-strict-aliasing -m64
cc1: warnings being treated as errors
fm-directory-view.c: In function ‘file_and_directory_hash’:
fm-directory-view.c:521: error: cast from pointer to integer of different size
fm-directory-view.c:521: error: cast from pointer to integer of different size
fm-directory-view.c: In function ‘remove_not_really_moved_files’:
fm-directory-view.c:2445: error: cast from pointer to integer of different size

(works fine for me without -m64 / with -m32).  You can use -Wno-pointer-to-int-cast to disable this particular warning.

Whoops.  I can reproduce the

fm-directory-view.c:8887: error: dereferencing type-punned pointer will break strict-aliasing rules

errors with -O2.

Err, simple.  (-Wstrict-aliasing=0 works, but -Wno-strict-aliasing doesn't)

Index: opts.c
===================================================================
--- opts.c	(revision 134849)
+++ opts.c	(working copy)
@@ -1865,6 +1865,8 @@ set_Wstrict_aliasing (int onoff)
   gcc_assert (onoff == 0 || onoff == 1);
   if (onoff != 0)
     warn_strict_aliasing = 3;
+  else
+    warn_strict_aliasing = 0;
 }
 
 /* The following routines are useful in setting all the flags that

(In reply to comment #15)
> Whoops.  I can reproduce the
> 
> fm-directory-view.c:8887: error: dereferencing type-punned pointer will break
> strict-aliasing rules
> 
> errors with -O2.
> 

Yes, of course, that's what we were seeing. I should have said I was using -O2, sorry for not pointing that out and for your quick work on this!

Subject: Bug 34973

Author: rguenth
Date: Sat May  3 15:26:10 2008
New Revision: 134902

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134902
Log:
2008-05-03  Richard Guenther  <rguenther@suse.de>

	PR middle-end/34973
	* opts.c (set_Wstrict_aliasing): Handle the turn-off case.

Modified:
    branches/gcc-4_3-branch/gcc/ChangeLog
    branches/gcc-4_3-branch/gcc/opts.c

Fixed.

Subject: Bug 34973

Author: rguenth
Date: Sat May  3 15:28:57 2008
New Revision: 134903

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134903
Log:
2008-05-03  Richard Guenther  <rguenther@suse.de>

	PR middle-end/34973
	* opts.c (set_Wstrict_aliasing): Handle the turn-off case.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/opts.c