This is the mail archive of the
mailing list for the GCC project.
Re: [RFC PATCH] Automatically check reproducability of ICE (ifpossible) and prepare testcase if reproducible
On Fri, 2004-01-23 at 21:26, Alexandre Oliva wrote:
> On Jan 23, 2004, "Zack Weinberg" <firstname.lastname@example.org> wrote:
> > I like the idea, but it needs to be generalized to handle languages
> > that don't have any concept of preprocessing (fortran, ada, java).
> *needs* to? You mean, as a requirement for the change to get in?
> Given that there's no way to create a single translation unit input
> file for such languages, this would probably put an indefinite block
> on this patch, and I think it would be nice to have it regardless of
> other languages.
While I agree with your position - no need to wait for other languages
to put a useful C/C++ feature such as the one you're proposing in,
I'd like to point out this feature is doable for Ada and in some way
already partially available for Ada when an ICE occurs:
+===========================GNAT BUG DETECTED==============================+
| 3.5.0 20040122 (experimental) (i686-pc-linux-gnu) GCC error: |
| in set_mem_alias_set, at emit-rtl.c:1778 |
| Error detected at c34005o.adb:138:35 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html. |
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
The last step would be for GCC to output the concatenated source file
then the gnatchop tool can be used to regenerate the individual files
in a clean directory and check again the failure.
(It still depends on predefined libraries though but that's
probably a solvable issue).
On your original proposal, I think it would be better for the driver
to output comments and the command to run multiple times - a special gcc
flag - to see if it's reproducible than to automatically run it three
times, in case of GCC using too much memory problems or other severe
problems it might not gain us friends amongst our users: when running
four times in a row an OOM process, who knows what the OS kernel will do