clang doesn't produce code deterministically in nsMediaFragmentURIParser::ParseNPTFraction
Categories
(Firefox Build System :: Toolchains, defect)
Tracking
(Not tracked)
People
(Reporter: glandium, Unassigned)
References
(Blocks 1 open bug)
Details
In 2 builds out of the 6 retriggers I did with the patch from bug 1577212 applied, the condition if (index > 1) in nsMediaFragmentURIParser::ParseNPTFraction was compiled as
95e075:» 83·fb·02·············» cmp····$0x2,%ebx
95e078:» 73·80················» jae····95dffa·<mozilla::net::nsMediaFragmentURIParser::ParseNPTFraction(nsTDependentSubstring<char16_t>&,·double&)+0x7a>
while it's usually compiled as
95e075:» 83·fb·01·············» cmp····$0x1,%ebx
95e078:» 77·80················» ja·····95dffa·<mozilla::net::nsMediaFragmentURIParser::ParseNPTFraction(nsTDependentSubstring<char16_t>&,·double&)+0x7a>
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 1•5 years ago
|
||
A build of the more usual variant:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Hq98vfPBT6SZGCz9GWMJdA/runs/0/artifacts/public/build/target.tar.bz2
A build of the other variant:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/OA_xWiJgT5GIscQDTjHiUg/runs/0/artifacts/public/build/target.tar.bz2
|
|
Reporter | |
Comment 2•5 years ago
|
||
This seems to be a regression between clang 8.0 and 9.0. Why? Because I can reproduce the same issue with FF70 with clang 9.0, while it didn't happen with clang 8.0.
To save others from searching:
A build of the more usual variant:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Hq98vfPBT6SZGCz9GWMJdA/runs/0/artifacts/public/build/target.tar.bz2
A build of the other variant:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/OA_xWiJgT5GIscQDTjHiUg/runs/0/artifacts/public/build/target.tar.bz2
|
|
Reporter | |
Comment 4•4 years ago
|
||
It seems like this is not happening anymore.
Description
•