Android uses no-strict-aliasing for Thumb code

Bug #822113 reported by Zach Pfeffer
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Linaro Android
Fix Released
Medium
Chao Yang

Bug Description

Original email:

Hi,
I just spotted this bit in Android's Makefiles (inherited that way from AOSP):

TARGET_arm_CFLAGS := [...] -fstrict-aliasing [...]
[...]
TARGET_thumb_CFLAGS := [...] -fno-strict-aliasing [...]

This general assumption that arm code can handle strict aliasing, but
thumb code can't, seems odd.

My guess is that they started out using -fno-strict-aliasing
everywhere, then fixed aliasing violations and "fixed" the compiler
flags for arm, and didn't notice they're still turning it off for
thumb -- either that, or they've run into toolchain bugs (that might
be fixed in the Linaro toolchain), or it's a matter of "something
we're building in thumb mode has aliasing violations and we're too
lazy to figure out which part it is".

Unless someone knows of a valid reason for doing things the way they
did, simply taking it out (preferrably replacing it with
-Werror=strict-aliasing, so we're likely to notice any aliasing
violations if it comes down to "too lazy to figure out which part")
should get us some free extra speed. (Not sure just how much we're
actually building in thumb mode - may or may not be relevant.)

ttyl
bero

Zach Pfeffer (pfefferz)
Changed in linaro-android:
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Chao Yang (chaoyang)
milestone: none → 11.08
Revision history for this message
Bernhard Rosenkraenzer (berolinux) wrote :

I've seen a couple of errors while running a test build -- looks like at least parts of bionic error out with -Werror=strict-aliasing.
Looks pretty simple to fix though (and of course limiting -fno-strict-aliasing to just the bad files already allows a much more optimized build).

Revision history for this message
Chao Yang (chaoyang) wrote :

The following files and the corresponding modules are found breaking aliasing rules (with -Werror=strict-aliasing). It looks like a bit too many. Most of them are taking advantage of breaking the rules, such as pointer casting and then dereference. The safest and easiest fix it is to recover -fno-strict-aliasing for the modules affected.

include/netinet/in6.h
frameworks/base/libs/utils/ResourceTypes.cpp
external/stlport/stlport/stl/_stdexcept_base.c
external/icu4c/common/rbbi.cpp
libcore/luni/src/main/native/cbigint.cpp
external/fdlibm/k_cos.c
dalvik/vm/oo/ObjectInlines.h
frameworks/base/media/libmedia/Visualizer.cpp
external/dnsmasq/src/rfc2131.c
external/iptables/libiptc/libip4tc.c
frameworks/base/media/libmediaplayerservice/MediaPlayerService.cpp
external/skia/tests/MathTest.cpp
system/media/opensles/libopensles/android_Effect.cpp
frameworks/base/voip/jni/rtp/AudioGroup.cpp
frameworks/base/media/libeffects/visualizer/EffectVisualizer.cpp
external/tcpdump/print-bfd.c

Revision history for this message
Chao Yang (chaoyang) wrote :
Changed in linaro-android:
status: Confirmed → Fix Committed
Amit Pundir (pundiramit)
Changed in linaro-android:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.