sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:37:19Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1306Type relation syntax incompatible with language2017-11-19T20:37:19ZClemens GrelckType relation syntax incompatible with language| | |
| --- | --- |
| Bugzilla Link | [751](http://bugs.sac-home.org/show_bug.cgi?id=751) |
| Created on | Sep 27, 2010 04:50 |
| Version | svn |
| OS | All |
| Architecture | All |
## Extended Description
<pre>The syntax invented fo...| | |
| --- | --- |
| Bugzilla Link | [751](http://bugs.sac-home.org/show_bug.cgi?id=751) |
| Created on | Sep 27, 2010 04:50 |
| Version | svn |
| OS | All |
| Architecture | All |
## Extended Description
<pre>The syntax invented for type relations using operators like .* .< .+
is incompatible with essential parts of the language otherwise, like
for instance the dots in generators.
I suggest to use a different syntax for type relations, e.g. ".*.".
That would be easy to scan and should avoid conflicts with existing
uses of the dot.
Currently, the parser allows spaces in between the dot and the combinator
to resolve conflicts. This can't be anything but a temporary fix.</pre>Santanu Kumar DashSantanu Kumar Dashhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1282Floating point fractions must have leading zero, or wrong answer2017-11-19T20:35:29ZRobert BerneckyFloating point fractions must have leading zero, or wrong answer| | |
| --- | --- |
| Bugzilla Link | [1196](http://bugs.sac-home.org/show_bug.cgi?id=1196) |
| Created on | Jun 26, 2017 15:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [0001-Fixes-1196.patch](/uploads/3...| | |
| --- | --- |
| Bugzilla Link | [1196](http://bugs.sac-home.org/show_bug.cgi?id=1196) |
| Created on | Jun 26, 2017 15:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [0001-Fixes-1196.patch](/uploads/332ca7ffc0f283db8e49ff1e0759731e/0001-Fixes-1196.patch) |
## Extended Description
<pre>The difference in behavior between these two examples seems
very wrong to me.
If it's a bug, it should be fixed. If it's part of the language
definition, the definition is wrong and should be fixed.
cat bugparser.sac
int main()
{
y = 0.0012;
StdIO::print(y);
y = .0012;
StdIO::print(y);
return(0);
}
sac@rattler:~/sac/testsuite/optimizations/pwlf$ sac2c bugparser.sac -v1
sac@rattler:~/sac/testsuite/optimizations/pwlf$ a.out; echo $?
Dimension: 0
Shape : < >
0.0012
Dimension: 0
Shape : < >
0
0
sac2c -V
sac2c 1.2-beta-BlackForest-542-g022cd
build-type: DEBUG
built-by: "sac" at 2017-06-25T17:37:57
I think it's a parser bug:
cat bugparser.sac
int main()
{
x = 0.0012;
StdIO::print(x);
y = .0012;
StdIO::print(y);
z = _sub_SxS_( x, y);
StdIO::print(z);
return(0);
}
sac@rattler:~/sac/testsuite/optimizations/pwlf$ sac2c bugparser.sac -v1
./bugparser.sac 1 error: All instances of "main" contain type errors
error: line 10 in file ./bugparser.sac:
error: Element types of argument #1 and argument #2 of "_sub_SxS_" should be
error: identical; types found: double{0.0...} and int{0}
compilation failed while Running type inference system, 1 error(s).</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1278#pragma noinline not working as expected2017-11-19T20:35:15ZHans-Nikolai Viessmann#pragma noinline not working as expected| | |
| --- | --- |
| Bugzilla Link | [1175](http://bugs.sac-home.org/show_bug.cgi?id=1175) |
| Created on | Nov 23, 2015 23:54 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Given a function id...| | |
| --- | --- |
| Bugzilla Link | [1175](http://bugs.sac-home.org/show_bug.cgi?id=1175) |
| Created on | Nov 23, 2015 23:54 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Given a function id():
int[*] id(int[*] a)
{ return a; }
#pragma noinline
Using `#pragma noinline' to prevent any inlining (via AINL) does not have the
intended effect - id() is selected for inlining.
Tracing though the compilations steps, the issue arises from libsac2c/scanparse/resolvepragma.c where the traversal (called RSP) does *not* traverse into ordinary N_fundef, only those linked to MODULE_FUNDECS, which means that the pragma is never resolved and the FUNDEF_NOINLINE flag is never set.
Looking through the RSP reversal, it becomes clear that it is only designed to handle external declarations, with asserts existing within RSPfundef() to ensure that only fundefs with ISEXTERN are traversed/modified.
My questions is, why are the pragmas of external declarations only 'resolved' and not all function declarations?</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1098Specialize directive requires parameter names2017-11-19T20:22:02ZClemens GrelckSpecialize directive requires parameter names| | |
| --- | --- |
| Bugzilla Link | [878](http://bugs.sac-home.org/show_bug.cgi?id=878) |
| Created on | Oct 07, 2011 19:41 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>Currently, the speciali...| | |
| --- | --- |
| Bugzilla Link | [878](http://bugs.sac-home.org/show_bug.cgi?id=878) |
| Created on | Oct 07, 2011 19:41 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>Currently, the specialization directives need both a return type and parameter names in addition to types. In particular, the latter is counter-intuitive for C programmers. This should be easy to fix in the parser.
The return type(s) could be made optional as they are not relevant in the specialisation. Likewise, the names of parameters.
We should also consider to make the specialisation directive a proper pragma:
#pragma specialize blaBlub( int[10,10], float)
instead of the current syntax. Both SAC and C provide pragmas for exactly this kind of purpose.
All these proposals are not particularly urgent, but would be a few mosaic stones in making SAC more customer-friendly and, with respect to the pragma, a bit more consistent.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1028Parser fails to parse structs2017-11-19T20:17:50ZClemens GrelckParser fails to parse structs| | |
| --- | --- |
| Bugzilla Link | [977](http://bugs.sac-home.org/show_bug.cgi?id=977) |
| Created on | Jun 12, 2012 17:52 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [struct.sac](/uploads/d2af2d2cb9d399ff...| | |
| --- | --- |
| Bugzilla Link | [977](http://bugs.sac-home.org/show_bug.cgi?id=977) |
| Created on | Jun 12, 2012 17:52 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [struct.sac](/uploads/d2af2d2cb9d399ff98d6b468ba46e350/struct.sac) |
## Extended Description
Created an attachment (id=901)
Example code with struct definitions
Summary says it all.
Structs are on our list for the DevCamp, so it is paramount that the parser accepts the code.Artem ShinkarovArtem Shinkarovhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1027UTmstruct parse error lacks fault isolation info: "illegal shape spec..."2017-11-19T20:17:46ZRobert BerneckyUTmstruct parse error lacks fault isolation info: "illegal shape spec..."| | |
| --- | --- |
| Bugzilla Link | [968](http://bugs.sac-home.org/show_bug.cgi?id=968) |
| Created on | Jun 04, 2012 14:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/354a4c02f154f720...| | |
| --- | --- |
| Bugzilla Link | [968](http://bugs.sac-home.org/show_bug.cgi?id=968) |
| Created on | Jun 04, 2012 14:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/354a4c02f154f7201f528f8b9b15bcc1/crud.sac) |
## Extended Description
<pre>Created an attachment (id=893)
source code to reproduce fault
**** Parsing input file ...
error: illegal shape specification
ABORT: Failed to construct a syntax tree for `crud.sac'
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17866 linux-gnu_x86_64
(Mon Jun 4 08:50:18 EDT 2012 by sac)
A source code line number would help here.</pre>Artem ShinkarovArtem Shinkarov