yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] JustArchi:
You're wrong mate.

-Wno-error=strct-aliasing works totally not the way you're describing it.

By turning on some flag through -f switch, like -fstrict-aliasing, we tell GCC to use it. Typically, if this will result in an error due to being unable to apply this flag, we'll have a warning and by default compilation will be aborted.

-Wno-error=strct-aliasing tells GCC to ignore warning, NOT error about strict aliasing. This option is made for guys like us who want to enable some flag, but also accept the fact that some parts may not be compatible with it, and this satisfies us. If you apply a flag, which causes direct problems, GCC will end up with internal compiler error and THIS is true error we can't avoid.

Therefore, you're wrong with your statement. I'm using this combination since half a year now and nobody, including ArchiDroid ports for i9000, i9305 and other has encountered any problems related to this combination. Also, I made bunch of tests to check how exactly GCC handles error with fstrict-aliasing. By default if you decide to apply -fstrict-aliasing GCC assumes that you want to apply this optimization and in case you can't, show you all errors on that. By adding no warning to it, it tells GCC to apply fstrict-aliasing where possible and locally turning it off for incompatible parts (with showing up warning and aborting compilation if -Werror).

GCC will automatically turn off fstrict-aliasing when it detects that it can't be used, the only difference is if you want to be informed about this fact and abort compilation, or ignore this warning and move forward.

Sorry but I can't agree with you here, this is not a truth. Otherwise my Android would be pretty messed up and half of the things would not work correctly, because as you noted, more than 30 parts are not working with fstrict-aliasing. Probably I'd not even boot and end up with kernel panics. It's PRACTICALLY impossible to force GCC to use fstrct-aliasing on whole Android and boot without problems.

Let's go further:

You're again wrong when you say that android_build doesn't touch kernel. It does, when I switched my O2 flags to O3, I noticed immediately that kernel is bigger. Maybe it doesn't apply to TARGET_ARM, but it definitely applies to $(combo_target) I used in select.mk. Try yourself, build your kernel through "make bootimage" after you lunch your target. Then clean ccache, make clean, cherry-pick my commit and build again. If you're right, size will be the same. But it will not be, I can assure you.

-flto caused problems to me, maybe it doesn't for some targets and do for others, I'm not using it at the moment.

Sorry mate but this is effect of practice and not theory. Maybe in theory it's right, but in practice it works as I said. Try yourself and compare results.
[Android Software/Hacking General [Developers Only]] RuralGalaxy:
Incredible Archi! Really good news! :D :D

Enviado desde mi Samsung Galaxy S3.
[Android Software/Hacking General [Developers Only]] desalesouche:
i had to fallback to 4.7, and it still errors...

target thumb C: adbd <= system/core/adb/backup_service.c

/tmp/ccmoWuCj.s: Assembler messages:

