-
Notifications
You must be signed in to change notification settings - Fork 13
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
JuleC's GCC compatibility issues #34
Comments
Here is the more information about that. We tried again to create a workflow for Windows. Meanwhile, Jule's current commit was Using Clang is not possible due to MSVC. Using We used Our workflow name: Build (Windows)
on: [push, pull_request]
jobs:
build:
runs-on: windows-latest
steps:
- uses: actions/checkout@v3
- name: Get latest IR
run: |
curl -o .\ir.cpp https://raw.githubusercontent.com/julelang/julec-ir/main/src/windows-amd64.cpp
- name: Compile Latest JuleC IR
shell: cmd
run: |
mkdir .\bin
g++ -Wa,-mbig-obj -O0 --std=c++17 -w -o .\bin\julec.exe .\ir.cpp
git update-index --add --chmod=-x .\bin\julec.exe
- name: JuleC Version
run: |
.\bin\julec.exe version
- name: Build JuleC
shell: cmd
run: |
.\bin\julec.exe -t .\src\julec
g++ -Wa,-mbig-obj -O0 --std=c++17 -w -o .\bin\julec.exe .\dist\ir.cpp
git update-index --add --chmod=-x .\bin\julec.exe We tried this with same JuleC codes and IR on our Additionally, on our own machine, GCC does not have a |
Maybe the version command doesn't work because JuleC has not been built yet? 🤔 |
We're pretty sure it was built. In any compile problem, the workflow does not proceed to the next step. But still, just to be sure, I executed a |
Research UpdateWe have more research and some findings on the subject. We're almost certain that the GCC in our build on a native Windows machine is actually an alias executable file for Clang, hence the wrong results. To fix this we got a MinGW GCC and tried again. The The interesting part is that the compiler compiled from the IR code still works correctly. Does not terminate immediately with exit code So it looks like we have to update GCC support as partial support state. There is detailed information about this on the relevant manual page. GitHub ActionsGitHub Actions is still a puzzle. We compiled it from IR code with MinGW LLVM Clang which allowed us to have a smooth experience on our local machine. We expected a smooth experience, but we may have found a strong finding that the problem is not related to the compilers. Even the executable obtained with the Clang compiler, which we have had smooth experience with, has the same problem as with GCC. The program terminated immediately with exit code This issue we're having on GitHub Actions machines may not have anything to do with us. |
We can also use |
GDB did not provide any meaningful help. I suspect this has more to do with the compiler than with the Jule API. No problems when compiled with Clang. When I test and debug it on my local machine, I see that this is due to the use of a When I checked the stack trace I couldn't see anything that could cause this. Additionally I must say that the my Windows machine is weak and the compile times are really long and it is difficult to debug. Therefore, the process cannot progress quickly on my machine. If you do any analysis, debugging, research and similar thing on this issue, please share your findings with us. Thanks. |
Here is the new news. This isn't just a Windows problem. Therefore, I will update the title of this issue accordingly. Seems like help is needed to understand if compatibility is fully achieved. I tried to compile on GitHub Actions. But |
I tested GCC support on VM Fedora Linux 38 Workstation Edition. Clang version: I used latest IR (version 54a6661) and master source tree (hash 54a6661) of Jule. |
That's great news! 🎉 Should we try again with Windows? |
I created a Windows build CI on my own Jule fork to see if the issues were resolved. Very strange, but the problem seems to occur when |
That's very strange. Are there any alternatives to |
I'm not sure about that, probably the issue is not the Please share with us if you found something about this issue after your investigation. |
Latest situation; The I tested with another local machine using GCC on Windows. Unlike GitHub Actions, no any change on local machine. Still same problem exist, no progress. I don't have any idea what makes different GitHub Actions but it seems to work. As I said, GitHub Actions have one known problem; console write call is not works. Jule uses I just investigate the original problem a bit more, no progress. I just write simple program like this: #include <stdio.h>
#include "api/utf8.hpp"
int main() {
printf("hello world\n");
return 0;
} The example program above will not prints while including |
Update for latest situation:
Alright, I discovered the problem. Probably my GCC installation is corrupted, same tasks are good after clean installation. Compiles successfully any program now.
After fixing the compiler problem, I tested again and here is the good news: GCC support looks good! Everything works as expected, even using bootstrapped compiler which is compiled with GCC. No observations of GCC and Clang behavioral differences. But we have a new problem. On Windows, GitHub Actions is failing when calling |
The relevant issue is: #107 |
Description
We tried to create a CI for Windows. It was a simple build CI. It would build JuleC from the IR code and rebuild and compile the latest JuleC from source. But we had some problems.
This CI gets the latest
windows-amd64
with CURL from Julec-IR repository and compiles via GCC withO3
,-w
,-Wa,-mbig-obj
and C++17. After compiling the IR code obtained with CURL, a simple command is executed for testing. A simplejulec version
command is then executed. However, the execution of the program results in failure.We left only the header files and an empty entry point, as we thought this could be caused by some algorithms in the IR code. Then we removed all header files. It was the inclusion of the API that was causing the problem. However, we had a program that did nothing. There was an empty entry point. From what we analyzed, the API did not have code that would lead to the execution of an algorithm that could cause problems when just included. So the program wasn't really doing anything as far as we know.
This issue could be a minor overlooked bug, a simple programming error in the API, or something that has nothing to do with us directly, such as a GCC compilation issue. We tried to do various things to understand this problem, but we couldn't find a rational point to start fixing it. Needs more research.
Expected behavior
Program should execute as expected.
Current behavior
Each execution's result is
Process completed with exit code -1073741511
or something like that.Additional information
The current situation when we do this:
79c36b2e9e
9ab7a750fc
The text was updated successfully, but these errors were encountered: