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

On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright wrote:
> On 9/4/2016 10:56 AM, David Nadlinger wrote:
> 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.

So, if we assume the user cannot debug if he hit an compiler bug, I as a compiler developer would at least like to receive a report containing a simple number, to identify which of the 830 assert(0)'s in the code that I deemed to be unreachable was actually hit.

Because even if I don't receive a reduced testcase, I have a strong hint what assumption I should re-think, now that I know that it is effectively NOT unreachable.

Could we agree so far?

SO what problem would it be to give the assert(0)'s a number each and print out a message:
"Compiler bug: assert #xxx was hit, please send a bug report"
?

On Saturday, 3 September 2016 at 12:12:34 UTC, Walter Bright wrote:
> Except that asserts are checking for compiler bugs, not diagnostics on user code. I don't expect users to debug the compiler - if they get an assert they should file a bug report to bugzilla and let us debug the compiler and fix it.
>

I suggest these assert come with a message explaining this is a compiler bug, and a link to the bug tracker + useful infos to include in the bug report in order to lower the barrier to get a bug report and make it clear to the user that it isn't a problem in their code with a obtuse error message.

On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright wrote:
> On 9/4/2016 10:56 AM, David Nadlinger wrote:
>> This is short-sighted, for the reason I pointed out in my earlier post. How
>> would you go about reporting an ICE for a 100k LOC test case without any idea
>> about where to start looking?
>
> I do that often. Binary search quickly reduces even the biggest code size. Manually, or using dustmite which works amazingly well.
>

That is not true. I had dustmite runs that lasted days (!) to report some ICE in my code.

On Tuesday, 6 September 2016 at 05:43:55 UTC, deadalnix wrote:
> On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright wrote:
>> I do that often. Binary search quickly reduces even the biggest code size. Manually, or using dustmite which works amazingly well.
>>
>
> That is not true. I had dustmite runs that lasted days (!) to report some ICE in my code.

I know it's tempting, but the idea is to NOT stare at the screen watching DustMite run, and go do something else instead :)

If you have more cores than time, DustMite now has -j.

On Tuesday, 6 September 2016 at 05:46:51 UTC, Vladimir Panteleev wrote:
> On Tuesday, 6 September 2016 at 05:43:55 UTC, deadalnix wrote:
>> On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright wrote:
>>> I do that often. Binary search quickly reduces even the biggest code size. Manually, or using dustmite which works amazingly well.
>>>
>>
>> That is not true. I had dustmite runs that lasted days (!) to report some ICE in my code.
>
> I know it's tempting, but the idea is to NOT stare at the screen watching DustMite run, and go do something else instead :)
>
> If you have more cores than time, DustMite now has -j.

That's what I did. Launched it on a server and waited for it to finish.

On Monday, 5 September 2016 at 15:55:16 UTC, Dominikus Dittes Scherkl wrote:
> On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright wrote:
>> On 9/4/2016 10:56 AM, David Nadlinger wrote:
>> 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.
>
> So, if we assume the user cannot debug if he hit an compiler bug, I as a compiler developer would at least like to receive a report containing a simple number, to identify which of the 830 assert(0)'s in the code that I deemed to be unreachable was actually hit.
>
> Because even if I don't receive a reduced testcase, I have a strong hint what assumption I should re-think, now that I know that it is effectively NOT unreachable.
>
> Could we agree so far?
>
> SO what problem would it be to give the assert(0)'s a number each and print out a message:
> "Compiler bug: assert #xxx was hit, please send a bug report"
> ?

I wonder what people think of opt in automatic statistic collecting.  Not a substitute for a bug report, as one doesn't want source code being shipped off, but suppose a central server at dlang.org tracks internal compiler errors for those who have opted in. At least it will be more obvious more quickly which parts of code seem to be asserting.