/tmp/ccmoWuCj.s:662: Error: can't resolve `.rodata' {.rodata section} - `.LPIC20' {*UND* section}

target thumb C: adbd <= system/core/adb/fdevent.c

build/core/binary.mk:512: recipe for target '/home/desalesouche/mokee/out/target/product/u8860/obj/STATIC_LIBRARIES/libmincrypt_intermediates/sha256.o' failed

make: *** [/home/desalesouche/mokee/out/target/product/u8860/obj/STATIC_LIBRARIES/libmincrypt_intermediates/sha256.o] Error 1

shame that i don't have the skill to fix , i really would like to test that...

thank you.
[Android Software/Hacking General [Developers Only]] MWisBest:
1. An internal compiler error means GCC segfaulting, and is an issue with GCC itself, not the code you're compiling. Internal means in the compiler, not in the code!

2. Compilation would be aborted IF you didn't use -Wno-error=strict-aliasing! You're telling GCC to IGNORE THE ERROR. If you want to not issue a WARNING, you use -Wno-strict-aliasing. Go test it yourself like you say you do!

3. GCC will not disable strict aliasing for a part of code it thinks isn't compatible with it. Besides, the only place it would provide a benefit in the first place is an area where it's compatible with it! You might as well not enable it at all then. (And plus, GCC can't compile only part of a source code file with strict aliasing disabled, there are #pragma s that can be used to disable an optimization or warning etc. for only a section of code, and GCC won't let you do that with strict-aliasing as it causes problems in doing so, go check their bug tracker on it.).

4. I'm not saying problems are going to be readily apparent. They're going to be lurking and hiding until they're triggered just right, and that's even more deadly.

5. So you're saying I've done the impossible using strict-aliasing everywhere? Thanks!

There's more in boot.img than just the kernel, that's why it increased in size. If you look at just the kernel image itself, it will be identical.

-flto caused problems because you can't blindly use it everywhere, you can just disable it in the areas it won't work:

1. Any HOST module, as those use outdated compilers, and it doesn't matter for the final result.

2. Anything built using the Clang compiler. Why Clang doesn't like it I'm not sure, but it's not a whole lot.

3. bionic.

My results are from practice too, and actually knowing how the compiler works. Go check GCC's docs, code, and bugtracker, THAT doesn't lie.

EDIT: I'll link you to the relevant GCC doc on Warning/Error Options: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
[Android Software/Hacking General [Developers Only]] JustArchi:
Okay then. Please show me your "deadly error" which I can reproduce on my phone and ROM which I won't be able to reproduce when not using -fstrict-aliasing. You can write your own binary for that, do whatever you want. Until then, considering the fact that I haven't run into any problems since half of the year with using such "death combination", I'm going to keep it.

And you're wrong again, kernel image differs. Have you tried it the way I suggested? Probably not.
[Android Software/Hacking General [Developers Only]] JustArchi:
Also, you're wrong.

Quoting your doc:

Then -Wno-error, turns off all warnings into errors, and turns off specific warning into error.

There's nothing mentioned that -Wno-error turns off errors. -W stands for warning, -Wno-error means do not threat warnings as errors. Opposite of -Werror (threat all warnings as errors).
[Android Software/Hacking General [Developers Only]] metalspring:
FYI, read this, while its not specifically for Wno-error=strict-aliasing, it tells you how the Wno-error= option is supposed to work-
[Android Software/Hacking General [Developers Only]] JustArchi:
Yeah, exactly. Disabling error for this warning. Warning generates error, not compiler. If you use -fstrict-aliasing then it may generate warning, and this warning may end up threated as an error. Compiler itself doesn't throw errors as long as code is right.
[Android Software/Hacking General [Developers Only]] PrimeDirective:
if you have to use Wno-error for anything performance related your'e doing it wrong lmao..
[Android Software/Hacking General [Developers Only]] JustArchi:
Of course you don't need to agree with me and you can cherry-pick my commit and disable -fstrict-aliasing on your own, but until I see any issue regarding this option I'm going to keep it, at least in my "deadly builds". Actually, the whole commit is one big signpost for experimenting with your own ROM and device, while it may magically work out of box for major portion of developers, still, not everything shared here will work with every ROM, device and compiler. This includes i.e. -flto - some people have no problem with it, while some do. And it's not only me :).
[Android Software/Hacking General [Developers Only]] MWisBest:
The only way this isn't causing problems is if you've got the stuff cherry-picked in to fix the violations and/or disable strict aliasing for unfixed sections (which the Neo guy's stuff does). This commit you released is authored today, how have you been using this specifically for 6 months then??

The kernel image will have a difference in the timestamp which will result in a different hash, and possibly a minute difference in size. If building the kernel depends on android_build, how do you explain that you can build the kernel without it, as most kernel devs do?

Enabling -fstrict-aliasing automatically enables -Werror=strict-aliasing, so when the compiler warns about an aliasing violation it then throws an error and halts compiling because it's a serious problem! Yes -W(no) is for warnings, and -W(no-)error(=) is for errors. What's your point?

That's for one thing, PGO. It's only specific to that one thing or it would be mentioned everywhere else.

A warning is a warning and an error is an error. The compiler can throw a warning which it may optionally treat as a serious error and stop compilation altogether. It doesn't throw an error, errors are just for instructing the compiler how to handle its warnings. Like I said, there's a reason an aliasing violation is treated as an error by default. It doesn't matter if -Werror (which treats any warning as an error) is enabled globally, -Werror=strict-aliasing is going to be enabled so long as -fstrict-aliasing is enabled and you don't recklessly disable the warning or the error.

---------- Post added at 08:04 PM ---------- Previous post was at 08:00 PM ----------

Exactly. Either fix the error or don't use the optimization.

---------- Post added at 08:08 PM ---------- Previous post was at 08:04 PM ----------

If you used LTO properly like I said just above this it'll work. The commit is right on my GitHub, it's not as simple as adding -flto next to all the other stuff which is why people blindly adding compiler flags like this can't get it to work.
[Android Software/Hacking General [Developers Only]] Neo:
I disagree. Many of the currently available strict aliasing "fixes" are unfortunately a flag to build that folder and all other files and folders under it recursively without strict aliasing. With the error flag disabled, should the compiler come across code that violates the policy, it automatically builds that file without the rule. In fact, it would be better imo to do it this way as it doesn't force every file and folder under it to build without that rule even if they were in compliance with the strict policy so you're actually doing more good then harm in this aspect. I would suggest, and have suggested before to people, is to apply any and all "TRUE" strict aliasing patches they can find that actually apply to the android platform they're compiling and then build with the error disabled.

Makes more sense then wrapping an entire arm with a bandage for a paper cut by using -fno-strict-aliasing in and Android.mk
[Android Software/Hacking General [Developers Only]] Codename13:
How can I tell if I properly compiled a ROM using the 4.8 toolchain? What I did was download this toolchain and I put it under prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8 in the ROM source. I then changed the value of "TARGET_GCC_VERSION" in build/core/combo/TARGET_linux-arm.mk from "4.7" to "4.8". Everything compiled well, and that's why I'm not sure if it even actually compiled using the 4.8 toolchain!
[Android Software/Hacking General [Developers Only]] PrimeDirective:
My rom already builds -fstrict-aliasing and it also doesn't use -wno-error=strict-aliasing or -fno-strict-aliasing locally becaues we fixed most of the violations in the actual code. We also build nightlies for 60 or so devices with god knows how many variants every single night. I can tell you right now these flags might work on your S3 but will undoubtably cause problems on others.

TBH some of these flags are probably valid improvements i just think maybe before you change any of them you should be doing performance benching and testing for regressions locally with statistical proof these are actually improvements. You should probably also find a way to implement them with a little more stategy. For example thumb2 code is meant to be small in size for efficient register usage so using -O3 optimization set is a bad idea unless you turn off the size increasing optimizations or compile thumb code as ARM and remove the thumb interworking.
[Android Software/Hacking General [Developers Only]] Neo:
Clobber, wipe ccache(if you use it), rename both your 4.7 toolchains to something like "TehOldzChain" then try to build again ;) haha
[Android Software/Hacking General [Developers Only]] twinko:
hello,

at first 2 things:

1. sorry for my bad english

2. and probably this is an very unprofessional question.

Is this Code implemented in your ArchiDroid ROM?

I only get 25% of what u written in your first post but im looking forward for new roms and most important long batterylife.

Greetings and thanks everybody!
[Android Software/Hacking General [Developers Only]] MWisBest:
The -W(no-)error flags don't magically make problems disappear. They only change whether or not the compiler ignores the error and keeps on trucking along or stops when there's a problem. If it actually fixed a problem I could probably write C/C++ code without any semicolons at the end of a line so long as I used -Wno-error, but that just isn't the case.

If it truely didn't build the file with -fstrict-aliasing, then there would be no problem with me using the pragma to disable -fstrict-aliasing right in the source file itself, but GCC instead has to ignore that pragma by design because it just isn't capable of switching it on and off on a per-file basis.

Go have a look at Linaro's git. They have done plenty of work on GCC as everybody knows by now, but yet you'll see them using -fno-strict-aliasing in some sections that just aren't fixable (frameworks/base/core is a good example). These are developers that IIRC are basically employees. They've flown thousands of miles to different countries just to speak at a conference. They wouldn't be doing that if they didn't know stuff like this.

I agree that there are some interesting flags here, but also like you I agree there's gotta be true statistics and testing behind something like this.

The 6x speed increase claimed here is completely untrue. Look at all the things Linaro does versus this, and they've only gone as far as saying a 100% (2x) improvement, and they had done actual testing.

I agree that -O3 on Thumb isn't ideal, but overall it's just faster. Disabling the size-increasing optimizations while using -O3? You might as well use -Os, everything from -O3 increases size.

Regardless of what optimization level is used on Thumb, Thumb will still be more efficient on register usage etc. as it's simply designed as an instruction set as a whole to do so (IMO)!
[Android Software/Hacking General [Developers Only]] PrimeDirective:
There must be some regressions somewhere using -O3 flags because i logged a 17% increase in mean benchmark scores on 3 different devices using -Os for thumb with 30 repetitions each in quadrant. wayyyy more than necessary to prove a positive impact on a 95% confidence interval :P

---------- Post added at 10:27 PM ---------- Previous post was at 10:26 PM ----------

Maybe. It's not improving the code and coudl likely introduce errors/regressions that are "swept under the rug" building fstrict with Wno-error=strict-aliasing though. most of those flags aren't designed to be used globally on a project of this scale.
[Android Software/Hacking General [Developers Only]] DJLamontagneIII:
I'm trying to reproduce the play store issue with linaro 4.8 on my moto x, Is it a constant thing or just randomly acts up? Also anyone able to compile there kernel just fine with 4.8 linaro but won't boot with 4.9?... I've usually has issues from 4.7 to 4.8 but not 4.8 to 4.9.
[Android Software/Hacking General [Developers Only]] JustArchi:
https://bugs.launchpad.net/linaro/+bug/1332989

Still unresolved.
[Android Software/Hacking General [Developers Only]] DJLamontagneIII:
I don't have a playstore issue with the latest 4.8 on your git. I'm trying to figure out if its working from a difference in our flags or a commit I have that resolves the issue.
[Android Software/Hacking General [Developers Only]] JustArchi:
This means that you're not using Linaro probably. Everybody has them.
[Android Software/Hacking General [Developers Only]] DJLamontagneIII:
Most definitely using linaro 4.8 for both kernel and rom. I'm not exactly new at this.
[Android Software/Hacking General [Developers Only]] JustArchi:
Are you sure that you have correct GCC version, not using strange envsetup hacks and proper paths? I can't believe that it magically resolved itself, especially because my git branches weren't updated for a while.
[Android Software/Hacking General [Developers Only]] DJLamontagneIII:
I wouldn't say its magic, There are many different variables we all don't have the same strict anilising fix's (Fix's not just turning strict off), I don't use the exact flags as you, possibly my device being caf based.
[Android Software/Hacking General [Developers Only]] JustArchi:
Flags aren't connected with playstore icons. I tried with both full optimization flags and none. Same results. If it would be optimization problem I'd dealt with it months ago.
[Android Software/Hacking General [Developers Only]] judas1977:
Hmm... I wanted to compile old SlimBean 4.2 with V2 (v3 has too many conflicts with sources so i wanted to test v2 first), but at the beginning, i encountered strange bug...:

host C: libz <= external/zlib/crc32.c
host C: libz <= external/zlib/deflate.c
host C: libz <= external/zlib/gzclose.c
host C: libz <= external/zlib/gzlib.c
external/zlib/x86/adler32.c: Assembler messages:
external/zlib/x86/adler32.c:255: Error: symbol `sse2_chop' is already defined
external/zlib/x86/adler32.c:623: Error: symbol `mmx_chop' is already defined
make: *** [/home/batlin/android/slim/out/host/linux-x86/obj/STATIC_LIBRARIES/libz_intermediates/adler32.o] Error 1

Strange thing - in those lines there is no mention about any sse2_chop or mmx_chop, just some variables:

#if defined(__ELF__) && !defined(__clang__)

# ".subsection 2\n\t"

#else

"jmp	7f\n\t"

#endif

Any solution, anybody? ^^
[Android Software/Hacking General [Developers Only]] micr0g:
No problem with linaro here too.i have build succesful 3 different roms with 4.8 linaro from your github.
[Android Software/Hacking General [Developers Only]] JustArchi:
Strange, I'll need to retest. Did you use 4.8 branch?
[Android Software/Hacking General [Developers Only]] micr0g:
Yes sir!
[Android Software/Hacking General [Developers Only]] KcLKcL:
Nice, I may try Linaro 4.8. GCC 4.8 gives me FC on Lens Blur lol. So I'm back with Linaro 4.7 and it worked fine.
[Android Software/Hacking General [Developers Only]] bigsupersquid:
disregard
[Android Software/Hacking General [Developers Only]] fusionjack:
i tried latest sm 4.9.1 on 4.3.1 and i also have play store graphic issue but not with old sm 4.9.0.

it is probably like DJ said, somewhere in the code is the culprit.

at least on my case, the graphic issue is effecting other app as well, for example candy crush saga. it closes by itself after some seconds without fc.

i saw in logcat, it could have something to do with opengl. perhaps we could start hunting in this area...just my two cents.
[Android Software/Hacking General [Developers Only]] JustArchi:
Funny thing is that it happens on all O* levels, including Os. I think we must wait for new Android L to arrive before we'll be able to track down this issue. I'd say that GCC in newer versions has some regression and wrongly parses some legacy code, if we're lucky, Google might faced this error and fixed it by now.
[Android Software/Hacking General [Developers Only]] F4k:
[MENTION=5161352]JustArchi[/MENTION] I can confirm that playstore glitch is not present but no using your optimizations.

I'm using Strict Aliasing=3, -O3 cflag and many others opt flags, but I have to fix many things using -fno-strict-aliasing

And yes, I'm using your Linaro 4.8.3 toolchain I can confirm this by viewing comment section of any of my compiled bin or lib files.

This is for example comment section of binary file fsck.f2fs
[Android Software/Hacking General [Developers Only]] JustArchi:
Okay I'm not saying it's impossible but other people totally not connected with my optimizations report similar issues on launchpad, and I also reproduced this problem with stock flags as well.

I'm compiling a test version right now, perhaps CM fixed something, we'll see.
[Android Software/Hacking General [Developers Only]] JustArchi:
Good news, you were right. Latest CM with PlayStore 4.8.22 compiled with Linaro 4.8 from my github doesn't cause weird playstore issues anymore :victory:.

I'll test 4.9 soon.
[Android Software/Hacking General [Developers Only]] JustArchi:
Okay, now it's random :eek:. It sometimes happen, sometimes not, for various users.
[Android Software/Hacking General [Developers Only]] DJLamontagneIII:
It is random. The other day I thought it was possibly a fix from CM or Caf in my motoX source that was fixing it so I fired up a AOSP build for my N7 flo and no play store glitches.

Sent from my XT1053
[Android Software/Hacking General [Developers Only]] kidkoala_uk:
Yeah tried both Linaro 4.8 and GCC 4.8 for hammerhead and getting the same issue with lens blur, Not sure about Sabermod I'll give this a go next.

[MENTION=5161352]JustArchi[/MENTION] also getting playstore glitch on Linaro 4.8.

Edit: Sabermod 4.8 also has the lens blur issue but the playstore glitch seems to be OK but this could be random. I can live with the lens blur so going to stick with Sabermod 4.8 for now I think.
[Android Software/Hacking General [Developers Only]] micr0g:
I start to believe that i'm doing something wrong lol.

Because i build for Hammerhead too,4 different roms with Linaro (i also tried google's and SM) and i never had any of these problems.
[Android Software/Hacking General [Developers Only]] kidkoala_uk:
Have you messed with any of JustArchi's O3 Flags? If not then you should have at least got a compile error on mm_camera.o using GCC 4.8 Toolchain.

You could find what it has compiled with by installing GHex and opening a bin file that you extract from your ROM for eg dex2oat gives me this on

Linaro 4.8 GCC: (Linaro GCC 4.8-2014.04-1~dev) 4.8.3 20140401 (prerelease)

On GCC 4.8 it shows this GCC: (GNU) 4.8

On Sabermod it shows this GCC: (UBER-SaberMod-4.8.4_android-graphite) 4.8.4 20140527 (prerelease)
[Android Software/Hacking General [Developers Only]] micr0g:
The only change is on target thumb I have Os and not O3,so I can compile without any errors.
[Android Software/Hacking General [Developers Only]] kidkoala_uk:
You can change the flag back to O3 and use these commits and it should fix your compile error.

https://github.com/VanirAOSP/hardware_qcom_camera/commit/2d8189014e648501c8dc93ff108759c6eeda88f2

https://github.com/VanirAOSP/hardware_qcom_camera/commit/4913c01931b39f82c6c3f3bdac0e84910753497d
[Android Software/Hacking General [Developers Only]] mastero9017:
Did someone make a personal AOSPA build for hammerhead with all of this optimizations?
[Android Software/Hacking General [Developers Only]] micr0g:
https://www.mediafire.com/folder/howua3sk4m5k4/PA
[Android Software/Hacking General [Developers Only]] mastero9017:
Thanks! You build regular?