After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 652272 - glib 2.29.6 unconditionally use gcc-specific -Wstrict-aliasing
glib 2.29.6 unconditionally use gcc-specific -Wstrict-aliasing
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gobject
2.29.x
Other Solaris
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-06-10 10:37 UTC by Dagobert Michelsen
Modified: 2011-09-05 00:10 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Removal of -Wstrict-aliasing (1.28 KB, text/plain)
2011-06-10 10:37 UTC, Dagobert Michelsen 		Details

Description Dagobert Michelsen 2011-06-10 10:37:12 UTC 
Created attachment 189609 [details]
Removal of -Wstrict-aliasing

The unconditional use of -Wstrict-aliasing breaks compilation on non-gcc compilers (here: Sun Studio 12 on Solaris 9 sparc). The attached patch removes the flag, a shielding to gcc-only would also be ok.
Comment 1 Matthias Clasen 2011-06-10 10:59:21 UTC 
It may fix the build, but it breaks the test... the entire point of the test was originally to verify that we don't get aliasing warnings. Does the sun studio compiler have a different flag to trigger aliasing warnings ?
Comment 2 Dagobert Michelsen 2011-06-10 11:36:21 UTC 
There is a flag in Sun Studio "lint", but to my knowledge there is none in "cc". Probably it is then best to skip the whole test for non-gcc?
Comment 3 Matthias Clasen 2011-06-16 23:28:55 UTC 
no, the test is actually checking that atomic ops do what they are supposed to do too, nowadays, so we probably just want to restrict the flag to be gcc-only
Comment 4 Dagobert Michelsen 2011-08-22 13:21:58 UTC 
The issue is still present in 2.29.16. Should the setting be made around
  if test "x$GCC" = "xyes"; then
  ...
in configure.ac?

Best regards  -- Dago
Comment 5 Colin Walters 2011-08-22 21:59:50 UTC 
(In reply to comment #4)
> The issue is still present in 2.29.16. Should the setting be made around
>   if test "x$GCC" = "xyes"; then
>   ...
> in configure.ac?

Yes.  You could either do AM_CONDITIONAL(HAVE_GCC) or AC_SUBST(STRICT_ALIASING_CFLAGS)