Page MenuHomeSolus

Update to GCC to 9.2.0
AbandonedPublic

Authored by joebonrichie on Aug 2 2019, 6:10 PM.
Tags
None
Tokens
"100" token, awarded by xulongwu4."Like" token, awarded by chax."Mountain of Wealth" token, awarded by kyrios123."Party Time" token, awarded by livingsilver94."Love" token, awarded by Jacalz.

Details

Summary

Note: The initial bootstrap will be staticly linked against isl, mpfr, etc. This is the rebootstrap.

Changelog

Signed-off-by: Joey Riches <josephriches@gmail.com>

Test Plan

Rebuilt glibc, binutils, isl, mpfr, gmp, mpc, mesa, libreoffice lto against this
Compiled and tested basic examples e.g. hello world, for loops, etc.
Tested mesa and LO before and after rebuilds

Diff Detail

Repository
R872 gcc
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage

Event Timeline

joebonrichie created this revision.Aug 2 2019, 6:10 PM
joebonrichie requested review of this revision.Aug 2 2019, 6:10 PM
Jacalz awarded a token.Aug 2 2019, 6:24 PM

Also ran some quick benchmarks via graphicsmagick, imagemagick and openjpeg via libpng to check if there weren't any obvious performance regressions in libgcc. Maybe not the most ideal but these are what came to mind as i've been testing libpng decode perf recently.

GraphicsMagick
gm -benchmark -iterations 10 convert pts-toronto-10mb.png -minify null
gcc8: Results: 4 threads 10 iter 11.93s user 11.41s total 0.876 iter/s 0.838 iter/cpu
gcc9: Results: 4 threads 10 iter 11.93s user 11.42s total 0.876 iter/s 0.838 iter/cpu

ImageMagick
convert -bench 10 pts-toronto-10mb.png -resize 1920x1080 /dev/null

gcc8:

Performance[1]: 10i 0.704ips 1.000000e 14.210000u 0:14.207
Performance[2]: 10i 0.837ips 0.543149e 14.210000u 0:11.950
Performance[3]: 10i 0.893ips 0.559163e 14.270000u 0:11.201
Performance[4]: 10i 0.914ips 0.564972e 14.490000u 0:10.939

gcc9:

Performance[1]: 10i 0.701ips 1.000000e 14.260000u 0:14.256
Performance[2]: 10i 0.833ips 0.542760e 14.290000u 0:12.010
Performance[3]: 10i 0.889ips 0.558901e 14.370000u 0:11.251
Performance[4]: 10i 0.914ips 0.565716e 14.510000u 0:10.944

OpenJPEG
opj_compress -i pts-toronto-10mb.png -o out.j2k (x10 averaged)
gcc8: encode time: 2150 ms
gcc9: encode time: 2147 ms

isl rebuilds are done and tested for GCC AVR and GCC ARM. Compiled some basic programs for ARM and AVR targets. Though I don't have any hardware to actually test them on. Also updated GCC ARM and GCC AVR to version GCC 9 for additional testing. Successfully compiled some basic examples for ARM and AVR targets once again. So it'll be greatly appreciated if the original submitter @chax could look at updating GCC AVR and ARM and look for any bug fixes need backporting from the GCC 9 branch when this get merged.

chax added a comment.Aug 4 2019, 12:01 AM

@joebonrichie thanks for testing ARM and AVR crosscompilers with new GCC. I saw that you submitted this patch and i was planning to do the same for ARM and AVR. I can test easily for ARM because my mechanical keyboard is using ARM microcontroller (STM32) so i can just rebuild firmware (QMK) for it and upgrade it. However i don't have any AVR hardware at hand but i think any Arduino board can be used for testing, and i'll do that when i find some time.

chax awarded a token.Aug 4 2019, 12:01 AM
chax added a comment.Aug 4 2019, 6:12 PM

