sac2c merge requestshttps://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests2020-11-25T12:58:40Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/52WIP: Documentation fix (and update?)2020-11-25T12:58:40ZHans-Nikolai ViessmannWIP: Documentation fix (and update?)This merge, which is a **WIP**, attempts to improve the inline documentation of the `sac2c` sources. Other than the obvious reasons for wanting to do this, is that our current documentation generator Doxygen provides a lot of nifty facil...This merge, which is a **WIP**, attempts to improve the inline documentation of the `sac2c` sources. Other than the obvious reasons for wanting to do this, is that our current documentation generator Doxygen provides a lot of nifty facilitates that can help in making the code more accessible and understandable - like our AST XHTML page, one can quickly look through and understand how functions/structs/macros are used.
This is certainly ambitious, but some attempt needs to be made to _at the least_ to bring about the following:
* [ ] a clear documentation standard
* [x] integration within the build system to generate the documentation
* [ ] some tool/hook to verify that commits adhere to the documentation standard before committing
Further goals (though likely not achievable in a reasonable amount of time) are:
* [ ] improve/update existing documentationHans-Nikolai ViessmannHans-Nikolai Viessmannhttps://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/58Json cmake follow2018-08-17T15:32:43ZArtem ShinkarovJson cmake followThis has been around for several years. Let's finally merge it in. The main advantage is that json-based generators implement a lot of checks that can be turned on and off and which guarantee consistency of the tree. Html files are a ...This has been around for several years. Let's finally merge it in. The main advantage is that json-based generators implement a lot of checks that can be turned on and off and which guarantee consistency of the tree. Html files are a bit nicer than before. Generation of C files is significantly faster, which speeds-up the overall compilation.
Also, by adopting JSON as a concept, we can use it in other parts of the compiler to describe things and to serialize/deserialize things.https://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/71Inctroducing new DIM_T struct type for TYPES_DIM, ICM, and others2021-05-22T13:16:22ZGrzegorz GoralInctroducing new DIM_T struct type for TYPES_DIM, ICM, and othersThis work will change the definitions of dim across the system to replace the current encoded dim.
This mainly occurs through usage of `TYPES_DIM` and `TCgetShapeDim`, but other dim usage shall be changed for possible future development...This work will change the definitions of dim across the system to replace the current encoded dim.
This mainly occurs through usage of `TYPES_DIM` and `TCgetShapeDim`, but other dim usage shall be changed for possible future development that may find the dim_t implementation more useful.
The definition of dim_t is:
```c++
typedef struct DIM_T {
size_t val;
bool f_array_or_scalar: 1;
bool f_known_shape: 1;
bool f_known_dimension: 1;
} dim_t;
```
The tests created to verify correct function of `TCgetShapeDim` currently highlight the possible types of dim results. These(with slight modification to use the struct instead of an int) will aid in later verifying that the modified dim still produces the required results.
This is the transition between the old and new definitions which shall be used to refactor the old usage of encoded dim:
```
TYPES_DIM can have the following values (and meanings):
* array, shape and dimension are know dim > SCALAR => val > SCALAR && f_known_shape
* array, shape is not known, dimension is known dim < KNOWN_DIM_OFFSET => val > SCALAR && f_known_dimension
* array, shape and dimension is not known dim == UNKNOWN_SHAPE => !f_known_shape && !f_known_dimension &&
!f_array_or_scalar
* array or scalar, shape and dimension are not known dim == ARRAY_OR_SCALAR => f_array_or_scalar
* scalar, shape and dimension are known dim == SCALAR => val == SCALAR && f_known_shape
```
Edit: Had to change flags for UNKNOWN_SHAPE to also check array_or_scalar as the previous check of only known shape or dimension was not enough. This would have left the chance that an array_or_scalar dim would also be unknown_shape, which is impossible following the rules of the previous version.https://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/78Bring sac2c up to date with most recent ISL/BARVINOK code2018-12-12T00:53:46ZRobert BerneckyBring sac2c up to date with most recent ISL/BARVINOK codeReflect ISL/BARVINOK include file name change.Reflect ISL/BARVINOK include file name change.https://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/101WIP: Introducing sz_t to represent larger unsigned values2021-06-27T08:38:30ZGrzegorz GoralWIP: Introducing sz_t to represent larger unsigned valuesThis merge request will introduce `sz_t`, which will be able to represent larger unsigned values by putting together two `size_t`.
With this, shape lengths will be changed so for the future if there are any situations where they are nee...This merge request will introduce `sz_t`, which will be able to represent larger unsigned values by putting together two `size_t`.
With this, shape lengths will be changed so for the future if there are any situations where they are needed to be larger than `int` the compiler will be able to handle this.
This will define ways to handle both scalar operations on `sz_t` as well as `sz_t` with `sz_t`.Grzegorz GoralGrzegorz Goralhttps://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/106Islbandtospace32019-02-22T18:53:35ZRobert BerneckyIslbandtospace3Reflect ISL/BARVINOK band.h -> space.h name changeReflect ISL/BARVINOK band.h -> space.h name changehttps://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/128Draft: EMR for const arrays2022-05-20T13:21:13ZHans-Nikolai ViessmannDraft: EMR for const arraysWith this MR we extend EMR (pun intended) to now also handle constant arrays (e.g. `N_array`). This means that we now also annotate them with ERCs, which might get used for allocation instead of allocating a fresh array.With this MR we extend EMR (pun intended) to now also handle constant arrays (e.g. `N_array`). This means that we now also annotate them with ERCs, which might get used for allocation instead of allocating a fresh array.https://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/152disabled SAC_MT_SYNC_FOLD completely to fix issue 22662021-06-27T07:46:32ZSven-Bodo Scholzdisabled SAC_MT_SYNC_FOLD completely to fix issue 2266I am not 100% sure this is the right thing to do. We need to investigate further whether SAC_MT_SYNC_FOLD really is no longer needed (which I believe).
If that truely is the case, we can get rid of that ICM and its generation in compile....I am not 100% sure this is the right thing to do. We need to investigate further whether SAC_MT_SYNC_FOLD really is no longer needed (which I believe).
If that truely is the case, we can get rid of that ICM and its generation in compile.c completely!
I am pretty sure that none of the three main WL operators (genarray, modarray, and fold) need this.
fold-WLs seem to end up with inout parameters (in for neutral and out for the result) and genarray and modarray typically
have non-scalar returns enforcing them to be inout as well.
Further investigation is being asked for!https://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/157Add a changelog2021-11-03T14:22:54ZHans-Nikolai ViessmannAdd a changelogWith this MR we add a CHANGELOG file which follows (as an example) the guidelines set out by https://keepachangelog.com/en/1.0.0/.
Note that the current entries where pulled from git history, **this is not how it should be done**! I've ...With this MR we add a CHANGELOG file which follows (as an example) the guidelines set out by https://keepachangelog.com/en/1.0.0/.
Note that the current entries where pulled from git history, **this is not how it should be done**! I've done this as a starting point, later entries should be properly handwritten with a sufficient description.Create a releaseHans-Nikolai ViessmannHans-Nikolai Viessmannhttps://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/161Draft: Extend module dependency checking2021-10-11T13:30:46ZHans-Nikolai ViessmannDraft: Extend module dependency checkingRelating to @jcuppen's project on creating a package manager for SAC, these changes in the compiler are meant
to help make it easier to resolve module dependencies. This MR adds/changes the following:
* We add functionality to printout ...Relating to @jcuppen's project on creating a package manager for SAC, these changes in the compiler are meant
to help make it easier to resolve module dependencies. This MR adds/changes the following:
* We add functionality to printout only those module dependencies which *do not* exist on the file-system.Hans-Nikolai ViessmannHans-Nikolai Viessmannhttps://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/169Draft: Leak Fixes2023-10-03T13:53:09ZHans-Nikolai ViessmannDraft: Leak FixesWith this we introduce some memory leak fixes. Some were found using valgrind, other using GCC/Clang static analyses.
Todo
- [ ] fixes need to be checked that don't cause issues further along the compilation stages (such as with the AST...With this we introduce some memory leak fixes. Some were found using valgrind, other using GCC/Clang static analyses.
Todo
- [ ] fixes need to be checked that don't cause issues further along the compilation stages (such as with the AST)
- [ ] integrate memory leak checks into CI
- [ ] integrate other checks like CWE (https://cwe.mitre.org/) stuffHans-Nikolai ViessmannHans-Nikolai Viessmannhttps://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/200Draft: Update CI build images2023-12-20T13:37:40ZHans-Nikolai ViessmannDraft: Update CI build imagesWith this we move away from centos8 which is EOL and ubuntu21
which never released a LTS version. We replace this with ubuntu22.With this we move away from centos8 which is EOL and ubuntu21
which never released a LTS version. We replace this with ubuntu22.Hans-Nikolai ViessmannHans-Nikolai Viessmannhttps://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/234Sanitize2023-10-18T18:17:46ZThomas KoopmanSanitizeFixing of various errors (UB and memory leaks) caught by GCC sanitizersFixing of various errors (UB and memory leaks) caught by GCC sanitizershttps://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/283Draft: Implement beta-reduction for single generator with-loops2024-02-21T11:15:59ZThomas KoopmanDraft: Implement beta-reduction for single generator with-loopsReplaces `{kv -> expr(kv) | kv < ub}[jv]` with `expr(jv)`.
Four tests still fail.
`test-emr.sac` gives the correct output, but the optimised code looks different so this is probably a problem in the test itself.
For `test-type-patte...Replaces `{kv -> expr(kv) | kv < ub}[jv]` with `expr(jv)`.
Four tests still fail.
`test-emr.sac` gives the correct output, but the optimised code looks different so this is probably a problem in the test itself.
For `test-type-pattern-matmul` and `test-wlur-modarray` the `DBUG_ASSERT` on `jv_avis` fails
For `test-fold-accu-mmv` there is a type error on an arrayhttps://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/290Use after free2024-03-25T08:29:37ZThomas KoopmanUse after freeFixed several use after free errors exposed by `-fsanitize=address`.
I have not been able to find pretty fixes for all errors, but I have been plagued by strange uninitialized memory in the compiler lately,
so I think duct-tape is bette...Fixed several use after free errors exposed by `-fsanitize=address`.
I have not been able to find pretty fixes for all errors, but I have been plagued by strange uninitialized memory in the compiler lately,
so I think duct-tape is better than nothing.
On top of request 289