[TCWG CI] Regression caused by newlib: README: configure.in -> configure.ac

[TCWG CI] Regression caused by newlib: README: configure.in -> configure.ac

[ci_notify]

[TCWG CI] Regression caused by newlib: README: configure.in -> configure.ac:
commit ff71c3fcdb9807fee8d9e5f898694ba56a02a013
Author: Jon Turney <jon.turney@dronecode.org.uk>

    README: configure.in -> configure.ac

Results regressed to
# reset_artifacts:
-10
# build_abe binutils:
-9
# build_abe stage1 -- --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard:
-8
# build_abe newlib:
-6
# build_abe stage2 -- --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard:
-5
# benchmark -- -Os_LTO_mthumb artifacts/build-ff71c3fcdb9807fee8d9e5f898694ba56a02a013/results_id:
1

from
# reset_artifacts:
-10
# build_abe binutils:
-9
# build_abe stage1 -- --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard:
-8
# build_abe newlib:
-6
# build_abe stage2 -- --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard:
-5
# benchmark -- -Os_LTO_mthumb artifacts/build-baseline/results_id:
1

THIS IS THE END OF INTERESTING STUFF.  BELOW ARE LINKS TO BUILDS, REPRODUCTION INSTRUCTIONS, AND THE RAW COMMIT.

This commit has regressed these CI configurations:
 - tcwg_bmk_gnu_eabi_stm32/gnu_eabi-master-arm_eabi-coremark-Os_LTO

First_bad build: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eabi-master-arm_eabi-coremark-Os_LTO/14/artifact/artifacts/build-ff71c3fcdb9807fee8d9e5f898694ba56a02a013/
Last_good build: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eabi-master-arm_eabi-coremark-Os_LTO/14/artifact/artifacts/build-90950758eb9f65227ef4ce8597ccc922959e25f6/
Baseline build: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eabi-master-arm_eabi-coremark-Os_LTO/14/artifact/artifacts/build-baseline/
Even more details: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eabi-master-arm_eabi-coremark-Os_LTO/14/artifact/artifacts/

Reproduce builds:
<cut>
mkdir investigate-newlib-ff71c3fcdb9807fee8d9e5f898694ba56a02a013
cd investigate-newlib-ff71c3fcdb9807fee8d9e5f898694ba56a02a013

# Fetch scripts
git clone https://git.linaro.org/toolchain/jenkins-scripts

# Fetch manifests and test.sh script
mkdir -p artifacts/manifests
curl -o artifacts/manifests/build-baseline.sh https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eabi-master-arm_eabi-coremark-Os_LTO/14/artifact/artifacts/manifests/build-baseline.sh --fail
curl -o artifacts/manifests/build-parameters.sh https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eabi-master-arm_eabi-coremark-Os_LTO/14/artifact/artifacts/manifests/build-parameters.sh --fail
curl -o artifacts/test.sh https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eabi-master-arm_eabi-coremark-Os_LTO/14/artifact/artifacts/test.sh --fail
chmod +x artifacts/test.sh

# Reproduce the baseline build (build all pre-requisites)
./jenkins-scripts/tcwg_bmk-build.sh @@ artifacts/manifests/build-baseline.sh

# Save baseline build state (which is then restored in artifacts/test.sh)
mkdir -p ./bisect
rsync -a --del --delete-excluded --exclude /bisect/ --exclude /artifacts/ --exclude /newlib/ ./ ./bisect/baseline/

cd newlib

# Reproduce first_bad build
git checkout --detach ff71c3fcdb9807fee8d9e5f898694ba56a02a013
../artifacts/test.sh

# Reproduce last_good build
git checkout --detach 90950758eb9f65227ef4ce8597ccc922959e25f6
../artifacts/test.sh

cd ..
</cut>

Full commit (up to 1000 lines):
<cut>
commit ff71c3fcdb9807fee8d9e5f898694ba56a02a013
Author: Jon Turney <jon.turney@dronecode.org.uk>
Date:   Wed Dec 8 15:40:59 2021 +0000

    README: configure.in -> configure.ac
    
    These files were renamed from that long deprecated name in commit
    92061799.
---
 newlib/README | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/newlib/README b/newlib/README
index 1c05412842..eac9f00454 100644
--- a/newlib/README
+++ b/newlib/README
@@ -545,14 +545,14 @@ $(source_dir)/src/configure --with-newlib --prefix=$(install_dir) --disable-shar
 Regenerating Configuration Files
 ================================
 
-At times you will need to make changes to configure.in and Makefile.am files.
+At times you will need to make changes to configure.ac and Makefile.am files.
 This will mean that configure and Makefile.in files will need to be
 regenerated.
 
 At the top level of newlib is the file: acinclude.m4.  This file contains
