sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2023-01-24T10:39:26Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2258Aliasing analysis fails2023-01-24T10:39:26ZSven-Bodo ScholzAliasing analysis failsLook at this code:
```c
noinline
int[10000], int[10000] foo (int len)
{
a = with {
} : genarray( [len], 2);
if( _eq_SxS_( len, 10000)) {
c = a;
} else {
c = with {
} : genarray( [...Look at this code:
```c
noinline
int[10000], int[10000] foo (int len)
{
a = with {
} : genarray( [len], 2);
if( _eq_SxS_( len, 10000)) {
c = a;
} else {
c = with {
} : genarray( [len], 4);
}
return (a, c);
}
int main()
{
a,c = foo (10000);
b = {iv-> _add_SxS_( _sel_VxA_(iv, a),1)};
return _add_SxS_( _sel_VxA_([2], b), _sel_VxA_([2], c));
}
```
The function foo creates a potential alias here. However, it seems the aliasing analysis does not pick this up.
What happens is that the mem phase decides that the increment in main can be done in place! After the selection into `c`, the runtime system attempts a free for a second time:
```
-sbs-Bodos-IMac-> sac2c MEMORY-error-cuda-managed.sac ; a.out
a.out(38071,0x10ca1edc0) malloc: *** error for object 0x7fe95d800000: pointer being freed was not allocated
a.out(38071,0x10ca1edc0) malloc: *** set a breakpoint in malloc_error_break to debug
Abort
```
```
-sbs-Bodos-IMac-> sac2c -V
sac2c 1.3.3-MijasCosta-578-g3920
build-type: RELEASE
built-by: "sbs" at 2021-04-13T19:54:17
```https://gitlab.sac-home.org/sac-group/sac2c/-/issues/1993-check c issue on WL body conformity constraint2017-11-19T21:47:13ZSven-Bodo Scholz-check c issue on WL body conformity constraint| | |
| --- | --- |
| Bugzilla Link | [440](http://bugs.sac-home.org/show_bug.cgi?id=440) |
| Created on | Jun 23, 2008 21:11 |
| Resolution | FIXED |
| Resolved on | Feb 19, 2009 11:33 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [440](http://bugs.sac-home.org/show_bug.cgi?id=440) |
| Created on | Jun 23, 2008 21:11 |
| Resolution | FIXED |
| Resolved on | Feb 19, 2009 11:33 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [aes.sac](/uploads/183e629c41b40572a245631845ea8b15/aes.sac) |
## Extended Description
<pre>Created an attachment (id=480)
source code
as of sac2c rev 15736
compiling the attached source file with the following options( each of which is crucial to produce the error): -maxspec 0 -noINL -check c
leads to
** 14: Introducing explicit memory management instructions ...
**** AUD/SCL distinction ...
**** Making copy operations explicit ...
**** Removing alias results from conformity checks ...
**** Introducing explicit allocation statements ...
**** Removing dead code ...
**** Inferring reuse candidates ...
**** Activating display of alias information ...
**** Interface aliasing analysis ...
**** Applying loop reuse optimization ...
**** Aliasing analysis ...
**** Removing non-local reuse-candidates ...
**** Removing invalid reuse candidates ...
**** Static reuse ...
**** Introducing reuse branches ...
TRAVERSE ERROR: node of type undefined found where N_assign was expected!
OOOPS your program crashed the compiler 8-((
Please send a bug report to bugs@sac-home.org.</pre>Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1945Syntax error in generated SL code when using async ref counting2017-11-19T21:42:17ZDaniel RollsSyntax error in generated SL code when using async ref counting| | |
| --- | --- |
| Bugzilla Link | [852](http://bugs.sac-home.org/show_bug.cgi?id=852) |
| Created on | Jul 04, 2011 15:21 |
| Resolution | FIXED |
| Resolved on | Jul 04, 2011 17:20 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [852](http://bugs.sac-home.org/show_bug.cgi?id=852) |
| Created on | Jul 04, 2011 15:21 |
| Resolution | FIXED |
| Resolved on | Jul 04, 2011 17:20 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [337236.tar.gz](/uploads/695845e0131a4d03a80918e1cafaa3c8/337236.tar.gz) |
## Extended Description
<pre>Created an attachment (id=803)
gzipped tar archive
When compiling attatched code with async reference counting and the SL_mta backend, slc complains about a syntax error:
File "/home/stca/sl/sl-s3.1.86-r4601-c3.6b.36-d87f-mta-mts/bin/spr", line 8, in <module>
main()
File "/home/stca/sl/sl-s3.1.86-r4601-c3.6b.36-d87f-mta-mts/lib/sl-core/slc/front/main.py", line 15, in main
p = parse_program(p)
File "/home/stca/sl/sl-s3.1.86-r4601-c3.6b.36-d87f-mta-mts/lib/sl-core/slc/input/parse.py", line 166, in parse_program
source = eval(source)
File "<string>", line 1528
SACp_armp_1764 = """, {'loc':r"""a.out.c:905""",'type':'getp','name':"""SACl_v"""},r"""; SACp_armp_1764__desc = """, {'loc':r"""a.out.c:905""",'type':'getp','name':"""""", {'loc':r"""a.out.c:905""",'type':'getp','name':"""SACl_v__desc"""},r""""""},r""";
sac compiler: 17448
sl compiler: s3.1.86-r4601-c3.6b.36-d87f-mta-mts
stdlib: 1520
flags: -mutc_suballoc_desc_one_level_up -rc_method 3
Many other flags combinations trigger the failure. They all specify a reference counting mode.
See:
https://unibench.sac-home.org/?submitType=&lastFocus=&page=query&pg=1&savedquery=null&operating_system=null&machine=32&language_group=14&language_version=null&compiler=32&compiler_version=254&benchmark_suite=169&benchmark=1323&benchmark_implementation=2256&input=null&optimisation_strategy=null&executable_requirement=null&observation_script=null&observation_strategy=null&standard_library=null&flags=null&query_name=&resultname=&gobutton=Go
for details.
The attatched file 337236.tar.gz contains the source code, generated c code and the output from the failed run.
Unigench run number: 337236</pre>Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1568referencecounting emits free on global object2017-11-19T21:03:41ZStephan Herhutreferencecounting emits free on global object| | |
| --- | --- |
| Bugzilla Link | [374](http://bugs.sac-home.org/show_bug.cgi?id=374) |
| Created on | Jun 14, 2007 15:19 |
| Resolution | FIXED |
| Resolved on | Nov 09, 2007 15:06 |
| Version | 1.00beta |
| OS | SunOS |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [374](http://bugs.sac-home.org/show_bug.cgi?id=374) |
| Created on | Jun 14, 2007 15:19 |
| Resolution | FIXED |
| Resolved on | Nov 09, 2007 15:06 |
| Version | 1.00beta |
| OS | SunOS |
| Architecture | PC |
## Extended Description
<pre>sac/testsuite/objects/withloops/default-partition-2.sac triggers the problem.</pre>Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1557mconv runs out memory in 1.5GBmachine2017-11-19T21:02:34ZRobert Berneckymconv runs out memory in 1.5GBmachine| | |
| --- | --- |
| Bugzilla Link | [273](http://bugs.sac-home.org/show_bug.cgi?id=273) |
| Created on | Aug 10, 2006 20:46 |
| Resolution | REMIND |
| Resolved on | Oct 21, 2006 22:52 |
| Version | 1.00beta |
| OS | Linux |
| Archit...| | |
| --- | --- |
| Bugzilla Link | [273](http://bugs.sac-home.org/show_bug.cgi?id=273) |
| Created on | Aug 10, 2006 20:46 |
| Resolution | REMIND |
| Resolved on | Oct 21, 2006 22:52 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [mconv.sac](/uploads/559bcd8543b651145c6c5aedfd654363/mconv.sac), [crud.sac](/uploads/b95c4fd9328753f8c183ab9b63982f38/crud.sac) |
## Extended Description
<pre>The attached runs out of memory on a 1.5GB machine, running an admittedly
large convolution. However, the same convolution code, running under an
APL interpreter with no smarts whatsoever, runs in a 1GB workspace on
the same machine.
I said "refcnt", but am unsure as to the real cause.
Oh, I said "naive" up above, but the problem appears to occur with
the ArrayTransforms rotate code. It's possible that the APL
interpreter sees that the rotate array argument is a temp, so
does the rotate in-place.
However, I was hoping sac would be able to do at least that wel...</pre>Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1552refcounting crash kills several demos2017-11-19T21:02:00ZSven-Bodo Scholzrefcounting crash kills several demos| | |
| --- | --- |
| Bugzilla Link | [196](http://bugs.sac-home.org/show_bug.cgi?id=196) |
| Created on | Jan 20, 2006 23:21 |
| Resolution | FIXED |
| Resolved on | Jan 26, 2006 10:32 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [196](http://bugs.sac-home.org/show_bug.cgi?id=196) |
| Created on | Jan 20, 2006 23:21 |
| Resolution | FIXED |
| Resolved on | Jan 26, 2006 10:32 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Masterrun from Fri Jan 20 17:35:07 GMT 2006 shows several crashes.
Quick check shows:
** 14: Introducing explicit memory management instructions ...
**** AUD/SCL distinction ...
**** Making copy operations explicit ...
**** Introducing explicit allocation statements ...
**** Removing dead code ...
**** Inferring reuse candidates ...
**** Interface aliasing analysis ...
**** Applying loop reuse optimization ...
**** Aliasing analysis ...
**** Filtering reuse candidates ...
**** Static reuse ...
**** Introducing reuse branches ...
**** Identfying in-place updates ...
**** Exploiting data reuse ...
**** Removing dead code ...
**** Reference counting ...
OOOPS your program crashed the compiler 8-((
Please send a bug report to bugs@sac-home.org.
For your convenience, the compiler has pre-fabricated a bug report in
the file "SACbugreport" which was created in the current directory!
Besides some infos concerning the compiler version and its
usage it contains the specified source file.
If you want to send that bug report to us you may simply use
for several cases....
most likely the origin of several new bugs (#19x)</pre>Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1551reference counting dies on loop1.sac2017-11-19T21:01:54ZStephan Herhutreference counting dies on loop1.sac| | |
| --- | --- |
| Bugzilla Link | [195](http://bugs.sac-home.org/show_bug.cgi?id=195) |
| Created on | Jan 20, 2006 21:37 |
| Resolution | DUPLICATE |
| Resolved on | Jan 20, 2006 23:24 |
| Version | 1.00beta |
| OS | Linux |
| Arc...| | |
| --- | --- |
| Bugzilla Link | [195](http://bugs.sac-home.org/show_bug.cgi?id=195) |
| Created on | Jan 20, 2006 21:37 |
| Resolution | DUPLICATE |
| Resolved on | Jan 20, 2006 23:24 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
sac2c dies with a segfault in referencecounting.c:207Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1549sac2c crashes during C code generation2017-11-19T21:01:43ZRobert Berneckysac2c crashes during C code generation| | |
| --- | --- |
| Bugzilla Link | [185](http://bugs.sac-home.org/show_bug.cgi?id=185) |
| Created on | Jan 10, 2006 21:35 |
| Resolution | FIXED |
| Resolved on | Jan 12, 2006 16:07 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [185](http://bugs.sac-home.org/show_bug.cgi?id=185) |
| Created on | Jan 10, 2006 21:35 |
| Resolution | FIXED |
| Resolved on | Jan 12, 2006 16:07 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [primes.sac](/uploads/e5e0bde7c49ae43916eb602779460472/primes.sac), [xprimes.sac](/uploads/48a3e20d65844ebb85fafcc90457f33a/xprimes.sac) |
## Extended Description
Code gen crashKai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1544Bizarre results of mandelbrot_opt.sac2017-11-19T21:01:12ZKai TrojahnerBizarre results of mandelbrot_opt.sac| | |
| --- | --- |
| Bugzilla Link | [128](http://bugs.sac-home.org/show_bug.cgi?id=128) |
| Created on | Oct 07, 2005 18:04 |
| Resolution | FIXED |
| Resolved on | Oct 11, 2005 11:35 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [128](http://bugs.sac-home.org/show_bug.cgi?id=128) |
| Created on | Oct 07, 2005 18:04 |
| Resolution | FIXED |
| Resolved on | Oct 11, 2005 11:35 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>int bug128(double ci, double cr)
{
do {
ocr = cr;
cr = cr - ci;
ci = ocr + ci;
} while ( cr <= 4d);
return( toi( cr));
}
int main()
{
res = bug128( 0.5d, 0.5d);
return(res);
}
The loop is eventually transformed into:
goto _dup_512__f2l_483;
do
{
{
free( _pinl_507__emal_461__pinl_457___flat_32);
}
_dup_512__f2l_483:
{
_pinl_506__emal_463__pinl_458_cr__SSA0_4 = alloc( 1, 0, []);
_pinl_506__emal_463__pinl_458_cr__SSA0_4 = (_pinl_505____cr -
_pinl_504____ci);
_pinl_505____cr = (_pinl_505____cr + _pinl_504____ci);
free( _pinl_504____ci);
_pinl_507__emal_461__pinl_457___flat_32 = alloc( 1, 0, []);
_pinl_507__emal_461__pinl_457___flat_32 =
(_pinl_506__emal_463__pinl_458_cr__SSA0_4 <= 4.0);
_pinl_511__cr__SSA0_4__SSA1_2 = _pinl_506__emal_463__pinl_458_cr__SSA0_4;
!!! _pinl_505____cr = _pinl_506__emal_463__pinl_458_cr__SSA0_4; !!!
!!! _pinl_504____ci = _pinl_505____cr; !!!
}
}
while (_pinl_507__emal_461__pinl_457___flat_32);
The problem arises from the lines marked with !!!.
Here, clearly both arguments to the recursive application of the loop are equal,
which must not happen.
A simplified version of the intermediate loop reads:
int loop( int cr, int ci) {
ncr' = alloc(0,[]);
ncr = fill( cr-ci, ncr');
nci' = alloc_or_reuse( 0, [], cr, ci);
nci = fill( cr+ci, nci');
...
if ( c) {
res = loop( ncr, nci);
}
res2 = c ? res : ncr;
return( res2);
}
cr is reused STATICALLY. This is possible because ncr does not have aliases in
the recursive application.
int loop( int cr, int ci) {
ncr' = alloc(0,[]);
ncr = fill( cr-ci, ncr');
nci' = reuse( cr);
nci = fill( cr+ci, nci');
...
if ( c) {
res = loop( ncr, nci);
}
res2 = c ? res : ncr;
return( res2);
}
Reuseelimination completely removes the reuse assignment in order to avoid
unnecessary variable cluttering.
int loop( int cr, int ci) {
ncr' = alloc(0,[]);
ncr = fill( cr-ci, ncr');
nci = fill( cr+ci, cr);
...
if ( c) {
res = loop( ncr, nci);
}
res2 = c ? res : ncr;
return( res2);
}
The final application of fun2lac now applies the clever stategy outlined in the
commentary of BuildRenamingAssignsForDo as the conditions in question are met!
int loop( int cr, ci) {
goto label;
do {
free( c);
label:
ncr' = alloc(0,[]);
ncr = fill( cr-ci, ncr');
nci = fill( cr+ci, cr);
...
res = ncr;
cr = ncr;
ci = nci;
} while( c);
free( c);
free(nci);
return(res);
}
Finally, MarkMemVals eliminates all artificial memory variables and the problem
arises again.
int loop( int cr, ci) {
goto label;
do {
free( c);
label:
ncr' = alloc(0,[]);
ncr' = cr-ci;
cr = cr+ci;
...
res = ncr';
!!! cr = ncr'; !!!
!!! ci = cr; !!!
} while( c);
free( c);
free(cr);
return(res);
}
Solutions:
The problem arises as MMV replaces variables that fun2lac made very specific
assumptions about. It can be tackled in many ways.
1) ReuseElimination should not remove the line nci' = reuse( cr). Instead, the
implementation of reuse (which does not yet exist) should result in nci' = cr.
2) Reuseelimination could transform it into a assignment nci' = cr on its own.
3) Fun2Lac must not apply its smart transformation in the imperative setting
after MM.
All solutions introduce additional variables and which might introduce a runtime
and space overhead if not removed by the C compiler.
However, 1) and 2) affect all reuse situations whereas 3) does only affect loops.
Therefore, I will make a quick implementation of 3). Maybe, one can come up with
a smarter solution later on.</pre>Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1543nasty memory bug2017-11-19T21:01:06ZSven-Bodo Scholznasty memory bug| | |
| --- | --- |
| Bugzilla Link | [122](http://bugs.sac-home.org/show_bug.cgi?id=122) |
| Created on | Sep 27, 2005 21:07 |
| Resolution | FIXED |
| Resolved on | Sep 27, 2005 22:46 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [122](http://bugs.sac-home.org/show_bug.cgi?id=122) |
| Created on | Sep 27, 2005 21:07 |
| Resolution | FIXED |
| Resolved on | Sep 27, 2005 22:46 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [kai_error.sac](/uploads/5a274fe1a6261605fcbd98a8131c8b61/kai_error.sac) |
## Extended Description
repeated freeing causes SEGFAULT with PHM and gcclib errormessage otherwiseKai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1541ReuseWithArray breaks on IdxSel2017-11-19T21:00:54ZStephan HerhutReuseWithArray breaks on IdxSel| | |
| --- | --- |
| Bugzilla Link | [113](http://bugs.sac-home.org/show_bug.cgi?id=113) |
| Created on | Sep 15, 2005 15:19 |
| Resolution | FIXED |
| Resolved on | Sep 15, 2005 19:14 |
| Version | 1.00beta |
| OS | SunOS |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [113](http://bugs.sac-home.org/show_bug.cgi?id=113) |
| Created on | Sep 15, 2005 15:19 |
| Resolution | FIXED |
| Resolved on | Sep 15, 2005 19:14 |
| Version | 1.00beta |
| OS | SunOS |
| Architecture | Sun |
| Attachments | [sel.sac](/uploads/a698b3b68fe1de7ff26f922ef88cfda8/sel.sac) |
## Extended Description
<pre>when IVE is turned on, ReuseWithArray breaks on IdxSel.
try testcase with
sac2c -doIVE sel.sac</pre>Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1540compiler segfaults2017-11-19T21:00:48ZStephan Herhutcompiler segfaults| | |
| --- | --- |
| Bugzilla Link | [106](http://bugs.sac-home.org/show_bug.cgi?id=106) |
| Created on | Jul 27, 2005 17:31 |
| Resolution | FIXED |
| Resolved on | Jul 28, 2005 12:42 |
| Version | 1.00beta |
| OS | SunOS |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [106](http://bugs.sac-home.org/show_bug.cgi?id=106) |
| Created on | Jul 27, 2005 17:31 |
| Resolution | FIXED |
| Resolved on | Jul 28, 2005 12:42 |
| Version | 1.00beta |
| OS | SunOS |
| Architecture | Sun |
## Extended Description
<pre>building the StdLib module String generates a segfault:
sac2c -O3 -check tb -o lib String.sac -b19:mmv</pre>Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1537memory leak in NAS_mg_with_borders?2017-11-19T21:00:32ZSven-Bodo Scholzmemory leak in NAS_mg_with_borders?| | |
| --- | --- |
| Bugzilla Link | [102](http://bugs.sac-home.org/show_bug.cgi?id=102) |
| Created on | Jun 29, 2005 14:16 |
| Resolution | WORKSFORME |
| Resolved on | Jul 06, 2005 09:26 |
| Version | 1.00beta |
| OS | Linux |
| Ar...| | |
| --- | --- |
| Bugzilla Link | [102](http://bugs.sac-home.org/show_bug.cgi?id=102) |
| Created on | Jun 29, 2005 14:16 |
| Resolution | WORKSFORME |
| Resolved on | Jul 06, 2005 09:26 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I ran it with a modified input 64_1, i.e., 1 (!) iteration on an
64x64x64 of doubles, i.e. approx 2 MB of memory.
After about 2 hours runtime, the memory usage of that process exceeds
500 MB!! and still does not teminate.....</pre>Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1533segfaulting executable (in sel)2017-11-19T21:00:11ZSven-Bodo Scholzsegfaulting executable (in sel)| | |
| --- | --- |
| Bugzilla Link | [91](http://bugs.sac-home.org/show_bug.cgi?id=91) |
| Created on | Jun 27, 2005 12:16 |
| Resolution | FIXED |
| Resolved on | Jun 28, 2005 14:52 |
| Version | 1.00beta |
| OS | Linux |
| Architect...| | |
| --- | --- |
| Bugzilla Link | [91](http://bugs.sac-home.org/show_bug.cgi?id=91) |
| Created on | Jun 27, 2005 12:16 |
| Resolution | FIXED |
| Resolved on | Jun 28, 2005 14:52 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/a9e3fc30ec898001f97a1c381dec47a8/tutu.sac) |
## Extended Description
<pre>compile with -noopt -doDFR -check tb -g
run in debugger to see the problem</pre>Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1531undefined variable used in NTCtemplates.mac[100]2017-11-19T20:59:59ZRobert Berneckyundefined variable used in NTCtemplates.mac[100]| | |
| --- | --- |
| Bugzilla Link | [77](http://bugs.sac-home.org/show_bug.cgi?id=77) |
| Created on | Oct 26, 2004 23:03 |
| Resolution | FIXED |
| Resolved on | Nov 12, 2004 11:16 |
| Version | 1.00beta |
| OS | Windows NT |
| Arch...| | |
| --- | --- |
| Bugzilla Link | [77](http://bugs.sac-home.org/show_bug.cgi?id=77) |
| Created on | Oct 26, 2004 23:03 |
| Resolution | FIXED |
| Resolved on | Nov 12, 2004 11:16 |
| Version | 1.00beta |
| OS | Windows NT |
| Architecture | PC |
| Attachments | [bug77.sac.gz](/uploads/313047662b6ec937441b65b4af5a3c59/bug77.sac.gz) |
## Extended Description
<pre>The attached gzip'd sac program dies in phase 17 [explicit allocation]
from a reference to an undefined variable, var_flat_2095_iv.
This may be a source code problem, but the problem reporting mechanism is
user-hostile.</pre>Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1465non allocated object freed fun2lac bug2017-11-19T20:53:19ZSven-Bodo Scholznon allocated object freed fun2lac bug| | |
| --- | --- |
| Bugzilla Link | [819](http://bugs.sac-home.org/show_bug.cgi?id=819) |
| Created on | Jan 19, 2011 10:57 |
| Resolution | FIXED |
| Resolved on | Feb 20, 2011 19:17 |
| Version | svn |
| OS | All |
| Architecture |...| | |
| --- | --- |
| Bugzilla Link | [819](http://bugs.sac-home.org/show_bug.cgi?id=819) |
| Created on | Jan 19, 2011 10:57 |
| Resolution | FIXED |
| Resolved on | Feb 20, 2011 19:17 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [bug819.sac](/uploads/a5adfe0ba55c6ebd374f71a85b03f6ec/bug819.sac), [wave_kern.sac](/uploads/38e31f0876c56a0688a51ba73470ba9e/wave_kern.sac), [bug.sac](/uploads/2a452c5edab38d522d18715ee1d1adfc/bug.sac) |
## Extended Description
<pre>Created an attachment (id=789)
source code for people with case-sensitive file systems
with rev 17286 I get the following error message (on OSX):
-sbs-idefix2-> ./a.out
a.out(77914) malloc: *** error for object 0x100a000b0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort
after compiling w/o flags</pre>BugZillaBugZilla