Notes from building gpc-20021128 with gcc-3.2.1 configured for i486-pc-mingw32:
* GPC will not build with the version of os-hacks.h on the GPC Web site; a patched version is required.
* GPC will build with the FSF gcc-3.2.1 sources, but compiled programs that use files will fault in _p_bind (bad pointer). Building with the FSF sources + the Mingw-specific patches from the mingw.org Web site works.
* GPC will not run on Win9x/WinME systems, due to a Mingw-specific change in gcc/config/i386/xm-mingw32.h. Patching gpc.c is required.
* Test suite results are:
agettext2test.pas: SKIPPED: libintl not installed crttest.pas: SKIPPED: no curses library found environo.pas: SKIPPED: setenv not present in libc fjf480a.pas: SKIPPED: librx not installed fjf480b.pas: SKIPPED: librx not installed fjf480c.pas: SKIPPED: librx not installed fjf582.pas: failed [Exception c00000fd (stack overflow)] fjf663.pas: failed [runs forever -- aborted by ulimit] gettexttest.pas: SKIPPED: libintl not installed gmptest.pas: SKIPPED: libgmp not installed pipetest.pas: SKIPPED: IOSelect not yet implemented for mingw regextest.pas: SKIPPED: librx not installed
# of GPC tests 2855 # of GPC tests passed 2843 # of GPC tests skipped 10 # of GPC tests failed 2
"fjf582" fails because GPC allocates about 144KB of stack with -O0 and -O1 but allocates about 4.1MB with -O2 and -O3. The default stack reserve set in "ld" is 2MB. Increasing the default manually allows "fsf582" to succeed. Specifically, the generated code is:
[with -O0 and -O1]
_pascal_main_program: pushl %ebp movl %esp, %ebp movl $147976, %eax call __alloca ...
[with -O2 and -O3]
_pascal_main_program: pushl %ebp movl $4259848, %eax movl %esp, %ebp call __alloca ...
"fjf663" appears to loop indefinitely and is aborted due to time limit.
-- Dave
On 9 Jan 2003 at 12:22, J. David Bryan wrote:
[...]
- GPC will not run on Win9x/WinME systems, due to a Mingw-specific
change in gcc/config/i386/xm-mingw32.h. Patching gpc.c is required.
Adding "-DTARGET_W9x" to the CFLAGS should do the job, without any patches to gpc.c
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
J. David Bryan wrote:
Notes from building gpc-20021128 with gcc-3.2.1 configured for i486-pc-mingw32:
- GPC will not run on Win9x/WinME systems, due to a Mingw-specific change in gcc/config/i386/xm-mingw32.h. Patching gpc.c is required.
What exactly is the difference?
fjf582.pas: failed [Exception c00000fd (stack overflow)]
Fixed in the next version.
fjf663.pas: failed [runs forever -- aborted by ulimit]
Oops. I suppose it loops forever in the `repeat' loop in the main program. Can you add `WriteLn (FileHandle (f^))' there to see what happens?
Frank
On 10 Jan 2003 at 9:58, Frank Heckenbach wrote:
J. David Bryan wrote:
Notes from building gpc-20021128 with gcc-3.2.1 configured for i486-pc-mingw32:
- GPC will not run on Win9x/WinME systems, due to a Mingw-specific
change in gcc/config/i386/xm-mingw32.h. Patching gpc.c is required.
What exactly is the difference?
It is the age-old front slash problem. In gcc-2.95.3.x, xm-mingw32.h contained these entries:
/* Even though we support "/", allow "" since everybody tests both. */ #ifdef TARGET_W9x /* This kludge must go, once we can get '/' to work on W9x */ #define DIR_SEPARATOR_2 '/' #define DIR_SEPARATOR '\' #else #define DIR_SEPARATOR '/' #define DIR_SEPARATOR_2 '\' #endif
So, the suggestion I gave earlier would have worked if you added "-DTARGET_W9x" to the CFLAGS when compiling. However, with gcc-3.x, xm-mingw32.h only now contains this:
/* Even though we support "/", allow "" since everybody tests both. */ #define DIR_SEPARATOR '/' #define DIR_SEPARATOR_2 '\'
This means that "-DTARGET_W9x" will not work with gcc-3.x. However, removing the earlier entries seems to indicate that the Mingw guys consider that the Win9x problem has been solved. If this is not the case, then David Bryan might as well report the problem on the Mingw list.
A short term solution would be to reverse the entries in xm-mingw32.h - i.e., do this:
#define DIR_SEPARATOR '\' #define DIR_SEPARATOR_2 '/'
This should cure the problem without any patches to gpc.c. If you don't want anything other than GPC to be affected, then perhaps an appropriate IFDEF can be used - like they did in gcc-2.95.3.x as shown above.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
Prof. A Olowofoyeku (The African Chief) wrote:
On 10 Jan 2003 at 9:58, Frank Heckenbach wrote:
J. David Bryan wrote:
Notes from building gpc-20021128 with gcc-3.2.1 configured for i486-pc-mingw32:
- GPC will not run on Win9x/WinME systems, due to a Mingw-specific
change in gcc/config/i386/xm-mingw32.h. Patching gpc.c is required.
What exactly is the difference?
It is the age-old front slash problem. In gcc-2.95.3.x, xm-mingw32.h contained these entries:
/* Even though we support "/", allow "" since everybody tests both. */ #ifdef TARGET_W9x /* This kludge must go, once we can get '/' to work on W9x */ #define DIR_SEPARATOR_2 '/' #define DIR_SEPARATOR '\' #else #define DIR_SEPARATOR '/' #define DIR_SEPARATOR_2 '\' #endif
So, the suggestion I gave earlier would have worked if you added "-DTARGET_W9x" to the CFLAGS when compiling. However, with gcc-3.x, xm-mingw32.h only now contains this:
/* Even though we support "/", allow "" since everybody tests both. */ #define DIR_SEPARATOR '/' #define DIR_SEPARATOR_2 '\'
This means that "-DTARGET_W9x" will not work with gcc-3.x. However, removing the earlier entries seems to indicate that the Mingw guys consider that the Win9x problem has been solved. If this is not the case, then David Bryan might as well report the problem on the Mingw list.
A short term solution would be to reverse the entries in xm-mingw32.h
- i.e., do this:
#define DIR_SEPARATOR '\' #define DIR_SEPARATOR_2 '/'
This should cure the problem without any patches to gpc.c. If you don't want anything other than GPC to be affected, then perhaps an appropriate IFDEF can be used - like they did in gcc-2.95.3.x as shown above.
As I wrote in an earlier mail:
: I could easily make gpc.c put a `' if either of the DIR_SEPARATOR's : is `'. This will then also include Cygwin where it's not necessary : AFAIK, but shouldn't hurt either, I guess.
However, this would be different from what GCC does. So I wonder, does GCC work in this situation, or does it use special patches?
Frank
On 11 Jan 2003 at 23:51, Frank Heckenbach wrote:
As I wrote in an earlier mail:
: I could easily make gpc.c put a `' if either of the DIR_SEPARATOR's : is `'. This will then also include Cygwin where it's not necessary : AFAIK, but shouldn't hurt either, I guess.
That will fail under Cygwin. Cygwin translates pathnames containing forward slashes via a "mount table" to Windows-native paths. For example, "/usr/local/src" might be translated to "F:\Users\Dave\Project\Source". If the path contains backslashes, e.g., "\usr\local\src", the translation doesn't occur.
-- Dave
On 10 Jan 2003 at 9:58, Frank Heckenbach wrote:
What exactly is the difference?
See:
ftp://ftp3.sourceforge.net/pub/sourceforge/mingw/gcc-3.2.1-20021201-3-src.diff.gz
The Mingw patches change xm-mingw32.h to define DIR_SEPARATOR as "/", i.e., a forward slash instead of the Windows-standard backslash, and then modify gcc.c to convert the resulting forward slashes to backslashes in the "execute" function. The problem is that while WinNT/2K/XP treat forward and backslashes interchangeably, Win9x/ME do not. So an unmodified GPC+Mingw build uses "/" as DIR_SEPARATOR but does not have the patches to gcc.c carried over to gpc.c, and so passes forward slashes to Windows to execute gpc1, as, etc. This fails under Win9x/ME.
Can you add `WriteLn (FileHandle (f^))' there to see what happens?
Given:
repeat New (f); Reset (f^, ParamStr (1)); WriteLn (FileHandle (f^)) until FileHandle (f^) >= 8;
...the program outputs "0" forever.
On 10 Jan 2003 at 16:21, Prof. A Olowofoyeku wrote:
In gcc-2.95.3.x, xm-mingw32.h contained these entries:
/* Even though we support "/", allow "" since everybody tests both. */ #ifdef TARGET_W9x /* This kludge must go, once we can get '/' to work on W9x */ #define DIR_SEPARATOR_2 '/' #define DIR_SEPARATOR '\' #else #define DIR_SEPARATOR '/' #define DIR_SEPARATOR_2 '\' #endif
Originally, xm-mingw32.h defined DIR_SEPARATOR as "\", i.e., a backslash. This is correct for the platform. However, as the Chief noted, this was subsequently changed to "/" for WinNT/2K/XP, while leaving "\" for Win9x/ME. This is very odd, because the directory separator has always been (and is today) a backslash on all versions of Windows. Moreover, why use a backslash on 9x/ME while using a forward slash on NT/2K/XP? The backslash will work on both sets of systems, so why go to the trouble of defining it differently for different Windows systems?
Finally, the current gcc-3.2.1 Mingw version defines DIR_SEPARATOR as "/" for all versions of Windows but then patches gcc.c to convert forward slashes to backslashes in "execute". Why do this instead of defining as "\" and being done with it?
I have no knowledge of the rationale, but I will point out that because NT/2K/XP treat backslashes and forward slashes equivalently, it is possible to have two different file paths refer to the same file, e.g., \dir\file and /dir/file would refer to the same file. There are places within gcc.c that determine if two paths are equivalent by doing a "strcmp", which would obviously fail with the above equivalence. See, for example, the 'g' case within "do_spec_1" and note the comment about 32 lines thereafter.
It appears as though the latest Mingw patches attempt to produce canonical file paths by always using forward slashes, i.e., so that "strcmp" would properly indicate equivalence. Then, to work around the 9x/ME behavior, forward slashes are converted to backslashes in "execute".
So, the suggestion I gave earlier would have worked if you added "-DTARGET_W9x" to the CFLAGS when compiling.
...And if I had been building with gcc-2.95.x. ;-)
However, removing the earlier entries seems to indicate that the Mingw guys consider that the Win9x problem has been solved.
It's "solved" in two parts: a change in xm-mingw32.h to use "/" as the DIR_SEPARATOR, and a change to gcc.c to change forward slashes to backslashes in "execute". It's the second part of this change that is not being picked up in gpc.c.
A short term solution would be to reverse the entries in xm-mingw32.h....
That allows GPC to execute gpc1, as, etc., but at the expense of "strcmp" failing for potentially equivalent file paths. As I noted, I don't know the ramifications of this, but I presume that the Mingw folks made the change for a reason other than pure perversity. ;-)
-- Dave
On 11 Jan 2003 at 15:40, J. David Bryan wrote:
On 10 Jan 2003 at 9:58, Frank Heckenbach wrote:
Can you add `WriteLn (FileHandle (f^))' there to see what happens?
Given:
repeat New (f); Reset (f^, ParamStr (1)); WriteLn (FileHandle (f^)) until FileHandle (f^) >= 8;
...the program outputs "0" forever.
Ignore the above. This is "pilot error" on my part on re-running the test to determine why it failed. I ran the test file directly, rather than via the test suite makefile with MASK="fjf663.pas". As a result, it did not receive the first commandline parameter (i.e., ParamStr (1)), and so the program looped indefinitely.
The correct problem description is as follows. Given this instrumented version of the test program:
program fjf663;
uses GPC;
var f: ^Text; s: array [1 .. 1] of PAnyFile;
begin writeln; writeln (ParamStr (1)); repeat New (f); Reset (f^, ParamStr (1)); writeln (FileHandle (f^)) until FileHandle (f^) >= 8; s[1] := f; writeln (IOSelectRead (s, 0)); if IOSelectRead (s, 0) = 1 then WriteLn ('OK') else WriteLn ('failed') end.
...I obtain these results:
GPC-TEST-BEGIN ========================== TEST fjf663.pas: ./fjf663.pas 3 4 5 6 7 8 -1 failed ========================== GPC-TEST-END
My apologies for the original, incorrect report.
-- Dave
J. David Bryan wrote:
The correct problem description is as follows. Given this instrumented version of the test program:
program fjf663;
uses GPC;
var f: ^Text; s: array [1 .. 1] of PAnyFile;
begin writeln; writeln (ParamStr (1)); repeat New (f); Reset (f^, ParamStr (1)); writeln (FileHandle (f^)) until FileHandle (f^) >= 8; s[1] := f; writeln (IOSelectRead (s, 0)); if IOSelectRead (s, 0) = 1 then WriteLn ('OK') else WriteLn ('failed') end.
...I obtain these results:
GPC-TEST-BEGIN
TEST fjf663.pas: ./fjf663.pas 3 4 5 6 7 8 -1 failed ========================== GPC-TEST-END
So the infinte loop disappeared?
Frank
J. David Bryan wrote:
On 12 Jan 2003 at 0:17, Frank Heckenbach wrote:
So the infinte loop disappeared?
Yes. It was an artifact of invoking "fjf663" without a parameter. The failure still exists, though.
Err, which failure? Your original report was:
fjf663.pas: failed [runs forever -- aborted by ulimit]
And your modified test shows -1 as the result of IOSelectRead which the original interprets as "SKIPPED", not a failure.
Frank
On 12 Jan 2003 at 1:20, Frank Heckenbach wrote:
And your modified test shows -1 as the result of IOSelectRead which the original interprets as "SKIPPED", not a failure.
The original fjf663.pas (dated 2002-09-06) has:
if IOSelectRead (s, 0) = 1 then WriteLn ('OK') else WriteLn ('failed')
Doesn't that write "failed" if the returned value is -1? How is that equivalent to "SKIPPED?"
-- Dave
J. David Bryan wrote:
On 12 Jan 2003 at 1:20, Frank Heckenbach wrote:
And your modified test shows -1 as the result of IOSelectRead which the original interprets as "SKIPPED", not a failure.
The original fjf663.pas (dated 2002-09-06) has:
if IOSelectRead (s, 0) = 1 then WriteLn ('OK') else WriteLn ('failed')
Doesn't that write "failed" if the returned value is -1? How is that equivalent to "SKIPPED?"
Oh, yeah -- I made the change after the last alpha. But still it doesn't explain where you got the infitue loop originally.
Frank
On 12 Jan 2003 at 1:32, Frank Heckenbach wrote:
But still it doesn't explain where you got the infitue loop originally.
Three hours ago, I wrote:
This is "pilot error" on my part on re-running the test to determine why it failed. I ran the test file directly, rather than via the test suite makefile with MASK="fjf663.pas". As a result, it did not receive the first commandline parameter (i.e., ParamStr (1)), and so the program looped indefinitely.
Invoking the program as:
fjf663
...produces an infinite loop (and prints "0" when so instrumented). Invoking as:
fjf663 ./fjf663.pas
...produces "failed" (and "3" .. "8", "-1", "failed" when so instrumented).
-- Dave
J. David Bryan wrote:
On 12 Jan 2003 at 1:32, Frank Heckenbach wrote:
But still it doesn't explain where you got the infitue loop originally.
Three hours ago, I wrote:
This is "pilot error" on my part on re-running the test to determine why it failed. I ran the test file directly, rather than via the test suite makefile with MASK="fjf663.pas". As a result, it did not receive the first commandline parameter (i.e., ParamStr (1)), and so the program looped indefinitely.
Invoking the program as:
fjf663
...produces an infinite loop (and prints "0" when so instrumented). Invoking as:
fjf663 ./fjf663.pas
...produces "failed" (and "3" .. "8", "-1", "failed" when so instrumented).
But on Thursday you wrote:
Test suite results are:
agettext2test.pas: SKIPPED: libintl not installed crttest.pas: SKIPPED: no curses library found environo.pas: SKIPPED: setenv not present in libc fjf480a.pas: SKIPPED: librx not installed fjf480b.pas: SKIPPED: librx not installed fjf480c.pas: SKIPPED: librx not installed fjf582.pas: failed [Exception c00000fd (stack overflow)] fjf663.pas: failed [runs forever -- aborted by ulimit] gettexttest.pas: SKIPPED: libintl not installed gmptest.pas: SKIPPED: libgmp not installed pipetest.pas: SKIPPED: IOSelect not yet implemented for mingw regextest.pas: SKIPPED: librx not installed
# of GPC tests 2855 # of GPC tests passed 2843 # of GPC tests skipped 10 # of GPC tests failed 2
So, does this mean it works when called with `MASK="fjf663.pas"', but not when called via the Makefile without a MASK?
Frank
On 12 Jan 2003 at 1:45, Frank Heckenbach wrote:
So, does this mean it works when called with `MASK="fjf663.pas"', but not when called via the Makefile without a MASK?
I seem to have confused the issue beyond recovery. Please forget everything I wrote previously regarding "fjf663.pas".
Now, here is my report from running the full test suite:
$ make --directory=/usr/local/src/gcc-3.2.1/gcc/p/test
[...]
agettext2test.pas: SKIPPED: libintl not installed crttest.pas: SKIPPED: no curses library found environo.pas: SKIPPED: setenv not present in libc fjf480a.pas: SKIPPED: librx not installed fjf480b.pas: SKIPPED: librx not installed fjf480c.pas: SKIPPED: librx not installed fjf582.pas: failed [Exception c00000fd (stack overflow)] fjf663.pas: failed gettexttest.pas: SKIPPED: libintl not installed gmptest.pas: SKIPPED: libgmp not installed pipetest.pas: SKIPPED: IOSelect not yet implemented for mingw regextest.pas: SKIPPED: librx not installed
# of GPC tests 2855 # of GPC tests passed 2843 # of GPC tests skipped 10 # of GPC tests failed 2
Modifying "fjf663.pas" as follows to show why it is failing:
program fjf663;
uses GPC;
var f: ^Text; s: array [1 .. 1] of PAnyFile;
begin writeln; writeln (ParamStr (1)); repeat New (f); Reset (f^, ParamStr (1)); writeln (FileHandle (f^)) until FileHandle (f^) >= 8; s[1] := f; writeln (IOSelectRead (s, 0)); if IOSelectRead (s, 0) = 1 then WriteLn ('OK') else WriteLn ('failed') end.
...gives me the following results:
$ make --directory=/usr/local/src/gcc-3.2.1/gcc/p/test MASK="fjf663.pas" pascal.check-long
[...]
GPC-TEST-BEGIN ========================== TEST fjf663.pas: ./fjf663.pas 3 4 5 6 7 8 -1 failed ========================== GPC-TEST-END
-- Dave
J. David Bryan wrote:
I seem to have confused the issue beyond recovery. Please forget everything I wrote previously regarding "fjf663.pas".
Now, here is my report from running the full test suite:
fjf582.pas: failed [Exception c00000fd (stack overflow)] fjf663.pas: failed
[...]
I have changed fjf663 meanwhile to write `SKIPPED' (according to a report by The Chief, I think) and fjf582 (where the problem also showed elsewhere). Find attached the current versions.
Frank
On 13 Jan 2003 at 20:18, Frank Heckenbach wrote:
I have changed fjf663 meanwhile to write `SKIPPED' (according to a report by The Chief, I think) and fjf582 (where the problem also showed elsewhere). Find attached the current versions.
Using those versions, here are the complete test results:
TEST agettext2test.pas: SKIPPED: libintl not installed TEST crttest.pas: SKIPPED: no curses library found TEST environo.pas: SKIPPED: setenv not present in libc TEST fjf480a.pas: SKIPPED: librx not installed TEST fjf480b.pas: SKIPPED: librx not installed TEST fjf480c.pas: SKIPPED: librx not installed TEST fjf663.pas: SKIPPED: IOSelectRead not supported on this system TEST gettexttest.pas: SKIPPED: libintl not installed TEST gmptest.pas: SKIPPED: libgmp not installed TEST pipetest.pas: SKIPPED: IOSelect not yet implemented for mingw TEST regextest.pas: SKIPPED: librx not installed
# of GPC tests 2856 # of GPC tests passed 2845 # of GPC tests skipped 11 # of GPC tests failed 0
-- Dave
J. David Bryan wrote:
It's "solved" in two parts: a change in xm-mingw32.h to use "/" as the DIR_SEPARATOR, and a change to gcc.c to change forward slashes to backslashes in "execute". It's the second part of this change that is not being picked up in gpc.c.
It would probably easy to add the same in gpc.c (since it's mostly synced with gcc-3.2's gcc.c). Of course, I'd like to know what will happen in GCC (if this change will be integrated, or something else), so we won't have to change things again and again ... :-/
Frank
-
Frank Heckenbach -
J. David Bryan -
Prof A Olowofoyeku (The African Chief) -
Prof. A Olowofoyeku (The African Chief)