Re: Linux and Windows generate different binaries
On Sat, 15 Jul 2017, Segher Boessenkool wrote: > Would it hurt us to use stable sorts *everywhere*? Stability (using the usual definition: keeping the original order of elements that compare equal) is not required to achieve reproducibility [*]. GCC could import or nih any non-randomized implementation of a [potentially not stable, e.g. qsort] sorting routine, and that would be sufficient to eliminate this source of codegen differences. Alexander [*] nor would it be sufficient, given our current practice of passing invalid comparators to libc sort, at which point anything can happen due to undefined behavior
Re: Getting spurious FAILS in testsuite?
Hi Bernd,
On Fri, Jul 14, 2017 at 4:36 PM, Bernd Edlinger
wrote:
> On 07/14/17 13:03, Georg-Johann Lay wrote:
>> On 13.07.2017 18:47, Bernd Edlinger wrote:
>>> On 07/13/17 16:31, Georg-Johann Lay wrote:
On 12.07.2017 15:40, Bernd Edlinger wrote:
> On 07/11/17 22:28, Bernd Edlinger wrote:
>> On 07/11/17 21:42, Andrew Pinski wrote:
>>> On Tue, Jul 11, 2017 at 12:31 PM, Andrew Pinski
>>> wrote:
On Tue, Jul 11, 2017 at 12:27 PM, Andrew Pinski
wrote:
> On Tue, Jul 11, 2017 at 12:15 PM, Bernd Edlinger
> wrote:
>> Hi,
>>
>> I see this now as well on Ubuntu 16.04, but I doubt that the
>> Kernel is
>> to blame.
>
> I don't see these failures when I use a 4.11 kernel. Only with a
> 4.4 kernel.
> Also the guality testsuite does not run at all with a 4.4
> kernel, it
> does run when using a 4.11 kernel; I suspect this is the same
> symptom
> of the bug.
4.11 kernel results (with CentOS 7.4 glibc):
https://gcc.gnu.org/ml/gcc-testresults/2017-07/msg00998.html
4.4 kernel results (with ubuntu 1604 glibc):
https://gcc.gnu.org/ml/gcc-testresults/2017-07/msg01009.html
Note the glibc does not matter here as I get a similar testsuite
results as the CentOS 7.4 glibc using the Ubuntu 1604 glibc but with
the 4.11 kernel.
Also note I get a similar results with a plain 4.11 kernel
compared to
the above kernel.
>>>
>>>
>>> Maybe commit 6a7e6f78c235975cc14d4e141fa088afffe7062c or
>>> 0f40fbbcc34e093255a2b2d70b6b0fb48c3f39aa to the kernel fixes both
>>> issues.
>>>
>>
>> As Georg-Johann points out here:
>> https://gcc.gnu.org/ml/gcc/2017-07/msg00028.html
>> updating the kernel alone does not fix the issue.
>>
>> These patches do all circle around pty and tty devices,
>> but in the strace file I see a pipe(2) command
>> creating the fileno 10 and the sequence of events is
>> as follows:
>>
>> pipe([7, 10]) = 0 (not in my previous e-mail)
>> clone() = 16141
>> clone() = 16142
>> write(4, "spawn: returns {0}\r\n", 20) = 20
>> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=16141,
>> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=16142,
>> read(10,...,4096) = 4096
>> read(10,...,4096) = 2144
>> read(10, "", 4096) = 0
>> close(10) = 0
>> wait4(16141, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 16141
>> wait4(16142, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 16142
>>
>> All data arrive at the expect process, but apparently too quickly.
>>
>>
>> Thanks
>> Bernd.
>
>
>
> Oh, I think the true reason is this patch:
> Author: Upstream
> Description: Report and fix both by Nils Carlson.
> Replaced a cc==0 check with proper Tcl_Eof() check.
> Last-Modified: Fri, 23 Oct 2015 11:09:07 +0300
> Bug: http://sourceforge.net/p/expect/patches/18/
> Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799301
>
> --- a/expect.c
> +++ b/expect.c
> @@ -1860,19 +1860,11 @@
> if (cc == EXP_DATA_NEW) {
> /* try to read it */
> cc = expIRead(interp,esPtr,timeout,tcl_set_flags);
> -
> -/* the meaning of 0 from i_read means eof. Muck with it a */
> -/* little, so that from now on it means "no new data arrived */
> -/* but it should be looked at again anyway". */
> -if (cc == 0) {
> +
> +if (Tcl_Eof(esPtr->channel)) {
> cc = EXP_EOF;
> -} else if (cc > 0) {
> -/* successfully read data */
> -} else {
> -/* failed to read data - some sort of error was encountered
> such as
> - * an interrupt with that forced an error return
> - */
> }
> +
> } else if (cc == EXP_DATA_OLD) {
> cc = 0;
> } else if (cc == EXP_RECONFIGURE) {
>
>
> The correct way to fix this would be something like this:
>
>if (cc == 0 && Tcl_Eof(esPtr->channel)) {
>cc = EXP_EOF;
>}
>
> What happens for me is cc > 0 AND Tcl_Eof at the same time.
> That makes dejagnu ignore the last few lines, because it does
> not expect EOF and data at the same time.
>
> Apparently tcl starts to read ahead because the default match
> buffer size is unreasonably small like 2000 bytes.
>
> I can work around it by increasing the buffer size like this:
>
> ndex: gcc/testsuite/lib/gcc-dg.exp
> ===
> --- gcc/testsuite/lib/gcc-dg.exp(revision 250150)
> +++ gcc/testsuite/lib/gcc-dg.exp(working c
Re: Linux and Windows generate different binaries
On Sun, Jul 16, 2017 at 12:38:58PM +0300, Alexander Monakov wrote: > On Sat, 15 Jul 2017, Segher Boessenkool wrote: > > Would it hurt us to use stable sorts *everywhere*? > > Stability (using the usual definition: keeping the original order of > elements that compare equal) is not required to achieve reproducibility [*]. I am well aware, and that is not what I asked. If we would use stable sorts everywhere we would not have to think about whether some sorting routine has to be stable or if we can get away with a (slightly slower) non-stable sort. > [*] nor would it be sufficient, given our current practice of passing > invalid comparators to libc sort, at which point anything can happen > due to undefined behavior That is just a plain bug, undefined behaviour even (C11 7.22.5/4). Of course it needs to be fixed. Segher
Re: Linux and Windows generate different binaries
On Sun, 16 Jul 2017, Segher Boessenkool wrote: > I am well aware, and that is not what I asked. If we would use stable > sorts everywhere How? There's no stable sort in libc and switching over to std::stable_sort would be problematic. The obvious approach is adding an implementation of a stable sort in GCC, but at that point it doesn't matter if it's stable, the fact it's deterministic is sufficient for reproducibility. > we would not have to think about whether some sorting routine has to be > stable or if we can get away with a (slightly slower) non-stable sort. I think you mean '(slightly faster)'. > That is just a plain bug, undefined behaviour even (C11 7.22.5/4). > Of course it needs to be fixed. I've posted patches towards this goal. Alexander
Re: Linux and Windows generate different binaries
On Sun, Jul 16, 2017 at 11:54:43PM +0300, Alexander Monakov wrote: > On Sun, 16 Jul 2017, Segher Boessenkool wrote: > > I am well aware, and that is not what I asked. If we would use stable > > sorts everywhere > > How? There's no stable sort in libc and switching over to std::stable_sort > would be problematic. Why? > The obvious approach is adding an implementation of > a stable sort in GCC, but at that point it doesn't matter if it's stable, > the fact it's deterministic is sufficient for reproducibility. Sure. Some of our sorts in fact require stable sort though, so if we do not use that everywhere people will still have to decide whether it is required in a specific case or not. > > we would not have to think about whether some sorting routine has to be > > stable or if we can get away with a (slightly slower) non-stable sort. > > I think you mean '(slightly faster)'. Yes I do, whoops :-) > > That is just a plain bug, undefined behaviour even (C11 7.22.5/4). > > Of course it needs to be fixed. > > I've posted patches towards this goal. Thanks! Segher
gcc-8-20170716 is now available
Snapshot gcc-8-20170716 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20170716/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 250247 You'll find: gcc-8-20170716.tar.xzComplete GCC SHA256=7ba581df06a4a166f6cd675afbd360a0d41a0757cfdfffb3099983ef42af3fcb SHA1=c65eb8e46043d2f28f4b2ae4ef3d366a068545cd Diffs from 8-20170709 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Linux and Windows generate different binaries
On Sun, 2017-07-16 at 17:32 -0500, Segher Boessenkool wrote: > On Sun, Jul 16, 2017 at 11:54:43PM +0300, Alexander Monakov wrote: > > > > On Sun, 16 Jul 2017, Segher Boessenkool wrote: > > > > > > I am well aware, and that is not what I asked. If we would use > > > stable sorts everywhere > > How? There's no stable sort in libc and switching over to > > std::stable_sort would be problematic. > Why? Actually GCC has been carrying around its very own implementation of sort algorithms in libstdc++. It's just not being used for the compiler itself. Because before GCC was compiled as C, using them was impossible. But now that it's compiled as C++, why not just use the algos from GCC's libstdc++? Cheers, Oleg
