-
Notifications
You must be signed in to change notification settings - Fork 900
Improve ARM support #170
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
Comments
Imported from trac issue 3481. Created by jsquyres on 2013-01-25T18:57:00, last modified: 2014-04-22T16:01:01 |
Trac comment by phargrov on 2014-01-23 19:38:55: No progress in 12 months? The original description indicates that 1.6 used a "different" solution to the ARM asm issues, and asks if r27882 should be reverted (in time for the then-future v1.7). However, the distinct I can confirm that the current 1.7.4rc tarballs, configured with no special options, passes "make all install check" on a multi-core armv7 system (Ubuntu Precise on QEMU-emulated Versatile Express). I also have an armv5 (QEMU-emulated Versatile PB) where I suspect we must fail due to attempts to use strex/ldrex instructions in the asm code (though I've not had time to confirm). -Paul |
Fix a cuda error message when we run out of memory
Several issues with compiling on a RasberryPi2 (armv7-a) have been reported on the mailing list. The patch proposed in the original svn r27882 provides an ugly but functional solution. I propose we reintegrate the original patch in master. |
@bosilca Sounds good. Can you commit to master? |
I just got a rpi2. Give me few days to check the status of this. |
Move this to the Future milestone -- I think 2.x is the earliest this will happen. |
@shamisp Just saw this in the old issues -- can you look to see if it is still relevant? If not, feel free to close it. Thanks. |
Moving to 3.x milestone |
I believe that ARMv8 is now well-supported. |
Per discussion on the devel list:
Lief would like to revert r27882 and implement it differently (see first mail in this thread). r27882 was not accepted into v1.6; a different (simpler) workaround was used as a stopgap.
Lief -- do you have a timeline for this implementation? Can it be done in the near enough future to include in the v1.7 series? Should be revert r27882 in the immediate future?
The text was updated successfully, but these errors were encountered: