From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout3.netcologne.de (cc-smtpout3.netcologne.de [IPv6:2001:4dd0:100:1062:25:2:0:3]) by sourceware.org (Postfix) with ESMTPS id BB5403858C53; Mon, 20 Mar 2023 07:14:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BB5403858C53 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=netcologne.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=netcologne.de Received: from cc-smtpin3.netcologne.de (cc-smtpin3.netcologne.de [89.1.8.203]) by cc-smtpout3.netcologne.de (Postfix) with ESMTP id 50A6E1232B; Mon, 20 Mar 2023 08:14:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1679296492; bh=1JULfDTG+s/VgalMrO6bNRiIB3zSzE6QBnImGVdx7ho=; h=Message-ID:Date:From:Subject:To:Cc:References:In-Reply-To:From; b=SXq+XYvZHKyzGgeub4fDdkFgPafiUjhOe6h8POTl7Hk7leZTUzvmcCw+PbPTV+TAR aV2iOVMbiujDPAnxGX6v464blTGs3S9pdH6lEt8FgzWOkf6H/TpszKUK+Z6275vePe e0ks7VkbVA7QEsmUHa2P30iWAQa4sUZysBFRMDFLoIXZKVgzK/QSYZ8E6mdRyyKpbY 8UfDaco8oqZOes+s6aRY6A4ednUJnpXLiYiVEIEDcHHWfJ9ZGKzYSJUc5e0EK/24aj Gk/dD0Kj0KsQb7sRLj5HPkHVr+k8Jmo1Shq2s9fsvUy8oIzdWXzukiNmt/NBRfkFRn EblzTB2CbPZpg== Received: from [IPV6:2001:4dd6:4ac:0:7285:c2ff:fe6c:992d] (2001-4dd6-4ac-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de [IPv6:2001:4dd6:4ac:0:7285:c2ff:fe6c:992d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin3.netcologne.de (Postfix) with ESMTPSA id 0E2EE11EBC; Mon, 20 Mar 2023 08:14:48 +0100 (CET) Message-ID: <83ed6780-22ac-bb57-d80c-c4d3a2c6b773@netcologne.de> Date: Mon, 20 Mar 2023 08:14:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 From: Thomas Koenig Subject: Re: [patch, fortran, doc] Explicitly mention undefined overflow To: Paul Richard Thomas Cc: "fortran@gcc.gnu.org" , gcc-patches References: <80e8f406-3e2c-3871-d225-0a74a620c6f6@netcologne.de> Content-Language: en-US In-Reply-To: <80e8f406-3e2c-3871-d225-0a74a620c6f6@netcologne.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-NetCologne-Spam: L X-Spamd-Bar: - X-Rspamd-Action: no action X-Rspamd-Queue-Id: 0E2EE11EBC X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: I wrote: > >> Yes, that's fine for trunk. I wonder if it is worth being explicit that >> linear congruential pseudo-random number generators can and do fail at >> -O3? > > I don't think we should put this into the docs, because that can change > at any time.  Maybe into porting_to.html, though (where I have only > mentioned this as a general issue with linear congruential generators, > without mentioning specific options. Current text can be seen at > https://gcc.gnu.org/gcc-13/porting_to.html ). > > Hm.... Breaking things actually goes back further than I thought. Taking the random number generator from rnseed and running it 10 times with my system gfortran 9.4.0 gets me, at different levels of optimization: $ for a in -O0 -O1 -O2; do echo $a; gfortran $a genuni.f90 && ./a.out; done -O0 0.269411892 0.891386986 0.444042951 0.779210865 0.500058949 0.666437685 0.666963458 0.462416053 0.376364112 2.90278494E-02 -O1 0.269411892 0.891386986 0.444042951 0.779210865 0.500058949 0.666437685 0.666963458 0.462416053 0.376364112 2.90278494E-02 -O2 -0.730588138 0.891386986 -0.555957019 -0.220789105 -0.499941051 0.666437685 -0.333036542 0.462416053 0.376364112 2.90278494E-02 and for current trunk it is $ for a in -O0 -O1 -O2; do echo $a; gfortran $a genuni.f90 && ./a.out; done -O0 0.269411892 0.891386986 0.444042951 0.779210865 0.500058949 0.666437685 0.666963458 0.462416053 0.376364112 2.90278494E-02 -O1 0.269411892 0.891386986 0.444042951 0.779210865 0.500058949 0.666437685 0.666963458 0.462416053 0.376364112 2.90278494E-02 -O2 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 so it the general problem is not restricted to -O3 and not to current trunk, it depends on the details. I doubt that the result from 9.4.0 was expected, but rather nobody noticed. Or, bringing out the pseudo-RNG into a different setting changed things. So... any suggestions on how to improve the current wording? Best regards Thomas