Bug#972004: Assembly code not working for mips64el and ppc64el (Was: Bug#972004: bowtie ftbfs on several release architectures)
Hi Andreas, Note I ended pushing some changes to the repository after some more verifications yesterday. Andreas Tille, on 2020-10-13 09:06:52 +0200: > H, may be I should remove third_party/cpuid.h in general? > Given its copyright informazion is > Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc. > that seems to be a pretty old copy of this file. I can confirm excluding third_party/cpuid.h does the job. > > > [1] > > > https://salsa.debian.org/med-team/bowtie/-/blob/master/debian/patches/popcnt_capability.patch > > > > As a side note, I believe that the $(filter ...) statement added > > in the patch to be able to list architectures reverted the > > logic, so replaced the ifeq (...) statement to an ifneq (...). > > > > Most changes are available on my machine. I would have > > suggested to push them, but my build targeting mips64el failed > > and it seems that its because `uname -m` returns mips64 on that > > architecture. I'm not 100% sure of the name for the other > > architectures, maybe listing CPUs handling popcnt might be > > simpler ? > > > > Anyway in hope any of these ideas helps... > > Would you mind sending a `git diff` to make sure I fully > understood what you mean? The diff below shows what I pushed to salsa yesterday; it is a bit different from my statement in my email, as I filter out x86_64 for setting POPCNT_CAPABILITY=0 instead of listing architectures that do not have this available: ---8<--8<--8<--8<--- commit ebb4152dc649d63bec2360a21bd909f1d4a44d2a Author: Étienne Mollier Date: Mon Oct 12 23:43:50 2020 +0200 reviewed debian/patches/popcnt_capability diff --git a/debian/patches/popcnt_capability.patch b/debian/patches/popcnt_capability.patch index eb0ae56..863c936 100644 --- a/debian/patches/popcnt_capability.patch +++ b/debian/patches/popcnt_capability.patch @@ -1,6 +1,7 @@ Description: Set POPCNT_CAPABILITY=0 for more architectures than just aarch64 Bug-Debian: https://bugs.debian.org/972004 Author: Andreas Tille +Reviewed-By: Étienne Mollier Last-Update: Mon, 12 Oct 2020 11:29:03 +0200 --- a/Makefile @@ -10,7 +11,7 @@ Last-Update: Mon, 12 Oct 2020 11:29:03 +0200 POPCNT_CAPABILITY ?= 1 -ifeq (aarch64,$(shell uname -m)) -+ifeq (,$(filter $(shell uname -m), aarch64 alpha mips64el ppc64 ppc64el risc64 sparc64 x32)) ++ifeq (,$(filter $(shell uname -m), x86_64)) POPCNT_CAPABILITY=0 endif ifeq (1, $(POPCNT_CAPABILITY)) ---8<--8<--8<--8<--- If you think some more architectures can make use of popcnt, they can be appended next to x86_64. If you want to make sure the option is applied, check the build log, the compilation command should show -DPOPCNT_CAPABILITY. Have a nice day, -- Étienne Mollier Old rsa/3072: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d New rsa/4096: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/tty1, please excuse my verbosity. signature.asc Description: PGP signature
Bug#972004: Assembly code not working for mips64el and ppc64el (Was: Bug#972004: bowtie ftbfs on several release architectures)
Hi Étienne,
On Mon, Oct 12, 2020 at 10:22:39PM +0200, Étienne Mollier wrote:
> > 162 | __cpuid (__ext, __eax, __ebx, __ecx, __edx);
> > | ^~~
> > third_party/cpuid.h:103:3: error: impossible constraint in ‘asm’
> > 103 | __asm__ ("cpuid\n\t" \
> > | ^~~
> > third_party/cpuid.h:185:3: note: in expansion of macro ‘__cpuid’
> > 185 | __cpuid (__level, *__eax, *__ebx, *__ecx, *__edx);
> > | ^~~
> > In file included from ebwt_build.cpp:8:
> > ...
> >
> > Any idea how to deal with this?
>
> I believe that cpuid.h is an architecture specific header, but
> the upstream source code ships with a custom third_party/cpuid.h
> which probably mainly targets amd64, hence issues on non amd64.
>
> I ran an arm64 build a few minutes ago, after having excluded
> third_party/. This way, the source code gently failed back to
> the system provided cpuid.h which should be always be
> appropriate. My build went through on arm64, as well as the
> test suite.
H, may be I should remove third_party/cpuid.h in general?
Given its copyright informazion is
Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
that seems to be a pretty old copy of this file.
> > [1]
> > https://salsa.debian.org/med-team/bowtie/-/blob/master/debian/patches/popcnt_capability.patch
>
> As a side note, I believe that the $(filter ...) statement added
> in the patch to be able to list architectures reverted the
> logic, so replaced the ifeq (...) statement to an ifneq (...).
>
> Most changes are available on my machine. I would have
> suggested to push them, but my build targeting mips64el failed
> and it seems that its because `uname -m` returns mips64 on that
> architecture. I'm not 100% sure of the name for the other
> architectures, maybe listing CPUs handling popcnt might be
> simpler ?
>
> Anyway in hope any of these ideas helps...
Would you mind sending a `git diff` to make sure I fully
understood what you mean?
Kind regards
Andreas.
--
http://fam-tille.de
Bug#972004: Assembly code not working for mips64el and ppc64el (Was: Bug#972004: bowtie ftbfs on several release architectures)
Hi Andreas,
Andreas Tille, on 2020-10-12 17:56:38 +0200:
> third_party/cpuid.h:103:3: error: impossible constraint in ‘asm’
> 103 | __asm__ ("cpuid\n\t" \
> | ^~~
> third_party/cpuid.h:162:3: note: in expansion of macro ‘__cpuid’
> 162 | __cpuid (__ext, __eax, __ebx, __ecx, __edx);
> | ^~~
> third_party/cpuid.h:103:3: error: impossible constraint in ‘asm’
> 103 | __asm__ ("cpuid\n\t" \
> | ^~~
> third_party/cpuid.h:185:3: note: in expansion of macro ‘__cpuid’
> 185 | __cpuid (__level, *__eax, *__ebx, *__ecx, *__edx);
> | ^~~
> In file included from ebwt_build.cpp:8:
> ...
>
> Any idea how to deal with this?
I believe that cpuid.h is an architecture specific header, but
the upstream source code ships with a custom third_party/cpuid.h
which probably mainly targets amd64, hence issues on non amd64.
I ran an arm64 build a few minutes ago, after having excluded
third_party/. This way, the source code gently failed back to
the system provided cpuid.h which should be always be
appropriate. My build went through on arm64, as well as the
test suite.
> [1]
> https://salsa.debian.org/med-team/bowtie/-/blob/master/debian/patches/popcnt_capability.patch
As a side note, I believe that the $(filter ...) statement added
in the patch to be able to list architectures reverted the
logic, so replaced the ifeq (...) statement to an ifneq (...).
Most changes are available on my machine. I would have
suggested to push them, but my build targeting mips64el failed
and it seems that its because `uname -m` returns mips64 on that
architecture. I'm not 100% sure of the name for the other
architectures, maybe listing CPUs handling popcnt might be
simpler ?
Anyway in hope any of these ideas helps...
Kind Regards,
--
Étienne Mollier
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
signature.asc
Description: PGP signature
Processed (with 1 error): Re: Bug#972004: Assembly code not working for mips64el and ppc64el (Was: Bug#972004: bowtie ftbfs on several release architectures)
Processing control commands:
> reopen -a
Unknown command or malformed arguments to command.
> tags -1 help
Bug #972004 {Done: Andreas Tille } [src:bowtie] bowtie ftbfs
on several release architectures
Ignoring request to alter tags of bug #972004 to the same tags previously set
--
972004: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972004
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#972004: Assembly code not working for mips64el and ppc64el (Was: Bug#972004: bowtie ftbfs on several release architectures)
Control: reopen -a
Control: tags -1 help
On Mon, Oct 12, 2020 at 02:50:41PM +0500, Andrey Rahmatullin wrote:
> > while I've fixed the issue for arm64 the new version of bowtie seems to
> > have some new assembly code where mips64el, ppc64el and others are
> > stumbling upon [1]:
> The reason it works on arm64 is
>
> ifeq (aarch64,$(shell uname -m))
> POPCNT_CAPABILITY=0
> endif
>
> in Makefile. It's clearly not supposed to run on anything else non-Intel
> but you can try patching this to also disable popcnt on other non-Intel.
My patch [1] worked for ppc64el and s390x. However for arm64 (and others)
a new build error occures:
...
In file included from ebwt_build.cpp:8:
ds.h: In function ‘void mkeyQSortSuf2(const T&, size_t, TIndexOffU*, size_t,
TIndexOffU*, int, size_t, size_t, size_t, size_t, EList*)
[with T = S2bDnaString]’:
ds.h:497:3: warning: ‘tmp2’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
497 | list_[cur_++] = el;
| ^
ds.h:497:3: warning: ‘tmp3’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
497 | list_[cur_++] = el;
| ^
ds.h:497:3: warning: ‘tmp4’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
497 | list_[cur_++] = el;
| ^
In file included from processor_support.h:17,
from ebwt.h:41,
from ebwt_build.cpp:10:
third_party/cpuid.h: In constructor ‘Ebwt::Ebwt(TStr, bool, int32_t, int32_t,
int32_t, int32_t, int32_t, int, const string&, bool, bool, TIndexOffU,
TIndexOffU, TIndexOffU, int, EList&, EList&,
EList&, TIndexOffU, const RefReadInParams&, uint32_t, int32_t,
int32_t, bool, bool, bool, bool) [with TStr = S2bDnaString]’:
third_party/cpuid.h:103:3: error: impossible constraint in ‘asm’
103 | __asm__ ("cpuid\n\t" \
| ^~~
third_party/cpuid.h:162:3: note: in expansion of macro ‘__cpuid’
162 | __cpuid (__ext, __eax, __ebx, __ecx, __edx);
| ^~~
third_party/cpuid.h:103:3: error: impossible constraint in ‘asm’
103 | __asm__ ("cpuid\n\t" \
| ^~~
third_party/cpuid.h:185:3: note: in expansion of macro ‘__cpuid’
185 | __cpuid (__level, *__eax, *__ebx, *__ecx, *__edx);
| ^~~
In file included from ebwt_build.cpp:8:
...
Any idea how to deal with this?
Kind regards
Andreas.
[1]
https://salsa.debian.org/med-team/bowtie/-/blob/master/debian/patches/popcnt_capability.patch
--
http://fam-tille.de
Bug#972004: Assembly code not working for mips64el and ppc64el (Was: Bug#972004: bowtie ftbfs on several release architectures)
On Mon, Oct 12, 2020 at 11:36:36AM +0200, Andreas Tille wrote: > Control: tags -1 help > > Hi, > > while I've fixed the issue for arm64 the new version of bowtie seems to > have some new assembly code where mips64el, ppc64el and others are > stumbling upon [1]: The reason it works on arm64 is ifeq (aarch64,$(shell uname -m)) POPCNT_CAPABILITY=0 endif in Makefile. It's clearly not supposed to run on anything else non-Intel but you can try patching this to also disable popcnt on other non-Intel. -- WBR, wRAR signature.asc Description: PGP signature
Bug#972004: Assembly code not working for mips64el and ppc64el (Was: Bug#972004: bowtie ftbfs on several release architectures)
Control: tags -1 help Hi, while I've fixed the issue for arm64 the new version of bowtie seems to have some new assembly code where mips64el, ppc64el and others are stumbling upon [1]: ...In file included from ebwt_build.cpp:8: ds.h: In function ‘void mkeyQSortSuf2(const T&, size_t, TIndexOffU*, size_t, TIndexOffU*, int, size_t, size_t, size_t, size_t, EList*) [with T = S2bDnaString]’: ds.h:497:3: warning: ‘tmp2’ may be used uninitialized in this function [-Wmaybe-uninitialized] 497 | list_[cur_++] = el; | ^ ds.h:497:3: warning: ‘tmp3’ may be used uninitialized in this function [-Wmaybe-uninitialized] 497 | list_[cur_++] = el; | ^ ds.h:497:3: warning: ‘tmp4’ may be used uninitialized in this function [-Wmaybe-uninitialized] 497 | list_[cur_++] = el; | ^ ds.h: In function ‘void mkeyQSortSuf2(const T&, size_t, TIndexOffU*, size_t, TIndexOffU*, int, size_t, size_t, size_t, size_t, EList*) [with T = SString]’: ds.h:497:3: warning: ‘tmp2’ may be used uninitialized in this function [-Wmaybe-uninitialized] 497 | list_[cur_++] = el; | ^ ds.h:497:3: warning: ‘tmp3’ may be used uninitialized in this function [-Wmaybe-uninitialized] 497 | list_[cur_++] = el; | ^ ds.h:497:3: warning: ‘tmp4’ may be used uninitialized in this function [-Wmaybe-uninitialized] 497 | list_[cur_++] = el; | ^ /tmp/ccRHXYbX.s: Assembler messages: /tmp/ccRHXYbX.s:27483: Error: unrecognized opcode: `popcntq' /tmp/ccRHXYbX.s:27951: Error: unrecognized opcode: `popcntq' /tmp/ccRHXYbX.s:28493: Error: unrecognized opcode: `popcntq' /tmp/ccRHXYbX.s:143323: Error: unrecognized opcode: `pushfd' /tmp/ccRHXYbX.s:143324: Error: unrecognized opcode: `pushfd' /tmp/ccRHXYbX.s:143325: Error: unrecognized opcode: `pop' /tmp/ccRHXYbX.s:143326: Error: unrecognized opcode: `mov' /tmp/ccRHXYbX.s:143327: Error: operand out of range (0x0020 is not between 0x and 0x001f) /tmp/ccRHXYbX.s:143327: Error: missing operand /tmp/ccRHXYbX.s:143328: Error: unrecognized opcode: `push' /tmp/ccRHXYbX.s:143329: Error: unrecognized opcode: `popfd' /tmp/ccRHXYbX.s:143330: Error: unrecognized opcode: `pushfd' /tmp/ccRHXYbX.s:143331: Error: unrecognized opcode: `pop' /tmp/ccRHXYbX.s:143332: Error: unrecognized opcode: `popfd' /tmp/ccRHXYbX.s:143391: Error: unrecognized opcode: `cpuid' /tmp/ccRHXYbX.s:143407: Error: unrecognized opcode: `cpuid' /tmp/ccRHXYbX.s:176663: Error: unrecognized opcode: `pushfd' /tmp/ccRHXYbX.s:176664: Error: unrecognized opcode: `pushfd' /tmp/ccRHXYbX.s:176665: Error: unrecognized opcode: `pop' /tmp/ccRHXYbX.s:17: Error: unrecognized opcode: `mov' /tmp/ccRHXYbX.s:176667: Error: operand out of range (0x0020 is not between 0x and 0x001f) /tmp/ccRHXYbX.s:176667: Error: missing operand /tmp/ccRHXYbX.s:176668: Error: unrecognized opcode: `push' /tmp/ccRHXYbX.s:176669: Error: unrecognized opcode: `popfd' /tmp/ccRHXYbX.s:176670: Error: unrecognized opcode: `pushfd' /tmp/ccRHXYbX.s:176671: Error: unrecognized opcode: `pop' /tmp/ccRHXYbX.s:176672: Error: unrecognized opcode: `popfd' /tmp/ccRHXYbX.s:176730: Error: unrecognized opcode: `cpuid' /tmp/ccRHXYbX.s:176746: Error: unrecognized opcode: `cpuid' make[2]: *** [Makefile:255: bowtie-build-s] Error 1 Any help would be welcome Andreas. [1] https://buildd.debian.org/status/fetch.php?pkg=bowtie=ppc64el=1.3.0%2Bdfsg-2=1602489351=0 -- http://fam-tille.de
