Hi list,
the test fjf949.pas from the test suite gpc-test-20041218.tar.gz (beta) seems to be getting into a endless loop. with gdb: #0 $000025a4 in init_pascal_main_program () at fjf949.pas:4 #1 $00002614 in main (argc=1, argv=$bffff01c, envp=$bffff024) at <implicit code>:10 the line is 4 a: array [Byte] of String (2);
I am running gpc on Mac OS X and it was installed through fink.
There were more test failures in test suite, but this one seems to be the most critical.
Jan Ruzicka
PS: Disassembled portion of the code is:
0x0000253c <init_pascal_main_program+0>: mflr r0 0x00002540 <init_pascal_main_program+4>: stmw r30,-8(r1) 0x00002544 <init_pascal_main_program+8>: stw r0,8(r1) 0x00002548 <init_pascal_main_program+12>: stwu r1,-80(r1) 0x0000254c <init_pascal_main_program+16>: mr r30,r1 0x00002550 <init_pascal_main_program+20>: bcl- 20,4*cr7+so,0x2554 <init_pascal_main_program+24> 0x00002554 <init_pascal_main_program+24>: mflr r31 0x00002558 <init_pascal_main_program+28>: addis r9,r31,4 0x0000255c <init_pascal_main_program+32>: addi r9,r9,-22972 0x00002560 <init_pascal_main_program+36>: lbz r0,0(r9) 0x00002564 <init_pascal_main_program+40>: clrlwi r0,r0,24 0x00002568 <init_pascal_main_program+44>: cmpwi r0,0 0x0000256c <init_pascal_main_program+48>: bne- 0x25b8 <init_pascal_main_program+124> 0x00002570 <init_pascal_main_program+52>: addis r9,r31,4 0x00002574 <init_pascal_main_program+56>: addi r9,r9,-22972 0x00002578 <init_pascal_main_program+60>: li r0,1 0x0000257c <init_pascal_main_program+64>: stb r0,0(r9) 0x00002580 <init_pascal_main_program+68>: li r0,0 0x00002584 <init_pascal_main_program+72>: stb r0,56(r30) ;-------------------- here starts the loop 0x00002588 <init_pascal_main_program+76>: addis r9,r31,4 0x0000258c <init_pascal_main_program+80>: addi r9,r9,-26044 0x00002590 <init_pascal_main_program+84>: lbz r0,56(r30) 0x00002594 <init_pascal_main_program+88>: clrlwi r0,r0,24 0x00002598 <init_pascal_main_program+92>: mulli r0,r0,12 0x0000259c <init_pascal_main_program+96>: add r9,r0,r9 0x000025a0 <init_pascal_main_program+100>: li r0,2 0x000025a4 <init_pascal_main_program+104>: stw r0,0(r9) 0x000025a8 <init_pascal_main_program+108>: lbz r9,56(r30) 0x000025ac <init_pascal_main_program+112>: addi r0,r9,1 0x000025b0 <init_pascal_main_program+116>: stb r0,56(r30) 0x000025b4 <init_pascal_main_program+120>: b 0x2588 <init_pascal_main_program+76> ;-------------------- here ends the loop 0x000025b8 <init_pascal_main_program+124>: lwz r1,0(r1) 0x000025bc <init_pascal_main_program+128>: lwz r0,8(r1) 0x000025c0 <init_pascal_main_program+132>: mtlr r0 0x000025c4 <init_pascal_main_program+136>: lmw r30,-8(r1) 0x000025c8 <init_pascal_main_program+140>: blr
jan.ruzicka@comcast.net wrote:
the test fjf949.pas from the test suite gpc-test-20041218.tar.gz (beta) seems to be getting into a endless loop.
The test passes with my (non fink) copy of gpc, based on gcc-3.3.3 and gpc-20041218. Can you can give some more information (e.g. gpc -v) ?
There were more test failures in test suite, but this one seems to be the most critical.
Try
[G4:gcc/p/test] adriaan% make EXTRA_PFLAGS=--longjmp-all-nonlocal-labels
and report the results.
Regards,
Adriaan van Os
The gpc -v gives:
Reading specs from /sw/lib/gcc-lib/powerpc-apple-darwin/3.3.2/specs Configured with: ./gpc-332d1/configure --prefix=/sw --enable-languages=c,pascal --enable-threads=posix --infodir=/sw/src/root-gpc-3.3.2d1-7/sw/share/info --mandir=/sw/src/root-gpc-3.3.2d1-7/sw/share/man --target=powerpc-apple-darwin Thread model: posix gpc version 20030830, based on gcc-3.3.2
(sorry it seems to be a dated one gpc version 20030830)
I left tests to run overnight and the test_run interrupted the test by itself: TEST fjf949.pas: ./test_run: line 336: 12525 Cputime limit exceeded ./"$A_OUT" "$1" the tests ended with : TEST fproc.pas: 9,23117273c9,11 < ake_delayed_ 8 formal print =Stack frame: -1 formal print = non-local jump and followed by 5729091 similar lines: ending : < ake_delayed_ 8 formal print =Stack frame:-5729092 formal print = non-local jump
When I try to run the test trough make it crashes with message: *** malloc: vm_allocate(size=2147487744) failed (error code=3) *** malloc[14647]: error: Can't allocate region gawk: cmd. line:115: (FILENAME=- FNR=22) fatal: grow_iop_buffer: iop->buf: can't allocate -2147483646 bytes of memory (Cannot allocate memory) make: *** [pascal.check-dejagnu] Error 2
Because of this I run the tests directly as: PC="gpc" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log
I am running the tests right now so it should be finished in the evening. Thanks for a quick response.
Jan
On Jan 5, 2005, at 03:55, Adriaan van Os wrote:
jan.ruzicka@comcast.net wrote:
the test fjf949.pas from the test suite gpc-test-20041218.tar.gz (beta) seems to be getting into a endless loop.
The test passes with my (non fink) copy of gpc, based on gcc-3.3.3 and gpc-20041218. Can you can give some more information (e.g. gpc -v) ?
There were more test failures in test suite, but this one seems to be the most critical.
Try
[G4:gcc/p/test] adriaan% make EXTRA_PFLAGS=--longjmp-all-nonlocal-labels
and report the results.
Regards,
Adriaan van Os
jan.ruzicka@comcast.net wrote:
The gpc -v gives:
Reading specs from /sw/lib/gcc-lib/powerpc-apple-darwin/3.3.2/specs Configured with: ./gpc-332d1/configure --prefix=/sw --enable-languages=c,pascal --enable-threads=posix --infodir=/sw/src/root-gpc-3.3.2d1-7/sw/share/info --mandir=/sw/src/root-gpc-3.3.2d1-7/sw/share/man --target=powerpc-apple-darwin Thread model: posix gpc version 20030830, based on gcc-3.3.2
(sorry it seems to be a dated one gpc version 20030830)
Yes, I already wondered. I hope to make a new gpc for Mac OS X available soon, based on gpc-20041218 and gcc-3.4. The fink release will follow, I assume.
I left tests to run overnight and the test_run interrupted the test by itself: TEST fjf949.pas: ./test_run: line 336: 12525 Cputime limit exceeded ./"$A_OUT" "$1" the tests ended with :
This test isn't in the testsuite for gpc-20030830, so you are running the wrong testsuite (see http://www.microbizz.nl/gpc332d1.src.tar.bz2 for the one that came with gpc-20030830).
TEST fproc.pas: 9,23117273c9,11 < ake_delayed_ 8 formal print =Stack frame: -1 formal print = non-local jump and followed by 5729091 similar lines: ending : < ake_delayed_ 8 formal print =Stack frame:-5729092 formal print = non-local jump
Known issue (try --longjmp-all-nonlocal-labels).
When I try to run the test trough make it crashes with message: *** malloc: vm_allocate(size=2147487744) failed (error code=3) *** malloc[14647]: error: Can't allocate region
Strange, because this looks like the systemtest.pas test that fails because of a bug in Mac OS X. Does it crash immediately on "make" ? What about the testsuite that came with gpc-20030830 ?
Regards,
Adriaan van Os
This time the gpc 3.3.2d1 finished the test suite 20041218. The --longjmp-all-nonlocal-labels helped.
The make for tests crashes fairly soon (about 10 tests). I did not try the gpc-20030830 test suite.
I am trying to compile the gpc-20041218 on OSX and update the fink package.
configuration was throwing an error: configure: error: The following requested languages were not found: pascal The following languages were available: c treelang Configure in /Users/janruzicka/Desktop/downloads/gpc-build/gcc failed, exiting.
The config did not see the config-lang.in for pascal.
find . -name "config-lang.in" in the gcc source directory did not show anything for gcc/p. the p directory had to be copied to gcc.
Can anybody add a note to compilation instructions (http://www.gnu-pascal.de/gpc/Compiling-GPC.html)? the note should say any think like: find . -name "config-lang.in" | xargs grep language= should return a line with pascal: ./gcc/p/config-lang.in:language="pascal" (this would save me fair amount of time of searching around all different manuals)
Now the GPC configures and starts to compile. Next obstacle is bison error in parse.c (USE_ASSERT_RATHER_THAN_ABORT). Lets see the bison package will be updated. (bison-2.0 was released on 04-Jan-2005)
That's it for tonight (this morning).
Jan
Can you give me some more tips for compiling GPC?
On Jan 5, 2005, at 09:26, Adriaan van Os wrote:
jan.ruzicka@comcast.net wrote:
I hope to make a new gpc for Mac OS X available soon, based on gpc-20041218 and gcc-3.4. The fink release will follow, I assume.
This test isn't in the testsuite for gpc-20030830, so you are running the wrong testsuite (see http://www.microbizz.nl/gpc332d1.src.tar.bz2 for the one that came with gpc-20030830).
Strange, because this looks like the systemtest.pas test that fails because of a bug in Mac OS X. Does it crash immediately on "make" ? What about the testsuite that came with gpc-20030830 ?
Regards,
Adriaan van Os
jan.ruzicka@comcast.net wrote:
This time the gpc 3.3.2d1 finished the test suite 20041218. The --longjmp-all-nonlocal-labels helped.
The make for tests crashes fairly soon (about 10 tests). I did not try the gpc-20030830 test suite.
I am trying to compile the gpc-20041218 on OSX and update the fink package.
You are entirely free to do so, but may want to wait a little until I update the compiler sources and binaries at my website (that the current fink package is based on). This will include some additional patches.
configuration was throwing an error: configure: error: The following requested languages were not found: pascal The following languages were available: c treelang Configure in /Users/janruzicka/Desktop/downloads/gpc-build/gcc failed, exiting.
The config did not see the config-lang.in for pascal.
find . -name "config-lang.in" in the gcc source directory did not show anything for gcc/p. the p directory had to be copied to gcc.
Can anybody add a note to compilation instructions (http://www.gnu-pascal.de/gpc/Compiling-GPC.html)? the note should say any think like: find . -name "config-lang.in" | xargs grep language= should return a line with pascal: ./gcc/p/config-lang.in:language="pascal" (this would save me fair amount of time of searching around all different manuals)
http://www.microbizz.nl/gpc332d1.src.tar.bz2 includes detailed building instructions.
Now the GPC configures and starts to compile. Next obstacle is bison error in parse.c (USE_ASSERT_RATHER_THAN_ABORT).
You need a special version of bison. Frank Heckenbach can tell you which one.
Lets see the bison package will be updated. (bison-2.0 was released on 04-Jan-2005)
That's it for tonight (this morning).
Jan
Can you give me some more tips for compiling GPC?
Yes, because of differences between fsf-gcc and apple-gcc, it is recommended that you bootstrap the compiler (or install an fsf-gcc first). See the instructions that come with http://www.microbizz.nl/gpc332d1.src.tar.bz2.
Regards,
Adriaan van Os
Adriaan van Os wrote:
find . -name "config-lang.in" in the gcc source directory did not show anything for gcc/p. the p directory had to be copied to gcc.
Can anybody add a note to compilation instructions (http://www.gnu-pascal.de/gpc/Compiling-GPC.html)? the note should say any think like: find . -name "config-lang.in" | xargs grep language= should return a line with pascal: ./gcc/p/config-lang.in:language="pascal" (this would save me fair amount of time of searching around all different manuals)
The documentation mentions moving the directory:
: @samp{cd} to the GPC directory and move the contents (a subdirectory : @file{p}) to the subdirectory @file{gcc} of the GCC directory: : : @smallexample : % mv /home/fred/gpc-20030209/p /home/fred/gcc-2.95.3/gcc/ : @end smallexample : : Instead of moving the directory, it is now also possible to make a : symbolic link (if the OS supports symlinks). This is useful if you : want to build GPC with several different GCC versions: : : @smallexample : % ln -s /home/fred/gpc-20030209/p /home/fred/gcc-2.95.3/gcc/p : @end smallexample
http://www.microbizz.nl/gpc332d1.src.tar.bz2 includes detailed building instructions.
Now the GPC configures and starts to compile. Next obstacle is bison error in parse.c (USE_ASSERT_RATHER_THAN_ABORT).
You need a special version of bison. Frank Heckenbach can tell you which one.
Lets see the bison package will be updated. (bison-2.0 was released on 04-Jan-2005)
Yes, fortunately we now have a stable bison version that we can use. I've checked that GPC works properly with it. So hopefully we're at least done with that ugly alpha/beta dependency.
So I recommend getting bison-2.0 (ftp://ftp.gnu.org/gnu/bison/bison-2.0.tar.gz) and using it for all GPC compilations.
Frank
I modified my local fink package to install gpc-20041218. it downloads the gcc-core-3.3.3.tar.bz2 and the gpc-20041218.tar.gz, compiles and installs.
The installation will have to be more tweaked, It does not put all documentation to the right places etc. The executable is generated. I am running the test suite over night.
I am definitely looking forward to Adriaans' patches.
test suite after a while crashes on: .... | tee test_log | "./test_sum" -d the error is: *** malloc: vm_allocate(size=2147487744) failed (error code=3) *** malloc[16396]: error: Can't allocate region gawk: cmd. line:115: (FILENAME=- FNR=22) fatal: grow_iop_buffer: iop->buf: can't allocate -2147483646 bytes of memory (Cannot allocate memory)
it happens with the "test_run" pipe and/or following command tail -f test_log | ./test_sum -d (the command was executed as the test is running) same on the static file just hangs as the tail -f is waiting for data added to the file.
following commands work: ./test_sum -d < test_log cat test_log | ./test_sum -d cat test_log | tee /tmp/tmp111111 | ./test_sum -d
That's all for tonight.
Jan
On Jan 6, 2005, at 03:07, Adriaan van Os wrote:
jan.ruzicka@comcast.net wrote:
This time the gpc 3.3.2d1 finished the test suite 20041218. The --longjmp-all-nonlocal-labels helped.
The make for tests crashes fairly soon (about 10 tests). I did not try the gpc-20030830 test suite.
I am trying to compile the gpc-20041218 on OSX and update the fink package.
You are entirely free to do so, but may want to wait a little until I update the compiler sources and binaries at my website (that the current fink package is based on). This will include some additional patches.
configuration was throwing an error: configure: error: The following requested languages were not found: pascal The following languages were available: c treelang Configure in /Users/janruzicka/Desktop/downloads/gpc-build/gcc failed, exiting.
The config did not see the config-lang.in for pascal.
find . -name "config-lang.in" in the gcc source directory did not show anything for gcc/p. the p directory had to be copied to gcc.
Can anybody add a note to compilation instructions (http://www.gnu-pascal.de/gpc/Compiling-GPC.html)? the note should say any think like: find . -name "config-lang.in" | xargs grep language= should return a line with pascal: ./gcc/p/config-lang.in:language="pascal" (this would save me fair amount of time of searching around all different manuals)
http://www.microbizz.nl/gpc332d1.src.tar.bz2 includes detailed building instructions.
Now the GPC configures and starts to compile. Next obstacle is bison error in parse.c (USE_ASSERT_RATHER_THAN_ABORT).
You need a special version of bison. Frank Heckenbach can tell you which one.
Lets see the bison package will be updated. (bison-2.0 was released on 04-Jan-2005)
That's it for tonight (this morning).
Jan
Can you give me some more tips for compiling GPC?
Yes, because of differences between fsf-gcc and apple-gcc, it is recommended that you bootstrap the compiler (or install an fsf-gcc first). See the instructions that come with http://www.microbizz.nl/gpc332d1.src.tar.bz2.
Regards,
Adriaan van Os
Jan-Ruzickas-Computer:~/Desktop/downloads/gpc-20041218/p/test janruzicka$ ./test_sum < test_log Test Run By janruzicka on 2005-01-07 01:11:40 Native configuration is powerpc-apple-darwin (Jan-Ruzickas-Computer.local) gpc 20041218, based on gcc-3.3.3, flags: -g -O3 -W -Wall -Wno-unused TEST aregextest.pas: SKIPPED: librx not installed TEST asmtest.pas: SKIPPED: only for IA32 TEST fjf165a.pas: ./fjf165a.cmp: line 40: unexpected EOF while looking for matching `"' ./fjf165a.cmp: line 42: syntax error: unexpected end of file TEST fjf558m.pas: O./test_run: line 336: 23294 Segmentation fault ./"$A_OUT" "$1" TEST fjf558n.pas: O./test_run: line 336: 23315 Segmentation fault ./"$A_OUT" "$1" TEST fjf558o.pas: O./test_run: line 336: 23336 Segmentation fault ./"$A_OUT" "$1" TEST fjf558p.pas: O./test_run: line 336: 23357 Segmentation fault ./"$A_OUT" "$1" TEST fproc.pas: 9c9,11 < ./test_run: line 336: 17581 Segmentation fault ./"$A_OUT" "$1" ---
Stack frame: 8 formal print = -1 formal routine = -1 Stack frame: 9 formal print = -1 formal routine = -1 Stack frame: 10 formal print = -1 formal routine = -1
failed TEST goto5.pas: O./test_run: line 336: 18086 Segmentation fault ./"$A_OUT" "$1" TEST longr2.pas: SKIPPED: no LongReal math routines available TEST nlgpp2.pas: 14c14,30 < ./test_run: line 336: 24176 Segmentation fault ./"$A_OUT" "$1" ---
OK Recursive end 3 True Recursive before goto 4 True Recursive end 4 True Recursive before goto 5 True Recursive end 5 True Recursive before goto 6 True Recursive end 6 True Recursive before goto 7 True Recursive end 7 True Recursive before goto 8 True Recursive end 8 True Recursive before goto 9 True Recursive end 9 True Recursive before goto 10 True Recursive end 10 True Main end
failed TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[452]: error: Can't allocate region *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[452]: error: Can't allocate region OK
# of tests 4112 # of expected passes 4100 # of unexpected failures 9 # of unsupported tests 3
jan.ruzicka@comcast.net wrote:
Jan-Ruzickas-Computer:~/Desktop/downloads/gpc-20041218/p/test janruzicka$ ./test_sum < test_log Test Run By janruzicka on 2005-01-07 01:11:40 Native configuration is powerpc-apple-darwin (Jan-Ruzickas-Computer.local) gpc 20041218, based on gcc-3.3.3, flags: -g -O3 -W -Wall -Wno-unused TEST aregextest.pas: SKIPPED: librx not installed TEST asmtest.pas: SKIPPED: only for IA32 TEST fjf165a.pas: ./fjf165a.cmp: line 40: unexpected EOF while looking for matching `"' ./fjf165a.cmp: line 42: syntax error: unexpected end of file TEST fjf558m.pas: O./test_run: line 336: 23294 Segmentation fault ./"$A_OUT" "$1" TEST fjf558n.pas: O./test_run: line 336: 23315 Segmentation fault ./"$A_OUT" "$1" TEST fjf558o.pas: O./test_run: line 336: 23336 Segmentation fault ./"$A_OUT" "$1" TEST fjf558p.pas: O./test_run: line 336: 23357 Segmentation fault ./"$A_OUT" "$1" TEST fproc.pas: 9c9,11
< ./test_run: line 336: 17581 Segmentation fault ./"$A_OUT" "$1"
Stack frame: 8 formal print = -1 formal routine = -1 Stack frame: 9 formal print = -1 formal routine = -1 Stack frame: 10 formal print = -1 formal routine = -1
failed TEST goto5.pas: O./test_run: line 336: 18086 Segmentation fault ./"$A_OUT" "$1" TEST longr2.pas: SKIPPED: no LongReal math routines available TEST nlgpp2.pas: 14c14,30
< ./test_run: line 336: 24176 Segmentation fault ./"$A_OUT" "$1"
Try again with --longjmp-all-nonlocal-labels. This works around a bug in gcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901. Please complain l o u d l y on the gcc mailing list.
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[452]: error: Can't allocate region *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[452]: error: Can't allocate region
A bug in Mac OS X. Please report it to devbugs@apple.com.
Regards,
Adriaan van Os
Perhaps search Apple's XCode user mailing list - I seem to vaguely recall a discussion about a similar issue quite some time ago. Sorry I can't remember the details myself.
Grant
jan.ruzicka@comcast.net wrote:
Jan-Ruzickas-Computer:~/Desktop/downloads/gpc-20041218/p/test janruzicka$ ./test_sum < test_log Test Run By janruzicka on 2005-01-07 01:11:40 Native configuration is powerpc-apple-darwin (Jan-Ruzickas-Computer.local) gpc 20041218, based on gcc-3.3.3, flags: -g -O3 -W -Wall -Wno-unused TEST aregextest.pas: SKIPPED: librx not installed TEST asmtest.pas: SKIPPED: only for IA32 TEST fjf165a.pas: ./fjf165a.cmp: line 40: unexpected EOF while looking for matching `"' ./fjf165a.cmp: line 42: syntax error: unexpected end of file TEST fjf558m.pas: O./test_run: line 336: 23294 Segmentation fault ./"$A_OUT" "$1" TEST fjf558n.pas: O./test_run: line 336: 23315 Segmentation fault ./"$A_OUT" "$1" TEST fjf558o.pas: O./test_run: line 336: 23336 Segmentation fault ./"$A_OUT" "$1" TEST fjf558p.pas: O./test_run: line 336: 23357 Segmentation fault ./"$A_OUT" "$1" TEST fproc.pas: 9c9,11
< ./test_run: line 336: 17581 Segmentation fault ./"$A_OUT" "$1"
Stack frame: 8 formal print = -1 formal routine = -1 Stack frame: 9 formal print = -1 formal routine = -1 Stack frame: 10 formal print = -1 formal routine = -1
failed TEST goto5.pas: O./test_run: line 336: 18086 Segmentation fault ./"$A_OUT" "$1" TEST longr2.pas: SKIPPED: no LongReal math routines available TEST nlgpp2.pas: 14c14,30
< ./test_run: line 336: 24176 Segmentation fault ./"$A_OUT" "$1"
Try again with --longjmp-all-nonlocal-labels. This works around a bug in gcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901. Please complain l o u d l y on the gcc mailing list.
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[452]: error: Can't allocate region *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[452]: error: Can't allocate region
A bug in Mac OS X. Please report it to devbugs@apple.com.
Regards,
Adriaan van Os
*** top-posting fixed *** Grant Jacobs wrote:
jan.ruzicka@comcast.net wrote:
Jan-Ruzickas-Computer:~/Desktop/downloads/gpc-20041218/p/test
... snip ...
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[452]: error: Can't allocate region *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[452]: error: Can't allocate region
A bug in Mac OS X. Please report it to devbugs@apple.com.
Perhaps search Apple's XCode user mailing list - I seem to vaguely recall a discussion about a similar issue quite some time ago. Sorry I can't remember the details myself.
Why a bug? Any malloc system has the right to limit assignment size. In this case I expect it is probably using sbrk calls to the system, and allowing for negative arguments to return core to the system. That assignment size is ridiculous on the face of it, and the test simply exposes a system limit.
CBFalconer wrote:
*** top-posting fixed *** Grant Jacobs wrote:
jan.ruzicka@comcast.net wrote:
Jan-Ruzickas-Computer:~/Desktop/downloads/gpc-20041218/p/test
... snip ...
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[452]: error: Can't allocate region *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[452]: error: Can't allocate region
A bug in Mac OS X. Please report it to devbugs@apple.com.
Perhaps search Apple's XCode user mailing list - I seem to vaguely recall a discussion about a similar issue quite some time ago. Sorry I can't remember the details myself.
Why a bug? Any malloc system has the right to limit assignment size.
But then malloc must return NULL (which GPC will translate into a proper error message) instead of crashing or terminating the program.
Frank
Frank Heckenbach wrote:
CBFalconer wrote:
Grant Jacobs wrote:
jan.ruzicka@comcast.net wrote:
Jan-Ruzickas-Computer:~/Desktop/downloads/gpc-20041218/p/test
... snip ...
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[452]: error: Can't allocate region *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[452]: error: Can't allocate region
A bug in Mac OS X. Please report it to devbugs@apple.com.
Perhaps search Apple's XCode user mailing list - I seem to vaguely recall a discussion about a similar issue quite some time ago. Sorry I can't remember the details myself.
Why a bug? Any malloc system has the right to limit assignment size.
But then malloc must return NULL (which GPC will translate into a proper error message) instead of crashing or terminating the program.
Oh. Didn't realize the errors were internal to malloc. Unbelievably sloppy.
Thanks again better result: ------------------------------------------------------------------------ ------ ./test_sum -d < test_log Test Run By janruzicka on 2005-01-07 07:49:15 Native configuration is powerpc-apple-darwin (Jan-Ruzickas-Computer.local)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas FAIL: fjf165a.pas UNSUPPORTED: longr2.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 4112 # of expected passes 4107 # of unexpected failures 2 # of unsupported tests 3
gpc version 20041218, based on gcc-3.3.3 ------------------------------------------------------------------------ ------ TEST fjf165a.pas: ./fjf165a.cmp: line 40: unexpected EOF while looking for matching `"' ./fjf165a.cmp: line 42: syntax error: unexpected end of file ------------------------------------------------------------------------ ------ Does anybody have any idea what may cause this?
Thanks Jan
On Jan 7, 2005, at 04:38, Adriaan van Os wrote:
Try again with --longjmp-all-nonlocal-labels. This works around a bug in gcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901. Please complain l o u d l y on the gcc mailing list.
TEST systemtest.pas: *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[452]: error: Can't allocate region *** malloc: vm_allocate(size=2147483648) failed (error code=3) *** malloc[452]: error: Can't allocate region
A bug in Mac OS X. Please report it to devbugs@apple.com.
Regards,
Adriaan van Os
jan.ruzicka@comcast.net wrote:
TEST fjf165a.pas: ./fjf165a.cmp: line 40: unexpected EOF while looking for matching `"' ./fjf165a.cmp: line 42: syntax error: unexpected end of file
Does anybody have any idea what may cause this?
Line 40 of the fjf165a.cmp reads:
echo "SKIPPED: German locale not installed"
Maybe the file is damaged ?
Regards,
Adriaan van Os
jan.ruzicka@comcast.net wrote:
TEST fjf165a.pas: ./fjf165a.cmp: line 40: unexpected EOF while looking for matching `"' ./fjf165a.cmp: line 42: syntax error: unexpected end of file
Does anybody have any idea what may cause this?
I can reproduce it now on Mac OS X 10.3, it doesn't happen on Mac OS X 10.2. I guess it has something to do with the redirection used in the fjf165a.cmp script, but this is really something for shell-script experts:
#!/bin/sh
# Try setting German locale (locally ;-) # # Which variables do we really need to set? (Probably not all of # these, but better be safe than sorry. ;-) # # The complicated redirecting is necessary on Solaris' shell which # otherwise would give messages "couldn't set locale correctly" # in the variable assignments that can't seem to be redirected # normally.
exec 3>&2 2> /dev/null LC_ALL=de_DE; export LC_ALL LC_CTYPE=de_DE; export LC_CTYPE LANG=de_DE; export LANG exec 2>&3
# Test if German locale actually works (i.e., whether the locale # database is installed on the system) cat << EOF > dummy.c #include <ctype.h> #include <locale.h> int main() { setlocale (LC_ALL, ""); printf ("%c\n", toupper ((unsigned char) '‰')); } EOF if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"ƒ" ]; then rm -f "$A_OUT" dummy.c $1 $2 if [ -r "$A_OUT" ] ; then ./"$A_OUT" else echo "failed" fi else rm -f dummy.c echo "SKIPPED: German locale not installed" fi
Regards,
Adriaan van Os
Adriaan van Os wrote:
jan.ruzicka@comcast.net wrote:
TEST fjf165a.pas: ./fjf165a.cmp: line 40: unexpected EOF while looking for matching `"' ./fjf165a.cmp: line 42: syntax error: unexpected end of file
Does anybody have any idea what may cause this?
I can reproduce it now on Mac OS X 10.3, it doesn't happen on Mac OS X 10.2. I guess it has something to do with the redirection used in the fjf165a.cmp script, but this is really something for shell-script experts:
if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"Â" ]; then
I guess we can take out one pair of quotes. Shouldn't really be a problem (just paranoia). Apparently that shell doesn't like nested quotes.
if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./$A_OUT 2> /dev/null`" = x"Ã" ]; then
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
jan.ruzicka@comcast.net wrote:
TEST fjf165a.pas: ./fjf165a.cmp: line 40: unexpected EOF while looking for matching `"' ./fjf165a.cmp: line 42: syntax error: unexpected end of file
Does anybody have any idea what may cause this?
I can reproduce it now on Mac OS X 10.3, it doesn't happen on Mac OS X 10.2. I guess it has something to do with the redirection used in the fjf165a.cmp script, but this is really something for shell-script experts:
if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"Â" ]; then
^^ (quote mark as anti wrap move) ^
shouldn't that thing above be ", not /"? I have no idea what it is all doing.
I guess we can take out one pair of quotes. Shouldn't really be a problem (just paranoia). Apparently that shell doesn't like nested quotes.
if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./$A_OUT 2> /dev/null`" = x"Ã" ]; then
I can reproduce it now on Mac OS X 10.3, it doesn't happen on Mac OS X 10.2. I guess it has something to do with the redirection used in the fjf165a.cmp script, but this is really something for shell-script experts:
if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"ƒ" ]; then
^^ (quote mark as anti wrap move) ^shouldn't that thing above be ", not /"? I have no idea what it is all doing.
Lets split it into blocks: 1) gcc dummy.c > /dev/null 2>&1 compiles dummy.c and redirects output (stdout,stderr) to /dev/null (bit bucket) 2) [ -r "$A_OUT" ] test if $A_OUT exists and is readable. 3) x"`./"$A_OUT" 2> /dev/null`" = x"ƒ" test if $A_OUT outputs ƒ 3.a) `./"$A_OUT" 2> /dev/null` execute $A_OUT and redirect stderr to /dev/null 3.b) compare outputs
I would suggest rewrite the conditions to a multiple lines/blocks. something like : ------------------------------------------------------- gcc dummy.c > /dev/null 2>&1 if [ ! $? ]; then echo "failed: can not compile the test C code" exit(1) fi if [ ! -r $A_OUT ]; then echo "failed: can not read the test C code" exit(1) fi ./$A_OUT 2> /dev/null 1>./$A_OUT.dat rm -f "$A_OUT" dummy.c printf "\x80" > ./${A_OUT}2.dat
if [ ! -r $A_OUT.dat ] || [ ! -r $A_OUT.dat ]; then echo "failed: can not read output of the test C code" exit(1) fi
cmp ./$A_OUT.dat ./${A_OUT}2.dat > /dev/null 2>&1 if [ $? ]; then $1 $2 else rm -f dummy.c echo "SKIPPED: German locale not installed" fi -------------------------------------------------------
comparison can be also ./$A_OUT 2> /dev/null | hexdump >./$A_OUT.dat # ... file tests as previous diff./$A_OUT.dat <<EOF 0000000 8000 0000001 EOF
Question is what exactly are we testing?
Are we testing that the compiler, shell and function toupper can work with non ASCII characters [in this case A umlaut]? printf ("%c\n", toupper ((unsigned char) '‰')); or
Are we testing the ability of toupper converting a non ASCII character ? printf ("%c\n", toupper ((unsigned char) 0x80));
The difference can be significant on some platforms.
Adriaan the non ASCII character was important for this test.
Is there any standard and portable way to obtain a selected localized letter? Example get platform representation of A-umlaut or u-circle.
The issue here is that different platforms can have different encoding of the character. Unicode vs. Latin-1, Windows etc.
Jan
jan.ruzicka@comcast.net wrote:
Adriaan the non ASCII character was important for this test.
I understand that, of course. The test with A instead of A-umlaut just proved where the script failed.
Is there any standard and portable way to obtain a selected localized letter? Example get platform representation of A-umlaut or u-circle.
The issue here is that different platforms can have different encoding of the character. Unicode vs. Latin-1, Windows etc.
Same for fjf165a.pas, which looks like this on the Macintosh,
... var i:1..n; c:t=('a','B','‰','÷','fl','-'); { Only with German locale } u:t=('A','B','ƒ','÷','fl','-'); l:t=('a','b','‰','ˆ','fl','-'); ...
Regards,
Adriaan van Os g
jan.ruzicka@comcast.net wrote:
Lets split it into blocks:
- gcc dummy.c > /dev/null 2>&1
compiles dummy.c and redirects output (stdout,stderr) to /dev/null (bit bucket)
Yes, because failure doesn't necessarily mean a problem with GPC, but perhaps just that the German locale is not installed, and the test should be skipped.
- [ -r "$A_OUT" ]
test if $A_OUT exists and is readable.
Yes, perhaps superfluous since the next step would fail as well, but shouldn't hurt.
- x"`./"$A_OUT" 2> /dev/null`" = x"Â"
test if $A_OUT outputs  3.a) `./"$A_OUT" 2> /dev/null` execute $A_OUT and redirect stderr to /dev/null 3.b) compare outputs
I would suggest rewrite the conditions to a multiple lines/blocks. something like :
gcc dummy.c > /dev/null 2>&1 if [ ! $? ]; then echo "failed: can not compile the test C code" exit(1) fi
Generally, I wouldn't object, but I find `||' easier to read (and more common, in shell scripts) than `[ ! $? ]'. (I'm generally a bit wary of `$?' because it adds an inter-statement dependency; adding something between the lines can cause non-obvious problems. So I rather don't use `$?' unless really necessary.)
if [ ! -r $A_OUT ]; then echo "failed: can not read the test C code"
The compiled program, BTW.
exit(1)
Shouldn't it be `exit 1'?
Also, I'd generally quote all variables in shell scripts unless explicitly meant not to. Though $A_OUT is probably harmless, anything that might contain a directory might also contain spaces nowadays, e.g. ...
printf "\x80" > ./${A_OUT}2.dat
comparison can be also ./$A_OUT 2> /dev/null | hexdump >./$A_OUT.dat # ... file tests as previous diff./$A_OUT.dat <<EOF 0000000 8000 0000001 EOF
Now, this is the actually tricky part. Apart from the fact that I'm not sure if we should require hexdump as a dependency, 80 is at least not the most common character code for A-umlaut.
Question is what exactly are we testing?
Are we testing that the compiler, shell and function toupper can work with non ASCII characters [in this case A umlaut]? printf ("%c\n", toupper ((unsigned char) 'Â')); or
We shouldn't really test the shell.
Are we testing the ability of toupper converting a non ASCII character ? printf ("%c\n", toupper ((unsigned char) 0x80));
Is there any standard and portable way to obtain a selected localized letter? Example get platform representation of A-umlaut or u-circle.
The issue here is that different platforms can have different encoding of the character. Unicode vs. Latin-1, Windows etc.
Exactly.
Well, we can surely remove the shell non-ASCII dependency. E.g., we can check the result within the C program and output 1 if it matches:
printf ("%i\n", toupper ((unsigned char) 'À') == (unsigned char) 'Ã');
[...]
if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"1" ]; then
If we then move the C program to a separate file, the shell won't have to deal with those characters. E.g., put it in fjf165a.c and put this in the script:
#!/bin/sh
# Try setting German locale (locally ;-) # # Which variables do we really need to set? (Probably not all of # these, but better be safe than sorry. ;-) # # The complicated redirecting is necessary on Solaris' shell which # otherwise would give messages "couldn't set locale correctly" # in the variable assignments that can't seem to be redirected # normally.
exec 3>&2 2> /dev/null LC_ALL=de_DE; export LC_ALL LC_CTYPE=de_DE; export LC_CTYPE LANG=de_DE; export LANG exec 2>&3
# Test if German locale actually works (i.e., whether the locale # database is installed on the system) if gcc "`dirname "$2"`"/fjf165a.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"1" ]; then rm -f "$A_OUT" $1 $2 if [ -r "$A_OUT" ] ; then ./"$A_OUT" else echo "failed" fi else echo "SKIPPED: German locale not installed" fi
Then we've restricted those characters to the compilers which should at least read them. If they don't treat them as expected (Latin[129]/Unicode), the test will be skipped which is acceptable. If someone would like to add support for other charsets in fjf165a.{c,pas}, go ahead, but note that the main problem might be to find a suitable test for the current charset (a system conditional probably won't suffice).
Frank
if we move the locale test completely to the C test file why don't we return result (pass/fail) in the exit code? ------------- #include <ctype.h> #include <locale.h> /* test for a correctly working locale. * for reference see: * http://czyborra.com/charsets/iso8859.html */ int main() { int rv = 0; setlocale (LC_ALL, ""); rv = rv || (toupper ((unsigned char) 'ä') == (unsigned char) 'Ä'); /* text ä to Ä */ rv = rv || (toupper ((unsigned char) 0xe4) == (unsigned char) 0xc4); /* codes for Latin[1-9] */ return ( ! rv ); /* revert to the shell meaning of the logic 0 == true; 0 != false */ } ------------- This way the test can be just a return value: ./"${A_OUT}" > /dev/null 2>&1
Jan
On Jan 26, 2005, at 11:56, Frank Heckenbach wrote:
jan.ruzicka@comcast.net wrote:
I would suggest rewrite the conditions to a multiple lines/blocks. something like :
gcc dummy.c > /dev/null 2>&1 if [ ! $? ]; then echo "failed: can not compile the test C code" exit(1) fi
Generally, I wouldn't object, but I find `||' easier to read (and more common, in shell scripts) than `[ ! $? ]'. (I'm generally a bit wary of `$?' because it adds an inter-statement dependency; adding something between the lines can cause non-obvious problems. So I rather don't use `$?' unless really necessary.)
You have a valid point.
Should it be then: ------------ gcc dummy.c > /dev/null 2>&1 ||\ echo "SKIPPED: can not compile the test C code" && exit 1 ------------
if [ ! -r $A_OUT ]; then echo "failed: can not read the test C code"
The compiled program, BTW.
exit(1)Shouldn't it be `exit 1'?
Also, I'd generally quote all variables in shell scripts unless explicitly meant not to. Though $A_OUT is probably harmless, anything that might contain a directory might also contain spaces nowadays, e.g. ...
printf "\x80" > ./${A_OUT}2.dat
comparison can be also ./$A_OUT 2> /dev/null | hexdump >./$A_OUT.dat # ... file tests as previous diff./$A_OUT.dat <<EOF 0000000 8000 0000001 EOF
Now, this is the actually tricky part. Apart from the fact that I'm not sure if we should require hexdump as a dependency, 80 is at least not the most common character code for A-umlaut.
Question is what exactly are we testing?
Are we testing that the compiler, shell and function toupper can work with non ASCII characters [in this case A umlaut]? printf ("%c\n", toupper ((unsigned char) '')); or
We shouldn't really test the shell.
Are we testing the ability of toupper converting a non ASCII character ? printf ("%c\n", toupper ((unsigned char) 0x80));
Is there any standard and portable way to obtain a selected localized letter? Example get platform representation of A-umlaut or u-circle.
The issue here is that different platforms can have different encoding of the character. Unicode vs. Latin-1, Windows etc.
Exactly.
Well, we can surely remove the shell non-ASCII dependency. E.g., we can check the result within the C program and output 1 if it matches:
printf ("%i\n", toupper ((unsigned char) 'ä') == (unsigned char) 'Ä');
[...]
if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"1" ]; then
If we then move the C program to a separate file, the shell won't have to deal with those characters. E.g., put it in fjf165a.c and put this in the script:
#!/bin/sh
# Try setting German locale (locally ;-) # # Which variables do we really need to set? (Probably not all of # these, but better be safe than sorry. ;-) # # The complicated redirecting is necessary on Solaris' shell which # otherwise would give messages "couldn't set locale correctly" # in the variable assignments that can't seem to be redirected # normally.
exec 3>&2 2> /dev/null LC_ALL=de_DE; export LC_ALL LC_CTYPE=de_DE; export LC_CTYPE LANG=de_DE; export LANG exec 2>&3
# Test if German locale actually works (i.e., whether the locale # database is installed on the system) if gcc "`dirname "$2"`"/fjf165a.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"1" ]; then rm -f "$A_OUT" $1 $2 if [ -r "$A_OUT" ] ; then ./"$A_OUT" else echo "failed" fi else echo "SKIPPED: German locale not installed" fi
Then we've restricted those characters to the compilers which should at least read them. If they don't treat them as expected (Latin[129]/Unicode), the test will be skipped which is acceptable. If someone would like to add support for other charsets in fjf165a.{c,pas}, go ahead, but note that the main problem might be to find a suitable test for the current charset (a system conditional probably won't suffice).
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8
jan.ruzicka@comcast.net wrote:
if we move the locale test completely to the C test file why don't we return result (pass/fail) in the exit code? This way the test can be just a return value: ./"${A_OUT}" > /dev/null 2>&1
Indeed, that's a little easier.
Frank
On Wed, Jan 26, 2005 at 05:56:06PM +0100, Frank Heckenbach wrote: [...]
If we then move the C program to a separate file, the shell won't have to deal with those characters. E.g., put it in fjf165a.c and put this in the script:
#!/bin/sh
# Try setting German locale (locally ;-) # # Which variables do we really need to set? (Probably not all of # these, but better be safe than sorry. ;-) # # The complicated redirecting is necessary on Solaris' shell which # otherwise would give messages "couldn't set locale correctly" # in the variable assignments that can't seem to be redirected # normally.
exec 3>&2 2> /dev/null LC_ALL=de_DE; export LC_ALL LC_CTYPE=de_DE; export LC_CTYPE LANG=de_DE; export LANG exec 2>&3
# Test if German locale actually works (i.e., whether the locale # database is installed on the system) if gcc "`dirname "$2"`"/fjf165a.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"1" ]; then rm -f "$A_OUT" $1 $2 if [ -r "$A_OUT" ] ; then ./"$A_OUT" else echo "failed" fi else echo "SKIPPED: German locale not installed" fi
Since the test does not actually test anything German specific, but rather handling of Latin 1 characters, it would be a good idea to specifically request this charset in the locale settings, i.e.:
LC_ALL=de_DE.iso-8859-1; export LC_ALL
and so on.
Emil
Emil Jerabek wrote:
Since the test does not actually test anything German specific, but rather handling of Latin 1 characters, it would be a good idea to specifically request this charset in the locale settings, i.e.:
LC_ALL=de_DE.iso-8859-1; export LC_ALL
Indeed, thanks for the idea.
Frank
CBFalconer wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
jan.ruzicka@comcast.net wrote:
TEST fjf165a.pas: ./fjf165a.cmp: line 40: unexpected EOF while looking for matching `"' ./fjf165a.cmp: line 42: syntax error: unexpected end of file
Does anybody have any idea what may cause this?
I can reproduce it now on Mac OS X 10.3, it doesn't happen on Mac OS X 10.2. I guess it has something to do with the redirection used in the fjf165a.cmp script, but this is really something for shell-script experts:
if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"Â" ]; then
^^ (quote mark as anti wrap move) ^shouldn't that thing above be ", not /"? I have no idea what it is all doing.
The standard directory separator is /. Even on Dos, sane shells (such as bash) recognize this. ;-)
Frank
Frank Heckenbach wrote:
CBFalconer wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
jan.ruzicka@comcast.net wrote:
TEST fjf165a.pas: ./fjf165a.cmp: line 40: unexpected EOF while looking for matching `"' ./fjf165a.cmp: line 42: syntax error: unexpected end of file
Does anybody have any idea what may cause this?
I can reproduce it now on Mac OS X 10.3, it doesn't happen on Mac OS X 10.2. I guess it has something to do with the redirection used in the fjf165a.cmp script, but this is really something for shell-script experts:
if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"Â" ]; then
^^ (quote mark as anti wrap move) ^shouldn't that thing above be ", not /"? I have no idea what it is all doing.
The standard directory separator is /. Even on Dos, sane shells (such as bash) recognize this. ;-)
I thought it might be escaping a quote mark.
CBFalconer dixit:
if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"" ]; then
I thought it might be escaping a quote mark.
Due to some people still not getting that $(...) is to be used over the less portable `...` that can happen ;)
Also an interesting read on the ` character: http://www.cl.cam.ac.uk/~mgk25/ucs/apostrophe.html
if gcc dummy.c >/dev/null 2>&1 && [ -r "$A_OUT" ] \ && [ x"$(./"$A_OUT" 2>/dev/null)" = x"^C" ]; then
bye, //mirabile
PS: I prefer the following ;) but that's not too portable since it requires mksh:
if gcc dummy.c >/dev/null 2>&1 && [[ -r $A_OUT ]] \ && [[ $(./"$A_OUT" 2>/dev/null) = ^C ]]; then
Thorsten Glaser wrote:
CBFalconer dixit:
> if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"" ]; then
I thought it might be escaping a quote mark.
Backslash is the escape character. (That's one reason why using it as the directory separator under Dos is a bad idea -- so its native shells don't have an escape character and perhaps for this reason Dos didn't allow characters such as `*' in file names at all.)
Due to some people still not getting that $(...) is to be used over the less portable `...` that can happen ;)
I think you're wrong. According to http://www.mpi-sb.mpg.de/~uwe/lehre/unixffb/quoting-guide.html:
: Both bash and ksh offer an alternative syntax for backquoted : commands. Instead of `command` they allow us to write $(command).
[I.e., the original Bourne shell doesn't support $(...).]
That's what I seemed to remember as well, but it took me some time to find a reference for it (mainly because ` and $() are bad Google search terms ;-).
So while $(...) can avoid some syntactical problems (mainly if nested, which isn't the case here, just like the `...` wasn't the problem at all in this thread), it is actually less, not more, portable than `...`, AFAICS.
If you have evidence to the contrary, feel free to post it here. Otherwise it might be time for an apology, as some people might take "not getting that" as a personal offense ...
Also an interesting read on the ` character: http://www.cl.cam.ac.uk/~mgk25/ucs/apostrophe.html
While I usually appreciate Markus Kuhn's writings, I think here he's a little off.
E.g., when he writes. "Some US developers made use of the spacing grave accent (which they called "backquote") in the syntax of various command languages. The few instances where this happened are: [...]", he misses, above all, and probably apart from some cases not mentioned, its use as a left quote in GNU (and not only GNU) style messages such as `foobar'. I use this convention myself, and I don't think I'm a US developer. ;-) And considering that `...', treating ` as a left ("back") quote, is the only way to get something like paired quotes at all in plain ASCII, this still seems a reasonable choice.
BTW, note he doesn't even claim that $(...) was more portable than `...`. In fact, he speaks about bash (not sh, or Bourne shell in this context).
In the end, it's simply that the character ` (whatever you call it) is an ASCII character. Given that ASCII is the base of most characters sets in use today, and that it's not exactly overly rich with punctuation characters, I can't agree to abandoning one of those few that exist because of potential keyboard layout problems. If there are really problems, they should fix their keyboards by adding the necessary keys instead.
He mentions a German standard of 1995 which hasn't been widely implemented so far and I hope never will, which actually plans to remove two keys, while in the meantime they apparently didn't mind adding 3 "Windows" keys and (on some keyboards) some 10-20 "multimedia" keys, and let's not mention the num block which consists of 16 complete duplications. So if there's really shortage of keys to enter all desired characters with accents, they should simply add the necessary keys for accents and perhaps, finally, a compose key (because even with so many dead-accent keys, there are still some characters you can't enter, such as Þ, Ê or å; a compose keys lets you enter these characters and at the same time alleviates any possible problems they might still have with accents).
BTW, I'm saying "they" because he only writes about Windows and X11 platforms. Me, being a happy text mode user as much as possible, I'm not affected by those problems.
This is not surprising to me since IME, X11 (and probably all GUIs) are not exactly best ideals WRT keyboard bindings at all. E.g., every xterm (and similar) I've used so far has had problems with function keys and similar. (Maybe it was only a wrong terminfo entry, at least in some cases, but since it would be the responsibility of the authors and packagers, not of me as the user, to correct it, I consider it broken just as well.) Compared to these problems, I consider the possible issues with accents and quotes rather minor.
BTW, in case you're objecting to the fact that characters are used in a meaning different from their typographic intention in programming (and other formal) languages, that's nothing special with that particular character, of course. Even in Pascal we have things like `..' (standard Pascal), `=>' and `base#number' and `**' (EP), or `#number' (BP), e.g., even while other languages are much heavier in this regard.
Frank
Frank Heckenbach wrote: <snip>
E.g., when he writes. "Some US developers made use of the spacing grave accent (which they called "backquote") in the syntax of various command languages. The few instances where this happened are: [...]", he misses, above all, and probably apart from some cases not mentioned, its use as a left quote in GNU (and not only GNU) style messages such as `foobar'. I use this convention myself, and I don't think I'm a US developer. ;-) And considering that `...', treating ` as a left ("back") quote, is the only way to get something like paired quotes at all in plain ASCII, this still seems a reasonable choice.
This is appropriate as *input* in TeX, which converts it nicely, and may be appropriate as input in other source-code-like things, but the mismatched quotes look frankly hideous when *output* on any modern computer. Paired straight quotes look better.
I think the more interesting reference is: http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
We are trying to fix this. I think it's a reported bug in texinfo that the generated info documents contain these bogus "quote" pairs. (The generated TeX documents, of course, contain nice curly quotes.)
<snip>
BTW, I'm saying "they" because he only writes about Windows and X11 platforms. Me, being a happy text mode user as much as possible, I'm not affected by those problems.
Well, it looks bad on my text mode console as well.... :-)
BTW, in case you're objecting to the fact that characters are used in a meaning different from their typographic intention in programming (and other formal) languages, that's nothing special with that particular character, of course. Even in Pascal we have things like `..' (standard Pascal), `=>' and `base#number' and `**' (EP), or `#number' (BP), e.g., even while other languages are much heavier in this regard.
You mean "..", "=>", "base#number", "**", or "#number", right? ;-)
Nathanael Nerode dixit:
(sorry, don't find the original message from Frank.)
its use as a left quote in GNU (and not only GNU) style messages such as `foobar'
The GNU project seems to have ceased to do this and in fact I have heard that gcc 4.0 uses the correct unicode quotation marks for the en_US.UTF-8 locale (on locale-aware operating systems such as the GNU) and plain '...' on the C/POSIX locales.
ASCII does not have such a thing as paired quotation marks.
The best you can emulate it is via `...� but the latter is latin1, and neither of these characters can stand alone, they are composing characters (and usually deadkeys).
bye, //mirabile
Nathanael Nerode wrote:
but the mismatched quotes look frankly hideous when *output* on any modern computer.
Thank you, my computer is quite modern, and they look fine. It's a matter of the font used, obviously, the computer used to display them has hardly anything to do with it.
I think the more interesting reference is: http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
Which, BTW, says that `...` in shell scripts "does not have to be changed and remains unaffected."
Even in Pascal we have things like `..' (standard Pascal), `=>' and `base#number' and `**' (EP), or `#number' (BP), e.g., even while other languages are much heavier in this regard.
You mean "..", "=>", "base#number", "**", or "#number", right? ;-)
Well, on this basis (Nathanael, making silly overgeneralizations and putting words, er characters ;-), in my mouth, and Thorsten, making wrong accusations combined with personal offence) it's pointless to discuss any further, and the issue isn't relevant to the origial topic anyway, so I consider this thread closed.
Frank
Frank Heckenbach wrote:
I think the more interesting reference is: http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
Which, BTW, says that `...` in shell scripts "does not have to be changed and remains unaffected."
Quite right.
On Jan 25, 2005, at 11:56, Frank Heckenbach wrote:
I guess we can take out one pair of quotes. Shouldn't really be a problem (just paranoia). Apparently that shell doesn't like nested quotes.
if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./$A_OUT 2> /dev/null`" = x"Ä" ]; then
Is there any way to have the non ASCII character escaped? I don't think the shell script necessary needs to reproduce non ascii characters correctly. Possibilities are compare result of hexdump or generate the output in a different way and use cmp.
What character should it be anyway? I see it as a capital letter A with umlaut. Saved in a file it is 8000 hex.
Jan Ruzicka
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8
jan.ruzicka@comcast.net wrote:
Is there any way to have the non ASCII character escaped? I don't think the shell script necessary needs to reproduce non ascii characters correctly.
Ah, you mean the non ASCII character is the problem ? Yes, when I change the test from A-umlaut to A, it passes (although it is trivial then). So, it wasn't the redirection after all.
Regards.
Adriaan van Os
[G5:gcc/p/test] adriaan% cat test_log Test Run By adriaan on 2005-01-26 04:33:36 Native configuration is powerpc-apple-darwin7 (G5.local) gpc 20041218, based on gcc-3.4.3, flags: -g -O3 -W -Wall -Wno-unused GPC-TEST-BEGIN ========================== TEST fjf165a.pas: OK
========================== GPC-TEST-END [G5:gcc/p/test] adriaan% cat fjf165a.cmp #!/bin/sh
# Try setting German locale (locally ;-) # # Which variables do we really need to set? (Probably not all of # these, but better be safe than sorry. ;-) # # The complicated redirecting is necessary on Solaris' shell which # otherwise would give messages "couldn't set locale correctly" # in the variable assignments that can't seem to be redirected # normally.
exec 3>&2 2> /dev/null LC_ALL=de_DE; export LC_ALL LC_CTYPE=de_DE; export LC_CTYPE LANG=de_DE; export LANG exec 2>&3
# Test if German locale actually works (i.e., whether the locale # database is installed on the system) cat << EOF > dummy.c #include <ctype.h> #include <locale.h> int main() { setlocale (LC_ALL, ""); printf ("%c\n", toupper ((unsigned char) 'a')); } EOF if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./"$A_OUT" 2> /dev/null`" = x"A" ]; then rm -f "$A_OUT" dummy.c $1 $2 if [ -r "$A_OUT" ] ; then ./"$A_OUT" else echo "failed" fi else rm -f dummy.c echo "SKIPPED: German locale not installed" fi
jan.ruzicka@comcast.net wrote:
On Jan 25, 2005, at 11:56, Frank Heckenbach wrote:
I guess we can take out one pair of quotes. Shouldn't really be a problem (just paranoia). Apparently that shell doesn't like nested quotes.
if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./$A_OUT 2> /dev/null`" = x"Ã" ]; then
Is there any way to have the non ASCII character escaped? I don't think the shell script necessary needs to reproduce non ascii characters correctly. Possibilities are compare result of hexdump or generate the output in a different way and use cmp.
What character should it be anyway? I see it as a capital letter A with umlaut.
Yes, that's what it should be.
Saved in a file it is 8000 hex.
That's strange. I know of no such charset. In Latin[129] (and perhaps some more) as well as Unicode it's hex C4. The output also contains a newline which is 0A (or 0D, or 0D, 0A on some systems). Nothing remotely similar to 8000!?
Adriaan van Os wrote:
The Macintosh has another character set for values > 127. The A-umlaut is auto-converted when you copy and paste it from email, but in the original script it looks like "Â" on the Mac. Does Linux/Unix have the same character set as WIndows (or the other way round) ?
Both Linux and Windows can use different charsets. Most systems, at least in Europe and America, probably use either Unicode or Latin1/Latin2/Latin9 AKA ISO 8859-1/-2/-15 (Linux) or a bastardization of it (Windows -- AFAIUI, they call it windows-1252, but sometimes wrongly declare it to be Latin1, e.g. in mail headers; the typical symptoms are wrong Euro signs, dashes and (non-ASCII) quotes, most other characters, including umlauts, seem to be the same).
Frank
Frank Heckenbach wrote:
Saved in a file it is 8000 hex.
That's strange. I know of no such charset. In Latin[129] (and perhaps some more) as well as Unicode it's hex C4. The output also contains a newline which is 0A (or 0D, or 0D, 0A on some systems). Nothing remotely similar to 8000!?
In the Macintosh character set, capital-A-umlaut has hex value 80 ...
Then we've restricted those characters to the compilers which should at least read them. If they don't treat them as expected (Latin[129]/Unicode), the test will be skipped which is acceptable. If someone would like to add support for other charsets in fjf165a.{c,pas}, go ahead, but note that the main problem might be to find a suitable test for the current charset (a system conditional probably won't suffice).
... but I don't mind if the test is skipped.
Regards,
Adriaan van Os
Hi, List! Could please someone clarify the situation with range-checking in GPC. I've downloaded and installed the latest version available at the moment (gpc version 20041218, based on gcc-3.3.4, RedHat 9, kernel 2.6.7). Test suite of the same version has been successfully passed (all tests ok, one skipped). It is written in the documentation that "--range-checking" option is already available. It's really available but it seems to me that it doesn't work or I've misunderstood something. Anyway, the test program below doesn't work - it hangs (actually, it runs in infinite loop since an assignment in the body of the loop overwrites the value of i by zero at every pass) instead of catch run-time error as it should be. Am I doing something wrong? I've built the program using "gpc --range-checking test.pas".
program test; {$R+} var a: array [0..1] of byte; i: byte; begin writeln ('test started'); for i := 0 to 2 do begin a [i] := 0; end; writeln ('test passed'); end.
Best regards, Igor Marnat mailto:marny@rambler.ru
Igor Marnat wrote:
Could please someone clarify the situation with range-checking in GPC. I've downloaded and installed the latest version available at the moment (gpc version 20041218, based on gcc-3.3.4, RedHat 9, kernel 2.6.7). Test suite of the same version has been successfully passed (all tests ok, one skipped). It is written in the documentation that "--range-checking" option is already available. It's really available but it seems to me that it doesn't work or I've misunderstood something.
It only does a few things so far (sets and dynamic ranges), as was noted in the respective announcement. The next alpha version might contain full range-checking support.
Frank
Hi, List! I've got the problem while tried to compile the program attached below with gpc of version "gpc version 20041218, based on gcc-3.3.4.". It is a bug, isn't it? Is it possible to do something to compile the program?
I compiled it with command line "gpc test.pas".
Compiler output: test.pas: In main program: test.pas:9: error: arithmetical overflow test.pas:9: error: size of variable `set_result_Test_0' is too large
Program:
program test; var s: set of byte; t:byte; begin s := []; t := 1; s := s + [t]; end.
Best regards, Igor mailto:marny@rambler.ru
Igor Marnat wrote:
I've got the problem while tried to compile the program attached below with gpc of version "gpc version 20041218, based on gcc-3.3.4.". It is a bug, isn't it? Is it possible to do something to compile the program?
For a quick workaround, declare t as `0 .. 255'.
I compiled it with command line "gpc test.pas".
Compiler output: test.pas: In main program: test.pas:9: error: arithmetical overflow test.pas:9: error: size of variable `set_result_Test_0' is too large
Program:
program test; var s: set of byte; t:byte; begin s := []; t := 1; s := s + [t]; end.
I found that this is (indirectly) due to build_range_type (tree.c) not setting
TREE_UNSIGNED (itype) = TREE_UNSIGNED (type);
Waldek, do you think this should be changed in the backend, or should we work around it in the frontend?
Frank
Frank Heckenbach wrote:
I found that this is (indirectly) due to build_range_type (tree.c) not setting
TREE_UNSIGNED (itype) = TREE_UNSIGNED (type);
Waldek, do you think this should be changed in the backend, or should we work around it in the frontend?
Logically `build_range_type' should set `TREE_UNSIGNED'. However, I suspect that some places in the compiler expect `build_range_type' to return signed type (like `build_index_2_type'). Still, I would change `build_range_type' and then fix places depending on old behaviour.
Waldek Hebisch wrote:
Frank Heckenbach wrote:
I found that this is (indirectly) due to build_range_type (tree.c) not setting
TREE_UNSIGNED (itype) = TREE_UNSIGNED (type);
Waldek, do you think this should be changed in the backend, or should we work around it in the frontend?
Logically `build_range_type' should set `TREE_UNSIGNED'. However, I suspect that some places in the compiler expect `build_range_type' to return signed type (like `build_index_2_type').
When I tried it with the backend change, I got no regressions.
Our use of build_index_2_type should be uncritical as well, since the range (only used for string literals) is always positive. Still I'm turning it into `build_range_type (pascal_integer_type_node, ...)' to avoid issues with TYPE_IS_SIZETYPE (and possibly to get a larger range, though this might not likely be necessary for string literals ;-).
The two uses of build_range_type in the C frontend (c-decl.c) look suspicious (strange things about "zero-leng arrays" and "flexible array members", whatever that is). I haven't tested how the change would affect them (i.e., if I didn't make it `#ifdef GPC'), but perhaps changing sizetype to ssizetype there might resolve the problems, if any. (In both cases, the lower bound is the constant 0, and the upper bound is NULL_TREE, so unsignedness might not actually be a problem at all.)
I haven't looked at other frontends.
Still, I would change `build_range_type' and then fix places depending on old behaviour.
I'm doing this now (adding it to the backend diffs).
Frank
Hello Frank,
I've got the problem while tried to compile the program attached below with gpc of version "gpc version 20041218, based on gcc-3.3.4.". It is a bug, isn't it? Is it possible to do something to compile the program?
FH> For a quick workaround, declare t as `0 .. 255'.
Frank, thank you, it works. BTW, i tried the previous version of gpc (20041017). It shows the same results.
Best regards, Igor Marnat mailto:marny@rambler.ru
Frank Heckenbach wrote:
I guess we can take out one pair of quotes. Shouldn't really be a problem (just paranoia). Apparently that shell doesn't like nested quotes.
if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ] && [ x"`./$A_OUT 2> /dev/null`" = x"Ä" ]; then
Thanks for the hint, but it doesn't help:
[G5:gcc/p/test] adriaan% cat test_log Test Run By adriaan on 2005-01-26 04:10:04 Native configuration is powerpc-apple-darwin7 (G5.local) gpc 20041218, based on gcc-3.4.3, flags: -g -O3 -W -Wall -Wno-unused GPC-TEST-BEGIN ========================== TEST fjf165a.pas: ./fjf165a.cmp: line 40: unexpected EOF while looking for matching `"' ./fjf165a.cmp: line 42: syntax error: unexpected end of file
========================== GPC-TEST-END
jan.ruzicka@comcast.net wrote:
Is there any way to have the non ASCII character escaped? I don't think the shell script necessary needs to reproduce non ascii characters correctly. Possibilities are compare result of hexdump or generate the output in a different way and use cmp.
What character should it be anyway? I see it as a capital letter A with umlaut. Saved in a file it is 8000 hex.
The Macintosh has another character set for values > 127. The A-umlaut is auto-converted when you copy and paste it from email, but in the original script it looks like "ƒ" on the Mac. Does Linux/Unix have the same character set as WIndows (or the other way round) ?
Regards,
Adriaan van Os
-
Adriaan van Os -
CBFalconer -
Emil Jerabek -
Frank Heckenbach -
Grant Jacobs -
Igor Marnat -
jan.ruzicka＠comcast.net -
Nathanael Nerode -
Thorsten Glaser -
Waldek Hebisch