@joebonrichie i rebuilt avr-gcc and arm-none-eabi-gcc packages with new gcc 9.1.0 source and did a bit of tesing. I successfully compiled and flashed some Arduino examples and they work. Then i tried to build QMK firmware for few different boards. For AVR i successfully compiled firmware but it turns out that resulting binary is a bit larger and it exceeds maximum flash size because of that. I don't have any AVR based board at hand so i couldn't test flashing that firmware (after removing features to make it fit flash size). However for ARM based board i couldn't even compile. QMK probably hasn't migrated code to be compilable with newer gcc and i have seen several reports on their repo about this problem. So, based on these test results i am reluctant to update those gcc versions to 9.1.0 for now. BTW i built those with older gcc (currently available in repos) and i am not sure if i would get different result by using your updated version.

gfortran rebuilds are done as requested by DataDrake. There was a bit of trouble with scipy via numpy and plplot needed an update, but the rest were smooth sailing. I couldn't find anything in the repo that directly links against the address sanitizers so that deleted symbol shouldn't be a problem (GCC is supposed to be abi forward compatible anyway). I'm in the mind that i'll let some dust settle on this and see if any issues crop up locally, then push it early next sync cycle barring any misfortune.

ermo added a subscriber: ermo.EditedAug 5 2019, 7:51 PM

@joebonrichie

gcc-9.2 is apparently just around the corner -- it might make more sense to go with that, assuming that it's mostly a bugfix release plus the SuSE-sourced zen2 optimisations from gcc-10?

If all goes well, I'd like to release 9.2 on Monday, August 12th. (source)

In D6863#108951, @ermo wrote:

@joebonrichie
gcc-9.2 is apparently just around the corner -- it might make more sense to go with that, assuming that it's mostly a bugfix release plus the SuSE-sourced zen2 optimisations from gcc-10?

If all goes well, I'd like to release 9.2 on Monday, August 12th. (source)

Not that I have a strong preference for which version we use, but the Zen2 optimizations are useless to us since we don't build binaries specifically for AMD.

ermo added a comment.Aug 6 2019, 12:47 PM
In D6863#108951, @ermo wrote:

@joebonrichie
gcc-9.2 is apparently just around the corner -- it might make more sense to go with that, assuming that it's mostly a bugfix release plus the SuSE-sourced zen2 optimisations from gcc-10?

If all goes well, I'd like to release 9.2 on Monday, August 12th. (source)

Not that I have a strong preference for which version we use, but the Zen2 optimizations are useless to us since we don't build binaries specifically for AMD.

For the sake of completeness, I actually sometimes build certain packages locally with -march=native. I'm weird that way and I completely understand if said preference is not considered a major decision driver in the larger scheme of things.

The zen2 optimizations are already in this build. Based on the included patch, it is effectively GCC 9.2.0 minus any patches that land between the day this is build and release of 9.2.0.

However, this patch will no longer build as the sha256sum of the gcc9branch changes every few hours.

The only way to make it stick is to use the latest commit from the gcc9 branch (or land immediately after updating sha256sum) i.e. https://github.com/gcc-mirror/gcc/compare/gcc-9_1_0-release...7ac249d7cdeac943feac682e553868a684b0c295.patch but is much harder to validate at a glance that this is the right commit.

My experience was that the git history was too large for using the solbuild git feature without adding the ability to do a shallow clone.

Waiting for GCC 9.2 tarballs and will update Monday/Tuesday. If tarballs are delayed it'll have to wait another sync until next Saturday.

Jacalz added a subscriber: Jacalz.Aug 10 2019, 8:56 AM
Jacalz added inline comments.
package.yml
137

Lets get this updated to getsol.us while at it, instead of me rebasing D5589 once this has landed :)

livingsilver94 added inline comments.Aug 10 2019, 9:40 AM
package.yml
5–6

I think it's also better practice to set the the URL in https.

joebonrichie retitled this revision from Update to GCC to 9.1.0 to Update to GCC to 9.2.0.

Update to 9.2.0. Address niggles.

joebonrichie abandoned this revision.Aug 13 2019, 6:40 PM

Pushing manually to bootstrap properly.