-the definition of the NEWLIB_CONFIGURE macro which is used by all configure.in
+the definition of the NEWLIB_CONFIGURE macro which is used by all configure.ac
 files in newlib.  You will notice that each directory in newlib containing
-a configure.in file also contains an aclocal.m4 file.  This file is
+a configure.ac file also contains an aclocal.m4 file.  This file is
 generated by issuing: aclocal -I${relative_path_to_toplevel_newlib_dir}
 -I${relative_path_to_toplevel_src_dir}
 The first relative directory is to access acinclude.m4.  The second relative
@@ -566,7 +566,7 @@ Note that if the top level acinclude.m4 is altered, every aclocal.m4 file
 in newlib should be regenerated.
 
 If the aclocal.m4 file is regenerated due to a change in acinclude.m4 or
-if a configure.in file is modified, the corresponding configure file in the 
+if a configure.ac file is modified, the corresponding configure file in the 
 directory must be regenerated using autoconf.  No parameters are necessary.
 In the previous example, we would issue:
 
@@ -581,12 +581,12 @@ files in newlib (and libgloss) are generated using the --cygnus option
 of automake.  
 
 Makefile.in files are generated from the nearest directory up the chain
-which contains a configure.in file.  In most cases, this is the same
-directory containing configure.in, but there are exceptions.
+which contains a configure.ac file.  In most cases, this is the same
+directory containing configure.ac, but there are exceptions.
 For example, the newlib/libc directory has a number of
-subdirectories that do not contain their own configure.in files (e.g. stdio).
+subdirectories that do not contain their own configure.ac files (e.g. stdio).
 For these directories, you must issue the automake command from newlib/libc
-which is the nearest parent directory that contains a configure.in.
+which is the nearest parent directory that contains a configure.ac.
 When you issue the automake command, you specify the subdirectory for
 the Makefile.in you are regenerating.  For example:
 
@@ -594,13 +594,13 @@ the Makefile.in you are regenerating.  For example:
 
 Note how multiple Makefile.in files can be created in the same step.  You
 would not specify machine/Makefile or sys/Makefile in the previous example
-because both of these subdirectories contain their own configure.in files.
+because both of these subdirectories contain their own configure.ac files.
 One would change to each of these subdirectories and in turn issue:
 
    automake --cygnus Makefile
 
 Let's say you create a new machine directory XXXX off of newlib/libc/machine.
-After creating a new configure.in and Makefile.am file, you would issue:
+After creating a new configure.ac and Makefile.am file, you would issue:
 
    aclocal -I ../../..
    autoconf
</cut>
>From hjl@sc.intel.com  Sat Dec 18 15:28:03 2021
Return-Path: <hjl@sc.intel.com>
X-Original-To: gcc-regression@gcc.gnu.org
Delivered-To: gcc-regression@gcc.gnu.org
Received: from mga12.intel.com (mga12.intel.com [192.55.52.136])
 by sourceware.org (Postfix) with ESMTPS id ADCC43858C27
 for <gcc-regression@gcc.gnu.org>; Sat, 18 Dec 2021 15:28:01 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ADCC43858C27
X-IronPort-AV: E=McAfee;i="6200,9189,10201"; a="219943808"
X-IronPort-AV: E=Sophos;i="5.88,216,1635231600"; d="scan'208";a="219943808"
Received: from fmsmga008.fm.intel.com ([10.253.24.58])
 by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 18 Dec 2021 07:28:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.88,216,1635231600"; d="scan'208";a="569355193"
Received: from scymds01.sc.intel.com ([10.148.94.138])
 by fmsmga008.fm.intel.com with ESMTP; 18 Dec 2021 07:27:59 -0800
Received: from gnu-skl-2.sc.intel.com (gnu-skl-2.sc.intel.com [172.25.33.218])
 by scymds01.sc.intel.com with ESMTP id 1BIFRxiD032563;
 Sat, 18 Dec 2021 07:27:59 -0800
Received: by gnu-skl-2.sc.intel.com (Postfix, from userid 1000)
 id DDF9F3C002C; Sat, 18 Dec 2021 07:27:59 -0800 (PST)
Date: Sat, 18 Dec 2021 07:27:59 -0800
To: skpgkp2@gmail.com, hjl.tools@gmail.com, gcc-regression@gcc.gnu.org
Subject: Regressions on releases/gcc-11 at commit r11-9399 vs commit
 r11-9375 on Linux/x86_64
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20211218152759.DDF9F3C002C@gnu-skl-2.sc.intel.com>
From: "H.J. Lu" <hjl@sc.intel.com>
X-Spam-Status: No, score=-3466.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, SPF_HELO_PASS, SPF_NONE,
 TXREP autolearn=no autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: gcc-regression@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-regression mailing list <gcc-regression.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-regression>,
 <mailto:gcc-regression-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-regression/>
