https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121690
--- Comment #12 from Torbjorn SVENSSON <azoff at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #11) > So here is what I think happens. the \n happens at the end of the buffer so > it is changed into \n\r into the buffer and then the next character from the > tty is \r. > > This sounds like an expect or a dejagnu bug handling of \n at the end of the > buffer rather than peeking to see if the next character was \r too. I would say that you are close to the truth here. I've been debugging this a bit more on the mac system and I've been able to create a small reproducer that can trigger this issue without DejaGNU or the GCC testsuite. I'm still not sure where the issue comes from, but it looks like the data read form the fd in ExpInputProc (exp_chan.c in expect) already contains the translated LF. Since the buffer only contains the CR, not the LF, it's not possible to do a simple peek at the next character, at least I've not found the spot where it could be done. I have one idea how to work around the problem in expect, but I will do the same kind of debug session on a Linux computer and compare the results, first. Lastly, @Iain, changing the buffer size does not help. I can reproduce it with your expect sources too. The good thing about my reproducer is that it's now happening 100% and no longer random, so a workaround should be easy to validate. I'll keep you updated on my findings after my debug session on a Linux system.
