David wrote
In fact, that's precisely what happened to the guys at Weka
before, although I'm certain they are not alone with this. They
encountered ICEs when updating the compiler version with no way
to narrow it down. Of course, *I* could just build DMD with
symbols and have a look at what was going on in GDB, but that's
the luxury of being a compiler dev.
Walter Bright wrote:
I do that often. Binary search quickly reduces even the biggest
code size. Manually, or using dustmite which works amazingly
well.
You can even compile with -v and which will give approximately
where in the test case it failed, which makes the initial
paring down of source code even faster.
They can create bug reports to help other people to do so,
though.
The bug report I need is the assert location, and a test case
that causes it. Users do not need to supply any other
information.
I do appreciate, however, when one of our team takes the time
to look at such a bug report and makes the effort to narrow
things down, and even propose solutions. But this is not
expected of users, and the file/line of the assert is
self-explanatory to the compiler dev looking at it (at least as
self-explanatory as a message like "variable x was not 3 like
it was expected to be".)
A good compromise would be to ship a debug version of dmd, with
most of the printf active, and ship also the log of the
compilation with the bug report...
/P
