sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2024-03-07T17:31:30Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2390Towards a more lazy semantics2024-03-07T17:31:30ZSven-Bodo ScholzTowards a more lazy semanticsSeveral optimisations do perform redices that in a strict evaluation would never be executed.
A simple example is: `K (2, 3/0)`. Under a strict evaluation scheme it should not terminate / yield bottom; if we optimise this into `2`, this ...Several optimisations do perform redices that in a strict evaluation would never be executed.
A simple example is: `K (2, 3/0)`. Under a strict evaluation scheme it should not terminate / yield bottom; if we optimise this into `2`, this changes the semantics even though, under a normal order regime, this is fine.
Quite some discussion on this matter was done in the context of the merge request for URR:
https://gitlab.sac-home.org/sac-group/sac2c/-/merge_requests/285#note_13840
The question remains: how do we want to deal with this?https://gitlab.sac-home.org/sac-group/sac2c/-/issues/2367Combine _afterguard_ and _guard_, and update guard insertion of ECC2023-12-22T14:55:41ZJordy AalderingCombine _afterguard_ and _guard_, and update guard insertion of ECCConformity checks only have an afterguard, we want to combine this afterguard with guard so that we have a single primitive function, instead of having almost the same thing twice.
Additionally, similarly to type patterns, we want this ...Conformity checks only have an afterguard, we want to combine this afterguard with guard so that we have a single primitive function, instead of having almost the same thing twice.
Additionally, similarly to type patterns, we want this guard to occur both before and after the conformity checked code so that we can keep the context in the future if we have better error messages.
Something like:
```
p1 = conformity check 1
...
pv = conformity check v
x1', .., xn' = guard (x, .., xn, p1, .., pv, "context");
res1, .., resm = _prf_ (x1', .., xn');
res1', .., resm' = guard (res1, .., resm, p1, .., pv, "context");
```Jordy AalderingJordy Aalderinghttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2366Virtual stack-trace of function applications2024-01-26T16:12:15ZJordy AalderingVirtual stack-trace of function applicationsWe want to keep track of a 'virtual' stack trace so that we can give the current trace if we encounter an error during run-time.
We return the arguments or return values to avoid code-reordering from messing with the location of these s...We want to keep track of a 'virtual' stack trace so that we can give the current trace if we encounter an error during run-time.
We return the arguments or return values to avoid code-reordering from messing with the location of these stack pushes and pops.
```
x1', .., xn' = _virtual_stack_push_ (x1, .., xn, "foo signature");
res1, .., resm = foo (x1', .., xn');
res1', .., resm' = _virtual_stack_pop_ (res1, .., resm);
```
Optionally, we might also be able to use this notation to construct a stack trace for compile time errors.
But that is something we should figure out in the future, first we must investigate whether this will even work as intended.
---
We might consider multiple tracing levels:
- No stack trace; used for performance-critical applications
- Trace user-defined function applications (even inlined ones); used for printing the stack trace of e.g. type checking, ecc, or type pattern errors
- Trace all function applications (even generated ones); useful for people debugging the compiler
For the two new function we might be able to reuse `NUMVARIABLERETS` and `CONTEXTSTRING` from the guard primitive.Jordy AalderingJordy Aalderinghttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2355Add DBUG_ASSERT variations to reduce duplicate code2023-11-21T22:08:07ZMichiel VerloopAdd DBUG_ASSERT variations to reduce duplicate codeMany functions start with a bunch of assertions, and rightly so. Making preconditions explicit in dbug_asserts is extremely helpful in stopping the propagation of bugs and conveying the intent to the reader. It is, however, quite repetit...Many functions start with a bunch of assertions, and rightly so. Making preconditions explicit in dbug_asserts is extremely helpful in stopping the propagation of bugs and conveying the intent to the reader. It is, however, quite repetitive. Consider the following, which I've taken from `WLUTupdateBoundNthDim`:
```
DBUG_ASSERT (bound != NULL, "bound may not be null!");
DBUG_ASSERT (*bound != NULL, "bound may not point to null!");
DBUG_ASSERT (NODE_TYPE (*bound) == N_array || NODE_TYPE (*bound) == N_id,
"bound must be an n_id or n_array but is \"%s\"!",
NODE_TEXT (*bound));
DBUG_ASSERT (new_scalar_avis != NULL, "new_scalar_avis may not be null!");
DBUG_ASSERT (vardecs != NULL, "Vardecs may not be null!");
DBUG_ASSERT (preassigns != NULL, "Preassigns may not be null!");
```
Frankly, I'm a bit tired of writing the same helpful debug messages over and over again.
Could we instead create some variations of the assertions to weed out most cases?
```
DBUG_ASSERT_NOT_NULL (bound, *bound, new_scalar_avis, vardecs, preassigns);
DBUG_ASSERT_NODE_IS_OF_TYPES (*bound, N_array, N_id);
```
This could still expand to give helpful messages as before, just now in an automatic manner.
Are the proposed variants feasible? What variants of DBUG_ASSERT should we make?https://gitlab.sac-home.org/sac-group/sac2c/-/issues/2282Streamlining errors and warnings2022-08-13T15:43:04ZMichiel VerloopStreamlining errors and warningsCurrently, all errors, warnings and notes (here: messages) go through the various functions in `/src/libsac2c/global/ctinfo.c`.
For these messages, the file and location are printed if they are present and relevant. For longer messages...Currently, all errors, warnings and notes (here: messages) go through the various functions in `/src/libsac2c/global/ctinfo.c`.
For these messages, the file and location are printed if they are present and relevant. For longer messages, they are split up and joined by a new line and one of the seperators `"abort: "`, `"error: "`, `"warning: "`, `"=> "`, `""`, `" "`.
An example of this can be seen by compiling any valid sac file and giving the `-printstart` compiler argument without also providing `-printstop`:
```
$ sac2c generic_error.sac -printstart 1:prs
error: Please use both -printstart <phase_id> and -printstop <phase_id>
error: If it is only one phase/subphase/cyclephase you want reported
error: then the -printstart and -printstop options should be identical.
compilation failed while Loading SAC program, 1 error(s).
```
If multiple such errors appear after each other, it's impossible for a computer to tell where the first error ends and the second error begins. For humans, I argue the distinction between the two errors wouldn't be immediately obvious either.
Additionally, type errors and SAC optimization errors currently differ in format from the other errors for no discernable reason.
In an effort to make the messages from the compiler parsable by regexes without ambiguity and to increase readability, I propose the following:
* The error message is only printed on the first line if the message bears no location information.
* The error message is always printed on a subsequent line if the file, line and/or column is known.
* The message header (abort/error/warning) is included in the function that determines where to place line breaks.
* Type errors are unified with the other errors.
* We capitalize the message headers and 'compilation' properly. (Arguably not important but this bugs me more than it should)
<details><summary>Current vs proposed message forms (click to expand)</summary>
<details><summary>Errors without location information</summary>
Current:
```
$ sac2c generic_error.sac -printstart 1:prs
error: Please use both -printstart <phase_id> and -printstop <phase_id>
error: If it is only one phase/subphase/cyclephase you want reported
error: then the -printstart and -printstop options should be identical.
compilation failed while Loading SAC program, 1 error(s).
```
Proposed:
```
$ sac2c generic_error.sac -printstart 1:prs
Error: Please use both -printstart <phase_id> and -printstop <phase_id>
If it is only one phase/subphase/cyclephase you want reported
then the -printstart and -printstop options should be identical.
Compilation failed while Loading SAC program, 1 error(s).
```
</details>
<details><summary>Errors with line information</summary>
Current:
```
$ sac2c overload_error.sac
./overload_error.sac 10 abort: Cannot overload functions of arity 0
compilation failed while Converting to static single assignment form.
```
Proposed:
```
$ sac2c overload_error.sac
./overload_error.sac 10 abort:
Cannot overload functions of arity 0
Compilation failed while Converting to static single assignment form.
```
</details>
<details><summary>Errors line and column information</summary>
Current:
```
$ sac2c syntax_error.sac
./syntax_error.sac:7:12: error:
=> token `}' expected, `f' token found
./syntax_error.sac:7:12: error:
=> type expected, `f' found
./syntax_error.sac:9:1: error:
=> function body or semicolon expected
abort: Failed to construct a syntax tree for `syntax_error.sac'
compilation failed while Loading SAC program, 3 error(s).
```
Proposed:
```
$ sac2c syntax_error.sac
./syntax_error.sac:7:12: error:
token `}' expected, `f' token found
./syntax_error.sac:7:12: error:
type expected, `f' found
./syntax_error.sac:9:1: error:
function body or semicolon expected
Abort: Failed to construct a syntax tree for `syntax_error.sac'
Compilation failed while Loading SAC program, 3 error(s).
```
</details>
</details>
I am still unsure what to do about SAC optimization errors. For the purposes of easily detecting them, I'd like to give them a special header like `optimization error`. Other than that, I'm told that finding the location in the source code instead of generated code is a worth a thesis on its own, so we probably can't make those more kind to the users.Michiel VerloopMichiel Verloophttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2241reallocation within outer loop (situation with livermore loop 8)2018-11-21T15:46:18ZHans-Nikolai Viessmannreallocation within outer loop (situation with livermore loop 8)The following example [reallocation-example.sac](/uploads/7bdd0534aae02881f8bd0b0b2437e9bd/reallocation-example.sac), performs some array scalar modification within a double loop nesting. The outer loop forces a repetition of the array m...The following example [reallocation-example.sac](/uploads/7bdd0534aae02881f8bd0b0b2437e9bd/reallocation-example.sac), performs some array scalar modification within a double loop nesting. The outer loop forces a repetition of the array modification which is happening in the inner loop. When we compile with flags `-DBODY -bmem`, we can see that for the outermost loop:
```
int[101] _MAIN::_dup_587_main__Loop_4( int{1} y { ,NN } , int[101] u1 { ,NN } , int i { ,NN } )
{
...
_emlr_6056_y = _alloc_( 1, _dim_A_( y), _shape_A_( y));
_emlr_6057_y = _fill_( _copy_( y), _emlr_6056_y);
_emlr_6054_u1 = _alloc_( 1, _dim_A_( u1), _shape_A_( u1));
_emlr_6055_u1 = _fill_( _copy_( u1), _emlr_6054_u1);
_pinl_588_u1n__SSA0_1 = _MAIN::_dup_589_main__Loop_2( u1, _emlr_6055_u1, _emlr_6057_y) ;
...
}
```
on each iteration we copy `u1` to `_emlr_6055_u1`, meaning on each iteration we create an additional allocation. We see this situation within the Livermore Loop 8 C variant, where we have a triple nesting of loops. Because we are in essence doing `a = op (a)` for the inner loop, we should be able to avoid the extra allocation by performing a buffer swap.
For the current example, this can be done manually be defining our inner loop operation as `b = op (a); a = b;`, where `b` is defined outside the outer loop. If we compile with `-DBODY -DLIFT -bmem`, we get:
```
int[101] _MAIN::_dup_587_main__Loop_4( int{1} y { ,NN } , int[101] u1 { ,NN } , int[101] u1n { ,NN } , int i { ,NN } )
{
...
_emlr_6056_y = _alloc_( 1, _dim_A_( y), _shape_A_( y));
_emlr_6057_y = _fill_( _copy_( y), _emlr_6056_y);
_emlr_6054_u1n = u1n;
_emlr_6055_u1n = _fill_( _noop_( u1n), _emlr_6054_u1n);
_pinl_588_u1n__SSA0_1 = _MAIN::_dup_589_main__Loop_2( u1, _emlr_6055_u1n, _emlr_6057_y) ;
...
}
```
No we no longer perform an allocation/copy, but pass in the extra buffer and reuse it within the outer loop.
It would be nice to do this automatically within the compiler. The attached example also shows a similar case with the inner loop occurring within a separate function. Here though the manual trick from above _does not_ work.https://gitlab.sac-home.org/sac-group/sac2c/-/issues/2237We should build stdlib with installed sac2c2019-02-25T15:50:55ZHans-Nikolai ViessmannWe should build stdlib with installed sac2cThere have been some issues when compiling the stdlib outside of the masterrun. Typically headers give off warnings and errors. This is caused by `config.h` not being included in as part of the install target.
We have two choices:
* we...There have been some issues when compiling the stdlib outside of the masterrun. Typically headers give off warnings and errors. This is caused by `config.h` not being included in as part of the install target.
We have two choices:
* we include `config.h` as part of the install target - NTL lib for instance does this
* we extend the masterrun to install sac2c, and then compile sac2c.
Though we can include `config.h`, its functions is for when we build the runtime-libraries and often is system specific. Including it in the install target means it also get packages... I'm not sure if this might lead to conflict due to differing system configurations.
Updating the masterrun is fairly straightforward... we can do this first I think.https://gitlab.sac-home.org/sac-group/sac2c/-/issues/2225extend masterrun to build sac2c with/without various features2019-09-26T13:18:39ZHans-Nikolai Viessmannextend masterrun to build sac2c with/without various featuresThis issue was spawned from the MR !43 which made it evident that we need to extend the masterrun to build `sac2c` with or without various combinations of features. This should hopefully more quickly reveal problems like the one solved b...This issue was spawned from the MR !43 which made it evident that we need to extend the masterrun to build `sac2c` with or without various combinations of features. This should hopefully more quickly reveal problems like the one solved by the MR.
It is unclear though what the best way of doing this is; either we extend `.gitlab-ci.yml` to build sac2c with different feature flags, or we run a few more docker images with various installs. Are there other possibilities?https://gitlab.sac-home.org/sac-group/sac2c/-/issues/2224Slight name confusion on sac2c binaries2018-04-30T22:17:12ZRobert BerneckySlight name confusion on sac2c binariesThe DEBUG version of sac2c is called sac2c_d. This is good.
The RELEASE version of sac2c is called sac2c_p. This is bad. Presumably, it
meant PRODUCTION in the bad old days...
If we rename the RELEASE version to be sac2c_r, the name wil...The DEBUG version of sac2c is called sac2c_d. This is good.
The RELEASE version of sac2c is called sac2c_p. This is bad. Presumably, it
meant PRODUCTION in the bad old days...
If we rename the RELEASE version to be sac2c_r, the name will make more sense.https://gitlab.sac-home.org/sac-group/sac2c/-/issues/2221[gitlab CI] Build stdlib using sac2c package2019-02-08T14:57:18ZArtem Shinkarov[gitlab CI] Build stdlib using sac2c packageCurrently, as a part of CI pipeline, we always build stdlib using sac2c binaries directly from the working build directory.
The problem with this is that we never test whether resulting package is operational or not.
It would be a better...Currently, as a part of CI pipeline, we always build stdlib using sac2c binaries directly from the working build directory.
The problem with this is that we never test whether resulting package is operational or not.
It would be a better idea to extend the pipeline as follows:
1. Compile sac2c
2. Create sac2c package
3. Install sac2c package & build stdlib
This would allow to identify the cases when packages are not fully operational.Hans-Nikolai ViessmannHans-Nikolai Viessmannhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2220Need more distinct package file names2017-12-13T15:07:23ZHans-Nikolai ViessmannNeed more distinct package file namesAfter merge requests like !35, it has become clear that the package generation can cause unintended overwrites of existing package blobs on the release server. A possible solution would be to append a timestamp to the name, or create a n...After merge requests like !35, it has become clear that the package generation can cause unintended overwrites of existing package blobs on the release server. A possible solution would be to append a timestamp to the name, or create a new directory with the timestamp as its name.https://gitlab.sac-home.org/sac-group/sac2c/-/issues/2219Scheduled weekly packages should have different name to distinguish them.2019-02-08T14:57:32ZHans-Nikolai ViessmannScheduled weekly packages should have different name to distinguish them.Currently we jut use the default name given by CPack. We can override this with the `CPACK_PACKAGE_FILE_NAME` variable, making the weekly packages distinguishable from normal releasee packages.Currently we jut use the default name given by CPack. We can override this with the `CPACK_PACKAGE_FILE_NAME` variable, making the weekly packages distinguishable from normal releasee packages.Hans-Nikolai ViessmannHans-Nikolai Viessmann