-
Notifications
You must be signed in to change notification settings - Fork 301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix mach compilation again; fold_constant has to be the same section as crc16_t10dif_copy_pmull #226
Conversation
…as crc16_t10dif_copy_pmull Signed-off-by: Taiju Yamada <tyamada@bi.a.u-tokyo.ac.jp>
|
@@ -379,13 +379,14 @@ v_br1 .req v5 | |||
.size crc16_t10dif_copy_pmull, .-crc16_t10dif_copy_pmull | |||
#endif | |||
|
|||
ASM_DEF_RODATA |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you want them in the .text section now? They were in .rodata before. You show a cross build in the comments but cross build seems to work fine when this is in rodata like other constants.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It worked for gcc but did not work for (apple-)clang.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$ make -f Makefile.unx CC=arm64-apple-darwin-gcc AR=arm64-apple-darwin-ar arch=aarch64 host_cpu=aarch64 DEFINES="-fno-stack-check" lib programs/igzip -j8
mkdir -p bin
---> Building crc/aarch64/crc16_t10dif_pmull.S aarch64
---> Building crc/aarch64/crc16_t10dif_copy_pmull.S aarch64
crc/aarch64/crc16_t10dif_pmull.S:222:9: error: unknown AArch64 fixup kind!
ldr q_fold_const, fold_constant
^
crc/aarch64/crc16_t10dif_copy_pmull.S:231:9: error: unknown AArch64 fixup kind!
ldr q_fold_const, fold_constant
^
make: *** [bin/crc16_t10dif_pmull.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [bin/crc16_t10dif_copy_pmull.o] Error 1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this has been confirmed by #226 (comment)
@kirbyzhou would you mind taking a look? I mean, does this improve compilation? |
I'll try it in a 2 or 3 days. I've been busy recently. |
It can be compiled with a lot of warnings:
The compression level=1,2,default is broken, only level=0,3 works
The decompression speed is the same as gzip of system and cloudera.
|
Could you tell me the Xcode version used? |
Also, is it true that you used master, not my patch? |
Xcode version 14.1
|
@kirbyzhou could you check whether fec429e compiles on Xcode 14? Edit: resolved #226 (comment) |
Any updates on this? Do we need this for isal support on Apple silicon? Install of the python library seems to be fine through a conda-installed Python 3.11, but I'm not clear whether it's safe to use without this patch. |
@akotlar could you check if 3c78474 and fec429e compiles on mac? I believe fec429e does not, but I need another witness. Edit: resolved #226 (comment) |
Any more info here? |
I need someone who can check #226 (comment) , which takes less than 30min. Otherwise I need to buy a M1 mac as github-hosted M1 runner is not free and cannot be used for experiments. Edit: resolved #226 (comment) |
Sorry missed this notification. I’ll double check thanks! |
@akotlar thanks for looking into it. Let us know asap, thanks! |
We are releasing this week, so I'll defer this to next release, unless it is clear this is fixing the issue and not breaking any other ARM architectures. |
SPDK ran into this general problem as well, see spdk/spdk#3247. We pushed a fix to our isa-l submodule fork which got me unblocked for now. But it would be great to have this fixed in isa-l upstream. |
@liuqinfei could you check this is OK with you? |
Ok, i am on holiday until this Saturday. When i am back, i will verify this pr as soon as possible.
…---- Replied Message ----
| From | Pablo de ***@***.***> |
| Date | 02/12/2024 17:13 |
| To | ***@***.***> |
| Cc | ***@***.***>***@***.***> |
| Subject | Re: [intel/isa-l] Fix mach compilation again; fold_constant has to be the same section as crc16_t10dif_copy_pmull (PR #226) |
@liuqinfei could you check this is OK with you?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
I have verified the latest master branch with this PR on kunpeng Aarch64 platform. All of the func test cases are passed. [root@node1 isa-l]# cat /etc/os-release [root@node1 isa-l]# uname -r [root@node1 isa-l]# make check
|
Hi, @jimharris I read your PR3247 for spdk. The issue is interesting. It seems that the behavior ldr data in .rodata section should be forbidden with (apple-)clang. For this case, GCC works but (apple-)clang fails. So, it seems that it is better to fix the (apple-)clang. Right? |
So, with macos-14 runner, I can run CI finally. Though I needed to add libtool explicitly cf #277
So this pull request is valid at least (unless clang should be fixed as Liuqinfei says) However igzip_rand_test segfaults (other 15 tests pass though), which should be investigated. But I think the investigation is super-difficult without local arm64 mac. |
x18 problem should be fix . I will raise an issue later. This looks forgotten. Could you take a look?
I remember I tried but in |
@yuhaoth seems like x29 is safe. And actually, thanks to github M1-mac runner, I was avoid x18 by my own. With M1-mac github runner CI fixed, I published #278 @kirbyzhou , 278 should not have segmentation fault anymore. |
closing to avoid confusion |
Reopening this PR, then #278 can be rebased. @liuqinfei, are you OK with this fix? |
As i verified, this patch works well on arm64. If no deep study on clang, it's ok to accept this. |
PR merged in the repo now, thanks! |
The patch works for me, any chance of cutting a new release? cc @pablodelara relates to Homebrew/homebrew-core#168488 |
@chenrui333 actually you should include #278 whole content |
No description provided.