-
Notifications
You must be signed in to change notification settings - Fork 361
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
delimcc/setjmp_amd32 compilation defect #3916
Comments
Hey, I've tried to reproduce it, but I couldn't receive the error/warning you're getting. I've tried it on GitPod on x86_64, using both latest GNU ld 2.42, and default 2.36. Reproducing it was especially important to me, so we can find out why compilation of this file is triggered at all. |
Thank you for taking a look at this. I'll try late tomorrow (Weds, probably Thursday your time) to reproduce. |
To get this out of my brain, so that I can deal with the javalib We are using the same version of I think the mid to longer range issue is why is the .c (or .cpp) file being presented to the compiler at all? I understand why the initial generation went in as it did. Succeeding generations have improved the |
TL; DR * I spent several hours and could not reproduce. I will submit a robustness PR anyway. Environment: Ubuntu 23.04 Intel X86_64 Test command: tests3/testOnly *.ContinuationsTest (passes)
|
PR #3925 provided a quick fix to the base issue. I think we are probably not up to a thousand cuts on Whilst working on #3925 it dawned on me that we might be able to avoid the core "presenting useless, weird stuff It occurred to me that we could concatenate the four current files into one new file (well, it will take a little bit of The compiler would see one file. That file would always generate some code (or else hit a #error "Unknown architecture") Yes, this is a slight deviation of from the project where this code was taken. I believe that project is venerable and sees I have not tried this out, but I am pretty sure it would work. If encouraged, I could first do the changes in a sandbox Please advise, Later: Please see PR #3926 CI was painfully slow, with intermittent build failures, so I had some time to try out the idea of this entry. At the very least, it should speed up the build a bit, by not considering know-to-be There may or may not be a |
I believe the build errors are intermittent and unrelated to the substance of this PR I read the logs but am not going to chase those errors unless I have to. I believe |
When compiling (scala-cli) on linux X86_64 (Intel), I am (since recently?) I am getting:
The long running basic defect is that a 32 bit file is getting compiled at all on a 64 bit machine. (and probably visa versa).
I think the death-by-a-thousand-cuts fix is to change
to
That should put the
.section
note outside of theguards and ensure that the necessary section note will get generated if the compiler ever touch the the file with
__linux_ && __ELF__
.I have not tried this, I am too deep in javalib
Files
symlink fun and am still recovering from the trauma from the lasttime I touched these files.
I suspect that a similar change needs to be made to all the .S files in that directory.
The text was updated successfully, but these errors were encountered: