GCC 10.3 Bugfix 1 - Constant literal address fix by earlephilhower · Pull Request #8393 · esp8266/Arduino (original) (raw)
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Fixes a hard-to-track bug in GCC 10.x.
earlephilhower/newlib-xtensa#19
GCC 10.3 had an issue with addressing constant literals which would result
in crazy offsets being used and random crashes in production. Update
with an upstream GCC 11 bugfix.
Fixes esp8266#8314 and other hard-to-track bugs.
GCC 10.3 had an issue with addressing constant literals which would result in crazy offsets being used and random crashes in production. Update with an upstream GCC 11 bugfix.
mcspr added a commit to xoseperez/espurna that referenced this pull request
TD-er added a commit to TD-er/ESPEasy that referenced this pull request
This was referenced
Dec 20, 2021
@mcspr , I see your PIO package for this (mcspr/toolchain-xtensa @ ~5.100300.211127). Would it be possible to upload the binaries for 'darwin_arm64'?
@mcspr , So it's the exact same files from the release packaged for PIO? Wonder how I tell my M1 MAC to just use the x64 intel version and virtualize it with Rosetta??
Do you know why the default pckage works fine on the M1 MAC but this toolchain does not and instead errors out on could not find darwin_arm64?
Hmm... The registry payload returns x86_64 version for both, I suppose package.json was modified to include it
{ "checksum": {"sha256": "0a40e1cc5f6f9cedd85d3d4dac548bfb5535c015c40cb10a7755f7dbd3f1db4c"}, "download_url": "https://dl.registry.platformio.org/download/platformio/tool/toolchain-xtensa/2.100300.210717/toolchain-xtensa-darwin_x86_64-2.100300.210717.tar.gz", "name": "toolchain-xtensa-darwin_x86_64-2.100300.210717.tar.gz", "size": 75089523, "system": ["darwin_x86_64", "darwin_arm64"] }
For a follow-up, does darwin_arm64 arch work now?
(ref. registry api response, there is now a special version with a +darwin suffix. I assume that will work, but I wonder if it needed to be a real version bump)
It does work now! Did that GCC build require manual patching? How should I regard the integrity of this compiler vs some of the other OS compilers? Won't they all generate slightly different firmware binary since they're different GCC binaries themselves? Is any one system more reliable/trusted than another?
Just my misunderstanding of the question 🤷
It is doing x86_64 emulation, no binary differences should manifest. You can check the test script in the linked issue if you want to check for this specific problem.
The repo above was about actual darwin_arm64 binaries possibility, but that's going to happen some time in the future.
mcspr added a commit to mcspr/platform-espressif8266 that referenced this pull request
valeros pushed a commit to platformio/platform-espressif8266 that referenced this pull request
hasenradball pushed a commit to hasenradball/Arduino that referenced this pull request
Labels
included in alpha release