sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-23T23:25:17Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2212stdlib's modules {SDL,SDL2} use outdated SDL1.22017-11-23T23:25:17ZRaphael 'kena' Possstdlib's modules {SDL,SDL2} use outdated SDL1.2| | |
| --- | --- |
| Bugzilla Link | [1168](http://bugs.sac-home.org/show_bug.cgi?id=1168) |
| Created on | Nov 03, 2015 17:13 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
SDL 1.2 is seriously depre...| | |
| --- | --- |
| Bugzilla Link | [1168](http://bugs.sac-home.org/show_bug.cgi?id=1168) |
| Created on | Nov 03, 2015 17:13 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
SDL 1.2 is seriously deprecated and simply does not work on a number of modern platforms. To ensure that SAC's SDL modules continue to exist/work, the code should be adapted to use the SDL 2.x APIs.BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2209Demo 'sac_from_c' does not compile2018-11-23T14:46:58ZHans-Nikolai ViessmannDemo 'sac_from_c' does not compile| | |
| --- | --- |
| Bugzilla Link | [1143](http://bugs.sac-home.org/show_bug.cgi?id=1143) |
| Created on | Nov 20, 2014 16:53 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>## System D...| | |
| --- | --- |
| Bugzilla Link | [1143](http://bugs.sac-home.org/show_bug.cgi?id=1143) |
| Created on | Nov 20, 2014 16:53 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>## System Details ##
uname -a - Linux 2.6.32-431.20.3.el6.x86_64
#1 SMP Thu Jun 19 14:01:59 CDT 2014 x86_64 GNU/Linux
distro - Scientific (RedHat) Linux 6.5
## SAC Details ##
revision - 18508 devel
stdlib - compiled as 'MODE=lean make mt'
## Problem ##
Tried to compile the 'sac_from_c' demo application (sac/demos/basics/sac_from_c).
Both the sac2c and sac4c processes completed without error. An error was given
when compiling the C program which links to the SAC C-lib.
## Additional ##
I had to edit the Makefile somewhat due to errors regarding the private heap
manager. The relevant line that I changed is 11; it now reads as:
$(CC) -o $* $*.c `sac4c -nophm Sum -ccflags` `sac4c -nophm Sum -ldflags` -pthread
## Error Message ##
gcc -o summarizer summarizer.c `sac4c -nophm Sum -ccflags` `sac4c -nophm Sum -ldflags` -pthread
./libcwrapper.so: undefined reference to `SACARGcopyDataInternal'
./libcwrapper.so: undefined reference to `SACARGfreeDataInternal'
collect2: error: ld returned 1 exit status
## Steps to Reproduce ##
1. cd sac/demos/basics/sac_from_c/
2. make
## Workaround (why?) ##
I wrapped the Structures::sum function in another function, 'mysum':
module Sum;
import Structures : {sum};
export {mysum};
int[] mysum(int[*] vector)
{
a = sum(vector);
return(a);
}
and changed the relevant line in summarizer.c. Doing this there are no errors
reported and the resulting binary runs.
## Extra ##
The output of 'nm -a libcwrapper.so':
0000000000202398 b .bss
0000000000000000 n .comment
00000000002020c0 d .ctors
0000000000202390 d .data
00000000002020d0 d .dtors
00000000002020e8 d .dynamic
00000000000006e0 r .dynstr
00000000000002a8 r .dynsym
0000000000001fe0 r .eh_frame
0000000000001fa0 r .eh_frame_hdr
0000000000001e58 t .fini
0000000000000a64 r .gnu.version
0000000000000ac0 r .gnu.version_r
0000000000202268 d .got
0000000000202298 d .got.plt
0000000000000158 r .hash
0000000000000e28 t .init
00000000002020e0 d .jcr
0000000000000e40 t .plt
0000000000000ae0 r .rela.dyn
0000000000000b88 r .rela.plt
0000000000001e70 r .rodata
0000000000001010 t .text
U SACARGcopyDataInternal
0000000000001d44 T SACARGcopyDataUdt
U SACARGfreeDataInternal
0000000000001dbc T SACARGfreeDataUdt
U SACARGisDouble
U SACARGisFloat
U SACARGisInt
U SACARGisUdt
U SACARGunwrapDouble
U SACARGunwrapFloat
U SACARGunwrapInt
U SACARGunwrapUdtDouble
U SACARGwrapDouble
U SACARGwrapFloat
U SACARGwrapInt
U SACARGwrapUdtDouble
U SAC_HM_MallocAnyChunk_at
U SAC_HM_MallocAnyChunk_mt
U SAC_HM_MallocAnyChunk_st
0000000000001f20 r SAC_HM_thread_status.2426
U SAC_MT_globally_single
U SAC_RuntimeError
U SAC_RuntimeError_Mult
00000000002023a8 B SAC___CWRAPPER__another_dummy_value_which_is_completely_useless
00000000002023ac B SAC___CWRAPPER__dummy_value_which_is_completely_useless
0000000000001158 T SACcw_Sum__sum1
U SACf_ArrayTransform__sum__d_S
U SACf_ArrayTransform__sum__f_S
U SACf_ArrayTransform__sum__i_S
U SACf_ComplexArrayTransform__sum__SACt_ComplexArrayTransform__complex_S
0000000000001cfd T Sum__sum1
00000000002020e8 a _DYNAMIC
0000000000202298 a _GLOBAL_OFFSET_TABLE_
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
w _Jv_RegisterClasses
00000000002020c8 d __CTOR_END__
00000000002020c0 d __CTOR_LIST__
00000000002020d8 d __DTOR_END__
00000000002020d0 d __DTOR_LIST__
00000000000020b8 r __FRAME_END__
00000000002020e0 d __JCR_END__
00000000002020e0 d __JCR_LIST__
0000000000001f10 r __PRETTY_FUNCTION__.2498
0000000000001f3a r __PRETTY_FUNCTION__.2631
0000000000202398 d __TMC_END__
U __assert_fail@@GLIBC_2.2.5
0000000000202398 A __bss_start
w __cxa_finalize@@GLIBC_2.2.5
0000000000001e20 t __do_global_ctors_aux
00000000000010a0 t __do_global_dtors_aux
0000000000202390 d __dso_handle
w __gmon_start__
0000000000202398 A _edata
00000000002023b0 A _end
0000000000001e58 T _fini
0000000000000e28 T _init
0000000000001010 t call_gmon_start
0000000000202398 b completed.6301
0000000000000000 a crtstuff.c
0000000000000000 a crtstuff.c
0000000000001030 t deregister_tm_clones
00000000002023a0 b dtor_idx.6303
0000000000001120 t frame_dummy
U free@@GLIBC_2.2.5
0000000000001c8f t freeScalarDesc
0000000000000000 a fun1.c
0000000000000000 a fundummy.c
0000000000000000 a globals.c
0000000000000000 a interface.c
0000000000001c18 t makeScalarDesc
U malloc@@GLIBC_2.2.5
0000000000001060 t register_tm_clones
0000000000000000 a sacargcopy.c
0000000000000000 a sacargfree.c
The output of 'nm -a libsac.seq.so | fgrep SACARGfree':
000000000000d59f T SACARGfree
000000000000d57e t SACARGfreeDataInternal
000000000000d2ea t SACARGfreeDataT_bool
000000000000d11c t SACARGfreeDataT_byte
000000000000d32c t SACARGfreeDataT_char
000000000000d36e t SACARGfreeDataT_classtype
000000000000d3b0 t SACARGfreeDataT_dots
000000000000d2a8 t SACARGfreeDataT_double
000000000000d434 t SACARGfreeDataT_double_dev
000000000000d4fa t SACARGfreeDataT_double_dist
000000000000d497 t SACARGfreeDataT_double_shmem
000000000000d266 t SACARGfreeDataT_float
000000000000d3f2 t SACARGfreeDataT_float_dev
000000000000d4b8 t SACARGfreeDataT_float_dist
000000000000d455 t SACARGfreeDataT_float_shmem
000000000000d287 t SACARGfreeDataT_floatvec
000000000000d34d t SACARGfreeDataT_hidden
000000000000d15e t SACARGfreeDataT_int
000000000000d413 t SACARGfreeDataT_int_dev
000000000000d4d9 t SACARGfreeDataT_int_dist
000000000000d476 t SACARGfreeDataT_int_shmem
000000000000d17f t SACARGfreeDataT_long
000000000000d2c9 t SACARGfreeDataT_longdbl
000000000000d1a0 t SACARGfreeDataT_longlong
000000000000d55d t SACARGfreeDataT_nothing
000000000000d53c t SACARGfreeDataT_rc
000000000000d13d t SACARGfreeDataT_short
000000000000d30b t SACARGfreeDataT_str
000000000000d51b t SACARGfreeDataT_sync
000000000000d1c1 t SACARGfreeDataT_ubyte
000000000000d203 t SACARGfreeDataT_uint
000000000000d224 t SACARGfreeDataT_ulong
000000000000d245 t SACARGfreeDataT_ulonglong
000000000000d0fb t SACARGfreeDataT_unknown
000000000000d3d1 t SACARGfreeDataT_user
000000000000d1e2 t SACARGfreeDataT_ushort
000000000000d38f t SACARGfreeDataT_void
Output of 'nm -a libsac.seq.so | fgrep SACARGcopy':
000000000000e0bc T SACARGcopy
U SACARGcopyDataUdt</pre>Hans-Nikolai ViessmannHans-Nikolai Viessmannhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2208gaussFilter delivers only values of 2552017-11-23T23:24:59ZVolkmar WiesergaussFilter delivers only values of 255| | |
| --- | --- |
| Bugzilla Link | [1105](http://bugs.sac-home.org/show_bug.cgi?id=1105) |
| Created on | Dec 10, 2013 13:57 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I've tried ...| | |
| --- | --- |
| Bugzilla Link | [1105](http://bugs.sac-home.org/show_bug.cgi?id=1105) |
| Created on | Dec 10, 2013 13:57 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I've tried to execute the gaussFilter example in sac/tutorial/L7_case_study_image-filter. I am using the compiler from the repository and I compiled the program as follows:
sac2c -DSOBEL -DSIMPLECLOCK -DRAWIMAGE image_filter.sac -o image_filter
and execution
./image_filter -c 2 -i ./testimages/sail.fibre -o ./outimage
After execution the outimage only contains values of 255</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2204Printf crashes nvcc on CUDA targets2017-11-23T23:24:38ZMiguel Sousa DiogoPrintf crashes nvcc on CUDA targets| | |
| --- | --- |
| Bugzilla Link | [941](http://bugs.sac-home.org/show_bug.cgi?id=941) |
| Created on | Mar 27, 2012 15:21 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>Using the printf functi...| | |
| --- | --- |
| Bugzilla Link | [941](http://bugs.sac-home.org/show_bug.cgi?id=941) |
| Created on | Mar 27, 2012 15:21 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>Using the printf function and compiling SaC for CUDA generates invalid CUDA code, which crashes the nvcc compiler. A simple hello-world program is enough to cause this crash:
----------------------------
$ sac2c -target cuda world.sac
...
** 22: Creating binary code ...
**** Handling dependencies ...
**** Invoking C compiler ...
a.out.cu(204): error: more than one instance of overloaded function "printf" has "C" linkage
a.out.cu(685): warning: variable "SACp_tcp_924__emal_696__flat_1__shp0" was set but never used
a.out.cu(686): warning: variable "SACp_tcp_924__emal_696__flat_1__sz" was set but never used
a.out.cu(687): warning: variable "SACp_tcp_924__emal_696__flat_1__dim" was declared but never referenced
1 error detected in the compilation of "/tmp/tmpxft_00009db2_00000000-4_a.out.cpp1.ii".
ABORT: System failed to execute shell command
...
with exit code 2
*** Compilation failed ***
*** Exit code 373 (Creating binary code)
*** 1 Error(s), 4 Warning(s)
----------------------------
Contents of world.sac:
----------------------------
use StdIO: all;
use Array: all;
int main() {
printf( "Hello World!\n");
return(0); }
----------------------------
Using sac2c from svn, nvcc version 4.1, and gcc version 4.5.3.</pre>Jing GuoJing Guohttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2202ArrayFormat show() fails on double scalar/vector (at least)2017-11-23T23:24:29ZRobert BerneckyArrayFormat show() fails on double scalar/vector (at least)| | |
| --- | --- |
| Bugzilla Link | [936](http://bugs.sac-home.org/show_bug.cgi?id=936) |
| Created on | Mar 19, 2012 21:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Array formatting fail...| | |
| --- | --- |
| Bugzilla Link | [936](http://bugs.sac-home.org/show_bug.cgi?id=936) |
| Created on | Mar 19, 2012 21:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Array formatting fails to print double scalars and vectors correctly,
in both show() and format() flavors. This is a long-standing bug.
This function: cat crud.sac
use Array: all;
use StdIO : all;
use ArrayFormat: all;
int main()
{
print(format(42.5));
show( 42.5);
print( 42.5);
show( [42.5]);
return(0);
}
produces this output:
a.out
Dimension: 1
Shape : < 22>
< >
Dimension: 0
Shape : < >
42.5
4
Not even close.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2189compiler crashed - WLF bug when folding across different frame-shapes2017-11-23T23:23:19ZNilesh Karavadaracompiler crashed - WLF bug when folding across different frame-shapes| | |
| --- | --- |
| Bugzilla Link | [820](http://bugs.sac-home.org/show_bug.cgi?id=820) |
| Created on | Jan 25, 2011 09:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [slice.sacbugreport](/uploads/324848...| | |
| --- | --- |
| Bugzilla Link | [820](http://bugs.sac-home.org/show_bug.cgi?id=820) |
| Created on | Jan 25, 2011 09:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [slice.sacbugreport](/uploads/3248489b063509ead2c7838faf3ac4ea/slice.sacbugreport), [bug820.sac](/uploads/60bf77a4d8f8a49dacff819415632f22/bug820.sac) |
## Extended Description
<pre>Created an attachment (id=792)
Bug Report
/**********************************************************************
*
* SAC bug report: slice.sacbugreport
*
**********************************************************************
*
* Automatically generated on Tue Jan 25 09:19:38 GMT 2011
*
* using sac2c v1.00-beta (Haggis And Apple) rev 17286 for linux-gnu_i686
* built Mon Jan 24 17:32:53 GMT 2011.
* by user nkk on host obelix for linux-gnu.
*
* The compiler was called by
* sac2c -o slice slice.sac
*
* The compiler crashed in
* phase: opt (Running SAC optimizations)
* sub phase: cyc (Optimization cycle)
* cycle phase: wlf (Applying with-loop folding)
* cycle instance: 1
*
* What follows is the contents of slice.sac.
*
**********************************************************************/</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2187stdlib won't compile with the SUN compiler2017-11-19T22:05:51ZRoeland Doumastdlib won't compile with the SUN compiler| | |
| --- | --- |
| Bugzilla Link | [816](http://bugs.sac-home.org/show_bug.cgi?id=816) |
| Created on | Jan 07, 2011 12:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
This is a tracker bug to a...| | |
| --- | --- |
| Bugzilla Link | [816](http://bugs.sac-home.org/show_bug.cgi?id=816) |
| Created on | Jan 07, 2011 12:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
This is a tracker bug to allow compilation of the stdlib with suncc.Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2184Excluded APEX code2017-11-19T22:05:35ZDaniel RollsExcluded APEX code| | |
| --- | --- |
| Bugzilla Link | [793](http://bugs.sac-home.org/show_bug.cgi?id=793) |
| Created on | Dec 01, 2010 11:46 |
| Version | unspecified |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>I have excluded...| | |
| --- | --- |
| Bugzilla Link | [793](http://bugs.sac-home.org/show_bug.cgi?id=793) |
| Created on | Dec 01, 2010 11:46 |
| Version | unspecified |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>I have excluded the source code from APEX for the failures listed below. I am raising this bug so that these actions are not forgotten. Do what you want with it. My commit log follows.
------------------------------------------------------------------------
r1410 | dsr | 2010-12-01 11:37:04 +0000 (Wed, 01 Dec 2010) | 57 lines
I have excluded the sac files for all these errors from APEX in the
Masterrun. Hopefully now we will be able to clearly see any new problems
that are introduced!
************************************************************
Errors apex (product version):
************************************************************
OOOOOOOPS, your program crashed the compiler 8-((
OOOOOOOPS, your program crashed the compiler 8-((
OOOOOOOPS, your program crashed the compiler 8-((
OOOOOOOPS, your program crashed the compiler 8-((
make[6]: [dtb] Error 87 (ignored)
make[6]: [dtb_mt] Error 87 (ignored)
make[6]: [dtb2] Error 87 (ignored)
make[6]: [dtb2_mt] Error 87 (ignored)
make[6]: *** [mdiv2] Aborted
make[6]: *** [mdiv2_mt] Aborted
make[6]: *** [mdiv2AKD] Aborted
make[6]: *** [mdiv2AKD_mt] Aborted
make[6]: [tomcatv2] Error 87 (ignored)
make[6]: [tomcatv2_mt] Error 87 (ignored)
make[6]: [UTClock] Error 51 (ignored)
make[6]: [UTClock_mt] Error 51 (ignored)
make[6]: [UTReverse] Error 87 (ignored)
make[6]: [UTReverse_mt] Error 87 (ignored)
make[6]: [UTRotate234] Error 87 (ignored)
make[6]: [UTRotate234_mt] Error 87 (ignored)
************************************************************
Warnings apex (product version):
************************************************************
.nmo.d:
-- OTHER WARNINGS FOUND
nmo.sac:
-- OTHER WARNINGS FOUND
nmo.sac:
-- OTHER WARNINGS FOUND
.tomcatv.d:
-- OTHER WARNINGS FOUND
tomcatv.sac:
-- OTHER WARNINGS FOUND
tomcatv.sac:
-- OTHER WARNINGS FOUND
.tomcatv2.d:
-- OTHER WARNINGS FOUND
tomcatv2.sac:
-- OTHER WARNINGS FOUND
tomcatv2.sac:
-- OTHER WARNINGS FOUND
.UTTranspose.d:
-- OTHER WARNINGS FOUND
UTTranspose.sac:
-- OTHER WARNINGS FOUND
UTTranspose.sac:
-- OTHER WARNINGS FOUND</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2174Livermore Loop 13 SAC vs. C code not equivalent2017-11-19T22:04:41ZRobert BerneckyLivermore Loop 13 SAC vs. C code not equivalent| | |
| --- | --- |
| Bugzilla Link | [708](http://bugs.sac-home.org/show_bug.cgi?id=708) |
| Created on | May 11, 2010 19:19 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The repositor...| | |
| --- | --- |
| Bugzilla Link | [708](http://bugs.sac-home.org/show_bug.cgi?id=708) |
| Created on | May 11, 2010 19:19 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The repository copy of SAC Loop 13 code reads its input from a file;
the C version has the input hard-coded into the source program.
The entire SAC benchmark executes in about 36msec, and the C
version in 7msec.
One of the benchmarks should be changed, so that they are equivalent.
Until that time, any performance measurements on Loop13 should be considered
bogus.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2171Potential memory leak in StringArray2021-08-31T11:47:07ZDaniel RollsPotential memory leak in StringArray| | |
| --- | --- |
| Bugzilla Link | [616](http://bugs.sac-home.org/show_bug.cgi?id=616) |
| Created on | Dec 11, 2009 00:07 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [testStringArray3.sac](/uploads/9943d5...| | |
| --- | --- |
| Bugzilla Link | [616](http://bugs.sac-home.org/show_bug.cgi?id=616) |
| Created on | Dec 11, 2009 00:07 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [testStringArray3.sac](/uploads/9943d571604e4ae398fe1431648afb4d/testStringArray3.sac) |
## Extended Description
<pre>Created an attachment (id=619)
testcase (SaC source)
The attached test case when run with
sac2c -check ctb testStringArray3.sac && a.out
triggers a segfault in the first call to free in
modules/structures/src/StringArray/sel.c. Carl and I fixed this for now by
commenting out this line but don't know how this works. We may have even
inadvertently created a memory leak. To reproduce the problem first uncomment
the call to SAC_ND_DEC_RC_FREE and run the test case as described above.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2141TC ignores type error in dead code2017-11-19T22:01:42ZClemens GrelckTC ignores type error in dead code| | |
| --- | --- |
| Bugzilla Link | [796](http://bugs.sac-home.org/show_bug.cgi?id=796) |
| Created on | Dec 08, 2010 15:35 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>In the code from the ...| | |
| --- | --- |
| Bugzilla Link | [796](http://bugs.sac-home.org/show_bug.cgi?id=796) |
| Created on | Dec 08, 2010 15:35 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>In the code from the latest SAC user:
import Array: all;
import StdIO: all;
typedef int[1] array;
int main()
{
array x;
x = 10;
#ifndef EXCLUDE_ERRORS
print(x);
#endif
return(0);
}
the obvious type error goes away if x becomes dead code.
I traced this in so far as until the tc there is a proper
type conversion, which in my view should lead to an error
message, but after type checking this is gone.
This is very counter-intuitive for the user and an error
for me.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2140LIR apparently failing to operate on APEX Floyd benchmark2017-11-19T22:01:39ZRobert BerneckyLIR apparently failing to operate on APEX Floyd benchmark| | |
| --- | --- |
| Bugzilla Link | [1008](http://bugs.sac-home.org/show_bug.cgi?id=1008) |
| Created on | Jul 20, 2012 16:40 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/94b1bf45c55c07...| | |
| --- | --- |
| Bugzilla Link | [1008](http://bugs.sac-home.org/show_bug.cgi?id=1008) |
| Created on | Jul 20, 2012 16:40 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/94b1bf45c55c0700abb1c245c3e8491b/crud.sac), [floyd.sac](/uploads/b7503563d5a065a86cc8f079aa47aac1/floyd.sac), [floyd2.sac](/uploads/731f3a5ebc00728d28503a95aaeca227/floyd2.sac) |
## Extended Description
<pre>Created an attachment (id=920)
source code to reproduce fault
The APL version of a Floyd's shortest path benchmark
runs VERY slowly. When I looked at the IL, I saw that we generate
WLs within the LACFUNs. The offending APL code looks like this:
[4] siz←⍴D
[5] :For k :In ⍳siz[0]
[6] :For i :In ⍳siz[0]
[7] :For j :In ⍳siz[1]
[8] D[i;j]←(D[i;k]+D[k;j])⌊D[i;j]
[9] :EndFor
[10] :EndFor
[11]:EndFor
The IL generates ⍳siz[0] WITHIN the LOOPFUNs, and although at
least one of them has been touched by LIR,they have not been lifted
entirely out of the LOOPFUNs. The result is extremely slow code.
When I rewrote the Floyd code, it ran quick like a bunny:
inline double[.,.] floydXDD(double[.,.] D ,int QUADio)
{
siz = shape(D)[0];
for( k=0; k<siz; k++) {
for( i=0; i<siz; i++) {
for( j=0; j<siz; j++) {
D[i,j] = min(D[i,k]+D[k,j], D[i,j]);
}
}
}
return( D);
}
However, the underlying problem in LIR is needs fixing here.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18091:MODIFIED linux-gnu_x86_64
(Thu Jul 19 18:26:07 EDT 2012 by sac)
I'm assigning this to Jara, on the assumption that it's still his
kettle of fish.
BTW, perhaps it's time to svn rm SSALIR.c, now that its functionality
lies elsewhere?</pre>Jaroslav SýkoraJaroslav Sýkorahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2139APEX benchmark shortened snp.sac gets stuck in WLUR during opt cycle 22017-11-19T22:01:34ZRobert BerneckyAPEX benchmark shortened snp.sac gets stuck in WLUR during opt cycle 2| | |
| --- | --- |
| Bugzilla Link | [1050](http://bugs.sac-home.org/show_bug.cgi?id=1050) |
| Created on | Mar 06, 2013 16:17 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/8f0267bd90f82b...| | |
| --- | --- |
| Bugzilla Link | [1050](http://bugs.sac-home.org/show_bug.cgi?id=1050) |
| Created on | Mar 06, 2013 16:17 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/8f0267bd90f82bb97a3b5c43dfccef3f/crud.sac) |
## Extended Description
<pre>Created an attachment (id=951)
source code to reproduce fault
Summary says it all:
**** Optimization cycle pass: 2
****** Optimizing regular function:
****** _MAIN::main( hidden(1), hidden(2), hidden(0)): ...
...
WLUR: -maxwlur 3 would unroll genarray with-loop
WLUR: -maxwlur 3 would unroll genarray with-loop
^CAborted
apex@rattler:~/apex3/benchmks/snp$ vi crud.sac
apex@rattler:~/apex3/benchmks/snp$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18061 linux-gnu_x86_64
(Fri Mar 1 17:24:54 EST 2013 by sac)
apex@rattler:~/apex3/benchmks/snp$ sac2c crud.sac -doawlf -nowlf -v1 -O3 -v4 -maxwlur 1</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2138three dots as arguments unsafer than expected2021-08-30T15:56:59ZSven-Bodo Scholzthree dots as arguments unsafer than expected| | |
| --- | --- |
| Bugzilla Link | [521](http://bugs.sac-home.org/show_bug.cgi?id=521) |
| Created on | Jul 07, 2009 14:45 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/6e449df16f5...| | |
| --- | --- |
| Bugzilla Link | [521](http://bugs.sac-home.org/show_bug.cgi?id=521) |
| Created on | Jul 07, 2009 14:45 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/6e449df16f5940c2e6e5d42fd468ef60/tutu.sac) |
## Extended Description
<pre>Created an attachment (id=549)
source code
compile with -maxspec 0 and the 5.0 will be printed as 0.0000.
The reason for this is that the scalar value comes as AUD and therefore
in boxed form. As it is in ... position of printf, precompile cannot
insert appropriate casts to make sure an unboxed double is passed to the
actual printf implementation.
inlining or specialisations obviously make this problem go away....</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1316conditionals are sometimes over-optimised2017-11-19T20:38:06ZSven-Bodo Scholzconditionals are sometimes over-optimised| | |
| --- | --- |
| Bugzilla Link | [1187](http://bugs.sac-home.org/show_bug.cgi?id=1187) |
| Created on | Jan 12, 2017 16:27 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [sacprelude_d.sacbugreport](/uploads...| | |
| --- | --- |
| Bugzilla Link | [1187](http://bugs.sac-home.org/show_bug.cgi?id=1187) |
| Created on | Jan 12, 2017 16:27 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [sacprelude_d.sacbugreport](/uploads/b8377a445927ee15e870784fc166faeb/sacprelude_d.sacbugreport) |
## Extended Description
<pre>noinline int forever( int x)
{
if( _eq_SxS_( x,0))
res = forever(x);
else
res = 42;
return res;
}
int main() {
return forever( 0);
}
after optimisation yields 42 :-(
What happens is that the type of the function forever is computed as int{42}. The constant folder reacts and throws the conditional away.....</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1315matmul Star algorithm crashes in Phase 152017-11-19T20:38:02ZRobert Berneckymatmul Star algorithm crashes in Phase 15| | |
| --- | --- |
| Bugzilla Link | [1107](http://bugs.sac-home.org/show_bug.cgi?id=1107) |
| Created on | Jan 08, 2014 22:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug1107redux.sac](/uploads/2a6ec2...| | |
| --- | --- |
| Bugzilla Link | [1107](http://bugs.sac-home.org/show_bug.cgi?id=1107) |
| Created on | Jan 08, 2014 22:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug1107redux.sac](/uploads/2a6ec20a4d3bc38eaea46df67cb97377/bug1107redux.sac), [1107.sac](/uploads/f5e9844406d5bd29da67e5d29eebdbf8/1107.sac) |
## Extended Description
<pre>sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18415 linux-gnu_x86_64
(Wed Jan 8 09:37:41 EST 2014 by sac)
cat bugrc.sac
use Array:all;
inline double[+] plusdotmpyDDDStar(double[+]x, double[+]y)
{ /* CDC STAR-100 APL Algorithm for inner product */
rowsx = drop([-1],shape(x));
colsx = shape(x)[[dim(x)-1]];
colsy = shape(y)[[dim(y)-1]];
Zrow = genarray([colsy],0.0d);
/* Parallel over rows of x */
z = with {
(. <= [row] <= .) {
Crow = with {
( [0] <= col < [colsy]) {
newrow = x[row] * y[col];
StdIO::show(newrow);
} : newrow;
} : fold( +, Zrow);
StdIO::show(Crow);
} : Crow;
}: genarray( rowsx, Zrow);
return(z);
}
int main()
{
siz = 5;
x = reshape( [siz,siz], 0.50* tod(iota(siz*siz)));
y = reshape( [siz,siz], 0.75* tod(iota(siz*siz)));
A_31=plusdotmpyDDDStar(x, y);
r = sum( A_31);
StdIO::print( r);
r = ( r== 732904294933574912.000000) ? 0 : 1;
return(r);
}
sac2c bugrc.sac -v1
**** Optimizing reference counting instructions ...
TRAVERSE ERROR: node of type 31:N_id found where 32:N_num was expected!
Compiling with -maxwlur 1 makes this crash not happen.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1314Sac2c product version fails to build sacprelude2017-11-19T20:37:57ZMiguel Sousa DiogoSac2c product version fails to build sacprelude| | |
| --- | --- |
| Bugzilla Link | [924](http://bugs.sac-home.org/show_bug.cgi?id=924) |
| Created on | Feb 27, 2012 13:12 |
| Version | svn |
| OS | MacOS X |
| Architecture | PC |
| Attachments | [sac2c_2012-02-27-130504_MBP-Migas...| | |
| --- | --- |
| Bugzilla Link | [924](http://bugs.sac-home.org/show_bug.cgi?id=924) |
| Created on | Feb 27, 2012 13:12 |
| Version | svn |
| OS | MacOS X |
| Architecture | PC |
| Attachments | [sac2c_2012-02-27-130504_MBP-Migas.crash](/uploads/aaebbf09fa145ba2d6a8632e122f742c/sac2c_2012-02-27-130504_MBP-Migas.crash), [xsacprelude.sacbugreport](/uploads/2515ee68594dfa112455bcff86a14e9b/xsacprelude.sacbugreport), [sac2c_2012-04-23-155505_MBP-Migas.crash](/uploads/d32308b1d4d3059e1331669358cb3f2c/sac2c_2012-04-23-155505_MBP-Migas.crash), [sacprelude.sacbugreport](/uploads/2f9bb6619d5de9d9ab130b919b1fb3e5/sacprelude.sacbugreport) |
## Extended Description
<pre>Created an attachment (id=855)
sac bug report
Running "make prod" from svn fails compiling sacprelude.sac. It's crashing on the constant folding subphase of enhancing with-loops.
I came across this on OS X, I'm not sure if this is a platform specific issue or not. I'm attaching the sac bug report.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1313CSE crash in tjck.sac2017-11-19T20:37:51ZRobert BerneckyCSE crash in tjck.sac| | |
| --- | --- |
| Bugzilla Link | [992](http://bugs.sac-home.org/show_bug.cgi?id=992) |
| Created on | Jul 07, 2012 23:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/394041f63aa86da3...| | |
| --- | --- |
| Bugzilla Link | [992](http://bugs.sac-home.org/show_bug.cgi?id=992) |
| Created on | Jul 07, 2012 23:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/394041f63aa86da3a3211fbf60bd399d/crud.sac) |
## Extended Description
<pre>We crash in CSE during SAACYC, with Build #18045:
cd sac/apex/tjck
svn update .
sac2c tjck.sac -doawlf -nowlf -v4
****** Optimizing regular function:
****** _MAIN::slBII( bool[3], int[.,.]): ...
Inserting symbolic array attributes ...
Eliminating index vectors (split selections) ...
Eliminating common subexpressions ...
OOOOOOOPS, your program crashed the compiler 8-((
I have not looked into this, other than to compile it
with no options; that compiles OK.</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1312"Attempting to read from non-readable memory" slr error on aes.sac2017-11-19T20:37:46ZDaniel Rolls"Attempting to read from non-readable memory" slr error on aes.sac| | |
| --- | --- |
| Bugzilla Link | [658](http://bugs.sac-home.org/show_bug.cgi?id=658) |
| Created on | Jan 10, 2010 22:06 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [aes.sac](/uploads/29cac23db102b7ec2aa...| | |
| --- | --- |
| Bugzilla Link | [658](http://bugs.sac-home.org/show_bug.cgi?id=658) |
| Created on | Jan 10, 2010 22:06 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [aes.sac](/uploads/29cac23db102b7ec2aa894c7e7c1928d/aes.sac), [xaes.sac](/uploads/bab0d82ba69bc6f83df8243864b88caa/xaes.sac) |
## Extended Description
<pre>Created an attachment (id=648)
source code
$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 16710 linux-gnu_i686
(Sat Jan 9 22:21:29 GMT 2010 by dsr)
stdlib version: 1275
slr 2.1.0a
slc 2.1.0a (rev /$Rev: 2539 $)
(binutils-utgcc-gcc:2831-2842-4.4.1p-m1.6p) (mgsim-slc:3183-3186)
With the attached source code run:
sac2c -DSACSL -DITERATE aes.sac -target sl_ppp
slr ./a.out
$ slr ./a.out
SYSTEM.CPU0.DCACHE: Attempting to read from non-readable memory
While executing instruction at 0x000000000100b0a8 in T4 in F4
While executing process system.cpu0.pipeline:default
The error appears immediately after running the slr command.
I am filing this as an SL backend bug after conversation with Carl.</pre>Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1311LS does not support SAA; LACFUN headers result are missing AVIS_SHAPE2017-11-19T20:37:41ZRobert BerneckyLS does not support SAA; LACFUN headers result are missing AVIS_SHAPE| | |
| --- | --- |
| Bugzilla Link | [700](http://bugs.sac-home.org/show_bug.cgi?id=700) |
| Created on | Apr 21, 2010 22:37 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbbAKD.sac](/uploads/13bd5800f1162...| | |
| --- | --- |
| Bugzilla Link | [700](http://bugs.sac-home.org/show_bug.cgi?id=700) |
| Created on | Apr 21, 2010 22:37 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbbAKD.sac](/uploads/13bd5800f116238f77dabc85fff1d815/ipbbAKD.sac) |
## Extended Description
<pre>Created an attachment (id=688)
source code to reproduce fault
In the ongoing battle to kill CYC, we need to extend LS to make it
support SAA. When it moves a value from within a LACFUN to outside it,
it fails to move the AVIS_SHAPE/DIM information for that.
This results in unpleasant failure modes, such as VPid dying.
The attached will fail if compiled with rbe's local sac2c
(the post-Loch Ness fixerupper that is not checked in yet), with these options:
sac2c -ecc -extrema -doawlf -nowlf ipbbAKD.sac
This is partly a place marker so that we remember to do this work.</pre>BugZillaBugZilla