List-Post: <mailto:gcc-regression@gcc.gnu.org>
List-Help: <mailto:gcc-regression-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-regression>,
 <mailto:gcc-regression-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Dec 2021 15:28:03 -0000

New failures:

New passes:
FAIL: g++.dg/asan/asan_test.C   -O2  (test for excess errors)
FAIL: g++.dg/asan/asan_test.C   -O2  (test for excess errors)
FAIL: g++.dg/asan/asan_test.C   -O2  (test for excess errors)
FAIL: g++.dg/cpp0x/decltype-bitfield1.C  -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp0x/decltype-bitfield1.C  -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp0x/decltype-bitfield1.C  -std=c++17 (test for excess errors)
FAIL: g++.dg/cpp0x/decltype-bitfield1.C  -std=c++17 (test for excess errors)
FAIL: g++.dg/cpp0x/decltype-bitfield1.C  -std=c++2a (test for excess errors)
FAIL: g++.dg/cpp0x/decltype-bitfield1.C  -std=c++2a (test for excess errors)

Re: [TCWG CI] Regression caused by newlib: README: configure.in -> configure.ac

[Maxim Kuvyrkov]

Hi Jon,

This was sent out due to a bug in our CI.  Sorry for the noise.

Regards,

--
Maxim Kuvyrkov
https://www.linaro.org

