https://sourceforge.net/p/gobo-eiffel/bugs/2012-04-13T16:25:36ZRecent changes to bugs2012-04-13T16:25:36Z2012-04-13T16:25:36ZWolfgang Jansenhttps://sourceforge.net/u/wjansen3/https://sourceforge.net26dfdfee8968bcff0f4e6b3fc9b498f3e34f5a8c

The GEC generated code for \`deep\_copy' of SPECIAL objects does either crash or does not work correctly. The file added describes the bug causing C code and proposes two possible bug fixes. With regards Wolfgang

2011-07-11T10:27:53Z2011-07-11T10:27:53ZWolfgang Jansenhttps://sourceforge.net/u/wjansen3/https://sourceforge.net7fc23864abd1fd878a7b58c956d6fe077d62df9b

The new GEC version \(GIT version 6857a16098ba22ce158627abfe2d5348b617378d from 7-July 2011\) does not compile an old project that has been compiled successfully by previous compiler versions, For example, features of a class are not found while the class text clearly says that they are there. The error messages sound as if during analysis of one class knowledge of another class is needed but not ready and the other class is not analyzed on the flight. The failure occurs for a rather large project, smaller sub-projects are compiled successfully, so I add the sources of the large project. To test it, unpack the TAR file in some directory, switch to that directory and the enter the commands \(in UNIX notation\): setenv WJ \`pwd\` \# WJ is referred to in the XACE file cd candys gec --cc=no --catcall=no ca.xace With regards WJ PS: The TAR file is too large to be added to this report. You may find it at http://www.cs.uni-potsdam.de/~wjansen/tar/wj.tgz

2011-03-23T17:13:24Z2011-03-23T17:13:24ZWolfgang Jansenhttps://sourceforge.net/u/wjansen3/https://sourceforge.net987377778b93a53db3ec1fd2b60d662f984a42fc

Hi, I would like to report a spurious bug of GEC. A local variable declared as REAL\_64 is considered by the compiler as an INTEGER\_32 variable: instead of \`T13 l3;' the C code reads \`T6 l6;'. This has several consequences. First, additions like \`x+x1' are rejected where \`x' is a correctly treated REAL\_64 but \`x1' is the variable of question. Compilation works if those additions are commented out but then the algorithm is wrong. Second, routine calls like \`call\(x1\)' get in C code a catcall check which at run time fires: the call expects REAL\_64 while the actual argument is the erroneous INTEGER\_32. The attachment contains the slightly reduced project. Running "geant compile" should work. The critical feature is \`DIAGRAM\_IMPL.callback', the critical local variable is \`x1' \(line 538\). Lines 555 and 559 are commented out additions, erroneous catcall checks are inserted in the calls of lines 552, 568, 580. With regards WJ

2010-05-27T13:42:52Z2010-05-27T13:42:52ZAnonymoushttps://sourceforge.net/u/userid-None/https://sourceforge.net684a3c3564629ad13776bb1ebd6ee41579d03f8f

$ ./bootstrap.sh gcc ge In file included from gec15.c:1: gec.h:71885:22: eif\_plug.h: No such file or directory In file included from gec14.c:1: gec.h:71885:22: eif\_plug.h: No such file or directory In file included from gec13.c:1: gec.h:71885:22: eif\_plug.h: No such file or directory In file included from gec12.c:1:

2010-05-20T03:24:55Z2010-05-20T03:24:55Zothyrohttps://sourceforge.net/u/othyro/https://sourceforge.net8ca0c7a5cb00e0ed88094eb144e4de9db4bf96f0

\# bmake install => Bootstrap dependency digest>=20010302: found digest-20080510 ===> Skipping vulnerability checks. WARNING: No /var/db/pkg/pkg-vulnerabilities file found. WARNING: To fix run: \`/usr/pkg/sbin/pkg\_admin -K /var/db/pkg fetch-pkg-vulnerabilities'. => Checksum SHA1 OK for gobo39-src.tar.gz => Checksum RMD160 OK for gobo39-src.tar.gz ===> Installing dependencies for gobo-eiffel-3.9 ===> Overriding tools for gobo-eiffel-3.9 ===> Extracting for gobo-eiffel-3.9 ===> Patching for gobo-eiffel-3.9 ===> Creating toolchain wrappers for gobo-eiffel-3.9 ===> Configuring for gobo-eiffel-3.9 ===> Building for gobo-eiffel-3.9 => Unwrapping files-to-be-installed. ===> Installing for gobo-eiffel-3.9 cd /usr/pkgsrc/wip/gobo-eiffel/work/gobo && /usr/bin/env GOBO=/usr/pkgsrc/wip/gobo-eiffel/work/gobo ./install.sh gcc strip: 'geant\}': No such file

2010-05-10T07:41:56Z2010-05-10T07:41:56ZEric Bezaulthttps://sourceforge.net/u/ericb/https://sourceforge.nete5f783febfec7730ca766292a11d0f1d530223ca

In the implementation of class IDENTIFIED\_ROUTINES, object addresses are casted to INTEGER\_32. This causes loss of information when compiled on a 64-bit computer.

2010-05-05T12:53:26Z2010-05-05T12:53:26ZEric Bezaulthttps://sourceforge.net/u/ericb/https://sourceforge.netca4b132971a7e2fb116bc0cd846b3db5fc4fac15

When compiling the following program: ~~~~~~~~~~~~~~~~~ class BUG create make feature make do print \(bar.item \(\[\]\)\) end foo: FUNCTION \[ANY, TUPLE, STRING\] do if 1 = 2 then Result := agent \("gobo"\).out elseif 2 = 3 then Result := agent out else Result := agent \(2\).out end end bar: FUNCTION \[ANY, TUPLE, STRING\] do Result := agent foo.item \(\[\]\) end end ~~~~~~~~~~~~~~~~~ the C compilers complains about unresolved functions: ~~~~~~~~~~~~~~~~~ bang2create1.obj : error LNK2019: unresolved external symbol \_T23x1759T0 referenced in function \_T21f1af1 ~~~~~~~~~~~~~~~~~

2009-09-07T16:16:55Z2009-09-07T16:16:55ZJocelyn FIAThttps://sourceforge.net/u/jfiat/https://sourceforge.net6a65cc34c481345bade74f6549e3448a22226930

For instance take this path a+path := "/tmp/bug/a\\\\\\\\\!@\#$%^&\*\(\)-\_=+|\`~\[\]\{\} ;:,.<>%"'z'/src" inherit KL\_SHARED\_FILE\_SYSTEM code: file\_system.pathname\_from\_file\_system \(directory \(a\_path\), windows\_file\_system\) it won't handle the \\\\\\\ as what it is, it resolves it as a simple directory separator "/"

2009-08-03T12:02:25Z2009-08-03T12:02:25ZJann Röderhttps://sourceforge.net/u/spooky23/https://sourceforge.net7630c3d6793cf9d841f38b7385c5756f3a858e47

The code below causes a precondition violation in feature move\_all\_cursors: make local l\_set: DS\_HASH\_SET\[INTEGER\] do create l\_set.make\_default l\_set.force \(5\) l\_set.force \(6\) l\_set.force \(10\) l\_set.remove \(6\) l\_set.compress end

2009-07-07T19:57:04Z2009-07-07T19:57:04Zhttps://sourceforge.net/u/meor/https://sourceforge.net63145772880f3d5576b1607803a32575525b1c9e

The gobo\_kernel.ecf project distributed with ES 6.4.7.9263 GPL Windows doesn't compile. It has a configuration error: Error code: VD71 Configuration error Directory open error: c:\program files\eiffel software\eiffelstudio 6.4 gpl\library\gobo\override\library\kernel override\library\kernel\ Configuration: c:\program files\eiffel software\eiffelstudio 6.4 gpl\library\gobo\gobo\_kernel.ecf If I remove the \`override' cluster the project compiles successfully.