| Summary: | www-client/chromium-38.0.2125.66 - In file included from ../../third_party/skia/src/opts/SkBlurImage_opts_SSE4.cpp:19: /usr/lib/gcc/i686-pc-linux-gnu/4.8.3/include/pmmintrin.h:50:68: error: ‘__builtin_ia32_addsubps’ was not declared in this scope | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andrew Savchenko <bircoph> |
| Component: | Current packages | Assignee: | Chromium Project <chromium> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | bircoph |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log.xz
1-environment 1-emerge.info 2-build.log.xz 2-environment 2-emerge.info chromium-sse-libvpx-r0.patch chromium-sse-skia-r0.patch 3-build.log.xz 3-environment chromium-sse-libvpx-r0.patch chromium-sse-skia-r0.patch 38.0.2125.101-build.log.xz |
||
Created attachment 385464 [details]
build.log.xz
Created attachment 385466 [details]
1-environment
Created attachment 385468 [details]
1-emerge.info
Created attachment 385470 [details]
2-build.log.xz
Created attachment 385472 [details]
2-environment
Created attachment 385474 [details]
2-emerge.info
With USE="-custom-cflags" error persists. So *FLAGS are not an issue here. Created attachment 385564 [details, diff]
chromium-sse-libvpx-r0.patch
Hi, I was able to fix the second problem (with third_party/libvpx/source/libvpx/vp8/encoder/x86/quantize_sse4.c): sse4_1 is disabled on x86 (ia32 in chromium terms) with this patch.
However, similar fix doesn't work with skia gyp subsystem. target_arch check is ignored for unknown reason.
Created attachment 385570 [details, diff]
chromium-sse-skia-r0.patch
Good news here. I fixed skia issue on x86: unsafe optimizations disabled for ia32.
Created attachment 385572 [details]
3-build.log.xz
And bad news: v8 requires SSE2 CPU:
FAILED: cd ../../v8/tools/gyp; ../../../out/Release/mksnapshot --log-snapshot-positions --logfile ../../../out/Release/obj/v8/tools/gyp/v8_snapshot.gen/snapshot.log --random-seed 314159265 ../../../out/Release/obj/v8/tools/gyp/v8_snapshot.gen/snapshot.cc
#
# Fatal error in ../../v8/src/ia32/assembler-ia32.cc, line 54
# CHECK(cpu.has_sse2()) failed
#
Created attachment 385574 [details]
3-environment
I'll look further into this issue.
It looks like noone cares about chromium on x86 CPUs, a lot of bugs already piled up...
The issue is quite complex and consists of following cases: 1) SSE2 capable x86 (32-bit) CPU 2) Pre-SSE2 x86 (32-bit) CPU In both cases there'are SSE4 code snippets which can't be compiled in 32-bit (see build logs above): a) libvpx sse4 code b) skia sse4 code In case 2) there is additional issue: c) non-SSE2 x86 32-bit support was removed from chromium this summer, so -Ddisable_sse2=1 is just ignored now: https://codereview.chromium.org/187423002 I have no decent words to chromium upstream devs regarding this issue... As for now I was able to fix issues a) and b), thus in case 1) (e.g. on Intel Atom N270) chromium-38.0.2125.66 was build and runs successfully. See patches below, previous patches are incomplete (they fix only compilation, but not linking). Proposed patches remove SSE4 code when target arch is 32-bit x86, it can't be compiled in 32-bit mode anyway. There is one issue, however: tcmalloc must be disabled, otherwise chromium segfaults. This problem is not related to proposed patches since I have it on 32-bit hosts since this USE flag was added. (On 64-bit machines it works fine). As for the issue c) and solution for the case 2), I'm still in the process. Probably following work will help: https://github.com/graysky2/chromium-no-sse2-patch Created attachment 385624 [details, diff]
chromium-sse-libvpx-r0.patch
Fix for issue a) — disable libvpx SSE4 code on x86.
Created attachment 385626 [details, diff]
chromium-sse-skia-r0.patch
Fix for issue b) — disable skia SSE4 code on x86.
Are you still able to reproduce this? Hello, Yes, I am, the bug is still here. With patches above I'm able to compile and use chromium on SSE2 x86 host (Intel Atom N270). On Athlon-XP system (non-SSE2 x86) I still can't use chromium. I made a patch that allows chromium to build on this machine, but it fails with SIGILL on startup at mfence instruction. I can't debug it properly because chromium can't be linked with -g on x86. I use spare amd64 host to perform such linking (ld takes about 9 GB memory meanwhile), but the process of moving data between these host is still complicated. ATM I stopped my efforts because I already killed 6 days and only with partial success. I'll try to continue in a while. Meanwhile if someone is interested in helping with my efforts, I put patches at github: https://github.com/bircoph/chromium-no-sse2-patch/tree/master/v38 It seems that ago was able to successfully build it for testing on bug 524764, so I'm not sure why it fails here. Maybe related to gcc 4.8? Is www-client/google-chrome-38* usable for you? (In reply to Mike Gilbert from comment #18) > Is www-client/google-chrome-38* usable for you? Using vanilla ebuild from portage tree — no, it fails to build (I tried chromium-38.0.2125.101): In file included from ../../third_party/skia/src/opts/SkBlurImage_opts_SSE4.cpp:19:0: /usr/lib/gcc/i686-pc-linux-gnu/4.8.3/include/smmintrin.h: In function ‘int _mm_testz_si128(__m128i, __m128i)’: /usr/lib/gcc/i686-pc-linux-gnu/4.8.3/include/smmintrin.h:67:60: error: ‘__builtin_ia32_ptestz128’ was not declared in this scope return __builtin_ia32_ptestz128 ((__v2di)__M, (__v2di)__V); ^ See full log below. With SSE4 removal patches above it depends on x86 CPU: - on SSE2 capable system (Intel Atom N270) I can build chromium and it works fine; - on pre-SSE2 x86 CPU (AMD Athlon-XP) it fails to build due to illegal instruction (from SSE2 instruction set). ATM work on SSE2 removal patch is suspended as I have to deal with some hardware issues. I also plan to try with chromium-39. But browser's build, patching and debugging on such old systems takes enormous amounts of time (even with ccache and distcc), so don't expect results early. Created attachment 386784 [details]
38.0.2125.101-build.log.xz
Build log for 38.0.2125.101 from tree (without patches) on Intel Atom N270 (emerge.info was posted above).
(In reply to Mike Gilbert from comment #17) > It seems that ago was able to successfully build it for testing on bug > 524764, so I'm not sure why it fails here. Maybe related to gcc 4.8? Perhaps... but maybe related to _how_ it was build. If SSE4 capable CPU target was used (e.g. -march=native on such host or in 32-bit chroot), then it is understandable why build was successful. (In reply to Andrew Savchenko from comment #19) > (In reply to Mike Gilbert from comment #18) > > Is www-client/google-chrome-38* usable for you? > > Using vanilla ebuild from portage tree — no, it fails to build (I tried > chromium-38.0.2125.101): That's not what I asked. I asked about google-chrome, which is a pre-built binary. I want to know if you get runtime failures with that. As far as I can tell, -march=native seems to work fine so long as the build system also passes -msse4.1. For example, on my AMD Phenom II, which does not support SSE 4.1, I ran the following test:
% cat test-sse4.c
#include <smmintrin.h>
int main(void) { return 0; }
% gcc -march=native -c test-sse4.c
In file included from test-sse4.c:1:0:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/smmintrin.h:31:3: error: #error "SSE4.1 instruction set not enabled"
# error "SSE4.1 instruction set not enabled"
^
% gcc -msse4.1 -march=native -c test-sse4.c
[no error]
So something really weird is happening on your system if that doesn't work.
One other thing I note is that you are using distcc in combination with -march=native. I think that may cause some strange behavior.
Hi, (In reply to Mike Gilbert from comment #22) > That's not what I asked. I asked about google-chrome, which is a pre-built > binary. I want to know if you get runtime failures with that. 1) On pre-SSE2 host (Athlon-XP) google-chrome-38.0.2125.104_p1 shows xmessage error window: This computer can no longer run Google Chrome because its hardware is no longer supported. With only "okay" button. No, this is not okay at all, but as of chrome-35 upstream removed pre-SSE2 x86 support as I mention in comment #12: https://codereview.chromium.org/187423002 2) On SSE2 x86 host (Atom N270) it seems to work. Though obviously I can't test all possible code paths for SIGILL issues. I can't reproduce your SSE4-related build failures (see comment 23), and I don't think we want to carry patches for pre-SSE2 support. If you can get upstream to support it, that's a different story. I don't think there is any bug in the Gentoo packaging. (In reply to Mike Gilbert from comment #25) > I can't reproduce your SSE4-related build failures (see comment 23) Test case there is for a different issue. > and I don't think we want to carry patches for pre-SSE2 support. Right now there are no good working patches, but if they'll be ready, why not? At least please add something like sse2 check (e.g. as in adobe-flash) so that people will not waste time on this browser. > If you can get upstream to support it, that's a different story. I'm afraid this is impossible. Anyway NPAPI support was removed too starting from version 35, thus chromium value as a browser diminishes significatly, since there is no way now to use java plugins which I unfortunately need for my job (hp ilo, cisco ucs). > I don't think there is any bug in the Gentoo packaging. There are no bug in Gentoo packaging, but Gentoo packages quite often include fixes for upstream issues they don't care about. (In reply to Andrew Savchenko from comment #26) > (In reply to Mike Gilbert from comment #25) > > I can't reproduce your SSE4-related build failures (see comment 23) > > Test case there is for a different issue. The available registers on your CPU should not cause a build-time failure. Again, I think this is some configuration issue on your system. Please do some testing to figure out what is causing that. It should not require patching to resolve. I would start by disabling distcc, and possibly ccache. (In reply to Andrew Savchenko from comment #26) > (In reply to Mike Gilbert from comment #25) > > I can't reproduce your SSE4-related build failures (see comment 23) > > Test case there is for a different issue. I was unable to reproduce any of the issues. This may need more info about what is required to reproduce. > > and I don't think we want to carry patches for pre-SSE2 support. > > Right now there are no good working patches, but if they'll be ready, why > not? Any custom patch we apply in chromium ebuild reduces maintainability. With upstream moving very fast (~200 changes per *day*) such patches often need to be rebased or even rewritten, sometimes even becoming absolutely infeasible. If you're *really* willing and committed to make Chromium work on pre-SSE2 systems, consider talking directly to upstream. > At least please add something like sse2 check (e.g. as in adobe-flash) so > that people will not waste time on this browser. Could you more specifically describe a check you'd expect the ebuild to perform? I couldn't find anything obvious in the adobe-flash ebuild. > > If you can get upstream to support it, that's a different story. > > I'm afraid this is impossible. For me this is actually another point against it. I'd like to support as many users and systems as possible, but the problem is with the "possible" (or feasible) part. There is only so much time we can spend on packaging, and Chromium is already quite maintenance-heavy IMHO. > Anyway NPAPI support was removed too starting from version 35, thus chromium > value as a browser diminishes significatly, since there is no way now to use > java plugins which I unfortunately need for my job (hp ilo, cisco ucs). This is off-topic for this bug, and yes, I wish Chromium could support these use cases better. It's significant work though that somebody would have to do. > > I don't think there is any bug in the Gentoo packaging. > > There are no bug in Gentoo packaging, but Gentoo packages quite often > include fixes for upstream issues they don't care about. I'd be interested in specific examples. Generally patches that are not strictly necessary are at least controversial. |
Hello, chromium fails to build on x86 hosts (two different machines with different setups). Error messages are slightly different, but commont point is that SSE4-related code fails to build (no wonder, since x86 just don't have appropriate registers). This code shouldn't be built in the first place. On first system: In file included from /usr/lib/gcc/i686-pc-linux-gnu/4.8.3/include/tmmintrin.h:35:0, from /usr/lib/gcc/i686-pc-linux-gnu/4.8.3/include/smmintrin.h:36, from ../../third_party/skia/src/opts/SkBlurImage_opts_SSE4.cpp:19: /usr/lib/gcc/i686-pc-linux-gnu/4.8.3/include/pmmintrin.h: In function ‘__m128 _mm_addsub_ps(__m128, __m128)’: /usr/lib/gcc/i686-pc-linux-gnu/4.8.3/include/pmmintrin.h:50:68: error: ‘__builtin_ia32_addsubps’ was not declared in this scope return (__m128) __builtin_ia32_addsubps ((__v4sf)__X, (__v4sf)__Y); ^ [and so on, long listing] On second system: In file included from ../../third_party/libvpx/source/libvpx/vp8/encoder/x86/quantize_sse4.c:12:0: /usr/lib/gcc/i686-pc-linux-gnu/4.8.3/include/smmintrin.h: In function ‘_mm_round_pd’: /usr/lib/gcc/i686-pc-linux-gnu/4.8.3/include/smmintrin.h:100:3: error: can’t convert between vector values of different size return (__m128d) __builtin_ia32_roundpd ((__v2df)__V, __M); ^ [and so on, long listing] Full build logs follows... I'll try to remove custom cflags and see what happens.