libs/csengine/basic/polyset.cpp:46: Internal compiler error 191.

Philipp Thomas
Thu Jun 10 16:01:00 GMT 1999

[Just a short explanation: I already had started an exchange with Alexandre on
how to get to a good gccbug script to minimize those bug postings that are
useless because the user either can't read or because he completely ignored
gcc's message.

As Alexandre stated that in his opinion we should have started the discussion
on the list right away and I agree, I'm reposting this mail to egcs]

On 10 Jun 1999 15:18:10 -0300, you wrote:

>That's exactly why I'm suggesting a wrapper script.  It would have to
>get all the options passed to gcc, and it would even test whether the
>compilation really failed.

Well this gets complicated. Following your scenario, the script would have to

  - check for a Makefile, ask the user if this is the correct one to call
    (it could be a sub level makefile that can only be called by the toplevel
  - call make
  - capture the output
  - find the failing gcc call
  - parse the gcc call for all options
  - filter out any -o or -pipe option
  - do the call
  - record gcc's error messages
  - compress the preprocessed source
  - do mime64 or uuencoding
  - generate the message with all the info and attach the source
  - mail that to egcs-bugs.

What do we do on BSD systems where no makefile needs to be present (i.e. using
system default makefiles) ? I guess in that case the script could only ask if
it should run make.

What if the user want's to report (in his opinion) false warnings ?

Seems that a script like that needs a shell wizard to write which I'm most
definitely not. Otherwise I would try to come up with something that could at
least serve as a starting point.

Given that Nathan is setting up a gnats site for testing and given that we all
agree that we definitely need some kind of bug tracking system, it seems we
have to think about a proper gccbug script.
I'd suggest we hash out the ideas a bit and then go to the list to (hopefully)
get others interested. Good idea ?

>If the user will have to figure out the compilation command to get the
>preprocessed source, he could certainly figure it out to run gccbug on

That's what I thought ;) And it would be *much* easier to implement :)

>> I can't think of a portable way to do mime (but I admit I've never
>> dealt with questions like that before). So I think uuencode would be
>> the simplest solution.
>But not as convenient :-(

I *knew* that answer would come (it would have been mine too) :-)

>We could generate MIME base64 on our own; it's not that hard, and
>there must be some perl package to do it already :-)

I guess so, but I don't know of any. I guess you don't have any hints at hand,
do you ?

>And then, we could run sendmail to deliver the message, or connect to
>the smtp server directly, or, if everything else
>fails, just create a file that the user should feed to `sendmail

Much too much hassle. I'd say lets store the file, ask the user if this should
be sent directly (could be a Windows system with no directly callable mailer)
, call mail to send it otherwise store it where the user wants it to be.

That way you don't have to bother what mailer the user actually uses and you
don't have to do direct mail transfer.


You have moved your mouse. Windows must be rebooted for the
changes to take effect.

More information about the Gcc mailing list