> On 18 Dec 2021, at 17:04, ci_notify@linaro.org wrote:
> 
> [TCWG CI] Regression caused by newlib: README: configure.in -> configure.ac:
> commit ff71c3fcdb9807fee8d9e5f898694ba56a02a013
> Author: Jon Turney <jon.turney@dronecode.org.uk>
> 
>    README: configure.in -> configure.ac
> 
> Results regressed to
> # reset_artifacts:
> -10
> # build_abe binutils:
> -9
> # build_abe stage1 -- --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard:
> -8
> # build_abe newlib:
> -6
> # build_abe stage2 -- --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard:
> -5
> # benchmark -- -Os_LTO_mthumb artifacts/build-ff71c3fcdb9807fee8d9e5f898694ba56a02a013/results_id:
> 1
> 
> from
> # reset_artifacts:
> -10
> # build_abe binutils:
> -9
> # build_abe stage1 -- --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard:
> -8
> # build_abe newlib:
> -6
> # build_abe stage2 -- --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard:
> -5
> # benchmark -- -Os_LTO_mthumb artifacts/build-baseline/results_id:
> 1
> 
> THIS IS THE END OF INTERESTING STUFF.  BELOW ARE LINKS TO BUILDS, REPRODUCTION INSTRUCTIONS, AND THE RAW COMMIT.
> 
> This commit has regressed these CI configurations:
> - tcwg_bmk_gnu_eabi_stm32/gnu_eabi-master-arm_eabi-coremark-Os_LTO
> 
> First_bad build: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eabi-master-arm_eabi-coremark-Os_LTO/14/artifact/artifacts/build-ff71c3fcdb9807fee8d9e5f898694ba56a02a013/
> Last_good build: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eabi-master-arm_eabi-coremark-Os_LTO/14/artifact/artifacts/build-90950758eb9f65227ef4ce8597ccc922959e25f6/
> Baseline build: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eabi-master-arm_eabi-coremark-Os_LTO/14/artifact/artifacts/build-baseline/
> Even more details: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eabi-master-arm_eabi-coremark-Os_LTO/14/artifact/artifacts/
> 
> Reproduce builds:
> <cut>
> mkdir investigate-newlib-ff71c3fcdb9807fee8d9e5f898694ba56a02a013
> cd investigate-newlib-ff71c3fcdb9807fee8d9e5f898694ba56a02a013
> 
> # Fetch scripts
> git clone https://git.linaro.org/toolchain/jenkins-scripts
> 
> # Fetch manifests and test.sh script
> mkdir -p artifacts/manifests
> curl -o artifacts/manifests/build-baseline.sh https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eabi-master-arm_eabi-coremark-Os_LTO/14/artifact/artifacts/manifests/build-baseline.sh --fail
> curl -o artifacts/manifests/build-parameters.sh https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eabi-master-arm_eabi-coremark-Os_LTO/14/artifact/artifacts/manifests/build-parameters.sh --fail
> curl -o artifacts/test.sh https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eabi-master-arm_eabi-coremark-Os_LTO/14/artifact/artifacts/test.sh --fail
> chmod +x artifacts/test.sh
> 
> # Reproduce the baseline build (build all pre-requisites)
> ./jenkins-scripts/tcwg_bmk-build.sh @@ artifacts/manifests/build-baseline.sh
> 
> # Save baseline build state (which is then restored in artifacts/test.sh)
> mkdir -p ./bisect
> rsync -a --del --delete-excluded --exclude /bisect/ --exclude /artifacts/ --exclude /newlib/ ./ ./bisect/baseline/
> 
> cd newlib
> 
> # Reproduce first_bad build
> git checkout --detach ff71c3fcdb9807fee8d9e5f898694ba56a02a013
> ../artifacts/test.sh
> 
> # Reproduce last_good build
> git checkout --detach 90950758eb9f65227ef4ce8597ccc922959e25f6
> ../artifacts/test.sh
> 
> cd ..
> </cut>
> 
> Full commit (up to 1000 lines):
> <cut>
> commit ff71c3fcdb9807fee8d9e5f898694ba56a02a013
> Author: Jon Turney <jon.turney@dronecode.org.uk>
> Date:   Wed Dec 8 15:40:59 2021 +0000
> 
>    README: configure.in -> configure.ac
> 
>    These files were renamed from that long deprecated name in commit
>    92061799.
> ---
> newlib/README | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/newlib/README b/newlib/README
> index 1c05412842..eac9f00454 100644
> --- a/newlib/README
> +++ b/newlib/README
> @@ -545,14 +545,14 @@ $(source_dir)/src/configure --with-newlib --prefix=$(install_dir) --disable-shar
> Regenerating Configuration Files
> ================================
> 
> -At times you will need to make changes to configure.in and Makefile.am files.
> +At times you will need to make changes to configure.ac and Makefile.am files.
> This will mean that configure and Makefile.in files will need to be
> regenerated.
> 
> At the top level of newlib is the file: acinclude.m4.  This file contains
> -the definition of the NEWLIB_CONFIGURE macro which is used by all configure.in
> +the definition of the NEWLIB_CONFIGURE macro which is used by all configure.ac
> files in newlib.  You will notice that each directory in newlib containing
> -a configure.in file also contains an aclocal.m4 file.  This file is
> +a configure.ac file also contains an aclocal.m4 file.  This file is
> generated by issuing: aclocal -I${relative_path_to_toplevel_newlib_dir}
> -I${relative_path_to_toplevel_src_dir}
> The first relative directory is to access acinclude.m4.  The second relative
> @@ -566,7 +566,7 @@ Note that if the top level acinclude.m4 is altered, every aclocal.m4 file
> in newlib should be regenerated.
> 
> If the aclocal.m4 file is regenerated due to a change in acinclude.m4 or
> -if a configure.in file is modified, the corresponding configure file in the 
> +if a configure.ac file is modified, the corresponding configure file in the 
> directory must be regenerated using autoconf.  No parameters are necessary.
> In the previous example, we would issue:
> 
> @@ -581,12 +581,12 @@ files in newlib (and libgloss) are generated using the --cygnus option
> of automake.  
> 
> Makefile.in files are generated from the nearest directory up the chain
> -which contains a configure.in file.  In most cases, this is the same
> -directory containing configure.in, but there are exceptions.
> +which contains a configure.ac file.  In most cases, this is the same
> +directory containing configure.ac, but there are exceptions.
> For example, the newlib/libc directory has a number of
> -subdirectories that do not contain their own configure.in files (e.g. stdio).
> +subdirectories that do not contain their own configure.ac files (e.g. stdio).
> For these directories, you must issue the automake command from newlib/libc
> -which is the nearest parent directory that contains a configure.in.
> +which is the nearest parent directory that contains a configure.ac.
> When you issue the automake command, you specify the subdirectory for
> the Makefile.in you are regenerating.  For example:
> 
> @@ -594,13 +594,13 @@ the Makefile.in you are regenerating.  For example:
> 
> Note how multiple Makefile.in files can be created in the same step.  You
> would not specify machine/Makefile or sys/Makefile in the previous example
> -because both of these subdirectories contain their own configure.in files.
> +because both of these subdirectories contain their own configure.ac files.
> One would change to each of these subdirectories and in turn issue:
> 
>    automake --cygnus Makefile
> 
> Let's say you create a new machine directory XXXX off of newlib/libc/machine.
> -After creating a new configure.in and Makefile.am file, you would issue:
> +After creating a new configure.ac and Makefile.am file, you would issue:
> 
>    aclocal -I ../../..
>    autoconf
> </cut>