I have uploaded a new alpha version of GPC to http://www.gnu-pascal.de/alpha/.
This is an ALPHA version. Not so many extensive tests have been made and the test suite is not expected to pass without errors. I'm not uploading binaries, diffs, separate test suite archives, updated web pages etc., just the source distribution. (Of course, others may feel free to upload binaries for various platforms.) I'm not aware of any serious bugs, but you have to decide for yourself whether to use it for production work.
New features:
* new options `--[no]-nonlocal-exit' (default in `--ucsd-pascal' and `--mac-pascal') (fjf988[fijk].pas, fjf1062*.pas) (U) (M)
* new options `--[no]-object-checking' (on by default) to check on virtual method calls if VMT pointer is not nil and has matching `Size' and `NegatedSize' entries, new options `--[no]-range-and-object-checking' which are now equivalent to `$R[+-]' (fjf1053*.pas) (B)
* new options `--[no]-pointer-checking', `--[no]-pointer-checking-user-defined'; new variable `ValidatePointerPtr' (fjf1052*.pas, pcerrorc.pas) (these options are _off_ by default!)
* new options `--[no]-implicit-result' (fjf1022*.pas) (on by default *only* in `--delphi' mode!) (D) (@)
* new options `--{en,dis}able-predefined-identifier' (fjf1037*.pas)
- Bug fixes:
* check initializers of unused types (fjf898*.pas)
* check identifier scopes stricter (az25.pas, fjf1059*.pas)
* in `--borland-pascal' give only a warning, not an error, for duplicate `case' elements (drf6*.pas)
* multi-dimensional `packed' arrays are not correctly packed (fjf149*.pas)
* check arithmetical overflow in constants somewhat better (fjf206*.pas)
* check duplicate external declarations stricter (fjf948.pas)
* check that actual discriminants match in parameters and assignments, and in strict EP mode, check that actual discriminants of parameters within one identifier list match (berend4.pas, fjf104[45]*.pas, typeof[2-4].pas)
* check pointer to schema types stricter (fjf130.pas, fjf614.pas, schema3a.pas affected)
* allow importing the same value as a result of distinct expressions under the same name for EP modules for ordinal, pointer, string and set constants (fjf1040*.pas, stef1.pas)
* allow attributes for procedural types (chief56.pas)
* problem with string operations and `goto' (contour0.pas, contourbug.pas, martin1.pas, berend3.pas)
* check `goto' targets more strictly 261020020000077022%gpaeper@empirenet.com, Pine.LNX.4.44.0210281004000.31943-100000@duch.mimuw.edu.pl (az48.pas, fjf701*.pas, fjf1038*.pas, gale6.pas)
* `Result' is not completely Delphi compatible (fjf1022*.pas)
* problem if a `Write' or `WriteLn' argument calls a routine which writes to the same file (fjf1036.pas)
* `Update' as well as writing after reading or checking `EOF' can get the file position wrong in some cases (arp2*.pas, fjf159.pas, fjf160*.pas)
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
On Thu, 31 Mar 2005 23:21:20 +0200, Frank Heckenbach frank@g-n-u.de wrote:
I have uploaded a new alpha version of GPC to http://www.gnu-pascal.de/alpha/.
This is an ALPHA version. Not so many extensive tests have been made and the test suite is not expected to pass without errors. I'm not uploading binaries, diffs, separate test suite archives, updated web pages etc., just the source distribution. (Of course, others may feel free to upload binaries for various platforms.) I'm not aware of any serious bugs, but you have to decide for yourself whether to use it for production work.
A diff is available at http://www.csclub.uwaterloo.ca/~ja2morri/pascal/200502-200503.diff.gz
On 31 Mar 2005 at 23:21, Frank Heckenbach wrote:
I have uploaded a new alpha version of GPC to http://www.gnu-pascal.de/alpha/.
[...]
Compilation under Mingw (gcc-3.2.3) fails with this:
../../gcc/p/declarations.c: In function `mark_binding_level': ../../gcc/p/declarations.c:1587: error: `shared_decl_lang_specific' undeclared (first use in this function) ../../gcc/p/declarations.c:1587: error: (Each undeclared identifier is reported only once ../../gcc/p/declarations.c:1587: error: for each function it appears in.)
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
On 1 Apr 2005 at 7:58, I wrote:
Compilation under Mingw (gcc-3.2.3) fails with this:
../../gcc/p/declarations.c: In function `mark_binding_level': ../../gcc/p/declarations.c:1587: error: `shared_decl_lang_specific' undeclared (first use in this function) ../../gcc/p/declarations.c:1587: error: (Each undeclared identifier is reported only once ../../gcc/p/declarations.c:1587: error: for each function it appears in.)
When I commented out the relevant line, further attempts at compilation led to this: "../../gcc/p/lang.c:1236: error: conflicting types for 'lang_mark_tree' ../../gcc/ggc.h:184: error: previous declaration of 'lang_mark_tree' was here ../../gcc/p/lang.c:1236: error: conflicting types for 'lang_mark_tree' ../../gcc/ggc.h:184: error: previous declaration of 'lang_mark_tree' was here ../../gcc/p/lang.c: In function `lang_mark_tree': ../../gcc/p/lang.c:1237: error: invalid type argument of `->' ../../gcc/p/lang.c:1243: error: invalid type argument of `->' ../../gcc/p/lang.c:1249: error: invalid type argument of `->' ../../gcc/p/lang.c:1249: error: invalid type argument of `->' ../../gcc/p/lang.c:1251: error: invalid type argument of `->' ../../gcc/p/lang.c:1260: error: invalid type argument of `->' ../../gcc/p/lang.c:1260: error: invalid type argument of `->' ../../gcc/p/lang.c:1262: error: invalid type argument of `->'"
Conclusion: It seems that this alpha is broken under gcc < 3.3.x
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 1 Apr 2005 at 7:58, I wrote:
Compilation under Mingw (gcc-3.2.3) fails with this:
../../gcc/p/declarations.c: In function `mark_binding_level': ../../gcc/p/declarations.c:1587: error: `shared_decl_lang_specific' undeclared (first use in this function) ../../gcc/p/declarations.c:1587: error: (Each undeclared identifier is reported only once ../../gcc/p/declarations.c:1587: error: for each function it appears in.)
When I commented out the relevant line, further attempts at compilation led to this: "../../gcc/p/lang.c:1236: error: conflicting types for 'lang_mark_tree' ../../gcc/ggc.h:184: error: previous declaration of 'lang_mark_tree' was here ../../gcc/p/lang.c:1236: error: conflicting types for 'lang_mark_tree' ../../gcc/ggc.h:184: error: previous declaration of 'lang_mark_tree' was here ../../gcc/p/lang.c: In function `lang_mark_tree': ../../gcc/p/lang.c:1237: error: invalid type argument of `->' ../../gcc/p/lang.c:1243: error: invalid type argument of `->' ../../gcc/p/lang.c:1249: error: invalid type argument of `->' ../../gcc/p/lang.c:1249: error: invalid type argument of `->' ../../gcc/p/lang.c:1251: error: invalid type argument of `->' ../../gcc/p/lang.c:1260: error: invalid type argument of `->' ../../gcc/p/lang.c:1260: error: invalid type argument of `->' ../../gcc/p/lang.c:1262: error: invalid type argument of `->'"
Conclusion: It seems that this alpha is broken under gcc < 3.3.x
Actually, with 3.2 only (which is the version I didn't test with ...)
Frank
On 1 Apr 2005 at 14:26, Frank Heckenbach wrote:
[...]
Conclusion: It seems that this alpha is broken under gcc < 3.3.x
Actually, with 3.2 only (which is the version I didn't test with ...)
That attached patch solves those problems, thanks.
However, I now get this: p/integrate.o:integrate.c:(.text+0x3f4): undefined reference to `copy_lang_decl'
BTW: Delphi has a facility for aliasing units: "-A<unit>=<alias>". I think we discussed this quite a while ago. Does gpc now have this feature, and, if not, is it planned? Thanks.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku wrote:
On 1 Apr 2005 at 14:26, Frank Heckenbach wrote:
[...]
Conclusion: It seems that this alpha is broken under gcc < 3.3.x
Actually, with 3.2 only (which is the version I didn't test with ...)
That attached patch solves those problems, thanks.
However, I now get this: p/integrate.o:integrate.c:(.text+0x3f4): undefined reference to `copy_lang_decl'
That one is easy: --- p.orig/gbe.h Fri Mar 25 21:53:14 2005 +++ p/gbe.h Fri Apr 1 15:42:18 2005 @@ -162,6 +162,9 @@ extern void (*print_error_function) (const char *); extern PTR alloca (size_t); extern tree void_list_node; +#endif + +#ifndef GCC_3_3 #define copy_decl_lang_specific copy_lang_decl #endif
But for me the build crashes later trying to compile GPC runtime. I am looking now what the problem is.
On 1 Apr 2005 at 16:31, Waldek Hebisch wrote:
[...]
However, I now get this: p/integrate.o:integrate.c:(.text+0x3f4): undefined reference to `copy_lang_decl'
That one is easy: --- p.orig/gbe.h Fri Mar 25 21:53:14 2005 +++ p/gbe.h Fri Apr 1 15:42:18 2005 @@ -162,6 +162,9 @@ extern void (*print_error_function) (const char *); extern PTR alloca (size_t); extern tree void_list_node; +#endif
+#ifndef GCC_3_3 #define copy_decl_lang_specific copy_lang_decl #endif
But for me the build crashes later trying to compile GPC runtime.
Same here. It segfaults on compiling error.pas
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku wrote:
Same here. It segfaults on compiling error.pas
OK, I have build gcc-3.2.3 based gpc. I applied the following patch (includes the change Frank posted and my previous patch):
diff -u p.orig/declarations.c p/declarations.c --- p.orig/declarations.c Thu Mar 31 20:04:18 2005 +++ p/declarations.c Fri Apr 1 16:48:36 2005 @@ -328,7 +328,7 @@ } else { -#ifndef GCC_3_3 +#ifndef EGCS97 newlevel->shared_decl_lang_specific = (struct lang_decl *) xmalloc (sizeof (*(newlevel->shared_decl_lang_specific))); #else newlevel->shared_decl_lang_specific = (struct lang_decl *) ggc_alloc (sizeof (*(newlevel->shared_decl_lang_specific))); @@ -1584,7 +1584,7 @@ ggc_mark_tree (level->shadowed); ggc_mark_tree (level->blocks); ggc_mark_tree (level->this_block); - ggc_mark (shared_decl_lang_specific); + ggc_mark (level->shared_decl_lang_specific); } } #endif Common subdirectories: p.orig/demos and p/demos Common subdirectories: p.orig/diffs and p/diffs Common subdirectories: p.orig/doc and p/doc diff -u p.orig/gbe.h p/gbe.h --- p.orig/gbe.h Fri Mar 25 21:53:14 2005 +++ p/gbe.h Fri Apr 1 15:42:18 2005 @@ -162,6 +162,9 @@ extern void (*print_error_function) (const char *); extern PTR alloca (size_t); extern tree void_list_node; +#endif + +#ifndef GCC_3_3 #define copy_decl_lang_specific copy_lang_decl #endif
diff -u p.orig/lang.c p/lang.c --- p.orig/lang.c Thu Mar 31 19:52:05 2005 +++ p/lang.c Fri Apr 1 16:59:41 2005 @@ -1232,7 +1232,7 @@ #else
void -lang_mark_tree (int t) +lang_mark_tree (tree t) { if (TREE_CODE (t) == IDENTIFIER_NODE) {
Waldek Hebisch wrote:
Prof A Olowofoyeku wrote:
Same here. It segfaults on compiling error.pas
OK, I have build gcc-3.2.3 based gpc. I applied the following patch (includes the change Frank posted and my previous patch):
Thanks, I guess I should start testing with 3.2 again when I make further changes.
diff -u p.orig/declarations.c p/declarations.c --- p.orig/declarations.c Thu Mar 31 20:04:18 2005 +++ p/declarations.c Fri Apr 1 16:48:36 2005 @@ -328,7 +328,7 @@ } else { -#ifndef GCC_3_3 +#ifndef EGCS97 newlevel->shared_decl_lang_specific = (struct lang_decl *) xmalloc (sizeof (*(newlevel->shared_decl_lang_specific))); #else newlevel->shared_decl_lang_specific = (struct lang_decl *) ggc_alloc (sizeof (*(newlevel->shared_decl_lang_specific)));
BTW, the same change could perhaps be made in line 315 above. But as I can't test it ATM, I better no do it. It's probably not very important there, and if 3.2 is dropped after integrating the preprocessor, it won't matter much in the long run anyway.
Frank
Frank Heckenbach wrote:
+#ifndef EGCS97 newlevel->shared_decl_lang_specific = (struct lang_decl *) xmalloc (sizeof (*(newlevel->shared_decl_lang_specific))); #else newlevel->shared_decl_lang_specific = (struct lang_decl *) ggc_alloc (sizeof (*(newlevel->shared_decl_lang_specific)));
BTW, the same change could perhaps be made in line 315 above. But as I can't test it ATM, I better no do it. It's probably not very important there, and if 3.2 is dropped after integrating the preprocessor, it won't matter much in the long run anyway.
AFAICS the code is correct (for 3.2) now: we allocate binding level with xmalloc in pushlevel and we free it in poplevel. We could use `ggc_alloc', mark it and forget free. The patch below is doing that and apparently works, but I do not know if it worth switching to garbage collector here (if you would like to install the patch I can do more testing).
--- p.pp/declarations.c Fri Apr 1 20:57:29 2005 +++ p/declarations.c Fri Apr 1 20:53:30 2005 @@ -312,7 +312,7 @@ void pushlevel (int transparent) { -#ifndef GCC_3_3 +#ifndef EGCS97 struct binding_level *newlevel = (struct binding_level *) xmalloc (sizeof (*newlevel)); #else struct binding_level *newlevel = (struct binding_level *) ggc_alloc (sizeof (*newlevel)); @@ -328,7 +328,7 @@ } else { -#ifndef GCC_3_3 +#ifndef EGCS97 newlevel->shared_decl_lang_specific = (struct lang_decl *) xmalloc (sizeof (*(newlevel->shared_decl_lang_specific))); #else newlevel->shared_decl_lang_specific = (struct lang_decl *) ggc_alloc (sizeof (*(newlevel->shared_decl_lang_specific))); @@ -455,7 +455,7 @@ else if (level->blocks) current_binding_level->blocks = chainon (current_binding_level->blocks, level->blocks);
-#ifndef GCC_3_3 +#ifndef EGCS97 free (level); #endif
@@ -1585,6 +1585,7 @@ ggc_mark_tree (level->blocks); ggc_mark_tree (level->this_block); ggc_mark (level->shared_decl_lang_specific); + ggc_mark (level); } } #endif
Waldek Hebisch wrote:
Frank Heckenbach wrote:
+#ifndef EGCS97 newlevel->shared_decl_lang_specific = (struct lang_decl *) xmalloc (sizeof (*(newlevel->shared_decl_lang_specific))); #else newlevel->shared_decl_lang_specific = (struct lang_decl *) ggc_alloc (sizeof (*(newlevel->shared_decl_lang_specific)));
BTW, the same change could perhaps be made in line 315 above. But as I can't test it ATM, I better no do it. It's probably not very important there, and if 3.2 is dropped after integrating the preprocessor, it won't matter much in the long run anyway.
AFAICS the code is correct (for 3.2) now: we allocate binding level with xmalloc in pushlevel and we free it in poplevel. We could use `ggc_alloc', mark it and forget free. The patch below is doing that and apparently works, but I do not know if it worth switching to garbage collector here (if you would like to install the patch I can do more testing).
I don't care too much. If you think it needs more testing and don't want to waste your time, we can leave it.
But now I'm wondering -- if we do change it, shouldn't we also remove this (for 3.2):
ggc_add_root (¤t_binding_level, 1, sizeof (current_binding_level), mark_binding_level);
Frank
Waldek Hebisch wrote:
Frank Heckenbach wrote:
+#ifndef EGCS97 newlevel->shared_decl_lang_specific = (struct lang_decl *) xmalloc (sizeof (*(newlevel->shared_decl_lang_specific))); #else newlevel->shared_decl_lang_specific = (struct lang_decl *) ggc_alloc (sizeof (*(newlevel->shared_decl_lang_specific)));
BTW, the same change could perhaps be made in line 315 above. But as I can't test it ATM, I better no do it. It's probably not very important there, and if 3.2 is dropped after integrating the preprocessor, it won't matter much in the long run anyway.
AFAICS the code is correct (for 3.2) now: we allocate binding level with xmalloc in pushlevel and we free it in poplevel. We could use `ggc_alloc', mark it and forget free. The patch below is doing that and apparently works, but I do not know if it worth switching to garbage collector here (if you would like to install the patch I can do more testing).
Frank Heckenbach wrote:
I don't care too much. If you think it needs more testing and don't want to waste your time, we can leave it.
I have run the test suite forcing garbage collection for each function, that should be enough testing for such change.
But now I'm wondering -- if we do change it, shouldn't we also remove this (for 3.2):
ggc_add_root (¤t_binding_level, 1, sizeof (current_binding_level), mark_binding_level);
In marketspeak "this is even more needed that was before". For 3.2 have to manually mark usefull stuff, and do slightly more work in `mark_binding_level'.
Waldek Hebisch wrote:
Waldek Hebisch wrote:
Frank Heckenbach wrote:
+#ifndef EGCS97 newlevel->shared_decl_lang_specific = (struct lang_decl *) xmalloc (sizeof (*(newlevel->shared_decl_lang_specific))); #else newlevel->shared_decl_lang_specific = (struct lang_decl *) ggc_alloc (sizeof (*(newlevel->shared_decl_lang_specific)));
BTW, the same change could perhaps be made in line 315 above. But as I can't test it ATM, I better no do it. It's probably not very important there, and if 3.2 is dropped after integrating the preprocessor, it won't matter much in the long run anyway.
AFAICS the code is correct (for 3.2) now: we allocate binding level with xmalloc in pushlevel and we free it in poplevel. We could use `ggc_alloc', mark it and forget free. The patch below is doing that and apparently works, but I do not know if it worth switching to garbage collector here (if you would like to install the patch I can do more testing).
Frank Heckenbach wrote:
I don't care too much. If you think it needs more testing and don't want to waste your time, we can leave it.
I have run the test suite forcing garbage collection for each function, that should be enough testing for such change.
But now I'm wondering -- if we do change it, shouldn't we also remove this (for 3.2):
I meant "don't".
ggc_add_root (¤t_binding_level, 1, sizeof (current_binding_level), mark_binding_level);
In marketspeak "this is even more needed that was before". For 3.2 have to manually mark usefull stuff, and do slightly more work in `mark_binding_level'.
Yes, with the previous change it's clearly needed. I was wondering if it could be harmful without the previous change. But I'm making the previous change now, so it doesn't really matter. Sorry for the confusion.
Frank
Prof A Olowofoyeku (The African Chief) wrote:
BTW: Delphi has a facility for aliasing units: "-A<unit>=<alias>". I think we discussed this quite a while ago. Does gpc now have this feature,
No, but two (partial) alternatives:
- Modules with `all' extension (if use is foreseen at module writing time). This exports two equivalent interfaces:
module Foo;
export Foo = all; Bar = all;
end;
end.
- Uses propagation (make a unit `Bar' which export everything it imports):
{$propagate-units}
unit Bar;
interface
uses Foo;
implementation
end.
Frank
On 1 Apr 2005 at 17:32, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
BTW: Delphi has a facility for aliasing units: "-A<unit>=<alias>". I think we discussed this quite a while ago. Does gpc now have this feature,
No, but two (partial) alternatives:
[...]
- Uses propagation (make a unit `Bar' which export everything it imports):
{$propagate-units}
unit Bar;
interface
uses Foo;
implementation
end.
Thanks. This could be a useful workaround. It would be nice to have something like "--unit-alias unitname=aliasname", but it probably isn't a trivial thing to implement ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 1 Apr 2005 at 17:32, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
BTW: Delphi has a facility for aliasing units: "-A<unit>=<alias>". I think we discussed this quite a while ago. Does gpc now have this feature,
No, but two (partial) alternatives:
[...]
- Uses propagation (make a unit `Bar' which export everything it imports):
{$propagate-units}
unit Bar;
interface
uses Foo;
implementation
end.
Thanks. This could be a useful workaround. It would be nice to have something like "--unit-alias unitname=aliasname", but it probably isn't a trivial thing to implement ...
Probably not so trivial, since it would affect both GPC (proper), automake and GP. And you didn't really state why you want it. Do you plan to use it regularly for all kinds of units? Or only for a fixed set of units? In the latter case, both alternatives would seem to do as well (the first one with `uses ... in', the second one even without it).
Frank
On 5 Apr 2005 at 21:05, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
On 1 Apr 2005 at 17:32, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
BTW: Delphi has a facility for aliasing units: "-A<unit>=<alias>". I think we discussed this quite a while ago. Does gpc now have this feature,
No, but two (partial) alternatives:
[...]
- Uses propagation (make a unit `Bar' which export everything it imports):
{$propagate-units}
unit Bar;
interface
uses Foo;
implementation
end.
Thanks. This could be a useful workaround. It would be nice to have something like "--unit-alias unitname=aliasname", but it probably isn't a trivial thing to implement ...
Probably not so trivial, since it would affect both GPC (proper), automake and GP.
I thought as much. Not to worry ...
And you didn't really state why you want it.
To avoid endless IFDEFs in USES clauses (and needing to change several source files to achieve this). Probably just a lazy way out - but it is far easier to do: "gpc --automake foo.pas --unit-alias foo2=bar" from the command line than to start to edit any number of source files and change: "USES bar;" to: "USES $ifdef __GPC__} foo2; {$else} bar; {$endif}"
Do you plan to use it regularly for all kinds of units?
Yes, that is how I would use it if it exists.
Or only for a fixed set of units? In the latter case, both alternatives would seem to do as well (the first one with `uses ... in', the second one even without it).
Indeed.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 5 Apr 2005 at 21:05, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
Thanks. This could be a useful workaround. It would be nice to have something like "--unit-alias unitname=aliasname", but it probably isn't a trivial thing to implement ...
Probably not so trivial, since it would affect both GPC (proper), automake and GP.
I thought as much. Not to worry ...
And you didn't really state why you want it.
To avoid endless IFDEFs in USES clauses (and needing to change several source files to achieve this). Probably just a lazy way out - but it is far easier to do: "gpc --automake foo.pas --unit-alias foo2=bar" from the command line than to start to edit any number of source files and change: "USES bar;" to: "USES $ifdef __GPC__} foo2; {$else} bar; {$endif}"
Well, you still don't say why the unit needs to be called differently in the first place.
Aside from the two other solutions (actually I don't really consider them work-arounds -- after all, if you want to import an interface called `foo2', it seems reasonable to export it as such, which both ways do), one could define a macro on the command-line which would also apply to `uses' clauses (but I'd rather consider that a work-around).
Frank
On 31 Mar 2005 at 23:21, Frank Heckenbach wrote:
I have uploaded a new alpha version of GPC to http://www.gnu-pascal.de/alpha/.
[...]
Successfully built under Mingw, based on gcc-3.3.5. There were 8 failures in the testsuite: TEST fjf1021d.pas: ./fjf1021d.pas:7: error: expressions with side- effects are not allowed in schema types failed TEST fjf1021h.pas: ./fjf1021h.pas:6: error: expressions with side- effects are not allowed in schema types failed TEST fjf1021i.pas: ./fjf1021i.pas:8: error: expressions with side- effects are not allowed in schema types failed TEST fjf1021j.pas: ./fjf1021j.pas:6: error: expressions with side- effects are not allowed in schema types failed TEST fjf1021k.pas: ./fjf1021k.pas:7: error: expressions with side- effects are not allowed in schema types failed TEST fjf1042b.pas: failed TEST fjf1042c.pas: failed bc, defgh TEST fjf1044s.pas: ./fjf1044s.pas: In procedure `p': ./fjf1044s.pas:36: internal compiler error: in expand_call, at gcc/calls.c:3110 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. failed
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Results for gpc 200503 on ia64-linux with gcc 3.4.4: === gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas UNSUPPORTED: aregextest.pas FAIL: arp1.pas UNSUPPORTED: asmtest.pas FAIL: chief40.pas FAIL: chief56.pas FAIL: chuck6.pas FAIL: emptyrec.pas FAIL: fieldw.pas FAIL: fjf1000.pas FAIL: fjf1021d.pas FAIL: fjf1021h.pas FAIL: fjf1021i.pas FAIL: fjf1021j.pas FAIL: fjf1021k.pas FAIL: fjf129.pas UNSUPPORTED: fjf165a.pas FAIL: fjf219e.pas FAIL: fjf219f.pas FAIL: fjf23.pas FAIL: fjf30a.pas FAIL: fjf30b.pas FAIL: fjf327.pas FAIL: fjf512.pas FAIL: fjf526a.pas FAIL: fjf526b.pas FAIL: fjf9.pas FAIL: fjf915s.pas a.out(4051): unaligned access to 0x60000000000045d2, ip=0x4000000000003db0 a.out(4051): unaligned access to 0x60000000000045ce, ip=0x4000000000003db1 a.out(4051): unaligned access to 0x60000000000045d2, ip=0x4000000000003db0 a.out(4051): unaligned access to 0x60000000000045ce, ip=0x4000000000003db1 a.out(4221): unaligned access to 0x60000fffffff9e16, ip=0x4000000000003da0 a.out(4221): unaligned access to 0x60000fffffff9e12, ip=0x4000000000003da1 a.out(4221): unaligned access to 0x60000fffffff9e16, ip=0x4000000000003da0 a.out(4221): unaligned access to 0x60000fffffff9e12, ip=0x4000000000003da1 FAIL: fsc22.pas FAIL: fsc24.pas FAIL: math.pas FAIL: mir015.pas FAIL: mir047h.pas FAIL: mir048c.pas FAIL: mir048d.pas FAIL: readb14.pas FAIL: readc14.pas FAIL: reade14.pas FAIL: readg14.pas FAIL: schema2a.pas FAIL: shl.pas FAIL: writeb.pas FAIL: writec.pas FAIL: writee.pas FAIL: writeg.pas
=== gpc Summary ===
# of tests 4946 # of expected passes 4901 # of unexpected failures 41 # of unsupported tests 4
Prof A Olowofoyeku (The African Chief) wrote:
On 31 Mar 2005 at 23:21, Frank Heckenbach wrote:
I have uploaded a new alpha version of GPC to http://www.gnu-pascal.de/alpha/.
[...]
Successfully built under Mingw, based on gcc-3.3.5. There were 8 failures in the testsuite: TEST fjf1021d.pas: ./fjf1021d.pas:7: error: expressions with side- effects are not allowed in schema types failed TEST fjf1021h.pas: ./fjf1021h.pas:6: error: expressions with side- effects are not allowed in schema types failed TEST fjf1021i.pas: ./fjf1021i.pas:8: error: expressions with side- effects are not allowed in schema types failed TEST fjf1021j.pas: ./fjf1021j.pas:6: error: expressions with side- effects are not allowed in schema types failed TEST fjf1021k.pas: ./fjf1021k.pas:7: error: expressions with side- effects are not allowed in schema types failed
These are expected to fail (also to Russ). Waldek and I are working on solving them.
TEST fjf1042b.pas: failed TEST fjf1042c.pas: failed bc, defgh
Apparently mingw doesn't support fcntl() (which is needed internally for these tests). Can you send me (perhaps by PM) your rts-config.h and point me to a current version of mingw system headers, so I can look for a solution or work-around?
TEST fjf1044s.pas: ./fjf1044s.pas: In procedure `p': ./fjf1044s.pas:36: internal compiler error: in expand_call, at gcc/calls.c:3110 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. failed
Can you send a compiler stack backtrace please?
Frank
On 6 Apr 2005 at 17:36, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
[....]
TEST fjf1042b.pas: failed TEST fjf1042c.pas: failed bc, defgh
Apparently mingw doesn't support fcntl() (which is needed internally for these tests). Can you send me (perhaps by PM) your rts-config.h
Attached.
and point me to a current version of mingw system headers,
http://prdownloads.sourceforge.net/mingw/mingw-runtime-3.6.tar.gz
so I can look for a solution or work-around?
TEST fjf1044s.pas: ./fjf1044s.pas: In procedure `p': ./fjf1044s.pas:36: internal compiler error: in expand_call, at gcc/calls.c:3110 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. failed
Can you send a compiler stack backtrace please?
I have no idea how to obtain that!
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.
---- File information ----------- File: rts-config.h Date: 1 Apr 2005, 15:50 Size: 18405 bytes. Type: Program-source
Prof A Olowofoyeku (The African Chief) wrote:
Prof A Olowofoyeku (The African Chief) wrote:
[....]
TEST fjf1042b.pas: failed TEST fjf1042c.pas: failed bc, defgh
Apparently mingw doesn't support fcntl() (which is needed internally for these tests). Can you send me (perhaps by PM) your rts-config.h
Try this patch (to avoid trying to use it if not present).
TEST fjf1044s.pas: ./fjf1044s.pas: In procedure `p': ./fjf1044s.pas:36: internal compiler error: in expand_call, at gcc/calls.c:3110 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. failed
Can you send a compiler stack backtrace please?
I have no idea how to obtain that!
Type `bt' in gdb.
Frank
On 23 Apr 2005 at 4:26, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
Prof A Olowofoyeku (The African Chief) wrote:
[....]
TEST fjf1042b.pas: failed TEST fjf1042c.pas: failed bc, defgh
Apparently mingw doesn't support fcntl() (which is needed internally for these tests). Can you send me (perhaps by PM) your rts-config.h
Try this patch (to avoid trying to use it if not present).
Solves the problem.
TEST fjf1044s.pas: ./fjf1044s.pas: In procedure `p': ./fjf1044s.pas:36: internal compiler error: in expand_call, at gcc/calls.c:3110 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. failed
Can you send a compiler stack backtrace please?
I have no idea how to obtain that!
Type `bt' in gdb.
While or after running what?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 23 Apr 2005 at 4:26, Frank Heckenbach wrote:
Try this patch (to avoid trying to use it if not present).
Solves the problem.
Good.
TEST fjf1044s.pas: ./fjf1044s.pas: In procedure `p': ./fjf1044s.pas:36: internal compiler error: in expand_call, at gcc/calls.c:3110 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions. failed
Can you send a compiler stack backtrace please?
I have no idea how to obtain that!
Type `bt' in gdb.
While or after running what?
As previously:
: > > Can you post a complete traceback or at least error position? (There are : > > many strncmp's in gpc.c, and know which one it is might help.) : > : > Attached ... : > (Mingw)/src/mingw/gcc-3.2.3/build/gcc $gdb xgpc.exe : > GNU gdb 6.3 : > (gdb) run : <snip> : > Program received signal SIGSEGV, Segmentation fault. : > 0x77c47a64 in strncmp () : > (gdb) info line *0x77c47a64 : > No line number information available for address 0x77c47a64 <strncmp+20> : : can you type `bt' here (to get the calling place)?
Frank
On 24 Apr 2005 at 0:22, Frank Heckenbach wrote:
[...]
Type `bt' in gdb.
While or after running what?
As previously:
: > > Can you post a complete traceback or at least error position? (There are : > > many strncmp's in gpc.c, and know which one it is might help.) : > : > Attached ... : > (Mingw)/src/mingw/gcc-3.2.3/build/gcc $gdb xgpc.exe : > GNU gdb 6.3 : > (gdb) run : <snip> : > Program received signal SIGSEGV, Segmentation fault. : > 0x77c47a64 in strncmp () : > (gdb) info line *0x77c47a64 : > No line number information available for address 0x77c47a64 <strncmp+20> : : can you type `bt' here (to get the calling place)?
IIRC, what I ran then was xgpc with no arguments (xgpc was crashing). That doesn't work here. Eventually, what I did was to load gpc1.exe into gdb and to do "run fjf1044s.pas -g -O3 -W". This is the output and that and the backtrace:
(gdb) run fjf1044s.pas -g -O3 -W Starting program: d:\src\mingw\gcc-3.2.3\build\gcc/gpc1.exe fjf1044s.pas -g -O3 -W gdb: do_initial_child_stuff: process 3296 gdb: kernel event for pid=3296 tid=3956 code=CREATE_PROCESS_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 3296.0xf74 ContinueDebugEvent (cpid=3296, ctid=3956, DBG_CONTINUE); gdb: kernel event for pid=3296 tid=3956 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 3296.0xf74 ContinueDebugEvent (cpid=3296, ctid=3956, DBG_CONTINUE); gdb: kernel event for pid=3296 tid=3956 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 3296.0xf74 ContinueDebugEvent (cpid=3296, ctid=3956, DBG_CONTINUE); gdb: kernel event for pid=3296 tid=3956 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 3296.0xf74 ContinueDebugEvent (cpid=3296, ctid=3956, DBG_CONTINUE); gdb: kernel event for pid=3296 tid=3956 code=EXCEPTION_DEBUG_EVENT) gdb: Target exception EXCEPTION_BREAKPOINT at 0x7c901230 q1 q2 q3 q4 q5 pgdb: child_resume.SetThreadContext: thread 3296.0xf74 ContinueDebugEvent (cpid=3296, ctid=3956, DBG_CONTINUE); gdb: kernel event for pid=3296 tid=3956 code=EXCEPTION_DEBUG_EVENT) (gdb) #14 0x004e013c in main (argc=5, argv=0x3d40a8) at ../../gcc/main.c:35 gdb: Target exception EXCEPTION_BREAKPOINT at 0x004de444
Breakpoint 1, fancy_abort (file=0x7484ec "../../gcc/calls.c", line=3078, function=0x7485f1 "expand_call") at ../../gcc/diagnostic.c:1452 1452 internal_error ("Internal compiler error in %s, at %s:%d", (gdb) bt #0 fancy_abort (file=0x7484ec "../../gcc/calls.c", line=3078, function=0x7485f1 "expand_call") at ../../gcc/diagnostic.c:1452 During symbol reading, struct/union type gets multiply defined: struct rtx_def. During symbol reading, struct/union type gets multiply defined: struct rtvec_def. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, forward-referenced types left unresolved, type code 0.. During symbol reading, struct/union type gets multiply defined: struct function. During symbol reading, struct/union type gets multiply defined: struct function. #1 0x00587b97 in expand_call (exp=0xc41cc0, target=0x0, ignore=1) at ../../gcc/calls.c:3078 #2 0x00479a00 in expand_expr (exp=0xc41cc0, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL) at ../../gcc/expr.c:7379 During symbol reading, struct/union type gets multiply defined: struct basic_block_def. #3 0x004c4b86 in expand_expr_stmt_value (exp=0xc41cc0, want_value=0, maybe_last=1) at ../../gcc/stmt.c:2254 #4 0x004c4a49 in expand_expr_stmt (exp=0xc41cc0) at ../../gcc/stmt.c:2208 #5 0x0044c15e in expand_call_statement (t=0xc41cc0) at ../../gcc/p/statements.c:1101 #6 0x00409468 in yyuserAction (yyn=395, yyrhslen=1, yyvsp=0xc25bd8, yyvalp=0x22fd44, yylocp=0x22fd20, yystack=0x22fdc0) at parse.y:1386 #7 0x004114d0 in yydoAction (yystack=0x22fdc0, yyk=0, yyrule=395, yyvalp=0x22fd44, yylocp=0x22fd20) at parse.c:7795 #8 0x00410fc3 in yyglrReduce (yystack=0x22fdc0, yyk=0, yyrule=395, yyforceEval=1 '\001') at parse.c:7867 #9 0x0041236a in main_yyparse () at parse.c:8591 #10 0x00412e9e in yyparse () at parse.y:2373 #11 0x004b4fe2 in compile_file () at ../../gcc/toplev.c:2124 #12 0x004b9f04 in do_compile () at ../../gcc/toplev.c:5218 #13 0x004b9f6a in toplev_main (argc=5, argv=0x3d40a8) at ../../gcc/toplev.c:5250 #14 0x004e013c in main (argc=5, argv=0x3d40a8) at ../../gcc/main.c:35
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 24 Apr 2005 at 0:22, Frank Heckenbach wrote:
[...]
Type `bt' in gdb.
While or after running what?
As previously:
: > > Can you post a complete traceback or at least error position? (There are : > > many strncmp's in gpc.c, and know which one it is might help.) : > : > Attached ... : > (Mingw)/src/mingw/gcc-3.2.3/build/gcc $gdb xgpc.exe : > GNU gdb 6.3 : > (gdb) run : <snip> : > Program received signal SIGSEGV, Segmentation fault. : > 0x77c47a64 in strncmp () : > (gdb) info line *0x77c47a64 : > No line number information available for address 0x77c47a64 <strncmp+20> : : can you type `bt' here (to get the calling place)?
IIRC, what I ran then was xgpc with no arguments (xgpc was crashing). That doesn't work here. Eventually, what I did was to load gpc1.exe into gdb and to do "run fjf1044s.pas -g -O3 -W". This is the output and that and the backtrace:
#1 0x00587b97 in expand_call (exp=0xc41cc0, target=0x0, ignore=1) at ../../gcc/calls.c:3078 #2 0x00479a00 in expand_expr (exp=0xc41cc0, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL) at ../../gcc/expr.c:7379 #3 0x004c4b86 in expand_expr_stmt_value (exp=0xc41cc0, want_value=0, maybe_last=1) at ../../gcc/stmt.c:2254 #4 0x004c4a49 in expand_expr_stmt (exp=0xc41cc0) at ../../gcc/stmt.c:2208
Sorry, which backend version are you using here? Your original report was about 3.3.5, but these line numbers match 3.2.3.
If it's with 3.2.3, you could try an updated backend diff (attached -- you'll have to rebuild GPC), though it didn't make a difference for me (I don't get the error on Linux with or without it).
If this doesn't help, I'm not sure the problem is important enough to spend much time one. It seems a rare case, and perhaps it will vanish with a newer backend version (after integration of the preprocessor).
Frank
On 25 Apr 2005 at 2:37, Frank Heckenbach wrote:
[...]
#1 0x00587b97 in expand_call (exp=0xc41cc0, target=0x0, ignore=1) at ../../gcc/calls.c:3078 #2 0x00479a00 in expand_expr (exp=0xc41cc0, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL) at ../../gcc/expr.c:7379 #3 0x004c4b86 in expand_expr_stmt_value (exp=0xc41cc0, #want_value=0, maybe_last=1) at ../../gcc/stmt.c:2254 #4 0x004c4a49 in expand_expr_stmt (exp=0xc41cc0) at ../../gcc/stmt.c:2208
Sorry, which backend version are you using here? Your original report was about 3.3.5, but these line numbers match 3.2.3.
I have reverted to 3.2.3, where the problem also exists.
If it's with 3.2.3, you could try an updated backend diff (attached -- you'll have to rebuild GPC), though it didn't make a difference for me (I don't get the error on Linux with or without it).
Will try it and report back ...
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.greatchief.plus.com/
On 25 Apr 2005 at 2:37, Frank Heckenbach wrote:
[....]
Sorry, which backend version are you using here? Your original report was about 3.3.5, but these line numbers match 3.2.3.
If it's with 3.2.3, you could try an updated backend diff (attached --
Zillions of failed hunks. See log below: (Mingw)/src/mingw/gcc-3.2.3/gcc $patch -p1 < /src/mingw/gcc-3.2.3.diff patching file `config/i386/i386.c' Hunk #1 succeeded at 1863 (offset 26 lines). patching file `config/s390/s390.h' patching file `config/s390/s390.md' patching file `dbxout.c' Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 FAILED at 1372. Hunk #2 FAILED at 1394. 2 out of 2 hunks FAILED -- saving rejects to dbxout.c.rej patching file `dwarf2out.c' Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 FAILED at 8077. Hunk #2 succeeded at 8270 with fuzz 2 (offset 12 lines). Hunk #3 FAILED at 8288. Hunk #4 succeeded at 9068 with fuzz 1 (offset 759 lines). 2 out of 4 hunks FAILED -- saving rejects to dwarf2out.c.rej patching file `emit-rtl.c' patching file `expr.c' Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 succeeded at 22 with fuzz 2 (offset 3 lines). Hunk #2 FAILED at 4861. Hunk #3 FAILED at 4898. Hunk #4 FAILED at 4913. Hunk #5 succeeded at 4954 (offset 29 lines). Hunk #6 succeeded at 4952 (offset 3 lines). Hunk #7 succeeded at 4992 (offset 29 lines). Hunk #8 FAILED at 5016. Hunk #9 FAILED at 5413. 5 out of 9 hunks FAILED -- saving rejects to expr.c.rej patching file `fold-const.c' Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 succeeded at 22 with fuzz 2 (offset 3 lines). Hunk #2 succeeded at 242 with fuzz 2 (offset 11 lines). Hunk #3 succeeded at 271 with fuzz 2 (offset 7 lines). Hunk #4 FAILED at 1714. 1 out of 4 hunks FAILED -- saving rejects to fold-const.c.rej patching file `function.c' Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 succeeded at 40 with fuzz 2 (offset 2 lines). Hunk #2 FAILED at 316. Hunk #3 FAILED at 5497. Hunk #4 FAILED at 5516. 3 out of 4 hunks FAILED -- saving rejects to function.c.rej patching file `gcc.c' Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 FAILED at 708. 1 out of 1 hunk FAILED -- saving rejects to gcc.c.rej patching file `integrate.c' Hunk #2 succeeded at 1341 with fuzz 2. patching file `recog.h' patching file `rtl.h' patching file `stmt.c' patching file `stor-layout.c' Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 succeeded at 22 with fuzz 2 (offset 2 lines). Hunk #2 FAILED at 60. Hunk #3 FAILED at 1571. Hunk #4 FAILED at 1687. Hunk #5 FAILED at 1706. 4 out of 5 hunks FAILED -- saving rejects to stor-layout.c.rej patching file `system.h' Hunk #1 succeeded at 34 with fuzz 2 (offset 6 lines). patching file `tree.c' Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 succeeded at 21 with fuzz 2 (offset 2 lines). Hunk #2 FAILED at 3841. Hunk #3 succeeded at 4754 with fuzz 2 (offset 11 lines). Hunk #4 FAILED at 4783. Hunk #5 FAILED at 4797. Hunk #6 FAILED at 4818. Hunk #7 FAILED at 4835. Hunk #8 FAILED at 4863. 6 out of 8 hunks FAILED -- saving rejects to tree.c.rej patching file `tree.def' Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 FAILED at 21. Hunk #2 FAILED at 512. Hunk #3 FAILED at 537. 3 out of 3 hunks FAILED -- saving rejects to tree.def.rej patching file `tree.h' Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 succeeded at 22 with fuzz 2 (offset 3 lines). Hunk #3 FAILED at 2498. 1 out of 3 hunks FAILED -- saving rejects to tree.h.rej patching file `varasm.c' Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] y Hunk #1 FAILED at 3171. Hunk #2 FAILED at 4395. 2 out of 2 hunks FAILED -- saving rejects to varasm.c.rej
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 25 Apr 2005 at 2:37, Frank Heckenbach wrote:
[....]
Sorry, which backend version are you using here? Your original report was about 3.3.5, but these line numbers match 3.2.3.
If it's with 3.2.3, you could try an updated backend diff (attached --
Zillions of failed hunks. See log below:
Please start with a fresh copy of 3.2.3 (not one with the previous GPC patch already applied, which is contained in the new one). But if it's too much work for you now, don't work. Just retry it with a future backend version (when the preprocessor has been integrated etc.) sometime. As I wrote, it doesn't seem very important now.
Frank
On 26 Apr 2005 at 4:40, Frank Heckenbach wrote:
[...]
Zillions of failed hunks. See log below:
Please start with a fresh copy of 3.2.3 (not one with the previous GPC patch already applied, which is contained in the new one). But if it's too much work for you now, don't work. Just retry it with a future backend version (when the preprocessor has been integrated etc.) sometime. As I wrote, it doesn't seem very important now.
I think we probably should leave it for now.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Hi,
is the WWW server working? All my attempts since Friday to connect to www.gnu-pascal.de were timed-out after several minutes of no progress. (Traceroute does not get past 132.252.254.251, nevertheless I can ping the server.)
Emil Jerabek
Hi group,
On Apr 2, 2005, at 16:39, Emil Jerabek wrote:
Hi,
is the WWW server working? All my attempts since Friday to connect to www.gnu-pascal.de were timed-out after several minutes of no progress. (Traceroute does not get past 132.252.254.251, nevertheless I can ping the server.)
Emil Jerabek
I see same problem.
The HTTP request are timing out. The ping on www.gnu-pascal.de (132.252.79.79) is OK.
Jan Ruzicka
PS: DNS answer: www.gnu-pascal.de. 604800 IN CNAME tartaglia.dida.physik.uni-essen.de. tartaglia.dida.physik.uni-essen.de. 86400 IN A 132.252.79.79
On Sun, 3 Apr 2005 jan.ruzicka@comcast.net wrote:
Hi group,
On Apr 2, 2005, at 16:39, Emil Jerabek wrote:
Hi,
is the WWW server working? All my attempts since Friday to connect to www.gnu-pascal.de were timed-out after several minutes of no progress. (Traceroute does not get past 132.252.254.251, nevertheless I can ping the server.)
Emil Jerabek
I see same problem.
"whois" reports:
[..] % "www.gnu-pascal.de" is not a valid domain name
Did the registration expire and someone overlooked renewing it?
Russ
On Apr 4, 2005, at 00:51, Russell Whitaker wrote:
On Sun, 3 Apr 2005 jan.ruzicka@comcast.net wrote:
Hi group,
On Apr 2, 2005, at 16:39, Emil Jerabek wrote:
Hi, is the WWW server working? All my attempts since Friday to connect to www.gnu-pascal.de were timed-out after several minutes of no progress. (Traceroute does not get past 132.252.254.251, nevertheless I can ping the server.) Emil Jerabek
I see same problem.
"whois" reports:
[..] % "www.gnu-pascal.de" is not a valid domain name
Did the registration expire and someone overlooked renewing it?
Russ
Which server are you connecting to? The whois.ripe.net returns: ------------------------------------------ % This is the RIPE Whois query server #2. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html
% The object shown below is NOT in the RIPE database. % It has been obtained by querying a remote server: % (whois.denic.de) at port 43. % To see the object stored in the RIPE database % use the -R flag in your query % %REFERRAL START domain: gnu-pascal.de status: connect
%%REFERRAL END -------------- and ---------------------------- %REFERRAL START domain: www.gnu-pascal.de status: invalid %%REFERRAL END ------------------------------------------ Jan
On Mon, 4 Apr 2005 jan.ruzicka@comcast.net wrote:
On Apr 4, 2005, at 00:51, Russell Whitaker wrote:
On Sun, 3 Apr 2005 jan.ruzicka@comcast.net wrote:
Hi group,
On Apr 2, 2005, at 16:39, Emil Jerabek wrote:
Hi, is the WWW server working? All my attempts since Friday to connect to www.gnu-pascal.de were timed-out after several minutes of no progress. (Traceroute does not get past 132.252.254.251, nevertheless I can ping the server.) Emil Jerabek
I see same problem.
"whois" reports:
[..] % "www.gnu-pascal.de" is not a valid domain name
Did the registration expire and someone overlooked renewing it?
Russ
Which server are you connecting to? The whois.ripe.net returns:
% This is the RIPE Whois query server #2. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html
% The object shown below is NOT in the RIPE database. % It has been obtained by querying a remote server: % (whois.denic.de) at port 43. % To see the object stored in the RIPE database % use the -R flag in your query % %REFERRAL START domain: gnu-pascal.de status: connect
%%REFERRAL END -------------- and ---------------------------- %REFERRAL START domain: www.gnu-pascal.de status: invalid %%REFERRAL END
The results, in full: for whois www.gnu-pascal.de % Copyright (c)2004 by DENIC % Version: 1.00.0 % % Restricted rights. % % % Except for agreed Internet operational purposes, no part of this % information may be reproduced, stored in a retrieval system, or % transmitted, in any form or by any means, electronic, mechanical, % recording, or otherwise, without prior permission of the DENIC % on behalf of itself and/or the copyright holders. Any use of this % material to target advertising or similar activities are explicitly % forbidden and will be prosecuted. The DENIC requests to be notified % of any such activities or suspicions thereof.
% "www.gnu-pascal.de" is not a valid domain name
and for whois gnu-pascal % Copyright (c)2004 by DENIC % Version: 1.00.0 % % Restricted rights. % % % Except for agreed Internet operational purposes, no part of this % information may be reproduced, stored in a retrieval system, or % transmitted, in any form or by any means, electronic, mechanical, % recording, or otherwise, without prior permission of the DENIC % on behalf of itself and/or the copyright holders. Any use of this % material to target advertising or similar activities are explicitly % forbidden and will be prosecuted. The DENIC requests to be notified % of any such activities or suspicions thereof.
domain: gnu-pascal.de domain-ace: gnu-pascal.de descr: Peter Gerwinski descr: Gerlachfeld 13 descr: D-45279 Essen nserver: ngc224.gerwinski.de nserver: ns2.afraid.org status: connect changed: 2005-02-11T19:06:28+0100 source: DENIC
[admin-c][tech-c][zone-c] Type: PERSON Name: Peter Gerwinski Address: Gerlachfeld 13 City: Essen Pcode: 45279 Country: DE Phone: +49201751176 Fax: +49201755440 Email: peter@gerwinski.de Changed: 2004-09-18T00:36:08+0200 Source: DENIC
And that's all I know. Russ
Russell Whitaker wrote:
"whois" reports:
[..] % "www.gnu-pascal.de" is not a valid domain name
(www.gnu-pascal.de is a machine name, the domain is gnu-pascal.de)
Eike Lange, the owner of the server, now told me that apparently the hard disk broke down. :-(
Of course, that's not entirely unusual for a heavily loaded server, and the good news is at least that it wasn't an attack (again).
I hope we can get new hardware running soon.
The other good news is that I made a complete backup less than two weeks ago, so only the last alpha version will need to be added again (plus what other contributors may have uploaded since then).
Frank
-
Emil Jerabek -
Frank Heckenbach -
Frank Heckenbach -
James A. Morrison -
jan.ruzicka＠comcast.net -
Prof A Olowofoyeku (The African Chief) -
Prof. A Olowofoyeku (The African Chief)
-
Russell Whitaker -
Waldek Hebisch