Hi Built gpc using just released gcc-3.4.6 and gpc-20060215:
passed: 5054 unsuported: aregextest.pas fail: fjf9321.pas, fjf932b.pas
both failures got an ICE at the line "with v do"
Russ
Russell Whitaker wrote:
Built gpc using just released gcc-3.4.6 and gpc-20060215:
passed: 5054 unsuported: aregextest.pas fail: fjf9321.pas, fjf932b.pas
I don't have a fjf9321.pas file.
both failures got an ICE at the line "with v do"
What platform ? On powerpc-apple-darwin7, the testsuite results for gpc-20060215 are the same with gcc-3.4.5 and with gcc-3.4.6 (diff included). Did you try gcc-3.4.5 ?
Regards,
Adriaan van Os
Adriaan van Os wrote:
Russell Whitaker wrote:
Built gpc using just released gcc-3.4.6 and gpc-20060215:
passed: 5054 unsuported: aregextest.pas fail: fjf9321.pas, fjf932b.pas
I don't have a fjf9321.pas file.
Should take me a while to reach that number. ;-)
I guess he meant fjf932a.pas (similar to -b).
Russell, can you provide more detailed failure information, please (make pascal.check-long MASK="fjf932*")?
Frank
Russell Whitaker wrote:
Hi Built gpc using just released gcc-3.4.6 and gpc-20060215:
passed: 5054 unsuported: aregextest.pas fail: fjf9321.pas, fjf932b.pas
both failures got an ICE at the line "with v do"
Russ
This was reported by Angelo Fumagalli. The fix (which I already posted) is :
=================================================================== RCS file: /mn/a8/cvsroot/gpc/p/types.c,v retrieving revision 1.10 diff -u -r1.10 types.c --- p/types.c 15 Feb 2006 02:03:12 -0000 1.10 +++ p/types.c 27 Feb 2006 21:51:28 -0000 @@ -1884,7 +1884,6 @@ tree field2 = sorted_fields[i], ret; if (DECL_NAME (field2) == component) { - gcc_unreachable (); field = field2; break; }
On Wed, 15 Mar 2006, Waldek Hebisch wrote:
Russell Whitaker wrote:
Hi Built gpc using just released gcc-3.4.6 and gpc-20060215:
passed: 5054 unsuported: aregextest.pas fail: fjf9321.pas, fjf932b.pas
both failures got an ICE at the line "with v do"
Russ
This was reported by Angelo Fumagalli. The fix (which I already posted) is :
=================================================================== RCS file: /mn/a8/cvsroot/gpc/p/types.c,v retrieving revision 1.10 diff -u -r1.10 types.c --- p/types.c 15 Feb 2006 02:03:12 -0000 1.10 +++ p/types.c 27 Feb 2006 21:51:28 -0000 @@ -1884,7 +1884,6 @@ tree field2 = sorted_fields[i], ret; if (DECL_NAME (field2) == component) {
gcc_unreachable (); field = field2; break; }
Just now applied patch; did a make clean; make; and full pascal test: same two failures.
uname -a: Linux bigred 2.6.15.5 #1 SMP PREEMPT Fri Mar 3 17:30:44 PST 2006 i686 unknown unknown GNU/Linux
make pascal.check-long MASK="fjf932*" > ~/test 2>&1
rm -f *.dat *.o *.s *.i *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core GP= PC="gpc" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" fjf932* | tee test_log Test Run By russ on 2006-03-15 10:55:02 Native configuration is i686-pc-linux-gnu (bigred) gpc 20060215, based on gcc-3.4.6, flags: -g -O3 -W -Wall -Wno-unused GPC-TEST-BEGIN ========================== TEST fjf932a.pas: ../../gcc-3.4.6/gcc/p/types.c:1887:find_field: failed assertion `unreachable code' ./fjf932a.pas: In main program: ./fjf932a.pas:73: error: Internal compiler error. Please submit a full bug report to the GPC mailing list gpc@gnu.de. See URL:http://www.gnu-pascal.de/todo.html for details. failed TEST fjf932b.pas: ../../gcc-3.4.6/gcc/p/types.c:1887:find_field: failed assertion `unreachable code' ./fjf932b.pas: In main program: ./fjf932b.pas:62: error: Internal compiler error. Please submit a full bug report to the GPC mailing list gpc@gnu.de. See URL:http://www.gnu-pascal.de/todo.html for details. ./fjf932u.pas: No such program failed
========================== GPC-TEST-END
Hope this helps, Russ
Russell Whitaker wrote:
On Wed, 15 Mar 2006, Waldek Hebisch wrote:
This was reported by Angelo Fumagalli. The fix (which I already posted) is :
=================================================================== RCS file: /mn/a8/cvsroot/gpc/p/types.c,v retrieving revision 1.10 diff -u -r1.10 types.c --- p/types.c 15 Feb 2006 02:03:12 -0000 1.10 +++ p/types.c 27 Feb 2006 21:51:28 -0000 @@ -1884,7 +1884,6 @@ tree field2 = sorted_fields[i], ret; if (DECL_NAME (field2) == component) {
gcc_unreachable (); field = field2; break; }Just now applied patch; did a make clean; make; and full pascal test: same two failures.
Most likely you made some mistake (perhaps testing with a previously built GPC), since the error message refers to the exact line Waldek's patch removed.
Please try again, perhaps starting by extracting fresh sources.
Also make sure that the patch applied correctly. Maybe it didn't get through email completely intact. In this case you can check in a text editor that the line was really removed, and if not, do so manually. -- BTW, Waldek, for such reasons, even if i'm not sure it is the actual cause here, it may be preferable to send patches as attachments.
TEST fjf932a.pas: ../../gcc-3.4.6/gcc/p/types.c:1887:find_field: failed assertion `unreachable code' TEST fjf932b.pas: ../../gcc-3.4.6/gcc/p/types.c:1887:find_field: failed assertion `unreachable code'
Frank
On Wed, 15 Mar 2006, Frank Heckenbach wrote:
Russell Whitaker wrote:
On Wed, 15 Mar 2006, Waldek Hebisch wrote:
This was reported by Angelo Fumagalli. The fix (which I already posted) is :
=================================================================== RCS file: /mn/a8/cvsroot/gpc/p/types.c,v retrieving revision 1.10 diff -u -r1.10 types.c --- p/types.c 15 Feb 2006 02:03:12 -0000 1.10 +++ p/types.c 27 Feb 2006 21:51:28 -0000 @@ -1884,7 +1884,6 @@ tree field2 = sorted_fields[i], ret; if (DECL_NAME (field2) == component) {
gcc_unreachable (); field = field2; break; }Just now applied patch; did a make clean; make; and full pascal test: same two failures.
Most likely you made some mistake (perhaps testing with a previously built GPC), since the error message refers to the exact line Waldek's patch removed.
Yes. Doing a "make install" before the test solved the problem.
But, is there a way to force the test suite to use the newly built compiler without having to install it first?
Russ
On Wed, 15 Mar 2006, Russell Whitaker wrote:
On Wed, 15 Mar 2006, Waldek Hebisch wrote:
Russell Whitaker wrote:
Hi Built gpc using just released gcc-3.4.6 and gpc-20060215:
[..] After that last email, as su, did a "make install", and repeated the test: Now they pass !
Oh gee Russ
Russell Whitaker wrote:
On Wed, 15 Mar 2006, Russell Whitaker wrote:
On Wed, 15 Mar 2006, Waldek Hebisch wrote:
Russell Whitaker wrote:
Hi Built gpc using just released gcc-3.4.6 and gpc-20060215:
[..] After that last email, as su, did a "make install", and repeated the test: Now they pass !
BTW, if you run the test in <build_directory>/gcc (sic!), they should even use the freshly built GPC if it wasn't installed. (Useful, so one can test before actual installation.)
If you did that, and it still used the old version, it might be a bug in our Makefiles. Please let us know.
Frank
On Wed, 15 Mar 2006, Frank Heckenbach wrote:
[..]
BTW, if you run the test in <build_directory>/gcc (sic!), they should even use the freshly built GPC if it wasn't installed. (Useful, so one can test before actual installation.)
If you did that, and it still used the old version, it might be a bug in our Makefiles. Please let us know.
Just now tried it. Works corectly.
Thank you, Russ
How can I have the true "sizeof" of variant records? Gpc sizeof accepts only one parameter as type or variable so isn't possible to specify tags parameters for example:
type myrec_t = packed record a: integer; case b: boolean of true: (x: integer; y: integer); false: (case cc: char of 'a': (tst: integer; 'b': (t1: byte; t2: byte); 'c': (tx: real)); end; ... writeln(sizeof(myrec_t,true); writeln(sizeof(myrec_t,false,'a');
I tried to use the new statement instead, e.g.
var p: ^myrec_t;
begin new(p,true); writeln(sizeof(p^)); dispose(p,true); new(p,false,'a'); writeln(sizeof(p^));
but in both cases sizeof return the same value that is the maximum record size.
Thanks in advance.
Angelo Fumagalli
Angelo.Fumagalli@alcatel.it wrote:
How can I have the true "sizeof" of variant records? Gpc sizeof accepts only one parameter as type or variable so isn't possible to specify tags parameters for example:
I tried to use the new statement instead, e.g. but in both cases sizeof return the same value that is the maximum record size.
In GPC that's the "true" size. GPC always allocates the maximum size.
I don't know what you plan to do, but if you're trying to allocate less manually with GetMem etc., that would be dangerous, as assignments can overwrite the "full" size.
If you want to store/load variant parts to/from files, you might better do so fieldwise anyway, for the usual reasons such as padding.
If you need a data structure that allows allocating different amounts of memory, you could look at objects.
Frank
-
Adriaan van Os -
Angelo.Fumagalli＠alcatel.it -
Frank Heckenbach -
Russell Whitaker -
Waldek Hebisch