Re: Different language frontends and fancy_abort()

Re: Different language frontends and fancy_abort()

[Richard Kenner]

We already have a facility for a front-end to produce its own ICE messages.
Ada has been using it for quite a while.

Re: Different language frontends and fancy_abort()

[Fergus Henderson]

On 07-Feb-2037, Richard Kenner, GNU C Maintainer <kenner@vlsi1.ultra.nyu.edu> wrote:
> We already have a facility for a front-end to produce its own ICE messages.
> Ada has been using it for quite a while.

I suppose you mean set_fatal_function() in diagnostic.c?

That doesn't solve the problem, because (*fatal_function)() is not
called in this case.  (*fatal_function)() is only called from
fatal(), not from abort(), fancy_abort(), or finish_abort().

Are you suggesting that I use the `fatal_function' hook
rather than adding a new `lang_handle_ICE' hook?

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: Different language frontends and fancy_abort()

[Richard Kenner]

    Surely when the Pascal front end is part of GCC, bug reports for it should
    go to the GCC GNATS database as with the rest of GCC (and GNATS can then
    send them - identified with category "pascal" - on to a separate
    pascal-bugs@gcc.gnu.org or similar list, if desired)?

That's a very different issue.  Even if the bugs go to the same place,
the information that a front can produce in explaining the location of the
bug can vary greatly.   The Ada front end takes advantage of this to list
the files that need to be included to reproduce the bug, for example.

Re: Different language frontends and fancy_abort()

[Joseph S. Myers]

On Tue, 2 Jan 2001, Peter Gerwinski wrote:

> I would prefer to have bug reports for the Pascal frontend directed
> to another address instead. A mechanism to modify that string would
> be nice here.

Surely when the Pascal front end is part of GCC, bug reports for it should
go to the GCC GNATS database as with the rest of GCC (and GNATS can then
send them - identified with category "pascal" - on to a separate
pascal-bugs@gcc.gnu.org or similar list, if desired)?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Different language frontends and fancy_abort()

[Richard Kenner]

    I suppose you mean set_fatal_function() in diagnostic.c?

Yes.

    That doesn't solve the problem, because (*fatal_function)() is not
    called in this case.  (*fatal_function)() is only called from
    fatal(), not from abort(), fancy_abort(), or finish_abort().

See this change:

    Sat Dec 16 10:41:11 2000  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>

	* diagnostic.c (finish_abort): Deleted.
	(fatal): Add code from finish_abort.
	(error_recursion, fancy_abort): Call fatal, not finish_abort.

    Are you suggesting that I use the `fatal_function' hook
    rather than adding a new `lang_handle_ICE' hook?

Yes.  That's what it's there for!

Re: Different language frontends and fancy_abort()

[Trevor Jenkins]

On Tue, 2 Jan 2001, Peter Gerwinski wrote:

> I would prefer to have bug reports for the Pascal frontend directed
> to another address instead. A mechanism to modify that string would
> be nice here.

You raise several issues that concern me. Firstly, that Pascal isn't a
standard component of gcc. A long hoped for objective. Will it ever
happen? Secondly, that there should multiple reporting mechanisms. In a
multi-lingual environment the user has to remember which (of many)
locations to go report the bug(s). Better to have a single point through
which people can report their findings. The back-end of the
trouble-ticketing system is where details of the ticket databases for
specific language front-ends should exist. This has the added benefit that
the front-end maintainers can change but the user is still presented with
a fixed address.

So rather than introducing an undesirable "surface" mechanism I'd prefer
to see effort expended upon completing Pascal's integration
into gcc and have the reporting system generalised.

Regards, Trevor

British Sign Language is not inarticulate handwaving; it's a living language.
Support the campaign for formal recognition by the British government now!

-- 

<>< Re: deemed!

Re: Different language frontends and fancy_abort()

[Fergus Henderson]

On 02-Jan-2001, Peter Gerwinski <peter@gerwinski.de> wrote:
> when a bug in the Pascal frontend triggers `fancy_abort()', GCC says:
> 
>     filename.pas:1375: Internal compiler error in foo, at bar.c:34
>     Please submit a full bug report.
>      See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
> 
> I would prefer to have bug reports for the Pascal frontend directed
> to another address instead. A mechanism to modify that string would
> be nice here.

I agree.  I want this for the Mercury front-end too.

Here's a patch.

----------

2001-01-02  Fergus Henderson  <fjh@cs.mu.oz.au>
 
 	* diagnostic.c (lang_handle_ICE): New.
 	(finish_abort): Call it.
 	* diagnostic.h (lang_handle_ICE): Declare it.
 
Index: diagnostic.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/diagnostic.c,v
retrieving revision 1.44
diff -u -d -c -p -r1.44 diagnostic.c
*** diagnostic.c	2000/11/17 06:05:14	1.44
--- diagnostic.c	2001/01/02 06:57:53
*************** extern int errorcount;
*** 115,120 ****
--- 115,124 ----
  /* Front-end specific tree formatter, if non-NULL.  */
  printer_fn lang_printer = NULL;
  
+ /* Front-end specific internal compiler error handler, if non-NULL.  */
+ void (*lang_handle_ICE) PARAMS ((void)) = NULL;
+ 
+ 
  /* This must be large enough to hold any printed integer or
     floating-point value.  */
  static char digit_buffer[128];
*************** finish_abort ()
*** 1687,1692 ****
--- 1691,1698 ----
  {
    if (errorcount > 1 || sorrycount > 0)
      fprintf (stderr, "confused by earlier errors, bailing out\n");
+   else if (lang_handle_ICE)
+     (*lang_handle_ICE) ();
    else
      fprintf (stderr, "\
  Please submit a full bug report.\n\
Index: diagnostic.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/diagnostic.h,v
retrieving revision 1.18
diff -u -d -c -p -r1.18 diagnostic.h
*** diagnostic.h	2000/11/15 15:50:49	1.18
--- diagnostic.h	2001/01/02 06:57:53
*************** extern printer_fn lang_printer;
*** 156,161 ****
--- 156,167 ----
  extern diagnostic_starter_fn lang_diagnostic_starter;
  extern diagnostic_finalizer_fn lang_diagnostic_finalizer;
  
+ /* If non-NULL, this variable contains a function to call
+    after an internal compiler error is encountered.
+    Normally the function should print a message to instruct
+    users on how to report bugs.  */
+ extern void (*lang_handle_ICE) PARAMS ((void));
+ 
  extern int diagnostic_message_length_per_line;
  
  /* This output buffer is used by front-ends that directly output
-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Different language frontends and fancy_abort()

[Peter Gerwinski]

Hello,

when a bug in the Pascal frontend triggers `fancy_abort()', GCC says:

    filename.pas:1375: Internal compiler error in foo, at bar.c:34
    Please submit a full bug report.
     See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.

I would prefer to have bug reports for the Pascal frontend directed
to another address instead. A mechanism to modify that string would
be nice here.

    Peter

PS: `foo' and `bar' above are metasyntactic variables, but the
    source file indeed reads `filename.pas'. :-)

-- 
http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-20010101
GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422
keys: http://www.gerwinski.de/pubkeys/ - AntiSpam: http://spam.abuse.net