Comments (13)
Latest version of oberon-lang
includes fixes to the scanner and parser to address the following issues.
module_unterminated.mod
: no terminating dot at end of module → infinite loopfail_on_extra_semicolon.mod
: expected failif_with_trailing_end.mod
: parser does not complain about superfluousEND
inIF
-ELSIF
-ELSE
statement
from oberon-lang.
Result MSYS2:
Failed Tests (7):
Oberon :: codegen/arithmetic_12.mod
Oberon :: codegen/array_5.mod
Oberon :: codegen/case_1.mod
Oberon :: codegen/const_long_hex.mod
Oberon :: codegen/const_longint.mod
Oberon :: codegen/loop_2.mod
Oberon :: codegen/system_6.modUnexpectedly Passed Tests (7):
Oberon :: codegen/arithmetic_11.mod
Oberon :: codegen/arithmetic_15.mod
Oberon :: codegen/arithmetic_3.mod
Oberon :: codegen/arithmetic_5.mod
Oberon :: codegen/arithmetic_6.mod
Oberon :: codegen/arithmetic_9.mod
Oberon :: codegen/procedure_4.modUnsupported : 2
Passed : 66
Expectedly Failed : 9
Failed : 7
Unexpectedly Passed: 7
codegen/const_long_hex.mod
and codegen/const_longint.mod
fails for me.
I am guessing this is related to use of long
which is 32bit on my platform.
from oberon-lang.
I just pushed two commits to the master branch that update Scanner, AST, Sema and CodeGen to use fixed-width integers (i.e., int64_t
, int32_t
, and int16_t
for LONGINT
, INTEGER
, and SHORTINT
as well as uint8_t
for CHAR
). Does that improve portability? It surely makes things more consistent.
from oberon-lang.
codegen/const_long_hex.mod
is now fixed.
codegen/const_longint.mod
still failed.
I added the following to rt_out_int
:
#ifdef MINGW32
sprintf(buf, "%lld", i);
#else
sprintf(buf, "%" PRId64, i);
#endif
This fixes the problem.
Probably the macro PRId64 is not correct on my platform.
from oberon-lang.
Since I currently don't have access to my Windows virtual machine, due to Easter travel, I was wondering if you could try the following. If you build the compiler in DEBUG
mode and run it with the -v
flag, it will print out a lot (like really a lot) of diagnostic information that will help me to localize the problem.
For example, if I run const_longint.mod
in DEBUG
it prints (among other things) the module how the compiler "sees" it. On my machine this look as shown below.
MODULE ConstLongInt(*Scope:0*);
IMPORT Out;
CONST longintmax(*Scope:1*) = 9223372036854775807(*L*)(*Type:LONGINT*);
longintmin(*Scope:1*) = -9223372036854775808(*L*)(*Type:LONGINT*);
PROCEDURE Test(*Scope:1*)();
BEGIN
Out.Long(9223372036854775807(*L*), 0(*S*));
Out.Ln();
Out.Long(-9223372036854775808(*L*), 0(*S*));
Out.Ln()
END Test;
BEGIN
Test()
END ConstLongInt.
The first thing to make sure is that all constant literals are annotated by the correct type (S
= SHORTINT
, I
= INTEGER
, L
= LONGINT
, etc). If this is not the case, the problem most likely resides in the Scanner code assigns types to literals. If all literals are correctly typed, the problem will be in Out.Long()
.
As the compiler can do more and more, I am currently trying to implement more parts of Out
and Texts
in Oberon rather than in C. So, if the problem is in the output procedure, it hopefully resolves itself "automatically", but if it is in the Scanner, I will put it on the to-do list.
from oberon-lang.
No problem. Output MSYS2:
MODULE ConstLongInt(Scope:0);
IMPORT Out;CONST longintmax(Scope:1) = 9223372036854775807(L)(Type:LONGINT);
longintmin(Scope:1) = -9223372036854775808(L)(Type:LONGINT);PROCEDURE Test(Scope:1)();
BEGIN
Out.Long(9223372036854775807(L), 0(S));
Out.Ln();
Out.Long(-9223372036854775808(L), 0(S));
Out.Ln()
END Test;BEGIN
Test()
END ConstLongInt.
The Scanner is then OK.
Sidenote on VM images: The NativeOberon image is available at. This
works suprisingly well and really fun to explore. Happy easter!
from oberon-lang.
On my Windows machine (VMware, Windows 11, x86_64), I have a strange problem that obfuscates a clear view of the status of the unit tests. The issue is related to some modules failing in JIT mode due to unresolved symbols. Using the MSYS/Clang64 toolchain the missing symbol is ___chkstk_ms
, while using the MSVC toolchain the missing symbols are __security_cookie
and __security_check_cookie
. Both symbols are related to the stack protection mechanisms of the respective toolchains.
I checked the assembly generated by oberon-lang
and calls to these symbols are indeed emitted if the optimization level is set to -O0
, otherwise the calls are (probably) optimized away by a (yet to be identified) optimization pass. Since there is no option to run optimization in JIT mode, these errors cannot be avoided for certain modules for the time being. I have not yet fully understood under which circumstances these calls are emitted. The sets of modules affected by the problem are similar but not the same in the two toolchains.
I'm now trying to figure out if and how I can load the libraries into the JIT session that contain these symbols or whether it makes sense to run the optimization pass that removes these calls also in JIT mode.
from oberon-lang.
I found this problem also and did not find any easy option to turn this off.
It seems that on un-optimized Windows build stack protection functions are added by default.
These functions reside in the static library libclang_rt.builtins-x86_64.a
as far as I can tell for MSYS2 & LLVM.
For MSVC it is probably enough with the ucrtbase.dll
(Only Windows 10 and later. msvcrt
for earlier versions).
In order to solve this I always linked in this libraries on the Windows platform found in these commits 1 and 2.
The latter commit I placed the static library alongside the .exe file so that upgrading CLANG MSYS2 will not
break the installation.
An other option could be just to define some dummy functions covering this and add to JIT symbol table.
I understand from reading some LLVM mailing lists that the long-term solution being worked on is a separate
runtime library for the JIT functionlality. This runtime library is still pending, so we might just choose to install a
temporary solution as referenced above.
from oberon-lang.
Interesting! Do you have a link to the mailing list discussion?
from oberon-lang.
I did not find the post, but I believe this issue is relevant : 60034
Edit : Turns out there is an option to link and export the symbols in the .exe directly: 1 2
This is maybe the cleanest solution as it will be resolved at compile time and can be just inserted with
#ifdefs into the C++ code.
from oberon-lang.
Confirm the fix for the stack protection issue is working for me.
The result for unittests is:
Failed Tests (8):
Oberon :: codegen/arithmetic_12.mod
Oberon :: codegen/arithmetic_16.mod
Oberon :: codegen/array_5.mod
Oberon :: codegen/case_1.mod
Oberon :: codegen/const_1.mod
Oberon :: codegen/loop_2.mod
Oberon :: codegen/system_6.mod
Oberon :: codegen/system_7.modUnexpectedly Passed Tests (7):
Oberon :: codegen/arithmetic_11.mod
Oberon :: codegen/arithmetic_15.mod
Oberon :: codegen/arithmetic_3.mod
Oberon :: codegen/arithmetic_5.mod
Oberon :: codegen/arithmetic_6.mod
Oberon :: codegen/arithmetic_9.mod
Oberon :: codegen/procedure_4.modTesting Time: 22.87s
Unsupported : 2
Passed : 65
Expectedly Failed : 9
Failed : 8
Unexpectedly Passed: 7
codegen/system_7.mod
fails with output -1.0E+00
against CHECK: -1.00E+00
.
This is probably due to update to Out module and similar on other platforms?
codegen/system_6.mod
fails with NaN
output where INF
and -INF
where expected for REAL.
from oberon-lang.
Interesting! These results are very different from what I see on the platforms available to me (including MSYS2/Clang64). Have you rebuilt liboberon
before running the tests?
from oberon-lang.
Sorry. Stale version of liboberon
.
Result is:
Failed Tests (4):
Oberon :: codegen/arithmetic_12.mod
Oberon :: codegen/array_5.mod
Oberon :: codegen/case_1.mod
Oberon :: codegen/loop_2.modUnexpectedly Passed Tests (7):
Oberon :: codegen/arithmetic_11.mod
Oberon :: codegen/arithmetic_15.mod
Oberon :: codegen/arithmetic_3.mod
Oberon :: codegen/arithmetic_5.mod
Oberon :: codegen/arithmetic_6.mod
Oberon :: codegen/arithmetic_9.mod
Oberon :: codegen/procedure_4.modTesting Time: 29.32s
Unsupported : 2
Passed : 69
Expectedly Failed : 9
Failed : 4
Unexpectedly Passed: 7
from oberon-lang.
Related Issues (20)
- endian.h not found on Windows platform HOT 2
- Enforce position of module level VAR section? HOT 5
- Output file argument not working HOT 2
- Avoid writing .smb file for JITed main module HOT 2
- Array passed as argument is shorten HOT 2
- Export of CHAR constants not supported HOT 1
- Add MSYS2 page to Wiki HOT 1
- Add Embedded example to wiki HOT 1
- Cross platform support HOT 2
- Compilation error due to extra semicolon
- CHAR variable not treated equal to CHAR literal HOT 5
- Bug in name mangling of (un)nested procedures HOT 2
- Undefined behavior due to nested procedure HOT 7
- Crash with assignment of string literal reference returned from procedure HOT 4
- DIV and MOD not in line with Oberon-07 report HOT 3
- Build report ArchLinux HOT 4
- Crash triggered by accessing exported variable HOT 4
- Proposal to make runtime functionality configurable.
- Access to argc & argv
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oberon-lang.